Wysoka dostępność (Standby, Failover)

Wprowadzenie

W systemie ERP odwzorowywane są kluczowe procesy biznesowe przedsiębiorstwa. Jeśli system nie jest dostępny, przebieg tych procesów zostaje utrudniony lub staje się niemożliwy. Z tego powodu oferowane są liczne rozwiązania zwiększające dostępność systemu. Opcje te zostały szczegółowo opisane poniżej.

Dodatkowo zalecanym jest zapoznanie się z pojęciami takimi jak wysoka dostępność, ciągła dostępność, failover opisanymi w tutaj.

Grupa docelowa

• Konsultanci techniczni
• Administratorzy systemu

Opis

Każdy zasób potrzebny do działania systemu Comarch ERP Enterprise (np. komputer, system operacyjny, JVM) może ulec awarii. Aby po awarii zasobu zachować lub przywrócić dostępność systemu, konieczna jest reakcja systemu lub ręczna interwencja administratora.

System może automatycznie reagować na awarię następujących zasobów i przywracać dostępność systemu.

Poniżej opisano funkcje zapewniające dostępność systemu.

IP-Failover

Połączenia sieciowe pomiędzy serwerem aplikacji, systemem bazy danych i przeglądarką są niezbędne do działania systemu (szczegóły w rozdziale: Failover po stronie klienta). Jeśli jedno z połączeń sieciowych zostanie trwale przerwane i nie można go przywrócić, system stanie się niedostępny.

Jeśli połączenie sieciowe między serwerem aplikacji a serwerem wiadomości systemu nie powiedzie się, serwer aplikacji pozstaje aktywny przez 30 sekund i próbuje ponownie nawiązać połączenie sieciowe. Jeśli połączenie z serwerem wiadomości może zostać przywrócone w ciągu 30 sekund, serwer aplikacji nadal działa bez utraty danych. W tym przypadku gwarantowana jest ciągła dostępność. Jeśli połączenie nie może zostać przywrócone w ciągu 30 sekund, serwer aplikacji uruchamia się ponownie.

Failover połączeń sieciowych (IP-Failover) pomiędzy serwerami aplikacyjnymi systemu jest zawsze aktywny. Konfiguracja IP-Failover nie jest wymagana

Jeśli w wyniku awarii połączeń sieciowych utracone zostaną także połączenia z bazą danych, system ERP zazwyczaj rozpoznaje tę awarię i inicjuje proces Failover bazy danych.

Inne komponenty, takie jak system plików, które nie są pod kontrolą systemu, muszą również reagować na awarię sieci. Należy upewnić się, czy używany sprzęt i oprogramowanie są nadal dostępne po tymczasowej awarii sieci.

Jeśli infrastruktura sieciowa między serwerami aplikacji lub systemem bazy danych ulegnie trwałej awarii, system staje się niedostępny.

Failover bazy danych

Większość systemów zarządzania bazami danych (DBMS) posiada mechanizmy przełączania awaryjnego. Oznacza to, że kilka instancji bazy danych działa równolegle w tej samej bazie danych lub na bazie danych z lustrzanym odbiciem. Jeśli instancja bazy danych nie jest już dostępna z powodu błędu, inna instancja bazy danych może przejąć jej zadania. Często istnieje kilka sposobów konfiguracji przełączania awaryjnego dla systemu bazy danych w ramach DBMS. Konfiguracje obsługiwane przez system można znaleźć w dokumentacji dotyczącej instalacji.

System zarządza wszystkimi połączeniami do instancji bazy danych dla każdej bazy danych we wspólnej puli. Jeśli serwer aplikacji wymaga połączenia, a wszystkie połączenia w puli są już używane, a maksymalna liczba połączeń w puli nie została jeszcze osiągnięta, nowe połączenie jest otwierane i rejestrowane w puli. Jeśli baza danych zgłosi błąd, dane połączenie zostanie zamknięte.

