BAB IV IMPLEMENTASI DAN PENGUJIAN INFRASTRUCTURE AS A SERVICE. Gambar 4.1 Perbedaan partisi drive antara Windows dan Linux

Transkripsi

1 BAB IV IMPLEMENTASI DAN PENGUJIAN INFRASTRUCTURE AS A SERVICE 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 83

2 84 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. 3. Tekan tombol Test jika ingin mengidentifikasi adanya error pada media instalasi, tekan Skip untuk melanjutkan.

3 85 Gambar 4.3 Testing CD media. 4. Tekan tombol Next pada layar selamat datang di ESX server 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.

4 86 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. 9. Pilih pilihan tombol radio Recommended untuk mengizinkan petunjuk instalasi agar secara otomatis mempartisi disk lokal. Pastikan bahwa opsi disk lokal dipilih dalam daftar drop-down pada instalasi ESX Server. Untuk melindungi data VMFS yang sudah ada, pastikan bahwa Keep Virtual Machines and the VMFS (Virtual Machine File System) That Contains Them dipilih. Kemudian tekan Next.

5 87 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 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

6 88 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.10 Konfigurasi jaringan. 14. Pilih Zona waktu yang sesuai untuk ESX server, kemudian tekan Next. 15. Isi dan ulangi kata sandi dibawah, kemudian tekan Next.

7 89 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. Gambar 4.13 Proses instalasi.

8 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.15 Booting ESX server. 20. Setelah selesainya booting ulang server, konsol akan menampilkan informasi untuk mengakses server dari komputer jarak jauh.

9 91 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. Gambar 4.17 Tampilan ESX server Web page.

10 92 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 masingmasing 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.

11 93 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 Infrastruktur Server Fleksibel terhadap Maintenance Infrastruktur virtualisasi server di PT. XYZ telah memenuhi persyaratan VMotion yang disebutkan pada Bab 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 perawatan perangkat keras dilakukan dengan fitur VMotion. Ketika akan dilakukan perawatan terhadap perangkat keras mesin server host, administrator dapat memindahkan seluruh VM di dalam host tersebut ke host lain menggunakan

12 94 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 host mempunyai beban kerja yang sangat tinggi.

13 95 MULAI Syarat vmotion Terpenuhi? TIDAK YA Pilih VM untuk migrasi Pilih target host Pilih prioritas migrasi High priority? TIDAK YA TIDAK Resource host asal dan tujuan cukup? YA Migrasi VM ke host tujuan BERHENTI Gambar 4.20 Diagram Kerja implementasi VMotion 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

14 96 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 VM akan dilakukan tanpa persetujuan administrator.

15 97 MULAI Pengawasan beban kerja host Apakah ada host yang melebihi batas beban kerja? YA TIDAK Mencari host dengan resource berlebih TIDAK Apakah migrasi otomatis? YA Rekomendasi ke administrator Migrasi disetujui administrator? TIDAK YA Migrasi VM ke host tujuan BERHENTI 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 Gambar 4.22, 4.23, dan 4.24 disusun menggunakan icon-icon resmi dari VMware

