Dokumen ini ditujukan untuk administrator sistem, arsitek cloud, dan developer aplikasi yang bertanggung jawab mempertahankan ketersediaan dan ketahanan aplikasi di OpenShift Container Platform yang di-deploy di Google Cloud.
Dokumen ini adalah bagian dari rangkaian yang berfokus pada strategi tingkat aplikasi yang memastikan workload Anda tetap sangat tersedia dan dapat dipulihkan dengan cepat jika terjadi kegagalan. Dokumen dalam rangkaian ini adalah sebagai berikut:
- Praktik terbaik untuk pemulihan dari bencana (halaman ini)
- Praktik terbaik untuk ketersediaan tinggi
- Strategi pemulihan dari bencana untuk penyiapan aktif-pasif
- Strategi disaster recovery untuk penyiapan aktif-nonaktif
Perencanaan DR
Perencanaan DR adalah komponen penting untuk menjalankan workload produksi di cloud. Meskipun OpenShift dan Google Cloud menawarkan redundansi tingkat infrastruktur yang kuat, Anda juga harus mendesain dan mengonfigurasi aplikasi untuk pulih dengan cepat dari kegagalan besar.
Perencanaan DR yang efektif melibatkan pendekatan berlapis. Anda mulai dengan menentukan batas waktu pemulihan (RTO) dan toleransi durasi kehilangan data (RPO) yang jelas untuk aplikasi dan sistem Anda untuk deployment ulang yang cepat.
Secret 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 nonaktif minimal.
Arsitektur untuk DR
Ada berbagai opsi arsitektur deployment yang dapat Anda gunakan untuk DR dengan OpenShift di Google Cloud. Setiap opsi ini memiliki implikasi yang berbeda untuk 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 siaga. | RTO lebih tinggi karena waktu failover, potensi penundaan sinkronisasi data. |
| Aktif-nonaktif | Mirip dengan aktif-pasif, tetapi cluster nonaktif tidak digunakan hingga terjadi peristiwa DR. Data dicadangkan secara rutin. | Ideal untuk lingkungan yang sensitif terhadap biaya yang memungkinkan RTO dan RPO lebih tinggi. | Biaya operasional lebih rendah saat tidak aktif, cocok untuk DR saat sistem sekunder tidak berjalan aktif (DR dingin). | RTO 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 waktu nonaktif minimal dan ketersediaan tinggi. | RTO dan RPO terendah, ketersediaan berkelanjutan. | Kompleksitas dan biaya tertinggi, memerlukan jaringan dan sinkronisasi data yang kuat. |
Langkah berikutnya
- Pelajari cara me nerapkan pemantauan dan pemberitahuan untuk kesehatan cluster, status replikasi, keberhasilan pencadangan, dan performa aplikasi di lingkungan utama dan sekunder.
- Pelajari cara menginstal OpenShift di Google Cloud.
- Pelajari lebih lanjut solusi Red Hat di Google Cloud