Halaman ini menjelaskan cara mengonfigurasi deployment yang sangat tersedia 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. Ini berfungsi karena Load Balancer Aplikasi eksternal regional di wilayah yang berbeda tidak hanya diisolasi satu sama lain, tetapi juga diisolasi dari Load Balancer Aplikasi eksternal global atau infrastruktur Load Balancer Aplikasi klasik yang berjalan di region yang sama.
Gunakan kebijakan perutean geolokasi Cloud DNS untuk mengarahkan traffic ke dua atau lebih banyak load balancer di berbagai region. Kebijakan ini mengarahkan traffic ke region terdekat yang tersedia berdasarkan asal permintaan klien. Kita juga sebaiknya gunakan health check agar Google Cloud dapat mendeteksi pemadaman layanan regional dan merutekan traffic hanya ke load balancer yang responsif.
Berikut contoh penyiapan yang menunjukkan dua Load Balancer Aplikasi eksternal regional dalam dua region yang berbeda-beda.
Bagian berikut ini menjelaskan alur kerja umum dengan berbagai komponen yang terlibat dalam konfigurasi ini.
Menggunakan health check untuk mendeteksi kegagalan regional
Google Cloud menggunakan layanan kesehatan pemeriksaan untuk mendeteksi apakah load balancer responsif. Anda mengonfigurasi health check ini untuk mengirim penyelidikan dari tiga region sumber. Ketiga region sumber ini harus perwakilan wilayah tempat klien Anda mengakses beban penyeimbang. Misalnya, jika Anda memiliki Load Balancer Aplikasi eksternal regional yang sebagian besar memiliki lalu lintas klien yang berasal dari Amerika Utara dan Eropa, Anda dapat probe yang berasal dari dua atau lebih region di Amerika Utara dan satelit yang berasal dari dua atau lebih wilayah di Eropa.
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.
Mengarahkan traffic ke load balancer yang responsif
Google Cloud menggunakan perutean geolokasi Cloud DNS untuk mengarahkan traffic ke load balancer. Jika semua load balancer responsif, Cloud DNS merutekan traffic ke load balancer yang secara geografis yang paling dekat dengan asal permintaan klien.
Saat load balancer di region tertentu mulai gagal dalam health check, traffic dirutekan ke load balancer responsif yang tersedia di region lain.
Gagal menggunakan semua load balancer
Failback akan otomatis terjadi saat health check mulai lulus lagi. Tidak ada periode nonaktif yang diperkirakan selama failback karena semua load balancer yang tersedia traffic penyaluran.
Mengonfigurasi load balancing lintas region
Lakukan langkah-langkah berikut untuk mengonfigurasi deployment lintas region yang memfasilitasi ketersediaan tinggi:
- Membuat Load Balancer Aplikasi eksternal regional di region tempat Anda menentukan traffic dukungan terbaik untuk aplikasi Anda. Setiap pemuatan ini load balancer harus memiliki konfigurasi keamanan dan pengelolaan traffic yang sama.
- Membuat health check dan kebijakan pemilihan rute DNS untuk mengarahkan traffic ke load balancer berdasarkan lokasi klien, dan mengarahkan traffic dari load balancer yang tidak responsif jika terjadi pemadaman layanan.
Membuat load balancer di beberapa region
Perhatikan pertimbangan berikut saat Anda mengonfigurasi konfigurasi load balancer Google Cloud:
Mengonfigurasi 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, kebijakan Google Cloud Armor yang sama, dan traffic yang sama untuk semua Load Balancer Aplikasi eksternal regional.
Sebaiknya gunakan framework otomatisasi seperti Terraform untuk membantu mencapai dan mempertahankan konsistensi konfigurasi load balancer di deployment regional yang berbeda.
Sebaiknya siapkan Load Balancer Aplikasi eksternal regional di setiap region yang Anda yang Anda tentukan paling dapat mendukung lalu lintas data untuk aplikasi Anda.
Load Balancer Aplikasi eksternal regional mendukung Premium dan Standar {i>Network Service Tiers<i}. Sebaiknya Anda menyiapkan Load Balancer Aplikasi eksternal regional di Paket Premium untuk memastikan latensi yang rendah.
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.
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 di region lain.
Gunakan langkah-langkah berikut untuk mengonfigurasi health check dan pemilihan rute yang diperlukan kebijakan:
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 checkSOURCE_REGION
: ketiga fitur keamanan Google Cloud region tempat pemeriksaan health check dikirim. 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
danUNHEALTHY_THRESHOLD
: menentukan 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
.
Di Cloud DNS, buat kumpulan data dan terapkan perutean geolokasi kebijakan pada perusahaan 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
: Nama domain atau DNS yang akan ditambahkan—misalnya,test.example.com
TIME_TO_LIVE
: time to live (TTL), dalam detik, sebagai catatan. Untuk nilai yang direkomendasikan, lihat DNS pertimbangan.RECORD_TYPE
: data jenis—misalnya,A
MANAGED_ZONE_NAME
: nama zona terkelola yang kumpulan datanya ingin Anda kelola—misalnya,my-zone-name
FORWARDING_RULE_NAME
: nama penerusan aturan untuk load balancer di setiapREGION
REGION
: region tempat setiap load balancer di-deploy
Praktik terbaik
Berikut ini beberapa praktik terbaik yang perlu diingat saat Anda mengonfigurasi Data Cloud DNS dan health check:
Waktu yang dibutuhkan lalu lintas untuk dirutekan dari beban tidak responsif ke sehat (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
Sebaiknya setel TTL DNS ke 30 hingga 60 detik. TTL yang lebih tinggi menyebabkan periode nonaktif yang lebih lama karena klien di internet terus mengakses {i>load balancer<i} yang tidak responsif bahkan setelah DNS gagal dialihkan ke region lain.
Mengonfigurasi parameter nilai minimum responsif dan tidak responsif dalam kondisi pemeriksaan sedemikian rupa agar Anda menghindari perutean ulang lalu lintas yang tidak perlu dan tiba-tiba karena kesalahan sementara. Nilai minimum yang lebih tinggi meningkatkan waktu yang diperlukan traffic untuk beralih ke pemuatan di region lain.