Software vysoké dostupnosti - High availability software

Software vysoké dostupnosti je software používaný k zajištění, že systémy jsou spuštěné a většinu času dostupné. Vysoká dostupnost je vysoké procento času, kdy systém funguje. Lze jej formálně definovat jako (1 - (prostoj / celkový čas)) * 100%. I když se minimální požadovaná dostupnost liší podle úkolu, systémy se obvykle snaží dosáhnout dostupnosti 99,999% (5 devíti). Tato vlastnost je slabší než odolnost proti chybám, která se obvykle snaží zajistit 100% dostupnost, i když s výraznými cenovými a výkonovými pokutami.

Software s vysokou dostupností se měří podle jeho výkonu při selhání subsystému, jeho schopnosti obnovit službu ve stavu blízkém stavu systému v době původního selhání a jeho schopnosti provádět další úlohy ovlivňující službu (například software aktualizace nebo změny konfigurace) způsobem, který eliminuje nebo minimalizuje prostoje. Všechny chyby, které ovlivňují dostupnost - hardware, software a konfiguraci, je třeba odstranit pomocí softwaru High Availability Software, aby se maximalizovala dostupnost.

Funkce

Typický software s vysokou dostupností poskytuje funkce, které:

Povolte redundanci hardwaru a softwaru: Mezi tyto funkce patří:

  1. Objev hardwarových a softwarových entit,
  2. Přiřazení aktivních / pohotovostních rolí těmto entitám,
  3. Detekce vadných komponent,
  4. Oznámení nadbytečným součástem, že by se měly stát aktivními, a
  5. Schopnost škálovat systém.

Služba není k dispozici, pokud nemůže obsloužit všechny požadavky, které jsou na ni kladeny. Vlastnost „scale-out“ systému odkazuje na schopnost vytvářet více kopií subsystému za účelem řešení rostoucí poptávky a efektivně distribuovat příchozí práci do těchto kopií (Vyrovnávání zátěže (výpočet) ) pokud možno bez vypnutí systému. Software s vysokou dostupností by měl umožňovat škálování bez přerušení služby.

Povolit aktivní / pohotovostní komunikaci (zejména Checkpointing): Aktivní subsystémy musí komunikovat s pohotovostními subsystémy, aby zajistily, že pohotovostní režim je připraven převzít místo, kde aktivní skončil. Software s vysokou dostupností může poskytovat abstrakce komunikace, jako jsou nadbytečné fronty zpráv a událostí, které pomáhají aktivním subsystémům v této úloze. Důležitý koncept zvaný „kontrolní bod“ je navíc vyhrazen vysoce dostupnému softwaru. V systému s kontrolním bodem identifikuje aktivní subsystém veškerý svůj kritický stav a pravidelně aktualizuje pohotovostní režim se všemi změnami tohoto stavu. Tato myšlenka se běžně abstrahuje jako distribuovaná hash tabulka - aktivní zapisuje záznamy klíč / hodnota do tabulky a čte z ní aktivní i pohotovostní subsystémy. Na rozdíl od „cloudové“ distribuované tabulky hash (Chord (peer-to-peer), Kademlia atd.) je kontrolní bod plně replikován. To znamená, že všechny záznamy v hash tabulce „kontrolního bodu“ jsou čitelné, pokud je spuštěna jedna kopie.[1] Další technika, nazývaná [kontrolní bod aplikace], pravidelně ukládá celý stav programu.[2]

Povolit upgrady v provozu: In Service Software Upgrade je schopnost upgradovat software bez zhoršení služby. Obvykle se implementuje v redundantních systémech provedením takzvaného „postupného“ upgradu - upgradováním pohotovostního režimu, zatímco aktivní poskytuje službu, selháním a poté upgradováním starého aktivního. Další důležitou funkcí je schopnost rychle přejít zpět na starší verzi softwaru a konfiguraci, pokud nová verze selže.[3][4]

Minimalizujte latenci pohotovostního režimu a zajistěte správnost pohotovostního režimu: Latence pohotovostního režimu je definována jako doba mezi okamžikem, kdy je pohotovostní režim aktivován, a okamžikem, kdy skutečně poskytuje službu. „Horké“ pohotovostní systémy jsou ty, které aktivně aktualizují vnitřní stav v reakci na aktivní kontrolní body systému, což má za následek výpadky milisekund. „Studené“ pohotovostní systémy jsou offline, dokud aktivní selže a obvykle se restartují ze „základního“ stavu. Například mnoho cloudových řešení restartuje virtuální stroj na jiném fyzickém počítači, pokud selže základní fyzický stroj. „Studený“ výpadek latence v pohotovostním režimu se může pohybovat od 30+ sekund do několika minut. A konečně, „teplý“ pohotovostní režim je neformální pojem zahrnující všechny běžící systémy, které musí být ještě aktivovány, ale musí provést určité interní zpracování. Například teplý pohotovostní systém může zpracovávat úlohy s nízkou prioritou - když aktivní selže, zruší tyto úlohy a přečte stav kontrolního bodu aktivovaného před obnovením služby. Teplé pohotovostní latence závisí na tom, kolik dat je zkontrolováno, ale obvykle mají latenci několik sekund.

Architektura systému

Software s vysokou dostupností může pomoci inženýrům vytvářet složité systémové architektury, které jsou navrženy tak, aby minimalizovaly rozsah poruch a zpracovávaly konkrétní režimy selhání. „Normální“ porucha je definována jako chyba, kterou lze řešit softwarovou architekturou, zatímco „katastrofická“ porucha je definována jako chyba, která není zpracována. Katastrofální porucha proto způsobí výpadek služby. Software však může stále výrazně zvýšit dostupnost automatickým návratem do stavu služby, jakmile dojde k nápravě katastrofické poruchy.

