Mi az az Edge és miért fontos hová/hogyan kerüljön?
Az észak-déli forgalom kikerülhetetlen komponense az Edge komponens, ezért ennek elhelyezése megér egy külön posztot, főleg mert erősen befolyásolja a design-t, a hálózati igényeket és természetesen a skálázhatóságot is.
Dedicated compute cluster + Dedicated Edge (vagy Collapsed Management és Edge) cluster
Ebben a kiépítésben csak a compute cluster ESXi kiszolgálóira kerül telepítésre az NSX-T, mármint annak VIB komponensei és kicsit kisarkítva, ezeknek lesz csak igazi TEP interfészük az adott overlay-ben.
Itt a lenti példában, minden hosztnak két fizikai hálózati interfésze van. Ez amúgy egyre gyakoribb, főleg a rack mount szerverek esetén, ahol például két NIC port valami komolyabb sávszélességgel bír – 10/25/40 Gbit – és van pár ami például 1/10 Gbit-es. A blade szervereknél ez kevésbé értelmezhető, mivel ott fizikailag gyakorta összesen van két port, de azokat lehet tovább virtualizálni több funkcióra – UCS, Synergy VC. A blade-ek esetében ezért én mégis azt javasolnám, ha lehet, akkor daraboljuk mindkét fizikai NIC-et két-két darabra, ha nem szeretnénk mindent az N-VDS-re migrálni.
De miért is ne szeretnénk?
- azért, mert az N-VDS-re migrált vmkernel interfészeket csak korlátozottan lehet látni/konfigurálni vCenter Server által.
- azért, mert az N-VDS-re migrált minden port group menedzsmentje csak az NSX Manager-ből hajtható végre. A vCenter Server inventory-jában opaque hálózatokként látszódnak majd ezek az NSX terminológiában Logical Switch/Segment-nek hívott entitások.
- azért, mert ha felelepítünk egy új hosztot, akkor törődni kell az alapértelmezetten létrejövő standard vSwitch kiürítéséről és eltávolításáról – mondjuk ez szkriptelhető.
Na vissza az első opcióhoz. Látható, hogy van egy NSX prepared klaszter, amin a VM-ek futnak és van egy másik klaszter, amiben pedig mondjuk a vCenter és az Edge VM(ek) is vannak. A zöld színnel jelölt részek az overlay hálózatot jelentik, azt a részét ami az overlay transport zóna kapcsán játszanak szerepet. A pirossal jelölt részek pedig az edge overlay zóna és uplink irányú komponenseit jelöli.
Amikor az Edge VM-et telepítjük, akkor lényegében két tansport zónának is tagja lesz, azaz meg kell kapja a compute klaszterből, a neki szánt forgalmat és azt tudnia kell kifelé továbbítani és ezt egy VLAN backed transport zónán teszi, méghozzá olyanon, ami egy vSS/vDS egy port group-ja.
Fully collapsed cluster – két NIC
Ebben az esetben, csak egy klaszter van, abban van minden. Itt is csak két fizikai interfész van, ezért hogy redundáns legyen, egészen egyszerűen muszáj mindkettő az N-VDS-nek adni. Az N-VDS-nek szüksége van valami fizikai interfészre. Meg lehet oldani úgy hogy az egyik fizikai NIC-et egy vSS/vDS kapja és a másikat pedig az N-VDS, de akkor nem lesz redundáns – ezért ezt a megoldást fel sem rajzolom, senki se csináljon ilyet!
Szóval marad az alább látható opció, azaz csak egy N-VDS lesz és semmi más. Ez használja a NIC1-et és a NIC2-t. Minden ehhez csatlakozik majd, az ESXi management/vMotion/VSAN vmkernel-eitől kezdve a nem NSX alá bevont VM-ekkel bezáróan.
Ennek azonban van egy fontos buktatója, bár ha ismerjük, akkor már nem is buktató. Az ESXi TEP interfésze – TEP_vMkernel – nem használt azonos VLAN-t az Edge VM, TEP interfésze – pirossal vNIC2 és PG_TEP_EDGE port group – használttal. Ez nem komoly limitáció, kell egy másik VLAN is, de azért egymást routing-ban érjék el. Ez jelenti egyébként azt is, hogy compute overlay-ből a forgalom, a TOR-on keresztül történik az Edge VM-ek irányába.
Fully collapsed cluster – négy NIC
Szinte megszólalásig hasonlít a két NIC-es megoldásra, de megőrizhető a vSS/vDS, ha valaki például a tart a vmkernel portok N-VDS-re történő migrációjától vagy például ha a management vmkernel egy másik, csak menedzsmentre használt switch-párra csatlakozik. Igaz ez a vMotion-ra is, például ha csak egy blade kereten belül szeretnénk megépíteni a klasztert akkor adható olyan NIC erre, aminek lényegében fizikai uplinkje a keretből nézve, északi irányba nincs.
Tehát a vSS/vDS használhatja továbbra is a NIC1-et és NIC2-t, az N-VDS pedig a NIC3-at és a NIC4-et. A káposzta és a kecske is megmaradt, azaz van redundancia és megőriztük a függetlenséget.
Fizikai Edge – 4 NIC
Ez itt csak egy példa, tényleg van pár megoldás. Alább egy N-VDS-lesz a bare metal gépen ami az Edge szerepkört látja el. Így a redundancia is megmarad, ha például négy fizikai interfész áll rendelkezésre a fizikai szerverben – ráadásul a negyediket nem is használjuk. Arra is van lehetőség, hogy az Edge MGMT interfészét in-band valósítsuk meg, akkor igazából elég két NIC is a fizikai Edge szerverben, de ki szeretné in-band menedzselni…… Az ábrán a nem használt NIC-et nem jelöltem.
Ennek a megoldásnak az a hátránya, hogy a forgalmi irányokat tekintve azonos fizikai interfészen jön be az overlay forgalom és megy ki/jön be az észak-déli.
Fizikai edge – 6 NIC
Ha ez szeretnénk elkerülni – amit javaslok – akkor van mód arra, hogy egészen nyolc NIC-et felhasználjunk. Ekkor lehet kettőt dedikálni az overlay-re, másik kettőt az észak-déli irányra, megtartva a redundanciát. Az ábrán a nem használt NIC-et nem jelöltem.
Összefoglaló
Mint látható, nagyon sok kombináció és lehetőség van az Edge elhelyezésére, nagy számmal szerintem úgyis mindenki VM-ként fogja futtatni, az adja a legtöbb rugalmasságot, illetve könnyebb feltenni pár újabb Edge VM-et, mint teljes hosztokat, ha szükség van ilyen szinten izolációra vagy szolgáltatások szeparációjára.
