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

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

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

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

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

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

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

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

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

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

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

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

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

מגבלות

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

תרחישי כשל

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

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

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

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

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

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

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

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

המצב ההתחלתי של הדיסק שגיאה ב- המצב החדש של הדיסק השלכות של כשל הפעולה שצריך לבצע

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

Secondary replica: Synced

סטטוס הדיסק: שכפול מלא

‫Disk attached in: primary zone

 אזור ראשי

עותק ראשי: לא מסונכרן או לא זמין

Secondary replica: Synced

סטטוס הדיסק: ירוד

‫Disk attached in: primary zone
  • העותק באזור המשני נשאר תקין ומכיל את נתוני הדיסק העדכניים ביותר.
  • העותק המשוכפל באזור הראשי לא תקין, ולא מובטח שהוא כולל את כל הנתונים בדיסק.
מעבירים את הדיסק ליתירות כשל על ידי חיבור בכוח למכונה וירטואלית באזור המשני התקין.

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

Secondary replica: Synced

סטטוס הדיסק: שכפול מלא

‫Disk attached in: primary zone

 אזור משני

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

עותק משני: לא מסונכרן או לא זמין

סטטוס הדיסק: ירוד

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

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

עותק משני: לא מסונכרן ולא זמין

סטטוס הדיסק: ירוד

‫Disk attached in: primary zone

 אזור ראשי

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

Secondary replica: Out of sync

סטטוס הדיסק: לא זמין

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

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

Secondary replica: Catching up but available

סטטוס הדיסק: השלמת הפערים

‫Disk attached in: primary zone

 אזור ראשי

העתק ראשי: לא זמין

Secondary replica: Catching up but available

סטטוס הדיסק: לא זמין

‫Disk attached in: primary zone
  • שני העותקים האזוריים לא יכולים להציג תעבורה. הדיסק לא יהיה זמין.
  • אם ההפסקה הזמנית בשירות או הכשל בשכפול הם זמניים, הפעולות בדיסק יתחדשו אחרי שהרפליקה הראשית תהיה זמינה שוב.
  • אם ההשבתה האזורית או הכשל בשכפול הם קבועים, אי אפשר להשתמש בדיסק.

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

Secondary replica: Out of sync but available

סטטוס הדיסק: ירוד

‫Disk attached in: primary zone

 אזור ראשי

העתק ראשי: לא זמין

Secondary replica: Out of sync but available

סטטוס הדיסק: לא זמין

‫Disk attached in: primary zone
  • שני העותקים האזוריים לא יכולים להציג תעבורה. הדיסק לא זמין.
  • אם ההפסקה הזמנית בשירות או הכשל בשכפול הם זמניים, הפעולות בדיסק יתחדשו אחרי שהרפליקה הראשית תהיה זמינה שוב.
  • אם ההשבתה האזורית או הכשל בשכפול הם קבועים, אי אפשר להשתמש בדיסק.

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

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

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

מעבר לגיבוי (failover) של דיסק אזורי באמצעות force-attach

אם האזור הראשי נכשל, אפשר לבצע מעבר לגיבוי (failover) שלHyperdisk Balanced High Availability למכונת מחשוב באזור אחר באמצעות פעולת צירוף בכפייה.

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

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

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

המסוף

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

    כניסה לדף VM instances

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

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

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

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

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

  7. כדי לצרף את הדיסק בכוח, מסמנים את תיבת הסימון Force-attach disk (צירוף הדיסק בכוח).

  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 של הדיסק האזורי שיצרתם. כדי לצרף את הדיסק למכונת החישוב החדשה, צריך להשתמש בפרמטר השאילתה forceAttach=true אם הדיסק עדיין מחובר למכונת החישוב הראשית.

POST https://compute.s3nsapis.fr/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: המיקום של מכונת החישוב
  • ‫VM_NAME: השם של מכונת ה-Compute שמוסיפים לה את הדיסק האזורי
  • ‫REGION: האזור שבו נמצא הדיסק האזורי
  • ‫DISK_NAME: השם של הדיסק האזורי

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

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

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

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

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

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

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

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

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

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

    gcloud

    כדי ליצור snapshot באמצעות נקודת הבדיקה לשחזור הרפליקה, משתמשים בפקודה gcloud compute snapshots create . כדי לציין שאתם רוצים ליצור את ה-snapshot באמצעות נקודת ביקורת לשחזור רפליקה, צריך לכלול את הדגל --source-disk-for-recovery-checkpoint. מחריגים את הפרמטרים --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.

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

    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.s3nsapis.fr/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.

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

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

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

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

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

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

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

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

ב-Compute Engine, נקודת הבדיקה לשחזור העותק המשוכפל שלנפח אחסון של 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 הוא למעשה אפס.

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

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