Implementace softwarových load-balancerů s použitím open-source platforem

Transkript

1 Implementace softwarových load-balancerů s použitím open-source platforem Jan Michálek (mic518) 18. ledna

2 Obsah 1 Úvod Základní pojmy Škálovatelnost (scaling) Vyvažování zátěže (LoadBalancing) Vysoká dostupnost (High Availability = HA) cluster Druhy vyvažování zátěže dle vstev ISO-OSI Druhá vrstva Třetí vrstva / čtvrtá vrstva Sedmá vrstva Kombinace OpenSource software implementující vyvažování zátěže HAProxy Crossroads Pound Testování Závěr

3 Seznam použitých zkratek a symbolů WWW World Wide Web DNS Domain Name System LB Load Balancing ASIC Application-specific integrated circuit SSL Secure Sockets Layer TCP Transmission Control Protocol HTTP Hypertext Transfer Protoco HDD Hard Drive Disc SSH Secure Shell SMTP Simple Mail Transfer Protocol 3

4 1 Úvod 1.1 Základní pojmy Škálovatelnost (scaling) Každý server má konečný výkon, který je daný současnou technoligií i fyzikálními omezeními. Naproti tomu serverové aplikace musí zpracovávat stále rostoucí množství požadavků od stále rostoucího množství uživatelů. Může tedy dojít k situaci, kdy výkon jednoho serveru ani po všemožných optimalizacích na provoz takové aplikace nestačí. Ze situace jsou tři možná východiska: Přepsat celou aplikaci tak, aby byla schopná běžet paralelně na více serverech. To ovšem stojí nemalé finanční prostředky a hlavně čas. V době kdy bude taková aplikace dokončena už může být zastaralá a je třeba jí opět upravovat. Nezvládnutí tohoto přístupu může vést i ke snížení konkurenceschopnosti společnosti. 1 Aplikaci zkopírovat a nasadit mezi jednotlivé instance aplikace a uživatele software [1.1.2], který se postará o rozložení zátěže. Aplikace si přitom vůbec není vědoma situace. Toto řešení lze použít jenom ve vyjímečných případech, kdy nedochází k úpravě dat na straně aplikace a tudíž kopie jsou stále shodné. Kompromis mezi výše uvedenými. Mezi klienty a aplikaci je nasazen software [1.1.2] a současně je aplikace částěčně upravena, aby byla s tímto software schopna spolupracovat. Tento přístup je v současnosti nejčastější u středně velkých firem a postupně se prosazuje i do menších. Schopnost aplikace dynamicky využívat proměnné množství sytémových prostředků dle vytížení bez toho, aby to mělo vliv na její funkčnost lze nazývat škálovatelností Vyvažování zátěže (LoadBalancing) Vyvažování zátěže je schopnost přimět více serverů podílet se na jedné službě a vykonávat stejnou práci Vysoká dostupnost (High Availability = HA) S narůstajícím počtem serverů podílejících se na jedné službě, roste pravděpodobnost selhání některého ze zůčastněných prvků. Schopnost zajistit plnohodnotnou službu během předem stanoveného počtu současných selhání 3 se nazýva vysoká dostupnost. Oba předchozí pojmy spolu úzce souvisí a proto je lidé často zaměňují. Je ovšem nutné mít na paměti, že jisté LoadBalancingové techniky neposkytují automaticky vysokou dostupnout a jsou proto nebezpečné cluster Původní význam slova cluster dle definice z wikipedie[5]: Počítačový cluster (anglicky computer cluster) je seskupení volně vázaných počítačů, které spolu úzce spolupracují, takže navenek mohou pracovat jako jeden počítač. Obvykle jsou propojeny počítačovou sítí. Clustery jsou obvykle nasazovány pro zvýšení výpočetní rychlosti nebo spolehlivosti s větší efektivitou než by mohl poskytnout jediný počítač, přičemž jsou levnější než jediný počítač o srovnatelné rychlosti nebo spolehlivosti. Tento význam může být u vyvažování zátěže použit přeneseně. Jednotlivé uzly spolu totiž nemusejí nutně spolupracovat, pouze plní stejnou úlohu. (Např. generování WWW stránky) 1 Přesto je tento proces někdy nunté podstoupit 2 např. zobrazení WWW stránky, vykonání SQL dotazu,... 3 Hodnoty jsou většinou zakotvené ve smlouvách s klienty a za každé procento se draze platí 1

