В predchádzajúce vydanie Popísal som rámec automatizácie siete. Podľa niektorých ľudí už aj tento prvý prístup k problému vyriešil niektoré otázky. A to ma veľmi teší, pretože naším cieľom v cykle nie je prekryť Ansible skriptami Python, ale vybudovať systém.

Rovnaký rámec určuje poradie, v ktorom sa budeme zaoberať otázkou.
A virtualizácia siete, ktorej je venované toto číslo, sa veľmi nehodí do témy ADSM, kde automatizáciu rozoberáme.

Ale pozrime sa na to z iného uhla.

Mnoho služieb používa rovnakú sieť už dlho. V prípade telekomunikačného operátora ide napríklad o 2G, 3G, LTE, broadband a B2B. V prípade DC: konektivita pre rôznych klientov, internet, blokové úložisko, objektové úložisko.

A všetky služby vyžadujú vzájomnú izoláciu. Takto sa objavili prekryvné siete.

A všetky služby nechcú čakať, kým si ich človek nakonfiguruje manuálne. Takto sa objavili orchestrátori a SDN.

Prvý prístup k systematickej automatizácii siete, alebo skôr jej časti, je už dávno prijatý a implementovaný na mnohých miestach: VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.

To je to, čím sa dnes budeme zaoberať.

Obsah

• dôvody
• terminológie
• Podklad – fyzická sieť
• Overlay - virtuálna sieť
  • Prekrytie s ToR
  • Prekrytie od hostiteľa
  • Použitie Tungsten Fabric ako príklad
    • Komunikácia v rámci jedného fyzického stroja
    • Komunikácia medzi VM umiestnenými na rôznych fyzických počítačoch
    • Odchod do vonkajšieho sveta

• FAQ
• Záver
• Užitočné odkazy

dôvody

A keďže už hovoríme o tomto, stojí za zmienku o predpokladoch virtualizácie siete. V skutočnosti sa tento proces nezačal včera.

Pravdepodobne ste už viac ako raz počuli, že sieť bola vždy najinertnejšou súčasťou každého systému. A to platí v každom zmysle. Sieť je základ, na ktorom všetko spočíva, a robiť na nej zmeny je dosť ťažké - služby to netolerujú, keď je sieť mimo prevádzky. Vyradenie jedného uzla z prevádzky môže často zničiť veľkú časť aplikácií a ovplyvniť mnohých zákazníkov. To je čiastočne dôvod, prečo sa sieťový tím môže brániť akejkoľvek zmene - pretože teraz to nejako funguje (možno ani nevieme ako), ale tu musíte nakonfigurovať niečo nové a nie je známe, ako to ovplyvní sieť.

Aby sa nečakalo, kým sieťoví pracovníci vložia siete VLAN a nezaregistrujú žiadne služby na každom uzle siete, ľudia prišli s nápadom použiť prekryvné siete - prekryvné siete - ktorých je veľké množstvo: GRE, IPinIP, MPLS, MPLS L2/L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE atď.

Ich príťažlivosť spočíva v dvoch jednoduchých veciach:

• Konfigurujú sa iba koncové uzly – tranzitných uzlov sa netreba dotýkať. To výrazne urýchľuje proces a niekedy umožňuje úplne vylúčiť oddelenie sieťovej infraštruktúry z procesu zavádzania nových služieb.
• Záťaž je ukrytá hlboko v hlavičkách – tranzitné uzly o nej nemusia nič vedieť, o adresovaní na hostiteľoch ani o trasách prekryvnej siete. To znamená, že do tabuliek musíte ukladať menej informácií, čo znamená použitie jednoduchšieho/lacnejšieho zariadenia.

V tejto nie celkom plnohodnotnej problematike neplánujem rozoberať všetky možné technológie, skôr popíšem framework pre fungovanie overlay sietí v DC.

Celá séria bude popisovať dátové centrum pozostávajúce z radov identických stojanov, v ktorých je nainštalované rovnaké serverové zariadenie.

Toto zariadenie prevádzkuje virtuálne stroje/kontajnery/bezserverové zariadenia, ktoré implementujú služby.

terminológie

V slučke server Pomenujem program, ktorý implementuje serverovú stranu komunikácie klient-server.

Fyzické stroje v stojanoch sa nazývajú servery nie budeme.

