זמינות גבוהה של האפליקציות

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

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

  • אדריכלי ענן שמתכננים תשתיות עמידות וארכיטקטורות של אפליקציות.

  • מהנדסי DevOps ומהנדסי Site Reliability שמטמיעים אסטרטגיות פריסה, אוטומציה, מעקב ותגובה לאירועים עבור עומסי עבודה של זמינות גבוהה.

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

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

החשיבות של זמינות גבוהה

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

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

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

יכולות היפר-סקייל, שזמינות באופן מקומי

GDC מרחיב את התשתית והשירותים אל הקצה ואל מרכזי הנתונים שלכם. Google Cloud ‫GDC מספקת פתרון מנוהל לחלוטין של חומרה ותוכנה, שמאפשר להפעיל את Google Kubernetes Engine‏ (GKE) באשכולות GDC ושירותים אחרים שלGoogle Cloud קרוב יותר למקום שבו הנתונים נוצרים ונצרכים.

המאמר הזה מתמקד ביקומים של GDC שהוגדרו בטופולוגיה של כמה אזורים. במקרה כזה, יקום אחד כולל כמה תחומים מבודדים פיזית באותו מיקום.

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

מדרגיות ואיזון עומסים

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

מאזן עומסים חיצוני לתעבורה מצפון לדרום

כדי לחשוף את האפליקציות שלכם למשתמשים או למערכות מחוץ לאשכול GKE on GDC (תעבורה מצפון לדרום), אתם יכולים להשתמש ביכולות המנוהלות של איזון עומסים חיצוני ב-GDC. שירות מאזן העומסים החיצוני (ELB) מספק את היכולות האלה ומשתלב בצורה חלקה עם Kubernetes.

המאפיינים העיקריים של שירות ELB שמספק זמינות גבוהה ומדרגיות הם:

  • שירות מנוהל: פועל כשירות ספציפי ל-GDC, ומיועד לזמינות גבוהה ולעמידות בסביבה עם פער אוויר.

  • גישה חיצונית: הקצאת כתובות IP חיצוניות יציבות ממאגרים שמנוהלים על ידי GDC, כדי לספק נקודת כניסה עקבית ללקוחות חיצוניים.

  • שילוב של מאזן עומסים עם Kubernetes: הקצאה והגדרה אוטומטיות של מאזן העומסים כשיוצרים Service של Kubernetes type: LoadBalancer ללא הערות פנימיות ספציפיות.

  • זיהוי אזורים: התכונה הזו מפזרת את התנועה הנכנסת בין פודים תקינים של אפליקציות שפועלים בכל האזורים הזמינים ב-GDC. ה-ELB מסתמך על בדיקות מוכנות של פודים כדי לקבוע את תקינות ה-backend.

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

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

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

מאזן עומסים פנימי לתנועת מזרח-מערב

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

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

  • גישה פנימית: הקצאת כתובת IP פנימית יציבה שאפשר לגשת אליה רק מתוך רשת GDC, למשל מצמתי אשכולות או משירותים פנימיים אחרים.

  • שילוב של מאזן עומסים עם Kubernetes: הקצאת איזון עומסים על ידי יצירת Kubernetes Service מסוג type: LoadBalancer עם הערה ספציפית שמציינת שהוא חייב להיות פנימי. לדוגמה, networking.gke.io/load-balancer-type: "Internal".

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

  • גילוי שירותים וביטול צימוד: מספק כתובת IP פנימית יציבה ושם DNS עם שילוב של kube-dns ו-CoreDNS. השירותים יכולים לגלות אחד את השני ולתקשר ביניהם, כך שהלקוחות לא צריכים לדעת את כתובות ה-IP של הפודים.

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

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

מידע נוסף מופיע במאמר בנושא הגדרת מאזני עומסים פנימיים.

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

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

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

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

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