Skrip Si

ANALISIS KINERJA DRBD DAN PACEMAKER

PADA HIGH AVAILABILITY CLUSTER

SEBAGAI SISTEM DISASTER RECOVERY

SKRIPSI

Diajukan Untuk Memenuhi Salah Satu Syarat Guna Memperoleh Gelar

Diploma Empat (D-4/S1 Terapan) Pada Politeknik Negeri Ujung Pandang

OLEH

NOVIANTO PADAUNAN

(42511040)

PROGRAM STUDI TEKNIK KOMPUTER DAN JARINGAN

JURUSAN TEKNIK ELEKTRO

POLITEKNIK NEGERI UJUNG PANDANG

MAKASSAR

2015

ii

LEMBAR PENGESAHAN PEMBIMBING

Skripsi dengan judul “Analisis Kinerja DRBD dan Pacemaker pada

High Availability Cluster sebagai Sistem Disaster Recovery” oleh Novianto

Padaunan (42511040), telah diterima dan disahkan sebagai salah satu syarat

untuk memperoleh gelar Diploma IV (D-4/S1 Terapan) pada Program Studi

Teknik Komputer dan Jaringan Jurusan Teknik Elektro Politeknik Negeri Ujung

Pandang.

Makassar, Juli 2015

Mengesahkan,

Pembimbing I Pembimbing II

Irawan, S.ST., M.T. .

NIP. 19790620 200312 1 001

Rini Nur, S.T., M.T. .

NIP. 19730713 200912 2 001

Mengetahui ,

Ketua Jurusan Teknik Elektro

Politeknik Negeri Ujung Pandang

KPS Teknik Komputer dan Jaringan

Politeknik Negeri Ujung Pandang

Dr. Ir. Hafsah Nirwana, M.T.

NIP. 19640405 199003 2 002

Muh. Fajri Raharjo, S.T., M.T.

NIP. 19700521 199961 1 001

iii

LEMBAR PERSETUJUAN TIM PENGUJI

Pada hari ini Selasa tanggal 18 Agustus 2015, Panitia Ujian Sidang

Skripsi, telah menerima dengan baik hasil Skripsi oleh mahasiswa : Novianto

Padaunan (42511040) dengan judul “Analisis Kinerja DRBD dan Pacemaker

pada High Availability Cluster Sebagai Sistem Disaster Recovery”

Makassar, 18 Agustus 2015

Panitia Ujian Sidang Skripsi:

1. Andi Wawan Indrawan, S.ST., M.Eng Ketua ( )

2. Irmawati, S.T., M.T Sekretaris ( )

3. Muh. Fajri Raharjo, S.T., M.T Anggota ( )

4. Eddy Tungadi, S.T., M.T Anggota ( )

5. Irawan, S.ST., M.T Pembimbing I ( )

6. Rini Nur, S.T., M.T Pembimbing II ( )

iv

KATA PENGANTAR

Puji syukur penulis panjatkan kehadirat Tuhan Yang Maha Esa karena

berkat rahmat dan hidayah-Nya, juga segala petunjuk dan kemudahan sehingga

penulis dapat menyelesaikan penulisan Skripsi yang membahas mengenai

“Analisis Kinerja DRBD dan Pacemaker pada High Availability Cluster

sebagai Sistem Disaster Recovery” dengan baik dan lancar.

Penyusunan Skripsi ini bukanlah hasil kerja penulis sendiri, melainkan juga

berkat bimbingan dan dukungan dari berbagai pihak, oleh karena itu melalui

kesempatan ini penulis ingin menyampaikan terima kasih dan penghargaan yang

setinggi-tingginya kepada:

1. Kedua orang tua penulis yakni Yohannes Daun Pute, S.E dan Maria

karena merekalah yang membesarkan penulis dari kecil hingga sekarang

dengan kasih sayang yang tulus dan ikhlas sehingga rasa terima kasih ini

tidaklah cukup sebagai wujud penghargaan kepada mereka.

2. Ucapan terima kasih juga diucapkan kepada semua anggota keluarga

terkasih atas doa dan dukungannya selama ini.

3. Bapak Dr. Ir. Hamzah Yusuf, M.S selaku Direktur Politeknik Negeri

Ujung Pandang .

4. Ibu Dr. Ir. Hafsah Nirwana, M.T selaku Ketua Jurusan Teknik Elektro

Politeknik Negeri Ujung Pandang.

5. Bapak Muh. Fajri Raharjo, S.T., M.T selaku Ketua Program Studi D-4

Teknik Komputer dan Jaringan Politeknik Negeri Ujung Pandang.

v

6. Dosen Pembimbing Skripsi, baik Pembimbing I Bapak Irawan, S.ST.,

M.T dan Pembimbing II Ibu Rini Nur, S.T., M.T.

7. Para dosen pengajar diantaranya Bapak Irfan Syamsuddin, S.T.,

M.Com.ISM., Ph.D, Bapak Andi Wawan Indrawan, S.ST., M.Eng,

Bapak Eddy Tungadi, S.T., M.T, Ibu Irmawati, S.T., M.T dan seluruh

dosen pada Program Studi Teknik Komputer dan Jaringan serta seluruh

staff dan tekniksi Jurusan Teknik Elektro.

8. Teman-teman kelas penulis diantaranya Ilham, Dio, Irfan, Rio, Dimas,

Ais, Idha, Arum, Gufran, Regar, Ratih, dan yang lainnya yang tidak

dapat penulis sebutkan satu persatu.

9. Seluruh teman-teman D-4 TKJ Kelas 4B yang selalu memberi bantuan

dan dukungannya selama penulis menyelesaikan Skripsi ini.

10. Dan kepada semua pihak yang telah membantu penulis secara langsung

maupun tidak langsung yang tidak dapat penulis sebutkan satu persatu.

Penulis menyadari masih terdapat banyak kekurangan dalam penulisan

Skripsi ini. Oleh karena itu penulis mengharapkan kritik dan saran yang

membangun agar Skripsi ini lebih baik lagi. Akhir kata, penulis mengucapkan

banyak terima kasih semoga Skripsi ini dapat bermanfaat bagi semua pihak.

Makassar, Agustus 2015

Penulis

vi

ABSTRAK

Data dan layanan server telah menjadi dua hal yang sangat penting dalam

mendukung proses kegiatan sebuah instansi. Namun tidak hanya peranannya saja

yang meningkat tetapi tingkat ancaman yang dapat menggangu dan merusak data

serta layanan server yang dimiliki suatu instansi pun juga semakin berkembang.

Menurut survey yang dilakukan Continuity Central Archive pada tahun 2011

diperoleh hasil bahwa 54% perusahaan di Eropa mengalami kerugian besar karena

kehilangan data dan kerusakan layanan pada server yang disebabkan oleh

beberapa hal yaitu kerusakan perangkat keras, data corruption dan kehilangan

daya listrik. Oleh karena itu sistem disaster recovery yang memiliki tingkat

ketersediaan yang tinggi sangat dibutuhkan oleh sebuah instansi. Pada penelitian

ini metode yang digunakan untuk membuat sistem disaster recovery adalah high

availability cluster. Dengan menggabungkan aplikasi Distributed Replicated

Blocks Device (DRBD) yang akan melakukan fungsi mirroring data dan aplikasi

Pacemaker yang akan melakukan proses fail over layanan server secara otomatis,

maka akan dapat diperoleh sebuah sistem yang memiliki tingkat ketersediaan

yang tinggi. Pengujian yang dilakukan pada penelitian ini meliputi pengujian

pengaruh DRBD dan Pacemaker terhadap kualitas sistem, pengaruh sistem

terhadap layanan server, dan pengujian nilai Availability dari sistem berdasarkan

beberapa skenario kegagalan sistem yang telah ditentukan. Nilai Availability rata-

rata yang diperoleh dari sistem yang digunakan dalam penelitian ini untuk

skenario kegagalan sistem karena Connection Lost adalah sebesar 99,0409%, dan

untuk skenario Power Lost adalah sebesar 98,8358% serta untuk skenario DDOS

Attack adalah sebesar 98,7343%.

Kata Kunci: Disaster Recovery, High Availability, DRBD, Pacemaker.

vii

ABSTRACT

Data and server services have been the two things that are very important in

supporting the activities of a process instance. But not only the role that increased

but the level of threat that can penetrate and damage to your data and server

service owned by a number of agencies is also growing. According to survey done

Continuity Central Archive in 2011 showed that 54% of companies in Europe

suffered heavy losses due to the loss of data and damage to the service on the

server that is caused by a few things, namely damage to the hard disk, data

corruption and loss of electrical power. Therefore the system of disaster recovery

that have very high availability required by an agency. On the research methods

used to make the system of disaster recovery is a high availability cluster. By

combining applications Distributed Replicated Blocks Device (DRBD) which will

perform the function of mirroring data and application of Pacemaker that will do

the process fail over the server service automatically, it will be available a system

that has a high availability. Testing done on this research includes testing the

influence of DRBD and Pacemaker on quality systems, the influence of the

system of the service server, and testing the value of Availability of systems based

on multiple scenarios of system failure. Average Availability values obtained

from the systems used in this study for system failure scenario because the

Connection was Lost of 99,9970%, and for the screenplay of Lost Power is

99,9970% as well as for DDOS Attack scenario is 99,9970%.

Keywords: Disaster Recovery, High Availability, DRBD, Pacemaker.

viii

DAFTAR ISI

LEMBAR JUDUL ........................................................................................... i

LEMBAR PENGESAHAN PEMBIMBING .................................................... ii

LEMBAR PERSETUJUAN TIM PENGUJI .................................................... iii

KATA PENGANTAR ..................................................................................... iv

ABSTRAK ...................................................................................................... vi

DAFTAR ISI ................................................................................................... viii

DAFTAR GAMBAR ....................................................................................... xi

DAFTAR TABEL ........................................................................................... xiii

BAB I PENDAHULUAN ............................................................................... 1

A. Latar Belakang .................................................................................... 1

B. Rumusan Masalah ............................................................................... 3

C. Tujuan Penelitian ................................................................................ 4

D. Manfaat Penelitian .............................................................................. 4

BAB II TINJAUAN PUSTAKA .................................................................... 5

A. Disaster Recovery ............................................................................... 5

1. Definisi Disaster Recovery ......................................................... 5

2. Tujuh Tier Disaster Recovery Strategies .................................... 5

B. Clustering Computer ........................................................................... 12

1. Jenis-Jenis Clustering Computer ................................................ 12

2. Keuntungan Clustering Computer .............................................. 13

C. High Availability ................................................................................. 14

1. Continuous Availability .............................................................. 14

2. Fail Over Availability ................................................................. 15

D. Redundant Array Independent Disk (RAID) ........................................ 16

E. Distributed Replicated Block Device (DRBD) ..................................... 18

F. Pacemaker .......................................................................................... 20

G. Parameter Kualitas Kinerja Sistem ...................................................... 22

1. Latency ...................................................................................... 22

2. Throughput ................................................................................ 23

ix

3. Round Time Trip (RTT) .............................................................. 24

4. Downtime ................................................................................... 24

5. Availability ................................................................................. 24

H. Temuan Penelitian Yang Relevan ....................................................... 25

BAB III METODOLOGI PENELITIAN ..................................................... 28

A. Tempat dan Waktu Penelitian ............................................................. 28

B. Metode Penelitian ............................................................................... 28

1. Tahapan Pelaksanaan Penelitian ................................................. 28

2. Desain Model Penelitian ............................................................. 30

3. Prinsip Kerja Sistem ................................................................... 32

C. Alat dan Bahan Penelitian ................................................................... 34

D. Prosedur Pengujian ............................................................................. 35

1. Pengujian Pengaruh DRBD dan Pacemaker Terhadap Sistem ..... 36

a. Skenario Sebelum Pemasangan DRBD dan Pacemaker ....... 36

b. Skenario Setelah Pemasangan DRBD dan Pacemaker ......... 37

2. Pengujian Pengaruh Sistem Terhadap Layanan Server ................ 38

3. Pengujian Nilai Availability Sistem ............................................ 38

a. Skenario Connection Lost ................................................... 39

b. Skenario Power Lost ........................................................... 39

c. Skenario DDOS Attack ........................................................ 40

E. Teknik Pengumpulan Data .................................................................. 41

F. Teknik Analisis Data........................................................................... 42

BAB IV HASIL DAN PEMBAHASAN......................................................... 43

A. Hasil Implementasi Sistem .................................................................. 43

B. Analisis Sistem ................................................................................... 46

1. Pengujian Pengaruh DRBD dan Pacemaker Terhadap Sistem ..... 46

a. Skenario Sebelum Pemasangan DRBD dan Pacemaker ....... 47

b. Skenario Setelah Pemasangan DRBD dan Pacemaker ......... 49

2. Pengujian Pengaruh Sistem Terhadap Layanan Server ................ 54

3. Pengujian Nilai Availability Sistem ............................................ 57

a. Skenario Connection Lost ................................................... 58

x

b. Skenario Power Lost ........................................................... 59

c. Skenario DDOS Attack ........................................................ 59

BAB V PENUTUP ......................................................................................... 64

A. Kesimpulan ......................................................................................... 64

B. Saran ................................................................................................... 65

DAFTAR PUSTAKA ..................................................................................... 66

LAMPIRAN

xi

DAFTAR GAMBAR

Gambar 2.1 Tujuh Tier Disaster Recovery Strategies ..................................... 6

Gambar 2.2 Mekanisme Kerja Tier 0 ............................................................. 7







Gambar 2.9 RAID 0........................................................................................ 17

Gambar 2.10 RAID 1........................................................................................ 17

Gambar 2.11 RAID 2........................................................................................ 18

Gambar 2.12 Prinsip Kerja DRBD .................................................................... 19

Gambar 2.13 Prinsip Kerja Pacemaker............................................................. 21

Gambar 2.14 Daftar Service yang di Dukung Pacemaker ................................. 22

Gambar 3.1 Flowchart Pelaksanaan Penelitian ............................................... 30

Gambar 3.2 Rancangan Konfigurasi Sistem ................................................... 31

Gambar 3.3 Proses Sinkronisasi DRBD .......................................................... 33

Gambar 3.4 Mekanisme Fail Over Pacemaker ............................................... 34

Gambar 3.5 Skenario Sebelum Pemasangan DRBD dan Pacemaker ............... 37

Gambar 3.6 Skenario Setelah Pemasangan DRBD dan Pacemaker ................. 37

Gambar 3.7 Skenario Pengujian Connection Lost ........................................... 39

Gambar 3.8 Skenario Pengujian Power Lost ................................................... 40

Gambar 3.9 Skenario Pengujian DDOS Attack ............................................... 41

Gambar 4.1 IP Floating Server Primary ........................................................ 43

Gambar 4.2 IP Floating Server Secondary ..................................................... 44

Gambar 4.3 Layanan Berjalan Di Server Primary .......................................... 45

Gambar 4.4 Layanan Berjalan Di Server Secondary ....................................... 45

Gambar 4.5 Summary Wireshark .................................................................... 46

Gambar 4.6 Hasil Round Time Trip ................................................................ 47

xii

Gambar 4.7 Grafik Perbandingan Latency ...................................................... 50

Gambar 4.8 Grafik Perbandingan Throughput ................................................ 51

Gambar 4.9 Grafik Perbandingan RTT ........................................................... 51

Gambar 4.10 Grafik Perbandingan Rata-Rata Latency ...................................... 52

Gambar 4.11 Grafik Perbandingan Rata-Rata Throughput ................................ 52

Gambar 4.12 Grafik Perbandingan Rata-Rata RTT ........................................... 52

Gambar 4.13 Antrian Data Tanpa DRBD dan Pacemaker ................................ 53

Gambar 4.14 Antrian Data Dengan DRBD dan Pacemaker .............................. 53

Gambar 4.15 Database Server Primary ............................................................ 54

Gambar 4.16 Database Server Secondary ........................................................ 54

Gambar 4.17 Halaman Login Website .............................................................. 55

Gambar 4.18 Session Website Expired ............................................................. 56

Gambar 4.19 Proses Download File ................................................................. 57

Gambar 4.20 Antrian Data Perpindahaan Fungsi Utama ................................... 57

Gambar 4.21 Aplikasi LOIC ............................................................................. 60

Gambar 4.22 Grafik Perbandingan Lama Downtime ......................................... 61

Gambar 4.23 Grafik Perbandingan Rata-Rata Lama Downtime ........................ 62

Gambar 4.24 Grafik Perbandingan Rata-Rata Availability Sistem .................... 63

xiii

DAFTAR TABEL

Tabel 2.1 Klasifikasi Latency Sistem .............................................................. 23

Tabel 4.1 Latency tanpa DRBD dan Pacemaker ............................................. 47

Tabel 4.2 Throughput tanpa DRBD dan Pacemaker ....................................... 48

Tabel 4.3 RTT tanpa DRBD dan Pacemaker ................................................... 48

Tabel 4.4 Latency dengan DRBD dan Pacemaker ........................................... 49

Tabel 4.5 Throughput dengan DRBD dan Pacemaker ..................................... 49

Tabel 4.6 RTT dengan DRBD dan Pacemaker ................................................ 50

Tabel 4.7 Availability Connection Lost ........................................................... 58

Tabel 4.8 Availability Power Lost .................................................................. 59

Tabel 4.9 Availability DDOS Attack ............................................................... 61

1

BAB I

PENDAHULUAN

A. Latar Belakang

Data dan layanan server telah menjadi dua hal yang sangat penting dalam

memenuhi kebutuhan suatu instansi yang semakin kompleks dari masa ke masa.

Sebuah sistem yang berjalan pada suatu instansi akan bergantung pada layanan

atau aplikasi yang memproses data hingga menjadi sebuah informasi yang

bermanfaat. Namun tidak hanya peranan data dan layanan server saja yang

meningkat tetapi tingkat ancaman yang dapat mengganggu dan merusak data serta

layanan server ini pun juga semakin berkembang. Menurut survey yang telah

dilakukan sebelumnya, ditemukan bahwa penyebab utama kehilangan data dan

kegagalan layanan server pada suatu instansi disebabkan oleh Virus/Worm

komputer, kerusakan perangkat keras, ketiadaan daya, data corruption, bencana

alam dan tindakan sabotase dari pengawai instansi itu sendiri (Barker, 2011).

Diperlukan sebuah sistem yang dapat mengatasi masalah seperti kehilangan

data dan kegagalan layanan server pada instansi dengan baik. Sistem ini harus

memiliki tingkat kehandalan dalam pemulihan data dan layanan server yang cepat

untuk mengurangi tingkat kerugian baik dari sisi ekonomi maupun dari waktu

pelayanan. Solusi terbaik yang dapat dilakukan untuk mengatasi berbagai macam

persoalan diatas adalah dengan membuat sebuah sistem disaster recovery yang

bertujuan untuk memulihkan kembali kondisi data dan layanan server yang

dimiliki oleh instansi seperti semula jika terjadi bencana yang tidak diharapkan.

2

Metode yang dapat digunakan untuk membuat sebuah sistem disaster

recovery adalah high availability cluster. Metode ini bekerja dengan cara

menggabungkan beberapa perangkat PC ataupun server menjadi satu kesatuan

sistem yang dapat menjaga kesinambungan data dan fungsi layanan server untuk

jangka waktu yang lebih lama, hal inilah yang menjadi dasar dari proses

pembuatan sistem disaster recovery yang baik. Untuk membuat sebuah sistem

disaster recovery menggunakan metode ini diperlukan bantuan dari beberapa

aplikasi untuk menjamin tingkat ketersediaan data dan layanan server yang tinggi.

Distributed Replicated Block Device (DRBD) adalah aplikasi open source

yang berfungsi untuk melakukan proses mirroring data, yaitu proses menduplikasi

isi sebuah harddisk ke harddisk lainnya yang terpisah secara fisik melalui media

jaringan komputer untuk menjamin tingkat ketersediaan data yang tinggi.

Sedangkan untuk layanan server dibutuhkan aplikasi yang akan melakukan proses

fail over, yaitu proses pemeriksaan layanan yang berjalan di server serta akan

memindahkan fungsi utama ke server yang lainnya secara otomatis jika server

utama mengalami kegagalan sistem.

Beberapa penelitian sebelumnya mencoba untuk melakukan integrasi proses

mirroring data dengan proses fail over layanan server untuk memperoleh sebuah

sistem disaster recovery yang baik. Pada umumnya penelitian-penelitian ini

menggunakan aplikasi DRBD dan aplikasi Heartbeat untuk proses fail over

layanan server. Adapun penelitian terakhir yang ditemukan, implementasi sistem

disaster recovery dilakukan dengan menggunakan aplikasi open source DRBD

dan Heartbeat kemudian dilengkapi dengan analisis nilai availability dari sistem

3

yang dibuat. Dari hasil penelitian tersebut diperoleh nilai availability sistem

sebesar 99,9950 % yang menunjukkan tingkat kerusakan pada sistem yaitu 26,28

menit down server per tahun (Bahsyar et al, 2013).

Aplikasi Pacemaker merupakan salah satu aplikasi fail over, aplikasi ini

memiliki beberapa kelebihan bila dibandingkan dengan aplikasi fail over

Heartbeat diantaranya yaitu terdapatnya fitur untuk monitoring sistem, dukungan

terhadap layanan server yang lebih banyak serta dapat menggunakan multicast

address sehingga dapat menghemat penggunaan bandwith sistem. Oleh karena itu

pada penelitian ini dilakukan implementasi dan analisis kinerja DRBD dan

Pacemaker sebagai sistem disaster recovery agar dapat menjadi bahan

perbandingan terhadap penelitian-penelitian yang telah dilakukan sebelumnya.

Adapun kinerja sistem yang diuji adalah pengaruh pemasangan DRBD dan

Pacemaker terhadap kualitas kinerja sistem, pengaruh implementasi sistem

terhadap layanan server, serta nilai availability dari sistem yang digunakan.

A. Rumusan Masalah

Berdasarkan uraian dari latar belakang di atas pokok permasalahan yang akan

dibahas dalam penelitian ini adalah:

Bagaimana mengintegrasikan aplikasi DRBD dan Pacemaker menjadi

sebuah high availability cluster sebagai solusi alternatif sistem disaster

recovery?

Bagaimana kemampuan sistem yang didesain dalam menghadapi

berbagai macam skenario pengujian sistem yang dilakukan?

4

Agar menghindari pokok pembahasan materi yang meluas, maka penelitian

ini memiliki ruang lingkup penelitian meliputi hal-hal sebagai berikut:

Pada proses penelitian ini sistem operasi yang akan digunakan adalah

Linux Debian 7.

Layanan server yang akan dibahas dalam penelitian ini adalah database

server, web server dan FTP server.

B. Tujuan Penelitian

Tujuan yang ingin dicapai dalam penelitian ini adalah sebagai berikut:

Mengintegrasikan aplikasi DRBD dan Pacemaker menjadi sebuah high

availability cluster sebagai solusi alternatif sistem disaster recovery.

Memperoleh tingkat kinerja dari sistem yang didesain dalam menghadapi

berbagai macam skenario pengujian sistem yang dilakukan.

C. Manfaat Penelitian

Adapun manfaat dari penelitian ini adalah dapat digunakan oleh administrator

sistem dan jaringan untuk memudahkan dalam melakukan proses mirroring data

dan proses fail over layanan server sehingga diperoleh sebuah sistem disaster

recovery yang memiliki tingkat ketersediaan tinggi bagi data dan layanan server.

5

BAB II

TINJAUAN PUSTAKA

A. Disaster Recovery

1. Definisi Disaster Recovery

Disaster atau bencana menurut kamus besar Bahasa Indonesia adalah

kejadian yang waktu terjadinya tidak dapat diprediksi dan bersifat sangat

merusak. Pengertian ini mengidentifikasikan sebuah kejadian yang tiba-tiba

tidak diharapkan, bersifat sangat merusak dan kurang perencanaan.

Sedangkan pengertian recovery atau pemulihan menurut kamus besar

Bahasa Indonesia adalah proses atau cara pengembalian sesuatu seperti

semula. Sehingga dapat ditarik sebuah kesimpulan bahwa disaster recovery

adalah suatu proses atau cara untuk mengembalikan sesuatu yang rusak

akibat kejadian yang tidak dapat diprediksi sebelumnya menjadi seperti

semula.

2. Tujuh Tier Disaster Recovery Strategies

Memahami disaster recovery strategies terkadang akan menjadi sangat

kompleks, oleh karena itu dibuat sebuat sistem klasifikasi yang akan

membantu dalam mengetahui dan menentukan disaster recovery yang tepat.

Pada tahun 1992, SHARE user grub dari Amerika Serikat bekerja sama

dengan IBM mendefinisikan tujuh tier dari disaster recovery. Definisi dari

6

tiap tier yang ada telah didesain supaya disaster recovery yang muncul dapat

dijelaskan dan diaplikasikan.

Tier 0 – Do Nothing, No Off-Site Data

Tier 0 didefinisikan sebagai single data center environment yang

tidak memiliki sistem backup dan disaster recovery plan sama sekali.

Pada tier ini, tidak ada informasi yang harus disimpan, tidak ada

dokumentasi, tidak ada backup hardware, dan contingency plan. Maka

tidak ada disaster recovery capability sama sekali. Tetapi menurut

pengalaman, beberapa orang atau customer masih berada pada tier ini.

Sebagai contoh, ketika beberapa customer secara aktif membuat

backup pada data yang dimiliki, backup mereka masih ditinggal pada

ruang komputer yang sama, atau kadang-kadang tidak dipindahkan dari

site karena kurangnya ketelitian dalam prosedur penyimpanan. Customer

data center yang berada pada tier ini sangat besar kemungkinannya

untuk mengalami kehilangan data dikarenakan tidak adanya backup.

Gambar 2.1 Tujuh Tier Disaster Recovery Strategies

(Sumber : http://jkt92.blogspot.com/2013/03/disaster-recovery-planning.html)

7

Tier 1 – Off Site Vaulting

Tier 1 didefinisikan sebagai tier yang sudah memiliki disaster

recovery, backup atau penyimpanan data yang dimiliki pada offsite

storage facility dan telah memiliki beberapa recovery requirements.

Backup data yang ingin disimpan diambil dan dibawa ke tempat dimana

data tersebut akan disimpan. Tetapi karena penyimpanan dan

pengambilan data ditangani oleh kurir, tier ini dideskripsikan sebagai

Pickup Truck Access Method (PTAM).

PTAM adalah metode yang digunakan oleh beberapa site, karena

harganya relatif murah. tetapi hal ini susah untuk diatur, karena susah

untuk mengetahui keberadaan data yang ingin disimpan tersebut.

Kemudian beberapa customer yang berada pada tier ini terlihat mampu

untuk melakukan proses recovery data yang ada ketika terjadi bencana.

Tetapi satu hal yang sering menjadi perhatian orang-orang adalah

Recovery Time Objective (RTO). Sebagai contoh, ketika masih mungkin

untuk melakukan recovery data, tetapi untuk melakukan hal itu mungkin

membutuhkan waktu selama beberapa hari atau bahkan beberapa

Gambar 2.2 Mekanisme Kerja Tier 0


8

minggu. Ketidakadanya bussiness data selama periode ini dapat

memberikan dampak yang sangat besar pada business operation.

Tier 2 – Off Site Vaulting with Hotsite

Tier 2 memiliki semua kebutuhan yang dimiliki oleh tier 1 (office

vaulting dan recovery planning) ditambah sebuah hotsite. Hotsite ini

memiliki hardware dan network infrastructure yang cukup mampu

untuk membantu instalasi pada critical processing requirement. Tier 2

mengandalkan kurir untuk melakukan kegiatan mengambil data pada

fasilitas offsite storage. ketika terjadi bencana, data yang ada pada offsite

storage dipindahkan ke hotsite dan dikembalikan kedalam backup

hardware yang telah disediakan. Memindahkan data ke hotsite dapat

meningkatkan biaya tetapi mengurangi recovery time yang signifikan.





9

Tier 3 – Electronic Vaulting

Tier 3 memiliki semua komponen yang dimiliki oleh tier 2 dan

sebagai tambahan, ditambah dengan penyimpanan elektronik terhadap

beberapa subset yang ada pada beberapa data. Penyimpanan elektronik

terdiri dari electronically transmitting dan membuat backup pada

fasilitas yang aman. Memindahkan bussiness-critical data offsite lebih

cepat dan lebih sering daripada menggunakan data backup process yang

dilakukan secara tradisional, hardware yang akan menerima data harus

secara fisik terpisah dengan site utama dan data yang disimpan untuk

recovery harus terjadi bencana terlebih dahulu pada site utama.

Data backup yang ada akan diambil dan disimpan pada offsite

storage facility. Lalu ada juga hotsite yang siap dan backup data yang

ada akan dikirim kesana dari offsite storage facility. Lalu ada juga

electronic vaulting terhadap data yang kritikal yang ditransfer diantara

site utama dengan hotsite. Hotsite yang ada akan tetap berjalan secara

permanen yang mengakibatkan naiknya biaya. Karena data kritikal telah

disimpan pada hotsite tetapi recovery time yang terjadi telah berkurang

lagi secara signifikan.



10

Tier 4 – Electronic Vaulting with Hotsite

Tier 4 dibuat dengan memiliki dua data center dengan penyimpanan

elektronik diantara dua site dan memperkenalkan kebutuhan dari

management data aktif yang disimpan pada recovery site. Hardware

untuk penyimpanan data harus secara fisik terpisah dari platform utama.

Lalu ada juga transmisi data atau koneksi diantara site utama dengan

hotsite yang didukung oleh high bandwidth connection. Pada skenario

ini, beban kerja yang ada dibagi diantara dua site tersebut. Ada transmisi

data yang terus menerus diantara dua site dengan salinan dari data

kritikal yang ada pada kedua site tersebut. Data non kritikal yang ada

pada perusahaan tetap harus dipindahkan oleh kurir ke dalam offsite.

Tier 5 – Two Site Two Phase Commit

Tier 5 memiliki semua kebutuhan yang ada pada tier 4 (offsite

backup, disaster recovery plan, electronic vaulting, dan active secondary

site) dan sebagai tambahannya, data yang dipilih akan dimaintain. Tier 5

membutuhkan kedua site yang ada, baik itu primary dan secondary



11

platform data untuk terus diupdate sebelum ada permintaan untuk

melakukan update agar dapat berhasil.

Tier 6 – Zero Data Loss

Tier 6 meliputi tidak adanya kehilangan data, tier ini secara langsung

dan otomatis akan mentransfer data ke secondary platform. Tier 6 adalah

disaster recovery yang paling akhir. Data yang ada dapat secara

langsung disalin antara primary site dan secondary site dengan network

switching capability.

Pada gambar diatas, kedua site ini sudah tersinkronisasi secara penuh

dengan menggunakan high bandwidth connection antara site utama

dengan hotsite. Kedua sistem ini masing-masing sudah terhubung secara





12

sempurna, memungkinkan switch over otomatis dari satu site ke site

yang lainnya ketika dibutuhkan. Ini merupakan disaster recovery yang

paling mahal tetapi hal ini juga menyediakan recovery yang paling cepat.

B. Clustering Computer

Cluster adalah sekelompok node yang bekerja secara bersama-sama sebagai

sebuah sistem tunggal untuk memastikan bahwa seluruh komponen dapat selalu

tersedia. Sekelompok node tersebut dikelola sebagai sistem tunggal yang didesain

untuk dapat melakukan recovery apabila terjadi sebuah kesalahan pada salah satu

komponen (Kaufmann, 2012).

Sedangkan yang dimaksud dengan clustering computer adalah sekumpulan

komputer (umumnya server jaringan) independen yang beroperasi serta bekerja

secara erat dan terlihat oleh klien jaringan seakan komputer-komputer tersebut

adalah satu unit komputer (Endi Dwi Kristanto, 2012).

1. Jenis-Jenis Clustering

Menurut Endi Dwi Kristanto (2012), clustering computer dapat

dikategorikan dalam beberapa jenis sebagai berikut:

High Availability Cluster

Menurut Storage Network Industri Association definisi dari high

availability adalah suatu kemampuan dari suatu sistem untuk

melakukan fungsinya secara berkesinambungan (tanpa adanya

interupsi) untuk jangka waktu lebih lama dari pada ketahanan yang

diberikan oleh masing-masing komponennya.

13

Load Balancing Cluster

Cluster jenis ini beroperasi dengan mendistribusikan beberapa

pekerjaan secara merata melalui beberapa node yang bekerja

dibelakang (back end node). Pada umumnya cluster ini akan

dikonfigurasi sedemikian rupa dengan beberapa front-end load-

balancing redundan.

Grid Computing

Grid computing dioptimalkan untuk beban pekerjaan yang mencakup

banyak pekerjaan independen atau paket-paket pekerjaan, yang tidak

harus berbagi data yang sama antar pekerjaan selama proses

komputasi dilakukan. Grid bertindak untuk mengatur alokasi

pekerjaan kepada komputer-komputer yang akan melakukan tugas

tersebut secara independen.

Dari penjelasaan diatas diketahui bahwa untuk membangun sebuah

sistem disaster recovery yang baik maka jenis cluster yang terbaik untuk

digunakan adalah high availability cluster karena dapat meningkatkan

kesinambungan fungsi dari data dan layanan pada server dengan tingkat

ketersediaan dan kehandalan yang lebih baik diantara jenis-jenis cluster yang

lainnya.

2. Keuntungan Clustering

Dari artikel yang sama juga Endi Dwi Kristanto menyebutkan beberapa

keuntungan dari clustering computer yaitu sebagai berikut:

14

Resource Sharing

Suatu komputer dapat mengambil sumber daya dari komputer yang

lainnya selama komputer tersebut masih berada dalam satu cluster.

Computation Speed up

Dapat meningkatkan kecepatan komputasi, karena pada sistem

clustering, proses yang ada dapat dibagi kedalam beberapa bagian

komputer yang ada di dalam sistem tersebut

Reliability

Apabila suatu komputer mengalami kegagalan maka sistem masih

dapat berjalan sebagaimana mestinya

Communication

Dikarenakan pada sistem clustering ini satu komputer terhubung

dengan komputer lainnya maka memungkinkan terjadinya pertukaran

informasi.

C. High Availability

Sebelum membahas tentang teknologi yang berhubungan dengan high

availabiltity, ada baiknya untuk mengenal sekilas mengenai konsep yang

diterapkan untuk implementasi high availabiltity. High availabiltity terbagi atas

dua tipe yaitu continuous availability dan fail over availability:

1. Continuous Availability

Dalam continuous availability, service (sebagai contoh database engine)

dituntut untuk tetap available tanpa adanya downtime yang dapat dirasakan

15

oleh user. Terdapat tiga design standar yang dapat digunakan untuk

mengimplemetasikan continuous availability, yaitu programatic, shared

availability dan multiple copy:

Programmatic

Pada intinya, konsep ini mengandalkan pemrograman dari sisi user

application (bukan dari sisi server) dengan cara mengakses ke dua

atau lebih server yang tidak saling berhubungan. Keuntungan dari

system ini adalah mendapatkan maximum flexibility dimana saat

terjadi kegagalan sistem pada satu server tidak akan mempengaruhi

kinerja dari user application.

Shared Availability

Design konsep ini adalah dengan penggunaan redundant systems

yang berbagi critical resources. Dengan konsep ini, selain untuk

high availibility, system juga berfungsi sebagai load balancer.

Multiple Copy

Konsep ini menggunakan beberapa salinan dari data yang diinginkan

untuk highly available pada beberapa server yang saling

berhubungan. Dengan konsep ini, selain untuk high availibility,

server-server juga berfungsi sebagai load balancer.

2. Fail over Availability

Berbeda dengan continuous availability, failover availability

membutuhkan waktu (walaupun sedikit) saat terjadi kegagalan sistem. Dalam

16

konsep ini digunakan dua buah server (primary dan secondary) dengan data

(yang diinginkan untuk highly available) identik pada masing-masing server.

Pada saat sistem dengan konsep ini berjalan normal hanya server

primary yang bertugas untuk melayani seluruh user. Sedangkan pada saat

server primary mengalami kegagalan sistem dan kemudian server secondary

mendeteksi hal tersebut, maka server secondary menggantikan fungsi dari

server primary. Dalam failover availability terdapat dua model kerja yaitu

synchronous dan asynchronous:

Synchronous

Dengan tipe ini, masing-masing server (primary dan secondary)

saling melakukan sinkronisasi data, sehingga keseragaman data pada

masing-masing server tersebut lebih terjamin.

Asynchronous

Dengan tipe ini, sinkronisasi dilakukan dengan cara mengirim

perubahan data pada server yang sedang aktif kepada server yang

sedang pasif. Sehingga hanya salah satu server saja yang melakukan

sinkronisasi dan pada akhirnya network traffic akan jauh lebih

terminimalisir.

D. Redundant Array Independent Disk (RAID)

Secara sederhana RAID bisa diartikan sebagai cara menyimpan data pada

beberapa media harddisk untuk meningkatkan kemampuan komputer atau sebagai

backup. RAID bekerja dengan cara membuat partisi pada ruang dengan ukuran

17

tertentu, tiap partisi tersebut mengandung pecahan data yang akan dibaca secara

bersamaan untuk meningkatkan proses pembacaan data.

RAID terdiri dari beberapa level, mulai dari level 0 hingga level 2 dan

beberapa metode RAID kombinasi lainnya, untuk lebih lengkapnya berikut adalah

penjelasannya:

RAID 0: dikenal juga dengan mode stripped. Sistem ini akan

menggabungkan kapasitas dari beberapa harddisk, sehingga menjadi

sebuah harddisk dengan kapasitas yang besar. Kelebihan dari RAID 0

adalah kecepatan dalam proses membaca data akan meningkat tetapi

kekurangannya jika salah satu dari harddisk tersebut rusak maka data

tidak dapat dibaca sama sekali.

RAID 1: dikenal juga dengan mode mirroring. Sistem ini akan menyalin

isi sebuah harddisk ke harddisk yang lainnya, sehingga jika salah satu

harddisk rusak maka data akan tetap dapat diakses dari harddisk lainnya.

Gambar 2.9 RAID 0

Gambar 2.10 RAID 1

(Sumber : https://en.wikipedia.org/wiki/Standard_RAID_levels)

(Sumber : https://en.wikipedia.org/wiki/Standard_RAID_levels)

18

RAID 2: dikenal menggunakan model mirroring. Namun ditambahkan

tiga harddisk lagi untuk parity hamming, sehingga data menjadi lebih

reliable. Karena itu, jumlah harddisk yang dibutuhkan adalah minimal 5.

Ketiga harddisk terakhir digunakan untuk menyimpan hamming code dari

hasil perhitungan tiap bit-bit yang ada pada harddisk lainnya.

E. Distributed Replicated Block Device (DRBD)

Merupakan solusi replikasi storage harddisk menggunakan dua buah server.

DRBD bekerja dengan cara melakukan teknik mirroring seperti pada RAID 1

hanya saja proses mirroring antara kedua harddisk dilakukan melalui media

jaringan. Proses sinkronisasi pada DRBD tidak terjadi pada level data melainkan

terjadi pada level harddisk sehingga keabsahan data lebih terjamin.

Proses sinkronisasi data bekerja dengan cara DRBD akan melihat sector pada

harddisk yang paling up to date yaitu harddisk yang aktif digunakan oleh client

kemudian sector tersebut akan dibandingkan dengan sector pada harddisk yang

berada pada kondisi standby melalui media jaringan, lalu sector pada harddisk

Gambar 2.11 RAID 2

(Sumber : http://adha.ms/p/85/mari-belajar-raid/)

19

kedua server tersebut akan dibandingkan dan jika ada sector yang tidak sama

maka DRBD akan melakukan modifikasi pada sector harddisk standby sesuai

dengan sector pada harddisk aktif sehingga data pada kedua harddisk menjadi

sama dan sesuai dengan data yang paling baru. Pada dasarnya DRBD dapat

melakukan fungsi mirroring dengan 3 teknik yaitu:

Uptime (A) : Replikasi dilakukan secara terus menerus saat aplikasi

melakukan modifikasi data pada block device

Asynchronous (B) : File system akan diberitahu bahwa penulisan selesai

saat data selesai ditulis pada local disk. Asynchronous ini dibutuhkan pada

saat melakukan mirror jarak jauh.

Synchronous (C) : Dengan melakukan mirroring sinkron, file system

pada aktif node diberitahu bahwa proses penulisan telah berhasil saat

penulisan telah dilakukan pada kedua block device dari masing masing

node. Synchronous mirroring (Protocol C DRBD) adalah pilihan terbaik

untuk local network agar tidak kehilangan single transaction jika terjadi

crash saat terjadi penulisan pada aktif node.

Gambar 2.12 Prinsip Kerja DRBD

(Sumber : http://drbd.linbit.com)

20

F. Pacemaker

Pacemaker adalah aplikasi yang berfungsi untuk melakukan proses fail over,

yaitu pengecekan layanan yang berjalan di server dan kemudian memindahkan

fungsi utama yang menyediakan layanan pada client ke server yang lainnya jika

server utama mengalami kerusakan. Pacemaker memiliki aplikasi bantuan untuk

membuat high availability cluster pada linux yaitu corosync, corosync adalah

linux high availability yang menggunakan teknik cluster yang biasanya digunakan

pada beberapa sistem operasi seperti Linux, Unix, FreeBSD, Solaris, MacOS yang

mengunggulkan kehandalan dan ketersediaan.

Corosync bertujuan untuk terus mengecek server dalam konfigurasi cluster

computer untuk mengetahui keadaan sebenarnya dari server lainnya yang berada

di dalam cluster yang sama pada setiap saat (Bookman, 2002). Corosync bekerja

dengan menggunakan algoritma totem single ring ordering. Algoritma tersebut

akan mendata semua server-server yang akan tergabung menjadi satu cluster dan

menentukan server mana yang akan menjadi mode aktif sedangkan sisanya akan

menjadi mode standby. Semua server yang terdapat di dalam cluster akan

mengirimkan paket konfirmasi ke server-server lainnya yang terdapat pada cluster

yang sama menggunakan protokol UDP dan broadcast address atau multicast

address serta port jaringan tertentu sesuai dengan konfigurasi yang dilakukan

sehingga diketahui bahwa kondisi server tersebut baik.

Ketika ada layanan yang bermasalah pada salah satu server maka server

tersebut tidak akan mengirimkan paket konfirmasi sehingga server akan dianggap

down, dan jika server yang mengalami gangguan adalah server utama maka server

21

utama tersebut akan berubah menjadi kondisi standby dan fungsinya akan diambil

alih oleh server lainnya. Ketika server utama yang sebelumnya mengalami

masalah telah pulih kembali maka server tersebut dapat mengirimkan paket

konfirmasi dan menjadi mode aktif kembali serta server yang sebelumnya berada

pada mode aktif akan kembali menjadi mode standby.

Pacemaker melakukan pengecekan pada level layanan server sehingga jika

terjadi masalah pada layanan server maka Pacemaker akan mengirimkan info

kepada corosync agar tidak mengirimkan paket konfirmasi. Pacemaker menjadi

aplikasi yang terbaik untuk high availability cluster karena selain melakukan

pengecekan server dari sisi layanan, Pacemaker juga memiliki fitur untuk

monitoring sistem cluster sehingga para admin jaringan dapat memantau status

dari layanan server yang berjalan pada sistem cluster. Selain itu Pacemaker juga

mendukung beragam layanan yang berjalan di sisi server, adapun beberapa

layanan yang didukung oleh Pacemaker adalah sebagai berikut.

Gambar 2.13 Prinsip Kerja Pacemaker

(Sumber : http://clusterlabs.org)

22

G. Parameter Kualitas Kinerja Sistem

Parameter-parameter yang menjadi acuan dari tingkat kualitas kinerja sistem

antara lain sebagai berikut.

1. Latency

Latency adalah waktu yang dibutuhkan oleh data untuk menempuh jarak

dari asal sampai ke tujuan (Solekan, 2009). Latency dapat dipengaruhi oleh

jarak, media fisik, kongesti atau juga waktu proses yang lama. Ketika nilai

latency besar dapat diketahui jaringan tersebut sedang sibuk atau

kemungkinan yang lain adalah kapasitas jaringan tersebut yang kecil

sehingga terjadi overload pada media jaringan. Pengambilan data latency

dapat dilakukan dengan menggunakan aplikasi wireshark. Proses perhitungan

dari latency dapat dilakukan dengan persamaan berikut.

(2.1)

Gambar 2.14 Daftar Service yang di Dukung Pacemaker

23

Dan dari hasil penghitungan tersebut kemudian akan dibandingkan

dengan tabel standarisasi latency versi TIPHON berikut ini untuk mengetahui

kinerja sistem yang didesain berdasarkan nilai latency yang telah dihitung.

2. Throughput

Bandwith adalah kemampuan sebuah jaringan untuk membawa data,

biasanya diukur dalam satuan bit per sekon (Oppenheimer, 2011). Konsep

bandwith tidak cukup untuk menjelaskan kecepatan jaringan dan apa yang

terjadi di jaringan. Untuk itulah konsep throughput yaitu kecepatan transfer

data effektif yang diukur dalam bps (bit per sekon) muncul. Throughput

merupakan jumlah total kedatangan paket yang sukses sampai diamati pada

destination selama interval waktu tertentu dibagi oleh durasi interval waktu

tersebut (Solekan, 2009). Untuk menghitung nilai throughput yang dimiliki

oleh sebuah sistem di dalam jaringan dapat digunakan persamaan matematis

sebagai berikut.

Kategori Latency Besar Latency

Excellent < 150 ms

Good 150 ms s/d 350 ms

Poor 350 ms s/d 450 ms

Unacceptable ≥ 450 ms

(2.2)

Tabel 2.1 Klasifikasi Latency Sistem

(Sumber : Standarisasi TIPHON)

24

3. Round Time Trip (RTT)

RTT adalah waktu yang dibutuhkan oleh sebuat paket mulai dari dikirim

sampai kepenerima dan mengirimkan kembali paket acknowledgement pada

pengirim.

4. Downtime

Downtime adalah jumlah waktu dimana suatu perlengkapan tidak dapat

beroperasi disebabkan adanya kerusakaan. Pengukuran downtime dilakukan

untuk mengetahui seberapa lama sebuah server tidak memberikan layanan

kepada client karena terjadi kegagalan sistem. Pengukuran nilai downtime

dilakukan ketika salah satu server mengalami kegagalan sistem dan server

yang lainnya mengambil alih fungsi utama dari sistem yang mengalami

kegagalan tersebut. Untuk mendapatkan nilai downtime dapat dilakukan

dengan menggunakan aplikasi wireshark dan melihat flow graph dari waktu

paket mulai gagal dikirimkan sampai paket berhasil untuk dikirimkan

kembali.

5. Availability

Nilai availability dapat diartikan sebagai kemampuan sebuah sistem

dapat beroperasional dan digunakan ketika dibutuhkan. Untuk menghitung

nilai availability dibutuhkan dua variabel yaitu Elapsed Time dan Downtime.

Elapsed Time adalah lamanya waktu pengamatan yang dihitung dalam satuan

25

detik. Untuk menghitung nilai availability dari sebuah sistem dapat dilakukan

dengan menggunakan persamaan berikut.

Nilai availability sistem diukur dengan banyaknya angka 9 (Nines), semakin

banyak angka 9 maka semakin tinggi tingkat ketersediaan sebuah sistem.

Nilai availability sistem yang bagus adalah 99,9999% (Six Nines) yang

menunjukkan tingkat kerusakan 2,6 detik perbulan (Bahsyar et al, 2013).

H. Temuan Penelitian Yang Relevan

Sebelum penelitian ini dilakukan telah ada beberapa penelitian sebelumnya

yang memiliki kaitan yang erat dengan penelitian ini, adapun penelitian tersebut

adalah:

1. Sovianty (2010) dalam penelitiannya yang berjudul “RANCANG

BANGUN FAIL OVER SERVER BERBASIS LINUX MENGGUNAKAN

SYSTEM DRBD”. ditemukan hasil bahwa DRBD (Distributed Replicated

Blocks Device) dapat menjamin tingkat ketersediaan data yang tinggi

bagi pengguna teknologi informasi, dan menjadi solusi alternatif bagi

metode backup data yang masih menggunakan aplikasi RSync yang

dimana proses penyalinan data hanya berjalan secara satu arah dari

server utama ke server cadangan sehingga keabsahan data tidak dapat

dijamin dengan baik. DRBD dapat melakukan proses penyalinan data

antar server dan berjalan dua arah antara server primary dengan server

(2.3)

26

secondary dengan menggunakan teknik mirroring data sehingga

keabsahan dan ketersediaan data menjadi lebih terjamin. Akan tetapi

pada proses penelitian tersebut tidak terdapat mekanisme fail over

sehingga tidak dapat menjamin ketersediaan yang tinggi untuk layanan

informasi pada server sehingga diperlukan penelitian yang lebih lanjut

untuk menerapkan mekanisme tersebut pada berbagai macam fungsi

layanan pada server.

2. Kemudian penelitian selanjutnya dilakukan oleh Wijaya (2010) yang

berjudul “PENGEMBANGAN DISASTER RECOVERY UNTUK

MENINGKATKAN KETERSEDIAAN INFORMASI DATA DAN

INFORMASI PADA PT.XYZ” diperoleh hasil bahwa sistem disaster

recovery yang dibuat dengan mengintegrasikan aplikasi DRBD dan

Heartbeat dapat menjamin tingkat ketersediaan yang tinggi untuk data

dan informasi yang terdapat pada PT. XYZ.

3. Selanjutnya penelitian yang dilakukan oleh Faruq dan Suryono (2012)

yang berjudul “IMPLEMENTASI DISASTER RECOVERY PLAN

DENGAN SISTEM FAIL OVER MENGGUNAKAN DRBD DAN

HEARTBEAT PADA DATA CENTER FKIP UNS”. Diperoleh hasil

bahwa DRBD berhasil diintegrasikan dengan salah satu aplikasi fail over

server yaitu Heartbeat dan dapat membantu aktifitas layanan teknologi

informasi pada FKIP UNS yang telah menggunakan sistem administrasi

berbasis online. Sehingga FKIP UNS memiliki sistem cadangan jika

sewaktu-waktu terjadi kerusakan pada sistem administrasi online UNS.

27

4. Penelitian lainnya yang serupa dilakukan oleh Purnomo (2012) berjudul

“PEMANFAATAN FAILOVER CLUSTER SERVER GUNA RECOVERY

SISTEM PADA PT LINTAS DATA PRIMA” dari hasil penelitian tersebut

diperoleh hasil bahwa Heartbeat dapat diimplementasikan sebagai

recovery sistem untuk menjamin kesinambungan fungsi layanan server

dan kelangsungan proses bisnis pada PT. Lintas Data Prima.

5. Penelitian yang serupa juga dilakukan oleh Bahsyar, Dkk (2013) dengan

judul penelitian “IMPLEMENTASI DAN ANALISIS PERFORMANSI

SISTEM HIGH AVAILABILITY SERVER MENGGUNAKAN

DISTRIBUTED REPLICATED BLOCK DEVICE (DRBD)”. Diperoleh

hasil penelitan bahwa aplikasi DRBD dapat diintegrasikan dengan

aplikasi fail over seperti Heartbeat. Selain itu juga diperoleh hasil

pengukuran kinerja dari sistem tersebut dengan beberapa parameter

acuan yaitu downtime, throughput dan round time trip serta availability

sistem sebesar 99,9950% yang menunjukkan tingkat kerusakan sistem

sebesar 26,28 menit down server per tahun. Tetapi hasil penelitan

tersebut memperlihatkan hasil pengukuran yang belum memuaskan dan

juga Heartbeat hanya mendukung cluster hingga dua server saja yang

tentu saja masih menjadi kelemahan dari sistem tersebut. Selain itu

Heartbeat juga tidak memiliki fitur monitoring untuk melihat status dan

kondisi dari sistem yang dibuat.

28

BAB III

METODOLOGI PENELITIAN

A. Tempat Dan Waktu Penelitian

Penelitian ini bertempat di Laboratorium Centre of Applied ICT Research

(C.A.I.R) Politeknik Negeri Ujung Pandang. Dan penelitian ini dilaksanakan pada

bulan Januari 2015 sampai dengan Juni 2015.

B. Metode Penelitian

Suatu metode digunakan agar penelitian yang dilakukan lebih terarah dan

mendapatkan data yang valid dengan tujuan agar dapat ditemukan, dikembangkan

dan dibuktikan sehingga dapat digunakan untuk memahami dan mengantisipasi

suatu masalah. Dalam penelitian ini metode penelitian yang digunakan adalah

metode eksperimen dengan pendekatan kuantitatif untuk menjelaskan variabel

yang diteliti. Dalam penelitian yang dilakukan variabel yang diteliti adalah

parameter-parameter kehandalan dari sistem yang didesain.

1. Tahapan Pelaksanaan Penelitian

Berikut ini adalah tahapan pelaksanaan yang akan dilakukan dalam

proses penelitian ini.

Langkah 1: Langkah pertama dimulai dengan mengidentifikasi dan

menganalisa daftar kebutuhan sistem yang akan digunakan dengan

mengamati kondisi sistem yang digunakan saat ini serta kebutuhan

29

client untuk proses perancangan sistem yang akan digunakan dalam

penelitian.

Langkah 2: Setelah itu dilanjutkan dengan menjelaskan hasil

perancangan sistem. Hasil perancangan sistem tersebut kemudian

diterapkan dan dilakukan proses pemasangan sistem sesuai dengan

perancangan yang telah didesain sebelumnya serta melakukan

installasi dan konfigurasi semua aplikasi yang dibutuhkan dalam

proses penelitian.

Langkah 3: Jika sistem yang berjalan tidak memperlihatkan hasil

sesuai dengan kondisi yang diinginkan pada proses perancangan

sebelumnya maka akan dilakukan proses perancangan ulang terhadap

sistem yang digunakan dalam penelitian ini hingga diperoleh hasil

sesuai dengan kondisi yang diinginkan.

Langkah 4: Kemudian akan dilakukan serangkaian pengujian sistem

sesuai dengan beberapa skenario pengujian yang sudah dirancang

sebelumnya untuk mendapatkan data yang diinginkan.

Langkah 5: Data tersebut kemudian dianalisa agar didapatkan hasil

penelitian yang sesuai dengan tujuan yang ingin dicapai

Langkah 6: Dan pada akhirnya akan diperoleh beberapa kesimpulan

dari proses penelitian.

Agar lebih mudah memahami tahapan pelaksanaan penelitian yang akan

dilakukan, berikut ini adalah flowchart dari tahapan pelaksanaan penelitian

sesuai dengan penjelasan diatas.

30

.

2. Desain Model Penelitian

Sistem yang akan didesain merupakan simulasi dari sistem disaster yang

sesunguhnya. Sistem yang didesain menggunakan topologi jaringan lokal

serta model warm standby redundant dimana terdapat dua buah node, yaitu

server primary dan server secondary serta satu buah switch yang akan

digunakan untuk menghubungkan kedua server dengan client dan beberapa

tambahan PC lainnya untuk pengujian sistem. Topologi serta penjelasan

secara rinci mengenai desain sistem tersebut dapat dilihat pada gambar 3.2

dibawah ini.

Gambar 3.1. Flowchart Pelaksanaan Penelitian

31

Secara umum hanya server primary saja yang akan melayani client.

Sedangkan server secondary akan berada pada kondisi standby.

Server secondary adalah server yang menerima duplikat data yang

ada di server primary dan hanya akan melayani permintaan client

jika server primary mengalami kegagalan sistem. Begitu pula

sebaliknya server primary akan menerima duplikat data di server

secondary ketika fungsi utama berjalan pada server secondary.

Untuk keperluan pengujian sistem pada penelitian ini maka pada

kedua buah server baik itu server primary dan server secondary

akan memiliki dua buah interface. Interface eth0 menggunakan

Ethernet dan akan difungsikan untuk memaksimalkan bandwith

yang akan digunakan untuk proses sinkronisasi data oleh DRBD.

Sedangkan interface eth1 pada server menggunakan Gigabit

Ethernet dan akan difungsikan untuk melayani permintaan client.

Gambar 3.2 Rancangan Konfigurasi Sistem

32

Selain itu interface eth1 pada kedua server juga akan menggunakan

IP floating. IP floating adalah IP virtual yang akan berpindah

lokasinya dari server primary ke server secondary jika terjadi

kegagalan sistem pada server primary. Ketika client ingin

menggunakan data atau layanan pada sistem maka IP floating

inilah yang harus diakses.

Dalam desain sistem ini juga akan digunakan sebuah switch untuk

menghubungkan sistem dengan client serta akan digunakan sebuah

laptop sebagai client untuk meminta layanan atau data ke sistem.

Dalam desain sistem ini juga digunakan beberapa buah PC lainnya

yang akan digunakan sebagai attacker DDOS untuk melumpuhkan

server primary pada salah satu skenario pengujian sistem nantinya.

3. Prinsip Kerja Sistem

Pada sistem yang akan diuji nanti akan digunakan dua buah aplikasi

yaitu DRBD dan Pacemaker. Berikut ini adalah penjelasan tentang prinsip

kerja dari kedua aplikasi yang akan diintegrasikan dan menjadi dasar dari

pembuatan sistem pada penelitian yang dilakukan.

Prisip Kerja Distributed Replicated Blocks Device (DRBD)

DRBD akan bekerja untuk melakukan proses sinkronisasi data antara

dua buah server yang ada, dimana satu server akan berfungsi sebagai

primary dan server lainnya akan berfungsi sebagai secondary. Data

apapun yang diinputkan, dimodifikasi dan dihapus pada server primary

33

maka sistem DRBD akan segera melakukan proses sinkronisasi dan

penyalinan data ke server secondary sehingga data yang ada di kedua

buah server selalu sama termasuk perubahaan yang terjadi pada data.

Dan jika server primary mengalami kegagalan sistem dan fungsi

utama diambil alih oleh server secondary lalu server primary aktif

kembali maka DRBD akan melakukan proses sinkronisasi data dari

server secondary ke server primary dan menyalin semua data baru yang

ada di server secondary ke server primary sehingga data di kedua buah

server selalu sama dan kemudian server primary akan mengambil alih

kembali fungsi utama dari sistem

Prisip Kerja Pacemaker

Cara kerja Pacemaker sangat sederhana, misalnya jika server

primary mengalami kegagalan sistem maka server primary tidak dapat

mengirimkan paket konfirmasi ke server secondary sehingga Pacemaker

yang ada di server secondary akan menyatakan bahwa server primary

mengalami kerusakan dan akan langsung mengubah status dari server

secondary menjadi aktif. Pengiriman paket konfirmasi dilakukan oleh

server primary dan server secondary menggunakan protokol UDP dan

Gambar 3.3 Proses Sinkronisasi DRBD

34

multicast address serta port yang sudah diatur sebelumnya. Kemudian

ketika server primary telah pulih kembali maka server primary dapat

mengirimkan paket konfirmasi lagi dan ketika server secondary

mendeteksi ada paket konfirmasi dari server primary maka Pacemaker

akan mengubah status server secondary dari mode aktif ke mode standby

dan server primary menjadi mode aktif kembali.

C. Alat dan Bahan Penelitian

Untuk mendukung penelitian ini maka diperlukan alat dan bahan yang dapat

digunakan untuk mencapai target yang diinginkan. Adapun spesifikasi hardware

yang akan digunakan adalah sebagai berikut.

1. 2 unit PC yang akan digunakan sebagai server dengan spesifikasi yaitu:

Processor Intel Core 2 Duo 2,20 GHz

RAM 1024 MB DDR3

Harddisk 500 GB

2. 1 Unit Monitor 14 “

3. 1 Unit Keyboard Computer

Gambar 3.4 Mekanisme Fail Over Pacemaker

35

4. 1 Unit Mouse Computer

5. 1 unit Switch Dlink 24 Port 100 Mbps

6. 1 unit Notebook/Laptop Untuk Client

7. 6 unit PC Untuk DDOS Attacker

8. 2 unit NIC 1 GigabitEthernet Tambahan

9. Kabel UTP Cat 5

10. Konektor RJ 45

Dan adapun kebutuhan software yang akan digunakan pada proses penelitian

ini adalah.

1. OS Debian 7 Wheezy 32-bit.

2. Distributed Replicated Blocks Device (DRBD)

3. Pacemaker

4. Proftpd

5. Apache2

6. Mysql-Server, Mysql-Client

7. Wireshark

8. Putty

D. Prosedur Pengujian

Pada penelitian ini dilakukan proses implementasi dari hasil perancangan

sistem yang digunakan dengan cara melakukan pemasangan serta installasi dari

aplikasi DRBD, Pacemaker, apache2, mysql-server dan proftpd sebagai aplikasi

36

yang akan diintegrasikan ke dalam sistem yang didesain. Kemudian akan

dilakukan pengujian kemampuan sistem sebagai sistem disaster recovery. Proses

pengujian dilakukan dengan menggunakan beberapa skenario pengujian yang

akan dilakukan sebanyak sepuluh kali untuk masing-masing skenario pengujian.

1. Pengujian Pengaruh DRBD dan Pacemaker Terhadap Sistem

Proses pengujian ini dilakukan untuk mengetahui pengaruh dari

pemasangan sistem DRBD dan Pacemaker, apakah terjadi penurunan kualitas

terhadap kinerja dari server yang akan digunakan dalam penelitian ini atau

tidak. Oleh karena itu dalam proses pengujian ini akan dilakukan dengan dua

skenario, yaitu skenario pengujian kinerja server sebelum pemasangan DRBD

dan Pacemaker dengan skenario pengujian kinerja server setelah pemasangan

DRBD dan Pacemaker. Kemudian akan dibandingkan hasilnya untuk

mengetahui perubahan kinerja server. Pengujian akan dilakukan selama dua

menit untuk sekali percobaan dan adapun parameter-parameter yang akan

diukur adalah nilai latency, throughput dan RTT dari sistem yang didesain.

a. Skenario Sebelum Pemasangan DRBD dan Pacemaker

Skenario pengujian sistem sebelum menggunakan DRBD dan

Pacemaker dilakukan untuk mengetahui kinerja dan kemampuan dari

sistem dalam keadaan normal agar dapat dibandingkan dengan kinerja

dan kemampuan dari sistem setelah proses implementasi DRBD dan

Pacemaker. Pengujian ini dilakukan dengan cara client akan mengakses

IP address yang terdapat pada server yang telah disiapkan.

37

b. Skenario Setelah Pemasangan DRBD dan Pacemaker

Kemudian setelah itu akan dilakukan skenario pengujian sistem

setelah menggunakan DRBD dan Pacemaker dengan menginstalkan dan

mengkonfigurasi DRBD dan Pacemaker pada kedua server. Kemudian

pengujian dilakukan dengan cara mengakses IP floating yang terdapat

pada sistem yang didesain.

Gambar 3.5 Skenario Sebelum Pemasangan DRBD dan Pacemaker

Gambar 3.6 Skenario Setelah Pemasangan DRBD dan Pacemaker

38

2. Pengujian Pengaruh Sistem Terhadap Layanan Server

Pengujian ini dilakukan untuk melihat ketersediaan sistem yang didesain

serta pengaruh dari kegagalan sistem terhadap data dan layanan yang terdapat

di server. Adapun layanan server yang akan diuji dalam proses pengujian ini

yaitu database server, Web server serta FTP server. Pengujian ini dilakukan

dengan cara mengamati data yang terdapat pada database di server primary

dengan server secondary apakah data pada kedua server tersebut sama atau

tidak, termasuk ketika terjadi perubahan data dan kegagalan pada sistem.

Kemudian akan dilakukan juga pengamatan untuk melihat pengaruh dari

kegagalan sistem terhadap layanan Web server pada sistem yang digunakan

oleh client dan selanjutnya akan dilakukan juga pengamatan terhadap layanan

FTP server pada sistem yang diujikan untuk mengetahui pengaruh dari

kegagalan sistem terhadap proses download data.

3. Pengujian Nilai Availability Sistem

Pengujian ini dilakukan untuk menghitung tingkat ketersediaan dari

sistem yang digunakan oleh client dalam menghadapi berbagai jenis ancaman

kegagalan sistem yang mungkin terjadi dan parameter yang menjadi acuan

adalah nilai availability dari sistem. Untuk pengujiannya akan dilakukan

dengan tiga skenario kegagalan sistem yang berbeda, adapun ketiga skenario

tersebut adalah skenario connection lost, power lost dan yang terakhir adalah

skenario kegagalan sistem yang sedikit berbeda karena kegagalan sistem

disebabkan oleh serangan cracker yaitu DDOS attack.

39

a. Skenario Connection Lost

Skenario ini adalah skenario pengujian sistem yang meliputi

kegagalan sistem yang terdapat pada server primary karena terputusnya

koneksi jaringan komputer sehingga fungsi utama pada sistem berpindah

ke server secondary. Pengujian ini dilakukan dengan cara client akan

mengakses IP floating pada sistem yang telah didesain kemudian kabel

jaringan yang terhubung ke server primary akan dicabut secara paksa

sehingga fungsi utama berpindah ke server secondary.

b. Skenario Power Lost

Selanjutnya adalah skenario pengujian sistem yang meliputi proses

kegagalan sistem yang terdapat pada server primary karena hilangnya

sumber daya listrik pada server primary sehingga fungsi utama pada

sistem berpindah ke server secondary. Pengujian ini dilakukan dengan

Gambar 3.7 Skenario Pengujian Connection Lost

40

cara client akan mengakses IP floating pada sistem yang telah didesain

kemudian kabel power pada server primary akan dicabut secara paksa

sehingga fungsi utama berpindah ke server secondary.

c. Skenario DDOS Attack

Skenario selanjutnya adalah skenario pengujian sistem yang dimana

proses kegagalan sistem pada server primary disebabkan oleh serangan

Distributed Denial Of Service (DDOS) yang bertujuan untuk

melumpuhkan server primary sehingga fungsi utama sistem diambil alih

oleh server secondary. Dalam skenario pengujian ini untuk melakukan

serangan DDOS attack akan digunakan sebuah software yang dipasang

pada tiap-tiap PC yang akan difungsikan sebagai penyerang.

Gambar 3.8 Skenario Pengujian Power Lost

41

E. Teknik Pengumpulan Data

Proses pengumpulan data di dalam penelitian ini akan dilakukan dengan

menggunakan beberapa teknik yaitu teknik observasi atau pengamatan dan juga

teknik studi literatur.

Studi Literatur

Pengumpulan data akan dilakukan melalui studi literatur dari buku,

jurnal, white paper, proceeding, tugas akhir/tesis/disertasi, dan website.

Observasi

Observasi atau pengamatan akan dilakukan selama proses pengujian

dengan beberapa cara yang berbeda. Untuk memperoleh data yang akan

digunakan untuk menghitung nilai latency, throughput, downtime dan

availability dapat dilakukan dengan cara melakukan PING dari client menuju

ke sistem yang diuji kemudian skenario pengujian dapat dilakukan.

Gambar 3.9 Skenario Pengujian DDOS Attack

42

Lalu hasil dari pengujian sistem tersebut akan ditangkap dengan

menggunakan aplikasi wireshark sedangkan untuk memperoleh data untuk

menghitung nilai RTT dapat dilakukan dengan cara menangkap hasil PING

dari layar terminal client. Kemudian data yang telah dikumpulkan tersebut

akan dianalisa menjadi hasil akhir dari penelitian ini.

F. Teknik Analisis Data

Teknik analisis data yang akan digunakan dalam penelitian ini adalah teknik

analisis data kuantitatif. Dimana data hasil pengukuran dari beberapa skenario

pengujian yang dilakukan kemudian akan disubstitusi ke dalam persamaan yang

ada untuk dihitung hasilnya. Dari hasil perhitungan tersebut kemudian akan dibuat

tabel dan grafik yang akan memperlihatkan perubahan dan hasil analisa dari

kemampuan sistem dalam penelitian ini.

43

BAB IV

HASIL DAN PEMBAHASAN

A. Hasil Implementasi Sistem

Untuk langkah-langkah instalasi sistem yang digunakan dalam penelitian ini

dapat dilihat secara langsung pada bagian lampiran. Pada proses instalasi sistem,

interface eth1 pada kedua server terdeteksi sebagai interface eth3 pada server

primary dan sebagai interface eth2 pada server secondary. Kemudian setelah

proses instalasi sistem yang digunakan dalam penelitian ini sudah selesai maka

diperoleh hasil yaitu sebagai berikut.

Dari gambar diatas dapat melihat pengaruh dari IP floating. IP floating adalah

IP address yang bersifat sementara artinya IP address ini akan berpindah-pindah

Gambar 4.1 IP Floating pada Server Primary

44

posisinya. Ketika fungsi utama berjalan di server primary maka IP floating ini

akan berada di server primary. Akan tetapi ketika fungsi utama berpindah ke

server secondary maka IP floating juga akan berpindah ke server secondary

sehingga client hanya perlu menggunakan IP floating saja untuk mengakses

database, web server atau FTP server dan fungsi layanan server tersebut juga

akan secara otomatis berpindah dan client tidak akan merasakan pengaruh dari

perpindahan server.

Dari kedua gambar diatas dapat lihat bahwa IP floating akan berada di server

primary ketika fungsi utama berjalan di server primary hal ini terlihat dengan

interface eth3:virt yang memiliki IP floating dan ketika fungsi utama pindah ke

server secondary maka IP floating akan pindah ke server secondary, dari gambar

diatas ditandai dengan interface eth2:virt yang miliki IP floating pada server

Gambar 4.2 IP Floating pada Server Secondary

45

secondary dan interface eth3:virt pada server primary akan menghilang

dikarenakan IP floating telah pindah ke server secondary.

Selain itu dengan menggunakan aplikasi Pacemaker terdapat fitur monitoring

sistem dengan cara mengetikkan perintah “crm_mon” berikut ini adalah tampilan

hasil monitoring ketika fungsi utama berjalan di server primary.

Sedangkan untuk tampilan hasil monitoring dari sistem ketika fungsi utama

berjalan di server secondary dapat dilihat pada gambar dibawah ini.

Gambar 4.3 Layanan Berjalan di Server Primary

Gambar 4.4 Layanan Berjalan di Server Secondary

46

B. Analisis Sistem

Analisis kinerja dari sistem yang didesain dilakukan dengan beberapa

skenario pengujian yang telah dibahas sebelumnya, adapun hasil yang diperoleh

dari skenario pengujian tersebut adalah sebagai berikut.

1. Pengujian Pengaruh DRBD Dan Pacemaker Terhadap Sistem

Pengujian yang pertama adalah pengujian yang membandingkan kinerja

server yang diuji sebelum pemasangan sistem DRBD dan Pacemaker dengan

setelah pemasangan sistem DRBD dan Pacemaker adapun parameter yang

akan dibandingkan adalah latency, throughput serta Round Time Trip (RTT).

Untuk mengukur parameter tersebut sebelum pemasangan DRBD dan

Pacemaker dapat dilakukan dengan cara client melakukan PING ke IP

address server target, sedangkan untuk mengukur parameter tersebut setelah

pemasangan DRBD dan Pacemaker dapat dilakukan dengan cara client

melakukan PING ke IP floating yang dimiliki oleh sistem yang telah didesain

kemudian untuk hasil dari kedua pengujian tersebut dapat ditangkap dengan

menggunakan aplikasi wireshark. Setelah itu untuk melihat hasilnya klik

pada menu bar Statistic --> Summary berikut ini adalah hasilnya.

Dan untuk mendapatkan nilai latency dapat diperoleh dengan cara

membagi nilai between first and last packet dengan nilai dari jumlah packets

Gambar 4.5 Summary Wireshark

47

sesuai dengan persamaan (2.1). Between first and last packet merupakan

durasi pengiriman sejumlah paket. Sedangkan untuk nilai throughput

diperoleh dengan cara membagi nilai jumlah Bytes dengan nilai between first

and last packets sesuai dengan persamaan (2.2). Kemudian untuk

memperoleh nilai RTT dari sistem yang diuji dapat dilihat secara langsung

dari hasil PING pada layar terminal atau cmd client sebagai berikut.

a. Skenario Sebelum Pemasangan DRBD dan Pacemaker

Hasil dari skenario yang pertama yaitu tanpa menggunakan sistem

DRBD dan Pacemaker diperoleh hasil sebagai berikut.

NO. Percobaan

Time Between First and Last (s)

Packet Latency

(ms)

1 Percobaan Ke 1 126.347 1307.000 96.669

2 Percobaan Ke 2 124.356 1323.000 93.995

3 Percobaan Ke 3 126.021 1575.000 80.013

4 Percobaan Ke 4 128.032 1407.000 90.996

5 Percobaan Ke 5 124.757 1284.000 97.163

6 Percobaan Ke 6 128.917 1465.000 87.998

7 Percobaan Ke 7 128.232 1279.000 100.260

8 Percobaan Ke 8 127.807 1307.000 97.787

9 Percobaan Ke 9 125.068 1293.000 96.727

10 Percobaan Ke 10 130.632 1436.000 90.969

Rata-Rata 93.258

Gambar 4.6 Hasil Round Time Trip

Tabel 4.1 Latency Tanpa DRBD dan Pacemaker

48

NO. Percobaan Jumlah Byte Sukses

(Byte) Waktu

Pengiriman (s) Throughput

(KB/sec)

1 Percobaan Ke 1 1340376.000 126.347 10.609

2 Percobaan Ke 2 1320915.000 124.356 10.622

3 Percobaan Ke 3 1415923.000 126.021 11.236

4 Percobaan Ke 4 1404523.000 128.032 10.970

5 Percobaan Ke 5 1318854.000 124.757 10.571

6 Percobaan Ke 6 1393061.000 128.917 10.806

7 Percobaan Ke 7 1318970.000 128.232 10.286

8 Percobaan Ke 8 1322657.000 127.807 10.349

9 Percobaan Ke 9 1328340.000 125.068 10.621

10 Percobaan Ke 10 1398173.000 130.632 10.703

Rata-Rata 10.677

NO. Percobaan RTT (ms)

1 Percobaan Ke 1 0.101










Rata-Rata 0.103

Dari hasil pengujian diperoleh hasil pengukuran latency yang nilainya

lebih kecil dari pada 150 ms hal ini menunjukkan bahwa kinerja server

tanpa sistem DRBD dan Pacemaker tergolong ke dalam kategori sangat

bagus menurut standarisasi TIPHON begitu pula dengan hasil pengukuran

throughput dan RTT yang menunjukkan hasil yang sangat bagus.

Tabel 4.2 Throughput Tanpa DRBD dan Pacemaker

Tabel 4.3 RTT Tanpa DRBD dan Pacemaker

49

b. Skenario Setelah Pemasangan DRBD dan Pacemaker

Sedangkan hasil pengujian dengan menggunakan sistem DRBD dan

Pacemaker diperoleh hasil sebagai berikut.

NO. Percobaan Time Between First

and Last (s) Packet Latency

(ms)

1 Percobaan Ke 1 138.205 1242.000 111.276

2 Percobaan Ke 2 119.588 1264.000 94.611

3 Percobaan Ke 3 124.115 1288.000 96.363

4 Percobaan Ke 4 124.447 1147.000 108.498

5 Percobaan Ke 5 128.948 1200.000 107.457

6 Percobaan Ke 6 134.105 1216.000 110.284

7 Percobaan Ke 7 126.001 1319.000 95.528

8 Percobaan Ke 8 128.497 1165.000 110.298

9 Percobaan Ke 9 126.014 1237.000 101.871

10 Percobaan Ke 10 121.822 1263.000 96.454

Rata-Rata 103.264

NO. Percobaan Jumlah Byte Sukses

(Byte) Total Waktu

Pengiriman (s) Throughput

(KB/sec)

1 Percobaan Ke 1 1366326.000 138.205 9.886

2 Percobaan Ke 2 1297731.000 119.588 10.852

3 Percobaan Ke 3 1340597.000 124.115 10.801

4 Percobaan Ke 4 1282317.000 124.447 10.304

5 Percobaan Ke 5 1339549.000 128.948 10.388

6 Percobaan Ke 6 1317081.000 134.105 9.821

7 Percobaan Ke 7 1348917.000 126.001 10.706

8 Percobaan Ke 8 1298579.000 128.497 10.106

9 Percobaan Ke 9 1300132.000 126.014 10.317

10 Percobaan Ke 10 1315549.000 121.822 10.799

Rata-Rata 10.398

Tabel 4.4 Latency Dengan DRBD dan Pacemaker

Tabel 4.5 Throughput Dengan DRBD dan Pacemaker

50

NO. Percobaan RTT (ms)











Rata-Rata 0.108

Dari hasil pengujian diatas dapat diketahui bahwa besar latency dari

sistem setelah menggunakan DRBD dan Pacemaker masih lebih kecil

dari 150 ms sehingga kualitas layanan termasuk kedalam kategori sangat

bagus begitu pula dengan nilai throughput dan RTT yang diperoleh.

Selain itu dari penelitian yang mengukur kinerja sistem tanpa

menggunakan DRBD dan Pacemaker dengan sistem yang telah

menggunakan DRBD dan Pacemaker maka dapat memperoleh grafik

sebagai berikut.

Tabel 4.6 RTT Dengan DRBD dan Pacemaker

0

20

40

60

80

100

120

1 2 3 4 5 6 7 8 9 10

ms

Percobaan

Latency

Tanpa Sistem

Dengan Sistem

Gambar 4.7 Grafik Perbandingan Latency

51

Kemudian dapat diperoleh juga grafik rata-rata latency, throughput

dan RTT antara sistem yang belum menggunakan DRBD dan Pacemaker

dengan sistem yang telah menggunakan DRBD dan Pacemaker sebagai

berikut.

9.0

9.5

10.0

10.5

11.0

11.5

1 2 3 4 5 6 7 8 9 10

MB

/se

c

Percobaan

Throughput

Tanpa Sistem

Dengan Sistem

0.000

0.050

0.100

0.150

0.200

0.250

0.300

1 2 3 4 5 6 7 8 9 10

ms

Percobaan

Round Time Trip

Dengan Sistem

Tanpa Sistem

Gambar 4.8 Grafik Perbandingan Throughput

Gambar 4.9 Grafik Perbandingan RTT

52

93.258

103.264

88

90

92

94

96

98

100

102

104

106

Tanpa Sistem Dengan Sistem

ms

Latency

Tanpa Sistem

Dengan Sistem

10.677

10.398

10.2

10.3

10.4

10.5

10.6

10.7


KB

/sec

Throughput

Tanpa Sistem

Dengan Sistem

0.103

0.108

0.1

0.101

0.102

0.103

0.104

0.105

0.106

0.107

0.108

0.109


ms

Round Time Trip

Tanpa Sistem

Dengan Sistem

Gambar 4.10 Grafik Perbandingan Rata-Rata Latency

Gambar 4.11 Grafik Perbandingan Rata-Rata Throughput

Gambar 4.12 Grafik Perbandingan Rata-Rata RTT

53

Dari grafik diatas dapat dilihat bahwa pemasangan sistem DRBD dan

Pacemaker pada server mempengaruhi kinerja dari sistem, hal ini terlihat dari

nilai latency dan RTT yang meningkat setelah pemasangan DRBD dan

Pacemaker serta nilai throughput yang menurun. Akan tetapi penurun kinerja

ini nilainya sangatlah kecil sehingga tidak terlalu mempengaruhi kinerja dari

sistem secara keseluruhan.

Adapun penyebab dari penurunan kinerja dari sistem ini disebabkan oleh

antrian data di dalam jaringan yang bertambah karena adanya paket data baru

yang melalui jaringan, paket tersebut adalah paket Pacemaker yang

melakukan fungsi untuk memberitahukan status dari server primary dan

server secondary, paket tersebut melalui jaringan menggunakan multicast

address 226.94.1.1 dan juga port 5405 UDP. Berikut adalah gambar yang

menampilkan paket yang terkirim pada sistem tanpa DRBD dan Pacemaker.

Sedangkan gambar dibawah ini adalah gambar yang menampilkan paket

yang terkirim pada sistem yang telah menggunakan DRBD dan Pacemaker.

Gambar 4.13 Antrian Data Tanpa DRBD dan Pacemaker

Gambar 4.14 Antrian Data Dengan DRBD dan Pacemaker

54

2. Pengujian Pengaruh Sistem Terhadap Layanan Server

Pengujian ini dilakukan untuk melihat pengaruh dari DRBD dan

Pacemaker terhadap kinerja database server, web server dan FTP server

termasuk ketika terjadi masalah atau bencana pada sistem yang digunakan.

Untuk pengujian database server dapat dilihat data yang terdapat pada

database di server primary sebagai berikut.

Sedangkan data yang terdapat di database pada server secondary adalah

sebagai berikut.

Gambar 4.15 Database Server Primary

Gambar 4.16 Database Server Secondary

55

Dari kedua gambar diatas terlihat bahwa setelah pemasangan DRBD dan

Pacemaker data yang terdapat pada database server akan selalu identik dan

sama antara server primary dan server secondary. Perubahan data apapun

yang terjadi pada data di server primary maka perubahaan itu juga akan

terjadi di server secondary sehingga dengan sistem ini juga bisa menyediakan

tingkat ketersediaan yang tinggi terhadap data bagi client dan dapat menjadi

solusi disaster recovery terhadap permasalahan data.

Dan untuk layanan web server berikut ini adalah tampilan dari website

yang digunakan dalam penelitian ini.

Ketika client mengakses web server dan terjadi perpindahan fungsi dari

server primary ke server secondary maka web server yang diakses oleh client

akan mengalami downtime dalam waktu yang sangat singkat sehingga client

tidak merasakan adanya perpindahan fungsi utama dari layanan web server.

Gambar 4.17 Halaman Login Website

56

Akan tetapi jika di dalam web server terdapat fungsi yang mengecek

session maka koneksi akan expired dan terputus sehingga client akan

terlogout secara otomatis, akan tetapi web server tidak mengalami down yang

lama sehingga client dapat login kembali kedalam sistem. Solusi untuk

mengatasi masalah tersebut adalah dengan melakukan sinkronisasi data

session website yang tersimpan pada harddisk server yang digunakan agar

session website dapat dikenali oleh kedua server sehingga session tidak akan

mengalami expired serta website tidak akan terlogout otomatis lagi.

Sedangkan untuk layanan FTP server, ketika client melakukan download

file menggunakan layanan FTP dan ditengah-tengah proses transfer data,

server primary tiba-tiba down dan fungsi utama dialihkan ke server

secondary maka proses download dari client akan berhenti sesaat tetapi tidak

terputus dan ketika pengalihan fungsi utama ke server secondary telah selesai

maka proses download akan berlanjut kembali tanpa harus memutuskan

koneksi FTP atau membangun ulang kembali koneksi layanan FTP dari awal

serta file yang di download tidak mengalami kerusakaan data sama sekali

sehingga menjamin tingkat ketersediaan tinggi dalam proses transfer data

bagi client.

Gambar 4.18 Session Website Expired

57

3. Pengujian Nilai Availability Sistem

Pengujian yang selanjutnya adalah pengujian yang mengukur tingkat

ketersediaan sistem dalam menghadapi berbagai jenis ancaman kegagalan

sistem yang mungkin terjadi, dan parameter yang menjadi acuan tingkat

ketersediaan sistem adalah nilai availability dari sistem. Untuk menghitung

nilai availability dari sistem maka diperlukan variable downtime. Downtime

yang diukur adalah waktu yang dibutuhkan oleh sistem untuk memindahkan

fungsi utama dari server primary ke server secondary hingga sistem dapat

pulih dan berjalan kembali seperti semula.

Gambar 4.19 Proses Download File

Gambar 4.20 Antrian Data Perpindahan Fungsi Utama

58

Sedangkan untuk proses penghitungan downtime-nya dapat dilakukan

dengan cara melihat hasil dari pengujian yang ditangkap menggunakan

wireshark dan kemudian akan dihitung waktu yang dibutuhkan mulai dari

server primary mengalami down hingga fungsi utama dapat berjalan kembali

di server secondary dengan baik itulah waktu downtime sistem. Kemudian

variable downtime tersebut dapat substitusikan ke dalam persamaan 2.3 untuk

menghitung nilai availability sistem.

a. Skenario Connection Lost

Skenario ini dilakukan dengan cara ketika client mengakses layanan

pada sistem kemudian kabel jaringan dari server primary dicabut dan

fungsi utama akan berpindah ke server secondary, waktu perpindahan

tersebut adalah waktu downtime sistem dan akan diukur menggunakan

wireshark kemudian dihitung nilai availability dari sistem. Dari skenario

tersebut diperoleh hasil sebagai berikut.

NO. Percobaan Elapsed Time(s) Downtime (s) Availability (%)

1 Percobaan Ke 1 600 4.011 99.3315

2 Percobaan Ke 2 600 5.818 99.0303

3 Percobaan Ke 3 600 7.010 98.8317

4 Percobaan Ke 4 600 5.818 99.0303

5 Percobaan Ke 5 600 5.818 99.0303

6 Percobaan Ke 6 600 4.013 99.3312

7 Percobaan Ke 7 600 7.016 98.8307

8 Percobaan Ke 8 600 7.013 98.8312

9 Percobaan Ke 9 600 7.011 98.8315

10 Percobaan Ke 10 600 4.016 99.3307

Rata-Rata 5.754 99.0409

Tabel 4.7 Availability Connection Lost

59

b. Skenario Power Lost

Dan untuk skenario ancaman kegagalan yang kedua adalah

kegagalan yang disebabkan oleh power untuk server primary yang

padam sehingga fungsi utama diambil alih oleh server secondary.

Penelitian ini dilakukan dengan cara client mengakses layanan yang

terdapat pada sistem kemudian kabel power dari server primary dicabut

sehingga server primary menjadi padam dan fungsi utama sistem

diambil alih oleh server secondary kemudian dihitung nilai availability

dari sistem. Dari pengujian tersebut diperoleh hasil sebagai berikut.

NO. Percobaan Elapsed Time (s) Downtime (s) Availability (%)

1 Percobaan Ke 1 600 10.013 98.3312

2 Percobaan Ke 2 600 4.014 99.3310

3 Percobaan Ke 3 600 5.880 99.0200

4 Percobaan Ke 4 600 10.014 98.3310

5 Percobaan Ke 5 600 7.011 98.8315

6 Percobaan Ke 6 600 7.010 98.8317

7 Percobaan Ke 7 600 4.015 99.3308

8 Percobaan Ke 8 600 4.012 99.3313

9 Percobaan Ke 9 600 7.014 98.3310

10 Percobaan Ke 10 600 10.872 98.1880

Rata-Rata 6.986 98.8358

c. Skenario DDOS Attack

Skenario selanjutnya adalah skenario yang menggunakan serangan

Distributed Denial of Service (DDOS) untuk melumpuhkan server

primary. Adapun aplikasi yang digunakan untuk melumpuhkan server

primary adalah Low Orbital Ion Cannon (LOIC).

Tabel 4.8 Availability Power Lost

60

Langkah pertama pasangkan aplikasi LOIC pada PC penyerang,

jumlah PC yang akan digunakan sebagai penyerang dalam skenario ini

adalah 6 unit PC agar server target menjadi lumpuh. Agar server yang

diserang bisa lumpuh lebih cepat lagi dapat dilakukan dengan menambah

jumlah PC yang akan digunakan sebagai penyerang. Setelah itu

masukkan alamat dari server yang akan diserang dalam hal ini IP

address dari server primary yaitu 192.168.1.101 kemudian tentukan

jumlah thread yang akan digunakan serta protocol yang akan diserang

dalam hal ini TCP.

LOIC bekerja dengan cara melakukan flooding atau mengirimkan

sejumlah paket berukuran besar dengan protocol tertentu kepada korban

untuk memenuhi trafik jaringan pada korban serta menguras kinerja unit

proses dari korban sehingga korban menjadi kelebihan beban kerja dan

kemudian mengalami crash sehingga lumpuh.

Gambar 4.21 Aplikasi LOIC

61

0

2

4

6

8

10

12

14

1 2 3 4 5 6 7 8 9 10

Seco

nd

s

Percobaan

Downtime

Connection Lost

Power Lost

DDOS Attack

Dari pengujian availability sistem karena serangan DDOS attack diatas

dapat diperoleh hasil sebagai berikut.

NO. Percobaan Elapsed Time (s) Downtime (s) Availability (%)

1 Percobaan Ke 1 600 7.194 98.8010

2 Percobaan Ke 2 600 6.270 98.9550

3 Percobaan Ke 3 600 5.958 99.0070

4 Percobaan Ke 4 600 5.007 99.1655

5 Percobaan Ke 5 600 12.042 97.9930

6 Percobaan Ke 6 600 5.054 99.1577

7 Percobaan Ke 7 600 10.014 98.3310

8 Percobaan Ke 8 600 7.194 98.8010

9 Percobaan Ke 9 600 7.194 98.8010

10 Percobaan Ke 10 600 10.014 98.3310

Rata-Rata 7.594 98.7343

Dari ketiga skenario pengujian kemampuan sistem dalam menghadapi

ancaman kegagalan sistem yang telah dilakukan maka dapat dibuat sebuah

grafik sebagai berikut.

Tabel 4.9 Availability DDOS Attack

Gambar 4.22 Grafik Perbandingan Lama Downtime

62

5.754

6.986 7.594

0.0

1.0

2.0

3.0

4.0

5.0

6.0

7.0

8.0

Connection Lost Power Lost DDOS Attack

Seco

nd

s

Downtime

Connection Lost

Power Lost

DDOS Attack

Dari grafik diatas dapat dilihat bahwa waktu downtime tercepat terjadi

pada skenario connection lost sedangkan waktu downtime terlama terjadi

pada skenario DDOS attack. Waktu downtime skenario power lost lebih lama

dibandingkan dengan skenario connection lost hanya karena perubahan nilai

dari kualitas media transmisi jaringan saja, tidak ada faktor lain yang

mempengaruhi secara langsung lamanya waktu downtime diantara kedua

skenario pengujian tersebut sehingga waktu downtime diantara kedua

skenario tersebut relatif sama dan perbedaan nilainya sangatlah kecil.

Sedangkan waktu downtime pada skenario DDOS attack menjadi sangat

lama bila dibandingkan dengan skenario pengujian yang lain disebabkan

karena ketika terjadi kegagalan sistem, pengiriman paket pemberitahuan

kondisi server primary yang telah crash untuk pengalihan fungsi utama ke

server secondary terhambat karena trafik pada jalur yang dilalui oleh paket

tersebut telah dipenuhi oleh paket DDOS yang berukuran sangat besar dan

berjumlah sangat banyak.

Gambar 4.23 Grafik Perbandingan Rata-Rata Lama Downtime

63

99.0409 98.8358 98.7343

0

10

20

30

40

50

60

70

80

90

100

Connection Lost Power Lost DDOS Attack

Per

cen

t (%

)

Availability

Connection Lost

Power Lost

DDOS Attack

Dalam pengujian ini variable downtime adalah variable yang sangat

menentukan besar kecilnya nilai availability dari sistem yang diuji sehingga

Dari pengujian diatas juga dapat diperoleh grafik rata-rata nilai availability

sistem sesuai dengan beberapa skenario kegagalan sistem sebagai berikut.

Ada beberapa faktor yang mempengaruhi besarnya nilai availability

sistem yaitu kecepatan koneksi jaringan dan kecepatan unit proses pada tiap-

tiap server sehingga jika menginginkan nilai availability yang lebih tinggi

lagi dapat dilakukan dengan cara menggunakan perangkat jaringan yang

dapat meningkatkan kecepatan koneksi jaringan komputer serta menambah

ukuran RAM dan kecepatan processor pada masing-masing server. Dari

grafik diatas juga dapat dilihat bahwa nilai rata-rata availability dari sistem

yang digunakan memperlihatkan hasil bahwa sistem yang digunakan dalam

penelitian ini layak untuk dipertimbangkan sebagai salah satu sistem disaster

recovery yang dapat digunakan oleh instansi.

Gambar 4.24 Grafik Perbandingan Rata-Rata Availability Sistem

64

BAB V

PENUTUP

A. Kesimpulan

Dari hasil implementasi dan analisis sistem yang telah dilakukan maka dapat

ditarik kesimpulan sebagai berikut.

Pemasangan Pacemaker dan DRBD pada server dapat menurunkan

kualitas kinerja pada layanan server yang akan digunakan seperti

meningkatnya nilai latency dan RTT pada sistem dan menurunnya nilai

throughput pada sistem. Akan tetapi penurunan kualitas kinerja ini

nilainya sangatlah kecil sehingga tidak mempengaruhi kualitas kinerja

sistem secara keseluruhan.

Data yang terdapat pada database server primary dengan database yang

terdapat pada server secondary selalu sama, termasuk perubahaan apapun

yang terjadi pada data di database juga akan selalu sama.

Sistem yang didesain dapat menjamin tingkat ketersediaan yang tinggi

untuk layanan web server. Akan tetapi jika di dalam aplikasi web terdapat

session maka ketika proses pengalihan fungsi utama ke server secondary,

session akan expired sehingga client akan terlogout otomatis. Solusi

untuk mengatasi masalah tersebut adalah dengan melakukan sinkronisasi

terhadap data session yang terdapat pada website yang digunakan.

Untuk layanan FTP server ketika terjadi kegagalan fungsi utama pada

server, proses download tidak akan terputus tetapi hanya berhenti sesaat

65

dan ketika proses perpindahaan fungsi utama ke server secondary telah

selesai maka proses download akan berlanjut kembali seperti semula

tanpa harus membuat koneksi baru dari awal.

Integrasi DRBD dan Pacemaker dapat mengatasi berbagai macam

skenario kegagalan sistem seperti connection lost, power lost dan DDOS

attack dengan nilai availability rata-rata untuk skenario connection lost

sebesar 99,0409 % dan untuk skenario power lost sebesar 98,8358 %

sedangkan untuk skenario DDOS attack sebesar 98,7343 %.

B. Saran

Beberapa saran dari penulis untuk penelitian lebih lanjut adalah sebagai

berikut.

Pada penelitian selanjutnya dapat dilakukan dengan menggunakan

jaringan WAN sebagai topologi jaringan yang akan digunakan, kemudian

kedua server yaitu server primary dan server secondary dapat dipisahkan

lokasinya secara geografis.

Perlu penelitian lebih lanjut untuk celah keamanaan saat terjadi proses

sinkronisasi data pada harddisk antara server.

Perlu penelitian lebih lanjut pada layanan server yang menggunakan

protocol UDP untuk mengetahui kemampuan sistem yang didesain dalam

menghadapi permasalahan packet loss.

66

DAFTAR PUSTAKA

Bahsyar, Irfan, R. Rumani, Yudha Purwanto. 2013. Implementasi dan Analisis

Performansi Sistem High Availability Server Menggunakan Distributed

Replicated Block Device (DRBD). Bandung: IT Telkom Bandung.

Barker, Richard. 2011. European Disaster Recovery Survey 2011. (online).

http://www.continuitycentral.com/news06044.html. Di akses pada tanggal

12 Januari 2015.

Binanto, Ilham. 2007. Membangun Jaringan Komputer Praktis Sehari-hari.

Yogyakarta: Graha Ilmu.

Brooks Charlotte, Matthew Bedernjak, Igor Jurran, John Merryman. 2002. DR

and Business Impact Analysis Planning Templates. United States of

America: RedBooks.

Calzolari, Federico. 2010. High Availability Using Virtualization. Italy:

University of Pisa.

Djearamane, Tanigaearassane & Siva Sathya. 2014. Security Challenges in

Realizing Virtual Cloud Infrastructure. India: Pondicherry University.

Don Frima, Iyoga. (2012). Implementasi Sistem Multiple-Computer Cluster

Menggunakan Linux Entreprise Real Application Cluster (LINUXERAC)

berbasis Metode Storage Area Network (DRBD) serta Analisa High

Performance dan High Availability. Depok: Universitas Indonesia.

http://www.continuitycentral.com/news06044.html

67

Faruq Muhammad, Tito Suryono. 2012. Implementasi Disaster Recovery Plan

Dengan Sistem Fail Over Menggunakan DRBD Dan Heartbeat Pada Data

Center FKIP UNS. Semarang: Universitas Negeri Semarang.

Kaufmann, Russ. Server Clustering 101- Desember 2012 -

http://www.starwindsoftware.com.

Kristianto, Endi Dwi. 2012. Clustering Komputer Server. Semarang:

IlmuKomputer.com.

Oppenheimer, Alan. 2011. Signals and Systems 2 Edition. USA: Prentice-Hall

Philipp, Reisner & Lars Ellenberg. 2005. DRBD v8 Replicated Storage with

Shared Disk Semantics.

Purnomo, Nanang. 2012. Pemanfaatan Failover Cluster Server Guna Recovery

Sistem Pada PT Lintas Data Prima. Yogyakarta: Amikom.

Pusat Bahasa. 2015. Kamus Besar Bahasa Indonesia Online. (online).

http://kbbi.web.id/. Diakses pada tanggal 8 Januari 2015

Rafsanzanie, Akbar. 2013. Disaster Recovery Planning. (online).

http://jkt92.blogspot.com/2013/03/disaster-recovery-planning.html. Diakses

pada 5 Maret 2015.

Ramakrishnan, S. 2015. An Efficient Failover Enabling Mechanism in Open

Stack. India: SRM Univesity.

http://kbbi.web.id/

http://jkt92.blogspot.com/2013/03/disaster-recovery-planning.html

68

Rosenberg, Marc J. 2006. Beyond E-Learning – Approaches and Technologies to

Enhance Organizational Knowledge, Learning, and Performance. United

States of America: Pteiffer.

Snedaker, Susan. 2007. Business Continuity and Disaster Recovery for IT

Professionals. United States of America: Syngress.

Solehuddin, Usep. 2005. Business Continuity and Disaster Recovery Plan. Depok:

Unversitas Indonesia.

Solekan. 2009. Sistem Telekomunikasi Edisi Pertama. Bandung: Politeknik

Negeri Bandung

Sovianty, Yuvirna Adiktia. 2010. Rancang Bangun Fail Over Server Berbasis

Linux Menggunakan System DRBD. Surabaya: Universitas Pembangunan

Nasional Veteran.

Syafik, Fahman. 2012. Implementasi dan Analisis Metode Failover pada Sistem

Redundant Server VoIP, Fakultas Elektro dan Komunikasi. Bandung: IT

Telkom Bandung.

Wijaya, Lustan. 2010. Pengembangan Disaster Recovery Untuk Meningkatkan

Ketersediaan Informasi Data dan Informasi pada PT XYZ. Jakarta: Binus

University.

Wiyanti Putri, Sila. 2006. Pembangunan Disaster Recovery Plan Untuk Sistem

Informasi Manajemen Terintegrasi ITB. Bandung: ITB.

L

A

M

P

I

R

A

N

INSTALLASI DAN KONFIGURASI

APACHE2, MYSQL-SERVER DAN PROFTPD

1. Konfigurasi Interface Jaringan

Langkah pertama adalah mengkonfigurasi interface jaringan pada kedua

server. Pada server primary login sebagai super user dengan mengetikkan

“su” lalu masukkan password root yang telah disetting sebelumnya pada

proses installasi Debian 7, kemudian konfigurasi jaringan komputer pada

server primary sebagai berikut ketikan “nano /etc/network/interfaces” lalu

enter dan edit isi file tersebut seperti gambar dibawah. Jika sudah selesai

simpan hasil konfigurasi dengan mengetikkan Ctrl+x lalu ketik y, setelah

itu restart interface jaringan dengan mengetikkan “service networking

restart”.

Lakukan hal yang sama pada server secondary dengan mengetikkan “su”

lalu masukkan password root dari server dan kemudian ketikan “nano

/etc/network/interfaces” dan edit isi file tersebut seperti gambar dibawah.

Jika sudah selesai simpan hasil konfigurasi dengan mengetikkan Ctrl+x

lalu ketik y, setelah itu restart interface jaringan dengan megetikan

“service networking restart”.

2. Instalasi WEB Server

Salah satu aplikasi yang akan digunakan dalam proses penelitian ini adalah

apache2. Aplikasi tersebut akan digunakan untuk layanan Web Server pada server

primary dan secondary sehingga client dapat mengakses layanan website di

jaringan.

root@primary:~# apt-get install apache2 php5 php5-mysql php5-gd

root@secondary:~# apt-get install apache2 php5 php5-mysql php5-gd

root@secondary:~# apt-get install mysql-server mysql-client

root@primary:~# apt-get install mysql-server mysql-client

root@primary:~# nano /etc/mysql/my.cnf

root@secondary:~# nano /etc/mysql/my.cnf

komputer lokal. Untuk menginstall aplikasi apache2 di server primary dan

server secondary gunakan perintah sebagai berikut ini.

3. Instalasi Database Server

Aplikasi yang akan digunakan selanjutnya adalah mysql-server, aplikasi ini

akan digunakan sebagai database server yaitu server yang akan berfungsi untuk

menyimpan semua data yang dimiliki oleh client. Untuk proses installasinya di

server primary dan server secondary gunakan perintah sebagai berikut.

Lalu akan muncul jendela yang meminta user untuk memasukkan password

dari mysql-server, isikan jendela tersebut dengan password mysql-server yang

nantinya akan digunakan untuk login ke mysql-server sebagai user root.

Kemudian konfigurasi mysql-server di kedua server agar mendengarkan IP

floating dengan cara

Lalu isi bagian my.cnf dengan menggunakan IP floating seperti berikut bind-

address = 192.168.1.103 dan ganti isi dari nilai variabel socket menjadi socket =

/var/lib/mysqld/mysqld.sock kemudian restart mysql.

root@primary:~# apt-get install proftpd

root@secondary:~# apt-get install proftpd

root@primary:~# nano /etc/proftpd/proftpd.conf

root@primary:~# service proftpd restart

root@secondary:~# service proftpd restart

4. Instalasi FTP Server

Aplikasi yang akan digunakan selanjutnya adalah proftpd, aplikasi ini akan

digunakan sebagai FTP server yaitu server yang akan berfungsi untuk file transfer

yang akan digunakan oleh client. Untuk proses installasinya di server primary dan

server secondary gunakan perintah sebagai berikut

Setelah proses instalasi selesai edit file dari proftpd untuk mengatur agar user

dapat login sebagai user anonymous dengan menggunakan perintah

kemudian tambahkan script berikut ini di bagian paling bawah dari file tersebut.

Lakukan hal yang sama pada server secondary dengan menyesuaikan parameter

yang akan digunakan sebagai user anonymous.

Kemudian simpan hasil perubahaan dari file tersebut kemudian restart FTP

server dengan menggunakan perintah.

# <Anonymous /home/pcskripsi/ > User pcskripsi UserAlias anonymous pcskripsi </Anonymous> #

root@primary:~# update-rc.d –f apache2 remove

root@primary:~# update-rc.d –f mysql remove

root@primary:~# update-rc.d –f proftpd remove

Setelah itu kemudian ketikkan perintah dibawah ini agar apache2, mysql-

server dan proftpd tidak berjalan secara otomatis saat server startup. Hal ini

dikarenakan fungsi ini nantinya akan dilakukan oleh aplikasi Pacemaker. Adapun

perintah tersebut adalah sebagai berikut.

Lakukan hal yang sama pada server secondary agar fungsi startup layanan

server diatas diambil alih oleh Pacemaker, sehingga Pacemaker lah yang akan

menjalankan fungsi dari beberapa layanan diatas tadi.

INSTALLASI DAN KONFIGURASI

DRBD DAN PACEMAKER

1. Instalasi DRBD (Distributed Replicated Block Device)

Langkah pertama yang harus dilakukan dalam proses install DRBD adalah

memberitahukan server primary dan secondary tentang keberadaan server lainnya

dengan cara edit file “/etc/hosts” seperti dibawah ini.

setelah itu lanjutkan ke proses installasi DRBD, prosesnya sebagai berikut ini.

Karena pada skenario penelitian ini akan digabungkan fungsi antara DRBD dan

Pacemaker maka ganti hak akses dari beberapa file yang terkait dengan DRBD

pada kedua server dengan menggunakan perintah berikut ini.

Lakukan hal yang sama pada server secondary agar kepemilikan dari file diatas

dapat diakses oleh Pacemaker.

127.0.0.1 localhost 192.168.0.1 primary

192.168.0.2 secondary

root@primary:~# apt-get install drbd8-utils drbdlinks

root@secondary:~# apt-get install drbd8-utils drbdlinks

root@primary:~# chgrp haclient /sbin/drbdsetup

root@primary:~# chmod o-x /sbin/drbdsetup

root@primary:~# chmod u+s /sbin/drbdsetup

root@primary:~# chgrp haclient /sbin/drbdmeta

root@primary:~# chmod o-x /sbin/drbdmeta

root@primary:~# chmod u+s /sbin/drbdmeta

Langkah selanjutnya proses konfigurasi DRBD. Lakukan modifikasi pada file

DRBD dengan mengetikkan perintah.

Kemudian edit file tersebut hingga seperti berikut.

root@primary:~# nano /etc/drbd.d/global_common.conf

root@secondary:~# nano /etc/drbd.d/global_common.conf

Lakukan konfigurasi yang sama pada server secondary atau menyalin isi file

konfigurasi diatas pada server primary ke server secondary. Proses copy dapat

menggunakan aplikasi seperti SCP dengan menggunakan perintah berikut di

terminal “scp /etc/drbd.d/global_common.conf [email protected]:/etc/drbd.d/”.

Kemudian Lakukan konfigurasi selanjutnya pada file DRBD seperti berikut ini

Dan kemudian sunting file tersebut hingga menjadi seperti dibawah ini

File tersebut digunakan untuk memberitahukan pada layanan DRBD bagian

harddisk yang akan disinkronisasikan lewat media jaringan serta IP address dan

port yang akan digunakan pada kedua server sehingga kedua server dapat saling

mengenal satu sama lain dan proses sinkronisasi data dapat terjadi. Lakukan

konfigurasi yang sama pada server secondary atau menyalin file konfigurasi diatas

pada server primary ke server secondary. Proses salin dapat menggunakan

root@primary:~# nano /etc/drbd.d/r0.res

resource r0 { protocol C;

device /dev/drbd0 minor 0;

disk /dev/sda2;

meta-disk internal; on primary {

address 192.168.0.1:7801;

} on secondary {

address 192.168.0.2:7801;

} net {

cram-hmac-alg sha1;

shared-secret novianto;

after-sb-0pri discard-younger-primary; #discard-zero-changes; after-sb-1pri discard-secondary;

after-sb-2pri call-pri-lost-after-sb;

}

}

aplikasi seperti SCP dengan perintah “scp /etc/drbd.d/r0.res

[email protected]:/etc/drbd.d/”. Setelah itu lanjutkan dengan mengetikkan

perintah dibawa ini pada server primary

Lakukan proses inisialisasi meta-data harddisk pada kedua server

Setelah itu nyalakan layanan DRBD pada kedua buah server dengan perintah

dibawah ini

Tentukan server mana yang akan bertindak sebagai server utama untuk

perangkat yang akan memuat file konfigurasi paket aplikasi serta layanan yang

akan dijalankan sebagai sistem utama. Dan juga perlu dilakukan proses

sinkronisasi penuh untuk pertama kali antara kedua server. Jalankan perintah

berikut pada server primary:

Lihat status proses sinkronisasi DRBD antara kedua server dengan

mengetikkan perintah.

Jika proses sinkronisasi sudah selesai maka selanjutnya adalah melakukan langkah

dibawah ini hanya pada server primary saja.

root@primary:~# drbdadm create-md r0

root@primary:~# /etc/init.d/drbd start

root@secondary:~# /etc/init.d/drbd start

root@primary:~# drbdadm -- --overwrite-data-of-peer primary r0

root@primary:~# cat /proc/drbd

root@primary:~# dd if = /dev/zero bs = 512 count = 512 of = /dev/sda2

root@secondary:~# drbdadm create-md r0

Terakhir lakukan langkah berikut ini pada kedua server yang dipakai

dan isi file yang diedit tersebut dengan script berikut

Kemudian restart drbdlinks pada kedua server yang digunakan pada penelitian

ini. Proses instalasi dan konfigurasi DRBD pada server primary dan server

secondary telah selesai. Dengan demikian proses penelitian yang membahas

mengenai penggunaan DRBD untuk sinkronisasi data yang terdapat pada harddisk

dikedua server sebagai sistem alternatif disaster recovery untuk instansi telah

dapat dilanjutkan.

2. Instalasi Pacemaker

Selanjutnya proses konfigurasi aplikasi Pacemaker yang akan melakukan

proses fail over jika server primary mengalami kegagalan sistem. Untuk proses

instalasi gunakan perintah.

root@primary:~# mkfs.ext4 /dev/drbd0

root@primary:~# mkdir /service

root@primary:~# mount /dev/drbd0 /service

root@primary:~# mkdir /service/www

root@primary:~# mkdir /service/mysql

root@primary:~# mkdir /service/ftp

###

root@primary:~# cp /usr/sbin/drbdlinks /etc/init.d/

root@primary:~# nano /etc/drbdlinks.conf

mountpoint('/service')

link('/var/www','/service/www')

link('/var/lib/mysql','/service/mysql')

link('/home/pcskripsi,'/service/ftp')

Lalu akan terbentuk sebuah folder dengan nama corosync di dalam folder etc.

kemudian konfigurasi pacemaker pada kedua server dengan perintah berikut ini.

Dan edit file tersebut hingga menjadi seperti dibawah ini.

root@primary:~# apt-get install pacemaker

root@secondary:~# apt-get install pacemaker

root@primary:~# nano /etc/corosync/corosync.conf

Selanjutnya akan dibuat keygen pada server primary dengan perintah berikut

Lalu salin keygen tersebut ke server secondary dengan perintah dibawah ini

Jika sudah maka restart layanan corosync pada kedua server yang digunakan

dalam penelitian ini.

Pastikan tidak terdapat error ketika proses restart corosync. Selanjutnya

lakukan proses mengkonfigurasi resource yang akan ditangani oleh cluster,

lakukan proses dibawah ini hanya pada server primary.

root@primary:~# corosync-keygen

root@primary:~# scp /etc/corosync/authkey [email protected]:/etc/corosync

root@primary:~# service corosync start

root@secondary:~# service corosync start

Lalu salin dan tempel konfigurasi dibawa ini pada jendela editor crm yang

terbuka, script dibawah ini adalah script yang berfungsi untuk mengintegrasikan

antara DRBD dan Pacemaker serta menentukkan layanan server apa yang akan

dicek oleh Pacemaker kondisinya nanti untuk proses fail over otomatis.

Script file diatas adalah script yang digunakan untuk menentukan IP floating

dari sistem yang didesain serta mendefinisikan layanan-layanan yang akan

property stonith-enabled="false"

property no-quorum-policy="ignore"

primitive ClusterIP ocf:heartbeat:IPaddr2 \

params ip="192.168.1.103" cidr_netmask="24" \

op monitor interval="30s"

primitive DBase ocf:heartbeat:mysql

primitive Links heartbeat:drbdlinks

primitive WebFS ocf:heartbeat:Filesystem \

params device="/dev/drbd0" directory="/service" fstype="ext4"

primitive WebSite ocf:heartbeat:apache \

params configfile="/etc/apache2/apache2.conf" \

op monitor interval="1min"

primitive ftp-server lsb:proftpd \

params configfile="/etc/proftpd/proftpd.conf" \

op monitor interval="1min"

primitive r0 ocf:linbit:drbd \

params drbd_resource="r0" \

op monitor interval="29s" role=”Master" \

op monitor interval="31s" role="Slave"

group WebServer ClusterIP WebFS Links DBase WebSite ftp-server

ms ms_r0 r0 \

meta primary-max="1" primary-node-max="1" clone-max="2" clone-node-max="1"

notify="true"

location prefer-primary WebServer 50: primary

colocation WebServer-with-ms_ro inf: WebServer ms_r0:Master

order WebServer-after-ms_ro inf: ms_r0:promote WebServer:start

root@primary:~# crm configure

crm(live)configure# edit

dimonitoring atau diatur oleh sistem Pacemaker. Setelah itu simpan konfigurasi

diatas dengan menekan tombol Ctrl+x lalu jawab konfirmasi penyimpanan dengan

menekan y. setelah itu jalankan konfigurasi tadi dengan perintah dibawah ini

Jika tidak ada pesan error maka lanjutkan dengan mengubah status default

dari corosync dengan perintah berikut, Lakukan perintah dibawah ini pada server

primary dan server secondary

Ganti nilai yang dimiliki oleh variabel start dari no menjadi yes kemudian

simpan file tersebut lalu restart kedua server yang digunakan. Jika semua langkah

diatas sudah dilakukan, periksa status dari sistem yang telah didesain dengan

menjalankan perintah

Jika konfigurasinya sudah benar maka semua resource akan jalan pada server

primary dan jika terjadi kegagalan sistem pada server primary maka semua

resource akan jalan pada server secondary. Proses installasi Pacemaker pada

server primary dan server secondary telah berhasil. Begitu pula dengan proses

integrasi antara DRBD dan Pacemaker yang telah berhasil menjadi satu kesatuan

sistem yang handal.

Crm(live)configure# commit

root@primary:~# nano /etc/default/corosync

root@primary:~# crm status

GAMBAR-GAMBAR HALAMAN

WEBSITE DAN FTP

Skrip Si

Documents