Szeretem azokat a feladatokat, amelyeknél a követelmények alapján a lehető legjobban illeszkedő és a legminimálisabban szükséges komplexitás metszetében lévő kialakítást lehet megvalósítani. Egy bonyolult és egy egyszerű rendszer között a legtöbbször sem képességekben, sem funkcionalitásban nincs különbség, azonban hibakeresés esetén nagyon megbonyolítja a felderítést és úgy általában a rendszer működésének megértését.
Szóval egy NSX-T telepítés első lépése egyáltalán nem az NSX-T ről szól, de mégcsak nem is arról milyen a hálózat és hogy van a routing stb. Ha overlay hálózatot szeretnénk használni, akkor szükség van pár VLAN-ra és magas MTU-ra, de előbbiek mégis, hogy legyenek megvalósítva és mely fizikai szerverekre legyen kiosztva.
NSX Manager és a külső load balancer
Három NSX Manager alkot egy telepítést. A maximális számuk a három és akkor tekinthető egészségesnek a rendszer, ha mindhárom rendben elérhető és szolgáltatásaik futnak. Ezeken keresztül történik az NSX üzemeltetése – management plane – és valósul meg a control plane is. Szükség van tehát egy olyan Cluster/VIP IP-re, amely mögött ez a három redundanciával tud szolgáltatni.
Erre kézenfekvő megoldás a beépített megoldásuk, azaz hogy fel lehet venni magából az NSX-T Manager-ből egy közös IP-t. Ez csak akkor lehetésges, ha a három manager azonos szegmensen van – VLAN szegmens! – mivel maga a VIP is azon lesz.
Viszont ha valaki ezt nem szeretné, akkor bevonhat egy külső load balancer-t annak feloldására, hogy így akkor nem kell azonos szegmensben lennie a három manager-nek.
Ennek ellenére érdemes az első lehetőségnél maradni, egyszerűbb és nem von be egy újabb rendszert a függőségbe.
Milyen formátumú szervereken fog futni?
De még ez sem egész, itt pontos gyártót kell ismerni, mert bizonyos esetekben bizony van eltérés, melyiknél van értelme valaminek. Azért fontos ez a kérdés, mert az implementációk igen nagy részében – az én mintáim alapján – az Edge VM-ek és az overlay-t használó virtuális gépek – host transport node ESXi-ken – azonos ESXi kiszolgálókon futnak, tehát ez collapsed kiépítés.
Mint emltettem két VLAN mindenképpen kell:
- TEP – overlay – VLAN
- uplink VLAN
Attól most eltekintek, hogy nem szükséges minden hosztnak azonos TEP VLAN-ban kell-e lennie, mert nem szükséges. Egy nyolc hosztos környezet, akár nyolc különböző TEP VLAN-ban lehet hosztonként másban, csak legyen köztük routing. Az uplink VLAN pedig a Tier 0 router uplink-je miatt fontos és persze ebből is lehet több – kettő javasolt dinamikus routing esetén – is.
Mivel collapsed-ről beszélünk, ezért ezt a két VLAN-t minden olyan fizikai szerverre el kell vinni, ahol overlay-t használó VM-ek és akár az Edge VM-ek fognak futni. És ez az a pont, ahol bele lehet tenni egy nagyságrendnyi bonyolultságot, hiszen a következő kettő elképzelhető. A bal oldali egy olyan követelménynek meg fut felelni – ha kell – hogy a Tier 0 által használt VLAN(ok) egy másik switch (páron) szolgálható ki, olyan sávszélességgel, aminek nem kell versenyezni más forgalommal azon a kapcsolaton.
A jobb oldalon látható, sokkal egyszerűbb és egyébként az erősen javasolt is. Trunk, azaz több VLAN is elérhető – amúgy a bal oldali megoldásban általában szintén van trunk, pl a management és a vmotion vmkernel számára – illetve ha egy működő rendszerről beszélünk, akkor olyan VLAN-okkal, amelyeket a VM-ek használnak. Szóval a jobb oldali képen az látható, hogy egy pár switch adja az összes VLAN-t.
Lehet követelmény a bal oldali, de csak akkor van bármiféle értelme, ha rack formátumú szerverekről beszélünk. Nem ismerek sok gyártót, de a HPE-nél a Synergy esetén ilyet maximum akkor érdemes csinálni, ha még két network interconnect benne van a keretben és külön mezzanine-on akarjuk kivinni vagy a TEP vagy az Uplink VLAN forgalmát. Ha csak egy pár interconnect van a keretben, akkor amúgy értelme sincs több VF-re szétszedni a blade oldalán az egészet – sávszélességet a vDS oldalán is lehet kezelni ez nem lehet ok – hogy aztán azonos interconnect-en végződjön és amúgy az legyen hozzákapcsolva a két külön switch kettőshöz. Alább pont egy ilyen látható.
Cisco UCS keret esetében egyenesen teljesen felesleges, HPE Synergy esetén adott kiépítésben szintén az. Egyedül megfelelő számú interfész esetén lehet – néha – értelme rack kiszolgálók esetén. Bonyolítani a dolgokat persze nagyon szép vele, de semmiféle haszna nincs. Ha egyszer van olyan szabály, hogy nem lehet azonos aktív eszközön “külső” és “belső” hálózat, akkor esetleg olyan formátumú kiszolgálókat kellene választani, amivel reális értelme van ilyet csinálni minden rétegben és nem csak a kiszolgálók amúgy virtuális portjain.
Egy ilyen beállítás alapvetően teszi lehetetlenné a javasolt Edge VM design használatát, ami nem más mint a single NVDS kiépítés.
Szóval ha valaki nem ezt alkalmazza, akkor ezt lehetetlenné teszi, mert egy Edge VM-nek négy interfésze lehet. Egy interfész nyilvánvalóan csak egy port group-hoz csatlakozhat. (A Management bekötését az ábrákon nem jelzem). Az alábbi egyébként NSX-T 2.5 előtti verzióknál volt javasolt. Attól a verziótól kezdve a Single NVDS design a javasolt!
Máris nyilvánvalóvá válik hogy itt egy TEP IP lesz csak, egyetlen TEP interfész, egyetlen interfészen lehet terhelni a fizikai kapcsolatokat. Tehát értelme nulla, cserébe lemondunk az egyszerűségről és az elérhető magasabb sávszélességről. Alább az én ábrámhoz hasonló a design guide-ból, annyi különbséggel, hogy lentebb nincs elválasztva két vDS-re, azaz ott azonos switch-en kezelt az uplink VLAN(kettő) és a TEP VLAN.
LACP vagy no LACP?
Rengetegszer előkerül az LACP. Nyilvánvaló, hiszen ha egy szerverben ott van a 2 x 10/25/40/50/100 Gbit-es port, a másik oldalán egy switch fogadja a kábelt belőle, akkor a két port “ára” ne legyen már “standby”. Senki sem szeretné, ha a drágán megvett portok feladat nékül csak úgy ott lennének.
Nyilvánvalóan lehet LACP-zni, támogatott az NSX-T esetén is. Az ESXi oldalán kevésbé absztrakt a dolog, de az Edge VM-nél, olyan sok réteg van, hogy nehéz megérteni a használatának értelmét.
Szóval ESXi esetén ha vDS-t akarunk használni, akkor a vDS oldalán konfigurálható az LACP a tetszőleges számú kapcsolattal és akkor az uplink profile-ban csak ezt a LAG-ot kell beírnunk, más teendő nincs. Ez jelenti azt is, hogy ha például két fizikai interfészem van egy LAG-ban, akkor az ESXi-nek nyilvánvalóan egy TEP IP-je lehet. Ha nem használnék LACP-t, akkor szintén lehetne aktív mindkét interfész, hiszen ha két TEP IP-je lehet a gépnek, akkor az egyiket az egyik interfészre, a másikat a másikra teszi. Nyilvánvalóan ebben az esetben kétszer annyi TEP IP-cím kell, sokkal több Geneve tunnel lesz, viszont továbbra is minden aktív maradhat.
Azt sem szabad elfelejteni, hogy egy vDS-en a port group-ok szintjén beállítható, hogy éppen milyen módon és mely uplink-ek legyenek használatban vagy készenlétben. Tehát egy két interfésszel szerelt kiszolgálón lehet mindettőn egy-egy TEP, a vMotion terhelheti az egyik, a management a másik lábat.
Tehát nem szükséges mindenáron LACP-t használni.
Statikus vagy dinamikus routing?
Sokáig az NSX-T csak két opciót adott a bejövő forgalom kezelésére. BGP-t és statikus routing-ot lehetett használni. Ma már az OSPF sem akadály, tehát háromra bővült a lista. Tier 0 router-ről Tier 0 router-re változhat melyiket szükséges használni, de akár egy Tier 0-n is lehet neighbor-onként OSPF-et vagy BGP-t felváltva használni.
A statikus legnagyobb hátránya, hogy csak egyetlen VLAN-ban lehet megvalósítani és nem lehet egyszerre több Edge VM is aktív – tehát ECMP az felejtős. Szóval a Tier 0 router-nek így ha két Edge VM-ről beszélünk amiben realizáljuk, lesz egy-egy IP-je az uplink VLAN-ban és lesz egy közös IP-jük, amire a külső eszközről a statikus route-tal mutatni lehet. Itt nyilvánvalóan esély sincs arra, hogy LACP nélkül az uplink forgalom mindkét – akárhány – interfészt terheljen.
Dinamikus esetén a javaslat minden esetben a két uplink VLAN használata, pontosan a magasabb redundancia miatt, amit a next hop eszközök miatt érdemes átgondolni. Tehát a fenti képen az egyik VLAN az Uplink 1 és ezáltal az SW #1 irányába, a másik VLAN az Uplink 2 és SW #2 irányába lesz aktív. Failover a PG szintjén be van állítva, de meg kell bizonyosodni arról, hogy a next hop eszközökön az csak az az uplink VLAN van felvéve és van benne IP-je, ami rá nézve szükséges. Tehát nem szabad mindkét uplink VLAN-nak ott lennie mindkét SW-n. Hagyni kell elhalni abban a routing-ot – BFD van – és nem kimozogni annak kiesését switch/router oldalon. Ezt egyébként a Tier 0 esetén az NSX-ben is meg kell tenni named teaming policy segítségével, azaz egy uplink VLAN-t az egyik, a másikat pedig a másik uplink irányába irányítunk.
Dinamikus routing használata erősen javasolt és minden esetben két uplink VLAN használatával.
Erről írtam korábban már alább:
Mentés hiánya
Az NSX Manager-ben ütemezhető a rendszer mentése. Ezeket periodikusan és módosítás esetéhez is köthetjük. Érdemes használni, mert volt már olyan hibajelenség, ahol a VMware GSS azt javasolta, hogy egy új NSX Manager telepítése és a mentés visszatöltése a megoldás (az volt). Ha ilyenkor nincs mentés, akkor marad a teljes újraépítés.
Bár a mentés jó alap, de érdemes a vDS-ek rendszeres mentése is. Ha vissza kell álítani egy szűz rendszerbe, akkor szükség lesz az export-ra.
Tesztelés
A rendszert vizsgálni kell azzal kapcsolatban, milyen eseményre hogyan reagál, mit várhatunk el tőle és mit kell adott esetben akár manuálisan is de tenni. Ha ezeket az eseteket nem vizsgáljuk bevezetés előtt, akkor izzasztó pillanatokat élünk majd át.
A lehető legegyszerűbb dologtól – legalább 1600-as MTU-val pingelhető a TEP a hosztok között és az Edge-ek felé? – a legkomplexebb irányba – mi történik ha az egyik uplink VLAN-ban megáll a forwarding – haladva mindent kipróbálni és dokumentálni. Minden olyan rendszerben, amely építéséhez közöm van, ott ezeket végrehajtom.
Összefoglaló
A Design guide és a VMware Validated Design elég jó alapot adnak a szakmai beszélgetés elkezdéséhez, de pusztán ezek alapján – és egy NSX ICM tanfolyam elvégzése után – nem érdemes nekiugrani az NSX produktív üzembe történő telepítéséhez, mert lehet működni fog de később majd lesznek anomáliák vagy szerencsés esetben egyáltalán nem fog működni. Minél többet dolgozom ezzel a termékkel, annál jobban látom, hogy nagyon keveset tudok róla, de szerencsére egyre többet tudok arról, mit nem szabad. Utóbbi nincs leírva sehol sem.
