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

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

שיקולי אבטחה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מגבלות על תדירות יצירת תמונות מצב

יש מגבלות על התדירות שבה אפשר ליצור קובץ 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."

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

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

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

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

אפשר ליצור דיסק אחסון מתמיד (Persistent Disk) או Hyperdisk אזורי חדש מתוך snapshot נתון לכל אזור יעד, עד 6 פעמים בכל 60 דקות. אזור היעד הוא מיקום האחסון של הדיסק החדש שנוצר מקובץ ה-snapshot.Cloud de Confiance by S3NS לא מבטיח שתוכלו ליצור דיסקים מקובץ 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."

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

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

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

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

  1. יצירת תמונה מקובץ ה-snapshot.
  2. Create disks from the image (יצירת דיסקים מהתמונה).

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

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

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

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

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

תזמון צילומי מצב בשעות שבהן העומס נמוך

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

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

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

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

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

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

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

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

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

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

שיטות מומלצות נוספות

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

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