Self Learner | Information Technology Enthusiast | Hamba Allah

My photo
Pribadi yang berdzikir itu : kalau bicara, bicaranya dakwah, diamnya berdzikir, nafasnya tasbih, matanya penuh ramat Allah, telinganya terjaga, pikirannya baik sangka, tidak suka sinis, pesimis dan tak suka memvonis. . dia tidak sibuk mencari kesalahan orang lain dan asik memperbaiki dirinya . . (Ust.Muhammad Arifin Ilham)

Thursday, July 21, 2016

Menjalankan Multiple Profile OpenVPN di Windows


Untuk menjalankan beberapa profile OpenVPN dalam waktu yang bersamaan memiliki kendala pada TAP-Adapter nya, dimana setiap session tunnel OpenVPN menggunakan 1 TAP-Adapter, sementara jika kita menginstall OpenVPN di Windows maka secara default akan terinstall hanya 1 TAP-Driver saja.
Maka, untuk dapat menjalankan beberapa profile OpenVPN sekaligus dalam waktu yang bersamaan dibutuhkan jumlah TAP-Driver sesuai jumlah profile yang diinginkan.
Dalam kasus ini, saya membutuhkan 2 profile OpenVPN yang harus dijalankan bersamaan, maka existing sudah terdapat 1 TAP-Adapter selanjutnya hanya tinggal menambahkan (meng-install) 1 TAP-Adapter lainnya.
Berikut langkah-langkah untuk menambahkan (menginstall) TAP-Adapter pada Windows 7:
  1. Buka icon windows, dan ketikkan CMD atau command prompt:
Atau juga bisa dengan membuka “Run” dan ketikkan “cmd”

  1. Apabila sudah muncul hasil pencarian dari cmd, maka klik kanan pada command prompt dan pilih “Run as administrator”

  1. Masuk ke direktori C:\Program Files\TAP-Windows\bin, dan jalankan file “addtap.bat”
C:\Users\donny\AppData\Local\Temp\SNAGHTML100f0d8.PNG
Apabila muncul alert, maka klik allow untuk mengizinkan proses instalasi TAP-Adapter baru, tunggu sebentar sampai proses instalasi selesai yang ditandai dengan pesan “Drivers installed successfully”.
Silahkan di-check sekarang TAP-Adapter sudah terlihat muncul 1 TAP-Adapter baru.
Sampai tahap ini sudah selesai, dan kini sudah dapat menjalankan 2 Profile OpenVPN sekaligus dalam waktu yang bersamaan.
Jika dibutuhkan untuk menjalankan lebih dari 2 profile sekaligus (misalnya: 4 profile) maka tinggal lakukan saja instalasi TAP-Adapter selanjutnya menggunakan langkah yang sama sebanyak yang dibutuhkan.

Thank you.
Donny Achmadi



Monday, July 18, 2016

Sizing VMware NSX Components


https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh1qqjuLRxHPAwft3eRnbhSdWTwBbJ70OSsue49IZFK7dqE8m3t_K99ajsJthsWCoHY9ix9FaWOH6trfwiZtbgLjqnkBJ4t9otUB7dnB1uEIYNM9CLys5B4tXkKRgg7rJxEvfGx5wGPlhY/s1600/comp.png

