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 pemadaman layanan infrastruktur atau error konfigurasi, Anda dapat mendesain strategi failover untuk Load Balancer Aplikasi eksternal global. Strategi ini menggunakan Load Balancer Aplikasi eksternal regional dan mengarahkan traffic ke load balancer tersebut dari Load Balancer Aplikasi eksternal global untuk mempertahankan ketersediaan tinggi selama pemadaman layanan infrastruktur global atau error 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 pemilihan rute traffic otomatis:

Failover terjadi saat Cloud DNS mendeteksi pemadaman layanan dan mengarahkan traffic dari load balancer utama ke load balancer cadangan.
Failback terjadi saat Cloud DNS membalikkan pemilihan rute ini dan mengalihkan traffic ke load balancer utama setelah health check lulus.

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 masing-masing regionGoogle Cloud dan juga terisolasi 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 beberapa 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 status stabil, Cloud DNS me-resolve ke alamat IP Load Balancer Aplikasi eksternal global. Jika load balancer global gagal, Cloud DNS akan mengarahkan traffic ke load balancer regional cadangan. Konfigurasi ini menggunakan kebijakan perutean failover Cloud DNS.
Aktif-aktif (bypass global-ke-regional): Load Balancer Aplikasi eksternal global bertindak sebagai frontend edge yang menyediakan fungsi Cloud CDN seperti edge caching yang meneruskan permintaan ke Load Balancer Aplikasi eksternal regional menggunakan grup endpoint jaringan (NEG) internet dengan nama domain yang sepenuhnya memenuhi syarat (FQDN). Dalam status stabil, traffic mengalir secara berurutan melalui kedua lapisan load balancing. Hal ini dapat dikonfigurasi menggunakan kebijakan perutean geolokasi Cloud DNS. Jika load balancer global mengalami pemadaman layanan, kebijakan perutean DNS akan mengabaikan lapisan global dan merutekan traffic klien langsung ke load balancer regional.

Sebagai praktik terbaik, jika arsitektur Anda tidak mengandalkan load balancing backend global yang berbasis kapasitas, pilih strategi aktif-aktif. Namun, jika aplikasi Anda secara eksplisit memerlukan load balancing backend global untuk mendistribusikan dan mengalihkan 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 kondisi stabil	Klien → Load Balancer Aplikasi eksternal global → Backend	Klien → Load Balancer Aplikasi eksternal global → Load Balancer Aplikasi eksternal regional → Backend
Alur traffic status kegagalan	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.
Manajemen 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 status stabil. Sebaiknya lakukan pengujian berkala atau pengaturan traffic DNS.	Traffic status stabil terus menguji Load Balancer Aplikasi eksternal regional. Sebaiknya lakukan pengujian berkala atau arahkan traffic langsung ke load balancer regional.
Keamanan deployment progresif	Perubahan konfigurasi Load Balancer Aplikasi eksternal global berlaku secara global. Perubahan Load Balancer Aplikasi eksternal regional diisolasi, tetapi traffic status 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 mengalihkan traffic antar-region berdasarkan kapasitas backend.
Biaya dan penagihan	Biaya pemrosesan data berlaku untuk satu lapisan load balancing. Dalam status 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 status stabil.
Kasus penggunaan yang direkomendasikan	Workload yang memerlukan load balancing backend global tingkat lanjut dan pengalihan traffic berbasis kapasitas di seluruh region.	Workload yang dirancang berdasarkan isolasi regional yang menggunakan lapisan global untuk performa edge dan caching.

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 utama atau Load Balancer Aplikasi klasik.

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.

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

Failover aktif-pasif mengikuti alur kerja ini:

Status stabil: Cloud DNS mengarahkan semua traffic klien ke Load Balancer Aplikasi eksternal global.
Deteksi kegagalan: Google Cloud menggunakan health check yang dikonfigurasi dengan tiga region sumber untuk mendeteksi apakah load balancer utama responsif. Jika health check yang berasal dari dua atau beberapa region sumber gagal, Cloud DNS akan memicu failover.
Failover: Kebijakan perutean 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 region Google Cloud tertentu, klien yang berada jauh dari region tujuan mungkin mengalami peningkatan latensi dan waktu round-trip (RTT) saat failover aktif.
Failback: Setelah health check berhasil lagi, Cloud DNS akan otomatis memulihkan traffic ke load balancer utama tanpa periode nonaktif karena kedua load balancer menyalurkan traffic.

