IMPLEMENTASI DAN EVALUASI KINERJA LOAD BALANCING PADA SERVER-SERVER PROXY DI IPB. Oleh : DAVID THAMRIN G

(1)

IMPLEMENTASI DAN EVALUASI KINERJA LOAD BALANCING PADA

SERVER-SERVER PROXY DI IPB

Oleh :

DAVID THAMRIN

G64103002

DEPARTEMEN ILMU KOMPUTER

FAKULTAS MATEMATIKA DAN ILMU PENGETAHUAN ALAM

INSTITUT PERTANIAN BOGOR

BOGOR

2008

(2)

Hidup adalah sebuah tantangan, maka hadapilah.

Hidup adalah sebuah lagu, maka nyanyikanlah.

Hidup adalah sebuah mimpi, maka sadarilah.

Hidup adalah sebuah permainan, maka mainkanlah.

Hidup adalah cinta, maka nikmatilah.

(Bhagawan Sri Sthya Sai Baba)

To exist is to change

to change is to mature

to mature is to go on creating oneself endlessly

(Henry Bergson)

Ilmu sendiri tidaklah punya nilai. PENGGUNAAN ILMU itulah yang

membuatnya bernilai. Bila pemikiran ini diungkapkan dengan cara lain –

Hidup tidak membayar anda atas apa yang dapat anda lakukan.

Hidup membayar anda atas apa yang anda lakukan.

(Les Giblin)

I know the price of success: dedication, hard workd and an unremitting devotion

to the things you want to see happen

(Frank Lloyd Wright)

Keberhasilan tidak diukur dengan apa yang telah anda raih, namun kegagalan

yang telah anda hadapi, dan keberanian yang membuat anda tetap berjuang

melawan rintangan yang datang bertubi-tubi.

(Orison Swett Marden)

There are two kinds of failures:

Those who thought and never did and those who did and never thought

(Laurence J. Peter)

Urusan kita dalam kehidupan ini bukanlah untuk mendahului orang lain, tetapi

untuk melampaui diri kita sendiri, untuk memecahkan rekor kita sendiri, dan

untuk melampaui hari kemarin dengan hari ini.

(Stuart B. Johnson)

I will praise you, LORD! You always do right.

I will sing about you, the LORD Most High

(Psalms 7:17)

(3)

IMPLEMENTASI DAN EVALUASI KINERJA LOAD BALANCING PADA

SERVER-SERVER PROXY DI IPB

Skripsi

sebagai salah satu syarat untuk memperoleh gelar Sarjana Komputer

pada Fakultas Matematika dan Ilmu Pengetahuan Alam

Institut Pertanian Bogor

Oleh :

David Thamrin

G64103002

DEPARTEMEN ILMU KOMPUTER

FAKULTAS MATEMATIKA DAN ILMU PENGETAHUAN ALAM

INSTITUT PERTANIAN BOGOR

BOGOR

2008

(4)

ABSTRAK

DAVID THAMRIN. Implementasi dan Evaluasi Kinerja Load Balancing pada Server-server Proxy di IPB. Dibimbing oleh HERU SUKOCO dan ENDANG PURNAMA GIRI.

Pertumbuhan internet dewasa ini menuntut lebih banyak server yang melayani permintaan pengguna. Pembagian kerja yang tidak adil dapat membuat sumber daya menjadi tidak efektif dan kinerja menjadi rendah. IPB memiliki dua buah server proxy yang melayani seluruh permintaan pengguna ke internet. Selama ini pembagian kerja antara kedua server dilakukan berdasarkan kebijakan sehingga dikhawatirkan tidak berjalan optimal.

Penelitian ini akan mengimplementasikan mekanisme load balancing agar pembagian beban menjadi adil antara dua buah server proxy IPB. Selain itu, implementasi diharapkan dapat meningkatkan realibilitas, skalabilitas, dan availabilitas server proxy.

Studi pustaka dan analisis lingkungan jaringan IPB digunakan sebagai dasar untuk menentukan berbagai aspek dalam load balancing. Metode yang digunakan adalah dedicated load

balancing dengan software. Load balancing diterapkan pada level IP memanfaatkan perangkat

lunak LVS dengan metode distribusi direct routing. Aplikasi keepalived dimanfaatkan untuk pengecekan kesehatan dan director failover. Spesifikasi server proxy yang berbeda menjadi dasar penggunaan algoritme penjadwalan weighted round robin. Pembobotan ditentukan dengan sistem

tuning, beberapa variasi pembobotan diimplementasikan untuk memilih yang paling baik. Sebelum

dan setelah implementasi, dilakukan pengukuran data kinerja server proxy yang meliputi utilisasi CPU, penggunaan memori, throughput, jumlah koneksi, dan hit ratio. Kinerja load balancing kemudian diukur dari cumulative density function (CDF) dan standar deviasi (SD) utilisasi CPU.

Hasil penelitian menunjukkan bahwa implementasi mekanisme load balancing terbukti dapat meningkatkan realibilitas, skalabilitas, dan availabilitas server proxy di IPB. Beban kerja dapat dibagi secara proporsional berdasarkan beban trafik, tanpa perlu kebijakan. Diketahui pula bahwa pembobotan mekanisme load balancing yang paling baik untuk diterapkan di sistem operasional server proxy IPB adalah 1:2 karena menghasilkan standar deviasi utilisasi CPU yang paling kecil yaitu 5.26. Hit ratio setelah implementasi load balancing secara keseluruhan mengalami peningkatan sekitar 4%.

(5)

ABSTRACT

DAVID THAMRIN. Implementation and Performance Evaluation of Load Balancing on IPB Proxy Servers. The research are supervised by HERU SUKOCO and ENDANG PURNAMA GIRI.

The explosive growth of Internet demand more servers to serve all the client requests. Unbalance workload distribution can make ineffective used of processing resource and degrade performance. IPB has two proxy servers which serve all client request to the internet. Since now, the workload distribution of both servers is done according to IPB policy so that it is doubtfully has optimal performance.

This research implements load balancing mechanism so that the workload distribution can be balance between two proxy servers of IPB. Besides that, the implementation is intended to improve reliability, scalability and availability of proxy server.

Literature study and analyisis of IPB networking environment is used as basis to determine various aspects of load balancing. The method used is dedicated load balancing using software. Load balancing is implemented at IP level using LVS software with direct routing forwarding method. Keepalived application is used to give healthchecking and director failover feature. The differences of proxy server specification suggesting weighted round robin scheduling algorithm to be used. The weight is determined by tuning system, variation of weight is implemented to find the best performance. Before and after the implementation, performance of proxy server is measured. The measure includes CPU utilization, memory utilization, throughput, total connection, and hit ratio. Load balancing performance is then measured by cumulative density function (CDF) and standard deviation.

The result of the research show that implementation of load balancing mechanism has been proven to improve reliability, scalability, and availability of IPB proxy server. Workload can be distributed proportionally according to the traffic load, no more policy. The result also shows that the best weight to implement in operational system of IPB proxy server is 1:2. It is because that weight gives the smallest standard deviation which is 5.26. Hit ratio after implementation of load balancing has improved approximately 4%.

(6)

Judul

: Implementasi dan Evaluasi Kinerja Load Balancing pada Server-server

Proxy di IPB

Nama

: David Thamrin

NRP :

G64103002

Menyetujui

Pembimbing I,

Heru Sukoco S.Si., M.T

NIP 132 282 666

Pembimbing II,

Endang Purnama Giri, S.Kom

NIP 132 321 639

Mengetahui:

Dekan Fakultas Matematika dan Ilmu Pengetahuan Alam

Institut Pertanian Bogor

Dr. Drh. Hasim, DEA

NIP 131578806

(7)

RIWAYAT HIDUP

Penulis dilahirkan di Lubuklinggau pada tanggal 23 Desember 1985 dari ayah Tjarsan Thamrin dan ibu Maria Magdalena. Penulis merupakan putra kedua dari empat bersaudara.

Tahun 2003 penulis lulus dari SMU Xaverius Lubuklinggau dan pada tahun yang sama lulus seleksi masuk IPB melalui jalur Undangan Seleksi Masuk IPB. Penulis memilih Program Studi Ilmu Komputer, Departemen Ilmu Komputer, Fakultas Matematika dan Ilmu Pengetahuan Alam.

Selama mengikuti perkuliahan, penulis aktif dalam berorganisasi, di antaranya menjadi ketua Unit Kegiatan Mahasiswa (UKM) Keluarga Mahasiswa Katolik IPB (KEMAKI) tahun kepengurusan 2006/2007, anggota Beswan Djarum tahun 2005-2007, dan anggota Perhimpunan Mahasiswa Katolik Indonesia (PMKRI). Penulis juga pernah menjadi asisten praktikum mata kuliah Organisasi Komputer, Bahasa Pemrograman, Fisika Dasar, dan Agama Katolik. Pada tahun 2006 Penulis menjalankan praktek lapangan di PT. Nusantara Compnet Integrator di Jakarta selama kurang lebih 2 bulan.

(8)

PRAKATA

Puji dan syukur penulis panjatkan kepada Allah Bapa Yang Maha Pengasih yang telah melimpahkan rahmat dan karunia-Nya sehingga penulis dapat menyelesaikan tugas akhir yang merupakan salah satu syarat kelulusan program sarjana pada Departemen Ilmu Komputer, Fakultas Matematika dan Ilmu Pengetahuan Alam, Institut Pertanian Bogor.

