כיצד להגדיל את מרכזי הנתונים. דוח Yandex

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

במקרים, למשל, עם Clos דו-מפלסי, כשאפשר לזהות בבירור רכיבים שהם אנכיים בתרשים שלי, הם נקראים בדרך כלל מישורים. אם היינו בונים Clos עם שלוש רמות של מתגי עמוד השדרה (שכולם אינם מתגי גבול או ToR ואשר משמשים רק למעבר), אז המטוסים היו נראים מורכבים יותר; דו-מפלסים נראים בדיוק כך. אנו קוראים לגוש של מתגי ToR או עלים ולמתגי עמוד השדרה ברמה הראשונה המשויכים אליהם Pod. מתגי עמוד השדרה של רמת עמוד השדרה-1 בחלק העליון של הפוד הם החלק העליון של הפוד, החלק העליון של הפוד. המתגים הממוקמים בחלק העליון של המפעל כולו הם השכבה העליונה של המפעל, Top of fabric.

כמובן, נשאלת השאלה: רשתות Clos נבנו כבר זמן מה, הרעיון עצמו מגיע בדרך כלל מתקופת הטלפוניה הקלאסית, רשתות TDM. אולי הופיע משהו טוב יותר, אולי אפשר לעשות משהו טוב יותר? כן ולא. תיאורטית כן, בפועל בעתיד הקרוב בהחלט לא. מכיוון שישנן מספר טופולוגיות מעניינות, חלקן אף משמשות בייצור, למשל, Dragonfly משמש ביישומי HPC; יש גם טופולוגיות מעניינות כמו Xpander, FatClique, מדוזה. אם תסתכל על דיווחים בכנסים כמו SIGCOMM או NSDI לאחרונה, אתה יכול למצוא מספר גדול למדי של עבודות על טופולוגיות אלטרנטיביות שיש להן תכונות טובות יותר (זו או אחרת) מאשר Clos.

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

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

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

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

בסדר, הסתפקנו בטופולוגיה הלוגית של Clos. איך נרחיב את זה? בואו נראה איך זה עובד ומה אפשר לעשות.

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

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

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

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

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

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

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

ניתן לראות שבכל העיצוב הזה מעניינות שתיים וחצי אפשרויות. ישנה אפשרות עם שתי שכבות של קוצים ומתגים של 64 יציאות, שקצת נופלת. אז יש אפשרויות מתאימות בצורה מושלמת עבור מתגי עמוד שדרה עם 128 יציאות (עם radix 128) עם שתי רמות, או מתגים עם radix 32 עם שלוש רמות. ובכל המקרים, שבהם יש יותר רדיקסים ויותר שכבות, אתה יכול ליצור רשת גדולה מאוד, אבל אם אתה מסתכל על הצריכה הצפויה, בדרך כלל יש ג'יגה וואט. אפשר להניח כבל, אבל לא סביר שנקבל כל כך הרבה חשמל באתר אחד. אם אתה מסתכל על נתונים סטטיסטיים ונתונים ציבוריים על מרכזי נתונים, אתה יכול למצוא מעט מאוד מרכזי נתונים עם קיבולת משוערת של יותר מ-150 MW. הגדולים שבהם הם בדרך כלל קמפוסים של מרכז נתונים, מספר מרכזי נתונים גדולים הממוקמים די קרוב זה לזה.

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

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

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

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

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

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

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

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

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

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

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

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

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

מה יקרה לפיזיקה? חישובים פשוטים מאוד. אם יש לנו שתי רמות של קוצים, אז יש לנו רק שלוש רמות של מתגים, ואנו מצפים שיהיו שלושה מקטעי כבלים ברשת: משרתים למתגי עלים, לעמוד 1 ועד עמוד שדרה 2. האפשרויות שאנו יכולים use are - אלו הם twinax, multimode, single mode. וכאן אנחנו צריכים לשקול איזה פס זמין, כמה זה יעלה, מה המידות הפיזיות, איזה טווחים נוכל לכסות ואיך נשדרג.

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

הערה נוספת: למרבה הצער, זה לא מאוד אפשרי להשתמש ביציאות מולטי-מודים מפורקות של 100 עד 4x25. בשל תכונות העיצוב של מקלטי משדר SFP28, הוא אינו זול בהרבה מ-28 Gbit QSFP100. והפירוק הזה עבור multimode לא עובד טוב במיוחד.

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

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

