תוכנית התאוששות מאסון (DR) באמצעות תמונות מצב של הסביבה

בדף הזה מוסבר איך להשתמש בקובצי snapshot של סביבות לצורך תוכנית התאוששות מאסון (DR).

הגדרות

במדריך הזה אנחנו משתמשים בהגדרות הבאות:

• אסון הוא אירוע שבו Managed Airflow או רכיבים אחרים שחיוניים לפעולה של הסביבה שלכם לא זמינים. האירוע הזה מחייב מעבר לגיבוי חם לאזור אחר ולסביבות של Managed Airflow. הגורם לאסון יכול להיות טבעי או מעשה ידי אדם, כולל השבתה של אזורי Cloud de Confiance by S3NS והפסקות חשמל בתשתית שלכם.
• תוכנית התאוששות מאסון (DR), בהקשר של Managed Airflow, היא תהליך של שחזור הפעולה של הסביבה אחרי אסון. התהליך כולל יצירה מחדש של הסביבה, אולי באזור אחר. מידע נוסף על התאוששות מאסון זמין במדריך לתכנון התאוששות מאסון.
• סביבה ראשית היא סביבת Managed Airflow שרוצים להפעיל בה יכולת DR.
• סביבת מעבר לגיבוי (failover) היא סביבת Managed Airflow שמיועדת להשתלט על פעילויות מהסביבה הראשית.
• תרחיש של DR חם הוא וריאציה של התאוששות מאסון, שבה משתמשים בסביבת מעבר לגיבוי (failover) במצב המתנה, שיוצרים לפני שמתרחש אסון.
• תרחיש של תוכנית התאוששות מאסון (DR) במצב לא פעיל הוא וריאציה של תוכנית התאוששות מאסון, שבה יוצרים סביבת מעבר לגיבוי לאחר התרחשות אסון.
• DR חוצה אזורים הוא וריאציה של DR חם או קר, שבה הסביבה הראשית וסביבת הגיבוי נמצאות באזורים שונים.

מידע על תהליך ההתאוששות מאסון

הליך ההתאוששות מאסון פותר את הבעיה אם הסביבה הראשית שלכם הפכה ללא פעילה (פגומה או לא נגישה מסיבה אחרת) בגלל אסון.

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

התהליך משתמש בסביבת מעבר לגיבוי, ולכן השינויים יחולו כשעוברים מהסביבה הראשית. השינויים בין הסביבה הראשית לבין סביבת הגיבוי כוללים (הרשימה לא מלאה):

• כתובת ה-URL של שרת האינטרנט תהיה שונה. הפעולה הזו משנה את הכתובת של ממשק המשתמש של Airflow ושל נקודת קצה ל-API של Airflow בארכיטקטורת REST.

• כתובת ה-URL של דלי האחסון בסביבה תהיה שונה.

• יכול להיות שיהיה צורך לשנות את ההגדרות של הרשאות הגישה והרשת.

אם אתם משתמשים בתרחיש DR חם, אתם יודעים מראש את הערכים של שרת האינטרנט, כתובות ה-bucket של הסביבה והגדרת הרשת.

לפני שמתחילים

• כדי ליצור תמונות מצב, מסד הנתונים של Airflow צריך להכיל פחות מ-20GB של נתונים.

• כדי ליצור תמונות מצב, המספר הכולל של האובייקטים בתיקיות /dags, /plugins ו-/data בדלי של הסביבה צריך להיות קטן מ-100,000.

• אם אתם משתמשים במנגנון XCom להעברת קבצים, חשוב לוודא שאתם משתמשים בו בהתאם להנחיות של Airflow. העברה של קבצים גדולים או של מספר גדול של קבצים באמצעות XCom משפיעה על הביצועים של מסד הנתונים של Airflow, ויכולה לגרום לכשלים בטעינת תמונות מצב או בשדרוג הסביבה. כדאי לשקול שימוש בחלופות כמו Cloud Storage להעברת נפחים גדולים של נתונים.

סקירה כללית על ההכנה

שני תרחישי ה-DR כוללים את שלבי ההכנה הבאים:

1. יצירת סביבת מעבר לגיבוי

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

