Domov › Nastavení › Horizontální a vertikální škálování. Pohled z podnikových aplikací. Horizontální škálování databázových serverů pro OLTP systémy nebo co je na trhu

Horizontální a vertikální škálování. Pohled z podnikových aplikací. Horizontální škálování databázových serverů pro OLTP systémy nebo co je na trhu

Oleg Spiryaev

V poslední době se často objevují tvrzení, že servery střední a vyšší třídy jsou aktivně nahrazovány skupinami serverů základní úrovně, sdruženými do racků nebo clusterů. Někteří odborníci však nesouhlasí. Podle Dataquestu se tedy podíl modelů s cenou 500 tisíc dolarů a vyšší (včetně serverů střední třídy a vyšší třídy SMP) na celkových prodejích serverů od roku 2000 do roku 2002 zvýšil z 38 na 52 %.

Další data získaná IDC naznačují růst (alespoň co do počtu strojů) v sektoru low-end modelů serverů - se dvěma procesory. IDC také předpovídá, že v roce 2005 bude nejběžnějším operačním systémem pro servery s cenou mezi 50 000 a 3 miliony USD Unix. Z porovnání těchto dat je jasné, že převládající platformou pro datová centra zůstanou unixové servery střední a vyšší třídy, ale budou doplněny rostoucím počtem menších (obvykle dvouprocesorových) serverů.

Tento trend se objevil v důsledku oddělení různých vrstev výpočetní techniky v datových centrech (obr. 1). Tier 1, neboli přední vrstva, se postupně posouvá na zmenšený model malých serverů, zatímco na vrstvě 3 (databázová vrstva) dominují scale-up servery. Vrstva 2 (aplikační vrstva) se stává oblastí, kde koexistují vertikální a horizontální architektury.

Vertikální a horizontální architektury

Podívejme se na hlavní rozdíly mezi vertikální a horizontální architekturou. Škálovatelné servery jsou velké systémy SMP (symetrický multiprocesing nebo sdílená paměť) s více než čtyřmi centrálními procesorovými jednotkami. Používají pouze jednu kopii operačního systému k ovládání všech procesorů, paměti a I/O komponent. Obvykle jsou všechny tyto zdroje umístěny v jednom stojanu nebo skříni. Tyto servery se propojují přes vysokorychlostní centrální nebo backplane s nízkou latencí a koherentním přístupem. Prostředky můžete přidat instalací dalších systémových desek uvnitř skříně. V systémech vertikální architektury (nebo SMP systémech) je paměť sdílená, což znamená, že všechny procesory a I/O komponenty mají přístup k veškeré paměti. Uživatel „vidí“ paměť jako jeden velký objekt.

Alternativně, horizontální škálování, jsou systémy propojeny prostřednictvím sítě nebo klastrovány dohromady. Propojení obvykle využívají standardní síťové technologie, jako je Fast Ethernet, Gigabit Ethernet (GBE) a Scalable Coherent Interconnect (SCI), které nabízejí nižší propustnost a vyšší latenci než vertikální systémy. Prostředky jsou v tomto případě rozděleny mezi uzly, obvykle obsahující jeden až čtyři procesory; Každý uzel má svůj vlastní procesor a paměť a může mít svůj vlastní I/O subsystém nebo jej sdílet s jinými uzly. Každý uzel provozuje samostatnou kopii operačního systému. Prostředky se rozšiřují přidáním uzlů, ale nikoli přidáním prostředků do uzlu. Paměť v horizontálních systémech je distribuovaná, to znamená, že každý uzel má svou vlastní paměť, ke které přímo přistupují jeho procesory a I/O subsystém. Přístup k těmto prostředkům z jiného uzlu je mnohem pomalejší než z uzlu, kde se nacházejí. Navíc s horizontální architekturou neexistuje konzistentní přístup mezi uzly do paměti a používané aplikace spotřebovávají relativně málo zdrojů, takže se „vejdou“ na jeden uzel a nepotřebují konzistentní přístup. Pokud aplikace vyžaduje více uzlů, musí sama poskytovat konzistentní přístup k paměti.

Pokud horizontální systém splňuje požadavky aplikace, pak je tato architektura výhodnější, protože její pořizovací náklady jsou nižší. Obvykle jsou pořizovací náklady na procesor pro horizontální systémy nižší než pro vertikální systémy. Rozdíl v ceně je způsoben tím, že vertikální systémy využívají výkonnější funkce RAS (reliability, dostupnosti, serviceability) a také vysoce výkonná propojení. Existuje však řada omezení pro použití systémů s horizontální architekturou. Níže probereme, za jakých podmínek lze horizontální systémy použít a kdy je nutné vertikální škálování.

Vertikální architektura zahrnuje kromě jednoho velkého SMP serveru také clustery velkých SMP serverů používaných pro jednu rozsáhlou aplikaci.

Příkladem horizontálních serverů jsou nedávno uvedené modulární nebo blade servery na trhu, obvykle vybavené jedním nebo dvěma procesory. Zde se cluster skládá z malých uzlů, z nichž každý má SMP server základní úrovně s počtem centrálních procesorů od 1 do 4.

Dalším způsobem, jak škálovat, jsou velké systémy MPP (Massive Parallel Computing), které se skládají z mnoha malých procesorů nainstalovaných v jediné skříni, z nichž každý má svou vlastní kopii operačního systému nebo kopii mikrojádra operačního systému. V současné době se vyrábí pouze několik MPP systémů, které nejčastěji představují specializovaná řešení. Jedná se například o systémy Terradata vyráběné NCR, IBM RS/6000SP (SP-2) a HP Tandem nonstop.

Tabulka 1. Vlastnosti vertikální a horizontální architektury

Parametr	Vertikální systémy	Horizontální systémy
Paměť	Velké sdílené	Malý oddaný
Proudy	Mnoho vzájemně závislých vláken	Mnoho nezávislých vláken
Propojení	Pevně spojený vnitřní	Volně připojené externí
RAS	Výkonný systém RAS single	Výkonný RAS využívající replikaci
Centrální procesorové jednotky	Mnoho standardních	Mnoho standardních
OS	Jedna kopie operačního systému pro mnoho centrálních procesorů	Několik kopií operačního systému (jedna kopie pro 1-4 procesory)
Rozložení	V jedné skříni	Umístění velkého počtu serverů do racku
Hustota		Vysoká hustota procesoru na jednotku podlahové plochy
Zařízení	Standardní a speciálně navržené	Standard
Měřítko	V rámci jednoho šasi serveru	V měřítku více serverů
Rozšíření	Instalací dalších komponent na server	Přidáním nových uzlů
Architektura	64bitový	32- a 64-bit

Stůl 1 umožňuje srovnávací analýzu vertikální a horizontální architektury.