ככה זה נראה לאחרונה, לאן אנחנו הולכים ומה אפשרי. ברור, לפחות, איך להתקדם לכיוון 50-Gigabit SerDes עבור מולטי-מודים וגם במצב יחיד. יתרה מכך, אם מסתכלים על מה שיש במקלטי משדר במצב יחיד עכשיו ובעתיד עבור 400G, לעתים קרובות גם כאשר 50G SerDes מגיעים מהצד החשמלי, 100Gbps לנתיב כבר יכולים לעבור לאופטיקה. לכן, בהחלט ייתכן שבמקום לעבור ל-50, יהיה מעבר ל-100 Gigabit SerDes ו-100 Gbps לנתיב, כי לפי הבטחות של ספקים רבים, זמינותם צפויה די בקרוב. התקופה שבה 50G SerDes היו המהירים ביותר, כך נראה, לא תהיה ארוכה במיוחד, כי העותקים הראשונים של 100G SerDes יוצאים כמעט בשנה הבאה. ואחרי כמה זמן אחר כך הם כנראה יהיו שווים כסף סביר.

ניואנס נוסף לגבי הבחירה בפיזיקה. באופן עקרוני, אנחנו כבר יכולים להשתמש ביציאות של 400 או 200 Gigabit באמצעות 50G SerDes. אבל מסתבר שזה לא הגיוני במיוחד, כי, כפי שאמרתי קודם, אנחנו רוצים רדיוס די גדול על המתגים, כמובן בסבירות. אנחנו רוצים 128. ואם יש לנו קיבולת שבב מוגבלת ואנחנו מגבירים את מהירות הקישור, אז הרדיוס יורד באופן טבעי, אין ניסים.

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

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

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

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

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

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

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

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

לשם כך, אנו משתמשים בעיצוב פשוט מספיק כדי להשתמש במנגנוני BGP הבסיסיים. כלומר, אנו משתמשים ב-eBGP הפועל על קישור מקומי, ומערכות אוטונומיות מוקצות באופן הבא: מערכת אוטונומית ב-ToR, מערכת אוטונומית על כל הבלוק של מתגי עמוד השדרה-1 של Pod אחד, ומערכת אוטונומית כללית על כל ה-Top. של בד. לא קשה להסתכל ולראות שאפילו ההתנהגות הרגילה של BGP נותנת לנו את הפצת העדכונים שאנחנו רוצים.

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

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

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

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

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

איך נראית מדרגיות מטוסי נתונים במכשירים מודרניים? אם נעשה LPM (התאמת הקידומת הארוכה ביותר), הכל די טוב, יותר מ-100 קידומות. אם אנחנו מדברים על קבוצות Next Hop, אז הכל יותר גרוע, 2-4 אלף. אם אנחנו מדברים על טבלה שמכילה תיאור של Next Hops (או adjacencies), אז זה איפשהו בין 16k ל-64k. וזה יכול להפוך לבעיה. וכאן הגענו לסטייה מעניינת: מה קרה ל-MPLS במרכזי נתונים? באופן עקרוני, רצינו לעשות את זה.

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

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

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

קל לראות שבתכנון שלנו היינו צריכים כ-4000 מתגי ToR, הרוחב המרבי היה 64 נתיבי ECMP, אם נתרחק מעמוד שדרה-1 לכיוון שדרה-2. אנחנו בקושי נכנסים לטבלה אחת של קבוצות ECMP, אם רק קידומת אחת עם ToR נעלמת, ואנחנו בכלל לא נכנסים לטבלת Next Hops.

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

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

אפשרות נוספת היא להתחיל תעבורה כזו מלמטה. קל לאמת שהטופולוגיה של Clos בנויה בצורה כזו שתעבורה שמגיעה מלמטה, כלומר מהצד של ה-ToR, מפוזרת באופן שווה בין הרמות על פני כל ה-Top of fabric בשתי איטרציות, תוך שהיא טוענת את כל הרשת. לכן, אנו מציגים סוג מיוחד של Pod, Edge Pod, המספק קישוריות חיצונית.

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

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

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

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

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

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

מקור: www.habr.com