ניהול מאגרי OnVault במסוף לניהול הציוד

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

מאגר OnVault שנוצר אוטומטית עם קטגוריה של Cloud Storage

מאגר OnVault שמצביע על קטגוריה של Cloud Storage נוצר באופן אוטומטי על ידי חשבון השירות שמצורף למכשיר, לפי הצורך. מאגר OnVault הזה מכיל את ההגדרה והמטא-נתונים של מכונת VM, והוא נוצר אוטומטית בזמן הריצה כשמקצים תבנית גיבוי למופע של Compute Engine. המיקום של קטגוריה של Cloud Storage נקבע על סמך המיקום או האזור של האחסון של קובצי ה-snapshot של דיסקי אחסון מתמידים (persistent disk), כפי שהוגדר בתבנית לגיבוי נתונים.

כדי לראות את מאגרי OnVault, עוברים במסוף לניהול המכשיר אל Manage > Storage Pools ופותחים את הדף Storage Pools. מאגרי OnVault שנוצרו אוטומטית בדף Storage Pools מוצגים עם אותו שם כמו של קטגוריות האחסון: <backup/recovery-appliance-name>-<random-string>-<region/multi-region>. אי אפשר לערוך או למחוק את מאגרי OnVault שנוצרו אוטומטית.

מאגרי OnVault נוצרים באופן אוטומטי בתרחישים הבאים:

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

מידע נוסף זמין במאמר בנושא מאגר OnVault שנוצר אוטומטית.

תפקידים והרשאות של IAM

לפני הוספת מאגר OnVault, צריך להקצות את התפקיד Backup and DR Cloud Storage Operator עם ההרשאות הנדרשות לפרויקט שבו נמצאת הקטגוריה או לקטגוריה עצמה. הענקת הרשאות ברמת הקטגוריה היא דרך פרטנית יותר.

התפקיד הזה מאפשר לחשבון השירות שמצורף למכשיר לבצע פעולות ב-OnVault, ויש לו את כל ההרשאות שנדרשות לאחסון ולניהול של גיבויים במאגרי OnVault – כולל גישה לנתוני גיבוי, העתקה של נתוני גיבוי מקטגוריה אחת של Cloud Storage לקטגוריה אחרת ותפוגה של גיבויים מאוחסנים. כדי לוודא מהן ההרשאות של התפקיד הזה, עוברים אל IAM & Admin ‏> Roles ובוחרים באפשרות Backup and DR Cloud Storage Operator.

אם אתם לא רוצים להקצות את התפקיד Backup and DR Cloud Storage Operator, אתם יכולים גם ליצור תפקיד בהתאמה אישית ולהקצות את ההרשאות הבאות.

  • storage.buckets.create
  • storage.buckets.get
  • storage.objects.create
  • storage.objects.delete
  • storage.objects.get
  • storage.objects.list

הוספה או עריכה של מאגר OnVault

בקטע הזה מוסבר איך להוסיף מאגר OnVault חדש או לערוך מאגר OnVault קיים.

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

מאגרי OnVault דורשים גישה ל-Cloud Storage. לפני שמוסיפים מאגר OnVault, צריך לבצע את הפעולות הבאות:

  • מאתרים או יוצרים קטגוריית אחסון לאחסון נתוני הגיבוי:

    • כל סוגי האחסון והמיקומים נתמכים. חשוב להשתמש בסוג אחסון (storage class) שמתאים למדיניות שלכם בנושא שמירת נתונים. אל תשתמשו בסוג האחסון 'ארכיון' בלי להתייעץ קודם עם צוות המכירות או התמיכה.

    • צריך להשבית את ניהול הגרסאות ואת מדיניות השמירה בקטגוריה של Cloud Storage.

    • צריך להשבית את מדיניות המחיקה הרכה בקטגוריית Cloud Storage.

    • בכל קטגוריה חדשה, בקרת הגישה צריכה להיות מוגדרת כאחידה.

    • Google-owned and Google-managed encryption keys יש תמיכה במפתחות הצפנה בניהול הלקוח (CMEK).

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

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

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

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

בטבלה הבאה מודגשת ההתנהגות של מאגר OnVault עם גרסת ה-Appliance שנפרסה.

הוספה של מאגר OnVault

כדי להוסיף מאגר OnVault, פועלים לפי ההוראות הבאות.

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

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

  5. בתפריט הנפתח Appliance, בוחרים את ה-appliance שאליו רוצים להוסיף את מאגר OnVault.

    שדה חשבון השירות לקריאה בלבד מתמלא אוטומטית.

  6. בשדה Bucket, מזינים את שם קטגוריית האחסון שמכילה את הנתונים. הקטגוריה חייבת כבר להתקיים, וצריך לוודא ששם הקטגוריה נכון. מעתיקים את שם הקטגוריה מדף המסוף Google Cloud , לוחצים על Cloud Storage ואז על Buckets. לחשבון השירות שמוצג בשלב חמש צריכה להיות הרשאה לגשת לקטגוריה ברמת הקטגוריה או ברמת הפרויקט. ב-Coldline וב-Nearline נדרשת רשימת ACL עם הרשאות ברמת גרנולריות גבוהה בקטגוריה.

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

  8. בקטע אפשרויות מתקדמות, מבצעים את הפעולות הבאות:

    1. בוחרים באפשרות גודל האובייקט. הערכים יכולים לנוע בין 64KB ל-8MB. ערך ברירת המחדל של 1MB הוא הבחירה הטובה ביותר ברוב המקרים. שינוי גודל האובייקט יכול להשפיע לרעה על הביצועים ועל העלות של שירות האחסון שמשמש ל-OnVault.

  9. אם משתמשים ב-proxy, מזינים את הכתובת ומספר היציאה של שרת ה-proxy.

  10. לוחצים על Save.