5 Obrázek 1: The OSI Reference Model, zdroj: [1] 2 Druhy vyvažování zátěže dle vstev ISO-OSI Jednotlivé vrstvy ISO modelu jsou obrázku 1 na str Druhá vrstva LoadBalancing na druhé vrstvě (také nazýván jako link aggregation, port aggregation, etherchannel, gigabit etherchannel port bundling) je sdružování více fyzických spojení do jednoho logického, které má vyšší propustnost než jednotlivá fyzická spojení. Jsou-li spoje vedeny odlišnými fyzickými cestami, pak agregace také vytváří redundaci a zvyšuje odolnost vůči výpadkům, Agregace spojení může být použita aby zlepšila přístup koncových sítí spojením modemových nebo digitálních spojení. Také může být použita při budování multigigabitové páteřní sítě. Linuxový kernel má zabudovanou podporu agregace, takže je možné spojit více rozhraní tak, aby se zvýšila propustnost nebo odolnost vůči výpadkům. zdroj [2] 2.2 Třetí vrstva / čtvrtá vrstva Nejvyšší výkon lze dosáhnout přidáním nejnižšího možného overhead-u při zpracování dat. To zpravidla znamená zpracování packetů na sít ové vrstvě. Proto mají LoadBalancer-y na třetí vrstvě vysokou propustnost. (Např. přímé routování na základě hashovacího algoritmu). Bohužel vyvažování zátěže na úrovni třetí vrstvy téměř nikdy nestačí a je nutno zpracovat i datagramy z vyšší (4.) vrstvy. Poté nejvíce strojového času zpravidla zabere vytváření session a její ukončení. I tyto operace lze ovšem zvládnout vysokými rychlostmi, protože jsou strojově levné. Náročnější aplikace (jako je např. překlad adres) vyžadují mnohem větší výkon. Musí totiž přepočítávat kontrolní součty a vyhledávat v tabulkách. Na všechny tyto operace je dnes často využívána hardwarová akcelerace. Dedikovaný ASIC LoadBalancer dokáže směrovat pakety na rychlosti blížící se rychlosti média, zakládat a ukončovat session prakticky okamžitě. Nároky na pamět jsou přitom maximálně několik set bytů na session. (uložení paketů před směrováním a parametry session). Dedikované LoadBalancer-y také umožňují další pokročilé techniky, jako je např. virtuální MAC, mapování celých sítí na jednu IP apod. 2

6 Oproti tomu proxy na 4. vrstvě zpracovávaná softwarově povede ke značnému snížení výkonu. Na jednoduché úlohy, které by bylo možné zpracovat na úrovni paketů, musí systém decapsulovat jednotlivé vrstvy aby našel odpovídající data, alokovat pamět, předat je procesu, navázat spojení na vzdálený server a do toho všeho ještě spravovat zdroje systému. Z tohoto důvodu bude softwarová proxy 5-10 krát pomalejší než hardwarové zařízení postavené za tímto účelem. Nároky na pamět jsou zde mnohem vyšší. (Je nutné držet buffery pro komunikaci se systémem, údaje o session). Velikost paměti zabraná jednou session se tak může vyšphat k několika kilobytům. Přeloženo z [3] Na první pohled se zdá, že vše mluví pro použítí Dedikovaných LoadBalancer-ů. Jejich zásadní nevýhodou je ovšem cena. Základní modely se málokdy prodávají pod CZK. Naproti tomu softwarovou proxy lze rozběhnout na drtivé většině běžně dostupného hardware pro PC navíc pod opensource řešením. Viz kap.[3] 2.3 Sedmá vrstva Vyvažování zátěže na 7. vrstvě (také známý pod application-level LoadBalancing) spočívá v analýze požadavků na aplikační vrstvě a jejich distribuci na servery v závislosti na obsahu požadavku a vytížení serverů. Tímto je dosaženo požadované úrovně QoS. Overhead je při tomto typu vyvažování zátěže z důvodu dekapsulace až do aplikační vrstvy znatelně vyšší, proto má v porovnání se čtvrtou vrstvou menší škálovatelnost. Navíc se musí potýkat s následujícími potížemi: hlavička komunikace rozšířená přes více paketů pakety v přeházeném pořadí fragmentace ztracené pakety a jejich znovuodeslání sloučení nesprávných dvojic hlavička - data Detailní popis těchto problémů je možné nalézt na zdroji:[3] 2.4 Kombinace Jak lze vyvodit z předhozích odstavců, neexistuje jediný univerzální prostředek na jedné vrstvě, který by řešil všechny problémy. Proto je nutné kombinovat přístupy dle skutečných potřeb a hlavně dle ceny. Ideální architektura strukturovaného LoadBalancer-u pro WWW služby (včetně SSL) je na obr. 2 na str. 4. 3

