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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

התאוששות מאסון במצב פעיל-לא פעיל כוללת תחזוקה של אזור משני כגיבוי, שמופעל רק בזמן אסונות. בניגוד להגדרות פעילות-פסיביות שבהן הנתונים משוכפלים באופן רציף, האסטרטגיה הזו מסתמכת על גיבויים תקופתיים שמאוחסנים ב-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, כל אחד באזור אחר של Google Cloud , כמו us-central1 ו-europe-west1. כל אשכול צריך להיות בעל זמינות גבוהה באזור שלו, ולהשתמש בכמה אזורים כדי לאפשר יתירות.

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

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

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

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

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

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

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

  • אפליקציות שדורשות 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 ‏ (PVCs) בשני האשכולות.

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

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

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

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

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

אופרטורים של מסדי נתונים, כמו CloudNative PostgreSQL Operator, יכולים לסייע בגיבויים מתוזמנים ובתוכנית התאוששות מאסון (DR) באשכולות של 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, פועלים לפי השלבים שמתוארים במסמכי התיעוד בנושא התאוששות מאסון ב-Google Cloud SQL. שימוש בשכפול אסינכרוני של מסד נתונים או אחסון גורם ל-RPO שאינו אפס, כדי לוודא שהאפליקציה יכולה לסבול אובדן של הכתיבות האחרונות. לחלופין, אפשר להשתמש בשיטת שכפול אחרת.

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

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

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

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

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

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

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

  • שימוש במאזני עומסים אזוריים (קבוצות של נקודות קצה ברשת האינטרנט): מגדיריםGoogle Cloud קבוצות של נקודות קצה ברשת האינטרנט (NEGs) כך שיפנו לכתובות ה-IP החיצוניות של מאזני העומסים האזוריים שחושפים כל אחד משירותי הכניסה (OCP Routers) של אשכולי OpenShift. לאחר מכן, מאזן העומסים הגלובלי מנתב את התעבורה לכתובות ה-IP של מאזני העומסים האזוריים האלה. הגישה הזו מספקת שכבת הפשטה, אבל היא כוללת מעבר לרשת נוספת.
  • ניתוב ישיר של Pod‏ (Compute Engine_VM_IP_PORT NEGs): מגדירים את השילוב של OpenShift Ingress Controller כך שישתמש ב Google Cloud 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.

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