Pemulihan dari bencana (disaster recovery) untuk OpenShift di Google Cloud

Pemulihan dari bencana (DR) sangat penting untuk menjaga kelangsungan aplikasi Anda yang di-deploy di OpenShift Container Platform diGoogle Cloud. Dokumen ini memberikan ringkasan opsi arsitektur untuk DR dengan OpenShift di Google Cloud, sehingga membantu organisasi Anda mencapai waktu henti minimum dan pemulihan cepat jika terjadi bencana.

Dokumen ini ditujukan bagi administrator sistem, arsitek cloud, dan developer aplikasi yang bertanggung jawab untuk menjaga ketersediaan dan ketahanan aplikasi di OpenShift Container Platform yang di-deploy diGoogle Cloud.

Dokumen ini adalah bagian dari rangkaian yang berfokus pada strategi tingkat aplikasi yang memastikan beban kerja Anda tetap sangat tersedia dan dapat dipulihkan dengan cepat jika terjadi kegagalan. Dokumen dalam rangkaian ini adalah sebagai berikut:

Perencanaan DR

Merencanakan DR adalah komponen penting untuk menjalankan workload produksi di cloud. Meskipun OpenShift dan Google Cloud menawarkan redundansi tingkat infrastruktur yang andal, Anda juga harus mendesain dan mengonfigurasi aplikasi agar dapat pulih dengan cepat dari kegagalan yang parah.

Perencanaan DR yang efektif melibatkan pendekatan berlapis. Anda memulai dengan menentukan batas waktu pemulihan (RTO) dan toleransi durasi kehilangan data (RPO) yang jelas untuk aplikasi dan sistem Anda agar dapat di-deploy ulang dengan cepat.

Terakhir, rahasia dan kredensial Anda juga harus dapat dipulihkan dan dikelola dengan aman. Dengan mempertimbangkan semua faktor ini, Anda dapat mencapai postur DR yang memungkinkan Anda membuat cluster OpenShift baru dengan cepat di region yang berbeda atau melakukan failover ke cluster sekunder yang tidak aktif. Cluster sekunder ini tetap offline hingga terjadi kegagalan, yang kemudian akan dimulai dan diaktifkan untuk mengambil alih operasi dengan waktu henti minimum.

Arsitektur untuk DR

Ada berbagai opsi untuk arsitektur deployment yang dapat Anda gunakan untuk DR dengan OpenShift di Google Cloud. Setiap opsi ini memiliki implikasi yang berbeda-beda terhadap biaya, kompleksitas, dan ketersediaan. Tabel berikut memberikan ringkasan arsitektur ini:

Arsitektur Deskripsi Kasus penggunaan Kelebihan Kekurangan
Aktif-pasif Satu cluster aktif, menangani semua traffic, dan cluster lainnya pasif dan siap mengambil alih. Data direplikasi ke cluster pasif. Cocok untuk aplikasi dengan persyaratan RTO dan RPO sedang. Lebih mudah diimplementasikan, biaya lebih rendah untuk cluster standby. RTO yang lebih tinggi karena waktu failover, potensi penundaan sinkronisasi data.
Aktif-tidak aktif Mirip dengan aktif-pasif, tetapi cluster yang tidak aktif tidak digunakan hingga terjadi peristiwa DR. Data dicadangkan secara rutin. Ideal untuk lingkungan yang sensitif terhadap biaya yang memungkinkan RTO dan RPO yang lebih tinggi. Biaya operasional yang lebih rendah saat tidak aktif, cocok untuk DR saat sistem sekunder tidak berjalan secara aktif (DR dingin) . RTO yang lebih tinggi karena waktu aktivasi dan sinkronisasi, meskipun ada potensi data menjadi tidak berlaku.
Aktif-aktif Kedua cluster aktif, menangani traffic dengan load balancing dan replikasi data antar-region. Aplikasi penting yang memerlukan periode nonaktif minimal dan ketersediaan tinggi. RTO dan RPO terendah, ketersediaan berkelanjutan. Kompleksitas dan biaya tertinggi, memerlukan sinkronisasi data dan jaringan yang andal.

Langkah berikutnya