Server Load Balancer：FAQ pemeriksaan kesehatan SLB

Topik ini menjawab 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 selengkapnya, lihat Pemeriksaan kesehatan SLB.

Apa saja konfigurasi pemeriksaan kesehatan yang direkomendasikan?

Kami merekomendasikan konfigurasi pemeriksaan kesehatan berikut.

Untuk mencegah perubahan status yang terlalu sering memengaruhi ketersediaan layanan, status kesehatan server backend hanya diubah setelah terjadi beberapa keberhasilan atau kegagalan berturut-turut dalam rentang waktu tertentu. Untuk informasi selengkapnya, lihat Konfigurasi dan kelola pemeriksaan kesehatan SLB.

Dapatkah saya menonaktifkan pemeriksaan kesehatan?

Ya, Anda bisa. Untuk informasi selengkapnya, lihat Nonaktifkan pemeriksaan kesehatan.

Bagaimana cara memilih metode pemeriksaan kesehatan untuk listener TCP?

Listener TCP mendukung pemeriksaan kesehatan HTTP dan TCP:

• Pemeriksaan kesehatan TCP mengirim pesan jabat tangan SYN untuk mendeteksi apakah port server aktif.

• Pemeriksaan kesehatan HTTP mengirim permintaan HEAD atau GET untuk mensimulasikan akses browser dan memverifikasi bahwa aplikasi server berjalan sesuai harapan.

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

Apa dampak pengaturan bobot instance ECS ke nol terhadap pemeriksaan kesehatan?

SLB berhenti meneruskan traffic ke instance ECS yang bobotnya diatur ke nol. Namun, status pemeriksaan kesehatan server backend tidak berubah menjadi abnormal. Mengatur bobot instance ECS backend ke nol sama artinya dengan menghapus instance tersebut dari instance SLB. Operasi ini biasanya dilakukan selama aktivitas maintenance, seperti me-restart atau mengonfigurasi ulang instance ECS.

Metode default apa yang digunakan oleh listener HTTP untuk melakukan pemeriksaan kesehatan pada instance ECS backend?

Metode HEAD

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

Alamat IP apa yang digunakan oleh listener HTTP untuk melakukan pemeriksaan kesehatan pada instance ECS backend?

SLB menggunakan blok CIDR 100.64.0.0/10 untuk pemeriksaan kesehatan. Server backend tidak boleh memblokir blok CIDR ini. Anda tidak perlu menambahkan aturan allow di grup keamanan ECS Anda. Namun, jika Anda telah mengonfigurasi kebijakan keamanan seperti iptables, Anda harus mengizinkan akses dari blok CIDR ini. Blok CIDR 100.64.0.0/10 merupakan ruang alamat terreservasi Alibaba Cloud dan tidak menimbulkan risiko keamanan.

Kapan pemeriksaan kesehatan CLB dimulai?

Pemeriksaan kesehatan dimulai segera setelah dikonfigurasi untuk instance SLB. SLB kemudian mengirim permintaan pemeriksaan kesehatan secara berkala berdasarkan interval pemeriksaan kesehatan yang dikonfigurasi.

Bagaimana menangani kegagalan pemeriksaan kesehatan yang disebabkan oleh database backend yang rusak?

• Masalah

  Instance ECS meng-host dua website: www.example.com (website statis) dan aliyundoc.com (website dinamis). Kedua website menggunakan SLB. Akses ke www.example.com mengembalikan error 502 karena layanan database backend mengalami gangguan.

• Penyebab

  Nama domain pemeriksaan dalam konfigurasi pemeriksaan kesehatan SLB adalah aliyundoc.com. Karena adanya gangguan pada ApsaraDB RDS atau database yang dikelola sendiri, akses ke aliyundoc.com gagal, sehingga menyebabkan pemeriksaan kesehatan gagal.

• Solusi

  Atur nama domain pemeriksaan kesehatan SLB ke www.example.com.

Mengapa log layanan backend menunjukkan error koneksi jaringan meskipun port TCP lulus pemeriksaan kesehatan?

• Masalah

  Setelah port layanan TCP dikonfigurasi pada backend SLB, pesan error koneksi jaringan sering muncul di log layanan backend. Analisis packet capture menunjukkan bahwa permintaan berasal dari server SLB dan SLB secara aktif mengirim paket RST.

  

