LOAD BALANCER PADA LINUX VIRTUAL SERVER

PLAGIAT MERUPAKAN TINDAKAN TIDAK TERPUJI

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 095314068

PROGRAM STUDI TEKNIK INFORMATIKA JURUSAN TEKNIK INFORMATIKA FAKULTAS SAINS DAN TEKNOLOGI UNIVERSITAS SANATA DHARMA YOGYAKARTA 2016

i


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 095314068

HALAMAN JUDUL (INGGRIS) INFORMATICS ENGINEERING STUDY PROGRAM INFORMATICS ENGINEERING DEPARTMENT FACULTY OF SCIENCE AND TECHNOLOGY SANATA DHARMA UNIVERSITY YOGYAKARTA 2016

ii


HALAMAN PERSETUJUAN

iii


HALAMAN PENGESAHAN

SKRIPSI

ANALISIS UNJUK KERJA ALGORITMA PENJADWALAN LOAD BALANCER PADA LINUX VIRTUAL SERVER Yang dipersiapkan dan Disusun Oleh : Yoseph Dian Sahadewa 095314068

Telah dipertahankan di depan Panitia Penguji Pada tanggal 21 Juli 2016 Dan dinyatakan memenuhi syarat

Susunan Panita Penguji Tanda Tangan Sri Hartati Wijono, M.Kom.

………...

Sekretaris :

Puspaningtyas Sanjoyo Adi, S.T., M.T.

………...

Anggota

Iwan Binanto, S.Si., M.Cs.

…………

Ketua

:

:

Yogyakarta, … Juli 2016 Fakultas Sains dan Teknologi Universitas Sanata Dharma Dekan,

(Sudi Mungkasi, S.Si., M.Math.SC., Ph.D.)

iv


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


HALAMAN MOTTO

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

vi


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

: 095314068

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


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


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


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


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


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..........................................................................................................1 1.1.

Latar Belakang ..............................................................................................1

1.2.

Rumusan Masalah .........................................................................................2

1.3.

Tujuan Penelitian...........................................................................................3

1.4.

Batasan Masalah ............................................................................................3

1.5.

Metodologi Penelitian ....................................................................................3

1.6.

Sistematika Penulisan ....................................................................................5

BAB II ...........................................................................................................................6 LANDASAN TEORI .....................................................................................................6 2.1.

Server ..............................................................................................................6

2.1.1.

Pengertian Server ...................................................................................6

2.1.2.

Pengertian Web Server ...........................................................................8

2.2.

Clustering .......................................................................................................8

2.2.1. 2.3.

Pengertian Clustering .............................................................................8

Linux Virtual Server (LVS) .......................................................................... 10

2.3.1.

Pengertian LVS .................................................................................... 10

xii


2.3.2.

Arsitektur Sistem ................................................................................. 11

2.3.3.

Topologi pada LVS .............................................................................. 13

2.3.4.

Algoritma Penjadwalan pada LVS ...................................................... 17

2.4.

Webserver Stress Tool ................................................................................... 21

2.4.1.

Pengertian Webserver Stress Tool......................................................... 21

2.4.2.

Cara Kerja Webserver .......................................................................... 21

2.4.3.

Output Hasil Simulasi .......................................................................... 22

BAB III ........................................................................................................................ 25 PERANCANGAN ....................................................................................................... 25 3.1.

Konfigurasi Jaringan ................................................................................... 25

3.2.

Konfigurasi Hardware ................................................................................. 26

3.2.1.

Spesifikasi Komputer ........................................................................... 26

3.2.2.

Sistem Operasi...................................................................................... 27

3.3.

Skenario Pengujian ...................................................................................... 28

BAB IV ........................................................................................................................ 33 IMPLEMENTASI DAN ANALISA ........................................................................... 33 4.1.

Instalasi Web dan Virtual Server .................................................................. 33

4.1.1.

Konfigurasi Web Server ........................................................................ 33

4.1.2.

Konfigurasi Virtual Server ................................................................... 35

4.2.

Hasil Pengujian dan Analisa ........................................................................ 39

BAB V.......................................................................................................................... 46 KESIMPULAN ........................................................................................................... 46 5.1.

Kesimpulan .................................................................................................. 46

5.2.

Saran ............................................................................................................ 46

DAFTAR PUSTAKA .................................................................................................. 47 LAMPIRAN ................................................................................................................ 48

xiii


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

xiv