VMware NSX memiliki cukup banyak komponen-komponen yang ada didalamnya, untuk melakukan implementasi VMware NSX kita membutuhkan resource yang cukup besar untuk mendeploy seluruh komponen-komponen yang ada.
Beberapa saat yang lalu saya agak kesulitan melakukan implementasi VMware NSX dikarenakan sizing tiap komponen yang ternyata beragam dan beberapa komponen membutuhkan hingga 3x VM (NSX controller) sesuai best practice dari VMware.
Dari beberapa sumber resmi dan non-resmi, berikut saya buat sizing komponen VMware NSX dalam table berikut:
Komponen
Size
CPU
RAM
Disk
NSX Edge Service Gateway (ESG)
Compact
1
512 MB
512 MB
Large
2
1 GB
512 MB
Quad-L
4
1 GB
512 MB
XL
6
8 GB
4.5 GB
NSX Manager
Standard
4
12 GB
60 GB
Large Scale
8
24 GB
60 GB
DLR Control VM
1
512 MB
500 MB
NSX Controller
4
4 GB
20 GB
Guest Introspection
2
1 GB
4 GB
NSX Data Security
1
512 MB
6 GB per ESXi host
Sesuai best-practice dari VMware, dimana jika jumlah environment hypervisor kita lebih dari 256 host, maka sangat direkomendasikan untuk me-resize NSX manager dari size standard-default menjadi Large scale (8 vCPU, 24 GB Memory).
Untuk NSX Edge, jenis size yang di deploy berbanding lurus dengan performance dan capacity dari NSX Edge itu sendiri, terutama untuk besar throughput, jumlah VPN tunnel, dan concurrent connection. Untuk detail performance matrix NSX edge saya akan coba share pada postingan yang lain.
Untuk NSX Controller jumlah unit yang dideploy adalah bilangan ganjil (1, 3), namun untuk didalam production harus mendeploy 3 NSX controller untuk redundancy dan failover, sehingga jika suatu saat salah satu NSX Controller mengalami failure controller yang lainnya akan takeover agar tidak terjadi downtime pada system.

More information:
Reference Design: VMware NSX for vSphere (NSX) Network Virtualization Design Guide:https://www.vmware.com/files/pdf/products/nsx/vmw-nsx-network-virtualization-design-guide.pdf 
--

Depok, 18 July 2016
Donny Achmadi

Testing VXLAN Tunnel End Point (VTEP) antar ESXi host



Didalam environment VMWare NSX kita dapat membuat sebuah logical switch yang akan dideploy secara distributed kedalam host-host ESXi yang terdapat didalam Cluster pada sebuah Transport Zone. Yang dimana logical switch tersebut bekerja menggunakan sebuah protocol baru berupa VXLAN, tidak lagi menggunakan VLAN dikarenakan limitasi dari sisi jumlah VLAN ID yang dapat dibuat maksimum hanya 4096.
Jika suatu saat kita mengalami kendala pada koneksi VXAN antar host-host, maka kita harus melakukan pengujian traffic VXLAN antar host yang bermasalah tersebut. Untuk pengujiannya terdapat 2 cara yang dapat dilakukan.
  1. Test PING dengan  ++netstack=vxlan dan MTU
Kita dapat melakukan ini dengan cara masuk kedalam konsol ESXi host via SSH, pertama-tama kita harus mengetahui IP yang digunakan oleh Netstack VXLAN Tunneling End Point (VTEP) di host tujuan dengan cara menjalankan “esxcfg-vmknic –l”

Setelah menemukan ip VTEP pada host tujuan, kemudian melakukan test ping ++netstack=vxlan ke IP VTEP host tujuan dengan load MTU yang dibutuhkan oleh VXLAN (1600) menjalankan command berikut:

vmkping ++netstack=vxlan -s MAXMTU -28 -d destination_Host_VTEP_IP

**MAX MTU disini yang sudah di set pada physical network switch dan VDS adalah 1600, maka dikurangi 28 = 1572

[root@localhost:~] ping ++netstack=vxlan -s 1572 -d 10.10.61.187
PING 10.10.61.187 (10.10.61.187): 56 data bytes
64 bytes from 10.10.61.187: icmp_seq=0 ttl=64 time=1.601 ms
64 bytes from 10.10.61.187: icmp_seq=1 ttl=64 time=0.653 ms
64 bytes from 10.10.61.187: icmp_seq=2 ttl=64 time=0.991 ms

--- 10.10.61.187 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.653/1.082/1.601 ms
[root@localhost:~]

Jika hasilnya adalah reply, maka ini berarti koneksi VTEP antar host sudah OK dan tidak ada masalah.

  1. Test VXLAN pada web-console
Testing VXLAN menggunakan web-console sebenarnya bagi sebagian orang lebih mudah, dikarenakan tidak perlu menghafal command pada ESXi console via SSH dan mencari nomor vmkernel yang digunakan, namun cukup dengan beberapa click testing VXLAN bisa dilakukan.

Caranya adalah dengan akses ke vCenter dan masuk ke menu Networking and Security, selanjutnya masuk ke menu “Logical Switch”. Kita pilih logical switch mana yang sedang mengalami masalah pada koneksinya.


