ניהול כשלים בדיסקים אזוריים

דיסקים לאחסון מתמיד אזורי ו-Hyperdisk Balanced High Availability הם אפשרויות אחסון שמספקות שכפול סינכרוני של נתונים בין שני אזורים באזור. אתם יכולים להשתמש ב-Regional Persistent Disk או ב-Hyperdisk Balanced High Availability כאבן בניין כשאתם מטמיעים שירותים של זמינות גבוהה (HA) ב-Compute Engine.

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

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

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

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

  gcloud

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

     gcloud init

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

     הערה: אם התקנתם את ה-CLI של gcloud, השתמשו בפקודה gcloud components update כדי לבדוק אם הגרסה העדכנית מותקנת.
• הגדרת אזור ותחום כברירת מחדל

REST

כדי להשתמש בסביבת פיתוח מקומית בדוגמאות של API בארכיטקטורת REST שבדף הזה, צריך להשתמש בפרטי הכניסה שאתם נותנים ל-CLI של gcloud.

התקינו את ה-CLI של Google Cloud.

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

מידע נוסף מופיע במאמר אימות לשימוש ב-REST במסמכי האימות של Google Cloud .

התפקידים הנדרשים

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

• כדי להעביר נתונים של דיסק אזורי באמצעות נקודת שחזור של רפליקה: Compute Instance Admin (v1) (roles/compute.instanceAdmin.v1) בפרויקט
• כדי לראות מדדים של דיסקים אזוריים (אחת מהאפשרויות הבאות):
  • צפייה במעקב (roles/monitoring.viewer) בפרויקט
  • עריכת מעקב (roles/monitoring.editor) בפרויקט

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

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

ההרשאות הנדרשות

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

• כדי ליצור קובץ snapshot רגיל מנקודת השחזור של הרפליקה:
  • compute.snapshots.create בפרויקט
  • compute.disks.createSnapshot בדיסק
• כדי ליצור דיסק אזורי חדש מ-snapshot רגיל: compute.disks.create בפרויקט שבו רוצים ליצור את הדיסק החדש
• כדי להעביר מכונות וירטואליות לדיסק החדש:
  • compute.instances.attachDisk במכונה הווירטואלית
  • ‫compute.disks.use permission בדיסק החדש שנוצר

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

מגבלות

אי אפשר להשתמש בפעולות force-attach בדיסקים שנמצאים במצב של גישה לכתיבה מכמה מקומות.

תרחישי כשל

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

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

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

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

כשלים באזורים

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

• יש הפסקת חשמל אזורית.
• הרפליקה חווה איטיות מוגזמת בפעולות כתיבה.

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

שוכפל באופן מלא ירודה התעדכנות

רפליקה משנית: מסונכרן עותק משני: מתעדכן רפליקה משנית: לא מסונכרנת

אזור ראשי אזור משני

ניקוי הכול

