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

שירות 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 נפרס בפרויקט הניהול של הגיבוי, והוא עם זמינות גבוהה באזור הפריסה, כך שהוא מספק חוסן (resilience) מפני הפסקות חשמל אזוריות.

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

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

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

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

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

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

הפעלת 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. לסוג הזה של מכשיר יש קיבולת מינימלית של דיסק מתמשך של 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, בהתאם לצורך הצפוי שלכם לגשת לנתונים.

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

כללי חומת האש הנדרשים הבאים לתעבורת נתונים נכנסת (ingress) אל שירות 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 ומכשירי הגיבוי והשחזור.

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

אפשר להשתמש בשירות 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 * Querétaro
דרום אמריקה
southamerica-east1 סאו פאולו ‫סמל של עלה רמה נמוכה של CO2‎
southamerica-west1 סנטיאגו ‫סמל של עלה רמה נמוכה של CO2‎
אירופה
europe-central2 ורשה
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 מילאנו
europe-west9 פריז ‫סמל של עלה רמה נמוכה של CO2‎
europe-west10 ברלין
europe-west12 טורינו
המזרח התיכון
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 יפעיל את תהליך העבודה באזור us-central1 (המכשיר עצמו עדיין נוצר באזור שבחרתם). אם יש לכם מדיניות ארגונית שמוגדרת למניעת יצירת משאבים באזורים אחרים, אתם צריכים לעדכן באופן זמני את המדיניות הארגונית כדי לאפשר יצירת משאבים באזור us-central1. אפשר להגביל את האזור us-central1 אחרי הפריסה של מכשיר הגיבוי או השחזור.

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