Ringkasan health check

Google Cloud menawarkan health check yang dapat dikonfigurasi untuk backend load balancer Google Cloud, backend Traffic Director, dan autohealing berbasis aplikasi untuk grup instance terkelola. Dokumen ini membahas konsep-konsep kesehatan utama.

Kecuali jika dinyatakan lain, health check Google Cloud diterapkan oleh tugas software khusus yang terhubung ke backend berdasarkan parameter yang ditentukan dalam resource health check. Setiap upaya koneksi disebut pemeriksaan. Google Cloud mencatat keberhasilan atau kegagalan setiap pemeriksaan.

Berdasarkan jumlah pemeriksaan yang berhasil atau gagal secara berurutan, status kesehatan keseluruhan dihitung untuk setiap backend. Backend yang berhasil merespons selama frekuensi yang dikonfigurasi dianggap sehat. Backend yang berhasil merespons selama beberapa kali yang dapat dikonfigurasi secara terpisah dianggap tidak sehat.

Status respons keseluruhan setiap backend menentukan kelayakan untuk menerima permintaan atau koneksi baru. Anda dapat mengonfigurasi kriteria yang menentukan pemeriksaan 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 ditetapkan di jaringan Virtual Private Cloud (VPC) Anda. Untuk mengetahui informasi selengkapnya, lihat Jalur yang ditampilkan load balancer.

Kategori, protokol, dan port health check

Health check memiliki kategori dan protokol. Dua kategori tersebut adalah health check dan health check lama, dan protokol yang didukungnya adalah sebagai berikut:

• Health check

  • Global (gRPC, TCP, SSL, HTTP, HTTPS, atau HTTP/2)
  • Regional (gRPC, TCP, SSL, HTTP, HTTPS, atau HTTP/2)

• Health check lama:

  • Global lama (HTTP)
  • Global lama (HTTPS)

Protokol dan port menentukan cara pemeriksaan health check dilakukan. Misalnya, health check dapat menggunakan protokol HTTP di TCP port 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.

Catatan: Istilah health check tidak mengacu pada health check lama. Dalam dokumen ini, health check lama secara eksplisit disebut health check lama. Perhatikan juga bahwa dokumen ini menggunakan istilah grup instance untuk merujuk pada grup instance tidak terkelola, grup instance terkelola menurut zona, dan grup instance terkelola regional.

Pilih health check

Health check harus kompatibel dengan jenis load balancer (atau Traffic Director) dan jenis backend. Faktor-faktor yang perlu dipertimbangkan saat Anda memilih health check 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 health check secara rutin.
• Protocol: yang digunakan Google Cloud untuk memeriksa 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 Anda. Health check memiliki dua metode spesifikasi port: --port dan --use-serving-port. Untuk health check lama, ada satu metode: --port.

Bagian berikutnya menjelaskan pilihan health check yang valid untuk setiap jenis load balancer dan backend.

Panduan load balancer

Tabel ini menampilkan kategori, cakupan, dan spesifikasi port yang didukung untuk setiap load balancer dan jenis backend.

Load balancer	Backend type	Kategori dan cakupan health check	Spesifikasi port
Load Balancer Aplikasi eksternal global Load Balancer Aplikasi Klasik ^1 Load Balancer Jaringan proxy eksternal global Load Balancer Jaringan proxy klasik	NEG yang Didukung	Health check (global)	Nomor port khusus (--port) Nomor port endpoint (--use-serving-port)
	Grup instance	Health check (global)	Nomor port khusus (--port) Port bernama untuk layanan backend (--use-serving-port)
Load Balancer Aplikasi eksternal regional	NEG yang Didukung	Health check (regional)	Nomor port khusus (--port) Nomor port endpoint (--use-serving-port)
	Grup instance	Health check (regional)	Nomor port khusus (--port) Port bernama untuk layanan backend (--use-serving-port)
Load Balancer Aplikasi internal lintas region Load Balancer Jaringan proxy internal lintas region	NEG yang Didukung	Health check (global)	Nomor port khusus (--port) Nomor port endpoint (--use-serving-port)
	Grup instance	Health check (global)	Nomor port khusus (--port) Port bernama untuk layanan backend (--use-serving-port)
