В алдыңғы шығарылым Мен желіні автоматтандыру құрылымын сипаттадым. Кейбір адамдардың пікірінше, мәселеге алғашқы көзқарастың өзі кейбір сұрақтарды шешіп қойған. Бұл мені өте қуантады, өйткені циклдегі біздің мақсатымыз Python сценарийлерімен Ansible-ді жабу емес, жүйені құру.

Дәл сол шеңбер біз мәселені шешу тәртібін белгілейді.
Бұл мәселе арналған желілік виртуализация біз автоматтандыруды талдайтын ADSM тақырыбына ерекше сәйкес келмейді.

Бірақ басқа қырынан қарайық.

Көптеген қызметтер бір желіні ұзақ уақыт бойы пайдаланып келеді. Байланыс операторы жағдайында бұл, мысалы, 2G, 3G, LTE, кең жолақты және B2B. Тұрақты ток жағдайында: әртүрлі клиенттерге қосылу мүмкіндігі, Интернет, блоктық сақтау, объектіні сақтау.

Және барлық қызметтер бір-бірінен оқшаулануды талап етеді. Оверлейлік желілер осылай пайда болды.

Және барлық қызметтер адамның оларды қолмен конфигурациялауын күтуді қаламайды. Оркестрлер мен SDN осылай пайда болды.

Желіні жүйелі автоматтандырудың бірінші тәсілі, дәлірек айтсақ, оның бір бөлігі көптеген жерлерде бұрыннан қабылданған және енгізілген: VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.

Бұл біз бүгін шешетін нәрсе.

Мазмұны

• себептері
• Терминология
• Астыңғы қабат – физикалық желі
• Overlay - виртуалды желі
  • ToR арқылы қабаттасу
  • Хосттың қабаттасуы
  • Мысал ретінде вольфрам матасын пайдалану
    • Бір физикалық машина ішіндегі байланыс
    • Әртүрлі физикалық машиналарда орналасқан VM арасындағы байланыс
    • Сыртқы әлемге шығу

• FAQ
• қорытынды
• Пайдалы сілтемелер

себептері

Біз бұл туралы айтып жатқандықтан, желіні виртуалдандырудың алғышарттарын атап өткен жөн. Негізі бұл процесс кеше басталған жоқ.

Сіз желі әрқашан кез келген жүйенің ең инертті бөлігі болғанын бірнеше рет естіген шығарсыз. Және бұл барлық мағынада шындық. Желі - бәрі тірек болатын негіз және оған өзгертулер енгізу өте қиын - желі өшірілген кезде қызметтер оған шыдамайды. Көбінесе бір түйінді пайдаланудан шығару қолданбалардың үлкен бөлігін алып тастауы және көптеген тұтынушыларға әсер етуі мүмкін. Желілік команда кез келген өзгеріске қарсы тұруы мүмкін - сондықтан ол қазір қандай да бір түрде жұмыс істейді (қалай екенін де білмеуіміз мүмкін), бірақ мұнда жаңа нәрсені конфигурациялау керек және оның желіге қалай әсер ететіні белгісіз.

Желілік пайдаланушылардың VLAN-ды енгізуін күтпеу және әрбір желі түйінінде ешқандай қызметтерді тіркемеу үшін адамдар қабаттасуды пайдалану идеясын ұсынды - қабаттасатын желілер - олардың алуан түрлілігі: GRE, IPinIP, MPLS, MPLS L2/L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE және т.б.

Олардың тартымдылығы екі қарапайым нәрседе жатыр:

• Тек соңғы түйіндер конфигурацияланады — транзиттік түйіндерге қол тигізудің қажеті жоқ. Бұл процесті айтарлықтай жылдамдатады, кейде желілік инфрақұрылым бөлімін жаңа қызметтерді енгізу процесінен толығымен алып тастауға мүмкіндік береді.
• Жүктеме тақырыптардың тереңінде жасырылған - транзиттік түйіндер бұл туралы, хосттардағы адрестеу туралы немесе қабаттасатын желінің маршруттары туралы ештеңе білудің қажеті жоқ. Бұл кестелерде аз ақпаратты сақтау керек дегенді білдіреді, яғни қарапайым/арзан құрылғыны пайдалану.

Бұл толығымен толық емес мәселеде мен барлық мүмкін технологияларды талдауды жоспарламаймын, керісінше тұрақты токтарда қабаттасатын желілердің жұмыс істеу негізін сипаттаймын.

Бүкіл серия бірдей серверлік жабдық орнатылған бірдей сөрелердің қатарларынан тұратын деректер орталығын сипаттайды.

