תכנון של תוכנית התאוששות מאסון (DR)
בדף הזה מפורט מידע שיעזור לכם לתכנן התאוששות מאסון לעומסי העבודה שפועלים בסביבת Bare Metal Solution.
Bare Metal Solution מסופק מתוסף אזורי. החל מפברואר 2024, כל האזורים של Bare Metal Solution מאוחסנים פיזית במתקנים שאינם של Google. בגלל מודל הרחבת האזור, Bare Metal Solution לא פועל לפי מודל ההפרדה הרגיל בין אזורים שמשמש שירותים אחרים של Google Cloud Google, כמו Compute Engine. כל פריסה של Bare Metal Solution בתוך אזור הרחבה נקראת pod. באזורים מסוימים, משאבי Bare Metal Solution מוגשים מכמה תאי שרתים, אבל אין דרישה או ציפייה שתאי השרתים יהיו מופרדים גיאוגרפית.
אם אתם מפעילים עומסי עבודה שחיוניים לעסק, מומלץ לתכנן התאוששות מאסון.
משאבים מומלצים לתכנון התאוששות מאסון
מומלץ לעיין במשאבים הבאים כדי לתכנן התאוששות מאסון:
- תכנון של תוכנית התאוששות מאסון (DR) (המסמך הזה)
- Google Cloud מדריך להכנת תוכנית התאוששות מאסון (כולל הנחיות נוספות שיעזרו לכם להטמיע את תוכנית ההתאוששות מאסון)
- אפשרויות להתאוששות מאסון (DR) לעומסי עבודה של מסדי נתונים של Oracle (רלוונטי אם אתם מריצים עומסי עבודה של מסדי נתונים של Oracle)
קישוריות בין תאי שרתים
ל-Pods ולתוספים אזוריים אין קישוריות ישירה. כל התנועה (נכנסת ויוצאת) של פריסת Bare Metal Solution עוברת דרך קישוריות הדדית ודרך עמוד השדרה של Google Cloud . אין נתיב נתונים נתמך לשכפול ברמת האחסון. כך נמנעות אפשרויות של התאוששות מאסון שמבוססות על טכנולוגיות אחסון, כמו שכפול של אחסון ברמת הבלוק או שכפול של תמונת מצב מרחוק.
תכנון אזור להתאוששות מאסון
בדרך כלל בוחרים אזור של Bare Metal Solution על סמךGoogle Cloud שירותים אחרים שבהם משתמשים. עם זאת, התאוששות מאסון (DR) למסדי נתונים בדרך כלל תואמת לאזורים שמשמשים לאפליקציות המתאימות ולאינטגרציות שלהן. לכן, כשמתכננים באילו אזורים רוצים להשתמש לצורך התאוששות מאסון, צריך לקחת בחשבון את זמן האחזור ברשת בין האזורים.
בהתאם לתחום הפעילות שלכם, יכול להיות שיש דרישות רגולטוריות לגבי מיקום הנתונים, שמכתיבות איפה אפשר לשכפל נתונים. לכל אפליקציה יש דרישות משלה, ולכן אתם צריכים לבחור את האזור הספציפי להתאוששות מאסון.
שיקולים לגבי רשתות
בידוד תנועה לחיבור בין רשתות
במקרים רבים, כדאי לבודד את תנועת השכפול מהפעלות של אפליקציות.
כדי לבודד את התנועה, אפשר להקצות חיבורי Partner Interconnect נפרדים בכל אזור שמסתיימים ב-VPC למעבר שמשמש לשכפול. התרשים הבא מתאר את סוג ההגדרה הזה.
בתרשים, השרתים של Bare Metal Solution באזור us-west2 משתמשים ברשת 10.10.10.0/24, והשרתים של Bare Metal Solution באזור us-east4 משתמשים ברשת 10.20.20.0/24. פרויקט המשתמש מכיל רשתות VPC נפרדות לתנועת נתונים של אפליקציות ולתנועת נתונים של שכפול, בשמות Application VPC ו-Replication VPC, בהתאמה. ההודעות של פרוטוקול BGP מוגדרות כך שכל Cloud Router ב-Replication VPC מפרסם נתיב לרשת Bare Metal Solution בין אזורים, וכך מאלץ את התנועה בין האזורים לעבור דרך Replication VPC. נתבי Cloud ב-Application VPC
מפרסמים נתיב כללי 0.0.0.0/0או נתיבים לבלוקים ספציפיים של CIDR שהשרתים של Bare Metal Solution צריכים לתקשר איתם. בדוגמה הזו, נעשה שימוש ב-0.0.0.0/0 כדי לציין מסלול ששולח תנועה לכל יעד אחר.
שרתי האפליקציות ושירותים אחרים שמתחברים ממרכזי נתונים מקומיים מתחברים דרך Application VPC. המופעים ב-Application VPC עדיין יכולים לתקשר עם מסדי נתונים שפועלים בתוסף האזור של Bare Metal Solution.
אפשר גם להשתמש בחיבורי הרשת שמסתיימים ב-VPC המרכזי כדי לגשת לשירותים כמו Cloud Storage, Filestore או Backup and DR. כדי לעשות את זה, צריך ליצור את מופע Filestore ב-VPC המרכזי או להשתמש בנקודות קצה של Private Service Connect שנמצאות ב-VPC המרכזי.Google Cloud