Halaman ini menjelaskan cara kerja failover untuk Load Balancer Aplikasi eksternal. Konfigurasi failover melibatkan dua load balancer: load balancer utama dan load balancer cadangan. Untuk tujuan pembahasan ini, load balancer utama adalah load balancer yang ingin Anda konfigurasi failover-nya. Load balancer cadangan adalah load balancer yang menerima koneksi saat load balancer utama mulai gagal dalam health check.
Failover dan failback adalah proses otomatis yang merutekan traffic ke dan dari load balancer. Saat Cloud DNS mendeteksi gangguan dan merutekan traffic dari load balancer utama ke load balancer cadangan, proses ini disebut failover. Saat Cloud DNS membalikkan proses ini dan mengalihkan traffic ke load balancer utama, proses ini disebut failback.
Cara kerja failover
Pengalihan dari global ke regional untuk Load Balancer Aplikasi eksternal ditangani dengan membuat dua atau lebih Load Balancer Aplikasi eksternal regional di region tempat Anda ingin traffic dialihkan. Hanya Load Balancer Aplikasi eksternal regional yang dapat digunakan sebagai load balancer cadangan. Load Balancer Aplikasi eksternal regional tidak hanya mandiri dalam setiap Google Cloud region, tetapi juga diisolasi dari infrastruktur Load Balancer Aplikasi eksternal global atau Load Balancer Aplikasi klasik yang berjalan di region yang sama.
Load Balancer Aplikasi eksternal regional berfungsi paling baik sebagai load balancer failover untuk Load Balancer Aplikasi eksternal global karena keduanya didasarkan pada proxy Envoy dan memproses traffic dengan cara yang sangat mirip. Hal ini berbeda dengan Load Balancer Aplikasi klasik yang memiliki perbedaan penting dalam cara penanganan traffic.
Singkatnya, skenario failover berikut didukung:
- Dari Load Balancer Aplikasi eksternal global ke Load Balancer Aplikasi eksternal regional
- Dari Load Balancer Aplikasi eksternal regional ke Load Balancer Aplikasi eksternal regional
- Dari Load Balancer Aplikasi klasik ke Load Balancer Aplikasi eksternal regional
Alur kerja failover dan failback
Penyiapan berikut menunjukkan failover dari Load Balancer Aplikasi eksternal global ke dua Load Balancer Aplikasi eksternal regional, dengan satu di setiap region tempat load balancer global telah men-deploy backend.
Bagian berikut menjelaskan alur kerja umum dengan berbagai komponen yang terlibat dalam konfigurasi failover.
Mendeteksi kegagalan di load balancer utama
Google Cloud menggunakan health check untuk mendeteksi apakah Load Balancer Aplikasi eksternal utama Anda berfungsi dengan baik. Anda mengonfigurasi health check ini untuk mengirim probe dari tiga region sumber. Ketiga region sumber ini harus mewakili region tempat klien Anda akan mengakses load balancer. Misalnya, jika Anda memiliki Load Balancer Aplikasi eksternal global dan sebagian besar traffic klien berasal dari Amerika Utara dan Eropa, Anda dapat mengonfigurasi probe yang berasal dari dua region di Amerika Utara dan satu region di Eropa.
Jika health check yang berasal dari dua atau lebih region ini gagal, hal ini akan memicu failover ke Load Balancer Aplikasi eksternal regional cadangan.
Catatan tambahan:
- Anda harus menentukan tepat tiga region sumber saat membuat health check. Hanya health check global yang dapat menentukan wilayah sumber.
- Health check HTTP, HTTPS, dan TCP didukung.
- Pemeriksaan health check sebenarnya berasal dari Point of Presence (PoP) di internet dalam jarak kecil dari region sumber Google Cloudyang dikonfigurasi.
Merutekan traffic ke load balancer cadangan
Jika load balancer utama mulai gagal dalam health check, Google Cloud gunakan kebijakan perutean failover Cloud DNS untuk menentukan cara merutekan traffic ke load balancer cadangan.
Durasi gangguan, atau waktu yang diperlukan agar traffic melakukan failover dari load balancer utama ke cadangan, ditentukan oleh nilai TTL DNS, interval health check, dan batas tidak responsif health check. Untuk setelan yang direkomendasikan, lihat Praktik terbaik.
Melakukan failback ke load balancer utama
Setelah health check mulai diteruskan lagi, failback ke load balancer utama akan otomatis. Tidak ada periode nonaktif yang diperkirakan selama failback karena load balancer cadangan dan utama melayani traffic.
Uji failover secara berkala
Sebaiknya uji alur kerja failover secara berkala sebagai bagian dari rencana kelangsungan bisnis Anda. Pastikan untuk menguji peralihan traffic bertahap dan instan dari load balancer utama ke load balancer cadangan. Setelah memverifikasi bahwa failover berfungsi, picu failback untuk memverifikasi bahwa traffic dialihkan kembali ke load balancer utama seperti yang diharapkan.
Mengonfigurasi failover
Untuk mengonfigurasi failover, lakukan langkah-langkah berikut:
- Tinjau konfigurasi load balancer utama yang ada dan pastikan fitur (seperti fitur keamanan, fitur pengelolaan traffic dan perutean, serta 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.
- Buat Load Balancer Aplikasi eksternal regional cadangan dengan konfigurasi yang semirip mungkin dengan load balancer utama.
- Buat health check dan kebijakan perutean DNS untuk mendeteksi gangguan dan merutekan traffic dari load balancer utama ke load balancer cadangan selama failover.
Meninjau konfigurasi load balancer utama
Sebelum memulai, pastikan Load Balancer Aplikasi eksternal regional cadangan mendukung semua fitur yang saat ini digunakan dengan load balancer utama Anda.
Untuk menghindari gangguan traffic, tinjau perbedaan berikut:
Deployment GKE. Pengguna GKE harus memperhatikan bahwa load balancer yang di-deploy menggunakan GKE Gateway lebih kompatibel dengan mekanisme failover ini daripada load balancer yang di-deploy menggunakan pengontrol Ingress GKE. Hal ini karena GKE Gateway mendukung konfigurasi Load Balancer Aplikasi eksternal global dan regional. Namun, pengontrol Ingress GKE hanya mendukung Load Balancer Aplikasi klasik.
Untuk mendapatkan hasil terbaik, gunakan GKE Gateway untuk men-deploy load balancer utama dan cadangan.
Cloud CDN. Load Balancer Aplikasi eksternal regional tidak mendukung Cloud CDN. Oleh karena itu, jika terjadi kegagalan, semua operasi yang mengandalkan Cloud CDN juga akan terpengaruh. Untuk redundansi yang lebih baik, sebaiknya konfigurasikan solusi CDN pihak ketiga yang dapat bertindak sebagai pengganti Cloud CDN.
Cloud Armor. Jika Anda menggunakan Cloud Armor untuk load balancer utama, pastikan Anda juga mengonfigurasi fitur Cloud Armor yang sama saat mengonfigurasi Load Balancer Aplikasi eksternal regional cadangan. Cloud Armor memiliki fitur yang berbeda yang tersedia dalam cakupan regional versus global. Untuk mengetahui informasi selengkapnya, lihat bagian berikut dalam dokumentasi Cloud Armor:
Sertifikat SSL. Jika Anda ingin menggunakan sertifikat SSL umum untuk load balancer utama dan cadangan, pastikan jenis sertifikat SSL yang digunakan dengan 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 detailnya, lihat bagian berikut:
Bucket backend. Load Balancer Aplikasi eksternal regional tidak mendukung bucket Cloud Storage sebagai backend. Anda tidak dapat menyiapkan failover untuk load balancer menggunakan bucket backend.
Mengonfigurasi load balancer cadangan
Load balancer cadangan adalah Load Balancer Aplikasi eksternal regional yang Anda konfigurasi di region tempat Anda ingin traffic dialihkan jika terjadi kegagalan.
Perhatikan pertimbangan berikut saat Anda mengonfigurasi load balancer cadangan:
Anda harus mengonfigurasi fitur Load Balancer Aplikasi eksternal regional cadangan agar semirip mungkin dengan load balancer utama sehingga traffic diproses secara serupa 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 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.
Sebaiknya siapkan Load Balancer Aplikasi eksternal regional cadangan di setiap region tempat Anda memiliki backend. Misalnya, jika Anda melakukan failover dari deployment global dengan grup instance di lima region ke load balancer regional cadangan di tiga region saja, Anda berisiko membebani layanan backend di tiga region ini secara berlebihan, sementara layanan backend di dua region yang tersisa tidak digunakan.
Selain itu, sebaiknya Anda mengonfigurasi Cloud DNS untuk menggunakan kebijakan round robin berbobot saat merutekan ulang traffic failover dari load balancer global utama ke load balancer regional cadangan ini. Tetapkan bobot ke setiap load balancer cadangan dengan mempertimbangkan ukuran maksimum grup instance backend di berbagai region.
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 Tingkat Standar. Menggunakan infrastruktur Paket Standar menawarkan isolasi tambahan dari infrastruktur Paket Premium yang digunakan oleh Load Balancer Aplikasi eksternal global.
Jika ingin menggunakan backend yang sama untuk load balancer utama dan cadangan, Anda membuat Load Balancer Aplikasi eksternal regional cadangan di region tempat backend berada. Jika telah mengaktifkan penskalaan otomatis untuk grup instance backend, Anda harus memenuhi persyaratan untuk berbagi backend di seluruh deployment.
Jika diperlukan, cadangkan proxy Envoy tambahan untuk Load Balancer Aplikasi eksternal regional guna membantu memastikan bahwa, jika terjadi peristiwa failover, traffic tambahan tidak mengganggu deployment load balancer lainnya di region 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. Untuk membantu memastikan kapasitas selalu tersedia untuk load balancer cadangan, sebaiknya tinjau ukuran subnet khusus proxy Anda. Sebaiknya Anda menghitung perkiraan jumlah proxy yang diperlukan untuk menangani traffic di region tertentu dan menambah kapasitas jika diperlukan. Hal ini juga membantu memastikan bahwa peristiwa failover tidak mengganggu load balancer berbasis Envoy regional lainnya di region dan jaringan yang sama.
Secara umum, proxy Load Balancer Aplikasi eksternal regional dapat mengelola hingga:
- 600 (HTTP) atau 150 (HTTPS) koneksi baru per detik
- 3.000 koneksi aktif
- 1.400 permintaan per detik
Jika Anda menggunakan kebijakan DNS untuk membagi traffic di beberapa load balancer cadangan di region yang berbeda, 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 menerapkan 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.
Namun, jika Anda ingin membagikan grup instance backend antara load balancer primer dan sekunder, dan penskalaan otomatis diaktifkan untuk grup instance, Anda harus memenuhi persyaratan berikut untuk membantu memastikan failover yang tepat terjadi:
- Autoscaler harus disiapkan dengan penskalaan berbasis CPU saja. Metode penskalaan berbasis pemanfaatan load balancer tidak didukung.
- Layanan backend global dan regional hanya boleh menggunakan mode load balancing
UTILIZATION. Penggunaan mode balancingRATEtidak direkomendasikan karena instance Anda dapat menerima traffic 2x dari load balancer global dan regional selama proses failover. - Kontrol penurunan skala harus dikonfigurasi 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 ditambah interval health check 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.
Mengonfigurasi Cloud DNS dan health check
Bagian ini menjelaskan cara menggunakan Cloud DNS dan Google Cloud pemeriksaan kondisi layanan untuk mengonfigurasi lingkungan Cloud Load Balancing Anda guna mendeteksi gangguan dan merutekan traffic ke load balancer cadangan.
Gunakan langkah-langkah berikut untuk mengonfigurasi health check dan kebijakan perutean yang diperlukan:
Buat health check untuk alamat IP aturan penerusan load balancer utama.
gcloud compute health-checks create http HEALTH_CHECK_NAME \ --global \ --source-regions=SOURCE_REGION_1,SOURCE_REGION_2,SOURCE_REGION_3 \ --use-serving-port \ --check-interval=HEALTH_CHECK_INTERVAL \ --healthy-threshold=HEALTHY_THRESHOLD \ --unhealthy-threshold=UNHEALTHY_THRESHOLD \ --request-path=REQUEST_PATHGanti kode berikut:
HEALTH_CHECK_NAME: nama health checkSOURCE_REGION: tiga Google Cloud region tempat pemeriksaan kondisi dilakukan. Anda harus menentukan tepat tiga wilayah sumber.HEALTH_CHECK_INTERVAL: jumlah waktu dalam detik dari awal satu pemeriksaan yang dikeluarkan oleh satu pemeriksa hingga awal pemeriksaan berikutnya yang dikeluarkan oleh pemeriksa yang sama. Nilai minimum yang didukung adalah 30 detik. Untuk nilai yang direkomendasikan, lihat Praktik terbaik.HEALTHY_THRESHOLDdanUNHEALTHY_THRESHOLD: jumlah pemeriksaan berurutan yang harus berhasil atau gagal agar instance VM dianggap responsif atau tidak responsif. Jika salah satunya tidak ada, Google Cloud menggunakan nilai minimum default 2.REQUEST_PATH: jalur URL yang menjadi tujuan Google Cloud mengirim permintaan pemeriksaan health check. Jika dihilangkan, Google Cloud akan mengirim permintaan pemeriksaan ke jalur root, /. Jika endpoint yang diperiksa kondisinya bersifat pribadi, yang tidak umum untuk alamat IP aturan penerusan eksternal, Anda dapat menetapkan jalur ini ke/afhealthz.
Buat set data Cloud DNS di Cloud DNS dan terapkan kebijakan perutean ke set data tersebut. Kebijakan perutean harus dikonfigurasi untuk menyelesaikan nama domain Anda ke alamat IP aturan penerusan load balancer utama, atau, jika terjadi kegagalan health check, ke salah satu alamat IP aturan penerusan load balancer cadangan.
gcloud dns record-sets create DNS_RECORD_SET_NAME \ --ttl=TIME_TO_LIVE \ --type=RECORD_TYPE \ --zone="MANAGED_ZONE_NAME" \ --routing-policy-type=FAILOVER \ --routing-policy-primary-data=PRIMARY_LOAD_BALANCER_FORWARDING_RULE \ --routing-policy-backup-data_type=GEO \ --routing-policy-backup-data="BACKUP_REGION_1=BACKUP_LOAD_BALANCER_1_IP_ADDRESS[;BACKUP_REGION_2=BACKUP_LOAD_BALANCER_2_IP_ADDRESS;BACKUP_REGION_3=BACKUP_LOAD_BALANCER_3_IP_ADDRESS]" \ --health-check=HEALTH_CHECK_NAME \ --backup-data-trickle-ratio=BACKUP_DATA_TRICKLE_RATIOGanti kode berikut:
DNS_RECORD_SET_NAME: nama DNS atau domain dari set data yang akan ditambahkan—misalnya,test.example.comTIME_TO_LIVE: time to live (TTL) untuk set rekaman yang ditetapkan dalam jumlah detik. Untuk nilai yang direkomendasikan, lihat Praktik terbaik.RECORD_TYPE: jenis catatan—misalnya,AMANAGED_ZONE_NAME: nama zona terkelola yang set rekaman datanya ingin Anda kelola—misalnya,my-zone-namePRIMARY_LOAD_BALANCER_FORWARDING_RULE: nama aturan penerusan load balancer utamaBACKUP_REGION: region tempat load balancer cadangan di-deployBACKUP_LOAD_BALANCER_IP_ADDRESS: alamat IP aturan penerusan load balancer cadangan yang sesuai dengan setiap regionBACKUP_DATA_TRICKLE_RATIO: rasio traffic yang akan dikirim ke load balancer cadangan, meskipun load balancer utama dalam kondisi baik. Rasio harus antara 0 dan 1, seperti 0,1. Nilai defaultnya adalah 0.
Praktik terbaik
Berikut beberapa praktik terbaik yang perlu diingat saat Anda mengonfigurasi pemeriksaan kondisi dan catatan Cloud DNS:
Waktu yang diperlukan agar traffic melakukan failover dari load balancer utama ke cadangan (yaitu, durasi gangguan) bergantung pada nilai TTL DNS, interval health check, dan parameter nilai minimum health check yang tidak responsif.
Dengan Cloud DNS Google, batas atas untuk periode ini dapat dihitung menggunakan formula berikut:
Duration of outage = DNS TTL + Health Check Interval * Unhealthy ThresholdUntuk konfigurasi failover, sebaiknya tetapkan TTL DNS ke 30-60 detik. TTL yang lebih tinggi menyebabkan waktu henti 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 parameter nilai minimum responsif dan tidak responsif di health check sehingga Anda dapat menghindari failover yang tidak perlu yang disebabkan oleh error sementara. Ambang batas yang lebih tinggi akan meningkatkan waktu yang diperlukan agar traffic melakukan failover ke load balancer cadangan.
Untuk membantu memastikan penyiapan failover Anda berfungsi seperti yang diharapkan, Anda dapat menyiapkan kebijakan perutean DNS agar selalu mengirimkan sebagian kecil traffic ke load balancer cadangan meskipun load balancer utama dalam kondisi baik. Hal ini dapat dilakukan dengan menggunakan parameter
--backup-data-trickle-ratiosaat Anda membuat kumpulan data catatan DNS.Anda dapat mengonfigurasi persentase traffic yang dikirim ke 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.