טאפרוור: הרוצח Kubernetes של פייסבוק?

ניהול יעיל ואמין של אשכולות בכל קנה מידה עם Tupperware

היום הלאה כנס Systems@Scale הצגנו את Tupperware, מערכת ניהול האשכולות שלנו שמתזמרת קונטיינרים על פני מיליוני שרתים המריצים כמעט את כל השירותים שלנו. פרסנו לראשונה את Tupperware ב-2011, ומאז התשתית שלנו גדלה מרכז נתונים 1 עד שלם 15 מרכזי נתונים מבוזרים גיאוגרפיים. כל הזמן הזה טאפרוור לא עמדה במקום והתפתחה איתנו. נראה לך כיצד Tupperware מספקת ניהול אשכולות מהשורה הראשונה, כולל תמיכה נוחה בשירותים ממלכתיים, פאנל בקרה יחיד לכל מרכזי הנתונים, ויכולת לחלק קיבולת בין שירותים בזמן אמת. אנו גם נשתף את הלקחים שלמדנו ככל שהתשתית שלנו מתפתחת.

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

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

ארכיטקטורת טאפרוור

ארכיטקטורת PRN של Tupperware היא אחד מהאזורים של מרכזי הנתונים שלנו. האזור מורכב ממספר בנייני מרכז נתונים (PRN1 ו-PRN2) הממוקמים בקרבת מקום. אנו מתכננים ליצור לוח בקרה אחד שינהל את כל השרתים באזור אחד.

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

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

• ה-frontend של Tupperware מספק ממשקי API עבור ממשק המשתמש, CLI וכלי אוטומציה אחרים שדרכם תוכל ליצור אינטראקציה עם Tupperware. הם מסתירים את כל המבנה הפנימי מבעלי משרות טאפרוור.
• Tupperware Scheduler הוא לוח בקרה האחראי על ניהול מחזור החיים של המכולה והעבודה. הוא נפרס ברמה אזורית וגלובלית, כאשר המתזמן האזורי מנהל שרתים באזור אחד והמתזמן הגלובלי מנהל שרתים מאזורים שונים. המתזמן מחולק לרסיסים, וכל רסיס מנהל מערך עבודות.
• פרוקסי מתזמן של Tupperware מסתיר את השבר הפנימי ומספק חלונית זכוכית אחת נוחה למשתמשי Tupperware.
• מקצה Tupperware מקצה קונטיינרים לשרתים. המתזמן מטפל בעצירה, הפעלה, עדכון וכשל של קונטיינרים. נכון לעכשיו, מקצה אחד יכול לנהל את האזור כולו מבלי להתפצל לרסיסים. (שים לב להבדל בטרמינולוגיה. לדוגמה, המתזמן בטאפרוור מתאים ללוח הבקרה ב קוברנט, ומקצה Tupperware נקרא מתזמן ב-Kubernetes.)
• מתווך המשאבים מאחסן את מקור האמת עבור אירועי השרת והשירות. אנו מפעילים מתווך משאבים אחד עבור כל מרכז נתונים, והוא מאחסן את כל המידע על השרתים באותו מרכז נתונים. מתווך המשאבים ומערכת ניהול הקיבולת, או מערכת הקצאת משאבים, מחליטים באופן דינמי איזה אספקת מתזמן שולט באיזה שרת. שירות בדיקת תקינות עוקב אחר שרתים ומאחסן נתונים על תקינותם במתווך המשאבים. אם לשרת יש בעיות או זקוק לתחזוקה, מתווך המשאבים אומר למקצה ולמתזמן לעצור את הקונטיינרים או להעביר אותם לשרתים אחרים.
• סוכן Tupperware הוא דמון הפועל בכל שרת שמכין ומסיר קונטיינרים. יישומים פועלים בתוך מיכל, מה שנותן להם יותר בידוד ושחזור. עַל כנס Systems @Scale בשנה שעברה כבר תיארנו כיצד מיכלי Tupperware בודדים נוצרים באמצעות תמונות, btrfs, cgroupv2 ו-systemd.

מאפיינים ייחודיים של טאפרוור

Tupperware דומה במובנים רבים למערכות ניהול אשכולות אחרות כגון Kubernetes ו מסוס, אבל יש גם הבדלים:

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

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

תמיכה מובנית עבור שירותים ממלכתיים.

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

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

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

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

ניהול שרתים במרכזי נתונים

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

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

ניתן להרחבה לתמיכה בכל המערכת הגלובלית

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

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

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

שפר את יעילות השימוש עם מחשוב אלסטי

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

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

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


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

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

הפקת לקחים ותוכניות לעתיד

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

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

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

מקור: www.habr.com