Klaster wysokiej dostępności Windows Server pozwala zachować ciągłość działania kluczowych usług, nawet w razie awarii jednego z serwerów.

Na czym polega ta usługa

Usługa obejmuje skonfigurowanie klastra wysokiej dostępności Windows Server oraz przetestowanie jego działania w warunkach awaryjnych.

Dla kogo ma sens

Usługa jest przydatna dla firm, którym zależy na maksymalnej ciągłości działania kluczowych usług serwerowych.

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.

Zasada działania klastra przełączania awaryjnego

Klaster wysokiej dostępności (zespół połączonych ze sobą serwerów współpracujących w celu zapewnienia ciągłości usług) opiera się na mechanizmie WSFC (Windows Server Failover Clustering, czyli wbudowanej w system funkcji klastrowania z przełączaniem awaryjnym). W klastrze uczestniczą co najmniej dwa węzły (pojedyncze serwery fizyczne lub maszyny wirtualne tworzące wspólne środowisko). Każdy węzeł stale monitoruje stan pozostałych jednostek za pomocą łącza heartbeat (dedykowanego połączenia sieciowego przesyłającego sygnały kontrolne o stanie pracy serwera).

W przypadku wystąpienia usterki sprzętowej, zaniku zasilania na jednym z serwerów lub błędu samego systemu operacyjnego, mechanizm klastra inicjuje proces przełączenia awaryjnego (ang. failover, czyli automatyczne przeniesienie obsługiwanych ról i zasobów na sprawny serwer). Cały proces odbywa się bez konieczności ręcznej interwencji administratora, a czas niedostępności usług zostaje skrócony do minimum. Użytkownicy korzystający z zasobów sieciowych, programów handlowo-magazynowych czy baz danych odnotowują jedynie krótką przerwę techniczną lub kontynuują pracę bez przerw, zależnie od specyfiki uruchomionej usługi.

Warianty wdrożenia klastra Windows Server

W zależności od infrastruktury i potrzeb organizacji konfiguracja klastra może przybierać różne formy architektoniczne:

Klaster wirtualizacji Hyper-V – rozwiązanie wykorzystujące Hyper-V (wbudowaną technologię wirtualizacji Microsoft pozwalającą na uruchamianie wielu systemów na jednym serwerze fizycznym). Maszyny wirtualne umieszczone są na wspólnej pamięci masowej. Dzięki funkcji Live Migration (migracji na żywo bez przestoju) maszyny wirtualne mogą być płynnie przenoszone między fizycznymi węzłami podczas prac konserwacyjnych lub w razie awarii jednego z komputerów.
Klaster baz danych SQL Server – środowisko skonfigurowane w oparciu o instancje klastrowe FCI (Failover Cluster Instances, czyli redundantne instancje serwera bazodanowego korzystające ze wspólnego magazynu danych) lub grupy dostępności Always On (mechanizm replikacji wybranych baz danych na poziomie aplikacji). Zapewnia to stały dostęp do danych dla systemów ERP (oprogramowania do planowania zasobów przedsiębiorstwa) oraz systemów finansowo-księgowych.
Klaster serwera plików – konfiguracja dedykowana do bezpiecznego przechowywania dokumentów i udziałów sieciowych. Występuje jako tradycyjny serwer plików ogólnego przeznaczenia lub SOFS (Scale-Out File Server, czyli skalowalny serwer plików zaprojektowany do równoległej obsługi dużych obciążeń generowanych przez wirtualizację lub bazy danych).
Klaster hiperkonwergentny Storage Spaces Direct – architektura S2D (Storage Spaces Direct, czyli technologia programowo definiowanej pamięci masowej), która łączy lokalne dyski twarde zamontowane w poszczególnych serwerach w jedną współdzieloną pulę pamięci. Eliminuje to konieczność zakupu kosztownej, zewnętrznej macierzy dyskowej.

Wymagania infrastrukturalne i przygotowanie środowiska

Prawidłowe działanie klastra wymaga spełnienia rygorystycznych wymagań technicznych dotyczących sprzętu, sieci oraz uprawnień systemowych. Kluczowe elementy infrastruktury obejmują:

Spójność sprzętowa węzłów – serwery wchodzące w skład klastra powinny posiadać zbliżone parametry techniczne, ten sam model procesora oraz identyczne wersje sterowników. Zgodność platformy sprzętowej jest weryfikowana przez Cluster Validation Wizard (kreator walidacji klastra, który wykonuje serię testów sprawdzających gotowość komponentów do pracy w klastrze).

Architektura połączeń sieciowych – w klastrze niezbędne jest wydzielenie kilku niezależnych tras sieciowych. Stosuje się separację ruchu zarządzającego, ruchu produkcyjnego dla użytkowników, komunikacji wewnętrznej heartbeat oraz ruchu pamięci masowej. W celu zabezpieczenia przed awarią fizycznych przewodów i kart sieciowych wdraża się NIC Teaming (mechanizm agregacji kart sieciowych łączący kilka portów w jeden logiczny, redundantny interfejs).

Współdzielona pamięć masowa – w tradycyjnych klastrach wymagane jest podłączenie wszystkich węzłów do wspólnego zasobu dyskowego za pośrednictwem protokołów iSCSI (protokołu przesyłania poleceń dyskowych przez sieć IP), Fibre Channel (światłowodowej magistrali danych) lub SAS (szeregowego interfejsu dyskowego). Na dyskach tworzone są woluminy CSV (Cluster Shared Volumes, czyli klastrowe współdzielone woluminy, do których wszystkie węzły mają jednoczesny dostęp do odczytu i zapisu).

Struktura usługi katalogowej – klaster wymaga obecności domeny Active Directory (usługi katalogowej zarządzającej tożsamościami i uprawnieniami w sieci). Podczas tworzenia środowiska generowany jest obiekt CNO (Cluster Name Object, czyli konto komputerowe reprezentujące klaster w domenie) oraz obiekty VCO (Virtual Computer Objects, czyli konta wirtualne dla poszczególnych ról klastrowych).

Konfiguracja mechanizmu kworum – Quorum (mechanizm kworum, czyli decyzyjności większościowej określający liczbę elementów klastra niezbędnych do utrzymania jego działania) zapobiega rozspójnieniu środowiska. W zależności od parzystości liczby serwerów stosuje się świadka kworum (element rozstrzygający remis w głosowaniu). Świadkiem może być dysk świadka (Disk Witness), udział plikowy (File Share Witness) lub świadek w chmurze (Cloud Witness).

Błędy popełniane przy samodzielnej konfiguracji klastra

Błędy popełnione na etapie projektowania lub wdrażania klastra mogą prowadzić do sytuacji, w której środowisko zamiast chronić przed przestojami, samo staje się źródłem awarii. Do najczęstszych problemów należą:

Pozostawienie pojedynczych punktów awarii – powszechnym błędem jest utworzenie dwóch węzłów serwerowych, ale podłączenie ich do jednego wspólnego przełącznika sieciowego bez redundancji lub zasilenie obu urządzeń z tej samej fazy bez zasilacza awaryjnego UPS (urządzenia zapewniającego podtrzymanie zasilania akumulatorowego). Awaria pojedynczego elementu pośredniego powoduje wówczas zatrzymanie całego klastra.

Niewłaściwa konfiguracja kworum i ryzyko stanu split-brain – brak skonfigurowanego świadka przy parzystej liczbie węzłów sprawia, że w przypadku przerwania łączności między serwerami oba węzły mogą uznać drugą stronę za niedostępną i spróbować jednocześnie przejąć te same zasoby dyskowe. Zjawisko to nosi nazwę split-brain (stan rozszczepienia klastra) i prowadzi do natychmiastowego uszkodzenia struktury plików na dyskach współdzielonych.

Ignorowanie ostrzeżeń z raportu walidacji – wymuszanie uruchomienia klastra pomimo błędów zgłaszanych przez kreator walidacji często skutkuje niestabilnością środowiska. Ostrzeżenia dotyczące różnic w wersjach poprawek systemowych, niejednolitych sterowników pamięci masowej lub zbyt dużych opóźnień sieciowych muszą zostać wyeliminowane przed wdrożeniem produkcyjnym.

