Ketersediaan tinggi untuk Load Balancer Aplikasi eksternal regional

Halaman ini menjelaskan cara mengonfigurasi deployment multi-region dengan tingkat ketersediaan tinggi dengan Load Balancer Aplikasi eksternal regional. Untuk mencapai ketersediaan tinggi, deploy beberapa Load Balancer Aplikasi eksternal regional individual di region yang paling mendukung traffic aplikasi Anda. Hal ini berfungsi karena Load Balancer Aplikasi eksternal regional di berbagai region tidak hanya terisolasi satu sama lain, tetapi juga terisolasi dari infrastruktur Load Balancer Aplikasi eksternal global atau Load Balancer Aplikasi klasik yang berjalan di region yang sama.

Strategi ketersediaan tinggi

Anda dapat menerapkan ketahanan lintas region untuk Load Balancer Aplikasi eksternal regional menggunakan salah satu strategi berikut:

  • Aktif-pasif (failover region): Deploy Load Balancer Aplikasi eksternal regional utama di region utama Anda dan satu atau beberapa Load Balancer Aplikasi eksternal regional cadangan di region sekunder. Dalam status stabil, Cloud DNS mengarahkan semua traffic ke load balancer utama. Jika load balancer utama gagal dalam health check, Cloud DNS akan menggunakan kebijakan perutean failover untuk merutekan traffic ke load balancer regional cadangan.

    Berikut adalah contoh penyiapan aktif-pasif yang menunjukkan dua Load Balancer Aplikasi eksternal regional di dua region yang berbeda.

Ketersediaan tinggi dengan dua Load Balancer Aplikasi eksternal regional.
Ketersediaan tinggi dengan dua Load Balancer Aplikasi eksternal regional (klik untuk memperbesar).
  • Aktif-aktif (perutean kedekatan): Deploy beberapa Load Balancer Aplikasi eksternal regional di berbagai region yang melayani traffic secara bersamaan. Gunakan kebijakan pemilihan rute geolokasi Cloud DNS untuk mengarahkan klien ke region responsif terdekat. Jika load balancer di satu region mengalami pemadaman layanan, Cloud DNS akan otomatis mengalihkan traffic dari region yang tidak responsif ke load balancer yang responsif di region lain.

    Berikut adalah contoh penyiapan aktif-aktif yang menunjukkan dua Load Balancer Aplikasi eksternal regional di dua region berbeda.

    Ketersediaan tinggi dengan dua Load Balancer Aplikasi eksternal regional.
    Ketersediaan tinggi dengan dua Load Balancer Aplikasi eksternal regional (klik untuk memperbesar).

Bagian berikut menjelaskan cara kerja health check dan pengalihan traffic di seluruh region dalam alur kerja standar:

  1. Menggunakan health check untuk mendeteksi kegagalan regional

    Google Cloud menggunakan health check untuk mendeteksi apakah load balancer regional Anda responsif. Anda mengonfigurasi health check ini untuk mengirim pemeriksaan dari tiga region sumber. Ketiga region sumber ini harus mewakili region tempat klien Anda mengakses load balancer. Misalnya, jika Anda memiliki Load Balancer Aplikasi eksternal regional dengan mayoritas traffic klien yang berasal dari Amerika Utara dan Eropa, Anda dapat memiliki pemeriksaan yang berasal dari dua region atau lebih di Amerika Utara dan pemeriksaan yang berasal dari dua region atau lebih di Eropa.

    Catatan tambahan:

    • Anda harus menentukan tepat tiga region sumber saat membuat health check. Hanya health check global yang dapat menentukan region sumber.
    • Health check HTTP, HTTPS, dan TCP didukung.
    • Pemeriksaan health check berasal dari Point of Presence (PoP) di internet dalam jarak dekat dari region sumber Google Cloudyang dikonfigurasi.
  2. Merutekan traffic berdasarkan kebijakan perutean

    • Aktif-pasif: Cloud DNS menggunakan kebijakan perutean failover untuk mengarahkan 100% traffic klien ke load balancer regional utama selama status stabil. Jika load balancer regional utama gagal dalam health check, Cloud DNS akan mengarahkan traffic ke load balancer regional cadangan.
    • Aktif-aktif: Cloud DNS menggunakan kebijakan perutean geolokasi untuk mengarahkan traffic ke load balancer. Jika semua load balancer responsif, Cloud DNS akan mengarahkan traffic ke load balancer yang secara geografis paling dekat dengan klien. Jika load balancer di suatu region mulai gagal dalam health check, traffic akan otomatis dialihkan ke load balancer yang responsif dan tersedia di region lain.
  3. Failback ke load balancer utama

    Failback akan otomatis dilakukan saat health check mulai lulus lagi. Traffic dipulihkan tanpa periode nonaktif karena load balancer menyalurkan traffic.

