PENGALOKASIAN RESOURCE BEBERAPA CONTAINER PADA PROXMOX VIRTUAL ENVIRONMENT SEBAGAI SERVER CLOUD COMPUTING

SKRIPSI

HANS NOEL ALEXANDER PANJAITAN 111402074

PROGRAM STUDI S1 TEKNOLOGI INFORMASI FAKULTAS ILMU KOMPUTER DAN TEKNOLOGI INFORMASI UNIVERSITAS SUMATERA UTARA 2018

Universitas Sumatera Utara

PENGALOKASIAN RESOURCE BEBERAPA CONTAINER PADA PROXMOX VIRTUAL ENVIRONMENT SEBAGAI SERVER CLOUD COMPUTING

SKRIPSI

Diajukan untuk melengkapi tugas dan memenuhi syarat memperoleh ijazah Sarjana Teknologi Informasi

HANS NOEL ALEXANDER PANJAITAN 111402074

PROGRAM STUDI S1 TEKNOLOGI INFORMASI FAKULTAS ILMU KOMPUTER DAN TEKNOLOGI INFORMASI UNIVERSITAS SUMATERA UTARA 2018

Universitas Sumatera Utara Universitas Sumatera Utara Scanned by CamScanner iii

PERNYATAAN

PENGALOKASIAN RESOURCE BEBERAPA CONTAINER PADA PROXMOX VIRTUAL ENVIRONMENT SEBAGAI SERVER CLOUD COMPUTING

SKRIPSI

Saya mengakui bahwa skripsi ini adalah hasil karya saya sendiri, kecuali beberapa kutipan dan ringkasan yang masing-masing telah disebutkan sumbernya.

Medan, 26 April 2018

HANS NOEL ALEXANDER PANJAITAN 111402074

Universitas Sumatera Utara iv

UCAPAN TERIMA KASIH

Segala puji dan syukur penulis sampaikan kepada Tuhan Yang Maha Esa yang telah memberikan berkat-Nya yang melimpah sehingga penulis dapat menyelesaikan Tugas Akhir yang berjudul “Pengalokasian Resource beberapa Container Pada Proxmox Virtual Environment Sebagai Server Cloud Computing” ini dapat penulis selesaikan untuk memperoleh gelar Sarjana Komputer, Program Studi S1 Teknologi Informasi Universitas Sumatera Utara. Skripsi ini penulis persembahkan kepada kedua orangtua penulis, Ayah Ir. Edward H. Panjaitan. dan Ibu Syamsinar Simanjuntak S.Pd. Yang selalu memberikan doa, dukungan dan kasih sayang kepada penulis. Terima kasih penulis ucapkan kepada saudara – saudara penulis Hans Fredrick Toga Panjaitan, S. T., Hans Edgar Yosua Christoper Panjaitan dan Hans David Yose Abraham Panjaitan dan kakak Mida terkasih yang selalu memberikan doa dan dukungan semangat dalam pengerjaan skripsi ini. Penulis menyadari bahwa penelitian ini tidak akan terwujud tanpa bantuan banyak pihak. Dengan kerendahan hati, penulis ingin menyampaikan ucapan terima kasih kepada: 1. Bapak Prof. Dr. Runtung Sitepu, SH, M.Hum selaku Rektor Universitas Sumatera Utara. 2. Bapak Prof. Dr. Opim Salim Sitompul, M.Sc. selaku Dekan Fakultas Ilmu Komputer dan Teknologi Informasi Universitas Sumatera Utara. 3. Ketua Program Studi S1 Teknologi Informasi, Bapak Romi Fadillah Rahmat, B.Comp.Sc., M.Sc. 4. Bapak Ainul Hizriadi, S.Kom., M.Sc. selaku Dosen Pembimbing I dan Ibu Sarah Purnamawati, ST., M.Sc. Selaku Dosen Pembimbing II yang bersedia meluangkan waktu, pikiran, kritik dan sarannya untuk penulis dalam menyelesaikan skripsi ini. 5. Bapak Dedy Arisandi, S.T., M.Kom. selaku Dosen Pembanding I dan Bapak Baihaqi Siregar, S.Si., M.T. selaku Dosen Pembanding II yang telah memberikan saran dan kritik dalam penyempurnaan skripsi ini.

Universitas Sumatera Utara v

6. Sahabat terhebat Tepen, Willy, Wilfrit, Gabriella dan yang kukasihi Indriany Tampubolon yang selalu mengingatkan dan memberikan dukungan serta semangat dan doa. 7. Teman satu perjuangan dari mulai semester awal sampai semester yang hampir habis Fachru Rozi Nasuton, Hanafiah Ismed Siregar, Roy P. Ginting, Suryansyah, Ilhamudin Hasibuan, Dhany RSS, Ade Dermawan S. Erick Siagian, Ryan Faisal, Indera Surya Satria, Imam Irhamsyah, Rina Bahri, Fahrunissa Khairani, Noel Andrew Panjaitan, Ardian Fadly, Rian Saputra, Wulan dan seluruh teman angkatan 2011 mahasiswa Teknologi Informasi. 8. Kepada Adik – adik junior Livia Fyoni Kemit, Sukma Yastika Putri, Fauziah Nur Amalia Purba dan Novira Naili Ulya Siregar, Deby Aprillia Sihombing, Vyna Simbolon, Victoria Lonita, Franco yang selalu mendukung dan membantu baik dalam hal pembuatan skripsi maupun hal lainnya. 9. Semua pihak yang terlibat langsung maupun tidak langsung yang tidak dapat penulis ucapkan satu persatu. Semoga Tuhan Yang Maha Esa selalu melimpahkan berkah kepada semua pihak yang telah memberikan bantuan, dukungan dan semangat kepada penulis dalam menyelesaikan skripsi ini.

Medan, 26 April 2018

Penulis

Universitas Sumatera Utara vi

ABSTRAK

Seiring berjalannya waktu, kemajuan teknologi tidak dapat dihindari, maka dari itu banyak sekali penemuan – penemuan yang terjadi dalam teknologi pada beberapa tahun terakhir. Salah satu diantaranya adalah cloud computing. Dalam perkembangan cloud computing, istilah virtualisasi semakin melekat dengan cloud computing, hal ini dikarenakan virtualisasi merupakan salah satu alasan dan juga sebagai landasan berkembangnya teknologi cloud itu sendiri. Pada , terdapat beberapa ataupun container dengan alokasi resource yang bervariasi. Tanpa penyesuaian yang baik maka resource tersebut tidak digunakan dengan maksimal. Oleh karena itu dibutuhkan sebuah pendekatan untuk memanfaatkan kemampuan server virtualisasi agar dapat bekerja dengan maksimal yaitu dengan mengelola serta mengalokasikan resource di lingkungan virtualisasi proxmox yang bertujuan agar service yang terdapat pada container dapat berjalan dengan baik. Penerapan script pengalokasian resource pada hypervisor di proxmox virtual environment dapat berjalan dengan baik pada virtualisasi server dengan menggunakan container. Perubahan resource dapat mempengaruhi penggunaan resource pada container. Pengalokasian resource mampu memaksimalkan kinerja dari service yang ada pada container dengan konfigurasi default yang dapat dilihat dari perubahan hasil benchmark dari service yang ada pada masing – masing container.

Kata kunci : Alokasi resource, cloud computing, virtualisasi server, linux container, hasil benchmark, Proxmox Virtual Environment.

Universitas Sumatera Utara vii

Containers Resource Allocation on Proxmox Virtual Environment

as Cloud Computing Server

ABSTRACT

As time goes by, technological advances are inevitable, therefore many inventions have occurred in technology in recent years. One of them is cloud computing. In the development of cloud computing, the term is increasingly embedded with cloud computing, this is because virtualization is one of the reasons and also as the foundation of the development of cloud technology itself. In the hypervisor, there are several virtual machines or containers with various resource allocations. Without a proper adjustment then the resources are not used to its maximum potential. Hence an approach is needed to utilize virtualization server’s capabilities in order to work maximally, that is by managing and allocating resource in proxmox virtual environment which aims that the service inside the container can run properly. The implementation of resource allocation script on hypervisor in proxmox virtual environment can run properly on server virtualization using linux container. Changes in resources can affect the usage of resources in the container. Resource allocation is able to maximize the performance of existing service in the container that can be seen from the changes in benchmark results from existing service on each container.

Keywords : Resource Allocation, Cloud Computing, Server Virtualization, Linux Container, Benchmark Results, Proxmox Virtual Environment.

Universitas Sumatera Utara viii

DAFTAR ISI

Halaman

Persetujuan ii Pernyataan iii Ucapan Terima Kasih iv Abstrak vi Abstract vii Daftar Isi viii Daftar Tabel xi Daftar Gambar xii

BAB 1 Pendahuluan 1.1 Latar Belakang 1 1.2 Rumusan Masalah 3 1.3 Batasan Masalah 3 1.4 Tujuan Penelitian 3 1.5 Manfaat Penelitian 4 1.6 Metode Penelitian 4 1.7 Sistematika Penulisan 5

Bab 2 Landasan Teori 2.1 Komputasi Awan (Cloud Computing) 7 2.1.1 Pembagian Model Cloud 9 2.2 Virtualisasi 11 2.2.1 Konsep Server Virtual 11 2.2.2 Keuntungan Server Virtual 12 2.3 Hypervisor 12

Universitas Sumatera Utara ix

2.4 Promox Virtual Environtment 14 2.5 Linux Container 16 2.6 Apache, MySQL, Vsftpd 18 2.6.1 Apache 18 2.6.2 MySQL 18 2.6.3 Vsftpd 18 2.7 Benchmark dan Crontab 19 2.7.1 Benchmark 19 2.7.2 Crontab 19 2.8 Penelitian Terdahulu 19

BAB 3 Analisis dan Perancangan Sistem 3.1 Analisis Permasalahan 25 3.2 Arsitektur Umum 26 3.3 Alokasi Resource Pada Linux Container 28 3.3.1 Alokasi Resource Memory 29 3.3.2 Alokasi Resource CPU 33 3.4 Pengelolaan Container Pada Promox 37

BAB 4 Implementasi dan Pengujian 4.1 Konfigurasi Sistem 39 4.1.1 Spesifikasi Perangkat Keras 39 4.1.2 Instalasi Promox Virtual Environment 39 4.1.3 Instalasi Linux Container dan Service Pada Container 44 4.1.4 Pengaturan Alokasi Resource 46 4.2 Pengujian Sistem 47 4.2.1 Program Yang Digunakan Dalam Pengujian 47 4.2.2 Skenario Pengujian 48 4.3 Hasil Pengujian 49 4.4 Analisis Hasil Pengujian 63

Universitas Sumatera Utara x

BAB 5 Kesimpulan dan Saran 5.1 Kesimpulan 70 5.2 Saran 70 Daftar Pustaka 71

Universitas Sumatera Utara xi

DAFTAR TABEL

Halaman Tabel 2.1 Peneliti Terdahulu 21 Tabel 3.1 Daftar Perintah PCT 37 Tabel 4.1 Spesifikasi Perangkat Keras Yang Digunakan 39 Tabel 4.2 Spesifikasi Container Yang Dibangun Pada Host 44 Tabel 4.3 Resource Yang Dimiliki Container Pada Skenario 1,2, dan 3 64 Tabel 4.4 Resource Yang Dimiliki Container Pada Skenario 4 dan 5 65 Tabel 4.5 Hasil Benchmark Terhadap LXC 100 65 Tabel 4.6 Hasil Benchmark Terhadap LXC 101 67 Tabel 4.7 Hasil Benchmark Terhadap LXC 102 68

Universitas Sumatera Utara xii

DAFTAR GAMBAR

Halaman Gambar 2.1. Cloud Deployment Model 10 Gambar 2.2. Cloud Computing Service Delivery Model 11 Gambar 2.3. Arsitektur Umum Virtualisasi 12 Gambar 2.4. Hypervisor Tipe 1 (Bare-Metal) 13 Gambar 2.5. Hypervisor Tipe 2 14 Gambar 2.6. Linux Container (LXC) Yang Berada Pada Sebuah Operating Sistem 17 Gambar 3.1. Model Pemanfaatan Linux Container 25 Gambar 3.2. Arsitektur Umum 26 Gambar 3.3. Contoh File Konfigurasi Raw Container 28 Gambar 3.4. Contoh Konfigurasi File Container Yang Digunakan Promox 28 Gambar 3.5. Pseudecode Alokasi Resource Memory 30 Gambar 3.6. Diagram Alur Alokasi Resource Memory 32 Gambar 3.7. Status Pemakaian CPU Pada Masing-Masing Core 33 Gambar 3.8. Pseudecode Alokasi Resource CPU 35 Gambar 3.9. Diagram Alur Alokasi Resource CPU 36 Gambar 4.1. Command Line Interface Pada Proxmox 40 Gambar 4.2. Halaman Login Promox Melalui Web 41 Gambar 4.3. Halaman Dashboard Promox Melalui Web 41 Gambar 4.4. Membuat User Baru Melalui Halaman Dashboard Promox 42 Gambar 4.5. Konfigurasi Jaringan Pada Host Melalui CLI 43 Gambar 4.6. Konfigurasi Jaringan Melalui Halaman Web 43 Gambar 4.7. Pilihan Template Yang Bisa Diunduh Melalui Halaman Dashboard 45 Gambar 4.8. Template Yang Sudah Terunduh Disimpan Pada Penyimpanan Local 45

Universitas Sumatera Utara xiii

Gambar 4.9. Pembuatan Container Melalui Halaman Dashboard 45 Gambar 4.10. Status Cron Yang Berjalan Pada Proses Background 47 Gambar 4.11. Resource Pada Skenario Pertama 49 Gambar 4.12. Hasil Resource Pengujian Skenario Kedua 50 Gambar 4.13. Hasil Resource Pengujian Skenario Ketiga 51 Gambar 4.14. Hasil Benchmark Pengujian Skenario Kedua Terhadap LXC 100 53 Gambar 4.15. Hasil Benchmark Pengujian Skenario Ketiga Terhadap LXC 100 54 Gambar 4.16. Hasil Resource Pengujian Skenario Keempat 55 Gambar 4.17. Hasil Resource Pengujian Skenario Kelima 56 Gambar 4.18. Hasil Benchmark Pengujian Skenario Keempat Terhadap LXC 100 58 Gambar 4.19. Hasil Benchmark Pengujian Skenario Kelima Terhadap LXC 100 59 Gambar 4.20. Hasil Benchmark Pengujian Skenario Keempat Terhadap LXC 101 61 Gambar 4.21. Hasil Benchmark Pengujian Skenario Kelima Terhadap LXC 101 62 Gambar 4.22. Hasil Benchmark Pengujian Skenario Keempat Terhadap LXC 102 62 Gambar 4.23. Hasil Benchmark Pengujian Skenario Kelima Terhadap LXC 102 63 Gambar 4.24. Hasil Benchmark Terhadap LXC 100 Dengan Service Apache Dalam Bentuk Diagram 66 Gambar 4.25. Hasil Benchmark Terhadap LXC 101 Dengan Service MySQL Dalam Bentuk Diagram 67 Gambar 4.26. Hasil Benchmark Terhadap LXC 100 Dengan Service FTP Dalam Bentuk Diagram 69

