Failover Clustering pozwala zachować ciągłość działania kluczowych aplikacji biznesowych, nawet w razie awarii jednego z serwerów.

Na czym polega ta usługa

Usługa obejmuje skonfigurowanie klastra typu Failover Clustering na Windows Server oraz przetestowanie jego działania.

Dla kogo ma sens

Usługa jest przydatna dla firm, którym zależy na maksymalnej dostępności kluczowych aplikacji biznesowych.

Ile to trwa

Konfiguracja klastra mieści się z reguły w standardowym czasie do 3 dni.

Warunki

Diagnoza wstępna i wycena są bezpłatne, a usługa objęta jest gwarancją do 12 miesięcy.

Architektura i mechanizm działania klastra Failover Clustering

Klaster pracy awaryjnej (Failover Clustering) w systemie Windows Server to rozwiązanie wysokiej dostępności (High Availability – HA), które łączy ze sobą wiele niezależnych serwerów fizycznych lub maszyn wirtualnych (nazywanych węzłami, czyli nodes) w jedną logiczną strukturę. Głównym zadaniem klastra jest ciągłe monitorowanie stanu uruchomionych usług, ról oraz zasobów sprzętowych. W momencie wystąpienia awarii sprzętu, systemu operacyjnego lub błędu krytycznego na węźle aktywnym, mechanizmy klastra automatycznie przenoszą obsługę aplikacji na węzeł zapasowy (pasywny) bez konieczności ręcznej interwencji administratora.

Sercem klastra jest usługa klastrowania (Cluster Service), która nadzoruje komunikację wewnętrzną oraz zarządza stanem poszczególnych komponentów. Prawidłowo zaprojektowana infrastruktura klastrowa opiera się na kilku fundamentalnych filarach technologicznych:

Węzły klastra (Cluster Nodes) – serwery wyposażone w system Windows Server, które współdzielą odpowiedzialność za wykonywanie powierzonych zadań biznesowych. W zależności od konfiguracji klaster może działać w trybie aktywny-pasywny (jeden serwer przetwarza dane, drugi oczekuje w gotowości) lub aktywny-aktywny (różne usługi są rozdzielone pomiędzy węzłami i wzajemnie się zabezpieczają).
Współdzielona pamięć masowa (Shared Storage) – centralny magazyn danych dostępny jednocześnie dla wszystkich węzłów. Może być zrealizowany za pomocą zewnętrznej macierzy dyskowej (wykorzystującej protokoły iSCSI, Fibre Channel lub SAS) bądź programowo definiowanej pamięci masowej Storage Spaces Direct (S2D), która łączy lokalne dyski serwerów w jedną pulę.
Współdzielone wolumeny klastra (Cluster Shared Volumes – CSV) – rozszerzenie systemu plików, które umożliwia wielu węzłom równoczesny odczyt i zapis do tego samego wolumenu dyskowego, co jest kluczowe przy wirtualizacji Hyper-V oraz bazach danych SQL Server.
Dedykowane sieci komunikacyjne – klaster wymaga rozdzielenia ruchu sieciowego. Ruch produkcyjny służy użytkownikom do łączenia się z aplikacjami, natomiast sieć wewnętrzna (tzw. heartbeat) przesyła pakiety kontrolne sprawdzające dostępność poszczególnych serwerów, a sieć pamięci masowej obsługuje transmisję danych dyskowych.
Mechanizm kworum (Quorum) – algorytm oparty na głosowaniu, który decyduje o tym, czy klaster posiada wystarczającą liczbę działających elementów, aby bezpiecznie kontynuować pracę i uniknąć uszkodzenia danych.

Rola kworum i świadka w zapobieganiu zjawisku split-brain

Jednym z najpoważniejszych zagrożeń w środowiskach klastrowych jest sytuacja określana jako split-brain (rozszczepienie klastra). Dochodzi do niej, gdy węzły klastra tracą ze sobą łączność sieciową, ale każdy z nich nadal działa poprawnie. Bez odpowiedniego zabezpieczenia oba serwery mogłyby uznać drugi węzeł za uszkodzony i podjąć jednoczesną próbę przejęcia współdzielonych zasobów dyskowych. Taki stan prowadzi do natychmiastowego uszkodzenia integralności baz danych i plików.