Load Balancer Aplikasi internal regional Load Balancer Jaringan proxy internal regional Load Balancer Jaringan proxy eksternal regional	NEG yang Didukung	Health check (regional)	Nomor port khusus (--port) Nomor port endpoint (--use-serving-port)
	Grup instance	Health check (regional)	Nomor port khusus (--port) Port bernama untuk layanan backend (--use-serving-port)
Load Balancer Jaringan passthrough eksternal ^2	Grup instance	Health check (regional)	Nomor port khusus (--port)
	Instance dalam kumpulan target	Health check lama (global dengan protokol HTTP)	Health check lama hanya mendukung spesifikasi nomor port (--port).
Load Balancer Jaringan passthrough internal ^2	NEG yang Didukung	Health check (global atau regional)	Nomor port khusus (--port)
	Grup instance	Health check (global atau regional)	Nomor port khusus (--port)

¹ Untuk Load Balancer Aplikasi eksternal, health check lama tidak direkomendasikan, tetapi terkadang didukung, bergantung pada mode load balancer.

Mode load balancer	Health check lama yang didukung
Load Balancer Aplikasi eksternal global Load Balancer Aplikasi Klasik	Ya, jika kedua hal berikut berlaku: Backend adalah grup instance. VM backend menyalurkan traffic yang menggunakan protokol HTTP atau HTTPS.
Load Balancer Aplikasi eksternal regional	Tidak

² Anda tidak dapat menggunakan flag --use-serving-port karena layanan backend yang digunakan dengan Load Balancer Jaringan passthrough internal dan Load Balancer Jaringan passthrough eksternal tidak berlangganan ke port bernama mana pun. Selain itu, Load Balancer Jaringan passthrough internal hanya mendukung NEG zona dengan endpoint GCE_VM_IP, yang tidak memiliki informasi port.

Catatan penggunaan tambahan

• Untuk Load Balancer Jaringan passthrough internal, Anda hanya dapat menggunakan TCP atau UDP untuk protokol layanan backend. Jika Anda menyalurkan traffic HTTP dari VM di belakang Load Balancer Jaringan 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 tidak dapat menggunakan health check HTTPS lama atau health check non-legacy apa pun. Jika Anda menggunakan Load Balancer Jaringan passthrough eksternal berbasis kumpulan target untuk menyeimbangkan traffic TCP, Anda perlu menjalankan layanan HTTP pada VM yang sedang di-load balanced agar dapat merespons pemeriksaan health check.
  
  Untuk hampir semua jenis load balancer lainnya, Anda harus menggunakan health check reguler non-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 hybrid tidak mendukung health check gRPC. Untuk mengetahui informasi selengkapnya, lihat ringkasan NEG Hybrid.

Health check dengan Traffic Director

Perhatikan perbedaan perilaku berikut saat Anda menggunakan health check dengan Traffic Director.

• Dengan Traffic Director, perilaku health check untuk endpoint jaringan dari jenis INTERNET_FQDN_PORT dan NON_GCP_PRIVATE_IP_PORT berbeda dengan perilaku health check untuk jenis endpoint jaringan lainnya. Daripada menggunakan tugas software khusus, Traffic Director memprogram proxy Envoy untuk melakukan health check untuk NEG internet (endpoint INTERNET_FQDN_PORT) dan NEG hybrid (endpoint NON_GCP_PRIVATE_IP_PORT).

  Envoy mendukung protokol berikut untuk health check:

  • HTTP
  • HTTPS
  • HTTP/2
  • TCP

• Jika Traffic Director terintegrasi dengan Direktori Layanan dan Anda mengikat layanan Direktori Layanan ke layanan backend Traffic Director, Anda tidak dapat menetapkan health check pada layanan backend.

Cara kerja health check

Bagian berikut menjelaskan cara kerja health check.

Termometer Masak

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 pemeriksaan. Flag ini mengontrol seberapa sering setiap pemeriksaan mengevaluasi instance dalam grup instance atau endpoint di NEG zona.

Setelan health check tidak dapat dikonfigurasi per backend. Health check dikaitkan dengan seluruh layanan backend. Untuk Load Balancer Jaringan passthrough eksternal berbasis kumpulan target, health check HTTP lama akan dikaitkan dengan seluruh kumpulan target. Dengan demikian, parameter untuk pemeriksaan tersebut sama untuk semua backend yang dirujuk oleh layanan backend atau kumpulan target tertentu.

