Programovanie

Architektúry vyrovnávania zaťaženia servera, časť 1: Vyrovnávanie zaťaženia na úrovni transportu

Serverové farmy dosahujú vysokú škálovateľnosť a vysokú dostupnosť pomocou vyrovnávania zaťaženia servera, čo je technika, vďaka ktorej sa serverová farma javí klientom ako jeden server. V tomto dvojdielnom článku Gregor Roth skúma architektúry vyrovnávania zaťaženia servera so zameraním na otvorené riešenia. Časť 1 obsahuje základné informácie o vyrovnávaní zaťaženia servera a pojednáva o výhodách a nevýhodách vyrovnávania zaťaženia servera na úrovni transportu. Časť 2 sa zaoberá architektúrami vyrovnávania zaťaženia serverov na úrovni aplikácie, ktoré sa zaoberajú niektorými obmedzeniami architektúr diskutovaných v časti 1.

Bariéra vstupu pre mnoho internetových spoločností je nízka. Každý, kto má dobrý nápad, môže vyvinúť malú aplikáciu, kúpiť si doménové meno a nastaviť niekoľko serverov na báze PC, aby zvládli prichádzajúci prenos. Počiatočná investícia je malá, takže počiatočné riziko je minimálne. Úspešná nízkonákladová infraštruktúra sa ale môže rýchlo stať vážnym problémom. Jeden server, ktorý spracováva všetky prichádzajúce požiadavky, nemusí mať kapacitu na zvládnutie veľkého objemu prenosu, akonáhle sa podnik stane populárnym. V takýchto situáciách spoločnosti často začínajú zvýšiť: inovujú existujúcu infraštruktúru zakúpením väčšieho boxu s väčším počtom procesorov alebo pridaním väčšej pamäte na spustenie aplikácií.

Rozšírenie je však iba krátkodobým riešením. A je to obmedzený prístup, pretože náklady na aktualizáciu sú nepomerne vysoké v porovnaní so ziskom v schopnosti servera. Z týchto dôvodov sa najúspešnejšie internetové spoločnosti riadia a škálovanie prístup. Komponenty aplikácie sa spracúvajú ako viaceré inštancie na serverových farmách, ktoré sú založené na nízkonákladovom hardvéri a operačných systémoch. Ako sa zvyšuje prevádzka, pridávajú sa aj servery.

Prístup server-farma má svoje vlastné jedinečné požiadavky. Po softvérovej stránke musíte navrhnúť aplikácie tak, aby mohli bežať ako viaceré inštancie na rôznych serveroch. Urobíte to rozdelením aplikácie na menšie komponenty, ktoré je možné nasadiť nezávisle. Je to triviálne, ak sú komponenty aplikácie bez štátnej príslušnosti. Pretože komponenty nezachovávajú žiadny stav transakcie, ktorákoľvek z nich dokáže vybaviť rovnaké požiadavky rovnako. Ak je potrebný väčší výpočtový výkon, stačí pridať viac serverov a nainštalovať komponenty aplikácie.

Náročnejší problém nastáva, keď sú aplikačné komponenty stavové. Napríklad, ak komponent aplikácie obsahuje údaje nákupného košíka, musí sa prichádzajúca požiadavka smerovať na inštanciu komponentu aplikácie, ktorá uchováva údaje nákupného košíka tohto žiadateľa. Ďalej v tomto článku budem diskutovať o tom, ako zaobchádzať s takýmito údajmi relácie aplikácie v distribuovanom prostredí. Avšak pre zníženie zložitosti sa najúspešnejšie internetové aplikačné systémy snažia vyhnúť sa stavovým komponentom aplikácie, kedykoľvek je to možné.

Na strane infraštruktúry musí byť zaťaženie spracovania rozdelené medzi skupinu serverov. Toto sa nazýva vyrovnávanie záťaže servera. Technológie vyrovnávania zaťaženia sa týkajú aj iných domén, napríklad šírenia medzi komponentmi, ako sú sieťové odkazy, procesory alebo pevné disky. Tento článok sa zameriava na vyrovnávanie zaťaženia servera.

Dostupnosť a škálovateľnosť

Vyrovnávanie zaťaženia servera distribuuje požiadavky na služby medzi skupinu skutočných serverov a vďaka nim tieto servery vyzerajú pre klientov ako jeden veľký server. Za adresou URL, ktorá implementuje jednu virtuálnu službu, sú často desiatky skutočných serverov.