Aby temu zapobiec, Windows Server wykorzystuje mechanizm kworum. Każdy węzeł posiada jeden głos, a klaster może funkcjonować tylko wtedy, gdy łączna liczba aktywnych głosów stanowi większość (ponad 50 procent). W klastrach o parzystej liczbie serwerów (na przykład w popularnych wdrożeniach dwuwęzłowych) konieczne jest dodanie dodatkowego zasobu rozstrzygającego, zwanego świadkiem kworum (Quorum Witness). W zależności od infrastruktury stosuje się następujące warianty świadka:

Świadek udziału plikowego (File Share Witness – FSW) – zabezpieczony udział sieciowy SMB zlokalizowany na osobnym serwerze poza klastrem, który otrzymuje jeden głos rozstrzygający.
Świadek w chmurze (Cloud Witness) – nowoczesny mechanizm wykorzystujący konto pamięci masowej w chmurze Microsoft Azure jako zewnętrzny punkt głosowania, eliminujący konieczność utrzymywania dodatkowego serwera fizycznego.
Świadek dyskowy (Disk Witness) – dedykowany mały wolumen (LUN) na współdzielonej macierzy dyskowej, do którego dostęp mogą uzyskać tylko sprawne węzły.

Prawidłowe skonfigurowanie dynamicznego kworum (Dynamic Quorum) oraz dynamicznego świadka (Dynamic Witness) w systemie Windows Server pozwala klastrowi na automatyczne dostosowywanie wag głosów w miarę planowego wyłączania lub awarii kolejnych węzłów, co pozwala utrzymać działanie usług nawet przy zachowaniu tylko jednego sprawnego serwera.

Obsługa systemów ERP i krytycznych baz danych

Konfiguracja Failover Clustering w środowiskach biznesowych najczęściej służy do zabezpieczenia oprogramowania do zarządzania przedsiębiorstwem oraz relacyjnych baz danych. Wiele firm opiera swoją codzienną działalność na systemach ERP, takich jak Comarch ERP (Optima, XL), InsERT nexo oraz GT (Subiekt, Rewizor, Gratyfikant), Sage Symfonia, WAPRO ERP (Mag, Fakir), RAKS, enova365 czy SAP. Przestój bazy danych tych aplikacji paraliżuje sprzedaż, magazyn, fakturowanie oraz obsługę zamówień.

Wdrażanie klastra dla środowisk bazodanowych Microsoft SQL Server realizowane jest zazwyczaj w jednym z dwóch wariantów:

Klastrowa instancja SQL Server (Failover Cluster Instance – FCI) – cała instancja silnika bazy danych jest instalowana na poziomie klastra Windows Server. Pliki baz danych znajdują się na współdzielonym wolumenie dyskowym. W razie awarii węzła aktywnego następuje restart instancji na drugim węźle i ponowne podmontowanie baz danych. Czas przełączenia wynosi zazwyczaj od kilkunastu sekund do kilku minut, w zależności od liczby otwartych transakcji.
Grupy dostępności SQL Server (Always On Availability Groups) – zaawansowane rozwiązanie, które wykorzystuje mechanizmy klastra Windows Server (WSFC) do monitorowania stanu i zarządzania punktem dostępowym (Listener), ale nie wymaga współdzielonej macierzy dyskowej. Każdy węzeł posiada własną kopię bazy danych, a transakcje są synchronizowane w czasie rzeczywistym. Zapewnia to natychmiastowe przełączenie awaryjne (Failover) oraz możliwość wykorzystania replik pomocniczych do odczytu danych (np. do generowania raportów bez obciążania serwera głównego).

Oprócz baz danych klaster Failover Clustering zabezpiecza również serwery wirtualizacji Hyper-V. W tym scenariuszu maszyny wirtualne zawierające serwery aplikacji ERP, kontrolery domeny Active Directory czy serwery terminalowe są uruchomione na klastrze maszyn wirtualnych. Dzięki funkcji Live Migration (migracja na żywo) możliwe jest bezprzerwowe przenoszenie pracujących maszyn między serwerami fizycznymi na czas konserwacji sprzętu, wymiany podzespołów czy instalacji poprawek systemowych.

