Hyper-V — pierwszy klaster Failover na 2 serwerach (HowTo 2026)

Hyper-V Failover Cluster na 2 serwerach: praktyczny scenariusz dla polskiej MŚP

Firma zatrudniająca 25-50 osób często zaczyna od jednego serwera z kontrolerem domeny, systemem ERP, plikami i kilkoma maszynami wirtualnymi. Po kilku latach taki host staje się pojedynczym punktem awarii: aktualizacja firmware, uszkodzenie płyty głównej albo awaria macierzy oznacza przestój całej organizacji. Rozsądnym następnym krokiem jest hyper-v failover cluster na dwóch węzłach z Windows Server 2025 lub Windows Server 2022, wspólną przestrzenią dyskową i wydzieloną siecią Live Migration.

Ten poradnik pokazuje konfigurację pierwszego klastra Hyper-V dla MŚP: od wymagań sprzętowych, przez role systemowe i Cluster Shared Volumes, po testy awarii. Cel jest prosty: gdy jeden serwer przestanie działać, maszyny wirtualne uruchomią się na drugim węźle; przy planowanych pracach można je przenieść bez wyłączania dzięki live migration hyper-v. Microsoft opisuje klaster jako mechanizm wysokiej dostępności dla ról takich jak Hyper-V i SQL Server w dokumentacji Failover Clustering overview.

Co zwykle pomijają krótsze poradniki o klastrowaniu Hyper-V

Analiza wyników wyszukiwania dla fraz „hyper-v failover cluster”, „hyper-v 2 serwery” i „windows server cluster” pokazuje, że wiele artykułów kończy się na kreatorze „Create Cluster”. W realnym wdrożeniu dla MŚP krytyczne są jednak elementy, które decydują o stabilności po miesiącach pracy:

• walidacja sprzętu i sterowników przed produkcją, nie dopiero po pierwszej awarii;
• osobna decyzja o witness: udział plikowy, Cloud Witness w Azure albo dysk witness;
• wydzielona sieć dla Live Migration, CSV i ruchu maszyn wirtualnych;
• licencjonowanie każdej fizycznej maszyny tak, jakby mogła przejąć wszystkie VM;
• testy: planowany Live Migration, drain node, symulowana awaria węzła i odtworzenie backupu.

Wymagania sprzętowe dla klastra Hyper-V na 2 węzłach

Najbezpieczniejszy wariant dla pierwszego klastra to dwa możliwie podobne serwery rack lub tower tej samej generacji, z procesorami z tej samej rodziny. Nie muszą mieć identycznych taktowań, ale mieszanie AMD i Intel albo bardzo różnych generacji CPU utrudnia Live Migration i ogranicza przewidywalność. Microsoft w wymaganiach klastra podkreśla zgodność sprzętu, sterowników, firmware i pamięci masowej z używaną wersją Windows Server oraz wymagania Hyper-V: procesor 64-bitowy, sprzętową wirtualizację i DEP/NX/XD w dokumentacji wymagań Failover Clustering.

Wspólna pamięć masowa jest sercem tej konfiguracji. Dla pierwszego wdrożenia w MŚP najczęściej wybierane są SAS shared storage albo iSCSI SAN. Storage Spaces Direct również jest możliwe, ale wymaga innego projektu, edycji Datacenter i większej dyscypliny sprzętowej. W tym HowTo zakładamy klasyczny model: dwa hosty Hyper-V widzą te same LUN-y, a VM-y leżą na CSV.

Licencjonowanie: Standard czy Datacenter?

Licencje dobieramy do fizycznych hostów, nie do liczby aktualnie uruchomionych maszyn na danym serwerze. W klastrze każdy z dwóch hostów musi być licencjonowany tak, aby legalnie uruchomić obciążenia po awarii drugiego węzła. Dla małej liczby maszyn wystarczy Windows Server Standard, ale przy większej liczbie VM szybciej opłaca się Windows Server 2025 Datacenter, bo daje prawa do nieograniczonej liczby maszyn wirtualnych Windows Server na licencjonowanym hoście. Według aktualnego cennika KluczeSoft z kwietnia 2026 orientacyjne ceny 16-core to około 3490 zł dla Server 2025 Standard i 5990 zł dla Server 2025 Datacenter; ceny rynkowe różnią się w zależności od kanału, typu licencji i CAL.

W praktyce dla firmy 25-50 użytkowników warto policzyć dwa warianty: Standard stackowany na oba hosty oraz Datacenter na oba hosty. Jeżeli środowisko ma rosnąć, Datacenter zwykle upraszcza audyt i utrzymanie. Usługi użytkowników, poczta, SharePoint/Teams i kopie dokumentów poza serwerownią warto równolegle ocenić w modelu Microsoft 365 dla MŚP.

Plan adresacji i nazw w przykładzie