Бұл жабдық қызметтерді жүзеге асыратын виртуалды машиналарды/контейнерлерді/серверсіз жұмыс істейді.

Терминология

Циклда сервер Клиент пен сервер байланысының серверлік жағын жүзеге асыратын программаны атаймын.

Сөрелердегі физикалық машиналар серверлер деп аталады емес біз істейміз.

Физикалық машина — сөреге орнатылған x86 компьютері. Ең жиі қолданылатын термин хост. Біз оны осылай атаймыз»машина«Немесе хост.

Гипервизор - виртуалды машиналар жұмыс істейтін физикалық ресурстарды эмуляциялайтын физикалық машинада жұмыс істейтін қолданба. Кейде әдебиетте және Интернетте «гипервизор» сөзі «хост» сөзінің синонимі ретінде қолданылады.

Виртуалды машина - гипервизордың үстіндегі физикалық машинада жұмыс істейтін операциялық жүйе. Бұл циклде біз үшін бұл шын мәнінде виртуалды машина ма, әлде жай контейнер ме, маңызды емес. Оны атаймыз»В.М.«

Жалға алушы бұл мақалада жеке қызмет немесе жеке клиент ретінде анықтайтын кең ұғым.

Көп пәтерлі немесе көп жалдау - әртүрлі клиенттердің/қызметтердің бір қолданбаны пайдалануы. Сонымен қатар, клиенттерді бір-бірінен оқшаулау бөлек іске қосылған даналар арқылы емес, қолданбалы архитектура арқасында қол жеткізіледі.

ToR — Сөренің үстіңгі қосқышы - барлық физикалық машиналар қосылған сөреде орнатылған коммутатор.

ToR топологиясына қоса, әртүрлі провайдерлер жолдың соңы (EoR) немесе жолдың ортасы бойынша тәжірибе жасайды (бірақ соңғысы кемсітетін сирек және MoR аббревиатурасын көрмедім).

Астыңғы желі немесе негізгі желі немесе астарлы желі физикалық желі инфрақұрылымы болып табылады: коммутаторлар, маршрутизаторлар, кабельдер.

Оверлайлы желі немесе қабаттасатын желі немесе қабаттас - физикалық бірінің үстінде жұмыс істейтін туннельдердің виртуалды желісі.

L3 матасы немесе IP матасы - STP қайталамауға және сұхбат үшін TRILL үйренуге мүмкіндік беретін адамзаттың таңғажайып өнертабысы. Қолжетімділік деңгейіне дейінгі бүкіл желі тек VLANсыз және сәйкесінше кең ауқымды таратылатын домендерсіз L3 болатын тұжырымдама. «Зауыт» сөзінің қайдан шыққанын келесі бөлімде қарастырамыз.

SDN - Бағдарламалық құралмен анықталған желі. Кіріспе қажет емес. Желіге өзгертулер адам емес, бағдарлама арқылы жасалатын желіні басқару тәсілі. Әдетте басқару жазығын соңғы желі құрылғыларынан тыс контроллерге жылжытуды білдіреді.

NFV — Желілік функцияны виртуализациялау — желілік құрылғыларды виртуалдандыру, кейбір желілік функцияларды жаңа қызметтерді енгізуді жылдамдату, Қызметтер тізбегін ұйымдастыру және көлденең масштабтауды жеңілдету үшін виртуалды машиналар немесе контейнерлер түрінде іске қосуға болатындығын болжайды.

VNF - Виртуалды желі функциясы. Арнайы виртуалды құрылғы: маршрутизатор, коммутатор, брандмауэр, NAT, IPS/IDS және т.б.

Оқырманды көп шатастырмау үшін мен қазір сипаттаманы нақты іске асыруға әдейі жеңілдетемін. Ойланып оқу үшін мен оны бөлімге жіберемін сілтемелер. Сонымен қатар, бұл мақаланы дәлсіздіктер үшін сынайтын Рома Гордж сервер мен желіні виртуалдандыру технологиялары туралы тереңірек және егжей-тегжейлі мұқият бөлек мақала жазуға уәде береді.

Бүгінгі таңда көптеген желілерді екі бөлікке бөлуге болады:

Астыңғы қабаты — тұрақты конфигурациясы бар физикалық желі.
Overlay — жалға алушыларды оқшаулау үшін астарлы қабаттың үстіне абстракция.

Бұл DC жағдайына да (біз оны осы мақалада талдаймыз) және ISP үшін де (біз талдамаймыз, өйткені ол бұрыннан болған) SDSM). Кәсіпорын желілерінде, әрине, жағдай біршама басқаша.