Universitas Sumatera Utara BAB 1

PENDAHULUAN

1.1. Latar Belakang

Seiring berjalannya waktu, kemajuan teknologi tidak dapat dihindari, maka dari itu banyak sekali penemuan – penemuan yang terjadi dalam teknologi pada beberapa tahun terakhir. Salah satu diantaranya adalah cloud computing. Cloud computing dapat digambarkan sebagai komputasi berorientasi layanan web yang menyediakan lingkungan yang berperan sebagai layanan dalam mengirimkan perangkat lunak dan manajemen informasi dengan cara yang biasanya hanya tersedia dalam format produk. Hal ini dilakukan melalui perangkat pribadi seperti laptop yang akan mengakses layanan yang tersedia melalui jaringan server yang biasa disebut “Cloud” (Marston, 2011). Dalam perkembangan cloud computing, istilah virtualisasi semakin melekat dengan cloud computing, hal ini dikarenakan virtualisasi merupakan salah satu alasan dan juga sebagai salah satu landasan berkembangnya teknologi cloud itu sendiri. Keuntungan utama dari virtualisasi server adalah server virtual ini dapat ditransisikan dari satu host ke host yang lain (tej Koganti et al, 2013). Sehubungan dengan semakin berkembangnya inovasi pada teknologi cloud computing, para penyedia jasa cloud diharapkan mampu mengelola server dengan baik. Server akan dikatakan bekerja dengan baik ketika mampu menjalankan aplikasi, service atau layanan yang digunakan oleh client. Mell & Grance (2011) menjelaskan bahwa cloud computing menurut model layanannya dibagi atas 3 jenis yaitu Infrastructure as a Service (IaaS), Platform as a Service (PaaS), dan Software as a Service (SaaS). Demi meningkatkan kualitas mutu layanan (Quality of Service) yang diberikan kepada pengguna, maka server sendiri perlu bekerja secara maksimal. Sering kali server tidak bekerja secara optimal yang disebabkan oleh banyaknya beban atau request pada server sehingga membuat server menghabiskan seluruh resource hanya untuk satu request tertentu dan akan

Universitas Sumatera Utara 2

menimbulkan gangguan, masalah pada sistem yang akan berujung menimbulkan kerugian baik itu pada sisi client ataupun pada sisi penyedia jasa cloud itu sendiri. Pada umumnya, masalah tersebut dapat diatasi dengan melakukan restart secara keseluruhan pada sistem atau pada service tertentu, namun tentu saja hal tersebut dapat mengurangi kinerja dari server tersebut. Selain contoh diatas, masih banyak masalah lain yang akan kita temukan ketika akan membangun sebuah server yang baik. Beberapa sistem operasi yang sering digunakan pada server mempunyai cara – cara khusus untuk mengatasi masalah – masalah diatas. Akan tetapi, setiap sistem operasi tentu memiliki kelebihan dan kekurangan masing – masing. Sebagai contoh sebuah teknologi virtualisasi yang diberi nama container (Hizriadi, 2011). Container merupakan sebuah teknologi virtualisasi yang didalamnya berupa sebuah sistem operasi ringan yang berjalan didalam host. Penggunaan container dapat menghemat dalam konsumsi resource serta mengisolasi lingkungan (environment) (Dua et al, 2014). Beberapa penelitian yang berkaitan dengan penggunaan container pada server sudah pernah dilakukan sebelumnya. Pada tahun 2013, Xavier et al melakukan beberapa percobaan dengan tujuan untuk melakukan evaluasi terhadap performa container dalam virtualisasi, serta membandingkan performa container dengan , yang merepresentasikan virtualisasi perangkat lunak yang menciptakan sekaligus bekerja sebagai mesin virtual pada perangkat keras atau yang biasa disebut hypervisor tradisional yang sering digunakan pada saat itu. Dua et al pada tahun 2014 melakukan perbandingan terhadap virtual machine dan container serta membandingkan container untuk menentukan pemilihan container yang tepat sebagai pengganti dari virtual machine untuk digunakan pada server. Penelitian yang berhubungan dengan alokasi resource juga telah dilakukan sebelumnya. Anuradha (2014), pada penelitiannya melakukan survey terhadap strategi pengalokasian resource pada lingkungan cloud dengan tujuan mengidentifikasi sebuah strategi efisien dalam pengalokasian resource yang memanfaatkan resource yang terbatas secara efektif pada lingkungan cloud computing.

Universitas Sumatera Utara 3

Berdasarkan latar belakang tersebut, penulis mengajukan proposal penelitian dengan judul “PENGALOKASIAN RESOURCE BEBERAPA CONTAINER PADA PROXMOX VIRTUAL ENVIRONMENT SEBAGAI SERVER CLOUD COMPUTING”.

1.2. Rumusan Masalah

Pada hypervisor, terdapat beberapa virtual machine ataupun container dengan alokasi resource yang bervariasi. Tanpa pengaturan yang baik maka resource tersebut tidak digunakan dengan maksimal. Oleh karena itu, dibutuhkan pendekatan bagaimana resource yang ada pada sebuah hypervisor bisa dialokasikan kinerjanya untuk beberapa service tertentu pada beberapa container.

1.3. Batasan Masalah

Agar penelitan yang dilakukan oleh penulis terarah dan fokus, maka penulis membatasi ruang masalah penelitian sebagai berikut : 1. Hypervisor yang digunakan Proxmox VE (Virtual Environtment), dengan virtualisasi yang akan diteliti adalah Linux Container (LXC). 2. Virtual Machine yang dibangun pada hypervisor sebanyak 3 buah, masing – masing memiliki satu buah service yaitu : apache, mysql, dan ftp. 3. Benchmark tools yang digunakan pada penelitian ini disesuaikan dengan masing – masing service yang ada pada container. 4. Tidak membahas masalah keamanan jaringan, bandwith atau paket data.

1.4. Tujuan Penelitian

Tujuan penelitian ini adalah memanfaatkan kemampuan server virtualisasi agar dapat bekerja dengan maksimal, yaitu dengan mengelola serta mengalokasikan resource di lingkungan virtualisasi proxmox yang bertujuan agar service yang terdapat pada container dapat berjalan dengan baik.

Universitas Sumatera Utara 4

1.5. Manfaat Penelitian

Manfaat dari penelitian ini yaitu: 1. Menerapkan sebuah program yang berfungsi untuk mengalokasikan resource pada container untuk memperoleh hasil benchmark yang lebih baik. 2. Penelitian dapat dijadikan bahan rujukan untuk penelitian lain.

1.6. Metodologi

Tahapan-tahapan yang dilakukan dalam penelitian ini adalah sebagai berikut: 1. Studi Literatur Studi literatur yang dilakukan dalam penelitian ini adalah mengumpulkan dan mempelajari materi-materi yang berhubungan dengan penelitian ini. Referensi diambil dari banyak sumber berupa jurnal, buku, skripsi dan dari referensi lainnya yang berhubungan dengan cloud computing, container, proxmox ve dan benchmark tools.

2. Analisis Permasalahan Pada tahap ini dilakukan analisis terhadap berbagai informasi yang telah diperoleh dari berbagai sumber yang terkait dengan penelitian agar didapatkan pemahaman tentang metode yang tepat untuk menyelesaikan masalah dalam penelitian ini.

3. Perancangan Pada tahap ini penulis melakukan perancangan sistem untuk menyelesaikan permasalahan pada tahap analisis.

4. Pembangunan Program Pada tahap ini program akan dibangun pada proxmox ve dengan menerapkan proses alokasi resource sesuai alur program yang telah dibuat.

Universitas Sumatera Utara 5

5. Evaluasi Pada tahap ini akan dilakukan proses evaluasi terhadap hasil implementasi yang telah dibuat untuk menguji pengalokasian resource pada hypervisor dengan membandingkan hasil implementasi terhadap keadaan sebelum pengalokasian resource diimplementasikan dengan melihat beberapa kriteria penilaian terhadap hasil benchmark.

6. Penyusunan Laporan Pada tahap ini penulis melakukan penyusunan laporan hasil evaluasi dan analisis serta implementasi alokasi resource pada penelitian ini.

1.7. Sistematika Penulisan

Sistematika penulisan dari skripsi ini terdiri dari lima bagian utama sebagai berikut: Bab 1: Pendahuluan Bab ini berisi latar belakang, rumusan masalah, batasan masalah, tujuan penelitian, manfaat penelitian, metodologi penelitian, dan sistematika penulisan.

Bab 2: Landasan Teori Bab ini berisi teori-teori yang digunakan untuk memahami permasalahan yang dibahas pada penelitian ini. Teori yang berhubungan dengan cloud computing, proxmox virtual environtment, container, dan alokasi resource.

Bab 3: Analisis dan Perancangan Sistem Bab ini membahas analisis dari penggunaan container pada proxmox dan penerapan alokasi resource pada proxmox. Pada bab ini juga dijabarkan arsitektur umum, proses yang dilakukan termasuk perancangan sistem yang dibuat seperti pemodelan dengan flowchart.

Bab 4: Implementasi dan Pengujian Sistem Bab ini berisi pembahasan tentang implementasi dari analisis dan perancangan sistem yang disusun pada Bab 3 dan hasil implementasi yang didapatkan.

Universitas Sumatera Utara 6

Bab 5: Kesimpulan dan Saran Bab ini berisi kesimpulan dari keseluruhan uraian bab-bab sebelumnya terutama pada Bab 3 dan 4 dan saran-saran yang diajukan untuk pengembangan pada penelitian selanjutnya.

Universitas Sumatera Utara

BAB 2

LANDASAN TEORI

2.1. Komputasi Awan (Cloud Computing)

Cloud computing adalah penggabungan teknologi komputasi seperti komputasi terdistribusi, paralel dan grid (Anuradha, 2014). Sejenis teknik komputasi dimana layanan teknologi informasi (IT) disediakan oleh unit komputasi berbiaya rendah yang terhubung dengan jaringan internet disebut cloud computing (Qian et al, 2009). Menurut Mell & Grance (2011) dari National Institute of Standards and Technology (NIST) mengartikan cloud computing sebagai sebuah model yang memungkinkan akses jaringan on-demand yang ada di mana-mana, resource bersama yang dapat dikonfigurasi yang dengan cepat tersedia dan dilepaskan dengan usaha pengelolaan minimal atau interaksi penyedia layanan. Cloud computing dapat digambarkan sebagai komputasi berorientasi layanan web yang menyediakan lingkungan yang berperan sebagai layanan dalam mengirimkan perangkat lunak dan manajemen informasi dengan cara yang biasanya hanya tersedia dalam format produk. Hal ini dilakukan melalui perangkat pribadi seperti laptop yang akan mengakses layanan yang tersedia melalui jaringan server yang biasa disebut “cloud” (Marston, 2011). Dari beberapa definisi tentang cloud computing diatas dapat disimpulkan bahwa cloud computing adalah sebuah layanan yang memanfaatkan jaringan internet sebagai media penghubung antara pengguna jasa dan penyedia jasa. Dengan kata lain seorang pengguna dapat mengakses file, aplikasi ataupun meminta suatu layanan tertentu yang disediakan oleh pihak penyedia jasa hanya menggunakan jaringan internet tanpa harus terhubung langsung dengan perangkat keras.

Universitas Sumatera Utara 8

Menurut Mell & Grance (2011) ada 5 karateristik penting yang harus dipenuhi pada cloud computing yaitu : a. On demand self-service Konsumen dapat secara sepihak menyediakan kemampuan komputasi, seperti waktu server dan penyimpanan jaringan, sesuai kebutuhan secara otomatis tanpa membutuhkan interaksi manusia dengan masing-masing penyedia layanan. b. Broad network access Kemampuan tersedia melalui jaringan dan diakses melalui mekanisme standar yang mempromosikan penggunaan platform oleh thin atau thick klien. c. Resource pooling Komputasi penyedia dikumpulkan untuk melayani beberapa konsumen menggunakan model multi-tenant, dengan resource fisik dan virtual yang berbeda yang ditugaskan dan ditugaskan kembali secara dinamis sesuai permintaan konsumen. Ada independensi lokasi bahwa pelanggan umumnya tidak memiliki kontrol atau pengetahuan mengenai lokasi yang tepat dari resource yang disediakan namun mungkin dapat menentukan lokasi pada tingkat abstraksi yang lebih tinggi. d. Rapid elasticity Kemampuan dapat secara elastis tersedia dan dilepaskan, dalam beberapa kasus secara otomatis, untuk skala cepat ke luar dan ke dalam sepadan dengan permintaan. Kepada konsumen, kemampuan yang tersedia untuk penyediaan seringkali tampak tidak terbatas dan dapat disesuaikan dalam jumlah apapun kapan saja. e. Measured service Cloud computing secara otomatis mengendalikan dan mengoptimalkan penggunaan resource dengan memanfaatkan kemampuan metering pada beberapa tingkat abstraksi yang sesuai dengan jenis layanan.

Universitas Sumatera Utara 9

2.1.1. Pembagian Model Cloud Mell & Grance (2011) juga menjelaskan 4 model pengembangan dari cloud computing yaitu: a. Private cloud Infrastruktur cloud disediakan untuk penggunaan eksklusif oleh satu organisasi yang terdiri dari beberapa konsumen. b. Community cloud Infrastruktur cloud tersedia untuk penggunaan eksklusif oleh komunitas konsumen tertentu dari organisasi yang memiliki tujuan bersama. c. Public cloud Infrastruktur cloud disediakan untuk penggunaan terbuka oleh masyarakat umum. d. Hybrid cloud Infrastruktur cloud yang komposisi terdiri dari dua atau lebih infrastruktur awan yang berbeda (private, community or public) yang tetap merupakan entitas unik, namun terikat oleh teknologi standar memungkinkan portabilitas data dan aplikasi.