16 98 (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 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 TCI-VFP1-JKT.

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

18 100 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 Gambar 4.26 Pemilihan host tujuan migrasi Berikutnya administrator memilih prioritas migrasi. Prioritas migrasi VM tersebut diatur dalam mode high priority sehingga kedua host yang terlibat dalam migrasi menyisihkan (reserve) sebagian sumber daya prosesor dan memori untuk proses migrasi VM. Hal ini dapat dilihat di Gambar 4.27.

19 101 Gambar 4.27 Pemilihan 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.

20 102 Gambar 4.29 Migrasi VM berhasil dilakukan 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 : Packets: Sent = 534, Received = 533, Lost = 1 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 6ms, Average = 0ms Kondisi setelah migrasi Gambar 4.31 dan 4.32 menunjukkan posisi VM yang aktif di host 1 dan host 2 setelah proses migrasi VM selesai. Pada Gambar 4.31 terlihat bahwa VM TCI-VARJKT telah aktif di host 1. Jumlah VM yang aktif di host 2 menjadi 3 VM, dari keadaan awal berjumlah 4 VM.

21 103 Gambar 4.31 Posisi VM pada host 1 setelah migrasi Gambar 4.32 Posisi VM pada host 2 setelah migrasi 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 pengiriman RARP vmnic host tujuan. Mulai fase tersebut hingga VM diaktifkan

22 104 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 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 dan jalur Gigabit Ethernet privat. Pengujian ini menunjukkan bahwa ketika migrasi, VM tidak aktif untuk beberapa saat. Hal ini ditunjukkan dengan keluaran request timed out ketika program ping dijalankan. Durasi downtime VM bukan sebagai parameter utama untuk menunjukkan ketersediaan layanan. Melalui pengujian ini penulis hanya ingin mengetahui kondisi keaktifan VM, sehingga diperlukan pengujian lanjutan

23 105 terhadap kondisi ini. Hasil pengujian ini kemudian diukur pengaruhnya terhadap 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 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 MD5 Command 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 pada Langkah 3.

24 106 Gambar 4.33 Desain pengujian pengaruh migrasi VM terhadap layanan transfer file 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. Di bawah ini adalah langkah-langkah yang dilakukan ketika mengirimkan file minix_r3.1.6-r6084.iso ke VM FTP Server dengan alamat IP

25 107 Pengiriman dilakukan menggunakan program bawaan sistem operasi Windows XP. Pengiriman file berhasil dalam durasi waktu 90,44 detik 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 A5B94D FA6C8F53F7EFC13E990. Penghitungan dilakukan di komputer yang bertindak sebagai client FTP, dengan alamat IP

26 108 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 Gambar 4.34 Screenshot direktori FTP Server sebelum pengiriman file Langkah kedua adalah mengirimkan file ke VM FTP Server. Komputer client, VM, dan program yang digunakan sama dengan pengiriman file ketika VM tidak migrasi, sehingga perbandingan durasi dapat dilakukan. Transfer file berhasil dilakukan dalam durasi waktu 100,61 detik.

27 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 (A5B94D FA6C8F53F7EFC13E990) dengan penghitungan file pada komputer client.

28 110 Gambar 4.35 Screenshot direktori FTP Server setelah pengiriman file Hasil Pengujian dan Pembahasan Tabel 4.2 dan Tabel 4.3 memperlihatkan hasil pengujian yang telah dilakukan. Tabel 4.2 menunjukkan perbedaan durasi pengiriman file ke VM FTP Server. Tabel 4.3 menunjukkan MD5 checksum dari file yang dikirimkan.

29 111 Tabel 4.2 Durasi transfer file 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 A5B94D FA6C8F53F7EFC13E990 Setelah pengiriman A5B94D FA6C8F53F7EFC13E990 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

30 112 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. 4.5 Skenario dan Pengaruh DRS terhadap Utilisasi Prosesor dan Memori Host Pengujian ini dilakukan untuk membuktikan bahwa DRS dapat membagi beban kerja untuk mengoptimalkan utilisasi sumber daya prosesor dan memori host. Desain pengujian ini dapat dilihat di Gambar Berikut adalah skenario dan langkah-langkah yang dilakukan dalam pengujian ini: 1. Memindahkan sejumlah VM ke host 1 untuk memicu DRS,

31 Melihat grafik utilisasi prosesor, grafik utilisasi memori dan posisi VM 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 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.

32 114 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: TCI-VAP2-JKT, TCI-VAR-JKT, TCI-VFP1-JKT, TCI-VCACHE-JKT, TCI- VAP1-JKT. Gambar 4.38 Posisi VM di host 1 sebelum DRS

33 Kondisi Host 2 sebelum DRS 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. Gambar 4.40 Posisi VM di host 2 sebelum DRS

34 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: tci-volvo-jkt, TCI-CITRIX1-JKT, TCI-VEPO-JKT, dan TCI-VEX-JKT EX. Gambar 4.42 Posisi VM di host 3 sebelum DRS

35 Kondisi Host 1 setelah DRS 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. Gambar 4.44 Posisi VM di host 1 setelah DRS

36 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.46 Posisi VM di host 2 setelah DRS

37 Kondisi Host 3 setelah DRS 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 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

38 120 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 MHz (10,86%) 7,54 GB (94,25%) MHz (1,02%) 2,83 GB (35,37%) 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 masingmasing 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. Tabel 4.5 Kondisi klaster setelah DRS Host Utilisasi prosesor (persentase) Utilisasi memori (persentase) VM aktif MHz (8,86%) 7,02 GB (87,75%) MHz (3,76%) 6,75 GB (84,37%) MHz (6,55%) 6,84 GB (85,5%) 4

39 121 Dapat dilihat bahwa setelah proses DRS selesai, utilisasi memori host 1 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.