Aktív-aktív alebo aktív-pasívny: ktorý potrebujete?

V pondelok ráno systém objednávok reaguje pomaly a potom sa stáva nedostupným. Webshop naďalej prijíma objednávky, ale sklad ich nevidí, zákaznícky servis nemôže poskytnúť presný stav a fakturácia sa zastaví. Vtedy sa stáva obchodnou otázkou, či aktívno-aktívna alebo aktívno-pasívna architektúra systému chráni kritické služby.

Tieto dva prístupy sa často považujú len za rozhodnutie o infraštruktúre. V skutočnosti určujú, čo sa stane s prevádzkou, keď vypadne server, aplikácia, sieťové pripojenie alebo dokonca celé miesto. Dobrá voľba nezávisí od toho, ktorá znie pokročilejšie, ale od toho, ktoré obchodné procesy nemôžu byť prerušené, koľko straty dát je prijateľné a aká je schopnosť organizácie bezpečne prevádzkovať zvolenú riešenie.

Čo znamená aktívno-aktívna a aktívno-pasívna prevádzka?

V aktívno-aktívnom nastavení dva alebo viac systémových inštancií súčasne vykonáva významnú prácu. Napríklad dva aplikačné servery paralelne obsluhujú používateľov webshopu a vyvažovač záťaže rozdeľuje medzi nimi požiadavky. Ak jedna inštancia vypadne, druhá pokračuje v prevádzke, zvyčajne bez povšimnutia alebo s krátkym prerušením.

V aktívno-pasívnom nastavení pracuje primárny systém, zatiaľ čo sekundárny je v pohotovosti. Záložný systém priebežne alebo v určených intervaloch prijíma dáta z primárneho systému, ale v normálnej prevádzke neobsluhuje používateľov. V prípade chyby preberá úlohu. Toto sa nazýva failover, teda automatické alebo manuálne prepnutie.

Na prvý pohľad sa môže zdať, že aktívno-aktívne je jednoznačne lepšie riešenie: dva fungujúce systémy sú lepšie ako jeden fungujúci a jeden čakajúci. To však platí len vtedy, ak aplikácia, správa dát, sieť a prevádzkové procesy dokážu zvládnuť paralelnú prevádzku. Nesprávne navrhnuté aktívno-aktívne prostredie môže byť nielen drahšie, ale aj spôsobovať ťažšie diagnostikovateľné chyby.

Dostupnosť nie je rovnaká ako viac serverov

Mnoho spoločností má druhý server, zálohu alebo dokonca záložné internetové pripojenie, ale stále nemôžeme hovoriť o skutočne vysokej dostupnosti. Dôvod je jednoduchý: príčinou výpadku často nie je samotný server.

Ak webshop a evidencia zásob závisia od tej istej databázy, sieťového zariadenia alebo externého poskytovateľa, dva aplikačné servery nevyriešia príčinu spoločnej chyby. To isté platí v prípade, keď systém funguje, ale na spracovanie prichádzajúcich objednávok je potrebný jedinečný Excel súbor, ktorý sa nachádza len na počítači jedného zamestnanca.

Dostupnosť by sa preto mala chápať ako obchodná služba. Otázka nie je, či beží virtuálny stroj, ale či sklad môže odovzdať tovar, či je pripravený dodací list, či objednávka dorazí k fakturácii a či vedenie dostáva spoľahlivé informácie o prevádzke.

Začnite na kritických miestach procesu

Najprv je potrebné presne určiť, ktoré procesy koľko výpadkov znesú. Niekoľkohodinový výpadok interného dokumentačného úložiska môže byť nepríjemný, ale zvládnuteľný. Riadiaci systém výroby, online platobný proces alebo spracovanie objednávok môže po desiatich minútach spôsobiť priamu stratu príjmov a dôvery zákazníkov.

Rovnako dôležitá je hranica straty dát. Ak sa systém môže obnoviť z dát starých jednu hodinu, znamená to iné technické riešenie a náklady, ako keď je prípustná strata dát maximálne niekoľko sekúnd. Tieto úrovne sa zvyčajne popisujú cieľovými hodnotami RTO a RPO. RTO udáva, za aký čas sa musí služba obnoviť. RPO zase, koľko dát môže byť stratených v porovnaní so stavom pred chybou.

Za číslami by mal vždy stáť konkrétny obchodný dôsledok. Cieľom by nemalo byť, aby v pláne figurovala „vysoká dostupnosť“, ale napríklad to, že spracovanie objednávok môže byť prerušené maximálne na 15 minút a žiadna zaplatená objednávka sa nesmie stratiť.

Kedy je aktívno-pasívny model opodstatnený?

Aktívno-pasívna architektúra je pre mnoho rastúcich spoločností rozumnou a efektívnou voľbou. Najmä vtedy, keď je správa stavu aplikácie zložitá, je založená na jednom zapisovači databázy alebo keď softvér nepodporuje paralelné obsluhovanie.

Predstavme si výrobnú spoločnosť, kde výrobné dáta spravuje centrálny systém. K systému je pripojených viacero pracovných staníc, ale konzistencia databázy je prvoradá. Tu môže byť starostlivo vybudovaná primárno-pohotovostná databáza s dokumentovaným prepínacím postupom, pravidelnými testami a vhodným monitorovaním spoľahlivejšia ako nútené aktívno-aktívne riešenie.

