Storage Spaces Direct (S2D) — tanie macierze dyskowe na Windows Server [Poradnik 2026]
Tradycyjna macierz SAN kosztuje 50–200 tys. zł. Storage Spaces Direct daje porównywalną wydajność za ułamek tej ceny — korzystając ze zwykłych serwerów x86 i dysków, które prawdopodobnie masz już w szafie serwerowej lub możesz kupić u dowolnego dystrybutora. S2D to nie kompromis — to architektura, którą Microsoft stosuje we własnych centrach danych Azure. W tym poradniku wyjaśniamy, czym jest S2D, kiedy warto je wdrożyć, jak skonfigurować klaster krok po kroku i kiedy ta technologia nie jest właściwym wyborem.
Czym jest Storage Spaces Direct i jak działa?
Storage Spaces Direct (S2D) to technologia software-defined storage wbudowana w Windows Server Datacenter, wprowadzona w wersji 2016 i systematycznie rozwijana w edycjach 2019, 2022 i 2025. Jej zasada działania jest prosta: zamiast kupować dedykowaną macierz dyskową z własnym kontrolerem, oprogramowaniem i kablem FC/iSCSI, używasz lokalnych dysków zainstalowanych bezpośrednio w węzłach klastra. Windows łączy te dyski w jedną logiczną pulę pamięci masowej, replikuje dane między węzłami przez sieć Ethernet i prezentuje woluminy jako Cluster Shared Volumes (CSV) dostępne dla wszystkich hostów jednocześnie.
S2D opiera się na kilku warstwach technologicznych współpracujących ze sobą:
- Storage Bus Layer (SBL) — niskopoziomowa warstwa abstrakcji dysków, która widzi napędy ze wszystkich węzłów jako jeden zasób
- Storage pool — pula grupująca wszystkie fizyczne dyski w jedną całość zarządzaną przez Windows
- Storage spaces — wirtualne dyski (virtual disks) z wybranym typem odporności (mirror, parity)
- ReFS/NTFS + CSV — woluminy dostępne jednocześnie ze wszystkich węzłów klastra
- Failover Clustering — zapewnia wysoką dostępność maszyn wirtualnych i automatyczne przełączanie awaryjne
Kluczowa różnica względem starszej technologii Storage Spaces (z Windows Server 2012): S2D nie wymaga współdzielonego storage'u — każdy węzeł ma własne dyski podłączone lokalnie. Replikacja odbywa się przez sieć, a nie przez wspólną szynę SAS. To właśnie eliminuje konieczność zakupu drogich macierzy zewnętrznych.
W Windows Server 2025 technologia S2D zyskała dodatkowe możliwości: obsługę klastrów bez domeny Active Directory (workgroup clusters), konfigurację Campus Cluster dla odporności na awarie całej szafy serwerowej, ulepszone thin provisioning oraz przyspieszoną resynchronizację dysków po awarii.
S2D kontra tradycyjna macierz SAN — realne porównanie kosztów
Argumentem, który przekonuje większość administratorów IT, jest rachunek ekonomiczny. Porównajmy realne koszty obu podejść dla typowego środowiska wirtualizacji z pojemnością 50 TB użytkową i redundancją 2-węzłową:
| Element | Tradycyjna macierz SAN | S2D na serwerach commodity |
|---|
| Sprzęt storage | 40 000–150 000 zł (SAN mid-range) | 0 zł (dyski wewnątrz serwerów) |
| Serwery (2 węzły) | 30 000–60 000 zł (bez storage) | 30 000–60 000 zł (z dyskami NVMe/SSD) |
| Przełączniki FC/iSCSI | 10 000–40 000 zł | 0–15 000 zł (przełączniki 10/25 GbE) |
| Licencje Windows Server Datacenter | wymagane (osobno) | wymagane — zawarte w całości rozwiązania |
| Wsparcie i kontrakty SLA | 5 000–20 000 zł/rok | koszt wsparcia serwera (opcjonalnie) |
| Skalowalność | ograniczona do modelu macierzy | liniowa — dodaj węzeł, dodaj pojemność i IOPS |
| Szacunkowy koszt całkowity (TCO 3 lata) | 120 000–350 000 zł | 40 000–90 000 zł |
Oszczędność rzędu 60–75% TCO to argument trudny do odrzucenia. Co ważne, S2D nie jest rozwiązaniem gorszej jakości — Microsoft używa tej samej technologii w Azure Stack HCI, a wielu dostawców chmury buduje na niej infrastrukturę dla setek klientów jednocześnie.
Istnieje jednak jeden istotny koszt, o którym warto pamiętać: S2D wymaga licencji Windows Server Datacenter na każdym węźle klastra. Edycja Standard nie jest wspierana. W zamian licencja Datacenter daje nieograniczoną liczbę maszyn wirtualnych Windows Server na danym hoście — co przy gęstej wirtualizacji i tak się opłaca.
Wymagania sprzętowe dla Storage Spaces Direct
Jednym z największych atutów S2D jest możliwość uruchomienia go na standardowym sprzęcie klasy serwerowej. Nie potrzebujesz certyfikowanego zestawu od jednego producenta — chociaż Microsoft zaleca wybór sprzętu z certyfikatem SDDC (Software-Defined Data Center), który gwarantuje zweryfikowaną kompatybilność.
Minimalne wymagania węzła
- CPU: Intel Nehalem lub nowszy albo AMD EPYC lub nowszy (64-bit, obsługa SLAT/EPT)
- RAM: pamięć dla systemu operacyjnego + maszyn wirtualnych + 4 GB RAM na każdy TB pojemności dysków cache na serwerze (dla metadanych S2D)
- Dysk rozruchowy: dedykowany napęd rozruchowy, minimum 200 GB (najlepiej M.2 lub SATADOM — nie wliczany do puli S2D)
- System operacyjny: Windows Server 2016/2019/2022/2025 Datacenter
Wymagania dyskowe
S2D działa wyłącznie z dyskami podłączonymi bezpośrednio do serwera (direct-attached): SATA, SAS, NVMe lub pamięć trwała (PMem). Nie jest obsługiwany shared SAS ani żadna forma MPIO. Kontroler RAID należy skonfigurować w trybie HBA pass-through — S2D samodzielnie zarządza logiką dyskową.
| Konfiguracja dysków | Minimum dysków (Windows Server) | Rola |
|---|
| Wyłącznie NVMe (all-flash) | 4 NVMe na węzeł | Pojemność (bez cache) |
| Wyłącznie SSD (all-flash) | 4 SSD na węzeł | Pojemność (bez cache) |
| NVMe (cache) + SSD/HDD | 2 NVMe + 4 SSD/HDD na węzeł | NVMe jako cache, reszta jako pojemność |
| SSD (cache) + HDD | 2 SSD + 4 HDD na węzeł | SSD jako cache, HDD jako pojemność |
| PMem + NVMe/SSD | 2 PMem + 4 NVMe/SSD na węzeł | PMem jako cache (najwyższa wydajność) |
Ważna praktyczna uwaga: dyski SSD używane jako cache powinny mieć wytrzymałość minimum 3 DWPD (drive-writes-per-day) lub 4 TBW/dzień. Dyski konsumenckie, nawet markowe, nie spełniają tego wymogu i grożą przedwczesną awarią w roli cache pod dużym obciążeniem zapisu.
Wymagania sieciowe
Sieć jest krytyczna dla wydajności i dostępności S2D. Ruch replikacyjny między węzłami musi mieć niskie opóźnienia i wysoką przepustowość:
- Minimum dla 2–3 węzłów: 10 GbE, co najmniej dwa połączenia z każdego węzła
- Zalecane dla 4+ węzłów lub wysokiej wydajności: 25 GbE z kartami RDMA (iWARP lub RoCE v2)
- RDMA (Remote Direct Memory Access) pozwala na przesyłanie danych z pominięciem CPU, redukując opóźnienia do poziomu kilkuset mikrosekund i odciążając procesory węzłów
- Ruch zarządzający, storage i migracja VM powinny być separowane w osobnych sieciach/VLAN-ach
Topologie wdrożenia: od 2 węzłów do skalowalnego klastra
S2D obsługuje kilka topologii wdrożenia, dostosowanych do różnych rozmiarów infrastruktury i wymagań dotyczących tolerancji awarii.
Klaster 2-węzłowy (Hyper-Converged, small business)
Najprostsza konfiguracja, idealna dla małych firm i oddziałów. Oba węzły pełnią rolę obliczeniową (Hyper-V) i storage jednocześnie. Wymaga świadka kworum (Cloud Witness w Azure lub File Share Witness na trzecim urządzeniu). Przy 2 węzłach S2D stosuje nested resiliency — zagnieżdżone lustro lub lustro z przyspieszonym parity — zapewniając przetrwanie awarii serwera i dysku jednocześnie.
- Nested two-way mirror: ok. 25% efektywności pojemności
- Nested mirror-accelerated parity: ok. 35–40% efektywności pojemności
Klaster 3-węzłowy
Trzy węzły umożliwiają zastosowanie klasycznego three-way mirror (trójkierunkowego lustrzanego odbicia). Każdy blok danych istnieje w trzech kopiach na trzech różnych węzłach. Klaster toleruje awarię jednego pełnego węzła bez przerwy w działaniu. Efektywność pojemności wynosi ok. 33%.
Klaster 4+ węzłowy (recommended production)
Cztery lub więcej węzłów to zalecana konfiguracja produkcyjna. Pozwala na jednoczesną awarię serwera i dysku bez ryzyka dla danych. Wydajność rośnie liniowo wraz z dodawaniem węzłów. Maksymalnie 16 węzłów w klastrze S2D. Pojemność puli może sięgać 4 PB (Windows Server 2019+), a surowa pojemność na węzeł — 400 TB.
Campus Cluster (nowość Windows Server 2025)
Nowa topologia dostępna od aktualizacji KB5072033 dla Windows Server 2025. Umożliwia rozmieszczenie węzłów w dwóch różnych szafach serwerowych lub budynkach w obrębie kampusu, zapewniając odporność na awarię całej szafy lub lokalizacji. Idealne rozwiązanie dla organizacji z dwoma serwerowniami w odległości do kilku kilometrów.
ReFS vs NTFS dla Storage Spaces Direct — którą wybrać?
To pytanie pojawia się przy każdym wdrożeniu S2D. Odpowiedź jest jednoznaczna: dla woluminów S2D przeznaczonych pod Hyper-V lub Scale-Out File Server, ReFS jest właściwym wyborem.
ReFS (Resilient File System) to nowoczesny system plików Microsoftu, zoptymalizowany specjalnie do pracy z Storage Spaces Direct. Oferuje funkcje niedostępne w NTFS:
- Mirror-Accelerated Parity (MAP): hybrydowy typ odporności łączący szybkość lustrzanego odbicia z oszczędnością miejsca parity — dostępny wyłącznie z ReFS na S2D
- Block clone: błyskawiczne klonowanie bloków danych bez kopiowania fizycznego — przyspiesza tworzenie punktów kontrolnych VM i klonowanie dysków wirtualnych nawet 10-krotnie
- Sparse VDL (Valid Data Length): natychmiastowe alokowanie dużych plików VHD/VHDX bez konieczności zerowania bloków — tworzenie dysku 1 TB trwa sekundy zamiast minut
- Integrity streams: automatyczna weryfikacja sum kontrolnych i naprawa uszkodzeń online dzięki redundantnym kopiom w puli S2D
Kiedy wybrać NTFS? Wyłącznie gdy wdrażasz starsze aplikacje, które mają certyfikację tylko na NTFS, albo gdy korzystasz z funkcji systemu plików niedostępnych w ReFS (np. skompresowane woluminy, szyfrowanie EFS, dyski twarde linki w stylu NTFS hard links dla niektórych workloadów). W praktyce produkcyjnej pod Hyper-V nie ma uzasadnionego powodu, by sięgać po NTFS w nowym wdrożeniu S2D.
Modele odporności na awarie — Mirror, Parity i Mirror-Accelerated Parity
S2D oferuje trzy modele odporności danych, każdy z innym kompromisem między wydajnością, pojemnością i odpornością na awarie:
Two-way mirror (lustro dwukierunkowe)
Każdy blok danych przechowywany jest w dwóch kopiach na dwóch różnych węzłach/dyskach. Toleruje awarię jednego węzła lub jednego dysku. Efektywność pojemności: 50%. Najlepsza wydajność losowych operacji I/O — rekomendowany typ dla intensywnych workloadów transakcyjnych i baz danych. Wymaga minimum 2 węzłów.
Three-way mirror (lustro trójkierunkowe)
Trzy kopie danych na trzech różnych węzłach. Toleruje jednoczesną awarię dwóch węzłów lub kombinację awarii serwera i dysku. Efektywność pojemności: 33%. Najwyższa dostępność — rekomendowany typ dla środowisk krytycznych. Wymaga minimum 3 węzłów, zalecane 4+.
Parity (parzystość)
Analogia do RAID 5/6 w świecie software-defined. Dane + informacja parzystości rozkładane są na wielu węzłach. Efektywność pojemności: 50–80% w zależności od liczby węzłów. Niższa wydajność zapisu niż mirror — rekomendowany głównie dla archiwów, backupów i danych rzadko modyfikowanych. Wymaga minimum 3 węzłów.
Mirror-Accelerated Parity (MAP) — tylko ReFS + S2D
Hybrydowy typ dostępny wyłącznie z ReFS na S2D. Nowe zapisy trafiają najpierw do szybkiej warstwy lustrzanej, skąd są asynchronicznie spłaszczane do tańszej warstwy parity. Łączy wysoką wydajność zapisu z oszczędnością pojemności. Efektywność: 35–55%. Rekomendowany dla archiwów i workloadów z umiarkowanym zapisem i dużym odczytem sekwencyjnym.
| Typ odporności | Efektywność pojemności | Wydajność zapisu | Min. węzłów | Zastosowanie |
|---|
| Two-way mirror | 50% | Bardzo wysoka | 2 | Bazy danych, VM intensywne I/O |
| Three-way mirror | 33% | Bardzo wysoka | 3 (zal. 4+) | Środowiska krytyczne, SQL, Exchange |
| Parity | 50–80% | Niska–średnia | 3 | Archiwa, backup, dane cold |
| Mirror-Acc. Parity (MAP) | 35–55% | Wysoka (burst) | 4 (zal.) | Archiwum z burst zapisu, file server |
| Nested mirror (2 węzły) | ~25% | Wysoka | 2 | Małe wdrożenia, branch office |
Konfiguracja klastra S2D — przewodnik krok po kroku
Poniżej przedstawiamy kompletną procedurę wdrożenia S2D na Windows Server 2022/2025 przy użyciu PowerShell. Zakładamy klaster 2-węzłowy z domeną Active Directory — najprostszy przypadek dla firm zaczynających przygodę z S2D.
Krok 1: Przygotowanie węzłów
Na każdym węźle klastra zainstaluj wymagane role i funkcje. Wykonaj poniższe polecenie na wszystkich serwerach (np. przez PSSession lub równolegle przez Invoke-Command):
# Instalacja wymaganych ról i funkcji
Install-WindowsFeature -Name Failover-Clustering, Hyper-V, `
Data-Center-Bridging, RSAT-Clustering-PowerShell `
-IncludeManagementTools -Restart
Upewnij się, że wszystkie dyski przeznaczone dla S2D są czyste (bez partycji). Sprawdź stan dysków:
# Wyczyść dyski na każdym węźle (UWAGA: usuwa wszystkie dane!)
Get-PhysicalDisk | Where-Object { $_.CanPool -eq $false } |
Reset-PhysicalDisk
# Alternatywnie, wyczyść konkretne dyski:
Get-Disk | Where-Object { $_.PartitionStyle -ne "RAW" } |
Clear-Disk -RemoveData -RemoveOEM -Confirm:$false
Krok 2: Walidacja klastra
Przed utworzeniem klastra zawsze uruchom pełną walidację. Jest to wymóg Microsoftu dla konfiguracji wspieranych przez producenta:
# Walidacja klastra (zamień na właściwe nazwy serwerów)
Test-Cluster -Node "SRV-HV01", "SRV-HV02" `
-Include "Storage Spaces Direct", "Inventory", "Network", "System Configuration"
Przejrzyj raport walidacji. Krytyczne błędy (czerwone) muszą być naprawione przed kontynuacją. Ostrzeżenia (żółte) dotyczące dysków S2D na tym etapie są normalne.
Krok 3: Tworzenie klastra
# Utwórz klaster (dla 2 węzłów z Cloud Witness)
New-Cluster -Name "KLASTER-S2D" `
-Node "SRV-HV01", "SRV-HV02" `
-StaticAddress "192.168.10.50" `
-NoStorage
# Skonfiguruj Cloud Witness (wymaga konta Azure Storage)
Set-ClusterQuorum -CloudWitness `
-AccountName "mojeklasterkonto" `
-AccessKey "twoj-klucz-dostepu-azure-storage"
Dla środowisk bez Azure możesz użyć File Share Witness na osobnym urządzeniu (np. NAS, kontroler domeny):
Set-ClusterQuorum -FileShareWitness "\\DC01\KlasterWitness"
Krok 4: Włączenie Storage Spaces Direct
# Włącz S2D — to polecenie automatycznie:
# - wykrywa dyski na wszystkich węzłach
# - tworzy pulę pamięci masowej
# - konfiguruje cache (jeśli są dyski cache)
# - tworzy warstwy wydajności i pojemności
Enable-ClusterStorageSpacesDirect -Verbose
Proces może potrwać kilka–kilkanaście minut zależnie od liczby dysków. Po jego zakończeniu S2D jest aktywne i gotowe do tworzenia woluminów.
Krok 5: Tworzenie woluminów CSV
# Utwórz wolumin 2 TB z three-way mirror na ReFS
New-Volume -FriendlyName "VM-Produkcja-01" `
-FileSystem ReFS `
-StoragePoolFriendlyName "S2D on KLASTER-S2D*" `
-ResiliencySettingName Mirror `
-Size 2TB
# Dla 2 węzłów użyj nested resiliency:
New-Volume -FriendlyName "VM-Archiwum" `
-FileSystem ReFS `
-StoragePoolFriendlyName "S2D on KLASTER-S2D*" `
-ResiliencySettingName "Nested Mirror Accelerated Parity" `
-Size 5TB
Krok 6: Weryfikacja stanu puli i woluminów
# Sprawdź stan puli
Get-StoragePool -FriendlyName "S2D on *" |
Select-Object FriendlyName, HealthStatus, OperationalStatus, Size, AllocatedSize
# Sprawdź stan woluminów
Get-VirtualDisk |
Select-Object FriendlyName, HealthStatus, OperationalStatus, ResiliencySettingName, Size
# Pełny przegląd zdrowia całego klastra
Get-StorageSubSystem -FriendlyName "Windows Storage on *" |
Debug-StorageSubSystem
Monitorowanie S2D za pomocą Windows Admin Center
Windows Admin Center (WAC) to bezpłatne, webowe narzędzie administracyjne Microsoftu, które znacznie upraszcza zarządzanie klastrami S2D. Dostępne na stronie Microsoft jako bezpłatne pobieranie — bez dodatkowych licencji.
WAC oferuje dla klastrów S2D:
- Dashboard klastra — przegląd stanu wszystkich węzłów, woluminów i dysków fizycznych w czasie rzeczywistym
- Alerty zdrowia storage — automatyczne wykrywanie dysków z obniżoną wydajnością, błędami I/O, problemami z replikacją
- Wydajność historyczna — wykresy IOPS, przepustowości i opóźnień dla każdego woluminu i dysku fizycznego
- Zarządzanie VM — tworzenie, migracja, zarządzanie maszynami wirtualnymi bez konieczności otwierania Hyper-V Managera
- Aktualizacje klastra — Cluster-Aware Updating (CAU) zintegrowane bezpośrednio w WAC
- Rozszerzenia AI (Windows Server 2025) — integracja z Azure Arc dla dodatkowych możliwości monitorowania i zarządzania
Instalacja WAC zajmuje kilka minut. Po zainstalowaniu na dowolnym serwerze z dostępem do sieci klastra, wejdź przeglądarką na https://nazwaservera i dodaj klaster przez „Add → Windows Server cluster". WAC automatycznie wykryje S2D i włączy rozszerzone funkcje monitorowania.
Dla środowisk bez WAC, stan S2D można monitorować przez PowerShell, system zdarzeń Windows (Event Viewer, kanał Microsoft-Windows-StorageSpacesDirect) lub przez zintegrowaną konsolę Failover Cluster Manager, która pokazuje stan CSV i węzłów klastra.
Kiedy S2D NIE jest właściwym wyborem?
Uczciwe omówienie S2D wymaga wskazania scenariuszy, w których ta technologia nie jest optymalnym rozwiązaniem. Wdrożenie S2D tam, gdzie nie pasuje, będzie frustrujące i kosztowne.
- Pojedynczy serwer: S2D wymaga minimum 2 węzłów. Na jednej maszynie należy użyć Storage Spaces (bez Direct) lub tradycyjnego RAID.
- Aplikacje certyfikowane tylko na SAN/Fibre Channel: Niektóre stare systemy ERP, medyczne lub przemysłowe mają certyfikację wyłącznie na sprzęt SAN. Wdrożenie S2D może unieważnić wsparcie producenta.
- Bardzo małe środowiska (<3 VM): Jeśli wirtualizujesz 2–3 maszyny o niskich wymaganiach, koszt i złożoność klastra S2D przewyższy korzyści. Rozważ Windows Server Standard z Hyper-V na pojedynczym hoście i ręcznym backupem.
- Workloady wymagające bardzo niskich opóźnień (<100 µs): S2D z NVMe i RDMA osiąga opóźnienia rzędu 200–500 µs. Jeśli potrzebujesz opóźnień poniżej 100 µs (np. trading HFT, przemysłowe systemy czasu rzeczywistego), rozważ lokalne NVMe bez replikacji lub dedykowany hardware PMem.
- Środowiska bez kompetencji Windows Server: S2D to zaawansowana technologia. Wdrożenie i utrzymanie wymaga znajomości Failover Clustering, PowerShell i podstaw storage. Bez tych kompetencji w zespole, lepiej rozważyć outsourcing lub prostsze rozwiązanie.
- Brak możliwości inwestycji w licencje Datacenter: Jeśli budżet nie pozwala na Windows Server Datacenter, S2D nie jest opcją. Windows Server Standard nie obsługuje tej technologii.
Wydajność S2D — czego realnie się spodziewać?
Microsoft nie podaje jednej oficjalnej liczby IOPS dla S2D, ponieważ wydajność zależy od konfiguracji sprzętowej. Poniżej orientacyjne wartości dla typowych konfiguracji w środowiskach produkcyjnych:
- 2 węzły, SSD + HDD (hybrid), 10 GbE, two-way mirror: ok. 50 000–150 000 IOPS losowych 4K, opóźnienie 1–3 ms
- 4 węzły, all-NVMe, 25 GbE RDMA, three-way mirror: 500 000–2 000 000+ IOPS losowych 4K, opóźnienie 200–500 µs
- 4 węzły, all-SSD, 25 GbE RDMA, mirror: 200 000–800 000 IOPS losowych 4K, opóźnienie 500 µs–1 ms
Dla porównania: entry-level macierz SAN (np. Dell EMC SC4020, HPE MSA 2060) oferuje typowo 100 000–300 000 IOPS przy koszcie 80 000–200 000 zł samego sprzętu. Klaster S2D z 4 węzłami all-NVMe za porównywalny budżet osiągnie znacznie wyższe parametry.
Kluczowe czynniki dla maksymalizacji wydajności S2D:
- Używaj kart RDMA (iWARP jest prostszy w konfiguracji niż RoCE v2 — nie wymaga konfiguracji PFC na przełącznikach)
- Separuj ruch storage od ruchu VM i zarządzającego w osobnych kartach lub VLAN-ach
- Dyski cache powinny mieć wyższą pojemność niż „hot data" workloadu — niedowymiarowany cache eliminuje korzyść z warstwy szybkich dysków
- Liczba dysków capacity powinna być wielokrotnością liczby dysków cache na każdym węźle
- Używaj ReFS z MAP zamiast parity „na czysto" — lepsza wydajność zapisu przy podobnej oszczędności pojemności
Licencje Windows Server Datacenter w KluczeSoft
Storage Spaces Direct wymaga licencji Windows Server Datacenter na każdym węźle klastra. Licencja Datacenter uprawnia do nieograniczonej liczby maszyn wirtualnych Windows Server na danym hoście fizycznym — co przy gęstej wirtualizacji jest de facto obowiązkowym wyborem niezależnie od S2D.
Licencje w KluczeSoft dostępne są jako klucze OEM i OPEN License, z dostawą w kilka minut po zaksięgowaniu płatności. W razie pytań dotyczących doboru licencji do konkretnej konfiguracji klastra — skontaktuj się z naszym działem technicznym.
Dodaj komentarz