7 Obrázek 2: Ideální škálovatelná architektura pro WWW zdroj:[3] 4

8 3 OpenSource software implementující vyvažování zátěže Ve světě OpenSource se vyskytuje až překvapivě vysoký počet software implementující vyvažování zátěže. Některé jsou kvalitně vyvinuté a připravené na nasazení do produkční sféry, další potřebují ještě překonat své nedostatky. V následující kapitole se pokusím shrnout nejznámější z nich. 3.1 HAProxy HAProxy je volně dostupné, velmi rychlé a spolehlivé řešení poskytující vysokou dostupnost, load- Balancing a proxy pro TCP a HTTP aplikace. Je speciálně vhodný pro webové stránky které trpí velkou zátěží a současně potřebují zachovat perzistenci na sedmé vrstvě. S použitím hardware, který je dnes reálně dostupný je možné obsluhovat desítky tísíc současných spojení. 4 Myšlenka na které HAProxy funguje jí činí snadno integrovatelnou do existující architektury při vnesení pouze nízkých rizik. Přitom ovšem nabízí možnost nevystavovat křehké web servery na Net. Pod pokličkou...: HAProxy funguje na principu událostmi řízeného, jednoprocesového modelu, který nabízí podpory pro velké množství současných spojení při zachování velkých rychlostí. Víceprocesové nebo vícevláknové modely dokáží pouze vyjímečně pracovat s tísici spojení kvůli pamět ovým omezením, omezením plynoucím z časovačl systému a zahlcením zámků. Model řízený událostmi nemá takovéto problémy, protože implementace v user-space dovoluje preciznější správu zdrojů a času. Problémem tohoto přístupu je, že není dobře škálovatelný na víceprocesorových systémech. Proto musí být optimalizován, aby se během každého procesorového cyklu odvedlo co nejvíce práce. 5 Podporované OS/platformy Linux 2.4 on x86, x86 64, Alpha, SPARC, MIPS, PARISC Linux 2.6 on x86, x86 64, ARM (ixp425), PPC64 Solaris 8/9 on UltraSPARC 2 and 3 Solaris 10 on Opteron and UltraSPARC FreeBSD on x86 OpenBSD 3.1 to -current on i386, amd64, macppc, alpha, sparc64 and VAX (check the ports) zdoj: [4] Současné typické použití je 1U server vybavený dual-core Opteron/Xeon, který dosáhne mezi a dotazy/s a nemá problém saturace 2Gbps. Tento software jsem také otestoval, více v kapitole Crossroads Crossroads je open source LoadBalancer a fail over nástroj pro TCP orientované služby. Je to daemon běžící v userspace, je bohatý na funkce a nabízí široké možnosti nastavení. Umožňuje pooling backendu pomocí wakeup volání, odchytávání návratových hodnot těchto volání a příslušné akce při selhání a mnoho dalšího. Crossroads je nezávislý na službě: může být použit pro HTTP(S), SSH, SMTP, DNS a další. U HTTP navíc dokáže udržet sessions pro ty procesy, které je potřebují. Ve verzi 2.00 Crossroads prošel dramatickými změnami. Není již forkující se daemon, ale místo toho se stal vícevláknovým program, který pracuje pouze v jednom úseku paměti. Toto opatření významně zvýšilo výkonnost ve srovnání s verzemi 1.xx. zdroj:[6] 4 Toto tvrzení je těžko uvěřitelné, ale teoreticky možné. V praxi se ovšem s tím, aby na jednom L7 LoadBalancer-u běželo tolik spojení nesetkáme. 5 Tento přístup dle mého názoru přímo odporuje myšlence vyvažování zátěže a škálovatelnosti 5

