Strategi pemulihan dari bencana untuk penyiapan aktif-pasif

Dokumen ini menjelaskan cara merencanakan dan menerapkan aktif-pasif pemulihan dari bencana untuk deployment OpenShift di Google Cloud guna membantu Anda mencapai waktu nonaktif minimal dan pemulihan cepat jika terjadi bencana. Dokumen 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 untuk administrator sistem, arsitek cloud, dan developer aplikasi yang bertanggung jawab untuk mempertahankan ketersediaan dan ketahanan aplikasi di Red Hat OpenShift Container Platform yang di-deploy di Google 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 ini mengasumsikan bahwa Anda telah membaca Praktik terbaik untuk pemulihan dari bencana. Dokumen dalam rangkaian ini adalah sebagai berikut:

Arsitektur untuk pemulihan dari bencana

Diagram arsitektur berikut menunjukkan skenario deployment aktif-pasif untuk OpenShift di Google Cloud:

Deployment aktif-pasif, dijelaskan dalam teks berikut.

Seperti yang ditunjukkan dalam diagram sebelumnya, dalam deployment aktif-pasif untuk pemulihan dari bencana, cluster OpenShift di region utama menangani semua traffic produksi. Cluster sekunder di region lain tetap siap untuk mengambil alih jika cluster utama gagal. Penyiapan ini memastikan waktu nonaktif minimal dengan cluster sekunder yang telah disediakan sebelumnya dan dalam status hangat , yang berarti cluster tersebut disiapkan dengan komponen infrastruktur dan aplikasi yang diperlukan, tetapi tidak secara aktif melayani traffic hingga diperlukan. Data aplikasi direplikasi ke cluster pasif untuk meminimalkan kehilangan data, yang selaras dengan RPO.

Salah satu cluster regional bertindak sebagai situs utama (aktif) dan menangani semua traffic produksi. Cluster sekunder, di region lain, adalah standby untuk pemulihan dari bencana. Cluster sekunder tetap dalam status hangat, dan siap mengambil alih dengan penundaan minimal jika terjadi kegagalan cluster utama.

Deskripsi komponen dalam skenario DR aktif-pasif

Arsitektur ini memiliki konfigurasi berikut:

  • Cluster OpenShift utama (aktif): Terletak di region utama Google Cloud , cluster ini menjalankan beban kerja produksi dan secara aktif melayani semua traffic pengguna dalam kondisi operasi normal.
  • Cluster OpenShift sekunder (pasif): Terletak di Google Cloud region terpisah untuk isolasi kesalahan, cluster ini bertindak sebagai cluster standby hangat. Cluster ini disiapkan dan berjalan sebagian serta siap mengambil alih jika sistem utama gagal. Cluster ini memiliki infrastruktur, konfigurasi OpenShift, dan komponen aplikasi yang diperlukan yang di-deploy di dalamnya, tetapi tidak melayani traffic produksi langsung hingga peristiwa failover dipicu.
  • Google Cloud region: Lokasi yang terisolasi secara geografis yang menyediakan fondasi untuk pemulihan dari bencana. Penggunaan region terpisah memastikan bahwa peristiwa skala besar yang memengaruhi satu region tidak memengaruhi cluster standby.
  • Load Balancer HTTPS Eksternal Global: Bertindak sebagai satu titik entri global untuk traffic aplikasi. Dalam kondisi normal, load balancer ini dikonfigurasi untuk merutekan semua traffic ke cluster utama (aktif). Health check-nya memantau ketersediaan cluster utama.
  • Mekanisme replikasi data: Proses atau alat berkelanjutan yang bertanggung jawab untuk menyalin data aplikasi penting dari cluster utama ke cluster sekunder cluster (misalnya, status database atau volume persisten). Pendekatan ini memastikan konsistensi data dan meminimalkan kehilangan data selama failover, sehingga membantu Anda memenuhi RPO.
  • Pemantauan dan health check: Sistem yang terus-menerus menilai kesehatan dan ketersediaan cluster utama dan aplikasinya, misalnya, Cloud Monitoring, health check load balancer, pemantauan cluster internal. Sistem ini penting untuk deteksi cepat kegagalan apa pun.
  • Mekanisme failover: Proses yang telah ditentukan sebelumnya (manual, semi-otomatis, atau sepenuhnya otomatis) untuk mengalihkan traffic dari cluster utama ke cluster sekunder setelah mendeteksi kegagalan yang tidak dapat dipulihkan di cluster utama. Proses ini biasanya melibatkan pembaruan konfigurasi backend Load Balancer Global untuk menargetkan cluster sekunder, sehingga menjadikannya situs aktif baru.
  • Jaringan VPC: Infrastruktur jaringan yang mendasarinya yang Google Cloud membuat konektivitas yang diperlukan antar-region untuk replikasi dan pengelolaan data.

