Strategi pemulihan dari bencana untuk penyiapan aktif-nonaktif

Dokumen ini menjelaskan cara merencanakan dan menerapkan pemulihan dari bencana aktif-nonaktif untuk deployment OpenShift di Google Cloud guna membantu Anda mencapai waktu non-operasional minimal dan pemulihan cepat jika terjadi bencana. Panduan ini memberikan praktik terbaik untuk mencadangkan data, mengelola konfigurasi sebagai kode, dan menangani secret untuk membantu memastikan Anda dapat memulihkan aplikasi dengan 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 Red Hat OpenShift Container Platform yang di-deploy di Google Cloud.

Dokumen ini adalah bagian dari seri yang berfokus pada strategi tingkat aplikasi yang memastikan beban kerja Anda tetap sangat tersedia dan dapat dipulihkan dengan cepat jika terjadi kegagalan. Panduan ini mengasumsikan bahwa Anda telah membaca Praktik terbaik untuk pemulihan dari bencana. Dokumen dalam seri ini adalah sebagai berikut:

Arsitektur untuk pemulihan dari bencana

DR aktif-nonaktif melibatkan pemeliharaan region sekunder sebagai standby, yang diaktifkan hanya selama bencana. Tidak seperti penyiapan aktif-pasif, tempat data direplikasi secara terus-menerus, strategi ini mengandalkan pencadangan berkala yang disimpan di Cloud Storage, dengan infrastruktur yang disediakan dan data dipulihkan selama failover. Anda dapat menggunakan alat seperti Velero, yang terintegrasi dengan OpenShift API for Data Protection (OADP), untuk melakukan pencadangan berkala. Pendekatan ini meminimalkan biaya, sehingga ideal untuk aplikasi yang dapat mentoleransi waktu pemulihan yang lebih lama. Solusi ini juga dapat membantu organisasi untuk menyelaraskan dengan batas waktu pemulihan (RTO) dan toleransi durasi kehilangan data (RPO) yang diperpanjang.

Dalam skenario DR aktif-nonaktif, data dicadangkan secara rutin ke region standby, tetapi tidak direplikasi secara aktif. Infrastruktur disediakan sebagai bagian dari proses failover dan data dipulihkan dari cadangan terbaru. Anda dapat menggunakan OpenShift API for Data Protection (OADP), yang didasarkan pada project open source Velero, untuk melakukan pencadangan rutin. Sebaiknya simpan cadangan ini di bucket Cloud Storage dengan pembuatan versi diaktifkan. Jika terjadi bencana, Anda dapat menggunakan OADP untuk memulihkan konten cluster. Pendekatan ini meminimalkan biaya berkelanjutan, tetapi menghasilkan RTO yang lebih lama dan RPO yang berpotensi lebih tinggi dibandingkan dengan aktif-pasif. Penyiapan ini cocok untuk aplikasi dengan tujuan waktu pemulihan yang lebih lama.

Diagram berikut menunjukkan deployment aktif-tidak aktif dan proses failover:

Proses failover.

Proses failover adalah sebagai berikut:

  1. Peristiwa DR dipicu saat layanan yang dipantau menjadi tidak tersedia.
  2. Pipeline akan otomatis menyediakan infrastruktur di region DR.
  3. Cluster OpenShift baru disediakan.
  4. Data, rahasia, dan objek aplikasi dipulihkan dari cadangan terbaru melalui OADP.
  5. Data Cloud DNS diperbarui untuk mengarah ke load balancer regional di region DR.

Seperti yang ditunjukkan dalam diagram sebelumnya, dua cluster regional OpenShift terpisah di-deploy, masing-masing di region Google Cloud yang berbeda, seperti us-central1 dan europe-west1. Setiap cluster harus memiliki ketersediaan tinggi dalam regionnya dan menggunakan beberapa zona untuk memungkinkan redundansi.

Deskripsi komponen dalam skenario DR aktif-tidak aktif

Arsitektur ini memiliki konfigurasi berikut:

  • Region utama (Region A): Berisi cluster OpenShift yang beroperasi penuh dan melayani traffic produksi.
  • Region sekunder (Region B): Awalnya berisi resource minimal (VPC dan subnet). Infrastruktur (instance Compute Engine dan OCP) disediakan selama failover.
  • Penyimpanan cadangan: Bucket Google Cloud Storage menyimpan cadangan berkala (OADP atau Velero untuk objek aplikasi, serta PV dan cadangan database). Sebaiknya gunakan pembuatan versi dan replikasi lintas region untuk bucket.
  • Pengelolaan konfigurasi: Repositori Git menyimpan Infrastructure as Code (IaC, misalnya, Terraform) dan manifes Kubernetes atau OpenShift (untuk GitOps).
  • Alat pencadangan: OADP (Velero) dikonfigurasi di cluster utama untuk melakukan pencadangan terjadwal ke Cloud Storage.
  • Orkestrasi: Skrip atau alat otomatisasi memicu proses penyediaan dan pemulihan infrastruktur selama failover.

