Tento článek jsem napsal pro časopis Connect a vyšel v čísle Connect 12/09, zde jej publikuji s laskavým svolením redakce.
Jedná se o shrnutí údajů, které jsem popsal v článcích dříve zveřejněných na tomto webu.
Link Aggregation, EtherChannel a NIC Teaming
Na trhu jsou sice zařízení s rychlostí 10Gbps, ale jejich cena je výrazně vyšší. Proto se dnes hojně využívá technologie agregace linek, která je stará více než 20 let. Její nemalou výhodou je i zajištění redundance linky a tedy zvýšení dostupnosti.
Agregace linek znamená spojení více fyzických Ethernetových síťových linek do jedné virtuální (logické) linky, abychom dosáhli větší rychlosti a redundance pro failover. Jako síťovou linku budeme označovat síťový kabel, který je zapojen na obou stranách do portu switche nebo portu síťového adaptéru serveru. V praxi se může jednat o propojení dvou switchů nebo připojení serveru do switche.
Můžeme se setkat s celou řadou termínů, které více méně označují to samé. Hlavní termíny jsou Link Aggregation, EtherChannel a NIC Teaming, ty budeme používat dále v článku. I když je jejich výsledek shodný, tak se používají na různých místech. Další termíny, s kterými se můžeme potkat, jsou Link Bundling, NIC bonding, Port Trunking, Port Teaming apod.
Slovníček VM - Virtual Machine je virtuální počítač, který běží uvnitř ESXi serveru. NIC - Network Interface Controller je označení pro síťovou kartu č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), dále může být propojen přes fyzický adaptér do sítě. Failover označuje schopnost automaticky se přepnout na redundantní nebo záložní linku v případě výpadku aktivní linky. Failback je proces, který zajistí návrat do původního stavu před failover, pokud se odstraní závada.
Cisco EtherChannel
Termín EtherChannel pochází od firmy Cisco (technologii získala akvizicí společnosti Kalpana) a je v současnosti značně rozšířený. Používá se převážně u Cisco switchů a jeho původní význam byl pro propojení dvou switchů spolehlivěji a větší rychlostí než poskytuje jedna linka. Stále je relativně běžná situace, že switch je vybaven porty stejné rychlosti (nyní nejčastěji 1Gbps, dříve 100Mbps), takže jeho připojení do páteře může být úzkým hrdlem.
Technologie EtherChannel se značně rozšířila, protože řeší nejen problém s datovou propustností do páteře sítě, ale také obchází nejčastější poruchy na trase port-kabel-port. EtherChannel můžeme vyrobit z dvou až osmi fyzických interfaců, které musí mít stejný typ a rychlost, být full duplex a zařazeny do stejné VLANy nebo stejného typu trunku. Na jednom switchi/stacku můžeme vytvořit až 48 EtherChannelů. Všechny interfacy, které mají být členem EtherChannelu, musí být na stejném switchi nebo stacku. EtherChannel nelze vytvořit mezi porty na různých switchích.
Vytvořením EtherChannelu vznikne virtuální interface, který se označuje jako Port-channel a číslo. Tento interface má konfiguraci společnou pro všechny fyzické porty a veškeré konfigurační zásahy bychom měli provádět na něm. Sdílí MAC adresy z fyzických portů a všechny technologie (jako Spanning Tree Protocol) pracují s tímto virtuálním portem místo fyzických.
Vlastní komunikace probíhá tak, že při odesílání dat přes EtherChannel se podle zvoleného algoritmu určí, přes který fyzický interface mají odejít. Vyvažování zátěže záleží na zvoleném algoritmu. Pokud dojde k přerušení linky, tak se komunikace automaticky přesune na funkční fyzický interface.
Samozřejmě není povinné, aby se na druhé straně nacházel switch. Velice často dnes použijeme tuto technologii, kdy na druhé straně je server a nakonfigurovaný NIC Teaming. Důležité je, aby připojené zařízení akceptovat komunikaci, která může přicházet přes více fyzických portů.
V konfiguraci EtherChannelu můžeme určit, podle čeho se má provádět přiřazování k fyzickému interfacu. Vždy se z dané hodnoty počítá hash, jehož výsledkem je hodnota 0 až 7 a ta určuje použitý port. Defaultní metoda pro Load Balancing je podle zdrojové MAC adresy, nastavit můžeme zdrojovou či cílovou MAC či IP adresu nebo podle XOR operace nad zdrojovou a cílovou MAC adresou či IP adresou. Jedna session by vždy měla posílat data přes stejný interface, aby nedošlo k doručení mimo pořadí.
EtherChannel je vlastní technologie, která zajišťuje spojení linek a komunikaci přes ně. Jako doplněk existuje protokol Port Aggregation Protocol (PAgP), který slouží k dynamickému vyjednání agregace linek. PAgP může pracovat buď v aktivním módu, kdy se aktivně snaží vyjednat ustanovení EtherChannelu, ten se označuje jako desirable. Nebo v pasivním módu, kdy se EtherChannel začne vyjednávat, pouze když přijde požadavek z druhé strany (sám nikdy nezačne vyjednávání), to je mód auto.
IEEE 802.1ax Link Aggregation
Na základě EtherChannelu vznikl v roce 2000 standard IEEE 802.1ad, který se později oddělil do samostatného standardu IEEE 802.1ax nazvaný Link Aggregation. Tento standard také popisuje protokol Link Aggregation Control Protocol (LACP), který je obdobou PAgP a slouží k dynamickému vyjednávání skupin. Tyto skupiny se zde označují jako Link Aggregation Group (LAG).
Většina vlastností Link Aggregation je shodná jako EtherChannel. Dnešní Cisco switche podporují obě tyto technologie. Drobné rozdíly jsou například v názvosloví. LACP pracuje v módech active, tehdy sám odesílá pakety pro vyjednání spojení, a passive, kdy čeká na začátek vyjednávání. Link Aggregation dovoluje vytvořit LAG až z osmi aktivních interfaců a k nim dovoluje přidat až 8 pasivních, které se přepnou v případě výpadku.
Rozdíl mezi LACP/PAgP a manuálním EtherChannelem
Ať použijeme nějaký dynamický protokol pro vyjednání agregace linek nebo agregaci nastavíme staticky, tak jsou hlavní vlastnosti stejné a práce s konfigurací také. V obou případech musíme provést konfiguraci na obou stranách a na všech portech. Když dojde k výpadku nějaké linky, tak se komunikace automaticky přesměruje na ostatní, a pokud se obnoví, tak se zas začne používat.
Takže v čem je rozdíl? V řadě praktických situací můžeme provést manuální konfiguraci. Použití protokolu přidává jednu vlastnost. Mezi přímo připojenými zařízeními (přesněji jejich porty) se odesílají rámce (LACPDU) a podle nich se zjišťuje, jestli je linka dostupná (bez protokolu se bere pouze stav linky). Také se pomocí těchto rámců ověří, že je druhá strana správně konfigurovaná.
Konfigurace v Cisco IOSu
Následující příkazy ukazují jednoduchost základní konfigurace EtherChannelu. Vytváříme skupinu pouze ze dvou portů a volíme statický EtherChannel, kdy se nepoužije ani PAgP ani LACP. Dalším krokem měníme Load Balancing algoritmus, který se nastavuje pro celý stack. Ještě následuje příkaz pro zobrazení informací o EtherChannelu, tedy jeho kontrola. A na závěr jeho zrušení (fyzické porty se v té chvíli přepnou do stavu shutdown).
SWITCH(config)#interface range g1/0/7,g1/0/8 SWITCH(config-if-range)#channel-group 1 mode on Creating a port-channel interface Port-channel 1 SWITCH(config)#port-channel load-balance src-dst-ip SWITCH#show etherchannel 1 summary | begin Group Group Port-channel Protocol Ports ------+-------------+-----------+----------------------- 1 Po1(SD) - Gi1/0/7(s) Gi3/0/6(s) SWITCH(config)#no interface port-channel 1
NIC Teaming ve světě Windows
Nyní se podíváme, na již zmiňovanou možnost, připojit pomocí agregace linek nějaký server. Často se v případě serveru používá termín NIC Teaming (případně pouze Teaming) a říkáme, že pomocí agregace spojíme dva či více síťových adaptérů do logického týmu (případně bundlu). Abychom mluvili konkrétněji, tak budeme uvažovat OS MS Windows, i když v dalších OS je situace podobná. A určitá specifika budou popsána na síťové kartě firmy Intel.
Když provádíme Teaming, tak spojujeme několik fyzických linek do jedné logické. Je to vlastně opak toho, když využijeme VLANy, tehdy přes jednu fyzickou linku přenášíme více sítí, tedy ji rozdělujeme na více logických linek. Obě technologie můžeme použít i dohromady, spojit adaptéry do týmu a přes něj přenášet více VLAN.
Ve světě Windows máme jeden problém, a sice že v jádru chybí podpora pro technologie jako je Teaming a VLANy. Potřebujeme tedy speciální ovladač pro síťový adaptér od jeho výrobce. Výrobci serverů většinou takový ovladač mají (i když ne vždy u nejlevnějších modelů), příkladem je firma HP, kde můžeme nainstalovat aplikaci HP Network Config Utility, přes kterou se konfigurace provádí. Z výrobců síťových karet má asi největší podporu firma Intel, jejichž většina síťových adaptérů, včetně řady integrovaných, Teaming podporuje. U Intelu se konfigurace provádí přímo na záložce ve vlastnostech síťového adaptéru.
Různé typy Teamingu ve Windows
NIC Teaming má jednu rozdílnou vlastnost oproti Link Aggregation, kterou můžeme v určitých situacích považovat za velkou výhodu. Dovoluje jej totiž provozovat ve dvou hlavních typech. Poprvé konfigurujeme obě strany, tedy na serveru Teaming a na switchi EtherChannel. Tehdy musí být splněny podmínky uvedené v popisu EtherChannelu. U NIC Teamingu můžeme zvolit metodu Static Link Aggregation, kdy na switchi nastavíme manuální EtherChannel. Nebo Dynamic Link Aggregation, který využívá protokol LACP podle IEEE 802.3ad.
Druhou možností je nastavit pouze jednu stranu a to Teaming na serveru. Tehdy můžeme použít libovolný switch (bez managementu a podpory Link Aggregation), dokonce mohou být členové jednoho týmu připojeni k různým switchům, čímž se výrazně zvedá dostupnost (řešíme i situaci, kdy vypadne celý switch). Jednotlivé linky mohou mít i jinou rychlost a vlastnosti. Důležité je, aby konfigurace všech portů byla shodná, to znamená zařazení do stejné VLANy případně trunku apod. Samozřejmě komunikace je vyvažována pouze v odchozím směru, ale výpadek se vyřeší oboustranně.
Opět máme několik různých typů, které můžeme na serveru nastavit. Adaptive Load Balancing vyvažuje provoz přes všechny adaptéry. Adapter Fault Tolerance používá pouze jednu linku jako aktivní a ostatní jsou záložní pro případ výpadku. Switch Fault Tolerance připojení ke dvěma různým switchům.
NIC Teaming a VMware ESXi
Od připojení serveru přes agregované linky se posuneme malý krůček dopředu. V dnešní době je virtualizace tématem dne, a dle mého názoru oprávněně. Když konsolidujeme více serverů na jeden fyzický hardware, protože výkon procesoru, množství paměti a další parametry jsou naprosto dostačující, tak můžeme narazit na problém síťového připojení. Buď nám nedostačuje rychlost linky, nebo riziko výpadku jediné linky, přes kterou komunikuje větší množství serverů, je příliš velké. Naprosto vhodným řešením této situace je použití NIC Teamingu.
Abychom opět hovořili konkrétně, tak se náš popis bude týkat mého oblíbeného nástroje VMware ESXi 4.0, který je poskytován zdarma.
Když použijeme Teaming, tak nejen že získáme zvýšení datové propustnosti díky vyvažování komunikace jednotlivých VM přes různé fyzické NIC. Zvýšení dostupnosti, kdy při výpadku jedné linky dojde k automatickému přesunu komunikace na jinou funkční. Ale také výrazné zvýšení rychlosti při operacích, kdy na ESXi server nahráváme data, třeba při převodu fyzického stroje na virtuální pomocí VMware vCenter Converter.
Možnosti Teamingu u ESXi
Podobně jako ve Windows můžeme konfigurovat Teaming pouze na ESXi nebo oboustranně i na switchi. Praxe ukazuje, že při použití oboustranné konfigurace je přepnutí v případě výpadku podstatně rychlejší.
U ESXi máme více možností konfigurace parametrů pro Teaming. Hlavní parametr je metoda pro Load Balancing, tedy podle čeho se bude komunikace rozhazovat na fyzické NIC. Můžeme zvolit podle zdrojového ID portu, tedy port vSwitche kam je připojen VM (to je defaultní nastavení), podle zdrojové MAC adresy. V těchto případech komunikuje VM (přesněji jeho virtuální NIC) vždy přes stejnou fyzickou NIC.
Další možnost je nepoužívat vyvažování, ale pouze failover. A poslední možnost je podle IP hashe, tehdy se počítá hash ze zdrojové a cílové IP adresy pro každou session a podle tohoto hashe se přiřazuje na fyzickou NIC. V tomto případě může jít různá komunikace jedné VM přes různé fyzické NIC. Je to také jediná metoda, kdy na switchi můžeme nastavit agregaci a musí se jednat o statický EtherChannel. Ten by se v tomto případě měl použít, protože stejná MAC adresa se může objevit na více portech switche. Také by tato konfigurace měla být provedena na celý vSwitch.
Dalším zajímavým parametrem je Network Failover Detection, tedy jakým způsobem se zjistí přerušení linky. Můžeme zvolit Link Status Only, rozhoduje pouze podle stavu linky, nebo Beacon Probing, který vysílá a poslouchá broadcasty.
Konfigurace Teamingu na ESXi
Teaming se na ESXi nastaví velice jednoduše. Stačí přidat další síťový adaptér a defaultně se použije NIC Teaming s vyvažováním podle zdrojového ID portu, s failover detekcí podle stavu linky a s failback funkcí. Celou konfiguraci můžeme provést přes vSphere Client.
Konfiguraci Teamingu můžeme provádět buď globálně pro celý virtuální switch (vSwitch), což je většinou doporučeno. Nebo hodnoty přepsat pro určité Port Group.
mozem poprosit o mensie vysvetlenie spoluprace teamingu na serveroch a nastavenia potov na switchoch.
V etherchanneli mozu byt len trunk porty?
v clanku http://www.samuraj-cz.com/clanek/windows-a-nic-teaming-aneb-pripojeni-pres-vice-sitovek/ sa pise, ze najprv porty nastavime ako access do vlan 100 a potom ich hodime do etherchannela.
Ako to teda je? Zrejme sa mylim, ze v etherchanneli mozu byt len trunky. Dakujem
odpověď na [1]joe07: Do EtherChannelu můžeme nastavit jak access port, tak trunk port. Důležité je pouze to, aby měli všechny porty v teamu stejnou konfiguraci.
Možná vás plete to, že některé firmy označují NIC Teaming jako NIC Trunking.
odpověď na [1]joe07:
pekny dokument, ktery to popisuje http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/vmware/VMware.pdf
vice k virtualizaci na www.windowsportal.cz
lze nastavit, ze napriklad Gi0/1 ma max propustnost 800Mbps a Gi0/2 500Mbps? A switch podle toho delal loadbalancing? Na portech jsou pripojeny 2 bezdratovy spoje, ktery je potreba spojit dohromady.
Dobrý den, moc rád bych na Vás prosím vznesl dotaz, z oficiální dokumentace k lagu jsem se dočetl, že se používají dva typy port-channel load-balance a to: a)src-dst-mac b)src-dest-mac-ip.
Moc rád bych se Vás zeptal, kdy použiji jakou metodu, a jaký je vlastně rozdíl..?
Děkuji.
odpověď na [5]Petr: Nevím, jestli tam nemáte chybu (src-dest-mac-ip by mělo být src-dst-ip). Každopádně jde o to, podle čeho se rozhazuje komunikace na jednotlivé porty. Cisco podporuje zdrojovou IP nebo MAC, cílovou IP nebo MAC, zdrojovou i cílovou IP nebo MAC. Výchozí nastavení je src-mac.