implementasi dan evaluasi kinerja load balancing … · meningkatkan realibilitas, skalabilitas,...

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

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)

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

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%. Kata kunci: Load Balancing, Server Proxy, LVS, Keepalived, Pembobotan, Hit Ratio, CDF, SD.

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%. Keywords: Load Balancing, Server Proxy, LVS, Keepalived, Pembobotan, Hit Ratio, CDF, SD.

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

Tanggal Lulus:

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.

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

David Thamrin

viii

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

DAFTAR PUSTAKA ..................................................................................................................... 22

ix

DAFTAR TABEL

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

x

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 12 Utilisasi CPU 5 Desember 2007. ................................................................................................ 12 13 Utilisasi memori 4 Desember 2007. ........................................................................................... 12 14 Utilisasi memori 5 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 21 Utilisasi CPU 18 Desember 2007. .............................................................................................. 15 22 Utilisasi CPU 19 Desember 2007. .............................................................................................. 15 23 Utilisasi CPU 27 Desember 2007. .............................................................................................. 15 24 Utilisasi CPU 28 Desember 2007. .............................................................................................. 15 25 Utilisasi CPU 2 Januari 2008. .................................................................................................... 15 26 Utilisasi CPU 3 Januari 2008. .................................................................................................... 16 27 Utilisasi CPU 4 Januari 2008. .................................................................................................... 16 28 Utilisasi CPU 7 Januari 2008. .................................................................................................... 16 29 Utilisasi memori 18 Desember 2007. ......................................................................................... 16 30 Utilisasi memori 19 Desember 2007. ......................................................................................... 16 31 Utilisasi memori 27 Desember 2007. ......................................................................................... 16 32 Utilisasi memori 28 Desember 2007. ......................................................................................... 17 33 Utilisasi memori 2 Januari 2008. ................................................................................................ 17 34 Utilisasi memori 3 Januari 2008. ................................................................................................ 17 35 Utilisasi memori 4 Januari 2008. ................................................................................................ 17 36 Utilisasi memori 7 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 50 Hit ratio keseluruhan. ................................................................................................................. 21

xi

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 12 Tabel hasil perhitungan keseluruhan koneksi, hit dan hit ratio .................................................. 42

1

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.

Gambar 1 Mekanisme load balancing.

2

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.

3

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 LVS-NAT, LVS-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 routing.

Gambar 5 Alur kerja direct routing.

4

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.

5

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.

Analisis kinerja

6

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

Gambar 8 Topologi jaringan IPB (Sukoco 2006).

7

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

8

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

9

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:

Ipvs Kernel devel linux Compiler gcc

10

Openssl Popt Ipvsadm 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

11

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

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

12

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.


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.


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

13

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


14

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

15

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.



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.

Gambar 25 Utilisasi CPU 2 Januari 2008.

16

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.


2007.


2007.

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


2007.

17


2007. 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 35 dan Gambar 36 menunjukkan

grafik utilisasi memori pada saat pembobotan 3:5 yaitu pada tanggal 4 dan 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.


18


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.


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




grafik throughput pada saat pembobotan 2:3 yaitu pada tanggal 2 dan 3 Januari 2008.

Gambar 41 Throughput 2 Januari 2008.


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



19

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


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.

20

Gambar 47 CDF utilisasi CPU.

Grafik di atas menunjukkan bahwa

pembobotan 1:1 memberikan kinerja yang lebih buruk daripada sebelum implementasi load balancing, sedangkan pemberian bobot 1:2, 2:3, dan 3:5 semuanya memberikan peningkatan kinerja karena posisi kurvanya berada di sebelah kiri kurva sebelum implementasi.

Sebelumnya disebutkan bahwa kurva paling kiri menunjukkan kinerja paling baik, namun hal tersebut hanya berlaku pada kondisi ideal. Pada penelitian ini, pengambilan data dilakukan pada situasi sesungguhnya di lapangan, dimana banyak faktor yang mempengaruhi data, misalnya pola pengaksesan dan jumlah koneksi yang berbeda. Oleh karena itu, grafik CDF hanya mampu menunjukkan peningkatan kinerja, tetapi tidak dapat menentukan pembobotan yang terbaik. Hal tersebut baru dapat diketahui dari nilai standar deviasi. • Standar Deviasi (SD)

Tabel 1 menunjukkan hasil perhitungan SD utilisasi CPU.

Tabel 1 Hasil perhitungan SD utilisasi CP

Bobot SD Utilisasi CPU Sebelum 6.113418367

1:1 20.18428571 1:2 5.256020408 2:3 10.20505102 3:5 11.25260204

Grafik SD utilisasi CPU dapat dilihat pada

Gambar 48 dan contoh tabel perhitungan SD dapat dilihat pada Lampiran 11.

Gambar 48 SD utilisasi CPU.

Tabel dan grafik SD utilisasi CPU

menunjukkan bahwa SD utilisasi CPU terkecil diperoleh ketika pembobotan 1:2. Oleh karena SD utilisasi CPU terkecil menunjukkan pembagian beban yang paling adil dan kinerja yang paling baik, maka disimpulkan bahwa pembobotan yang paling tepat untuk diterapkan pada mekanisme load balancing server proxy di IPB adalah 1:2.

Tampak pula bahwa pembobotan selain 1:2 menghasilkan SD yang lebih tinggi daripada SD sebelum implementasi mekanisme load balancing. b. Penggunaan Memori

Dari keseluruhan grafik utilisasi memori, baik sebelum maupun sesudah implementasi load balancing, tampak bahwa ternyata implementasi load balancing tidak terlalu mempengaruhi persentase jumlah memori yang digunakan oleh kedua server proxy. Begitu pula perbedaan bobot yang diberikan, tidak terlalu berpengaruh layaknya persentase utilisasi CPU.

Hal ini ditegaskan dengan hasil perhitungan SD utilisasi memori yang dapat dilihat pada Tabel 2.

Tabel 2 Hasil perhitungan SD utilisasi memori

Bobot SD Utilisasi Memori Sebelum 3.016632653

1:1 2.497275046 1:2 4.196122449 2:3 3.556173469 3:5 4.674387755

21

Gambar 49 menyajikan grafik SD utilisasi memori.

Gambar 49 SD utilisasi memori.

Seperti disebutkan sebelumnya, ternyata hasil perhitungan SD utilisasi memori tidak menunjukkan perbedaan yang signifikan jika dibandingkan dengan SD utilisasi CPU. Hal ini disebabkan karena data utilisasi memori yang diambil adalah utilisasi memori keseluruhan sistem. Menurut Tranter (2004), linux selalu berusaha membuat semua memori bekerja, seperti untuk buffer dan cache. Oleh karena itu, SD memori tidak dapat menunjukkan kinerja dari load balancing. c. Hit Ratio

