איזון עומסים ב-Openstack

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

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

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

מונחים והגדרות

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

פעולה היא משימה אלמנטרית המשנה את המצב הנוכחי של משאב היעד המנוהל של אשכול OpenStack, כגון: העברת מכונה וירטואלית (הגירה), שינוי מצב הספק של צומת (change_node_power_state), שינוי מצב שירות nova (change_nova_service_state ), שינוי טעם (שינוי גודל), רישום הודעות NOP (nop), חוסר פעולה למשך זמן מסוים - הפסקה (שינה), העברת דיסק (volume_migrate).

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

בְּדִיקָה היא בקשה לייעל את האשכול. אופטימיזציה מתבצעת על מנת להשיג יעד אחד באשכול נתון. עבור כל ביקורת מוצלחת, Watcher מייצר תוכנית פעולה.

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

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

אֶשׁכּוֹל הוא אוסף של מכונות פיזיות המספקות משאבי מחשוב, אחסון ורשת ומנוהלים על ידי אותו צומת ניהול OpenStack.

מודל נתוני אשכול (CDM) הוא ייצוג לוגי של המצב הנוכחי והטופולוגיה של המשאבים המנוהלים על ידי האשכול.

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

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

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

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

מטרות ואסטרטגיות של Watcher

יעד
אסטרטגיה

גול דמה
אסטרטגיית דמה 

אסטרטגיית דמה באמצעות מנועי ניקוד לדוגמה

אסטרטגיית דמה עם שינוי גודל

חיסכון באנרגיה
אסטרטגיית חיסכון באנרגיה

איחוד שרתים
איחוד שרתים לא מקוון בסיסי

אסטרטגיית איחוד עומסי עבודה של VM

איזון עומסי עבודה
אסטרטגיית הגירה של איזון עומסי עבודה

אסטרטגיית איזון קיבולת אחסון

ייצוב עומס העבודה

שכן רועש
שכן רועש

אופטימיזציה תרמית
אסטרטגיה מבוססת טמפרטורת יציאה

אופטימיזציה של זרימת אוויר
אסטרטגיית העברת זרימת אוויר אחידה

תחזוקת חומרה
נדידת אזור

לא מסווג
מפעיל

גול דמה - יעד שמור המשמש למטרות בדיקה.

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

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

אסטרטגיית דמה עם שינוי גודל - האסטרטגיה דומה לקודמתה, ההבדל היחיד הוא השימוש בשינוי הטעם (הגירה ושינוי גודל).

לא בשימוש בייצור.

חיסכון באנרגיה - למזער את צריכת האנרגיה. אסטרטגיית חיסכון באנרגיה של מטרה זו, יחד עם אסטרטגיית איחוד עומס העבודה של VM (איחוד שרתים), מסוגלות לתכונות ניהול צריכת חשמל דינמי (DPM) החוסכות אנרגיה על ידי איחוד דינמי של עומסי עבודה אפילו בתקופות של ניצול משאבים נמוך: מכונות וירטואליות מועברות לפחות צמתים וצמתים מיותרים מושבתים. לאחר איחוד, האסטרטגיה מציעה החלטה על הפעלה/כיבוי של צמתים בהתאם לפרמטרים שצוינו: "min_free_hosts_num" - מספר הצמתים הפנויים המאפשרים ממתינים לטעינה, ו-"free_used_percent" - אחוז המארחים המופעלים בחינם ל- מספר צמתים שתפוסים על ידי מכונות. כדי שהאסטרטגיה תעבוד חייבת להיות איפשרה והגדירה את Ironic לטיפול במחזורי חשמל בצמתים.

פרמטרים של אסטרטגיה

פרמטר
тип
כברירת מחדל
описание

free_used_percent
מספר
10.0
יחס בין מספר צמתי המחשוב הפנויים למספר צמתי המחשוב עם מכונות וירטואליות

min_free_hosts_num
Int
1
מספר מינימלי של צמתי מחשוב פנויים

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

איחוד שרתים - צמצם את מספר צמתי המחשוב (קונסולידציה). יש לו שתי אסטרטגיות: איחוד שרתים לא מקוונים בסיסי ואסטרטגיית איחוד עומסי עבודה VM.

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

האסטרטגיה הבסיסית דורשת את המדדים הבאים:

מדדים
שירות
תוספים
פרשנות

compute.node.cpu.percent
מד צלעות
אף לא אחד
 

cpu_util
מד צלעות
אף לא אחד
 

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

שיטות בשימוש: הגירה, שינוי מצב שירות nova (change_nova_service_state).

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

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

האסטרטגיה דורשת את המדדים הבאים:

מדדים
שירות
תוספים
פרשנות