Produk yang digunakan

Kasus penggunaan

DR aktif-nonaktif direkomendasikan untuk kasus penggunaan berikut:

  • Aplikasi yang dapat mentoleransi RTO yang lebih lama (misalnya, beberapa menit hingga jam).
  • Lingkungan yang mengutamakan pengoptimalan biaya, dan biaya cluster standby yang berjalan terus-menerus sangat mahal. Biaya berkelanjutan utama adalah untuk penyimpanan objek, bukan untuk menjalankan instance komputasi.
  • Workload pengembangan, pengujian, atau produksi yang kurang penting.
  • Sistem pemrosesan batch atau pengarsipan yang waktu pemulihannya kurang penting.

Pertimbangan desain

Bagian ini menjelaskan faktor desain, praktik terbaik, dan rekomendasi desain yang harus Anda pertimbangkan saat menggunakan arsitektur referensi ini untuk mengembangkan topologi yang memenuhi persyaratan spesifik Anda untuk keamanan, keandalan, biaya, dan performa.

Konfigurasi aplikasi sebagai kode (GitOps)

Sebaiknya Anda menerapkan pendekatan GitOps untuk menyimpan semua konfigurasi cluster dan aplikasi di repositori Git. Pendekatan ini memungkinkan pemulihan cepat dalam skenario DR dengan mengaktifkan sinkronisasi ke status yang diketahui berjalan dengan andal di cluster lain. Pencadangan memastikan Anda memiliki snapshot status runtime, tetapi, Anda juga memerlukan cara yang andal untuk men-deploy ulang logika aplikasi, manifes, dan definisi infrastruktur dengan cepat setelah bencana.

Menggunakan Operator GitOps OpenShift

Operator OpenShift GitOps, yang didasarkan pada Argo CD, menyediakan cara yang didukung Red Hat untuk menerapkan pola GitOps langsung dalam lingkungan OpenShift. Hal ini mengotomatiskan proses terus-menerus menyelaraskan status cluster Anda dengan konfigurasi yang Anda pilih dan menyimpannya di repositori Git.

Pengontrol operator OpenShift GitOps terus memastikan bahwa status cluster cocok dengan konfigurasi yang ditentukan di repositori ini. Jika sumber daya mengalami penyimpangan atau hilang, sumber daya tersebut akan otomatis disesuaikan. Untuk mempelajari lebih lanjut, lihat Tentang Red Hat OpenShift GitOps.

Eksekusi skenario DR

Jika terjadi bencana, lakukan hal berikut:

  • Siapkan cluster OpenShift baru di region lain.
  • Instal operator OpenShift GitOps.
  • Terapkan manifes Aplikasi yang sama yang mereferensikan repositori Git Anda.

Operator menyinkronkan status cluster agar sesuai dengan repositori Anda, dengan cepat men-deploy ulang deployment, layanan, rute, operator, dan resource lain yang ditentukan dalam kode Anda.

Untuk membantu menghindari masalah selama DR, sebaiknya lakukan hal berikut:

  • Pertahankan strategi percabangan dan pemberian tag yang ketat di repositori Git Anda sehingga Anda dapat mengidentifikasi konfigurasi stabil yang sesuai untuk DR.
  • Periksa apakah cluster DR Anda memiliki konektivitas jaringan dan izin yang sesuai untuk mengakses repositori Git.
  • Sertakan semua jenis resource sebagai kode untuk menghindari intervensi manual selama pengalihan (misalnya, komponen infrastruktur, beban kerja aplikasi, dan konfigurasi).

Aturan firewall

Tentukan kebijakan firewall terpadu dan terapkan secara konsisten di kedua cluster untuk mengontrol alur traffic dan meningkatkan keamanan.

Ikuti prinsip hak istimewa terendah, yang berarti Anda membatasi traffic masuk dan keluar hanya untuk yang diperlukan bagi fungsi aplikasi.

Deployment

Untuk mempelajari cara men-deploy topologi berdasarkan arsitektur referensi ini, lihat dokumentasi Red Hat.

Langkah berikutnya