Google menggunakan teknologi AI untuk menerjemahkan konten ke dalam bahasa pilihan Anda. Terjemahan AI mungkin mengandung kesalahan.

Pengalihan untuk Load Balancer Aplikasi eksternal global

Untuk melindungi dari gangguan infrastruktur atau kesalahan konfigurasi, Anda dapat merancang strategi failover untuk Load Balancer Aplikasi eksternal global. Strategi ini menggunakan Load Balancer Aplikasi eksternal regional dan merutekan traffic ke Load Balancer Aplikasi eksternal regional dari Load Balancer Aplikasi eksternal global untuk mempertahankan ketersediaan tinggi selama gangguan infrastruktur global atau kesalahan konfigurasi.

Dalam arsitektur failover, Anda men-deploy load balancer utama dan satu atau beberapa load balancer cadangan:

Load balancer utama adalah Load Balancer Aplikasi eksternal global yang menangani traffic klien selama operasi normal.
Load balancer cadangan adalah Load Balancer Aplikasi eksternal regional yang menerima traffic saat load balancer utama gagal dalam health check.

Failover dan failback adalah proses perutean traffic otomatis:

Failover terjadi saat Cloud DNS mendeteksi gangguan dan mengarahkan traffic dari load balancer utama ke load balancer cadangan.
Failback terjadi saat Cloud DNS membalikkan perutean ini dan mengalihkan traffic ke load balancer utama setelah health check berhasil.

Dokumen ini membahas failover dari Load Balancer Aplikasi eksternal global ke load balancer cadangan regional. Jika Anda ingin mengonfigurasi failover antara Load Balancer Aplikasi eksternal regional di berbagai region, lihat Ketersediaan tinggi untuk Load Balancer Aplikasi eksternal regional.

Alasan menggunakan load balancer regional untuk failover

Load Balancer Aplikasi eksternal regional berfungsi paling baik sebagai load balancer failover untuk Load Balancer Aplikasi eksternal global karena properti berikut:

Load Balancer Aplikasi eksternal regional bersifat mandiri dalam setiap regionGoogle Cloud dan juga diisolasi dari infrastruktur Load Balancer Aplikasi eksternal global yang berjalan di region yang sama.
Load Balancer Aplikasi eksternal regional dan Load Balancer Aplikasi eksternal global didasarkan pada proxy Envoy dan memproses traffic dengan cara yang serupa.

Untuk menerapkan failover global ke regional untuk Load Balancer Aplikasi eksternal global, buat dua atau lebih Load Balancer Aplikasi eksternal regional di region tempat Anda ingin traffic melakukan failover.

Strategi failover

Anda dapat menerapkan failover untuk Load Balancer Aplikasi eksternal global menggunakan strategi berikut:

Aktif-pasif (failover global ke regional): Anda men-deploy satu atau beberapa Load Balancer Aplikasi eksternal regional hanya untuk tujuan pencadangan. Dalam kondisi stabil, Cloud DNS di-resolve ke alamat IP Load Balancer Aplikasi eksternal global. Jika load balancer global gagal, Cloud DNS akan merutekan traffic ke load balancer regional cadangan. Konfigurasi ini menggunakan kebijakan pemilihan rute failover Cloud DNS.
Aktif-aktif (pengalihan global ke regional): Load Balancer Aplikasi eksternal global bertindak sebagai frontend edge yang menyediakan fungsi Cloud CDN seperti caching edge yang meneruskan permintaan ke Load Balancer Aplikasi eksternal regional menggunakan grup endpoint jaringan (NEG) internet dengan nama domain yang sepenuhnya memenuhi syarat (FQDN). Dalam kondisi stabil, traffic mengalir secara berurutan melalui kedua lapisan load balancing. Hal ini dapat dikonfigurasi menggunakan kebijakan pemilihan rute geolokasi Cloud DNS. Jika load balancer global mengalami gangguan, kebijakan perutean DNS akan melewati lapisan global dan merutekan traffic klien langsung ke load balancer regional.