Výhodou aktívno-pasívneho modelu je menšia prevádzková zložitosť. Menej je konfliktov dát z paralelných zápisov, jednoduchšie môže byť hľadanie chýb a prevádzkový tím má jasnejšie, ktorý systém je primárny. Nevýhodou je, že prepnutie môže trvať čas, najmä ak je potrebné manuálne rozhodnutie, zmena DNS, spustenie služby alebo kontrola dát.

„Pasívne“ nemôže znamenať, že sme na to zabudli. Záložné prostredie je potrebné aktualizovať, monitorovať a testovať. Plán núdzových situácií, ktorý existuje len na papieri, zvyčajne zlyhá práve vtedy, keď ho organizácia najviac potrebuje. plán núdzových situácií zvyčajne zlyhá práve vtedy, keď ho organizácia najviac potrebuje.

Kedy prináša aktívno-aktívny model skutočnú hodnotu?

Aktívno-aktívne riešenie je opodstatnené tam, kde nepretržitá dostupnosť služby priamo súvisí s príjmami, výrobou alebo zmluvnými záväzkami. Môže to byť napríklad veľký e-shop, zákaznícky portál, nepretržite fungujúci logistický systém alebo aplikácia, ktorej zaťaženie sa periodicky výrazne zvyšuje.

Model môže poskytovať nielen odolnosť voči chybám, ale aj kapacitu. Ak dva aktívne aplikačné servery rozdeľujú záťaž, zdroje môžu byť využité aj v normálnej prevádzke. Pri výpadku jednej inštancie však zostávajúca kapacita musí stále zvládnuť kritickú záťaž. To často chýba v plánoch: sú dva servery, ale oba pracujú už v bežný deň na 70-80 percent kapacity. Pri výpadku je teda systém technicky dostupný, ale obchodne stále nepoužiteľne pomalý.

V aktívno-aktívnom prostredí je najťažšou otázkou zvyčajne dáta. Ak dve miesta alebo dve databázové inštancie prijímajú úpravy súčasne, je potrebné regulovať, ktoré dáta sú platné v prípade konfliktu. Posledný kus zásob nemôže byť predaný dvoma kanálmi nezávisle od seba. Systém potrebuje jednotné obchodné pravidlá, spracovanie transakcií a kontrolovanú synchronizáciu.

Preto nie každú aplikáciu je možné alebo vhodné spraviť aktívno-aktívnou. Často je správnym riešením, že webové služby sú aktívno-aktívne, zatiaľ čo databáza alebo kritický proces na pozadí zostáva aktívno-pasívny. Vysoká dostupnosť je často kombináciou rôznych vrstiev, nie jedným označením.

Prepnutie funguje len vtedy, ak sa pravidelne cvičí

Väčšina rizík sa neobjavuje na nákrese architektúry, ale v prevádzke. Kto je oprávnený iniciovať prepnutie? Odkiaľ je vidieť, že došlo k skutočnej chybe, nie len k dočasnému spomaleniu? Ako sa kontroluje, že sekundárny systém je skutočne aktuálny? Kto informuje používateľov, ak je služba čiastočne dostupná?

Osobitnú pozornosť si vyžaduje situácia split-brain. Tá nastáva, keď sa dve systémové inštancie navzájom považujú za chybu a obe začnú fungovať ako primárne. Ak obe môžu zapisovať do rovnakých obchodných dát, nekonzistentnosť dát sa rýchlo stáva vážnym problémom. Bez vhodných quorum mechanizmov, sieťového návrhu a databázovej stratégie sa redundancia sama stáva zdrojom chýb.

Je potrebné preskúmať aj plánovanú údržbu. Dobrý model dostupnosti nie je cenný len pri neočakávaných výpadkoch. Aj vtedy, keď je potrebná bezpečnostná aktualizácia, výmena hardvéru alebo zmena verzie. Ak každá zmena vyžaduje nočný výpadok a manuálny zásah, dlhodobé prevádzkové riziko systému zostáva vysoké.

Správne rozhodnutie vychádza z procesu

Spoločnosť nepotrebuje aktívno-aktívne riešenie len preto, že ho používajú veľké technologické firmy. A nemusí si vybrať aktívno-pasívne nastavenie len preto, že sa zdá byť lacnejšie. Rozhodnutie by malo byť vedené tým, ako prúdia informácie od objednávky po splnenie, od výrobného pokynu po hotový výrobok alebo od zákazníckej požiadavky po faktúru.

Pred návrhom systému je potrebné odhaliť závislosti: z ktorej aplikácie prichádzajú dáta, kde sa vykonáva manuálny vstup dát, ktorý systém je jediným dôveryhodným zdrojom a kde sa práca zastaví pri výpadku. V prístupe CGAT je technologická architektúra odpoveďou na tieto prevádzkové otázky, nie samostatným zoznamom produktov.

Najlepšie riešenie nemusí byť najkomplikovanejšie. Dobrý systém je ten, ktorého správanie pri výpadku je známe, prepnutie je kontrolované, dáta sú chránené a ktorý môže byť dlhodobo bezpečne prevádzkovaný vlastným tímom alebo určeným partnerom. Ak to nie je možné jednoznačne povedať pred ďalším plánovaným výpadkom alebo neočakávanou chybou, potom nie je potrebný ďalší server, ale jasnejší prevádzkový plán.