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

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

מה יצא מזה?

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

בקשות משתמשים מתקבלות הן בחזיתות הפורטל הראשי www.ok.ru, ובאחרים, למשל בחזיתות ה-API של מוזיקה. כדי לעבד את ההיגיון העסקי, הם מתקשרים לשרת היישומים, אשר בעת עיבוד הבקשה קורא לשירותי המיקרו המיוחדים הדרושים - גרף אחד (גרף של קשרים חברתיים), מטמון משתמש (מטמון של פרופילי משתמשים) וכו'.

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

למה? לגישה זו היו מספר יתרונות:

• הקלה ניהול המונים. נניח שמשימה דורשת מספר ספריות, כמה הגדרות. ואז השרת מוקצה בדיוק לקבוצה ספציפית אחת, מדיניות cfengine עבור קבוצה זו מתוארת (או שהיא כבר תוארה), והתצורה הזו מתגלגלת באופן מרכזי ואוטומטי לכל השרתים בקבוצה זו.
• מְפוּשָׁט אבחון. נניח שאתה מסתכל על העומס המוגבר על המעבד המרכזי ומבין שהעומס הזה יכול להיווצר רק על ידי המשימה שפועלת על מעבד החומרה הזה. החיפוש אחר מישהו להאשים מסתיים מהר מאוד.
• מְפוּשָׁט ניטור. אם משהו לא בסדר בשרת, המוניטור מדווח על כך, ואתה יודע בדיוק מי אשם.

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

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

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

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

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

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

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

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

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

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

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

הפצת קונטיינרים ידנית היא לא אופציה כשיש לך 8 אלף שרתים ו-8-16 אלף קונטיינרים.

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

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

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

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

הקצאת משאבים

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

משאב מחשוב בענן אחד הוא:

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

ואז עבור שירות כלשהו, ​​למשל עבור מטמון משתמש, נוכל להקליט את המשאבים הנצרכים בדרך זו: 400 ליבות מעבד, 2,5 TB של זיכרון, תעבורה של 50 Gbit/s לשני הכיוונים, 6 TB של שטח HDD הממוקם על 100 צירים. או בצורה יותר מוכרת כמו זו:

alloc:
    cpu: 400
    mem: 2500
    lan_in: 50g
    lan_out: 50g
    hdd:100x6T

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

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

מה שמושך את העין:

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

בואו נצייר מחדש את התמונה שוב:

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

על ידי הסרת השורות הנוספות, נוכל לכתוב כל צומת בתמונה שלנו בצורה שטוחה יותר: group1.web.front, api.music.front, user-cache.cache.

כך אנו מגיעים למושג "תור היררכי". יש לו שם כמו "group1.web.front". מוקצית לו מכסה של משאבים וזכויות משתמש. אנחנו ניתן לאדם מ-DevOps את הזכויות לשלוח שירות לתור, ועובד כזה יכול להפעיל משהו בתור, ולאדם מ-OpsDev יהיו זכויות אדמין, ועכשיו הוא יכול לנהל את התור, להקצות אליו אנשים, לתת לאנשים אלה זכויות וכו'. שירותים הפועלים בתור זה יפעלו במסגרת המכסה של התור. אם מכסת המחשוב של התור אינה מספיקה לביצוע כל השירותים בבת אחת, אז הם יבוצעו ברצף, ובכך יווצרו את התור עצמו.

בואו נסתכל מקרוב על השירותים. לשירות יש שם מלא, הכולל תמיד את שם התור. אז לשירות האינטרנט הקדמי יהיה השם ok-web.group1.web.front. ושירות שרת היישומים אליו הוא ניגש ייקרא ok-app.group1.web.front. לכל שירות יש מניפסט, המפרט את כל המידע הדרוש להצבה במכונות ספציפיות: כמה משאבים משימה זו צורכת, איזו תצורה נדרשת עבורה, כמה העתקים צריכים להיות, מאפיינים לטיפול בתקלות של שירות זה. ולאחר שהשירות ממוקם ישירות על המכונות, מופיעים המופעים שלו. הם נקראים גם באופן חד משמעי - כמספר המופע ושם השירות: 1.ok-web.group1.web.front, 2.ok-web.group1.web.front, …

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

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

שיעורי בידוד משימות

