Активно-активно или активно-пасивно: шта изабрати?

Jednog ponedeljka ujutru sistem za naručivanje sporo odgovara, a zatim postaje nedostupan. Webshop i dalje prima narudžbine, ali skladište ih ne vidi, korisnička podrška ne može da pruži tačan status, a fakturisanje se zaustavlja. Tada postaje poslovno pitanje da li aktivno-aktivna ili aktivno-pasivna arhitektura sistema štiti kritične usluge.

Dva pristupa se često tretiraju samo kao infrastrukturna odluka. U stvari, oni određuju šta se dešava sa operacijama kada server, aplikacija, mrežna veza ili čak cela lokacija prestane da radi. Dobar izbor ne zavisi od toga koji zvuči naprednije, već od toga koji poslovni procesi ne smeju stati, koliko gubitka podataka je prihvatljivo i koliko je organizacija sposobna da bezbedno upravlja izabranim rešenjem.

Šta znači aktivno-aktivno i aktivno-pasivno funkcionisanje?

U aktivno-aktivnom postavljanju, dve ili više instanci sistema istovremeno obavljaju suštinski rad. Na primer, dva aplikaciona servera paralelno opslužuju korisnike webshopa, a balansiranje opterećenja raspodeljuje zahteve među njima. Ako jedna instanca prestane da radi, druga nastavlja da funkcioniše, obično neprimetno ili uz kratki prekid.

U aktivno-pasivnom postavljanju, primarni sistem radi, dok sekundarni čeka u pripravnosti. Rezervni sistem kontinuirano ili u određenim intervalima prima podatke primarnog sistema, ali u normalnom radu ne opslužuje korisnike. U slučaju greške, preuzima ulogu. To se naziva failover, odnosno automatsko ili ručno prebacivanje.

Na prvi pogled, aktivno-aktivno može izgledati kao očigledno bolje rešenje: dva funkcionalna sistema su bolja od jednog funkcionalnog i jednog u čekanju. Međutim, to je tačno samo ako aplikacija, upravljanje podacima, mreža i operativni procesi mogu da podnesu paralelno funkcionisanje. Nepravilno dizajnirano aktivno-aktivno okruženje ne samo da je skuplje, već može izazvati i teže dijagnostikovane greške.

Dostupnost nije jednaka sa više servera

Mnoge kompanije imaju drugi server, backup ili čak rezervnu internet vezu, ali to ne znači stvarno visoku dostupnost. Razlog je jednostavan: uzrok prekida često nije sam server.

Ako webshop i upravljanje zalihama zavise od iste baze podataka, mrežnog uređaja ili spoljnog provajdera, dva aplikaciona servera neće rešiti uzrok zajedničke greške. Isto važi i za slučaj kada sistem funkcioniše, ali jedinstveni Excel fajl potreban za obradu dolaznih narudžbina postoji samo na računaru jednog zaposlenog.

Dostupnost se stoga mora tumačiti kao poslovna usluga. Pitanje nije da li virtuelna mašina radi, već da li skladište može da preda robu, da li je tovarni list spreman, da li narudžbina stiže do fakturisanja i da li rukovodstvo dobija pouzdane informacije o operacijama.

Počnite sa kritičnim tačkama procesa

Vredi prvo precizirati koji procesi koliko prekida mogu da izdrže. Unutrašnja dokumentacija može biti neprijatna ako nestane na nekoliko sati, ali je upravljiva. Sistem za upravljanje proizvodnjom, proces online plaćanja ili veza za obradu narudžbina može izazvati direktan gubitak prihoda i poverenja klijenata već nakon deset minuta.

Jednako je važna granica gubitka podataka. Ako se sistem može obnoviti sa podacima starim sat vremena, to zahteva drugačije tehničko rešenje i troškove nego kada je dozvoljen gubitak podataka od samo nekoliko sekundi. Ovi nivoi se obično opisuju ciljevima RTO i RPO. RTO pokazuje koliko brzo usluga mora biti obnovljena. RPO pokazuje koliko podataka može biti izgubljeno u odnosu na stanje pre greške.

Iza brojeva uvek treba da stoje konkretne poslovne posledice. Cilj ne treba da bude da „visoka dostupnost“ bude u planu, već na primer da obrada narudžbina može stati najviše 15 minuta i da nijedna plaćena narudžbina ne sme biti izgubljena.

Kada je opravdan aktivno-pasivni model?

Aktivno-pasivna arhitektura je razumna i efikasna opcija za mnoge rastuće kompanije. Posebno kada je upravljanje stanjem aplikacije složeno, kada se oslanja na jednog pisca baze podataka ili kada softver ne podržava paralelno opsluživanje.

Zamislite proizvodnu kompaniju gde centralni sistem upravlja proizvodnim podacima. Više radnih stanica je povezano sa sistemom, ali je konzistentnost baze podataka primarna. Ovdje pažljivo izgrađena primarna-rezervna baza podataka, sa dokumentovanim procedurama prebacivanja, redovnim testovima i odgovarajućim nadzorom može biti pouzdanija od forsiranog aktivno-aktivnog dizajna.

