Aktywny-aktywny czy aktywny-pasywny: który wybrać?

Pewnego poniedziałkowego poranka system zamówień odpowiada wolno, a następnie staje się niedostępny. Sklep internetowy nadal przyjmuje zamówienia, ale magazyn ich nie widzi, obsługa klienta nie może podać dokładnego statusu, a fakturowanie staje w miejscu. W takich sytuacjach pojawia się pytanie biznesowe, czy architektura aktywna-aktywna czy aktywna-pasywna chroni krytyczne usługi.

Oba podejścia często traktowane są jako decyzje infrastrukturalne. W rzeczywistości określają, co dzieje się z działaniem, gdy serwer, aplikacja, połączenie sieciowe lub nawet cała lokalizacja przestają działać. Dobry wybór nie zależy od tego, które rozwiązanie brzmi bardziej zaawansowanie, ale od tego, które procesy biznesowe nie mogą się zatrzymać, ile utraty danych jest akceptowalne i na ile organizacja jest w stanie bezpiecznie obsługiwać wybrane rozwiązanie.

Co oznacza działanie aktywne-aktywne i aktywne-pasywne?

W konfiguracji aktywnej-aktywnej dwie lub więcej instancji systemu wykonują jednocześnie znaczącą pracę. Na przykład dwa serwery aplikacji równolegle obsługują użytkowników sklepu internetowego, a równoważnik obciążenia rozdziela między nimi żądania. Jeśli jedna z instancji przestanie działać, druga kontynuuje pracę, zwykle niezauważalnie lub z krótką przerwą.

W konfiguracji aktywnej-pasywnej system główny pracuje, a zapasowy jest w gotowości. System zapasowy regularnie lub w określonych odstępach czasu otrzymuje dane z systemu głównego, ale w normalnym trybie nie obsługuje użytkowników. W przypadku awarii przejmuje rolę głównego. Nazywa się to przełączeniem awaryjnym, czyli automatycznym lub ręcznym przełączeniem.

Na pierwszy rzut oka aktywne-aktywne może wydawać się lepszym rozwiązaniem: dwa działające systemy są lepsze niż jeden działający i jeden oczekujący. To jednak prawda tylko wtedy, gdy aplikacja, zarządzanie danymi, sieć i procesy operacyjne są w stanie obsłużyć równoległe działanie. Nieprawidłowo zaprojektowane środowisko aktywne-aktywne może nie tylko być droższe, ale także powodować trudniejsze do zdiagnozowania błędy.

Dostępność nie równa się większej liczbie serwerów

Wiele firm posiada drugi serwer, kopię zapasową lub nawet zapasowe połączenie internetowe, a mimo to nie można mówić o prawdziwej wysokiej dostępności. Powód jest prosty: przyczyną awarii często nie jest sam serwer.

Jeśli sklep internetowy i ewidencja magazynowa zależą od tej samej bazy danych, urządzenia sieciowego lub zewnętrznego dostawcy, to dwa serwery aplikacji nie rozwiążą wspólnej przyczyny awarii. To samo dotyczy sytuacji, gdy system działa, ale unikalny plik Excel potrzebny do przetworzenia zamówień znajduje się tylko na komputerze jednego pracownika.

Dlatego dostępność należy rozumieć jako usługę biznesową. Nie chodzi o to, czy maszyna wirtualna działa, ale o to, czy magazyn może przekazać towar, czy list przewozowy jest gotowy, czy zamówienie dociera do fakturowania i czy kierownictwo otrzymuje wiarygodne informacje o działaniu.

Zacznij od krytycznych punktów procesu

Warto najpierw określić, które procesy mogą tolerować jak długie przestoje. Kilkugodzinna awaria wewnętrznego archiwum dokumentów może być nieprzyjemna, ale do opanowania. System zarządzania produkcją, proces płatności online lub połączenie przetwarzania zamówień mogą po dziesięciu minutach spowodować bezpośrednią utratę przychodów i zaufania klientów.

Równie ważna jest granica utraty danych. Jeśli system można przywrócić na podstawie danych sprzed godziny, oznacza to inne rozwiązanie techniczne i koszty niż wtedy, gdy można pozwolić sobie na utratę zaledwie kilku sekund danych. Te poziomy są zazwyczaj opisywane za pomocą celów RTO i RPO. RTO wskazuje, jak szybko usługa musi zostać przywrócona. RPO natomiast określa, ile danych można utracić w porównaniu do stanu sprzed awarii.

Za liczbami zawsze powinny stać konkretne konsekwencje biznesowe. Celem nie powinno być, aby w planie znalazło się „wysoka dostępność”, ale na przykład, że przetwarzanie zamówień może być wstrzymane na maksymalnie 15 minut, a żadne opłacone zamówienie nie może zostać utracone.

Kiedy model aktywno-pasywny jest uzasadniony?

Architektura aktywno-pasywna jest rozsądnym i efektywnym wyborem dla wielu rozwijających się firm. Szczególnie wtedy, gdy zarządzanie stanem aplikacji jest skomplikowane, opiera się na jednym pisarzu bazy danych lub oprogramowanie z natury nie wspiera równoległej obsługi.

Wyobraźmy sobie firmę produkcyjną, w której dane produkcyjne są zarządzane przez centralny system. Do systemu podłączonych jest wiele stanowisk pracy, ale spójność bazy danych jest priorytetem. W takim przypadku starannie zbudowana baza danych główna-zapasowa, z udokumentowaną procedurą przełączania, regularnymi testami i odpowiednim monitorowaniem, może być bardziej niezawodna niż wymuszona konfiguracja aktywno-aktywna.

