Upload
anto-padaunan
View
36
Download
6
Embed Size (px)
DESCRIPTION
c
Citation preview
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.3 Mekanisme Kerja Tier 1 ............................................................. 8
Gambar 2.4 Mekanisme Kerja Tier 2 ............................................................. 8
Gambar 2.5 Mekanisme Kerja Tier 3 ............................................................. 9
Gambar 2.6 Mekanisme Kerja Tier 4 ............................................................. 10
Gambar 2.7 Mekanisme Kerja Tier 5 ............................................................. 11
Gambar 2.8 Mekanisme Kerja Tier 6 ............................................................. 11
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
(Sumber : http://jkt92.blogspot.com/2013/03/disaster-recovery-planning.html)
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.
Gambar 2.3 Mekanisme Kerja Tier 1
Gambar 2.4 Mekanisme Kerja Tier 2
(Sumber : http://jkt92.blogspot.com/2013/03/disaster-recovery-planning.html)
(Sumber : http://jkt92.blogspot.com/2013/03/disaster-recovery-planning.html)
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.
Gambar 2.5 Mekanisme Kerja Tier 3
(Sumber : http://jkt92.blogspot.com/2013/03/disaster-recovery-planning.html)
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
Gambar 2.6 Mekanisme Kerja Tier 4
(Sumber : http://jkt92.blogspot.com/2013/03/disaster-recovery-planning.html)
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
Gambar 2.7 Mekanisme Kerja Tier 5
Gambar 2.8 Mekanisme Kerja Tier 6
(Sumber : http://jkt92.blogspot.com/2013/03/disaster-recovery-planning.html)
(Sumber : http://jkt92.blogspot.com/2013/03/disaster-recovery-planning.html)
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
2 Percobaan Ke 2 0.106
3 Percobaan Ke 3 0.105
4 Percobaan Ke 4 0.102
5 Percobaan Ke 5 0.104
6 Percobaan Ke 6 0.103
7 Percobaan Ke 7 0.102
8 Percobaan Ke 8 0.102
9 Percobaan Ke 9 0.106
10 Percobaan Ke 10 0.100
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)
1 Percobaan Ke 1 0.112
2 Percobaan Ke 2 0.121
3 Percobaan Ke 3 0.143
4 Percobaan Ke 4 0.101
5 Percobaan Ke 5 0.096
6 Percobaan Ke 6 0.124
7 Percobaan Ke 7 0.094
8 Percobaan Ke 8 0.093
9 Percobaan Ke 9 0.096
10 Percobaan Ke 10 0.095
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
Tanpa Sistem Dengan Sistem
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
Tanpa Sistem Dengan Sistem
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.
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.
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