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

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

אבל בואו נסתכל על זה מזווית אחרת.

שירותים רבים משתמשים באותה רשת במשך זמן רב. במקרה של מפעיל טלקום, מדובר ב-2G, 3G, LTE, פס רחב ו-B2B, למשל. במקרה של DC: קישוריות עבור לקוחות שונים, אינטרנט, אחסון בלוק, אחסון אובייקטים.

וכל השירותים דורשים בידוד אחד מהשני. כך הופיעו רשתות שכבת-על.

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

הגישה הראשונה לאוטומציה שיטתית של הרשת, או ליתר דיוק חלק ממנה, ננקטה ומיושמה זה מכבר במקומות רבים: VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.

בזה נעסוק היום.

תוכן

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

• שאלות נפוצות
• מסקנה
• קישורים שימושיים

סיבות

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

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

כדי לא לחכות לאנשי רשת שיכניסו רשתות VLAN ולא לרשום שירותים בכל צומת רשת, אנשים העלו את הרעיון של שימוש בשכבות-על - רשתות-על - שיש מגוון גדול מהן: GRE, IPinIP, MPLS, MPLS L2/L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE וכו'.

הערעור שלהם טמון בשני דברים פשוטים:

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

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

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

ציוד זה מפעיל מכונות וירטואליות/מכולות/ללא שרתים שמיישמים שירותים.

טרמינולוגיה

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

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

מכונה פיזית - מחשב x86 מותקן במדף. המונח הנפוץ ביותר מארח. זה מה שנקרא לזה"מכונה"או מארח.

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

מכונה וירטואלית - מערכת הפעלה הפועלת על מכונה פיזית על גבי היפרוויזר. עבורנו במחזור הזה, זה לא ממש משנה אם זו בעצם מכונה וירטואלית או רק קונטיינר. בואו נקרא לזה"ВМ«

שׂוֹכֵר הוא מושג רחב שאגדיר במאמר זה כשירות נפרד או כלקוח נפרד.

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

ToR - מתג החלק העליון של ה-Rack - מתג המותקן במדף אליו מחוברים כל המכונות הפיזיות.

בנוסף לטופולוגיית ה-ToR, ספקים שונים מתרגלים את End of Row (EoR) או Middle of Row (למרות שהאחרון הוא דבר נדיר ומזלזל ולא ראיתי את קיצור ה-MoR).

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

רשת שכבת-על או רשת שכבת-על או שכבת-על - רשת וירטואלית של מנהרות הפועלות על גבי זו הפיזית.

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

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

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

VNF - פונקציית רשת וירטואלית. מכשיר וירטואלי ספציפי: נתב, מתג, חומת אש, NAT, IPS/IDS וכו'.

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

את רוב הרשתות כיום ניתן לחלק בבירור לשני חלקים:

תחתון - רשת פיזית עם תצורה יציבה.
כיסוי - הפשטה על תחתית לבידוד דיירים.

זה נכון גם למקרה של DC (שאותו ננתח במאמר זה) וגם לגבי ISP (שלא ננתח, כי זה כבר היה SDSM). עם רשתות ארגוניות, כמובן, המצב שונה במקצת.

תמונה עם דגש על הרשת:

תחתון

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

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

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

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

• IPv4+OSPF
• IPv6+ISIS+BGP+L3VPN
• L2+TRILL
• L2+STP

רשת ה- Underlay מוגדרת בצורה הקלאסית: CLI/GUI/NETCONF.

באופן ידני, סקריפטים, כלי עזר קנייניים.

המאמר הבא בסדרה יוקדש לבסיס ביתר פירוט.

כיסוי

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

נתוני הלקוח מובלעים בחלק מכותרות המנהור לשידור דרך הרשת הציבורית.

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

שכבת-על יכולה להיות, למשל, כמו שציינתי למעלה:

• מנהרת GRE
• VXLAN
• EVPN
• L3VPN
• ז'נבה

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

כן, זהו SDN בצורתו הטהורה ביותר.

ישנן שתי גישות שונות באופן מהותי לארגון רשת שכבת-על:

1. שכבת-על עם ToR
2. שכבת-על מהמארח

שכבת-על עם ToR

