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

בחירת גרסה של מאמר העזרה:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הטמעה

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

יתרונות

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

מגבלות

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

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

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