Hyper-V İçin Paylaşımlı Depolama: iSCSI, SMB3 ve Fibre Channel

Hyper-V kümesinde “VM’ler yavaş” şikâyeti geldiğinde ilk bakılacak yer çoğu zaman CPU değil, depolama yoludur. VM disklerinin hangi protokolle ve hangi ağ üzerinden tutulduğu; performansı, arıza davranışını ve günlük işletim yükünü doğrudan belirler. Bu yazı harici depolama kullanacak Hyper-V kümeleri için iSCSI, SMB3 ve Fibre Channel seçeneklerini karşılaştırıyor; MPIO, SMB Multichannel ve Cluster Shared Volume (CSV) yapılandırmasını PowerShell örnekleriyle veriyor. Kümenin genel tasarım kontrolleri için Hyper-V failover cluster planlama yazısıyla birlikte okuyun.

Hyper-V kümesinde depolama erişim modelleri

Hyper-V kümesi VM dosyalarına iki temel yoldan erişir:

• Blok depolama (iSCSI, Fibre Channel, SAS): Dizi LUN’ları tüm düğümlere sunar; LUN’lar NTFS veya ReFS ile biçimlendirilip kümede CSV olarak eklenir. VM’ler C:\ClusterStorage\VolumeN yolunda durur.
• Dosya depolama (SMB 3.x): VM dosyaları bir dosya sunucusundaki (çoğunlukla Scale-Out File Server veya SMB3 destekli NAS) paylaşımda durur; Hyper-V hostları UNC yoluyla erişir.

Üçüncü model Storage Spaces Direct (S2D) harici depolama kullanmaz, hostların yerel disklerini havuzlar. HCI ile klasik SAN arasındaki mimari karar HCI ve SAN karar rehberinde; burada yalnız harici depolamaya erişim protokolü var.

iSCSI: ağ tasarımı ve MPIO

iSCSI blok depolamayı standart Ethernet üzerinden (TCP 3260) taşır. Doğru tasarlanırsa kurumsal iş yükleri için yeterli performans ve yedeklilik verir. Yanlış tasarlanırsa kümedeki bütün VM’leri aynı anda etkileyen gecikmelerin kaynağı olur ve sorun çoğu zaman yanlış yerde, uygulamada veya hipervizörde aranır.

Temel tasarım kuralları:

• Her hostta iSCSI için en az iki ayrılmış fiziksel port; bu portlar VM trafiği veya yönetim ağıyla paylaşılmaz.
• İki port teaming yapılmaz; yedeklilik ve yük dağıtımı MPIO ile sağlanır. Her port ayrı alt ağda (ör. 10.20.1.0/24 ve 10.20.2.0/24), mümkünse ayrı switch’te olur.
• iSCSI arayüzlerinde varsayılan ağ geçidi tanımlanmaz, DNS kaydı kapatılır; Client for Microsoft Networks ve File and Printer Sharing bağlantıları kaldırılabilir.
• Jumbo frame kullanılacaksa host NIC’i, switch portları ve depolama dizisinde aynı MTU ayarlanır. Tek bir eksik nokta parçalanma veya bağlantı sorunu doğurur.

Sahada en sık gördüğümüz iSCSI hatası, MTU’nun yolun bir noktasında unutulmasıdır. Küçük paketler geçer, büyükler takılır. Kontrol için hosttan diziye ping -f -l 8972 ile parçalanmasız büyük paket gönderin; yanıt gelmiyorsa zincirde eksik bir halka var.

MPIO kurulumu ve iSCSI bağlantısı PowerShell ile şöyle yapılır (adresler örnektir):

Install-WindowsFeature -Name Multipath-IO   # yeniden baslatma gerekir
Enable-MSDSMAutomaticClaim -BusType iSCSI
Set-MSDSMGlobalDefaultLoadBalancePolicy -Policy RR

Set-Service msiscsi -StartupType Automatic; Start-Service msiscsi
New-IscsiTargetPortal -TargetPortalAddress 10.20.1.50 -InitiatorPortalAddress 10.20.1.11
New-IscsiTargetPortal -TargetPortalAddress 10.20.2.50 -InitiatorPortalAddress 10.20.2.11

$t = (Get-IscsiTarget).NodeAddress
Connect-IscsiTarget -NodeAddress $t -TargetPortalAddress 10.20.1.50 `
  -InitiatorPortalAddress 10.20.1.11 -IsMultipathEnabled $true -IsPersistent $true
Connect-IscsiTarget -NodeAddress $t -TargetPortalAddress 10.20.2.50 `
  -InitiatorPortalAddress 10.20.2.11 -IsMultipathEnabled $true -IsPersistent $true