Procedura wdrożenia i wymagania techniczne

Wdrożenie klastra niezawodnościowego wymaga skrupulatnego przygotowania warstwy sprzętowej, sieciowej i systemowej. Proces konfiguracji realizowany podczas prac wdrożeniowych składa się z kilku etapów:

Audyt zgodności sprzętowej i licencyjnej – weryfikacja procesorów, pamięci RAM, kontrolerów sieciowych oraz wersji systemu operacyjnego Windows Server (Standard lub Datacenter). Zaleca się stosowanie identycznych konfiguracji sprzętowych na wszystkich węzłach w celu uniknięcia problemów ze zgodnością sterowników.
Przygotowanie struktury Active Directory – węzły klastra muszą być członkami tej samej domeny Active Directory Domain Services (AD DS). W usłudze katalogowej tworzone są odpowiednie obiekty komputerów (Cluster Name Object – CNO oraz Virtual Computer Objects – VCO) z właściwymi uprawnieniami administracyjnymi.
Konfiguracja podsystemu sieciowego – utworzenie redundantnych połączeń sieciowych z wykorzystaniem technologii agregacji łączy (NIC Teaming lub Switch Embedded Teaming – SET). Konieczne jest przypisanie statycznych adresów IP dla punktów dostępowych klastra oraz skonfigurowanie odpowiednich podsieci dla komunikacji heartbeat i replikacji danych.
Przygotowanie i inicjalizacja pamięci masowej – utworzenie wolumenów dyskowych (LUN) na macierzy iSCSI lub SAS, przypisanie unikalnych identyfikatorów dysków oraz sformatowanie partycji w systemie plików NTFS lub ReFS z obsługą mechanizmu rezerwacji trwałej (SCSI-3 Persistent Reservation).
Walidacja konfiguracji klastra (Cluster Validation Wizard) – uruchomienie oficjalnego zestawu testów diagnostycznych firmy Microsoft. Narzędzie testuje wydajność i spójność sieci, poprawność działania magistrali dyskowej, konfigurację oprogramowania oraz uprawnienia domenowe. Dopiero uzyskanie w pełni pozytywnego raportu (lub raportu z akceptowalnymi ostrzeżeniami) daje gwarancję stabilnej pracy i pełnego wsparcia technicznego producenta.
Instalacja i konfiguracja ról klastra – utworzenie klastra za pomocą Menedżera klastra pracy awaryjnej (Failover Cluster Manager) lub poleceń środowiska PowerShell, dodanie świadka kworum oraz wdrożenie wymaganych ról wysokiej dostępności.
Rygorystyczne testy przełączania awaryjnego – praktyczna weryfikacja zachowania klastra w kontrolowanych warunkach awaryjnych (symulacja odłączenia kabla sieciowego, awarii zasilania węzła, zatrzymania procesów bazodanowych oraz wymuszonego przełączenia ról).

Typowe warianty problemów i usterek w działaniu klastra

Nawet prawidłowo wdrożony klaster może w trakcie eksploatacji napotkać trudności wynikające ze zmian w infrastrukturze IT lub zużycia komponentów sprzętowych. W praktyce spotyka się kilka charakterystycznych kategorii awarii:

Niestabilność komunikacji międzywęzłowej (Heartbeat Packet Loss) – gubienie pakietów kontrolnych w sieci klastra, wywołane przeciążeniem przełączników sieciowych, błędną konfiguracją zapory sieciowej (Windows Defender Firewall) lub awarią karty sieciowej. Skutkuje to niepotrzebnymi, fałszywymi przełączeniami usług między serwerami.
Utrata łączności ze współdzieloną pamięcią masową (Storage Dropouts) – przerwanie sesji iSCSI, błędy kontrolera macierzy lub uszkodzenie magistrali kablowej. Prowadzi to do przejścia wolumenów CSV w stan izolacji lub przejścia zasobów dyskowych w tryb tylko do odczytu.
Zablokowanie zasobów w stanie oczekiwania (Resource State Pending/Failed) – sytuacja, w której rola klastrowa nie może pomyślnie wystartować na węźle docelowym po awarii. Najczęściej jest to spowodowane brakiem uprawnień konta serwisowego, wygaśnięciem certyfikatów SSL/TLS, konfliktami portów sieciowych lub uszkodzeniem plików konfiguracyjnych aplikacji.
Problemy z rejestracją rekordów w usłudze DNS i Active Directory – błędy synchronizacji punktu dostępowego klastra z serwerami nazw DNS, co uniemożliwia stacjom roboczym odnalezienie adresu wirtualnego klastra po przełączeniu awaryjnym.
Błędy aktualizacji klastrowych (Cluster-Aware Updating – CAU) – nieprawidłowe działanie mechanizmu automatycznej instalacji łatek, w wyniku którego węzeł zostaje zrestartowany zanim usługi zostaną bezpiecznie opróżnione (drained) i przeniesione na działający serwer.

Błędy popełniane przy samodzielnym wdrażaniu klastrów

Próby samodzielnego konfigurowania lub modyfikowania klastrów Windows Server bez odpowiedniego doświadczenia inżynieryjnego często prowadzą do obniżenia poziomu bezpieczeństwa danych lub całkowitego zablokowania usług. Najczęstsze błędy obejmują:

Pojedynczy punkt awarii (Single Point of Failure – SPOF) – podłączenie wszystkich serwerów klastra do jednego przełącznika sieciowego (switcha), jednej listwy zasilającej lub zdefiniowanie świadka kworum na maszynie zależnej od tego samego zasilania. Awaria takiego pojedynczego elementu unieruchamia cały klaster.
Ignorowanie ostrzeżeń kreatora walidacji – wymuszenie utworzenia klastra pomimo błędów dotyczących rezerwacji dyskowych lub nierównomiernych czasów odpowiedzi sieci, co skutkuje niestabilnością całego środowiska produkcyjnego.
Zarządzanie usługami z pominięciem konsoli klastra – ręczne zatrzymywanie, uruchamianie lub restartowanie usług systemowych (np. silnika SQL Server) za pomocą apletu services.msc zamiast Menedżera klastra pracy awaryjnej. Powoduje to, że usługa klastra interpretuje takie działanie jako nagłą awarię i rozpoczyna niekontrolowane przełączanie zasobów.
Brak cyklicznych testów procedury Failover – pozostawienie klastra bez okresowej weryfikacji manualnego i automatycznego przełączania ról. W sytuacji rzeczywistej awarii sprzętu okazuje się wówczas, że np. brak miejsca na węźle zapasowym lub nieaktualne sterowniki uniemożliwiają przejęcie obciążenia.
Mieszanie wersji i edycji systemów operacyjnych – próba łączenia w jednym klastrze węzłów z różnymi wersjami Windows Server (np. Windows Server 2016 i Windows Server 2022) poza procedurą migracji stopniowej (Rolling Cluster OS Upgrade).

Kiedy Failover Clustering NIE jest właściwym rozwiązaniem

Mimo ogromnych zalet Failover Clustering nie jest uniwersalnym lekiem na każdy problem związany z dostępnością systemów informatycznych. Ważne jest precyzyjne odróżnienie klastrowania pracy awaryjnej od innych technologii:

Ochrona przed uszkodzeniem danych i ransomware – klaster chroni przed awarią sprzętu i systemu operacyjnego, lecz nie zabezpiecza przed logicznym uszkodzeniem danych, przypadkowym skasowaniem plików przez użytkownika czy zaszyfrowaniem bazy przez złośliwe oprogramowanie. Uszkodzone dane są natychmiast widoczne na obu węzłach. Klaster nigdy nie zastępuje regularnie wykonywanych kopii zapasowych (backupów) przechowywanych w odizolowanej lokalizacji.
Równoważenie obciążenia sieciowego (Network Load Balancing – NLB) – Failover Clustering służy do zapewnienia ciągłości działania usług stanowych (gdzie dane zmieniają się dynamicznie, np. bazy danych SQL). Dla bezstanowych aplikacji webowych (np. serwery stron WWW na IIS) właściwym rozwiązaniem jest klastrowanie NLB, które rozdziela ruch użytkowników na wiele serwerów jednocześnie w celu zwiększenia wydajności.
Brak infrastruktury pod redundantny sprzęt – wdrożenie klastra na pojedynczym serwerze fizycznym z wieloma maszynami wirtualnymi nie chroni przed awarią zasilacza, płyty głównej czy procesora tej maszyny fizycznej. Klaster wymaga co najmniej dwóch niezależnych jednostek sprzętowych.

