Ketersediaan tinggi untuk Load Balancer Aplikasi eksternal regional

Halaman ini menjelaskan cara mengonfigurasi deployment multiregion dengan ketersediaan tinggi menggunakan 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 region yang berbeda 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 dengan 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 kondisi stabil, Cloud DNS mengarahkan semua traffic ke load balancer utama. Jika load balancer utama gagal dalam health check, Cloud DNS akan menggunakan kebijakan pemilihan rute failover untuk merutekan traffic ke load balancer regional cadangan.

    Berikut 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 terdekat yang responsif. Jika load balancer di satu region mengalami pemadaman layanan, Cloud DNS akan otomatis mengalihkan traffic dari region yang bermasalah ke load balancer yang responsif di region lain.

    Berikut contoh penyiapan aktif-aktif yang menampilkan 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 pemeriksaan kondisi dan pengarahan traffic di seluruh region dalam alur kerja umum:

  1. Menggunakan health check untuk mendeteksi kegagalan regional

    Google Cloud menggunakan health check untuk mendeteksi apakah load balancer regional Anda berfungsi dengan baik. 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 sebagian besar traffic klien berasal dari Amerika Utara dan Eropa, Anda dapat memiliki probe yang berasal dari dua region atau lebih di Amerika Utara dan probe 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 kecil dari region sumber Google Cloudyang dikonfigurasi.

  2. Merutekan traffic berdasarkan kebijakan pemilihan rute

    • Aktif-pasif: Cloud DNS menggunakan kebijakan pemilihan rute failover untuk mengarahkan 100% traffic klien ke load balancer regional utama selama kondisi 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 merutekan traffic ke load balancer yang secara geografis paling dekat dengan klien. Jika load balancer di suatu region mulai gagal melakukan health check, traffic akan otomatis diarahkan ke load balancer yang responsif dan tersedia di region lain.

  3. Melakukan failback ke load balancer utama

    Failback bersifat otomatis saat health check mulai lulus lagi. Traffic dipulihkan tanpa menyebabkan gangguan karena load balancer melayani 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 baik mendukung traffic untuk aplikasi Anda. Setiap load balancer ini harus memiliki konfigurasi keamanan dan pengelolaan traffic yang sama.
  2. Buat health check untuk memantau alamat IP aturan penerusan load balancer regional Anda.
  3. Konfigurasi kebijakan pemilihan rute DNS di Cloud DNS:

Membuat load balancer di beberapa region

Perhatikan pertimbangan berikut saat Anda mengonfigurasi load balancer tambahan yang redundan:

  • Konfigurasi 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 perutean 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 menurut Anda paling baik mendukung traffic untuk aplikasi Anda.

  • Load Balancer Aplikasi eksternal regional mendukung Paket Layanan Jaringan 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 aturan penerusan setiap 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 Google Cloud region tempat pemeriksaan health check dikirim. 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_THRESHOLD dan UNHEALTHY_THRESHOLD: menentukan jumlah pemeriksaan berurutan yang harus berhasil atau gagal agar load balancer dianggap responsif atau tidak responsif. Jika salah satunya tidak ada, Google Cloud akan menggunakan nilai minimum default 2.
  • REQUEST_PATH: jalur URL yang menjadi tujuan Google Cloud mengirim permintaan pemeriksaan health check. Jika tidak ada, Google Cloud mengirim permintaan probe 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.

Mengonfigurasi failover regional aktif-pasif

Di Cloud DNS, buat kumpulan data dan terapkan kebijakan pemilihan rute FAILOVER untuk mengirim traffic dalam kondisi stabil ke load balancer regional utama dan melakukan failover ke load balancer regional cadangan selama terjadi gangguan:

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 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 Load Balancer Aplikasi eksternal regional cadangan
  • HEALTH_CHECK_NAME: nama health check
  • BACKUP_DATA_TRICKLE_RATIO: fraksi traffic (dari 0 hingga 1, seperti 0.1) yang akan dikirim ke load balancer regional cadangan selama kondisi stabil untuk memastikan cadangan siap dan berfungsi. Defaultnya adalah 0.

Mengonfigurasi perutean wilayah aktif-aktif

Di Cloud DNS, buat set data dan terapkan kebijakan pemilihan rute geolokasi untuk mengarahkan traffic secara bersamaan di seluruh load balancer regional yang sehat:

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 nilai yang direkomendasikan, lihat Praktik terbaik.
  • RECORD_TYPE: jenis data—misalnya, A
  • MANAGED_ZONE_NAME: nama zona terkelola yang set datanya 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 beberapa praktik terbaik yang perlu diingat saat Anda mengonfigurasi data Cloud DNS dan health check:

  • Menghitung durasi gangguan: Waktu yang diperlukan agar traffic dialihkan dari load balancer yang tidak responsif ke load balancer yang responsif (durasi gangguan) bergantung pada nilai TTL DNS, interval health check, dan parameter ambang batas 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 waktu henti yang lebih lama karena klien di internet terus mengakses load balancer yang tidak responsif meskipun DNS telah melakukan failover ke region lain.

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

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