Strategi aktif-aktif (bypass 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:

Status stabil: Traffic mengalir dari klien ke Load Balancer Aplikasi eksternal global. Load balancer global menggunakan grup endpoint jaringan (NEG) FQDN internet berjenis 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 status stabil, jika satu Load Balancer Aplikasi eksternal regional atau region-nya gagal, Load Balancer Aplikasi eksternal global akan mendeteksi kegagalan tersebut menggunakan kebijakan health check Cloud DNS di NEG internet. Load balancer global secara otomatis mengalihkan traffic dari region yang tidak responsif ke load balancer regional yang responsif.
Pengabaian: Jika Load Balancer Aplikasi eksternal global mengalami pemadaman layanan, kebijakan failover Cloud DNS akan mendeteksi kegagalan dan merutekan traffic langsung ke Load Balancer Aplikasi eksternal regional, sehingga mengabaikan lapisan global sepenuhnya. Dampak latensi selama bypass: Load Balancer Aplikasi eksternal global memberikan manfaat performa edge seperti menghentikan koneksi lebih dekat ke pengguna dan edge caching. Saat traffic mengabaikan load balancer global, koneksi klien akan dibuat langsung dengan VIP regional, yang dapat meningkatkan latensi koneksi dan RTT untuk klien yang 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 pemilihan rute 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 aktif-aktif, aturan perutean dan keamanan inti harus dikonfigurasi langsung di tingkat regional, sedangkan fitur edge global, seperti Cloud CDN, akan diabaikan selama pemadaman layanan 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 Gateway GKE lebih kompatibel dengan mekanisme failover ini daripada load balancer yang di-deploy menggunakan pengontrol Ingress GKE. Pengontrol GKE Ingress 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 fitur yang berbeda-beda 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.
- Load Balancer Aplikasi eksternal global. 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 memudahkan pencapaian kesetaraan antara load balancer utama dan cadangan.
- Load Balancer Aplikasi Klasik. Dengan Load Balancer Aplikasi klasik, kesetaraan 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 dari 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 Network Service Tiers Premium dan Standar. Jika latensi bukan masalah utama Anda selama failover, sebaiknya siapkan Load Balancer Aplikasi eksternal regional cadangan menggunakan Paket 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 untuk mengakomodasi peningkatan traffic selama peristiwa failover tanpa mengganggu load balancer regional lainnya di region dan jaringan yang sama. Untuk mengetahui detailnya, lihat Mencadangkan 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 regional berbasis Envoy di suatu region dan jaringan VPC menggunakan kumpulan proxy Envoy yang sama. Dalam peristiwa failover, Load Balancer Aplikasi eksternal regional cadangan mengalami peningkatan penggunaan proxy untuk menangani traffic failover dari load balancer utama. Mencadangkan 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 bahwa 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 region tertentu dan meningkatkan kapasitas jika diperlukan. Untuk mengetahui informasi selengkapnya tentang batas kapasitas proxy dan penghitungan 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 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 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:

Konfigurasikan autoscaler hanya dengan penskalaan berbasis CPU. Penskalaan otomatis berdasarkan pemakaian load balancer tidak didukung.
Layanan backend global dan regional hanya boleh menggunakan mode penyeimbangan UTILIZATION. Jangan gunakan mode balancing RATE karena instance Anda dapat menerima traffic 2x lipat dari load balancer global dan regional selama proses failover.
Konfigurasikan kontrol penurunan skala untuk mencegah autoscaler memperkecil skala grup secara prematur selama waktu non-operasional saat traffic beralih dari load balancer global ke load balancer regional. Periode nonaktif ini dapat mencapai jumlah TTL (time to live) DNS ditambah interval health check yang dikonfigurasi.

Kegagalan dalam menyiapkan penskalaan otomatis dengan benar dapat menyebabkan pemadaman layanan 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.
Konfigurasikan Load Balancer Aplikasi eksternal regional cadangan: Siapkan Load Balancer Aplikasi eksternal regional independen di region tempat Anda ingin mengalihkan traffic. Untuk mengetahui informasi tentang cara mengonfigurasi Load Balancer Aplikasi eksternal regional, lihat Menyiapkan Load Balancer Aplikasi eksternal regional dengan backend grup instance VM.
Mengonfigurasi perutean DNS dan health check: Buat health check untuk load balancer utama dan konfigurasikan kebijakan perutean failover Cloud DNS untuk mendeteksi pemadaman layanan dan mengarahkan traffic klien ke load balancer regional cadangan.

Mengonfigurasi bypass aktif-aktif

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

Tinjau pertimbangan arsitektur: Sebelum membuat resource, tinjau pertimbangan untuk load balancer regional untuk memverifikasi kompatibilitas fitur, dan pastikan kapasitas subnet khusus proxy dapat menangani traffic steady-state 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 region atau lebih dengan layanan backend, alamat IP eksternal, sertifikat SSL, dan kebijakan keamanan Cloud Armor regional Anda. Untuk mengetahui petunjuk penyiapan, lihat Menyiapkan Load Balancer Aplikasi eksternal regional dengan backend grup instance VM.
Konfigurasi 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.
Konfigurasikan Load Balancer Aplikasi eksternal Global: Cadangkan alamat IP eksternal global dan buat grup endpoint jaringan (NEG) internet global dengan jenis 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. Konfigurasikan peta URL, proxy HTTP(S) target, dan aturan penerusan global.
Konfigurasi DNS untuk failover dan health check: Buat data DNS layanan utama (misalnya, api.example.com) menggunakan kebijakan perutean 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 eksternal Load Balancer Aplikasi eksternal regional. Konfigurasikan 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 pemadaman layanan: Waktu yang diperlukan untuk mengalihkan traffic dari load balancer utama ke load balancer 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 bahkan setelah DNS gagal beralih ke Load Balancer Aplikasi eksternal regional cadangan.
Konfigurasikan nilai minimum health check: Tetapkan parameter nilai minimum responsif dan tidak responsif untuk menghindari failover yang disebabkan oleh error jaringan sementara. Nilai minimum yang lebih tinggi akan meningkatkan waktu yang diperlukan traffic untuk beralih ke load balancer cadangan.
Menggunakan trickle traffic untuk validasi: Konfigurasikan 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 load balancer 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 disaster recovery Anda. Verifikasi pergeseran traffic secara bertahap dan tiba-tiba dari load balancer utama ke cadangan, dan verifikasi bahwa traffic kembali dengan lancar ke load balancer utama setelah failback.