כפי שמתואר בזמינות הפלטפורמה, התשתית שלGoogle Cloud מתוכננת לתמוך בזמינות יעד של 99.9% לעומס עבודה שנפרס באזור יחיד. זמינות היעד היא 99.99% לפריסה במספר אזורים1 ו-99.999% לפריסה במספר אזורים. החלק הזה בGoogle Cloud מדריך לאמינות התשתית מספק הנחיות לפריסה, דוגמאות לארכיטקטורות וטכניקות עיצוב שיכולות לעזור לכם להגן על עומסי העבודה מפני כשלים ברמת המשאב, האזור והאזור.
הימנעות מנקודות כשל בודדות
אפליקציות מורכבות בדרך כלל מכמה רכיבים שתלויים זה בזה, וכל אחד מהם נועד לבצע פונקציה ספציפית. בדרך כלל, הרכיבים האלה מקובצים לרמות על סמך הפונקציה שהם מבצעים והקשר שלהם לרכיבים האחרים. לדוגמה, לאפליקציה שמציגה תוכן יכולים להיות שלושה רבדים: רובד אינטרנט שמכיל מאזן עומסים ושרתי אינטרנט, רובד אפליקציה עם אשכול של שרתי אפליקציות ורובד נתונים להתמדה. אם רכיב כלשהו במערך האפליקציות הזה מסתמך על משאב תשתית יחיד, כשל במשאב הזה יכול להשפיע על הזמינות של המערך כולו. לדוגמה, אם שכבת האפליקציה פועלת במכונה וירטואלית אחת, ואם המכונה הווירטואלית קורסת, אז כל הערימה לא זמינה. רכיב כזה הוא נקודת כשל בודדת (SPOF).
יכול להיות שיש יותר מנקודת כשל יחידה אחת במערך של אפליקציה. נבחן את מחסנית האפליקציות הרב-שכבתית שמוצגת בדיאגרמה הבאה:
כפי שמוצג בתרשים הקודם, הארכיטקטורה לדוגמה הזו מכילה מאזן עומסים אחד, שני שרתי אינטרנט, שרת אפליקציות אחד ומסד נתונים אחד. מאזן העומסים, שרת האפליקציות ומסד הנתונים בדוגמה הזו הם נקודות כשל יחידות (SPOF). אם אחד מהרכיבים האלה ייכשל, בקשות המשתמשים לאפליקציה ייכשלו.
כדי להסיר את נקודות הכשל היחידות במערך האפליקציות, צריך לפזר את המשאבים בין מיקומים שונים ולפרוס משאבים מיותרים.
הפצה של משאבים ויצירת יתירות
בהתאם לדרישות האמינות של האפליקציה, אפשר לבחור מבין ארכיטקטורות הפריסה הבאות:
| ארכיטקטורה | המלצה לעומס עבודה |
|---|---|
| במספר אזורים | עומסי עבודה שהם קריטיים לעסק ושבהם זמינות גבוהה היא חיונית, כמו יישומי קמעונאות ומדיה חברתית. |
| רב-אזורי | עומסי עבודה שצריכים עמידות בפני הפסקות זמניות באזורים, אבל יכולים לסבול השבתה מסוימת שנגרמת בגלל הפסקות זמניות באזורים. |
| אזור יחיד | עומסי עבודה שיכולים לעמוד בהשבתה או שאפשר לפרוס אותם במיקום אחר כשצריך, במאמץ מינימלי. |
שיקולים לגבי עלות, זמן אחזור ותפעול
כשמתכננים ארכיטקטורה מבוזרת עם משאבים מיותרים, צריך לקחת בחשבון, בנוסף לדרישות הזמינות של האפליקציה, גם את ההשפעות על מורכבות התפעול, על זמן האחזור ועל העלות.
בארכיטקטורה מבוזרת, אתם מקצים ומנהלים מספר גדול יותר של משאבים. נפח התנועה ברשת בין מיקומים גבוה יותר. אתם גם מאחסנים ומשכפלים יותר נתונים. כתוצאה מכך, העלות של משאבי הענן בארכיטקטורה מבוזרת גבוהה יותר, והתפעול של פריסות כאלה מורכב יותר. במקרה של אפליקציות קריטיות לעסק, היתרון של זמינות גבוהה יותר בארכיטקטורה מבוזרת עשוי להיות חשוב יותר מהעלות הגבוהה וממורכבות התפעול.
באפליקציות שלא חיוניות לעסק, יכול להיות שהזמינות הגבוהה שארכיטקטורה מבוזרת מספקת לא חיונית. יש אפליקציות מסוימות שבהן יש דרישות אחרות שחשובות יותר מהזמינות. לדוגמה, אפליקציות של עיבוד באצווה דורשות חיבורי רשת עם זמן אחזור נמוך ורוחב פס גבוה בין מכונות ה-VM. ארכיטקטורה של אזור יחיד יכולה להתאים מאוד לאפליקציות כאלה, והיא גם יכולה לעזור לכם לצמצם את עלויות העברת הנתונים.
ארכיטקטורות פריסה
בקטע הזה מוצגות האפשרויות הבאות לארכיטקטורה לבניית תשתית לעומסי העבודה ב- Google Cloud:
- פריסה באזור יחיד
- פריסה בכמה אזורים
- פריסה בכמה אזורים עם איזון עומסים אזורי
- פריסה במספר אזורים עם איזון עומסים גלובלי
פריסה באזור יחיד
התרשים הבא מציג ארכיטקטורת אפליקציה באזור יחיד עם יתירות בכל רמה, כדי להשיג זמינות גבוהה יותר של הפונקציות שמבוצעות על ידי כל רכיב:
כפי שמוצג בתרשים הקודם, הארכיטקטורה לדוגמה הזו כוללת את הרכיבים הבאים:
- מאזן עומסים חיצוני אזורי מסוג HTTP/S לקבלת בקשות משתמשים ולמענה עליהן.
- קבוצת מופעי מכונה מנוהלת (MIG) אזורית כבק-אנד למאזן עומסים מסוג HTTP/S. קבוצת ה-MIG כוללת שתי מכונות וירטואליות ב-Compute Engine. כל מכונה וירטואלית מארחת מופע של שרת אינטרנט.
- מאזן עומסים פנימי לטיפול בתקשורת בין שרת האינטרנט לבין מופעי שרת האפליקציות.
- קבוצת MIG אזורית שנייה כבק-אנד למאזן העומסים הפנימי. ה-MIG הזה מכיל שתי מכונות וירטואליות ב-Compute Engine. כל מכונה וירטואלית מארחת מופע של שרת אפליקציות.
- מכונת מסד נתונים ב-Cloud SQL (מהדורת Enterprise) שהאפליקציה כותבת נתונים לתוכה וקוראת נתונים ממנה. מסד הנתונים משוכפל באופן ידני למכונת מסד נתונים שנייה ב-Cloud SQL באותו אזור.
זמינות מצטברת: פריסה באזור יחיד
בטבלה הבאה מוצגת הזמינות של כל רמה בתרשים הארכיטקטורה של אזור יחיד שמופיע למעלה:
| משאב | הסכם רמת שירות (SLA) |
|---|---|
| מאזן עומסים חיצוניים | 99.99% |
| שכבת האינטרנט: מכונות וירטואליות ב-Compute Engine בתחום אחד | 99.9% |
| מאזן עומסים פנימיים | 99.99% |
| שכבת האפליקציה: מכונות וירטואליות ב-Compute Engine באזור אחד | 99.9% |
| מכונה של Cloud SQL (מהדורת Enterprise) | 99.95% |
אפשר לצפות שמשאבי התשתית שמפורטים בטבלה הקודמת יספקו את הזמינות המצטברת הבאה ואת זמן ההשבתה החודשי המקסימלי המשוער: Google Cloud
- זמינות מצטברת: 0.9999 x 0.999 x 0.9999 x 0.999 x 0.9995 = 99.73%
- זמן ההשבתה החודשי המקסימלי המשוער: כשעה ו-57 דקות
בחישוב הזה נלקחים בחשבון רק משאבי התשתית שמוצגים בתרשים הארכיטקטורה שלמעלה. כדי להעריך את הזמינות של אפליקציה ב- Google Cloud, צריך להביא בחשבון גם גורמים אחרים, כמו:
- העיצוב הפנימי של האפליקציה
- תהליכי DevOps והכלים שמשמשים לפיתוח, לפריסה ולתחזוקה של האפליקציה, של קשרי התלות שלה ושל התשתית של Google Cloud
מידע נוסף זמין במאמר גורמים שמשפיעים על מהימנות האפליקציה.
ההשפעות של הפסקות זמניות בשירות והנחיות לשחזור
בארכיטקטורת פריסה של אזור יחיד, אם רכיב כלשהו נכשל, האפליקציה יכולה לעבד בקשות אם כל רמה מכילה לפחות רכיב אחד מתפקד עם קיבולת מספקת. לדוגמה, אם מופע של שרת אינטרנט נכשל, מאזן העומסים מעביר את בקשות המשתמשים למופעים אחרים של שרת האינטרנט. אם מכונה וירטואלית שמארחת שרת אינטרנט או מופע של שרת אפליקציות קורסת, קבוצת ה-MIG מוודאת שמכונה וירטואלית חדשה נוצרת באופן אוטומטי. אם מסד הנתונים קורס, צריך להפעיל ידנית את מסד הנתונים השני ולעדכן את המופעים של שרת האפליקציות כדי להתחבר למסד הנתונים.
הפסקה זמנית בשירות באזור או באזור מוגדר משפיעה על המכונות הווירטואליות ב-Compute Engine ועל מופעי מסדי הנתונים ב-Cloud SQL בפריסה באזור יחיד. הפסקה זמנית בשירות באזור לא משפיעה על מאזן העומסים בארכיטקטורה הזו כי הוא משאב אזורי. עם זאת, מאזן העומסים לא יכול להפיץ את התנועה כי אין קצה עורפי זמין. אם מתרחשת הפסקה זמנית בשירות באזור, צריך לחכות ש-Google תפתור את הבעיה, ואז לוודא שהאפליקציה פועלת כמצופה.
בקטע הבא מתואר גישה ארכיטקטונית שבה אפשר להשתמש כדי לפזר משאבים על פני כמה אזורים, וכך לשפר את עמידות האפליקציה בפני הפסקות זמניות בשירות באזורים.
פריסה רב-אזורית
בפריסה של אזור יחיד, אם מתרחשת הפסקה זמנית בשירות באזור, יכול להיות שהאפליקציה לא תוכל לטפל בבקשות עד שהבעיה תיפתר. כדי לעזור לשפר את החוסן (resilience) של האפליקציה שלכם מפני הפסקות זמניות בשירות באזורים, אתם יכולים להקצות כמה מופעים של משאבים של תחום מוגדר (כמו מכונות וירטואליות ב-Compute Engine) בשני אזורים או יותר. בשירותים שתומכים במשאבים בהיקף אזורי (כמו קטגוריות של Cloud Storage), אפשר לפרוס משאבים אזוריים.
התרשים הבא מציג ארכיטקטורה עם זמינות גבוהה בין אזורים, שבה הרכיבים בכל שכבה של מחסנית האפליקציות מפוזרים בין שני אזורים:
כפי שמוצג בתרשים הקודם, הארכיטקטורה לדוגמה הזו כוללת את הרכיבים הבאים:
- מאזן עומסים חיצוני אזורי מסוג HTTP/S מקבל בקשות ממשתמשים ומגיב להן.
- קבוצת MIG אזורית היא הקצה העורפי של מאזן העומסים HTTP/S. ה-MIG מכיל שתי מכונות וירטואליות ב-Compute Engine באזורים שונים. כל מכונה וירטואלית מארחת מופע של שרת אינטרנט.
- מאזן עומסים פנימי מטפל בתקשורת בין שרת האינטרנט לבין מופעי שרת האפליקציות.
- קבוצת MIG אזורית שנייה היא הבק-אנד של מאזן העומסים ב-TCP. קבוצת ה-MIG הזו כוללת שתי מכונות וירטואליות ב-Compute Engine באזורים שונים. כל מכונה וירטואלית מארחת מופע של שרת אפליקציות.
- מופע Cloud SQL (מהדורת Enterprise) שהוגדר לזמינות גבוהה הוא מסד הנתונים של האפליקציה. מופע מסד הנתונים הראשי משוכפל באופן סינכרוני למופע מסד נתונים במצב המתנה.
זמינות מצטברת: פריסה מרובת אזורים
בטבלה הבאה מוצגת הזמינות של כל רמה בתרשים הארכיטקטורה הקודם עם שני אזורים:
| משאב | הסכם רמת שירות (SLA) |
|---|---|
| מאזן עומסים חיצוניים | 99.99% |
| שכבת האינטרנט: מכונות וירטואליות של Compute Engine בתחומים נפרדים | 99.99% |
| מאזן עומסים פנימיים | 99.99% |
| שכבת האפליקציה: מכונות וירטואליות של Compute Engine באזורים נפרדים | 99.99% |
| מכונה של Cloud SQL (מהדורת Enterprise) | 99.95% |
אפשר לצפות שמשאבי התשתית שמפורטים בטבלה הקודמת יספקו את הזמינות המצטברת הבאה ואת זמן ההשבתה החודשי המקסימלי המשוער: Google Cloud
- זמינות מצטברת: 0.9999 x 0.9999 x 0.9999 x 0.9999 x 0.9995 = 99.91%
- זמן ההשבתה החודשי המקסימלי המשוער: כ-39 דקות
בחישוב הזה נלקחים בחשבון רק משאבי התשתית שמוצגים בתרשים הארכיטקטורה שלמעלה. כדי להעריך את הזמינות של אפליקציה ב- Google Cloud, צריך להביא בחשבון גם גורמים אחרים, כמו:
- העיצוב הפנימי של האפליקציה
- תהליכי DevOps והכלים שמשמשים לפיתוח, לפריסה ולתחזוקה של האפליקציה, של קשרי התלות שלה ושל התשתית של Google Cloud
מידע נוסף זמין במאמר גורמים שמשפיעים על מהימנות האפליקציה.
ההשפעות של הפסקות זמניות בשירות והנחיות לשחזור
בפריסה דו-אזורית, אם רכיב כלשהו נכשל, האפליקציה יכולה לעבד בקשות אם קיים רכיב אחד לפחות בכל שכבה עם קיבולת מספקת. לדוגמה, אם מופע של שרת אינטרנט נכשל, מאזן העומסים מעביר את בקשות המשתמשים למופע של שרת האינטרנט באזור השני. אם מכונה וירטואלית שמארחת שרת אינטרנט או מופע של שרת אפליקציות קורסת, קבוצת ה-MIG מוודאת שמכונה וירטואלית חדשה נוצרת באופן אוטומטי. אם מסד הנתונים הראשי ב-Cloud SQL קורס, Cloud SQL מבצע אוטומטית מעבר לגיבוי כשל למופע מסד הנתונים במצב המתנה.
בתרשים הבא מוצגת אותה ארכיטקטורה כמו בתרשים הקודם, וההשפעות של הפסקת חשמל באזור על הזמינות של האפליקציה:
כפי שמוצג בדיאגרמה הקודמת, אם מתרחשת הפסקה זמנית בשירות באחד מהאזורים, מאזן העומסים בארכיטקטורה הזו לא מושפע, כי הוא משאב אזורי. הפסקה זמנית בשירות באזור עלולה להשפיע על מכונות וירטואליות ספציפיות ב-Compute Engine ועל אחד ממופעי מסד הנתונים של Cloud SQL. אבל האפליקציה נשארת זמינה ומגיבה, כי המכונות הווירטואליות נמצאות בקבוצות אזוריות של MIG ומסד הנתונים של Cloud SQL מוגדר לזמינות גבוהה. קבוצות ה-MIG מבטיחות שמכונות וירטואליות חדשות ייווצרו באופן אוטומטי כדי לשמור על המספר המינימלי של מכונות וירטואליות שהוגדר. אם מכונת מסד הנתונים הראשית ב-Cloud SQL מושפעת מהפסקה זמנית בשירות באזור, Cloud SQL עובר אוטומטית לגיבוי למכונת הגיבוי באזור השני. אחרי ש-Google תפתור את ההפסקה הזמנית בשירות, תצטרכו לוודא שהאפליקציה פועלת כצפוי בכל האזורים שבהם היא נפרסה.
אם יש הפסקת חשמל בשני האזורים בארכיטקטורה הזו, האפליקציה לא תהיה זמינה. מאזן העומסים ממשיך להיות זמין אלא אם מתרחש שיבוש ברמה האזורית. עם זאת, מאזן העומסים לא יכול להפיץ את התנועה כי אין קצה עורפי זמין. אם מתרחשת הפסקה זמנית בשירות בכמה אזורים או באזור מסוים, צריך לחכות ש-Google תפתור את הבעיה, ואז לוודא שהאפליקציה פועלת כצפוי.
בקטעים הבאים מוצגות אפשרויות ארכיטקטוניות להגנה על האפליקציה מפני הפסקות זמניות בשירות בכמה אזורים והפסקות זמניות בשירות באזור מסוים.
פריסה בכמה אזורים עם איזון עומסים אזורי
בפריסה של אזור יחיד או של מספר אזורים, אם מתרחשת הפסקה זמנית בשירות באזור, האפליקציה לא יכולה לטפל בבקשות עד שהבעיה תיפתר. כדי להגן על האפליקציה מפני הפסקות חשמל באזור מסוים, אפשר לפזר את המשאבים בין שני אזורים או יותר. Google Cloud
התרשים הבא מציג ארכיטקטורה עם זמינות גבוהה בין אזורים, שבה הרכיבים בכל שכבה של מחסנית האפליקציות מפוזרים על פני כמה אזורים:
כפי שמוצג בתרשים הקודם, הארכיטקטורה לדוגמה הזו כוללת את הרכיבים הבאים:
- תחום DNS ציבורי ב-Cloud DNS עם מדיניות ניתוב שמפנה תעבורה לשני אזורים Google Cloud .
- מאזן עומסים חיצוני אזורי מסוג HTTP/S בכל אזור, כדי לקבל בקשות ממשתמשים ולהגיב להן.
- הקצה העורפי של כל מאזן עומסים אזורי מסוג HTTP/S הוא MIG אזורי. כל קבוצת MIG מכילה שתי מכונות וירטואליות של Compute Engine באזורים שונים. כל אחת מהמכונות הווירטואליות האלה מארחת מופע של שרת אינטרנט.
- מאזן עומסים פנימי בכל אזור מטפל בתקשורת בין מופעי שרת האינטרנט לבין מופעי שרת האפליקציות.
- זוג שני של קבוצות אזוריות של מכונות מנוהלות (MIG) משמש כבק-אנד למאזני עומסים פנימיים. כל קבוצת MIG מכילה שתי מכונות וירטואליות של Compute Engine באזורים שונים. כל מכונה וירטואלית מארחת מופע של שרת אפליקציות.
- האפליקציה כותבת נתונים למופע Spanner במספר אזורים וקוראת ממנו נתונים. ההגדרה במספר אזורים שמשמשת בארכיטקטורה הזו (
eur6) כוללת ארבעה עותקים משוכפלים לקריאה ולכתיבה. ההעתקים לקריאה ולכתיבה מוקצים באופן שווה בשני אזורים ובאזורים נפרדים. ההגדרה של Spanner במספר אזורים כוללת גם רפליקת עדות באזור שלישי.
זמינות מצטברת: פריסה במספר אזורים עם איזון עומסים אזורי
בפריסה במספר אזורים שמוצגת בתרשים הקודם, מאזני העומסים והמכונות הווירטואליות מוקצים באופן מיותר בשני אזורים. אזור ה-DNS הוא משאב גלובלי, ומופע Spanner הוא משאב במספר אזורים.
כדי לחשב את הזמינות הכוללת של התשתית שמוצגת בארכיטקטורה הזו, קודם צריך לחשב את הזמינות הכוללת של המשאבים בכל אזור, ואז להתייחס למשאבים שמשתרעים על כמה אזורים. Google Cloudכך עושים זאת:
- חישוב הזמינות הכוללת של משאבי התשתית לכל אזור, כלומר ללא משאבי ה-DNS והמסד הנתונים:
משאבים והסכמי רמת שירות (SLA) הסכם רמת שירות (SLA) מאזן עומסים חיצוניים 99.99% שכבת האינטרנט: מכונות וירטואליות של Compute Engine בתחומים נפרדים 99.99% מאזן עומסים פנימיים 99.99% שכבת האפליקציה: מכונות וירטואליות של Compute Engine באזורים נפרדים 99.99% זמינות מצטברת לכל אזור: 0.9999 x 0.9999 x 0.9999 x 0.9999 = 99.96%
חישוב הזמינות הכוללת של משאבי התשתית, תוך התחשבות ביתירות הכשל של מאזני העומסים ושל המכונות הווירטואליות של Compute Engine באזורים הכפולים.
הזמינות התיאורטית היא 1-(1-0.9996)(1-0.9996) = 99.999984%. עם זאת, הזמינות בפועל שאתם יכולים לצפות לה מוגבלת לזמינות היעד לפריסות מרובות אזורים, שהיא 99.999%.
חישוב הזמינות הכוללת של כל משאבי התשתית, כולל משאבי Cloud DNS ו-Spanner:
- זמינות מצטברת: 0.99999 x 1 x 0.99999 = 99.998%
- זמן ההשבתה החודשי המקסימלי המשוער: כ-52 שניות
בחישוב הזה נלקחים בחשבון רק משאבי התשתית שמוצגים בתרשים הארכיטקטורה שלמעלה. כדי להעריך את הזמינות של אפליקציה ב- Google Cloud, צריך להביא בחשבון גם גורמים אחרים, כמו:
- העיצוב הפנימי של האפליקציה
- תהליכי DevOps והכלים שמשמשים לפיתוח, לפריסה ולתחזוקה של האפליקציה, של קשרי התלות שלה ושל התשתית של Google Cloud
מידע נוסף זמין במאמר גורמים שמשפיעים על מהימנות האפליקציה.
ההשפעות של הפסקות זמניות בשירות והנחיות לשחזור
אם רכיב כלשהו בפריסה הרב-אזורית הזו נכשל, אבל יש לפחות רכיב אחד מתפקד עם קיבולת מספקת בכל רמה, האפליקציה ממשיכה לפעול. לדוגמה, אם מופע של שרת אינטרנט נכשל, מאזן העומסים החיצוני האזורי של HTTP/S מעביר את בקשות המשתמשים למופעים אחרים של שרת האינטרנט באזור. באופן דומה, אם אחת מהמכונות של שרת האפליקציה קורסת, מאזני העומסים הפנימיים שולחים בקשות למכונות האחרות של שרת האפליקציה. אם אחת מהמכונות הווירטואליות קורסת, קבוצות ה-MIG מוודאות שמכונות וירטואליות חדשות נוצרות באופן אוטומטי כדי לשמור על המספר המינימלי של מכונות וירטואליות שהוגדר.
הפסקה זמנית בשירות באזור אחד לא משפיעה על מאזני העומסים, כי הם משאבים אזוריים ועמידים להפסקות זמניות בשירות באזורים. יכול להיות שהפסקת חשמל באזור תשפיע על מכונות וירטואליות ספציפיות ב-Compute Engine. אבל המכונות הווירטואליות של שרת האינטרנט ושרת האפליקציה נשארות זמינות, כי הן חלק מקבוצות MIG אזוריות. קבוצות ה-MIG מבטיחות שמכונות וירטואליות חדשות ייווצרו באופן אוטומטי כדי לשמור על המספר המינימלי של מכונות וירטואליות שהוגדר. מופע Spanner בארכיטקטורה הזו משתמש בהגדרה של מספר אזורים, שמאפשרת עמידות להפסקות זמניות באזורים.
מידע על אופן הפעולה של שכפול במספר אזורים ב-Spanner זמין במאמרים Regional and multi-region configurations ו- Demystifying Spanner multi-region configurations.
בתרשים הבא מוצגת אותה ארכיטקטורה במספר אזורים כמו בתרשים הקודם, וההשפעות של הפסקה זמנית בשירות באזור יחיד על הזמינות של האפליקציה:
כפי שמוצג בדיאגרמה הקודמת, גם אם מתרחשת הפסקה זמנית בשירות בשני האזורים בכל אזור, האפליקציה ממשיכה להיות זמינה, כי מחסנית אפליקציות עצמאית נפרסת בכל אזור. תחום ה-DNS מפנה את בקשות המשתמשים לאזור שלא מושפע מההפסקה הזמנית בשירות. מופע Spanner במספר אזורים עמיד בפני הפסקות זמניות בשירות באזור מסוים. אחרי ש-Google תפתור את הבעיה, תצטרכו לוודא שהאפליקציה פועלת כצפוי באזור שבו הייתה הפסקת השירות.
אם יש הפסקות חשמל בשני אזורים כלשהם בארכיטקטורה הזו, האפליקציה לא תהיה זמינה. צריך לחכות ש-Google תפתור את הבעיות בהפסקות השירות. לאחר מכן, מוודאים שהאפליקציה פועלת כצפוי בכל האזורים שבהם היא נפרסה.
בפריסות במספר אזורים, במקום להשתמש במאזני עומסים אזוריים, אפשר להשתמש במאזן עומסים גלובלי. בקטע הבא מוצגת ארכיטקטורת פריסה מרובת אזורים שמשתמשת במאזן עומסים גלובלי, ומתוארים היתרונות והסיכונים של הגישה הזו.
פריסה בכמה אזורים עם איזון עומסים גלובלי
בתרשים הבא מוצגת פריסה חלופית במספר אזורים שבה נעשה שימוש במאזן עומסים גלובלי במקום במאזני עומסים אזוריים:
כפי שמוצג בתרשים הקודם, ארכיטקטורה זו משתמשת במאזן עומסים גלובלי חיצוני של HTTP/S (עם Cloud CDN מופעל) כדי לקבל בקשות של משתמשים ולהגיב להן. כל כלל העברה של מאזן העומסים משתמש בכתובת IP חיצונית אחת, כך שלא צריך להגדיר רשומת DNS נפרדת לכל אזור. הקצה העורפי של מאזן העומסים הגלובלי החיצוני מסוג HTTP/S מורכב משתי קבוצות אזוריות של מכונות מנוהלות (MIG). מאזן העומסים מנתב בקשות לאזור שהכי קרוב למשתמשים.
כל שאר הרכיבים בארכיטקטורה הזו זהים לארכיטקטורה שמוצגת במאמר פריסה במספר אזורים עם איזון עומסים אזורי.
יתרונות וסיכונים של איזון עומסים גלובלי לפריסות במספר אזורים
כדי לבצע איזון עומסים של תעבורה חיצונית לאפליקציה שמפוזרת בכמה אזורים, אפשר להשתמש במאזן עומסים גלובלי או בכמה מאזני עומסים אזוריים.
אלה היתרונות של ארכיטקטורה שמשתמשת במאזן עומסים גלובלי:
- אתם צריכים לנהל רק איזון עומסים אחד.
- מאזני עומסים גלובליים משתמשים בכתובת IP אחת מסוג anycast כדי לספק איזון עומסים בין Google Cloud אזורים.
- מאזני עומסים גלובליים עמידים להפסקות זמניות בשירות באזור, ומספקים יתירות כשל אוטומטית בין אזורים.
- מאזני עומסים גלובליים תומכים בתכונות הבאות, שיכולות לעזור לשפר את המהימנות של הפריסות:
- שמירה במטמון קצה באמצעות Cloud CDN
- אפשרות להשתמש בקטגוריות של Cloud Storage עם עמידות גבוהה בתור בק-אנד
- כללי מדיניות האבטחה של Google Cloud Armor
אלה הסיכונים בארכיטקטורה שמשתמשת במאזן עומסים גלובלי:
- שינוי שגוי בהגדרות של מאזן העומסים הגלובלי עלול לגרום לכך שהאפליקציה לא תהיה זמינה למשתמשים. לדוגמה, אם במהלך עדכון קצה קדמי של מאזן עומסים גלובלי, אתם מוחקים בטעות כלל העברה, מאזן העומסים מפסיק לקבל בקשות ממשתמשים. ההשפעה של הסיכון הזה נמוכה יותר במקרה של ארכיטקטורה מרובת אזורים שמשתמשת במאזני עומסים אזוריים, כי גם אם מאזן העומסים האזורי באחד האזורים מושפע משגיאת הגדרה, מאזני העומסים באזורים האחרים ממשיכים לפעול.
- הפסקת שירות בתשתית שמשפיעה על משאבים גלובליים עלולה לגרום לכך שמאזן העומסים הגלובלי לא יהיה זמין.
כדי למזער את הסיכונים האלה, צריך לנהל את השינויים במאזן העומסים הגלובלי בקפידה, וכדאי להשתמש בחלופות גיבוי מרובות שכבות כשזה אפשרי. למידע נוסף, אפשר לעיין במאמר המלצות לניהול הסיכון של הפסקות שירות במשאבים גלובליים.
זמינות מצטברת: פריסה במספר אזורים עם איזון עומסים גלובלי
בפריסה במספר אזורים שמוצגת בתרשים הקודם, המכונות הווירטואליות ומאזני העומסים הפנימיים מפוזרים באופן מיותר בשני אזורים. מאזן העומסים החיצוני הוא משאב גלובלי, ומופע Spanner הוא משאב במספר אזורים.
כדי לחשב את הזמינות הכוללת של הפריסה הזו, קודם מחשבים את הזמינות הכוללת של המשאבים בכל אזור, ואז מתייחסים למשאבים שמשתרעים על פני כמה אזורים.
- חישוב הזמינות הכוללת של משאבי התשתית לכל אזור, לא כולל מאזן העומסים החיצוני ומסד הנתונים:
משאב הסכם רמת שירות (SLA) שכבת האינטרנט: מכונות וירטואליות של Compute Engine בתחומים נפרדים 99.99% מאזן עומסים פנימיים 99.99% שכבת האפליקציה: מכונות וירטואליות של Compute Engine באזורים נפרדים 99.99% זמינות מצטברת לכל אזור: 0.9999 x 0.9999 x 0.9999 = 99.97%
חישוב הזמינות הכוללת של משאבי התשתית, תוך התחשבות ביתירות הכשל של מאזן העומסים הפנימי ושל המכונות הווירטואליות ב-Compute Engine באזורים הכפולים.
הזמינות התיאורטית היא 1-(1-0.9997)(1-0.9997) = 99.999991%. עם זאת, הזמינות בפועל שאתם יכולים לצפות לה מוגבלת לזמינות היעד לפריסות מרובות אזורים, שהיא 99.999%.
חישוב הזמינות הכוללת של כל משאבי התשתית, כולל מאזן העומסים הגלובלי ומשאבי Spanner:
- זמינות מצטברת: 0.99999 x 0.9999 x 0.99999 = 99.988%
- זמן ההשבתה החודשי המקסימלי המשוער: כ-5 דקות ו-11 שניות
בחישוב הזה נלקחים בחשבון רק משאבי התשתית שמוצגים בתרשים הארכיטקטורה שלמעלה. כדי להעריך את הזמינות של אפליקציה ב- Google Cloud, צריך להביא בחשבון גם גורמים אחרים, כמו:
- העיצוב הפנימי של האפליקציה
- תהליכי DevOps והכלים שמשמשים לפיתוח, לפריסה ולתחזוקה של האפליקציה, של קשרי התלות שלה ושל התשתית של Google Cloud
מידע נוסף זמין במאמר גורמים שמשפיעים על מהימנות האפליקציה.
ההשפעות של הפסקות זמניות בשירות והנחיות לשחזור
אם רכיב כלשהו בארכיטקטורה הזו נכשל, האפליקציה ממשיכה לפעול אם קיים לפחות רכיב אחד בכל שכבה עם קיבולת מספקת. לדוגמה, אם מופע של שרת אינטרנט נכשל, מאזן העומסים הגלובלי החיצוני מסוג HTTP/S מעביר את בקשות המשתמשים למופעים אחרים של שרת האינטרנט. אם מופעלת יחידת שרת אפליקציה, מאזני העומסים הפנימיים שולחים את הבקשות ליחידות אחרות של שרת האפליקציה. אם אחת מהמכונות הווירטואליות קורסת, קבוצות ה-MIG מוודאות שמכונות וירטואליות חדשות נוצרות באופן אוטומטי כדי לשמור על המספר המינימלי של מכונות וירטואליות שהוגדר.
אם מתרחשת הפסקה זמנית בשירות באחד מהתחומים באזור כלשהו, מאזן העומסים לא מושפע. מאזן העומסים הגלובלי החיצוני מסוג HTTP/S עמיד להפסקות חשמל באזורים ובאזורי זמינות. מאזני העומסים הפנימיים הם משאבים אזוריים, ולכן הם עמידים בפני הפסקות זמניות בשירות באזור מסוים. הפסקת חשמל באזור מסוים עלולה להשפיע על מכונות וירטואליות ספציפיות ב-Compute Engine. אבל מופעי שרת האינטרנט ושרת האפליקציות נשארים זמינים, כי המכונות הווירטואליות הן חלק מקבוצות MIG אזוריות. קבוצות ה-MIG מוודאות שמכונות וירטואליות חדשות נוצרות באופן אוטומטי כדי לשמור על המספר המינימלי של מכונות וירטואליות שהוגדר. מופע Spanner בארכיטקטורה הזו משתמש בהגדרה של מספר אזורים, שמאפשרת עמידות להפסקות חשמל באזורים.
בתרשים הבא מוצגת אותה ארכיטקטורה במספר אזורים כמו בתרשים הקודם, וההשפעות של הפסקה זמנית בשירות באזור יחיד על הזמינות של האפליקציה:
כפי שמוצג בדיאגרמה הקודמת, גם אם מתרחשת הפסקה זמנית בשירות בשני האזורים בכל אזור, האפליקציה ממשיכה להיות זמינה, כי מחסנית אפליקציות עצמאית נפרסת בכל אזור. מאזן העומסים החיצוני הגלובלי מסוג HTTP/S מעביר את בקשות המשתמשים לאפליקציה באזור שלא הושפע מההפסקה הזמנית בשירות. מופע Spanner במספר אזורים עמיד להפסקות חשמל באזור. אחרי ש-Google תפתור את ההפסקה, תצטרכו לוודא שהאפליקציה פועלת כצפוי באזור שבו הייתה ההפסקה.
מידע על אופן הפעולה של שכפול במספר אזורים ב-Spanner זמין במאמרים Regional and multi-region configurations ו- Demystifying Spanner multi-region configurations.
אם יש הפסקות חשמל בשני אזורים כלשהם בארכיטקטורה הזו, האפליקציה לא תהיה זמינה. מאזן העומסים החיצוני הגלובלי מסוג HTTP/S זמין, אבל הוא לא יכול להפיץ תנועה כי אין בק-אנד זמין. צריך לחכות ש-Google תפתור את הבעיות בהפסקות השירות. לאחר מכן, מוודאים שהאפליקציה פועלת כצפוי בכל האזורים שבהם היא נפרסה.
פריסות בכמה אזורים יכולות לעזור לכם להבטיח זמינות גבוהה של האפליקציות העסקיות הכי חשובות. כדי להבטיח את המשכיות העסקית במהלך אירועי כשל, בנוסף לפריסת האפליקציה בכמה אזורים, צריך לבצע כמה פעולות נוספות. לדוגמה, צריך לבצע תכנון קיבולת כדי לוודא שקיבולת מספקת שמורה בכל האזורים, או שהסיכונים שקשורים להתאמה אוטומטית לעומס במקרה חירום מקובלים. אתם צריכים גם להטמיע שיטות עבודה לתפעול לבדיקות DR, לניהול אירועים, לאימות סטטוס האפליקציה אחרי אירועים ולביצוע רטרוספקטיבות.
-
מידע נוסף על שיקולים ספציפיים לאזור זמין במאמר מיקום גיאוגרפי ואזורים. ↩