Vlastní technologie NIC Teaming či Link Aggregation či EtherChannel je popsána v předchozích článcích. Zde se budeme věnovat přímo nastavení NIC Teamingu na VMware ESXi (přesněji ESXi 4.0.0, který patří do rodiny VMware vSphere) a kombinaci s Cisco switchem. ESXi funguje spolehlivě, výkonně a nabízí všechny potřebné funkce. Oblast výkonu (hlavně pro určité situace) můžeme výrazně zvýšit, když použijeme připojení přes dvě nebo více síťových karet.

Pozn.: V článku se hojně užívají dvě zkratky. VM - Virtual Machine, tedy virtuální počítač, který běží uvnitř ESXi serveru. NIC - Network Interface Controller, tedy síťová karta či síťový adaptér. Může se jednat o fyzický adaptér, který se nachází v serveru a pomocí něj je zapojen do počítačové sítě (přes nějaký fyzický switch). Nebo virtuální adaptér, který je uvnitř VM a pomocí něj je virtuál připojen k virtuálnímu switchi (vSwitch) a dále může být propojen přes fyzický adaptér do sítě.

Znatelný rozdíl v rychlosti, pokud použijeme více než jeden síťový adaptér, získáme pro operace, kdy na ESXi server nahráváme data. Tedy například při převodu fyzického stroje na virtuální nebo další akce pomocí VMware vCenter Converter. ESXi pravděpodobně při použití jednoho síťového adaptéru vyhradí většinu pásma pro VM network, takže ostatní operace jsou velmi pomalé. Když se přidá další NIC, tak se provoz rozdělí.

Pozn.: Úvodní podmínkou pro provozování NIC Teamingu je samozřejmě podpora dané síťové karty v ESXi. Od verze ESXi 4 jsou podporovány pouze Gigabitové NIC. Co se však týče výrobců a modelů, tak je podpora opravdu široká.

VMware NIC Teaming

Výhody, které získáme připojením serveru s ESXi do počítačové sítě pomocí více síťových adaptérů, jsou asi jasné. Můžeme dosáhnout navýšení propustnosti, kdy se komunikace podle určitých parametrů rozdělí a proudí přes různé fyzické NIC. Dále získáme odolnost proti výpadku, kdy se komunikace přepne na záložní linku (nebo prostě přestane používat tu nefunkční). Obě tyto výhody jsou obzvlášť vhodné pro virtualizaci, protože jsme konsolidovali více serverů na jeden HW. Navíc asi každý dnešní server má minimálně dvě síťové karty, a pokud ty další nepoužíváme k ničemu jinému (jako je například připojení k iSCSI), tak nás použití Teamingu téměř nic nestojí (samozřejmě musíme mít zdroje jako port na switchi apod).

Stejně, jako u NIC Teamingu ve Windows, máme dvě hlavní možnosti, jak Teaming nastavit. Od toho se také odvíjí, jaké prostředky budeme potřebovat.

1. konfiguraci provedeme pouze na ESXi - můžeme se připojit k libovolným switchům (to znamená i k jednoduchým bez managementu) a můžeme se zároveň připojit k různým switchům, vyvažování je pouze jednosměrné, pomalejší failover
2. konfigurujeme ESXi server i switch - máme oboustranný Teaming, ale potřebujeme switch, který to podporuje, navíc většinou pak musíme všechny spojení (na kterých se konfiguruje Teaming) vést do stejného switche

Konfigurace VMware ESXi

Vyjdeme z počátečního stavu, kdy máme čistě nainstalovaný (což samozřejmě není podmínkou) ESXi 4.0, kde máme nastavenu Management Network, tedy přiřazen jeden síťový adaptér s IP adresou. Používáme VLANy, takže na tomto spoji je nastaven trunk na straně switche a na straně ESXi je nastavena VLAN, v které se nachází IP adresa na Management Network.

Konfigurace portu na switchi může vypadat následovně:

interface GigabitEthernet1/0/30
  description ESXi-1
  switchport trunk encapsulation dot1q
  switchport trunk allowed vlan 200,400
  switchport mode trunk
  switchport nonegotiate
end

Nyní přidáme druhý síťový adaptér, čímž se automaticky zapne Teaming. Důležité je, aby další port na switchi měl správnou konfiguraci, to znamená stejnou, jako ten první. Takže například:

interface GigabitEthernet1/0/31
  description ESXi-2
  switchport trunk encapsulation dot1q
  switchport trunk allowed vlan 200,400
  switchport mode trunk
  switchport nonegotiate
end

Pozn.: Pokud budeme mít konfiguraci jinou, tak neuvidíme žádnou chybu, ale prostě to nebude fungovat.