Vertikální systémy sdílejí paměť a poskytují konzistentní přístup k vyrovnávací paměti.
Vertikální systémy jsou ideální pro toky úkolů, které spolu potřebují komunikovat.
Vertikální systémy se vyznačují výkonnými funkcemi RAS a v horizontálních systémech je dostupnost implementována pomocí masivní replikace (do clusteru je připojeno několik uzlů, takže výpadek jednoho z nich má malý dopad na chod celého systému).
Ve vertikálních systémech pokrývá jedna kopie operačního systému všechny zdroje. Některé vertikální systémy, jako jsou midframe a high-end servery Sun Microsystems (Sun Fire 4800 až Sun Fire 15K), lze rozdělit na menší vertikální servery.
Vertikální systémy využívají co nejvíce standardních komponent, ale některé klíčové komponenty (např. propojení) jsou speciálně navrženy.
Vertikální systémy lze rozšířit instalací dalších komponent do stávajícího rámce (výkonnější procesory, přídavná paměť, přídavná a výkonnější I/O připojení atd.). Horizontální systémy se rozšiřují přidáním uzlu nebo nahrazením starých uzlů novými.
Téměř všechny vertikální systémy jsou 64bitové, zatímco horizontální systémy mohou být 32bitové nebo 64bitové.

Vertikální systémy jsou vhodnější pro některé typy aplikací a horizontální systémy pro jiné, ale v mnoha případech závisí optimální volba architektury na velikosti problému. V tabulce 2 ukazuje příklady aplikací, pro které je optimální vertikální nebo horizontální architektura.

Tabulka 2. Typy aplikací pro vertikální a horizontální architektury

Malé a modulární servery se dobře hodí pro aplikace, které jsou bezstavové, mají malý rozsah a snadno se replikují. A pro aplikace, které využívají stavové informace a velké objemy dat, které vyžadují intenzivní přenos dat v rámci systému, jsou vertikální servery ideálním řešením. Na trhu vysoce výkonných technických výpočtů (HPTC) existuje mnoho aplikací, ve kterých jsou vlákna na sobě závislá a vyměňují si data. Existují také aplikace, které vyžadují velké množství sdílené paměti. Pro tyto dva typy aplikací jsou nejvhodnější velké servery SMP. Existují však také aplikace HPTC, ve kterých jsou spouštěcí vlákna nezávislá a nevyžadují velké množství sdílené paměti. Takové aplikace mohou být rozděleny, takže clustery malých serverů jsou ideální pro jejich provozování. Podobně jsou některé komerční aplikace rozdělené a těží z horizontálních serverů, zatímco jiné nelze rozdělit, takže vertikální servery jsou pro ně nejlepší platformou.

Faktory ovlivňující výkon

Všechna velká datová centra jsou paralelní počítače. Zde lze i clustery považovat za zvláštní typ paralelních systémů. Vysoký výkon vyžaduje vyvážený systém s výkonnými procesory, vysokorychlostním propojením a I/O, škálovatelným operačním systémem, optimalizovanými aplikacemi a pokročilými funkcemi RAS.

Procesory a systémové propojení

Procesory jsou jistě nezbytnou součástí, ale pouze částečně určují celkový výkon systému. Důležitější je zajistit, aby procesory běžely na maximální kapacitu. Výkonný procesor, který je zatížen pouze z 50 %, bude fungovat hůře než pomalejší procesor, který je zatížen z 80 %.

Navíc s rostoucím počtem procesorů v paralelním systému se do popředí dostává spíše propojení systému než výkon procesoru. Jsou zodpovědné za přesun dat z disku, z paměti a ze sítě do procesoru. V clusteru je propojením síťové připojení, jako je Fast Ethernet nebo Gigabit Ethernet. Cluster propojuje přesun dat mezi uzly, zatímco systém propojuje přesun dat v rámci jednoho systému. Pokud je propojení příliš pomalé, bude procesor nečinně čekat na data.

Systémová propojení se také používají k přesunu datových adres, což je nezbytné pro podporu koherence mezipaměti. Pokud je propojení systému příliš pomalé při přenosu datových adres, bude procesor opět nečinně čekat na data, protože pro přístup k nim potřebuje znát svou adresu. Rychlá propojení poskytují vysokou propustnost a nízkou latenci (nízká doba od podání požadavku na data do zahájení přenosu dat).

Hlavním technickým rozdílem mezi horizontálními a vertikálními systémy je propustnost a latence jejich propojení. Pro propojení clusterů se propustnost může pohybovat od 125 MB/s pro Fast Ethernet do 200 MB/s pro SCI a latence se může pohybovat od 100 tisíc ns pro GBE a až 10 tisíc ns pro SCI. Pomocí rozhraní InfiniBand je možné implementovat rychlejší propojení se špičkovými rychlostmi od cca 250 MB/s pro první verzi a až 3 GB/s pro následující.

Vstup a výstup

Rychlý I/O je nutný, aby propojení mohlo rychle načíst data z disku a sítě a přenést je do procesorů. Úzké místo v I/O subsystému může negativně ovlivnit výkon i těch nejrychlejších propojení a procesorů.

operační systém

I ten nejlepší hardware je neúčinný, pokud OS není dostatečně škálovatelný. U horizontálních systémů není škálovatelnost OS tak důležitá, protože na jednom uzlu nebo se samostatnou kopií OS neběží více než čtyři procesory.

Dostupnost systému

Obecně řečeno, dostupnost systému do značné míry závisí na typu architektury. Ve velkých systémech SMP je funkce RAS zabudována do systému a doplněna o převzetí služeb při selhání pro dva až čtyři uzly. V horizontálních systémech je RAS jednotlivých uzlů horší, ale zlepšení těchto funkcí je dosaženo vícenásobnou replikací uzlů.

Optimalizované aplikace

Aplikace musí být optimalizovány pro architekturu výpočetního systému. Nejjednodušší je psát a optimalizovat aplikace pro SMP systémy. Velké komerční aplikace jsou optimalizovány speciálně pro SMP systémy a byly na nich dokonce vyvíjeny, a proto SMP dominují na trhu se systémy střední a vyšší třídy posledních deset let.

Velikost aplikace

Jak bylo uvedeno, velké systémy SMP používají vysokorychlostní propojení k zajištění dostatečného výkonu systému. Horizontální systémy mohou mít problémy s výkonem kvůli nízké propustnosti a vysoké latenci propojení v případech, kdy je potřeba často přenášet data mezi uzly. Některé aplikace však k dosažení vysokého výkonu nevyžadují vysoké rychlosti propojení – obvykle malé aplikace a aplikace, které lze snadno replikovat (například webové servery, proxy, firewally a malé aplikační servery). V takových horizontálních systémech každý uzel vykonává malý úkol nezávisle na práci všech ostatních.

Například v horizontální (neboli distribuované paměti) architektuře mohou čtyři procesorové uzly (každý se samostatnou RAM a vyhrazeným nebo sdíleným I/O subsystémem) používat síťové propojení, jako je Gigabit Ethernet. Toto výpočetní prostředí spouští tři typy úloh. Nejmenší zatížení se vejde na jeden uzel, ale jak se zvyšuje, je k jeho dokončení zapotřebí několik uzlů. Podle odborníků se při provádění jednoho úkolu na více uzlech výkon výrazně zhoršuje kvůli pomalému propojení mezi uzly. Malé úlohy, které spolu nepotřebují komunikovat, fungují dobře s horizontální architekturou, ale provozování velkých úloh na ní představuje výzvy.

Velká konfigurace systému SMP může zahrnovat například až 100 procesorů, 576 GB sdílené paměti a vysokorychlostní propojení. Takový systém zvládne všechny typy pracovních zátěží, protože neexistuje žádná komunikace mezi uzly a efektivní komunikace mezi procesy. Všechny centrální procesorové jednotky mohou současně přistupovat ke všem diskům, veškeré paměti a síťovým připojením – to je klíčová vlastnost SMP systémů (neboli vertikálních systémů).

