Storage Spaces Direct (S2D), Azure Local ve Windows Server altyapılarında fiziksel sunucuların yerel disklerini ortak, hata toleranslı bir depolama katmanında birleştiren Microsoft teknolojisidir. Özellikle hiper-birleşik (HCI) altyapılarda, ayrı bir SAN yatırımı yapmadan sanallaştırma iş yükleri için yüksek erişilebilir depolama tasarlamamızı sağlar. Bu makalede S2D’nin nasıl çalıştığını, Azure Local ile ilişkisini, ağ ve disk gereksinimlerini, kullanılabilir kapasiteyi ve üretim ortamına geçmeden önce yapılması gereken doğrulamaları değerlendireceğim.
Güncelleme notu (Ekim 2026): Bu yazının önceki sürümündeki Windows Server 2016/2022 ve Azure Stack HCI 20H2/21H2 referanslarını tarihsel bağlamda bırakarak, güncel Azure Local ve Windows Server 2025 ayrımını netleştirdim. Buradaki PowerShell komutları örnek/denetim amaçlıdır; bunları gerçek donanım üzerinde çalıştırıp sonuç elde ettiğimi iddia etmiyorum.
Storage Spaces Direct (S2D) nedir?
S2D, Software-Defined Storage (SDS) yaklaşımının Windows Server ve Azure Local tarafındaki uygulamasıdır. VMware vSAN ile benzer bir problemi çözer: Farklı sunuculara fiziksel olarak bağlı disklerin yüksek hızlı Ethernet ağı üzerinden tek bir mantıksal havuz gibi kullanılması. Ancak ürünlerin disk yerleşimi, dayanıklılık politikaları, ağ tasarımı ve yönetim modelleri aynı değildir.
Windows Server üzerinde klasik S2D mimarisi genellikle 2–16 fiziksel düğüm ölçeğinde anlatılır. Azure Local ise desteklenen tasarımına bağlı olarak tek düğümlü ve çok düğümlü seçenekler sunar. Tek düğüm kurulumu, düğüm arızasına karşı yüksek erişilebilirlik sağlamaz. Yeni kapasite ekleme, disk ekleme ve sunucu genişletme yetenekleri de seçilen Azure Local sürümüne ve sertifikalı sistem tasarımına göre değerlendirilmelidir.
S2D nasıl çalışır?
S2D mimarisinin temelinde Failover Clustering, SMB 3, Software Storage Bus, Storage Spaces, Cluster Shared Volumes (CSV) ve çoğunlukla ReFS yer alır. Her sunucunun kendi yerel NVMe/SSD/HDD diskleri vardır. Yazılım katmanı bu diskleri fiziksel olarak ortak disk haline getirmez; bunun yerine küme düğümleri arasında veri ve metadata erişimini yöneterek ortak kullanılan bir storage pool sunar.
Yukarıdaki orijinal mimari şemasını katmanlara ayırırsak:
- Ağ: SMB Multichannel ve uygun donanımda SMB Direct (RDMA) kullanılarak düğümler arasında depolama trafiği taşınır. Üretim tasarımında en az 10 GbE sınıfındaki onaylı bağlantılar ve uygun ağ yedekliliği değerlendirilir.
- Software Storage Bus: Her düğümün yerel disklerini mantıksal olarak kümeye sunan dağıtık depolama katmanıdır.
- Storage Pool: Desteklenen, havuza dahil olmaya uygun disklerin birleştirildiği yazılım tanımlı kapasitedir.
- Resiliency: Mirror, parity veya tasarıma uygun birleşik politikalarla veri kopyaları ya da kodlanmış parçalar disk/düğüm arızalarına karşı dağıtılır.
- ReFS ve CSV: Sanallaştırma dosyalarına uygun dosya sistemi ve kümedeki düğümlerin birimlere ortak erişim sağlayan katmanıdır.
- Yönetim: Azure Local tarafında Azure yönetim düzlemi ve yerel sistem araçları; Windows Server tarafında Failover Cluster Manager, Windows Admin Center ve PowerShell kullanılabilir.
Windows Server S2D ile Azure Local arasındaki fark
| Konu | Windows Server S2D | Azure Local |
|---|---|---|
| Platform | Windows Server Datacenter ve desteklenen küme rolleri | Azure ile bütünleşik, doğrulanmış Azure Local sistemi |
| Dağıtım | Converged/SoFS veya hyperconverged tasarımlar | S2D kullanan Azure Local HCI tasarımları; ayrıca ürünün ayrı dış SAN seçenekleri olabilir |
| Yönetim | Windows Server/cluster yönetim araçları | Azure yönetim ve yaşam döngüsü entegrasyonuyla birlikte yerel araçlar |
| Donanım | Windows Server S2D gereksinimleri | Azure Local sertifikalı sistem ve sürüme özgü gereksinimler |
| Tek düğüm | Klasik çok düğümlü S2D tasarımından ayrıdır | Desteklenen tek düğümlü dağıtımlar vardır; düğüm arızasına dayanıklılık yoktur |
Önemli ayrım: Azure Local yalnızca “Windows Server + Hyper-V + S2D” toplamından ibaret değildir. Bu bileşenlerin üzerine platforma özgü kurulum, doğrulama, yaşam döngüsü, Azure bağlantısı ve yönetim gereksinimleri gelir. Üstelik güncel Azure Local sistem gereksinimleri, bazı senaryolarda harici Fibre Channel SAN depolamaya da izin verir; buna rağmen Azure Local altyapısı için asgari bir S2D kapasitesi gerekliliği devam eder.
Hyperconverged ve converged mimari
Hyperconverged: compute ve storage aynı düğümlerde
Hyperconverged modelde Hyper-V sanal makineleri ve S2D depolama aynı fiziksel düğümlerde çalışır. Veri yolu mümkün olduğunca kısa tutulur; küme kapasitesi ve işleme gücü birlikte ölçeklenir. Azure Local üzerindeki standart HCI yaklaşımının merkezinde bu model bulunur.
Converged: depolama ve compute ayrı kümelerde
Windows Server S2D ile oluşturulan bir depolama kümesi, SMB 3 paylaşımları üzerinden ayrı bir Hyper-V kümesine Scale-Out File Server (SoFS) olarak hizmet verebilir. Bu, compute ve storage ölçeklemesini ayrıştırır. Bu şema Windows Server S2D senaryosuna aittir; Azure Local’in standart HCI dağıtımıyla aynı şekilde yorumlanmamalıdır.
Donanım ve ağ tasarımında en kritik noktalar
Eski S2D belgelerinde çok kullanılan “her sunucuda iki SSD ve dört ek disk” gibi ifadeler, tüm Azure Local dağıtımlarında geçerli tek bir zorunluluk olarak okunmamalı. Örneğin güncel Azure Local çok düğümlü all-flash tasarımları tek tip NVMe/SSD medya kullanabilir. Desteklenen disk sayısı, önbellek oranı, disk sürücüleri ve topoloji mutlaka seçilen sertifikalı sistemin ve ilgili Azure Local sürümünün matrisinden doğrulanmalıdır.
- Disk sunumu: S2D diskleri ilgili sunucuya doğrudan bağlı olmalı; RAID sanal diski olarak sunulmamalı, desteklenen pass-through/HBA yapılandırması kullanılmalıdır.
- All-flash veya hibrit: NVMe/SSD tabanlı tasarımlarda önbellek seçimi farklı olabilir. HDD + flash hibrit tasarımlar için ayrı cache ve dayanıklılık koşulları vardır.
- RDMA: RoCE ve iWARP seçeneklerini “her koşulda tak-çalıştır” değerlendirmemek gerekir. DCB/PFC, sürücü, firmware ve anahtar yapılandırmasının çözüm mimarisiyle uyumu önemlidir.
- Network ATC: Azure Local’de management, compute ve storage ağ intent’lerinin doğrulanması; VLAN, adaptör ataması ve storage trafiğinin uygun şekilde ayrıştırılması gerekir.
- Switchless: Belirli iki, üç veya dört düğümlü doğrulanmış topolojilerde depolama bağlantıları doğrudan kurulabilir. Daha büyük veya gelecekte genişletilecek tasarımlarda fiziksel switch gereksinimini planlama sırasında doğrulayın.
- Üretim ortamı: Uyumluluğu doğrulanmamış masaüstü sınıfı disklerle veya destek dışı RAID kontrolcüleriyle S2D kurulumu planlamayın.
Mirror, parity ve kullanılabilir kapasite
S2D seçiminde ham toplam TB değeri tek başına belirleyici değildir. Veri dayanıklılığına ayırdığınız kopyalar, yedek kapasite, altyapı diskleri, yeniden dengeleme/repair alanı ve iş yükü büyümesi gerçek kapasiteyi etkiler.
| Koruma türü | Yaklaşık teorik veri verimliliği | Başlıca değerlendirme |
|---|---|---|
| Two-way mirror | %50 | İki kopya; iki düğümde tipik seçenek |
| Three-way mirror | %33 | Üç kopya; yeterli sayıda hata alanı/düğüm gerekir |
| Mirror-accelerated parity | İş yükü ve mirror/parity oranına bağlı | Yazma performansı ile kapasite arasında denge |
| Dual parity | Düğüm sayısına göre değişir | Kapasite avantajı; rastgele yazma gecikmesi ve CPU maliyeti |
Örneğin 10 TB fiziksel kapasitenin two-way mirror ile teorik olarak yaklaşık 5 TB veri alanına karşılık gelmesi beklenir. Bu sonuç, kullanılabilir net kapasite anlamına gelmez: repair reserve, metadata, altyapı ve operasyonel boş alan ayrıca hesaplanmalıdır. Three-way mirror için aynı 10 TB ham alan teorik olarak yaklaşık 3,3 TB kopyalanan veri kapasitesi sunar. Tasarımdaki düğüm sayısı ve ilgili dayanıklılık seçeneği uygun değilse bu yöntem uygulanamaz.
SQL Server ve yoğun rastgele I/O yapan sanal makinelerde genellikle mirror tabanlı tasarımlar daha öngörülebilir gecikme sunar. Parity tabanlı yerleşimler, kapasitenin öncelikli olduğu ve iş yükü profilinin buna uygun olduğu durumlarda değerlendirilmelidir. Bu tercihi yalnızca teorik IOPS iddialarına bakarak yapmak doğru değildir.
Düğüm ve disk arızasında ne olur?
Bir disk veya düğüm kaybından sonra veriye erişimin sürmesi, seçilen koruma politikasına, kalan sağlam kopyalara, kümenin quorum durumuna ve aynı anda yaşanan arızalara bağlıdır. Dolayısıyla “herhangi bir node düşse bile veri daima erişilebilir” şeklinde koşulsuz bir garanti veremeyiz. Disk değiştirme veya düğüm geri geldiğinde repair ve rebalance işlemleri başlatılabilir; bu sırada performans ve boş kapasite dikkatle izlenmelidir.
Özellikle iki düğümlü mimaride witness ve quorum tasarımı önemlidir. S2D dayanıklılığı yedekleme değildir; yanlışlıkla silme, fidye yazılımı veya mantıksal veri bozulması gibi risklere karşı ayrı yedekleme ve geri yükleme testleri planlanmalıdır.
Üretim öncesi salt okunur PowerShell kontrolleri
Aşağıdaki komutlar, Windows Server S2D kümesinin mevcut durumunu görüntülemek için örnektir. Azure Local’de aynı cmdlet’lerin kullanılabilirliği ve yönetim yöntemi sürüme göre değişebilir. Komutları uygun yönetim oturumunda ve yetkiyle çalıştırın; burada disk silme, havuz oluşturma veya cluster yapılandırmasını değiştirme komutu vermiyorum.
Get-ClusterNode | Format-Table Name, State -AutoSize
Get-StoragePool -IsPrimordial $false | Format-Table FriendlyName, HealthStatus, OperationalStatus, Size
Get-PhysicalDisk | Select-Object FriendlyName, MediaType, HealthStatus, OperationalStatus, Size
Get-VirtualDisk | Format-Table FriendlyName, ResiliencySettingName, HealthStatus, OperationalStatus, Size
Get-Volume | Select-Object FileSystemLabel, FileSystem, HealthStatus, Size, SizeRemainingS2D’nin durumu ve onarım işlerini takip ederken kullanılabilecek ek denetimler:
Get-StorageJob
Get-ClusterSharedVolume
Get-ClusterPerformanceHistory -ErrorAction SilentlyContinueSon komutun kullanılabilirliği sistem sürümüne ve yapılandırmaya bağlıdır. Daha kapsamlı doğrulamada üretici tanılama araçları, Azure Local health/validation araçları ve Windows Server küme doğrulaması birlikte değerlendirilmelidir.
Azure Local için kurulum öncesi kontrol listesi
- Dağıtım hedefini belirleyin: Windows Server S2D mi, Azure Local mi? Bu ikisinin lisans, yaşam döngüsü ve destek şartlarını karıştırmayın.
- Donanımın ve ağ adaptörlerinin üretici onaylı çözüm kataloğunda bulunduğunu doğrulayın; firmware/driver sürümlerini eşleştirin.
- Storage intent, RDMA, IP/VLAN, DNS, Active Directory ve zaman eşitlemesini doğrulayın.
- Düğüm sayısına göre mirror/parity seçeneklerini ve quorum/witness gereksinimini tasarlayın.
- Ham kapasite yerine kullanılabilir kapasite, büyüme payı ve arıza sonrası onarım alanını hesaplayın.
- Gerçek uygulama profilinde gecikme, IOPS, bant genişliği ve failover davranışını doğrulayın.
- Yedekleme, geri dönüş, izleme ve güncelleme prosedürlerini önceden yazılı hale getirin.
Sık sorulan sorular
Azure Local için ayrı SAN satın almak zorunda mıyım?
Hayır. HCI/S2D’nin önemli avantajlarından biri onaylı yerel disklerle ortak depolama sağlayabilmesidir. Fakat güncel Azure Local’de bazı sertifikalı harici SAN senaryoları da vardır; tasarımın uygunluğu iş yüküne göre belirlenir.
S2D, Windows Server 2025 üzerinde kullanılabilir mi?
Evet. Microsoft’un güncel S2D genel bakış belgesi Windows Server 2025’i de kapsar. Üretimde Windows Server sürümü, Datacenter lisansı ve sertifikalı donanım gereksinimleri ayrı ayrı kontrol edilmelidir.
S2D her zaman 16 sunucu ile mi sınırlı?
Windows Server S2D ve standart çok düğümlü HCI referanslarında 2–16 düğüm yaygın sınırdır. Fakat Azure Local ailesindeki farklı mimariler, tek düğüm ve harici SAN kullanan ayrıştırılmış tasarımlar nedeniyle “her Azure Local sistemi 2–16 düğümdür” genellemesi doğru değildir.
S2D veri yedekleme ihtiyacını ortadan kaldırır mı?
Hayır. Mirror ve parity erişilebilirlik ile donanım arızası toleransı sağlar; sürümleme, fidye yazılımı koruması ve olaydan geri dönüş için ayrı yedekleme gerekir.
Sonuç
S2D’nin değeri yalnızca diskleri bir havuzda toplamak değil; compute, ağ, depolama ve hata toleransını birlikte tasarlayabilmemizdir. Azure Local bu altyapıyı Azure yönetimiyle bütünleştirerek yeni bir kullanım modeli sunuyor. Benim önerim, ürün seçimini performans tablolarındaki en yüksek değerlere göre değil; doğrulanmış donanım, iş yükünün gecikme ihtiyacı, kapasite verimliliği ve olası düğüm kaybındaki gerçek davranış üzerinden yapmak.
