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 diskusi 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 pemadaman layanan dan merutekan traffic dari load balancer utama ke load balancer cadangan, proses ini disebut failover. Saat Cloud DNS membalikkan hal ini dan mengalihkan traffic ke load balancer utama, proses ini disebut failback.
Cara kerja failover
Failover 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 di-failover. Hanya Load Balancer Aplikasi eksternal regional yang dapat digunakan sebagai load balancer cadangan. Load Balancer Aplikasi eksternal regional tidak hanya mandiri dalam setiap region Google Cloud, tetapi juga terisolasi 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 yang signifikan dalam cara traffic ditangani.
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 standar dengan berbagai komponen yang terlibat dalam konfigurasi failover.
Mendeteksi kegagalan di load balancer utama
Google Cloud menggunakan pemeriksaan kondisi untuk mendeteksi apakah Load Balancer Aplikasi eksternal utama Anda dalam kondisi 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 beberapa 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.
- Proba health check sebenarnya berasal dari Titik Kehadiran (PoP) di internet dalam jarak yang tidak terlalu jauh dari region sumber Google Cloud yang dikonfigurasi.
Merutekan traffic ke load balancer cadangan
Jika load balancer utama mulai gagal dalam health check, Google Cloud akan menggunakan kebijakan pemilihan rute failover Cloud DNS untuk menentukan cara merutekan traffic ke load balancer cadangan.
Durasi pemadaman layanan, atau waktu yang diperlukan untuk failover traffic 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.
Failback ke load balancer utama
Setelah health check mulai diteruskan lagi, failback ke load balancer utama akan otomatis dilakukan. Tidak ada periode nonaktif yang diharapkan selama failback karena load balancer cadangan dan utama menayangkan traffic.
Menguji failover secara berkala
Sebaiknya uji alur kerja failover secara berkala sebagai bagian dari rencana kelangsungan bisnis Anda. Pastikan untuk menguji pergeseran traffic yang bertahap dan seketika dari load balancer utama ke 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 periksa apakah fitur (seperti fitur keamanan, fitur pengelolaan dan pemilihan rute traffic, 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 mencerminkan load balancer utama sebanyak mungkin.
- Buat health check dan kebijakan perutean DNS untuk mendeteksi pemadaman layanan 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 GKE Ingress hanya mendukung Load Balancer Aplikasi klasik.
Untuk 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, operasi apa pun yang mengandalkan Cloud CDN juga akan terpengaruh. Untuk redundansi yang lebih baik, sebaiknya konfigurasikan solusi CDN pihak ketiga yang dapat berfungsi sebagai pengganti Cloud CDN.
Google Cloud Armor. Jika Anda menggunakan Google Cloud Armor untuk load balancer utama, pastikan Anda juga mengonfigurasi fitur Google Cloud Armor yang sama saat mengonfigurasi Load Balancer Aplikasi eksternal regional cadangan. Google Cloud Armor memiliki fitur yang berbeda-beda yang tersedia dalam cakupan regional versus global. Untuk informasi selengkapnya, lihat bagian berikut dalam dokumentasi Google 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 konfigurasikan 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 seserupa 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, yang memudahkan untuk mencapai 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 primer 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 untuk mencadangkan load balancer regional di tiga region saja, Anda berisiko membebani layanan backend di tiga region ini, sementara layanan backend di dua region lainnya tidak ada aktivitas.
Selain itu, sebaiknya konfigurasikan 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 Paket Layanan Jaringan Premium dan Standar. Jika latensi bukan masalah utama Anda selama failover, sebaiknya siapkan Load Balancer Aplikasi eksternal regional cadangan menggunakan Paket 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 harus 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, siapkan proxy Envoy tambahan untuk Load Balancer Aplikasi eksternal regional guna membantu memastikan bahwa, jika terjadi peristiwa failover, traffic tambahan tidak akan 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 regional berbasis Envoy di region dan jaringan VPC menggunakan kumpulan proxy Envoy yang sama. Dalam peristiwa failover, Load Balancer Aplikasi eksternal regional cadangan akan melihat 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 hitung perkiraan jumlah proxy yang diperlukan untuk menangani traffic di region tertentu dan tingkatkan 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.
Umumnya, 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 menggunakan kebijakan DNS untuk membagi traffic di beberapa load balancer cadangan di region yang berbeda, Anda harus memperhitungkannya saat memperkirakan persyaratan proxy per region dan jaringan. Subnet khusus proxy yang lebih besar memungkinkan Google 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.
Membagikan 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 berbagi grup instance backend antara load balancer primer dan sekunder, dan penskalaan otomatis diaktifkan untuk grup instance, Anda harus memenuhi persyaratan berikut untuk membantu memastikan bahwa failover yang tepat terjadi:
- Autoscaler harus disiapkan hanya dengan penskalaan berbasis CPU. Metode penskalaan berbasis penggunaan 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 lipat 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 tidak aktif ini dapat mencapai jumlah TTL 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.
Mengonfigurasi Cloud DNS dan health check
Bagian ini menjelaskan cara menggunakan Cloud DNS dan pemeriksaan status Google Cloud untuk mengonfigurasi lingkungan Cloud Load Balancing Anda guna mendeteksi pemadaman layanan dan merutekan traffic ke load balancer cadangan.
Gunakan langkah-langkah berikut untuk mengonfigurasi kebijakan health check dan perutean yang diperlukan:
Buat health check untuk alamat IP aturan penerusan load balancer utama.
gcloud beta 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 region Google Cloud tempat pemeriksaan kesehatan dilakukan. Anda harus menentukan tiga region sumber secara tepat.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 dihilangkan, Google Cloud akan menggunakan nilai minimum default 2.REQUEST_PATH: jalur URL tempat Google Cloud mengirim permintaan pemeriksaan health check. Jika dihilangkan, Google Cloud akan mengirim permintaan pemeriksaan ke jalur root, /. Jika endpoint yang sedang diperiksa kesehatannya bersifat pribadi, yang tidak biasa untuk alamat IP aturan penerusan eksternal, Anda dapat menetapkan jalur ini ke/afhealthz.
Buat kumpulan data Cloud DNS di Cloud DNS dan terapkan kebijakan pemilihan rute ke kumpulan data tersebut. Kebijakan perutean harus dikonfigurasi untuk me-resolve 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 beta 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: DNS atau nama domain dari kumpulan data yang akan ditambahkan—misalnya,test.example.comTIME_TO_LIVE: time to live (TTL) untuk kumpulan data dalam jumlah detik. Untuk mengetahui nilai yang direkomendasikan, lihat Praktik terbaik.RECORD_TYPE: jenis data—misalnya,AMANAGED_ZONE_NAME: nama zona terkelola yang kumpulan 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. Defaultnya ditetapkan ke 0.
Praktik terbaik
Berikut adalah beberapa praktik terbaik yang perlu diingat saat Anda mengonfigurasi data dan pemeriksaan kesehatan Cloud DNS:
Waktu yang diperlukan untuk pengalihan traffic dari load balancer utama ke load balancer cadangan (yaitu, durasi pemadaman) 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 periode nonaktif yang lebih lama karena klien di internet terus mengakses Load Balancer Aplikasi eksternal utama meskipun setelah DNS beralih ke Load Balancer Aplikasi eksternal regional cadangan.
Konfigurasikan parameter nilai minimum responsif dan tidak responsif dalam health check sehingga Anda menghindari failover yang tidak perlu yang disebabkan oleh error sementara. Batas yang lebih tinggi akan meningkatkan waktu yang diperlukan untuk pengalihan traffic ke load balancer cadangan.
Untuk membantu memastikan bahwa penyiapan failover berfungsi seperti yang diharapkan, Anda dapat menyiapkan kebijakan pemilihan rute DNS untuk selalu mengirim 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 DNS.Anda dapat mengonfigurasi persentase traffic yang dikirim ke cadangan sebagai fraksi 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.