Aktív-aktív vagy aktív-passzív: melyik kell?

Egy hétfő reggel a rendelési rendszer lassan válaszol, majd elérhetetlenné válik. A webshop továbbra is fogad rendeléseket, de a raktár nem látja őket, az ügyfélszolgálat nem tud pontos státuszt mondani, a számlázás pedig megáll. Ilyenkor válik üzleti kérdéssé az, hogy aktív-aktív vagy aktív-passzív rendszerarchitektúra védi-e a kritikus szolgáltatásokat.

A két megközelítést gyakran pusztán infrastruktúra-döntésként kezelik. Valójában azt határozzák meg, mi történik a működéssel, amikor egy szerver, alkalmazás, hálózati kapcsolat vagy akár egy teljes telephely kiesik. A jó választás nem attól függ, melyik hangzik fejlettebbnek, hanem attól, hogy mely üzleti folyamatok nem állhatnak le, mennyi adatvesztés elfogadható, és mennyire képes a szervezet biztonságosan üzemeltetni a választott megoldást.

Mit jelent az aktív-aktív és az aktív-passzív működés?

Aktív-aktív felállásban két vagy több rendszerpéldány egyszerre végez érdemi munkát. Például két alkalmazásszerver párhuzamosan szolgálja ki a webshop felhasználóit, és egy terheléselosztó osztja el közöttük a kéréseket. Ha az egyik példány kiesik, a másik tovább működik, általában észrevehetetlen vagy rövid fennakadással.

Aktív-passzív felállásban az elsődleges rendszer dolgozik, a másodlagos pedig készenlétben áll. A tartalék rendszer folyamatosan vagy meghatározott időközönként megkapja az elsődleges rendszer adatait, de normál üzemben nem szolgál ki felhasználókat. Hiba esetén átveszi a szerepet. Ezt nevezik failovernek, vagyis automatikus vagy kézi átkapcsolásnak.

Első látásra az aktív-aktív tűnhet egyértelműen jobb megoldásnak: két működő rendszer jobb, mint egy működő és egy várakozó. Ez azonban csak akkor igaz, ha az alkalmazás, az adatkezelés, a hálózat és az üzemeltetési folyamatok is képesek kezelni a párhuzamos működést. Egy hibásan kialakított aktív-aktív környezet nemcsak drágább, hanem nehezebben diagnosztizálható hibákat is okozhat.

A rendelkezésre állás nem egyenlő a több szerverrel

Sok vállalatnál van második szerver, mentés vagy akár tartalék internetkapcsolat, mégsem beszélhetünk valódi magas rendelkezésre állásról. Ennek oka egyszerű: a kiesés oka gyakran nem maga a szerver.

Ha a webshop és a készletnyilvántartás ugyanattól az adatbázistól, hálózati eszköztől vagy külső szolgáltatótól függ, akkor két alkalmazásszerver sem oldja meg a közös hiba okát. Ugyanez igaz arra az esetre, amikor a rendszer működik, de a beérkező rendelések feldolgozásához szükséges egyedi Excel-fájl csak egy munkatárs gépén található.

A rendelkezésre állást ezért üzleti szolgáltatásként kell értelmezni. Nem az a kérdés, hogy fut-e egy virtuális gép, hanem az, hogy a raktár át tudja-e adni az árut, elkészül-e a fuvarlevél, eljut-e a rendelés a számlázásig, és a vezetés hiteles információt kap-e a működésről.

Kezdje a folyamat kritikus pontjainál

Érdemes először pontosítani, mely folyamatok mennyi leállást viselnek el. Egy belső dokumentumtár néhány órás kiesése kellemetlen lehet, de kezelhető. Egy termelésirányító rendszer, online fizetési folyamat vagy rendelésfeldolgozó kapcsolat akár tíz perc után közvetlen bevétel- és ügyfélbizalom-veszteséget okozhat.

Ugyanilyen lényeges az adatvesztési határ. Ha egy rendszer egy órával korábbi adatokból helyreállítható, az más műszaki megoldást és költséget jelent, mint amikor legfeljebb néhány másodpercnyi adatvesztés engedhető meg. Ezeket a szinteket általában RTO és RPO célértékekkel írják le. Az RTO azt jelzi, mennyi idő alatt kell helyreállnia a szolgáltatásnak. Az RPO pedig azt, legfeljebb mennyi adat veszhet el a hiba előtti állapothoz képest.

A számok mögött mindig konkrét üzleti következmény álljon. Ne az legyen a cél, hogy „magas rendelkezésre állás” szerepeljen a tervben, hanem például az, hogy a rendelésfeldolgozás legfeljebb 15 percre állhat le, és egyetlen kifizetett rendelés sem veszhet el.

Mikor indokolt az aktív-passzív modell?

Az aktív-passzív architektúra sok növekvő vállalat számára józan és hatékony választás. Különösen akkor, ha az alkalmazás állapotkezelése összetett, egyetlen adatbázis-írón alapul, vagy a szoftver eleve nem támogatja a párhuzamos kiszolgálást.

Képzeljünk el egy gyártóvállalatot, ahol a termelési adatokat egy központi rendszer kezeli. A rendszerhez több munkaállomás kapcsolódik, de az adatbázis konzisztenciája elsődleges. Itt egy gondosan felépített elsődleges-készenléti adatbázis, dokumentált átkapcsolási eljárással, rendszeres tesztekkel és megfelelő monitorozással megbízhatóbb lehet, mint egy erőltetett aktív-aktív kialakítás.