Tanda konfigurasi	Tujuan	Nilai default
Interval pemeriksaan check-interval	Interval pemeriksaan adalah jumlah waktu dari awal satu pemeriksaan yang dikeluarkan oleh seorang peneliti hingga dimulainya pemeriksaan berikutnya yang dikeluarkan oleh petugas pemeriksaan yang sama. Unit dalam hitungan detik.	5s (5 detik)
Waktu tunggu timeout	Waktu tunggu adalah jumlah waktu yang dihabiskan 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 profesional Google Cloud dapat terhubung ke backend Anda.

Tabel berikut menunjukkan rentang IP sumber yang akan diizinkan:

Produk	Rentang IP sumber penyelidikan	Contoh aturan firewall
Load Balancer Aplikasi eksternal global Load Balancer Aplikasi Klasik Load Balancer Aplikasi eksternal regional ^1, 2 Load Balancer Aplikasi internal lintas region ^1 Load Balancer Aplikasi internal regional ^1, 2 Load Balancer Jaringan passthrough internal Load Balancer Jaringan proxy eksternal Load Balancer Jaringan proxy internal regional^1, 2 Load Balancer Jaringan proxy internal lintas region ^1 Load Balancer Jaringan proxy eksternal regional^1, 2 Traffic Director, kecuali untuk backend NEG internet dan backend NEG hybrid	35.191.0.0/16 130.211.0.0/22	Aturan firewall untuk semua produk kecuali Load Balancer Jaringan passthrough eksternal
Load Balancer Jaringan passthrough eksternal	Untuk traffic IPv4 ke backend: 35.191.0.0/16 209.85.152.0/22 209.85.204.0/22 Untuk traffic IPv6 ke backend: 2600:1901:8001::/48 ^3	Aturan firewall untuk Load Balancer Jaringan passthrough eksternal
Load Balancer Jaringan passthrough internal	Untuk traffic IPv4 ke backend: 35.191.0.0/16 130.211.0.0/22 Untuk traffic IPv6 ke backend: 2600:2d00:1:b029::/64	Aturan firewall untuk Load Balancer Jaringan passthrough internal
Traffic Director dengan backend NEG internet dan backend NEG hybrid	Alamat IP VM yang menjalankan software Envoy	Contoh aturan firewall

¹ Pemberian rentang rentang pemeriksaan health check Google yang diizinkan tidak diperlukan untuk NEG hybrid. Namun, jika menggunakan kombinasi NEG campuran dan zona dalam satu layanan backend, Anda harus mengizinkan rentang pemeriksaan health check Google untuk NEG zona.

² Untuk NEG internet regional, health check bersifat opsional. Traffic dari load balancer yang menggunakan NEG internet regional berasal dari subnet khusus proxy dan kemudian 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: Gunakan Cloud NAT untuk keluar.

³ Load Balancer Jaringan passthrough eksternal berbasis kumpulan target hanya mendukung traffic IPv4 dan dapat melakukan health check melalui proxy 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 mewajibkan Anda membuat aturan firewall allow masuk yang diperlukan untuk mengizinkan traffic dari prober ke backend Anda. Sebagai praktik terbaik, batasi aturan ini hanya untuk protokol dan port yang sesuai dengan yang digunakan oleh health check Anda. Untuk rentang IP sumber, pastikan untuk menggunakan rentang IP pemeriksaan yang didokumentasikan yang tercantum di bagian sebelumnya.

Jika Anda tidak memiliki aturan firewall allow masuk yang mengizinkan health check, aturan deny tersirat akan memblokir traffic masuk. Jika pengguna tidak dapat menghubungi backend Anda, load balancer menganggap backend Anda tidak responsif.

Pertimbangan keamanan untuk pemeriksaan rentang IP

Pertimbangkan informasi berikut saat merencanakan health check dan aturan firewall yang diperlukan:

• Rentang IP pemeriksaan adalah milik Google. Google Cloud menggunakan rute khusus di luar jaringan VPC Anda, tetapi di dalam jaringan produksi Google untuk memfasilitasi komunikasi dari prober.

