תוכנית התאוששות מאסון (DR) ל-OpenShift ב-Cloud de Confiance by S3NS

התאוששות מאסון (DR) חיונית לשמירה על המשכיות של האפליקציות שפרוסות ב-OpenShift Container Platform ב-Cloud de Confiance. מסמך זה מספק סקירה כללית של אפשרויות הארכיטקטורה עבור DR עם OpenShift ב- Cloud de Confiance, כדי לעזור לארגון שלכם להשיג זמן השבתה מינימלי ושחזור מהיר במקרה של אסון.

המסמך הזה מיועד לאדמינים של מערכות, למומחי Cloud Architect ולמפתחי אפליקציות שאחראים על שמירת הזמינות והחוסן של אפליקציות ב-OpenShift Container Platform שנפרס ב-Cloud de Confiance.

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

תכנון DR

תכנון התאוששות מאסון הוא רכיב קריטי בהפעלת עומסי עבודה של ייצור בענן. למרות ש-OpenShift ו- Cloud de Confiance מציעים יתירות חזקה ברמת התשתית, אתם צריכים גם לתכנן ולהגדיר את האפליקציות כך שיוכלו להתאושש במהירות מכשלים קריטיים.

תכנון יעיל של DR כולל גישה רב-שכבתית. מתחילים בהגדרת יעדים ברורים של משך ההתאוששות (RTO) ויעדים של נקודת ההתאוששות (RPO) עבור האפליקציה והמערכת, כדי להבטיח פריסה מחדש מהירה.

לבסוף, צריך גם להיות אפשר לשחזר את הסודות ואת פרטי הכניסה, ולנהל אותם בצורה מאובטחת. אם לוקחים בחשבון את כל הגורמים האלה, אפשר להשיג מצב של התאוששות מאסון שמאפשר ליצור במהירות אשכול OpenShift חדש באזור אחר או לבצע מעבר לגיבוי פעיל לאשכול משני לא פעיל. האשכול המשני הזה נשאר במצב אופליין עד שמתרחשת תקלה. בשלב הזה הוא מופעל ועובר למצב אונליין כדי להשתלט על הפעולות עם השבתה מינימלית.

ארכיטקטורות ל-DR

יש אפשרויות שונות לארכיטקטורות פריסה שאפשר להשתמש בהן להתאוששות מאסון באמצעות OpenShift ב- Cloud de Confiance. לכל אחת מהאפשרויות האלה יש השלכות שונות על העלות, המורכבות והזמינות. בטבלה הבאה מופיעה סקירה כללית של הארכיטקטורות האלה:

ארכיטקטורה תיאור תרחיש לדוגמה היתרונות חסרונות
פעיל-סביל קלאסטר אחד פעיל ומטפל בכל התנועה, והקלאסטר השני פסיבי ומוכן להשתלט על התנועה. הנתונים משוכפלים לאשכול הפסיבי. מתאים לאפליקציות עם דרישות מתונות של RTO ו-RPO. קל יותר להטמיע, עלות נמוכה יותר עבור אשכול במצב המתנה. RTO גבוה יותר בגלל זמן יתירות כשל, עיכובים אפשריים בסנכרון הנתונים.
פעיל-לא פעיל בדומה לגישת active-passive, אבל לא נעשה שימוש באשכול הלא פעיל עד לאירוע DR. הנתונים מגובים באופן קבוע. פתרון אידיאלי לסביבות שבהן העלות היא שיקול חשוב, ושיש בהן אפשרות לזמני RTO ו-RPO ארוכים יותר. העלות התפעולית נמוכה יותר כשהמערכת לא פעילה, ולכן היא מתאימה להתאוששות מאסון (DR) שבה מערכת משנית לא פועלת באופן פעיל (cold DR) . זמן ההתאוששות (RTO) גבוה יותר בגלל זמן ההפעלה והסנכרון, למרות שיש סיכוי שהנתונים יהיו לא עדכניים.
פעיל-פעיל שני האשכולות פעילים, ומטפלים בתעבורה באמצעות איזון עומסים ושכפול נתונים בין אזורים. אפליקציות קריטיות שנדרשת בהן זמינות גבוהה וזמן השבתה מינימלי. זמן השבתה (RTO) ונקודת שחזור (RPO) נמוכים ביותר, זמינות רציפה. המורכבות והעלות הכי גבוהות, נדרשת רשת חזקה וסנכרון נתונים.

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