LOAD BALANCER PADA LINUX VIRTUAL SERVER

Transkripsi

1 HALAMAN JUDUL ANALISIS UNJUK KERJA ALGORITMA PENJADWALAN LOAD BALANCER PADA LINUX VIRTUAL SERVER SKRIPSI Diajukan Untuk Memenuhi Salah Satu Syarat Memperoleh Gelar Sarjana Komputer Program Studi Teknik Informatika Disusun Oleh : Yoseph Dian Sahadewa PROGRAM STUDI TEKNIK INFORMATIKA JURUSAN TEKNIK INFORMATIKA FAKULTAS SAINS DAN TEKNOLOGI UNIVERSITAS SANATA DHARMA YOGYAKARTA 2016 i

2 LOAD BALANCER SCHEDULING ALGORITHM PERFORMANCE ANALYSIS ON LINUX VIRTUAL SERVER THESIS Presented as Partial Fulfillment of the Requirements to Obtain Sarjana Komputer Degree in Informatic Engineering Department Created By : Yoseph Dian Sahadewa HALAMAN JUDUL (INGGRIS) INFORMATICS ENGINEERING STUDY PROGRAM INFORMATICS ENGINEERING DEPARTMENT FACULTY OF SCIENCE AND TECHNOLOGY SANATA DHARMA UNIVERSITY YOGYAKARTA 2016 ii

3 HALAMAN PERSETUJUAN iii

4 HALAMAN PENGESAHAN SKRIPSI ANALISIS UNJUK KERJA ALGORITMA PENJADWALAN LOAD BALANCER PADA LINUX VIRTUAL SERVER Yang dipersiapkan dan Disusun Oleh : Yoseph Dian Sahadewa Telah dipertahankan di depan Panitia Penguji Pada tanggal 21 Juli 2016 Dan dinyatakan memenuhi syarat Susunan Panita Penguji Tanda Tangan Ketua : Sri Hartati Wijono, M.Kom.... Sekretaris : Puspaningtyas Sanjoyo Adi, S.T., M.T.... Anggota : Iwan Binanto, S.Si., M.Cs. Yogyakarta, Juli 2016 Fakultas Sains dan Teknologi Universitas Sanata Dharma Dekan, (Sudi Mungkasi, S.Si., M.Math.SC., Ph.D.) iv

5 PERNYATAAN KEASLIAN KARYA Saya menyatakan dengan sungguh bahwa skripsi yang saya tulis ini tidak memuat karya orang lain, kecuali yang telah disebutkan dalam kutipan dan daftar pustaka, sebagaimana layaknya karya ilmiah. Yogyakarta, 28 Juli 2016 Penulis Yoseph Dian Sahadewa v

6 HALAMAN MOTTO ~ Kesuksesan berasal dari 99% usaha dan 1% doa,~ ~ Perbanyak usahamu, lengkapi dengan doa selalu.~ vi

7 LEMBAR PERNYATAAN PERSETUJUAN PUBLIKASI KARYA ILMIAH UNTUK KEPENTINGAN AKADEMIS Yang bertanda tangan di bawah ini, saya mahasiswa Universitas Sanata Dharma : Nama : Yoseph Dian Sahadewa Nomor Mahasiswa : Demi pengembangan ilmu pengetahuan, saya memberikan kepada Perpustakaan Universitas Sanata Dharma karya ilmiah saya yang berjudul : ANALISIS UNJUK KERJA ALGORITMA PENJADWALAN LOAD BALANCER PADA LINUX VIRTUAL SERVER beserta perangkat yang diperlukan (bila ada). Dengan demikian saya memberikan kepada Perpustakaan Universitas Sanata Dharma hak untuk menyimpan, mengalihkan dalam bentuk media lain, mengelolanya dalam bentuk pangkalan data, mendistribusikan secara terbatas, dan mempublikasikannya di Internet atau media lain untuk kepentingan akademis tanpa perlu meminta ijin dari saya maupun memberikan royalti kepada saya selama tetap mencantumkan nama saya sebagai penulis. Demikian pernyataan ini yang saya buat dengan sebenarnya. Dibuat di Yogyakarta Pada tanggal : 28 Juli 2014 Yang menyatakan ( Yoseph Dian Sahadewa ) vii

8 ABSTRAK Sebuah web server bekerja dengan cara menerima request dari user untuk kemudian diproses dan dikembalikan kepada user berupa konten berisikan halaman website. Semakin bertambahnya user yang dapat mengakses website membuat sistem server tunggal mengalami beban kerja yang besar. Cluster server menyediakan solusi untuk mengatasi kegagalan yang dialami oleh sistem server tunggal dengan menyediakan kumpulan server berkonten sama untuk saling berbagi beban kerja. Agar dapat berjalan optimal, diperlukan software khusus untuk memanajemen semua request yang akan dikirimkan kepada server. Linux Virtual Server bekerja dengan cara membagi setiap request yang masuk berdasarkan algoritma yang saat itu sedang dipakai. Algoritma tersebut memiliki keunggulan dan kelemahan sendiri-sendiri dalam menangani setiap request dari user dengan jumlah user yang berbeda-beda pula. Untuk dapat menentukan algoritma mana yang terbaik dalam setiap perubahan user, setiap algoritma akan diuji dengan perubahan jumlah user serta kondisi lingkungan privat, dimana interferensi dari internet tidak ada. Kategori terbaik ini dilihat berdasarkan waktu respon tercepat yang didapatkan oleh setiap algoritma. Dengan demikian, hasil pengujian ini diharapkan dapat digunakan untuk mengetahui algoritma yang terbaik pada tiap beban user yang berbeda. Kata kunci : web server, load balancing, waktu respon. viii

9 ABSTRACT A web server works by receiving a request from a user to be processed and returned to the user in the form of web pages containing content. The increasing number of users who can access the website create a single server system experienced a huge workload. Cluster server provides a solution to address the failures experienced by a single server system to provide the same content server clusters to share the workload. In order to run optimally, it needs special software to manage all the requests that will be sent to the server. Linux Virtual Server works by dividing each incoming request based on the algorithm while it is being used. The algorithm has advantages and disadvantages of self-own in dealing with any request from the user with the different number of users. To be able to determine which is the best algorithm to each user changes, each algorithm will be tested using different number of user as well as in private environmental conditions, where no interference from the internet. Best category is seen by the fastest response time obtained by each algorithm. Thus, the results of this testing are expected to be used to determine the best algorithm for each different user load. Keyword : web server, load balancing, response time. ix

10 KATA PENGANTAR Puji dan syukur penulis ucapkan kepada Tuhan Yang Maha Esa, karena atas berkat dan rahmat-nya penulis dapat menyelesaikan tugas akhir yang berjudul ANALISIS UNJUK KERJA ALGORITMA PENJADWALAN LOAD BALANCER PADA LINUX VIRTUAL SERVER. Tugas akhir ini ditulis sebagai salah satu syarat memperoleh gelar Sarjana Komputer program studi Teknik Informatika, Fakultas Sains dan Teknologi Universitas Sanata Dharma. Penulis mengucapkan banyak terima kasih kepada semua pihak yang turut memberikan motivasi, semangat dan bantuan dalam bentuk apapun sehingga tugas akhir ini dapat terselesaikan dengan baik : 1. Tuhan Yang Maha Esa yang selalu memberikan petunjuk dan kekuatan dalam perjalanan penulisan skripsi ini. 2. Bapak Sudi Mungkasi, Ph.D., selaku Dekan Fakultas Sains dan Teknologi. 3. Ibu Dr. Anastasia Rita Widiarti, selaku Ketua Program Studi Teknik Informatika. 4. Ibu Sri Hartati Wijono, M.Kom. dan Bapak Puspaningtyas Sanjoyo Adi, S.T., M.T. selaku dosen penguji yang memberikan kritik dan saran terhadap tugas akhir ini. 5. Bapak Iwan Binanto, S.Si., M.Cs. selaku dosen pembimbing akademik sekaligus dosen pembimbing tugas akhir penulis yang tiada henti selalu membantu dan memberikan masukan dalam penulisan skripsi. 6. Bapak Benediktus Zainal Abidin serta Ibu Yohanna Ratna Susanti yang selalu mengingatkan dan memberi semangat, serta tiada henti memberikan dukungan moriil dan materiil kepada penulis. Matur nuwun Papi-kun, maturu nuwun Mami-kun. x

