Google Cloud שירותי התשתית פועלים במיקומים ברחבי העולם. המיקומים מחולקים לדומיינים של כשל שנקראים אזורים ותחומים (zones). אלה אבני הבניין הבסיסיות לתכנון תשתית אמינה לעומסי העבודה בענן.
תחום כשל הוא משאב או קבוצת משאבים שיכולים להיכשל באופן עצמאי ממשאבים אחרים. מכונה וירטואלית עצמאית של Compute Engine היא דוגמה למשאב שהוא תחום כשל. Google Cloud אזור או תחום הם דוגמה לתחום כשל שמורכב מקבוצת משאבים. כשמפזרים את האפליקציה באופן יתירני על פני תחומים שונים של כשל, אפשר להשיג רמת זמינות מצטברת גבוהה יותר מזו שמספק כל תחום כשל.
בחלק הזה של Google Cloud מדריך האמינות של התשתית מוסבר על אבני הבניין של האמינות ב- Google Cloud ואיך הן משפיעות על הזמינות של משאבי הענן.
אזורים ותחומים
אזורים הם מיקומים גיאוגרפיים עצמאיים שמחולקים לתחומים (zones). האזורים והתחומים הם הפשטות לוגיות של המשאבים הפיזיים שעומדים בבסיס מרכזי הנתונים. מידע נוסף על שיקולים ספציפיים לאזור זמין במאמר מיקום גיאוגרפי ואזורים.
זמינות הפלטפורמה
Google Cloud התשתית מתוכננת כך שתהיה עמידה בפני כשלים ותאפשר התאוששות מהם. Google משקיעה ללא הרף בגישות חדשניות כדי לשמור על האמינות של Google Cloudולשפר אותה. היכולות הבאות של תשתיתGoogle Cloud עוזרות לספק פלטפורמה אמינה לעומסי העבודה בענן:
- אזורים מופרדים גיאוגרפית כדי לצמצם את ההשפעות של אסונות טבע והפסקות זמניות בשירותים גלובליים.
- יתירות ושכפול של חומרה כדי להימנע מנקודות כשל בודדות.
- מיגרציה פעילה של משאבים במהלך אירועי תחזוקה. לדוגמה, במהלך תחזוקה מתוכננת של התשתית, אפשר להעביר מכונות וירטואליות של Compute Engine למארח אחר באותו אזור באמצעות מיגרציה פעילה.
- בסיס תשתיתי מאובטח משלב התכנון לתשתית הפיזית ולתוכנה שעליהן Google Cloud פועל, ואמצעי בקרה תפעוליים לאבטחת נתונים ועומסי עבודה. מידע נוסף זמין במאמר סקירה כללית על תכנון האבטחה בתשתית של Google.
- רשת Backbone עם ביצועים גבוהים שמתבססת על גישה מתקדמת של שירותי Networking מוגדרי-תוכנה (SDN) לניהול רשת, עם שירותי שמירת נתונים במטמון בקצה הרשת כדי לספק ביצועים עקביים עם יכולת התרחבות טובה.
- מעקב ודיווח רציפים. אפשר לראות את הסטטוס שלGoogle Cloud השירותים בכל מיקום באמצעות Google Cloud לוח הבקרה של Service Health.
- אירועי בדיקה שנתית של התאוששות מאסון (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. אבל אם מוגדרת מדיניות הניתוב single-cluster, התחייבות לזמינות מינימלית היא 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 באזורים שונים. כל מכונה וירטואלית מארחת מופע של שרת אינטרנט.
- מאזן עומסים פנימי מטפל בתקשורת בין שרת האינטרנט לבין מופעים של שרת האפליקציות.
- קבוצת מופעים מנוהלת אזורית שנייה היא קצה העורפי של מאזן העומסים הפנימי. בקבוצת המופעים המנוהלת הזו יש שתי מכונות וירטואליות של 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 הזמינות הגבוהה יותר נובעת מהסיכוי הנמוך יותר שכל המשאבים בקבוצה ייכשלו בו-זמנית, לעומת הסיכוי שמשאבים בדומיין כשל יחיד ייכשלו באופן מתואם.
לדוגמה, אם הסכם רמת השירות (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-tier באמצעות הנוסחה הבאה:
לדוגמה, אם כל רמה במערך של שלוש רמות מתוכננת לספק זמינות של 99.9%, הזמינות הכוללת של המערך היא בערך 99.7% (0.999 x 0.999 x 0.999). כלומר, הזמינות הכוללת של מחסנית רב-שכבתית נמוכה מהזמינות של השכבה שמספקת את הזמינות הנמוכה ביותר.
ככל שמספר הרמות התלויות זו בזו בסטאק גדל, הזמינות הכוללת של הסטאק יורדת, כפי שמוצג בטבלה הבאה. לכל סטאק לדוגמה בטבלה יש מספר שונה של רמות, וההנחה היא שכל רמה מספקת זמינות של 99.9%.
| רמה | מקבץ א' | 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 שירותים לבניית מחסנית התשתית, חשוב לקחת בחשבון את הסכם רמת השירות (SLA) של השירותים.
- כדי לשפר את הזמינות של הפונקציה (לדוגמה, מחשוב או מסד נתונים) שמסופקת על ידי משאב, אפשר להקצות מופעים מיותרים של המשאב. כשמתכננים ארכיטקטורה עם משאבים מיותרים, בנוסף ליתרונות הזמינות, צריך לקחת בחשבון גם את ההשפעות הפוטנציאליות על מורכבות התפעול, זמן האחזור והעלות.
- מספר השכבות במערך התשתית (כלומר, העומק של המערך) נמצא ביחס הפוך לזמינות המצטברת של המערך. כדאי לקחת את היחס הזה בחשבון כשמתכננים או משנים את המערך.
דוגמאות נוספות לחישובים של זמינות מצטברת מופיעות בקטעים הבאים:
- חישוב לדוגמה: פריסה באזור יחיד
- חישוב לדוגמה: פריסה בכמה אזורים
- חישוב לדוגמה: פריסה במספר אזורים עם איזון עומסים אזורי
- חישוב לדוגמה: פריסה במספר אזורים עם איזון עומסים גלובלי
היקפי המיקום
היקף המיקום של Google Cloud משאב קובע את המידה שבה כשל בתשתית יכול להשפיע על המשאב. לרוב המשאבים שמקצים ב- Google Cloud יש אחד מהיקפי המיקום הבאים: אזורי, אזורי, במספר אזורים או גלובלי.
היקף המיקום של חלק מסוגי המשאבים קבוע, כלומר אי אפשר לבחור או לשנות את היקף המיקום. לדוגמה, רשתות של ענן וירטואלי פרטי (VPC) הן משאבים גלובליים, ומכונות וירטואליות (VM) של Compute Engine הן משאבים של תחום מוגדר. לגבי משאבים מסוימים, אפשר לבחור את היקף המיקום בזמן הקצאת המשאב. לדוגמה, כשיוצרים אשכול Google Kubernetes Engine (GKE), אפשר לבחור ליצור אשכול GKE אזורי או אזורי.
בקטעים הבאים מוסבר על היקפי מיקום בפירוט רב יותר.
משאבים של תחום מוגדר
משאבים של תחום מוגדר נפרסים בתחום אחד ב Google Cloudאזור. בהמשך מפורטות דוגמאות למשאבים של תחום מוגדר. הרשימה הזו לא מלאה.
- מכונות וירטואליות של Compute Engine
- קבוצות של מופעי מכונה מנוהלים (MIG) אזוריים
- דיסקים לאחסון מתמיד של תחום
- אשכולות GKE עם אזור יחיד
- מכונות Filestore Basic ואזורי
- משימות Dataflow
- מכונות של Cloud SQL
- שירות מנוהל לאשכולות Apache Spark ב-Compute Engine
כשל באזור מסוים עשוי להשפיע על המשאבים האזוריים שהוקצו באותו אזור. האזורים מתוכננים כך שיצמצמו את הסיכון לכשלים מתואמים עם אזורים אחרים באותו אזור. כשל באזור אחד בדרך כלל לא משפיע על המשאבים באזורים אחרים באותו אזור. בנוסף, כשל באזור מסוים לא בהכרח גורם לכל התשתית באותו אזור להיות לא זמינה. האזור רק מגדיר את הגבול הצפוי להשפעה של כשל.
כדי להגן על אפליקציות שמשתמשות במשאבים של תחום מוגדר מפני אירועים שקורים בתחום, אפשר לפרוס או לשכפל את המשאבים בכמה תחומים או אזורים. מידע נוסף זמין במאמר תכנון תשתית מהימנה לעומסי העבודה ב- Google Cloud.
משאבים אזוריים
משאבים אזוריים נפרסים בצורה יתירה במספר תחומים באזור מסוים. אלה דוגמאות למשאבים אזוריים. זו רשימה חלקית בלבד.
- קבוצות אזוריות של מכונות וירטואליות בניהול (MIG)
- קטגוריות אזוריות של Cloud Storage
- דיסקים לאחסון מתמיד אזורי
- אשכולות 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). לדוגמה, אפשר להשתמש במאזן עומסים גלובלי כחלק הקדמי של אפליקציה שמפוזרת גיאוגרפית. בדרך כלל, מאזן עומסים גלובלי הוא בחירה טובה לאפליקציה כזו. עם זאת, שגיאה בהגדרת מאזן העומסים עלולה לגרום לכך שהוא לא יהיה זמין בכל המיקומים הגיאוגרפיים. כדי למנוע את הסיכון הזה, צריך לנהל בזהירות את שינויי ההגדרות במשאבים גלובליים. מידע נוסף על שליטה בשינויים במשאבים גלובליים
שימוש במשאבים אזוריים כגיבויים להגנה לעומק
באפליקציות עם דרישות זמינות גבוהות במיוחד, גיבויים אזוריים עם הגנה מקיפה יכולים לעזור למזער את ההשפעה של הפסקות שירות במשאבים גלובליים. נניח שיש לכם אפליקציה שמפוזרת גיאוגרפית וכוללת מאזן עומסים גלובלי כחלק הקדמי שלה. כדי לוודא שהאפליקציה תישאר נגישה גם אם מאזן העומסים הגלובלי מושפע מהפסקת שירות גלובלית, אפשר לפרוס מאזני עומסים אזוריים. אתם יכולים להגדיר את הלקוחות כך שהם יעדיפו את מאזן העומסים הגלובלי, אבל יעברו למאזן העומסים האזורי הקרוב ביותר אם מאזן העומסים הגלובלי לא זמין.
דוגמה לארכיטקטורה עם משאבים גלובליים, אזוריים ושל תחום מוגדר
טופולוגיית הענן יכולה לכלול שילוב של משאבים אזוריים, גלובליים ואזוריים, כמו שמוצג בתרשים הבא. התרשים הבא מציג ארכיטקטורה לדוגמה של אפליקציה מרובת-שכבות שפרוסה ב-Google Cloud.
כפי שמוצג בתרשים הקודם, מאזן עומסים חיצוני גלובלי מסוג HTTP/S מקבל בקשות מלקוחות. מאזן העומסים מפזר את הבקשות אל ה-Backend, שהוא קבוצת מופעים מנוהלת (MIG) אזורית עם שתי מכונות וירטואליות של Compute Engine. האפליקציה שפועלת במכונות הווירטואליות כותבת נתונים למסד נתונים של Cloud SQL וקוראת ממנו נתונים. מסד הנתונים מוגדר לזמינות גבוהה (HA). המופעים הראשיים והמשניים של מסד הנתונים מוקצים באזורים נפרדים, ומסד הנתונים הראשי משוכפל באופן סינכרוני למסד הנתונים המשני. בנוסף, מסד הנתונים מגובה אוטומטית לקטגוריה מרובת אזורים ב-Cloud Storage.
בטבלה הבאה מפורטים המשאבים בארכיטקטורה הקודמת ומידת החוסן (resilience) של כל משאב להפסקות זמניות בשירות באזור ובאזור הזמינות: Google Cloud
| משאב | חוסן (resilience) בפני הפסקות זמניות בשירות |
|---|---|
| רשת VPC | רשתות VPC, כולל נתיבים וכללים לחומת אש שמשויכים אליהן, הן משאבים גלובליים. הן עמידות להפסקות חשמל באזורים ובתחומים. |
| תת-רשתות | תת-רשתות של VPC הן משאבים אזוריים. הם עמידים להפסקות זמניות בשירות באזור מסוים. |
| מאזן עומסים גלובלי חיצוני מסוג HTTP/S | מאזני עומסים גלובליים חיצוניים מסוג HTTP/S עמידים להפסקות חשמל באזורים ובאזורי זמינות. |
| Regional MIG | קבוצות אזוריות של מכונות וירטואליות עמידות להפסקות זמניות בשירות באזור מסוים. |
| מכונות וירטואליות של Compute Engine | מכונות וירטואליות של Compute Engine הן משאבים של תחום מוגדר. אם מתרחש הפסקת חשמל באזור, יכול להיות שיושפעו המכונות הווירטואליות של Compute Engine. עם זאת, האפליקציה יכולה להמשיך לטפל בבקשות כי הבק-אנד של מאזן העומסים הוא MIG אזורי, ולא מכונות וירטואליות עצמאיות. |
| מכונות של Cloud SQL | פריסת Cloud SQL בארכיטקטורה הזו מוגדרת לזמינות גבוהה (HA). כלומר, הפריסה כוללת זוג של מכונות מסד נתונים ראשיות ומשניות. מסד הנתונים הראשי משוכפל באופן סינכרוני למסד הנתונים המשני באמצעות אחסון מתמיד (persistent disk) אזורי.
|
| קטגוריה של Cloud Storage בכמה אזורים | נתונים שמאוחסנים בקטגוריות של Cloud Storage בכמה אזורים עמידים להפסקות חשמל באזור יחיד. |
| דיסקים לאחסון מתמיד | דיסקים לאחסון מתמיד יכולים להיות אזוריים או של תחום מוגדר. דיסקים לאחסון מתמיד אזוריים עמידים בפני הפסקות זמניות בשירות באזור מסוים. כדי להתכונן להתאוששות מהפסקות חשמל באזור, אפשר לתזמן תמונות מצב של דיסקים מתמידים ולאחסן את תמונות המצב בקטגוריה של Cloud Storage במספר אזורים. |