Server Load Balancer:FAQ Pemeriksaan Kesehatan CLB

Topik ini menjawab pertanyaan-pertanyaan berikut:

Bagaimana cara kerja pemeriksaan kesehatan?

Pemeriksaan kesehatan mengacu pada pengiriman permintaan secara berkala ke server backend untuk memeriksa status server tersebut.

Untuk informasi lebih lanjut, lihat Pemeriksaan kesehatan CLB.

Apa saja konfigurasi pemeriksaan kesehatan yang direkomendasikan?

Kami merekomendasikan konfigurasi pemeriksaan kesehatan berikut.

Untuk mencegah perubahan status yang terlalu sering memengaruhi ketersediaan sistem, status pemeriksaan kesehatan hanya berubah setelah pemeriksaan berhasil atau gagal beberapa kali berturut-turut dalam rentang waktu tertentu. Untuk informasi lebih lanjut, lihat Konfigurasi dan kelola pemeriksaan kesehatan CLB.

Dapatkah saya menonaktifkan pemeriksaan kesehatan?

Ya. Untuk informasi lebih lanjut, lihat Nonaktifkan pemeriksaan kesehatan.

Bagaimana memilih metode pemeriksaan kesehatan untuk listener TCP?

Listener TCP mendukung metode pemeriksaan kesehatan HTTP dan TCP:

• Metode TCP memverifikasi bahwa port server aktif dengan mengirim paket SYN untuk melakukan handshake tiga arah dasar.

• Metode HTTP mengirim permintaan HEAD atau GET untuk mensimulasikan akses browser dan memeriksa apakah aplikasi server dalam kondisi sehat.

Pemeriksaan kesehatan TCP mengonsumsi lebih sedikit sumber daya server. Jika server backend Anda sangat sensitif terhadap beban dan Anda hanya perlu memastikan ketersediaan port, pilih metode TCP. Jika Anda perlu memastikan status kesehatan aplikasi secara lebih akurat, pilih metode HTTP.

Apa yang terjadi jika saya mengatur bobot instance ECS menjadi nol?

Mengatur bobot instance ECS backend menjadi 0 menghentikan CLB dari meneruskan traffic ke instance tersebut, meskipun pemeriksaan kesehatan tetap berhasil. Praktik ini umum dilakukan selama maintenance terencana, seperti reboot atau perubahan konfigurasi.

Metode default untuk pemeriksaan kesehatan HTTP

Metode HEAD.

curl -v -0 -I -H "Host:" -X HEAD http://IP:port

Alamat IP sumber pemeriksaan kesehatan

Pemeriksaan kesehatan CLB menggunakan blok CIDR 100.64.0.0/10. Anda harus memastikan bahwa server backend Anda tidak memblokir blok CIDR ini. Anda tidak perlu menambahkan aturan allow khusus di security group ECS Anda, tetapi jika Anda menggunakan kebijakan keamanan lain seperti iptables, Anda harus mengizinkan traffic dari blok ini. Blok CIDR 100.64.0.0/10 adalah ruang alamat tereservasi yang digunakan oleh Alibaba Cloud dan tidak menimbulkan risiko keamanan.

Kapan pemeriksaan kesehatan CLB dimulai?

Pemeriksaan kesehatan CLB dimulai segera setelah Anda mengonfigurasikannya untuk suatu listener, dengan mengirim permintaan secara berkala sesuai interval pemeriksaan kesehatan yang ditentukan.

Kegagalan pemeriksaan kesehatan akibat database bermasalah

• Gejala

  Sebuah instance ECS menghosting dua website: www.example.com (website statis) dan aliyundoc.com (website dinamis), dan keduanya dikonfigurasi dengan load balancing. Masalah pada layanan database backend menyebabkan error 502 saat Anda mengakses www.example.com.

• Penyebab

  Pemeriksaan kesehatan dikonfigurasi dengan domain pemeriksaan kesehatan aliyundoc.com. Kegagalan pada instance ApsaraDB RDS atau database yang dikelola sendiri menyebabkan aliyundoc.com tidak dapat diakses, sehingga menyebabkan pemeriksaan kesehatan gagal untuk seluruh server backend.

• Solusi

  Ubah domain pemeriksaan kesehatan dalam konfigurasi listener CLB Anda ke domain statis yang tidak bergantung pada database, seperti www.example.com.

Error koneksi meskipun pemeriksaan kesehatan TCP berhasil

