Úvod do výpočtov vysokej dostupnosti: koncepty a teória

Zamerajme sa viac na niektoré z väčších architektonických princípov správy klastrov ako na akékoľvek jednotlivé technologické riešenie.

Niektoré skutočné implementácie uvidíme neskôr v knihe - a o tom, ako to funguje na AWS spoločnosti Amazon, sa dozviete veľa v mojej knihe Learn Amazon Web Services in a Month of Lunches od Manninga. Ale zatiaľ si najskôr overme, či nám vyhovujú základné informácie.

Prevádzka servera pomocou klastrov fyzických alebo virtuálnych počítačov spočíva v zlepšení spoľahlivosti a výkonu nad rámec toho, čo by ste od jedného výkonného servera mohli očakávať. Spoľahlivosť pridáte tým, že nebudete musieť zavesiť celú svoju infraštruktúru na jediný bod zlyhania (tj. Na jednom serveri). A môžete zvýšiť výkon vďaka schopnosti veľmi rýchlo pridať výpočtový výkon a kapacitu zväčšením a zmenšením.

To sa môže stať prostredníctvom inteligentného rozloženia vašich pracovných úloh medzi rôzne geografické a dopytové prostredia (vyvažovanie záťaže)

záložné servery, ktoré je možné rýchlo uviesť do prevádzky v prípade zlyhania fungujúceho uzla (failover), optimalizácie spôsobu nasadenia dátovej vrstvy alebo umožnenia odolnosti voči chybám prostredníctvom voľne prepojených architektúr.

K tomu všetkému sa ešte dostaneme. Najskôr však uvádzame niekoľko základných definícií:

Uzol : Jeden počítač (fyzický alebo virtuálny), ktorý spúšťa serverové operácie nezávisle na svojom vlastnom operačnom systéme. Pretože akýkoľvek jednotlivý uzol môže zlyhať, splnenie cieľov dostupnosti vyžaduje, aby viac uzlov fungovalo ako súčasť klastra.

Klaster : Dva alebo viac serverových uzlov, ktoré navzájom spolupracujú, aby dokončili jednotlivé úlohy ako súčasť väčšej služby, kde vzájomné povedomie umožňuje jednému alebo viacerým uzlom kompenzovať stratu druhého.

Zlyhanie servera : Neschopnosť uzla servera adekvátne reagovať na požiadavky klientov. Môže to byť spôsobené úplným zlyhaním, problémami s pripojením alebo preto, že bol zaplavený vysokým dopytom.

Failover : Spôsob, akým sa klaster snaží vyhovieť potrebám klientov osirelých po zlyhaní jedného uzla servera spustením alebo presmerovaním ďalších uzlov, aby sa vyplnila medzera v službe.

Failback : Obnovenie zodpovedností za uzol servera, ktorý sa zotavuje zo zlyhania.

Replikácia : Vytváranie kópií dôležitých dátových úložísk, ktoré umožňujú spoľahlivý synchrónny prístup z viacerých serverových uzlov alebo klientov a zabezpečujú ich prežitie po katastrofách. Replikácia sa tiež používa na umožnenie spoľahlivého vyváženia záťaže.

Redundancia : Zabezpečenie viacerých identických fyzických alebo virtuálnych serverových uzlov, z ktorých každý môže adoptovať osirelých klientov iného zlyhávajúceho.

Rozdelený mozog : Chybový stav, pri ktorom sa sieťová komunikácia medzi uzlami alebo zdieľaným úložiskom nejako rozpadla a niekoľko jednotlivých uzlov, z ktorých každý verí, že je to jediný uzol, ktorý je stále aktívny, pokračuje v prístupe a aktualizácii spoločného zdroja údajov. Aj keď to nemá vplyv na návrhy zdieľaného ničoho, môže to viesť k chybám klientov a poškodeniu údajov v zdieľaných klastroch.

