IBM HyperSwap Cluster – Load Balancing

Merhaba

Cluster mimarilerde yük dağılımını efektif yapmak için dikkat edilmesi gereken bir durum var.

Bilindiği üzere HyperSwap lokasyon yedekliliği sağlayan, bir sistem odasındaki cihaz (site) bozulduğunda sistemi diğer taraftan (site) kesintisiz çalıştırmak için tasarlanmış bir mimari. Her cihaz üzerinde 2 adet node, toplamda minimum 4 adet node’la bu mimari kurulabiliyor.

Burada esas kritik nokta iki storage’in de aktif çalışabilir olması. Yani bir cihaz tam performans çalışırken diğerinin boşta yatmaması lazım.

PR-V7000 = node1, node2
BC-V7000 = node3, node4

Bunu kontrol edebilmek için 8.1 firmware’i ile gelen yeni dashboard ekranını açıyoruz.

beforesite

Yükün görsel olarak incelenebildiği Node Comparison ekranında sadece Primary V7000 üzerindeki node1 ve node2’nin kullanıldığını görüyoruz. node3 ve node4 tamamen boşta yatıyor.

Bunun sebebi ise Host’ların “Site” bilgisi girilirken sadece tek bir site üzerindeymiş gibi tanımlanması.

hosts.jpg

Üstteki ekran görüntüsünde BC_ESX hostlara bile “Site” olarak PR-V7000’i kullan dediğimiz için yük dağılımı yayılmıyor. Bu yüzden BC_ESX hostların site bilgisini BC-V7000 olarak değiştiriyoruz.

hostsite.jpg

hosts2

Değişiklik sonrası BC host’lar artık BC_V7000 cihazını kullanacaklar. Bu değişiklik sonrası ise yük dağılımını izlemek için Dashboard altındaki Node Comparison’u tekrar açıyoruz.

v7000 load balance

Artık tüm node’lar ESX host’lar tarafından kullanılıp yük dağılımı yapılabiliyor. Bunun IOPS’a olan faydasını test etmedim ama storage vmotion kullanarak yaptığım taşımalarda süre epey kısaldı. Mutlaka IOPS konusunda da kayda değer artışlar olmuştur.

Reklamlar

Depolama mimarisini sağlamlaştırmak için yapılması gerekenler

Öncelikle bu konuyu açıklayabilmek için iki terimi tanımlamamız gerekiyor.

1-URE/NRE nedir? Uncorrectable/Nonrecoverable Read Error (Düzeltilemeyen/Kurtarılamayan Okuma Hatası)

2- BER nedir? Bit Error Rate (Okuma başına hata oranı)

Bu durumu bad sector ile karıştırmamak gerekiyor. Çünkü URE sadece RAID mimarilerde yaşanıyor.

8 diskten oluşan RAID5 mimaride 7 data diski, 1 parity diski bulunur. Bu 8 diskten biri arızalandığında parity blokları 9. slot’ta boşta duran yedek diske taşınır. İşte tam bu sırada parity blokları arasında yer alan ve yedek diske kopyalanması gereken veri bu ihtimal nedeniyle okunamayabilir. Bu duruma URE deniyor. Bu kötü tesadüfe yakalanmış fakat haberi olmayanlar bu yazıyı okuduktan sonra neden RAID5 array’deki 1 disk arızasında RAID’in bozulduğunu anlayabilirler. Çünkü 2. disk bozulmamasına rağmen okunamayan sektördeki bit nedeniyle array kurtarılamadı. Bu okunamama ihtimaline de Bit Error Rate (BER) deniyor.

Depolama ünitelerinde kullandığımız disklerin her okuma başına BER oranı var. Bu  oran disklerin üretimi sırasında disk üreticisi tarafından belirtilen bir kalite seviyesi. Giriş seviyesi disklerde bu oran daha yüksek, pahalı disklerde daha düşük. Alttaki tabloda görülebilir.

