Server Load Balancer:FAQ pendengar CLB

Dukungan pengalihan port di CLB

Ya.

CLB mendukung pengalihan port. Untuk contoh, lihat Gunakan CLB untuk mengalihkan permintaan HTTP ke HTTPS.

Dukungan range port untuk pendengar Lapisan 4

Tidak. Untuk mendengarkan pada range port dengan pendengar TCP atau UDP, buat instance Network Load Balancer (NLB) dan aktifkan fitur All Ports untuk pendengar tersebut. Untuk informasi lebih lanjut, lihat Gunakan fitur pendengar NLB All Ports untuk meneruskan traffic pada beberapa port.

Pertimbangan konfigurasi port pendengar

Beberapa penyedia layanan mengklasifikasikan port seperti 25, 135, 139, 444, 445, 5800, dan 5900 sebagai port berisiko tinggi dan memblokirnya secara default. Bahkan jika Anda mengizinkan port-port tersebut dalam aturan security group, pengguna di wilayah yang dibatasi mungkin tidak dapat mengakses layanan Anda. Kami menyarankan menggunakan port non-berisiko tinggi lainnya.

• Untuk informasi tentang port yang digunakan oleh aplikasi pada sistem Windows Server, lihat Dokumentasi Microsoft Ikhtisar layanan dan persyaratan port jaringan untuk Windows Server.

• Untuk informasi lebih lanjut tentang port umum, lihat Port umum.

Konfigurasi pendengar untuk WebSocket

• Jika server backend Anda menyediakan layanan WebSocket, Anda dapat mengonfigurasi pendengar TCP atau pendengar HTTP.

• Jika server backend Anda menyediakan layanan WebSocket Secure, Anda dapat mengonfigurasi pendengar TCP atau pendengar HTTPS.

Dampak perubahan konfigurasi pendengar

Perubahan berlaku segera dan hanya berlaku untuk permintaan baru. Koneksi yang sudah ada tidak terpengaruh.

Karakter khusus dalam aturan pengalihan URL

