VMware vSphere Storage API’ler – Storage Array Entegrasyonu (VAAI)
VMware vSphere Storage API’ler (VAAI) hakkında yayınlayacağım makale serisinde vaai primitive’lere giriş & vaai türleri ,vaai desteğinin kontrol edilip monitor edilmesi ve vaai primitive’lerin devre dışı bırakılması ve aktifleştirilmesi konularına değineceğiz.
- VMware vSphere Storage API’ler – Storage Array Entegrasyonu (VAAI)
- VMware vSphere VAAI Desteğinin Kontrol ve Monitor Edilmesi
- VMware vSphere VAAI Primitive etkinleştirme ve devre dışı bırakma
VMware vSphere Storage API’ler , Hardware acceleration veya Hardware offload API’leri olarak da adlandırılan Array Integration (VAAI), VMware vSphere ESXi hostlar ve storage device’lar arasındaki iletişimi sağlayan bir dizi API’dır.
API’ler, ESXi host’ların belirli storage işlemlerini array’e boşaltmasına olanak tanıyan bir dizi “storage primitive’ler” (storage ilkesi ) olarak tanımlanırlar .
Bu da ESXi host’lardaki ek kaynak yükünü azaltır ve storage cloning ,zeroing gibi storage yoğun işlemler için performansı önemli ölçüde artırabilir.
VAAI’nin amacı, storage üreticilerinin, storage donanımında daha verimli bir şekilde gerçekleştirilen VMware I/O işlemlerini hızlandırmak için donanım yardımı sağlamasına yardımcı olmaktır.
VAAI kullanılmadan, sanal makinelerin vSphere VMkernel Data Mover tarafından klonlanması veya taşınması software data hareketini içerir. Data Mover, kaynak ve hedef datastore’a gelen ve giden blokları okumak ve yazmak için I/O oluşturur.
VAAI ile Data Mover , mümkünse işlemleri storage array’e yüklemek için API primitive’leri kullanır.
Örneğin, bir sanal makine diski (VMDK) dosyasını bir datastoare’dan aynı array içindeki başka bir datastore kopyalama yapılmak istendiğinde , array , kopyayı tamamen array içinde yapmak için yönlendirir.
Bir veri taşıma işlemi çağrıldığında ve karşılık gelen hardware offload işlemi etkinleştirildiğinde, Data Mover önce hardware offload kullanmaya çalışır.
Hardware offload işlemi başarısız olursa, Data Mover geleneksel veri hareketi yazılım yöntemine döner.
Neredeyse tüm durumlarda, hardware data mover software mover hareketinden önemli ölçüde daha iyi performans gösterir. Storage fabric üzerinde daha az CPU ve daha az bant genişliği tüketir.
Performanstaki iyileşmeler, VAAI primitive’leri kullanan zamanlama işlemleri ve işlem sırasında CMDS/s, READS/s, WRITES/s, MBREAD/s ve MBWRTN/s gibi değerleri izlemek için esxtop kullanabilirsiniz.
İlk VMware vSphere 4.1 sürümünde , üç VAAI primitive release oldu . Bu primitive’ler yalnızca block storage’a (Fiber Kanal, iSCSI, FCoE) uygulanır. Bu ilk sürümde NAS depolama için VAAI primitive’ler yoktu.
vSphere 5.0 sürümünde, NAS storage ve VMware vSphere Thin Provisioning için VAAI temel öğeleri tanıtıldı. O zamandan beri çeşitli vSphere sürümlerinde, UNMAP aracılığıyla dead space reclamation ile başa çıkmanın farklı yöntemleri tanıtılmıştır.
Aşağıda farklı VAAI Block Primitive türleri, işlevleri ve özellikleri anlatılmaktadır :
Atomic Test & Set (ATS)
VMware vSphere VMFS’de, birçok işlem bir kaynağı güncellerken volume üzerinde lock oluşturmalıdır.
VMFS cluster bir dosya sistemi olmasından kaynaklı ESXi hostlar arasında paylaştırılmış durumdadır.
Bir host’un VMFS metadata için bir güncelleme yapması gerektiğinde, dosya sistemi bütünlüğünü korumak ve başka bir host’un içeri girmesini ve aynı meta data’ları güncellemesini önlemek için locking mekanizması gerekir.
Aşağıdaki işlemler için lock (kilit) gerekir:
- Acquire on-disk locks
- Upgrade an optimistic lock to an exclusive/physical lock
- Unlock a read-only/multi-writer lock
- Acquire a heartbeat
- Maintain “liveness” of a heartbeat
- Clear a heartbeat
- Replay a heartbeat
- Reclaim a heartbeat
- Acquire on-disk lock with dead owner
ATS metadata güncellemeleri yaparken VMFS volume’lerda SCSI rezervasyonları kullanımını değiştirmek için tasarlanmış gelişmiş bir locking mekanizmasıdır.
Bir SCSI reservation tüm LUN’u kilitler ve volume’ü paylaşan bir host’un kilidi olduğunda diğer host’ların VMFS volume meta data güncellemelerini yapmasını engeller.
Bu, birçok sanal makine aynı datastore’u kullandığında çeşitli contention (çekişme ) sorunlarına neden olabilir. Çok büyük VMFS volume boyutlarında ölçeklendirme için sınırlayıcı bir faktör olduğuda unutulmamalıdır.
ATS, VMFS volume’de yalnızca bir disk sector değiştiren bir kilit mekanizmasıdır.
Başarılı olduğunda, ESXi host’un volume üzerinde meta data güncellemesi yapmasını sağlar.
Bu, sağlama sırasında bir VMDK’ya alan ayırmayı içerir, çünkü belirli özelliklerin dosyanın yeni boyutunu yansıtacak şekilde meta data’larda güncellenmesi gerekir.
ATS , SCSI reservation’daki contention sorunlarını giderir ve VMFS birimlerinin çok daha büyük boyutlara ölçeklenmesini sağlar. ATS bir test-image ve set-image kavramına sahiptir.
“Compare” sırasında diskteki görüntü beklendiği gibi olduğu sürece, host kilidin güncellenmeye devam edebileceğini bilir.
İlk VAAI sürümünde, ATS primitive’lerin her storage array’de farklı şekilde uygulanması gerekiyordu, bu da üreticiye bağlı olarak farklı bir ATS opcode gerektiriyordu. ATS artık standart bir T10 SCSI komutudur ve 0x89 (COMPARE AND WRITE) kodunu kullanır.
Storage ‘da VAAI etkin değilse , VMFS5’te kritik bölümler oluşturmak için SCSI reservation’ları kullanılmaya devam eder.
ATS Only Flag
Yeni oluşturulan VMFS5 ve VMFS6 veri depolarında ATS flag bulunur. Host array’de ATS’yi desteklediğini algıladığında, ATS only flag datastore’a yazılır.
Bu noktadan sonra, ATS her zaman datastore’da kullanılacaktır, böylece tüm meta data işlemleri için kullanılabilir durumda olacaktır.
ATS flag yeni oluşturulan bir VMFS5’te manuel olarak etkinleştirilebilir veya devre dışı bırakılabilir. Manuel olarak etkinleştirmek için aşağıdaji komutu kullanabilirsiniz:
# vmkfstools –configATSOnly 1 [device path]
XCOPY (Extended Copy)
VAAI olmadan, bir clone veya migrate işlemi için VMkernel software Data Mover driver kullanılır.
Bu full copy , HBA queue’da CPU cycle , DMA buffer ve SCSI komutları gibi host kaynaklarını tüketir.
Bu VAAI primitive, array’in Data Mover adına blokların full copy gerçekleştirmesini ister. Öncelikle klonlama ve taşıma işlemlerinde (VMware vSphere Storage vMotion gibi) kullanılır. XCOPY için SCSI opcode 0x83’tür.
Write Same (Zero)
Herhangi bir verinin bir sanal diske yazılabilmesi için önce “sıfırlanması” gerekir. Lazy-zeroed sanal diskler, ilk kez yazılana kadar her disk bloğunu sıfırlanmaz ve yazma işlemi gerçekleştiğinde hafif bir performans kaybına neden olur.
Bir disk bloğuna ilk yazma işleminde oluşan performans kaybını önlemek için Eager-zeroed sanal diskler kullanılabilir.
Bir eager-zeroed thick VMDK sağlanırken, disk bloklarına sıfır yazmak için bir SCSI komutu verilir.
Bu ESXi hostun HBA queue,CPU, DMA Buffer gibi kaynaklarının tüketilmesine neden olur.
Biçimlendirme işlemi (disk bloklarını sıfırlama ) hem zaman alan, hem de yoğun kaynak alan bir işlem olabilir, çünkü ESXi hostlar storage array’e gigabayt’larca sıfır gönderir.
ESXi host’lar diskin büyük bölümlerini sıfırlamak için WRITE_SAME SCSI komutunu çağırabilir. Bu şekilde storage array’de, verileri aktarım bağlantısı üzerinden aktarmadan çok sayıda disk bloğunu sıfırlar. WRITE_SAME SCSI opcode 0x93’tür.
VAAI özellikli storage array’ lerde, tüm disk bloklarını çok daha verimli bir şekilde sıfırlama işlemini gerçekleştirebilir.
ESXi Host’ların işlemin tamamlanmasını beklemesi yerine, storage işlemin hemen tamamlandığını bildirir ve ESXi Host’u dahil etmeden işlemi kendi başına işler.
WRITE_SAME komutu kullanılarak aşağıdakiler hızlandırılmış olur :
1- eager-zeroed thick hedef diskleri için klonlama işlemleri
2- Thin-provisioned sanal diskler için yeni dosya blokları ayırma
3- zeroed-thick sanal diskleri için önceden yazılmamış dosya bloklarını başlatma
UNMAP
Bir VAAI primitive olan , UNMAP, ESXi host’ların daha önce başka bir datastore’a taşınan veya silinen bir sanal makine tarafından işgal edilen alanın artık geri alınabileceğini storage array’e bilgilendirmesini sağlar.
Bu genellikle ‘dead space reclamation’ (ölü alan kazanımı) olarak adlandırılır ve bir storage array ‘in thin-provisioned datastore’da alan tüketimini doğru bir şekilde rapor etmesini ve ayrıca kullanıcıların yeni storage gereksinimlerini izlemesini ve doğru şekilde tahmin etmesini sağlar.
Space reclamation işlemi , vSphere 5.0 sürümünde sunulduğundan beri düzenli olarak güncellenmiştir. Başlangıçta operasyon otomatik idi.
Sanal makine bir datastore’dan taşındığında veya silindiğinde, UNMAP komutu hemen çağrılır ve storage üzerinde alan geri kazanılırdı.
Bu yaklaşımda, öncelikle performans ve bir array’de alanı en uygun zaman diliminde geri kazanma yeteneği ile ilgili bazı sorunlara sebep olurdu.
Bu nedenle UNMAP operasyonu manuel bir sürece dönüştürüldü. Bununla birlikte, vSphere 6.5 verisiyonu ile , VMFS6 ile datastore biçimlendirildiği sürece UNMAP ilkesi bir kez daha otomatik hale getirildi .
VMFS6 datastore’larda otomatik olarak etkinleştirilir. VMFS6 datastore’larda ölü alanın geri (‘dead space reclamation) kazanılması için otomatik UNMAP tarayıcı mekanizması artık arka planda sürekli olarak çalışıyor.
vSphere 6.0’da, UNMAP’taki ek iyileştirmelerden biride, bir Guest OS içinden mahsur alanın geri kazanılmasını kolaylaştırmaktır.
Thin olan bir VMDK ‘ya sahip konuk işletim sisteminin, blokların geri kazanılabileceğini ve buna bağlı olarak VMDK’nın boyutunu küçültebileceğini destekleyen storage’ı bilgilendirme yeteneği vardır.
vSphere 6.5’ten önce, VM’de Change Block Tracking ( CBT) etkinleştirildiyse Guest OS’da içindeki UNMAP çalışmazdı.
vSphere 6.5 sürümünde, VM’de CBT etkinleştirildiyse Guest OS’da UNMAP çalışır, bu da büyük bir gelişmedir.
Esxcli ile kullanıcılar Thin Provisioning ve VAAI ile ilgili aygıta özgü ayrıntıları görüntüleyebilir.
[root@esx01:~] esxcli storage core device list -d naa.60001440000000106077d2xxxxxxxxxx
naa.60001440000000106077d2xxxxxxxxxx
Display Name: EMC Fibre Channel Disk (naa.60001440000000106077d2xxxxxxxxxx)
Has Settable Display Name: true
Size: 2097153
Device Type: Direct-Access
Multipath Plugin: PowerPath
Devfs Path: /vmfs/devices/disks/ naa.60001440000000106077d2xxxxxxxxxx
Vendor: EMC
Model: Invista
Revision: 6010
SCSI Level: 4
Is Pseudo: false
Status: on
Is RDM Capable: true
Is Local: false
Is Removable: false
Is SSD: false
Is VVOL PE: false
Is Offline: false
Is Perennially Reserved: false
Queue Full Sample Size: 0
Queue Full Threshold: 0
Thin Provisioning Status: yes
Attached Filters:
VAAI Status: supported
Other UIDs: vml.02001f000060001440000000106077d2dda0a9765249xxxxxxxxxx
Is Shared Clusterwide: true
Is Local SAS Device: false
Is SAS: false
Is USB: false
Is Boot USB Device: false
Is Boot Device: false
Device Max Queue Depth: 64
No of outstanding IOs with competing worlds: 32
Drive Type: unknown
RAID Level: unknown
Number of Physical Drives: unknown
Protection Enabled: false
PI Activated: false
PI Type: 0
PI Protection Mask: NO PROTECTION
Supported Guard Types: NO GUARD SUPPORT
DIX Enabled: false
DIX Guard Type: NO GUARD SUPPORT
Emulated DIX/DIF Enabled: false
[root@esx01:~]
Ayrıca storage array’ın dead space reclamation (Delete Status olarak adlandırılır) için UNMAP primitive’ı destekleyip desteklemediği de dahil olmak üzere, bu cihaz için array tarafından desteklenen VAAI primitive’leri değerini görüntüleyebilir.
Aşağıda gösterildiği gibi bu adım için başka bir esxcli komutu kullanılır:
[root@esx01:~] esxcli storage core device vaai status get –d naa.60001440000000106077d2xxxxxxxxxx
naa.60001440000000106077d2xxxxxxxxxx
VAAI Plugin Name:
ATS Status: supported
Clone Status: supported
Zero Status: supported
Delete Status: supported
[root@esx01:~]
Device, bir alan geri kazanımı işlemi istendiğinde array’e SCSI UNMAP komutları gönderebildiğini göstermek için “DeletecStatus: supported” görüntüler.
Storage vMotion işlemi başlatılırsa ve sanal makine kaynak datastore’dan hedef datastore’a taşınırsa, array bu alanı geri kazanır.
UNMAP granularity değeri 1 MB’den büyük olan storage array’de otomatik UNMAP desteklenmez.
UNMAP’in yalnızca VMFS 6 olan ve powered-on VM’lerine sahip VMFS datastore’larda otomatik olur.
UNMAP otomatik olduğundan, datastore’daki ölü alanların tamamen geri kazanılması 12-24 saat sürebilir.
