הגנה על הנתונים באמצעות שכפול אזורי ואזורי

בוחרים גרסת תיעוד:

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

הארכיטקטורה לדוגמה הזו מתאימה במיוחד לתרחישי השימוש הבאים:

  • אתם צריכים הגנה אזורית בנוסף להגנה ברמת האזור (zone) לאפליקציות קריטיות.

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

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

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

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

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

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

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

ארכיטקטורות של זמינות גבוהה (HA) באזור מסוים והתאוששות מאסון (DR) בכמה אזורים

באיור 1 מוצגת הצעה להגדרת HA ו-DR עם שלושה מסדי נתונים של רפליקות לקריאה בלבד במצב המתנה, בשלושה אזורי זמינות ובשני אזורים.

‫AlloyDB Omni עם גיבויים ואפשרויות לזמינות גבוהה באזורים שונים

איור 1. ‫AlloyDB Omni עם גיבויים ואפשרויות זמינות גבוהה (HA) בין אזורים.

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

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

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

גיבויים של עותקים לקריאה בלבד

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

כמה נקודות שכדאי לחשוב עליהן:

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

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

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

מעבר מארכיטקטורה של HA בלבד לארכיטקטורה של HA ו-DR

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

הטמעה

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

יתרונות

  • הגנה מפני כשלים באזורים ובמכונות
  • הגנה מפני כשלים אזוריים
  • הפחתת ה-RTO כשמתרחשת תקלה אזורית במסד הנתונים

מגבלות

  • אפשר להפחית את ה-RPO לשחזור אזורי באמצעות שכפול סינכרוני, אבל הגישה הזו גורמת לזמן אחזור נוסף בביצועי העסקאות. לצורך DR ורפליקציה לאזור מרוחק, מומלץ להשתמש רק ברפליקציה אסינכרונית.
  • הגדרת סטרימינג של WAL ב-PostgreSQL במצב סינכרוני מונעת אובדן נתונים (RPO=0) במהלך פעולה רגילה או יתירות כשל אופיינית. עם זאת, הגישה הזו לא מגנה מפני אובדן נתונים במצבים ספציפיים של כשל כפול, למשל כשכל המופעים במצב המתנה אובדים או שלא ניתן להגיע אליהם מהמופע הראשי, ומיד לאחר מכן מתבצעת הפעלה מחדש של המופע הראשי.

אפשרויות להגנה על הנתונים

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