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 individual di region yang paling mendukung traffic aplikasi Anda. Hal ini berfungsi karena Load Balancer Aplikasi eksternal regional di region yang berbeda tidak hanya diisolasi satu sama lain, tetapi juga diisolasi 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 lebih load balancer di region yang berbeda. Kebijakan ini merutekan traffic ke region yang tersedia terdekat berdasarkan asal permintaan klien. Kami juga merekomendasikan agar Anda menggunakan health check sehingga Trusted Cloud dapat mendeteksi gangguan regional dan merutekan traffic hanya ke load balancer yang berfungsi dengan baik.

Berikut contoh penyiapan 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 alur kerja umum dengan berbagai komponen yang terlibat dalam konfigurasi ini.

  1. Menggunakan health check untuk mendeteksi kegagalan regional

    Trusted 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 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 wilayah sumber.
    • Health check HTTP, HTTPS, dan TCP didukung.
    • Pemeriksaan health check sebenarnya berasal dari Point of Presence (PoP) di internet dalam jarak kecil dari region sumber Trusted Cloudyang dikonfigurasi.
  2. Merutekan traffic ke load balancer yang responsif

    Trusted Cloud menggunakan kebijakan perutean geolokasi Cloud DNS untuk mengarahkan traffic ke load balancer. Jika semua load balancer dalam kondisi baik, Cloud DNS akan merutekan traffic ke load balancer yang secara geografis paling dekat dengan asal permintaan klien.

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

  3. Melakukan failback untuk menggunakan semua load balancer

    Failback bersifat otomatis saat health check mulai lulus lagi. Tidak ada waktu nonaktif yang diperkirakan selama failback karena semua load balancer yang tersedia melayani 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 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 dan kebijakan perutean DNS untuk mengarahkan traffic ke load balancer berdasarkan lokasi klien, dan untuk mengarahkan traffic dari load balancer yang tidak responsif jika terjadi gangguan.

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, Anda harus memastikan bahwa Anda menggunakan jenis sertifikat SSL yang sama, kebijakan 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 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 Network Service Tiers 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 Trusted Cloud pemeriksaan kondisi untuk mengonfigurasi lingkungan Cloud Load Balancing Anda guna mendeteksi gangguan dan merutekan traffic ke load balancer di region lain.

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

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

    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: tiga region Trusted Cloud 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 instance VM dianggap responsif atau tidak responsif. Jika salah satunya tidak ada, Trusted Cloud menggunakan nilai minimum default 2.
    • REQUEST_PATH: jalur URL yang menjadi tujuan Trusted Cloud mengirim permintaan pemeriksaan health check. Jika tidak ada, Trusted 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 menyetel jalur ini ke /afhealthz.
  2. Di Cloud DNS, buat set data dan terapkan kebijakan perutean geolokasi ke set data tersebut.

    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 Pertimbangan DNS.
    • RECORD_TYPE: jenis catatan—misalnya, A
    • MANAGED_ZONE_NAME: nama managed zone yang set catatannya 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 beberapa praktik terbaik yang perlu diingat saat Anda mengonfigurasi pemeriksaan kondisi dan catatan Cloud DNS:

  • Waktu yang diperlukan agar traffic dirutekan dari load balancer yang tidak responsif ke load balancer yang responsif (yaitu, durasi gangguan) 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 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 sehat meskipun DNS telah melakukan failover ke region lain.

  • Konfigurasi parameter batas responsif dan tidak responsif dalam health check sehingga Anda dapat 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.