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

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

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

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

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

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

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

С него днес ще се занимаем.

Съдържание

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

• ЧЗВ
• Заключение
• Полезни линкове

Причини

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

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

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

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

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

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

Цялата серия ще описва дата център, състоящ се от редици еднотипни стойки, в които е инсталирано идентично сървърно оборудване.

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

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

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

Физическите машини в стойките ще наричаме сървъри не ще.

Физическа машина — x86 компютър, инсталиран в стойка. Най-често използван термин хост. Така и ще я наричаме «машина» или хост.

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

Виртуална машина — операционна система, работеща на физическа машина над хипервизора. За нас в рамките на този цикъл не е толкова важно, дали всъщност това е виртуална машина или просто контейнер. Ще наричаме това «ВМ«

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

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

ToR — комутатор в горната част на рафта — комутатор, инсталиран в рафта, към който са свързани всички физически машини.

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

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

Наложена мрежа или оверлей — виртуална мрежа от тунели, работеща над физическата.

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

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

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

VNF — Virtual Network Function. Конкретно виртуално устройство: маршрутизатор, комутатор, защитна стена, NAT, IPS/IDS и т.н.

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

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

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

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

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

Подложна

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

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

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

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

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

Underlay мрежата се настройва по класически начин: CLI/GUI/NETCONF.

На ръка, чрез скриптове, проприетарни утилити.

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

Наложена

Overlay — виртуална мрежа от тунели, опъната над Underlay, която позволява на ВМ на един клиент да комуникират помежду си, осигурявайки изолация от другите клиенти.

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

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

Overlay може да изглежда, както споменах по-горе:

• GRE тунел
• VXLAN
• EVPN
• L3VPN
• GENEVE

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

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

Съществуват два принципно различаващи се подхода за организиране на Overlay мрежа:

1. Overlay от ToR
2. Overlay от хост

Overlay от ToR

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

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

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

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

А за по-пълно потапяне в реалността, може да прочетете книгата на Cisco A Modern, Open, and Scalable Fabric: VXLAN EVPN.

Искам да подчертая, че VXLAN е само метод на инкапсулация и терминализация на тунелите може да се извърши не на ToR, а на хоста, както е случая с OpenStack, например.

Въпреки това, VXLAN фабрика, където overlay започва на ToR, е един от утвърдените дизайни на оверлейна мрежа.

Overlay от хост

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

За целта е необходимо със сигурност да се стартира специално приложение на хостовете, но това си струва.

Първо, да стартирате клиент на Linux машина е по-лесно или, да кажем, — изобщо възможно — докато на комутатора вероятно ще се наложи да се обърнете към собствени SDN решения, което убива идеята за многопроизводителност.

На второ място, ToR комутаторът в този случай може да остане максимално прост, както по отношение на Control Plane, така и на Data Plane. Наистина — с SDN контролер не е необходимо да комуникира, и да съхранява мрежи/ARP на всички свързани клиенти — достатъчно е да знаете IP адреса на физическата машина, което значително улеснява таблиците за комутация/маршрутизация.

В серията АДСМ избирам подхода за оверлей с хоста — оттук нататък ще говорим само за него и вече няма да се връщаме към VXLAN фабриката.

Най-лесно е да обсъдим примерите. И като опитен субект ще вземем OpenSource SDN платформата OpenContrail, вече известна като Tungsten Fabric.

В края на статията ще споделя някои размисли относно аналогията с OpenFlow и OpenvSwitch.

На примера на Tungsten Fabric

На всяка физическа машина има vRouter — виртуален рутер, който познава свързаните към него мрежи и на кои клиенти принадлежат те — в същността си — PE-рутер. За всеки клиент той поддържа изолирана таблица за маршрутизация (виж VRF). И самият vRouter прави Overlay тунелиране.

По-подробно за vRouter — в края на статията.

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

TAP — Terminal Access Point — виртуален интерфейс в ядрото на Linux, който позволява осъществяване на мрежово взаимодействие.

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

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

За да се излезе навън, съществува изходна точка от матрицата — шлюз на виртуалната мрежа VNGW — Virtual Network GateWay (термин мой).

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

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

VM0 иска да изпрати пакет на VM2. Предположим засега, че това са ВМ на един клиент.

Data Plane

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

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

Control Plane

Хипервизорът при стартиране на виртуалната машина уведомява:

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

На vRouter-а чрез специално API хипервизорът съобщава:

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

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

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

ВМ0 и ВМ1 принадлежат на различни клиенти и съответно се намират в различни таблици на vRouter-а.

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

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

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

Data Plane

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. На илюстрацията има два следващи хопа и различните потоци ще бъдат разпределени в тях по хеширане. В случай на истинска фабрика, тук вероятно ще има девет хопа.

   При това не е нужно да знае какво се намира под външното IP заглавие. Тоест, всъщност под IP може да има слой от IPv6 над MPLS над Ethernet над MPLS над GRE и т.н.

7. Съответно, на приемната страна vRouter сваля GRE и по MPLS етикета разбира в кой интерфейс трябва да предаде този пакет, разглобява го и изпраща в първоначалния му вид на получателя.

Control Plane

При стартиране на машината се извършва всичко това, което беше описано по-горе.

И плюс още следното:

• За все клиенти vRouter разписва MPLS-етикет. Това е сервизен етикет L3VPN, по който клиентите ще бъдат разделени в рамките на едно физическо устройство.
  

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