• Gejala

  Setelah Anda mengonfigurasi listener TCP pada CLB, log aplikasi backend sering menunjukkan error koneksi jaringan. Analisis packet capture menunjukkan bahwa permintaan berasal dari server CLB, yang secara aktif mengirim paket RST untuk menghentikan koneksi.

  

• Penyebab

  Masalah ini terjadi karena mekanisme pemeriksaan kesehatan TCP. CLB memeriksa kesehatan port listener TCP dengan menyelesaikan handshake tiga arah, lalu segera mengirim paket RST untuk menutup koneksi. Prosesnya sebagai berikut:

  1. Server CLB mengirim paket SYN ke server backend.

  2. Server backend merespons dengan paket SYN+ACK.

  3. Setelah menerima respons, server CLB menganggap port tersebut sehat dan menandai pemeriksaan kesehatan sebagai berhasil.

  4. Server CLB mengirim paket RST untuk menghentikan koneksi tanpa mengirim data aplikasi apa pun.

  Karena koneksi langsung dihentikan setelah pemeriksaan kesehatan berhasil, beberapa framework aplikasi (seperti kolam koneksi Java) mungkin menganggap ini sebagai koneksi abnormal, sehingga menghasilkan error seperti Connection reset by peer.

• Solusi

  • Ubah protokol pemeriksaan kesehatan untuk listener dari TCP ke HTTP.

  • Di tingkat aplikasi, filter entri log yang berasal dari blok CIDR pemeriksaan kesehatan CLB (100.64.0.0/10) untuk mengabaikan error yang diharapkan ini.

Kegagalan pemeriksaan kesehatan pada server yang sehat

• Gejala

  Pemeriksaan kesehatan HTTP listener CLB terus-menerus gagal, tetapi pengujian langsung ke server backend menggunakan perintah curl mengembalikan kode status normal.

• Penyebab

  Pemeriksaan kesehatan gagal jika kode respons HTTP server tidak sesuai dengan kode status yang diharapkan dalam konfigurasi listener. Misalnya, jika Anda mengonfigurasi http_2xx sebagai kode status yang diharapkan, respons non-2xx apa pun dari server backend dianggap sebagai kegagalan pemeriksaan kesehatan.

  Dalam konfigurasi Tengine/Nginx, perintah curl berjalan tanpa masalah, tetapi perintah echo cocok dengan situs default, sehingga file uji test.html mengembalikan error 404.

  

• Solusi

  • Dalam file konfigurasi utama server web Anda, komentari atau konfigurasikan dengan benar virtual host default.

  • Tentukan domain pemeriksaan kesehatan dalam konfigurasi pemeriksaan kesehatan listener CLB untuk memastikan permintaan diarahkan ke virtual host yang benar.

Ketidaksesuaian frekuensi pemeriksaan kesehatan dalam log

Layanan pemeriksaan kesehatan CLB berjalan pada kluster node untuk mencegah titik kegagalan tunggal. Setiap node dalam kluster melakukan pemeriksaan kesehatan secara independen. Arsitektur ini meningkatkan jumlah total permintaan pemeriksaan kesehatan yang dikirim ke server backend Anda. Akibatnya, frekuensi entri pemeriksaan kesehatan dalam log server web Anda akan lebih tinggi daripada frekuensi yang Anda konfigurasi di Konsol. Ini merupakan perilaku yang diharapkan.

Bagaimana cara memisahkan log pemeriksaan kesehatan dari log aplikasi?

• Gejala

  Log permintaan pemeriksaan kesehatan tercampur dengan log traffic aplikasi normal, sehingga ukuran file log menjadi besar dan sulit dianalisis.

• Penyebab

  Pemeriksaan kesehatan mengirim permintaan HTTP, TCP, atau UDP untuk menguji ketersediaan server backend. Permintaan ini dicatat oleh layanan backend seperti traffic lainnya, sehingga tercampur dengan log aplikasi.

• Solusi

  • Kurangi frekuensi pemeriksaan kesehatan: Tingkatkan interval pemeriksaan kesehatan untuk menghasilkan lebih sedikit entri log pemeriksaan kesehatan.

  • Gunakan jalur pemeriksaan kesehatan khusus (untuk pemeriksaan kesehatan HTTP): Atur jalur pemeriksaan kesehatan ke jalur khusus yang tidak terkait bisnis, seperti /health. Anda kemudian dapat memfilter log berdasarkan jalur permintaan untuk memisahkan traffic pemeriksaan kesehatan.

  • Nonaktifkan pemeriksaan kesehatan (tidak direkomendasikan): Jika Anda yakin bahwa pemeriksaan kesehatan tidak diperlukan untuk kasus penggunaan Anda, Anda dapat menonaktifkannya untuk menghentikan pembuatan log pemeriksaan kesehatan.