Často vyvstává otázka o vhodnosti umístění malých nákladů na velké SMP. Ačkoli je to technicky možné, z ekonomického hlediska není tento přístup opodstatněný. U velkých SMP jsou pořizovací náklady na procesor vyšší než u malých systémů. Pokud tedy aplikace může běžet na malém uzlu (nebo několika malých uzlech) bez větších problémů se správou, je lepší volbou pro nasazení škálování. Pokud je však aplikace příliš velká na to, aby běžela na malém uzlu (nebo na několika takových uzlech), pak bude velký SMP server nejlepší volbou z hlediska výkonu i správy systému.

Výkon na úrovni databáze

Hlavní otázkou je zde porovnat výkon jednotlivých středních a velkých SMP serverů s clusterem malých serverů (ne více než čtyři procesory).

Při diskusi o škálovatelnosti používají výrobní společnosti řadu odborných termínů. Růst výkonu (Speedup) pro SMP je tedy definován jako poměr rychlostí spouštění aplikací na několika procesorech a na jednom. Lineární zrychlení například znamená, že na 40 procesorech běží aplikace 40x (40x) rychleji než na jednom. Nárůst výkonu není závislý na počtu procesorů, tj. pro konfiguraci 24 procesorů to bude stejné jako pro 48 procesorů. Nárůst výkonu clusteru (Cluster speedup) se liší pouze tím, že při jeho výpočtu se bere počet uzlů, nikoli počet procesorů. Stejně jako růst výkonu SMP zůstává růst výkonu clusteru konstantní napříč různými počty uzlů.

Účinnost škálování charakterizuje schopnost aplikací, zejména klastrových, škálovat přes velký počet uzlů. Obecně se má za to, že účinnost škálování závisí na počtu uzlů účastnících se měření. Efektivita škálování SMP je zvýšení výkonu děleno počtem procesorů a účinnost klastru je zvýšení výkonu klastru děleno počtem uzlů v něm. Musíte pochopit, co tyto parametry znamenají, abyste nezískali špatný obrázek, protože 90% účinnost škálování na dvou uzlech není totéž jako 90% účinnost škálování na čtyřech uzlech.

Na Obr. Obrázek 2 ukazuje tři grafy: ideální lineární škálovatelnost, škálovatelnost 24procesorového SMP serveru na 95 % a škálovatelnost clusteru dvou 4procesorových serverů na 90 %. Je vidět, že existují určitá omezení škálovatelnosti databází v clusterech (s horizontálním škálováním). Spojení mnoha malých serverů dohromady neposkytuje škálovatelnost potřebnou pro střední až velké aplikace. Důvodem je omezení šířky pásma propojení v rámci klastru, další zátěž databázového softwaru spojená se správou klastrů a obtížnost psaní aplikací pro prostředí klastrů s distribuovanou pamětí.

Zveřejněné výsledky benchmarku například ukazují, že Oracle9i RAC (Real Application Cluster) má nárůst výkonu o 1,8 a efektivitu škálování 90 %. Tato efektivita škálovatelnosti se může zdát poměrně vysoká, ale ve skutečnosti je škálovatelnost 90 % pro čtyři uzly ve srovnání s výsledky velkých SMP serverů neúčinná.

Výkon na úrovni aplikace

Aplikační vrstva ve třívrstvém datovém centru je velmi odlišná od databázové vrstvy. Aplikace na této úrovni jsou obvykle bezstavové – jinými slovy, na samotném serveru nejsou uložena žádná data nebo je uložena pouze jejich malá část. Tato vrstva obsahuje obchodní pravidla pro aplikační služby. Transakce přicházejí na aplikační úroveň a jsou jí zpracovávány. Když je potřeba data zapsat nebo přečíst, transakce jsou předány do databázové vrstvy. Aplikační servery mají tendenci konsolidovat databázová připojení, protože velký počet připojení má negativní dopad na výkon.

Ve většině případů vyžaduje vrstva aplikačního serveru mnohem více procesorů než vrstva databáze na jednotlivé aplikační služby. Například v případě SAP R/3 je tento poměr přibližně 10 procesorů na každý databázový procesor, tj. pokud SAP R/3 vyžaduje 20 procesorů pro databázovou vrstvu, pak by pro aplikační vrstvu mělo být přibližně 200 procesorů. Otázkou je, co je výhodnější nasadit – 100 dvouprocesorových serverů nebo deset 20procesorových serverů. Podobně v Oracle je poměr aplikačních procesorů k databázovým procesorům přibližně 5 ku 1.

Předpokládá se, že aplikační servery nemusí být distribuovány přes více uzlů. Více kopií aplikačního softwaru lze distribuovat mezi různé fyzické servery různých kapacit nebo přes dynamické domény velkých serverů.

Počet procesorů potřebných pro aplikační vrstvu bude přibližně stejný bez ohledu na architekturu počítače. Náklady na nákup hardwaru a softwaru pro horizontální architekturu budou nižší, protože náklady na procesor jsou v tomto případě nižší. Ve většině případů mohou horizontální systémy poskytovat výkon požadovaný pro splnění dohody o úrovni služeb. Náklady spojené s nákupem softwarových licencí jsou pro obě architektury přibližně stejné.

Zároveň mohou být vyšší náklady na správu a údržbu infrastruktury pro horizontální architekturu. Při nasazení na horizontálních systémech se používá více kopií operačního systému a softwaru aplikačního serveru. Náklady na údržbu infrastruktury obvykle rostou úměrně s počtem kopií OS a aplikací. S horizontální architekturou se navíc zálohování a obnova po havárii decentralizují a správa síťové infrastruktury je obtížnější.

Náklady na správu systému je obtížné měřit. Modely porovnávající horizontální a vertikální nasazení aplikačních serverů obvykle ukazují, že správa menšího počtu výkonnějších serverů (vertikálních serverů) je levnější než správa mnoha menších serverů. Obecně platí, že při výběru typu architektury pro nasazení aplikační vrstvy by IT manažeři měli pečlivě zvážit náklady na pořízení hardwaru.

Vliv architektury na dostupnost

Dostupnost je pro moderní datová centra zásadní – aplikační služby musí být dostupné 24x7x365 (24 hodin denně, 7 dní v týdnu, 365 dní v roce). V závislosti na potřebách konkrétního datového centra se používají různá schémata vysoké dostupnosti. Pro výběr konkrétního řešení je nutné stanovit přijatelné prostoje (plánované i neplánované). Na Obr. Obrázek 3 ukazuje, jak procento dostupnosti ovlivňuje dobu odstávky.

S rostoucími požadavky na dostupnost rostou i náklady na řešení. Manažeři datových center musí určit, jaká kombinace nákladů, složitosti a dostupnosti nejlépe vyhovuje požadavkům na úroveň služeb. Datová centra, která vyžadují přibližně 99,95% dostupnost, mohou nasadit jediný server SMP s funkcemi RAS, jako je plná redundance hardwaru a online údržba.

K dosažení dostupnosti vyšší než 99,95 % však bude vyžadován cluster. Software Sun Cluster s HA (High Availability) failover poskytuje 99,975% dostupnost. HA převzetí služeb při selhání používá primární server a pohotovostní režim; Pokud primární server selže, převezme jeho zátěž záložní server. Doba potřebná k restartování služby se liší podle aplikace a může trvat několik minut, zejména u databázových aplikací, které k obnovení transakcí vyžadují velká data náročná vrácení zpět.