Yük dengeleme politikasında (Round Robin, Least Queue Depth vb.) depolama üreticisinin önerisini esas alın; bazı diziler kendi DSM’ini veya belirli bir politikayı şart koşar. Yol sayısını mpclaim -s -d ile doğrulayın: her LUN için beklenen sayıda yol görünmeli. Tek yol görünüyorsa MPIO yok demektir.

SMB3: Multichannel, RDMA ve Scale-Out File Server

Windows Server 2012 ile gelen SMB 3.0, Hyper-V VM dosyalarının dosya paylaşımında tutulmasını destekler. Bu senaryoyu güçlü kılan iki özellik var:

• SMB Multichannel: Birden fazla NIC varsa SMB otomatik olarak birden fazla bağlantı açar; bant genişliğini toplar, bir NIC arızasında oturumu sürdürür. Ek yapılandırma gerektirmez.
• SMB Direct (RDMA): iWARP, RoCE veya InfiniBand destekli NIC’lerde veri CPU’yu büyük ölçüde atlayarak aktarılır. RoCE kullanılıyorsa switch tarafında DCB/PFC yapılandırması gerekir; iWARP bu gereksinimi taşımaz. Yarım yapılmış PFC, RDMA’yı hiç açmamaktan kötüdür.

Dosya tarafında yüksek erişilebilirlik için Scale-Out File Server (SOFS) rolü kullanılır. SOFS, CSV üzerindeki paylaşımı tüm dosya sunucusu düğümlerinden aynı anda sunar; “continuously available” paylaşımlar sayesinde bir düğüm arızasında Hyper-V hostları G/Ç’yi kesintisiz sürdürür. Kurulumun özü:

Add-ClusterScaleOutFileServerRole -Name SOFS01
New-Item -ItemType Directory -Path C:\ClusterStorage\Volume1\Shares\VMs
New-SmbShare -Name VMs -Path C:\ClusterStorage\Volume1\Shares\VMs `
  -FullAccess 'CORP\HV01$','CORP\HV02$','CORP\HV-CLU$','CORP\HyperV-Admins' `
  -ContinuouslyAvailable $true
Set-SmbPathAcl -ShareName VMs   # paylaşım izinlerini klasör NTFS ACL’ine uygular

Hyper-V hostlarının bilgisayar hesaplarına ve küme adına hem paylaşım hem NTFS izni verilmeli. Uzak bir yönetim makinesinden VM oluşturuluyorsa Kerberos kısıtlı yetkilendirme (constrained delegation) yapılandırılmalı; yoksa “erişim reddedildi” hatası alırsınız ve izinler doğru göründüğü için saatler kaybedilir. Doğrulama:

Get-SmbMultichannelConnection
Get-SmbClientNetworkInterface
Get-NetAdapterRdma | Where-Object Enabled

SMB3 destekli üçüncü taraf NAS’lar da kullanılabilir. Hyper-V için gereken SMB 3 özelliklerini (özellikle continuous availability) desteklediğini ve üreticinin Hyper-V için onay verdiğini doğrulayın.

Fibre Channel ne zaman anlamlı

Fibre Channel ayrı bir fiziksel ağ (HBA, FC switch, zoning) ister. Kurulum ve işletimi ek uzmanlık gerektirir; karşılığında kayıpsız, öngörülebilir gecikmeli ve depolama trafiğini Ethernet’ten tamamen ayıran bir yapı verir. FC genellikle şu durumlarda mantıklıdır:

• Kurumda zaten çalışan bir FC fabric’i ve onu yönetebilen ekip varsa
• Gecikmeye çok duyarlı, yüksek G/Ç’li veritabanları aynı diziyi kullanıyorsa
• Konuk VM’lerin doğrudan LUN görmesi gerekiyorsa: Hyper-V’nin Virtual Fibre Channel özelliği NPIV ile VM’e sanal HBA verir (HBA ve switch NPIV desteklemeli)

Sıfırdan kurulan küçük ve orta ölçekli kümelerde 25 GbE iSCSI veya SMB3, FC’nin getirdiği faydayı sunucu ve sistem altyapısı için daha düşük işletim yüküyle genellikle karşılar. FC’de arızaların büyük kısmı zoning ve HBA firmware uyumsuzluğundan çıkar; firmware matrisini takip edecek kimse yoksa FC kurmayın.

Protokol karşılaştırma tablosu

Cluster Shared Volume davranışı