11 7. Mas Adri, Mbak Maria, Mas Hani, Mbak Vita, dan Ayoe yang selalu memberi semangat dan mendukung penulis. 8. Para anggota Pejuang Skripsi Lab. Utara Jaringan Komputer, yang sudah berjuang bersama dengan penulis dan membantu dalam setiap kesulitan yang dihadapi selama proses pengerjaan skripsi. 9. Personil Ndlogoks ( Pidi, Doyok, Momoo, Simbah, Yuting, Andus, Romo Kiki, Paus Jeanot, Yemyut, Jablay ) yang selalu ada baik dalam suka maupun duka, baik dalam susah maupun senang. Kalian warbyasah!! 10. Pihak-pihak lain yang turut membantu penulis dalam menyelesaikan tugas akhir ini, yang tidak dapat disebutkan satu persatu. Penulis menyadari bahwa tugas akhir ini masih memiliki banyak kekurangan. Oleh karena itu diperlukan saran dan kritik yang penulis harapkan dalam memperbaiki tugas akhir ini. Akhir kata, penulis berharap semoga tugas akhir ini bisa memberikan manfaat bagi semua pihak di masa yang akan datang. Terima Kasih. Yogyakarta, 28 Juli 2016 Yoseph Dian Sahadewa xi

12 DAFTAR ISI HALAMAN JUDUL... i HALAMAN JUDUL (INGGRIS)... ii HALAMAN PERSETUJUAN... iii HALAMAN PENGESAHAN... iv PERNYATAAN KEASLIAN KARYA... v LEMBAR PERNYATAAN PERSETUJUAN... vii ABSTRAK... viii ABSTRACT... ix KATA PENGANTAR... x DAFTAR ISI... xii DAFTAR GAMBAR... xiv DAFTAR TABEL... xv BAB I... 1 PENDAHULUAN Latar Belakang Rumusan Masalah Tujuan Penelitian Batasan Masalah Metodologi Penelitian Sistematika Penulisan... 5 BAB II... 6 LANDASAN TEORI Server Pengertian Server Pengertian Web Server Clustering Pengertian Clustering Linux Virtual Server (LVS) Pengertian LVS xii

13 Arsitektur Sistem Topologi pada LVS Algoritma Penjadwalan pada LVS Webserver Stress Tool Pengertian Webserver Stress Tool Cara Kerja Webserver Output Hasil Simulasi BAB III PERANCANGAN Konfigurasi Jaringan Konfigurasi Hardware Spesifikasi Komputer Sistem Operasi Skenario Pengujian BAB IV IMPLEMENTASI DAN ANALISA Instalasi Web dan Virtual Server Konfigurasi Web Server Konfigurasi Virtual Server Hasil Pengujian dan Analisa BAB V KESIMPULAN Kesimpulan Saran DAFTAR PUSTAKA LAMPIRAN xiii

14 DAFTAR GAMBAR Gambar 2.1 Server Clustering Gambar 2.2 Arsitektur Umum Linux Virtual Server Gambar 2.3 Tabel perbandingan 3 topologi LVS Gambar 2.4 Topologi LVS NAT Gambar 2.5 LVS Direct Routing Gambar 2.6 LVS Tunneling Gambar 3.1 Konfigurasi 2 Server Gambar 3.2 Setting pengujian pada Webserver Gambar 3.3 Contoh hasil uji 100 user Gambar 3.4 Contoh hasil uji 200 user Gambar 3.5 Contoh hasil uji 500 user Gambar 3.6 Contoh raw data yang sudah dipindah ke Excel Gambar 4.1 Halaman utama web dalam real server Gambar 4.2 Waktu respon beban user Gambar 4.3 Waktu respon beban user Gambar 4.4 Waktu respon beban user xiv

15 DAFTAR TABEL Tabel 3.1 Distribusi IP address yang digunakan Tabel 3.2 Spesifikasi komputer client & server xv

16 BAB I PENDAHULUAN 1.1. Latar Belakang Web server bekerja dengan menerima request HTTP dari client dan membalasnya dengan menyediakan konten data berupa halaman website. Banyaknya jumlah request yang bisa ditangani sebuah server tergantung pada spesifikasi hardware server tersebut. Dengan semakin bertambahnya jumlah user yang mengakses internet, maka satu server saja jelas tidak cukup untuk menangani semua request. Ada beberapa metode untuk mengatasinya, salah satunya dengan meng-upgrade hardware server menjadi lebih baik. Namun metode ini memerlukan biaya yang besar, dan setiap hardware memiliki limit kapasitas yang bisa di-upgrade[1]. Alternatif lain adalah dengan menambah jumlah web server yang saling terkoneksi secara paralel, atau disebut clustering. Clustering menggunakan beberapa server dengan isi konten web yang persis sama untuk saling berbagi beban koneksi. Dengan metode ini, server menjadi lebih reliable, karena jika terjadi kegagalan fungsi pada salah satu server tidak akan mengganggu aktivitas website yang sedang berjalan, mengingat setiap server memiliki konten yang persis sama[2]. Agar clustering dapat berjalan optimal, diperlukan sebuah software untuk memanajemen kinerja dari kumpulan server tersebut. 1

17 2 Linux Virtual Server adalah salah satu software clustering yang memiliki skalabilitas tinggi. Berjalan pada platform Linux, Linux Virtual Server dapat menangani web server dari berbagai macam sistem operasi [3]. Linux Virtual Server membuat sebuah layanan paralel antar server dan mengarahkan setiap request dari client menuju server yang berbeda-beda. Pilihan server mana yang akan dituju akan bergantung pada algoritma yang digunakan. Linux Virtual Server menyediakan 3 topologi load balancing yang dapat digunakan. Ketiga topologi tersebut adalah Network Address Translation, Direct Routing, serta Tunneling. Ketiga topologi ini diimplementasikan bersama dengan algoritma untuk menentukan urutan server yang harus menangani setiap request dari client. Algoritma ini bekerja berdasarkan pada parameter yang berbeda-beda, seperti bobot kerja, jumlah request yang sedang ditangani, serta urutan antrian dari tiap web server[4]. Perbedaan dalam cara kerja tiap algoritma ini tentu saja akan berdampak pada performa dari web server dalam memberikan layanan kepada client Rumusan Masalah Yang menjadi rumusan masalah dalam tugas akhir ini adalah bagaimana menemukan algoritma penjadwalan yang paling baik di antara algoritma penjadwalan yang dimiliki oleh Linux Virtual Server dilihat dari seberapa cepat waktu respon server dalam memroses request yang datang dari user.

18 Tujuan Penelitian Menentukan algortima penjadwalan yang paling baik dari keseluruhan algoritma milik Linux Virtual Server, yang dapat menangani request dari client dengan melihat dari waktu respon request tercepat Batasan Masalah Batasan yang diterapkan dalam penelitian ini adalah : Topologi load balancing yang digunakan adalah NAT (Network Address Translation) Menggunakan sistem operasi Ubuntu Server LTS dengan kernel 3.11 Port yang digunakan adalah HTTP 80 Tidak meneliti sistem keamanan dari rangkaian server Penelitian dilakukan dalam lingkungan jaringan privat, tanpa terhubung dengan internet maupun jaringan intranet Metodologi Penelitian 1. Studi Pustaka Mencari referensi yang berasal dari berbagai sumber yang ada seperti

