Dvounodový cluster je nejmenší možná konfigurace vSAN. Tato konfigurace je primárně určena pro pobočky firem, které potřebují část výpočetního výkonu lokálně (navrhnuto pro americký trh). V České republice je však takovýto cluster použitelný jako primární serverová infrastruktura pro menší firmy. Poskytuje redundanci všech hlavních komponent (výpočetní a diskový výkon). Celá konfigurace se skládá ze dvou serverů a místa, kde je umístěno witness VM (to může být nějaký servřík s minimem prostředků, stejně tak ale může být umístěno někde v datovém centru).
My se dnes budeme bavit o tom, jak takový cluster síťově spojit a jaká jsou úskalí některých voleb. Nebudu zde popisovat základy vSphere networkingu, ty jsou detailně popsány zde, stejně tak všeobecná doporučení vSAN networkignu jsou popsána zde.
Propojení nodů
Jedna z výhod dvounodového řešení je, že pro vSAN a vMotion traffic lze použít pouze pasivní přenosové médium. Není tak potřeba žádných switchů. Stačí mít dva volné porty a ty propojit proti sobě. Samozřejmě porty volíme dle zamýšlené konfigurace. Pokud zamýšlíte hybridní řešení (SSD pro cache a rotační disky jako storage), stačí vám 1Gb porty, v All-flash variantě jsou již požadovány 10Gb porty. Všeobecně vždy doporučuji použít 10Gb porty, ideálně dvě dvouportové karty. Máte tak redundanci proti chybě jedné z nich a zbývající porty se dají použít právě např. pro vMotion. Jelikož u tohoto řešení nepotřebujeme další networing, tak 10Gb NIC nejsou zásadním prodražením řešení.
Propojení witness
Jak jsem psal v úvodu, witness VM může běžet teoreticky kdekoliv. Musí být pouze zachovány minimální požadavky konektivity, 1,5 Mbps šířka pásma a latence nižší než 500ms. Doporučené hodnoty bych ale zvažoval před samotným nasazením s ohledem na zamýšlený počet a velikost VM (rozhodující je počet objektů). Přesný výpočet je popsán zde.
Základní vlastnosti
– pro vSAN traffic se používá VMkernel port
– vSAN nepodporuje multipath
– jumbo frames je doporučen (MTU 9000)
Scénáře
1) Použití dvou VMkernel portů
Tento scénář je podporovaný, ale nedoporučovaný. Existují sice dvě na sobě naprosto nezávislé cesty, a tak je scénář podobný klasickým SAN sítím, nicméně má mnoho nevýhod daných vlastnostmi vSAN např.:
- vSphere ani vSAN nepodporují více VMkernel adaptérů ve stejném subnetu, každý vmkX tak musí mít IP z jiného rozsahu, viz. VMware KB 2010877
- každý VMkernel port musí mít přiřazeny dva fyzické uplinky, v opačném případě vSphere hlásí chybu “network uplink redundancy lost”
- vzhledem k tomu, že vSAN nepodporuje multipath, tento scénář nepřináší benefit rozkladu zátěže
- při selhání aktivní cesty může v některý konfiguracích trvat přechod na další cestu až 90 sekund, toto je způsobeno ESXi TCP connection timeoutem
2) Použítí jednoho VMkernel portu
Tento scénář minimalizuje konfiguraci, zjednodušuje troubleshooting, a pokud se správně nastaví teaming a failover, tak vás nečekají žádná nepříjemná překvapení. Ukážeme si tedy, jaké volby máme k dispozici.
Load balancing – jediné smysluplné varianty jsou “Route Based on Physical NIC” a “Route Based on Originating Virtual Port”, záleží spíš na tom, jaký typ virtuálního switche použijete, jestli VSS nebo VDS.
Network failure detection a Notify switches – tyto parametry ponecháme v defaultu, jejich další volby nemají u direct connect řešení smysl.
Failback – je volba, která může mnohé ovlivnit. Záleží však na nastavení “Failover Order”, viz. dále.
Failover Order Active/Active
Tato volba na první pohled vypadá pěkně, ale to, co se za ní skrývá, už tak pěkné není. Připomeňme si, že vSAN nepodporuje multipath a vSAN traffic nemůže použít dvou cest zároveň. Nastavení “Failback” v tomto případě nehraje roli, obě linky jsou ve stavu “Active”, a tak i když jedna vypadne a traffic přejde na druhou, tak dokud ta bude aktivní, nikdy se nevrátí zpět, viz. VMware KB 2072928. Tato volba ale může mít ještě horší dopad. Pokud v takto nakonfigurovaném clusteru budete chtít provést běžný vSphere update nebo prostě jen restartovat server, tak se vSAN na síťové vrstvě již z vysokou pravděpodobností nespojí. Je to způsobeno tím, že node, který zůstal v provozu, přešel na druhý uplink, a node, který se právě vrátil po restartu, vidí oba uplinky v pořádku, tak se zkouší spojit po prvním uplinku, kde již druhý node nenaslouchá. Existují dvě varianty, jak tento stav opravit:
- jeden z linků fyzicky rozpojit, pak oba nody přejdou na jeden zbývající a vše se vrátí do funkčního stavu
- změnit “Failover Order” nastavení
Failover Order Active/Standby
Dle mého názoru nejvhodnější možná varianta. Oba nody mají vždy aktivní pouze jeden uplink a nedochází ke křížení a případné nefunkčnosti. V této variantě taktéž je možné efektivně uplatnit volbu “Failback”. V této konfiguraci pokud je “Failback” nastaven na “No” při poruše Uplink 1 přejde provoz na Uplink 2, po znovuobnovení Uplink 1 však zůstává provoz na Uplink2. Pokud je “Failback” nastaven na “Yes”, tak při poruše Uplink 1 dojde k přepnutí na Uplink 2 a po znovuobnovení Uplink 1 přechází provoz zpět na něj. Toto ale v případě chyby, která způsobuje flapování, může mít negativní vliv na výkon. Osobně si myslím, že není důvod, aby se přecházelo zpět, dokud je cesta, kterou proudí data, funkční.
Nastavení vSAN a Witness trafficu
U 2-node Direct Connect clusteru je nutné přesměrovat witness traffic proti witness VM. Tím, že jsou nody připojeny proti sobě na přímo, není tak witness VM, kam připojit. I vzhledem k tomu, že witness VM může být mimo lokalitu a komunikace již může probíhat za pomocí routingu, je witness traffic oddělen a směrován ideálně přes management VMkernel port.
Nastavení vSAN trafficu
Lze provést dvěma způsoby, z GUI:
což je asi nejrychlejší i vzhledem k tomu, že je nutno VMkernel vytvořit. Druhá varianta je pomocí příkazu:
esxcli vsan network ipv4 add -i vmk1 -T=vsan
Nastavení Witness trafficu
Witness traffic lze nastavit pouze z příkazové řádky pomocí příkazu:
esxcli vsan network ipv4 add -i vmk0 -T=witness
Kontrola nastavení
pomocí příkazu esxcli vsan network list zkontrolujeme, že máme správně nastaveno
[root@esxi:~] esxcli vsan network list Interface VmkNic Name: vmk1 IP Protocol: IP Interface UUID: 654e125b-4700-e7c1-bf1c-e0071b66d180 Agent Group Multicast Address: 224.2.3.4 Agent Group IPv6 Multicast Address: ff19::2:3:4 Agent Group Multicast Port: 23451 Master Group Multicast Address: 224.1.2.3 Master Group IPv6 Multicast Address: ff19::1:2:3 Master Group Multicast Port: 12345 Host Unicast Channel Bound Port: 12321 Multicast TTL: 5 Traffic Type: vsan Interface VmkNic Name: vmk0 IP Protocol: IP Interface UUID: 5b50125b-5001-b359-e3da-e0071b66d180 Agent Group Multicast Address: 224.2.3.4 Agent Group IPv6 Multicast Address: ff19::2:3:4 Agent Group Multicast Port: 23451 Master Group Multicast Address: 224.1.2.3 Master Group IPv6 Multicast Address: ff19::1:2:3 Master Group Multicast Port: 12345 Host Unicast Channel Bound Port: 12321 Multicast TTL: 5 Traffic Type: witness