V reálném světě mohou nastat situace, kdy může dojít k poklesu výkonu vašich serverů v důsledku událostí od náhlého nárůstu provozu až po náhlý výpadek proudu. Může to být mnohem horší a vaše servery mohou být ochromeny – bez ohledu na to, zda jsou vaše aplikace hostovány v cloudu nebo na fyzickém stroji. Takovým situacím se nelze vyhnout. Spíše než doufat, že nenastanou, byste však měli ve skutečnosti udělat to, že se připravíte na to, aby vaše systémy nenarazily na výpadek.
Řešením problému je použití konfigurace nebo architektury vysoké dostupnosti (HA). Architektura vysoké dostupnosti je přístup definování komponent, modulů nebo implementace služeb systému, který zajišťuje optimální provozní výkon i v době vysokého zatížení. Ačkoli neexistují žádná pevná pravidla implementace systémů HA, obecně existuje několik osvědčených postupů, které je třeba dodržovat, abyste získali maximum z nejmenších zdrojů.
Proč to potřebujete?“
Než se posuneme dále, definujme výpadky. Prostoje jsou časové období, kdy váš systém (nebo síť) není k dispozici pro použití nebo nereaguje. Prostoje mohou společnosti způsobit obrovské ztráty, protože při výpadku systémů jsou pozastaveny všechny jejich služby. V srpnu 2013 měla společnost Amazon výpadek na 15 minut (webové i mobilní služby) a nakonec přišla o více než 66 000 dolarů za minutu. To jsou obrovská čísla i pro společnost velikosti Amazonu.
Existují dva typy výpadků – plánované a neplánované. Plánovaná odstávka je důsledkem údržby, které se nelze vyhnout. Patří sem aplikace záplat, aktualizace softwaru nebo dokonce změny ve schématu databáze. Neplánovaná odstávka je však způsobena nějakou nepředvídanou událostí, například selháním hardwaru nebo softwaru. K tomu může dojít v důsledku výpadku napájení nebo selhání některé komponenty. Plánované odstávky jsou obecně z výpočtů výkonu vyloučeny.
Primárním cílem implementace architektury vysoké dostupnosti je zajistit, aby byl systém nebo aplikace nakonfigurovány tak, aby zvládaly různé zátěže a různá selhání s minimálními nebo žádnými odstávkami. K dosažení tohoto cíle vám pomůže více komponent, které si stručně probereme.
Jak se dostupnost měří?
Organizace, které plánují plně využívat cloudovou infrastrukturu, musí být také schopny splnit požadavky na nepřetržitou dostupnost. Dostupnost lze měřit jako procento času, po který jsou systémy dostupné.
x = (n – y) * 100/n
Kde n je celkový počet minut v kalendářním měsíci a y je celkový počet minut, kdy je služba v daném kalendářním měsíci nedostupná. Vysoká dostupnost jednoduše označuje komponentu nebo systém, který je nepřetržitě funkční po žádoucí dlouhou dobu. Všeobecně rozšířený, ale téměř nedosažitelný standard dostupnosti produktu nebo systému se označuje jako dostupnost „pět devítek“ (99,999 %). Vysoká dostupnost je požadavkem pro každý podnik, který doufá, že ochrání své podnikání před riziky způsobenými výpadkem systému. Tato rizika mohou vést ke ztrátě příjmů ve výši milionů dolarů.
Stojí to opravdu za ty peníze?“
To, že přechod na architekturu s vysokou dostupností přináší vyšší výkon, je v pořádku, ale také to něco stojí. Musíte si položit otázku, zda si myslíte, že je toto rozhodnutí z hlediska financí opodstatněné.
Je třeba se rozhodnout, zda dodatečná doba provozuschopnosti skutečně stojí za množství peněz, které se na ni musí vynaložit. Musíte si položit otázku, jak škodlivé mohou být případné výpadky pro vaši společnost a jak důležité jsou vaše služby pro chod podniku.
Jak toho dosáhnout?
Když už jste se rozhodli pro tuto variantu, pojďme probrat způsoby její realizace. Není intuitivní, že přidávání dalších komponent do systému nepomáhá k jeho větší stabilitě a dosažení vysoké dostupnosti. Ve skutečnosti to může vést k opaku, protože více komponent zvyšuje pravděpodobnost selhání. Moderní návrhy umožňují rozdělit pracovní zátěž mezi více instancí, například síť nebo cluster, což pomáhá optimalizovat využití zdrojů, maximalizovat výkon, minimalizovat dobu odezvy a zabránit přetížení některého systému v procesu známém jako rozložení zátěže. Zahrnuje také přepnutí na záložní zdroj, jako je server, komponenta nebo síť, v případě selhání aktivního, známé jako systémy Failover.
Použití více aplikačních serverů:
Představte si, že máte jediný server pro poskytování služeb a náhlý nárůst provozu vede k jeho selhání (nebo k jeho pádu). V takové situaci, dokud není server restartován, nelze obsloužit žádné další požadavky, což vede k výpadku.
Zřejmým řešením je zde nasazení aplikace na více serverů. Mezi všechny je třeba rozložit zátěž tak, aby žádný z nich nebyl přetížen a výstup byl optimální. Můžete také nasadit části své aplikace na různé servery. Například může existovat samostatný server pro zpracování pošty nebo samostatný server pro zpracování statických souborů, například obrázků (jako síť pro doručování obsahu).
Škálování databází:
Databáze jsou nejoblíbenějším a možná jedním z koncepčně nejjednodušších způsobů ukládání uživatelských dat. Je třeba si uvědomit, že databáze jsou pro vaše služby stejně důležité jako aplikační servery. Databáze běží na samostatných serverech (například Amazon RDS) a jsou také náchylné k haváriím. Horší je, že havárie databází mohou vést ke ztrátě uživatelských dat, což se může ukázat jako nákladné.
Redundance je proces, který vytváří systémy s vysokou úrovní dostupnosti tím, že dosahuje zjistitelnosti selhání a zabraňuje selháním se společnou příčinou. Toho lze dosáhnout udržováním podřízených serverů, které mohou zasáhnout v případě havárie hlavního serveru. Dalším zajímavým konceptem škálování databází je sharding. Shard je horizontální oddíl v databázi, kde jsou řádky stejné tabulky, která pak běží na samostatném serveru.
Diverzifikované geografické umístění:
Škálování aplikací a následně databází je opravdu velký krok vpřed, ale co když jsou všechny servery na stejném fyzickém místě a datové centrum, ve kterém se servery nacházejí, postihne něco hrozného, například přírodní katastrofa? To může vést k potenciálně obrovským výpadkům.
Je proto nutné, abyste měli servery na různých místech. Většina moderních webových služeb umožňuje zvolit geografické umístění serverů. Měli byste vybírat moudře, aby vaše servery byly rozmístěny po celém světě a nebyly lokalizovány v jedné oblasti.
V tomto příspěvku jsem se pokusil dotknout základních myšlenek, které tvoří ideu architektury vysoké dostupnosti. V konečném důsledku je zřejmé, že žádný systém nedokáže vyřešit všechny problémy. Proto je třeba pečlivě posoudit situaci a rozhodnout se, jaké možnosti jim nejlépe vyhovují. Doufáme, že vás tento článek uvedl do světa architektury vysoké dostupnosti a pomohl vám rozhodnout se, jak toho dosáhnout u sebe.
Jaké jsou osvědčené postupy?
Pro omezení výpadků systému a udržení plánovaných i neplánovaných odstávek na uzdě se velmi doporučuje používat architekturu vysoké dostupnosti (HA), zejména u kritických aplikací. Odborníci na dostupnost trvají na tom, že aby byl jakýkoli systém vysoce dostupný, měly by být jeho části dobře navrženy a důkladně testovány. Návrh a následná implementace architektury vysoké dostupnosti může být obtížná vzhledem k široké škále možností softwaru, hardwaru a nasazení. Úspěšné úsilí však obvykle začíná jasně definovanými a komplexně pochopenými obchodními požadavky. Zvolená architektura by měla být schopna splnit požadované úrovně zabezpečení, škálovatelnosti, výkonu a dostupnosti.
Jediným způsobem, jak zaručit výpočetním prostředím žádoucí úroveň provozní kontinuity během výrobních hodin, je navrhnout je s vysokou dostupností. Kromě správného návrhu architektury mohou podniky udržet klíčové aplikace online dodržováním doporučených osvědčených postupů pro vysokou dostupnost.
- Zálohování, obnova a replikace dat
Značkou dobrého plánu ochrany dat, který chrání před selháním systému, je spolehlivá strategie zálohování a obnovy. Cenná data by nikdy neměla být uložena bez řádného zálohování, replikace nebo možnosti data znovu vytvořit. Každé datové centrum by mělo předem plánovat ztrátu nebo poškození dat. Chyby dat mohou způsobit problémy s autentizací zákazníků, poškodit finanční účty a následně i důvěryhodnost obchodní komunity. Doporučenou strategií pro zachování integrity dat je vytvoření úplné zálohy primární databáze a následné inkrementální testování zdrojového serveru na poškození dat. Vytváření úplných záloh je v popředí zájmu o obnovu po katastrofickém selhání systému.
- Klastrování
I při sebelepší kvalitě softwarového inženýrství musí všechny aplikační služby někdy selhat. Vysoká dostupnost spočívá v poskytování aplikačních služeb bez ohledu na selhání. Clustering může v případě poruchy zajistit okamžité převzetí aplikačních služeb při selhání. Aplikační služba, která je „cluster aware“, je schopna volat prostředky z více serverů; v případě výpadku hlavního serveru se vrátí zpět na sekundární server. Cluster s vysokou dostupností zahrnuje více uzlů, které sdílejí informace prostřednictvím sdílených datových paměťových sítí. To znamená, že kterýkoli uzel může být odpojen nebo vypnut ze sítě a zbytek clusteru bude nadále normálně fungovat, pokud bude alespoň jeden uzel plně funkční. Každý uzel lze samostatně upgradovat a znovu připojit, dokud cluster funguje. Vysoké náklady na nákup dalšího hardwaru pro implementaci clusteru lze zmírnit nastavením virtualizovaného clusteru, který využívá dostupné hardwarové prostředky.
- Vyrovnávání zátěže sítě
Vyrovnávání zátěže je účinný způsob, jak zvýšit dostupnost kritických webových aplikací. Při zjištění selhání instancí serverů jsou tyto bezproblémově nahrazeny, když je provoz automaticky přerozdělen na servery, které jsou stále v provozu. Vyrovnávání zátěže vede nejen k vysoké dostupnosti, ale také usnadňuje postupné škálování. Vyrovnávání zátěže sítě lze provádět prostřednictvím modelu „pull“ nebo „push“. Usnadňuje vyšší úroveň odolnosti proti chybám v rámci aplikací služeb.
- Řešení pro případ selhání
Architektura vysoké dostupnosti se tradičně skládá ze sady volně propojených serverů, které mají možnost převzetí služeb při selhání. Převzetí služeb při selhání je v podstatě záložní provozní režim, ve kterém funkce systémové komponenty přebírá sekundární systém v případě, že primární systém přestane fungovat, ať už z důvodu selhání nebo plánované odstávky. K „studenému převzetí služeb při selhání“ dochází tehdy, když je sekundární server spuštěn až po úplném vypnutí primárního. K „horkému převzetí služeb při selhání“ dochází, když jsou všechny servery spuštěny současně a zátěž je v daném okamžiku směrována výhradně na jediný server. V obou scénářích jsou úlohy automaticky přeneseny na záložní systémovou komponentu, aby proces zůstal pro koncového uživatele co nejplynulejší. Převzetí služeb při selhání lze řídit prostřednictvím systému DNS, a to v dobře kontrolovaném prostředí.
- Geografická redundance
Geografická redundance je jedinou obrannou linií, pokud jde o prevenci selhání služeb v případě katastrofických událostí, jako jsou přírodní katastrofy, které způsobují výpadky systému. Stejně jako v případě georeplikace je na geograficky odlišných místech rozmístěno více serverů. Tato místa by měla být rozmístěna globálně a neměla by být lokalizována v určité oblasti. Zásadní je, aby v každé z těchto lokalit byly provozovány nezávislé zásobníky aplikací, aby v případě výpadku v jedné lokalitě mohly ostatní pokračovat v provozu. V ideálním případě by tyto lokality měly být na sobě zcela nezávislé.
- Plánování pro případ selhání
Přestože uplatňování osvědčených postupů pro vysokou dostupnost je v podstatě plánováním pro případ selhání; existují další opatření, která může organizace přijmout, aby zvýšila svou připravenost v případě selhání systému vedoucího k výpadku. Organizace by měly uchovávat údaje o poruchách nebo spotřebě zdrojů, které lze použít k izolaci problémů a analýze trendů. Tyto údaje lze shromáždit pouze prostřednictvím průběžného monitorování provozního zatížení. Pro shromažďování informací o problémech, zjišťování historie problémů a zahájení okamžitého řešení problémů lze zavést oddělení pomoci při obnově. Plán obnovy by měl být nejen dobře zdokumentován, ale také pravidelně testován, aby byla zajištěna jeho praktičnost při řešení neplánovaných přerušení. Školení zaměstnanců v oblasti inženýrství dostupnosti zlepší jejich dovednosti při navrhování, nasazování a údržbě architektur s vysokou dostupností. Měly by být také zavedeny bezpečnostní zásady, aby se omezily případy výpadků systému v důsledku narušení bezpečnosti.
Příklad: Následující schéma vysvětluje, jak lze servery FileCloud nakonfigurovat pro vysokou dostupnost, aby se zvýšila spolehlivost služeb a omezily prostoje. Kliknutím sem získáte další podrobnosti.