19 4 dari buku, jurnal ilmiah dan artikel internet terutama yang berkaitan dengan topik permasalahan yang akan diteliti. Referensi inilah yang akan digunakan sebagai dasar dari pengembangan skripsi yang akan dibuat. 2. Perancangan Pada poin ini, penulis akan melakukan langkah sebagai berikut : 1). Menentukan konfigurasi dan topologi jaringan yang akan digunakan dalam pengujian. 2). Konfigurasi dari Linux Virtual Server dan web server yang digunakan. 3). Menentukan skenario pengujian. 3. Implementasi & Analisa Membuat konfigurasi dari web server dan Linux Virtual Server berdasarkan perancangan yang telah dibuat. Kemudian dilakukan pengujian terhadap masing-masing algoritma penjadwalan dalam memanajemen request dari client menuju ke web server. Hasil pengujian akan dianalisa kemudian dengan menggunakan landasan teori yang ada. 4. Kesimpulan Hasil analisa akan digunakan untuk menarik kesimpulan akan penelitian yang dilakukan.

20 Sistematika Penulisan BAB I PENDAHULUAN Berisi latar belakang masalah, rumusan masalah, tujuan penelitian, batasan masalah, luaran yang diharapkan, dan sistematika penulisan. Merupakan bagian utama dari karya ilmiah ini yang menjadi acuan dalam melakukan penelitian. BAB II LANDASAN TEORI Berisi penjelasan mengenai dasar teori berkaitan dengan setiap aspek yang terkait dengan penelitian ini. BAB III PERANCANGAN Berisi tentang langkah-langkah dan metode kerja yang akan dilakukan demi tercapainya tujuan dari diadakannya penelitian. BAB IV IMPLEMENTASI DAN ANALISA Berisi tentang proses penelitian dan juga hasil yang didapatkan dari penelitian tersebut. BAB V KESIMPULAN Berisi kesimpulan yang didapatkan dalam dari hasil penelitian. Dalam bab ini juga berisi saran untuk penelitian lebih lanjut.

21 BAB II LANDASAN TEORI 2.1. Server Pengertian Server Dalam konteks jaringan secara umum, setiap alat yang merespon permintaan dari aplikasi client disebut sebagai server. Sebuah server biasanya berupa komputer yang berisi infomasi yang dibagikan kepada banyak client dalam sebuah sistem. Contohnya, halaman web, dokumen, database, gambar, video, dan file audio. Server didukung dengan prosesor yang bersifat scalable dan RAM yang besar, juga dilengkapi dengan sistem operasi khusus. Server juga menjalankan perangkat lunak administratif yang mengontrol akses terhadap jaringan dan sumber daya yang terdapat di dalamnya. Ada beberapa jenis layanan pada server. Masing-masing memiliki kemampuan dan tujuan yang berbeda-beda. Macam-macam layanan tersebut adalah[5] : 1) Web Server Merupakan sebuah software yang melayani permintaan berupa HTTP dari client dan memberikan suatu hasil berupa halaman halaman web yang ditampilkan dalam web browser. Web server berjalan pada port 80 HTTP 6

22 7 maupun port 443 HTTPS. Contoh web server adalah Apache, Windows Server IIS, Zerus, Xitami, dll. 2) Database Server Server database menyediakan layanan pengelolaan basis data dan melayani komputer atau program aplikasi basis data yang menggunakan model client / server. Beberapa contoh sistem manajemen basis data yang sering dipakai adalah MySQL dan Microsoft SQL Server. 3) Proxy Server Proxy server menyediakan cache dari alamat domain yang pernah dikunjungi. Cache ini akan mempersingkat proses waktu pencarian domain yang sama pada lain waktu, karena informasi alamat tersebut tinggal mengambil dari repository milik proxy server. 4) DNS Server DNS merupakan penerjemah alamat domain suatu komputer ke dalam bentuk IP. Dengan layanan DNS, user cukup mengetahui alamat dari domain tanpa harus mengetahui nomor IP dari domain tersebut. Selanjutnya, oleh DNS server akan diterjemahkan ke dalam IP, sehingga user dapat terhubung ke domain yang dimaksud. Contoh-contoh di atas merupakan beberapa jenis layanan yang tersedia pada sebuah server. Masih banyak layanan lain, yang tentunya memiliki tugas dan fungsi masing-masing. Layanan-layanan tersebut dapat

23 8 diinputkan pada satu server, maupun terpisah dengan setiap layanan memiliki server tersendiri Pengertian Web Server Pengertian dari web server adalah sebuah perangkat lunak server yang berfungsi menerima request dari client untuk mendapatkan informasi berupa halaman web dengan menggunakan protokol HTTP. Konten dari form web ini dapat berupa konten statis (teks, gambar) maupun dinamis (script). Sebagai contoh, user dari PC client meminta halaman web dari Facebook dengan mengetik alamat URL Facebook di web browser, yang kemudian akan diteruskan kepada web server milik Facebook. Server ini akan merespon dengan memberikan halaman Facebook dengan format HTML kepada client. Contoh dari aplikasi web server yang banyak digunakan adalah Apache Web Server Clustering Pengertian Clustering Clustering adalah sebuah software yang saling terintegrasi dengan kumpulan server untuk menerima request koneksi dan saling membagi beban pemrosesan antar server. Clustering sering disebut juga dengan load

24 9 balancing. Dalam clustering, software load balancer merupakan komponen penting untuk mengatur lalu lintas request dari client menuju server yang ditentukan lewat sebuah algoritma. Clustering muncul dari kebutuhan akan server yang redundan terhadap kenaikan lonjakan akses internet yang hampir mencapai dua kali lipat setiap tahunnya. Lonjakan akses ini tentunya membutuhkan infrastuktur yang selalu menunjang, dengan faktor-faktor yang dibutuhkan adalah[2] : Layanan harus fleksibel ; jika beban kerja bertambah, sistem harus bisa bisa mengakomodasi pertambahan tersebut. Layanan harus selalu tersedia, terbebas dari kerusakan hardware maupun kegagalan software. Sistem yang dibangun harus ekonomis ; baik ekonomis saat dibangun maupun saat akan di-upgrade. Walaupun keseluruhan sistem secara fisik tampak besar, namun harus mudah untuk dimanajemen oleh admin jaringan. Server cluster yang saling terkoneksi oleh jaringan, menawarkan ketersediaan layanan dan performa yang tinggi. Server cluster memiliki skalabilitas tinggi, lebih ekonomis, dan lebih reliable daripada sistem server tunggal dengan multi prosesor.

25 10 Gambar 2.1 Server Clustering 2.3. Linux Virtual Server (LVS) Pengertian LVS Linux Virtual Server (LVS) merupakan software load balancing berbasis sistem operasi Linux yang dikembangkan oleh Wensong Zhang. Dalam LVS, sekumpulan server cluster tampak sebagai sebuah server dengan satu alamat IP publik. LVS meneruskan setiap request dari client kepada server yang berbeda-beda berdasarkan pada algoritma yang digunakan.

26 Arsitektur Sistem Arsitektur dalam implementasi Linux Virtual Server dapat dibagi menjadi 3 bagian utama,yaitu : Load balancer, adalah bagian yang terhubung langsung dengan client. Request koneksi dari client akan didistribusikan menuju sekumpulan web server untuk kemudian diproses dan dikembalikan lagi kepada client. Server cluster, adalah sekumpulan web server yang menjalankan proses dari beberapa servis yang tersedia, seperti http, ftp, , dns, dan sebagainya. Basis data, adalah sebuah perangkat gudang data yang terkoneksi dengan kumpulan server tersebut, sehingga memudahkan dalam memberikan layanan dan servis yang sama untuk setiap server. Jika dituangkan dalam gambar, maka arsitektur umum pada LVS adalah sebagai berikut :

