vCendol 25 September 2014 - @KokiCafe Plaza Semanggi

Setelah vCendol sebelumnya yang diadakan pada tanggal 6 Juni 2014 di XXI Plaza Indonesia, maka pada kesempatan kali ini pada hari kamis tanggal 25 September 2014 kita adakan vCendol lagi di Koki Cafe, Plaza Semanggi lt.3A.

Peserta yang hadir pertama yang tiba di lokasi sejak sore adalah Faisal, Catherine, Frederic, Nia. Kemudian berikutnya yang hadir sehabis maghrib adalah Wawa, Naufal (penulis), Adri, kemudian di susul oleh Iip dan Wahyu, lalu Oki, dan yang datang terakhir adalah Yugi dan Agung.

Topik utama yang didiskusikan pada vCendol kali ini adalah mengenai informasi akan diadakannya event VSS (VMware Solutions Symposium) Indonesia 2014 pada tanggal 18 November 2014 di GrandBall room Hotel Mulia Senayan, Jakarta Selatan. Tapi bukan cuma informasi tentang event itu yang dibahas, ada kabar baik dari informasi tersebut, yaitu pada event itu VMware Indonesia menyediakan booth khusus untuk VMUG-ID.

Informasi ini tentu merupakan kabar gembira bagi VMUG-ID, karena berarti eksistensi VMUG-ID diakui secara resmi pada event bergengsi sebesar itu. Yang perlu ditetukan selanjutnya adalah pembagian tugas dari para aktifis VMUG-ID yang akan standby di booth VMUG-ID itu dan melayani para pengunjung yang mampir ke booth itu. Topik ini akan dibahas dan didiskusikan lebih lanjut, baik melalui groupd diskusi WhatsApp maupun dengan mengadakan vCendol lagi sebelum hari H.

vCendol berlanjut sampai cukup malam, yang lebih dulu pamit adalah Frederic dan Nia, kemudian Catherine. Dan pada sekitar jam 9 lewat atau setengah sepuluh, kita semua membubarkan diri. 

Berikut ini beberapa hasil dokumentasi vCendol kali ini.

Read more ...

Lisensi Windows Server 2008 & 2012 pada virtual environment

Beberapa waktu belum lama sebelum artikel ini ditulis, ada diskusi di group WhatsApp VMUG Indonesia, yaitu mengenai skema lisensi microsoft windows server pada virtual environment, yaitu dimana sistem operasi windows diinstall pada virtual machine. Diskusi tersebut menjadi inspirasi ditulisnya artikel ini.

Di era virtualisasi saat ini, skema lisensi sistem operasi (dalam hal ini yang dibahas adalah lisensi Microsoft Windows Server) pada infrastruktur IT perlu penyesuaian dibanding skema lisensi yang lama. Oleh karena itu Microsoft membuat skema lisensi khusus untuk virtual environment, terlepas dari vendor virtualisasi yang digunakan (Hyper-V, VMware, RHEV, Oracle VM, dll). Dan ini perlu diketahui dan diperhatikan oleh para pengguna system virtualisasi jika ingin menggunakan sistem operasi Windows server.

Artikel ini terbatas hanya membahas skema lisensi untuk windows server 2008 dan windows server 2012 dengan asumsi bahwa dua sistem operasi itulah yang paling banyak digunakan untuk windows-based production servers.

1. Lisensi Windows Server 2008 pada virtual environment

Lisensi Windows Server 2008 terdiri dari 4 pilihan, yaitu:

• Windows Server 2008 Standard (1 VM per Host)
• Windows Server 2008 Enterprise (4 VM per Host)
• Windows Server 2008 Datacenter (Unlimited VM per Host)
• Windows Server 2008 Itanium Based Systems

Semua skema lisensinya itu adalah dihitung per OS (Operating System) yang running tanpa dibatasi jumlah processor, kecuali yang Windows Server 2008 Datacenter dan Itanium, lisensinya dibatasi/dihitung per processor yaitu per single processor, jadi jika sebuah server fisik memiliki 2 processor maka memerlukan 2 lisensi jika ingin menggunakan lisensi Datacenter (yg jumlah VM per Host tidak terbatas / unlimited)

tabel jumlah VM per Host untuk setiap satu lisensi adalah sebagai berikut:

Referensi :

- Licensing Microsoft Windows Server 2008 to Run with Virtualization Technologies

2. Lisensi Windows Server 2012 pada virtual environment 

Berbeda dengan Windows Server 2008 yang skema lisensinya per single processor, lisensi Windows Server 2012 dihitung dengan 2-physical processors per lisensi untuk satu server fisik, jadi setiap server fisik yang memiliki 2 processor maka cukup membutuhkan 1 lisensi windows server 2012 (berlaku juga bagi server yg hanya memiliki 1 processor). Jika server memiliki 4 processor maka membutuhkan 2 lisensi, dan begitu seterusnya setiap kelipatan 2 maka membutuhkan tambahan 1 lisensi.

Lisensi Windows Server 2012 terdiri dari 2 pilihan, yaitu:

• Windows Server 2012 Standard
• Windows Server 2012 Datacenter

kedua lisensi itu memiliki fitur yang sama, perbedaannya adalah jumlah VM per Host pada deployment di virtual environment.

- Windows Server 2012 Standard dibatasi per lisensi maksimal 2 VM dalam satu Host.

- Windows Server 2012 Datacenter tidak dibatasi jumlah VM per Host, sehingga jumlah VM per Host adalah unlimited.

Referensi :

- Windows Server 2012 Licensi & Pricing FAQ

- Licensing Windows Server 2012 for use with virtualization technologies

Demikian informasi yang bisa disharing mengenai skema lisensi windows server 2008 & 2012 pada virtual environment, semoga bermanfaat dan harap dikoreksi jika ada informasi yang keliru pada artikel ini.

Read more ...

VMware EVO: RAIL, Hyper-Converged Infrastructure Appliance solution

VMware EVO: RAIL adalah product baru dari VMware berupa Hyper-Converged Infrastructure Appliance sebagai bundling solution untuk Software Define Data Center, yaitu sebuah hardware appliance yang sudah dibundling dengan product software-software berikut ini dari VMware :

• vSphere Enterprise plus
• vCenter Server Virtual Appliance
• VSAN
• vCenter Log Insight

Adapun untuk hardwarenya, VMware bekerjasama dengan beberapa vendor produsen hardware yang disebut sebagai qualified EVO:RAIL partners yang diumumkan pada VMword 2014 yaitu : Dell, EMC, Fujitsu, Inspur, Net One Systems and SuperMicro. Semuanya software dan hardware pada product EVO: RAIL disertai support dan maintenance selama 3 tahun dari VMware sebagai satu SKU.

Setiap hardware appliance dari semua vendor tersebut sudah distandarisasi memiliki spesifikasi pada masing-masing node dalam EVO RAIL appliance adalah sebagai berikut:

• Two Intel E5-2620 v2 six-core CPUs
• 192GB of memory
• One SLC SATADOM or SAS HDD as the ESXi™ boot device
• Three SAS 10K RPM 1.2TB HDD for the VMware Virtual SAN™ datastore
• One 400GB MLC enterprise-grade SSD for read/write cache
• One Virtual SAN-certified pass-through disk controller
• Two 10GbE NIC ports (configured for either 10GBase-T or SFP+ connections)
• One 1GbE IPMI port for remote (out-of-band) management

Dengan VMware EVO RAIL kita dapat membangun suatu infrastruktur virtual berisi 4 node sebagai 4 host untuk ESXi hanya dengan sebuah box hardware berukuran 2U dengan estimasi waktu untuk konfigurasi awal hanya dalam waktu kurang lebih 15 menit, hal itu karena kemudahan dan kesederhanaan proses instalasi dan konfigurasi yang ada pada EVO: RAIL engine, sehingga untuk membangun sebuah infrastruktur untuk virtualisasi dengan 4 host ESXi beserta vCenter dan storage menggunakan VSAN maka user hanya cukup menghidupkan hardwarenya kemudian langsung melakukan konfigurasi dengan mengikuti wizardnya EVO: RAIL engine dan mengisi parameter yang ada pada wizard tersebut (hostname, password, IP range, subnetmask, gateway, VM network, dan lain-lain), sebagaimana dapat dilihat pada video demo berikut ini:

Sebagaimana dilihat pada video demo di atas, bagi yang terbiasa menggunakan vCenter mungkin merasakan bahwa dashboard EVO: RAIL engine terasa relatif lebih sederhana dan user-friendly dibanding vSphere Web client. Meskipun demikian, user tetap bisa menggunakan vSphere Web client untuk mengkonfigurasi lebih detail tentang fitur-fitur di vCenter, karena dashboard EVO: RAIL hanyalah penyederhanaan dari sebagian saja fungsi yang ada pada vCenter.

Tapi tentunya infrastruktur virtual environment yang dapat dibangun dengan EVO: RAIL tidak terbatas hanya empat host saja, karena EVO: RAIL adalah scalable building block, sehingga beberapa appliance EVO: RAIL engine dapat digabung dalam membangun infrastruktur virtual yang lebih besar dengan jumlah host kelipatan 4 setiap satu EVO: RAIL hardware appliance.

Untuk sumber informasi resmi mengenai EVO: RAIL, dapat dilihat pada beberapa link referensi berikut ini:

VMware EVO: RAIL overview
http://www.vmware.com/products/evorail/

VMware EVO: RAIL features
http://www.vmware.com/products/evorail/features.html

VMware EVO: RAIL Datasheet PDF
http://www.vmware.com/files/pdf/products/evo-rail/vmware-evo-rail-datasheet.pdf

Introduction to VMware EVO: RAIL White Paper PDF
http://www.vmware.com/files/pdf/products/evo-rail/vmware-evo-rail-introduction.pdf

VMware EVO: RAIL User guide PDF
http://www.vmware.com/files/pdf/products/evo-rail/vmware-evo-rail-configuration-management-guide.pdf

Read more ...

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

Read more ...

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

Read more ...

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