במאמר הזה מוסבר על ההתנהגויות והאינטראקציות בין אפליקציה עם שמירת מצב, סוכן לבדיקת תקינות ומישור בקרה אזורי ספציפי לאפליקציה שמשמש לניטור ולתיאום של מעבר לגיבוי אזורי על ידי פריסת דיסקים אזוריים עם שכפול סינכרוני.
המסמך הזה מיועד למפתחי אפליקציות כהמשך למאמר יצירת שירותים עם זמינות גבוהה באמצעות דיסקים אזוריים. הוא מרחיב על העיצוב והארכיטקטורה שמתוארים בקטע יצירת שירותי מסדי נתונים עם זמינות גבוהה באמצעות דיסקים אזוריים. מומלץ לקרוא קודם את המסמך הזה, במיוחד את הקטעים בנושא שיקולי עיצוב והשוואת עלויות, ביצועים ועמידות.
אפליקציה בלי שמירת מצב משפרת את החוסן בכך שיש לפחות מכונת Compute Engine משנית אחת שפועלת באזור אחר. אם המופע הראשי נכשל, האפליקציה ממשיכה לפעול במופע המשני. אפליקציה עם שמירת מצב יכולה לשמור את מצב האפליקציה שלה בדיסק אזורי, או בדיסק שזמין רק באזור אחד, כדי לשחזר את המצב שלה מהפעלה מחדש של מופע. כדי שאפליקציה עם שמירת מצב תהיה עמידה, היא צריכה גם לשמור את מצב האפליקציה במופע משני.
איור 1 מציג אפליקציה טיפוסית עם שמירת מצב (stateful) בשני צמתים, שמשוכפלת בשני אזורים. לאפליקציה בכל אזור יש דיסק אזורי לתיעוד מצב האפליקציה, וחיבור רשת בין המופעים כדי לסנכרן את השינויים במצב האפליקציה בין הצמתים.
איור 1. אפליקציה עם שני צמתים למעקב אחר מצב, ללא דיסקים אזוריים
הוספת דיסק אזורי
דרך נוספת לסנכרן את מצב האפליקציה של אפליקציה עם שמירת מצב היא להוסיף דיסק אזורי. כשיישום כותב את מצב היישום שלו לדיסק אזורי,Cloud de Confiance by S3NS מסנכרן אוטומטית את האחסון הבלוקי עם אזור אחר.
תרשים 2 מציג את הארכיטקטורה של אפליקציית מסד נתונים עם שמירת מצב.
איור 2. אפליקציית מסד נתונים עם שמירת מצב
כפי שמוצג באיור 2, עדיין יש שני מופעים של מחשוב אפליקציות – מופע ראשי ומופע משני – שנפרסו בשני אזורים. בנוסף לשימוש בדיסק אזורי לאחסון מצב האפליקציה, יש עכשיו ישות נוספת, מישור הבקרה האזורי הספציפי לאפליקציה. מישור הבקרה האזורי הספציפי לאפליקציה מחליט לאיזה מופע מצורף הדיסק האזורי ולאיזה מופע מוגדר כרגע המופע הראשי. הארכיטקטורה הזו היא הגדרה פעילה-סבילה כי רק המופע הראשי יכול לבצע commit של מצב האפליקציה לדיסק האזורי.
מכונות וירטואליות ואפליקציה עם שמירת מצב
איור 2 מציג יישום של מסד נתונים פעיל-סביל חם. אפשר גם להשתמש בהגדרות הבאות:
- אם היעד שלכם לזמן ההתאוששות (RTO) מאפשר את זמן האחזור הנוסף של הפעלת מכונה משנית, אתם יכולים לחסוך בעלויות של Compute Engine על ידי הפעלת המכונה הפעילה בלבד. במעבר לגיבוי, מישור הבקרה האזורי שספציפי לאפליקציה מפעיל את המופע המשני ומצרף את הדיסק האזורי למופע הזה.
- עומסי עבודה (workload) של עיבוד אצווה או עיבוד בסטרימינג שיוצרים נקודות ביקורת להתקדמות שלהם בדיסק האזורי. במעבר לגיבוי, האפליקציה ממשיכה את העיבוד מנקודת הבדיקה האחרונה.
ניהול הפעלות של מכונות Compute Engine
מכיוון שאפשר לצרף דיסק אזורי רק למופע חישוב אחד בכל פעם, צריך להפעיל את המופעים ולצרף את הדיסק האזורי באופן שיטתי. שיטה מומלצת אחת היא להפריד בין מופע החישוב לבין הפעלת האפליקציה, לבין צירוף הדיסק האזורי. סקריפטים להפעלה של המופע לא אמורים ליזום את צירוף הדיסק האזורי. במקום זאת, סקריפטים להפעלה צריכים להפעיל את סוכן בדיקת התקינות ולהמתין לצירוף הדיסק האזורי.
בזמן ההפעלה, מופעלים במכונת החישוב השלבים הבאים ברצף:
- מפעילים את סוכן בדיקת התקינות.
- מחכים עד שהדיסק האזורי יצורף.
- אחרי שמצרפים את הדיסק האזורי, צריך לטעון את מערכת הקבצים.
- אחרי שמערכת הקבצים נטענת, מפעילים את האפליקציה.
השלבים האלה מתייחסים להפעלת המערכת, אבל יש גם יתירות כשל. במהלך מעבר לגיבוי (failover), הדיסק האזורי מצורף בכוח למכונה המשנית. הדיסק האזורי מוסר בכוח גם מהמופע הראשי, ופעולות קלט/פלט במערכת הקבצים נכשלות. בשלב הזה, צריך לכבות את מופע החישוב או להפעיל אותו מחדש.
הפעלת סוכן בדיקת התקינות ובדיקות התקינות
כמו שמתואר בקטע הקודם, מופע המחשוב ממתין לצירוף הדיסק האזורי לפני הפעלת האפליקציה. מישור הבקרה האזורי הספציפי לאפליקציה מצרף את הדיסק האזורי, אבל רק למופע של מחשוב שממתין לצירוף הדיסק. כשדיסק מצורף, מישור הבקרה הספציפי לאפליקציה עוקב אחרי תקינות האפליקציה ומתחיל מעבר לגיבוי אם האפליקציה לא תקינה.
כל מופע של מחשוב נמצא באחד מהמצבים הבאים:
- למטה
- מתחיל
- בהמתנה לדיסק
- אפליקציה פועלת
הסוכן לבדיקת תקינות מדווח על המצב הנוכחי של המופע. במקום לדווח על שני המצבים האלה באמצעות בדיקת תקינות אחת, אפשר להפעיל שתי בדיקות תקינות בינאריות. אם מופע Compute מוכן לצירוף של דיסק אזורי, או אם הדיסק האזורי מצורף וניתן לכתיבה, בדיקת תקינות המופע מדווחת על סטטוס תקין. אם האפליקציה פועלת ויכולה לכתוב את מצב האפליקציה לדיסק האזורי, בדיקת התקינות של האפליקציה מדווחת על סטטוס תקין.
לשימוש בשני בדיקות תקינות בינאריות יש כמה יתרונות:
- אפשר להשתמש בשירות מנוהל לבדיקת תקינות של Compute Engine, ששולח שאילתות לסוכן לבדיקת תקינות וגם פותר שגיאות זמניות באמצעות ספירת סף.
- קבוצת מופעי מכונה מנוהלים (MIG) יכולה לעקוב אחרי בדיקת התקינות של המכונה ולתקן באופן אוטומטי מכונת Compute לא תקינה.
- מאזן העומסים יכול לעקוב אחרי בדיקת התקינות של האפליקציה ולהפנות תנועה למופע הפעיל של האפליקציה.
כדי למנוע מהמערכת להגיב לכשל זמני, אפשר להקטין את תדירות הדיווח של בדיקת התקינות או להגדיל את הסף של האותות החוזרים שנדרשים כדי לעבור מרמה אחת לרמה אחרת. בשתי הגישות האלה, המערכת מגיבה להפסקה זמנית בשירות באיחור וזמן ההתאוששות מתארך. בדיקה ומדידה של הפרמטרים האלה מאפשרות לכם לשנות את הפרמטרים של בדיקת תקינות כדי לאזן את זמן השחזור של המערכת.
הסבר על מישור הבקרה האזורי הספציפי לאפליקציה
החלק האחרון בארכיטקטורה הוא מישור הבקרה האזורי שספציפי לאפליקציה, שאחראי לשתי הפונקציות הבאות:
- ניהול מחזור החיים של מופעי החישוב הראשיים והמשניים.
- ההחלטה אם נדרש מעבר לגיבוי מתקבלת על סמך מעקב אחרי הסטטוס של בדיקת התקינות של האפליקציה.
אם נדרש מעבר לגיבוי, מישור הבקרה האזורי הספציפי לאפליקציה מתזמר את המעבר לגיבוי באמצעות השלבים הבאים:
- בודק אם מופע משני פועל וממתין לצירוף של הדיסק האזורי.
- הפקודה מחייבת את צירוף הדיסק האזורי למופע המשני.
- מנטר את המופע הראשי שנכשל ומפעיל אותו מחדש. כשמפעילים מחדש את המופע הראשי, מישור הבקרה מתחיל מעבר חזרה לגיבוי לפי הצורך.
מישור הבקרה האזורי הספציפי לאפליקציה עצמו צריך להיות זמין מאוד בשני האזורים שבהם האפליקציה פועלת. במרכזי נתונים מקומיים, זמינות גבוהה (HA) מושגת בדרך כלל באמצעות פריסה של שרתים נוספים כדי ליצור קוורום, להחליט איזו מכונה היא המכונה הראשית ולתזמן יתירות כשל. בגישה הזו נעשה שימוש בדרך כלל בכלי ניטור של זמינות גבוהה, כמו Heartbeat, Pacemaker או Keepalived.
אף על פי שאפשר להשתמש במישור הבקרה האזורי הספציפי לאפליקציה בכל מקום בענן, Cloud de Confiance מציע את השירותים המנוהלים והזמינים באזורים הבאים שמפשטים את ההטמעה של הגישה הזו:
- Cloud de Confiance מוצרים ללא שרתים כמו App Engine, Cloud Run ו-פונקציות Cloud Run, שקל לנהל ולפרוס.
- בדיקות תקינות מנוהלות שמעבירות את המעקב אחרי מופעי המחשוב שמריצים את האפליקציה.
- קבוצות של מופעי מכונה מנוהלים שמנהלות את מחזור החיים של מופעי המחשוב.
איור 3 מציג את השימוש בפונקציות Cloud Run למישור הבקרה האזורי הספציפי לאפליקציה, יחד עם קבוצת מופעי מכונה מנוהלים עם שמירת מצב ובדיקות תקינות מנוהלות.
איור 3. מישור בקרה אזורי ספציפי לאפליקציה
איור 3 מציג שני מופעי מחשוב של האפליקציה, ראשי ומשני. כל מופע פועל באזור נפרד ומנוהל על ידי קבוצת MIG אזורית עם שמירת מצב. דיסק אזורי זמין בשני תחומים באותו אזור. שני שירותים מנוהלים של בדיקות תקינות פועלים. שירות אחד מנוהל לבדיקת תקינות עוקב אחרי סטטוס התקינות של המופע, והוא נמצא בשימוש על ידי קבוצת ה-MIG עם שמירת מצב. שירות אחר לבדיקת תקינות עוקב אחרי סטטוס התקינות של האפליקציה, והוא נמצא בשימוש של מאגר היעדים של מאזן העומסים.
מישור בקרה אזורי ספציפי לאפליקציה פועל באינטראקציה עם סטטוס הבריאות של האפליקציה במאגר היעד ועם ה-MIG האזורי עם שמירת המצב, כדי לעקוב אחרי סטטוס האפליקציה ולהתחיל לצרף את הדיסק האזורי למופע החישוב התקין הנוכחי.
המאמרים הבאים
- מידע נוסף על הקצאת דיסקים אזוריים זמין במסמכי Google Kubernetes Engine.
- כדי ללמוד איך להתאים כלי HA מקומיים לשימוש ב-Cloud de Confiance, אפשר לעיין במאמר דפוסים לשימוש בכתובות IP צפות.
- כדאי להעמיק את הקריאה ולהכיר דוגמאות לארכיטקטורות, תרשימים ושיטות מומלצות בנושאי Google Cloud. כל אלה זמינים במרכז הארכיטקטורה של Cloud.