Active active může mít více komponent a méně odolnosti CIO MAG

Aktivní provoz ve dvou lokalitách snižuje čas přepnutí, ale přidává nové způsoby selhání. Dokumentace cloudových architektur upozorňuje na synchronizaci dat, konflikty souběžných zápisů, konfigurační rozdíly a závislosti mezi lokalitami. Výzkumné systémy Dynamo a Spanner ukazují dva odlišné přístupy k dostupnosti a konzistenci. Oba zároveň dokazují, že distribuovaný stav vyžaduje konkrétní technické kompromisy, nikoli pouze druhou kopii infrastruktury.

Nejčastější omyl vzniká při počítání komponent. Dvě databáze, dva clustery a dva load balancery vypadají lépe než jedna sada. Pokud ale obě lokality sdílejí jedinou autoritu zápisu, identitu, DNS změnu nebo provozní tým, počet komponent nerovná se počet nezávislých cest k dodání služby.

Manažerské shrnutí

01Redundance potřebuje nezávislost. Druhá lokalita nepomůže proti poruše komponenty, kterou obě lokality sdílejí.

02Přeživší lokalita musí mít kapacitu. Přesměrování provozu bez rezervy může z lokálního incidentu vytvořit přetížení zdravé strany.

03Datový model určuje skutečný režim. Souběžné zápisy vyžadují konzistenci, rozdělení vlastnictví dat nebo vědomé řešení konfliktů.

Active active je datové rozhodnutí

U bezstavové vrstvy lze provoz rozdělit relativně snadno. Jakmile obě strany zapisují do stejného obchodního stavu, musí architektura rozhodnout, co se stane při síťovém oddělení. Dynamo upřednostnilo vysokou dostupnost a v některých poruchách připustilo pozdější řešení verzí a konfliktů. Spanner používá synchronní replikaci a mechanismus času, aby mohl nabídnout externí konzistenci napříč geograficky rozloženým systémem.

Z těchto výzkumných systémů neplyne, že jedna volba je univerzálně lepší. Plyne z nich, že dostupnost, konzistence a latence mají cenu v aplikačním návrhu. Objednávka, zůstatek a telemetrický údaj nemusí potřebovat stejný režim. Název architektury bez určení pravidel zápisu proto neříká, jak se služba zachová při rozdělení sítě.

Otázka	Skrytý dopad	Potřebný důkaz
Kde lze zapisovat	Konflikt, ztráta pořadí nebo vyšší latence	Test souběžných zápisů a síťového oddělení
Kdo přesměruje provoz	Závislost na DNS, control plane nebo ručním kroku	Přepnutí bez dostupnosti primární lokality
Kolik unese jedna strana	Přetížení zdravé lokality po výpadku druhé	Zátěžový test v režimu přeživší kapacity
Jak se nasazuje změna	Stejná chyba současně v obou lokalitách	Postupné nasazení s odděleným blast radius

ROZHODOVACÍ PRAVIDLO

Active active neschvalujte podle počtu lokalit. Vyžadujte důkaz, že každá strana samostatně dokončí kritickou transakci při ztrátě druhé strany a bez změny přes její control plane.

Společný osud se skrývá mimo diagram aplikace

Aplikační diagram často začíná load balancerem a končí databází. Skutečná dostupnost však závisí také na certifikátech, tajných hodnotách, registru image, času, správě identit, observabilitě a způsobu, jakým tým během incidentu provede změnu. Sdílený pipeline může během vadného releasu nasadit stejnou chybu na obě strany rychleji, než ji monitoring odhalí.

Nezávislost neznamená, že se vše musí zdvojit. Znamená, že organizace vědomě rozumí společným závislostem a přijala jejich riziko. Některé společné služby mají samy vysokou odolnost a jejich duplikace by jen zvýšila složitost. Problém vzniká, když je společná závislost mimo test a přepnutí na ní stojí.

MAPA SPOLEČNÉHO OSUDU

Ke každé kritické transakci sepište data, identitu, DNS, síť, certifikáty, artefakty, control plane a lidskou roli. Položka, která je pro obě lokality stejná, musí mít doloženou odolnost nebo explicitně přijaté zbytkové riziko.

Modelový scénář z praxe: zdravá lokalita bez rezervy

Modelová služba rozdělovala provoz rovnoměrně mezi dvě lokality. Každá běžela na přibližně 55 procentech své ověřené kapacity. Při výpadku jedné strany směrování správně přesunulo klienty na druhou. Zdravá lokalita se však dostala nad bod zlomu, narostly fronty a klienti začali opakovat požadavky.

Architektura selhala nikoli kvůli chybě přepnutí, ale kvůli kapacitní matematice. Dvě aktivní strany vytvářely dobrou efektivitu v běžném provozu, ale neměly přeživší rezervu. Organizace zavedla omezení méně důležitých funkcí, předem rezervovanou kapacitu a test, který ověřoval plný provoz pouze na jedné straně. Náklady stouply, protože skutečná odolnost vyžadovala nevyužitou možnost, nikoli jen dvě vytížené lokality.

POZNÁMKA Z PRAXE

Pokud každá aktivní lokalita dlouhodobě potřebuje více než polovinu své bezpečné kapacity, výpadek jedné strany pravděpodobně vyžaduje řízenou degradaci. Bez ní přepnutí pouze přesune poruchu.

Co active active neřeší

Více lokalit nechrání před logickou korupcí, chybným oprávněním ani vadnou změnou, která se replikuje všude. Replikace není historická záloha. Vysoká dostupnost také neznamená nulové RPO u všech datových modelů. Asynchronní replikace může při přepnutí připustit ztrátu nebo nekonzistenci posledních změn.

Naopak active passive nemusí být méně profesionální volba. Pokud podnik přijme několik minut obnovy, jednodušší režim může omezit konflikty zápisů a provozní složitost. Správné rozhodnutí vychází z RTO, RPO, datové sémantiky, kapacity týmu a ceny pravidelného testování.

HRANICE DŮKAZU

Úspěšné přesměrování syntetického požadavku potvrzuje směrování. Neprokazuje správnost souběžných zápisů, přeživší kapacitu, obnovu všech závislostí ani ochranu před společnou chybnou změnou.

Odolnost se počítá podle přeživší služby

Investiční návrh má obsahovat nejen dvě lokality, ale také model společného osudu, pravidla zápisu, ověřenou kapacitu jedné strany, způsob degradace a plán pravidelného provozu v poruchovém režimu. Bez těchto důkazů organizace financuje složitost, nikoli nutně dostupnost.

Nosná teze zní: více aktivních komponent zvyšuje odolnost jen tehdy, když po poruše zůstane jednodušší, samostatná a dostatečně kapacitní cesta k dokončení služby.