הכנה לפריסת מכשיר לגיבוי או לשחזור

זהירות: התמיכה בגיבוי ובשחזור של עומסי עבודה שמנוהלים באמצעות מסוף הניהול של המכשיר הקודם הוצאה משימוש. מידע נוסף זמין במאמר הוצאה משימוש של תכונות במסמכי התיעוד של Backup and DR.

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

לפני שמתחילים את החלק הזה, מומלץ לקרוא את המאמר תכנון פריסה של Backup and DR.

בדף הזה מפורטות Google Cloud הדרישות שצריך לעמוד בהן לפני ש מפעילים Google Cloud את Backup and DR, וצריך לעשות את זה במסוף Google Cloud .

את כל המשימות שמתוארות בדף הזה צריך לבצע בפרויקט ב-Google Cloud שבו אתם פורסים את מכשיר הגיבוי/השחזור. אם הפרויקט הזה הוא פרויקט שירות של VPC משותף, חלק מהמשימות מבוצעות בפרויקט ה-VPC וחלק בפרויקט של עומס העבודה.

אישור פרויקטים של קובצי אימג' מהימנים

ההרשאות שנדרשות למשימה הזו

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

• orgpolicy.policies.create
• orgpolicy.policies.delete
• orgpolicy.policies.delete
• orgpolicy.policy.get
דוגמאות לתפקידים שכוללים את ההרשאה הזו: Organization Policy Administrator

אם הפעלתם את המדיניות constraint/compute.trustedImageProjects במדיניות הארגון, לא תוכלו להשתמש בפרויקט המקור שמנוהל על ידי Google Cloudלתמונות שמשמשות לפריסת מכשיר הגיבוי/השחזור. כדי למנוע שגיאה של הפרת מדיניות במהלך הפריסה, צריך להתאים אישית את מדיניות הארגון בפרויקטים שבהם פורסים את מכשירי הגיבוי וההתאוששות, כמו שמפורט בהוראות הבאות:

1. נכנסים לדף Organization policies ובוחרים את הפרויקט שבו פורסים את המכשירים.

   כניסה לדף Organization policies

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

3. לוחצים על עריכה כדי להתאים אישית את האילוצים הקיימים של התמונות המהימנות.

4. בדף עריכה, לוחצים על התאמה אישית.

5. בוחרים אחת משלוש האפשרויות הבאות:

   מדיניות קיימת שעברה בירושה

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

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

   2. לוחצים על הוספת כלל.

   3. בוחרים באפשרות Custom מהרשימה הנפתחת Policy values כדי להגדיר את המגבלה בפרויקטים ספציפיים של תמונות.

   4. ברשימה הנפתחת Policy type, בוחרים באפשרות Allow כדי להסיר את ההגבלות על פרויקטים ספציפיים של קובצי אימג'.

   5. בשדה Custom values, מזינים את הערך המותאם אישית projects/backupdr-images.

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

   כלל אישור קיים

   אם יש כלל אישור קיים, מבצעים את השלבים הבאים:

   1. משאירים את ברירת המחדל של Policy enforcement.

   2. בוחרים את הכלל הקיים אישור.

      אזהרה: אם יש כלל, צריך להשתמש בו. אל תנסו להוסיף כלל נוסף.

   3. לוחצים על Add value כדי להוסיף עוד פרויקטים של תמונות, ומזינים את הערך projects/backupdr-images.

   4. לוחצים על סיום.

   אין מדיניות או כלל קיימים

   אם אין כלל קיים, לוחצים על הוספת כלל ואז מבצעים את הפעולות הבאות:

   1. משאירים את האפשרות Policy enforcement כברירת המחדל שנבחרה.

   2. בוחרים באפשרות Custom מהרשימה הנפתחת Policy values כדי להגדיר את האילוץ בפרויקטים ספציפיים של תמונות.

   3. ברשימה הנפתחת Policy type, בוחרים באפשרות Allow כדי להסיר את ההגבלות על פרויקטים ספציפיים של קובצי אימג'.

   4. בשדה Custom values, מזינים את הערך המותאם אישית projects/backupdr-images.

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

   6. לוחצים על Add value כדי להוסיף עוד פרויקטים של תמונות, ואז על Done.

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

6. לוחצים על שמירה כדי להחיל את האילוץ.

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

תהליך הפריסה

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

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

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

מסוף ניהול המכשירים נפרס כשמתקינים את המכשיר הראשון לגיבוי או לשחזור. אתם יכולים לפרוס את Backup and DR ב-VPC משותף או ב-VPC לא משותף.

‫Backup and DR ב-VPC לא משותף

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

