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

‫Backup and DR תומך בגיבוי של מופעי Cloud SQL, אשכולות AlloyDB ומופעים ודיסקים בודדים של Compute Engine מתוךGoogle Cloud המסוף. ההליכים לגיבוי ולשחזור של המשאבים האלה מפורטים במסמכים שלהם. אם כל עומסי העבודה שלכם מתאימים לקטגוריות האלה, אתם לא צריכים מכשיר גיבוי או שחזור.

כדי לגבות ולשחזר מכונות וירטואליות של VMware ומסדי נתונים של SAP HANA, ‏ IBM Db2, ‏ Oracle ו-Microsoft SQL Server שפועלים בתוך מכונות וירטואליות של Compute Engine, צריך מסוף ניהול של מכשיר Backup and DR ומכשיר אחד או יותר לגיבוי/שחזור. כשמשתמשים בהגדרה הזו, צריך לבחור את הגודל של מכשירי הגיבוי והשחזור כך שיתאים לאפליקציות שמגבים. תהליך ההגדרה הזה כולל יצירת שרת ניהול, פריסת מכשירים ואז שימוש במסוף לניהול מכשירים כדי להגדיר לוחות זמנים לגיבוי ולהגדיר מה מגבים ולאן.

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

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

רכיבים בארכיטקטורה של מכשיר הגיבוי או השחזור

ארכיטקטורת ה-Backup and DR מועברת דרך הרכיבים הבאים:

  • Google Cloud המסוף: המסוף Google Cloud כולל את המוצר Backup and DR לניהול מרכזי של הגיבויים המאובטחים של Persistent Disk, תוכניות גיבוי למופעי Compute Engine וגיבוי משופר ל-Cloud SQL במוצרים האלה.

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

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

  • סוכני Backup and DR: סוכן ה-Backup and DR קורא לממשקי ה-API המקוריים של האפליקציה כדי ללכוד נתונים ביעילות מאפליקציות בייצור באופן מצטבר, ומספק את ה-Application Awareness בזמן השחזור. הסוכן מותקן במארחי אפליקציות שבהם נמצאות האפליקציות שרוצים להגן עליהן. אם אתם מגנים רק על המכונה הווירטואלית כולה או על קבוצת משנה של הדיסקים שלה, לא צריך את הסוכן Backup and DR.

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

התקשורת בין שרת הניהול לבין מכשירי ה-appliance, בין מכשירי ה-appliance לבין עצמם ובין מכשירי ה-appliance לבין סוכני המארח מאובטחת באמצעות אימות TLS בו-זמני (mTLS).

הגדרת Backup and DR במסוף Google Cloud

נכנסים למסוף Google Cloud כדי להפעיל את backupdr API ולהגדיר הרשאות לחשבון:

הפעלת Google Cloud Backup and DR

סוגי מכשירים לגיבוי או לשחזור

‫Backup and DR מספק סוגים של מכשירים וירטואליים שעברו אופטימיזציה לעומסי עבודה שונים – מכונות וירטואליות ב-Compute Engine, מכונות וירטואליות ב-VMware, מסדי נתונים ומערכות קבצים. אתם יכולים לבחור את סוג המכשיר שהכי מתאים לצרכים שלכם. חשוב לבחור את סוג המכשיר המתאים ביותר לעומסי העבודה שלכם. אחרי שמכשיר הגיבוי או השחזור מתחיל לפעול, הוא פועל ברציפות כל הזמן, ומוכן תמיד להפעיל מחדש גיבוי, שחזור ועבודות אחרות.

