VAAI (vStorage APIs Array Integration)

oleh Rachmat Adriyanto

VAAI (vStorage APIs Array Integration) adalah fitur untuk mempercepat proses di storage yang ada sejak ESX/ESXi versi 4.1. Berguna untuk memindahkan pekerjaan yang sebelumnya dijalankan oleh vSphere/host menjadi dijalankan oleh storage, sehingga keuntungannya :

• Penggunaan CPU lebih kecil
• Penggunaan memory lebih kecil
• Proses lebih cepat
• Penggunaan bandwidth untuk storage lebih kecil

Ada 4 fitur VAAI, yaitu :

ATS : Atomic Test & Set

Hardware Assisted Locking or Hardware Accelerated Locking

Memberi kemampuan untuk menguncisatu segment pada metatada VMFS. Proses normalnya menggunakan SCSI reservation yang akan mengunci seluruh LUN, yang dibutuhkan untuk melakukan perubahan tanpa host lain menulis pada file yang sama bersamaan. Hal ini mengurangi efek performa pada VM lain pada LUN yang sama

Clone

Full Copy, Clone Blocks, Extended Copy, XCOPY dan Hardware Accelerated Move

proses copy pada storage dilakukan oleh storage sendiri, sehingga mempercepat proses dan tidak membebani jaringan. Tanpa fitur ini, proses copy akan dilakukan oleh VMkernel yang berarti akan membebani host dan jaringan.

Zero

Write Same, Zero Blocks, atau Hardware Accelerated Init

vSphere hanya mengatakan ke storage untuk menulis berapa banyak zero yang perlu ditulis tanpa mengirimkan perintak SCSI. Ini digunakan pada disk berjenis thick VMDK.

Delete : mulai ada di ESXi versi 5.x

Block Delete, SCSI UNMAP, Space Reclaim, atau Block Reclaim

metode untuk mereklaim kapasitas yang tidak digunakan dari LUN dan mengembalikannya .

Untuk penjelasan detil keempat fungsi di atas,

Sebetulnya sudah ada banyak yang membahas apa itu VAAI, alasan saya kenapa menulis tentang VAAI adalah walaupun sudah muncul Hardware Acceleration Supported :

Tetapi bila dicek dengan command : esxcli storage core device vaai status

ternyata tidak semua keempat fitur di atas didukung.

Dari contoh di atas, walaupun storage dengan id : naa.6001xxx keterangan dari vSphere Client mendukung Hardware Acceleration, ternyata dari command esxcli, fitur Delete Status tidak didukung.

Karena itu, saat membeli storage, cek dahulu fitur VAAI apa saja yang didukung, karena bisa saja statusnya mendukung VAAI, tetapi ternyata tidak semua fitur didukung.

Source :

- http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1021976

- http://wahlnetwork.com/2013/11/29/many-names-aliases-vaai-primitives/

Read more ...

Berkenalan dengan Virtual SAN

Di event VMworld 2013, VMware menyampaikan visinya tentang Software Defined Storage yaitu dengan meluncurkan produk yang diberi nama Virtual SAN (VSAN) versi beta untuk public, sejak saat itu respon untuk VSAN sangat banyak (hingga lebih dari 10.000 orang) yang bergabung dalam pengujian versi beta. Pada tanggal 6 Maret 2014 lalu VMware mengadakan event online mengenai VSAN yang sekaligus merupakan launching VSAN.

VSAN adalah software hypervisor-converged storage yang memanfaatkan SSD dan HDD local storage pada server-server Host yang tergabung dalam cluster dan membentuk suatu block-level shared storage dengan performa tinggi di dalam layer hypervisor pada cluster tersebut. VSAN di embed dalam kernel vSphere sehingga memungkinkan penggunaan yang terintegrasi dengan vSphere untuk best performance. Dengan adanya VSAN maka pertimbangan untuk pembelian infrastruktur storage pada environment vSphere tidak lagi hanya tertuju pada perangkat hardware storage appliance, tapi juga bisa dengan pilihan lain yaitu penggunaan local storage pada server host vSphere existing berupa SSD dan HDD untuk digunakan sebagai VSAN. Berikut ini ilustrasi arsitektur VSAN:

VSAN adalah terobosan baru yang cukup significant dalam bidang Software Defined Storage, dan selayaknya para pengguna vSphere mempelajari tentang VSAN sebagai solusi alternatif shared storage selain dengan penggunaan external shared storage.

Berikut ini point-point yang menarik yang akan didapat dengan implementasi VSAN:

• Linear scalability for performance and capacity when adding new nodes
• vSphere 5.5 Update 1 - VSAN GA in v 1.0
• 2 Million IOPS - on 32 node cluster