9 Obrázek 3: Reverzní proxy, zdroj: [5] 3.3 Pound Pound je program poskytující reverzní proxy, LoadBalancer a HTTPS rozhraní pro Webové servery. Pound byl vyvinut pro distribuci zátěže mezi několik Webových serverů a také aby umožnil vhodnou SSL wrapper technologii pro Webové servery, které ji neposkytují samy. Je distribuován pod GPL - no warranty licencí a je zdarma k použítí, kopírování a šíření. Co Pound nabízí: Reverzní proxy: předává požadavky od klientů na back-end servery LoadBalancer: distribuuje požadavky přes více back-end serverů, přičemž zachovává session informace. SSL wrapper: Dekryptuje HTTPS požadavky od klientů a zasílá je jako HTTP na server. HTTP/HTTPS sanitizer: Pound will ověřuje požadavky a přijímá pouze dobře formulované. fail over-server: Při selhání back-endu na něj Pound nevysílá další požadavky, dokud nedojde k jeho zotavení. request redirector: požadavky mohou být předávány na různé back-end servery dle jejich obsahu. Pound je velmi malý software, se snadno sledovatelným auditem pro bezpečnostní problémy. Může pracovat v setuid,setgid a chrootovaných prostředích. Nepřistupuje k HDD (kromě počátečního načtení certifikátů při startu). zdroj: [7] 6

10 4 Testování Pro testování jsem vybral software HAProxy z důvodu jeho velké rozšířenosti a snadnému nasazení. Samotný test jsem prováděl ve virtualizovaném prostředí, přičemž konfigurace jednotlivých strojů byla zcela shodná. Provedl jsem i sérii jednoduchých benchmarků nejdříve na jednom serveru: obr. 4. Na tomto serveru byla umístěna statická data (php + obrázky) i MySQL server. Cluster o proměnném počtu uzlů (node 1-3) měl společné úložiště statických dat, na kterém byl umístěn i MySQL server: obr. 5. Testování probíhalo zasíláním série HTTP požadavků na zobrazení stránky a měřením doby zpracování celé série. Jeden test spočíval v zobrazení titulní stránky aplikace Wordpress. Další test byl více zaměřen na mysql, šlo o jednochý SELECT s ORDER BY tabulku s cca 8000 záznamy, výsledek se vypíše přímo na stánku, čímž se zatíží uzel i společné úložiště. Detailní popis instalace a konfigurace serverů a provádení benchmarků je uveden v souboru přiloženém k této práci. Výsledky z benchmarků jsou graficky znázorněny na obr. 6 a 7 Obrázek 4: Single node Obrázek 5: Testovaná sestava 7

11 Obrázek 6: SQL dotaz volaný z PHP na sdílenou databázi obsahující ORDER BY na několik tisíc řádků Obrázek 7: Benchmark 2 - načtení titulní stránky RS Wordpress 8

12 5 Závěr Celkově výsledky testování odpovídají obecným předpokladům, že zvyšováním počtu pracujících uzlů dochází ke snižování celkového času zpracování. Vyjímkou byla vyšší doba zpracování u tří uzlů než u dvou na obr. 6. Tuto nesrovnalost připisuji zpoždění vznikajícím na sít ové komunikaci mezi uzly a datovým úložištěm. Také je možný vliv zkreslení vzniklého prací s virtálními stroji. Po srovnání výhod a nevýhod testované technologie vyvažování zátěže, bych její nasazení rozhodně doporučil. 9

13 Seznam obrázků 1 The OSI Reference Model, zdroj: [1] Ideální škálovatelná architektura pro WWW zdroj:[3] Reverzní proxy, zdroj: [5] Single node Testovaná sestava SQL dotaz volaný z PHP na sdílenou databázi obsahující ORDER BY na několik tisíc řádků Benchmark 2 - načtení titulní stránky RS Wordpress Reference [1] The OSI Reference Model [online] [cit ]. ISO Model.Dostupné z WWW: < [2] Load balancing [online] [cit ]. Network Load Balancing. Dostupné z WWW: < balancing>. [3] Making applications scalable with Load Balancing [online] [cit ]. Willy Tarreau s articles. Dostupné z WWW < lb/>. [4] HAProxy [online] [cit ] The Reliable, High Performance TCP/HTTP Load Balancer. Dostupné z WWW < [5] Počítačový cluster [online] [cit ]. Počítačový cluster. Dostupné z WWW < cluster>. [6] Crossroads [online] [cit ]. Crossroads. Dostupné z WWW < [7] Pound [online] [cit ]. Pound - Reverse-Proxy and Load-Balancer. Dostupné z WWW < 10