תכנון תוכנית התאוששות מאסון (DR) להפסקות זמניות בתשתית הענן

Last reviewed 2024-05-10 UTC

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

הסדרה מורכבת מהחלקים הבאים:

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

מבוא

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

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

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

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

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

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

איך Google Cloud מתוכנן לעמידות

מרכזי הנתונים של Google

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

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

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

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

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

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

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

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

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

איך להשתמש באזורים ובאזורי זמינות כדי להשיג אמינות

מהנדסי SRE ב-Google מנהלים ומרחיבים מוצרים גלובליים שמשתמשים רבים מסתמכים עליהם, כמו Gmail וחיפוש Google, באמצעות מגוון טכניקות וטכנולוגיות שממנפות בצורה חלקה את תשתית המחשוב ברחבי העולם. זה כולל הפניית תנועה ממיקומים לא זמינים באמצעות איזון עומסים גלובלי, הפעלת רפליקות מרובות במיקומים רבים ברחבי העולם ושכפול נתונים בין מיקומים. אותן יכולות זמינות ללקוחות Google Cloud באמצעות מוצרים כמו Cloud Load Balancing,‏ Google Kubernetes Engine ‏ (GKE) ו-Spanner.

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

משאב	דוגמאות	יעד התכנון של הזמינות	זמן השבתה משוער
אזורי	‫Compute Engine, ‏ Persistent Disk	99.9%	‫8.75 שעות בשנה
אזורי	‫Cloud Storage אזורי, דיסק לאחסון מתמיד משוכפל, GKE אזורי	99.99%	‫52 דקות בשנה

הערה: אלה הנחיות עיצוב. Google Cloud התחייבויות לרמת השירות מפורטות בGoogle Cloud הסכמי רמת השירות.

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

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

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

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

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

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

Google Cloud מציע רק כמה משאבים אזוריים, כלומר מכונות וירטואליות (VM) של Compute Engine ו-Persistent Disk. אם אתם מתכננים להשתמש במשאבים של תחום מוגדר, תצטרכו לבצע בעצמכם את הרכבת המשאבים. לשם כך, תצטרכו לתכנן, לבנות ולבדוק יתירות כשל ושחזור בין משאבים של תחום מוגדר שנמצאים בכמה אזורים. למשל:

• ניתוב מהיר של התנועה למכונות וירטואליות באזור אחר באמצעות Cloud Load Balancing, כשבדיקת תקינות קובעת שיש בעיות באזור מסוים.
• משתמשים בתבניות של מכונות ב-Compute Engine או בקבוצות של מופעי מכונה מנוהלים כדי להריץ ולהרחיב מכונות וירטואליות זהות בכמה אזורים.
• אפשר להשתמש ב-Persistent Disk אזורי כדי לשכפל נתונים באופן סינכרוני לאזור אחר באזור. פרטים נוספים זמינים במאמר בנושא אפשרויות לזמינות גבוהה באמצעות PD אזוריים.

תכנון של היקפי הפסקות שירות אזוריות

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

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

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

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

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

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

Google Cloud גישה לעמידות ולזמינות

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

מערכת שתוכננה היטב יכולה לענות על השאלה: "מה קורה כשאזור או אזור משנה חווים הפסקה זמנית בשירות למשך דקה, 5 דקות, 10 דקות או 30 דקות?" צריך לקחת את זה בחשבון ברמות רבות, כולל:

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

מדריך מפורט לתכנון תוכנית התאוששות מאסון (DR) של אפליקציות ב- Google Cloud

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

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

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

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

שלב 1: איסוף הדרישות הקיימות

השלב הראשון הוא להגדיר את דרישות הזמינות של האפליקציות. לרוב החברות כבר יש הנחיות עיצוב ברמה מסוימת בתחום הזה, שיכול להיות שהן פותחו באופן פנימי או שהן נגזרות מתקנות או מדרישות משפטיות אחרות. הנחיות התכנון האלה בדרך כלל מוגדרות בשני מדדים מרכזיים: יעד משך ההתאוששות (RTO) ויעד נקודת ההתאוששות (RPO). במונחים עסקיים, RTO מתורגם ל'כמה זמן אחרי אסון יעבור עד שהמערכת תפעל שוב'. ה-RPO מתורגם לשאלה: "כמה נתונים אני יכול להרשות לעצמי לאבד במקרה של אסון".

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

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

1. האם האפליקציה צריכה לפעול בכמה אזורים באותו אזור, או בכמה אזורים בכמה אזורים?
2. באילו מוצרים של Google Cloud Google האפליקציה יכולה להיות תלויה?

זוהי דוגמה לפלט של תהליך איסוף הדרישות:

RTO ו-RPO לפי רמת הקריטיות של האפליקציה בארגון לדוגמה Co:

רמת הקריטיות של האפליקציה	אחוז האפליקציות	אפליקציות לדוגמה	הפסקת פעילות באזור	הפסקה זמנית בשירות שמשפיעה על אזור
רמה 1 (הכי חשוב)	‫5%	בדרך כלל מדובר באפליקציות גלובליות או חיצוניות שפונות ללקוחות, כמו תשלומים בזמן אמת וחנויות מסחר אלקטרוני.	RTO Zero RPO Zero	RTO Zero RPO Zero
קבוצה 2	‪35%	בדרך כלל מדובר באפליקציות אזוריות או באפליקציות פנימיות חשובות, כמו CRM או ERP.	RTO 15mins RPO 15mins	RTO 1hr RPO 1hr
שכבה 3 (הכי פחות חשוב)	60%	בדרך כלל אפליקציות של צוותים או מחלקות, כמו back office, הזמנת חופשות, נסיעות פנימיות, חשבונאות ומשאבי אנוש.	RTO 1hr RPO 1hr	זמן החזרה לפעילות (RTO) 12 שעות RPO 12hrs

שלב 2: מיפוי היכולות למוצרים הזמינים

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

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

Google Cloud יכולות כלליות של המוצר
(בנספח מפורטות יכולות ספציפיות של המוצר)

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

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

איך מגבלות RPO משפיעות על בחירת המוצרים

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

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

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

איך מגבלות RTO משפיעות על בחירת המוצרים

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

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

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

שלב 3: פיתוח מדריכים וארכיטקטורות הפניה משלכם

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

יצירת הנחיות לגבי מוצרים

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

דוגמאות לדפוסי ארכיטקטורה לארגון לדוגמה Co – הפסקה זמנית בשירות באזור חוסן (resilience)

Google Cloud מוצר	האם המוצר עומד בדרישות להפסקה זמנית בשירות אזורית עבור ארגון לדוגמה (עם הגדרת מוצר מתאימה)
	רמה 1	קבוצה 2	שכבה 3
Compute Engine	לא	לא	לא
Dataflow	לא	לא	לא
BigQuery	לא	לא	כן
GKE	כן	כן	כן
Cloud Storage	כן	כן	כן
Cloud SQL	לא	כן	כן
Spanner	כן	כן	כן
Cloud Load Balancing	כן	כן	כן

הטבלה הזו היא דוגמה בלבד שמבוססת על רמות היפותטיות שמוצגות למעלה.

דוגמאות לדפוסי ארכיטקטורה לארגון לדוגמה Co – הפסקה זמנית בשירות אזורית חוסן (resilience)

Google Cloud מוצר	האם המוצר עומד בדרישות להפסקה זמנית בשירות אזורית עבור ארגון לדוגמה (עם הגדרת מוצר מתאימה)
	רמה 1	קבוצה 2	שכבה 3
Compute Engine	כן	כן	כן
Dataflow	לא	לא	לא
BigQuery	לא	לא	כן
GKE	כן	כן	כן
Cloud Storage	לא	לא	לא
Cloud SQL	לא	כן	כן
Spanner	כן	כן	כן
Cloud Load Balancing	כן	כן	כן

הטבלה הזו היא דוגמה בלבד שמבוססת על רמות היפותטיות שמוצגות למעלה.

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

דוגמה לארכיטקטורה ברמה 3

רמת הקריטיות של האפליקציה	הפסקת פעילות באזור	הפסקה זמנית בשירות שמשפיעה על אזור
רמה 3 (הכי פחות חשובה)	RTO 12 hours RPO 24 hours	RTO 28 days RPO 24 hours

(סמלים אפורים מציינים תשתיות שצריך להפעיל כדי לאפשר שחזור)

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

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

החלטות מרכזיות לגבי הארכיטקטורה במקרה של הפסקה זמנית בשירות באזור – RTO של 12 שעות ו-RPO של 24 שעות:

• מאזן עומסים פנימי משמש כדי לספק למשתמשים נקודת גישה שניתנת להרחבה, ומאפשר מעבר אוטומטי ליתירות כשל באזור אחר. למרות שזמן ההתאוששות (RTO) הוא 12 שעות, שינויים ידניים בכתובות IP או אפילו עדכוני DNS יכולים להימשך יותר זמן מהצפוי.
• קבוצת מופעי מכונה מנוהלים אזורית מוגדרת עם כמה אזורים אבל עם מינימום משאבים. האפשרות הזו מבצעת אופטימיזציה של העלויות, אבל עדיין מאפשרת הרחבה מהירה של מכונות וירטואליות באזור הגיבוי.
• הגדרת Cloud SQL לזמינות גבוהה מאפשרת מעבר אוטומטי ליתירות כשל לאזור אחר. יצירה מחדש ושחזור של מסדי נתונים הם תהליכים מורכבים בהרבה בהשוואה למכונות וירטואליות של Compute Engine.

החלטות מרכזיות לגבי הארכיטקטורה במקרה של הפסקה זמנית בשירות באזור – RTO של 28 ימים ו-RPO של 24 שעות:

• מאזן עומסים ייווצר באזור 2 רק במקרה של הפסקה זמנית בשירות אזורית. ‫Cloud DNS משמש כדי לספק יכולת יתירות כשל אזורית מתואמת אבל ידנית, כי התשתית באזור 2 תהיה זמינה רק במקרה של הפסקה זמנית בשירות באזור.
• קבוצה חדשה של מופעי מכונה מנוהלים תיבנה רק במקרה של הפסקת חשמל באזור. האפשרות הזו מבצעת אופטימיזציה של העלויות, ולא סביר שהיא תופעל בהתחשב באורך הקצר של רוב ההפסקות האזוריות. הערה: כדי לפשט את הדיאגרמה, לא מוצגים בו כלי העזר שנדרשים לפריסה מחדש או העתקה של תמונות Compute Engine.
• מכונת Cloud SQL חדשה תיווצר מחדש והנתונים ישוחזרו מגיבוי. שוב, הסיכון להפסקה זמנית בשירות ממושכת באזור מסוים הוא נמוך מאוד, ולכן זהו עוד פשרה שקשורה לאופטימיזציה של עלויות.
• ‫Cloud Storage שפועל במספר אזורים משמש לאחסון הגיבויים האלה. הגדרה זו מספקת חוסן אוטומטי של אזורים ואזורים משנה במסגרת RTO ו-RPO.