Oplotenie : Aby sa zabránilo rozdeleniu mozgu, dá sa stonithdov démon nakonfigurovať tak, aby automaticky vypínal nefunkčný uzol alebo aby medzi ním a dátovými prostriedkami zvyšku klastra uložil virtuálny plot. Pokiaľ existuje šanca, že uzol môže byť stále aktívny, ale nebude správne koordinovaný so zvyškom klastra, zostane za plotom. Stonith znamená „Vystreľte druhý uzol do hlavy“. Naozaj.

Kvórum : Môžete nakonfigurovať, aby sa oplotenie (alebo vynútené vypnutie) ukladalo na uzly, ktoré vypadli z vzájomného kontaktu alebo s nejakým zdieľaným prostriedkom. Kvórum sa často definuje ako viac ako polovica všetkých uzlov celkového klastra. Použitím takto definovaných konfigurácií sa vyhnete tomu, aby ste mali dve podskupiny uzlov, pričom každý z nich by mal mať podozrenie, že nefunguje správne, a pokúšať sa druhého vyraziť.

Obnova po katastrofe y: Vašu infraštruktúru možno ťažko považovať za vysoko dostupnú, ak nemáte zavedený žiadny automatizovaný systém zálohovania spolu s integrovaným a testovaným plánom obnovy po katastrofe. Váš plán bude musieť počítať s presunom každého zo serverov vo vašom klastri.

Aktívny / pasívny klaster

Myšlienka zlyhania služby spočíva v tom, že náhlu stratu ktoréhokoľvek z uzlov v klastri služieb by rýchlo nahradil iný uzol, ktorý nahradí miesto. Aby to fungovalo, je adresa IP automaticky presunutá do pohotovostného uzla v prípade zlyhania. Alternatívne možno na presmerovanie prenosu z neúspešných uzlov použiť nástroje na smerovanie v sieti, ako sú napríklad nástroje na vyrovnávanie zaťaženia. Presný spôsob zlyhania pri zlyhaní závisí od spôsobu, akým ste nakonfigurovali svoje uzly.

Iba jeden uzol bude pôvodne nakonfigurovaný tak, aby slúžil klientom, a bude to robiť sám, až kým nejako neuspeje. Zodpovednosť za existujúcich a nových klientov sa potom presunie (tj „prepnutie po zlyhaní“) na pasívny alebo záložný uzol, ktorý bol doteraz pasívne držaný v zálohe. Aplikácia modelu na viac serverov alebo komponentov serverovej miestnosti (napríklad napájacie zdroje), n + 1 redundancia poskytuje len toľko zdrojov pre aktuálny dopyt, ako aj jednu ďalšiu jednotku na pokrytie zlyhania.

Aktívny / aktívny klaster

Klaster používajúci aktívny / aktívny dizajn bude mať dva alebo viac identicky nakonfigurovaných uzlov nezávisle obsluhujúcich klientov.

Ak by jeden uzol zlyhal, jeho klienti sa automaticky spoja s druhým uzlom a pokiaľ to zdroje dovolia, získajú úplný prístup k prostriedkom.

Po obnovení alebo výmene prvého uzla sa klienti opäť rozdelia medzi oba uzly servera.

Primárna výhoda fungovania aktívnych / aktívnych klastrov spočíva v schopnosti efektívne vyvážiť pracovné zaťaženie medzi uzlami a dokonca aj sieťami. Nástroj na vyrovnávanie zaťaženia - ktorý smeruje všetky požiadavky klientov na dostupné servery - je nakonfigurovaný tak, aby monitoroval aktivitu uzlov a sietí a používal nejaký vopred určený algoritmus na smerovanie prenosu do týchto uzlov, ktoré to najlepšie zvládnu. Pravidlá smerovania môžu postupovať podľa vzorca „každý s každým“, keď sa požiadavky klientov jednoducho striedajú medzi dostupnými uzlami, alebo podľa prednastavenej váhy, keď je jeden uzol v určitom pomere uprednostňovaný pred iným.