Tugas utama server proxy adalah menyediakan cache. Salah satu parameter untuk mengukur kinerja server proxy adalah hit ratio. Hit ratio yang tinggi mengimplikasikan server proxy telah bekerja dengan baik karena untuk melayani permintaan pengguna, server proxy tersebut tidak perlu melakukan koneksi ke server web sesungguhnya, tetapi cukup memanfaatkan informasi yang tersedia di cache.

Apabila implementasi load balancing menurunkan hit ratio pada server proxy berarti terjadi penurunan kinerja.

Data hit ratio sesudah implementasi menunjukkan bahwa terjadi penurunan hit ratio pada server proxy 172.17.0.11, yang diimbangi dengan peningkatan hit ratio pada server proxy 172.17.0.18. Hanya dari informasi tersebut, kita tidak dapat menyimpulkan secara lengkap sehingga diperlukan nilai hit ratio keseluruhan. Hit ratio keseluruhan diperoleh dengan cara menambahkan jumlah hit dan jumlah koneksi pada kedua server proxy. Kemudian total hit dibagi dengan total koneksi dan dikalikan dengan 100%.

Gambar 50 menunjukkan grafik hit ratio keseluruhan.

Gambar 50 Hit ratio keseluruhan.

Dari grafik tersebut, tampak bahwa hit ratio sesudah implementasi mengalami sedikit peningkatan yang berarti bahwa implementasi load balancing meningkatkan kinerja server proxy meskipun tidak terlalu signifikan dari sisi hit ratio. Rata-rata hit ratio keseluruhan selama sepuluh hari sebelum implementasi adalah 12.71% dan rata-rata hit ratio keseluruhan selama delapan hari setelah implementasi mencapai 16.96%. Hal ini berarti terdapat peningkatan sekitar 4%. Tabel hasil perhitungan hit ratio keseluruhan dapat dilihat pada Lampiran 12.

KESIMPULAN DAN SARAN

Kesimpulan

Implementasi mekanisme load balancing terbukti dapat meningkatkan realibilitas, skalabilitas, dan availabilitas server proxy di IPB. Dengan implementasi mekanisme load balancing, beban kerja dapat dibagi secara adil berdasarkan beban trafik, tanpa perlu kebijakan.

Berdasarkan hasil penelitian, diketahui 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%.

Saran

Beberapa saran yang dapat diberikan untuk penelitian selanjutnya antara lain: 1. Pembobotan yang diberikan dapat lebih

bervariasi untuk menemukan pembobotan yang lebih baik.

2. Algoritme penjadwalan weighted round robin menimbulkan sedikit masalah dalam hal pengaksesan. Terdapat situs

22

yang tidak mau melayani request apabila koneksi berasal dari dua buah sumber yang berbeda, sebagai contoh meebo.com. Oleh karena itu, perlu diuji coba algoritme penjadwalan lain yang memperhatikan masalah locality tersebut seperti locality based least connection.

3. Berbagai aspek dalam load balancing dapat diganti misalnya dalam sisi level load balancing atau dalam hal perangkat lunak yang digunakan. Kemudian hasilnya dapat dibandingkan dengan penelitian ini.

4. Pada pengukuran kinerja server proxy, dapat ditambahkan parameter utilisasi harddisk karena server proxy pasti banyak melakukan akses ke harddisk (cache).

DAFTAR PUSTAKA

Anonymous. 2000. Maximum Linux Security.

USA: Sams Publishing.

Balasubramanian J, Schimdt DC, Dowdy L, Othman O. 2004. Evaluating the Performance of Middleware Load Balancing Strategies. Proceedings of the 8th Intl Enterprise Distributed Object Computing (EDOC 2004).

Cassen A. 2002. Keepalived User Guide. Released Under GPL.

[Cisco]. 2003. ARP. Glossary Cisco Networking Academy Program.

Garcia AL dan Widjaja I. 2004. Communication Networks: Fundamental Concepts and Key Architectures. Ed ke-2. New York: McGraw-Hill.

[ITU]. International Telecommunication Union for Standardization. 1998. Traffic Intensity Measurement Principles. http://eu.sabotage.org/www/ITU/E/E0500e.pdf [13 Des 2007].

Jong-Bae M dkk. 2004. A High Performance LVS System For Webserver Cluster. Proceedings of World Academy of Science, Engineering and Technology Volume 1. (PWASET 2004)

[Keepalived] Healthchecking for LVS & High Availability. http://www.keepalived.org [7 Nov 2007].

[LVS] The Linux Virtual Server Project. http://www.linuxvirtualserver.org [28 Nov 2007].

Mack J. 2007. LVS-HOWTO. http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/ [25 Okt 2007].

Menascé dan Almeida.1998. Capacity Planning Methodology. http://www.cse.msu.edu/~cse 807/notes/slides/part3set1presentation.ppt [5 Nov 2007].

[PCMag]. Hit Ratio. http://www.pcmag.com/encyclopedia_term/0,2542,t=hit+rate&i=44289,00.asp [7 Jan 2008]

[PCMedia]. Sistem Load Balancing: Solusi untuk Server Sibuk. 2004. http://www.pcmedia.co.id/detail.asp?id=179&Cid=22&cp=1&Eid=6 [25 Okt 2007]

Peterson LL dan Davie BS. 2003. Computer Networks: A System Approach. Ed ke-3. San Fransisco: Elsevier.

Qodarsih N. 2007. Perencanaan Kapasitas untuk Kinerja Web dan Proxy Server IPB Menggunakan Model Open Queueing Network M/M/2 dan M/M/1 [skripsi]. Bogor: Fakultas Matematika dan Ilmu Pengetahuan Alam.

RFC 3768. Virtual Router Redundancy Protocol. http://www.ietf.org/rfc/rfc3768.txt [12 Des 2007]

Sukoco H. 2006. Lingkungan Jaringan IPB. Bogor: KPSI.

Tatham S. 2008. PuTTY. http://www.chiark.greenend.org.uk/~sgtatham/putty/ [13 Des 2007]

Tranter J. 1994. Tips for Optimizing Linux Memory Usage. http://www.linuxjournal.com/article/2770 [8 Jan 2008].

Wagito. 2005. Jaringan Komputer: Teori dan Implementasi Berbasis Linux. Yogyakarta: Gava Media.

