В előző szám Leírtam a hálózati automatizálási keretrendszert. Egyesek szerint már ez az első megközelítés is megoldott néhány kérdést. Ez pedig nagyon boldoggá tesz, mert a ciklusban nem az Ansible elfedése Python szkriptekkel a célunk, hanem egy rendszer felépítése.

Ugyanez a keret határozza meg azt a sorrendet, amelyben a kérdéssel foglalkozunk.
A hálózati virtualizáció pedig, amelyre ez a szám szól, nem igazán illik bele az ADSM témakörbe, ahol az automatizálást elemezzük.

De nézzük más szemszögből.

Sok szolgáltatás már régóta használja ugyanazt a hálózatot. Egy távközlési szolgáltatónál ez például a 2G, 3G, LTE, szélessáv és B2B. DC esetén: csatlakozás különböző kliensekhez, Internet, blokktárolás, objektumtárolás.

És minden szolgáltatás elszigetelést igényel egymástól. Így jelentek meg az overlay hálózatok.

És minden szolgáltatás nem akar megvárni, amíg egy személy manuálisan konfigurálja őket. Így jelentek meg a hangszerelők és az SDN.

A hálózat, vagy inkább annak egy része szisztematikus automatizálásának első megközelítését már régóta alkalmazzák és alkalmazzák sok helyen: VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.

Ma ezzel fogunk foglalkozni.

Tartalom

• Okok
• terminológia
• Underlay – fizikai hálózat
• Overlay – virtuális hálózat
  • Átfedés ToR-ral
  • Fedvény a gazdagéptől
  • Példaként a Tungsten Fabric használata
    • Kommunikáció egyetlen fizikai gépen belül
    • Kommunikáció a különböző fizikai gépeken található virtuális gépek között
    • Kilépés a külvilágba

• FAQ
• Következtetés
• Hasznos Linkek

Okok

És mivel erről beszélünk, érdemes megemlíteni a hálózati virtualizáció előfeltételeit. Valójában ez a folyamat nem tegnap kezdődött.

Valószínűleg többször hallottad már, hogy a hálózat mindig is a rendszer legtehetetlenebb része volt. És ez minden értelemben igaz. A hálózat az alap, amelyen minden nyugszik, és ezen a változtatások elvégzése meglehetősen nehézkes - a szolgáltatások nem tolerálják, ha a hálózat nem működik. Gyakran egyetlen csomópont leszerelése az alkalmazások nagy részét leállíthatja, és sok ügyfélre hatással lehet. Részben ez az oka annak, hogy a hálózati csapat ellenáll minden változásnak - mert most valahogy működik (talán nem is tudjuk, hogyan), de itt valami újat kell konfigurálnia, és nem tudni, hogy ez milyen hatással lesz a hálózatra.

Annak érdekében, hogy ne várják meg, amíg a hálózatépítők beillesztik a VLAN-okat, és ne regisztráljanak semmilyen szolgáltatást az egyes hálózati csomópontokon, az emberek az átfedések - overlay hálózatok - alkalmazásának ötletével álltak elő, amelyekből nagyon sokféle létezik: GRE, IPinIP, MPLS, MPLS L2/L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE stb.

A vonzerejük két egyszerű dologban rejlik:

• Csak a végcsomópontok vannak konfigurálva – a szállítási csomópontokat nem kell megérinteni. Ez jelentősen felgyorsítja a folyamatot, és néha lehetővé teszi a hálózati infrastruktúra részlegének teljes kizárását az új szolgáltatások bevezetésének folyamatából.
• A terhelés mélyen a fejlécek belsejében van elrejtve – a tranzit csomópontoknak semmit sem kell tudniuk róla, sem a hosztokon történő címzésről, sem az overlay hálózat útvonalairól. Ez azt jelenti, hogy kevesebb információt kell táblázatokban tárolni, ami azt jelenti, hogy egyszerűbb/olcsóbb eszközt kell használni.

Ebben a nem teljesen teljes értékű kérdésben nem kívánok minden lehetséges technológiát elemezni, inkább leírom az overlay hálózatok DC-k működésének kereteit.

A teljes sorozat egy adatközpontot ír le, amely azonos rackek soraiból áll, amelyekbe ugyanaz a szerverberendezés van telepítve.

Ez a berendezés virtuális gépeket/tárolókat/kiszolgáló nélküli szolgáltatásokat futtat.

terminológia

Egy ciklusban szerver Megnevezek egy programot, ami megvalósítja a kliens-szerver kommunikáció szerver oldalát.

A rackekben lévő fizikai gépeket szervereknek nevezzük nincs mi fogunk.