דוגמה לארכיטקטורה ברמה 2

רמת הקריטיות של האפליקציה	הפסקת פעילות באזור	הפסקה זמנית בשירות שמשפיעה על אזור
קבוצה 2	RTO 4 hours RPO zero	RTO 24 hours RPO 4 hours

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

חלק מהרכיבים הבודדים בארכיטקטורה הזו לא תומכים ישירות ב-RPO הנדרש לרמה שלהם. עם זאת, בגלל אופן השימוש בהם יחד, השירות הכולל עומד בדרישות של RPO. במקרה הזה, מכיוון ש-Dataflow הוא מוצר אזורי, כדאי לפעול לפי ההמלצות לתכנון זמינות גבוהה כדי למנוע אובדן נתונים במהלך הפסקת שירות. עם זאת, שכבת Cloud Storage היא מקור הזהב של הנתונים האלה, והיא תומכת ב-RPO של אפס. כתוצאה מכך, תוכלו להטמיע מחדש ב-BigQuery את הנתונים שאבדו באמצעות אזור b במקרה של הפסקה זמנית בשירות באזור a.

החלטות ארכיטקטוניות מרכזיות לגבי הפסקת שירות באזור – RTO של 4 שעות ו-RPO של אפס:

• מאזן עומסים משמש כדי לספק למשתמשים נקודת גישה שניתנת להרחבה, ומאפשר מעבר אוטומטי לזמינות בעוד אזור. למרות שזמן ההתאוששות הוא 4 שעות, שינויים ידניים בכתובות IP או אפילו עדכוני DNS יכולים להימשך יותר מהצפוי.
• קבוצת מופעי מכונה מנוהלים אזורית לשכבת החישוב של התצוגה החזותית של הנתונים מוגדרת עם כמה אזורים אבל עם מינימום משאבים. האפשרות הזו מבצעת אופטימיזציה של העלויות, אבל עדיין מאפשרת הרחבה מהירה של מכונות וירטואליות.
• ‫Cloud Storage אזורי משמש כשכבת ביניים להעברה ראשונית של נתונים, ומספק עמידות אוטומטית של אזורים.
• ‫Dataflow משמש לחילוץ נתונים מ-Cloud Storage ולשינוי שלהם לפני טעינתם ל-BigQuery. במקרה של הפסקה זמנית בשירות באזור, זהו תהליך בלי שמירת מצב שאפשר להפעיל מחדש באזור אחר.
• ‫BigQuery מספק את העורף של מחסן הנתונים לממשק הקצה של ויזואליזציית הנתונים. במקרה של הפסקה זמנית בשירות באזור, כל הנתונים שאבדו יוכנסו מחדש מ-Cloud Storage.

החלטות ארכיטקטוניות מרכזיות במקרה של הפסקה זמנית בשירות באזור – RTO של 24 שעות ו-RPO של 4 שעות:

• מאזן עומסים בכל אזור משמש כנקודת גישה שניתנת להרחבה עבור המשתמשים. ‫Cloud DNS משמש כדי לספק יכולת יתירות כשל אזורית מתואמת אבל ידנית, כי התשתית באזור 2 תהיה זמינה רק במקרה של הפסקה זמנית בשירות באזור.
• קבוצת מופעי מכונה מנוהלים אזורית לשכבת החישוב של התצוגה החזותית של הנתונים מוגדרת עם כמה אזורים אבל עם מינימום משאבים. אי אפשר לגשת לנתונים האלה עד שמגדירים מחדש את איזון העומסים, אבל לא נדרשת התערבות ידנית.
• ‫Cloud Storage אזורי משמש כשכבת ביניים להעברה ראשונית של נתונים. הנתונים נטענים בו-זמנית לשני האזורים כדי לעמוד בדרישות של RPO.
• ‫Dataflow משמש לחילוץ נתונים מ-Cloud Storage ולשינוי שלהם לפני טעינתם ל-BigQuery. במקרה של הפסקת שירות באזור מסוים, הנתונים האחרונים מ-Cloud Storage יאוכלסו ב-BigQuery.
• ‫BigQuery מספק את העורף של מחסן הנתונים. בפעילות רגילה, הנתונים האלה מתעדכנים לסירוגין. במקרה של הפסקה זמנית בשירות באזור, הנתונים האחרונים ייקלטו מחדש דרך Dataflow מ-Cloud Storage.

דוגמה לארכיטקטורה ברמה 1

רמת הקריטיות של האפליקציה	הפסקת פעילות באזור	הפסקה זמנית בשירות שמשפיעה על אזור
רמה 1 (הכי חשוב)	RTO zero RPO zero	RTO 4 hours RPO 1 hour

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

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

החלטות ארכיטקטוניות מרכזיות במקרה של הפסקה זמנית בשירות באזור – RTO של אפס ו-RPO של אפס:

• מאזן עומסים משמש כדי לספק למשתמשים נקודת גישה שניתנת להרחבה, ומאפשר מעבר אוטומטי לזמינות בעוד אזור.
• אשכול GKE אזורי משמש לשכבת האפליקציה, שמוגדרת עם כמה אזורים. כך מתקבל RTO של אפס בכל אזור.
• ‫Spanner במספר אזורים משמש כשכבת התמדה של נתונים, ומספק עמידות אוטומטית של נתונים באזור ועקביות של עסקאות.
• ‫BigQuery מספק את יכולות הניתוח של האפליקציה. כל אזור מקבל נתונים מ-Spanner באופן עצמאי, והאפליקציה ניגשת אליו באופן עצמאי.

החלטות אדריכליות מרכזיות לגבי הפסקה זמנית בשירות באזור – RTO של 4 שעות ו-RPO של שעה אחת:

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

נספח: הפניה למוצר

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

עיצובים נפוצים

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

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

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

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

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

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

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

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

Access Context Manager

בעזרת Access Context Manager, ארגונים יכולים להגדיר רמות גישה למיפוי לפי מדיניות שמוגדרת על סמך מאפיינים רצויים. כללי המדיניות משוכפלים באזורים.

במקרה של הפסקה זמנית בשירות אזורית, בקשות לאזורים לא זמינים מטופלות באופן אוטומטי ושקוף מאזורים זמינים אחרים באזור.

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

Access Transparency

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

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

‫AlloyDB ל-PostgreSQL

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

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

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

‫AlloyDB ל-PostgreSQL מזהה באופן אוטומטי כשלים ברמת האזור ומפעיל מעבר לגיבוי (failover) כדי לשחזר את הזמינות של מסד הנתונים. במהלך מעבר לגיבוי,‏ AlloyDB ל-PostgreSQL מפעיל את מסד הנתונים בצומת ההמתנה, שכבר הוקצה באזור אחר. חיבורים חדשים למסד נתונים מנותבים אוטומטית לאזור הזה.

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

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

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

ה-RPO של שכפול בין אזורים מושפע גם מניצול המעבד (CPU) של האשכול הראשי, וגם מהמרחק הפיזי בין האזור של האשכול הראשי לבין האזור של האשכול המשני. כדי לבצע אופטימיזציה של RPO, מומלץ לבדוק את עומס העבודה עם הגדרה שכוללת רפליקה כדי לקבוע מגבלה בטוחה של עסקאות לשנייה (TPS). זוהי המגבלה הגבוהה ביותר של TPS שלא מצטבר בה זמן השהיה של שטיפה. אם עומס העבודה חורג ממגבלת ה-TPS הבטוחה, מצטבר פיגור של שטיפה, שיכול להשפיע על RPO. כדי לצמצם את השהיית הרשת, כדאי לבחור זוגות של אזורים באותה יבשת.

מידע נוסף על מעקב אחרי השהיית הרשת ומדדים אחרים של AlloyDB ל-PostgreSQL זמין במאמר בנושא מעקב אחרי מכונות.

AI למניעה של הלבנת הון

‫Anti Money Laundering AI (AML AI) מספק API שעוזר למוסדות פיננסיים ברחבי העולם לזהות הלבנת הון בצורה יעילה יותר. הפתרון לזיהוי הלבנת הון באמצעות AI הוא אזורי, כלומר הלקוחות יכולים לבחור את האזור, אבל לא את האזורים שמרכיבים את האזור. הנתונים והתעבורה עוברים איזון עומסים אוטומטי בין אזורים בתוך אזור. הפעולות (לדוגמה, יצירת צינור או הפעלת חיזוי) מותאמות אוטומטית ברקע, והעומס מאוזן בין האזורים לפי הצורך.

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

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

מפתחות API

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

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

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

Apigee

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

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

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

AutoML Translation

‫AutoML Translation הוא שירות תרגום אוטומטי שמאפשר לכם לייבא נתונים משלכם (זוגות משפטים) כדי לאמן מודלים מותאמים אישית לצרכים הספציפיים שלכם בתחום מסוים.

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

הפסקה זמנית בשירות ברמת האזור: במקרה של כשל אזורי, AutoML Translation לא זמין.

AutoML Vision

‫AutoML Vision הוא חלק מ-Vertex AI. הוא מציע מסגרת מאוחדת ליצירת מערכי נתונים, לייבוא נתונים, לאימון מודלים ולהצגת מודלים לחיזוי אונליין ולחיזוי באצווה.

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

הפסקה זמנית בשירות אזורית: AutoML Vision מאחסן את המטא-נתונים של העבודות באופן אזורי, וכותב באופן סינכרוני באזורים בתוך האזור. המשימות מופעלות באזור ספציפי, כפי שנבחר על ידי Cloud Load Balancing.

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

• משימות חיזוי באצווה ב-AutoML Vision: חיזוי באצווה מבוסס על חיזוי באצווה ב-Vertex AI. כשמתרחשת הפסקה זמנית בשירות אזורית, השירות מנסה שוב באופן אוטומטי להריץ את העבודה על ידי ניתוב שלה לאזורים זמינים. אם הניסיונות החוזרים נכשלים, סטטוס העבודה מתעדכן ל'נכשל'. בקשות משתמשים עוקבות להפעלת העבודה מנותבות לאזור זמין.

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

Batch

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

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

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

הגנה על נתונים מפני איומים ב-Chrome Enterprise Premium

הגנה על נתונים מפני איומים ב-Chrome Enterprise Premium היא חלק מהפתרון Chrome Enterprise Premium. הוא מרחיב את Chrome עם מגוון תכונות אבטחה, כולל הגנה מפני תוכנות זדוניות ופישינג, מניעת אובדן נתונים (DLP), כללים לסינון כתובות URL ודיווח על אבטחה.

