Failover Clustering na Windows Server — wysoka dostępność dla firm

Czym jest Failover Clustering w Windows Server?

Failover Clustering (klastrowanie awaryjne) to wbudowana funkcja systemu Windows Server, która zapewnia wysoką dostępność (High Availability) krytycznych usług i aplikacji. Mechanizm ten łączy dwa lub więcej serwerów (nazywanych węzłami) w jeden logiczny klaster, który automatycznie przejmuje obciążenie w przypadku awarii jednego z węzłów.

W praktyce oznacza to, że jeśli serwer główny przestanie działać — z powodu awarii sprzętu, aktualizacji systemu lub błędu oprogramowania — drugi węzeł natychmiast przejmuje jego rolę. Użytkownicy końcowi mogą nawet nie zauważyć przerwy, ponieważ cały proces failover trwa zaledwie kilka sekund.

Failover Clustering jest dostępny w edycjach Standard i Datacenter systemu Windows Server — od wersji 2016 aż po najnowszy Windows Server 2025. Edycja Datacenter oferuje dodatkowe funkcje, takie jak Storage Spaces Direct (S2D) i nieograniczona wirtualizacja Hyper-V, co czyni ją idealnym wyborem dla dużych wdrożeń klastrowych.

Kiedy warto wdrożyć Failover Clustering? Przypadki użycia

Failover Clustering znajduje zastosowanie wszędzie tam, gdzie przestój oznacza straty finansowe lub naruszenie umów SLA. Oto najważniejsze scenariusze:

Klaster Hyper-V — wysoka dostępność maszyn wirtualnych

Dzięki Failover Clustering maszyny wirtualne Hyper-V mogą być automatycznie migrowane na inny węzeł w przypadku awarii hosta. Technologia Live Migration umożliwia przenoszenie VM bez przerwy w działaniu, a Quick Migration zapisuje stan maszyny i wznawia ją na innym węźle w ciągu sekund.

SQL Server Always On — bezprzerwowy dostęp do baz danych

Instancje SQL Server w konfiguracji Always On Failover Cluster Instance (FCI) lub Always On Availability Groups zapewniają automatyczne przełączanie awaryjne baz danych. To krytyczne rozwiązanie dla systemów ERP, CRM i aplikacji e-commerce, które wymagają ciągłego dostępu do danych.

Serwer plików Scale-Out (SOFS)

Klaster Scale-Out File Server pozwala na jednoczesny dostęp do udziałów SMB ze wszystkich węzłów klastra. Jest to podstawowa architektura dla środowisk hiperkonwergentnych (HCI) opartych o Storage Spaces Direct.

Usługi sieciowe i aplikacje biznesowe

Failover Clustering obsługuje również role takie jak DHCP, DNS, DFS, IIS oraz niestandardowe aplikacje biznesowe. Każdą usługę, która może być zainstalowana jako rola klastrowa, można zabezpieczyć przed awarią.

Wymagania sprzętowe i sieciowe dla klastra

Prawidłowe zaplanowanie infrastruktury to fundament niezawodnego klastra. Microsoft definiuje precyzyjne wymagania, które muszą zostać spełnione przed wdrożeniem.

Wymagania sprzętowe

• Minimum 2 serwery (węzły) — zalecane 3 lub więcej dla optymalnego kworum
• Identyczne lub bardzo podobne konfiguracje sprzętowe — te same procesory, pamięć RAM, kontrolery sieci i dysków
• Serwery muszą znajdować się na liście zgodności sprzętowej Microsoft (HCL)
• Wspólny magazyn danych: SAN (iSCSI, Fibre Channel) lub Storage Spaces Direct w konfiguracji hiperkonwergentnej
• Minimum 2 karty sieciowe na każdym węźle — jedna dla ruchu klastrowego, druga dla ruchu klienckiego

Wymagania sieciowe