Berdasarkan model layanannya, cloud computing dibagi menjadi 3 yaitu : 1) Infrastructure as a Service (IaaS) Kemampuan yang diberikan kepada konsumen adalah menyediakan pemrosesan, penyimpanan, jaringan, dan resource komputasi fundamental lainnya dimana konsumen dapat menerapkan dan menjalankan perangkat lunak dengan sewenang- wenang, yang mencakup sistem operasi dan aplikasi.

2) Platform as a Service (PaaS) Kemampuan yang diberikan kepada konsumen adalah menyebarkan aplikasi berbasis cloud yang dibuat atau diakuisisi oleh pengguna dengan menggunakan bahasa pemrograman, perpustakaan, layanan, dan alat yang didukung oleh penyedia layanan.

Universitas Sumatera Utara 10

3) Software as a Service (SaaS) Kemampuan yang diberikan kepada konsumen adalah menggunakan aplikasi penyedia yang berjalan di infrastruktur cloud. Aplikasi dapat diakses dari berbagai perangkat klien seperti browser atau antarmuka program.

Dari penjelasan diatas Nazir et al, 2015 membuat ilustrasi bagaimana model cloud tersebut diterapkan seperti pada gambar 2.1 berikut.

Gambar 2.1 Cloud deployment model (Nazir et al, 2015)

Dapat dilihat pada Gambar 2.1 bagaimana model – model cloud bekerja. Pada lingkungan nyata, keberadaan cloud sangat berpengaruh dalam memudahkan pekerjaan baik itu sebagai penyedia jasa cloud maupun yang menggunakan cloud tersebut. Hal ini dikarenakan dalam sistem cloud, pengguna berhak mengatur sendiri penggunaan dari sistem yang dipakainya tanpa harus melibatkan penyedia jasa, sementara untuk penyedia jasa pada umumnya hanya menyediakan resource yang akan digunakan pada pengguna. Akan tetapi baik pengguna maupun penyedia jasa perlu memperhatikan dan melakukan perbaikan secara berkala pada keamanan sistem yang dibangun. Dengan menggabungkan beberapa jenis cloud dengan model pengiriman maka kita akan mendapat ilustrasi sistem cloud yang alami. Seperti yang ditunjukkan pada gambar 2.2.

Universitas Sumatera Utara 11

Gambar 2.2 Cloud computing service delivery model (Nazir et al, 2015)

2.2. Virtualisasi

Dalam perkembangan teknologi komputasi awan atau cloud computing. Kata virtualisasi tentulah sangat melekat dalam pembahasan tersebut, dikarenakan virtualisasi merupakan salah satu landasan berkembangnya teknologi cloud sampai saat ini. Virtualisasi adalah sebuah teknik yang dipakai untuk menyembunyikan karateristik fisik dari sumber daya komputer (seperti: perangkat keras, media penyimpanan data dan sistem operasi) dan membuatnya berinteraksi agar dapat digunakan oleh sistem lain, aplikasi, atau pengguna dalam cloud.

2.2.1. Konsep Server Virtual Biasanya server virtual memegang peran utama pada lingkungan cloud. Server virtual terdiri dari sistem operasi, aplikasi dan penyimpanan. Jika server virtual dipertahankan, server virtual ini dapat dilayani oleh satu atau lebih host, dan pada sisi host dapat mempertahankan lebih dari satu server virtual. Sama seperti server biasa, server virtual juga dinamai sesuai penggunaannya. Jika seorang administrator merasa bahwa layanan yang diberikan melayani batasnya, maka dia dapat mengurangi sampai batas tertentu. Dalam pengembangannya, kita dapat membangun beberapa server virtual atau server virtual yang identik (tej Koganti et al, 2013). Model virtualisasi terdiri dari pengguna cloud, model layanan, model virtualisasi dan perangkat lunak serta perangkat keras dari host itu sendiri. Hal ini didasari dari tiga model layanan yaitu SaaS (Software as a Service), PaaS (Platform as

Universitas Sumatera Utara 12

a Service), dan IaaS (Infrastructure as a Service). SaaS menyediakan aplikasi kepada para pengguna cloud untuk memenuhi kebutuhan dan permintaan yang diperlukan. PaaS menyediakan kepada pengguna cloud tempat (platform) dimana para pengguna cloud dapat menjalankan aplikasi. IaaS menyediakan keamanan dan perangkat keras yang digunakan untuk sumber daya cloud (Malhotra, L et al, 2014).

Pengguna cloud

Model layanan

Layer atau Host virtual

Perangkat keras dan sumber daya

Gambar 2.3 Arsitektur umum virtualisasi

2.2.2. Keuntungan Server Virtual tej Koganti et al (2013) pada penelitiannya menyebutkan keuntungan utama dari server virtual adalah server virtual ini dapat ditransisikan dari satu host ke host yang lain. Adapun keuntungan – keuntungan lain dari server virtual adalah sebagai berikut : a. Kita dapat menjaga sumber daya IT. b. Perangkat keras yang tersedia di server virtual ada pada tingkat yang tinggi. c. Dapat dengan mudah mengganti pengaturan dari server itu sendiri ketika sebuah layanan sedang berjalan. d. Seringkali kita dapat meluncurkan server baru pada lingkungan virtual.

2.3. Hypervisor

Dalam virtualisasi, mesin host adalah mesin yang sebenarnya tempat dimana virtualisasi itu berlangsung sementara mesin guest adalah virtual. Perangkat lunak atau firmware yang menciptakan mesin virtual dan bekerja sebagai mesin virtual pada

Universitas Sumatera Utara 13

perangkat keras host disebut Hypervisor atau sering juga disebut sebagai yang adalah sebuah program tingkat rendah yang memungkinkan sebuah mesin host tunggal memiliki banyak sistem operasi yang berjalan pada waktu bersamaan. Jenis hypervisor itu sendiri terbagi atas 2 yaitu: 1. Tipe 1 Hypervisor tipe 1 ini berhubungan secara langsung dengan perangkat keras yang sedang divirtualisasikan. Tipe 1 ini merupakan hypervisor yang independen atau tidak terikat dengan sistem operasi (OS), juga dapat berjalan sebelum sistem operasi. Tipe ini sering kali disebut native, bare-metal dan embedded hypervisor.

App 1 App 2

Sistem operasi

Hypervisor / Virtual machine manager

Perangkat keras

Gambar 2.4 Hypervisor tipe 1 (bare-metal)

2. Tipe 2 Berbeda dengan tipe 1, hypervisor tipe 2 ini tidak berhubungan langsung dengan perangkat keras melainkan berada pada sistem operasi, sehingga menyebabkan hypervisor tipe ini sangat bergantung pada sistem operasi. Sama seperti sebuah aplikasi yang ada pada sistem operasi, hypervisor tipe ini tidak dapat berjalan kalau sistem operasi belum menyala dan bekerja. Ketika sebuah sistem operasi yang didalamnya terdapat hypervisor rusak, maka semua pengguna akan merasakan akibatnya. Karena tipe ini sangat bergantung pada sistem operasi maka hypervisor tidak memegang kendali penuh terhadap mesin penggunanya.

Universitas Sumatera Utara 14

App 3 App 4

Sistem operasi 2 (guest)

App 1 App 2 Hypervisor / VMM

Sistem operasi 1 (host)

Perangkat keras

Gambar 2.5 Hypervisor tipe 2

2.4. Proxmox Virtual Environtment

Menurut Suryono, T. & Afif, M., F. (2012) pada penelitiannya mendefinisikan Proxmox VE sebagai perangkat lunak open source virtualisasi platform untuk menjalankan Virtual Appliance dan Virtual Machine. Cheng (2014) menyebutkan bahwa proxmox merupakan sebuah hypervisor untuk virtualisasi server yang berdasarkan pada distribusi Debian linux yang mengizinkan pengguna untuk melakukan instalasi beberapa jenis sistem operasi (Windows, Linux, Unix) pada sebuah komputer tunggal atau sebuah cluster yang terbuat dari pengelompokkan beberapa komputer secara bersamaan. Proxmox dikenal sebagai hypervisor tipe 2 dikarenakan layer virtualisasi dibuat dalam sistem operasi. Sebagai hypervisor tipe 2 proxmox dibuat didalam sistem operasi linux debian, berbeda dengan hypervisor tipe 1 yang bekerja secara langsung pada perangkat keras tanpa adanya media dari sistem operasi, tipe ini tidak memiliki fungsi tambahan selain mengelola virtualisasi dan perangkat keras. (Goldman, 2016). Virtualisasi dalam proxmox paling sering mengacu pada abstraksi semua aspek sistem komputasi dari perangkat kerasnya. Dalam konteks ini, virtualisasi adalah penciptaan, dengan kata lain mesin virtual atau VM, dengan sistem operasi dan aplikasinya sendiri. Fitur utama proxmox dapat diringkas sebagai berikut:  Open source : proxmox sepenuhnya open source yang berada dibawah General Public License, version 3 (GNU AGPL, v3), yang berarti pengguna proxmox dapat dengan bebas melihat, mengubah serta menghapus source code dan mendistribusikan versi yang diinginkan selama versi tersebut mematuhi lisensi.

Universitas Sumatera Utara 15

 Live Migration: Hal ini berarti proxmox mengizinkan sebuah virtual mesin yang sedang berjalan dari sebuah server fisik ke server yang berbeda tanpa downtime.

 High Availability: Pada mode cluster proxmox HA, ketika sebuah node mengalami kegagalan sistem, virtual mesin yang tersisa akan dipindahkan ke node lain yang befungsi dengan baik untuk memastikan gangguan pada service menjadi minimal.

 Bridged Networking: Proxmox mengizinkan pengguna untuk membuat sebuah jaringan pribadi yang berada diantara mesin virtualnya.

 Flexible Storage: Terdapat berbagai pilihan penyimpanan yang tersedia dalam hal ini termasuk tempat penyimpanan lokal dan tempat penyimpanan yang berbasis jaringan seperti LVM, iSCSI, NFS, Filesystem Gluster dan Filesystem CEPH.

 Template Sistem Operasi: proxmox mengizinkan penggunanya untuk membuat template sistem operasi mereka sendiri untuk penyebaran lebih lanjut, akan tetapi proxmox juga memungkinkan pengguna untuk mengunduh sebuah file template dari internet dan memasukkannya kedalam sistem pengguna tersebut.

 Scheduled Backup: sebuah antarmuka disediakan kepada pengguna sehingga pengguna dapat menyiapkan strategi backup pengguna itu sendiri. File backup dapat disimpan pada tempat penyimpanan lokal atau tempat penyimpanan lainnya sesuai dengan pilihan dari konfigurasi sistem pengguna tersebut.

 Command-line (CLI) tool: Proxmox menyediakan manajemen CLI yang berbeda yang memungkinkan penggunanya untuk dapat mengakses langsung mesin virtual, container, mengatur resource dan sebagainya.

Proxmox menyediakan fungsionalitas virtualisasinya melalui tiga teknologi terbuka yang dikelola melalui antarmuka berbasis web. Adapun ketiga teknologi tersebut yaitu KVM, QEMU, dan LXC. Dalam penelitian ini, penulis menggunakan teknologi LXC dalam virtualisasi server yang dibangun.

Universitas Sumatera Utara 16

Berikut adalah kebutuhan spesifikasi minimum yang diperlukan dalam sistem proxmox VE:  CPU harus menggunakan 64 bit. Dapat menggunakan Intel EMT64 atau AMD64  Memory minimum yang digunakan 1 Gigabyte, rekomendasi diatas 2 Gigabyte untuk memuat lebih banyak mesin virtual atau container.  Kapasitas Penyimpanan yang dibutuhkan minimal satu buah hard disk drive dengan kapasitas minimum 500 Gigabyte.  Untuk konektivitas jaringan dibutuhkan minimal satu buah Network Interface Card (NIC).

2.5. Linux Container

Linux Container (LXC) adalah implementasi kernel containment ringan yang didukung oleh Linux seperti Ubuntu dan Oracle linux. (Dua et al, 2014). Menurut Zulfa (2011), LXC atau Linux Container adalah virtualisasi pada level sistem operasi yang dapat digunakan untuk menjalankan banyak sistem operasi yang terisolasi pada sebuah komputer. LXC menyediakan lingkungan virtual yang terisolasi yang memiliki proses dan jaringan sendiri. Berbeda dengan mesin virtual atau VM yang membutuhkan lebih banyak resource komputer utama virtualisasi, hal ini dikarenakan VM memerlukan kernel sistem operasinya secara lengkap serta program dan aplikasi harus terlebih dahulu diinstalasi agar dapat digunakan, sedangkan container (CT) lebih sedikit menggunakan resource dikarenakan CT itu sendiri memakai kernel yang sama dengan komputer utama virtualisasinya. Menurut Dua, Karakteristik kunci dari LXC adalah: 1. Process Setiap container diberi sebuah Process ID (PID) yang unik. Setiap container dapat menjalankan sebuah process.

2. Resource Isolation Menggunakan dan namespaces untuk mengisolasi resource.

Universitas Sumatera Utara 17

3. Network Isolation Container mendapat sebuah alamat IP pribadi dan antarmuka veth menghubungkan ke linux bridge pada host

4. File System Isolation Setiap container mendapat sistem file pribadi dengan memanfaatkan .

Diberi contoh penggunaan LXC dalam sebuah OS yang menjalankan dua Linux Container LXC 1 dan LXC 2, yang memiliki sistem file sendiri di /var/lib/. Pada gambar tersebut, kedua containers terhubung ke sebuah jembatan linux lxcbro dan menugaskan IP dan komponen jaringan pribadi, seperti yang terlihat pada Gambar 2.6.

Gambar 2.6 Linux Container (LXC) yang berada pada sebuah (Dua et al, 2014)

Universitas Sumatera Utara 18

Keuntungan utama LXC adalah implementasi ringan yang bekerja pada kecepatan asli yang menyediakan isolasi jaringan dan sistem yang lebih baik. Saat ini LXC menderita keterbatasan: 1. Container menggunakan kernel bersama. 2. Terbatas untuk lingkungan berbasis Linux. 3. Implementasi sangat berkaitan erat dengan kernel Linux.

2.6. Apache, MySQL, Vsftpd.

2.6.1. Apache Apache adalah sebuah perangkat lunak open source yang dikembangkan oleh komunitas Apache Software Foundation dirilis pada tahun 1995 yang berfungsi sebagai server web yang dapat dijalankan dibanyak sistem operasi (Windows, Linux, Unix, BSD serta platform lainnya) dan memiliki tugas untuk melayani serta membuat sebuah situs web bekerja dengan baik dengan menggunakan Hypertext Transfer Protocol atau biasa disingkat HTTP.