Produk yang digunakan

Kasus penggunaan

DR aktif-pasif direkomendasikan untuk kasus penggunaan berikut:

  • Aplikasi yang memerlukan RTO yang lebih rendah (misalnya, menit hingga jam) daripada yang dapat dicapai dengan pemulihan dingin, tempat data dipulihkan dari cadangan yang tidak dapat langsung diakses.
  • Sistem yang memungkinkan replikasi data berkelanjutan dan RPO harus diminimalkan (misalnya, menit hingga detik).
  • Industri yang diatur dengan batas waktu nonaktif yang ketat dan aplikasi bisnis penting yang biaya pemeliharaan cluster standby hangatnya dibenarkan oleh dampak bisnis dari waktu nonaktif.

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.

Melindungi status dan konfigurasi aplikasi

OpenShift Container Platform menyediakan OADP dan menawarkan perlindungan pemulihan dari bencana yang komprehensif untuk aplikasi yang berjalan di cluster. Anda dapat menggunakannya untuk mencadangkan objek Kubernetes dan OpenShift yang digunakan oleh aplikasi dalam container dan mesin virtual (misalnya, deployment, layanan, rute, PVC, ConfigMap, secret, dan CRD). Namun, OADP tidak mendukung pencadangan dan pemulihan cluster penuh. Untuk mempelajari cara mengonfigurasi dan menjadwalkan pencadangan, serta cara memulihkan operasi, lihat dokumentasi Red Hat.

OADP menyediakan proses pencadangan dan pemulihan untuk volume persisten yang mengandalkan penyimpanan blok dan penyimpanan NFS yang digunakan oleh aplikasi. Anda dapat melakukan tindakan pada proses ini menggunakan alat seperti Restic atau Kopia untuk mengambil snapshot atau melakukan pencadangan tingkat file.

OADP berguna untuk mencadangkan definisi objek, memastikan konsistensi konfigurasi, dan berpotensi memulihkan aplikasi atau namespace tertentu jika diperlukan, yang melengkapi replikasi data.

Untuk lebih mengurangi RPO dan RTO dalam konfigurasi aktif-pasif, sebaiknya konfigurasi replikasi data antara region utama dan sekunder.

Replikasi data penting untuk memastikan cluster sekunder dapat mengambil alih dengan lancar. Seperti yang diuraikan di bagian berikut, penerapan replikasi data dari cluster utama ke sekunder bergantung pada jenis penyimpanan yang digunakan aplikasi.

Block storage (volume persisten)

Gunakan Replikasi Asinkron Persistent Disk Google untuk menyalin data dari region utama ke sekunder. Dalam pendekatan ini, Anda membuat disk utama di region utama, disk sekunder di region sekunder, dan menyiapkan replikasi di antara keduanya. Penggunaan grup yang konsisten memastikan bahwa kedua disk berisi data replikasi dari titik waktu umum, yang kemudian digunakan untuk DR. Untuk mempelajari lebih lanjut, lihat Mengonfigurasi Replikasi Asinkron Persistent Disk.

Objek PersistentVolume

Di OpenShift, buat objek PersistentVolume di kedua cluster yang ditautkan ke disk ini, dan pastikan aplikasi menggunakan Persistent Volume Claim (PVC) yang sama di kedua cluster.

Replikasi tingkat aplikasi

Beberapa aplikasi (misalnya, database dan antrean pesan) memiliki fitur replikasi bawaan yang dapat Anda konfigurasi di seluruh cluster. Anda juga dapat menggunakan layanan terkelola seperti Pub/Sub untuk memfasilitasi replikasi untuk jenis data atau peristiwa aplikasi tertentu.

