CLB menggunakan pemeriksaan kesehatan untuk menentukan ketersediaan server backend. Ketika pemeriksaan kesehatan diaktifkan, CLB akan mendistribusikan permintaan ke server backend lain yang sehat jika suatu server backend menjadi tidak sehat. Setelah server tersebut pulih, CLB melanjutkan pengiriman lalu lintas kepadanya. Mekanisme ini meningkatkan ketersediaan layanan dengan mencegah gangguan akibat kegagalan server individual.
Jika beban kerja Anda sensitif terhadap beban, pemeriksaan kesehatan yang sering dapat memengaruhi akses layanan normal. Sesuai kebutuhan bisnis Anda, Anda dapat mengurangi dampaknya dengan menurunkan frekuensi pemeriksaan kesehatan, memperpanjang interval pemeriksaan kesehatan, atau beralih dari pemeriksaan Lapisan 7 ke Lapisan 4. Namun, untuk memastikan ketersediaan layanan secara berkelanjutan, kami tidak merekomendasikan menonaktifkan pemeriksaan kesehatan.
Cara kerja pemeriksaan kesehatan
Pemeriksaan kesehatan mengonfirmasi status server dengan mengirim permintaan pada interval reguler.
CLB dideploy dalam kluster. Node-nya menangani baik penerusan data maupun pemeriksaan kesehatan. Jika server backend gagal dalam pemeriksaan kesehatan, CLB berhenti mendistribusikan permintaan klien baru kepadanya.
Pemeriksaan kesehatan CLB menggunakan blok CIDR 100.64.0.0/10. Pastikan server backend Anda tidak memblokir blok CIDR ini. Anda tidak perlu menambahkan aturan izin ke security group Anda untuk blok CIDR ini. Namun, jika Anda telah mengonfigurasi kebijakan keamanan lain, seperti iptables, Anda harus mengizinkan lalu lintas dari 100.64.0.0/10. Ini adalah blok CIDR yang dicadangkan untuk Alibaba Cloud dan tidak menimbulkan risiko keamanan.
Pemeriksaan kesehatan listener HTTP/HTTPS
Pendengar Lapisan 7 (HTTP/HTTPS) melakukan pemeriksaan kesehatan dengan menggunakan permintaan HEAD atau GET.
Untuk listener HTTPS, sertifikat dikelola oleh CLB. CLB dan server backend bertukar data melalui HTTP untuk meningkatkan performa.
Proses pemeriksaan kesehatan untuk listener Lapisan 7 adalah sebagai berikut:
Sebuah node mengirim permintaan HTTP HEAD ke server backend berdasarkan konfigurasi listener.
Server backend mengembalikan kode status HTTP.
Jika tidak ada tanggapan yang diterima dalam batas waktu respons, pemeriksaan kesehatan gagal.
Jika tanggapan diterima dalam batas waktu respons, CLB membandingkan kode status tanggapan tersebut dengan kode status sehat yang dikonfigurasi. Jika kode statusnya cocok, pemeriksaan berhasil. Jika tidak, pemeriksaan gagal.
Secara default, pemeriksaan kesehatan CLB hanya menganggap kode status HTTP 2xx dan 3xx sebagai sehat. Jika server backend mengembalikan kode status 4xx (seperti 400, 403, 404, atau 429) atau kode status 5xx (seperti 500, 502, atau 503), pemeriksaan kesehatan gagal.
Kami merekomendasikan membuat titik akhir pemeriksaan kesehatan khusus, seperti /health, yang mengembalikan kode status HTTP 200, daripada menambahkan kode 4xx atau 5xx ke daftar kode status sehat.
Pemeriksaan kesehatan listener TCP
Untuk meningkatkan efisiensi pemeriksaan kesehatan pada listener TCP Lapisan 4, pemeriksaan kesehatan menggunakan probe TCP kustom untuk memperoleh informasi status, seperti yang ditunjukkan pada gambar berikut.
Proses pemeriksaan kesehatan untuk listener TCP adalah sebagai berikut:
Sebuah node dalam kluster Lapisan 4 mengirim paket TCP SYN ke alamat IP internal dan port pemeriksaan kesehatan server backend berdasarkan konfigurasi pemeriksaan kesehatan.
Jika port pada server backend aktif mendengarkan, port tersebut merespons dengan paket SYN+ACK.
Jika node tidak menerima tanggapan dari server backend dalam batas waktu respons, pemeriksaan kesehatan gagal. Node kemudian mengirim paket RST untuk menghentikan koneksi TCP.
Jika node menerima tanggapan dari server backend dalam batas waktu respons, pemeriksaan kesehatan berhasil. Node kemudian mengirim paket RST untuk menghentikan koneksi TCP.
Mekanisme ini dapat menyebabkan server backend mencatat error koneksi TCP, seperti Connection reset by peer, dalam log aplikasinya.
Solusi:
Gunakan pemeriksaan kesehatan berbasis HTTP untuk listener TCP.
Aktifkan pelestarian IP klien pada server backend, lalu konfigurasikan agar mengabaikan error koneksi dari blok CIDR layanan CLB.
Pemeriksaan kesehatan listener UDP
Untuk listener UDP Lapisan 4, pemeriksaan kesehatan menggunakan probe UDP untuk memperoleh informasi status, seperti yang ditunjukkan pada gambar berikut.
Proses pemeriksaan kesehatan untuk listener UDP adalah sebagai berikut:
Sebuah node dalam kluster Lapisan 4 mengirim paket UDP ke alamat IP internal dan port pemeriksaan kesehatan server backend berdasarkan konfigurasi pemeriksaan kesehatan.
Jika port server backend tidak sedang mendengarkan, sistem operasinya mengembalikan pesan error ICMP, seperti
port XX unreachable. Jika port tersebut sedang mendengarkan, tidak ada pesan yang dikembalikan.Jika node menerima pesan error ICMP ini dalam batas waktu respons, pemeriksaan kesehatan gagal.
Jika node tidak menerima tanggapan apa pun dari server backend dalam batas waktu respons, pemeriksaan kesehatan berhasil.
Pemeriksaan kesehatan untuk layanan UDP mungkin tidak secara akurat mencerminkan status sebenarnya dari layanan dalam skenario berikut:
Jika server backend menjalankan Linux, proteksi banjir ICMP pada sistem operasi dapat membatasi laju pengiriman pesan ICMP selama periode konkurensi tinggi. Dalam kasus ini, meskipun layanan mati, CLB mungkin tidak menerima error port XX unreachable. CLB kemudian salah menandai pemeriksaan sebagai berhasil karena tidak menerima error ICMP, sehingga terjadi ketidaksesuaian antara status pemeriksaan kesehatan dan status layanan sebenarnya.
Solusi:
Konfigurasikan CLB untuk mengirim string tertentu ke server backend. Pemeriksaan hanya berhasil setelah menerima tanggapan tertentu. Metode ini memerlukan perubahan pada aplikasi backend.
Jendela waktu pemeriksaan kesehatan
Pemeriksaan kesehatan meningkatkan ketersediaan layanan. Untuk mencegah ketidakstabilan akibat perubahan status yang sering, CLB hanya mengubah status server backend setelah server tersebut secara berturut-turut lulus atau gagal dalam beberapa pemeriksaan. Jendela pemeriksaan kesehatan ini bergantung pada tiga faktor:
Interval pemeriksaan kesehatan: Waktu antara dua pemeriksaan kesehatan berturut-turut.
Timeout respons: Waktu maksimum untuk menunggu tanggapan dari server.
Ambang batas pemeriksaan kesehatan: Jumlah pemeriksaan kesehatan berturut-turut yang berhasil atau gagal yang diperlukan untuk mengubah status server.
Jendela waktu dihitung menggunakan rumus berikut:
Jendela waktu hingga pemeriksaan kesehatan gagal = timeout respons × ambang batas tidak sehat + interval pemeriksaan kesehatan × (ambang batas tidak sehat - 1)
Jendela waktu hingga pemeriksaan kesehatan berhasil = (Waktu respons untuk pemeriksaan berhasil × ambang batas sehat) + interval pemeriksaan kesehatan × (ambang batas sehat - 1)
CatatanWaktu respons untuk pemeriksaan berhasil adalah durasi antara pengiriman permintaan pemeriksaan kesehatan dan penerimaan tanggapannya. Untuk pemeriksaan kesehatan TCP, waktu ini sangat singkat dan dapat diabaikan. Untuk pemeriksaan kesehatan HTTP, waktu ini bergantung pada performa dan beban server backend tetapi biasanya kurang dari satu detik.
Dampak status pemeriksaan kesehatan terhadap penerusan permintaan:
Jika server backend gagal dalam pemeriksaan kesehatan, permintaan baru tidak didistribusikan kepadanya. Hal ini tidak memengaruhi akses klien.
Jika server backend lulus dalam pemeriksaan kesehatan, permintaan baru didistribusikan kepadanya, dan akses klien berjalan normal.
Jika server backend mengalami masalah dan berada dalam jendela waktu hingga pemeriksaan kesehatan gagal tetapi belum mencapai ambang batas tidak sehat (secara default, tiga kali kegagalan berturut-turut), permintaan masih didistribusikan kepadanya. Hal ini dapat menyebabkan permintaan klien gagal.
Contoh: Timeout respons dan interval pemeriksaan kesehatan
Pertimbangkan konfigurasi pemeriksaan kesehatan berikut:
Response timeout: 5 seconds
Health check interval: 2 seconds
Healthy threshold: 3
Unhealthy threshold: 3
Jendela waktu hingga pemeriksaan kesehatan gagal = timeout respons × ambang batas tidak sehat + interval pemeriksaan kesehatan × (ambang batas tidak sehat - 1). Perhitungannya adalah 5 × 3 + 2 × (3 - 1) = 19 detik. Artinya, diperlukan waktu 19 detik sejak pemeriksaan kesehatan pertama gagal hingga server ditandai sebagai tidak sehat.
Jendela waktu hingga pemeriksaan kesehatan berhasil = (Waktu respons untuk pemeriksaan berhasil × ambang batas sehat) + interval pemeriksaan kesehatan × (ambang batas sehat - 1). Dengan asumsi waktu respons 1 detik, perhitungannya adalah (1 × 3) + 2 × (3 - 1) = 7 detik. Artinya, diperlukan waktu 7 detik sejak pemeriksaan kesehatan pertama berhasil hingga server yang sebelumnya tidak sehat ditandai sebagai sehat.
Waktu respons untuk pemeriksaan berhasil adalah durasi antara pengiriman permintaan pemeriksaan kesehatan dan penerimaan tanggapannya. Untuk pemeriksaan kesehatan TCP, waktu ini sangat singkat dan dapat diabaikan karena hanya memeriksa apakah port aktif. Untuk pemeriksaan kesehatan HTTP, waktu ini bergantung pada performa dan beban server backend tetapi biasanya kurang dari satu detik.
Nama domain untuk pemeriksaan kesehatan HTTP
Saat Anda menggunakan pemeriksaan kesehatan HTTP, Anda dapat secara opsional mengatur nama domain. Beberapa server backend mensyaratkan header Host ada dalam permintaan dan akan memvalidasi isinya. Jika Anda mengonfigurasi nama domain, CLB menambahkannya ke header Host pada permintaan pemeriksaan kesehatan. Jika Anda tidak mengonfigurasi nama domain, server mungkin menolak permintaan pemeriksaan kesehatan, sehingga menyebabkan pemeriksaan gagal.
Oleh karena itu, jika server backend Anda memvalidasi header Host, Anda harus mengonfigurasi nama domain untuk memastikan pemeriksaan kesehatan berfungsi dengan benar.
Referensi
Anda harus mengonfigurasi pemeriksaan kesehatan saat menambahkan listener. Untuk petunjuknya, lihat Konfigurasi dan kelola pemeriksaan kesehatan CLB.
Untuk pertanyaan umum tentang pemeriksaan kesehatan, lihat FAQ pemeriksaan kesehatan CLB.