Fizikai gép — x86 számítógép állványba telepítve. A leggyakrabban használt kifejezés vendéglátó. így fogjuk hívni"gépvagy vendéglátó.

Hipervizor - egy fizikai gépen futó alkalmazás, amely emulálja azokat a fizikai erőforrásokat, amelyeken a virtuális gépek futnak. Az irodalomban és az interneten néha a „hipervizor” szót a „host” szinonimájaként használják.

Virtuális gép - egy fizikai gépen futó operációs rendszer egy hypervisor tetején. Számunkra ebben a ciklusban teljesen mindegy, hogy valójában egy virtuális gépről vagy csak egy konténerről van szó. nevezzük "VM«

Bérlő egy tág fogalom, amelyet ebben a cikkben külön szolgáltatásként vagy külön ügyfélként fogok meghatározni.

Több bérlés vagy több bérlés - ugyanazon alkalmazás különböző ügyfelek/szolgáltatások általi használata. Ugyanakkor a kliensek egymástól való elszigetelése az alkalmazás architektúrának köszönhetően valósul meg, nem pedig külön futó példányokon keresztül.

ToR — Az állvány teteje kapcsoló - egy rackbe szerelt kapcsoló, amelyhez minden fizikai gép csatlakoztatva van.

A ToR topológia mellett különböző szolgáltatók alkalmazzák az End of Row (EoR) vagy a Middle of Row (bár ez utóbbi lekicsinylő ritkaság, és nem láttam a MoR rövidítést).

Alátétes hálózat vagy a mögöttes hálózat vagy alátét a fizikai hálózati infrastruktúra: switchek, útválasztók, kábelek.

Átfedő hálózat vagy átfedő hálózat vagy átfedés – alagutak virtuális hálózata, amely a fizikai felett fut.

L3 szövet vagy IP szövet - az emberiség csodálatos találmánya, amely lehetővé teszi, hogy elkerülje az STP megismétlését és a TRILL tanulását az interjúkhoz. Olyan koncepció, amelyben a teljes hálózat a hozzáférési szintig kizárólag L3, VLAN-ok és ennek megfelelően hatalmas kiterjesztett broadcast tartományok nélkül. A következő részben megtudjuk, honnan származik a „gyár” szó.

SDN - Szoftver által definiált hálózat. Aligha kell bemutatkozás. A hálózatkezelés olyan megközelítése, ahol a hálózaton nem egy személy, hanem egy program hajtja végre a változtatásokat. Általában azt jelenti, hogy a vezérlősíkot a véghálózati eszközökön túl a vezérlőhöz kell mozgatni.

NFV - Hálózati funkciók virtualizálása - hálózati eszközök virtualizálása, ami azt sugallja, hogy egyes hálózati funkciók virtuális gépek vagy konténerek formájában futtathatók az új szolgáltatások megvalósításának felgyorsítása, a Service Chaining megszervezése és az egyszerűbb horizontális méretezhetőség érdekében.

VNF - Virtuális hálózati funkció. Konkrét virtuális eszköz: router, switch, tűzfal, NAT, IPS/IDS stb.

Most szándékosan leegyszerűsítem a leírást egy konkrét megvalósításra, nehogy túlságosan összezavarjam az olvasót. Az átgondoltabb olvasás kedvéért a részt ajánlom neki referenciák. Ráadásul a cikket pontatlanságok miatt kritizáló Roma Gorge megígéri, hogy külön számot ír a szerver- és hálózati virtualizációs technológiákról, mélyebben és a részletekre odafigyelve.

A legtöbb hálózat ma egyértelműen két részre bontható:

süppedés — stabil konfigurációjú fizikai hálózat.
Borítás — absztrakció a bérlők elkülönítésére szolgáló alátét felett.

Ez igaz mind a DC esetére (amelyet ebben a cikkben elemezünk), mind az internetszolgáltatóra (amit nem elemezünk, mert már megtörtént). SDSM). A vállalati hálózatok esetében természetesen némileg más a helyzet.

Kép a hálózatra fókuszálva:

süppedés

Az Underlay egy fizikai hálózat: hardveres kapcsolók és kábelek. A földalatti eszközök tudják, hogyan kell elérni a fizikai gépeket.

Szabványos protokollokra és technológiákra támaszkodik. Már csak azért sem, mert a hardvereszközök a mai napig olyan szabadalmaztatott szoftvereken működnek, amelyek nem teszik lehetővé sem a chip programozását, sem a saját protokollok megvalósítását, ennek megfelelően más gyártókkal való kompatibilitás és szabványosítás szükséges.