Medya tipiOkuma başına Bit Error Rate
Optik sürücü (Blue-Ray/DVD)1 üzeri 13
Tüketici HDD (PC/Laptops)1 üzeri 14
Kurumsal HDD 15k/10k/7200 rpm1 üzeri 16
Solid-State ve Flash1 üzeri 17
LTO-7 Teyp1 üzeri 19
IBM TS1150 Teyp1 üzeri 20

Burada belirtilmeyen noktalardan biri ise çoğu storage üreticisi disklerini Hitachi, Seagate, WD gibi firmalara yaptırdığı için aslında çoğu üründe 1 üzeri 15 hata oranına sahip diskler kullanılıyor. Storage üreticisinin disklerindeki üretici kodunu internette aratarak bu bilgiye ulaşabilirsiniz. Çoğu NAS cihazında kullanılan disklerin 1^15 olduğunu net olarak söyleyebilirim.

Alttaki tabloda olasılık hesapları yapılmış oranlar var. Tablo 8 diskten oluşan RAID5 ve RAID6 mimarilerde bu hataya yakalanma ihtimalinizi gösteriyor.

Disk TipiBER İhtimaliDisk AdetiRAID Array GBRAID5 URE OranıRAID6 URE Oranı
6 TB Tüketici SATA1^14848.000%980,39
6TB Orta Seviye SATA/NSAS1^15848.000%32,50,13
6TB Kurumsal NSAS1^16848.000%40,0163
600 GB SAS1^1684.800%0,30,00008

Öncelikle disk kapasitesi arttıkça RAID array kapasiteside arttığı için bu hataya yakalanma ihtimaliniz artıyor. Çünkü bir disk arızasında okunacak disk sektörü arttığı için ihtimaller yükseliyor. Bu yüzden yüksek kapasiteli diskler satın alırken diskin üretim detaylarındaki bu detaya dikkat etmek gerekiyor. 600 GB’lık SAS ile 6 TB Kurumsal NSAS 1^16 BER ihtimaline sahipken 600 GB’lık array daha küçük olduğu için URE ihtimali azalıyor.

Gördüğünüz gibi  1^14 disklerde RAID5 array’de bir disk arızasında %98 ihtimalle okunamayan bit’e denk geleceksiniz. 1^15 disklerde de bu oran %32.5’e düşmüş.

İkinci olarak da RAID5 array’de 6 TB Kurumsal diskler %4 hata oranına sahipken RAID6 array’de ise %0.01 gibi ufak bir orana düşüyor. Çünkü 2 adet parity diski olduğu için bir diskten okuyamazsa bile diğer parity diskinden bu veriyi okuma ihtimali var. O yüzden şansımız yükseliyor. Dolayısıyla ucuz disk veya pahalı farketmez yeni oluşturduğumuz array’leri RAID6 olarak oluşturmakta fayda var.

Bu veriler belki yıllarca depolama ünitesinde saklanacak ve devlet tarafından sizin için yasal bir zorunluluk haline getirilecek. O yüzden kapasite hesabına girip 1 disk kaybetmemek için güvenlikten feragat etmek size sonrasında çok pahalıya mal olabilir. Her zaman yeni disk ilavesi yapılabilir ama giden verinizi geriye getirmek ancak şanslıysanız mümkün olabiliyor. RAID array offline olduğu için sistem duracağından  kimsenin çalışamaması da ayrı bir dert.

Bu yüzden RAID6 haricinde satın aldığınız depolama ünitesi ve onun üzerine takılan diskleri de detaylıca incelemek gerekiyor. Ayrıca sürekli yedek almak da bu durumun etkilerini azaltmak için önemli.

Okuduğunuz için teşekkürler…

IBM Storwize Deduplication & Data Reduction Pools – Derinlemesine İnceleme

Herkese Merhaba

Sonunda Storwize’a 8.1 güncellemesi ile birlikte tekilleştirme geldi ve ücretsiz. Hybrid storage serisinden V5030 ve V7000’de bu özellik yer alıyor. Dosbil Bilgisayar test merkezinde yeni gelen özelliği derinlemesine inceledik.