זיכרון
מד צלעות
אף לא אחד
 

גודל.שורש.דיסק
מד צלעות
אף לא אחד
 

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

מדדים
שירות
תוספים
פרשנות

זיכרון.תושב
מד צלעות
אף לא אחד
 

cpu_util
מד צלעות
אף לא אחד
 

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

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

איזון עומסי עבודה - איזון עומס העבודה בין צמתי מחשוב. למטרה שלוש אסטרטגיות: אסטרטגיית העברת איזון עומס עבודה, ייצוב עומס עבודה, אסטרטגיית איזון קיבולת אחסון.

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

דרישות

• שימוש במעבדים פיזיים;
• לפחות שני צמתי מחשוב פיזיים;
• התקן והגדיר את רכיב ה-Ceilometer - ceilometer-agent-compute, פועל בכל צומת מחשוב, ואת ה-Ceilometer API, כמו גם איסוף המדדים הבאים:

מדדים
שירות
תוספים
פרשנות

cpu_util
מד צלעות
אף לא אחד
 

זיכרון.תושב
מד צלעות
אף לא אחד
 

פרמטרים של אסטרטגיה:

פרמטר
тип
כברירת מחדל
описание

מדדים
מחרוזת
'cpu_util'
המדדים הבסיסיים הם: 'cpu_util', 'memory.resident'.

סף
מספר
25.0
סף עומס עבודה להגירה.

תקופה
מספר
300
פרק זמן מצטבר Ceilometer.

השיטה בה משתמשים היא הגירה.

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

דרישות

• שימוש במעבדים פיזיים;
• לפחות שני צמתי מחשוב פיזיים;
• התקן והגדיר את רכיב ה-Ceilometer - ceilometer-agent-compute, פועל בכל צומת מחשוב, ואת ה-Ceilometer API, כמו גם איסוף המדדים הבאים:

מדדים
שירות
תוספים
פרשנות

cpu_util
מד צלעות
אף לא אחד
 

זיכרון.תושב
מד צלעות
אף לא אחד
 

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

דרישות והגבלות

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

פרמטרים של אסטרטגיה:

פרמטר
тип
כברירת מחדל
описание

volume_threshold
מספר
80.0
ערך סף של דיסקים לאיזון נפחים.

השיטה שבה נעשה שימוש היא העברת דיסקים (volume_migrate).