Желідегі фокустағы сурет:

Астыңғы қабаты

Астыңғы қабат - бұл физикалық желі: аппараттық қосқыштар мен кабельдер. Жер астындағы құрылғылар физикалық машиналарға қалай жетуге болатынын біледі.

Ол стандартты хаттамалар мен технологияларға сүйенеді. Аппараттық құрылғылар бүгінгі күнге дейін микросхеманы бағдарламалауға немесе өзінің хаттамаларын жүзеге асыруға мүмкіндік бермейтін жеке бағдарламалық жасақтамада жұмыс істейтіндіктен, тиісінше, басқа жеткізушілермен үйлесімділік және стандарттау қажет.

Бірақ Google сияқты біреудің өз қосқыштарын әзірлеуге және жалпы қабылданған протоколдардан бас тартуға мүмкіндігі бар. Бірақ LAN_DC Google емес.

Астыңғы қабат салыстырмалы түрде сирек өзгереді, өйткені оның жұмысы физикалық машиналар арасындағы негізгі IP байланысы болып табылады. Underlay оның үстінде жұмыс істейтін қызметтер, клиенттер немесе жалға алушылар туралы ештеңе білмейді - тек пакетті бір құрылғыдан екіншісіне жеткізу керек.
Астыңғы қабат келесідей болуы мүмкін:

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

Underlay желісі классикалық жолмен конфигурацияланған: CLI/GUI/NETCONF.

Қолмен, сценарийлер, меншікті утилиталар.

Сериядағы келесі мақала толығырақ астыңғы қабатқа арналған.

Overlay

Overlay - бұл Underlay үстіне созылған туннельдердің виртуалды желісі, ол бір клиенттің VM-леріне басқа клиенттерден оқшаулауды қамтамасыз ете отырып, бір-бірімен байланысуға мүмкіндік береді.

Клиент деректері жалпыға ортақ желі арқылы тасымалдау үшін кейбір туннельдік тақырыптарға инкапсулирленген.

Осылайша, бір клиенттің (бір қызмет) VM құрылғылары пакеттің нақты қандай жолды таңдайтынын білмей-ақ, Overlay арқылы бір-бірімен байланыса алады.

Қабаттасу, мысалы, мен жоғарыда айтқанымдай болуы мүмкін:

• GRE туннелі
• VXLAN
• EVPN
• L3VPN
• ЖЕНЕВ

Үстемелік желі әдетте орталық контроллер арқылы конфигурацияланады және қызмет көрсетіледі. Одан конфигурация, басқару жазықтығы және деректер жазықтығы клиенттік трафикті бағыттайтын және инкапсуляциялайтын құрылғыларға жеткізіледі. Азғана Төменде Мұны мысалдармен қарастырайық.

Иә, бұл ең таза түрінде SDN.

Overlay желісін ұйымдастырудың екі түбегейлі әртүрлі тәсілдері бар:

1. ToR арқылы қабаттасу
2. Хосттың қабаттасуы

ToR арқылы қабаттасу

Қабаттасу, мысалы, VXLAN мата жағдайында орын алатындай, сөреде тұрған кіру қосқышынан (ToR) басталуы мүмкін.

Бұл ISP желілеріндегі уақытпен тексерілген механизм және барлық желілік жабдық жеткізушілері оны қолдайды.

Дегенмен, бұл жағдайда ToR қосқышы сәйкесінше әртүрлі қызметтерді ажырата алуы керек және желі әкімшісі белгілі бір дәрежеде виртуалды машина әкімшілерімен ынтымақтасуы және құрылғылардың конфигурациясына өзгерістер енгізуі керек (автоматты түрде болса да) .

Мұнда мен оқырманды мақалаға сілтеме жасаймын Habré-дегі VxLAN біздің ескі досымыз @bormoglotx.
Осыған ENOG көмегімен презентациялар EVPN VXLAN құрылымымен тұрақты ток желісін құру тәсілдері егжей-тегжейлі сипатталған.

Ал шындыққа толық ену үшін сіз Цисканың кітабын оқи аласыз Заманауи, ашық және масштабталатын құрылым: VXLAN EVPN.

Мен VXLAN тек инкапсуляция әдісі екенін және туннельдердің тоқтатылуы ToR-де емес, мысалы, OpenStack жағдайындағыдай хостта болуы мүмкін екенін ескертемін.

Дегенмен, қабаттасуы ToR-дан басталатын VXLAN матасы белгіленген қабаттасатын желі дизайндарының бірі болып табылады.

