Trik untuk mengetahui "apakah perlu meng-upgrade atau menambah jumlah host?"

oleh: Rachmat Adriyanto

Untuk mengetahui apakah dalam satu cluster perlu meng-upgrade resources / menambah jumlah host ada beberapa cara yaitu:

1. Gunakan vCOPs

2. Minta bantuan partner vmware

3. Manfaatkan fitur Maintenance Mode

4. Manfaatkan fitur DPM (Distribution Power Management)

Di bawah ini saya akan coba sharing semua cara yang saya sebutkan itu :

1. Gunakan vCOPs (vCenter Operations Manager) :

Cukup download dan install, untuk pembahasan vCOPs semoga ada waktu untuk menulis artikel tentang vCOPs. Metode ini membutuhkan biaya ekstra yaitu untuk membeli lisensinya.

2. Minta bantuan partner VMware :

Cukup kirim email ke vmware partner, contohnya:

"Halo partner, saya ingin tahu apakah sudah saatnya meng-upgrade compute resource host, mohon bantuannya untuk menghitung kebutuhan itu. Kalau memang ada kebutuhan, sekalian kirimkan penawarannya".

Nanti partner akan datang dan akan membantu menghitungnya. Semoga partnernya gak matre yang bagaimanapun keadaannya, harus upgrade :) (just kidding, mohon partner tidak marah)

Sayangnya metode ini membutuhkan waktu.

3. Manfaatkan fitur Maintenance Mode

Ini adalah fitur yang sudah ada di vCenter dan tidak perlu membeli, dan membutuhkan waktu yang cepat, hanya kurang dari 1 jam.

Dalam satu cluster, melakukan Maintenance Mode pada salah satu host akan memindah semua VM yang ada pada host tersebut ke host lain yang masih dalam satu cluster yang sama.

Hal ini rutin saya lakukan biasanya sebulan sekali, karena dengan adanya VM, penambahan server menjadi kurang terkontrol. Maintenance mode akan memindahkan semua VM yang ada pada host tersebut secara otomatis. Caranya, pada satu cluster, jalankan maintenance mode pada host yang paling besar resource CPU & RAM nya, sebagai simulasi bila host ini down, maka simulasi ini akan memastikan apakah host yang tersisa dalam cluster masih memiliki cukup resources untuk menjalankan VM yang ada.

Contohnya : sebelum dijalankan maintenance mode

Saya jalankan maintenance mode pada host dengan resource paling besar, yaitu esx2 yg memiliki RAM 128 GB. Hasilnya :

Kesimpulannya, cluster Production2 masih memiliki resource yang cukup bila ada host yang mati. Hanya saja, bila melihat utilisasi memory, jika akan ada penambahan jumlah VM atau memory VM, maka sebaiknya memory fisik perlu diupgrade.

4. Manfaatkan fitur DPM (Distribution Power Management)

Fitur DPM ini digunakan untuk menidurkan (sleep) host ketika VM-VM yang ada dapat dipindahkan ke host lain jika utilisasi host lainnya belum maksimal. DPM ini berjalan secara otomatis (berbeda dengan maintenance mode yang harus dijalankan manual), sehingga monitoring ini membutuhkan campur tangan yang minimal dari VMware admin. Contoh di bawah adalah DPM menidurkan host -esx11, dan terlihat utilisasi host yang bangun sehingga dari hasil ini, host masih aman.

Metode no.4 biasanya saya jalankan terus menerus. Bila ternyata ada 1 cluster yang ada hostnya tidak tidur, berarti kemungkinan kapasitas cluster yang ada perlu diupgrade. Bila ini terjadi, saya akan melakukan metode no.3, untuk memastikan memang perlu melakukan upgrade.

Sumber: pengalaman dari trik yang saya lakukan :)

Read more ...

Keuntungan Disaster Recovery di Cloud

oleh Purwandi*

Banjir, Tanah Longsor, Gempa Bumi, Kerusuhan Massa, Kebakaran adalah hal yang tidak diharapkan tetapi kita harus antisipasi dengan cara yang bijak supaya keberlangsungan bisnis tetap berjalan. Tentunya dengan

Disaster Recovery Site yang bisa menjawab tantangan diatas maka bisnis anda akan tetap berjalan dan system backbone dari bisnis anda ada di infrastruktur IT anda. 

So, bagaimana menjaganya supaya tetap berjalan normal dikondisi apapun dan kapanpun?

Mengapa Disaster Recoverynya di Cloud?

Nah saya pernah tanyakan hal ini ke Mr. IC dan beliau memberikan pencerahan buat diri saya, beliau menjawab,  “ Disaster Recovery di cloud adalah Disaster Recovery pada Infrastruktur IT dengan pendekatan teknologi virtualisasi, jadi semuanya baik itu Server, Operating System, Aplikasi dan Patch Management semua terintegrasi dalam satu kesatuan utuh Cloud Disaster Recovery”.

Jika dibandingkan Disaster Recovery Non Virtual akan membutuhkan waktu yang lebih besar karena akan ada depedencies ke sisi hardwarenya baik kompabilitas maupun performancenya pada saat restore.

Sedangkan di Virtualisasi tidak melihat fisik lagi selama CPU dan RAM masih cukup berjalan dengan baik  sesuai dengan yang Productionnya.

Disaster Recovery  harus bisa Provisioning yang Cepat, Skalabilitas  dan Elastisitas tentunya didukung dengan Cost Effective.

Perhatikan bagan dibawah ini :

Panah Merah = Disaster Recovery di Cloud, perhatikanlah waktu yang diperlukan buat recovery baik Online Backup, Warm Site DR dan Hot Site DR memerlukan waktu yang lebih cepat dan lebih cost effective jika dibandingkan dengan panah hitam (fisik)

