В նախորդ թողարկում Ես նկարագրեցի ցանցի ավտոմատացման շրջանակը: Որոշ մարդկանց կարծիքով՝ խնդրին նույնիսկ այս առաջին մոտեցումն արդեն որոշ հարցեր է հարթել։ Եվ սա ինձ շատ ուրախացնում է, քանի որ մեր նպատակը ցիկլի մեջ ոչ թե Ansible-ը Python սկրիպտներով ծածկելն է, այլ համակարգ կառուցելը։

Նույն շրջանակը սահմանում է այն հաջորդականությունը, որով մենք կզբաղվենք հարցին:
И виртуализация сети, которой посвящён этот выпуск, не особо укладывается в тематику АДСМ, где мы разбираем автоматику.

Но давайте взглянем на неё под другим углом.

Շատ ծառայություններ երկար ժամանակ օգտվում են նույն ցանցից։ Հեռահաղորդակցության օպերատորի դեպքում սա, օրինակ, 2G, 3G, LTE, լայնաշերտ և B2B է: DC-ի դեպքում՝ միացում տարբեր հաճախորդների համար, ինտերնետ, բլոկների պահեստավորում, օբյեկտների պահեստավորում:

Իսկ բոլոր ծառայությունները պահանջում են մեկուսացում միմյանցից։ Այսպես հայտնվեցին ծածկույթի ցանցերը։

Եվ բոլոր ծառայությունները չեն ցանկանում սպասել, որ մարդը ձեռքով կարգավորի դրանք: Այսպես հայտնվեցին նվագախմբերն ու SDN-ն։

Ցանցի, ավելի ճիշտ՝ դրա մի մասի համակարգված ավտոմատացման առաջին մոտեցումը վաղուց ընդունվել և ներդրվել է շատ վայրերում՝ VMWare, OpenStack, Google Compute Cloud, AWS, Facebook:

Դա այն է, ինչի հետ մենք այսօր կզբաղվենք:

Պարունակություն

• պատճառները
• Տերմինոլոգիա
• Underlay - ֆիզիկական ցանց
• Overlay - վիրտուալ ցանց
  • Overlay с ToR’a
  • Ծածկույթ հյուրընկալողից
  • Օգտագործելով վոլֆրամի գործվածքը որպես օրինակ
    • Հաղորդակցություն մեկ ֆիզիկական մեքենայի ներսում
    • Տարբեր ֆիզիկական մեքենաների վրա տեղակայված VM-ների միջև հաղորդակցություն
    • Ելք դեպի արտաքին աշխարհ

• FAQ
• Ամփոփում
• Օգտակար հղումներ

պատճառները

Եվ քանի որ մենք խոսում ենք այս մասին, հարկ է նշել ցանցի վիրտուալացման նախադրյալները: Փաստորեն, այս գործընթացը երեկ չի սկսվել։

Դուք հավանաբար մեկ անգամ չէ, որ լսել եք, որ ցանցը միշտ եղել է ցանկացած համակարգի ամենաիներտ մասը: Եվ սա ճիշտ է բոլոր իմաստներով։ Ցանցը այն հիմքն է, որի վրա ամեն ինչ հենվում է, և դրա վրա փոփոխություններ կատարելը բավականին դժվար է. ծառայությունները չեն հանդուրժում այն, երբ ցանցը անջատված է: Հաճախ մեկ հանգույցի շահագործումից հանելը կարող է հեռացնել հավելվածների մեծ մասը և ազդել բազմաթիվ հաճախորդների վրա: Մասամբ սա է պատճառը, որ ցանցի թիմը կարող է դիմակայել ցանկացած փոփոխության, քանի որ այժմ այն ​​ինչ-որ կերպ աշխատում է (մենք կարող ենք նույնիսկ չգիտենք, թե ինչպես), բայց այստեղ պետք է նոր բան կարգավորել, և հայտնի չէ, թե ինչպես դա կազդի ցանցի վրա։

Որպեսզի չսպասենք, որ ցանցային ցանցերը տեղադրեն VLAN-ներ և չգրանցեն որևէ ծառայություն ցանցի յուրաքանչյուր հանգույցում, մարդկանց մոտ միտք առաջացավ օգտագործել ծածկույթներ՝ ծածկող ցանցեր, որոնցից մեծ բազմազանություն կա՝ GRE, IPinIP, MPLS, MPLS L2/L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE և այլն:

Նրանց գրավչությունը երկու պարզ բանի մեջ է.

• Կազմաձևված են միայն վերջի հանգույցները. անհրաժեշտ չէ դիպչել տարանցիկ հանգույցներին: Սա զգալիորեն արագացնում է գործընթացը և երբեմն թույլ է տալիս ամբողջովին բացառել ցանցային ենթակառուցվածքի բաժինը նոր ծառայությունների ներդրման գործընթացից:
• Բեռը թաքնված է վերնագրերի խորքում. տարանցիկ հանգույցները կարիք չունեն դրա մասին որևէ բան իմանալու, հոսթինգների հասցեների կամ ծածկույթի ցանցի երթուղիների մասին: Սա նշանակում է, որ դուք պետք է ավելի քիչ տեղեկատվություն պահեք աղյուսակներում, ինչը նշանակում է օգտագործել ավելի պարզ/էժան սարք:

Այս ոչ ամբողջությամբ լիարժեք հարցում ես չեմ նախատեսում վերլուծել բոլոր հնարավոր տեխնոլոգիաները, այլ ավելի շուտ նկարագրել DC-ներում ծածկող ցանցերի շահագործման շրջանակը:

Ամբողջ շարքը նկարագրելու է տվյալների կենտրոնը, որը բաղկացած է միանման դարակաշարերի շարքերից, որոնցում տեղադրված է նույն սերվերի սարքավորումը:

Այս սարքավորումն աշխատում է վիրտուալ մեքենաներով/կոնտեյներներով/առանց սերվերով, որոնք իրականացնում են ծառայություններ:

Տերմինոլոգիա

В цикле սերվեր Ես կնշեմ մի ծրագիր, որն իրականացնում է հաճախորդ-սերվեր հաղորդակցության սերվերային կողմը:

Դարակաշարերում գտնվող ֆիզիկական մեքենաները կոչվում են սերվերներ ոչ մենք կանենք.

Ֆիզիկական մեքենա — x86 համակարգիչ՝ տեղադրված դարակում։ Ամենահաճախ օգտագործվող տերմինը հյուրընկալող. մենք դա կանվանենք»ավտոմեքենա" կամ հյուրընկալող.

Հիպերվիզոր — приложение, запущенное на физической машине, эмулирующее физические ресурсы, на которых запускаются Виртуальные Машины. Иногда в литературе и сети слово «гипервизор» используют как синоним «хост».

Վիրտուալ մեքենա - օպերացիոն համակարգ, որն աշխատում է հիպերվիզորի վերևում գտնվող ֆիզիկական մեքենայի վրա: Մեզ համար այս ցիկլում իրականում նշանակություն չունի՝ դա իրականում վիրտուալ մեքենա է, թե պարզապես կոնտեյներ: Եկեք այն անվանենք»Վ.Մ.«

Վարձակալ լայն հասկացություն է, որը ես կսահմանեմ այս հոդվածում որպես առանձին ծառայություն կամ առանձին հաճախորդ:

Բազմավարձակալություն կամ բազմավարձակալություն՝ նույն հավելվածի օգտագործումը տարբեր հաճախորդների/ծառայությունների կողմից: Միևնույն ժամանակ, հաճախորդների մեկուսացումը միմյանցից ձեռք է բերվում հավելվածի ճարտարապետության շնորհիվ, այլ ոչ թե առանձին գործարկվող օրինակների միջոցով:

ToR - Դարակի անջատիչի վերևում - դարակաշարում տեղադրված անջատիչ, որին միացված են բոլոր ֆիզիկական մեքենաները:

Բացի ToR տոպոլոգիայից, տարբեր պրովայդերներ կիրառում են End of Row (EoR) կամ Middle of Row (չնայած վերջինս արհամարհական հազվադեպություն է, և ես չեմ տեսել MoR հապավումը):

Ներքևի ցանց կամ հիմքում ընկած ցանցը կամ հիմքը ֆիզիկական ցանցի ենթակառուցվածքն է՝ անջատիչներ, երթուղիչներ, մալուխներ:

Overlay ցանց կամ overlay network կամ overlay - թունելների վիրտուալ ցանց, որն անցնում է ֆիզիկականի վերևում:

L3-фабрика или IP-фабрика - մարդկության զարմանալի գյուտ, որը թույլ է տալիս խուսափել STP-ի կրկնությունից և հարցազրույցների համար TRILL սովորելուց: Հայեցակարգ, որտեղ ամբողջ ցանցը մինչև մուտքի մակարդակը բացառապես L3 է, առանց VLAN-ների և, համապատասխանաբար, հսկայական ընդլայնված հեռարձակման տիրույթների: Մենք կնայենք, թե որտեղից է գալիս «գործարան» բառը հաջորդ մասում:

SDN - Ծրագրային ապահովման սահմանած ցանց: Հազիվ թե ներածության կարիք ունենա: Ցանցի կառավարման մոտեցում, որտեղ ցանցում փոփոխությունները կատարվում են ոչ թե անձի, այլ ծրագրի կողմից: Սովորաբար նշանակում է Control Plane-ը վերջնական ցանցային սարքերից այն կողմ տեղափոխել վերահսկիչ:

NFV — Ցանցի գործառույթների վիրտուալացում — ցանցային սարքերի վիրտուալացում, որը ենթադրում է, որ ցանցի որոշ գործառույթներ կարող են գործարկվել վիրտուալ մեքենաների կամ կոնտեյներների տեսքով՝ արագացնելու նոր ծառայությունների իրականացումը, կազմակերպելու Ծառայությունների շղթա և ավելի պարզ հորիզոնական մասշտաբայնություն։

