העברת הגדרת גיבוי של מכונה ב-Compute Engine ממסוף הניהול של האפליקציה אל כספת גיבוי

אתם יכולים להעביר את ההגנה על מכונה של Compute Engine מתוכנית הגיבוי של מסוף הניהול של המכשיר לתוכנית גיבוי של כספת גיבוי, באמצעות הגנה על מכונה של Compute Engine, בלי לגרום לשיבושים, להסיר את סוכן הגיבוי, לבצע התאמת רשתות (peering) או לבצע שינויים בחומות האש של ה-VPC.

יתרונות

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

• חיסכון מיידי בעלויות: הפחתת דמי הניהול מיד בסיום ההעברה.

• תשתית יעילה: מעבר למודל ללא תשתית שמייתר את הצורך במכשירי גיבוי, וכך מפחית את עלות הבעלות הכוללת (TCO).

• ניהול חלק: שימוש במסוף משולב Google Cloud עם תמיכה מלאה ב-ה-CLI של gcloud, ב-Terraform ובממשקי API של Google Cloud לאוטומציה בקנה מידה נרחב ובקלות.

• תמיכה מורחבת: פלטפורמה מאוחדת שתומכת גם ב-Cloud SQL, ב-AlloyDB ל-PostgreSQL וב-Filestore.

• זמין בכל האזורים של Google Cloud .

מגבלות

• אי אפשר להעביר את הנתונים אם תוכנית הגיבוי הנוכחית של מסוף ניהול המכשירים או ההגדרות של המכונה ב-Compute Engine כוללות את אחת מהתכונות הבאות:

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

  • מכונות של Compute Engine שמשתמשות ב-Google Cloud Hyperdisk.

  • מכונות של Compute Engine שמחריגות דיסקים ספציפיים מגיבויים.

• אפשר להעביר רק מכונות רגילות של Compute Engine. אי אפשר להעביר באמצעות הדף הזה סוגים אחרים של עומסי עבודה של אפליקציות, כמו Microsoft SQL,‏ SAP HANA,‏ Oracle ומכונות וירטואליות של VMware.

• אי אפשר להעביר גיבויים קיימים.

לתשומת ליבכם

• כדי לבצע העברה בכמות גדולה, צריך סקריפט העברה שיבצע את המעבר באופן אוטומטי בסביבות בקנה מידה גדול. פנו ל-Cloud Customer Care כדי לקבל סקריפט להעברה בכמות גדולה.

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

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

• מומלץ להימנע מהעברת מכונות וירטואליות שמשתמשות ב-Google Cloud Hyperdisk.

• התפקידים הקיימים של שירות הגיבוי וההתאוששות מאסון ממשיכים לפעול כצפוי. עם זאת, אם אתם מתכננים לגבות מכונות של Compute Engine מכמה פרויקטים של שירות לכספת גיבוי מרכזית אחת (כלומר, כספת גיבוי שנוצרה בפרויקט גיבוי מרכזי), אתם צריכים להקצות את התפקיד "מפעיל של Backup and DR ב-Compute Engine" (roles/backupdr.computeEngineOperator) לסוכן השירות של כספת הגיבוי בכל פרויקטי השירות שמארחים את המכונות שצריך לגבות. מידע נוסף זמין במאמר הקצאת תפקיד לסוכן השירות.

איך זה עובד

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

בסיום ההעברה, תוכלו לראות את נקודות השחזור ההיסטוריות במסוף הניהול של המכשיר, ואת נקודות השחזור החדשות במסוף Google Cloud .

כדי להעביר את המכונה של Compute Engine ממסוף הניהול של המכשיר לכספת גיבוי, מבצעים את הפעולות הבאות:

1. הגדרת הגנה: משתמשים בפקודה MigrateToBackupVault כדי להגן על מכונות Compute Engine באמצעות תוכנית גיבוי של כספת גיבוי.

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

3. הסרת ההגנה ממסוף הניהול של המכשיר: משתמשים בפקודה UnprotectVMsFromManagementConsole כדי להסיר את ההגנה ממסוף הניהול של המכשיר.

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

1. מוודאים שיש את ההרשאות הנדרשות כדי להשלים את ההדרכה.

