שיטות מומלצות לשימוש בקובצי snapshot של דיסקים ב-Compute Engine

אפשר ליצור תמונות מצב של Persistent Disk ו-Google Cloud Hyperdisk בכל שלב, אבל כדי ליצור תמונות מצב מהר יותר ובאמינות גבוהה יותר, מומלץ לפעול לפי השיטות המומלצות הבאות.

שיקולי אבטחה

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

  • compute.snapshots.useReadOnly
  • compute.instantSnapshots.useReadOnly

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

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

הכנה ליצירת תמונות מצב עקביות

אם יוצרים snapshot של Persistent Disk או Hyperdisk בזמן שהאפליקציה פועלת, יכול להיות שה-snapshot לא יתעד כתיבות בהמתנה שנמצאות במעבר מהזיכרון לדיסק. בגלל חוסר העקביות הזה, יכול להיות שתמונת המצב לא תשקף את המצב המדויק של האפליקציה בזמן שצילמתם את תמונת המצב. בתרחיש הזה, התמונה נחשבת עקבית במקרה של קריסה כי היא מתעדת את מצב האפליקציה כאילו המכונה קרסה בזמן צילום התמונה.

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

יצירת קובצי snapshot שתואמים למצב קריסה

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

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

  1. צילום תמונת מצב בזמן שהאפליקציות פועלות, בהנחה שיהיו חוסר עקביות בנתוני האפליקציות.
  2. מוודאים שאפשר לשחזר את עומס העבודה למצב אפליקציה תקין מהתמונה.
  3. בהתאם לשלב הקודם, שומרים או מוחקים את קובץ ה-snapshot.

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

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

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

  • מופעים שמשתמשים ב-Hyperdisk: אמצעי האחסון של Hyperdisk לא תומכים ב-guest-flush או בשירות Volume Shadow Copy (VSS). כדי ליצור תמונות מצב עקביות של אפליקציות לנפחי Hyperdisk, צריך להשהות את האפליקציה באופן ידני לפני שיוצרים את תמונת המצב. מידע נוסף זמין במאמר בנושא יצירה ידנית של תמונות מצב עקביות של אפליקציות.

  • מכונות של Windows Server שמשתמשות ב-Persistent Disk: לדיסקים שמצורפים למכונות של Windows Server, משתמשים בתמונות מצב של VSS.

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

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

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

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

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

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

סטטוס הפעילות סטטוס המשאב של תמונת המצב
PENDING עדיין לא קיים משאב של תמונת מצב.
RUNNING ‫CREATING או UPLOADING

CREATING: יצירת תמונת המצב עדיין לא הסתיימה. ‫
‫UPLOADING: תמונת מצב נוצרה אבל עדיין לא נשמרה ב-Cloud Storage.
DONE ‫FAILED או READY.

אל תשתמשו בתמונות מצב זמניות רגילות

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

מגבלות על תדירות הצילום

יש מגבלות על התדירות שבה אפשר ליצור snapshot של דיסק.

יצירת קובצי snapshot מ-Persistent Disk או מ-Hyperdisk

אפשר ליצור תמונת מצב של דיסק בודד עד 6 פעמים בכל 60 דקות.

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

"code": "RESOURCE_OPERATION_RATE_EXCEEDED",
"message": "Operation rate exceeded for resource 'projects/project-id/zones/zone-id/disks/disk-name'.
Too frequent operations from the source resource."

המגבלה הזו חלה על הפעולות הבאות:

המגבלה הזו לא חלה על הפעולות הבאות:

מומלץ ליצור קובץ Snapshot של הדיסק פעם בשעה. מומלץ להימנע מצילום תמונות מצב בתדירות גבוהה יותר. הדרך הקלה ביותר לעשות זאת היא להגדיר תזמון של קובצי snapshot.

יצירת דיסקים אזוריים חדשים מ-snapshots

אפשר ליצור דיסק אחסון מתמיד (Persistent Disk) או Hyperdisk אזורי חדש מתוך snapshot נתון לכל אזור יעד, עד 6 פעמים בכל 60 דקות. אזור היעד הוא מיקום האחסון של הדיסק החדש שנוצר מקובץ ה-snapshot. ‏Google Cloud לא מבטיח שתוכלו ליצור דיסקים מקובץ snapshot בקצב מהיר יותר, אבל יכול להיות שתוכלו ליצור דיסקים בתדירות גבוהה יותר אם לא יצרתם דיסקים מקובץ ה-snapshot בשעה האחרונה.

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

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

"code": "RESOURCE_OPERATION_RATE_EXCEEDED",
"message": "Operation rate exceeded for resource 'projects/project-id/global/snapshots/snapshot-name'.
Too frequent operations from the source resource."

המגבלה הזו חלה על הפעולות הבאות:

המגבלה הזו לא חלה על הפעולות הבאות:

  • יצירת דיסקים חדשים של אחסון מתמיד (persistent disks) אזורי מתוך קובץ snapshot.
  • יצירת דיסקים חדשים של אחסון מתמיד (persistent disk) אזוריים או של אזור מסוים באמצעות תמונה כמקור.

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

  1. יצירת תמונה מקובץ ה-Snapshot.
  2. Create disks from the image.

במקרה של דיסקים שאינם דיסקי אתחול, פועלים לפי ההוראות ליצירת דיסקי אחסון מתמידים (persistent disk) מתמונת הדיסק ומשתמשים בשלבים הבאים:

  • במסוף Google Cloud , בוחרים באפשרות Image (תמונה) בתור סוג המקור של הדיסק.
  • ב-CLI של gcloud, משתמשים בדגל image.
  • אם משתמשים ב-REST, משתמשים בפרמטר sourceImage.

שימוש בתמונות מצב קיימות כנקודת התחלה לתמונות מצב עתידיות

אם יש לכם קובצי snapshot קיימים של דיסק (Persistent Disk או Hyperdisk), המערכת משתמשת בהם באופן אוטומטי כבסיס לכל קובצי ה-snapshot הבאים שתיצרו מאותו דיסק.

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

תזמון של תמונות מצב בשעות שאינן שעות שיא

אם אתם מתזמנים יצירה של תמונות מצב קבועות לדיסקים שלכם (Persistent Disk או Hyperdisk), אתם יכולים לקצר את הזמן שנדרש ליצירת כל תמונת מצב על ידי יצירת תמונות מצב בשעות השפל, אם אפשר.

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

ארגון הנתונים בדיסקים נפרדים

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

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

מפעילים את האפשרות discard או מריצים את הפקודה fstrim בדיסק

במקרים של מופעי Linux, אם לא פורמטו הדיסקים (Persistent Disk או Hyperdisk) ולא בוצעה להם התקנה עם האפשרות discard, צריך להריץ את הפקודה fstrim במופע לפני שיוצרים תמונת מצב. הפקודה מסירה בלוקים שמערכת הקבצים כבר לא צריכה, כדי שהמערכת תוכל ליצור את התמונה במהירות רבה יותר ובגודל קטן יותר. כדי ללמוד איך להגדיר את האפשרות 'הסרה' בדיסקים, אפשר לעיין במאמר בנושא פורמט והרכבה של דיסק שאינו דיסק אתחול במכונה וירטואלית של Linux.

יצירת תמונה של קובץ snapshot שנמצא בשימוש לעיתים קרובות

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

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

שיטות עבודה מומלצות נוספות

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

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