Serverové farmy dosahují vysoké škálovatelnosti a vysoké dostupnosti pomocí vyrovnávání zatížení serveru, což je technika, díky které se serverová farma klientům jeví jako jeden server. V tomto dvoudílném článku Gregor Roth zkoumá architektury rozložení zátěže serveru se zaměřením na open source řešení. Část 1 popisuje základy vyrovnávání zatížení serveru a pojednává o výhodách a nevýhodách vyrovnávání zatížení serveru na úrovni přenosu. Část 2 pokrývá architektury pro vyrovnávání zatížení serveru na úrovni aplikace, které řeší některá omezení architektur popsaných v části 1.
Bariéra vstupu pro mnoho internetových společností je nízká. Každý, kdo má dobrý nápad, může vyvinout malou aplikaci, zakoupit název domény a nastavit několik serverů založených na PC, které budou zpracovávat příchozí provoz. Počáteční investice je malá, takže počáteční riziko je minimální. Úspěšná nízkonákladová infrastruktura se ale může rychle stát vážným problémem. Jeden server, který zpracovává všechny příchozí požadavky, nemusí mít kapacitu zvládnout velké objemy provozu, jakmile se podnik stane populárním. V takových situacích společnosti často začínají zvýšit: upgradují stávající infrastrukturu zakoupením větší krabice s více procesory nebo přidáním více paměti pro spuštění aplikací.
Škálování je však jen krátkodobé řešení. A je to omezený přístup, protože náklady na upgrade jsou nepřiměřeně vysoké ve srovnání se zisky ve schopnosti serveru. Z těchto důvodů se nejúspěšnější internetové společnosti řídí a škálování přístup. Komponenty aplikace jsou zpracovány jako více instancí na serverových farmách, které jsou založeny na nízkonákladovém hardwaru a operačních systémech. Jak se zvyšuje provoz, přidávají se servery.
Přístup server-farma má své vlastní jedinečné požadavky. Na straně softwaru musíte navrhnout aplikace tak, aby mohly běžet jako více instancí na různých serverech. To provedete rozdělením aplikace na menší součásti, které lze nasadit samostatně. To je triviální, pokud jsou komponenty aplikace bez státní příslušnosti. Protože komponenty nezachovávají žádný transakční stav, může každá z nich zpracovat stejné požadavky stejně. Pokud je vyžadován větší výpočetní výkon, stačí přidat více serverů a nainstalovat komponenty aplikace.
Náročnější problém nastává, když jsou komponenty aplikace stavové. Například pokud komponenta aplikace obsahuje data nákupního košíku, musí být příchozí požadavek směrován na instanci komponenty aplikace, která obsahuje data nákupního košíku tohoto žadatele. Později v tomto článku proberu, jak zacházet s takovými daty relace aplikace v distribuovaném prostředí. Pro snížení složitosti se však nejúspěšnější internetové aplikační systémy snaží vyhnout stavovým aplikačním komponentům, kdykoli je to možné.
Na straně infrastruktury musí být zatížení zpracování rozloženo mezi skupinu serverů. Toto se nazývá vyrovnávání zatížení serveru. Technologie vyrovnávání zátěže se týkají i jiných domén, například šíření práce mezi komponentami, jako jsou síťové odkazy, CPU nebo pevné disky. Tento článek se zaměřuje na vyrovnávání zatížení serveru.
Dostupnost a škálovatelnost
Vyrovnávání zatížení serveru rozděluje požadavky na služby mezi skupinu skutečných serverů a klientům tyto servery vypadají jako jeden velký server. Za adresou URL, která implementuje jednu virtuální službu, jsou často desítky skutečných serverů.
Jak to funguje? V široce používané architektuře vyrovnávání zatížení serveru je příchozí požadavek směrován do vyhrazeného nástroje pro vyrovnávání zatížení serveru, který je pro klienta transparentní. Na základě parametrů, jako je dostupnost nebo aktuální zatížení serveru, nástroj pro vyrovnávání zatížení rozhodne, který server by měl požadavek zpracovat, a předá jej vybranému serveru. Chcete-li poskytnout algoritmu vyrovnávání zatížení s požadovanými vstupními daty, nástroj pro vyrovnávání zatížení také načte informace o stavu a zatížení serverů, aby ověřil, že mohou reagovat na provoz. Obrázek 1 ilustruje tuto klasickou architekturu nástroje pro vyrovnávání zatížení.
Architektura dispečera načtení znázorněná na obrázku 1 je pouze jedním z několika přístupů. Chcete-li se rozhodnout, které řešení pro vyrovnávání zatížení je pro vaši infrastrukturu nejlepší, musíte zvážit dostupnost a škálovatelnost.
Dostupnost je definována provozuschopnost - doba mezi poruchami. (Odstávka je čas na detekci poruchy, její opravu, provedení požadovaného zotavení a restartování.) Během doby provozuschopnosti musí systém reagovat na každý požadavek v předem stanoveném, přesně stanoveném čase. Pokud je tato doba překročena, vidí to klient jako poruchu serveru. Vysoká dostupnost je v zásadě redundance v systému: pokud jeden server selže, ostatní transparentně převezmou zátěž serveru, který selhal. Selhání jednotlivého serveru je pro klienta neviditelné.
Škálovatelnost znamená, že systém může sloužit jednomu klientovi i tisícům současných klientů, protože splňuje požadavky na kvalitu služby, jako je doba odezvy. Při zvýšeném zatížení může vysoce škálovatelný systém zvýšit propustnost téměř lineárně v poměru k výkonu přidaných hardwarových prostředků.
Ve scénáři na obrázku 1 je vysoké škálovatelnosti dosaženo distribucí příchozího požadavku přes servery. Pokud se zatížení zvýší, lze přidat další servery, pokud se z nástroje pro vyrovnávání zatížení nestane úzké místo. Aby bylo možné dosáhnout vysoké dostupnosti, nástroj pro vyrovnávání zatížení musí sledovat servery, aby nedocházelo k předávání požadavků na přetížené nebo mrtvé servery. Kromě toho musí být redundantní také samotný nástroj pro vyrovnávání zatížení. O tomto bodu se budu bavit dále v tomto článku.
Techniky vyrovnávání zatížení serveru
Obecně platí, že řešení vyrovnávání zatížení serveru jsou dvou hlavních typů:
- Transportní úroveň Vyrovnávání zatížení - například přístup založený na DNS nebo vyrovnávání zatížení na úrovni TCP / IP - funguje nezávisle na užitečném zatížení aplikace.
- Úroveň aplikace Vyrovnávání zatížení používá k rozhodování o vyrovnávání zatížení užitečné zatížení aplikace.
Řešení pro vyrovnávání zátěže lze dále rozdělit na softwarové vyvažovače zátěže a hardwarové vyvažovače zátěže. Hardwarové vyrovnávače zatížení jsou specializované hardwarové boxy, které obsahují integrované obvody specifické pro aplikaci (ASIC) přizpůsobené pro konkrétní použití. ASIC umožňují vysokorychlostní předávání síťového provozu bez režie univerzálního operačního systému. Hardwarové balancery zátěže se často používají k vyrovnávání zátěže na úrovni přenosu. Hardwarové vyrovnávače zatížení jsou obecně rychlejší než softwarová řešení. Nevýhodou je jejich cena.
Na rozdíl od hardwarových balancerů zatížení fungují softwarové balancery zatížení na standardních operačních systémech a standardních hardwarových komponentách, jako jsou PC. Softwarová řešení běží buď ve vyhrazeném hardwarovém uzlu nástroje pro vyrovnávání zatížení, jak je znázorněno na obrázku 1, nebo přímo v aplikaci.
Vyrovnávání zatížení založené na DNS
Vyrovnávání zatížení založené na DNS představuje jeden z prvních přístupů k vyrovnávání zatížení serveru. Systém názvů domén na internetu (DNS) přidružuje adresy IP k názvu hostitele. Pokud do prohlížeče zadáte název hostitele (jako součást adresy URL), prohlížeč požaduje, aby server DNS přeložil název hostitele na adresu IP.
Přístup založený na DNS je založen na skutečnosti, že DNS umožňuje přiřazení více IP adres (skutečných serverů) jednomu názvu hostitele, jak je ukázáno v příkladu vyhledávání DNS v Seznamu 1.
Výpis 1. Příklad vyhledávání DNS
> nslookup amazon.com Server: ns.box adresa: 192.168.1.1 název: amazon.com adresy: 72.21.203.1, 72.21.210.11, 72.21.206.5Pokud server DNS implementuje přístup typu každý s každým, změní se po každé odpovědi DNS pořadí adres IP pro daného hostitele. Klienti, jako jsou prohlížeče, se obvykle pokoušejí připojit k první adrese vrácené z dotazu DNS. Výsledkem je, že odpovědi na více klientů jsou distribuovány mezi servery. Na rozdíl od architektury rozložení zátěže serveru na obrázku 1 není vyžadován žádný hardwarový uzel mezilehlého vyrovnávání zatížení.
DNS je efektivní řešení pro globální vyvažování zátěže serveru, kde musí být zátěž rozdělena mezi datová centra na různých místech. Globální vyvažování zátěže serveru založené na DNS je často kombinováno s jinými řešeními rozložení zátěže serveru k distribuci zátěže ve vyhrazeném datovém centru.
I když je snadné jej implementovat, přístup DNS má vážné nevýhody. Chcete-li omezit dotazy DNS, má klient tendenci ukládat dotazy DNS do mezipaměti. Pokud server nebude k dispozici, bude mezipaměť klienta i server DNS i nadále obsahovat adresu mrtvého serveru. Z tohoto důvodu přístup DNS málo implementuje vysokou dostupnost.
Vyrovnávání zátěže serveru TCP / IP
Vyrovnávače zatížení serveru TCP / IP fungují na přepínání vrstev na nízké úrovni. Oblíbeným softwarovým nástrojem pro vyrovnávání zatížení serveru na nízké úrovni je Linux Virtual Server (LVS). Skutečné servery se vnějšímu světu jeví jako jeden „virtuální“ server. Příchozí požadavky na připojení TCP jsou předávány na skutečné servery nástrojem pro vyrovnávání zatížení, který spouští jádro systému Linux opravené tak, aby obsahovalo kód IP Virtual Server (IPVS).
Aby byla zajištěna vysoká dostupnost, ve většině případů je nastavena dvojice uzlů nástroje pro vyrovnávání zatížení, přičemž jeden uzel nástroje pro vyrovnávání zatížení je v pasivním režimu. Pokud se nástroj pro vyrovnávání zatížení nezdaří, program prezenčního signálu, který běží na obou nástrojích pro vyrovnávání zatížení, aktivuje uzel pasivního nástroje pro vyrovnávání zatížení a iniciuje převzetí virtuální adresy IP (VIP). Zatímco prezenční signál je odpovědný za správu převzetí služeb při selhání mezi nástroji pro vyrovnávání zatížení, ke sledování stavu skutečných serverů se používají jednoduché skripty send / expect.
Transparentnosti vůči klientovi je dosaženo použitím VIP, který je přiřazen k nástroji pro vyrovnávání zatížení. Pokud klient vydá požadavek, nejprve je požadovaný název hostitele přeložen do VIP. Když obdrží paket požadavku, nástroj pro vyrovnávání zatížení rozhodne, který skutečný server by měl zpracovat paket požadavku. Cílová IP adresa paketu požadavku je přepsána na Real IP (RIP) skutečného serveru. LVS podporuje několik plánovacích algoritmů pro distribuci požadavků na skutečné servery. Často je nastaveno používání cyklického plánování, podobně jako vyvažování zátěže založené na DNS. U LVS se rozhodnutí o vyrovnávání zátěže provádí na úrovni TCP (vrstva 4 referenčního modelu OSI).
Po přijetí paketu požadavku jej skutečný server zpracuje a vrátí paket odpovědi. Chcete-li vynutit vrácení paketu odpovědí pomocí nástroje pro vyrovnávání zatížení, použije skutečný server jako výchozí cestu odpovědi VIP. Pokud nástroj pro vyrovnávání zatížení obdrží paket odpovědí, přepíše se zdrojová IP paketu odpovědí pomocí VIP (OSI Model Layer 3). Tento režim směrování LVS se nazývá směrování překladu síťových adres (NAT). Obrázek 2 ukazuje implementaci LVS, která využívá směrování NAT.
LVS podporuje také další režimy směrování, jako je Přímý návrat serveru. V tomto případě je paket odpovědí odeslán přímo klientovi skutečným serverem. K tomu musí být VIP přiřazen také ke všem skutečným serverům. Je důležité, aby server VIP nebyl řešitelný v síti; v opačném případě bude nástroj pro vyrovnávání zatížení nedostupný. Pokud nástroj pro vyrovnávání zatížení obdrží paket požadavku, namísto IP adresy se přepíše MAC adresa (OSI Model Layer 2) požadavku. Skutečný server obdrží paket požadavku a zpracuje ho. Na základě zdrojové adresy IP se paket odpovědí odešle přímo klientovi a obejde se nástroj pro vyrovnávání zatížení. U webového provozu může tento přístup dramaticky snížit vytížení balanceru. Obvykle se přenáší mnohem více paketů odpovědí než paketů požadavků. Například pokud požadujete webovou stránku, je často odeslán pouze jeden paket IP. Pokud je požadována větší webová stránka, je k přenosu požadované stránky vyžadováno několik paketů IP odezvy.
Ukládání do mezipaměti
Nízkoúrovňová řešení pro vyrovnávání zatížení serveru, jako je LVS, dosáhnou svého limitu, pokud je vyžadováno ukládání do mezipaměti na úrovni aplikace nebo podpora relace aplikace. Ukládání do mezipaměti je důležitý princip škálovatelnosti, aby se zabránilo nákladným operacím, které opakovaně načítají stejná data. Mezipaměť je dočasné úložiště, které obsahuje nadbytečná data vyplývající z předchozí operace načítání dat. Hodnota mezipaměti závisí na nákladech na načtení dat v porovnání s rychlostí přístupu a požadovanou velikostí mezipaměti.
Na základě algoritmu plánování nástroje pro vyrovnávání zatížení jsou požadavky na relaci uživatele zpracovávány různými servery. Pokud se na straně serveru použije mezipaměť, z bludných požadavků bude problém. Jedním z přístupů, jak to vyřešit, je umístit mezipaměť do globálního prostoru. memcached je populární řešení distribuované mezipaměti, které poskytuje velkou mezipaměť na více počítačích. Jedná se o rozdělenou, distribuovanou mezipaměť, která používá konzistentní hash k určení serveru mezipaměti (démona) pro danou položku mezipaměti. Na základě hash kódu klíče mezipaměti klientská knihovna vždy mapuje stejný hash kód na stejnou adresu serveru mezipaměti. Tato adresa se poté použije k uložení položky mezipaměti. Obrázek 3 ilustruje tento přístup do mezipaměti.
Výpis 2 použití spymemched, a memcached klient napsaný v Javě, do mezipaměti HttpResponse zprávy na více počítačích. The spymemched knihovna implementuje požadovanou logiku klienta, kterou jsem právě popsal.
