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

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

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

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

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

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

הארכיטקטורה של Backup and DR מורכבת מהרכיבים הבאים:

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

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

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

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

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

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

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

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

הפעלת Google Cloud Backup and DR

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

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

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

  • ‫Standard למכונות וירטואליות של 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 מהסוגים הבאים:

    • קיבולת מינימלית של Persistent Disk: האפשרות הזו מספקת קיבולת דיסק מינימלית של 10GB. בסוג האחסון הזה, הגיבויים נשמרים כתמונות מצב של Persistent Disk ולא צורכים את האחסון המקומי של מכשיר הגיבוי/השחזור.
    • ‫Standard Persistent Disk: בחרו בסוג האחסון הזה אם אתם רוצים אחסון בלוקים יעיל. מומלץ להשתמש באפשרות הזו למכונות וירטואליות, למסדי נתונים או לאפליקציות של מערכת קבצים ב-Google Cloud VMware Engine עם קלט/פלט בינוני-גבוה, בנוסף למכונות וירטואליות של Compute Engine. כך מוסיפים קיבולת של 4TB ל-Persistent Disk כקיבולת הדיסק המינימלית.
    • ‫SSD Persistent Disk: בוחרים בסוג האחסון הזה אם רוצים אחסון בלוקים מהיר. מומלץ להשתמש בזה ב-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 Storage, ל-Nearline Storage ול-Coldline Storage, בהתאם לצורך הצפוי בגישה לנתונים.

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

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

מטרה מקור יעד יציאה (TCP)
תנועת תמיכה (תמיכה במכשיר) SSH_CLIENT_IP מכשיר לגיבוי או לשחזור 26
גיבוי iSCSI (ממארח למכשיר) AGENT_HOST_IP מכשיר לגיבוי או לשחזור 3260
תנועה ב-StreamSnap (ממכשיר למכשיר) 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 מארח שמפעיל את Agent או מארח ESXi שמפעיל את הטעינה מכשיר לגיבוי או לשחזור 111, 756, 2049, 4001, 4045

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

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

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

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

אפשר להשתמש ב-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 אזור.

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

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