Ako to funguje? V široko používanej architektúre vyrovnávania zaťaženia servera je prichádzajúca požiadavka smerovaná do vyhradeného nástroja na vyrovnávanie zaťaženia servera, ktorý je pre klienta transparentný. Na základe parametrov, ako je dostupnosť alebo aktuálne zaťaženie servera, nástroj na vyrovnávanie zaťaženia rozhodne, ktorý server by mal požiadavku vybaviť, a preposiela ju vybranému serveru. Na zaistenie algoritmu vyrovnávania zaťaženia s požadovanými vstupnými údajmi načítava nástroj na vyrovnávanie zaťaženia tiež informácie o stave a zaťažení serverov, aby overil, či môžu reagovať na prenos. Obrázok 1 zobrazuje túto klasickú architektúru nástroja na vyrovnávanie zaťaženia.

Architektúra dispečera záťaže znázornená na obrázku 1 je iba jedným z niekoľkých prístupov. Musíte sa rozhodnúť, ktoré riešenie na vyrovnávanie zaťaženia je pre vašu infraštruktúru najlepšie dostupnosť a škálovateľnosť.

Dostupnosť je definovaná uptime - čas medzi poruchami. (Odstávka je čas na zistenie poruchy, jej opravu, vykonanie požadovanej obnovy a reštartovanie systému.) Počas doby prevádzkyschopnosti musí systém reagovať na každú požiadavku v rámci vopred stanoveného, ​​presne stanoveného času. Ak je tento čas prekročený, klient to vidí ako poruchu servera. Vysoká dostupnosť je v zásade redundancia v systéme: ak zlyhá jeden server, ostatné transparentne prevezmú načítanie servera, ktorý zlyhal. Zlyhanie jednotlivého servera je pre klienta neviditeľné.

Škálovateľnosť znamená, že systém dokáže uspokojiť požiadavky na kvalitu služieb, ako je napríklad doba odozvy, pre jedného klienta aj pre tisíce súčasne pracujúcich klientov. Pri zvýšenom zaťažení môže vysoko škálovateľný systém zvýšiť priepustnosť takmer lineárne v pomere k výkonu pridaných hardvérových zdrojov.

V scenári na obrázku 1 sa dosahuje vysoká škálovateľnosť distribúciou prichádzajúcej požiadavky cez servery. Ak sa zaťaženie zvýši, je možné pridať ďalšie servery, pokiaľ sa nástroj na vyrovnávanie zaťaženia nestane úzkym miestom. Na dosiahnutie vysokej dostupnosti musí nástroj na vyrovnávanie zaťaženia monitorovať servery, aby sa vyhli preposielaniu požiadaviek na preťažené alebo mŕtve servery. Ďalej musí byť nadbytočný aj samotný vyrovnávač zaťaženia. Tomuto bodu sa budem venovať neskôr v tomto článku.

Techniky vyrovnávania zaťaženia servera

Riešenia na vyrovnávanie zaťaženia servera sú vo všeobecnosti dva hlavné typy:

  • Transportná úroveň vyvažovanie záťaže - napríklad prístup založený na DNS alebo vyvažovanie záťaže na úrovni TCP / IP - funguje nezávisle od užitočného zaťaženia aplikácie.
  • Úroveň aplikácie Vyrovnávanie zaťaženia používa na rozhodovanie o vyrovnávaní zaťaženia užitočné zaťaženie aplikácie.

Riešenia na vyrovnávanie zaťaženia je možné ďalej rozdeliť na softvérové ​​vyrovnávače zaťaženia a hardvérové ​​vyrovnávače zaťaženia. Hardvérové ​​vyvažovače zaťaženia sú špecializované hardvérové ​​boxy, ktoré zahŕňajú aplikačne špecifické integrované obvody (ASIC) prispôsobené pre konkrétne použitie. ASIC umožňujú vysokorýchlostné presmerovanie sieťovej prevádzky bez réžie univerzálneho operačného systému. Na vyvažovanie záťaže na úrovni transportu sa často používajú hardvérové ​​balancéry záťaže. Hardvérové ​​vyrovnávače zaťaženia sú vo všeobecnosti rýchlejšie ako softvérové ​​riešenia. Ich nevýhodou sú náklady.

Na rozdiel od hardvérových vyrovnávačov zaťaženia fungujú softvérové ​​vyrovnávače zaťaženia na štandardných operačných systémoch a štandardných hardvérových komponentoch, ako sú PC. Softvérové ​​riešenia fungujú buď v samostatnom hardvérovom uzle nástroja na vyrovnávanie zaťaženia, ako je to na obrázku 1, alebo priamo v aplikácii.