Mengonfigurasi load balancing multi-region

Untuk mengonfigurasi deployment multi-region yang memfasilitasi ketersediaan tinggi, lakukan langkah-langkah berikut:

  1. Buat Load Balancer Aplikasi eksternal regional di region yang menurut Anda paling mendukung traffic untuk aplikasi Anda. Setiap load balancer ini harus memiliki konfigurasi pengelolaan traffic dan keamanan yang sama.
  2. Buat health check untuk memantau alamat IP aturan penerusan load balancer regional Anda.
  3. Konfigurasikan kebijakan perutean DNS di Cloud DNS:

Membuat load balancer di beberapa region

Perhatikan pertimbangan berikut saat Anda mengonfigurasi load balancer redundan tambahan:

  • Konfigurasikan semua Load Balancer Aplikasi eksternal regional dengan fitur serupa sehingga traffic diproses secara konsisten, terlepas dari load balancer mana yang melayani permintaan. Misalnya, pastikan Anda menggunakan jenis sertifikat SSL yang sama, kebijakan keamanan regional Cloud Armor yang sama, dan setelan pemilihan rute peta URL yang sama untuk semua Load Balancer Aplikasi eksternal regional.

    Sebaiknya gunakan framework otomatisasi seperti Terraform untuk membantu mencapai dan mempertahankan konsistensi dalam konfigurasi load balancer di berbagai deployment regional.

  • Sebaiknya siapkan Load Balancer Aplikasi eksternal regional di setiap region yang Anda tentukan akan mendukung traffic untuk aplikasi Anda dengan baik.

  • Load Balancer Aplikasi eksternal regional mendukung Network Service Tiers Premium dan Standar. Sebaiknya siapkan Load Balancer Aplikasi eksternal regional di Paket Premium untuk memastikan latensi rendah.

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

Membuat health check

Buat health check global untuk memantau alamat IP eksternal dari setiap aturan penerusan load balancer regional:

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_PATH

Ganti kode berikut:

  • HEALTH_CHECK_NAME: nama health check
  • SOURCE_REGION_1, SOURCE_REGION_2, dan SOURCE_REGION_3: tiga region Google Cloud tempat pemeriksaan health check dikirim. Anda harus menentukan tepat tiga region 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 mengetahui nilai yang direkomendasikan, lihat Praktik terbaik.
  • HEALTHY_THRESHOLD dan UNHEALTHY_THRESHOLD: menentukan jumlah pemeriksaan berurutan yang harus berhasil atau gagal agar load balancer 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 diperiksa responsnya bersifat pribadi, yang tidak umum untuk alamat IP aturan penerusan eksternal, Anda dapat menetapkan jalur ini ke /afhealthz.

Mengonfigurasi failover regional aktif-pasif

Di Cloud DNS, buat set data dan terapkan kebijakan perutean FAILOVER untuk mengirim traffic status stabil ke load balancer regional utama dan melakukan failover ke load balancer regional cadangan selama pemadaman layanan:

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_REGIONAL_FORWARDING_RULE \
    --routing-policy-backup-data_type=GEO \
    --routing-policy-backup-data="BACKUP_REGION_1=BACKUP_LOAD_BALANCER_1_IP[;BACKUP_REGION_2=BACKUP_LOAD_BALANCER_2_IP]" \
    --health-check=HEALTH_CHECK_NAME \
    --backup-data-trickle-ratio=BACKUP_DATA_TRICKLE_RATIO