W przykładzie użyjemy dwóch hostów: HV01 i HV02, klastra CL-HV01, adresu klastra 192.168.10.50 oraz udziału witness \\FS01\Witness-CL-HV01. Sieci rozdzielamy logicznie: Management 192.168.10.0/24, Live Migration 192.168.20.0/24, iSCSI 192.168.30.0/24, VM Network według projektu LAN. Nazwy kart powinny być identyczne na obu hostach, np. Mgmt, LM, iSCSI-A, iSCSI-B.

HowTo: pierwszy klaster Hyper-V Failover na 2 serwerach

1. Zaktualizuj firmware, sterowniki i Windows Server

   Przed instalacją ról ujednolić BIOS/UEFI, firmware kontrolerów RAID/HBA, karty sieciowe oraz sterowniki producenta. Włącz Intel VT-x/AMD-V, SR-IOV jeśli używasz, DEP/NX/XD oraz właściwy profil zasilania. Dołącz oba hosty do domeny Active Directory, skonfiguruj statyczne adresy IP i upewnij się, że czas systemowy jest spójny.

2. Zainstaluj role Hyper-V i Failover Clustering

   Na obu hostach uruchom PowerShell jako administrator:

   Install-WindowsFeature Hyper-V, Failover-Clustering, RSAT-Clustering-PowerShell, Multipath-IO -IncludeManagementTools -Restart

   Po restarcie włącz MPIO dla iSCSI, jeżeli korzystasz z macierzy iSCSI:

   Enable-MSDSMAutomaticClaim -BusType iSCSI
   Restart-Computer

3. Skonfiguruj storage i Cluster Shared Volumes

   Na macierzy utwórz co najmniej jeden LUN na maszyny wirtualne, np. CSV01, oraz opcjonalny mały LUN witness, jeżeli nie używasz Cloud Witness lub File Share Witness. LUN-y muszą być widoczne dla obu hostów i nie mogą być inicjowane niezależnie na każdym serwerze. Na jednym hoście zainicjuj dysk jako GPT, utwórz wolumin NTFS lub ReFS, a następnie pozostaw go gotowego do dodania do klastra. Microsoft opisuje CSV jako woluminy, do których wiele węzłów klastra ma równoczesny dostęp i które są typowym miejscem przechowywania plików VM Hyper-V w dokumentacji Cluster Shared Volumes.

   Get-Disk
   Initialize-Disk -Number 5 -PartitionStyle GPT
   New-Partition -DiskNumber 5 -UseMaximumSize -AssignDriveLetter | Format-Volume -FileSystem ReFS -NewFileSystemLabel CSV01

4. Przygotuj sieć i Live Migration

   Dla prostego klastra użyj Switch Embedded Teaming dla ruchu VM i management, a iSCSI zostaw na osobnych kartach fizycznych bez vSwitch, jeśli wymaga tego macierz. Przykład dla dwóch kart 10 GbE przeznaczonych na VM/management:

   New-VMSwitch -Name "vSwitch-VM" -NetAdapterName "NIC1","NIC2" -EnableEmbeddedTeaming $true -AllowManagementOS $true
   Rename-VMNetworkAdapter -ManagementOS -Name "vSwitch-VM" -NewName "Mgmt-vNIC"
   New-VMNetworkAdapter -ManagementOS -Name "LiveMigration" -SwitchName "vSwitch-VM"
   New-NetIPAddress -InterfaceAlias "vEthernet (LiveMigration)" -IPAddress 192.168.20.11 -PrefixLength 24

   Na drugim hoście użyj odpowiednio adresu 192.168.20.12. Microsoft zaleca rozdzielanie ruchu klastra, CSV, Live Migration i maszyn wirtualnych oraz świadome ustawienie sieci dla migracji w rekomendacjach sieci Hyper-V cluster.

5. Uruchom Cluster Validation Wizard

   Walidacja jest obowiązkowa przed produkcją. Test wykryje problemy z dyskami, MPIO, sterownikami, siecią i zgodnością konfiguracji. Uruchom:

   Test-Cluster -Node HV01,HV02 -Include "Storage","Inventory","Network","System Configuration"

   Raport HTML zapisz do dokumentacji wdrożenia. Ostrzeżenia trzeba zrozumieć, a błędy usunąć przed utworzeniem klastra. To jeden z punktów, które najczęściej odróżniają stabilne klastrowanie Hyper-V od instalacji „klikanej” bez kontroli jakości.

6. Utwórz klaster Windows Server

   Po poprawnej walidacji utwórz klaster z adresem administracyjnym:

   New-Cluster -Name CL-HV01 -Node HV01,HV02 -StaticAddress 192.168.10.50 -NoStorage
   Get-ClusterNode

   Następnie dodaj dostępne dyski i przekształć wolumin VM w CSV:

   Get-ClusterAvailableDisk | Add-ClusterDisk
   Get-ClusterResource
   Add-ClusterSharedVolume -Name "Cluster Disk 1"

   Po dodaniu CSV ścieżka będzie zwykle wyglądać jak C:\ClusterStorage\Volume1. Tam twórz katalogi maszyn wirtualnych, np. C:\ClusterStorage\Volume1\VMs.

