Disaster Recovery saat ini kebanyakan dilakukan dengan cara replikasi pada aplikasi diantara data center primer dan data center sekunder. Ketika data center primer mengalami gangguan hingga mengganggu kelangsungan bisnis organisasi tersebut, data center sekunder akan mengambil alih fungsi data center primer serta aktivasi aplikasi yang telah tereplikasi tersebut. Kemudian, dengan adanya virtualisasi, organisasi kemudian bisa melakukan replikasi pada level virtual machine. Salah satu keuntungan virtualisasi pada skema disaster recovery adalah data center sekunder bisa bersifat pasif (virtual machine), tidak aktif namun organisasi masih bisa mendapatkan RTO yang memadai.
Oleh karena data center sekunder yang bersifat pasif, layanan Disaster Recovery sangat diminati oleh penyedia layanan dan organisasi yang menginginkan layanan ini. Dari sisi penyedia layanan, mereka tidak perlu menyediakan sumber daya 1:1 (kecuali harus mengikuti persyaratan tertentu dari pengguna layanan) karena virtual machineyang berada di data center bersifat pasif (dalam keadaan powered off). Sedangkan dari sisi organisasi yang menginginkan layanan ini, mereka tentunya akan mendapatkan biaya yang sangat efisien dikarenakan penyedia layanan seharusnya bisa menerapkan metode sharing resources.
Ada beberapa hal penting yang harus diperhatikan ketika memilih layanan Disaster Recovery, yaitu :
RPO (Recovery Point Objective)
Hal ini mengatur berapa lama data yang diperbolehkan untuk hilang ketika terjadinya bencana. RPO 15 menit artinya sistem akan melakukan replikasi dari data center primer ke data center sekunder setiap 15 menit. RPO dipengaruhi oleh 2 hal, yaitu : besar perubahan data (delta data) dan besarnya bandwidth untuk replikasi. Sebagai acuan, dengan jaringan 1 Mbps (Mega bits per second) kita bisa melakukan transfer data sebesar 300 MB (Mega Bytes) dalam kurun waktu 1 jam (60 menit). Sehingga untuk mencapai RPO 15 menit, organisasi membutuhkan sekitar 4 Mbps untuk 300 MB delta data. Untuk mencapai RPO 0 dibutuhkan solusi synchronous replication.
RTO (Recovery Time Objective)
Hal ini mengatur berapa lama data center sekunder bisa beroperasi setelah terjadinya bencana pada data center primer. RTO akan dipengaruhi oleh waktu yang dibutuhkan untuk memutuskan kondisi bencana (disaster), koordinasi dengan penyedia layanan DR, inisialisasi data center sekunder (inisialisasi aplikasi), rekonfigurasi jaringan dari data center primer ke sekunder. Melihat aplikasi dan teknik back up aplikasi tersebut, masih dimungkinkan juga untuk diperlukannya beberapa langkah manual seperti verifikasi aplikasi.
Performa Pada Disaster Recovery
Agar layanan DR bisa dimanfaatkan secara baik, layanan ini seharusnya memiliki dampak yang minimum terhadap setiap aplikasi yang berada di data center primer. Penyedia layanan DR harus menjamin bahwa software yang mereka gunakan untuk melindungi aplikasi yang berada di data center primer memiliki dampak yang minimal. Selain itu, penyedia layanan juga bertanggung jawab atas performa ketika sudah dilakukan aktivasi data center sekunder pengguna layanan DR. Pengguna layanan DR sebaiknya melakukan skenario uji coba DR setelah menggunakan layanan ini, agar menyetarakan ekspektasi dari penyedia layanan untuk pengguna layanan DR.
Konsistensi
Penyedia layanan DR harus bisa memberi jaminan atas konsistensi data ketika digunakan (terjadinya bencana). Konsistensi data yang dimaksud ini termasuk konsistensi aplikasi, konsistensi transaksi dan konsistensi point-in-time (konsistensi pada waktu tertentu). Pada OS Windows, konsistensi ini biasanya dibantu oleh Volume Shadow Copy Services (VSS).
Lokasi Pada Disaster Recovery
Lokasi data center sekunder juga menjadi salah satu unsur penting dalam pemilihan layanan DR. Adanya kebijakan pemerintah tentang penyimpanan data yang mengatur jarak antar data center primer dan data center sekunder harus mencapai radius minimal 30 km. Jarak juga akan mempengaruhi biaya WAN dan menambah latency. Terkait dengan latency, biasanya pengguna akan memilih jenis asynchronous replication. Untuk mencapai synchronous replication dengan jarak tersebut, dibutuhkan biaya dan perangkat tambahan untuk memperkecil latency yang terjadi.
Akhir kata, pengguna layanan DR harus jeli melihat kesiapan penyedia layanan DR. Kesiapan ini berupa contact point penyedia layanan DR yaitu helpdesk atau technical support 24×7, skema persiapan DR (kesiapan tim DR, struktur tim DR penyedia layanan, dan DRP) dan pastikan penyedia layanan dapat memfasilitasi skenario uji coba DR untuk memastikan kelancaran proses DR ketika terjadi bencana.
Salam!
Garibaldi – Senior Cloud Consultant IndonesianCloud
Berikut penjelasan dari kami. Jika Ingin membaca artikel lainnya seputar teknologi atau ingin informasi lebih lanjut mengenai produk dari Indonesian Cloud, Anda dapat mengunjungi laman website kami Indonesiancloud.com, dan website VPS kami cloudhostingaja.com. Sampai jumpa di artikel lainnya.