De valaki, mint a Google, megengedheti magának, hogy saját kapcsolóit fejlesszen, és elhagyja az általánosan elfogadott protokollokat. De a LAN_DC nem a Google.

Az alátét viszonylag ritkán változik, mert feladata a fizikai gépek közötti alapvető IP-kapcsolat. Az Underlay semmit sem tud a rajta futó szolgáltatásokról, ügyfelekről vagy bérlőkről – csak át kell szállítania a csomagot egyik gépről a másikra.
Az alátét ilyen lehet:

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

Az Underlay hálózat a klasszikus módon van konfigurálva: CLI/GUI/NETCONF.

Manuálisan, szkriptek, szabadalmaztatott segédprogramok.

A sorozat következő cikke az alátétnek lesz szentelve részletesebben.

Borítás

Az Overlay az Underlay tetején húzódó alagutak virtuális hálózata, amely lehetővé teszi, hogy egy ügyfél virtuális gépei kommunikáljanak egymással, miközben elszigetelik magukat a többi klienstől.

A kliens adatok néhány alagútfejlécbe vannak beágyazva a nyilvános hálózaton történő továbbításhoz.

Így egy ügyfél (egy szolgáltatás) virtuális gépei kommunikálhatnak egymással az Overlay-n keresztül, anélkül, hogy tudnák, hogy a csomag valójában milyen úton halad.

A fedvény lehet például az, amit fentebb említettem:

• GRE alagút
• VXLAN
• EVPN
• L3VPN
• GENF

Az átfedő hálózatot általában egy központi vezérlőn keresztül konfigurálják és tartják karban. Ebből a konfiguráció, a vezérlősík és az adatsík olyan eszközökhöz kerülnek, amelyek irányítják és beágyazzák az ügyfélforgalmat. Egy kis alatt Nézzük ezt példákkal.

Igen, ez az SDN a legtisztább formájában.

Két alapvetően eltérő megközelítés létezik az Overlay hálózat megszervezésére:

1. Átfedés ToR-ral
2. Fedvény a gazdagéptől

Átfedés ToR-ral

Az átfedés kezdődhet a rackben álló hozzáférési kapcsolónál (ToR), mint például egy VXLAN szövet esetében.

Ez egy jól bevált mechanizmus az ISP-hálózatokon, és minden hálózati berendezés gyártója támogatja.

Ebben az esetben azonban a ToR switchnek el kell tudnia különíteni a különböző szolgáltatásokat, a hálózati rendszergazdának pedig bizonyos mértékig együtt kell működnie a virtuális gép adminisztrátoraival és (bár automatikusan) módosítania kell az eszközök konfigurációját. .

Itt egy cikkre utalom az olvasót VxLAN a Habré-n régi barátunk @bormoglotx.
Ebben előadások az ENOG-val részletesen ismertetjük az egyenáramú hálózat EVPN VXLAN szövettel történő felépítésének megközelítéseit.

A valóságban való teljesebb elmerüléshez pedig elolvashatja Tsiska könyvét Modern, nyitott és méretezhető szövet: VXLAN EVPN.

Megjegyzem, a VXLAN csak egy beágyazási módszer, és az alagutak lezárása nem a ToR-on, hanem a gazdagépen történhet, mint például az OpenStack esetében.

Azonban a VXLAN-szövet, ahol az átfedés a ToR-nál kezdődik, az egyik bevált átfedési hálózat.

Fedvény a gazdagéptől

Egy másik megközelítés az alagutak indítása és befejezése a végállomásokon.
Ebben az esetben a hálózat (Underlay) a lehető legegyszerűbb és statikus marad.
És maga a házigazda elvégzi az összes szükséges tokozást.

Ehhez természetesen egy speciális alkalmazást kell futtatni a gazdagépeken, de megéri.

Először is, a kliens futtatása Linuxos gépen egyszerűbb vagy, mondjuk, akár lehetséges is, míg egy kapcsolónál nagy valószínűséggel szabadalmaztatott SDN-megoldásokhoz kell fordulni, ami megöli a több gyártó gondolatát.

Másodszor, a ToR kapcsoló ebben az esetben a lehető legegyszerűbben hagyható, mind a vezérlősík, mind az adatsík szempontjából. Valóban, akkor nem kell kommunikálnia az SDN vezérlővel, és nem kell tárolnia az összes csatlakoztatott kliens hálózatát/ARP-jét - elég tudni a fizikai gép IP címét, ami nagyban leegyszerűsíti a váltást/ útválasztó táblázatok.

Az ADSM sorozatban az overlay megközelítést választom a hosttól - akkor csak erről beszélünk és nem térünk vissza a VXLAN gyárba.