8.1 versiyonu çıkalı epey oldu fakat Deduplication’ın menüden seçilebilmesi 8.1.3.x ile mümkün olabiliyor. Dolayısıyla 8.1.3.x altında bir sürüm kullanıyorsanız bu özelliği açamamanız olası.

8.1.3.x kullansanız bile storage ilk yapılandırırken Pool oluşturma kısmında Data Reduction seçeneğini işaretlemediyseniz Deduplication veya Thin Reclaimation özelliğini kullanmak mümkün değil.

create pool

IBM tekilleştirmeyi neden bu kadar geç getirdi?

Yazılan veriler 32KB‘lik block’larla işlediği için standart disk havuzu (pool) tekilleştirme gibi alan kazanımı sağlayan teknolojiler için uygun değildi. Çünkü veri 8KB‘lik block’larla yazıldığında çok daha iyi tekilleşiyor ve kontroller ünitesini çok daha az yoruyor. IBM’in bu kriteri değiştirmesi, petabyte’larca cluster’lara sahip müşterileri için pek mümkün gözükmüyordu. Dolayısıyla standart disk havuzunun yanında “Data Reduction Pool” eklenerek tamamen yeni mimaride bir disk havuzu getirildi. Yazının geri kalanında kısaltma için DRP yazacağım.

Aradaki büyüklük farkını şöyle belirtebilirim: Storwize’da oluşturulabilecek;
Max Standart Pool adeti: 1024
Max DRPool adeti: 4

Max Standart Raid Array: 4096
Max DRP Raid Array: 128

O yüzden DRP tamamen yeni bir disk havuzu mimarisi ve aktif iş yüklerinde tekilleştirme açılamaz. Boş yeri çok olan veya HyperSwap cluster mimariler, diğer site üzerindeki standart pool’u silip DRP oluşturarak ve bolca storage vmotion ile taşıma yaparak bu mimariye online geçebilirler.

Altta görüldüğü gibi SAS diskler standart, SSD’ler ise DRP.

pools

DRP oluşturduktan sonra volume oluştururken Thin Provision seçildiğinde “automatic space reclaimation/SCSI Unmap” özelliği açık geliyor. Eğer siz buna ilave olarak diğer yer kazanımı teknolojilerinden Compression veya Deduplication isterseniz açabiliyorsunuz.

create volume

Volume performansını tam olarak test edebilmek için 4 farklı tipte de volume oluşturduk. Bunu yapmaktaki amaç ise volume tipinden bağımsız olarak alabileceğimiz performansı ve tekilleştirmeyi gözlemleyebilmekti.

DRAID6_SSD_TVOL: Thin
DRAID6_SSD_TDVOL: Thin + Deduplicated
DRAID6_SSD_CVOL: Thin + Compressed
DRAID6_SSD_CDVOL: Thin + Compressed + Deduplicated

volumes

Thin Dedup ve Compress Dedup volume’lerine her birine onar adet Windows 2016 Server ISO’su kopyaladık. Bu ISO’ların her biri 5.5 GB.

isolar
Burada dikkat etmemiz gereken nokta ise volume tiplerinin birbirinden farklı olması. Volume’lerden birinde sadece dedup açık, diğerinde ise compression+dedup açık. Dolayısıyla storage üzerinde olan ama farklı tip volume’lerde olan bu verinin tekilleştirileceği benim için merak konusuydu.

Altta görüldüğü üzere toplamda 106 GB yer kaplaması gereken 20 adet ISO dosyası tekilleştirilerek 98 GB yer kazanımı sağlanmış. Yani sadece 8 GB‘lık bir yer kaplıyor volume üzerinde.

20 iso deduplication

Performans Testi:

İşin yer kazanımı konusu sorunsuz fakat performans konusunda da şüphelerim vardı. Bu volume’lerin tamamının IOPS performansını test ettik.

Test Server: Lenovo SR650, 2 x Xeon Silver 4110 – 48 GB Ram
Vmware ESX 6.5.0 Update 1 (Build 7388607)
Test VM: Windows 2016 Server, 1×8 CPU, 24 GB Ram
Test Storage: IBM V5030 – 9×1.96 TB SSD – Distributed RAID6