Pokud je pro datové centrum několikaminutový výpadek nepřijatelný, řešením může být systém active-active, kdy je aplikace nasazena na dvou nebo více uzlech, takže pokud jeden z nich selže, ostatní budou aplikaci nadále provozovat. Díky tomu bude výpadek velmi krátký (někteří klienti uvádějí, že trvá méně než 1 minutu), někdy si uživatel výpadku uzlu ani nemusí všimnout.

Vertikální servery poskytují vysokou dostupnost díky vestavění mnoha funkcí RAS do jediného serveru, aby se minimalizovaly plánované i neplánované prostoje. V horizontálních serverech nejsou funkce, které poskytují vysokou úroveň RAS, implementovány na úrovni jednotlivého serveru, ale prostřednictvím duplikace a umístění několika serverů. Kvůli různým implementacím funkcí RAS a propojení jsou horizontální servery obvykle levnější na procesor.

Pro třívrstvou architekturu je dobrým příkladem horizontální vysoké dostupnosti nasazení webových serverů. Můžete nasadit mnoho malých serverů, každý s nainstalovanou samostatnou kopií softwaru webového serveru. Pokud dojde k výpadku jednoho webového serveru, jeho transakce se přerozdělí mezi zbývající zdravé servery. V případě aplikačních serverů mohou být hostovány na horizontálních i vertikálních serverech a vysoké dostupnosti je dosaženo díky redundanci. Bez ohledu na to, zda nasazujete několik velkých serverů SMP nebo mnoho menších, redundance zůstává primárním způsobem, jak dosáhnout vysokého RAS na aplikační úrovni.

Na úrovni databáze se však situace mění. Databáze jsou stavové a ze své podstaty vyžadují ve většině případů, aby byla data rozdělena a přístupná ze všech procesorů/uzlů. To znamená, že pro vysokou dostupnost s redundancí je třeba použít klastrovací software, jako je Sun Cluster nebo Oracle9i RAC (pro velmi vysokou dostupnost).

závěry

Vertikální i horizontální architektura má v dnešních datových centrech své místo. Zatímco dnešní zaměření je na nové technologie, jako jsou modulární servery a paralelní databáze, na trhu zůstává vysoká poptávka po serverech střední a vyšší třídy.

Vertikální a horizontální systémy mohou používat stejný software, OS a dokonce stejné procesory. Hlavním rozdílem, který ovlivňuje cenu a výkon, jsou propojení použitá v každé architektuře. Horizontální servery používají volně propojená externí propojení, zatímco vertikální servery používají těsně propojená propojení, která poskytují vyšší rychlosti přenosu dat.

Pro frontend poskytují horizontální servery obvykle optimální řešení z hlediska výkonu, celkových pořizovacích nákladů a dostupnosti. Pro aplikační vrstvu lze efektivně využít vertikální i horizontální architektury. Pro databázovou vrstvu je optimálním řešením použití vertikálních serverů bez ohledu na požadovanou úroveň dostupnosti.

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 mezi sebou úlohu automaticky sdílejí. V tomto případě se propustnost vašeho webu ve srovnání s vertikálním měřítkem 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ě úkol 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 ve 2. části 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ě budou ztracena všechna data 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í zátěže: bude muset nejen 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 jediný load balancer 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

Použitím 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 jednoho ú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.

) Ahoj! Jsem Alexander Makarov a můžete mě znát z frameworku Yii – jsem jedním z jeho vývojářů. Mám také práci na plný úvazek – a to už není startup – Stay.com, která se zabývá cestováním.

Dnes budu mluvit o horizontálním škálování, ale velmi, velmi obecně.

Co je to vlastně škálování? To je příležitost ke zvýšení produktivity projektu v minimálním čase přidáním zdrojů.

Škálování obvykle nezahrnuje přepisování kódu, ale buď přidávání serverů, nebo navyšování zdrojů stávajícího. Tento typ zahrnuje vertikální a horizontální měřítko.

Vertikální je, když se přidá více RAM, disků atd. na již existujícím serveru a horizontální je, když do datových center umístí více serverů a servery tam již nějak interagují.

Nejúžasnější otázka, kterou si kladou, je: proč je to potřeba, když mi na jednom serveru vše funguje dobře? Ve skutečnosti musíme zkontrolovat, co se stane. To znamená, že to nyní funguje, ale co bude později? Existují dva skvělé nástroje - ab a siege, které, jak se zdá, dohánějí mrak konkurenčních uživatelů, kteří začnou bušit server, zkoušet si vyžádat stránky, posílat nějaké požadavky. Musíte jim říct, co mají dělat, a nástroje generují zprávy, jako je tato:

Hlavní dva parametry: n - počet požadavků, které je třeba provést, c - počet souběžných požadavků. Kontrolují tak konkurenci.

Na výstupu dostaneme RPS, tzn. počet požadavků za sekundu, které je server schopen zpracovat, ze kterého bude zřejmé, kolik uživatelů dokáže obsloužit. Vše samozřejmě závisí na projektu, liší se, ale většinou vyžaduje pozornost.

Je zde ještě jeden parametr – Doba odezvy – doba odezvy, během které server průměrně obsluhoval stránku. Liší se, ale je známo, že kolem 300 ms je norma a cokoliv vyššího není moc dobré, protože těchto 300 ms zpracuje server a k tomu se přidá dalších 300-600 ms, které zpracuje klient. , tj. Zatímco se vše načítá - styly, obrázky a zbytek - čas také plyne.

Stává se, že se vlastně ještě není třeba starat o škálování - jdeme na server, aktualizujeme PHP, získáme 40% nárůst výkonu a vše je v pohodě. Dále nakonfigurujeme Opcache a vyladíme ji. Opcache je mimochodem vyladěna stejným způsobem jako APC, pomocí skriptu, který lze nalézt v repozitáři Rasmuse Lerdorfa a který ukazuje hity a miss, kde hity jsou, kolikrát PHP šlo do mezipaměti, a miss jsou kolikrát to šlo do systému souborů získat soubory. Pokud spustíme celý web nebo spustíme nějaký prohledávač na odkazy nebo do něj ručně šťouchneme, budeme mít statistiky o těchto návštěvách a chybách. Pokud je 100 % zásahů a 0 % chyb, pak je vše v pořádku, ale pokud dojde k chybám, pak musíme alokovat více paměti, aby se celý náš kód vešel do Opcache. To je běžná chyba, která se dělá - zdá se, že tam je Opcache, ale něco nefunguje...

Často se také začnou usazovat, ale vůbec se na to nedívají, a proto vše funguje pomalu. Nejčastěji jdeme do databáze, koukáme - nejsou tam indexy, dáme indexy - vše funguje hned, stačí na další 2 roky, krása!

Musíte také povolit mezipaměť, nahradit apache nginx a php-fpm, abyste ušetřili paměť. Všechno bude skvělé.

Všechny výše uvedené jsou docela jednoduché a dají vám čas. Je čas na to, že to jednoho dne nebude stačit, a na to se musíme připravit už teď.