Noisy Neighbor - זיהוי והעברה של "שכן רועש" - מכונה וירטואלית בעדיפות נמוכה שמשפיעה לרעה על הביצועים של מכונה וירטואלית בעדיפות גבוהה במונחים של IPC על ידי שימוש יתר ב-Last Level Cache. אסטרטגיה משלו: Noisy Neighbor (פרמטר אסטרטגיה בשימוש הוא cache_threshold (ערך ברירת המחדל הוא 35), כאשר הביצועים יורדים לערך שצוין, ההעברה מתחילה. כדי שהאסטרטגיה תעבוד, מופעל מדדי LLC (מטמון ברמה האחרונה), שרת אינטל העדכני ביותר עם תמיכה ב-CMT, כמו גם איסוף המדדים הבאים:

מדדים
שירות
תוספים
פרשנות

cpu_l3_cache
מד צלעות
אף לא אחד
אינטל נדרשת CMT.

מודל נתוני אשכול (ברירת מחדל): אוסף מודל נתוני אשכול נתונים של Nova. השיטה בה משתמשים היא הגירה.

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

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

כדי שהאסטרטגיה תעבוד, אתה צריך שרת עם Intel Power Node Manager מותקן ומוגדר 3.0 ואילך, כמו גם איסוף המדדים הבאים:

מדדים
שירות
תוספים
פרשנות

hardware.ipmi.node.outlet_temperature
מד צלעות
IPMI
 

פרמטרים של אסטרטגיה:

פרמטר
тип
כברירת מחדל
описание

סף
מספר
35.0
סף טמפרטורה להגירה.

תקופה
מספר
30
מרווח הזמן, בשניות, לקבלת הצבירה הסטטיסטית ממקור הנתונים המטריים.

השיטה בה משתמשים היא הגירה.

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

כדי שהאסטרטגיה תעבוד אתה צריך:

• חומרה: צמתי מחשוב < תומכים ב-NodeManager 3.0;
• לפחות שני צמתי מחשוב;
• רכיב ה-Ceilometer-agent-compute ו-Ceilometer API מותקן ומוגדר בכל צומת מחשוב, שיכולים לדווח בהצלחה על מדדים כגון זרימת אוויר, הספק מערכת, טמפרטורת כניסה:

מדדים
שירות
תוספים
פרשנות

hardware.ipmi.node.flow
מד צלעות
IPMI
 

hardware.ipmi.node.temperatur
מד צלעות
IPMI
 

hardware.ipmi.node.power
מד צלעות
IPMI
 

כדי שהאסטרטגיה תעבוד, אתה צריך שרת עם Intel Power Node Manager 3.0 ואילך מותקן ומוגדר.

מגבלות: הקונספט אינו מיועד לייצור.

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

הגירה חיה אפשרית.

פרמטרים של אסטרטגיה:

פרמטר
тип
כברירת מחדל
описание

threshold_flow
מספר
400.0
סף זרימת האוויר ליחידת הגירה הוא 0.1CFM

threshold_inlet_t
מספר
28.0
סף טמפרטורת הכניסה להחלטת הגירה

כוח_סף
מספר
350.0
סף כוח מערכת להחלטת הגירה

תקופה
מספר
30
מרווח הזמן, בשניות, לקבלת הצבירה הסטטיסטית ממקור הנתונים המטריים.

השיטה בה משתמשים היא הגירה.

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

מגבלות: יש להגדיר משקלי פעולה והקבלה.

פרמטרים של אסטרטגיה:

פרמטר
тип
כברירת מחדל
описание

compute_nodes
מערך
ללא חתימה
חישוב צמתים להגירה.

בריכות_אחסון
מערך
ללא חתימה
צמתי אחסון להעברה.

parallel_total
מספר שלם
6
המספר הכולל של הפעילויות שיש לבצע במקביל.

parallel_per_node
מספר שלם
2
מספר הפעולות שבוצעו במקביל עבור כל צומת מחשוב.

parallel_per_pool
מספר שלם
2
מספר הפעולות שבוצעו במקביל עבור כל מאגר אחסון.

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

with_attached_volume
בוליאני
לא נכון
False—מכונות וירטואליות יועברו לאחר העברת כל הדיסקים. נכון - מכונות וירטואליות יועברו לאחר העברת כל הדיסקים המחוברים.

אלמנטים של מערך צמתי המחשוב:

פרמטר
тип
כברירת מחדל
описание

src_node
מחרוזת
ללא חתימה
צומת המחשוב שממנו מעבירים את המכונות הוירטואליות (חובה).

dst_node
מחרוזת
ללא חתימה
חשב את הצומת שאליו עוברות המכונות הוירטואליות.

רכיבי מערך צומת אחסון:

פרמטר
тип
כברירת מחדל
описание

src_pool
מחרוזת
ללא חתימה
מאגר האחסון שממנו מועברים הדיסקים (חובה).

dst_pool
מחרוזת
ללא חתימה
מאגר האחסון אליו מועברים הדיסקים.

src_type
מחרוזת
ללא חתימה
סוג דיסק מקורי (חובה).

dst_type
מחרוזת
ללא חתימה
סוג הדיסק המתקבל (חובה).

רכיבי עדיפות אובייקט:

פרמטר
тип
כברירת מחדל
описание

פּרוֹיֶקט
מערך
ללא חתימה
שמות פרויקטים.

compute_node
מערך
ללא חתימה
חישוב שמות צמתים.

מאגר_אחסון
מערך
ללא חתימה
שמות בריכות אחסון.

לחשב
enum
ללא חתימה
פרמטרים של מכונה וירטואלית ["vcpu_num", "mem_size", "disk_size", "created_at"].

אחסון
enum
ללא חתימה
פרמטרי דיסק ["גודל", "created_at"].

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

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

יצירת מטרה חדשה

Watcher Decision Engine בעל ממשק תוסף "מטרה חיצונית" המאפשר לשלב יעד חיצוני שניתן להשיג באמצעות אסטרטגיה.

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

יצירת תוסף חדש

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

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

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

ליישם את השיטה שלו get_efficacy_specification()כדי להחזיר את מפרט היעילות עבור היעד שלך. השיטה get_efficacy_specification() מחזירה את המופע Unclassified() שסופק על ידי Watcher. מפרט ביצועים זה שימושי בתהליך פיתוח המטרה שלך מכיוון שהוא מתאים למפרט הריק.

→ קרא עוד כאן

ארכיטקטורת Watcher (פרטים נוספים) כאן).

רכיבים

Watcher API - רכיב שמיישם את REST API שמסופק על ידי Watcher. מנגנוני אינטראקציה: CLI, תוסף Horizon, Python SDK.

Watcher DB - מסד נתונים של Watcher.

Watcher Applier - רכיב המיישם ביצוע תוכנית פעולה שנוצרה על ידי רכיב Watcher Decision Engine.

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