Vyrovnávanie zaťaženia založené na DNS

Vyrovnávanie zaťaženia založené na DNS predstavuje jeden z prvých prístupov k vyrovnávaniu zaťaženia servera. Systém názvov domén na internete (DNS) spája adresy IP s názvom hostiteľa. Ak do prehľadávača zadáte názov hostiteľa (ako súčasť adresy URL), prehľadávač požaduje, aby server DNS preložil názov hostiteľa na adresu IP.

Prístup založený na DNS je založený na skutočnosti, že server DNS umožňuje priradiť viacerým adresám IP (skutočným serverom) k jednému názvu hostiteľa, ako je uvedené v príklade vyhľadávania DNS v zozname 1.

Výpis 1. Príklad vyhľadávania DNS

> nslookup amazon.com Server: ns.box adresa: 192.168.1.1 názov: amazon.com adresy: 72.21.203.1, 72.21.210.11, 72.21.206.5

Ak server DNS implementuje prístup založený na princípe round-robin, poradie adries IP pre daného hostiteľa sa zmení po každej odpovedi DNS. Spravidla sa klienti, napríklad prehliadače, pokúšajú pripojiť k prvej adrese vrátenej z dotazu DNS. Výsledkom je, že odpovede na viacerých klientov sú distribuované medzi servermi. Na rozdiel od architektúry vyrovnávania zaťaženia servera na obrázku 1 nie je potrebný žiadny hardvérový uzol medzičlánku na vyrovnávanie zaťaženia.

DNS je efektívne riešenie pre globálne vyrovnávanie zaťaženia servera, kde musí byť zaťaženie distribuované medzi dátovými centrami na rôznych miestach. Globálne vyrovnávanie zaťaženia servera založené na DNS sa často kombinuje s inými riešeniami vyrovnávania zaťaženia servera na distribúciu záťaže v rámci vyhradeného dátového centra.

Aj keď je prístup DNS jednoduchý na implementáciu, má vážne nevýhody. Na zníženie počtu DNS dotazov má klient tendenciu ukladať DNS dotazy do medzipamäte. Ak bude server nedostupný, vyrovnávacia pamäť klientov a server DNS budú naďalej obsahovať adresu mŕtveho servera. Z tohto dôvodu prístup DNS málo implementuje vysokú dostupnosť.

Vyrovnávanie zaťaženia servera TCP / IP

Vyrovnávače zaťaženia servera TCP / IP pracujú na prepínaní nízkoúrovňových vrstiev. Populárnym softvérovým nástrojom na vyrovnávanie zaťaženia serverov na nízkej úrovni je Linux Virtual Server (LVS). Skutočné servery sa navonok javia ako jeden „virtuálny“ server. Prichádzajúce požiadavky na pripojenie TCP preposiela na skutočné servery nástroj na vyrovnávanie zaťaženia, ktorý spúšťa jadro systému Linux opravené tak, aby obsahovalo kód virtuálneho servera IP (IPVS).

Na zaistenie vysokej dostupnosti je vo väčšine prípadov nastavená dvojica uzlov nástroja na vyrovnávanie zaťaženia, pričom jeden uzol nástroja na vyrovnávanie zaťaženia je v pasívnom režime. Ak zlyhá nástroj na vyrovnávanie zaťaženia, program prezenčného signálu, ktorý beží na oboch nástrojoch na vyrovnávanie zaťaženia, aktivuje uzol pasívneho nástroja na vyrovnávanie zaťaženia a iniciuje prevzatie virtuálnej adresy IP (VIP). Zatiaľ čo prezenčný signál je zodpovedný za správu núdzového prepnutia medzi nástrojmi na vyrovnávanie zaťaženia, na sledovanie stavu skutočných serverov sa používajú jednoduché skripty send / expect.

Transparentnosť pre klienta sa dosahuje použitím VIP, ktoré je priradené k nástroju na vyrovnávanie zaťaženia. Ak klient vydá požiadavku, najskôr sa požadované meno hostiteľa preloží do VIP. Keď prijme paket žiadosti, nástroj na vyrovnávanie zaťaženia rozhodne, ktorý skutočný server by mal spracovať paket žiadosti. Cieľová adresa IP paketu požiadaviek sa prepíše na skutočnú adresu IP (RIP) skutočného servera. LVS podporuje niekoľko plánovacích algoritmov na distribúciu požiadaviek na skutočné servery. Často sa nastavuje použitie plánovania typu každý s každým, podobné vyvažovaniu záťaže na základe DNS. Pri LVS sa rozhodnutie o vyrovnávaní zaťaženia robí na úrovni TCP (vrstva 4 referenčného modelu OSI).

