Klastr převzetí služeb při selhání

Failover cluster ( anglicky  High-Availability cluster , HA cluster  - high-availability cluster ) - cluster (skupina serverů ), navržený v souladu s technikami vysoké dostupnosti a zaručující minimální prostoje kvůli hardwarové redundanci. Bez klastrování způsobí selhání serveru selhání aplikací nebo síťových služeb , které podporuje.jsou nedostupné, dokud nebudou obnoveny. Klastrování s podporou převzetí služeb při selhání tuto situaci opravuje restartováním aplikací na jiných uzlech v clusteru bez zásahu správce, pokud jsou zjištěna selhání hardwaru nebo softwaru. Proces restartování je známý jako převzetí služeb při selhání . V rámci tohoto procesu může klastrovací software dále konfigurovat uzel před spuštěním aplikace na něm (například importovat a připojit příslušné systémy souborů, překonfigurovat síťový hardware nebo spustit jakékoli pomocné aplikace).

Klastry s podporou převzetí služeb při selhání jsou široce používány pro podporu kritických databází , síťových úložišť souborů, obchodních aplikací a systémů zákaznických služeb, jako jsou stránky elektronického obchodování .

Implementace HA clusterů jsou pokusy o dosažení chybové odolnosti clusteru jako celku odstraněním kritických bodů selhání, včetně redundance výpočetního výkonu, síťových připojení a ukládání dat, kombinovaných do redundantní SAN .

Požadavky na architekturu aplikace

Ne každá aplikace může běžet ve vysoce dostupném clusterovém prostředí. Vhodná rozhodnutí by měla být přijata v rané fázi vývoje softwaru. Aby aplikace běžela v clusteru HA, musí splňovat alespoň následující technické požadavky, z nichž poslední dva jsou kritické pro její spolehlivý provoz v clusteru a které je nejobtížnější plně splnit:

• Měl by existovat relativně jednoduchý způsob, jak spustit, zastavit, vynutit zastavení a zkontrolovat stav aplikace. V praxi to znamená, že aplikace musí mít rozhraní příkazového řádku nebo skripty pro její správu, včetně práce s více spuštěnými instancemi aplikace.
• Aplikace musí být schopna využívat sdílené úložiště dat ( NAS / SAN ).
• Je velmi důležité, aby aplikace ukládala co nejvíce dat o svém aktuálním stavu do nezničitelného sdíleného úložiště. Obdobně je stejně důležitá schopnost aplikace restartovat na jiném uzlu ve stavu před selháním pomocí stavových dat ze sdíleného úložiště.
• Aplikace nesmí poškodit data při zhroucení nebo obnovení z uloženého stavu.

Stavební schémata

Nejběžnější dvouuzlové HA clustery představují minimální konfiguraci požadovanou pro zajištění odolnosti proti chybám. Často ale clustery obsahují mnohem více, někdy i desítky uzlů. Všechny tyto konfigurace lze obecně popsat jedním z následujících modelů:

• Aktivní / aktivní – Část provozu zpracovaného neúspěšným uzlem je přesměrována na nějaký pracovní uzel nebo distribuována mezi několik pracovních uzlů. Toto schéma se používá, když mají uzly homogenní softwarovou konfiguraci a provádějí stejný úkol.
• Aktivní / pasivní - Má plnou redundanci (zdravou kopii) každého uzlu. Rezerva je uvedena do provozu pouze při poruše příslušného hlavního uzlu. Tato konfigurace vyžaduje značný redundantní hardware.
• N + 1 - Má jeden plnohodnotný záložní uzel, na který v okamžiku poruchy přechází role neúspěšného uzlu. V případě heterogenní softwarové konfigurace primárních uzlů musí být sekundární uzel schopen převzít roli kteréhokoli z primárních uzlů, za které je odpovědný. Toto schéma se používá v klastrech obsluhujících několik heterogenních služeb běžících současně; v případě jedné služby se taková konfigurace zvrhne na Aktivní / pasivní.
• N + M – Pokud jeden klastr obsluhuje více služeb, včetně jednoho redundantního uzlu nemusí být dostatečné pro adekvátní úroveň redundance. V takových případech cluster obsahuje několik redundantních serverů, jejichž počet je kompromisem mezi cenou řešení a požadovanou spolehlivostí.
• N-to-1 – Umožňuje pohotovostnímu uzlu dočasně se připojit do režimu online, dokud není obnoven uzel se selháním, poté se původní zatížení vrátí do primárního uzlu, aby byla zachována původní úroveň dostupnosti systému.
• N-to-N je kombinace aktivních / aktivních a N + M clusterů. V clusteru N-to-N jsou služby, systémové instance nebo připojení z neúspěšného uzlu přerozděleny do zbývajících aktivních uzlů. To eliminuje (stejně jako v aktivním / aktivním schématu) potřebu samostatného pohotovostního uzlu, ale zároveň musí mít všechny uzly clusteru určitou nadbytečnou kapacitu nad minimální požadovanou kapacitu.