הערה: צריך להשבית את CMEK בפרויקט שבו נפרס מכשיר הגיבוי/השחזור.

אם ה-VPC משותף, קראו את המאמר Backup and DR ב-VPC משותף.

הפעלת ממשקי ה-API הנדרשים להתקנה ב-VPC לא משותף

לפני שמפעילים את ממשקי ה-API הנדרשים להתקנה ב-VPC לא משותף, צריך לבדוק את האזורים הנתמכים לפריסת Backup and DR. אזורים נתמכים

כדי להריץ את תוכנת ההתקנה ב-VPC לא משותף, צריך להפעיל את ממשקי ה-API הבאים. כדי להפעיל ממשקי API, צריך את התפקיד אדמין של שימוש בשירות.

API	שם השירות
Compute Engine	compute.googleapis.com
מנהל המשאבים	cloudresourcemanager.googleapis.com
תהליכי עבודה ^1	workflows.googleapis.com
Cloud Key Management Service (KMS)	cloudkms.googleapis.com
ניהול זהויות והרשאות גישה	iam.googleapis.com
Cloud Logging	logging.googleapis.com

‫¹ שירות Workflow נתמך באזורים שברשימה. אם שירות Workflows לא זמין באזור שבו פורסים את מכשיר הגיבוי והשחזור, אזור ברירת המחדל של Backup and DR הוא us-central1. אם מדיניות הארגון שלכם מוגדרת כך שלא ניתן ליצור משאבים באזורים אחרים, תצטרכו לעדכן אותה באופן זמני כדי לאפשר יצירת משאבים באזור us-central1. אפשר להגביל את האזור "us-central1" אחרי פריסת מכשיר הגיבוי/השחזור.

חשבון המשתמש צריך את ההרשאות האלה בפרויקט VPC לא משותף

התפקיד המועדף	נדרשות הרשאות
‫resourcemanager.projectIamAdmin (אדמין IAM של פרויקט)	resourcemanager.projects.getIamPolicy
	resourcemanager.projects.setIamPolicy
	resourcemanager.projects.get
	iam.serviceAccounts.delete
	iam.serviceAccounts.get
	workflows.workflows.delete
	workflows.executions.create
	workflows.executions.get
	workflows.operations.get
‫serviceusage.serviceUsageAdmin (אדמין של שימוש בשירות)	serviceusage.services.list
‫iam.serviceAccountUser (משתמש בחשבון שירות)	iam.serviceAccounts.actAs
‫iam.serviceAccountAdmin (אדמין של חשבון שירות)	iam.serviceAccounts.create
	iam.serviceAccounts.delete
	iam.serviceAccounts.get
workflows.editor (עורך תהליכי עבודה)	workflows.workflows.create
	workflows.workflows.delete
	workflows.executions.create
	workflows.executions.get
	workflows.operations.get
‫backupdr.admin (אדמין של Backup and DR)	backupdr.*‎
צפייה (בסיסי)	מעניק את ההרשאות שנדרשות כדי לצפות ברוב המשאבים של Google Cloud .

Backup and DR ב-VPC משותף

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

לפני שמפעילים את ממשקי ה-API הנדרשים להתקנה ב-VPC משותף, צריך לבדוק את האזורים שנתמכים בפריסה של Backup and DR. אזורים נתמכים

הערה: צריך להשבית את CMEK בפרויקט שבו פורסים מכשיר לגיבוי או לשחזור.

• פרויקט הבעלים של ה-VPC: הפרויקט שבבעלותו ה-VPC שנבחר. הבעלים של ה-VPC הוא תמיד הפרויקט המארח.

• פרויקט של מסוף ניהול המכשירים: בפרויקט הזה מפעילים את Backup and DR API, ודרכו ניגשים למסוף ניהול המכשירים כדי לנהל את עומסי העבודה.

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

ב-VPC משותף, יכולים להיות פרויקט אחד, שניים או שלושה.

סוג	בעלי ה-VPC	מסוף ניהול המכשירים	מכשיר לגיבוי או לשחזור
HHH	פרויקט מארח	פרויקט מארח	פרויקט מארח
HHS	פרויקט מארח	פרויקט מארח	פרויקט שירות
HSH	פרויקט מארח	פרויקט שירות	פרויקט מארח
HSS	פרויקט מארח	פרויקט שירות	פרויקט שירות
HS2	פרויקט מארח	פרויקט שירות	פרויקט שירות אחר

תיאורים של אסטרטגיות הפריסה

• ‫HHH: VPC משותף. הבעלים של ה-VPC, מסוף הניהול של המכשיר ומכשיר הגיבוי/השחזור נמצאים כולם בפרויקט המארח.

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