המצב הראשוני של הדיסק	כשל ב	המצב החדש של הדיסק	ההשלכות של אי-עמידה בדרישות	מה צריך לעשות
רפליקה ראשית: מסונכרן רפליקה משנית: מסונכרנת סטטוס הדיסק: שכפול מלא הדיסק מחובר ב: אזור ראשי	האזור הראשי	רפליקה ראשית: לא מסונכרן או לא זמין רפליקה משנית: מסונכרנת סטטוס הדיסק: ירוד ‫Disk attached in: primary zone	הרפליקה באזור המשני נשארת תקינה ומכילה את הנתונים העדכניים ביותר בדיסק. הרפליקה באזור הראשי לא תקינה, ולא בטוח שכל הנתונים בדיסק נמצאים בה.	מעבירים את הדיסק למצב יתירות כשל באמצעות צירוף מאולץ למכונה וירטואלית באזור המשני התקין.
רפליקה ראשית: מסונכרן רפליקה משנית: מסונכרנת סטטוס הדיסק: שכפול מלא ‫Disk attached in: primary zone	אזור משני	רפליקה ראשית: מסונכרנת רפליקה משנית: לא מסונכרן או לא זמין סטטוס הדיסק: ירוד ‫Disk attached in: primary zone	העותק המשוכפל באזור הראשי נשאר תקין ומכיל את הנתונים העדכניים ביותר מהדיסק. הרפליקה באזור המשני לא תקינה, ולא מובטח שהיא מכילה את כל הנתונים בדיסק.	לא נדרשת פעולה. ‫Compute Engine יסנכרן מחדש את הרפליקה הלא תקינה באזור המשני אחרי שהיא תהיה זמינה שוב.
רפליקה ראשית: מסונכרנת רפליקה משנית: לא מסונכרנת ולא זמינה סטטוס הדיסק: ירוד ‫Disk attached in: primary zone	אזור ראשי	רפליקה ראשית: מסונכרנת אבל לא זמינה רפליקה משנית: לא מסונכרנת סטטוס הדיסק: לא זמין הדיסק מחובר ב: אזור ראשי	שני העותקים האזוריים לא זמינים ולא יכולים לשרת תעבורה. הדיסק לא זמין. אם ההשבתה האזורית או הכשל בשכפול הם זמניים, לא יאבדו נתונים. אם ההשבתה האזורית או הכשל בשכפול הם קבועים, כל הנתונים שנכתבו בעותק התקין בזמן שהדיסק היה במצב של ירידה בביצועים אבדו לתמיד.	‫Google ממליצה להשתמש בתמונת מצב רגילה קיימת וליצור דיסק חדש כדי לשחזר את הנתונים. מומלץ לגבות את הדיסקים האזוריים באופן קבוע באמצעות תמונות מצב רגילות.
רפליקה ראשית: מסונכרנת רפליקה משנית: מתעדכן אבל זמין סטטוס הדיסק: מתעדכן ‫Disk attached in: primary zone	אזור ראשי	רפליקה ראשית: לא זמינה רפליקה משנית: מתעדכן אבל זמין סטטוס הדיסק: לא זמין ‫Disk attached in: primary zone	שני העותקים האזוריים לא יכולים לשרת תעבורה. הדיסק לא יהיה זמין. אם ההפסקה הזמנית בשירות או הכשל בשכפול הם זמניים, הפעולות בדיסק יתחדשו אחרי שהרפליקה הראשית תהיה זמינה שוב. אם ההשבתה האזורית או הכשל בשכפול הם קבועים, אי אפשר להשתמש בדיסק.	‫Google ממליצה להשתמש בתמונת מצב רגילה קיימת וליצור דיסק חדש כדי לשחזר את הנתונים. מומלץ לגבות את הדיסק האזורי באופן קבוע באמצעות תמונות מצב רגילות. אם אין לכם תמונות מצב רגילות קיימות של הדיסק, עדיין תוכלו לשחזר את הנתונים מהרפליקה שלא מסונכרנת באמצעות נקודת הבדיקה לשחזור הרפליקה.
רפליקה ראשית: מסונכרנת רפליקה משנית: לא מסונכרן אבל זמין סטטוס הדיסק: פגום ‫Disk attached in: primary zone	אזור ראשי	רפליקה ראשית: לא זמין רפליקה משנית: לא מסונכרן אבל זמין סטטוס הדיסק: לא זמין ‫Disk attached in: primary zone	שני העותקים האזוריים לא יכולים לשרת תעבורה. הדיסק לא זמין. אם ההפסקה הזמנית בשירות או הכשל בשכפול הם זמניים, הפעולות בדיסק יתחדשו אחרי שהעותק הראשי יהיה זמין שוב. אם ההשבתה האזורית או הכשל בשכפול הם קבועים, אי אפשר להשתמש בדיסק.	‫Google ממליצה להשתמש בתמונת מצב רגילה קיימת וליצור דיסק חדש כדי לשחזר את הנתונים. מומלץ לגבות את הדיסק האזורי באופן קבוע באמצעות תמונות מצב רגילות. אם אין לכם תמונות מצב רגילות קיימות של הדיסק, עדיין תוכלו לשחזר את הנתונים מהעותק המשוכפל שלא מסונכרן באמצעות נקודת הבדיקה לשחזור העותק המשוכפל.

