ארכיטקטורה של מאזן עומסים ברשת ב-Yandex.Cloud

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

ראשית, בואו נציג כמה מונחים:

• VIP (Virtual IP) - כתובת IP מאזנת
• שרת, אחורי, מופע - מכונה וירטואלית שמריצה אפליקציה
• RIP (Real IP) - כתובת IP של השרת
• בדיקת בריאות - בדיקת מוכנות השרת
• Availability Zone, AZ - תשתית מבודדת במרכז נתונים
• אזור - איחוד של AZs שונים

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

מאזן עומסים מסווג לרוב לפי שכבת הפרוטוקול ממודל ה-OSI עליו הוא פועל. ה-Cloud Balancer פועל ברמת TCP, התואמת את השכבה הרביעית, L4.

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

מישור נתונים

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

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

מטוס תצורה

 
מרכיב המפתח של מישור התצורה הוא ה-API, שבאמצעותו מתבצעות פעולות בסיסיות עם מאזנים: יצירה, מחיקה, שינוי הרכב המופעים, קבלת תוצאות בדיקות בריאות וכו'. מצד אחד, זהו REST API, ומצד אחד. אחר, אנחנו בענן משתמשים לעתים קרובות מאוד במסגרת gRPC, אז אנחנו "מתרגמים" REST ל-gRPC ואז משתמשים רק ב-gRPC. כל בקשה מובילה ליצירת סדרה של משימות א-סינכרוניות אדמומיות המבוצעות במאגר משותף של עובדי Yandex.Cloud. משימות כתובות בצורה כזו שניתן להשעות אותן בכל עת ואז להפעיל אותן מחדש. זה מבטיח מדרגיות, חזרתיות ורישום פעולות.

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

השירות מאחסן את מצבו ב-Yandex Database, מסד נתונים מנוהל מבוזר שבו תוכל להשתמש בקרוב. ב-Yandex.Cloud, כמו כבר סיפר, תפיסת המזון לכלבים חלה: אם אנחנו בעצמנו משתמשים בשירותינו, אז גם הלקוחות שלנו ישמחו להשתמש בהם. מסד הנתונים של Yandex הוא דוגמה ליישום מושג כזה. אנחנו מאחסנים את כל הנתונים שלנו ב-YDB, ואנחנו לא צריכים לחשוב על תחזוקה וקנה מידה של מסד הנתונים: הבעיות האלה נפתרות עבורנו, אנחנו משתמשים במסד הנתונים כשירות.

נחזור לבקר האיזון. המשימה שלו היא לשמור מידע על המאזן ולשלוח משימה לבדיקת מוכנות המכונה הוירטואלית לבקר ה- Healthcheck.

בקר בדיקת בריאות

הוא מקבל בקשות לשינוי כללי בדיקה, שומר אותם ב-YDB, מפיץ משימות בין צמתים לבדיקות בריאות ומצבר את התוצאות, שנשמרות לאחר מכן במסד הנתונים ונשלחות לבקר העומס. הוא, בתורו, שולח בקשה לשנות את הרכב האשכול במישור הנתונים ל-loadbalancer-node, עליו אדון בהמשך.

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

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

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

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

ההבדל הוא שלקוחות מגישים בקשות ל-VIP, בעוד שבדיקות בריאות מגישות בקשות לכל RIP בנפרד. מתעוררת כאן בעיה מעניינת: אנו נותנים למשתמשים שלנו את ההזדמנות ליצור משאבים ברשתות IP אפורות. בואו נדמיין שיש שני בעלי ענן שונים שהסתירו את השירותים שלהם מאחורי איזונים. לכל אחד מהם יש משאבים ברשת המשנה 10.0.0.1/24, עם אותן כתובות. אתה צריך להיות מסוגל איכשהו להבחין ביניהם, וכאן אתה צריך לצלול לתוך המבנה של הרשת הוירטואלית Yandex.Cloud. עדיף לברר פרטים נוספים ב סרטון מאירוע about:cloud, חשוב לנו כעת שהרשת היא רב-שכבתית ובעלת מנהרות שניתן להבחין בהן לפי מזהה רשת משנה.

