Software Defined Storage (Yazılım Tanımlı Depolama) akımının Microsoft ayağını temsil eden Storage Space Direct (S2D) sayesinde fiziksel veya sanal sunuculara doğrudan takılı lokal depolama birimleriyle yüksek erişilebilir bir depolama ünitesi kurmak ve yönetmek mümkün hale geldi. Windows Server 2012’de Storage Pools ile ilk adımları atılan Software Defined Networking, Windows Server 2016 ile tam teşekküllü bir hale geldi ve Windows Server 2019 ile beraber olgunlaştı.
Windows Server 2012’deki Storage Pools ile bir sunucu üzerindeki lokal diskleri özel bir SCSI veya RAID kontrolcüsüne ihtiyaç duymadan bir depolama havuzuna dönüştürüp fiziksel disk yedekliliğini (redundancy) sağlayabiliyorduk, fakat bu havuz sunucuya özel oluşturuluyordu. Yüksek erişilebilir Cluster ortamlarında ihtiyaç duyulan, cluster’a üye bütün sunucuların ortak olarak veya aynı anda erişebildiği paylaşımlı bir depolama alanı (Shared Storage) oluşturmak mümkün değildi. Windows Server 2016 ile beraber gelen S2D sayesinde bu eksiklik giderilmiş oldu. Artık fiziksel veya sanal ortamlarınızda cluster storage veya cluster shared storage oluşturma imkânımız oldu.
Türkiye’de Azure’a erkenden adapte olan kurumlardan birinde çalışanlar şunu iyi bilir: Azure’da üçüncü parti bir yazılıma para vermeden iSCSI veya benzer bir protokolle shared storage oluşturmak ve en basitinden yüksek erişilebilir bir dosya sunucusu kurup içerisinde kritik uygulama dosyalarını barındırmak mümkün değildi. FCI ile SQL Server Cluster kurmak veya IIS farm’ınızın faydalanabileceği ortak bir depolama sağlamayı bunlara örnek verebiliriz. Bulut diyoruz, kesintisizlik, yüksek SLA, HA olmalı diyoruz, lakin o zamanlar bunları sanal makine depolaması için istediğinizde üçüncü partiye başvurmak zorunda kalıyordunuz. Veri tabanı tarafı için SQL AlwaysOn AG ile shared storage ihtiyacının kaldırılmasının nedenlerinden birinin, Azure’da yüksek erişilebilir veri tabanı ortamı kurmayı sağlamak olduğunu düşünüyorum.
Bu kısa tarih bilgisini vermemin sebebi S2D’nin ne kadar kritik bir özellik olduğunu anlatabilmek adınaydı. S2D’nin faydaları tabi ki sadece Azure kullanıcılarına değil; on premise ortamlarda özel storage donanımı satın almaya ihtiyaç kalmadan, sadece sunucular üzerindeki depolama alanı ve network kartlarını kullanarak Hyper Converged Cluster ortamları kurmak mümkün hale geldi. Vendor bağımlı olmadan istediğiniz sunucu markasından sunucu ve yeterli miktarda disk ve network kartı satın alarak siz de kendi storage’inizi kurup yönetebiliyor ve sanallaştırma gibi birçok amaç için kullanabiliyorsunuz. Ekstra bir Windows Server lisansına ihtiyacınız yok, fiziksel işlemci soketi için aldığınız lisanslar yeterli. Bulut tarafında S2D kullanmak istediğinizde de vendor bağımlı değilsiniz. İster Azure’da ister Amazon’da ister Google’da Windows Server lisansınız olduğu sürece S2D cluster ortamları kurabilirsiniz.
Makalemizin konusu her ne kadar Azure ortamında geçse de anlatacaklarımı ufak değişikliklerle diğer bulutlarda veya on-premise ortamlarda da uygulayabilirsiniz. Hangi ortamda kuruyor olursanız olun 10 Gbit/s bant genişliği sunan, RDMA destekli network kartları kullanmanız gerekiyor; şayet bunlardan birkaçını birleştirmeniz gerekirse Switch Embedded Teaming (SET) özelliğini kullanmanız tavsiye ediliyor. Microsoft’un geçmişteki Ignite etkinliğinde yaptığı demolara bakarsak sadece iki sunucu, yeterli miktarda disk ve Thunderbolt portları ile de S2D yapısı kurmak mümkün.
Yapımızın kurmak adına 2 adet VM kurduk, her VM’e işletim sistemi diski dışında 3 adet data disk ekledik. Minimum 2 adet data diski ile de ortamınızı kurabilirsiniz. Ortamda iki sunucu olduğu için yedeklilik seçeneği olarak Two Way Mirroring’i seçeceğiz. Bu da bize makinelerden birinin veya 1 diskin ulaşılamaz hale geldiğinde veri kaybı/kesinti olmayacağı ve toplam disk kapasitesinin yarısını kullanabileceğimiz anlamına geliyor.
Burada Windows Server 2019’a özel ufak bir parantez açmamız gerekiyor. Zira 2 host makine bulunan kurulumlarda 2019 öncesinde sadece Two Way Mirroring kullanabiliyorduk; fakat 2019 ile beraber Nested Resiliency özelliği de geldi. Bu özelliğin kendi içerisinde sunduğu iki opsiyondan da kısaca bahsedelim.
Nested two-way mirror opsiyonu yazma işlemlerini bütün disklere aynı anda, okuma işlemlerini ise herhangi bir kopyadan gerçekleştirerek standart two way mirroring’e göre daha fazla performans sunuyor. Performans artışı sonucunda kapasiteden feragat etmek zorunda kalıyoruz; zira kapasite verimliği ise yüzde 25 oranında; yani 1 TB kullanılabilir alan için 4 TB depolama alanına ihtiyaç duyuyoruz.
Nested mirror-accelerated parity opsiyonu ise daha fazla kapasite verimliliği sunmayı hedefliyor ve her host makinede kullanılan disk adedi ve kapasitesine göre yüzde 35-40 arasında kapasite verimliliği sunuyor.
Dikkat ederseniz bu iki esneklik seçeneği de kapasite verimliliği söz konusu olduğunda Two Way Mirroring’den çok da farklı değiller. Yüzde 40’a kadar verimliliği sunan opsiyonu kullandığınızda hem depolama tarafında daha yüksek erişilebilirlik hem de hatırı sayılır bir performans artışı sağlamış oluyorsunuz. Ayrıca aynı cluster içerisinde oluşturduğunuz farklı disk bölümleri (volume) için farklı esneklik opsiyonları kullanabiliyorsunuz; yani bir bölüm için Nested two-way mirror, diğeri için nested mirror-accelerated parity kullanabiliyorsunuz.
Bu kısa bilgiden sonra konumuza kaldığımız yerden devam edelim. Sanal makine boyutu seçimi S2D için önemli, çünkü bir makinenin destekleyeceği maksimum IOPS miktarı vardır. İşletim sistemi diski dahil takacağınız tüm diğer disklerin IOPS’larının toplamı makinenin desteklediği IOPS’u geçmemeli ki disklerden tam performans alabilesiniz. Bu bir test ortamı olduğu için Azure portaldan 2 vCPU, 8 GB RAM’e sahip, B serisi iki adet makine açalım ve işletim sistemi olarak Windows Server 2019 Datacenter Core seçelim. Sunucumuz bir depolama havuzu olacağı için Desktop Experience arayüz paketine ihtiyacımız yok. Kurulum ve konfigürasyon işlemlerinin neredeyse tamamını client makineden, remote powershell ile yapacağız.
Bir sonraki aşamada kullanacağımız ek diskleri sanal makinemize ekleyelim. 128 GB kapasiteli 3 adet Standard HDD tipinde disk seçiyoruz.
Sonraki aşamaları ortamınıza göre seçin. RDP portunu açmayı unutmayın zira Server Core kullandığımız için domain’e dahil etme gibi ilk işlemleri RDP ile yapacağız. Bütün kurulumlarınız bittikten sonra da bu portu public erişime kapatmayı unutmayın.
Her iki sunucu da kurulduktan sonra sunucuları domain’e dahil etmemiz gerekiyor; S2D workgroup ortamlarını desteklemiyor. Sunucularımıza public IP’lerinden RDP ile erişip oturum açalım.
Oturum açtığınızda sizi boş bir komut satırı karşılayacaktır. “sconfig” komutu ile sunucumuzun temel konfigürasyonunu yapacağımız script’i çalıştıralım.
Gördüğünüz gibi birçok temel işlemi numaralarını yazıp Enter’a basarak yapabiliyoruz. Biz sadece makineleri domain’e alacağımız için 1’i seçelim. Sonraki aşamalarda sizden istenen bilgileri girdikten sonra 13 seçeneği ile makineyi yeniden başlatalım.
Her iki makineyi de domain’e dahil ettikten sonra aynı domain’e dahil olan bir client makineye geçip remote powershell ile sunucularımıza bağlanalım. Bunun için powershell açıp aşağıdaki komutu girmeniz yeterli:
Enter-PSSession -ComputerName <bilgisayar_adı> -Credential <domain\kullanıcı_adı>
Makine ismi ve kullanıcı adına kendi bilgilerinizi yazdıktan sonra bağlantıyı kurmuş olacaksınız. Aynı işlemi ikinci makine için ayrı bir powershell penceresinde de yapalım.
Sonrasında makineye takılı diskleri görüntülemek için Get-Disk komutunu girelim:
Gördüğünüz gibi “Msft Virtual Disk” olarak adlandırılan 3 diskimiz henüz başlatılmış durumda değil; zira partition style “RAW” olarak gözüküyor. “Initialize-Disk -Number […]” komutunu girerek sırayla disklerimizi başlatalım. […] yerine disk numarasını yazacağız.
Bu işlemden sonra SOFS (Scale-Out File Server) ve S2D için gerekli özellikleri şu komutla kuralım:
Install-WindowsFeature -Name “Failover-Clustering”, “FS-FileServer”, ”RSAT-Clustering-Powershell”
Azure’da S2D ve SOFS kuracaksak bu komutlar yeterli. Şayet on-premise ortamda bir sanallaştırma altyapısı ile beraber fiziksel donanımın üzerine kuracak olursanız şu komutla gerekli özellikleri kurabilirsiniz:
Install-WindowsFeature -Name “Hyper-V”, “Failover-Clustering”, “Data-Center-Bridging”, “RSAT-Clustering-PowerShell”, “Hyper-V-PowerShell”, “FS-FileServer”
Her iki sunucuda da kurulumlar bittikten sonra Failover Cluster’ımızı oluşturmaya başlayabiliriz. Bu aşamadan sonraki komutları cluster node’larının birinde çalıştırmanız yeterli.
Aşağıdaki komut ile cluster’ımızı oluşturalım:
New-Cluster -Name <cluster_ismi> -Node <node_1,node_2,…node_n> -NoStorage
Daha önceki Azure’da ADFS ortamı kurulumunu anlattığım makalemde bahsettiğim özel durum burada da geçerli. Windows Server 2019 ile beraber Azure’da Failover Cluster kurduğunuzda Cluster IP’si ve buna bağlı bir Load Balancer objesi oluşturmanıza gerek yok. Windows Server 2019, cluster’ın Azure sanal makinesinde kurulduğunu algılayıp bu Cluster IP’si yerine “Distributed Network Name” objesi oluşturur ve bu obje için AD DNS’te cluster node adedince A kaydı oluşturur. Bu A kayıtlarının her biri cluster node’larının IP adresine işaret eder. Sizde bu makaledeki adımları uyguladığınızda aynısı olacaktır. Benim DNS panelimden örnek vermek gerekirse durum böyle gözükecektir.
Cluster’ımızı oluşturduktan sonra Storage Space Direct özelliğini aktif hal getirmemiz gerekiyor. Bu işlem için aşağıdaki komutu girelim:
Enable-ClusterS2D
Komut, işlemini bitirdikten sonra ekranda gözüken “no disks found to be used for cache” uyarısını dikkate almayın. Uyarıda cache (ön bellek) için disk bulunamadığını söylüyor. Azure ortamında olduğumuz için normal, şayet fiziksel ortamda kuruyor olsaydık SSD sürücülerimizi cache için konfigüre etmiş olacaktı.
Aşağıdaki komut ile depolama havuzumuzu oluşturalım:
Get-StorageSubSystem *cluster* | New-StoragePool -FriendlyName <depolama_havuzu_ismi> -WriteCacheSizeDefault 0 -ProvisioningTypeDefault Fixed -ResiliencySettingNameDefault Mirror -PhysicalDisks (Get-PhysicalDisk | ? CanPool -EQ $true)
Bu komut ile “Mirror” yedeklilik tipini kullanan bir havuz oluşturmuş olduk. Fiziksel disk kapasitemiz 761.99 GB gözüküyor fakat bu havuzda bir disk bölümü (volume) oluşturduğumuzda en fazla yarısı kadarını kullanabileceğiz.
Aşağıdaki komutla maksimum büyüklükte bir disk bölümü oluşturalım. Şayet farklı boyutlarda bölümler oluşturacaksanız “UseMaxSize” parametresini kaldırıp yerine -Size …GB” yazarak istediğiniz boyutu belirtebilirsiniz. Dosya sistemi olarak ReFS kullandık, zira Microsoft S2D bölümleri için bu dosya sistemini tavsiye ediyor .
New-Volume -StoragePoolFriendlyName S2DPool -FriendlyName <bölüm_ismi> -PhysicalDiskRedundancy 1 -FileSystem CSVFS_ReFS -UseMaxSize
Client makinemizde yüklü olan Failover Cluster Manager’dan kontrol ettiğimizde depolama havuzumuzu ve disk bölümümüzü görebiliyoruz.
Cluster storage’imiz hazır olduğuna göre üzerinde Scale-Out File Server (SOFS) hizmetini konumlandırabiliriz.
SOFS kurmak için gerekli komuta özel bir durum var. Bu komutu remote powershell çalıştırmak için öncesinde sunucuda CredSSP kimlik doğrulama yönteminin konfigüre edilmiş olması gerekiyor. Bunu konfigüre etmek makalenin konusunun dışında olduğu için bu komutu node’lardan birine RDP ile bağlanıp lokalde powershell ile çalıştıralım. Bağlandığınızda cmd’den powershell’e geçmek için “powershell” yazmanız yeterli.
Add-ClusterScaleOutFileServerRole -Name “servis_ismi”
Bu işlemden sonra Cluster Manager’a baktığımızda Scale-Out File Server rolünün eklendiğini teyit edebiliriz. Bu işlem dışında sunucuya RDP ile bağlanmamıza gerek olmayacak. Dolayısıyla tekrar remote powershell’e dönebiliriz.
Bu işlemden sonra AD DNS panelini açıp SOFS için kullandığımız DNS ismine karşılık 2 adet A kaydı açacağız ve bu kayıtlar node’ların IP adreslerine işaret edecek. Kendi DNS panelimde kayıtlar şu şekilde gözüküyor:
SOFS üzerinde bir test paylaşımı oluşturmadan önce Cluster için Quorum oluşturmamız gerek. Yapımız Azure’da konumlandığından bu iş için Cloud Witness kullanmak maliyet ve yüksek erişilebilirlik konusundan en mantıklısı oluyor. Azure panelden bir storage account oluşturalım, account name ve access key’i bir kenara not edelim. Cloud Witness oluşturmak için node’lardan birinde powershell üzerinden şu komutu girelim.
Set-ClusterQuorum -CloudWitness -AccountName <storage_account_ismi> -AccessKey <access_key>
Bu komutu da girdikten sonra cloud witness’i Failover Cluster Manager’da göreceğiz.
Artık SOFS üzerinde bir paylaşım oluşturabilir ve yetkilendirme yapabiliriz. Test için “Paylasim” adında bir klasör ve paylaşım oluşturacağım ve AD’de daha önceden açtığım “Paylasim” isimli güvenlik grubuna bu paylaşımda tam yetki vereceğim.
cd komutu ile ClusterStorage\Volume1 dizininin altına gelelim ve klasörümüzü açalım:
New-Item -Name <klasör_ismi> -ItemType Directory
New-SmbShare -Name <paylaşım_ismi> -Path C:\ClusterStorage\Volume1\Paylasim -FullAccess <domain_ismi\kullanıcı_veya_grup>
Set-SmbPathAcl <paylaşım_ismi>
Aşağıdaki resimde gördüğümüz gibi paylaşımımız hazır, hatta içerisine dosya dahi attık.
Bu makalede elimden geldiğince Azure’da yüksek erişilebilir, S2D üzerine konumlandırılmış bir Scale-Out File Server kurulum ve konfigürasyonunu anlatmaya çalıştım. Bir sonraki makalede görüşmekaa üzere.
Kaynaklar:
https://docs.microsoft.com/en-us/windows-server/failover-clustering/create-failover-cluster
https://docs.microsoft.com/en-us/windows-server/storage/storage-spaces/deploy-storage-spaces-direct
https://docs.microsoft.com/en-us/windows-server/storage/storage-spaces/nested-resiliency
https://docs.microsoft.com/en-us/windows-server/failover-clustering/deploy-cloud-witness