ניהול מאזני עומסים

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

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

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

ארכיטקטורה של איזון עומסים

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

מאזני עומסים מוגדרים לסוגי עומסי העבודה הבאים:

• עומסי עבודה (workloads) שפועלים במכונות וירטואליות.
• עומסי עבודה בקונטיינרים בתוך אשכול Kubernetes.

יש שלוש דרכים להגדיר מאזני עומסים ב-GDC:

• שימוש ב-Networking Kubernetes Resource Model (KRM) API. אפשר להשתמש ב-API הזה כדי ליצור מאזני עומסים גלובליים או אזוריים.
• משתמשים ב-CLI של gcloud. אפשר להשתמש ב-API הזה כדי ליצור מאזני עומסים גלובליים או אזוריים.
• שימוש בשירות Kubernetes ישירות מאשכול Kubernetes. השיטה הזו יוצרת רק מאזני עומסים אזוריים.

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

רכיבים של מאזן עומסים

כשמשתמשים ב-KRM API או ב-CLI של gcloud כדי להגדיר את מאזן העומסים, משתמשים במאזן עומסים מסוג L4 passthrough:

• L4 מציין שהפרוטוקול הוא TCP או UDP.
• המשמעות של passthrough היא שאין שרת proxy בין עומס העבודה לבין הלקוח.

מאזן העומסים מורכב מהרכיבים הבאים שאפשר להגדיר:

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

  • מורכב משלושה טאפלים, CIDR, יציאה ופרוטוקול, לגישה של הלקוח.
  • תמיכה בפרוטוקולים TCP ו-UDP.
  • מציע כללי העברה פנימיים וחיצוניים. לקוחות יכולים לגשת לכללי העברה פנימיים מתוך הענן הווירטואלי הפרטי (VPC). לקוחות יכולים לגשת לכללי העברה חיצוניים מחוץ לפלטפורמת GDC או מתוך עומסי עבודה שהוגדר להם ערך של EgressNAT.
  • כללי העברה מתחברים לשירות לקצה העורפי. אפשר להפנות כמה כללי העברה לאותו שירות קצה עורפי.

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

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

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

  • עורף פרויקט הוא עורף שלא מוגדר בו השדה ClusterName. במקרה הזה, התוויות שצוינו חלות על כל עומסי העבודה בפרויקט הספציפי, ב-VPC הספציפי באזור. התוויות מוחלות על עומסי עבודה של מכונות וירטואליות ושל pods בכמה אשכולות. כששירות קצה עורפי משתמש בקצה עורפי של פרויקט, אי אפשר להפנות לקצה עורפי אחר באזור הזה בשירות הקצה העורפי הזה.

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

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

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

איזון עומסים חיצוני ופנימי

לאפליקציות GDC יש גישה לסוגים הבאים של שירותי רשת:

• מאזן עומסים פנימי (ILB): מאפשר לחשוף שירות לאשכולות אחרים בארגון.
• מאזן עומסים חיצוני (ELB): מקצה כתובת IP וירטואלית (VIP) מתוך טווח שניתן לניתוב מעומסי עבודה חיצוניים, וחושף שירותים מחוץ לארגון GDC, כמו ארגונים אחרים בתוך מופע GDC או מחוצה לו. כדי להבטיח שבקשות מלקוח ינותבו באופן עקבי לאותו בק-אנד, צריך להשתמש בזיקה לסשן (session affinity) למאזני עומסים של ELB.

מאזני עומסים גלובליים ואזוריים

אפשר ליצור מאזני עומסים גלובליים או אזוריים. ההיקף של מאזני עומסים גלובליים משתרע על פני יקום GDC. כל יקום GDC יכול לכלול כמה אזורי GDC שמאורגנים באזורים שמחוברים ביניהם וחולקים מישור בקרה. לדוגמה, יקום שמורכב משני אזורים, שבכל אחד מהם יש שלושה אזורים, יכול להיראות כך: us-virginia1-a,‏ us-virginia1-b,‏ us-virginia1-c ו-eu-ams1-a,‏ eu-ams1-b,‏ eu-ams1-c.

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

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

אפשר ליצור מאזני עומסים גלובליים באמצעות השיטות הבאות:

• שימוש ב-Networking Kubernetes Resource Model (KRM) API. משתמשים בגרסת ה-API‏ networking.global.gdc.goog כדי ליצור משאבים גלובליים.
• משתמשים ב-CLI של gcloud. כדי לציין היקף גלובלי כשמשתמשים בפקודות gdcloud CLI, צריך להשתמש בדגל --global.

אפשר ליצור מאזני עומסים אזוריים באמצעות השיטות הבאות:

• שימוש ב-Networking Kubernetes Resource Model (KRM) API. משתמשים בגרסת ה-API‏ networking.gdc.goog כדי ליצור משאבים אזוריים.
• משתמשים ב-CLI של gcloud. כשמשתמשים בפקודות gdcloud CLI, צריך להשתמש בדגל --zone כדי לציין באילו אזורים ליצור מאזני עומסים.
• שימוש ב-Kubernetes Service ישירות מאשכול Kubernetes.

כתובות IP וירטואליות של שירות

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

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

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

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

איך Maglev עובד: מנגנון הגיבוב

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

• קלט גיבוב (5-tuple): האלגוריתם משתמש ב-5-tuple רגיל מכותרת החבילה כדי ליצור גיבוב. הטופל הזה כולל:
  1. כתובת ה-IP של המקור
  2. יציאת המקור
  3. כתובת ה-IP של היעד
  4. יציאת יעד
  5. פרוטוקול (לדוגמה, TCP, ‏ UDP)
• החלטה לגבי העברה: התוצאה של הגיבוב הזה ממפה באופן דטרמיניסטי את החיבור לאחד מהשרתים העורפיים התקינים במאגר איזון העומסים. במשך משך החיים של החיבור הזה, כל החבילות שלו יועברו לאותו שרת קצה.
• אנטרופיה לאיזון: באמצעות כל חמשת הרכיבים של ה-tuple,‏ Maglev יוצר אנטרופיה מספקת כדי להבטיח שחיבורים שונים יפוזרו באופן שווה בכל השרתים הזמינים.

טיפול בבעיות בקצה העורפי

‫Maglev נועד להיות עמיד ולצמצם את השיבושים כשקבוצת ה-Backend הזמינים משתנה.

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

התנהגות בפריסות מרובות אזורים

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

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

מגבלות

• אסור להגדיר את המשאב BackendService עם משאב HealthCheck לעומסי עבודה של Pod. המאפיין HealthCheckName במפרט BackendService הוא אופציונלי, וצריך להשמיט אותו כשמגדירים איזון עומסים עם פודים.

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

• למשאב מותאם אישית של מאזן עומסים גלובלי, כמו ForwardingRuleExternal,‏ ForwardingRuleInternal,‏ BackendService או HealthCheck, אסור שיהיה שם זהה לשמות של משאבים מותאמים אישית של מאזני עומסים אזוריים.

• ארגון יכול להגדיר עד 500 כללי העברה לכל אזור שבו הוא נמצא. כללי העברה גלובליים נכללים במגבלה הזו בכל האזורים.

מגבלות של אשכולות רגילים

המגבלות הבאות חלות על איזון עומסים באשכולות רגילים:

היקף של אשכול יחיד

• היקף של אשכול יחיד: כל איזון עומסים (ILB או ELB) שהוקצה לאשכול רגיל באמצעות משאב Service type=LoadBalancer חייב להיות מיועד לנקודות קצה של שרתים עורפיים שהן פודים שנמצאים באופן בלעדי באותו אשכול רגיל יחיד. לא ניתן להשתמש בהגדרה אחת של מאזן עומסים כדי לנסות לפזר תנועה בין פודים שפועלים בכמה אשכולות רגילים שונים, או בין שילוב של אשכולות רגילים ואשכולות משותפים.

• אין תמיכה בgdcloud CLI וב-Networking Kubernetes Resource Model API באשכולות רגילים. כדי לנהל את איזון העומסים באשכולות רגילים, משתמשים במשאב Kubernetes Service רגיל עם type=LoadBalancer וההערות המשויכות.

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

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

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

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

• הגדרת מאזני עומסים פנימיים
• הגדרת מאזני עומסים חיצוניים