DAFTAR TABEL

Tabel 3.1 Distribusi IP address yang digunakan .......................................... 26 Tabel 3.2 Spesifikasi komputer client & server ............................................. 27

xv


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

PLAGIAT MERUPAKAN TINDAKAN TIDAK TERPUJI 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.

1.2. 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.


1.3. 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.

1.4. Batasan Masalah Batasan yang diterapkan dalam penelitian ini adalah : 

Topologi load balancing yang digunakan adalah NAT (Network Address Translation)



Menggunakan sistem operasi Ubuntu Server 12.04 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.

1.5. Metodologi Penelitian 1.

Studi Pustaka Mencari referensi yang berasal dari berbagai sumber yang ada seperti


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.


1.6. 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.


BAB II LANDASAN TEORI

2.1. Server 2.1.1.

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


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


diinputkan pada satu server, maupun terpisah dengan setiap layanan memiliki server tersendiri. 2.1.2.

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.

2.2. Clustering 2.2.1.

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


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.


Gambar 2.1 Server Clustering

2.3. Linux Virtual Server (LVS) 2.3.1.

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.


2.3.2.

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, email, 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 :


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.


2.3.3.

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 2.3.3.1. 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 :


Paket datang dari IP 202.198.20.200 (source) menuju IP load balancer, yaitu 202.198.20.10 (destination). Oleh load balancer, IP destination diganti menjadi IP dari web server yang akan memroses request tersebut, misal 192.168.10.21. Setelah paket dikembalikan ke load balancer, IP source dikembalikan menjadi 202.198.20.10 sebelum dikembalikan ke client yang ber-IP 202.198.20.200, agar client mengenali bahwa paket yang datang memang berasal dari load balancer.

Gambar 2.4 Topologi LVS NAT


2.3.3.2. 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


2.3.3.3. 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


2.3.4.

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]: 2.3.4.1. 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. 2.3.4.2. 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


tinggi akan menerima jumlah request yang lebih banyak daripada server dengan weight yang lebih kecil. 2.3.4.3. 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.


2.3.4.4. 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. 2.3.4.5. 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. 2.3.4.6. 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.


2.3.4.7. Destination Hash (dh) Pemilihan server berdasarkan pada IP destinasi dari server yang diset secara statik atau manual ke dalam tabel hash milik virtual server 2.3.4.8. Source Hash (sh) Pemilihan server berdasarkan pada IP asal dari server yang diset secara statik atau manual ke dalam tabel hash milik virtual server. 2.3.4.9. 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. 2.3.4.10. 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.


2.4. Webserver Stress Tool 2.4.1.

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. 2.4.2.

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.


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 2.4.3.

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


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.


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.


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


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

eth0

192.168.100.2 / 30

192.168.100.1

eth1

192.168.100.1 / 30

-

eth0

172.23.5.1 / 29

-

Web Server 1

eth1

172.23.5.4 / 29

172.23.5.1

Web Server 2

eth1

172.23.5.5 / 29

172.23.5.1

Load Balancer

3.2. Konfigurasi Hardware 3.2.1.

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 :


Tabel 3.2 Spesifikasi Komputer Client & Server

Spesifikasi

SERVER

CLIENT

Prosesor

Dual Core @ 2.7 GHz

Dual Core @ 2.7 GHz

RAM

4 GB

4 GB

Harddisk

500 GB

500 GB

3.2.2.

Sistem Operasi Dalam pengujian ini, akan digunakan sistem operasi Linux Ubuntu

Server 12.05.5 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 www.linuxvirtualserver.org, atau dengan memasukkan perintah sudo apt-get install ipvsadm pada terminal Linux.


3.3. 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.


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 173-186 kali perdetik, yang berarti setiap user melakukan paling tidak 50000 kali request dalam waktu 5 menit.


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 25000 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 25-31 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


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 :


= 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.


BAB IV IMPLEMENTASI DAN ANALISA

4.1. Instalasi Web dan Virtual Server 4.1.1.

Konfigurasi Web Server Dalam pengujian ini, untuk web server akan digunakan sistem operasi

dari Linux yaitu Ubuntu. Ubuntu yang dipilih adalah versi Server 12.05.5 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


# 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


4.1.2.

Konfigurasi Virtual Server Untuk server Load Balancer, akan digunakan sistem operasi dari

Linux Ubuntu. Versi yang digunakan adalah Ubuntu Server 12.05.5 LTS dengan kernel 3.11. 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 www.linuxvirtualserver.org. 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


