VMware NSX לקטנטנים. חלק 5: הגדרת מאזן עומסים

חלק ראשון. אֲקָדֵמַאִי
חלק שני. הגדרת כללי חומת אש וכללי NAT
חלק שלישי. הגדרת DHCP
חלק רביעי. הגדרת ניתוב

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

Теория

כל פתרונות איזון המטען של היום מחולקים לרוב לשתי קטגוריות: איזון ברמה הרביעית (הובלה) והשביעית (יישום) של המודל או אם. מודל OSI אינו נקודת ההתייחסות הטובה ביותר בעת תיאור שיטות איזון. לדוגמה, אם מאזן L4 תומך גם בסיום TLS, האם הוא הופך למאזן L7? אבל זה מה שזה.

• איזון L4 לרוב זהו פרוקסי אמצעי העומד בין הלקוח לבין קבוצה של backends זמינים, אשר מסיים את חיבורי TCP (כלומר, מגיב באופן עצמאי ל-SYN), בוחר backend ומתחיל סשן TCP חדש לכיוונו, שולח SYN באופן עצמאי. סוג זה הוא אחד הבסיסיים; אפשרויות אחרות אפשריות.
• איזון L7 מפיץ תעבורה על פני קצה זמינים "יותר מתוחכם" ממה שמאזן L4 עושה. הוא יכול להחליט באיזה קצה אחורי לבחור בהתבסס, למשל, על תוכן הודעת ה-HTTP (URL, cookie וכו').

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

• גילוי שירות הוא תהליך של קביעת קבוצת הקצה האחורי הזמינים (סטטי, DNS, Consul, וכו' וכו').
• בדיקת הפונקציונליות של ה-backends שזוהו ("פינג" פעיל של ה-backend באמצעות בקשת HTTP, זיהוי פסיבי של בעיות בחיבורי TCP, נוכחות של מספר קודי 503 HTTP בתגובות וכו').
• האיזון עצמו (round robin, בחירה אקראית, מקור IP hash, URI).
• סיום TLS ואימות תעודה.
• אפשרויות הקשורות לאבטחה (אימות, מניעת התקפות DoS, הגבלת מהירות) ועוד הרבה יותר.

NSX Edge מציע תמיכה בשני מצבי פריסת איזון עומסים:

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

הנה איך זה הולך:
1. המשתמש שולח בקשה לכתובת VIP (כתובת איזון) המוגדרת ב-Edge.
2. Edge בוחר באחד מהחלקים האחוריים ומבצע NAT של יעד, ומחליף את כתובת ה-VIP בכתובת של הקצה האחורי שנבחר.
3. Edge מבצע NAT מקור, ומחליף את כתובת המשתמש ששלח את הבקשה בכתובת שלו.
4. החבילה נשלחת ל-backend הנבחר.
5. ה-backend אינו מגיב ישירות למשתמש, אלא ל-Edge, מאחר והכתובת המקורית של המשתמש שונתה לכתובת המאזן.
6. Edge משדר את תגובת השרת למשתמש.
התרשים נמצא למטה.


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

המנגנון הוא כדלקמן:
1. המשתמש שולח בקשה לכתובת VIP (כתובת איזון) המוגדרת ב-Edge.
2. Edge בוחר באחד מהחלקים האחוריים ומבצע NAT של יעד, ומחליף את כתובת ה-VIP בכתובת של הקצה האחורי שנבחר.
3. החבילה נשלחת ל-backend הנבחר.
4. ה-backend מקבל בקשה עם הכתובת המקורית של המשתמש (מקור NAT לא בוצע) ומשיב לה ישירות.
5. התעבורה מתקבלת שוב על ידי מאזן העומס, מכיוון שבסכימה מוטבעת היא משמשת בדרך כלל כשער ברירת המחדל של חוות השרתים.
6. Edge מבצע NAT מקור כדי לשלוח תנועה למשתמש, תוך שימוש ב-VIP שלו ככתובת ה-IP של המקור.
התרשים נמצא למטה.

עיסוק

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

הפקת אישור SSL שישמש את NSX Edge
אתה יכול לייבא אישור CA חוקי או להשתמש בחתימה עצמית. למבחן זה אשתמש בחתימה עצמית.

1. בממשק vCloud Director, עבור להגדרות שירותי Edge.
   
2. עבור אל הכרטיסייה אישורים. מרשימת הפעולות, בחר הוספת CSR חדש.
   
3. מלא את השדות הנדרשים ולחץ על שמור.
   
4. בחר את CSR החדש שנוצר ובחר באפשרות CSR עם חתימה עצמית.
   
5. בחר את תקופת התוקף של האישור ולחץ על שמור
   
6. התעודה בחתימה עצמית מופיעה ברשימת התעודות הזמינות.
   

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

1. עבור אל הכרטיסייה Load Balancer והפעל את המאזן. אפשרות ה-Acceleration Enabled כאן מאפשרת למאזן להשתמש באיזון L4 מהיר יותר במקום L7.
   
2. עבור אל הכרטיסייה פרופיל יישום כדי להגדיר את פרופיל היישום. לחץ על +.
   
3. הגדר את שם הפרופיל ובחר את סוג התנועה שעבורה הפרופיל יוחל. תן לי להסביר כמה פרמטרים.
   התמדה – מאחסן ועוקב אחר נתוני הפעלה, למשל: איזה שרת ספציפי במאגר משרת את בקשת המשתמש. זה מבטיח שבקשות משתמשים מנותבות לאותו חבר בבריכה למשך כל חיי ההפעלה או הפעלות עוקבות.
   אפשר מעבר SSL - כאשר אפשרות זו נבחרת, NSX Edge מפסיק לסיים את SSL. במקום זאת, הסיום מתרחש ישירות בשרתים שמאוזנים.
   הכנס את כותרת ה-X-Forwarded-For HTTP - מאפשר לך לקבוע את כתובת ה-IP המקור של הלקוח המתחבר לשרת האינטרנט באמצעות מאזן העומס.
   אפשר SSL לצד הבריכה – מאפשר לך לציין שהבריכה שנבחרה מורכבת משרתי HTTPS.
   
4. מכיוון שאאזן תעבורת HTTPS, אני צריך להפעיל SSL לצד הבריכה ולבחור את האישור שנוצר קודם לכן בכרטיסייה אישורי שרת וירטואלי -> אישור שירות.
   
5. בדומה לתעודות מאגר -> תעודת שירות.
   

אנו יוצרים מאגר שרתים, שהתעבורה אליו תהיה Pools מאוזנת

1. עבור ללשונית בריכות. לחץ על +.
   
2. אנחנו מגדירים את שם הבריכה, בוחרים באלגוריתם (אני אשתמש ב-round robin) וסוג הניטור עבור ה-backend של בדיקת הבריאות. האפשרות Transparent מציינת האם כתובות ה-IP הראשוניות של הלקוחות גלויות לשרתים פנימיים.
   • אם האפשרות מושבתת, התעבורה לשרתים פנימיים מגיעה מה-IP המקור של המאזן.
   • אם האפשרות מופעלת, שרתים פנימיים רואים את ה-IP המקור של הלקוחות. בתצורה זו, NSX Edge חייב לשמש כשער ברירת המחדל כדי להבטיח שהמנות המוחזרות עוברות דרך NSX Edge.

   NSX תומך באלגוריתמי האיזון הבאים:

   • IP_HASH - בחירת שרת על סמך תוצאות של פונקציית Hash עבור המקור והיעד IP של כל מנה.
   • LEASTCONN - איזון של חיבורים נכנסים, בהתאם למספר שכבר זמין בשרת מסוים. חיבורים חדשים יופנו לשרת עם הכי פחות חיבורים.
   • רובין העגול – חיבורים חדשים נשלחים לכל שרת בתורו, בהתאם למשקל המוקצה לו.
   • URI – החלק השמאלי של ה-URI (לפני סימן השאלה) מחולק ומחולק במשקל הכולל של השרתים בבריכה. התוצאה מציינת איזה שרת מקבל את הבקשה, מה שמבטיח שהבקשה מנותבת תמיד לאותו שרת, כל עוד כל השרתים נשארים זמינים.
   • HTTPHEADER - איזון המבוסס על כותרת HTTP ספציפית, שניתן לציין כפרמטר. אם הכותרת חסרה או שאין לה ערך כלשהו, ​​אלגוריתם ROUND_ROBIN מוחל.
   • כתובת האתר - כל בקשת HTTP GET מחפשת את פרמטר ה-URL שצוין כארגומנט. אם אחרי הפרמטר מופיעים סימן שווה וערך, אז הערך עובר גיבוב ומחולק במשקל הכולל של שרתים פועלים. התוצאה מציינת איזה שרת מקבל את הבקשה. תהליך זה משמש למעקב אחר מזהי משתמש בבקשות ולהבטיח שאותו מזהה משתמש נשלח תמיד לאותו שרת, כל עוד כל השרתים נשארים זמינים.

   

3. בגוש חברים, לחץ על + כדי להוסיף שרתים למאגר.
   
   
   כאן אתה צריך לציין:
   • שם שרת;
   • כתובת השרת;
   • היציאה שעליה השרת יקבל תעבורה;
   • יציאה לבדיקת בריאות (Monitor healthcheck);
   • משקל - באמצעות פרמטר זה ניתן להתאים את כמות התעבורה היחסית המתקבלת עבור חבר ספציפי במאגר;
   • מקסימום חיבורים - מספר מקסימלי של חיבורים לשרת;
   • Min Connections - המספר המינימלי של חיבורים שעל השרת לעבד לפני העברת התעבורה לחבר הבא בבריכה.

   
   
   כך נראה המאגר הסופי של שלושה שרתים.
   

הוספת שרת וירטואלי

1. עבור ללשונית שרתים וירטואליים. לחץ על +.
   
2. אנו מפעילים את השרת הוירטואלי באמצעות Enable Virtual Server.
   אנו נותנים לו שם, בוחרים את פרופיל היישום שנוצר בעבר, מאגר ומציינים את כתובת ה-IP שאליה השרת הוירטואלי יקבל בקשות מבחוץ. אנו מציינים את פרוטוקול HTTPS ויציאה 443.
   פרמטרים אופציונליים כאן:
   מגבלת חיבור - המספר המרבי של חיבורים בו-זמניים שהשרת הוירטואלי יכול לעבד;
   מגבלת קצב חיבור (CPS) - המספר המרבי של בקשות חדשות נכנסות בשנייה.
   

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


לאחר רענון הדף, הבקשה תעובד על ידי השרת הבא:


ושוב - כדי לבדוק את השרת השלישי מהבריכה:


בעת הבדיקה, ניתן לראות שהתעודה ש-Edge שולח לנו היא אותה אישור שיצרנו בהתחלה.

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


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

• צג TCP,
• צג HTTP,
• צג HTTPS.

בואו ניצור אחד חדש.

1. עבור לכרטיסייה ניטור שירות, לחץ על +.
   
2. בחר:
   • שם לשיטה החדשה;
   • המרווח שבו יישלחו בקשות,
   • פסק זמן בהמתנה לתגובה,
   • סוג ניטור – בקשת HTTPS בשיטת GET, קוד מצב צפוי – 200(בסדר) ו-URL בקשה.
3. זה משלים את ההגדרה של צג השירות החדש; כעת נוכל להשתמש בו בעת יצירת מאגר.
   

הגדרת כללי יישום

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

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

בדוגמה למעלה הפעלנו תמיכה ב-tlsv1.

עוד כמה דוגמאות:

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

acl pool_down nbsrv(PRIMARY_POOL_NAME) eq 0
use_backend SECONDARY_POOL_NAME if PRIMARY_POOL_NAME


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

acl pool_down nbsrv(NAME_OF_POOL) eq 0
redirect location http://www.example.com if pool_down

עוד דוגמאות כאן.

זה הכל בשבילי לגבי המאזן. אם יש לך שאלות, שאל, אני מוכן לענות.

מקור: www.habr.com