2. ודאו שיש לכם את המשאבים הבאים:

   • כספת גיבוי קיימת. איך יוצרים כספת גיבוי?
   • תוכנית גיבוי קיימת שמוגדרת לשימוש בכספת הגיבוי. יוצרים את תוכנית הגיבוי הזו במסוף Google Cloud . היא יכולה להיות זהה לתוכנית הגיבוי של מסוף הניהול של המכשיר. להוראות, ראו יצירת תוכנית גיבוי.

התפקידים הנדרשים

כדי לקבל את ההרשאות שנדרשות להעברת הגדרת גיבוי של מכונה ב-Compute Engine, צריך לבקש מהאדמין להקצות לכם את תפקידי ה-IAM הבאים בפרויקט:

• אדמין של Backup and DR (תפקיד מדור קודם לפעולות במסוף הניהול של המכשיר)
• אדמין ב-Backup and DR ‏(roles/backupdr.admin)

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

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

התקנת כלי ההעברה

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

Google Cloud Shell

1. פותחים את Cloud Shell במסוף Google Cloud .

2. לוחצים על סמל האפשרויות הנוספות ואז על העלאה.

3. בוחרים את הקובץ backupdr_gcevm_migration_tool.

4. הופכים את הכלי לקובץ הפעלה:

   chmod +x ~/backupdr_gcevm_migration_tool
   

5. מפעילים את הכלי באמצעות ~/backupdr_gcevm_migration_tool.

סביבה מקומית

1. מורידים את קובץ ההפעלה של backupdr_gcevm_migration_tool.

2. מתקינים את ה-CLI של gcloud ומאמתים אותו. למידע נוסף, קראו את המאמר התקנת ה-CLI של gcloud.

3. מעבירים את קובץ ההפעלה לספרייה, לדוגמה ~/tools, והופכים אותו לקובץ הפעלה:

   mkdir -p ~/tools
   mv ~/Downloads/backupdr_gcevm_migration_tool ~/tools/
   chmod +x ~/tools/backupdr_gcevm_migration_tool
   

4. אופציונלי: כדי להריץ את הכלי מכל ספרייה, מוסיפים אותו ל-PATH. מוסיפים את השורה הבאה לקובץ ~/.bashrc או ~/.zshrc:

   export PATH="$PATH:$HOME/tools"
   

5. טוענים מחדש את המעטפת:

   source ~/.bashrc
   

העברת מכונות של Compute Engine

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

הגנה על מכונות Compute Engine באמצעות תוכנית גיבוי בכספת גיבוי

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

1. מריצים את הפקודה MigrateToBackupVault:

   ./backupdr_gcevm_migration_tool MigrateToBackupVault \
     --slt_name=SLT_NAME \
     --management_server_url=MANAGEMENT_SERVER_URL \
     --backup_plan=projects/PROJECT_ID/locations/REGION/backupPlans/BACKUP_PLAN_NAME \
     --workload_projects=PROJECT_ID_1,PROJECT_ID_2 \
     --apply \
     --trigger_backup
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫SLT_NAME: השם של תוכנית הגיבוי של מסוף הניהול של מכשיר המקור (לשעבר תבנית רמת שירות או SLT).
   • ‫MANAGEMENT_SERVER_URL: כתובת ה-URL של מסוף הניהול של המכשיר.
   • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
   • ‫REGION: האזור שבו נמצאת תוכנית הגיבוי.
   • ‫BACKUP_PLAN_NAME: השם של תוכנית הגיבוי שרוצים להחיל.
   • ‫PROJECT_ID_1,PROJECT_ID_2: רשימה מופרדת בפסיקים של מזהי פרויקטים שמכילים מכונות Compute Engine, או all.

   דגלים נוספים:

   • ‫--apply: מפעיל את ההגנה. אם משמיטים את הפרמטר, הכלי פועל במצב הרצת בדיקה.
   • ‫--trigger_backup: הפעלה של גיבוי לפי דרישה מיד אחרי שההגנה מופעלת.

   הפקודה יוצרת קובץ פלט בשם MigrateToBackupVault_{slt_name}_output.txt שמסכם את הפעולות שבוצעו ואת הסטטוס של המכונה הווירטואלית.