Fyzický stroj — počítač x86 nainštalovaný v stojane. Najčastejšie používaný výraz hostiteľ. Tak to nazveme"stroj"alebo hostiteľ.

Hypervízor - aplikácia spustená na fyzickom stroji, ktorá emuluje fyzické prostriedky, na ktorých bežia virtuálne stroje. Niekedy sa v literatúre a na internete slovo „hypervízor“ používa ako synonymum pre „hostiteľ“.

Virtuálny prístroj - operačný systém bežiaci na fyzickom stroji nad hypervízorom. Pre nás v tomto cykle je v podstate jedno, či ide skutočne o virtuálny stroj alebo len o kontajner. Nazvime to"VM«

Nájomca je široký pojem, ktorý v tomto článku zadefinujem ako samostatnú službu alebo samostatného klienta.

Viacnásobný nájom alebo multiprenájom – používanie tej istej aplikácie rôznymi klientmi/službami. Vzájomná izolácia klientov je zároveň dosiahnutá vďaka aplikačnej architektúre, a nie prostredníctvom samostatne spustených inštancií.

ToR — Horná časť prepínača Rack - prepínač inštalovaný v racku, ku ktorému sú pripojené všetky fyzické stroje.

Okrem topológie ToR rôzni poskytovatelia praktizujú End of Row (EoR) alebo Middle of Row (hoci tá druhá je pohŕdavá rarita a skratku MoR som nevidel).

Podkladová sieť alebo základnou sieťou alebo podkladom je fyzická sieťová infraštruktúra: prepínače, smerovače, káble.

Prekryvná sieť alebo overlay network alebo overlay - virtuálna sieť tunelov bežiacich nad fyzickým.

L3 tkanina alebo IP tkanina - úžasný vynález ľudstva, ktorý vám umožňuje vyhnúť sa opakovaniu STP a učeniu TRILL na pohovory. Koncept, v ktorom je celá sieť až po úroveň prístupu výhradne L3, bez VLAN a teda aj obrovských rozšírených vysielacích domén. V ďalšej časti sa pozrieme na to, odkiaľ pochádza slovo „továreň“.

SDN - Sieť definovaná softvérom. Sotva treba predstavovať. Prístup k správe siete, kde zmeny v sieti nevykonáva osoba, ale program. Zvyčajne to znamená presunutie riadiacej roviny za koncové sieťové zariadenia k ovládaču.

NFV — Virtualizácia sieťových funkcií — virtualizácia sieťových zariadení, čo naznačuje, že niektoré sieťové funkcie možno spúšťať vo forme virtuálnych strojov alebo kontajnerov, aby sa urýchlila implementácia nových služieb, organizovalo reťazenie služieb a jednoduchšia horizontálna škálovateľnosť.

VNF - Funkcia virtuálnej siete. Špecifické virtuálne zariadenie: router, switch, firewall, NAT, IPS/IDS atď.

Popis teraz zámerne zjednodušujem na konkrétnu implementáciu, aby som čitateľa príliš nezmiatol. Pre premyslenejšie čítanie ho odkazujem do sekcie referencie. Okrem toho Roma Gorge, ktorý kritizuje tento článok za nepresnosti, sľubuje, že napíše samostatné vydanie o technológiách virtualizácie serverov a sietí, ktoré bude podrobnejšie a pozorné na detaily.

Väčšina dnešných sietí sa dá jasne rozdeliť na dve časti:

podložka — fyzická sieť so stabilnou konfiguráciou.
Obložiť — abstrakcia cez podklad na izoláciu nájomníkov.

To platí tak pre prípad DC (ktorý budeme analyzovať v tomto článku), ako aj pre ISP (ktorého nebudeme rozoberať, pretože to už bolo SDSM). V prípade podnikových sietí je situácia samozrejme trochu iná.

Obrázok so zameraním na sieť:

podložka

Podklad je fyzická sieť: hardvérové ​​prepínače a káble. Zariadenia v podzemí vedia, ako dosiahnuť fyzické stroje.

Spolieha sa na štandardné protokoly a technológie. V neposlednom rade preto, že hardvérové ​​zariadenia dodnes fungujú na proprietárnom softvéri, ktorý neumožňuje programovanie čipu ani implementáciu vlastných protokolov, a preto je potrebná kompatibilita s inými dodávateľmi a štandardizácia.

Ale niekto ako Google si môže dovoliť vyvinúť vlastné prepínače a opustiť všeobecne akceptované protokoly. Ale LAN_DC nie je Google.