Nejjednodušší konfigurace (nebo „model redundance“) je 1 aktivní, 1 pohotovostní režim nebo 1 + 1. Další běžnou konfigurací je N + 1 (N aktivní, 1 pohotovostní režim), která snižuje celkové náklady na systém tím, že má méně pohotovostních subsystémů. Některé systémy používají plně aktivní model, který má tu výhodu, že „pohotovostní“ subsystémy jsou neustále ověřovány.

Příklad architektury systému s vysokou dostupností softwaru

Konfigurace lze také definovat pro aktivní systémy, horký pohotovostní režim a studený pohotovostní režim (nebo nečinný), čímž se rozšíří tradiční nomenklatura „aktivní + pohotovostní režim“ na „aktivní + pohotovostní režim + nečinný“ (např. 5 + 1 + 1). Pro práci s nižší prioritou jsou obvykle aktivní subsystémy „studený pohotovostní režim“ nebo „nečinný“. Někdy jsou tyto systémy umístěny daleko od jejich redundantního páru ve strategii zvané geografická redundance.[5] Tato architektura se snaží zabránit ztrátě služby z fyzicky místních událostí (požár, povodeň, zemětřesení) oddělením nadbytečných strojů.

Sofistikované zásady mohou být specifikovány softwarem s vysokou dostupností, aby bylo možné odlišit software od chyb hardwaru a pokusit se o časově zpožděná restartování jednotlivých softwarových procesů, celých softwarových sad nebo celých systémů.

Použití v průmyslu

V posledních 20 letech se telekomunikační sítě a další složité softwarové systémy staly nezbytnou součástí obchodních a rekreačních aktivit.

"Současně [protože je ekonomika v útlumu] vyžaduje 60% téměř - to je šest z 10 podniků - 99,999." To jsou čtyři devíti nebo pět devíti hodin dostupnosti a provozuschopnosti jejich nejdůležitějších obchodních aplikací. A 9% respondentů, což je téměř jedna z 10 společností, tvrdí, že potřebují více než pět devíti provozních hodin. To tedy znamená, žádné prostoje. Jinými slovy, musíte mít skutečně neprůstřelné, bombové aplikace a hardwarové systémy. Takže víte, co používáte? Jedna věc je, že máte klastry s vysokou dostupností nebo máte dražší a složitější servery odolné proti chybám. “[6]

Telekomunikace: Software s vysokou dostupností je základní součástí telekomunikační zařízení protože výpadek sítě může mít za následek významnou ztrátu příjmů poskytovatelů telekomunikačních služeb a telefonický přístup k pohotovostním službám je důležitým problémem veřejné bezpečnosti.

Obrana / armáda: Software pro vysokou dostupnost si v poslední době našel cestu do obranných projektů jako levný způsob zajištění dostupnosti pro vozidla s posádkou a bez posádky[7]

Prostor: Software pro vysokou dostupnost je navržen pro použití zařízení odolných proti záření v kosmickém prostředí. Radiačně kalená elektronika je podstatně dražší a má nižší výkon než běžná zařízení. Software s vysokou dostupností, který běží na jednom nebo dvojici řadičů vytvrzených rad, však může spravovat mnoho redundantních vysoce výkonných počítačů nerad-hard, což může potenciálně selhat a resetovat je v případě poruchy.[8]

Použít v cloudu

Typický mrak služby poskytují sadu počítačů v síti (typicky virtuální stroj) se standardním operačním systémem serveru, jako je Linux. Počítače mohou často komunikovat s jinými instancemi ve stejném datovém centru zdarma (síť nájemce) a s externími počítači za poplatek. Cloudová infrastruktura může poskytovat jednoduchou detekci chyb a restart na úrovni virtuálního stroje. Restartování však může trvat několik minut, což má za následek nižší dostupnost. Cloudové služby navíc nemohou detekovat selhání softwaru ve virtuálních počítačích. Software s vysokou dostupností spuštěný uvnitř cloudových virtuálních strojů dokáže detekovat selhání softwaru (a virtuálního stroje) během několika sekund a může pomocí kontrolního bodu zajistit, že pohotovostní virtuální stroje jsou připraveny převzít službu.

Standardy

Fórum dostupnosti služeb definuje standardy pro vysokou dostupnost s vědomím aplikací.[9]

Viz také

Reference

  1. ^ Fórum dostupnosti služeb. „Checkpoint Service“.
  2. ^ Cooperman, Gene. Msgstr "Distribuované vícevláknové kontrolní body". dmtcp.sourceforge.net. Chybějící nebo prázdný | url = (Pomoc)
  3. ^ Cisco Systems, Inc. „Vysoká dostupnost softwaru CISCO IOS v servisním softwaru“ (PDF). www.cisco.com.
  4. ^ Juniper Networks. „Porozumění upgradu servisního softwaru“.
  5. ^ Bauer, Eric; Adams, Randee; Eustace, Daniel (listopad 2011). Beyond Redundancy: How Geographic Redundancy can zlepšit dostupnost služeb a spolehlivost počítačových systémů. Wiley-IEEE Press. ISBN  978-1-118-03829-1.
  6. ^ DiDio, Laura. „Trendy ve vysoké dostupnosti a odolnosti proti chybám“.
  7. ^ OpenClovis. „SAIC vybírá OpenClovis SAFPlus pro projekt ACTUV“.
  8. ^ Samson, John. „Spolehlivá architektura více procesorů (DM) pro vesmírné aplikace“ (PDF). Archivovány od originál (PDF) dne 04.02.2015. Citováno 2015-02-04.
  9. ^ „Fórum dostupnosti služeb - Domů“. www.saforum.org. Archivovány od originál dne 06.10.2008. Citováno 2020-01-14.

externí odkazy