אסטרטגיות להתאוששות מאסון (DR) בהגדרות פעילה-סבילה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

‫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 (רפליקת קריאה) ל-primary (ראשי), הוא הופך לאתר פעיל ומשרת תעבורת נתונים של ייצור. המבצע הזה נדרש כדי לאפשר כתיבה למסד הנתונים.

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

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

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

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

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

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

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

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

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

פריסה

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

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