Podklad sa mení pomerne zriedka, pretože jeho úlohou je základná IP konektivita medzi fyzickými strojmi. Spoločnosť Underlay nevie nič o službách, klientoch alebo nájomníkoch, ktoré sú nad ňou spustené – potrebuje iba doručiť balík z jedného počítača na druhý.
Podložka môže byť takáto:

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

Sieť Underlay sa konfiguruje klasickým spôsobom: CLI/GUI/NETCONF.

Manuálne, skripty, proprietárne nástroje.

Ďalší článok zo série bude venovaný podložke podrobnejšie.

Obložiť

Overlay je virtuálna sieť tunelov natiahnutá na vrchu Underlay, umožňuje virtuálnym počítačom jedného klienta navzájom komunikovať a zároveň poskytuje izoláciu od ostatných klientov.

Klientske dáta sú zapuzdrené v niektorých tunelovacích hlavičkách na prenos cez verejnú sieť.

Takže VM jedného klienta (jednej služby) môžu medzi sebou komunikovať cez Overlay bez toho, aby vedeli, akou cestou sa paket v skutočnosti uberá.

Prekrytie môže byť napríklad také, ako som spomenul vyššie:

• tunel GRE
• VXLAN
• EVPN
• L3VPN
• GENEVE

Prekryvná sieť sa zvyčajne konfiguruje a udržiava prostredníctvom centrálneho ovládača. Z neho sa konfigurácia, riadiaca rovina a dátová rovina doručujú zariadeniam, ktoré smerujú a zapuzdrujú klientsky prenos. Málo nižšie Pozrime sa na to s príkladmi.

Áno, toto je SDN vo svojej najčistejšej podobe.

Existujú dva zásadne odlišné prístupy k organizácii prekryvnej siete:

1. Prekrytie s ToR
2. Prekrytie od hostiteľa

Prekrytie s ToR

Prekrytie môže začať na prístupovom spínači (ToR) stojacom v stojane, ako sa to stáva napríklad v prípade tkaniny VXLAN.

Toto je časom overený mechanizmus v sieťach ISP a podporujú ho všetci predajcovia sieťových zariadení.

V tomto prípade však musí byť prepínač ToR schopný oddeliť jednotlivé služby a správca siete musí do určitej miery spolupracovať so správcami virtuálnych strojov a vykonávať zmeny (hoci automaticky) v konfigurácii zariadení. .

Tu odkážem čitateľa na článok o VxLAN na Habré náš starý priateľ @bormoglotx.
V tomto prezentácií s ENOG podrobne sú opísané prístupy k budovaniu DC siete s EVPN VXLAN tkaninou.

A pre úplnejší ponor do reality si môžete prečítať knihu Tsiska Moderná, otvorená a škálovateľná tkanina: VXLAN EVPN.

Podotýkam, že VXLAN je len metóda zapuzdrenia a ukončenie tunelov môže nastať nie na ToR, ale na hostiteľovi, ako sa to deje napríklad v prípade OpenStack.

Avšak štruktúra VXLAN, kde prekrytie začína na ToR, je jedným zo zavedených návrhov prekryvných sietí.

Prekrytie od hostiteľa

Ďalším prístupom je spustenie a ukončenie tunelov na koncových hostiteľoch.
V tomto prípade zostáva sieť (Underlay) maximálne jednoduchá a statická.
A hostiteľ sám urobí všetko potrebné zapuzdrenie.

To bude samozrejme vyžadovať spustenie špeciálnej aplikácie na hostiteľoch, ale stojí to za to.

Po prvé, spustenie klienta na počítači so systémom Linux je jednoduchšie alebo, povedzme, dokonca možné, zatiaľ čo na prepínači sa s najväčšou pravdepodobnosťou budete musieť obrátiť na proprietárne riešenia SDN, čo zabíja myšlienku viacerých dodávateľov.

Po druhé, prepínač ToR môže byť v tomto prípade ponechaný čo najjednoduchšie, a to ako z pohľadu riadiacej roviny, tak aj dátovej roviny. V skutočnosti potom nemusí komunikovať s SDN radičom a tiež nemusí ukladať siete/ARP všetkých pripojených klientov - stačí poznať IP adresu fyzického stroja, čo výrazne zjednodušuje prepínanie/ smerovacie tabuľky.