Хосттың қабаттасуы

Тағы бір тәсіл - соңғы хосттардағы туннельдерді бастау және тоқтату.
Бұл жағдайда желі (Underlay) мүмкіндігінше қарапайым және статикалық болып қалады.
Ал хосттың өзі барлық қажетті инкапсуляцияны жасайды.

Бұл, әрине, хосттарда арнайы қолданбаны іске қосуды талап етеді, бірақ бұл тұрарлық.

Біріншіден, клиентті Linux құрылғысында іске қосу оңайырақ немесе айталық, тіпті мүмкін, коммутаторда сіз көп жеткізуші идеясын жоятын меншікті SDN шешімдеріне жүгінуіңіз керек.

Екіншіден, бұл жағдайда ToR қосқышын басқару жазықтығы және деректер жазықтығы тұрғысынан мүмкіндігінше қарапайым қалдыруға болады. Шынында да, SDN контроллерімен байланысудың қажеті жоқ, сонымен қатар барлық қосылған клиенттердің желілерін/ARP-терін сақтаудың қажеті жоқ - физикалық машинаның IP мекенжайын білу жеткілікті, бұл коммутацияны айтарлықтай жеңілдетеді/ маршруттау кестелері.

ADSM сериясында мен хосттан қабаттасу тәсілін таңдаймын - содан кейін біз бұл туралы ғана сөйлесеміз және VXLAN зауытына оралмаймыз.

Мысалдарды қарау ең оңай. Сынақ тақырыбы ретінде біз OpenSource SDN OpenContrail платформасын аламыз, қазір атымен белгілі Вольфрам мата.

Мақаланың соңында мен OpenFlow және OpenvSwitch ұқсастығы туралы бірнеше ойлар беремін.

Мысал ретінде вольфрам матасын пайдалану

Әрбір физикалық машина бар vRouter - оған қосылған желілерді және олардың қандай клиенттерге жататынын білетін виртуалды маршрутизатор - негізінен PE маршрутизаторы. Әрбір клиент үшін ол оқшауланған маршруттау кестесін сақтайды (VRF оқыңыз). Және vRouter шын мәнінде Overlay туннельдерін жасайды.

vRouter туралы толығырақ мақаланың соңында.

Гипервизорда орналасқан әрбір VM осы құрылғының vRouter-ге арқылы қосылады TAP интерфейсі.

БГБ - Терминалға кіру нүктесі – желілік өзара әрекеттесуге мүмкіндік беретін Linux ядросындағы виртуалды интерфейс.

Егер vRouter артында бірнеше желі болса, онда олардың әрқайсысы үшін IP мекенжайы тағайындалған виртуалды интерфейс жасалады - бұл әдепкі шлюз мекенжайы болады.
Бір клиенттің барлық желілері біреуінде орналастырылған 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) оны байланыстырады.
• Осы VM үшін статикалық ARP жазбасы — оның IP мекенжайы қандай интерфейсте орналасқан және ол қандай MAC мекенжайына байланысты.

Тағы да, нақты өзара әрекеттесу процедурасы тұжырымдаманы түсіну үшін жеңілдетілген.

Осылайша, vRouter берілген құрылғыдағы бір клиенттің барлық VM құрылғыларын тікелей қосылған желілер ретінде көреді және олардың арасында өзі бағыттай алады.

Бірақ VM0 және VM1 әртүрлі клиенттерге жатады және сәйкесінше әртүрлі vRouter кестелерінде болады.

Олардың бір-бірімен тікелей байланыса алуы vRouter параметрлері мен желі дизайнына байланысты.
Мысалы, егер екі клиенттің виртуалды құрылғылары жалпыға ортақ мекенжайларды пайдаланса немесе 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 желісінің мүшесі ретінде 10.0.1.2 нұсқасына қалай жетуге болатынын біледі (мысалы, OSPF арқылы) және пакетті маршрут бойынша жібереді. Мұнда ECMP қосылғанын ескеріңіз. Суретте екі келесі бөлім бар және әртүрлі ағындар оларға хэш бойынша сұрыпталады. Нағыз зауыт жағдайында 4 келесі цех болуы мүмкін.

   Бұл ретте оған сыртқы IP тақырыбының астында не бар екенін білудің қажеті жоқ. Яғни, шын мәнінде, IP астында Ethernet арқылы MPLS арқылы IPv6 сэндвичі грек арқылы GRE арқылы MPLS арқылы болуы мүмкін.