Backup and DR מספק את סוגי המכשירים הבאים:

  • סטנדרט למכונות וירטואליות של VMware ולמסדי נתונים או משאבים אחרים: סוג המכונה n2-standard-16 תומך בביצועים אופטימליים לגיבוי של מסדי נתונים של ייצור, מכונות וירטואליות של VMware ומשאבים אחרים. הציוד הזה מוסיף 4TB של קיבולת דיסק מאוזנת בזמן הפריסה, ואפשר להוסיף עוד 63 דיסקים של 4TB. המכשיר הזה יכול לנהל עד 1,500 אפליקציות ו-5,000 תמונות מצב יומיות.
  • Standard למכונות וירטואליות של Compute Engine או למסדי נתונים של SAP HANA: סוג המכונה e2-standard-4 מתאים במיוחד לגיבוי של מכונות וירטואליות של Compute Engine, מכונות של Cloud SQL, אשכולות של AlloyDB ומשאבי נתונים שמשתמשים ב-Persistent Disk לגיבויים: מסדי נתונים של IBM Db2 ו-SAP HANA שהוגדרו לשימוש ב-Persistent Disk. לסוג המכשיר הזה יש קיבולת מינימלית של דיסק קשיח (Persistent Disk) של 10GB. האפליקציה הזו יכולה לנהל עד 5,000 מכונות של Compute Engine ומכונות של Cloud SQL, אשכולות של AlloyDB ואפליקציות נתונים שמבוססות על Persistent Disk.
  • ‫Basic למכונות וירטואליות של VMware ולמסדי נתונים או למשאבים אחרים: סוג המכונה e2-standard-16 תומך בביצועים בינוניים לגיבוי מסדי נתונים, מכונות וירטואליות של VMware ומשאבים אחרים. המכשיר הזה יכול לנהל עד 1,500 אפליקציות ו-5,000 תמונות מצב יומיות. התקן זה מוסיף 4TB של קיבולת דיסק רגילה בזמן הפריסה, ואפשר להוסיף 63 דיסקים נוספים של 4TB מהסוגים הבאים:

    • קיבולת מינימלית של דיסק מתמיד: האפשרות הזו מספקת קיבולת מינימלית של 10GB. בסוג האחסון הזה, הגיבויים מאוחסנים כתמונות מצב של דיסק מתמיד (Persistent Disk) ולא תופסים מקום באחסון המקומי של מכשיר הגיבוי או השחזור.
    • Standard Persistent Disk: בוחרים את סוג האחסון הזה אם רוצים אחסון בלוקים יעיל. מומלץ להשתמש ב-Google Cloud VMware Engine למכונות וירטואליות, למסדי נתונים או לאפליקציות של מערכות קבצים עם קלט/פלט בינוני עד גבוה, בנוסף למכונות וירטואליות של Compute Engine. כך מתווסף נפח של 4TB ל-Persistent Disk כנפח המינימלי של הדיסק.
    • דיסק מתמיד שמבוסס על SSD: בוחרים את סוג האחסון הזה אם רוצים אחסון בלוקים (block storage) מהיר. מומלץ להשתמש בשיטה הזו ב-Google Cloud VMware Engine, במסדי נתונים או באפליקציות של מערכת קבצים עם קלט/פלט גבוה מאוד, בנוסף למכונות וירטואליות ב-Compute Engine. כך מוסיפים 4TB של קיבולת Persistent Disk כקיבולת המינימלית של הדיסק.

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

השם של חשבון השירות מופיע בפורמט של כתובת האימייל:

APPLIANCE_NAME@PROJECT_ID.iam.gserviceaccount.com

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

  • ‫APPLIANCE_NAME: השם של המכשיר לגיבוי או לשחזור.
  • ‫PROJECT_ID: מזהה הפרויקט (המקור) שלכם Google Cloud .

אתם יכולים להעביר גיבויים שצריך לשמור לטווח ארוך ל-Standard,‏ Nearline ו-Coldline Storage, בהתאם לצורך הצפוי שלכם לגשת לנתונים.

הגדרות חומת אש

כללי חומת האש הנדרשים הבאים לתעבורת נתונים נכנסת אל Backup and DR מתווספים באופן אוטומטי.

מטרה מקור יעד יציאה (TCP)
תנועת נתונים של תמיכה (תמיכה במכשיר) SSH_CLIENT_IP מכשיר לגיבוי או לשחזור 26
גיבוי iSCSI (ממארח למכשיר) AGENT_HOST_IP מכשיר לגיבוי או לשחזור 3260
תנועה של StreamSnap (מ-appliance ל-appliance) SOURCE_APPLIANCE_IP מכשיר לגיבוי או לשחזור 5107
קישוריות של מכשיר לגיבוי או לשחזור למסוף הניהול של המכשיר APPLIANCE_IP ‫*.backupdr.googleusercontent.com 443

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

  • ‫SSH_CLIENT_IP: כתובת ה-IP של המארח שבו פועל לקוח ה-SSH.
  • ‫AGENT_HOST_IP: כתובת ה-IP של המארח שבו פועל סוכן Backup and DR.
  • ‫SOURCE_APPLIANCE_IP: כתובת ה-IP של מכשיר המקור.
  • ‫APPLIANCE_IP: כתובת ה-IP או רשת המשנה של המכשיר לגיבוי או לשחזור.

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

לכל מארח שמופעל בו סוכן Backup and DR, צריך להוסיף ידנית את יציאת ה-TCP הבאה כדי לאפשר קישוריות באמצעות כלל חומת אש של תעבורת כניסה.

מטרה מקור יעד יציאה (TCP)
תנועת נציגים (מכשיר לאירוח) מכשיר לגיבוי או לשחזור מארח שמריץ את סוכן Backup and DR 5106