V sérii ADSM volím overlay prístup od hostiteľa – potom sa o tom len bavíme a do továrne VXLAN sa už nevrátime.

Najjednoduchšie je pozrieť sa na príklady. A ako testovací subjekt vezmeme OpenSource SDN platformu OpenContrail, teraz známu ako Volfrámová tkanina.

Na konci článku uvediem niekoľko myšlienok o analógii s OpenFlow a OpenvSwitch.

Použitie Tungsten Fabric ako príklad

Každý fyzický stroj má vRouter - virtuálny router, ktorý vie o sieťach, ktoré sú k nemu pripojené a ktorým klientom patria - v podstate PE router. Pre každého klienta udržiava izolovanú smerovaciu tabuľku (čítaj VRF). A vRouter skutočne vykonáva tunelovanie prekrytia.

Trochu viac o vRouter je na konci článku.

Každý VM umiestnený na hypervízore je pripojený k vRouteru tohto počítača cez Rozhranie TAP.

TAP - Terminal Access Point - virtuálne rozhranie v jadre Linuxu, ktoré umožňuje interakciu so sieťou.

Ak je za vRouterom viacero sietí, tak sa pre každú z nich vytvorí virtuálne rozhranie, ku ktorému je priradená IP adresa – bude to predvolená adresa brány.
Všetky siete jedného klienta sú umiestnené v jednej VRF (jedna tabuľka), rôzne - do rôznych.
Urobím prehlásenie, že nie všetko je také jednoduché, a zvedavého čitateľa pošlem na koniec článku.

Aby vRouters mohli medzi sebou komunikovať, a teda virtuálne počítače umiestnené za nimi si vymieňajú informácie o smerovaní cez SDN ovládač.

Aby ste sa dostali von do vonkajšieho sveta, existuje výstupný bod z matrice - virtuálna sieťová brána VNGW — Brána virtuálnej siete (môj termín).

Teraz sa pozrime na príklady komunikácie - a bude to jasné.

Komunikácia v rámci jedného fyzického stroja

VM0 chce poslať paket do VM2. Predpokladajme teraz, že ide o virtuálny počítač s jedným klientom.

Dátová rovina

1. VM-0 má predvolenú cestu k rozhraniu eth0. Balík sa tam odošle.
   Toto rozhranie eth0 je v skutočnosti virtuálne pripojené k virtuálnemu smerovaču vRouter cez rozhranie TAP tap0.
2. vRouter analyzuje, na ktoré rozhranie paket prišiel, teda ku ktorému klientovi (VRF) patrí a skontroluje adresu príjemcu pomocou smerovacej tabuľky tohto klienta.
3. Po zistení, že príjemca na tom istom počítači je na inom porte, vRouter mu jednoducho odošle paket bez ďalších hlavičiek – v tomto prípade vRouter už má záznam ARP.

V tomto prípade paket nevstúpi do fyzickej siete - je smerovaný vo vnútri vRoutera.

Kontrolná rovina

Keď sa virtuálny počítač spustí, hypervízor mu povie:

• Jej vlastnú IP adresu.
• Predvolená trasa je cez IP adresu vRouter v tejto sieti.

Hypervízor podáva správy vRouter cez špeciálne API:

• Čo potrebujete na vytvorenie virtuálneho rozhrania.
• Aký druh virtuálnej siete potrebuje (VM) vytvoriť?
• Na ktorý VRF (VN) ho naviazať.
• Statická položka ARP pre tento VM – ktoré rozhranie sa nachádza za jeho IP adresou a s ktorou MAC adresou je spojené.

Skutočný postup interakcie je opäť zjednodušený kvôli pochopeniu konceptu.

VRouter teda vidí všetky VM jedného klienta na danom počítači ako priamo prepojené siete a môže medzi nimi sám smerovať.

Ale VM0 a VM1 patria rôznym klientom, a preto sú v rôznych tabuľkách vRouter.

Či môžu medzi sebou komunikovať priamo, závisí od nastavení vRouteru a dizajnu siete.
Ak napríklad virtuálne počítače oboch klientov používajú verejné adresy alebo sa NAT vyskytuje na samotnom vRouteri, je možné vykonať priame smerovanie na vRouter.

V opačnej situácii je možné krížiť adresné priestory – na získanie verejnej adresy musíte prejsť cez NAT server – je to podobné ako pri prístupe k externým sieťam, ktoré sú popísané nižšie.