7. Тиісінше, қабылдаушы жағында vRouter GRE-ді жояды және MPLS тегін пайдалана отырып, бұл пакетті қай интерфейске жіберу керектігін түсінеді, оны ажыратады және оны бастапқы түрінде алушыға жібереді.

Бақылау жазықтығы

Сіз машинаны іске қосқан кезде, жоғарыда сипатталғандай нәрсе болады.

Және плюс келесілер:

• Әрбір клиент үшін vRouter MPLS тегін бөледі. Бұл L3VPN қызмет белгісі, ол арқылы клиенттер бір физикалық машинада бөлінеді.
  

  Шындығында, MPLS тегі әрқашан vRouter арқылы сөзсіз бөлінеді - ақыр соңында, машинаның бір vRouter артындағы басқа машиналармен ғана әрекеттесетіні алдын ала белгілі емес және бұл тіпті дұрыс емес.

• vRouter BGP протоколы арқылы SDN контроллерімен қосылымды орнатады (немесе оған ұқсас – TF жағдайында бұл XMPP 0_o).
• Осы сеанс арқылы vRouter SDN контроллеріне қосылған желілердің бағыттарын хабарлайды:
  • Желі мекенжайы
  • Инкапсуляция әдісі (MPLSoGRE, MPLSoUDP, VXLAN)
  • MPLS клиент тегі
  • Сіздің IP мекенжайыңыз келесідей

• SDN контроллері мұндай маршруттарды барлық қосылған vRouterлерден алады және оларды басқаларға көрсетеді. Яғни, ол маршрут рефлекторы қызметін атқарады.

Дәл сол нәрсе қарама-қарсы бағытта болады.

Қабаттау кем дегенде әр минут сайын өзгеруі мүмкін. Клиенттер виртуалды машиналарын үнемі іске қосып, өшіретін жалпыға ортақ бұлттарда осылай болады.

Орталық контроллер конфигурацияны сақтаудың және vRouter жүйесіндегі коммутация/маршруттау кестелерін бақылаудың барлық күрделілігін шешеді.

Шамамен айтқанда, контроллер барлық vRouters-пен BGP (немесе ұқсас протокол) арқылы байланысады және жай ғана маршруттау туралы ақпаратты жібереді. Мысалы, BGP-де инкапсуляция әдісін жеткізу үшін мекенжай-отбасы бар MPLS-in-GRE немесе MPLS-in-UDP.

Сонымен қатар, Underlay желісінің конфигурациясы еш өзгермейді, айтпақшы, оны автоматтандыру әлдеқайда қиын және ыңғайсыз қозғалыспен бұзу оңайырақ.

Сыртқы әлемге шығу

Бір жерде модельдеу аяқталуы керек және виртуалды әлемнен шынайы әлемге шығу керек. Ал сізге таксофондық шлюз қажет.

Екі тәсіл қолданылады:

1. Аппараттық маршрутизатор орнатылған.
2. Маршрутизатордың функцияларын жүзеге асыратын құрылғы іске қосылды (иә, SDN-ден кейін біз VNF-ді кездестірдік). Оны виртуалды шлюз деп атаймыз.

Екінші тәсілдің артықшылығы - арзан көлденең масштабтау - қуат жеткіліксіз - біз шлюзі бар басқа виртуалды машинаны іске қостық. Кез келген физикалық машинада бос сөрелерді, блоктарды, қуат шығысын іздемей, жабдықтың өзін сатып алыңыз, оны тасымалдаңыз, орнатыңыз, ауыстырыңыз, конфигурациялаңыз, содан кейін ондағы ақаулы компоненттерді өзгертіңіз.

Виртуалды шлюздің кемшіліктері физикалық маршрутизатордың бірлігі әлі де көп ядролы виртуалды машинаға қарағанда әлдеқайда қуаттырақ және оның жеке аппараттық базаға бейімделген бағдарламалық жасақтамасы әлдеқайда тұрақты жұмыс істейді (жоқ). Сондай-ақ, аппараттық-бағдарламалық кешеннің жай ғана жұмыс істейтінін, тек конфигурацияны қажет ететінін жоққа шығару қиын, ал виртуалды шлюзді іске қосу және қолдау күшті инженерлердің міндеті.

Бір аяқпен шлюз кәдімгі виртуалды машина сияқты Overlay виртуалды желісіне қарайды және барлық басқа виртуалды құрылғылармен әрекеттесе алады. Сонымен бірге ол барлық клиенттердің желілерін тоқтата алады және сәйкесінше олардың арасында маршруттауды жүзеге асырады.

Екінші аяғымен шлюз магистральдық желіге қарайды және Интернетке қалай кіру керектігін біледі.