VNF - Վիրտուալ ցանցի գործառույթ: Հատուկ վիրտուալ սարք՝ երթուղիչ, անջատիչ, firewall, NAT, IPS/IDS և այլն:

Ես հիմա միտումնավոր պարզեցնում եմ նկարագրությունը կոնկրետ իրականացման համար, որպեսզի շատ չշփոթեցնեմ ընթերցողին: Ավելի կշռադատված ընթերցանության համար նրան ուղղորդում եմ բաժինը Սայլակ. Բացի այդ, Ռոմայի կիրճը, ով քննադատում է այս հոդվածը անճշտությունների համար, խոստանում է առանձին համար գրել սերվերների և ցանցերի վիրտուալացման տեխնոլոգիաների մասին՝ ավելի խորը և ուշադիր։

Այսօրվա ցանցերի մեծ մասը կարելի է հստակորեն բաժանել երկու մասի.

Ներքնազգեստ — կայուն կոնֆիգուրացիայով ֆիզիկական ցանց:
Կափարիչ — աբստրակցիա Underlay-ի վրա վարձակալներին մեկուսացնելու համար:

Սա ճիշտ է ինչպես DC-ի դեպքում (որը մենք կվերլուծենք այս հոդվածում), այնպես էլ ISP-ի համար (որը մենք չենք վերլուծի, քանի որ դա արդեն եղել է. ՍԴՍՄ) Ձեռնարկությունների ցանցերի դեպքում, իհարկե, իրավիճակը մի փոքր այլ է:

Նկար՝ կենտրոնանալով ցանցի վրա.

Ներքնազգեստ

Underlay-ը ֆիզիկական ցանց է՝ ապարատային անջատիչներ և մալուխներ: Ստորգետնյա սարքերը գիտեն, թե ինչպես հասնել ֆիզիկական մեքենաների:

Այն հիմնված է ստանդարտ արձանագրությունների և տեխնոլոգիաների վրա: Հատկապես այն պատճառով, որ ապարատային սարքերը մինչ օրս գործում են սեփական ծրագրաշարով, որը թույլ չի տալիս ծրագրավորել չիպը կամ իրականացնել իր սեփական արձանագրությունները, համապատասխանաբար, անհրաժեշտ է համատեղելիություն այլ վաճառողների հետ և ստանդարտացում:

Սակայն Google-ի նման մեկը կարող է իրեն թույլ տալ զարգացնել սեփական անջատիչները և հրաժարվել ընդհանուր ընդունված արձանագրություններից: Բայց LAN_DC-ն Google չէ:

Underlay сравнительно редко меняется, потому что его задача — базовая IP-связность между физическими машинами. Underlay ничего не знает о запущенных поверх него сервисах, клиентах, тенантах — ему нужно только доставить пакет от одной машины до другой.
Ներքնաշերտը կարող է լինել այսպիսին.

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

Underlay ցանցը կազմաձևված է դասական եղանակով՝ CLI/GUI/NETCONF:

Ձեռքով, սցենարներ, գույքային կոմունալ ծառայություններ:

Շարքի հաջորդ հոդվածը ավելի մանրամասն կնվիրվի հիմքի վրա:

Կափարիչ

Overlay-ը թունելների վիրտուալ ցանց է, որը ձգվում է Underlay-ի վերևում, այն թույլ է տալիս մեկ հաճախորդի VM-ներին շփվել միմյանց հետ՝ միաժամանակ ապահովելով մեկուսացում մյուս հաճախորդներից:

Հաճախորդի տվյալները փակցված են որոշ թունելային վերնագրերում՝ հանրային ցանցով փոխանցելու համար:

Այսպիսով, մեկ հաճախորդի (մեկ ծառայության) VM-ները կարող են միմյանց հետ շփվել Overlay-ի միջոցով՝ նույնիսկ չիմանալով, թե իրականում ինչ ճանապարհ է անցնում փաթեթը:

Overlay-ը կարող է լինել, օրինակ, ինչպես ես վերը նշեցի.

• GRE թունել
• VXLAN
• EVPN
• L3VPN
• ԺԵՆԵՎ

Overlay’ная сеть обычно настраивается и поддерживается через центральный контроллер. С него конфигурация, Control Plane и Data Plane доставляются на устройства, которые занимаются маршрутизацией и инкапсуляцией клиентского трафика. Чуть Ստորեւ Սրան նայենք օրինակներով։

Да, это SDN в чистом виде.

Overlay ցանցի կազմակերպման երկու սկզբունքորեն տարբեր մոտեցում կա.

1. Overlay с ToR’a
2. Ծածկույթ հյուրընկալողից

Overlay с ToR’a

