В предишен брой Описах рамката за мрежова автоматизация. Според някои хора дори този първи подход към проблема вече е поставил някои въпроси на рафтовете. И това много ме радва, защото целта ни в цикъла не е да цапаме ansible със скриптове на Python, а да изградим система.

Същата рамка определя реда, по който ще се занимаваме с проблема.
И мрежовата виртуализация, на която е посветен този брой, не се вписва в темата на ADSM, където анализираме автоматизацията.

Но нека го погледнем от друг ъгъл.

Много услуги използват една и съща мрежа от дълго време. В случая на телекомуникационен оператор това са например 2G, 3G, LTE, широколентов достъп и B2B. В случай на DC: свързаност за различни клиенти, интернет, блоково съхранение, обектно съхранение.

И всички услуги изискват изолация една от друга. Така се появиха наслагващите мрежи.

И всички услуги не искат да чакат човек да ги конфигурира ръчно. Така се появиха оркестраторите и SDN.

Първият подход за систематична автоматизация на мрежата, или по-скоро част от нея, отдавна е възприет и внедрен на много места: VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.

Нека да го разгледаме днес.

Съдържание

• причини
• терминология
• Подложка - физическа мрежа
• Overlay - виртуална мрежа
  • Наслагване с ToR
  • Наслагване от хост
  • На примера на волфрамова тъкан
    • Комуникация в рамките на една физическа машина
    • Комуникация между виртуални машини, разположени на различни физически машини
    • Изход към външния свят

• Често задавани въпроси
• Заключение
• Полезни връзки

причини

И тъй като говорим за това, си струва да споменем предпоставките за мрежова виртуализация. Всъщност този процес не е започнал вчера.

Вероятно неведнъж сте чували, че мрежата винаги е била най-инертната част от всяка система. И това е вярно във всеки смисъл. Мрежата е основата, на която се крепи всичко и е доста трудно да се правят промени в нея - услугите не толерират, когато мрежата не работи. Често извеждането от експлоатация на единичен възел може да добави към повечето приложения и да засегне много клиенти. Това е отчасти причината екипът на мрежата да устои на всяка промяна - защото сега някак работи (може дори да не знаем как), и тук трябва да конфигурирате нещо ново и не се знае как ще се отрази на мрежата.

За да не чакат мрежовите мрежи да хвърлят VLAN и да не регистрират никакви услуги на всеки мрежов възел, хората излязоха с идеята да използват наслагвания - мрежи с наслагване - от които има голямо разнообразие: GRE, IPinIP, MPLS, MPLS L2 / L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE и др.

Тяхната привлекателност се крие в две прости неща:

• Само крайните възли са конфигурирани - транзитните възли не трябва да се докосват. Това значително ускорява процеса и понякога дори ви позволява да изключите отдела за мрежова инфраструктура от процеса на въвеждане на нови услуги.
• Товарът е скрит дълбоко в заглавките - транзитните възли не трябва да знаят нищо за него, за адресиране на хостове, маршрути на насложената мрежа. И това означава, че трябва да съхранявате по-малко информация в таблици, което означава да вземете по-просто / по-евтино устройство.

В този не съвсем пълен брой не планирам да анализирам всички възможни технологии, а по-скоро да опиша рамката за работа на мрежи с наслагване в DC.

Цялата серия ще опише центъра за данни, състоящ се от редове от същия тип стелажи, в които е инсталиран същия сървърен хардуер.

Това оборудване работи с виртуални машини/контейнери/без сървър, които изпълняват услуги.

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

В цикъл сървър Ще се позова на програмата, която реализира сървърната страна на комуникацията клиент-сървър.

Обадете се на физически машини в шкафове сървъри не ние ще.

физическа машина - x86 компютър, инсталиран в шкаф. Най-често използваме термина домакин. Така че нека го наречем "кола"или домакин.

хипервизор — приложение, работещо на физическа машина, което емулира физическите ресурси, на които работят виртуалните машини. Понякога в литературата и в мрежата думата "хипервайзор" се използва като синоним на "хост".