Terima kasih kepada orangtua tercinta, Papa Tjarsan Thamrin dan Mama Maria Magdalena yang curahan kasihnya selalu mengalir tanpa henti buat penulis, juga untuk dukungan, semangat, bimbingan, dan doa demi keberhasilan dan kesuksesan hidup penulis. Untuk saudara-saudari tercinta, Benny Thamrin, Indra Thamrin, dan Ferina Thamrin yang selalu dekat di hati penulis, terima kasih telah mengiringi gerak langkah penulis dengan dukungan dan semangat.

Untuk Fransiska Eka Handayani, kekasih yang selalu setia menemani penulis dalam masa-masa penuh keceriaan pun dalam masa-masa kekelaman. Terima kasih karena selalu sedia untuk menghibur ketika sedih, memberi semangat ketika lesu, mendengarkan semua keluh kesah, menerima semua masalah penulis. Terima kasih untuk semua cinta kasih dan perhatian yang telah diberikan. Terima kasih telah menjadi pemberi warna, rasa, dan asa dalam hidup penulis.

Penulis juga mengucapkan terima kasih kepada Bapak Heru Sukoco selaku pembimbing I yang telah banyak berbagi ilmu pengetahuannya dan memberikan pengarahan kepada penulis. Terima kasih juga penulis ucapkan kepada Bapak Endang Purnama Giri selaku pembimbing II yang telah banyak memberi masukan dan pengarahan kepada Penulis. Penulis juga ingin mengucapkan terima kasih kepada Ibu Ir. Sri Wahjuni yang telah bersedia menjadi moderator dan penguji.

Terima kasih kepada Mas Hassan, Mas Komar, dan Mas Imanto di KPSI yang telah banyak membantu penulis selama melaksanakan penelitian. Juga kepada Pak Djatmiko di Ilkom, dan Mas Sujiwo di perpustakaan yang banyak membantu dalam tahapan penelitian penulis. Penulis juga mohon maaf jika telah merepotkan dan mengganggu pekerjaan kalian.

Kepada segenap Ilkomerz 40, terima kasih karena telah menjadi teman-teman seperjuangan selama penulis menimba ilmu di IPB. Terima kasih khususnya untuk Naniq Qodarsih, Irena Susanti, Andi Setiadi, dan Ghoffar yang telah memberi banyak masukan bagi penelitian penulis. Untuk Rizal Ansyori, Faiq Al Syawaf, dan Gallan Saputra Aji, teman-teman penulis di lab NCC atas kebersamaan dan dukungannya.

Terima kasih juga ingin penulis sampaikan kepada teman-teman penulis di Tim Pendamping IPB dan Keluarga Mahasiswa Katolik IPB (KEMAKI). Keberadaan kalian semua sungguh merupakan penyemangat dalam hidup penulis. Terima kasih atas kebersamaannya sebagai sebuah keluarga.

Tak lupa terima kasih kepada Departemen Ilmu Komputer, staf dan dosen yang telah begitu banyak membantu baik selama penelitian maupun pada masa perkuliahan. Khususnya kepada Pak Pendi dan Pak Soleh untuk urusan peminjaman kunci lab NCC, kepada Mas Irvan di perpustakaan Ilkom atas bantuan pustakanya, kepada Pak Fathur dan Pak Yadi untuk masalah surat menyurat.

Semua pihak yang tidak dapat penulis sebutkan satu persatu, terima kasih atas semua dukungannya selama masa perkuliahan dan pengerjaan skripsi ini.

Semoga penelitian ini dapat memberikan manfaat.

Bogor, Januari 2008

(9)

DAFTAR ISI

Halaman

DAFTAR ISI ... viii

DAFTAR TABEL ... ix

DAFTAR GAMBAR ... x

DAFTAR LAMPIRAN ... xi

PENDAHULUAN ... 1 Latar Belakang ... 1 Tujuan... 1 Ruang Lingkup ... 1 Manfaat Penelitian ... 1 TINJAUAN PUSTAKA ... 1 Load Balancing ... 1 Server Proxy ... 2

Metode Load Balancing ... 2

Level Load Balancing ... 2

Virtual Server & Linux Virtual Server ... 2

IP Virtual Server (IPVS) ... 3

Forwarding Method ... 3

Keunggulan dan Kelemahan Metode-Metode Distribusi Paket LVS ... 3

Algoritme Load Balancing ... 4

Weighted Round Robin ... 4

Keepalived ... 4

Virtual Router Redundancy Protocol (VRRP) ... 5

Ipvsadm ... 5

Rekomendasi ITU-T E.500 ... 5

Throughput ... 5

Hit Ratio ... 5

Address Resolution Protocol (ARP) ... 5

Single Point of Failure (SPOF) ... 5

METODOLOGI PENELITIAN ... 5

1. Studi pustaka ... 6

2. Analisis lingkungan jaringan IPB ... 6

3. Pengambilan data kinerja server proxy sebelum penerapan mekanisme load balancing ... 7

4. Analisis dan pemilihan berbagai aspek load balancing ... 8

5. Implementasi mekanisme load balancing. ... 9

6. Pengambilan data kinerja server proxy setelah penerapan mekanisme load balancing. ... 11

7. Analisis kinerja ... 11

HASIL DAN PEMBAHASAN ... 12

Data kinerja server proxy di IPB sebelum penerapan mekanisme load balancing ... 12

Pengujian Tahap Implementasi ... 14

Data kinerja server proxy di IPB setelah penerapan mekanisme load balancing ... 14

Analisis Kinerja ... 19

KESIMPULAN DAN SARAN ... 21

Kesimpulan ... 21

Saran ... 21

(10)

DAFTAR TABEL

Halaman 1 Hasil perhitungan SD utilisasi CPU. ... 20

(11)

DAFTAR GAMBAR

Halaman

1 Mekanisme load balancing. ... 1

2 Server proxy. ... 2

3 Virtual server. ... 2

4 Virtual server dengan direct routing. ... 3

5 Alur kerja direct routing. ... 3

6 Arsitektur perangkat lunak keepalived (Sumber: Cassen 2002). ... 4

7 Metodologi penelitian. ... 5

8 Topologi jaringan IPB. ... 6

9 Topologi jaringan director dan ... 10

10 Arsitektur LVS di IPB. ... 10

11 Utilisasi CPU 4 Desember 2007. ... 12

13 Utilisasi memori 4 Desember 2007. ... 12

15 Throughput 4 Desember 2007. ... 13

16 Throughput 5 Desember 2007. ... 13

17 Jumlah koneksi sebelum implementasi mekanisme load balancing. ... 13

18 Hit ratio sebelum implementasi mekanisme load balancing. ... 13

19 Throughput pada saat salah satu server proxy dinonaktifkan. ... 14

20 Perbandingan utilisasi CPU director sebelum dan sesudah implementasi load balancing. ... 14

25 Utilisasi CPU 2 Januari 2008. ... 15

33 Utilisasi memori 2 Januari 2008. ... 17

37 Throughput 18 Desember 2007. ... 17 38 Throughput 19 Desember 2007. ... 18 39 Throughput 27 Desember 2007. ... 18 40 Throughput 29 Desember 2007. ... 18 41 Throughput 2 Januari 2008. ... 18 42 Throughput 3 Januari 2008. ... 18 43 Throughput 4 Januari 2008. ... 18 44 Throughput 7 Januari 2008. ... 18

45 Jumlah koneksi setelah implementasi mekanisme load balancing. ... 19

46 Hit ratio setelah implementasi mekanisme load balancing. ... 19

47 CDF utilisasi CPU. ... 20

48 SD utilisasi CPU. ... 20

49 SD utilisasi memori. ... 21

(12)

DAFTAR LAMPIRAN

Halaman

1 Contoh data utilisasi cpu pada server proxy di IPB... 24

2 Contoh data penggunaan memori pada server proxy di IPB ... 25

3 Contoh data throughput server proxy dari CTM ... 26

4 Contoh data pada akses log server proxy ... 27

5 Langkah implementasi mekanisme load ,balancing pada server proxy di IPB ... 28

6 Grafik utilisasi CPU sebelum implementasi mekanisme load balancing ... 33

7 Grafik utilisasi memori sebelum implementasi mekanisme load balancing ... 35

8 Grafik throughput sebelum implementasi mekanisme load balancing ... 37

9 Tabel hasil perhitungan jumlah koneksi, jumlah hit dan hit ratio ... 39

10 Contoh tabel perhitungan CDF pada saat pembobotan 1:1 ... 40

11 Contoh tabel perhitungan SD pada saat pembobotan 1:2 ... 41

(13)

PENDAHULUAN

Latar Belakang

Sejalan dengan pertumbuhan internet yang demikian eksplosif dan peranannya yang semakin penting dalam kehidupan kita, jumlah trafik di internet turut meningkat secara dramatis. Beban kerja pada server meningkat dengan cepat sehingga server dapat menjadi kelebihan beban dalam waktu yang singkat.

Masalah kelebihan beban dapat diatasi dengan dua solusi. Solusi pertama adalah solusi satu server, yaitu dengan meningkatkan kualitas atau kecanggihan sebuah server, misalnya dengan meng-upgrade cpu dan atau menambah memori. Solusi ini dinilai tidak skalabel karena ketika kebutuhan (beban) meningkat, kita harus melakukan upgrade kembali, padahal upgrade terus-menerus membutuhkan biaya yang tinggi, dan