A legegyszerűbb példákat nézni. Tesztalanyaként pedig az OpenContrail OpenSource SDN platformot vesszük, amely ma már nevén Volfrám szövet.

A cikk végén néhány gondolatot adok az OpenFlow és az OpenvSwitch analógiájáról.

Példaként a Tungsten Fabric használata

Minden fizikai gép rendelkezik vRouter - egy virtuális útválasztó, amely tud a hozzá kapcsolódó hálózatokról és arról, hogy azok mely kliensekhez tartoznak - lényegében egy PE router. Minden egyes klienshez elkülönített útválasztási táblát tart fenn (VRF olvasható). És a vRouter valójában Overlay tunnelinget végez.

Egy kicsit többet a vRouterről a cikk végén.

A hypervisoron található minden virtuális gép csatlakozik a gép vRouteréhez ezen keresztül TAP interfész.

TAP - Terminal Access Point – egy virtuális interfész a Linux kernelben, amely lehetővé teszi a hálózati interakciót.

Ha több hálózat van a vRouter mögött, akkor mindegyikhez létrejön egy virtuális interfész, amelyhez egy IP-cím van hozzárendelve - ez lesz az alapértelmezett átjáró címe.
Egy ügyfél összes hálózata egyben van elhelyezve VRF (egy asztal), különböző - különbözőekké.
Itt teszek egy nyilatkozatot, hogy nem minden olyan egyszerű, és a cikk végére küldöm a kíváncsi olvasót.

Annak érdekében, hogy a vRouterek kommunikálni tudjanak egymással, és ennek megfelelően a mögöttük található virtuális gépek az útválasztási információkat SDN vezérlő.

A külvilágba való kijutáshoz van egy kilépési pont a mátrixból - egy virtuális hálózati átjáró VNGW - Virtuális hálózati átjáró (az én kifejezésem).

Most nézzünk példákat a kommunikációra - és akkor lesz egyértelmű.

Kommunikáció egyetlen fizikai gépen belül

A VM0 csomagot szeretne küldeni a VM2-nek. Tételezzük fel most, hogy ez egyetlen kliens virtuális gép.

Adat sík

1. A VM-0 alapértelmezett útvonala az eth0 interfészhez. Oda küldik a csomagot.
   Ez az eth0 interfész valójában virtuálisan kapcsolódik a virtuális útválasztóhoz, a vRouterhez a tap0 TAP interfészen keresztül.
2. A vRouter elemzi, hogy a csomag melyik interfészre érkezett, vagyis melyik klienshez (VRF) tartozik, és ellenőrzi a címzett címét ennek a kliensnek az útválasztási táblájával.
3. Miután észlelte, hogy ugyanazon a gépen a címzett egy másik porton van, a vRouter egyszerűen elküldi neki a csomagot további fejlécek nélkül - ebben az esetben a vRouter már rendelkezik ARP bejegyzéssel.

Ebben az esetben a csomag nem lép be a fizikai hálózatba - a vRouteren belül van irányítva.

Irányító sík

Amikor a virtuális gép elindul, a hypervisor közli:

• Saját IP címe.
• Az alapértelmezett útvonal a vRouter IP-címén keresztül vezet ezen a hálózaton.

A hypervisor egy speciális API-n keresztül jelent a vRouternek:

• Amire szüksége van egy virtuális felület létrehozásához.
• Milyen virtuális hálózatot kell létrehoznia (VM)?
• Melyik VRF-hez (VN) kell kötni.
• Statikus ARP-bejegyzés ehhez a virtuális géphez – milyen interfészen található az IP-címe, és milyen MAC-címhez van kötve.

A tényleges interakciós eljárást ismét leegyszerűsítettük a fogalom megértése érdekében.

Így a vRouter egy adott gépen egy kliens összes virtuális gépét közvetlenül csatlakoztatott hálózatnak tekinti, és maga is tud közöttük útvonalat vezetni.

De a VM0 és a VM1 különböző kliensekhez tartoznak, és ennek megfelelően különböző vRouter táblákban vannak.

Az, hogy közvetlenül tudnak-e kommunikálni egymással, a vRouter beállításaitól és a hálózat kialakításától függ.
Például, ha mindkét kliens virtuális gépe nyilvános címeket használ, vagy a NAT magán a vRouteren fordul elő, akkor közvetlen útválasztás végezhető a vRouterhez.

Ellenkező esetben lehetőség van a címterek keresztezésére – a nyilvános cím megszerzéséhez egy NAT-szerveren kell keresztülmenni – ez hasonló a külső hálózatokhoz való hozzáféréshez, amiről az alábbiakban lesz szó.

Kommunikáció a különböző fizikai gépeken található virtuális gépek között