צמתי Healthcheck יוצרים קשר עם מאזנים באמצעות מה שנקרא כתובות מעין IPv6. מעין-כתובת היא כתובת IPv6 עם כתובת IPv4 ומזהה רשת משנה של המשתמש מוטמעים בתוכה. התעבורה מגיעה למאזן, שמחלץ ממנו את כתובת משאב ה-IPv4, מחליף את ה-IPv6 ב-IPv4 ושולח את החבילה לרשת של המשתמש.

התעבורה ההפוכה מתנהלת באותה דרך: המאזן רואה שהיעד הוא רשת אפורה מבדיקת בריאות, וממיר IPv4 ל-IPv6.

VPP - הלב של מישור הנתונים

האיזון מיושם באמצעות טכנולוגיית Vector Packet Processing (VPP), מסגרת מבית סיסקו לעיבוד אצווה של תעבורת רשת. במקרה שלנו, המסגרת פועלת על גבי ספריית ניהול התקני הרשת של מרחב המשתמש - Data Plane Development Kit (DPDK). זה מבטיח ביצועי עיבוד מנות גבוהים: הרבה פחות פסיקות מתרחשות בליבה, ואין מעברי הקשר בין מרחב הקרנל למרחב המשתמש. 

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

לדוגמה, העיבוד של מנות IP ב-VPP מתרחש בסדר הבא: ראשית, כותרות החבילות מנותחות בצומת הניתוח, ולאחר מכן הן נשלחות לצומת, שמעביר את החבילות הלאה לפי טבלאות ניתוב.

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

n_left_from = frame->n_vectors;
while (n_left_from > 0)
{
    vlib_get_next_frame (vm, node, next_index, to_next, n_left_to_next);
    // ...
    while (n_left_from >= 4 && n_left_to_next >= 2)
    {
        // processing multiple packets at once
        u32 next0 = SAMPLE_NEXT_INTERFACE_OUTPUT;
        u32 next1 = SAMPLE_NEXT_INTERFACE_OUTPUT;
        // ...
        /* Prefetch next iteration. */
        {
            vlib_buffer_t *p2, *p3;

            p2 = vlib_get_buffer (vm, from[2]);
            p3 = vlib_get_buffer (vm, from[3]);

            vlib_prefetch_buffer_header (p2, LOAD);
            vlib_prefetch_buffer_header (p3, LOAD);

            CLIB_PREFETCH (p2->data, CLIB_CACHE_LINE_BYTES, STORE);
            CLIB_PREFETCH (p3->data, CLIB_CACHE_LINE_BYTES, STORE);
        }
        // actually process data
        /* verify speculative enqueues, maybe switch current next frame */
        vlib_validate_buffer_enqueue_x2 (vm, node, next_index,
                to_next, n_left_to_next,
                bi0, bi1, next0, next1);
    }

    while (n_left_from > 0 && n_left_to_next > 0)
    {
        // processing packets by one
    }

    // processed batch
    vlib_put_next_frame (vm, node, next_index, n_left_to_next);
}

אז, Healthchecks מדברים על IPv6 ל-VPP, מה שהופך אותם ל-IPv4. זה נעשה על ידי צומת בגרף, שאנו קוראים לו NAT אלגוריתמי. עבור תעבורה הפוכה (והמרה מ-IPv6 ל-IPv4) קיים אותו צומת NAT אלגוריתמי.

תעבורה ישירה מלקוחות האיזון עוברת דרך צמתי הגרף, שמבצעים את האיזון בעצמו. 

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

ה-hash 5-tuple עוזר לנו לבצע פחות חישוב בצמת ה-hashing העקבית שלאחר מכן, כמו גם לטפל טוב יותר בשינויים ברשימת המשאבים מאחורי המאזן. כאשר חבילה שעבורה אין סשן מגיעה למאזן, היא נשלחת לצומת הגיבוב העקבית. זה המקום שבו מתרחש איזון באמצעות hashing עקבי: אנו בוחרים משאב מרשימת המשאבים ה"חיים" הזמינים. לאחר מכן, החבילות נשלחות לצומת NAT, אשר למעשה מחליף את כתובת היעד ומחשב מחדש את סכומי הבדיקה. כפי שאתה יכול לראות, אנו עוקבים אחר הכללים של VPP - כמו לאהוב, מקבצים חישובים דומים כדי להגביר את היעילות של מטמוני מעבד.