2.6.2. MySQL MySQL merupakan sebuah perangkat lunak open source sistem manajemen database yang dirilis pertama kali pada tahun 1995 dan pada saat ini dikembangkan oleh Oracle. MySQL pada dasarnya merupakan turunan salah satu konsep utama dalam database yang sudah ada sebelumnya yaitu Structured Query Language atau disingkat SQL. Suatu keuntungan suatu sistem database dapat diketahui dengan cara mengoptimalkan dalam melakukan proses perintah – perintah SQL yang dibuat oleh pengguna atau aplikasi yang memanfaatkan service tersebut.

2.6.3. Vsftpd Very secure ftp daemon (vsftpd) merupakan sebuah perangkat lunak yang digunakan dalam untuk melakukan File Transfer Protocol (FTP). FTP itu sendiri merupakan protokol yang digunakan untuk proses mengunduh atau mengunggah file antar komputer yang terpisah secara geografis. Vsftpd sudah menjadi default aplikasi untuk beberapa distro linux seperti Ubuntu dalam melakukan FTP. Pada dasarnya vsftpd merupakan aplikasi yang bersifat client-server dimana pada bagian server akan

Universitas Sumatera Utara 19

menyediakan sebuah tempat untuk para client dalam melakukan proses unduh dan unggah file.

2.7. Benchmark dan Crontab

2.7.1. Benchmark Benchmark merupakan sebuah metode yang dilakukan untuk menguji sebuah program atau perangkat lunak dimana tujuan dari pengujian itu adalah melihat nilai yang dihasilkan dari program atau perangkat lunak tersebut yang nantinya akan dimanfaatkan untuk pengembangan dari program atau perangkat lunak itu sendiri. Hasil dari nilai benchmark tersebut akan dijadikan sebagai acuan.

2.7.2. Crontab Crontab merupakan utilitas perangkat lunak yang berfungsi sebagai penjadwalan tugas (task). Task akan dieksekusi pada proses background ditentukan berdasarkan waktu yang sudah diatur sebelumnya dalam konfigurasi crontab itu sendiri. File crontab berisi sejumlah text yang mengandung perintah yang akan dijalankan pada waktu yang sudah ditentukan pada file tersebut.

2.8. Penelitian Terdahulu

Adapun beberapa penelitian terdahulu yang berhubungan dengan penelitian yang dibuat adalah penelitian pada tahun 2010 Wei et al yang meneliti pengalokasian resource pada service di cloud computing dengan menggunakan metode game- theoretic. Peneliti membatasi masalah alokasi khusus terhadap QoS, dimana para pengguna service berniat untuk memecahkan masalah komputasi paralel dengan meminta penggunaan sumber daya di seluruh jaringan cloud, dan biaya setiap layanan komputasi bergantung pada jumlah perhitungan. Game theory diterapkan dalam memecahkan masalah alokasi resource dengan membuat 2 langkah pendekatan yang ditawarkan. Pertama setiap pengguna memecahkan masalah dalam pengoptimalan secara independen, tanpa mempertimbangkan tugas multiplexing dari resource, Metode Pemrograman Biner Integer diusulkan untuk menyelesaikan masalah optimasi. Tahap kedua, dirancang mekanisme evolusioner yang mengubah strategi

Universitas Sumatera Utara 20

multiplexing dari solusi optimal yang awal yang berasal dari pengguna yang berbeda dengan meminimalisir kerugian dari efisiensi. Pada tahun 2013 Xavier et al melakukan beberapa percobaan dengan tujuan untuk melakukan evaluasi terhadap performa container dalam virtualisasi, serta membandingkan performa container dengan Xen, yang merepresentasikan virtualisasi hypervisor tradisional yang sering digunakan pada saat itu. Pada penelitiannya, Xavier membandingkan antara Linux VServer, OpenVZ, dan Linux Container (LXC) sebagai perbandingan dalam menentukan container yang disarankan untuk dipakai dalam virtualisasi. Ditahun yang sama Xiao, Song & Chen meneliti tentang alokasi resource pada mesin virtual secara dinamis pada cloud computing. Penelitian ini mempresentasikan sebuah sistem yang menggunakan teknologi virtualisasi untuk mengalokasi resource secara dinamis yang berdasarkan permintaan aplikasi dan mengoptimalkan jumlah server yang digunakan. Konsep Skewness diperkenalkan oleh peneliti untuk mengukur penggunaan resource multi dimensi dari sebuah server yang tidak merata. Dengan meminimalisir kemiringan, peneliti dapat mengkombinasikan berbagai jenis beban kerja dengan baik dan meningkatkan penggunaan resource pada server secara keseluruhan. Pada tahun 2014, Dua et al meneliti tentang perbandingan terhadap virtual machine dan container serta membandingkan container untuk menentukan pemilihan container yang tepat sebagai pengganti dari virtual machine untuk digunakan pada server. Pada penelitiannya, peneliti mengeksplorasi bagaimana vendor PaaS menggunakan container sebagai alat untuk aplikasi hosting. Penelitian ini dimulai dengan diskusi tentang use case PaaS dan adopsi arsitektur PaaS berbasis container dengan vendor yang ada. Peneliti juga mengeksplorasi berbagai implementasi container antara lain Linux Container (LXC), , Warden Container, lmctfy dan OpenVZ. Kami melihat bagaimana masing-masing implementasi ini menangani Proses, isolasi FileSystem dan Namespace. Kami melihat beberapa fitur unik dari setiap container dan bagaimana beberapa dari mereka menggunakan kembali implementasi Linux Container atau berbeda darinya. Peneliti juga mengeksplorasi bagaimana IaaS layer sendiri telah mulai memberikan dukungan untuk manajemen siklus hidup (life cycle) container bersama dengan mesin virtual.

Universitas Sumatera Utara 21

Masih pada tahun yang sama, Anuradha juga melakukan sebuah survey terhadap alokasi resource terbatas pada lingkungan cloud dengan menggunakan berbagai teknik alokasi resource pada lingkungan cloud dan membuat studi perbandingan tentang kelebihan dan kekurangan masing – masing teknik dengan tujuan untuk mengidentifikasi sebuah strategi efisien dalam pengalokasian resource dalam memanfaatkan resource terbatas pada lingkungan cloud. Penelitian ini menyajikan studi tentang strategi alokasi resource dalam cloud computing. Strategi tersebut meliputi algoritma prediksi kebutuhan resource dan algoritma alokasi resource. Strategi ini bekerja untuk mempelajari berbagai teknik alokasi resource yang digunakan dalam cloud computing dan membuat studi perbandingan tentang kelebihan dan kekurangan masing-masing teknik. Penelitian ini bertujuan untuk mengidentifikasi strategi alokasi resource yang efisien yang memanfaatkan resource secara efektif di lingkungan resource yang dibatasi resource.

Rangkuman dari penelitian-penelitian terdahulu dapat dilihat pada Tabel 2.1.

Tabel 2.1. Penelitian Terdahulu No. Judul Peneliti Tahun Keterangan 1. A game-theoretic method of Wei et al 2010 Peneliti membatasi fair resource allocation for masalah alokasi cloud computing services khusus terhadap QoS, dimana para pengguna service berniat untuk memecahkan masalah komputasi paralel dengan meminta penggunaan sumber daya di seluruh jaringan cloud, dan biaya setiap layanan komputasi

Universitas Sumatera Utara 22

bergantung pada jumlah perhitungan. Game theory diterapkan dalam memecahkan masalah alokasi resource. 2. Performance Evaluation of Xavier et al 2013 Peneliti melakukan Container-based beberapa percobaan Virtualization for High dengan tujuan untuk Performance Computing melakukan evaluasi Environments terhadap performa container dalam virtualisasi, serta membandingkan performa container dengan Xen, yang merepresentasikan virtualisasi hypervisor tradisional yang sering digunakan pada saat itu. 3. Dynamic resource Xiao, Z., 2013 Penelitian ini allocation using virtual Song, W., mempresentasikan machines for cloud & Chen, Q. sebuah sistem yang computing environment menggunakan teknologi virtualisasi untuk mengalokasi resource secara dinamis yang berdasarkan permintaan aplikasi

Universitas Sumatera Utara 23

dan mengoptimalkan jumlah server yang digunakan. Konsep Skewness diperkenalkan oleh peneliti untuk mengukur penggunaan resource multi dimensi dari sebuah server yang tidak merata. Dengan meminimalisir kemiringan, peneliti dapat mengkombinasikan berbagai jenis beban kerja dengan baik dan meningkatkan penggunaan resource pada server secara keseluruhan. 4. Virtualization vs Dua et al 2014 Peneliti melakukan Containerization to support perbandingan PaaS terhadap virtual machine dan container serta membandingkan container untuk menentukan pemilihan container yang tepat sebagai pengganti dari

Universitas Sumatera Utara 24

virtual machine untuk digunakan pada server. .5. A survey on resource Anuradha, 2014 Peneliti melakukan allocation strategies in V. P. & survey terhadap cloud computing Sumathi, D strategi pengalokasian resource pada lingkungan cloud dengan tujuan mengidentifikasi sebuah strategi efisien dalam pengalokasian resource yang memanfaatkan resource yang terbatas secara efektif pada lingkungan cloud computing.

Universitas Sumatera Utara BAB 3

ANALISIS DAN PERANCANGAN

Pada bab ini akan dibahas mengenai analisis dan perancangan sistem. Pada tahap analisis akan dilakukan analisis bagaimana Linux Container bekerja pada proxmox, pengaturan resource yang ada pada server dan memahami proses penjadwalan pada pengalokasian resource. Pada tahap perancangan akan dibahas mengenai tahap-tahap yang dilakukan dalam merancang sistem.

3.1. Analisis Permasalahan

Untuk memahami bagaimana sebuah Linux Container bekerja, diberikan sebuah contoh kasus yaitu sebuah komputer akan digunakan sebagai hypervisor, dan didalamnya akan terdapat 3 Linux Container yang berfungsi sebagai server dan masing – masing akan diberikan sebuah service yaitu apache, mysql dan ftp.

apache mysql ftp

Lxc 1 Lxc 2 Lxc 3

Linux Kernel (hypervisor)

Alokasi Alokasi Alokasi lxc 1 lxc 2 lxc 3

Resource (Hardware)

Gambar 3.1 Model pemanfaatan Linux Container

Dalam gambar 3.1 terlihat bahwa dalam hypervisor tersebut terdapat 3 buah Linux Container yang masing – masing memiliki sebuah service yang dijalankan yaitu apache, mysql dan ftp. Resource yang ada pada hypervisor tersebut dibagi

Universitas Sumatera Utara 26

sesuai dengan jumlah container yang ada. Penggunaan resource prosesor dan RAM diatur sedemikian rupa agar container tersebut dapat menjalan masing – masing service yang terdapat pada container tersebut. Resource lainnya seperti storage dan NIC (Network Interface Card) juga akan diatur untuk menjaga kestabilan kinerja server.

3.2. Arsitektur Umum

Setelah menganalisis permasalahan dari informasi yang didapat pada tahapan sebelumnya, pada tahap ini akan dilakukan perancangan sistem yang sesuai dengan hasil analisa permasalahan. Pada penelitian ini, arsitektur umum dari perancangan sistem dapat dilihat pada Gambar 3.2.

Gambar 3.2 Arsitek Umum

Universitas Sumatera Utara 27

Dari Gambar 3.2 dapat dilihat bahwa penelitian ini terdiri dari 3 tahapan yaitu input, proses dan output. 1. Input Pada proses ini, client akan memberikan beban (load) kepada masing – masing container untuk meningkatkan pemakaian CPU dan memory dari container, selanjutnya client juga akan memberikan benchmark yang disesuaikan terhadap service yang ada pada masing – masing container. 2. Proses Pada tahap ini load yang telah diberikan oleh client akan dikerjakan oleh masing – masing container sehingga terjadi proses dalam menangani load yang telah diberikan terhadap container. Pada saat yang bersamaan maka proses alokasi resource juga berjalan, dimana pada proses ini diambil data – data dari masing – masing container terhadap pemakaian CPU dan juga memory sehingga akan diketahui tingkat persentasi penggunaan resource tersebut dari masing – masing container. Ketika sebuah container memiliki beban yang cukup tinggi maka container tersebut akan memberikan sebuah data yang dimana nantinya data tersebut akan digunakan sebagai acuan bahwa container tersebut memerlukan resource tambahan. Apabila ada container yang memiliki resource yang lebih dan pemakaian terhadap resource pada container tersebut dibawah batas yang sudah ditentukan, maka container tersebut juga akan memberikan data untuk memberitahukan kepada container lain bahwa resource yang dimiliki dapat diberikan kepada container yang membutuhkan. Ketika kedua situasi tersebut tercapai maka resource akan berpindah dari container yang memiliki resource lebih ke container yang sedang membutuhkan resource tambahan yang berfungsi untuk menjalankan load atau benchmark yang diberikan pada tahap sebelumnya sehingga memberi hasil yang lebih maksimal pada container tersebut. Proses diatas penulis terapkan pada hypervisor Proxmox VE dan container yang akan penulis terapkan adalah Linux Container (LXC). 3. Output Output dari proses yang sudah dijalankan adalah berupa utilization dari masing – masing container dari benchmark yang diberikan terhadap penggunaan resource yang diteliti.

Universitas Sumatera Utara 28

3.3. Alokasi Resource Pada Linux Container

Pada proxmox, setiap Linux Container (LXC) mempunya dua buah file konfigurasi. Pada file konfigurasi pertama menunjukkan alokasi resource mentah (raw), sementara konfigurasi yang kedua digunakan proxmox untuk mendefinisikan container. File konfigurasi raw container terdapat pada /var/lib/lxc//config. Sementara file yang digunakan proxmox untuk konfigurasi container terdapat pada /etc/pve/local/lxc/.conf. Gambar 3.3 dan 3.4 merupakan contoh dari konfigurasi file raw container dan konfigurasi file yang dipakai proxmox untuk mendefinisikan container.

Gambar 3.3 Contoh file konfigurasi raw container

Gambar 3.4 Contoh konfigurasi file container yang digunakan proxmox

Universitas Sumatera Utara 29

Pada Gambar 3.3 dan 3.4 dapat dilihat bahwa kedua konfigurasi file tersebut sama – sama menunjukkan isi dari sebuah container. Salah satu keuntungan memakai container adalah seorang sys-administrator dapat dengan mudah melakukan alokasi resource tanpa harus mematikan daya dari container hal ini dikarenakan pada LXC memakai kernel namespaces dalam menyediakan isolasi resource antar container dan manajemen resource hanya dapat diakses melalui cgroups. LXC menggunakan cgroups untuk menentukan kontrol proses yang berfungsi mengisolasi container dan proses.