Adat sík

1. A kezdet pontosan ugyanaz: a VM-0 egy csomagot küld a VM-7 célállomással (172.17.3.2).
2. A vRouter fogadja, és ezúttal azt látja, hogy a cél egy másik gépen van, és a Tunnel0-n keresztül érhető el.
3. Először a távoli interfészt azonosító MPLS címkét akasztja fel, így a hátoldalon a vRouter további keresések nélkül meghatározhatja, hová helyezze ezt a csomagot.

   

4. A Tunnel0 forrása 10.0.0.2, célhelye: 10.0.1.2.
   A vRouter GRE (vagy UDP) fejléceket és új IP-címet ad az eredeti csomaghoz.
5. A vRouter útválasztási táblázat alapértelmezett útvonallal rendelkezik a 1 ToR10.0.0.1 címen keresztül. Oda küldi.

   
   

6. A ToR1, mint az Underlay hálózat tagja, tudja (például OSPF-en keresztül), hogyan kell eljutni a 10.0.1.2-hez, és az útvonalon elküldi a csomagot. Vegye figyelembe, hogy az ECMP itt engedélyezve van. Két nexthop van az illusztráción, és a különböző szálak hash alapján lesznek besorolva. Egy igazi gyár esetében valószínűbb, hogy 4 nexthop lesz.

   Ugyanakkor nem kell tudnia, mi van a külső IP fejléc alatt. Vagyis valójában IP alatt lehet egy IPv6 szendvics MPLS felett Etherneten keresztül MPLS felett GRE felett, görög felett.

7. Ennek megfelelően a fogadó oldalon a vRouter eltávolítja a GRE-t, és az MPLS címkét használva megérti, hogy melyik interfészre kell ezt a csomagot elküldeni, eltávolítja és eredeti formájában elküldi a címzettnek.

Irányító sík

Amikor elindítja az autót, ugyanaz történik, mint fentebb.

És plusz a következők:

• A vRouter minden klienshez MPLS címkét rendel. Ez az L3VPN szolgáltatáscímke, amellyel az ügyfelek ugyanazon a fizikai gépen belül lesznek elválasztva.
  

  Valójában az MPLS címkét mindig feltétel nélkül osztja ki a vRouter - elvégre nem lehet előre tudni, hogy a gép csak más gépekkel fog kommunikálni ugyanazon vRouter mögött, és ez nagy valószínűséggel nem is igaz.

• A vRouter kapcsolatot létesít az SDN vezérlővel a BGP protokoll segítségével (vagy ahhoz hasonló - TF esetén ez XMPP 0_o).
• Ezen a munkameneten keresztül a vRouter a csatlakoztatott hálózatokhoz vezető útvonalakat jelenti az SDN-vezérlőnek:
  • Hálózati cím
  • Tokozási módszer (MPLSoGRE, MPLSoUDP, VXLAN)
  • MPLS kliens címke
  • Az IP-címed, mint nexthop

• Az SDN-vezérlő megkapja ezeket az útvonalakat az összes csatlakoztatott vRoutertől, és visszaadja azokat másoknak. Vagyis Útvisszaverőként működik.

Ugyanez történik az ellenkező irányban is.

A fedvény legalább percenként változhat. Nagyjából ez történik a nyilvános felhőkben, ahol az ügyfelek rendszeresen elindítják és leállítják virtuális gépeiket.

A központi vezérlő gondoskodik a konfiguráció karbantartásának és a vRouter kapcsolási/útválasztási tábláinak felügyeletének minden bonyolultságáról.

Nagyjából elmondható, hogy a vezérlő az összes vRouterrel BGP-n (vagy hasonló protokollon) keresztül kommunikál, és egyszerűen továbbítja az útválasztási információkat. A BGP-nek például már van Address-Family-je a beágyazási módszer közvetítésére MPLS-in-GRE vagy MPLS-in-UDP.

Ugyanakkor az Underlay hálózat konfigurációja semmit sem változik, ami egyébként sokkal nehezebben automatizálható, és egy kínos mozdulattal könnyebb megtörni.

Kilépés a külvilágba

Valahol véget kell érnie a szimulációnak, és ki kell lépnie a virtuális világból a valós világba. És szükség van egy nyilvános telefon átjáróra.

Két megközelítést alkalmaznak:

1. Hardveres útválasztó van telepítve.
2. Elindul a router funkcióit megvalósító készülék (igen, az SDN-t követően VNF-fel is találkoztunk). Nevezzük virtuális átjárónak.

