HA dla ERP.
Jak zapewnić wysoką dostępność systemu ERP?

System ERP często odpowiada za sprzedaż, magazyn, produkcję, księgowość i fakturowanie. Gdy przestaje działać, problem nie dotyczy wyłącznie działu IT. Pracownicy nie mogą realizować zamówień, wystawiać dokumentów ani obsługiwać klientów.

Dlatego firmy coraz częściej pytają o wysoką dostępność, czyli High Availability. Sam zakup drugiego serwera nie tworzy jednak środowiska HA. Odporność musi obejmować cały łańcuch działania systemu: zasilanie, sieć, storage, wirtualizację, bazę danych, aplikację, dostęp użytkowników i backup.

Dobrze zaprojektowane HA nie obiecuje, że żadna awaria nigdy nie nastąpi. Ma ograniczyć jej wpływ, automatycznie przełączyć usługi na sprawne elementy i umożliwić powrót do pracy w czasie akceptowalnym dla biznesu.

Co oznacza wysoka dostępność systemu ERP?

HA oznacza zdolność środowiska do dalszego działania mimo awarii jednego z jego elementów. Może to być awaria hosta wirtualizacji, dysku, kontrolera, przełącznika, zasilacza, systemu operacyjnego, instancji SQL Server, serwera aplikacyjnego lub połączenia internetowego.

Nie każda firma potrzebuje jednak tej samej dostępności. Dla jednej organizacji akceptowalny będzie dziesięciominutowy przestój. Dla innej nawet minuta przerwy zatrzyma linię produkcyjną lub obsługę tysięcy zamówień.

Dlatego projektowanie HA należy rozpocząć od ustalenia dwóch parametrów.

RTO i RPO powinny wynikać z analizy procesów biznesowych, a nie z możliwości wybranego produktu.

HA, backup i Disaster Recovery to trzy różne rzeczy

Pojęcia te są często używane zamiennie, chociaż rozwiązują inne problemy.

Klaster HA nie zastępuje backupu. Backup nie zapewnia natomiast automatycznego przełączenia po awarii hosta. Skuteczne środowisko ERP powinno łączyć wszystkie trzy warstwy.

Dlaczego HA tylko na poziomie Proxmox nie zawsze wystarczy?

Proxmox VE posiada mechanizm HA Manager, który może monitorować wskazane maszyny wirtualne i po awarii węzła uruchomić je na innym serwerze klastra. Dla niezawodnego quorum producent rekomenduje co najmniej trzy głosy. W środowisku dwuwęzłowym można zastosować QDevice jako dodatkowy głos, ale projekt wymaga szczególnej ostrożności.

Takie rozwiązanie chroni przed awarią fizycznego hosta, ale nie jest bezprzerwowe. Proces obejmuje:

1. 1 wykrycie awarii,
2. 2 ustalenie stanu klastra,
3. 3 odizolowanie niesprawnego węzła,
4. 4 uruchomienie maszyny na innym hoście,
5. 5 start systemu operacyjnego,
6. 6 start SQL Server i aplikacji ERP.

Przerwa może trwać kilka minut lub dłużej, zależnie od konfiguracji i czasu uruchamiania systemu.

Dla wielu firm jest to wystarczające. Jeżeli wymagany jest krótszy przestój, trzeba wdrożyć dodatkową redundancję na poziomie bazy i aplikacji.

Warstwy wysokiej dostępności ERP

Warstwa sprzętowa

Każdy krytyczny element powinien mieć redundancję lub możliwość szybkiej wymiany. Dotyczy to między innymi zasilaczy, kontrolerów, dysków, interfejsów sieciowych, przełączników, zasilania UPS oraz połączeń z Data Center lub internetem.

Klaster z trzema serwerami podłączonymi do jednego przełącznika i jednego UPS-a nadal posiada istotne pojedyncze punkty awarii.

Warstwa sieciowa