• ‫HSH: VPC משותף. הבעלים של ה-VPC ומכשיר הגיבוי/השחזור נמצאים בפרויקט המארח, ומסוף הניהול של המכשיר נמצא בפרויקט שירות.

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

• ‫HS2: VPC משותף. הבעלים של ה-VPC נמצא בפרויקט המארח, והמכשיר לגיבוי/שחזור ומסוף הניהול של המכשיר נמצאים בשני פרויקטים שונים של שירות.

הפעלת ממשקי ה-API הנדרשים להתקנה בפרויקט המארח

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

API	שם השירות
Compute Engine	compute.googleapis.com
מנהל המשאבים	cloudresourcemanager.googleapis.com

הפעלת ממשקי ה-API הנדרשים להתקנה בפרויקט של מכשיר הגיבוי/השחזור

API	שם השירות
Compute Engine	compute.googleapis.com
מנהל המשאבים	cloudresourcemanager.googleapis.com
תהליכי עבודה ^1	workflows.googleapis.com
Cloud Key Management Service (KMS)	cloudkms.googleapis.com
ניהול זהויות והרשאות גישה	iam.googleapis.com
Cloud Logging	logging.googleapis.com

הערה: מכשיר הגיבוי/השחזור צריך גישה לממשקי ה-API של Google Cloud . אם הגדרות הרשת של רשת המשנה לא מאפשרות למכונות הווירטואליות לגשת לממשקי ה-API של Google Cloud , פריסת מכשיר הגיבוי/השחזור תיכשל. מוודאים שלרשת המשנה שבה פרסתם את מכשיר הגיבוי/השחזור יש גישה לממשקי ה-API ולשירותים של Google Cloud . מידע נוסף על ההגדרה הזו זמין במאמר הגדרת גישה פרטית Google Cloud |VPC.

‫¹ שירות Workflow נתמך באזורים שברשימה. אם שירות Workflows לא זמין באזור שבו פורסים את מכשיר הגיבוי/השחזור, אזור ברירת המחדל של Backup and DR הוא us-central1. אם מדיניות הארגון שלכם מוגדרת כך שלא ניתן ליצור משאבים באזורים אחרים, תצטרכו לעדכן אותה באופן זמני כדי לאפשר יצירת משאבים באזור us-central1. אפשר להגביל את האזור "us-central1" אחרי פריסת מכשיר הגיבוי/השחזור.

לחשבון המשתמש נדרשות ההרשאות האלה בפרויקט של בעלי ה-VPC

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

התפקיד המועדף	נדרשות הרשאות
‫resourcemanager.projectIamAdmin (אדמין IAM של פרויקט)	resourcemanager.projects.getIamPolicy
	resourcemanager.projects.setIamPolicy
	resourcemanager.projects.get
	iam.serviceAccounts.delete
	iam.serviceAccounts.get
	workflows.workflows.delete
	workflows.executions.create
	workflows.executions.get
	workflows.operations.get
‫serviceusage.serviceUsageAdmin (אדמין של שימוש בשירות)	serviceusage.services.list

חשבון המשתמש צריך את ההרשאות האלה בפרויקט של מסוף הניהול של המכשיר

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

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

התפקיד המועדף	נדרשות הרשאות
‫resourcemanager.projectIamAdmin (אדמין IAM של פרויקט)	resourcemanager.projects.getIamPolicy
	resourcemanager.projects.setIamPolicy
	resourcemanager.projects.get
	iam.serviceAccounts.delete
	iam.serviceAccounts.get
	workflows.workflows.delete
	workflows.executions.create
	workflows.executions.get
	workflows.operations.get
‫backupdr.admin (אדמין של Backup and DR)	backupdr.*‎
צפייה (בסיסי)	נותן את ההרשאות שנדרשות כדי לראות את רוב Google Cloud המשאבים.

אלה ההרשאות שחשבון המשתמש צריך בפרויקט של מכשיר הגיבוי והשחזור:

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

התפקיד המועדף	נדרשות הרשאות
‫resourcemanager.projectIamAdmin (אדמין IAM של פרויקט)	resourcemanager.projects.getIamPolicy
	resourcemanager.projects.setIamPolicy
	resourcemanager.projects.get
‫iam.serviceAccountUser (משתמש בחשבון שירות)	iam.serviceAccounts.actAs
‫iam.serviceAccountAdmin (אדמין של חשבון שירות)	iam.serviceAccounts.create
	iam.serviceAccounts.delete
	iam.serviceAccounts.get