Komunikácia medzi VM umiestnenými na rôznych fyzických počítačoch

Dátová rovina

1. Začiatok je úplne rovnaký: VM-0 odošle paket s cieľovým VM-7 (172.17.3.2) v predvolenom nastavení.
2. vRouter ho prijme a tentoraz vidí, že cieľ je na inom počítači a je prístupný cez Tunnel0.
3. Najprv zavesí štítok MPLS, ktorý identifikuje vzdialené rozhranie, takže na opačnej strane môže vRouter určiť, kam umiestniť tento paket bez ďalšieho vyhľadávania.

   

4. Tunel0 má zdroj 10.0.0.2, cieľ: 10.0.1.2.
   vRouter pridá hlavičky GRE (alebo UDP) a novú IP do pôvodného paketu.
5. Smerovacia tabuľka vRouter má predvolenú cestu cez adresu ToR1 10.0.0.1. Tam to posiela.

   
   

6. ToR1 ako člen siete Underlay vie (napríklad cez OSPF) ako sa dostať na 10.0.1.2 a pošle paket po trase. Upozorňujeme, že ECMP je tu povolené. Na obrázku sú dva nexthopy a rôzne vlákna budú do nich zoradené podľa hash. V prípade skutočnej továrne budú pravdepodobnejšie 4 nexthopy.

   Zároveň nemusí vedieť, čo je pod externou IP hlavičkou. To znamená, že pod IP môže existovať sendvič IPv6 cez MPLS cez Ethernet cez MPLS cez GRE cez cez gréčtinu.

7. V súlade s tým na strane príjemcu vRouter odstráni GRE a pomocou značky MPLS pochopí, na ktoré rozhranie by mal byť tento paket odoslaný, odstráni ho a odošle ho v pôvodnej podobe príjemcovi.

Kontrolná rovina

Keď naštartujete auto, stane sa to isté, čo je popísané vyššie.

A plus nasledujúce:

• Pre každého klienta vRouter prideľuje značku MPLS. Toto je označenie služby L3VPN, podľa ktorého budú klienti oddelení v rámci toho istého fyzického počítača.
  

  V skutočnosti je MPLS tag vždy pridelený bezpodmienečne vRouterom - koniec koncov, nie je vopred známe, že stroj bude interagovať iba s inými strojmi za rovnakým vRouterom a s najväčšou pravdepodobnosťou to ani nie je pravda.

• vRouter nadviaže spojenie s radičom SDN pomocou protokolu BGP (alebo jemu podobného - v prípade TF je to XMPP 0_o).
• Prostredníctvom tejto relácie hlási vRouter smerovaču SDN trasy do pripojených sietí:
  • Sieťová adresa
  • Spôsob zapuzdrenia (MPLSoGRE, MPLSoUDP, VXLAN)
  • Značka klienta MPLS
  • Vaša IP adresa ako nexthop

• SDN kontrolér prijíma takéto trasy zo všetkých pripojených vRouterov a odráža ich ostatným. To znamená, že funguje ako reflektor trasy.

To isté sa deje v opačnom smere.

Prekrytie sa môže meniť minimálne každú minútu. Zhruba to sa deje vo verejných cloudoch, kde klienti pravidelne spúšťajú a vypínajú svoje virtuálne stroje.

Centrálny ovládač sa stará o všetku zložitosť údržby konfigurácie a monitorovania prepínacích/smerovacích tabuliek na vRouter.

Zhruba povedané, radič komunikuje so všetkými vRoutermi cez BGP (alebo podobný protokol) a jednoducho prenáša informácie o smerovaní. Napríklad BGP už má Address-Family na sprostredkovanie metódy zapuzdrenia MPLS-in-GRE alebo MPLS-in-UDP.

Zároveň sa nijako nemení konfigurácia siete Underlay, ktorá je mimochodom oveľa náročnejšia na automatizáciu a je ľahšie ju zlomiť nepohodlným pohybom.

Odchod do vonkajšieho sveta

Niekde musí simulácia skončiť a vy musíte opustiť virtuálny svet do toho skutočného. A potrebujete bránu telefónneho automatu.

Praktizujú sa dva prístupy:

1. Je nainštalovaný hardvérový smerovač.
2. Spustí sa spotrebič, ktorý implementuje funkcie smerovača (áno, po SDN sme sa stretli aj s VNF). Nazvime to virtuálna brána.