Přidání dalšího adaptéru provedeme následujícím způsobem, obrázky ilustrují celý proces.

• připojíme se pomocí vSphere Client na ESXi
• záložka Configuration
• menu Hardware - Networking

• vedle Virtual Switch: vSwitch0 klikneme na Properties
• záložka Network Adapters - klikneme na Add
• zatrhneme adaptéry, které chceme přidat

• necháme adaptéry jako aktivní

• nyní již na záložce Network Adapters vidíme více adaptérů

Touto jednoduchou konfigurací jsme již dosáhli redundance, kdy se použili defaultní hodnoty. Komunikace je určitým způsobem vyvažována na všechny zúčastněné NIC a v případě výpadku se přepíná. Můžeme vyzkoušet vypojit jeden síťový kabel a komunikace se po pár vteřinách přepne na druhou cestu (failover). Po zapojení se vrací zpět (failback).

Změna vlastností Teamingu

Nyní můžeme upravit některé parametry Teamingu. Nastavení můžeme upravovat globálně pro celý virtuální switch (vSwitch) nebo pro jednotlivé Port Groupy (co se zde nastaví, tak přepisuje globální nastavení). Většinou si vystačíme s konfigurací vSwitche. Nastavení provedeme následně:

• připojíme se pomocí vSphere Client na ESXi
• záložka Configuration
• menu Hardware - Networking
• vedle Virtual Switch: vSwitch0 klikneme na Properties
• vybereme vSwitch a klikneme na Edit

• přepneme se na záložku NIC Teaming

Zde nastavujeme následující parametry:

• Load Balancing - metoda, podle které dochází k vyvažování provozu na jednotlivé fyzické NIC (tedy přiřazení virtuálního Ethernet adaptéru uvnitř VM přes vSwitch na fyzický Ethernet adaptér), možnosti jsou
  • Route based on the originated virtual port ID - podle ID portu na vSwitchi kam je zapojen VM, nejjednodušší a defaultní metoda, na různých místech doporučovaná, ale u mne problematická (viz. dále), provoz z VM se posílá stále na jednu fyzickou NIC (pokud nedojde k výpadku) a odpovědi se očekávají z té samé NIC
  • Route based on source MAC hash - podle posledního bytu MAC adresy VM, provoz z VM se posílá stále na jednu fyzickou NIC (pokud nedojde k výpadku) a odpovědi se očekávají z té samé NIC
  • Route based on IP hashe - podle spojení na IP úrovni, jednoduchý hash se počítá ze zdrojové i cílové IP adresy, VM může komunikovat přes více NIC, fyzický switch pak vidí stejnou MAC na více portech, proto se doporučuje mít zapnut statický Etherchannel, IPhash metoda by měla být nastavena na celý vSwitch a zděděna na všechny Port Group
  • Use explicit failover order - zajišťuje pouze failover, NIC používá v daném pořadí a na další přehazuje pouze při výpadku
• Network Failover Detection - jakým způsobem detekuje přerušení linky
  • Link Status Only - bere pouze stav linky (můžeme využít funkci switche Link State Tracking), jedná se o jednoduchou doporučovanou metodu
  • Beacon Probing - odesílá do sítě broadcasty v každé VLAN a poslouchá, podle toho určuje funkční cesty
• Notify Switch - odešle upozornění pro switche, aby si aktualizovali tabulky, v případě kdy dojde k failover
• Failback - pokud se adaptér obnoví po chybě, tak se vrátí jeho aktivní funkce

V defaultním stavu je nastavení Teamingu pro Management Network přepsáno, i když stejnými hodnotami, jako jsou pro vSwitch. Toto nastavení můžeme zrušit.

VMware Teaming a Cisco switche

VMware ESXi nepodporuje žádné dynamické protokoly pro vyjednávání agregace linek, jako je PAgP či LACP. Pokud chceme využít oboustranný Teaming, tak musíme použít manuální (jinak řečeno statický) EtherChannel. Konfiguraci u Cisco switche provedeme jednoduše. Na vybraných portech (musí mít stejnou konfiguraci) nastavíme Etherchannel v módu on.

SWITCH(config)#int range g1/0/30,g1/0/31
SWITCH(config-if)#channel-group 1 mode on
SWITCH#show etherchannel 1 summary | begin Group
Group  Port-channel  Protocol    Ports
------+-------------+-----------+-----------------------------------------------
1      Po1(SU)          -        Gi1/0/30(P) Gi1/0/31(P)