# 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


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 172.23.5.0/29 –d 192.168.100.0/30 –p 80 –j ACCEPT


# 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


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 192.168.100.1:80 –r 172.23.5.5: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.


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.


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 100 1.61 1.56

1.55 1.51

1.49

1.48

1.48

1.47

1.51

1.50

1.53

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].


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


server menjadi lebih cepat overload dengan adanya 200 user yang mencoba terkoneksi secara bersamaan.

Beban user 200

3.26

3.30

3.24

3.21

3.57

4.13

4.29

4.04

3.20

3.24

3.27


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.


Beban user 500 8.77

8.84

8.83 8.47

8.24

8.38

8.16

8.53

8.12 7.66

7.87


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.


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.


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 LocallyBased Least Connection w/ Replication atau LBLCR. 2) untuk jumlah user 200, waktu tercepat dimiliki oleh algoritma LocallyBased Least Connection w/ Replication atau LBLCR. 3) untuk jumlah user 500, waktu tercepat dimiliki oleh algoritma Destination Hash atau DH. 5.2. 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


DAFTAR PUSTAKA

[1]

Zhang, W. Linux Virtual Server for Scalable Network Services. Tersedia : http://linuxvirtualserver.org/ols/lvs.pdf (Tanggal akses : 13 Februari 2014)

[2]

Bourke, T. Server Load Balancing. O’Reilly & Associates, Inc:USA. 2001.

[3]

Horman,

S.

Linux

Virtual

Server

Tutorial.

2004.

Tersedia

:

http://www.ultramonkey.org/papers/lvs_tutorial/html/ (Tanggal akses : 13 Februari 2014) [4]

Zhang, W. Job Scheduling Algorithms in Linux Virtual Server. 2011 http://www.linuxvirtualserver.org/docs/scheduling.html/ (Tanggal akses : 18 Februari 2014)

[5]

Firdian, F. Macam-macam Server. Tersedia: http://www.scribd.com/doc/28131016/Macam-Macam-Server (Tanggal akses : 5 Maret 2014)

[6]

Webserver

Stress

Tool

User

Manual.

Paessler.

Tersedia:www.paessler.com/support/manuals (Tanggal akses : 28 Januari 2014) [7]

Huston, G. Measuring IP Network Performance. Telstra. The Internet Protocol

Journal-Volume

6,

Number

1-Cisco

System.

2003.

Tersedia:http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj _6-1/measuring_ip.html (Tanggal akses : 25 Juni 2014) [8]

Mack, J. LVS-HOWTO. 2012. Tersedia: http://www.austintek.com/LVS/LVSHOWTO/HOWTO/LVS-HOWTO.ipvsadm.html#DH (Tanggal akses : 28 Agustus 2014)

47


LAMPIRAN

1.

Raw data 1.1. 100 user 

Round Robin

48


49




Weighted Round Robin

50


51


52




Least Connection

53


54


55




Weighted Least Connection

56


57




Locally-Based Least Connection

58


59


60




Locally-Based Least Connection with Replication

61


62




Destination Hash

63


64


65




Source Hash

66


67


68




Never Queue

69


70




Shortest Expected Delay

71


72


73


1.2. 200 user 

Round Robin

74


75


76


77


78





79


80


81


82


83




Least Connection

84


85


86


87


88





89


90


91


92


93





94


95


96


97


98





99


100


101


102


103




Destination Hash

104


105


106


107


108




Source Hash

109


110


111


112


113




Never Queue

114


115


116


117


118





119


120


121


122


123


1.3. 500 user 

Round Robin

124


125


126


127


128


129


130


131


132


133


134


135





136


137


138


139


140


141


142


143


144


145


146


147


148




Least Connection

149


150


151


152


153


154


155


156


157


158


159


160





161


162


163


164


165


166


167


168


169


170


171


172


173





174


175


176


177


178


179


180


181


182


183


184


185





186


187


188


189


190


191


192


193


194


195


196


197




Destination Hash

198


199


200


201


202


203


204


205


206


207


208


209


210




Source Hash

211


212


213


214


215


216


217


218


219


220


221


222




Never Queue

223


224


225


226


227


228


229


230


231


232


233


234





235


236


237


238


239


240


241


242


243


244


245


246


247

LOAD BALANCER PADA LINUX VIRTUAL SERVER

Recommend Documents