Jak můžete obecně pochopit, v čem je problém? Buď už máte vysokou zátěž, a to nemusí být nutně nějaký šílený počet požadavků atd., je to tehdy, když váš projekt zátěž nezvládne, a to již nelze řešit triviálními způsoby. Musíte růst buď širší, nebo vyšší. Něco je potřeba udělat a s největší pravděpodobností je na to málo času, je potřeba něco vymyslet.

První pravidlo je, že byste nikdy neměli nic dělat naslepo, tzn. potřebujeme vynikající monitorování. Nejprve získáme čas na některé zřejmé optimalizace, jako je povolení mezipaměti nebo ukládání domovské stránky do mezipaměti atd. Pak nastavíme monitoring, ten nám ukáže, co chybí. A to vše se mnohokrát opakuje – nikdy nemůžete přestat sledovat a zlepšovat.

Co může sledování ukázat? Můžeme se opřít o disk, tzn. do souborového systému, do paměti, do procesoru, do sítě... A může se stát, že se vše zdá být více či méně, ale objeví se nějaké chyby. To vše se řeší různými způsoby. Problém s diskem můžete vyřešit například přidáním nového disku na stejný server, nebo můžete nainstalovat druhý server, který bude pracovat pouze se soubory.

Na co si dát při sledování právě teď pozor? Tento:

dostupnost, tzn. zda je server naživu nebo ne;
nedostatek diskových prostředků, procesoru atd.;
chyby.

Jak to vše sledovat?

Zde je seznam skvělých nástrojů, které vám umožní sledovat zdroje a zobrazovat výsledky velmi pohodlným způsobem:

Tato zpráva je přepisem jedné z nejlepších prezentací na školicí konferenci pro vývojáře vysoce zatěžovaných systémů v roce 2015.
Stará věc! - říkáš.
- Věčné hodnoty! - odpovíme. Přidat štítky

Ahoj! Jsem Alexander Makarov a můžete mě znát z frameworku Yii – jsem jedním z jeho vývojářů. Mám také práci na plný úvazek – a to už není startup – Stay.com, která se zabývá cestováním.

Dnes budu mluvit o horizontálním škálování, ale velmi, velmi obecně.

Co je to vlastně škálování? To je příležitost ke zvýšení produktivity projektu v minimálním čase přidáním zdrojů.

Hlavní dva parametry: n - počet požadavků, které je třeba provést, c - počet souběžných požadavků. Kontrolují tak konkurenci.

Musíte také povolit mezipaměť, nahradit apache nginx a php-fpm, abyste ušetřili paměť. Všechno bude skvělé.

Všechny výše uvedené jsou docela jednoduché a dají vám čas. Je čas na to, že to jednoho dne nebude stačit, a na to se musíme připravit už teď.

Na co si dát při sledování právě teď pozor? Tento:

dostupnost, tzn. zda je server naživu nebo ne;
nedostatek diskových prostředků, procesoru atd.;
chyby.

Jak to vše sledovat?

Zde je seznam skvělých nástrojů, které vám umožní sledovat zdroje a zobrazovat výsledky velmi pohodlným způsobem:

První 4 nástroje lze nainstalovat na server, jsou výkonné a cool. A ServerDensity je hostován někým, tj. platíme za to peníze a může shromažďovat všechna data ze serverů a zobrazovat je pro analýzu.

Existují dvě dobré služby pro sledování chyb:

Obvykle takto sledujeme chyby - buď vše zapíšeme do logu a pak se na to podíváme, nebo kromě toho začneme posílat e-maily či SMS vývojářům. To je normální, ale jakmile máme dav lidí přichází do služby a tam je nějaký druh - tato chyba se začne opakovat velmi často, e-mail začne šíleně spamovat nebo se obecně zaplní nebo vývojář úplně ztratí pozornost a začne ignorovat písmena Výše uvedené služby berou a shromažďují chyby stejného typu do jednoho velkého balíčku, navíc počítají, kolikrát se v poslední době vyskytly chyby, a automaticky celou záležitost upřednostňují.

Sentry lze nainstalovat na váš server, je tam zdrojový kód, ale Rollbar ne, ale Rollbar je lepší, protože si účtuje peníze za počet chyb, tzn. povzbuzuje je k nápravě.

Pokud jde o oznámení, zopakuji, že byste neměli spamovat, protože by se ztratila vaše pozornost.

Co je obecně potřeba analyzovat?

RPS a doba odezvy – pokud naše doba odezvy začne klesat, musíme něco udělat.

Počet procesů, vláken a velikostí front – pokud se to vše začne množit, zanášet atd., tak tady zase není něco v pořádku, musíme to rozebrat podrobněji a nějak změnit infrastrukturu.

Také stojí za to podívat se na obchodní analýzu. Google Analytics je skvělý pro typy webových stránek a mixpanel je skvělý pro protokolování událostí, funguje v aplikacích pro počítače, mobilních aplikacích a na webu. Můžete psát na základě nějakých vlastních dat, ale doporučil bych hotové služby. Jde o to, že náš monitoring dokáže ukázat, že služba žije, že vše funguje, že celková doba odezvy je normální, ale když, řekněme, začneme sledovat registrace v mixpanelu, ukáže se, že jich je nějak málo. V tomto případě se musíte podívat na to, jak rychle jsou určité události a stránky zpracovávány a jaké jsou problémy Projekt by měl být vždy „propojen“ s analýzou, abyste vždy věděli, co se děje, a nepracoval naslepo.

Zátěž obecně vzniká buď plánovaně nebo ne, může vznikat postupně, nemusí postupně:

Jak se vypořádat se zátěží? O všem rozhoduje byznys a důležitá je pouze cena emise. Důležité:

aby služba fungovala,
aby to nebylo moc drahé a nezruinovalo to firmu.

Zbytek není moc důležitý.

Pokud je levnější profilovat, optimalizovat, zapisovat do mezipaměti, opravovat některé konfigurace, pak by to mělo být provedeno bez přemýšlení o škálování nebo nákupu dalšího hardwaru atd. Stává se ale, že hardware je levnější než práce programátora, zvláště pokud jsou programátoři velmi důvtipní. V tomto případě již začíná škálování.

Na obrázku je modrá věc internet, ze kterého přicházejí požadavky. Je nainstalován balancer, jehož jediným úkolem je distribuovat požadavky na samostatné front-end servery, přijímat od nich odpovědi a odesílat je klientovi. Tady jde o to, že 3 servery dokážou zpracovat (ideálně) 3x více požadavků, bez jakýchkoliv režijních nákladů na síť a práci samotného balanceru.

Co nám to dává? Výše zmíněná schopnost zpracovat více požadavků a také spolehlivost. Pokud v tradičním schématu nginx nebo aplikace spadne, nebo se disk dostane do problémů atd., vše se zastaví. Zde, pokud jeden z našich frontendů selže, pak je to v pořádku, balancer to s největší pravděpodobností pochopí a pošle požadavky na zbývající 2 servery. Může to být trochu pomalejší, ale to není velký problém.

Obecně je PHP skvělé pro škálování, protože se ve výchozím nastavení řídí principem Share Nothing. To znamená, že když vezmeme, řekněme, Javu pro web, tak se tam aplikace spustí, načte veškerý kód, zapíše co nejvíce dat do paměti programu, všechno se tam točí, funguje, na požadavek se stráví velmi málo času , velmi málo dalších zdrojů. Existuje však přepadení - protože. Aplikace je napsaná tak, že musí běžet na jedné instanci, cachovat, číst z vlastní paměti, pak z ní při škálování nic dobrého nevzejde. Ale v PHP není ve výchozím nastavení nic běžného, a to je dobře. Cokoli chceme sdílet, vložíme do memcached a memcached lze číst z více serverů, takže vše je skvělé. Tito. U vrstvy aplikačního serveru je dosaženo volné vazby. To je úžasné.