כשלים באפליקציות ובמכונות וירטואליות

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

קטגוריית הכשל (וההסתברות)	סוגי כשלים	פעולה
כשל באפליקציה (גבוה)	אפליקציות שלא מגיבות כשל בגלל פעולות אדמיניסטרטיביות באפליקציה (לדוגמה, שדרוג) טעות אנוש (לדוגמה, הגדרה שגויה של פרמטרים כמו אישור SSL או רשימות ACL)	מישור הבקרה של האפליקציה יכול להפעיל מעבר לגיבוי (failover) על סמך ערכי הסף של בדיקת התקינות.
כשל ב-VM (בינוני)	כשל בתשתית או בחומרה המכונה הווירטואלית לא מגיבה בגלל תחרות על משאבי המעבד (CPU), הפרעה ברשת הביניים	בדרך כלל, המכונות הווירטואליות מתקנות את עצמן באופן אוטומטי. מישור הבקרה של האפליקציה יכול להפעיל יתירות כשל על סמך ערכי הסף של בדיקת התקינות.
פגם באפליקציה (נמוך-בינוני)	פגיעה בנתוני האפליקציה (לדוגמה, בגלל באגים באפליקציה או שדרוג לא מוצלח של מערכת ההפעלה)	שחזור האפליקציה: אם יש כלים לשחזור ספציפיים לאפליקציה, כדאי לנסות אותם. לדוגמה, פגם בדף של מסד נתונים מסוג MySQL. שחזור מארכיון של שכפול לוגי. לדוגמה, עותק לקריאה או ארכיון של יומן לוגי כמו ארכיון רציף של PostgreSQL.

מעבר לגיבוי במקרה של כשל בדיסק אזורי באמצעות force-attach

אם האזור הראשי נכשל, אתם יכולים להעביר את ה-Regional Persistent Disk או את נפח ה-Hyperdisk Balanced High Availability ל-Compute Engine באזור אחר באמצעות פעולת צירוף מאולץ.

אם יש כשל באזור הראשי, יכול להיות שלא תוכלו לנתק את הדיסק מהמכונה כי אי אפשר להגיע למכונה כדי לבצע את פעולת הניתוק. צירוף מאולץ מאפשר לצרף נפח שלPersistent Disk אזורי או Hyperdisk Balanced High Availability למכונה של Compute Engine, גם אם הנפח הזה מצורף למכונה אחרת.

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

כדי לצרף בכוח דיסק קיים למופע של Compute, בוחרים אחת מהמשימות הבאות:

המסוף

1. נכנסים לדף VM instances.

   כניסה לדף VM instances

2. בוחרים את הפרויקט הרצוי.

3. לוחצים על שם המכונה שרוצים לשנות.

4. בדף הפרטים, לוחצים על עריכה.

5. בקטע Additional disks (דיסקים נוספים), לוחצים על Attach additional disk (צירוף דיסק נוסף).

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

7. כדי לצרף את הדיסק בכוח, מסמנים את תיבת הסימון צירוף הדיסק בכוח.

8. לוחצים על סיום ואז על שמירה.

אפשר לבצע את אותם השלבים כדי force-attach דיסק למופע המקורי של Compute אחרי שהבעיה נפתרה.

gcloud

ב-CLI של gcloud, משתמשים בפקודה instances attach-disk כדי לצרף את דיסק הרפליקה למכונת חישוב. מוסיפים את הדגל --disk-scope ומגדירים אותו לערך regional.

gcloud compute instances attach-disk VM_NAME \
    --disk DISK_NAME --disk-scope regional \
    --force-attach