• Google menggunakan rentang IP pemeriksaan untuk mengirim pemeriksaan 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 pemeriksaan, Google akan menghapus paket tersebut. Hal ini mencakup alamat IP eksternal instance Compute Engine atau node Google Kubernetes Engine (GKE).

• Rentang IP pemeriksaan adalah kumpulan lengkap alamat IP yang mungkin digunakan oleh engineer Google Cloud. Jika menggunakan tcpdump atau alat serupa, Anda mungkin tidak mengamati traffic dari semua alamat IP di semua rentang IP pemeriksaan. Sebagai praktik terbaik, buat aturan firewall masuk yang mengizinkan semua rentang IP pemeriksaan sebagai sumber. Google Cloud dapat menerapkan prober baru secara otomatis tanpa notifikasi.

Beberapa pemeriksaan dan frekuensi

Google Cloud mengirimkan pemeriksaan health check dari beberapa sistem redundan yang disebut prober. Pakar menggunakan rentang IP sumber tertentu. Google Cloud tidak hanya mengandalkan satu penguji untuk menerapkan health check. Beberapa engineer mengevaluasi instance di backend grup instance atau endpoint di backend NEG zona secara bersamaan. Jika satu penguji gagal, Google Cloud akan terus melacak status respons backend.

Setelan interval dan waktu tunggu yang Anda konfigurasi untuk health check diterapkan ke setiap pemeriksaan. Untuk backend tertentu, log akses software dan tcpdump menampilkan pemeriksaan yang lebih sering daripada setelan yang dikonfigurasi.

Hal ini normal terjadi, dan Anda tidak dapat mengonfigurasi jumlah akun yang digunakan Google Cloud untuk health check. Namun, Anda dapat memperkirakan efek dari beberapa pemeriksaan simultan 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:

    ¹⁄_{(interval pemeriksaan)}

    Saat mengaitkan health check dengan layanan backend, Anda akan menetapkan frekuensi dasar yang digunakan oleh setiap prober untuk backend pada layanan backend tersebut.

  • Menyelidiki faktor skala. Frekuensi dasar layanan backend dikalikan dengan jumlah prober simultan 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 berbeda) yang mengarah ke layanan backend internal regional yang sama, Google Cloud akan menggunakan beberapa prober untuk memeriksa setiap alamat IP. Frekuensi pemeriksaan 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 prober 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 prober untuk memeriksa alamat IP yang terkait dengan setiap proxy target. Frekuensi pemeriksaan per layanan backend dikalikan dengan jumlah proxy target yang dikonfigurasi.

• Jumlah di atas 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 zona, menentukan jumlah pasti pemeriksaan health check menjadi lebih sulit. Misalnya, endpoint yang sama dapat berada di beberapa NEG zona. NEG zona tersebut tidak harus memiliki kumpulan endpoint yang sama, dan endpoint yang berbeda dapat mengarah ke backend yang sama.

Tujuan untuk paket pemeriksaan

Tabel berikut menunjukkan antarmuka jaringan dan alamat IP tujuan yang menjadi tujuan pengiriman paket health check, bergantung pada jenis load balancer.

Untuk Load Balancer Jaringan passthrough eksternal dan Load Balancer Jaringan passthrough internal, aplikasi harus terikat ke alamat IP load balancer (atau alamat IP 0.0.0.0).

Load balancer	Antarmuka jaringan tujuan	Alamat IP tujuan
Load Balancer Aplikasi eksternal global Load Balancer Aplikasi Klasik Load Balancer Aplikasi eksternal regional Load Balancer Aplikasi internal lintas region Load Balancer Aplikasi internal Load Balancer Jaringan proxy eksternal global Load Balancer Jaringan proxy klasik Load Balancer Jaringan proxy internal regional Load Balancer Jaringan proxy internal lintas region Traffic Director	Untuk backend grup instance, antarmuka jaringan utama (nic0). Untuk backend NEG zona dengan endpoint GCE_VM_IP_PORT, antarmuka jaringan di jaringan VPC yang terkait dengan NEG. Untuk backend NEG zona dengan endpoint NON_GCP_PRIVATE_IP_PORT, endpoint harus merepresentasikan antarmuka resource lokal yang dapat dijangkau melalui rute di jaringan VPC yang terkait dengan NEG dan di region yang berisi NEG.	Untuk backend grup instance, alamat IPv4 internal utama yang terkait dengan antarmuka jaringan utama (nic0) dari setiap instance. Untuk backend NEG zona dengan endpoint GCE_VM_IP_PORT, alamat IP endpoint: alamat IPv4 internal utama antarmuka jaringan atau alamat IPv4 internal dari rentang IP alias antarmuka jaringan. Untuk backend NEG zona dengan endpoint NON_GCP_PRIVATE_IP_PORT, alamat IP endpoint.
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 pemeriksaan ke setiap alamat IP aturan penerusan. Hal ini dapat mengakibatkan peningkatan jumlah pemeriksaan.
Load Balancer Jaringan passthrough internal	Untuk backend grup instance dan backend NEG zona 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 mengirimkan pemeriksaan ke setiap alamat IP aturan penerusan. Hal ini dapat mengakibatkan peningkatan jumlah pemeriksaan.