Az aktív-passzív modell előnye a kisebb működési összetettség. Kevesebb a párhuzamos írásból eredő adatütközés, egyszerűbb lehet a hibakeresés, és az üzemeltetési csapatnak világosabb, melyik rendszer az elsődleges. Hátránya, hogy az átkapcsolás időt vehet igénybe, különösen akkor, ha manuális döntés, DNS-módosítás, szolgáltatásindítás vagy adatellenőrzés szükséges hozzá.

A „passzív” nem jelentheti azt, hogy elfelejtettük. A tartalék környezetet frissíteni, felügyelni és tesztelni kell. A csak papíron létező vészhelyzeti terv általában akkor bukik meg, amikor a szervezetnek a legnagyobb szüksége lenne rá.

Mikor ad valódi értéket az aktív-aktív modell?

Az aktív-aktív kialakítás ott indokolt, ahol a szolgáltatás folyamatos elérhetősége közvetlenül kapcsolódik a bevételhez, a termeléshez vagy szerződéses kötelezettségekhez. Ilyen lehet egy nagy forgalmú webshop, ügyfélportál, folyamatosan működő logisztikai rendszer vagy olyan alkalmazás, amelynek terhelése időszakosan jelentősen megugrik.

A modell nemcsak hibatűrést, hanem kapacitást is adhat. Ha a két aktív alkalmazásszerver osztja el a forgalmat, normál üzemben is kihasználhatók az erőforrások. Egy példány kiesésekor a fennmaradó kapacitásnak azonban továbbra is el kell bírnia a kritikus terhelést. Ez sok tervből hiányzik: két szerver van, de mindkettő már normál napon is 70-80 százalékos kihasználtság mellett dolgozik. Kieséskor tehát a rendszer technikailag elérhető marad, üzletileg mégis használhatatlanná lassul.

Aktív-aktív környezetben a legnehezebb kérdés általában az adat. Ha két helyszín vagy két adatbázis-példány egyszerre fogad módosításokat, szabályozni kell, melyik adat az érvényes egy ütközés esetén. Egyazon készlet utolsó darabját nem értékesítheti két csatorna egymástól függetlenül. A rendszernek egységes üzleti szabályokra, tranzakciókezelésre és ellenőrzött szinkronizációra van szüksége.

Ezért nem minden alkalmazást lehet vagy érdemes aktív-aktívvá tenni. Gyakran az a helyes megoldás, hogy a webes kiszolgálás aktív-aktív, míg az adatbázis vagy egy kritikus háttérfolyamat aktív-passzív marad. A magas rendelkezésre állás sokszor rétegek eltérő kombinációja, nem egyetlen címke.

Az átkapcsolás csak akkor működik, ha rendszeresen gyakorolják

A legtöbb kockázat nem az architektúra rajzán, hanem az üzemeltetésben jelenik meg. Ki jogosult átkapcsolást indítani? Honnan látszik, hogy valódi hiba történt, nem csak átmeneti lassulás? Hogyan ellenőrzik, hogy a másodlagos rendszer valóban naprakész? Ki tájékoztatja a felhasználókat, ha a szolgáltatás részlegesen elérhető?

Külön figyelmet igényel a split-brain helyzet. Ez akkor fordul elő, amikor két rendszerpéldány egymást hibásnak érzékeli, és mindkettő elsődlegesként kezd működni. Ha mindkettő írhat ugyanabba az üzleti adatba, az adatinkonzisztencia gyorsan komoly problémává válhat. Megfelelő quorum-mechanizmusok, hálózati kialakítás és adatbázis-stratégia nélkül a redundancia maga is hibaforrássá válik.

A tervezett karbantartást is vizsgálni kell. A jó rendelkezésre állási modell nemcsak váratlan leálláskor értékes. Akkor is, amikor biztonsági frissítés, hardvercsere vagy verzióváltás szükséges. Ha minden változtatás éjszakai leállást és kézi beavatkozást igényel, a rendszer hosszú távú üzemeltetési kockázata magas marad.

A helyes döntés a folyamatból indul ki

Egy vállalatnak nem azért van szüksége aktív-aktív megoldásra, mert ezt használják a nagy technológiai cégek. És nem azért kell aktív-passzív felállást választania, mert olcsóbbnak tűnik. A döntést annak kell vezetnie, hogyan áramlik az információ a rendeléstől a teljesítésig, a gyártási utasítástól a késztermékig vagy az ügyféligénytől a számláig.

A rendszertervezés előtt fel kell tárni a függőségeket: melyik alkalmazásból érkezik az adat, hol történik a kézi adatbevitel, mely rendszer az egyetlen hiteles forrás, és hol akad meg a munka egy kieséskor. A CGAT megközelítésében a technológiai architektúra ezekre a működési kérdésekre adott válasz, nem önálló terméklista.

A legjobb kialakítás nem feltétlenül a legbonyolultabb. Az a jó rendszer, amelynek a kiesési viselkedése ismert, az átkapcsolása ellenőrzött, az adatai védettek, és amelyet a saját csapat vagy kijelölt partner hosszú távon is biztonsággal tud üzemeltetni. Ha a következő tervezett leállás vagy váratlan hiba előtt ezt nem lehet egyértelműen kimondani, akkor nem még egy szerverre, hanem tisztább működési tervre van szükség.