Виртуална машина - операционна система, работеща на физическа машина върху хипервайзор. За нас в този цикъл не е толкова важно дали всъщност е виртуална машина или просто контейнер. Нека го наречем "VM«

наемател - широко понятие, което в тази статия ще дефинирам като отделна услуга или отделен клиент.

Много наемане или multi-tenancy – използването на едно и също приложение от различни клиенти/услуги. В същото време изолацията на клиентите един от друг се постига благодарение на архитектурата на приложението, а не на отделно стартирани екземпляри.

ToR - горната част на превключвателя Rack - комутатор, монтиран в стелаж, към който са свързани всички физически машини.

В допълнение към топологията на ToR, различни доставчици практикуват End of Row (EoR) или Middle of Row (въпреки че последното е пренебрежителна рядкост и не съм виждал MoR съкращения).

подложна мрежа или основна мрежа или подложка - физическа мрежова инфраструктура: комутатори, рутери, кабели.

наслагваща мрежа или overlay network или overlay - виртуална мрежа от тунели, която работи върху физическата.

L3 фабрика или IP фабрика е невероятно изобретение на човечеството, което ви позволява да не повтаряте STP и да не учите TRILL за интервюта. Концепция, при която цялата мрежа до нивото на достъп е изключително L3, без VLAN и съответно огромни разтегнати броудкаст домейни. Откъде идва думата "фабрика", ще разберем в следващата част.

SDN — Софтуерно дефинирана мрежа. Едва ли има нужда от представяне. Подход за управление на мрежата, когато промените в мрежата се извършват не от човек, а от програма. Обикновено означава преместване на Control Plane извън крайните мрежови устройства към контролера.

NFV - Виртуализация на мрежови функции - виртуализация на мрежови устройства, като се предполага, че част от мрежовите функции могат да се изпълняват като виртуални машини или контейнери, за да се ускори въвеждането на нови услуги, организацията на Service Chaining и по-лесното хоризонтално мащабиране.

VNF — Функция за виртуална мрежа. Конкретно виртуално устройство: рутер, комутатор, защитна стена, NAT, IPS/IDS и др.

Сега умишлено опростявам описанието до конкретна реализация, за да не объркам читателя твърде много. За по-обмислено четене го препращам към раздела Позоваването. Освен това Roma Gorge, който критикува тази статия за неточности, обещава да напише отделен брой за технологиите за виртуализация на сървъри и мрежи, по-задълбочени и внимателни към детайлите.

Повечето мрежи днес могат изрично да бъдат разделени на две части:

подпирам — физическа мрежа със стабилна конфигурация.
Подложка - абстракция над Underlay за изолиране на наематели.

Това важи както за случая с DC (който ще анализираме в тази статия), така и за ISP (който няма да анализираме, защото вече беше в SDSM). С корпоративните мрежи, разбира се, ситуацията е малко по-различна.

Снимка на фокус върху мрежата:

подпирам

Основата е физическа мрежа: хардуерни превключватели и кабели. Устройствата в подложката знаят как да стигнат до физическите машини.

Той разчита на стандартни протоколи и технологии. Не на последно място защото хардуерните устройства и до ден днешен работят върху патентован софтуер, който не позволява нито програмиране на чипове, нито имплементиране на техните протоколи, съответно е необходима съвместимост с други доставчици и стандартизация.

Но някой като Google може да си позволи да разработи свои собствени комутатори и да изостави конвенционалните протоколи. Но LAN_DC не е Google.

Underlay се променя сравнително рядко, тъй като целта му е основна IP свързаност между физически машини. Underlay не знае нищо за услугите, работещи върху него, клиенти, наематели - трябва само да достави пакета от една машина на друга.
Подложката може да бъде така:

• IPv4+OSPF
• IPv6+ISIS+BGP+L3VPN
• L2+ТРЕЛКА
• L2+STP

