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

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

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


עבור מהנדסי רשת רבים, רשת מרכז הנתונים מתחילה, כמובן, ב-ToR, עם מתג במדף. ל-ToR יש בדרך כלל שני סוגים של קישורים. הקטנים הולכים לשרתים, אחרים - יש פי N יותר מהם - הולכים לכיוון הקוצים של הרמה הראשונה, כלומר אל ה-uplinks שלו. קישורים מעלה נחשבים בדרך כלל שווים, והתעבורה בין קישורים מעלה מאוזנת בהתבסס על 5-tuple hash, הכולל פרוטו, src_ip, dst_ip, src_port, dst_port. אין כאן הפתעות.


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


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


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


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


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

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


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


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


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


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


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


מה יקרה אם נאבד חבילה 3? במקרה זה, הנמען יקבל מנות 1, 2 ו-4. והוא יודיע במפורש לשולח באמצעות אפשרות SACK: "אתה יודע, הגיעו שלוש, אבל האמצע אבד". הוא אומר "אק 2, שק 4".


השולח ברגע זה חוזר בדיוק על החבילה שאבדה ללא בעיות.


אבל אם החבילה האחרונה בחלון תאבד, המצב ייראה שונה מאוד.

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


מהו פסק זמן RTO? זהו המקסימום מה-RTT המחושב על ידי מחסנית ה-TCP וקבוע כלשהו. מהו הקבוע הזה, נדון כעת.


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


עכשיו בואו נראה למה הבסיס הזה שווה. כברירת מחדל, RTO המינימלי הוא 200ms. זהו ה-RTO המינימלי עבור מנות נתונים. עבור מנות SYN, זה שונה, שנייה אחת. כפי שאתה יכול לראות, אפילו הניסיון הראשון לשלוח מנות מחדש ייקח פי 1 יותר מאשר RTT בתוך מרכז הנתונים.


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


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


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

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


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


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

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


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


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


מה יכול לעזור לנו? חלקכם כבר ניחשו מהשם שהשדה החשוב בסיפור הנוסף שלנו יהיה שדה הכותרת של תווית הזרימה של IPv6. אכן, זה שדה שמופיע ב-v6, הוא לא ב-v4, הוא לוקח 20 סיביות, ויש מחלוקת לגבי השימוש בו כבר הרבה זמן. זה מאוד מעניין - היו מחלוקות, משהו תוקן במסגרת ה-RFC, ובמקביל הופיע בליבת לינוקס מימוש שמעולם לא תועד בשום מקום.


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

שנת 2014. מהנדס מחברה גדולה ומוכרת מוסיף לפונקציונליות של ליבת לינוקס את התלות של ערך תווית הזרימה ב-hash של השקע. מה מנסים לתקן כאן? זה קשור ל-RFC 6438 שדן בנושא הבא. בתוך מרכז הנתונים, IPv4 מוקף לרוב בחבילות IPv6, מכיוון שהמפעל עצמו הוא IPv6, אבל איכשהו חייבים למסור את IPv4. במשך זמן רב היו בעיות עם מתגים שלא יכלו לחפש מתחת לשתי כותרות IP כדי להגיע ל-TCP או UDP ולמצוא שם src_ports, dst_ports. התברר שה-hash, אם מסתכלים על שתי כותרות ה-IP הראשונות, התברר ככמעט מתוקן. כדי למנוע זאת, כדי שהאיזון של התעבורה המובלעת הזו יפעל בצורה נכונה, הוצע להוסיף hash מהחבילה המובלעת בת 5-טופלים לערך של שדה תווית הזרימה. בערך אותו הדבר נעשה עבור תוכניות אנקפסולציה אחרות, עבור UDP, עבור GRE, באחרון נעשה שימוש בשדה מפתח GRE. כך או אחרת, המטרות כאן ברורות. ולפחות באותה נקודת זמן הם היו שימושיים.

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

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

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

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


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

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


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


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


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


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


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