ניתן לחלק את כל המשימות ב-OK (וכנראה, בכל מקום) לקבוצות:

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

בואו נראה כיצד משימות כאלה צורכות משאבים, למשל, המעבד המרכזי.

משימות עיכוב קצר. למשימה כזו תהיה דפוס צריכת מעבד דומה לזה:

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

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

alloc: cpu = 4 (max)

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

משימות חישוב. הדפוס שלהם יהיה מעט שונה:

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

alloc: cpu = [1,*)

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

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

אבל איך עושים זאת?

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

• שימוש באפשרות --cpuset=1-4, כלומר להקצות ארבע ליבות ספציפיות במכונה למשימה.
• להשתמש --cpuquota=400_000 --cpuperiod=100_000, הקצה מכסה לזמן המעבד, כלומר ציין שכל 100 אלפיות השנייה של זמן אמת המשימה צורכת לא יותר מ-400 אלפיות השנייה של זמן מעבד. מתקבלות אותן ארבע ליבות.

אבל איזו מהשיטות הללו מתאימה?

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

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

הסכמנו שאם אצווה דורשת ערבות לליבה אחת לפחות, אז אנחנו מציינים --cpushares=1024, ואם יש לפחות שתי ליבות, אז אנחנו מציינים --cpushares=2048. שיתופי מעבד לא מפריעים בשום צורה לחלוקת זמן המעבד כל עוד יש מספיק ממנו. לפיכך, אם prod לא משתמש כרגע בכל ארבע הליבות שלו, אין שום דבר שמגביל משימות אצווה, והן יכולות להשתמש בזמן מעבד נוסף. אבל במצב שבו יש מחסור במעבדים, אם הפרוד צרך את כל ארבע הליבות שלו והגיע למכסה שלו, זמן המעבד שנותר יחולק באופן יחסי ל-cpushares, כלומר במצב של שלוש ליבות פנויות, אחת תהיה ניתן למשימה עם 1024 שיתופי מעבד, והשניים הנותרים יינתנו למשימה עם 2048 שיתופי מעבד.

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

• SCHED_OTHER
  כברירת מחדל, כל תהליכי המשתמש הרגילים במחשב לינוקס מקבלים.
• SCHED_BATCH
  מיועד לתהליכים עתירי משאבים. בעת הצבת משימה על מעבד, מוכנס מה שנקרא עונש הפעלה: סבירות שמשימה כזו תקבל משאבי מעבד אם היא נמצאת כעת בשימוש על ידי משימה עם SCHED_OTHER
• SCHED_IDLE
  תהליך רקע עם עדיפות נמוכה מאוד, אפילו נמוך מ-19 נחמד. אנו משתמשים בספריית הקוד הפתוח שלנו אחד-ניו, על מנת להגדיר את המדיניות הדרושה בעת הפעלת הקונטיינר על ידי קריאה

one.nio.os.Proc.sched_setscheduler( pid, Proc.SCHED_IDLE )

אבל גם אם אינך מתכנת ב-Java, ניתן לעשות את אותו הדבר באמצעות הפקודה chrt:

chrt -i 0 $pid

בואו נסכם את כל רמות הבידוד שלנו לטבלה אחת לבהירות:

כיתת בידוד
דוגמה Alloc
אפשרויות הפעלת Docker
sched_setscheduler chrt*

לדרבן
מעבד = 4
--cpuquota=400000 --cpuperiod=100000
SCHED_OTHER

תצווה
מעבד = [1, *)
--cpushares=1024
SCHED_BATCH

להתבטל
CPU= [2, *)
--cpushares=2048
SCHED_IDLE

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

אבל משימות צורכות לא רק את המעבד, אלא גם את התעבורה, מה שמשפיע על ההשהיה של משימת רשת אפילו יותר מהקצאה לא נכונה של משאבי המעבד. לכן, אנחנו כמובן רוצים לקבל בדיוק את אותה תמונה עבור תנועה. כלומר, כאשר משימת פרוד שולחת כמה מנות לרשת, אנו מגבילים את המהירות המקסימלית (נוסחה alloc: lan=[*,500mbps) ), שאיתו פרוד יכול לעשות זאת. ועבור אצווה אנו מבטיחים רק את התפוקה המינימלית, אך לא מגבילים את המקסימום (נוסחה alloc: lan=[10Mbps,*) ) במקרה זה, תעבורת פרוד צריכה לקבל עדיפות על פני משימות אצווה.
כאן ל-Docker אין פרימיטיבים שאנחנו יכולים להשתמש בהם. אבל זה בא לעזרתנו בקרת תנועה של לינוקס. הצלחנו להגיע לתוצאה הרצויה בעזרת משמעת עקומת שירות הוגן היררכית. בעזרתו, אנו מבחינים בין שני סוגים של תעבורה: פרוד בעדיפות גבוהה ואצווה/בטלה בעדיפות נמוכה. כתוצאה מכך, התצורה של תעבורה יוצאת היא כזו:

כאן 1:0 הוא "שורש qdisc" של דיסציפלינה hsfc; 1:1 - כיתת ילדים hsfc עם מגבלת רוחב פס כוללת של 8 Gbit/s, שמתחתיה ממוקמות כיתות הילד של כל המכולות; 1:2 - כיתת הילד hsfc משותפת לכל משימות האצווה והסרק עם מגבלה "דינמית", עליה נדון להלן. כיתות הילד הנותרות של hsfc הן מחלקות ייעודיות להפעלת קונטיינרים פרוד עם מגבלות המתאימות למניפסטים שלהם - 450 ו-400 Mbit/s. לכל מחלקה hsfc מוקצה תור qdisc fq או fq_codel, בהתאם לגרסת ליבת לינוקס, כדי למנוע אובדן מנות במהלך פרצי תנועה.

בדרך כלל, דיסציפלינות tc משמשות לתעדוף רק לתנועה יוצאת. אבל אנחנו רוצים לתעדף גם תעבורה נכנסת - אחרי הכל, איזו משימה יכולה לבחור בקלות את כל הערוץ הנכנס, ולקבל, למשל, אצווה גדולה של נתוני קלט עבור map&reduce. לשם כך אנו משתמשים במודול ifb, אשר יוצר ממשק וירטואלי ifbX עבור כל ממשק רשת ומנתב תעבורה נכנסת מהממשק לתעבורה יוצאת ב-ifbX. יתר על כן, עבור ifbX, כל אותן דיסציפלינות פועלות כדי לשלוט בתעבורה יוצאת, עבורה תצורת hsfc תהיה דומה מאוד:

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

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

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

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

עם הסרת השורות הנוספות שוב, נוכל לכתוב את שמות השירות שלנו בצורה שטוחה יותר על ידי הוספת מחלקת בידוד המשימות לסוף שם השירות המלא: web.front.prod, catalog.music.batch, שנאי.מוזיקה.בטלה.

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

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

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

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

בנוסף, עד כה הצלחנו לפתור רק את הבעיה של תעדוף תעבורת TCP: גישת hsfc לא עובדת עבור UDP. וגם במקרה של תעבורת TCP, אם משימת האצווה מייצרת הרבה תעבורה, זה גם נותן בערך 10% עלייה בעיכוב של משימת ה-prod.

סובלנות לתקלות

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

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

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

מה אתה יכול לעשות אם מיניון שלם אינו זמין?

ברור, הפעל את המיכל במכונה אחרת. החלק המעניין כאן הוא מה קורה לכתובת/ות ה-IP שהוקצו למיכל.

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

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

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

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

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

לפיכך, המיפוי של שם שירות לרשימת כתובות ה-IP שלו משתנה לעתים רחוקות מאוד. אם תסתכל שוב על שמות מקרי השירות שהזכרנו בתחילת המאמר (1.ok-web.group1.web.front.prod, 2.ok-web.group1.web.front.prod, …), נבחין שהם דומים ל-FQDNs המשמשים ב-DNS. זה נכון, כדי למפות את שמות מופעי השירות לכתובות ה-IP שלהם, אנו משתמשים בפרוטוקול DNS. יתרה מכך, ה-DNS הזה מחזיר את כל כתובות ה-IP השמורות של כל הקונטיינרים - הן פועלות והן עצורות (נניח שנעשה שימוש בשלוש העתקים, ויש לנו חמש כתובות שמורות שם - כל החמש יוחזרו). לקוחות, לאחר שקיבלו מידע זה, ינסו ליצור קשר עם כל חמשת ההעתקים - וכך לקבוע את אלו שפועלים. אפשרות זו לקביעת זמינות אמינה הרבה יותר; היא אינה כרוכה ב-DNS או ב-Service Discovery, מה שאומר שאין בעיות קשות לפתרון בהבטחת הרלוונטיות של המידע וסובלנות תקלות של מערכות אלו. יתרה מכך, בשירותים קריטיים שבהם תלויה פעולת הפורטל כולו, לא נוכל להשתמש ב-DNS כלל, אלא פשוט להזין כתובות IP לתוך התצורה.