שכבת על יכולה להתחיל במתג הגישה (ToR) העומד במדף, כפי שקורה, למשל, במקרה של בד VXLAN.

זהו מנגנון שנבדק בזמן ברשתות ISP וכל ספקי ציוד הרשת תומכים בו.

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

כאן אפנה את הקורא למאמר בנושא VxLAN על Habré החבר הוותיק שלנו @bormoglotx.
בזה מצגות עם ENOG גישות לבניית רשת DC עם מארג EVPN VXLAN מתוארות בפירוט.

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

אני מציין ש-VXLAN היא רק שיטת אנקפסולציה וסיום מנהרות יכול להתרחש לא ב-ToR, אלא במארח, כפי שקורה במקרה של OpenStack, למשל.

עם זאת, מארג VXLAN, שבו שכבת-העל מתחילה ב-ToR, הוא אחד מתכנוני רשת-העל המבוססים.

שכבת-על מהמארח

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

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

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

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

בסדרת ה-ADSM אני בוחר בגישת ה-overlay מהמארח - ואז מדברים רק על זה ולא נחזור למפעל VXLAN.

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

בסוף המאמר אתן כמה מחשבות על האנלוגיה עם OpenFlow ו-OpenvSwitch.

שימוש בבד טונגסטן כדוגמה

לכל מכונה פיזית יש vRouter - נתב וירטואלי שיודע על הרשתות המחוברות אליו ולאילו לקוחות הם שייכים - בעצם נתב PE. עבור כל לקוח, הוא שומר על טבלת ניתוב מבודדת (קרא VRF). ו-vRouter למעשה עושה מנהור Overlay.

קצת יותר על vRouter נמצא בסוף המאמר.

כל VM שנמצא ב-hypervisor מחובר ל-vRouter של מחשב זה באמצעות ממשק TAP.

TAP - Terminal Access Point - ממשק וירטואלי בקרנל הלינוקס המאפשר אינטראקציה ברשת.

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

כדי ש-vRouters יוכלו לתקשר זה עם זה, ובהתאם ה-VMs הממוקמים מאחוריהם, הם מחליפים מידע ניתוב באמצעות בקר SDN.

כדי לצאת אל העולם החיצון, ישנה נקודת יציאה מהמטריצה ​​- שער רשת וירטואלי VNGW - שער רשת וירטואלית (הקדנציה שלי).

עכשיו בואו נסתכל על דוגמאות לתקשורת - ותהיה בהירות.

תקשורת בתוך מכונה פיזית אחת

VM0 רוצה לשלוח חבילה ל-VM2. הבה נניח לעת עתה שמדובר ב-VM של לקוח יחיד.

מטוס נתונים

1. ל-VM-0 יש מסלול ברירת מחדל לממשק ה-eth0 שלו. החבילה נשלחת לשם.
   ממשק זה eth0 מחובר למעשה לנתב הוירטואלי vRouter דרך ממשק TAP tap0.
2. vRouter מנתח לאיזה ממשק החבילה הגיעה, כלומר לאיזה לקוח (VRF) היא שייכת, ובודק את כתובת הנמען עם טבלת הניתוב של הלקוח הזה.
3. לאחר שזיהה שהנמען באותו מחשב נמצא ביציאה אחרת, vRouter פשוט שולח אליו את החבילה ללא כותרות נוספות - במקרה זה, ל-vRouter כבר יש רשומת ARP.

במקרה זה, החבילה לא נכנסת לרשת הפיזית - היא מנותבת בתוך ה-vRouter.

מטוס בקרה

כשהמכונה הוירטואלית מתחילה, ההיפרוויזר אומר לה:

• כתובת ה-IP שלה.
• מסלול ברירת המחדל הוא דרך כתובת ה-IP של ה-vRouter ברשת זו.

ה-Hypervisor מדווח ל-vRouter באמצעות API מיוחד:

• מה אתה צריך כדי ליצור ממשק וירטואלי.
• איזה סוג של רשת וירטואלית היא (VM) צריכה ליצור?
• לאיזה VRF (VN) לאגד אותו.
• ערך ARP סטטי עבור VM זה - איזה ממשק עומד מאחורי כתובת ה-IP שלו ולאיזו כתובת MAC הוא משויך.

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

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

