Érzékem van a szürke zónák megtalálásához, mi több itt érzem magam igazán elememben. Többször írtam már az NSX-T által használt Edge VM-ek lelki világáról, jobban mondva arról, hogy a bennük kialakított Tier 0 milyen igényekkel és beállításokkal tehető redundánssá.
Az NSX-T dokumentációja a VMware oldalán ebben nem sok segítséget ad, az NSX Design Guide jó irány lehet. Általában a VMware Cloud Foundation tekintett a de facto-nak, tehát mivel az a VMware Validated Design-on alapul, biztosan tud mérvadó lenni. Sokszor az, de a VCF életében volt pár olyan, mikor pontosan rosszul állított be valamit, majd a következő verzióban javításra került valami.
Mielőtt felhozom a problémámat, ismételjünk picit. Mire van szüksége egy Edge VM-nek a legtöbb esetben – igen tudom, van single TEP, single uplink stb – tehát egy normál multi-TEP, two uplink VLAN esetben?
- 2 darab Trunk vDS PG – vagy NSX VLAN backed szegmens
- 1 darab TEP VLAN
- 2 darab uplink VLAN
- 2 darab named uplink policy – ez a determinisztikus uplink VLAN miatt kell
- 2 darab IP a TEP VLAN hálózaton
- 2 darab IP az uplink VLAN hálózaton
- 1 darab management VLAN
- 1 darab IP a management VLAN hálózaton
Azt már korábban tárgyaltam hogy egy adott port group beállításainál mit kell beállítani, mert bár működni fog a rendszer, de valamilyen kiesés esetén akár percekig vagy manuális beavatkozásig nem forgalmaz, minden forgalom megy a black hole-ba.
A fenti képet felbővítve a vDS uplink-jeivel ezt kapjuk.
Tehát a Trunk 1 port group a vDS Uplink 1-et – például – kell tartalmazza mint active és vDS Uplink 2-t mint standby adapter, a Trunk 2 port group pedig a vDS Uplink 2-t mint active és a vDS Uplink 1-et mint standby.
Itt volt az a rész, mikor a VMware Cloud Foundation nem standby-ba tette a másik oldalt, hanem unused-be, teljesen hibásan, mert……
Mikor a TOR 1 tegyük fel újraindul, akkor nyilvánvalóan az Uplink 1 VLAN-ban az érintett T0 számára megszűnik a kommunikáció, tehát abban a VLAN-ban nem tud északi/déli irányban forgalmazni. De erre nincs is szükség, mert a gyártó elmondása szerint a BFD-re – BGP/OSPF – kell bízni a hiba feloldását. Az érintett TEP interfész mivel a TEP VLAN mindkét TOR switch-en ott van, ezért az érintett port group majd a másik uplink-en, a hoszt másik vmnic-jén kertesztül a másik TOR switch-en keresztül tovább tud működni.
És akkor van ilyen rész az NSX dokumentációjában:
On a vDS switch running version equal to or greater than (>=) 6.6, enable mac learning and disable promiscuous mode. These settings ensure that packets are received at the destination where destination mac address does not match the virtual NIC effective MAC address.
Erre semmiféle találat nincs az NSX Design Guide-ban. Készítettem egy nem reprezentatív felmérést a vExpert NSX közösségben és elenyésző azok száma, akik a MAC learning-et beállítják. Ez azért meglepő mert az első sorban ez szerepel „you must do”. Számomra ez kötelezőt jelent.
Ez mikor lehet lényeges, mikor kellhet ez a beállítás? Akkor, mikor az Edge VM elveszti a kapcsolatot az egyik lábán oly módon, hogy az az interfész disconnected-be kerül. A fenti esetben ez soha nem fordul elő, mivel van egy active és egy standby adapter. Ha mégis, akkor valamilyen megmagyarázhatatlan okból a disconnected Edge VM NIC-en korábban lévő TEP IP-t át akarja vinni az Edge VM a másik interfészére és akkor azért áll meg mert hirtelen egy másik MAC is megjelenne az interfészen, amit a vDS nyilvánvalóan nem szívlel a port group-on.
Több rendszert építettem már és az Edge tesztelése mindig kiterjedt és körültekintő. Nem csak a háttért szolgáltató hálózati réteg viselkedését tesztelem, hanem az emberi hibából eredő dolgokat is. Tehát a teljesség igénye nélkül én ezeket – is – végre szoktam hajtani a rendszer tesztelésekor:
- TOR switch kikapcsolás
- TOR switch bekapcsolás
- TOR switch hoszt felé néző portjának letiltása
- TOR switch hoszt felé néző portján az uplink VLAN levétele a trunk-ről
- Edge VM kikapcsolása
- Edge VM újraindítása
- Edge VM hálózati kapcsolatainak módosítása – azaz Connected pipa eltávolítása
Ez az utóbbi eset, ami romba tudja dönteni az NSX-et, akkor ha a dokumentáció „must do” részét valaki nem hajtja végre. És igen, aláírom, hogy „very unlikely”, hogy miért venné ki a pipát valaki az Edge VM-ről felelőtlenül? Ezek mind olyan esetek, amelyeket nem kellene kezelni, de én szeretem lefedni az összes eset, minden lehetséges kimenetelét, főleg akkor ha a gyártó is kéri, bár közel sem konzisztens módon.
Tehát vagy el kell tüntetni az NSX dokumentációjából ezt a részt, vagy bele kell tenni az NSX Design Guide-ba, vagy éppen át kell fogalmazni a „must do” kifejezést „might have to do” sorra.