27 12 Gambar 2.2 Arsitektur umum Linux Virtual Server Load balancer bertindak sebagai pintu akses setiap request kepada sistem. Client mengakses situs melalui alamat IP yang diketahui, untuk selanjutnya load balancer akan meneruskan kepada server asli yang akan memroses request. Load balancer akan memilih server dari dalam kumpulan server berdasarkan algoritma yang digunakan, kemudian memforward paket ke server tersebut untuk selanjutnya diproses.

28 Topologi pada LVS Ada 3 topologi IP load balancing pada Linux Virtual Server, yaitu NAT (Network Address Translation), DR (Direct Routing), serta TUN(Tunneling). Masing-masing dari topologi ini memiliki keunggulan dan kekurangan tersendiri, seperti yang terlihat pada tabel di bawah ini[1]. Dengan demikian, penggunaan topologi dapat disesuaikan dengan kebutuhan. Gambar 2.3 Tabel perbandingan 3 topologi LVS Network Address Translation (NAT) Poin utama dari topologi ini adalah semua trafik data, baik masuk maupun keluar, melewati load balancer. Request masuk dari client ditangani dengan mengubah header IP tujuan menjadi IP dari server yang akan memrosesnya. Setelah request selesai ditangani oleh web server dan dikembalikan ke load balancer, header IP dikembalikan ke asalnya sebelum kemudian diteruskan kembali kepada client. Contohnya :

29 14 Paket datang dari IP (source) menuju IP load balancer, yaitu (destination). Oleh load balancer, IP destination diganti menjadi IP dari web server yang akan memroses request tersebut, misal Setelah paket dikembalikan ke load balancer, IP source dikembalikan menjadi sebelum dikembalikan ke client yang ber-ip , agar client mengenali bahwa paket yang datang memang berasal dari load balancer. Gambar 2.4 Topologi LVS NAT

30 Direct Routing (DR) Arsitektur dari topologi ini mengharuskan server dan load balancer saling terhubung secara fisik, misalnya via switch / HUB. Server dan load balancer berbagi IP virtual yang sama, yang dibagi antara loopback interface milik real server dengan salah satu ethernet milik load balancer. Transfer paket data terjadi dengan mengubah MAC address dari load balancer menjadi milik web server yang dituju. Setelah diproses, paket data akan langsung diteruskan oleh server menuju ke client. Yang harus diperhatikan adalah server harus mematikan konfigurasi ARP agar tidak terjadi tabrakan IP antar server dan load balancer. Gambar 2.5 LVS Direct Routing

31 Tunneling Konsep tunneling adalah membalut IP datagram dengan IP datagram pula,yang memungkinkan paket untuk diteruskan pada server yang berada di jaringan yang berbeda. Saat server menerima paket yang dienkapsulasi, paket data akan didekapsulasi untuk kemudian di proses dan dikirimkan kembali langsung kepada client. Dengan konsep ini, server bisa berada di segmentasi jaringan yang berbeda dari load balancer. Gambar 2.6 LVS Tunneling

32 Algoritma Penjadwalan pada LVS Algoritma penjadwalan digunakan oleh Linux Virtual Server untuk menentukan server mana yang akan memroses data request dari client. Pada awalnya, hanya 4 algoritma yang ada. Namun seiring berjalannya waktu, algoritma tersebut berkembang menjadi lebih banyak. Algoritma tersebut antara lain[4]: Round Robin (rr) Algoritma ini meneruskan setiap paket yang datang ke setiap server dengan model antrian. Sebagai contoh, digunakan 3 buah server A, B, dan C. Maka untuk request 1 akan dikerjakan server A, request 2 oleh server B, request 3 oleh server C, dan request 4 kembali kepada A. Algoritma Round Robin menangani setiap server dengan penanganan yang sama, terlepas dari kemampuan masingmasing server dalam menangani request Weighted Round Robin (wrr) Disini algoritma Round Robin dimodifikasi dengan memasukkan beban kerja server sebagai pertimbangan. Beban kerja ini, disebut dengan weight, merupakan indikator bagi load balancing untuk meneruskan request yang masuk. Server dengan weight yang

33 18 tinggi akan menerima jumlah request yang lebih banyak daripada server dengan weight yang lebih kecil Least Connection (lc) Algortima ini bekerja dengan mengarahkan request menuju server yang paling sedikit memiliki koneksi yang sedang tersambung. Algoritma ini terus meng-update catatan koneksi tersambung secara live, sehingga bisa diketahui server mana yang sedang menangani banyak request dan server mana yang tidak. Least Connection dapat bekerja dengan baik pada web server dengan spesifikasi hardware yang sama. Untuk server dengan spesifikasi hardware yang bervariasi, kerja algoritma ini bisa menjadi tidak optimal, disebabkan oleh adanya TCP_WAIT_TIME. Kondisi dari wait time ini akan menyebabkan setiap koneksi yang belum diproses disimpan dalam antrian. Akibatnya, server dengan spesifikasi rendah akan mengalami waktu proses yang lebih lama dibandingkan dengan server dengan spesifikasi tinggi, menyebabkan waktu reply yang tinggi untuk koneksi yang dilayani oleh server dengan spesifikasi rendah.

34 Weighted Least Connection (wlc) Versi modifikasi dari Least Connection, dimana beban kerja pada server juga menjadi pertimbangan dari load balancer. Pada algoritma ini, server dengan kemampuan pemrosesan yang tinggi dapat diberikan weight yang lebih besar daripada server dengan kemampuan pemrosesan yang lebih rendah. Algoritma ini dapat digunakan pada load balancer yang memiliki sekumpulan web server yang kemampuannya berbeda-beda Locally-Based Least Connection (lblc) Algoritma ini men-direct koneksi menuju server yang aktif dan memiliki koneksi yang sedikit. Jika ada server yang memiliki koneksi overload, maka koneksi akan diteruskan kepada server lainnya Locally-Based Least Connection /w Replication (lblcr) Algoritma ini membuat antrian menuju server dengan koneksi yang paling sedikit (Least Connection). Jika semua server dalam keadaan overload, maka load balancer akan memasukkan koneksi pada daftar antrian server dengan koneksi paling sedikit. Jika request ini tidak dijalankan dalam jangka waktu tertentu, maka server ini akan dihilangkan sementara dari daftar server yang aktif.

35 Destination Hash (dh) Pemilihan server berdasarkan pada IP destinasi dari server yang diset secara statik atau manual ke dalam tabel hash milik virtual server Source Hash (sh) Pemilihan server berdasarkan pada IP asal dari server yang diset secara statik atau manual ke dalam tabel hash milik virtual server Never Queue (nq) Ada 2 metode yang digunakan dalam algoritma ini. Metode pertama, jika ada server dengan kondisi idle, maka request akan langsung dikirimkan ke server tersebut, tanpa melihat prioritas dari server tersebut. Metode kedua, jika semua server sibuk, maka request akan dikirimkan menuju server dengan ekspektasi delay paling sedikit. Dengan kata lain, metode kedua mirip dengan algoritma Shortest Expected Delay Short Expected Delay (sed) Koneksi diarahkan pada server dengan ekspektasi waktu delay paling kecil. Rumus yang digunakan adalah (Ci+1)/Ui, dimana Ci adalah banyaknya koneksi pada server dan Ui adalah beban kerja server tersebut.

