V terminologii počítačových sítí je vyvažování zátěže nebo vyvažování zátěže ( anglicky load balancing ) metoda distribuce úloh mezi několik síťových zařízení (například servery ) za účelem optimalizace využití zdrojů, snížení doby dotazovací služby, horizontálního škálování clusteru ( dynamické přidávání / odebírání zařízení), jakož i zajištění odolnosti proti chybám ( redundance ).
V počítačích rozložení zátěže rozděluje zátěž mezi více výpočetních zdrojů, jako jsou počítače, počítačové clustery , sítě, CPU nebo disky. Účelem vyvažování zátěže je optimalizovat využití zdrojů, maximalizovat propustnost, zlepšit dobu odezvy a zabránit přetížení jakéhokoli jednotlivého zdroje. Použití více komponent pro vyrovnávání zátěže namísto jediné komponenty může zlepšit spolehlivost a dostupnost díky redundanci . Vyvažování zátěže obvykle zahrnuje přítomnost speciálního softwaru nebo hardwaru, jako je vícevrstvý přepínač nebo systém názvů domén, jako serverový proces.
Vyrovnávání zátěže se liší od fyzického připojení v tom, že vyrovnávání zátěže rozděluje provoz mezi síťovými rozhraními na bázi síťového soketu (model OSI vrstvy 4), zatímco linkové připojení zahrnuje rozdělení provozu mezi fyzická rozhraní na nižší úrovni nebo do paketů (OSI). modelová vrstva 3) nebo přes komunikační kanál (model OSI vrstva 2).
Příklady zařízení, na která lze vyvažování použít:
Vyrovnávání zátěže lze použít k posílení serverové farmy s více než jedním serverem. Může vám také umožnit pokračovat v práci i v podmínkách, kdy selhalo několik výkonných zařízení (serverů). Díky tomu se zvyšuje odolnost proti chybám a je možné dynamicky upravovat použité výpočetní zdroje přidáváním/odebíráním výkonných zařízení v clusteru .
Jednou z nejčastěji používaných aplikací pro vyrovnávání zátěže je vytvoření jediné internetové služby s více servery , někdy známé jako serverové farmy . Mezi systémy pro vyrovnávání zatížení obvykle patří oblíbené webové stránky , velké online obchody , servery FTP ( File Transfer Protocol ), DNS ( Domain Name System ) a databáze.
Pro internet je load balancer obvykle program, který naslouchá na portu , kde se externí klienti připojují ke službám. Nástroj pro vyrovnávání zatížení předává požadavky na jeden ze „serverů“ serveru, který obvykle odpovídá nástroji pro vyrovnávání zatížení. To umožňuje nástroji pro vyrovnávání zatížení reagovat na klienta, aniž by znal vnitřní oddělení zájmů. Umožňuje také klientům přímo kontaktovat back-end servery, což může mít bezpečnostní výhody a skrýt vnitřní strukturu sítě a zabránit útokům na jádro, síťový zásobník nebo nesouvisející služby běžící na jiných portech.
Některé nástroje pro vyrovnávání zatížení poskytují mechanismus pro provedení něčeho zvláštního v případě, že je celý backend serveru nedostupný. To může zahrnovat přesměrování na záložní vyrovnávací systém nebo zobrazení chybového hlášení.
Je také důležité, aby se load balancer nestal jediným bodem selhání. Obvykle jsou nástroje pro vyrovnávání zatížení implementovány ve vysoké dostupnosti , které mohou také replikovat relace persistence, pokud to konkrétní aplikace vyžaduje. [jeden]
Alternativní metoda vyrovnávání zátěže, která nutně nevyžaduje speciální hostitelský software nebo hardware, se nazývá DNS robin round . V této technice více IP adres spojených se stejným názvem domény ; klienti si musí vybrat server, ke kterému se připojí. Na rozdíl od použití vyhrazeného nástroje pro vyrovnávání zatížení tato technika umožňuje klientům mít více serverů. Tato technika má své výhody a nevýhody v závislosti na stupni kontroly nad servery DNS a na granularitě požadované zátěže.
Další, efektivnější metodou pro vyrovnávání zátěže pomocí DNS je delegovat www.example.org jako subdoménu, pro kterou je zóna udržována každým ze stejných serverů obsluhujících web. Tato technika funguje zvláště dobře tam, kde jsou jednotlivé servery geograficky rozmístěny na internetu. Například:
one.example.org A 192.0.2.1 dva.example.org A 203.0.113.2 www.example.org NS one.example.org www.example.org NS dva.example.orgSoubor zóny pro www.example.org na každém serveru se však liší, takže každý server rozhoduje o tom, jak použít adresu IP jako záznam A. Na jednozónovém souborovém serveru pro hlášení www.example.org:
@ v 192.0.2.1Na serveru dva obsahuje stejný soubor zóny:
@v 203.0.113.2Když je tedy první server mimo provoz, jeho DNS neodpovídá a webová služba nepřijímá žádný provoz. Pokud je linka na jednom serveru přetížená, nespolehlivá služba DNS poskytuje menší provoz http k dosažení tohoto serveru. Kromě toho je nejrychlejší odpověď DNS téměř vždy vyřešena ze sítě nejbližšího serveru, a to díky geosenzitivnímu vyrovnávání zátěže. Krátký TTL na A-záznam umožňuje rychle přesměrovat provoz, pokud dojde k selhání serveru. Je třeba vzít v úvahu možnost, že tato technika může vést k tomu, že jednotliví klienti budou moci přepínat mezi samostatnými servery uprostřed relace.
Mnoho plánovacích algoritmů používají nástroje pro vyrovnávání zatížení k určení, na který server odeslat požadavek. Jednoduché algoritmy zahrnují náhodný výběr nebo kruhový výběr . Sofistikovanější nástroje pro vyrovnávání zátěže mohou vzít v úvahu další faktory, jako je to, které servery hlásily zátěž, pomalejší doby odezvy, stav nahoru/dolů (určený určitým monitorováním dotazování), počet aktivních připojení, geografickou polohu, možnosti nebo objem provozu. byl nedávno jmenován.
Důležitým problémem při spouštění služby vyrovnávání zátěže je, jak zacházet s informacemi, které je třeba uložit v rámci více požadavků v uživatelské relaci. Pokud jsou tyto informace uloženy lokálně na jediném backendovém serveru, následné požadavky přicházející z různých backendových serverů je nebudou moci najít. Může se jednat o informace uložené v mezipaměti, které lze přepočítat. V takovém případě problém s výkonem vyřeší požadavek na vyrovnávání zátěže na jiný server backend.
V ideálním případě by shluk serverů za vyrovnávačem zátěže měl být informován o relaci, takže pokud se klient kdykoli připojí k libovolnému serveru, historie komunikace uživatele s konkrétním serverem je irelevantní. Toho je obvykle dosaženo pomocí sdílené databáze nebo relace databáze v paměti, jako je memcached .
Jedním ze základních řešení problému s daty relace je poslat všechny požadavky v relaci uživatele postupně na stejný server. Tomu se říká vytrvalost nebo lepivost . Významnou nevýhodou této technologie je absence automatického převzetí služeb při selhání : pokud server selže, informace o jeho relaci se stanou nedostupnými, všechny relace jsou ztraceny. Stejný problém se obvykle týká centrální databáze serveru; i když jsou webové servery „bezstavové“ (bezstavové) a nikoli „lepivé“ (sticky), centrální databáze (viz níže).
Přiřazení ke konkrétnímu serveru může být založeno na uživatelském jménu, IP adrese klienta nebo může být náhodné. Vzhledem ke změnám vnímané adresy klienta v důsledku DHCP , Network Address Translation a Web Proxy může být tato metoda nespolehlivá. Náhodné úlohy si musí pamatovat nástroj pro vyrovnávání zatížení, který zatěžuje úložiště. Pokud dojde k výměně nebo výpadku nástroje pro vyrovnávání zatížení, mohou se tyto informace ztratit a úlohy může být nutné odstranit po určité době nebo během období vysokého zatížení, aby nedošlo k překročení místa dostupného pro tabulku přiřazení. Metoda náhodného přiřazení také vyžaduje, aby klienti podporovali některá nastavení, což může být problém, například když webový prohlížeč zakázal ukládání souborů cookie. Komplexní nástroje pro vyrovnávání zátěže používají několik perzistenčních metod, aby se vyhnuly některým nevýhodám kterékoli metody.
Dalším řešením je ukládání dat relace do databáze . Obecně je to špatné pro výkon, protože to zvyšuje zatížení databáze: databáze se lépe používá k ukládání informací, které jsou méně nestálé než data relace. Aby se zabránilo tomu, že se databáze stane jediným bodem selhání, a aby se zlepšila škálovatelnost , jsou databáze často replikovány na více počítačích a k distribuci indexu zatížení mezi tyto repliky se používá vyrovnávání zatížení. Technologie Microsoft ASP.net State Server je příkladem relace databáze. Všechny servery ve webové farmě ukládají data relace na server Master State Server a data může načíst jakýkoli server ve farmě.
Ve velmi běžných případech, kdy je klientem webový prohlížeč, je jednoduchým, ale účinným přístupem ukládání dat relace do samotného prohlížeče. Jedním ze způsobů, jak toho dosáhnout, je používat soubory cookie prohlížeče , šifrovaná časová razítka. Dalším způsobem je přepisování URL. Ukládání dat relace na klientovi je obvykle preferovaným řešením: nástroj pro vyrovnávání zátěže si pak může zvolit libovolný server pro zpracování požadavku. Tento způsob zpracování stavových dat však není vhodný pro některé scénáře složité obchodní logiky, kde je stav relace velkou užitečnou zátěží a není možné jej znovu načíst s každým požadavkem na server. Přepisování adres URL má vážné bezpečnostní problémy, protože koncový uživatel může snadno změnit odeslané adresy URL, a tak změnit toky relací.
Dalším řešením pro ukládání trvalých dat je přidružit název ke každému bloku dat, použít distribuovanou hashovací tabulku k pseudonáhodnému přiřazení názvu k jednomu z dostupných serverů a pak uložit tento blok dat na určený server.
Hardwarové a softwarové vyvažovače zátěže mohou mít různé speciální vlastnosti. Hlavním rysem nástroje pro vyrovnávání zatížení je schopnost distribuovat příchozí požadavky na více serverů v clusteru podle plánovacího algoritmu. Většina vlastností specifických pro dodavatele uvedených níže:
Vyvažování zátěže může být užitečné v aplikacích s redundantním propojením. Společnost může mít například několik připojení k internetu, které poskytují přístup k síti, pokud je jedno z připojení mimo provoz. V systémech zabezpečených proti selhání by to znamenalo, že jeden odkaz je pro normální použití a druhý se používá pouze v případě, že hlavní odkaz selže.
Pomocí vyvažování zátěže mohou být obě linky neustále zaneprázdněny. Zařízení nebo program řídí přítomnost všech odkazů a volí cestu pro odesílání paketů. Použití více odkazů současně zvyšuje dostupnou šířku pásma.
Standard IEEE schválil standard IEEE 802.1 rr v květnu 2012 [2], který je také známý a zdokumentovaný ve většině knih jako nejkratší cesta (SCP). KPC umožňuje všem propojením, aby byly aktivní napříč více cestami stejné důležitosti, poskytuje rychlejší konvergenci snižující prostoje a usnadňuje použití vyvažování zátěže v mesh síti (částečně a/nebo plně propojené), což umožňuje provozu vyvažovat zátěž napříč všemi síťovými cestami. . [3] [4] PPC je navržen tak, aby prakticky eliminoval lidskou chybu během procesu nastavení a zachovává plug-and-play povahu plug-and-play, která vytváří Ethernet jako de facto protokol ve druhé vrstvě. [5]
Mnoho telekomunikačních společností má několik cest přes své sítě nebo do externích sítí. Používají komplexní zátěže ke změně provozu z jedné cesty na druhou, aby se vyhnuli zahlcení sítě na kterémkoli konkrétním spoji a někdy aby minimalizovali náklady na tranzit přes externí sítě nebo zlepšili spolehlivost sítě.
Dalším způsobem, jak využít vyrovnávání zatížení sítě, je sledování aktivity. Nástroj pro vyrovnávání zátěže lze použít k rozdělení velkých datových toků do více dílčích toků a použití více síťových analyzátorů, z nichž každý čte část původních dat. To je velmi užitečné pro monitorování rychlých sítí, jako jsou porty 10gbe nebo STM64, kde složité zpracování dat nemusí být možné při rychlosti drátu.
Vyvažování zátěže se často používá k implementaci odolnosti proti chybám – pokračování služby po selhání jedné nebo více jejích součástí. Komponenty jsou neustále monitorovány (například webové servery mohou být řízeny vzorkováním známých stránek), a když některá přestane reagovat, je o tom informován nástroj pro vyrovnávání zátěže a již na server neposílá provoz. Když se komponenta vrátí do režimu online, nástroj pro vyrovnávání zatížení do ní znovu začne směrovat provoz. Aby to fungovalo, musí existovat alespoň jedna komponenta přesahující kapacitu služby (N+1 rezervace). To je mnohem levnější a flexibilnější než přístupy s převzetím služeb při selhání, ve kterých je každá živá komponenta spárována se zálohou jedné komponenty, která převezme řízení v případě poruchy (duální modulární redundance). Některé typy systémů RAID lze také použít jako horké náhradní díly pro podobný efekt.