עריכה של מאגר OnVault

כדי לערוך מאגר OnVault, פועלים לפי ההוראות הבאות.

  1. לוחצים על ניהול ובוחרים באפשרות מאגרי אחסון בתפריט הנפתח.
  2. בוחרים את המאגר ב-OnVault שרוצים לערוך ולוחצים על הלחצן עריכה בפינה השמאלית התחתונה של הדף.
  3. עורכים את הפרטים של OnVault Pool Name ושל Bucket לפי הצורך. מפעילים או משביתים את הדחיסה לפי הצורך. אי אפשר לערוך את חשבון השירות.

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

  5. לוחצים על עדכון.

החלפת מאגר OnVault של מפתח JSON במאגר OnVault שמבוסס על חשבון שירות

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

כדי להחליף מאגר מפתחות JSON במאגר של חשבון שירות למכשיר, פועלים לפי ההוראות הבאות.

  1. מוסיפים מאגר חדש של OnVault ובשדה Bucket משתמשים באותו שם של מאגר שבו השתמשתם ליצירת מאגר OnVault עם מפתח JSON.
  2. במסוף הניהול של האפליקציה, עוברים אל Backup Plans (תוכניות גיבוי) > Profiles (פרופילים).
  3. בוחרים את הפרופיל שמשתמש במאגר הישן של OnVault שנוצר באמצעות מפתח ה-JSON.
  4. לוחצים על Edit.
  5. בתפריט הנפתח OnVault pool, בוחרים את מאגר OnVault החדש שנוצר עם חשבון שירות.

  6. לוחצים על Save.

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

מחיקת מאגר OnVault

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

  • מוודאים שאין פרופילים של משאבים בתוכנית הגיבוי שמציינים את המאגר.

  • התמונות ב-OnVault יפוגו במאגר. התוקף של התמונה האחרונה בתיקיית הכספת לא פג אף פעם, אלא אם האפליקציה לא מוגנת או שהתוקף של התמונה פג באופן מפורש.

כדי למחוק מאגר OnVault ממכשיר, פועלים לפי ההוראות הבאות:

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

גישה לנתונים במאגר OnVault

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

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

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

  • מכשירי גיבוי או שחזור יכולים ליצור שיבוטים מנתוני OnVault.
  • מכשירי גיבוי ושחזור לא יכולים ליצור LiveClones מנתוני OnVault.
  • מכשירים לגיבוי או לשחזור יכולים לטעון נתונים ב-OnVault.
  • אמצעי גיבוי ושחזור יכולים לטעון נתונים במאגר OnVault, אבל הם קודם מעתיקים את כל הנתונים למאגר התמונות ואז טוענים אותם.
  • מכשיר גיבוי/שחזור יכול לבצע טעינה של נתונים ב-OnVault pool עם מודעות לאפליקציה.

שליחת גיבויים למאגר OnVault

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

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

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

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

    • מדיניות Snapshot to OnVault: משתמשים במדיניות הזו כדי לתזמן את העברת הנתונים של מכונות וירטואליות, מערכות קבצים ואפליקציות לאחסון שמוגדר על ידי מאגר OnVault. מידע נוסף על מדיניות OnVault
    • מדיניות Direct to OnVault: משתמשים בה כדי לתזמן את העברת הנתונים של מכונות וירטואליות ב-VMware Engine לאחסון שמוגדר על ידי מאגר OnVault. מידע נוסף זמין במאמר בנושא מדיניות OnVault.

  3. בקטע Backup Plans, יוצרים פרופיל משאבים שמציין איפה לאחסן את הנתונים באופן מקומי, אם רלוונטי, וגם את מאגר OnVault שאליו הנתונים נשלחים. איך יוצרים פרופיל של משאב

  4. במרכז ניהול האפליקציות, בוחרים את הנתונים שרוצים לשכפל למאגר OnVault, ואז מחילים את תבנית הגיבוי ואת פרופיל המשאבים.

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

    • ליצור שיבוטים.
    • טוענים את הנתונים.
    • אי אפשר ליצור LiveClones במאגר OnVault.

  6. בהתאם לדרישות הגישה והשחזור של הנתונים שמאוחסנים במאגר OnVault, במסוף לניהול מכשירים אפשר לבצע פעולות של הרכבה או שיבוט מהחלון Access של App Manager.

איזון בין ביצועים וצריכה של תמונות ב-OnVault

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

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

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

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

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

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

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

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

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

שימוש במאגרי OnVault

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

כך מעבירים נתוני תמונות לאחסון שמוגדר על ידי מאגר אחסון OnVault:

  1. מוודאים שיצרתם את מאגר OnVault. מאגרי אחסון ב-OnVault מגדירים את האחסון שבו נעשה שימוש ומצוינים בפרופיל משאבים.

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

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

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

  4. בApp Manager, בוחרים את הנתונים שרוצים לשכפל למאגר OnVault, ואז מחילים את Backup Template (תבנית גיבוי) וResource Profile (פרופיל משאבים).

  5. מכשירי גיבוי ושחזור יכולים לבצע את הפעולות הבאות כשניגשים לנתונים באחסון של OnVault Pool:

    • יצירת שיבוטים
    • טעינת נתונים
    • אי אפשר ליצור LiveClones במאגר OnVault.

  6. בהתאם לדרישות הגישה והשחזור של הנתונים שמאוחסנים במאגר OnVault, במסוף לניהול מכשירים אפשר לבצע פעולות של הרכבה או שיבוט מהחלון Access של App Manager.