Cadangan database

Aplikasi dapat bergantung pada berbagai jenis produk database. Untuk membantu menguraikan pertimbangan desain untuk pencadangan database, dokumen ini menggunakan PostgreSQL sebagai contoh database.

Cadangan yang dihosting sendiri menggunakan operator database dalam cluster

Operator database seperti CloudNative PostgreSQL Operator dapat memfasilitasi pencadangan terjadwal dan pemulihan dari bencana untuk cluster PostgreSQL. CloudNative PostgreSQL Operator terintegrasi secara native dengan alat seperti pg_basebackup dan mendukung pencadangan replikasi streaming. Anda dapat menyimpan cadangan di layanan penyimpanan cloud seperti Google Cloud Storage (Cloud Storage) untuk ketahanan dan pemulihan.

Anda dapat menyiapkan replikasi streaming antara cluster regional utama dan sekunder untuk memastikan bahwa, bahkan jika terjadi pemadaman layanan di region utama, data tetap tersedia. Replikasi streaming ini biasanya sinkron dalam satu region, dan asinkron di seluruh region. Untuk langkah-langkah konfigurasi mendetail, lihat dokumentasi CloudNativePG.

Jika terjadi bencana, Anda dapat memulihkan cadangan ke cluster PostgreSQL baru, sehingga memastikan waktu nonaktif dan kehilangan data minimal. Berikut adalah contoh cuplikan konfigurasi untuk mengaktifkan pencadangan terjadwal menggunakan CloudNative PostgreSQL Operator:

apiVersion: postgresql.cnpg.io/v1
kind: ScheduledBackup
metadata:
  name: backup-example
spec:
  schedule: "0 0 0 * * *"
  backupOwnerReference: self
cluster:
  name: pg-backup

Layanan terkelola

Database terkelola seperti Cloud SQL memiliki fitur pencadangan dan replikasi bawaan. Sebaiknya siapkan replikasi asinkron dari instance database utama ke replika di region sekunder. Untuk mempelajari lebih lanjut, lihat Tentang replikasi di Cloud SQL. Di OpenShift, konfigurasi secret atau config map untuk mengarah ke string koneksi database yang benar untuk setiap cluster.

Karena replikasi asinkron menghasilkan RPO bukan nol, ada potensi kehilangan penulisan data terbaru. Anda harus mendesain aplikasi untuk mengurangi kehilangan data. Atau, pertimbangkan untuk menggunakan metode replikasi lain.

Sebaiknya aktifkan juga pencadangan otomatis Cloud SQL. Untuk mempelajari lebih lanjut, lihat Membuat dan mengelola pencadangan on-demand dan otomatis.

Proses failover

Jika terjadi kegagalan cluster utama, Cloud DNS akan otomatis mengalihkan traffic ke cluster regional sekunder berdasarkan health check dan kebijakan failover.

Saat dipromosikan dari replika baca ke utama, cluster sekunder akan mengambil alih sebagai situs aktif dan melayani traffic produksi. Promosi ini diperlukan agar dapat menerima penulisan database.

Untuk menyiapkan DR untuk Cloud SQL, ikuti langkah-langkah yang dijelaskan dalam dokumentasi disaster recovery Google Cloud SQL. Menggunakan replikasi database atau penyimpanan asinkron menyebabkan RPO bukan nol untuk membantu memastikan aplikasi Anda dapat mentoleransi kehilangan penulisan terbaru. Atau, pertimbangkan untuk menggunakan metode replikasi lain.

Pengelolaan secret yang aman

Secret seperti sandi database, kunci API, dan sertifikat TLS adalah aspek penting dari DR. Anda harus dapat memulihkan secret ini dengan aman dan andal di cluster baru.

Pendekatan umum untuk pengelolaan secret adalah sebagai berikut:

  • Menggunakan secret eksternal: Gunakan alat seperti operator secret eksternal untuk mengambil secret dari Google Secret Manager.
  • Mencadangkan secret dengan OADP Operator: Jika Anda tidak menggunakan penyimpanan eksternal, pastikan secret disertakan dalam cadangan Anda.
  • Rotasi reguler: Rotasi secret secara rutin dan pastikan strategi pengelolaan secret Anda mengakomodasi skenario DR.
  • Pengujian: Uji pemulihan secret di lingkungan bertahap untuk mengonfirmasi bahwa semua layanan dapat dimulai dengan kredensial yang diberikan.
  • Validasi: Validasi bahwa cluster DR Anda memiliki peran IAM atau metode autentikasi yang diperlukan untuk mengambil secret dari penyimpanan eksternal.