3.3.1. Alokasi Resource Memory Pada sistem yang hendak dibangun, pengalokasian memory ditujukan kepada container yang sedang menerima load yang cukup tinggi sehingga memerlukan memory tambahan pada container tersebut. untuk mencapai pendekatan tersebut maka diperlukan data dari memory pada masing – masing container untuk mengetahui kebutuhan memory melalui persentasi memory yang sedang dipakai dan juga jumlah memory total yang ada pada sebuah container, misalkan Mu100, Mu101,…,Mun merupakan memory keseluruhan yang terpakai sejak container dinyalakan dan Mc100,

Mc101,…,Mcn adalah penggunaan memory cache pada container. maka untuk mendapatkan penggunaan memory yang benar didapatkan dari persamaan 3.1 :

(3.1)

Dimana : Mrealn = Nilai pemakaian memory real-time container n

Mun = Nilai pemakaian memory keseluruhan container n

Mcn = Nilai pemakaian memory cache container n

Setelah mendapatkan nilai dari pemakaian memory yang real dari Persamaan 3.1 yang merupakan hasil selisih dari pemakaian memory keseluruhan terhadap pemakaian memory cache, selanjutnya akan dihitung nilai dari persentasi memory dengan membandingkan hasil memory real-time dari Persamaan 3.1 dengan jumlah memory yang ada pada container, sehingga persentasi pemakaian memory didapatkan dari persamaan 3.2 :

Universitas Sumatera Utara 30

( ) (3.2)

Dimana : PM = Persentase penggunaan memory Mreal = Nilai penggunaan memory real-time Mtot = Nilai memory total yang tersedia n = Container ID (CTID)

Dari Persamaan 3.2 didapatkan persentase penggunaan memory yang terpakai dari sebuah container. Bergerak dari nilai persentase yang didapatkan maka alokasi resource memory dapat diterapkan dengan membandingkan persentasi memory container yang lain dan jumlah memory total yang ada pada container lain. Gambar 3.5 adalah pseudocode dari alokasi resource memory yang akan diterapkan: syaratpindahmemory=0 bataspindahmemory=400 memorypindah=$(($memorytotal/2)) FunctionSyarat() if [[ $percentmemory -gt 75 ]];then syaratpindahmemory='1' elif [[ $percentmemory -lt 30 ]];then syaratpindahmemory='2' fi end function function pindahmemory() if [[ $syaratpindahmemory - eq 1 && $syaratpindahmemorylain -eq 2 ]]; then if [[ $memorypindahlain -gt $bataspindahmemory ]];then memorytotalbaru=$(($memorytotal + $memorypindahlain)) set memorytotalbaru fi fi end function

Gambar 3.5 Pseudocode alokasi resource memory

Universitas Sumatera Utara 31

Berdasarkan pseudocode dari Gambar 3.5 terdapat beberapa tahap sebelum melakukan alokasi resource memory. Diberikan contoh ketika sebuah LXC dengan CTID 100 dengan kapasitas memory 1024Mb dan sebuah LXC dengan CTID 101 dengan kapasistas memory 1024Mb. Ketika LXC100 diberikan beban sehingga persentase memory yang terpakai mencapai 75% dan LXC101 diberikan beban namun hanya memakai memory sebesar 25%, maka akan terjadi perubahan syaratpindahmemory pada LXC100 dari 0 menjadi 1 pada sistem, Selanjutnya LXC101 juga akan memberikan perubahan nilai pada syaratpindahmemory yang dimilikinya dari 0 menjadi 2. Setelah masing – masing LXC mengubah syaratpindahmemory, maka dilakukan tahap berikutnya yaitu sistem melakukan pengecekan terhadap syaratpindahmemory yang ada pada kedua LXC, ketika memenuhi syarat untuk melakukan perpindahan memory, maka sistem akan memberikan perintah agar LXC101 menyumbangkan resource memory miliknya kepada LXC100. Dari penjelasan di atas maka dapat direpresentasikan diagram alur (flowchart) untuk alokasi resource memory seperti pada gambar 3.6.

Universitas Sumatera Utara 32

Start

memory_total, memory_usage, memory_cache

No No memory_percent memory_percent Syarat_pindah > 75 % < 30 % = 0

Yes Yes

Syarat_pindah Syarat_pindah = 1 = 2

memory_percentage

memory_total = Pindah_memory memory_total + Get value memory_pindah syarat_pindah

Yes

Syarat_pindah = 1 Yes Batas_pindah = 400, && If memorypindah > End syarat_pindah_dari_ batas_pindah yanglain = 2

No No

Gambar 3.6 Diagram alur alokasi resource memory

Universitas Sumatera Utara 33

3.3.2. Alokasi Resource CPU Pada sistem yang hendak dibangun juga akan diterapkan alokasi resource CPU yang bertujuan untuk meringankan kerja CPU pada container yang sudah menghabiskan resource CPU pada saat mengerjakan beban (load). Proses alokasi resource CPU memerlukan data dari masing masing CPU yang ada pada hypervisor yang diterapkan pada container, hal ini bertujuan untuk mengetahui persentase penggunaan CPU dan juga jumlah CPU core yang ada pada masing – masing container. Jumlah core dapat diketahui dari file konfigurasi raw container maupun dari file konfigurasi yang dipakai oleh proxmox itu sendiri. Sementara untuk pemakaian dari masing – masing CPU core itu sendiri terdapat pada file /proc/stat seperti pada Gambar 3.7.

Gambar 3.7 Status pemakaian CPU pada masing – masing core

Pada Gambar 3.7 terdapat beberapa nilai yang ada pada sebuah core CPU. Angka tersebut memiliki arti yang berbeda – beda. Untuk mendapatkan pemakaian CPU pada sebuah core maka diperlukan nilai dari pemakaian CPU terhadap user, nice, system dan idle. Sebagai contoh untuk mengambil nilai pemakaian CPU pada core 0, maka diperlukan nilai pemakaian CPU pada core 0 terhadap user, nice, system dan idle, sehingga diperoleh Persamaan 3.3.

(3.3)

Universitas Sumatera Utara 34

Dimana : CPU = Nilai Pemakaian total CPU USR = Nilai Pemakaian CPU terhadap user NC = Nilai Pemakaian CPU nice SYS = Nilai Pemakaian CPU terhadap system ID = Nilai Pemakaian CPU pada saat idle N = Nilai core yang ada pada CPU

Dari Persamaan 3.3 maka akan didapatkan hasil dari pemakaian total CPU yang ada pada sebuah core. Untuk menentukan alokasi resource CPU diperlukan nilai persentase yang ada pada core. Nilai CPU pada masing – masing core selalu berubah – ubah hal ini dikarenakan CPU akan tetap terus bekerja bahkan pada saat tidak sedang menjalankan proses (idle). Nilai CPU berubah setiap nano detik (ns) maka untuk mendapatkan persentase pemakaian CPU diperlukan sebuah kondisi khusus dimana nilai pemakaian CPU diambil pada dua kondisi yang memiliki selang waktu. Kemudian dari kedua nilai pemakaian CPU yang diambil pada waktu yang berbeda dapat diketahui persentase pemakaian CPU untuk sebuah core. Dari proses tersebut maka diperoleh Persamaan 3.4.

( ) (3.4)

Dimana : PCPUn = Persentase Pemakaian CPU pada core n ∆CPUt = Selisih dari Nilai CPU total terhadap waktu t IDt2 = Nilai Pemakaian CPU idle pada waktu t2 ID t1 = Nilai Pemakaian CPU idle pada waktu t1

Dari Persamaan 3.4 didapatkan persentase pemakaian CPU yang nantinya akan digunakan untuk alokasi resource CPU pada container. Nilai Persentase CPU sebuah container yang melebihi dari batas yang ditetapkan maka berarti container hampir memakai seluruh resource CPU yang ada pada container tersebut sehingga diperlukan alokasi CPU dari container lainnya dengan terlebih dahulu memeriksa persentase CPU dan jumlah core pada container yang hendak memberikan resource CPU.

Universitas Sumatera Utara 35

syaratpindahcpu=0 jumlahcorecpu jumlahcorecpulain FunctionSyarat() if [[ $percentcpu -gt 75 ]];then syaratpindahcpu='1' elif [[ $percentcpu -lt 30 ]];then syaratpindahcpu='2' fi end function function pindahcpu() if [[ $syaratpindahcpu - eq 1 && $syaratpindahcpulain -eq 2 ]]; then if [[ $jumlahcorelain -gt 1]];then jumlahcorecpulain=$(($jumlahcorecpulain - 1)) jumlahcorecpu=$(($jumlahcorecpu + 1)) set cpu $jumlahcorecpu fi fi end function

Gambar 3.8 Pseudocode alokasi resource CPU

Dapat dilihat pada gambar 3.8 terdapat beberapa tahap sebelum alokasi resource CPU dieksekusi. Diberikan sebuah contoh yang sama dengan alokasi resource memory dimana LXC100 memiliki CPU core sebanyak 2 buah dan LXC 101 memiliki CPU core sebanyak 2 buah, ketika LXC100 memakai CPU hingga mencapai 80% maka syaratpindahcpu pada LXC100 akan berubah dari 0 menjadi 1, pada saat yang bersamaan LXC101 memakai CPU sebanyak 10%, maka syaratpindahcpu pada LXC101 juga berubah dari 0 menjadi 2. Setelah syaratpindahcpu dari kedua buah container sudah berubah dan memenuhi syarat untuk melakukan alokasi resource CPU, maka dari contoh tersebut LXC101 akan menyumbangkan 1 buah CPU core kepada LXC100 sehingga LXC100 mempunyai 3 buah CPU core. Dari penjelasan diatas maka dapat direpresentasikan diagram alur (flowchart) untuk alokasi resource CPU seperti diberikan pada Gambar 3.9.

Universitas Sumatera Utara 36

Start

cpu_usage, jumlahcore, cpuset

No No cpu_percent cpu_percent Syarat_pindah > 75 % < 30 % = 0

Yes Yes

Syarat_pindah Syarat_pindah = 1 = 2

cpu_percent

Jumlah_core = Pindah_cpu Get value Jumlah_core + 1 syarat_pindah

Yes

Syarat_pindah = 1 Yes && Jumlah_core_lain syarat_pindah_dari_ > 1 End yanglain = 2

No No

Gambar 3.9 Diagram alur alokasi resource CPU

Universitas Sumatera Utara 37

3.4. Pengelolaan Container Pada Proxmox

Pada penelitian tugas akhir ini, penulis memilih proxmox sebagai hypervisor untuk menjalankan Linux Container yang merupakan container built-in dari proxmox dimulai versi 4.1. Pada proxmox terdapat tool khusus yang digunakan untuk mengatur container tool tersebut adalah Proxmox Container Tools atau biasa disingkat dengan PCT. pct itu sendiri merupakan sebuah command line tool yang digunakan untuk mengatur Linux Container pada proxmox. Pct dapat digunakan untuk menciptakan, menghancurkan dan mengatur eksekusi (start, stop, migrate) pada container. pct dapat digunakan untuk menerapkan aturan yang sudah dibuat untuk pengalokasian resource pada tahap sebelumnya. Tabel 3.1 adalah kumpulan perintah – perintah dari pct untuk mengubah resource yang ada pada container, tidak semua perintah dari pct digunakan pada penelitian tugas akhir ini.

Tabel 3.1 Daftar perintah pct Pct Command (pct set) Keterangan Arch Menentukan arsitektur sistem operasi. Menentukan mode console. Terdapat 3 pilihan dari opsi Cmode ini yaitu console, shell atau tty. Menentukan jumlah core yang diberikan kepada Cores container. Cpulimit Batas dari pemakaian CPU. Berat untuk CPU pada mesin virtual, semakin besar Cpuunits jumlahnya, semakin banyak waktu CPU mesin virtual tersebut. Delete Menghapus setting pada file konfigurasi Deskripsi dari container. hanya bisa digunakan pada Description konfigurasi antarmuka web. Mencegah perubahan konfigurasi jika memiliki SHA1 Digest digest yang berbeda, berguna untuk mencegah modifikasi bersamaan.

Universitas Sumatera Utara 38

Tabel 3.1 Daftar perintah pct (lanjutan) Pct Command (pct set) Keterangan Hostname Mengganti nama host dari container Lock Mengunci atau membuka container Mengatur jumlah RAM dari container dalam Memory Megabytes Menggunakan volume atau folder sebagai mount point Mp pada container Nameserver Mengatur alamat IP DNS server pada container Net Mengatur spesifikasi interface jaringan pada container Mengatur apakah container akan langsung menyala Onboot ketika sistem host hidup. Mengatur flag pelindung dari container. yang berguna Protection untuk mencegah operasi hapus/update CT disk. Rootfs Menggunakan volume sebagai root container Searchdomain Mengatur pencarian domain DNS untuk container Swap Mengatur jumlah swap memory. Template Mengaktifkan atau menonaktifkan template Tty Menentukan jumlah tty yang tersedia untuk container Membuat container berjalan sebagai unprivileged user. Unprivileged (tidak dianjurkan untuk mengubah secara manual) Referensi untuk volume yang tidak terpakai.digunakan Unused secara internal, dan tidak boleh dimodifikasi secara manual.

Dari tabel 3.1 dapat dilihat bahwa untuk mengalokasikan resource CPU dan memory dapat dilakukan melalui tool tersebut. sehingga penerapan alokasi resource yang sudah dirancang dapat dilakukan pada penelitian tugas akhir ini.

Universitas Sumatera Utara BAB 4

IMPLEMENTASI

4.1. Konfigurasi Sistem

Implementasi dan pengujian pengalokasian resource pada linux container di proxmox virtual environment dengan menggunakan bahasa Bash script.

4.1.1. Spesifikasi Perangkat Keras Spesifikasi perangkat keras yang digunakan pada penelitian ini dapat dilihat dari tabel 4.1:

Tabel 4.1 Spesifikasi perangkat keras yang digunakan. No. Jenis Komponen Komponen yang digunakan 1. Processor Intel Core i5 quad-core 7200U up to 3.10 2. Memory 4 GB DDR4 3. Storage 1 TB 5400RPM 4. Network Integrated 802.11b/g/n, 10/100/1000 BASE T 1 port USB 3.0 (Untuk instalasi) 5. Interface 1 RJ45 LAN jack (Untuk instalasi)