36 Webserver Stress Tool Pengertian Webserver Stress Tool Webstress Stress Tool merupakan software yang digunakan untuk mengukur kinerja dari web server. Pengukuran dilakukan dengan cara mensimulasikan sejumlah user request untuk menyerang web server dalam waktu yang bersamaan. Dengan begitu dapat diketahui bagaiamana performa dari web server Cara Kerja Webserver Pada tampilan awal, kita akan diberi 3 pilihan mode simulasi, yaitu CLICK, TIME, dan RAMP. Ketiga mode simulasi ini fungsi yang berbedabeda,yaitu : 1) CLICK : simulasi akan berjalan sampai setiap user mencapai jumlah click request yang telah ditentukan. Jumlah click yang dihitung baik yang sukses maupun tidak. 2) TIME : simulasi akan berjalan sepanjang batas waktu simulasi yang telah ditentukan. Jika simulasi sudah mencapai waktu yang ditentukan,maka semua aktivitas oleh user akan dihentikan. 3) RAMP : simulasi akan berjalan dengan kenaikan jumlah user dari mulai satu hingga ratusan user. Mode ini dapat digunaakn untuk mengetahui sejauh mana kemampuan server dalam menangani user.

37 22 Selain ketiga mode di atas, kita juga diharuskan untuk memilih berapa banyak user yang akan dipakai serta delay per klik dalam simulasi. Banyak user serta delay klik akan sangat menentukan seberapa stres kondisi yang kita inginkan pada web server[6]. Gambar 2.7 Tampilan menu awal Webserver Stress Tool Output Hasil Simulasi Hasil pengujian dengan menggunakan Webserver Stress Tool ditampilkan dalam bentuk teks dan grafik. Masing-masing grafik mewakili : 1) Click times & Error Grafik ini memperlihatkan rataan click time dan besaran error yang terjadi selama simulasi. Click time merupakan waktu dari pertama kali request dikirim hingga selesai dibalas oleh server. Grafik ini juga menunjukkan lama proses download dan error rate gambar pada halaman yang diakses jika opsi download image diaktifkan. Error bisa disebabkan karena terjadi

38 23 gangguan pada jaringan maupun data yang dikembalikan karena tidak diproses. 2) Click times, Hits/s & Clicks/s Perbedaannya dengan grafik pertama adalah adanya line tambahan berupa rataan jumlah click dan hit (klik yang sukses dilakukan) per user per detik. 3) Open Request & Traffic Grafik ini menunjukkan perbandingan antara besaran transfer data yang terjadi dengan jumlah request yang dapat dibuka oleh client. Dalam grafik ini juga termasuk berapa banyak request yang dikirim dan diterima oleh client per detiknya. 4) Protocol Times Grafik ini menunjukkan rataan waktu yang diperlukan untuk tiap langkah request HTTP. Pertama, proses translasi nama web ke dalam IP address lewat DNS (Time to DNS). Selanjutnya lama waktu dibukanya IP port oleh server (Time to Connect) untuk kemudian server mulai mengirimkan data yang diminta (Time for First Byte). Yang terakhir adalah lamanya keseluruhan proses berlangsung dari awal hingga selesai (Click time). 5) Test Client Health Grafik ini menunjukkan kondisi vital dari komputer yang menjalankan Webserver Stress Tool. Kondisi ini meliputi load CPU dalam persentase, jumlah penggunaan memory per detik, serta besaran transfer data per detik.

39 24 Dengan grafik ini dapat diketahui batasan yang dapat dicapai oleh PC client dalam melakukan simulasi. 6) Click time Spectrum Grafik ini menunjukkan waktu tunggu per user. Grafik ditampilkan dalam bentuk 3 dimensi. Vertical axis menunjukkan jumlah user dalam persentase, horizontal axis menunjukkan lamanya waktu tunggu per request, dan depth axis menunjukkan jumlah user total. 7) Bandwitdh Grafik ini menunjukkan penggunaan bandwidth server serta rataan penggunaan bandwidth pada client dalam hitungan perdetik. Dapat dikatakan bahwa grafik ini dapat menunjukkan efektivitas penggunaan bandwidth yang tersedia selama tes berlangsung.

40 BAB III PERANCANGAN 3.1. Konfigurasi Jaringan Tujuan akhir dari penulisan skripsi ini adalah untuk menemukan algoritma terbaik yang dimiliki oleh LVS dalam kaitannya membagi beban kerja yang masuk. Dibutuhkan perangkat web server lebih dari satu agar kinerja pembagian beban kerja algoritma dapat diamati. Maka untuk penelitian ini, akan digunakan 2 buah web server sebagai tempat halaman web berada dengan konten yang persis sama. Dalam penelitian ini, karena menggunakan topologi NAT, maka client cukup tersambung dengan LVS. Penelitian ini akan dilakukan dalam jaringan privat bebas internet untuk menghilangkan interferensi yang mungkin terdapat di internet. switch Gambar 3.1 Konfigurasi 2 server 25

41 26 Dalam merancang distribusi alamat IP pada masing-masing PC, akan digunakan konfigurasi 2 buah network. Alamat network pertama untuk pengalamatan antara PC client dengan server LVS, dengan subnet 30, dan alamat network kedua untuk pengalamatan antar server, dengan subnet 29. Konfigurasi IP yang digunakan sebagai berikut : Tabel 3.1 Distribusi IP address yang digunakan PC Interfce IP Address / Mask Gateway Client eth / Load Balancer eth / 30 - eth / 29 - Web Server 1 eth / Web Server 2 eth / Konfigurasi Hardware Spesifikasi Komputer Pada penelitian ini akan digunakan 3 PC untuk server (2 unit web server serta 1 unit load balancer) dan 1 PC sebagai client. Untuk spesifikasi hardware dari PC client dan server, baik load balancer maupun web server, memiliki spesifikasi yang sama. Spesifikasi dari server dan client yang digunakan :

42 27 Tabel 3.2 Spesifikasi Komputer Client & Server Spesifikasi Prosesor RAM Harddisk SERVER Dual 2.7 GHz 4 GB 500 GB CLIENT Dual 2.7 GHz 4 GB 500 GB Sistem Operasi Dalam pengujian ini, akan digunakan sistem operasi Linux Ubuntu Server LTS untuk web server dan server load balancing. Sistem operasi ini dipilih karena menggunakan kernel 3.11 yang sudah mendukung virtual server, sehingga tidak memerlukan patch sebelum memasang aplikasi load balancing. Untuk client, akan digunakan sistem operasi dari Windows, yaitu Windows 7 Ultimate 32bit. Langkah tambahan yang diperlukan adalah menginstall package ipvsadm pada load balancer, yang merupakan software untuk menjalankan load balancing. Package ipvsadm dapat diperoleh secara manual dengan mengunduh secara gratis lewat situs atau dengan memasukkan perintah sudo apt-get install ipvsadm pada terminal Linux.

43 Skenario Pengujian Pengujian akan dilakukan tanpa memperhitungkan beban kerja pada real server. Setiap web server akan mendapatkan distribusi beban kerja sama rata, karena hardware server yang digunakan dalam pengujian ini memiliki spesifikasi yang sama. Dengan demikian setiap unit web server akan diperlakukan sama oleh load balancer tanpa memperhitungkan kemampuan kinerja komputasi dari masing-masing web server. Pengujian akan dilakukan dengan menggunakan software Webserver Stress Tool. Pengujian akan dilakukan dengan menggunakan mode TIME, dengan lama waktu pengujian adalah 5 menit. Lama waktu ini dianggap cukup untuk mengumpulkan data yang dianggap valid untuk dianalisa serta menguji sistem yang tersedia[7]. Variabel yang digunakan untuk jumlah user yaitu 100, 200, dan 500 user. Untuk memberikan tingkat stress maksimal, delay per click akan diset pada angka 0. Hal ini sesuai pada panduan manual Webserver, yaitu semakin besar nilai user dan semakin kecil nilay delay per click, beban kerja yang diberikan kepada web akan semakin besar[6]. Selain setting di atas, pengujian juga akan dilakukan dengan menggunakan setting dowload Image. Fungsi dari setting ini adalah agar setiap user juga melakukan request untuk download setiap gambar yang ada pada halaman web yang diakses. Dengan menambah setting ini diharapkan dapat meningkatkan beban kerja pada server, sehingga perfoma server dapat semakin terlihat.

