מאגר OnVault הוא מצביע לקטגוריה של Cloud Storage או לכספת גיבוי שמשמשת לאחסון נתוני גיבוי. הם מוזכרים בפרופילי המשאבים. הפרופילים של המשאבים משמשים יחד עם מדיניות OnVault כדי לשלוח נתוני גיבוי למאגר OnVault שהוקצה.
מאגר OnVault שנוצר באופן אוטומטי עם קטגוריה של Cloud Storage
מאגר OnVault שמפנה לקטגוריה של Cloud Storage נוצר באופן אוטומטי על ידי חשבון השירות שמצורף למכשיר, לפי הצורך. מאגר OnVault הזה מכיל את המטא-נתונים וההגדרות של מכונת ה-VM, והוא נוצר באופן אוטומטי בזמן הריצה, כשמקצים תבנית לגיבוי נתונים למכונה של Compute Engine. המיקום של הקטגוריה ב-Cloud Storage נקבע לפי המיקום או האזור של האחסון של קובצי ה-snapshot של Persistent Disk, כפי שהוגדר בתבנית לגיבוי נתונים.
כדי לראות את מאגרי OnVault במסוף ניהול המכשירים, נכנסים לדף Storage Pools דרך Manage > Storage Pools. מאגרי OnVault שנוצרו באופן אוטומטי בדף Storage Pools מוצגים עם אותו שם כמו של קטגוריות האחסון, בפורמט <backup/recovery-appliance-name>-<random-string>-<region/multi-region>. אי אפשר לערוך או למחוק את מאגרי OnVault שנוצרו באופן אוטומטי.
מאגרי OnVault נוצרים באופן אוטומטי בתרחישים הבאים:
- לתבנית לגיבוי נתונים שהוקצתה למכונה של Compute Engine אין מאגר.
- תבנית לגיבוי נתונים מתעדכנת כדי להשתמש באזור אחר או במספר אזורים, ואז המאגר נוצר באופן אוטומטי אחרי שה-snapshot הראשון פועל בהצלחה. כך השירות מבטיח שהנתונים של Persistent Disk וההגדרות של המכונה הווירטואלית נמצאים באותו מיקום.
- אם עוקפים את המדיניות של מכונה מוגנת ב-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.createstorage.buckets.getstorage.objects.createstorage.objects.deletestorage.objects.getstorage.objects.list
הוספה או עריכה של מאגר OnVault
בקטע הזה מוסבר איך להוסיף מאגר OnVault חדש או לערוך מאגר OnVault קיים.
לפני שמתחילים
מאגרי OnVault דורשים גישה ל-Cloud Storage. לפני שמוסיפים מאגר OnVault, צריך לבצע את הפעולות הבאות:
מזהים או יוצרים קטגוריית אחסון שתכיל את נתוני הגיבוי:
- יש תמיכה בכל סוגי האחסון והמיקומים. השתמשו בסוג אחסון שמתאים לשמירת הנתונים שלכם. אל תשתמשו בסוג האחסון Archive בלי להתייעץ קודם עם ארגון המכירות או התמיכה.
צריך להשבית את ניהול הגרסאות והשמירה בקטגוריה של Cloud Storage.
המדיניות בנושא מחיקת נתונים רכה בקטגוריה של Cloud Storage צריכה להיות מושבתת.
בקרת הגישה צריכה להיות מוגדרת כאחידה בכל קטגוריה חדשה.
Google-owned and Google-managed encryption keys ומפתחות הצפנה בניהול הלקוח (CMEK).
מוסיפים לקטגוריה את חשבון השירות של מכשיר הגיבוי/השחזור כחשבון משתמש עם התפקידים וההרשאות הנדרשים. צריך לעשות את זה לכל קטגוריה שנוצרה על ידי משתמש.
פרטי קטגוריית האחסון, כי השדה של חשבון השירות מאוכלס באופן אוטומטי כשבוחרים את המכשיר, כי הוא משתמש בחשבון השירות שמצורף למכשיר הגיבוי/השחזור.
מוודאים שלחשבון השירות יש גישה לקטגוריה עם תפקיד שכולל את ההרשאות הנדרשות ברמת הפרויקט או ברמת הקטגוריה.
אפשר ליצור כמה מאגרי OnVault שרוצים במכשיר הגיבוי והשחזור, באמצעות אותו חשבון שירות של מכשיר הגיבוי והשחזור. התהליך להוספת מאגר OnVault משתנה בהתאם לגרסת התוכנה של מכשיר הגיבוי/השחזור. כדי לבדוק באיזו גרסה אתם משתמשים, עוברים אל Manage > Appliances ובודקים את העמודה Version.
בטבלה הבאה מודגשת ההתנהגות של מאגר OnVault עם גרסת המכשיר שנפרסה.
הוספת מאגר OnVault
כדי להוסיף מאגר OnVault:
- לוחצים על ניהול ובוחרים באפשרות מאגרי נפח אחסון בתפריט הנפתח.
- בפינה הימנית העליונה של הדף, לוחצים על Add OnVault Pool.
- מזינים את OnVault Pool Name. התווים התקינים הם אותיות, מספרים, רווחים, מקפים (-) וקווים תחתונים (_).
בוחרים את סוג הבריכה. בוחרים באפשרות ברירת המחדל, Cloud Storage. סוג המאגר Cloud Storage תומך בכל סוגי האחסון, וצריך להשתמש בו אלא אם נדרשת תאימות לדורות קודמים עם מאגר OnVault מדור קודם. אי אפשר לשנות את סוג המאגר אחרי שיוצרים את מאגר OnVault.
בתפריט הנפתח Appliance, בוחרים את המכשיר שאליו רוצים להוסיף את מאגר OnVault.
השדה לקריאה בלבד של חשבון השירות מתמלא באופן אוטומטי.
בשדה Bucket, מזינים את שם קטגוריית האחסון שבה נמצאים הנתונים. הקטגוריה כבר צריכה להיות קיימת, וצריך לוודא ששם הקטגוריה נכון. כדי לקבל את שם הקטגוריה, בדף Google Cloud של המסוף לוחצים על Cloud Storage ואז על Buckets. לחשבון השירות שמוצג בשלב חמש צריכה להיות הרשאת גישה לקטגוריה, ברמת הקטגוריה או ברמת הפרויקט. ב-Coldline וב-Nearline נדרשת רשימת ACL מפורטת בקטגוריה.
מציינים אם הנתונים במאגר OnVault צריכים להישמר בפורמט דחוס או לא דחוס. דחיסת נתונים מפחיתה את עלויות האחסון, אבל דורשת קיבולת מחשוב נוספת כדי שמכשירי הגיבוי/השחזור ידחסו את הנתונים לפני השידור. ברוב המקרים כדאי להשאיר את תיבת הדחיסה מסומנת. הדחיסה גם מצמצמת את התנועה ברשת.
בקטע אפשרויות מתקדמות, מבצעים את הפעולות הבאות:
בוחרים את גודל האובייקט. הערכים נעים בין 64KB ל-8MB. ערך ברירת המחדל של 1MB הוא הבחירה הטובה ביותר ברוב המקרים. שינוי גודל האובייקט יכול להשפיע לרעה על הביצועים ועל העלות של שירות האחסון שמשמש ל-OnVault.
אם משתמשים בשרת proxy, מזינים את הכתובת ואת מספר היציאה של שרת ה-proxy.
לוחצים על Save.
עריכת מאגר OnVault
כך עורכים מאגר OnVault:
- לוחצים על ניהול ובוחרים באפשרות מאגרי נפח אחסון בתפריט הנפתח.
- בוחרים את מאגר OnVault שרוצים לערוך ולוחצים על הכפתור Edit בפינה הימנית התחתונה של הדף.
- עורכים את הפרטים של OnVault Pool Name ו-Bucket לפי הצורך. מפעילים או משביתים את האפשרות דחיסה לפי הצורך. אי אפשר לערוך את חשבון השירות.
בקטע Advanced Options, משנים את הערכים של Object size ו-שרת proxy לפי הצורך. שינוי גודל האובייקט יכול להשפיע לרעה על הביצועים ועל עלות שירות האחסון שמשמש ל-OnVault.
לוחצים על עדכון.
החלפת מאגר OnVault עם מפתח JSON במאגר OnVault שמבוסס על חשבון שירות
אם יש לכם מאגר OnVault שנוצר באמצעות מפתח JSON לאימות, אתם לא יכולים להעביר את מאגר OnVault הזה לשימוש עם אימות של חשבון שירות של מכשיר. במקום זאת, צרו מאגר OnVault חדש והשתמשו באותם פרטי קטגוריה ששימשו בעבר ליצירה שלו באמצעות מפתח JSON.
כדי להחליף מאגר OnVault של מפתחות JSON במאגר של חשבונות שירות של מכשירים, פועלים לפי ההוראות הבאות.
- מוסיפים מאגר OnVault חדש ובשדה Bucket משתמשים באותו שם קטגוריה שמשמש ליצירת מאגר OnVault עם מפתח JSON.
- במסוף לניהול המכשיר, נכנסים ל-Backup Plans > Profiles.
- בוחרים את הפרופיל שמשתמש במאגר OnVault הישן שנוצר באמצעות מפתח ה-JSON.
- לוחצים על Edit.
- בתפריט הנפתח OnVault pool, בוחרים את מאגר OnVault החדש שנוצר באמצעות חשבון שירות.
לוחצים על Save.
כל התמונות החדשות נוצרות במאגר OnVault החדש שהוגדר. שימו לב שאי אפשר למחוק את מאגר OnVault הישן עד שתוקף כל התמונות שנוצרו בעבר במאגר הזה יפוג.
מחיקת מאגר OnVault
כך מוחקים מאגר OnVault:
מוודאים שאין פרופילים של משאבים בתוכנית הגיבוי שמציינים את המאגר.
תפוגת התוקף של כל תמונות OnVault במאגר. התוקף של קובץ האימג' האחרון של OnVault אף פעם לא פג, אלא אם האפליקציה לא מוגנת או שהתוקף של קובץ האימג' פג באופן מפורש.
כדי למחוק מאגר OnVault ממכשיר:
- לוחצים על ניהול ובוחרים באפשרות מאגרי נפח אחסון בתפריט הנפתח.
- לוחצים לחיצה ימנית על מאגר OnVault שרוצים למחוק ובוחרים באפשרות Delete.
- לוחצים על אישור.
גישה לנתונים במאגר OnVault
אחרי שיוצרים פרופיל משאבים שמשתמש במאגר OnVault ובתבנית לגיבוי נתונים שמכילה מדיניות OnVault, אפשר להחיל את פרופיל המשאבים ואת התבנית לגיבוי נתונים על אפליקציות ומכונות וירטואליות בכרטיסייה Backup Plans. מדיניות OnVault פועלת לפי לוח הזמנים שלה, והתמונה שנוצרה נכתבת למאגר OnVault שצוין ב-Resource Profile.
אחרי הגיבוי המלא הראשוני, כללי המדיניות של תמונת המצב ל-OnVault פועלים לפי המודל של Backup and DR שבו רק השינויים בנתונים נלכדים ונשלחים לאחסון.
אחרי שפעולת התיעוד הראשונה מסתיימת, אפשר לגשת לנתונים במיקום האחסון של מאגר OnVault לפי הכללים הבאים:
- מכשירי גיבוי/שחזור יכולים ליצור שיבוטים מנתוני OnVault.
- מכשירי הגיבוי/השחזור לא יכולים ליצור LiveClones מנתוני OnVault.
- מכשירי גיבוי/שחזור יכולים לטעון נתוני OnVault.
- מכשירי גיבוי/שחזור יכולים לטעון נתונים במאגר OnVault, אבל הם מעתיקים את כל הנתונים למאגר תמונות המצב לפני הטעינה.
- מכשיר הגיבוי/השחזור יכול לבצע טעינות של נתונים במאגר OnVault, תוך זיהוי האפליקציה.
שליחת גיבויים למאגר OnVault
כללי המדיניות Snapshot to OnVault ו-Direct to OnVault קובעים את העברת הנתונים לאחסון. הם מספקים לוח זמנים לשליחת הנתונים וגם הגדרה של משך הזמן לשמירת הנתונים. השילוב של פרופיל המשאבים ותבנית OnVault יוצר את תוכנית הגיבוי לאפליקציות שעליהן הם חלים. כדי ליצור מאגר OnVault, קראו את המאמר הוספת מאגר OnVault.
כך מעבירים נתוני תמונות לאחסון שמוגדר על ידי מאגר אחסון של OnVault.
- מוודאים שיצרתם את מאגר OnVault. מאגרי האחסון של OnVault מגדירים את מאגר האובייקטים שבו משתמשים, והם מצוינים בפרופיל המשאבים.
ב-Backup Plans, יוצרים תבנית שכוללת:
- מדיניות Snapshot to OnVault: משתמשים במדיניות הזו כדי לתזמן את העברת הנתונים של המכונה הווירטואלית, מערכת הקבצים והאפליקציה לאחסון שמוגדר על ידי מאגר OnVault. כללי מדיניות של OnVault
- מדיניות Direct to OnVault: משמשת לתזמון ההעברה של נתוני ה-VM של VMware Engine לאחסון שמוגדר על ידי מאגר OnVault. מידע נוסף זמין במאמר כללי מדיניות של OnVault.
ב-Backup Plans, יוצרים פרופיל משאבים שמציין איפה לאחסן ועיבוד נתונים באופן מקומי, אם רלוונטי, וגם את מאגר OnVault שאליו נשלחים הנתונים. איך יוצרים פרופיל משאבים
ב-App Manager, בוחרים את הנתונים שרוצים לשכפל למאגר OnVault, ואז מחילים את התבנית לגיבוי נתונים ואת פרופיל המשאבים.
מכשירי גיבוי/שחזור יכולים לבצע את הפעולות הבאות כשהם ניגשים לנתונים באחסון של מאגר OnVault:
- ליצור שיבוטים.
- נתוני טעינה.
- אי אפשר ליצור LiveClones במאגר OnVault.
בהתאם לדרישות הגישה והשחזור של הנתונים שמאוחסנים במאגר OnVault, אתם יכולים לבצע פעולות טעינה או שכפול דרך מסוף הניהול של המכשיר, בחלון Access של App Manager.
- מידע נוסף על ביצוע פעולת טעינה זמין במאמר טעינת קובצי אימג'.
- במאמר סקירה כללית על שכפול מוסבר איך מבצעים פעולת שכפול.
איזון בין הביצועים לבין הצריכה של קובצי אימג' של OnVault
כשמפעילים קובץ אימג' ממאגר OnVault, ארבע האפשרויות הבאות מאפשרות לאזן בין הביצועים לבין צורכי האחסון כדי לגשת לנתונים:
Storage Optimized: בלוקים לקריאה מגיעים ממאגר הסנאפשוטים כשאפשר, אחרת הם מגיעים ישירות ממאגר OnVault דרך הרשת. פעולות הכתיבה מועברות למאגר קובצי ה-snapshot המקומיים.
האפשרות הזו מאפשרת לצמצם את צריכת האחסון המקומי על חשבון ביצועי הקריאה, כי הנתונים נשלפים כל הזמן דרך הרשת.
מאוזן: (אפשרות ברירת המחדל) אובייקטים שנקראים ממאגר OnVault נשמרים במטמון במאגר קובצי ה-snapshot המקומיים, כך שקריאות עוקבות של אותם בלוקים מתבצעות באופן מקומי. פעולות הכתיבה מועברות למאגר קובצי ה-snapshot המקומיים. ביצועי הקריאה משתפרים עם הזמן, ככל שיותר נתונים נקראים ונשמרים במאגר של קובצי ה-snapshot. השימוש באחסון המקומי מוגבל לנתונים שהאפליקציות באמת צריכות.
האפשרות הזו מתאימה כשיש אחסון מקומי ולא נדרשים ביצועי קלט/פלט גבוהים.
ביצועים אופטימליים: בלוקים של קריאה נשמרים במאגר קובצי ה-snapshot המקומיים, כך שקריאות עוקבות של אותם בלוקים מתבצעות באופן מקומי. בנוסף, כל הבלוקים נקראים ברקע למאגר קובצי ה-snapshot המקומיים כדי ליצור עותק מקומי מלא. פעולות הכתיבה עוברות למאגר קובצי ה-snapshot המקומיים. ביצועי הקריאה משתפרים במהירות כשתהליך ברקע מעתיק נתונים מ-OnVault למאגר קובצי ה-snapshot המקומיים. דרישת האחסון היא הגבוהה ביותר, כי כל הנתונים מועתקים לאחסון המקומי.
כדאי להשתמש באפשרות הזו כשצריך גם גישה מהירה לנתונים וגם ביצועי קלט/פלט גבוהים.
ביצועים מקסימליים: כל הבלוקים נקראים למאגר קובצי ה-snapshot המקומיים כדי ליצור עותק מקומי מלא, ורק אז התמונה נטענת. האפשרות הזו משתמשת באותו נפח אחסון נדרש מקומי כמו אופטימיזציה לביצועים, כי כל הנתונים מועתקים למאגר קובצי ה-snapshot המקומיים.
האפשרות הזו מתאימה כשצריך ביצועים מקסימליים מהאחסון המקומי לכל פעולות הקלט/פלט של האפליקציה, וכשזמן האחזור של הקריאה ממאגר OnVault לא מקובל, כך שלא רצוי לתת לאפליקציה גישה לנתונים לפני שנוצר עותק מקומי מלא.
שימוש במאגרי OnVault
כללי המדיניות "תמונת מצב ל-OnVault" ו"ישירות ל-OnVault" קובעים את העברת הנתונים לאחסון. הם מספקים לוח זמנים לשליחת הנתונים והגדרה של משך הזמן לשמירת הנתונים. השילוב של פרופיל המשאבים והתבנית של OnVault יוצר את תוכניות הגיבוי לאפליקציות שעליהן הם חלים.
כך מעבירים נתוני תמונות לאחסון שמוגדר על ידי מאגר אחסון של OnVault:
- מוודאים שיצרתם את מאגר OnVault. מאגרי האחסון של OnVault מגדירים את האחסון שבו משתמשים, והם מצוינים בפרופיל המשאבים.
ב-Backup Plans, יוצרים תבנית שכוללת את אחד מהאפשרויות הבאות:
- מדיניות Snapshot to OnVault: משתמשים במדיניות הזו כדי לתזמן את העברת הנתונים של המכונה הווירטואלית, מערכת הקבצים והאפליקציה לאחסון שמוגדר על ידי מאגר OnVault. כללי מדיניות של OnVault
- Direct to OnVault policy: משתמשים במדיניות הזו כדי לתזמן את העברת הנתונים של המכונה הווירטואלית ב-Google Cloud VMware Engine לאחסון שמוגדר על ידי מאגר OnVault. מידע נוסף זמין במאמר כללי מדיניות של OnVault.
ב-Backup Plans, יוצרים פרופיל משאבים שמציין איפה לאחסן ועיבוד נתונים באופן מקומי, אם רלוונטי, וגם את מאגר OnVault שאליו נשלחים הנתונים. איך יוצרים פרופיל משאבים
ב-App Manager, בוחרים את הנתונים שרוצים לשכפל למאגר OnVault, ואז מחילים את תבנית הגיבוי ואת פרופיל המשאבים.
מכשירי גיבוי/שחזור יכולים לבצע את הפעולות הבאות כשהם ניגשים לנתונים באחסון של OnVault Pool:
- יצירת שיבוטים
- נתוני טעינה
- אי אפשר ליצור LiveClones במאגר OnVault.
בהתאם לדרישות הגישה והשחזור של הנתונים שמאוחסנים במאגר הנתונים של OnVault, אתם יכולים לבצע פעולות טעינה או שכפול דרך מסוף הניהול של המכשיר, בחלון Access של App Manager.