Sebagai praktik terbaik, jika arsitektur Anda tidak mengandalkan load balancing backend global yang mendukung kapasitas, sebaiknya gunakan strategi aktif-aktif. Namun, jika aplikasi Anda secara eksplisit memerlukan load balancing backend global untuk mendistribusikan dan melimpahkan traffic di seluruh region berdasarkan kapasitas backend, terapkan strategi aktif-pasif.

Perbandingan strategi failover

Tabel berikut membandingkan strategi failover aktif-pasif dan aktif-aktif:

Atribut strategi	Aktif-pasif	Aktif-aktif
Aliran traffic dalam kondisi stabil	Klien → Load Balancer Aplikasi eksternal global → Backend	Klien → Load Balancer Aplikasi eksternal global → Load Balancer Aplikasi eksternal regional → Backend
Alur traffic status gagal	Klien → Load Balancer Aplikasi eksternal regional → Backend. Layanan tetap tersedia, tetapi mungkin mengalami latensi yang lebih tinggi karena hilangnya manfaat performa edge.	Klien → Load Balancer Aplikasi eksternal regional → Backend (melewati Load Balancer Aplikasi eksternal global). Layanan tetap tersedia, tetapi mungkin mengalami latensi yang lebih tinggi karena hilangnya manfaat performa edge.
Pengelolaan konfigurasi	Memerlukan sinkronisasi konfigurasi independen di seluruh load balancer global dan regional.	Lapisan global memerlukan konfigurasi minimal karena sebagian besar logika aplikasi berada di load balancer regional. Namun, Anda harus menduplikasi kebijakan keamanan edge (Cloud Armor) dan konfigurasi penghentian koneksi (sertifikat TLS) di kedua lapisan.
Verifikasi keandalan	Load Balancer Aplikasi eksternal regional tidak ada aktivitas dalam kondisi stabil. Pengujian berkala atau traffic tetesan DNS direkomendasikan.	Traffic dalam kondisi stabil terus-menerus menguji Load Balancer Aplikasi eksternal regional. Sebaiknya lakukan pengujian berkala atau kirimkan traffic trickle langsung ke load balancer regional.
Keamanan deployment progresif	Perubahan konfigurasi Load Balancer Aplikasi eksternal global berlaku secara global. Perubahan Load Balancer Aplikasi eksternal regional bersifat terisolasi, tetapi traffic dalam kondisi stabil tidak mengujinya.	Anda dapat menerapkan perubahan Load Balancer Aplikasi eksternal regional secara progresif, region demi region. Jika suatu region gagal, lapisan global akan otomatis mengalihkan traffic dari region tersebut ke region yang responsif.
Load balancing backend global	Didukung Load Balancer Aplikasi eksternal global dapat menyeimbangkan traffic di seluruh backend di berbagai region berdasarkan kapasitas.	Terbatas Load Balancer Aplikasi eksternal global merutekan traffic ke Load Balancer Aplikasi eksternal regional terdekat. Load balancer regional hanya menyeimbangkan traffic secara lokal dan tidak melimpahkan traffic ke seluruh region berdasarkan kapasitas backend.
Biaya dan penagihan	Biaya pemrosesan data berlaku untuk satu lapisan load balancing. Dalam kondisi stabil, biaya berasal dari Load Balancer Aplikasi eksternal global; biaya untuk Load Balancer Aplikasi eksternal regional hanya berlaku selama pengujian atau peristiwa failover.	Kedua lapisan load balancing menghasilkan biaya pemrosesan data secara bersamaan karena traffic mengalir melalui tingkat global dan regional dalam kondisi stabil.
Kasus penggunaan yang direkomendasikan	Beban kerja yang memerlukan load balancing backend global tingkat lanjut dan pelimpahan traffic berbasis kapasitas di seluruh region.	Beban kerja yang didesain di sekitar isolasi regional yang menggunakan lapisan global untuk performa dan caching edge.

