תכנון תוכנית התאוששות מאסון (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 'מובנים'.

תוכנית התאוששות מאסון (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 ודיסק אחסון מתמיד. אם אתם מתכננים להשתמש במשאבים אזוריים, תצטרכו לבצע בעצמכם את הרכבת המשאבים על ידי תכנון, בנייה ובדיקה של מעבר לגיבוי ושחזור בין משאבים אזוריים שנמצאים בכמה אזורים. למשל:

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

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

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

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

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

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

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

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

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

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

מערכת שתוכננה היטב יכולה לענות על השאלה: "מה קורה כשבאזור או בתחום (zone) יש הפסקה זמנית בשירות למשך דקה, 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 יכולה האפליקציה להיות תלויה?

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

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 12hrs RPO 12hrs

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

דוגמאות לדפוסי ארכיטקטורה לארגון לדוגמה Co – הפסקת פעילות אזורית חוסן

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 שעות:

• מאזן עומסים פנימי משמש כדי לספק למשתמשים נקודת גישה שניתנת להרחבה, ומאפשר מעבר אוטומטי ליתירות כשל באזור אחר. למרות שזמן ההתאוששות הוא 12 שעות, שינויים ידניים בכתובות IP או אפילו עדכוני DNS יכולים להימשך יותר זמן מהצפוי.
• קבוצת מופעי מכונה מנוהלים אזורית מוגדרת עם מספר תחומים (zones) אבל עם מינימום משאבים. כך מתבצעת אופטימיזציה של העלויות, אבל עדיין אפשר להרחיב במהירות את המכונות הווירטואליות בתחום (zone) הגיבוי.
• הגדרת זמינות גבוהה ב-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 יכולים להימשך יותר מהצפוי.
• קבוצת מופעי מכונה מנוהלים אזורית לשכבת החישוב של התצוגה החזותית של הנתונים מוגדרת עם מספר תחומים (zones) אבל עם מינימום משאבים. כך מתבצעת אופטימיזציה של העלויות, אבל עדיין אפשר להרחיב במהירות את המכונות הווירטואליות.
• ‫Cloud Storage אזורי משמש כשכבת ביניים להעברה ראשונית של נתונים, ומספק עמידות אוטומטית לאזורים.
• ‫Dataflow משמש לחילוץ נתונים מ-Cloud Storage ולשינוי שלהם לפני הטעינה שלהם ל-BigQuery. במקרה של הפסקת חשמל באזור, זהו תהליך חסר מצב שאפשר להפעיל מחדש באזור אחר.
• BigQuery מספק את ה-backend של מחסן הנתונים עבור ממשק הקצה של הדמיית הנתונים. במקרה של הפסקה זמנית בשירות באזור, כל הנתונים שאבדו יוטמעו מחדש מ-Cloud Storage.

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

• מאזן עומסים בכל אזור משמש כנקודת גישה שניתנת להרחבה עבור המשתמשים. משתמשים ב-Cloud DNS כדי לספק יכולת יתירות כשל אזורית מתואמת אבל ידנית, כי התשתית באזור 2 תהיה זמינה רק במקרה של הפסקה זמנית בשירות באזור.
• קבוצת מופעי מכונה מנוהלים אזורית לשכבת החישוב של ויזואליזציית הנתונים מוגדרת עם מספר תחומים (zones) אבל עם מינימום משאבים. אי אפשר לגשת אליה עד שמגדירים מחדש את מאזן העומסים (LB), אבל לא נדרשת התערבות ידנית.
• ‫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

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

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

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

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

Access Context Manager

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

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

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

Access Transparency

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

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

‫AlloyDB ל-PostgreSQL

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

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

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

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

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

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

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

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

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

Anti Money Laundering AI

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

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

הפסקת שירות אזורית: הלקוחות בוחרים את האזור ב-Google Cloud שבו הם רוצים ליצור את משאבי ה-AI למניעת הלבנת הון. הנתונים אף פעם לא משוכפלים בין אזורים. תעבורת הנתונים של הלקוחות אף פעם לא מנותבת לאזור אחר על ידי ה-AI למניעת הלבנת הון. במקרה של כשל אזורי, ה-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 מאחסן מטא נתונים של המשימות באופן אזורי, וכותב באופן סינכרוני בתחומים (zones) בתוך האזור. המשימות מופעלות בתחום (zone) ספציפי, כפי שנבחר על ידי Cloud Load Balancing.

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

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

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

Batch

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

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

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

הגנה על נתונים מפני איומים ב-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 הוא מחסן נתונים בענן שפועל במודל ללא שרת (serverless), עם יכולת התאמה רחבה וחסכוניות, שמתוכנן להשגת גמישות עסקית. ‫BigQuery תומך בסוגי המיקומים הבאים למערכי נתונים של משתמשים:

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

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

Binary Authorization

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

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

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

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

‫Google Security Operations SIEM (שהוא חלק מ-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), ולהנפיק אישורים בהיקף גדול בצורה גמישה.

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

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

חיוב ב-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, הבקשה מועברת לשרתי המקור, כמו מכונות וירטואליות (VM) בעורף או קטגוריות של Cloud Storage, שבהם מאוחסן התוכן המקורי.

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

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

Managed Service for Apache Airflow

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

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

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

• אפשר ליצור סביבות Managed Airflow 2 ו-Managed Airflow 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, או באופן חיצוני באמצעות כלי תזמור, כמו Managed Airflow. כדי לשחזר הגדרות של צינורות נתונים בזמן ריצה, צריך לגבות את צינורות הנתונים וההגדרות, כמו פלאגינים ולוחות זמנים. במקרה של הפסקת שירות, אפשר להשתמש בגיבוי כדי לשכפל מופע באזור או באזור זמין שלא הושפעו.

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

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

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

Cloud Deploy

‫Cloud Deploy מספק פריסה רציפה של עומסי עבודה בשירותי זמן ריצה כמו 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 ממרכזי הנתונים המקומיים שלהם, באמצעות כבלים פיזיים שמחוברים לנקודת הפירינג של Google.

‫Cloud Interconnect מספק ללקוחות הסכם רמת שירות (SLA) של 99.9% אם הם מקצים קישורים לשני אזורי זמינות של קצה הרשת (EAD) באזור מטרופוליטני. הסכם רמת שירות של 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 מנתב יומנים לתחומים (zones) אחרים באזור. בדרך כלל, יומנים שמנותבים על ידי נתב היומנים אל 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 מספק גם תרגום של כתובת רשת של יעד (destination 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 הוא שירות אזורי, כלומר הלקוחות יכולים לבחור את האזור אבל לא את האזורים שמרכיבים אותו. הנתונים והתנועה מאוזנים באופן אוטומטי בין אזורים בתוך אזור. ההתאמה של מופעי מאגר מתבצעת באופן אוטומטי כדי לעמוד בדרישות של התנועה הנכנסת, והעומס מתחלק בין האזורים לפי הצורך. בכל אזור יש מתזמן שמספק את ההתאמה האוטומטית לעומס הזו לכל אזור. בנוסף, המערכת מודעת לעומס שמתקבל באזורים אחרים, ותקצה קיבולת נוספת באזור כדי לאפשר התמודדות עם כשלים אזוריים.

אם אתם משתמשים ב-GPU ב-Cloud Run, יש לכם אפשרות להשבית את יתירות האזורים בשירות, ובמקום זאת להשתמש באמינות של 'הכי טוב שאפשר' במקרה של הפסקה זמנית בשירות באזור, בעלות נמוכה יותר. פרטים נוספים זמינים במאמר בנושא אפשרויות יתירות אזוריות של GPU.

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

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

Cloud Shell

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

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

המכונות ב-Compute Engine שמגבות את השירות הן משאבים של תחום מוגדר, ולכן במקרה של הפסקה זמנית בשירות בתחום (zone), 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 Server. ב-Cloud SQL נעשה שימוש במכונות וירטואליות מנוהלות של Compute Engine כדי להריץ את תוכנת מסד הנתונים. הוא מציע הגדרה של זמינות גבוהה ליתירות אזורית, כדי להגן על מסד הנתונים מפני הפסקה זמנית בשירות באזור. אפשר להקצות רפליקות באזורים שונים כדי להגן על מסד הנתונים מפני הפסקה זמנית בשירות באזור. מכיוון שהמוצר גם מציע אפשרות אזורית שלא עמידה להפסקת חשמל באזור או באזור, חשוב לבחור את ההגדרה של זמינות גבוהה, רפליקות חוצות אזורים או את שניהם.

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

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

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

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

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

מומלץ לבדוק את עומס העבודה עם הגדרה שכוללת רפליקה ב-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
• תוכנית התאוששות מאסון של מסד נתונים ב-Cloud SQL ל-SQL Server

Cloud Storage

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

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

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

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

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

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

Cloud Translation

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

Compute Engine

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

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

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

דיירות יחידה

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

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

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

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

רשתות ב-Compute Engine

מידע על הגדרות של זמינות גבוהה לחיבורי Cloud 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 מספק עמידות להפסקות זמניות בשירות בכל המקרים, ועמידות להפסקות זמניות בשירות באזורים לכל הנתונים ששוכפלו באופן אסינכרוני למספר אזורים על ידי Cloud Storage.

Database Migration Service

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

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

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

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

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

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

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

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

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

Dataflow

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

ההגבלות הבאות חלות:

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

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

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

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

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

Managed Service for Apache Spark

‫Managed Service for Apache Spark מספק יכולות של עיבוד נתונים בסטרימינג ועיבוד נתונים ברצף (batch processing). הארכיטקטורה של Managed Service for Apache Spark מבוססת על מישור בקרה אזורי שמאפשר למשתמשים לנהל אשכולות של Managed Service for Apache Spark. מישור הבקרה לא תלוי באזור ספציפי באזור נתון. לכן, במהלך הפסקת חשמל אזורית, הגישה ל-API של Managed Service for Apache Spark נשמרת, כולל האפשרות ליצור אשכולות חדשים.

אפשר ליצור אשכולות של Managed Service for Apache Spark ב:

• שירות מנוהל לאשכולות Apache Spark ב-Compute Engine
• אשכולות של Apache Spark בשירות מנוהל ב-GKE

שירות מנוהל לאשכולות Apache Spark ב-Compute Engine

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

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

שירות מנוהל לאשכולות Apache Spark ב-GKE

אשכולות של Managed Service for Apache Spark ב-GKE יכולים להיות אזוריים או של תחום מוגדר.

מידע נוסף על הארכיטקטורה ועל יכולות ה-DR של אשכולות אזוריים ואשכולות אזוריים ב-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 הוא מוצר אזורי. הלקוחות יכולים לבחור את האזור, אבל לא את התחומים (zones) בתוך האזור הזה. הנתונים ותעבורת הנתונים מאוזנים אוטומטית בין התחומים (zones) באזור. השרתים מותאמים אוטומטית כדי לעמוד בתעבורת הנתונים הנכנסת, והעומס עליהם מאוזן בין התחומים (zones) לפי הצורך. בכל תחום (zone) יש מתזמן שמספק את ההתאמה האוטומטית לעומס (autoscaling) הזו לכל תחום (zone). המתזמן גם מודע לעומס שמתקבל בתחומים (zones) אחרים, ומקצה קיבולת נוספת בתחום (zone) כדי לאפשר התמודדות עם כשלים בתחום (zone).

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

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

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

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

מומלץ להשתמש ב-Endpoint Verification כשרוצים לקבל סקירה כללית של מצב האבטחה של מחשבים ניידים ומחשבים נייחים בארגון. כשמשלבים את 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 מאחסן מטא-נתונים שקשורים לטריגרים. הנתונים האלה מאוחסנים באזור מסוים ונכתבים באופן סינכרוני. ה-API של Eventarc שיוצר ומנהל טריגרים וערוצים מחזיר את קריאת ה-API רק אחרי שהנתונים עברו אישור של קוורום באזור מסוים. מכיוון שהנתונים מאוחסנים באזור מסוים, פעולות במישור הנתונים לא מושפעות מכשלים אזוריים. במקרה של כשל אזורי, התנועה מנותבת אוטומטית לאזורים אחרים. שירותי Eventarc לקבלה ולמסירה של אירועים מצד שני ומצד שלישי משוכפלים באזורים שונים. השירותים האלה מפוזרים באזורים שונים. בקשות לאזורים לא זמינים מטופלות אוטומטית על ידי אזורים זמינים באזור.

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

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

• שירותי Eventarc לקבלת אירועים מאינטראקציה ישירה (First-Party) ולאספקתם ניתנים על בסיס 'כמיטב יכולתנו' ולא מכוסים על ידי 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

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

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

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

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

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

צי

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

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

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

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

Google Cloud Armor

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

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

הפסקה זמנית בשירות אזורית: במקרה של הפסקה זמנית בשירות אזורית, מאזני עומסים גלובליים של Google Cloud מפנים את תעבורת הנתונים לאזורים אחרים שבהם יש שרתי קצה עורפי (backend instance) תקינים. ההגנה של Cloud Armor זמינה מיד אחרי יתירות הכשל של תעבורת הנתונים, כי מדיניות האבטחה הגלובלית של Cloud Armor משוכפלת באופן סינכרוני לכל האזורים. כדי להבטיח חוסן (resilience) בפני כשלים אזוריים, צריך להגדיר מדיניות אבטחה אזורית של 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 מופצת באופן אזורי, ובקשות לאזורים לא זמינים מטופלות באופן אוטומטי מאזורים זמינים אחרים באזור.

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

Identity Platform

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

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

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

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

‫Knative serving הוא שירות גלובלי שמאפשר ללקוחות להריץ עומסי עבודה ללא שרתים באשכולות של לקוחות. המטרה שלו היא לוודא שעומסי העבודה של 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 core) מציע סביבת פיתוח משולבת (IDE) למודלים של נתונים, ותכונות הטמעה עשירות וממשקי API למפתחים.

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

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

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

Data Studio

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

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

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

Memorystore for Memcached

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

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

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

Memorystore for Redis

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

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

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

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

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

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

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

במקרה של הפסקת שירות בתחום, Multi-Cluster Service Discovery ממשיך לטפל בבקשות מתחום או מאזור אחר. במקרה של הפסקת שירות באזור, 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 משוכפל באופן גלובלי, והזמינות שלו לא מושפעת מהפסקה זמנית בשירות ברמה האזורית.

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

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

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

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

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

לוח בקרה לביצועי הענן

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

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

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

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

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

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

Network Connectivity Center

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

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

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

Network Service Tiers

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

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

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

Organization Policy Service

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

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

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

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

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

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

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

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

Persistent Disk

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

נקודות קצה של Private Service Connect ל-Google APIs

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

הפסקה זמנית בשירות אזורית: תעבורת נתונים של Private Service Connect מנקודות קצה של לקוחות VPC לצרכן עדיין יכולה לגשת לממשקי Google API, כי הקישוריות בין המכונה הווירטואלית לנקודת הקצה תעבור אוטומטית לזמינות חלופית לתחום (zone) פונקציונלי אחר באותו אזור. התאוששות של בקשות שכבר נמצאות בתהליך כשמתחיל הפסקה זמנית בשירות תלויה בערך הזמן הקצוב לתפוגה של 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

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

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

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

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

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

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

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

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

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

• ‫Speech-to-Text API v2:

  • ‫Speech-to-Text API גרסה 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. תחזיות באצווה הן שירות אזורי. הלקוחות יכולים לבחור את האזור שבו הם מריצים את העבודות, אבל לא את האזורים הספציפיים בתוך האזור הזה. שירות התחזיות באצווה מבצע איזון עומסים אוטומטי של העבודה בין אזורים שונים בתוך האזור שנבחר.

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

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

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

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

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

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

חיזוי אונליין ב-Vertex AI

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

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

הפסקת שירות אזורית: הלקוחות בוחרים את Google Cloud האזור שבו הם רוצים להפעיל את המודלים של AI/ML ואת שירותי החיזוי אונליין. הנתונים אף פעם לא משוכפלים בין אזורים. התחזיות אונליין מגבילות את ההרצה של מודל ה-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 לא יבצע מעבר אוטומטי לאזור אחר. אם מתרחשת הפסקה זמנית בשירות אזורי, מומלץ להריץ את משימות הפייפליין באזור גיבוי.

חיפוש סוכנים

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

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

אימון של Vertex AI

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

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

הפסקת חשמל אזורית: הלקוחות בוחרים את Google Cloud האזור שבו הם רוצים להריץ את משימות האימון. הנתונים אף פעם לא משוכפלים בין אזורים. היקף הביצוע של משימות ב-Vertex AI Training מוגבל לאזור המבוקש, ומשימות אימון אף פעם לא מנותבות לאזור אחר. במקרה של כשל אזורי, שירות 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 מאוחסן קוד המקור של תהליכי העבודה, יחד עם ערכי המשתנים ותגובות ה-HTTP שמתקבלות מתהליכי עבודה שפועלים. קוד המקור מאוחסן באזורים ונכתב באופן סינכרוני: ה-API של מישור הבקרה מחזיר נתונים רק אחרי שהמטא-נתונים האלה מועברים לקוורום באזור. גם משתנים ותוצאות של HTTP מאוחסנים באופן אזורי ונכתבים באופן סינכרוני, לפחות כל חמש שניות.

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

הפסקה זמנית בשירות באזור מסוים: Workflows הוא שירות אזורי, ולכן במקרה של הפסקה זמנית בשירות באזור מסוים, לא תתבצע יתירות כשל. מומלץ ללקוחות לפרוס את 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 תמיד שומר על מספר רפליקות. אחרי שההשבתה האזורית תיפתר, תתבצע שחזור מלא של היתירות.

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