המאמר הזה מיועד לאדמינים של מערכות, למומחי Cloud Architect ולמפתחי אפליקציות שאחראים על שמירת הזמינות והחוסן של אפליקציות ב-Red Hat OpenShift Container Platform שנפרס ב- Google Cloud.
המסמך הזה הוא חלק מסדרה שמתמקדת באסטרטגיות ברמת האפליקציה שמבטיחות שעומסי העבודה שלכם יישארו זמינים מאוד וניתנים לשחזור מהיר במקרה של כשלים. ההנחה היא שקראתם את המאמר בנושא שיטות מומלצות לשחזור אחרי אסון. המסמכים בסדרה הזו הם:
- שיטות מומלצות לתוכנית התאוששות מאסון (DR)
- שיטות מומלצות לזמינות גבוהה
- אסטרטגיות להתאוששות מאסון (DR) בהגדרות פעילות-סבילה
- אסטרטגיות להתאוששות מאסון (DR) בהגדרות פעילות-לא פעילות (הדף הזה)
ארכיטקטורה להתאוששות מאסון
התאוששות מאסון פעילה-לא פעילה כוללת תחזוקה של אזור משני כגיבוי, שמופעל רק בזמן אסונות. בניגוד להגדרות פעילות-פסיביות שבהן הנתונים משוכפלים באופן רציף, האסטרטגיה הזו מסתמכת על גיבויים תקופתיים שמאוחסנים ב-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. ההגדרה הזו מתאימה לאפליקציות עם יעדי זמן שחזור ארוכים יותר.
הדיאגרמה הבאה מציגה פריסה פעילה-לא פעילה ותהליך יתירות הכשל:
תהליך המעבר לגיבוי הוא כזה:
- אירוע DR מופעל כששירות שנמצא במעקב הופך ללא זמין.
- צינור לעיבוד נתונים מקצה באופן אוטומטי תשתית באזור DR.
- מוקצה אשכול OpenShift חדש.
- נתוני האפליקציה, הסודות והאובייקטים משוחזרים מהגיבוי האחרון באמצעות OADP.
- רשומת Cloud DNS מעודכנת כך שתפנה למאזני העומסים האזוריים באזור DR.
כפי שמוצג בדיאגרמה הקודמת, נפרסים שני אשכולות אזוריים נפרדים של OpenShift, כל אחד באזור Google Cloud אחר, כמו 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.
- תזמור: סקריפטים או כלי אוטומציה מפעילים תהליכי הקצאת משאבים ושחזור של התשתית במהלך מעבר לגיבוי.
המוצרים שהשתמשו בהם
- Google Compute Engine
- Google Cloud מאזן עומסים גלובלי חיצוני מסוג HTTPS
- Google Cloud מאזני עומסי רשת להעברת סיגנל ללא שינוי
- Cloud DNS
- קבוצות של נקודות קצה ברשת
- Cloud Storage
- Cloud SQL
- Persistent Disk
- Secret Manager
- Cloud Monitoring
- רשת VPC
תרחישים לדוגמה
מומלץ להשתמש ב-DR פעיל-לא פעיל בתרחישי השימוש הבאים:
- אפליקציות שיכולות לעמוד ב-RTO ארוך יותר (לדוגמה, כמה דקות עד כמה שעות).
- סביבות שבהן אופטימיזציה של עלויות היא חשובה, וההוצאה של אשכול המתנה שפועל באופן רציף היא גבוהה מדי. העלות העיקרית השוטפת היא על אחסון אובייקטים ולא על הפעלת מכונות וירטואליות.
- עומסי עבודה של פיתוח, בדיקות או ייצור פחות קריטיים.
- מערכות לארכיון או לעיבוד ברצף (batch processing) שבהן זמן השחזור פחות קריטי.
שיקולים בתכנון
בקטע הזה מתוארים גורמים בתכנון, שיטות מומלצות והמלצות לתכנון שכדאי לקחת בחשבון כשמשתמשים בארכיטקטורת ההפניה הזו כדי לפתח טופולוגיה שעונה על הדרישות הספציפיות שלכם בנוגע לאבטחה, למהימנות, לעלות ולביצועים.
הגדרת אפליקציה כקוד (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 operator.
- מחילים את אותו מניפסט של האפליקציה שמפנה אל מאגר ה-Git.
האופרטור מסנכרן את מצב האשכול כך שיתאים למאגר, ומבצע פריסה מחדש של פריסות, שירותים, מסלולים, אופרטורים וכל משאב אחר שמוגדר בקוד.
כדי למנוע בעיות במהלך התאוששות מאסון, מומלץ לבצע את הפעולות הבאות:
- חשוב לשמור על אסטרטגיות הסתעפות ותיוג מחמירות במאגר Git, כדי שתוכלו לזהות הגדרות יציבות שמתאימות להתאוששות מאסון.
- מוודאים שלאשכול ה-DR יש קישוריות לרשת והרשאות מתאימות לגישה למאגר Git.
- כדי להימנע מהתערבות ידנית במהלך מעבר לגיבוי (failover), צריך לכלול את כל סוגי המשאבים כקוד (לדוגמה, רכיבי תשתית, עומסי עבודה של אפליקציות והגדרות).
כללי חומת אש
הגדרת מדיניות מאוחדת של חומת אש והחלתה באופן עקבי על שני האשכולות כדי לשלוט בזרימת התעבורה ולשפר את האבטחה.
פועלים לפי העיקרון של הרשאות מינימליות, כלומר מגבילים את התנועה הנכנסת והיוצאת רק למה שנדרש לפונקציונליות של האפליקציה.
פריסה
כדי ללמוד איך פורסים טופולוגיה שמבוססת על ארכיטקטורת העזר הזו, אפשר לעיין במסמכי התיעוד של Red Hat.
המאמרים הבאים
- איך מטמיעים מעקב והתראות לגבי תקינות האשכול, סטטוס השכפול, הצלחת הגיבוי וביצועי האפליקציה בסביבות ראשוניות ומשניות.
- כך מתקינים את OpenShift ב- Google Cloud.
- מידע נוסף על פתרונות Red Hat ב- Google Cloud