Server Load Balancer:Pemecahan Masalah Kegagalan Pemeriksaan Kesehatan ALB

Deskripsi masalah

Health Check Status untuk suatu listener pada instans ALB adalah Unhealthy.

Penyebab

Solusi

Pemeriksaan kesehatan gagal selama konfigurasi awal

Penyebab 1: Parameter pemeriksaan kesehatan salah

1. Masuk ke ALB console.

2. Di bilah menu atas, pilih wilayah tempat instans ALB berada.

3. Di panel navigasi kiri, pilih ALB > Server Groups.

4. Di halaman Server Groups, temukan grup server yang terhubung ke instans ALB target, lalu klik ID grup server tersebut.

5. Di halaman detail grup server, pada bagian Health Check, klik Modify Health Check.

6. Di kotak dialog Modify Health Check, verifikasi parameter pemeriksaan kesehatan. Kami merekomendasikan penggunaan nilai default.

   Pemeriksaan kesehatan untuk ALB

Penyebab 2: Masalah pada port pemeriksaan kesehatan

1. Masuk ke ALB console.

2. Di bilah menu atas, pilih wilayah tempat instans ALB berada.

3. Di panel navigasi kiri, pilih ALB > Server Groups.

4. Di halaman Server Groups, temukan grup server yang terhubung ke instans ALB target, lalu klik ID grup server tersebut.

5. Di halaman detail grup server, klik tab Backend Servers untuk melihat dan mencatat port server backend.

6. Di halaman detail grup server, klik tab Details, lalu di bagian Health Check, klik Modify Health Check. Di kotak dialog Modify Health Check, lihat dan catat parameter pemeriksaan kesehatan.

7. Masuk ke server backend dan gunakan perintah nc atau curl untuk melakukan probing terhadap server.

   Menghubungkan ke instans ECS

   # Perintah nc:
   echo -e "[$Method] [$PATH] [$VERSION]\r\nHost: [$Domain]\r\n\r\n" | nc -t [$IP] [$Port] # Format
   echo -e "HEAD /index.html HTTP/1.0\r\nHost: www.example.org\r\n\r\n" | nc -t 127.0.0.1 80 # Contoh
   # Perintah curl:
   curl -X [$Method] -H "Host: [$Domain]" -I http://[$IP]:[$Port][$PATH]  # Format
   curl -X HEAD --http1.0 -H "Host: www.example.org" -I http://127.0.0.1:80/index.html # Contoh

   Catatan

   • [$Method] adalah metode pemeriksaan kesehatan yang dikonfigurasi untuk grup server.

   • [$PATH] adalah jalur pemeriksaan kesehatan yang dikonfigurasi untuk grup server.

   • [$VERSION] adalah versi HTTP yang digunakan untuk pemeriksaan kesehatan, misalnya HTTP/1.0.

   • [$Domain] adalah nama domain yang dikonfigurasi untuk pemeriksaan kesehatan. Jika nilainya -----, alamat IP privat dari setiap instans ECS backend digunakan secara default. Dalam kasus ini, Anda dapat menggunakan [$IP] sebagai gantinya.

   • [$IP] adalah alamat IP privat dari instans ECS backend.

   • [$Port] adalah port pemeriksaan kesehatan yang dikonfigurasi untuk grup server. Jika tidak ada port pemeriksaan kesehatan yang dikonfigurasi secara manual, port instans ECS backend digunakan secara default. Jika port pemeriksaan kesehatan dikonfigurasi, maka port tersebut yang digunakan.

8. Periksa apakah kode status yang dikembalikan menunjukkan respons normal untuk layanan Anda.

   • Jika kode status normal tetapi tidak termasuk dalam kode status sehat yang dikonfigurasi, tambahkan kode tersebut ke konfigurasi pemeriksaan kesehatan.

   • Jika kode status menunjukkan kesalahan, lakukan pemecahan masalah menggunakan tabel berikut.

     Kode status	Deskripsi	Pemecahan Masalah
     400	Format permintaan HTTP dari client tidak valid.	Kemungkinan penyebab: (1) Kesalahan format header HTTP, misalnya content-length kosong atau permintaan HTTP dikirim ke port HTTPS — periksa format permintaan HTTP. (2) Jika logika bisnis tertentu mengembalikan kode 4xx dan menyebabkan kegagalan pemeriksaan kesehatan, pilih 4xx di bawah Health Check Response Codes dalam konfigurasi pemeriksaan kesehatan agar kode status 4xx diperlakukan sebagai respons normal. Hal ini mencegah node backend dihapus oleh pemeriksaan kesehatan karena kode balasan bisnis tertentu.
     403	Akses dilarang. ALB sendiri tidak mengembalikan kode status 403; respons 403 biasanya berasal dari konfigurasi layanan web backend.	Periksa apakah layanan backend (misalnya Nginx atau Tomcat) memiliki aturan kontrol akses yang memblokir permintaan dari alamat IP sumber atau pola permintaan tertentu. Jika backend memblokir sumber permintaan pemeriksaan kesehatan, pemeriksaan kesehatan akan terus-menerus mengembalikan 403. Sesuaikan konfigurasi kontrol akses layanan backend agar mengizinkan permintaan pemeriksaan kesehatan.
     404	Sumber daya target tidak ditemukan. Hal ini biasanya disebabkan oleh ketidaksesuaian antara jalur pemeriksaan kesehatan dan jalur yang benar-benar tersedia di server backend.	Lakukan pemecahan masalah sebagai berikut: Periksa awalan jalur yang diekspos oleh gerbang backend (misalnya Nginx), seperti /api/v1, dan pastikan Health Check Path yang dikonfigurasi sesuai dengan jalur yang benar-benar dapat diakses di backend. Jika akses langsung ke IP server backend menghasilkan respons normal tetapi akses melalui nama domain mengembalikan 404, layanan backend biasanya melakukan pencocokan host virtual berdasarkan nama domain (header Host). Verifikasi bahwa Health Check Domain yang dikonfigurasi untuk pemeriksaan kesehatan sesuai dengan konfigurasi domain layanan backend.
     405	Metode permintaan pemeriksaan kesehatan tidak didukung.	Periksa apakah layanan backend mendukung metode pemeriksaan kesehatan yang dikonfigurasi.
     500	Terjadi kesalahan internal server sehingga permintaan tidak dapat diselesaikan.	Periksa logika bisnis layanan backend.
     503	Server sementara tidak tersedia.	Periksa logika bisnis layanan backend atau tentukan apakah beban server terlalu tinggi.

Kegagalan pemeriksaan kesehatan pada konfigurasi yang sudah ada

Penyebab 1: Gangguan perangkat lunak keamanan

ALB menggunakan alamat IP dari blok CIDR yang dicadangkan untuk berkomunikasi dengan instans ECS backend. Jika blok CIDR ini diblokir, pemeriksaan kesehatan gagal dan ALB tidak dapat meneruskan permintaan. Contoh berikut menggunakan iptables untuk memeriksa pemblokiran pada 100.64.0.0/10.

1. Masuk ke instans ECS backend yang terpengaruh dan jalankan perintah berikut untuk menampilkan aturan tabel filter.

   iptables -nL

   Output yang mirip dengan berikut menunjukkan bahwa instans ECS backend memblokir permintaan dari blok CIDR ALB.

   [root@xxx Z ~]# iptables -nL
   Chain INPUT (policy ACCEPT)
   target     prot opt source               destination
   DROP       all  --  100.64.0.0/10        0.0.0.0/0
   Chain FORWARD (policy ACCEPT)
   target     prot opt source               destination
   Chain OUTPUT (policy ACCEPT)
   target     prot opt source               destination
   Chain L (0 references)
   target     prot opt source               destination

2. Jalankan perintah berikut untuk menghapus aturan ini:

   iptables -t filter -D INPUT -s 100.64.0.0/10 -j DROP

3. Konfirmasi bahwa blok CIDR ALB tidak lagi diblokir:

   iptables -nL

Selain aturan iptables, periksa konfigurasi keamanan berikut untuk memastikan trafik pemeriksaan kesehatan ALB dapat mencapai layanan backend:

1. Periksa status pendengaran port server backend: Pastikan server backend sedang mendengarkan pada port backend yang dikonfigurasi di grup server (misalnya port 80). Jalankan perintah berikut untuk memeriksa status pendengaran port:

   netstat -tlnp | grep <port>
   # Atau gunakan perintah ss:
   ss -tlnp | grep <port>

   Jika port tidak berada dalam status LISTEN, periksa apakah layanan backend telah dimulai dengan benar.

2. Periksa aturan masuk grup keamanan ECS backend: Pastikan aturan masuk grup keamanan mengizinkan akses dari sumber berikut. Jika tidak, probe pemeriksaan kesehatan ALB mungkin diblokir oleh grup keamanan:

   • Obyek otorisasi (alamat sumber): Untuk instans ALB yang telah ditingkatkan, blok CIDR vSwitch tempat Local IP-nya berada; untuk instans ALB yang belum ditingkatkan, blok CIDR 100.64.0.0/10.

   • Protokol: TCP

   • Rentang port: Port layanan backend yang dikonfigurasi di grup server.

Penyebab 2: Konfigurasi rute salah

Konfigurasi rute yang salah untuk blok CIDR 100.64.0.0/10 pada instans ECS backend dapat mencegah tanggapan pemeriksaan kesehatan mencapai instans ALB. Contoh berikut menggunakan perintah Linux route untuk memverifikasi konfigurasi.