Kriteria keberhasilan untuk HTTP, HTTPS, dan HTTP/2

Jika health check menggunakan protokol HTTP, HTTPS, atau HTTP/2, setiap pemeriksaan memerlukan kode status 200 (OK) HTTP untuk dikirimkan sebelum waktu tunggu pemeriksaan. Selain itu, Anda dapat melakukan hal berikut:

• Anda dapat mengonfigurasi prober Google Cloud untuk mengirim permintaan HTTP ke jalur permintaan tertentu. Jika Anda tidak menentukan jalur permintaan, / akan digunakan.

• Jika Anda mengonfigurasi health check berbasis konten dengan menentukan string respons yang diharapkan, Google Cloud harus menemukan string yang diharapkan dalam 1.024 byte pertama isi respons HTTP.

Kombinasi jalur permintaan dan tanda string respons berikut tersedia untuk health check yang menggunakan protokol HTTP, HTTPS, dan HTTP/2.

Tanda konfigurasi	Kriteria kesuksesan
Jalur permintaan request-path	Tentukan jalur URL tujuan pengiriman permintaan pemeriksaan health check oleh Google Cloud. Jika dihilangkan, Google Cloud akan mengirimkan permintaan pemeriksaan ke jalur root, /.
Respons response	Tanda respons opsional memungkinkan Anda mengonfigurasi health check berbasis konten. String respons yang diharapkan harus kurang dari atau sama dengan 1.024 karakter ASCII (byte tunggal). Jika dikonfigurasi, Google Cloud mengharapkan string ini dalam 1.024 byte pertama respons selain menerima kode status 200 (OK) HTTP.

Kriteria keberhasilan untuk SSL dan TCP

Kecuali Anda menentukan string respons yang diharapkan, pemeriksaan untuk health check yang menggunakan protokol SSL dan TCP akan berhasil jika kedua kondisi dasar berikut terpenuhi:

• Setiap penguji Google Cloud dapat menyelesaikan handshake SSL atau TCP sebelum waktu tunggu pemeriksaan yang dikonfigurasi habis.
• Untuk health check TCP, sesi TCP dihentikan secara halus dengan:
  • Backend, atau
  • Klien Google Cloud yang mengirim paket TCP RST (reset) saat sesi TCP ke prober masih dilakukan

Jika backend mengirim paket TCP RST (reset) guna menutup sesi TCP untuk health check TCP, pemeriksaan mungkin dianggap gagal. Hal ini terjadi saat penyedia Google Cloud telah memulai penghentian TCP halus.

Anda dapat membuat health check berbasis konten jika Anda memberikan string permintaan dan string respons yang diharapkan, masing-masing hingga 1.024 karakter ASCII (byte tunggal). Saat string respons yang diharapkan dikonfigurasi, Google Cloud akan menganggap pemeriksaan berhasil hanya jika kondisi dasar terpenuhi dan string respons yang ditampilkan sama persis dengan string respons yang diharapkan.

Kombinasi tanda permintaan dan respons berikut tersedia untuk health check yang menggunakan protokol SSL dan TCP.