Altta test sonuçlarının parametrelerini ve detaylarını inceleyebilirsiniz.

                          8k yazma / 8k okuma
Thin Volume: 68.000 / 95.510
Thin+Dedup: 91.020 / 143.050
Compressed: 70.820 / 98.500
Comp+Dedup: 72.820 / 88.780

Compression + Deduplication’ın ikisinin birden aktif edilmesi doğal olarak okumada IOPS kaybına neden oluyor.
Thin Dedup’ın da bu kadar yüksek IOPS’lara çıkması gelen verinin henüz daha diske yazılmadan cache’de tekilleştirilmesinden kaynaklanıyor. Controller sıkıştırmayla uğraşmadığı için IOPS epey yükselmiş.

Kısacası tüm volume tiplerinde 8K IO büyüklüğü ile 68.000 IO üzerinde performans alınabiliyor. Bu da çoğu iş yükü için yeterli bir performans.

tvol

tdvol

cvol

cdvol

NVMe™ ve NVMe™ over Fabrics Nedir?

NVMe™, 30 yıllık SCSI ve SAS arabiriminin yerini almayı hedefleyen bir teknoloji. Yapılan testlerden sonra ortaya çıkan değerler sonrasında açıkçası artık bu işin geri dönüşü yok. Storage Admin’lerinin bildiği terimlerin bir çoğu değişecek.

NVMe™ neden ortaya çıktı?

SAS ve SATA teknolojileri hem ağır komut setlerine hem de düşük mesaj kuyruklarına sahip olduğundan gelen komutlar aynı anda işlenemediği için gecikme oluşuyordu.

SATA’da her mesaj kuyruğunda 32 komut seti, SAS’da her mesaj kuyruğunda 256 komut seti işlenebilirken NVMe™’de bu rakam 65.535.

Dolayısıyla flash tabanlı depolama birimleri gayet hızlı olmasına rağmen aradaki mesaj komutları maksimum 256 adet işlenebildiği için sistemdeki darboğaz burada oluşuyordu.Bu yüzden SSD diskler daha hızlı çalışabilmesi mümkün olduğu halde SCSI/SAS teknolojisi yüzünden yavaş çalışıyordu.

Diğer yandan NVMe™ komut seti çok daha hafif bir koda sahip olduğu için SCSI komut setine nazaran %50 daha az CPU tüketiyor ve düşük gecikmeye de sahip.

Bunu şuna benzetebiliriz; fabrikamızda çıkan ürünleri ayıran robotlar var ve bu robotun 256 adet kolu var. Dolayısıyla 1 dakika içinde 256 adet ürünü ayırıp ilgili yerlere yerleştirebiliyor. Bunu yaparken de makinanın işlem gücünün %100‘ünü kullanıyor.

Bu robot kolunun 65.535’e çıkarıldığını ve tükettiği gücün de %50 azaldığını düşünün.

NVMe™ depolama birimini evimizdeki PC’ye veya ofisimizdeki sunucuya da taksak performans iyileştirme mantığı buradan geliyor.

NVMe™ over Fabrics nedir?

NVMe™ bir PC üstündeki memory ile depolama alanını birbiriyle hızlı görüştürmek için yeterli bir teknoloji. Fakat iş birden fazla sunucuyu birbirlerinin memory’sine hızlı ulaştırmaya geldiğinde o zaman araya bir arabirim sokmak zorundayız. Bunun adına da NVMe™ over Fabrics deniyor. Fabrics birden fazla arabirimi içine almış bir şemsiye konumunda. Bu arabirimler ise;

Fibre Channel, InfiniBand, RoCE, iWarp, TCP(geliştiriliyor)

Bu arabirimlerin tamamı NVMe desteğine sahip veya ileride sadece bir firmware güncellemesi ile sahip olacak.

slide7_029

