Memecahkan masalah respons lalu lintas backend Azure Load Balancer

Halaman ini menyediakan informasi pemecahan masalah untuk pertanyaan Azure Load Balancer.

Mesin virtual di belakang penyeimbang beban menerima distribusi lalu lintas yang tidak merata

Jika Anda menduga anggota kumpulan backend menerima lalu lintas, mungkin hal tersebut disebabkan oleh hal berikut ini. Azure Load Balancer mendistribusikan lalu lintas berdasarkan koneksi. Pastikan untuk memeriksa distribusi lalu lintas per koneksi dan bukan per paket. Verifikasi menggunakan tab Distribusi Alur di dasbor Load Balancer Insights yang telah dikonfigurasi sebelumnya.

Azure Load Balancer tidak mendukung penyeimbangan beban round robin yang sebenarnya, tetapi mendukung mode distribusi berbasis hash.

Penyebab 1: Anda memiliki sesi persistensi yang dikonfigurasi

Menggunakan mode distribusi persistensi sumber dapat menyebabkan distribusi lalu lintas yang tidak merata. Jika distribusi ini tidak diinginkan, perbarui persistensi sesi menjadi Tidak Ada sehingga lalu lintas didistribusikan ke seluruh instans yang sehat dalam kumpulan backend. Pelajari selengkapnya tentang mode distribusi untuk Azure Load Balancer.

Penyebab 2: Anda memiliki proksi yang dikonfigurasi

Klien yang berjalan di balik proksi mungkin akan terlihat sebagai satu aplikasi klien yang unik dari sudut pandang penyeimbang beban.

Mesin Virtual di balik penyeimbang beban tidak merespons terhadap lalu lintas pada port data yang dikonfigurasikan

Jika Mesin Virtual kumpulan backend terdaftar dengan kondisi sehat dan merespons terhadap penyelidikan kesehatan, tetapi masih tidak berpartisipasi dalam penyeimbangan beban, atau tidak merespons terhadap lalu lintas data, itu mungkin disebabkan oleh salah satu alasan berikut:

  • Mesin Virtual kumpulan backend penyeimbang beban tidak mendengarkan port data

  • Kelompok keamanan jaringan memblokir port pada VM kumpulan backend load balancer

  • Mengakses penyeimbang beban dari Mesin Virtual dan NIC yang sama

  • Mengakses frontend penyeimbang beban Internet dari Mesin Virtual kumpulan backend penyeimbang beban yang berpartisipasi

Penyebab 1: Mesin Virtual kumpulan backend penyeimbang beban tidak mendengarkan port data

Jika Mesin Virtual tidak merespons lalu lintas data, itu mungkin karena port target tidak terbuka terhadap Mesin Virtual yang berpartisipasi, atau, Mesin Virtual tidak mendengarkan port tersebut.

Validasi dan resolusi

  1. Masuk ke Mesin Virtual backend.

  2. Buka perintah dan jalankan perintah berikut untuk memvalidasi ada aplikasi yang mendengarkan di port data:

    netstat -an 
    
  3. Jika port tidak terdaftar dengan status MENDENGARKAN, konfigurasikan port pendengar yang tepat

  4. Jika port ditandai sebagai MENDENGARKAN, periksa aplikasi target pada port tersebut untuk mengetahui masalah apa pun yang mungkin terjadi.

Penyebab 2: Kelompok keamanan jaringan memblokir port pada VM kumpulan backend load balancer

Jika satu atau beberapa kelompok keamanan jaringan yang dikonfigurasi pada subnet atau pada komputer virtual, memblokir IP atau port sumber, komputer virtual tidak dapat merespons.

Untuk penyeimbang muatan publik, alamat IP klien Internet akan digunakan untuk komunikasi antara klien dan komputer virtual backend penyeimbang muatan. Pastikan alamat IP klien diperbolehkan dalam kelompok keamanan jaringan komputer virtual backend.

  1. Mencantumkan kelompok keamanan jaringan yang dikonfigurasi pada komputer virtual backend. Untuk informasi selengkapnya, lihat Mengelola kelompok keamanan jaringan

  2. Dari daftar kelompok keamanan jaringan, periksa apakah:

    • Lalu lintas masuk atau keluar pada port data memiliki gangguan.

    • Aturan kelompok keamanan jaringan Tolak Semua pada NIC dari Mesin Virtual atau subnet yang memiliki prioritas lebih tinggi daripada aturan default yang memperbolehkan penyelidikan penyeimbang beban dan lalu lintas (kelompok keamanan jaringan harus memperbolehkan IP penyeimbang beban 168.63.129.16, yang merupakan port penyelidikan)

  3. Jika salah satu aturan ini memblokir lalu lintas, hapus dan konfigurasi ulang aturan untuk memungkinkan lalu lintas data. 

  4. Uji apakah komputer virtual sekarang telah mulai menanggapi pemeriksaan kesehatan.

Penyebab 3: Akses load balancer internal dari VM dan antarmuka jaringan yang sama

Jika aplikasi Anda yang dihosting di VM backend dari load balancer internal mencoba mengakses aplikasi lain yang dihosting di VM backend yang sama melalui antarmuka jaringan yang sama, ini adalah skenario yang tidak didukung dan akan gagal.

Resolusi

Anda dapat menyelesaikan masalah ini melalui salah satu metode berikut:

  • Konfigurasikan komputer virtual kumpulan backend terpisah per aplikasi.

  • Konfigurasikan aplikasi dalam Mesin Virtual NIC ganda sehingga setiap aplikasi menggunakan antarmuka jaringan dan alamat IP sendiri.

Penyebab 4: Akses frontend penyeimbang beban internal dari Mesin Virtual kumpulan backend penyeimbang beban yang berpartisipasi

Jika penyeimbang beban internal dikonfigurasikan di dalam jaringan virtual, dan salah satu Mesin Virtual backend peserta mencoba mengakses frontend penyeimbang beban internal, kegagalan dapat terjadi ketika alur dipetakan ke Mesin Virtual asal. Skenario ini tidak didukung.

Resolusi

Ada beberapa cara untuk membuka blokir skenario ini, termasuk menggunakan proksi. Mengevaluasi Application Gateway atau proksi pihak ketiga lainnya (misalnya, nginx atau haproxy). Untuk informasi selengkapnya tentang Application Gateway, lihat Gambaran Umum Application Gateway

Rincian

Penyeimbang beban internal tidak menerjemahkan sambungan asal keluar ke front end penyeimbang beban internal karena keduanya berada dalam ruang alamat IP privat. Penyeimbang beban publik menyediakan sambungan keluar dari alamat IP privat di dalam jaringan virtual ke alamat IP publik. Untuk penyeimbang beban internal, pendekatan ini menghindari potensi kelelahan port SNAT di dalam ruang alamat IP internal yang unik, tempat terjemahan tidak diperlukan.

Efek samping adalah bahwa jika aliran keluar dari VM di kumpulan backend mencoba aliran ke ujung depan penyeimbang beban internal di kumpulannya dan dipetakan kembali ke dirinya sendiri, dua kaki aliran tidak cocok. Karena mereka tidak cocok, alurnya gagal. Alur berhasil jika alur tidak memetakan kembali ke VM yang sama di kumpulan backend yang membuat alur ke ujung depan.

Ketika alur memetakan kembali ke dirinya sendiri, alur keluar tampaknya berasal dari VM ke ujung depan, dan alur masuk yang sesuai tampaknya berasal dari VM ke dirinya sendiri. Dari sudut pandang sistem operasi tamu, bagian masuk dan keluar dari alur yang sama tidak cocok di dalam komputer virtual. Tumpukan TCP tidak akan mengenali bagian-bagian ini dari alur yang sama sebagai bagian dari alur yang sama. Sumber dan tujuan tidak cocok. Ketika alur memetakan ke VM lain di kumpulan backend, bagian alur cocok dan VM dapat merespons alur.

Gejala untuk skenario ini adalah batas waktu koneksi terputus-putus ketika alur kembali ke backend yang sama yang berasal dari alur. Solusi umum mencakup penyisipan lapisan proksi di belakang penyeimbang beban internal dan penggunaan aturan gaya Pengembalian Server Langsung (DSR). Untuk informasi selengkapnya, lihat Beberapa frontend untuk Azure Load Balancer.

Anda dapat menggabungkan penyeimbang beban internal dengan proksi pihak ketiga atau menggunakan Application Gateway internal untuk skenario proksi dengan HTTP /HTTPS. Saat Anda dapat menggunakan penyeimbang beban publik untuk meredakan masalah ini, skenario yang dihasilkan rentan terhadap Kelelahan SNAT. Hindari pendekatan kedua ini kecuali dikelola dengan hati-hati.

Langkah berikutnya

Jika langkah-langkah sebelumnya tidak mengatasi masalah, buka tiket dukungan.