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

מדוע DR רב-אזורי נשבר ברפליקציה

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

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

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

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

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

מה נותן גיבוי גאוגרפי: אפקט במדדים מדידים

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

המדדים מושכים לכיוונים שונים: רפליקציה סינכרונית ב-PostgreSQL מקצרת את נקודת שמירת הנתונים, אך מוסיפה השהיה לכתיבה; אסינכרונית — מהירה יותר, אבל בעת תקלה הולכות לאיבוד העסקאות האחרונות.

את השירותים ממיינים למחלקות: לתשלומים ולסטטוסים של הזמנות — נקודת שמירה קפדנית, לאנליטיקה ולמטמונים — מהירות.

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

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

מצבי עבודה של DR רב-אזורי: קר, חם, פעיל

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

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

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

שלבי ההטמעה: מביקורת ועד מיתוגי תרגול

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

1. ביקורת תשתית. עורכים מלאי של השירותים, בסיסי הנתונים, התורים, האינטגרציות החיצוניות והקשרים ביניהם, ומשייכים לכל אחד מחלקת קריטיות וזמן שחזור יעד. התוצאה — מפת תלויות שממנה רואים מה אי אפשר להרים בנפרד.
2. סכימת רפליקציה. מחליטים מה מעבירים סינכרונית (נתונים טרנזקציוניים) ומה אסינכרונית (לוגים, מטמון, אנליטיקה), וקובעים את אובדן הנתונים המותר לכל מחלקה. בנפרד בודקים כיצד מתנהג פיגור הרפליקה תחת עומס שיא.
3. הכנת האזור השני. פורסים מתאר זהה מתוך תיאור התשתית: כללי רשת, הרשאות, סודות, קונפיגורציית השירותים. השוואה סדירה תופסת אי-התאמות שמצטברות בתיקונים ידניים.
4. מיתוג תעבורה. מתארים את סדר העלאת השירותים בהתחשב בתלויות ואת אופן העברת העומס דרך ניהול רשומות הדומיין והמאזן. לפני קליטת התעבורה — בדיקת כשירות הצמתים.
5. בדיקת שלמות. משווים נפחים וסכומי ביקורת של הנתונים, מריצים תרחישים קריטיים על הרפליקה, מתעדים אי-התאמות ומחליטים אילו מהן קבילות ואילו חוסמות את המיתוג.
6. מיתוגי תרגול. עורכים לפי הנהלים, עם מדידת הזמן מהאות ועד קליטת העומס והחזרה לאחור. כל תרגול מסתיים בניתוח ובתיקונים לנהלים — הם חיים, ולא שוכבים בתיעוד.
7. מסירה לתפעול. הוראות תורנות, רשימות בדיקה, אוטומציה של שלבים חוזרים ואזורי אחריות מוגדרים.

נהלי המיתוג מתעדכנים אחרי כל תרגול — אחרת הם נפרדים מהתשתית האמיתית כבר אחרי כמה שינויים.

מערך התיעוד, הסכמות והנהלים למיתוג

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

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

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

מקרה בוחן: שחזור בדקות במקום שעות של השבתה

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

מה מצאנו בניתוח

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

מה קרה לאחר מכן

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

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

במה נבדל מיתוג מתוכנן ממיתוג חירום?

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

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

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

הקריטריונים לבחירת המצב מצטמצמים לשלוש בדיקות:

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

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

ספקות טכניים: רפליקציה, השהיות, תרגולים

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

באיזו תדירות נדרשים תרגולים?

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

במה מאומתת שלמות הנתונים?

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

מה עם קונפליקטים בעת החזרת התעבורה?

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

נדון בסכימת הגיבוי שלכם ובמצב המיתוג

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

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

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