Strategi aktif-pasif

Dalam konfigurasi aktif-pasif, Anda men-deploy Load Balancer Aplikasi eksternal regional independen di satu atau beberapa region bersama dengan Load Balancer Aplikasi eksternal global atau Load Balancer Aplikasi klasik utama Anda.

Cara kerja failover aktif-pasif

Penyiapan berikut menunjukkan failover dari Load Balancer Aplikasi eksternal global ke dua Load Balancer Aplikasi eksternal regional cadangan, dengan satu di setiap region tempat load balancer global telah men-deploy backend.

Pengalihan dari Load Balancer Aplikasi eksternal global ke dua Load Balancer Aplikasi eksternal regional. — Pengalihan dari Load Balancer Aplikasi eksternal global ke dua Load Balancer Aplikasi eksternal regional (klik untuk memperbesar).

Failover aktif-pasif mengikuti alur kerja berikut:

Kondisi stabil: Cloud DNS mengarahkan semua traffic klien ke Load Balancer Aplikasi eksternal global.
Deteksi kegagalan: Google Cloud menggunakan pemeriksaan kondisi yang dikonfigurasi dengan tiga region sumber untuk mendeteksi apakah load balancer utama responsif. Jika health check yang berasal dari dua atau lebih region sumber gagal, Cloud DNS akan memicu failover.
Failover: Kebijakan pemilihan rute failover Cloud DNS mengarahkan traffic klien langsung ke Load Balancer Aplikasi eksternal regional cadangan. Dampak latensi selama failover: Karena Load Balancer Aplikasi eksternal regional menghentikan koneksi dalam Google Cloud region tertentu, klien yang berada jauh dari region tujuan mungkin mengalami peningkatan latensi dan waktu perjalanan pulang pergi (RTT) saat failover aktif.
Failback: Setelah health check berhasil lagi, Cloud DNS akan otomatis memulihkan traffic ke load balancer utama tanpa waktu henti karena kedua load balancer melayani traffic.

Strategi aktif-aktif (pengabaian global ke regional)

Dalam strategi aktif-aktif, Load Balancer Aplikasi eksternal global menggunakan NEG FQDN internet (INTERNET_FQDN_PORT) untuk mengirim traffic ke Load Balancer Aplikasi eksternal regional di dua region atau lebih.

Cara kerja bypass aktif-aktif

Failover aktif-aktif mengikuti alur kerja ini:

Kondisi stabil: Traffic mengalir dari klien ke Load Balancer Aplikasi eksternal global. Load balancer global menggunakan grup endpoint jaringan (NEG) FQDN internet dengan jenis INTERNET_FQDN_PORT untuk meneruskan traffic ke Load Balancer Aplikasi eksternal regional terdekat. Load balancer regional kemudian mengirimkan traffic ke backend lokal.
Deteksi kegagalan: Dalam kondisi stabil, jika satu Load Balancer Aplikasi eksternal regional atau regionnya gagal, Load Balancer Aplikasi eksternal global akan mendeteksi kegagalan tersebut menggunakan kebijakan health check Cloud DNS pada NEG internet. Load balancer global akan otomatis merutekan traffic dari region yang bermasalah ke load balancer regional yang berfungsi dengan baik.
Bypass: Jika Load Balancer Aplikasi eksternal global mengalami gangguan, kebijakan failover Cloud DNS akan mendeteksi kegagalan dan merutekan traffic langsung ke Load Balancer Aplikasi eksternal regional, dengan sepenuhnya melewati lapisan global. Dampak latensi selama melewati: Load Balancer Aplikasi eksternal global memberikan manfaat performa edge seperti menghentikan koneksi lebih dekat dengan pengguna dan caching edge. Saat traffic melewati load balancer global, koneksi klien dibuat langsung dengan VIP regional, yang dapat meningkatkan latensi koneksi dan RTT untuk klien yang berlokasi jauh secara geografis.
Failback: Saat load balancer global lulus health check berturut-turut, Cloud DNS akan otomatis melanjutkan menampilkan VIP Anycast global dalam respons DNS, sehingga memulihkan tingkat perutean edge global.

