4.1 Instalasi ESX Server
Instalasi ESX server dapat dilakukan dalam mode grafis atau dalam mode teks hitam putih yang membatasi kerumitan konfigurasi layar selama instalasi. Sebelum kita melangkah satu demi satu mengikuti proses instalasi ESX server, adalah penting untuk diketahui. Penting untuk mengkaji beberapa komponen fungsional dari arsitektur hard disk yang terdapat di atas ESX Server yang akan diinstal. Karena bermula pada Red Hat Linux, ESX Server tidak menggunakan nama huruf pada drive untuk mewakili partisi dari disk fisik. Sebaliknya, ESX Server seperti linux menggunakan mount point untuk mewakili berbagai partisi.
Menggunakan mount point untuk berbagai direktori di bawah sistem file root dapat melindungi sistem file root dengan tidak membiarkan sebuah direktori mengkonsumsi begitu banyak ruang sehingga root akan menjadi penuh. Jika kita mengambil contoh sistem operasi Microsoft, seringkali sistem operasi berjalan pada drive C. Dan apa yang akan terjadi bila drive C kehabisan ruang penyimpanan? Sistem operasi akan mengalami kemungkinan menggantung (Hang). Pada ESX server, hal itu tidak terjadi.
Gambar 4.1 Perbedaan partisi drive antara Windows dan Linux
Untuk tahap installasi ESX server tidak bisa diselesaikan hanya dengan menekan tombol Next sampai tombol Finish muncul seperti yang sering dilakukan ketika kita sedang menginstallasi sistem operasi windows dan sejenisnya. Ada
beberapa keputusan penting yang harus dibuat ketika proses installasi sedang berjalan, keputusan yang mempengaruhi proses berjalannya ESX server nanti serta dapat juga menyebabkan kerusakan parah pada data atau mesin virtual perusahaan. Untuk alasan ini, penting bagi sebuah admin yang berpengalaman atau instruktur bersertifikat resmi dari VMware untuk membaca bagian ini dengan seksama dan memahami bagaimana cara terbaik untuk menginstall ESX server ini dalam membuat sebuah VMware Infrastruktur.
Berikut langkah-langkah yang dilakukan untuk menginstallasi sebuah ESX server 3.5 dari sebuah CD:
1. Masuk ke BIOS, pilih untuk boot dari CD. Masukkan CD VMware ESX server 3.5 lalu restart komputer.
2. Pilih mode installasi grafis dengan menekan tombol enter pada layar.
Gambar 4.2 Proses awal instalasi.
Gambar 4.3 Testing CD media.
4. Tekan tombol Next pada layar selamat datang di ESX server 3.5. 5. Pilih susunan keyboard yang sesuai, biasanya U.S English 6. Pilih koneksi mouse yang sesuai, (PS/2, USB, Serial)
Gambar 4.4 ESX server mendukung berbagai pilihan mouse.
7. Tekan tombol Yes untuk melakukan inisialisasi perangkat yang akan digunakan untuk menyimpan instalasi partisi ESX server 3.5.
Gambar 4.5 Konfirmasi inisialisasi perangkat.
8. Cek list kotak yang berlabel “I accept the terms of the License Agreement” dan tekan tombol Next.
Gambar 4.6 End user License Agreement.
Gambar 4.7 Petunjuk instalasi ESX server. 10.Tekan tombol Yes pada peringatan penghapusan partisi.
11.Tinjauan ulang strategi partisi, untuk melanjutkan tekan tombol Next.
Gambar 4.8 Partisi standar ESX server 3.5.
12.Pastikan telah memilih untuk boot dari drive yang sama yang telah dipilih untuk dipartisi. Untuk menghindari kesalahan konfigurasi pada instalasi tersebut, lakukan pada disk local tetapi server melakukan boot dari LUN SAN, atau sebaliknya. Tekan tombol Next
Gambar 4.9 Konfigurasi standar.
13.Pilih Network Interface Card (NIC) yang dilalui sebuah konsol layanan untuk berkomunikasi. Berikan alamat IP yang valid, subnet mask, default gateway, dan DNS server.
Gambar 4.11 Root password.
16.Meninjau ulang konfigurasi parameter instalasi yang telah diberikan. Tekan tombol Next.
Gambar 4.12 Peninjauan ulang. 17.Proses instalasi akan dimulai.
18.Jika instalasi telah selesai tekan tombol Finish untuk booting ulang.
Gambar 4.14 Proses instalasi berhasil.
19.Selama proses booting ulang, GRUB boot loader akan menampilkan pilihan booting. Pastikan pilih VMware ESX Server terpilih, kemudian tekan enter.
Gambar 4.16 Tampilan final setelah instalasi ESX server. Installasi VI Client
Untuk dapat melakukan instalasi VI Client, unduh dan install versi terbaru dari Microsoft.NET Framework, setelah itu install VI Client sbb:
1. Buka web browser Modzila / IE.
2. Isikan alamat IP ESX server yang telah diinstall sebelumnya. 3. Tekan tombol Download the VMware Infrastructure Client. 4. Jalankan paket instalasi VI Client.
Setelah selesai proses instalasi VI Client, untuk terhubung kedalam servis konsol yang telah ESX Server sediakan, caranya adalah:
1. Buka aplikasi VI Client 2. Masukkan hal-hal berikut:
Nama server DNS atau alamat IP. Login menggunakan root server. Kata sandi root server.
3. Kemudian OK.
Gambar 4.18 Login VIC
Tampilan yang akan terbuka terlihat seperti gambar 4.19, tiap-tiap layar terbagi menjadi tiga bagian:
Inventory: (sebelah kiri atas) area sebelah sini menunjukkan masing-masing status terakhir VM pada server anda.
Konfigurasi: (sebelah kanan atas) pada area ini adalah tempat untuk melakukan konfigurasi VM dan tugas-tugas.
Recent task: (bawah) pada area ini menunjukkan status yang sedang dan yang telah menyelesaikan tugas.
Gambar 4.19 VMware Infrastuktur Client
4.2 Implementasi
Sesuai dengan kebutuhan sistem yang telah dipaparkan pada Bab IV mengenai kebutuhan sistem, virtualisasi server pada PT. XYZ diimplementasikan untuk membangun layanan Jasa Nilai Tambah (VAS) cloud computing.
4.2.1 Infrastruktur Server Fleksibel terhadap Maintenance
Infrastruktur virtualisasi server di PT. XYZ telah memenuhi persyaratan VMotion yang disebutkan pada Bab 2.10. Ketiga mesin server host memiliki
spesifikasi yang sama, sehingga syarat kompatibilitas prosesor terpenuhi. VirtualCenter Server telah dikonfigurasi untuk mendukung klaster, VMotion, dan DRS. Syarat jaringan privat terpenuhi, yaitu menggunakan salah satu dari 2 NIC yang tersedia di mesin host. Media penyimpanan datamenggunakan file system
VMFS yang terhubung dengan SAN, sehingga syarat terakhir VMotion terpenuhi. Implementasi untuk menyediakan infrastruktur server yang fleksibel terhadap perawatanperangkat keras dilakukan dengan fitur VMotion. Ketika akan dilakukan perawatan terhadap perangkat keras mesin server host, administrator
fitur VMotion. Ketika perawatan selesai dilakukan, administrator dapat mengembalikan VM-VM ke host asalnya.
Gambar 4.20 menunjukkan diagram alir migrasi VM secara individual. Administrator menginisiasi migrasi VM. Kemudian VC Server mengevaluasi apakah syarat-syarat VMotion terpenuhi. Apabila syarat VMotion tidak terpenuhi, maka proses migrasi VM tidak akan dilakukan. Setelah klaster dinyatakan memenuhi syarat VMotion, administrator dapat melanjutkan dengan memilih VM untuk dimigrasi ke host lain. Administrator harus menentukan sendiri host yang
sesuai sebagai tujuan migrasi VM karena proses migrasi ini dilakukan secara manual. Langkah berikutnya adalah memilih prioritas migrasi. Selanjutnya proses migrasi dilaksanakan oleh VC Server.
Migrasi VM selain membutuhkan ruang memori dan ketersediaan prosesor bagi VM, juga membutuhkan sumber daya host untuk proses migrasi itu sendiri.
Tersedia 2 macam prioritas migrasi yang dapat dipilih yaitu low priority dan high priority. Low priority yaitu migrasi akan tetap dilaksanakan tanpa ada
pencadangan (reservation) sumber daya (resource) prosesor dan memori di host
asal dan tujuan. Jika sumber daya di host asal dan tujuan tidak cukup, maka dapat
timbul dampak pada ketersediaan layanan VM tersebut. Pada high priority, VC
Server akan mencadangkan (reserve) sumber daya host asal dan tujuan, sehingga
tersedia sumber daya yang cukup untuk proses migrasi. Apabila sumber daya kedua host tidak mencukupi, proses migrasi tidak dapat dilakukan. High priority
harus digunakan secara hati-hati, karena dapat menyebabkan prosesor di kedua
MULAI Syarat vMotion Terpenuhi? Pilih VM untuk migrasi Pilih target host Pilih prioritas migrasi High priority? Resource host
asal dan tujuan cukup? Migrasi VM ke host tujuan BERHENTI YA YA YA TIDAK TIDAK TIDAK
Gambar 4.20 Diagram Kerja implementasi VMotion 4.2.2 Infrastruktur Server Fleksibel terhadap Beban Kerja
Infrastruktur virtualisasi server PT. XYZ mendukung fitur VMotion, sehingga juga mendukung fitur DRS. DRS dapat diimplementasikan untuk mengoptimalkan utilisasi sumber daya prosesor dan memori host dengan
memantau dan memindahkan VM dari host yang memiliki beban kerja tinggi ke host yang memiliki beban kerja rendah. Hal ini menjadikan infrastruktur server
fleksibel karena sumber daya dapat dialokasikan sesuai dengan beban kerja yang dialami host.
Diagram alir implementasi DRS dapat dilihat pada Gambar 4.21 VCServer secara terus-menerus melakukan pengawasan beban kerja host.
Jikamenemukan host yang memiliki beban kerja melebihi batas yang telah
ditetapkan oleh administrator, maka VC Server akan mencari host lain yang
memiliki utilisasi prosesor dan memori yang masih rendah. VC Server kemudian melakukan pengecekan mode DRS yang telah ditetapkan oleh administrator. Jika
DRS dalam mode manual, maka DRS hanya akan memberikan rekomendasi ke
administrator untuk melakukan migrasi VM. Administrator dapat menerima atau menolak rekomendasi yang diberikan DRS. Namun dalam mode otomatis, migrasi
MULAI
Pengawasan beban kerja host
Apakah ada host yang melebihi batas
beban kerja? Mencari host dengan resource berlebih Apakah migrasi otomatis? Rekomendasi ke administrator Migrasi disetujui administrator? Migrasi VM ke host tujuan BERHENTI TIDAK TIDAK TIDAK YA YA YA
Gambar 4.21 Diagram Kerja implementasi DRS
4.3 Skenario dan Pengujian VMotion
Pengujian pertama dilakukan untuk melihat pengaruh migrasi VM terhadap kondisi VM. Desain pengujian ini dapat dilihat di Gambar 4.22. Gambar 4.22, 4.23, dan 4.24 disusun menggunakan icon-icon resmi dari VMware
(Stephens, 2010). Berikut adalah skenario dan langkah-langkah yang dilakukan dalam pengujian ini:
1. Mengirimkan paket ICMP dari PC A ke alamat IP VM yang akan dipindahkan (migrasi). Pengiriman paket ICMP dilakukan dengan mengeksekusi perintah „ping x -t‟ melalui command prompt, dengan x
adalah alamat IP dari VM yang dimigrasi, 2. Memindahkan VM dari host 1 ke host 2,
3. Menghentikan pengiriman paket ICMP beberapa saat setelah proses migrasi selesai,
4. Menghitung jumlah paket yang hilang (request timed out) berdasarkan
keluaran di command prompt.
Gambar 4.22 Desain pengujian dan pengaruh migrasi VM 4.3.1 Kondisi Sebelum Migrasi
Gambar 4.23 dan 4.24 menunjukkan posisi VM di host 1 dan host 2. VM
yang aktif ditandai dengan tulisan „Powered on‟ pada kolom „State‟. Pada Gambar
4.23 terdapat 3 VM yang aktif di host 1 (esxho1), yaitu:
TCI-VAP1-JKT, TCIVAP2- JKT, dan
Gambar 4.23 Posisi VM di host 1 sebelum migrasi
Gambar 4.24 menunjukkan bahwa terdapat 4 VM yang aktif di host 2
(esxho2), yaitu:
TCI-CITRIX2-JKT, TCI-VCACHE-JKT, TCI-VAR-JKT, dan TCI VSCCMJKT.
Gambar 4.24 Posisi VM di host 2 sebelum migrasi
4.3.2 Proses Migrasi VM
Gambar 4.25 menunjukkan inisiasi migrasi VM. VM yang akan migrasi adalah TCI-VAR-JKT yang aktif di host 2. VM tersebut disimpan di datastore
Active Directory Role. Untuk memulai langkah-langkah migrasi, administrator melakukan „klik kanan‟ pada VM yang bersangkutan, kemudian dilanjutkan dengan memilih opsi „Migrate‟.
Gambar 4.25 Inisiasi migrasi VM
Langkah selanjutnya adalah memilih host tujuan migrasi. Dalam pengujian
ini, VM TCI-VAR-JKT akan dipindahkan dari host 2 ke host 1. Hal ini dapat
dilihat di Gambar 4.26.
Gambar 4.26 Pemilihan host tujuan migrasi
Gambar 4.27Pemilihan prioritas migrasi
Pada Gambar 1.6 dapat dilihat bahwa proses migrasi VM TCI-VAR-JKT dimulai pada tanggal 25 Maret 2012 pukul 14:04:42.
Gambar 4.28 Proses migrasi VM dimulai
Pada gambar 4.29 dapat dilihat bahwa proses migrasi selesai pada tanggal 25 Maret 2012 pukul 14:05:58. Jadi durasi migrasi VM 76 detik.
Gambar 4.29 Migrasi VM berhasil dilakukan 4.3.3 Hasil Pengujian
Gambar 4.30 menunjukkan keluaran program „ping‟. Dari total 534 paket yang dikirimkan ke VM TCI-VAR-JKT, terdapat 1 paket yang hilang (request timed out).
Gambar 4.30 Satu kali RTO pada pengiriman paket ICMP
Ping statistics for 10.90.1.16:
Packets: Sent = 534, Received = 533, Lost = 1 (0% loss), Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 6ms, Average = 0ms
4.3.4 Kondisi setelah migrasi
Gambar 4.31 Posisi VM pada host 1 setelah migrasi
Gambar 4.32 Posisi VM pada host 2 setelah migrasi
4.3.5 Pembahasan
Pengujian ini dilakukan melalui komputer yang terhubung ke jaringan lokal perusahaan melalui pusat data. Sehingga hasil pengujian ini cukup akurat untuk menggambarkan kondisi ketersediaan VM kepada pengguna ketika migrasi VM dilakukan.
Ketersediaan suatu komputer dapat diketahui dengan pengiriman paket ICMP, yaitu suatu metode pengiriman pesan di antara 2 komputer. Apabila komputer pengirim pesan tidak menerima jawaban (reply) dalam selang waktu
tertentu, dapat dikatakan bahwa komputer tujuan tidak aktif atau tidak tersedia (unavailable). Pada Tabel 4.1 dapat dilihat bahwa terdapat 1 paket yang hilang.
Paket yang hilang, atau dikenal sebagai request timed out (RTO), menunjukkan
bahwa ketika migrasi dilakukan, terdapat selang waktu di mana VM tidak terhubung ke jaringan produksi. Pada bagian tersebut dijelaskan fase-fase migrasi VM menggunakan VMotion. Terdapat fase dalam proses migrasi VM di mana VM dihentikan sementara waktu (paused) untuk sinkronisasi memori bitmap dan
di host tujuan, VM tidak terhubung ke jaringan sehingga tidak dapat memberikan
layanan.
Kondisi VM yang tidak aktif merupakan satu-satunya penyebab paket yang hilang. Kondisi peralatan jaringan dan media komunikasi data juga dapat menyebabkan paket hilang, namun penyebab ini dapat dieliminasi. Hal ini karena komputer yang digunakan untuk menjalankan program „ping‟ terhubung secara
local dengan host. Kedua mesin tersebut saling terhubung melalui core switch.
Perangkat switch yang kita kenal saat ini dapat dikatakan tidak memiliki paket drop, karena penggunaan buffer. Penggunaan kabel tembaga sebagai media
komunikasi data juga memastikan tidak ada paket yang hilang. Satu-satunya kemungkinan paket hilang adalah di perangkat router, namun skema pengujian ini tidak menggunakan perangkat tersebut. Ini berarti satu-satunya penyebab paket yang hilang adalah VM yang tidak aktif.
Tabel 4.1 Hasil pengiriman paket ICMP Paket dikirim Paket diterima Paket hilang
543 533 1
Pengitungan durasi downtime secara tepat cukup sulit untuk dilakukan
dalam pengujian ini. Program „ping‟ sistem operasi Windows XP memiliki default timeout pengiriman paket selama 4 detik. Paket akan dianggap hilang apabila
selama 4 detik, komputer pengirim paket tidak menerima balasan. Terdapat 1 paket hilang, artinya dalam sudut pandang program „ping‟, durasi downtime yang
terjadi maksimal selama 4 detik, walaupun dalam kejadian nyata durasi downtime
jauh lebih singkat. Durasi downtime VM cukup singkat karena dukungan SAN
layanan FTP.
4.4 Skenario dan Pengaruh Migrasi VM terhadap Ketersediaan Layanan
FTP
Pengujian kedua dilakukan untuk melihat pengaruh migrasi VM terhadap ketersediaan layanan FTP. Desain pengujian ini dapat dilihat di Gambar 4.33. Berikut adalah skenario dan langkah-langkah yang dilakukan dalam pengujian ini: 1. Mengirimkan file minix_R3.1.6-r6084.iso yang memiliki ukuran 609 MB
(638,582,784 bytes) dari PC A ke VM FTP Server, 2. Melihat durasi pengiriman file minix_R3.1.6-r6084.iso,
3. Menghitung message digest MD5 dari file minix_R3.1.6-r6084.iso
menggunakan program MD5Command Line Message Digest Utility, 4. Memindahkan VM dari host 1 ke host 2,
5. Mengirimkan file minix_R3.1.6-r6084.iso dari PC A ke VM FTP Server, ketika VM tersebut sedang migrasi,
6. Melihat durasi pengiriman file minix_R3.1.6-r6084.iso,
7. Membandingkan durasi pengiriman file minix_R3.1.6-r6084.iso ketika VM tidak migrasi dengan durasi ketika VM sedang migrasi,
8. Menghitung message digest MD5 dari file minix_R3.1.6-r6084.iso,
kemudian membandingkan dengan message digest yang telah dihitung
Gambar 4.33 Desain pengujian pengaruh migrasi VM terhadap layanan transfer file
4.4.1 Pengiriman file ke VM FTP Server yang Tidak Migrasi
Berikut ini adalah pengecekan ukuran file yang akan dikirimkan menggunakan layanan FTP. Ukuran file yang akan dikirimkan adalah 638,582,784 bytes.
XP. Pengiriman file berhasil dalam durasi waktu 90,44 detik.
4.4.2 Pengiriman file ke VM FTP Server yang Migrasi
Berikutnya adalah pengiriman file ke VM FTP Server yang migrasi. Pertama, message digest file yang akan dikirimkan dihitung menggunakan
program MD5 Command Line Message Digest Utility. Message digest yang
dihasilkan adalah A5B94D8488398FA6C8F53F7EFC13E990. Penghitungan dilakukan di komputer yang bertindak sebagai client FTP, dengan alamat IP
Gambar 4.34 menunjukkan file-file yang tersimpan di VM FTP Server sebelum pengiriman file minix_R3.1.6-r6084.iso dilakukan. Alamat IP yang digunakan sebagai VM FTP Server adalah 10.90.1.16.
4.4.3 Checksum file setelah pengiriman file selesai
Penghitungan message digest file minix_R3.1.6-r6084.iso pada VMFTP
Server menunjukkan hasil dengan nilai yang sama (A5B94D8488398FA6C8F53F7EFC13E990) dengan penghitungan file pada komputer client.
Kondisi VM FTP Server Durasi pengiriman File Tidak Migrasi 90,44 Detik
Migrasi 100,61 Detik
Terdapat perbedaan durasi pengiriman file ke VM FTP Server. Ketika VM FTP Server tidak migrasi, durasi waktu pengiriman file adalah 90,44 detik. Durasi pengiriman file bertambah ketika VM tersebut mengalami migrasi, yaitu menjadi 100,61 detik. Terdapat perbedaan waktu sebesar 10,17 detik yang menunjukkan bahwa terjadi penurunan performa layanan pengiriman file pada VM FTP Server yang sedang mengalami migrasi.
Pada sesi pengujian pengiriman file dengan kondisi VM migrasi, message digest file sebelum pengiriman menunjukkan nilai yang sama dengan message digest setelah file diterima oleh VM FTP Server. Hal ini menunjukkan bahwa file
yang dikirimkan tidak mengalami kerusakan (corrupt).
Layanan FTP menggunakan protokol TCP, yang memastikan paket data telah diterima dengan baik oleh komputer tujuan. Jika ada paket data yang rusak atau hilang, maka paket data tersebut akan dikirim ulang. Pengujian 4.2 menunjukkan bahwa terdapat 1 kali request timed out (RTO). Artinya dalam
selang waktu yang singkat, VM FTP Server tidak tersedia ke pengguna. Kondisi tersebut tidak mempengaruhi integritas file yang dikirimkan, karena paket-paket yang hilang akan dikirimkan kembali.
Tabel 4.3 Message digest MD5
Waktu pemeriksaan Hasil MD5 checksum
Sebelum pengiriman A5B94D8488398FA6C8F53F7EFC13E990 Setelah pengiriman A5B94D8488398FA6C8F53F7EFC13E990
Hasil pengujian menunjukkan bahwaVMotion berpengaruh terhadap kondisi VM. VM yang tidak aktif dalam selang waktu singkat tidak menyebabkan file yang dikirimkan menjadi rusak, namun berpengaruh pada durasi pengiriman
file. Terdapat penundaan (delay) karena pengiriman ulang sejumlah paket data.
Hal ini mengakibatkan durasi pengiriman file menjadi lebih lama dibandingkan ketika VM tidak migrasi. Penggunaan jaringan privat, Gigabit Ethernet, dan SAN menyebabkan perbedaan durasi tersebut relatif tidak besar. Perbedaan durasi tersebut dapat saja menjadi lebih besar apabila jaringan yang digunakan sebagai jalur migrasi VM juga digunakan sebagai jalur produksi perusahaan. Hal tersebut tidak dibahas dalam penelitian ini dan masih perlu dibuktikan kebenarannya.
VM yang tidak aktif dalam selang waktu singkat juga tidak menyebabkan terputusnya sesi layanan FTP, sehingga pengguna tidak menyadari proses migrasi VM. Hal ini didapat dijelaskan karena migrasi menjaga state VM, termasuk di
dalamnya TCP control block untuk koneksi yang sedang aktif dan state aplikasi.
Hal yang terpenting adalah pengguna dapat meneruskan pekerjaannya tanpa terganggu dengan proses migrasi VM.
Pengujian pengiriman file pada VM FTP Server menunjukkan bahwa terdapat penurunan performa layanan pada VM yang sedang migrasi. Penurunan performa tersebut berupa penundaan yang menyebabkan durasi pengiriman file menjadi lebih lama dibadingkan dengan VM tanpa migrasi. Pengujian tersebut juga menunjukkan bahwa sesi layanan FTP tidak terputus dan file yang dikirimkan tidak mengalami kerusakan. Hal ini menunjukkan bahwa gangguan yang terjadi pada layanan akibat migrasi VM masih dapat ditoleransi. Dengan demikian, dapat disimpulkan bahwa downtime yang terjadi ketika migrasi VM
tidak mempengaruhi ketersediaan layanan FTP.
pada masing-masing host setelah pemindahan VM,
3. Mengawasi proses DRS,
4. Melihat grafik utilisasi prosesor, grafik utilisasi memori dan posisi VM pada masing-masing host setelah proses DRS selesai.
Gambar 4.36 Desain pengujian pengaruh DRS terhadap utilisasi prosesor dan memori host
4.5.1 Kondisi Host 1 sebelum DRS
Gambar 4.37 menunjukkan utilisasi prosesor dan memori di host 1
sebelum DRS. Utilisasi prosesor sebesar 2312 MHz dan utilisasi memori sebesar 7,53 GB.
Gambar 4.37 Utilisasi prosessor dan memori host 1 sebelum DRS
Gambar 4.38 menunjukkan beberapa VM yang aktif di host 1 sebelum
DRS. Terdapat 5 VM yang aktif pada host 1, yaitu:
VAP2-JKT, VAR-JKT, VFP1-JKT, VCACHE-JKT, TCI-VAP1-JKT.
Gambar 1.15 menunjukkan utilisasi prosesor dan memori di host 2
sebelum DRS. Utilisasi prosesor sebesar 218 MHz dan utilisasi memori sebesar 2,83 GB.
Gambar 4.39 Utilisasi prosessor dan memori host 2 sebelum DRS
Gambar 1.16 menunjukkan beberapa VM yang aktif di host 2 sebelum
DRS. Terdapat 2 VM yang aktif, yaitu: TCI-CITRIX2-JKT dan TCI-VSCCM-JKT.
4.5.3 Kondisi Host 3 sebelum DRS
Gambar 4.41 menunjukkan utilisasi prosesor dan memori di host 3
sebelum DRS. Utilisasi prosesor sebesar 1130 MHz dan utilisasi memori sebesar 6,59 GB.
Gambar 4.41 Utilisasi prosessor dan memori host 3 sebelum DRS
Gambar 4.42 menunjukkan beberapa VM yang aktif di host 3 sebelum
DRS. Terdapat 4 VM yang aktif, yaitu:
Gambar 4.43 menunjukkan utilisasi prosesor dan memori di host 1 setelah
DRS. Utilisasi prosesor sebesar 1886 MHz dan utilisasi memori sebesar 7,02 GB. Utilisasi prosesor dan memori mengalami penurunan sebesar 426 MHz dari 2312 MHz dan 0,51 GB dari 7,53 GB.
Gambar 4.43 Utilisasi prosessor dan memori host 1 setelah DRS
Gambar 4.44 menunjukkan beberapa VM yang aktif di host 1 setelah
DRS. Terdapat 2 VM yang berpindah ke host lain, sehingga tersisa 3 VM yang
aktif yaitu:
TCI-VAP1-JKT, TCI-VAP2-JKT, TCI-VFP1-JKT.
Sedangkan untuk 2 VM; TCI-VCACHE-JKT dan TCI-VAR-JKT didistribusikan ke host 2.
4.5.5 Kondisi Host 2 setelah DRS
Gambar 4.45 menunjukkan utilisasi prosesor dan memori di host 2 setelah
DRS. Utilisasi prosesor sebesar 800 MHz dan utilisasi memori sebesar 6,75GB. Utilisasi prosesor dan memori mengalami kenaikan sebesar 528 MHz dari 218 MHz dan 3,92 GB dari 2,83 GB sebelum DRS.
Gambar 4.45 Utilisasi prosessor dan memori host 2 setelah DRS
Gambar 4.46 menunjukkan beberapa VM yang aktif di host 2 setelah
DRS. Host 2 menerima tambahan 2 VM dari host 1, yaitu:
TCI-VAR-JKT dan TCI-VCACHEJKT, sehingga jumlah VM yang aktif berjumlah 4 VM.
Gambar 4.47 menunjukkan utilisasi prosesor dan memori di host 3 setelah
DRS. Utilisasi prosesor sebesar 1394 MHz dan utilisasi memori sebesar 6,84 GB. Utilisasi prosesor dan memori mengalami kenaikan sebesar 264 MHz dari 1130 MHz dan 0,25 GB dari 6,59 GB sebelum DRS.
Gambar 4.47 Utilisasi prosessor dan memori host 3 setelah DRS
Gambar 4.48 menunjukkan beberapa VM yang aktif di host 3 setelah
DRS. Tidak terjadi perubahan jumlah VM, yaitu jumlahnya tetap 4 VM.
Gambar 4.48 Posisi VM di host 3 setelah DRS
4.5.7 Hasil Pengujian dan Pembahasan
Tabel 4.4 menunjukkan utilisasi prosesor, utilisasi memori, dan jumlah VM yang aktif di ketiga host yang tergabung dalam klaster. Dapat dilihat bahwa utilisasi prosesor ketiga host masih rendah. Kondisi ini juga dialami oleh sebagian
besar server, seperti yang telah dijelaskan pada Bagian 2.4. Di lain sisi, utilisasi memori relatif lebih tinggi dibandingkan dengan utilisasi prosesor. Kemungkinan
utilisasi memori untuk memicu DRS lebih besar dibandingkan dengan utilisasi prosesor.
Tabel 4.4 Kondisi klaster sebelum DRS
Host Utilisasi prosesor (persentase) Utilisasi memori (persentase) VM aktif 1 2312 MHz (10,86%) 7,54 GB (94,25%) 5
2 218 MHz (1,02%) 2,83 GB (35,37%) 2
3 1130 MHz (5,31%) 6,59 GB (82,37%) 4
Dalam infrastruktur virtualisasi server yang dibangun dengan VI3, administrator dapat memberikan aturan-aturan ke sejumlah host yang tergabung di
klaster. Salah satu aturan tersebut adalah tingkat evaluasi DRS. Aturan tersebut digunakan sebagai penentuan batas utilisasi prosesor atau memori di masing-masing host, sehingga mesin server tetap bekerja dalam kondisi optimal. Jika
utilisasi prosesor atau memori di suatu host melebihi batas yang telah ditentukan,
DRS akan dijalankan secara otomatis. Dalam infrastruktur virtualisasi server PT. XYZ, masing-masing host diberikan aturan batas utilisasi prosesor dan memori
sebesar 90%.
Pada pengujian yang dilakukan, utilisasi memori host 1 mencapai 7,54 GB
atau mencapai persentase sebesar 94,25% dari kapasitas memori 8,00 GB. Kondisi ini melebihi batas utilisasi memori yang telah ditetapkan sehingga memicu DRS. Administrator telah mengatur agar DRS berjalan secara otomatis sehingga permasalahan berkaitan dengan beban kerja berlebih dapat diatasi tanpa kehadiran administrator di ruang server. Kondisi klaster setelah proses DRS selesai, dapat dilihat di Tabel 4.5.
berkurang menjadi 7,02 GB atau 87,75% dari kemampuan memori. Kondisi tersebut berhasil menekan utilisasi memori hingga di bawah batas utilisasi yang telah ditetapkan. Di lain sisi, utilisasi memori host 2 meningkat menjadi 6,75 GB
atau mencapai persentase sebesar 84,37%. Peningkatan utilisasi memori di host 2
merupakan efek dari DRS. Pada kondisi awal yang dapat dilihat di Tabel 4.4, host
2 memiliki utilisasi memori sebesar 2,83 GB. Utilisasi memori tersebut lebih rendah dibandingkan dengan utilisasi memori dari host 3, yaitu sebesar 6,59 GB
sehingga ketika VC Server melakukan evaluasi, host 2 terpilih sebagai tujuan
migrasi sejumlahVM dari host 1.
Terdapat 2 VM yang mengalami migrasi dari host 1 ke host 2. Setelah
proses DRS selesai, jumlah VM yang berjalan di dalam host 1 berjumlah 3,
sedangkan di host 2 terdapat 4 VM.Utilisasi prosesor danmemori host 1 lebih
besar dibandingkan dengan host 2, walaupun jumlah VM di host 1 lebih sedikit
dibandingkan dengan host 2. Hal ini berarti jumlah VM tidak selalu berbanding
lurus dengan utilisasi prosesor dan memori, namun utilisasi tersebut bergantung dari beban kerja masing-masing VM. VC Server mengevaluasi dan menentukan sejumlah VM yang sesuai untuk dipindahkan dari suatu host yang utilisasi
prosesor atau memorinya melebihi batas.
Pengujian ini menunjukkan bahwa implementasi DRS pada infrastruktur virtualisasi server dapat menjaga utilisasi prosesor dan memori mesin server dalam kondisi optimal. Secara fleksibel, sumber daya prosesor dan memori sejumlah host yang tergabung dalam klaster dapat dialokasikan mengikuti
kenaikan beban kerja VM. Hal ini dapat terjadi karena infrastruktur server dibangun menggunakan konsep virtualisasi, di mana sumber daya perangkat keras tidak terikat dengan perangkat lunak aplikasi. DRS merupakan implementasi dari VMotion sehingga dapat digeneralisasi bahwa DRS tidak menganggu ketersediaan layanan.
