Ketersediaan tinggi untuk Load Balancer Aplikasi eksternal regional

Halaman ini menjelaskan cara mengonfigurasi deployment dengan ketersediaan tinggi menggunakan Load Balancer Aplikasi eksternal regional. Untuk mencapai ketersediaan tinggi, deploy beberapa Load Balancer Aplikasi eksternal regional 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.

Gunakan kebijakan perutean geolokasi Cloud DNS untuk merutekan traffic ke dua atau beberapa load balancer di region yang berbeda. Kebijakan merutekan traffic ke wilayah terdekat yang tersedia berdasarkan asal permintaan klien. Sebaiknya Anda juga menggunakan health check agar Google Cloud dapat mendeteksi pemadaman layanan regional dan merutekan traffic hanya ke load balancer yang berfungsi dengan baik.

Berikut adalah contoh penyiapan yang menampilkan 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).

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

  1. Menggunakan health check untuk mendeteksi kegagalan regional

    Google Cloud menggunakan health check untuk mendeteksi apakah load balancer 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 mengakses load balancer. Misalnya, jika Anda memiliki Application Load Balancer eksternal regional dengan sebagian besar traffic klien yang 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 wilayah sumber.
    • Health check HTTP, HTTPS, dan TCP didukung.
    • Proba health check sebenarnya berasal dari Titik Kehadiran (PoP) di internet dalam jarak yang cukup dekat dari region sumber Google Cloud yang dikonfigurasi.

  2. Merutekan traffic ke load balancer yang responsif

    Google Cloud menggunakan kebijakan perutean geolokasi Cloud DNS untuk mengarahkan traffic ke load balancer. Jika semua load balancer berfungsi dengan baik, Cloud DNS akan merutekan traffic ke load balancer yang geografisnya paling dekat dengan asal permintaan klien.

    Saat load balancer di region tertentu mulai gagal dalam health check, traffic akan dirutekan ke load balancer responsif yang tersedia di region lain.

  3. Failback untuk menggunakan semua load balancer

    Failback bersifat otomatis saat health check mulai lulus lagi. Tidak ada downtime yang diharapkan selama failback karena semua load balancer yang tersedia menayangkan traffic.

Mengonfigurasi load balancing lintas region

Lakukan langkah-langkah berikut untuk mengonfigurasi deployment lintas region yang memfasilitasi ketersediaan tinggi:

  1. Buat Load Balancer Aplikasi eksternal regional di region yang Anda tentukan sebagai traffic pendukung terbaik untuk aplikasi Anda. Setiap load balancer ini harus memiliki konfigurasi keamanan dan pengelolaan traffic yang sama.
  2. Buat health check dan kebijakan perutean DNS untuk mengarahkan traffic ke load balancer berdasarkan lokasi klien, dan untuk me-rutekan traffic dari load balancer yang tidak responsif jika terjadi pemadaman layanan.

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, Anda harus memastikan bahwa Anda menggunakan jenis sertifikat SSL yang sama, kebijakan Google Cloud Armor yang sama, dan setelan pengelolaan traffic 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 seluruh deployment regional yang berbeda.

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

  • Load Balancer Aplikasi eksternal regional mendukung Paket Layanan Jaringan Premium dan Standar. Sebaiknya siapkan Load Balancer Aplikasi eksternal regional tambahan 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.

Mengonfigurasi Cloud DNS dan health check

Bagian ini menjelaskan cara menggunakan Cloud DNS dan pemeriksaan kesehatan Google Cloud untuk mengonfigurasi lingkungan Cloud Load Balancing Anda guna mendeteksi pemadaman layanan dan merutekan traffic ke load balancer di region lain.

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

  1. 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_PATH

    Ganti kode berikut:

    • HEALTH_CHECK_NAME: nama health check
    • SOURCE_REGION: tiga region Google Cloud tempat pemeriksaan health check dikirim. 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_THRESHOLD dan UNHEALTHY_THRESHOLD: menentukan 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 diperiksa kondisinya bersifat pribadi, yang tidak biasa untuk alamat IP aturan penerusan eksternal, Anda dapat menetapkan jalur ini ke /afhealthz.

  2. Di Cloud DNS, buat kumpulan data dan terapkan kebijakan perutean geolokasi ke kumpulan data tersebut.

    gcloud beta 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: DNS atau nama domain data yang ditetapkan untuk ditambahkan—misalnya, test.example.com
    • TIME_TO_LIVE: time to live (TTL), dalam detik, untuk data. Untuk nilai yang direkomendasikan, lihat Pertimbangan DNS.
    • RECORD_TYPE: jenis data—misalnya, A
    • MANAGED_ZONE_NAME: nama zona terkelola yang kumpulan datanya ingin Anda kelola—misalnya, my-zone-name
    • FORWARDING_RULE_NAME: nama aturan penerusan untuk load balancer di setiap REGION
    • REGION: region tempat setiap load balancer di-deploy

Praktik terbaik

Berikut adalah beberapa praktik terbaik yang perlu diingat saat Anda mengonfigurasi data dan pemeriksaan kesehatan Cloud DNS:

  • Waktu yang diperlukan untuk merutekan traffic dari load balancer yang tidak responsif ke load balancer yang responsif (yaitu, durasi pemadaman) bergantung pada nilai TTL DNS, interval health check, dan parameter batas tidak responsif health check.

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

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

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

  • Konfigurasikan parameter batas responsif dan tidak responsif dalam health check sehingga Anda menghindari pengalihan traffic yang tidak perlu dan tiba-tiba karena error sementara. Batas yang lebih tinggi akan meningkatkan waktu yang diperlukan untuk mengalihkan traffic ke load balancer di region lain.