Kemudian klik 2x pada logical switch yang bermasalah dan pilih tab “monitor” dan menu ping, maka disini kita perlu memasukkan parameter berupa source dan destination host


Kita pilih host source dan destination sesuai dengan masalah koneksi antar host yang terjadi dan size of test packet kita pilih VXLAN standard, kemudian klik “Start Test

Jika koneksi VXLAN antar host OK maka akan muncul green sign seperti gambar berikut:

Namun jika terdapat masalah maka akan muncul error message, seperti salahsatunya error berikut:

Permasalahan yang umumnya terjadi pada koneksi VXLAN antar host adalah issue pada MTU size antar host minimum 1600 MTU, maka lakukan crosscheck pada seluruh host didalam cluster pastikan VTEP dan juga pada port di physical networknya sudah menggunakan jumbo frame atau minimum MTU 1600.

Source : KB VMware

Tuesday, May 31, 2016

Troubleshooting Methodology for VMware NSX




Didalam operasional VMware NSX tentunya (berharap semoga tidak) terkadang timbul masalah pada system yang sedang berjalan, dapat diakibatkan oleh banyak hal misalnya: issue konektivitas Antara vCenter Server dan NSX Manager, NSX Manager dengan NSX Controller, Issue konektivitas antar VM melalui VXLAN, dan masalah-masalah lainnya yang sebenarnya tidak diinginkan.
Berikut ini beberapa langkah-langkah terstruktur yang seharusnya dilakukan ketika melakukan troubleshooting didalam system VMware NSX:

1. Define the Problem
Yang sebenarnya terjadi ketika ada masalah didalam system pastinya ada sesuatu yang salah, banyak factor yang mengakibatkan terjadinya masalah seperti: Configuration Issue, Resource contention, terjadinya serangan, adanya Bug pada software, Hardware failure, dan lainnya.
Pada tahap ini kita harus mendefinisikan, atau setidaknya benar-benar mengetahui masalah apa yang sebenarnya sedang terjadi? Untuk memastikan letak masalah apa yang terjadi sebaiknya lakukan hal-hal berikut:

  • Identifying Symptoms
Membandingkan antara masalah yang terjadi dengan gejala-gejala yang ada, contohnya sebagai berikut:
Symptoms
Problem
Komunikasi antar VM di ESXi host yang berbeda bermasalah Test ping menggunakan semua logical switch yang ada di host tersebut bermasalah
Tidak bisa melakukan pendaftaran vSphere Cluster kedalam system NSX Cek log menunjukan “Name or Service is not known”
Dan contoh-contoh lainnya.
Pada hasilnya, kita dapat meng-kerucutkan akar masalah yang sebenarnya terjadi dimana

  • Gathering Information
Mengumpulkan sebanyak-banyaknya informasi yang berkaitan dengan hasil pengerucutan masalah, misalnya IP address dari DNS Server, NTP Server, vNIC yang digunakan sebagai VTEP, jenis metode uplink yang digunakan ke physical switch dan yang lainnya. Hal tersebut akan sangat berguna nantinya, karena akan memudahkan proses verifikasi konfigurasi untuk solving the issue.

  • Identify recent changes
Mengidentifikasi perubahan apa yang baru dilakukan sebelum terjadinya masalah? Akan sangat lucu jika misalnya problem pada konektivitas Logical switch dan ternyata diakibatkan team network sebelumnya melakukan penggantian IP pada VTEP Gateway.


2. Identify the Cause of the Problem
Setelah menentukan masalah apa yang sebenarnya terjadi, beserta data-data yang sudah dikumpulkan, maka seharusnya akan sangat mudah untuk menentukan root-cause dari masalah tersebut, namun untuk menghasilkan analisa yang tepat sebaiknya lakukan 3 proses berikut:

  • Identify possible cause
Mengumpulkan kemungkinan-kemungkinan penyebab masalah, kumpulkan sebanyak-banyaknya

  • Determining the root cause
Menentukan akar dari penyebab masalah yang terjadi pada system NSX, tentunya bukan sekedar “workaround” agar kedepannya problem tidak terjadi lagi.

3. Implement the Resolution
Setelah menentukan akar dari penyebab masalah yang terjadi pada NSX, maka selanjutnya adalah melakukan koreksi dari kesalahan-kesalahan yang terjadi. Namun agar kedepannya problem tersebut tidak terulang, maka perlu untuk melakukan langkah-langkah berikut:

  • Identify possible solution