Środowisko powinno posiadać osobne lub logicznie wydzielone sieci dla zarządzania, komunikacji klastra, storage, backupu, maszyn produkcyjnych i dostępu użytkowników. Ważne są również redundantne przełączniki i co najmniej dwa niezależne połączenia każdego hosta.

Corosync jest wrażliwy na opóźnienia oraz utratę pakietów, dlatego ruch klastra nie powinien konkurować z backupem lub dużymi transferami maszyn wirtualnych.

Warstwa wirtualizacji

Najczęściej stosuje się klaster z co najmniej trzema węzłami Proxmox. Zapewnia on quorum, migrację maszyn pomiędzy węzłami, automatyczne uruchamianie VM po awarii hosta, centralne zarządzanie i łatwiejsze wykonywanie prac serwisowych.

Live Migration jest szczególnie przydatna przy planowanych aktualizacjach. Pozwala przenieść działającą maszynę przed restartem hosta. Nie pomaga jednak, gdy serwer ulegnie nagłej awarii.

Storage dla wysokiej dostępności ERP

Warstwa storage jest jednym z najważniejszych elementów projektu.

Ceph

Ceph zapewnia rozproszony storage dostępny dla wielu węzłów. Dane są replikowane pomiędzy dyskami i serwerami, dzięki czemu awaria pojedynczego hosta nie musi oznaczać utraty dostępu do wolumenu maszyny.

Proxmox wymaga co najmniej trzech, najlepiej podobnych sprzętowo serwerów do budowy hiperkonwergentnego klastra z Ceph. Poprawna implementacja wymaga odpowiedniej liczby dysków i szybkiej sieci.

Ceph nie jest jednak automatycznie najlepszym rozwiązaniem dla każdej firmy. Ma sens, gdy:

• -wymagana jest wysoka dostępność storage,
• -infrastruktura posiada odpowiednio szybką sieć,
• -dostępna jest wystarczająca liczba dysków,
• -środowisko jest stale monitorowane,
• -zespół ma kompetencje do jego utrzymania.

Źle zaprojektowany Ceph może mieć gorszą wydajność niż prostszy lokalny storage.

ZFS i replikacja

Alternatywą dla mniejszych środowisk jest lokalny ZFS oraz replikacja maszyn pomiędzy węzłami. Takie rozwiązanie jest prostsze, może oferować bardzo dobrą wydajność, nie wymaga rozproszonego storage i zwykle kosztuje mniej.

Trzeba jednak pamiętać, że replikacja może być asynchroniczna. Oznacza to możliwość utraty zmian wykonanych od ostatniej synchronizacji. RPO zależy więc od częstotliwości replikacji.

Zewnętrzny shared storage

Można również zastosować macierz SAN, NFS lub iSCSI. Zapewnia ona współdzielony dostęp do danych, ale sama macierz nie może być pojedynczym punktem awarii. Wymaga redundantnych kontrolerów, ścieżek sieciowych i zasilania.

Wysoka dostępność SQL Server

Jeżeli ERP korzysta z Microsoft SQL Server, samo HA maszyny wirtualnej nie zabezpiecza przed awarią usługi SQL, uszkodzeniem systemu operacyjnego, błędem instancji, problemem z konkretną bazą ani długim restartem maszyny. Konfigurację samej bazy opisaliśmy w artykule SQL Server dla ERP.

W środowiskach o bardziej rygorystycznym RTO można rozważyć mechanizmy SQL Server.

Always On Availability Groups

Availability Groups replikują bazy pomiędzy instancjami SQL Server i mogą automatycznie przełączyć bazę na replikę pomocniczą. Mechanizm działa w oparciu o Windows Server Failover Clustering. Tryb failoveru i czas przełączenia zależą od konfiguracji replik, synchronizacji oraz polityki monitorowania.

Trzeba uwzględnić edycję SQL Server. W SQL Server Standard dostępne są Basic Availability Groups, które mają istotne ograniczenia:

• -dwie repliki,
• -jedna baza w jednej grupie,
• -brak odczytu z repliki pomocniczej,
• -brak wykonywania backupu na replice pomocniczej,
• -brak części zaawansowanych możliwości Enterprise.

Wiele systemów ERP korzysta z kilku baz, dlatego przed wyborem tego rozwiązania trzeba sprawdzić wymagania aplikacji, edycję SQL oraz koszty licencji.

Failover Cluster Instance

FCI zapewnia wysoką dostępność całej instancji SQL Server i działa w oparciu o Windows Server Failover Clustering. Instancja jest instalowana na wielu węzłach i korzysta ze współdzielonego storage.

Rozwiązanie chroni instancję, ale nie zapewnia kopii danych na niezależnym storage, jeżeli całość korzysta z tej samej macierzy.

Replikacja nie zastępuje backupu

Błąd użytkownika, usunięcie danych lub zaszyfrowanie bazy może zostać natychmiast przeniesione na replikę. Dlatego SQL HA nadal wymaga pełnych backupów, backupów różnicowych, kopii logu transakcyjnego, kopii off-site i testów odtwarzania. Kompletną strategię opisaliśmy w artykule Backup ERP.

Wysoka dostępność aplikacji ERP

Nie każdy system ERP obsługuje aktywną pracę kilku serwerów aplikacyjnych. Możliwe modele to:

Wybór zależy od producenta ERP. Nie należy samodzielnie uruchamiać kilku serwerów aplikacyjnych, jeżeli system nie wspiera takiego modelu.

Trzeba również sprawdzić sposób przechowywania sesji, licencjonowanie, wspólne katalogi, mechanizmy kolejek, integracje, usługi harmonogramu oraz dostęp użytkowników.

Dostęp użytkowników i load balancing

Nawet działający ERP może być niedostępny, jeżeli awarii ulegnie terminal RDS, brama VPN, reverse proxy, DNS, firewall lub pojedyncze łącze internetowe. Dlatego projekt HA powinien uwzględniać również ścieżkę użytkownika do aplikacji.

Może to oznaczać:

Backup i Disaster Recovery

Środowisko HA nadal wymaga pełnej strategii backupu. Przykładowe warstwy ochrony:

1. 1 natywne backupy SQL Server,
2. 2 backup maszyn wirtualnych do Proxmox Backup Server,
3. 3 kopia w drugiej lokalizacji,
4. 4 chroniona kopia offline lub immutable,
5. 5 regularne testy odtworzenia.

Proxmox Backup Server zapewnia mechanizmy backupu przyrostowego, deduplikacji i weryfikacji, ale powinien być elementem szerszej strategii, a nie jedyną kopią.

Monitoring środowiska HA

Automatyczny failover nie zwalnia z monitoringu. Należy obserwować:

Szczególnie niebezpieczna jest sytuacja, w której środowisko działa po awarii jednego elementu, ale nikt nie zauważa utraty redundancji. Kolejna awaria może już spowodować pełny przestój.

Testowanie failoveru

Środowisko HA, którego nigdy nie testowano, jest tylko projektem teoretycznym. Testy powinny obejmować:

Nie wszystkie testy muszą polegać na fizycznym wyciąganiu przewodów w produkcji. Powinny jednak potwierdzać, że procedury, automatyka i monitoring działają zgodnie z projektem.

Każdy test powinien zakończyć się raportem zawierającym rzeczywisty czas niedostępności, utracone dane, błędy, działania ręczne i rekomendacje. Dopiero wtedy można uczciwie deklarować osiągane RTO i RPO.

Przykładowa architektura HA dla ERP

Dla średniej firmy typowa koncepcja może obejmować:

Taki projekt trzeba dostosować do konkretnego systemu. Nie każdy ERP wymaga wszystkich warstw.

Ile kosztuje HA dla ERP?

