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: 7 disklik RAID5  (5 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. Distributed Parity olarak da adlandırılıyor.

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

draid_04

Böylece sistem tek bir disk üzerinden çalışmak yerine o veri bloklarını 6 diskten okuyarak diski yormuyor.
Arızalı diski yenisiyle değiştirdiğimizde de yine aynı şekilde tek diskten okuyup tek diske yazmak yerine 6 diskten okuyup tek diske veriyi eşitliyor. Dolayısıyla hem arızanın ilk gerçekleştiği anda hem de daha sonrasındaki disk değişimi operasyonunda süreyi kısaltıyor.

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.

Reklamlar

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 256 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

VMware’den yeni patent başvurusu

Geçtiğimiz günlerde Vmware yeni bir patent başvurusunda bulundu. Muhtemelen ilerleyen sürümlerde VMware ESX’i non-distruptive upgrade yapabileceğiz. Her ne kadar Vmotion ile host’lar üzerindeki yükü kesintisiz taşıyabilme imkanı olsa da özellikle Linux VM’lerde bu taşıma esnasında kesintiler olabiliyor. Özellikle bazı yazılımların lisans kontrolünü yapan USB cihazlar nedeniyle de Vmotion kullanırken kesintiler yaşanabiliyor. Bu açıdan ESX çalışırken upgrade edilebilir olmasının çok işe yarayacağını düşünüyorum.

Vmware Converter Senkronizasyonu

Özellikle büyük boyutlu fiziksel sunucular veya kapatılması güç sunucular için Vmware Converter’daki senkronizasyon seçeneğini kullanmak gerekli.

Böylece saatlerce süren convert işleminin ardından sadece değişen block’lar aktarılarak sunucunun downtime süresi minimumda tutuluyor.

Bu süreçte dikkat edilecek birkaç nokta haricinde normal convert’ten pek bir farkı yok.
11
Öncelikle Advanced Options’dan ilgili seçeneği işaretliyoruz ve Perform final synchronization tickini kaldırıyoruz.

2

Convert işlemi bittikten sonra SQL, Exchange vb gibi servislerimizi durdurup anlık veri girişini engellememiz gerekiyor.

Daha sonrasında  Jobs bölümüne gelip ilgili göreve sağ tıkladıktan sonra Synchronize’e basıyoruz. Convert ekranı tekrar açılıyor fakat bu sefer Advanced Options’daki Perform final syncronization seçeneğini işaretlememiz gerekiyor. Böylece converter son defa sanal makinayı eşitleyip kapanışı gerçekleştiriyor.

Test olarak 400 GB’lık bir Exchange 2010 makinasını sanaldan sanala convert ettim. Convert işlemi kendi içinde olduğu için 1 saat gibi kısa sürede bitti. Normalde 400 GB’lık bi convert 2-3 saat civarı sürer. Herneyse; daha sonra convert’in senkronizasyonunu başlattığımda ise sadece 5 dakika sürdü.

Örneğin artık 2-3 TB’lık sunucuları bile kullanıcı erişimini uzun süre kısıtlamadan convert etmek mümkün.

IBM & Lenovo sunucularda otomatik arıza kaydı açmak

Merhabalar

Garantisi devam eden IBM ve Lenovo sunucularda Integrated Management Module (IMM) vasıtasıyla herhangi bir arızada IBM’e otomatik arıza kaydı açılabilmektedir. İletişim bilgileriniz de belirtildiyse IBM’den de bu arıza konusunda hızlı geri dönüş de alınıyor.

Bu özelliği kullanabilmek için ücretli Advanced IMM Upgrade’ine gerek yok. Tek yapmanız gereken sunucunuzun IMM portunu network’e bağlamak ve internete çıkabilmesi, mail atabilmesi için yapılandırmak.

1

IMM’den bağlandıktan sonra öncelikle hostname’imizi ve network ayarlarını tanımlıyoruz.

2

Daha sonra DNS ayarlarını tanımlamamız gerekiyor.

3

Ardından smtp mail server’ı tanımlanacak.

4

En önemlisi de Service & Support bölümündeki iletişim ve country code bilgilerini doğru bir şekilde yazmak. Country Code çok önemli çünkü bu arıza kaydı konusunda direkt olarak IBM Türkiye’den aranacaksınız.

Bu işlemi de yaptıktan sonra sunucu IBM’e bir test arıza kaydı açıyor ve kısa süre içinde IBM’den bu test kaydının açıldığına dair teknik destekten bir yetkili sizinle irtibata geçiyor. “Test kaydınız sistemimize ulaştı” bilgisini iletiyor.

5

En sonunda da Events / Events Recipients bölümünden hangi mailinize bildirim geleceğine dair bir tanımlama yapıyoruz.

Erken teşhis hayat kurtarır 🙂

IBM Storwize v7000 Real Time Compression Simulasyonu

Uzun süreli backup saklama konusunda 20-30 kata kadar deduplication yapan cihazlar bir kenara dursun aktif verinizi nasıl küçültebileceğiniz, sıkıştırabileceğiniz de önem teşkil ediyor. IBM’in 2010 yılında veri sıkıştırma firması Storwize’ı satın almasının sebeplerinden biri de Real Time Compression patenti.

Real Time Compression, Storwize CPU Utilization’ı %25’in üstünde olduğu durumlarda açılması pek tavsiye edilmiyor. Fakat IOPS ve throughput darboğazının olmadığı, sadece veri depolama amacıyla ekstra yer gereken yerlerde bu özelliği açmamak için bence hiç bir sebep yok.

V7000, V5030’a sahipsek veya yeni bir storage almayı düşünüyorsak doğru ürünü konumlandırma açısından sahip olduğumuz veriyi incelememiz gerekiyor. Bu konuda ise ne kadar veri sıkıştırabileceğimizi IBM Comprestimator Tool ile öğrenebiliyoruz. Real Time Compression benim verimi ne kadar sıkıştırabilir? Bunu test etme imkanımız oluyor.

Benim test ettiğim yapıya gelirsek;

– Vmware ESXi 5.5 Update 2
– 8 TB Mapped Volume
– 4 TB Virtual Machine VMDK (Windows 2008 R2)
– 2 TB Doluluk
– Veri Türü: Hastane Röntgen Görüntüleri

Öncelikle ESX’de Security Profile’dan ESXi Shell ve SSH servisini çalıştırmamız gerekiyor. Daha sonra alttaki adresten gerekli tool’u indirip Windows’umuza kuruyoruz.
http://www14.software.ibm.com/webapp/set2/sas/f/comprestimator/home.html
Kurulum işlemi bittikten sonra Program Files/IBM/Comprestimator/ESX’in altından comprestimator_esx dosyasını WinSCP ile ESX host’a bağlanıp “bin” klasörü altına “comprestimator” adında kopyalıyoruz. Farkettiğiniz gibi sadece ESX değil diğer platformlar için de test araçları mevcut.

Kopyalama işlemi bittikten sonra da bu dosyaya sağ tıklayıp tam yetki vermemiz gerekiyor. Chmod 777

1

Bu işlemleri tamamladıktan sonra ESX’imize putty ile bağlanıp alttaki komutu gönderiyoruz.

esxcli storage core device list | grep Dev

2

Bu komut sonrasında ESX hostumuza bağlı volume’ler listelenecektir. Artık hangi datastore’da işlem yapacaksak onun device path’ini bir kenara not alıyoruz.

Örnek “/vmfs/devices/disks/naa.60050763008085741800000000000002”

Daha sonra alttaki analiz komutuna ilgili device path’i ekleyip, gönderip sonucunu bekliyoruz.

comprestimator -d “/vmfs/devices/disks/naa.60050763008085741800000000000002” -s SVC

3

Görüldüğü gibi 8 TB’lık toplam alanı bulunan, 2 TB’ı röntgen görüntüsü ile dolu olan bir sanal makinayı 1.2 TB’a sıkıştırmayı başarmış. Bunun yanında her ihtimale karşı son sütunda %5’lik de bir yanılma payı olduğu belirtiliyor.

Hastane röntgen görüntüleri nispeten sıkıştırılmış veriler olduğu için aslında %38’lik bu kazanç az bile denebilir. IBM’in teknik dökümanlarına bakarsak alttaki oranlarda sıkıştırmalardan söz ediliyor.

4

Sadece simulasyon değil ofisimizde bulunan v7000’in Real Time Compression’ını test ettiğimde de %36.73 kazanç sağladım. Resimde görebileceğiniz gibi sıkıştırılmadığında 235 GB yer kaplayan veri, sıkıştırıldığında 148 GB yer kaplıyor. Thin Provision ve AutoExpand’da dahil edildiğinde 169 GB volume’un toplam kapladığı alan.

5

2 TB’lık SQL veya Exchange database’iniz compressed volume üzerinde 400-500 GB yer kaplayabilir. Tabiki bunu comprestimator tool ile test etmeden bilemezsiniz ki yazıyı yazmaktaki amaç da buydu.

Dolayısıyla Storwize V7000, V5030’u tercih etmeyerek kaçınılan tutarı bu sefer ekstra disk ve expansion storage’e vermek durumunda kalabilirsiniz.