4.1.2. Instalasi Proxmox Virtual Environment Proxmox VE yang digunakan pada penelitian ini adalah Proxmox VE No-Subscription yang merupakan salah satu repositori paket yang dikembangkan oleh proxmox untuk proses pengujian sebelum masuk kedalam tahap produksi yang dapat diunduh dari www.proxmox.com Untuk instalasi proxmox itu sendiri dapat dilakukan dengan 2 cara, yaitu bare- metal yang berarti melakukan instalasi terhadap sebuah komputer fisik yang tidak mempunyai sistem operasi atau belum mempunyai perangkat lunak lain didalamnya, cara yang lain adalah dengan melakukan instalasi pada sistem operasi debian yang

Universitas Sumatera Utara 40

sudah ada sebelumnya pada komputer fisik. Pada penelitian ini, penulis melakukan instalasi dengan cara bare-metal pada sebuah komputer dengan spesifikasi yang sudah dijelaskan sebelumnya dengan menggunakan sebuah USB stick yang didalamnya terdapat file ISO image dari proxmox yang akan diinstal yang sudah diunduh sebelumnya. Pada proses Instalasi proxmox yang perlu diperhatikan adalah menentukan jenis partisi yang digunakan untuk proxmox dan menentukan konfigurasi jaringan awal yaitu penentuan alamat ip yang nantinya akan digunakan untuk mengakses halaman dashboard dari proxmox melalui web browser yang digunakan. Setelah proses instalasi selesai, konfigurasi selanjutnya dapat dilakukan melalui Command Line Interface (CLI) atau dengan mengakses Web-based User Interface yang disediakan oleh proxmox dengan format sebagai berikut :

https://:8006

Contoh untuk mengakses proxmox melalui CLI atau melalui halaman web dapat dilihat pada gambar 4.1, 4.2, dan 4.3.

Gambar 4.1 Command Line Interface pada proxmox

Universitas Sumatera Utara 41

Gambar 4.2 Halaman login proxmox melalui web

Gambar 4.3 Halaman dashboard proxmox melalui web

Pada tahap berikutnya, diperlukan sebuah user baru pada proxmox dikarenakan pada proses instalasi hanya terbentuk satu buah user yaitu root. Root merupakan user dengan hak akses tertinggi yang dapat melakukan perubahan apapun terhadap sistem. Untuk mengoperasikan komputer disarankan untuk tidak menggunakan user root karena dapat menyebabkan kerusakan pada sistem ketika melakukan kesalahan dalam konfigurasi atau secara tidak sengaja menghapus file yang penting. Untuk mengurangi resiko yang ditimbulkan akibat kesalahan dalam penggunaan user root maka diperlukan user baru yang mengoperasikan proxmox, apabila user root diperlukan

Universitas Sumatera Utara 42

dalam konfigurasi dapat melakukan login super-user untuk menggunakan hak akses root melalui CLI. Untuk membuat user baru dapat dilakukan dengan 2 cara yaitu melalui CLI atau melalui halaman dashboard proxmox. Pada halaman dashboard proxmox, untuk membuat user atau group baru dapat membuka pengaturan yang ada pada menu Datacenter>Permissions>User. Pada CLI untuk membuat sebuah user dengan nama hans-admin dengan home directory /home/hans-admin/ yang memiliki hak akses sebagai administrator dengan memasukkan kedalam group admin dapat menggunakan perintah sebagai berikut: # adduser –-home /home/hans-admin --shell /bin/bash hans- admin

Gambar 4.4 Membuat user baru melalui halaman dashboard proxmox

Hal yang perlu disiapkan lainnya adalah pengaturan alamat IP (Internet Protocol) pada konfigurasi jaringan yang bertujuan agar komputer yang dijadikan sebagai server ini dapat terkoneksi dengan internet, terhubung dengan container yang akan dibuat melalui virtual bridge sehingga container juga mampu mengakses internet melalui perantara host dan komputer host dapat diakses oleh komputer lain atau client melalui jaringan. Sama seperti pada distro debian pada umumnya, pengaturan jaringan pada proxmox tersimpan pada /etc/network/interfaces yang hanya bisa diakses oleh root atau melalui halaman dashboard proxmox host dengan hak akses yang diizinkan adalah administrator. Oleh karena itu, untuk mengubah konfigurasi jaringan pada

Universitas Sumatera Utara 43

proxmox diperlukan akses root atau dengan menggunakan perintah sudo pada CLI atau langsung mengubah konfigurasi jaringan dari halaman dashboard dengan masuk sebagai user yang memiliki hak akses administrator. Adapun konfigurasi jaringan yang dipakai pada penelitian ini dapat dilihat pada gambar 4.5 dan 4.6.

Gambar 4.5 Konfigurasi jaringan pada host melalui CLI

Gambar 4.6 Konfigurasi jaringan melalui halaman web.

Universitas Sumatera Utara 44

Pada proxmox, yang menjadi jembatan untuk menghubungkan antara mesin virtual atau container terhadap jaringan internet adalah host dimana mesin virtual atau container itu berada. Pada penelitian ini, penulis memanfaatkan teknologi wireless yang ada pada komputer untuk terhubung ke internet. Sehingga konfigurasi jaringan serta virtual bridge disesuaikan dengan teknologi wireless tersebut.

4.1.3. Instalasi Linux Container dan Service Pada Container. Pada penelitian ini, jumlah container yang akan digunakan sebanyak 3 buah yang diberikan sebuah service yang berbeda pada masing – masing container. Adapun spesifikasi container yang hendak dibangun dapat dilihat pada tabel 4.2.

Tabel 4.2 Spesifikasi container yang dibangun pada host Linux Container ID 100 101 102 Container hostname Ubuntu1 Debian Ubuntu2 Sistem Operasi Ubuntu 17.04 Debian 8.0 Ubuntu 17.04 Memory 1 GB 1GB 2GB CPU core 1 1 2 Service yang digunakan Apache Mysql Vsftpd

Sama halnya dengan membuat user baru pada proxmox, untuk membuat sebuah container dapat dilakukan melalui halaman dashboard proxmox dengan terlebih dahulu mengunduh template dari container yang akan digunakan dan akan tersimpan pada direktori /var/lib/vz ,selanjutnya template yang telah diunduh dapat digunakan untuk membuat container dari menu create CT kemudian mengisi spesifikasi container seperti jenis sistem operasi sesuai dengan template yang sudah diunduh, jumlah memory, cpu core, serta pengalamatan ip pada container tersebut, seperti yang dapat dilihat pada gambar 4.7, 4.8 dan 4.9.

Universitas Sumatera Utara 45

Gambar 4.7 Pilihan template yang bisa diunduh melalui halaman dashboard

Gambar 4.8 Template yang sudah terunduh disimpan pada penyimpanan local

Gambar 4.9 Pembuatan container melalui halaman dashboard

Universitas Sumatera Utara 46

Setelah pembuatan container, langkah selanjutnya adalah menjalankan container tersebut. Untuk menjalankan atau menghentikan sebuah container dapat dilakukan melalui halaman dashboard atau melalui CLI. Adapun perintah CLI untuk menjalankan container yaitu sebagai berikut:

# pct start

Setelah container dijalankan tahap berikutnya adalah melakukan instalasi service kepada masing – masing container. Instalasi dilakukan dengan melakukan akses langsung terhadap container dengan menggunakan proxmox container tools (pct) yang dapat diakses melalui CLI dengan melakukan perintah sebagai berikut :

# pct enter

Setelah memasuki container untuk melakukan instalasi service dapat menggunakan tools default dari linux yaitu aptitude. Pada tugas akhir ini, konfigurasi pada masing – masing service yang akan diinstall pada container merupakan konfigurasi default. Pada LXC 100, file konfigurasi apache terdapat pada /etc/apache2/apache2.conf. untuk file konfigurasi mysql pada LXC 101 terdapat pada /etc/mysql/my.cnf . Pada LXC 102, konfigurasi vsftpd terdapat pada /etc/vsftpd.conf.

4.1.4. Pengaturan Alokasi Resource Setelah membuat container serta melakukan instalasi service pada container, tahap selanjutnya adalah melakukan pengaturan alokasi resource yang sudah dibuat. Pada tugas akhir ini pengalokasian resource dibuat menggunakan bash script yang diletakkan pada direktori /home/alokasi-resource dan mengeksekusinya dengan menggunakan crontab agar script dapat berjalan pada proses background. Untuk mengeksekusi script melalui crontab dapat menjalakankan perintah crontab –e pada terminal, kemudian mengatur parameter waktu yang digunakan untuk menjalakan script alokasi resource yang sudah dibuat. Langkah terakhir, restart service crontab untuk menjalankan konfigurasi crontab yang baru dengan menjalankan perintah service cron restart pada terminal. Untuk melihat

Universitas Sumatera Utara 47

status cron dapat menjalankan perintah service cron status pada terminal agar memastikan bahwa cron yang sudah dibuat berjalan seperti pada gambar 4.10.

Gambar 4.10 Status cron yang berjalan pada proses background

4.2. Pengujian Sistem

Pengujian sistem dilakukan untuk mengetahui hasil dari pengalokasian resource yang sudah diterapkan terhadap kemampuan service yang ada pada masing – masing container dalam menjalankan request yang diberikan. Untuk melakukan pengujian terhadap service pada container digunakan tool atau program yang dapat mensimulasikan kondisi kerja yang berat pada CPU dan memory sehingga dapat menguji kemampuan dari service yang ada pada container.

4.2.1. Program Yang Digunakan Dalam Pengujian Adapun tool atau program yang digunakan pada pengujian tugas akhir ini adalah sebagai berikut: a. Apache-benchmark Aplikasi yang digunakan untuk menguji service apache pada LXC 100 adalah apache-benchmark. Apache-benchmark (ab) digunakan untuk mengukur kinerja apache http server, ab memberikan gambaran performa terhadap kinerja apache yang sudah diinstal pada server. Adapun parameter ab yang digunakan pada pengujian adalah total jumlah request yang akan diberikan dan jumlah request yang dijalankan bersamaan pada waktu yang bersamaan.

Universitas Sumatera Utara 48

b. Sysbench Sysbench merupakan tool yang digunakan untuk menguji kinerja service mysql pada LXC 101. Sysbench yang digunakan untuk pengujian ini dikhususkan terhadap pengujian mysql. Parameter yang digunakan dari sysbench terhadap pengujian mysql banyaknya jumlah tabel yang akan diuji pada sebuah database dengan batas waktu yang ditentukan c. Stress dan Stress-ng Stress dan stress-ng merupakan tool yang digunakan untuk memberikan beban terhadap resource container. hal ini diperlukan untuk mengukur batas maksimum yang bisa dicapai oleh container dengan resource yang dimilikinya untuk tujuan pengujian. Parameter yang dipakai dari tool stress adalah jumlah pekerjaan yang diberikan terhadap memory, dan besar jumlah memory yang hendak digunakan. Sementara pada tool stress-ng parameter yang digunakan adalah banyaknya CPU yang akan diberikan beban serta persentase jumlah CPU yang dipakai. d. Apache-JMeter Apache-JMeter merupakan sebuah aplikasi berbasis java yang digunakan untuk menguji kinerja dari service FTP pada LXC 102. Adapun parameter yang akan digunakan adalah jumlah pengguna yang akan menggunakan service FTP dalam melakukan proses unggah dan unduh dari sebuah file pada FTP server pada LXC 102.

4.2.2. Skenario Pengujian Dalam pengujian tugas akhir ini, penulis akan memberikan beberapa skenario pengujian terhadap container dan melihat nilai dari benchmark yang diberikan. Adapun skenario pengujian yang akan diberikan kepada masing – masing container adalah sebagai berikut : 1. Kondisi idle pada masing – masing container. 2. LXC 100 akan diberikan beban dan diberikan benchmark, sementara LXC 101 dan 102 berada dalam kondisi idle. 3. LXC 100 akan diberikan beban dan diberikan benchmark, LXC 101 dan 102 berada dalam kondisi idle, pengalokasian resource diterapkan.

Universitas Sumatera Utara 49

4. LXC 100 dan 101 akan diberikan beban kemudian diberikan benchmark, sementara LXC 102 diberikan benchmark dalam kondisi idle. 5. LXC 100 dan 101 akan diberikan beban kemudian diberikan benchmark, LXC 102 diberikan benchmark dalam kondisi idle, pengalokasian resource diterapkan.

4.3 Hasil Pengujian

Hasil pengujian diperoleh dengan mengamati resource yang dimiliki oleh container ketika pengalokasian resource diterapkan dan nilai hasil dari benchmark yang dilakukan terhadap LXC 100 dan LXC 101 sesuai dengan skenario yang sudah direncanakan. Pada skenario pengujian yang pertama masing – masing container berada dalam kondisi idle yang berarti sedang tidak menerima beban. Dapat dilihat penggunaan resource masing – masing container dalam kondisi idle seperti pada gambar 4.11

Gambar 4.11 Resource pada skenario pertama

Universitas Sumatera Utara 50

Pada skenario pengujian kedua, LXC 100 akan diberikan beban kemudian akan diberikan benchmark namun dua container lainnya yaitu LXC 101 dan 102 tetap pada kondisi idle. Pada skenario ketiga, pengalokasian resource diterapkan, LXC 100 akan diberikan beban yang kemudian diberikan benchmark, LXC 101 dan 102 berada dalam kondisi idle. Hasil dari skenario kedua dan ketiga dapat dilihat pada gambar 4.12 dan 4.13.

Gambar 4.12 Hasil resource pengujian skenario kedua

Universitas Sumatera Utara 51

Gambar 4.13 Hasil resource pengujian skenario ketiga

Dari gambar 4.12 dan 4.13 dapat dilihat perbedaan resource antara skenario pengujian kedua dengan skenario pengujian ketiga pada skenario kedua resource yang dimiliki container tidak mengalami perubahan, sementara pada skenario ketiga ketika pengalokasian resource diterapkan maka LXC 100 akan menerima resource tambahan yaitu berupa core CPU dan memory yang berasal dari LXC 101 dan 102 sehingga penggunaan resource CPU dan memory pada LXC 100 menjadi berkurang. Gambar 4.14 dan 4.15 merupakan nilai benchmark yang diberikan terhadap service yang ada pada LXC 100 dalam skenario pengujian kedua dan ketiga.

Universitas Sumatera Utara 52

root@ubuntu1:~# ab -n 30000 -c 100 192.168.50.2/clinic/index.php This is ApacheBench, Version 2.3 <$Revision: 1757674 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 192.168.50.2 (be patient) Completed 3000 requests Completed 6000 requests Completed 9000 requests Completed 12000 requests Completed 15000 requests Completed 18000 requests Completed 21000 requests Completed 24000 requests Completed 27000 requests Completed 30000 requests Finished 30000 requests