Jak vyvážit zátěž obecně?

Nejčastěji to dělal Squid nebo HAProxy, ale to bylo dříve. Nyní autor nginx vzal a rozdělil balancer z nginx+ do nginx, takže nyní umí vše, co dělal Squid nebo HAProxy. Pokud začne selhávat, můžete nainstalovat nějaký skvělý drahý hardwarový balancer.

Problémy, které balancer řeší, jsou jak vybrat server a jak ukládat relace? Druhý problém je čistě PHP a server lze vybrat buď jeden po druhém ze seznamu, nebo podle geografie některých IP, nebo podle nějaké statistiky (nginx podporuje nejméně připojené, tj. který server má méně připojení, vyhodí je to na něj). Můžeme napsat nějaký kód pro balancer, který vybere, jak má fungovat.

Co když narazíme na vyvažovačku?

Existuje něco jako DNS Round robin - to je skvělý trik, který nám umožňuje neutrácet peníze za hardwarový balancer. Co to děláme? Vezmeme DNS server (většinou nikdo nehostí DNS server, je drahý, málo spolehlivý, když selže, tak z toho nic dobrého nevzejde, každý používá nějakou firmu), registrujeme více než jeden server v A rekord, ale pár. Budou to A-záznamy z různých balancerů. Když tam prohlížeč přejde (ve skutečnosti neexistují žádné záruky, ale všechny moderní prohlížeče se takto chovají), vybere jednu po druhé IP adresu z A-záznamů a skončí buď na jednom balanceru, nebo na druhém. Zátěž se samozřejmě nemusí rozložit rovnoměrně, ale alespoň se rozloží a vyvažovačka toho zvládne trochu víc.

Co dělat se sezeními?

Ve výchozím nastavení máme relace v souborech. Není tomu tak, protože každý z našich front-end serverů bude uchovávat relace ve svém vlastním souborovém systému a uživatel může přejít nejprve na jeden, pak na druhý, pak na třetí, tzn. pokaždé ztratí relace.

Existuje zřejmá touha vytvořit společný souborový systém a připojit NFS. Ale nemusíte to dělat - je to strašně pomalé.

Můžete to zapsat do databáze, ale také to nestojí za to, protože Databáze není pro tuto práci optimální, ale pokud nemáte jinou možnost, pak v zásadě postačí.

Do memcached můžete psát, ale velmi, velmi opatrně, protože memcached je koneckonců cache a má tendenci se vymazat, jakmile má málo zdrojů nebo není kam zapisovat nové klíče - pak se začne ztrácet staré bez varování se relace začnou ztrácet. Musíte to buď sledovat, nebo zvolit stejný Redis.

Redis je dobré řešení. Jde o to, že máme Redis na samostatném serveru a všechny naše frontendy tam spěchají a začínají číst své relace z Redisu, ale Redis je jednovláknový a dříve nebo později se můžeme dostat do problémů je nainstalován stejný nginx a je informován, že potřebuje provést relaci, takže když uživatel přijde na server a dostane cookie relace, dostane se následně pouze na tento server Ukázalo se, že pokud je Redis na každé instanci, jsou zde samostatné relace a propustnost čtení a zápisu bude mnohem lepší.

Co takhle cookies? Můžete si zapisovat do coockies, nebude žádné úložiště, vše je v pořádku, ale zaprvé musíme stále někam umístit data relace, a pokud začneme zapisovat do kulíšků, může se zvětšit a nevejde se do úložiště, ale , za druhé, do cookies můžete ukládat pouze ID a i tak budeme muset kontaktovat databázi pro některá data relace. V zásadě je to normální, problém to řeší.

Je tu skvělá věc - proxy pro memcached a Redis:

Zdá se, že po vybalení podporují paralelizaci, ale to se děje způsobem, o kterém bych neřekl, že je velmi optimální. Ale tato věc - twemproxy - funguje přibližně jako nginx s PHP, tzn. jakmile obdrží odpověď, okamžitě odešle data a uzavře spojení na pozadí, je rychlejší a spotřebovává méně zdrojů. Velmi dobrá věc.

Velmi často se tato chyba „cyklování“ vyskytuje, když začnou psát, například „Nepotřebuji sezení! Nyní vytvořím úžasný žeton, který se bude přenášet tam a zpět“... Ale když se nad tím zamyslíte, je to opět sezení.

PHP má takový mechanismus jako session handler, tzn. můžeme si dát vlastní handler a zapisovat do cookies, do databáze, do Redis - kdekoliv, a to vše bude fungovat se standardním startem relace atd.

Relace by měly být uzavřeny pomocí této skvělé metody.

Jakmile si vše přečteme z relace, nebudeme tam psát, musí být uzavřena, protože relace je často blokována. Ve skutečnosti by měl být blokován, protože bez blokování budou problémy s konkurencí. To je okamžitě vidět na souborech na jiných úložištích, blokátory nejsou dostupné pro celý soubor najednou, a to je o něco jednodušší.

Co dělat se soubory?

Můžete se s nimi vypořádat dvěma způsoby:

nějaké specializované řešení, které poskytuje abstrakci, a pracujeme se soubory jako se souborovým systémem. Je to něco jako NFS, ale NFS není potřeba.
„sharding“ pomocí PHP.

Specializované řešení z toho, co skutečně funguje, je GlusterFS. To je něco, co si můžete nastavit sami. Jde to, je to rychlé, dává to stejné rozhraní jako NFS, jen to funguje normální snesitelnou rychlostí.

A Amazon S3 je, pokud jste v cloudu Amazon, také dobrý souborový systém.

Pokud implementujete ze strany PHP, existuje nádherná knihovna Flysystem, pokrytá vynikajícími testy, lze s ní pracovat se všemi druhy souborových systémů, což je velmi pohodlné. Pokud okamžitě zapíšete veškerou práci se soubory s touto knihovnou, přenos z místního souborového systému do Amazon S3 nebo jiných bude jednoduchý - přepište řádek v konfiguraci.

Jak to funguje? Uživatel stáhne soubor z prohlížeče, může buď přejít na frontend a odtud se šířit mezi souborové servery, nebo na každém souborovém serveru je vytvořen skript pro nahrávání a soubor je nahrán přímo do systému souborů. Paralelně se do databáze zapíše, který soubor je na kterém serveru, a odtud ho můžeme přímo číst.

Nejlepší je distribuovat soubory pomocí nginx nebo Varnish, ale je lepší dělat vše s nginx, protože to všichni milujeme a používáme - zvládne to, je to dobré.

Co se děje s naší databází?

Pokud vše dopadne na PHP kód, uděláme spoustu frontendů a stále se obracíme na jednu databázi – ta bude zvládat poměrně dlouhou dobu. Pokud zatížení není hrozné, databáze žije dobře. Například jsme udělali JOINy o 160 milionech řádků v tabulce a všechno bylo skvělé, všechno běželo dobře, ale tam by se mělo alokovat více RAM do vyrovnávacích pamětí, do mezipaměti...