Bir sunucu üzerindeki veriyi storage’lere hızlı iletmek ve veriyi storage’den memory’ye hızlı almak istiyorsak kullanılan arabirim NVMe™ over Fibre Channel.

Fakat amacımız veri analitiği veya yüksek performans gerektiren işlemler (süper bilgisayarlar), dolayısıyla tüm sunucular üzerindeki memory’lerin diğer sunucular tarafından işlenebilmesini istiyorsak RDMA tabanlı diğer alt arabirimlere ihtiyaç duyuluyor. (RoCE, iWarp, InfiniBand)

Ethernet platformundaki hızlar (RoCE, iWarp) artmasına rağmen Fibre Channel üzerindeki kayıpsız, tahmin edilebilen ve tutarlı veri aktarımı nedeniyle iş kritik (mission-critical) uygulamaların Fibre Channel üzerinde kalacağına kesin gözle bakılıyor. O yüzden NVMe™ over Fabrics teknolojisini bu arabirimler üzerinden birbirlerinin önünü kesecek bir teknoloji gibi düşünmemek lazım. Her arabirimin kullanım amacı ve isteklere cevap verdiği alan farklı.

SAN Fibre Channel switchlerde aynı ASIC chip ile FICON, FCP(SCSI) ve NVMe™ veri transferi yapılabiliyor, ekstra bir donanım ihtiyacına gerek yok. Eğer şuanda sisteminizde bulunan fibre host bus adapter GEN6, SAN Switch GEN6 ve depolama ünitesi NVMe™ over Fabrics destekliyor ise veri trafiği arabirimi olarak sistem otomatik olarak fibre yerine NVMe™’i seçiyor.

Performans karşılaştırması olarak bakıldığında ise 12Gbit SAS arabirimli SSD’lere kıyasla;

100% rastgele okuma, NVMe 3x daha fazla IOPS,
70% rastgele okuma, NVMe 2x daha fazla IOPS,
100% rastgele yazma, NVMe 1.5x fazla IOPS,
100% okuma: NVMe 2x daha hızlı,
100% yazma: NVMe 2.5x daha hızlı.

Bu arabirimin en güzel faydası da Host üzerindeki CPU yükünü azaltması.

Linkte IBM’in bu konuda yaptığı bir demo mevcut.
Linux bir sunucuda ilk önce SCSI arabirimi ile IO testi yapılıyor ve test sırasında CPU kullanımı ölçülüyor. 65.000 IOPS ve %26 CPU kullanımı

Aynı sunucular üzerinde ve aynı donanımla NVMe arabirimi seçildiğinde ise 65.000 IOPS’un CPU kullanımı %12!

NVMe sayesinde sadece storage’dan alacağımız performans artmadığı gibi hostların CPU kullanımlarında da %50’ye varan düşüşler olacak.

latency.jpg

Üstteki resimde de depolama tiplerinin gecikmeleri yer alıyor. NVMe SCM SSD’ler NAND ve SAS arabirimli SSD’lere nazaran çok daha az gecikmeye sahip.

vocabulary

Üstteki tabloda gözüktüğü gibi yeni teknolojinin gündeme gelmesiyle tabiki bazı isimler de değişecek.

Çoğu storage üreticisinin NVMe™ over Fabrics destekleyen storage’ları yolda, hatta bazılarının satışta bile. Hız gereksinimi olduğunda açıkçası ilerleyen süreçte SCSI arabirimi kullanılmayacak. Ama iş kapasiteye geldiğinde maliyet faktörü göz önüne alındığında SCSI tabanlı en son çıkan 12 TB diskler kullanılmaya devam edecektir.

Traditional RAID vs Distributed RAID

Her sistem yöneticisinin elinin altında ama iyi ama kötü storage’ler (NAS, SAN), her storage’e de takılı diskler var. Bu diskler üzerinde oluşturulmuş da bir RAID yapısı mevcut.

Örneğin: 6 disklik RAID5  (4 data disk, 1 parity disk, 1 spare disk)