Pasívny uzol fungujúci ako náhrada za partnera v konfigurácii aktívneho / pasívneho klastra za partnera poskytuje významnú zabudovanú redundanciu. Ak vaša prevádzka bezpodmienečne vyžaduje nepretržitú službu a plynulé prechody po zlyhaní, potom by vaším cieľom mala byť nejaká variácia aktívnej / pasívnej architektúry.

Zdieľané nič a klastre zdieľaného disku

Jedným z hlavných princípov distribuovaného výpočtu je zabrániť tomu, aby sa vaša prevádzka spoliehala na jeden jediný bod zlyhania. To znamená, že každý zdroj by mal byť buď aktívne replikovaný (redundantný), alebo nezávisle vymeniteľný (failover) a nemal by existovať jediný prvok, ktorého zlyhanie by mohlo znefunkčniť celú vašu službu.

Teraz si predstavte, že máte spustených niekoľko desiatok uzlov, ktoré sa pri svojej funkcii spoliehajú na jediný databázový server. Aj keď zlyhanie ľubovoľného počtu uzlov nebude mať vplyv na ďalšie zdravie tých uzlov, ktoré zostanú, v prípade spustenia databázy by sa celý klaster stal zbytočným. Uzly v klastri zdieľaného nič však (zvyčajne) budú udržiavať svoje vlastné databázy, takže - za predpokladu, že sú správne synchronizované a nakonfigurované na zabezpečenie nepretržitej transakcie - na ne nebude mať vplyv žiadne vonkajšie zlyhanie.

To bude mať výraznejší dopad na klaster s vyrovnaným zaťažením, pretože každý uzol s vyrovnaným zaťažením má neustálu a kritickú potrebu súčasného prístupu k údajom. Pasívny uzol v jednoduchom systéme pre prípad zlyhania by však mohol nejaký čas prežiť bez prístupu.

Aj keď také nastavenie môže spomaliť spôsob, akým klaster reaguje na niektoré požiadavky - čiastočne preto, že obavy zo zlyhaní split-brain môžu vyžadovať pravidelné oplotenie prostredníctvom stonithu - kompromis môže byť odôvodnený pre nasadenia kritické pre misie, kde je hlavným aspektom spoľahlivosť.

Dostupnosť

Pri navrhovaní vášho klastra budete musieť mať celkom dobrý pocit z toho, ako tolerantný môžete byť k zlyhaniu. Alebo inými slovami, vzhľadom na potreby ľudí alebo strojov, ktoré využívajú vaše služby, ako dlho môže trvať prerušenie služby, kým davy ľudí preletia prednými bránami s vidlami a horiacimi pochodňami. Je dôležité to vedieť, pretože množstvo nadbytočnosti, ktoré zabudujete do svojho návrhu, bude mať obrovský vplyv na prestoje, ktorým nakoniec čelíte.

Je zrejmé, že systém, ktorý vybudujete pre službu, ktorá môže na víkend zlyhať bez toho, aby si to niekto všimol, sa bude veľmi líšiť od webu elektronického obchodu, ktorého zákazníci očakávajú nepretržitý prístup. Prinajmenšom by ste sa mali všeobecne zamerať na priemernú dostupnosť najmenej 99% - pri niektorých operáciách sa vyžadujú podstatne vyššie výsledky v reálnom svete. Čas 99% by sa premietol do straty menej ako celkovo štyroch dní z každého roka.

Existuje pomerne jednoduchý vzorec, ktorý môžete použiť na zostavenie užitočného odhadu dostupnosti (A). Cieľom je rozdeliť stredný čas pred zlyhaním na stredný čas pred zlyhaním plus stredný čas na opravu.

A = MTBF / (MTBF + MTTR)