Po prijatí paketu žiadosti ho skutočný server spracuje a vráti paket odpovedí. Na vynútenie vrátenia paketu odpovedí cez nástroj na vyrovnávanie zaťaženia použije skutočný server ako svoju predvolenú cestu odpovede VIP. Ak nástroj na vyrovnávanie zaťaženia prijme paket odpovedí, zdrojová IP paketu odpovedí sa prepíše pomocou VIP (OSI Model Layer 3). Tento režim smerovania LVS sa nazýva smerovanie sieťových prekladov (NAT). Obrázok 2 zobrazuje implementáciu LVS, ktorá využíva smerovanie NAT.

LVS podporuje aj ďalšie režimy smerovania ako napr Priamy návrat servera. V takom prípade je paket odpovedí odoslaný priamo klientovi skutočným serverom. Aby ste to dosiahli, musí byť VIP priradený aj všetkým skutočným serverom. Je dôležité, aby bol server VIP nerozpoznateľný v sieti; inak sa nástroj na vyrovnávanie zaťaženia stane nedostupným. Ak nástroj na vyrovnávanie zaťaženia prijme paket požiadavky, namiesto adresy IP sa prepíše adresa MAC (vrstva 2 OSI) požiadavky. Skutočný server prijme paket žiadosti a spracuje ho. Na základe zdrojovej adresy IP sa paket odpovedí odošle priamo klientovi, pričom sa obíde nástroj na vyrovnávanie zaťaženia. V prípade webového prenosu môže tento prístup dramaticky znížiť pracovné zaťaženie balanceru. Spravidla sa prenáša oveľa viac paketov odpovedí ako paketov požiadaviek. Napríklad, ak požadujete webovú stránku, často sa pošle iba jeden paket IP. Ak sa požaduje väčšia webová stránka, na prenos požadovanej stránky sa vyžaduje niekoľko paketov IP odpovede.

Ukladanie do vyrovnávacej pamäte

Nízkoúrovňové riešenia pre vyrovnávanie zaťaženia servera, ako napríklad LVS, dosiahnu svoj limit, ak sa vyžaduje ukladanie do pamäte cache na úrovni aplikácie alebo relácie aplikácie. Ukladanie do medzipamäte je dôležitý princíp škálovateľnosti, aby sa zabránilo nákladným operáciám, ktoré opakovane načítajú rovnaké dáta. Cache je dočasné úložisko, ktoré obsahuje nadbytočné údaje vyplývajúce z predchádzajúcej operácie načítania údajov. Hodnota medzipamäte závisí od nákladov na načítanie údajov v porovnaní s mierou prístupu a požadovanou veľkosťou medzipamäte.

Na základe algoritmu plánovania nástroja na vyrovnávanie zaťaženia vybavujú požiadavky relácie používateľa rôzne servery. Ak sa na strane servera použije vyrovnávacia pamäť, bludné požiadavky sa stanú problémom. Jedným z prístupov, ako to vyriešiť, je umiestniť vyrovnávaciu pamäť do globálneho priestoru. memcached je populárne riešenie distribuovanej pamäte cache, ktoré poskytuje veľkú pamäť cache na viacerých počítačoch. Je to rozdelená, distribuovaná vyrovnávacia pamäť, ktorá používa na určenie servera vyrovnávacej pamäte (démona) pre danú položku vyrovnávacej pamäte konzistentné hašovanie. Na základe hash kódu kľúča medzipamäte klientská knižnica vždy namapuje rovnaký hash kód na rovnakú adresu servera cache. Táto adresa sa potom použije na uloženie záznamu z pamäti cache. Obrázok 3 zobrazuje tento prístup do pamäte cache.

Zoznam 2 použití spymemched, a memcached klient napísaný v Jave, do medzipamäte HttpResponse správy na viacerých počítačoch. The spymemched knižnica implementuje požadovanú logiku klienta, ktorú som práve opísal.

Zoznam 2. medzipamäť HttpResponse založená na pamätiach

$config[zx-auto] not found$config[zx-overlay] not found