2. יוצרים קטגוריה לתמונות מצב.

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

   • בודקים של-DAGs יש גישה למשאבים אזוריים.

3. הגדרת תחזוקה של מסד נתונים

4. הגדרת תמונות מצב מתוזמנות

5. בדיקה של תוכנית ההתאוששות מאסון.

סקירה כללית של תוכנית התאוששות מאסון (DR)

אחרי שמתרחש אסון:

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

שלבי ההכנה

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

יצירת סביבת יתירות כשל

יוצרים סביבה שתשמש כסביבת מעבר לגיבוי.

כדאי לפעול לפי ההנחיות הבאות:

• בסביבה הראשית ובסביבת הגיבוי צריך להשתמש באותה גרסה ובאותו build של Airflow.

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

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

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

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

בדיקת זמינות המשאבים

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

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

יצירת קטגוריית אחסון לתמונות מצב

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

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

אתם יכולים:

• יוצרים קטגוריה באזור אחר.
• יוצרים קטגוריה בכמה אזורים.

הגדרת תחזוקה של מסד נתונים

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

הגדרת תמונות מצב מתוזמנות

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

אפשר ליצור תמונות מצב רק בסביבה תקינה, ולכן צריך לשמור אותן לפני שמתרחש אסון.

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

(אופציונלי) הגדרת מעקב אחר פעולות מתוזמנות של יצירת תמונת מצב

אם קובצי ה-snapshot מתוזמנים בתדירות של לפחות פעם ב-12 שעות, אפשר להשתמש ב-Cloud Monitoring כדי לקבל התראה אם קובץ snapshot לא נוצר באופן אוטומטי.

במקרים של תזמונים בתדירות נמוכה יותר, משתמשים ב-Google Cloud CLI כדי לאמת את התוצאות של פעולות הצילום. איך מוודאים שפעולות השמירה של תמונת המצב מתבצעות

1. נכנסים לדף Monitoring במסוף Cloud de Confiance .

   מעבר למעקב

2. בחלונית הניווט של Monitoring, בוחרים באפשרות notificationsAlerting.
3. אם לא יצרתם ערוצי התראות ואתם רוצים לקבל התראות, לוחצים על Edit Notification Channels (עריכת ערוצי התראות) ומוסיפים את ערוצי ההתראות. אחרי שמוסיפים את הערוצים, חוזרים לדף התראות.
4. בדף Alerting, לוחצים על Create policy.
5. כדי לבחור את המדד, מרחיבים את התפריט Select a metric ומבצעים את הפעולות הבאות:
   1. כדי להגביל את התפריט לרשומות רלוונטיות, מזינים Composer Snapshot בסרגל הסינון. אם לא מוצאים תוצאות אחרי סינון התפריט, משביתים את המתג Show only active resources & metrics.
   2. בשדה Resource type, בוחרים באפשרות Cloud Composer Environment.
   3. בקטגוריה מדד, בוחרים באפשרות סביבה.
   4. בקטע מדד, בוחרים באפשרות מספר יצירת התמונות.
   5. לוחצים על אישור.
6. לוחצים על הוספת מסנן ומשתמשים בתפריטים הנפתחים כדי להוסיף את המסננים הבאים:

   מסנן	גורם השוואה	ערך
   תווית משאב > שם הסביבה	=	שם הסביבה שבה רוצים לעקוב אחרי תמונות מצב מתוזמנות.
   תווית מעקב > תוצאה	=	SUCCEEDED

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

     הערך המומלץ למעקב אחר תמונת מצב מתוזמנת: יום אחד.

   • בקטע Rolling window function (פונקציית חלון נע), בוחרים באפשרות delta (דלתא).
