אבני הבניין של מהימנות ב-Google Cloud

Google Cloud שירותי התשתית פועלים במיקומים ברחבי העולם. המיקומים מחולקים לדומיינים של כשלים, שנקראים אזורים ותחומים (zones). אלה אבני הבניין הבסיסיות לתכנון תשתית אמינה לעומסי העבודה בענן.

דומיין כשל הוא משאב או קבוצת משאבים שיכולים להיכשל באופן עצמאי ממשאבים אחרים. דוגמה למשאב שהוא תחום כשל היא מכונה וירטואלית עצמאית של Compute Engine. Google Cloud אזור או תחום הם דוגמה לדומיין כשל שמורכב מקבוצת משאבים. כשמפיצים אפליקציה באופן מיותר בדומיינים של כשלים, אפשר להשיג רמת זמינות מצטברת גבוהה יותר מזו שמספק כל דומיין של כשלים.

בחלק הזה של Google Cloud מדריך האמינות של התשתית מוסבר על אבני הבניין של האמינות ב- Google Cloud ואיך הן משפיעות על הזמינות של משאבי הענן.

אזורים ותחומים

אזורים הם מיקומים גיאוגרפיים עצמאיים שמחולקים לתחומים (zones). האזורים והתחומים הם הפשטות לוגיות של המשאבים הפיזיים שעומדים בבסיס מרכזי הנתונים. מידע נוסף על שיקולים ספציפיים לאזור זמין במאמר מיקום גיאוגרפי ואזורים.

זמינות בפלטפורמות השונות

Google Cloud התשתית מתוכננת כך שתהיה עמידה בפני כשלים ותאפשר התאוששות מהם. ‫Google משקיעה באופן קבוע בגישות חדשניות כדי לשמור על האמינות של Google Cloudולשפר אותה. היכולות הבאות של תשתיתGoogle Cloud עוזרות לספק פלטפורמה אמינה לעומסי העבודה בענן:

• אזורים מופרדים גיאוגרפית כדי לצמצם את ההשפעות של אסונות טבע והפסקות זמניות בשירותים גלובליים.
• יתירות ושכפול של חומרה כדי להימנע מנקודות כשל בודדות.
• מיגרציה פעילה של משאבים במהלך אירועי תחזוקה. לדוגמה, במהלך תחזוקה מתוכננת של התשתית, אפשר להעביר מכונות וירטואליות של Compute Engine למארח אחר באותו אזור באמצעות מיגרציה פעילה.
• בסיס תשתיתי מאובטח משלב התכנון לתשתית הפיזית ולתוכנה שעליהן Google Cloud פועל, ואמצעי בקרה תפעוליים לאבטחה להגנה על הנתונים ועומסי העבודה. למידע נוסף, ראו סקירה כללית על תכנון האבטחה בתשתית של Google.
• רשת בשדרה מרכזית עם ביצועים גבוהים שמשתמשת בגישה מתקדמת של שירותי Networking מוגדרי-תוכנה (SDN) לניהול רשת, עם שירותי שמירה במטמון קצה כדי לספק ביצועים עקביים עם יכולת התאמה לעומס טובה.
• מעקב ודיווח רציפים. אפשר לראות את הסטטוס שלGoogle Cloud השירותים בכל מיקום באמצעות Google Cloud Service Health Dashboard.
• אירועי בדיקה שנתית של תוכנית התאוששות מאסון (DiRT) ברמת החברה, כדי לוודא ששירותי Google Cloud החברה והפעולות העסקיות הפנימיות ימשיכו לפעול בזמן אסון.
• גישה לניהול שינויים שמדגישה את האמינות בכל השלבים של מחזור החיים של פיתוח התוכנה, לכל שינוי בפלטפורמה ובשירותים של Google Cloud .

פלטפורמתGoogle Cloud נועדה לתמוך ברמות הזמינות הבאות עבור רוב עומסי העבודה של הלקוחות:

מיקום הפריסה	זמינות (זמן פעולה) %	זמן ההשבתה המקסימלי המשוער
תחום אחד	‫3 תשיעיות: 99.9%	‫43.2 דקות בחודש של 30 ימים
כמה אזורים באזור	‫4 תשיעיות: 99.99%	‫4.3 דקות בחודש של 30 ימים
מספר אזורים	‫5 תשיעיות: 99.999%	‫26 שניות בחודש של 30 ימים

