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

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

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

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

כדי לראות את מאגרי 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, צריך לבצע את הפעולות הבאות:

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

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

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

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

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

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

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

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

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

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

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

הוספת מאגר OnVault

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  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 לא פג אף פעם, אלא אם האפליקציה לא מוגנת או שהתוקף של התמונה פג באופן מפורש.

כדי למחוק מאגר 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 storage pool.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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