Az előző részt ott fejeztem be, hogy létrehoztuk a szükséges, három darab controller-t és mivel ezek az NSX-V-től eltérően már converged/collapsed appliance-ok, nem hoztunk létre NSX Manager-t, mivel azt a három NSX Controller szolgáltatja. Ennek működéséhez elengedhetetlen egy közös IP.
A migrációt teljes mértékben feladtam, legfőbb oka pontosan a migrációs varázsló hibaüzenete, az csak hab a tortán, hogy OSPF-et használó ESG-vel nem tud mit kezdeni, hiszen csak BGP-t tud az NSX-T. Ezért a „lift and shift” megközelítés helyett, a „rip and replace”-t használom, azaz létrehozok én magam mindent újra.
Építőkockák
Uplink profile
Ebben kerül definícióra az a szabály és beállítás, ami azokon a hosztokon kerül értelmezésre, amelyek az hosztokat az NSX-T logical switch-ekhez, illetve az NSX Edge Node-okat a külső fizikai hálózathoz kapcsolják. Ezekben szerepel az MTU és a teaming beállítás, illetve a legfontosabb, az VLAN amelyet a hoszt használ.
NSX-V-ben ilyen nem volt.
Virtual Tunnel EndPoint/Tunnel EndPoint
Az elnevezésben van némi különbség, de lényegében ugyanarról beszélünk, V és T esetén is. Ezeken az interfészeken történik meg a csomagok enkapszulációja, így minden az overlay-ben résztvevő hosztnak van egy – legalább – ilyen interfésze. Ez a példában egy L2 szegmens, de ezek a szegmensek lehetnek eltérőek is a szerverek számára, per hoszt is akár. Amiben különbség van, az az, hogy a V-ben az overlay az VXlan, a T-ben pedig Geneve. Viszont ennek létéről úgy körülbelül semmit sem vesz észre az ember.
Transport Zone
A transport zone azt mondja meg, hogy egy logical switch/segment, milyen messzire nyúlhat, azaz mely hosztokon lehet elérhető a virtuális gépek számára. Minden egy transport zónába tartozó logical switch kommunikálhat egymással – ki túlzással.
És itt a nagy különbség az NSX-V és NSX-T között. NSX-V-ben létrehoztunk egy Transport Zone-t és készen is voltunk – az esetek 99%-ban. NSX-T-ben legalább kétféle TZ-t fogunk használni, mert kétféle van:
„Overlay transport zone” amelyeket a host transport node-ok használanak és az NSX-Edge-ek.
„VLAN transport zone” amelyet az NSX Edge használ a VLAN uplink-jei esetén.
Szóval lesz két TZ és az Edge komponens mindkettőbe belelóg. Eddig nem így volt ugye? Eddig volt egy TZ és a DLR komponens egy tranziton keresztül disztributálta a forgalat az Edge felé például egy szintén ugyanabba a TZ-be tartozó logical switch-en.
Ezeket a TZ-ket egyébként N-VDS-ek valósítják meg, azaz ha egy hoszt – függetlenül attól hogy host transport vagy edge transport node – tagja egy TZ-nek, akkor telepítésre kerül rá az adott TZ-re specifikus N-VDS.
N-VDS
Kifejezőbben, az „NSX Managed Virtual Distributed Switch” -ez jelenti, de szerintem ugyanúgy megállja a helyét a „Next generation Virtual Distributed Switch” is. Feladata nem más, mint a kommunikáció megalósítása komponensek között. Végső soron az N-VDS a data plane. Mikor egy TZ-t létrehozunk, akkor asszociálódik hozzá egy N-VDS. Fontos hogy ez az N-VDS bár látszik a vCenter Server-ben, a rajta lévő vmkernel nem látszik és a PG/LS-ek is opaque formátumban vannak ott. vCenter Server irányból annyi látszik, hogy mely vmnic-eket használja, más nem, azaz innen nem is menedzselhető.
Transport Node
A „host transport node” egy olyan kiszolgáló, amely részt vesz az NSX-T overlay üzemeltetésében. Másik fajtája az „edge transport node” ami viszont a külvilág felé kapcsolatot biztosító – és egyéb szolgáltatásokat adó – Edge komponenseknek ad helyet. Az NSX-V-ben ilyen nem volt.
IP-Pool
Egy használható range, amiből a TEP-ek számára kiosztásra kerülnek az IP-címek. Fontos hogy ez nem DHCP-pool! Ettől nem lesz DHCP szolgáltatás, ez csak egy olyan tartomány, amelyből a TEP interfészek IP-t kaphatnak, de úgy hogy a Manager konfigurálja be őket és nem a DHCP-prokoll segítségével saját maguk kérnek IP-t.
Design
A lehetőségek száma végtelen, de alapvetően három fő vonal van és ezek abban térnek el, hogy hány klaszterrel dolgozunk:
- Egy klaszter, azaz collapsed Compute, Edge és Management klaszter
- Két klaszter, azaz Compute és Collapsed Edge és Management klaszter
- Három klaszter, azaz külön Compute, külön Edge és külön Management klaszter
Én az első opciót fogom megvalósítani, annak ellenére, hogy ebben van a lehető legtöbb megkötés. Ez hatványozottan igaz, ha két használható interfésze van egy hosztnak. Mivel egy N-VDS mindenképpen lesz az Overlay „Transport Zone” miatt, amiben a hosztoknak a TEP interfésze lesz, ezért oda már el használódik egy fizikai port. Marad egy, amin nem lehet megvalósítani a vMotion/mgmt VMkertnel-t és a VLAN backed port group-okat.
Hogy lehet ezt feloldani? Úgy hogy négy interfészt használunk, de ha nincs rá lehetőség, akkor van mód arra, hogy teljesen átálljunk N-VDS-re, akkor az a switch használhatja mindkét uplink-et. Ez azt is jelenti, hogy át kell migrálni rá minden vmkernel interfészt és lényegében az N-VDS mint egy ilyen dormant dolog a vCenter-ben bár ott lesz, kevés információ és még kevesebb akció hajtható végre rajta, NSX Manager-ből kell menedzselni inkább. Ez azonban a telepítés egyik lépésében, méghozzá ahol az Edge VM-nek adunk majd uplink port group-ot, akkor problémát fog okozni. Ez a 2.4-ben is így van, egyszerűen a GUI-n, abban a mezőben nem jeleníti meg az N-VDS-ről a port group-okat. CLI/RestAPI-n be lehet állítani, de a grafikus felületen nem.
Ehelyett én négy interfészt fogok haszálni:
A collapsed design sajátja, hogy elég egy N-VDS is. Tehát Transport Zónából ugyanúgy kettő kell és két interfészt az overlay-re, kettőt pedig az uplink-re (is) fogok használni.
Telepítés
Uplink profile létrehozása
Pár bekezdéssel feljebb megismertük, hogy mi ez. Alapból kapunk négy default profilt és amennyiben nem felel meg nekünk – nem fog! – akkor hozzunk létre egy újat. Egyébként ezek az alapból definiáltak:
Fentebb látszik, hogy az első sorban a hostra vonatkozó uplink profil van, a 2-4 sorban pedig az Edge-re vonatkozó. Az alapértelmezett profilok, nem módosíthatóak, tehát hozzunk létre egyet – ha több klaszterem lenne, akkor többet hoznék létre, függetlenül attól, hogy az uplink konfigurációjuk azonos:
Na mit is állítottunk be? LAG-ot nem, de ha valaki azt szeretné, akkor azt is lehet. Lényegében elneveztem az uplink profile-t, majd megmondtam hogy a teaming policy „failover order” és megadtam hogy az uplink-1 legyen az aktív és az uplink-2 a standby. Ezek itt csak dummy nevek, majd amikor a hoszt „Transport Node” lesz, akkor kell megmondani hogy melyik vmnic az uplink-1-nek megfeleltetett és melyik az uplink-2. Ezen kívül még szerepel a VLAN, amelyik az overlay forgalmat hordozza – ha nem access port amin kommunikálunk – és az MTU – esetemben 9000.
A teaming policy-nél egyébként van lehetőség a „Failover order” helyett „Load Balance Source”-t is választani, akkor mindkét uplink lehet aktív, de ez csak ESXi-nél lehetséges – és az NSX-T használhat amúgy KVM-et is például. Ebben az esetben a Source Port ID alapon kerül kiosztásra az uplink. Van még „Load balanced source MAC” lehetőség is, ekkor szintén nem lehet standby uplink.
Transport Zone létrehozása
Korábban kiderült hogy kettőre lesz szükség, hozzuk létre őket:
Az Edge-ek számára:
És az overlay számára:
Látom a kikerekedő szemeket, hogy mi az az „Enhanced Datapath”. Amennyiben támogatott NIC-el rendelkezünk, akkor lehetséges annak emelt képességeit kiaknázni. Így ez egy olyan network stack mode, amivel elméletileg magasabb teljesítmény érhető el, ezáltal elsődlegesen NFV – értsd telco – szektor profitálhat a nyereségől.Lényegében minden az elmúlt két évben vásárolt kártya támogatott:
Ilyenkor még arra is van mód hogy a késleltetés minimalizációját segítsük abban, hogy a „Load Balanced Source” teaming beállítás NUMA aware legyen, szóval tényleg figyeljen arra, hogy a VM futása azonos NUMA node-on belül történjen, mint amihez adott N-VDS fizikai uplink-je kötve van.
Ha mindent jól csináltunk, akkor ezt látjuk:
IP pool létrehozása
A TEP interfészeknek szükségük lesz IP-címre is és ezeket egy vagy több pool képes kiszolgálni. Hozzunk létre egyet.
Transport Node Profile létrehozása
Most hogy megvan mindkét TZ, hozzuk létre a profilt is. Itt rendelünk hozzá egy hoszthoz TZ-t, a TZ-khez pedig N-VDS-eket, állítjuk be az uplink profile-t és konfiguráljuk az uplink-eket.
Az „N-VDS” tab-on kiválasztjuk az „NVDS_Overlay” N-VDS-t és konfiguráljuk:
Látható, hogy a korábban létrehozott profilokkal tudunk dolgozni, a „Physical NICs” résznél pedig az N-VDS uplink-jeit adjuk meg. Erre is igaz hogy ha több klaszter van, akkor klaszterenként legyen egy profil.
A következő részben innen folytatjuk………..