אחוזי הזמינות בטבלה שלמעלה הם יעדים. זמן הפעולה הסכמי רמת השירות (SLA) לשירותים ספציפיים Google Cloud עשויים להיות שונים מיעדי הזמינות האלה. לדוגמה, הסכם רמת השירות (SLA) לזמינות של מופע Bigtable תלוי במספר האשכולות, בפיזור שלהם במיקומים שונים ובמדיניות הניתוב שהגדרתם.

הסכם רמת השירות (SLA) המינימלי לזמינות של מופע Bigtable עם אשכולות בשלושה אזורים או יותר הוא 99.999% אם מדיניות הניתוב multi-cluster מוגדרת. אבל אם מוגדרת מדיניות ניתוב של אשכול יחיד, הסכם רמת השירות (SLA) לגבי זמן הפעולה התקינה המינימלי הוא 99.9%, ללא קשר למספר האשכולות ולפיזור שלהם.

בתרשימים שבקטע הזה מוצגים מקרים של Bigtable עם גדלים שונים של אשכולות, וההבדלים שנובעים מכך בהסכמי רמת השירות (SLA) של זמן הפעולה הרציפה שלהם.

זמינות מצטברת של התשתית

בקטע הזה מוסבר איך לחשב את הזמינות המצטברת של מחסנית תשתית ב- Google Cloud. במאמר הזה מתוארים הגורמים שמשפיעים על הזמינות הכוללת, ומוצגות דוגמאות לחישובים.

כדי להריץ את האפליקציות ב- Google Cloud, צריך להשתמש במשאבי תשתית כמו מכונות וירטואליות ומסדי נתונים. משאבי התשתית האלה ביחד מהווים את הערימה של תשתית האפליקציה. בתרשים הבא מוצג לדוגמה מחסנית תשתית ב- Google Cloud והסכם רמת השירות לזמינות של כל משאב במחסנית:

דוגמה למערך משאבים של תשתית כוללת את המשאבים הבאים Google Cloud:

• מאזן עומסים חיצוני אזורי של אפליקציות (ALB) מקבל בקשות ממשתמשים ומגיב להן.
• קבוצת מופעי מכונה מנוהלים (MIG) אזורית היא הבק-אנד של מאזן העומסים החיצוני האזורי של אפליקציות (ALB). ה-MIG מכיל שתי מכונות וירטואליות ב-Compute Engine באזורים שונים. כל מכונה וירטואלית מארחת מופע של שרת אינטרנט.
• מאזן עומסים פנימי מטפל בתקשורת בין שרתי האינטרנט לבין שרתי האפליקציות.
• קבוצת MIG אזורית שנייה היא הבק-אנד של מאזן העומסים הפנימי. לקבוצת ה-MIG הזו יש שתי מכונות וירטואליות ב-Compute Engine באזורים שונים. כל מכונה וירטואלית מארחת מופע של שרת אפליקציות.
• מכונת Cloud SQL שהוגדרה לזמינות גבוהה היא מסד הנתונים של האפליקציה. מופע מסד הנתונים הראשי משוכפל באופן סינכרוני למופע מסד נתונים במצב המתנה.

הזמינות המצטברת שאפשר לצפות לה ממערך תשתית כמו בדוגמה הקודמת תלויה בגורמים הבאים:

• Google Cloud הסכמי רמת שירות (SLA)
• יתירות של משאבים
• Stack depth

Google Cloud הסכמי רמת שירות (SLA)

הסכמי ה-SLA של זמינות (uptime) של Google Cloud השירותים שבהם אתם משתמשים במערך התשתית שלכם משפיעים על הזמינות המינימלית המצטברת שאתם יכולים לצפות לה מהמערך.

בטבלאות הבאות מוצגת השוואה של הסכמי רמת השירות (SLA) לגבי זמן פעולה תקינה של חלק מהשירותים:

שירותי מחשוב	הסכם רמת שירות לזמן פעולה תקינה חודשי	זמן ההשבתה המקסימלי המשוער בחודש של 30 ימים
מכונה וירטואלית ב-Compute Engine	99.9%	‫43.2 דקות
‫Pods של Google Kubernetes Engine‏ (GKE) במצב Autopilot במספר אזורים	99.9%	‫43.2 דקות
שירות Cloud Run	99.95%	‫21.6 דקות

שירותים של מסדי נתונים	הסכם רמת שירות לזמן פעולה תקינה חודשי	זמן ההשבתה המקסימלי המשוער בחודש של 30 ימים
מכונת Cloud SQL ל-PostgreSQL (מהדור Enterprise, עם הגדרת זמינות גבוהה)	99.95%	‫21.6 דקות
מכונת AlloyDB ל-PostgreSQL (הגדרת HA)	99.99%	‫4.3 דקות
מכונת Spanner במספר אזורים	99.999%	‫26 שניות

למידע על הסכמי רמת השירות של שירותים אחרים של Google Cloud , אפשר לעיין במאמר Google Cloud הסכמי רמת שירות.

כפי שאפשר לראות בטבלאות שלמעלה, Google Cloud השירותים שבוחרים לכל רמה של מחסנית התשתית משפיעים ישירות על זמן הפעולה הכולל שאפשר לצפות לו ממחסנית התשתית. כדי להגדיל את הזמינות הצפויה של עומס עבודה שנפרס במשאב Google Cloud , אפשר להקצות מופעים מיותרים של המשאב, כמו שמתואר בקטע הבא.

יתירות של משאבים

יתירות של משאבים פירושה הקצאה של שני מופעים זהים או יותר של משאב ופריסה של אותה עומס עבודה בכל המשאבים בקבוצה. לדוגמה, כדי לארח את שכבת האינטרנט של אפליקציה, אפשר להקצות קבוצת מופעים מנוהלת (MIG) שמכילה כמה מכונות וירטואליות זהות של Compute Engine.

אם מפזרים קבוצת משאבים באופן מיותר בכמה דומיינים של כשלים – למשל, שני Google Cloud אזורים – זמינות המשאבים שאפשר לצפות לה מהקבוצה הזו גבוהה יותר מהסכם רמת השירות (SLA) של זמן הפעולה של כל משאב בקבוצה. הזמינות הגבוהה יותר נובעת מכך שההסתברות שכל המשאבים בקבוצה ייכשלו בו-זמנית נמוכה יותר מההסתברות שמשאבים ב<b>דומיין כשל</b> יחיד ייכשלו באופן מתואם.

לדוגמה, אם הסכם רמת השירות (SLA) לזמינות של משאב הוא 99.9%, ההסתברות שהמשאב ייכשל היא 0.001 (1 פחות SLA). אם אתם מפזרים עומס עבודה בין שני מופעים של המשאב הזה שמוקצים בתחומי כשל נפרדים, ההסתברות ששני המשאבים ייכשלו בו-זמנית היא 0.000001 (כלומר, 0.001 x 0.001). ההסתברות לכשל מתורגמת לזמינות תיאורטית של 99.9999% לקבוצה של שני משאבים. עם זאת, הזמינות בפועל שאתם יכולים לצפות לה מוגבלת לזמינות היעד של מיקום הפריסה: 99.9% אם המשאבים נמצאים באזורGoogle Cloud אחד, 99.99% אם הפריסה היא במספר אזורים ו-99.999% אם המשאבים העודפים מפוזרים על פני מספר אזורים.

עומק המחסנית

העומק של מחסנית תשתית הוא מספר הרמות (או השכבות) השונות במחסנית. כל רמה במערך התשתית מכילה משאבים שמספקים פונקציה נפרדת לאפליקציה. לדוגמה, השכבה האמצעית במערך של שלוש שכבות יכולה להשתמש במכונות וירטואליות של Compute Engine או באשכול GKE כדי לארח שרתי אפליקציות. בדרך כלל יש תלות הדוקה בין כל שכבה במערך התשתית לבין השכבות הסמוכות לה. כלומר, אם רמה כלשהי בערימה לא זמינה, כל הערימה לא זמינה.

כדי לחשב את הזמינות המצטברת הצפויה של ערימת תשתית עם N רמות, משתמשים בנוסחה הבאה:

לדוגמה, אם כל רמה במערך של שלוש רמות מתוכננת לספק זמינות של 99.9%, הזמינות הכוללת של המערך היא בערך 99.7% (0.999 x 0.999 x 0.999). כלומר, הזמינות הכוללת של מחסנית רב-שכבתית נמוכה מהזמינות של השכבה שמספקת את הזמינות הנמוכה ביותר.

ככל שמספר הרמות התלויות זו בזו בסט גדל, הזמינות הכוללת של הסט קטנה, כפי שמוצג בטבלה הבאה. לכל ערימה לדוגמה בטבלה יש מספר שונה של רמות, וכל רמה מספקת זמינות של 99.9%.

רמה	Stack A	Stack B	חבילה ג'
קצה קדמי	99.9%	99.9%	99.9%
רמת האפליקציה	99.9%	99.9%	99.9%
רמה אמצעית	–	99.9%	99.9%
רמת נתונים	–	–	99.9%
זמינות מצטברת של המקבץ	99.8%	99.7%	99.6%
זמן ההשבתה המקסימלי המשוער של ה-stack בחודש של 30 ימים	‫86 דקות	‫130 דקות	‫173 דקות

סיכום של שיקולים בתכנון

כשמעצבים את האפליקציות, כדאי לקחת בחשבון את הזמינות המצטברת שלGoogle Cloud ערימת התשתית.

• הזמינות של כל Google Cloud משאב בסטאק התשתיתי משפיעה על הזמינות הכוללת של הסטאק. כשבוחרים Google Cloud שירותים לבניית מחסנית התשתית, חשוב לקחת בחשבון את הסכם רמת השירות (SLA) של הזמינות של השירותים.
• כדי לשפר את הזמינות של הפונקציה (לדוגמה, מחשוב או מסד נתונים) שמסופקת על ידי משאב, אפשר להקצות מופעים מיותרים של המשאב. כשמתכננים ארכיטקטורה עם משאבים מיותרים, בנוסף ליתרונות הזמינות, צריך גם לקחת בחשבון את ההשפעות הפוטנציאליות על מורכבות התפעול, זמן האחזור והעלות.
• מספר הרמות במערך התשתית (כלומר, העומק של המערך) נמצא ביחס הפוך לזמינות הכוללת של המערך. כדאי לקחת את הקשר הזה בחשבון כשמעצבים או משנים את ה-stack.

דוגמאות נוספות לחישובים של זמינות מצטברת מופיעות בקטעים הבאים:

• חישוב לדוגמה: פריסה באזור יחיד
• חישוב לדוגמה: פריסה בכמה אזורים
• חישוב לדוגמה: פריסה במספר אזורים עם איזון עומסים אזורי
• חישוב לדוגמה: פריסה במספר אזורים עם איזון עומסים גלובלי

היקפי הדף העסקי

היקף המיקום של משאב Google Cloud קובע את המידה שבה כשל בתשתית יכול להשפיע על המשאב. לרוב המשאבים שמקצים ב- Google Cloud יש אחד מההיקפים הבאים של מיקום: תחום, אזור, מספר אזורים או גלובלי.

היקף המיקום של חלק מסוגי המשאבים קבוע, כלומר אי אפשר לבחור או לשנות את היקף המיקום. לדוגמה, רשתות של ענן וירטואלי פרטי (VPC) הן משאבים גלובליים, ומכונות וירטואליות (VM) של Compute Engine הן משאבים של תחום מוגדר. לגבי משאבים מסוימים, אפשר לבחור את היקף המיקום בזמן הקצאת המשאב. לדוגמה, כשיוצרים אשכול GKE, אפשר לבחור ליצור אשכול GKE אזורי או אזורי.

בקטעים הבאים מוסבר בהרחבה על היקפי מיקום.

משאבים של תחום מוגדר

משאבים של תחום מוגדר נפרסים בתחום אחד באזור מסוים ב- Google Cloud. אלה דוגמאות למשאבים אזוריים. זו רשימה חלקית בלבד.

• מכונות וירטואליות של Compute Engine
• קבוצות MIG אזוריות
• Google Cloud Hyperdisk volumes
• אשכולות GKE עם אזור יחיד
• מכונות Filestore Basic ו-Zonal
• משימות Dataflow
• מכונות של Cloud SQL
• שירות מנוהל לאשכולות Apache Spark ב-Compute Engine

כשל בתחום מסוים עלול להשפיע על המשאבים של התחום שהוקצו בתוך אותו תחום. התחומים נועדו לצמצם את הסיכון לכשלים מתואמים עם תחומים אחרים באזור. בדרך כלל, כשל באזור אחד לא משפיע על המשאבים באזורים אחרים באותו אזור. בנוסף, תקלה באזור לא בהכרח גורמת לכל התשתית באזור הזה להיות לא זמינה. האזור רק מגדיר את הגבול הצפוי להשפעה של כשל.

כדי להגן על אפליקציות שמשתמשות במשאבים של תחום מוגדר מפני אירועים שקורים בתחום, אפשר לפרוס או לשכפל את המשאבים בכמה תחומים או אזורים. מידע נוסף זמין במאמר תכנון תשתית מהימנה לעומסי העבודה ב- Google Cloud.

משאבים אזוריים

משאבים אזוריים נפרסים בצורה יתירה במספר תחומים באזור מסוים. דוגמאות למשאבים אזוריים: זו רשימה חלקית בלבד.

• קבוצות אזוריות של מכונות וירטואליות בניהול (MIG)
• קטגוריות אזוריות של Cloud Storage
• נפחי אחסון של Hyperdisk Balanced High Availability
• אשכולות GKE אזוריים עם הגדרת ברירת המחדל (multi-zone)
• רשתות משנה של VPC
• מאזני עומסים חיצוניים אזוריים של אפליקציות (ALB)
• מכונות Spanner אזוריות
• מכונות Filestore Enterprise
• שירותי Cloud Run

משאבים אזוריים עמידים בפני אירועים באזור ספציפי. הפסקות זמניות בשירות באזור יכולות להשפיע על חלק מהמשאבים האזוריים שהוקצו באותו אזור, או על כולם. הפסקות כאלה יכולות להיגרם מאסונות טבע או מכשלים בתשתיות בקנה מידה גדול.

משאבים שמנוהלים במספר אזורים

משאבים שמנוהלים במספר אזורים מפוזרים באזורים ספציפיים. הנה כמה דוגמאות למשאבים שמנוהלים במספר אזורים. זו רשימה חלקית.

• קטגוריות של Cloud Storage בשני אזורים ובמספר אזורים
• מכונות Spanner במספר אזורים
• מכונות Bigtable מרובות אשכולות (מרובות אזורים)
• אוספי מפתחות מרובי-אזורים ב-Cloud Key Management Service

כאן אפשר לראות רשימה מלאה של שירותי Google שזמינים בהגדרות של כמה אזורים.

משאבים שמנוהלים במספר אזורים עמידים בפני אירועים באזורים ובאזורי זמינות ספציפיים. הפסקת שירות בתשתית שמתרחשת בכמה אזורים יכולה להשפיע על הזמינות של חלק מהמשאבים או של כל המשאבים בכמה אזורים שהוקצו באזורים המושפעים.

משאבים גלובליים

משאבים גלובליים זמינים בכל Google Cloud המיקומים. אלה דוגמאות למשאבים גלובליים. זו רשימה חלקית.

• פרויקטים. במאמר בחירה של היררכיית משאבים ל Google Cloud אזור הנחיתה מפורטות שיטות מומלצות לארגון המשאביםGoogle Cloud בתיקיות ובפרויקטים.

• רשתות VPC, כולל מסלולים וכללי חומת אש משויכים

• תחומי Cloud DNS

• מאזני עומסים גלובליים חיצוניים של אפליקציות (ALB)

• אוספי מפתחות גלובליים ב-Cloud Key Management Service

• נושאים ב-Pub/Sub

• סודות ב-Secret Manager

רשימה מלאה של שירותי Google שזמינים ברחבי העולם מופיעה במאמר בנושא מוצרים גלובליים.

משאבים גלובליים עמידים בפני אירועים אזוריים ואירועים בתחום מוגדר. המשאבים האלה לא מסתמכים על תשתית באזור ספציפי. Google Cloud יש ל-Google מערכות ותהליכים שעוזרים לצמצם את הסיכון להפסקות בשירותי התשתית הגלובלית. ‫Google גם מנטרת באופן רציף את התשתית, ופותרת במהירות כל הפסקת שירות גלובלית.

