‫OpenShift ב-Cloud de Confiance by S3NS: אסטרטגיות להתאוששות מאסון להגדרות פעילות-סבילה ופעילות-לא פעילה

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

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

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

ארכיטקטורות להתאוששות מאסון

בקטע הזה מתוארות ארכיטקטורות לתרחישי התאוששות מאסון פעילים-סבילים ופעילים-לא פעילים.

המוצרים שהשתמשו בהם

פריסות פעילות-סבילות

בתרשים הבא מוצג תרחיש פריסה פעילה-סבילה של OpenShift ב- Cloud de Confiance.

פריסת active-passive, מוסברת בטקסט הבא.

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

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

תיאור של רכיבים בתרחיש DR פעיל-סביל

הארכיטקטורה כוללת את ההגדרות הבאות:

  • אשכול OpenShift ראשי (פעיל): האשכול הזה ממוקם באזור הראשיCloud de Confiance , מריץ את עומס העבודה של הייצור ומשרת באופן פעיל את כל תנועת המשתמשים בתנאי הפעלה רגילים.
  • אשכול OpenShift משני (פסיבי): האשכול הזה ממוקם באזורCloud de Confiance נפרד כדי לבודד תקלות, והוא משמש כאשכול המתנה הפעיל. היא מוגדרת ופועלת באופן חלקי, ומוכנה להשתלט אם המערכת הראשית תיכשל. יש בו את התשתית הדרושה, את ההגדרה של OpenShift ואת רכיבי האפליקציה שפרוסים בו, אבל הוא לא משרת תעבורת נתונים של ייצור פעיל עד להפעלת אירוע מעבר לגיבוי.
  • Cloud de Confiance by S3NS אזורים: מיקומים מבודדים גיאוגרפית שמהווים בסיס לתוכנית התאוששות מאסון (DR). שימוש באזורים נפרדים מבטיח שאירוע בקנה מידה גדול שמשפיע על אזור אחד לא ישפיע על אשכול ההמתנה.
  • מאזן עומסים גלובלי חיצוני מסוג HTTPS: משמש כנקודת כניסה גלובלית יחידה לתנועה של אפליקציות. בתנאים רגילים, הוא מוגדר להפנות את כל התנועה אל האשכול הראשי (הפעיל). בדיקות התקינות שלה עוקבות אחרי הזמינות של האשכול הראשי.
  • מנגנון שכפול נתונים: תהליך או כלים רציפים שאחראים על העתקת נתוני אפליקציה חיוניים מהאשכול הראשי לאשכול המשני (לדוגמה, מסדי נתונים או מצב של נפחים מתמשכים). הגישה הזו מבטיחה עקביות בנתונים ומצמצמת את אובדן הנתונים במהלך יתירות כשל, ועוזרת לכם לעמוד ביעד להתאוששות מאסון (RPO).
  • מעקב ובדיקות תקינות: מערכות שמעריכות באופן רציף את התקינות והזמינות של האשכול הראשי והאפליקציות שלו, למשל Cloud Monitoring, בדיקות תקינות של איזון עומסים ומעקב פנימי אחרי האשכול. המערכות האלה חשובות לזיהוי מהיר של כשלים.
  • מנגנון יתירות כשל: תהליך מוגדר מראש (ידני, חצי אוטומטי או אוטומטי לחלוטין) להפניית תנועה מהאשכול הראשי לאשכול המשני כשמזוהה כשל שלא ניתן לשחזר באשכול הראשי. התהליך הזה כולל בדרך כלל עדכון של הגדרות ה-backend של מאזן העומסים הגלובלי כדי לטרגט את האשכול המשני, וכך להפוך אותו לאתר הפעיל החדש.
  • רשת VPC: תשתית הרשת הבסיסית של Cloud de Confiance שיוצרת את הקישוריות הנדרשת בין אזורים לשכפול ולניהול נתונים.

פריסות פעילות ולא פעילות

התאוששות מאסון פעילה-לא פעילה כוללת שמירה על אזור משני כגיבוי, שמופעל רק בזמן אסונות. בניגוד להגדרות פעילות-פסיביות שבהן הנתונים משוכפלים באופן רציף, האסטרטגיה הזו מסתמכת על גיבויים תקופתיים שמאוחסנים ב-Cloud Storage, עם הקצאת תשתית ושחזור נתונים במהלך מעבר לגיבוי. אפשר להשתמש בכלים כמו Velero, שמשולב עם OpenShift API for Data Protection (OADP), כדי לבצע גיבויים תקופתיים. הגישה הזו ממזערת את העלויות, ולכן היא אידיאלית לאפליקציות שיכולות לעמוד בזמני שחזור ארוכים יותר. הוא גם יכול לעזור לארגונים להתאים את עצמם ליעדים מורחבים של משך ההתאוששות (RTO) ושל נקודת ההתאוששות (RPO).