44 29 Gambar 3.2 Setting pengujian pada Webserver Delay yang dimaksud adalah jeda waktu user dalam melakukan request. Jika di set ke angka 0, maka setiap user akan langsung melakukan request lagi setelah selesai melakukan 1 request. Hal ini tentu akan menghasilkan tingkat stres yang lebih tinggi, karena setiap user akan memiliki rataan jumlah klik yang tinggi perdetiknya. Rataan ini tercapai karena setiap user tidak memiliki delay dalam melakukan request, sehingga bisa langsung melakukan request selanjutnya. Gambar 3.3 Contoh hasil uji 100 user Gambar di atas adalah contoh hasil yang didapat dengan pengujian menggunakan mode CLICK dengan jumlah user sebanyak 100. Terlihat rata-rata user melakukan klik request sebanyak kali perdetik, yang berarti setiap user melakukan paling tidak kali request dalam waktu 5 menit.

45 30 Gambar 3.4 Contoh hasil uji 200 user Untuk gambar di atas adalah contoh hasil uji dengan 200 user. Jumlah klik yang berhasil dilakukan user menurun 2x lipat. Rata-rata setiap user berhasil melakukan request sebanyak kali selama 5 menit. Gambar 3.5 Contoh hasil uji 500 user Sedangkan untuk gambar di atas adalah contoh hasil pengujian dengan 500 user mengakses secara bersamaan. Terlihat jumlah klik yang berhasil dilakukan oleh setiap user perdetiknya menurun tajam, hanya berkisar antara klik per user perdetik. Ini berarti setiap user hanya dapat melakukan request rata-rata sebanyak 8000 kali. Perbedaan ini dapat menjadi tolak ukur untuk melihat kemampuan setiap algoritma dalam menangani request. Berdasarkan dua gambar contoh pengujian di atas, dapat diketahui pula masing-masing user memiliki rataan waktu respon yang didapatkan untuk setiap request yang berhasil kembali dari server. Waktu respon ini nantinya akan

46 31 digunakan untuk mengomparasi kesepuluh algoritma untuk dilihat mana algoritma terbaik yang memberikan waktu respon lebih cepat daripada algoritma lainnya. Waktu respon yang dipakai akan dihitung dengan mengambil rata-rata dari nilai mentah yang didapatkan sebagai hasil pengujian. Rata-rata waktu yang diambil adalah rata-rata waktu respon keseluruhan user, bukan per user. Dari data tersebut, akan diambil algoritma dengan waktu tercepat serta waktu terlambat pada setiap jumlah user. Gambar 3.6 Contoh raw data yang sudah dipindah ke Excel Data yang akan digunakan akan diambil dengan menghitung data AVERAGE menggunakan Ms. Excel. Dari hasil penghitungan akan didapatkan nilai rata-rata yang diinginkan. Data pada kolom A adalah waktu pengambilan data, sedangkan B adalah data waktu respon, serta data berakhir pada setiap kolom ke 60, sehingga rumus yang digunakan adalah :

47 32 = AVERAGE (B2:B60) Untuk pengujian ini, web server menggunakan Apache Web Server. Web server ini akan diisi dengan konten berupa halaman web lomba SadharBlog. Untuk setting web server, digunakan setting web default dari Apache tanpa mengubah apapun.

48 BAB IV IMPLEMENTASI DAN ANALISA 4.1. Instalasi Web dan Virtual Server Konfigurasi Web Server Dalam pengujian ini, untuk web server akan digunakan sistem operasi dari Linux yaitu Ubuntu. Ubuntu yang dipilih adalah versi Server LTS. Sistem operasi ini sudah memiliki package Apache yang berfungsi sebagai konten web. Opsi ini dapat dipilih saat proses instalasi, yaitu dengan memilih opsi LAMP (Linux-Apache-MySQL-PHP) Server pada langkah instalasi package. Setelah memasukkan folder berisi data dari konten web ke dalam direktori /var/www, perlu diaktifkan agar dapat digunakan. Untuk mengaktifkan web tersebut, terlebih dahulu folder harus diberikan hak akses agar bisa diakses oleh semua user. Masukan perintah : # sudo chown R $USER:$USER /var/www/[nama folder] # sudo chown R 755 /var/www Kolom [nama folder] diisi dengan nama dari folder website yang akan ditampilkan. Setelah itu, ubah setting agar file website dari folder tersebut yang akan ditampilkan saat diakses dari luar server. Masukkan perintah : 33

49 34 # sudo nano /etc/apache2/sites-available/default Pada file konfigurasi ini, ubah kolom DocumentRoot agar mengarah ke folder yang berisi file website. Dalam skripsi ini digunakan nama [sadarblog] untuk folder file website,sehingga harus ditulis : DocumentRoot /var/www/sadarblog Simpan konfigurasi, kemudian masukkan perintah untuk mengaktifkan website tersebut : # sudo a2ensite sadarblog Restart konfigurasi Apache dengan perintah sudo apache2 reload. Untuk ujicoba, masukkan IP Address server dari komputer luar server. Jika berhasil, akan keluar tampilan sebagai berikut : Gambar 4.1 Halaman utama web dalam real server

50 Konfigurasi Virtual Server Untuk server Load Balancer, akan digunakan sistem operasi dari Linux Ubuntu. Versi yang digunakan adalah Ubuntu Server LTS dengan kernel Versi kernel ini sudah memiliki modul-modul yang diperlukan untuk mendukung virtual server, sehingga tidak perlu dilakukan patch. Untuk yang menggunakan versi kernel yang belum mendukung virtual server (2.4 kebawah), dapat dilihat tutorial cara instal pada laman web Walau sudah mendukung virtual server, namun kita perlu mengaktifkan modul-modul yang diperlukan dengan perintah modprobe. Modul ini diperlukan agar kita dapat menggunakan algoritma yang ada pada virtual server. Ketikan deretan perintah berikut untuk mengaktifkan modul virtual server : # echo ip_vs_dh >> /etc/modules # echo ip_vs_ftp >> /etc/modules # echo ip_vs >> /etc/modules # echo ip_vs_lblc >> /etc/modules # echo ip_vs_lblcr >> /etc/modules # echo ip_vs_lc >> /etc/modules # echo ip_vs_nq >> /etc/modules # echo ip_vs_rr >> /etc/modules

51 36 # echo ip_vs_sed >> /etc/modules # echo ip_vs_sh >> /etc/modules # echo ip_vs_wlc >> /etc/modules # echo ip_vs_wrr >> /etc/modules # modprobe ip_vs_dh # modprobe ip_vs_ftp # modprobe ip_vs # modprobe ip_vs_lblc # modprobe ip_vs_lblcr # modprobe ip_vs_lc # modprobe ip_vs_nq # modprobe ip_vs_rr # modprobe ip_vs_sed # modprobe ip_vs_sh # modprobe ip_vs_wlc # modprobe ip_vs_wrr Langkah selanjutnya adalah meng-install ipvsadm. Software ini berfungsi untuk mengaktifkan fungsi load balancing pada virtual server. Software ini bisa didapatkan lewat internet dengan memasukkan perintah : # sudo apt-install ipvsadm

