Failover untuk Load Balancer Aplikasi eksternal

Pratinjau

Produk atau fitur ini tunduk pada "Persyaratan Penawaran Pra-GA" di bagian Persyaratan Layanan Umum di Persyaratan Khusus Layanan. Produk dan fitur pra-GA tersedia "sebagaimana adanya" dan mungkin memiliki dukungan terbatas. Untuk mengetahui informasi selengkapnya, lihat deskripsi tahap peluncuran.

Halaman ini menjelaskan cara kerja failover untuk Load Balancer Aplikasi eksternal. Failover melibatkan dua load balancer: load balancer utama dan cadangan dengan load balancer Jaringan Passthrough Eksternal Regional. Untuk tujuan diskusi ini, load balancer utama adalah load balancer yang failovernya ingin dikonfigurasi. Beban pencadangan adalah load balancer yang menerima koneksi saat load balancing memulai health check yang gagal.

{i>Failover<i} dan {i>failback<i} adalah proses otomatis yang mengarahkan lalu lintas ke dan dari dengan 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 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 banyak Load Balancer Aplikasi eksternal regional di region tempat Anda ingin traffic failover. Hanya Load Balancer Aplikasi eksternal regional yang dapat digunakan sebagai load balancer cadangan. Load Balancer Aplikasi eksternal regional tidak hanya berdiri sendiri dalam individu di region Google Cloud, mereka juga terisolasi dari Load Balancer Aplikasi eksternal global atau infrastruktur 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 dan proses Envoy traffic dengan cara yang sangat mirip. Hal ini berbeda dengan Load Balancer Aplikasi klasik yang memiliki perbedaan mencolok dalam hal lalu lintas ditangani.

Singkatnya, skenario failover berikut ini telah 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

Penting: Konfigurasi failover yang dijelaskan di halaman ini adalah pasif aktif konfigurasi failover saat traffic gagal beralih ke load balancer cadangan saja saat load balancer utama tidak tersedia. Hal ini dicapai dengan menggunakan Kebijakan perutean failover Cloud DNS. Load Balancer Aplikasi eksternal regional juga mendukung konfigurasi active-active, tempat Anda dapat men-deploy beberapa load balancer di berbagai region yang semuanya yang menyalurkan traffic secara bersamaan. Hal ini dapat dikonfigurasi menggunakan Perutean geolokasi Cloud DNS kebijakan kami. Untuk mengetahui detailnya, lihat Ketersediaan tinggi untuk 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 Load Balancer di setiap region tempat load balancer global telah men-deploy backend.

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

Bagian berikut ini menjelaskan alur kerja umum dengan berbagai komponen yang terlibat dalam konfigurasi failover.

1. Mendeteksi kegagalan di load balancer utama

   Google Cloud menggunakan layanan kesehatan pemeriksaan untuk mendeteksi apakah Load Balancer Aplikasi eksternal utama responsif. Anda mengonfigurasi health check ini untuk mengirim penyelidikan dari tiga region sumber. Ketiga region sumber ini harus perwakilan wilayah tempat klien Anda akan mengakses muatan dengan load balancer Jaringan Passthrough Eksternal Regional. Misalnya, jika Anda memiliki Load Balancer Aplikasi eksternal global dan sebagian besar traffic klien berasal dari Amerika Utara dan Eropa, Anda dapat mengonfigurasi satelit 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, memicu failover ke Load Balancer Aplikasi eksternal regional cadangan.

   Catatan tambahan:

   • Anda harus menentukan dengan tepat tiga region sumber saat membuat kolom respons centang. Hanya health check global yang dapat menentukan sumber region.
   • Health check HTTP, HTTPS, dan TCP didukung.
   • Pemeriksaan health check sebenarnya berasal dari Titik Kehadiran (PoP) di internet dalam jarak tertentu dari jaringan Google Cloud region sumber.

2. Mengarahkan traffic ke load balancer cadangan

   Jika load balancer utama mulai gagal dalam health check, Google Cloud menggunakan kebijakan perutean failover Cloud DNS untuk menentukan cara merutekan traffic ke load balancer cadangan.

   Durasi pemadaman, atau waktu yang diperlukan traffic untuk melakukan failover dari load balancer utama ke cadangan, ditentukan oleh nilai TTL DNS, interval health check, dan health check-nya tidak sehat minimum. Sebagai setelan yang direkomendasikan, lihat Praktik terbaik.

3. Kegagalan mengembalikan ke load balancer utama

   Setelah health check mulai lulus lagi, failback ke pemuatan utama load balancer adalah otomatis. Tidak ada periode nonaktif yang diperkirakan selama failback karena baik load balancer cadangan maupun utama menyalurkan traffic.

