Horizontální škálování PHP aplikací. Základy škálování
Jak roste obliba webové aplikace, její podpora nevyhnutelně začíná vyžadovat stále více zdrojů. Nejprve lze (a nepochybně by mělo) zatížení řešit optimalizací algoritmů a/nebo architektury samotné aplikace. Co však dělat, když už bylo optimalizováno vše, co šlo optimalizovat, ale aplikace si se zátěží stále neví rady?
Optimalizace
První věc, kterou byste měli udělat, je sednout si a popřemýšlet, zda se vám již podařilo vše optimalizovat:- Jsou databázové dotazy optimální (EXPLAIN analýza, použití indexů)?
- jsou data uložena správně (SQL vs NoSQL)?
- používá se cachování?
- Existují nějaké zbytečné požadavky na systém souborů nebo databázi?
- Jsou algoritmy zpracování dat optimální?
- Jsou nastavení prostředí optimální: Apache/Nginx, MySQL/PostgreSQL, PHP/Python?
Měřítko
A tak řekněme, že optimalizace již byla provedena, ale aplikace se stále nedokáže vyrovnat se zátěží. V tomto případě může být řešením problému jeho distribuce mezi několik hostitelů, aby se zvýšil celkový výkon aplikace zvýšením dostupných zdrojů. Tento přístup má oficiální název – „škálování“ aplikace. Přesněji řečeno, „škálovatelnost“ označuje schopnost systému zvyšovat svůj výkon s rostoucím počtem zdrojů, které jsou mu přiděleny. Existují dva způsoby škálování: vertikální a horizontální. Vertikální škálování znamená zvýšení výkonu aplikace při přidávání zdrojů (procesor, paměť, disk) v rámci jednoho uzlu (hostitele). Horizontální škálování je typické pro distribuované aplikace a znamená zvýšení výkonu aplikace při přidání dalšího uzlu (hostitele).Je jasné, že nejjednodušší by byla jednoduchá aktualizace hardwaru (procesor, paměť, disk) – tedy vertikální škálování. Tento přístup navíc nevyžaduje žádné úpravy aplikace. Vertikální škálování však velmi rychle dosáhne svého limitu, po kterém vývojáři a správci nezbývá, než přejít na horizontální škálování aplikace.
Architektura aplikace
Většina webových aplikací je distribuována a priori, protože v jejich architektuře lze rozlišit nejméně tři vrstvy: webový server, obchodní logika (aplikace), data (databázová, statická).Každá z těchto vrstev může být škálována. Pokud tedy ve vašem systému aplikace a databáze žijí na stejném hostiteli, prvním krokem by samozřejmě měla být distribuce mezi různé hostitele.
Úzké místo
Když začínáte škálovat systém, prvním krokem je určit, která vrstva je „úzké místo“ – to znamená, že funguje pomaleji než zbytek systému. Pro začátek můžete použít banální nástroje jako top (htop) k odhadu spotřeby procesoru/paměti a df, iostat k odhadu spotřeby disku. Je však vhodné vyčlenit samostatný hostitel s emulací bojové zátěže (pomocí nebo JMeter), na kterém bude možné profilovat chod aplikace pomocí utilit, jako je xdebug a podobně. K identifikaci úzkých dotazů do databáze můžete použít nástroje jako pgFouine (je jasné, že je lepší to udělat na základě protokolů z produkčního serveru).Obvykle to závisí na architektuře aplikace, ale nejpravděpodobnějšími kandidáty na úzké místo obecně jsou databáze a kód. Pokud vaše aplikace pracuje s velkým množstvím uživatelských dat, pak bude úzkým místem s největší pravděpodobností statické úložiště.
Škálování databáze
Jak již bylo zmíněno výše, databáze je často úzkým hrdlem moderních aplikací. Problémy s ním se obvykle dělí do dvou tříd: výkon a potřeba ukládat velké množství dat.Zatížení databáze můžete snížit jejím rozložením na několik hostitelů. Současně se stává akutní problém synchronizace mezi nimi, což lze vyřešit implementací schématu master/slave se synchronní nebo asynchronní replikací. V případě PostgreSQL můžete implementovat synchronní replikaci pomocí Slony-I, asynchronní replikaci pomocí PgPool-II nebo WAL (9.0). Problém oddělení požadavků na čtení a zápis a také vyrovnávání zátěže mezi stávajícími slave zařízeními lze vyřešit nastavením speciální vrstvy pro přístup k databázi (PgPool-II).
Problém ukládání velkého množství dat při použití relačních DBMS lze vyřešit pomocí rozdělovacího mechanismu (“partitioning” v PostgreSQL) nebo nasazením databází na distribuované systémy souborů, jako je Hadoop DFS.
Pro ukládání velkého množství dat je však nejlepším řešením sdílení dat, které je vestavěnou výhodou většiny NoSQL databází (například MongoDB).
Kromě toho databáze NoSQL obecně pracují rychleji než jejich SQL bratři kvůli absenci režie pro analýzu/optimalizaci dotazů, kontrolu integrity datové struktury atd. Téma porovnávání relačních a NoSQL databází je také poměrně rozsáhlé a zaslouží si.
Samostatně stojí za zmínku zkušenost Facebooku, který používá MySQL bez výběrů JOIN. Tato strategie jim umožňuje mnohem snadněji škálovat databázi a zároveň přenášet zátěž z databáze do kódu, který, jak bude popsáno níže, se škáluje snadněji než databáze.
Škálování kódu
Obtížnost škálování kódu závisí na tom, kolik sdílených prostředků hostitelé potřebují ke spuštění vaší aplikace. Budou to pouze relace, nebo to bude vyžadovat sdílenou mezipaměť a soubory? V každém případě je prvním krokem spuštění kopií aplikace na několika hostitelích se stejným prostředím.Dále musíte nakonfigurovat vyvažování zátěže/požadavku mezi těmito hostiteli. To lze provést jak na úrovni TCP (haproxy), tak na HTTP (nginx) nebo DNS.
Dalším krokem je ujistit se, že na každém hostiteli jsou dostupné statické soubory, mezipaměť a relace webových aplikací. Pro relace můžete použít server běžící v síti (například memcached). Je docela rozumné použít stejný memcached jako cache server, ale samozřejmě na jiném hostiteli.
Statické soubory lze připojit ze sdíleného úložiště souborů přes NFS/CIFS nebo pomocí distribuovaného systému souborů (HDFS, GlusterFS, Ceph).
Můžete také ukládat soubory do databáze (například Mongo GridFS), čímž se vyřeší problémy s dostupností a škálovatelností (s přihlédnutím ke skutečnosti, že u NoSQL databází je problém škálovatelnosti vyřešen kvůli shardingu).
Samostatně stojí za zmínku problém nasazení na více hostitelů. Jak mohu zajistit, aby uživatel po kliknutí na „Aktualizovat“ neviděl různé verze aplikace? Nejjednodušším řešením by podle mého názoru bylo vyloučit neaktualizované hostitele z konfigurace nástroje pro vyrovnávání zatížení (webového serveru) a zapínat je postupně, jak jsou aktualizovány. Můžete také propojit uživatele s konkrétními hostiteli pomocí cookie nebo IP. Pokud aktualizace vyžaduje významné změny v databázi, nejjednodušším způsobem je dočasně projekt úplně zavřít.
FS škálování
Pokud je nutné ukládat velké množství statických dat, lze identifikovat dva problémy: nedostatek místa a rychlost přístupu k datům. Jak již bylo napsáno výše, problém s nedostatkem místa lze vyřešit minimálně třemi způsoby: distribuovaným souborovým systémem, ukládáním dat do databáze s podporou shardingu a organizováním shardingu „ručně“ na úrovni kódu.Je třeba si uvědomit, že distribuce statické elektřiny také není nejjednodušší úkol, pokud jde o vysoké zatížení. Proto je docela rozumné mít mnoho serverů vyhrazených pro distribuci statických souborů. Navíc, pokud máme sdílené datové úložiště (distribuovaný souborový systém nebo databázi), můžeme při ukládání souboru uložit jeho název bez zohlednění hostitele a název hostitele nahradit náhodně při generování stránky (náhodné vyvážení zatížení mezi webové servery distribuující statické soubory). V případě, kdy je sharding implementován ručně (to znamená, že logika v kódu je zodpovědná za výběr hostitele, do kterého budou data nahrána), musí být informace o hostiteli uploadu buď vypočteny na základě samotného souboru, nebo vygenerovány na základě na třetí údaje (informace o uživateli, množství místa na úložných discích) a uloženy spolu s názvem souboru do databáze.
Sledování
Je jasné, že velký a složitý systém vyžaduje neustálé sledování. Řešení je zde dle mého názoru standardní - zabbix, který hlídá zátěž/provoz systémových uzlů a monit pro démony pro zálohování.Závěr
Výše uvedené stručně pojednává o mnoha možnostech řešení problémů škálování webové aplikace. Každý z nich má své výhody a nevýhody. Neexistuje žádný recept, jak udělat vše dobře a najednou – pro každý úkol existuje mnoho řešení s vlastními klady a zápory. Který z nich si vyberete, je jen na vás.Schopnost škálovat informační systém – horizontálně i vertikálně – je jedním z nejdůležitějších faktorů, kterým byste měli věnovat pozornost při výběru prostředků pro automatizaci činností jakékoli organizace. Pokud zvolené řešení nelze škálovat nebo každá fáze obchodního růstu povede k potížím s údržbou a vývojem takového softwarového produktu, neměli byste jej ani začít používat. Vyvinuli jsme LETOGRAF EDMS s ohledem na vysoké požadavky na měřítko.
Potřeba horizontálního nebo vertikálního škálování vyvstává v souvislosti s tvorbou firemních vysoce zatěžovaných IT systémů zaměstnávajících tisíce nebo dokonce desetitisíce uživatelů. Ne všechny EDMS však mohou podporovat současný provoz velkého počtu uživatelů. Pouze pokud EDMS na architektonické úrovni obsahuje možnost zvýšit počet uživatelů bez ztráty výkonu - pouze v tomto případě bude škálování úspěšné. Systém LETOGRAF, který jsme vytvořili, byl navržen tak, aby byl ideálně škálovatelný horizontálně i vertikálně. Toho je dosaženo jak prostřednictvím architektury samotného systému a aplikačního kódu, který jsme vyvinuli, tak prostřednictvím funkcionality InterSystems Caché DBMS, na které je náš EDMS postaven.
Caché DBMS je moderní systém pro správu databází a prostředí pro rychlý vývoj aplikací. Tento DBMS je založen na technologii, která poskytuje rychlost a vysoký výkon, škálovatelnost a spolehlivost. Hardwarové nároky systému přitom zůstávají vcelku skromné.
Caché DBMS si zachovává vysoký výkon i při práci s obrovským množstvím dat a velkým počtem serverů v distribuovaných systémech. V tomto případě se k datům přistupuje prostřednictvím objektů, vysoce výkonných SQL dotazů a prostřednictvím přímého zpracování vícerozměrných datových struktur.
Vertikální škálování
Vertikální škálování zahrnuje zvýšení výkonu serveru a jeho schopností spojených s diskovým subsystémem. LETOGRAF podporuje moderní procesorovou architekturu, která umožňuje zpracovávat velké množství dat ve více vláknech. Zároveň jsou samotná data v EDMS organizována tak, že je lze snadno distribuovat napříč úložným systémem na různé disky. Tento přístup umožňuje rovnoměrně rozložit zatížení datových úložišť a minimalizovat je při čtení dat přímo z databáze, což znamená, že se lze vyhnout poklesu výkonu systému i při současné práci velkého počtu uživatelů.
Již ve fázi vývoje platformy jsme pochopili, že vertikální škálování je jednou z klíčových schopností systému, jejíž potřeba bude časem jen narůstat. Systém jsme vyvinuli tak, že pracovní procesy každého uživatele byly rozděleny do samostatných systémových procesů, které se navzájem nekříží díky tomu, že databáze efektivně sdílejí přístup k informacím. Zároveň je minimalizován počet datových zámků v LETOGRAF EDMS a nedochází k žádnému úzkému hrdlu ani při čtení dat, ani při jejich zápisu.
Architektura EDMS LETOGRAF umožňuje distribuovat data přes několik fyzických nebo virtuálních serverů. Díky této distribuci běží každý uživatel v izolovaném procesu a požadovaná data jsou efektivně ukládána do mezipaměti pomocí technologií Caché DBMS. Doba zamykání dat je minimalizována: všechny transakce jsou strukturovány tak, aby data přešla do režimu výhradního přístupu pouze na velmi krátkou dobu. Přitom i takto vysoce zatížená data z hlediska počtu přístupů na disk, jako jsou logy, indexy, objektová data, streamy, logy uživatelských akcí, jsou distribuována tak, aby průměrné zatížení subsystému zůstalo jednotné a nevede ke zpoždění. Tento přístup vám umožňuje efektivně vertikálně škálovat systém a rozdělovat zátěž mezi servery nebo virtuální disky.
Horizontální škálování
Horizontální škálování je distribuce uživatelských relací na různé servery (dokonce i zatížení aplikačních serverů a možnost připojení dalších aplikačních serverů), stejně jako distribuce dat mezi různé databázové servery, což zajišťuje vysoký výkon systému bez snížení odolnosti proti chybám. Pro horizontální škálování poskytuje systém LETOGRAF řadu možností.
Především se jedná o škálování zátěže díky Enterprise Cache Protocol (ECP, distribuovaný cache protokol), protokolu používaného v InterSystems Caché DBMS. Výhodou ECP je inovativní přístup k ukládání dat do mezipaměti. V rámci tohoto protokolu získávají uživatelské procesy, které běží na aplikačních serverech (nebo klientech ECP) DBMS a obsluhují dotazy, přístup k místní mezipaměti nedávno použitých dat. A pouze pokud tato data nestačí, ECP klient přistupuje k databázi. ECP provádí automatickou správu mezipaměti: nejčastěji používaná data jsou uložena v mezipaměti a často aktualizovaná data jsou periodicky replikována, což zajišťuje integritu a správnost dat napříč všemi klienty ECP za všech okolností. V tomto případě interní algoritmus InterSystems Caché předpokládá, že databáze jsou synchronizovány mezi klientem ECP a serverem ECP.
Využití technologií Caché DBMS ve skutečnosti umožňuje snadno a rychle škálovat zátěž napříč aplikačními servery a zajistit tak připojení velkého počtu uživatelů k jednomu databázovému serveru pomocí protokolu ECP.
Vzhledem k tomu, že informace požadované konkrétním uživatelem mohou být použity na několika ECP klientech, je nutné data na krátkou dobu zablokovat, rychle provádět transakce bez provádění interních výpočtů. A úspěšně jsme to realizovali. Tato technologie nám umožňuje efektivně škálovat systém v situaci, kdy je využíván jeden databázový server a několik serverů, na kterých běží uživatelské procesy. Technologickým rysem Caché DBMS je, že udržuje správnost transakcí v rámci jednoho ECP serveru bez ohledu na počet ECP klientů k němu připojených. V případě, že máme jeden ECP server a mnoho ECP klientů, je tento problém dokonale vyřešen, protože všechny transakce probíhají na jednom databázovém serveru.
Zkušenosti ukazují, že i ve vysoce zatížených systémech je vždy možné jasně rozdělit data mezi databázové servery na základě určitých charakteristik. Pokud je například několik organizací sdruženo do holdingu, je nepravděpodobné, že by uživatelé z jedné strukturální jednotky někdy vyžadovali data, která se týkají jiné jednotky. To umožňuje na úrovni algoritmu oddělovat a ukládat taková data na různých databázových serverech, čímž se zvyšuje možnost horizontálního škálování.
EDMS LETOGRAF implementuje shardovací mechanismus, díky kterému na úrovni nastavení systému (bez použití programování) umožňujeme popsat pravidla a principy samotné distribuce dat mezi různé databázové servery. Navzdory skutečnosti, že z hlediska databázové struktury jsou informace uložené na každém serveru stejné, samotné informace se zásadně liší v závislosti na organizaci nebo jakýchkoli jiných charakteristikách, které jsou významné pro konkrétní úkol. Pomocí technologie sharding je možné dosáhnout toho, že v 95-99 % případů budou uživatelé pracovat pouze se svou „částí dat“ a nebude potřeba přistupovat k různým databázovým serverům v rámci relace.
Schopnosti škálování LETOGRAF EDMS jsou ovlivněny také tím, že data lze zpracovávat různě. Například lze provádět změny v dokumentech (i těch, které byly vytvořeny před několika lety), ale záznamy lze přidávat pouze do protokolu činnosti uživatele (nelze smazat ani změnit jediný záznam). Mechanismy používané v LETOGRAF EDMS umožňují dále zvyšovat výkon systému a zlepšovat škálování udržováním těchto protokolů na samostatných databázových serverech - jak v případě jednoserverových, tak i víceserverových konfigurací. Tento přístup je zaměřen na snížení zatížení hlavních databázových serverů.
Podobná situace nastává u obsahu („informační obsah“ EDMS). Vzhledem k tomu, že systém LETOGRAF pracuje s velkým objemem obsahu – terabajty dat, miliony souborů a dokumentů – je rozumné předpokládat, že obsah, který se do systému dostane, by neměl být za žádných okolností poškozen. Proto také přesouváme úložiště souborů na samostatné databázové servery a poskytujeme tak další horizontální škálování.
Přední software
LETOGRAF EDMS používá jako front-end Apache a HAProxy. HAProxy je zodpovědný za vyvažování zátěže mezi webovými servery Apache. HAProxy, jak ukázaly zkušenosti systému, se etablovalo jako nejúčinnější řešení, které dokáže poskytnout podporu velkému počtu uživatelů a nezbytnou kontrolu nad odolností proti chybám.
Když uživatel otevře prohlížeč a připojí se k systému, HAProxy jej „distribuuje“ na jeden z aplikačních serverů. Dále budou všechny požadavky, které přijdou od tohoto uživatele, odeslány na stejný aplikační server ve stejném procesu.
Vyzkoušeli jsme různé systémy a testování ukázalo, že HAProxy je nejúčinnějším nástrojem pro vyrovnávání zátěže, který zajišťuje rovnoměrné rozložení uživatelů mezi volné sloty aplikačních serverů. HAProxy má všechny nezbytné mechanismy pro monitorování stavu každého aplikačního serveru a nerozdělování nového provozu na aplikační server, který z nějakého důvodu selhal. Kromě toho HAProxy navíc poskytuje řadu funkcí, pokud jde o ukládání statických (neměnných během práce uživatele) dat - například stylů, ikon atd. - do mezipaměti, což vám umožňuje organizovat rozhraní.
Příklad realizace projektu
Architektura LETOGRAF umožňuje dosáhnout významných výsledků při zkrácení doby odezvy a zvýšení výkonu systému. V rámci jednoho z našich projektů je v EDMS uloženo 23,5 TB dat. Z toho 14,7 TB (63 %) jsou streamy („soubory připojené ke kartám“), 3,5 TB (15 %) jsou formuláře pro hlášení, jako jsou tabulky sestav, které jsou generovány v asynchronním režimu a lze je spouštět podle plánu a na požadavek uživatele a představují souhrnnou tabulku, libovolná data, ve kterých mohou být podrobně popsány až k objektu. Dalších 1,6 TB (7 %) tvoří uživatelský protokol transakcí a zbytek (16 %) tvoří data a indexy karet.
Tento systém zaměstnává více než 11 tisíc uživatelů, 2 tisíce z nich pracuje současně a ve špičkách počet zaměstnanců současně pracujících v EDMS přesahuje 3 tisíce Počet záznamů v logu již přesáhl 5,5 miliardy a počet registračních karet dosáhl téměř půl miliardy.
V tomto projektu je jako databázový server nainstalován cluster dvou fyzických serverů odolných proti chybám se třemi instalacemi DBMS a také záložní server. Deset aplikačních serverů (a jeden záložní) zpracovává uživatelské relace a poskytuje asynchronní hlášení. 2 HAProxy servery fungují jako balancery. V případě problémů s jedním ze serverů je jeho IP adresa automaticky přenesena na jiný server. K dispozici je také server pro indexování souborů a server pro rozpoznávání (poskytující rozpoznání textu naskenovaných papírových dokumentů při vkládání elektronických obrázků do systému).
souhrn
EDMS LETOGRAF poskytuje velké množství různých škálovacích mechanismů. Nabízíme jakýsi koláč, který je založen na serveru (fyzickém nebo virtuálním), na kterém je nainstalován operační systém. Nad ním je InterSystems Caché DBMS, uvnitř kterého je umístěn kód platformy. A již nad ním je nastavení systému LETOGRAF, díky kterému je EDMS plně nakonfigurován. A takový koláč je umístěn na každém serveru. Servery jsou navzájem propojeny určitým způsobem díky zvoleným konfiguracím. A poslední vrstvou je HAProxy, která distribuuje požadavky uživatelů mezi servery. Tato architektura nám umožňuje podporovat škálovatelnost a poskytovat všechny potřebné monitorovací mechanismy. Výsledkem je, že koncoví uživatelé dostávají rychle běžící EDMS a IT specialisté jednotný systém, který lze snadno spravovat a udržovat, bez velkého množství komponent, které je v případě vysoce vytížených aplikací nutné neustále sledovat a spravovat. . Navíc, v závislosti na měnících se potřebách organizace, lze LETOGRAF EDMS snadno překonfigurovat přidáním nových serverů nebo možností disků.
Tento materiál je soukromý příspěvek člena komunity Club.CNews.
Redakce CNews nenese odpovědnost za její obsah.
Představme si, že jsme vytvořili web. Tento proces byl vzrušující a bylo skvělé sledovat, jak se zvyšuje počet návštěvníků.
Ale v určitém okamžiku začne návštěvnost růst velmi pomalu, někdo zveřejnil odkaz na vaši aplikaci na Reddit nebo Hacker News, něco se stalo se zdrojovým kódem projektu na GitHubu a obecně se zdálo, že všechno jde proti vám.
Kromě toho se váš server zhroutil a nezvládá stále se zvyšující zátěž. Místo získávání nových klientů a/nebo pravidelných návštěvníků vám nezbývá nic a navíc prázdná stránka.
Veškeré vaše snahy o obnovení práce jsou marné - ani po restartu server nezvládá příliv návštěvníků. Ztrácíte provoz!
Nikdo nemůže předvídat dopravní problémy. Jen velmi málo lidí se zabývá dlouhodobým plánováním, když pracuje na projektu s potenciálně vysokou návratností, aby dodržel pevný termín.
Jak se tedy můžete všem těmto problémům vyhnout? Chcete-li to provést, musíte vyřešit dva problémy: optimalizaci a škálování.
Optimalizace
Prvním krokem je aktualizace na nejnovější verzi PHP (aktuální verze 5.5, používá OpCache), indexování databáze a mezipaměť statického obsahu (zřídka se mění stránky jako About , FAQ a tak dále).
Optimalizace ovlivňuje více než jen ukládání statických zdrojů do mezipaměti. Je také možné nainstalovat další server bez Apache (například Nginx) speciálně navržený pro zpracování statického obsahu.
Myšlenka je tato: umístíte Nginx před váš server Apache (Ngiz bude frontend server a Apache backend) a zadáte mu zachycování požadavků na statické zdroje (tj. *.jpg, *.png, *.mp4 , *.html ...) a jejich služby BEZ ODESÍLÁNÍ požadavku na Apache.
Toto schéma se nazývá reverzní proxy (často je zmiňováno společně s technikou vyvažování zátěže, která je popsána níže).
Měřítko
Existují dva typy škálování – horizontální a vertikální.
Říkáme, že web je škálovatelný, když zvládne zvýšenou zátěž bez nutnosti změn softwaru.
Vertikální škálování
Představte si, že máte webový server obsluhující webovou aplikaci. Tento server má následující specifikace: 4GB RAM, i5 CPU a 1TB HDD.
Svou práci plní dobře, ale pro lepší zvládnutí narůstajícího provozu se rozhodnete vyměnit 4GB RAM za 16GB, nainstalovat nový i7 CPU a přidat PCIe SSD/HDD hybridní disk.
Server je nyní výkonnější a snese zvýšené zatížení. Tomu se říká vertikální škálování nebo „ škálování do hloubky"- zlepšujete vlastnosti vozu, aby byl výkonnější.
To je dobře znázorněno na obrázku níže:
Horizontální škálování
Na druhou stranu máme možnost horizontálně škálovat. Ve výše uvedeném příkladu je nepravděpodobné, že náklady na upgrade hardwaru budou nižší než náklady na počáteční náklady na nákup serverového počítače.
To je finančně velmi nákladné a často to nepřináší očekávaný efekt – většina problémů se škálováním souvisí s paralelním prováděním úloh.
Pokud počet procesorových jader nestačí ke spuštění dostupných vláken, pak nezáleží na tom, jak výkonný je CPU - server bude stále pracovat pomalu a nechá návštěvníky čekat.
Horizontální škálování zahrnuje vytváření shluků strojů (často s poměrně nízkou spotřebou), které jsou vzájemně propojeny, aby obsluhovaly webové stránky.
V tomto případě se používá load balancer – stroj nebo program, který určuje, do kterého clusteru má být odeslán další příchozí požadavek.
A stroje v clusteru automaticky sdílejí úlohu mezi sebou. V tomto případě se propustnost vašeho webu v porovnání s vertikálním škálováním zvýší o řád. Toto je také známé jako " škálovací šířka».
Existují dva typy load balancerů – hardwarové a softwarové. Softwarový balancér je nainstalován na běžném počítači a přijímá veškerý příchozí provoz a přesměrovává jej na příslušný obslužný program. Nginx může například fungovat jako softwarový nástroj pro vyrovnávání zátěže.
Přijímá požadavky na statické soubory a sám je obsluhuje, aniž by zatěžoval Apache. Dalším oblíbeným soft balancingem je Squid, který používám ve své firmě. Poskytuje úplnou kontrolu nad všemi možnými problémy prostřednictvím velmi uživatelsky přívětivého rozhraní.
Hardwarové balancéry jsou samostatným speciálním strojem, který plní výhradně úlohu balancování a na kterém zpravidla není nainstalován žádný další software. Nejoblíbenější modely jsou navrženy tak, aby zvládly obrovské množství provozu.
Při horizontálním měřítku se stane následující:
Všimněte si, že dvě popsané metody škálování se vzájemně nevylučují – můžete zlepšit hardwarové charakteristiky počítačů (nazývaných také uzly) používaných v clusterovém systému škálování.
V tomto článku se zaměříme na horizontální škálování, protože ve většině případů je výhodnější (levnější a efektivnější), i když je z technického hlediska obtížnější implementovat.
Potíže s oddělením dat
Existuje několik lepkavých bodů, které se objevují při škálování aplikací PHP. Úzkým hrdlem je zde databáze (více si o ní povíme v části 2 této série).
Problémy také vznikají se správou dat relace, protože po přihlášení na jednom počítači zjistíte, že jste neoprávnění, pokud vás balancer při příštím požadavku převede na jiný počítač. Existuje několik způsobů, jak tento problém vyřešit - můžete přenášet lokální data mezi počítači nebo použít trvalý nástroj pro vyrovnávání zatížení.
Persistent Load Balancer
Perzistentní load balancer si pamatuje, kde byl zpracován předchozí požadavek konkrétního klienta, a při dalším požadavku tam požadavek odešle.
Pokud jsem například navštívil náš web a přihlásil se tam, nástroj pro vyrovnávání zatížení mě přesměruje například na Server1, zapamatuje si mě tam a při příštím kliknutí budu znovu přesměrován na Server1. To vše se mi děje zcela transparentně.
Ale co když se Server1 zhroutil? Přirozeně dojde ke ztrátě všech dat relace a budu se muset znovu přihlásit na novém serveru. To je pro uživatele velmi nepříjemné. Navíc se jedná o další zatížení nástroje pro vyrovnávání zatížení: nejenže bude muset přesměrovat tisíce lidí na jiné servery, ale také si pamatovat, kam je přesměroval.
To se stává dalším úzkým hrdlem. Co když selže samotný vyvažovač zatížení a všechny informace o umístění klientů na serverech se ztratí? Kdo bude řídit vyvážení? Je to složitá situace, že?
Místní sdílení dat
Sdílení dat relace v rámci clusteru se rozhodně jeví jako dobré řešení, ale vyžaduje změny v architektuře aplikace, i když to stojí za to, protože úzké hrdlo se rozšiřuje. Selhání jednoho serveru přestává mít fatální dopad na celý systém.
Je známo, že data relace jsou uložena v superglobálním PHP poli $_SESSION . Také není žádným tajemstvím, že toto pole $_SESSION je uloženo na pevném disku.
Vzhledem k tomu, že disk patří jednomu nebo druhému počítači, ostatní k němu nemají přístup. Jak tedy můžete uspořádat sdílený přístup k němu pro několik počítačů?
Všimněte si, že obslužné nástroje relací v PHP lze přepsat – můžete definovat svou vlastní třídu/funkci pro správu relací.
Použití databáze
Pomocí našeho vlastního obslužného programu relace si můžeme být jisti, že všechny informace o relaci jsou uloženy v databázi. Databáze musí být na samostatném serveru (nebo ve vlastním clusteru). V tomto případě budou rovnoměrně zatížené servery zpracovávat pouze obchodní logiku.
I když tento přístup funguje docela dobře, pokud je velký provoz, databáze se nejen stane zranitelnou (pokud ji ztratíte, ztratíte vše), ale bude podléhat velkému množství přístupu kvůli nutnosti zapisovat a číst relaci. data.
To se stává dalším úzkým hrdlem v našem systému. V tomto případě můžete použít škálování šířky, což je problematické při používání tradičních databází jako MySQL, Postgre a podobně (tomuto problému se budeme věnovat ve druhém díle seriálu).
Použití sdíleného systému souborů
Můžete nastavit síťový souborový systém, ke kterému budou přistupovat všechny servery a pracovat s daty relace. To bys neměl dělat. Jedná se o zcela neefektivní přístup s vysokou pravděpodobností ztráty dat a celé to funguje velmi pomalu.
To je další potenciální nebezpečí, ještě nebezpečnější než výše popsaný případ databáze. Aktivace sdíleného souborového systému je velmi jednoduchá: změňte hodnotu session.save_path v souboru php.ini, ale důrazně se doporučuje použít jinou metodu.
Pokud stále chcete implementovat možnost sdíleného souborového systému, pak existuje mnohem lepší řešení - GlusterFS.
Memcached
Memcached můžete použít k ukládání dat relace do RAM. Toto je velmi nebezpečná metoda, protože data relace budou přepsána, jakmile dojde volné místo na disku.
Neexistuje žádná perzistence - přihlašovací údaje budou uloženy tak dlouho, dokud bude server memcached spuštěn a bude k dispozici volné místo pro uložení těchto dat.
Možná se ptáte – není RAM specifická pro každý stroj? Jak aplikovat tuto metodu na cluster? Memcached má schopnost virtuálně kombinovat veškerou dostupnou RAM více strojů do jediného úložiště:
Čím více počítačů máte, tím větší je velikost vytvořeného sdíleného úložiště. Paměť v rámci úložiště nemusíte přidělovat ručně, ale můžete proces řídit určením, kolik paměti lze přidělit z každého počítače, aby se vytvořil sdílený prostor.
Potřebné množství paměti tak zůstává k dispozici počítačům pro jejich vlastní potřeby. Zbytek se používá k ukládání dat relace pro celý cluster.
Kromě relací může mezipaměť obsahovat také jakákoli další data, která si přejete, hlavní věc je, že je dostatek volného místa. Memcached je skvělé řešení, které se stalo široce používaným.
Použití této metody v aplikacích PHP je velmi snadné: stačí změnit hodnotu v souboru php.ini:
session.save_handler = memcache session.save_path = "tcp://path.to.memcached.server:port"
Cluster Redis
Redis je jiné než SQL úložiště dat v paměti jako Memcached, ale je trvalé a podporuje složitější datové typy než jen řetězce PHP pole ve formě párů „klíč => hodnota“.
Toto řešení nepodporuje clustery, takže implementace do horizontálního škálovacího systému není tak jednoduchá, jak by se na první pohled mohlo zdát, ale je docela proveditelná. Ve skutečnosti je již k dispozici alfa verze clusterové verze a můžete ji používat.
Ve srovnání s řešeními, jako je Memcached, je Redis kříženec mezi běžnou databází a Memcached.
Vertikální škálování— škálování — zvýšení počtu zdrojů dostupných pro software zvýšením výkonu využívaného servery.
— škálování — zvýšení počtu uzlů sloučených do serverového clusteru, když je nedostatek CPU, paměti nebo místa na disku.
Oba jsou infrastrukturní řešení, která jsou vyžadována v různých situacích, kdy webový projekt roste.
Vertikální a horizontální škálování, škálování pro web
Zvažte například databázové servery. U velkých aplikací je to vždy nejvíce zatěžovaná součást systému.
Možnosti škálování pro databázové servery jsou dány použitými softwarovými řešeními: nejčastěji se jedná o relační databáze (MySQL, Postgresql) popř. NoSQL(Casandra atd.).
Horizontální škálování pro databázové servery při velkém zatížení je mnohem levnější
Webový projekt se obvykle spouští na jednom serveru, jehož zdroje s růstem docházejí. V takové situaci jsou 2 možnosti:
- přesunout web na výkonnější server
- přidat další server s nízkou spotřebou a sloučit počítače do clusteru
MySQL je nejoblíbenější RDBMS a jako každý z nich vyžaduje mnoho serverových prostředků, aby mohl běžet pod zatížením. Škálování je možné hlavně směrem nahoru. Existuje sharding (jehož konfigurace vyžaduje změny kódu) a sharding, které může být obtížné podporovat.
Vertikální škálování
NoSQL se snadno škáluje a druhá možnost například s MongoDB bude finančně mnohem výnosnější a nebude vyžadovat pracné nastavování a podporu výsledného řešení. Sdílení probíhá automaticky.
S MySQL tedy budete potřebovat server s velkým množstvím CPU a RAM, takové servery mají značné náklady.
Horizontální škálování
S MongoDB můžete přidat další střední server a výsledné řešení bude fungovat stabilně a poskytne další odolnost proti chybám. 
Škálování nebo je přirozenou fází rozvoje infrastruktury. Každý server má omezení, a když se jich dosáhne nebo když se náklady na výkonnější server ukáží jako nepřiměřeně vysoké, přidají se nové stroje. Zatížení je rozloženo mezi ně. Poskytuje také odolnost proti chybám.
Středně velké servery a nastavování clusterů byste měli začít přidávat, když jsou vyčerpány možnosti navýšení zdrojů jednoho stroje nebo když se nákup výkonnějšího serveru ukáže jako nerentabilní.
Uvedený příklad s relačními databázemi a NoSQL je situace, která se vyskytuje nejčastěji. Frontend a backend servery jsou také škálovatelné.
Přečtěte si o tématu Balancér
Do konce roku 2012 bylo virtualizováno více než 50 % aplikací běžících na platformě x86. Pouze 20 % kriticky důležitých aplikací je však virtualizováno.
Je to proto, že IT oddělení nedůvěřují virtualizačním platformám? Mají pocit, že virtualizační platformy nejsou dostatečně stabilní, aby podporovaly kritické aplikace?
Za posledních 10 let VMware prokázalo, že virtualizace je realitou a ve skutečnosti jsou virtualizované aplikace často stabilnější, když běží na infrastruktuře spravované VMware.
Pokud tedy důvěra nebo stabilita není problém, jaký je důvod, proč IT oddělení dosud nevirtualizovala zbývající aplikace?
Škálování
Škálování nebo horizontální škálování – přidávání nových zdrojů do infrastruktury, například serverů v clusteru.
Vzhledem k tomu, že ceny stále klesají a výkon stále roste, jsou levné, komoditní servery ideálním řešením pro horizontální škálování a lze je sestavit do velkých clusterů pro sdílení výpočetních zdrojů.
Posledních sedm let se architekti infrastruktury VMware modlili za horizontální škálování. Někteří mohou argumentovat pro použití tohoto konkrétního přístupu, ale má také své vlastní nuance a vše závisí na obchodních požadavcích. Výhodou horizontálního škálování je, že komoditní servery jsou levné a pokud server selže, ovlivní to malý počet virtuálních počítačů. Nevýhodou jsou vyšší náklady na licence pro vSphere, velké požadavky na prostor datového centra a obvykle takovéto komoditní servery nemají velké výpočetní zdroje.
Zvýšit
Vertikální škálování je přidání výpočetních prostředků k již používanému serveru. Obvykle se jedná o procesory nebo RAM.
Obvykle jsou takové servery poměrně výkonné - s podporou 4 procesorů a 512 GB paměti. Kromě toho existují systémy s 8 procesory a 1 TB paměti a některé mají to štěstí, že vidí i 16procesorové servery se 4 TB paměti. A ne, to nejsou mainframy ani nic podobného, to jsou servery založené na klasické x86 architektuře.
Přechod na druhou vlnu virtualizace, která poskytuje flexibilitu, kterou tato technologie poskytuje pro kritické obchodní aplikace, vyvíjí obrovský tlak na dnes používané infrastruktury VMware kvůli následujícím problémům:
- Nedostatečné možnosti škálování. Výpočetně náročné pracovní zátěže jsou výzvou kvůli omezenému množství zdrojů dostupných u nízkonákladových komoditních serverů.
- Nedostatečná spolehlivost. Komoditní zařízení nebo hardware využívající takové komponenty mohou být méně spolehlivé. Problém spolehlivosti lze vyřešit pomocí funkcí, které proberu v následujících článcích.
- Rostoucí složitost řízení a rostoucí provozní náklady. Je snazší spravovat 100 serverů, ne 1000, a v důsledku toho je 10 serverů snazší spravovat než 100. Totéž platí pro provozní náklady – údržba 10 serverů je mnohem levnější než 100.
S vydáním vSphere 5 se počet zdrojů dostupných pro jeden virtuální počítač čtyřnásobně zvýšil.
A s vydáním vSphere 5.1 se monstrózní virtuální počítače mohou stát ještě monstróznějšími.
Aby mohla vSphere 5.1 spustit monstrum VM, plánovač musí mít a naplánovat běh vláken na 64 fyzických procesorech. Není mnoho serverů, které mohou podporovat tolik jader, a je ještě méně serverů, které podporují 16 soketů a 160 jader.
Existují dva typy serverového vertikálního škálování: bez lepidla a lepené. Tato slova se do ruštiny překládají takto: bez integrujících technologií a s integrujícími technologiemi, resp.
Architektura bez lepidla
Tato architektura byla vyvinuta společností Intel a představena v Intel Xeon E7.
Pro komunikaci mezi I/O zařízeními, síťovými rozhraními a procesory se používá speciálně navržená sběrnice QPI.
V serverech se 4 procesory jsou všechny připojeny přímo k sobě prostřednictvím této sběrnice. Procesor Glueless používá jeden z kanálů k připojení procesoru k I/O rozhraním a další tři k připojení k sousedním procesorům.
V 8procesorovém serveru je každý procesor přímo připojen ke třem sousedním a prostřednictvím dalšího procesoru k dalším čtyřem.
Výhody této architektury:
- Není potřeba speciální vývoj nebo specializace ze strany výrobce serveru
- Každý výrobce serverů může vyrábět 8procesorové servery
- Sníží se náklady na servery se 4 i 8 procesory
- Celkové náklady na vlastnictví se zvyšují s tím, jak škálujete
- Architektura je omezena na 8 procesorových serverů
- Je obtížné udržet integritu mezipaměti, protože počet soketů se zvyšuje
- Nelineární růst produktivity
- Poměr cena výkon klesá
- Suboptimální výkon při použití velkých virtuálních počítačů
- Až 65 % šířky pásma sběrnice je vynaloženo na chatové vysílání protokolu QPI
Hlavní aplikace, jejichž výkon trpí nedostatky protokolu QPI, jsou Java aplikace, velké databáze a aplikace citlivé na latenci.
Výsledkem vertikálního škálování musí být, že neexistuje žádné úzké hrdlo, jinak architektura ztrácí smysl. Linearita růstu produktivity tedy musí odpovídat linearitě přírůstků zdrojů.
Lepená architektura
K vyřešení výše popsaných problémů vyvinuli vývojáři hardwaru lepenou architekturu. Tato architektura využívá externí řadič uzlu pro organizaci propojení QPI ostrovů - procesorových clusterů.
Intel QPI nabízí speciální škálovatelné řešení – eXternal Node-Controllers (nebo XNC), jehož praktickou implementaci vyvíjejí OEM společnosti třetích stran. Externí uzlový řadič, používaný počínaje Intel Xeon E7-4800, s vestavěným paměťovým řadičem, obsahuje také systém Cache Coherent Non-Uniform Memory Access (ccNUMA), jehož úkolem je sledovat relevanci dat. v každém řádku mezipaměti procesoru.
Latence mezi procesorem a pamětí v ccNUMA závisí na vzájemném umístění dvou komponent, což má za následek, že se řadiče XNC stávají kritickou komponentou serveru a jen velmi málo výrobců serverů je schopno navrhovat servery, které lze škálovat.