• 32 hosts - The maximum cluster size for v 1.0 of VSAN
• VSAN maximum scalability  4.4 PB (35 disks x 32 hosts)
• VSAN 1.0 supports 3200 Virtual Machines (but only 2048 can be protected by HA due to HA restrictions – datastore limit per cluster. If you have more VMs above that number then you’ll have to create another datastore)
• VSAN 1.0 supports VMware Horizon View  
• VSAN 1.0 supports vSphere Replication (VR)
• VSAN 1.0 supports vSphere Data Protection (VDP)
• VSAN Nodes will be announced from HP, IBM, Dell, Fujitsu and Cisco - certified for VSAN. Shall be announced with GA next week as well. VSAN nodes are certified servers which can run VSAN without any hardware modifications. You can also adapt your existing hardware which is on the HCL, by checking the HCL for VSAN components (SSDs, HBA, HDDs …) and add those components into your servers.

Untuk mempelajari tentang VSAN lebih dalam dan lebih rinci, materi-materi berikut ini munkin dapat bermanfaat:

- Virtual SAN Overview
- Virtual SAN: Scaling Storage Capacity
- A quick reference to VSAN (Virtual SAN) resources & VSAN related posts

White Papers (PDF file)

- What's New in VMware Virtual SAN

- VMware Virtual SAN Design and Sizing Guide

Video

Read more ...

Diskusi tentang Multiple Extents

Bagi administrator vSphere pasti umumnya sudah cukup familiar dengan istilah extend VMFS volume, yaitu menambah/memperbesar kapasitas volume VMFS pada suatu datastore. 

Terkait dengan VMFS, tulisan ini merupakan hasil diskusi pada group WhatsApp komunitas VMUG ID mengenai pembahasan menggunakan extents pada VMFS volume, yaitu pada tanggal 12 Maret 2014 berawal dari adanya yang menanyakan pendapat rekan-rekan VMUG ID mengenai gambar berikut ini :

Sebagaimana nampak pada gambar diatas, itu adalah sebuah tampilan Volume Properties VMFS yang di extend dengan 5 LUN. Maka terjadilah diskusi mengenai hal itu, berikut ini komentar dari opini rekan-rekan VMUG ID sebagai jawaban dari pertanyaan "Kira-kira apa kelemahannya ya?", diantaranya:

- "Biasanya multiple extent dihindari krn khawatir kalau LUNnya lepas corrupt, susah restore dll" (komentar Bayu Wibowo - VMware Indonesia)

- "Saya gak pake extent, takuuttt. Ada db besar, file dbnya yg dipisah" (komentar Rachmat Adriyanto - Asuransi Astra Buana"

- "Not recommended pak, Kalau LUN pertama failed, data akan hilang semua. Pointer ke extent LUN disimpan di LUN pertama. Apalagi campur array begitu. Performancenya sulit dipredict" (komentar Shiraz Erosagon - VMware Indonesia)

- "jarang kita extend pak novi, alasannya spt yg bro eros sampaikan" (komentar Muhammad Faisal - VMware Indonesia)

Pada diskusi tersebut juga di share beberapa artikel terkait permasalahan penggunaan extents:

- Creating and managing extents on ESX/ESXi (2000643)

- VMFS Extents – Are they bad, or simply misunderstood?

- To extend or not to extend? That is the question.

Kesimpulannya, penggunaan multiple extent dengan beberapa LUN tidaklah direkomendasikan dengan alasan: LUN-LUN satu dengan yang lain yang digunakan sebagai extents akan saling tergantung sehingga menjadi riskan/beresiko karena jika salah satu LUN pada extents bermasalah atau koneksinya lepas / offline (apalagi jika yang bermasalah adalah LUN yang pertama), maka data VM yang ada pada datastore tersebut akan corrupt jika sebagian (atau semua) datanya ada di LUN yang bermasalah itu. Ini sudah cukup menjadi alasan kuat untuk menghindari penggunaan extents, ditambah lagi jika beberapa LUN yang di jadikan extent diambil dari storage array yang berlainan, hal itu dikhawatirkan akan mempengaruhi performance.

Mungkin ada pertanyaan, jika demikian, lalu kapan atau dalam kondisi bagaimana yang bisa dijadikan alasan tepat untuk penggunaan extents ? jawabnya adalah jika ada satu atau beberapa VM yang tidak bisa power-on karena freespace datastore habis yang mungkin disebabkan adanya banyak snapshot. Dalam kondisi seperti itu maka penggunaan extent dapat menjadi solusi sementara sekedar agar VM yang gagal power-on dapat normal kembali, tapi setelah itu harus di buat datastore baru dari sebuah LUN dengan kapasitas yang lebih besar lalu pindahkan isi datastore (misalkan dengan menggunaakn vStorageMotion) yang telah diextend ke datastore baru yang kapasitasnya lebih besar.

Best-Practise pembuatan VMFS adalah dengan satu LUN yang besar sesuai yang dibutuhkan dengan telah mempertimbangkan pertumbuhan usagenya. Jika suatu saat datastore existing sudah tidak mencukupi dan butuh yang lebih besar, maka buatlah datastore baru dengan sebuah LUN baru berkapasitas lebih besar, kemudian pindahkan VM dari datastore yang sudah penuh ke datastore baru yang lebih besar. Cara itu lebih direkomendasikan daripada menggunakan extents pada pada datastore yang sudah penuh.

Read more ...