52 37 Atau jika tidak ada koneksi internet, dapat di-install manual dengan terlebih dahulu men-download ipvsadm dalam format [.deb]. Package diinstall dengan mengetikkan perintah : # dpkg i [nama file].deb Setelah ter-install, masukkan perintah berikut untuk mengkonfigurasi ipvsadm : # dpkg-reconfigure ipvsadm Pilih Yes pada pilihan pertama untuk mengaktifkan fungsi ipvsadm saat booting. Kemudian pilih Master untuk pilihan peran dari virtual server. Setelah itu, akan muncul pilihan untuk memasukkan ethernet yang digunakan untuk multicast. Pada pilihan ini, dimasukkan ethernet yang terhubung dengan web server, dalam skripsi ini adalah ethernet 0 ( eth0 ). Setelah itu, pastikan bahwa server bisa mem-forward paket IP dengan mengedit nilai dari baris net.ipv4.ip_forward menjadi 1 pada file /etc/sysctl.conf, kemudian restart konfigurasi dengan mengetik : # sudo sysctl p Langkah selanjutnya adalah mengkonfigurasi iptables untuk mendukung proses masquerade pada topologi NAT yang digunakan, dengan memasukkan perintah : # iptables A FORWARD s /29 d /30 p 80 j ACCEPT

53 38 # iptables t nat A POSTROUTING o eth1 j MASQUERADE Untuk dapat menggunakan ipvsadm, perlu dimasukkan alamat IP dari server, serta algoritma yang akan digunakan. Format perintah untuk memasukkan setting dari ipvsadm adalah : # ipvsadm A t [ip address lvs : port] s [algoritma penjadwalan] Isi kolom [ip address lvs:port] di atas mengacu pada alamat IP dari LVS yang terhubung dengan client / network eksternal bersama dengan port dari layanan yang akan dijalankan. Sedangkan kolom [algoritma] diisi dengan opsi algoritma penjadwalan yang akan digunakan, contohnya untuk mengaktifkan algoritma Round Robin, maka masukkan perintah rr pada kolom [algoritma penjadwalan]. Kode untuk nama-nama algoritma pada LVS dapat dilihat pada halaman manual dari ipvsadm. Perintah selanjutnya adalah memasukkan alamat IP dari web server yang digunakan. Cara menginputkan sama seperti contoh di atas, yaitu dengan memasukkan IP beserta port dari layanan yang diberikan. Kemudian dilanjutkan dengan opsi topologi yang digunakan. Baris perintahnya adalah sebagai berikut : # ipvsadm a t [ip address lvs : port] r [ip address server : port] [opsi topologi] Pada skripsi ini digunakan topologi NAT, maka digunakan opsi masquerade [-m]. Opsi ini dapat diganti sesuai dengan topologi yang akan

54 39 digunakan, yaitu g untuk Direct Routing dan i untuk Tunneling. Selain itu ada pula opsi w untuk memberikan bobot pada masing-masing server. Perintah ini bisa digunakan saat memakai algoritma Weighted Round Robin (wrr) maupun Weighted Least Connection (wlc) yang juga memperhitungkan beban server dalam menjalankan algoritma. Contohnya, untuk algoritma Weighted Round Robin dengan beban server 2 dan opsi topologi masquerade, maka diinputkan perintah : # ipvsadm a t :80 r :80 m w 2 Perintah di atas dapat diulang sesuai dengan jumlah web server yang digunakan, hanya tinggal menyesuaikan ip address dari real server serta ada tidaknya beban server untuk real web server yang diinputkan. Indikator benar atau tidaknya setting ipvsadm adalah jika mengetik alamat IP dari real server via web browser client, maka yang akan muncul adalah web page milik real server. Untuk melihat apakah setting pada ipvsadm sudah benar, inputkan perintah : # ipvsadm ln 4.2. Hasil Pengujian dan Analisa Setiap pengujian dilakukan dalam rentang waktu 5 menit. Setelah pengujian selesai, akan didapatkan data mentah berupa. Berdasarkan data mentah ini, akan di rata-rata untuk kemudian dimasukkan ke dalam grafik, untuk dibandingkan dengan grafik rata-rata dari algoritma lainnya.

55 40 Pengujian akan dilakukan 3 kali. Dimulai dari pengujian dengan beban user sebesar 100, lalu dinaikan menjadi 200, dan terakhir menjadi 500 user dalam sekali pengujian. Hal ini dilakukan untuk melihat kinerja server dalam menghadapi berbagai pola trafik data, dengan harapan walaupun server diberi pola beban yang berbeda, hasil yang dikeluarkan tidak berbeda terlalu jauh. Dengan demikian, akan didapatkan data yang lebih akurat. Akan dilakukan serangkaian pengujian dengan menggunakan rasio beban kerja server default, yaitu 1-1. Artinya, setiap web server akan diperlakukan sama oleh load balancer, terlepas dari kemampuan komputasi dari masing-masing web server. Sistem pembagian request oleh load balancer akan ditentukan oleh masing-masing algoritma yang sedang berjalan. Waktu respon server dilihat dari lamanya proses request permintaan laman web yang dikembalikan oleh server kepada client. Proses request dimulai dari saat client men-generate permintaan laman web kepada server (click), hingga direspon oleh server dalam bentuk laman web yang diminta kepada client. Output dari proses ini adalah (x) second/click, yaitu waktu rata-rata yang diperlukan oleh server untuk menyelesaikan setiap request dalam satuan detik.

56 41 Hasilnya, untuk waktu respon server terhadap request 100 user, algoritma Locally-Based Least Connection w/ Replication (LBLCR) memiliki waktu respon tercepat dengan rata-rata waktu respon yang didapat setiap user mencapai 1.47 detik. Algoritma ini memiliki selisih waktu yang lebih cepat 0.01 detik dibandingkan dua algoritma Least Connection, yaitu LC dan WLC. Hal ini disebabkan karena ketiga algoritma ini sebenarnya bekerja dengan algoritma yang sama, namun LBLCR memiliki keunggulan dalam me-manage antrian request dengan menonaktifkan sementara daftar server aktif jika antrian tidak segera dieksekusi oleh server. Poin ini membantu server untuk tidak mengalami overload lebih cepat daripada algoritma lainnya. Beban user Gambar 4.2 Waktu respon server beban user 100 Untuk algoritma terlambat terjadi pada Destination Hash (DH) yang memiliki waktu respon 1.61 detik. Algoritma DH menggunakan konsep squid server, dimana server akan diset menyimpan cache data yang menyebabkan setiap request yang masuk akan melewati server tersebut[8].

57 42 Akibatnya, server yang dianggap aktif hanya 1. Walaupun secara teori cache tersebut mempercepat proses pengambilan data, tetapi karena trafik data menjadi 1, maka menjadi tidak efektif jika dibandingkan dengan algoritma lain yang menggunakan 2 server. Jika dibandingkan dengan pengujian dimana komputer client terhubung langsung ke server tanpa melewati LVS (Tanpa Algoritma), dapat diketahui bahwa waktu responnya tidak berbeda jauh dengan beberapa algoritma LVS. Waktu respon pengujian tanpa algoritma ini hanya terpaut 0.06 detik jika dibandingkan dengan algoritma LBLCR yang memiliki waktu respon tercepat. Dikarenakan pada pengujian ini baru tercapai 100 jumlah user yang mengakses server, maka waktu respon pada sistem single server tanpa menggunakan algoritma masih tidak jauh berbeda dengan waktu respon dengan menggunakan algoritma-algoritma LVS. Pada pengujian dengan beban user 200, algoritma LBLCR masih menjadi yang tercepat dengan waktu respon sebesar 3.20 detik. Sedangkan untuk respon terlambat terjadi pada saat diujikan pada Point-to-Point. Berdasarkan pada pengujian ini, algoritma LBLCR terbukti masih efektif digunakan untuk meng-handle jumlah user yang tidak terlalu besar. Sedangkan algoritma Destination Hash masih menjadi algoritma terlambat dengan catatan waktu respon mencapai 4.13 detik. Hal ini disebabkan oleh digunakannya setting default pada web server, yaitu dibatasi hanya 150 user yang bisa terkoneksi ke server dalam satu waktu, sehingga menyebabkan

