Aktivní-aktivní nebo aktivní-pasivní: který potřebujete?

V pondělí ráno systém objednávek reaguje pomalu a poté se stává nedostupným. E-shop nadále přijímá objednávky, ale sklad je nevidí, zákaznický servis nemůže poskytnout přesný stav a fakturace se zastaví. V takových případech se stává obchodní otázkou, zda aktivně-aktivní nebo aktivně-pasivní architektura systému chrání kritické služby.

Oba přístupy jsou často považovány pouze za rozhodnutí o infrastruktuře. Ve skutečnosti určují, co se stane s provozem, když dojde k výpadku serveru, aplikace, síťového připojení nebo dokonce celé lokality. Správná volba nezávisí na tom, která zní pokročileji, ale na tom, které obchodní procesy se nesmí zastavit, kolik ztráty dat je přijatelné a jak dobře je organizace schopna bezpečně provozovat zvolenou řešení.

Co znamená aktivně-aktivní a aktivně-pasivní provoz?

V aktivně-aktivním nastavení provádí dvě nebo více instancí systému současně významnou práci. Například dva aplikační servery současně obsluhují uživatele e-shopu a zátěžový vyrovnávač rozděluje požadavky mezi ně. Pokud jedna instance vypadne, druhá pokračuje v provozu, obvykle bez povšimnutí nebo s krátkým přerušením.

V aktivně-pasivním nastavení pracuje primární systém, zatímco sekundární je v pohotovosti. Záložní systém průběžně nebo v pravidelných intervalech přijímá data z primárního systému, ale v normálním provozu neobsluhuje uživatele. V případě chyby přebírá roli. To se nazývá failover, tedy automatické nebo ruční přepnutí.

Na první pohled se může zdát, že aktivně-aktivní je jednoznačně lepší řešení: dva fungující systémy jsou lepší než jeden fungující a jeden čekající. To však platí pouze tehdy, pokud aplikace, správa dat, síť a provozní procesy jsou schopny zvládnout paralelní provoz. Nesprávně navržené aktivně-aktivní prostředí může být nejen dražší, ale také způsobovat obtížně diagnostikovatelné chyby.

Dostupnost není totéž co více serverů

Mnoho společností má druhý server, zálohu nebo dokonce záložní internetové připojení, přesto nelze hovořit o skutečně vysoké dostupnosti. Důvod je jednoduchý: příčinou výpadku často není samotný server.

Pokud e-shop a skladová evidence závisí na stejné databázi, síťovém zařízení nebo externím poskytovateli, dva aplikační servery nevyřeší společnou příčinu chyby. Totéž platí, když systém funguje, ale jedinečný Excel soubor potřebný ke zpracování příchozích objednávek je pouze na počítači jednoho zaměstnance.

Dostupnost by proto měla být chápána jako obchodní služba. Nejde o to, zda běží virtuální stroj, ale zda sklad může vydat zboží, zda je vytvořen dodací list, zda objednávka dorazí k fakturaci a zda vedení dostává spolehlivé informace o provozu.

Začněte u kritických bodů procesu

Je vhodné nejprve upřesnit, které procesy snesou jak dlouhý výpadek. Několikahodinový výpadek interního dokumentového úložiště může být nepříjemný, ale zvládnutelný. Systém řízení výroby, online platební proces nebo zpracování objednávek může po deseti minutách způsobit přímou ztrátu příjmů a důvěry zákazníků.

Stejně důležitá je hranice ztráty dat. Pokud lze systém obnovit z dat starých hodinu, znamená to jiné technické řešení a náklady, než když je povolena maximálně několikasekundová ztráta dat. Tyto úrovně jsou obvykle popsány cílovými hodnotami RTO a RPO. RTO udává, za jak dlouho musí být služba obnovena. RPO pak, kolik dat může být ztraceno ve srovnání se stavem před chybou.

Za čísly by vždy měly stát konkrétní obchodní důsledky. Cílem by nemělo být mít v plánu "vysokou dostupnost", ale například to, že zpracování objednávek může být přerušeno maximálně na 15 minut a žádná zaplacená objednávka nesmí být ztracena.

Kdy je aktivně-pasivní model opodstatněný?

Aktivně-pasivní architektura je pro mnoho rostoucích společností rozumnou a efektivní volbou. Zejména pokud je správa stavu aplikace složitá, závisí na jednom zapisovači databáze nebo software nepodporuje paralelní obsluhu.

Představme si výrobní společnost, kde výrobní data spravuje centrální systém. K systému je připojeno několik pracovních stanic, ale konzistence databáze je prioritou. Zde může být pečlivě vybudovaná primární-záložní databáze s dokumentovaným postupem přepnutí, pravidelnými testy a odpovídajícím monitorováním spolehlivější než nucené aktivně-aktivní řešení.