4. Uji failover secara berkala

   Sebaiknya uji alur kerja failover secara berkala sebagai bagian dari rencana kelangsungan bisnis. Pastikan untuk menguji secara bertahap dan instan perubahan traffic dari load balancer utama ke cadangan. Setelah memverifikasi bahwa failover berfungsi, memicu failback untuk memverifikasi bahwa traffic dialihkan kembali ke load balancer utama seperti yang diharapkan.

Mengonfigurasi failover

Untuk mengonfigurasi failover, lakukan langkah-langkah berikut:

1. Meninjau konfigurasi load balancer utama yang ada dan periksa apakah fitur (seperti fitur keamanan, pengelolaan lalu lintas, dan fitur perutean, dan CDN) yang digunakan oleh load balancer utama yang tersedia dengan Load Balancer Aplikasi eksternal regional cadangan. Jika fitur serupa tidak tersedia, maka load balancer ini mungkin bukan kandidat yang baik untuk failover.
2. Buat Load Balancer Aplikasi eksternal regional cadangan dengan konfigurasi yang menduplikasi load balancer utama sebanyak mungkin.
3. Membuat health check dan pemilihan rute DNS untuk mendeteksi pemadaman layanan dan mengarahkan traffic dari 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 seharusnya Perlu diketahui bahwa load balancer yang di-deploy menggunakan Gateway GKE lebih kompatibel dengan mekanisme failover ini dibandingkan dengan load balancer yang di-deploy menggunakan pengontrol GKE Ingress. Hal ini karena GKE Gateway mendukung konfigurasi jaringan Load Balancer Aplikasi eksternal regional. Namun, GKE Ingress dan pengontrol hanya mendukung Load Balancer Aplikasi klasik.

  Untuk hasil terbaik, gunakan Gateway GKE untuk men-deploy load balancer utama dan cadangan.

• Cloud CDN lainnya. Load Balancer Aplikasi eksternal regional tidak mendukung yang dihosting di Google Cloud CDN. Oleh karena itu, jika terjadi gagal, operasi apa pun yang mengandalkan Cloud CDN juga akan terpengaruh. Untuk redundansi yang lebih baik, sebaiknya konfigurasi solusi CDN pihak ketiga yang dapat bertindak 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 saat mengonfigurasi cadangan Load Balancer Aplikasi eksternal regional. Google Cloud Armor menyediakan berbagai fitur dalam lingkup regional versus global. Untuk informasi selengkapnya, lihat referensi berikut dalam dokumentasi Google Cloud Armor:

  • Kebijakan keamanan Google Cloud Armor regional
  • Kebijakan keamanan global Google Cloud Armor

• Sertifikat SSL. Jika Anda ingin menggunakan sertifikat SSL umum untuk load balancer utama dan cadangan, pastikan jenis sertifikat yang digunakan dengan load balancer utama kompatibel dengan mencadangkan Load Balancer Aplikasi eksternal regional. Tinjau perbedaan antara beberapa SSL sertifikat yang tersedia dengan load balancer global, regional, dan klasik. Untuk mengetahui detailnya, lihat bagian berikut:

  • Sertifikat SSL Compute Engine
  • Sertifikat SSL Pengelola Sertifikat

• 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 menjadi semirip mungkin dengan load balancer utama, sehingga traffic diproses di kedua deployment tersebut.

  • 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 load balancing kemampuan pengelolaan traffic tingkat lanjut sebagai load balancer global, yang memudahkan untuk mencapai ekuivalensi antara beban utama dan cadangan penyeimbang.

  • Load Balancer Aplikasi Klasik. Dengan Load Balancer Aplikasi klasik, fitur paritas antara load balancer utama dan cadangan lebih sulit dicapai karena Load Balancer Aplikasi eksternal regional adalah load balancer berbasis Envoy yang memproses lalu lintas secara berbeda. Pastikan Anda menguji failover dan failback secara menyeluruh sebelum diterapkan ke produksi.

  Untuk melihat kemampuan spesifik regional, global, dan klasik Load Balancer Aplikasi, lihat Perbandingan fitur load balancer halaman.

  Sebaiknya gunakan framework otomatisasi seperti Terraform untuk membantu mencapai dan mempertahankan konsistensi konfigurasi load balancer di kedua 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 untuk mencadangkan load balancer regional hanya di tiga region, Anda berisiko kelebihan beban layanan backend di ketiga region sementara layanan backend di dua region lainnya tidak ada aktivitas.

  Selain itu, sebaiknya Anda mengonfigurasi Cloud DNS untuk menggunakan round robin berbobot kebijakan saat mengubah rute failover traffic dari load balancer global utama ke beban regional cadangan ini penyeimbang. Tetapkan bobot untuk setiap load balancer cadangan dengan mempertimbangkan ukuran maksimum grup backend instance di berbagai region.