downtime mungkin akan sering terjadi. Jalan

keluar yang lebih baik adalah solusi banyak server, yaitu membangun sistem layanan jaringan yang skalabel dengan lebih dari satu server. Ketika beban bertambah, kita dapat dengan mudah menambah server baru untuk memenuhi kebutuhan.

Para ahli berpendapat bahwa menggunakan dua atau lebih server dengan harga dan kualitas rata-rata seringkali jauh lebih efektif dan menguntungkan daripada hanya menggunakan sebuah server mahal yang berkinerja tinggi.

Namun solusi banyak server ternyata juga bukan tanpa masalah. Masalah utama yang dapat timbul adalah pembagian beban yang tidak merata. Untuk mengatasi hal tersebut, perlu diterapkan mekanisme load balancing.

Di IPB sendiri terdapat dua buah server proxy. Dari hasil penelitian Nanik Qodarsih yang berjudul Perencanaan Kapasitas untuk Kinerja Web dan Proxy Server IPB Menggunakan Model Open Queueing Network M/M/2 dan M/M/1 diperoleh kesimpulan bahwa kondisi salah satu server proxy di IPB berada pada level tertinggi, karena penggunaan sumber daya terbesar lebih dari 70%. Hal ini terjadi karena pembagian beban kerja yang tidak merata. Teknik load balancing diharapkan dapat mengatasi masalah tersebut.

Tujuan

Tujuan dari penelitian ini adalah:

1 mempelajari dan memahami berbagai aspek dalam load balancing,

2 mengimplementasikan mekanisme load

balancing pada server proxy di IPB, dan

3 menganalisis perbaikan kinerja server sebelum dan sesudah penerapan mekanisme load balancing.

Ruang Lingkup

Penelitian ini akan menerapkan salah satu metode load balancing yang dinilai paling sesuai untuk digunakan di IPB. Kinerja server sebelum dan sesudah penerapan mekanisme

load balancing akan diukur untuk melihat

apakah terjadi perbaikan.

Manfaat Penelitian

Manfaat yang diharapkan dari penelitian ini adalah:

1 beban kerja server proxy terbagi secara adil berdasarkan beban trafik, bukan berdasarkan kebijakan, dan

2 mampu meningkatkan reliabilitas, skalabilitas, dan availabilitas server proxy di IPB.

TINJAUAN PUSTAKA

Load Balancing

Secara harafiah, load balancing artinya adalah pembagian beban (load) menjadi seimbang (balance) (PCMedia 2004).

Menurut Balasubramanian et al. (2004),

load balancing adalah suatu teknik untuk

memanfaatkan sumber daya pengolahan yang tersedia secara lebih efektif dengan cara membagi pekerjaan berdasarkan strategi pembagian tertentu.

Ketika sebuah server sedang diakses oleh para pengguna, maka server tersebut sebenarnya sedang dibebani karena harus melakukan proses terhadap permintaan para penggunanya. Jika penggunanya banyak, maka proses yang dilakukan juga menjadi banyak.

(14)

Server Proxy

Server proxy adalah server yang berada di antara proses pengguna dan proses server. Bagi pengguna, proxy tampak sebagai server, sedangkan bagi server, proxy tampak sebagai pengguna. Oleh karena proxy mengimitasi pengguna dan juga server, proxy harus memiliki aplikasi yang tertanam didalamnya. Salah satu hal yang mungkin dilakukan oleh proxy adalah mengimplementasikan cache (Peterson 2003).

Menurut Wagito (2005), server proxy mempunyai dua macam manfaat yaitu meningkatkan kinerja jaringan dan sebagai filter permintaan. Gambar 2 menunjukkan diagram server proxy pada umumnya.

Gambar 2 Server proxy.

Metode Load Balancing

Secara garis besar, cara pembuatan sistem

load balancing terbagi menjadi tiga kategori

besar yaitu:

1. DNS Round Robin

Domain Name System (DNS) merupakan

sebuah sistem penamaan terhadap perangkat komputer. Penamaan ini dibuat berdasarkan alamat IP dari perangkat tersebut. DNS dapat dimanfaatkan untuk membagi request pada server yang berbeda dengan cara mengubah nama domain menjadi alamat IP yang berlainan.

2. Integrated load balancing

Integrated load balancing merupakan

solusi load balancing tambahan dari sebuah aplikasi atau sistem operasi, misalnya yang terdapat pada Microsoft Windows 2000 Advance Server.

3. Dedicated load balancing

Dedicated load balancing adalah sistem

load balancing yang sesungguhnya

karena kerja dan prosesnya secara total

diperuntukan bagi proses load balancing terhadap server atau jaringan di bawahnya. Metode ini dibagi lagi menjadi:

• Load balancing dengan hardware atau

switch

• Load balancing dengan software

• Load balancing dengan perangkat perpaduan hardware dan software

Level Load Balancing

Sistem load balancing yang dikenal terdiri dari dua level yaitu load balancing level aplikasi dan load balancing level IP. Load

balancing level aplikasi melakukan

pengecekan terhadap layer 7 (aplikasi) pada sistem layer OSI (Open System

Interconnection) sebelum data diteruskan

kepada server sebenarnya. Load balancing level IP hanya melakukan pengecekan hingga layer 4 (transport) (Wensong 2002).

Virtual Server & Linux Virtual Server

Virtual server adalah server dengan

skalabilitas dan availabilitas tinggi yang dibangun pada sekelompok server sesungguhnya (realserver). Arsitektur dari

virtual server bersifat transparan terhadap

pengguna. Pengguna seolah-olah berinteraksi hanya dengan sebuah server, padahal sesungguhnya ada dua atau lebih server yang memberi layanan. Virtual server diakses oleh pengguna melalui alamat IP virtual. Ilustrasi dari virtual server dapat dilihat pada Gambar 3.

Gambar 3 Virtual server.

Skalabilitas dari sistem diperoleh dengan cara menambah atau mengurangi jumlah

realserver secara transparan. Availabilitas

yang tinggi disediakan melalui pendeteksian kesehatan node dan konfigurasi ulang sistem secara tepat.

(15)

Linux virtual server adalah virtual server yang menggunakan Linux sebagai sistem operasinya (Wensong 2002).

IP Virtual Server (IPVS)

IPVS mengimplementasikan load

balancing layer transport di dalam kernel

Linux, sehingga disebut juga layer 4

switching. IPVS berjalan pada komputer host

yang bertindak sebagai load balancer

(director) di depan sekelompok server yang

sesungguhnya. IPVS dapat mengarahkan permintaan layanan TCP/UDP kepada

realserver dan membuat layanan dari

beberapa realserver terlihat sebagai layanan virtual pada sebuah alamat IP (Wensong 2002).

Forwarding Method

LVS mengenal tiga metode untuk mendistribusikan paket dari pengguna ke

realserver. Ketiga metode tersebut adalah Network Address Translation (NAT), Direct Routing (DR) dan Tunneling (TUN) atau

disingkat NAT, DR, dan LVS-TUN (Wensong 2002).

Pada metode LVS-NAT, header paket yang dikirim pengguna akan ditulis ulang oleh

director. Director harus menjadi default gateway dari server asli agar metode

LVS-NAT dapat berjalan dengan baik. Setiap respon dari server asli akan kembali ke pengguna melalui director.

Metode LVS-TUN menggunakan enkapsulasi IP. Paket yang ditujukan kepada

virtual server akan dienkaspsulasi dalam

paket yang lain, kemudian diarahkan kepada salah satu dari server asli. Pada metode ini, paket respon dari server asli tidak harus melalui director untuk kembali ke pengguna.

Pada metode LVS-DR, setiap server asli juga dapat mengirimkan paket respon langsung kepada pengguna, tanpa harus

melalui director. Setiap node dalam cluster diberikan alamat IP dari virtual server (VIP), namun hanya director yang dibolehkan untuk merespon permintaan address resolution

protocol (ARP). Gambar 4 memberikan

ilustrasi virtual server dengan direct routing dan Gambar 5 menunjukkan alur kerja direct

routing.

Keunggulan dan Kelemahan Metode-Metode Distribusi Paket LVS

• Keunggulan

LVS-NAT: berjalan pada sistem operasi apapun yang memiliki dukungan TCP/IP;

Realserver dapat menggunakan alamat IP

privat.

LVS-TUN: memiliki skalabilitas yang lebih baik daripada LVS-NAT; server mengembalikan paket langsung kepada pengguna; server dapat berada pada jaringan yang berbeda dari director.

LVS-DR: memiliki skalabilitas yang lebih baik daripada LVS-NAT; director hanya menangani koneksi dari pengguna ke server (setengah koneksi); tidak mempunyai

overhead IP tunneling.

• Kelemahan

LVS-NAT: memiliki skalabilitas yang rendah; director dapat menjadi bottleneck karena paket harus melaluinya pada kedua arah.

LVS-TUN: sistem oprerasi server harus mendukung IP-tunneling; terdapat overhead untuk enkapsulasi IP; sistem operasi server harus dapat menonaktifkan ARP pada antarmuka jaringan.

LVS-DR: director dan pengguna harus berada pada segmen jaringan yang sama; sistem operasi server harus dapat menonaktifkan ARP pada antarmuka jaringan.

