איזון עומסים ב-Openstack (חלק 2)

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

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

קצת טרמינולוגיה

חברת VmWare הציגה את כלי השירות DRS (Distributed Resource Scheduler) כדי לאזן את העומס של סביבת הוירטואליזציה שהם פיתחו והציעו.

כמו שכותב searchvmware.techtarget.com/definition/VMware-DRS
"VMware DRS (Distributed Resource Scheduler) הוא כלי עזר שמאזן עומסי מחשוב עם משאבים זמינים בסביבה וירטואלית. כלי השירות הוא חלק מחבילת וירטואליזציה בשם VMware Infrastructure.

עם VMware DRS, משתמשים מגדירים כללים להפצת משאבים פיזיים בין מכונות וירטואליות (VMs). ניתן להגדיר את כלי השירות לשליטה ידנית או אוטומטית. ניתן להוסיף, להסיר או לארגן מחדש בקלות מאגרי משאבים של VMware. אם תרצה, ניתן לבודד מאגרי משאבים בין יחידות עסקיות שונות. אם עומס העבודה על מכונות וירטואליות אחד או יותר משתנה באופן דרמטי, VMware DRS מפיצה מחדש את המכונות הוירטואליות על פני שרתים פיזיים. אם עומס העבודה הכולל יורד, ייתכן שחלק מהשרתים הפיזיים יועברו באופן זמני למצב לא מקוון ועומס העבודה יתאחד."

מדוע יש צורך באיזון?

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

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

עננים פרטיים / לקוחות ארגוניים גדולים
עננים ציבוריים / עסקים בינוניים וקטנים, אנשים

הקריטריון והמטרות העיקריות של המפעיל
מתן שירות או מוצר אמין
הפחתת עלות השירותים במאבק בשוק תחרותי

דרישות שירות
אמינות בכל הרמות ובכל מרכיבי המערכת

ביצועים מובטחים

תעדוף מכונות וירטואליות למספר קטגוריות 

אבטחת מידע ונתונים פיזיים

SLA ותמיכה XNUMX/XNUMX
קלות מרבית של קבלת השירות

שירותים פשוטים יחסית

האחריות על הנתונים היא של הלקוח

אין צורך בתעדוף VM

אבטחת מידע ברמת שירותים סטנדרטיים, אחריות על הלקוח

יתכנו תקלות

ללא SLA, איכות לא מובטחת

תמיכת דוא"ל

אין צורך בגיבוי

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

יישומים מדור קודם שעברו בירושה בחברה.

ארכיטקטורות מורכבות בהתאמה אישית לכל לקוח.

כללי זיקה.

התוכנה פועלת ללא עצירה במצב 7x24. 

כלי גיבוי תוך כדי תנועה.

עומס לקוחות מחזורי צפוי.
יישומים אופייניים - איזון רשת, Apache, WEB, VPN, SQL

היישום עשוי להפסיק לזמן מה

מאפשר הפצה שרירותית של VMs בענן

גיבוי לקוח

עומס ממוצע סטטיסטי צפוי עם מספר רב של לקוחות.

השלכות על אדריכלות
גיאוקלסינג

אחסון מרכזי או מבוזר

IBS שמור
אחסון נתונים מקומי בצמתי מחשוב

מטרות איזון
חלוקת עומס שווה

היענות אפליקציה מרבית 

זמן עיכוב מינימלי לאיזון

איזון רק כאשר יש צורך ברור

הוצאת קצת ציוד לתחזוקה מונעת
הפחתת עלויות השירות ועלויות המפעיל 

השבתת משאבים מסוימים במקרה של עומס נמוך

חוסך אנרגיה

הפחתת עלויות כוח אדם

אנו מסיקים לעצמנו את המסקנות הבאות:

לעננים פרטייםהמסופק ללקוחות עסקיים גדולים, ניתן להשתמש ב-DRS בכפוף להגבלות הבאות:

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

עבור עננים ציבורייםמתן שירותים ללקוחות קטנים, ניתן להשתמש ב-DRS לעתים קרובות יותר, עם יכולות מתקדמות:

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

מורכבות הבעיה

הקושי באיזון הוא ש-DRS חייב לעבוד עם מספר רב של גורמים לא ודאיים:

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

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

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

היסטוריה של ההתפתחויות שלנו

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

שלב 1

השתמשנו במערכת המבוססת על טכנולוגיית רשת עצבית וניסינו לייעל את המשאבים שלנו על בסיסה.

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

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

יחד עם זאת, היו לנו מגבלות די רציניות:

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

שלב 2

כיוון שלא היינו מרוצים ממצב העניינים, החלטנו לשנות את המערכת ולשם כך ענו השאלה העיקרית - למי אנחנו מכינים את זה?

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

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

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

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

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

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

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

כאשר מזוהה חוסר איזון ב-RAM או ב-CPU, המערכת מוציאה פקודות למתזמן Tionix לבצע הגירה חיה של המכונות הווירטואליות הנדרשות. כפי שניתן לראות ממערכת הניטור, המכונה הוירטואלית עברה ממארח ​​אחד (עליון) לאחר (תחתון) ושחרר זיכרון במארח העליון (מודגש בעיגולים צהובים), בהתאמה תפס אותו בתחתון (מודגש בלבן). מעגלים).

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

שלב 3

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

1. סטטיסטיקה, למשל, כאן и כאן מראה שמערכות שני וארבעה מעבדים נמוכות משמעותית בביצועים ממערכות מעבד יחיד. המשמעות היא שכל המשתמשים מקבלים פחות תפוקה משמעותית מ-CPU, RAM, SSD, LAN, FC שנרכשו במערכות מרובות מעבדים בהשוואה למעבדים בודדים.
2. למתזמני המשאבים עצמם עלולות להיות שגיאות חמורות, הנה אחד המאמרים בנושא זה.
3. טכנולוגיות שמציעות אינטל ו-AMD לניטור זיכרון RAM ומטמון מאפשרות ללמוד את ההתנהגות של מכונות וירטואליות ולמקם אותן בצורה כזו ששכנים "רועשים" לא יפריעו למכונות וירטואליות "שקטות".
4. הרחבת מערך הפרמטרים (רשת, מערכת אחסון, עדיפות המכונה הוירטואלית, עלות ההגירה, מוכנותה להגירה).

בסך הכל

התוצאה של עבודתנו לשיפור אלגוריתמי האיזון הייתה המסקנה הברורה שבאמצעות אלגוריתמים מודרניים ניתן להגיע לאופטימיזציה משמעותית של משאבי הדטה סנטר (25-30%) ובמקביל לשפר את איכות שירות הלקוחות.

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

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

מקור: www.habr.com