VMUG Indonesia

Selasa, 05 Agustus 2014

Mengatasi Script Error : Expected')' saat instalasi VMware Workstation 10

oleh: Budi Gunawan

Pada tulisan ini saya membahas tentang cara mengatasi masalah Script Error pada saat instalasi Vmware Workstation 10. Mungkin saat menginstall VMware Workstation 10 pernah mengalami seperti gambar di bawah ini ?

Hal ini terjadi karena saat VMware Workstation 10 mengekstrak ke folder “C:/Users/Budi_Gun'z/AppData/Local/Temp/vmware_1394788831/index.htmlang=1033&locale=1033“ dan mulai membaca script, tapi gagal saat membaca script tersebut karena gagal mengenali directory tempat dimana VMware Workstation 10 di ekstrak.

Untuk masalah seperti ini anda dapat mengatasinya dengan cara mengganti “PATH” untuk sementara waktu, caranya adalah sebagai berikut :

1. Start → Di kotak Search programs and files ketik “View advanced system settings” & pilih iconnya yang terletak diatas.

2. Pilih menu “Environment Variables” atau dengan menekan tombol “N”.

3. Sebelumnya backup dahulu lokasi “TEMP” & “TMP” di notepad.

4. Edit “TEMP” & “TMP” yang berada pada dialog “User Variables” dengan cara klik 2x.

5. Menjadi Seperti gambar di bawah ini.

6. Klik OK pada “Environment Variables” & “System Properties”.

7. Untuk mendapatkan efeknya restart PC anda dan jalankan installer VMware 10 seperti biasa dan masalah Script Error harusnya tidak muncul kembali.

8. Setelah anda selesai menginstall VMware 10 kembalikan value yang ada di “Environment Variables” seperti backup yang berada di notepad & restart kembali PC anda.

Selesai, semoga bermanfaat :-)

Mengatasi SSL Certificate Verification Failed pada VMware vSphere Web Client

oleh: Budi Gunawan

Perkenalkan nama saya adalah Budi Gunawan, saya sebagai Technical Cosultant pada sebuah perusahaan yang bernama PT. Juke Solusi Teknologi. Pada tulisan ini saya akan membahas tentang masalah SSL certificate verification failed pada vCenter. Mungkin anda pernah gagal login ke VMware vSphere Webclient karena terjadi kegagalan seperti gambar di berikut ini ?

Ketika saya mengalami hal itu, ternyata ini terjadi karena saat identifikasi network untuk vSphere Web Client berubah tetapi SSO SSL certificate tidak di perbaharui. Untuk masalah seperti ini anda dapat mengatasinya dengan cara mengganti “SSO SSL certificate” agar SSO SSL certificate di perbaharui, caranya adalah sebagai berikut :

1. Login VMware vCenter Server Appliance.

2. Lalu pindah ke TAB Admin.

3. Setelah berada di TAB Admin klik “YES” pada “Certificate regeneration enabled” lalu “SUBMIT“.

4. Setelah itu Restart VMware vCenter Server Appliance anda menggunakan VMware vSphere Client.

5. Setelah restart maka VMware vCenter Server Appliance akan Regenerating ulang certificate.

6. Setelah restart tunggulah beberapa menit untuk loading VMware vCenter Server Appliance, lalu Login vSphere Web Client maka masalah “SSO SSL certificate” tidak akan muncul kembali dan anda akan di arahkan ke halaman vSphere Web Client.

7. Setelah anda sukses login maka disable kembali “Certificate regeneration enabled” dengan cara :

Selesai, terimakasih.

Referensi: KB2033338

Selasa, 01 Juli 2014

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 :)

Rabu, 11 Juni 2014

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

Senin, 09 Juni 2014

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

Minggu, 01 Juni 2014

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/

Kamis, 13 Maret 2014

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.