אבל VM0 ו-VM1 שייכים ללקוחות שונים, ובהתאם לכך, נמצאים בטבלאות vRouter שונות.

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

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

תקשורת בין מחשבי VM הממוקמים במכונות פיזיות שונות

מטוס נתונים

1. ההתחלה זהה לחלוטין: VM-0 שולח חבילה עם היעד VM-7 (172.17.3.2) כברירת מחדל.
2. vRouter מקבל את זה והפעם רואה שהיעד נמצא במחשב אחר ונגיש דרך Tunnel0.
3. ראשית, הוא תולה תווית MPLS המזהה את הממשק המרוחק, כך שבצד ההפוך vRouter יכול לקבוע היכן למקם את החבילה הזו ללא חיפושים נוספים.

   

4. ל-Tunnel0 יש מקור 10.0.0.2, יעד: 10.0.1.2.
   vRouter מוסיף כותרות GRE (או UDP) ו-IP חדש לחבילה המקורית.
5. לטבלת הניתוב vRouter יש מסלול ברירת מחדל דרך כתובת ToR1 10.0.0.1. לשם הוא שולח את זה.

   
   

6. ToR1, כחבר ברשת Underlay, יודע (למשל, דרך OSPF) איך להגיע ל-10.0.1.2 ושולח את החבילה לאורך המסלול. שימו לב ש-ECMP מופעל כאן. יש שני Nexthops באיור, ושרשורים שונים ימוינו לתוכם לפי hash. במקרה של מפעל אמיתי, סביר להניח שיהיו 4 Nexthops.

   יחד עם זאת, הוא לא צריך לדעת מה נמצא מתחת לכותרת ה-IP החיצונית. כלומר, למעשה, תחת IP יכול להיות כריך של IPv6 על MPLS על Ethernet על פני MPLS על פני GRE על פני יוונית.

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

מטוס בקרה

כאשר אתה מתניע את המכונית, אותו דבר קורה כמתואר לעיל.

ובנוסף את הדברים הבאים:

• עבור כל לקוח, vRouter מקצה תג MPLS. זוהי תווית השירות L3VPN, שבאמצעותה יופרדו לקוחות בתוך אותה מחשב פיזי.
  

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

• vRouter יוצר חיבור עם בקר SDN באמצעות פרוטוקול BGP (או דומה לו - במקרה של TF, זהו XMPP 0_o).
• באמצעות הפעלה זו, vRouter מדווח על מסלולים לרשתות מחוברות לבקר SDN:
  • כתובת רשת
  • שיטת אנקפסולציה (MPLSoGRE, MPLSoUDP, VXLAN)
  • תג לקוח MPLS
  • כתובת ה-IP שלך בתור nexthop

• בקר ה-SDN מקבל מסלולים כאלה מכל ה-vRouters המחוברים ומשקף אותם לאחרים. כלומר, הוא פועל כמשקף מסלול.

אותו דבר קורה בכיוון ההפוך.

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

הבקר המרכזי דואג לכל המורכבות של תחזוקת התצורה וניטור טבלאות המיתוג/ניתוב ב-vRouter.

באופן גס, הבקר מתקשר עם כל ה-vRouters באמצעות BGP (או פרוטוקול דומה) ופשוט משדר מידע ניתוב. ל-BGP, למשל, כבר יש את Address-Family כדי להעביר את שיטת האנקפסולציה MPLS-in-GRE או MPLS-in-UDP.

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

יציאה לעולם החיצון

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

נהוגות שתי גישות:

1. נתב חומרה מותקן.
2. מושק מכשיר שמיישם את הפונקציות של נתב (כן, בעקבות SDN, נתקלנו גם ב-VNF). בואו נקרא לזה שער וירטואלי.

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

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

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

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

מטוס נתונים

כלומר, התהליך נראה כך:

1. VM-0, לאחר שהגדר כברירת מחדל לאותו vRouter, שולח חבילה עם יעד בעולם החיצון (185.147.83.177) לממשק eth0.
2. vRouter מקבל חבילה זו ומחפש את כתובת היעד בטבלת הניתוב - מוצא את מסלול ברירת המחדל דרך שער VNGW1 דרך מנהרה 1.
   הוא גם רואה שמדובר במנהרת GRE עם SIP 10.0.0.2 ו-DIP 10.0.255.2, והוא גם צריך לצרף תחילה את תווית MPLS של הלקוח הזה, לה מצפה VNGW1.