Brak dedykowanej sieci dla pamięci masowej i komunikacji wewnętrznej – przesyłanie ruchu klastrowego tymi samymi przewodami, z których korzystają stacje robocze, stwarza ryzyko utraty pakietów w momentach dużego obciążenia sieci. Klaster może wówczas błędnie zinterpretować opóźnienie w odpowiedzi jako awarię węzła i rozpocząć niepotrzebne przełączanie usług.

Pomijanie procedury testów obciążeniowych i awaryjnych – uruchomienie usług produkcyjnych bez wcześniejszego przeprowadzenia symulacji odcięcia zasilania, odłączenia przewodów sieciowych czy awarii dysków uniemożliwia weryfikację, czy scenariusze przełączania wykonują się w założonym czasie.

Kiedy klaster wysokiej dostępności nie jest właściwym rozwiązaniem

Klaster przełączania awaryjnego rozwiązuje problem dostępności sprzętowej, jednak nie stanowi uniwersalnej odpowiedzi na wszystkie zagrożenia infrastruktury IT. Warto odróżnić klaster od innych mechanizmów zabezpieczeń:

Klaster a kopia zapasowa – klaster wysokiej dostępności nie zastępuje kopii bezpieczeństwa (backupu). Błąd logiczny w bazie danych, przypadkowe skasowanie plików przez pracownika lub zaszyfrowanie dysków przez złośliwe oprogramowanie zostanie natychmiast zreplikowane na wszystkie węzły klastra. Regularna archiwizacja danych poza środowisko klastrowe pozostaje bezwzględnym wymogiem.

Klaster przełączania awaryjnego a równoważenie obciążenia – WSFC służy do ochrony przed awariami (w danym momencie rola działa na jednym aktywnym węźle, a drugi pozostaje w gotowości lub obsługuje inne zadania). W przypadku konieczności równomiernego rozłożenia dużego ruchu sieciowego (np. zapytań do serwera WWW) stosuje się technologię NLB (Network Load Balancing, czyli mechanizm równoważenia obciążenia sieciowego) lub dedykowane kontrolery dostarczania aplikacji.

Replikacja asynchroniczna Hyper-V Replica – dla mniejszych środowisk, które nie dysponują współdzieloną pamięcią masową ani szybkimi łączami światłowodowymi, wystarczającym rozwiązaniem może być Hyper-V Replica (funkcja przesyłania zmian z maszyn wirtualnych na zapasowy serwer w określonych odstępach czasu). Zapewnia ona odtworzenie pracy po awarii przy minimalnym nakładzie sprzętowym, choć wiąże się z możliwością utraty danych z ostatnich kilku minut przed awarią.

Odzyskiwanie po katastrofie – pojedynczy klaster zlokalizowany w jednej szafie serwerowej nie chroni przed zdarzeniami losowymi obejmującymi całe pomieszczenie (np. pożar, zalanie). W takich sytuacjach projektuje się klastry rozproszone geograficznie (ang. stretch cluster, czyli klaster rozciągnięty pomiędzy dwoma różnymi lokalizacjami) połączone łączami światłowodowymi.

Procedura wdrożenia i testowania odporności na awarie

Prace związane z budową klastra wysokiej dostępności realizowane są bezpośrednio w siedzibie klienta na terenie Warszawy oraz 7 okolicznych powiatów (pruszkowskiego, piaseczyńskiego, warszawskiego zachodniego, grodziskiego, legionowskiego, otwockiego i wołomińskiego). Cały proces przebiega według uporządkowanego schematu:

Audyt sprzętu i okablowania – weryfikacja parametrów serwerów fizycznych, macierzy dyskowych, kart sieciowych, zasilaczy awaryjnych oraz konfiguracji przełączników zarządzalnych.

Konfiguracja bazowa systemów Windows Server – instalacja i ujednolicenie systemów operacyjnych na węzłach, konfiguracja adresacji IP, utworzenie zespołów kart sieciowych NIC Teaming oraz wdrożenie ról i funkcji klastrowania.

Przygotowanie pamięci masowej – utworzenie jednostek LUN (Logical Unit Number, czyli logicznych jednostek pamięci masowej wydzielonych na macierzy), skonfigurowanie połączeń iSCSI lub Fibre Channel oraz inicjalizacja woluminów CSV.