Мрежата Underlay се конфигурира по класическия начин: CLI/GUI/NETCONF.

Ръчно, скриптове, собствени помощни програми.

Следващата статия от цикъла ще бъде посветена по-подробно на Андерлей.

Подложка

Overlay е виртуална мрежа от тунели, опънати върху Underlay, тя позволява на виртуалните машини на един клиент да комуникират помежду си, като същевременно осигурява изолация от други клиенти.

Клиентските данни са капсулирани в някакъв вид тунелна заглавка за предаване през обществената мрежа.

Така виртуалните машини на един клиент (една услуга) могат да комуникират помежду си чрез Overlay, без дори да знаят какъв път всъщност поема пакетът.

Наслагването може да бъде така, както споменах по-горе:

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

Мрежата с наслагване обикновено се конфигурира и поддържа чрез централен контролер. От него конфигурацията, Control Plane и Data Plane се доставят до устройства, които са ангажирани с маршрутизиране и капсулиране на клиентски трафик. малко по-долу Нека да разгледаме това с примери.

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

Има два фундаментално различни подхода за организиране на мрежа с наслагване:

1. Наслагване с ToR
2. Наслагване от хост

Наслагване с ToR

Наслагването може да започне от превключвател за достъп (ToR) в шкаф, както се случва например в случай на VXLAN тъкан.

Това е изпитан във времето механизъм в мрежите на ISP и всички доставчици на мрежово оборудване го поддържат.

В този случай обаче превключвателят ToR трябва да може да разделя съответно различните услуги и мрежовият администратор трябва да си сътрудничи до известна степен с администраторите на виртуалната машина и да прави промени (макар и автоматично) в конфигурацията на устройството.

Тук ще насоча читателя към статия за VxLAN на Хабре наш стар приятел @bormoglotx.
В това презентации с ENOG подходи за изграждане на DC мрежа с EVPN VXLAN фабрика са описани подробно.

И за по-пълно потапяне в реалността, можете да прочетете книгата на tsiska Модерна, отворена и мащабируема структура: 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 тунелиране.

Малко повече за vRouter има в края на статията.

Всяка виртуална машина, разположена на хипервайзор, се свързва с vRouter на тази машина чрез TAP интерфейс.

TAP - Терминална точка за достъп - виртуален интерфейс в ядрото на Linux, който позволява мрежово взаимодействие.

Ако зад vRouter има няколко мрежи, тогава за всяка от тях се създава виртуален интерфейс, на който се присвоява IP адрес - това ще бъде адресът на шлюза по подразбиране.
Всички мрежи на един клиент са поставени в едно VRF разширение (една маса), различни - в различни.
Тук ще направя уговорка, че всичко не е толкова просто и ще изпратя любознателния читател до края на статията.

За да могат vRouters да комуникират помежду си и, съответно, виртуалните машини зад тях, те обменят информация за маршрутизиране чрез SDN контролер.

За да излезете във външния свят, има изходна точка от матрицата - шлюзът на виртуалната мрежа VNGW — Шлюз за виртуална мрежа (моят срок).

Сега нека да разгледаме примери за комуникации - и ще има яснота.

Комуникация в рамките на една физическа машина

VM0 иска да изпрати пакет до VM2. Нека засега приемем, че това е виртуална машина с един клиент.

Равнина на данни

1. VM-0 има маршрут по подразбиране към своя интерфейс eth0. Пакетът се изпраща там.
   Този интерфейс eth0 всъщност е свързан виртуално към виртуалния рутер vRouter чрез интерфейса tap0 TAP.
2. vRouter анализира на кой интерфейс е дошъл пакетът, тоест на кой клиент (VRF) принадлежи, проверява адреса на получателя с таблицата за маршрутизиране на този клиент.
3. След като установи, че получателят е на същата машина зад различен порт, vRouter просто изпраща пакета до него без допълнителни заглавки - в този случай vRouter вече има ARP запис.

Пакетът в този случай не влиза във физическата мрежа - той се маршрутизира вътре във vRouter.