Wensong Z. 2002. Linux Virtual Server: Linux Server Clusters for Scalable Network Services. Free Software Symposium.

[WinSCP.net]. WinSCP. http://winscp.net/eng/index.php [13 Des 2007].

Zhong X, Rong H, dan Bhuyan LN. 2004. Load Balancing of DNS-Based Distributed Web Serer Systems with Page Caching.

23

Proceedings of the Tenth International Conference on Parallel and Distributed Systems (ICPADS ’04).

24

Lampiran 1 Contoh data utilisasi cpu pada server proxy di IPB

Linux 2.6.13-15-default (linux) 12/27/2007

8:00:01 AM CPU %user %nice %system %idle 8:00:01 AM all 0.34 0 0.19 99.47 8:10:01 AM all 0.42 0 0.3 99.28 8:20:01 AM all 0.45 0 0.46 99.09 8:30:01 AM all 0.54 0 0.46 998:40:01 AM all 0.56 0 0.42 99.02 8:50:01 AM all 0.83 0 0.98 98.19 9:00:01 AM all 0.92 0 0.93 98.16 9:10:01 AM all 1.75 3.25 4.76 90.24 9:20:01 AM all 1.87 0 1.91 96.22 9:30:01 AM all 1.41 0 2.05 96.54 9:40:01 AM all 8.99 0 19.55 71.46 9:50:01 AM all 16.34 0 36.77 46.89 10:00:01 AM all 21.09 0 48.36 30.56 10:10:01 AM all 23.97 0 54.75 21.28 10:20:01 AM all 25.54 0 55.91 18.55 10:30:01 AM all 26.46 0 59.02 14.52 10:40:01 AM all 30 0 59.81 10.19 10:50:01 AM all 31.82 0 59.2 8.9911:00:02 AM all 34.26 0 62.86 2.88 11:00:02 AM CPU %user %nice %system %idle 11:10:02 AM all 33.48 0 62.73 3.7911:20:02 AM all 33.51 0 61.81 4.6811:30:02 AM all 31.5 0 58.8 9.7111:40:02 AM all 30.04 0 59.18 10.77 11:50:02 AM all 29.07 0 60.26 10.68 12:00:01 PM all 28.17 0 58.68 13.15 12:10:01 PM all 23.32 0 45.68 3112:20:01 PM all 24.55 0 48.71 26.74 12:30:01 PM all 21.17 0 45.44 33.39 12:40:01 PM all 20.57 0 43.1 36.33 12:50:01 PM all 23.67 0 45.53 30.81:00:01 PM all 20.68 0 45.07 34.25 1:10:01 PM all 21.24 0 47.19 31.57 1:20:01 PM all 23.66 0 48.47 27.87 1:30:01 PM all 22.26 0 47.09 30.65 1:40:01 PM all 24.77 0 53.49 21.74 1:50:01 PM all 24.5 0 52.33 23.17 2:00:02 PM all 25.34 0 57.35 17.32:10:02 PM all 25.73 0 55.98 18.29 2:20:02 PM all 26.09 0 56.63 17.28 2:30:02 PM all 27.8 0 58.78 13.42 2:40:02 PM all 27.42 0 59.07 13.51 2:40:02 PM CPU %user %nice %system %idle 2:50:02 PM all 27.9 0 58.92 13.18 3:00:01 PM all 27.78 0 58.72 13.53:10:01 PM all 27.43 0 58.11 14.45 3:20:01 PM all 27.99 0 59.23 12.78 3:30:01 PM all 26.78 0 57.32 15.89 3:40:01 PM all 23.09 0 49.87 27.04 3:50:01 PM all 22.11 0 47.83 30.06 4:00:02 PM all 19.75 0 43.15 37.1

25

Lampiran 2 Contoh data penggunaan memori pada server proxy di IPB

Linux 2.4.21-exp (nms.ipb.ac.id) 12/27/07

8:00:01 kbmemfree kbmemused %memused kbmemshrd kbbuffers kbcached kbswpfree kbswpused %swpused

8:00:01 114336 269940 70.25 0 151692 65744 735168 43976 5.64 8:10:00 115132 269144 70.04 0 146916 67928 735168 43976 5.64 8:20:00 114660 269616 70.16 0 141888 73500 735168 43976 5.64 8:30:00 115036 269240 70.06 0 137480 75672 735168 43976 5.64 8:40:00 112824 271452 70.64 0 134872 79272 735156 43988 5.65 8:50:00 112620 271656 70.69 0 122832 90216 735156 43988 5.65 9:00:00 94108 290168 75.51 0 118828 111600 735144 44000 5.65 9:10:01 97760 286516 74.56 0 108072 114948 735144 44000 5.65 9:20:09 26528 357748 93.1 0 8448 232728 732436 46708 5.99 9:30:01 77176 307100 79.92 0 13400 231164 731356 47788 6.13 9:40:01 59532 324744 84.51 0 17488 239024 731356 47788 6.13 9:50:01 48448 335828 87.39 0 20936 234456 730988 48156 6.18

10:00:01 51920 332356 86.49 0 23916 236200 730968 48176 6.18 10:10:01 5588 378688 98.55 0 26860 284840 729780 49364 6.34 10:20:09 5988 378288 98.44 0 12080 220976 726124 53020 6.8 10:30:00 54504 329772 85.82 0 16780 235692 726508 52636 6.76 10:40:00 53120 331156 86.18 0 19640 228324 726508 52636 6.76 10:50:00 43732 340544 88.62 0 22692 228624 726224 52920 6.79 11:00:00 29428 354848 92.34 0 26028 233696 726172 52972 6.8


11:10:00 48272 336004 87.44 0 29200 214708 726160 52984 6.8 11:20:01 59720 324556 84.46 0 26376 199716 722184 56960 7.31 11:30:00 42888 341388 88.84 0 27640 221908 719580 59564 7.64 11:40:00 25544 358732 93.35 0 28976 237264 718636 60508 7.77 11:50:03 4548 379728 98.82 0 12016 266912 717508 61636 7.91 12:00:01 31444 352832 91.82 0 16780 251824 717176 61968 7.95 12:10:00 12000 372276 96.88 0 22036 259116 717092 62052 7.96 12:20:03 4508 379768 98.83 0 24828 233588 716716 62428 8.01 12:30:08 10428 373848 97.29 0 10696 230276 716404 62740 8.05 12:40:01 4704 379572 98.78 0 18368 282072 716240 62904 8.07 12:50:01 14784 369492 96.15 0 22896 254360 715996 63148 8.1 13:00:00 16796 367480 95.63 0 27468 256528 715996 63148 8.1 13:10:01 25008 359268 93.49 0 32620 240440 715920 63224 8.11 13:20:00 25548 358728 93.35 0 35748 233376 715872 63272 8.12 13:30:06 4288 379988 98.88 0 26348 198564 714248 64896 8.33 13:40:00 23596 360680 93.86 0 32448 238416 715416 63728 8.18 13:50:00 21248 363028 94.47 0 32200 241068 715184 63960 8.21 14:00:01 17340 366936 95.49 0 32056 243628 715232 63912 8.2 14:10:00 36032 348244 90.62 0 26776 229416 715208 63936 8.21 14:20:02 6108 378168 98.41 0 29300 233036 715188 63956 8.21 14:30:00 15976 368300 95.84 0 29656 246040 715092 64052 8.22 14:40:00 24228 360048 93.7 0 29364 237776 715016 64128 8.23


14:50:01 57108 327168 85.14 0 25812 207376 715340 63804 8.19 15:00:00 10664 373612 97.22 0 30016 250640 715296 63848 8.19 15:10:00 30728 353548 92 0 30752 229456 715288 63856 8.2 15:20:00 19912 364364 94.82 0 31684 236888 715220 63924 8.2 15:30:04 10036 374240 97.39 0 27828 201816 715204 63940 8.21 15:40:01 20112 364164 94.77 0 29948 241208 715208 63936 8.21 15:50:01 26408 357868 93.13 0 29628 225976 715148 63996 8.21 16:00:04 4360 379916 98.87 0 30880 222352 714352 64792 8.32

26

Lampiran 3 Contoh data throughput server proxy dari CTM

Date Time ipaddr:Proxy18:wan:kbps ipaddr:proxy11:wan:kbps 12/27/2007 0:00 26.85 7.1712/27/2007 0:05 31.94 17.3312/27/2007 0:10 8.13 23.6512/27/2007 0:15 56.99 10.7212/27/2007 0:20 35.73 10.9812/27/2007 0:25 15.43 64.3812/27/2007 0:30 12.6 4212/27/2007 0:35 38.91 28.4612/27/2007 0:40 11.66 6.7512/27/2007 0:45 8.46 7.4912/27/2007 0:50 15.57 5.1312/27/2007 0:55 11.19 6.1812/27/2007 1:00 19.34 11.6212/27/2007 1:05 21.8 14.1912/27/2007 1:10 16.54 14.8912/27/2007 1:15 22.31 11.2312/27/2007 1:20 25.03 10.8112/27/2007 1:25 18.13 6.8812/27/2007 1:30 15.79 19.5712/27/2007 1:35 10.59 6.6712/27/2007 1:40 14.87 6.3212/27/2007 1:45 12.05 6.2412/27/2007 1:50 15.28 9.6112/27/2007 1:55 4.74 3.7712/27/2007 2:00 13.38 19.7412/27/2007 2:05 9.06 1.2312/27/2007 2:10 52.61 17.8112/27/2007 2:15 41.17 11.4212/27/2007 2:20 58.7 27.8912/27/2007 2:25 56.66 25.6312/27/2007 2:30 6.24 4.6212/27/2007 2:35 0.05 0.1612/27/2007 2:40 3 1.3212/27/2007 2:45 0.17 0.2212/27/2007 2:50 0.83 0.1312/27/2007 2:55 3.1 1.3612/27/2007 3:00 2.13 0.8712/27/2007 3:05 0.34 0.2612/27/2007 3:10 0.01 0.0412/27/2007 3:15 0.19 0.2412/27/2007 3:20 1.37 0.6812/27/2007 3:25 1.71 0.8512/27/2007 3:30 4.97 1.8812/27/2007 3:35 5.94 6.5112/27/2007 3:40 11.81 1.5112/27/2007 3:45 3.09 1.312/27/2007 3:50 12.91 2.8712/27/2007 3:55 13.99 2.4312/27/2007 4:00 22.09 9.1712/27/2007 4:05 14.46 8.2712/27/2007 4:10 15.36 5.5312/27/2007 4:15 18.62 5.5212/27/2007 4:20 19.82 4.1112/27/2007 4:25 9.21 3.3812/27/2007 4:30 4.71 0.8412/27/2007 4:35 13.65 5.7812/27/2007 4:40 10.06 1.1812/27/2007 4:45 6.13 5.0912/27/2007 4:50 2.98 1.1712/27/2007 4:55 2.39 1.4112/27/2007 5:00 5.52 4.6312/27/2007 5:05 7.19 6.712/27/2007 5:10 14.1 3.6912/27/2007 5:15 3.52 3.33

27

Lampiran 4 Contoh data pada akses log server proxy 1198720802.500 1168 172.17.33.42 TCP_MISS/200 843 GET http://ads.bridgetrack.com/event/? h24051995 DIRECT/216.250.59.67 image/GIF 1198720802.669 6673 172.17.65.180 TCP_MISS/200 469 GET http://row.bc.yahoo.com/b? a24052075 DIRECT/203.84.204.69 image/gif 1198720802.702 32 172.17.33.42 TCP_IMS_HIT/304 276 GET http://m1.2mdn.net/879366/flashwrite_1_2.js h24051995 NONE/- application/x-javascript 1198720802.924 425 172.17.65.194 TCP_MISS/200 452 POST http://windowsupdate.microsoft.com/redirect.asp? rita DIRECT/207.46.18.94 text/html 1198720802.934 6242 172.17.65.180 TCP_MISS/200 469 GET http://row.bc.yahoo.com/b? a24052075 DIRECT/203.84.204.69 image/gif 1198720802.968 3942 172.17.33.88 TCP_MISS/200 406 POST http://shttp.msg.yahoo.com/notify/ aminf DIRECT/216.155.194.239 text/plain 1198720803.026 62 172.17.1.74 TCP_MISS/304 255 GET http://klikvnet.com/images/sisbonus_07.gif danis DIRECT/202.158.18.222 - 1198720803.042 50 172.17.1.74 TCP_MISS/304 255 GET http://klikvnet.com/images/sisbonus_10.gif danis DIRECT/202.158.18.222 - 1198720803.071 45 172.17.1.74 TCP_MISS/304 254 GET http://klikvnet.com/images/keanggotaan_02.gif danis DIRECT/202.158.18.222 - 1198720803.087 587 172.17.1.161 TCP_MISS/200 406 POST http://shttp.msg.yahoo.com/notify/ novi_nn DIRECT/216.155.194.239 text/plain 1198720803.103 60 172.17.1.74 TCP_MISS/304 255 GET http://klikvnet.com/images/sisbonus_11.gif danis DIRECT/202.158.18.222 - 1198720803.110 305 172.17.1.74 TCP_MISS/200 26251 GET http://klikvnet.com/login.asp danis DIRECT/202.158.18.222 text/html 1198720803.127 274 172.17.33.42 TCP_MISS/200 20599 GET http://m1.2mdn.net/1533054/MX10_120x600_20k_18fps.swf? h24051995 DIRECT/125.160.16.42 application/x-shockwave-flash 1198720803.132 28 172.17.1.74 TCP_MISS/304 255 GET http://klikvnet.com/images/sisbonus_16.gif danis DIRECT/202.158.18.222 - 1198720803.149 38 172.17.1.74 TCP_MISS/304 255 GET http://klikvnet.com/images/sisbonus_17.gif danis DIRECT/202.158.18.222 - 1198720803.166 34 172.17.1.74 TCP_MISS/304 256 GET http://klikvnet.com/images/PROGRAM%20BINTANG%20BUTTON.gif danis DIRECT/202.158.18.222 - 1198720803.185 35 172.17.1.74 TCP_MISS/304 256 GET http://klikvnet.com/images/PROMO%20TOUR%20BUTTON.gif danis DIRECT/202.158.18.222 - 1198720803.196 2 172.17.65.156 TCP_DENIED/407 1922 GET http://msg.edit.yahoo.com/config/eval_register? - NONE/- text/html 1198720803.206 38 172.17.1.74 TCP_MISS/304 256 GET http://klikvnet.com/images/BONUS%20PROMO%20BUTTON.gif danis DIRECT/202.158.18.222 - 1198720803.211 25 172.17.1.74 TCP_MISS/304 256 GET http://klikvnet.com/images/20%20jt.gif danis DIRECT/202.158.18.222 - 1198720803.247 36 172.17.1.74 TCP_MISS/304 256 GET http://klikvnet.com/images/WEB%20MALL%20BUTTON.gif danis DIRECT/202.158.18.222 - 1198720803.255 49 172.17.1.74 TCP_MISS/304 256 GET http://klikvnet.com/images/ceremonia.gif danis DIRECT/202.158.18.222 - 1198720803.274 26 172.17.1.74 TCP_MISS/304 254 GET http://klikvnet.com/images/sisbonus_08.gif danis DIRECT/202.158.18.222 - 1198720803.284 28 172.17.1.74 TCP_MISS/304 254 GET http://klikvnet.com/images/story.png danis DIRECT/202.158.18.222 - 1198720803.307 32 172.17.1.74 TCP_MISS/304 256 GET http://klikvnet.com/images/Pensiun%20pin%20Emaskcl.jpg danis DIRECT/202.158.18.222 - 1198720803.322 38 172.17.1.74 TCP_MISS/304 255 GET http://klikvnet.com/images/gbr_motor.jpg danis DIRECT/202.158.18.222 - 1198720803.347 40 172.17.1.74 TCP_MISS/304 254 GET http://klikvnet.com/images/gbr_pc.jpg danis DIRECT/202.158.18.222 - 1198720803.354 282 172.17.1.74 TCP_MISS/304 255 GET http://klikvnet.com/images/sisbonus_13.gif danis DIRECT/202.158.18.222 - 1198720803.360 37 172.17.1.74 TCP_MISS/304 255 GET http://klikvnet.com/images/nokia6020.jpg danis DIRECT/202.158.18.222 - 1198720803.577 443 172.17.65.194 TCP_MISS/200 403 POST http://windowsupdate.microsoft.com/redirect.asp? rita DIRECT/207.46.18.94 text/html 1198720803.677 573 172.17.66.23 TCP_MISS/200 406 POST http://shttp.msg.yahoo.com/notify/ erizal DIRECT/216.155.194.239 text/plain 1198720804.314 16 172.17.65.146 TCP_DENIED/407 2090 GET http://watson.microsoft.com/StageOne/Generic/AppHangB1/wmplayer_exe/11_0_6000_6324/4549b52a/dc25/1.htm? - NONE/- text/html 1198720804.817 11031 172.17.33.92 TCP_MISS/200 28736 CONNECT login.yahoo.com:443 dinayuniar DIRECT/209.73.168.74 - 1198720805.113 961 172.17.33.92 TCP_MISS/200 406 POST http://shttp.msg.yahoo.com/notify/ dinayuniar DIRECT/216.155.194.239 text/plain

28

Lampiran 5 Langkah implementasi mekanisme load balancing pada server proxy di IPB

Director Master 1. Instal ipvsadm (lihat bagian A) 2. Instal keepalived (lihat bagian B) 3. Ubah file konfigurasi pada /usr/local/etc/keepalived/keepalived.conf ! Configuration File for keepalived global_defs { ! notification_email { ! [email protected] ! } ! notification_email_from [email protected] ! smtp_server 127.0.0.1 ! smtp_connect_timeout 30 router_id LVS_DIRECTOR } vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 150 advert_int 1 authentication { auth_type AH auth_pass proxyIPB } virtual_ipaddress { 172.17.0.11 brd 172.17.0.11 172.17.0.18 brd 172.17.0.18 } } virtual_server 172.17.0.11 8080 { delay_loop 6 lb_algo rr lb_kind DR ! persistence_timeout 1 protocol TCP ! sorry_server 172.18.78.22 80 real_server 172.17.0.19 8080 { weight 1 TCP_CHECK { connect_timeout 7 } } real_server 172.17.0.20 8080 { weight 1 TCP_CHECK { connect_timeout 7 } } }

29

Lampiran 5 Lanjutan.

virtual_server 172.17.0.18 8080 { delay_loop 6 lb_algo wrr lb_kind DR ! persistence_timeout 1 protocol TCP ! sorry_server 172.18.78.22 80 real_server 172.17.0.19 8080 { weight 1 TCP_CHECK { connect_timeout 7 } } real_server 172.17.0.20 8080 { weight 1 TCP_CHECK { connect_timeout 7 } } } virtual_server 172.17.0.11 22 { delay_loop 6 lb_algo wrr lb_kind DR protocol TCP real_server 172.17.0.19 22 { weight 1 TCP_CHECK {

connect_timeout 7 } } } virtual_server 172.17.0.18 22 { delay_loop 6 lb_algo rr lb_kind DR protocol TCP real_server 172.17.0.20 22 { weight 1 TCP_CHECK { connect_timeout 7 } } } 4. Tambahkan baris perintah berikut pada file /etc/rc.local #Menambah rute ke alamat virtual ip /sbin/route add -host 172.17.0.11 dev eth0

30

Lampiran 5 Lanjutan

/sbin/route add -host 172.17.0.18 dev eth0 #Memastikan firewall dinonaktifkan /sbin/iptables –flush #Menjalankan keepalived dengan menggunakan konfigurasi pada file keepalived.conf /usr/local/sbin/keepalived -f /usr/local/etc/keepalived/keepalived.conf 5. Lakukan reboot. Director Backup Pada director backup, lakukan langkah yang sama seperti pada director master. Perbedaan hanya terletak pada file konfigurasi keepalived bagian berikut: vrrp_instance VI_1 { state BACKUP interface eth0 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type AH auth_pass proxyIPB } virtual_ipaddress { 172.17.0.11 brd 172.17.0.11 172.17.0.18 brd 172.17.0.18 } } Server Proxy 1. Setting interface loopback supaya tidak menjawab ARP request

Untuk kernel di bawah 2.4.26 harus dilakukan patch hidden dan rebuild kernel, kemudian aktifkan flag hidden: echo “1” > /proc/sys/net/ipv4/conf/all/hidden echo “1” > /proc/sys/net/ipv4/conf/lo/hidden Untuk kernel di atas 2.4.26, aktifkan flag arp_ignore: echo “1” > /proc/sys/net/ipv4/conf/all/arp_ignore echo “1” > /proc/sys/net/ipv4/conf/lo/arp_ignore

2. Tambahkan baris perintah berikut pada file /etc/rc.local #Setting interface loopback supaya tidak menjawab ARP request (lihat point 1) #echo … #Setting ip virtual pada interface loopback /sbin/ifconfig lo:7 172.17.0.11 broadcast 172.17.0.11 netmask 255.255.255.255 up /sbin/ifconfig lo:17 172.17.0.18 broadcast 172.17.0.18 netmask 255.255.255.255 up #Menambah rute ke alamat virtual ip /sbin/route add –host 172.17.0.11 dev lo:7 /sbin/route add –host 172.17.0.18 dev lo:17

31

Lampiran 5 Lanjutan

A. Instalasi ipvsadm Langkah-langkah instalasi ipvsadm pada Linux FC 6 (disesuaikan untuk distro yang lain): Pastikan gcc sudah terinstal, caranya dengan mengetik gcc. Jika sudah terinstal, maka output yang

dihasilkan sebagai berikut: [root@localhost david]# gcc gcc: no input files Jika gcc belum terinstall, lakukan instalasi gcc terlebih dahulu.

Pastikan kernel-devel sudah terinstal. Caranya sebagai berikut: [root@localhost ~]# rpm -qa |grep kernel-devel kernel-devel-2.6.18-1.2798.fc6 Jika kernel-devel belum terinstal, lakukan instalasi kernel-devel-2.6.18-1.2798.fc6.i686.rpm pada /usr/src

Buat link simbolik dari kernel (2.6.18-1.2798.fc6-i686) dengan nama linux pada /usr/src. Caranya sebagai berikut: ln -s 2.6.18-1.2798.fc6-i686 linux

Buat folder /usr/src/redhat/SOURCES (jika belum ada) Kopi file instalasi ipvsadm (ipvsadm-1.24-6.src.rpm) pada /usr/src/redhat/SOURCES Install file tersebut dengan perintah rpm -i ipvsadm-1.24-6.src.rpm Akan dihasilkan ipvsadm-1.24.tar.gz Ekstrak file tersebut dengan perintah tar -xzf ipvsadm-1.24.tar.gz Akan dihasilkan folder ipvsadm-1.24 Masuk ke folder tersebut dan ketik make kemudian make install Pesan kesalahan yang muncul jika gcc belum terinstal: [root@localhost ipvsadm-1.24]# make make -C libipvs make[1]: Entering directory `/usr/src/redhat/SOURCES/ipvsadm-1.24/libipvs' gcc -Wall -Wunused -Wstrict-prototypes -g -O2 -I/usr/src/linux/include -DHAVE_NET_IP_VS_H -c -o libipvs.o libipvs.c make[1]: gcc: Command not found make[1]: *** [libipvs.o] Error 127 make[1]: Leaving directory `/usr/src/redhat/SOURCES/ipvsadm-1.24/libipvs' make: *** [libs] Error 2 Solusi: lakukan instalasi gcc (dan dependenciesnya) yang terdapat pada cd kedua (2) FC6 • gcc-4.1.1-30.i386.rpm • glibc-devel-2.5-3.i386.rpm • glibc-headers-2.5-3.i386.rpm • libgomp-4.1.1-30.i386.rpm Apabila kita belum melakukan langkah 3 akan muncul pesan kesalahan berikut: [root@localhost ipvsadm-1.24]# make make -C libipvs make[1]: Entering directory `/usr/src/redhat/SOURCES/ipvsadm-1.24/libipvs' gcc -Wall -Wunused -Wstrict-prototypes -g -O2 -I/usr/src/linux/include -DHAVE_NET_IP_VS_H -c -o libipvs.o libipvs.c In file included from libipvs.c:23: libipvs.h:14:23: error: net/ip_vs.h: No such file or directory In file included from libipvs.c:23: libipvs.h:119: error: expected ‘)’ before ‘fwmark’

32

Lampiran 5 Lanjutan

libipvs.c:27: error: field ‘svc’ has incomplete type libipvs.c:28: error: field ‘dest’ has incomplete type libipvs.c: In function ‘ipvs_init’: libipvs.c:40: error: invalid application of ‘sizeof’ to incomplete type ‘struct ip_vs_getinfo’ libipvs.c:44: error: ‘IP_VS_SO_GET_INFO’ undeclared (first use in this function) [DIPOTONG] libipvs.c:293: error: ‘IP_VS_SO_GET_TIMEOUT’ undeclared (first use in this function) libipvs.c: In function ‘ipvs_get_daemon’: libipvs.c:309: error: dereferencing pointer to incomplete type libipvs.c:315: error: ‘IP_VS_SO_GET_DAEMON’ undeclared (first use in this function) libipvs.c: In function ‘ipvs_strerror’: libipvs.c:357: error: ‘ipvs_get_service’ undeclared (first use in this function) make[1]: *** [libipvs.o] Error 1 make[1]: Leaving directory `/usr/src/redhat/SOURCES/ipvsadm-1.24/libipvs' make: *** [libs] Error 2 Solusi: lakukan langkah 3. B. Instalasi keepalived

1. Pastikan openssl dan openssl-devel sudah terinstal rpm –qa | grep openssl Jika belum terinstal, lakukan instalasi openssl dan openssl-devel terlebih dahulu

2. Ekstrak file keepalived-1.1.15.tar.gz 3. Masuk ke folder keepalived-1.1.15 4. Lakukan ./configure kemudian make dan make install

Catatan: Langkah implementasi di atas bersifat spesifik untuk kondisi di IPB pada saat penelitian dilakukan. Untuk informasi yang lebih lengkap, dapat merujuk ke dokumen referensi dalam CD skripsi seperti LVS-HOWTO dan User Guide Keepalived.

33

Lampiran 6 Grafik utilisasi CPU sebelum implementasi mekanisme load balancing

34

Lampiran 6 Lanjutan

35

Lampiran 7 Grafik utilisasi memori sebelum implementasi mekanisme load balancing

36

Lampiran 7 Lanjutan

37

Lampiran 8 Grafik throughput sebelum implementasi mekanisme load balancing

38

Lampiran 8 Lanjutan

39

Lampiran 9 Tabel hasil perhitungan jumlah koneksi, jumlah hit dan hit ratio

Data ke‐ Tanggal Jumlah Koneksi Jumlah Hit Hit Ratio

Proxy 11 Proxy 18 Proxy 11 Proxy 18 Proxy 11 Proxy 18

1 4 Desember 2007 1535234 2400168 282258 215105 18.38534 8.962081

2 5 Desember 2007 1483489 2812764 323803 215269 21.82713 7.653291

3 6 Desember 2007 1494234 3425688 401980 270339 26.90208 7.891524

4 7 Desember 2007 1282305 2794419 246186 254867 19.19871 9.120572

5 10 Desember 2007 1162849 2441053 274638 236008 23.61768 9.668287

6 11 Desember 2007 1730215 2366341 307408 265723 17.76704 11.22928

7 12 Desember 2007 1386175 2804329 347997 276680 25.10484 9.866175

8 13 Desember 2007 1288555 6728678 314553 287092 24.4113 4.266693

9 14 Desember 2007 1563792 2727126 364097 337019 23.28296 12.35803

10 17 Desember 2007 1512483 4457328 311530 244661 20.59726 5.488961

11 18 Desember 2007 2598561 2747008 385837 445833 14.8481 16.22977

12 19 Desember 2007 1937572 2230644 281148 354024 14.51033 15.87093

13 27 Desember 2007 1243137 2917104 188808 512463 15.18803 17.56753

14 28 Desember 2007 1267267 3363590 188175 425830 14.84888 12.65999

15 2 Januari 2008 1373679 2356117 216011 430778 15.725 18.28339

16 3 Januari 2008 1079530 1858273 186731 343801 17.29743 18.5011

17 4 Januari 2008 923536 2824536 155684 512278 16.85738 18.13671

18 7 Januari 2008 1262308 2403886 265608 525147 21.04146 21.84575

40

Lampiran 10 Contoh tabel perhitungan CDF pada saat pembobotan 1:1 (tanggal 18 dan 19 Desember 2007)

j Utilisasi CPU

U max

j Utilisasi CPU

U max x CDF(x)

Proxy 11 Proxy 18 Proxy 11 Proxy 18 5 0 1 13.24 100 100 54 52.69 8.7 52.69 10 0.010204 2 14.25 100 100 55 58.73 10.21 58.73 15 0.030612 3 16.83 100 100 56 53.35 11.61 53.35 20 0.030612 4 28.18 100 100 57 82.43 42.19 82.43 25 0.040816 5 30.93 100 100 58 67.15 12.43 67.15 30 0.040816 6 29.98 100 100 59 62.54 11.68 62.54 35 0.05102 7 39.75 100 100 60 58.73 10.74 58.73 40 0.05102 8 52.58 100 100 61 62.98 17.67 62.98 45 0.05102 9 52.8 100 100 62 64.76 17.16 64.76 50 0.05102 10 68.54 100 100 63 72.41 16.83 72.41 55 0.071429 11 79.27 100 100 64 83.34 30.65 83.34 60 0.091837 12 82.3 100 100 65 88.98 40.37 88.98 65 0.122449 13 100 100 100 66 92.21 43.35 92.21 70 0.132653 14 100 100 100 67 92.54 49.75 92.54 75 0.142857 15 69.66 100 100 68 94.61 62.41 94.61 80 0.173469 16 83.66 100 100 69 94.97 63.33 94.97 85 0.255102 17 92.43 100 100 70 94.81 63.53 94.81 90 0.469388 18 93.44 100 100 71 92.75 67.81 92.75 95 0.734694 19 92.86 100 100 72 94.97 75.4 94.97 100 1 20 94.4 60.07 94.4 73 98.3 77.54 98.3 21 93.06 59.2 93.06 74 97.15 75.96 97.15 22 90.31 59.87 90.31 75 93.43 68.69 93.43 23 93 54.94 93 76 89.55 58.15 89.55 24 10.47 13.28 13.28 77 88.13 47.87 88.13 25 79.18 27.5 79.18 78 89.62 29.95 89.62 26 89.77 44.31 89.77 79 83.74 31.28 83.74 27 91.34 46.24 91.34 80 86.33 36.85 86.33 28 97.07 50.58 97.07 81 87.87 36.93 87.87 29 89.78 47.7 89.78 82 100 27.94 100 30 85.3 48.44 85.3 83 82.2 21.02 82.2 31 87.33 41.5 87.33 84 76.7 23.94 76.7 32 89.42 43.75 89.42 85 77.39 26.26 77.39 33 93.66 54.3 93.66 86 84.46 39.09 84.46 34 94.18 59.74 94.18 87 84.99 42 84.99 35 96.33 62.23 96.33 88 86.44 33.62 86.44 36 95.82 65.85 95.82 89 92.11 47.61 92.11 37 94.09 65.73 94.09 90 88.77 37.07 88.77 38 89.68 57.92 89.68 91 89.25 43.81 89.25 39 100 8.78 100 92 93.29 56.6 93.29 40 86.65 15.86 86.65 93 94.29 55.46 94.29 41 82.26 34.82 82.26 94 93.25 63.85 93.25 42 85.91 44.14 85.91 95 91.73 64.68 91.73 43 85.94 48.88 85.94 96 94.26 64.57 94.26 44 90.2 49.73 90.2 97 93.5 67.21 93.5 45 88.01 48.41 88.01 98 93.2 57.26 93.2 46 93.51 48.88 93.51 47 89.38 60.13 89.38 48 84.7 48.66 84.7 49 85.45 33.55 85.45 50 8.86 0.73 8.86 51 11.56 1.84 11.56 52 23.27 3.81 23.27 53 33.55 4.74 33.55

41

Lampiran 11 Contoh tabel perhitungan SD pada saat pembobotan 1:2 (tanggal 27 dan 28 Desember 2007)

j Utilisasi CPU

U avg SD

j Utilisasi CPU

U avg SD Proxy 11 Proxy 18 Proxy 11 Proxy 18

1 6.86 0.53 3.695 3.165 54 18.55 5.16 11.855 6.695 2 7.68 0.72 4.2 3.48 55 18.68 6.33 12.505 6.175 3 7.28 0.91 4.095 3.185 56 20.81 11.45 16.13 4.68 4 7.57 1 4.285 3.285 57 31.67 50.56 41.115 9.445 5 7.94 0.98 4.46 3.48 58 33.64 27.01 30.325 3.315 6 9.31 1.81 5.56 3.75 59 34.93 21.56 28.245 6.685 7 9.46 1.84 5.65 3.81 60 46.57 28.47 37.52 9.05 8 19.72 9.76 14.74 4.98 61 55.45 35.84 45.645 9.805 9 28.29 3.78 16.035 12.255 62 64.98 51.09 58.035 6.945 10 21.51 3.46 12.485 9.025 63 67.15 58.62 62.885 4.265 11 28.1 28.54 28.32 0.22 64 65.37 60.91 63.14 2.23 12 26.09 53.11 39.6 13.51 65 66.15 66.65 66.4 0.25 13 28.33 69.44 48.885 20.555 66 63.86 65.18 64.52 0.66 14 44.79 78.72 61.755 16.965 67 63.85 66.16 65.005 1.155 15 43.74 81.45 62.595 18.855 68 71.54 72.73 72.135 0.595 16 48.38 85.48 66.93 18.55 69 70.17 74.74 72.455 2.285 17 53.72 89.81 71.765 18.045 70 83.04 70.48 76.76 6.28 18 55.08 91.01 73.045 17.965 71 91.21 70.48 80.845 10.365 19 68.51 97.12 82.815 14.305 72 61.38 64 62.69 1.31 20 60.72 96.21 78.465 17.745 73 55.73 59.19 57.46 1.73 21 72.42 95.32 83.87 11.45 74 51.35 54.37 52.86 1.51 22 78.69 90.29 84.49 5.8 75 40.16 36.58 38.37 1.79 23 79.87 89.23 84.55 4.68 76 46.46 47.62 47.04 0.58 24 84.48 89.32 86.9 2.42 77 51.04 54.26 52.65 1.61 25 66.82 86.85 76.835 10.015 78 44.5 53.11 48.805 4.305 26 77.59 69 73.295 4.295 79 45.46 48.81 47.135 1.675 27 72.16 73.26 72.71 0.55 80 37.32 31.54 34.43 2.89 28 87.04 66.61 76.825 10.215 81 44.2 32.62 38.41 5.79 29 76.16 63.67 69.915 6.245 82 45.59 35.91 40.75 4.84 30 74.78 69.2 71.99 2.79 83 42.91 33.42 38.165 4.745 31 66.85 65.75 66.3 0.55 84 46.26 33.87 40.065 6.195 32 67.22 68.43 67.825 0.605 85 66.57 60.95 63.76 2.81 33 70.89 72.13 71.51 0.62 86 66.81 65.04 65.925 0.885 34 65.99 69.35 67.67 1.68 87 77.48 76.75 77.115 0.365 35 69.98 78.26 74.12 4.14 88 71.82 81.04 76.43 4.61 36 72.98 76.83 74.905 1.925 89 70.46 76.62 73.54 3.08 37 75.19 82.7 78.945 3.755 90 73.48 77.31 75.395 1.915 38 75.52 81.71 78.615 3.095 91 72.82 79.14 75.98 3.16 39 78.98 82.72 80.85 1.87 92 63.29 76.54 69.915 6.625 40 80.18 86.58 83.38 3.2 93 66.24 76.92 71.58 5.34 41 79.75 86.49 83.12 3.37 94 63.93 71.64 67.785 3.855 42 78.5 86.82 82.66 4.16 95 65.61 71.17 68.39 2.78 43 79.08 86.5 82.79 3.71 96 69.37 71.33 70.35 0.98 44 78.85 85.55 82.2 3.35 97 67.86 76.34 72.1 4.24 45 82.91 87.22 85.065 2.155 98 70.41 63.33 66.87 3.54 46 78.05 84.11 81.08 3.03 47 73.27 72.96 73.115 0.155 SD rata‐rata 5.25602 48 68.98 69.94 69.46 0.48 49 64.56 62.9 63.73 0.83 50 18.3 3.72 11.01 7.29 51 20.81 4.35 12.58 8.23 52 23.89 3.53 13.71 10.18 53 23.15 8.98 16.065 7.085

42

Lampiran 12 Tabel hasil perhitungan keseluruhan koneksi, hit dan hit ratio

Data ke‐ Tanggal Total Koneksi Total Hit Total Hit Ratio

1 4 Desember 2007 3935402 497363 12.63817521

2 5 Desember 2007 4296253 539072 12.54749197

3 6 Desember 2007 4919922 672319 13.66523697

4 7 Desember 2007 4076724 501053 12.2905794

5 10 Desember 2007 3603902 510646 14.16925321

6 11 Desember 2007 4096556 573131 13.99055695

7 12 Desember 2007 4190504 624677 14.90696584

8 13 Desember 2007 8017233 601645 7.504397091

9 14 Desember 2007 4290918 701116 16.33953387

10 17 Desember 2007 5969811 556191 9.316727112

11 18 Desember 2007 5345569 831670 15.55811926

12 19 Desember 2007 4168216 635172 15.23846173

13 27 Desember 2007 4160241 701271 16.85649942

14 28 Desember 2007 4630857 614005 13.25899288

15 2 Januari 2008 3729796 646789 17.34113608

16 3 Januari 2008 2937803 530532 18.05880108

17 4 Januari 2008 3748072 667962 17.82148262

18 7 Januari 2008 3666194 790755 21.56882587

Hit ratio rata‐rata sebelum implementasi = sum(Data 1‐ Data 8) = 12.71 10 Hit ratio rata‐rata sesudah implementasi = sum (Data 11‐Data 18) = 16.96 8

implementasi dan evaluasi kinerja load balancing … · meningkatkan realibilitas, skalabilitas,...

Documents