Деректер жазықтығы

Яғни, процесс келесідей көрінеді:

1. VM-0 әдепкі бойынша бірдей vRouter-ге орнатылып, eth185.147.83.177 интерфейсіне сыртқы әлемде (0) тағайындалуы бар пакетті жібереді.
2. vRouter осы пакетті алады және маршруттау кестесінен тағайындалған мекенжайды іздейді - 1 туннель арқылы VNGW1 шлюзі арқылы әдепкі маршрутты табады.
   Ол сондай-ақ бұл SIP 10.0.0.2 және DIP 10.0.255.2 бар GRE туннелі екенін көреді және ол алдымен VNGW1 күтетін осы клиенттің MPLS белгісін бекітуі керек.
3. vRouter бастапқы пакетті MPLS, GRE және жаңа IP тақырыптарымен буып, оны әдепкі бойынша ToR1 10.0.0.1 жібереді.
4. Негізгі желі пакетті VNGW1 шлюзіне жеткізеді.
5. VNGW1 шлюзі GRE және MPLS туннельдеу тақырыптарын жояды, тағайындалған мекенжайды көреді, оның маршруттау кестесін қарастырады және оның Интернетке бағытталғанын түсінеді - яғни Толық көрініс немесе Әдепкі арқылы. Қажет болса, NAT аудармасын орындайды.
6. VNGW-ден шекараға дейін тұрақты IP желісі болуы мүмкін, бұл екіталай.
   Классикалық MPLS желісі (IGP+LDP/RSVP TE) болуы мүмкін, BGP LU бар артқы мата немесе VNGW-ден IP желісі арқылы шекараға дейін GRE туннелі болуы мүмкін.
   Қалай болғанда да, VNGW1 қажетті инкапсуляцияларды орындайды және бастапқы пакетті шекараға жібереді.

Қарсы бағыттағы қозғалыс қарама-қарсы ретпен бірдей қадамдардан өтеді.

1. Шекара пакетті VNGW1-ге түсіреді
2. Ол оны шешіндіріп, алушының мекенжайына қарайды және оған Tunnel1 туннелі (MPLSoGRE немесе MPLSoUDP) арқылы кіруге болатынын көреді.
3. Тиісінше, ол MPLS белгісін, GRE/UDP тақырыбын және жаңа IP тіркейді және оны ToR3 10.0.255.1 жібереді.
   Туннельдің тағайындалған мекенжайы мақсатты VM орналасқан vRouter IP мекенжайы болып табылады - 10.0.0.2.
4. Негізгі желі пакетті қажетті vRouter-ке жеткізеді.
5. Мақсатты vRouter GRE/UDP оқиды, MPLS белгісін пайдаланып интерфейсті анықтайды және VM eth0-мен байланысты TAP интерфейсіне жалаң IP пакетін жібереді.

Бақылау жазықтығы

VNGW1 SDN контроллері бар BGP төңірегін орнатады, одан ол клиенттер туралы барлық бағыттау ақпаратын алады: қай IP мекенжайы (vRouter) қай клиенттің артында орналасқан және ол қандай MPLS белгісімен анықталған.

Сол сияқты, оның өзі SDN контроллеріне осы клиенттің белгісімен әдепкі маршрут туралы хабарлайды, өзін келесі блок ретінде көрсетеді. Содан кейін бұл әдепкі vRouters-ке келеді.

VNGW жүйесінде әдетте маршрутты біріктіру немесе NAT аудармасы орын алады.

Ал басқа бағытта ол дәл осы жинақталған маршрутты шекаралары немесе маршрут рефлекторлары бар сеансқа жібереді. Және олардан ол әдепкі маршрутты немесе толық көріністі немесе басқа нәрсені алады.

Инкапсуляция және трафик алмасу тұрғысынан VNGW vRouter-тен еш айырмашылығы жоқ.
Егер сіз ауқымды сәл кеңейтсеңіз, онда сіз басқа желілік құрылғыларды VNGW және vRouters-ке қоса аласыз, мысалы, желіаралық қалқандар, трафикті тазалау немесе байыту фермалары, IPS және т.б.

Және VRF-ті дәйекті құру және маршруттарды дұрыс хабарлау көмегімен трафикті өзіңіз қалаған жолмен айналдыруға мәжбүрлей аласыз, бұл Service Chaining деп аталады.

Яғни, бұл жерде де SDN контроллері VNGW, vRouters және басқа желілік құрылғылар арасында маршрут рефлекторы ретінде әрекет етеді.