3. vRouter אורז את החבילה הראשונית עם MPLS, GRE וכותרות IP חדשות ושולח אותה לכתובת ToR1 10.0.0.1 כברירת מחדל.
4. הרשת הבסיסית מספקת את החבילה לשער VNGW1.
5. השער VNGW1 מסיר את כותרות המנהור GRE ו-MPLS, רואה את כתובת היעד, מתייעץ בטבלת הניתוב שלו ומבין שהיא מופנית לאינטרנט - כלומר דרך Full View או Default. במידת הצורך, מבצע תרגום NAT.
6. יכולה להיות רשת IP רגילה מ-VNGW לגבול, וזה לא סביר.
   יכול להיות שיש רשת MPLS קלאסית (IGP+LDP/RSVP TE), יכול להיות שיש בד אחורי עם BGP LU או מנהרה GRE מ-VNGW לגבול דרך רשת IP.
   כך או כך, VNGW1 מבצע את האנקפסולציות הדרושות ושולח את החבילה הראשונית לכיוון הגבול.

התנועה בכיוון ההפוך עוברת את אותם שלבים בסדר הפוך.

1. הגבול מפיל את החבילה ל-VNGW1
2. הוא מפשיט אותו, מסתכל על הכתובת של הנמען ורואה שהוא נגיש דרך מנהרת Tunnel1 (MPLSoGRE או MPLSoUDP).
3. בהתאם, הוא מצרף תווית MPLS, כותרת GRE/UDP ו-IP חדש ושולח אותו ל-ToR3 10.0.255.1 שלו.
   כתובת יעד המנהרה היא כתובת ה-IP של ה-vRouter שמאחוריו נמצא ה-VM היעד - 10.0.0.2.
4. הרשת הבסיסית מספקת את החבילה ל-vRouter הרצוי.
5. ה-vRouter של היעד קורא GRE/UDP, מזהה את הממשק באמצעות תווית MPLS ושולח חבילת IP חשופה לממשק ה-TAP שלו המשויך ל-eth0 של ה-VM.

מטוס בקרה

VNGW1 מקים שכונת BGP עם בקר SDN, שממנו הוא מקבל את כל מידע הניתוב על לקוחות: איזו כתובת IP (vRouter) עומדת מאחורי איזה לקוח, ואיזו תווית MPLS היא מזוהה.

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

ב-VNGW, בדרך כלל מתרחש צבירת מסלול או תרגום NAT.

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

מבחינת אנקפסולציה וחילופי תעבורה, VNGW אינו שונה מ-vRouter.
אם תרחיב מעט את ההיקף, אז תוכל להוסיף התקני רשת אחרים ל-VNGWs ו-vRouters, כגון חומות אש, חוות ניקוי תנועה או העשרה, IPS וכו'.

ובעזרת יצירה רציפה של VRFs והכרזה נכונה על מסלולים, אתה יכול לאלץ את התעבורה לעבור לולאה כמו שאתה רוצה, מה שנקרא Service Chaining.

כלומר, גם כאן בקר ה-SDN פועל כ-Route-Reflector בין VNGWs, vRouters והתקני רשת אחרים.

אבל למעשה, הבקר גם מדליף מידע על ACL ו-PBR (ניתוב מבוסס מדיניות), מה שגורם לזרימות תנועה בודדות להתנהל בצורה שונה ממה שהמסלול אומר להם.

שאלות נפוצות

למה אתה תמיד אומר את הערת GRE/UDP?

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

אבל אם ניקח את זה, אז TF עצמו, למרות שעדיין OpenContrail, תמך בשתי האנקפסולציות: MPLS ב-GRE ו-MPLS ב-UDP.

UDP טוב כי ב-Source Port קל מאוד לקודד פונקציית hash מה-IP+Proto+Port המקורי בכותרת שלו, מה שיאפשר לכם לבצע איזון.

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

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

למען ההגינות, ראוי לציין ש-TF תומך באופן מלא בקישוריות L2 באמצעות VXLAN.