אדמינים של Chrome Enterprise Premium יכולים להסכים לאחסון של תוכן ליבה של לקוחות שמפר מדיניות DLP או מדיניות בנושא תוכנות זדוניות ביומן האירועים של רישום כללים ב-Google Workspace או ב-Cloud Storage לצורך בדיקה עתידית. אירועים ביומן של כללים ב-Google Workspace מבוססים על מסד נתונים של Spanner עם מספר אזורים. יכולות לעבור כמה שעות עד ש-Chrome Enterprise Premium יזהה הפרות של מדיניות. במהלך הזמן הזה, כל הנתונים שלא עברו עיבוד חשופים לאובדן נתונים כתוצאה מהפסקה זמנית בשירות אזורית או אזורית. כשמזוהה הפרה, התוכן שמפר את המדיניות נרשם באירועים של יומן הכללים של Google Workspace ו/או ב-Cloud Storage.

הפסקה זמנית בשירות באזור או בתחום: מכיוון שההגנה על נתונים מפני איומים ב-Chrome Enterprise Premium פועלת במספר תחומים ובמספר אזורים, היא יכולה להמשיך לפעול גם אם יש הפסקה זמנית בשירות בתחום או באזור מסוים, בלי שתהיה פגיעה בזמינות. כדי לספק את רמת האמינות הזו, השירות מפנה את תנועת הגולשים לאזורים או לאזורים פעילים אחרים. עם זאת, יכול להיות שיחלפו כמה שעות עד שההגנה מפני איומים וההגנה על נתונים ב-Chrome Enterprise Premium יזהו הפרות של מדיניות DLP ותוכנות זדוניות. לכן, נתונים שלא עברו עיבוד באזור מסוים עלולים ללכת לאיבוד בגלל הפסקה זמנית בשירות באזור.

BigQuery

‫BigQuery הוא מחסן נתונים (data warehouse) בענן, חסכוני וללא שרת (serverless), עם יכולת התאמה רחבה, שמתוכנן להשגת גמישות עסקית. ‫BigQuery תומך בסוגי המיקומים הבאים עבור מערכי נתונים של משתמשים:

• אזור: מיקום גיאוגרפי ספציפי, כמו איווה (us-central1) או מונטריאול (northamerica-northeast1).
• מספר אזורים: אזור גיאוגרפי נרחב שמכיל שני מקומות גיאוגרפיים או יותר, כמו ארצות הברית (US) או אירופה (EU).

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

Binary Authorization

‫Binary Authorization הוא מוצר אבטחה לשרשרת האספקה של תוכנות ל-GKE ול-Cloud Run.

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

פעולות האכיפה של Binary Authorization עמידות בפני הפסקות זמניות בשירות באזור מסוים, אבל לא בפני הפסקות זמניות בשירות באזור. פעולות האכיפה מתבצעות באותו אזור שבו נמצא אשכול GKE או עבודת Cloud Run ששולחת את הבקשה. לכן, במקרה של הפסקה זמנית בשירות אזורית, לא פועל שום דבר שיכול לשלוח בקשות לאכיפת Binary Authorization.

Certificate Manager

‫Certificate Manager מאפשר לכם לקבל ולנהל אישורי Transport Layer Security (TLS) לשימוש בסוגים שונים של Cloud Load Balancing.

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

המערכת לגילוי חדירות (IDS) של Google Cloud

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

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

הפסקת שירות אזורית: Cloud IDS הוא מוצר אזורי. היא לא מספקת פונקציונליות חוצת-אזורים. כשל אזורי ישבית את כל הפונקציות של Cloud IDS בכל התחומים באותו אזור.

Google Security Operations SIEM

‫SIEM של Google Security Operations (שהוא חלק מ-Google Security Operations) הוא שירות בניהול מלא שעוזר לצוותי אבטחה לזהות איומים, לחקור אותם ולהגיב להם.

ב-Google Security Operations SIEM יש חבילות שירות אזוריות ורב-אזוריות.

• במוצרים אזוריים, הנתונים והתנועה מאוזנים אוטומטית בין אזורים בתוך האזור שנבחר, והנתונים מאוחסנים בצורה יתירה בין אזורי הזמינות בתוך האזור.

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

• ברוב הנתיבים להעברת נתונים, נתוני הלקוחות משוכפלים באופן סינכרוני בכמה מיקומים. כשנתונים משוכפלים באופן אסינכרוני, יש חלון זמן (יעד נקודת שחזור, או RPO) שבמהלכו הנתונים עדיין לא משוכפלים בכמה מיקומים. זה קורה כשמבצעים המרה באמצעות פידים בפריסות מרובות אזורים. אחרי ה-RPO, הנתונים זמינים בכמה מיקומים.

הפסקת חשמל אזורית:

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

• פריסות במספר אזורים: הפסקות חשמל אזוריות שוות להפסקות חשמל אזוריות.

הפסקת שירות אזורית:

• פריסות אזוריות: מערכת Google Security Operations SIEM מאחסנת את כל נתוני הלקוחות באזור אחד, והתנועה אף פעם לא מנותבת בין אזורים. במקרה של הפסקת שירות אזורית, Google Security Operations SIEM לא זמין באזור עד שההפסקה תיפתר.

• פריסות במספר אזורים (ללא פידים): הבקשות מוגשות מכל אזור בפריסה במספר אזורים. הנתונים משוכפלים באופן סינכרוני בכמה אזורים. במקרה של הפסקה זמנית בשירות באזור שלם, האזורים הנותרים ממשיכים להעביר תנועה ולעבד את הנתונים. הקצאת משאבים יתירה ושינוי גודל אוטומטי ב-Google Security Operations SIEM עוזרים לוודא שהשירות ימשיך לפעול באזורים הנותרים במהלך שינויי העומס האלה.

• פריסות במספר אזורים (עם פידים): הבקשות מוגשות מכל אזור בפריסה במספר אזורים. הנתונים משוכפלים באופן אסינכרוני בכמה אזורים עם RPO שסופק. במקרה של הפסקת שירות באזור שלם, רק נתונים שאוחסנו אחרי ה-RPO זמינים באזורים הנותרים. יכול להיות שהנתונים בחלון RPO לא ישוכפלו.

מאגר משאבי ענן

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

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

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

Bigtable

‫Bigtable הוא שירות מנוהל של מסד נתונים NoSQL עם רמת ביצועים גבוהה, שמתאים לעומסי עבודה תפעוליים ואנליטיים גדולים.

סקירה כללית על שכפול ב-Bigtable

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

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

שיקולי ביצועים

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

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

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

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

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

מעקב

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

אפשר גם לנטר באופן פרוגרמטי את המדדים של השכפול ב-Bigtable באמצעות Cloud Monitoring API.

Certificate Authority Service

Certificate Authority Service (CA Service) מאפשר ללקוחות לפשט, לבצע אוטומציה ולהתאים אישית את הפריסה, הניהול והאבטחה של רשויות אישורים פרטיות (CA), ולהנפיק אישורים בהיקף גדול בצורה גמישה.

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

הפסקה זמנית בשירות אזורית: CA Service הוא מוצר אזורי, ולכן הוא לא יכול לעמוד בכשל אזורי. אם אתם צריכים חוסן (resilience) בפני כשלים אזוריים, כדאי ליצור רשויות אישורים מנפיקות בשני אזורים שונים. יוצרים את רשות האישורים הראשית באזור שבו נדרשים אישורים. יוצרים רשות אישורים חלופית באזור אחר. שימוש בחלופה אם יש הפסקה זמנית בשירות באזור של רשות האישורים המשנית. במקרה הצורך, שני רשויות האישורים יכולות ליצור שרשרת עד לאותה רשות אישורים בסיסית.

חיוב ב-Cloud

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

כשל אזורי או אזורי: Cloud Billing API יעבור אוטומטית לאזור אחר. יכול להיות שבקשות בודדות ייכשלו, אבל מדיניות ניסיון חוזר (retry) אמורה לאפשר לניסיונות הבאים להצליח.

Cloud Build

‫Cloud Build הוא שירות להפעלת גרסאות ה-build שפיתחתם, ב- Google Cloud.