7. Skonfiguruj witness dla quorum

   W klastrze dwu-węzłowym witness nie jest dodatkiem, lecz elementem decydującym o quorum. Najprostszy jest File Share Witness na trzecim serwerze, NAS lub kontrolerze domeny, jeśli polityka bezpieczeństwa na to pozwala. Alternatywą jest Cloud Witness w Azure, który wymaga konta Storage, ale nie wymaga trzeciego serwera w lokalnej serwerowni. Microsoft opisuje File Share Witness, Cloud Witness i Disk Witness w dokumentacji quorum witness.

   Set-ClusterQuorum -FileShareWitness "\\FS01\Witness-CL-HV01"

   Dla Cloud Witness użyj:

   Set-ClusterQuorum -CloudWitness -AccountName "nazwaStorageAccount" -AccessKey "kluczDostepu"

8. Ustaw preferencje Live Migration

   W Failover Cluster Manager przejdź do Networks i upewnij się, że sieć Live Migration ma właściwą metrykę oraz jest używana do migracji. PowerShell:

   Get-ClusterNetwork | Sort-Object Metric | Format-Table Name,Address,Metric,Role
   Set-VMHost -VirtualMachineMigrationEnabled $true -VirtualMachineMigrationAuthenticationType Kerberos -VirtualMachineMigrationPerformanceOption SMB

   Jeżeli hosty działają w domenie, skonfiguruj constrained delegation dla usługi CIFS i Microsoft Virtual System Migration Service. W Windows Server 2025 poprawiono logikę wyboru sieci Live Migration, ale nadal warto jawnie przetestować, którędy idzie ruch.

9. Utwórz lub przenieś maszyny wirtualne do klastra

   Nową VM zapisuj od razu na CSV:

   New-VM -Name "ERP01" -Generation 2 -MemoryStartupBytes 8GB -Path "C:\ClusterStorage\Volume1\VMs" -NewVHDPath "C:\ClusterStorage\Volume1\VMs\ERP01\ERP01.vhdx" -NewVHDSizeBytes 200GB -SwitchName "vSwitch-VM"
   Add-ClusterVirtualMachineRole -VMName "ERP01"

   Istniejące VM przenieś na CSV przy użyciu Storage Migration w Hyper-V Manager lub PowerShell, a następnie dodaj jako rolę klastra. Dla kontrolerów domeny zaleca się co najmniej dwa DC, najlepiej rozłożone tak, aby awaria jednego hosta nie odcinała administracji domeną.

10. Przetestuj Live Migration i failover

    Najpierw test planowany:

    Move-ClusterVirtualMachineRole -Name "ERP01" -Node HV02
    Get-ClusterGroup

    Następnie wykonaj drain jednego węzła przed aktualizacją:

    Suspend-ClusterNode -Name HV01 -Drain
    Resume-ClusterNode -Name HV01

    Na końcu zaplanuj kontrolowany test awarii poza godzinami pracy: odłącz host od sieci klastra lub wyłącz go z poziomu kontrolera zarządzania. Sprawdź, które VM zostały zrestartowane, ile trwał powrót usług i czy monitoring zgłosił incydent. Failover cluster nie jest tym samym co fault tolerance: przy nagłej awarii hosta VM zwykle uruchamiają się ponownie na drugim węźle, a nie działają bez żadnej przerwy.

Bezpieczeństwo i ciągłość działania

Klaster nie zastępuje backupu, procedur odtworzeniowych ani dokumentacji BCP. Chroni głównie przed awarią hosta i ułatwia prace serwisowe. Nie ochroni przed skasowaniem danych w VM, ransomware szyfrującym udziały, błędną aktualizacją aplikacji ani awarią wspólnej macierzy. Dlatego plan powinien obejmować kopie poza klastrem, odseparowane konto backupowe, testy restore oraz monitoring. ENISA w materiałach dla MŚP wskazuje ocenę ryzyka, ciągłość działania i cyberhigienę jako kluczowe obszary ochrony małych firm w zasobach SME Cybersecurity. Z kolei ISO 22301 porządkuje podejście do systemu zarządzania ciągłością działania jako standard business continuity.

Lista kontrolna przed produkcyjnym uruchomieniem

• Oba hosty mają identyczne wersje BIOS, firmware i sterowników kart sieciowych/HBA.
• Test-Cluster kończy się bez błędów, a ostrzeżenia są opisane w dokumentacji.
• CSV działa na redundantnym storage, z poprawnym MPIO i monitoringiem macierzy.
• Witness jest poza dwoma hostami klastra i był testowany.
• Live Migration działa w obie strony, po właściwej sieci.
• Każdy host ma licencję wystarczającą do przejęcia obciążeń po awarii.
• Backup VM jest wykonywany narzędziem świadomym Hyper-V i klastra.
• Administrator ma procedurę aktualizacji: drain node, patch, restart, resume, drugi węzeł.