Analisis unjuk kerja algoritma penjadwalan load balancer pada linux virtual server.

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.

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.

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

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

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

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,

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

HALAMAN MOTTO

~ Kesuksesan berasal dari 99% usaha dan 1% doa,~

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, me-ngalihkan 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

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.

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.

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.

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

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. Pengertian Clustering ... 8

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

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

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

DAFTAR TABEL

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

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

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

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

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

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

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.

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

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

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

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

.

Gambar 2

.

2 Arsitektur umum Linux Virtual Server

Load balancer bertindak sebagai pintu akses setiap request kepada

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 [image:30.595.84.514.184.649.2]

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

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

[image:31.595.84.512.202.641.2]

balancer.

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

[image:32.595.83.515.227.695.2]

dan load balancer

.

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 [image:33.595.85.510.195.654.2]

berbeda dari load balancer

.

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 masing-masing server dalam menangani request.

2.3.4.2. Weighted Round Robin (wrr)

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

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)

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)

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

berbeda-beda,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

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

[image:39.595.82.512.201.635.2]

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

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

,

[image:40.595.84.516.217.639.2]

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

[image:41.595.83.515.197.629.2]

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

[image:42.595.86.513.197.685.2]

internet.

Gambar 3.1 Konfigurasi 2 server

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

[image:43.595.88.509.219.611.2]

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

Load Balancer

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

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

[image:44.595.83.515.149.630.2]

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

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

Gambar 3.2 Setting pengujian pada Webserver

[image:46.595.84.513.111.635.2]

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

[image:47.595.86.513.111.637.2]

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.

digunakan untuk mengomparasi kesepuluh algoritma untuk dilihat mana algoritma terbaik yang memberikan waktu respon lebih cepat daripada algoritma lainnya.

[image:48.595.85.513.239.616.2]

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

= AVERAGE (B2:B60)

Untuk pengujian ini, web server menggunakan Apache Web Server. Web server ini akan diisi dengan konten berupa halaman web lomba SadharBlog.

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

# sudo nano /etc/apache2/sites-available/default

[image:51.595.85.524.202.704.2]

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 :

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_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 :

Atau jika tidak ada koneksi internet

,

dapat di-install manual dengan

terlebih dahulu men-download ipvsadm dalam format [

.

deb]

.

Package

di-install 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

# 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

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

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

[image:58.595.84.518.225.619.2]

algoritma lainnya.

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

1.49 _{1.48 1.48}

1.55

1.47 1.61

1.56

1.51 _1.50 1.53

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.

server menjadi lebih cepat overload dengan adanya 200 user yang mencoba

[image:60.595.80.513.175.623.2]

terkoneksi secara bersamaan.

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.

3.26 3.30 3.24 3.21 3.57 3.20

4.13 4.04

[image:61.595.84.513.110.625.2]

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

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

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.

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

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/LVS-HOWTO/HOWTO/LVS-HOWTO.ipvsadm.html#DH (Tanggal akses : 28

LAMPIRAN

1. Raw data

1.1. 100 user

 Round Robin

1.2. 200 user