Jeśli system rozpozna na podstawie komunikatu o błędzie, że instancja bazy danych uległa awarii, wszystkie otwarte nieaktywne połączenia z bazą danych są zamykane i ponownie otwierane po okresie oczekiwania. System wielokrotnie próbuje wznowić połączenie, zwiększając czas oczekiwania między próbami. Jest to uwzględnienie faktu, że DBMS może potrzebować czasu na pełne przełączenie (failover). Podczas próby ponownego nawiązania połączenia przez serwer aplikacyjny wszystkie aplikacje próbujące uzyskać dostęp do bazy danych są wstrzymane.

Jeśli aplikacja wykonuje operację na połączeniu z bazą danych, a instancja bazy przestanie działać, operacja zostanie przerwana z komunikatem o błędzie. System ERP rozpoznaje ten komunikat i w miarę możliwości próbuje ponownie wykonać operację za pomocą nowego połączenia.

Jednak następujące operacje nie mogą zostać ponownie wykonane:

• zakończenie transakcji bazy danych za pomocą Commit
• pobranie następnego rekordu w już otwartym ResultSet
• modyfikacje schematu bazy danych

Jeśli podczas tych operacji dojdzie do zerwania połączenia z bazą danych, aplikacja zostanie zazwyczaj zakończona z komunikatem o błędzie.

Jeśli żadne nowe połączenia z instancją bazy danych nie mogą zostać otwarte nawet po wielokrotnych próbach, serwer aplikacji musi zostać zamknięty ręcznie. Problem z dostępem do instancji bazy danych musi zostać naprawiony, a następnie serwer aplikacji może zostać ponownie uruchomiony.

Systemy zarządzania bazami danych obsługują szeroki zakres opcji konfiguracji przełączania awaryjnego bazy danych. Dlatego ważne jest, aby przetestować przełączanie awaryjne bazy danych w systemie deweloperskim lub testowym.

Alternatywny serwer wiadomości (Message-Server)

Serwer wiadomości koordynuje współpracę wszystkich serwerów aplikacji w systemie. Jeśli żaden serwer wiadomości nie jest uruchomiony, żaden inny serwer aplikacji nie może się uruchomić ani działać. Serwer wiadomości jest zatem pojedynczym punktem awarii. Aby zwiększyć niezawodność, można skonfigurować alternatywny serwer wiadomości dla każdego systemu. Alternatywny serwer wiadomości może przejąć zadania serwera wiadomości po jego awarii bez konieczności ręcznej interwencji. Ten proces nazywany jest Cold-Standby.

Cold-Standby działa w następujący sposób:

• serwer wiadomości kończy działanie, co powoduje zerwanie połączeń sieciowych ze wszystkimi serwerami aplikacyjnymi oraz z alternatywnym serwerem wiadomości.
• wszystkie serwery aplikacji i alternatywny serwer wiadomości uruchamiają się ponownie i próbują ponownie połączyć się z serwerem wiadomości.
• jeśli alternatywny serwer wiadomości nie może nawiązać połączenia z serwerem wiadomości w czasie oczekiwania, alternatywny serwer wiadomości zmienia konfigurację systemu i rejestruje się jako serwer wiadomości. Oryginalny serwer wiadomości staje się w ten sposób alternatywnym serwerem wiadomości.
• wszystkie serwery aplikacji w systemie rozpoczynają pracę z nowym serwerem wiadomości.
• system jest ponownie dostępny.

Jeśli serwer wiadomości ulegnie awarii, system jest ponownie dostępny po kilku minutach bez ręcznej interwencji dzięki funkcji Cold-Standby. Użytkownicy systemu mogą ponownie zalogować się do systemu po uruchomieniu alternatywnego serwera wiadomości.

W artkule Panel System: System opisano sposób konfigurowania alternatywnych serwerów wiadomości.

Failover po stronie klienta