מוציא לאור של Watcher Metrics - רכיב שאוסף ומחשב כמה מדדים או אירועים ומפרסם אותם לנקודת הקצה של CEP. הפונקציונליות של הרכיב יכולה להיות מסופקת גם על ידי המוציא לאור של Ceilometer.

מנוע עיבוד אירועים מורכב (CEP). - מנוע לעיבוד אירועים מורכבים. מטעמי ביצועים, עשויים להיות מופעי CEP Engine מרובים הפועלים במקביל, כל אחד מעבד סוג מסוים של מדד/אירוע. במערכת Watcher, CEP מפעיל שני סוגים של פעולות: - רישום האירועים / המדדים המתאימים במסד הנתונים של סדרות הזמן; - שלח אירועים מתאימים ל-Water Decision Engine כאשר אירוע זה יכול להשפיע על התוצאה של אסטרטגיית האופטימיזציה הנוכחית, מכיוון שאשכול Openstack אינו מערכת סטטית.

הרכיבים מקיימים אינטראקציה באמצעות פרוטוקול AMQP.

→ הגדרת Watcher

תכנית האינטראקציה עם Watcher

תוצאות בדיקת הצופה

1. באופטימיזציה - תוכניות פעולה עמוד 500 (הן בקווינס טהור והן במעמד עם מודולים של Tionix), היא מופיעה רק לאחר השקת הביקורת והפקת תוכנית פעולה; הריקה נפתחת כרגיל.
2. ישנן שגיאות בלשונית פרטי הפעולה, לא ניתן לקבל את מטרת הביקורת והאסטרטגיה (גם בקווינס טהור וגם בסטנד עם מודולים של Tionix).
3. ביקורת עם מטרת Dummy (מבחן) נוצרות ומושקות כרגיל, תוכניות פעולה נוצרות.
4. ביקורת עבור היעד הבלתי מסווג לא נוצרות מכיוון שהמטרה אינה פונקציונלית ומיועדת לתצורת ביניים בעת יצירת אסטרטגיות חדשות.
5. ביקורת לצורך איזון עומסי עבודה (אסטרטגיית איזון קיבולת אחסון) נוצרות בהצלחה, אך לא נוצרת תוכנית פעולה. אין צורך באופטימיזציה של בריכת האחסון.
6. ביקורת עבור יעד איזון עומסי עבודה (אסטרטגיית העברת איזון עומסים) נוצרות בהצלחה, אך לא נוצרת תוכנית פעולה.
7. ביקורת לאיזון עומסי עבודה (אסטרטגיית ייצוב עומס עבודה) נכשלות.
8. ביקורת עבור יעד השכן הרועש נוצרות בהצלחה, אך לא נוצרת תוכנית פעולה.
9. ביקורת לצורך תחזוקת חומרה נוצרות בהצלחה, תוכנית הפעולה אינה מופקת במלואה (נוצרים מדדי ביצוע, אך רשימת הפעולות עצמה אינה נוצרת).
10. עריכות בתצורות nova.conf (בסעיף ברירת המחדל compute_monitors = cpu.virt_driver) בצמתי החישוב והבקרה לא מתקנות את השגיאות.
11. גם ביקורות המכוונות לאיחוד שרתים (אסטרטגיה בסיסית) נכשלות.
12. ביקורת למטרת איחוד שרתים (אסטרטגיית איחוד עומסי עבודה VM) נכשלות עם שגיאה. ביומנים ישנה שגיאה בהשגת נתוני מקור. דיון על הטעות, במיוחד כאן.
    ניסינו לציין את Watcher בקובץ התצורה (זה לא עזר - כתוצאה משגיאה בכל דפי האופטימיזציה, חזרה לתוכן המקורי של קובץ התצורה לא מתקן את המצב):
    [watcher_strategies.basic] מקור נתונים = ceilometer, ניוקי
13. ביקורות לחיסכון באנרגיה נכשלות. אם לשפוט לפי היומנים, הבעיה היא עדיין היעדר Ironic; זה לא יעבוד ללא שירות baremetal.
14. ביקורות לאופטימיזציה תרמית נכשלות. העקיבה לאחור זהה ל-Server Consolidation (אסטרטגיית איחוד עומסי עבודה VM) (שגיאת נתוני מקור)
15. ביקורות למטרת אופטימיזציית זרימת אוויר נכשלות עם שגיאה.

נתקלו גם בשגיאות השלמת הביקורת הבאות. Traceback ביומני decision-engine.log (מצב אשכול לא מוגדר).

← דיון בשגיאה כאן

מסקנה

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

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

אבל עוד על כך במאמרים הבאים של הסדרה.

מקור: www.habr.com