Бірақ шын мәнінде, контроллер сонымен қатар ACL және PBR (саясатқа негізделген маршруттау) туралы ақпаратты шығарады, бұл жеке трафик ағындарының маршруттан басқаша жүруіне әкеледі.

FAQ

Неліктен сіз GRE/UDP ескертуін жасайсыз?

Жалпы, бұл вольфрам матасына тән деп айтуға болады - оны мүлдем ескерудің қажеті жоқ.

Бірақ егер біз оны алсақ, онда TF өзі әлі OpenContrail болған кезде екі инкапсуляцияны да қолдады: GRE-де MPLS және UDP-де MPLS.

UDP жақсы, себебі Source Port-та ​​оның тақырыбындағы бастапқы IP+Proto+Port хэш-функциясын кодтау өте оңай, бұл сізге теңгерімдеуге мүмкіндік береді.

GRE жағдайында, өкінішке орай, тек сыртқы IP және GRE тақырыптары бар, олар барлық инкапсуляцияланған трафик үшін бірдей және теңгерімдеу туралы әңгіме жоқ - пакеттің ішіне соншалықты терең қарайтын адамдар аз.

Біраз уақытқа дейін, маршрутизаторлар, егер олар динамикалық туннельдерді пайдалана алатын болса, мұны тек MPLSoGRE-де жасады және жақында ғана MPLSoUDP пайдалануды үйренді. Сондықтан біз әрқашан екі түрлі инкапсуляцияның мүмкіндігі туралы ескертпе жасауымыз керек.

Әділдік үшін, TF VXLAN арқылы L2 қосылымын толығымен қолдайтынын атап өткен жөн.

Сіз OpenFlow-пен параллельдер салуға уәде бердіңіз.
Олар шынымен де сұрайды. Сол OpenStack ішіндегі vSwitch VXLAN арқылы өте ұқсас әрекеттерді жасайды, айтпақшы, оның UDP тақырыбы да бар.

Деректер жазықтығында олар шамамен бірдей жұмыс істейді; Басқару жазықтығы айтарлықтай ерекшеленеді. Tungsten Fabric vRouter жүйесіне бағыттау ақпаратын жеткізу үшін XMPP пайдаланады, ал OpenStack Openflow іске қосады.

vRouter туралы аздап айтып бере аласыз ба?
Ол екі бөлікке бөлінеді: vRouter Agent және vRouter Forwarder.

Біріншісі хост ОЖ пайдаланушы кеңістігінде жұмыс істейді және SDN контроллерімен байланысады, маршруттар, VRF және ACL туралы ақпарат алмасады.

Екіншісі Data Plane бағдарламасын іске асырады - әдетте ядро ​​кеңістігінде, бірақ сонымен бірге SmartNIC-де де жұмыс істей алады - процессоры және жеке бағдарламаланатын коммутациялық чипі бар желілік карталар, ол негізгі компьютердің орталық процессорынан жүктемені алып тастауға және желіні жылдамырақ және көбірек етуге мүмкіндік береді. болжауға болатын.

Басқа ықтимал сценарий vRouter пайдаланушы кеңістігіндегі DPDK қолданбасы болып табылады.

vRouter Agent параметрлерді vRouter Forwarder қызметіне жібереді.

Виртуалды желі дегеніміз не?
Мен VRF туралы мақаланың басында әр жалға алушы өзінің VRF-ге байланғанын айттым. Ал егер бұл қабаттасатын желінің жұмысын үстірт түсіну үшін жеткілікті болса, келесі итерацияда нақтылаулар енгізу қажет.

Әдетте, виртуалдандыру механизмдерінде Виртуалды желі нысаны (сіз мұны тиісті зат есім деп санай аласыз) клиенттерден/жалға алушылардан/виртуалды машиналардан бөлек енгізіледі - толығымен тәуелсіз нәрсе. Және бұл виртуалды желі интерфейстер арқылы бір жалға алушыға, екіншісіне, екеуіне немесе кез келген жерде қосылуы мүмкін. Мәселен, мысалы, Сервис тізбегі трафикті қажетті реттілікпен белгілі түйіндер арқылы өткізу қажет болғанда, Виртуалды желілерді дұрыс ретпен жасау және қосу арқылы жүзеге асырылады.

Сондықтан, Виртуалды желі мен жалға алушы арасында тікелей сәйкестік жоқ.

қорытынды