Gambar 4 Virtual server dengan direct

(16)

Gambar 6 Arsitektur perangkat lunak keepalived (Cassen 2002).

Algoritme Load Balancing

Algoritme pembagian beban (penjadwalan) yang dikenal saat ini diantaranya:

• Round-Robin Scheduling

• Weighted Round-Robin Scheduling • Least-Connection Scheduling

• Weighted Least-Connection Scheduling • Locality-Based Least-Connection

Scheduling

• Locality-Based Least-Connection with

Replication Scheduling

• Destination Hashing Scheduling • Source Hashing Scheduling

• Shortest Expected Delay Scheduling • Never Queue Scheduling

Weighted Round Robin

Penjadwalan weighted round-robin

didesain untuk mengelola server yang memiliki perbedaan kemampuan pemrosesan. Setiap server dapat diberikan bobot, yaitu sebuah nilai integer yang mengindikasikan kemampuan pemrosesan. Server dengan bobot lebih tinggi menerima koneksi lebih dahulu daripada server dengan bobot yang lebih rendah. Server dengan bobot tinggi menerima koneksi lebih banyak daripada server dengan bobot rendah, dan apabila bobotnya sama, jumlah koneksi yang diterima juga sama.

Pseduo code dari algoritme penjadwalan

weighted round-robin adalah sebagai berikut: Misalkan terdapat himpunan server S = {S0, S1, …, Sn-1};

W(Si) adalah bobot dari Si;

i adalah server yang dipilih

terakhir kali, dan i diinisialisasi dengan -1;

cw adalah bobot saat ini dalam

penjadwalan, dan cw diinisialisasi dengan nol;

max(S) adalah bobot maksimum dari seluruh server dalam S;

gcd(S) adalah faktor persekutuan terbesar dari semua bobot server dalam S; while (true) { i = (i + 1) mod n; if (i == 0) { cw = cw - gcd(S); if (cw <= 0) { cw = max(S); if (cw == 0) return NULL; } } if (W(Si) >= cw) return Si; }

Sebagai contoh, terdapat server A, B and C, dengan bobot masing-masing 4, 3, dan 2. Urutan penjadwalan akan menjadi AABABCABC dalam satu periode.

Keepalived

Keepalived adalah perangkat lunak yang mendukung kinerja dari linux virtual server. Keepalived melakukan pengecekan TCP/IP multilayer terhadap realserver untuk mengetahui kesehatan dari realserver tersebut. Apabila ada realserver yang mati, keepalived akan mengirim informasi kepada kernel linux untuk menghapus realserver tersebut dari daftar dalam topologi LVS. Pada saat

realserver tersebut berfungsi kembali,

keepalived akan memasukkannya kembali ke dalam sistem operasional.

(17)

Keepalived juga mengimplementasikan stack VRRPv2 yang independen untuk mengelola pergantian director jika terjadi kesalahan. Keepalived dapat digunakan secara bebas dan gratis karena menggunakan lisensi GNU general public license (GPL). Arsitektur perangkat lunak keepalived dapat dilihat pada Gambar 6.

Virtual Router Redundancy Protocol (VRRP)

Virtual router redundancy protocol adalah

protokol yang dikembangkan oleh IETF (Internet Engineering Task Force).

VRRP membolehkan beberapa router pada hubungan multi-akses untuk menggunakan alamat IP virtual yang sama. Sebuah router akan dipilih sebagai master dan router yang lain berperan sebagai backups (cadangan) apabila router master mengalami kerusakan. (RFC 3768).

Ipvsadm

Ipvsadm adalah antarmuka pengguna untuk IPVS. Ipvsadm dapat digunakan untuk menambah atau mengurangi layanan load

balancing, mengatur pembobotan,

menjalankan atau menghentikan layanan, serta berbagai fungsi lainnya. Ipvsadm juga sangat sesuai digunakan untuk debugging (Mack 2007).

Rekomendasi ITU-T E.500

ITU (International Telecommunication

Union) adalah agen khusus United Nation

(PBB) di bidang telekomunikasi. ITU

Telecommunication Standardization Sector

(ITU-T) adalah bagian permanen dari ITU. ITU-T bertanggung jawab dalam pembelajaran terhadap masalah teknis, pengoperasian, tariff questions dan

menerbitkan rekomendasi. Tujuan ITU-T adalah untuk melakukan standardisasi telekomunikasi di seluruh dunia.

Rekomendasi ITU-T E.500 menjelaskan tentang konsep intensitas trafik dan metodologi pengukuran intensitas trafik. Rekomendasi ini memberikan prinsip-prinsip untuk mengukur trafik dari suatu jaringan. Pengukuran yang dilakukan berdasar Rekomendasi ITU-T E.500 adalah daily

continuous measurement. Daily continuous measurements direkomendasikan untuk dilakukan secara kontinu selama beberapa hari dengan periode waktu pengukuran tertentu (ITU 2007).

Throughput

Throughput sebuah sistem didefinisikan

sebagai ukuran sebenarnya dari informasi yang dikirimkan melalui suatu saluran.

Throughput dapat diukur dalam satuan bits/second atau packet/second (Garcia 2004).

Hit Ratio

Hit ratio adalah persentase dari semua request yang dapat dilayani oleh cache pada

server proxy dibandingkan dengan seluruh koneksi yang diterima (PCMag 2008).

Address Resolution Protocol (ARP)

ARP adalah protokol internet yang digunakan untuk memetakan alamat IP kepada alamat MAC (Media Access Control). ARP didefinisikan pada RFC 826 (Cisco 2003)

Single Point of Failure (SPOF)

Single point of failure adalah sebuah titik (server, hub, kabel, router) yang menghubungkan satu atau lebih peralatan jaringan. Apabila titik perhubungan ini rusak, satu atau lebih workstation akan kehilangan konektivitas jaringan (Anonymous 2007).

METODOLOGI PENELITIAN

Langkah-langkah penelitian yang dilaksanakan adalah sebagai berikut:

Gambar 7 Metodologi penelitian. Studi Pustaka

Analisis lingkungan jaringan IPB

Pengambilan data kinerja server proxy di IPB sebelum penerapan

mekanisme load balancing

Analisis dan pemilihan berbagai aspek load balancing

Implementasi mekanisme load balancing

Pengambilan data kinerja server proxy di IPB setelah penerapan

mekanisme load balancing.

(18)

Beberapa langkah pada metodologi penelitian ini merujuk pada/ bersesuaian dengan metodologi perencanaan kapasitas oleh Menascé & Almeida (1998).

1. Studi pustaka

Pada tahap ini, dilakukan pengumpulan informasi mengenai metode dan algoritme

load balancing serta berbagai hal yang terkait

dengan mekanisme load balancing. Sumber pustaka berupa buku tentang jaringan, jurnal maupun artikel di internet.

2. Analisis lingkungan jaringan IPB Untuk menentukan mekanisme load

balancing yang paling sesuai untuk diterapkan

berdasarkan situasi nyata, dibutuhkan pengetahuan tentang jaringan IPB antara lain:

• Perangkat keras (server proxy)

• Perangkat lunak (sistem operasi, aplikasi)

IPB memiliki dua buah server proxy dengan alamat IP 172.17.0.11 dan 172.17.0.18. Selama ini, kedua server proxy tersebut memberikan layanan untuk pengguna internal yang berbeda. Server proxy dengan alamat IP 172.17.0.11 melayani permintaan pengguna di sekitar rektorat dan KPSI, juga empat fakultas di IPB yaitu Fakultas Peternakan (Fapet), Fakultas Kedokteran Hewan (FKH), Fakultas Kehutanan (Fahutan) dan Fakultas Ekonomi dan Manajemen (FEM). Server proxy dengan alamat IP 172.17.0.18 melayani permintaan pengguna di

Fakultas Pertanian (Faperta), Fakultas Perikanan (FPIK), Fakultas Teknologi Pertanian (Fateta), dan Fakultas Matematika dan Ilmu Pengetahuan Alam (FMIPA). Gambar 8 menunjukkan topologi jaringan IPB.

Pembagian layanan yang dilakukan berdasarkan kebijakan tersebut memungkinkan terjadinya perbedaan beban kerja yang harus ditanggung oleh kedua server proxy tersebut. Perbedaan ini dapat menyebabkan terjadinya penurunan kinerja pada server proxy yang memiliki beban trafik lebih besar, sedangkan server yang lainnya tidak dimanfaatkan secara optimal.

Analisis Spesifikasi Komputer yang Digunakan sebagai Server Proxy IPB

Spesifikasi komputer yang digunakan sebagai server proxy di IPB adalah sebagai berikut:

 Komputer server proxy IPB 1 (172.17.0.11)

• Sistem Operasi Linux Redhat Enterprise Edition versi 3.0.1 kernel 2.4.21

• Prosesor: Intel(R) Pentium(R) 4 CPU 1.5 GHz

• RAM 384 MB • Harddisk 40 GB • Server proxy Squid 2.5

(19)

 Komputer server proxy IPB 2 (172.17.0.18)

• Sistem Operasi Linux OpenSuse versi 10.0 kernel 2.6.13

• Prosesor: Intel(R) Pentium(R) 4 CPU 2.80 GHz

• RAM 1 GB • Harddisk 80 GB • Server proxy Squid 2.5