Meninjau konfigurasi load balancer utama

Sebelum mengonfigurasi failover, pastikan Load Balancer Aplikasi eksternal regional cadangan mendukung fitur yang digunakan oleh load balancer utama.

Dalam mode aktif-pasif, load balancer regional cadangan harus mendukung fitur serupa untuk mengambil alih traffic dengan lancar selama pemadaman layanan.
Dalam mode active-active, aturan perutean dan keamanan inti harus dikonfigurasi langsung di tingkat regional, sementara fitur edge global, seperti Cloud CDN, dilewati selama gangguan global.

Fitur	Persyaratan kompatibilitas
Deployment Google Kubernetes Engine	Gunakan Gateway GKE untuk men-deploy load balancer utama dan cadangan. Hal ini karena load balancer yang di-deploy menggunakan GKE Gateway lebih kompatibel dengan mekanisme failover ini daripada load balancer yang di-deploy menggunakan pengontrol Ingress GKE. Pengontrol Ingress GKE hanya mendukung Load Balancer Aplikasi klasik.
Cloud CDN	Load Balancer Aplikasi eksternal regional tidak mendukung Cloud CDN. Jika terjadi failover, operasi yang mengandalkan Cloud CDN akan terpengaruh.
Cloud Armor	Jika Anda menggunakan Cloud Armor di load balancer utama, konfigurasikan kebijakan keamanan Cloud Armor regional yang setara di load balancer cadangan. Cloud Armor memiliki berbagai fitur yang tersedia dalam cakupan regional dan global. Untuk mengetahui informasi selengkapnya, lihat Kebijakan keamanan Cloud Armor regional dan Kebijakan keamanan Cloud Armor global.
Sertifikat SSL	Pastikan jenis sertifikat SSL yang digunakan oleh load balancer utama kompatibel dengan Load Balancer Aplikasi eksternal regional cadangan. Tinjau perbedaan antara sertifikat SSL yang tersedia dengan load balancer global, regional, dan klasik. Untuk mengetahui informasi selengkapnya, lihat Sertifikat SSL Compute Engine dan Sertifikat SSL Certificate Manager.

Pertimbangan untuk load balancer regional

Konfigurasi dan deploy Load Balancer Aplikasi eksternal regional di region tempat Anda ingin traffic dialihkan jika terjadi kegagalan.

Perhatikan pertimbangan berikut untuk arsitektur failover atau bypass saat Anda mengonfigurasi load balancer regional:

Anda harus mengonfigurasi fitur Load Balancer Aplikasi eksternal regional cadangan agar semirip mungkin dengan load balancer utama sehingga traffic diproses dengan cara yang sama di kedua deployment.
- Global external Application Load Balancer. Load Balancer Aplikasi eksternal regional mendukung sebagian besar fitur yang sama dengan Load Balancer Aplikasi eksternal global, dengan beberapa pengecualian. Load balancer regional juga mendukung kemampuan pengelolaan traffic lanjutan yang sama dengan load balancer global, sehingga mempermudah pencapaian kesetaraan antara load balancer utama dan cadangan.
- Load Balancer Aplikasi Klasik. Dengan Load Balancer Aplikasi klasik, paritas fitur antara load balancer utama dan cadangan lebih sulit dicapai karena Load Balancer Aplikasi eksternal regional adalah load balancer berbasis Envoy yang memproses traffic secara berbeda. Pastikan Anda menguji failover dan failback secara menyeluruh sebelum men-deploy ke produksi.
Untuk melihat kemampuan spesifik Load Balancer Aplikasi regional, global, dan klasik, lihat halaman Perbandingan fitur load balancer.