Výhodou aktivně-pasivního modelu je menší provozní složitost. Je méně konfliktů z paralelního zápisu, jednodušší může být hledání chyb a provozní tým má jasnější představu, který systém je primární. Nevýhodou je, že přepnutí může trvat čas, zejména pokud je nutné manuální rozhodnutí, změna DNS, spuštění služby nebo kontrola dat.

"Pasivní" nesmí znamenat zapomenutý. Záložní prostředí je třeba aktualizovat, sledovat a testovat. Nouzový plán, který existuje pouze na papíře, obvykle selže právě tehdy, když ho organizace nejvíce potřebuje. nouzový plán obvykle selže právě tehdy, když ho organizace nejvíce potřebuje.

Kdy přináší aktivně-aktivní model skutečnou hodnotu?

Aktivně-aktivní řešení je opodstatněné tam, kde je nepřetržitá dostupnost služby přímo spojena s příjmy, výrobou nebo smluvními závazky. To může být například velký e-shop, zákaznický portál, nepřetržitě fungující logistický systém nebo aplikace, jejíž zatížení se periodicky výrazně zvyšuje.

Model může poskytnout nejen odolnost proti chybám, ale i kapacitu. Pokud dva aktivní aplikační servery rozdělují zátěž, lze zdroje využít i v běžném provozu. Při výpadku jedné instance však zbývající kapacita musí stále zvládnout kritické zatížení. To v mnoha plánech chybí: jsou dva servery, ale oba pracují i v běžném dni na 70-80% kapacity. Při výpadku je tedy systém technicky dostupný, ale obchodně se stává nepoužitelně pomalým.

V aktivně-aktivním prostředí je největší výzvou obvykle data. Pokud dvě lokality nebo dvě instance databáze přijímají změny současně, je třeba regulovat, která data jsou v případě konfliktu platná. Stejnou položku zásob nemohou nezávisle prodat dva kanály. Systém potřebuje jednotná obchodní pravidla, správu transakcí a kontrolovanou synchronizaci.

Proto ne všechny aplikace lze nebo je vhodné udělat aktivně-aktivními. Často je správným řešením, že webové služby jsou aktivně-aktivní, zatímco databáze nebo kritický backendový proces zůstává aktivně-pasivní. Vysoká dostupnost je často kombinací různých vrstev, nikoli jedním označením.

Přepnutí funguje pouze tehdy, pokud je pravidelně procvičováno

Většina rizik se neobjevuje na schématu architektury, ale v provozu. Kdo je oprávněn iniciovat přepnutí? Jak je vidět, že došlo k opravdové chybě, a ne jen k dočasnému zpomalení? Jak se ověřuje, že sekundární systém je skutečně aktuální? Kdo informuje uživatele, pokud je služba částečně dostupná?

Zvláštní pozornost vyžaduje situace split-brain. K tomu dochází, když se dvě instance systému navzájem považují za chybné a obě začnou fungovat jako primární. Pokud obě mohou zapisovat do stejných obchodních dat, nekonzistence dat se rychle stává vážným problémem. Bez vhodných quorum mechanismů, síťového designu a strategie databáze se redundance sama stává zdrojem chyb.

Plánovanou údržbu je třeba také zkoumat. Dobrý model dostupnosti je cenný nejen při neočekávaném výpadku. Také když je třeba bezpečnostní aktualizace, výměna hardwaru nebo změna verze. Pokud každá změna vyžaduje noční odstávku a ruční zásah, zůstává dlouhodobé provozní riziko systému vysoké.

Správné rozhodnutí vychází z procesu

Společnost nepotřebuje aktivně-aktivní řešení jen proto, že je používají velké technologické firmy. A neměla by volit aktivně-pasivní nastavení jen proto, že se zdá levnější. Rozhodnutí by mělo být vedeno tím, jak proudí informace od objednávky k plnění, od výrobního příkazu k hotovému výrobku nebo od požadavku zákazníka k faktuře.

Před návrhem systému je třeba odhalit závislosti: z které aplikace data přicházejí, kde dochází k ručnímu zadávání dat, který systém je jediným spolehlivým zdrojem a kde se práce zastaví při výpadku. V přístupu CGAT je technologická architektura odpovědí na tyto provozní otázky, nikoli samostatným seznamem produktů.

Nejlepší design nemusí být nutně nejsložitější. Dobrá je ta, jejíž chování při výpadku je známé, přepnutí je kontrolované, data jsou chráněná a kterou může vlastní tým nebo určený partner dlouhodobě bezpečně provozovat. Pokud to nelze jednoznačně říci před dalším plánovaným výpadkem nebo neočekávanou chybou, není potřeba další server, ale jasnější provozní plán.