בדף הזה מוסבר על תוכנית התאוששות מאסון (DR) ב-Cloud SQL.
סקירה כללית
ב- Google Cloud, התאוששות מאסון (DR) במסד נתונים היא תהליך שמטרתו לספק המשכיות של העיבוד, במיוחד כשאזור נכשל או הופך ללא זמין. Cloud SQL הוא שירות אזורי (כאשר Cloud SQL מוגדר לזמינות גבוהה (HA)). לכן, אם אזור Google Cloud שמארח מסד נתונים של Cloud SQL הופך ללא זמין, גם מסד הנתונים של Cloud SQL הופך ללא זמין.
כדי להמשיך בעיבוד, עליך להפוך את מסד הנתונים לזמין באזור משני בהקדם האפשרי. תוכנית ה-DR מחייבת הגדרה של רפליקה לקריאה בין אזורים ב-Cloud SQL. אפשר גם לבצע מעבר לגיבוי בעקבות כשל על סמך ייצוא/ייבוא או גיבוי/שחזור, אבל הגישה הזו אורכת זמן רב יותר, במיוחד כשמדובר במסדי נתונים גדולים.
התרחישים העסקיים הבאים הם דוגמאות למצבים שבהם כדאי להגדיר תצורת יתירות כשל בין אזורים:
- הסכם רמת השירות של האפליקציה העסקית גבוה יותר מהסכם רמת השירות האזורי של Cloud SQL (זמינות של 99.99% בהתאם למהדורת Cloud SQL). מעבר לאזור אחר יכול לצמצם את ההשפעה של הפסקה זמנית בשירות.
- כל הרמות של אפליקציית העסק כבר מרובות אזורים, והיא יכולה להמשיך לעבד נתונים כשמתרחש הפסקת חשמל באזור מסוים. הגדרת מעבר אוטומטי לגיבוי באזור אחר עוזרת לשמור על זמינות רציפה של מסד נתונים.
- יעד משך ההתאוששות (RTO) ויעד נקודת ההתאוששות (RPO) הנדרשים הם בדקות ולא בשעות. מעבר לגיבוי באזור אחר מהיר יותר מיצירה מחדש של מסד נתונים.
באופן כללי, יש שתי גרסאות לתהליך DR:
- מסד נתונים עובר אוטומטית לאזור משני. אחרי שמסד הנתונים מוכן ומשמש אפליקציה, הוא הופך למסד הנתונים הראשי החדש ונשאר ככזה.
- מסד נתונים עובר לאזור משני, אבל חוזר לאזור הראשי אחרי שהאזור הראשי משוחזר מהכשל.
בסקירה הכללית הזו של התאוששות מאסון (DR) של מסד נתונים של SQL Google Cloud מתואר המקרה השני – כשמסד נתונים שנכשל משוחזר וחוזר לאזור הראשי. הגרסה הזו של תהליך DR רלוונטית במיוחד למסדי נתונים שצריכים לפעול באזור הראשי בגלל זמן האחזור ברשת, או בגלל שחלק מהמשאבים זמינים רק באזור הראשי. בגרסה הזו, מסד הנתונים פועל באזור המשני רק למשך ההשבתה באזור הראשי.
ארכיטקטורה של תוכנית התאוששות מאסון (DR)
התרשים הבא מציג את הארכיטקטורה המינימלית שתומכת ב-DR של מסד נתונים עבור מופע Cloud SQL עם זמינות גבוהה:
הארכיטקטורה פועלת באופן הבא:
- שני מופעים של Cloud SQL (מופע ראשי ומכונה במצב המתנה) ממוקמים בשני אזורים נפרדים באותו אזור (האזור הראשי). הסנכרון בין המופעים מתבצע באמצעות דיסקים לאחסון מתמיד אזורי.
- מופע אחד של Cloud SQL (הרפליקה לקריאה בין אזורים) נמצא באזור שני (האזור המשני). לצורך DR, העותק לקריאה חוצה-אזורים מוגדר לסנכרון (באמצעות שכפול אסינכרוני) עם המופע הראשי באמצעות הגדרת עותק לקריאה.
למכונות הראשיות ולמכונות ההמתנה יש אותו דיסק אזורי, ולכן המצבים שלהן זהים.
מכיוון שההגדרה הזו משתמשת ברפליקציה אסינכרונית, יכול להיות שרפליקת הקריאה בין האזורים תהיה מאחורי המופע הראשי. כתוצאה מכך, כשמתרחש מעבר לגיבוי (failover), סביר להניח שערך ה-RPO של העותק לקריאה בין אזורים יהיה שונה מאפס.
תהליך התאוששות מאסון (DR)
תהליך ההתאוששות מאסון (DR) מתחיל כשהאזור הראשי לא זמין. כדי להמשיך את העיבוד באזור משני, מפעילים יתירות כשל של המופע הראשי על ידי קידום רפליקת קריאה בין אזורים. תהליך ה-DR קובע את השלבים התפעוליים שצריך לבצע, באופן ידני או אוטומטי, כדי לצמצם את ההשפעה של הכשל באזור וליצור מופע ראשי פעיל באזור משני.
התרשים הבא מציג את תהליך ה-DR:
תהליך ה-DR כולל את השלבים הבאים:
- האזור הראשי (R1), שבו פועל המופע הראשי, הופך ללא זמין.
- צוות התפעול מזהה את האסון ומאשר אותו באופן רשמי, ומחליט אם נדרשת יתירות כשל.
- אם נדרש יתירות כשל, אפשר להעלות בדרגה את הרפליקה לקריאה חוצה אזורים באזור המשני (R2) כדי שתהיה המכונה הראשית החדשה.
- החיבורים של הלקוחות מוגדרים מחדש כדי להמשיך את העיבוד במופע הראשי החדש ולגשת למופע הראשי ב-R2.
התהליך הראשוני הזה יוצר שוב מסד נתונים ראשי פעיל. עם זאת, היא לא יוצרת ארכיטקטורת DR מלאה, שבה למופע הראשי החדש יש מופע המתנה ועותק לקריאה חוצה-אזורים.
תהליך DR מלא מבטיח שהמופע היחיד, המופע הראשי החדש, מופעל ל-HA ויש לו רפליקה לקריאה חוצה-אזורים. תהליך DR מלא מספק גם חזרה לפריסה המקורית באזור הראשי המקורי.
מעבר אוטומטי לאזור משני
תהליך מלא של DR מרחיב את תהליך ה-DR הבסיסי על ידי הוספת שלבים להקמת ארכיטקטורת DR מלאה אחרי מעבר לגיבוי. התרשים הבא מציג ארכיטקטורה מלאה של DR למסד נתונים אחרי המעבר לגיבוי:
תהליך ה-DR המלא של מסד הנתונים כולל את השלבים הבאים:
- האזור הראשי (R1), שבו פועל מסד הנתונים הראשי, לא זמין.
- צוות התפעול מזהה את האסון ומאשר אותו באופן רשמי, ומחליט אם נדרשת יתירות כשל.
- אם נדרש יתירות כשל, אפשר להעלות בדרגה את הרפליקה לקריאה בלבד באזור המשני (R2) למופע הראשי החדש.
- החיבורים של הלקוחות מוגדרים מחדש כדי לגשת למופע הראשי החדש (R2) ולעבד בו.
- מופע חדש של מצב המתנה נוצר ומופעל ב-R2, ונוסף למופע הראשי. מופע הגיבוי נמצא באזור אחר מזה של המופע הראשי. המופע הראשי זמין עכשיו ברמה גבוהה כי נוצר עבורו מופע בהמתנה.
- באזור שלישי (R3), נוצר העתק קריאה חדש בין אזורים ומצורף למופע הראשי. בשלב הזה, ארכיטקטורה מלאה של התאוששות מאסון נוצרת מחדש ופועלת.
אם האזור הראשי המקורי (R1) יהיה זמין לפני שמיישמים את שלב 6, אפשר להציב את העותק לקריאה בכמה אזורים באזור R1 באופן מיידי, במקום באזור R3. במקרה כזה, החזרה לאזור הראשי המקורי (R1) פשוטה יותר ודורשת פחות שלבים.
מניעת מצב של פיצול מוח
אם יש כשל באזור הראשי (R1), זה לא אומר שהמופע הראשי המקורי ומופע ההמתנה שלו מושבתים אוטומטית, מוסרים או הופכים ללא נגישים כש-R1 הופך שוב לזמין. אם R1 יהיה זמין, יכול להיות שהלקוחות יקראו ויכתבו נתונים (גם בטעות) במופע הראשי המקורי. במקרה כזה, יכול להתפתח מצב של פיצול נתונים, שבו חלק מהלקוחות ניגשים לנתונים לא עדכניים במסד הנתונים הראשי הישן, ולקוחות אחרים ניגשים לנתונים עדכניים במסד הנתונים הראשי החדש, מה שמוביל לבעיות בעסק.
כדי להימנע ממצב של פיצול, צריך לוודא שהלקוחות לא יכולים יותר לגשת למופע הראשי המקורי אחרי ש-R1 הופך לזמין. מומלץ להפוך את המופע הראשי המקורי ללא נגיש לפני שהלקוחות מתחילים להשתמש במופע הראשי החדש, ואז למחוק את המופע הראשי המקורי מיד אחרי שהופכים אותו ללא נגיש.
יצירת גיבוי ראשוני אחרי מעבר לגיבוי בעקבות כשל
כשמקדמים את העותק לקריאה בין-אזורי כדי שיהיה הראשי החדש במעבר לגיבוי, יכול להיות שהעסקאות בראשי החדש לא יהיו מסונכרנות באופן מלא עם העסקאות מהראשי המקורי. לכן, העסקאות האלה לא זמינות במופע החדש.
מומלץ לגבות מיד את המכונה הראשית החדשה בתחילת יתירות הכשל ולפני שהלקוחות ניגשים למסד הנתונים. הגיבוי הזה מייצג מצב עקבי וידוע בנקודת המעבר לגיבוי. גיבויים כאלה יכולים להיות חשובים למטרות רגולטוריות או לשחזור למצב מוכר אם לקוחות נתקלים בבעיות בגישה לשרת הראשי החדש.
חזרה לאזור הראשי המקורי
כמו שצוין קודם, במסמך הזה מפורטים השלבים לחזרה לאזור המקורי (R1). יש שתי גרסאות שונות של תהליך החזרה למצב הקודם.
- אם יצרתם את העותק החדש לקריאה חוצה אזורים באזור משני (R3), אתם צריכים ליצור עוד עותק (שני) לקריאה חוצה אזורים באזור הראשי (R1).
- אם יצרתם את העותק החדש לקריאה בין אזורים באזור הראשי (R1), אתם לא צריכים ליצור עוד עותק לקריאה בין אזורים ב-R1.
אחרי שנוצר העתק לקריאה בין-אזורי באזור R1, מופעלת חזרה אוטומטית של מופע Cloud SQL לאזור R1. מכיוון שהמעבר לגיבוי הזה מופעל באופן ידני ולא מבוסס על הפסקת שירות, אתם יכולים לבחור את היום והשעה המתאימים לפעילות התחזוקה הזו.
לכן, כדי להשיג DR מלא עם רפליקה לקריאה ראשית, רפליקה לקריאה במצב המתנה ורפליקה לקריאה חוצה אזורים, צריך לבצע שני מעברים אוטומטיים לשירות גיבוי. המעבר הראשון ליתירות כשל מופעל בגלל ההפסקה (יתירות כשל אמיתית), והמעבר השני ליתירות כשל מחזיר את הפריסה למצב ההתחלתי (חזרה למצב הקודם).
החזרה לאזור הראשי המקורי (R1) כוללת את השלבים הבאים:
- קידום הרפליקה החדשה שנוצרה באזור הראשי המקורי (R1).
- אם המופע שקודם לא נוצר במקור כרפליקה של זמינות גבוהה, צריך להפעיל זמינות גבוהה במופע כדי להגן עליו מפני כשלים אזוריים.
- מגדירים מחדש את האפליקציות כך שיתחברו למופע הראשי החדש.
- יוצרים רפליקה חוצת-אזורים עבור המופע הראשי החדש באזור DR (R2).
- (אופציונלי) כדי להימנע מהפעלת כמה מופעים ראשיים עצמאיים, צריך לנקות את המופע הראשי באזור DR (R2).
תוכנית התאוששות מאסון (DR) מתקדמת
אם אתם משתמשים במהדורת Cloud SQL Enterprise Plus, אתם יכולים ליהנות מ-DR מתקדם. DR מתקדם מפשט את השחזור והחזרה למצב הקודם אחרי מעבר לגיבוי בעקבות כשל חוצה אזורים. כפי שמתואר בתהליך ההתאוששות מאסון, כשמבצעים DR, מסירים את החיבור בין האזור שנכשל במופע הראשי הישן לבין האזור התפעולי במופע הראשי החדש. כדי לשחזר את החיבורים לאזור הפריסה המקורי ולחזור למופע הראשי הישן, צריך לבצע סדרה של שלבי חזרה ידנית.
ב-DR מתקדם, כשמתרחש כשל באזור, אפשר להפעיל מעבר לגיבוי (failover) של העותק המשוכפל. במעבר אוטומטי לגיבוי (failover) של רפליקה, מקדמים רפליקה לקריאה באזור אחר, בדומה לביצוע שחזור רגיל מאסון, אלא שמקדמים את הרפליקה שיועדה לשחזור מאסון (DR). הקידום של העותק המשוכפל לצורך התאוששות מאסון מתבצע באופן מיידי.
במקום להסיר את המופע הראשי הישן, המופע נשאר חלק מטופולוגיית השכפול האסינכרוני של Cloud SQL. בסופו של דבר, המופע הראשי הישן (מופע א') הופך לעותק של העותק שלו לשחזור אחרי אסון (מופע ב'), אחרי שהעותק לשחזור אחרי אסון קודם למופע הראשי החדש.
אחרי שהמופע הראשי הישן (A) הפך למופע משוכפל, אפשר לבצע את השלב האחרון של התאוששות מתקדמת מאסון. אפשר להחזיר את הפריסה של Cloud SQL למצב המקורי ולשחזר את המופע הראשי הישן (A) לתפקיד הקודם שלו כמופע הראשי ללא אובדן נתונים. כדי לבצע שחזור של המופע הראשי הישן (A) ללא אובדן נתונים, אפשר להשתמש בפעולת המעבר. כשמבצעים מעבר לגיבוי, לא מתרחש אובדן נתונים כי המופע הראשי (B) נשאר במצב קריאה בלבד עד שהעותק המשוכפל המיועד להתאוששות מאסון (A) מתעדכן עם המופע הראשי (B). אחרי שעותק השחזור (A) מקבל את כל עדכוני השכפול שלו, עותק השחזור (A) מקבל את התפקיד של המופע הראשי, והמופע הראשי הקודם (B) מוגדר מחדש באופן אוטומטי כעותק השחזור של המופע הראשי הנוכחי (A). המופעים חוזרים לתפקידים המקוריים שלהם, וכך הטופולוגיה חוזרת למצב המקורי שלה לפני ה-DR והמעבר לגיבוי (failover) של העותק המשוכפל.
במהלך DR מתקדם, כל המופעים שמשתתפים בפעולות של מעבר לגיבוי (failover) ומעבר חזרה (switchover) של העותק המשוכפל שומרים על כתובות ה-IP שלהם.
אפשר גם להשתמש בפעולת המעבר של DR מתקדם כדי לבצע תרגילי DR שגרתיים, במטרה לבדוק ולהכין את הטופולוגיה של Cloud SQL למעבר לגיבוי בעקבות כשל חוצה אזורים לפני שמתרחש אסון. אם מתרחש אסון אמיתי, אפשר לבצע מעבר לגיבוי חם של העותק המשוכפל בין אזורים שכבר נבדק.
עותק משוכפל של תוכנית התאוששות מאסון (DR)
כחלק חובה מ-DR מתקדם, העותק המשוכפל של DR כולל את המאפיינים הבאים:
- שכפול DR הוא שכפול לקריאה באזור אחר שמחובר ישירות.
- אפשר לשנות את ייעוד העותק המשוכפל של DR כמה פעמים.
- אפשר לשנות את ייעוד העותק המשוכפל של DR בכל שלב, למעט במהלך פעולת מעבר או פעולת מעבר לגיבוי.
בנוסף, כדי לצמצם את זמן ההשבתה אחרי שימוש ב-DR מתקדם, מומלץ:
- מגדירים את העותק המשוכפל של DR באותו גודל כמו המכונה הראשית.
- אם מופעלת זמינות גבוהה במופע הראשי, מומלץ להפעיל זמינות גבוהה גם בעותק המשוכפל של DR. כדי לעשות זאת, קודם מוודאים שהאפשרות HA מופעלת בשרת הראשי. לאחר מכן, מבצעים את המעבר לגיבוי לשחזור (DR). אחרי שפעולת המעבר מסתיימת, מפעילים את הזמינות הגבוהה במופע הראשי החדש. אחר כך תוכלו לחזור למופע הראשי הקודם. ההגדרה של הזמינות הגבוהה נשמרת בעותק המשוכפל של DR גם אחרי שהוא הופך שוב לעותק משוכפל.
יתירות כשל של רפליקה
לסיכום, יתירות כשל של רפליקה כוללת את האירועים הבאים:
- יוצרים ומקצים רפליקה של DR.
- האזור הראשי לא זמין.
- מבצעים מעבר לגיבוי האוטומטי של העותק המשוכפל ל-DR.
- נקודת הקצה לכתיבה מתעדכנת ומתחילה להצביע על המופע הראשי החדש.
- כשהמופע הראשי המקורי חוזר למצב אונליין, הוא הופך לעותק לקריאה של המופע הראשי החדש.
- אפשר להשתמש בפעולת המעבר כדי לשחזר את הפריסה לטופולוגיה המקורית שלה.
כדי לראות את הפרטים והתרשימים של פעולת מעבר לגיבוי (failover) של העתק, לוחצים על הכרטיסיות הבאות.
הקצאת עותק כפול לשחזור מאסון
לפני שמבצעים יתירות כשל של רפליקה, צריך להקצות רפליקה של DR למופע הראשי, ואולי גם לבדוק את התהליך על ידי ביצוע מעבר.
מתרחשת הפסקה זמנית בשירות
האזור הראשי שבו פועל מסד הנתונים הראשי הופך ללא זמין.
יתירות כשל של רפליקה
אחרי שקובעים שנדרשת תוכנית התאוששות מאסון (DR), מבצעים יתירות כשל של הרפליקה ל-DR רפליקה שמוגדרת באזור אחר.
הרפליקה הייעודית ל-DR בין אזורים הופכת באופן מיידי למופע הראשי ומתחילה לקבל קריאות וכתיבות נכנסות. נקודת הקצה לכתיבה מתעדכנת ומתחילה להצביע על המופע הראשי החדש.
השרת הראשי המקורי הופך לשרת משוכפל
אחרי שהשכפול יקודם, Cloud SQL יבדוק מעת לעת אם המופע הראשי המקורי חזר למצב אונליין. אם המכונה הראשית המקורית מחוברת לאינטרנט, Cloud SQL יוצר מחדש את המכונה הראשית הישנה כרפליקה של המכונה שודרגה. כתובת ה-IP של המופע הראשי הישן נשמרת.
חזרה אוטומטית למקור
אחרי שמבצעים יתירות כשל של רפליקה, אפשר לשחזר את המכונה הראשית באזור המקורי על ידי ביצוע פעולת המעבר, והיפוך של אותו רפליקה של DR וזוג מכונות ראשיות.
מעבר
לסיכום, פעולת מעבר כוללת את האירועים הבאים:
- יוצרים ומקצים רפליקה של DR.
- אתם מתחילים את המעבר.
- כשפיגור הרפליקציה יורד לאפס, המופעים הראשיים החדשים מתחילים לקבל חיבורים נכנסים.
- המופע הראשי הישן הופך לעותק לקריאה.
- אם נעשה שימוש בנקודת קצה לכתיבת DNS, נקודת הקצה לכתיבת DNS מתעדכנת כך שתפנה למופע הראשי החדש.
כדי לראות את הפרטים והתרשימים של פעולת מעבר, לוחצים על הכרטיסיות הבאות.
הקצאת עותק כפול לשחזור מאסון
לפני שמתחילים את פעולת ה *החלפה*, צריך להקצות רפליקה של DR למופע הראשי.
מוודאים שהמופע הראשי תקין. אפשר לבצע מעבר לגיבוי רק אם גם המופע הראשי וגם העותק המשוכפל של ה-DR מחוברים לאינטרנט.
הפעלת מעבר
אתם מתחילים את המעבר. כשמפעילים מעבר לגיבוי, המופע הראשי מפסיק לקבל פעולות כתיבה והופך לקריאה בלבד. Cloud SQL מחכה שהעתקה של יומני העסקאות תתבצע ל-Cloud Storage. הרפליקה שמוגדרת כ-DR מתעדכנת בהתאם למופע הראשי.
כשזמן ההשהיה של הרפליקציה יורד לאפס, העותק המשוכפל של DR מקודם כמופע הראשי החדש. המופע הראשי החדש מתחיל לקבל חיבורים נכנסים, כולל קריאות וכתיבות של אפליקציות.
נקודת הקצה עודכנה
אחרי שמשדרגים את העותק המשוכפל של DR למופע הראשי החדש, נקודת הקצה של כתיבת ה-DNS מתעדכנת ומתחילה להצביע על המופע הראשי החדש. אם אתם לא משתמשים בנקודת קצה של כתיבת DNS, אתם צריכים להגדיר את האפליקציות כך שיפנו לכתובת ה-IP של המופע הראשי החדש.
המופע הראשי הישן מוגדר מחדש כרפליקה לקריאה.
האפשרות PITR מופעלת באופן אוטומטי עבור המופע הראשי החדש. אפשר לבצע PITR רק אחרי הגיבוי האוטומטי הראשון.
נקודת קצה לכתיבה
נקודת קצה לכתיבה היא שם גלובלי של Domain Name Service (DNS) שמקבל באופן אוטומטי את כתובת ה-IP של המופע הראשי הנוכחי. נקודת הקצה הזו מפנה מחדש חיבורים נכנסים למופע הראשי החדש באופן אוטומטי במקרה של יתירות כשל או מעבר לגיבוי פעיל של רפליקה. אפשר להשתמש בנקודת הקצה לכתיבה במחרוזת חיבור SQL במקום בכתובת IP. שימוש בנקודת קצה לכתיבה מאפשר לכם להימנע משינויים בחיבור האפליקציה במקרה של הפסקת חשמל באזור.
כדי להשתמש בנקודת קצה לכתיבה, צריך להפעיל את Cloud DNS API בפרויקט שבו יוצרים את המכונה הראשית של מהדורת Cloud SQL Enterprise Plus או שיש בו מכונה ראשית כזו. כשיוצרים מכונה במהדורת Cloud SQL Enterprise Plus עם כתובת IP פרטית ורשתות מורשות, מערכת Cloud SQL יוצרת באופן אוטומטי נקודת קצה (endpoint) לכתיבה עבור המכונה. אם כבר יש לכם מופע ראשי במהדורת Cloud SQL Enterprise Plus, Cloud SQL ייצור את נקודת הקצה לכתיבה כשתיצרו את העותק המשוכפל לצורך התאוששות מאסון (עותק משוכפל חוצה אזורים שאתם מגדירים למופע הראשי). אם המופע הראשי משתנה בגלל פעולת מעבר או פעולת מעבר לגיבוי, Cloud SQL מקצה את נקודת הקצה של הכתיבה לגיבוי לשחזור מאסון כשהגיבוי לשחזור מאסון הופך למופע הראשי החדש.
מידע נוסף על שימוש בנקודת קצה לכתיבה כדי להתחבר למופע זמין במאמר בנושא התחברות למופע באמצעות נקודת קצה לכתיבה.
המאמרים הבאים
- שימוש בתכונות מתקדמות של התאוששות מאסון (DR).
- כדאי להעמיק את הקריאה ולהכיר דוגמאות לארכיטקטורות, תרשימים, מדריכים ושיטות מומלצות בנושאי Google Cloud. כל אלה זמינים במרכז הארכיטקטורה של Cloud.