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 * |
מונטריאול |
|
|
northamerica-northeast2 |
טורונטו |
|
|
us-central1 |
אייווה |
|
|
us-east1 |
דרום קרוליינה | ||
us-east4 |
צפון וירג'יניה | ||
us-east5 |
קולומבוס | ||
us-south1 |
דאלאס |
|
|
us-west1 |
אורגון |
|
|
us-west2 |
לוס-אנג׳לס | ||
us-west3 |
סולט לייק סיטי | ||
us-west4 |
לאס וגאס | ||
northamerica-south1 * |
קוורטארו | ||
| דרום אמריקה | |||
southamerica-east1 |
סאו פאולו |
|
|
southamerica-west1 |
סנטיאגו |
|
|
| אירופה | |||
europe-central2 |
ורשה |
|
|
europe-north1 |
פינלנד |
|
|
europe-north2 |
שטוקהולם |
|
|
europe-southwest1 |
מדריד |
|
|
europe-west1 |
בלגיה |
|
|
europe-west2 |
לונדון |
|
|
europe-west3 |
פרנקפורט | ||
europe-west4 |
הולנד |
|
|
europe-west6 |
ציריך |
|
|
europe-west8 |
מילאנו |
|
|
europe-west9 |
פריז |
|
|
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 יפעיל את ה-Workflow באזור us-central1 (המכשיר עצמו עדיין נוצר באזור שבחרתם). אם יש לכם מדיניות ארגונית שמוגדרת למניעת יצירת משאבים באזורים אחרים, אתם צריכים לעדכן באופן זמני את המדיניות הארגונית כדי לאפשר יצירת משאבים באזור us-central1. אפשר להגביל את האזור us-central1 אחרי הפריסה של מכשיר הגיבוי או השחזור.