BAB III ANALISA KEBUTUHAN DAN PERANCANGAN SISTEM

perpustakaan.uns.ac.id

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 3.1.1

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

Processor Type

: Intel(R) Xeon(R) CPU E7-4870 @ 2.40 GHz

VMware version

: ISXi-5.5.0-1331820-standard

Memory

: 130921.30 MB

Storage

: 1630 GB

2. Spesifikasi virtual mechine CPU

: 1 vCPU @ 2.393 GHz

Memory

: 2048 MB

Storage

: 300 GB Thin Provision

Network Adapter

: 1 x E1000 1GB/s

commit to user

18

19 digilib.uns.ac.id


3.1.2

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 1.6.2 3. 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 commit to user



-

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

commit to user Pembuatan laporan dipergunakan sebagai dokumentasi penelitian.



Perancangan Sistem Berdasarkan pengambilan data dan mencari kebutuhan informasi maka perancangan High Availability server sebagai berikut:

FILE SERVER

WEB 01 LOAD BALANCER 01

DATABASE 01

INTERNET

VIRTUAL IP VIRTUAL IP

LOAD BALANCER 02

DATABASE 02 WEB 02

Rancangan High Availability Dari gambar 3.2 diatas rancangan High Availability Server dibagi menjadi 3 tahap yaitu: 3.3.1

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 daricommit satu buah to server user agar dapat menggantikan fungsi



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 lagi. to user commit



3.3.2

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.

commit to user



3.3.3

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

commit to user


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: WEB 01 10.10.20.103

LOAD BALANCER 01 10.10.20.101

VIRTUAL IP 10.10.20.110 DATABASE 01 10.10.20.108

INTERNET

VIRTUAL IP 10.10.20.100 DATABASE 02 10.10.20.109

LOAD BALANCER 02 10.10.20.102

WEB 02 10.10.20.104

FILE SERVER 10.10.20.107

Skema High Availability Pada Gambar 4.1 merupakan gabungan dari loadbalancer, failover, dan replikasi dan redundansi database LOAD BALANCER 02 10.10.20.100 10.10.20.102

INTERNET switch

LOAD BALANCER 01 10.10.20.100 10.10.20.101

Router gateway 10.10.20.1

WEB 01 10.10.20.103

WEB 02 10.10.20.104

FILE SERVER 10.10.20.107

DATABASE 01 10.10.20.110 10.10.20.108

DATABASE 02 10.10.20.110 10.10.20.109

commit to user Topologi fisik Jaringan 25



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 1.4.25 server Hardware

FreeBSD 10.0

Loadbalancer Server

CARP

Nginx 1.6.2

MySQL-Server 5.6

MySQL Replication

Database Server

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 http://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.0/FreeBSD-10.0RELEASE-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.

commit to user



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.

commit to user



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 1.6.2 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 1.4.25 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.

commit to user



Konfigurasi Aplikasi Server 4.3.1

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

commit to user php info



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 4.10

Tampilan web server 4.3.2

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

commit to user



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 10.10.20.101 netmask 255.255.255.128" ifconfig_em0_alias0="vhid 1 pass rahasia alias 10.10.20.100/24"

Konfigurasi CARP loadbalancer 1 Kemudian untuk konfigurasi pada server 2 adalah sebagai berikut hostname="lb02.netmon.local" ifconfig_em0="inet 10.10.20.102 netmask 255.255.255.128" ifconfig_em0_alias0="vhid 1 advskew 100 pass rahasia alias 10.10.20.100/24"

Konfigurasi CARP loadbalancer 2 Pada konfigurasi diatas dapat dilihat bahwa server 1 mempunyai ip management 10.10.20.101 dan server 2 mempunyai ip management 10.10.20.102 dengan keduanya mempunyai satubuah ip yang sama yaitu 10.10.20.100 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

commit to user Perintah restart network dan routing



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

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 commit to user mengaktifkan log-bin maka secara otomatis mysql akan membuat file baru



pada directory mysql pada freebsd defaultnya terletak di /var/db/mysql disitu akan muncul file log-bin dengan nama namadatabase-bin.000001, sebagai contoh pada database db02 maka akan membuat file log-bin dengan nama db02-bin.000001 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 # mysql –u root –p

Perintah masuk kedalam mysql Kemudin masukkan password user root. Setelah masuk perintah untuk menambahkan user dan memberi privileges replication pada user trersebut adalah 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

commit to user



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.000012', MASTER_LOG_POS=1935579; 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 commitdari to user tinggal menunggu update master yaitu db02.



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 4.4.1 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 commit to user



2. Topologi 2 Pengujian pada topologi 2 dilakukan dengan cara melakukan testing langsung pada web serever 2 dengan topologi seperti pada gambar 4.26

WEB SERVER 2

TESTER

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

LOAD BALANCER TESTER WEB SERVER 2

Topologi testing 3

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

commit to user



FILE SERVER DATABASE 01

TESTER

VIRTUAL IP

WEB SERVER 1 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

VIRTUAL IP

WEB SERVER 2 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

commit to user



WEB 01

VIRTUAL IP

LOAD BALANCER 01

DATABASE 01

VIRTUAL IP TESTER

DATABASE 02 LOAD BALANCER 02 WEB 02

FILE SERVER

Topologi 6 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 10000 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 10000 -rate 100 --timeout 10 Perintah pengujian performa Perintah di atas menginstruksikan httperf untuk menguji web server dengan

alamat

netmon.local/index.php.

Perintah

--num-conn

10000

menginstruksikan httperf untuk menyediakan 10000 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.

commit to user



4.4.2 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 Req/sec 200 400 700 1000 1500 2000 2500 3000 Rata-rata

Rata-rata Troughput/req Topologi 1 84.591 60.350 32.091 21.552 13.352 9.144 6.586 5.305 29.121

Topologi 2 84.716 59.718 32.946 21.392 12.953 8.819 6.319 5.128 28.999

Topologi 3 84.637 84.620 68.749 46.804 29.022 21.125 15.815 11.223 45.249

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 90.000

Troughput(KB/s)

80.000 70.000 60.000 50.000 40.000 30.000 20.000 10.000 0.000 200

400 Topologi 1

700

1000

1500

2000

2500

RateRequest (req/s) Topologi 2

Topologi 3

Grafik Perbandingan Troughput commit to user

3000



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 %. 4.4.3 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 Req/sec 200 400 700 1000 1500 2000 2500 3000 Rata-rata

Rata-rata Response Time/req Topologi 1 0.021 1.210 0.417 0.211 0.098 0.058 0.041 0.030 0.261

Topologi 2 0.021 1.212 0.410 0.207 0.097 0.057 0.040 0.030 0.259

Topologi 3 0.023 0.011 0.757 0.393 0.182 0.106 0.078 0.059 0.201

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:

commit to user



Response Time Response Time(ms)

1.400 1.200 1.000

0.800 0.600 0.400 0.200 0.000 200

400

Topologi 1

700

1000

1500

2000

2500

Rate Request (req/s)

Topologi 2

3000

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 jikacommit dilihattodengan user reply sukses yang dihasilkan 2



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

4.4.4 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 Req/sec 200 400 700 1000 1500 2000 2500 3000 Rata-rata

Reply sukses (req) Topologi 1 10000.0 7286.0 3909.3 2651.3 1662.7 1146.7 835.0 675.7 3520.8

Topologi 2 10000.0 7187.0 4048.0 2613.0 1645.0 1124.0 845.0 659.0 3515.1

Topologi 3 10000.0 10000.0 8478.3 5864.7 3738.0 2772.0 2134.7 1776.7 5595.5

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:

commit to user



Reply sukses 12000.0

Reply (req)

10000.0 8000.0 6000.0 4000.0 2000.0 0.0 200

400 Topologi 1

700

1000

1500

2000

Rate Request (req/s) Topologi 2

2500

3000

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 10000 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%.

4.4.5 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 commit to user



Tabel penggunaan sumberdaya pada topologi 1 Request 200 400 700 1000 1500 2000 2500 3000

web server 01 CPU (%) Memory (Kb) 73.00 0 100.00 1924 100.00 1924 100.00 1924 100.00 1924 100.00 1924 100.00 1924 100.00 1924

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 Request 200 400 700 1000 1500 2000 2500 3000

web server 02 CPU (%) Memory (Kb) 74.00 0 100.00 1920 100.00 1920 100.00 1920 100.00 1920 100.00 1920 100.00 1920 commit 100.00to user 1920



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 Request CPU Memory (%) (Kb) 200 45.00 0 400 80.00 0 700 100.00 1924 1000 100.00 1924 1500 100.00 1924 2000 100.00 1924 2500 100.00 1924 3000 100.00 0

web server 02 CPU Memory (%) (Kb) 40.00 0 75.00 0 100.00 1920 100.00 1920 100.00 1920 100.00 942 100.00 0 100.00 0

Load balancer CPU Memory (%) (Kb) 30.00 0 50.00 0 65.00 0 65.00 0 60.00 0 65.00 0 65.00 0 75.00 0

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 commit to user dengan katalain 100 req/s menuju web server 1 dan 100 req/s menuju web server



2. 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 4.4.6 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 10.10.20.100. Sebelum percobaan dimulai cek status pada interface

commit to user



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 10.10.20.100. Kemudian dilakukan ping sambil mematikan interface lb01 dengan perintah ifconfig em0 down

Status ping saat loadbalancer lb01 down

commit to user



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 4.39. 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 commit to user



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

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

commit to user



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 commitpada to user memberikan server id yang berbeda setiap server database. Konfigurasi



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.

Saat database commit to user db02 down



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

commit to user Status database db02 setelah database db02 up



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

commit to user



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.

4.4.8 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 10.10.20.100 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 10.10.20.100 ip tersebeut merupakan ip virtual yang ada pada loadbalancer, selanjutnya loadbalancer yang bertindak sebagai master dari ip 10.10.20.100 akan meneruskan request yang diberikan oleh pengunjung ke commit user berisikan 2 buah webserver yaitu dalam server farm dalam hal ini servertofarm



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 to userpersis dengan databases yang untuk mempunyai isi data commit yang sama



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 Rata-rata Troughput/req Topologi 4 Topologi 5 Topologi 6 0.779 0.787 0.956 0.666 0.677 0.826 0.553 0.553 0.663 0.467 0.467 0.570 0.374 0.375 0.461 0.256 0.269 0.385 0.189 0.201 0.329 0.150 0.164 0.286 0.429 0.436 0.560

rate Req/sec 200 400 700 1000 1500 2000 2500 3000 Rata-rata

Berdasarkan data dari Tabel 4.7 dapat dibuat grafik sebagai berikut

Troughput 1.200

Troughput(KB/s )

1.000 0.800

0.600 0.400 0.200 0.000 200

400 Topologi 4

700

1000

1500

2000

RateRequest (req/s) Topologi 5

2500

3000

Topologi 6

commit to user Grafik Perbandingan throughput keseluruhan sistem



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 Req/sec 200 400 700 1000 1500 2000 2500 3000 Rata-rata

Rata-rata Response Time/req Topologi 4 Topologi 5 Topologi 6 0.332 0.349 0.741 0.151 0.159 0.325 0.085 0.084 0.172 0.057 0.059 0.116 0.051 0.060 0.081 0.155 0.126 0.064 0.140 0.124 0.058 0.132 0.116 0.061 0.138 0.135 0.202

Dati data pada yang dihasilkan pada parameter response time seperti pad table 4.8, maka dapat dibuat grafik sebagai berikut

Response Time 0.800

Response Time(ms)

0.600 0.400 0.200 0.000 200

400

Topologi 4

700

1000

1500

2000

2500

Rate Request (req/s)

Topologi 5

3000

Topologi 6

commit to user Grafik Perbandingan response time keseluruhan sistem



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 Req/sec 200 400 700 1000 1500 2000 2500 3000 Rata-rata

Reply sukses (req) Topologi 4 Topologi 5 Topologi 6 105.33 110.67 230.00 93.00 100.00 214.00 92.67 92.67 191.33 87.33 87.33 194.00 86.67 90.67 195.00 91.67 93.00 196.67 94.00 96.00 195.00 93.00 97.33 194.67 92.96 95.96 201.33

Berdasarkan data pada table 4.9 dapat diperoleh grafik sebagai berikut:

Reply sukses 250.00

Reply

200.00 150.00 100.00 50.00 0.00 200

400 Topologi 4

700

1000

1500

2000

Rate Request (reqs) Topologi 5

2500

3000

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 commit to user yang diperbolehkan adalah sebesar 100. Jadi jika yang digunakan pada load



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

commit to user

BAB III ANALISA KEBUTUHAN DAN PERANCANGAN SISTEM

Recommend Documents