Mikor elkezdtem ismerkedni az NSX-el egyszerűbbnek bizonyult szétválasztani a képességeit. Aláírom, hogy ez így talán túlzottan is kisarkított csoportosítás, de szerintem a termék három fő funkciója a mikroszegmentáció (distributed firewall, spoofguard), az overlay képesség és a distributed routing. Előbbi működik az utóbbi kettő nélkül és ez fordítva is megállja a helyét.
Sok ügyfélnél a belépési pont a mikroszegmentáció igénye, mivel az overlay képességre kevésbé van szükségük. Az overlay közepes és nagy-vállalatoknál lehet érdekes, de sokuk pedig – ha szükségük volt/van rá – megoldották másképp a L2 transzparenciát – a virtualizációtól függetlenül. Így ez utóbbi képesség ritkán jelenti azt az igényt, hogy miért lenne jó az NSX-et bevezetni náluk. Ennek ellenére rengeteg ok szól amellett, hogy miért vegyük le a hálózati réteg hátáról a „terhet” ami a VMware környezeten kívül történő útválasztást jelenti abban az esetben, amikor mind a forrás, mind a cél virtuális gép – ráadásul akár egymás mellett futnak azonos hoszton.
A mikroszegmentációt (minden VM esetében külön szűrés) a Cisco ACI-on kívül csak kliens oldali megoldásokkal lehet megoldani, Ez meg mindig mindig kockázati tényező illetve több erőforrást is használ, speciális fizikai eszközökre is szükség van.
Lássuk a kiindulási rendszert:
Ha a piros VM a 10.1.210.10/24 forrásról a kék VM-el szeretne kommunikálni, ami a 10.1.211.10/24 IP-vel rendelkezik, akkor az útválasztás a DC SW-n történik. Egy VLAN-nál ez nem probléma, sőt 1000-nél sem, viszont egy dinamikusan változó környezetben, ahol jönnek-mennek a VLAN-ok – bocsánat…szegmensek – szép munkával láthatja el a hálózatos kollégákat.
Lássuk ugyanezt a példát és nézzük meg mi történik akkor ha a két VM azonos hoszton helyezkedik el:
Kis környezetben vagy alacson inter-VLAN forgalom esetén – vagy éppen ha a hosztok komoly uplink-ekkel bírnak – nem jelent problémát, hogy legrosszabb esetben a két VLAN forgalma ugyanazon a fizikai kábelen osztozik. Azonban optimalizációra mindig van lehetőség és itt jön a képbe a distributed routing – bocsánat distributed logical routing. Mi lenne ha az ilyen szegmensek forgalmát akár hoszton belül lehetne tartani. Máris hallom a tömegeket, amik azt skandálják, hogy sokkal olcsóbb és egyszerűbb a két VM-et egy szegmensbe tenni. Akkor fordulhatna a vSwitch-en a forgalom. Szuper ötlet, főleg akkor, ha sok VM van – ekkor lehet szép nagy alhálózatot csinálni – és persze ez jól el is lehetetleníti az adatközponton belüli forgalom szegmentációját. Egy szegmensen belül azért elég nehéz tűzfallal kontrollálni hogy honnan, hová, milyen porton és milyen irányba engedem/tiltom a kommunikációt. Az optimálisabb útválasztás oltárán fel kell áldozni a biztonságot.
Aki erre nem hajlandó és még mindig nem zárta be ezt az ablakot, amiben ezt a posztot olvassa, világossá válhatott hogy pontosan mindkettőt megvalósítjuk NSX-ben.
Amennyiben a VLAN210-ben és VLAN211-ben csak olyan gépek vannak, amelyek virtuálisak, a feladat egyszerű. Létrehozunk egy DLR-t és két Logical Switch-et és lehozzuk a gateway-eket a DLR szintjére.
Ennek folyamata azonban diszruptív, több okból is. Mindkét VM a változtatás előtt VLAN alapú port group-on van, ezeket módosítani kell a vxlan alapú PG-re – LS_210 és LS_211. Amint ez megtörténik, el is vesztik a világgal a kalcsolatot, egészen addig amíg a DC SW-ről a GW-t le nem vesszük, és azt fel nem vesszük a DLR-ben az LS_210 és LS_211-hez kapcsolt LIF – logical interface – entitásokra. Ezért mielőtt ezt végrehajtanánk meg kell emlékezni a bridging-ről. A LS-eket lehetséges bridge-ben használni, ezáltal az LS-hez kapcsolt VM is képes kommunikálni a világgal azalatt is, amíg felkészülünk a GW átállítására.
Mivel a példában két VLAN szerepel, ezért két „Bridge” lesz a DLR-en. A nevük lehet akrámi, de az „Logical Switches” résznél értelemszerűen az LS_210/LS_211-et kell választani és a VLAN_210/VLAN_211-et. Ahhoz hogy ezt megtehessük szükség van a Control VM-re és ha jót akarunk, akkor HA-ban telepítsük le őket. Lényeges, mivel az aktív Control VM-et futtató hoszt valósítja meg a bridge-et, ezáltal ha nem HA-ban konfiguráltuk, akkor a hoszt kiesése esetén nem lesz bridge.
Ez egy migrációs állapotnak fogható fel. Amint a GW-t felvesszük az LIF-ekre, a bridge-ek megszüntethetőek.
A gateway DLR-re felvétele nem igazán bonyolult, de ha eddig nem is volt kiesésünk, akkor most lesz. Amint a DC SW-ről levesszük a VLAN interfészt a gépek elérhetetlenek lesznek a más szegmensekből, legyenek azok VMware-ben vagy a fizikai világban. Megszüntetjük a bridge-eket és felvesszük az interfészt a DLR-re, konfigurálva a GW IP-jét az adott szegmensen.
Ez a lépés fontos, a rendelkezésre állás miatt. Amint megszűnik a bridge, a forgalom lekerül minden hoszton az ESXi kernelébe, azaz minden hoszt ami benne van az adott transport zónában és létezik a szükséges vDS rajta, részt vesz a distributed routing-ban.
Ha ez megvan, akkor a külvilággal is tudani kell, hogy ez a két szegmens mostantól merre található. Amennyiben a DLR létrehozásakor hoztunk létre Control VM-et, akkor lehetőség van dinamikus útválasztási protokollok használatára – OSPF,BGP – ha nem akkor statikus route-okkal kell operálni. A fenti ábrán van egy ESG is, ami elengedhetetlenül szükséges. Az valósítja meg a virtualizált és a fizikai világ kapcsolatát, azaz ő kezeli az észak-déli forgalmat a VMware környezet határán, neki is hirdetnie kell a világ felé hogy a 10.1.210.0/24 és a 10.1.211.0/24 a DLR irányában van.
Ez a sok munka mire volt jó?
- Optimalizáltuk az útválasztást. Mostantól a szegmensek között hoszton belül történik a routing is.
- Dinamikusabbá/automatizálhatóbbá és átláthatóbbá tettük VLAN/vxlan struktúrát. A VMware NSX admin képes létrehozni szegmenseket – vxlan-ból azért lehet pár millió – módosítani és törölni őket. Akár egy automatizációs megoldás is képes erre RestAPI-n.
- Megőriztük az optimális routing képességet és a mikroszegmentációs képességekkel együtt.
- Különösen sok disztribúciót alkotó DC-nél sokkal hatékonyabb struktúrát lehet alkotni, nem kell mindennek L2 blob-nak lennie, ezért nincs annyi fölös BUM traffic, sokkal kisebb a failure domain, mégis tud mindenki L2-ben kommunikálni
- Különösen multi-tenant környezetben könnyen elfogyhat 4096 VLAN.
- CAM table size – Egy mai modern virtualizált szerverekkel telerakott rack akár 1000VM-et is képes kiszolgálni. Ha soronként számolunk egy switch párral, akkor azokban már túlnőhet a szükséges bejegyzések száma a CAM táblában.