1. Masuk ke instans ECS backend dan jalankan perintah berikut untuk memeriksa konfigurasi rute:

   route -n

   Rute salah jika terdapat entri dengan Destination 100.64.0.0 dan Genmask 255.192.0.0 yang memiliki Gateway selain gateway default NIC (nilai Gateway tempat Destination adalah 0.0.0.0).

   [root@test-server2 ~]# route -n
   Kernel IP routing table
   Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
   0.0.0.0         <Default gateway of eth0>  0.0.0.0         UG    100    0        0 eth0
   xxx             xxx             xxx             xxx   xxx    xxx      xxx xxx
   100.64.0.0      0.0.0.0         255.192.0.0     U     0      0        0 eth0

2. Jalankan perintah berikut untuk menghapus rute salah untuk blok CIDR 100.64.0.0/10:

   route del -net 100.64.0.0/10

Penyebab 3: Beban tinggi pada server backend

Ketika instans ECS backend kekurangan sumber daya, server mungkin gagal merespons probe pemeriksaan kesehatan dalam batas waktu yang dikonfigurasi, sehingga menyebabkan kegagalan pemeriksaan kesehatan. Kekurangan sumber daya dapat disebabkan oleh kelebihan beban sistem secara umum atau oleh masalah spesifik, seperti kebocoran koneksi, yang secara bertahap menghabiskan sumber daya sistem. Lakukan pemecahan masalah untuk dua sub-skenario berikut.

Sub-skenario 1: Kelebihan beban sumber daya sistem

Ketika CPU, memori, atau I/O disk jenuh, server tidak dapat merespons probe pemeriksaan kesehatan tepat waktu. Pemecahan masalah dan penanganan beban tinggi pada instans Linux.

Sub-skenario 2: Kebocoran koneksi yang menghabiskan sumber daya (penumpukan CLOSE_WAIT)

Jika instans ECS backend mengumpulkan sejumlah besar koneksi TCP CLOSE_WAIT, penyebabnya biasanya adalah aplikasi backend (misalnya layanan Java yang dikelola oleh jsvc.exec) tidak secara aktif memanggil close() untuk melepaskan koneksi setelah menangani permintaan. Hal ini menyebabkan koneksi tetap dalam status CLOSE_WAIT dan terakumulasi seiring waktu. Koneksi CLOSE_WAIT yang berlebihan mengonsumsi sumber daya sistem dan dapat memengaruhi respons pemeriksaan kesehatan.

Langkah pemecahan masalah:

1. Masuk ke instans ECS backend dan jalankan perintah berikut untuk memeriksa jumlah koneksi CLOSE_WAIT saat ini:

   netstat -an | grep CLOSE_WAIT | wc -l

2. Jika jumlah koneksi CLOSE_WAIT terus bertambah atau jumlahnya tidak wajar, periksa kode aplikasi backend atau konfigurasi layanan untuk memastikan aplikasi menutup koneksi dengan benar setelah memproses permintaan (misalnya dengan memanggil close() atau shutdown()). Untuk framework yang menggunakan kolam koneksi, periksa pengaturan timeout idle dan reclamation kolam tersebut.

FAQ

Mengapa server backend menerima permintaan pemeriksaan kesehatan dengan frekuensi tinggi?

ALB menggunakan arsitektur kluster terdistribusi multi-zona. Semua node penerusan dalam kluster mengirim probe pemeriksaan kesehatan ke server backend secara independen. Akibatnya, frekuensi permintaan aktual yang diterima server backend sama dengan frekuensi per node dikalikan jumlah node. Misalnya, jika interval pemeriksaan kesehatan diatur menjadi 5 detik dan kluster berisi 10 node penerusan, server backend menerima sekitar 10 permintaan pemeriksaan kesehatan setiap 5 detik, atau hampir 2 permintaan per detik. Ini merupakan perilaku yang diharapkan berdasarkan desain dan bukan menunjukkan adanya masalah.

Jika volume pemeriksaan kesehatan memengaruhi kinerja backend, kurangi frekuensinya dengan salah satu metode berikut:

• Sesuaikan parameter pemeriksaan kesehatan: Dalam konfigurasi pemeriksaan kesehatan, tingkatkan Health Check Interval (rentang: 1–50 detik) atau naikkan Healthy Threshold. Perhatikan bahwa interval yang lebih panjang akan menunda deteksi kesalahan.

• Beralih ke protokol pemeriksaan kesehatan Lapisan 4: Pemeriksaan Kesehatan Lapisan 4 hanya melakukan handshake TCP tanpa mengirim permintaan HTTP, sehingga secara signifikan mengurangi trafik pada server backend.