Nie istnieje uniwersalny cennik. Koszt zależy od liczby użytkowników, wielkości bazy, wymaganych RTO i RPO, wydajności storage, liczby lokalizacji, edycji SQL Server, licencji Windows Server, obsługi HA przez aplikację, zakresu backupu i DR oraz poziomu wsparcia.

Koszt może obejmować trzy lub więcej hostów, dyski enterprise, redundantną sieć, licencje Windows i SQL, wdrożenie klastra, monitoring, backup, testy, administrację oraz umowę SLA. Z tego powodu nie należy zakładać, że każdy klaster dla 30 użytkowników będzie kosztował podobnie.

Najpierw trzeba policzyć koszt przestoju.

Jeżeli godzina niedostępności kosztuje firmę 20 000 zł, inwestycja w HA może zwrócić się po jednym incydencie. Jeżeli ERP jest używany przez kilka osób tylko przez część dnia, prostsza architektura i dobry backup mogą być bardziej racjonalne.

Kiedy warto wdrożyć HA dla ERP?

Wysoka dostępność ma szczególne uzasadnienie, gdy:

• -przestój zatrzymuje sprzedaż lub produkcję,
• -ERP pracuje przez całą dobę,
• -system obsługuje wiele lokalizacji,
• -aplikacja współpracuje z WMS, MES, BI i e-commerce,
• -baza wykonuje dużą liczbę transakcji,
• -firma ma bardzo krótki dopuszczalny RTO,
• -nie ma długich okien serwisowych.

Nie należy jednak opierać decyzji wyłącznie na liczbie użytkowników. ERP używany przez dziesięć osób może być bardziej krytyczny niż system wykorzystywany przez pięćdziesiąt, jeżeli bez niego zatrzymuje się produkcja.

Kiedy prostsze rozwiązanie będzie lepsze?

Pełne HA może nie mieć uzasadnienia, gdy system pracuje tylko w godzinach biurowych, firma akceptuje kilka godzin przestoju, istnieje skuteczna procedura pracy awaryjnej, koszt niedostępności jest niski, środowisko jest niewielkie albo budżet lepiej przeznaczyć najpierw na backup i bezpieczeństwo.

W takim przypadku rozsądny wariant może obejmować:

• -dwa serwery,
• -replikację,
• -dobry backup,
• -sprzęt zastępczy,
• -sprawdzoną procedurę odtworzenia,
• -monitoring.

Najdroższe rozwiązanie nie zawsze jest najlepsze. Najlepsze jest to, które odpowiada realnemu ryzyku biznesowemu.

Najczęstsze błędy przy wdrażaniu HA

Klaster HA w jednej serwerowni nie ochroni firmy przed utratą całej lokalizacji, a konfiguracja nigdy niesprawdzona podczas awarii nie daje wiarygodnej informacji o realnym RTO.

Podsumowanie

Prawdziwe HA dla ERP nie jest jednym produktem ani jedną funkcją w panelu Proxmox. To wielowarstwowa architektura obejmująca redundantny sprzęt, sieć, storage, klaster wirtualizacji, bazę SQL, aplikację ERP, dostęp użytkowników, monitoring, backup i Disaster Recovery.

Klaster Proxmox z Ceph może być bardzo dobrym fundamentem takiego środowiska, ale nie zawsze musi być najlepszym wyborem. W niektórych firmach wystarczy HA maszyny wirtualnej, w innych potrzebne będą również SQL Server Always On, redundantne serwery aplikacyjne i druga lokalizacja.

Projekt należy rozpocząć od rozmowy o biznesie: ile kosztuje godzina przestoju, ile danych można utracić i jak szybko system musi wrócić do pracy. Dopiero później dobiera się technologię.

W PRO-Admin analizujemy cały łańcuch działania systemu ERP. Sprawdzamy infrastrukturę, SQL Server, aplikację, sieć, backup i procedury awaryjne. Na tej podstawie przygotowujemy architekturę dopasowaną do rzeczywistych wymagań, bez budowania nadmiernie drogiego środowiska tylko dlatego, że technicznie jest to możliwe.