מחליפים את מה שכתוב בשדות הבאים:

• ‫VM_NAME: השם של מופע Compute חדש באזור
• ‫DISK_NAME: השם של הדיסק האזורי

אחרי שforce-attach אתם את הדיסק, אתם יכולים להתקין את מערכות הקבצים בדיסק, אם צריך. מכונת ה-Compute יכולה להשתמש בדיסק שמצורף בכוח כדי להמשיך בפעולות קריאה וכתיבה בדיסק.

REST

יוצרים בקשת POST לשיטה compute.instances.attachDisk וכוללים בה את כתובת ה-URL של הדיסק האזורי שיצרתם. כדי לצרף את הדיסק למופע החדש של Compute, צריך להשתמש בפרמטר השאילתה forceAttach=true אם הדיסק עדיין מחובר למופע הראשי של Compute.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instances/VM_NAME/attachDisk?forceAttach=true

{
 "source": "projects/PROJECT_ID/regions/REGION/disks/DISK_NAME"
}

מחליפים את מה שכתוב בשדות הבאים:

• ‫PROJECT_ID: מזהה הפרויקט
• ‫ZONE: המיקום של מכונת ה-Compute
• ‫VM_NAME: השם של מכונת ה-Compute שמוסיפים לה את הדיסק האזורי
• ‫REGION: האזור שבו נמצא הדיסק האזורי
• ‫DISK_NAME: השם של הדיסק האזורי

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

הערה: אי אפשר לצרף את הדיסק אם הוא חורג ממגבלות הגודל והצירוף של Hyperdisk במכונה של Compute Engine.

מעבר אוטומטי של דיסק אתחול למכונה משנית

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

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

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

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

נקודת שמירה לשחזור רפליקה מייצגת את הנקודה העדכנית ביותר בזמן שבה יש עקביות במקרה של קריסה של נפח Regional Persistent Disk או Hyperdisk Balanced High Availability ששוכפל באופן מלא. ב-Compute Engine אפשר ליצור תמונות מצב רגילות מנקודת הבדיקה לשחזור העותק המשוכפל של דיסקים אזוריים פגומים.

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

חשוב: אם הדיסק לא זמין, Google ממליצה להשתמש תמיד בתמונות מצב רגילות קיימות כדי ליצור Persistent Disk אזורי חדש או נפח אחסון של Hyperdisk Balanced High Availability ולשחזר את נתוני הדיסק. אפשר ליצור קובצי snapshot רגילים מנקודת ביקורת רק אם אין קובצי snapshot רגילים זמינים.

הליך להעברה ולשחזור של נתונים בדיסק

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