• Dedykowana sieć heartbeat — prywatna sieć do komunikacji między węzłami (sygnały pulsu)
• Sieć publiczna — do obsługi ruchu klienckiego i dostępu do usług
• Statyczne adresy IP dla węzłów klastra i nazwy klastra (Cluster Name Object — CNO)
• Łącza sieciowe o przepustowości minimum 1 Gbps (zalecane 10 Gbps lub wyższe dla Storage Spaces Direct)
• Redundantne przełączniki sieciowe — eliminacja single point of failure

Wymagania dotyczące Active Directory

• Wszystkie węzły muszą być członkami tej samej domeny AD
• Konto komputera klastra (CNO) musi mieć uprawnienia do tworzenia obiektów w kontenerze organizacyjnym
• Alternatywnie — od Windows Server 2025 możliwe jest tworzenie klastrów odłączonych od AD (AD-detached clusters)

Wymagania dotyczące licencjonowania

Każdy węzeł klastra wymaga osobnej licencji Windows Server (Standard lub Datacenter). Dodatkowo, każdy użytkownik lub urządzenie łączące się z klastrem potrzebuje licencji CAL (Client Access License). W przypadku SQL Server na klastrze, potrzebne są również odpowiednie licencje SQL Server CAL.

Krok po kroku: tworzenie klastra Failover Clustering

Poniżej przedstawiamy kompletny przewodnik tworzenia klastra awaryjnego na Windows Server. Proces składa się z kilku etapów — od przygotowania węzłów po walidację i konfigurację ról.

Krok 1: Instalacja funkcji Failover Clustering

Na każdym węźle klastra zainstaluj funkcję Failover Clustering. Możesz to zrobić przez Server Manager lub PowerShell:

# Instalacja funkcji Failover Clustering z narzędziami zarządzania
Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools

# Sprawdzenie, czy funkcja została zainstalowana
Get-WindowsFeature Failover-Clustering

Po instalacji wymagany jest restart serwera.

Krok 2: Walidacja konfiguracji klastra

Przed utworzeniem klastra obowiązkowe jest uruchomienie testu walidacji. Test sprawdza kompatybilność sieci, storage i konfiguracji węzłów:

# Walidacja wszystkich testów na dwóch węzłach
Test-Cluster -Node "NODE1","NODE2" -Include "Storage","Network","Inventory","System Configuration"

# Walidacja z generowaniem raportu HTML
Test-Cluster -Node "NODE1","NODE2" -ReportName "C:\ClusterValidation"

Ważne: Microsoft wymaga pomyślnego przejścia walidacji jako warunku uzyskania wsparcia technicznego. Wszystkie testy muszą zakończyć się statusem Passed lub Warning — wynik Failed wymaga naprawy przed kontynuowaniem.

Krok 3: Utworzenie klastra

# Utworzenie klastra z dwoma węzłami
New-Cluster -Name "CLUSTER01" -Node "NODE1","NODE2" -StaticAddress 192.168.1.100

# Utworzenie klastra z trzema węzłami i dedykowaną siecią
New-Cluster -Name "CLUSTER01" -Node "NODE1","NODE2","NODE3" -StaticAddress 192.168.1.100 -NoStorage

Parametr -NoStorage jest przydatny, gdy chcesz dodać dyski ręcznie po utworzeniu klastra lub gdy używasz Storage Spaces Direct.

Krok 4: Konfiguracja Cluster Shared Volumes (CSV)

Udostępnione woluminy klastra (CSV) umożliwiają wielu węzłom jednoczesny dostęp do tego samego magazynu:

# Dodanie dysku do klastra
Add-ClusterDisk -Cluster "CLUSTER01" -InputObject (Get-Disk -Number 2)

# Konwersja dysku klastra na CSV
Add-ClusterSharedVolume -Name "Cluster Disk 1"

# Wyświetlenie woluminów CSV
Get-ClusterSharedVolume

Woluminy CSV są montowane w katalogu C:\ClusterStorage\ i są dostępne z każdego węzła jednocześnie.

Krok 5: Dodanie roli klastrowej

# Dodanie roli Hyper-V
Add-ClusterRole -Name "HyperV-HA" -StaticAddress 192.168.1.101