Tanda konfigurasi	Kriteria kesuksesan
Tidak ada permintaan atau respons yang ditentukan Tidak ada tanda yang ditentukan: --request, --response	Google Cloud menganggap pemeriksaan berhasil jika kondisi dasar terpenuhi.
Permintaan dan respons ditentukan Kedua tanda yang ditentukan: --request, --response	Google Cloud mengirimkan string permintaan yang dikonfigurasi dan menunggu string respons yang diharapkan. Google Cloud menganggap pemeriksaan berhasil jika kondisi dasar terpenuhi dan string respons yang ditampilkan sama persis dengan string respons yang diharapkan.
Hanya respons yang ditentukan Tanda yang ditentukan: hanya --response	Google Cloud menunggu string respons yang diharapkan, dan menganggap pemeriksaan berhasil saat kondisi dasar terpenuhi dan string respons yang ditampilkan sama persis dengan string respons yang diharapkan. Anda hanya boleh menggunakan --response jika backend Anda akan otomatis mengirim string respons sebagai bagian dari handshake TCP atau SSL.
Hanya permintaan yang ditentukan Tanda yang ditentukan: hanya --request	Google Cloud akan mengirimkan string permintaan yang dikonfigurasi dan menganggap pemeriksaan berhasil saat kondisi dasar terpenuhi. Respons, jika ada, tidak diperiksa.

Kriteria keberhasilan untuk gRPC

Jika Anda menggunakan health check gRPC, pastikan layanan gRPC mengirimkan respons RPC dengan status OK dan kolom status yang ditetapkan ke SERVING atau NOT_SERVING sebagaimana mestinya.

Perhatikan hal-hal berikut:

• Health check gRPC hanya digunakan dengan aplikasi gRPC dan Traffic Director.
• Health check gRPC tidak mendukung TLS.

Untuk informasi selengkapnya, lihat referensi berikut:

• Flag tambahan untuk health check gRPC
• Dokumentasi gRPC untuk health check

Kriteria keberhasilan untuk health check lama

Jika respons yang diterima oleh pemeriksaan health check lama adalah HTTP 200 OK, pemeriksaan akan dianggap berhasil. Semua kode respons HTTP lainnya, termasuk pengalihan (301, 302), dianggap tidak responsif.

Status kesehatan

Google Cloud menggunakan flag konfigurasi berikut untuk menentukan status kesehatan keseluruhan dari setiap backend yang menjadi tujuan load balancing.

Tanda konfigurasi	Tujuan	Nilai default
Ambang batas responsif healthy-threshold	Ambang batas responsif menentukan jumlah hasil pemeriksaan yang berhasil dan berurutan agar backend dianggap responsif.	Nilai minimum 2 pemeriksaan.
Ambang batas tidak responsif unhealthy-threshold	Ambang batas yang tidak responsif menentukan jumlah hasil pemeriksaan yang gagal secara berurutan agar backend dianggap tidak responsif.	Nilai minimum 2 pemeriksaan.

Google Cloud menganggap backend sehat setelah batas yang responsif ini telah terpenuhi. Backend yang responsif memenuhi syarat untuk menerima koneksi baru.

Google Cloud menganggap backend tidak responsif jika batas tidak responsif telah terpenuhi. Backend yang tidak responsif tidak memenuhi syarat untuk menerima koneksi baru. Namun, koneksi yang ada tidak langsung dihentikan. Sebaliknya, koneksi tetap terbuka hingga waktu tunggu habis atau hingga traffic berhenti.

Koneksi yang ada mungkin gagal menampilkan respons, bergantung pada penyebab kegagalan pemeriksaan. Backend yang tidak responsif dapat menjadi responsif jika dapat kembali memenuhi batas responsif.