Prednost aktivno-pasivnog modela je manja operativna složenost. Manje je sukoba podataka zbog paralelnih upisa, lakše je rešavanje problema, a operativni tim ima jasnije koji je sistem primarni. Nedostatak je što prebacivanje može potrajati, posebno ako zahteva ručnu odluku, izmene DNS-a, pokretanje usluga ili proveru podataka.

„Pasivno“ ne znači da smo ga zaboravili. Rezervno okruženje mora biti ažurirano, nadgledano i testirano. Plan za vanredne situacije koji postoji samo na papiru obično propada kada je organizaciji najpotrebniji. plan za vanredne situacije obično propada kada je organizaciji najpotrebniji.

Kada aktivno-aktivni model donosi stvarnu vrednost?

Aktivno-aktivni dizajn je opravdan tamo gde je stalna dostupnost usluge direktno povezana sa prihodima, proizvodnjom ili ugovornim obavezama. To može biti webshop sa velikim prometom, portal za klijente, kontinuirani logistički sistem ili aplikacija čije opterećenje povremeno značajno raste.

Model ne samo da pruža toleranciju na greške, već i kapacitet. Ako dva aktivna aplikaciona servera dele saobraćaj, resursi se mogu koristiti čak i u normalnom radu. Kada jedna instanca prestane da radi, preostali kapacitet i dalje mora da podnese kritično opterećenje. Ovo često nedostaje u planovima: postoje dva servera, ali oba rade sa 70-80% kapaciteta čak i u normalnom danu. U slučaju kvara, sistem tehnički ostaje dostupan, ali poslovno postaje neupotrebljivo spor.

U aktivno-aktivnom okruženju najteže pitanje je obično podaci. Ako dve lokacije ili dve instance baze podataka istovremeno primaju izmene, potrebno je regulisati koji podaci su važeći u slučaju sukoba. Isti poslednji komad zaliha ne može biti prodat kroz dva kanala nezavisno jedan od drugog. Sistem mora imati jedinstvena poslovna pravila, upravljanje transakcijama i kontrolisanu sinhronizaciju.

Zbog toga nije svaku aplikaciju moguće ili preporučljivo učiniti aktivno-aktivnom. Često je ispravno rešenje da je web usluga aktivno-aktivna, dok baza podataka ili kritični pozadinski proces ostaju aktivno-pasivni. Visoka dostupnost je često različita kombinacija slojeva, a ne jedna oznaka.

Prebacivanje funkcioniše samo ako se redovno vežba

Većina rizika se ne pojavljuje na dijagramu arhitekture, već u operacijama. Ko je ovlašćen da pokrene prebacivanje? Kako se vidi da je došlo do stvarne greške, a ne samo privremenog usporenja? Kako se proverava da li je sekundarni sistem zaista ažuriran? Ko obaveštava korisnike ako je usluga delimično dostupna?

Posebnu pažnju zahteva situacija split-brain. To se dešava kada dve instance sistema pogrešno smatraju jedna drugu neispravnom i obe počnu da rade kao primarne. Ako obe mogu da pišu u iste poslovne podatke, nekonzistentnost podataka može brzo postati ozbiljan problem. Bez odgovarajućih mehanizama kvoruma, mrežnog dizajna i strategije baze podataka, redundancija sama po sebi postaje izvor grešaka.

Planirano održavanje takođe treba ispitati. Dobar model dostupnosti nije vredan samo u slučaju neočekivanog prekida. Takođe je vredan kada je potrebna bezbednosna nadogradnja, zamena hardvera ili promena verzije. Ako svaka promena zahteva noćni prekid i ručnu intervenciju, dugoročni operativni rizik sistema ostaje visok.

Ispravna odluka počinje od procesa

Kompaniji nije potrebna aktivno-aktivna rešenja samo zato što ih koriste velike tehnološke kompanije. I ne treba da bira aktivno-pasivni pristup samo zato što izgleda jeftinije. Odluku treba voditi time kako informacije teku od narudžbine do isporuke, od proizvodne instrukcije do gotovog proizvoda ili od zahteva klijenta do fakture.

Pre dizajniranja sistema, treba istražiti zavisnosti: iz koje aplikacije dolaze podaci, gde se vrši ručni unos podataka, koji sistem je jedini pouzdan izvor i gde se posao zaustavlja u slučaju prekida. U CGAT pristupu, tehnološka arhitektura je odgovor na ova operativna pitanja, a ne samostalna lista proizvoda.

Najbolji dizajn nije nužno najkompleksniji. Dobar sistem je onaj čije je ponašanje u slučaju prekida poznato, čije je prebacivanje kontrolisano, čiji su podaci zaštićeni i koji tim ili odabrani partner može bezbedno da upravlja na duži rok. Ako se to ne može jasno reći pre sledećeg planiranog prekida ili neočekivane greške, potrebno je jasnije operativno rešenje, a ne još jedan server.