כפי שמתואר בזמינות הפלטפורמה,Google Cloud התשתית מיועדת לתמוך בזמינות יעד של 99.9% עבור עומס עבודה שנפרס באזור יחיד. זמינות היעד היא 99.99% עבור פריסה מרובת אזורים1 ו-99.999% עבור פריסה מרובת אזורים. בחלק הזה של Google Cloud מדריך האמינות של התשתית מופיעות הנחיות לפריסה, דוגמאות לארכיטקטורות וטכניקות עיצוב שיכולות לעזור לכם להגן על עומסי העבודה מפני כשלים ברמת המשאב, האזור והאזור.
הימנעות מנקודות כשל בודדות
אפליקציות מורכבות בדרך כלל מכמה רכיבים שתלויים זה בזה, וכל אחד מהם נועד לבצע פונקציה ספציפית. בדרך כלל, הרכיבים האלה מקובצים לרמות על סמך הפונקציה שהם מבצעים והקשר שלהם לרכיבים האחרים. לדוגמה, לאפליקציה שמציגה תוכן יכולים להיות שלושה רבדים: רובד אינטרנט שמכיל מאזן עומסים ושרתי אינטרנט, רובד אפליקציה עם אשכול של שרתי אפליקציות ורובד נתונים להתמדה. אם רכיב כלשהו במערך האפליקציות הזה מסתמך על משאב תשתית יחיד, כשל במשאב הזה יכול להשפיע על הזמינות של המערך כולו. לדוגמה, אם רמת האפליקציה פועלת במכונה וירטואלית אחת, ואם המכונה הווירטואלית קורסת, אז כל הערימה לא זמינה. רכיב כזה הוא נקודת כשל בודדת (SPOF).
יכול להיות שיש יותר מנקודת כשל יחידה אחת במערך של אפליקציה. נבחן את מחסנית האפליקציות הרב-שכבתית שמוצגת בתרשים הבא:
כפי שמוצג בתרשים הקודם, הארכיטקטורה לדוגמה הזו מכילה מאזן עומסים אחד, שני שרתי אינטרנט, שרת אפליקציות אחד ומסד נתונים אחד. מאזן העומסים, שרת האפליקציות ומסד הנתונים בדוגמה הזו הם נקודות כשל יחידות (SPOF). אם אחד מהרכיבים האלה ייכשל, בקשות המשתמשים לאפליקציה ייכשלו.
כדי להסיר את נקודות הכשל היחידות (SPOF) במערך האפליקציות, צריך לפזר את המשאבים בין מיקומים שונים ולפרוס משאבים מיותרים.
הפצה של משאבים ויצירת יתירות
בהתאם לדרישות האמינות של האפליקציה, אפשר לבחור מבין ארכיטקטורות הפריסה הבאות:
| ארכיטקטורה | המלצה לעומס עבודה |
|---|---|
| במספר אזורים | עומסי עבודה שהם קריטיים לעסק ושבהם זמינות גבוהה היא חיונית, כמו יישומי קמעונאות ומדיה חברתית. |
| רב-אזורי | עומסי עבודה שצריכים עמידות בפני הפסקות זמניות באזורים, אבל יכולים לסבול השבתה מסוימת שנגרמת כתוצאה מהפסקות זמניות באזורים. |
| תחום אחד | עומסי עבודה שיכולים לעמוד בהשבתה או שאפשר לפרוס אותם במיקום אחר כשצריך, במאמץ מינימלי. |
שיקולי עלות, חביון ותפעול
כשמתכננים ארכיטקטורה מבוזרת עם משאבים מיותרים, צריך לקחת בחשבון לא רק את דרישות הזמינות של האפליקציה, אלא גם את ההשפעות על מורכבות התפעול, על זמן האחזור ועל העלות.
בארכיטקטורה מבוזרת, אתם מקצים ומנהלים מספר גדול יותר של משאבים. נפח התנועה ברשת בין מיקומים גבוה יותר. אתם גם מאחסנים ומשכפלים יותר נתונים. כתוצאה מכך, העלות של משאבי הענן בארכיטקטורה מבוזרת גבוהה יותר, והפעלת פריסות כאלה מורכבת יותר. במקרה של אפליקציות קריטיות לעסק, היתרון של זמינות גבוהה יותר בארכיטקטורה מבוזרת עשוי להיות משמעותי יותר מהעלות הגבוהה וממורכבות התפעול.
באפליקציות שלא חיוניות לעסק, יכול להיות שהזמינות הגבוהה שארכיטקטורה מבוזרת מספקת לא חיונית. יש אפליקציות מסוימות שבהן יש דרישות אחרות שחשובות יותר מהזמינות. לדוגמה, אפליקציות של עיבוד באצווה דורשות חיבורי רשת עם זמן אחזור נמוך ורוחב פס גבוה בין מכונות ה-VM. ארכיטקטורה של אזור יחיד יכולה להתאים מאוד לאפליקציות כאלה, והיא גם יכולה לעזור לכם לצמצם את עלויות העברת הנתונים.
ארכיטקטורות פריסה
בקטע הזה מוצגות האפשרויות הבאות לארכיטקטורה לבניית תשתית לעומסי העבודה ב- Google Cloud:
- פריסה באזור יחיד
- פריסה בכמה אזורים
- פריסה במספר אזורים עם איזון עומסים אזורי
- פריסה במספר אזורים עם איזון עומסים גלובלי
פריסה באזור יחיד
התרשים הבא מציג ארכיטקטורת אפליקציה באזור יחיד עם יתירות בכל רמה, כדי להשיג זמינות גבוהה יותר של הפונקציות שמבוצעות על ידי כל רכיב:
כפי שמוצג בתרשים הקודם, הארכיטקטורה לדוגמה הזו כוללת את הרכיבים הבאים:
- מאזן עומסים חיצוני אזורי מסוג HTTP/S לקבלת בקשות משתמשים ולמענה עליהן.
- קבוצת מופעי מכונה מנוהלים (MIG) באזור מסוים בתור הקצה העורפי של מאזן העומסים מסוג HTTP/S. בקבוצה יש שתי מכונות וירטואליות ב-Compute Engine. כל מכונה וירטואלית מארחת מופע של שרת אינטרנט.
- מאזן עומסים פנימי לטיפול בתקשורת בין שרת האינטרנט לבין מופעי שרת האפליקציה.
- קבוצת מכונות מנוהלת (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 תפתור את הבעיה, ואז לוודא שהאפליקציה פועלת כמצופה.
בקטע הבא מתואר גישה ארכיטקטונית שבה אפשר להשתמש כדי להפיץ משאבים בכמה תחומים (zones), וכך לשפר את חוסן (resilience) האפליקציה להפסקות זמניות בשירות (outages) בתחומים (zones).
פריסה רב-אזורית
בפריסה של אזור יחיד, אם מתרחשת הפסקה זמנית באזור, יכול להיות שהאפליקציה לא תוכל לטפל בבקשות עד שהבעיה תיפתר. כדי לשפר את העמידות של האפליקציה מפני הפסקות זמניות באזור, אפשר להקצות כמה מופעים של משאבים אזוריים (כמו מכונות וירטואליות של Compute Engine) בשני אזורים או יותר. בשירותים שתומכים במשאבים בהיקף אזורי (כמו קטגוריות של Cloud Storage), אפשר לפרוס משאבים אזוריים.
בתרשים הבא מוצגת ארכיטקטורה עם זמינות גבוהה בין אזורים, שבה הרכיבים בכל שכבה של מחסנית האפליקציות מפוזרים בין שני אזורים:
כפי שמוצג בתרשים הקודם, הארכיטקטורה לדוגמה הזו כוללת את הרכיבים הבאים:
- מאזן עומסים חיצוני אזורי מסוג HTTP/S מקבל בקשות ממשתמשים ומגיב להן.
- קבוצת המכונות לניהול מופעים (MIG) האזורית היא הקצה העורפי של מאזן העומסים של HTTP/S. קבוצת המכונות לניהול מופעים מכילה שתי מכונות וירטואליות של 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 מבצע מעבר אוטומטי לגיבוי למופע של מסד הנתונים במצב המתנה.
בתרשים הבא מוצגת אותה ארכיטקטורה כמו בתרשים הקודם, וההשפעות של הפסקת חשמל באזור על הזמינות של האפליקציה:
כפי שמוצג בדיאגרמה הקודמת, אם מתרחשת הפסקה זמנית בשירות באחד מתחומי (zone) הזמינות, מאזן העומסים (LB) בארכיטקטורה הזו לא מושפע, כי הוא משאב אזורי. הפסקה זמנית בשירות באזור עלולה להשפיע על מכונות וירטואליות ספציפיות ב-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) משמש כקצה העורפי של מאזני העומסים הפנימיים. כל אחת מהקבוצות האלה מכילה שתי מכונות וירטואליות של 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 מוודאות שמכונות וירטואליות חדשות נוצרות באופן אוטומטי כדי לשמור על המספר המינימלי של מכונות וירטואליות שהוגדר.
הפסקה זמנית בשירות בתחום (zone) אחד לא משפיעה על מאזני העומסים (LB), כי הם משאבים אזוריים ועמידים להפסקות זמניות בשירות בתחומים (zone). יכול להיות שהפסקת חשמל באזור תשפיע על מכונות וירטואליות ספציפיות ב-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
אלה הסיכונים בארכיטקטורה שמשתמשת במאזן עומסים גלובלי:
- שינוי שגוי בהגדרות של מאזן העומסים הגלובלי עלול לגרום לכך שהאפליקציה לא תהיה זמינה למשתמשים. לדוגמה, אם במהלך עדכון הקצה הקדמי של מאזן עומסים גלובלי, אתם מוחקים בטעות כלל העברה, מאזן העומסים מפסיק לקבל בקשות ממשתמשים. ההשפעה של הסיכון הזה נמוכה יותר במקרה של ארכיטקטורה מרובת אזורים שמשתמשת במאזני עומסים אזוריים, כי גם אם מאזן העומסים האזורי באחד האזורים מושפע משגיאת הגדרה, מאזני העומסים באזורים האחרים ממשיכים לפעול.
- הפסקת חשמל בתשתית שמשפיעה על משאבים גלובליים עלולה לגרום לכך שמאזן העומסים הגלובלי לא יהיה זמין.
כדי לצמצם את הסיכונים האלה, צריך לנהל את השינויים במאזן העומסים הגלובלי בקפידה, ולשקול שימוש בגיבויים מרובים ככל האפשר. מידע נוסף זמין במאמר המלצות לניהול הסיכון להפסקות זמניות של משאבים גלובליים.
זמינות מצטברת: פריסה במספר אזורים עם איזון עומסים גלובלי
בפריסה במספר אזורים שמוצגת בתרשים הקודם, מכונות ה-VM ומאזני העומסים הפנימיים מפוזרים באופן יתירני בשני אזורים. מאזן העומסים החיצוני הוא משאב גלובלי, ומופע 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 תפתור את הפסקות השירות, ואז לוודא שהאפליקציה פועלת כמצופה בכל האזורים שבהם היא נפרסה.
פריסות במספר אזורים יכולות לעזור להבטיח זמינות גבוהה של האפליקציות העסקיות החשובות ביותר. כדי להבטיח המשכיות עסקית במהלך אירועי כשל, בנוסף לפריסת האפליקציה במספר אזורים, צריך לבצע כמה פעולות נוספות. לדוגמה, צריך לבצע תכנון קיבולת כדי לוודא שקיבולת מספקת שמורה בכל האזורים או שהסיכונים שקשורים להתאמה אוטומטית לעומס במקרה חירום מקובלים. בנוסף, צריך ליישם שיטות תפעול לבדיקת התאוששות מאסון, לניהול אירועים, לאימות סטטוס האפליקציה אחרי אירועים ולביצוע רטרוספקטיבה.
-
מידע נוסף על שיקולים ספציפיים לאזור זמין במאמר מיקום גיאוגרפי ואזורים. ↩