Azért szeretem a marketinget, mert minden program, prezentáció és üzenet, akár hétről hétre változhat és általában olyan módon, mibtha előző program meg sem történt volna. Pont ezt érzem az NSX-V és NSX-T kapcsán is, mivel egészen sokáig volt az NSX-V „A TERMÉK” és az NSX-T pedig „még nem javasolt” verzió. Aztán egyik reggel úgy változott, hogy az NSX-V „már nem javasolt” az NSX-T pedig „go to platform” lett.
Hazánkban egyébként halmozottan hátrányos a helyzet, mivel alapvetően nincs sok NSX-V implementáció, NSX-T pedig még annyi sem. Viszont ami szerintem nagyobb probléma, az az NSX-T oktatások és tananyagok hiánya, egyszerűen senki sem tart tanfolyami, szervezett rendszerben oktatást. Az sem könnyíti meg a dolgot, hogy az NSX-T alapvetően különbözik a T-től. Azt is meg merem kockáztatni, hogy az aki most kezd ismerkedni az NSX-el, az sokkal jobban jár, mivel nincsenek prekoncepciói, nem keresi folyton azt, hogy az NSX-V-ben ez meg az miképpen volt, nem akarja annak sablonjába belehajtogatni a T-t. Nekem például ez komoly gondot okoz, mert nagyon nehéz megértenem a Tier alapú design-t és az SR/LR réteget.
Azon ügyfeleket, akik az elmúlt egy évben NSX-V-t implementáltak, sajnálom, akik most vezetik be, azoknak pedig fizetek pár pofa sört.
A koegzisztencia, azért nem kézenfekvő, mivel alapvető korlátozások vannak:
- egy hoszt csak NSX-V vagy NSX-T-re lehet „felkészítve”. Ütköznek a szükséges VIB-ek stb.
- egy klaszter csak teljesen NSX-V-s vagy NSX-T-s hosztokat tartalmazhat.
- mivel az overlay teljesen más (egyiknél VXlan, másiknál Geneve) ezért ezek L3-ban találkozhatnak csak, a külvilágban.
A licenszelés természetesen jogosultságot az az NSX-V ügyfeleknek, hogy áttérjenek NSX-T-re.
1. NSX Manager/Controller telepítés
Az NSX-T-ben, annak is 2.4-es verziójában az NSX Manager és NSX Controller szerepkörök összevonásra kerültek, szóval amíg eddig négy appliance kellett a működéshez, ebben a verzióban elegendő három is. Ennek előnye ezen felül még annyi, hogy így az NSX Manager is redundánssá válik – nem aktív-aktív, hanem aktív/passzív.
Az első „Manager” telepítése az OVF importjával kezdődik. A méretezési kérdés az első fontosabb lépés:
A következő ablakban meg kell adni azt a datastore-t, amelyikre telepíteni szeretnénk, majd azt, hogy melyik VM portgroup-ra szeretnénk tenni a controller-t. Ezek után egy fontos lépés következik, itt kell konfigurálni a következőket:
- Root jelszó
- CLI admin jelszó
- CLU audit jelszó
- (ha a fenti felhasználók belépési nevén kívánunk módosítani, akkor az újakat) – opcionális lépés
- hostname – ne használjunk FQDN-t
- „role kiválasztása”: két verzió van „nsx-manager nsx-controller” és „nsx-cloud-service manager”. Válasszuk ki az elsőt.
- IP átjáró
- Controller IP
- Alhálózati maszk
- DNS kiszolgálók listája. Nem vesszővel elválasztott lista, hanem „space”-szel.
- DNS search list
- NTP szerverek listája. Nem vesszővel elválasztott lista, hanem „space”-szel.
- SSH engedélyezése/nem engedélyezése.
- Root felhasználó SSH elérésének engedélyezése/nem engedélyezése.
Kis érdekesség, hogy Ubuntu alapú a Manager, fogalmam sincs hogy miért nem PhotonOS, ami a VMware több terméke alatt váltotta le a SLES-t.
Ezek után be kell lépni a manager admin felületére, amit a https-es en érünk el. Itt el szükséges fogadni az EULA-t és nyilatkozni a CEIP-ről is, ha szeretnénk benne résztvenni.
Első ablakban a fókusz egyből ugrik, a „System” részre és kéri hogy adjunk hozzá több node-ot, mert legalább három javasolt. Válasszuk a „Deploy nodes„-t.
Itt látható az első és eddig egyetlen node, ami mellé így még kettő – legalább kettő javasolt. Válasszuk ki az „Add nodes” részt:
A megnyíló ablakban egy piros hibaüzenetben válik olvashatóvá, hogy nincs „Compute Manager”, ezért azt kell konfigurálni először. Ez vCenter lehet, így nyilván be kell állítani egyet vagy többet és ezekben lehet majd NSX-T-t használni.
Meg fog nyílni a „Fabric” menü és alatta a „Compute Managers„. Itt válasszuk ki az „+Add”-ot.
Majd írjuk be a vCenter elérhetőségét és a szükséges felhasználót.
Előre nem írtam be SSL thumbprint-et, ezért szól, hogy a vCenter thumbprint-je az-e az amit használni szeretnék majd, azaz ez-e az a vCenter amit én szeretnék beállítani.
Ha így van akkor válasszuk ki az „Add„-ot és rögvest hozzá is adja a „Compute Manager”-t. Pár perc múlva két lehetséges kimenetel várható, attól függően, hogy van/volt-e más NSX-V vagy NSX-T Manager valaha a vCenter-hez regisztrálva. Ha nem volt, akkor sikeresen, minden további teendő nélkül lezárható a folyamat. Ha volt, akkor a következő állapot jelenik meg:
Látható hogy a „Registration status”, „Not registered”-ben áll. Kattintsunk rá ez utóbbira.
Válasszuk ki a hibát és kattintsunk rá a „Resolve„-ra.
Újabb üzenet, hogy mi a probléma, azaz hogy már mással is társítva van/volt. Migráció esetén ez normális, új telepítés esetén pedig ilyet nem fog írni. Migráció esetén egyébként ki ne regisztráljuk az NSX-V Manager-ét. Itt a „Close” kiválasztása után, újra bekéri a felhasználót.A végén válasszuk ki újra a „Resolve” gombot.
Megint pár perc és egy frissítés után az állapot teljesen normalizálódik.
Ezek után, már telepíthető akkor a még két szükséges node. Ezt az „Overview” kiválasztásával tehetjük meg. Tulajdonképpen visszavezet a pár képpel korábbi részre minket, de ezúttal már nem fogja jelezni, hogy nincs „Compute Manager”.
Itt kell megadni az újabb manager helyét, azt hogy elérhető legyen-e SSH-n és a root belépés működjön-e rajta, továbbá a jelszavait, DNS és NTP szervereit és a méretezését. Három féle méretben lehet telepíteni, tárterületben egyébként nincs eltérés, viszont CPU és RAM-ban igen sok.
A VMware egyébként a következő esetekben javasolja az adott méretet (az extra small, csak az első manager OVF-ból történő telepítésénél érhető el):
Természetesen a controller-ek elhelyezésénél ügyelni kell, hogy lehetőleg sose legyenek egy ESXi hoszton, így sérülne a működés, amennyiben az az egy hoszt kiesik. Szintén lényeges, hogy maximum 10ms RTT a controller node-ok között.
Saját tapasztalat, hogy amennyiben az FQDN tartalmaz számmal kezdődő részt, akkor mindenféle hibákat generál a második és harmadik kontroller telepítésekor a rendszer.
Nagyon érdekes, hogy az IP-t és a maszkot itt IP/maszk formátumban kéri a rendszer, pl 192.168.10.10/24. A „Finish” választása után vCenter-ben tetten is érhető a deployment.
A harmadik manager/controller telepítése tulajdonképpen azonos a második telepítésének folyamatával.
Ha minden szinkronba került és legalább három manager/controller van már, akkor érdemes a virtual IP-t is beállítani. Ez lesz az a floating IP, ami mindig egy node birtokol és kiesés esetén átveszi egy másik. Ezáltal a menedzsment plane is elérhető marad, ha valami hiba érinti az aktív manager-t.
Pici várakozás után végez és javasolja, hogy frissítsük az UI-t. Kisvártatva meg is jelenik, hogy ki az owner.
Körülbelül eddig a pontig egyezik a migráció és az új telepítés folyamata. A következő részben innen folyatjuk….
