הגנה על נתונים באמצעות אחסון בכמה אזורים

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

המסמך הזה מיועד לקבוצות הקהלים הבאות:

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

מידע נוסף מופיע במאמרי העזרה בנושא קהלים ב-GDC עם פער אבטחה.

שכפול אחסון לצורך תוכנית התאוששות מאסון (DR)

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

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

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

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

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

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

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

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

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

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

מגבלות

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

המאמרים הבאים