גיבוב עקבי

למה בחרנו בזה ומה זה בכלל? ראשית, בואו נבחן את המשימה הקודמת - בחירת משאב מהרשימה. 

עם hashing לא עקבי, ה-hash של החבילה הנכנסת מחושב, ומשאב נבחר מהרשימה על ידי שאר חלקי ה-hash הזה במספר המשאבים. כל עוד הרשימה נשארת ללא שינוי, סכימה זו פועלת היטב: אנו תמיד שולחים מנות עם אותו 5-tuple לאותו מופע. אם, למשל, משאב כלשהו הפסיק להגיב לבדיקות בריאות, אז עבור חלק ניכר מה-hash הבחירה תשתנה. חיבורי ה-TCP של הלקוח ינותקו: מנה שהגיעה בעבר למופע A עשויה להתחיל להגיע למופע B, שאינו מכיר את ההפעלה של מנה זו.

Hahing עקבי פותר את הבעיה המתוארת. הדרך הקלה ביותר להסביר את המושג הזה היא זו: דמיינו שיש לכם טבעת שאליה אתם מחלקים משאבים לפי hash (לדוגמה, לפי IP:port). בחירת משאב היא סיבוב הגלגל בזווית, אשר נקבעת על ידי ה-hash של החבילה.

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

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

איזון עומסים-צומת ורכיבים מורכבים

הרכב האיזונים והמשאבים ב-VPP מדווח על ידי השירות המקומי - loadbalancer-node. הוא נרשם לזרם האירועים ממאזן העומס-בקר ומסוגל לשרטט את ההבדל בין מצב ה-VPP הנוכחי לבין מצב היעד המתקבל מהבקר. אנחנו מקבלים מערכת סגורה: אירועים מה-API מגיעים לבקר האיזון, שמקצה משימות לבקר ה-Healthcheck כדי לבדוק את "חייות" המשאבים. זה, בתורו, מקצה משימות ל- Healthcheck-node ומצבירה את התוצאות, ולאחר מכן הוא שולח אותן בחזרה לבקר המאזן. Loadbalancer-node נרשם לאירועים מהבקר ומשנה את מצב ה-VPP. במערכת כזו, כל שירות יודע רק מה נחוץ לגבי שירותים שכנים. מספר החיבורים מוגבל ויש לנו את היכולת להפעיל ולהרחיב קטעים שונים באופן עצמאי.

אילו בעיות נמנעו?

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

בעיות ופתרונות

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

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

ארכיטקטורת אירועים של Microservice מורכבת יותר ממונוליט: איסוף יומנים בעשרות מכונות שונות אינו נוח במיוחד. מסקנה: אם אתה מייצר שירותי מיקרו, תחשוב מיד על מעקב.

התכניות שלנו

נשיק איזון פנימי, איזון IPv6, נוסיף תמיכה בסקריפטים של Kubernetes, נמשיך לרסיס את השירותים שלנו (כרגע רק healthcheck-node ו-healthcheck-ctrl מרוסקים), נוסיף בדיקות בריאות חדשות, וגם נטמיע צבירה חכמה של בדיקות. אנו שוקלים אפשרות להפוך את השירותים שלנו לעצמאיים עוד יותר - כך שהם מתקשרים לא ישירות אחד עם השני, אלא באמצעות תור הודעות. שירות תואם SQS הופיע לאחרונה בענן תור הודעות של Yandex.

לאחרונה התקיימה ההפצה הפומבית של Yandex Load Balancer. לַחקוֹר תיעוד לשירות, נהל מאזנים בצורה נוחה לך והגבר את סובלנות התקלות של הפרויקטים שלך!

מקור: www.habr.com