В Ја опишав рамката за мрежна автоматизација. Според некои луѓе, дури и овој прв пристап кон проблемот веќе реши некои прашања. И ова ме прави многу среќен, бидејќи нашата цел во циклусот не е да го прикриеме Ansible со Python скрипти, туку да изградиме систем.
Истата рамка го поставува редоследот по кој ќе се занимаваме со прашањето.
И мрежната виртуелизација, на која е посветен овој број, не се вклопува особено во темата ADSM, каде што ја анализираме автоматизацијата.
Но, да го погледнеме од поинаков агол.
Многу услуги ја користат истата мрежа долго време. Во случај на телекомуникациски оператор, ова е 2G, 3G, LTE, широкопојасен интернет и B2B, на пример. Во случај на DC: поврзување за различни клиенти, Интернет, блок складирање, складирање на објекти.
И сите услуги бараат изолација едни од други. Вака се појавија преклопените мрежи.
И сите услуги не сакаат да чекаат некој да ги конфигурира рачно. Вака се појавија оркестратори и СДН.
Првиот пристап за систематска автоматизација на мрежата, поточно дел од неа, одамна е преземен и имплементиран на многу места: VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.
Тоа е она со што ќе се занимаваме денес.
содржина
- Причини
- Терминологија
- Подлога - физичка мрежа
- Преклопување - виртуелна мрежа
- Преклопување со ToR
- Преклопување од домаќинот
- Користење на волфрамска ткаенина како пример
- Комуникација во една физичка машина
- Комуникација помеѓу VM лоцирани на различни физички машини
- Излез во надворешниот свет
- Често поставувани прашања
- Заклучок
- Корисни линкови
Причини
И бидејќи зборуваме за ова, вреди да се споменат предусловите за виртуелизација на мрежата. Всушност, овој процес не започна вчера.
Веројатно сте слушнале повеќе од еднаш дека мрежата отсекогаш била најинертниот дел од кој било систем. И ова е вистина во секоја смисла. Мрежата е основата на која почива сè, а правењето промени на неа е доста тешко - услугите не го толерираат тоа кога мрежата е во прекин. Често, деактивирањето на еден јазол може да уништи голем дел од апликациите и да влијае на многу клиенти. Ова е делумно зошто мрежниот тим може да се спротивстави на секоја промена - затоа што сега некако функционира (можеби и не знаеме како), но тука треба да конфигурирате нешто ново, а не се знае како тоа ќе влијае на мрежата.
За да не чекаат мрежерите да вметнат VLAN и да не регистрираат никакви услуги на секој мрежен јазол, луѓето дојдоа на идеја да користат преклопувања - мрежи за преклопување - од кои има голема разновидност: GRE, IPinIP, MPLS, MPLS L2/L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE итн.
Нивната привлечност лежи во две едноставни работи:
- Само крајните јазли се конфигурирани - транзитните јазли не треба да се допираат. Ова значително го забрзува процесот, а понекогаш ви овозможува целосно да го исклучите одделот за мрежната инфраструктура од процесот на воведување нови услуги.
- Товарот е скриен длабоко во заглавјата - транзитните јазли не треба да знаат ништо за тоа, за адресирањето на домаќините или за маршрутите на преклопната мрежа. Ова значи дека треба да складирате помалку информации во табелите, што значи да користите поедноставен/поевтин уред.
Во ова не целосно полноправно издание, не планирам да ги анализирам сите можни технологии, туку да ја опишам рамката за работа на преклопните мрежи во DC.
Целата серија ќе опише центар за податоци кој се состои од редови идентични полици во кои е инсталирана истата серверска опрема.
Оваа опрема работи со виртуелни машини/контејнери/без сервери кои имплементираат услуги.
Терминологија
Во јамка сервер Ќе именувам програма која ја имплементира серверската страна на комуникацијата клиент-сервер.
Физичките машини во решетките се нарекуваат сервери Нема ние ќе.
Физичка машина — x86 компјутер инсталиран во решетката. Најчесто користен термин домаќин. Така ќе го наречеме“машина„или домаќин.
Хипервизор - апликација која работи на физичка машина која ги имитира физичките ресурси на кои работат Виртуелните машини. Понекогаш во литературата и интернетот зборот „хипервизор“ се користи како синоним за „домаќин“.
Виртуелна машина - оперативен систем кој работи на физичка машина на врвот на хипервизорот. За нас во овој циклус, навистина не е важно дали тоа е всушност виртуелна машина или само контејнер. Ајде да го наречеме“ВМ«
Закупец е широк концепт што ќе го дефинирам во оваа статија како посебна услуга или посебен клиент.
Мулти-закуп или multitenancy - користење на иста апликација од различни клиенти/услуги. Во исто време, изолацијата на клиентите едни од други се постигнува благодарение на архитектурата на апликацијата, а не преку одделни инстанци кои работат.
ToR - врвот на прекинувачот Rack - прекинувач инсталиран во багажник на кој се поврзани сите физички машини.
Покрај ТоР топологијата, различни провајдери практикуваат End of Row (EoR) или Middle of Row (иако ова последното е омаловажувачка реткост и не сум ја видел кратенката MoR).
Подлога мрежа или основната мрежа или подлогата е физичката мрежна инфраструктура: прекинувачи, рутери, кабли.
Преклопена мрежа или преклопна мрежа или преклоп - виртуелна мрежа од тунели што се протегаат над физичкиот.
L3 ткаенина или IP ткаенина - неверојатен изум на човештвото кој ви овозможува да избегнете повторување на STP и учење TRILL за интервјуа. Концепт во кој целата мрежа до нивото на пристап е исклучиво L3, без VLAN и, соодветно, огромни проширени домени за емитување. Ќе разгледаме од каде доаѓа зборот „фабрика“ во следниот дел.
SDN - Софтвер дефинирана мрежа. Едвај треба вовед. Пристап за управување со мрежата каде што промените во мрежата не се направени од лице, туку од програма. Обично значи преместување на контролната рамнина надвор од крајните мрежни уреди до контролорот.
НФВ — Виртуелизација на мрежна функција — виртуелизација на мрежните уреди, што сугерира дека некои мрежни функции може да се извршуваат во форма на виртуелни машини или контејнери за да се забрза имплементацијата на новите услуги, да се организира синџир на услуги и поедноставна хоризонтална приспособливост.
VNF - Функција на виртуелна мрежа. Специфичен виртуелен уред: рутер, прекинувач, заштитен ѕид, NAT, IPS/IDS итн.
Сега намерно го поедноставувам описот на одредена имплементација, за да не го збунам читателот премногу. За попромислено читање, го упатувам на делот . Дополнително, Ромската клисура, која го критикува овој напис за неточности, ветува дека ќе напише посебно издание за технологиите за виртуелизација на сервери и мрежи, подлабоко и повнимателно на деталите.
Повеќето мрежи денес можат јасно да се поделат на два дела:
Подлога — физичка мрежа со стабилна конфигурација.
Шалче — апстракција преку подлога за изолирање на станарите.
Ова важи и за случајот на DC (кој ќе го анализираме во овој напис) и за интернет провајдерот (кој нема да го анализираме, бидејќи веќе е ). Со претпријатијата мрежи, се разбира, ситуацијата е малку поинаква.
Слика со фокус на мрежата:
Подлога
Подлогата е физичка мрежа: хардверски прекинувачи и кабли. Уредите во подземјето знаат како да стигнат до физичките машини.
Се потпира на стандардни протоколи и технологии. Не само затоа што хардверските уреди до денес работат на сопствен софтвер кој не дозволува ниту програмирање на чипот ниту имплементирање на сопствени протоколи; соодветно, потребна е компатибилност со други продавачи и стандардизација.
Но, некој како Google може да си дозволи да развие свои прекинувачи и да ги напушти општоприфатените протоколи. Но, LAN_DC не е Google.
Подлогата се менува релативно ретко бидејќи нејзината работа е основната IP конекција помеѓу физичките машини. Underlay не знае ништо за услугите, клиентите или станарите кои работат над него - треба само да го испорача пакетот од една машина на друга.
Подлогата може да биде вака:
- IPv4+OSPF
- IPv6+ISIS+BGP+L3VPN
- L2+TRILL
- L2+STP
Мрежата Underlay е конфигурирана на класичен начин: CLI/GUI/NETCONF.
Рачно, скрипти, комерцијални комунални услуги.
Следната статија од серијата ќе биде посветена на подлогата подетално.
Шалче
Overlay е виртуелна мрежа од тунели протегана на врвот на Underlay, која им овозможува на VM-и на еден клиент да комуницираат едни со други, истовремено обезбедувајќи изолација од другите клиенти.
Податоците на клиентот се инкапсулирани во некои заглавија на тунели за пренос преку јавната мрежа.
Така, VM-ите на еден клиент (една услуга) можат да комуницираат едни со други преку Overlay, без воопшто да знаат по кој пат всушност оди пакетот.
Преклопувањето може да биде, на пример, како што споменав погоре:
- GRE тунел
- VXLAN
- ЕВПН
- L3VPN
- GЕНЕВЕ
Преклопената мрежа обично се конфигурира и одржува преку централен контролер. Од него, конфигурацијата, контролната рамнина и рамнината на податоци се доставуваат до уредите што го насочуваат и капсулираат сообраќајот на клиентите. Малку Ајде да го разгледаме ова со примери.
Да, ова е SDN во својата најчиста форма.
Постојат два фундаментално различни пристапи за организирање мрежа на преклопување:
- Преклопување со ToR
- Преклопување од домаќинот
Преклопување со ToR
Преклопувањето може да започне од прекинувачот за пристап (ToR) што стои во решетката, како што се случува, на пример, во случај на ткаенина VXLAN.
Ова е временски тестиран механизам на ISP мрежите и сите продавачи на мрежна опрема го поддржуваат.
Меѓутоа, во овој случај, ToR прекинувачот мора да може да ги одвои различните услуги, соодветно, а мрежниот администратор мора, до одреден степен, да соработува со администраторите на виртуелната машина и да прави промени (иако автоматски) во конфигурацијата на уредите .
Овде ќе го упатам читателот на статија за нашиот стар пријател .
Во ова детално се опишани пристапите за изградба на DC мрежа со ткаенина EVPN VXLAN.
И за поцелосно потопување во реалноста, можете да ја прочитате книгата на Циска .
Забележувам дека VXLAN е само метод на инкапсулација и завршувањето на тунелите може да се случи не на ToR, туку на домаќинот, како што се случува во случајот со OpenStack, на пример.
Сепак, VXLAN ткаенината, каде што преклопувањето започнува во ToR, е еден од воспоставените дизајни на мрежа за преклопување.
Преклопување од домаќинот
Друг пристап е започнување и завршување на тунелите на крајните домаќини.
Во овој случај, мрежата (Underlay) останува што е можно поедноставна и статична.
И самиот домаќин ја прави целата потребна инкапсулација.
Ова секако ќе бара да се стартува посебна апликација на домаќините, но вреди.
Прво, водење на клиент на машина Линукс е полесно или, да речеме, дури и можно, додека на прекинувач најверојатно ќе треба да се свртите кон сопственички SDN решенија, што ја убива идејата за повеќе продавачи.
Второ, ToR прекинувачот во овој случај може да се остави што е можно поедноставен, и од гледна точка на контролната рамнина и од гледна точка на рамнината на податоци. Навистина, тогаш не треба да комуницира со контролерот SDN, а исто така не треба да ги складира мрежите/ARP-ите на сите поврзани клиенти - доволно е да се знае IP адресата на физичката машина, што во голема мера го поедноставува префрлувањето/ рутирачки табели.
Во серијата ADSM, го избирам пристапот за преклопување од домаќинот - тогаш само зборуваме за тоа и нема да се вратиме во фабриката VXLAN.
Најлесно е да се погледнат примери. И како предмет за тестирање ќе ја земеме OpenSource SDN платформата OpenContrail, сега позната како .
На крајот од статијата ќе дадам неколку размислувања за аналогијата со OpenFlow и OpenvSwitch.
Користење на волфрамска ткаенина како пример
Секоја физичка машина има vРутер - виртуелен рутер кој знае за мрежите поврзани со него и на кои клиенти им припаѓаат - во суштина PE рутер. За секој клиент, тој одржува изолирана рутирачка табела (читај VRF). И vRouter всушност прави Overlay тунелирање.
Малку повеќе за vRouter е на крајот од статијата.
Секој VM лоциран на хипервизорот е поврзан со vRouter на оваа машина преку .
ТАП - Терминална пристапна точка - виртуелен интерфејс во кернелот Линукс кој овозможува мрежна интеракција.
Ако има неколку мрежи зад vRouter, тогаш за секоја од нив се креира виртуелен интерфејс, на кој е доделена IP адреса - тоа ќе биде стандардната адреса на портата.
Сите мрежи на еден клиент се сместени во еден VRF (една маса), различни - во различни.
Овде ќе објавам одрекување дека не е сè толку едноставно и ќе го испратам љубопитниот читател до крајот на статијата.
За да може vRouters да комуницираат меѓу себе, и соодветно на VM-ите што се наоѓаат зад нив, тие разменуваат информации за рутирање преку SDN контролер.
За да излезете во надворешниот свет, постои излезна точка од матрицата - виртуелна мрежна порта VNGW — Виртуелна мрежна порта (мојот мандат).
Сега да погледнеме примери на комуникации - и ќе има јасност.
Комуникација во една физичка машина
VM0 сака да испрати пакет до VM2. Да претпоставиме засега дека ова е еден клиент VM.
Рамнина на податоци
- VM-0 има стандардна рута до својот eth0 интерфејс. Пакетот се испраќа таму.
Овој интерфејс eth0 е всушност виртуелно поврзан со виртуелниот рутер vRouter преку интерфејсот TAP tap0. - vRouter анализира до кој интерфејс дошол пакетот, односно на кој клиент (VRF) припаѓа и ја проверува адресата на примачот со рутирачката табела на овој клиент.
- Откако откри дека примачот на истата машина е на различна порта, vRouter едноставно го испраќа пакетот до него без никакви дополнителни заглавија - за овој случај, vRouter веќе има запис ARP.
Во овој случај, пакетот не влегува во физичката мрежа - се пренасочува во vRouter.
Контролен авион
Кога виртуелната машина ќе стартува, хипервизорот му кажува:
- Нејзината сопствена IP адреса.
- Стандардната рута е преку IP адресата на vRouter на оваа мрежа.
Хипервизорот известува до vRouter преку специјален API:
- Што ви е потребно за да креирате виртуелен интерфејс.
- Каков вид на виртуелна мрежа (VM) треба да создаде?
- На кој VRF (VN) да се поврзе.
- Статичен ARP запис за овој VM - кој интерфејс се наоѓа зад неговата IP адреса и со која MAC адреса е поврзан.
Повторно, вистинската процедура за интеракција е поедноставена заради разбирање на концептот.
Така, vRouter ги гледа сите VM на еден клиент на дадена машина како директно поврзани мрежи и може самиот да рутира меѓу нив.
Но, VM0 и VM1 припаѓаат на различни клиенти и, соодветно, се во различни табели на vRouter.
Дали тие можат директно да комуницираат меѓу себе зависи од поставките на vRouter и мрежниот дизајн.
На пример, ако VM-ите на двата клиенти користат јавни адреси или NAT се појавува на самиот vRouter, тогаш може да се направи директно рутирање до vRouter.
Во спротивна ситуација, можно е да се вкрстат адресни простори - треба да поминете низ NAT сервер за да добиете јавна адреса - ова е слично на пристапот до надворешни мрежи, за кои се дискутира подолу.
Комуникација помеѓу VM лоцирани на различни физички машини
Рамнина на податоци
- Почетокот е потполно ист: VM-0 испраќа пакет со дестинација VM-7 (172.17.3.2) како стандардно.
- vRouter го прима и овој пат гледа дека дестинацијата е на друга машина и е достапна преку Tunnel0.
- Прво, закачува етикета MPLS што го идентификува далечинскиот интерфејс, така што на задната страна vRouter може да одреди каде да го постави овој пакет без дополнителни пребарување.
- Tunnel0 има извор 10.0.0.2, дестинација: 10.0.1.2.
vRouter додава GRE (или UDP) заглавија и нова IP адреса на оригиналниот пакет. - Рутирачката табела vRouter има стандардна рута преку адресата ToR1 10.0.0.1. Таму го праќа.
- ToR1, како член на мрежата Underlay, знае (на пример, преку OSPF) како да стигне до 10.0.1.2 и го испраќа пакетот долж рутата. Забележете дека ECMP е овозможен овде. На илустрацијата има два следни хопови и различни нишки ќе бидат подредени во нив по хаш. Во случај на вистинска фабрика, поверојатно ќе има 4 следни хопови.
Во исто време, тој не треба да знае што има под надворешното заглавие на IP. Тоа е, всушност, под IP може да има сендвич од IPv6 преку MPLS преку етернет преку MPLS преку GRE над над грчки.
- Според тоа, од страната на примачот, 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 за да го пренесе методот на енкапсулација или .
Во исто време, конфигурацијата на мрежата Underlay не се менува на кој било начин, што, патем, е многу потешко да се автоматизира и полесно да се скрши со незгодно движење.
Излез во надворешниот свет
Некаде симулацијата мора да заврши, а вие треба да излезете од виртуелниот свет во реалниот. И ви треба портал за говорница.
Се практикуваат два пристапа:
- Инсталиран е хардверски рутер.
- Лансиран е апарат кој ги имплементира функциите на рутерот (да, по SDN, наидовме и на VNF). Ајде да го наречеме виртуелна порта.
Предноста на вториот пристап е евтина хоризонтална приспособливост - нема доволно моќ - лансиравме друга виртуелна машина со портал. На која било физичка машина, без да барате слободни лавици, единици, излезна моќност, да го купите самиот хардвер, да го транспортирате, да го инсталирате, да го префрлите, да го конфигурирате, а потоа да ги менувате неисправните компоненти во него.
Недостатоците на виртуелната порта се тоа што единицата на физичкиот рутер е сè уште помоќна од виртуелната машина со повеќе јадра, а нејзиниот софтвер, прилагоден на сопствената хардверска база, работи многу постабилно (Нема). Исто така, тешко е да се негира фактот дека хардверскиот и софтверскиот комплекс едноставно работи, бара само конфигурација, додека лансирањето и одржувањето на виртуелна порта е задача за силни инженери.
Со една нога, портата гледа во виртуелната мрежа Overlay, како обична виртуелна машина, и може да комуницира со сите други VM. Во исто време, може да ги прекине мрежите на сите клиенти и, соодветно, да изврши рутирање меѓу нив.
Со другата нога, портата гледа во основната мрежа и знае како да влезе на Интернет.
Рамнина на податоци
Тоа е, процесот изгледа вака:
- VM-0, откако стандардно го постави истиот vRouter, испраќа пакет со дестинација во надворешниот свет (185.147.83.177) до интерфејсот eth0.
- vRouter го прима овој пакет и ја бара одредишната адреса во рутирачката табела - ја наоѓа стандардната рута низ портата VNGW1 низ Тунел 1.
Тој исто така гледа дека ова е тунел GRE со SIP 10.0.0.2 и DIP 10.0.255.2, а исто така треба прво да ја закачи MPLS ознаката на овој клиент, што го очекува VNGW1. - vRouter го пакува почетниот пакет со MPLS, GRE и нови IP заглавија и стандардно го испраќа до ToR1 10.0.0.1.
- Основната мрежа го доставува пакетот до портата VNGW1.
- Портата VNGW1 ги отстранува заглавјата на тунелирањето GRE и MPLS, ја гледа адресата на дестинацијата, ја консултира својата рутирачка табела и разбира дека е насочена кон Интернет - односно преку Целосен преглед или Стандардно. Доколку е потребно, врши NAT превод.
- Може да има редовна IP мрежа од VNGW до границата, што е малку веројатно.
Може да има класична MPLS мрежа (IGP+LDP/RSVP TE), може да има задна ткаенина со BGP LU или GRE тунел од VNGW до границата преку IP мрежа.
Како и да е, VNGW1 ги извршува потребните инкапсулации и го испраќа почетниот пакет кон границата.
Сообраќајот во спротивна насока се одвива низ истите чекори во спротивен редослед.
- Границата го испушта пакетот на VNGW1
- Го соблекува, ја гледа адресата на примачот и гледа дека е достапен преку тунелот Tunnel1 (MPLSoGRE или MPLSoUDP).
- Соодветно на тоа, тој прикачува ознака MPLS, заглавие GRE/UDP и нова IP и ја испраќа до својот ToR3 10.0.255.1.
Адресата за дестинација на тунелот е IP адресата на vRouter зад кој се наоѓа целниот VM - 10.0.0.2. - Основната мрежа го доставува пакетот до саканиот vRouter.
- Целниот vRouter чита GRE/UDP, го идентификува интерфејсот користејќи ја ознаката MPLS и испраќа гол IP пакет до неговиот TAP интерфејс поврзан со eth0 на VM.
Контролен авион
VNGW1 воспоставува BGP соседство со SDN контролер, од кој ги добива сите информации за рутирање за клиентите: која IP адреса (vRouter) се наоѓа зад кој клиент, и со која ознака MPLS е идентификувана.
Слично на тоа, тој самиот го информира контролорот SDN за стандардната рута со ознаката на овој клиент, означувајќи се себеси како nexthop. И тогаш овој стандарден пристигнува на vRouters.
На VNGW, обично се случува агрегација на рути или NAT превод.
А во другата насока, ја испраќа токму оваа збирна рута до сесијата со граници или рефлектори на маршрутата. И од нив ја добива стандардната рута или Full-View, или нешто друго.
Во однос на инкапсулација и размена на сообраќај, VNGW не се разликува од vRouter.
Ако малку го проширите опсегот, тогаш можете да додадете други мрежни уреди на VNGW и vRouters, како што се заштитни ѕидови, фарми за чистење или збогатување сообраќај, IPS итн.
И со помош на последователно креирање на VRFs и правилно објавување на маршрутите, можете да го принудите сообраќајот да се врти како што сакате, што се нарекува Service Chaining.
Односно, и овде SDN контролерот делува како Route-Reflector помеѓу VNGWs, vRouters и другите мрежни уреди.
Но, всушност, контролорот, исто така, објавува информации за ACL и PBR (Рутирање базирано на политика), што предизвикува индивидуалните сообраќајни текови да се одвиваат поинаку отколку што им кажува маршрутата.
Често поставувани прашања
Зошто продолжувате да ја давате забелешката GRE/UDP?
Па, генерално, ова може да се каже дека е специфично за волфрамската ткаенина - воопшто не мора да го земате предвид.
Но, ако го земеме, тогаш самиот TF, додека сè уште OpenContrail, ги поддржа двете енкапсулации: MPLS во GRE и MPLS во UDP.
UDP е добар затоа што во изворната порта е многу лесно да се шифрира хаш функција од оригиналната IP+Proto+Port во неговото заглавие, што ќе ви овозможи да направите балансирање.
Во случајот со GRE, за жал, постојат само надворешни IP и GRE заглавија, кои се исти за целиот инкапсулиран сообраќај и не се зборува за балансирање - малку луѓе можат да погледнат толку длабоко во пакетот.
До одредено време, рутерите, ако знаеја да користат динамични тунели, тоа го правеа само во MPLSoGRE, а дури неодамна научија да користат MPLSoUDP. Затоа, секогаш мораме да забележеме за можноста за две различни инкапсулации.
За волја на вистината, вреди да се напомене дека TF целосно поддржува L2 поврзување користејќи VXLAN.
Ветивте дека ќе повлечете паралели со OpenFlow.
Тие навистина го бараат тоа. vSwitch во истиот OpenStack прави многу слични работи, користејќи VXLAN, кој, патем, има и UDP заглавие.
Во рамнината на податоци тие работат приближно исто; контролната рамнина значително се разликува. Волфрамската ткаенина користи XMPP за доставување информации за рутирање до vRouter, додека OpenStack работи Openflow.
Можете ли да ми кажете малку повеќе за vRouter?
Поделен е на два дела: vRouter Agent и vRouter Forwarder.
Првиот работи во корисничкиот простор на оперативниот систем домаќин и комуницира со контролерот SDN, разменувајќи информации за маршрути, VRF и ACL.
Вториот имплементира Data Plane - обично во Kernel Space, но може да работи и на SmartNIC - мрежни картички со процесор и посебен програмабилен чип за префрлување, што ви овозможува да го отстраните оптоварувањето од процесорот на машината домаќин и да ја направите мрежата побрза и повеќе предвидливи.
Друго можно сценарио е дека vRouter е апликација DPDK во кориснички простор.
vRouter Agent испраќа поставки до vRouter Forwarder.
Што е виртуелна мрежа?
На почетокот на статијата за VRF спомнав дека секој закупец е врзан за својот VRF. И ако ова беше доволно за површно разбирање на работата на преклопната мрежа, тогаш на следната повторување е неопходно да се направат појаснувања.
Вообичаено, во механизмите за виртуелизација, ентитетот Виртуелна мрежа (може да го сметате ова за соодветна именка) се воведува одделно од клиентите/закупците/виртуелните машини - сосема независна работа. И оваа виртуелна мрежа веќе може да се поврзе преку интерфејси со еден станар, со друг, со двајца или каде било. Така, на пример, Service Chaining се имплементира кога сообраќајот треба да се помине низ одредени јазли во потребната низа, едноставно со креирање и поврзување на Виртуелни мрежи во правилна секвенца.
Затоа, како таква, не постои директна кореспонденција помеѓу Виртуелната мрежа и закупецот.
Заклучок
Ова е многу површен опис на работата на виртуелна мрежа со преклоп од домаќинот и SDN контролер. Но, без разлика која платформа за виртуелизација ќе ја изберете денес, таа ќе работи на сличен начин, било да е тоа VMWare, ACI, OpenStack, CloudStack, Tungsten Fabric или Juniper Contrail. Тие ќе се разликуваат во типовите на инкапсулации и заглавија, протоколи за доставување информации до крајните мрежни уреди, но принципот на софтверски конфигурирана мрежа за преклопување која работи врз релативно едноставна и статична подлога мрежа ќе остане ист.
Можеме да кажеме дека денес SDN базиран на мрежа за преклопување го освои полето за создавање приватен облак. Сепак, ова не значи дека Openflow нема место во современиот свет - се користи во OpenStacke и во истиот VMWare NSX, колку што знам Google го користи за поставување на подземната мрежа.
Подолу дадов линкови до подетални материјали доколку сакате да го проучите проблемот подлабоко.
А што е со нашата подлога?
Но, генерално, ништо. Тој не го промени целиот пат. Сè што треба да направи во случај на преклопување од домаќинот е да ги ажурира маршрутите и ARP-ите додека vRouter/VNGW се појавуваат и исчезнуваат и пренесува пакети меѓу нив.
Ајде да формулираме листа на барања за мрежата Underlay.
- Бидете способни да користите некој вид протокол за рутирање, во нашата ситуација - BGP.
- Имајте широк опсег, по можност без претплата, за да не се губат пакетите поради преоптоварувања.
- Поддршката за ECMP е составен дел од ткаенината.
- Бидете во можност да обезбедите QoS, вклучувајќи незгодни работи како ECN.
- Поддршката на NETCONF е основа за иднината.
Овде посветив многу малку време на работата на самата мрежа Underlay. Тоа е затоа што подоцна во серијата ќе се фокусирам на тоа, а ќе го допреме само Overlay во минување.
Очигледно, строго нè ограничувам сите нас користејќи како пример DC мрежа изградена во фабрика на Cloz со чисто рутирање на IP и преклоп од домаќинот.
Сепак, уверен сум дека секоја мрежа што има дизајн може да се опише во формални термини и да се автоматизира. Едноставно, мојата цел овде е да ги разберам пристапите кон автоматизацијата и да не ги збунам сите со решавање на проблемот во општа форма.
Како дел од АДСМ, Роман Горџ и јас планираме да објавиме посебен број за виртуелизација на компјутерската моќ и нејзината интеракција со мрежната виртуелизација. Останете во контакт.
Корисни линкови
- .
- . 6 часа за Yandex.Cloud, кој исто така ја покрива виртуелната мрежа на TF.
- .
- . Зборува за целата мрежа на DC, вклучително и Underlay, Overlay, пристапи за мулти-домаќинство и управување.
Ви благодарам
- - поранешен водител на подкастот linkmeup и сега експерт во областа на облак платформи. За коментари и уредувања. Па, во блиска иднина ја чекаме неговата подлабока статија за виртуелизација.
- - мој колега и експерт во областа на развој на виртуелни мрежи. За коментари и уредувања.
- - мој колега и експерт во областа на волфрамска ткаенина. За коментари и уредувања.
- — илустраторско поврзување. За KDPV.
- Александар Лимонов. За „автоматскиот“ мем.
Извор: www.habr.com