• vRouter установява връзка с SDN контролера по протокол BGP (или на подобен на него — в случая TF това е XMPP 0_o).
• Чрез тази сесия vRouter информира SDN контролера за маршрутите до свързаните мрежи:
  • Адрес на мрежата
  • Метод на инкапсулация (MPLSoGRE, MPLSoUDP, VXLAN)
  • MPLS-етикет на клиента
  • Собствения си IP адрес като nexthop

• SDN контролерът получава такива маршрути от всички свързани vRouter-и и ги отражава на другите. Тоест, той функционира като Route Reflector.

Същото се случва и в обратна посока.

Overlay може да се променя всяка минута. Примерно така става в публичните облаци, когато клиентите редовно стартират и спират своите виртуални машини.

Централният контролер поема всички сложности с поддържането на конфигурации и контрол на таблиците за комутация/маршрутиране на vRouter.

Грубо казано, контролерът се свързва с всички vRouter-и по BGP (или подобен на него протокол) и просто предава информация за маршрутите. Например, BGP вече има Address-Family за предаване на метода на инкапсулация. MPLS-in-GRE или MPLS-in-UDP.

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

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

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

Прилагат се два подхода:

1. Поставя се хардуерният маршрутизатор.
2. Стартира се някакъв appliance, реализиращ функциите на маршрутизатор (да-да, след SDN сме се сблъскали и с VNF). Нека го наречем виртуален шлюз.

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

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

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

С другата страна шлюзът гледа към магистралната мрежа и знае как да се свърже с Интернет.

Data Plane

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

1. VM-0, със зададен по подразбиране vRouter, изпраща пакет с адресат во външния свят (185.147.83.177) през интерфейс eth0.
2. vRouter получава този пакет и извършва търсене на адреса на получателя в таблицата за маршрутизация — намира маршрута по подразбиране през шлюза VNGW1 през Tunnel 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. Underlay мрежата доставя пакета до шлюза 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.
   Адрес на тунела — IP-адрес на vRouter’а, зад който стои целевата ВМ — 10.0.0.2.
4. Андерлейн мрежата доставя пакета до нужния vRouter’а.
5. Целевият vRouter открива GRE/UDP, по MPLS-метката определя интерфейса и изпраща гол пакет IP в своя TAP интерфейс, свързан с eth0 на ВМ.

Control Plane

VNGW1 установява BGP-съседство с SDN-контролера, от който получава цялата маршрутна информация за клиентите: зад кой IP-адрес (vRouter’а) се намира кой клиент и с коя MPLS-метка е идентифициран.

По подобен начин, той самият информира SDN-контролера за дефолтния маршрут с метката на този клиент, посочвайки себе си като nexthop. След това този дефолт идва на vRouter’ите.

На VNGW обикновено протича агрегация на маршрути или NAT транслация.

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

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

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

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

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

ЧЗВ

Защо всеки път правиш бележка за 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 заглавие.

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

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

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

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

Също така е възможен сценарий, когато vRouter е DPDK приложение в User Space.

vRouter Agent прехвърля настройките на vRouter Forwarder.

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

Обикновено в механизмите на виртуализация, обектът виртуална мрежа (може да се счита за собствено име) се въвежда отделно от клиентите/наемателите/виртуалните машини — напълно самостоятелна единица. А тази виртуална мрежа чрез интерфейси вече може да бъде свързана в един наемател, друг, двама, или където и да е. Например, така се реализира Service Chaining, когато трафикът трябва да премине през определени нодове в нужната последователност, просто създавайки и свързвайки виртуални мрежи в правилната последователност.

Затова няма пряко съответствие между виртуалната мрежа и наемателя.

Заключение

Това е доста повърхностно описание на работата на виртуалната мрежа с overlay от хост и SDN контролер. Без значение коя виртуализационна платформа изберете днес, тя ще работи по подобен начин, независимо дали става дума за VMWare, ACI, OpenStack, CloudStack, Tungsten Fabric или Juniper Contrail. Разликите ще бъдат в типовете инкапсулации и заглавия, протоколите за доставка на информация до крайните мрежови устройства, но принципът на софтуерно конфигурируема overlay мрежа, работеща върху сравнително проста и статична underlay мрежа, ще остане същият.
Можем да кажем, че в областта на създаването на частно облако, SDN базирано на overlay мрежа е победител. Въпреки това, това не означава, че OpenFlow няма място в съвременния свят — той се използва в OpenStack и в същия VMWare NSX, от колкото ми е известно, Google го използва за конфигуриране на underlay мрежата.

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

А какво става с нашия Underlay?

А всъщност нищо. Той не се е променял през цялото време. Всичко, което трябва да прави в случай на overlay от хост, е да актуализира маршрути и ARP записи при появата и изчезването на vRouter/VNGW и да пренася пакети между тях.

Нека формулираме списък с изисквания към Underlay мрежата.

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

На работата на самата Underlay мрежа отделих много малко време. Това е, защото в следващите части на серията ще се фокусирам именно на нея, а Overlay ще засегнем само мимоходом.

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

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

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

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

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

Благодаря

• на Романа Горге — бивш водещ на подкаста linkmeup, а сега експерт в областта на облачните платформи. За коментари и корекции. Очакваме и по-задълбочен труд от него за виртуализация в близко бъдеще.
• на Александру Шалимову — моят колега и експерт в областта на разработката на виртуални мрежи. За коментари и корекции.
• на Валентину Синицыну — моят колега и експерт в областта на Tungsten Fabric. За коментари и корекции.
• на Артему Чернобаю — илюстратор на linkmeup. Благодаря за КДПВ.
• на Александру Лимонову. За мема „automato“.

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