• Load Balancer Aplikasi eksternal regional mendukung Premium dan Standar {i>Network Service Tiers<i}. 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 Anda ingin menggunakan backend yang sama untuk beban utama dan cadangan Anda akan membuat Load Balancer Aplikasi eksternal regional cadangan di region lokasi backend. Jika Anda telah mengaktifkan penskalaan otomatis untuk backend grup instance, Anda harus memenuhi persyaratan untuk membagikan akses backend di seluruh deployment.

• Jika diperlukan, cadangkan proxy Envoy tambahan untuk Load Balancer Aplikasi eksternal regional untuk membantu memastikan bahwa, jika terjadi peristiwa failover, traffic tambahan tidak dan mengganggu deployment load balancer lain di region 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 Load Balancer Aplikasi eksternal regional dengan grup instance VM backend.

Mencadangkan kapasitas subnet khusus proxy tambahan

Semua load balancer berbasis Envoy regional di region dan VPC jaringan memiliki kumpulan {i>proxy<i} Envoy yang sama. Jika terjadi failover, cadangan Load Balancer Aplikasi eksternal regional mengalami peningkatan penggunaan proxy untuk menangani failover traffic dari load balancer utama. Untuk membantu memastikan bahwa kapasitas selalu yang tersedia untuk load balancer cadangan, sebaiknya tinjau dari subnet khusus proxy. Rab sebaiknya Anda menghitung perkiraan jumlah proxy yang diperlukan untuk menangani lalu lintas di wilayah tertentu dan meningkatkan kapasitas jika diperlukan. Hal ini juga membantu memastikan bahwa peristiwa failover tidak mengganggu pemuatan berbasis Envoy regional lainnya beberapa load balancer 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 Anda menggunakan kebijakan DNS untuk membagi traffic ke beberapa beban pencadangan di berbagai region, Anda harus memperhitungkannya saat memperkirakan persyaratan proxy per region dan jaringan. Subnet khusus {i>proxy<i} yang lebih besar memungkinkan Google Cloud menetapkan proxy Envoy dalam jumlah yang lebih besar ke load balancer Anda jika diperlukan.

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

Untuk mempelajari cara mengubah ukuran subnet khusus {i>proxy<i} Anda, lihat Mengubah ukuran atau rentang alamat IP khusus proxy Subnet.

Membagikan backend antara load balancer utama dan cadangan

Untuk mencapai redundansi infrastruktur yang lengkap, Anda harus menerapkan redundansi di baik di tingkat load balancer maupun di 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 instance dan load balancer sekunder, dan penskalaan otomatis akan diaktifkan untuk instance grup, Anda harus memenuhi persyaratan berikut untuk membantu memastikan bahwa terjadi failover:

• Penskala otomatis harus disiapkan dengan beberapa sinyal. Sebaiknya gunakan kombinasi sinyal penskalaan CPU dan sinyal penggunaan load balancer untuk grup instance.
• Baik layanan backend global maupun regional hanya boleh menggunakan UTILIZATION mode balancing. Menggunakan mode penyeimbangan RATE tidak direkomendasikan karena instance Anda dapat menerima traffic 2x lipat dari beban global dan regional selama proses failover.
• Kontrol peningkatan skala harus dikonfigurasi untuk mencegah autoscaler menurunkan skala grup secara dini selama periode nonaktif saat traffic beralih dari load balancer global ke load balancer regional. Ini periode nonaktif dapat setinggi jumlah TTL DNS ditambah interval health check dikonfigurasi.

Kegagalan dalam menyiapkan penskalaan otomatis dengan benar dapat mengakibatkan 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 Health check Google Cloud untuk mengonfigurasi lingkungan Cloud Load Balancing Anda guna mendeteksi pemadaman layanan dan mengarahkan rute traffic ke load balancer cadangan.

Gunakan langkah-langkah berikut untuk mengonfigurasi health check dan pemilihan rute yang diperlukan kebijakan:

1. Membuat health check untuk IP aturan penerusan load balancer utama alamat IPv6

   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_PATH
   

   Ganti kode berikut:

   • HEALTH_CHECK_NAME: nama health check
   • SOURCE_REGION: ketiga fitur keamanan Google Cloud wilayah tempat health check dilakukan. Anda harus menentukan tiga region sumber.
   • HEALTH_CHECK_INTERVAL: jumlah waktu dalam detik dari awal satu probe yang dikeluarkan oleh satu prober hingga awal probe berikutnya yang dikeluarkan oleh pengawas yang sama. Nilai minimum yang didukung adalah 30 detik. Untuk nilai yang direkomendasikan, lihat Praktik terbaik.
   • HEALTHY_THRESHOLD dan UNHEALTHY_THRESHOLD: jumlah elemen pemeriksaan yang harus berhasil atau gagal agar instance VM dapat dipertimbangkan sehat atau tidak sehat. Jika salah satunya dihilangkan, Google Cloud akan menggunakan nilai minimum default 2.
   • REQUEST_PATH: jalur URL tempat Google Cloud mengirimkan permintaan pemeriksaan health check. Jika dihilangkan, Google Cloud akan mengirimkan permintaan pemeriksaan ke jalur root, /. Jika endpoint yang diperiksa kondisinya bersifat pribadi, hal ini tidak umum untuk alamat IP aturan penerusan eksternal, Anda dapat menetapkan jalur ini ke /afhealthz.

2. Buat kumpulan data Cloud DNS di Cloud DNS dan terapkan kebijakan pemilihan rute ke subnet tersebut. Kebijakan perutean harus dikonfigurasi untuk mengatasi nama domain Anda ke alamat IP aturan penerusan load balancer utama, atau, jika terjadi kegagalan health check, ke salah satu beban cadangan penyeimbang alamat IP aturan penerusan.

   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_RATIO
   

   Ganti kode berikut:

   • DNS_RECORD_SET_NAME: Nama domain atau DNS yang akan ditambahkan—misalnya, test.example.com
   • TIME_TO_LIVE: time to live (TTL) untuk data yang diatur dalam jumlah detik. Untuk nilai yang direkomendasikan, lihat Terbaik praktik terbaik.
   • RECORD_TYPE: data jenis—misalnya, A
   • MANAGED_ZONE_NAME: nama zona terkelola yang kumpulan data yang ingin Anda kelola—misalnya, my-zone-name
   • PRIMARY_LOAD_BALANCER_FORWARDING_RULE: aturan penerusan nama load balancer utama
   • BACKUP_REGION: wilayah tempat load balancer cadangan di-deploy
   • BACKUP_LOAD_BALANCER_IP_ADDRESS: aturan penerusan Alamat IP load balancer cadangan yang sesuai dengan setiap region
   • BACKUP_DATA_TRICKLE_RATIO: rasio traffic terhadap dikirim ke load balancer cadangan, meskipun load balancer utama sehat. Rasionya harus antara 0 dan 1, misalnya 0,1. Defaultnya adalah tetapkan ke 0.

Praktik terbaik

Berikut ini beberapa praktik terbaik yang perlu diingat saat Anda mengonfigurasi Data Cloud DNS dan health check:

• Waktu yang dibutuhkan traffic untuk beralih dari beban utama ke cadangan (yaitu, durasi pemadaman) bergantung pada nilai TTL DNS, interval health check, dan health check adalah ambang batas.

  Dengan Cloud DNS Google, batas atas untuk periode ini adalah dihitung menggunakan formula berikut:

  Duration of outage = DNS TTL + Health Check Interval * Unhealthy Threshold
  

  Untuk 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 bahkan setelah DNS gagal ke Load Balancer Aplikasi eksternal regional cadangan.

• Konfigurasikan kampanye responsif dan parameter tidak responsif dalam respons pemeriksaan sedemikian rupa agar Anda menghindari failover yang tidak perlu yang disebabkan oleh error sementara. Nilai minimum yang lebih tinggi menambah waktu yang dibutuhkan traffic untuk beralih ke load balancer cadangan.

• Untuk membantu memastikan bahwa penyiapan failover Anda berfungsi seperti yang diharapkan, Anda dapat menyiapkan Kebijakan perutean DNS untuk selalu mengirim sebagian kecil traffic ke cadangan load balancer meskipun load balancer utama responsif. Dapat berupa dilakukan dengan menggunakan parameter --backup-data-trickle-ratio saat Anda membuat Kumpulan data DNS.

  Anda dapat mengonfigurasi persentase traffic yang dikirim ke cadangan sebagai pecahan dari 0 hingga 1. Nilai standarnya adalah 0,1, meskipun Cloud DNS memungkinkan Anda mengirim 100 persen lalu lintas ke alamat VIP cadangan, untuk memicu failover secara manual.