Overlay-ը կարող է սկսվել դարակում կանգնած մուտքի անջատիչից (ToR), ինչպես դա տեղի է ունենում, օրինակ, VXLAN գործվածքի դեպքում:

Սա ժամանակի փորձարկված մեխանիզմ է ISP ցանցերում, և ցանցային սարքավորումների բոլոր վաճառողները աջակցում են դրան:

Այնուամենայնիվ, այս դեպքում ToR անջատիչը պետք է համապատասխանաբար կարողանա առանձնացնել տարբեր ծառայություններ, և ցանցի ադմինիստրատորը պետք է որոշակի չափով համագործակցի վիրտուալ մեքենայի ադմինիստրատորների հետ և փոփոխություններ կատարի (թեև ավտոմատ կերպով) սարքերի կազմաձևում: .

Այստեղ ես ընթերցողին կուղարկեմ հոդվածի մասին VxLAN Habré-ում մեր հին ընկերը @bormoglotx.
Այսում շնորհանդեսներ ENOG-ի հետ EVPN VXLAN գործվածքով DC ցանց կառուցելու մոտեցումները մանրամասն նկարագրված են:

Իսկ իրականության մեջ ավելի ամբողջական ընկղմվելու համար կարող եք կարդալ Ցիսկայի գիրքը Ժամանակակից, բաց և մասշտաբային գործվածք՝ VXLAN EVPN.

Ես նշում եմ, որ VXLAN-ը միայն ինկապսուլյացիայի մեթոդ է, և թունելների դադարեցումը կարող է տեղի ունենալ ոչ թե ToR-ում, այլ հոսթի վրա, ինչպես, օրինակ, տեղի է ունենում OpenStack-ի դեպքում:

Այնուամենայնիվ, VXLAN գործվածքը, որտեղ ծածկույթը սկսվում է ToR-ից, ծածկույթների ցանցի հաստատված ձևավորումներից մեկն է:

Ծածկույթ հյուրընկալողից

Другой подход — начинать и терминировать туннели на конечных хостах.
Այս դեպքում ցանցը (Underlay) մնում է հնարավորինս պարզ և ստատիկ:
Իսկ հյուրընկալողն ինքն է անում բոլոր անհրաժեշտ ինկապսուլյացիան:

Սա, իհարկե, կպահանջի հոսթերի վրա հատուկ հավելված գործարկել, բայց արժե այն:

Նախ, Linux մեքենայով հաճախորդի գործարկումն ավելի հեշտ է կամ, ասենք, նույնիսկ հնարավոր է, մինչդեռ անջատիչի վրա դուք, ամենայն հավանականությամբ, ստիպված կլինեք դիմել սեփականության SDN լուծումներին, ինչը սպանում է բազմավաճառքի գաղափարը:

Во-вторых, ToR-коммутатор в этом случае можно оставить максимально простым, как с точки зрения Control Plane’а, так и Data Plane’а. Действительно — с SDN-контроллером ему тогда общаться не нужно, и хранить сети/ARP’ы всех подключенных клиентов — тоже — достаточно знать IP-адрес физической машины, что кратно облегчает таблицы коммутации/маршрутизации.

ADSM սերիայում ես ընտրում եմ հաղորդավարից ծածկույթի մոտեցումը, այնուհետև մենք միայն խոսում ենք դրա մասին և չենք վերադառնա VXLAN գործարան:

Օրինակներին նայելն ամենահեշտն է: Եվ որպես թեստային առարկա մենք կվերցնենք OpenSource SDN հարթակը OpenContrail, որն այժմ հայտնի է որպես Վոլֆրամի գործվածք.

Հոդվածի վերջում ես մի քանի մտքեր կտամ OpenFlow-ի և OpenvSwitch-ի անալոգիայի վերաբերյալ:

Օգտագործելով վոլֆրամի գործվածքը որպես օրինակ

На каждой физической машине есть vRouter - վիրտուալ երթուղիչ, որը գիտի իրեն միացված ցանցերի մասին և որ հաճախորդներին են պատկանում, հիմնականում PE երթուղիչ: Յուրաքանչյուր հաճախորդի համար այն պահպանում է մեկուսացված երթուղային աղյուսակ (կարդացեք VRF): Իսկ vRouter-ը իրականում կատարում է Overlay tunneling:

Մի փոքր ավելին vRouter-ի մասին՝ հոդվածի վերջում:

Հիպերվիզորի վրա տեղակայված յուրաքանչյուր VM միացված է այս մեքենայի vRouter-ին TAP ինտերֆեյս.

Թակել — Terminal Access Point — виртуальный интерфейс в ядре linux, которые позволяет осуществлять сетевое взаимодействие.

