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

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

שיקולי אבטחה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

CREATING: יצירת ה-Snapshot עדיין לא הסתיימה.
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. ‏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."

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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