www.SAMURAJ-cz.com 

14.12.2017 Lýdie Translate to English by Google     VÍTEJTE V MÉM SVĚTĚ

Články

VMware ESXi a NIC Teaming aneb připojení přes více síťovek

Sobota, 10.10.2009 18:56 | Samuraj - Petr Bouška |
Další článek, který se věnuje oblasti NIC Teamingu a Link Aggregation. Když provedeme konsolidaci více serverů na jeden fyzický HW (protože výkon procesoru, paměti a dalších komponent je naprosto dostačující), tak je velice vhodné zvýšit bezpečnost a propustnost síťového připojení pomocí zapojení přes více síťových rozhranní. Za nejlepší vizualizační platformu dnes považuji VMware ESX, kde verze ESXi je dokonce zdarma, takže se věnuji jí.

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
ESXi - vSphere Client konfigurace sítě
  • vedle Virtual Switch: vSwitch0 klikneme na Properties
  • záložka Network Adapters - klikneme na Add
  • zatrhneme adaptéry, které chceme přidat
ESXi - přidání síťového adaptéru
  • necháme adaptéry jako aktivní
ESXi - pořadí pro failover
  • nyní již na záložce Network Adapters vidíme více adaptérů
ESXi - vlastnosti síťových 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).

ESXi - vSwitch s dvěma NIC

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
ESXi - konfigurace vSwitch
  • přepneme se na záložku NIC Teaming
ESXi - NIC Teaming pro vSwitch

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.

ESXi - Management Network Teaming

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.

zobrazeno: 17048krát | Komentáře [14]

Autor:

Související články:

Link Aggregation

Připojení přes více linek. EtherChannel, Link Aggregation, PAgP, LACP, NIC Teaming, Bonding, Bundling ...

Virtualizace

Články z populárních témat o virtualizace serverů a stanic.

Pokud se Vám článek líbil, tak mne potěšíte, když uložíte odkaz na některý server:

Pokud se chcete vyjádřit k tomuto článku, využijte komentáře níže. Pokud chcete poradit s nějakým problémem či diskutovat na nějaké téma, tak použijte fórum.