Եթե ​​vRouter-ի հետևում կան մի քանի ցանցեր, ապա դրանցից յուրաքանչյուրի համար ստեղծվում է վիրտուալ ինտերֆեյս, որին նշանակվում է IP հասցե՝ դա կլինի լռելյայն gateway հասցեն:
Մեկ հաճախորդի բոլոր ցանցերը տեղադրված են մեկում VRF (մեկ սեղան), տարբեր՝ տարբերների մեջ։
Այստեղ ես հրաժարվում եմ պատասխանատվությունից, որ ամեն ինչ այնքան էլ պարզ չէ, և ես հետաքրքրասեր ընթերցողին կուղարկեմ հոդվածի վերջ:.

Որպեսզի vRouters-ները կարողանան շփվել միմյանց հետ, և, համապատասխանաբար, դրանց հետևում տեղակայված VM-ները, նրանք փոխանակում են երթուղային տեղեկատվություն SDN վերահսկիչ.

Чтобы выбраться во внешний мир, существует точка выхода из матрицы — шлюз виртуальной сети VNGW — Վիրտուալ ցանցի դարպաս (իմ ժամկետը).

Теперь рассмотрим примеры коммуникаций — и будет ясность.

Հաղորդակցություն մեկ ֆիզիկական մեքենայի ներսում

VM0-ը ցանկանում է փաթեթ ուղարկել VM2-ին: Առայժմ ենթադրենք, որ սա մեկ հաճախորդի VM է:

Տվյալների հարթություն

1. VM-0-ն ունի լռելյայն երթուղի դեպի իր eth0 ինտերֆեյսը: Փաթեթն ուղարկվում է այնտեղ։
   Այս ինտերֆեյսը eth0 իրականում վիրտուալ միացված է վիրտուալ երթուղիչին vRouter-ին TAP ինտերֆեյսի tap0-ի միջոցով:
2. vRouter-ը վերլուծում է, թե որ միջերեսին է հայտնվել փաթեթը, այսինքն՝ որ հաճախորդին (VRF) է այն պատկանում, և ստուգում է ստացողի հասցեն այս հաճախորդի երթուղային աղյուսակով:
3. Պարզելով, որ նույն մեքենայի ստացողը գտնվում է այլ պորտի վրա, vRouter-ը պարզապես փաթեթն ուղարկում է դրան՝ առանց որևէ լրացուցիչ վերնագրի. այս դեպքում, vRouter-ն արդեն ունի ARP մուտք:

Այս դեպքում փաթեթը չի մտնում ֆիզիկական ցանց, այն ուղղորդվում է vRouter-ի ներսում:

Կառավարման ինքնաթիռ

Երբ վիրտուալ մեքենան գործարկվում է, հիպերվիզորն ասում է նրան.

• Իր սեփական IP հասցեն:
• Լռելյայն երթուղին այս ցանցում vRouter-ի IP հասցեի միջոցով է:

Հիպերվիզորը հաղորդում է 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-ն այստեղ միացված է: Նկարում կա երկու հաջորդ հոլով, և տարբեր թելեր կդասավորվեն դրանց մեջ ըստ հեշի: Իրական գործարանի դեպքում ավելի հավանական է լինելու 4 հաջորդ հոփ։

   Միևնույն ժամանակ, նա կարիք չունի իմանալու, թե ինչ կա արտաքին 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-ն, օրինակ, արդեն ունի Հասցե-Ընտանիք՝ ինկապսուլյացիայի մեթոդը փոխանցելու համար MPLS-in-GRE կամ MPLS-in-UDP.

Միևնույն ժամանակ, Underlay ցանցի կոնֆիգուրացիան ոչ մի կերպ չի փոխվում, ինչը, ի դեպ, շատ ավելի դժվար է ավտոմատացնելը, և ավելի հեշտ է կոտրել անհարմար շարժումով:

Ելք դեպի արտաքին աշխարհ

Ինչ-որ տեղ պետք է սիմուլյացիան ավարտվի, և դուք պետք է դուրս գաք վիրտուալ աշխարհից դեպի իրական աշխարհ: Եվ ձեզ հարկավոր է վճարովի հեռախոսի դարպաս:

Կիրառվում է երկու մոտեցում.

1. Տեղադրված է ապարատային երթուղիչ:
2. Գործարկվել է մի սարք, որն իրականացնում է երթուղիչի գործառույթները (այո, հետևելով SDN-ին, մենք նույնպես հանդիպեցինք VNF-ին): Եկեք այն անվանենք վիրտուալ դարպաս:

Երկրորդ մոտեցման առավելությունը էժան հորիզոնական մասշտաբայնությունն է. ուժը բավարար չէ. մենք գործարկեցինք մեկ այլ վիրտուալ մեքենա՝ դարպասով: Ցանկացած ֆիզիկական մեքենայի վրա, առանց փնտրելու ազատ դարակաշարեր, միավորներ, ելքային հզորություն, գնել սարքավորումն ինքնին, տեղափոխել այն, տեղադրել այն, փոխարկել այն, կարգավորել այն և այնուհետև փոխել դրա մեջ անսարք բաղադրիչները:

Վիրտուալ դարպասի թերությունները կայանում են նրանում, որ ֆիզիկական երթուղիչի միավորը դեռ մի քանի կարգով ավելի հզոր է, քան բազմամիջուկ վիրտուալ մեքենան, և դրա ծրագրակազմը, հարմարեցված իր սեփական ապարատային բազայի վրա, շատ ավելի կայուն է աշխատում (ոչ) Դժվար է նաև հերքել այն փաստը, որ ապարատային և ծրագրային համալիրը պարզապես աշխատում է՝ պահանջելով միայն կոնֆիգուրացիա, մինչդեռ վիրտուալ դարպասի գործարկումն ու պահպանումը խնդիր է ուժեղ ինժեներների համար:

Մեկ ոտքով դարպասը նայում է Overlay վիրտուալ ցանցին, ինչպես սովորական վիրտուալ մեքենան, և կարող է փոխազդել բոլոր մյուս VM-ների հետ: Միևնույն ժամանակ, այն կարող է դադարեցնել բոլոր հաճախորդների ցանցերը և, համապատասխանաբար, իրականացնել երթուղիներ նրանց միջև:

Իր մյուս ոտքով դարպասը նայում է հիմնական ցանցին և գիտի, թե ինչպես մտնել ինտերնետ:

Տվյալների հարթություն

Այսինքն, գործընթացը նման է հետևյալին.

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. VNGW-ից մինչև սահմանը կարող է լինել սովորական IP ցանց, ինչը քիչ հավանական է:
   Կարող է լինել դասական 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-ին:
   Թունելի նպատակակետ հասցեն vRouter-ի IP հասցեն է, որի հետևում գտնվում է թիրախային VM-ն՝ 10.0.0.2:
4. Հիմնական ցանցը փաթեթը փոխանցում է ցանկալի vRouter-ին:
5. Целевой vRouter снимает GRE/UDP, по MPLS-метке определяет интерфейс и шлёт голый IP-пакет в свой TAP-интерфейс, связанный с eth0 ВМ.

Կառավարման ինքնաթիռ

VNGW1-ը ստեղծում է BGP հարևանություն SDN վերահսկիչով, որտեղից ստանում է բոլոր երթուղային տեղեկատվությունը հաճախորդների մասին. որ IP հասցեն (vRouter) որ հաճախորդի հետևում է, և որ MPLS պիտակի կողմից է այն նույնացվում:

Նմանապես, նա ինքն է հայտնում SDN վերահսկիչին այս հաճախորդի պիտակով լռելյայն երթուղու մասին՝ նշելով իրեն որպես nexthop: Եվ հետո այս լռելյայն հասնում է vRouters-ին:

VNGW-ում սովորաբար տեղի է ունենում երթուղու համախմբում կամ NAT թարգմանություն:

Իսկ մյուս ուղղությամբ, այն ուղարկում է հենց այս ագրեգացված երթուղին սահմանների կամ Route Reflectors-ի հետ նստաշրջանին: Եվ դրանցից ստանում է լռելյայն երթուղին կամ Full-View, կամ այլ բան։

Էկապսուլյացիայի և տրաֆիկի փոխանակման առումով VNGW-ն ոչնչով չի տարբերվում vRouter-ից:
Եթե ​​մի փոքր ընդլայնեք շրջանակը, ապա կարող եք ցանցային այլ սարքեր ավելացնել VNGW-ներին և vRouters-ին, օրինակ՝ firewalls, երթևեկության մաքրման կամ հարստացման ֆերմաներ, IPS և այլն:

Եվ VRF-ների հաջորդական ստեղծման և երթուղիների ճիշտ հայտարարման օգնությամբ դուք կարող եք ստիպել երթևեկին շրջել ձեր ուզած ձևով, որը կոչվում է Service Chaining:

То есть и тут SDN-контроллер выступает в роли Route-Reflector’а между VNGW, vRouter’ами и другими сетевыми устройствами.

Բայց փաստորեն, վերահսկիչը նաև տեղեկատվություն է հրապարակում ACL-ի և PBR-ի (Քաղաքականության վրա հիմնված երթուղի) մասին, ինչի հետևանքով առանձին երթևեկության հոսքերը տարբեր կերպ են ընթանում, քան երթուղին է ասում:

FAQ

Зачем ты всё время делаешь ремарку GRE/UDP?

Դե, ընդհանուր առմամբ, կարելի է ասել, որ սա հատուկ է վոլֆրամի գործվածքին. ընդհանրապես պետք չէ դա հաշվի առնել:

Բայց եթե վերցնենք, TF-ն ինքը, դեռ OpenContrail-ը, աջակցում էր երկու ինկապսուլյացիաներին՝ MPLS GRE-ում և MPLS՝ UDP-ում:

UDP-ն լավն է, քանի որ Source Port-ում շատ հեշտ է կոդավորել հեշ ֆունկցիա բնօրինակ IP+Proto+Port-ից իր վերնագրում, ինչը թույլ կտա հավասարակշռել:

GRE-ի դեպքում, ավաղ, կան միայն արտաքին IP և GRE վերնագրեր, որոնք նույնն են բոլոր ինկապսուլացված տրաֆիկի համար, և հավասարակշռման մասին խոսք չկա. քչերն են կարող այդքան խորը նայել փաթեթի ներսում:

Մինչև որոշ ժամանակ երթուղիչները, եթե գիտեին, թե ինչպես օգտագործել դինամիկ թունելներ, դա անում էին միայն MPLSoGRE-ում, և միայն վերջերս նրանք սովորեցին օգտագործել MPLSoUDP: Հետեւաբար, մենք միշտ պետք է նշում կատարենք երկու տարբեր ինկապսուլյացիաների հնարավորության մասին:

Հանուն արդարության, հարկ է նշել, որ TF-ն լիովին աջակցում է L2 միացմանը՝ օգտագործելով VXLAN:

Դուք խոստացել եք զուգահեռներ անցկացնել OpenFlow-ի հետ։
Նրանք իսկապես խնդրում են դա։ vSwitch-ը նույն OpenStack-ում շատ նման բաներ է անում՝ օգտագործելով VXLAN-ը, որն, ի դեպ, ունի նաև UDP վերնագիր։

В Data Plane они работают примерно одинаково, существенно различается Control Plane. Tungsten Fabric использует XMPP для доставки информации о маршрутах на vRouter, в то время, как в OpenStack’е работает Openflow.

Կարո՞ղ եք ինձ մի փոքր ավելին պատմել vRouter-ի մասին:
Он делится на две части: vRouter Agent и vRouter Forwarder.

Առաջինն աշխատում է հյուրընկալող ՕՀ-ի User Space-ում և շփվում է SDN վերահսկիչի հետ՝ փոխանակելով տեղեկություններ երթուղիների, VRF-ների և ACL-ների մասին:

Երկրորդն իրականացնում է Data Plane - սովորաբար միջուկային տարածությունում, բայց կարող է նաև աշխատել SmartNIC-ների վրա՝ ցանցային քարտեր պրոցեսորով և առանձին ծրագրավորվող անջատիչ չիպով, որը թույլ է տալիս հեռացնել բեռը հյուրընկալող մեքենայի պրոցեսորից և դարձնել ցանցն ավելի արագ և ավելի։ կանխատեսելի.

Մեկ այլ հնարավոր սցենարն այն է, որ vRouter-ը DPDK հավելված է User Space-ում:

vRouter Agent-ը կարգավորումներ է ուղարկում vRouter Forwarder-ին:

Ի՞նչ է վիրտուալ ցանցը:
VRF-ի մասին հոդվածի սկզբում նշեցի, որ յուրաքանչյուր վարձակալ կապված է իր VRF-ի հետ։ Եվ եթե սա բավարար էր ծածկույթի ցանցի աշխատանքի մակերեսային ըմբռնման համար, ապա հաջորդ կրկնության ժամանակ անհրաժեշտ է պարզաբանումներ անել։

Սովորաբար, վիրտուալացման մեխանիզմներում Վիրտուալ Ցանցի էությունը (կարող եք սա համարել հատուկ գոյական) ներկայացվում է բաժանորդներից/վարձակալներից/վիրտուալ մեքենաներից առանձին՝ միանգամայն անկախ բան: Եվ այս վիրտուալ ցանցն արդեն կարող է ինտերֆեյսների միջոցով միացված լինել մեկ վարձակալի, մյուսի, երկուսի կամ ցանկացած վայրի: Այսպես, օրինակ, Service Chaining-ն իրականացվում է, երբ թրաֆիկը պետք է անցնի որոշակի հանգույցներով՝ պահանջվող հաջորդականությամբ՝ պարզապես ստեղծելով և միացնելով Վիրտուալ ցանցերը ճիշտ հաջորդականությամբ:

Поэтому как такового прямого соответствия между Virtual Network и тенантом нет.

Ամփոփում

Սա շատ մակերեսային նկարագրություն է վիրտուալ ցանցի աշխատանքի՝ հոսթից և SDN վերահսկիչից ծածկված: Բայց անկախ նրանից, թե որ վիրտուալացման հարթակ եք ընտրում այսօր, այն կաշխատի նույն ձևով, լինի դա VMWare, ACI, OpenStack, CloudStack, վոլֆրամի գործվածք կամ Juniper Contrail: Նրանք կտարբերվեն ինկապսուլյացիաների և վերնագրերի տեսակներով, ցանցային սարքերին տեղեկատվություն փոխանցելու արձանագրություններով, սակայն համեմատաբար պարզ և ստատիկ ներքևի ցանցի վերևում գործող ծրագրաշարով կարգավորվող ծածկույթի ցանցի սկզբունքը կմնա նույնը:
Կարելի է ասել, որ այսօր ծածկույթի ցանցի վրա հիմնված SDN-ն հաղթել է մասնավոր ամպի ստեղծման դաշտում։ Այնուամենայնիվ, դա չի նշանակում, որ Openflow-ը տեղ չունի ժամանակակից աշխարհում. այն օգտագործվում է OpenStacke-ում և նույն VMWare NSX-ում, որքան գիտեմ, Google-ն օգտագործում է այն ստորգետնյա ցանցը տեղադրելու համար։