Bagaimana cara melakukan troubleshooting kegagalan pemeriksaan kesehatan?

Pemeriksaan kesehatan menentukan apakah server backend berfungsi dengan benar. Saat pemeriksaan kesehatan gagal, hal ini sering kali menunjukkan adanya masalah pada server backend, tetapi konfigurasi pemeriksaan kesehatan yang salah juga dapat menyebabkan kegagalan. Ikuti langkah-langkah berikut untuk melakukan troubleshooting masalah tersebut.

1. Langkah 1: Pastikan blok CIDR 100.64.0.0/10 tidak diblokir.

   Pastikan server backend Anda tidak memblokir blok CIDR 100.64.0.0/10 dengan menggunakan iptables atau perangkat lunak firewall atau keamanan pihak ketiga lainnya. CLB menggunakan alamat IP dari blok CIDR internal tereservasi 100.64.0.0/10 untuk berkomunikasi dengan server backend. Jika blok CIDR ini diblokir, akan terjadi eksepsi pemeriksaan kesehatan.

2. Langkah 2: Uji layanan backend berdasarkan protokol listener.

   Pilih metode probing yang sesuai berdasarkan jenis listener:

   Lapisan 4 (TCP/UDP)

   Di Konsol CLB, buka halaman detail listener dan periksa konfigurasi pemeriksaan kesehatan. Konfirmasi Health Check Port, yang secara default menggunakan port server backend. Kemudian, dari mesin yang memiliki akses ke server, jalankan perintah telnet untuk mencoba koneksi ke port pemeriksaan kesehatan:

   telnet 172.17.58.131 80

   Ganti 172.17.58.131 dengan alamat IP pribadi server backend dan 80 dengan port pemeriksaan kesehatan yang sebenarnya.

   • Kasus normal: Mengembalikan Connected to xxx.xxx.xxx.xxx, yang menunjukkan bahwa port yang ditentukan pada server backend berfungsi dengan benar dan pemeriksaan kesehatan normal.

   • Hasil tidak sesuai: Perintah gagal dengan pesan "Connection refused" atau "Unable to connect". Hal ini menunjukkan tidak ada proses yang mendengarkan pada port tersebut. Periksa apakah layanan backend Anda berjalan dan mendengarkan pada port yang sama dengan yang ditentukan dalam konfigurasi pemeriksaan kesehatan.

   Jika listener Lapisan 4 menggunakan metode HTTP untuk pemeriksaan kesehatan, ikuti langkah troubleshooting di tab "Lapisan 7 (HTTP/HTTPS)".

   Lapisan 7 (HTTP/HTTPS)

   Di Konsol CLB, buka halaman detail listener untuk melihat konfigurasi pemeriksaan kesehatan Lapisan 7 dan konfirmasi Health Check Port, Health Check Domain Name, dan Health Check Path. Kemudian, dari server backend (misalnya, sistem Linux), jalankan perintah nc atau curl untuk menguji layanan HTTP backend. Jalur, port, dan domain pemeriksaan kesehatan harus sesuai dengan konfigurasi aktual di server backend. Jika tidak, pemeriksaan kesehatan akan gagal.

   Contoh menggunakan perintah nc:

   echo -e "HEAD /test.html HTTP/1.0\r\nHost: www.slb-test.com\r\n\r\n" | nc -t 172.17.58.131 80

   Ganti jalur, domain, IP, dan port dengan nilai dari lingkungan Anda.

   • Kasus normal: Kode status 200 atau kode status 2xx/3xx lainnya dikembalikan, yang menunjukkan bahwa layanan HTTP backend dalam kondisi sehat dan pemeriksaan kesehatan berhasil.

   • Situasi abnormal: Kode error seperti 404 dikembalikan, dan tidak sesuai dengan kode status 2xx/3xx yang dikonfigurasi untuk listener CLB. Periksa apakah resource di jalur pemeriksaan kesehatan tersedia, domain pemeriksaan kesehatan dikonfigurasi di server backend, dan port pemeriksaan kesehatan benar.