Termíny logický hostitel nebo klastrovaný logický hostitel se používají k označení síťové adresy, která se používá pro přístup ke službám poskytovaným klastrem. Logické ID hostitele není vázáno na jediný uzel clusteru. Je to vlastně síťová adresa/název, která je spojena se službou (službami) poskytovanými clusterem. Pokud dojde k výpadku uzlu clusteru, například s běžící databází, bude databáze restartována na jiném uzlu clusteru a síťová adresa, kde uživatelé přistupují k databázi, bude zachována pro jakýkoli nový uzel, takže uživatelé budou mít stále přístup k databázi.

Spolehlivost jednoho uzlu

Klastry HA kromě popsaných schémat redundance mezi uzly využívají všechny metody obvykle používané v samostatných (neklastrových) systémech a síťové infrastruktuře k maximalizaci spolehlivosti. Tyto zahrnují:

• Redundance a replikace disku: Selhání některých interních disků nevede k selhání systému. DRBD je jedním příkladem.
• Redundance externích síťových připojení : Selhání kabelu, selhání přepínače nebo síťového rozhraní nevede k úplnému odpojení od sítě.
• Interní připojení redundantní sítě úložiště (SAN) : Selhání kabelu, selhání přepínače nebo síťového rozhraní nezpůsobí, že servery ztratí připojení k úložišti (to by narušilo nesdílenou architekturu).
• Schémata redundantního napájení pro různá zařízení, obvykle chráněná nepřerušitelnými zdroji napájení , a redundantní zdroje napájení : selhání jednoho vstupu , kabelu, UPS nebo PSU nevede ke kritickému výpadku napájení systému.

Měření doby provozuschopnosti jednotlivých uzlů pomáhají minimalizovat šance na využití nativních mechanismů klastrování při selhání. V případě aktivace posledně jmenovaného může dojít k přerušení přístupu ke službě, byť jen na krátkou dobu, a je vhodnější předcházet kritickým poruchám zařízení.

Algoritmy obnovy po selhání

Systémy, které řeší chyby v distribuovaných počítačových systémech, používají různé strategie k řešení následků selhání. Například Apache Cassandra API Hector (API) poskytuje tři možnosti pro zpracování chyb:

• Fail Fast , ve skriptu - "FAIL_FAST", jednoduše vrátí chybu klientovi, když je uzel nedostupný.
• Při selhání, Try One - Next Available , ve skriptu - "ON_FAIL_TRY_ONE_NEXT_AVAILABLE" znamená, že když uzel selže, systém se pokusí přenést požadavek na jiný uzel, nejvolnější, a po prvním neúspěšném pokusu vrátí chybu.
• On Fail, Try All , ve skriptu - "ON_FAIL_TRY_ALL_AVAILABLE" znamená, že systém po prvním neúspěšném pokusu postupně vyzkouší všechny dostupné uzly a teprve potom vrátí chybu.

Pro kontrolu stavu uzlů v clusteru se obvykle z každého z uzlů přenáší nepřetržitý periodický signál („puls“, anglicky  heartbeat ) ve vnitřní síti clusteru, podle jehož přítomnosti řídící software posuzuje normální provoz. sousedních uzlů. S tím souvisí ne zcela zřejmý, ale závažný problém „split-brain_(computing)“ -  v případě současného přerušení mnoha spojení ve vnitřní síti clusteru z důvodu výpadku napájení, síťového zařízení apod. , uzel nebude schopen tuto situaci správně zvládnout, začne se chovat, jako by všechny ostatní uzly clusteru selhaly, čímž se spustí duplicitní služby, které již v clusteru běží, což může vést k poškození dat ve sdíleném úložišti.

Viz také

• Cluster (skupina počítačů)
• Server (hardware)
• Sálový počítač
• Serverovna

Poznámky

Odkazy