Dodatkowe pytania i odpowiedzi (FAQ)

Czy po awarii jednego z serwerów użytkownicy zostaną odłączeni od systemu ERP?

W przypadku klastrów bazodanowych w architekturze FCI (Failover Cluster Instance) następuje krótkotrwałe przerwanie połączenia na czas restartu usługi SQL Server na węźle zapasowym, trwające zazwyczaj od kilkunastu do kilkudziesięciu sekund. Aplikacje ERP wspierające automatyczne ponawianie połączeń (Connection Retry) wznawiają pracę samoczynnie. W przypadku wirtualizacji Hyper-V z migracją na żywo (Live Migration) przeniesienie maszyny odbywa się całkowicie bezprzerwowo i jest niezauważalne dla zalogowanych użytkowników.

Ile serwerów fizycznych jest minimalnie wymaganych do uruchomienia bezpiecznego klastra?

Minimalna konfiguracja klastra wysokiej dostępności to dwa serwery fizyczne (węzły) połączone ze świadkiem kworum (np. świadkiem udziału plikowego na osobnym urządzeniu NAS lub świadkiem w chmurze Cloud Witness w usłudze Azure). Taka architektura zapewnia pełną odporność na awarię jednego kompletnego serwera.

Czy do wdrożenia klastra niezbędna jest droga macierz dyskowa SAN?

Nie zawsze. W nowszych wersjach systemu Windows Server (edycja Datacenter) można wykorzystać technologię Storage Spaces Direct (S2D), która tworzy wirtualną, współdzieloną przestrzeń dyskową z lokalnych dysków SSD/NVMe zainstalowanych bezpośrednio w serwerach. Alternatywnie w mniejszych środowiskach z powodzeniem stosuje się wydajne pamięci masowe NAS obsługujące protokół iSCSI z rezerwacją SCSI-3.

W jaki sposób weryfikowana jest poprawność działania klastra po zakończeniu prac?

Po zakończeniu instalacji przeprowadzana jest pełna procedura testowa. Obejmuje ona weryfikację raportu Cluster Validation Wizard, symulację planowego przełączania ról (Live Migration / Switchover) oraz testy awaryjne polegające na odcięciu zasilania węzła aktywnego lub odłączeniu łączy sieciowych, aby potwierdzić, że aplikacje biznesowe zachowują pełną spójność danych i dostępność.

Jakie uprawnienia i przygotowanie są konieczne przed przystąpieniem do konfiguracji?

Wymagany jest dostęp administracyjny do domeny Active Directory oraz uprawnienia do tworzenia obiektów komputerów w odpowiedniej jednostce organizacyjnej (OU). Wszystkie węzły muszą posiadać zainstalowane oficjalne aktualizacje systemowe oraz poprawnie skonfigurowane adresy IP w wydzielonych podsieciach klastrowych.

Profesjonalne wdrożenia i audyty klastrów Windows Server

Prawidłowe wdrożenie klastra Failover Clustering eliminuje ryzyko kosztownych przestojów w działalności operacyjnej przedsiębiorstwa. Wszystkie prace konfiguracyjne, audyty istniejących środowisk wysokiej dostępności oraz testy procedur awaryjnych realizowane są bezpośrednio w siedzibie klienta na terenie Warszawy oraz okolicznych powiatów (grodziski, legionowski, otwocki, piaseczyński, pruszkowski, warszawski zachodni, wołomiński). Każda konfiguracja kończy się sporządzeniem dokumentacji powykonawczej, weryfikacją polityk kworum oraz testami obciążeniowymi, co zapewnia stabilność krytycznych systemów ERP i baz danych.

22 378 48 09

Windows Server — konfiguracja Failover Clustering dla aplikacji biznesowych