Výhodou druhého prístupu je lacná horizontálna škálovateľnosť – nie je dostatok energie – spustili sme ďalší virtuálny stroj s bránou. Na akomkoľvek fyzickom stroji bez toho, aby ste museli hľadať voľné stojany, jednotky, výkon, kupovať samotný hardvér, prepravovať ho, inštalovať, prepínať, konfigurovať a potom v ňom aj meniť chybné komponenty.

Nevýhody virtuálnej brány spočívajú v tom, že jednotka fyzického smerovača je stále o rádovo výkonnejšia ako viacjadrový virtuálny stroj a jeho softvér, prispôsobený vlastnej hardvérovej základni, funguje oveľa stabilnejšie (nie). Je tiež ťažké poprieť fakt, že hardvérový a softvérový komplex jednoducho funguje, vyžaduje len konfiguráciu, pričom spustenie a údržba virtuálnej brány je úlohou pre silných inžinierov.

Jednou nohou sa brána pozrie do virtuálnej siete Overlay ako bežný virtuálny stroj a môže interagovať so všetkými ostatnými virtuálnymi počítačmi. Zároveň dokáže ukončiť siete všetkých klientov a podľa toho medzi nimi realizovať smerovanie.

Druhou nohou sa brána pozerá do chrbticovej siete a vie, ako sa dostať na internet.

Dátová rovina

To znamená, že proces vyzerá takto:

1. VM-0, ktorý má štandardne nastavený rovnaký vRouter, odošle paket s cieľom vo vonkajšom svete (185.147.83.177) do rozhrania eth0.
2. vRouter prijme tento paket a vyhľadá cieľovú adresu v smerovacej tabuľke - nájde predvolenú cestu cez bránu VNGW1 cez Tunnel 1.
   Vidí tiež, že ide o GRE tunel so SIP 10.0.0.2 a DIP 10.0.255.2 a tiež potrebuje najprv pripojiť MPLS štítok tohto klienta, čo VNGW1 očakáva.
3. vRouter zabalí počiatočný paket s MPLS, GRE a novými hlavičkami IP a štandardne ho odošle do ToR1 10.0.0.1.
4. Základná sieť doručí paket na bránu VNGW1.
5. Brána VNGW1 odstraňuje hlavičky tunelovania GRE a MPLS, vidí cieľovú adresu, konzultuje svoju smerovaciu tabuľku a chápe, že je nasmerovaná na internet – teda cez Úplné zobrazenie alebo Predvolené. V prípade potreby vykoná preklad NAT.
6. Od VNGW po hranice by mohla existovať bežná IP sieť, čo je nepravdepodobné.
   Môže tam byť klasická MPLS sieť (IGP+LDP/RSVP TE), môže existovať back fabric s BGP LU alebo GRE tunel z VNGW na hranicu cez IP sieť.
   Nech je to akokoľvek, VNGW1 vykoná potrebné zapuzdrenia a odošle počiatočný paket smerom k hranici.

Doprava v protismere prechádza rovnakými krokmi v opačnom poradí.

1. Hranica zníži paket na VNGW1
2. Vyzlečie ho, pozrie sa na adresu príjemcu a zistí, že je prístupný cez tunel Tunnel1 (MPLSoGRE alebo MPLSoUDP).
3. V súlade s tým pripojí štítok MPLS, hlavičku GRE/UDP a novú IP a odošle to na svoj ToR3 10.0.255.1.
   Cieľová adresa tunela je adresa IP smerovača vRouter, za ktorým sa nachádza cieľový VM – 10.0.0.2.
4. Základná sieť doručí paket do požadovaného vRouteru.
5. Cieľový vRouter číta GRE/UDP, identifikuje rozhranie pomocou návestia MPLS a odošle holý paket IP na svoje rozhranie TAP spojené s eth0 virtuálneho počítača.

Kontrolná rovina

VNGW1 vytvára susedstvo BGP s radičom SDN, z ktorého prijíma všetky smerovacie informácie o klientoch: ktorá IP adresa (vRouter) sa nachádza za ktorým klientom a ktorým MPLS štítkom je identifikovaný.

Podobne sám informuje SDN radič o predvolenej trase s označením tohto klienta, pričom sa označuje ako nexthop. A potom toto predvolené nastavenie dorazí do vRouters.

