OpenShift di Google Cloud: Strategi Pemulihan dari Bencana untuk penyiapan aktif-pasif dan aktif-nonaktif

Dokumen ini menjelaskan cara merencanakan dan menerapkan pemulihan bencana aktif-pasif dan 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 untuk 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. Panduan ini mengasumsikan bahwa Anda telah membaca Praktik terbaik untuk pemulihan dari bencana dengan OpenShift. Dokumen dalam seri ini adalah sebagai berikut:

Arsitektur untuk pemulihan dari bencana

Bagian ini menjelaskan arsitektur untuk skenario pemulihan dari bencana aktif-pasif dan aktif-nonaktif.

Produk yang digunakan

Deployment aktif-pasif

Diagram berikut menunjukkan skenario deployment pasif-aktif 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 yang berbeda tetap siap untuk mengambil alih jika cluster utama gagal. Penyiapan ini memastikan waktu henti minimum dengan menyediakan cluster sekunder dan dalam status siap, 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, sesuai dengan RPO.

Salah satu cluster regional bertindak sebagai situs utama (aktif) dan menangani semua traffic produksi. Cluster sekunder, di region yang berbeda, adalah standby untuk pemulihan dari bencana. Cluster sekunder tetap dalam status aktif, 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 Google Cloud utama, 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 berfungsi sebagai cluster standby aktif. Sistem ini disiapkan dan dijalankan sebagian serta siap untuk mengambil alih jika sistem utama gagal. Lingkungan ini memiliki infrastruktur yang diperlukan, konfigurasi OpenShift, dan komponen aplikasi 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 dasar untuk pemulihan dari bencana. Menggunakan region terpisah memastikan bahwa peristiwa berskala besar yang memengaruhi satu region tidak akan memengaruhi cluster standby.
  • Load Balancer HTTPS Eksternal Global: Berfungsi sebagai titik masuk global tunggal untuk traffic aplikasi. Dalam kondisi normal, load balancer 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 (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 kondisi dan ketersediaan cluster utama dan aplikasinya, misalnya, Cloud Monitoring, health check load balancer, pemantauan cluster internal. Sistem ini penting untuk mendeteksi kegagalan dengan cepat.
  • Mekanisme failover: Proses yang telah ditentukan sebelumnya (manual, semi-otomatis, atau sepenuhnya otomatis) untuk mengalihkan traffic dari cluster utama ke cluster sekunder setelah terdeteksi kegagalan yang tidak dapat dipulihkan di cluster utama. Proses ini biasanya melibatkan pembaruan konfigurasi backend Global Load Balancer untuk menargetkan cluster sekunder, sehingga menjadikannya situs aktif baru.
  • Jaringan VPC: Infrastruktur jaringan Google Cloud yang mendasarinya yang menciptakan konektivitas yang diperlukan antar-region untuk replikasi dan pengelolaan data.

Deployment aktif-tidak aktif

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. Layanan ini juga dapat membantu organisasi menyelaraskan dengan batas waktu pemulihan (RTO) dan toleransi durasi kehilangan data (RPO) yang diperpanjang.

Dalam skenario DR aktif-tidak aktif, 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-nonaktif 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, secret, 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 cadangan PV dan database). Sebaiknya gunakan pembuatan versi dan replikasi lintas region untuk bucket.
  • Pengelolaan konfigurasi: Repositori Git menyimpan Infrastruktur sebagai Kode (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 pemulihan dan penyediaan infrastruktur selama failover.

Kasus penggunaan

Bagian ini memberikan contoh berbagai kasus penggunaan untuk deployment aktif-pasif dan aktif-tidak aktif.

Kasus penggunaan DR aktif-pasif

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, di mana data dipulihkan dari cadangan yang tidak dapat langsung diakses.
  • Sistem yang memungkinkan replikasi data berkelanjutan dan RPO harus diminimalkan (misalnya, menit hingga detik).
  • Industri teregulasi dengan batas periode nonaktif yang ketat dan aplikasi bisnis penting yang biaya pemeliharaan cluster standby aktifnya dapat dibenarkan oleh dampak periode nonaktif terhadap bisnis.

Kasus penggunaan DR aktif-nonaktif

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 produksi pengembangan, pengujian, atau 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 terkait keamanan, keandalan, biaya, dan performa.

Pertimbangan desain aktif-pasif

Bagian ini menjelaskan pertimbangan desain untuk skenario DR aktif-pasif.

Mengamankan status dan konfigurasi aplikasi

OpenShift Container Platform menyediakan OADP dan menawarkan perlindungan pemulihan bencana yang komprehensif untuk aplikasi yang berjalan di cluster. Anda dapat menggunakannya untuk mencadangkan objek Kubernetes dan OpenShift yang digunakan oleh aplikasi yang di-container dan virtual machine (misalnya, deployment, layanan, rute, PVC, ConfigMap, secret, dan CRD). Namun, OADP tidak mendukung pencadangan dan pemulihan kluster 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 dengan menggunakan alat Restic atau Kopia untuk membuat snapshot atau melakukan pencadangan tingkat file.

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

Untuk lebih mengurangi RPO dan RTO dalam konfigurasi aktif-pasif, sebaiknya konfigurasi replikasi data antara region primer 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 cluster 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 region 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 yang sama, 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 PersistentVolumeClaim (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. (misalnya, database dan antrean pesan).

Pencadangan database

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

Pencadangan 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. Operator CloudNative PostgreSQL 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 primer dan sekunder untuk memastikan bahwa, bahkan jika terjadi pemadaman di region primer, data tetap tersedia. Replikasi streaming ini biasanya bersifat sinkron dalam satu region, dan asinkron di seluruh region. Untuk mengetahui langkah-langkah konfigurasi yang mendetail, lihat dokumentasi CloudNativePG.

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

        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 non-nol, ada potensi kehilangan penulisan data terbaru. Anda harus mendesain aplikasi untuk memitigasi kehilangan data. Atau, pertimbangkan untuk menggunakan metode replikasi lain.

Sebaiknya Anda juga mengaktifkan 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 cluster sekunder dipromosikan dari replika baca menjadi cluster utama, cluster tersebut 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 Pemulihan dari bencana (disaster recovery) Google Cloud SQL. Menggunakan replikasi database atau penyimpanan asinkron menyebabkan RPO non-nol untuk membantu memastikan bahwa 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 DR. Anda harus dapat memulihkan secret ini dengan aman dan andal di cluster baru.

Pendekatan umum untuk pengelolaan rahasia adalah sebagai berikut:

  • Gunakan secret eksternal: Gunakan alat seperti operator secret eksternal untuk mengambil secret dari Google Secret Manager.
  • Mencadangkan secret dengan Operator OADP: Jika Anda tidak menggunakan penyimpanan eksternal, pastikan secret disertakan dalam cadangan Anda.
  • Rotasi reguler: Rotasi rahasia secara rutin dan pastikan strategi pengelolaan rahasia Anda mengakomodasi skenario DR.
  • Pengujian: Uji pemulihan rahasia 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.

Networking dan pengelolaan traffic

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

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

  • Gunakan 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). Kemudian, Load Balancer Global mengarahkan 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 Network Endpoint Groups (NEG) berjenis Compute Engine_VM_IP_PORT. Pendekatan ini memungkinkan Load Balancer Global menargetkan pod OpenShift Ingress Controller (Router) secara langsung menggunakan PodIP:TargetPort internalnya. Metode ini melewati hop tambahan dan proxying node tambahan. Hal ini biasanya menghasilkan latensi yang lebih rendah, dan memungkinkan health check yang lebih langsung dari load balancer global.

Kedua penyiapan memungkinkan Global Load Balancer 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

Kami merekomendasikan pendekatan berikut untuk pengelolaan VPC:

  • VPC Bersama: Gunakan VPC Bersama untuk memusatkan pengelolaan jaringan bagi cluster primer 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 menyebarkan rute secara otomatis 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 VPC native 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.

Pertimbangan desain aktif-tidak aktif

Bagian ini menjelaskan pertimbangan desain untuk solusi DR aktif-nonaktif.

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. Proses 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 dalam 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