Контролна равнина

Когато виртуалната машина се стартира, хипервайзорът й казва:

• Нейният собствен IP адрес.
• Маршрутът по подразбиране е през IP адреса на vRouter в тази мрежа.

Хипервайзорът докладва на vRouter чрез специален API:

• Какво ви е необходимо, за да създадете виртуален интерфейс.
• От какво се нуждае (VM), за да създаде виртуална мрежа.
• Към какъв VRF го (VN) да се свърже.
• Статичен ARP запис за тази виртуална машина - на кой интерфейс се намира нейният IP адрес и към кой MAC адрес е свързан.

И отново, действителната процедура за взаимодействие е опростена в името на разбирането на концепцията.

По този начин vRouter вижда всички VM на един клиент на тази машина като директно свързани мрежи и може да се маршрутизира между тях.

Но VM0 и VM1 принадлежат на различни клиенти, съответно са в различни vRouter таблици.

Дали могат да комуникират директно един с друг зависи от настройките на vRouter и мрежовия дизайн.
Например, ако виртуалните машини и на двата клиента използват публични адреси или NAT се появява на самия vRouter, тогава може да се направи и директно маршрутизиране към vRouter.

В обратната ситуация е възможно пресичане на адресни пространства - трябва да преминете през NAT сървър, за да получите публичен адрес - това е подобно на достъпа до външни мрежи, които са обсъдени по-долу.

Комуникация между виртуални машини, разположени на различни физически машини

Равнина на данни

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 над над над Greek.

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-в-GRE или MPLS-в-UDP.

В същото време конфигурацията на мрежата Underlay не се променя по никакъв начин, която, между другото, е с порядък по-трудна за автоматизиране и по-лесна за разбиване с неудобно движение.

Изход към външния свят

Някъде симулацията трябва да приключи и вие трябва да излезете от виртуалния свят в реалния. И имате нужда от шлюз за телефонни автомати.

Практикуват се два подхода:

1. Инсталиран е хардуерен рутер.
2. Стартира се всяко устройство, което изпълнява функциите на рутера (да, след SDN срещнахме и VNF). Нека го наречем виртуален портал.

Предимството на втория подход в евтината хоризонтална мащабируемост - няма достатъчно мощност - пуснахме друга виртуална машина с шлюз. На всяка физическа машина, без да е необходимо да търсите свободни стелажи, модули, електрически контакти, купете самото парче желязо, транспортирайте го, инсталирайте, превключете, конфигурирайте и след това също сменете дефектните компоненти в него.

Недостатъците на виртуалния шлюз са, че единица от физически рутер все още е с порядъци по-мощна от многоядрена виртуална машина и неговият софтуер, адаптиран към собствената му хардуерна база, работи много по-стабилно (не). Също така е трудно да се отрече фактът, че софтуерно-хардуерният комплекс просто работи, изисквайки само конфигурация, докато стартирането и поддържането на виртуален шлюз е занимание за силни инженери.

С един крак шлюзът гледа във виртуалната мрежа на Overlay, като нормална виртуална машина, и може да взаимодейства с всички други виртуални машини. В същото време може да терминира мрежите на всички клиенти върху себе си и съответно да извършва маршрутизация между тях.

С другия крак шлюзът вече гледа в опорната мрежа и знае как да излезе в интернет.

Равнина на данни

Така че процесът изглежда така:

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, вижда адреса на местоназначението, прави справка със своята таблица за маршрутизиране и разбира, че е насочен към Интернет - това означава чрез пълен изглед или по подразбиране. Извършва 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.
   Адресът на местоназначение на тунела е 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 транслация.

И в другата посока, в сесия с граници или Route Reflectors, дава точно този агрегиран маршрут. И от тях получава маршрута по подразбиране или Full-View, или нещо друго.