58 43 server menjadi lebih cepat overload dengan adanya 200 user yang mencoba terkoneksi secara bersamaan. Beban user Gambar 4.3 Waktu respon server beban user 200 Pada pengujian tanpa algoritma, karena semua request hanya ditangani oleh 1 server saja, maka kemungkinan overload pada server semakin besar, sehingga waktu responnya menjadi lebih lambat 1 detik dari LBLCR. Pada pengujian ini, setting pada Apache Web Server menggunakan setting default juga. Pada setting ini, setiap server hanya dapat menangani 150 thread atau 150 user yang terkoneksi dalam satu waktu. Inilah yang menyebabkan overload lebih besar kemungkinan terjadinya daripada pengujian lewat LVS dengan menggunakan algoritma. Pada pengujian ketiga dengan beban user 500, terjadi perubahan yang cukup signifikan. DH justru menjadi algoritma tercepat dengan waktu respon 7.66 detik, sedangkan waktu terlama oleh WLC dengan 8.84 detik.

59 44 Beban user Gambar 4.4 Waktu respon server beban user 500 Dengan diberi beban sebesar 500 user langsung dalam satu waktu, maka setiap server akan menerima masing-masing 250 user dalam satu waktu. Namun karena setting default pada web server hanya membolehkan 150 user saja yang terkoneksi pada satu waktu, maka sisa user yang tidak terkoneksi harus menunggu untuk mendapatkan koneksi dari server. Akibatnya server mengalami overload yang sangat signifikan. Kondisi ini menyebabkan setiap server memiliki waktu respon yang cukup tinggi, mengingat banyaknya antrian yang terjadi pada pengujian ini. Namun pada algoritma DH, karena menyimpan cache dari halaman web, maka proses pengembalian data pada kepada user menjadi lebih cepat daripada algoritma lain. Pada beban uji kali ini, cara kerja algoritma DH terbukti lebih efektif dalam menangani beban user yang besar.

60 45 Dibandingkan dengan pengujian langsung tanpa melewati LVS atau tanpa algoritma, waktu respon yang didapat masih cukup besar jika dibandingkan dengan pengujian dengan menggunakan LVS. Waktu respon pada pengujian tanpa algoritma hanya berbeda sedikit dengan algoritma RR, WRR, dan WLC. Walau begitu, berdasarkan waktu respon yang didapat, sistem single server tanpa algoritma LVS tidak dapat memberikan waktu respon yang optimal karena waktu respon yang didapatkan cukup besar, dan terjadi perbedaan sebesar hampir 1 detik jika dibandingkan dengan algoritma DH sebagai algoritma dengan waktu respon tercepat. Berdasarkan ketiga pengujian di atas, maka dapat ditarik kesimpulan sementara bahwa algoritma LBLCR lebih baik dalam meng-handle jumlah user kecil. Sementara untuk jumlah user yang lebih besar, algoritma DH lebih baik dalam menangani jumlah yang besar.

61 BAB V KESIMPULAN 5.1. Kesimpulan Berdasarkan hasil penelitian yang telah dilakukan, maka dapat diambil beberapa kesimpulan sebagai berikut : 1) untuk jumlah user 100, waktu tercepat dimiliki oleh algoritma Locally- Based Least Connection w/ Replication atau LBLCR. 2) untuk jumlah user 200, waktu tercepat dimiliki oleh algoritma Locally- Based Least Connection w/ Replication atau LBLCR. 3) untuk jumlah user 500, waktu tercepat dimiliki oleh algoritma Destination Hash atau DH Saran Ada beberapa saran yang dapat digunakan untuk pengembangan pada penelitian selanjutnya, yaitu : 1) menambahkan fitur keepalived atau heartbeat pada load balancer untuk melihat bagaimana proses pembagian request saat ada pengurangan jumlah web server ditengah proses. 2) menambah jumlah real server. 3) menambah jumlah hardware client yang terhubung untuk melakukan request. 46

62 DAFTAR PUSTAKA [1] Zhang, W. Linux Virtual Server for Scalable Network Services. Tersedia : (Tanggal akses : 13 Februari 2014) [2] Bourke, T. Server Load Balancing. O Reilly & Associates, Inc:USA [3] Horman, S. Linux Virtual Server Tutorial Tersedia : (Tanggal akses : 13 Februari 2014) [4] Zhang, W. Job Scheduling Algorithms in Linux Virtual Server (Tanggal akses : 18 Februari 2014) [5] Firdian, F. Macam-macam Server. Tersedia: (Tanggal akses : 5 Maret 2014) [6] Webserver Stress Tool User Manual. Paessler. Tersedia: (Tanggal akses : 28 Januari 2014) [7] Huston, G. Measuring IP Network Performance. Telstra. The Internet Protocol Journal-Volume 6, Number 1-Cisco System Tersedia: _6-1/measuring_ip.html (Tanggal akses : 25 Juni 2014) [8] Mack, J. LVS-HOWTO Tersedia: HOWTO/HOWTO/LVS-HOWTO.ipvsadm.html#DH (Tanggal akses : 28 Agustus 2014) 47

63 LAMPIRAN 1. Raw data user Round Robin 48

64 49

65 Weighted Round Robin 50

66 51

67 52

68 Least Connection 53

69 54

70 55

71 Weighted Least Connection 56

72 57

73 Locally-Based Least Connection 58

74 59

75 60

76 Locally-Based Least Connection with Replication 61

77 62

78 Destination Hash 63

79 64

80 65

81 Source Hash 66

82 67

83 68

84 Never Queue 69

85 70

86 Shortest Expected Delay 71

87 72

88 73

89 user Round Robin 74

90 75

91 76

92 77

93 78

94 Weighted Round Robin 79

95 80

96 81

97 82

98 83

99 Least Connection 84

100 85

101 86

102 87

103 88

104 Weighted Least Connection 89

105 90

106 91

107 92

108 93

109 Locally-Based Least Connection 94

110 95

111 96

112 97

113 98

114 Locally-Based Least Connection with Replication 99

115 100

116 101

117 102

118 103

119 Destination Hash 104

120 105

121 106

122 107

123 108

124 Source Hash 109

125 110

126 111

127 112

128 113

129 Never Queue 114

130 115

131 116

132 117

133 118

134 Shortest Expected Delay 119

135 120

136 121

137 122

138 123

139 user Round Robin 124

140 125

141 126

142 127

143 128

144 129

145 130

146 131

147 132

148 133

149 134

150 135

151 Weighted Round Robin 136

152 137

153 138

154 139

155 140

156 141

157 142

158 143

159 144

160 145

161 146

162 147

163 148

164 Least Connection 149

165 150

166 151

167 152

168 153

169 154

170 155

171 156

172 157

173 158

174 159

175 160

176 Weighted Least Connection 161

177 162

178 163

179 164

180 165

181 166

182 167

183 168

184 169

185 170

186 171

187 172

188 173

189 Locally-Based Least Connection 174

190 175

191 176

192 177

193 178

194 179

195 180

196 181

197 182

198 183

199 184

200 185

201 Locally-Based Least Connection with Replication 186

202 187

203 188

204 189

205 190

206 191

207 192

208 193

209 194

210 195

211 196

212 197

213 Destination Hash 198

214 199

215 200

216 201

217 202

218 203

219 204

220 205

221 206

222 207

223 208

224 209

225 210

226 Source Hash 211

227 212

228 213

229 214

230 215

231 216

232 217

233 218

234 219

235 220

236 221

237 222

238 Never Queue 223

239 224

240 225

241 226

242 227

243 228

244 229

245 230

246 231

247 232

248 233

249 234

250 Shortest Expected Delay 235

251 236

252 237

253 238

254 239

255 240

256 241

257 242

258 243

259 244

260 245

261 246

262 247