Bu disklerin de bir gün arızalanacağı gün gibi açık… Arıza durumunda arızalı diskin (failed disk) içindeki veriler eşitleme diskinden (parity disk) okunmaya başlar ve bu andan itibaren sistem parity disk üzerinden çalışmaya devam eder. Aynı zamanda sistemimizdeki yedek diske (spare disk) de parity diskinden veriler kopyalanmaya başlar. Dolayısıyla parity disk üzerine acayip bir yük biner. Fakat kimsenin pek de bahsetmediği bu operasyonun ne kadar süreceği?

Alttaki tabloda disk kapasiteleri ve arıza durumunda rebuild işleminin % kaç IO harcaması istediği belirtilerek spare diskin aktif edilme süresi belirtiliyor. Görüldüğü üzere 8 TB’lık bir disk arızalandığında geleneksel raid’de spare diskin devreye girme süresi 35 saat olarak belirtilmiş.

distributedraid

Açıkçası o 35 saatlik sürede parity disk üzerine binen bu yük nedeniyle o diskin de arızalanması gayet mümkün. RAID6 kullarak çift parity diskine sahip olabilirsiniz ama bu sefer de performans çok düşük olacak. RAID10 kullanarak kendinizi hız ve güvenlik açısından garantiye alabilirsiniz ama bu sefer de kapasiteden feragat etmeniz gerekecek. Bunun farklı bir çözümü daha var.

IBM, Huawei, HP gibi markalarda farklı isimlerde yer alan çok da yeni olmayan bir RAID teknolojisi: IBM’de Distributed RAID olarak geçiyor.

Spare disk için ayrı fiziksel disk ayırmaktansa o disk kapasitesini sistem içerisindeki bütün data disk’lerine yayıyor. Örneğin 6 disklik bir yapıda bir disk arızalandığında sadece parity blokları geri kalan 5 diskteki spare bloklarına aktarılıyor.

draid_04

Böylece sistem tek bir disk üzerinden çalışmak yerine o veri bloklarını 5 diskten okuyarak diski yormuyor.

4 TB’lık diskin geleneksel RAID ile %50 yükte 24 saatte devreye alındığı biliniyor Distributed RAID ile bu süre 3 saate düşmüş durumda.

Bir diğer avantajı da tüm diskler veri yazma ve okumada kullanıldığı için %5 ila %10 arası performans artışı sağlıyor.

Örneğin Huawei Storage’lerde zaten zorunlu bu teknoloji kullanılıyor fakat IBM’de kullanıcı seçebiliyor. İlerleyen süreçte tüm storage üreticileri buna geçecek ve bence geleneksel RAID hiç kullanılmayacak.

Vmware ESX üzerinde Database Sanallaştırma (SQL, Oracle)

Veritabanı sunucularında özellikle yazılımcıların yönlendirmesi nedeniyle sanallaştırmaya karşı olumsuz bir görüş vardır. Hatta yazılımcının yazdığı yazılımın veritabanı ve uygulama geliştirme platformu sanallaştırma ile ilgili uyumluluk makaleleri yazsa bile yazılımcı kişi/firma sanallaştırma önermiyoruz diyebilecek kadar ileri gidebiliyor.

Fiziksel sunucu tabiki sanallaştırılmış sunucudan biraz daha hızlı ama bu fark küçük ve orta ölçekli işletmeler için tolere edilebilir. O yüzden sanallaştırmanın getirdiği diğer avantajlar kesinlikle performans farkından daha önemli. Tabi sanallaştırılmış ortamlarda da bu yapıyı düzgün kullanabilmek için yapılması gereken birkaç ipucu var. Oracle ve MsSQL ile ilgili makaleleri derleyerek size yapılması gereken adımları açıklamak istiyorum. Altta belirtilen ayarlar her iki veritabanı için de geçerlidir. Sadece yapılması gereken adımları ufak açıklamalarla belirttim. Detaylı açıklama isteyenler alttaki linklerden indirip inceleyebilirler, kesinlikle öneririm.

SQL: http://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/solutions/sql-server-on-vmware-best-practices-guide.pdf
Oracle: http://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/solutions/vmware-oracle-databases-on-vmware-best-practices-guide.pdf

