לפני שמוסיפים OTV, כתבו את חוזה ה-Ethernet שאתם צריכים

עומס עבודה עובר למרכז נתונים שני ומתחיל לחרוג מהזמן בשירות שהגיב היטב מהראשון. מישהו מציע OTV, מפני שה-Layer 2 VPN הקיים «לא עושה broadcast». המסקנה הזו בדרך כלל מוקדמת. קטגוריית השירות והחוזה הספציפי שקניתם הם שתי שאלות שונות, וחריגת הזמן עדיין לא יוחסה לאף אחת מהן.

התסמין שמתחיל את ההשוואה

כתבו מה האפליקציה באמת צריכה לפני השוואת מוצרים. מספר האתרים, היקף VLAN, למידת כתובות, סבילות ל-flooding והתנהגות הכשל מתארים את הדרישה. «Layer 2» ו-«OTV» מתארים ארכיטקטורות, ואף אחד מהם אינו דרישה בפני עצמו. חמש תכונות בעמוד אחד ישרדו יותר מכל השוואת ספקים.

אחר כך בדקו אם השירות הנוכחי כבר עומד בחמש התכונות האלה. Layer 2 VPN המנוהל על ידי הספק עשוי לכלול העברת multipoint ולמידה במישור הבקרה שמבט מהיר בחשבונית לא הזכיר.

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

מה שהתווית לא מספרת לכם

Layer 2 VPN הוא קטגוריה, לא מוצר. VPWS מנקודה לנקודה ו-VPLS multipoint מעבירים אחרת, והקטגוריה כוללת שירותים עם למידה במישור הבקרה וניהול לולאות וגם פשוטים יותר. ההנחה שכל Layer 2 VPN מחבר בדיוק שני אתרים ומציף הכול היא הדרך לעשות את ההשוואה השגויה. השם על החוזה לא אומר דבר על טבלת ההעברה שמאחוריו.

שאלו איזה מודל העברה השירות הקיים מיישם, ואיזה האפליקציה צריכה. דרישת hub-and-spoke ודרישת full-mesh מייצרות עיצובים שונים גם כששתיהן מתוארות כ-Layer 2.

איפה OTV משרטט את הגבול שלו

OTV פועל על תעבורת IP עם נגישות MAC במישור הבקרה ותפקידי edge מוגדרים. מידע spanning-tree מקומי נשאר מקומי במקום להיות מורחב כדומיין אחד לא נשלט על פני התעבורה. זהו הבדל אמיתי מהרחבה מגושרת פשוטה, וזו הסיבה שאנשים פונים אליו.

הגבול חשוב כמו התועלת. הטיפול ב-unicast, broadcast ו-multicast לא ידועים תלוי בפלטפורמה ובתצורתה, וזוג edge חייב לשתף פעולה דרך מנגנון ה-multihoming הנתמך. שני התקנים עצמאיים שמעבירים את אותו VLAN אינם אותו עיצוב, והם מייצרים מצב כשל אחר.

Flooding מצטמצם, לא מוסר

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

לכן השאלה אינה אם OTV עוצר סערות broadcast. השאלה היא אילו מחלקות תעבורה חוצות, באילו תנאים, ומה מגביל את הקצב כשהן חוצות.

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

החוזה שיש לדרוש, בכתב

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

בחרו שינוי רק עבור דרישה שהשירות הנוכחי מוכח שאינו יכול למלא. הרחבת VLAN הלאה מרחיבה גם את התלויות של האפליקציה ושל Ethernet יחד איתה; שם overlay חדש לא מסיר אותן.

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