Dari data di atas, terlihat bahwa spesifikasi kedua buah server proxy memiliki perbedaan yang cukup signifikan, terutama dari segi prosesor dan ukuran memori fisik.

3. Pengambilan data kinerja server proxy sebelum penerapan mekanisme load balancing

Sebelum penerapan mekanisme load

balancing, dilakukan pengambilan data

kinerja server proxy. Pada tahap pengambilan data, digunakan teknik pengukuran sebagai berikut:

• Parameter kinerja yang akan diukur ditentukan terlebih dahulu. Pada penelitian ini, parameter yang akan diukur adalah utilisasi CPU, penggunaan memori,

throughput, jumlah koneksi dan hit ratio

pada masing-masing server proxy.

• Setelah diketahui parameter yang akan diukur, maka ditentukan perangkat lunak untuk memonitor kedua server proxy IPB, kemudian dilakukan pengumpulan data. Pada penelitian ini, utilisasi CPU dan penggunaan memori diperoleh dengan paket aplikasi sysstat yang diinstall pada masing-masing server proxy. Data tersebut diambil dengan koneksi Secure Shell (SSH) menggunakan perangkat lunak PuTTY. Contoh data utilisasi cpu dapat dilihat pada Lampiran 1 dan contoh data penggunaan memori dapat dilihat pada Lampiran 2. Data throughput diambil dari Converged Traffic Manager (CTM) dengan menggunakan browser Mozilla Firefox. Contoh data throughput dapat dilihat pada Lampiran 3. Jumlah koneksi dan hit ratio diperoleh dari data akses log server proxy yang diparsing menggunakan GAWK. Contoh data pada akses log dapat dilihat pada Lampiran 4.

Perangkat Keras dan Perangkat Lunak yang digunakan untuk Monitoring

Komputer yang digunakan untuk memonitoring kinerja server proxy adalah komputer lokal di lab Net Centric Computing

(NCC) Departemen Ilmu Komputer IPB, dengan alamat IP 172.18.78.60. Komputer ini memiliki spesifikasi prosesor Intel Pentium IV 2,4 GHz, memori 256 MB, harddisk 80 GB dan sistem operasi Windows XP Professional Edition. Perangkat lunak yang digunakan adalah sebagai berikut:

• Sar dan Sa1, adalah program yang terdapat dalam paket program sysstat yang berfungsi untuk memonitor kinerja sistem pada sistem operasi Linux, termasuk di dalamnya informasi tentang utilisasi cpu dan penggunaan memori. Program ini dapat menyimpan informasi tersebut ke dalam sebuah file log yang dapat diakses sesuai kebutuhan.

• Converged Traffic Manager (CTM) adalah peralatan jaringan yang mengintegrasikan fungsi monitoring trafik, manajemen trafik, kompresi dan caching. Penelitian ini hanya memanfaatkan fungsi monitoring dari CTM.

• PuTTY adalah implementasi dari telnet dan SSH untuk platform unix dan win32. PuTTY merupakan perangkat lunak bebas dan bersifat open source (Tatham 2008). • WinSCP (Windows Secure Copy) adalah

perangkat lunak open source yang berfungsi sebagai pengguna SFTP dan FTP pada sistem operasi Microsoft Windows. Fungsi utamanya adalah transfer file yang aman antara komputer lokal dan remote. WinSCP menggunakan Secure Shell (SSH) untuk melakukan transfer file dan mendukung protokol SCP (winscp.net 2007).

• GAWK adalah program untuk menginterpretasi bahasa pemrograman khusus. GAWK memudahkan kita mengelola data teks, mulai dari menambah, mengurangi, mengubah, hingga mengekstrak data. Dalam penelitian ini, GAWK digunakan untuk mengekstrak file log akses pada server proxy untuk memperoleh jumlah koneksi dan hit ratio.

• gnuplot adalah sebuah program plotting data dan fungsi yang sangat baik untuk menghasilkan grafik yang interaktif karena disertai script program yang dapat dimanipulasi oleh pengguna. Penelitian ini menggunakan gnuplot untuk membuat grafik hasil monitoring.

Mekanisme Pengambilan Data

Dasar mekanisme pengambilan data CPU dan memori pada server proxy IPB yang digunakan dalam penelitian ini adalah ITU-T

(20)

E.500. Pengukuran dilakukan selama 10 hari kerja. Hari kerja adalah hari Senin sampai Jumat dan tidak termasuk hari libur. Setiap harinya, data diambil pada jam kerja di IPB, yaitu pukul 08.00 hingga pukul 16.00. Dalam kurun waktu 8 jam tersebut, pengukuran dilakukan per 10 menit, sehingga terdapat 49 hasil pengukuran.

Pengambilan data throughput juga dilakukan selama 10 hari kerja. Data

throughput direkam pada keseluruhan hari

sejak pukul 00.00 hingga pukul 23.59. Interval pengukuran adalah setiap 5 menit sekali, yang menghasilkan 288 titik data dalam satu hari. Data throughput direkam pada keseluruhan hari untuk memberi gambaran yang lebih luas mengenai jumlah data yang mengalir melalui server proxy.

Data akses log juga diambil selama 10 hari. Data ini akan diparsing untuk memperoleh jumlah koneksi dan hit ratio pada masing-masing hari. Dalam penelitian ini, semua hasil pengukuran disimpan dalam bentuk file teks.

Data Parsing

Setelah dilakukan pengambilan data log akses (access.log) pada server proxy, akan dilakukan data parsing dengan menggunakan GAWK. Parsing dilakukan untuk mengubah format tanggal pada file access.log, kemudian memilahnya berdasarkan tanggal tertentu. Setelah data terbagi berdasarkan tanggal, parsing berikutnya dilakukan untuk mengkalkulasi jumlah koneksi dan jumlah hit dari masing-masing server proxy.

4. Analisis dan pemilihan berbagai aspek load balancing

Hasil dari tahap sebelumnya kemudian dianalisis untuk memilih beberapa aspek yang terkait dengan implementasi mekanisme load

balancing sebagai berikut:

• Metode load balancing • Level load balancing

• Perangkat lunak load balancing • Metode forwarding

• Algoritme penjadwalan • Pembobotan

Metode Load Balancing

IPB menginginkan solusi load balancing yang terjangkau dari segi biaya namun tetap memiliki performa yang baik. Berdasarkan hasil studi pustaka, metode load balancing yang memenuhi kriteria tersebut adalah metode dedicated load balancing dengan

software. Metode ini yang dipilih untuk

diimplementasikan karena metode ini jauh lebih murah daripada membeli sebuah perangkat load balancer khusus. Selain itu, metode ini juga memberikan fleksibilitas dalam hal perangkat keras dan perangkat lunaknya yang dapat diperbaharui dengan mudah.

Level Load Balancing

Pemilihan level load balancing mempertimbangkan overhead yang

ditimbulkan oleh setiap level. Load balancing level aplikasi menimbulkan overhead yang lebih tinggi karena harus melakukan pemrosesan hingga ke layer aplikasi.

Pada penelitian ini, load balancing diimplementasikan pada server proxy. Server proxy hanya perlu meneruskan permintaan dari pengguna tanpa perlu mengetahui isi dari permintaan tersebut. Atas dasar tersebut, level

load balancing yang dipilih untuk

diimplementasikan adalah level IP.

Perangkat Lunak Load Balancing

Perangkat lunak yang dipilih adalah Linux

Virtual Server (LVS) dan aplikasi

pendukungnya seperti ipvsadm, dan keepalived. LVS dipilih karena merupakan solusi load balancing yang telah stabil dan telah teruji reliabilitasnya. LVS memiliki skalabilitas dan availabilitas yang tinggi. LVS juga sudah banyak digunakan di dunia sehingga memiliki basis pengguna dan pengembang yang luas. Dari faktor biaya, LVS dan aplikasi pendukungnya menggunakan lisensi GNU GPL sehingga dapat digunakan secara gratis (Jong Bae et al. 2004)

Metode Forwarding

Metode forwarding yang dipilih adalah metode LVS-DR. Pemilihan metode ini didasarkan pada kelebihan dan kelemahan masing-masing metode forwarding yang disesuaikan dengan kondisi di IPB.

Dari sisi kelebihan, LVS-DR mengungguli kedua metode yang lain. LVS-DR tidak mengharuskan koneksi dari realserver ke pengguna melalui director. Hal ini dapat membuat waktu proses lebih cepat. LVS-DR juga tidak memiliki overhead tunneling seperti yang terdapat pada metode LVS-TUN.

Dari sisi kelemahan, penerapan metode LVS-DR tidak menjadi suatu masalah pada kasus di IPB karena director dapat ditempatkan pada jaringan fisik yang sama dengan server proxy. Selain itu, karena kedua server proxy di IPB menggunakan sistem

(21)

operasi Linux, maka masalah ARP juga dapat diselesaikan dengan baik.

Algoritme Penjadwalan

Pada analisis lingkungan jaringan IPB diperoleh informasi bahwa kedua server proxy di IPB memiliki spesifikasi perangkat keras yang berbeda. Hal ini tentu mempengaruhi kemampuan pemrosesan dari kedua server tersebut.

