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.

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.

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.

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:

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

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.

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.

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.

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:

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.