1. יוצרים snapshot רגיל של דיסק האחסון המתמיד האזורי או של נפח האחסון Hyperdisk Balanced High Availability שנפגעו מנקודת השחזור של העותק המשוכפל.

   אפשר ליצור את ה-snapshot הרגיל של דיסק מנקודת השחזור של הרפליקה שלו באמצעות ה-CLI של gcloud או REST בלבד.

   gcloud

   כדי ליצור snapshot באמצעות נקודת הבדיקה לשחזור הרפליקה, משתמשים בפקודה gcloud compute snapshots create . מוסיפים את הדגל --source-disk-for-recovery-checkpoint כדי לציין שרוצים ליצור את קובץ ה-snapshot באמצעות נקודת ביקורת לשחזור רפליקה. מחריגים את הפרמטרים --source-disk ו---source-disk-region.

   gcloud compute snapshots create SNAPSHOT_NAME \
       --source-disk-for-recovery-checkpoint=SOURCE_DISK \
       --source-disk-for-recovery-checkpoint-region=SOURCE_REGION \
       --storage-location=STORAGE_LOCATION \
       --snapshot-type=SNAPSHOT_TYPE
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫DESTINATION_PROJECT_ID: מזהה הפרויקט שבו רוצים ליצור את התמונה.
   • ‫SNAPSHOT_NAME: שם לקובץ ה-snapshot.
   • ‫SOURCE_DISK: השם או הנתיב המלא של דיסק המקור שרוצים להשתמש בו כדי ליצור את ה-snapshot. כדי לציין את הנתיב המלא של דיסק מקור, משתמשים בתחביר הבא:

       projects/SOURCE_PROJECT_ID/regions/SOURCE_REGION/disks/SOURCE_DISK_NAME
       

     אם מציינים את הנתיב המלא לדיסק המקור, אפשר להחריג את הדגל --source-disk-for-recovery-checkpoint-region. אם מציינים רק את שם הדיסק, צריך לכלול את הדגל הזה.

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

   • ‫SOURCE_PROJECT_ID: מזהה הפרויקט של דיסק המקור שרוצים להשתמש בנקודת הבדיקה שלו כדי ליצור את ה-Snapshot.
   • ‫SOURCE_REGION: האזור של דיסק המקור שרוצים להשתמש בנקודת הבדיקה שלו כדי ליצור את ה-snapshot.
   • ‫SOURCE_DISK_NAME: השם של דיסק המקור שאת נקודת הבדיקה שלו רוצים להשתמש כדי ליצור את קובץ ה-snapshot.
   • ‫STORAGE_LOCATION: אופציונלי: ה-Cloud Storage במספר אזורים או האזור של Cloud Storage שבו רוצים לאחסן את ה-snapshot. אפשר לציין רק מיקום אחסון אחד.
     משתמשים בדגל --storage-location רק אם רוצים לשנות את מיקום האחסון שמוגדר כברירת מחדל או בהתאמה אישית בהגדרות של התמונה.
   • ‫SNAPSHOT_TYPE: סוג ה-snapshot, ‏STANDARD או ARCHIVE. אם לא מציינים סוג תמונת מצב, נוצרת תמונת מצב STANDARD.

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

   The device is fully replicated and should not create snapshots out of a recovery checkpoint. Please
   create regular snapshots instead.
   

   REST

   כדי ליצור קובץ snapshot באמצעות נקודת הבדיקה לשחזור הרפליקה, שולחים בקשת POST אל ה-method‏ snapshots.insert. צריך להחריג את הפרמטר sourceDisk ולכלול במקומו את הפרמטר sourceDiskForRecoveryCheckpoint כדי לציין שרוצים ליצור את התמונה באמצעות נקודת הבדיקה.

   POST https://compute.googleapis.com/compute/v1/projects/DESTINATION_PROJECT_ID/global/snapshots
   
   {
     "name": "SNAPSHOT_NAME",
     "sourceDiskForRecoveryCheckpoint": "projects/SOURCE_PROJECT_ID/regions/SOURCE_REGION/disks/SOURCE_DISK_NAME",
     "storageLocations": "STORAGE_LOCATION",
     "snapshotType": "SNAPSHOT_TYPE"
   }
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫DESTINATION_PROJECT_ID: מזהה הפרויקט שבו רוצים ליצור את התמונה.
   • ‫SNAPSHOT_NAME: שם לקובץ ה-snapshot.
   • ‫SOURCE_DISK: השם או הנתיב המלא של דיסק המקור שרוצים להשתמש בו כדי ליצור את ה-snapshot. כדי לציין את הנתיב המלא של דיסק מקור, משתמשים בתחביר הבא:

       projects/SOURCE_PROJECT_ID/regions/SOURCE_REGION/disks/SOURCE_DISK_NAME
       

     אם מציינים את הנתיב המלא לדיסק המקור, אפשר להחריג את הדגל --source-disk-for-recovery-checkpoint-region. אם מציינים רק את שם הדיסק, צריך לכלול את הדגל הזה.

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

   • ‫SOURCE_PROJECT_ID: מזהה הפרויקט של דיסק המקור שרוצים להשתמש בנקודת הבדיקה שלו כדי ליצור את ה-Snapshot.
   • ‫SOURCE_REGION: האזור של דיסק המקור שרוצים להשתמש בנקודת הבדיקה שלו כדי ליצור את ה-snapshot.
   • ‫SOURCE_DISK_NAME: השם של דיסק המקור שאת נקודת הבדיקה שלו רוצים להשתמש כדי ליצור את קובץ ה-snapshot.
   • ‫STORAGE_LOCATION: אופציונלי: ה-Cloud Storage במספר אזורים או האזור של Cloud Storage שבו רוצים לאחסן את ה-snapshot. אפשר לציין רק מיקום אחסון אחד.
     משתמשים בפרמטר storageLocations רק אם רוצים לשנות את מיקום האחסון שמוגדר כברירת מחדל או מותאם אישית בהגדרות של התמונה.
   • ‫SNAPSHOT_TYPE: סוג קובץ ה-snapshot, ‏ STANDARD או ARCHIVE. אם לא מציינים סוג של תמונת מצב, נוצרת תמונת מצב מסוג STANDARD.

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

   The device is fully replicated and should not create snapshots out of a recovery checkpoint. Please
   create regular snapshots instead.
   