BIOS UEFI Ayarları

-İşlemcilerin tüm C durumları kapatılmalı (C1E Hata durumu dahil): C-State işlemcinin güç tasarrufu yaptığı durumdur. İşlemci kendini beklemeye aldığı için bu bekleme durumundan dönerken gecikmeye yol açar. Linkte hangi C durumunun hangi işe yaradığı açıklanmış. Hepsinin kapatılması kesinlikle öneriliyor.
-Mümkün olan en son firmware seviyesi kullanılmalı.
-Turbo Boost etkinleştirilmeli.
-Hyper-Threading etkinleştirilmeli.
-Gelişmiş CPU ayarları etkinleştirilmeli (VT-x/AMD-V, EPT, RVI)
-Sunucunun güç ayarları İşletim sistemi kontrol edecek şekilde ayarlanmalı (OS Controlled)

ESX ve VM Güç Ayarları
-ESX Ayarlarındaki güç seçeneği High Performance olarak ayarlanmalı
-DB sanal makinesinin Windows/Linux güç ayarları High Performance olarak ayarlanmalı.

VM İşlemci Ayarları
-Pek çok kişi sanal makinaya atadığı vCPU ve vCore arasındaki farkı bilmiyor. Örneğin SQL Server 2016 Standart Edition maksimum 4 vCPU ve maksimum 24 vCore adresleyebilir.

Yani sanal makineye 6 vCPU, 4 vCore atadığınızda 24 core atadığınızı düşünüyorsunuz ama SQL 4 vCPU üzerindeki 4 çekirdeği çarparak 16 core’u işleyebiliyor. O yüzden bu kural çok önemli.

-Bunun haricinde vNUMA denilen hangi işlemci çekirdeğine hangi iş yükünün gideceğini belirleyen bir kriter de mevcut. Vsphere 6.5 ve sonrasını kullanıyorsanız bu konuda hiçbir şey yapmanıza gerek yok kendisi otomatik en iyisi neyse hesaplayıp onu uyguluyor. ESX 6.5’den öncesini kullanıyorsanız VM’lere CPU atarken alttaki şekilde yapmanız gerekli.

ESX host’taki fiziksel işlemci sayısı: 2
ESX host’taki fiziksel işlemcinin core sayısı: 12
DB sanal makinama verilmesi istenen core sayısı: 16
DB sanal makinam da girilmesi gereken CPU ayarı: 2 vCPU, 8 vCore.

Sanal makineye atayacağım core sayısı fiziksel core sayısından fazla olamaz! Fiziksel core sayısından fazla vermek istiyorsam vCPU çarpanını arttırmam ve core sayısını düşürmem gerekli. Eğer DB sunucumuza 12 core’luk bir kaynak atamak isteseydim 1 vCPU, 12 vCore vermem gerekiyordu.

CPU HotAdd/Plug özelliği devre dışı bırakılmalı: vNUMA’yı devre dışı bırakması nedeniyle işlemciye gidecek talepler düzgün işlenemediği için performans kaybı yaşatıyor. O yüzden bu özelliğin kesinlikle kapatılması isteniyor.

Sanal sunucuların işlemci istatistiklerinde de kaale alacağımız yer ESX’in göstergeleri olacak. Yapılan testlerde sanal sunucunun içinden %15 CPU kullandığını görsenize bile ESX bu değeri %25 olarak gösterebiliyor. Çünkü VM işlemciye veri gönderdiği anda diğer tüm sanal sunucuların performansını düşürüyor. Dolayısıyla ESX istatistikleri diğer sanal sunuculardan DB sanal sunucusuna kaymış işlemci gücünü de içerdiği için doğru veri ancak ESX üzerinden okunabiliyor.

VM Memory Ayarları
-Reserve all guest memory (All locked) işaretlenmeli
-Memory HotAdd tam olarak istenmese de çok iyi analiz edilen yapılarda etkileştirilebilir.

