Tegnap elérhetővé vált az NSX 4.1.1, amiben van pár lényeges újdonság, de talán a legfontosabb az, hogy végre megoldott a a VMware azt a hibát, amit a 4.1.0-ra történő frissítés okoz.
Erről írtam az alábbi bejegyzésben. A lényeg az, hogy a frissítés után, ha böngészőben a locale nem „english”, akkor a GUI nem töltődik be. API-n tökéletesen megy minden, de a GUI megtörik.
Mikor ezzel szembesültem egy frissítés során, nyitottam is azonnal egy jegyet a VMware Support-nál. A szokásos logokat töltsd fel körök után egy Zoom session-ben megmutattam nekik a hibát és akkor mégcsak nem is sejtve a workaround-ot kerestük a hibát. A GSS arra kért tegyek fel egy negyedik NSX Manager-t, mert szerintük valami a reverse proxy-ban állt meg a manager-ben és majd ez a nem frissített, hanem telepített új verzió majd megoldja a hibát. Furcsa volt látni négy kontroller/manager-t egy klaszterben. Végül nem oldotta meg, szóval ki is dobtam az újonnan behozott node-ot. Végül kollégám jött rá, hogy itt bizony a locale a probléma. Ennek örömére le is zártam a jegyet a VMware-nél, de kérdezték mi volt a megoldás. Na most ezt a hibát mindenképpen javították, szóval immáron akármi lehet a locale – ahogyan akármi lehetett korábbi verziókban is a 4.1 előtt – a GUI rendületlenül működik.
- Fixed Issue 3151441: After upgrading to NSX 4.1.0, the UI is not accessible if the browser locale is set to non-English or to a locale not supported by NSX.The UI is not accessible if the browser locale is non-English or to a locale not supported by NSX.
A release notes itt található: https://docs.vmware.com/en/VMware-NSX/4.1.1/rn/vmware-nsx-411-release-notes/index.html
Újdonságok
Első és majdnem legfontosabb, az VPC kezelése NSX-ben. A multi-tenant képessége a terméknek a „project”-ek lehetőségével indult, ami körülbelül hívható tenantnak is. Ezek egy NSX telepítésen belül, annak bizonyos részeit és funkcióit képesek kvázi izoláltan kiadni az adott project/tenant számára. Így az API/GUI is pont azt fogja nekik nyújtani – és csak azt – amihez joguk van, méghozzá olyan számban és mennyiségben, ami nekik allokálva van.
Erről írtam korábban a blogon, de lényegében a Tier0 volt a határa a delegációnak és azon belül lehetett szegmenseket, FW szabályokat stb-stb létehozni, illetve azok létrehozását delegálni a tenant számára.
NSX VPC
Cloud Consumption Model with NSX VPCs: New NSX VPC allows self service consumption for networking, security and services through on-demand isolated environment aligned to Cloud standard consumption. It offers a second level of tenancy below Project, with a streamlined UI and API to allow teams to easily deploy networking and security in the Cloud environment.
Kicsit zavaros tudom, de arról ez egy újabb lehetséges réteg, ami az NSX multitenant fogyasztását segíti. Egy project-ben több VPC is lehet és ezek mind egy különálló routing domain-t alkotnak, minden VPC egyet-egyet. Kicsit olyan érzésem van, hogy a Cloud Director VDC féle működést szeretnék megvalósítani az NSX-ben.
A fenti ábrán például látszik, hogy van egy project/tenant és abban van két NSX VPC.
Mindegyik VPC kaphat egy/több privát IP blokkot, amiből úgy hasíthatnak ki alhálózatokat, ahogyan akarnak. Ezt látjuk a Dev/Test/Production szegmenseken. A private subnet az felfogható olyan szegmensnek, ami – ha tűzfal engedi – kommunikálhat más privát és public szegmensekkel, azonban ha VPC-n kívülre kommunikálna, akkor SNAT-olni kell – automatikusan létrejön a szükséges szabály. A publikus szegmens ezzel szemben hirdetésre kerül a T0 irányába és ez közvetlenül, routing-ban elérhető, nem úgy mint a private subnet. (Pontosan így működik egy NSX-es hálózat a Cloud Director esetén per VDC.) Bár nincs a képen, de van izolált szegmens is, ami semmivel sem tud kommunikálni, más izolált hálózatokkal sem. Mint látszik a poject-nek van publikus IP blokkja is, amiből a fenti képen látható public szegmensek alakíthatóak ki.
Szerintem ez a kép elég sokat segít a megértésben. Az NSX-ben definiált IP blokkok felhasználásával adhatunk External IP tartomány(oka)t és privát tartomány(oka)t. Utóbbiak a VPC között felhasználhatóak újra egy másik VPC-ben természetesen – elvégre amúgy is NAT-olva lesz/van.
Egyelőre nem tudom eldönteni, hogy ennek egy nem szolgáltatói NSX környezetben mi a felhasználhatósága.
Multi-tenant Distributed IDS/IPS
Multi-tenant Distributed IDS/IPS: Distributed IDS/IPS now offers multi-tenant consumption with the ability to configure it under Projects. It allows multiple users to apply IDS/IPS rules to their own VMs without risks of overlap.
Sokkal lényegesebb újdonság, az IDS/IPS beemelése a project alá. Egy 4.1-es rendszerben ezt látja egy project. Distributed tűzfal és gateway tűzfal, mint biztonsági elemek.
A 4.1.1.-re történő frissítés után ilyenné válik a felület.
Ettől kezdve delegálni lehet az ilyen elosztott – azaz végső soron az ESXi kiszolálókon hatályos – IDS/IPS szabályok kezelését, azt hogy mely VM-ekre vontakozzon, milyen profil, milyen akció és milyen szabály.
IPv6 a a Transport Node-ok TEP interfészein
IPv6 TEP (tunnel end point) support for Transport Nodes: This release introduces support for IPv6 TEP (tunnel end point) with Geneve encapsulation for Transport Nodes (Edge Nodes and ESXi hosts). With this feature, you can create overlay Transport Zones using IPv6 as the underlay transport protocol.
Személy szerint még sehol sem találkoztam az igénnyel, hogy IPv6 alapon működjön már az underlay hálózat is, de a 4.1.1-ben ott a lehetőség.
Frissítés
Maga a frissítés egyébként kiadásról, kiadásra zökkenőmentesebb. Nyilvánvalóan függ attól, hány Edge klaszter, azokban mennyi Edge Node, hány vSphere klaszter és menniy ESXi van összesen, de maga a precheck is egyre értelmesebb és ha ott validálta, hogy menni fog a frissítés, akkor sikeresen végre is fog hajtódni.
