המסמך הזה מיועד לאדמינים של מערכות, למומחי Cloud Architect ולמפתחי אפליקציות שאחראים על שמירת הזמינות והחוסן של אפליקציות ב-OpenShift Container Platform שנפרס ב-Google Cloud.
המסמך הזה הוא חלק מסדרה שמתמקדת באסטרטגיות ברמת האפליקציה שמבטיחות שעומסי העבודה שלכם יישארו זמינים מאוד וניתנים לשחזור מהיר במקרה של כשלים. המסמכים בסדרה הזו הם:
- שיטות מומלצות לתוכנית התאוששות מאסון (DR) (הדף הזה)
- שיטות מומלצות לזמינות גבוהה
- אסטרטגיות להתאוששות מאסון (DR) בהגדרות פעילות-סבילה
- אסטרטגיות להתאוששות מאסון (DR) בהגדרות פעילות-לא פעילות
תכנון DR
תכנון התאוששות מאסון הוא רכיב חיוני בהפעלת עומסי עבודה של ייצור בענן. למרות ש-OpenShift ו- Google Cloud מציעים יתירות חזקה ברמת התשתית, אתם צריכים גם לתכנן ולהגדיר את האפליקציות שלכם כך שיוכלו להתאושש במהירות מכשלים קריטיים.
תכנון יעיל של DR כולל גישה רב-שכבתית. מתחילים בהגדרה של יעדי משך התאוששות (RTO) ויעדי נקודת התאוששות (RPO) ברורים לאפליקציה ולמערכת, כדי לאפשר פריסה מחדש מהירה.
בנוסף, צריך להיות אפשר לשחזר את הסודות ואת פרטי הכניסה, ולנהל אותם בצורה מאובטחת. אם לוקחים בחשבון את כל הגורמים האלה, אפשר להשיג מצב של התאוששות מאסון שמאפשר ליצור במהירות אשכול OpenShift חדש באזור אחר או לבצע מעבר לגיבוי פעיל לאשכול משני לא פעיל. האשכול המשני הזה נשאר במצב אופליין עד שמתרחשת תקלה. בשלב הזה הוא מופעל ועובר למצב אונליין כדי להשתלט על הפעולות עם זמן השבתה מינימלי.
ארכיטקטורות ל-DR
יש אפשרויות שונות לארכיטקטורות פריסה שאפשר להשתמש בהן להתאוששות מאסון עם OpenShift ב- Google Cloud. לכל אחת מהאפשרויות האלה יש השלכות שונות על העלות, המורכבות והזמינות. בטבלה הבאה מופיעה סקירה כללית של הארכיטקטורות האלה:
| ארכיטקטורה | תיאור | תרחיש לדוגמה | יתרונות | חסרונות |
|---|---|---|---|---|
| פעיל-סביל | קלאסטר אחד פעיל ומטפל בכל התנועה, והקלאסטר השני פסיבי ומוכן להשתלט על התנועה. הנתונים משוכפלים לאשכול הפסיבי. | מתאים לאפליקציות עם דרישות מתונות של RTO ו-RPO. | קל יותר להטמיע, עלות נמוכה יותר עבור אשכול במצב המתנה. | זמן השבתה ארוך יותר בגלל זמן המעבר לגיבוי, עיכובים אפשריים בסנכרון הנתונים. |
| פעיל-לא פעיל | בדומה לגישת active-passive, אבל לא נעשה שימוש באשכול הלא פעיל עד לאירוע DR. הנתונים מגובים באופן קבוע. | מתאים לסביבות שבהן העלות היא שיקול חשוב, ושאפשר להרשות לעצמכם זמן התאוששות ארוך יותר (RTO) ונקודת התאוששות ארוכה יותר (RPO). | עלות תפעול נמוכה יותר כשהמערכת לא פעילה, מתאים ל-DR שבו מערכת משנית לא פועלת באופן פעיל (cold DR). | זמן ההתאוששות (RTO) גבוה יותר בגלל זמן ההפעלה והסנכרון, למרות שיש סיכוי שהנתונים יהיו לא עדכניים. |
| פעיל-פעיל | שני האשכולות פעילים ומטפלים בתעבורה באמצעות איזון עומסים ושכפול נתונים בין אזורים. | אפליקציות קריטיות שדורשות זמן השבתה מינימלי וזמינות גבוהה. | הזמן הקצר ביותר עד לחזרה לפעילות (RTO) והזמן הקצר ביותר עד לשחזור נקודת זמן (RPO), זמינות רציפה. | מורכבות ועלות גבוהות ביותר, נדרשת רשת חזקה וסנכרון נתונים. |
המאמרים הבאים
- איך מטמיעים מעקב והתראות לגבי תקינות האשכול, סטטוס השכפול, הצלחת הגיבוי וביצועי האפליקציה בסביבות ראשוניות ומשניות.
- כך מתקינים את OpenShift ב- Google Cloud.
- מידע נוסף על פתרונות Red Hat ב- Google Cloud