Korábban ezt a posztot megírtam angolul és azt 2200-an látták eddig. Kaptam kommenteket komoly szakemberektől – VCDX-ektől is – de valahogy a VMware-től bár 79-en látták, egyik sem “tetszikelte” vagy osztotta meg. Ennél jobban szerintem semmi sem magyarázza, hogy az elevenjükre sikerült tapintani. A VMware NSX twitter-én olyan alapcikkeket is megosztanak, amik arról szólnak, hogy kell deploy-olni egy NSX Managert – ami így a termék több éves megléte után kicsit vicc kategória, viszont az enyémet egyáltalán nem 😉
Szóval a 2.5 megjelenésekor megjelent a design guide is, ami a multi-NVDS-t váltotta a Single NVDS design-nal. Nos a 3.0 és közvetve a vSphere 7 megjelenésével még inkább megváltozott minden, tekinve hogy végre képes vDS-t használni az ESXi is a TEP networking-re. Az hogy az Edge VM képes vDS port group-ot fogyasztani, az már ismerős lehet, de valahogy csak nem sikerült egy friss design guide-ot kiadnia a gyártónak.
Alább én nem állítom azt egyik bemutatott opcióról, hogy az tökéletes és javasolt. Nem beszélek aktív-aktív T0-ról sem csak aktív/készenléti-ről.
Viszont a lehetéges megoldások az Edge hálózati kialakítására elég magas számmal lézeznek. Meg sem próbálkozom mindet leírni – majd ha a VMware fizetési listáján IS leszek, akkor talán – csak közülök párat.Újfent hangsúlyozom, hogy nem tudom melyik a legjobb, mindegyik működik amúgy.
Az alábbi példákban én egy VLAN-ban peer-elek egy IRF-ben lévő switch-párral, de lesz olyan példa amiben két VLAN is lesz és természetesen két switch.Below in the examples I am peering in one VLAN with Switch1/2 which are in one IRF – there will be one example where two VLANs are to be used and naturally two peers.
Az első különbség pont ez, hány uplink VLAN van:
- egy
- kettő
A második elágazás, hogy hány TEP interfész van:
- egy
- kettő
És ha ez még nem lenne elég, akkor a vDS-en, illetve a port group-okon beállítható a következő load balancing opciók állnak rendelkezésre. Na nézzük meg a fenti két lehetőséget és azokat extrapoláljuk azzal amiket be lehet állítani.
Egészen addig amíg egy port group-nak egyetlen aktív fizikai interfész van beállítva, addig teljesen mindegy melyiket is állítjuk be a fentiek közül, azonban van olyan rendszer, ahol több van. Na az ilyen esetekben nehéz megérteni mi is történik. Ezzel meg sem próbálkozom ebben a cikkben és nemes egyszerűséggel az alapértelmezett beállítást használom amennyien nem egy aktív interfészem van. A MAC hash és IP hash között az egyiknek több a CPU terhelése és pont emiatt – talán öreg is vagyok már – de az alacsonyabb CPU igényűt használom, mert szeretem ha egy csomag minél gyorsabban megjárja a stack-et.
(Kis komment ezzel kapcsolatosan. Gondoljuk végig hogyha felrajzoljuk egy Edge VM TEP interfészét(interfészeit) és megnézzük kikkel kommunikál, akkor nincs túl nagy változatosság, hiszen más Edge VM TEP-jével és a hosztok TEP interfészeivel. Szóval a honnan-hova mátrix eléggé kicsi, akkor meg mégis minek számoltatnánk vele folyamatosan minden csomagra?)
Nyiván lehet LAG-ot is használni és az én kézjegyem az lassan az lesz, hogy a lehető legalacsonyabb komplexitásra törekszem, továbbá a 25/50/100Gbit-es világban nem nagyon látom értelmét LACP-vel összefogni.
Mielőtt belevágok, erre érdemes emlékezni:
Igen. Ha nem hiszed el, akkor olvasd el újra. Ez pont azt jelenti, hogyha nem használsz named uplink policy-t – VLAN esetén csak failover lehet, ahol egy aktív uplink lehet – fp-eth0 – és nulla készenléti – akkor ha az az uplink – tehát az adott fizikai interfész például – megáll, akkor az uplink VLAN nem kerül át az fp-eth1 interfészre.
Aztán ez is lényeges:
Amit ez állít az nem más mint, azokban az esetekben ha legaláb 6.6-os vDS verzión fut az NSX ott a Mac learning-et kell beállítani, az alacsonyabb verziók esetén forded transmit-ot. Szóval ha ezek nincsenek meg és az egyik uplink elveszne, akkor az addig azon az interfészen ülő TEP interfész IP-je és Mac-je mozogna a túlélő fizikai interfészre a másik TEP IP mellé, de nem tud átmenni és a csomagok mennének a dev nullba. Na a Mac learning-et nem lehet GUI-ról bekapcsolni!
Na nézzük a példákat!
Multiple TEP – One uplink VLAN – vDS PGs with one uplink and no standby, named uplink policy
Két named policy kell hozzá, hiába van egyetlen uplink VLAN. Egy T0 van, aminek az első Edge VM-ről az uplink-1, a második Edge VM-ről az uplink-2 irányba van ugyanaz a VLAN.
Ennek a hátránya az az, hogy bár a TEP forgalom mindkét fizikai interfészt aktívan fogja használni, de az uplink irány csak az egyiket – még mindig A/S-ről beszélek – továbbá, ha az aktív Edge VM által használt uplink alól elveszik a kapcsolat, akkor mindenképpen T0 failover lesz.
Multiple TEP – One uplink VLAN – vDS PGs with two uplinks, one active and one standby – named uplink policy
Hasonló az előzőhöz, de ebben a vDS port group-ok stanby adapterként használhatják a másik interfészt is.
Nyilván azt kérdezed, hogy miért? Ennek a lehetőségnek egyetlen előnye, hogy az előbbi esettel szemben uplink vesztés esetén nincs T0 failover.
Multiple TEP – One uplink VLAN – vDS PGs with two uplinks, one active and one standby – no named uplink policy
Mint azt a bevezetőben említettem, itt az uplink forgalom mindig az fp-eth0-n történik, teljesen mindegy melyik Edge VM-ben aktív a T0.
(NEM JAVASOLT, HIBÁKAT OKOZHAT) Multiple TEP – Two uplink VLANs – vDS PGs with one uplink and no standby – named uplink policy
A Cloud Foundation ezt használta a 4.0-ban.Hibákat is okozott, nem működik a failover rendesen….known issue.
Inkább a “Multiple TEP – Two uplink VLANs – vDS PGs with one active uplink and one standby – named uplink policy” javasolt használni!
Multiple TEP – Two uplink VLANs – vDS PGs with one active uplink and one standby – named uplink policy
Biztosan van pár ilyen telepítés is, nagyon hasonló a fentihez annyi különbséggel, hogy a vDS port group-okban van standby interfész is, pont a másik PG aktív adapter-e. Az NSX Design Guide 165-ik oldalán is ez van.
Single TEP – One uplink VLAN – vDS PG with one active and one standby
Ebben a hiba elhárítása a vDS-re van bízva. Itt Edge VM-enként egy TEP interfész van, egy VLAN-ban van peering.
Összefoglaló
Minden amit javasolni tudok, hogy mindent ki kell próbálni, mivel az Edge VM hálózati kiépítése nagyon absztrakt, hiszen egy vDS-en lévő PG-khez csatlakozik, ami felett még named uplink policy-k is lehetnek NSX-ben. Ráadásul a PG-ken lehet akármilyen policy. Tényleg a fizikai rétegtől – értsd kábel kidug-bedug – kell letesztelni mindent egész a belső működésig, mielőtt bármi élesbe menne.