System może zniwelować krótkotrwałe awarie połączenia sieciowego między przeglądarką a serwerem aplikacji. W przypadku braku interakcji ze strony klienta w zdefiniowanym oknie czasowym, system okresowo sprawdza połączenie komunikacyjne między serwerem aplikacji a klientem. Jeśli połączenie może zostać ponownie nawiązane przez oryginalną instancję przeglądarki internetowej w tym przedziale czasowym, użytkownik może kontynuować pracę w tym samym miejscu bez żadnych ograniczeń.

Comarch ERP Enterprise oferuje funkcje umożliwiające użytkownikowi łatwiejsze wznowienie pracy po nieoczekiwanym zakończeniu działania serwera aplikacyjnego oraz w przypadku dłuższego przerwania połączenia pomiędzy przeglądarką a serwerem aplikacyjnym. Podczas ponownego logowania (w zależności od ustawień użytkownika) zostaje ponownie uruchomiona ostatnia aktywna aplikacja oraz ostatnio przetwarzana jednostka biznesowa. Dzięki temu użytkownik po ponownym zalogowaniu odnajduje taką samą przestrzeń roboczą jak przed wystąpieniem błędu.

W systemie dla każdego użytkownika rejestrowana jest historia:

• ostatnio używanych aplikacji

• ostatnio przeglądanych jednostek biznesowych

Historię można przeglądać w różnych widokach, na przykład wg. aplikacji, jednostki biznesowej lub przedziału czasowego. Użytkownik może korzystać z historii, aby szybko i łatwo otwierać ostatnio używane aplikacje i edytować obiekty.

W praktyce liczba niezapisanych pozycji jest zawsze stosunkowo niewielka, ponieważ liczba instancji aplikacji w trybie Nowy lub Edycja na jedną sesję dialogową jest ograniczona.

Load balancer

Dostęp do każdego serwera aplikacji używanego do przetwarzania dialogowego można uzyskać za pośrednictwem adresu URL. Adres URL jest zazwyczaj jednoznacznie przypisany do serwera aplikacji w obrębie sieci. Jeśli serwer aplikacji ulegnie awarii i nie zostanie ponownie uruchomiony, dostęp dialogowy nie jest możliwy za pośrednictwem adresu URL przypisanego do tego serwera aplikacji. Użytkownicy, którzy zwykle pracowali na tym serwerze aplikacyjnym, muszą skorzystać z innego URL, aby połączyć się z innym serwerem aplikacyjnym.

Load Balancer jest dostarczany wraz z systemem. Load Balancer zapewnia jeden adres URL dostępu do systemu i rozdziela dostęp do tego adresu URL na kilka serwerów aplikacji. Rozkład użytkowników do uruchomionych serwerów aplikacji odbywa się automatycznie, biorąc pod uwagę status serwerów aplikacji.

Jeśli serwer aplikacji używany do przetwarzania dialogowego ulegnie awarii i zostanie użyty load balancer, wszystkie niezapisane dane użytkowników, którzy pracowali na tym serwerze aplikacji, zostaną utracone. Użytkownicy mogą jednak zalogować się ponownie bez użycia innego adresu URL i kontynuować pracę. Jak opisano w rozdziale Failover po stronie klienta, system może automatycznie ponownie uruchomić ostatnio otwartą aplikację, w przypadku gdy użytkownik ponownie się zaloguje i załaduje ostatnio edytowaną jednostkę biznesową.

Gdy tylko SAS ulegnie awarii, load balancer w przejrzysty sposób dystrybuuje dalsze przychodzące żądania połączenia do SAS, które są nadal dostępne, przyczyniając się w ten sposób do wysokiej dostępności systemu.

Rozproszone kolejki przetwarzania

