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

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

: Implementasi dan Evaluasi Kinerja Load Balancing pada Server-server Proxy di IPB : David Thamrin : G64103002

Menyetujui Pembimbing I,

Pembimbing II,

Heru Sukoco S.Si., M.T NIP 132 282 666

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 masamasa 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 LVSTUN (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 LVSNAT 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

Gambar 4 Virtual server dengan direct routing.

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 MetodeMetode 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 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 dilaksanakan adalah sebagai berikut: 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 Gambar 7 Metodologi penelitian.

yang

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 masingmasing 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 masingmasing 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 masingmasing realserver setiap interval waktu tertentu. Apabila terdapat realserver yang tidak menjawab sinyal yang dikirimkan, maka keepalived akan menganggap realserver tersebut rusak dan mengeluarkannya dari tabel layanan load balancing. Seandainya realserver tersebut kembali berfungsi, maka keepalived akan memasukkannya kembali ke dalam tabel layanan load balancing. Mekanisme pengecekan kesehatan ini memberikan availabilitas yang tinggi terhadap sistem load balancing karena pengguna akan selalu memperoleh layanan tanpa mengetahui bahwa bagian dari sistem telah mengalami kerusakan ataupun sedang mengalami perbaikan. Keepalived juga menyediakan mekanisme yang disebut director failover untuk mengatasi masalah single point of failure dengan menggunakan protokol VRRP. Apabila director pertama rusak maka tugasnya dapat langsung diambil alih oleh director cadangan. Teknis Implementasi Pada tahap implementasi, terdapat beberapa hal teknis yang harus menjadi perhatian. • Kebutuhan minimum Kebutuhan minimum untuk dapat mengimplementasikan mekanisme load balancing yang sudah ditetapkan adalah: 9 Ipvs 9 Kernel devel linux 9 Compiler gcc

10

9 Openssl 9 Popt 9 Ipvsadm 9 Keepalived • Masalah ARP Pada metode LVS-DR yang digunakan, alamat Virtual IP (VIP) digunakan bersama oleh director dan realserver, namun pengguna tidak boleh mengetahui hal tersebut. Pengguna hanya tahu bahwa alamat VIP dipegang oleh director. Oleh karena itu, realserver harus dikonfigurasi agar tidak menjawab permintaan ARP. Untuk mengatasi masalah ARP, pada server proxy yang menggunakan linux kernel 2.6.13 cukup dengan menonaktifkan flag arp_ignore yang sudah tersedia. Pada server proxy dengan kernel 2.4.21, belum tersedia flag tersebut sehingga perlu dilakukan patch dan recompile kernel terlebih dahulu. • Firewall Konfigurasi firewall pada director harus disesuaikan agar tidak memblok paket yang melaluinya. • Konfigurasi squid Konfigurasi squid pada kedua server proxy harus disamakan, khususnya dalam hal filter.

Kebijakan Implementasi Implementasi mekanisme load balancing di IPB mempertimbangkan dua alternatif kebijakan implementasi. Pertama, director diberikan alamat IP yang baru (172.17.0.17) dan membagi request kepada proxy 172.17.0.11 dan proxy 172.17.0.18. Apabila menggunakan alternatif ini, maka perubahan ini harus diinformasikan kepada seluruh lingkungan pengguna proxy di IPB untuk mengarahkan proxynya ke alamat IP 172.17.0.17. Hal ini tentunya akan memakan cukup banyak waktu hingga seluruh pengguna mengikuti kebijakan tersebut. Selain itu dikhawatirkan tidak semua pengguna akan mengikuti kebijakan tersebut mengingat server proxy 172.17.0.11 dan 172.17.0.18 tetap dapat diakses oleh pengguna. Alternatif yang kedua, director disetting untuk memegang alamat IP 172.17.0.11 dan 172.17.0.18 (sebagai alamat IP virtual), kemudian alamat IP server proxy diganti menjadi alamat yang lain. Keuntungan dari alternatif ini adalah kita pengguna sama sekali tidak perlu diberitahu mengenai perubahan yang terjadi. Pengguna tetap menggunakan

alamat proxy .18 atau .11 tanpa mengetahui bahwa alamat tersebut telah dimiliki oleh director. Director kemudian tinggal membagi permintaan yang masuk ke alamat proxy yang sesungguhnya. Berdasarkan pertimbangan dari sisi transparansinya, maka alternatif kebijakan kedua yang digunakan. Gambar 9 menunjukkan topologi jaringan director dan server proxy di IPB dan Gambar 10 menunjukkan arsitektur LVS di IPB.

Gambar 9 Topologi jaringan director dan server proxy di IPB.

Gambar 10 Arsitektur LVS di IPB. Analisis Spesifikasi Komputer yang Digunakan sebagai Director Spesifikasi komputer yang digunakan sebagai director adalah sebagai berikut: Komputer director master (172.17.0.50) • Sistem Operasi Linux Fedora Core 6, kernel 2.6.18-1.2798.fc6 • Prosesor: Intel(R) Pentium (R) 4 CPU 3.00GHz • Harddisk 80 GB • RAM 384 MB

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, untuk setiap server terdapat utilisasi 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:

adalah jumlah slot dengan 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.

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. Gambar 11 Utilisasi CPU 4 Desember 2007.

Gambar 14 Utilisasi memori 5 Desember 2007. Gambar 12 Utilisasi CPU 5 Desember 2007. Dari grafik sekilas tampak bahwa ternyata utilisasi CPU sebelum implementasi load balancing sudah cukup merata pada kedua server proxy di IPB. Hal ini berarti

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.

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

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 17 Jumlah koneksi sebelum implementasi mekanisme load balancing.

Gambar 15 Throughput 4 Desember 2007.


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.

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

Gambar 18 Hit ratio sebelum implementasi mekanisme load balancing.

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.

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

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

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.

Gambar 23 Utilisasi CPU 27 Desember 2007.



Gambar 22 Utilisasi CPU 19 Desember 2007. 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

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

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

Gambar 29 Utilisasi memori 18 Desember 2007.

Gambar 30 Utilisasi memori 19 Desember 2007. Gambar 27 Utilisasi CPU 4 Januari 2008.

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

Gambar 28 Utilisasi CPU 7 Januari 2008. Pembobotan 3:5 memberikan hasil utilisasi CPU yang tidak jauh berbeda dibandingkan dengan pembobotan 2:3 karena memang nilai keduanya cukup dekat.


17


Gambar 35 Utilisasi memori 4 Januari 2008.

Gambar 33 dan Gambar 34 menunjukkan grafik utilisasi memori pada saat pembobotan 2:3 yaitu pada tanggal 2 dan 3 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.

Gambar 34 Utilisasi memori 3 Januari 2008. Gambar 35 dan Gambar 36 menunjukkan grafik utilisasi memori pada saat pembobotan 3:5 yaitu pada tanggal 4 dan 7 Januari 2008. Gambar 37 Throughput 18 Desember 2007.

18


Gambar 41 Throughput 2 Januari 2008.

Grafik di atas menunjukkan dengan jelas bahwa pembobotan 1:1 mempunyai arti bahwa kedua server proxy memperoleh beban pekerjaan yang sama sehingga grafik throughput kedua server proxy tampak berhimpitan satu dengan yang lain. Gambar 39 dan Gambar 40 menunjukkan grafik throughput pada saat pembobotan 1:2 yaitu pada tanggal 27 dan 28 Desember 2007. Gambar 42 Throughput 3 Januari 2008. Gambar 43 dan Gambar 44 menunjukkan grafik throughput pada saat pembobotan 3:5 yaitu pada tanggal 4 dan 7 Januari 2008.


Gambar 43 Throughput 4 Januari 2008.

Gambar 40 Throughput 29 Desember 2007. Gambar 41 dan Gambar 42 menunjukkan grafik throughput pada saat pembobotan 2:3 yaitu pada tanggal 2 dan 3 Januari 2008. Gambar 44 Throughput 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.

e. Hit ratio Hit ratio setelah masing-masing server proxy setelah implementasi load balancing dapat dilihat pada Gambar 46.

Gambar 46 Hit ratio setelah implementasi mekanisme load balancing. Setelah implementasi load balancing, hit ratio pada kedua server proxy mengalami perubahan dimana hit ratio pada server proxy 172.17.0.11 mengalami penurunan sedangkan hit ratio pada server proxy 172.17.0.18 mengalami peningkatan.

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.

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 50 Hit ratio keseluruhan. 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.

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

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

DAFTAR PUSTAKA

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

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 Networking Academy Program.

Cisco

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/E0500 e.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].

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_ter m/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=1 79&Cid=22&cp=1&Eid=6 [25 Okt 2007]

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/~sgtath am/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) 8:00:01 8:00:01 8:10:01 8:20:01 8:30:01 8:40:01 8:50:01 9:00:01 9:10:01 9:20:01 9:30:01 9:40:01 9:50:01 10:00:01 10:10:01 10:20:01 10:30:01 10:40:01 10:50:01 11:00:02 11:00:02 11:10:02 11:20:02 11:30:02 11:40:02 11:50:02 12:00:01 12:10:01 12:20:01 12:30:01 12:40:01 12:50:01 1:00:01 1:10:01 1:20:01 1:30:01 1:40:01 1:50:01 2:00:02 2:10:02 2:20:02 2:30:02 2:40:02 2:40:02 2:50:02 3:00:01 3:10:01 3:20:01 3:30:01 3:40:01 3:50:01 4:00:02

AM AM AM AM AM AM AM AM AM AM AM AM AM AM AM AM AM AM AM AM AM AM AM AM AM AM PM PM PM PM PM PM PM PM PM PM PM PM PM PM PM PM PM PM PM PM PM PM PM PM PM PM

CPU all all all all all all all all all all all all all all all all all all all CPU all all all all all all all all all all all all all all all all all all all all all all CPU all all all all all all all all

12/27/2007 %user 0.34 0.42 0.45 0.54 0.56 0.83 0.92 1.75 1.87 1.41 8.99 16.34 21.09 23.97 25.54 26.46 30 31.82 34.26

%nice 0 0 0 0 0 0 0 3.25 0 0 0 0 0 0 0 0 0 0 0

%system 0.19 0.3 0.46 0.46 0.42 0.98 0.93 4.76 1.91 2.05 19.55 36.77 48.36 54.75 55.91 59.02 59.81 59.2 62.86

%idle 99.47 99.28 99.09 99 99.02 98.19 98.16 90.24 96.22 96.54 71.46 46.89 30.56 21.28 18.55 14.52 10.19 8.99 2.88

%user 33.48 33.51 31.5 30.04 29.07 28.17 23.32 24.55 21.17 20.57 23.67 20.68 21.24 23.66 22.26 24.77 24.5 25.34 25.73 26.09 27.8 27.42

%nice 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

%system 62.73 61.81 58.8 59.18 60.26 58.68 45.68 48.71 45.44 43.1 45.53 45.07 47.19 48.47 47.09 53.49 52.33 57.35 55.98 56.63 58.78 59.07

%idle 3.79 4.68 9.71 10.77 10.68 13.15 31 26.74 33.39 36.33 30.8 34.25 31.57 27.87 30.65 21.74 23.17 17.3 18.29 17.28 13.42 13.51

%user 27.9 27.78 27.43 27.99 26.78 23.09 22.11 19.75

%nice 0 0 0 0 0 0 0 0

%system 58.92 58.72 58.11 59.23 57.32 49.87 47.83 43.15

%idle 13.18 13.5 14.45 12.78 15.89 27.04 30.06 37.1

25

Lampiran 2 Contoh data penggunaan memori pada server proxy di IPB Linux 2.4.21-exp (nms.ipb.ac.id) 8:00:01 8:00:01 8:10:00 8:20:00 8:30:00 8:40:00 8:50:00 9:00:00 9:10:01 9:20:09 9:30:01 9:40:01 9:50:01 10:00:01 10:10:01 10:20:09 10:30:00 10:40:00 10:50:00 11:00:00

kbmemfree

11:00:00 11:10:00 11:20:01 11:30:00 11:40:00 11:50:03 12:00:01 12:10:00 12:20:03 12:30:08 12:40:01 12:50:01 13:00:00 13:10:01 13:20:00 13:30:06 13:40:00 13:50:00 14:00:01 14:10:00 14:20:02 14:30:00 14:40:00

kbmemfree

14:40:00 14:50:01 15:00:00 15:10:00 15:20:00 15:30:04 15:40:01 15:50:01 16:00:04

114336 115132 114660 115036 112824 112620 94108 97760 26528 77176 59532 48448 51920 5588 5988 54504 53120 43732 29428

48272 59720 42888 25544 4548 31444 12000 4508 10428 4704 14784 16796 25008 25548 4288 23596 21248 17340 36032 6108 15976 24228 kbmemfree

57108 10664 30728 19912 10036 20112 26408 4360

kbmemused

269940 269144 269616 269240 271452 271656 290168 286516 357748 307100 324744 335828 332356 378688 378288 329772 331156 340544 354848 kbmemused

336004 324556 341388 358732 379728 352832 372276 379768 373848 379572 369492 367480 359268 358728 379988 360680 363028 366936 348244 378168 368300 360048 kbmemused

327168 373612 353548 364364 374240 364164 357868 379916

12/27/07 %memused

70.25 70.04 70.16 70.06 70.64 70.69 75.51 74.56 93.1 79.92 84.51 87.39 86.49 98.55 98.44 85.82 86.18 88.62 92.34 %memused

87.44 84.46 88.84 93.35 98.82 91.82 96.88 98.83 97.29 98.78 96.15 95.63 93.49 93.35 98.88 93.86 94.47 95.49 90.62 98.41 95.84 93.7 %memused

85.14 97.22 92 94.82 97.39 94.77 93.13 98.87

kbmemshrd

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 kbmemshrd

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 kbmemshrd

0 0 0 0 0 0 0 0

kbbuffers

151692 146916 141888 137480 134872 122832 118828 108072 8448 13400 17488 20936 23916 26860 12080 16780 19640 22692 26028 kbbuffers

29200 26376 27640 28976 12016 16780 22036 24828 10696 18368 22896 27468 32620 35748 26348 32448 32200 32056 26776 29300 29656 29364 kbbuffers

25812 30016 30752 31684 27828 29948 29628 30880

kbcached

65744 67928 73500 75672 79272 90216 111600 114948 232728 231164 239024 234456 236200 284840 220976 235692 228324 228624 233696 kbcached

214708 199716 221908 237264 266912 251824 259116 233588 230276 282072 254360 256528 240440 233376 198564 238416 241068 243628 229416 233036 246040 237776 kbcached

207376 250640 229456 236888 201816 241208 225976 222352

kbswpfree

735168 735168 735168 735168 735156 735156 735144 735144 732436 731356 731356 730988 730968 729780 726124 726508 726508 726224 726172 kbswpfree

726160 722184 719580 718636 717508 717176 717092 716716 716404 716240 715996 715996 715920 715872 714248 715416 715184 715232 715208 715188 715092 715016 kbswpfree

715340 715296 715288 715220 715204 715208 715148 714352

kbswpused

43976 43976 43976 43976 43988 43988 44000 44000 46708 47788 47788 48156 48176 49364 53020 52636 52636 52920 52972 kbswpused

52984 56960 59564 60508 61636 61968 62052 62428 62740 62904 63148 63148 63224 63272 64896 63728 63960 63912 63936 63956 64052 64128 kbswpused

63804 63848 63856 63924 63940 63936 63996 64792

%swpused

5.64 5.64 5.64 5.64 5.65 5.65 5.65 5.65 5.99 6.13 6.13 6.18 6.18 6.34 6.8 6.76 6.76 6.79 6.8 %swpused

6.8 7.31 7.64 7.77 7.91 7.95 7.96 8.01 8.05 8.07 8.1 8.1 8.11 8.12 8.33 8.18 8.21 8.2 8.21 8.21 8.22 8.23 %swpused

8.19 8.19 8.2 8.2 8.21 8.21 8.21 8.32

26

Lampiran 3 Contoh data throughput server proxy dari CTM Date 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007 12/27/2007

Time 0:00 0:05 0:10 0:15 0:20 0:25 0:30 0:35 0:40 0:45 0:50 0:55 1:00 1:05 1:10 1:15 1:20 1:25 1:30 1:35 1:40 1:45 1:50 1:55 2:00 2:05 2:10 2:15 2:20 2:25 2:30 2:35 2:40 2:45 2:50 2:55 3:00 3:05 3:10 3:15 3:20 3:25 3:30 3:35 3:40 3:45 3:50 3:55 4:00 4:05 4:10 4:15 4:20 4:25 4:30 4:35 4:40 4:45 4:50 4:55 5:00 5:05 5:10 5:15

ipaddr:Proxy18:wan:kbps 26.85 31.94 8.13 56.99 35.73 15.43 12.6 38.91 11.66 8.46 15.57 11.19 19.34 21.8 16.54 22.31 25.03 18.13 15.79 10.59 14.87 12.05 15.28 4.74 13.38 9.06 52.61 41.17 58.7 56.66 6.24 0.05 3 0.17 0.83 3.1 2.13 0.34 0.01 0.19 1.37 1.71 4.97 5.94 11.81 3.09 12.91 13.99 22.09 14.46 15.36 18.62 19.82 9.21 4.71 13.65 10.06 6.13 2.98 2.39 5.52 7.19 14.1 3.52

ipaddr:proxy11:wan:kbps 7.17 17.33 23.65 10.72 10.98 64.38 42 28.46 6.75 7.49 5.13 6.18 11.62 14.19 14.89 11.23 10.81 6.88 19.57 6.67 6.32 6.24 9.61 3.77 19.74 1.23 17.81 11.42 27.89 25.63 4.62 0.16 1.32 0.22 0.13 1.36 0.87 0.26 0.04 0.24 0.68 0.85 1.88 6.51 1.51 1.3 2.87 2.43 9.17 8.27 5.53 5.52 4.11 3.38 0.84 5.78 1.18 5.09 1.17 1.41 4.63 6.7 3.69 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/xshockwave-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/ipvsadm1.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/ipvsadm1.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/ipvsadm1.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/ipvsadm1.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 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53

Utilisasi CPU Proxy 11 Proxy 18 13.24 100 14.25 100 16.83 100 28.18 100 30.93 100 29.98 100 39.75 100 52.58 100 52.8 100 68.54 100 79.27 100 82.3 100 100 100 100 100 69.66 100 83.66 100 92.43 100 93.44 100 92.86 100 94.4 60.07 93.06 59.2 90.31 59.87 93 54.94 10.47 13.28 79.18 27.5 89.77 44.31 91.34 46.24 97.07 50.58 89.78 47.7 85.3 48.44 87.33 41.5 89.42 43.75 93.66 54.3 94.18 59.74 96.33 62.23 95.82 65.85 94.09 65.73 89.68 57.92 100 8.78 86.65 15.86 82.26 34.82 85.91 44.14 85.94 48.88 90.2 49.73 88.01 48.41 93.51 48.88 89.38 60.13 84.7 48.66 85.45 33.55 8.86 0.73 11.56 1.84 23.27 3.81 33.55 4.74

U max 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 94.4 93.06 90.31 93 13.28 79.18 89.77 91.34 97.07 89.78 85.3 87.33 89.42 93.66 94.18 96.33 95.82 94.09 89.68 100 86.65 82.26 85.91 85.94 90.2 88.01 93.51 89.38 84.7 85.45 8.86 11.56 23.27 33.55

j 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98

Utilisasi CPU Proxy 11 Proxy 18 52.69 8.7 58.73 10.21 53.35 11.61 82.43 42.19 67.15 12.43 62.54 11.68 58.73 10.74 62.98 17.67 64.76 17.16 72.41 16.83 83.34 30.65 88.98 40.37 92.21 43.35 92.54 49.75 94.61 62.41 94.97 63.33 94.81 63.53 92.75 67.81 94.97 75.4 98.3 77.54 97.15 75.96 93.43 68.69 89.55 58.15 88.13 47.87 89.62 29.95 83.74 31.28 86.33 36.85 87.87 36.93 100 27.94 82.2 21.02 76.7 23.94 77.39 26.26 84.46 39.09 84.99 42 86.44 33.62 92.11 47.61 88.77 37.07 89.25 43.81 93.29 56.6 94.29 55.46 93.25 63.85 91.73 64.68 94.26 64.57 93.5 67.21 93.2 57.26

U max 52.69 58.73 53.35 82.43 67.15 62.54 58.73 62.98 64.76 72.41 83.34 88.98 92.21 92.54 94.61 94.97 94.81 92.75 94.97 98.3 97.15 93.43 89.55 88.13 89.62 83.74 86.33 87.87 100 82.2 76.7 77.39 84.46 84.99 86.44 92.11 88.77 89.25 93.29 94.29 93.25 91.73 94.26 93.5 93.2

x 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100

CDF(x) 0 0.010204 0.030612 0.030612 0.040816 0.040816 0.05102 0.05102 0.05102 0.05102 0.071429 0.091837 0.122449 0.132653 0.142857 0.173469 0.255102 0.469388 0.734694 1

41

Lampiran 11 Contoh tabel perhitungan SD pada saat pembobotan 1:2 (tanggal 27 dan 28 Desember 2007) j 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53

Utilisasi CPU Proxy 11 Proxy 18 6.86 0.53 7.68 0.72 7.28 0.91 7.57 1 7.94 0.98 9.31 1.81 9.46 1.84 19.72 9.76 28.29 3.78 21.51 3.46 28.1 28.54 26.09 53.11 28.33 69.44 44.79 78.72 43.74 81.45 48.38 85.48 53.72 89.81 55.08 91.01 68.51 97.12 60.72 96.21 72.42 95.32 78.69 90.29 79.87 89.23 84.48 89.32 66.82 86.85 77.59 69 72.16 73.26 87.04 66.61 76.16 63.67 74.78 69.2 66.85 65.75 67.22 68.43 70.89 72.13 65.99 69.35 69.98 78.26 72.98 76.83 75.19 82.7 75.52 81.71 78.98 82.72 80.18 86.58 79.75 86.49 78.5 86.82 79.08 86.5 78.85 85.55 82.91 87.22 78.05 84.11 73.27 72.96 68.98 69.94 64.56 62.9 18.3 3.72 20.81 4.35 23.89 3.53 23.15 8.98

U avg 3.695 4.2 4.095 4.285 4.46 5.56 5.65 14.74 16.035 12.485 28.32 39.6 48.885 61.755 62.595 66.93 71.765 73.045 82.815 78.465 83.87 84.49 84.55 86.9 76.835 73.295 72.71 76.825 69.915 71.99 66.3 67.825 71.51 67.67 74.12 74.905 78.945 78.615 80.85 83.38 83.12 82.66 82.79 82.2 85.065 81.08 73.115 69.46 63.73 11.01 12.58 13.71 16.065

SD 3.165 3.48 3.185 3.285 3.48 3.75 3.81 4.98 12.255 9.025 0.22 13.51 20.555 16.965 18.855 18.55 18.045 17.965 14.305 17.745 11.45 5.8 4.68 2.42 10.015 4.295 0.55 10.215 6.245 2.79 0.55 0.605 0.62 1.68 4.14 1.925 3.755 3.095 1.87 3.2 3.37 4.16 3.71 3.35 2.155 3.03 0.155 0.48 0.83 7.29 8.23 10.18 7.085

j 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98

Utilisasi CPU Proxy 11 Proxy 18 18.55 5.16 18.68 6.33 20.81 11.45 31.67 50.56 33.64 27.01 34.93 21.56 46.57 28.47 55.45 35.84 64.98 51.09 67.15 58.62 65.37 60.91 66.15 66.65 63.86 65.18 63.85 66.16 71.54 72.73 70.17 74.74 83.04 70.48 91.21 70.48 61.38 64 55.73 59.19 51.35 54.37 40.16 36.58 46.46 47.62 51.04 54.26 44.5 53.11 45.46 48.81 37.32 31.54 44.2 32.62 45.59 35.91 42.91 33.42 46.26 33.87 66.57 60.95 66.81 65.04 77.48 76.75 71.82 81.04 70.46 76.62 73.48 77.31 72.82 79.14 63.29 76.54 66.24 76.92 63.93 71.64 65.61 71.17 69.37 71.33 67.86 76.34 70.41 63.33 SD rata‐rata

U avg

SD

11.855 12.505 16.13 41.115 30.325 28.245 37.52 45.645 58.035 62.885 63.14 66.4 64.52 65.005 72.135 72.455 76.76 80.845 62.69 57.46 52.86 38.37 47.04 52.65 48.805 47.135 34.43 38.41 40.75 38.165 40.065 63.76 65.925 77.115 76.43 73.54 75.395 75.98 69.915 71.58 67.785 68.39 70.35 72.1 66.87

6.695 6.175 4.68 9.445 3.315 6.685 9.05 9.805 6.945 4.265 2.23 0.25 0.66 1.155 0.595 2.285 6.28 10.365 1.31 1.73 1.51 1.79 0.58 1.61 4.305 1.675 2.89 5.79 4.84 4.745 6.195 2.81 0.885 0.365 4.61 3.08 1.915 3.16 6.625 5.34 3.855 2.78 0.98 4.24 3.54 5.25602

42

Lampiran 12 Tabel hasil perhitungan keseluruhan koneksi, hit dan hit ratio Data ke‐

Tanggal 4 Desember 2007

Total Koneksi 3935402

Total Hit 497363

Total Hit Ratio 12.63817521

1 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

7 Januari 2008

3666194

790755

21.56882587

18

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 PADA SERVER-SERVER PROXY DI IPB. Oleh : DAVID THAMRIN G

Recommend Documents