Sanal makinenin kullandığı rami ESX istatistiklerinden incelerken Active Memory istatistiği çok yanıltıcı olabiliyor. Database sunucularının ram erişimi ve cache’lemesi farklı olduğu için Active Memory istatistiği sanal sunucunun gerçekte ihtiyacı olduğu ram’i göstermiyor. Dolayısıyla DB sunucunuz ile ilgili performans analizi yapılacaksa bunu ESX yerine işletim sistemi içerisinden yapmak gerekli. 16 GB ram verilen sanal sunucuda Active Memory 2 GB gösterdiği halde veritabanınıza ram yetmiyor olabilir.

VM Depolama Ayarları
Oluşturulan VirtualDisk’ler Thick Provision Eager Zeroed ile oluşturulmalı. Thin Provision ve Lazy Zeroed’da ilk veri yazılmaya çalışıldığında storage üzerindeki alan talep edildiği için ufak bir yük biniyor. Eager Zeroed ile bu alan en baştan istendiği için bu yük binmiyor.

Sanal makine üzerinde OS, DB, LOG ve Backup Diski olmak üzere minimum 4 virtual disk oluşturulmalı ve bu 4 sanal disk farklı SCSI Controller’lar üzerinde çalışmalı. OS diski LSI Controller üzerinde çalıştırılabilir fakat diğer tüm disklerin Vmware Paravirtual SCSI Adapter üzerinde çalışması gerekiyor.

Paravirtual SCSI Adapter QueueDepth ayarı regedit’ten Windows Server maksimumu  olan 254 olarak ayarlanmalı
“HKLM\SYSTEM\CurrentControlSet\services\pvscsi\Parameters\Device /v DriverParameter /t REG_SZ /d “RequestRingPages=32,MaxQueueDepth=254”.

Depolama alanı olarak Raw Device Mapping ile storage üzerinden oluşturulan alanın direkt olarak sanal makineye map edildiği RDM diskler açıkçası eskisi kadar önerilmiyor. Çünkü bu konuda yapılan IO testlerinde Sequential 4k okuma testi haricinde arada nerdeyse hiçbir fark yok. Sequential 4k Okuma testinde de

RDM: 38.000 IOPS
VMFS: 35.000 IOPS

değeri sağlamış. %8’lik bir kayıp söz konusu. Bu testi 8k, 16k ile yaptıklarında neredeyse hiç fark yok.

Network Ayarları
VMXNET3 ayarı olan Receive Side Scaling etkinleştirilmeli
netsh interface tcp set global rss=enabled
Windows VMXNET adaptör ayarlarından enabled olarak seçilmeli.

Dökümanlarda NSX, VSAN, Virtual Volumes konularında da uygulanması gereken detaylardan bahsedilmiş fakat ben çok göz önünde olan ve kesinlikle heryerde uygulanması gereken net ayarlara dikkat çekmek istedim. Bu detayları uygulamak  her veritabanı sunucusu için kritik.

ReFS Dosya sistemi hakkında kritik bilgi

Merhabalar

Microsoft’un Windows 2016’da iyiden iyiye geliştirdiği dosya sistemi ile ilgili bir problem var ve Microsoft bu konuda bir patch yayınlayabilmiş değil.

ReFS özellikle backup almak için veya dosya sunucusu olarak kullanmak için mükemmel bir dosya sistemi fakat bu volume’ü oluştururken eğer Cluster size’ı 4K seçerseniz Windows 2016 memory hatası ile durduk yere kendini kilitliyor. Bu çözümün etrafından dolaşabilmek için cluster size’ı 64k seçebilirsiniz. 64K’da bu sorun yaşanmıyor fakat bu sefer de dosyalar %10 daha fazla yer kaplıyor. Muhtemel patch’in Mart ayında çıkması bekleniyor ama şuanda bu dosya sistemini kullanmak için mutlaka 64k seçilmeli.

Düzeltildi: https://support.microsoft.com/en-us/help/4016173/fix-heavy-memory-usage-in-refs-on-windows-server-2016-and-windows-10