Pengelolaan jaringan dan traffic

Gunakan Load Balancer HTTPS Eksternal Global Google Cloudsebagai titik ingress utama untuk mendistribusikan traffic antara beberapa cluster OpenShift (misalnya, cluster utama dan sekunder). Layanan global ini mengarahkan permintaan pengguna ke cluster backend yang sesuai berdasarkan kedekatan, kesehatan, dan ketersediaan.

Untuk menghubungkan Load Balancer Global ke cluster OpenShift, Anda dapat menggunakan salah satu pendekatan berikut:

  • Menggunakan load balancer regional (NEG internet): Konfigurasi Google Cloud grup endpoint jaringan (NEG) internet untuk mengarah ke alamat IP eksternal Load Balancer Regional yang mengekspos setiap layanan ingress cluster OpenShift Anda (Router OCP). Load Balancer Global kemudian merutekan traffic ke IP load balancer regional ini. Pendekatan ini menyediakan lapisan abstraksi, tetapi melibatkan hop ke jaringan tambahan.
  • Perutean Pod Langsung (Compute Engine_VM_IP_PORT NEGs): Konfigurasi integrasi Pengontrol Ingress OpenShift untuk menggunakan Google Cloud Grup Endpoint Jaringan (NEG) berjenis Compute Engine_VM_IP_PORT. Pendekatan ini memungkinkan Load Balancer Global menargetkan pod Pengontrol Ingress OpenShift (Router) secara langsung menggunakan PodIP:TargetPort internalnya. Metode ini melewati hop tambahan dan proxy node tambahan. Biasanya menghasilkan latensi yang lebih rendah, dan memungkinkan health check yang lebih langsung dari load balancer global.

Kedua penyiapan memungkinkan Load Balancer Global mengelola distribusi traffic secara efektif di seluruh cluster di berbagai region. Untuk mempelajari lebih lanjut, lihat Menyiapkan Load Balancer Aplikasi eksternal global dengan backend eksternal.

VPC

Sebaiknya gunakan pendekatan berikut untuk pengelolaan VPC:

  • VPC Bersama: Gunakan VPC Bersama untuk memusatkan pengelolaan jaringan untuk cluster utama dan sekunder. Pendekatan ini menyederhanakan administrasi dan memastikan kebijakan jaringan yang konsisten di seluruh region.
  • Perutean Dinamis Global: Aktifkan Perutean Dinamis Global dalam VPC Anda untuk otomatis menyebarkan rute antar-region, sehingga memastikan konektivitas yang lancar antar-cluster.
  • VPC Mode Kustom: Gunakan VPC mode kustom dan buat subnet tertentu di region tempat cluster Anda berjalan. Hal ini sering kali diperlukan untuk jaringan pod native VPC yang diperlukan oleh metode seperti perutean Compute Engine_VM_IP_PORT.
  • Peering Jaringan VPC: Jika Anda perlu menggunakan jaringan VPC terpisah untuk setiap region dan cluster, gunakan Peering Jaringan VPC untuk menghubungkan region dan cluster.

Subnet dan alamat IP

Buat subnet regional di setiap region untuk mempertahankan segmentasi jaringan dan menghindari konflik alamat IP.

Pastikan ada rentang IP yang tidak tumpang tindih antar-region untuk mencegah masalah perutean.

Traffic lintas cluster dengan Red Hat Service Mesh

OpenShift mendukung federasi Service Mesh, yang memungkinkan komunikasi antara layanan yang di-deploy di beberapa cluster OpenShift. Fungsi ini sangat berguna untuk skenario DR ketika layanan mungkin perlu berkomunikasi di seluruh cluster selama failover atau replikasi data.

Untuk mempelajari cara menyiapkan federasi Service Mesh antara cluster utama dan sekunder, lihat dokumentasi Red Hat.

Deployment

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

Langkah berikutnya