ANALISIS KINERJA PEMBAGI BEBAN KLASTER SERVER WEB DENGAN ALGORITME WEIGHTED ROUND ROBIN DI JARINGAN OPENFLOW
YUGGO AFRIANTO
SEKOLAH PASCASARJANA INSTITUT PERTANIAN BOGOR BOGOR 2017
PERNYATAAN MENGENAI TESIS DAN SUMBER INFORMASI SERTA PELIMPAHAN HAK CIPTA Dengan ini saya menyatakan bahwa tesis berjudul Analisis Kinerja Pembagi Beban Klaster Server Web dengan Algoritme Weighted Round Robin di Jaringan Openflow adalah benar karya saya dengan arahan dari komisi pembimbing dan belum diajukan dalam bentuk apa pun kepada perguruan tinggi mana pun. Sumber informasi yang berasal atau dikutip dari karya yang diterbitkan maupun tidak diterbitkan dari penulis lain telah disebut dalam teks dan dicantumkan dalam Daftar Pustaka di bagian akhir tesis ini. Dengan ini saya melimpahkan hak cipta dari karya tulis saya kepada Institut Pertanian Bogor. Bogor, Maret 2017
Yuggo Afrianto NIM G651130031
RINGKASAN YUGGO AFRIANTO. Analisis Kinerja Pembagi Beban Klaster Server Web dengan Algoritme Weighted Round Robin di Jaringan Openflow. Dibimbing oleh HERU SUKOCO dan SRI WAHJUNI. Jaringan komputer telah menjadi bagian yang penting dalam berbagai bidang, seperti bisnis, hiburan, dan pendidikan. Keberhasilan ini merupakan suatu tantangan bagi para peneliti dan pengembang jaringan komputer. Permasalahan yang muncul dan menjadi tantangan adalah terbatasnya inovasi yang muncul dari teknologi jaringan komputer saat ini, yang disebabkan keterbatasan perangkat dan protokol jaringan komputer. Jaringan komputer saat ini umumnya masih didominasi perangkat dan mekanisme yang tradisional dan statis. Hal ini ditunjukkan dengan banyaknya perangkat layer 2 dan layer 3 pada model OSI berupa switch dan router yang umumnya unprogrammable. Jaringan komputer kampus adalah salah satu contoh penerapan jaringan komputer pada bidang pendidikan, di mana jaringan tersebut dapat dijadikan sebagai area bagi para peneliti untuk dapat memanfaatkan dan mengembangkan teknologi jaringan komputer. Kampus juga biasanya menyediakan beberapa layanan sistem informasi, yang memerlukan adanya teknologi jaringan komputer guna mendukung layanan tersebut, seperti web server, database server, storage area network, hosting, akses internet, proxy dan lain-lain. Beberapa aplikasi layanan tersebut banyak menerapkan aplikasi berbasis web, contohnya aplikasi sistem informasi akademik, keuangan, kepegawaian, dan lainnya. Seluruh layanan aplikasi berbasis web tersebut perlu adanya sebuah manajemen server dan jaringan komputer yang sesuai dan handal. Konsep yang dapat menjawab permasalahan dan tantangan bagi para peneliti dan pengembang untuk manajemen server dan jaringan komputer adalah sistem software defined network (SDN) dan sistem load balancer. Salah satu ide SDN adalah memisahkan proses data plane dan control plane pada perangkat layer 2 dan 3, yang biasanya proses ini telah menyatu. Salah satu protokol yang mendukung SDN adalah Openflow. Sistem load balancer server web merupakan salah satu metode yang digunakan untuk meningkatkan kinerja dan tingkat ketersediaan server web, dengan cara membagi request yang datang ke beberapa server sekaligus sehingga beban yang ditanggung oleh masing-masing server menjadi lebih ringan. Penelitian ini mencoba merancang dan menganalisis model sistem load balancer klaster server web dengan algoritme weighted round robin (WRR) di jaringan Openflow, untuk mengembangkan sistem load balancer jaringan yang sudah ada menjadi jaringan yang dapat diprogram, dinamis, dan rendah biaya. Nilai bobot pada algoritme WRR didapat dari dua parameter dinamis, yaitu total connections dan kapasitas link throughput setiap server. Selanjutnya dilakukan analisis persentase perubahan quality of service (QoS) terhadap response time, throughput, HTTP Succsess dan Loss Connections untuk setiap sistem load balancer. Hasil analisis kinerja sistem load balancer di jaringan Openflow dibandingkan dengan kinerja load balancer di jaringan yang sudah ada, dengan skenario membangkitkan beban koneksi dengan perulangan sebanyak N=10 pengujian. Beberapa tahapan pengujian dilakukan dengan total beban koneksi
sebesar 4000, 6000, 8000, 10000, 100000 dan 1000000 koneksi, dengan pola antar kedatangan untuk setiap total beban koneksi per detik, yaitu 100, 200, 300, 400 dan 500 koneksi. Hasil analisis dari proses pengujian dengan total koneksi yang besar pada total koneksi di atas 100000 sampai 1000000 koneksi, di mana sistem load balancer pada jaringan Openflow mampu mencapai kinerja yang lebih baik untuk semua parameter QoS kecuali throughput yang tidak signifikan perbedaannya. Tetapi berdasarkan data agregasi dapat disimpulkan kembali, di mana sistem load balancer WRR dapat meningkatkan kinerja response time sebesar 57% dari sistem load balancer sebelumnya yang sudah ada. Namun demikian terjadi penurunan untuk kinerja throughput sebesar 2%, HTTP success connections sebesar 10%, dan meningkatkan HTTP loss connections sebesar 49%. Kata kunci: Load balancer, Openflow, QoS, Web Server, Weighted Round Robin
SUMMARY YUGGO AFRIANTO. Performance Analysis of Load Balancer of the Web Server Cluster using Weighted Round Robin Algorithm in OpenFlow Network. Supervised by HERU SUKOCO and SRI WAHJUNI. The computer network has become an important part in many aspects such as business, entertainment and education. This achievement is a challenge to researchers and computer network developer. The problem that arises and becomes a challenge is the limited amount of innovation that arise from computer network technologies this day due to limited device and protocol of computer networks. A computer network generally dominated by traditional and static device and mechanism. This shown by many of layer 2 and layer 3 devices usage in OSI model in the form of switch and router that generally unprogrammable. University computer network is an example of computer network implementation in education aspect, where this network can become an area for researchers to utilise and develop computer network technology. University mostly serve some information system service, which needs a computer network technology to support the service such as web server, database server, storage area network, hosting, internet access, proxy, etc. some of this application implement a web based application as academic information system application, finance, employee affair, etc. all this web-based application needs a server management and computer network that suitable yet reliable. The concept to this problem and challenge is a software define network (SDN) system and load balancer system. One idea of SDN is to distinguish the data plane process and the control plane in layer 2 and layer 3 devices that used to be as one. One protocol that supports SDN is open flow. The load balancer web server system is one method that used to increase the performance and availability of web server by distributing incoming request to several servers at once so the load in each server become lighter. This research tries to design and analysis a load balancer system model in web server cluster with weighted round robin (WRR) algorithm in open flow network. To develop a load balancer system, the existing network changed to a programmable, dynamic and low-cost network. The weighted value at WRR algorithm provides from two dynamic parameters they are the total connections and the link throughput for each server capacity. The next step is to analysis the changing quality of services (QoS) percentage toward response time, throughput, HTTP success and loss connection for each load balancer system. The load balancer system performance analysis result in open flow network compared to the load balancer performance in the existing network by generating connection load scenario with N=10 iteration testing. Some testing step conduct with total load connections to 4000, 6000, 8000, 10000, 100000 and 1000000 connections with pattern between arrivals for each total load per second to 100, 200, 300, 400 and 500 connections. The analysis result of the testing process with a huge total connection. The load balancer system in open flow network has better performance, where the system can increase the response time performance by 57% compared to the previous load balancer system in the existing network. The performance has a
reduction in throughput performance by 2%, reduce success connection of HTTP by 10% and improvement of HTTP loss connections by 49%. Keywords : Load balancer, Openflow, QoS, Web Server, Weighted Round Robin
© Hak Cipta Milik IPB, Tahun 2017 Hak Cipta Dilindungi Undang-Undang Dilarang mengutip sebagian atau seluruh karya tulis ini tanpa mencantumkan atau menyebutkan sumbernya. Pengutipan hanya untuk kepentingan pendidikan, penelitian, penulisan karya ilmiah, penyusunan laporan, penulisan kritik, atau tinjauan suatu masalah; dan pengutipan tersebut tidak merugikan kepentingan IPB Dilarang mengumumkan dan memperbanyak sebagian atau seluruh karya tulis ini dalam bentuk apa pun tanpa izin IPB
ANALISIS KINERJA PEMBAGI BEBAN KLASTER SERVER WEB DENGAN ALGORITME WEIGHTED ROUND ROBIN DI JARINGAN OPENFLOW
YUGGO AFRIANTO
Tesis sebagai salah satu syarat untuk memperoleh gelar Magister Komputer pada Program Studi Ilmu Komputer
SEKOLAH PASCASARJANA INSTITUT PERTANIAN BOGOR BOGOR 2017
Penguji Luar Komisi pada Ujian Tesis: DrEng Wisnu Ananta Kusuma, ST MT
Judul Tesis : Analisis Kinerja Pembagi Beban Klaster Server Web dengan Algoritme Weighted Round Robin di Jaringan Openflow Nama : Yuggo Afrianto NIM : G651130031
Disetujui oleh Komisi Pembimbing
DrEng Heru Sukoco, SSi MT Ketua
Dr Ir Sri Wahjuni, MT Anggota
Diketahui oleh
Ketua Program Studi Ilmu Komputer
Dekan Sekolah Pascasarjana
Dr Ir Sri Wahjuni, MT
Dr Ir Dahrul Syah, MScAgr
Tanggal Ujian: 8 Februari 2017
Tanggal Lulus:
PRAKATA Puji syukur penulis panjatkan kehadirat Allah SWT yang telah melimpahkan rahmat, hidayah dan inayahnya sehingga penulis dapat menyelesaikan karya ilmiah yang berjudul “ Analisis Kinerja Pembagi Beban Klaster Server Web dengan Algoritme Weighted Round Robin di Jaringan Openflow”. Shalawat dan salam semoga senantiasa tercurahkan kepada junjungan kita Nabi besar Muhammad shallallahu ‘alaihi wasallam. Terima kasih Penulis ucapkan kepada Bapak DrEng Heru Sukoco, SSi MT dan Ibu Dr Ir Sri Wahjuni, MT selaku pembimbing, serta DrEng Wisnu Ananta Kusuma, ST MT selaku penguji yang telah memberikan banyak masukan kepada Penulis dalam penyusunan tesis ini. Selanjutnya penulis ingin mengucapkan terima kasih kepada: 1. 2. 3. 4. 5.
Bapak, ibu, istri dan anak berserta seluruh keluarga tercinta atas do’a dan dukungannya demi kelancaran dan keberhasilan masa studi Penulis. Rekan-rekan LAB NCC. Rekan-rekan mahasiswa Ilmu Komputer IPB. Rekan-rekan dosen Teknik Informatika UIKA. Rudi Hartono yang telah membantu dalam pengumpulan data.
Di samping itu, penghargaan penulis sampaikan kepada Universitas Ibn Khaldun Bogor atas pemberian fasilitas baik pembiayaan maupun sarana prasarana selama penyusunan studi dan karya ilmiah ini. Ungkapan terima kasih juga disampaikan kepada pengelola pascasarjana, seluruh dosen dan staf akademik Fakultas Matematika dan Ilmu Pengetahuan Alam (MIPA) khususnya Departemen Ilmu Komputer Institut Pertanian Bogor. Semoga karya ilmiah ini bermanfaat.
Bogor, Maret 2017
Yuggo Afrianto
DAFTAR ISI DAFTAR TABEL
vi
DAFTAR GAMBAR
vi
DAFTAR LAMPIRAN
vi
1 PENDAHULUAN Latar Belakang Perumusan Masalah Tujuan Penelitian Manfaat Penelitian Ruang Lingkup Penelitian
1 1 2 2 3 3
2 TINJAUAN PUSTAKA Teori Antrian Load Balancer Software Defined Networking Teknologi Openflow Openflow Switch Cloud Computing Tsung
3 3 4 5 5 6 7 8
3 METODE Tempat dan Waktu Penelitian Komponen Instrumentasi Penelitian Tahapan Pelaksanaan Penelitian Analisis dan Identifikasi Masalah Desain dan Implementasi
9 9 9 10 10 11
4 HASIL DAN PEMBAHASAN Hasil Kinerja Throughput Link Server Hasil Pengujian Distribusi Koneksi Pada Sistem Load Balancer Hasil Rata-rata Total Koneksi Dan Jam Sibuk Sistem Layanan Web Informasi Kampus UIKA Hasil Pengujian Sistem Load balancer
16 16 17 18 19
5 SIMPULAN DAN SARAN Simpulan Saran
29 29 29
DAFTAR PUSTAKA
30
LAMPIRAN
32
RIWAYAT HIDUP
43
DAFTAR TABEL
1 Notasi Kendall 2 Perangkat keras 3 Deskripsi topologi jaringan UIKA 4 Manajemen data center UIKA 5 Pengambilan populasi data request 6 Table flows OpenVswitch 7 Hasil pengujian kinerja link server 8 Paired samples test 9 Monitoring pengujian beban distribusi server 10 Puncak jam sibuk Kampus UIKA 11 Alamat IP perangkat 12 Skenario total koneksi 13 Hasil agregasi rerata pengujian per kedatangan koneksi 14 Hasil pengujian rerata total koneksi
4 9 10 11 12 15 16 16 18 18 20 21 22 26
DAFTAR GAMBAR 1 Model antrian jaringan komputer dengan WRR (Hottmar dan Adamec 2012) 2 Perbandingan jaringan tradisional dengan jaringan SDN (Kreutz dan Ramos 2014) 3 Openflow switch (Chen et al. 2014) 4 Flow table (Othman et al. 2010) 5 Topologi jaringan Uika 6 Desain topologi antrian jaringan. 7 Skema komunikasi protokol Openflow 8 Flow chart control plane 9 Skenario topologi pengujian kinerja link server 10 Framework traffic measurement dan evaluation 11 Skenario pengujian existing load balancer 12 Skenario pengujian load balancer WRR pada Openflow 13 Struktur file Tsung.xml 14 Rerata perbandingan response time 15 Rerata perbandingan throughput 16 Rerata perbandingan http success connections 17 Rerata perbandingan http loss connections 18 Grafik hasil pengujian total koneksi
5 6 7 7 10 12 15 16 17 19 19 20 21 23 24 24 25 27
DAFTAR LAMPIRAN 1 Source code akuisisi data total koneksi setiap fakultas 2 Source code normalisasi data, rata-rata, varians, dan bobot server. 3 Source code load balancer WRR pox controller 4 Hasil pengujian distribusi traffic pada sistem kerja load balancer
32 34 35 40
1
1 PENDAHULUAN Latar Belakang Jaringan komputer telah menjadi bagian yang penting dalam berbagai bidang, seperti bisnis, hiburan, dan kampus. Keberhasilan ini merupakan suatu tantangan bagi para peneliti dan pengembang jaringan komputer Mckeown et al. (2008). Permasalahan yang muncul dan menjadi tantangan adalah terbatasnya inovasi yang muncul dari teknologi jaringan komputer saat ini, yang disebabkan keterbatasan perangkat dan protokol jaringan komputer. Jaringan komputer saat ini umumnya masih didominasi perangkat dan mekanisme yang tradisional dan statis. Hal ini ditunjukkan dengan banyaknya perangkat layer 2 dan layer 3 pada model OSI berupa switch dan router yang umumnya unprogrammable (Khatri 2013). Kampus Universitas Ibn Khaldun (UIKA) telah memiliki data center yang berlokasi terpisah di gedung rektort dan fakultas teknik dalam pelayanan informasi dan internet, yang terdiri atas beberapa layanan seperti web server, database server, storage area network, hosting, akses internet, proxy dan lain-lain. Jumlah mahasiswa kurang lebih 8000 mahasiswa aktif, yang terkadang layanan yang tersedia mengalami waktu downtime karena beban yang tinggi dan kapasitas link transfer antara kedua gedung yang berbeda. Melihat kondisi tersebut tentu saja UIKA memerlukan data center yang mendukung manajemen jaringan yang handal. Tantangan dalam manajemen jaringan yaitu bagaimana untuk mengoperasikan, memelihara dan mangamankan komunikasi jaringan (Kim dan Feamster 2013). Menurut dokumentasi ITU-T G.1000 kualitas layanan jaringan yang baik tentunya akan didapat dari manajemen jaringan yang handal, salah satunya dapat diukur dengan melihat nilai unjuk kerja parameter QoS. Software defined networking (SDN) merupakan ide baru pada jaringan komputer, yang menyederhanakan fungsi kontrol dan manajemen pada jaringan. SDN memungkinkan untuk dapat berinovasi melalui jaringan yang bersifat dinamis, virtualisasi jaringan dan dapat diprogram. Salah satu protokol yang menerapkan SDN yaitu Openflow (Azodolmolky 2013). Openflow dapat diaplikasikan pada infratruktur data center berbasiskan cloud computing, di mana cloud computing memberikan kemudahan dan efisiensi pengelolaan sumber daya melalui virtualisasi yang dapat diakses kapan pun dan di mana saja untuk memenuhi kebutuhan permintaan sumber daya IT Zhang et al. (2013). Beberapa aplikasi layanan kampus banyak menerapkan aplikasi berbasis web, seperti aplikasi sistem informasi akademik, keuangan, kepegawaian, dan lainnya. Seluruh layanan aplikasi berbasis web tersebut perlu adanya penyesuaian infrastruktur sesuai kebutuhan. Perangkat jaringan yang ada saat ini belum optimal dalam penanganan lalu lintas layanan web dalam jumlah yang besar memungkinkan kehilangan layanan web yang tersedia. Hal ini berkaitan dengan fungsi control plane dan data plane yang ada di dalam perangkat tersebut (Kaur 2016). Lukitasari (2010) mengemukakan load balancer web server merupakan salah satu cara yang digunakan untuk meningkatkan kinerja dan tingkat ketersediaan web server, yaitu dengan membagi request yang datang ke beberapa server sekaligus, sehingga beban yang ditanggung oleh masing-masing server lebih ringan.
2 Beberapa penelitian yang pernah dilakukan, seperti Mckeown et al. (2008) melakukan percobaan protokol di jaringan yang digunakan setiap hari dengan menerapkan Openflow yang berdasarkan pada ethernet switch dengan internal flowtable, dan interface standar untuk menambah dan menghapus flow-entri. Merekomendasikan untuk mendorong vendor jaringan untuk menambahkan protokol Openflow kedalam produk switch mereka untuk dibangun di area jaringan backbone kampus, dan kampus lain dapat ikut serta mencoba dan mengembangkan jaringan Openflow ini. Lukitasari (2010) melakukan analisis kinerja Linux Virtual Server (LVS) menggunakan load balancer untuk membandingkan kinerja web server tunggal dengan web server cluster merekomendasikan bahwa LVS dengan metode load-balancer mampu membuat kinerja dari sebuah server menjadi lebih ringan dengan beberapa server yang tergabung di dalamnya. Chen et al. (2014) meneliti load balancer server cluster di dalam lingkungan virtualisasi pada jaringan Openflow. Controller yang terhubung dengan kumpulan server yang berjalan melalui teknik manajemen virtualisasi dan menghitung rata-rata beban untuk server berdasarkan umpan balik rata-rata load-balancer algoritme penjadwalan dinamis, merekomendasikan dengan pendekatan Openflow dapat melakukan teknik load balancer yang fleksibel dan handal. Sabastian dan Guarddin (2013) melakukan pembangunan infrastruktur bersifat cloud dengan jenis IaaS pada data center Universitas Indonesia menggunakan aplikasi free open source software (F/OSS) memudahkan semua pihak dalam organisasi untuk mengkonfigurasi sistem informasi mereka. Hottmar dan Adamec (2012) meneliti strategi penjadwalan layanan jaringan menggunakan model matematis pada algoritme weighted round robin, berdasarkan paramater QoS yaitu maksimum panjang antrian dan kapasitas link transfer untuk mendapatkan pembobotan sehingga dapat mengatur kemacetan lalu lintas jaringan. Penelitian yang akan dilakukan untuk menerapkan sistem pembagi beban klaster server web dengan algoritme weighted round robin (WRR) di jaringan Openflow untuk mengembangkan sistem jaringan yang sudah ada, menjadi jaringan yang dapat diprogram, dinamis, dan rendah biaya, lalu mengintegrasikan jaringan Openflow dengan jaringan yang sudah ada sehingga layanan jaringan masih dapat digunakan oleh pengguna, serta dilakukan analisis terhadap kinerja untuk mengukur kualitas layanan. Perumusan Masalah Berdasarkan latar belakang di atas, maka dapat dirumuskan dalam beberapa hal yaitu: 1 Bagaimana merancang sistem load balancer klaster server web di jaringan Openflow? 2 Bagaimana menganalisis kinerja sistem load balancer pada jaringan yang sudah ada dan jaringan Openflow untuk layanan klaster server web? Tujuan Penelitian Tujuan penelitian ini adalah merancang dan menganalisis model sistem load balancer pada jaringan Openflow dengan menerapkan algoritme Weighted Round Robin.
3 Manfaat Penelitian Hasil dari penelitian ini dapat memberikan rekomendasi salah satu alternatif model sistem load balancer pada jaringan Openflow sebagai pembagi beban klaster server web di IaaS, dan mekanisme sistem yang telah dibangun dapat diimplementasikan pada server layanan yang lain pada data center. Ruang Lingkup Penelitian 1 2
3 4
Beberapa ruang lingkup yang digunakan pada penelitian ini antara lain: Objek penelitian adalah sistem load balancer pada jaringan yang sudah ada dan jaringan Openflow sebagai pembagi beban klaster server web. Metode implementasi pembagi beban yang digunakan dalam sistem load balancer pada jaringan Openflow adalah algoritme penjadwalan weighted round robin. Request beban yang akan diteliti pada packet request server web. Penelitian dibatasi pada sistem data center jaringan yang ada pada kampus UIKA.
2 TINJAUAN PUSTAKA Teori Antrian Sebuah sistem antrian adalah suatu himpunan pelanggan, pelayan dan suatu aturan yang mengatur pelayanan kepada pelanggan. Sedangkan keadaan sistem menunjuk pada jumlah pelanggan yang berada dalam suatu fasilitas pelayanan, termasuk dalam antriannya (Kakiay 2004). Sistem antrian dicirikan oleh lima komponen utama yaitu: pola kedatangan costumer, pola pelayanan costumer, banyaknya server, kapasitas sistem dan disiplin antrian (Medhi 1991 dalam Ningrum 2006). 1 Pola Kedatangan Pola kedatangan customer dapat dicirikan oleh waktu antar kedatangan (interarrival time) yaitu waktu antara kedatangan costumer yang satu dengan costumer berikutnya. Pola ini dapat bersifat deterministic (tertentu) diketahui secara pasti kedatangannya atau stochastic (peubah acak yang mengikuti sebaran peluang tertentu). Pola ini juga dapat bergantung pada banyaknya costumer yang ada di sistem (state dependent) atau tidak bergantung pada banyaknya costumer di sistem (state independent). 2 Pola Pelayanan Pola pelayanan biasanya dicirikan sebagai waktu pelayanan (sevice time) yaitu waktu yang digunakan oleh satu server untuk melayani satu costumer. Pola pelayanan juga dapat bersifat probabilistic, state independent atau state dependent. Selain itu dalam suatu sistem pelayanan, costumer dapat dilayani oleh satu atau lebih server.
4 Kapasitas Sistem Kapasitas sistem adalah banyaknya costumer di sistem, baik costumer yang sedang dilayani maupun costumer yang terdapat dalam antrian. Suatu sistem antrian yang memiliki kapasitas tertentu, pada saat pelayanan penuh, costumer yang datang akan ditolak untuk masuk kedalam sistem. Dengan demikian costumer tersebut dipaksa pergi dari sistem tanpa menerima pelayanan. Sistem yang tidak mempunyai batasan terhadap jumlah costumer yang diijinkan untuk masuk ke dalam fasilitas pelayanan disebut kapasitas tak terbatas sedangkan proses sebaliknya disebut kapasitas terbatas. 4 Disiplin Antrian Bentuk antrian secara umum dinotasikan oleh Kendall-Lee sebagai (a/b/c): (d/e/f), di mana masing-masing simbol A, B, C, D, E dan F (Osaki 1992 dalam Ningrum 2006) notasi Kendal/Universal antrian dapat dijelaskan pada Tabel 1. 3
Tabel 1 Notasi Kendall Karakteristik A = Sebaran waktu antar kedatangan
B = Sebaran waktu pelayanan
C = jumlah server D = Disiplin Pelayanan
E = Kapasitas Sistem F = Populasi Costumer
Simbol M D Ek G M D Ek G 1,2,.. ∞ FIFO LIFO SIRO PRI GD 1,2,.. ∞ 1,2,.. ∞
Keterangan Eksponensial Deterministik Erlang jenis k General Eksponensial Deterministik Erlang jenis k General First In First Out Last In First Out Service In Random Order Priority General Dicipline -
Salah satu model penerapan sistem antrian dapat dilakukan pada sistem komunikasi jaringan komputer, yang dipercaya dengan mengatur bagaimana costumer dapat menghubungi server dapat menghindari kemacetan lalu lintas jaringan, dan penolakan layanan. Model antrian dalam jaringan komputer dapat dilihat pada Gambar 1. Load Balancer Menurut Lukitasari (2010) load balancer, merupakan teknik yang digunakan untuk memisahkan antara dua atau banyak network link, dengan mempunyai banyak link maka optimalisasi utilisasi sumber daya throughput dan response time akan semakin baik karena mempunyai lebih dari satu link yang bisa saling menjaga pada saat network down dan menjadi cepat pada saat network normal. Jika memerlukan reliabilitas tinggi yang memerlukan 100% koneksi uptime dan yang menginginkan koneksi upstream yang berbeda dan dibuat saling menjaga.
5
Gambar 1 Model antrian jaringan komputer dengan WRR (Hottmar dan Adamec 2012)
Software Defined Networking Menurut Kreutz dan Ramos (2014) jaringan komputer dapat dibagi ke dalam 3 bagian menurut fungsinya, yaitu: data plane, control plane dan management plane. Data plane yaitu bagaimana meneruskan paket data masuk atau keluar dari sebuah perangkat. Control plane yaitu bagaimana aturan atau protokol yang digunakan untuk paket data tersebut harus diteruskan untuk data plane. Management plane yaitu bagaimana melakukan konfigurasi untuk control plane. Ketiga bagian ini menyatu kedalam perangkat jaringan dan sistem pengelolaannya berdasarkan vendor perangkat. Menurut (Kim dan Feamster (2013) Software Defined Networking (SDN) adalah sebuah pendekatan baru dalam mendesain, membangun, dan mengelola jaringan komputer. Konsep dasar SDN berkaitan erat dengan arsitektur perangkat jaringan seperti router, packet switch, LAN switch dan lain sebagainya. Jaringan tradisional yang ada saat ini menggabungkan antara fungsi control plane dan data plane, sedangkan SDN melakukan pemisahan antara control plane dan data plane, di mana data plane tetap berada pada perangkat jaringan, sedang control plane berada pada sebuah entitas terpisah bernama “Controller” yang akan menentukan perilaku jaringan dengan cara memungkinkan data plane untuk diprogram (Mendonca dan Astuto 2013). Perbandingan jaringan tradisional dengan jaringan SDN dapat dilihat pada Gambar 2. Teknologi Openflow Openflow adalah sebuah standar terbuka yang memungkinkan peneliti untuk menjalankan percobaan protokol dalam jaringan yang biasa kita pakai sehari-hari. Pada router tradisional, data plane dan control plane terletak dalam perangkat yang sama. Tetapi pada Openflow switch, kedua fungsi ini dipisahkan. Bagian data plane
6 tetap berada dalam switch, sementara control plane dipindahkan ke controller yang terpisah. Openflow switch dan controller tersebut berkomunikasi menggunakan protokol Openflow yang berisi pesan-pesan yang sudah terdefinisi sebelumnya. Data plane dari Openflow switch memperlihatkan clean flow table abstraction di mana setiap flow entry terdiri dari satu set paket field untuk dicocokkan, counters untuk menyimpan aliran statistik dan sebuah aksi yang akan diberikan ketika terjadi kecocokan paket dengan field tersebut. Ketika switch menerima paket yang tidak didefinisikan dalam flow entry, switch akan meneruskan informasi tentang paket tersebut ke controller, kemudian controller akan memutuskan bagaimana untuk memproses paket tersebut. Paket dapat dibuang atau controller dapat menginstal flow entry baru pada switch, sehingga switch bisa menangani paket-paket yang sama selanjutnya (Anthony 2012 dalam Amrun 2014).
Gambar 2 Perbandingan jaringan tradisional dengan jaringan SDN (Kreutz dan Ramos 2014)
Openflow Switch Openflow switch berkomunikasi dengan controller melalui protokol Openflow. Openflow switch terdiri dari tiga bagian dapat dilihat pada Gambar 3. 1
2
Flow Table Openflow switch terdiri dari satu atau lebih flow table yang berfungsi untuk memproses paket yang datang, dapat dilihat pada Gambar 4. Secure Channel Secure channel merupakan sebuah interface yang menghubungkan Openflow switch dan controller. Melalui interface tersebut, controller bisa saling mengirim pesan dengan Openflow switch guna melakukan konfigurasi terhadap switch tersebut.
7
Gambar 3 Openflow switch (Chen et al. 2014) 3
Openflow Controller Openflow protocol menyediakan sebuah cara yang bersifat terbuka dan standar untuk bisa berkomunikasi dengan Openflow switch. Protokol Openflow memungkinkan sebuah controller logis terpusat bisa menangani aliran paket yang berasal dari switch (Kumar 2012 dalam Amrun 2014).
Gambar 4 Flow table (Othman et al. 2010) Cloud Computing Cloud computing merupakan konvergensi dari kemajuan berbagai teknologi komputasi terkini seperti kemajuan di bidang perangkat keras (hardware virtualisasi), komputasi terdistribusi melalui teknik grid, computer cluster dan utility computing, serta manajemen sumber daya komputasi dengan adanya
8 otomatisasi data center dan komputasi autonomous. Selain itu, akses terhadap sumber daya komputasi yang terdistribusi menjadi seragam dengan hadirnya web services dan service oriented architecture (SOA), terdapat tiga model layanan cloud computing, model tersebut adalah layanan (Sabastian dan Guarddin 2013): 1 Berbasis abstraksi perangkat keras beserta interkoneksinya (IaaS). 2 Berbasis abstraksi model pemrograman tanpa perlu mengetahui model pemrograman tersebut berjalan di atas perangkat keras dengan arsitektur spesifik ataupun umum (PaaS). 3 Model yang terakhir adalah perangkat lunak yang dapat langsung memanfaatkan akses terhadap sumber daya komputasi terdistribusi serta digunakan secara langsung di manapun pengguna tersebut mengakses perangkat lunak tersebut (SaaS). Tsung Tsung adalah aplikasi uji beban terdistribusi, di mana Tsung menggunakan protokol yang independent dan pada saat ini Tsung digunakan untuk menguji beberapa layanan seperti HTTP, WebDAV, SOAP, PostgreSQL, MySQL, LDAP dan Jabber/XMPP servers. Kemampuan utama Tsung adalah mampu mensimulasikan beban yang besar secara simultan dari satu mesin, dan dapat juga pada beberapa mesin yang di klaster. Tsung dikembangkan oleh Erlang, di mana Erlang adalah sebuah bahasa pemrograman concurrency-oriented. Berbasiskan pada erlang OTP (Open Transaction Platform) yang memiliki beberapa karateristik (Niclausse 2015): 1. Performance Erlang dibuat untuk mendukung ratusan ribu proses ringan dalam satu mesin virtual. Scalability 2. Erlang runtime enviroment adalah terdistribusi, menawarkan ide untuk lokasi proses dapat transparan. 3. Fault-tolerance Erlang dibangun untuk pengembangan yang handal, dengan sistem fault tolerance, di mana jika ada kesalahan response dari server. Tsung tidak akan menjalankan keseluruhan sehingga kesalahan tidak akan menyebar keseluruhan. Penelitian yang pernah dilakukan oleh aplikasi pengujian Tsung adalah, pada protokol HTTP dan HTTPS Tsung mengujikan: 1. Membuat 12.000 beban koneksi secara simultan, di mana Tsung berjalan pada 4 komputer cluster menghasilkan 3000 koneksi per detik pada tahun 2003. 2. Membuat 10 juta beban koneksi secara simultan, menghasilkan satu juta lebih koneksi per detik. Tsung juga telah digunakan pada: 1. DGI (Direction Générale des impôts): French finance ministry. 2. Cap Gemini Ernst & Young.
9
3. 4. 5.
IFP (Institut Français du Pétrole): French Research Organization for Petroleum. LibertySurf. Sun (TM) for their Mooddlerooms platform on Niagara processors: https://blogs.oracle.com/kevinr/resource/Moodle-Sun-RA.pdf.
3 METODE Tempat dan Waktu Penelitian Penelitian ini dilaksanakan mulai bulan Mei 2015 sampai dengan bulan Juli 2016, bertempat di Laboratorium NCC (Net Centric Computing) Departemen Ilmu Komputer Fakultas Matematika dan Ilmu Pengetahuan Alam Institut Pertanian Bogor dan Data Center Kampus Universitas Ibn Khaldun Bogor. Komponen Instrumentasi Penelitian a)
Perangkat Keras (Hardware) Perangkat keras yang digunakan dalam penelitian ini dapat dilihat pada Tabel 2.
Tabel 2 Perangkat keras Nama Alat Router Hub PC OVS
PC Penguji 1
PC Penguji 2
PC Penguji 3
PC Server
Spesifikasi CPU AR7161 680MHz RAM 256MB LAN Ports 5, Gigabit LAN Ports 5, 10/100 Mbps CPU Intel Xeon RAM 2 GB LAN Ports 3 10/100 Mbps, 2 Gigabit CPU Core I3 Ram 4 GB LAN Ports 2, 10/100 Mbps CPU Core I5 Ram 4 GB LAN Ports 2, 10/100 Mbps CPU Dual Core Ram 2 GB LAN Ports 2, 10/100 Mbps CPU Xeon E31220 @ 3.10 Ghz Ram 8 GB Lan Gigabits
Jumlah 1 1 1
1
1
1
3
Perangkat Lunak (Software) Software yang digunakan pada penelitian ini antara lain: O/S Windows 7, O/S Linux Ubuntu 14.10, PSPP, Python, Iperf, Tsung. Openvswitch, Pox Controller. b)
10 Tahapan Pelaksanaan Penelitian Tahapan pelaksanaan penelitian yang digunakan dalam penelitian ini terdiri dari beberapa tahapan yaitu: Analisis dan Identifikasi Masalah Pada tahap pertama ini dilakukan analisis dan identifikasi masalah terhadap sistem jaringan yang sudah ada atau jaringan existing pada kampus UIKA seperti, distribusi koneksi jaringan dan manajamen sistem server pada data center UIKA. Distribusi koneksi jaringan UIKA 1 Analisis distribusi jaringan UIKA digambarkan ke dalam topologi logika dengan dimodelkan ke dalam 3 level layer yaitu core layer, distribution layer, access layer, seperti ditunjukkan pada Gambar 5.
Gambar 5 Topologi jaringan Uika Dari Gambar 5 setiap layer terdapat informasi berupa jenis dan lokasi perangkat seperti yang ditunjukkan pada Tabel 3. Tabel 3 Deskripsi topologi jaringan UIKA Level Layer Core Layer Distribution Layer
Nama Perangkat Router Router
Access Layer
Switch Access Point
Lokasi Perangkat Fak. Teknik Fak. Teknik Fak. Agama Islam Fak. Ekonomi Rektorat Setiap Lantai Gedung
11 Manajemen data center Data center UIKA saat ini memiliki 4 physical server yang dibangun private cloud computing, dengan menerapkan model layanan IaaS yang secara lokasi terpisah gedung, yaitu gedung rektorat dan fakultas teknik dengan media link koneksi radio wireless untuk ke gedung fakultas teknik. UIKA juga memiliki beberapa virtual machine server sebagai host dari setiap layanan aplikasi informasi, beberapa layanan seperti ditunjukkan pada Tabel 4.
2
Tabel 4 Manajemen data center UIKA VM Server
Deskripsi
Aplikasi 1
Server layanan web informasi universitas dan setiap fakultas
Aplikasi 2
Server layanan sistem informasi akademik
Aplikasi 3
Server database
Aplikasi 4
Server monitoring device
Aplikasi 5
Server EPSBED
Physical Server
Server 1, Server 2, Server 3, dan Server 4
Dengan kondisi data center terpisah gedung, didapati perbedaan kapasitas link throughput antar server. Maka perlu mekanisme manajemen yang sesuai untuk memberikan beban koneksi yang sesuai dengan kemampuan kapasitas throughput link server tersebut. Berdasarkan data pada Tabel 4, maka diperlukan mekanisme pembagi beban request client pada server virtual mesin cluster yang ada pada setiap physical server. Desain dan Implementasi Pada tahap ini terdapat 2 tahapan yaitu desain dan implementasi desain algoritme WRR (weighted round robin), lalu desain dan implementasi sistem load balancer pada jaringan Openflow. 1 Desain dan implementasi sistem load balancer WRR pada jaringan Openflow Tahap desain dan implementasi sistem load balancer WRR pada jaringan Openflow dimodelkan dengan model antrian. Menurut Idatriska et al. (2014) teori antrian pada umumnya selalu diasumsikan adanya proses poisson sebagai proses kedatangan, di mana paket-paket yang masuk ke dalam suatu sistem antrian diasumsikan datang secara acak dan penggambaran matematisnya menggunakan proses stokastik. Pada penelitian ini adalah model satu antrian dengan beberapa pelayanan, notasi M/M/3. Model topologi antrian jaringan seperti yang ditunjukkan pada pada Gambar 6. Asumsi dasar simulasi dan pengujian antrian jaringan: Kedatangan paket diasumsikan bersifat acak mengikuti proses poisson diset oleh peneliti dijadikan sebagai skenario pengujian. Mean service time adalah terdistribusi eksponensial. Disiplin antrian yang digunakan adalah order priority.
12 Diasumsikan bahwa kapasitas buffer tak terbatas. Jumlah server yang digunakan 3 server.
Gambar 6 Desain topologi antrian jaringan. Berdasarkan disiplin antrian, yang digunakan adalah order priority di mana dalam penelitian ini menggunakan algoritme WRR. Pada Gambar 1 terdapat beberapa formula dalam penentuan bobot algoritme WRR, di mana dapat dilakukan dengan beberapa tahapan yaitu: A Akuisisi data Mencari total N request pada setiap distribusi fakultas menggunakan Persamaan 1. 𝑛
𝑁 = ∑ 𝑁𝑖
req……….………………………..………………..……..… (1)
𝑖=1
Keterangan: 𝑁 i
= Total request (req). = Request (req).
Data request diakusisi dengan mengambil ke database aplikasi layanan yang sudah ada, dengan melakukan koneksi ke database berdasarkan tabel total request masing-masing fakultas per satu hari sebelumnya. Seperti ditunjukkan pada Tabel 5. Kode lengkap program untuk mangambil data dapat dilihat pada Lampiran 1. Tabel 5 Pengambilan populasi data request Fak. Teknik N request
Total Request Fak. Agama Islam Fak. Ekonomi N request
N request
Rektorat N request
13
# Fungsi koneksi database def Koneksi(self): try: self.__con=MySQLdb.connect(self.__host,self.__user,self. __passwd,self.__db) print "Koneksi berhasil..." except: print "Koneksi gagal"
Data throughput setiap link server dengan notasi 𝑇 diakuisisi dengan menggunakan aplikasi iperf yang sebelumnya aplikasi iperf diuji untuk kesesuaian datanya dengan membandingkan rata-rata nilai yang didapat dengan nilai rata-rata aplikasi wireshark menggunakan metode uji beda dua sampel berpasangan menggunakan aplikasi pspp. B
Praproses data Normalisasi rentang data Data total request masing-masing fakultas yang didapat. Dilakukan normalisasi rentang data antara 0 dan 1, agar nilai sebaran data pada pembobotan hasil peluang setiap server memiliki nilai range belakang koma yang sama, dapat dihitung dengan Persamaan 2. Kode lengkap program untuk mengambil data dapat dilihat pada Lampiran 2. 𝑁𝑖 =
𝑁𝑖 − 𝑚𝑖𝑛 max − 𝑚𝑖𝑛
req …………………………………...…...…….
(2)
Keterangan: 𝑁𝑖 𝑛𝑖 min max
= Nilai req setiap fakultas yang dinormalisasikan (req). = Nilai total req setiap fakultas (req). = Nilai terendah dari data set (req). = Nilai maximum dari data set (req).
# Fungsi normalisasi data list = [ft1,fai1,fe1,rektorat1] mini = min(list) maxi = max(list) rentang = maxi-mini if rentang == 0: rentang = 1 ft = (ft1 fai = (fai1 fe = (fe1 rektorat =
mini) / rentang - mini) / rentang mini) / rentang (rektorat1 - mini) / rentang
Perhitungan nilai varians. Berdasarkan data intensitas request normalisasi setiap fakultas yang didapat, selanjutnya dihitung nilai varians beban request pada level core dengan
14 menggunakan metode statistik varians, sebagai salah satu nilai penentu peluang tugas setiap server, menggunakan Persamaan 3. Kode lengkap program untuk mangambil data dapat dilihat pada Lampiran 2. 2
𝜎2 =
∑𝑛𝑖=1(𝑏𝑒𝑏𝑎𝑛𝑡,𝑖 − 𝑏𝑒𝑏𝑎𝑛𝑡 ) 𝑛
req ……………….............................….. (3)
Keterangan: 𝜎2 bebant,i
= Nilai varians beban request pada level core. = Nilai request setiap lantai per hari.
𝑏𝑒𝑏𝑎𝑛𝑡
= Nilai rata-rata beban pada level distribution.
#Fungsi varians var = (pow(ft - rata,2) + pow(fai - rata,2) + pow(fe - rata,2) + pow(rektorat - rata,2))/4
Di mana nilai beban pada level distribution didapat dari nilai beban pada setiap level access ditunjukkan pada Persamaan 4. Kode lengkap program untuk mangambil data dapat dilihat pada Lampiran 2. 𝑏𝑒𝑏𝑎𝑛𝑡 =
∑𝑛 𝑖=1(𝑏𝑒𝑏𝑎𝑛𝑡,𝑖 ) 𝑛
req ………….……………….……………..……...… (4)
#fungsi beban rata - rata rata = (ft + fai + fe + rektorat) / 4
C
Perhitungan peluang bobot server. Berdasarkan nilai varians request dan nilai throughput selanjutnya akan dihitung untuk menentukan ke server mana request tersebut akan dilayani ditunjukkan dengan notasi λ1S, λ2S, λ3S,…, λnS, dan request yang sudah dilayani ditunjukkan dengan notasi λ1L, λ2L, λ3L,…, λnL. Penentuan bagaimana peluang setiap server mendapatkan tugas kedatangan request ditunjukkan dengan notasi μ1, μ2, μ3,…,μn menurut Li et al. (2005) dapat dihitung dengan Persamaan 5. Kode lengkap program untuk mangambil data dapat dilihat pada Lampiran 2. 𝜇𝑛 =
𝑇𝑟𝑛 1 . 𝑇𝑟 𝜎2
rps…..…………………………………………….………...……. (5)
Keterangan:
μn = Nilai probabilitas setiap link server dalam satuan request pes second (rps). Trn = Nilai besarnya throughput setiap link dalam satuan bit per second (bps). Tr = Nilai total besarnya throughput banyaknya link dalam satuan bit per second (bps). 2 𝜎 = Nilai varians beban request pada level core.
Desain dan implementasi jaringan Openflow Pada tahap ini dibuat desain topologi yang dijadikan skenario pembagi beban pada data center IaaS dengan membangun beberapa komponen yaitu Openflow switch sebagai data plane, Openflow controller sebagai control plane, web server dan host. Skema komunikasi protokol Openflow ditunjukkan pada Gambar 7. 2
15
Gambar 7 Skema komunikasi protokol Openflow A
Table Flows OpenVswitch Pada tahap ini table flow yang dijadikan skenario data plane atau bagai mana data flow berjalan pada switch Openflow yang mendapat pengetahuan dari controller dengan mode reactive, table flow desain ditunjukkan pada Tabel 6.
Tabel 6 Table flows OpenVswitch Header Fields If ingress port == 2 && dst_adrr == 192.168.2.5 && dst_mac == 00:00:00:00:00:00
B
Counter *
Actions Re-write to 192.168.2.11, forward port 2 || Re-write to 192.168.2.12, forward port 2 || Re-write to 192.168.2.13, forward port 2
Control Plane POX Controller Pada tahap ini adalah logika pemrogaman bagaimana perilaku komunikasi data dilakukan, implementasi control plane menggunakan pox controller dengan bahasa pemrograman python. Desain flowchart implementasi control plane ditunjukkan pada Gambar 8. Kode lengkap program load balancer WRR dapat dilihat pada Lampiran 3.
16
4 HASIL DAN PEMBAHASAN Hasil Kinerja Throughput Link Server Pengujian kinerja link setiap server dilakukan dengan mengukur nilai throughput menggunakan aplikasi iperf dan wireshark. Hasil pengukuran dari ke dua aplikasi yang didapat, selanjutnya dibandingkan menggunakan metode uji beda dua sampel berpasangan sebanyak N = 10 kali percobaan. Skenario topologi pengujian ditunjukkan pada Gambar 9.
Gambar 8 Flow chart control plane Data hasil pengukuran nilai throughput link setiap server yang didapat, selanjutnya diolah dengan metode uji beda dua sampel berpasangan menggunakan aplikasi PSPP, didapatkan hasil yang dapat dilihat pada Tabel 7 dan Tabel 8. Tabel 7 Hasil pengujian kinerja link server Aplikasi Iperf Wireshark
1 7.740 7.810
2 7.430 7.524
3 7.970 7.968
N Percobaan throughput (kbps) 4 5 6 7 8 8.240 9.500 7.210 6.880 9.740 8.377 9.567 6.838 7.112 10.038
9 10.000 10.117
10 8.360 8.399
Tabel 8 Paired samples test Mean Pair 1Wireshark - Iperf
.07
Paired Differences 95% Confidence interval of Std, Std, the difference Error Deviation Mean Lower Upper .18
.06
.06
.20
t
Df
sig. (2tailed)
1.20
9
.259
17
Gambar 9 Skenario topologi pengujian kinerja link server Berdasarkan Tabel 8 disimpulkan bahwa H0 diterima dengan nilai korelasi antara dua variable adalah sebesar 0.99 dengan nilai sig sebesar 0. Hal ini menunjukkan bahwa korelasi antara dua rata-rata pengujian throughput iperf dan wireshark adalah nyata dan signifikan, lalu pada Tabel 8 menunjukkan hipotesis dari nilai t 1.20 dengan sig 0.259. Karena sig > 0.05 disimpulkan bahwa H0 diterima, artinya rata-rata pengujian throughput aplikasi iperf dengan wireshark adalah sama dan aplikasi iperf dapat digunakan sebagai alat pengumpul data nilai throughput, yang nantinya akan dipakai sebagai salah satu tool aplikasi untuk menghitung nilai bobot peluang pelayanan setiap server melayani request. Hasil Pengujian Distribusi Koneksi Pada Sistem Load Balancer Skenario monitoring dilakukan menggunakan aplikasi Tsung sebagai generator request pada sisi client, dengan mencoba melakukan koneksi sebanyak 100 koneksi untuk mengetahui bagaimana pola pembagian distribusi request sistem load balancer pada setiap server dengan perintah: Tsung -f Tsung.xml –f
Perintah di atas akan meng-generate 100 koneksi ke alamat server uji.ac.id dengan interval waktu kedatangan request 1 koneksi per detik, lalu dilakukan monitoring dengan menjalankan aplikasi tshark pada sisi switch distribusi dengan perintah: tshark -f "tcp port 80" -i any -w nama_file.cap
Pengujian menggunakan topologi yang sama dengan mengacu pada Gambar 9, hasil pembagian beban request ke setiap server dari monitoring load balancer ODMP pada jaringan existing dan load balancer WRR pada jaringan Openflow dapat dilihat pada Tabel 9.
18 Tabel 9 Monitoring pengujian beban distribusi server Sistem Load balancer Jaringan existing LB ODMP
Jaringan Openflow LB WRR
IP Server Server 1 Server 2 Server 3 Server 1 Server 2 Server 3
Hasil Pembagian 33 35 32 48 9 43
Berdasarkan Tabel 9 ditunjukkan, bahwa data request dari client menuju server yang berhasil ditangani, dengan peluang yang diberikan oleh load balancer pada setiap server dengan metode ODMP pada sistem load balancer existing dihasilkan bobot rasio peluang setiap server s1:s2:s3 = 1:1:1 terdistribusi 33% pada server 1, 35% pada server 2, dan 32% pada server 3, di mana pada setiap pengujian peluangnya bersifat statis, sedangkan pada metode WRR pada sistem load balancer Openflow 48% terdistribusi pada server 1, 9% terdistribusi pada server 2, dan 43% terdistribusi pada server 3, dari bobot rasio peluang yang dihasilkan pada setiap server s1:s2:s3 = 4:1:4 dan bersifat dinamis pada setiap pengujian, data file hasil capture setiap aplikasi dapat dilihat pada Lampiran 4. Hasil Rata-rata Total Koneksi dan Jam Sibuk Sistem Layanan Web Informasi Kampus UIKA Pengujian dilakukan mengikuti dokumentasi standar ITU-T E.490 yang mengatur framework traffic measurement dan evaluation, seperti ditunjukkan pada Gambar 10. Waktu yang diambil untuk pengujian pengumpulan data mengikuti loop yang ke 2 yaitu, pengujiaan dalam mingguan, hari, dan jam. Metode yang dipakai adalah daily peak period (DPP) berdasarkan dokumen ITU-T E.500 di mana intensitas lalu lintas diukur berturut-turut pada periode waktu tertentu berdasarkan intensitas puncak lalu lintas yang tercatat. Data log aktivitas real time yang diambil selama 3 bulan yaitu maret, april dan mei 2016 dapat dilihat pada Tabel 10. Tabel 10 Puncak jam sibuk Kampus UIKA Bulan Agustus September Oktober
Total Koneksi Tertinggi 353 1120 362
Rerata Total Koneksi 20 80 32
Puncak Jam Sibuk 13:00 - 14:00 10:00 - 14:00 10:00 - 14:00
Hasil yang ditunjukkan pada Tabel 10 menjelaskan bahwa rerata total koneksi yang terbesar terjadi pada bulan September dikarenakan bulan tersebut merupakan waktu terjadinya masa pengisian formulir rencana study (FRS) online ganjil bagi seluruh mahasiswa UIKA, dan waktu jam sibuk terjadi setiap bulannya terjadi pada dimulai sekitar pukul 10.00 sampai pukul14.00 WIB, yang biasanya menurun jumlah koneksi nya sekitar jam istirahat pukul 12.00 WIB. Nilai ini akan dijadikan sebagai rujukan dalam penentuan total koneksi dan waktu pengujian kinerja sistem load balancer.
19
Gambar 10 Framework traffic measurement dan evaluation Hasil Pengujian Sistem Load balancer Pengujian menggunakan aplikasi Tsung sebagai generator request ke server website sebanyak X koneksi perdetik dengan total request sebanyak N mengacu pada Tabel 12, sebagai simulasi proses koneksi dengan beban request yang besar, untuk mendapatkan nilai response time, throughput, total http success connections, dan total http loss connections. Pengujian pertama dilakukan pada system load balancer yang sudah ada dengan metode one domain name multiple ip (ODMP). Skenario topologi pengujian ditunjukkan pada Gambar 11.
Gambar 11 Skenario pengujian existing load balancer
20 Pengujian selanjutnya dilakukan pada sistem load balancer di jaringan Openflow dengan metode weighted round robin, di mana bobot peluang service server yang berubah-rubah pada setiap tahap total koneksi pengujian. Skenario topologi pengujian ditunjukkan pada Gambar 12.
Gambar 12 Skenario pengujian load balancer WRR pada Openflow Dari kedua topologi Gambar 11 dan Gambar 12, skenario pengujian skema pengalamatan IP setiap perangkat dapat dilihat pada Tabel 11. Tabel 11 Alamat IP perangkat Nama Perangkat PC Load 1 PC Load 2 PC Load 3 Web Server 1 Web Server 2 Web Server 3 Router Switch Openflow
Alamat IP 192.168.3.2/24 192.168.3.3/24 192.168.3.4/24 192.168.2.11/24 192.168.2.12/24 192.168.2.13/24 192.168.3.1/24 -192.168.2.1/24 192.168.2.5/24
Saat dilakukan pengujian, client akan melakukan request menggunakan aplikasi Tsung yang akan meng-eksekusi script xml yang berfungsi sebagai alat pembangkit request dan penghasil nilai uji, bentuk struktur dokumen dari Tsung.xml seperti ditunjukkan pada Gambar 13. File Tsung.xml dapat dilihat pada Lampiran 5, akan dieksekusi dengan perintah Tsung -f y.xml start
21
Gambar 13 Struktur file Tsung.xml Perintah di atas akan menghasilkan N koneksi dengan nilai koneksi perdetik sebanyak X request dan terdapat 30 script file Tsung.xml untuk melakukan pengujian, di mana X request, N koneksi dan Y nama file mengacu pada Tabel 12. Tabel 12 Skenario total koneksi X : Koneksi per detik 100 200 300 400 500 100 200 300 400 500 100 200 300 400 500 100 200 300 400 500 100 200 300 400 500 100 200 300 400 500
N : Total Koneksi
Y : Nama File Script Tsung
4000
6000
8000 Tsung_N_X.xml 10000
100000
1000000
22 Hasil agregasi rerata pengujian Hasil dari pengujian kinerja sistem load balancer, didapatkan nilai agregasi rerata terdahap QoS dari setiap pengujian yang dilakukan sebanyak 10 kali perulangan. Hasil rerata setiap pengujian dapat dilihat pada Tabel 13. 1.
Response Time Hasil nilai rerata total response time per skenario kedatangan koneksi, antara sistem load balancer existing dengan sistem load balancer Openflow berdasarkan data pada Tabel 13, dapat disajikan ke dalam bentuk grafik seperti ditunjukkan pada Gambar 14. Tabel 13 Hasil agregasi rerata pengujian per kedatangan koneksi Jaringan Existing ODMP Jaringan Openflow WRR Con Total Con
4000
6000
8000
10000
100000
1000000
Per Sec
Respon se Time
Throug hput
Succes Con
Loss Con
100 200 300 400 500 100 200 300 400 500 100 200 300 400 500 100 200 300 400 500 100 200 300 400 500 100 200 300 400 500
0.13 0.56 0.85 1.59 2.13 0.14 1.13 2.61 2.97 2.90 0.15 1.45 4.29 4.18 3.84 0.16 2.27 11.27 14.78 18.46 0.16 22.31 102.10 122.90 133.70 0.33 13.17 79.60 180.20 139.30
276.39 431.70 496.20 479.43 470.34 279.86 490.04 548.90 570.32 527.05 280 515.88 569.96 582.51 516.27 282.12 531.45 579.10 545.96 489.70 294.66 563.39 569.01 548.50 511.53 311.92 589.05 577.04 573.48 578.39
3785 3999 3999 3999 3999 5752 5999 5999 5858 5301 7749 7999 6948 6145 5460 9997 9999 9641 9016 8668 99969 92565 71149 66648 51646 999796 625164 143939 43969 370840
16 1 1 1 2 10 1 1 2 2 18 1 2 3 3 3 1 359 984 1332 6 4102 28852 33352 27383 14 8992 11561 6032 61455
Respo nse Time 0.14 0.57 1.98 1.67 2.39 0.15 0.95 2.65 3.11 2.78 0.15 1.5 4.38 4.23 3.72 0.16 2.67 12.91 15.98 17.84 0.16 9.81 32.68 36.85 27.75 0.16 10.37 18.19 22.25 23.38
Through put
Success Con
Loss Con
276.85 436.72 470.03 477.55 455.86 278.63 505.72 557.23 525.99 531.27 278.14 507.22 554.63 536.78 494.41 286.20 525.72 518.27 478.82 460.27 293.55 567.04 569.64 500.61 485.01 303.81 599.25 592.00 554.05 520.62
3765 3982 3872 3980 3981 5859 5994 5960 5299 5314 7640 7978 7114 5727 5208 9997 9993 9536 9102 8570 99972 88727 63049 43633 46611 999415 793578 515027 310434 366753
19 18 29 21 19 34 6 40 13 67 19 22 36 23 37 3 7 464 898 1430 6 3773 36951 56367 24783 56 76423 51473 41233 27413
23
Gambar 14 Rerata perbandingan response time Nilai rerata response time pada setiap sistem load balancer, di mana pada skenario total koneksi layanan server web yang rendah menghasilkan nilai kinerja yang berimbang dengan selisih yang tidak terlalu signifikan, namun pada skenario total koneksi layanan server web yang besar pada total connections 100000 dan 1000000, ditampilkan bahwa system load balancer WRR pada jaringan Openflow menghasilkan nilai rerata response time lebih baik dibandingkan dengan system load balancer ODMP pada jaringan existing. Hal ini disebabkan karena utilitas penggunaan sumber daya komputasi perangkat switch Openflow menggunakan sumber daya yang tidak terlalu besar dibandingkan dengan sistem load balancer ODMP pada jaringan existing, karena proses pemilihan forwarding data tidak lagi berada pada perangkat sistem load balancer yang existing, namun sudah terbagi beban pada perangkat controller di jaringan Openflow. 2.
Throughput Pengukuran kinerja throughput yang dilakukan pada penelitian ini adalah analisis terhadap rerata nilai throughput layanan bebarapa web server yang berhasil dicatat untuk total paket dalam satuan waktu pada interface networking pc uji. Analisis throughput ini digunakan untuk mengetahui kemampuan sebenarnya suatu jaringan. Hasil rerata perbandingan total throughput per skenario, antara sistem load balancer Openflow dengan sistem load balancer existing berdasarkan data pada Tabel 13, dapat disajikan ke dalam bentuk grafik seperti ditunjukkan pada Gambar 15. Nilai rerata throughput pada setiap sistem load balancer, di mana untuk nilai throughput sistem load balancer ODMP pada jaringan existing sedikit lebih baik dari pada sistem load balancer WRR pada jaringan Openflow. Hal ini disebabkan karena nilai throughput memang berkorelasi dengan jumlah paket yang berhasil
24 diterima oleh client yang berasal dari server web, semakin banyak packet http success connections web server yang diterima semakin besar pula nilai throughput.
Gambar 15 Rerata perbandingan throughput Total http success connections Pengukuran kinerja http success connections yang dilakukan adalah analisis terhadap jumlah request yang berhasil dijawab oleh beberapa server web untuk akses single page yang sama, melalui masing-masing sistem load balancer yang berhasil dicatat. Hasil perbandingan rerata total http success connections per skenario pengujian, antara sistem load balancer Openflow dengan sistem load balancer existing berdasarkan data pada Tabel 13, dapat disajikan ke dalam bentuk grafik seperti ditunjukkan pada Gambar 16. 3.
Gambar 16 Rerata perbandingan http success connections Pada hasil perhitungan rerata http success connections pada setiap sistem load balancer, di mana untuk trafik beban yang rendah kedua sistem load balancer memiliki nilai
25 kinerja yang berimbang dengan selisih rerata yang tidak terlalu signifikan, namun setelah dibebani dengan trafik yang besar pada total connections 1000000, dapat dilihat pada Tabel 13 bahwa sistem load balancer yang memiliki rerata http success connections terbesar adalah sistem load balancer WRR pada jaringan Openflow dibandingkan dengan sistem load balancer ODMP pada jaringan existing.
4.
Total http loss connections Pengukuran kinerja http loss connections yang dilakukan adalah analisis terhadap jumlah request yang gagal dijawab oleh beberapa server web yang didapat dari total koneksi yang dihasilkan oleh aplikasi Tsung dikurangi dengan total http success connections. Hasil perbandingan rerata total http loss connections per skenario pengujian, antara sistem load balancer Openflow dengan sistem load balancer existing berdasarkan data pada Tabel 13, dapat disajikan ke dalam bentuk grafik seperti ditunjukkan pada Gambar 17.
Gambar 17 Rerata perbandingan http loss connections Pada hasil perhitungan rerata http loss connections pada setiap sistem load balancer, di mana untuk trafik beban yang rendah sistem load balancer ODMP memiliki nilai kinerja sedikit lebih baik, dengan selisih rerata yang tidak terlalu signifikan, namun setelah dibebani dengan trafik yang besar dimulai pada total connections 100000 dan 1000000, dapat dilihat pada Tabel 13 sistem load balancer yang memiliki rerata http loss connections yang lebih baik adalah sistem load balancer WRR pada jaringan Openflow dibandingkan dengan sistem load balancer ODMP pada jaringan existing. Hal ini terjadi karena fungsi algoritme load balancer pada proses control plane untuk pemilihan bagaimana paket tersebut akan diteruskan pada proses data plane masih terjadi di dalam perangkat sistem load balancer ODMP, maka dengan trafik beban yang rendah kinerja komputasi perangkat tersebut tidak terlalu terbebani menjadikan proses data plane menjadi lebih terjaga, sedangkan ketika trafik beban yang besar, kinerja komputasi perangkat tersebut menjadi lebih terbebani, menjadikan pada proses data plane menjadi banyak paket komunikasi yang hilang. Sistem load balancer WRR pada jaringan Openflow, di mana proses control plane dan data plane terpisah secara perangkat pada sistem load balancer, sehingga terdapat delay komunikasi terhadap fungsi algoritme load balancer pada proses control plane untuk pemilihan bagaimana paket tersebut akan diteruskan pada proses data plane. Hal ini perlu ditingkatkan mekanisme link komunikasi antara controller dan switch Openflow, selain itu mekanisme waktu pembaharuan
26 waktu informasi flow table agar lebih disesuiakan, sehingga pada trafik beban yang rendah dapat lebih meminimalkan kehilangan paket koneksi, untuk trafik beban yang tinggi kinerja komputasi perangkat sistem load balancer WRR tidak terlalu terbebani dibandingkan dengan perangkat sistem load balancer ODMP.
Hasil rerata total koneksi pengujian Data akumulasi hasil rerata total kedatangan koneksi per detik, untuk masingmasing skenario total koneksi pengujian pada jaringan Existing dan Openflow. Didapatkan nilai total rerata perbandingan kinerja QoS (Throughput, Reponse Time, HTTP Success Con, dan HTTP Loss Con) yang sebelumnya dilakukan proses pemilihan data yang valid, dengan mengeliminasi data yang tidak sebanding untuk total request yang dihasilkan aplikasi Tsung pada setiap skenario kedatangan request per detik, dan dihitung nilai persentase perubahan kinerja. Data hasil pengujian rerata total koneksi dapat dilihat pada Tabel 14 dan dihitung menggunakan Persamaan 6, 7, 8 dan 9. Tabel 14 Hasil pengujian rerata total koneksi Total Con
RT (s)
4000 6000 8000 10000 100000 Rerata
1.43 1.87 1.45 9.39 75.05 14.87
Jaringan Existing ODMP Tr (Kbps) Success Con 460.49 3999 519.47 5999 515.88 7999 485.66 9464 470.73 79255 408.70 17786
Loss Con
RT (s)
1 1 1 536 20736 3546
1.54 1.8 1.5 9.91 23.23 6.33
Jaringan Openflow WRR Tr (Kbps) Success Con 456.71 3981 531.48 5977 507.22 7978 453.86 9440 454.6 68885 400.64 16043
Loss Con 19 23 22 560 31108 5289
Keterangan: RT = Response Time (s) Tr = Throuhput (Kbps) Berdasarkan Tabel 14 diperoleh persentase perubahan kinerja, 1. Nilai persentase perubahan kinerja response time. Rerata 𝑟𝑒𝑠𝑝𝑜𝑛𝑠𝑒 𝑡𝑖𝑚𝑒 𝐸𝑥𝑖𝑠𝑡𝑖𝑛𝑔 − Rerata 𝑟𝑒𝑠𝑝𝑜𝑛𝑠𝑒 𝑡𝑖𝑚𝑒 𝑂𝑝𝑒𝑛𝐹𝑙𝑜𝑤 𝑥100% Rerata 𝑟𝑒𝑠𝑝𝑜𝑛𝑠𝑒 𝑡𝑖𝑚𝑒 𝐸𝑥𝑖𝑠𝑡𝑖𝑛𝑔
= 2.
14.87−6.33 14.87
𝑥100% = 57%
Nilai persentase perubahan kinerja throughput. Rerata 𝑡ℎ𝑟𝑜𝑢𝑔ℎ𝑝𝑢𝑡 𝐸𝑥𝑖𝑠𝑡𝑖𝑛𝑔 − Rerata 𝑡ℎ𝑟𝑜𝑢𝑔ℎ𝑝𝑢𝑡 𝑂𝑝𝑒𝑛𝐹𝑙𝑜𝑤 𝑥100% Rerata 𝑡ℎ𝑟𝑜𝑢𝑔ℎ𝑝𝑢𝑡 𝐸𝑥𝑖𝑠𝑡𝑖𝑛𝑔
= 3.
....... (6)
408.70−400.64 408.70
.............(7)
𝑥100% = 2%
Nilai persentase perubahan kinerja http success conn. Rerata 𝑠𝑢𝑐𝑐𝑒𝑠𝑠 𝑐𝑜𝑛 𝐸𝑥𝑖𝑠𝑡𝑖𝑛𝑔 − Rerata 𝑠𝑢𝑐𝑐𝑒𝑠𝑠 𝑐𝑜𝑛 𝑂𝑝𝑒𝑛𝐹𝑙𝑜𝑤 𝑥100% Rerata 𝑠𝑢𝑐𝑐𝑒𝑠𝑠 𝑐𝑜𝑛 𝐸𝑥𝑖𝑠𝑡𝑖𝑛𝑔 =
17786−16043 17786
𝑥100% = 10%
............ (8)
27 4.
Nilai persentase perubahan kinerja http loss conn. Rerata 𝑙𝑜𝑠𝑠 𝑐𝑜𝑛 𝐸𝑥𝑖𝑠𝑡𝑖𝑛𝑔 − Rerata 𝑙𝑜𝑠𝑠 𝑐𝑜𝑛 𝑂𝑝𝑒𝑛𝐹𝑙𝑜𝑤 𝑥100% Rerata 𝑙𝑜𝑠𝑠 𝑐𝑜𝑛 𝐸𝑥𝑖𝑠𝑡𝑖𝑛𝑔 =
3546−5289 3546
................... (9)
𝑥100% = -49%
Dari data yang ditunjukkan pada Tabel 14 dapat digambarkan grafik dari kedua jenis sistem load balancer yang diujikan, seperti ditunjukkan pada Gambar 18.
Gambar 18 Grafik hasil pengujian total koneksi Dari hasil yang ditunjukkan pada Tabel 14 dan Gambar 18 dapat dilihat bahwa untuk sistem load balancer ODMP pada jaringan existing memiliki response time dengan total rata-rata sebesar 14.87 dan sistem load balancer WRR pada jaringan Openflow memiliki response time dengan total rata-rata sebesar 6.33s. Hasil tersebut dapat dianalisis dengan perhitungan persentase perubahan kinerja terhadap nilai response time, di mana terjadi penurunan nilai response time sebesar 57% dari sistem load balancer ODMP pada jaringan existing menjadi sistem load balancer WRR pada jaringan Openflow. Hal ini disebabkan karena utilitas penggunaan sumber daya komputasi perangkat switch Openflow menggunakan sumber daya komputasi yang tidak terlalu besar dibandingkan dengan sistem load balancer ODMP pada jaringan existing, karena proses pemilihan forwarding data tidak lagi berada pada perangkat sistem load balancer yang existing, namun sudah terbagi beban pada perangkat controller di jaringan Openflow, sehingga dengan penerapan sistem load balancer WRR pada jaringan Openflow dapat meningkatkan kinerja response time. Throughput sistem load balancer ODMP pada jaringan existing memiliki total ratarata sebesar 408.70 Kbps dan sistem load balancer WRR pada jaringan Openflow memiliki throughput dengan total rata-rata sebesar 400.64 Kbps. Hasil tersebut dapat dianalisis dengan perhitungan persentase perubahan kinerja terhadap nilai throughput di mana terjadi penurunan yang tidak terlalu signifikan sebesar 2% dari sistem load balancer ODMP pada jaringan existing menjadi sistem load balancer WRR pada jaringan
28 Openflow. Hal ini disebabkan karena nilai throughput memang berkorelasi dengan jumlah paket yang berhasil diterima oleh client yang berasal dari server web, semakin banyak packet http success connections web server yang diterima semakin besar pula nilai throughput. HTTP loss connections sistem load balancer ODMP pada jaringan existing memiliki total rata-rata sebesar 3546 koneksi dan sistem load balancer WRR pada jaringan Openflow memiliki HTTP loss connections dengan total rata-rata sebesar 5289. Hasil tersebut dapat dianalisis di mana terjadi peningkatan sebesar 49% HTTP loss connections dari sistem load balancer ODMP pada jaringan existing menjadi sistem load balancer WRR pada jaringan Openflow. Hal ini terjadi karena fungsi algoritme load balancer pada proses control plane untuk pemilihan bagaimana paket tersebut akan diteruskan pada proses data plane masih terjadi di dalam perangkat sistem load balancer ODMP, maka dengan trafik beban yang rendah kinerja komputasi perangkat tersebut tidak terlalu terbebani menjadikan proses data plane menjadi lebih terjaga, sedangkan ketika trafik beban yang besar, kinerja komputasi perangkat tersebut menjadi lebih terbebani menjadikan proses data plane menjadi banyak paket komunikasi yang hilang. Sistem load balancer WRR pada jaringan Openflow, di mana proses control plane dan data plane terpisah secara perangkat pada sistem load balancer, sehingga terdapat delay komunikasi terhadap fungsi algoritme load balancer pada proses control plane untuk pemilihan bagaimana paket tersebut akan diteruskan pada proses data plane. Hal ini perlu ditingkatkan mekanisme link komunikasi antara controller dan switch Openflow, selain itu mekanisme perubahan waktu informasi flow table agar lebih disesuiakan, sehingga pada trafik beban yang rendah dapat lebih meminimalkan kehilangan paket koneksi, untuk trafik beban yang tinggi kinerja komputasi perangkat sistem load balancer WRR tidak terlalu terbebani dibandingkan dengan perangkat sistem load balancer ODMP. HTTP success connections sistem load balancer ODMP pada jaringan existing memiliki total rata-rata sebesar 17786 koneksi dan sistem load balancer WRR pada jaringan Openflow memiliki HTTP success connections dengan total rata-rata sebesar 16043 koneksi. Hasil tersebut dapat dianalisis di mana terjadi penurunan sebesar 10% HTTP success connections dari sistem load balancer ODMP pada jaringan existing menjadi sistem load balancer WRR pada jaringan Openflow. Hal ini disebabkan dengan permasalahan yang sama yang terjadi pada kondisi HTTP loss connections. Hasil dari seluruh pengujian, di mana sistem load balancer pada jaringan Openflow memiliki kinerja yang lebih baik untuk jaringan dengan beban request yang besar, dengan selisih nilai response time yang besar. Nilai response time sangat dibutuhkan dalam proses transaksi layanan aplikasi berbasis web. Nilai throughput yang tidak jauh berbeda, yang didadapat berdasarkan total packet success connections yang berhasil ditangkap oleh aplikasi penguji Tsung. Nilai total HTTP success connections dan HTTP loss connections yang didapat dalam pengujian ini terpengaruh dari keberhasilan aplikasi Tsung dalam meng-generate total request, di mana aplikasi Tsung memiliki batasan dalam kemampuan menulis file descriptor pada kernel sistem operasi dalam jumlah yang besar, selain itu adanya waktu propagasi dalam penentuan forwarding data dalam proses algoritme sistem load balancer WRR pada jaringan Openflow yang membuat HTTP success connections dan HTTP loss connections pada sistem load balancer ODMP menjadi lebih baik.
29
5 SIMPULAN DAN SARAN Simpulan Model perancangan protokol Openflow dapat diimplementasikan di jaringan data center Kampus UIKA, sebagai sistem load balancer pada layanan klaster server web. Algoritme WRR dipakai sebagai disiplin penjadwalan dalam penentuan beban tugas pelayanan setiap server. Paramater total request pada setiap level distribusi dan kemampuan kapasitas link transfer setiap server dapat dijadikan sebagai penentuan beban tugas pelayanan setiap server. Hal ini membuat konsep SDN pada protokol Openflow dapat dipakai untuk mengembangkan suatu sistem jaringan yang sesuai dan dinamis berdasarkan kebutuhan dan permasalahan yang ada pada Kampus UIKA. Hasil analisis dari proses pengujian dengan total koneksi yang besar pada total koneksi di atas 100.000 sampai 1.000.000 koneksi, di mana sistem load balancer pada jaringan Openflow mampu mencapai kinerja yang lebih baik untuk semua parameter QoS kecuali throughput yang tidak signifikan perbedaannya. Tetapi berdasarkan data agregasi dapat disimpulkan kembali, di mana sistem load balancer WRR dapat meningkatkan kinerja response time sebesar 57% dari sistem load balancer sebelumnya yang sudah ada. Namun demikian terjadi penurunan untuk kinerja throughput sebesar 2%, HTTP success connections sebesar 10%, dan meningkatkan HTTP loss connections sebesar 49%. Saran Hasil yang diperoleh pada penelitian ini belum membahas bagaimana proses komunikasi yang terjadi antara controller dan openswitch secara empiris. Oleh karena itu pada penelitian selanjutnya perlu dilakukan analisis terhadap kinerja dan mekanisme komunikasi antara controller dan openswitch yang optimal. Terdapat perbedaan algoritme yang digunakan antara sistem load balancer jaringan existing yaitu ODMP dan jaringan Openflow yaitu WRR (weighted round robin). Oleh karena itu perlu dilakukan pengujjian untuk kedua sistem load balancer, yang sama-sama menggunakan algoritme penjadwalan yang sama, dalam kasus ini menggunakan algoritme WRR.
30
DAFTAR PUSTAKA
Amrun H. 2014. Implementasi dan analisis kinerja switch openflow dan switch konvensional pada jaringan komputer [skripsi]. Bogor (ID): Institut Pertanian Bogor. Azodolmolky S. 2013. Software Defined Networking With OpenFlow. Birmingham (UK): Packt Publishing Ltd. Chen W, Li H, Shang Z, Ma Q. 2014. Design and implementation of server cluster dynamic load balancing in virtualization environment based on OpenFlow. Di dalam: [editor tidak diketahui], editor. Proceedings of The Ninth International Conference on Future Internet Technologies [Internet]; 2014 Juni 18 -20. Tokyo (JP): ACM. hlm 1-6. Hottmar V, Adamec B. 2012. Analytical model of a weighted round robin service system. JECE. 2012:17:17--17:17. Idatriska, M RR, Mulyana A. 2014. Perancangan dan simulasi antrian paket dengan model antrian M/M/N di dalam suatu jaringan. JSM STMIK Mikroskil. 15:111–120. Kakiay TJ. 2004. Dasar Teori Antrian Untuk Kehidupan Nyata. Yogyakarta (ID): Andi. Kaur K, Kaur S. 2016. Flow statistics based load balancing in openflow. Di dalam: Karamjeet Kaur, Sukhveer Kaur, Vipin Gupta, editor. 2016 International Conference on Advances in Computing, Communications and Informatics (ICACCI); 2016 Sept 21-24, Jaipur, India. IEEE. 378–381. Khatri V. 2013. Analysis of openflow protocol in local area network [Tesis]. Tampere (FIN): Tampere University of Technology. Kim H, Feamster N. 2013. Improving network management with software defined networking. IEEE Communications Magazine. 51:114–119. Kreutz D, Ramos F. 2014. Software-defined networking: a comprehensive survey. arXiv preprint. 103(1):1–61. Kustituanto B, Badrudin R. 1994. Statistika 1 (Deskriptif). Jakarta (ID): Gunadarma. Li DC, Wu C, Chang FM. 2005. Determination of the parameters in the dynamic weighted Round-Robin method for network load balancing. Computers and Operations Research. 32(8):2129–2145. Lukitasari D. 2010. Analisis perbandingan load balancing web server tunggal dengan web server cluster menggunakan linux virtual server. Jurnal Generic. 5(2):31–34. Mckeown N, Anderson T, Balakrishnan H, Parulkar G, Peterson L, Rexford J, Shenker S, Turner J. 2008. OpenFlow: enabling innovation in campus networks. SIGCOMM Comput. Commun. 38(2):69-74. Mendonca M, Astuto B. 2013. Software defined networking for heterogeneous networks. Ieee Mmtc. 3:1–3. Niclausse N. 2015. Tsung Documentation. Ningrum G. 2006. Sistem antrian M/G/1, M/M/1 DAN M/D/1 [tesis]. Bogor (ID): Institut Pertanian Bogor Othman MM, Okamura K, Mm O, Okamura K, Othman OMM, Okamura K. 2010. Design and implementation of application based routing using OpenFlow. Proc. 5th Int. Conf. Futur. Internet Technol. - CFI ’10:60. Sabastian TA, Guarddin G. 2013. Membangun Layanan IaaS Cloud Berbasis Perangkat
31 Lunak F/OSS Di Universitas Indonesia. :7–12. Zhang Z, Xiao L, Tao Y, Tian J, Wang S, Liu H. 2013. A model based load-balancing method in IaaS cloud. Proc. Int. Conf. Parallel Process.:808–816.
32
LAMPIRAN
Lampiran 1 Source code akuisisi data total koneksi setiap fakultas import MySQLdb class Database: def __init__(self,host,user,passwd,db): self.__host=host self.__user=user self.__passwd=passwd self.__db=db def Koneksi(self): try: self.__con = MySQLdb.connect(self.__host,self.__user, self.__passwd, self.__db) print "Koneksi berhasil..." except: print "Koneksi gagal" def TampilData(self): #request FT try: global Req_ft self.__kursor = self.__con.cursor() self.__kursor.execute("SELECT ip_address, ip_server FROM adm_activities WHERE activity_dt like '2015-1015%' and ip_address like '10.10.%'") data_ft = self.__kursor.fetchall() Req_ft = len(data_ft) print "Total request FT ",Req_ft except: print "Query gagal" #request fai try: global Req_fai self.__kursor = self.__con.cursor() self.__kursor.execute("SELECT ip_address, ip_server FROM adm_activities WHERE activity_dt like '2015-10-15%' and ip_address like '192.168.10.%'")
33 data_fai = self.__kursor.fetchall() Req_fai = len(data_fai) print "Total request FAI ",Req_fai except: print "Query gagal" #request fe try: global Req_fe self.__kursor = self.__con.cursor() self.__kursor.execute("SELECT ip_address, ip_server FROM adm_activities WHERE activity_dt like '2015-1015%' and ip_address like '192.168.16.%' union SELECT ip_address, ip_server FROM adm_activities WHERE activity_dt like '2015-10-15%' and ip_address like '192.168.17.%' union SELECT ip_address, ip_server FROM adm_activities WHERE activity_dt like '2015-10-15%' and ip_address like '192.168.18.%' union SELECT ip_address, ip_server FROM adm_activities WHERE activity_dt like '2015-10-15%' and ip_address like '192.168.19.%'") data_fe = self.__kursor.fetchall() Req_fe = len(data_fe) print "Total request FE ",Req_fe except: print "Query gagal" #request rektorat try: global Req_rektorat self.__kursor = self.__con.cursor() self.__kursor.execute("SELECT ip_address, ip_server FROM adm_activities WHERE activity_dt like '2015-10-15%' and ip_address like '192.168.30.%' union SELECT ip_address, ip_server FROM adm_activities WHERE activity_dt like '2015-10-15%' and ip_address like '192.168.40.%' union SELECT ip_address, ip_server FROM adm_activities WHERE activity_dt like '2015-10-15%' and ip_address like '192.168.100.%'") data_rektorat = self.__kursor.fetchall() Req_rektorat = len(data_rektorat) print "Total request Rektorat ",Req_rektorat except: print "Query gagal" db = Database("172.16.18.20","*******","******","********")
34 db.Koneksi() db.TampilData() Lampiran 2 Source code normalisasi data, rata-rata, varians, dan bobot server. import math import bandwith import koneksi_db ft1 = float(koneksi_db.Req_ft) fai1 = float(koneksi_db.Req_fai) fe1 = float(koneksi_db.Req_fe) rektorat1 = float(koneksi_db.Req_rektorat) def Wrr(): #global rata global b1 global b2 global b3 #normalisasi data list = [ft1,fai1,fe1,rektorat1] mini = min(list) maxi = max(list) rentang = maxi-mini ft = (ft1 fai = (fai1 fe = (fe1 rektorat =
mini) / rentang - mini) / rentang mini) / rentang (rektorat1 - mini) / rentang
print "normalisasi :",ft print "normalisasi :", fai print "normalisasi :",fe print "normalisasi :",rektorat #rata - rata rata = (ft + fai + fe + rektorat) / 4 print "Beban rata - rata request : ", rata #load var = rata,2) + print
varians (pow(ft - rata,2) + pow(fai - rata,2) + pow(fe pow(rektorat - rata,2))/4 "Beban varians request : ", var
#peluang weighted robin tr1 = float(bandwith.tr_s1) tr2 = float(bandwith.tr_s2) tr3 = float(bandwith.tr_s3)
35 tr = tr1+tr2+tr3 p1 = (tr1/tr)*(1/var) p2 = (tr2/tr)*(1/var) p3 = (tr3/tr)*(1/var) #peluang print "Peluang server 1 = ",p1 print "Peluang server 2 = ",p2 print "Peluang server 3 = ",p3 b1 = math.ceil(p1) b2 = math.ceil(p2) b3 = math.ceil(p3) print "Pemberian tugas pembulatan server 1 = ",b1 print "Pemberian tugas pembulatan server 2 = ",b2 print "Pemberian tugas pembulatan server 3 = ",b3 Wrr() Lampiran 3 Source code load balancer WRR pox controller """ Author Haichen Shen Module to perform round-robin load balancing. """ from pox.core import core import pox.Openflow.libOpenflow_01 as of from pox.lib.revent import * from pox.lib.util import dpidToStr from pox.lib.packet.ethernet import ethernet from pox.lib.packet.arp import arp from pox.lib.addresses import IPAddr, EthAddr import time import Load_Average log = core.getLogger() IDLE_TIMEOUT = 5 # in seconds HARD_TIMEOUT = 0 # infinity #LOAD_BALANCER_IP = IPAddr('192.168.2.5') #LOAD_BALANCER_MAC = EthAddr('a0:b3:cc:df:7f:2d') LOAD_BALANCER_IP = IPAddr('192.168.2.5') LOAD_BALANCER_MAC = EthAddr('E4:8D:8C:0A:86:14')
36 b1 = int(Load_Average.b1) b2 = int(Load_Average.b2) b3 = int(Load_Average.b3) class Load balancer (EventMixin): class Server: def __init__ (self, ip, mac, port): self.ip = IPAddr(ip) self.mac = EthAddr(mac) self.port = port def __str__(self): return','.join([str(self.ip), str(self.mac), str(self.port)]) def __init__ (self, connection): self.connection = connection self.listenTo(connection) # Initialize the server list self.servers = [ self.Server('192.168.2.11', '66:24:28:40:ae:e7', 6), self.Server('192.168.2.12', '52:06:e4:88:55:21', 7), self.Server('192.168.2.13', 'e6:24:ef:83:8c:1d', 2)] self.last_server = 0 #Penambahan variabel self.s1 = b1 self.s2 = b2 self.s3 = b3 self.counter1 = 0 self.counter2 = 0 self.counter3 = 0 def get_next_server (self): #Modifikasi weighted Round-robin if self.counter1 < self.s1 : self.counter1 = self.counter1 + 1 return self.servers[0] elif self.counter2 < self.s2: self.counter2 = self.counter2 + 1 return self.servers[1]
37 elif self.counter3 < self.s3: self.counter3 = self.counter3 + 1 return self.servers[2] else: self.counter1 = 0 self.counter2 = 0 self.counter3 = 0 self.counter1 = self.counter1 + 1 return self.servers[0] def handle_arp (self, packet, in_port): # Get the ARP request from packet arp_req = packet.next # Create ARP reply arp_rep = arp() arp_rep.opcode = arp.REPLY arp_rep.hwsrc = LOAD_BALANCER_MAC arp_rep.hwdst = arp_req.hwsrc arp_rep.protosrc = LOAD_BALANCER_IP arp_rep.protodst = arp_req.protosrc # Create the Ethernet packet eth = ethernet() eth.type = ethernet.ARP_TYPE eth.dst = packet.src eth.src = LOAD_BALANCER_MAC eth.set_payload(arp_rep) # Send the ARP reply to client msg = of.ofp_packet_out() msg.data = eth.pack() msg.actions.append(of.ofp_action_output(port = of.OFPP_IN_PORT)) msg.in_port = in_port self.connection.send(msg) def handle_request (self, packet, event): # Get the next server to handle the request server = self.get_next_server()
38 "First install the reverse rule from server to client" msg = of.ofp_flow_mod() msg.idle_timeout = IDLE_TIMEOUT msg.hard_timeout = HARD_TIMEOUT msg.buffer_id = None # Set packet matching # Match (in_port, src MAC, dst MAC, src IP, dst IP) msg.match.in_port = server.port msg.match.dl_src = server.mac msg.match.dl_dst = packet.src msg.match.dl_type = ethernet.IP_TYPE msg.match.nw_src = server.ip msg.match.nw_dst = packet.next.srcip # Append actions # Set the src IP and MAC to load balancer's # Forward the packet to client's port msg.actions.append(of.ofp_action_nw_addr.set_src(L OAD_BALANCER_IP)) msg.actions.append(of.ofp_action_dl_addr.set_src(LOAD_BALAN CER_MAC)) msg.actions.append(of.ofp_action_output(port = event.port)) self.connection.send(msg) "Second install the forward rule from client to server" msg = of.ofp_flow_mod() msg.idle_timeout = IDLE_TIMEOUT msg.hard_timeout = HARD_TIMEOUT msg.buffer_id = None msg.data = event.ofp # Forward the incoming packet # Set packet matching # Match (in_port, MAC src, dst MAC, IP src, IP dst) msg.match.in_port = event.port msg.match.dl_src = packet.src msg.match.dl_dst = LOAD_BALANCER_MAC msg.match.dl_type = ethernet.IP_TYPE msg.match.nw_src = packet.next.srcip
39 msg.match.nw_dst = LOAD_BALANCER_IP # Append actions # Set the dst IP and MAC to load balancer's # Forward the packet to server's port msg.actions.append(of.ofp_action_nw_addr.set_dst(s erver.ip)) msg.actions.append(of.ofp_action_dl_addr.set_dst(s erver.mac)) msg.actions.append(of.ofp_action_output(port = server.port)) self.connection.send(msg) log.info("Installing %s <-> %s" % (packet.next.srcip, server.ip)) def _handle_PacketIn (self, event): packet = event.parse() if packet.type == packet.LLDP_TYPE or packet.type == packet.IPV6_TYPE: # Drop LLDP packets # Drop IPv6 packets # send of command without actions msg = of.ofp_packet_out() msg.buffer_id = event.ofp.buffer_id msg.in_port = event.port self.connection.send(msg) elif packet.type == packet.ARP_TYPE: # Handle ARP request for load balancer # Only accept ARP request for load balancer if packet.next.protodst != LOAD_BALANCER_IP: return log.debug("Receive an ARP request") self.handle_arp(packet, event.port) elif packet.type == packet.IP_TYPE:
40 # Handle client's request # Only accept ARP request for load balancer if packet.next.dstip != LOAD_BALANCER_IP: return log.debug("Receive an IPv4 packet from %s" % packet.next.srcip) self.handle_request(packet, event) class load_balancer (EventMixin): def __init__ (self): self.listenTo(core.Openflow) def _handle_ConnectionUp (self, event): log.debug("Connection %s" % event.connection) Load balancer(event.connection) def launch (): # Start load balancer core.registerNew(load_balancer) Lampiran 4 Hasil pengujian distribusi traffic pada sistem kerja load balancer Metode One Domain Multiple IP (ODMP)
41
Metode Weighted Round Robin (WRR)
42
Lampiran 5 Source code Tsung.xml
<servers> <server host="uji.ac.id" port="80" type="tcp"/> <arrivalphase phase="1" duration="1" unit="minute"> <users maxnumber="500" arrivalrate="100" unit="second"/> <sessions> <session name="es_load" weight="1" type="ts_http"> <request subst="true">
43
RIWAYAT HIDUP
Penulis dilahirkan di Bogor, provinsi Jawa Barat pada tanggal 11 Januari 1987 sebagai anak Kedua dari tiga bersaudara dari Bapak Rasito dan Ibu Solimah. Pendidikan Sekolah Menengah Kejuruan Negeri (SMKN) 1 Gunung Putri Bogor, lulus tahun 2005 dengan penjurusan Kimia Industri. Kemudian melanjutkan bekerja di PT. Sari Multi Utama (SMU) pada tahun 2007 sampai 2008 dan PT. Adiwira Persada (AWP) 2008 sampai 2010. Pendidikan sarjana ditempuh di Universitas Ibn Khaldun, Bogor dengan Program Studi Teknik Informatika diawal masuk tahun 2007 dan lulus tahun 2012. Setelah lulus penulis bekerja sebagai staf laboran Universitas Ibn Khaldun, yang selanjutnya dialih fungsikan menjadi staf pengajar. Tahun 2013 penulis diterima diprogram studi Ilmu Komputer, Fakultas Matematika dan Ilmu Pengetahuan Alam Sekolah Pascasarjana Institut Pertanian Bogor.