Mengumpulkan daftar kemungkinan-kemungkinan langkah perbaikan yang akan dilakukan

  • Implementing the best Solution
Perhatikan daftar langkah-langkah perbaikan yang sudah ada, pertimbangkan besar efek dari masing-masing di list tersebut, kemudian pilih solusi yang efeknya tidak akan berpengaruh menimbulkan issue-issue yang lain.

  • Verifying the resolution
Setelah langkah perbaikan dilakukan, lakukan pengetesan dan pengecekan, apakah masalah benar-benar sudah selesai? Adakah masalah lain yang timbul?

  • Document the resolution
Setelah semuanya dijalankan dengan baik dan problem benar-benar telah solved, maka jangan lupa untuk melakukan dokumentasi atas langkah-langkah perbaikan yang sudah dilakukan. Supaya jika dikemudian hari problem yang sama timbul lagi, maka orang lain dapat mengatasinya dengan baik sebagaimana anda telah melakukannya.

In anyway, these are the key point:
  •   Identifikasi troubleshooting secara terstruktur akan membantu kita mengatasi problem secara efektif
  • Identifikasi antara "Gejala" dan "Problem" adalah langkah yang sangat penting didalam proses troubleshooting
  • Selain itu pengetahuan dan Skill yang kita miliki mengenai cara kerja SDDC VMware didalam infrastructure akan sangat membantu untuk mengetahui "What's going on?"
  • Disamping itu juga skill dasar networking yang mumpuni juga akan sangat membantu, dikarenakan troubleshooting Network Virtualization itu tidak terlalu jauh berbeda konsepnya dengan legacy networking.

Untuk tulisan di awal ini sepertinya masih terlalu general, untuk postingan selanjutnya mungkin akan lebih spesifik dan (sangat) teknis serta menguras tenaga :D

Cheers !

Singapore,
31 May 2016

VMware NSX Ninja Bootcamp




Kali ini saya akan coba share sedikit mengenai materi yang sempat saya dapatkan ketika ikut Training Vmware NSX Ninja Bootcamp di Singapore (30 May 2016 – 3 June 2016), untuk Training VMware NSX kali ini cukup berbeda dengan training sebelumnya, yaitu VMware NSX ICM (Install, Configure, Manage) yang fokus sesuai namanya, mulai dari instalasi komponen VMware NSX sampai operasionalnya seperti menambah rule firewall, aktivasi dynamic routing dan lainnya.

Namun pada VMware NSX Ninja kali ini materinya cukup advance, session trainingnya diadakan dalam 2 minggu yang berbeda, pada minggu pertama kami belajar untuk fokus di “Troubleshooting and Operation”, dan di minggu kedua lebih fokus ke “Deployment and Design”. 

Sebenarnya untuk NSX Ninja Program ini para peserta betul-betul diarahkan untuk sertifikasi level expert untuk Network Virtualization VMware NSX yaitu VCIX (VMware Certified Implementation Expert), melihat kata-kata expert agak merinding sebenarnya, karena dibenak saya Expert level itu setara dengan apa yang ada pada CCIE (Cisco Certified Internetworking Expert) usahanya berat, belajarnya berat, namun memang jika benar-benar diusahakan dengan serius pasti hasilnya memuaskan :D

Begitu pula lah dengan NSX Ninja Program kali ini, benar-benar Hands-on untuk LAB yang berdasarkan real-world operational dari VMware NSX, sehingga kandidat yang berhasil lulus VCIX sudah terbukti kemampuannya didalam pengelolaan system VMware NSX mulai dari Design, Deployment, dan operationalnya sesuai dengan blueprint skill yang beragam.
Berikut beberapa coret-coretan saya mengenai materi yang saya dapatkan, bukan untuk mengejar apa-apa, tak lain agar ilmu yang sudah didapat tidak hilang begitu saja tertelan kesibukan, hhaa. Dan disamping itu semoga ilmunya bermanfaat buat orang banyak, atau juga bisa jadi bahan contekan saya kedepannya jika ada deployment VMware NSX :D



Don't hesitate to give any input or comment for me :)

Donny Achmadi