Také na switchi se používá určitá metoda pro Load Balancing, tedy podle čeho rozhazovat komunikaci na různé porty. Defaultní nastavení je podle zdrojové MAC adresy. Můžeme nastavit podle zdrojové či cílové MAC či IP adresy nebo podle XOR operace nad zdrojovou a cílovou MAC adresou či IP adresou.

SWITCH(config)#port-channel load-balance src-dst-ip

Praxe ukazuje, že v případě, kdy použijeme Teaming na obou stranách, tak je výpadek, v případě přepnutí na druhou linku, výrazně kratší. Při jednoduchém ping testu, s nekonečným opakováním, se ztratí pouze jeden paket (v předchozím případě se jednalo o pět).

Problémy v praxi aneb různé Load Balancing metody

V praxi jsem narazil na problém, kterému jsem se nějakou dobu věnoval a nakonec našel jeho příčinu i řešení. Nejprve popíšu vlastní problém.

Pokud se použije defaultní nastavení a tedy Load Balancing metoda Route based on the originated virtual port ID, tak vše funguje dobře, pokud používáme Teaming pouze na ESXi. Ve chvíli, kdy jsem nastavil Etherchannel na switchi, tak ještě vše fungovalo (po krátkém výpadku, kdy se přestavila konfigurace). Ale pokud se přerušila komunikace na Management rozhranní asi na 10 minut, tak toto rozhranní přestalo odpovídat a nedalo se s ním spojit. Následně bylo třeba odpojit jeden síťový kabel nebo zrušit Etherchannel na switchi. Pokud jsem nechal běžet jednoduchý ping na toto rozhranní, tak vše fungovalo dobře. Stejně tak pokud se přepnula metoda Network Failover Detection na Beacon Probing. Tak vše fungovalo jak má, ale nebyl jsem spokojen s rozesíláním množství broadcastů. Po určitých pokusech se ukázalo, že když se změní Load Balancing metoda na Route based on IP hashe, tak vše chodí bez problémů.

Až dodatečně jsem našel příčinu tohoto problému a dokonce i materiál od VMwaru, kde je důvod popsaný (obdobných materiálů jsem přečetl celou řadu, ale nikde jsem na tento popis nenarazil). V dokumentu se píše, že Load Balancing metody srcPortID nebo srcMAChash se nedoporučuje používat spolu s Teamingem na fyzickém switchi. Protože očekávají, že odpovědi budou chodit přes stejnou NIC přes kterou odesílají pakety, a komunikaci na jiných NIC zahazují. Ale když použijeme Etherchannel na switchi, tak ten podle zvoleného algoritmu posílá komunikaci na určitý port (a ten může být jiný než kde mu komunikace přichází).

Také se v dokumentu uvádí, že pokud použijeme metodu IPhash, tak by se na fyzickém switchi měl zapnout Etherchannel, jinak se může stát, že se některé pakety ztratí. Lidé v různých diskuzích doporučují nepoužívat Etherchannel a mít pouze NIC Teaming podle srcPortID na ESXi, ale moje praktické výsledky jsou znatelně lepší při použití Etherchannelu a při nastavení IPhash vše funguje dobře.

MAC adresy při Teamingu

Pokud chce člověk nahlédnout do detailů fungování Teamingu, tak je určitě dobré podívat se, jaké MAC adresy komunikují na jednotlivých síťových adaptérech.

V nejjednodušším případě máme Management Network, na toto rozhranní si ESXi přiřadí MAC adresu první fyzické NIC. Komunikace pak probíhá, přes jednu NIC, pokud dojde k výpadku na této lince, tak se MAC adresa přesune na druhou NIC a komunikace pokračuje. Switch má vždy údaj, na kterém portu je tato MAC adresa, takže odpovědi posílá správně.

Když nastartujeme nějaký VM a začneme komunikovat po síti, tak se komunikace přiřadí k určité fyzické NIC (a zde se nastaví MAC adresa VM). Toto přiřazení se může v průběhu různě měnit, pokud použijeme Load Balancing metodu Route based on IP hashe. V případě výpadku se přesouvá na jinou funkční NIC. Pokud nepoužijeme Etherchannel, tak switch má MAC adresu přiřazenu vždy maximálně k jednomu portu a tam posílá komunikaci.

Na switchi se objevují MAC adresy na jednotlivých portech, kde jsou připojeny NIC. Pokud použijeme Etherchannel, tak nevidíme MAC na fyzických portech, ale pouze na virtuálním interfacu Port-channel 1 (číslo, které jsme vytvořili). Tento interface má pod sebou fyzické porty a komunikovat může přes všechny (podle nastavené metody), MAC adresy má jakoby ke všem fyzickým portům.