Čím bližšie bude hodnota A k 1, tým viac bude váš klaster k dispozícii. Ak chcete získať realistickú hodnotu pre MTBF, pravdepodobne budete musieť venovať čas vystaveniu skutočného systému nejakým závažným trestom a jeho dôkladnému sledovaniu, či nevykazuje chyby softvéru, hardvéru a sietí. Predpokladám, že by ste si tiež mohli prečítať zverejnené metriky životného cyklu dodávateľov hardvéru alebo veľkých spotrebiteľov, ako je Backblaze, a získať tak predstavu o tom, ako dlho je možné očakávať, že vyťažený hardvér vydrží.

MTTR bude produktom v čase, keď vášmu klastru bude potrebné vymeniť funkčnosť serverového uzla, ktorý zlyhal (proces, ktorý je podobný, aj keď nie identický, po zotavení po katastrofe - ktorý sa zameriava na rýchlu výmenu zlyhaného hardvéru a pripojenia). Ideálne by to bola hodnota čo najbližšia nule sekúnd.

Problém je v tom, že v skutočnom svete existuje zvyčajne príliš veľa neznámych premenných, aby bol tento vzorec skutočne presný, pretože uzly s rôznymi softvérovými konfiguráciami a zostavené z hardvéru rôznych profilov a vekových skupín budú mať širokú škálu priemerných dĺžok života. Môže to však byť dobrý nástroj, ktorý vám pomôže identifikovať návrh klastra, ktorý je pre váš projekt najlepší.

S týmito informáciami môžete ľahko vygenerovať odhad, koľko celkových výpadkov bude vaša služba pravdepodobne mať počas celého roka.

S tým súvisiaca úvaha, ak nasadzujete svoje zdroje na poskytovateľovi platformy tretích strán, ako sú VMWare alebo Amazon Web Services, je dohoda o úrovni poskytovateľa služieb (SLA). Napríklad EC2 od Amazonu zaručuje, že ich výpočtové inštancie a úložné zariadenia blokov budú poskytovať mesačné percento prevádzkyschopnosti minimálne 99,95% - čo je menej ako päť hodín výpadku ročne. AWS bude vydávať kredity za mesiace, v ktorých minuli svoje ciele - hoci to nie je dosť na to, aby kompenzovali celkové obchodné náklady spojené s výpadkom. S týmito informáciami môžete zariadiť úroveň redundancie služieb, ktorá vyhovuje vašim jedinečným potrebám.

Ako poskytovateľ služieb svojim zákazníkom samozrejme budete musieť zverejniť svoju vlastnú SLA na základe odhadov MTBF a MTTR.

Spracovanie relácie

Pre akýkoľvek vzťah server - klient je potrebné údaje generované stavovými reláciami HTTP uložiť tak, aby boli dostupné pre budúce interakcie. Klastrové architektúry môžu do týchto vzťahov vniesť vážnu zložitosť, pretože konkrétny server, s ktorým klient alebo používateľ interaguje, sa môže medzi jednotlivými krokmi meniť.

Pre ilustráciu si predstavte, že ste prihlásení na Amazon.com, prechádzate ich knihy o školení LPIC a pravidelne pridávate položky do košíka (dúfajme, že viac kópií tejto knihy). V čase, keď budete pripravení na zadanie platobných údajov a odhlásenie, server, ktorý ste používali na prehliadanie, už nemusí existovať. Ako bude váš súčasný server vedieť, ktoré knihy ste sa rozhodli kúpiť?

Neviem presne, ako to Amazon rieši, ale problém sa často rieši pomocou nástroja na replikáciu údajov, ako je memcached bežiaci na

externý uzol (alebo uzly). Cieľom je poskytnúť neustály prístup k spoľahlivému a konzistentnému zdroju údajov každému uzlu, ktorý by to mohol potrebovať.

Tento článok je upravený z časti „ Naučte sa virtualizáciu systému Linux a vysokú dostupnosť: pripravte sa na certifikačnú skúšku LPIC-3 304 “. Pozrite si moje ďalšie knihy o správe AWS a Linuxu , vrátane Linuxu v akcii a Linuxu v pohybe  - hybridného kurzu zloženého z viac ako dvoch hodín videa a asi 40% textu systému Linux v akcii.