בטבלה הבאה מופיע סיכום של החוסן היחסי של משאבים אזוריים, משאבים של תחום מוגדר, משאבים במספר אזורים ומשאבים גלובליים, בהתמודדות עם בעיות באפליקציות ובאינפראסטרוקטורה. בנוסף, במאמר מוסבר כמה מאמץ נדרש כדי להגדיר את המשאבים האלה, ומופיצות המלצות לצמצום ההשפעות של הפסקות שירות.

היקף המשאבים	חוסן	המלצות לצמצום ההשפעות של הפסקות זמניות בתשתית
אזורי	נמוכה	פריסת המשאבים בצורה יתירה בכמה אזורים או בכמה תחומים.
אזורי	בינוני	פריסת המשאבים בצורה מיותרת בכמה אזורים.
בכמה אזורים או גלובלי	גבוהה	חשוב לנהל את השינויים בזהירות ולהשתמש בחלופות גיבוי מרובות שכבות כשזה אפשרי. מידע נוסף זמין במאמר בנושא המלצות לניהול הסיכון של הפסקות בשירותים של משאבים גלובליים.

המלצות לניהול הסיכון של הפסקות זמניות במשאבים גלובליים

כדי לנצל את העמידות של משאבים גלובליים להפסקות חשמל באזורים ובתחומים, כדאי לשקול להשתמש במשאבים גלובליים מסוימים בארכיטקטורה שלכם. ‫Google ממליצה על הגישות הבאות לניהול הסיכון של הפסקות זמניות בשירותים של משאבים גלובליים:

ניהול זהיר של שינויים במשאבים גלובליים

משאבים גלובליים עמידים בפני כשלים פיזיים. ההגדרה של משאבים כאלה היא בהיקף גלובלי. לכן, קל יותר להגדיר ולנהל משאב גלובלי אחד מאשר להפעיל כמה משאבים אזוריים. עם זאת, שגיאה קריטית בהגדרה של משאב גלובלי עלולה להפוך אותו לנקודת כשל יחידה (SPOF). לדוגמה, אפשר להשתמש במאזן עומסים גלובלי כחלק הקדמי של אפליקציה שמפוזרת גיאוגרפית. בדרך כלל כדאי להשתמש במאזן עומסים גלובלי לאפליקציה כזו. עם זאת, שגיאה בהגדרת מאזן העומסים עלולה לגרום לכך שהוא לא יהיה זמין בכל המיקומים הגיאוגרפיים. כדי להימנע מהסיכון הזה, צריך לנהל בזהירות את שינויי ההגדרות במשאבים גלובליים. מידע נוסף על שליטה בשינויים במשאבים גלובליים

שימוש במשאבים אזוריים כגיבויים להגנה לעומק

באפליקציות עם דרישות זמינות גבוהות במיוחד, שימוש בגיבויים להגנה מקיפה באזורים יכול לעזור למזער את ההשפעה של הפסקות בשירותים גלובליים. לדוגמה, נניח שיש אפליקציה שמפוזרת גיאוגרפית וכוללת מאזן עומסים גלובלי כחלק הקדמי שלה. כדי לוודא שהאפליקציה תישאר נגישה גם אם מאזן העומסים הגלובלי מושפע מהפסקת שירות גלובלית, אפשר לפרוס מאזני עומסים אזוריים. אתם יכולים להגדיר את הלקוחות כך שהם יעדיפו את מאזן העומסים הגלובלי, אבל יעברו אוטומטית למאזן העומסים האזורי הקרוב ביותר אם מאזן העומסים הגלובלי לא זמין.

כדי להגן על עצמכם מפני הפסקות בשירות של מאזן עומסים גלובלי ושגיאות בהגדרות, אתם יכולים להטמיע אסטרטגיה של מעבר אוטומטי לגיבוי או של עקיפה באמצעות Cloud DNS ומאזני עומסים אזוריים לגיבוי. מידע נוסף זמין במאמר בנושא אסטרטגיות למעבר לגיבוי במאזני עומסים חיצוניים גלובליים של אפליקציות.

