Az NSX 4.1 megjelenésével a VMware egy igen régi adósságát törlesztette, mégpedig a multitenant működés támogatását. A „Projects” kivesézése előtt még egy helyen láthatunk erre utaló jeleket. (Ha frissítenél vagy frissítetél akkor ügyelj a böngésződ „English”-re állításán a GUI bug miatt – lsd előző cikkem.)
NSX Manager – vCenter Server – több az egyhez
Korábban az NSX Manager és a vCenter Server kapcsolata N:1 volt. Tehát az NSX Manager képes volt több vCenter instanciát kezelni, de egy vCenter csak egy NSX Manager-hez tartozhatott – ha jót akartál. Ez változott és amennyiben a Workload Management – Tanzu – be van kapcsolva vagy éppen vLCM-et használsz, akkor nem használható – általában keveseket fenyeget ez.
Fontos hogy egy klasztert, egy hosztot, egy distributed vSwitch-et csak egyetlen NSX használhat, tehát csak akkor van értelme a fent képességnek ha több klaszter vagy több standalone hoszt van a vCenter-ben és más vDS-ek vannak rajtuk.
A bal oldalon egy 4.0.1.1-et láthattok, a jobb oldalon a 4.1-et.
Projects
Más nevén tenant, mindegy hogy pontosan hogyan hívják, a bal felső sarokban látható ennek nyoma. Ha friss telepítésről van szó vagy éppen most történt meg az upgrade, akkor igazából kettő elem van a listában ami látható.
- All Projects: Itt globális nézet található minden projekt, minden azokban található objektumával és beállításával. Ez egy read only nézet, nincs módosítási lehetőség.
- Default: A korábban ismert nézet – ami eddig az egyetlen volt – ez felfogható innentől egy service provider-i nézetnek. Minden NSX beállítás itt történik meg és ebből a szerepkörből bizonyos objektumok mentén lehet delegációt létrehozni a projektek képében.
A bemutatásához létrehoztam a következőket (a default nézetben):
- Parent-T0 – ez a valódi Tier0 entitás.
- Tenant1-VRF – ez a Parent-T0-n értelmezett VRF a Tenant1 projekthez
- Tenant2-VRF – ez a Parent-T0-n értelmezett VRF a Tenant2 projekthez
(Project) Tenant létrehozása
A „Manage Projects” alatt kell létrehozni a projektet, amiben bár nem kötelező – ekkor nem lesz az észak-déli ki/bejárata – kell beállítani a Tier-0/VRF-et, ami alatt az elválasztás megtörténik. Egy vagy több ilyen Tier-0/VRF-et ki lehet választani egy projekt számára. A „short log identifier” is lényeges mert a naplózásban ezzel fog könnyebben kereshetővé válni a kontextus. Ha nem írunk be semmit, akkor a projekt neve lesz az alapértelmezett, azonban utólag nem lehetséges ezt megváltoztatni!
Az Edge Clusters résznél meg lehet adni azt, hogy a létrehozásra kerülő elemek, amelyek az Edge Node-on realizálódnak, valójában hol realizálódjanak. A rendszerek túlnyomó többségében a Tier0 és a Tier1 azonos Edge Cluster-t használ, de van lehetőség – eddig is volt – ezek elválasztására, itt pedig a projektek kezelése során ki is kényszeríti a rendszer.
(Quotas) Kvóták beállítása
A kvóták adják meg, hogy milyen entitásból mennyit – ha egyáltalán – hozhatunk létre. Ezek kialakításánál nagyon szabadságot ad a rendszer, hiszen lehet egy kvóta több projekthez rendelve, de projektekhez akár külön külön más kvóta is tartozhat.
A limit gomb megnyomása után három fő kategória jelenik meg, azok alatt pedig még több entitás:
- Networking:
- Tier-1 Gateway
- Segment
- Segment Port
- NAT Rule
- DNS Service
- DNS Zone
- IP Address Pool
- IP Address Pool Subnet
- IP Address Block
- IP Address Allocation
- ND Profile
- DAD Profile
- Gateway QoS Profile
- DHCP Relay
- DHCP Server
- Security
- Distributed Firewall Security Policy
- Distributed Firewall Rules
- Gateway Firewall Policy
- Gateway Firewall Rules
- Inventory:
- Service
- Service Entry
- Group
- Context Profile
- L7 Access Profile
A Tenant1 – és Tenant2 – projekt számára engedélyezem két Tier-1 Gateway és 2 szegmens létrehozását.
Tesztelés
A teszt kezdetén a projektek kiválasztásánál a Tenant1-et jelölöm ki. Egyből látható is a különbség, hiszen a GUI-ról nagyon sok opció el is tűnik, így például az alábbi képen a „Tier-0 Gateways” is láthatatlanná válik. Létre is hozok három T1-et és megnézzük mit ír ki, mivel kettő a limit.
A harmadik létehozása során egy barátságos üzenettel közli hogy nem fog menni. Kihámozható hogy azért mert csak kettő engedélyezett.
A szegmensekből is létrehozok kettőt.
A fenti két lépést megismétlem a Tenant2-vel is.
Ha ezek után lenyitjuk a menüt és kiválasztjuk a „Default” nézetet, ami ugye az volt eddig, amin a Tier0-t és a VRF-eket létrehoztam, illetve az egész NSX-et úgy alapjaiban konfiguráltam, akkor a tenantok által látrehozott objektumokat nem is fogom látni.
Azonban ha a „Network Topology”-t választom ki akkor a térképen azért megmutatja. Lehet hogy ez bug, nem tudom.
Sokkal lényegesebb, hogy ezeket igazából az „All Projects” nézetben listázza és elég jól mutatja is hogy melyik projektben hozták létre, melyikhez tartozik. Említettem korábban, hogy ez áttekintést ad, de csak read only.
A projektekhez jogosultságot lehet adni akár NSX lokális vagy éppen valamilyen külső forrásból authentikált felhasználók és csoportok számára.
Quality of life improvement(s)
Végre valahára a compute manager-nél nem kell a „None: Standalone Hosts”-ról a kívánt vCenter-re állítani az ablakot, alapból mutat mindent.
A „Transport Node Profile” átkerült a „Fabric-> Hosts” alá.
Sub Transport Node Profile – Korábban megjelent képesség, amelyekről keveset lehetett eddig olvasni
Láttam már olyan NSX telepítést, ahol a transport node profile nem a vSphere klaszter szintjén volt beállítva és bár annak oka determinisztikus TEP IP-cím kosztás volt. Azonban voltak olyan esetek is, ahol a klasztert alkotó vSphere hosztok TEP IP-címzése, az általuk használt uplink-ek többfélesége nem tette lehetővé a klaszter szintű profil használatát. Egészen eddig a pontig ez egyenkénti – azaz nem TNP alapú – konfigurációt igényelt. Ez most változott meg, ugyanis elérhető a Sub-Transport Node Profile.
Segítségével a klaszteren belül tudunk kezelni eltéréseket a vDS-ben, az uplink profile-ban (például ha más VLAN-on lenne a TEP, ha DHCP helyett IP Pool-t használna vagy éppen másik IP Pool-t, mert éppen másik rack-ben van (és a rack a L3 boundary) vagy még inkább másik telephelyen.
Összefoglaló
Üdvözlendő a fejlesztési irány, bár sokkal gyakrabban lehetett eddig olyat látni, hogy nem a Tier0-k mentén volt a szerepkörök darabolása, hanem mondjuk a routing/switch-ingért egyik, a security-ért pedig egy másik csoport volt felelős. A következő részben ennek a multinenant működésnek a tűzfalazási opcióival foglalkozunk.
