Volt már korábban számos bejegyzés az NSX-T világából, arról milyen entitások vannak benne, hogyan kell telepíteni, frissíteni és egyebek. Sok továbbra is érvényes, de mégis idejét érzem, annak, hogy picit másképp és másként írjak róla. Több fórumon olvasom, hogy mások is úgy érzik, hogy a VMware picit elaluldt a hivatalos ajánlással kapcsolatban. A 2.4-es verzióra kiadtak annó egy hivatalos „NSX-T Design Guide„-ot, majd azt frissítették 2.5-re. Aztán fél éve megjelent az NSX-T 3.0 és még mindig nincs frissített guide, pedig legalább akkora változások vannak a 2.5 és 3.0 között, mint amekkorák voltak a 2.4 és 2.5 között.
Természetesen két módon lehet NSX-T 3.0-ra kerülni, mégpedig vagy upgrade vagy új telepítést követően. A kettő között nagyon lényeges különbség, hogy a végeredmény nem lesz azonos, később kitérek rá miért.
A friss telepítés folyamata lényegében a következő:
- NSX Manager cluster létrehozása
- Uplink profile létrehozása
- Transport node profil létrehozása
- NSX telepítése a hosztokra
- Edge uplink létrehozása
- IP pool(ok) létrehozása
- Edge VM(ek) telepítése
- T0 lértehozása
- (opcionálisan T1 létrehozása)
- ezekről korábban mind írtam…..
NSX-T 3.0 esetén VDS-sel, már az hosztok számára szükséges uplink profile-nál más a folyamat, nézzük meg mégis miért.
Uplink profile
Minden NSX-T verzióban a 3.0 előtt az NVDS-t kötelező volt használni a hosztok TEP interfészei számára. Attól függően, hogy az ESXi kiszolgáló hány fizikai interfésszel rendelkezett, kellett kitalálni, hogy melyik a jó opció. Lényeg a lényeg, ha két interfész volt, akkor csak NVDS lehetett a hoszton. Ha négy interfész, akkor egyp pár NIC-et elhasznált az NVDS, a másik párral pedig lehetett vDS/vSS-t csinálni.
Pre NSX-T 3.0
Korábban így nézett ki – nézhettek ki, mivel ez egy példa és nem az összes megoldási lehetőség – két fizikai NIC esetén egy ESXi hoszt, amely az overlay-ben vett részt:
NSX-T 3.0
2 NIC esetén annyiban változik, hogy eltűnik az NVDS, mindkét fizikai portot a vDS birtokolja és a hoszt ezen a VDS-en kapja a TEP interfészét. Minden más ami a hoszton van, tehát egyéb virtuális gépek, vmkernel portok – ha van külön vMotion és VSAN dedikált vmkernel – mind mind úgy vannak, mint lennének NSX nélkül.
Ennek az egésznek az a legnagyobb előnye, hogy mivel vDS alapú az egész, ezért nem kell átlépkedni az NSX Manager-be azért, hogy kezeljük a switch-et, illetve nem kell NVDS-re migrálni a vmkernel portokat, illetve szegmenseket létrehozni minden egyéb vmkernel-nek és NSX független virtuális gépnek. Szintén előny, hogy a VLAN transport zone sem kell rajta legyen a hosztokon, mivel nem használunk VLAN backed szegmenst (de használhatunk, ha nem NSX független virtuális gépeket akarunk kiszolgálni NSX szolgáltatásokkal). Ez csak abban az esetben igaz, ha az Edge VM-ek nem ezeken a hosztokon fognak futni, ellenkező esetben szükséges a VLAN TZ is.
Ahhoz hogy a VDS erre használható legyen, annak 7.0.0-s verzója kell. Ahhoz pedig ESXi 7.0, ahhoz pedig vCenter Server 7.0. És itt van az upgrade és az új telepítés közötti különbség. Egy már meglévő, NVDS alapú rendszert frissítve 3.0-ra, az NVDS megmarad, migrálni kell. Egy új telepítésnél pedig kis túlzással eldönthető, hogy NVDS-t vagy vDS-t akarunk használni.
Hozzuk létre az uplink profile-t a hosztok számára. Ennél a lépésnél a VMware dokumentációja eléggé ködös mi történik annak függvényéban mi a teamin policy.
Failover Order választása esetén a jellemzők (ESXi,KVM és Edge esetén használható):
- nincs semmiféle load balancing.
- ha az aktív uplink-kel probléma van, akkor a standby uplink kerül felhasználásra.
- egy TEP interfész jön létre.
Load Balanced Source választása esetén a jellemzők (csak ESXi és Edge esetén használható):
- az aktív interfészek számával egyenlő TEP interfész jön létre. Azaz az aktív uplink-ek listájából, minden egyes uplink-en lesz egy TEP interfész, egy IP-vel.
- ezeken Source port ID alapon történik a load balancing.
Load Balanced Source MAC választása esetén a jellemzők (csak ESXi esetén használható):
- az aktív interfészek számával egyenlő TEP interfész jön létre. Azaz az aktív uplink-ek listájából, minden egyes uplink-en lesz egy TEP interfész, egy IP-vel.
- ezeken a forrás VM MAC-je alapján történik a load balancing.
- egyetlen értelmes felhasználási esete, ha a Guest trunk-öt kezelünk a VM-ben.
Nem vagyok a LAG ellen, de hiszem hogy plusz egy tényező a képletben, amivel baj is lehet, ha úgy alakul. A LAG beállítása nem tekinthető teaming policy-nek NSX szempontjáből. Ha egy LAG-ot hozunk létre, majd az uplink profile-ban Failover Order-t választunk, aztán felhasználjuk a LAG-ot, akkor abban a LAG-ban hiába van 2 fizikai interfész, még egy TEP jön létre. Ha készítünk egy újabb LAG-ot és majd az elsőt aktív uplink-ként használjuk, a másodikat failover-ként, akkor azonos a végeredmény, egy TEP lesz. Ha Load Balanced Source-t választunk, akkor a két LAG, két TEP IP-t eredményez, közüttük load balancing-gal. Ez utóbbi elég egzotikus irány, ezért is mondom azt, hogy „keep it simple”.
Mikor kell több uplink profile? Ha egy klaszterben többféle kiépítésű kiszolgáló van, más más számú interfésszel, LACP/LACP nélkül, más VLAN-ban lévő TEP interfésszel. Azért az a szép ha egy klaszterben azonos a kiépítés, mert akkor klaszter szinten, egy kattintással teríthető az NSX és hozódnak létre a TEP interfészek.
Nagyon fontos, hogy 3.0 és vDS esetén az uplink profile-ban nem szabad beállítani az MTU-t, mert azt a vCenter-ben kell állítani a vDS-en!
Transport node profile
A transport node profile, az uplink profile-t használja fel mikor lentebb bekéri a tényleges interfészeket. A 3.0-ban itt látható, hogy ki kell választani a vDS-t, majd egy vCenter-t és a vDS-t magát. És pont itt érdemes picit gondolkodni azon, hogy vCenter-ben egy vDS-t használ több klaszter vagy éppen klaszterenként van egy vDS-ünk. Például ha NSX-et kívánunk használni két klaszterben, de az két különböző vDS-t használ per klaszter, akkor az két transport node profile lesz a végén, mert egy TNP (transport node profile) csaj egy vDS állítható be.
És itt is van különbség, mivel két fizikai interfész esetén minden esetben kellett egy olyan transport zone is, amiben szegmensként szerepelnek azok a VLAN-ok, amelyekben a hoszt vmkernel portja van – ha külön van még egyéb, akkor azoknak is. Itt erre nincs szükség, mert vDS lévén azok továbbra is fogyaszthatják továbbra is a vDS normális port group-jait.
Az fentebb már tárgyalt „esxi_uplink_profile” alapján a végeredmény a két TEP IP lesz.
ESXi oldaláról látható a fejlődés, de még van mit faragni rajta, mivel így néz ki a vDS. A TEP vmkernel-eknek nyoma sincs.
Pedig léteznek.
Edge telepítése
Mielőtt bármit is tennénk, el kell dönteni hogy amennyiben Edge VM – tehát nem bare metal Edge – kívánt, akkor az hol fog futni. Erről is írtam már korábban, dióhéjban:
- consolidated/collapsed eset: Compute és Edge VM kiszolgálás egyben, NSX-be bevont hosztokon.
- külön Compute és külön Edge klaszter esete: Az Edge VM-eket kiszolgáló hosztok nincsenek NSX-be bevonva.
Előbbi esetben két TEP VLAN kell, egy a hosztok számára az overlay, egy pedig az Edge VM-ek számára az overlay. Ezeket nyilvánvalóan routolni kell, el kell érniük egymást. Ha az Edge VM-ek nem olyan ESXi-ken lesznek, amelyeken van TEP interfész, akkor erre nincs szükség.
Ha az Edge VM, ahogy a neve is mondja egy virtuális gép. Interfészei csaltakozhatnak Standard vSwich-hez, Distributed vSwitch-hez vagy NVDS-hez. Ha utóbbihoz csatlakoznak, akkor nyilvánvalóan létre kell, hozni azokat a VLAN segment-eket az VLAN tansport zone-ban.
Pre NSX-T 2.5
A design guide-ban szerintem ez a kép magyarázza a legjobban. Az Edge VM létehozásakor három NVDS – vagy kettő, ha egy uplink-je lesz – kerül beállításra. Az egyiken lesz az Edge VM TEP interfésze, a másik kettőn, pedig az uplink irány. Ezt híváták „Multi-NVDS Single TEP”-nek.
NSX-T 2.5 és 3.0
Megváltozott az ajánlás, immáron a „Single NVDS Multi TEP” a javasolt – mert történtek változások pl Named Teamin Policy” megjelenése, illetve a multi TEP biztosít végre load balancing-ot is.
A fenti képen látszik, hogy az Edge VM-nek van:
- egy management interfésze, amely csatlakozhat vSS/vDS port group-hoz vagy VLAN backed szegmenshez.
- uplink 1 interfésze
- uplink 2 interfésze
Utóbbi kettő nyilvánvalóan trunk kell legyen, mivel mind az overlay VLAN, mint az uplink VLAN-ok ezeken az interfészeken kerülnek elérésre. Lehet egy uplink is, akkor egy TEP interfész és IP lesz, de a trunk igénye nem változik. Lényeges, hogy az Edge uplink profiljában kezeljük a VLAN-t a TEP interfészéhez.
A fenti képen felmerülhet a kérdés, hogy mégis miért nem adtam meg ugyanazt a port group-ot mindkét uplink-nek. Azért mert akkor a vDS, adott portgroup-ra vonatkozó részénél nem tudnék igény esetén egyik uplink VLAN irányba egy fizikai interfészt használni, egy másik esetén egy másikat.
A végeredmény így néz majd ki:
A két Edge VM egy Edge klaszterbe került.
T0 létrehozása
Egy Tier 0 router-t hozok létre.
Ezek után állítom be az uplink-eket.
És máris látszik, hogy mivel az uplink trunk, ezért valamilyen módon meg kell mondani abban a trunk-ben, hogy milyen VLAN-on kívánjuk használni az uplink-et. Ezért fel kell venni a szükséges VLAN-okat, mint szegmens és a VLAN TZ-be kell tenni.
És a másik szegmens.
A Tier 0 router az Edge01 VM-en így rendelkezik uplink interfészekkel.
Edge02-n is természetesen meg kell ismételni az uplink-ek beállítását.
Összefoglalva
A VDS felhasználhatósága sok helyen egyszerűsítette az amúgy még mindig elég absztrakt konfigurációt, de még sok helyen lesz szükség további lépésekre, hogy az átláthatóság még tovább javuljon. Jelenleg, ha létrehozunk egy szegmenst NSX-ben adott névvel, akkor egy teljesen ugyanolyan nevű port group-ot simán létre tudunk hozni vCenter-ben.
Egyébként minden így néz ki. Az NSX szegmenseknél egy kis „N” betű van a port group ikonján és konfigurálni nyilván semmit sem enged a vCenter felől, de ad némi információt arról, hogy melyik TZ-ben van az szegmens amit a PG reprezentál, illetve az NSX Manager URL-jét is mutatja.