דוגמה לארכיטקטורה עם משאבים של תחום מוגדר, אזוריים וגלובליים

טופולוגיית הענן יכולה לכלול שילוב של משאבים אזוריים, גלובליים ואזוריים, כמו שמוצג בתרשים הבא. התרשים הבא מציג ארכיטקטורה לדוגמה של אפליקציה מרובת-שכבות שפרוסה ב-Google Cloud.

כפי שמוצג בתרשים הקודם, מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) מקבל בקשות מלקוחות. מאזן העומסים מחלק את הבקשות לעורף, שהוא קבוצת מופעים אזורית לניהול מכונות (MIG) עם שתי מכונות וירטואליות ב-Compute Engine. האפליקציה שפועלת במכונות הווירטואליות כותבת נתונים למסד נתונים של Cloud SQL וקוראת נתונים ממנו. מסד הנתונים מוגדר לזמינות גבוהה. המופעים הראשיים והמשניים של מסד הנתונים מוקצים באזורים נפרדים, ומסד הנתונים הראשי משוכפל באופן סינכרוני למסד הנתונים המשני. בנוסף, מסד הנתונים מגובה אוטומטית לקטגוריה עם מספר אזורים ב-Cloud Storage.

בטבלה הבאה מפורטים Google Cloud המשאבים בארכיטקטורה הקודמת ומידת החוסן (resilience) של כל משאב להפסקות באזור ובאזור הזמינות:

משאב	חוסן (resilience) בפני הפסקות שירות
רשת VPC	רשתות VPC, כולל מסלולים וכללי חומת אש משויכים, הם משאבים גלובליים. הם עמידים להפסקות זמניות בשירות באזור מסוים או בתחום מסוים.
תת-רשתות	תת-רשתות של VPC הן משאבים אזוריים. הם עמידים להפסקות זמניות בשירות באזור מסוים.
מאזן עומסים גלובלי חיצוני של אפליקציות (ALB)	מאזני עומסים גלובליים חיצוניים של אפליקציות (ALB) עמידים להפסקות חשמל באזורים ובאזורי זמינות.
Regional MIG	קבוצות אזוריות של מכונות וירטואליות עמידות להפסקות זמניות בשירות באזור מסוים.
מכונות וירטואליות של Compute Engine	מכונות וירטואליות ב-Compute Engine הן משאבים של תחום מוגדר. אם מתרחש הפסקת חשמל באזור, יכול להיות שהמכונות הווירטואליות של Compute Engine יושפעו. עם זאת, האפליקציה יכולה להמשיך לטפל בבקשות כי הבק-אנד של מאזן העומסים הוא MIG אזורי, ולא מכונות וירטואליות עצמאיות.
מכונות של Cloud SQL	פריסת Cloud SQL בארכיטקטורה הזו מוגדרת לזמינות גבוהה. כלומר, הפריסה כוללת זוג של מכונות מסד נתונים ראשיות ומשניות. מסד הנתונים הראשי משוכפל באופן סינכרוני למסד הנתונים המשני באמצעות נפחי Hyperdisk Balanced High Availability. אם מתרחשת הפסקת חשמל באזור שבו מתארח מסד הנתונים הראשי, שירות Cloud SQL מבצע מעבר אוטומטי למסד הנתונים במצב המתנה. אם מתרחש הפסקת חשמל באזור מסוים, אפשר לשחזר את מסד הנתונים באזור אחר באמצעות הגיבויים של מסד הנתונים.
קטגוריה של Cloud Storage בכמה אזורים	נתונים שמאוחסנים בקטגוריות של Cloud Storage בכמה אזורים עמידים להפסקות חשמל באזור יחיד.
נפחי אחסון מסוג Hyperdisk	נפחי Hyperdisk הם משאבים של תחום מוגדר. לזמינות גבוהה, אפשר להשתמש בנפחי אחסון של Hyperdisk Balanced High Availability. הנתונים משוכפלים באופן סינכרוני בין שני אזורים באותו אזור.כדי להתכונן לשחזור במקרה של הפסקות חשמל באזור, אפשר לתזמן יצירת תמונות מצב של נפחי Hyperdisk ולאחסן את תמונות המצב בקטגוריה של Cloud Storage במספר אזורים.