2. יוצרים דיסק חדש Regional Persistent Disk או Hyperdisk Balanced High Availability באמצעות קובץ ה-snapshot הזה. כשיוצרים את הדיסק החדש, משחזרים את כל הנתונים מנקודת הבדיקה האחרונה לשחזור הרפליקה, על ידי שחזור הנתונים לדיסק החדש מה-snapshot. הוראות מפורטות זמינות במאמר בנושא יצירת אירוע חדש עם דיסק אתחול אזורי.

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

אחרי שמשחזרים ומעבירים את הנתונים בדיסק ואת המכונות הווירטואליות לדיסק החדש מסוגRegional Persistent Disk או Hyperdisk Balanced High Availability, אפשר להמשיך בפעולות.

קביעת ה-RPO שסופק על ידי נקודת הבדיקה לשחזור הרפליקה

בקטע הזה מוסבר איך לקבוע את ה-RPO שסופק על ידי נקודת הבדיקה האחרונה לשחזור רפליקה של Persistent Disk אזורי או של נפח Hyperdisk Balanced High Availability.

העותקים המשוכפלים של אזור מסוים מסונכרנים באופן מלא

ב-Compute Engine, נקודת הבדיקה לשחזור העותק שלPersistent Disk אזורי אונפח אחסון של Hyperdisk Balanced High Availability מתעדכנת כל 15 דקות בערך. כתוצאה מכך, כשהרפליקות האזוריות מסונכרנות באופן מלא, ה-RPO הוא בערך 15 דקות.

הרפליקות האזוריות לא מסונכרנות

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

• חותמת הזמן האחרונה של מצב הדיסק ששוכפל באופן מלא: אפשר לקבל את המידע הזה באמצעות נתוני Cloud Monitoring של המדד replica_state של הדיסק האזורי. כדי לדעת מתי העותק הרפליקה יצא מסינכרון, בודקים את replica_state נתוני המדדים של העותק הרפליקה שלא מסונכרן. מכיוון ש-Compute Engine מרענן את נקודת הבדיקה של הדיסק כל 15 דקות, יכול להיות שהרענון האחרון של נקודת הבדיקה היה לפני כ-15 דקות מחותמת הזמן הזו.
• חותמת הזמן של פעולת הכתיבה האחרונה: אפשר לקבל את המידע הזה באמצעות נתוני Cloud Monitoring של מדד write_ops_count של הדיסק האזורי. כדי לקבוע את פעולת הכתיבה האחרונה בדיסק, צריך לבדוק את נתוני המדדים write_ops_count.

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

Approximate RPO provided by the latest checkpoint =
(Most recent write operation timestamp - (Most recent timestamp of the fully
replicated disk state - 15 minutes))

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

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