All Products
Search

This Product

    Server Load Balancer:Pemeriksaan kesehatan CLB

    Document Center

    Server Load Balancer:Pemeriksaan kesehatan CLB

    Last Updated:May 28, 2026

    CLB menggunakan pemeriksaan kesehatan untuk menentukan ketersediaan server backend. Jika server backend menjadi tidak sehat, CLB berhenti mengirim permintaan ke server tersebut dan mendistribusikannya ke server yang sehat. Ketika server pulih, CLB melanjutkan penerusan lalu lintas kepadanya. Mekanisme pemeriksaan kesehatan ini meningkatkan ketersediaan layanan secara keseluruhan dengan mencegah kegagalan server individual memengaruhi aplikasi Anda.

    Penting

    Jika layanan Anda sensitif terhadap beban, pemeriksaan kesehatan yang terlalu sering dapat memengaruhi lalu lintas layanan normal. Anda dapat mengurangi dampak ini dengan menurunkan frekuensi pemeriksaan kesehatan, memperpanjang interval pemeriksaan kesehatan, atau beralih dari pemeriksaan kesehatan Lapisan 7 ke Lapisan 4. Namun, untuk memastikan ketersediaan layanan yang berkelanjutan, kami menyarankan agar Anda tidak menonaktifkan pemeriksaan kesehatan.

    Proses pemeriksaan kesehatan

    Pemeriksaan kesehatan mengonfirmasi status server dengan mengirim permintaan secara berkala.

    CLB dideploy dalam sebuah kluster. Node-node dalam kluster ini melakukan baik penerusan data maupun pemeriksaan kesehatan. Jika server backend gagal dalam pemeriksaan kesehatan, CLB berhenti mendistribusikan permintaan klien baru ke server yang tidak sehat tersebut.

    CLB menggunakan blok CIDR 100.64.0.0/10 untuk pemeriksaan kesehatan. Server backend Anda tidak boleh memblokir lalu lintas dari rentang alamat ini. Anda tidak perlu menambahkan aturan izin di grup keamanan ECS Anda, tetapi jika Anda telah mengonfigurasi kebijakan keamanan lain seperti iptables, Anda harus mengizinkan lalu lintas dari blok CIDR ini. Rentang 100.64.0.0/10 merupakan ruang alamat Alibaba Cloud yang dicadangkan dan tidak menimbulkan risiko keamanan.

    Catatan

    Praktik terbaik untuk perlindungan grup keamanan ECS backend

    Untuk mencegah penyerang melewati CLB dan langsung mengakses IP publik instans ECS backend, kami menyarankan Anda mengonfigurasi aturan masuk untuk grup keamanan ECS. Aturan ini harus hanya mengizinkan lalu lintas ke port layanan Anda dari blok CIDR yang diperlukan dan menolak permintaan langsung dari internet. Kami merekomendasikan konfigurasi berikut:

    • Blok CIDR 100.64.0.0/10, yang digunakan untuk pemeriksaan kesehatan dan penerusan lalu lintas CLB, tidak dibatasi oleh aturan masuk grup keamanan ECS backend. Anda tidak perlu menambahkan aturan izin khusus untuk blok CIDR ini karena lalu lintas dari CLB ke instans ECS backend selalu diizinkan.

    • Dalam aturan masuk grup keamanan ECS, izinkan akses ke port layanan Anda (seperti 80 dan 443) hanya dari blok CIDR VPC Anda. Jangan izinkan akses ke port layanan Anda dari internet (0.0.0.0/0).

    • Setelah konfigurasi ini selesai, grup keamanan akan memblokir permintaan langsung dari internet ke port layanan instans ECS. Lalu lintas normal yang diteruskan oleh CLB tidak terpengaruh.

    Pemeriksaan kesehatan HTTP dan HTTPS

    Pendengar Lapisan 7 (HTTP/HTTPS) melakukan pemeriksaan kesehatan menggunakan permintaan HEAD atau GET.

    Untuk pendengar HTTPS, sertifikat dikelola oleh CLB. CLB menggunakan HTTP untuk pertukaran data dengan server backend guna meningkatkan performa.

    Pemeriksaan kesehatan pendengar Lapisan 7 bekerja sebagai berikut:

    1. CLB mengirim permintaan HTTP HEAD ke server backend.

    2. Server backend mengembalikan kode status HTTP.

    3. Jika CLB tidak menerima tanggapan dalam batas waktu respons, pemeriksaan kesehatan gagal.

    4. Jika CLB menerima tanggapan dalam batas waktu respons, CLB membandingkan kode status dengan kode status sehat yang dikonfigurasi. Jika sesuai, pemeriksaan berhasil. Jika tidak, pemeriksaan gagal.

    Penting

    Secara default, pemeriksaan kesehatan CLB hanya menganggap kode status HTTP 2xx dan 3xx sebagai sehat. Jika server backend mengembalikan kode 4xx (seperti 400, 403, 404, atau 429) atau 5xx (seperti 500, 502, atau 503), pemeriksaan kesehatan gagal.

    Kami menyarankan 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 TCP

    Untuk pendengar TCP Lapisan 4, CLB menggunakan probe TCP khusus untuk memeriksa status server, seperti yang ditunjukkan pada gambar berikut.

    Pemeriksaan kesehatan pendengar TCP bekerja sebagai berikut:

    1. Sebuah node dalam kluster Lapisan 4 mengirim paket TCP SYN ke IP internal dan port pemeriksaan kesehatan server backend.

    2. Setelah menerima permintaan, jika server sedang mendengarkan port tersebut dengan benar, server akan mengembalikan paket SYN+ACK.

    3. Jika node kluster Lapisan 4 tidak menerima tanggapan dari server backend dalam batas waktu respons, pemeriksaan kesehatan gagal. Node tersebut kemudian mengirim paket RST untuk menghentikan koneksi TCP.

    4. Jika node kluster Lapisan 4 menerima tanggapan dari server backend dalam batas waktu respons, pemeriksaan kesehatan berhasil. Node tersebut kemudian mengirim paket RST untuk menghentikan koneksi TCP.

    Catatan

    Mekanisme ini dapat menyebabkan server backend menganggap koneksi TCP sebagai abnormal dan mencatat error, seperti Connection reset by peer, dalam log aplikasinya.

    Solusi alternatif:

    • Untuk pendengar TCP, gunakan pemeriksaan kesehatan berbasis HTTP.

    • Setelah Anda mengonfigurasi server backend untuk mendapatkan IP klien asli, abaikan error koneksi dari blok alamat layanan CLB.

    Pemeriksaan kesehatan UDP

    Untuk pendengar UDP Lapisan 4, pemeriksaan kesehatan menggunakan probe paket UDP untuk memeriksa status server, seperti yang ditunjukkan pada gambar berikut.

    Pemeriksaan kesehatan pendengar UDP bekerja sebagai berikut:

    1. Sebuah node dalam kluster Lapisan 4 mengirim paket UDP ke IP internal dan port pemeriksaan kesehatan server backend.

    2. Jika server backend tidak sedang mendengarkan port tersebut, sistem operasinya akan mengembalikan pesan error ICMP seperti port XX unreachable. Jika tidak, server tidak memberikan respons.

    3. Jika node dalam kluster Lapisan 4 menerima pesan error ini dari server backend dalam batas waktu respons, pemeriksaan kesehatan gagal.

    4. Jika node dalam kluster Lapisan 4 tidak menerima respons apa pun dari server backend dalam batas waktu respons, pemeriksaan kesehatan berhasil.

    Catatan

    Untuk layanan UDP, status pemeriksaan kesehatan mungkin tidak selalu sesuai dengan status layanan aktual.

    Jika server backend adalah Server Linux, skenario konkurensi tinggi dapat memicu mekanisme proteksi banjir ICMP Linux, yang membatasi laju pengiriman pesan ICMP oleh server. Dalam kasus ini, meskipun layanan sedang down, server mungkin tidak dapat mengembalikan error ICMP port XX unreachable. Akibatnya, ketika CLB tidak menerima respons ICMP, CLB salah menganggap pemeriksaan kesehatan berhasil. Hal ini menyebabkan ketidaksesuaian antara status kesehatan yang dilaporkan dan status layanan aktual.

    Solusi alternatif:

    Konfigurasikan load balancer untuk mengirim string tertentu ke server backend dan anggap pemeriksaan berhasil hanya setelah menerima respons tertentu. Mekanisme ini memerlukan dukungan dari aplikasi backend Anda.

    Jendela waktu pemeriksaan kesehatan

    Mekanisme pemeriksaan kesehatan meningkatkan ketersediaan layanan. Namun, untuk mencegah ketidakstabilan sistem akibat perubahan status yang terlalu sering, CLB hanya mengubah status server setelah server tersebut lulus atau gagal dalam jumlah tertentu pemeriksaan kesehatan berturut-turut dalam jendela waktu pemeriksaan kesehatan. Jendela waktu ini ditentukan oleh tiga faktor berikut:

    • interval pemeriksaan kesehatan (seberapa sering pemeriksaan kesehatan dilakukan)

    • timeout respons (waktu tunggu hingga server merespons pemeriksaan kesehatan)

    • ambang batas pemeriksaan (jumlah pemeriksaan sukses atau gagal berturut-turut yang diperlukan untuk perubahan status)

    Jendela waktu pemeriksaan kesehatan dihitung sebagai berikut:

    • Jendela kegagalan pemeriksaan kesehatan = timeout respons × ambang batas tidak sehat + interval pemeriksaan kesehatan × (ambang batas tidak sehat - 1)

    • Jendela keberhasilan pemeriksaan kesehatan = (waktu respons sukses pemeriksaan kesehatan × ambang batas sehat) + interval pemeriksaan kesehatan × (ambang batas sehat - 1)

      Catatan

      Waktu respons sukses pemeriksaan kesehatan adalah durasi dari pengiriman permintaan pemeriksaan kesehatan hingga menerima respons. Untuk pemeriksaan kesehatan TCP, waktu ini dapat diabaikan. Untuk pemeriksaan kesehatan HTTP, waktu ini bergantung pada performa dan beban server, tetapi biasanya kurang dari satu detik.

    Status pemeriksaan kesehatan memengaruhi penerusan permintaan sebagai berikut:

    • Jika server backend target gagal dalam pemeriksaan kesehatan, permintaan baru tidak lagi didistribusikan kepadanya. Pengalihan ini transparan bagi klien baru.

    • Jika server backend target lulus dalam pemeriksaan kesehatan, permintaan baru didistribusikan kepadanya dan akses klien berjalan normal.

    • Jika server backend sedang gagal dalam pemeriksaan kesehatannya tetapi belum mencapai ambang batas tidak sehat (tiga kegagalan berturut-turut secara default), CLB tetap mengirim permintaan kepadanya. Hal ini dapat menyebabkan permintaan klien gagal.

    Contoh konfigurasi pemeriksaan kesehatan

    Contoh ini menggunakan konfigurasi pemeriksaan kesehatan berikut:

    • response timeout: 5 seconds

    • health check interval: 2 seconds

    • healthy threshold: 3

    • unhealthy threshold: 3

    Jendela kegagalan pemeriksaan kesehatan dihitung sebagai: timeout respons × ambang batas tidak sehat + interval pemeriksaan kesehatan × (ambang batas tidak sehat - 1). Dengan nilai-nilai yang diberikan, hasilnya adalah 5 × 3 + 2 × (3 - 1) = 19 detik. Ini adalah total waktu dari awal pemeriksaan kesehatan pertama yang gagal hingga server ditandai sebagai tidak sehat.

    Jendela keberhasilan pemeriksaan kesehatan dihitung sebagai: (waktu respons sukses pemeriksaan kesehatan × ambang batas sehat) + interval pemeriksaan kesehatan × (ambang batas sehat - 1). Dengan asumsi waktu respons sukses sebesar 1 detik, hasilnya adalah (1 × 3) + 2 × (3 - 1) = 7 detik. Ini adalah total waktu dari awal pemeriksaan kesehatan pertama yang berhasil hingga server ditandai sebagai sehat.

    Catatan

    Waktu respons sukses pemeriksaan kesehatan adalah durasi dari pengiriman permintaan pemeriksaan kesehatan hingga menerima respons. Untuk pemeriksaan kesehatan TCP, waktu ini dapat diabaikan karena hanya memeriksa apakah port aktif. Untuk pemeriksaan kesehatan HTTP, waktu ini bergantung pada performa dan beban server aplikasi, tetapi biasanya kurang dari satu detik.

    Nama domain dalam pemeriksaan kesehatan HTTP

    Saat Anda mengonfigurasi pemeriksaan kesehatan HTTP, Anda dapat secara opsional menentukan Nama domain. Beberapa server aplikasi mengharuskan header host ada dalam permintaan. Jika server Anda memiliki persyaratan ini, Anda harus mengonfigurasi Nama domain. CLB menambahkan Nama domain ini ke header host pada permintaan pemeriksaan kesehatan. Jika header ini tidak ada, server mungkin menolak permintaan tersebut, sehingga menyebabkan pemeriksaan kesehatan gagal.

    Oleh karena itu, jika server aplikasi Anda memvalidasi bidang host, konfigurasikan Nama domain untuk memastikan pemeriksaan kesehatan berhasil.

    Referensi