Бұл хост пен SDN контроллерінің қабаттасуы бар виртуалды желінің жұмысының өте үстірт сипаттамасы. Бірақ бүгін қандай виртуалдандыру платформасын таңдасаңыз да, ол VMWare, ACI, OpenStack, CloudStack, Tungsten Fabric немесе Juniper Contrail болсын, ұқсас түрде жұмыс істейді. Олар инкапсуляциялар мен тақырыптардың түрлерімен, соңғы желілік құрылғыларға ақпаратты жеткізу протоколдарымен ерекшеленеді, бірақ салыстырмалы түрде қарапайым және статикалық астарлы желі үстінде жұмыс істейтін бағдарламалық қамтамасыз ету арқылы конфигурацияланатын қабаттастыру желісінің принципі өзгеріссіз қалады.
Бүгінгі күні қабаттастыру желісіне негізделген SDN жеке бұлтты құру өрісін жеңіп алды деп айта аламыз. Дегенмен, бұл Openflow-қа қазіргі әлемде орын жоқ дегенді білдірмейді - ол OpenStacke-де және сол VMWare NSX-те қолданылады, менің білуімше, Google оны жерасты желісін орнату үшін пайдаланады.

Төменде мен егжей-тегжейлі материалдарға сілтемелер бердім, егер сіз мәселені тереңірек зерттегіңіз келсе.

Ал біздің астарымыз ше?

Бірақ жалпы, ештеңе. Ол жолды толығымен өзгертпеді. Хосттан қабаттасу жағдайында оған тек vRouter/VNGW пайда болып, жоғалып, олардың арасында пакеттерді тасымалдау кезінде маршруттар мен ARP жаңартулары қажет.

Underlay желісіне қойылатын талаптар тізімін құрастырайық.

1. Маршруттау протоколының қандай да бір түрін пайдалана білу, біздің жағдайымызда - BGP.
2. Пакеттердің шамадан тыс жүктелу салдарынан жоғалып кетпеуі үшін, артық жазылусыз, кең өткізу қабілетіне ие болыңыз.
3. Қолдау ECMP матаның ажырамас бөлігі болып табылады.
4. ECN сияқты күрделі нәрселерді қоса, QoS қамтамасыз ете алу.
5. NETCONF-ті қолдау болашақтың негізі болып табылады.

Мен мұнда Underlay желісінің жұмысына өте аз уақыт бөлдім. Себебі, кейінірек серияда мен оған тоқталатын боламын және біз тек өту кезінде қабаттасуға ғана тоқталамыз.

Мен мысал ретінде таза IP маршрутизациясы және хосттан қабаттасуы бар Clos зауытында салынған тұрақты ток желісін пайдалану арқылы барлығымызды шектейтінмін.

Дегенмен, дизайны бар кез келген желіні ресми түрде сипаттауға және автоматтандыруға болатынына сенімдімін. Бұл жерде менің мақсатым автоматтандыру тәсілдерін түсіну және мәселені жалпы түрде шешу арқылы барлығын шатастырмау.

ADSM аясында Роман Гордж екеуміз есептеу қуатын виртуализациялау және оның желілік виртуализациямен өзара әрекеттесуі туралы жеке басылым шығаруды жоспарлап отырмыз. Байланыста бол.

Пайдалы сілтемелер

• Вольфрам матасының архитектурасы.
• туралы: бұлт. TF-де виртуалды желіні де қамтитын Yandex.Cloud туралы 6 сағат.
• Open vSwitch дегеніміз не?
• VxLAN-ға кіріспе.
• RFC 7348. Виртуалды кеңейтілетін жергілікті желі (VXLAN): 2-деңгейдегі виртуалды желілерді 3-деңгейдегі желілер арқылы қабаттастыруға арналған құрылым.
  
• VXLAN EVPN Fabric үшін масштабты тәсіл. Ол бүкіл DC желісі туралы, соның ішінде Underlay, Overlay, мульти-гоминг және басқару тәсілдері туралы айтады.

Рақмет сізге

• Роман Горга - linkmeup подкастының бұрынғы хосты және қазір бұлтты платформалар саласындағы сарапшы. Түсініктемелер мен өңдеулер үшін. Жақын арада біз оның виртуализация туралы тереңірек мақаласын күтеміз.
• Александр Шалимов - менің әріптесім және виртуалды желіні дамыту саласындағы сарапшы. Түсініктемелер мен өңдеулер үшін.
• Валентин Синицын - менің әріптесім және вольфрамдық мата саласындағы сарапшы. Түсініктемелер мен өңдеулер үшін.
• Артем Чернобай — иллюстратор сілтемесі. KDPV үшін.
• Александр Лимонов. «Автоматты» мем үшін.

Ақпарат көзі: www.habr.com