eBPF בא להציל. בפשטות, מדובר בתוכנות קטנות מסוג C. ניתן להכניס אותן ל-hooks במקומות שונים בביצוע מחסנית הקרנל וערימת ה-TCP, בעזרתן ניתן לשנות מספר רב מאוד של הגדרות. באופן כללי, eBPF היא מגמה ארוכת טווח. במקום לנסר עשרות פרמטרים חדשים של sysctl ולהרחיב את כלי ה-IP, התנועה היא לכיוון eBPF והרחבת הפונקציונליות שלו. עם eBPF, אתה יכול לשנות באופן דינמי את בקרות הגודש והגדרות TCP שונות אחרות.


אבל חשוב לנו שבעזרתו תוכלו לסובב את הערכים של SYN_RTO. ויש דוגמה שפורסמה בפומבי: https://elixir.bootlin.com/linux/latest/source/samples/bpf/tcp_synrto_kern.c. מה עושים כאן? הדוגמה עובדת, אבל כשלעצמה היא מאוד גסה. מניחים כאן שבתוך מרכז הנתונים אנו משווים את 44 הביטים הראשונים, אם הם תואמים, אז נמצא את עצמנו בתוך ה-DC. ובמקרה זה, אנו משנים את הערך של פסק זמן SYN_RTO ל-4ms. את אותה משימה אפשר לעשות הרבה יותר בחן. אבל הדוגמה הפשוטה הזו מראה מה אפשר א); ב) קל יחסית.

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


נניח שיש לך שירות ברשת שחי ב- anycast. לצערי, אין לי זמן לפרט על anycast, אבל זה שירות מבוזר שבו שרתים פיזיים שונים זמינים על אותה כתובת IP. והנה בעיה אפשרית: אירוע ה-RTO יכול להתרחש לא רק כאשר התנועה עוברת במפעל. זה יכול להתרחש גם ברמת מאגר ה-ToR: כאשר מתרחש אירוע קלט, זה יכול להתרחש אפילו על המארח כאשר המארח שופך משהו. כאשר מתרחש אירוע RTO והוא משנה את תווית הזרימה. במקרה זה, התנועה עשויה לעבור למופע כל-קאסט אחר. נניח שזה anycast stateful, הוא מכיל מצב חיבור - זה יכול להיות L3 Balancer או שירות אחר. ואז נוצרת בעיה, כי אחרי ה-RTO, חיבור ה-TCP מגיע לשרת, שלא יודע דבר על חיבור ה-TCP הזה. ואם אין לנו שיתוף מצבים בין שרתי Anycast, אז תעבורה כזו תופסק וחיבור ה-TCP יינתק.


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

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


כשהפעלנו את תווית הזרימה ב-ToR, הכנו את ה-eBPF של הסוכן, שחי כעת על המארחים, החלטנו לא לחכות לכשל הגדול הבא, אלא לבצע פיצוצים מבוקרים. לקחנו את ה-ToR, שיש לו ארבעה קישורים למעלה, ועשינו טיפות על אחד מהם. הם ציינו כלל, הם אמרו - עכשיו אתה מאבד את כל החבילות. כפי שניתן לראות בצד שמאל, יש לנו ניטור לכל מנה, שירד ל-75%, כלומר, 25% מהמנות אבדו. בצד ימין יש גרפים של שירותים החיים מאחורי ה-ToR הזה. למעשה, אלו הם גרפי תנועה של ג'וינטים עם שרתים בתוך המדף. כפי שאתה יכול לראות, הם שקעו אפילו נמוך יותר. מדוע הם שקעו נמוך יותר - לא ב-25%, אלא בחלק מהמקרים פי 3-4? אם חיבור ה-TCP חסר מזל, הוא ממשיך לנסות להגיע דרך הממשק השבור. הדבר מחמיר על ידי ההתנהגות האופיינית של השירות בתוך ה-DC - עבור בקשת משתמש אחת, נוצרות N בקשות לשירותים פנימיים, והתגובה תעבור למשתמש, או כאשר כל מקורות הנתונים יגיבו, או כאשר מופעל פסק זמן בשעה רמת היישום, שעדיין צריך להגדיר. כלומר, הכל מאוד מאוד רע.


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

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

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

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

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

מקור: www.habr.com