Na VNGW zvyčajne dochádza k agregácii trasy alebo prekladu NAT.

A opačným smerom posiela presne túto agregovanú trasu do relácie s okrajmi alebo smerovými reflektormi. A od nich dostane predvolenú trasu alebo Full-View, alebo niečo iné.

Pokiaľ ide o zapuzdrenie a výmenu prevádzky, VNGW sa nelíši od vRouter.
Ak trochu rozšírite rozsah, môžete k VNGW a vRouterom pridať ďalšie sieťové zariadenia, ako sú brány firewall, farmy na čistenie alebo obohatenie prevádzky, IPS atď.

A pomocou sekvenčného vytvárania VRF a správneho oznamovania trás môžete prinútiť premávku, aby zacyklila tak, ako chcete, čo sa nazýva Service Chaining.

To znamená, že aj tu SDN radič funguje ako Route-Reflector medzi VNGW, vRoutermi a inými sieťovými zariadeniami.

V skutočnosti však radič uniká aj informácie o ACL a PBR (Policy Based Routing), čo spôsobuje, že jednotlivé dopravné toky idú inak, ako im káže trasa.

FAQ

Prečo stále robíte poznámky GRE/UDP?

Vo všeobecnosti sa dá povedať, že je to špecifické pre Tungsten Fabric - nemusíte to vôbec brať do úvahy.

Ale ak si to vezmeme, potom samotný TF, zatiaľ čo stále OpenContrail, podporoval obe zapuzdrenia: MPLS v GRE a MPLS v UDP.

UDP je dobré, pretože v zdrojovom porte je veľmi jednoduché zakódovať do jeho hlavičky hašovaciu funkciu z pôvodného IP+Proto+Port, čo vám umožní robiť balansovanie.

V prípade GRE, žiaľ, existujú iba externé hlavičky IP a GRE, ktoré sú rovnaké pre všetku zapuzdrenú prevádzku a o vyvažovaní sa nehovorí – len málokto sa dokáže pozrieť tak hlboko do paketu.

Routre, pokiaľ vedeli, ako používať dynamické tunely, to do určitej doby robili iba v MPLSoGRE a až nedávno sa naučili používať MPLSoUDP. Preto si vždy musíme urobiť poznámku o možnosti dvoch rôznych zapuzdrení.

Spravodlivo stojí za zmienku, že TF plne podporuje konektivitu L2 pomocou VXLAN.

Sľúbili ste paralely s OpenFlow.
Naozaj to žiadajú. vSwitch v tom istom OpenStack robí veľmi podobné veci pomocou VXLAN, ktorý má mimochodom tiež hlavičku UDP.

V dátovej rovine fungujú približne rovnako, kontrolná rovina sa výrazne líši. Tungsten Fabric používa XMPP na doručovanie smerovacích informácií do vRouter, zatiaľ čo OpenStack prevádzkuje Openflow.

Môžete mi povedať niečo viac o vRouter?
Je rozdelený na dve časti: vRouter Agent a vRouter Forwarder.

Prvý beží v užívateľskom priestore hostiteľského OS a komunikuje s radičom SDN, pričom si vymieňa informácie o trasách, VRF a ACL.

Druhá implementuje Data Plane - zvyčajne v Kernel Space, ale môže bežať aj na SmartNIC - sieťových kartách s CPU a samostatným programovateľným prepínacím čipom, ktorý vám umožňuje odstrániť záťaž z CPU hostiteľského počítača a zrýchliť a zrýchliť sieť. predvídateľné.

Ďalším možným scenárom je, že vRouter je aplikácia DPDK v užívateľskom priestore.

vRouter Agent odošle nastavenia do vRouter Forwarder.

Čo je to virtuálna sieť?
Na začiatku článku o VRF som spomenul, že každý nájomca je viazaný na svoje vlastné VRF. A ak to stačilo na povrchné pochopenie fungovania prekryvnej siete, potom pri ďalšej iterácii je potrebné objasniť.

Typicky je vo virtualizačných mechanizmoch entita virtuálnej siete (môžete to považovať za vlastné meno) zavedená oddelene od klientov/nájomníkov/virtuálnych strojov – úplne nezávislá vec. A táto virtuálna sieť už môže byť pripojená cez rozhrania k jednému nájomcovi, druhému, dvom alebo kdekoľvek. Takže napríklad Service Chaining sa implementuje, keď je potrebné, aby prevádzka prechádzala cez určité uzly v požadovanom poradí, jednoducho vytvorením a pripojením virtuálnych sietí v správnom poradí.