Ստորև ես տրամադրել եմ ավելի մանրամասն նյութերի հղումներ, եթե ցանկանում եք ավելի խորը ուսումնասիրել խնդիրը:

Իսկ ինչ վերաբերում է մեր Ներքևին:

Բայց ընդհանուր առմամբ՝ ոչինչ։ Նա ամբողջ ճանապարհը չփոխեց։ Այն ամենը, ինչ նա պետք է անի հոսթից ծածկույթի դեպքում, թարմացնել երթուղիները և ARP-ները, քանի որ vRouter/VNGW-ն հայտնվում և անհետանում է և փաթեթներ տեղափոխում նրանց միջև:

Давайте сформулируем список требований к Underlay-сети.

1. Կարողանալ օգտագործել ինչ-որ երթուղային արձանագրություն, մեր իրավիճակում՝ BGP:
2. Ունենալ լայն թողունակություն, ցանկալի է՝ առանց գերբաժանորդագրման, որպեսզի փաթեթները չկորչեն ծանրաբեռնվածության պատճառով:
3. Աջակցող ECMP-ը գործվածքի անբաժանելի մասն է:
4. Уметь обеспечить QoS, в том числе хитрые штуки, вроде ECN.
5. NETCONF-ի աջակցությունը հիմք է ապագայի համար:

Ես այստեղ շատ քիչ ժամանակ եմ հատկացրել բուն Underlay ցանցի աշխատանքին: Դա պայմանավորված է նրանով, որ հաջորդ շարքում ես կկենտրոնանամ դրա վրա, և մենք միայն անցողիկ կանդրադառնանք Overlay-ին:

Ակնհայտ է, որ ես խստորեն սահմանափակում եմ մեզ բոլորիս՝ որպես օրինակ օգտագործելով DC ցանցը, որը կառուցվել է Cloz-ի գործարանում մաքուր IP երթուղղմամբ և հոսթից ծածկույթով:

Այնուամենայնիվ, ես վստահ եմ, որ ցանկացած ցանց, որն ունի դիզայն, կարելի է բնութագրել պաշտոնական տերմիններով և ավտոմատացնել: Պարզապես այստեղ իմ նպատակն է հասկանալ ավտոմատացման մոտեցումները, և ոչ թե բոլորին շփոթեցնել՝ խնդիրը ընդհանուր ձևով լուծելով։

Որպես ADSM-ի մաս, Ռոման Գորջը և ես նախատեսում ենք հրապարակել առանձին թողարկում՝ հաշվողական հզորության վիրտուալացման և ցանցի վիրտուալացման հետ դրա փոխազդեցության մասին: Մնալ կապի մեջ.

Օգտակար հղումներ

• Tungsten Fabric Archvitecture.
• մասին:ամպ. 6 ժամ Yandex.Cloud-ի մասին, որը նույնպես ծածկում է TF-ի վիրտուալ ցանցը:
• Ի՞նչ է Open vSwitch-ը:
• Введение в VxLAN.
• RFC 7348. Վիրտուալ ընդարձակվող տեղային ցանց (VXLAN). Շերտ 2-ի վիրտուալացված ցանցերը 3-րդ շերտի վրա ծածկելու շրջանակ:
  
• Scaleway մոտեցում VXLAN EVPN Fabric-ին. Այն խոսում է ամբողջ DC ցանցի մասին, ներառյալ Underlay-ը, Overlay-ը, բազմաբնակարան տան և կառավարման մոտեցումները:

Շնորհակալություն

• Ռոման Գորգա - Linkmeup podcast-ի նախկին հաղորդավար և այժմ ամպային հարթակների ոլորտում փորձագետ: Մեկնաբանությունների և խմբագրումների համար։ Դե ինչ, առաջիկայում սպասում ենք նրա վիրտուալացման մասին ավելի խորը հոդվածին։
• Ալեքսանդր Շալիմով - իմ գործընկերն ու փորձագետը վիրտուալ ցանցերի զարգացման ոլորտում: Մեկնաբանությունների և խմբագրումների համար։
• Վալենտին Սինիցին - Վոլֆրամի գործվածքների ոլորտում իմ գործընկերն ու փորձագետը: Մեկնաբանությունների և խմբագրումների համար։
• Արտյոմ Չեռնոբայ — illustrator linkmeup. KDPV-ի համար.
• Ալեքսանդր Լիմոնով. «Ավտոմատ» մեմերի համար։

Source: www.habr.com