Google Cloud menawarkan health check yang dapat dikonfigurasi untuk backend load balancer Google Cloud, backend Cloud Service Mesh, dan pemulihan otomatis berbasis aplikasi untuk grup instance terkelola. Dokumen ini membahas konsep pemeriksaan kesehatan utama.
Kecuali jika dinyatakan lain, health check Google Cloud diterapkan oleh tugas software khusus yang terhubung ke backend sesuai dengan parameter yang ditentukan dalam resource health check. Setiap upaya koneksi disebut probe. Google Cloud mencatat keberhasilan atau kegagalan setiap probe.
Berdasarkan jumlah probe berurutan yang berhasil atau gagal yang dapat dikonfigurasi, status respons secara keseluruhan dihitung untuk setiap backend. Backend yang berhasil merespons sebanyak yang dikonfigurasi dianggap responsif. Backend yang gagal merespons dengan sukses untuk sejumlah kali yang dapat dikonfigurasi secara terpisah dianggap tidak responsif.
Status kondisi keseluruhan setiap backend menentukan kelayakan untuk menerima permintaan atau koneksi baru. Anda dapat mengonfigurasi kriteria yang menentukan probe yang berhasil. Hal ini dibahas secara mendetail di bagian Cara kerja health check.
Health check yang diterapkan oleh tugas software khusus menggunakan rute khusus yang tidak ditentukan di jaringan Virtual Private Cloud (VPC) Anda. Untuk mengetahui informasi selengkapnya, lihat Jalur untuk health check.
Kategori, protokol, dan port health check
Health check memiliki kategori dan protokol. Kedua kategori tersebut adalah health check dan health check lama, dan protokol yang didukungnya adalah sebagai berikut:
Health check
Health check lama:
Protokol dan port menentukan cara pemeriksaan health check dilakukan. Misalnya, health check dapat menggunakan protokol HTTP di port TCP 80, atau dapat menggunakan protokol TCP untuk port bernama dalam grup instance.
Anda tidak dapat mengonversi health check lama menjadi health check, dan Anda tidak dapat mengonversi health check menjadi health check lama.
Memilih health check
Health check harus kompatibel dengan jenis load balancer (atau Cloud Service Mesh) dan jenis backend. Faktor-faktor yang perlu dipertimbangkan saat Anda memilih pemeriksaan kesehatan adalah sebagai berikut:
- Kategori: health check atau health check lama. Hanya Load Balancer Jaringan passthrough eksternal berbasis kumpulan target yang memerlukan health check lama. Untuk semua produk lainnya, Anda akan menggunakan pemeriksaan kesehatan rutin.
- Protokol: protokol yang digunakan Google Cloud untuk menyelidiki backend. Sebaiknya gunakan health check (atau health check lama) yang protokolnya cocok dengan protokol yang digunakan oleh layanan backend atau kumpulan target load balancer. Namun, protokol health check dan protokol load balancer tidak harus sama.
- Spesifikasi port: port yang digunakan Google Cloud dengan protokol.
Anda harus menentukan port untuk health check. Health check memiliki dua metode
spesifikasi port:
--portdan--use-serving-port. Untuk health check lama, ada satu metode:--port. Untuk mengetahui informasi selengkapnya tentang persyaratan port health check per load balancer, lihat Flag spesifikasi port.
Bagian berikutnya menjelaskan pilihan health check yang valid untuk setiap jenis load balancer dan backend.
Panduan load balancer
Tabel ini menunjukkan kategori dan cakupan health check yang didukung untuk setiap jenis load balancer.
| Load balancer | Kategori dan cakupan health check |
|---|---|
|
Load Balancer Aplikasi eksternal global Load Balancer Aplikasi Klasik * Load Balancer Jaringan proxy eksternal global Load Balancer Jaringan proxy klasik Load Balancer Aplikasi internal lintas region Load Balancer Jaringan proxy internal lintas region |
Health check (global) |
|
Load Balancer Aplikasi eksternal regional Load Balancer Aplikasi internal regional Load Balancer Jaringan proxy internal regional Load Balancer Jaringan proxy eksternal regional |
Health check (regional) |
| Load Balancer Jaringan passthrough eksternal | Load balancer berbasis layanan backend: Health check (regional) Load balancer berbasis kumpulan target: Health check lama |
| Load Balancer Jaringan passthrough internal | Health check (global atau regional) |
| Mode load balancer | Health check lama yang didukung |
|---|---|
Load Balancer Aplikasi eksternal global Load Balancer Aplikasi Klasik |
Ya, jika kedua hal berikut berlaku:
|
| Load Balancer Aplikasi eksternal regional | Tidak |
Catatan penggunaan tambahan
Untuk backend grup instance VM, health check hanya dilakukan pada instance VM yang dimulai. Instance VM yang dihentikan tidak menerima paket health check.
Untuk Load Balancer Jaringan passthrough internal, Anda hanya dapat menggunakan
TCPatauUDPuntuk protokol layanan backend. Jika Anda menyalurkan traffic HTTP dari VM di balik Network Load Balancer passthrough internal, sebaiknya gunakan health check menggunakan protokol HTTP.Load Balancer Jaringan passthrough eksternal berbasis kumpulan target harus menggunakan health check HTTP lama. Health check ini tidak dapat menggunakan health check HTTPS lama atau health check non-lama. Jika menggunakan Load Balancer Jaringan passthrough eksternal berbasis kumpulan target untuk menyeimbangkan traffic TCP, Anda harus menjalankan layanan HTTP di VM yang di-load balance agar dapat merespons pemeriksaan kesehatan.
Untuk hampir semua jenis load balancer lainnya, Anda harus menggunakan health check reguler, bukan lama, dengan protokol yang cocok dengan protokol layanan backend load balancer.Untuk layanan backend yang menggunakan protokol gRPC, hanya gunakan health check gRPC atau TCP. Jangan gunakan health check HTTP(S) atau HTTP/2.
Load balancer berbasis Envoy tertentu yang menggunakan backend NEG campuran tidak mendukung health check gRPC. Untuk informasi selengkapnya, lihat Ringkasan NEG Hybrid.
Pemeriksaan status dengan Cloud Service Mesh
Perhatikan perbedaan perilaku berikut saat Anda menggunakan health check dengan Cloud Service Mesh.
Dengan Cloud Service Mesh, perilaku health check untuk endpoint jaringan jenis
INTERNET_FQDN_PORTdanNON_GCP_PRIVATE_IP_PORTberbeda dengan perilaku health check untuk jenis endpoint jaringan lainnya. Daripada menggunakan tugas software khusus, Cloud Service Mesh memprogram proxy Envoy untuk melakukan health check untuk NEG internet (endpointINTERNET_FQDN_PORT) dan NEG hibrida (endpointNON_GCP_PRIVATE_IP_PORT).Envoy mendukung protokol berikut untuk health check:
- HTTP
- HTTPS
- HTTP/2
- TCP
Saat Cloud Service Mesh terintegrasi dengan Direktori Layanan dan Anda mengikat layanan Direktori Layanan ke layanan backend Cloud Service Mesh, Anda tidak dapat menetapkan health check pada layanan backend.
Cara kerja health check
Bagian berikut menjelaskan cara kerja pemeriksaan kesehatan.
Probe
Saat membuat health check atau health check lama, Anda menentukan flag berikut atau menerima nilai defaultnya. Setiap health check atau health check lama yang Anda buat diterapkan oleh beberapa probe. Flag ini mengontrol frekuensi setiap probe mengevaluasi instance dalam grup instance atau endpoint di NEG zonal.
Setelan health check tidak dapat dikonfigurasi per backend. Pemeriksaan kesehatan dikaitkan dengan seluruh layanan backend. Untuk Load Balancer Jaringan passthrough eksternal berbasis kumpulan target, health check HTTP lama dikaitkan dengan seluruh kumpulan target. Dengan demikian, parameter untuk probe sama untuk semua backend yang dirujuk oleh layanan backend atau kumpulan target tertentu.
| Flag konfigurasi | Tujuan | Nilai default |
|---|---|---|
Check intervalcheck-interval |
Interval pemeriksaan adalah jumlah waktu dari awal satu pemeriksaan yang dikeluarkan oleh satu pengorek hingga awal pemeriksaan berikutnya yang dikeluarkan oleh pengorek yang sama. Unit dalam hitungan detik. | 5s (5 detik) |
Waktu tunggutimeout |
Waktu tunggu adalah jumlah waktu yang diperlukan Google Cloud untuk menunggu respons terhadap pemeriksaan. Nilainya harus kurang dari atau sama dengan interval pemeriksaan. Unit dalam hitungan detik. | 5s (5 detik) |
Memeriksa rentang IP dan aturan firewall
Agar health check berfungsi, Anda harus membuat aturan firewall allow masuk sehingga traffic dari penguji Google Cloud dapat terhubung ke backend Anda. Untuk mengetahui petunjuknya, lihat Membuat aturan firewall yang diperlukan.
Tabel berikut menunjukkan rentang IP sumber yang diizinkan untuk setiap load balancer:
| Produk | Rentang IP sumber pemeriksaan health check |
|---|---|
|
Untuk traffic IPv6 ke backend:
|
Untuk traffic IPv6 ke backend:
|
|
|
|
| Load Balancer Jaringan passthrough eksternal 3 |
Untuk traffic IPv4 ke backend:
Untuk traffic IPv6 ke backend:
|
| Load Balancer Network passthrough internal |
Untuk traffic IPv4 ke backend:
Untuk traffic IPv6 ke backend:
|
| Cloud Service Mesh dengan backend NEG internet dan backend NEG campuran | Alamat IP VM yang menjalankan software Envoy Untuk contoh konfigurasi, lihat dokumentasi Cloud Service Mesh |
1 Menambahkan rentang probe health check Google ke daftar yang diizinkan tidak diperlukan untuk NEG hibrida. Namun, jika Anda menggunakan kombinasi NEG campuran dan zonal dalam satu layanan backend, Anda harus mengizinkan rentang probe pemeriksaan kesehatan Google untuk NEG zonal.
2 Untuk NEG internet regional, health check bersifat opsional. Traffic dari load balancer yang menggunakan NEG internet regional berasal dari subnet khusus proxy, lalu diterjemahkan NAT (dengan menggunakan Cloud NAT) ke alamat IP NAT yang dialokasikan secara manual atau otomatis. Traffic ini mencakup pemeriksaan health check dan permintaan pengguna dari load balancer ke backend. Untuk mengetahui detailnya, lihat NEG regional: Menggunakan Cloud NAT untuk keluar.
3 Load Balancer Jaringan passthrough eksternal berbasis kumpulan target hanya mendukung traffic IPv4 dan
dapat melakukan proxy health check melalui server metadata. Dalam hal ini,
sumber paket health check cocok dengan alamat IP server metadata:
169.254.169.254. Anda tidak perlu membuat aturan
firewall untuk mengizinkan traffic dari server metadata. Paket dari
server metadata selalu diizinkan.
Pentingnya aturan firewall
Google Cloud mengharuskan Anda membuat aturan firewall allow masuk yang diperlukan untuk mengizinkan traffic dari pemeriksa ke backend Anda. Sebagai praktik
terbaik, batasi aturan ini hanya pada protokol dan port yang
cocok dengan yang digunakan oleh health check Anda. Untuk rentang IP sumber, pastikan untuk menggunakan rentang IP probe yang terdokumentasi dan tercantum di bagian sebelumnya.
Jika Anda tidak memiliki aturan firewall allow masuk yang mengizinkan health check, aturan deny tersirat akan memblokir traffic masuk. Jika penguji tidak dapat menghubungi backend Anda, load balancer akan menganggap backend Anda tidak responsif.
Pertimbangan keamanan untuk rentang IP probe
Pertimbangkan informasi berikut saat merencanakan health check dan aturan firewall yang diperlukan:
Rentang IP probe adalah milik Google. Google Cloud menggunakan rute khusus di luar jaringan VPC Anda, tetapi dalam jaringan produksi Google untuk memfasilitasi komunikasi dari prober.
Google menggunakan rentang IP probe untuk mengirim probe health check untuk Load Balancer Aplikasi eksternal dan Load Balancer Jaringan proxy eksternal. Jika paket diterima dari internet dan alamat IP sumber paket berada dalam rentang IP probe, Google akan menghapus paket tersebut. Ini mencakup alamat IP eksternal instance Compute Engine atau node Google Kubernetes Engine (GKE).
Rentang IP probe adalah kumpulan lengkap alamat IP yang mungkin digunakan oleh prober Google Cloud. Jika menggunakan
tcpdumpatau alat serupa, Anda mungkin tidak mengamati traffic dari semua alamat IP di semua rentang IP probe. Sebagai praktik terbaik, buat aturan firewall masuk yang mengizinkan semua rentang IP pengujian sebagai sumber. Google Cloud dapat menerapkan pemeriksa baru secara otomatis tanpa pemberitahuan.
Beberapa pemeriksaan dan frekuensi
Google Cloud mengirimkan pemeriksaan health check dari beberapa sistem redundan yang disebut penguji. Prober menggunakan rentang IP sumber tertentu. Google Cloud tidak hanya mengandalkan satu penguji untuk menerapkan health check. Beberapa penguji secara bersamaan mengevaluasi instance di backend grup instance atau endpoint di backend NEG zonal. Jika satu penguji gagal, Google Cloud akan terus melacak status kesehatan backend.
Setelan interval dan waktu tunggu yang Anda konfigurasikan untuk health check diterapkan ke setiap pemeriksa. Untuk backend tertentu, log akses software dan
tcpdump menampilkan probe yang lebih sering daripada setelan yang Anda konfigurasikan.
Ini adalah perilaku yang diharapkan, dan Anda tidak dapat mengonfigurasi jumlah pemeriksa yang digunakan Google Cloud untuk health check. Namun, Anda dapat memperkirakan dampak dari beberapa probe serentak dengan mempertimbangkan faktor-faktor berikut.
Untuk memperkirakan frekuensi pemeriksaan per layanan backend, pertimbangkan hal berikut:
Frekuensi dasar per layanan backend. Setiap health check memiliki frekuensi pemeriksaan terkait, yang berbanding terbalik dengan interval pemeriksaan yang dikonfigurasi:
1⁄(interval pemeriksaan)
Saat mengaitkan health check dengan layanan backend, Anda menetapkan frekuensi dasar yang digunakan oleh setiap pemeriksa untuk backend di layanan backend tersebut.
Faktor skala probe. Frekuensi dasar layanan backend dikalikan dengan jumlah pemeriksa serentak yang digunakan Google Cloud. Jumlah ini dapat bervariasi, tetapi umumnya antara 5 dan 10.
Beberapa aturan penerusan untuk Load Balancer Jaringan passthrough internal. Jika Anda telah mengonfigurasi beberapa aturan penerusan internal (masing-masing memiliki alamat IP yang berbeda) yang mengarah ke layanan backend internal regional yang sama, Google Cloud akan menggunakan beberapa penguji untuk memeriksa setiap alamat IP. Frekuensi probe per layanan backend dikalikan dengan jumlah aturan penerusan yang dikonfigurasi.
Beberapa aturan penerusan untuk Load Balancer Jaringan passthrough eksternal. Jika Anda telah mengonfigurasi beberapa aturan penerusan yang mengarah ke layanan backend atau kumpulan target yang sama, Google Cloud akan menggunakan beberapa penguji untuk memeriksa setiap alamat IP. Frekuensi pemeriksaan per VM backend, dikalikan dengan jumlah aturan penerusan yang dikonfigurasi.
Beberapa proxy target untuk Load Balancer Aplikasi eksternal. Jika Anda memiliki beberapa proxy target yang mengarahkan traffic ke peta URL yang sama, Google Cloud akan menggunakan beberapa prober untuk memeriksa alamat IP yang terkait dengan setiap proxy target. Frekuensi pemeriksaan per layanan backend dikalikan dengan jumlah proxy target yang dikonfigurasi.
Beberapa proxy target untuk Load Balancer Jaringan proxy eksternal dan Load Balancer Jaringan proxy internal regional. Jika Anda telah mengonfigurasi beberapa proxy target yang mengarahkan traffic ke layanan backend yang sama, Google Cloud akan menggunakan beberapa pemeriksa untuk memeriksa alamat IP yang terkait dengan setiap proxy target. Frekuensi pemeriksaan per layanan backend dikalikan dengan jumlah proxy target yang dikonfigurasi.
Menjumlahkan seluruh layanan backend. Jika backend digunakan oleh beberapa layanan backend, instance backend akan dihubungi sesering jumlah frekuensi untuk setiap health check layanan backend.
Dengan backend NEG zonal, akan lebih sulit untuk menentukan jumlah tepat probe pemeriksaan kesehatan. Misalnya, endpoint yang sama dapat berada di beberapa NEG zonal. NEG zonal tersebut tidak harus memiliki kumpulan endpoint yang sama, dan endpoint yang berbeda dapat mengarah ke backend yang sama.
Tujuan untuk paket probe
Tabel berikut menunjukkan antarmuka jaringan dan alamat IP tujuan tempat penguji health check mengirim paket, bergantung pada jenis load balancer.
Untuk Load Balancer Jaringan passthrough eksternal dan Load Balancer Jaringan passthrough internal, aplikasi harus terikat dengan alamat IP load balancer (atau alamat IP 0.0.0.0 apa pun).
| Load balancer | Antarmuka jaringan tujuan | Alamat IP tujuan |
|---|---|---|
|
|
|
|
|
|
| Load Balancer Jaringan passthrough eksternal | Antarmuka jaringan utama (nic0) |
Alamat IP aturan penerusan eksternal. Jika beberapa aturan penerusan mengarah ke layanan backend yang sama (untuk Load Balancer Jaringan passthrough eksternal berbasis kumpulan target, kumpulan target yang sama), Google Cloud akan mengirimkan probe ke setiap alamat IP aturan penerusan. Hal ini dapat menyebabkan peningkatan jumlah probe. |
| Load Balancer Network passthrough internal | Untuk backend grup instance dan backend NEG zonal dengan
endpoint GCE_VM_IP, antarmuka jaringan yang digunakan bergantung pada
cara layanan backend dikonfigurasi. Untuk mengetahui detailnya, lihat
Layanan
backend dan antarmuka jaringan.
|
Alamat IP aturan penerusan internal. Jika beberapa aturan penerusan mengarah ke layanan backend yang sama, Google Cloud akan mengirim probe ke setiap alamat IP aturan penerusan. Hal ini dapat menyebabkan peningkatan jumlah probe. |
Kriteria keberhasilan untuk HTTP, HTTPS, dan HTTP/2
Health check HTTP, HTTPS, dan HTTP/2 selalu memerlukan kode respons 200 (OK) HTTP
untuk diterima sebelum waktu tunggu health check habis. Semua kode respons HTTP lainnya, termasuk kode respons pengalihan seperti 301 dan 302, dianggap tidak sehat.
Selain mewajibkan kode respons 200 (OK) HTTP, Anda dapat:
Konfigurasikan setiap pemeriksa kondisi untuk mengirim permintaan HTTP ke jalur permintaan tertentu, bukan jalur permintaan default,
/.Konfigurasikan setiap pemeriksa health check untuk memeriksa keberadaan string respons yang diharapkan dalam isi respons HTTP. String respons yang diharapkan hanya boleh berisi karakter ASCII satu byte yang dapat dicetak, yang terletak dalam 1.024 byte pertama isi respons HTTP.
Tabel berikut mencantumkan kombinasi yang valid dari jalur permintaan dan flag respons yang tersedia untuk health check HTTP, HTTPS, dan HTTP/2.
| Flag konfigurasi | Perilaku pemeriksa | Kriteria sukses |
|---|---|---|
--request-path atau --response
tidak ditentukan
|
Penguji menggunakan / sebagai jalur permintaan. |
Khusus kode respons 200 (OK) HTTP. |
--request-path dan --response ditentukan
|
Penguji menggunakan jalur permintaan yang dikonfigurasi. | Kode respons 200 (OK) HTTP dan hingga 1.024 karakter ASCII pertama dari isi respons HTTP harus cocok dengan string respons yang diharapkan. |
Hanya --response yang ditentukan
|
Penguji menggunakan / sebagai jalur permintaan. |
Kode respons 200 (OK) HTTP dan hingga 1.024 karakter ASCII pertama dari isi respons HTTP harus cocok dengan string respons yang diharapkan. |
Hanya --request-path yang ditentukan
|
Penguji menggunakan jalur permintaan yang dikonfigurasi. | Khusus kode respons 200 (OK) HTTP. |
Kriteria keberhasilan untuk SSL dan TCP
Health check TCP dan SSL memiliki kriteria keberhasilan dasar berikut:
Untuk health check TCP, pemeriksa health check harus berhasil membuka koneksi TCP ke backend sebelum waktu tunggu health check habis.
Untuk pemeriksaan kondisi SSL, pemeriksa pemeriksaan kondisi harus berhasil membuka koneksi TCP ke backend dan menyelesaikan TLS/SSL handshake sebelum pemeriksaan kondisi habis waktu tunggunya.
Untuk pemeriksaan kesehatan TCP, koneksi TCP harus ditutup dengan salah satu cara berikut:
- Dengan pengirim probe health check yang mengirimkan paket FIN atau RST (reset), atau
- Dengan backend yang mengirimkan paket FIN. Jika backend mengirim paket RST TCP, pemeriksaan mungkin dianggap tidak berhasil jika pemeriksa health check telah mengirim paket FIN.
Tabel berikut mencantumkan kombinasi flag permintaan dan respons yang valid yang tersedia untuk health check TCP dan SSL. Flag permintaan dan respons hanya boleh terdiri dari karakter ASCII satu byte yang dapat dicetak, dengan setiap string tidak lebih dari 1.024 karakter.
| Flag konfigurasi | Perilaku pemeriksa | Kriteria sukses |
|---|---|---|
--request atau --response tidak ditentukan
|
Penguji tidak mengirimkan string permintaan apa pun. | Khusus kriteria keberhasilan dasar. |
--request dan --response ditentukan
|
Penguji mengirimkan string permintaan yang dikonfigurasi. | Kriteria keberhasilan dasar dan string respons yang diterima oleh pemeriksa harus sama persis dengan string respons yang diharapkan. |
Hanya --response yang ditentukan
|
Penguji tidak mengirimkan string permintaan apa pun. | Kriteria keberhasilan dasar dan string respons yang diterima oleh pemeriksa harus sama persis dengan string respons yang diharapkan. |
Hanya --request yang ditentukan
|
Penguji mengirimkan string permintaan yang dikonfigurasi. | Hanya kriteria keberhasilan dasar (string respons apa pun tidak diperiksa). |
Kriteria keberhasilan untuk gRPC
Jika Anda menggunakan health check gRPC, pastikan layanan gRPC mengirim
respons RPC dengan status OK dan kolom status ditetapkan ke SERVING atau
NOT_SERVING.
Perhatikan hal berikut:
- Health check gRPC hanya digunakan dengan aplikasi gRPC dan Cloud Service Mesh.
- Health check gRPC tidak mendukung TLS.
Untuk informasi selengkapnya, lihat referensi berikut:
Kriteria keberhasilan untuk health check lama
Jika respons yang diterima oleh probe health check lama adalah HTTP 200 OK,
probe dianggap berhasil. Semua kode respons HTTP lainnya, termasuk
pengalihan (301, 302), dianggap tidak sehat.
Status kesehatan
Google Cloud menggunakan flag konfigurasi berikut untuk menentukan status kondisi keseluruhan setiap backend yang diimbangi traffic-nya.
| Flag konfigurasi | Tujuan | Nilai default |
|---|---|---|
Batas responsifhealthy-threshold |
Batas responsif menentukan jumlah hasil pemeriksaan berurutan yang berhasil agar backend dianggap responsif. | Batas 2 probe. |
Ambang batas tidak responsifunhealthy-threshold |
Nilai minimum tidak responsif menentukan jumlah hasil pemeriksaan berurutan yang gagal agar backend dianggap tidak responsif. | Batas 2 probe. |
Google Cloud menganggap backend responsif setelah nilai minimum responsif ini terpenuhi. Backend yang responsif memenuhi syarat untuk menerima koneksi baru.
Google Cloud menganggap backend tidak responsif saat nilai minimum tidak responsif telah terpenuhi. Backend yang tidak responsif tidak memenuhi syarat untuk menerima koneksi baru; tetapi, koneksi yang ada tidak langsung dihentikan. Sebagai gantinya, koneksi tetap terbuka hingga waktu tunggu habis atau hingga traffic dihentikan.
Koneksi yang ada mungkin gagal menampilkan respons, bergantung pada penyebab kegagalan pemeriksaan. Backend yang tidak responsif dapat menjadi responsif jika dapat memenuhi nilai minimum responsif lagi.
Perilaku spesifik saat semua backend tidak responsif berbeda-beda, bergantung pada jenis load balancer yang Anda gunakan:
| Load balancer | Perilaku saat semua backend tidak responsif |
|---|---|
| Load Balancer Aplikasi Klasik | Menampilkan kode status HTTP `502` kepada klien saat semua backend tidak responsif. |
|
Load Balancer Aplikasi eksternal global Load Balancer Aplikasi internal lintas region Load Balancer Aplikasi eksternal regional Load Balancer Aplikasi internal regional |
Menampilkan kode status HTTP `503` kepada klien saat semua backend tidak responsif. |
| Load Balancer Jaringan Proxy | Mengakhiri koneksi klien saat semua backend tidak responsif. |
| Load Balancer Jaringan passthrough internal Load Balancer Jaringan passthrough eksternal berbasis layanan backend |
Mendistribusikan traffic ke semua VM backend sebagai upaya terakhir jika semua backend tidak responsif dan failover tidak dikonfigurasi. Untuk informasi selengkapnya tentang perilaku ini, lihat Distribusi traffic untuk Load Balancer Jaringan passthrough internal dan Distribusi traffic untuk Load Balancer Jaringan passthrough eksternal berbasis layanan backend. |
| Load Balancer Jaringan passthrough eksternal berbasis kumpulan target | Mendistribusikan traffic ke semua VM backend sebagai upaya terakhir saat semua backend tidak responsif. |
Catatan tambahan
Bagian berikut menyertakan beberapa catatan lainnya tentang penggunaan pemeriksaan kesehatan di Google Cloud.
Sertifikat dan health check
Penguji health check Google Cloud tidak melakukan validasi sertifikat, bahkan untuk protokol yang mewajibkan backend Anda menggunakan sertifikat (SSL, HTTPS, dan HTTP/2)—misalnya:
- Anda dapat menggunakan sertifikat yang ditandatangani sendiri atau sertifikat yang ditandatangani oleh certificate authority (CA) mana pun.
- Sertifikat yang sudah tidak berlaku atau belum valid dapat diterima.
- Atribut
CNmaupunsubjectAlternativeNametidak perlu cocok dengan headerHostatau data PTR DNS.
Header
Health check yang menggunakan protokol apa pun, tetapi bukan health check lama, memungkinkan Anda menetapkan header proxy menggunakan tanda --proxy-header.
Health check yang menggunakan protokol HTTP, HTTPS, atau HTTP/2 dan health check
lama memungkinkan Anda menentukan header Host HTTP menggunakan flag --host.
Jika Anda menggunakan header permintaan kustom, perhatikan bahwa load balancer hanya menambahkan header ini ke permintaan klien, bukan ke pemeriksaan kondisi. Jika backend Anda memerlukan header tertentu untuk otorisasi yang tidak ada dalam paket health check, health check mungkin akan gagal.
Contoh health check
Misalkan Anda menyiapkan health check dengan setelan berikut:
- Interval: 30 detik
- Waktu tunggu: 5 detik
- Protokol: HTTP
- Unhealthy threshold: 2 (default)
- Batas responsif: 2 (default)
Dengan setelan ini, health check akan berperilaku sebagai berikut:
- Beberapa sistem redundan dikonfigurasi secara bersamaan dengan parameter health check. Setelan interval dan waktu tunggu diterapkan ke setiap sistem. Untuk informasi selengkapnya, lihat Beberapa pemeriksaan dan frekuensi.
Setiap penguji health check melakukan hal berikut:
- Memulai koneksi HTTP dari salah satu alamat IP sumber ke instance backend setiap 30 detik.
- Menunggu hingga lima detik untuk kode status
200 (OK)HTTP (kriteria keberhasilan untuk protokol HTTP, HTTPS, dan HTTP/2).
Backend dianggap tidak responsif jika setidaknya satu sistem probe health check melakukan hal berikut:
- Tidak menerima kode respons
HTTP 200 (OK)untuk dua pemeriksaan berturut-turut. Misalnya, koneksi mungkin ditolak, atau mungkin ada waktu tunggu koneksi atau soket habis. - Menerima dua respons berturut-turut yang tidak cocok dengan kriteria keberhasilan khusus protokol.
- Tidak menerima kode respons
Backend dianggap responsif jika setidaknya satu sistem probe health check menerima dua respons berturut-turut yang cocok dengan kriteria keberhasilan khusus protokol.
Dalam contoh ini, setiap pemeriksa memulai koneksi setiap 30 detik. Tiga puluh detik berlalu di antara upaya koneksi pemeriksa, terlepas dari durasi waktu tunggu (baik koneksi habis waktu tunggu maupun tidak). Dengan kata lain, waktu tunggu harus selalu kurang dari atau sama dengan interval, dan waktu tunggu tidak pernah meningkatkan interval.
Dalam contoh ini, pengaturan waktu setiap pemeriksa terlihat seperti berikut, dalam detik:
- t=0: Mulai probe A.
- t=5: Hentikan probe A.
- t=30: Mulai probe B.
- t=35: Hentikan probe B.
- t=60: Mulai probe C.
- t=65: Hentikan probe C.
Langkah selanjutnya
- Untuk membuat, mengubah, dan menggunakan health check, lihat Menggunakan health check.
- Untuk memecahkan masalah health check, aktifkan logging health check.