Supaya beban kerja dapat terbagi secara adil sesuai dengan kemampuan masing-masing server, maka server yang memiliki spesifikasi lebih tinggi harus diberi lebih banyak pekerjaan, sedangkan server yang memiliki spesifikasi lebih rendah harus diberi lebih sedikit tugas. Pembagian beban seperti yang diharapkan dapat dipenuhi oleh algoritme penjadwalan weighted round robin (round robin dengan pembobotan).

Pembobotan

Pembobotan ditentukan dengan mengamati perbedaan spesifikasi cpu dan memori pada kedua server, hasil data utilisasi cpu dan memori sebelum implementasi mekanisme load balancing serta data

throughput dan jumlah koneksi pada

masing-masing server proxy.

Pembobotan awal yang diberikan adalah 1:1, yang berarti setiap server proxy memiliki bobot yang sama dan akan memperoleh jumlah pekerjaan yang sama. Selanjutnya, bobot akan di-tuning setiap dua hari sekali untuk menentukan pembobotan yang paling sesuai dengan kondisi IPB.

Pada putaran kedua, server proxy 172.17.0.11 diberi bobot 1 dan server proxy 172.17.0.18 diberi bobot 2. Pada putaran ketiga, server proxy 172.17.0.11 diberi bobot 2 dan server proxy 172.17.0.18 diberi bobot 3. Pada putaran keempat, server proxy 172.17.0.11 diberi bobot 3 dan server proxy 172.17.0.18 diberi bobot 5.

5. Implementasi mekanisme load balancing.

Pada tahapan ini dilakukan implementasi mekanisme load balancing pada server proxy di IPB sesuai dengan aspek-aspek yang telah ditetapkan sebelumnya. Langkah implementasi mekanisme load balancing dapat dilihat pada Lampiran 5.

Availabilitas

Dengan diterapkannya pembagian kerja, maka semua permintaan layanan dari pengguna kepada server proxy di IPB harus

selalu melalui director baru kemudian dibagi kepada dua buah server proxy yang ada. Masalah dapat timbul apabila salah satu server mengalami kerusakan sehingga tidak dapat melayani pengguna. Director akan tetap mengirimkan permintaan kepada server proxy tersebut karena director tidak mengetahui apa yang terjadi. Hal ini menyebabkan layanan menjadi tidak tersedia bagi pengguna.

Untuk mengatasi masalah tersebut, maka

director harus mampu melakukan pengecekan

kesehatan terhadap realserver dan konfigurasi ulang terhadap sistem yang ada secara otomatis. Jika ada realserver yang mengalami kerusakan, maka director harus mengeluarkannya dari tabel layanan load

balancing sehingga layanan secara

keseluruhan tidak mengalami masalah dan pengguna tetap dapat memperoleh layanan yang dibutuhkannya.

Kemampuan tersebut disediakan oleh aplikasi keepalived. Keepalived mengirimkan sinyal pengecekan kesehatan kepada masing-masing realserver setiap interval waktu tertentu. Apabila terdapat realserver yang tidak menjawab sinyal yang dikirimkan, maka keepalived akan menganggap realserver tersebut rusak dan mengeluarkannya dari tabel layanan load balancing. Seandainya realserver tersebut kembali berfungsi, maka

keepalived akan memasukkannya kembali ke dalam tabel layanan load balancing.

Mekanisme pengecekan kesehatan ini memberikan availabilitas yang tinggi terhadap sistem load balancing karena pengguna akan selalu memperoleh layanan tanpa mengetahui bahwa bagian dari sistem telah mengalami kerusakan ataupun sedang mengalami perbaikan.

Keepalived juga menyediakan mekanisme yang disebut director failover untuk mengatasi masalah single point of failure dengan menggunakan protokol VRRP. Apabila director pertama rusak maka

tugasnya dapat langsung diambil alih oleh

director cadangan.

Teknis Implementasi

Pada tahap implementasi, terdapat beberapa hal teknis yang harus menjadi perhatian.

• Kebutuhan minimum

Kebutuhan minimum untuk dapat mengimplementasikan mekanisme load

balancing yang sudah ditetapkan adalah:

9 Ipvs

9 Kernel devel linux 9 Compiler gcc

(22)

9 Openssl 9 Popt 9 Ipvsadm 9 Keepalived • Masalah ARP

Pada metode LVS-DR yang digunakan, alamat Virtual IP (VIP) digunakan bersama oleh director dan

realserver, namun pengguna tidak boleh

mengetahui hal tersebut. Pengguna hanya tahu bahwa alamat VIP dipegang oleh

director. Oleh karena itu, realserver harus

dikonfigurasi agar tidak menjawab permintaan ARP.

Untuk mengatasi masalah ARP, pada server proxy yang menggunakan linux kernel 2.6.13 cukup dengan menonaktifkan flag arp_ignore yang sudah tersedia. Pada server proxy dengan kernel 2.4.21, belum tersedia flag tersebut sehingga perlu dilakukan patch dan

recompile kernel terlebih dahulu.

• Firewall

Konfigurasi firewall pada director harus disesuaikan agar tidak memblok paket yang melaluinya.

• Konfigurasi squid

Konfigurasi squid pada kedua server proxy harus disamakan, khususnya dalam hal filter.

Kebijakan Implementasi

Implementasi mekanisme load balancing di IPB mempertimbangkan dua alternatif kebijakan implementasi. Pertama, director diberikan alamat IP yang baru (172.17.0.17) dan membagi request kepada proxy 172.17.0.11 dan proxy 172.17.0.18. Apabila menggunakan alternatif ini, maka perubahan ini harus diinformasikan kepada seluruh lingkungan pengguna proxy di IPB untuk mengarahkan proxynya ke alamat IP 172.17.0.17. Hal ini tentunya akan memakan cukup banyak waktu hingga seluruh pengguna mengikuti kebijakan tersebut. Selain itu dikhawatirkan tidak semua pengguna akan mengikuti kebijakan tersebut mengingat server proxy 172.17.0.11 dan 172.17.0.18 tetap dapat diakses oleh pengguna.

Alternatif yang kedua, director disetting untuk memegang alamat IP 172.17.0.11 dan 172.17.0.18 (sebagai alamat IP virtual), kemudian alamat IP server proxy diganti menjadi alamat yang lain. Keuntungan dari alternatif ini adalah kita pengguna sama sekali tidak perlu diberitahu mengenai perubahan yang terjadi. Pengguna tetap menggunakan

alamat proxy .18 atau .11 tanpa mengetahui bahwa alamat tersebut telah dimiliki oleh

director. Director kemudian tinggal membagi

permintaan yang masuk ke alamat proxy yang sesungguhnya. Berdasarkan pertimbangan dari sisi transparansinya, maka alternatif kebijakan kedua yang digunakan.

Gambar 9 menunjukkan topologi jaringan

director dan server proxy di IPB dan Gambar

10 menunjukkan arsitektur LVS di IPB.

Gambar 9 Topologi jaringan director dan server proxy di IPB.

Gambar 10 Arsitektur LVS di IPB.

Analisis Spesifikasi Komputer yang Digunakan sebagai Director

Spesifikasi komputer yang digunakan sebagai director adalah sebagai berikut:

 Komputer director master (172.17.0.50) • Sistem Operasi Linux Fedora Core 6,

kernel 2.6.18-1.2798.fc6

• Prosesor: Intel(R) Pentium (R) 4 CPU 3.00GHz

• Harddisk 80 GB • RAM 384 MB

(23)

 Komputer director backup (172.17.0.21) • Sistem Operasi Linux Fedora Core 6,

kernel 2.6.18-1.2798.fc6

• Prosesor: Intel(R) Pentium (R) 4 CPU 2.40GHz

• Harddisk 40 GB • RAM 256 MB Pengujian

Setelah implementasi, dilakukan beberapa pengujian untuk memastikan sistem telah dapat berjalan dengan baik:

• Pada selang waktu tertentu, salah satu server proxy akan dinonaktifkan untuk menguji apakah sistem pengecekan kesehatan telah berjalan baik. Hasil yang diharapkan adalah server yang dinonaktifkan tersebut akan dikeluarkan dari daftar LVS dan seluruh permintaan akan dikirimkan ke server yang masih aktif.

• Pada selang waktu tertentu, director

master akan dinonaktifkan untuk menguji

apakah director failover telah berjalan baik. Hasil yang diharapkan adalah

director cadangan mengambil alih tugas

dari director master dan sistem dapat berjalan seperti sediakala.

Selain kedua pengujian tersebut, akan dilakukan pengukuran utilisasi cpu dari

director sebelum dan setelah menjalankan

tugasnya sebagai pembagi beban. Hal ini dilakukan untuk mengetahui sejauh mana tugas tersebut mempengaruhi kinerja cpu. Pengukuran dilakukan selama 5 hari sebelum dan 5 hari sesudah director bertugas.

6. Pengambilan data kinerja server proxy setelah penerapan mekanisme load balancing.

Setelah mekanisme load balancing berhasil diimplementasikan, kembali akan dilakukan pengukuran kinerja server proxy. Teknis pengukuran pada tahap ini sama seperti pada tahap ketiga, namun pada tahap ini diberikan pembobotan yang berbeda setiap dua hari sekali.

7. Analisis kinerja

Tahap terakhir dari penelitian ini adalah analisis kinerja. Data sebelum dan sesudah implementasi mekanisme load balancing akan dibandingkan untuk mengetahui apakah terjadi perbaikan kinerja server proxy di IPB.

Parameter Kinerja Load Balancing