• Penyebab

  Masalah ini terkait dengan mekanisme pemeriksaan kesehatan SLB. Untuk port layanan TCP, pemeriksaan kesehatan SLB hanya melakukan jabat tangan tiga arah TCP, lalu mengirim paket RST untuk menutup koneksi. Prosedurnya sebagai berikut:

  1. Server SLB mengirim paket permintaan SYN.

  2. Server backend mengembalikan paket acknowledgement SYN+ACK.

  3. Setelah server SLB menerima acknowledgement tersebut, port dianggap aktif dan pemeriksaan kesehatan berhasil.

  4. Server SLB mengirim paket RST untuk menutup koneksi dan tidak mengirim data layanan apa pun.

  Karena koneksi langsung diputus setelah pemeriksaan kesehatan berhasil, layanan tingkat atas—seperti kolam koneksi Java—dapat menganggap hal ini sebagai koneksi abnormal. Akibatnya, muncul pesan error seperti Connection reset by peer.

• Solusi

  • Ubah protokol dari TCP ke HTTP.

  • Filter permintaan dari rentang alamat IP SLB di tingkat aplikasi untuk mengabaikan pesan error tersebut di log Anda.

Mengapa pemeriksaan kesehatan ditampilkan sebagai abnormal padahal layanan berjalan dengan benar?

• Masalah

  Pemeriksaan kesehatan HTTP SLB selalu gagal, tetapi pengujian dengan curl mengembalikan kode status normal.

• Penyebab

  Jika kode status yang dikembalikan tidak sesuai dengan kode status normal yang dikonfigurasi di konsol, pemeriksaan kesehatan akan gagal. Misalnya, jika kode status normal dikonfigurasi sebagai http_2xx, semua kode status non-HTTP 2xx akan menyebabkan pemeriksaan kesehatan gagal.

  Dalam konfigurasi Tengine/Nginx, perintah curl berfungsi dengan benar. Namun, perintah echo cocok dengan situs default, sehingga file test.html mengembalikan error 404.

  

• Solusi

  • Anda dapat memodifikasi file konfigurasi utama untuk memberi komentar pada situs default.

  • Tambahkan nama domain ke konfigurasi pemeriksaan kesehatan.

Mengapa frekuensi pemeriksaan kesehatan berbeda dari yang tercatat di log web?

Layanan pemeriksaan kesehatan SLB juga berjalan dalam kluster untuk mencegah single point of failure. Layanan SLB didistribusikan di beberapa node. Setiap node melakukan pemeriksaan kesehatan secara independen. Desain ini meningkatkan jumlah total permintaan pemeriksaan kesehatan yang diterima server backend Anda. Akibatnya, frekuensi pemeriksaan kesehatan yang teramati di log tidak sesuai dengan frekuensi yang diatur di konsol. Hal ini normal.

Bagaimana cara membedakan log pemeriksaan kesehatan dan log layanan di server backend secara efektif?

• Masalah

  Di server backend, log permintaan pemeriksaan kesehatan tercampur dengan log layanan normal. Hal ini membuat ukuran file log besar dan sulit difilter.

• Penyebab

  Pemeriksaan kesehatan memverifikasi ketersediaan layanan backend dengan mengirim permintaan HTTP, TCP, atau UDP. Layanan backend mencatat permintaan pemeriksaan kesehatan ini dengan cara yang sama seperti permintaan layanan normal, sehingga tercampur dengan log layanan normal.

• Solusi

  • Kurangi frekuensi pemeriksaan kesehatan: Perbesar Interval Pemeriksaan Kesehatan untuk mengurangi frekuensi pemeriksaan kesehatan dan volume log pemeriksaan kesehatan.

  • Sesuaikan jalur pemeriksaan kesehatan (untuk pemeriksaan kesehatan HTTP): Atur Jalur Pemeriksaan Kesehatan ke jalur non-layanan, seperti /health. Anda kemudian dapat memfilter log berdasarkan jalur ini untuk memisahkan log pemeriksaan kesehatan dari log layanan.

  • Nonaktifkan pemeriksaan kesehatan (tidak direkomendasikan): Jika Anda yakin tidak memerlukan fitur pemeriksaan kesehatan, nonaktifkan fitur tersebut untuk mencegah pembuatan log pemeriksaan kesehatan.