Co dělat s databází, když na ni narazíme? Existují techniky, jako je replikace. Obvykle se provádí replikace master-slave a existuje replikace master-master. Můžete provést replikaci ručně, můžete provést sharding a můžete provést rozdělení.

Co je hlavní otrok?

Jeden server je vybrán jako hlavní a několik serverů je vybráno jako sekundární. Zapisuje se do hlavního a můžeme číst z pána, nebo můžeme i z otroků (na obrázku jsou červené šipky to, co píšeme, zelené to, co čteme). V typickém projektu máme mnohem více čtení než zápisů. Existují atypické projekty.

V případě typického projektu velké množství slave umožňuje odlehčit jak masteru, tak obecně zvýšit rychlost čtení.

To také zajišťuje odolnost proti chybám – pokud jeden z podřízených jednotek selže, není třeba nic dělat. Pokud pán padne, můžeme z jednoho z otroků rychle udělat pána. Pravda, většinou se to nedělá automaticky, jde o nouzovou situaci, ale možnost tu je.

No a zálohy. Každý dělá zálohy databází jinak, někdy se to dělá s výpisem MySQL a to zamrzí celý projekt, což není moc dobré. Ale pokud vytvoříte zálohu z nějakého slave, poté, co jste to nejprve zastavili, uživatel si ničeho nevšimne. To je úžasné.

Kromě toho lze provádět těžké výpočty na otrokech, aby neovlivnily hlavní základnu, hlavní projekt.

Existuje něco jako rozdělení čtení/zápisu Existují 2 skupiny serverů – hlavní, podřízený, připojení na vyžádání a logika výběru připojení se liší. Jde o to, že pokud budeme vždy číst z otroků a vždy psát pánovi, dojde k malému přepadení:

těch. replikace není okamžitá a neexistuje žádná záruka, že byla dokončena, když vzneseme jakýkoli požadavek.

Existují dva typy vzorků:

pro čtení nebo výstup;
pro nahrávání, tedy když jsme něco vybrali a pak je potřeba toto něco změnit a zapsat zpět.

Pokud je ukázka pro zápis, tak můžeme buď vždy číst z masteru a zapisovat do masteru, nebo můžeme provést „SHOW SLAVE STATUS“ a podívat se tam na Seconds_Behind_Master (pro PostgreSQL je na obrázku i super-dotaz) - ukáže nám to číslo. Pokud je 0 (nula), pak již bylo vše replikováno, můžete bezpečně číst z slave. Pokud je číslo větší než nula, pak se musíme podívat na hodnotu - buď bychom měli chvíli počkat a pak číst z slave, nebo rovnou číst z mastera. Pokud máme NULL, znamená to, že jsme to ještě nereplikovali, něco se zaseklo a musíme se podívat na protokoly.

Důvody pro takové zpoždění jsou buď pomalá síť, nebo replika, kterou nezvládá, nebo příliš mnoho slave (více než 20 na 1 master). Pokud je síť pomalá, pak je jasné, že je třeba ji nějak zrychlit, shromáždit do jednotlivých datových center atd. Pokud replika selže, musíte přidat repliky. Pokud je otroků příliš mnoho, musíte přijít s něčím zajímavým, s největší pravděpodobností vytvořit nějakou hierarchii.

Co je to mistr řemesla?

Toto je situace, kdy existuje několik serverů a všude se vše zapisuje a čte. Výhodou je, že může být rychlejší, je odolný vůči poruchám. V principu je vše stejné jako u otroků, ale logika je obecně jednoduchá – jednoduše vybereme náhodné spojení a pracujeme s ním. Nevýhody: zpoždění replikace je vyšší, existuje možnost získání nějakého druhu nekonzistentních dat, a pokud dojde k nějakému zhroucení, pak se začne šířit mezi všechny mastery a nikdo neví, který master je normální, který je rozbité... Celá tato věc se začíná replikovat napříč kruhem, tzn. Velmi dobře zanáší síť. Obecně platí, že pokud jste měli udělat mistra-mistra, musíte 100krát přemýšlet. S největší pravděpodobností si vystačíte s hlavním otrokem.

Replikaci můžete vždy provést ručně, tzn. uspořádat pár spojení a napsat 2, 3 najednou, nebo dělat něco na pozadí.

Co je to sharding?

Ve skutečnosti jde o šíření dat na několik serverů. Jednotlivé tabulky můžete rozdělit. Vezměme si například tabulku fotografií, tabulku uživatelů atd. a přetáhněte je na samostatné servery. Pokud byly tabulky velké, pak se vše zmenšuje, spotřebovává se méně paměti, vše je v pořádku, ale nemůžete se PŘIPOJIT a musíte klást dotazy typu WHERE IN, tj. nejprve vybereme spoustu ID, pak všechna tato ID nahradíme do dotazu, ale k jinému připojení, k jinému serveru.

Část stejných dat můžete skartovat, tj. například vezmeme a vytvoříme několik databází s uživateli.

Můžete jednoduše vybrat server - zbytek dělení podle počtu serverů. Alternativou je pořízení karty, tzn. U každého záznamu ponechte klíč hodnoty v nějakém Redis nebo podobně, tedy tam, kde se každý záznam nachází.

Existuje jednodušší možnost:

Je to obtížnější, když nemůžete seskupit data. Abyste je získali, musíte znát ID dat. Žádné JOIN, ORDER atd. Ve skutečnosti redukujeme naše MySQL nebo PostgreSQL na úložiště klíč-hodnota, protože s nimi nemůžeme nic dělat.

Z běžných úkolů se stávají mimořádné:

Vyberte TOP 10.
Rozdělení stránek.
Vyberte si ten s nejnižšími náklady.
Vyberte příspěvky od uživatele X.

Pokud jsme to rozstříhali natolik, že se vše rozházelo po všech serverech, začíná se to řešit velmi netriviálním způsobem. V této situaci vyvstává otázka – proč SQL vůbec potřebujeme? Neměli bychom hned napsat Redisovi? Vybrali jsme správné úložiště?

Po vybalení je sharování podporováno věcmi jako:

memcache;
Redis;
Cassandra (ale ona, říkají, v určitém okamžiku nemůže zvládnout a začne padat).

A co statistika?

Často rádi počítají statistiky z hlavního serveru – z jednoho databázového serveru. To je skvělé, ale dotazy ve statistikách jsou obvykle plíživé, vícestránkové atd., takže počítat statistiky z hlavních dat je velká chyba. Ve většině případů není pro statistiky potřeba realtime, takže můžeme nastavit replikaci v master slave a vypočítat tyto statistiky na slave. Nebo můžeme vzít něco hotového - Mixpanel, Google Analytics nebo podobně.

Toto je hlavní myšlenka, která pomáhá distribuovat vše mezi různé servery a různé velikosti. Za prvé, zisk z toho je hned vidět – i když máte jeden server a začnete něco dělat na pozadí, uživatel dostane odpověď mnohem rychleji, ale také následně rozloží zátěž, tzn. celé toto zpracování můžeme přetáhnout na jiný server, můžeme to dokonce zpracovat ne v PHP. Například na Stay.com se velikost obrázků mění v Go.

