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

בחירה של גרסת המסמך:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מאזני עומסים

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

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

זמינות גבוהה

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

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

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

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

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

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

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

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

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

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

פריסות HA שאינן של Kubernetes

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

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

  • ‫Ttl: הזמן המקסימלי שנדרש כדי לקבל נעילה של מסד הנתונים הראשי לפני הפעלת יתירות כשל. ברירת המחדל היא 30 שניות.
  • ‫Loop_wait: משך הזמן להמתנה לפני בדיקה חוזרת. ברירת המחדל היא 10 שניות.
  • ‫Retry_timeout: הזמן הקצוב לתפוגה לפני הורדת הרמה של המכונה הראשית בגלל כשל ברשת. ברירת המחדל היא 10 שניות.

למידע נוסף, ראו ארכיטקטורת זמינות גבוהה של AlloyDB Omni ל-PostgreSQL.

הטמעה

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

יתרונות

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

מגבלות

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

חלופות

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