A második megközelítés előnye az olcsó vízszintes skálázhatóság - nincs elég teljesítmény - újabb átjárós virtuális gépet indítottunk. Bármilyen fizikai gépen anélkül, hogy szabad állványokat, egységeket, teljesítményt kellene keresni, magát a hardvert megvenni, szállítani, telepíteni, kapcsolni, konfigurálni, majd a hibás alkatrészeket is kicserélni benne.

A virtuális átjáró hátránya, hogy a fizikai útválasztó egysége még mindig nagyságrendekkel erősebb, mint egy többmagos virtuális gép, és szoftvere a saját hardverbázisára szabva sokkal stabilabban működik (nincs). Azt is nehéz tagadni, hogy a hardver-szoftver komplexum egyszerűen működik, csak konfigurációt igényel, míg a virtuális átjáró elindítása és karbantartása erős mérnökök feladata.

Az átjáró egyik lábával az Overlay virtuális hálózatba néz, mint egy hagyományos virtuális gép, és kölcsönhatásba léphet az összes többi virtuális géppel. Ugyanakkor az összes kliens hálózatát lezárhatja, és ennek megfelelően útválasztást végezhet közöttük.

A másik lábával az átjáró a gerinchálózatba néz, és tudja, hogyan férhet hozzá az internethez.

Adat sík

Vagyis a folyamat így néz ki:

1. A VM-0, miután alapértelmezetten ugyanazt a vRoutert használja, egy csomagot küld a külvilágban (185.147.83.177) az eth0 interfészre.
2. A vRouter megkapja ezt a csomagot, és megkeresi a célcímet az útválasztási táblázatban – megkeresi az alapértelmezett útvonalat a VNGW1 átjárón keresztül az 1. alagúton keresztül.
   Azt is látja, hogy ez egy GRE alagút SIP 10.0.0.2-vel és DIP 10.0.255.2-vel, és először hozzá kell csatolnia ennek a kliensnek az MPLS címkéjét, amit a VNGW1 elvár.
3. A vRouter a kezdeti csomagot MPLS-sel, GRE-vel és új IP-fejlécekkel csomagolja, és alapértelmezés szerint elküldi a ToR1 10.0.0.1-nek.
4. Az alapul szolgáló hálózat továbbítja a csomagot a VNGW1 átjáróhoz.
5. A VNGW1 átjáró eltávolítja a GRE és MPLS alagútfejlécet, látja a célcímet, megnézi az útválasztási táblát, és megérti, hogy az internetre van irányítva – vagyis teljes nézeten vagy alapértelmezetten keresztül. Ha szükséges, elvégzi a NAT fordítást.
6. Lehetne egy rendes IP hálózat a VNGW-től a határig, ami nem valószínű.
   Lehet klasszikus MPLS hálózat (IGP+LDP/RSVP TE), lehet egy hátsó szövet BGP LU-val vagy egy GRE alagút a VNGW-től a határig IP hálózaton keresztül.
   Bárhogy is legyen, a VNGW1 elvégzi a szükséges beágyazásokat, és elküldi a kezdeti csomagot a határ felé.

Az ellenkező irányú forgalom ugyanazokon a lépéseken megy keresztül, ellenkező sorrendben.

1. A szegély ledobja a csomagot a VNGW1-re
2. Levetkőzteti, megnézi a címzett címét, és látja, hogy elérhető az Tunnel1 alagúton (MPLSoGRE vagy MPLSoUDP).
3. Ennek megfelelően egy MPLS címkét, egy GRE/UDP fejlécet és egy új IP-címet csatol, és elküldi a ToR3 10.0.255.1-re.
   Az alagút célcíme annak a vRouternek az IP-címe, amely mögött a cél virtuális gép található – 10.0.0.2.
4. Az alapul szolgáló hálózat eljuttatja a csomagot a kívánt vRouterhez.
5. A cél vRouter beolvassa a GRE/UDP-t, az MPLS címke segítségével azonosítja az interfészt, és egy csupasz IP-csomagot küld a virtuális gép eth0-jához társított TAP-interfészére.

Irányító sík

A VNGW1 egy BGP szomszédságot hoz létre egy SDN-vezérlővel, ahonnan megkapja az összes útválasztási információt a kliensekről: melyik kliens mögött melyik IP-cím (vRouter) van, és melyik MPLS-címke azonosítja.

Hasonlóképpen, ő maga tájékoztatja az SDN vezérlőt az alapértelmezett útvonalról ennek a kliensnek a címkéjével, és magát nexthop-ként jelöli meg. És akkor ez az alapértelmezett megérkezik a vRouterekhez.

A VNGW-n általában útvonal-összesítés vagy NAT-fordítás történik.