CSV aynı LUN’a tüm düğümlerin aynı anda yazabilmesini sağlar. Her CSV’nin bir koordinatör (owner) düğümü vardır; meta veri işlemleri (dosya oluşturma, genişletme gibi) koordinatör üzerinden yapılır, normal okuma–yazma ise her düğümden doğrudan diziye gider (Direct I/O).

Bir düğüm LUN’a doğrudan erişimini kaybederse G/Ç küme ağı üzerinden koordinatöre yönlendirilir (redirected I/O). VM’ler çalışmaya devam eder, performans belirgin düşer. Kimse alarm almaz. Durumu şöyle izleyin:

Get-ClusterSharedVolume | Select-Object Name, OwnerNode, State
Get-ClusterSharedVolumeState | Select-Object Name, Node, StateInfo, FileSystemRedirectedIOReason, BlockRedirectedIOReason

StateInfo değeri tüm düğümlerde Direct olmalı. Bir ayrıntı: SAN üzerinde ReFS ile biçimlendirilmiş CSV’ler dosya sistemi yönlendirmeli modda çalışır; bu yüzden harici blok depolamada CSV için NTFS önerilir. ReFS’in CSV’de doğrudan modda çalışması S2D senaryosuna özgüdür. “Yeni dosya sistemi daha iyidir” diye SAN LUN’unu ReFS ile biçimlendirmek, sahada performans şikâyetinin klasik sebeplerinden biridir.

CSV sayısını düğüm sayısına göre planlayın: birkaç CSV oluşturup sahipliklerini düğümlere dağıtmak meta veri yükünü tek düğümde toplamaz.

Doğrulama ve performans testi

Üretime almadan önce iki tür doğrulama yapın:

1. Küme doğrulaması: Test-Cluster depolama testleri dahil çalıştırılır. Depolama testleri diskleri çevrimdışı alabileceği için üretimdeki kümede yalnız yeni eklenen ve henüz kullanılmayan diskleri hedefleyin.
2. Yük testi: Microsoft’un DiskSpd aracıyla CSV üzerinde gerçekçi bir profil çalıştırın ve ortalamaya değil gecikme dağılımına bakın:

   diskspd.exe -c50G -d120 -b8K -o16 -t8 -r -w30 -Sh -L C:\ClusterStorage\Volume1\test.dat

Testi çift yolla ve tek yolla (bir iSCSI portu kapatılarak) tekrarlayın; yol arızasında G/Ç’nin kesilmediğini ve gecikmenin kabul edilebilir kaldığını görün. Bu sonuçları saklayın; ileride “eskiden hızlıydı” şikâyeti geldiğinde elinizdeki tek somut referans bunlar olacak. Depolama dizisi ve sunucu donanımı seçiminde donanım danışmanlığı, küme tasarımı ve devreye almada sanallaştırma ve veri yönetimi hizmetimiz kapsamında birlikte çalışabiliriz. Sanal switch ve trafik ayrımı tarafı için Hyper-V SET ve sanal ağ tasarımı yazısına bakın.

Sık sorulan sorular

iSCSI için NIC teaming kullanabilir miyim?

Microsoft, iSCSI trafiği için NIC teaming yerine MPIO önerir. MPIO depolama yollarını iSCSI oturumu düzeyinde yönetir; hem yük dağıtır hem de yol arızasında hızlı geçiş sağlar.

SMB3 depolama iSCSI’den daha mı yavaştır?

Zorunlu olarak değil. SMB Multichannel ve özellikle RDMA destekli NIC’lerle SMB3, blok protokollerle karşılaştırılabilir performans verebilir. Sonucu ağ tasarımı, dosya sunucusu ve disklerin kapasitesi belirler; kendi ortamınızda DiskSpd ile ölçün.

CSV redirected I/O moduna neden geçer?

Bir düğümün LUN’a doğrudan yolu kesildiğinde, bazı yedekleme işlemleri sırasında veya SAN üzerinde ReFS kullanıldığında CSV yönlendirmeli moda geçer. Teşhiste ilk bakılacak yer Get-ClusterSharedVolumeState çıktısındaki neden alanlarıdır.

Küçük bir kümede Fibre Channel gerekli mi?

Genellikle hayır. Mevcut FC altyapısı ve ekibi yoksa ayrılmış ağ üzerinde iSCSI veya SMB3 daha düşük işletim yüküyle yeterli performans verir. FC, mevcut fabric’i olan veya gecikmeye çok duyarlı iş yükü bulunan ortamlarda anlamlıdır.