הבטחת לצייר הקבלות עם OpenFlow.
הם באמת מבקשים את זה. vSwitch באותו OpenStack עושה דברים מאוד דומים, באמצעות VXLAN, שאגב, יש לו גם כותרת UDP.

במישור הנתונים הם עובדים בערך אותו הדבר; מישור הבקרה שונה באופן משמעותי. Tungsten Fabric משתמש ב-XMPP כדי לספק מידע ניתוב ל-vRouter, בעוד ש-OpenStack מריץ את Openflow.

אתה יכול לספר לי קצת יותר על vRouter?
הוא מחולק לשני חלקים: vRouter Agent ו-vRouter Forwarder.

הראשון פועל במרחב המשתמש של מערכת ההפעלה המארח ומתקשר עם בקר ה-SDN, מחליף מידע על מסלולים, VRF ו-ACL.

השני מיישם את Data Plane - בדרך כלל ב-Kernel Space, אבל יכול לרוץ גם על SmartNICs - כרטיסי רשת עם מעבד ושבב מיתוג נפרד הניתן לתכנות, המאפשר להסיר את העומס מהמעבד של המכונה המארח, ולהפוך את הרשת למהירה יותר ויותר. צָפוּי.

תרחיש אפשרי נוסף הוא ש-vRouter הוא יישום DPDK במרחב המשתמש.

vRouter Agent שולח הגדרות ל-vRouter Forwarder.

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

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

לפיכך, ככזו, אין התכתבות ישירה בין הרשת הוירטואלית לבין השוכר.

מסקנה

זהו תיאור שטחי מאוד של הפעולה של רשת וירטואלית עם שכבת-על מהמארח ובקר SDN. אבל לא משנה באיזו פלטפורמת וירטואליזציה תבחר היום, היא תעבוד בצורה דומה, בין אם זה VMWare, ACI, OpenStack, CloudStack, Tungsten Fabric או Juniper Contrail. הם יהיו שונים בסוגי אנקפסולציות וכותרות, פרוטוקולים לאספקת מידע למכשירי קצה ברשת, אך העיקרון של רשת שכבת-על הניתנת להגדרת תוכנה הפועלת על גבי רשת תחתית פשוטה וסטטית יחסית, יישאר זהה.
ניתן לומר שכיום SDN המבוסס על רשת על ניצחה בתחום יצירת ענן פרטי. עם זאת, זה לא אומר של-Openflow אין מקום בעולם המודרני – הוא נמצא בשימוש ב-OpenStacke ובאותה VMWare NSX, עד כמה שידוע לי גוגל משתמשת בו כדי להקים את הרשת המחתרתית.

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

ומה עם התחתית שלנו?

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

בואו נגבש רשימה של דרישות לרשת ה- Underlay.

1. להיות מסוגל להשתמש בסוג של פרוטוקול ניתוב, במצבנו - BGP.
2. יש רוחב פס רחב, רצוי ללא מנוי יתר, כדי שהמנות לא יאבדו עקב עומס יתר.
3. תמיכה ב-ECMP היא חלק בלתי נפרד מהבד.
4. להיות מסוגל לספק QoS, כולל דברים מסובכים כמו ECN.
5. תמיכה ב-NETCONF היא בסיס לעתיד.

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

ברור, אני מגביל את כולנו באופן חמור על ידי שימוש כדוגמה ברשת DC שנבנתה במפעל Clos עם ניתוב IP טהור ושכבת-על מהמארח.

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

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

קישורים שימושיים

• ארכיטקטורת בד טונגסטן.
• about:cloud. 6 שעות על Yandex.Cloud, המכסה גם את הרשת הוירטואלית ב-TF.
• מה זה Open vSwitch?
• מבוא ל-VxLAN.
• RFC 7348. Virtual eXtensible Local Area Network (VXLAN): מסגרת לשכבת-על של רשתות וירטואליות שכבה 2 על גבי רשתות שכבה 3.
  
• גישת Scaleway ל-VXLAN EVPN Fabric. הוא מדבר על רשת DC כולה, כולל Underlay, Overlay, גישות לריבוי בום וניהול.

תודה

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

מקור: www.habr.com