A másik irányba pedig pontosan ezt az összesített útvonalat küldi el a munkamenethez szegélyekkel vagy Route Reflektorokkal. És tőlük megkapja az alapértelmezett útvonalat vagy Full-View-t, vagy valami mást.

A tokozás és a forgalomcsere szempontjából a VNGW nem különbözik a vRoutertől.
Ha kicsit bővíti a hatókört, akkor a VNGW-khez és a vRouterekhez további hálózati eszközöket is hozzáadhat, például tűzfalakat, forgalomtisztító vagy dúsító farmokat, IPS-t és így tovább.

A VRF-ek szekvenciális létrehozásával és az útvonalak helyes bejelentésével pedig rákényszerítheti a forgalmat a kívánt módon történő hurokra, amit szolgáltatásláncnak neveznek.

Vagyis itt is az SDN vezérlő Route-Reflektorként működik a VNGW-k, vRouterek és más hálózati eszközök között.

Valójában azonban a vezérlő információkat ad ki az ACL-ről és a PBR-ről (Policy Based Routing), így az egyes forgalmi áramlások az útvonaltól eltérően haladnak.

FAQ

Miért teszed folyton a GRE/UDP megjegyzést?

Nos, általánosságban elmondható, hogy ez a Tungsten Fabricra jellemző - egyáltalán nem kell figyelembe vennie.

De ha úgy vesszük, akkor maga a TF, miközben még OpenContrail, mindkét tokozást támogatta: az MPLS-t GRE-ben és az MPLS-t UDP-ben.

Az UDP azért jó, mert a Source Portban nagyon könnyen lehet a fejlécébe kódolni egy hash függvényt az eredeti IP+Proto+Portból, amivel lehetõvé válik az egyensúlyozás.

A GRE esetében sajnos csak külső IP és GRE fejlécek vannak, amik minden beágyazott forgalomnál ugyanazok, és szó sincs egyensúlyozásról - kevesen tudnak ilyen mélyre nézni a csomagban.

Egy ideig az útválasztók, ha tudták a dinamikus alagutak használatát, csak az MPLSoGRE-ben tették ezt, és csak a közelmúltban tanulták meg az MPLSoUDP használatát. Ezért mindig meg kell jegyeznünk két különböző tokozás lehetőségét.

Az őszinteség kedvéért érdemes megjegyezni, hogy a TF teljes mértékben támogatja az L2 csatlakozást a VXLAN használatával.

Megígérted, hogy párhuzamot vonsz az OpenFlow-val.
Tényleg ezt kérik. A vSwitch ugyanabban az OpenStackben nagyon hasonló dolgokat csinál, VXLAN-t használva, aminek egyébként UDP fejléce is van.

Az adatsíkon megközelítőleg ugyanúgy működnek, a vezérlési sík jelentősen eltér. A Tungsten Fabric az XMPP segítségével továbbítja az útválasztási információkat a vRouternek, míg az OpenStack az Openflow-t futtatja.

Mondana egy kicsit többet a vRouterről?
Két részre oszlik: vRouter Agent és vRouter Forwarder.

Az első a gazdagép operációs rendszer felhasználói területén fut, és kommunikál az SDN-vezérlővel, információt cserélve az útvonalakról, a VRF-ekről és az ACL-ekről.

A második a Data Plane - általában Kernel Space-ben, de akár SmartNIC-en is futtatható - hálózati kártyákat valósít meg CPU-val és külön programozható kapcsolóchippel, amivel eltávolítható a gazdagép CPU-járól a terhelés, és gyorsabbá és többbbé tehető a hálózat. kiszámítható.

Egy másik lehetséges forgatókönyv az, hogy a vRouter egy DPDK-alkalmazás a User Space-ben.

A vRouter Agent elküldi a beállításokat a vRouter Forwardernek.

Mi az a virtuális hálózat?
A VRF-ről szóló cikk elején említettem, hogy minden bérlő saját VRF-hez van kötve. És ha ez elég volt az overlay hálózat működésének felületes megértéséhez, akkor a következő iterációnál pontosításokat kell tenni.

Általában a virtualizációs mechanizmusokban a Virtual Network entitást (ezt tekinthetjük tulajdonnévnek) az ügyfelektől/bérlőktől/virtuális gépektől elkülönítve vezetik be - ez egy teljesen független dolog. Ez a Virtuális Hálózat pedig már interfészeken keresztül csatlakoztatható egyik bérlőhöz, egy másikhoz, kettőhöz vagy bárhová. Így például a Service Chaining akkor valósul meg, amikor a forgalmat bizonyos csomópontokon kell átadni a kívánt sorrendben, egyszerűen virtuális hálózatok létrehozásával és összekapcsolásával a megfelelő sorrendben.