Gearmana si můžete okamžitě vzít. Jedná se o hotovou věc pro zpracování na pozadí. Pro PHP existují knihovny a ovladače... Nebo můžete použít fronty, tzn. ActiveMQ, RabbitMQ, ale fronty pouze přeposílá zprávy, nevolají ani nespouštějí samotné handlery, a pak budete muset něco vymyslet.

Obecný význam je vždy stejný - existuje hlavní software, který umisťuje nějaká data do fronty (obvykle to je „co mám dělat?“ a data pro to), a nějaká služba – buď je získá, nebo se do ní odešle (pokud se fronta dokáže aktivně chovat chování) tato data, zpracovává vše na pozadí.

Pojďme k architektuře.

Nejdůležitější při škálování je, aby byl projekt co nejméně propojený. Čím menší propojenost, tím snazší je změnit jedno řešení na jiné, tím snazší je přesunout část na jiný server.

Soudržnost probíhá v kódu. SOLID, GRASP jsou principy, které vám umožňují vyhnout se propojení v kódu. Ale konektivita v kódu samozřejmě ovlivňuje distribuci mezi servery, ale ne tolik jako konektivitu doménové vrstvy s naším prostředím. Pokud do ovladače napíšeme hodně kódu, ukáže se, že jej s největší pravděpodobností nebudeme moci použít jinde. Nebude pro nás snadné toto vše přenést z webového ovladače do konzole, a proto bude obtížnější to přenést na jiné servery a tam to zpracovat jinak.

Architektura orientovaná na služby.

Existují 2 přístupy k rozdělení systémů na části:

když se zaměřují na technické části, tj. například existuje fronta, odstranili službu řazení do fronty, došlo ke zpracování obrazu, odstranili tuto službu atd.
To je dobré, ale když tyto fronty, obrázky atd. interagují v rámci dvou doménových oblastí... Například v projektu existuje oblast prodeje a oblast zákazníků – to jsou různé oblasti, pracují s nimi různí uživatelé, ale obě mají různé fronty. Když všechno začne do sebe zapadat, z projektu se stane nepořádek;
Správným řešením je rozdělení na samostatné logické části, tzn. pokud oblasti Prodej a Zákazník používají uživatelský model, pak vytvoříme 2 uživatelské modely. Mohou číst stejná data, ale prezentují je mírně odlišně. Pokud takto nabouráte systém, pak je vše vnímáno mnohem lépe a je mnohem snazší to všechno rozházet.
Další důležitou věcí je, že díly musí vždy komunikovat přes rozhraní. Takže v našem příkladu, pokud Sales s něčím interaguje, pak to nezapisuje do databáze, nepoužívá společný model a „mluví“ s jinými oblastmi prostřednictvím konkrétní smlouvy.

A co doménová vrstva?

Doménová vrstva je rozdělena na nějaké služby atd. - to je důležité pro vývoj aplikace, ale pro škálování jejího designu není příliš důležité. V doménové vrstvě je nesmírně důležité ji oddělit od prostředí, kontextu, ve kterém se provádí, tzn. z ovladače, konzolového prostředí atd., takže všechny modely lze používat v jakémkoli kontextu.

Existují 2 knihy o vrstvě domény, které doporučuji všem:

„Design řízený doménou: Řešení složitosti v srdci softwaru“ od Erica Evanse,
"Implementace návrhu řízeného doménou, implementace návrhu řízeného doménou."

o BoundedContext - http://martinfowler.com/bliki/BoundedContext.html (to, co bylo zmíněno výše - pokud máte dvě oblasti, které se zdánlivě prolínají, ale
různé, pak se vyplatí některé entity duplikovat, např. uživatelský model);
o DDD obecně - odkaz na jinou knihu.

V architektuře se opět vyplatí držet se zásady share Nothing, tzn. pokud chcete udělat něco společného, vždy to dělejte vědomě. Je lepší dát logiku na stranu aplikace, ale stojí za to vědět, kdy přestat. Nikdy byste například neměli vytvářet uložené procedury v DBMS, protože jejich škálování je velmi obtížné. Pokud to přeneseme na aplikační stranu, bude to jednodušší – vytvoříme několik serverů a vše se bude provádět tam.

Nepodceňujte optimalizaci prohlížeče. Jak jsem již řekl, z 300-600 ms, které jsou požadavky provedeny na serveru, se k nim přidá 300-600 ms, které jsou vynaloženy na klienta. Klienta nezajímá, zda je náš server rychlý nebo zda stránka funguje tak rychle, proto vám doporučuji použít Google PageSpeed atd.

Jak už to tak bývá, abstrakce a fragmentace nejsou vůbec zadarmo. Pokud službu rozdělíme na mnoho mikroslužeb, tak už nebudeme moci pracovat s nováčky a budeme muset hodně, hodně platit našemu týmu, který se tím vším bude hrabat, třídit všechny vrstvy, navíc , může služba začít pracovat pomaleji. Pokud to není děsivé v kompilovaných jazycích, pak v PHP, alespoň do verze 7, to není moc...

Nikdy nechovejte slepě, vždy sledujte a analyzujte. Slepě, téměř všechna výchozí rozhodnutí jsou chybná. Myslet si! Nevěřte, že existuje stříbrná kulka, vždy si to zkontrolujte.

Některé další užitečné odkazy:

Kontakty

Tato zpráva je přepisem jedné z nejlepších prezentací na školicí konferenci pro vývojáře vysoce zatěžovaných systémů v roce 2015.

Stará věc! - říkáš.
- Věčné hodnoty! - odpovíme.

Některé z těchto materiálů používáme také v online školení o vývoji systémů s vysokou zátěží – jedná se o řetězec speciálně vybraných dopisů, článků, materiálů a videí. Naše učebnice již obsahuje více než 30 unikátních materiálů. Připojit!

No a hlavní zprávou je, že jsme zahájili přípravy na jarní festival „Ruské internetové technologie“, který zahrnuje osm konferencí, vč. HighLoad++ Junior.

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? Myslí si, že virtualizační platformy nejsou dostatečně stabilní, aby podporovaly kritické aplikace?

VMware za posledních 10 let prokázal, ž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.

Vertikální škálování je skvělé pro kritické obchodní aplikace s jejich velkými požadavky na zdroje. Ahoj Monster VM! Všechny tyto kritické databáze, obrovské ERP systémy, systémy pro analýzu velkých dat, aplikace JAVA a tak dále a tak dále budou přímo těžit z vertikálního škálování.

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 vSphere 5.1 bylo možné 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 vertikálního škálování serveru: 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
Náklady na servery se 4 i 8 procesory jsou sníženy

nedostatky:

Celkové náklady na vlastnictví se zvyšují, když se š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

Jaký je důvod chatrnosti protokolu QPI? Aby bylo dosaženo integrity mezipaměti procesoru, musí být každá operace čtení replikována napříč všemi procesory. To lze přirovnat k broadcast paketu v síti IP. Každý procesor musí zkontrolovat požadovanou paměťovou linku a pokud je použita nejnovější verze dat, poskytnout ji. Pokud jsou aktuální data v jiné mezipaměti, protokol QPI zkopíruje tento paměťový řádek ze vzdálené mezipaměti s minimálním zpožděním. Replikace každé operace čtení tedy plýtvá šířkou pásma sběrnice a cykly mezipaměti, které by mohly být použity k přenosu užitečných dat.

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í uzlový řadič 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.

Oblíbené v kategorii: