IMPLEMENTASI DISASTER RECOVERY PLAN SERVER SYSTEM DENGAN METODE FAILOVER DAN MIRRORING CO-LOCATION SERVER BERBASIS LINUX DI FAKULTAS KEDOKTERAN UNISSULA
Tugas Akhir disusun untuk memenuhi syarat Mencapai gelar Kesarjanaan Komputer pada Program Studi Teknik Informatika Jenjang Program Strata -1
Disusun oleh : UDI MULYANTO SAPUTRO 12.01.63.0004 14067
FAKULTAS TEKNOLOGI INFORMASI UNIVERSITAS STIKUBANK (UNISBANK) SEMARANG 2016
i
ii
iii
HALAMAN MOTTO
Berangkat dengan penuh keyakinan. Berjalan dengan penuh keikhlasan. Istiqomah dalam menghadapi cobaan. “ YAKIN, IKHLAS, ISTIQOMAH “ ( TGKH. Muhammad Zainuddin Abdul Madjid )
Kegagalan hanya terjadi bila kita menyerah ( Lessing )
Kemenangan yang seindah – indahnya dan sesukar – sukarnya yang boleh direbut oleh manusia ialah menundukan diri sendiri. (Ibu Kartini )
“Menyesali nasib tidak akan mengubah keadaan. Terus berkarya dan bekerjalah yang membuat kita berharga” (KH. Abdurrahman Wahid)
iv
FAKULTAS TEKNOLOGI INFORMASI UNIVERSITAS STIKUBANK (UNISBANK) SEMARANG Program Studi : Teknik Informatika Tugas Akhir Sarjana Komputer Semester Ganjil Tahun 2016 Implementasi Disaster Recovery Plan Server System Dengan Metode Failover Dan Mirroring Co-Location Server Berbasis Linux Di Fakultas Kedokteran Unissula Udi Mulyanto Saputro NIM. 12.01.63.0004 Abstrak Ketersediaan backup server sangat menopang kelancaran Perguruan Tinggi dalam memberikan pelayanan dan penerapkan sistem DRP (Disaster Recovery Plan) di FK UNISSULA untuk mengamankan resiko hilangnya data karena suatu bencana dan untuk meningkatkan High Availability Data Center yang dimiliki, serta memberikan pelayanan sistem informasi akademik secara up to date. System backup konten server yang kami lakukan dengan menggunakan metodologi offsite backup server dimana merupakan metode antisipasi gangguan server dengan menempatkan server cadangan di lokasi yang berbeda dari server utama, dan sistem FailOver secara otomatis server backup akan menggantikan peran server utama apabila server utama down. Sistem failover clustering server yang dibangun dapat bekerja dengan baik berdasarkan pengujian yang telah dilakukan dimana jika salah satu server baik secara fisik maupun secara jaringan tidak dapat diakses, maka user tetap dapat mengakses data dan aplikasi server pada server backup. Proses sinkronisasi data antar server utama dan server backup dapat berjalan dengan baik dan realtime dengan memanfaatkan metode replikasi database master to master dan response time failover server dari server utama ke server backup lebih pendek dibandingan proses recovery dari server backup ke server utama. Hasil akhir dari penelitian ini adalah implementasi dengan teknik failover cluster server dengan memanfaatkan jaringan VPN ini dapat menjadi solusi Fakultas Kedokteran Unissula untuk menerapakan disaster recovery system yang aman, karena backup server dapat ditempatkan dimana saja dan dengan tingkat keamanan akses yang tinggi karena memanfaatkan jaringan private (VPN). Kata Kunci DRP, Server, Jaringan VPN, Failover Semarang : 11 Februari 2016 Pembimbing
(Saefurrohman, S.Kom, M.Cs)
v
vi
KATA PENGANTAR
Puji syukur penulis panjatkan kehadirat Allah SWT karena berkat Rahmat dan Karunia-Nya penulis dapat menyelesaikan penyusunan tugas akhir ini. Shalawat beserta salam semoga senantiasa terlimpah curahkan kepada
Nabi
Muhammad SAW, kepada keluarganya, para sahabatnya, hingga kepada umatnya hingga akhir zaman, amin. Dalam penyusunan dan penulisan tugas akhir dengan judul Implementasi Disaster Recovery Plan Server System Dengan Metode Failover Dan Mirroring CoLocation Server Berbasis Linux Di Fakultas Kedokteran Unissula dapat penulis selesaikan dan tidak terlepas dari bantuan, bimbingan serta dukungan dari berbagai pihak. Oleh karena itu dalam kesempatan ini penulis dengan senang hati menyampaikan terima kasih kepada : 1.
Dr. H. Hasan Abdul Rozak, SH., CN selaku Rektor Universitas Stikubak Semarang
2.
Dr. Drs. Yohanes Suhari, M.Msi selaku Dekan Fakultas Teknologi Informatika Universitas Stikubank.
3.
Bapak Jati Sasongko Wibowo, S.Kom., M.Cs selaku Ketua program Studi teknik Informatika
4.
Bapak Saefurrohman, S.Kom., M.Cs selaku Dosen Pembimbing yang telah banyak memberikan petunjuk, masukan dan bimbingan hingga terselesainya penulisan Tugas Akhir ini.
5.
Dosen – dosen pengampu di program Studi Teknik Informatika Fakultas Teknologi Informasi Universitas Stikubank semarang yang telah memberikan ilmu dan pengalamannya. Semoga Allah SWT memberikan balasan yang berlipat ganda kepada
semuanya.Akhirnya, hanya kepada Allah SWT penulis serahkan segalanya mudahmudahan dapat bermanfaat khususnya bagi penulis umumnya bagi kita semua. Semarang, Februari 2016 Penulis
vii
DAFTAR ISI
JUDUL ..................................................................................................................... HALAMAN PERSETUJUAN ....................................................................................... HALAMAN PENGESAHAN ......................................................................................... MOTTO ..................................................................................................................... ABSTRAKSI ................................................................................................................. KATA PENGANTAR ................................................................................................... DAFTAR ISI ................................................................................................................. DAFTAR TABEL ......................................................................................................... DAFTAR GAMBAR ..................................................................................................... BAB I
i ii iii iv v vi vii xi xii
PENDAHULUAN 1.1. Latar Belakang ................................................................................... 1.2. Perumusan Masalah ............................................................................ 1.3. Pembatasan Masalah .......................................................................... 1.4. Tujuan dan Manfaat Penelitian ............................................................ 1.5. Metodologi Penelitian ......................................................................... 1.6. Sistematika penelitian .........................................................................
1 3 3 4 6 7
BAB II
TINJAUAN PUSTAKA ............................................................................
9
BAB III
LANDASAN TEORI 3.1. Disaster Recovery Center ................................................................... 3.2. Jenis Disaster Recovery Centers ......................................................... 3.2.1. Hot Site backup ....................................................................... 3.2.2. Warm site backup ................................................................... 3.2.3. Cold site backup ...................................................................... 3.2.4. Reciprocal Agreement .............................................................. 3.2.5. Service proveider .................................................................... 3.2.6. Time Brooker .......................................................................... 3.2.7. Dual Data Center ..................................................................... 3.3. Pembagian DRC berdasarkan Lokasi .................................................. 3.3.1. Lokasi backup onsite ............................................................... 3.3.2. Lokasi backup off site ............................................................. 3.4. Disaster Recovery Plan (DRP) ............................................................ 3.4.1. Risk Assessment ..................................................................... 3.4.2. Priority Assessment ................................................................. 3.4.3. Recovery strategy selection ..................................................... 3.4.4. Plan documenting .................................................................... 3.5. Metode Failover ................................................................................. 3.6. High Availability ................................................................................ 3.7. Backup dan Recovery ......................................................................... 3.8. Server ................................................................................................ 3.9. EoIp Tunneling....................................................................................
16 16 17 17 17 18 18 18 19 19 20 21 22 23 23 24 24 25 25 26 26 27
viii
BAB IV
ANALISA DAN PERANCANGAN SYSTEM 4.1 Struktur Sistem .................................................................................. 29 4.1.1. Sentralisasi Server Aplikasi ...................................................... 29 4.1.2. Desentralisasi Server Aplikasi ................................................. 31 4.2. Desain Perancangan Sistem ................................................................ 31 4.2.1. Pengaruh failover Networking terhadap Faailover DNS ............ 31 4.2.2. Pemetaan IP Publik sebagai DNS Server ................................. 33 4.2.3. Reverse proxy yang memforward request ke vhost (IP Private) ................................................................................... 34 4.3. Konsep Manajemen Jaringan .............................................................. 36 4.4. Hierarki Fungsional dan Desain Jaringan DMZ 4.4.1. Desain jaringan berdasarkanHierarki Fungsional ..................... 37 4.4.2. Desain Jaringan DMZ .............................................................. 38 4.4.3. Desain Jaringan Captive Portal ................................................ 38 4.5. Jenis Perangkat Jaringan ..................................................................... 39 4.5.1. Perangkat Core Layer .............................................................. 39 4.5.2. Perangkat DMZ ....................................................................... 40 4.5.3. Perangkat Distribution layer .................................................... 40 4.5.4. Perangkat Access Layer ........................................................... 41 4.5.5. Perangkat Edge Layer .............................................................. 41 4.6. Analisis Kebutuhan Perangkat Keras .................................................. 41 4.6.1. Tersedianya server sebanyak 2 buah ........................................ 41 4.6.2. Router Mikrotik ....................................................................... 42 4.6.3. Switch Manageble .................................................................... 43 4.7. Analisis Kebutuhan Perangkat lunak .................................................... 43 4.8. Perancangan Topologi Jaringan .......................................................... 45 4.9. Perancangan Failover ........................................................................... 45 4.10. Perancangan Sinkronisasi Database ..................................................... 46
BAB V
IMPLEMENTASI INFRASTRUCTUR 5.1. Implementasi Virtualisasi Mesin ......................................................... 5.2. Implementasi Infrastructure Production Server Baru ........................... 5.2.1. Managed Server APPS ............................................................ 5.2.2. Managed Server Storage ......................................................... 5.2.3. Desain NFS untuk tiap mesin VM APPS ................................. 5.3. Implementasi Management Domain Name Server .............................. 5.4. Implementasi Reverse-Proxy Server ................................................... 5.5. Implementasi Backup Konten Server .................................................. 5.5.1. Metodologi Offsite Backup Server .......................................... 5.5.2. Identifikasi Kebutuhan System ................................................ 5.5.3. Identifikasi Proses Backup Server ........................................... 5.6. Skenario backup server hosting .......................................................... 5.7. Implementasi Failover dan Mirror Web Server ................................... 5.7.1. Implementasi vlan pada Captive Portal .................................... 5.7.2. Tunnel EoIp sebagai gateway failover DNS ............................ 5.7.3. Skenario Failover DNS dan Mirror server ...............................
ix
47 56 57 58 60 60 65 67 67 69 69 69 72 72 73 74
BAB VI
BAB VII
5.8. Skenario Implementasi update Aplikasi Konten dan database dengan menggunakan GITLAB .........................................................
75
PENGUJIAN SISTEM DAN MONITORING 6.1. Pengujian Sistem ................................................................................. 6.1.1. Pengujian mapping Konfigurasi Webmin ................................. 6.1.2. Pengujian mapping konfigurasi Reverse-proxy server .............. 6.1.3. Pengujian Failover DNS tiap Subdomain ................................. 6.2. Monitoring Menggunakan Tool Zabbix ...............................................
78 78 81 81 83
KESIMPULAN DAN SARAN 7.1. Kesimpulan 7.2. Saran
................................................................................... ...................................................................................
DAFTAR PUSTAKA
x
86 87
DAFTAR TABEL
Tabel 4.1 Spesifikasi Server Hosting............................................................. 29 Tabel 4.2 Spesifikasi Server Utama .............................................................. 33 Tabel 4.3 Spesifikasi Server Utama Baru ...................................................... 42 Tabel 4.3 Spesifikasi Server backup .............................................................. 42
xi
DAFTAR GAMBAR
Gambar 4.1 Skenario Reverse - Proxy........................................................... 35 Gambar 4.2 Topologi Jaringan FKUNISSULA ............................................. 37 Gambar 4.3 Jaringan DMZ .......................................................................... 38 Gambar 4.4 Captive Portal Jaringan FKUNISSULA .................................... 39 Gambar 4.5 Topologi EoIp Tunel Fkunissula ............................................... 45 Gambar 5.1 Install Proxmox ........................................................................ 48 Gambar 5.2 User License Proxmox .............................................................. 49 Gambar 5.3 Proxmox Virtualization Environment........................................ 49 Gambar 5.4 Konfigurasi Location and Time zone ........................................ 50 Gambar 5.5 Konfigurasi User and Password ................................................ 50 Gambar 5.6 Konfigurasi Name Server and IP Address ................................. 51 Gambar 5.7 Install Proxmox ....................................................................... 51 Gambar 5.8 Instalasi Proxmox selesai .......................................................... 52 Gambar 5.9 Booting by commandline .......................................................... 52 Gambar 5.10 Interface proxmox by browser ................................................ 53 Gambar 5.11 Tampilan menu proxmox ......................................................... 53 Gambar 5.12 Proxmox desentralisasi ............................................................ 54 Gambar 5.13 spesifikasi server utama ........................................................... 55 Gambar 5.14 Spesifikasi server hosting backup ............................................ 56 Gambar 5.15 Spesifikasi server APPS ........................................................... 57 Gambar 5.16 Spesifikasi storage ................................................................... 59 Gambar 5.17 Mesin storage By proxmox ...................................................... 59 Gambar 5.18 Mapping Storage mesin APPS ................................................. 60 Gambar 5.19 Aplikasi webmin ...................................................................... 62 Gambar 5.20 Konfigurasi dns fkunissula....................................................... 63 Gambar 5.21 Konfigurasi name server domain fkunissula ............................. 63 Gambar 5.22 Mapping name server sebagai dns ............................................ 64 Gambar 5.23 Mapping IP Publik DNS SERVER .......................................... 64 Gambar 5.24 Konfigurasi Virtualhost Reverse Proxy .................................... 66
xii
Gambar 5.25 Desain Implementasi Reverse Proxy ........................................ 66 Gambar 5.26 Backup Snapshot pada VM Hosting ......................................... 70 Gambar 5.27 Desain Backup Server Via ProxMox........................................ 71 Gambar 5.28 Clone Web Server Via Image Proxmox ................................... 71 Gambar 5.29 Clone Database Server Via Image Proxmox ............................. 71 Gambar 5.30 Skenario Failover dan Mirror Server ........................................ 72 Gambar 5.31 Desain Captive Portal .............................................................. 73 Gambar 5.32 Desain Update Aplikasi dengan Github.................................... 76 Gambar 5.33 Update Repository Lokal dengan Perintah “ Pull” .................... 77 Gambar 6.1 Konfigurasi IP Domain dan Subdomain ..................................... 79 Gambar 6.2 DNS Sebagai Domain Server ..................................................... 80 Gambar 6.3 Uji Coba Trace dan Ping IP DNAT ............................................ 80 Gambar 6.4 Trace vhost dan error massage ................................................... 81 Gambar 6.5 Vhost 202.91.8.149 sudah Resolve ............................................ 81 Gambar 6.6 Failover Domain Gagal Akses ................................................... 82 Gambar 6.7 Map Server Farm FKUNISSULA .............................................. 84 Gambar 6.8 Display Konfigurasi Hosts Server Farm ..................................... 84 Gambar 6.9 Remote Services( FTP,SSH,HTTP) .......................................... 85
xiii
BAB I PENDAHULUAN
1.1.
Latar Belakang Data center dan infrastruktur jaringan komputer yang berada pada suatu
wilayah tertentu tidak lepas dari kemungkinan terkena bencana seperti bencana alam yang disebabkan oleh faktor geologis dan demografis, kebakaran, baik itu faktor lingkungan atau elektrik, kesalahan manusia, maupun serangan terhadap sistem seperti virus ataupun worm atau fault sistem. Dalam membangun data center diperlukan juga suatu perencanaan backup data center utama dan pemulihan jika terjadi suatu bencana pada data center atau infrastruktur jaringan yang menyokong data center tersebut. Backup data harus dilokasi yang berbeda dengan data center utama untuk mengantisipasi bencana yang besar. Disaster Recovery Plan menurut Concil dalam “ Introdution to Disaster Recovery and Busines Continutinuity” adalah sebuah proses/kemampuan dari organisasi untuk menganggapai bencana atau gangguan dalam pelayanan melalui implementasi rencana untuk memulihkan fungsi kritis dari perusahaan. Pelaksanaan Disaster Recovery Plan dilakukan untuk melakukan perencanaan dan penangganan tentang force majeure pada data dan Infrastruktur TI yang bersifat darurat dimana tahapan yang dilakukan sesuai prosedur sehingga bisa meminimalisir kerugian organisasi dan dituntut untuk memiliki sistem yang high availability. Pada Instansi Perguruan Tinggi (PT) yang telah menerapkan Sistem Informasi (Sisfo) secara online, menghindari adanya force majeure yang dapat menimbulkan down time pada
1
server yang diakses DRP yang harus diimplementasikan dengan management yang baik. Sistem failover adalah suatu metode untuk mengatasi keadaan yang memaksa, apabila terjadi suatu kejadian yang mengakibatkan sistem utama down maka secara otomatis sistem backup yang menggantikan peran dari server utama. Mirroring server merupakan suatu metode replikasi 2 buah server, yang memungkinkan melakukan sinkronisasi antara server utama dengan server backup dengan metode Uptime, Synchronous dan Asynchronous. Dengan metode failover maka sebuah sistem dapat mendeteksi apabila server utama down maka secara otomatis mengarahkan peran server utama kepada server backup. Pada implementasi ini server utama dan server backup akan ditempatkan pada data center yang berbeda. Instansi Perguruan Tinggi (PT) merupakan salah satu instansi yang memiliki bidang layanan informasi yang kompleks. Layanan informasi tersebut diberikan tidak hanya kepada civitas akademika di lingkungan internal tetapi juga untuk alumni dan masyarakat umum memacu PT untuk memiliki sistem informasi yang baik. Oleh karena itu, FK UNISSULA menerapkan Sistem informasi berbasis online pada berbagai bidang pelayananannya. Sistem informasi sudah menjadi tumpuan kegiatan tersebut dituntut untuk selalu siap digunakan kapanpun. Sistem informasi berbasis online dibangun dengan mengandalkan infrastruktur jaringan komputer dan data center untuk menopang kinerjanya.
2
1.2.
Rumusan Masalah Berdasarkan latar belakang masalah serta kendala yang ditemukan penulis
dalam study kasus di Fakultas Kedokteran Unissula meliputi : 1.
Penerapan sistem failover pada koneksi jaringan FKUNISSULA yang memiliki 2 ISP menjadikan kendala dalam menerapkan metode failover server.
2.
Semakin berkembangnya permintaan aplikasi yang baru membutuhkan resources infrastruktur server harus mensupport aplikasi tersebut.
3.
Management DNS yang di butuhkan untuk mendifinisikan setiap aplikasi yang menggunakan IP Private.
4.
Sistem DRP (Disaster Recovery plan) yang menggunakan metode failover dns dan menggunakan reverse proxy.
1.3.
Batasan Masalah Materi yang penulis susun dalam menerapkan implementasi DRP dengan
metode miroring dan failover berdasarakan study kasus yang penulis lakukan di Fakultas Kedokteran Unissula. Tempat atau lokasi kami jadikan objek di data center FKUNISSULA, dimana di perlukan implementasi backup server untuk menjaga kelangsungan layanan informasi yang bisa diakses secara up to date oleh mahasiswa dosen dan masyarakat umum dalam mendapatkan informasi yang diperlukan. Ketersedian infrastruktur yang kami sediakan berupa server utama yang terdapat di data center Fakultas Kedokteran sendiri dan untuk backup server kami bekerjasama dengan salah satu ISP kami dimana spesifikasi yang tersedia sama dengan server utama. 3
Dalam penulisan batasan masalah maka penulis hanya akan membahas mengenai topologi jaringan yang digunakan dan metode backup data secara berkala atau dengan metode off site yang akan di terapkan dengan menggunakan OS Linux Debian. Batasan masalah penelitian adalah : 1.
Hanya membahas tentang pengenalan DRP.
2.
Membahas tentang metodologi proses backup server secara offsite yang meliputi : sinkronisasi aplikasi, data dan konfigurasi server utama.
3.
Membahas tentang desain infrastruktur jaringan yang memungkinkan untuk failover ( konfigurasi DNS ).
4.
Implementasi sinkronisasi dan backup data hanya di fokuskan pada konten server hosting saja.
1.4.
Tujuan dan Manfaat Penelitian Adapun tujuan penelitian ini adalah :
1.
Membangun sistem keamanan dan backup data akibat hacking atau pun force majeure.
2.
Meningkatkan layanan kepada customer agar kestabilan layanan informasi kemahasiswaan berjalan dengan baik.
3.
Mengurangi biaya maintance dan recovery server apabila mengalami kerusakan.
4.
Membangun monitoring untuk meningkatkan optimalisasi aplikasi untuk kelangsungan pembangunan infrastruktur.
4
Manfaat dari penelitian: Menurut penulis, kegiatan penelitian ini dapat dijadikan informasi dalam menentukan penulisan skripsi lebih lanjut. Berikut manfaat yang bisa dijadikan acuan bagi : 1.
Masyarakat Fakultas Kedokteran Unissula di jadikan penulis tempat untuk implementasi
Disaster Recovery Plan, dimana proses DRP di lakukan dengan
implementasi
backup server untuk menjaga kelangsungan layanan informasi yang bisa diakses secara up to date oleh mahasiswa dosen dan masyarakat umum dalam mendapatkan informasi yang diperlukan. Sehingga segala informasi yang masyarakat butuhkan dapat di dapatkan dengan mudah. 2.
Akademik
a.
Dalam membangun mirroring server untuk mempermudah IT administrator dalam memanaged, konfigurasi dan memaintenace server bisa dilakukan secera cepat tanpa harus terhenti apabila ada masalah dengan server utama down atau mengalami kerusakan di hardware ataupun software.
b.
Mahasiswa sebagai customer dapat mengkases segala informasi nilai ataupun melakukan aktifitas akademik kapanpun tanpa mengalami kesulitan di manapun.
3.
Penulis
a.
Penulis dapat melakukan backup server yang di sesuaikan dengan kebutuhan dari sistem IT yang ada di Fakultas Kedokteran.
5
b.
Penulis dapat dengan mudah dalam melakukan implementasi proses backup data karena sudah mengetahui topologi jaringan dan manajemen server yang ada.
1.5.
Metodologi Penelitian Pembuatan metode penelitian yang digunakan dalam penyusunan skripsi ini
meliputi: 1.
Survey Lapangan Di Fakultas Kedokteran Unissula Semarang sebagai penyedia infrastruktur
server utama dan PT. DESNET (Ruko Gombel Lama No. 31 Semarang) sebagai rekanan yang bekerjasama untuk penempatan collocation server dan penyedia jaringan internet. 2.
Studi Literatur Melakukan pengumpulan dokumen-dokumen, referensi-referensi, buku-
buku, sumber dari internet, atau sumber-sumber lain yang di perlukan untuk merancang dan membuat modul instalasidari perangakat lunak
serta untuk
mengimplementasikan system yang akan di buat. 3.
Analisa dan Perancangan Sistem Dari hasil literature dan hasil survey lapangan di jadikan penulis untuk
mendeskripsikan secara umum tentang analisa kebutuhan system, perancangan awal system yang akan dibuat, sehingga akan menghasilkan desain dan proses sistem untuk diimplementasikan. 4.
Pembuatan Sistem
6
Proses perancangan dan pembuatan sistem merupakan suatu proses yang sangat memerlukan waktu, setelah sistem jadi memerlukan pengujian, mulai kesetabilan sistem itu sendiri bagaimana dapat berkomunikasi dan metode backup nya di jalankan. 5.
Ujicoba dan Evaluasi System Pada tahapan ini sistem failover dns yang telah dibuat akan dilakukan
beberapa skenario uji coba dan evaluasi. 6.
Pada tahap ini merupakan tahap terakhir dari pengerjaan skripsi. Buku ini disusun sebagai laporan dari seluruh proses pengerjaaan skripsi.
1.6.
Sistematika Penulisan BAB I PENDAHULUAN, Pada bab ini berisi tentang deskripsi umum yang meliputi latar belakang masalah, batasan dan perumusan masalah, manfaat dan tujuan penelitian, metodologi penelitian dan sistematika penulisan. BAB II TINJAUAN PUSTAKA, Berisi uraian mengenai konsep dan teori pembelajaran yang menjadi landasan pembuatan skripsi antara lain tentang informasi hasil study kasus yang telah dilakukan sebelumnya. BAB III LANDASAN TEORI, Berisi landasan teori yang relevan dengan materi skripsi, meliputi gambaran umum dari sistem DRP dengan Metode Mirroring dan Failover pada server aplikasi konten web yang akan dibuat.
7
BAB IV ANALISA DAN PERANCANGAN SYSTEM, Metodologi dan Perancangan Sistem Failover DNS dan Mirroring Server. BAB V IMPLEMENTASI SYSTEM, Berisi penjelasan dari hasil konfigurasi dan implementasi Failover DNS dan Mirroring Server. BAB VI HASIL DAN PENGUJIAN, Uji coba konfigurasi aplikasi yang dibuat dan hasil eksekusi server. BAB VII KESIMPULAN, Berisi kesimpulan implentasi yang sudah di lakukan.
8
BAB II TINJAUAN PUSTAKA
Perencanaan pemulihan bencana cenderung menggunakan tren kontemporer dalam informasi teknologi. Meskipun perusahaan memiliki sistem informasi yang canggih di mana mereka benar-benar bergantung, rencana pemulihan bencana TI mereka mungkin terbatas back up data saja
dan merancang metode untuk
memulihkan sumber data yang diperlukan. Mengingat integrasi TI ke dalam semua fungsi bisnis dan ketergantungan pada teknologi. (Journal of Information Technology Management Volume XX, Number 4, 2009). Yuri. M., 2003, menyatakan bahwa backup data menjadi kegiatan yang harus dilakukan, pada saat ini pertumbuhan data yang tersimpan pada hardisk web sebagai data on line berbanding lurus dengan pertambahan informasi yang di sajikan, maka di butuhkan antisipasi bila terjadi kerusakan data. Kasus kehilangan atau kerusakan data dari tahun ke tahun meningkat sekitar 70% bisnis banyak kehilangan data akibat berbagai kecelakaan seperti tidak sengaja terhapusnya data, kegagalan sistem, virus, kebakaran atau bencana lainnya. Ellyani., 2012, menuliskan keadaan yang mempengaruhi backup server tergantung pada infrastructur hardware dan software dalam suatu sistem jaringan, penanganan yang dilakukan adalah dengan mengupgrade sistem dan recovery sistem. Terdapat beberapa faktor internal berupa sering nya gangguan listrik menjadi salah satu penyebab kerusakan (crass) server sehingga mengakibatkan kinerjanya terganggu baik dari sisi aplikasi maupun database. Disaster Recovery Planning 9
merupakan aktivitas yang penting dalam menjamin kelangsungan proses kegiatan recovery server yang rusak, kegiatan yang harus dilakukan adalah penyiapan dalam penyelamatan data agar proses backup data berhasil dilakukan. Afif, MF., 2012, dalam jurnalnya membahas tentang lima elemen utama yang penting untuk fungsi dasar dari sebuah data center meliputi : 1.
Aplikasi
2.
Database
3.
Server dan Operating System
4.
Jaringan
5.
Storage Array Untuk itu dalam perencanaan disaster recovery plan biasanya di utamakan
proses berhasil atau tidaknya proses penduplikasian data ke dalam media yang terpisah, data hasil duplikasi tersebut nantinya akan digunakan untuk memulihkan kembali data bila terjadi kerusakan atau kehilangan data. Backup biasanya digunakan dengan tujuan untuk memulihkan kembali data yang mengalami kerusakan / kehilangan pada saat terjadi bencana, dalam proses backup data ada beberapa jenis strategi backup antara lain: 1.
Snapshot Backup Data diduplikasi secara live dengan melakukan penguncian terhadap seluruh data untuk sementara waktu dan kemudian dilakukan snapshot terhadap data tersebut yang dilanjutkan dengan dilepas agar dapat beroperasi kembali.
2.
Full Backup Data diduplikasi secara keseluruhan baik data yang sudah pernah diduplikasi maupun belum pernah kedalam media yang terpisah. Backup dilakukan secara berkala. 10
3.
Differential Backup Data yang diduplikasi hanya merupakan data baru atau data yang mengalami perubahan. Pada proses backup ini, data tidak pernah dilakukan marking. Backup dilakukan secara berkala.
4.
Incremental Backup Data yang diduplikasi hanya data yang belum pernah dilakukan backup. Bila terjadi perbedaan byte pada data, maka hanya perbedaan dari byte data tersebut yang akan diduplikasi. Backup dilakukan secara berkala.
5.
Continuous Backup Data dilakukan duplikasi secara terus menerus terhadap seluruh data yang berubah. Selama ini di FK UNISSULA hanya menggunakan backup server pada
mesin server yang berbeda tetapi pada tempat yang sama, suatu kejadian muncul akibat terjadi bencana kelistrikan di data center yang menyebabkan terjadi kerusakan perangkat pada server utama serta infrastruktur yang lainnya. Untuk menjamin kelangsungan pelayanan yang ada dengan menggunakan Sistem informasi berbasis online. Sistem informasi ini sudah menjadi tumpuan kegiatan tersebut dituntut untuk selalu siap digunakan kapanpun. Sistem informasi berbasis online dibangun dengan menitikberatkan pada infrastruktur jaringan internet dan data center untuk menopang kinerjanya. Ketersediaan backup server sangat menopang kelancaran Perguruan Tinggi dalam memberikan pelayanan dan penerapkan sistem DRP (disaster recovery plan) di FK UNISSULA untuk mengamankan resiko hilangnya data karena suatu bencana dan untuk meningkatkan High availability data center yang dimiliki, serta memberikan pelayanan sistem informasi akademik secara up to date. System backup konten server yang kami lakukan dengan menggunakan metodologi offsite backup 11
server di mana merupakan metode antisipasi gangguan server dengan menempatkan server cadangan di lokasi yang berbeda dari server utama, dan sistem Failover secara otomatis server backup akan menggantikan peran server utama apabila server utama down. Topologi jaringan VPN yang digunakan adalah metode tunneling EoIp (Ethernet over IP) yaitu protocol yang digunakan untuk membuat terowongan / jalur (tunnel) menggunakan interface ethernet antar 2 buah router atau lebih. Syarat dari penggunaan metode ini adalah fungsi bridging pada router harus aktif, karena interface - interface pada ethernet pada router akan di-bridging dengan koneksi konfigurasi eoip. Router yang digunakan untuk implemetasi jaringan VPN EoIP adalah router mikrotik (Purnomo, N. 2012). Metode backup server dengan metode offsite dengan menempatkan server cadangan ditempat yang berbeda menjadi kerjasama kami dengan penyedia layanan internet. Kerjasama yang kami lakukan dengan penyedia layanan merupakan bentuk layanan managed server yang dilakukan guna mendukung ketersedian backup server dan infrastruktur jaringan yang akan di bangun. Co-location server kami tempatkan di data center PT. Desnet yang bekerjasama dengan kami merupakan redudant server yang identik dengan server utama dimana kami memiliki resources server utama yang terdiri dari storage, database, server hosting. Dibutuhkan resource hardware dan infrastruktur sangat besar demi menjamin kelangsungan dan ketersediaan layanan sistem informasi on line bagi mahasiswa, dosen dan masyarakat umum kami hanya membangun backup server hosting sebagai mesin aplikasi web yang menyediakan sistem informasi akademik saja yang kami miror dengan server utama kami. Managed server berupa server aplikasi webserver yang kami bangun sangat kompleks berisi tentang informasi akademik, informasi kegiatan 12
dosen dan mahasiswa, banksoal dan lainnya. Kegiatan akademik di fakultas kedokteran unissula berbeda dengan kegiatan akademik dimana aktifitas kegiatan ujian mahaasiswa sudah dilakukan dengan menggunakan Computer Based Test (CBT) dimana semua sistem apliaksi ujian dan database server sudah terintegrasi dengan server web hosting, dengan adanya sistem yang sudah terintegrasi setiap kegiatan akademik dan ujian mahasiswa bisa langsung dapat di record dan di monitoring secara on line hasil ataupun informasi kegiatan yang sedang berlangsung. Proxmox VE merupakan salah satu manajemen solusi virtualisasi yang berbasis web based lengkap untuk server. Virtualisasi server dapat dikonfigurasi dijalankan dengan maksimal, bahkan beban kerja aplikasi yang dituntut harus berjalan pada Server Linux dan Windows. Hal ini dapat dilakukan pada Proxmox karena menggunakan kernel terkemuka berbasis virtual yaitu Kernel Virtual Machine (KVM) hypervisor dan OpenVZ, yang memberikan solusi utama untuk virtualisasi berbasis container. Proxmox memberikan kinerja yang diadopsi dari teknologi bare-metal dan memiliki skalabilitas terkemuka untuk beban kerja yang padat (Hernawati, K. 2010). Kendala yang dihadapi penulis saat melakukan tahapan -tahapan penelitian yaitu Proxmox VE belum mendukung akses langsung media penyimpanan. Hal ini mengakibatkan kurang efektifnya pada saat akan melakukan maintenance. Di sisi lain juga menjadi keuntungan bagi server yaitu memberi proteksi terhadap server virtual agar tidak langsung dapat diakses dari luar host server secara fisik. Lukitasari,dkk. 2010, membahas tentang Load balancing yang merupakan suatu teknik yang digunakan untuk memisahkan antara dua atau banyak network 13
link. Dengan mempunyai banyak link maka optimalisasi utilisasi sumber daya, throughput, atau response time akan semakin baik karena mempunyai lebih dari satu link yang bisa saling mem-backup pada saat network down dan menjadi cepat pada saat network normal jika memerlukan realibilitas tinggi yang memerlukan 100% koneksi uptime dan yang menginginkan koneksi upstream yang berbeda dan dibuat saling mem-backup. Cluster Service tidak bisa dilepaskan dari layanan load balancing, dan mempunyai tujuan untuk pencegahan kegagalan layanan bagi pengguna jaringan komputer bila salah satu sistem atau aplikasi yang ada dalam jaringan komputer mengalami kegagalan. Biasanya setelah layanan load balancing ini diimplementasikan maka cluster service juga diaplikasikan untuk membuat cadangan sistem atau aplikasi yang berjalan dalam jaringan komputer. Sebuah server farm dengan mengimplementasikan layanan cluster akan meningkatkan faktor ketersediaan, reliabilitas dan juga kecepatan akses. DNS Failover adalah sistem failover yang bisa digunakan pada sistem operasi Linux dan Windows (Verryson, dkk. 2012). Prinsip kerja dari DNS failover yaitu master dan node diberi nama domain yang sama, dan nama inilah yang akan dipanggil. Jadi harus ada satu server yang berfungsi sebagai server DNS. Caranya yakni dengan membuat file dalam direktori /var/lib/bind. Kemudian dilakukan perubahan pada file named.conf.local yang terletak dalam folder /etc/bind/. Selanjutnya kedua IP klient pada jaringan local, diseting pada server DNS sehingga kedua IP tersebut berfungsi sebagai alamat dari fkunissula.ac.id. Semua client akan berhubungan dengan internet melalui server DNS. Saat client mencari alamat dengan memasukkan nama domain, maka server DNS akan memberikan salah satu dari 2 alamat IP yang didaftarkan memiliki nama yang sama. Jika IP yang 14
pertama gagal, maka akan dialihkan ke IP yang ke dua. Pada pengukuran DNS Failover dilakukan dengan perintah ping terhadap domain untuk mengecek perpindahan IP DNS yang sudah dikonfigurasikan. Jadi jika primary server mengalami gangguan, maka secara otomatis akan beralih ke IP secondary server, dan apabila primary server sudah normal kembali, maka akan dialihkan kembali ke alamat IP primary server. Ketika seorang user mengakses nama domain dari sebuah situs web, terdapat beberapa aturan yang ditetapkan (yaitu protokol), web browser memanggil nama server dan meminta mereka alamat dari mesin hosting situs web mengatakan. Setelah menerima alamat IP, maka mengirimkan permintaan ke komputer itu, bersama dengan beberapa data tambahan dan membuat respon .Sejak DNS memungkinkan beberapa catatan untuk disimpan (bahkan jenis yang sama), maka ada kemungkinan untuk daftar beberapa host sebagai server. Oleh karena itu, seperti yang ditunjukkan pada skema di atas, jika Anda daftar alamat IP dari 2 beban balancer / reverse- proxy, yang terletak di dua lokasi yang berbeda, masing-masing set untuk menyeimbangkan beban antara server aplikasi, lagi terletak di setidaknya dua data- berbeda pusat, jika salah satu dari data - pusat menjadi tidak terjangkau, klien web browser akan mencoba catatan alamat IP berikutnya dikembalikan oleh server DNS dan ulangi proses untuk mendapatkan situs web. Proses dalam meningkatkan High - Availability service tergantung dengan provider sebagai menyediakan
dedicated network dimana link dan kapasitas
network sangat mempengaruhi dalam proses backup data dan loadbalancing aplikasi yang sedang berjalan.
15
BAB III LANDASAN TEORI
3.1.
Disaster Recovery Center ( DRC) Disaster Recovery Center (DRC) adalah merupakan suatu metode backup off
site data center atau lokasi pengganti operasional data center atau lokasi pengganti server pengolah data. Saat Disaster recovery Center dioperasikan apabila terjadi disaster sebagian atau total pada data center utama yang mengalami waktu yang lama dalam recovery tak dapat diprediksi, sedangkan suatu pelayanan harus segera kembali beroperasi. Diperlukan komitmen manajemen dan stackeholder dalam menyediakan DRC karena perusahaan harus mengeluarkan anggaran biaya yang cukup tinggi sementara perannya tak pasti waktu terjadinya. Oleh karenanya tak heran apabila banyak dijumpai lokasi server yang tidak secara kontinuitas di lakukan maintenance yang dilakukan, dimana hanya dijadikan formalitas untuk memenuhi kewajiban. (Irianto, M., 2013)
3.2.
Jenis Disaster Recovery Center ( DRC) Perencanaan DRC merupakan salah satu upaya dalam melakukan
perencanaan lanjutan guna mempercepat recovery. Oleh karenanya DRC sangat penting perannya dalam mendukung kontinuitas operasional data center. Kontinutias operasional
tergantung pada kelanjutan operasional pada data center. Semakin
banyak aplikasi yang dibackup semakin besar biaya yang diperlukan untuk membangun DRC. Semakin singkat waktu recovery yang diharapkan, semakin besar
16
biaya yang diperlukan. Biaya yang diperlukan dalam recovery berbanding terbalik dengan waktu penyelesaian recovery. (Irianto, M., 2013). Karena alasan biaya tersebut, terdapat banyak pilihan jenis DRC antara lain : 3.2.1. Hot Site Backup Merupakan salah satu jenis
DRC yang paling siap dioperasikan sistem
backup aplikasi terpilih untuk menggantikan peran data center bilamana diperlukan. Kesiapan hot site backup meliputi ketersediaan dan kesiapan infrastruktur pendukung, hardware / software, aplikasi kritis, data terakhir, dan jaringan komunikasi data. Karena kelengkapan dan kesiapannya, pembangunan hot site backup membutuhkan biaya tinggi atau paling mahal diantara jenis backup lainnya. 3.2.2. Warm site backup Adalah salah satu jenis DRC dimana fasilitas yang disediakan tidak selengkap pada hot site backup. Kecuali server, infrastruktur pendukung dan jaringan komunikasi data sudah diinstal dan sudah diuji efektifitasnya. Apabila terdapat kekurangan suatu perangkat, perangkat tersebut harus mudah diperoleh ketika terjadi kondisi emergency. Intinya, warm site backup dalam posisi siap running ketika diperlukan untuk mendukung operasional suatu server. 3.2.3. Cold site backup DRC ini merupakan jenis yang paling sederhana, belum ada instalasi infrastruktur pendukung kecuali outlet listrik. DRC jenis ini tidak siap running layaknya kedua jenis backup sebelumnya. Konsekuensinya, waktu yang diperlukan untuk melaksanakan recovery sangat lama. Tidak disarankan untuk industri perbankan. Karena kesederhanaannya, cold site backup sebenarnya dapat juga
17
menggunakan kamar hotel, bahkan rumah tinggal bila perlu karena fasilitas yang disiapkan sama. 3.2.4. Reciprocal Agreement Merupakan perjanjian timbal balik antar pihak-pihak untuk menyediakan fasilitas data center-nya kepada pihak lain, yang data centernya mengalami gangguan. Pelaksanaan pengolahan data dapat dilakukan setelah tuan rumah selesai melakukan proses. Pilihan alternative ini lebih tepat untuk data center yang menggunakan server sekelas PC. Kurang tepat untuk data center besar karena kemungkinan system computer antar pihak-pihak tidak compatible. 3.2.5. Service Provider Suatu Perusahan atau biro penyelenggara dan penyedia jasa layanan Internet dan data center. Service provider menyediakan seluruh infrastruktur yang dibutuhkan untuk operasional data center, termasuk jaringan komunikasi data. Alternatif layanan yang disediakan oleh provider antara lain jasa penitipan server (co-location), atau berikut dengan menyewakan server-nya (dedicated server), atau menyewakan virtual server (Virtual Private Server). Service provider saat ini banyak melayani jasa bidang hosting internet. 3.2.6. Time Brooker Menyediakan jasa penyediaan computer extra dalam waktu singkat namun terbatas hanya untuk perusahaan kecil / kantor cabang yang membutuhkan komputer jenis PC atau infrastruktur yang sifatnya umum. Waktu recovery cukup lama karena diperlukan waktu untuk melakukan setup komputer dan restore data terlebih dahulu sebelum dioperasikan, kurang tepat untuk industri perbankan.
18
3.2.7. Dual Data Center Perkembangan ke depan, DRC tidak cukup hanya menyediakan backup khusus aplikasi kritis saja tetapi juga menyediakan backup untuk semua aplikasi tanpa kecuali dalam bentuk dual data center. Kedua data center tersebut beroperasi secara bergantian dan saling membackup diantara keduanya. Melalui konfigurasi mirroring, database kedua data center tersebut mendekati kesamaan karena data transaksi pada server produksi di transfer ke server backup secara periodik. Semakin rapat frekuensi transfer batch data antar server, semakin kecil selisih data diantara keduanya. Untuk memitigasi selisih data diantara kedua server, switch over data center sebaiknya dilakukan pada tengah malam. Apabila ada perbedaan / selisih data, perbedaan itu tidak signifikan. Dengan demikian dual data center merupakan solusi ideal dalam menjaga kontinuitas operasional data center dari ancaman disaster.
3.3.
Pembagian DRC berdasarkan Lokasi Berdasarkan hasil evaluasi dan petimbangan biaya, maka dapat ditentukan
alternative backup data center. Ada dua jenis lokasi backup data center yakni on site backup dan off site backup. 3.3.1. Lokasi backup On site Backup on site dikembangkan dengan menggunakan komputer versi lama/ versi sebelum diganti dengan versi baru. Tujuan pembangunan lokasi backup on site adalah untuk mempercepat proses recovery apabila terjadi kegagalan proses pada komputer utama/produksi. Hal ini memungkinkan karena antara komputer utama dan backup menggunakan infrastruktur dan konfigurasi yang sama. Karena itu 19
backup on site disebut juga sebagai hot site backup. Agar proses recovery berjalan cepat, kedua komputer harus memiliki kesamaan dalam : a)
Versi dan release operating system
b)
Data aplikasi kritis miroring
c)
Jenis drive storage, apabila diperlukan restore data (karena backup data tidak mirroring).
d)
Jenis port komunikasi data. Keuntungan pembangunan lokasi backup on site adalah
a)
Biaya pembangunan lebih murah karena menggunakan jaringan dan infrastruktur yang sama.
b)
Backup data transaksi lebih mudah dilakukan bahkan secara real time / mirroring karena server utama dan server backup berada pada LAN/ VLAN yang sama.
c)
Koordinasi tim recovery lebih mudah karena lokasi recovery ada di data center, lokasi yang tidak asing bagi tim recovery.
d)
Waktu recovery relatif lebih singkat karena hanya mengganti IP komputer backup menjadi IP server utama dan memindahkan routing. Adapun yang perlu diwaspadai penempatan backup di lokasi on site berisiko
terhadap : a)
Disaster major seperti gempa bumi, kebakaran, kelistrikan yang efeknya merusak data center.
b)
Gangguan jaringan komunikasi data dan infrastruktur yang digunakan bersama.
20
3.3.2. Lokasi backup off site Sama dengan backup on site, backup off site juga dapat dibangun dengan memanfaatkan komputer seri sebelumnya dengan catatan adanya kesamaan pada : a)
Versi dan release operasting system
b)
Jenis tape drive, apabila diperlukan restore data karena
data tidak
mirroring. c)
Jenis port komunikasi data. Walaupun jarak lokasi antara kedua komputer berjauhan, tidak tertutup kemungkinan proses backup data dilakukan secara mirroring. Kecepatan recovery bukan lagi ditentukan oleh jarak tetapi oleh kelengkapan dan kesiapan DRC. Disamping itu lokasi backup off site seharusnya memiliki tingkat keamanan yang lebih tinggi dari data center, baik dari aspek geografi, sosial, maupun politik. Oleh karena itu lokasi backup off site tidak terbatas pada satu pulau atau negara tetapi dapat ditempatkan di luar negeri bila perlu. Penempatkan backup di lokasi off site dengan jarak antara 30-50 Km,
bertujuan memitigasi risiko ancaman bencana alam yang sama dengan bencana yang mengancam data center, seperti banjir, gempa bumi, tsunami dan lain sebagainya. Dengan jarak sejauh itu diharapkan dampaknya tidak saling mengganggu.Namun demikian bentangan jarak yang jauh saja tidak cukup untuk memitigasi risiko disaster, harus diperhatikan jarak antara loaksi DRC terhadap lokasi pusat bencana seperti kawasan bekas rawa, daerah aliran sungai, sepanjang pesisir utara Pulau Jawa yang rawan terhadap rob / air pasang, atau sepanjang pesisir selatan Pulau Jawa yang rawan terhadap gempa dan tsunami. 21
3.4.
Disaster Recovery Plan (DRP) Disaster Recovery Plan adalah prosedure yang dijalankan secara otomatis
atau pun manual yang dirancang untuk mengurangi ancaman terhadap fungsi-fungsi penting, sehingga menjamin kontinuitas layanan bagi operasi yang penting dan berlangsungnya langkah-langkah untuk penyelamatan dan pemulihan (recovery) khususnya terhadap fasilitas IT dan sistem informasi. Disaster Recovery Plan merupakan pengaturan yang komprehensive berisikan tindakan-tindakan konsisten yang harus dilakukan sebelum, selama, dan setelah adanya kejadian (bencana) yang mengakibatkan hilangnya sumber daya sistem informasi secara bermakna. DRP berisikan prosedur untuk merespon kejadian emergensi, menyediakan operasi backup cadangan selama sistem terhenti, dan mengelola proses pemulihan serta penyelamatan sehingga mampu meminimalisir kerugian yang dialami oleh organisasi. Tujuan utama dari Disaster Recovery Plan adalah untuk menyediakan kemampuan atau sumber daya untuk menjalankan proses vital pada lokasi cadangan sementara waktu dan mengembalikan fungsi lokasi utama menjadi normal dalam batasan waktu tetentu, dengan menjalankan prosedur pemulihan cepat, untuk meminimalisir kerugian organisasi. Karena bertindak sebagai pegangan saat terjadi keadaan darurat, Disaster Recovery Plan tidak dapat disusun secara sembarangan. Disaster Recovery Plan yang tidak sesuai dapat berakibat lebih buruk bagi keberlangsungan organisasi daripada bencana itu sendiri (SW. Putri, 2008). Disaster Recovery Planning merupakan proses bertahap yang tersusun secara metodikal. Tahapan pembangunan sebuah Disaster Recovery Plan tidak selalu sama, karena sangat bergantung pada kebutuhan dan tujuan pembuatannya. Namun secara garis besar, tahapan tersebut dapat dirangkum sebagai berikut: 22
3.4.1. Risk assessment Risk Assessment adalah suatu proses identifikasi ancaman-ancaman yang mungkin terjadi, baik yang berasal dari dalam, maupun dari luar. Bencana yang dianalisa termasuk bencana alam, bencana kegagalan teknis, maupun ancamanancaman faktor manusia. Risk Assessment berperan penting untuk keberlangsungan pembangunankeseluruhan Disaster Recovery Planning karena dapat dianggap sebagai landasanawal yang akan mempengaruhi tahapan-tahapan selanjutnya. Risk Assessment biasanya diikuti dengan Impact Analysis, dimana kemungkinan kemungkinan bencana yang sudah teridentifikasi kemudian dianalisis dampaknya. 3.4.2. Priority Assessment Saat suatu bencana terjadi dan mengganggu berbagai macam proses bisnis dan operasi, sangatlah penting untuk memiliki urutan prioritas proses yang jelas. Prioritas dapat diurutkan berdasarkan banyak hal. Dari segi arsitektur misalnya, server / router manakah yang menjadi prioritas dalam dipulihkan?, Data mana yang harus lebih dahulu diselamatkan? Begitu juga dengan proses, prioritas pemulihan harus terurut dengan jelas. Proses yang dianggap paling vital untuk keberlangsungan sistem nantinya akan mendapatkan alokasi perhatian paling besar untuk dipulihkan kembali sebelum proses-proses lainnya. Dengan demikian tujuan dari pembangunan Disaster Recovery Plan, yaitu untuk memastikan sistem dapat berfungsi sebaik mungkin secepat mungkin setelah gangguan suatu bencana, dapat terlaksana. Priority Assessment untuk proses biasanya sangat relatif terhadap waktu dan tempat terjadinya suatu bencana. Suatu sekolah misalnya, jika bencana terjadi pada saat penerimaan mahasiswa baru, proses yang pertama kali harus dipulihkan mungkin 23
adalah proses terkait tes masuk dan pembayaran. Tidak demikian jika bencana terjadi saat liburan, dimana kebanyakan proses akan berada dalam kondisi statis, dan mungkin hanya akan berfokus pada penyelamatan data saja. Karena penentuan prioritas pada tahap ini sangat krusial dan berkaitan dengan eksekusi Disaster Recovery Plan di lapangan nantinya bila terjadi bencana, tahapan ini harus dilakukan dengan hati-hati dan melalui berbagai macam pertimbangan yang matang. 3.4.3. Recovery strategy selection Pemilihan strategi pemulihan haruslah dipertimbangkan dengan seksama. Strategi pemulihan yang baik harus memenuhi beberapa kriteria, yaitu: a.
Strategi pemulihan harus memenuhi key requirement yang sudah didefinisikan di tahap sebelumnya.
b.
Strategi pemulihan harus cost effective berbanding dengan risiko dan prioritasnya.
c.
Strategi pemulihan harus dapat diterapkan dengan kondisi yang terdapat sekarang dan memungkinkan untuk ditingkatkan jika teknologi atau bisnisyang terkait berkembang di masa depan. Strategi pemulihan yang sudah dirancang kemudian harus dituangkan ke
dalam Disaster Recovery Plan yang terdokumentasi secara baik sehingga dapat dengan mudah dilaksanakan jika suatu saat terjadi bencana. 3.4.4. Plan documenting Hasil analisa dan rancangan strategi yang sudah dihasilkan dari tahapantahapan sebelumnya tidak akan berarti apa-apa jika tidak terdokumentasi dengan baik. Saat terjadi bencana, personel-personel yang mengerti benar akan Disaster Recovery Plan yang sudah dirancang mungkin tidak akan sepenuhnya 24
tersedia, atau bahkan sudah tidak aktif di organisasi tersebut. Karena itu Disaster Recovery Plan haruslah didokumentasikan dengan terstruktur sehingga mudah dipahami saat dibutuhkan. Tersedia berbagai macam standar untuk mendokumentasikan sebuah Disaster Recovery Plan. Toolkit dan pedoman-pedoman penyusunan dokumen Disaster Recovery Plan pun banyak tersedia. Dalam pengerjaan tugas akhir ini, Disaster Recovery Plan yang dirancang akan didokumentasikan sesuai dengan kebutuhan.
3.5.
Metode Failover Failover adalah proses peralihan atau alih fungsi dari sebuah server utama ke
server cadangan atau backup yang berupa: elemen atau sistem operasi. Mekanisme failover dapat dirancang sehingga dapat sesegera mungkin dapat di lakukan setelah gangguan muncul. Metode backup data sangat menopang kelancaran Perguruan Tinggi dalam memberikan pelayanan dan penerapkan sistem DRP (Disaster Recovery Plan) di FK UNISSULA untuk mengamankan resiko hilangnya data karena suatu bencana dan untuk meningkatkan High availability data center yang dimiliki, serta memberikan pelayanan sistem informasi akademik secara up to date.
3.6.
High Availability Metode Failover menyediakan solusi high availability server dimana jika
terjadi kegagalan pada sistem hardware seperti power supply mati yang menyebabkan server mati, dengan secara otomatis fungsi dari dns server akan mengambil alih fungsi dari server yang mati, sehingga pada saat user mengakses 25
webserver tidak mengetahui jika terjadi kegagalan akses pada server utama, karena proses yang dilakukan pada server utama yang gagal atau mati akan dilanjutkan oleh server backup. Untuk menjadi high available dalam layanan maka fungsi failover menjadi peran utama dalam menjaga kestabilan dan kontinuitas saat salah satu server mengalami masalah.
3.7.
Backup dan Recovery Backup data merupakan salah satu kegiatan pengelola database untuk
melakukan penyalinan sistem, data dan aplikasi. Backup data harus dilakukan untuk menjaga jangan sampai terjadi kerusakan sistem dari luar ataupun dari dalam sistem, yang disengaja atau pun tidak disengaja. Recovery adalah proses mengembalikan backup ke dalam sistem pasca terjadi kerusakan. Recovery dilakukan untuk mengembalikan keadaan sistem kembali pada keadaan semula, keadaan terakhir pada saat operasional, sebelum terjadi kerusakan sistem.
3.8.
Server Server adalah sebuah sistem komputer yang menyediakan jenis layanan
tertentu dalam sebuah jaringan komputer (Wahana Komputer,2008). Server didukung dengan prosesor yang bersifat scalable dan RAM yang besar, juga dilengkapi dengan sistem operasi khusus, yang disebut sebagai sistem operasi jaringan atau network operating system. Server juga menjalankan perangkat lunak / software administratif yang mengontrol akses terhadap jaringan dan sumber daya
26
yang terdapat di dalamnya, seperti halnya berkas atau alat pencetak (printer), dan memberikan akses kepada workstation anggota jaringan.
3.9.
EoIP Tunneling Ethernet over IP (EoIP) Tunneling adalah sebuah protocol Mikrotik
RouterOS yang digunakan membuat jalur tunnel melalui interface ethernet diantara dua router dengan menggunakan koneksi IP. Protokol EoIP digunakan untuk melakukan bridging antar LAN (Local Area Network) melalui koneksi internet, dengan memanfaatkan tunnel antar router mikrotik, sehingga dengan jalur tunel yang sudah di buat dapat terjalin interkoneksi dari WAN ataupun LAN antar tiap server .
27
BAB IV ANALISA DAN PERANCANGAN SYSTEM
Fakultas Kedokteran merupakan fakultas yang mandiri mempunyai jaringan internet dan data center sendiri yang terpisah dengan Unissula sebagai lembaga pendidikan yang menaungi semua fakultas yang ada di bawahnya. Fakultas Kedokteran mempunyai layanan internet sendiri untuk memfasilitasi mahsiswa, dosen dan karyawan yang dalam kegiatan akademik dan pelayanan membutuhkan koneksi internet untuk mencari sumber belajar atau untuk mendapatkan informasi akademik melalui Fakultas Kedokteran. Saat ini Fakultas Kedokteran mempunyai 5 PRODI ( Prodi PPSK, Prodi PPPD, Prodi S2 Biomedik, Prodi Farmasi, Prodi Kebidanan) dimana mempunyai fasilitas pelayanan tempat yang terpisah, hampir semua prodi kami fasilitasi layanan internet dengan akses hotspot yang mudah di akses dan tersebar disemua spot aktifitas mahasiswa belajar (Ruang Kelas, Perpustakaan, Laboratorium Klinik baik yang di tiap-tiap gedung atau pun Laboratorium yang ada di Rumah Sakit Islam Sultan Agung) dan berdiskusi mencari sumber belajar atau yang lainnya. Semua akses internet dan SIA (Sistem Informasi Akademik) yang ada di managed dan terkontrol dalam satu tempat di datacenter yang tercentaralisasi baik berupa fisik perangkat internet berupa hardware yang berupa mesin server dan core mesin server gateway network dan switch managable serta software yang berupa windows server, Mssql dan Debian Linux yang di install dan terkonfigurasi di setiap mesin. Untuk melayani kebutuhan layanan koneksi internet kami mempunyai 2 ISP yang bekerja sama dengan kami antara lain PT. TIME EXELINDO dan PT. DESNET sebagai penyedia internet juga sebagai patner 28
kami dalam menempatkan co-location server yang digunakan sebagai backup server yang kami rancang untuk mirror server utama yang kami punya untuk perancangan Disaster Recovery Plan.
4.1.
Struktur Sistem
4.1.1. Sentralisasi server aplikasi Pada saat sebelum pengembangan sistem informasi seperti saat ini yang sudah terpisah sistem aplikasi dan server masing – masing di setiap prodi, Fakultas Kedokteran masih menggunakan desentralisasi sistem aplikasi yang ditempatkan dan di konfigurasikan di satu server hosting. Server hosting tersebut di alokasikan sebagai server utama untuk domain www.fkunissula.ac.id , dimana operating systemnya menggunakan linux debian 6.0. Mesin server hosting khusus digunakan untuk melayani aplikasi domain dan subdomen fkunissula.ac.id, website aplikasi menggunakan joomla yang desain dan fitur content sesuai dengan standart yang ada di unissula untuk managemen domainnya menggunakan ISPCP. Spesifikasi server hosting : Tabel 4.1 Spesifikasi Server Hosting Hardware Mainboard Processor Memory Hardisk NIC
Tipe
ukuran
Intel Intel AMD Opteron Proccesor 4130 8 DIMM 2.5 SATA Raid 2 , PERC H800 Dual-port Broadcom 5716 Gigabit NIC
8GB 200 GB
Server hosting ini memiliki kapasitas storage 200 GB dimana setiap periode akademik banyak aktifitas upload data pada domain fkunissula semakin meningkat apalagi
dengan
adanya
subdomain 29
banksoal.fkunissula.ac.id
dan
rotasikoas.fkunissula.ac.id yang semua datanya tersimpan di database mysql yang terinstalasi di server tersebut, sehingga semakin berkembangnya sistem aplikasi, kebutuhan storage yang tersedia sudah tidak memadai dan di butuhkan resource memory yang besar pula agar domain dan subdomain dapat diakses secara cepat. www.fkunissula.ac.id merupakan web aplikasi online yang diakses mahasiswa sebagai customer utama untuk mendapatkan segala macam informasi akademik kapan pun dan dimana pun bisa dengan mudah di akses. Kendala yang terjadi di fakultas kedokteran unissula adalah sering terjadinya gangguan kelistrikan yang kadang bisa mati seharian, backup power yang tersedia hanya mampu mengcover selama 1 - 2 Jam saja. DRP dengan co-location server menjadi prioritas utama dimana penempatan server backup di tempatkan di datacenter rekanan ISP kami PT. Desnet yang menjamin ketersediaan backup power. Penempatan VPS dengan spesifikasi storage dan memory didesain sebagai backup aplikasi saat server utama down karena gangguan kelistrikan. Tapi karena kebutuhan resource untuk menampung data di server utama semakin berkembang maka VPS backup server pun juga di butuhkan penambahan resource yang sama. Itu yang menjadi dasar untuk mengembangkan sistem cluster server agar kebutuhan storage dan sistem aplikasi bisa di analisis. 4.1.2. Desentralisasi Server Aplikasi Desain struktur sistem aplikasi baru dengan desentralisasi server yang terbagi kedalam cluster server merupakan solusi yang saat ini di terapkan sebagai bentuk optimalisasi implementasi datacenter di FK UNISSULA dengan memisahkan antara server aplikasi dan server storage tersendiri dengan mapping dan konfigurasi yang berbeda di setiap cluster virtual mesinnya. Nantinya sistem aplikasi yang 30
terdapat di server hosting akan di mapping kan pada virtual mesin – virtual mesin sesuai dengan domain masing prodi. Setiap prodi akan memiliki virtual mesin sendiri untuk sistem aplikasi yang akan dibangun seperti Akademik
Program
Study
PPSK
:
Sistem Informasi
sia.fkunissula.ac.id
dan
website:
ppsk.fkunissula.ac.id di mana akan memudahkan dalam memanage aplikasi yang akan di kembangkan. Kebutuhan resources server untuk membangun cluster server tersebut.
4.2.
Desain Perancangan Sistem
4.2.1. Pengaruh failover networking terhadap failover DNS Menurut analisa penulis, penerapkan konfigurasi dan topologi yang lama dengan mengunakan metode loadbalancing pada konfigurasi Routerboard 1100AH berbasis mikrotik v4.17 sering mengalami permasalahan dengan resources load cpu yang terpantau 100% . Untuk mendukung ketersediaan koneksi jaringan di Fakultas Kedokteran Unissula yang banyak pengadaan infrastuctur seperti Acces point, switch, dan pengembangan penempatan akses point guna menempat spot-spot dimana kegiatan mahasiswa terpusat. Setiap tahun penerimaan mahasiswa baru semakin bertambah pula pengguna internet di Fakultas Kedokteran, sehingga permasalahan yang terjadi meliputi kebutuhan kapasitas internet, sistem aplikasi sebagai
media
infotmasi
mahasiswa dan infrastruktur
untuk mendukung
ketersediaannya. Routerboard 1100AH yang di konfigurasikan menjadi Edge Layer + Captive portal pada saat itu menjadi pilihan untuk memanaged bandwitdh dan management user, bertambahnya pengguna internet menjadikan load cpu perangkat Routerboard 1100AH semakin tinggi yang menyebabkan penurunan performa 31
layanan koneksi internet. Permasalahan tersebut yang menjadikan pertimbangan dalam menentukan pengantian Routerboard 1100AH menjadi virtual mesin sendiri – sendiri. Saat ini semua perangkat Edge Layer + Captive portal dikonfigurasikan dalam satu mesin server, dimana menjadi VM Gateway dan VM Captive Portal yang menggunakan mikrotik v5. Pertimbangan kenapa konfigurasi edge layer dan core layer di konfigurasikan di virtual mesin bukan di Perangkat Router Cisco atau Routerboard menurut penulis dalam implementasi jaringan dan lebih menghemat resoursces.
Dalam
perencanaan
pengembangan
datacenter
yang
meliputi
implementasi jaringan dan lebih menghemat resoursces. Dalam perencanaan pengembangan datacenter yang meliputi implementasi jaringan dan managemen server membutuhkan infrastructur yang mendukung. Untuk mendukung ketersediaan koneksi jaringan di Fakultas Kedokteran Unissula yang banyak pengadaan infrastuktur seperti Acces point, switch, dan pengembangan penempatan akses point guna menempat spot-spot dimana kegiatan mahasiswa terpusat. Setiap tahun penerimaan mahasiswa baru semakin bertambah pula pengguna internet di fakultas kedokteran, sehingga permasalahan yang terjadi meliputi kebutuhan kapasitas internet, sistem aplikasi sebagai media infotmasi mahasiswa dan infrastruktur untuk mendukung ketersediaannya. Routerboard 1100AH yang di konfigurasikan menjadi Edge Layer + Captive portal pada saat itu menjadi pilihan untuk memanaged bandwitdh dan management user, bertambahnya pengguna internet menjadikan load cpu perangkat Routerboard 1100AH semakin tinggi yang menyebabkan penurunan performa layanan koneksi internet. Permasalahan tersebut yang menjadikan
32
pertimbangan dalam menentukan pengantian Routerboard 1100AH menjadi virtual mesin sendiri – sendiri. 4.2.2. Pemetaan IP Publik sebagai DNS Server FK UNISSULA bekerjasama dengan 2 ISP dalam pelayanan penyediaan koneksi internet, dimana masing - masing penyedia internet mempunyai layanan sebesar 40 Mbps. Pada awal pengembangan sistem dan jaringan internet, web www.fkunissula.ac.id masih menggunakan 1 mesin server yang menggunakan DNS IP Publik dari PT. TIME EXELINDO saja. Spesifikasi server utama sebagai berikut: Tabel 4.2 Spesifikasi server Utama Hardware Mainboard Processor Memory Hardisk NIC
Tipe
ukuran
Intel Intel (R) Xeon CPU E5-2420 @1,90GHz 4 DiMM 2.5 SATA Raid 2 Broadcom BMC5790c Quad Port NIC
4GB 100 G
Mesin server ini hanya digunakan untuk aplikasi web fkunissula.ac.id saja dimana
untuk
database
nya
menggunakan
mysql,
managed
domainnya
menggunakan ispcp sebagai dns server ataupun managed seluruh subdomain yang ada, aplikasi websevernya menggunakan jomla yang disesuaikan dengan custom dan template dari unissula, menggunakan operating system berbasis linux debian untuk menopang akses webservernya. Domain www.fkunissula.ac.id teregister di PANDI dengan hanya menggunakan IP DNS dari PT. Time Exelindo. Sebagai bentuk layanan yang berbasis online menuntut agar layanan informasi bisa diakses kapanpun dan dengan menggunakan perangkat apapun, sehingga proses dalam meningkatkan High - availability service tergantung dengan provider sebagai
33
menyediakan
dedicated network dimana link dan kapasitas network sangat
mempengaruhi dalam proses backup data dan loadbalancing aplikasi yang sedang berjalan dan juga tergantung dengan backup power saat terjadi force majur misal mati listrik. Ini yang menjadi kendala saat ini karena menggunakan single link dari satu proveider pada saat mengalami downtime semua akses web hosting mengalami tidak dapat diakses, sehingga pelayanan sistem informasi juga tidak berjalan sesuai dengan perencaanaan yang sudah ditetapkan. Apabila mengalami downtime sekian waktu banyak aktivifitas akademik online yang tertunda misal: pengisian krs online, pengumuman akademik, download materi kuliah dan lainnya, mahasiswa sebagai user atau pengguna informasi online akan menuntut stackholder atas ketersedian layanan informasi secara uptime. Solusi utama yang harus segera dilakukan memanaged service pemanfaatan layanan 2 ISP sebagai metode failover IP DNS dan managed domain dengan menggunakan IP aliasing sebagai penerjemah dari setiap mesin server domain yang tersedia. Dalam development infrastructur dengan meyediakan mesin dan konfigurasi dns server yang nantinya failover dns dari 2 ISP bisa berjalan saaat terjadi downtime dari salah satu penyedia layanan link internet. 4.2.3
Reverse proxy yang mem-forward request ke vhost (dengan Ip Private) Di FKUNISSULA hampir semua cluster mesin untuk aplikasi menggunakan
IP Private dan masing-masing VM mempunyai konfigurasi lebih dari satu aplikasi. Mesin DNS Server memang bisa menyatakan hak akses dari semua user yang mengkases subdomain tersebut sesuai dengan mapping IP yang sudah di konfigurasikan. Pada jaringan FK UNISSULA webserver sebagian besar berada di segmen jaringan internal (DMZ), kemudian di ekspos port-port tertentu ke internet
34
dengan menggunakan metode DNAT. Untuk itu solusi Reverse proxy menjadi alternatif pilihan utama. Reverse proxy merupakan perangkat proxy yang menerima request dari client (web browser) ke satu atau lebih web server dan kemudian mengirim respon dari server request tersebut ke klien seakan-akan berasal dari proxy itu sendiri. Semakin bertambahnya domain dan subdomain sangat membutuhkan segmentasi netblock IP yang sangat banyak, padahal keterbatasan ip public bisa menjadi kendala utama. Solusi yang harus di inplementasikan agar ekspos ip publik yang terpasang pada VM yang nanti di fungsikan sebagai reverse proxy.
Gambar 4.1 Skenario Reverse - Proxy Skema ekspos pada virtual mesin akan membaca request dan meneruskan ke virtualhost yang sesuai disisi DNS, konfigurasi subdomain – subdomain di arahkan ke 1 publik saja yang terpasang pada VM Reverse proxy kemudian nantinya vm reverse proxy-lah yang memforwat request ke vhost (dengan ip private) yang sesuai.
4.3.
Konsep Manajemen Jaringan Prinsip-prinsip dasar yang digunakan dalam desain jaringan:
A.
Hierarkis 1)
Jaringan dibuat dalam lapis-lapis fungsional yang saling berinteraksi. 35
2)
Mengakomodasi pembedaan fungsi yang perlu diterapkan di masingmasing segmen jaringan yang berbeda.
B.
3)
Menyederhanakan pembangunan, operasi dan manajemen.
4)
Meminimalisasi adanya gangguan pada setiap lapis fungsional.
Modular 1)
Jaringan dibangun berdasarkan komponen –komponen / Modul perangkat yang melakukan suatu fungsi tertentu.
2)
Jaringan dapat dikembangkan dengan menambahkan modul-modul perangkat baru untuk menghasilkan fungsi baru tanpa mengubah desain (evolusioner vs revolusioner).
C.
Keandalan 1)
Desain perlu mempertimbangkan adanya faktor gangguan dan kegagalan fungsi kerja perangkat.
2)
Bagaimana agar adanya gangguan & kegagalan fungsi kerja ini tidak “meruntuhkan” jaringan.
3)
Gangguan dilokalisasi di segmen jaringan tertentu.
4)
Gangguan di suatu segmen jaringan berdampak minimal pada segmen jaringan lain.
5) D.
Keywords: Redundancy, Failover, Backup Plan, Disaster Recovery.
Fleksibilitas 1)
Jaringan dapat mengakomodasi adanya karakteristik penggunaan layanan yang berbeda-beda.
2)
Optimalisasi sumberdaya melalui load sharing dan QoS.
36
4.4.
Hierarki Fungsional dan Desain Jaringan DMZ
4.4.1. Desain jaringan berdasarkan hierarki fungsional meliputi : a.
Access Layer Segmen jaringan yang menghubungkan perangkat pengguna ke jaringan.
b.
Distribution Layer Segmen jaringan perantara access layer ke core layer, berfungsi untuk : 1) Agregasi fisik jaringan pengkabelan dari access layer. 2) Agregasi broadcast domain (L2) dan routing domain (L3). 3) Intelligent switching, routing & network access policy.
c.
Core
Layer
Segmen
jaringan
yang
berfungsi
sebagai
backbone,
menghubungkan segmen distribution layer dengan data center / server farm. Merupakan agregator dari layer-layer lain dibawahnya.
Gambar 4.2 Topologi Jaringan FKUNISSULA
37
4.4.2 Desain Jaringan DMZ Desain jaringan farm meliputi : a.
Menggunakan Virtualisasi terhubung ke storage cluster.
b.
Hardware dengan Multicore CPU & RAM besar menjalankan
banyak
Virtual Machine (VM) -> Computing node dan 1 VM per service : 1.
Memudahkan dukungan catu daya & backup power.
2.
Storage cluster: Komputer eksisting dialih fungsikan untuk storage server.
c.
Diisi harddisk kapasitas maksimal, jumlah maksimal.
d.
Dibuat redundan untuk backup.
Gambar 4.3 Jaringan DMZ
4.4.3. Desain jaringan Captive Portal a.
Wireless Network 1) Authentication Gateway berada di access layer. 2) Memanfaatkan fitur Virtual AP Mikrotik 38
3) Setiap Virtual AP menyediakan SSID sesuai Class-off service yang akan digelar. 4) VAP terhubung ke VLAN Misal: a)
VAP Guest (jalur merah pada diagram hanya bisa akses Internet).
b)
VAP Internal #1 dan #2 (jalur biru & hitam) bisa akses Internet dan akses ke Internal Resources Network.
b.
Wired Network Port manageable switch untuk pemisah Class of service, memanfaatkan
fasilitas vlan
Port 1 -> guest computer -> vlan guest.
Port 2 -> lab computer -> Internal #1.
Gambar 4. 4 Captive Portal Jaringan FKUNISSULA 4.5.
Jenis perangkat Jaringan
4.5.1. Perangkat Core Layer a.
Core Router
39
Mikrotik/Linux diatas platform x86 dengan multi gigabit ethernet port. b.
Core switch 1)
L2 Gigabit manageable switch dengan SFP port (untuk FO link antar gedung) minimal 24 port.
2) c.
Mendukung 802.1x.
HTTP Cache 1)
Server 64 bit CPU.
2)
RAM 4GB (semakin besar RAM, performansi semakin baik).
3)
2 hard disk (1 untuk OS, 1 untuk cache object).
4.5.2. Perangkat DMZ a)
Gigabit L2 manageable switch. Dapat menggunakan core switch.
b)
Virtualisation Host. 1) Server CPU 64 bit multicore 2) RAM > 16GB. 3) Harddisk.
c)
Storage Farm . 1) Alih fungsikan server lama. 2) Penambahan harddisk sejumlah kapasitas SATA & PSU port server. 3) Menggunakan cluster filesystem (misal DRBD, GlusterFS, CEPH).
4.5.3. Perangkat Distribution Layer a)
Distribution Switch – L2 Gigabit Manageable switch.
b)
Port SFP untuk uplink – 24 Port fast Ethernet.
40
4.5.4. Perangkat Access Layer a.
Wireless Router. 1) Mendukung 802.1x. 2) Mendukung VLAN trunking .
b.
Wireless Access Point. Ubnt / Mikrotik.
c.
L2 Manageable Switch Fast Ethernet. 1) Jika memungkinkan memakai gigabyte lebih baik. 2) Mendukung 802.1x. 3) Mendukung 802.1q (vlan).
4.5.5. Perangkat Edge Layer Router Multi Services (BGP Dynamic Routing, Firewall, QoS/Bandwidth Management): a)
Mikrotik CCR platform.
b)
Mikrotik/Linux di platform x86.
4.6.
Analisis Kebutuhan Perangkat Keras
4.6.1. Tersedianya server sebanyak 2 buah Kedua server ini mempunyai spesifikasi yang indentik yang terdapat dalam environment virtualisasi server. Satu server sebagai active server dan satu server lainnya sebagai backup server. Mesin server utama merupakan server yang digunakan untuk aplikasi Sistem Informasi Akademik Mahasiswa. Server yang disiapakan kami sesuaikan dengan kebutuhan layanan informasi online. Kedua server tersebut memiliki spesifikasi seperti berikut : 41
Tabel 4.3 Spesifikasi Server Utama Baru Hardware Mainboard Processor Memory Hardisk NIC
Tipe Intel Intel (R) Xeon CPU E5-2420 @1,90GHz 4 DiMM 2.5 SATA Raid 2 Broadcom BMC5790c Quad Port NIC
ukuran
4GB 100 G
Tabel 4.3 Spesifikasi Server Backup Hardware Mainboard Processor Memory Hardisk NIC
Tipe Intel Intel (R) Xeon CPU E5-2630
[email protected] DDR4 1600/1866 2.5 SATA Raid 2 Broadcom BMC5790c Quad Port NIC
ukuran
4GB 100 G
4.6.2. Ruter Mikrotik Topologi jaringan VPN yang digunakan adalah dengan metode tunneling EoIp (Ethernet over IP), yaitu protokol yang digunakan untuk membuat terowongan (tunnel) menggunakan interface ethernet antar 2 buah router atau lebih. Syarat dari penggunaan metode ini adalah fungsi bridging pada router harus aktif, karena interface-interface ethernet pada router akan di-bridging dengan koneksi eoip. Router yang digunakan untuk implemetasi jaringan VPN EoIP adalah router mikrotik. Tujuan digunakannya metode eoip ini adalah : 1.
Membuat 2 network yang berbeda terhubung secara virtual, sehingga masingmasing network dapat berkomunikasi satu sama lain.
2.
Komunikasi berjalan seperti dalam satu jaringan, walaupun masing-masing network telah melewati beberapa router. Dengan menggunakan EoIp tunnel
42
maka jaringan yang dituju akan menjadi satu subnet dengan alokasi ip address yang telah ditentukan. Kedua server akan saling terhubung dengan menggunakan koneksi vpn antar network dengan masing-masing router melakukan tunneling vpn ke router vpn pusat dengan metode EoIP (Ethernet over IP). Dimana menggunakan link jaringan FO (Fiber Optik) yang merupakan backbone link dari data center di Fakultas Kedokteran menuju data center di PT. Desnet sebagai penyedia Layanan Collocation server yang berbasis VPS. 4.6.3. Switch Manageble Switch manageble type cisco type srw250gw merupakan vlan switch yang memanage link koneksi jaringan dari 2 buah link yang berupa Fiber Optic dan Jaringan Wireles serta virtualisasi network DMZ dan jaringan lokal kami. Switch tersebut merupakan core vlan dari semua switch distribusi dan dhcpserver.
4.7.
Analisis Kebutuhan Perangkat Lunak Beberapa perangkat lunak / software yang digunakan adalah :
1.
Sistem Operasi Sistem operasi yang digunakan adalah Linux Debian 6.0 Whezzy pada kedua server (node utama dan node backup).
2.
Webmin Merupakan Aplikasi yang melakukan konfigurasi service, proses backup dan restore filesystem, edit pasword system, konfigurasi jaringan seperti interfaces yang digunakan konfigurasi DNS, Routing Subdomain. 43
dan management domain dan
3.
Reserve-Proxy-web Suatu aplikasi untuk memetakan Ip public ke ip private. Dimana reserve proxy inimemiliki keunggulan di banding dengan DNAT dan dapat memetakan nama domain ke ip private jadi tidak boros ip public.
4.
Software Aplikasi Web Server Web server dijalankan dengan menggunaka aplikasi server apache2, php5 yang akan terintregasi pada masing-masing server Linux Debian.
5.
Software Aplikasi Database Server Database server dijalankan dengan menggunakan aplikasi MySQL Server dan MSSQL server database terpusat yang akan terpasang pada masing-masing server.
6.
Aplikasi GITLAB Server GitLab adalah suatu apliakasi layanan berbasis web hosting untuk pengembangan proyek –proyek perangkat lunak software yang menggunakan tool kontrol sistem revisi dalam melakukan revisi code ( GIT). Aplikasi ini di gunakan sebagai Repository dan RBAC semua developer agar memudahkan programer yang bekerja berbeda tempat agar lebih mudah bagi individu dan tim untuk menulis kode yang lebih baik, lebih cepat. GitLab mendukung semua bahasa pemrograman dan bebas memakai bahasa dan tool yang biasa di pakai.
44
4.8.
Perancangan Topologi Jaringan
Gambar 4.5 Topologi Eoip Tunnel FKUNISSULA Topologi untuk implementasi failover ini adalah dengan menempatkan dua server, node utama berada di data center Fakultas Kedokteran Unissula sedangkan node backup berada di data center PT. Desnet dengan memanfaatkan tunneling vpn EoIP.
4.9.
Perancangan Failover Setiap server akan diberikan IP address masing-masing, namun pada
prinsipnya di dalam sebuah jaringan diperlukan sebuah IP address. IP address inilah yang akan digunakan sebagai IP address tujuan oleh client saat ingin mengirimkan sebuah informasi sehingga setiap server dapat bertukar informasi dan request yang diperlukan agar proses yang terjadi di server yang satu dengan lainnya bisa diterima dengan cepat.
45
4.10. Perancangan Sinkronisasi Database Database utama dibackup secara periodik kemudian dari server utama di konfigurasi script agar secara periodik bisa melakukan proses sinkronisasi antar kedua server. Hal tersebut dimaksudkan agar record data pada server bisa saling sinkron atau bisa saling update satu sama lain. Metode replikasi database yang digunakan adalah metode master to master. Metode ini dimaksudkan agar masingmasing database pada server bertindak sebagai master atau database utama. Dengan demikian jika ada insert, update, dan delete pada satu server maka data akan terreplika juga pada server yang lain.
46
BAB V IMPLEMENTASI INFRASTRUCTUR
Tahapan perancangan Disaster Recovery Plan yang dilakukan di setiap institusi tidak selalu sama, karena tergantung dengan kebutuhan, tujuan pembuatan dan kendala yang di hadapi menurut skala prioritas di institusi yang bersangkutan. Fakultas Kedokteran Unissula yang mempunyai ketersediaan infrastruktur yang bisa di bilang sudah lengkap karena sejak tahun 2005 planning pembuatan datacenter sudah mulai di laksanakan, bermula dari hanya mempunyai 1 ISP yang menyediakan layanan koneksi internet dan mempunyai 2 server sebagai database server dan server aplikasi yang berbasis web server serta infrastructure router gateway internet dan switch sebagai core distribusi jaringan di setiap gedung. Kami merupakan Fakultas yang memiliki management bandwith dan server sendiri yang terpisah dengan BSI ( Biro Sistem Informasi) unissula baik secara pembiayaan dan managed service data center yang ada. Pertimbangan managed service sendiri karena setiap tahunnya contiunuitas permintaan pengembangan infrastructur dan aplikasi semakin meningkat sehingga kami membutuhkan progres yang cepat dan sesuai dengan permintaan di setiap Prodi. Dengan berkembangnya kebutuhan tersebut BSI belom bisa memenuhi permintaan continueitas plan yang kami butuhkan. Setiap tahunnya kami mengembangan infrasturure dengan menambah beberapa server dan perangkat jaringan internet sebagai pendukung ketersedian sarana prasaraan dalam kegiatan akademik dan sisfo berbasis online. Managed service yang yang tercentral di datacenter
memudahkan
administrator dalam mengontrol, maintenance dan mengontrol semua perangkat dan 47
aplikasi yang di akses mahasiswa, 2 buah server yang digunakan sebagai server database dan aplikasi web server sangat berperan penting dalam mengakses domain website : www.fkunissula.ac.id.
5. 1.
Implementasi Virtualisasi Mesin Proses implementasi mesin server yang digunakan sebagai mesin untuk
menempatkan aplikasi dan domain web fkunissula.ac.id. Operating system yang di gunakan adalah Linux debian 6.0 di mana di install diatas virtualisasi mesin yang berbasis ProxMox. Petunjuk Installasi Proxmox untuk membuat Virtualisasi Server : 1.
Software
aplikasi
proxmox
dapat
di
download
:
https://pve.proxmox.com/wiki/Downloads dan setelah kita download file ISOnya dapat langsung di gunakan pada mesin ( sebagai virtual CD / DVD ), atau kita Burn ke CD untuk selanjutnya kita gunakan sebagai installer pada Server atau PC Server kita.
Gambar 5.1 Install Proxmox
48
2.
Saat muncul tampilan diatas, tekan enter untuk mulai proses installasi. Lalu saat muncul tampilan dibawah ini, klik I Agree.
Gambar 5.2 User license Agreement 3.
Lalu klik NEXT.
Gambar 5.3 Proxmox Virtualization Environment
49
4.
Kemudian tentukan Time Zone Jakarta.
Gambar 5.4 Konfigurasi location and time zone 5.
Masukkan Password untuk Proxmox root.
Gambar 5.5 Konfigurasi user and password
50
6.
Tentukan Nama Server atau Hostname dan IP Address ProxMox Server kita.
Gambar 5.6 Konfigurasi name server and ip address 7.
Selanjutnya akan mulai proses installasi ProxMox dan tunggu hingga selesai
Gambar 5.7 Proses installasi proxmox
51
8.
Selanjutnya setelah proses installasi selesai, klik REBOOT.
Gambar 5.8 Proses installasi proxmox selesai 9.
Setelah proses Booting, akan muncul tampilan seperti gambar dibawah ini dan selanjutnya kita bisa langsung Login ataupun mengakses Proxmox via WebBrowser.
Gambar 5.9 Booting by commandline 52
10.
Untuk via WebBrowser ketikkan pada browser kita : https://ip-address:8006
Gambar 5.10 Interface proxmox by browser 11.
Setelah kita Login, kita bisa melakukan aktifivitas untuk konfigurasi ProxMox Server lebih lanjut dengan tampilan menu atau metode view. Yaitu : Server View, Folder View dan Storage View.
Gambar 5.11 Tampilan menu proxmox 53
12.
Sampai disini kita bisa melihat status server, konfigurasi server, maupun membuat VM baru serta mengunakan virtual Appliances :
Gambar 5.12 Proxmox desentrali server Study kasus yang dilakukan berdasarkan berbagai kasus atau kejadian yang terjadi saat semua aplikasi content webserver fkunissula.ac.id di implementasikan di satu server, dimana domain fkunissula.ac.id dimanaged menggunakan aplkasi ispcp / webmin dan database server mengunakan mysql / Mssql dan aplikasi contentnya menggunakan jomla. Semakin banyak prodi yang meminta pengembangan aplikasi sistem informasi akademik yang bisa di akses secara online tidak bisa berbanding lurus dengan kapasitas storage dan memori untuk melayani bertambahnya data setiap harinya. Disamping membutuhkan storage yang besar dalam menampung data keseharian yang di unggah di server tersebut kendala utama yang terjadi adalah power server yang kadang fault di sebabkan karena naik turunnya supplay listrik, kami sudah menyediakan backup power berupa ups yang di pakai secara bersamaan 54
beberapa server dan perangkat network lainnya hanya mampu bertahan sekitar 60 menit saja. Di daerah Kaligawe merupakan kawasan industri dan institusi unissula ada dalam wilayah tersebut, kendala sering mati listrik sangat sering intensitasnya dan mungkin bisa sampai beberapa jam. Dari kejadian diatas memaksa institusi untuk menyediakan supply backup power , storage dan colocation server supaya layanan sistem informasi bisa di akses kapanpun tanpa mengalami masalah. Penerapan Disaster Recovery Plan sangat berperan penting dalam penggembang infrastructur
dengan
memaksimalkan
biaya
guna
melengkapi
kebutuhan
pengembangan datacenter. Colocation server menjadi prioritas utama dalam penerapan DRP dimana kami bekerjasama dengan ISP sebagai penyedia layanan internet di FKUNISSULA dan penyedia Colocation server. Managed aplikasi web server dan domain yang terpusat di satu mesin kami sebut sentralisasi server. Server hosting memiliki spesifikasi : Intel AMD Proc 4130, Ram 8GB, Hardisk 200Gb, 2 Interface internet.
Gambar 5.13 Spesifikasi server utama 55
Untuk storage tambahan pada server hosting menggunakan ekternal hardisk 500 Gb untuk menampung data yang ter upload di web fkunissula.ac.id. Backup colocation server yang di tempatkan di data center PT. Desnet mempunyai spesifikasi yang setara dengan mesin server utama .
Gambar 5.14 Spesifikasi server hosting backup
5. 2.
Implementasi infrastructure production server terbaru Kendala terbesar yang kami rasakan adalah kebutuhan storage pada server
lama yang semakin bertambah banyak resources untuk media penyimpanan data, untuk itu kami merubah desain desentralisasi server dengan menggunakan clustercluster mesin di setiap aplikasi yang ada. Dengan penambahan 2 buah mesin server yang di alokasikan khusus storage server dan APPS server cukup bisa menunjang untuk pengembangan infrastructure dalam mencari solusi terbaik dalam memanaged server yang efisien. Virtualisasi mesin server yang dibangun dengan aplikasi ProxMox, dimana di desain menjadi 2 server utama yaitu APPS ENGINE dan 56
STORAGE ENGINE. Terlihat di environment pada proxmox 2 buah server yang di gabungkan, dimana 2 buah server memiliki spesifikasi yang berbeda. Masingmasing server di bagi dalam virtualisasi mesin yang berbeda-beda pula. Managed server yang kami desain saat ini kami lakukan karena semakin bertambahnya permintaan pengembangan aplikasi dari tiap prodi, pengembangan infrastructur sedang di kembangkan dan dilakukan implementasi sampai saat ini. 5.2.1. Managed Server APPS Server ini merupakan master plan yang di rancang untuk memisahkan kebutuhan tiap prodi yang mempunyai manajement dan pengembangan SIA dan webserver yang berbeda – beda sesuai dengan kebutuhan dan kebijakan prodi tersebut. Pembagian cluster – cluster masing – masing virtualisasi mesin dengan menggunakan aplikasi Virtualisasi Mesin yang berbasis Web based yaitu dengan Proxmox 4.2 dengan Debian Linux 8.0 sebagai dasar untuk memanaged aplikasi tersebut.
Gambar 5.15 spesifikasi Server APPS 57
Dari environment server APPS terbagi dalam beberapa virtualisasi mesin dari tiap – tiap prodi dan aplikasi untuk menempatkan aplikasi CBS untuk kegiatan ujian kompetensi mahasiswa. 5.2.2. Managed Storage Server Server storage ini hanya di gunakan untuk NFS dan Virtual mesin windows server, tiap-tiap VM di server APPS semua di extend storage hardisk pada server storage. Setiap VM APPS di distribusi strorage 10 GB bisa di rezise sesuai dengan kebutuhan nantinya. Keutamaan tercentral data storage selain sebagai backup data juga sebagai data store yang bisa digunakan untuk share folder dan file, memudahkan administrator untuk memanaged kebutuhan storage tiap mesin dan juga apabila mesin server APPS mengalami fault atau tidak bisa di akses data yang ada masih tersimpan rapi dan akurat di NFS masing-masing server yang sudah di mapping kan satu persatu di mesin aplikasi. Dalam proses develop aplikasi yang di kembangkan bisa di letakkan di mesin manapun dan mengunakan Operating system apapaun bisa tetap mudah di migrasi dan di create baru sekalipun akan dengan mudah di intergrasikan karena datastore dan database nya sudah di mapper tinggal di mountkan sesuai dengan kebutuhan aplikasi yang ada. Pada server Storage di create Virtual Mesin NFS dengan kapasitas hardisk 1 TB dimana di buatkan mapper pada directory sesuai dengan Virtal mesin yanga da di APPS, jadi semua data log dan file data sudah langsung mengarah di mesin server NFS sesuai dengan mapper directory yang sudah disesuaikan dan di create sesuaikan ukuran kebutuhan hardisknya dan tinggal meresize apabila membutuhkan extend storage.
58
Gambar 5.16 spesifikasi storage
Gambar 5.17 Proxmox Mesin Storage
59
5.2.3. Desain NFS untuk tiap mesin VM APPS Storage server yang memang difungsikan NFS (Network File System) untuk tempat sharing file antar mesin – mesin di APPS. Server ini menyediakan direktori yang akan di-share, client akan memounting di directori tersebut. NFS server dapat mengatur: siapa saja client yang di perbolehkan akses, dan apa hak aksesnya (read only atau read write). Pada server –server APPS yang sudah di maaping berapa kapasitas storage yang berbeda-beda dimana kita bisa merezise NFS sesuai dengan kebutuhan yang di perlukan saat itu.
Gambar 5.18 mapping Storage Mesin APPS 5. 3.
Implementasi Management Domain Name Server Untuk menjalankan failover webserver di butuhkan sebuah DNS dalam
mengakses
suatu
aplikasi
suatu
web.
Kebetulan
domain
server
yang
www.fkunissula.ac.id bisa di managed sendiri, domain fkunissula.ac.id sudah teregister di PANDI dan utuk proses perpanjangan domain di butuhkan pihak ketiga untuk penyedia dasboard dalam memanaged domain tersebut. Kami bekerja sama 60
dengan Indosat M2 untuk billing dan managed service domain fkunissula.ac.id, semua transaksi pembayaran dan managed domain di lakukan sendiri oleh administrator sebagai pemilik domain tersebut. Fakultas kedokteran unissula bekerjasama dengan 2 buah ISP dimana masing- masing mempunyai IP publick yang kami registerkan di domain fkunissula.ac.id, IP publick tersebut menjadi alamat address saat mengakses domain www.fkunissula.ac.id dan dapat di test menggunakan tool di internet di mana akan terlihat data IP berapa dan siapakah pemilik register ip domain tersebut. Untuk managemen domain pada mesin server yang lama menggunakan Aplikasi webbased ISCP dan untuk pengembangan domain pada mesin yang baru kami menggunakan metode failover DNS yang di managed dengan aplikasi webmin, Aplikasi webmin ini menjadi address atau alamat ip masing-masing dari domain yang kami punyai. Aplikasi Webmin installkan dan konfigurasi menjadi 2 mesin yang berbeda dengan konfigurasi ip domain yang berbeda pula yang menggunakan ip dari ISP yang memberikan layanan kepada fkunissula. Mesin Aplikasi domain di install di mesin yang berbeda dan tidak menjadi satu di mesin storage dan APPS, tetapi di konfigurasi dan di install di mesin server network yang berbeda spesifikasi mesin dan interface networknya. Konfigurasi gateway network dan konfigurasi dns server dijadikan satu dalam mesin yang sama supaya integrasi IP Publik dari tiap proveider bisa mudah dalam membuat virtualisasi network sebagai bridge network dari semua VM yang sudah di mapping. Semua subdomain dari fkunissula.ac.id di destinasikan sendiri - sendiri sesuai dengan Ip publik masing –masing. Setiap mesin yang sudah di buat menjadi
61
cluster mesin sesuai prodi dan aplikasi, sudah dikonfigurasi dalam mesin dns server dengan mengunakan aplikasi Webmin. Instalasi webmin pada OS debian 1.
Saat ini saya anggap anda sudah login di console dengan akses root. Silahkan masukan command ini satu persatu, kemudian Enter. a.
Wget http://prdownloads.sourceforge.net/webadmin/webmin_1.690_all.deb
b.
dpkg -i webmin_1.690_all.deb
c.
apt-get install perl libnet-ssleay-perl openssl libauthen-pam-perl libpamruntime libio-pty-perl apt-show-versions python
d. 2.
apt-get -f install
Setelah selesai menginstall Webmin, untuk mengakses admin panel kunjugi https://x.x.x.x:10000 dimana x.x.x.x adalah ip dari VPS anda.
Gambar 5.19 aplikasi webmin 62
Dengan menggunakaan tool aplikasi dns zone yang ada di webmin, domain fkunissula.ac.id bisa dengan mudah di konfigurasi sesuai dengan name server saat register di PANDI.
Gambar 5.20 Konfigurasi dns fkunissula Name server yang di dapatkan saat kita meregistrasikan domain fkunissula.ac.id dengan 2 IP dari masing-masing proveider sangat berperan penting dalam mengarahkan subdomain dari fkunissula.ac.id melalui ip yang di tentukan dan di setting agar manage domain bisa di akses di kedua ip tersebut.
Gambar 5.21 konfigurasi name server domain fkunissula 63
Untuk mapping name server yang teregister berbeda, karena ada 2 IP publik dari masing –masing ISP yang di registerkan :
Gambar 5.22 mapping name server sebagai dns Subdomain juga di konfigurasikan sesuai dengan Ip masing-masing sehingga proses filover dns bisa berjalan. Apabila diakses dari lokal jaringan fkunissula dan maupun dari wan dengan proveider jaringan yang berbeda pasti akan terindentifikasi ip yang berbeda-beda saaat mengakses web subdomain di fkunissula. Kejadian tersebut memang konfigurasi dari failover dns apabila salah satu ISP down secara otomatis dns yang satunya yang jalan.
Gambar 5.23 Mapping IP Publik DNS SERVER
64
5. 4.
Implementasi Reverse-Proxy Server Semakin bertambahnya domain dan subdomain sangat membutuhkan
segmentasi netblock ip yang sangat banyak, padahal keterbatasan ip publik bisa menjadi kendala utama. Pada jaringan FKUNISSULA webserver sebagian besar berada di segmen jaringan internal (DMZ), kemudian di ekspos port-port tertentu ke internet dengan menggunakan metode DNAT. Dengan metode DNAT ini : 1.
Diperlukan satu IP publik untuk tiap IP private webserver yang akan di ekspos ke internet (keculai bila webserver internal tidak running di port 80).
2.
Router gateway FK UNISSULA menerapkan konfigursi load balance yang terkadang menyebabkan munculnya asymetric routing ( jalur routing yang digunakan untuk request akses ke salah satu IP publik di pakai untuk DNAT ke IP DMZ dan jalur requestnya menggunakan jalur internet yang berbeda). Dalam menjalankan implementasi reverse proxy untuk menggantikan nat di
jaringan fkunissula memiliki beberapa jenis mekanisme mapping / pemetaan untuk meneruskan request yang di terima ke webserver melalui IP private antara lain : 1.
Pemetaan berdasarkan virtualhost/nama domain ,dengan mekanisme ini beberapa hostname yang menujuk ke ip publik yang sama dapat di petakan ke ip private internal yang berbeda a.
www.a.com 10.20.30.1
b.
Web.a.com 10.20.30.2
c.
(DNS www.a.com dan web.a.com keduanya menunjuk ke 1 ip publick yang sama)
65
2.
Pemetaan berdasarkan IP, dengan mekanisme ini, request ke ip publik yang berbeda di petakan ke ip private internal yang berbeda a.
1.2.3.4 (publik) 10.20.30.1
b.
1.2.3.4 (publik) 10.20.30.2
Untuk menambahkan konfigurasi IP pada mesin aplikasi makan perlu dilakukan konfigurasi virtualhost : server, listen dan acces log sebagai berikut :
Gambar 5.24 konfigurasi virtualhost reverse proxy
Gambar 5.25 Desain Implementasi reverse proxy 66
Berdasarkan skenario gambar di 5.24 : 1.
Server reverse-proxy berperan sebagai mekanisme mapping / pemetaan sebuah mesin web server yang mempunyai beberapa domain aplikasi dalam satu mesin webserver yang mempunyai IP Private internal di petakan agar menujuk ke IP Publik yang sudah di tetapkan.
2.
Destination IP Publik dari server revers-proxy di konfigurasikan pada mesin DNS agar virtualhost / domain yang terdapat pada mesin web server bisa diakses publik.
3.
Dengan hanya mengakses / memanggil nama domain via saja via browser domain fkunissula.ac.id yang awalnya mempunyai di IP Private bisa diakses secara online dan sudah di terjemahkan ke IP Publik.
5.5.
Implementasi Backup Konten Server Desain solusi backup server yang ada di fakultas kedokteran unissula
menggunakan metode offsite backup server. Pemilihan metode tersebut karena server backup ditempatkan di datacenter di PT. Desnet , colocation server yang dilakukan dengan mempertimbangkan dengan lokasi yang tidak terlalu jauh dengan server utama dan tersediananya core backbone netwok yang sudah tersedia untuk itu mempermudah proses konfigurasi mirror dan proses failover berjalan secara periodik. 5.5.1. Metodologi offsite backup server : a.
Merupakan metode antisipasi gangguan server dengan menempatkan server cadangan di lokasi berbeda (offsite backup) dari server utama dimana server cadangan melakukan sinkronisasi aplikasi dan data dari server utama 67
b.
Server cadangan dapat difungsikan untuk berperan sebagai : 1) Hot standby a) Server cadangan merupakan sistem yang dikonfigurasi identik dengan server utama. Ketika ada gangguan pada server utama, server cadangan dapat difungsikan (otomatis/manual) untuk menggantikan server utama (hot standby). b) Faktor Kunci:
Sinkronisasi aplikasi, data dan konfigurasi server utama dan cadangan secara real time
Kapasitas 1:1 (spesifikasi resource hardware serta jenis software sistem & aplikasi di server cadangan identik dengan server utama)
Otomatisasi proses
Desain infrastruktur jaringan yang memungkinkan failover
Menghilangkan single point of failure
2) Batch & Periodic backup Metodologi Offsite Backup a) Batch & Periodic backup: server cadangan merupakan sistem yang dikonfigurasi untuk menyimpan data server utama. Server cadangan menjalankan sistem backup yang melakukan copy data (baik sistem maupun aplikasi) dari server utama secara periodik (harian, mingguan, bulanan). b)
Sistem backup yang diterapkan bertujuan agar sewaktu-waktu terjadi gangguan & kerusakan data pada server utama, dapat diperbaiki secara cepat dengan melakukan restore data & konfigurasi dari backup. 68
c) Faktor Kunci:
Backup periodik aplikasi, data dan konfigurasi server utama
Otomatisasi proses
Multiple version konten backup (historical).
5.5.2. Identifikasi Kebutuhan System Solusi backup data yang dapat berfungsi: a.
Melakukan backup konten data pada server hosting (202.91.8.163)
b.
Melakukan backup konten database pada MS SQL server (10.10.0.20)
c.
Solusi mirror server hosting yang sewaktu-waktu dapat difungsikan sebagai server hosting cadangan ketika server aslinya (202.91.8.163) mengalami gangguan
5.5.3 Identifikasi Proses Backup Server Solusi sistem backup yang disarankan untuk menjawab identifikasi kebutuhan sistem adalah memakai metode batch & periodic backup. Dasar pertimbangan: a.
Asymmetric Resources (Spesifikasi backup server dibawah main server)
b.
Heterogenitas sistem yang perlu dibackup (1 server berbasis Linux, 1 server berbasis Windows)
c.
Lokasi backup server berada di WAN, sehingga implementasi realtime sync storage akan beresiko menghabiskan kapasitas link WAN.
5.6. a.
Skenario backup server hosting : Backup VM dengan snapshot image bertujuan untuk membuat backup sistem & aplikasi secara total sehingga dalam 1 kali proses backup seluruh konten 69
sistem & data terduplikasi sekaligus, serta siap untuk direstore tanpa perlu konfigurasi manual. File
image
hasil
snapshot
berupa
:
vzdump-qemu-112-2016_01_07-
12_37_02.vma.lzo
Gambar 5.26 Backup Snapshot pada VM Hosting b.
File dengan extensi LZO (Lempel ZIV-Oberhume) yang di hasilkan dari proses image snapshot merupakan hasil compression yang nantinya hasil snapshot tersebut digunakan untuk di installasikan pada server backup dengan proses via image proxmox yang ada di colocation server. Proses clone server pada node backup lebih effective karena menggunakan aplikasi proxmox, sehingga server backup dan server utama menjadi kembar identik baik OS ataupun aplikasi yang ada.
70
Gambar 5.27 Desain Backup Server via Proxmox
Gambar 5.28 Clone Web Server Via Image Proxmox
Gambar 5.29 Clone Database Server Via Image Proxmox
71
5.7.
Implementasi Failover dan Mirror Web Server
Gambar 5.30 Skenario Failover dan Mirror Server Desain
jaringan
yang
dibangun
dalam
mengintegrasikan
dan
mengimplementasikan konfigurasi jaringan yang menjadi faktor kunci penyediaan jaringan / koneksi yang menjadi jalur otomatis proses backup periodik aplikasi, data dan konfigurasi server utama. 5.7.1. Implementasi vlan pada captive portal Core layer yang menjadi segmen jaringan yang berfungsi sebagai backbone yag menghubungkan segmen distribusi layer dengan data center / server farm, menghubungkan DMZ dengan core layer dengan distribusi layer sehingga dari jaringan lokal sendiri bisa diakses dengan mudah dengan memanfaatkan fasilitas vlan.
72
Gambar 5.31 Desain Captive Portal Untuk perangkat edge layer menggunakan mesin server yang berbasis mikrotik dimana sebagai gateway dan portal yang manjadi konfigurasi virtualisasi yang terhubung dengan storage cluster dan menjadi authentifikasi VLAN dari switch distribusi atau perangkat Acces layer yang berbasis perangkat cisco. Desain hierarki Fungsional dan jaringan yang berbasis DMZ menjadi solusi dalam menjalankan backup data ataupun failover yang berbasis DNS server sebagai implementasi Disaster Recovery Plan. 5.7.2. Tunnel EoIP sebagai gateway failover dns Edge layer gateway dengan menggunakan link Fiber Optik dengan kapasitas 40 Mbps mendukung dalam proses backup database dan konten server dari server utama ke server backup yang di setting secara otomatis periodek waktunya. Tunnel EoIP yang di konfigurasikan hanya di gunakan untuk membangun link lokal di server fkunissula dengan link lokal server di PT. Desnet sehingga dari netblock yang
73
sudah ditetapkan bisa dengan mudah dalam mengakses server backup menggunakan link lokal di jaringan fkunissula. Tunel EoIP yang di konfigurasikan menjadi link utama dalam proses backup database, sehingga koneksi ke server backup bisa preposisi sesuai penetapan kapasitas link yang di gunakan. Saat terjadi gangguan koneksi internet link tunel yang di buat tidak akan terganggu saat proses backup di jalankan, dan integrasi antar beberapa mesin server dan database antara server backup dengan server lain yang ada di data center fkunissula lebih mudah di implementasikan. 5.7.3. Skenario Failover DNS dan Mirror server Proses Failover DNS dapat terjadi secara otomatis apabila salah satu ISP mengalami downtime ataupun saat mengalami gangguan kelistrikan di Fakultas Kedokteran. Berikut skenario prosedur failover yang di implementasikan : a.
Pemetaan pergantian IP DNS sudah dikonfigurasikan pada aplikasi webmin menggunakan IP Publik dari kedua belah ISP sangat berperan apabila satu ISP mengalami downtime proses failover / pergantian destination bisa secara otomatis mengarah ke IP Publik yang uptime pada saat itu tetapi akan mengalami delay beberapa waktu saat proses failover dns berlangsung.
b.
Pada jaringan internal tidak akan mengalami kegagalan akses domain yang dituju karena peran revers-proxy yang memetakan domain – domain dari IP Private menjadi IP Publik. Saat user mengakses domain fkunissula.ac.id dengan menggunakan jaringan internal tidak mengalami delay downtime dan migrasi failover dns, karena sama seperti mengakses domain dengan ip private.
74
c.
Proses DRP dengan metode failover dns bisa ber jalankan otomatis saat terjadi down mesin server utama akibat gangguan kelistrikan atau force majure.
Prosedur
failover
dapat
dijalankan
karena
server
backup
mengantikan dns server dan webserver secara otomatis. Redudan server backup yang selalu hidup dan menggantikan peran dns server dan webserver hanya bisa kita cek saat kita mengakses dengan menggunakan jaringan WAN yang berbeda dengan jaringan di FKUNISSULA. Delay downtime mungkin di rasakan sekian detik atau bahkan tidak akan terasaa saat proses failover terjadi. Saat kita mengakses fkunissula.ac.id tetapi sudah termapping menggunakan dns dari server backup tidak akan mengalami loading lambat saat mengakses domain tersebut, tetapi sebaliknya akan mengalami loading sebentar karena pergantian dns.
5.8.
Skenario implementasi update aplikasi konten dan database dengan menggunakan GITLAB GitLab merupakan software yang berbasis web based dimana menggunakan
sistem pengontrol git dan mempunyai repository sebagai penyimpanan aplikasi yang berupa koding atau hasil dari source code program dari semua project desain yang telah di buat sehingga tim developer bisa secara bersama – sama mengakses koding dalam repository tersebut. Fakultas Kedokteran menggunakan mesin server GITLAB tersendiri untuk menyimpan repository source code dan project desain dari semua aplikasi yang telah di update / modifikasi sehingga monitoring dan proses update antar aplikasi lebih mudah.
75
Gambar 5.32 Desain Update Aplikasi dengan Github Prosedure update aplikasi yang di implementasikan di fakultas kedokteran dengan menggunakan perintah commit, push , pull untuk mengupdate / memodifikasi source code aplikasi yang sudah di unggah di repository mesin gitlab oleh programer saat ada perubahan source code dari aplikasi yang di buatnya. 1.
Perintah commit di gunakan untuk mengunggah atau menyimpan perubahan source code dari repository lokal aplikasi yang programer gunakan.
2.
Perintah push di gunakan untuk mengirimkan hasil commit dari repository lokal ke repository server gitlab
3.
Perintah Pull di gunakan untuk menarik commit dari repository di server gitlab untuk di teruskan atau di copy secara otomatis source code yang di update tersebut sehingga modifikasi / update yang ada di repository server sama dengan repository lokal server yang ter update. Dengan adanya server gitlab proses mirror server update source code atau
aplikasi yang pull kan pada server utama akan sama dengan modifikasi source code yang akan di pull di server backup karena proses penyamaan repository server git akan sama juga pada repository lokal server utama dan server backup.
76
Gambar 5.33 Update Repository Lokal dengan Perintah “Pull”
77
BAB VI PENGUJIAN SISTEM DAN MONITORING
6.1.
Pengujian Sistem Setelah proses backup server, update server dilakukan sehingga server utama
mempunyai spesifikasi yang indentik dengan server backup baik aplikasi maupun database. Prosedur failover DNS dan mirror server yang sudah berjalan secara otomatis dan periodik sinkronisasi aplikasi dan databasenya diperlukan pegujian dan monitoring secara berkala agar saat terjadi force majure proses Disaster Recovery Plan dapat berjalan sesuai skenario dan metode yang di jalankan, dimana server backup secara otomatis mengambil alih fungsi sebagai dns server dan server aplikasi. Seperti yang telah di jelaskan pada bagian sebelumnya, pengujian dan monitoring yang akan di lakukan berdasarkan metode yang sudah di tetepkan antara lain: 1.
Proses Failover DNS yang sudah di konfigurasi berjalan sesuai dengan skenario yang sudah di jalankan.
2.
Report
Monitoring
melalui
tool
managemen
monitoring
dengan
menggunakan aplikasi Zabbix Pengujian di lakukan dengan beberapa skenario implementasi yang sudah di jalankan yaitu: 6.1.1. Pengujian mapping konfigurasi Webmin Pengujian konfigurasi yang dilakukan pada mesin aplikasi webmin dari subdomain yang sudah di destinasikan ke beberapa IP publik sehingga apabila kita lakukan pengecekan domain tersebut IP berapa yang bisa terjemahkan aplikasi yang 78
sedang di akses, berikut beberapa pengujian di mana error message yang di munculkan web yang tidak bisa diakses akibat kesalahan konfigurasi dns server. Skenario pengujian konfigurasi mapping dns server meliputi : 1.
Pengujian berdasarkan IP publik yang di DNAT kan sebagai address domain yang bersangkutan. Semua domain dan subdomain sudah di konfigurasi atau di mappingkan sesuai dengan IP Publik masing – masing dimana setiap domian memiliki 2 IP Publik sesuai Netblock dari kedua ISP .
Gambar 6.1 Konfigurasi IP Domain dan Subdomain 2.
Pengujian berdasarkan nama domain dan ip publik.
79
Gambar 6.2 DNS sebagai Domain Server 3.
Pengujian Resolve / tidaknya DNAT yang di konfigurasikan. Proses ujicoba yang di lakukan untuk mengecek apakah IP yang sudah di konfigurasikan di DNS server sebagai address domain sudah bisa resolve dan apakah sudah domain juga sudah bisa mengarah baik ke IP Lokal dan DNAT yang di konfigurasikan tersebut
Gambar 6.3
Ujicoba Trace dan Ping IP DNAT 80
6.1.2. Pengujian mapping konfigurasi Reverse-proxy server Pengujian konfigurasi pada resverse proxy ini berbeda dengan pengujian dns server tersebut, karena konfigurasinya juga berbeda. Konfigurasi pada reverse proxy dilakukan pada virtualhostnya yang di destinatisikan pada name subdomain yang mau di mappingkan ip agar bisa di akses
Gambar 6.4 Akses Vhost dan Error Massage
Gambar 6.5 Vhost 202.91.8.149 sudah Resolve 6.1.3. Pengujian failover DNS tiap subdomain Pengujian yang dilakukan untuk mengecek apakah konfigurasi dari webmin dan reverse proxy berjalan sesuai denga tujuan awal saat di konfigurasi.
81
Gambar 6.6 Failover Domain Gagal diakses Kegagalan saat di ujicoba dengan ping dan traceroute domain yang di sebabkan karena salah satu IP publik mengalami down koneksinya, dari contoh IP : 202.91.8.163 yang mengalami down dari penyedia layanan internet.
82
6.2.
Monitoring menggunakan Tool Zabbix ZABBIX adalah aplikasi enterprise yang digunakan untuk memonitor dan
melacak status berbagai macam network services, server, dan perangkat jaringan lainnya. Aplikasi ini dibuat oleh seorang programmer berkebangsaan Rusia yang bernama Alexei Vladishev, dan dilisensikan sebagai GPL software. Untuk menyimpan log data yang dihasilkan, aplikasi ini memanfaatkan database server seperti MySQL, PostgreSQl, atau Oracle, untuk menyimpan data. Tampilan aplikasi ini dibuat berbasiskan web, dan dibuat sepenuhnya dengan menggunakan bahasa PHP. Aplikasi ZABBIX juga menawarkan sejumlah options monitoring. Aplikasi ini juga dapat dengan mudah mengecek keberadaan sejumlah standar service seperti SMTP atau HTTP, tanpa menginstalasi software tambahan lainnya pada komputer host yang sedang dimonitor. Aplikasi ini juga menyediakan suatu aplikasi agent yang dapat diinstalasi pada komputer host berbasis Linux maupun Windows, untuk menghasilkan statistik penggunaan resource CPU,Utility jaringan, kapasitas harddisk, dan sebagainya. Selain menginstalasi aplikasi agent di komputer host, ZABBIX juga mendukung proses monitoring melalui protokol SNMP. Sebagai aplikasi yang sifatnya enterprise bersifat free software yang terdapat di Linux, ZABBIX sudah dilengkapi dengan sejumlah fitur. Beberapa fitur yang dimiliki oleh ZABBIX antara lain:
Bersifat distributed monitoring. Dapat memproses ribuan
proses ketersediaan jaringan dan melakukan update pengecekan setiap satu detik sekali atau bisa kita setting roundown waktunya. Zabbix dapat memberikan solusi penangana masalah dengan cepat karena bersifat real-time monitoringnya. Laporan yang dihasilkan dapat diintegrasikan dengan mudah, dengan menggunakan third party tool. Proses monitoring dan laporan secara otomatis pada perangkat jaringan 83
dan server apabila ada fault yang ditemukan. Dengan berbasis web monitoring. Dapat memonitor remote sevices (FTP, SSH, HTTP), dan mendukung SNMP. Memiliki
administrasi
aplikasi
yang
mudah
dilakukan.
mengimpor/mengekspor data ke dalam format XML.
Gambar 6.7 Map Server Farm FKUNISSULA
Gambar 6.8 Display Konfigurasi Hosts Server Farm
84
Dapat
Gambar 6.9 Remote Sevices (FTP, SSH, HTTP)
85
BAB VII KESIMPULAN DAN SARAN
7.1.
KESIMPULAN Fakultas Kedokteran Unissula bekerja sama dengan 2 (ISP) Internet Service
Proveider dalam melakukan aktifitas pelayanan penyediaan akses ineternet dan proses backup server dalam pelaksaanaan Disaster Recovery Plan. Kesimpulan yang dapat diambil dari kegiatan penelitian ini adalah sebagai berikut : 1
Sistem failover clustering server yang dibangun dapat bekerja dengan baik berdasarkan pengujian yang telah dilakukan dimana jika salah satu server baik secara fisik maupun secara jaringan tidak dapat diakses, maka user tetap dapat mengakses data dan aplikasi server pada server backup.
2
Proses sinkronisasi data dan aplikasi antar server utama dan server backup dapat berjalan dengan baik dan realtime dengan memanfaatkan metode mirroring dengan response times failover server dari server utama ke server backup lebih pendek dibandingan proses recovery dari server backup ke server utama, hal ini dikarenakan pengaruh proses inisialisasi kedua server.
3
Jaringan VPN dengan metode EoIP (Ethernet over IP), dapat menjawab kebutuhan akan syarat failover cluster server yang harus dalam satu subnet, karena EoIP melakukan metode bridging antar network.
4
Teknik failover cluster server dengan memanfaatkan jaringan VPN ini dapat menjadi solusi FKUNISSULA untuk menerapakan disaster recovery system yang aman, karena backup server dapat ditempatkan dimana saja dan dengan
86
tingkat keamanan akses yang tinggi karena memanfaatkan jaringan private (VPN). 5
Proses failover DNS dan loadbalancing dengan reverse proxy menjadi pilihan utama. Reverse proxy merupakan perangkat proxy yang menerima request dari client (web browser) ke satu atau lebih web server dan kemudian mengirim respon dari server request tersebut ke klien seakan-akan berasal dari proxy itu sendiri. Dalam menjalankan implementasi reverse proxy untuk menggantikan nat di jaringan fkunissula memiliki beberapa jenis mekanisme mapping /pemetaan untuk meneruskan request yang di terima ke webserver melalui IP private.
7.2.
SARAN Fakultas Kedokteran Unissula saat ini sedang mengembangan banyak
berbagai System Aplikasi untuk tiap – tiap prodi, banyak sekali kebutuhan aplikasi yang sedang dibangun atas permintaan dan kebijakan dari pimpinan yang semuanya untuk pengembangan informasi yang berbasis on line. Managed service layanan koneksi internet dan kebutuhan resource server (server aplikasi dan server storage) harus segera di akumulatif sesuai dengan kebutuhannya misalnya : 1.
Setiap prodi di berikan support layanan internet sesuai dengan kebutuhan akses setiap dosen dan mahasiswa.
2.
Setiap prodi memiliki server aplikasi dan storage yang di sesuaikan dengan kebutuhan development system.
3.
Setiap di berikan hak akses untuk memanged aplikasi dan VPS yang telah di sediakan. 87
4.
Report dan monitoring realtime yang di laporkan setiap periodik. Kendala utama yang sedang di hadapi di fakultas kedokteran unissula ada
disaster recovery plan dimana masalah kelistrikan menjadi masalah utama di unissula umumnya. Ketersediaan backup server sangat menopang kelancaran Perguruan Tinggi dalam memberikan pelayanan dan penerapkan sistem DRP (Disaster Recovery Plan) di Fakultas Kedokteran Unissula untuk mengamankan resiko hilangnya data karena suatu bencana dan untuk meningkatkan High availability data center yang dimiliki, serta memberikan pelayanan sistem informasi akademik secara up to date.
88
DAFTAR PUSTAKA
A.H.. Kusuma,.et.al. Penggunaan dan Proses SAP. Fakultas Teknik. UNDIP. 2010.
Backup
Data. Sistem
ERP
Anonim, http://wiki.mikrotik.com/wiki/Manual:Interface/EoIP , Diakes 20 Agustus 2015 jam 10.00 wib. Anonim,https://www.digitalocean.com/community/tutorials/how-to-configure-dnsround-robin-load-balancing-for-high-availability, Diakses tanggal 13 November 2015 jam 20:18 wib D.
Ramansyah, 2007. Ilmu Komputer. Com http://mirror.unej.ac.id/iso/dokumen/pdf2/dony-zabix-monitoring-serverdengan-linux.pdf , diakses 18 desember 2015 Diakes 20 Agustus 2015 jam 10.00 wib.
Ellyani, 2012. Metode Manajemen Backup data sebagai Upaya penyelamatan data on line web LAPAN Bandung, Berita Dirgantara vol.13 no.1 maret 2012:22-27. Hernawati, K. 2010. Evisiensi Sumber Daya dengan Virtualisasi Server,(online),Vol.1,(http://staff.uny.ac.id/sites/default/files/penelitian/Kus wari%20Hernawati,%20S.Si.,M.Kom./Efisiensi%20Sumber%20Daya%20d engan%20Virtualisasi%20Server.pdf, diakses 18 April 2012). Irfani. dkk, Implementasi High Availability Server Dengan Teknik Failover Virtual Computer Cluster . Universitas Muhammadiyah Surakarta 2015. http://eprints.ums.ac.id/35179/1/NASKAH%20PUBLIKASI.pdf Irianto, M. 2013, http://manajemen-data-center.blogspot.co.id/, Lukitasari. D dan Oklilas, AF, 2012 . Analisis Perbandingan Load Balancing Web Server Tunggal Dengan Web server Cluster Menggunakan Linux Virtual Server. Universitas Sriwijaya, Jurnal Generic Vol.5 N0.2, ISSN: 1907-4093 (print) / 2087-9814 (online). MF. Afif. 2013. Implementasi Disaster Recovery Plan Dengan Sistem Fail Over Menggunakan Drbd Dan Heartbeat Pada Data Center FKIP UNS IJNS Volume 2 No 2 – April 2013 - ISSN: 2302-5700 http://ijns.org/journal/index.php/ijns/article/viewFile/75/73. SW. Putri, 2008. Pembangunan Disaster Recovery Plan Untuk Sistem Informasi Manajemen Terintegrasi ITB http://s.itb.ac.id/home/
[email protected]/Magister%20Informati ka%20ITB/TA051Studi%20kasus.pdf , diakses 5 April 2015
89
Veryssoon, dkk. (2012), Simulasi Load Balancing Multihoming dan Fail-Over menggunakan VYATTA. Politeknik Telkom, Bandung.
90
91
92