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

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

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

תרחישים לדוגמה

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

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

איך פועלת ארכיטקטורת ההפניה

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

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

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

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

אפשרויות לזמינות גבוהה

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

הערה: Patroni ו-HAProxy הם כלים לשימוש לא מסחרי של צד שלישי, והם תואמים ל-AlloyDB Omni.

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

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

מאזני עומסים

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

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

זמינות גבוהה

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

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

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

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

גיבויים והגדרת זמינות גבוהה

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

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

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

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

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

פריסות HA ב-Kubernetes

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

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

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

  • ‫healthcheckPeriodSeconds: הזמן בין בדיקות התקינות. ברירת המחדל היא 30 שניות.
  • autoFailoverTriggerThreshold: מספר הבדיקות הרצופות של תקינות המערכת שנכשלו לפני הפעלת מעבר לגיבוי. ערך ברירת המחדל הוא 3.

מידע נוסף זמין במאמר בנושא ניהול זמינות גבוהה ב-Kubernetes.

הטמעה

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

יתרונות

  • הגנה מפני כשלים במופע.
  • הגנה מפני כשלים בשרת.
  • הגנה מפני כשלים באזורים.
  • זמן ההתאוששות (RTO) קצר משמעותית בהשוואה לזמינות רגילה.

מגבלות

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

חלופות

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