הטמעת העברת IP כזו מאחורי קונטיינרים יכולה להיות לא טריוויאלית - ואנו נראה איך זה עובד עם הדוגמה הבאה:

נניח שהמאסטר של ענן אחד נותן את הפקודה ל-Minion M1 לרוץ 1.ok-web.group1.web.front.prod עם כתובת 1.1.1.1. עובד על מיניון בירד, שמפרסמת כתובת זו לשרתים מיוחדים משקף מסלול. לאחרונים יש הפעלת BGP עם חומרת הרשת, אליה מתורגם מסלול הכתובת 1.1.1.1 ב-M1. M1 מנתב מנות בתוך הקונטיינר באמצעות לינוקס. ישנם שלושה שרתי מחזירי מסלול, מאחר וזהו חלק מאוד קריטי בתשתית הענן האחד – בלעדיהם הרשת בענן אחד לא תעבוד. אנו מניחים אותם במדפים שונים, אם אפשר ממוקמים בחדרים שונים של מרכז הנתונים, כדי להפחית את הסבירות ששלושתם ייכשלו בו זמנית.

כעת נניח שהחיבור בין מאסטר הענן האחד למיניון M1 אבד. המאסטר של ענן אחד יפעל כעת בהנחה ש-M1 נכשל לחלוטין. כלומר, הוא ייתן את הפקודה למיניון M2 לשיגור web.group1.web.front.prod עם אותה כתובת 1.1.1.1. כעת יש לנו שני מסלולים סותרים ברשת עבור 1.1.1.1: ב-M1 וב-M2. על מנת לפתור התנגשויות כאלה, אנו משתמשים ב-Multi Exit Discriminator, המצוין בהודעת BGP. זהו מספר שמראה את משקל המסלול המפורסם. בין המסלולים המתנגשים, ייבחר המסלול עם ערך ה- MED הנמוך יותר. המאסטר של ענן אחד תומך ב- MED כחלק בלתי נפרד מכתובות ה-IP של מיכל. בפעם הראשונה הכתובת נכתבת עם MED גדול מספיק = 1. במצב של העברת מכולה חירום כזו, המאסטר מקטין את ה-MED, ו-M000 כבר יקבל את הפקודה לפרסם את הכתובת 000 עם MED = 2. המופע שרץ ב-M1.1.1.1 יישאר במצב זה, אין קשר, וגורל נוסף שלו מעניין אותנו מעט עד שהקשר עם המאסטר ישוחזר, כאשר הוא יופסק כמו טייק ישן.

תאונות

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

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

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

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

מה אתה יכול לעשות עם כל זה?

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

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

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

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

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

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

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

תאונות DC שלמות

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

וזה מה שאנחנו עושים כדי למנוע מאף אחד לצייץ #חי.

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

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

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

תוצאות של

מאפיינים ייחודיים של ענן אחד:

• ערכת שמות היררכית וויזואלית עבור שירותים ומכולות, מה שמאפשר לגלות מהר מאוד מהי המשימה, למה היא קשורה ואיך היא עובדת ומי אחראי עליה.
• אנו מיישמים את שלנו טכניקה של שילוב פרוד ואצווה-משימות על מיניונים לשיפור היעילות של שיתוף מכונה. במקום cpuset אנו משתמשים במכסות CPU, שיתופים, מדיניות מתזמן CPU ו-Linux QoS.
• לא ניתן היה לבודד לחלוטין מכולות הפועלות על אותה מכונה, אך ההשפעה ההדדית שלהן נותרה בטווח של 20%.
• ארגון שירותים בהיררכיה מסייע בהתאוששות אוטומטית מאסון באמצעות עדיפויות מיקום וקדימות.

שאלות נפוצות

למה לא לקחנו פתרון מוכן?

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

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

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

מקור: www.habr.com