Preto neexistuje žiadna priama korešpondencia medzi virtuálnou sieťou a nájomcom.

Záver

Toto je veľmi povrchný popis fungovania virtuálnej siete s prekrytím z hostiteľa a radiča SDN. Bez ohľadu na to, akú virtualizačnú platformu si dnes vyberiete, bude fungovať podobným spôsobom, či už to bude VMWare, ACI, OpenStack, CloudStack, Tungsten Fabric alebo Juniper Contrail. Líšiť sa budú typmi zapuzdrenia a hlavičiek, protokolmi na doručovanie informácií koncovým sieťovým zariadeniam, ale princíp softvérovo konfigurovateľnej prekryvnej siete fungujúcej nad relatívne jednoduchou a statickou podsadenou sieťou zostane rovnaký.
Dá sa povedať, že dnes SDN založené na overlay sieti vyhralo oblasť vytvárania privátneho cloudu. To však neznamená, že Openflow nemá miesto v modernom svete - používa sa v OpenStacke a v rovnakom VMWare NSX, pokiaľ viem, Google ho používa na nastavenie podzemnej siete.

Nižšie uvádzam odkazy na podrobnejšie materiály, ak si chcete problematiku preštudovať hlbšie.

A čo náš Underlay?

Ale vo všeobecnosti nič. Celú cestu nezmenil. Všetko, čo musí urobiť v prípade prekrytia z hostiteľa, je aktualizovať trasy a ARP, keď sa vRouter/VNGW objavujú a miznú a prenášajú medzi nimi pakety.

Sformulujme si zoznam požiadaviek na sieť Underlay.

1. Byť schopný použiť nejaký druh smerovacieho protokolu, v našej situácii - BGP.
2. Majte širokú šírku pásma, najlepšie bez nadmerného odberu, aby sa pakety nestratili v dôsledku preťaženia.
3. Podpora ECMP je neoddeliteľnou súčasťou tkaniny.
4. Byť schopný poskytovať QoS vrátane zložitých vecí, ako je ECN.
5. Podpora NETCONF je základom pre budúcnosť.

Samotnej práci siete Underlay som tu venoval veľmi málo času. Je to preto, že neskôr v sérii sa na to zameriam a Overlay sa dotkneme len zbežne.

Je zrejmé, že nás všetkých výrazne obmedzujem tým, že ako príklad použijem DC sieť postavenú v továrni Cloz s čistým IP smerovaním a prekrytím od hostiteľa.

Som si však istý, že každá sieť, ktorá má dizajn, môže byť opísaná formálne a automatizovaná. Ide len o to, že mojím cieľom je porozumieť prístupom k automatizácii a nezmiasť všetkých riešením problému vo všeobecnej forme.

V rámci ADSM plánujeme s Romanom Gorgeom vydať samostatné číslo o virtualizácii výpočtovej sily a jej interakcii s virtualizáciou siete. Zostať v kontakte.

Užitočné odkazy

• Architektúra Tungsten Fabric.
• about:cloud. 6 hodín o Yandex.Cloud, ktorý pokrýva aj virtuálnu sieť na TF.
• Čo je Open vSwitch?
• Úvod do VxLAN.
• RFC 7348. Virtual eXtensible Local Area Network (VXLAN): Rámec pre prekrytie virtualizovaných sietí vrstvy 2 cez siete 3. vrstvy.
  
• Scaleway prístup k VXLAN EVPN Fabric. Hovorí o celej DC sieti vrátane Underlay, Overlay, prístupov k multi-homingu a manažmentu.

Ďakujem

• Roman Gorga - bývalý hostiteľ podcastu linkmeup a teraz odborník v oblasti cloudových platforiem. Pre komentáre a úpravy. No a v blízkej dobe čakáme na jeho hlbší článok o virtualizácii.
• Alexander Šalimov - môj kolega a odborník v oblasti vývoja virtuálnych sietí. Pre komentáre a úpravy.
• Valentin Sinitsyn - môj kolega a odborník v oblasti Tungsten Fabric. Pre komentáre a úpravy.
• Arťom Černobaj — ilustrátorský linkmeup. Pre KDPV.
• Alexander Limonov. Pre "automat" meme.

Zdroj: hab.com