Perilaku tertentu 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` ke klien saat semua backend tidak responsif.
Load Balancer Aplikasi eksternal global Load Balancer Aplikasi eksternal regional Load Balancer Aplikasi Internal	Menampilkan kode status HTTP `503` ke klien saat semua backend tidak responsif.
Load Balancer Jaringan Proxy	Hentikan koneksi klien saat semua backend tidak responsif.
Load Balancer Jaringan passthrough internal dan Load Balancer Jaringan passthrough eksternal berbasis layanan backend	Distribusikan traffic ke semua VM backend sebagai upaya terakhir saat semua backend tidak responsif dan failover tidak dikonfigurasi. Untuk mengetahui 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	Distribusikan traffic ke semua VM backend sebagai upaya terakhir saat semua backend tidak responsif.

Catatan tambahan

Bagian berikut mencakup beberapa catatan lain tentang penggunaan health check di Google Cloud.

Health check berbasis konten

Health check berbasis konten adalah yang kriteria keberhasilannya bergantung pada evaluasi string respons yang diharapkan. Gunakan health check berbasis konten untuk menginstruksikan pemeriksaan health check Google Cloud agar memvalidasi respons backend Anda lebih lengkap.

• Anda mengonfigurasi health check berbasis konten HTTP, HTTPS, atau HTTP/2 dengan menentukan string respons yang diharapkan, dan secara opsional dengan menentukan jalur permintaan. Untuk mengetahui detail selengkapnya, lihat Kriteria keberhasilan untuk HTTP, HTTPS, dan HTTP/2.

• Anda mengonfigurasi health check berbasis konten SSL atau TCP dengan menentukan string respons yang diharapkan, dan secara opsional dengan menentukan string permintaan. Untuk mengetahui detail selengkapnya, lihat Kriteria keberhasilan untuk SSL dan TCP.

Sertifikat dan health check

Pakar health check Google Cloud tidak melakukan validasi sertifikat, bahkan untuk protokol yang mengharuskan backend Anda menggunakan sertifikat (SSL, HTTPS, dan HTTP/2)—misalnya:

• Anda dapat menggunakan sertifikat yang ditandatangani sendiri atau sertifikat yang ditandatangani oleh otoritas sertifikat (CA) apa pun.
• Sertifikat yang telah kedaluwarsa atau belum valid dapat diterima.
• Baik atribut CN maupun subjectAlternativeName tidak harus cocok dengan header Host atau data PTR DNS.

Header

Health check yang menggunakan protokol apa pun, tetapi bukan health check lama, memungkinkan Anda menetapkan header proxy dengan menggunakan flag --proxy-header.

Health check yang menggunakan protokol HTTP, HTTPS, atau HTTP/2 serta health check lama memungkinkan Anda menentukan header Host HTTP dengan menggunakan tanda --host.

Contoh health check

Misalkan Anda menyiapkan health check dengan setelan berikut:

• Interval: 30 detik
• Waktu tunggu: 5 detik
• Protokol: HTTP
• Ambang batas tidak responsif: 2 (default)
• Ambang batas responsif: 2 (default)

Dengan setelan ini, health check berperilaku sebagai berikut:

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

2. Setiap pemeriksaan kesehatan melakukan hal berikut:

   1. Memulai koneksi HTTP dari salah satu alamat IP sumber ke instance backend setiap 30 detik.
   2. Menunggu hingga lima detik untuk kode status 200 (OK) HTTP (kriteria keberhasilan untuk protokol HTTP, HTTPS, dan HTTP/2).

3. Backend dianggap tidak responsif jika setidaknya satu sistem pemeriksaan health check melakukan hal berikut:

   1. Tidak menerima kode respons HTTP 200 (OK) untuk dua pemeriksaan berturut-turut. Misalnya, koneksi mungkin ditolak, atau mungkin terjadi waktu tunggu koneksi atau soket.
   2. Menerima dua respons berturut-turut yang tidak cocok dengan kriteria keberhasilan khusus protokol.

4. Backend dianggap responsif jika setidaknya satu sistem pemeriksaan health check menerima dua respons berturut-turut yang cocok dengan kriteria keberhasilan khusus protokol.

Dalam contoh ini, setiap prober memulai koneksi setiap 30 detik. Tiga puluh detik berlalu antara upaya koneksi prober, terlepas dari durasi waktu tunggu (apakah waktu koneksi habis atau tidak). Dengan kata lain, waktu tunggu harus selalu kurang dari atau sama dengan interval, dan waktu tunggu tidak boleh menambah interval.

Dalam contoh ini, pengaturan waktu setiap prober terlihat seperti berikut, dalam detik:

1. t=0: Memulai pemeriksaan A.
2. t=5: Hentikan probe A.
3. t=30: Mulai pemeriksaan B.
4. t=35: Hentikan pemeriksaan B.
5. t=60: Mulai pemeriksaan C.
6. t=65: Hentikan pemeriksaan C.

Langkah selanjutnya

• Untuk membuat, mengubah, dan menggunakan health check, lihat Menggunakan health check.
• Untuk memecahkan masalah health check, aktifkan logging health check.