Úvod
High Availability Proxy (HAProxy), je populární open-source proxy a TCP/HTTP nástroj pro vyvažování zátěže schopný běžet na Solaris, FreeBSD, a Linux. Nejčastěji se používá ke zvýšení spolehlivosti a výkonu serverového prostředí tím, že zajišťuje vyvážené rozdělení pracovní zátěže mezi více serverů. Tento typ nástroje se používá v mnoha významných prostředích, jako jsou Instagram, GitHub, Twitter a Imgur.
Tato příručka vás seznámí s HAProxy, obeznámí vás s terminologií vyvažování zátěže a poskytne příklady, jak jej lze využít k posílení výkonu i spolehlivosti serverových prostředí.
Základní pojmy HAProxy
Předtím, než se pustíme do podrobností o vyvažování zátěže a proxyování, je třeba se seznámit s některými důležitými pojmy a koncepty. Začneme tím, že si tyto koncepty projdeme v následujících částech.
ACL (Access Control List)
Pokud jde o vyvažování zátěže, ACL se využívají k testování konkrétní podmínky a provedení akce na základě výsledku. To umožňuje optimálně přesměrovávat provoz na základě faktorů, jako jsou připojení k backendu, porovnávání vzorů a mnoho dalších. Zde je příklad použití ACL:
|
1 |
acl url_blog path_beg /blog |
V tomto případě se ACL shoduje, pokud požadovaná cesta uživatele začíná na /blog. Tento odpovídající požadavek by například ukazoval na http://yourdomain.com/blog/blog-entry-1. Konfigurační příručka HAProxy obsahuje podrobný návod k použití ACL.
Backend
Přesměrované požadavky přijímá skupina serverů označovaná jako backend. Požadavky jsou definovány v sekci backend v konfiguraci HAProxy. V nejjednodušším vyjádření lze backend definovat podle toho, jaké algoritmy pro vyvažování zátěže se mají použít, a seznamem portů a serverů. Backend se může skládat z jednoho serveru nebo z více serverů. S přidáváním dalších serverů do backendu se zvyšuje potenciální kapacita zátěže, přičemž zpracování se rozděluje mezi více serverů. Pokud některé servery v backendu přejdou do režimu offline, ostatní budou sloužit jako záloha pro zpracování požadavků.
Podívejme se na příklad konfigurace dvou backendů. V tomto případě se jedná o blog-backend a web-backend. Každý z nich má dva webové servery naslouchající na portu 80:
|
1 2 3 4 5 6 7 8 9 10 |
backend web-backend balance roundrobin server web1 web1.yourdomain.com:80 check server web2 web2.yourdomain.com:80 check backend blog-backend balance roundrobin node http server blog1 blog1.yourdomain.com:80 check server blog2 blog2.yourdomain.com:80 check |
Řádek balance roundrobin slouží k určení algoritmu vyvažování zátěže. Podrobnosti naleznete v nadcházející části Algoritmy pro vyvažování zátěže, zatímco mode http nastavuje použití proxy na 7. vrstvě. To si vysvětlíme v části Typy vyvažování zátěže. Volba check za definicí serverů navíc značí, že na těchto konkrétních backendových serverech budou spouštěny kontroly stavu (health checks).
Frontend
Definice toho, jak jsou požadavky přesměrovávány na backend, se označuje jako frontend. Požadavky jsou definovány v sekci frontend v konfiguraci HAProxy. Skládají se z ACL, portu, sady IP adres a pravidla definujícího, které backendy se mají použít v závislosti na splnění podmínek ACL, nazývaného pravidlo use_backend. Kromě toho existuje také pravidlo default_backend pro jakýkoli jiný případ. V další části bude vysvětleno, jak lze frontend nakonfigurovat pro různé typy síťového provozu.
Typy vyvažování zátěže
Po definování základních komponent používaných pro vyvažování zátěže se nyní můžeme přesunout k základním typům vyvažování zátěže.
Bez vyvažování zátěže
V té nejjednodušší formě lze absenci vyvažování zátěže znázornit následovně:
V tomto scénáři se uživatel připojuje přímo k webovému serveru na adrese yourdomain.com. Není zde žádné vyvažování zátěže. Vzhledem k tomu, že existuje pouze jeden databázový server, pokud přejde do režimu offline, přístup k informacím na něm je nyní zcela přerušen. Pokud se mnoho uživatelů pokouší připojit k jednomu webovému serveru současně a ten není schopen zvládnout zátěž, kterou to vyvolává, všechna připojení se zpomalí nebo se nepodaří připojit vůbec.
Vyvažování zátěže (4. vrstva)
Jedním z nejjednodušších a nejpragmatičtějších způsobů vyvažování síťového provozu na více serverů je použití metod vyvažování na transportní vrstvě neboli 4. vrstvě. Tento způsob vyvažování zátěže směruje každého připojujícího se uživatele na základě rozsahu IP adres, do kterého spadá jeho IP adresa, a portu. Jinými slovy, pokud http://yourdomain.com/anything je místo, odkud požadavek přichází, backend, který je definován pro zpracování těchto požadavků, bude tím, kdo je nakonec zpracuje. Přesměruje tyto požadavky pro yourdomain.com na portu 80.
Základní uspořádání vyvažování zátěže na 4. vrstvě vypadá takto:
Jakmile uživatel získá přístup k nástroji pro vyvažování zátěže, jeho požadavky jsou přesměrovány na skupinu serverů web-backend. Nakonfigurovaný backendový server přímo odpoví na požadavek uživatele. Aby se zabránilo tomu, že se uživatel setká s nekonzistentními daty, měly by všechny servery web-backend poskytovat identický obsah. Podle výše uvedeného diagramu se oba webové servery nakonec připojují ke stejnému databázovému serveru.
Vyvažování zátěže (7. vrstva)
Existuje další, složitější metoda vyvažování síťového provozu. Tou je použití vyvažování zátěže na 7. úrovni neboli aplikační vrstvě. Tento přístup umožňuje přesměrovat požadavky uživatelů na různé backendové servery v závislosti na obsahu požadavků uživatelů. Tato metoda umožňuje vyvažování zátěže napříč více servery webových aplikací prostřednictvím stejného portu a domény. Podrobnější informace o této vrstvě naleznete v podsekci HTTP v našem Podstata síťování: Seznamte se s terminologií, rozhraními a protokoly tutoriálu.
Následující diagram znázorňuje vyvažování zátěže na 7. vrstvě:
V tomto případě uživatel požaduje yourdomain.com/blog a jeho požadavek je přesměrován na blog backend. Jedná se o sadu backendových serverů speciálně vyhrazenou pro spuštění blogové aplikace. Mezitím budou ostatní požadavky přesměrovány na web-backend. Oba backendy však nakonec přistupují ke stejnému databázovému serveru.
Příklad malé části konfigurace frontendu pro vyvažování zátěže na 7. vrstvě by vypadal jako následující příkazy. Konfigurují http frontend pro zpracování příchozího provozu přes port 80:
|
1 2 3 4 5 6 7 8 |
frontend http bind *:80 node http acl url_blog path_beg /blog use_backend blog.backend if url_blog default_backend web.backend |
Pokud cesta požadavku uživatele začíná na /blog, acl url_blog path_beg /blog bude odpovídat požadavku.
use_backend blog backend if url_blog předává provoz na blog-backend pomocí ACL.
defaut_backen web_backend směruje veškeré ostatní předávání provozu na web-backend.
Algoritmy pro vyvažování zátěže
Při provádění vyvažování zátěže určuje algoritmus vyvažování zátěže, který backendový server bude pro tento účel vybrán. HAProxy nabízí několik možností algoritmů. Serverům je navíc možné přiřadit parametr váhy (weight), a tím ovlivnit, jak často bude jeden server vybírán ve srovnání s ostatními. K dispozici je jednoduše příliš mnoho algoritmů, než abychom je zde popsali všechny. Proto se tato příručka zaměří pouze na ty nejběžnější. Můžete se podívat na HAProxy Documentation Converter, kde najdete úplný seznam. Mezi ty nejčastěji používané patří:
- roundrobin: Výchozí algoritmus, který vybírá servery po řadě.
- leastconn: Automaticky se vybere server s nejmenším počtem připojení. Servery v rámci stejného backendu by se však měly střídat metodou round-robin.
- source: Algoritmus vybírá server na základě IP adresy, ze které pochází požadavek uživatele. Jedná se o metodu, která zajišťuje, že se uživatel vždy připojí ke stejnému serveru.
Sticky Sessions
U některých aplikací je vyžadováno, aby se připojující se uživatelé vždy připojovali ke stejnému serveru. Pomocí „sticky sessions“ a použitím parametru appsession v backendu, který to vyžaduje, lze takové persistence dosáhnout.
Zpracování kontrol stavu
HAProxy potřebuje metodu, pomocí které může určit schopnost backendového serveru zpracovávat požadavky. To slouží k odstranění serveru z backendu, pokud přejde do režimu offline. Spouští se výchozí „kontrola stavu“ (health check), která se pokouší navázat TCP spojení. Činí tak nasloucháním na nakonfigurované IP adrese a portu.
Pokud kontrola stavu serveru neprojde, server není schopen zpracovávat odeslané požadavky. V tomto okamžiku je server v backendu automaticky deaktivován a provoz na něj již není přesměrováván, dokud není opět v provozu (v pořádku). V některých případech se však určení stavu serveru pomocí výchozí kontroly stavu ukazuje jako nedostatečné.
Alternativní řešení
HAProxy se může ukázat jako příliš sofistikované pro vaše konkrétní potřeby. V takovém případě existuje několik dobrých alternativ, které by se mohly ukázat jako efektivnější:
- Nginx: Jedná se o spolehlivý a rychlý webový server, který lze využít pro účely vyvažování zátěže a proxy. Nginx se ve skutečnosti běžně používá v kombinaci s HAProxy, které využívá jeho schopnosti komprese a ukládání do mezipaměti.
- Linux Virtual Servers (LVS): Jedná se o jednoduchý nástroj pro vyvažování zátěže na 4. vrstvě (layer 4), který je součástí mnoha systémů Linux.
Vysoká dostupnost
Dosud jsme hovořili o vyvažování zátěže na 4. a 7. vrstvě. Obě tyto metody využívají nástroj pro vyvažování zátěže (load balancer) k určení, který z mnoha backendových serverů bude pověřen odpovědí na požadavek uživatele. Je však důležité mít na paměti omezení load balanceru. Konkrétně to, že představuje jediný bod selhání (single point of failure). To znamená, že pokud by přestal fungovat nebo by byl přetížen požadavky uživatelů, vedlo by to k výpadku, respektive ke zpoždění zpracování požadavků. Nastavení HA (vysoké dostupnosti) však představuje infrastrukturu, která postrádá jakýkoli jediný bod selhání. Tím se předchází výpadkům způsobeným selháním serveru zavedením redundance na každé úrovni architektury systému. Zatímco load balancer pomůže zajistit redundanci backendu, samotné load balancery musí vykazovat redundanci také.
Následující diagram znázorňuje základní formu nastavení vysoké dostupnosti:

Tato infrastruktura má několik load balancerů (jeden aktivní, ostatní pasivní) vázaných na statickou IP adresu. Tuto IP adresu lze v případě potřeby přemapovat na jiný server. Požadavek uživatele putuje přes externí IP adresu do aktuálně aktivního load balanceru. Pokud je load balancer v daném okamžiku offline, mechanismus zajištění proti selhání (failsafe) detekuje jeho stav a přiřadí IP adresu pasivnímu serveru (nebo serverům).
Závěr
Základní pochopení vyvažování zátěže a znalost některých způsobů, jakými může HAProxy splnit potřeby vyvažování zátěže pro váš systém, by vám měly poskytnout pevný základ pro zahájení optimalizace spolehlivosti a výkonu vašich stávajících serverových prostředí. Můžete se také podívat na náš návod Nginx HTTP proxyování, vyvažování zátěže, buffering a cachování: přehled, abyste se dozvěděli více o vlastnostech vyvažování zátěže u Nginx.
Příjemnou práci!



Komentáře
Zatím žádné komentáře. Buďte první.