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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מאזני עומסים

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

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

זמינות גבוהה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הטמעה

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

יתרונות

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

מגבלות

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

חלופות

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