По отношение на капсулиране и обмен на трафик, VNGW не се различава от vRouter.
Ако разширите малко обхвата, тогава към VNGW и vRouters могат да се добавят други мрежови устройства, като защитни стени, ферми за почистване или обогатяване на трафика, IPS и т.н.

И с помощта на последователно създаване на VRF и правилното обявяване на маршрути, можете да направите цикъл на трафика по начина, по който искате, което се нарича Service Chaining.

Тоест тук SDN контролерът действа като Route-Reflector между VNGW, vRouters и други мрежови устройства.

Но всъщност контролерът издава повече информация за ACL и PBR (маршрутизиране, базирано на правила), принуждавайки отделните потоци от трафик да вървят по различен начин, отколкото им казва маршрутът.

Често задавани въпроси

Защо винаги правите забележка GRE / UDP?

Е, като цяло това може да се каже, че е специфично за Tungsten Fabric - изобщо не можете да го вземете предвид.

Но ако го вземете, тогава самият 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 хедър.

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

Можете ли да ми кажете малко повече за vRouter?
Той е разделен на две части: vRouter Agent и vRouter Forwarder.

Първият работи в потребителското пространство на хост ОС и комуникира със SDN контролера, като обменя информация за маршрути, VRF и ACL.

Вторият внедрява Data Plane - обикновено в Kernel Space, но може да работи и на SmartNIC - мрежови карти с CPU и отделен програмируем превключващ чип, който ви позволява да свалите натоварването от CPU на хост машината и да направите мрежата по-бърза и по-предвидим.

Друг сценарий е възможен, когато vRouter е DPDK приложение в потребителското пространство.

Агентът на vRouter изтегля настройките на 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.

1. Да можем да използваме някакъв протокол за маршрутизиране, в нашата ситуация - BGP.
2. Имайте широка лента, за предпочитане без свръхабонамент, така че пакетите да не се губят поради претоварване.
3. Поддръжката на ECMP е неразделна част от фабриката.
4. Бъдете в състояние да осигурите QoS, включително трудни неща като ECN.
5. Поддръжка на NETCONF - резерв за бъдещето.

Посветих много малко време тук на работата на самата мрежа Underlay. Това е така, защото ще се съсредоточа върху него по-късно в поредицата и ще се докоснем до Overlay само мимоходом.

Очевидно силно ограничавам всички ни, използвайки като пример DC мрежа, изградена във фабриката на Klose с чисто IP маршрутизиране и наслагване от хоста.

Сигурен съм обаче, че всяка мрежа, която има дизайн, може да бъде описана формално и автоматизирана. Просто преследвам целта тук да разбера подходите към автоматизацията, а не да объркам всички като цяло, решавайки проблема по общ начин.

Като част от ADSM, Роман Гордж и аз планираме да публикуваме отделен брой за виртуализацията на изчислителната мощност и нейното взаимодействие с мрежовата виртуализация. Поддържате връзка.

Полезни връзки

• Волфрамова тъканна архитектура.
• относно: облак. 6 часа за Yandex.Cloud, включително виртуалната мрежа на TF.
• Какво е Open vSwitch?
• Въведение във VxLAN.
• RFC 7348. Виртуална разширяема локална мрежа (VXLAN): Рамка за наслагване на виртуализирани мрежи от слой 2 върху мрежи от слой 3.
  
• Подход Scaleway към VXLAN EVPN Fabric. Той разказва за цялата DC мрежа, включително Underlay, Overlay, подходи за мулти-насочване и управление.

Благодаря

• Роман Горга Бивш хост на подкаст linkmeup и сега експерт по облачна платформа. За коментари и редакции. Е, очакваме неговата по-задълбочена статия за виртуализацията в близко бъдеще.
• Александър Шалимов - на моя колега и експерт в областта на разработката на виртуални мрежи. За коментари и редакции.
• Валентин Синицин — към моя колега и експерт по волфрамова тъкан. За коментари и редакции.
• Артьом Чернобай — илюстратор linkmeup. За KDPV.
• Александър Лимонов. За мемето "автомат".

Източник: www.habr.com