Zlecenia przetwarzania w rozproszonej kolejce przetwarzania są obsługiwane przez wszystkie serwery aplikacji, które zapewniają workerów (Threads) dla tej kolejki przetwarzania. Oczekujące zadania przetwarzania są automatycznie dystrybuowane do uruchomionych serwerów aplikacji. Jeśli jeden z serwerów aplikacji przypisanych do kolejki przetwarzania rozproszonego nie jest dostępny, oczekujące zadania przetwarzania są przetwarzane przez inne serwery aplikacji przypisane do kolejki przetwarzania rozproszonego. Zadania przetwarzania, które można ponownie uruchomić i które były przetwarzane na serwerze aplikacji w momencie awarii, są automatycznie uruchamiane na innym serwerze roboczym w kolejce przetwarzania rozproszonego. Zadania przetwarzania, których nie można ponownie uruchomić, są anulowane i muszą zostać ponownie uruchomione ręcznie.

W artykule Panel System: Serwer aplikacji oraz Panel System: Kolejka przetwarzania opisano sposób konfigurowania kolejek przetwarzania rozproszonego.

Instrukcje

Wymagania dotyczące dostępności systemu są wymaganiem indywidualnym. Wyższa dostępność wiąże się z wyższymi kosztami. Poniżej opisano warianty konfiguracji, które zwiększają dostępność systemu. Można te warianty łączyć lub modyfikować w zależności od potrzeb.

Rozproszone kolejki przetwarzania

Wymagania

Należy zapewnić co najmniej dwa, a najlepiej więcej niezależnych komputerów, które będą przeznaczone wyłącznie do przetwarzania w tle. Komputery powinny być skonfigurowane w taki sposób, aby w przypadku awarii jednego z nich pozostałe dysponowały wystarczającą liczbą workerów oraz mocą obliczeniową, aby utrzymać ciągłość pracy.

Należy pamiętać, że przy jednej jednostce CPU na serwer aplikacyjny nie powinno się tworzyć więcej niż 3 workerów do przetwarzania w tle.

Instrukcja

• Należy utworzyć kolejkę przetwarzania bez serwera aplikacyjnego o nazwie SERVICES dla usług niezależnych od serwera aplikacyjnego.
• Do kolejki przetwarzania SERVICES należy przypisać tyle workerów na tak wielu różnych komputerach, aby w przypadku awarii jednego komputera pozostało wystarczająco dużo workerów do uruchomienia wszystkich usług.

• należy utworzyć kolejkę przetwarzania bez serwera aplikacyjnego o nazwie USERJOBS dla krótkotrwałych zleceń przetwarzania.

• do kolejki przetwarzania USERJOBS należy przypisać tyle workerów na tak wielu różnych komputerach, aby w przypadku awarii jednego komputera pozostało wystarczająco dużo workerów do przetworzenia wszystkich krótkotrwałych zleceń w akceptowalnym czasie.

• należy utworzyć kolejkę przetwarzania bez serwera aplikacyjnego o nazwie MASSJOBS dla długotrwałych zleceń przetwarzania.

• do kolejki przetwarzania MASSJOBS należy przypisać tyle workerów na tak wielu różnych komputerach, aby w przypadku awarii jednego komputera pozostało wystarczająco dużo workerów do przetworzenia wszystkich długotrwałych zleceń w akceptowalnym czasie.

Alternatywny serwer wiadomości

Wymagania 

Należy zapewnić co najmniej dwa niezależne komputery, na których można rozmieścić alternatywne serwery wiadomości. Komputery te powinny być odpowiednio zabezpieczone przed awarią.
Podczas korzystania z alternatywnych serwerów wiadomości należy sprawdzić, czy nie jest również wymagane failover bazy danych. Zarówno baza danych, jak i serwery wiadomości stanowią pojedyncze punkty awarii, a przy porównywalnym sprzęcie oba te komponenty mają podobne prawdopodobieństwo awarii.

Instrukcja

• Należy zarejestrować dwa serwery aplikacji na różnych komputerach

• Należy dodać oba serwery aplikacyjne jako alternatywne serwery wiadomości w systemie