Ganti kode berikut:

  • DNS_RECORD_SET_NAME: nama domain atau DNS dari set data yang akan ditambahkan—misalnya, test.example.com
  • TIME_TO_LIVE: TTL dalam detik untuk data. Untuk mengetahui nilai yang direkomendasikan, lihat Praktik terbaik.
  • RECORD_TYPE: jenis data—misalnya, A
  • MANAGED_ZONE_NAME: nama zona terkelola Cloud DNS Anda—misalnya, my-zone-name
  • PRIMARY_REGIONAL_FORWARDING_RULE: nama aturan penerusan Load Balancer Aplikasi eksternal regional utama
  • BACKUP_REGION_1 dan BACKUP_REGION_2: region tempat Load Balancer Aplikasi eksternal regional cadangan di-deploy
  • BACKUP_LOAD_BALANCER_1_IP dan BACKUP_LOAD_BALANCER_2_IP: alamat IP eksternal aturan penerusan dari Load Balancer Aplikasi eksternal regional cadangan
  • HEALTH_CHECK_NAME: nama health check
  • BACKUP_DATA_TRICKLE_RATIO: pecahan traffic (dari 0 hingga 1, seperti 0.1) yang akan dikirim ke load balancer regional cadangan selama status stabil untuk memastikan cadangan sudah siap dan aktif. Defaultnya adalah 0.

Mengonfigurasi perutean region aktif-aktif

Di Cloud DNS, buat set data dan terapkan kebijakan perutean geolokasi untuk mengarahkan traffic secara serentak di seluruh load balancer regional yang responsif:

gcloud dns record-sets create DNS_RECORD_SET_NAME \
    --ttl=TIME_TO_LIVE \
    --type=RECORD_TYPE \
    --zone="MANAGED_ZONE_NAME" \
    --routing-policy-type="GEO" \
    --routing-policy-data="FORWARDING_RULE_NAME_A@REGION_A;FORWARDING_RULE_NAME_B@REGION_B[,;FORWARDING_RULE_NAME_C@REGION_C]" \
    --health-check=HEALTH_CHECK_NAME

Ganti kode berikut:

  • DNS_RECORD_SET_NAME: nama domain atau DNS dari set data yang akan ditambahkan—misalnya, test.example.com
  • TIME_TO_LIVE: time to live (TTL), dalam detik, untuk data. Untuk mengetahui nilai yang direkomendasikan, lihat Praktik terbaik.
  • RECORD_TYPE: jenis data—misalnya, A
  • MANAGED_ZONE_NAME: nama zona terkelola yang set data-nya ingin Anda kelola—misalnya, my-zone-name
  • FORWARDING_RULE_NAME_A, FORWARDING_RULE_NAME_B, dan FORWARDING_RULE_NAME_C: nama aturan penerusan untuk load balancer di setiap region yang sesuai
  • REGION_A, REGION_B, dan REGION_C: region tempat setiap load balancer di-deploy
  • HEALTH_CHECK_NAME: nama health check

Praktik terbaik

Berikut adalah beberapa praktik terbaik yang perlu diperhatikan saat Anda mengonfigurasi data DNS Cloud dan health check:

  • Menghitung durasi pemadaman layanan: Waktu yang diperlukan untuk mengarahkan traffic dari load balancer yang tidak responsif ke load balancer yang responsif (durasi pemadaman layanan) bergantung pada nilai TTL DNS, interval health check, dan parameter nilai minimum tidak responsif health check:

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

    Sebaiknya tetapkan TTL DNS ke 30 hingga 60 detik. TTL yang lebih tinggi menyebabkan periode nonaktif yang lebih lama karena klien di internet terus mengakses load balancer yang tidak responsif bahkan setelah DNS gagal beralih ke region lain.

  • Konfigurasi nilai minimum health check: Konfigurasi parameter nilai minimum responsif dan tidak responsif untuk menghindari pengalihan ulang traffic yang tidak perlu dan tiba-tiba karena error sementara. Nilai minimum yang lebih tinggi akan meningkatkan waktu yang diperlukan traffic untuk beralih ke load balancer di region lain.

  • Gunakan trickle traffic untuk validasi aktif-pasif: Dalam penyiapan aktif-pasif, konfigurasikan flag --backup-data-trickle-ratio untuk terus mengirimkan sebagian kecil traffic (misalnya, 0.1) ke load balancer regional cadangan selama status stabil. Langkah ini memverifikasi bahwa infrastruktur cadangan aktif dan siap menangani traffic selama peristiwa failover.