Walidacja środowiska – uruchomienie pełnego zestawu testów zgodności w kreatorze klastra, analiza wygenerowanego raportu HTML i usunięcie wszelkich wykrytych nieprawidłowości konfiguracyjnych.

Klastrowanie ról i aplikacji – przeniesienie maszyn wirtualnych, baz danych SQL lub udziałów plikowych do zasobów wysokiej dostępności.

Praktyczne testy awaryjne – kontrolowane wyłączenie zasilania pierwszego serwera, odpięcie kabli transmisyjnych pamięci masowej oraz symulacja awarii sieci wewnętrznej w celu potwierdzenia, że proces przełączenia ról zachodzi bez błędów.

Najczęstsze pytania o klastry Windows Server

Czy do zbudowania klastra wysokiej dostępności potrzebna jest zewnętrzna macierz dyskowa?

Nie jest to konieczne w nowszych wersjach systemu Windows Server. W przypadku zastosowania technologii Storage Spaces Direct (S2D) klaster może korzystać z lokalnych dysków SSD lub NVMe zamontowanych wewnątrz każdego serwera, synchronizując dane bezpośrednio przez sieć Ethernet. Tradycyjna macierz dyskowa (SAN/NAS) pozostaje jednak sprawdzonym i często wybieranym standardem w środowiskach bazodanowych.

Czym różni się świadek udziału plikowego od świadka w chmurze?

Świadek udziału plikowego (File Share Witness) to zwykły folder współdzielony na dowolnym innym serwerze w sieci lokalnej, który bierze udział w głosowaniu klastra nad utrzymaniem kworum. Świadek w chmurze (Cloud Witness) wykorzystuje konto magazynu w chmurze Microsoft Azure, co eliminuje konieczność utrzymywania dodatkowego serwera fizycznego na miejscu w biurze.

Czy wdrożenie klastra wymaga zakupu specjalnych wersji licencji Windows Server?

Funkcja Failover Clustering jest dostępna w wersjach Windows Server Standard oraz Windows Server Datacenter. Jeśli klaster ma pełnić rolę środowiska wirtualizacji Hyper-V z dużą liczbą maszyn wirtualnych, zalecanym wyborem jest edycja Datacenter, która obejmuje nieograniczone prawo do uruchamiania wirtualnych instancji systemu na licencjonowanym sprzęcie.

Czy podczas konfigurowania klastra konieczne jest wyłączenie działających serwerów w firmie?

Większość prac instalacyjnych i konfiguracyjnych na nowych węzłach przeprowadzana jest bez wpływu na bieżącą pracę środowiska produkcyjnego. Jedynie etap migracji istniejących baz danych lub przepinania dysków maszyn wirtualnych do klastra może wymagać zaplanowanego okna serwisowego, które standardowo realizowane jest w godzinach wieczornych lub w dni wolne od pracy.

Co dzieje się w sytuacji, gdy uszkodzeniu ulegną wszystkie węzły klastra jednocześnie?

W przypadku całkowitego zaniku zasilania lub fizycznego zniszczenia serwerowni klaster zatrzymuje pracę. Po przywróceniu sprawności sprzętu i uruchomieniu serwerów usługa klastrowa automatycznie weryfikuje spójność bazy danych klastra i kworum, po czym podnosi role w kolejności określonej w priorytetach startowych. W przypadku uszkodzenia danych konieczne jest odtworzenie stanu z kopii zapasowej.

Niezawodność infrastruktury serwerowej w środowisku Windows Server

Właściwie zaplanowany i przetestowany klaster wysokiej dostępności Windows Server eliminuje ryzyko wielogodzinnych przestojów w działalności operacyjnej przedsiębiorstwa spowodowanych awarią pojedynczego serwera. Precyzyjna konfiguracja warstwy sieciowej, przemyślany dobór modelu kworum oraz wyeliminowanie pojedynczych punktów awarii gwarantują stabilne funkcjonowanie systemów bazodanowych, aplikacji ERP oraz środowisk wirtualnych w trybie ciągłym.

22 378 48 09

Windows Server — konfiguracja klastra wysokiej dostępności