הגדרת VLAN בשרתים לפילוח רשת

הגדרת VLAN ב-Linux: היכן נשברת הסגמנטציה

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

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

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

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

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

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

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

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

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

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

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

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

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

מצבי VLAN: פורטי גישה, trunk וניתוב

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

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

אפשרויות ארגון

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

איך מתבצעת הטמעת הסגמנטציה: שלבי העבודה

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

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

סדר העבודה נראה כך:

1. מיפוי הרשת. אוספים מלאי של מתגים, היפרוויזורים, ממשקים פיזיים ורשתות המשנה הקיימות. בנפרד מתעדים מפת קשרים בין השירותים לצרכנים חיצוניים — היא תשמש בסיס לכללים.
2. תרשים מיעון. מקצים לכל סגמנט רשת משנה משלו, שמות ממשקים וניתוב ביניהם. כאן גם מחליטים אילו שירותים נשארים בסגמנט המשותף ומדוע.
3. תכנון תרשים ה-VLAN. מסמנים פורטים לתעבורה מתויגת ולא מתויגת, ומתאמים את הסימון עם הווירטואליזציה, כדי שהכללים יעבדו באותה צורה גם על צמתים פיזיים וגם על וירטואליים.
4. הרכבה במתחם בדיקות. מעבירים קבוצת שירותים אחת, בודקים את הניתוב ואת ההתנהגות בעת כשל של סגמנט נפרד.
5. בדיקת הבידוד. סורקים מכל סגמנט: קשרים אסורים לא עוברים, מותרים מגיבים. מתעדים את התוצאה כתקן לפני העברת שירותי הפרודקשן.
6. העברה מדורגת. מעבירים את שירותי העבודה בקבוצות, עם חלונות תחזוקה ותוכנית חזרה לאחור בכל שלב.
7. מסירה לתפעול. מוסרים את תרשים המיעון, הקונפיגורציות, נוהל חיבור צמתים חדשים והוראות שחזור — כדי שהשינויים בהמשך יבוצעו על ידי הצוות שלכם.

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

תרשימי מיעון, קונפיגורציות ונהלי גישה

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

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

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

מקרה בוחן: חלוקת צי השרתים בלי לעצור שירותים

לפני: רשת שטוחה אחת לכל הצי

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

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

מה שינינו

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

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

אחרי: נתונים

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

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

במה שונה תיוג מהפרדה פיזית של רשתות?

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

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

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

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

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

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

חששות לגבי תאימות, לולאות וחזרה לאחור של שינויים

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

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

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

איך אתם מתגוננים מלולאות רשת?

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

אפשר להחזיר את התרשים הקודם אם משהו ישתבש?

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

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

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

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

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

תארו את המשימה בצורה חופשית — נחזור עם הערכה ותוכנית.