Zaletą modelu aktywno-pasywnego jest mniejsza złożoność operacyjna. Mniej jest konfliktów danych wynikających z równoległego zapisu, łatwiejsze może być rozwiązywanie problemów, a zespół operacyjny ma jasność, który system jest główny. Wadą jest to, że przełączenie może zająć czas, zwłaszcza jeśli wymaga ręcznej decyzji, zmiany DNS, uruchomienia usługi lub weryfikacji danych.

„Pasywne” nie może oznaczać zapomniane. Środowisko zapasowe musi być aktualizowane, monitorowane i testowane. Plan awaryjny istniejący tylko na papierze zazwyczaj zawodzi, gdy organizacja najbardziej go potrzebuje. plan awaryjny zazwyczaj zawodzi, gdy organizacja najbardziej go potrzebuje.

Kiedy model aktywno-aktywny przynosi rzeczywistą wartość?

Konfiguracja aktywno-aktywna jest uzasadniona tam, gdzie ciągła dostępność usługi bezpośrednio wiąże się z przychodami, produkcją lub zobowiązaniami umownymi. Może to być sklep internetowy o dużym ruchu, portal klienta, system logistyczny działający non-stop lub aplikacja, której obciążenie okresowo znacznie wzrasta.

Model ten zapewnia nie tylko odporność na awarie, ale także pojemność. Jeśli dwa serwery aplikacji aktywnie rozdzielają ruch, zasoby mogą być wykorzystywane nawet w normalnym trybie. W przypadku awarii jednej instancji pozostała pojemność musi jednak nadal obsługiwać krytyczne obciążenie. Tego często brakuje w planach: są dwa serwery, ale oba pracują już w normalnym dniu przy 70-80% wykorzystaniu. W przypadku awarii system technicznie pozostaje dostępny, ale z biznesowego punktu widzenia staje się zbyt wolny, by być użytecznym.

W środowisku aktywno-aktywnym najtrudniejsze pytanie dotyczy zazwyczaj danych. Jeśli dwie lokalizacje lub dwie instancje bazy danych jednocześnie przyjmują modyfikacje, trzeba określić, które dane są ważne w przypadku konfliktu. Ten sam ostatni element zapasów nie może być sprzedany przez dwa kanały niezależnie od siebie. System musi mieć jednolite zasady biznesowe, zarządzanie transakcjami i kontrolowaną synchronizację.

Dlatego nie każdą aplikację można lub warto przekształcić w aktywno-aktywną. Często właściwym rozwiązaniem jest, aby obsługa sieciowa była aktywno-aktywna, podczas gdy baza danych lub krytyczny proces zaplecza pozostają aktywno-pasywne. Wysoka dostępność często jest kombinacją różnych warstw, a nie jednym etykietą.

Przełączenie działa tylko wtedy, gdy jest regularnie ćwiczone

Większość ryzyk nie pojawia się na rysunku architektury, ale w operacjach. Kto jest uprawniony do inicjowania przełączenia? Skąd wiadomo, że doszło do rzeczywistej awarii, a nie tylko tymczasowego spowolnienia? Jak sprawdza się, czy system zapasowy jest rzeczywiście aktualny? Kto informuje użytkowników, jeśli usługa jest częściowo dostępna?

Szczególną uwagę wymaga sytuacja split-brain. Występuje ona, gdy dwie instancje systemu uznają się nawzajem za wadliwe i obie zaczynają działać jako główne. Jeśli obie mogą zapisywać do tych samych danych biznesowych, niespójność danych szybko staje się poważnym problemem. Bez odpowiednich mechanizmów kworum, konfiguracji sieciowej i strategii bazy danych, redundancja sama w sobie staje się źródłem błędów.

Należy również rozważyć planowaną konserwację. Dobry model dostępności jest wartościowy nie tylko w przypadku nieoczekiwanej awarii. Również wtedy, gdy potrzebna jest aktualizacja bezpieczeństwa, wymiana sprzętu lub zmiana wersji. Jeśli każda zmiana wymaga nocnego wyłączenia i ręcznej interwencji, długoterminowe ryzyko operacyjne systemu pozostaje wysokie.

Właściwa decyzja zaczyna się od procesu

Firma nie potrzebuje rozwiązania aktywno-aktywnego, ponieważ używają go duże firmy technologiczne. I nie musi wybierać konfiguracji aktywno-pasywnej, ponieważ wydaje się tańsza. Decyzję powinno prowadzić to, jak przepływa informacja od zamówienia do realizacji, od instrukcji produkcji do gotowego produktu lub od zapotrzebowania klienta do faktury.

Przed zaprojektowaniem systemu należy zidentyfikować zależności: z której aplikacji pochodzi dane, gdzie odbywa się ręczne wprowadzanie danych, który system jest jedynym wiarygodnym źródłem i gdzie praca zatrzymuje się w przypadku awarii. W podejściu CGAT architektura technologiczna jest odpowiedzią na te pytania operacyjne, a nie samodzielną listą produktów.

Najlepsza konfiguracja niekoniecznie jest najbardziej skomplikowana. Dobry system to taki, którego zachowanie w przypadku awarii jest znane, przełączenie jest kontrolowane, dane są chronione, a który zespół własny lub wyznaczony partner może bezpiecznie obsługiwać na dłuższą metę. Jeśli przed kolejną planowaną przerwą lub nieoczekiwaną awarią nie można tego jednoznacznie stwierdzić, potrzebny jest nie kolejny serwer, ale czystszy plan operacyjny.