‫Cloud Build מורכב ממופעים מבודדים אזורית שיוצרים רפליקציה סינכרונית של נתונים בין אזורים בתוך האזור. מומלץ להשתמש באזורים ספציפיים Google Cloud במקום באזור הגלובלי, ולוודא שהמשאבים שבהם נעשה שימוש ב-build (כולל מאגרי יומנים, מאגרי Artifact Registry וכו') תואמים לאזור שבו ה-build פועל.

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

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

Cloud CDN

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

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

מידע נוסף על Cloud CDN ועל התנהגות המטמון זמין במסמכי העזרה של Cloud CDN.

Cloud Composer

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

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

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

• אפשר ליצור סביבות של Cloud Composer 2 ו-Cloud Composer 3 במצב עמידות גבוהה, שמאפשר להן להיות עמידות בפני כשלים אזוריים. בסביבה עמידה במיוחד, מישור הבקרה ומסד הנתונים של Airflow בסביבה מפוזרים על פני כמה אזורים באזור. אם תחום אחד הופך ללא זמין, הסביבה ממשיכה לפעול.

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

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

Cloud Data Fusion

‫Cloud Data Fusion הוא שירות מנוהל לחלוטין לשילוב נתונים ארגוניים, שמאפשר ליצור ולנהל צינורות עיבוד נתונים במהירות. יש שלוש מהדורות.

• הפסקות חשמל אזוריות משפיעות על מופעים של מהדורת Developer.

• הפסקות חשמל אזוריות משפיעות על מקרים של מהדורות Basic ו-Enterprise.

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

ההמלצות הבאות רלוונטיות להפסקות חשמל אזוריות ואזורי משנה.

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

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

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

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

דרך נוספת להתכונן להפסקות שירות היא להגדיר כמה מופעים באזורים שונים עם אותה הגדרה ואותה קבוצת צינורות. אם משתמשים באורקסטרציה חיצונית, אפשר לבצע איזון עומסים אוטומטי של צינורות פעילים בין מופעים. חשוב לוודא שאין משאבים (כמו מקורות נתונים או כלי תזמור) שקשורים לאזור יחיד ומשמשים את כל המופעים, כי הם עלולים להפוך לנקודת כשל מרכזית בהפסקה זמנית בשירות. לדוגמה, יכולים להיות לכם כמה מופעים באזורים שונים, ותוכלו להשתמש ב-Cloud Load Balancing וב-Cloud DNS כדי להפנות את הבקשות להרצת צינורות אל מופע שלא מושפע מהפסקה זמנית בשירות (ראו את הארכיטקטורות של רמה 1 ורמה 3 לדוגמה).

הפסקות זמניות בשירותי נתונים אחרים בצינור עיבוד הנתונים Google Cloud

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

Cloud Deploy

‫Cloud Deploy מספק פיתוח רציף (continuous delivery) של עומסי עבודה לשירותי זמן ריצה כמו GKE ו-Cloud Run. השירות מורכב ממופעים אזוריים שיוצרים רפליקה של הנתונים באופן סינכרוני בין אזורים באותו אזור.

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

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

Cloud DNS

‫Cloud DNS הוא שירות DNS גלובלי, עמיד ובעל ביצועים גבוהים, שמפרסם את שמות הדומיינים שלכם ב-DNS הגלובלי בצורה חסכונית.

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

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

Cloud Healthcare API

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

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

הגדרה של מספר אזורים: בהגדרה של מספר אזורים, Cloud Healthcare API נפרס בשלושה אזורים ששייכים לשלושה אזורים שונים. הנתונים משוכפלים גם בשלושה אזורים. כך נמנעת הפסקת שירות במקרה של הפסקה זמנית בשירות באזור שלם, כי האזורים הנותרים ישתלטו אוטומטית. נתונים מובְנים, כמו FHIR, משוכפלים באופן סינכרוני במספר אזורים, ולכן הם מוגנים מפני אובדן נתונים במקרה של הפסקת שירות באזור שלם. נתונים שמאוחסנים בקטגוריות של Cloud Storage, כמו DICOM ודיבור להקלדה או אובייקטים גדולים של HL7v2/FHIR, משוכפלים באופן אסינכרוני במספר אזורים.

Cloud Identity

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

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

Cloud Interconnect

‫Cloud Interconnect מאפשר ללקוחות RFC 1918 גישה לרשתות Google Cloud ממרכזי הנתונים המקומיים שלהם, באמצעות כבלים פיזיים שמחוברים לנקודת הקישור בין רשתות שכנות (peering) של Google.

אם לקוחות יקצו קישורים לשני אזורי זמינות של קצה (EAD) באזור מטרופוליטני, הם יקבלו הסכם רמת שירות (SLA) של 99.9% ב-Cloud Interconnect. הסכם SLA של 99.99% זמין אם הלקוח מקצה קישורים בשני אזורי זמינות משופרים בשני אזורים מטרופוליטניים לשני אזורים עם ניתוב גלובלי. מידע נוסף זמין במאמרים סקירה כללית של טופולוגיה לאפליקציות לא קריטיות וסקירה כללית של טופולוגיה לאפליקציות ברמת ייצור.

‫Cloud Interconnect לא תלוי באזורי מחשוב ומספק זמינות גבוהה בצורה של EAD. במקרה של כשל ב-EAD, סשן ה-BGP לאותו EAD נקטע והתנועה עוברת ל-EAD השני.

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

Cloud Key Management Service

שירות Cloud Key Management Service‏ (Cloud KMS) מספק ניהול של משאבי מפתחות קריפטוגרפיים עם יכולת התאמה לעומס ורמת עמידות גבוהה. כל הנתונים והמטא נתונים של Cloud KMS מאוחסנים במסדי נתונים של Spanner, שמספקים עמידות וזמינות גבוהות של הנתונים באמצעות שכפול סינכרוני.

אפשר ליצור משאבי Cloud KMS באזור אחד, בכמה אזורים או באופן גלובלי.

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

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

Cloud External Key Manager (Cloud EKM)

‫Cloud External Key Manager משולב עם Cloud Key Management Service כדי לאפשר לכם לשלוט במפתחות חיצוניים ולגשת אליהם דרך שותפים נתמכים של צד שלישי. אתם יכולים להשתמש במפתחות החיצוניים האלה כדי להצפין נתונים באחסון, ולהשתמש בהם בשירותים אחרים שתומכים בשילוב של מפתחות הצפנה בניהול הלקוח (CMEK). Google Cloud

• הפסקה זמנית בשירות אזורית: Cloud External Key Manager עמיד להפסקות זמניות בשירות אזוריות בגלל היתירות שמסופקת על ידי מספר אזורים באזור. אם מתרחשת הפסקה זמנית בשירות אזורי, התנועה מנותבת מחדש לאזורים אחרים באזור. בזמן שהתנועה מנותבת מחדש, יכול להיות שיוצגו יותר שגיאות, אבל השירות עדיין יהיה זמין.

• הפסקה זמנית בשירות אזורית: שירות Cloud External Key Manager לא זמין במהלך הפסקה זמנית בשירות אזורית באזור המושפע. אין מנגנון מעבר לגיבוי (failover) שמפנה בקשות בין אזורים. מומלץ ללקוחות להשתמש בכמה אזורים להרצת העבודות שלהם.

Cloud External Key Manager לא מאחסן נתוני לקוחות באופן קבוע. לכן, לא מתרחש אובדן נתונים במהלך הפסקה זמנית בשירות אזורית במערכת Cloud External Key Manager. עם זאת, Cloud External Key Manager תלוי בזמינות של שירותים אחרים, כמו Cloud Key Management Service וספקים חיצוניים של צד שלישי. אם המערכות האלה ייכשלו במהלך הפסקת שירות אזורית, יכול להיות שחלק מהנתונים יאבדו. ה-RPO וה-RTO של המערכות האלה לא נכללים בהתחייבויות של Cloud External Key Manager.

Cloud Load Balancing

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

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

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

מידע נוסף על Cloud Load Balancing והתכונות שלו זמין במאמר סקירה כללית על Cloud Load Balancing.

Cloud Logging

‫Cloud Logging מורכב משני חלקים עיקריים: נתב היומנים ואחסון Cloud Logging.

הכלי Logs Router מטפל בהזרמת אירועים ביומן ומנתב את היומנים לאחסון ב-Cloud Storage, ב-Pub/Sub, ב-BigQuery או ב-Cloud Logging.

אחסון ב-Cloud Logging הוא שירות לאחסון יומנים, להפעלת שאילתות עליהם ולניהול התאימות שלהם. הוא תומך בהרבה משתמשים ובתהליכי עבודה, כולל פיתוח, תאימות, פתרון בעיות והתראות יזומות.

נתב יומנים ויומנים נכנסים: במהלך הפסקה זמנית בשירות אזורית, ממשק Cloud Logging API מנתב יומנים לאזורים אחרים באזור. בדרך כלל, יומנים שמנותבים על ידי נתב היומנים אל Cloud Logging,‏ BigQuery או Pub/Sub נכתבים ביעד הסופי שלהם בהקדם האפשרי, בעוד שיומנים שנשלחים אל Cloud Storage נשמרים במאגר זמני ונכתבים בקבוצות מדי שעה.

רשומות ביומן: במקרה של הפסקה זמנית בשירות אזורית או אזורית, לא נגיש לרשומות ביומן שנשמרו במאגר נתונים זמני באזור או באזור המושפע ולא נכתבו ליעד הייצוא. מדדים מבוססי-יומנים מחושבים גם בנתב היומנים, והם כפופים לאותן מגבלות. אחרי שהיומנים מועברים למיקום הייצוא שנבחר, הם משוכפלים בהתאם לשירות היעד. יומנים שמיוצאים לאחסון ב-Cloud Logging משוכפלים באופן סינכרוני בשני אזורים באזור מסוים. למידע על התנהגות השכפול של סוגי יעדים אחרים, אפשר לעיין בקטע הרלוונטי במאמר הזה. שימו לב: יומנים שמיוצאים ל-Cloud Storage נכתבים בקבוצות כל שעה. לכן אנחנו ממליצים להשתמש באחסון ב-Cloud Logging, ב-BigQuery או ב-Pub/Sub כדי לצמצם את כמות הנתונים שמושפעת מהפסקה זמנית בשירות.

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

Cloud Monitoring

‫Cloud Monitoring כולל מגוון תכונות מקושרות, כמו לוחות בקרה (מובנים ומוגדרים על ידי המשתמש), התראות וניטור זמינות.

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

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

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

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

Cloud NAT

‫Cloud NAT (תרגום כתובות רשת) הוא שירות מנוהל מבוזר מוגדר-תוכנה, שמאפשר למשאבים מסוימים ללא כתובות IP חיצוניות ליצור חיבורים יוצאים לאינטרנט. היא לא מבוססת על מכשירי או מכונות וירטואליות של proxy. במקום זאת, Cloud NAT מגדיר את תוכנת Andromeda שמפעילה את רשת ה-VPC, כך שהיא מספקת תרגום כתובות רשת של המקור (source NAT או SNAT) למכונות וירטואליות ללא כתובות IP חיצוניות. ‫Cloud NAT מספק גם תרגום כתובת רשת של יעד (תרגום NAT של יעד או DNAT) לחבילות תגובה נכנסות שנוצרו.

מידע נוסף על הפונקציונליות של Cloud NAT זמין במאמרי העזרה.

הפסקה זמנית בשירות אזורית:‏ Cloud NAT עמיד בפני כשלים אזוריים כי מישור הבקרה ומישור נתוני הרשת הם יתירים במספר אזורים בתוך אזור מסוים.

הפסקה זמנית בשירות אזורית: ‏Cloud NAT הוא מוצר אזורי, ולכן הוא לא יכול לעמוד בפני כשל אזורי.

Cloud Router

‫Cloud Router הוא שירות מבוזר ומנוהל באופן מלא Google Cloud שמשתמש בפרוטוקול Border Gateway Protocol ‏ (BGP) כדי לפרסם טווחים של כתובות IP. הוא מתכנת מסלולים דינמיים על סמך מודעות BGP שהוא מקבל מעמית. במקום מכשיר פיזי, כל Cloud Router מורכב ממשימות תוכנה שפועלות כרכיבי BGP ששולחים ומקבלים הודעות.

במקרה של הפסקה זמנית בשירות אזורית, Cloud Router עם הגדרת זמינות גבוהה (HA) עמיד לכשלים אזוריים. במקרה כזה, יכול להיות שאחד הממשקים יאבד את הקישוריות, אבל תעבורת הנתונים תנותב מחדש לממשק השני באמצעות ניתוב דינמי באמצעות BGP.

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

Cloud Run

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

אם אתם משתמשים ב-Cloud Run GPUs, יש לכם אפשרות להשבית את יתירות האזורים בשירות, ובמקום זאת להשתמש באמינות של best-effort במקרה של הפסקה זמנית בשירות באזור, בעלות נמוכה יותר. מידע נוסף זמין במאמר בנושא אפשרויות יתירות אזוריות של GPU.

הפסקה זמנית בשירות אזורית: Cloud Run מאחסן מטא-נתונים וגם את הקונטיינר שנפרס. הנתונים האלה מאוחסנים באזור מסוים ונכתבים באופן סינכרוני. ה-Cloud Run Admin API מחזיר את הקריאה ל-API רק אחרי שהנתונים נשמרים בקוורום באזור. מכיוון שהנתונים מאוחסנים באופן אזורי, כשלים אזוריים לא משפיעים על פעולות במישור הנתונים. אם יהיה כשל באזור מסוים, התנועה תנותב לאזורים אחרים.

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

Cloud Shell

‫Cloud Shell מספק Google Cloud למשתמשים גישה למכונות של Compute Engine עם משתמש יחיד, שמוגדרות מראש לצורך צירוף משתמשים, למידה, פיתוח ומשימות של אופרטורים.

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

המכונות ב-Compute Engine שמגבות את השירות הן משאבים אזוריים, ולכן במקרה של הפסקת חשמל באזור, Cloud Shell של המשתמש לא יהיה זמין.

Cloud Source Repositories

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

במקום זאת, פעולות git push מול Cloud Source Repositories משכפלות באופן סינכרוני את עדכון מאגר המקורות לכמה אזורים בכמה אזורים. כלומר, השירות עמיד בפני הפסקות זמניות בשירות באזור מסוים.

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

יכול להיות שבעיות ב-GitHub או ב-Bitbucket ישפיעו על התכונה של שיקוף מאגרים באופן אוטומטי. לדוגמה, שיקוף מושפע אם GitHub או Bitbucket לא יכולים להודיע ל-Cloud Source Repositories על קומיטים חדשים, או אם Cloud Source Repositories לא יכולים לאחזר תוכן מהמאגר המעודכן.

Spanner

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

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

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

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

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

ייצוא וייבוא: אפשר לייצא מסדי נתונים של Spanner לקובצי נתונים של Avro לגיבוי ולארכיון לטווח ארוך.

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

מידע נוסף על Spanner:

• הגדרות של מכונות Spanner
• Spanner replication
• סקירה כללית על התאוששות מאסון (DR) ב-Spanner
• שחזור מנקודה מסוימת בזמן ב-Spanner
• ייצוא וייבוא ב-Spanner

Cloud SQL

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

הפסקה זמנית בשירות אזורית: האפשרות זמינות גבוהה יוצרת מופע VM ראשי ומופע VM לגיבוי בשני אזורים נפרדים באותו אזור. במהלך פעולה רגילה, מופע ה-VM הראשי משרת את כל הבקשות, וכותב קבצים של מסד נתונים ל-Persistent Disk אזורי, שמשוכפל באופן סינכרוני לאזורים הראשיים ולאזורי ההמתנה. אם הפסקת שירות באזור משפיעה על המופע הראשי, Cloud SQL מתחיל יתירות כשל, שבמהלכה Persistent Disk מצורף למכונה הווירטואלית במצב המתנה והתנועה מנותבת מחדש.

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

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

פרטים נוספים על האפשרות של זמינות גבוהה מופיעים במאמרי העזרה בנושא זמינות גבוהה ב-Cloud SQL.

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

מומלץ לבדוק את עומס העבודה באמצעות הגדרה שכוללת העתק כדי לקבוע את המגבלה של 'עסקאות בטוחות לשנייה (TPS)', שהיא ה-TPS הגבוה ביותר שלא מצטבר בו פיגור בשכפול. אם עומס העבודה חורג ממגבלת ה-TPS הבטוחה, נוצר פער זמן בשכפול, שמשפיע לרעה על ערכי ה-RPO וה-RTO. ככלל, מומלץ להימנע משימוש בהגדרות קטנות של מופעים (פחות מ-2 ליבות vCPU, פחות מ-100GB דיסקים או PD-HDD), שרגישות לפיגור בשכפול.

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

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

פרטים נוספים על האפשרות של רפליקה חוצה אזורים זמינים במאמרי העזרה בנושא רפליקה חוצה אזורים ב-Cloud SQL.

מידע נוסף על DR ב-Cloud SQL:

• תוכנית התאוששות מאסון (DR) של מסד נתונים של Cloud SQL ל-MySQL
• תוכנית התאוששות מאסון (DR) במסד נתונים של Cloud SQL ל-PostgreSQL
• תוכנית התאוששות מאסון (DR) של מסד נתונים ב-Cloud SQL ל-SQL Server

Cloud Storage

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

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

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

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

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

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

Cloud Translation

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

Compute Engine

‫Compute Engine הוא אחת מהאפשרויות של תשתית כשירות (IaaS) של Google Cloud. היא משתמשת בתשתית העולמית של Google כדי להציע מכונות וירטואליות (ושירותים קשורים) ללקוחות.

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

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

דיירות יחידה

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

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

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

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

רשתות ב-Compute Engine

מידע על הגדרות של זמינות גבוהה לחיבורי Interconnect זמין במסמכים הבאים:

• זמינות של 99.99% ל-Dedicated Interconnect
• זמינות של 99.99% ל-Partner Interconnect

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

עמידות של Cloud Load Balancing

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

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

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

מידע נוסף על בחירת מאזן עומסים זמין במאמרי העזרה בנושא Cloud Load Balancing.

בדיקות קישוריות

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

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

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

Container Registry

‫Container Registry מספק הטמעה של Docker Registry מתארח וניתן להרחבה, שמאחסן באופן מאובטח ופרטי קובצי אימג' של קונטיינרים של Docker. ‫Container Registry מטמיע את HTTP Docker Registry API.

‫Container Registry הוא שירות גלובלי שמאחסן באופן סינכרוני מטא-נתונים של תמונות בצורה יתירה בכמה אזורים ואזורי זמינות כברירת מחדל. תמונות של קונטיינרים מאוחסנות בקטגוריות של Cloud Storage במספר אזורים. באמצעות אסטרטגיית האחסון הזו, Container Registry מספק חוסן (resilience) להפסקות זמניות בשירות אזוריות בכל המקרים, וחוסן (resilience) להפסקות זמניות בשירות אזוריות לכל הנתונים ששוכפלו באופן אסינכרוני למספר אזורים על ידי Cloud Storage.

Database Migration Service

Database Migration Service הוא שירות מנוהל של Google Cloud להעברת מסדי נתונים מספקי ענן אחרים או ממרכזי נתונים מקומיים אל Google Cloud.

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

השירות Database Migration Service תלוי בזמינות של מסדי הנתונים של המקור והיעד שמשמשים לתהליך ההעברה. אם מסד נתונים של מקור או יעד ב-Database Migration Service לא זמין, ההעברות מפסיקות להתקדם, אבל לא מתרחש אובדן של נתוני ליבה של לקוחות או נתוני משימות. העבודות של ההעברה יתחדשו כ שמסדי הנתונים של המקור והיעד יהיו זמינים שוב.

לדוגמה, אתם יכולים להגדיר מסד נתונים של Cloud SQL כיעד עם זמינות גבוהה (HA) כדי לקבל מסד נתונים כיעד שהוא עמיד להפסקות אזוריות.

העברות באמצעות Database Migration Service מתבצעות בשני שלבים:

• קובץ dump מלא: מתבצעת העתקה מלאה של הנתונים מהמקור ליעד בהתאם למפרט של עבודת המיגרציה.
• סימון נתונים שהשתנו (CDC): שכפול של שינויים מצטברים מהמקור ליעד.

הפסקה זמנית בשירות אזורית: אם מתרחשת הפסקה זמנית בשירות אזורית במהלך אחד מהשלבים האלה, עדיין תוכלו לגשת למשאבים ב-Database Migration Service ולנהל אותם. ההשפעה על העברת הנתונים היא כדלקמן:

• גיבוי מלא: העברת הנתונים נכשלת. צריך להפעיל מחדש את משימת ההעברה אחרי שמסד הנתונים של היעד משלים את פעולת היתירות כשל.
• ‫CDC: העברת הנתונים מושהית. משימת המיגרציה מתחדשת באופן אוטומטי אחרי שמסד הנתונים של היעד משלים את פעולת היתירות כשל.

הפסקה זמנית בשירות באזור: Database Migration Service לא תומך במשאבים חוצי-אזורים, ולכן הוא לא עמיד בפני כשלים אזוריים.

Dataflow

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

יש הגבלות:

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

תכנון צינורות עיבוד נתונים של Dataflow לזמינות גבוהה

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

במקרה של הפסקה זמנית בשירות באזור או באזור, אפשר למנוע אובדן נתונים על ידי שימוש חוזר באותו מינוי לנושא Pub/Sub. כדי להבטיח שהרשומות לא יאבדו במהלך הערבוב, Dataflow משתמש בגיבוי במעלה הזרם. כלומר, תהליך העבודה ששולח את הרשומות מנסה שוב את קריאות ה-RPC עד שהוא מקבל אישור חיובי שהרשומה התקבלה ושתוצרי הלוואי של עיבוד הרשומה נשמרים באחסון מתמיד במורד הזרם. בנוסף, Dataflow ממשיך לנסות לבצע קריאות RPC אם העובד ששולח את הרשומות הופך ללא זמין. ניסיון חוזר של קריאות RPC מבטיח שכל רשומה תועבר בדיוק פעם אחת. מידע נוסף על ההבטחה של Dataflow לגבי בדיוק פעם אחת זמין במאמר בדיוק פעם אחת ב-Dataflow.

אם הצינור משתמש בקיבוץ או בחלונות זמן, אפשר להשתמש בפונקציונליות Seek של Pub/Sub או בפונקציונליות Replay של Kafka אחרי הפסקה זמנית בשירות אזורית או אזורית כדי לעבד מחדש רכיבי נתונים ולהגיע לאותן תוצאות חישוב. אם הלוגיקה העסקית שבה נעשה שימוש בצינור לא מסתמכת על נתונים לפני ההפסקה הזמנית בשירות, אפשר לצמצם את אובדן הנתונים של הפלטים של צינורות ל-0 רכיבים. אם הלוגיקה העסקית של צינור הנתונים מסתמכת על נתונים שעברו עיבוד לפני ההפסקה הזמנית בשירות (לדוגמה, אם נעשה שימוש בחלונות הזזה ארוכים, או אם חלון זמן גלובלי מאחסן מונייטורים שהערכים שלהם הולכים וגדלים), אפשר להשתמש בתמונות מצב של Dataflow כדי לשמור את המצב של צינור הנתונים של הסטרימינג ולהתחיל גרסה חדשה של העבודה בלי לאבד את המצב.

Dataproc

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

אפשר ליצור אשכולות Dataproc ב:

• אשכולות Dataproc ב-Compute Engine
• אשכולות Dataproc ב-GKE

אשכולות Dataproc ב-Compute Engine

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

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

אשכולות Dataproc ב-GKE

אשכולות Dataproc ב-GKE יכולים להיות אזוריים או אזוריים.

מידע נוסף על הארכיטקטורה ועל יכולות ה-DR של אשכולות GKE אזוריים ואשכולות GKE אזוריים זמין בקטע Google Kubernetes Engine בהמשך המאמר.

Datastream

‫Datastream הוא שירות ללא שרת (serverless) לסימון נתונים שהשתנו (CDC) וליצירת רפליקות, שמאפשר לכם לסנכרן נתונים בצורה מהימנה ועם השהיה מינימלית. ‫Datastream מספק שכפול של נתונים ממסדי נתונים תפעוליים אל BigQuery ו-Cloud Storage. בנוסף, הוא מציע שילוב יעיל עם תבניות Dataflow כדי ליצור תהליכי עבודה בהתאמה אישית לטעינת נתונים למגוון רחב של יעדים, כמו Cloud SQL ו-Spanner.

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

הפסקה זמנית בשירות אזורית: במקרה של הפסקה זמנית בשירות אזורית, Datastream חוזר לפעול ברגע שהבעיה נפתרת.

Document AI

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

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

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

אימות של נקודות קצה

התכונה 'בדיקת נקודות קצה' מאפשרת לאדמינים ולאנשי מקצוע בתחום אבטחת מידע ליצור מלאי של מכשירים שיש להם גישה לנתונים של הארגון. הפתרון Endpoint Verification מספק גם אמון קריטי במכשירים ובקרת גישה מבוססת-אבטחה כחלק מהפתרון Chrome Enterprise Premium.

מומלץ להשתמש ב-Endpoint Verification כשרוצים לקבל סקירה כללית של מצב האבטחה של מחשבים ניידים ומחשבים נייחים בארגון. כשמשלבים את התכונה 'אימות של נקודות קצה' עם מוצרי Chrome Enterprise Premium, היא עוזרת לאכוף בקרת גישה מפורטת למשאבים שלכם Google Cloud .

אימות נקודות קצה זמין ב- Google Cloud, Cloud Identity,‏ Google Workspace Business ו-Google Workspace Enterprise.

Eventarc

‫Eventarc מספק אירועים שנשלחים באופן אסינכרוני מספקי Google (צד ראשון), מאפליקציות משתמשים (צד שני) ומתוכנות כשירות (צד שלישי) באמצעות שירותים בצימוד חלש שמגיבים לשינויים במצב. השירות מאפשר ללקוחות להגדיר את יעדי האירועים (לדוגמה, מופע של Cloud Run או פונקציית Cloud Run מדור שני) כך שהם יופעלו כשמתרחש אירוע בשירות של ספק אירועים או בקוד של הלקוח.

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

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

שימו לב לנקודות הבאות:

• שירותי Eventarc לקבלת אירועים מצד ראשון ולאספקתם ניתנים על בסיס 'במידת האפשר' ולא מכוסים על ידי RTO/RPO.
• העברת אירועים ב-Eventarc לשירותי Google Kubernetes Engine מתבצעת על בסיס 'כמיטב היכולת' ולא מכוסה על ידי RTO/RPO.

Filestore

החבילות Basic ו-Zonal הן משאבים של תחום מוגדר. הם לא סובלניים לכשל באזור או באזור הפריסה.

מופעי Filestore ברמה אזורית הם משאבים אזוריים. ‫Filestore פועל לפי מדיניות העקביות המחמירה שנדרשת על ידי NFS. כשלקוח כותב נתונים, Filestore לא מחזיר אישור עד שהשינוי נשמר ומשוכפל בשני אזורים, כדי שפעולות קריאה עתידיות יחזירו את הנתונים הנכונים.

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

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

Firestore

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

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

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

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

תובנות לגבי חומת האש

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

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

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

צי

Fleets מאפשרים ללקוחות לנהל כמה אשכולות Kubernetes כקבוצה, ומאפשרים לאדמינים של הפלטפורמה להשתמש בשירותים של כמה אשכולות. לדוגמה, באמצעות צי מכונות אפשר לאדמינים להחיל מדיניות אחידה על כל האשכולות או להגדיר Multi Cluster Ingress.

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

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

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

Google Cloud Armor

‫Cloud Armor עוזר להגן על הפריסות והאפליקציות מפני סוגים שונים של איומים, כולל התקפות DDoS נפחיות והתקפות על אפליקציות כמו פרצות אבטחה XSS‏ (cross-site scripting) והזרקות SQL. ‫Cloud Armor מסנן תנועה לא רצויה במאזני העומסים של Google Cloud ומונע מתנועה כזו להיכנס ל-VPC ולצרוך משאבים. חלק מההגנות האלה הן אוטומטיות. חלק מהשירותים האלה דורשים שתגדירו מדיניות אבטחה ותקשרו אותה לשירותי קצה עורפיים או לאזורים. כללי מדיניות האבטחה של Cloud Armor בהיקף גלובלי חלים על מאזני עומסים גלובליים. מדיניות אבטחה בהיקף אזורי מוחלת על מאזני עומסים אזוריים.

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

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

Google Kubernetes Engine

‫Google Kubernetes Engine ‏ (GKE) מציע שירות מנוהל של Kubernetes, שמפשט את הפריסה של אפליקציות בקונטיינרים ב- Google Cloud. אפשר לבחור בין טופולוגיות של אשכולות אזוריים או אזוריים.

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

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

הפסקה זמנית בשירות אזורי: כדי לצמצם את ההשפעה של הפסקה זמנית בשירות אזורי, צריך לבצע פריסה בכמה אזורים. אף על פי שכרגע לא מוצעת טופולוגיה מרובת אזורים כחלק ממוצר מובנה, לקוחות GKE רבים משתמשים בגישה הזו היום, ואפשר להטמיע אותה באופן ידני. אפשר ליצור כמה אשכולות אזוריים כדי לשכפל את עומסי העבודה בכמה אזורים, ולשלוט בתנועת הגולשים לאשכולות האלה באמצעות multi-cluster ingress.

HA VPN

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

לשערי HA VPN יש שני ממשקים, ולכל ממשק יש כתובת IP ממאגרי כתובות IP נפרדים, שמפוצלים גם מבחינה לוגית וגם מבחינה פיזית בין נקודות נוכחות (PoP) ובין אשכולות שונים, כדי להבטיח יתירות אופטימלית.

הפסקה זמנית בשירות אזורית: במקרה של הפסקה זמנית בשירות אזורית, יכול להיות שלממשק אחד לא תהיה קישוריות, אבל התנועה תופנה לממשק השני באמצעות ניתוב דינמי באמצעות Border Gateway Protocol ‏ (BGP).

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

ניהול זהויות והרשאות גישה

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

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

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

שרת proxy לאימות זהויות (IAP)

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

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

Identity Platform

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

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

הפסקה זמנית בשירות אזורית: במהלך הפסקה זמנית בשירות אזורית, בקשות של Identity Platform לאזור הלא זמין נכשלות באופן זמני, בזמן ש-Identity Platform מסירה את התעבורה מהאזור המושפע. כשאין יותר תעבורה לאזור המושפע, שירות גלובלי לאיזון עומסים בשרתים מנתב את הבקשות לאזור הקרוב ביותר שזמין ותקין. כל הנתונים נשמרים באופן גלובלי, כך שלא יאבדו נתונים.

מילוי בקשות מסוג Knative

‫Knative serving הוא שירות גלובלי שמאפשר ללקוחות להריץ עומסי עבודה (workloads) ללא שרת (serverless) באשכולות של לקוחות. המטרה שלו היא לוודא שעומסי העבודה של Knative Serving נפרסים בצורה תקינה באשכולות של הלקוחות, ושהסטטוס של ההתקנה של Knative Serving משתקף במשאב התכונה של GKE Fleet API. השירות הזה פועל רק כשמתקינים או משדרגים משאבי Knative serving באשכולות של לקוחות. הוא לא מעורב בהרצת עומסי עבודה של אשכולות. אשכולות של לקוחות ששייכים לפרויקטים שבהם מופעל Knative serving מפוזרים בין רפליקות בכמה אזורים וחלוקות משנה – כל אשכול נמצא במעקב של רפליקה אחת.

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

Looker (Google Cloud core)‎

‫Looker (Google Cloud core) היא פלטפורמה לבינה עסקית (BI) שמספקת הקצאה, הגדרה וניהול פשוטים ויעילים של מופע Looker מתוך Google Cloud המסוף. ‫Looker (הליבה של Google Cloud) מאפשר למשתמשים לחקור נתונים, ליצור לוחות בקרה, להגדיר התראות ולשתף דוחות. בנוסף, Looker (הליבה של Google Cloud) מציע סביבת פיתוח משולבת (IDE) למודלים של נתונים, ותכונות הטמעה עשירות וממשקי API למפתחים.

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

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

הפסקה זמנית בשירות אזורית: מכונות Looker (Google Cloud core) באזור המושפע לא זמינות. ‫Looker (Google Cloud Core) מפסיק את כל לוחות הזמנים או השאילתות שפועלים כרגע. אחרי שפותרים את הבעיה, צריך לקבוע מועד חדש להפעלת השאילתות או להוסיף אותן לתור. אפשר ליצור באופן ידני מופעים חדשים באזור אחר. אפשר גם לשחזר את המכונות באמצעות התהליך שמוגדר במאמר ייבוא או ייצוא נתונים ממופע של Looker (Google Cloud core). מומלץ להגדיר תהליך ייצוא נתונים תקופתי כדי להעתיק את הנכסים מראש, למקרה של הפסקה זמנית בשירות אזורית (אירוע לא סביר).

Looker Studio

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

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

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

Memorystore for Memcached

‫Memorystore for Memcached הוא שירות Memcached מנוהל של Google Cloud. ‫Memorystore for Memcached מאפשר ללקוחות ליצור אשכולות Memcached שאפשר להשתמש בהם כמסדי נתונים של זוגות מפתח/ערך עם תפוקה גבוהה לאפליקציות.

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

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

Memorystore ל-Redis

‫Memorystore for Redis הוא שירות Redis מנוהל באופן מלא ל-Google Cloud, שיכול להקל על ניהול פריסות מורכבות של Redis. השירות מציע כרגע 2 מסלולים: מסלול בסיסי ומסלול רגיל. במסלול בסיסי, הפסקה זמנית בשירות אזורית או אזורית תגרום לאובדן נתונים, שנקרא גם ניקוי מלא של מטמון. ב-Standard Tier, הפסקה זמנית בשירות אזורית תגרום לאובדן נתונים. הפסקה זמנית בשירות אזורית עלולה לגרום לאובדן נתונים חלקי במופע של מסלול רגיל, בגלל הרפליקציה האסינכרונית שלו.

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

הפסקה זמנית בשירות אזורית: מופעים ברמת Standard משכפלים באופן אסינכרוני פעולות של מערכי נתונים ממערך הנתונים בצומת הראשי לצומת הרפליקה. כאשר מתרחשת הפסקה זמנית בשירות באזור של הצומת הראשי, הצומת המשוכפל יקודם ויהפוך לצומת הראשי. במהלך המבצע, מתרחש מעבר לגיבוי (failover) ולקוח Redis צריך להתחבר מחדש למופע. אחרי החיבור מחדש, הפעולות יתחדשו. מידע נוסף על זמינות גבוהה של מכונות Memorystore for Redis במסלול הרגיל זמין במאמר בנושא זמינות גבוהה ב-Memorystore for Redis.

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

הפסקת שירות אזורית:‏ Memorystore for Redis הוא מוצר אזורי, ולכן מופע יחיד לא יכול לעמוד בפני כשל אזורי. אתם יכולים לתזמן משימות תקופתיות לייצוא מופע Redis לקטגוריה של Cloud Storage באזור אחר. כשמתרחש שיבוש אזורי, אפשר לשחזר את מופע Redis באזור אחר ממערך הנתונים שייצאתם.

גילוי שירותים מרובי אשכולות ו-Multi Cluster Ingress

שירותים מרובי אשכולות (MCS) ב-GKE מורכבים מכמה רכיבים. הרכיבים כוללים את ה-hub של Google Kubernetes Engine (שמבצע תזמור של כמה אשכולות של Google Kubernetes Engine באמצעות חברות), את האשכולות עצמם ואת בקרי ה-hub של GKE (Multi Cluster Ingress,‏ Multi-Cluster Service Discovery). הבקרה המרכזית מתזמנת את ההגדרה של מאזן העומסים של Compute Engine באמצעות קצה עורפי במספר אשכולות.

במקרה של הפסקה זמנית בשירות באזור מסוים, שירות גילוי מרובה אשכולות ממשיך לטפל בבקשות מאזור אחר או מאזור אחר. במקרה של הפסקה זמנית בשירות אזורית, Multi-Cluster Service Discovery לא מבצע מעבר לגיבוי.

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

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

מידע נוסף על GKE מופיע בקטע 'Google Kubernetes Engine' במאמר תכנון התאוששות מאסון (DR) להפסקות בשירותי תשתיות ענן.

Network Analyzer

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

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

Network Analyzer הוא כלי אבחון ללא רכיבי מישור נתונים. היא לא מעבדת או יוצרת תעבורת נתונים של משתמשים.

הפסקה זמנית בשירות אזורית: שירות Network Analyzer משוכפל באופן גלובלי, והזמינות שלו לא מושפעת מהפסקה זמנית בשירות אזורית.

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

הפסקה זמנית בשירות ברמה האזורית: שירות Network Analyzer משוכפל באופן גלובלי, והזמינות שלו לא מושפעת מהפסקה זמנית בשירות ברמה האזורית.

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

הטופולוגיה של הרשת

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

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

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

מרכז הבקרה לביצועי הענן

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

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

הפסקת חשמל אזורית:

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

הפסקת שירות אזורית:

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

Network Connectivity Center

‫Network Connectivity Center הוא מוצר לניהול קישוריות רשת שמבוסס על ארכיטקטורת רכזת וחישורים. בארכיטקטורה הזו, משאב ניהול מרכזי משמש כמרכז, וכל משאב קישוריות משמש כזרוע. בשלב הזה, רכזות היברידיות תומכות ב-HA VPN, ב-Dedicated Interconnect וב-Partner Interconnect, וגם במכשירי נתב SD-WAN מספקים גדולים של צד שלישי. באמצעות spokes היברידיים של Network Connectivity Center, ארגונים יכולים לקשר Google Cloud עומסי עבודה ושירותים למרכזי נתונים מקומיים, לעננים אחרים ולסניפים שלהם Google Cloud באמצעות הכיסוי הגלובלי של הרשת.

הפסקה זמנית בשירות אזורית: spoke היברידי של Network Connectivity Center עם הגדרת זמינות גבוהה (HA) עמידה בפני כשלים אזוריים, כי מישור הבקרה ומישור נתוני הרשת הם יתירים בכמה אזורים בתוך אזור.

הפסקה זמנית בשירות אזורית: spoke היברידי של Network Connectivity Center הוא משאב אזורי, ולכן הוא לא יכול לעמוד בפני כשל אזורי.

Network Service Tiers

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

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

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

Organization Policy Service

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

הפסקה זמנית בשירות אזורית: כל מדיניות הארגון שנוצרה על ידי Organization Policy Service משוכפלת באופן אסינכרוני במספר אזורים בכל אזור. הנתונים של מדיניות הארגון והפעולות של מישור הבקרה עמידים לכשלים באזורים בתוך כל אזור.

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

רפליקציה של חבילות נתונים

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

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

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

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

Persistent Disk

דיסקים לאחסון מתמיד (persistent disks) זמינים בתצורות אזוריות ותצורות של תחום מוגדר.

דיסקים לאחסון מתמיד של תחום מוגדר מתארחים בתחום אחד. אם התחום של הדיסק לא זמין, ה-Persistent Disk לא זמין עד שהבעיה בתחום תיפתר.

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

כדי לשכפל נתונים באופן אסינכרוני ב-Persistent Disk באזורים שונים, אפשר להשתמש בשכפול אסינכרוני של Persistent Disk (PD Async Replication), שמספק RTO ו-RPO נמוכים של אחסון בלוקים לשחזור פעיל-סביל באזורים שונים. במקרה הלא סביר של הפסקת פעילות אזורית, שכפול אסינכרוני של Persistent Disk מאפשר לבצע יתירות כשל של הנתונים לאזור משני ולהפעיל מחדש את עומס העבודה באזור הזה.

‫Service Health בהתאמה אישית

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

• לוח בקרה במסוף Google Cloud
• ממשק API של שירות
• התראות שניתנות להגדרה
• יומנים שנוצרו ונשלחו אל Cloud Logging

הפסקה זמנית בשירות אזורית: הנתונים מוגשים ממסד נתונים גלובלי ללא תלות במיקומים ספציפיים. אם מתרחש שיבוש בזמינות של אזור, Service Health יכול להגיב לבקשות ולהפנות מחדש את התעבורה לאזורים באותו אזור שעדיין פועלים. ה-API של Service Health יכול להחזיר קריאות ל-API בהצלחה אם הוא יכול לאחזר נתוני אירועים ממסד הנתונים של Service Health.

הפסקה זמנית בשירות אזורית: הנתונים מוגשים ממסד נתונים גלובלי ללא תלות במיקומים ספציפיים. אם יש הפסקה זמנית בשירות אזורית, עדיין אפשר לשלוח בקשות ל-Service Health, אבל יכול להיות שהביצועים יהיו מוגבלים. כשלים אזוריים במיקומים של Logging עשויים להשפיע על משתמשים ב-Service Health שצורכים יומנים או התראות בענן.

התחברות לשירות פרטי

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

נקודות קצה של Private Service Connect לשירותים שפורסמו

נקודת קצה של Private Service Connect מתחברת לשירותים ברשת ה-VPC של ספק השירות באמצעות כלל העברה של Private Service Connect. בעלים של שירות מנוהל מספקים שירות באמצעות קישוריות פרטית לצרכן השירות, על ידי חשיפה של קובץ מצורף יחיד עם שירות. לאחר מכן, צרכן השירות יוכל להקצות כתובת IP וירטואלית מ-VPC לשירות הזה.

הפסקה זמנית בשירות אזורית: תעבורת נתונים של Private Service Connect שמגיעה מתעבורת הנתונים של VM שנוצרו על ידי נקודות קצה (endpoint) של לקוחות VPC צרכנים, עדיין יכולה לגשת לשירותים מנוהלים שנחשפים ברשת ה-VPC הפנימית של בעלים של שירות מנוהל. הגישה הזו אפשרית כי התנועה של Private Service Connect עוברת אוטומטית לשרתי קצה בריאים יותר של שירותים באזור אחר.

הפסקה זמנית בשירות אזורית: Private Service Connect הוא מוצר אזורי. הוא לא עמיד בפני הפסקות זמניות בשירות באזור מסוים. שירותים מנוהלים במספר אזורים יכולים להשיג זמינות גבוהה במהלך הפסקות חשמל אזוריות על ידי הגדרת נקודות קצה של Private Service Connect במספר אזורים.

נקודות קצה של Private Service Connect לממשקי API של Google

נקודת קצה של Private Service Connect מתחברת לממשקי API של Google באמצעות כלל העברה של Private Service Connect. כלל ההעברה הזה מאפשר ללקוחות להשתמש בשמות מותאמים אישית של נקודות קצה עם כתובות ה-IP הפנימיות שלהם.

הפסקה זמנית בשירות אזורית: תנועת הנתונים של Private Service Connect מנקודות קצה של לקוחות VPC עדיין יכולה לגשת ל-Google APIs, כי הקישוריות בין ה-VM לנקודת הקצה תעבור אוטומטית לזמינות חלופית באזור פונקציונלי אחר באותו אזור. ההתאוששות של בקשות שכבר נמצאות בתהליך כשמתחילה הפסקה זמנית בשירות תלויה בערך הזמן הקצוב לתפוגה של TCP ובאופן שבו הלקוח מנסה לשלוח את הבקשה מחדש.

פרטים נוספים זמינים במאמר בנושא שחזור של Compute Engine.

הפסקה זמנית בשירות אזורית: Private Service Connect הוא מוצר אזורי. הוא לא עמיד בפני הפסקות זמניות בשירות באזור מסוים. שירותים מנוהלים במספר אזורים יכולים להשיג זמינות גבוהה במהלך הפסקות חשמל אזוריות על ידי הגדרת נקודות קצה של Private Service Connect במספר אזורים.

מידע נוסף על Private Service Connect זמין בקטע 'נקודות קצה' במאמר סוגי Private Service Connect.

Pub/Sub

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

הפסקה זמנית בשירות אזורית: כשמפרסמים הודעה ב-Pub/Sub, היא נכתבת באופן סינכרוני לאחסון בשני אזורים לפחות בתוך האזור. לכן, אם תחום אחד לא זמין, אין לכך השפעה שגלוי ללקוחות.

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

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

reCAPTCHA

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

במקרה של הפסקה זמנית בשירות אזורית, reCAPTCHA ממשיך לטפל בבקשות מאזור אחר באותו אזור או באזור אחר, ללא הפרעה.

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

Secret Manager

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

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

הפסקה זמנית בשירות אזורית: במקרה של הפסקה זמנית בשירות אזורית, Secret Manager ממשיך לטפל בבקשות מאזור אחר באותו אזור או באזור אחר ללא הפרעה. בכל אזור, Secret Manager תמיד שומר לפחות 2 עותקים באזורים נפרדים (ברוב האזורים, 3 עותקים). כשההשבתה של האזור נפתרת, יתירות מלאה משוחזרת.

הפסקה זמנית בשירות אזורית: במקרה של הפסקה זמנית בשירות אזורית, Secret Manager ממשיך לטפל בבקשות מאזור אחר ללא הפרעה, בהנחה שהנתונים שוכפלו ליותר מאזור אחד (באמצעות רפליקציה אוטומטית או באמצעות רפליקציה שמנוהלת על ידי המשתמש ליותר מאזור אחד). כשההשבתה האזורית מסתיימת, יתבצע שחזור מלא של היתירות.

Security Command Center

‫Security Command Center היא פלטפורמה גלובלית לניהול סיכונים בזמן אמת ב-Google Cloud. הוא מורכב משני רכיבים עיקריים: גלאים וממצאים.

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

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

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

Sensitive Data Protection (כולל DLP API)

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

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

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

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

שימוש בשירות

‫Service Usage API הוא שירות תשתית של Google Cloud שמאפשר לכם להציג ולנהל ממשקי API ושירותים בפרויקטים שלכם ב- Google Cloud . אתם יכולים לראות רשימה של ממשקי API ושירותים שסופקו על ידי Google,‏ Google Cloudויצרנים של צד שלישי, ולנהל אותם. ממשק Service Usage API הוא שירות גלובלי, והוא עמיד להפסקות חשמל אזוריות וגם להפסקות חשמל בתחום (zone). במקרה של הפסקת זמנית בשירות באזור או באזור משנה, Service Usage API ממשיך לטפל בבקשות מאזור משנה אחר באזורים שונים.

מידע נוסף על 'שימוש בשירות' זמין במסמכי העזרה בנושא 'שימוש בשירות'.

המרת דיבור לטקסט (STT)

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

הפסקת חשמל אזורית:

• ‫Speech-to-Text API v1: במהלך הפסקה זמנית בשירות אזורית, Speech-to-Text API גרסה 1 ממשיך לטפל בבקשות מאזור אחר באותו אזור ללא הפרעה. עם זאת, כל המשימות שמופעלות כרגע באזור שנכשלות יאבדו. המשתמשים צריכים לנסות שוב את המשימות שנכשלו, והן ינותבו אוטומטית לאזור זמין.

• ‫Speech-to-Text API v2: במהלך הפסקה זמנית בשירות אזורית, גרסה 2 של Speech-to-Text API ממשיכה לטפל בבקשות מאזור אחר באותו אזור. עם זאת, כל המשימות שמופעלות כרגע באזור שנכשלות יאבדו. המשתמשים צריכים לנסות שוב את המשימות שנכשלו, והן ינותבו אוטומטית לאזור זמין. ה-API של Speech-to-Text מחזיר את הקריאה ל-API רק אחרי שהנתונים מועברים לקוורום באזור. באזורים מסוימים, מאיצי AI ‏ (TPU) זמינים רק באזור אחד. במקרה כזה, הפסקה זמנית בשירות באזור הזה תגרום לכך שהזיהוי של הדיבור ייכשל, אבל לא יהיה אובדן נתונים.

הפסקת שירות אזורית:

• ‫Speech-to-Text API v1: לא מושפע מכשל אזורי כי הוא שירות גלובלי שפועל בכמה אזורים. השירות ימשיך לטפל בבקשות מאזור אחר ללא הפרעה. עם זאת, משימות שמופעלות כרגע באזור שנכשלות יאבדו. המשתמשים צריכים לנסות שוב את המשימות שנכשלו, והן ינותבו אוטומטית לאזור זמין.

• ‫Speech-to-Text API v2:

  • ‫Multi-region Speech-to-Text API version 2, השירות ממשיך לטפל בבקשות מאזור אחר באותו אזור ללא הפרעה.

  • בגרסה 2 של Speech-to-Text API באזור יחיד, השירות מגביל את ביצוע העבודה לאזור המבוקש. גרסה 2 של Speech-to-Text API לא מעבירה תנועה לאזור אחר, והנתונים לא משוכפלים לאזור אחר. במהלך כשל אזורי, גרסה 2 של Speech-to-Text API לא זמינה באזור הזה. עם זאת, הוא יהיה זמין שוב כשההפסקה הזמנית בשירות תיפתר.

Storage Transfer Service

‫Storage Transfer Service מנהל העברות נתונים ממקורות שונים בענן אל Cloud Storage, וגם אל מערכות קבצים, מהן וביניהן.

‫Storage Transfer Service API הוא משאב גלובלי.

השימוש ב-Storage Transfer Service תלוי בזמינות של המקור והיעד של ההעברה. אם מקור או יעד של העברה לא זמינים, ההעברות מפסיקות להתקדם. עם זאת, לא יאבדו נתוני ליבה של לקוחות או נתוני עבודות. ההעברות יתחדשו כשהמקור והיעד יהיו זמינים שוב.

אפשר להשתמש ב-Storage Transfer Service עם סוכן או בלעדיו, באופן הבא:

• העברות ללא סוכן משתמשות בעובדים אזוריים כדי לתזמן את משימות ההעברה.

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

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

במהלך הפסקת שירות, ההתנהגות של Storage Transfer Service היא כדלקמן:

• הפסקת זמינות אזורית: במהלך הפסקת זמינות אזורית, ממשקי ה-API של Storage Transfer Service ממשיכים להיות זמינים, ואפשר להמשיך ליצור משימות העברה. העברת הנתונים נמשכת.

• הפסקה זמנית בשירות אזורית: במהלך הפסקה זמנית בשירות אזורית, ממשקי ה-API של Storage Transfer Service ממשיכים להיות זמינים, ואפשר להמשיך ליצור משימות העברה. אם העובדים של ההעברה נמצאים באזור המושפע, העברת הנתונים תיפסק עד שהאזור יהיה זמין שוב וההעברה תתחדש באופן אוטומטי.

Vertex ML Metadata

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

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

הפסקה זמנית בשירות אזורית: Vertex ML Metadata הוא שירות אזורי. במקרה של הפסקה זמנית בשירות באזור מסוים, Vertex ML Metadata לא יבצע מעבר אוטומטי לאזור אחר.

חיזוי באצווה ב-Vertex AI

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

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

הפסקה זמנית בשירות אזורית: הלקוחות בוחרים את Google Cloud האזור שבו הם רוצים להריץ את משימות חיזוי (Prediction) ב-Batch. הנתונים אף פעם לא משוכפלים בין אזורים. היקף הביצוע של משימת חיזוי באצווה מוגבל לאזור המבוקש, ובקשות לחיזוי אף פעם לא מנותבות לאזור אחר. כשמתרחש כשל אזורי, התכונה 'חיזוי באצווה' לא זמינה באזור הזה. הוא יהיה זמין שוב כשההפסקה הזמנית בשירות תסתיים. מומלץ ללקוחות להשתמש בכמה אזורים להרצת העבודות שלהם. במקרה של הפסקה זמנית בשירות אזורית, צריך להפנות את העבודות לאזור זמין אחר.

מרשם המודלים של Vertex AI

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

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

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

חיזוי אונליין של Vertex AI

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

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

הפסקה זמנית בשירות אזורית: הלקוחות בוחרים את Google Cloud האזור שבו הם רוצים להריץ את המודלים של AI/ML ואת שירותי חיזוי (Prediction) אונליין. הנתונים אף פעם לא משוכפלים בין אזורים. היקף החיזוי אונליין מצמצם את הביצוע של מודל ה-AI/ML לאזור המבוקש, ולעולם לא מעביר בקשות לחיזוי לאזור אחר. כשמתרחש כשל אזורי, שירות החיזוי אונליין לא זמין באזור הזה. הוא יהיה זמין שוב כשההשבתה תיפתר. מומלץ ללקוחות להשתמש במספר אזורים להרצת מודלים של AI/ML. במקרה של הפסקה זמנית בשירות אזורית, מפנים את התנועה הישירה לאזור אחר שזמין.

Vertex AI Pipelines

‫Vertex AI Pipelines הוא שירות של Vertex AI שמאפשר לכם לבצע אוטומציה, מעקב וניהול של תהליכי עבודה של למידת מכונה (ML) באופן חסר שרת. ‫Vertex AI Pipelines נועד לספק זמינות גבוהה והוא מציע הגנה מפני כשלים בתחומים.

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

הפסקה זמנית בשירות אזורית:‏ Vertex AI Pipelines הוא שירות אזורי. במקרה של הפסקה זמנית בשירות אזורית, Vertex AI Pipelines לא יבצע מעבר אוטומטי לאזור אחר. אם מתרחשת הפסקה זמנית בשירות אזורית, מומלץ להריץ את משימות הצינור באזור גיבוי.

חיפוש מבוסס-Vertex AI

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

הפסקה זמנית בשירות אזורית: יכול להיות שלא ניתן יהיה לשחזר נתונים שהועלו אל UserEvents חיפוש מבוסס-Vertex AI בגלל עיכוב ברפליקציה אסינכרונית. נתונים ושירותים אחרים שמוצעים על ידי חיפוש מבוסס-Vertex AI ממשיכים להיות זמינים בגלל יתירות כשל אוטומטית ורפליקציה סינכרונית של נתונים.

אימון של Vertex AI

‫Vertex AI Training מאפשר למשתמשים להריץ משימות אימון בהתאמה אישית בתשתית של Google. ‫Vertex AI Training הוא שירות אזורי, כלומר לקוחות יכולים לבחור את האזור שבו יפעילו את משימות האימון שלהם. עם זאת, לקוחות לא יכולים לבחור את האזורים הספציפיים בתוך האזור הזה. יכול להיות ששירות ההדרכה יבצע איזון עומסים אוטומטי של ביצוע העבודה באזורים שונים בתוך האזור.

הפסקה זמנית בשירות אזורית: Vertex AI Training מאחסן מטא-נתונים של משימת האימון המותאמת אישית. הנתונים האלה מאוחסנים באזור מסוים ונכתבים באופן סינכרוני. הקריאה ל-Vertex AI Training API מוחזרת רק אחרי שהמטא-נתונים האלה מועברים לקוורום באזור. יכול להיות שמשימת האימון תפעל באזור ספציפי. הפסקה זמנית בשירות אזורית מובילה לכשל בהרצת המשימה הנוכחית. אם כן, השירות מנסה שוב להריץ את העבודה באופן אוטומטי על ידי ניתוב שלה לאזור אחר. אם כמה ניסיונות חוזרים נכשלים, סטטוס העבודה מתעדכן ל'נכשל'. בקשות משתמשים עוקבות להפעלת העבודה מנותבות לאזור זמין.

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

ענן וירטואלי פרטי (VPC)

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

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

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

VPC Service Controls

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

הפסקה זמנית בשירות אזורי: מערכת VPC Service Controls ממשיכה לטפל בבקשות מאזור אחר באותו אזור ללא הפרעה.

הפסקה זמנית בשירות אזורית: ממשקי API שהוגדרו לאכיפת מדיניות VPC Service Controls באזור המושפע לא זמינים עד שהאזור יהיה זמין שוב. אם רוצים זמינות גבוהה יותר, מומלץ ללקוחות לפרוס שירותים שמופעלים על ידי VPC Service Controls במספר אזורים.

Workflows

‫Workflows הוא מוצר לתזמור תהליכי עבודה שמאפשר ללקוחות: Google Cloud

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

לקוחות Workflows יכולים לפרוס תהליכי עבודה שמתארים את הלוגיקה העסקית שהם רוצים לבצע, ואז להפעיל את תהליכי העבודה ישירות באמצעות ה-API או באמצעות טריגרים מבוססי-אירועים (נכון לעכשיו, מוגבל ל-Pub/Sub או ל-Eventarc). תהליך העבודה שמופעל יכול לתפעל משתנים, לבצע קריאות HTTP ולאחסן את התוצאות, או להגדיר קריאות חוזרות ולהמתין להפעלה מחדש על ידי שירות אחר.

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

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

הפסקה זמנית בשירות אזורית: Workflows הוא שירות אזורי, ובמקרה של הפסקה זמנית בשירות אזורית, לא תתבצע העברה אוטומטית של נתונים (failover). מומלץ ללקוחות לפרוס את Workflows במספר אזורים אם הם רוצים זמינות גבוהה יותר.

Cloud Service Mesh

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

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

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

Service Directory

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

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

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

הפסקת שירות אזורית: אין ב-Service Directory חוסן מפני הפסקות שירות אזוריות.