Ezért, mint ilyen, nincs közvetlen kapcsolat a Virtuális Hálózat és a bérlő között.

Következtetés

Ez egy nagyon felületes leírása egy virtuális hálózat működésének a gazdagéptől és egy SDN-vezérlővel rendelkező overlay-vel. De mindegy, milyen virtualizációs platformot választunk ma, az hasonlóan fog működni, legyen az VMWare, ACI, OpenStack, CloudStack, Tungsten Fabric vagy Juniper Contrail. Különböznek a tokozások és fejlécek típusaiban, a véghálózati eszközökhöz való információtovábbítás protokolljaiban, de a szoftverrel konfigurálható overlay hálózat elve, amely egy viszonylag egyszerű és statikus alátéthálózaton működik, ugyanaz marad.
Elmondhatjuk, hogy ma az overlay hálózaton alapuló SDN nyerte meg a privát felhő létrehozásának terepet. Ez azonban nem jelenti azt, hogy az Openflow-nak ne lenne helye a modern világban – az OpenStacke-ben és ugyanabban a VMWare NSX-ben is használják, ha jól tudom, a Google ezt használja a földalatti hálózat kiépítésére.

Az alábbiakban linkeket adtam meg részletesebb anyagokhoz, ha mélyebben szeretné tanulmányozni a kérdést.

És mi a helyzet az alátétünkkel?

De általában semmi. Nem változott az egész úton. A gazdagéptől érkező átfedés esetén mindössze annyit kell tennie, hogy frissíti az útvonalakat és az ARP-ket, amikor a vRouter/VNGW megjelenik és eltűnik, és csomagokat szállít közöttük.

Fogalmazzuk meg az Underlay hálózat követelménylistáját.

1. Legyen képes valamilyen útválasztási protokollt használni, a mi helyzetünkben - BGP.
2. Legyen széles sávszélesség, lehetőleg túljelentkezés nélkül, hogy a csomagok ne vesszenek el a túlterhelés miatt.
3. Az ECMP támogatása a szövet szerves része.
4. Legyen képes QoS szolgáltatást nyújtani, beleértve az olyan trükkös dolgokat is, mint az ECN.
5. A NETCONF támogatása a jövő alapja.

Nagyon kevés időt szenteltem itt magának az Underlay hálózat munkájának. Ennek az az oka, hogy a sorozat későbbi részében erre fogok koncentrálni, az Overlay-t pedig csak futólag érintjük.

Nyilvánvalóan erősen korlátozok mindannyiunkat azzal, hogy példaként egy Cloz-i gyárban épített egyenáramú hálózatot használok, tiszta IP-útválasztással és átfedésekkel a gazdagéptől.

Meggyőződésem azonban, hogy minden hálózat, amelynek van tervezése, formálisan leírható és automatizálható. Csak az a célom, hogy megértsem az automatizálás megközelítéseit, és ne zavarjak meg mindenkit a probléma általános megoldásával.

Az ADSM részeként Roman Gorge és én egy külön szám kiadását tervezzük a számítási teljesítmény virtualizációjáról és a hálózati virtualizációval való kölcsönhatásáról. Maradj kapcsolatban.

Hasznos Linkek

• Volfrámszövet építészet.
• about:cloud. 6 óra a Yandex.Cloudról, amely a TF virtuális hálózatát is lefedi.
• Mi az az Open vSwitch?
• Bevezetés a VxLAN-ba.
• RFC 7348. Virtuális bővíthető helyi hálózat (VXLAN): Keretrendszer a virtualizált 2. rétegű hálózatok 3. rétegű hálózatokon való átfedésére.
  
• Scaleway megközelítés a VXLAN EVPN Fabrichoz. A teljes egyenáramú hálózatról szól, beleértve az Underlay-t, az Overlay-t, a több-homing és a menedzsment megközelítéseit.

Köszönöm

• Roman Gorga - a linkmeup podcast egykori házigazdája, jelenleg pedig a felhőplatformok szakértője. Megjegyzésekhez és szerkesztésekhez. Nos, a közeljövőben várjuk a virtualizációról szóló részletesebb cikkét.
• Alekszandr Shalimov - kollégám és szakértőm a virtuális hálózatfejlesztés területén. Megjegyzésekhez és szerkesztésekhez.
• Valentin Sinitsyn - kollégám és szakértőm a volfrámszövet területén. Megjegyzésekhez és szerkesztésekhez.
• Artyom Csernobay — Illusztrátor linkmeup. A KDPV számára.
• Alekszandr Limonov. Az "automata" mémhez.

Forrás: will.com