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.
- אירועי בדיקה של תוכנית התאוששות מאסון (DiRT) שנערכים מדי שנה בכל החברה, כדי לוודא ששירותי Google Cloud החברה והפעילות העסקית הפנימית שלה 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 מוגדרת. אבל אם מוגדרת מדיניות הניתוב single-cluster, הסכם רמת השירות (SLA) של זמן הפעולה התקינה המינימלי הוא 99.9%, ללא קשר למספר האשכולות ולפיזור שלהם.
בתרשימים שבקטע הזה מוצגים מקרים של Bigtable עם גדלים שונים של אשכולות, וההבדלים שנובעים מכך בהסכמי רמת השירות (SLA) של זמן הפעולה.
אשכול יחיד
התרשים הבא מציג מופע Bigtable עם אשכול יחיד, עם התחייבות לזמן פעולה תקינה מינימלי של 99.9%:
מספר אשכולות
בתרשים הבא מוצג מופע Bigtable עם כמה אשכולות בכמה אזורים באזור יחיד, עם ניתוב בין אשכולות (הסכם רמת שירות מינימלי לזמן פעולה תקינה: 99.99%):
מספר אשכולות
התרשים הבא מציג מופע Bigtable עם כמה אשכולות בשלושה אזורים, עם ניתוב בין אשכולות (הסכם רמת שירות מינימלית לזמן פעולה תקינה: 99.999%):
זמינות מצטברת של התשתית
בקטע הזה מוסבר איך לחשב את הזמינות הכוללת של מחסנית תשתית ב- Google Cloud. במאמר מוסבר על הגורמים שמשפיעים על הזמינות הכוללת ומוצגות דוגמאות לחישובים.
כדי להריץ את האפליקציות ב- Google Cloud, משתמשים במשאבי תשתית כמו מכונות וירטואליות ומסדי נתונים. משאבי התשתית האלה ביחד מהווים את הערימה של תשתית האפליקציה. בתרשים הבא מוצג לדוגמה מחסנית תשתית ב- Google Cloud והסכם רמת השירות (SLA) לזמינות של כל משאב במחסנית:
דוגמה לתשתית שכוללת את המשאבים הבאים Google Cloud:
- מאזן עומסים חיצוני אזורי של אפליקציות (ALB) מקבל בקשות ממשתמשים ומגיב להן.
- קבוצת מופעי מכונה מנוהלת (MIG) אזורית היא הבק-אנד של מאזן העומסים החיצוני האזורי של אפליקציות (ALB). ה-MIG מכיל שתי מכונות וירטואליות ב-Compute Engine באזורים שונים. כל מכונה וירטואלית מארחת מופע של שרת אינטרנט.
- מאזן עומסים פנימי מטפל בתקשורת בין שרת האינטרנט לבין מופעים של שרת האפליקציות.
- קבוצת MIG אזורית שנייה היא הבק-אנד של מאזן העומסים הפנימי. קבוצת ה-MIG הזו כוללת שתי מכונות וירטואליות של Compute Engine באזורים שונים. כל מכונה וירטואלית מארחת מופע של שרת אפליקציות.
- מופע Cloud SQL שהוגדר לזמינות גבוהה הוא מסד הנתונים של האפליקציה. מופע מסד הנתונים הראשי משוכפל באופן סינכרוני למופע מסד נתונים במצב המתנה.
הזמינות המצטברת שאפשר לצפות לה ממערך תשתית כמו בדוגמה הקודמת תלויה בגורמים הבאים:
Google Cloud הסכמי רמת שירות (SLA)
הסכמי ה-SLA של זמינות (Uptime) של השירותים שבהם אתם משתמשים במערך התשתית שלכם משפיעים על הזמינות המינימלית המצטברת שאתם יכולים לצפות לה מהמערך. Google Cloud
בטבלאות הבאות מוצגת השוואה של הסכמי רמת השירות (SLA) של זמן הפעולה התקינה של חלק מהשירותים:
| שירותי מחשוב | הסכם רמת שירות (SLA) לזמן פעולה תקינה חודשי | זמן ההשבתה המקסימלי המשוער בחודש של 30 ימים |
|---|---|---|
| מכונה וירטואלית ב-Compute Engine | 99.9% | 43.2 דקות |
| Pods ב-GKE Autopilot בכמה אזורים | 99.9% | 43.2 דקות |
| שירות Cloud Run | 99.95% | 21.6 דקות |
| שירותי מסדי נתונים | הסכם רמת שירות (SLA) לזמן פעולה תקינה חודשי | זמן ההשבתה המקסימלי המשוער בחודש של 30 ימים |
|---|---|---|
| מכונה של Cloud SQL ל-PostgreSQL (מהדורת Enterprise) | 99.95% | 21.6 דקות |
| מכונת AlloyDB ל-PostgreSQL | 99.99% | 4.3 דקות |
| מכונת Spanner במספר אזורים | 99.999% | 26 שניות |
הסכמי רמת השירות של שירותים אחרים של Google Cloud זמינים במאמר הסכמי רמת השירות שלGoogle Cloud .
כפי שאפשר לראות בטבלאות הקודמות, השירותים שבוחרים לכל שכבה במערך התשתית משפיעים ישירות על זמן הפעולה הכולל שאפשר לצפות לו ממערך התשתית. Google Cloud כדי להגדיל את הזמינות הצפויה של עומס עבודה שנפרס במשאב Google Cloud , אפשר להקצות מופעים מיותרים של המשאב, כמו שמתואר בקטע הבא.
יתירות משאבים
יתירות של משאבים פירושה הקצאה של שני מופעים זהים או יותר של משאב ופריסה של אותה עומס עבודה בכל המשאבים בקבוצה. לדוגמה, כדי לארח את שכבת האינטרנט של אפליקציה, אפשר להקצות קבוצת MIG שמכילה כמה מכונות וירטואליות זהות של Compute Engine.
אם מפזרים קבוצת משאבים באופן מיותר בכמה תחומים של כשלים – למשל, שני אזורים – זמינות המשאבים שאפשר לצפות לה מקבוצה כזו גבוהה יותר מהסכם רמת השירות (SLA) של זמן הפעולה של כל משאב בקבוצה. Google Cloud הזמינות הגבוהה יותר נובעת מהסיכוי הנמוך יותר שכל המשאבים בקבוצה ייכשלו בו-זמנית, לעומת הסיכוי שמשאבים ב<b>דומיין כשל</b> יחיד ייכשלו באופן מתואם.
לדוגמה, אם הסכם רמת השירות (SLA) לזמינות של משאב הוא 99.9%, ההסתברות שהמשאב ייכשל היא 0.001 (1 פחות הסכם רמת השירות). אם אתם מפזרים עומס עבודה על פני שני מופעים של המשאב הזה שמוקצים בתחומי כשל נפרדים, ההסתברות ששני המשאבים ייכשלו בו-זמנית היא 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 | Stack C |
|---|---|---|---|
| קצה קדמי | 99.9% | 99.9% | 99.9% |
| רמת האפליקציה | 99.9% | 99.9% | 99.9% |
| רמה בינונית | – | 99.9% | 99.9% |
| רמת נתונים | – | – | 99.9% |
| זמינות מצטברת של המקבץ | 99.8% | 99.7% | 99.6% |
| זמן ההשבתה המקסימלי המשוער של החבילה בחודש של 30 ימים | 86 דקות | 130 דקות | 173 דקות |
סיכום של שיקולי התכנון
כשמעצבים את האפליקציות, כדאי להתחשב בזמינות המצטברת שלGoogle Cloud מערך התשתית.
- הזמינות של כל Google Cloud משאב בסטאק התשתית משפיעה על הזמינות הכוללת של הסטאק. כשבוחרים Google Cloud שירותים לבניית מחסנית התשתית, חשוב לקחת בחשבון את מועד הזמינות לאיסוף של השירותים.
- כדי לשפר את הזמינות של הפונקציה (לדוגמה, מחשוב או מסד נתונים) שמסופקת על ידי משאב, אפשר להקצות מופעים מיותרים של המשאב. כשמתכננים ארכיטקטורה עם משאבים מיותרים, בנוסף ליתרונות הזמינות, צריך לקחת בחשבון גם את ההשפעות הפוטנציאליות על מורכבות התפעול, זמן האחזור והעלות.
- מספר הרמות במערך התשתית (כלומר, העומק של המערך) נמצא ביחס הפוך לזמינות הכוללת של המערך. כדאי לקחת בחשבון את הקשר הזה כשמעצבים או משנים את חבילת הטכנולוגיות.
דוגמאות נוספות לחישובים של זמינות מצטברת מופיעות בקטעים הבאים:
- חישוב לדוגמה: פריסה באזור יחיד
- חישוב לדוגמה: פריסה בכמה אזורים
- חישוב לדוגמה: פריסה במספר אזורים עם איזון עומסים אזורי
- חישוב לדוגמה: פריסה במספר אזורים עם איזון עומסים גלובלי
היקפי הדף העסקי
היקף המיקום של Google Cloud משאב קובע את המידה שבה כשל בתשתית יכול להשפיע על המשאב. לרוב המשאבים שמקצים ב- Google Cloud יש אחד מההיקפים הבאים של מיקום: תחום, אזור, מספר אזורים או גלובלי.
היקף המיקום של חלק מסוגי המשאבים קבוע, כלומר אי אפשר לבחור או לשנות את היקף המיקום. לדוגמה, רשתות של ענן וירטואלי פרטי (VPC) הן משאבים גלובליים, ומכונות וירטואליות (VM) של Compute Engine הן משאבים של תחום מוגדר. לגבי משאבים מסוימים, אפשר לבחור את היקף המיקום בזמן הקצאת המשאב. לדוגמה, כשיוצרים אשכול Google Kubernetes Engine (GKE), אפשר לבחור ליצור אשכול GKE אזורי או אזורי.
בקטעים הבאים מוסבר על היקפי מיקום בפירוט רב יותר.
משאבים של תחום מוגדר
משאבים של תחום מוגדר נפרסים בתחום אחד באזור מסוים ב- Google Cloud. דוגמאות למשאבים אזוריים: זו רשימה חלקית בלבד.
- מכונות וירטואליות של Compute Engine
- קבוצות של מופעי מכונה מנוהלים (MIG) אזוריים
- דיסקים לאחסון מתמיד של תחום
- אשכולות GKE עם אזור יחיד
- מכונות Filestore Basic ו-Zonal
- משימות Dataflow
- מכונות של Cloud SQL
- אשכולות Dataproc ב-Compute Engine
כשל באזור מסוים עלול להשפיע על המשאבים האזוריים שהוקצו באותו אזור. התחומים נועדו לצמצם את הסיכון לכשלים מתואמים עם תחומים אחרים באזור. בדרך כלל, כשל באזור אחד לא משפיע על המשאבים באזורים אחרים באותו אזור. בנוסף, תקלה באזור לא בהכרח גורמת לכל התשתית באזור הזה להיות לא זמינה. האזור רק מגדיר את הגבול הצפוי להשפעה של כשל.
כדי להגן על אפליקציות שמשתמשות במשאבים של תחום מוגדר מפני אירועים שקורים בתחום, אפשר לפרוס או לשכפל את המשאבים במספר תחומים או אזורים. מידע נוסף זמין במאמר בנושא תכנון תשתית מהימנה לעומסי העבודה ב- Google Cloud.
משאבים אזוריים
משאבים אזוריים נפרסים בצורה יתירה בכמה תחומים באזור מסוים. דוגמאות למשאבים אזוריים: זו רשימה חלקית בלבד.
- קבוצות אזוריות של מכונות וירטואליות מנוהלות (MIG)
- קטגוריות אזוריות של Cloud Storage
- דיסקים לאחסון מתמיד אזורי
- אשכולות GKE אזוריים עם הגדרת ברירת המחדל (מספר אזורים)
- רשתות משנה של VPC
- מאזני עומסים חיצוניים אזוריים של אפליקציות (ALB)
- מכונות Spanner אזוריות
- מכונות Filestore Enterprise
- שירותי Cloud Run
משאבים אזוריים עמידים לאירועים באזור ספציפי. הפסקות זמניות בשירות באזור יכולות להשפיע על חלק מהמשאבים האזוריים שהוקצו באותו אזור, או על כולם. הפסקות כאלה יכולות להיגרם מאסונות טבע או מכשלים בתשתית בקנה מידה גדול.
משאבים שמנוהלים במספר אזורים
משאבים שמנוהלים במספר אזורים מפוזרים באזורים ספציפיים. הנה כמה דוגמאות למשאבים שמנוהלים במספר אזורים. זו רשימה חלקית.
- קטגוריות של Cloud Storage בשני אזורים ובמספר אזורים
- מכונות Spanner במספר אזורים
- מכונות Bigtable מרובות אשכולות (מרובות אזורים)
- אוספי מפתחות מרובי-אזורים ב-Cloud Key Management Service
לרשימה מלאה של שירותי Google שזמינים בהגדרות של מספר אזורים, ראו מוצרים זמינים לפי מיקום.
משאבים שמנוהלים במספר אזורים עמידים בפני אירועים באזורים ובאזורי זמינות ספציפיים. הפסקת שירות בתשתית שמתרחשת בכמה אזורים יכולה להשפיע על הזמינות של חלק מהמשאבים או של כל המשאבים שפועלים בכמה אזורים ומוקצים באזורים המושפעים.
משאבים גלובליים
משאבים גלובליים זמינים בכל Google Cloud המיקומים. אלה דוגמאות למשאבים גלובליים. זו רשימה חלקית.
פרויקטים. במאמר בחירה של היררכיית משאבים לאזור הנחיתה ב- Google Cloud Google Cloud תוכלו לקרוא על שיטות מומלצות לארגון המשאבים בתיקיות ובפרויקטים.Google Cloud
רשתות VPC, כולל מסלולים וכללי חומת אש שמשויכים אליהן
תחומי Cloud DNS
מאזני עומסים גלובליים חיצוניים של אפליקציות (ALB)
אוספי מפתחות גלובליים ב-Cloud Key Management Service
נושאים ב-Pub/Sub
סודות ב-Secret Manager
כאן אפשר לראות רשימה מלאה של שירותי Google שזמינים ברחבי העולם.
משאבים גלובליים עמידים בפני אירועים אזוריים ואירועים בתחום מוגדר. המשאבים האלה לא מסתמכים על תשתית באזור ספציפי. Google Cloud יש ל-Google מערכות ותהליכים שעוזרים לצמצם את הסיכון להפסקות בשירותי התשתית הגלובלית. Google גם מנטרת את התשתית באופן רציף, ופותרת במהירות כל הפסקת שירות גלובלית.
בטבלה הבאה מופיע סיכום של רמת העמידות היחסית של משאבים אזוריים, משאבים של תחום מוגדר, משאבים במספר אזורים ומשאבים גלובליים, בפני בעיות באפליקציות ובאינפראסטרוקטורה. במאמר מוסבר גם על המאמץ שנדרש כדי להגדיר את המשאבים האלה, ומופיצות בו המלצות לצמצום ההשפעות של הפסקות שירות.
| היקף המשאבים | חוסן | המלצות לצמצום ההשפעות של הפסקות זמניות בתשתית |
|---|---|---|
| אזורי | נמוכה | פריסת המשאבים בצורה יתירה בכמה אזורים או בכמה תחומים. |
| אזורי | בינוני | פריסת המשאבים בצורה יתירה בכמה אזורים. |
| בכמה אזורים או גלובלי | גבוהה | חשוב לנהל את השינויים בזהירות ולהשתמש בחלופות הגנה מרובות שכבות (defense-in-depth) כשזה אפשרי. מידע נוסף זמין במאמר המלצות לניהול הסיכון של הפסקות זמניות במשאבים גלובליים. |
המלצות לניהול הסיכון של הפסקות בשירותים של משאבים גלובליים
כדי לנצל את העמידות של משאבים גלובליים להפסקות חשמל באזורים ובתחומים, כדאי לשקול להשתמש במשאבים גלובליים מסוימים בארכיטקטורה שלכם. Google ממליצה על הגישות הבאות לניהול הסיכון של הפסקות זמניות במשאבים גלובליים:
ניהול זהיר של שינויים במשאבים גלובליים
משאבים גלובליים עמידים לכשלים פיזיים. ההגדרה של משאבים כאלה היא בהיקף גלובלי. לכן, קל יותר להגדיר ולנהל משאב גלובלי יחיד מאשר להפעיל כמה משאבים אזוריים. עם זאת, שגיאה קריטית בהגדרת משאב גלובלי עלולה להפוך אותו לנקודת כשל יחידה (SPOF). לדוגמה, אפשר להשתמש במאזן עומסים גלובלי כחלק הקדמי של אפליקציה שמפוזרת גיאוגרפית. בדרך כלל, מאזן עומסים גלובלי הוא בחירה טובה לאפליקציה כזו. עם זאת, שגיאה בהגדרת מאזן העומסים עלולה לגרום לכך שהוא לא יהיה זמין בכל המיקומים הגיאוגרפיים. כדי למנוע את הסיכון הזה, צריך לנהל בזהירות את השינויים בהגדרות של משאבים גלובליים. מידע נוסף על שליטה בשינויים במשאבים גלובליים
שימוש במשאבים אזוריים כגיבויים להגנה לעומק
באפליקציות עם דרישות זמינות גבוהות במיוחד, שימוש בגיבויים להגנה מרובדת באזור יכול לעזור למזער את ההשפעה של הפסקות זמניות במשאבים גלובליים. נניח שיש לכם אפליקציה שמפוזרת גיאוגרפית וכוללת מאזן עומסים גלובלי כחלק הקדמי שלה. כדי לוודא שהאפליקציה תישאר נגישה גם אם מאזן העומסים הגלובלי מושפע מהפסקת שירות גלובלית, אפשר לפרוס מאזני עומסים אזוריים. אתם יכולים להגדיר את הלקוחות כך שיעדיפו את מאזן העומסים הגלובלי, אבל יעברו למאזן העומסים האזורי הקרוב ביותר אם מאזן העומסים הגלובלי לא זמין.
דוגמה לארכיטקטורה עם משאבים גלובליים, אזוריים ושל תחום מוגדר
טופולוגיית הענן יכולה לכלול שילוב של משאבים אזוריים, משאבים בתחומים ומשאבים גלובליים, כמו שמוצג בתרשים הבא. בתרשים הבא מוצגת ארכיטקטורה לדוגמה של אפליקציה מרובת-שכבות שפריסתה מתבצעת ב-Google Cloud.
כפי שמוצג בתרשים הקודם, מאזן עומסים חיצוני גלובלי מסוג HTTP/S מקבל בקשות מלקוחות. מאזן העומסים מחלק את הבקשות לעורף, שהוא קבוצת MIG אזורית עם שתי מכונות וירטואליות ב-Compute Engine. האפליקציה שפועלת במכונות הווירטואליות כותבת נתונים למסד נתונים של Cloud SQL וקוראת נתונים ממנו. מסד הנתונים מוגדר לזמינות גבוהה. המופעים הראשיים והמשניים של מסד הנתונים מוקצים באזורים נפרדים, ומסד הנתונים הראשי משוכפל באופן סינכרוני למסד הנתונים המשני. בנוסף, מסד הנתונים מגובה אוטומטית לקטגוריה עם מספר אזורים ב-Cloud Storage.
בטבלה הבאה מפורטים המשאבים בארכיטקטורה הקודמת, ומידת החוסן (resilience) של כל משאב להפסקות זמניות בשירות באזור ובאזור הזמינות: Google Cloud
| משאב | חוסן בפני הפסקות זמניות בשירות |
|---|---|
| רשת VPC | רשתות VPC, כולל מסלולים וכללי חומת אש שמשויכים אליהן, הם משאבים גלובליים. הם עמידים להפסקות זמניות בשירות באזור מסוים או בתחום מסוים. |
| תת-רשתות | תת-רשתות של VPC הן משאבים אזוריים. הם עמידים להפסקות זמניות בשירות באזור מסוים. |
| מאזן עומסים גלובלי חיצוני מסוג HTTP/S | מאזני עומסים גלובליים חיצוניים מסוג HTTP/S עמידים להפסקות חשמל באזורים ובאזורי זמינות. |
| קבוצת מופעים אזורית של MIG | קבוצות אזוריות של מכונות וירטואליות עמידות להפסקות זמניות בשירות באזור מסוים. |
| מכונות וירטואליות של Compute Engine | מכונות וירטואליות ב-Compute Engine הן משאבים אזוריים. אם מתרחש הפסקת חשמל באזור, יכול להיות שהמכונות הווירטואליות של Compute Engine יושפעו. עם זאת, האפליקציה יכולה להמשיך לטפל בבקשות כי הבק-אנד של מאזן העומסים הוא MIG אזורי, ולא מכונות וירטואליות עצמאיות. |
| מכונות של Cloud SQL | פריסת Cloud SQL בארכיטקטורה הזו מוגדרת לזמינות גבוהה (HA). כלומר, הפריסה כוללת זוג של מכונות מסד נתונים ראשיות ומשניות. מסד הנתונים הראשי משוכפל באופן סינכרוני למסד הנתונים במצב המתנה באמצעות אחסון מתמיד (persistent disk) אזורי.
|
| קטגוריה של Cloud Storage בכמה אזורים | נתונים שמאוחסנים בקטגוריות של Cloud Storage בכמה אזורים עמידים להפסקות חשמל באזור יחיד. |
| דיסקים לאחסון מתמיד | דיסקים לאחסון מתמיד יכולים להיות אזוריים או של תחום מוגדר. דיסקים לאחסון מתמיד אזוריים עמידים בפני הפסקות זמניות בשירות באזור מסוים. כדי להתכונן להתאוששות מהפסקות חשמל באזור, אפשר לתזמן תמונות מצב של דיסקים מתמידים ולאחסן את תמונות המצב בקטגוריה של Cloud Storage במספר אזורים. |