BAB III ANALISA KEBUTUHAN DAN PERANCANGAN SISTEM

Transkripsi

1 digilib.uns.ac.id BAB III ANALISA KEBUTUHAN DAN PERANCANGAN SISTEM Berdasarkan hasil observasi dan analisis yang sudah dilakukan maka dihasilkan kebutuhan dan perancangan untuk High Availability server sebagai berikut: Spesifikasi Perangkat Perangkat perangkat yang digunakan pada penelitian ini dibagi menjadi 2 jenis yaitu hardware dan software Spesifikasi hardware Untuk perangkat yang digunakan dalam penelitian ini penulis menggunkan Virtual machine yang berada pada suatu host VMware hypervisor dengan spesifikasi sebagai berikut: 1. Host VMware ESXi Manufacture : Cisco System Inc Model : UCSC-BASE-M2-C460 CPU Cores : 40 CPUs x GHz Processor Type : Intel(R) Xeon(R) CPU 2.40 GHz VMware version : ISXi standard Memory : MB Storage : 1630 GB 2. Spesifikasi virtual mechine CPU : GHz Memory : 2048 MB Storage : 300 GB Thin Provision Network Adapter : 1 x E1000 1GB/s 18

2 digilib.uns.ac.id Spesifikasi Software Semua server pada penelitian ini menggunakan operating sistm yang sama yaitu FreeBSD 10.0 amd64. Perangkat lunak yang digunakan dalam penelitian ini pada masing masing server adalah sebagai berikut : 1. Load Balancer, aplikasi yang di install adalah HAproxy 1.4 dan CARP 2. Web server, aplikasi yang di install adalah PHP 5.6 dan nginx Database server, aplikasi yang di install adalah Mysql 5.0 dan CARP 4. File server, aplikasi yang di install adalah NFSd 5. Server tester aplikasi yang di install adalah HTTPerf Jalannya Penelitian Skema yang dijalankan pada pembuatan High Availabity Server ini seperti gambar berikut: Skema Penelitian Penjelasan skema dari jalannya penelitian seperti pada gambar 3.1 yaitu sebagai berikut: 1. Pengambilan data Data data yang dibutuhkan yaitu berkaitan dengan kebutuhan dan kendala - kendala yang ada pada system suatu web server seperti : - Web server jika menangani request yang banyak sering kali down - Jika terjadi maintenance pada webserver pasti website down karena server hanya ada Satu - Jika terjadi masalah hardware pada database khususnya harddisk maka data yang ada didalamnya akan sulit untuk didapatkan lagi

3 digilib.uns.ac.id 20 - Meskipun hardware server yang digunakan mempunyai spesifikasi yang besar, tetapi jika terjadi sesuatu misal harus reboot maka web site pasti juga mengalami down. 2. Analisa Data Proses pengecekan semua data yang telah ada yang nantinya digunakan untuk membuat perencanaan terhadap sistem 3. Perencanaan Setelah semua data yang diperlukan terkumpul kemudian dibuat perencanaan untuk pembuatan sistem seperti topologi yang akan digunakan aplikasi yang akan dipakai 4. instalasi dan konfigurasi Proses pembuatan sistem yang didalamnya meliputi instalasi hardware dan software dalam bentuk percobaan. 5. Evaluasi Evaluasi dilakukan untuk mengecek apakah semua komponen yang ada pada sistem sudah berjalan seperti yang direncanakan. Apabila masih terdapat kekurangan pada sistem akan diperbaiki kembali ke skema analisa data 6. Tes Akhir Tes dilakukan untuk memastikan sistem sudah melakukan fungsinya dengan baik. Pengujian yang dilakukan adalah - Pengujian performa dengan parameter Thoughput - Pengujian performa dengan parameter Response time - Pengujian performa dengan parameter reply sukses - Pengujian failover - Pengujian redundansi database 7. Implementasi Implementasi dilakukan apabila sistem High Availability web server sudah beralan dan siap produksi 8. Dokumentasi Pembuatan laporan dipergunakan sebagai dokumentasi penelitian.

4 digilib.uns.ac.id 21 Perancangan Sistem Berdasarkan pengambilan data dan mencari kebutuhan informasi maka perancangan High Availability server sebagai berikut: FILE SERVER LOAD BALANCER 01 WEB 01 DATABASE 01 INTERNET VIRTUAL IP VIRTUAL IP LOAD BALANCER 02 WEB 02 DATABASE 02 Rancangan High Availability Dari gambar 3.2 diatas rancangan High Availability Server dibagi menjadi 3 tahap yaitu: Perancangan load balance server Semakin banyak pengguna yang mengakses web site maka semakin berat pula kerja web server. Karena, web server harus dapat menjawab semua permintaan tersebut tanpa ada yang tertolak. Untuk memenuhi permintaan tersebut maka web server harus memiliki performa yang handah. Untuk memperoleh performa yang handal maka web server harus memiliki resource yang besar pula, tetapi untuk mendapatkan sesource yang besar memerlukan biaya yang sangat besarpula. Terlebih lagi kalau hanya dengan satu server saja jika terjadi kerusakan baik pada sisi hardware atau pun software dari server tersebut maka service tersebut akanberhenti. Akibatnya informasi yang dimiliki tidakakan tersebar dengan kata lain web site akan down atau mati. Untuk mengantisipasi kerusakan tersebut maka diperlukan lebih dari commit satu buah to server user agar dapat menggantikan fungsi

5 digilib.uns.ac.id 22 dari server yang down tadi. Dengan demikian waktu hidup web server menjadi meningkat. Akan tetapi kembali ke biaya lagi, untuk mendapatkan resource yang besar saja harus memerlukan biaya yang sangat besar apalagi harus menyediakan backup yang memiliki resource yang sama. Terlebih lagi resource yang ada pada server backup sedikit kurang bermanfaat karena hanya digunakan saat server utama mati saja. Untuk mengatasi hal tersebut maka dapat menggunakan sistem load balance. Skema load balance Load Balance disini berfungsi untuk membagi permintaan dari pengunjung untuk ditangani oleh lebih dari satu server dengan katalain resource yang ada pada beberapa server tersebut akan terpakai semua dan bisa di katakan di kombinasikan atar kedianya untuk mempeoleh performa yang tinggi. Request yang datang dari pengunjung akan diarahkan ke load balancer baik dengan domain ataupun alamat ip kemudian Load balance akan membagi request tersebut ke server - server yang telah di alokasikan dengan algoritma yang digunakan seperti pada gambar 3.3. Algoritma atau metode yang dapat digunakan dalam load balance sangatlah beragam seperti Round Robin, lease connection, source, URL, DNS round robin, random allocation dan masih banyak commit lagi. to user

6 digilib.uns.ac.id Perancangan failover Dalam mengimplementasikan High Availability web server, redundansi adalah hal yang wajib di terapkan untuk membuat sistem tersebut mempunyai uptime yang tinggi. Redudansi dibutuhkan di semua bagian sistem mulai dari listrik yang harus memiliki lebih dari dua sumber (redundant) untuk membuat mesin selalu menyala, selain itu di sisi network juga harus redundanyaitu memiliki lebih dari satu jalur, Load balancer-pun juga harus begitu lebih dari satu. Dalam penenelitian ini untuk mengimplementasikan failover tersebut pada load balancer penulis menggunakan ip virtual. Dalam FreeBSD untuk membuat ip virtual dapat menggunakan CARP interface. Skema failover Seperti pada gambar 3.4 load balancer server dipasang CARP interface yang memiliki satu alamat ip yang sama, kemudian salah satunya ditunjuk sebagai master dan sisanya sebagai slave. Server yang bertindak sebagai master akan menangani semua traffic yang menuju ke ip virtual tadi. Ketika server master mati maka secara otomatis server yang slave akan menggantikan posisi master yang down kemudian status pada server yag master sebelumnya berubah menjadi slave.

7 digilib.uns.ac.id Perancangan redudansi databases Dalam redudansi database tidak hanya berfungsi sebagai backup saja tetapi juga berfungsi sebagai failover. Selain itu yang paling penting adalah data yang ada di dalamnya harus selalu sama antar keduanya. Terlebih lagi saat salah satu server database mati, selain menjaga agar update data tetap berjalan tanpa merubah setingan dari sisi aplikasi, database server yang mati tadi dipastikan saat hidup bisa melakukan sinkronisasi data dengan server database yang masih menyala. Skema redundansi

8 digilib.uns.ac.id BAB IV IMPLEMENTASI DAN ANALISA HASIL Berdasarkan Perancangan pada pembuatan High Availability Server maka dilakukan pengimplementasian dan analisa untuk mengecek fungsi dari masing - masing bagian sebagi berikut: Topologi jaringan Berikut adalah gambaran scema high availability server yang akan dibangun: LOAD BALANCER WEB VIRTUAL IP DATABASE INTERNET VIRTUAL IP LOAD BALANCER WEB Skema High Availability FILE SERVER DATABASE Pada Gambar 4.1 merupakan gabungan dari loadbalancer, failover, dan replikasi dan redundansi database INTERNET Router gateway switch LOAD BALANCER LOAD BALANCER WEB WEB FILE SERVER DATABASE Topologi fisik Jaringan DATABASE

9 digilib.uns.ac.id 26 Pada gambar 4.2 semua server terletak pada satu jaringan yang sama dan memepunyai ip address yang satu network untuk mempermudah dan mempercepat koneksi antar server. Instalasi Server Dalam subbab ini dijelaska proses instalasi semua server yang nantinya menjadi bagian dari system ini. Skema instalasi yang dilakukan adalah HAProxy Loadbalancer Server server Hardware CARP MySQL-Server 5.6 MySQL Replication Database Server FreeBSD 10.0 Nginx Php 5.6 & php-extension 5.6 NFS Client Web Server Httperf Tester server NFSd File server Skema Instalasi Gambar 4.3 merupakan langkah instalasi yang dilakukan untuk membuat server sesuai dengan fungsi masing masing. Seluruh server yang digunakan menggunakan Operating system yang sama yaitu FreeBSD RELEASE 10.0 yang dapat di unduh di situs resminya RELEASE-amd64-dvd1.iso. Proses instalasi FreeBSD 10.0 dilakukan sama seperti sistem operasi lain Linux dan Windows, langkah pertama dimulai dengan proses booting dari compact disk/flashdisk. Tampilan awal booting seperti pada gambar 5.1 Proses instalasi tidak menggunakan mode GUI (Graphic User Interface) namun instalasi digunakan mode text dikarenakan prosesnya yang lebih cepat dan mudah. Instalasi dimulai ketika muncul bootloader seperti pada gambar 4.4.

10 digilib.uns.ac.id 27 Booting instalasi FreeBSD10.0 Instalasi dilanjutkan dengan menekan tombol Enter, maka muncul pilihan Install seperti pada gambar 4.5 Menu instalasi FreeBSD 10.0 Pilih Install dipergunakan ketika sistem ingin dipasang sistem operasi FreeBSD. Pilih Shell dipergunakan apabila ingin repair/perbaiki sistem operasi dan pilih Live CD digunakan bila ingin mencoba sistem operasi tanpa melakukan instalasi pada hardisk.

11 digilib.uns.ac.id 28 Setelah proses instalasi selesai setting ip dan domain sesuai dengan topologi yang telah dibuat. Untuk memastikan ip yang terkonfigurasi sudah benar atau salah lakukan ping ke google.com dan update ports pada freebsd untuk memperbarui list-list aplikasi yang dapat diinstall di operatingsistem freebsd. Setelah semua konfigurasi dasar sudah terseting di semua server, tingggal proses instalasi aplikasi untuk masing masing bagian adalah sebagai berikut: Pada pembuatan webserver instalasi aplikasi yang diperlukan adalah 1. Instalasi nginx sebagai webserver 2. Instalasi php 5.6 dan php 5.6 extension sebagai bahasa pemrograman untuk membuat website 3. Mounting NFS yang digunakan untuk file-file web site untuk memastikan semua web server mempunya file yang sama Pada pembuatan Loadbalancer instalasi aplikasi yang dilakukan adalah 1. Mengedit kernel dengan menambahkan modul baru yaitu CARP 2. Memastikan carp sudah terpasang dengan perintah sysctl net.inet.carp jika sudah terpasang akan tampil informasi tentang carp yang telah ada 3. Instalasi HAProxy sebagai aplikasi loadbalancer Pada pembuatan database instalasi aplikasi yang dilakukan adalah 1. Mengedit kernel dengan menambahkan modul baru yaitu CARP 2. Memastikan carp sudah terpasang dengan perintah sysctl net.inet.carp jika sudah terpasang akan tampil informasi tentang carp yang telah ada 3. Instalasi MySQL server 5.0 sebagai database Pada pembuatan NFS server tidak perlu melakukan instalasi apapun karena secara default freebsd sudah terinstall nfs tinggal diaktifkan saja. Untuk server untuk melakukan testing aplikasi yang diperlukan adalah httperf yang digunakan untuk testing performa webserver.

12 digilib.uns.ac.id 29 Konfigurasi Aplikasi Server Konfigurasi Webserver Pada web server penulis hanya menggunakan konfigurasi default yang sedah ada, yang perlu ditambahkan adalah konfigurasi penghubung antara nginx dengan php agar nginx dapat mengenali file dengan ekstensi php. Konfigurasi yang ditambahkan adalah location ~ \.php$ { root html; fastcgi_pass :9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME/usr/local/www/nginx$fastcgi_scrip include fastcgi_params; } Pengaktifan modul php pada nginx Nginx dan php-fpm perlu diseting berjalan otomatis ketika booting computer sehingga pengguna server tidak selalu manual menjalankan service. Sisipkan script nginx_enable=yes dan php_fpm_enable="yes" ke file /etc/rc.conf seperti berikut: # echo nginx_enable= YES >> /etc/rc.conf # echo php_fpm_enable= YES >> /etc/rc.conf seting startup aplikasi Untuk menjalankan service - service yang telah dikonfigurasi dengan menggunakan perintah # /usr/local/etc/rc.d/nginx start # /usr/local/etc/rc.d/php-fpm start menjalankan nginx dan php-fpm Untuk mengecek apakah web server sudah benar dengan membuat file php dengan didalamnya berisikan <?php Phpinfo();?> php info

13 digilib.uns.ac.id 30 Jika web server sudah terkonfigurasi dengan benar maka jika membuka file php dibrowser maka web server akan mengeksekusi script php kemudian dikonvert menjadi sebuah file html yang kemudian dibaca oleh web browser. Untuk script diatas jika browser melakukan request maka akan tampil seperti pada gambar Konfigurasi Failover Tampilan web server Dalam membuat system failover penulis menggunakan CARP pada freebsd unutk membuat pseudo devices yang diguanakan sebagai ip virtual. Konfigurasi dimulai dengan merubah kernel pada freebsd, yaitun dengan menduplikat file konfigurasi kernel dengan perintah # cd /usr/src/sys/amd64/conf # cp GENERIC NETMON Kostum kerner File NETMON di tambahkan option carp. Setelah itu config dan install NETMON tersebut dengan perintah # cd /usr/src # make buildkernel KERNCONF=NETMON # make installkernel KERNCONF=NETMON Instalasi kernel Setelah selesai melakukan perubakan pada kernel maka server perlu melakukan reboot untuk merefrash kembali system. Untuk mengecek

14 digilib.uns.ac.id 31 apakah CARP interface sudah terinstall menggunakna perintah Sysctl net.int.carp maka akan muncul # sysctl net.inet.carp net.inet.carp.allow: 1 net.inet.carp.preempt: 1 net.inet.carp.log: 1 net.inet.carp.demotion: 0 Status CARP Kemudian untuk membuat ip virtual dengan merubah pada file /etc/rc.conf. Konfigurasi dilakukan di kedua serever sebagai contoh pada server 1 di konfigurasi sebagai berikut: hostname="lb01.netmon.local" ifconfig_em0="inet netmask " ifconfig_em0_alias0="vhid 1 pass rahasia alias /24" Konfigurasi CARP loadbalancer 1 Kemudian untuk konfigurasi pada server 2 adalah sebagai berikut hostname="lb02.netmon.local" ifconfig_em0="inet netmask " ifconfig_em0_alias0="vhid 1 advskew 100 pass rahasia alias /24" Konfigurasi CARP loadbalancer 2 Pada konfigurasi diatas dapat dilihat bahwa server 1 mempunyai ip management dan server 2 mempunyai ip management dengan keduanya mempunyai satubuah ip yang sama yaitu yang sering disebut sebagai ip virtual. Dari kedua konfigurasi tersebut dapat dilihan server 1 nantinya akan menjadi master, karena pada server 1 mempunya advskew yang lebih kecil dari pada server 2, secara default jika advskew tidak dituliskan maka akan memiliki nilai 0 semakin kecil advskewnya maka memiliki prioritas yang semakin besar. Untuk menjalankannya lakukan restart network dengan perintah # /etc/rc.d/netif restart && /etc/rc.d/routing restart Perintah commit restart to user network dan routing

15 digilib.uns.ac.id 32 Setelah berhasil maka akan muncul interface vhid yang dapat dilihat dengan perintah ifconfig maka diperoleh hasil Interface status server 1 interface status server 2 Dari gambar 4.6 dapat dilihat interface carp sertindak sebagai master dan pada server 2 carp interface bertindak sebagai backup Konfigurasi Database Server Aplikasi yang digunakan dalam membuat system redudansi database ini adalah mysql dan carp interface dimana konfigurasi pada carp seperti pada subbab sebelumnya carp interface di gunakan untuk failover database dan untuh sinkronisasi database menggunakan salah satu fasilitas yang ada pada mysql yairu mysql replikasi. Konfigurasi yang dilakukan adalah dengan menambahkan server id dan mengaktifkan log-bin pada file konfigurasi mysql yaitu my.cnf yang terletak pada folder /usr/locat dengan perintah # echo server-id = 1 >> /usr/local/my.cnf # echo log-bin >> /usr/local/my.cnf Konfigurasi mysql Nilai server id harus berbeda pada setiap server. Dengan mengaktifkan log-bin maka secara otomatis mysql akan membuat file baru

16 digilib.uns.ac.id 33 pada directory mysql pada freebsd defaultnya terletak di /var/db/mysql disitu akan muncul file log-bin dengan nama namadatabase-bin , sebagai contoh pada database db02 maka akan membuat file log-bin dengan nama db02-bin yang berisikan log query pada database db02. Log ini nantinya akan dibaca oleh database slave untuk melakukan replikasi. Untuk menjalankan relikasi hal yang harus dilakuakan yaitu 1. Membuat user yang nantinya digunakan untuk replikasi user tersebut diberi privileges replication langkah yang dilakaukan adalah dengan masuk ke mysql kemudian dengan perintah Perintah masuk kedalam mysql Kemudin masukkan password user root. Setelah masuk perintah untuk menambahkan user dan memberi privileges replication pada user trersebut adalah # mysql u root p Mysql > GRANT SELECT,RELOAD,SUPER,REPLICATION SLAVE ON *.* TO 'replika03'@'%' IDENTIFIED BY 'passw0rd'; Konfigurasi user replikasi Perintah tersebut berarti memberikan privileges SELECT, RELOAD, SUPER, dan REPLICATION SLAVE pada semua table di semua database kepada user replica 03 yang login darimanapu dengan password passw0rd. Jika user replica03 belum ada pada database maka secara otomatis akan dibuat 2. Mengubah master database yang semula dirinya sendiri kemudian diubah ke server yang lain yang bertindak sebagai master. Sebagai contoh db03 akan mengubah masternya menjadi db02. Artinya db03 sebagai slave dari db02. Sebelum merubahnya db03 harus tahu master status pada db02 terlebih dahulu. Untuk melihat master status pad db02 di gunan perintah Show master status pada mydql db02

17 digilib.uns.ac.id 34 master status db02 Setelah tahu file log-bin dan posisinya kemudin pada db03 dilakukan konfigurasi Mysql > CHANGE MASTER TO MASTER_HOST = 'db02', MASTER_USER = 'replika03', MASTER_PASSWORD = 'passw0rd', MASTER_LOG_FILE = 'mysqlbin ', MASTER_LOG_POS= ; Mysql > START SLAVE; konfigurasi slave mysql Setelah delesai dapat dilihat status slave pada db03 dengan perintah show slave status; pada msql slave status database db03 Dari gambar 4.9 dapat dilihat slave_io_state yang bernilai waiting for master to sent event artinya server db03 sudah siap menjadi slave tinggal menunggu update commit dari to user master yaitu db02.

18 digilib.uns.ac.id 35 Setelah konfigurasi slave pada db03 kemudian dilakukan ha yang sama pada server db02. Untuk memastikan replikasi yang dibuat sudah berhasil atau belum dilakukan dengan cara menambahkan data pada salh satu server dan kemudian dilihat pada server yang lainnya apakah ikut bertambah atau tidak. Percobaan dilakukan di kedua server database Pengujian dan Analisa Skema pengujian Pengujian yang dilakukan ada dua jenis pengujian yaitu pengujian terhadap availability atau ketersedian dan pengujian terhadap performa Pengujian terhadap availability dilakukan dengan cara mematikan salah satu komponen yang ada pada salah satu system dengan menggunakan topologi high availability seperti pada gambar 4.1 dengan hasil yang natinya didapat adalah apakah website masih bisa di akases atau tidak dan data yang pada databases dapat sinkron atau tidak Pengujian terhadap performa dilakukan dengan menggunakan server tester yang menggunakan aplikasi httperf yang berfungsi untuk mengirimkan request ke webserver. Pengunjian yang dilakukan untuk membandingkan performa antara satu server dengan dua server dengan topologi sebagai berikut: 1. Topologi 1 Pengujian yang dilakukan pada topologi pertama adalah dengan melakukan testing langsung kepada webserver 1 tanpa adanya loadbalancer, dengan topologi sebagai berikut TESTER WEB SERVER 1 Topologi testing 1

19 digilib.uns.ac.id Topologi 2 Pengujian pada topologi 2 dilakukan dengan cara melakukan testing langsung pada web serever 2 dengan topologi seperti pada gambar 4.26 TESTER WEB SERVER 2 Topologi testing 2 3. Topologi 3 Pada topologi 3 pengujian dilakukan dengan cara tester melakukan pengujian terhadap load balancer server yang menangani 2 buah web server di bawahnya dengan topologi sebagai berikut WEB SERVER 1 TESTER LOAD BALANCER Topologi testing 3 WEB SERVER 2 4. Topologi 4 Pada topologi 4 pengujian dilakukan dengan cara tester melakukan pengujian terhadap web server 1 yang sudah terhubung dengan file server dan database server. Topologi yang di ujikan adalah sbagai berikut

20 digilib.uns.ac.id 37 FILE SERVER DATABASE 01 TESTER WEB SERVER 1 VIRTUAL IP DATABASE 02 Topologi 4 5. Topologi 5 Pada topologi 5 pengujian dilakukan dengan cara tester melakukan pengujian terhadap web server 2 yang sudah terhubung dengan file server dan database server. Topologi yang di ujikan adalah sebagai berikut FILE SERVER DATABASE 01 TESTER WEB SERVER 2 VIRTUAL IP DATABASE 02 Topologi 5 6. Topologi 6 Pada topologi 6 pengujian diarahkan ke loadbalancer yang menggunakan 2 web server yang sudah terhubung dengan file server dan databases server ddengan topologi adalah sebagai berikut

21 digilib.uns.ac.id 38 LOAD BALANCER 01 WEB 01 VIRTUAL IP DATABASE 01 VIRTUAL IP TESTER DATABASE 02 LOAD BALANCER 02 WEB 02 Topologi 6 FILE SERVER Pengujian load balancer penulis melakakukan 3 kali pengujian 1 server dan 5 kali pengujian 2 server yang dilakukan dengan jeda waktu 1 jam antar pengujian, yang diasumsikan dengan jeda waktu tersebut server dapat kembali normal setelah diberikan beban yang berat. Parameter yang digunakan untuk melakukan pengujian adalah Troughput, Response Time, dan Error dengan mengirimkan request dengan rate 200, 400, 700, 1000, 1500, 2000, 2500, dan 3000 request per detik. Pengujian menggunakan perangkatlunak httperf. Web server. Pengujian dilakukan dengan perangkat lunak httperf. Perangkat lunak ini dapat menciptakan banyak request dan koneksi dalam satu waktu. Parameter yang digunakan pada pengujian menggunakan httperf adalah sebagai berikut: #httperf --server netmon.local --uri /index.php --num-conn rate timeout 10 Perintah pengujian performa Perintah di atas menginstruksikan httperf untuk menguji web server dengan alamat netmon.local/index.php. Perintah --num-conn menginstruksikan httperf untuk menyediakan request, perintah --rate 100 menetapkan httperf untuk membuat 100 request baru per detik, perintah-- timeout 10 mengatur waktu time out sebesar 10 detik, setiap permintaan yang tidak direspon dalam rentang waktu ini akan dianggap sebagai error.

22 digilib.uns.ac.id Parameter Throughput Parameter throughput pada penelitian ini mewakili sejumlah request yang dapat direspon oleh web server pada satu waktu. Parameter ini dihitung dalam satuan KB/second. Semakin besar nilai dari parameter ini, maka semakin baik pula kinerja dari web server tersebut. Hasil Uji Parameter Throughput rate Rata-rata Troughput/req Req/sec Topologi 1 Topologi 2 Topologi Rata-rata Tabel 4.1 menunjukkan perbandingan troughput antara webserver 01, webserver 02, dan kedua webserver dengan loadbalancer. Dari Tabel 4.1 tersebut dapat dibuat grafik sebagai berikut. Troughput Troughput(KB/s) RateRequest (req/s) Topologi 1 Topologi 2 Topologi 3 Grafik Perbandingan Troughput

23 digilib.uns.ac.id 40 Dari grafik pada gambar 4.32 menunjukakan trougput berbanding terbalik dengan jumlah request semakin banyak jumlah request yang di terima maka semakin kecil througput yang dapat ditangan oleh web server. Webserver1 dan Webserver2 memilik grafik troughput yang sama karena mempunyai resource yang sama pula. Berbeda dengan 2server yang menggunakan loadbalancer memiliki troughput yang lebih tinggi karena memiliki resource yang lebih besar yaitu gabungan dari webserver1 dan webserver2. Jika diratarata maka peningkatan troughput dari 1 server ke 2 server adalah sebesar 55 % Parameter Response Time Parameter Respose Time Parameter response time pada penelitian ini menggambarkan kecepatan web server dalam menanggapi request dari client. Parameter ini dihitung dalam satuan milisecond. Semakin kecil nilai dari parameter ini, maka semakin cepat sebuah web server dalam menanggapi request dari client. Hasil dari pengamatan parameter response time pada penelitian ini, seperti pada tabel 4.2 Hasil Uji Parameter Response Time rate Rata-rata Response Time/req Req/sec Topologi 1 Topologi 2 Topologi Rata-rata Tabel 4.2 menunjukkan perbandingan dari response time antara webserver 01, webserver 02, dan kedua webserver dengan loadbalancer yang dihasilkan pada penelitian ini. Dari data diatas dapat dibuat grafik sebagai berikut:

24 digilib.uns.ac.id 41 Response Time Response Time(ms) Rate Request (req/s) Topologi 1 Topologi 2 Topologi 3 Grafik Perbandingan Response Time Pada gambar 4.33 menunjukkan grafik perbandingan response time antara webserver 01, webserver 02, dan kedua webserver dengan loadbalancer. Dari grafik tersebut response time antara server1 dan server 2 memiliki nulai yang hampirsama dengan titik tercepat pada connection yang mempuyai rate di bawah 200req/s. Sedang yang menggunakan 2 server dengan loadbalancer mempunyai responstime tercepat sampai dengan rate 400 req/s. setelah titik tersebut server mulai dipaksa bekerja lebih, karena server tidak kuat dengan rate diatas 200 req/s maka dari situlah mulai terjadi antrian karena terjadi antrian maka responstime yang dihasilkan akan menjadi tinggi. Puncak responstime tertinggi pada 1 server yaitu antara rate 200 req/s sampai rate 400 req/s, sedangkan untuk yang 2 server adalah rentang 400 req/s sampai 700 req/s. pada titik puncak itu server mulai terjadi error pada saat menangani request. Semakin banyak rate yang diberikan maka semakin banyak pula error yang terjadi sehingga request yang direply sukses semakin turun karena itulah responsetime yang diberikan mulai mengecil karena semakin sedikit reply sukses yang di hasilkan. Jika dilihat responstime dengan rate lebihdari 700 request/second 1 server memiliki respons yang lebih baik daripada 2 server yang menggunakan load balancer. Akan tetapi jika commit dilihat to dengan user reply sukses yang dihasilkan 2

25 digilib.uns.ac.id 42 server dengan load balancer lebih banyak 2 kalilipat dibandingkan dengan menggunakan 1 server karena reply sukses yang dihasilkan besar itu mengakibatkan response time yang dihasilkan lebih besar Parameter Reply Sukses Parameter Reply sukses pada penelitian ini menggambarkan banyaknya reply sukses yang terjadi pada saat web server menanggapi request dari client. Semakin besar nilai dari parameter ini, maka semakin baik kinerja sebuah web server dalam menanggapi request dari client dan semakin besar nilai dari parameter ini maka semakin kecil reply error yang dihasilkan Hasil dari pengamatan parameter error pada penelitian ini, seperti pada tabel 4.3 Hasil Uji Parameter Reply sukses rate Reply sukses (req) Req/sec Topologi 1 Topologi 2 Topologi Rata-rata Tabel 4.3 menunjukkan perbandingan dari reply suskes antara webserver 01, webserver 02, dan kedua webserver dengan loadbalancer yang dihasilkan pada penelitian ini. Dari data diatas dapat dibuat grafik sebagai berikut:

26 digilib.uns.ac.id Reply sukses Reply (req) Rate Request (req/s) Topologi 1 Topologi 2 Topologi 3 Grafik Perbandingan reply suskes Dari grafik gambar 4.34 menunjukkan semakin banyak request rate yang diberikan ke webserver maka semakin kecil reply sukses yang diberikan web server. Dari request yang diberikan pada percobaan dengan rate yang berbeda, web server yang hanya dengan 1 server dapat mengembalikan sebua requs yang diberik sampai dengan rate 200 req/s sedangkan untuk webserver yang menggunakan loadbalancer 2 server dapat mereply semua request sampai dengan rate 400 req/s setelh batas tersebut mulai terjadi error pada sisi webserver karena tidak sanggup menangani request dengan kecepatan lebih dari batas tersebut diatas. Dari rata-rata pad percobaan dengan parameter reply sukses maka peningkatan reply sukses dari 1 server menjadi 2 server sebesar 60% Konsumsi Sumberdaya Pada subbab ini menjelaskan tentang resource yang digunakan saat dilakukan pengujian performa seperti CPU dan Memory. Penelitian yang dilakukan adalah membandingkan resource yang di konsumsi saat server menerima request dengan rate request yang berbeda. Ada dua nilai yang diambil yaitu CPU Load dan pertambahan memory yang digunakan. Pada percobaan terhadap topologi 1 sumberdaya yang dikonsumsi oleh Webserver 1 adalah seperti table berikut

27 digilib.uns.ac.id 44 Tabel penggunaan sumberdaya pada topologi 1 web server 01 Request CPU (%) Memory (Kb) Dari table diatas dapat di jelaskan bahwa webserver 01 ketika menangani request dengan rate 200 request per second dapat ditangani dengan mudah karena cpu yang dibutuhkan untuk menangani request tersebut belum sepenuhnya terpakai, yang terpakai hanya 73 % dari cpu yang dimiliki dan juga tidak memakan memory. Untuk rate request 400 sampai 300 req/s web server 01 kualahan untuk menangani request tersebut, hal itu dapat dilihat dari load cpu yang digunakan yaitu 100% hal tersebut dapat menyebabkan reqest yang diterima tidak semuanya dapat dibalas dengan sukses seperti yang di jelaskan di subbab sebelumnya. Sedangkan konsumsi untuk konsumsi memory web server tidak terlalu membutuhkan memory hal itu dapat dilihat dari penggunaan memory hanya sebesat 1924 Kb atau hamper 2 Mb saja. Percobaan yang dilakukan terhadap topologi 2 yaitu langsung kepada web server 02 diperoleh hasil sebagai berikut Tabel penggunaan sumberdaya pada topologi 2 web server 02 Request CPU (%) Memory (Kb) commit to user 1920

28 digilib.uns.ac.id 45 Pada topologi 2 atau percobaan terhadap webserver 02 sumberdaya yang dibutuhkan tidak jauh berbeda dengan web server 01 hal itukarena resource yang dimiliki, aplikasi yang digunakan, dan load yang diterima sama persis antar keduanya. Percobaan yang dilakukan pada topologi 3 yaitu dua server yang di load balance diperoleh hasil sebagai berikut Tabel penggunaan sumberdaya pada topologi 3 web server 01 web server 02 Load balancer Request CPU (%) Memory (Kb) CPU (%) Memory (Kb) CPU (%) Memory (Kb) Dari table 4.6 diperoleh hasil untuk semua percobaan dengan rate yang berbeda-beda load balancer masih kuat untuk menangani request yang datang kemudian di teruskan ke webserver maksimum sumberdaya yang dikonsumsi adalah 75 % dari sumberdaya yang ada yaitu pada rate 3000 req/s. load balancer tidak membutuhkan memory untuk melakukan pembagian request hal itu dapat dilihat dari data yang telah diperoleh untuk semua rate yang diterima pertambahan load memory pada server sebesar 0 Kb. Dari data tersebut berarti load balancer tersebut masih bisa menangani request dengan rate yang lebih besar lagi. Untuk sumberdaya CPU yang dikonsumsi web server pada hakikatnya sama dengan percobaan di topologi 1 maupun di topologi 2 satu server dapat menangani request dengan rate 200req/s tanpa ada masalah, sedangkan pada rate 400 req/s server mulai kualahan untuk menangani. Di topologi 3 ketika rate yang datang sebesar 200 req/s maka request tersebut akan dibagi ke kedua server dengan katalain 100 req/s menuju web server 1 dan 100 req/s menuju web server

29 digilib.uns.ac.id Dengan kata lain rate yang diterima oleh webserver adalah rate request yang diperoleh loadbalancer dibagi 2. Oleh sebab ituketikan rate pada loadbalancer sebesar 700 req/s web server baru mulai kualahan yang dibuktikan dengan load CPU yang digunakan sebesar 100%. Pada subbab ini dapat disimpulkan bahwa resource yang dimiliki dapat mempengaruhi performa server. Semakin besar resource yang dimiliki maka semakin besarpula performa yang dihasilkan. Untuk webserver dan load balancer tidahk terlalu membutuhkan resource memory yang besar tetapi tergantung pada resource CPU yang dimiliki Failover Failover bertujuan agar saat suatu system mengalami down maka system yang dijadikan sebagai backup dapat segera menggantikan posisi master yang down tadi dengan cepat. Pengujian yang dilakukan dengan menggunakan Topologi 6. Sistem failover pada penelitian ini terletak pada loadbalancer, ada 2 loadbalancer yang ada didalam system ini yaitu loadbalancer lb01 dan lb02 dengan master pada lb01 dan slave pada lb2. Dalam pengujianya penulis melakukan percobaan dengan membuat down salah satu server yaitu lb01 dan menganalisa apakah server lb02 dapat menggantikan fungsi master yang ada pada lb01 sebelumnya dan menganalisa bagaimana jika server lb01 up kembali apakah bisa langsung menjadi master kembali. Untuk mengeceknya dengan cara melakukan ping ke ip virtual yang dimiliki keduanya dan juga dengan melihat status yang interface pada server dengan perintah ifconfig. Disitu nanti bisa melihat sebagai apakah server tersebut berfungsi. Percobaan yang dilakukan adalah Mematikan server lb01 dengancara mematikan interfacenya. Pengujian dengan menjalankan ping dengan tujuan ip virtual yang ada di kedua server yaitu Sebelum percobaan dimulai cek status pada interface

30 digilib.uns.ac.id 47 Status loadbalancer lb01 awal Status loadbalancer lb02 awal Gambar 4.35 dan gambar 4.36 menunjukkan status sebelum dilakukan percobaan. Dimana lb01 sebagai master dan lb02 sebagai backup dengan ip virtual Kemudian dilakukan ping sambil mematikan interface lb01 dengan perintah ifconfig em0 down Status ping saat loadbalancer lb01 down

31 digilib.uns.ac.id 48 Status loadbalancer lb01 setelah loadbalancer lb01 down Status loadbalancer lb02 setelah loadbalancer lb01 down Pada gambar 4.38 menunjukkan status yang semula master menjadi INIT artiniya mati karena physical interfacenya down, sebangkan pada lb02 yang semula berstatus sebagai backup setelah lb01 mati maka status lb02 menjadi master untuk menggantikan lb01 seperti pada gambar Padasaat perpindahan terjadi down sesaat pasa ip virtualnya seperti yang terlihat pada gambar 4.37 yang terjadi request time out satukali pada proses ping. Dengan itu berarti failover berfungsi seperti yang di rencanakan. Setelah melakukan percobaan pemutusan kemudin dilakukan percobaan lagi dengan menghidupkan lagi lb01 yang di matikan pada percobaan sebelumnya dengan menggunakan perintah ifconfig em0 up ping setelah loadbalancer lb01 up

32 digilib.uns.ac.id 49 Stat us loadbalancer lb01 setelah loadbalancer lb01 up Status loadbalancer lb02 setelah loadbalancer lb01 up Pada percobaan ini pada saat lb 01 kembali up ip virtual yang semula berada pada lb02 secara langsung akan pindah kembali ke I lb01 kembali tanpa ada delay seperti yang terlihat pada gambar Redundansi database Pada redundansi database dituntut untuk mempunyai lebih dari 1 database yang dapat di akses. Topologi yang digunakan adalah topologi 6. Dalam penelitian ini penulis menggunakan 2 node atau databases. Di kedua node tersebut dapat digunakan bersamasama atau loadbalance atau bisa juga dengan bergantian failover. Pada penelitian kaliini penulis menggunakan kedua node tersebut secara bergantian atau failover. Dengan prinsip sama dengan failover pada load balancing server pada subbab sebelumnya jika salah satu database mati maka akan pindah ke database yang lainya tntusaja dipastikan bahwa data antar kedua database itu sama. Dalam penelitian ini penulis memneri hostname pada kedua database itu sebagi db02.netmon.local dan db03.netmon.local sedangkan db01.netmon.local bertindak sebagai server file sharing.

33 digilib.uns.ac.id 50 Pengunjian yang dilakukan dengan mematikan salah satu database dan kemudian apakah bisa langsung pindah ke node yang lainya. Kemudian jika saat salah satu node mati dan node yang lainya masih melakukan transaksi data baik penambahan atau pengurangan data, akankah node yang mati tadi ketika menyala kembali bisa melakukan sinkronisasi data pada node yang menyala. Pengujian dilakukan dengan cara mematikan interface pada salahsatu node yaitu db02 dan apakah db03 dapat menggantikan peran db02. Di kedua database ini terdapat ip yang dimiliki keduanya dan itu dijadikan sebagai alamat database untuk aplikasi web. Status database db02 sebelum down Status database db03 sebelum database db02 down Konsep redudansi database pada penelitian ini menggunakan 2 metode yaitu carp interface sebagi failover dan mysql replikasi sebagai pensinkron data. Dimana replikasi dilakukan 2 arah, db02 mereplikasi db03 dan db03 mereplikasi db02. Prinsip kerjanya jika db02 sebagai master maka db02 akan mengirim kopian query kepada db03 dan jika db03 sebagai master maka akan mengirimkan kopian querynya ke db02. Mysql replikasi adalah salah satu fiture yang ada pada mysql database konfigurasi yang dibutuhkan adalah mengaktivekan log-bin dan memberikan server id yang berbeda commit pada to user setiap server database. Konfigurasi

34 digilib.uns.ac.id 51 selanjutnya adalah membuat user yang digunakan untuk replikasi dengan privilege replication. Server database yang bertindah sebagai slave dikonfigurasi mengikuti log-bin pada master. Perbandingan data sebelum database db02 down Pada gambar 4.45 menunjukkan data yang berada pada kedua server sama sebelum salah satu database dimatikan. Kemudian dilakukan percobaab dengan mematikan salah satu database degan cara menonaktifkan interfacenya seperti yang dilakukan saat melakukan percobaan failover. Setelah salah satu database mati kemudian lakukan input data ke database yang masih menyala. Saat salah satu database mati maka secara otomatis database yang lainya akan langsung menggantikan posisi master seperti failover pada loadbalancer. commit Saat database to user db02 down

35 digilib.uns.ac.id 52 input data saat database db02 down Kemudian setelah itu diaktifkan kembali db02 yang down tadi dengan mengaaktifkan kembali interfacenya. Setelah aktif lihat pada status interface di kedua database. Status database db02 stelah database db02 up Status database db02 setelah database db02 up

36 digilib.uns.ac.id 53 Pada gambar diatas menunjukan saat db02 kembali up db03 tetap sebagai master hal ini diakrenakan pada db02 yang mempunyai nilai advskew 0 diberikan demotion pada carp interface sebanyak 100 agar nilai keduanya sama. Jadi master akan berpindah jika master itu mati jika dan jika master tersebut tidak mati maka status master tidak akan berpindahhal ini berfungsi untuk memberikan waktu agar database yang mati tadi bisa bisa melakukan sinkronisasi data sebelum dia diakses langsung oleh webserver. Perintah untuk menurunkan prioritas sebagai master yaitu # sysctl net.inet.carp.demotion= -100 Perintah penurunan nilai demotion Yang hasilnya dapat dilihat dengan perintah sysctl net.inet.carp Status carp database db02 Status carp database db03

37 digilib.uns.ac.id 54 Perbandingan data setelah database db02 up kembali Secara default nilai dari demotion adalah 0. Dengan konfigurasi tersebut dapat dikatakan keduanya sebagai master karena memiliki proiritas yang sama tergantung server mana yang up terlebih dahulu maka dia akan menjadi master. Pada gambar 4.53 menunjukkan perbandingan data setelah db02 kembali up. Saat db02 up maka secara otomatis akan membaca log-bin db03 dan mulai melakukan sinkronisasi data Keseluruhan sistem Pada pengujian keseluruhan system yang dilakukan adalah hampirsama dengan pengujian pengujian yang sudah dilakukan pada subbab sebelumnya. Pada pengujian kaliini penulis sudah menggunakan domain untuk pengaksesan webserver dimana semua system yang dibuat ini ip yang dapat diakses oleh semua orang adalah ip yaitu ip virtual dari loadbalancer ip tersebut yang dimasukkan ke DNS dan di berikan domain netmon.local doman netmon.local adalah alamat website yang di akses oleh semua orang. Alur ketika ada seseorang yang melakukan request ke website adalah pertama mereka melakukan request terhadap domain netmon.local melalui web browser dengan bantuan DNS domain netmon.local diterjemahkan kedalam sebuah ip yaitu ip ip tersebeut merupakan ip virtual yang ada pada loadbalancer, selanjutnya loadbalancer yang bertindak sebagai master dari ip akan meneruskan request yang diberikan oleh pengunjung ke dalam server farm dalam hal ini commit server to farm user berisikan 2 buah webserver yaitu

38 digilib.uns.ac.id 55 web01 dan web02 mengan menggunakan sebuah algoritma load balancer membagi reques yang datang kemudian server farm yang telah ditunjuk untuk menangani request yang diberikan locadbalancer merespon dengan menyediakan halaman yang diinginkan oleh pengunjung yang diambilkan dari database dimana database yang bertindak sebagain master yang akan merespon permintaan webserver setelah mendapatkan respon dari database kemudian webserver menjawab permintaan pengunjung dalam bentuk html yang kemudian dapat dibaca oleh web browser. Ada beberapa algoritma yang bisa dilakukan oleh loadbalancer dalam halini Haproxy. Dalam Haproxy algoritma yang dapat digunakan yaitu round robin, static round robin, least connection, source, URI, dan URL Parameter. Loadbalancer merupakan salah satu yang dapat mendukung High Availability karena dengan adanya load balancer ketika salah satu web server down maka rekuest yang harusnya ditangani webserver tersebut akan di alihkan ke server farm yang lainya, dan ketika server tersebut up kembali maka loadbalancer secara otomatis akan memberikan beban seperti yang sebelumnya. Jika ingin menambahkan webserver yang baru tinggal dimasukkan kedalam list backend di file konfigurasi haproxy maka setelah direstart service haproxy otomatis langsung menjadi anggota server farm. Load balancer bertugas membagi request ke dalam server farm bagaimana jika loadbalancer servernya mati? Dari situ maka digunakan metode failover di mana dibuat 2 load balancer dengan konfigurasi yang sama yang nantinya salah satu akan menjadi backup ketika salah satunya mati. Sekarang jarang sekali website yang menggunakan web static. Hampir semua website sekarang ini menggunakan database untuk mengimpan data data website oleh karena itu databases server merupaka salahsatu komponen penting yang ada pada system ini. Untuk menunjang High Availability database harus mempunyai backup cadangan yang digunakan untuk menggantikan databases yang asli bila terjadi masalah. Sudah pasti kalau database yang paling penting adalah data yang ada didalamnya. Sebagai database backup dituntut untuk mempunyai isi data commit yang sama to user persis dengan databases yang

39 digilib.uns.ac.id 56 sesungguhnya. High Availability menuntut database agar saat databases utama fail atau gagal maka secara otomatis akan berpindah menuju database backup tampa merubah suatu konfigurasi apapun pada sisi clientnya dalam hal ini webserver. Untuk membuat system tersebut ada banyak cara untuk mengimplementasikannya salah satunya dengan menggunakan ip virtual pada beberapa database sebagai frontendnya kemudian antar database melakukan syncronisasi data dalam penelitian ini menggunakan mysql replication sebagai penyinkron database. Dari pengujian performa yang dilakukake seluruh system menggunakan parameter Troughput didapatkan data sebagai berikut: Hasil Uji Parameter Throughput keseluruhan sistem rate Rata-rata Troughput/req Req/sec Topologi 4 Topologi 5 Topologi Rata-rata Berdasarkan data dari Tabel 4.7 dapat dibuat grafik sebagai berikut Troughput Troughput(KB/s ) RateRequest (req/s) Topologi 4 Topologi 5 Topologi 6 Grafik Perbandingan throughput keseluruhan sistem

40 digilib.uns.ac.id 57 Dari data tersebut kecenderungan troughput terhadap rate request adalah semakin tinggi rate request yang diberikan maka semakin kecil troughput yang dihasilkan. Peningkatan Throughput dari 1 server menjadi dua server adalah adalah sebesar 30 % di bandingkan dengan percobaan pada subbab sebelumya pertambahan troughput di keseluruhan system lebih kecil, karena di seluruh system ini sudah termasuk troughput database juga jadi koneksi dari ke webserver sangat mempengarusi troughput keseluruhan system. Pengujian performa keseluruhan system menggunakan parameter Responstime dadapatkan data sebagai berikut: Hasil Uji Parameter Response Time keseluruhan sistem rate Rata-rata Response Time/req Req/sec Topologi 4 Topologi 5 Topologi Rata-rata Dati data pada yang dihasilkan pada parameter response time seperti pad table 4.8, maka dapat dibuat grafik sebagai berikut Response Time Response Time(ms) Rate Request (req/s) Topologi 4 Topologi 5 Topologi 6 Grafik Perbandingan response time keseluruhan sistem

41 digilib.uns.ac.id 58 Pada parameter resposntime semakin kecil response time suatu system maka semakin bagus performa system tersebu. Dari hasil pengambilan data pada percobaan ini didapatkan semakin besar rate yang diberikan maka semakin cepat pula responstime yang diberikan. Hal itu terjadi karena semakin besar rate request yang diberikan maka semakin sedikit request yang dapat dijawab oleh system tersebut. Pengujian performa yang ketiga adalah dengan menggunakan parameter reply sukses data yang didapatkan adalah sebagai berikut: Hasil Uji Parameter Response Time keseluruhan sistem rate Reply sukses (req) Req/sec Topologi 4 Topologi 5 Topologi Rata-rata Berdasarkan data pada table 4.9 dapat diperoleh grafik sebagai berikut: Reply sukses Reply Rate Request (reqs) Topologi 4 Topologi 5 Topologi 6 Grafik Perbandingan throughput keseluruhan sistem Diliahat dari grafik dari pada gambar 4.56 peningkatan jumlah reply sukses yang di hasilkan mencapai 100% hal ini dikarenakan maksimal conection yang diperbolehkan adalah sebesar 100. Jadi jika yang digunakan pada load

42 digilib.uns.ac.id 59 balancer 2 server makaa maksimal yang dapat di terima database adalah 200. Peningkatan reply sukses pada percobaan ini bisa dampai 2 kali lipat karena angka maksimal request yang dapat ditangani oleh database masih lebih kecil dibandingkan dengan request yang dapat di tangani oleh web server. Jadi pada percobaan ini keberhasilan reply yang dapat diberikan kepada pengakses tergantung pada performa dari database