workflows.editor (עורך תהליכי עבודה)	workflows.workflows.create
	workflows.workflows.delete
	workflows.executions.create
	workflows.executions.get
	workflows.operations.get
‫serviceusage.serviceUsageAdmin (אדמין של שימוש בשירות)	serviceusage.services.list

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

הגדרת רשתות

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

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

הגדרת גישה פרטית ל-Google

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

רשת המשנה שבה פרוס מכשיר הגיבוי/השחזור צריכה לתקשר עם דומיין ייחודי שמתארח בדומיין backupdr.googleusercontent.com. מומלץ לכלול את ההגדרות הבאות ב-Cloud DNS:

1. יוצרים אזור פרטי לשם ה-DNS‏ backupdr.googleusercontent.com.
2. יוצרים רשומת A לדומיין backupdr.googleusercontent.com וכוללים את כל אחת מארבע כתובות ה-IP‏ 199.36.153.8,‏ 199.36.153.9,‏ 199.36.153.10,‏ 199.36.153.11 מרשת המשנה private.googleapis.com 199.36.153.8/30. אם אתם משתמשים ב-VPC Service Controls, השתמשו ב-199.36.153.4,‏ 199.36.153.5,‏ 199.36.153.6,‏ 199.36.153.7 מרשת המשנה 199.36.153.4/30 של restricted.googleapis.com.
3. יוצרים רשומת CNAME ל-*.backupdr.googleusercontent.com שמצביעה על שם הדומיין backupdr.googleusercontent.com.

כך אפשר לוודא שכל פענוח DNS של הדומיין הייחודי של מסוף הניהול של המכשיר עובר דרך גישה פרטית ל-Google.

מוודאים שבכללי חומת האש יש כלל תעבורת נתונים יוצאת (egress) שמאפשר גישה ב-TCP 443 לתת-הרשת 199.36.153.8/30 או 199.36.153.4/30. בנוסף, אם יש לכם כלל תעבורה יוצאת שמאפשר את כל התעבורה אל 0.0.0.0/0, הקישוריות בין מכשירי הגיבוי/השחזור לבין מסוף ניהול המכשירים אמורה לפעול.

יצירת קטגוריה של Cloud Storage

אם אתם רוצים להגן על מסדי נתונים ועל מערכות קבצים באמצעות סוכן ה-Backup and DR, ואז להעתיק את הגיבויים ל-Cloud Storage לשמירה לטווח ארוך, אתם צריכים קטגוריה של Cloud Storage. זה נכון גם לגבי גיבויים של מכונות וירטואליות של VMware שנוצרו באמצעות ממשקי API להגנה על נתונים באחסון של VMware vSphere.

ההרשאות שנדרשות למשימה הזו

כדי ליצור קטגוריה של Cloud Storage, צריך תפקיד שכולל את ההרשאות הבאות:

• storage.buckets.get
• storage.objects.create
• storage.objects.delete
• storage.objects.get
• storage.objects.list
• iam.serviceAccountKeys.create
התפקידים שכוללים את ההרשאות האלה הם Storage Admin ו-Editor.

יוצרים קטגוריה של Cloud Storage לפי ההוראות הבאות:

1. במסוף Google Cloud , נכנסים לדף Buckets של Cloud Storage.
   

   כניסה לדף Buckets

2. לוחצים על Create bucket.

3. נותנים שם לקטגוריה.

4. בוחרים אזור לאחסון הנתונים ולוחצים על המשך.

5. בוחרים סוג אחסון שיוגדר כברירת מחדל ולוחצים על Continue. אם משך השמירה הוא 30 יום או פחות, כדאי להשתמש ב-Nearline. אם משך השמירה הוא 90 יום או יותר, כדאי להשתמש ב-Coldline. אם תקופת השמירה היא בין 30 ל-90 ימים, כדאי להשתמש ב-Coldline.

6. משאירים את האפשרות בקרת גישה אחידה מסומנת ולוחצים על Continue. אל תשתמשו ב-fine-grained.

7. משאירים את ההגדרה None (ללא) בשדה Protection tools (כלי הגנה) ולוחצים על Continue (המשך). אל תבחרו אפשרויות אחרות כי הן לא פועלות עם Backup and DR.

8. לוחצים על יצירה.

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

   1. בוחרים את הקטגוריה החדשה כדי להציג את הפרטים שלה.

   2. עוברים אל הרשאות.

   3. בקטע Principals, מוודאים שחשבונות השירות החדשים מופיעים ברשימה. אם הם לא מופיעים, לוחצים על Add כדי להוסיף את חשבונות השירות לקריאה ולכתיבה כחשבונות משתמשים.

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

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

• פריסת Backup and DR