# Dodanie roli serwera plików
Add-ClusterFileServerRole -Name "FS-HA" -Storage "Cluster Disk 2" -StaticAddress 192.168.1.102

# Wyświetlenie aktywnych ról klastrowych
Get-ClusterGroup

Tryby kworum — jak klaster podejmuje decyzje?

Kworum to mechanizm głosowania, który zapobiega scenariuszowi split-brain — sytuacji, w której dwie części klastra próbują działać niezależnie, powodując niespójność danych. Klaster pozostaje operacyjny tylko wtedy, gdy posiada większość głosów (quorum).

Tryby kworum w Windows Server

Konfiguracja Cloud Witness (zalecana)

# Ustawienie Cloud Witness z kontem Azure Storage
Set-ClusterQuorum -CloudWitness -AccountName "mystorageaccount" -AccessKey "base64key..."

# Sprawdzenie aktualnej konfiguracji kworum
Get-ClusterQuorum | Format-List *

Cloud Witness jest zalecanym rozwiązaniem od Windows Server 2019, ponieważ eliminuje potrzebę dedykowanego serwera plików i zapewnia niezależność geograficzną.

Cluster-Aware Updating (CAU) — aktualizacje bez przestojów

Cluster-Aware Updating to wbudowana funkcja, która umożliwia automatyczną instalację aktualizacji Windows Update na węzłach klastra bez przerwy w działaniu usług. CAU sekwencyjnie:

1. Przenosi role klastrowe z węzła na inne węzły (drain)
2. Instaluje aktualizacje na opróżnionym węźle
3. Restartuje węzeł (jeśli wymagane)
4. Przywraca role na zaktualizowany węzeł
5. Przechodzi do następnego węzła

Konfiguracja CAU przez PowerShell

# Włączenie auto-aktualizacji klastra (self-updating mode)
Add-CauClusterRole -ClusterName "CLUSTER01" -DaysOfWeek Saturday -WeeksOfMonth 2 -MaxRetriesPerNode 3

# Ręczne uruchomienie aktualizacji
Invoke-CauRun -ClusterName "CLUSTER01" -Force

# Sprawdzenie statusu aktualizacji
Get-CauRun -ClusterName "CLUSTER01"

SQL Server Always On z Failover Clustering

Integracja SQL Server z Failover Clustering to jedno z najpopularniejszych zastosowań klastrów w środowiskach enterprise. Microsoft oferuje dwa podejścia:

Always On Failover Cluster Instance (FCI)

FCI to tradycyjne podejście, w którym instancja SQL Server jest zainstalowana jako rola klastrowa. Wszystkie węzły współdzielą jeden magazyn danych (SAN). W przypadku awarii aktywnego węzła, pasywny węzeł przejmuje instancję SQL Server wraz z bazami danych.

• Zalety: prosta konfiguracja, automatyczny failover, ochrona na poziomie instancji
• Wady: wymaga wspólnego magazynu (SAN), brak równoważenia obciążenia odczytu

Always On Availability Groups (AG)

Availability Groups to nowocześniejsze rozwiązanie, które umożliwia replikację baz danych na wielu węzłach z niezależnym magazynem. Obsługuje:

• Automatyczny failover — przełączanie na replikę synchroniczną
• Odczyt z replik wtórnych — odciążenie serwera głównego
• Replikacja asynchroniczna — dla klastrów rozproszonych geograficznie (disaster recovery)

Konfiguracja AG wymaga bazowego klastra Failover Clustering, nawet jeśli sam SQL Server nie jest instalowany jako FCI.

Wymagania licencyjne SQL Server na klastrze

Każdy węzeł klastra, na którym może być uruchomiona instancja SQL Server, wymaga pełnej licencji. W modelu Server + CAL potrzebne są również licencje dostępowe SQL Server CAL dla każdego użytkownika lub urządzenia. Szczegółowe porównanie wersji znajdziesz w artykule: SQL Server 2019 vs 2022 — porównanie i przewodnik migracji.

