הגדרת Bonding/Teaming של ממשקי רשת לעמידות בתקלות

Bonding ב-Linux: היכן כשל של קישור אחד מפיל שירות

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

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

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

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

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

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

עמידות הקישור לתקלות: מה משתנה לאחר התצורה

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

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

באגרגט LACP ההשפעה שונה: הזרם מחולק לפי מדיניות hash, ורוחב הפס הכולל של הערוץ גדל יחד עם מספר הקישורים החיים. פיזור התעבורה מותאם לפרופיל העומס — layer3+4 כאשר יש יישומים רבים ואלפי סשנים, או layer2 כאשר התעבורה עוברת בין זוגות כתובות.

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

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

גם את הגבולות צריך לזכור: שני קישורים באותו מתג לא מצילים מכשל של המתג עצמו, ולכן בפרודקשן מפצלים את האגרגט בין שני התקנים (MLAG/vPC). התנהגות המצבים והמגבלות שלהם מתוארות בפירוט ב-תיעוד ליבת Linux בנושא bonding — עליו אנו נשענים בבחירת הסכימה.

מצבי bonding ב-Linux: מה לבחור למשימה

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

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

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

סדר היישום: מביקורת טופולוגיה ועד מסירה

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

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

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

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

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

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

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

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

תצורות, סכימות ונהלים: מה מוסרים ללקוח

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

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

כל מסמך מקושר לסכימה אמיתית, ולא נכתב "לפי תבנית": משמרת התורן יכולה לפעול לפיו בלי להתקשר אלינו.

מקרה בוחן: כיצד הסרנו ניתוקי תקשורת בשני צמתי גישה

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

לפני יישום הגיבוי

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

מה שינינו ומה קיבלנו

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

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

ספקות טכניים לפני הגדרת אגרגציה

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

האם נצטרך לעצור את השירות בזמן המעבר?

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

מה יקרה אם המתג לא תומך ב-LACP?

חלק מהקישורים לא יעלו, והנותרים יתחילו להפיל חבילות או ייצרו מפולת כתובות MAC בטבלת המתג. לכן לפני השינויים משווים את מצבי הפורטים: LACP משני הצדדים, אותם VLAN, מהירות ודופלקס מתואמים בכל המשתתפים. אם אגרגציה במתג אינה זמינה, נשאר active-backup — עמידות לתקלות בלי שינויים בהגדרות שלו.

במה אגרגציית ערוצים שונה מגיבוי נתיב?

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

ההבדל מתגלה בהשלכות הטעות. אגרגציה דורשת מצב מתואם משני צדי הערוץ: בהסכמה דינמית (LACP) השרת והמתג מתאמים את ההרכב, ומצב active-backup מסתדר בלי הגדרת מתג ואף שורד את אתחולו.

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

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

נדון בסכימת הגיבוי שלכם ונחזור עם תוכנית

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

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

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

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