בתרחיש של DR פעיל-לא פעיל, הנתונים מגובים באופן קבוע לאזור ההמתנה, אבל לא משוכפלים באופן פעיל. התשתית מוקצה כחלק מתהליך המעבר לגיבוי, והנתונים משוחזרים מהגיבוי האחרון. אתם יכולים להשתמש ב-OpenShift API for Data Protection‏ (OADP), שמבוסס על פרויקט הקוד הפתוח Velero, כדי לבצע גיבויים באופן קבוע. מומלץ לאחסן את הגיבויים האלה בקטגוריות של Cloud Storage עם ניהול גרסאות מופעל. במקרה של אסון, אפשר להשתמש ב-OADP כדי לשחזר את התוכן של האשכול. הגישה הזו מצמצמת את העלויות השוטפות, אבל מובילה לזמן שחזור ארוך יותר (RTO) ולנקודת שחזור פוטנציאלית גבוהה יותר (RPO) בהשוואה לגישת active-passive. ההגדרה הזו מתאימה לאפליקציות עם יעדי זמן שחזור ארוכים יותר.

בתרשים הבא מוצגת פריסה פעילה-לא פעילה ותהליך המעבר לגיבוי.

תהליך המעבר לגיבוי.

תהליך המעבר לגיבוי הוא כזה:

  1. אירוע DR מופעל כששירות שנמצא במעקב הופך ללא זמין.
  2. צינור לעיבוד נתונים מקצה באופן אוטומטי תשתית באזור DR.
  3. מוקצה אשכול OpenShift חדש.
  4. נתוני האפליקציה, הסודות והאובייקטים משוחזרים מהגיבוי האחרון באמצעות OADP.
  5. רשומת Cloud DNS מעודכנת כך שתפנה למאזני העומסים האזוריים באזור DR.

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

תיאור של רכיבים בתרחיש DR פעיל-לא פעיל