Pada penelitian ini digunakan dua parameter untuk mengevaluasi kinerja load

balancing. (Zhong et al. 2004). Parameter

pertama adalah Cumulative Density Function (CDF) atau frekuensi kumulatif dari utilisasi maksimum. Hasil pengamatan dibagi menjadi n slot waktu dan untuk setiap slot waktu j, terdapat utilisasi server untuk setiap server i. utilisasi maksimum adalah nilai maksimum diantara semua utilisasi server dalam slot waktu j. Frekuensi kumulatif didefinisikan sebagai peluang terjadinya utilisasi maksimum yang kurang dari atau sama dengan x:

dengan adalah jumlah slot waktu dimana utilisasi maksimum tidak lebih besar daripada x, dan n adalah jumlah total slot waktu.

Untuk sejumlah beban trafik , jika sebuah server melayani lebih banyak trafik, server lainnya akan melayani lebih sedikit trafik. Situasi ini akan menghasilkan utilisasi maksimum yang lebih besar. Oleh karenanya, utilisasi maksimum yang lebih besar menunjukkan pembagian beban tidak seimbang di antara server. Di dalam grafik dengan lebih dari satu kurva frekuensi kumulatif, kurva yang paling kiri menunjukkan kinerja yang terbaik. Untuk frekuensi kumulatif yang sama, utilisasi maksimum yang lebih besar menunjukkan kinerja yang lebih buruk.

Parameter kedua untuk mengevaluasi kinerja load balancing adalah standar deviasi (SD) dari utilisasi server. Pada slot waktu j, standar deviasi instant SDj dikalkulasi dengan rumus:

∑ ₁ 2/

dengan K adalah jumlah server, dan adalah rata-rata utilisasi server , i=1, …, K. Standar deviasi SD dihitung dengan merata-ratakan semua nilai standar deviasi instan. Apabila beban kerja server terdistribusi secara adil, maka standar deviasi seharusnya memiliki nilai sangat kecil. Oleh karena itu, semakin kecil standar deviasi, maka semakin baik kinerja load balancing.

(24)

HASIL DAN PEMBAHASAN

Hasil dan pembahasan disajikan seturut dengan susunan metodologi penelitian.

Data kinerja server proxy di IPB sebelum penerapan mekanisme load balancing a. Utilisasi CPU

Pengambilan data utilisasi CPU server proxy IPB dilakukan secara remote dari komputer lokal (172.18.78.60) di Lab NCC selama 10 hari kerja dari tanggal 4 sampai dengan tanggal 17 Desember 2007. Pengambilan data dilakukan selama jam kerja mulai pukul 08.00 sampai dengan pukul 16.00, dengan interval waktu 10 menit sehingga terdapat 49 titik data dalam satu hari. Grafik utilisasi CPU pada tanggal 4 dan 5 Desember 2007 dapat dilihat pada Gambar 11 dan Gambar 12. Grafik utilisasi CPU selama 10 hari pengambilan data dapat dilihat pada Lampiran 6.

Gambar 11 Utilisasi CPU 4 Desember 2007.

Gambar 12 Utilisasi CPU 5 Desember 2007. Dari grafik sekilas tampak bahwa ternyata utilisasi CPU sebelum implementasi load

balancing sudah cukup merata pada kedua

server proxy di IPB. Hal ini berarti

mekanisme pembagian beban berdasarkan kebijakan sebenarnya sudah berjalan cukup baik. Meskipun demikian, bukan berarti implementasi mekanisme load balancing tidak lagi bermanfaat karena masih banyak nilai tambah yang dapat diperoleh.

b. Penggunaan memori

Data penggunaan memori diambil dengan mekanisme yang sama seperti data utilisasi CPU. Data yang diambil adalah penggunaan memori sistem secara global, dengan memperhitungkan proses yang lain selain squid. Hal ini dilakukan untuk memperoleh hasil yang sesuai dengan kondisi nyata. Grafik utilisasi memori pada tanggal 4 dan 5 Desember 2007 dapat dilihat pada Gambar 13 dan Gambar 14. Grafik utilisasi memori selama 10 hari pengambilan data dapat dilihat pada lampiran 7.

Gambar 13 Utilisasi memori 4 Desember 2007.

Grafik utilisasi memori menunjukkan bahwa sistem operasi kedua server proxy berusaha memanfaatkan memori yang dimiliki secara maksimal. Server proxy 172.17.0.18 dengan sistem operasi Linux OpenSuse

(25)

tampak selalu menggunakan hampir 100% dari kapasitas memori yang dimilikinya.

c. Throughput

Data throughput juga diambil selama 10 hari kerja mulai tanggal 4 hingga 17 Desember 2007. Data diambil selama satu hari penuh dengan interval 5 menit sehingga diperoleh 288 titik data dalam satu hari. Grafik throughput pada tanggal 4 dan 5 Desember 2007 dapat dilihat pada Gambar 15 dan Gambar 16. Data throughput selama 10 hari dapat dilihat pada Lampiran 8.

Gambar 15 Throughput 4 Desember 2007.

Grafik throughput pada tanggal 4

Desember hanya memberikan sebagian informasi, yaitu dimulai sekitar pukul 12.00 karena sebelumnya perangkat keras CTM mati. Dari kedua grafik tersebut dapat dilihat bahwa server proxy 172.17.0.18 memiliki

throughput yang lebih besar daripada server

proxy 172.17.0.11.

d. Jumlah koneksi

Data jumlah koneksi pada masing-masing server proxy diperoleh dari data log akses squid. Jumlah baris pada file akses log squid menunjukkan jumlah koneksi yang diterima dan diproses oleh server proxy. Gambar 17

menunjukkan grafik jumlah koneksi selama 10 hari kerja sebelum implementasi mekanisme load balancing.

Gambar 17 Jumlah koneksi sebelum implementasi mekanisme load balancing.

Dari grafik di atas, tampak bahwa jumlah koneksi pada server proxy 172.17.0.18 selalu lebih banyak daripada server proxy 172.17.0.11. Pada tanggal 13 Desember 2007 terlihat jumlah koneksi pada server proxy 172.17.0.18 meningkat secara tidak wajar. Hal ini kemungkinan disebabkan adanya pengguna yang melakukan akses secara berlebihan. Tabel hasil perhitungan jumlah koneksi dapat dilihat pada Lampiran 9.

e. Hit ratio

Seperti data jumlah koneksi, hit ratio juga dikalkulasi dari data akses log squid pada masing-masing server proxy. Data akses log diparsing untuk mengetahui jumlah hit, kemudian jumlah hit dibagi dengan jumlah koneksi untuk memperoleh persentase hit

ratio. Hit ratio sebelum implementasi

mekanisme load balancing selama 10 hari kerja dapat dilihat pada Gambar 18.

Gambar 18 Hit ratio sebelum implementasi mekanisme load balancing.

(26)

Dari grafik di atas, dapat diketahui bahwa persentase hit ratio pada server proxy 172.17.0.11 hampir selalu lebih tinggi daripada server proxy 172.17.0.18. Hal ini berarti server proxy 172.17.0.11 dapat melakukan fungsi cache dengan cukup baik. Selain itu, nilai hit ratio yang tinggi juga dapat memprediksi bahwa pengguna server proxy 172.17.0.11 lebih banyak mengakses situs yang sama. Tabel hasil perhitungan hit

ratio dapat dilihat pada Lampiran 9.

Pengujian Tahap Implementasi

Pada tahap implementasi dilakukan beberapa pengujian untuk memastikan sistem berjalan dengan baik.

a. Pengecekan kesehatan

Pengujian pengecekan kesehatan dilakukan pada tanggal 18 Desember 2007 sekitar pukul 16.00 sampai dengan pukul 17.00. Layanan squid pada salah satu server proxy dinonaktikan selama waktu tersebut. Server proxy yang dipilih untuk dinonaktifkan adalah server proxy 172.17.0.11 dengan alasan spesifikasi yang dimilikinya lebih rendah sehingga dikhawatirkan tidak mampu untuk menangani seluruh request pengguna apabila bekerja sendiri.

Hasil pengujian menunjukan bahwa

director mengeluarkan server proxy tersebut

dari daftar layanan LVS dan seluruh koneksi diarahkan pada server proxy 172.17.0.18 sehingga pengguna tetap dapat mengakses internet. Gambar 19 menunjukan grafik

throughput pada saat salah satu server proxy

dinonaktifkan.

Gambar 19 Throughput pada saat salah satu server proxy dinonaktifkan. b. Director failover

Pengujian director failover dilakukan pada tanggal 4 Januari 2008, dengan selang waktu antara pukul 08.00 hingga pukul 09.30. Pada selang waktu tersebut, layanan keepalived

pada director master dihentikan untuk sementara. Hasil pengujian menunjukan bahwa koneksi dapat terus berjalan karena

director cadangan langsung mengambil alih

tugas dari director master.

c. Utilisasi CPU

Gambar 20 menunjukkan perbandingan utilisasi CPU director sebelum dan sesudah implementasi load balancing. Kurva dengan garis lurus menunjukan utilisasi CPU sebelum implementasi. Data sebelum implementasi diambil pada tanggal 6, 7, 9, 10, dan 12 Desember 2007. Kurva dengan garis lurus bertanda menunjukkan utilisasi CPU sesudah implementasi. Data sesudah implementasi diambil pada tanggal 18, 19, dan 28 Desember 2007 serta tanggal 2 dan 3 Januari 2008.