Server Software: Apache/2.4.25 Server Hostname: 192.168.50.2 Server Port: 80

Document Path: /clinic/index.php Document Length: 7693 bytes

Concurrency Level: 100 Time taken for tests: 153.740 seconds Complete requests: 30000 Failed requests: 0 Total transferred: 242250000 bytes HTML transferred: 230790000 bytes Requests per second: 195.13 [#/sec] (mean) Time per request: 512.467 [ms] (mean) Time per request: 5.125 [ms] (mean, across all concurrent requests) Transfer rate: 1538.78 [Kbytes/sec] received

Universitas Sumatera Utara 53

Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 1.8 0 34 Processing: 3 512 376.4 413 3596 Waiting: 3 512 376.4 412 3596 Total: 3 512 376.2 413 3596

Percentage of the requests served within a certain time (ms) 50% 413 66% 561 75% 651 80% 711 90% 820 95% 1053 98% 1685 99% 2382 100% 3596 (longest request) root@ubuntu1:~#

Gambar 4.14 Hasil benchmark pengujian skenario kedua terhadap LXC 100

root@ubuntu1:~# ab -n 30000 -c 100 192.168.50.2/clinic/index.php This is ApacheBench, Version 2.3 <$Revision: 1757674 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 192.168.50.2 (be patient) Completed 3000 requests Completed 6000 requests Completed 9000 requests Completed 12000 requests Completed 15000 requests Completed 18000 requests Completed 21000 requests Completed 24000 requests Completed 27000 requests Completed 30000 requests Finished 30000 requests

Server Software: Apache/2.4.25 Server Hostname: 192.168.50.2 Server Port: 80

Universitas Sumatera Utara 54

Document Path: /clinic/index.php Document Length: 7693 bytes

Concurrency Level: 100 Time taken for tests: 147.419 seconds Complete requests: 30000 Failed requests: 0 Total transferred: 242250000 bytes HTML transferred: 230790000 bytes Requests per second: 203.50 [#/sec] (mean) Time per request: 491.397 [ms] (mean) Time per request: 4.914 [ms] (mean, across all concurrent requests) Transfer rate: 1604.76 [Kbytes/sec] received

Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 1.5 0 65 Processing: 3 491 384.2 409 4427 Waiting: 3 490 384.3 409 4427 Total: 3 491 384.0 410 4427

Percentage of the requests served within a certain time (ms) 50% 410 66% 539 75% 635 80% 683 90% 826 95% 988 98% 1462 99% 2365 100% 4427 (longest request)

root@ubuntu1:~#

Gambar 4.15 Hasil benchmark pengujian skenario ketiga terhadap LXC 100

Dari gambar 4.14 dan 4.15 dapat dilihat hasil dari benchmark yang sudah dilakukan terhadap service yang ada pada LXC 100 yaitu apache dalam skenario pengujian kedua dan ketiga, yang perlu diperhatikan dari hasil benchmark adalah nilai dari time taken for tests, complete requests, failed requests, request per second, time per request dan transfer rate. Nilai – nilai dari benchmark tersebut merupakan nilai yang menunjukkan kinerja service apache yang ada pada LXC 100 dengan memakai

Universitas Sumatera Utara 55

parameter yang sama pada setiap skenario yaitu melakukan 100 request secara bersamaan dengan jumlah request sebanyak 30000 request yang diberikan kepada sebuah halaman web yang ada pada LXC 100. Pada skenario pengujian keempat, LXC 100 dan 101 akan diberi beban dan LXC 102 berada dalam kondisi idle, kemudian LXC 100 dan 101 akan diberikan benchmark. Pada skenario pengujian kelima, dengan menerapkan pengalokasian resource, LXC 100 dan 101 akan diberi beban dan diberi benchmark dengan kondisi LXC 102 dalam keadaan idle. Hasil pengujian skenario keempat dan kelima dapat dilihat pada gambar 4.16 dan 4.17.

Gambar 4.16 Hasil resource pengujian skenario keempat

Universitas Sumatera Utara 56

Gambar 4.17 Hasil resource pengujian skenario kelima

Pada gambar 4.16 dan 4.17 yang merupakan pengujian skenario keempat dan kelima dapat dilihat bahwa pada skenario keempat, tidak terjadi perubahaan resource baik itu pada LXC 100, 101 maupun 102. Sebaliknya, pada skenario kelima, dengan menerapkan pengalokasian resource dihasilkan resource yang berbeda dari keadaan awal dimana LXC 102 memberikan resource kepada LXC 100 dan LXC 101 untuk meringankan penggunaan resource pada kedua container tersebut. pada LXC 101 dapat dilihat bahwa penggunaan CPU tidak berubah hal ini terjadi karena LXC 102 hanya mampu menyumbangkan satu buah core CPU kepada LXC 100 yang penggunaan CPU pada container tersebut lebih tinggi daripada LXC 101. Pada

Universitas Sumatera Utara 57

skenario keempat dan kelima juga diberikan benchmark masing – masing kepada LXC 100 dan 101. Gambar 4.18 dan 4.19 merupakan hasil dari benchmark dalam skenario pengujian keempat dan kelima terhadap service yang bekerja pada LXC 100 yaitu apache.

root@ubuntu1:~# ab -n 30000 -c 100 192.168.50.2/clinic/index.php This is ApacheBench, Version 2.3 <$Revision: 1757674 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 192.168.50.2 (be patient) Completed 3000 requests Completed 6000 requests Completed 9000 requests Completed 12000 requests Completed 15000 requests Completed 18000 requests Completed 21000 requests Completed 24000 requests Completed 27000 requests Completed 30000 requests Finished 30000 requests

Server Software: Apache/2.4.25 Server Hostname: 192.168.50.2 Server Port: 80

Document Path: /clinic/index.php Document Length: 7693 bytes

Concurrency Level: 100 Time taken for tests: 201.511 seconds Complete requests: 30000 Failed requests: 0 Total transferred: 242250000 bytes HTML transferred: 230790000 bytes Requests per second: 148.88 [#/sec] (mean) Time per request: 671.702 [ms] (mean) Time per request: 6.717 [ms] (mean, across all concurrent requests) Transfer rate: 1173.99 [Kbytes/sec] received

Universitas Sumatera Utara 58

Connection Times (ms) min mean[+/-sd] median max Connect: 0 1 5.8 0 137 Processing: 4 670 682.1 477 6514 Waiting: 4 670 682.2 476 6514 Total: 4 671 681.6 477 6514

Percentage of the requests served within a certain time (ms) 50% 477 66% 616 75% 720 80% 805 90% 1157 95% 1952 98% 3139 99% 4032 100% 6514 (longest request) root@ubuntu1:~#

Gambar 4. 18 Hasil benchmark pengujian skenario keempat terhadap LXC 100

root@ubuntu1:~# ab -n 30000 -c 100 192.168.50.2/clinic/index.php This is ApacheBench, Version 2.3 <$Revision: 1757674 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 192.168.50.2 (be patient) Completed 3000 requests Completed 6000 requests Completed 9000 requests Completed 12000 requests Completed 15000 requests Completed 18000 requests Completed 21000 requests Completed 24000 requests Completed 27000 requests Completed 30000 requests Finished 30000 requests

Server Software: Apache/2.4.25 Server Hostname: 192.168.50.2 Server Port: 80

Universitas Sumatera Utara 59

Document Path: /clinic/index.php Document Length: 7693 bytes

Concurrency Level: 100 Time taken for tests: 189.471 seconds Complete requests: 30000 Failed requests: 0 Total transferred: 242250000 bytes HTML transferred: 230790000 bytes Requests per second: 158.34 [#/sec] (mean) Time per request: 631.570 [ms] (mean) Time per request: 6.316 [ms] (mean, across all concurrent requests) Transfer rate: 1248.59 [Kbytes/sec] received

Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 1.2 0 54 Processing: 3 631 669.0 418 6463 Waiting: 2 631 669.0 418 6463 Total: 3 631 668.9 418 6463

Percentage of the requests served within a certain time (ms) 50% 418 66% 586 75% 711 80% 812 90% 1212 95% 1687 98% 3011 99% 4188 100% 6463 (longest request) root@ubuntu1:~#

Gambar 4.19 Hasil benchmark pengujian skenario kelima terhadap LXC 100

Pada gambar 4.18 dan 4.19 terdapat hasil benchmark terhadap service yang ada pada LXC 100 dalam skenario pengujian keempat dan kelima. Nilai yang perlu diperhatikan untuk melihat kinerja service apache pada LXC 100 dari hasil benchmark adalah nilai dari time taken for tests, complete requests, failed requests, request per second, time per request dan transfer rate.

Universitas Sumatera Utara 60

Gambar 4.20 dan 4.21 merupakan hasil benchmark dalam skenario pengujian keempat dan kelima terhadap service yang bekerja pada LXC 101 yaitu mysql. root@debian:~# sysbench --test=oltp --oltp-table-size=1000000 --mysql-db=test --mysql-user=root --mysql-password=hansman --max-time=120 --oltp-read-only=on --max-requests=0 --num-threads=4 run sysbench 0.4.12: multi-threaded system evaluation benchmark No DB drivers specified, using mysql Running the test with following options: Number of threads: 4

Doing OLTP test. Running mixed OLTP test Doing read-only test Using Special distribution (12 iterations, 1 pct of values are returned in 75 pct cases) Using "BEGIN" for starting transactions Using auto_inc on the id column Threads started! Time limit exceeded, exiting... (last message repeated 3 times) Done. OLTP test statistics: queries performed: read: 601762 write: 0 other: 85966 total: 687728 transactions: 42983 (358.18 per sec.) deadlocks: 0 (0.00 per sec.) read/write requests: 601762 (5014.47 per sec.) other operations: 85966 (716.35 per sec.)

Test execution summary: total time: 120.0052s total number of events: 42983 total time taken by event execution: 479.8277 per-request statistics: min: 0.72ms avg: 11.16ms max: 1183.88ms approx. 95 percentile: 23.49ms

Universitas Sumatera Utara 61

Threads fairness: events (avg/stddev): 10745.7500/143.16 execution time (avg/stddev): 119.9569/0.00 root@debian:~#

Gambar 4.20 Hasil benchmark pengujian skenario keempat terhadap LXC 101 root@debian:~# sysbench --test=oltp --oltp-table-size=1000000 --mysql-db=test --mysql-user=root --mysql-password=hansman --max-time=120 --oltp-read-only=on --max-requests=0 --num-threads=4 run sysbench 0.4.12: multi-threaded system evaluation benchmark No DB drivers specified, using mysql Running the test with following options: Number of threads: 4

Doing OLTP test. Running mixed OLTP test Doing read-only test Using Special distribution (12 iterations, 1 pct of values are returned in 75 pct cases) Using "BEGIN" for starting transactions Using auto_inc on the id column Threads started! Time limit exceeded, exiting... (last message repeated 3 times) Done.

OLTP test statistics: queries performed: read: 805518 write: 0 other: 115074 total: 920592 transactions: 57537 (479.44 per sec.) deadlocks: 0 (0.00 per sec.) read/write requests: 805518 (6712.16 per sec.) other operations: 115074 (958.88 per sec.)

Test execution summary: total time: 120.0088s total number of events: 57537 total time taken by event execution: 479.8204

Universitas Sumatera Utara 62

per-request statistics: min: 0.66ms avg: 8.34ms max: 1206.10ms approx. 95 percentile: 18.12ms

Threads fairness: events (avg/stddev): 14384.2500/200.00 execution time (avg/stddev): 119.9551/0.00 root@debian:~#

Gambar 4.21 Hasil benchmark pengujian skenario kelima terhadap LXC 101

Pada gambar 4.20 dan 4.21 adalah hasil benchmark terhadap service yang ada pada LXC 101 yaitu mysql. Pada benchmark yang diberikan dalam skenario pengujian keempat dan kelima, sysbench memberikan sebuah simulasi terhadap database yang bernama test yang ada pada LXC 101 dengan jumlah tabel sebanyak 1000000 dengan batas waktu pengujian selama 120 detik dan jumlah thread yang digunakan sebanyak 4 buah. Nilai yang perlu diperhatikan dari hasil benchmark tersebut adalah transactions. Gambar 4.22 dan 4.23 merupakan hasil benchmark dalam skenario pengujian keempat dan kelima terhadap service yang bekerja pada LXC 102 yaitu FTP.

Gambar 4.22 Hasil benchmark pengujian skenario keempat terhadap LXC 102

Universitas Sumatera Utara 63

Gambar 4.23 Hasil benchmark pengujian skenario kelima terhadap LXC 102

Dari Gambar 4.22 dan 4.23 yang merupakan hasil benchmark terhadap service FTP yang ada pada LXC 102 pada skenario keempat dan kelima. Apache JMeter memberikan sebuah load test terhadap service FTP pada LXC 102 dengan menggunakan metode unggah dan unduh terhadap sebuah file yang ada pada FTP server dengan menggunakan 15 pengguna dan melakukan pengulangan sebanyak 2 kali. Adapun nilai yang dapat dilihat dari benchmark pada LXC 102 adalah nilai average, throughput.

4.4. Analisis Hasil Pengujian

Dari pengujian pengalokasian resource yang sudah dilakukan, seperti yang dapat dilihat pada tabel 4.3 pada skenario pengujian pertama dapat dilihat bahwa tidak adanya beban yang diberikan kepada masing – masing container atau dengan kata lain setiap container berada dalam kondisi idle, sehingga resource yang ada pada masing – masing container tidak berubah. Pada skenario pengujian kedua dan ketiga terdapat perbedaan resource yang dimiliki oleh masing – masing container antara skenario pengujian kedua dan ketiga. Hal itu disebabkan oleh pengalokasian resource yang sudah diterapkan pada skenario pengujian ketiga yang mengakibatkan LXC 100 mendapat resource tambahan dari LXC 101 dan LXC 102. Selain mengalami perubahan resource, nilai benchmark yang dihasilkan pada saat skenario pengujian ketiga memiliki nilai yang berbeda dari hasil skenario pengujian kedua. Hasil benchmark pada skenario kedua dan ketiga dapat dilihat pada tabel 4.4 dan gambar 4.22.

Universitas Sumatera Utara 64

Tabel 4.3 Resource yang dimiliki container pada skenario 1,2 dan 3 Skenario pertama Skenario kedua Skenario ketiga LXC ID LXC ID LXC ID 100 101 102 100 101 102 100 101 102 Perbandingan penggunaan 0.0 0.0 0.0 81.25 0.0 0.0 39.98 0.0 0.0 CPU (dalam %) Perbandingan 1 1 2 1 1 2 2 1 1 jumlah core Perbandingan penggunaan 13.14 5.06 0.38 77.09 5.06 0.38 29.43 9.89 0.84 memory (dalam %) Perbandingan jumlah 1 1 2 1 1 2 2.62 0.536 1.05 memory (dalam GB)

Pada skenario pengujian keempat dan kelima, resource yang dimiliki oleh masing – masing container memiliki perbedaan antara skenario keempat dan kelima. Pada skenario kelima dengan penerapan pengalokasian resource, LXC 102 akan memberikan resource kepada LXC 100 dan 101, core CPU diberikan kepada salah satu diantara LXC 100 dan 101 yang memiliki penggunaan CPU yang lebih besar. Sementara untuk memory, LXC 100 dan 101 mendapat jumlah yang sama besar. Penerapan pengalokasian resource juga mempengaruhi nilai benchmark yang dihasilkan pada skenario pengujian keempat dan kelima terhadap LXC 100 dan 101. Perbandingan resource pada skenario pengujian keempat dan kelimat dapat dilihat pada tabel 4.4. Hasil benchmark terhadap LXC 100 , LXC 101 dan LXC 102 dapat dilihat pada tabel 4.5, 4.6 dan 4.7 serta pada gambar 4.24, 4.25 dan 4.26.

Universitas Sumatera Utara 65

Tabel 4.4 Resource yang dimiliki container pada skenario 4 dan 5. Skenario keempat Skenario keempat LXC ID LXC ID 100 101 102 100 101 102 Perbandingan penggunaan 80.52 79.79 0.0 39.91 81.71 0.0 CPU (dalam %) Perbandingan 1 1 2 2 1 1 jumlah core Perbandingan penggunaan 77.03 78.45 0.38 49.04 49.92 0.73 memory (dalam %) Perbandingan jumlah 1 1 2 1.57 1.57 1.05 memory (dalam GB)

Tabel 4.5 Hasil benchmark terhadap LXC 100 Skenario Skenario Skenario Skenario

kedua ketiga keempat kelima Time taken for tests 153.740 147.419 201.511 189.471 (dalam second) Requests per second 195.13 203.50 148.88 158.34 Rata – rata time per request (dalam 5.125 4.914 6.717 6.316 milisecond) Transfer rate (dalam 1538.78 1604.76 1173.99 1248.59 Kb/sec)

Universitas Sumatera Utara 66

Time taken for tests Requests per second (dalam second) 250 250 200 200 150 Time taken Requests per 150 for tests second. (dalam 100 Skenario 3 100 second) dan 5 alokasi skenario 3 resource 50 dan 5 alokasi 50 diterapkan resource diterapkan 0 0

Rata – rata time per Transfer rate (dalam request (dalam Kb/sec) milisecond) 1800 1600 8 1400 7 1200 6 Rata – rata Transfer rate 5 time per 1000 (dalam 4 request 800 Kb/sec) 3 (dalam 600 skenario 3 milisecond) 2 400 dan 5 alokasi skenario 3 resource 1 200 dan 5 alokasi diterapkan 0 resource 0 diterapkan

Gambar 4.24 Hasil benchmark terhadap LXC 100 dengan service apache dalam bentuk diagram.

Dari tabel 4.4 dapat dilihat bahwa terdapat perubahan nilai hasil benchmark terjadi antara skenario kedua dan ketiga. Waktu yang dipergunakan untuk pengujian benchmark pada skenario kedua berkurang 6.321 detik pada skenario ketiga dengan pengalokasian resource yang sudah diterapkan. Kecepatan transfer yang diukur pada skenario ketiga bertambah sebesar 65.98 Kb/sec dari skenario kedua. Dari hasil

Universitas Sumatera Utara 67

benchmark tersebut dapat diambil kesimpulan bahwa pada skenario ketiga dengan penerapan pengalokasian resource, kinerja service apache yang ada pada LXC 100 menjadi lebih baik. Pada skenario pengujian keempat dan kelima juga terdapat perubahan hasil benchmark terhadap LXC 100. Waktu yang dipergunakan untuk pengujian benchmark pada skenario kelima berkurang 12.04 detik dari skenario keempat dengan pengalokasian resource yang sudah diterapkan. Kecepatan transfer yang diukur pada skenario kelima bertambah sebesar 74.6 Kb/sec dari skenario keempat. Dari hasil benchmark yang didapat dari tabel 4.5 dapat disimpulkan bahwa penerapan pengalokasian resource dapat membuat kinerja service apache pada LXC 100 menjadi lebih baik.

Tabel 4.6 Hasil benchmark terhadap LXC 101 Skenario keempat Skenario kelima Jumlah event yang 42983 57537 dilakukan Event per second 358.18 479.44

Jumlah event yang Event per second dilakukan. 600 70000 500 60000

50000 400 Jumlah event Event per second. 40000 yang 300 dilakukan. Skenario 5 30000 Skenario 5 alokasi 200 resource 20000 alokasi resource diterapkan 10000 diterapkan 100 0 Skenario Skenario 0 4 5 Skenario 4 Skenario 5

Gambar 4.25 Hasil benchmark terhadap LXC 101 dengan service mysql dalam bentuk diagram.

Universitas Sumatera Utara 68

Dari tabel 4.6 dapat dilihat bahwa pada skenario pengujian keempat dan kelima terdapat perubahan hasil benchmark pada LXC 101 yang memiliki service mysql, perubahan hasil benchmark terdapat pada jumlah event yang dilakukan pada skenario kelima yang bertambah sebesar 14554 event dari skenario keempat. Event yang dapat dilakukan per detik pada skenario kelima juga bertambah sebesar 121.26 event/detik dari skenario keempat. Dari hasil benchmark yang didapat dari tabel 4.6 dapat disimpulkan bahwa penerapan pengalokasian resource dapat membuat kinerja service mysql pada LXC 101 menjadi lebih baik.

Tabel 4.7 Hasil benchmark terhadap LXC 102 Skenario keempat Skenario kelima

FTP Upload FTP Download FTP Upload FTP Download Average 36211 23571 27018 29975 Throughput 13.0 13.4 15.2 14.6 per menit

Universitas Sumatera Utara 69

FTP Upload Average FTP Upload 40000 Throughput per 35000 menit 30000 15.5 25000 FTP Upload 15 20000 Average. 14.5 FTP Upload Skenario 5 14 Throughput 15000 Alokasi 13.5 per menit. 10000 Resource Skenario 5 13 diterapkan alokasi 5000 12.5 resource 0 12 diterapkan Skenario Skenario 11.5 4 5 Skenario 4 Skenario 5

FTP Download FTP Download Average Throughput per 35000 menit 30000 15 25000 FTP 14.5 FTP Download 20000 Download Average. 14 Throughput 15000 Skenario 5 per menit. alokasi 13.5 10000 Skenario 5 resource alokasi 5000 diterapkan 13 resource diterapkan 0 12.5 Skenario 4Skenario 5 Skenario 4 Skenario 5

Gambar 4.26 Hasil benchmark terhadap LXC 102 dengan service FTP dalam bentuk diagram.

Dari tabel 4.7 dapat dilihat perubahan nilai benchmark yang terjadi pada LXC 102 pada skenario keempat dan kelima. Nilai average pada skenario kelima berkurang sebesar 1394 sementara throughput bertambah sebesar 2 per menit. Kinerja service FTP sedikit menurun disebabkan karena LXC 102 memberikan resource yang dimilikinya kepada LXC 100 dan LXC 101 pada skenario kelima. Namun perubahan nilai benchmark yang terjadi pada LXC 102 tidak terlalu signifikan sehingga dapat diambil kesimpulan bahwa alokasi resource membuat kinerja service ftp pada LXC 102 sedikit menurun namun kinerja service masih dalam kategori baik.

Universitas Sumatera Utara BAB 5

KESIMPULAN DAN SARAN

5.1. Kesimpulan

Berdasarkan hasil penelitian pengalokasian resource virtualisasi server pada proxmox virtual environment, dapat ditarik beberapa kesimpulan antara lain sebagai berikut: 1. Penerapan script pengalokasian resource pada hypervisor proxmox virtual environment dapat berjalan dengan baik pada virtualisasi server dengan menggunakan linux container. 2. Perubahan resource dapat mempengaruhi penggunaan resource pada container. 3. Pengalokasian resource mampu memaksimalkan kinerja dari service yang ada pada container dengan konfigurasi default yang dapat dilihat dari perubahan hasil benchmark dari service yang ada pada container.

5.2. Saran

Berikut ini beberapa saran yang dapat menjadi bahan pertimbangan dalam pengembangan penelitian selanjutnya mengenai pengalokasian resource virtualisasi server: 1. Perlu dilakukan penelitian lebih lanjut terhadap alokasi resource pada lingkungan cloud pada jenis virtualisasi yang berbeda. 2. Pengembangan penelitian yang dapat meningkatkan tidak hanya kinerja dari service melainkan kestabilan dan keamanan dari server agar Quality of Service yang diberikan dapat lebih ditingkatkan.

Universitas Sumatera Utara 71

DAFTAR PUSTAKA

Ahmed, W. 2016. Mastering Proxmox. 2nd Edition. Packt Publishing Ltd:Birmingham. Anuradha, V. P. & Sumathi, D. 2014. A survey on resource allocation strategies in cloud computing. International Conference on Information Communication and Embedded Systems (ICICES), pp. 1-7. Apache Software Foundation. Ab-apache http server benchmarking tool. (Online) http://httpd.apache.org/docs/2.4/programs/ab.html ( 9 Mei 2017). Arfriandi, A. 2012. Perancangan, Implementasi, dan Analisis Kinerja Virtualisasi Server Menggunakan Proxmox, Vmware Esx, Dan Openstack. Jurnal Teknologi 5(2): 182-191. Arlita, N. 2014. Optimasi Penjadwalan Resource Pada Cloud Computing Menggunakan Model Integer Programming. Skripsi. Universitas Sumatera Utara. Arpaci-Dusseau, R. H. & Arpaci-Dusseau, A. C. 2014. Operating systems: Three easy pieces. Arpaci-Dusseau Books: Wisconsin. Cheng, S. M. 2014. Proxmox High Availability. Packt Publishing Ltd:Birmingham. Dua, R., Raja, A. R., & Kakadia, D. 2014. Virtualization vs containerization to support paas. IEEE International Conference on Cloud Engineering (pp. 610- 614). Dyke, J. & Shaw, S. 2008. Pro Oracle Database 10g RAC on Linux: Installation, Administration, and Performance.Apress:Berkeley. Goldman, R. 2016. Learning Proxmox VE. Packt Publishing Ltd:Birmingham Hizriadi, A. 2011. Optimalisasi Kinerja Dual-Core Prosesor Pada Server Melalui Pengalokasian dan Pengisolasian Proses – Proses Aplikasi Dengan . Skripsi. Universitas Sumatera Utara. tej Koganti, K., Patnala, E., Narasingu, S. S. & Chaitanya, J. N. 2013. Virtual Technology in Cloud Computing Environment. International Journal of Emerging Technology and Advanced Engineering 3(3):771-773. Malhotra, L., Agarwal, D. & Jaiswal, A. 2014. Virtualization in Cloud Computing. International Journal of Computer Science and Mobile Computing 3(8):745– 749.

Universitas Sumatera Utara 72

Marston, S. 2011. Cloud computing – the bisnis perspective. Proceedings of the 44th , Hawaii Inter- national Conference on System Sciences, pp. 32-40. Mell, P. & Grance, T. 2011. The NIST Definition about Cloud Computing. (Online) http://csrc.nist.gov/groups/SNS/cloud-computing/index.html ( 22 April 2017). Nazir, M., Tiwari, P., Tiwari S.D. & Mishra, R. G. 2015. Cloud computing: An overview. Book Chapter of Cloud Computing: Reviews, Surveys, Tools, Techniques and Application – An Open-Access eBook by HTCL Open. (Online) http://ebooks.hctl.org/cloud-computing/chapter-1.pdf ( 10 November 2017 ). Qian, L., Luo, Z., Du, Y., & Guo, L. 2009. Cloud computing: An overview. IEEE International Conference on Cloud Computing ,pp. 626-631. Rizki, R., Rakhmatsyah, A., & Nugroho, M. A. 2016. Performance analysis of container-based hadoop cluster: OpenVZ and LXC. 4th International Conference on Information and Communication Technology (ICoICT),pp. 1-4. Silberschatz, A. & Galvin, P. 1994. Operating system concepts. Addison-wesley: Boston. Sudeepa, R., & Guruprasad, H. S. 2014. Resource allocation in cloud computing. International Journal of Modern Communication Technologies & Research 2(4):19-21. Suryono, T. & Afif, M., F. 2012. Pembuatan prototype virtual server menggunakan proxmox VE untuk optimalisasi resource hardware di NOC FKIP UNS. Indonesian Journal on Networking and Security (IJNS) : 56-60. Wei, G., Vasilakos, A. V., Zheng, Y., & Xiong, N. 2010. A game-theoretic method of fair resource allocation for cloud computing services. The journal of supercomputing, 54(2):252-269. Wikipedia. Apache HTTP Server (Online) https://id.wikipedia.org/wiki/Apache_HTTP_Server ( 20 Desember 2017). Wikipedia. MySQL (Online) https://id.wikipedia.org/wiki/MySQL ( 20 Desember 2017). Wikipedia. vsftpd (Online) https://en.wikipedia.org/wiki/Vsftpd ( 20 Desember 2017).

Universitas Sumatera Utara 73

Wikipedia. Benchmark (Online) https://id.wikipedia.org/wiki/Benchmark ( 20 Desember 2017). Wikipedia. Cron (Online) https://en.wikipedia.org/wiki/Cron#cite_note-1 ( 20 Desember 2017). Xavier, M. G., Neves, M. V., Rossi, F. D., Ferreto, T. C., Lange, T., & De Rose, C. A. 2013. Performance evaluation of container-based virtualization for high performance computing environments. Euromicro International Conference on Parallel, Distributed and Network-Based Processing (PDP. pp. 233-240. Xiao, Z., Song, W., & Chen, Q. 2013. Dynamic resource allocation using virtual machines for cloud computing environment. IEEE transactions on parallel and distributed systems 24(6):1107-1117. Zulfa, M. I., Fadli, A., & Ramadhani, Y. 2017. Model Infrastruktur dan Manajemen Platform Server Berbasis Cloud Computing. JURNAL INFOTEL 9(4):394-400.

Universitas Sumatera Utara