הארכיטקטורה כוללת את ההגדרות הבאות:

  • אזור ראשי (אזור א'): מכיל את אשכול OpenShift שפועל באופן מלא ומשרת תנועה בסביבת הייצור.
  • אזור משני (אזור ב'): מכיל בהתחלה מינימום משאבים (VPC ותת-רשתות). התשתית (מכונות Compute Engine ו-OCP) מוקצית במהלך מעבר לגיבוי.
  • אחסון גיבויים: בקבצים מסוג Bucket ב-Google Cloud Storage מאוחסנים גיבויים תקופתיים (OADP או Velero לאובייקטים של אפליקציות, וגם PV וגיבויים של מסדי נתונים). מומלץ להשתמש בניהול גרסאות ובשכפול בין אזורים עבור הקטגוריה.
  • ניהול הגדרות: מאגר Git מאחסן תשתית כקוד (IaC, למשל, Terraform) ומניפסטים של Kubernetes או OpenShift (ל-GitOps).
  • כלי גיבוי: OADP‏ (Velero) מוגדר באשכול הראשי לביצוע גיבויים מתוזמנים ל-Cloud Storage.
  • תזמור: סקריפטים או כלי אוטומציה מפעילים תהליכי הקצאת משאבים ושחזור של התשתית במהלך מעבר לגיבוי.

תרחישים לדוגמה

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

תרחישים לדוגמה של DR פעיל-סביל

מומלץ להשתמש ב-DR מסוג Active-passive בתרחישי השימוש הבאים:

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

תרחישים לדוגמה של DR פעיל-לא פעיל

מומלץ להשתמש ב-DR פעיל-לא פעיל בתרחישי השימוש הבאים:

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

שיקולים בתכנון

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

שיקולים בתכנון פעיל-פסיבי

בקטע הזה מתוארים שיקולי התכנון לתרחיש של DR פעיל-סביל.

שמירה על מצב האפליקציה וההגדרה שלה

‫OpenShift Container Platform מספקת OADP ומציעה הגנה מקיפה לשחזור מאסון לאפליקציות שפועלות באשכולות. אפשר להשתמש בו כדי לגבות את אובייקטי Kubernetes ו-OpenShift שמשמשים גם אפליקציות מבוססות-קונטיינרים וגם מכונות וירטואליות (לדוגמה, פריסות, שירותים, מסלולים, PVC,‏ ConfigMap, סודות ו-CRD). עם זאת, OADP לא תומך בגיבוי ובשחזור מלאים של האשכול. במסמכי התיעוד של Red Hat מוסבר איך להגדיר גיבויים ולתזמן אותם, ואיך לבצע פעולות שחזור.

‫OADP מספק תהליכי גיבוי ושחזור של נפחי אחסון מתמיד שמסתמכים על אחסון הבלוקים ומאגרי ה-NFS שבהם האפליקציות משתמשות. אפשר לבצע פעולות בתהליכים האלה באמצעות הכלים Restic או Kopia כדי ליצור תמונת מצב או לבצע גיבוי ברמת הקובץ.

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

כדי להקטין עוד יותר את RPO ואת RTO בהגדרה של פעיל-סביל, מומלץ להגדיר שכפול נתונים בין אזורים ראשיים ומשניים.

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

אחסון בלוקים (נפחי אחסון מתמידים)

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

אובייקטים של נפחי אחסון מתמיד

ב-OpenShift, יוצרים אובייקטים של PersistentVolumes בשני האשכולות שמקושרים לדיסקים האלה, ומוודאים שהאפליקציות משתמשות באותם PersistentVolume Claims ‏ (PVC) בשני האשכולות.

שכפול ברמת האפליקציה

חלק מהאפליקציות (לדוגמה, מסדי נתונים ותורים של הודעות) כוללות תכונות שכפול מובנות שאפשר להגדיר באשכולות. אפשר גם להשתמש בשירות מנוהל כמו Pub/Sub כדי להקל על השכפול של סוגים ספציפיים של נתונים או אירועים באפליקציה.

גיבויים של מסדי נתונים

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

גיבויים באירוח עצמי באמצעות אופרטור של מסד נתונים בתוך האשכול

אופרטורים של מסדי נתונים, כמו CloudNative PostgreSQL Operator, יכולים לסייע בגיבויים מתוזמנים ובהתאוששות מאסון באשכולות PostgreSQL. ‫CloudNative PostgreSQL Operator משתלב באופן טבעי עם כלים כמו pg_basebackup ותומך בגיבויים של שכפול סטרימינג. אתם יכולים לאחסן גיבויים בשירותי אחסון בענן כמו Google Cloud Storage‏ (Cloud Storage) כדי להבטיח עמידות ואפשרות שחזור.

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

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

        apiVersion: postgresql.cnpg.io/v1
        kind: ScheduledBackup
        metadata:
        name: backup-example
        spec:
        schedule: "0 0 0 * * *"
        backupOwnerReference: self
        cluster:
            name: pg-backup

שירותים מנוהלים

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

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

מומלץ גם להפעיל גיבויים אוטומטיים של Cloud SQL. מידע נוסף זמין במאמר בנושא יצירה וניהול של גיבויים לפי דרישה וגיבויים אוטומטיים.

תהליך המעבר לגיבוי

במקרה של כשל באשכול הראשי, Cloud DNS מפנה אוטומטית את התעבורה לאשכול המשני האזורי על סמך בדיקות תקינות ומדיניות יתירות כשל.

כשמקודמת קבוצת משנה משנית מ-read replica לקבוצת משנה ראשית, היא הופכת לאתר פעיל ומשרתת תעבורת נתונים של ייצור. המבצע הזה נדרש כדי לאפשר כתיבה למסד הנתונים.

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

ניהול סודות מאובטח

סודות כמו סיסמאות למסדי נתונים, מפתחות API ואישורי TLS הם היבטים חשובים של DR. אתם צריכים להיות מסוגלים לשחזר את הסודות האלה בצורה מאובטחת ומהימנה באשכול חדש.

אלה כמה גישות נפוצות לניהול סודות:

  • שימוש בסודות חיצוניים: אפשר להשתמש בכלי כמו external secrets operator כדי לשלוף סודות מ-Google Secret Manager.
  • גיבוי סודות באמצעות OADP Operator: אם לא משתמשים בחנות חיצונית, צריך לוודא שהסודות כלולים בגיבויים.
  • רוטציה קבועה: צריך לבצע רוטציה של הסודות באופן קבוע ולוודא שאסטרטגיית ניהול הסודות מתאימה לתרחישי DR.
  • בדיקה: בודקים את שחזור הסודות בסביבת הכנה כדי לוודא שכל השירותים יכולים להתחיל עם פרטי הכניסה שסופקו.
  • אימות: מוודאים שלאשכול ה-DR יש את התפקידים הנדרשים ב-IAM או את שיטות האימות הנדרשות כדי לאחזר סודות ממאגרי סודות חיצוניים.

ניהול תנועה ורשתות

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

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

  • שימוש במאזני עומסים אזוריים (קבוצות של נקודות קצה (endpoint) ברשת האינטרנט): מגדיריםCloud de Confiance קבוצות של נקודות קצה (endpoint) ברשת האינטרנט כדי להפנות לכתובות ה-IP החיצוניות של מאזני העומסים האזוריים שחושפים כל אחד משירותי הכניסה (OCP Routers) של אשכולי OpenShift. לאחר מכן, מאזן העומסים הגלובלי מנתב את התעבורה לכתובות ה-IP של מאזן העומסים האזורי. הגישה הזו מספקת שכבת הפשטה, אבל היא כוללת מעבר לרשת נוספת.
  • ניתוב ישיר של Pod‏ (Compute Engine_VM_IP_PORT NEGs): מגדירים את השילוב של OpenShift Ingress Controller כך שישתמש ב Cloud de Confiance Network Endpoint Groups (NEGs) מסוג Compute Engine_VM_IP_PORT. הגישה הזו מאפשרת למאזן העומסים הגלובלי לטרגט ישירות את הפודים של OpenShift Ingress Controller (Router) באמצעות PodIP:TargetPort הפנימי שלהם. בשיטה הזו לא מתבצעת קפיצה נוספת ולא מופעל פרוקסי של צומת נוסף. בדרך כלל הוא מוביל לזמן אחזור נמוך יותר, ומאפשר בדיקת תקינות ישירה יותר ממאזן העומסים הגלובלי.

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

VPCs

אנחנו ממליצים על הגישות הבאות לניהול VPC:

  • VPC משותף: אפשר להשתמש בVPC משותף כדי לרכז את ניהול הרשת עבור אשכולות ראשיים ומשניים. הגישה הזו מפשטת את הניהול ומבטיחה מדיניות רשת עקבית באזורים שונים.
  • ניתוב דינמי גלובלי: הפעלת ניתוב דינמי גלובלי בתוך רשתות ה-VPC מאפשרת להפיץ מסלולים בין אזורים באופן אוטומטי, וכך להבטיח קישוריות חלקה בין אשכולות.
  • רשתות VPC במצב מותאם אישית: אפשר להשתמש ברשתות VPC במצב מותאם אישית וליצור תת-רשתות ספציפיות באזורים שבהם פועלים האשכולות. לרוב זה נדרש עבור רשתות פודים מקוריות של VPC, שנדרשות לשיטות כמו ניתוב Compute Engine_VM_IP_PORT.
  • קישור בין רשתות VPC שכנות (peering): אם אתם צריכים להשתמש ברשתות VPC נפרדות לכל אזור וקלאסטר, תוכלו להשתמש בקישור בין רשתות VPC שכנות כדי לקשר בין האזורים והקלאסטרים.

תת-רשתות וכתובות IP

יוצרים רשתות משנה אזוריות בכל אזור כדי לשמור על פילוח הרשת ולמנוע התנגשויות בין כתובות IP.

כדי למנוע בעיות ניתוב, חשוב לוודא שאין חפיפה בין טווחי כתובות ה-IP באזורים שונים.

תעבורה בין אשכולות עם Red Hat Service Mesh

‫OpenShift תומך בפדרציה של Service Mesh, שמאפשרת תקשורת בין שירותים שנפרסו בכמה אשכולות OpenShift. הפונקציה הזו שימושית במיוחד בתרחישי DR שבהם יכול להיות ששירותים יצטרכו לתקשר בין אשכולות במהלך יתירות כשל או רפליקציה של נתונים.

במסמכי התיעוד של Red Hat מוסבר איך להגדיר איחוד של Service Mesh בין אשכולות ראשיים ומשניים.

שיקולים בתכנון של מצב פעיל/לא פעיל

בקטע הזה מפורטים שיקולי התכנון לפתרון DR פעיל-לא פעיל.

הגדרת אפליקציה כקוד (GitOps)

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

שימוש באופרטור OpenShift GitOps

‫OpenShift GitOps operator, שמבוסס על Argo CD, מספק דרך שנתמכת על ידי Red Hat להטמעת דפוסי GitOps ישירות בסביבת OpenShift. הכלי מבצע אוטומציה של התהליך של התאמת מצב האשכול באופן רציף להגדרה שבחרתם, ושומר את ההגדרה במאגר Git.

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

ביצוע תרחיש DR

במקרה של אסון, מבצעים את הפעולות הבאות:

  • מגדירים אשכול OpenShift חדש באזור אחר.
  • מתקינים את האופרטור OpenShift GitOps.
  • מחילים את אותו מניפסט של האפליקציה שמפנה אל מאגר ה-Git.

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

כדי למנוע בעיות במהלך התאוששות מאסון, מומלץ לבצע את הפעולות הבאות:

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

כללי חומת אש

הגדרת מדיניות מאוחדת של חומת אש והחלתה באופן עקבי על שני האשכולות כדי לשלוט בזרימת התעבורה ולשפר את האבטחה.

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

פריסה

כדי ללמוד איך לפרוס טופולוגיה שמבוססת על ארכיטקטורת העזר הזו, אפשר לעיין במסמכי התיעוד של Red Hat.

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