Komentáře

  1. [1] Wiper2

    Sohlas...s ethernetchannel a IPhash...to funguje pekne..u hp terminologie s trunk-em. Myslim, ze to chodilo i s LACP. Co se tyka sitove komunikace tak kluci u vmwaru v nove verzi esx4 udelali fakt pokrok. Distributed switch me osobne se hodne libi..i možnost použít virtualni switche cisco nexus v HA...jen je k tomu zapotrebi az nejvyssi licence enterprise plus nebo 60den eval. aby si to clovek vyzkousel a s nasazenim ESX + BLADE je to sexy :)

    Neděle, 11.10.2009 11:04 | odpovědět
  2. [2] Karel

    odpověď na [1]Wiper2: No jo, s nasazenim na ESX + Blade je to sexy, az na drobnost, ze v blade enclosure mas kazdou sitovku vedenou do jinyho switche (mame cbs3020), ktery spolu nejsou spojeny. Leda rozchodit nejak stackwise i pro ne. Dalsi vec, ktera me napada je, ze pres jednu sitovku chodi provoz z virtualnich masin a druha je vyhrazena pro VMotion, ale to by asi nemuselo vadit.

    Samuraji, uz jsi zkousel spojit vic switchu do stacku, aniz by to byly 3750ky? Se mi to zatim nepovedlo.

    Úterý, 22.12.2009 14:25 | odpovědět
  3. [3] Samuraj

    odpověď na [2]Karel: Ano, nechápu proč ty switche v bladech nejsou řešený jako stack, přitom se jedná o speciální modely a na sběrnici jsou spolu propojeny několika porty. Takhle se Etherchannel dá rozchodit jen ze strany ESX ...

    Neslyšel jsem, že by šlo rozchodit stack třeba přes normální ethernet porty (ale je to škoda).

    Úterý, 22.12.2009 14:38 | odpovědět
  4. [4] diatonix

    Dobrý den,

    mám prosbu, lze nastavit na VMWARE ESXi SERVERU dva síťové rozsahy. Jde o to, že mám síť rozdělenou na VLAN1 a VLAN2. Na serveru mám dvě síťové karty do každé z nich vede jedna VLANa. Část virtualních mašin potřebuji mít v 1. a část v 2. VLAN rozsahu. Lze to nějakým způsobem uskutečnit.

    Úterý, 09.02.2010 11:43 | odpovědět
  5. [5] Samuraj

    odpověď na [4]diatonix: Jde to velice jednoduše pomocí VLAN na straně ESXi. Já to používám tak, že do serveru vede trunk s více VLANami a s těmi již ESXi normálně pracuje (virtuálu se přiřadí daná VLAN).

    Více třeba v www.vmware.com/files/pdf/virtual_networking_concepts.pdf nebo www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/vmware/VMware.pdf.

    Středa, 10.02.2010 17:52 | odpovědět
  6. [6] Diatonix

    Díky za radu.

    Mám ještě jeden problém. Podporuje ESXi server xaxmodemové karty, potřeboval bych instalovat faxserver. Bohužel jsem se nikde nedočetl jestli s tím má někdo nějaké zkušenosti. Dík :-(

    Pondělí, 01.03.2010 14:57 | odpovědět
  7. [7] pam

    Dobrý den

    Smazal sem si v configuration - networking původní vSwitch0 a nedošlo mi, že přes něj se k vSphare Serveru připojuju :-(. Takže teď mi z počítače s vSphare Clientem nejde adresa, na kterou jsem se připojoval, ani pingnout. Nevíte prosím jak se to dá opravit?

    Úterý, 09.03.2010 13:13 | odpovědět
  8. [8] Karel

    odpověď na [7]pam: Pripoj se na server pres iLO, pokud mas moznost, a pust si Remote Console - tam mas nastaveni sitovek. Taky jsem se jednou behem pokusu s etherchannelem odriznul... nastesti od testovaciho stroje.

    Úterý, 09.03.2010 20:33 | odpovědět
  9. [9] s_rybka

    Lze nastavit na VMWARE ESXi 4, že danému virtuálu přiřadím jednu jistou fyzickou síťovou kartu? Dále potřebuji aby tento virtuál komunikoval i s ostatními virtuály. Jedná se o hodně síťově náročný stroj. Tak hledám řešení.

    Předem díky.

    Středa, 18.08.2010 10:37 | odpovědět
  10. [10] Michal

    Ahoj,

    řešíme také, dokoupil jsem další Pass throug Lan modul do blade BLC3000.

    Podle infa z vmware, Management network slouží pro Vmotion a služby iSCSI, NFS... pro spojení s úložišti. Vyhradil jsem 2x lan pouze pro management rozhraní a 2 lan pro Vmnetwork k VM.

    Ale netuším zde píši pravdu.

    Pokud ne děkuji za opravu.

    Čtvrtek, 16.06.2011 07:06 | odpovědět
  11. [11] PetrB

    odpověď na [9]s_rybka: Lze nastavit na VMWARE ESXi 4, že danému virtuálu přiřadím jednu jistou fyzickou síťovou kartu? Dále potřebuji aby tento virtuál komunikoval i s ostatními virtuály. Jedná se o hodně síťově náročný stroj. Tak hledám řešení.

    ve virtualnim switchi se udela dalsi port group a v teto lze nastavit ze pouziva konkretni vnic sitovou kartu ze switche

    pro cely switch tato karta pak muze byt jako zaloha

    Úterý, 03.01.2012 08:49 | odpovědět
  12. [12] Samuraj

    Od vSphere 5.1 VMware podporuje Link Aggregation Control Protocol (LACP), ale pouze na vSphere Distributed Switch (VDS).

    kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2034277

    Úterý, 08.04.2014 11:53 | odpovědět
  13. [13] Choze

    Zdravim , je potreba provest nastaveni na cisco switchi ? nebo staci pouze ve vmware.

    Mam jednoduchy switch cisco SG200-26 s web interface.

    Ve vmware bych postupu rozumnel ,ale s cisco nemam velkou zkusenost.

    Diky

    PS: Pripadne jak overim ze mi to funguje spravne ?

    Úterý, 06.01.2015 21:14 | odpovědět
  14. [14] Samuraj

    odpověď na [13]Choze: Stačí si projít tuhle moji sérii článků a vše je tam vysvětleno!

    Pokud mi stačí jednostranné rozkládání zátěže a zajištění vysoké dostupnosti, tak mohu nastavit pouze na VMware.

    Středa, 07.01.2015 08:34 | odpovědět
Přidat komentář

Vložit tag: strong em link

Vložit smajlík: :-) ;-) :-( :-O


Ochrana proti SPAMu, zdejte následující čtyři znaky image code

Nápověda:
  • maximální délka komentáře je 2000 znaků
  • HTML tagy nejsou povoleny (budou odstraněny), použít se mohou pouze speciální tagy (jsou uvedeny nad vstupním polem)
  • nový řádek (ENTER) ukončí odstavec a začne nový
  • pokud odpovídáte na jiný komentář, vložte na začátek odstavce (řádku) číslo komentáře v hranatých závorkách