Monitorowanie i diagnostyka klastra

Skuteczne monitorowanie klastra jest kluczowe dla zapobiegania awariom i szybkiego reagowania na problemy. Windows Server oferuje wbudowane narzędzia, które pozwalają na proaktywne śledzenie stanu klastra.

Failover Cluster Manager (GUI)

Graficzne narzędzie do zarządzania klastrem, które pozwala na:

• Podgląd stanu węzłów, ról i dysków w czasie rzeczywistym
• Ręczne przenoszenie ról między węzłami
• Przeglądanie dziennika zdarzeń klastra
• Uruchamianie walidacji i diagnostyki

PowerShell — zaawansowana diagnostyka

# Sprawdzenie stanu wszystkich węzłów
Get-ClusterNode | Format-Table Name, State, StatusInformation

# Sprawdzenie stanu ról klastrowych
Get-ClusterGroup | Format-Table Name, State, OwnerNode

# Wyświetlenie ostatnich zdarzeń klastra
Get-ClusterLog -Destination "C:\Logs" -TimeSpan 60

# Sprawdzenie stanu sieci klastrowej
Get-ClusterNetwork | Format-Table Name, State, Role

# Test łączności między węzłami
Test-NetConnection -ComputerName "NODE2" -Port 3343

Health Service (od Windows Server 2016)

Usługa Health Service automatycznie monitoruje klaster i generuje alerty o potencjalnych problemach — zanim doprowadzą do awarii. Można ją odpytywać przez PowerShell:

# Wyświetlenie aktywnych alertów zdrowotnych
Get-HealthFault

# Sprawdzenie metryki wydajności klastra
Get-StorageSubSystem -FriendlyName "Clustered*" | Get-HealthReport

Rozwiązywanie typowych problemów

Nawet prawidłowo skonfigurowany klaster może napotkać problemy. Poniżej znajdziesz najczęstsze scenariusze i sposoby ich rozwiązania.

Problem: Węzeł nie dołącza do klastra

Przyczyna: Najczęściej problemy z DNS, firewallem lub niekompatybilne aktualizacje systemu.

# Sprawdzenie łączności klastrowej
Test-Cluster -Node "NODE1","NODE2" -Include "Network"

# Sprawdzenie portów wymaganych przez klaster (TCP 3343, UDP 3343)
Test-NetConnection -ComputerName "NODE2" -Port 3343

# Restart usługi klastra
Restart-Service -Name ClusSvc

Problem: Częste, nieoczekiwane failovery

Przyczyna: Zbyt agresywne progi heartbeat lub problemy z siecią prywatną.

# Sprawdzenie i dostosowanie progów heartbeat
(Get-Cluster).SameSubnetDelay = 1000        # ms między heartbeatami
(Get-Cluster).SameSubnetThreshold = 10      # liczba utraconych heartbeatów
(Get-Cluster).CrossSubnetDelay = 2000       # ms dla cross-subnet
(Get-Cluster).CrossSubnetThreshold = 20     # próg dla cross-subnet

Problem: Event ID 1069 — zasób klastrowy nie może się uruchomić

Przyczyna: Brak dostępu do wspólnego magazynu lub problem z zależnościami roli.

# Sprawdzenie stanu dysków klastrowych
Get-ClusterResource | Where-Object {$_.ResourceType -eq "Physical Disk"} | Format-Table Name, State, OwnerGroup

# Wymuszenie przejęcia dysku online
Resume-ClusterResource -Name "Cluster Disk 1"

# Sprawdzenie zdarzeń klastra
Get-WinEvent -LogName "Microsoft-Windows-FailoverClustering/Operational" -MaxEvents 20 | Format-Table TimeCreated, Message -Wrap

Problem: Utrata kworum

Jeśli klaster stracił kworum i żadna usługa nie działa:

# Wymuszone uruchomienie klastra bez kworum (tryb awaryjny)
Start-ClusterNode -Name "NODE1" -FixQuorum