Sebaiknya gunakan framework otomatisasi seperti Terraform untuk membantu mencapai dan mempertahankan konsistensi dalam konfigurasi load balancer di seluruh deployment utama dan cadangan.
Load Balancer Aplikasi eksternal regional mendukung Paket Layanan Jaringan Premium dan Standar. Jika latensi bukan masalah utama Anda selama failover, sebaiknya siapkan Load Balancer Aplikasi eksternal regional cadangan menggunakan Tingkat Standar. Penggunaan infrastruktur Paket Standar menawarkan isolasi tambahan dari infrastruktur Paket Premium yang digunakan oleh Load Balancer Aplikasi eksternal global.
Pastikan subnet khusus proxy berukuran cukup besar untuk mengakomodasi peningkatan traffic selama peristiwa failover tanpa mengganggu load balancer regional lainnya di region dan jaringan yang sama. Untuk mengetahui detailnya, lihat Mereservasi kapasitas subnet khusus proxy tambahan.

Untuk mempelajari cara mengonfigurasi Load Balancer Aplikasi eksternal regional, lihat Menyiapkan Load Balancer Aplikasi eksternal regional dengan backend grup instance VM.

Mereservasi kapasitas subnet khusus proxy tambahan

Semua load balancer berbasis Envoy regional dalam jaringan VPC dan region yang sama menggunakan kumpulan proxy Envoy yang sama. Dalam peristiwa failover, Load Balancer Aplikasi eksternal regional cadangan akan mengalami peningkatan penggunaan proxy untuk menangani traffic failover dari load balancer utama. Memesan kapasitas proxy yang memadai akan memastikan bahwa peristiwa failover tidak mengganggu load balancer berbasis Envoy regional lainnya di region dan jaringan yang sama.

Untuk membantu memastikan kapasitas selalu tersedia untuk load balancer cadangan, tinjau ukuran subnet khusus proxy Anda. Sebaiknya Anda menghitung perkiraan jumlah proxy yang diperlukan untuk menangani traffic di wilayah tertentu dan meningkatkan kapasitas jika diperlukan. Untuk mengetahui informasi selengkapnya tentang batas kapasitas proxy dan perhitungan ukuran, lihat bagian Biaya instance proxy di "Harga Cloud Load Balancing".

Jika Anda menggunakan kebijakan DNS untuk membagi traffic di beberapa load balancer cadangan di berbagai region, Anda harus mempertimbangkannya saat memperkirakan persyaratan proxy per region dan jaringan. Subnet khusus proxy yang lebih besar memungkinkanGoogle Cloud menetapkan lebih banyak proxy Envoy ke load balancer Anda jika diperlukan.

Anda tidak dapat memperluas subnet khusus proxy dengan cara yang sama seperti yang Anda lakukan untuk rentang alamat IP utama (dengan perintah expand-ip-range). Sebagai gantinya, Anda harus membuat subnet khusus proxy cadangan yang memenuhi kebutuhan Anda, lalu mempromosikannya ke peran aktif.

Untuk mempelajari cara mengubah ukuran subnet khusus proxy, lihat Mengubah ukuran atau rentang alamat IP subnet khusus proxy.

Berbagi backend antara load balancer utama dan cadangan

Untuk mencapai redundansi infrastruktur yang lengkap, Anda harus memperkenalkan redundansi di tingkat load balancer dan di tingkat backend. Artinya, Anda harus mengonfigurasi Load Balancer Aplikasi eksternal regional cadangan dengan backend (grup instance atau grup endpoint jaringan) yang tidak tumpang-tindih dengan load balancer utama.