Anda harus melakukan URL-encode karakter khusus dalam URL agar akses berjalan lancar. Misalnya, karakter hash (#) di-encode sebagai %23, sehingga URL-nya menjadi http://www.example.com/%23/. Untuk aturan encoding lengkap, lihat RFC 3986.

Manage backend servers for forwarding rules

Pada halaman Aturan Pengalihan, klik nama kelompok vServer target di kolom Kelompok Server Virtual. Pada halaman Edit Kelompok Server Virtual, Anda dapat menambah atau menghapus server backend, serta mengubah port atau bobotnya.

Apakah CLB mendukung pengaturan batas ukuran badan permintaan?

CLB tidak mendukung parameter client_max_body_size. Batas ukuran badan permintaan 50 GB adalah milik Application Load Balancer (ALB), bukan CLB.

Untuk mengontrol ukuran badan permintaan, gunakan pendengar Lapisan-4 TCP dan konfigurasikan client_max_body_size pada server web (seperti Nginx) di instance ECS backend:

http {
    client_max_body_size 100m;
}

Dengan pendengar TCP, CLB meneruskan traffic Lapisan-4 secara transparan, dan batas ukuran badan permintaan diterapkan oleh instance ECS backend.

Bagaimana cara menghitung bandwidth untuk instance CLB dengan bandwidth tetap?

Bandwidth arah keluar dan arah masuk instance CLB dengan bandwidth tetap dihitung secara terpisah. Setelah Anda menetapkan nilai bandwidth tetap, baik bandwidth arah keluar maupun arah masuk masing-masing dibatasi pada nilai yang dikonfigurasi. Anda tidak perlu menjumlahkannya. Misalnya, jika bandwidth tetap diatur ke 80 Mbps, bandwidth maksimum arah keluar adalah 80 Mbps dan bandwidth maksimum arah masuk juga 80 Mbps. Kedua nilai ini dihitung secara independen dan tidak saling memengaruhi.

Anda dapat melihat data pemantauan bandwidth arah keluar dan arah masuk secara real-time pada halaman pemantauan di konsol CLB. Dalam metrik pemantauan, inBitsPS merepresentasikan bandwidth arah masuk dan outBitsPS merepresentasikan bandwidth arah keluar. Kami menyarankan menggunakan data pemantauan per menit di konsol sebagai referensi saat menyesuaikan bandwidth.

Traffic turun meskipun tidak melebihi batas bandwidth

Masalah ini biasanya terjadi karena alasan berikut:

• Pemantauan bandwidth Alibaba Cloud menggunakan rata-rata per menit. Jika lonjakan traffic instan dalam satu detik melebihi batas bandwidth instance, sistem akan menjatuhkan traffic tersebut. Hal ini dapat terjadi meskipun rata-rata bandwidth selama satu menit tetap di bawah batas yang dikonfigurasi. Akibatnya, grafik pemantauan mungkin menunjukkan bahwa penggunaan bandwidth secara keseluruhan lebih rendah daripada batas yang ditentukan.

• Instance CLB berjalan pada kluster server yang mendistribusikan permintaan masuk secara merata di antara server-servernya. Bandwidth puncak yang dikonfigurasi juga didistribusikan ke seluruh server dalam kluster. Jika data yang diunduh oleh koneksi klien tunggal melebihi ambang batas server individual, sistem akan menjatuhkan traffic tersebut. Untuk informasi lebih lanjut tentang cara menghitung traffic unduhan maksimum untuk koneksi tunggal, lihat Mengapa koneksi tidak dapat mencapai bandwidth puncak dalam skenario tertentu?.

Traffic yang dipantau melebihi batas yang dikonfigurasi

Instance CLB menggunakan kluster server untuk pembatasan laju terdistribusi. Batas laju puncak untuk node tunggal dihitung sebagai Batas laju puncak per node = Total bandwidth yang dikonfigurasi / (N - 1), di mana N adalah jumlah node dalam kluster. Akibatnya, batas laju efektif total mungkin sedikit lebih tinggi daripada nilai yang dikonfigurasi.

Koneksi gagal mencapai bandwidth puncak

• Skenario: Koneksi tunggal ke instance CLB publik yang menggunakan metode penagihan bayar-per-spesifikasi (bandwidth tetap) mungkin tidak mencapai bandwidth puncak yang dikonfigurasi. Masalah ini sering terjadi selama uji stres klien tunggal atau saat mentransfer paket data yang sangat besar.

• Penyebab:

  Instance CLB berjalan pada kluster server. Kluster tersebut mendistribusikan semua permintaan masuk secara merata di antara server-servernya.

  Traffic unduhan maksimum untuk koneksi tunggal dihitung sebagai berikut: Traffic unduhan puncak per koneksi = Total bandwidth yang dikonfigurasi / (N - 1), di mana N adalah jumlah server dalam kluster. N bernilai 4 untuk pendengar Lapisan-4 dan 8 untuk pendengar Lapisan-7. Misalnya, jika Anda mengatur batas bandwidth ke 10 Mbps di konsol, bandwidth total dapat mencapai 10 Mbps ketika beberapa klien digunakan secara bersamaan. Namun, traffic maksimum yang dapat diunduh oleh klien tunggal adalah 10 / (4 - 1) = 3,33 Mbps.

• Solusi:

  • Gunakan metode penagihan bayar-per-lalu-lintas untuk instance CLB publik.

  • Gunakan instance NLB atau ALB dengan EIP dan shared bandwidth. Konfigurasi ini lebih elastis dan menghindari keterbatasan ini.

Instance CLB gagal mencapai QPS puncak

• Skenario: Saat menggunakan sejumlah kecil koneksi persisten, koneksi-koneksi tersebut mungkin tidak didistribusikan ke semua server dalam kluster pengalihan. Akibatnya, instance CLB mungkin tidak mencapai QPS puncaknya.

• Penyebab:

  Instance CLB dideploy dalam kluster. Sistem mendistribusikan permintaan masuk secara merata ke seluruh server dalam kluster. Oleh karena itu, QPS puncak instance CLB juga didistribusikan ke server-server tersebut.

  QPS maksimum untuk server tunggal dihitung sebagai berikut: QPS puncak per server = Total QPS instance / (N - 1), di mana N adalah jumlah server dalam kluster pengalihan. Misalnya, jika Anda membeli instance CLB spesifikasi slb.s1.small yang mendukung 1.000 QPS, total QPS dapat mencapai 1.000 ketika beberapa klien digunakan. Namun, jika kluster memiliki 8 server, QPS maksimum untuk server tunggal adalah 1000 / (8 - 1) = 142 QPS.

  Catatan

  Pembelian baru instance CLB bayar-per-spesifikasi akan dihentikan pada pukul 00:00:00 tanggal 1 Juni 2025 (UTC+8). Untuk informasi lebih lanjut, lihat Penghentian penjualan instance CLB bayar-per-spesifikasi.

• Solusi:

  • Gunakan koneksi singkat dari klien tunggal untuk uji stres.

  • Kurangi penggunaan ulang koneksi berdasarkan kebutuhan bisnis aktual Anda.

  • Tingkatkan spesifikasi instance CLB. Untuk informasi lebih lanjut, lihat Tingkatkan atau turunkan spesifikasi instance pay-as-you-go (bayar-per-spesifikasi).

  • Gunakan instance ALB. Jenis instance ini menawarkan elastisitas yang lebih besar.

Laju koneksi baru gagal mencapai puncak

• Skenario: Saat Anda menggunakan instance Classic Load Balancer (CLB) bayar-per-spesifikasi, laju koneksi barunya (CPS) mungkin tidak mencapai level yang ditentukan, terutama selama uji stres klien tunggal atau saat traffic berasal dari sumber tunggal.

  Catatan

  Pembelian baru instance CLB bayar-per-spesifikasi akan dihentikan pada pukul 00:00:00 tanggal 1 Juni 2025 (UTC+8). Untuk informasi lebih lanjut, lihat Penghentian penjualan instance CLB bayar-per-spesifikasi.

• Penyebab:

  Sistem load balancing menggunakan arsitektur kluster untuk ketersediaan tinggi dan skalabilitas. Sistem mendistribusikan permintaan koneksi masuk secara merata ke seluruh server dalam kluster. Oleh karena itu, CPS puncak instance CLB juga didistribusikan ke server-server tersebut.

  CPS puncak untuk server tunggal dihitung sebagai berikut: CPS puncak per server = Total CPS instance / (N - 1), di mana N adalah jumlah server dalam kluster pengalihan.

  Misalnya, jika Anda membeli instance CLB spesifikasi slb.s1.small dengan rating 3.000 CPS, instance tersebut dapat mencapai 3.000 CPS penuh dengan permintaan dari beberapa klien. Namun, jika kluster memiliki 4 server, CPS maksimum untuk server tunggal adalah 3000 / (4 - 1) = 1.000 CPS.

• Solusi:

  • Ubah metode penagihan instance dari bayar-per-spesifikasi ke bayar-per-penggunaan. Instance bayar-per-penggunaan tidak terikat pada spesifikasi kinerja tertentu dan menawarkan batas yang lebih tinggi, yang membantu mencegah bottleneck.

  • Upgrade ke Network Load Balancer (NLB) untuk skenario dengan konkurensi tinggi dan laju koneksi baru yang tinggi. NLB menawarkan kinerja dan elastisitas yang lebih unggul dibandingkan CLB. Instance NLB tunggal mendukung 100 juta koneksi bersamaan, menjadikannya ideal untuk aplikasi skala besar dan menghindari keterbatasan CPS dari arsitektur kluster CLB.

Range timeout koneksi yang didukung

• Timeout koneksi pendengar TCP: 10 hingga 900 detik.

• Pendengar HTTP:

  • Timeout idle: 1 hingga 60 detik.

  • Timeout permintaan: 1 hingga 180 detik.

• Pendengar HTTPS:

  • Timeout idle: 1 hingga 60 detik.

  • Timeout permintaan: 1 hingga 180 detik.

Penyebab timeout koneksi CLB

Masalah berikut di sisi server dapat menyebabkan timeout koneksi ke alamat layanan CLB:

• Alamat layanan diblokir oleh tindakan keamanan

  Ini termasuk pembersihan lalu lintas, penyaringan blackhole, atau perlindungan WAF. Sebagai contoh, WAF mengirim paket RST ke klien dan kluster server setelah koneksi terbentuk.

• Port klien tidak mencukupi

  Masalah ini umum terjadi selama uji stres. Kekurangan port klien dapat menyebabkan kegagalan koneksi. Secara default, CLB menghapus opsi timestamp dari koneksi TCP, yang mencegah fitur tw_reuse kernel Linux (menggunakan ulang koneksi dalam status TIME_WAIT) berfungsi. Hal ini menyebabkan akumulasi koneksi dalam status TIME_WAIT dan kekurangan port klien yang tersedia.

  Solusi: Gunakan koneksi persisten alih-alih koneksi singkat. Putuskan koneksi dengan mengirim paket RST dengan mengatur opsi socket SO_LINGER, bukan mengirim paket FIN.

• Antrean accept server backend penuh

  Jika antrean accept server backend penuh, server tidak mengirim respons SYN-ACK, yang menyebabkan timeout klien.

  Solusi: Nilai default net.core.somaxconn adalah 128. Evaluasi volume traffic Anda dan sesuaikan nilai ini sesuai kebutuhan. Kemudian, jalankan sysctl -w net.core.somaxconn=<new_value> untuk mengubah parameter dan restart aplikasi di server backend.

• Server backend Lapisan 4 mengakses alamat layanan load balancer-nya sendiri

  Pendengar Lapisan 4 CLB (TCP/UDP) tidak mengizinkan server backend bertindak sebagai klien sekaligus server. Jika server backend mencoba mengakses alamat layanan instance CLB yang terhubung dengannya, koneksi akan gagal. Skenario pemicu umum termasuk aplikasi backend yang mengalihkan ke alamat layanan CLB dengan membuat URL, dan instance ECS dalam VPC yang mengakses alamat layanan instance CLB-nya sendiri melalui jaringan publik, yang menyebabkan loopback traffic.

  Perilaku ini disebabkan oleh cara CLB meneruskan traffic di Lapisan 4 (LVS). Saat instance ECS backend mengirim paket ke instance CLB, CLB menulis ulang alamat IP tujuan dan meneruskan paket ke server backend. Jika CLB meneruskan permintaan kembali ke instance ECS yang sama yang mengirimnya, alamat IP sumber dan tujuan paket tersebut sama-sama merupakan alamat IP instance ECS tersebut. Akibatnya, respons diselesaikan secara lokal pada instance ECS dan tidak pernah melewati CLB lagi, sehingga koneksi tidak dapat terbentuk.

  • Jika instance CLB hanya memiliki satu server backend, setiap permintaan dari server backend tersebut diteruskan kembali ke dirinya sendiri, menghasilkan tingkat kegagalan koneksi 100%.

  • Jika instance CLB memiliki beberapa server backend, misalnya dua server backend dengan bobot yang sama, CLB meneruskan sekitar 50% permintaan ke server backend lain (koneksi berhasil). CLB meneruskan sekitar 50% permintaan kembali ke server backend asli (koneksi gagal). Tingkat keberhasilan keseluruhan sekitar 50%.

  Solusi:

  • Gunakan klien berbeda untuk mengakses alamat layanan alih-alih server backend Lapisan 4.

  • Migrasi ke instance Network Load Balancer (NLB) dan nonaktifkan client IP preservation di kelompok server. Setelah fitur ini dinonaktifkan, instance ECS dalam kelompok server dapat bertindak sebagai server backend sekaligus klien instance NLB. Untuk mendapatkan alamat IP sumber klien, aktifkan Proxy Protocol. Untuk informasi lebih lanjut, lihat Bagaimana instance ECS dapat bertindak sebagai server backend sekaligus klien instance NLB?.

  • Gunakan Alibaba Cloud DNS PrivateZone untuk mengonfigurasi resolusi nama domain privat sehingga nama domain layanan di-resolve ke alamat IP pribadi server backend. Permintaan kemudian mencapai server backend secara langsung melalui jaringan internal tanpa melewati instance CLB, yang menghilangkan kondisi loopback. Pendekatan ini berlaku ketika server backend mengakses layanan instance CLB yang terhubung dengannya menggunakan nama domain. Perhatikan bahwa permintaan melewati CLB dalam kasus ini dan tidak lagi mendapat manfaat dari load balancing atau pemeriksaan kesehatan. Gunakan pendekatan ini hanya untuk permintaan yang dimulai oleh server backend itu sendiri.

  • Modifikasi file hosts pada server tempat klien berjalan sehingga nama domain layanan mengarah ke alamat IP pribadi server backend. Efeknya sama seperti PrivateZone, dan pendekatan ini cocok untuk skenario di mana Anda hanya memerlukan solusi ini pada beberapa server individual. Karena file hosts harus dikelola di setiap server, gunakan PrivateZone sebagai gantinya jika Anda memiliki banyak server backend.

• Penanganan paket RST yang tidak tepat saat timeout koneksi

  Setelah koneksi TCP terbentuk, jika tidak ada aktivitas selama 900 detik, CLB mengirim paket RST ke klien dan server untuk menutup koneksi. Beberapa aplikasi mungkin tidak menangani paket RST dengan benar dan mungkin mencoba mengirim data melalui koneksi yang sudah ditutup, menyebabkan timeout aplikasi.

  Catatan

  Timeout default adalah 900 detik tetapi dapat disesuaikan sesuai kebutuhan.

Timeout koneksi HTTP dan HTTPS

• Koneksi persisten HTTP mendukung maksimal 100 permintaan berurutan. Setelah batas ini tercapai, CLB menutup koneksi.

• Timeout idle antara dua permintaan HTTP atau HTTPS pada koneksi persisten dapat dikonfigurasi dari 1 hingga 60 detik (dengan margin kesalahan 1 hingga 2 detik). Jika timeout ini terlampaui, koneksi TCP ditutup. Jika aplikasi Anda menggunakan koneksi persisten, kami menyarankan mengirim permintaan heartbeat setidaknya setiap 13 detik.

• Jabat tangan tiga arah TCP antara instance CLB dan instance ECS backend timeout setelah 5 detik. Jika jabat tangan timeout, CLB mencoba instance ECS berikutnya. Anda dapat mengidentifikasi masalah ini dengan memeriksa waktu respons upstream di log akses.

• Timeout permintaan (waktu yang dihabiskan instance CLB untuk menunggu respons dari instance ECS) dapat dikonfigurasi dari 1 hingga 180 detik. Jika timeout ini terlampaui, CLB biasanya mengembalikan kode status 504 atau 408 ke klien. Anda dapat mengidentifikasi masalah ini dengan memeriksa waktu respons upstream di log akses.

• Timeout penggunaan ulang sesi HTTPS adalah 300 detik. Setelah periode ini, klien yang sama harus melakukan jabat tangan SSL penuh lagi.

Apakah CLB secara otomatis mencoba ulang permintaan setelah timeout?

Tidak. Jika permintaan melebihi timeout permintaan yang dikonfigurasi pada pendengar (misalnya, default 60 detik), CLB menghentikan koneksi dan mengembalikan kode kesalahan 504 ke klien. CLB tidak secara otomatis mencoba ulang permintaan tersebut. Untuk menerapkan logika percobaan ulang, Anda harus mengimplementasikannya di sisi klien.

Mekanisme percobaan ulang implisit untuk pendengar Lapisan-7 HTTPS CLB

Saat server backend tidak merespons atau mengembalikan kesalahan pada pendengar Lapisan-7 HTTPS CLB, CLB secara otomatis memicu mekanisme percobaan ulang implisit. CLB mencoba secara berurutan server backend sehat lainnya. Percobaan ulang ini diprakarsai oleh CLB sendiri dan tidak bergantung pada klien. Saat terjadi timeout, CLB mencatat kesalahan 504 dan mencoba ulang ke node backend lain. Hanya hasil percobaan terakhir yang dikembalikan ke klien.

Lihat catatan percobaan ulang: Konsol CLB tidak menyediakan antarmuka khusus untuk menanyakan log percobaan ulang. Anda dapat melihat catatan percobaan ulang di log akses CLB. Beberapa nilai dalam bidang upstream_addr (dipisahkan koma) berfungsi sebagai bukti percobaan ulang. Beberapa nilai dalam upstream_response_time sesuai dengan waktu respons setiap percobaan. Misalnya, upstream_addr: 10.0.0.1:80, 10.0.0.2:80 menunjukkan bahwa CLB mencoba dua server backend secara berurutan.

Perilaku CLB saat klien memutus koneksi lebih awal

Tidak. CLB tidak menutup koneksi ke server backend selama operasi baca dan tulis.

Aktifkan koneksi persisten backend untuk CLB

Instance CLB tidak mendukung koneksi persisten backend. Untuk menggunakan fitur ini, buat instance ALB, konfigurasi pendengar HTTP atau HTTPS, dan aktifkan koneksi persisten backend untuk kelompok server ALB yang sesuai. Untuk informasi lebih lanjut, lihat Buat dan kelola kelompok server.

Atasi latency CLB yang tinggi

Mengakses layanan backend melalui instance CLB memperkenalkan latency tambahan yang kecil dibandingkan mengakses server backend secara langsung. Hal ini normal. Pendengar Lapisan 7 CLB menggunakan arsitektur reverse proxy (Tengine), yang menambahkan hop jaringan ekstra dan waktu pemrosesan protokol. Latency tambahan untuk pendengar Lapisan 4, yang menggunakan LVS untuk penerusan, biasanya lebih kecil.

Jika Anda mengalami latency yang sangat tinggi, ikuti langkah-langkah berikut untuk troubleshooting:

1. Aktifkan log akses dan analisis bidang latency: Aktifkan log akses CLB dan fokus pada bidang berikut:

   • request_time: Interval, dalam detik, dari saat CLB menerima paket permintaan pertama hingga mengembalikan respons.

   • upstream_response_time: Interval, dalam detik, dari saat koneksi ke server backend terbentuk hingga data sepenuhnya diterima dan koneksi ditutup.

2. Identifikasi sumber latency:

   • Jika upstream_response_time tinggi: Latency kemungkinan disebabkan oleh pemrosesan lambat di server backend. Periksa kinerja aplikasi backend, efisiensi kueri database, dan penggunaan sumber daya (CPU/memori), atau tambahkan lebih banyak server backend untuk mendistribusikan beban.

   • Jika request_time jauh lebih besar daripada upstream_response_time, latency mungkin berada di tautan jaringan dari klien ke CLB. Anda dapat menjalankan pengujian ping berkelanjutan atau melakukan pelacakan rute MTR dari klien ke alamat layanan CLB untuk troubleshooting masalah tautan jaringan.

3. Akses lintas wilayah: Jika klien dan instance CLB berada di wilayah berbeda, latency jaringan akibat jarak fisik tidak dapat dihindari. Kami menyarankan menggunakan Global Accelerator (GA) untuk mengoptimalkan pengalaman akses lintas wilayah.

Atasi kesalahan 502, 503, atau 504

Saat Anda mengakses layanan backend melalui instance CLB, kode kesalahan 502, 503, atau 504 biasanya menunjukkan bahwa permintaan tidak diproses dengan benar oleh server backend. Kode kesalahan tersebut berarti:

• 502 Bad Gateway: CLB tidak dapat meneruskan permintaan ke server backend atau menerima respons darinya. Penyebab umum termasuk layanan backend tidak dapat dijangkau atau semua pemeriksaan kesehatan gagal.

• 503 Service Temporarily Unavailable: Biasanya disebabkan oleh traffic yang melebihi batas atau server backend tidak tersedia. Kesalahan ini dikembalikan saat traffic instan melebihi batas spesifikasi instance CLB.

• 504 Gateway Timeout: Server backend timeout. Penyebab umum termasuk waktu pemrosesan yang lama di backend atau timeout saat membentuk koneksi ke server backend.

Langkah pertama: Periksa log akses

Pertama, aktifkan log akses CLB dan periksa bidang status (kode status yang dikembalikan CLB ke klien) dan upstream_status (kode status yang dikembalikan server backend ke CLB) di log:

• Jika status dan upstream_status sama, CLB kemungkinan meneruskan kode kesalahan langsung dari server backend. Selidiki mengapa server backend mengembalikan kesalahan ini.

• Jika upstream_status adalah "-" atau berbeda dari status, kesalahan dikembalikan oleh CLB. Rujuk poin berikut untuk troubleshooting.

Atasi kesalahan 502

• Semua pemeriksaan kesehatan server backend gagal: Saat semua server backend yang terkait dengan pendengar gagal dalam pemeriksaan kesehatan, CLB tidak dapat meneruskan permintaan dan malah mengembalikan kesalahan 502. Periksa status pemeriksaan kesehatan di konsol dan selidiki penyebab kegagalannya, seperti iptables atau perangkat lunak keamanan pihak ketiga yang memblokir blok CIDR sistem CLB 100.64.0.0/10, kode status pemeriksaan kesehatan yang tidak sesuai, atau path pemeriksaan kesehatan yang tidak ada. Untuk informasi lebih lanjut, lihat FAQ Pemeriksaan Kesehatan CLB.

• Backend mengembalikan kode kesalahan yang dikonversi CLB menjadi 502: Jika server backend mengembalikan kode kesalahan tertentu (seperti 504 atau 444), CLB mungkin mengembalikan kesalahan 502 ke klien. Periksa bidang upstream_status di log akses untuk mengonfirmasi kode status aktual yang dikembalikan backend dan selidiki penyebab kesalahan backend.

• Kesalahan layanan backend: Beban tinggi, respons yang salah format, atau penutupan koneksi yang tidak terduga di server backend juga dapat menyebabkan kesalahan 502. Periksa log server backend dan penggunaan sumber daya, seperti CPU dan memori.

Atasi kesalahan 503

• Traffic melebihi batas spesifikasi instance: CLB mengembalikan kesalahan 503 jika QPS, bandwidth, atau laju koneksi baru dari traffic masuk melebihi batas spesifikasi instance CLB saat ini. Anda dapat mengambil metrik ini dari Cloud Monitor.

• Traffic instan melebihi batas tetapi tidak ditampilkan di pemantauan: Cloud Monitor menampilkan data dengan granularitas per menit dan mungkin tidak menunjukkan lonjakan per detik. Periksa jumlah permintaan per detik di log akses. Jika upstream_status adalah "-", ini menunjukkan bahwa permintaan tidak dikirim ke server backend.

Atasi kesalahan 504

• Timeout respons backend: Jika server backend tidak merespons dalam periode timeout permintaan yang dikonfigurasi untuk pendengar, CLB mengembalikan kesalahan 504. Periksa bidang upstream_response_time di log akses untuk mengonfirmasi waktu respons aktual backend dan sesuaikan timeout permintaan pendengar yang sesuai.

• Timeout koneksi backend: Timeout untuk instance CLB menyelesaikan jabat tangan tiga arah TCP dengan instance ECS backend adalah 5 detik. Jika upstream_response_time di log akses terlalu lama, ini mungkin menunjukkan masalah koneksi dengan server backend. Kami menyarankan menangkap paket untuk menyelidiki penyebabnya.

• Beban backend tinggi: Penggunaan sumber daya tinggi (CPU, memori, dll.) di server backend dapat menyebabkan waktu respons melebihi periode timeout. Selidiki dan optimalkan kinerja layanan backend, atau tambahkan lebih banyak server backend untuk mendistribusikan beban.

Atasi masalah akses CLB

Jika Anda tidak dapat mengakses layanan setelah mengonfigurasi instance CLB, ikuti langkah-langkah berikut untuk troubleshooting secara berjenjang:

1. Verifikasi resolusi nama domain: Jika Anda mengakses layanan menggunakan nama domain, pastikan nama domain tersebut di-resolve dengan benar ke alamat layanan instance CLB. Anda dapat menggunakan perintah nslookup atau dig untuk memverifikasi resolusi. Resolusi nama domain yang salah adalah alasan umum kegagalan akses.

2. Verifikasi konfigurasi pendengar: Di konsol CLB, periksa apakah pendengar telah dibuat dan konfirmasi bahwa port dan protokol pendengar dikonfigurasi dengan benar. Jika pendengar tidak ada atau salah konfigurasi, CLB tidak dapat meneruskan permintaan.

3. Verifikasi status pemeriksaan kesehatan: Di konsol CLB, periksa status pemeriksaan kesehatan server backend. Jika semua server backend gagal dalam pemeriksaan kesehatan, CLB tidak dapat meneruskan permintaan.

4. Periksa pengaturan firewall: Periksa apakah iptables atau perangkat lunak keamanan pihak ketiga di server backend mengizinkan port layanan backend dan blok CIDR sistem CLB 100.64.0.0/10.

5. Verifikasi bahwa layanan backend berjalan dengan baik: Masuk langsung ke server backend dan konfirmasi bahwa layanan backend itu sendiri responsif dengan menjalankan telnet <alamat IP pribadi server backend> <port> (Lapisan 4) atau curl -I http://<alamat IP pribadi server backend> (Lapisan 7).

6. Atasi tautan jaringan: Uji akses ke alamat layanan CLB dari lingkungan jaringan yang berbeda. Jika hanya jaringan lokal Anda yang terpengaruh, Anda dapat menjalankan pengujian ping berkelanjutan atau menggunakan pelacakan rute MTR untuk investigasi lebih lanjut.

Akses melalui IP tetapi tidak melalui nama domain

Alasan paling umum adalah nama domain belum menyelesaikan Pendaftaran ICP-nya.

Sesuai peraturan, saat nama domain digunakan untuk akses publik di Tiongkok daratan, nama domain tersebut harus memiliki Pendaftaran ICP yang valid. Akses ke domain tanpa Pendaftaran ICP diblokir, menghasilkan kode status 403 atau reset koneksi.

Kami menyarankan Anda mengikuti langkah-langkah berikut untuk troubleshooting dan menyelesaikan masalah:

1. Verifikasi status Pendaftaran ICP: Masuk ke Sistem Pendaftaran ICP Alibaba Cloud untuk memeriksa apakah nama domain Anda telah menyelesaikan Pendaftaran ICP. Jika belum, selesaikan proses tersebut terlebih dahulu. Untuk informasi lebih lanjut, lihat Proses Pendaftaran ICP.

2. Periksa apakah Anda perlu mentransfer Pendaftaran ICP Anda: Jika nama domain Anda memiliki Pendaftaran ICP dengan penyedia layanan cloud lain tetapi Anda menggunakannya dengan Alibaba Cloud untuk pertama kalinya, Anda juga harus menyelesaikan transfer Pendaftaran ICP untuk mengaitkan informasi pendaftaran dengan Alibaba Cloud. Kegagalan menyelesaikan transfer ini juga dapat mengakibatkan akses diblokir.

3. Kesampingkan penyebab lain: Jika nama domain memiliki Pendaftaran ICP dan transfer Pendaftaran ICP juga telah selesai, periksa apakah resolusi nama domain mengarah dengan benar ke alamat layanan CLB (Anda dapat menggunakan perintah nslookup atau dig untuk memverifikasi), dan apakah konfigurasi port dan protokol pendengar CLB sesuai dengan metode akses nama domain.

Dampak kontrol akses terhadap traffic internal

Ya. Kontrol akses diterapkan di tingkat pendengar dan memengaruhi traffic internal maupun publik. Jika Anda mengonfigurasi daftar izin yang hanya mengizinkan alamat IP publik tertentu, permintaan dari alamat IP internal yang tidak ada dalam daftar izin akan diblokir. Untuk menghindari gangguan layanan internal, kami menyarankan menambahkan blok CIDR internal yang relevan ke daftar izin atau menggunakan Cloud Firewall untuk membatasi akses publik ke EIP.

Atasi timeout permintaan selama uji stres

Saat Anda melakukan uji stres pada CLB Lapisan 7, jika Anda menerima kode status 504 atau timeout permintaan, dan upstream_response_time di log berkumpul sekitar 5 detik, masalah ini biasanya merupakan timeout koneksi yang disebabkan oleh gagalnya jabat tangan tiga arah TCP antara CLB dan server backend. Alasan umum untuk ini adalah tabel pelacakan koneksi (nf_conntrack) di server backend penuh, yang menyebabkan server menjatuhkan paket untuk koneksi baru.

Masuk ke server backend dan periksa log /var/log/messages. Anda dapat mengonfirmasi masalah ini jika muncul pesan kesalahan berikut:

nf_conntrack: table full, dropping packet

Solusi: Sesuaikan nilai parameter nf_conntrack berikut berdasarkan kebutuhan layanan aktual Anda:

sysctl -w net.netfilter.nf_conntrack_max=1048576
sysctl -w net.netfilter.nf_conntrack_buckets=262144
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=3600

Catatan: Perintah di atas hanya berlaku sementara. Perubahan akan hilang setelah instance direstart. Untuk membuat perubahan permanen, tulis parameter ke /etc/sysctl.conf.

Dampak kegagalan backend terhadap pendengar bersama

Skenario: Anda memiliki beberapa website, seperti website statis www.example.com dan website dinamis app.example.com, yang terhubung ke pendengar CLB yang sama. Saat database backend untuk website dinamis gagal, website statis juga menjadi tidak dapat diakses dan mengembalikan kesalahan HTTP 502.

Penyebab: Kedua situs berbagi pendengar yang sama, dan Health Check Domain Name pendengar dikonfigurasi dengan nama domain situs dinamis. Saat backend situs dinamis gagal, semua server backend gagal dalam pemeriksaan kesehatan. Akibatnya, CLB berhenti meneruskan traffic ke backend, yang memengaruhi semua situs yang dikonfigurasi di bawah pendengar tersebut.

Solusi: Gunakan instance CLB terpisah untuk menyediakan load balancing untuk situs dinamis dan statis guna mencapai isolasi bisnis. Dengan cara ini, kegagalan di situs dinamis tidak akan memengaruhi situs statis.

Alasan kegagalan persistensi sesi

• Persistensi sesi tidak diaktifkan: Periksa apakah persistensi sesi diaktifkan dalam konfigurasi pendengar.

• Masalah pendengar HTTP/HTTPS: Untuk pendengar HTTP atau HTTPS, CLB tidak dapat menyisipkan cookie yang diperlukan untuk persistensi sesi ke respons 4xx.

  Solusi: Beralih ke pendengar TCP, yang menggunakan alamat IP sumber klien untuk mempertahankan persistensi sesi. Untuk keandalan tambahan, Anda juga dapat menyisipkan cookie di instance ECS backend dan menambahkan pemeriksaan validasi cookie.

• Masalah pengalihan 302: Pengalihan 302 dapat mengubah string SERVERID yang digunakan untuk persistensi sesi.

  Jika instance ECS backend mengeluarkan pengalihan 302, ini dapat mengubah string SERVERID dalam cookie yang disuntikkan CLB, sehingga memutus persistensi sesi.

  Cara troubleshooting: Gunakan alat developer browser atau packet sniffer untuk menangkap permintaan dan respons. Analisis paket untuk memeriksa respons pengalihan 302 dan bandingkan string SERVERID dalam cookie sebelum dan sesudah pengalihan.

  Solusi: Beralih ke pendengar TCP, yang menggunakan alamat IP sumber klien untuk mempertahankan persistensi sesi. Untuk keandalan tambahan, Anda juga dapat menyisipkan cookie di instance ECS backend dan menambahkan pemeriksaan validasi cookie.

• Timeout persistensi sesi terlalu singkat: Jika nilai timeout diatur terlalu rendah, persistensi sesi mungkin gagal.

Menampilkan string persistensi sesi

Anda dapat menggunakan alat developer browser (F12) untuk memeriksa apakah header respons berisi string SERVERID atau kata kunci kustom. Atau, jalankan perintah curl www.example.com -c /tmp/cookie123 untuk menyimpan cookie, lalu jalankan curl www.example.com -b /tmp/cookie123 untuk mengirim cookie pada permintaan berikutnya.

Menguji persistensi sesi dengan curl

1. Buat halaman uji.

   Di setiap instance ECS backend, buat halaman uji yang menampilkan alamat IP pribadi instance tersebut. Alamat ini mengidentifikasi server mana yang menangani permintaan. Jika alamat IP konsisten di beberapa permintaan, persistensi sesi berfungsi.

2. Jalankan perintah curl pada sistem Linux.

   Asumsikan alamat IP layanan CLB adalah 10.170.XX.XX, dan URL halaman uji adalah http://10.170.XX.XX/check.jsp.

   1. Masuk ke server Linux yang akan Anda gunakan untuk pengujian.

   2. Jalankan perintah berikut untuk mengambil cookie dari load balancer.

      curl -c test.cookie http://10.170.XX.XX/check.jsp

      Catatan

      Secara default, CLB menggunakan penyuntikan cookie untuk persistensi sesi. Namun, curl tidak menyimpan atau mengirim cookie secara default. Anda harus menyimpan cookie sebelum pengujian. Jika tidak, permintaan curl berikutnya akan dikirim tanpa cookie, menyebabkan routing acak, yang mungkin membuat Anda salah menyimpulkan bahwa persistensi sesi tidak berfungsi.

   3. Jalankan perintah berikut untuk melakukan pengujian berkelanjutan.

      for ((a=1;a<=30;a++));
          do curl  -b test.cookie http://10.170.XX.XX/check.jsp  | grep '10.170.XX.XX';
          sleep 1;
      done

      Catatan

      Dalam a≤30, 30 adalah jumlah pengujian berulang dan dapat dimodifikasi sesuai kebutuhan. Perintah grep '10.170.XX.XX' menyaring informasi IP yang ditampilkan. Ubah 10.170.XX.XX menjadi alamat IP pribadi instance ECS backend.

   4. Amati alamat IP yang dikembalikan oleh pengujian. Jika semua respons berasal dari alamat IP pribadi server backend yang sama, persistensi sesi berfungsi dengan benar. Jika tidak, persistensi sesi tidak berfungsi dengan benar.

Konfigurasi cookie backend untuk mode Rewrite Cookie

Jika Anda memilih mode Rewrite Cookie untuk persistensi sesi Lapisan 7, Anda harus mengonfigurasi cookie dengan nama yang sama di server backend Anda. Nama cookie harus identik dengan yang dikonfigurasi di konsol CLB. Contoh berikut menunjukkan cara mengonfigurasi ini di server web umum:

server {
    listen 8080;
    server_name wqwq.example.com;
    location / {
        add_header Set-Cookie name=xxxx;
        root   html;
        index  index.html index.htm;
    }
}

Atasi beban server yang tidak merata

Jika Anda memiliki beberapa server backend yang terhubung ke instance CLB dan satu server memiliki beban yang jauh lebih tinggi daripada yang lain, ikuti langkah-langkah berikut untuk troubleshooting:

1. Periksa apakah persistensi sesi diaktifkan: Pendengar HTTP/HTTPS CLB mendukung persistensi sesi melalui penyuntikan cookie. Saat persistensi sesi diaktifkan, semua permintaan dari klien yang sama diarahkan ke server backend yang sama. Jika beberapa klien menghasilkan banyak permintaan, ini memusatkan traffic pada server backend tertentu, menyebabkan beban tidak merata.

2. Nonaktifkan persistensi sesi untuk distribusi merata: Jika aplikasi Anda tidak bergantung pada status sesi (seperti cookie atau status login), nonaktifkan persistensi sesi untuk pendengar tersebut. Setelah dinonaktifkan, CLB mendistribusikan permintaan secara merata ke semua server backend berdasarkan algoritma penjadwalan yang dikonfigurasi, seperti round-robin berbobot. Lakukan tindakan ini selama jam sepi dan segera verifikasi bahwa aplikasi Anda tetap tersedia. Menonaktifkan persistensi sesi akan memengaruhi layanan stateful, seperti keranjang belanja atau login persisten. Evaluasi ketergantungan aplikasi Anda pada persistensi sesi sebelum melanjutkan.

3. Periksa beban aplikasi di server backend: Meskipun CLB mendistribusikan traffic secara merata, perbedaan penggunaan CPU, memori, atau sumber daya lain di server backend itu sendiri dapat menyebabkan beberapa server mengalami beban lebih tinggi. Masuk ke setiap server backend, bandingkan penggunaan sumber daya aplikasi Anda, dan periksa bottleneck kinerja.

Gaya gagal dimuat melalui HTTPS

Gejala:

Anda memiliki pendengar HTTP dan HTTPS, keduanya menggunakan server backend yang sama. Saat Anda mengakses website melalui pendengar HTTP, tampilannya benar. Namun, saat Anda mengakses website melalui pendengar HTTPS, tata letaknya rusak.

Penyebab:

Load balancer tidak memblokir file JavaScript (JS) secara default. Masalah ini dapat disebabkan oleh hal berikut:

• Sertifikat tidak kompatibel dengan tingkat keamanan browser.

• Sertifikat berasal dari penyedia pihak ketiga yang tidak tepercaya. Hubungi penerbit untuk menyelesaikan masalah ini.

Solusi:

1. Saat membuka website, ikuti petunjuk browser untuk memuat skrip.

2. Tambahkan sertifikat yang sesuai ke trust store klien.

Sertifikat server backend untuk pengalihan HTTP ke HTTPS

Tidak. Anda hanya perlu mengonfigurasi sertifikat pada pendengar HTTPS instance CLB. Untuk informasi lebih lanjut, lihat Konfigurasi sertifikat SSL.

Browser menampilkan masa kedaluwarsa sertifikat lama setelah pembaruan

Hal ini biasanya terjadi jika instance CLB terintegrasi secara transparan dengan WAF 2.0, dan sertifikat WAF belum diperbarui. WAF menyinkronkan sertifikat dari CLB secara berkala. Untuk memicu sinkronisasi segera, Anda dapat menonaktifkan lalu mengaktifkan kembali pengalihan traffic di konsol WAF untuk memaksa refresh sertifikat. Tindakan ini mungkin menyebabkan gangguan layanan singkat, berlangsung 1 hingga 2 detik.

Versi protokol HTTP untuk akses server backend

• Jika permintaan klien menggunakan HTTP/1.1 atau HTTP/2.0, pendengar Lapisan-7 berkomunikasi dengan server backend menggunakan HTTP/1.1.

• Jika permintaan klien menggunakan versi protokol selain HTTP/1.1 atau HTTP/2.0, pendengar Lapisan-7 berkomunikasi dengan server backend menggunakan HTTP/1.0.

Mengambil versi protokol klien

Ya.

Pembatasan laju berbasis URL

CLB tidak mendukung pembatasan laju berbasis URL, hanya pembatasan bandwidth di tingkat pendengar.

ALB mendukung pembatasan laju berbasis URL. Anda dapat mengonfigurasi aturan pengalihan pendengar untuk menerapkan pembatasan QPS pada path tertentu. Fitur ini harus digunakan bersama dengan aksi "Forward to".

Apakah CLB mendukung SSE (Server-Sent Events)?

SSE (Server-Sent Events) adalah teknologi berbasis HTTP yang memungkinkan server mendorong data ke klien secara unidireksional. Teknologi ini umum digunakan dalam skenario streaming data real-time.

• CLB Lapisan 7 mendukung protokol SSE.

• CLB Lapisan 4 tidak mendukung protokol SSE.

Batasan penggunaan: Pendengar Lapisan 7 CLB mendukung SSE, tetapi tidak mendukung penggunaan SSE melalui koneksi persisten HTTP (keep-alive). Anda harus menggunakan koneksi singkat.

Bidang Transfer-Encoding: chunked tersebut

Transfer-Encoding: chunked adalah bidang protokol HTTP standar yang menunjukkan bahwa badan pesan dikirim menggunakan transfer chunked. CLB Lapisan-7 adalah reverse proxy yang dibangun di atas Tengine. Saat meneruskan permintaan ke server backend, ia menggunakan transfer chunked. Oleh karena itu, server backend menerima bidang ini di header permintaan. Ini adalah perilaku normal untuk reverse proxy dan tidak memengaruhi layanan Anda. CLB Lapisan-4 hanya meneruskan traffic dan tidak menambahkan bidang ini.

Bidang header respons yang dihapus

Untuk menerapkan persistensi sesi, CLB menghapus bidang seperti Date, Server, X-Pad, dan X-Accel-Redirect dari header respons. Untuk mempertahankan bidang-bidang ini, Anda dapat menambahkan awalan ke header respons kustom Anda, seperti xl-server, atau beralih ke pendengar TCP Lapisan-4.

proxy_buffering dan proxy_cache

Fitur proxy_buffering dan proxy_cache tidak diaktifkan untuk CLB. CLB tidak melakukan buffering atau caching data permintaan atau respons. Sebaliknya, ia meneruskan permintaan klien langsung ke server backend dalam mode penerusan transparan. Ini adalah perilaku default CLB dan tidak memerlukan konfigurasi tambahan.

Apakah CLB mendukung forward proxy?

CLB tidak mendukung forward proxy. CLB adalah load balancer reverse proxy: ia mendistribusikan permintaan klien ke server backend, tetapi tidak dapat memproksi akses klien ke sumber daya eksternal seperti yang dilakukan forward proxy. Jika Anda memerlukan kemampuan forward proxy, bangun forward proxy Anda sendiri menggunakan layanan seperti Nginx.

Aktifkan perlindungan WAF untuk CLB

Dampak menonaktifkan ENI publik

Jika instance ECS memiliki IP publik, menonaktifkan antarmuka jaringan elastis publiknya memengaruhi layanan load balancer.

Hal ini karena jika antarmuka jaringan elastis publik ada, rute default mengarahkan traffic melalui jaringan publik. Menonaktifkan antarmuka mencegah paket respons dikirim kembali, yang mengganggu layanan load balancer. Kami menyarankan untuk tidak menonaktifkan antarmuka jaringan elastis publik. Jika Anda harus menonaktifkannya, ubah rute default ke jaringan pribadi untuk menghindari gangguan layanan. Namun, pertimbangkan apakah layanan Anda bergantung pada akses jaringan publik, misalnya untuk mengakses RDS.

Dukungan untuk permintaan klien dengan bidang TOA

Tidak. Bidang TCP Option Address (TOA) yang disediakan klien bertentangan dengan bidang TOA yang digunakan load balancer untuk komunikasi internal. Konflik ini mencegah server backend mendapatkan alamat IP asli klien.