Gambar 20 Perbandingan utilisasi CPU director sebelum dan sesudah implementasi load balancing.

Dari grafik tersebut dapat dilihat bahwa sebelum implementasi, utilisasi CPU pada

director selalu mendekati 0%. Sesudah

implementasi, terjadi peningkatan utilisasi CPU, namun peningkatan tersebut tidaklah signifikan karena hanya berkisar dibawah 1%. Hal ini menunjukan bahwa pekerjaan membagi beban yang dilakukan director tidak mengkonsumsi banyak sumber daya CPU. Hasil ini sesuai dengan yang diharapkan karena proses pembagian beban berlangsung pada kernel space.

Data kinerja server proxy di IPB setelah penerapan mekanisme load balancing a. Utilisasi CPU

Pada pengukuran 2 hari pertama, yaitu pada tanggal 18 dan 19 Desember 2007, diberikan bobot 1:1 pada kedua server proxy. Bobot 1:1 bermakna bahwa kedua server proxy diberi beban trafik yang sama. Grafik

(27)

utilisasi CPU pada kedua hari tersebut dapat dilihat pada Gambar 21 dan Gambar 22.

Kurva utilisasi CPU menunjukkan perbedaan yang cukup signifikan. Hal ini disebabkan oleh perbedaan spesifikasi CPU pada kedua server proxy. Ketika diberi sejumlah beban trafik yang sama, server proxy 172.17.0.11 dengan kecepatan pemrosesan CPU 1,5 GHz tentu akan lebih banyak mengutilisasi CPUnya daripada server proxy 172.17.0.18 yang memiliki kecepatan pemrosesan CPU 2,8 GHz. Grafik tersebut juga menunjukan bahwa pembagian beban yang sama banyak tidak berarti pembagian beban yang adil.

Kurva utilisasi CPU server proxy 172.17.0.18 pada tanggal 18 Desember 2007 selalu berada pada posisi 100% hingga pukul 11.00. Pengamatan pada data mentah menunjukkan bahwa sebagian besar CPU diutilisasi untuk proses user yang memiliki prioritas nice.

Pada pengukuran 2 hari kedua, yaitu pada tanggal 27 dan 28 Desember 2007 diberikan bobot 1:2 pada kedua server proxy. Grafik utilisasi CPU pada kedua hari tersebut dapat dilihat pada Gambar 23 dan Gambar 24.

Gambar 24 Utilisasi CPU 28 Desember 2007. Kurva menunjukkan bahwa utilisasi CPU terbagi secara cukup adil pada saat pembobotan 1:2.

Pada pengukuran 2 hari ketiga, yaitu pada tanggal 2 dan 3 Januari 2008 diberikan bobot 2:3 pada kedua server proxy. Grafik utilisasi CPU pada kedua hari tersebut dapat dilihat pada Gambar 25 dan Gambar 26.

(28)

Gambar 26 Utilisasi CPU 3 Januari 2008.

Dari grafik tersebut, pembobotan 2:3 ternyata kembali merenggangkan kurva utilisasi CPU kedua server proxy.

Pada pengukuran 2 hari keempat, yaitu pada tanggal 4 dan 7 Januari 2008 diberikan bobot 3:5 pada kedua server proxy. Grafik utilisasi CPU pada kedua hari tersebut dapat dilihat pada Gambar 27 dan Gambar 28.

Pembobotan 3:5 memberikan hasil utilisasi CPU yang tidak jauh berbeda dibandingkan dengan pembobotan 2:3 karena memang nilai keduanya cukup dekat.

b. Penggunaan memori

Gambar 29 dan Gambar 30 menunjukkan grafik utilisasi memori pada saat pembobotan 1:1 yaitu pada tanggal 18 dan 19 Desember 2007.

Gambar 31 dan Gambar 32 menunjukkan grafik utilisasi memori pada saat pembobotan 1:2 yaitu pada tanggal 27 dan 28 Desember 2007.

(29)

Gambar 33 dan Gambar 34 menunjukkan grafik utilisasi memori pada saat pembobotan 2:3 yaitu pada tanggal 2 dan 3 Januari 2008.

Gambar 33 Utilisasi memori 2 Januari 2008.

Gambar 34 Utilisasi memori 3 Januari 2008.

Gambar 35 dan Gambar 36 menunjukkan grafik utilisasi memori pada saat pembobotan 3:5 yaitu pada tanggal 4 dan 7 Januari 2008.

Gambar 35 Utilisasi memori 4 Januari 2008.

Gambar 36 Utilisasi memori 7 Januari 2008. Keseluruhan kurva utilisasi memori tidak menunjukkan perbedaan yang signifikan. Kurva utilisasi memori server proxy 172.17.0.18 selalu mendekati nilai 100% dan kurva utilisasi server proxy 172.17.0.18 selalu berkisar antara 80% hingga 100%

c. Throughput

Gambar 37 dan Gambar 38 menunjukkan grafik throughput pada saat pembobotan 1:1 yaitu pada tanggal 18 dan 19 Desember 2007.

(30)

Gambar 38 Throughput 19 Desember 2007. Grafik di atas menunjukkan dengan jelas bahwa pembobotan 1:1 mempunyai arti bahwa kedua server proxy memperoleh beban pekerjaan yang sama sehingga grafik

throughput kedua server proxy tampak

berhimpitan satu dengan yang lain.

Gambar 39 dan Gambar 40 menunjukkan grafik throughput pada saat pembobotan 1:2 yaitu pada tanggal 27 dan 28 Desember 2007.

Gambar 40 Throughput 29 Desember 2007.

Gambar 41 dan Gambar 42 menunjukkan grafik throughput pada saat pembobotan 2:3 yaitu pada tanggal 2 dan 3 Januari 2008.

Gambar 41 Throughput 2 Januari 2008.

Gambar 42 Throughput 3 Januari 2008. Gambar 43 dan Gambar 44 menunjukkan grafik throughput pada saat pembobotan 3:5 yaitu pada tanggal 4 dan 7 Januari 2008.

Gambar 43 Throughput 4 Januari 2008.

(31)

Grafik throughput pada tanggal 4 Januari 2008 menunjukkan sedikit keanehan. Tampak bahwa pada selang waktu sekitar pukul 12.00 hingga pukul 16.00, server proxy 172.17.0.18 memperoleh peningkatan throughput yang cukup drastis, sedangkan server proxy 172.17.0.11 justru mengalami penurunan

throughput. Fenomena ini tidak dapat

dipastikan penyebabnya. Kemungkinan yang dapat diprediksi adalah pada selang waktu tersebut, server proxy 172.17.0.11 tidak menjawab pengecekan kesehatan yang dilakukan director sehingga koneksi tidak diarahkan kepadanya tetapi kepada server proxy 172.17.0.18.

d. Jumlah koneksi

Jumlah koneksi pada masing-masing server proxy setelah implementasi load

balancing dapat dilihat pada Gambar 45.

Gambar 45 Jumlah koneksi setelah implementasi mekanisme load balancing.

Jumlah koneksi dipengaruhi secara langsung oleh pembobotan. Pada saat pembobotan 1:1 pada tanggal 18 dan 19 Desember, jumlah koneksi pada kedua server proxy hampir sama seperti terlihat pada grafik. Meskipun dikatakan hampir sama, namun tidak tepat sama. Pada grafik terlihat bahwa server proxy 172.17.0.11 menerima jumlah koneksi yang lebih sedikit. Hal ini disebabkan karena dalam beberapa kesempatan, server proxy 172.17.0.11 gagal melakukan respon terhadap pengecekan kesehatan yang dikirimkan oleh director sehingga dalam selang waktu yang tertentu, server tersebut dikeluarkan dari layanan load

balancing, dan ketika pengecekan kesehatan

berhasil, server tersebut dimasukkan kembali ke dalam layanan. Pengguna sendiri tidak mengetahui kejadian tersebut.

e. Hit ratio

Hit ratio setelah masing-masing server

proxy setelah implementasi load balancing dapat dilihat pada Gambar 46.

Gambar 46 Hit ratio setelah implementasi mekanisme load balancing.

Setelah implementasi load balancing, hit

ratio pada kedua server proxy mengalami

perubahan dimana hit ratio pada server proxy 172.17.0.11 mengalami penurunan sedangkan

hit ratio pada server proxy 172.17.0.18

mengalami peningkatan.

Analisis Kinerja

Seperti dijelaskan sebelumnya, kinerja

load balancing dapat dilihat dari 2 parameter

yaitu CDF dan SD. Data hit ratio juga turut dipertimbangkan mengingat peran utama squid sebagai cache.

Oleh karena perlakuan pembobotan yang berbeda, maka terdapat perbedaan durasi pengambilan data sebelum dan sesudah implementasi. Hal ini dikhawatirkan menghasilkan pembandingan yang tidak valid. Untuk mengatasi masalah ini, dipilih data 2 hari yang dianggap paling merepresentasikan keseluruhan data sebelum implementasi yaitu data tanggal 6 dan 7 Desember 2007.

a. Utilisasi CPU

• Cumulative Density Function (CDF) Gambar 45 menunjukkan grafik CDF utilisasi CPU dan contoh tabel perhitungan CDF dapat dilihat pada Lampiran 10.