בונד גיבוי-פעיל של Linux על EVPN פעיל-מלא: מה נשבר

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

מה גיבוי-פעיל עושה לפריים נכנס

מצב bonding 1 מחזיק בדיוק עבד אחד בנתיב השידור ומחליף אותו רק כשהנוכחי נכשל. החלק הזה מוכר היטב. מה שחשוב כאן הוא צד הקבלה: הקרנל מוסר פריים למחסנית רק אם הוא מגיע בעבד הפעיל, וזורק פריימים שמופיעים בעבד אחר. הגדרה all_slaves_active זו קיימת בדיוק כדי לרכך את הכלל הזה, והיא כבויה כברירת מחדל. ip -d link show bond0 מדפיס את הערך הנוכחי לצד המצב.

/proc/net/bonding/bond0 מציין את העבד הפעיל ומדווח על מצב הקישור של כל עבד. הקובץ הזה הוא המקור היחיד והאמין לשאלה איזה פורט נושא תעבורה כרגע.

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

מה multihoming פעיל-מלא עושה לקפיצה הבאה המרוחקת

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

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

איפה שתי הבחירות חלוקות

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

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

למה כבל הגיבוי ממשיך להיראות בריא

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

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

בדקו מסירה בשני הכיוונים, לא מצב קישור

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

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

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