2. כדי לוודא שהמכונות מוגנות על ידי תוכנית הגיבוי, נכנסים לדף Backup and DR > Vaulted Backups במסוף Google Cloud .

ביטול ההגנה על מכונות Compute Engine ממסוף הניהול של המכשיר

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

1. מריצים את הפקודה UnprotectVMsFromManagementConsole:

   ./backupdr_gcevm_migration_tool UnprotectVMsFromManagementConsole \
     --slt_name=SLT_NAME \
     --management_server_url=MANAGEMENT_SERVER_URL \
     --workload_projects=PROJECT_ID_1,PROJECT_ID_2 \
     --apply
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫SLT_NAME: השם של תוכנית הגיבוי של מסוף הניהול של המכשיר המקורי.
   • ‫MANAGEMENT_SERVER_URL: כתובת ה-URL של מסוף הניהול של המכשיר.

   • ‫PROJECT_ID_1,PROJECT_ID_2: רשימה מופרדת בפסיקים של מזהי פרויקטים או all.

     דגלים נוספים:

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

הפקודה יוצרת קובץ פלט בשם UnprotectVMsFromManagementConsole_{slt_name}_output.txt שמסכם את הפעולות.

1. מוודאים שהמכונות שעומדות בדרישות כבר לא מוגנות במסוף הניהול של המכשיר.

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

הצפנה

כספת הגיבוי תומכת באופן מלא במפתחות הצפנה בניהול הלקוח (CMEK) למכונות Compute Engine, ומאפשרת לכם להצפין את הגיבויים באמצעות מפתחות הצפנה משלכם.

שינויים במעקב, בדיווח ובהתראות

אחרי המיגרציה, אתם משתמשים ב-Cloud Monitoring וב-Cloud Logging לצורך ניראות (observability), במקום בדוח שנשלח באימייל של מסוף הניהול המדור קודם. כך תוכלו ליצור מרכזי בקרה בהתאמה אישית ולהגדיר התראות ישירות במסוףGoogle Cloud . במאמר מבוא להתראות מוסבר איך מתזמנים התראות באימייל או מגדירים מדיניות התראות ממרכזי הבקרה למעקב.

גישה לנתוני דיווח היסטוריים

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

אם אתם רוצים לנתח ביחד ב-BigQuery את הנתונים שלפני ההעברה ואחריה, אתם יכולים לנתב את היומנים למערך נתונים ב-BigQuery באמצעות sink ביומן. כדי להגדיר sink ביומן ודוחות מוכנים מראש, קראו את המאמר הגדרת דוחות מוכנים מראש ב-BigQuery.

אחרי שהיומנים נמצאים ב-BigQuery, אתם יכולים:

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

• ליצור דוחות והמחשות חזותיות בהתאמה אישית של התשתית באמצעות Data Studio. מידע נוסף זמין במאמר מבוא ל-Data Studio.

• הגדרת התראות מבוססות-יומנים במסוף Google Cloud . למידע נוסף, קראו את המאמר הגדרת התראות מבוססות-יומן.

הפעלת סביבה היברידית

יש תמיכה מלאה בסביבה היברידית. כדי ליהנות מהיתרונות של עלות ואבטחה, מומלץ להעביר מיד את כל המכונות המתאימות של Compute Engine לכספת גיבוי. עם זאת, אם הסביבה שלכם כוללת הגדרות שכספת הגיבוי לא תומכת בהן, אתם יכולים להמשיך להגן על המכונות האלה באמצעות מסוף הניהול של המכשיר. כשהתכונות האלה ייתמכו ב-"גיבוי ו-DR", תוכלו להעביר את המכונות שנותרו לכספת הגיבוי. אם יש לכם שאלות לגבי הגדרות נתמכות, תוכלו לפנות ל-Cloud Customer Care.

חזרה למצב הקודם של ההעברה

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

הגיבויים ההיסטוריים של המכונות שנוצרו לפני המעבר החד למערכת אחרת (cutover) עדיין זמינים ונגישים במסוף הניהול של המכשיר. אתם יכולים לגשת לגיבויים חדשים שנוצרו בכספת הגיבוי ישירות במסוף Google Cloud .

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

• מידע נוסף על תוכניות גיבוי במסוף הניהול של המכשיר
• איך מנהלים את הגיבויים במסוף Google Cloud