Jika Anda memilih untuk menggunakan backend yang sama untuk load balancer utama dan cadangan, Anda harus membuat setiap Load Balancer Aplikasi eksternal regional cadangan di region tempat backend tersebut berada. Selain itu, jika penskalaan otomatis diaktifkan untuk grup instance, Anda harus memenuhi persyaratan berikut untuk membantu memastikan bahwa failover yang tepat terjadi:

Konfigurasi autoscaler dengan penskalaan berbasis CPU saja. Penskalaan otomatis berdasarkan penggunaan load balancer tidak didukung.
Layanan backend global dan regional hanya boleh menggunakan mode load balancing UTILIZATION. Jangan gunakan mode load balancing RATE karena instance Anda dapat menerima traffic 2x dari load balancer global dan regional selama proses failover.
Konfigurasi kontrol penurunan skala untuk mencegah autoscaler menurunkan skala grup secara prematur selama periode nonaktif saat traffic beralih dari load balancer global ke load balancer regional. Waktu nonaktif ini bisa setinggi jumlah TTL DNS (time to live) ditambah interval pemeriksaan kondisi yang dikonfigurasi.

Kegagalan menyiapkan penskalaan otomatis dengan benar dapat menyebabkan gangguan sekunder selama failover karena hilangnya traffic dari load balancer global menyebabkan grup instance menyusut dengan cepat sebelum load balancer regional mengambil alih.

Mengonfigurasi failover aktif-pasif

Untuk mengonfigurasi failover aktif-pasif, ikuti langkah-langkah berikut:

Tinjau pertimbangan arsitektur: Sebelum membuat resource, tinjau pertimbangan untuk load balancer regional untuk memverifikasi kompatibilitas fitur, kapasitas proxy, dan persyaratan penskalaan otomatis backend bersama.
Konfigurasi load balancer utama: Siapkan Load Balancer Aplikasi eksternal global Anda dengan layanan backend yang didistribusikan di satu atau beberapa region. Untuk mengetahui informasi selengkapnya tentang cara mengonfigurasi Load Balancer Aplikasi eksternal global, lihat Menyiapkan Load Balancer Aplikasi eksternal global.
Tinjau konfigurasi load balancer utama: Pastikan fitur (seperti fitur keamanan, fitur pengelolaan dan perutean traffic, serta Cloud CDN) yang digunakan oleh load balancer utama tersedia dengan Load Balancer Aplikasi eksternal regional cadangan. Jika fitur serupa tidak tersedia, load balancer ini mungkin bukan kandidat yang baik untuk failover.
Konfigurasi Load Balancer Aplikasi eksternal regional cadangan: Siapkan Load Balancer Aplikasi eksternal regional independen di region tempat Anda ingin traffic di-failover. Untuk mengetahui informasi tentang cara mengonfigurasi Load Balancer Aplikasi eksternal regional, lihat Menyiapkan Load Balancer Aplikasi eksternal regional dengan backend grup instance VM.
Mengonfigurasi pemilihan rute DNS dan health check: Buat health check untuk load balancer utama dan konfigurasi kebijakan pemilihan rute failover Cloud DNS untuk mendeteksi gangguan dan merutekan traffic klien ke load balancer regional cadangan.

Mengonfigurasi pengalihan aktif-aktif

Untuk mengonfigurasi arsitektur aktif-aktif, ikuti langkah-langkah berikut:

Tinjau pertimbangan arsitektur: Sebelum membuat resource, tinjau pertimbangan untuk load balancer regional guna memverifikasi kompatibilitas fitur, dan pastikan kapasitas subnet khusus proxy dapat menangani traffic kondisi stabil dan failover.
Mengonfigurasi Load Balancer Aplikasi eksternal regional: Sebelum mengonfigurasi load balancer regional, tinjau Kompatibilitas dan batasan fitur. Deploy Load Balancer Aplikasi eksternal regional di dua atau beberapa region dengan layanan backend, alamat IP eksternal, sertifikat SSL, dan kebijakan keamanan Cloud Armor regional. Untuk mengetahui petunjuk penyiapan, lihat Menyiapkan Load Balancer Aplikasi eksternal regional dengan backend grup instance VM.
Mengonfigurasi DNS untuk load balancer regional: Buat data DNS (misalnya, regional-api.example.com) yang mengarah ke alamat IP eksternal Load Balancer Aplikasi eksternal regional Anda menggunakan kebijakan perutean geolokasi atau latensi. Aktifkan health check DNS pada data ini untuk mendeteksi kegagalan di region tertentu dan secara otomatis mengalihkan traffic dari region tersebut ke region lain yang responsif.
Konfigurasi Load Balancer Aplikasi eksternal Global: Cadangkan alamat IP eksternal global dan buat grup endpoint jaringan (NEG) internet global berjenis INTERNET_FQDN_PORT. Tambahkan endpoint ke NEG internet yang mengarah ke FQDN data DNS regional, misalnya, regional-api.example.com. Konfigurasi layanan backend untuk Load Balancer Aplikasi eksternal global, lampirkan NEG internet, dan aktifkan Cloud CDN atau Cloud Armor jika diperlukan. Konfigurasi peta URL, proxy HTTP(S) target, dan aturan penerusan global.
Mengonfigurasi DNS untuk failover dan health check: Buat data DNS layanan utama (misalnya, api.example.com) menggunakan kebijakan pemilihan rute FAILOVER. Pastikan set data memiliki endpoint utama yang mengarah ke alamat IP Load Balancer Aplikasi eksternal global dan endpoint cadangan yang mengarah ke alamat IP alamat IP eksternal Load Balancer Aplikasi eksternal regional. Konfigurasi health check DNS untuk memantau Load Balancer Aplikasi eksternal global.

Praktik terbaik

Perhatikan praktik terbaik berikut saat Anda mengonfigurasi data Cloud DNS dan health check:

Menghitung durasi gangguan: Waktu yang diperlukan agar traffic melakukan failover dari load balancer utama ke cadangan bergantung pada TTL DNS, interval health check, dan parameter nilai minimum tidak responsif health check:

Dengan Cloud DNS Google, batas atas untuk periode ini dapat dihitung menggunakan formula berikut:
```
Duration of outage = DNS TTL + Health Check Interval * Unhealthy Threshold
```
Tetapkan TTL DNS ke 30–60 detik. Nilai TTL yang lebih tinggi menyebabkan waktu failover yang lebih lama karena klien di internet terus mengakses Load Balancer Aplikasi eksternal utama meskipun DNS telah melakukan failover ke Load Balancer Aplikasi eksternal regional cadangan.
Konfigurasi nilai minimum health check: Tetapkan parameter nilai minimum responsif dan tidak responsif untuk menghindari failover yang disebabkan oleh error jaringan sementara. Ambang batas yang lebih tinggi akan meningkatkan waktu yang diperlukan agar traffic melakukan failover ke load balancer cadangan.
Gunakan traffic tetesan untuk validasi: Konfigurasi flag --backup-data-trickle-ratio untuk terus mengirimkan sebagian kecil traffic ke load balancer cadangan meskipun load balancer utama responsif. Hal ini memastikan bahwa infrastruktur cadangan aktif dan siap menangani traffic. Anda dapat mengonfigurasi persentase traffic yang dikirim ke penyeimbang beban cadangan sebagai pecahan dari 0 hingga 1. Nilai umumnya adalah 0,1, meskipun Cloud DNS memungkinkan Anda mengirim 100 persen traffic ke alamat VIP cadangan, untuk memicu failover secara manual.
Uji failover dan failback secara berkala: Sertakan pengujian failover dalam rencana pemulihan dari bencana Anda. Verifikasi perubahan traffic bertahap dan tiba-tiba dari load balancer utama ke load balancer cadangan, dan verifikasi bahwa traffic kembali lancar ke load balancer utama setelah failback.