8. לוחצים על הבא.
9. ההגדרות בדף Configure alert trigger קובעות מתי ההתראה תופעל. משלימים את ההגדרות בדף הזה לפי הטבלה הבאה.
   

   שדה	ערך
   Condition type	Threshold
   Alert trigger	Any time series violates
   Threshold position	Below threshold
   Threshold value	מספר התמונות של מצב המערכת שצפויות להינצל בפרק הזמן שהוגדר כחלון הזמן הנע להתראה. כדי לחשב את הערך הזה, משתמשים בנוסחה הבאה: (rolling window in hours / schedule frequency in hours) - 1 הערה: החיסור של 1 שעות בנוסחה נועד להביא בחשבון את הזמנים השונים שבהם מסתיימת יצירת תמונת המצב. כך אפשר למנוע תוצאות חיוביות שגויות אם הצילום העדכני עדיין פועל במהלך בדיקת מעקב. דוגמה: אם משתמשים בחלון הזמן הנע המומלץ של יום אחד, ותדירות התזמון היא פעם בשעתיים, צריך להגדיר את הערך הזה ל-11 (לפי החישוב: 24 / 2 - 1 = 11). אם התזמון פועל בצורה תקינה, אמורות להיות לפחות 11 תמונות מצב בכל חלון של 24 שעות. אם לא, סימן שפעולת צילום תמונת מצב לא הושלמה בהצלחה ו-Cloud Monitoring מפעיל את ההתראה הזו.
   Condition name	השם המותאם אישית של התנאי.

10. לוחצים על הבא.
11. אופציונלי: כדי להוסיף התראות למדיניות ההתראות, לוחצים על ערוצי התראות. בתיבת הדו-שיח, בוחרים ערוץ התראות אחד או יותר מהתפריט ולוחצים על אישור.
12. אופציונלי: מעדכנים את משך הזמן עד לסגירה אוטומטית של אירוע. השדה הזה קובע מתי מערכת Monitoring סוגרת אירועים בהיעדר נתוני מדדים.
13. אופציונלי: לוחצים על תיעוד, ואז מוסיפים את המידע שרוצים לכלול בהודעת ההתראה.
14. לוחצים על שם ההתראה ומזינים שם למדיניות ההתראה.
15. לוחצים על יצירת מדיניות.

בדיקה של תהליך ההתאוששות מאסון

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

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

אימות פעולות השמירה של תמונת המצב

אתם יכולים להשתמש ב-Google Cloud CLI כדי לאחזר את רשימת הפעולות של שמירת תמונת מצב ולוודא שתמונות המצב מוכנות לתרחישי תוכנית התאוששות מאסון (DR).

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

gcloud composer operations list \
    --locations LOCATION \
    --filter="metadata.operationType=SAVE_SNAPSHOT AND 
    metadata.resource=projects/PROJECT_ID/locations/LOCATION/environments/ENVIRONMENT_ID"
    --format yaml

gcloud composer operations list \
    --locations us-central1 \
    --filter="metadata.operationType=SAVE_SNAPSHOT AND 
    metadata.resource=projects/my-project/locations/us-central1/environments/my-environment"
    --format yaml

אחרי שקורה אסון

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

(רק ב-Cold DR) יצירת סביבת מעבר לגיבוי בעת כשל

פועלים לפי ההוראות שבקטע יצירת סביבת יתירות כשל.

הפסקת ההפעלה של DAG בסביבה הראשית

אם אפשר, מפסיקים את ההפעלה של DAG בסביבה הראשית:

• אם עדיין יש גישה לסביבה הראשית, צריך להשהות את כל ה-DAG.
• אם יש גישה לבאקט של הסביבה הראשית, מעבירים את כל ה-DAG מהבאקט של הסביבה או לתיקייה מחוץ ל-/dags בבאקט של הסביבה הראשית.

טעינת תמונת מצב בסביבת הגיבוי למקרה כשל

טוענים תמונת מצב מסביבת המקור לסביבת הגיבוי למקרה כשל.

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

(אם נדרש) משנים את ההגדרות של סביבת הגיבוי למקרה כשל

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

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

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

מחליטים מה לעשות עם הסביבה הראשית

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

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

אם סביבת המקור קיימת, אבל לא פועלת כמו שצריך

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

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

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

• להמשיך להשתמש בסביבת הגיבוי.
• חזרה לסביבה הראשית.

כדי להמשיך להשתמש בסביבת הגיבוי:

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

כדי לחזור לסביבה הראשית:

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

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

• הגדרת צילומי מצב מתוזמנים
• יצירת סביבות