במארחים שמשתמשים ב-NFS לתעבורת גיבוי, או במארחי ESX שפועלים ב-Google Cloud VMware Engine ומשתמשים ב-NFS לחיבורים, צריך להוסיף באופן ידני את יציאות ה-TCP וה-UDP הבאות כדי לאפשר קישוריות באמצעות כלל חומת אש של תעבורת נכנסת.

מטרה מקור יעד יציאה (TCP/UDP)
גיבוי או טעינה של NFS מארח שמריץ סוכן או מארח ESXi שמריץ טעינה מכשיר לגיבוי או לשחזור ‫111, ‏ 756, ‏ 2049, ‏ 4001, ‏ 4045

רשימת ההרשאות שמשמשות במהלך הפעולה הזו מופיעה במאמר הפניה להרשאות ההתקנה של Backup and DR.

אזורים נתמכים

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

אזורים נתמכים במסוף לניהול מכשירים

אפשר להשתמש ב-Backup and DR כדי לגבות עומסי עבודה נתמכים בכלGoogle Cloud אזור, אבל אפשר להפעיל את מסוף ניהול המכשירים רק באזורים הבאים:

אזור גיאוגרפי שם האזור תיאור האזור
צפון אמריקה
northamerica-northeast1 * מונטריאול ‫סמל של עלה רמה נמוכה של CO2‎
northamerica-northeast2 טורונטו ‫סמל של עלה רמה נמוכה של CO2‎
us-central1 אייווה ‫סמל של עלה רמה נמוכה של CO2‎
us-east1 דרום קרוליינה
us-east4 צפון וירג'יניה
us-east5 קולומבוס
us-south1 דאלאס ‫סמל של עלה רמה נמוכה של CO2‎
us-west1 אורגון ‫סמל של עלה רמה נמוכה של CO2‎
us-west2 לוס-אנג׳לס
us-west3 סולט לייק סיטי
us-west4 לאס וגאס
northamerica-south1 * קוורטארו
דרום אמריקה
southamerica-east1 סאו פאולו ‫סמל של עלה רמה נמוכה של CO2‎
southamerica-west1 סנטיאגו ‫סמל של עלה רמה נמוכה של CO2‎
אירופה
europe-central2 ורשה ‫סמל של עלה רמה נמוכה של CO2‎
europe-north1 פינלנד ‫סמל של עלה רמה נמוכה של CO2‎
europe-north2 שטוקהולם ‫סמל של עלה רמה נמוכה של CO2‎
europe-southwest1 מדריד ‫סמל של עלה רמה נמוכה של CO2‎
europe-west1 בלגיה ‫סמל של עלה רמה נמוכה של CO2‎
europe-west2 לונדון ‫סמל של עלה רמה נמוכה של CO2‎
europe-west3 פרנקפורט
europe-west4 הולנד ‫סמל של עלה רמה נמוכה של CO2‎
europe-west6 ציריך ‫סמל של עלה רמה נמוכה של CO2‎
europe-west8 מילאנו ‫סמל של עלה רמה נמוכה של CO2‎
europe-west9 פריז ‫סמל של עלה רמה נמוכה של CO2‎
europe-west10 ברלין
europe-west12 טורינו ‫סמל של עלה רמה נמוכה של CO2‎
המזרח התיכון
me-central1 דוחה
me-central2 דמאם
me-west1 ישראל
אפריקה
africa-south1 יוהנסבורג
אסיה ואזור האוקיינוס השקט
asia-east1 טייוואן
asia-east2 הונג קונג
asia-northeast1 טוקיו
asia-northeast2 * אוסקה
asia-northeast3 סיאול
asia-southeast1 סינגפור
asia-southeast2 ג'קארטה
australia-southeast1 סידני
australia-southeast2 מלבורן
הודו
asia-south1 מומבאי
asia-south2 דלהי

‫* בקוורטרו (northamerica-south1), במונטריאול (northamerica-northeast1) ובאוסקה (asia-northeast2) אין תמיכה בהפרדה בין אזורים. כלומר, יכול להיות שהאזורים המרובים בכל אחד מהאזורים האלה לא ממוקמים בקמפוסים נפרדים פיזית של מרכזי נתונים. לכן, אירוע אסון פיזי מקומי יחיד עלול להשפיע על כמה אזורים באותו אזור, ולהגדיל את הסיכון לאובדן נתונים בהשוואה לאזורים שתומכים בהפרדה בין אזורים.

אזורים נתמכים של מכשירים לגיבוי או לשחזור

אפשר לפרוס מכשירים לגיבוי או לשחזור בכל אזורGoogle Cloud .

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

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