# Przywrócenie normalnego kworum po naprawie
Set-ClusterQuorum -NodeMajority

Uwaga: Tryb -FixQuorum powinien być używany wyłącznie jako rozwiązanie tymczasowe. Po naprawieniu problemu należy jak najszybciej przywrócić normalną konfigurację kworum.

Najlepsze praktyki i rekomendacje

• Regularnie uruchamiaj walidację klastra — nie tylko przy tworzeniu, ale też po każdej zmianie konfiguracji
• Używaj Cloud Witness zamiast File Share Witness — prostsze zarządzanie, lepsza odporność
• Separuj sieci — dedykowana sieć heartbeat, oddzielna sieć do Live Migration, oddzielna sieć kliencka
• Włącz Cluster-Aware Updating — automatyczne aktualizacje bez przestojów
• Monitoruj Health Service — reaguj na alerty zanim staną się awariami
• Dokumentuj konfigurację — zapisuj adresy IP, konfigurację kworum, przypisania ról
• Testuj failover regularnie — symuluj awarie co najmniej raz na kwartał
• Utrzymuj identyczne wersje oprogramowania na wszystkich węzłach — OS, sterowniki, firmware

Porównanie edycji Windows Server dla klastrów

Dla środowisk z wieloma maszynami wirtualnymi i wymaganiami na Storage Spaces Direct, edycja Datacenter jest jednoznacznym wyborem. Dla prostszych klastrów z zewnętrznym magazynem SAN, edycja Standard jest wystarczająca i bardziej ekonomiczna.

Szczegółowe porównanie wszystkich edycji znajdziesz w artykule: Porównanie edycji Windows Server 2022: Standard vs Datacenter vs Essentials.

Często zadawane pytania (FAQ)

Ile węzłów może mieć klaster Failover Clustering?

Windows Server obsługuje klastry o maksymalnie 64 węzłach. W praktyce większość wdrożeń korporacyjnych wykorzystuje 2–4 węzły. Większe klastry (8–16 węzłów) są typowe dla środowisk hiperkonwergentnych z Storage Spaces Direct.

Czy do Failover Clustering potrzebna jest domena Active Directory?

Tradycyjnie — tak, wszystkie węzły muszą należeć do tej samej domeny AD. Jednak od Windows Server 2025 możliwe jest tworzenie klastrów odłączonych od Active Directory (AD-detached), co upraszcza wdrożenia w środowiskach DMZ i edge computing.

Jaka jest różnica między Failover Clustering a Network Load Balancing (NLB)?

Failover Clustering zapewnia wysoką dostępność — jeśli jeden serwer padnie, drugi przejmuje jego rolę. NLB równoważy obciążenie między wieloma serwerami — wszystkie serwery obsługują żądania jednocześnie. Są to komplementarne technologie, nie zamienniki.

Ile kosztuje licencja Windows Server do klastra?

Każdy węzeł klastra wymaga osobnej licencji Windows Server. Licencje w modelu core-based (minimum 16 rdzeni) plus licencje CAL dla użytkowników/urządzeń. Sprawdź aktualne ceny w naszym sklepie z licencjami Windows Server.

Czy mogę mieszać wersje Windows Server w jednym klastrze?

Tak, ale tylko tymczasowo — podczas procesu Cluster OS Rolling Upgrade. Ta funkcja pozwala na stopniowe uaktualnianie węzłów (np. z Windows Server 2019 do 2022) bez przerwy w działaniu klastra. Docelowo wszystkie węzły muszą pracować na tej samej wersji.

Czy Failover Clustering działa z VMware lub inną wirtualizacją?

Failover Clustering jest natywną funkcją Windows Server i działa zarówno na serwerach fizycznych, jak i wirtualnych. Może działać wewnątrz maszyn wirtualnych VMware ESXi, Hyper-V lub KVM, jednak Microsoft oficjalnie wspiera tylko konfiguracje na fizycznym sprzęcie lub Hyper-V. Klastry wewnątrz VM VMware wymagają dodatkowej konfiguracji.