Panah Hitam = Disaster Recovery Era Fisik dimana masih banyak ketergantungan disisi fisik server dan memerlukan waktu yang lebih panjang untuk proses Online Backup, Warm Site dan Hot Site DR, tentunya tidak cost effective.

Disaster Recovery di Cloud akan memangkas budget hardware kita , sebagai contoh Tape Backup proses akan menjadi lebih lama dalam proses backup dan lebih cepat dalam proses recovery karena prosesnya lebih pendek jika dibandingkan dengan Fisik yang harus dibackup kedalam tape backup.

Belum lagi adanya Teknologi Storage yang mensupport Disaster Recovery di Cloud yakni Storage Area Network atau lebih populer disebut SAN Storage. Adapun fitur khusus dari SAN Storage adalah Replikasi antar SAN ke SAN Storage yang lain (antar site DR) yang kecepatan replikasinya lebih cepat bahkan real time.

Bahkan dengan teknologi ini bisa memungkinkan Proses Recovery lebih cepat, bayangkan jika Sebuah DataCenter A (Site Jakarta) kemudian Disaster Recovery Site A (Site Bogor) ketika di Recovery otomatis Site Bogor menjadi Production Anda dan Site Jakarta. Dan Ketika sudah normal kembali Site Jakarta akan menjadi Production kembali dan Site Bogor menjadi DR.

Dalam kondisi seperti ini tentunya Disaster Recovery di Cloud adalah solusi yang paling cost effective dan spektakuler dalam proses recovery.

Disaster Recovery Cloud Aman kah?

Hal ini banyak menghantui orang yang ingin menggunakkan Disaster Recovery di Cloud, dan sekali lagi Mr.IC memberikan jawabannya , “ Disaster Recovery di Cloud harus didukung dengan system Security yang handal baik di level network maupun di level keamanan fisik”.

Di level Network harus dipersiapkan perangkat Firewall, Anti DDos, Load Balancer dan Switch dalam 10GB support sehingga sangat membantu dalam proses Recovery berlangsung dan data anda aman.

Di level Fisik harus dipersiapkan Datacenter dengan tingkat keamanan yang tinggi sehingga hanya Person In Charge saja yang bisa akses kedalam tidak ada  pihak lain, selain itu dilevel Hardware juga dipersiapkan

System Redundancy dimana seluruh perangkat memiliki Backup sehingga Single Failure Perangkat Hardware tidak terjadi. 

So, masih adakah keraguan dalam diri anda menggunanakan Disaster Recovery di Cloud….tentunya anda bisa jawab sendiri sesuai dengan pemaparan saya diatas tadi.

Kata bijak kali ini adalah :”  Pakailah Solusi Disaster Recovery anda di Cloud dan Perhatikanlah apa yang terjadi jika anda terjadi Disaster Kelak “.

* Penulis adalah Leader komunitas VMUG ID 

Read more ...

vCendol 6 Juni 2014 - Nonton Bareng Maleficent @XXI Plaza Indonesia

Acara vCendol komunitas VMUG-ID kali ini adalah nonton bareng di bioskop XXI Plaza Indonesia pada hari jum'at 6 Juni 2014, yaitu nonton film berjudul Maleficent. Acara ini dihadiri oleh 19 orang yang berhasil melewati perjuangan macetnya jakarta dari tempatnya masing-masing menuju Plaza Indonesia :P

Acara dimulai sekitar jam 18.30 dengan ngumpul-ngumpul sambil ngobrol dan berfoto-foto bareng sebelum masuk theater 1

Ketika theater 1 sudah dibuka maka kita semua masuk theater 1 sekitar jam 19.15, di dalam theater sudah dibooking 2 baris kursi dengan posisi deretan tengah paling belakang khusus untuk member VMUG-ID peserta acara nonton bareng ini. Tentu aja ngga ketinggalan foto bareng (lagi) di dalam theater setelah film selesai, sebelum keluar.

Film selesai sekitar jam 21 kurang, sebelum vCendol bubar, para peserta ngobrol lagi di luar ruang tunggu XXI sekalian sedikit membahas tentang rencana vCendol berikutnya, termasuk rencana acara buka puasa bersama nanti saat bulan Ramadhan yang tinggal sebentar lagi.

Ketika akan bubar dan saling berpamitan, maka sudah pasti yang dilakukan adalah foto bareng (lagi) :D

Oh iya, ngga lupa komunitas VMUG-ID --khususnya member yang hadir di acara nonton bareng ini-- ngucapin terimakasih banyak kepada Bu Boss Regina (itu tuh orangnya yang kedua dari paling kanan yang pegang tas sambil senyum manis) yang udah berkenan menjadi sponsor tunggal sehingga terselenggaranya acara vCendol ini, dan acara ini juga sekaligus untuk merayakan ulang tahun beliau yang ke ... (tebak sendiri!) :P

Read more ...

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

Kebijakan Baru dari VMware tentang sertifikasi

Sertifikasi VMware merupakan sertifikasi yang cukup bergengsi dalam dunia IT, sehingga bagi anda yang berprofesi dalam dunia IT khususnya yang berkecimpung dalam bidang virtualisasi tentunya akan memiliki nilai lebih jika memiliki sertifikasi VMware yang merupakan market leader dalam bidang virtualisasi. 

Terkait dengan sertifikasi, pada tanggal 10 Maret 2014 VMware memberlakukan kebijakan baru mengenai validitas masa berlaku sertifikat VCP. Kebijakan tersebut memberikan tiga pilihan kepada pemilik sertifikat VCP (track apapun) sebagai berikut:

Read more ...