Mielőtt folytatnám a telepítés menetét és egyéb beállításokat, úgy gondolom hogy érdemes tisztázni a későbbiekben szükséges NSX-T elemek fogalmát, miértjét és lehetőségeit.
Az NSX-V-ben két „fő komponens” volt, a Distributed Logical Router (DLR), ami az kelet-nyugati forgalomért felelt, illetve az Edge Services Gateway, ami pedig az észak-déliért. Ez utóbbi valósította lényegében a virtuális hálózat, fizikai hálózatra történő továbbítását. Természetesen lehetett őket magas rendelkezésreállásra is konfigurálni, ami lényegében az aktív/standby párjukat jelentette, ekkor lehetett stateful szolgáltatásokat is futtatni rajtuk (firewall, VPN stb.) de ha ilyenre nem volt szükség, akkor egy instance-ban lehetett akár nyolc darab is, ekkor ECMP-vel mindegyik aktív lehetett, igazán nagy észak-déli sávszélességet biztosítva.
Na az NSX-T ezzel szemben teljesen más, ezek nincsenek, illetve vannak, de más formában, kicsit talán jöbban átgondolva.
Multi tier lehetőségek
Eddig is volt lehetőség több tier-ből álló kialakításra az NSX-V-ben. Nézzük csak meg az alábbi ábrát. A bal oldalon egy egyetlen tier-ből álló megvalósítás látszik – nem rajzoltam be HA-t/ECMP-t – két DLR, egy ESG és kész. Ez nem annyira szolgáltatói design, szóval ha több tenant van, akkor nekik vagy saját ESG-ket kellett létrehozni vagy a jobb oldalon látható módra átalakítani a hálózatot. Az első esetben fontos, hogy a forgalom a tenant-ok között mindenképpen kilépne a virtualizációból. Ezért jobb talán az utóbbi – a jobb oldali – architektúra. A „Tier 1” a tenant hálózata, a „Tier 0” pedig a szolgáltatóé. Természetesen ezeket lehet keverni is, szóval a „Tier 1” HA módban van, a „Tier 1” pedig ECMP-ben. Ekkor a „Tier 1” lesz a perimeter tűzfal a tenant szemszögéből, a „Tier 0” pedig inkább csak a felhordó-infrastuktúra.
Hozzáteszem, hogy a fenti ábrán a T0 és T1 közötti tranzit hálózatot minden esetben létre kellett hozni.
NSX-T-ben ha tetszik, ha nem, a jobb oldali az alap, már az elnevezésben is követik a tiered fogalmakat. Természetesen nem szükséges mondjuk, mint a tier-1-t, mind a tier 0-t meg is valósítani, igényektől függően néha elég csak a tier 0 réteg. Ez furcsán hangzik tudom, de az NSX-T-ben a Tier 0 konstrukt képes csak ellátni a virtuális hálózat és a fizikai hálózat interfészét. A Tier 1-nek csak Logical switch irányba lehet downlink-je és egy – és csakis egy!! – Tier 0-hoz lehet uplink-je. Mikor nem érdemes csak egy Tier-0-val réteggel megoldani a dolgokat? Akkor, ha például load balancer szolgáltatást szeretnék ebben a rétegben, na akkor kell Tier-1 mindenképpen, csak ott használható az NSX ilyen funkciója. A NAT mindkét tier-ben működik egyébként.
Tier = Logical Router és Services Router (ha kell)
Ami szerintem nagyon érdekes, hogy minden tier-nek két része van. Egy úgynevezett Distributed Router(DR) és egy Services Router(SR).
A DR – nevéhez méltóan – „distributed”, azaz minden hoszton ott van, amelyik az adott transport zone tagja. Szóval ha például a fenti ábra bal oldalán – a csak Tier-0-s képen – bármelyik virtuális gép kommunikálni szeretne a másikkal, akkor azt akár a hypervisor kernelében megtehetik, ha pedig nem egy hoszton vannak, akkor a két hipervisor egymás között egy tunnel-ben ezt leforgalmazza, nem jön ki a forgalom, végképp nem a fizikai hálózatra. Ez igaz a jobb oldalon lévő two tier megoldásra is, de értelemszerűen csak egy T1 alatt lévő gépek tudnak egymással kommunikálni így, T1-ek között a T0-ig fel kell menni ha forgalmazni szeretnénk.
Az SR, pedig olyan dolgokat végez amelyek már az említett stateful dolgok lehetnek. Így például NAT, tűzfal, LB – csak Tier 1 esetén tudja – VPN – csak Tier 0 esetén tudja – DHCP.
A DR és az SR kapcsolata automatikusan jön létre, 169.254-es APIPA címek segítségével. Igaz ez a Tier 1 és Tier 0 összekapcsolására is, itt már nekünk nem kell gondoskodni a tranzitról, automatikusan létrejön, alapesetben a 100.64.0.0/10 tartományból kihasított /31 tartományban – jóhogy, mivel azon a downlink-en maximum két eszköz lesz.
Egy Tier 0 router-hez, 400 Tier 1 kapcsolható! És több Tier-0 lehet egy telepítésben.
Minden SR komponens az Edge Node-on/okon koncentrálódik. Ez lehet virtuális és fizikai is (NSX-V-nél ez csak virtuális lehetett). Tudom még fokozni, mert egy Edge képes több Tier-nek is szolgáltatni az SR szolgáltatásokat. Na itt volt nekem az a pont, ahol tartanom kellett pár nap szünetet a tanulásban, mert ez túlterhelte az agyamat. Szóval egy edge VM-ben – vagy egy párban HA esetén vagy ECMP-vel – több SR lehet és ezek az SR-ek lényegében csak VRF-ek -virtual routing and forwarding – az Edge gépben.
Az ilyen Edge Node-okból – virtuális gépekből vagy bare metal – készíthető egy Edge Cluster. Itt megint problémát okozott megemészteni, hogy az NSX-V-ben az Edge Cluster terminus egy ESXi klasztert jelentett. NSX-T-ben meg egy ilyen shell-t, ami tulajdonképpen a helye a T0/T1 SR-eknek.
Ez csak egy példa a VM formátumra, bare metal esetén négy NIC használható. Az is fontos, hogy a T1 és T0 SR komponenseknek nem kell szükségszerűen egy Edge-en/Edge Cluster-en lenniük. Így építhető olyan környezet is, ahol a load balancing-ot egy bizonyos edge klaszter végzi, a kifelé irányuló forgalmat meg egy másik. Olyan is elképzelhető hogy a T0 SR funkciókat egy, a T1 funkciókat egy másik. Az is lehet, hogy minden tenant saját Edge klasztert kap a T1 funkciókra.
A következő részben innnen folytatjuk.
Eddigi részek:
