A harmadik és a negyedik poszt, elméleti volt, míg a második rész gyakorlati rész volt, odáig jutottunk el, hogy létrehoztunk a sokféle profilt, uplink, transport node stb.
Ahogy ott is írtam, én négy interfészt használok egy hoszton és nálam az Edge VM-ek egy hoszton lesznek a compute-tal. Ez jelenti azt is, hogy szabadon választhatok, hogy az Edge VM egy vDS bizonyos port group-jához csatlakozzon vagy annak az N-VDS-nek az egyik Logical switch-éhez amin egyébként az overlay is üzemel. Én előbbit választom, azaz nálam vDS_PG lesz az Edge VM-ek uplink interfésze.
Ez a design egyébként szerintem az ügyfelek igen nagy részének jó, de ismételjük át a következő ábrán:
A hosztjaimnak négy interfésze van, kettő a vDS-en és kettő az N-VDS-en. Az NSX Manager – mind a három – nem ebben a klaszterben fut.
Részletesebben ezt szeretném megépíteni:
Host transport node(ok) létrehozása
A második részben ott fejeztük be, hogy létrehoztuk a „Transport Node Profile”-t. Ezen profil alapján kell az NSX-et tulajdonképpen felkonfigurálni a hosztokon/klasztereken.
Ennek elindítása a hosztok/klaszterek kijelölése után „Configure NSX” kiválasztásával történik.
Csak egy dolgot kell megadni, a „Transport node profile”-t és el is indul a telepítés. Ilyenkor települnek a szükséges VIB-ek, jön(nek) létre az N-VDS(ek), konfigurálódnak a TEP vmkernel portok is.
Ha elkészült, akkor a remények szerint az NSX Manager GUI-ban mindent egészségesnek mutat.
Viszont javaslom duplán ellenőrizzük le, mármint lépjünk be a hosztokra SSH-n és listázzuk ki a VMkernel interfészeket:
A vmk10 jött létre és ez a hoszt TEP interfésze.
Edge transport node(ok) létrehozása
A topológián látszik, hogy az Edge VM-ek, egy vDS-hez fognak csaltakozni. Itt szükséges eldönteni, hogy a VLAN-t hol kezeljük. Ha vDS szinten a PG nem trunk, hanem ott levesszük a VLAN ID-t róla, akkor az edge-et érintő „Uplink profile”-ban az nem kell konfigurálni, azaz értéke annak a beállításnak nem lesz. Ellenkező esetben azt is be kell állítani az uplink profile-on. Ennek előnyei is vannak, mivel a vDS két fizikai uplink-kel rendelkezik, ezért nekem az Edge uplink profiljában, nem kell két uplink-et megadnom.
Hozzuk hát létre az elsőt!
DNS-be jegyezzétek be mindig!!
A méretezés a későbbi teljesítmény és skálázhatósági tényezőket befolyásolja. Később még kifejtem ezt a részt.
Minimum kettő felhasználónak kell elegendően komplex jelszót adni. Az egyik a root a másik az admin, ezeknél engedélyezni tudjuk ha szeretnénk SSH-n a bejelentkezést a nevükben. Én az „admin” esetében engedem meg, a „root” nevében nem.
A következő ablakban meg kell adni hová is szeretnénk tenni az Edge-et. Itt én klaszter-t adok meg és nem definiálok explicit hosztot. Azonban minden esetben nagyon fontos egy DRS/HA klaszternél, amin az Edge VM még közös tárolón is van, affinitási szabállyal külön tartani az egy klaszterhez tartozó Edge VM-eket. Ez el is árulja azt, hogy még egyet – legalább – létre fogunk hozni, hogy aktív/standby üzembe tudjuk őket vonni. Ehhez pedig tényleg az kell, hogy ne egy hoszton legyenek.
A következőben meg kell adni az Edge VM menedzsmenjének részleteit, IP-t, azt a port group-ot, amin ez a menedzsment-interfész majd kapcsolódni fog. DNS, átjáró és NTP-t kell még megadni. Mindegyik nagyon fontos, ellenőrzni illik párszor, hogy tényleg minden korrektül legyen beállítva. Én DHCP-re állítom, de ha fix IP-t szeretnénk neki adni, akkor az is megtehető. Produktív környezetben ez utóbbit javasolnám, de laborban maradhat DHCP-n.
El is jutottunk az utolsó, ugyanakkor legfontosabb lépésig, a Edge VM interfészeinek beállításához. Korábban beszéltem róla, hogy az Edge VM mindjét transzport zónának tagja lesz. Ennek megfelelően adjuk hozzá mindkét zónát, majd a legördülőből válasszuk ki az Edge Switch nevét. Amint kiválasztottuk, alatta egy nem szerkeszthető menüben megjelenik a transzport zóna is. Az is látható, hogy miután ebben a kiépítésben vDS port group az uplink-je, ráadásul az port group szinten tag-elt, ezért én a default uplink profilet használom, az „nsx-edge-single_nic_uplink_profile” nevűt. Kiválasztom még, hogy melyik a szóban forgó port group.
Hozzá kell adni még egy N-VDS-t az „Add N-VDS” gombbal. Nem lesz meglepő, de itt az Edge Switch neve az „NVDS_Overlay” lesz. Itt meg kell adni egy TEP IP-t is, amit egy pool megoldásával lehet leghatékonyabban megtenni. Szerencsére a második részben már létrehoztuk. Az egyetlen interfész szintén egy vDS port group-jához csatlakozik. Fontos, hogy a két N-VDS különböző szegmensről/VLAN-ból kapja az uplink-et és az overlay-hálózatot.
A finish kiválasztása után létrejön az első Edge VM, körülbelül 4-5 perc alatt lesz üzemképes.
Hozzunk létre egy másodikat is, pontosan úgy mint az az előbb tettük, csak a neve legyen más, esetemben edge02.5×9.hu lesz. Ha ez is megtörtént, akkor ezt látjuk:
Itt szeretnék kitérni arra, hogy AMD-n nem támogatott az Edge, így hibát fog írni ha valaki EPYC processzoros szerverre tenné. Ha valaki mégis szeretné így használni, akkor az úgy kell lehetővé tenni, hogy az Edge-re bejelentkezünk és módosítjuk a „/opt/vmware/nsx-edge/bin/config.py” fájlt. Ebben kell kikommentelni a következő két sort:
Ezek után SSH-n keresztül ki kell adni a következő parancsot az admin nevében:
Az Edge újraindul és minden működőképes lesz. Hangsúlyozom, hogy ezt csak AMD processzor esetén kell megtenni és biztos vagyok benne hogy, hamarosan hivatalosan támogatott lesz az AMD EPYC és akkor egyáltalán nem kell ezt így kikerülni.
Edge cluster létrehozása
Majd később lesz jelentősége, de amikor egy T0-t vagy T1-et létrehozunk, akkor ezt az entitást fogjuk megadni és ezen valósul meg az aktív/standby or aktív/aktív (ECMP) üzem.
Validáljuk, hogy a klaszter tényleg létrejött és a tagok egymással tunnel-en keresztül látják egymást.
Tier 0 létrehozása
Miután minden telepítésben T0 biztosan lesz ezért annak létrehozásával kell kezdeni.
Nem kell sok adatot megadni, csak azt hogy ECMP-ben legyen-e, ekkor például ECMP-t lehet használni mert a klaszter minden Edge VM tagján aktív lesz a T0 SR komponense. A példában én ezt nem használom, ezért az active/standby-t választom. A Failover mode pedig igazából fallback-et jelent, szóval ha az aktív Edge megáll, a standby átveszi a szerepét, de ha az eredetileg aktív visszatér, akkor a T0 is visszatér rá aktívan.
Itt is van egy kis kitételem. Látható, hogy az Edge Cluster megadása nem kötelező. Amennyiben nem akarunk stateful szolgáltatásokat és elég nekünk a statikus routing, akkor nem kell megadni semmit.
Tier 1 létrehozása
Mivel a Tier 0 már létrejött, kapcsoljunk hozzá egy Tier 1 router-t.
Itt több információt kell megadni, így azt a Tier 0 router-t amihez kapcsolni akarjuk. Van olyan Tier 1 is, amit nem kell Tier 0-hoz kapcsolni, de erről majd később. Én viszont itt az előbb létrehozott T0-hoz kapcsolom, kiválasztom az Edge cluster-t. A standby relocation-t nem kapcsolom, be mert két tagja van csak az edge cluster-nek. Ha három lenne és a Tier 1 router egyik „példánya” az Edge VM hibája miatt megállna, akkor egy másik, azonos Edge cluster-ben lévő másik Edge VM-re tenné át a standby párt.
Itt van egy kis érdekesség. vExpert Slack-en volt egy jó thread arról, hogy ha itt valaki megadja – ahogy én is – az Edge Cluster-t, akkor létrejön a stateful tűzfal a T1-en. Ettől kezdve ha két különböző Tier 1-hez kapcsolt szegmens akar kommunikálni egymással, akkor az meg fogja járni az Edge Cluster-t, illetve azon a T0 SR-t. Így elbukható az a lényeges hatékonyság, amit amúgy a T1-ek között az elosztott útválasztás ad, kernel szinten, mivel ez nem fog működni ebben az esetben.
Ha mindent jól csináltunk, akkor ezt látjuk:
A T0 és T1 közötti kapcsolatot az NSX-T magától megoldja, NSX-V-ben nekünk kellett tranzitot létrehozni. Ez a tranzit itt a 100.64.0.0./16-ot használja. EZ módosítható, de a hálózaton nem jelenik meg és amúgy is reserved range.
Tier 0 uplink
Az NSX-T szintjén a hálózati topológia kialakult – bár majd még létre kell hozni szegmenseket, amelyekbe a virtuális gépek kerülnek – de ebben a pillanatban északi irányba nem lehet kommunikálni. Adjunk tehát hozzá a Tier 0 kofigurációjához egy uplink-et:
Majd „Add”:
A megnyíló ablakban nevezzük el a portot, írjuk be az kívánt MTU-t és válasszuk ki az egyik Edge VM-et. Aztán válasszuk ki a Create New Switch-et. Erre azért van szükség mert amikor az Edge VM-et létrehoztuk, ott nem kellett IP-t megadni ahhoz az N-VDS-hez, hiszen egy T0-n több uplink is lehet.
Nálam az uplink egy vDS port group-ja, ahol kezelem a VLAN ID-t, így itt 0-t adok meg.
Még egy lépés van, ezen az interfészen IP-t kell adni a T0-nak, a „Subnets” résznél.
Javaslom ezt az utolsó három lépést tegyük meg a másik Edge VM-re vonatkoztatva is. Produktív környezetben egy másik szegmensből kapna uplink-et a második Edge VM, ehhez a T0-hoz, nálam azonos VLAN-t használ mindkettő, a második uplink-je egyébként 10.2.170.101.
Innen folytatjuk a következő részben…..
