Server Load Balancer:FAQ tentang listener CLB

Apakah CLB mendukung pengalihan port?

Ya.

CLB mendukung pengalihan port. Contohnya, lihat Mengalihkan permintaan HTTP ke HTTPS menggunakan instans CLB.

Apakah listener Lapisan 4 CLB mendukung range port?

Tidak. Untuk mengonfigurasi listener TCP atau UDP untuk range port, buat instans Network Load Balancer (NLB) dan aktifkan fitur full-port pada listener-nya. Untuk informasi selengkapnya, lihat Meneruskan traffic melalui beberapa port dengan listener full-port NLB.

Catatan konfigurasi port listener

Beberapa penyedia layanan menandai port seperti 25, 135, 139, 444, 445, 5800, dan 5900 sebagai high-risk dan memblokirnya secara default. Bahkan jika Anda mengizinkan traffic pada port-port tersebut dalam aturan security group, pengguna di wilayah yang dibatasi tidak dapat mengakses layanan Anda. Kami menyarankan agar Anda menggunakan port non-high-risk lainnya untuk layanan Anda.

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

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

Mengonfigurasi listener untuk WebSocket

• Untuk server backend yang menggunakan WebSocket, Anda dapat mengonfigurasi listener TCP atau HTTP.

• Untuk server backend yang menggunakan WebSocket Secure, Anda dapat mengonfigurasi listener TCP atau HTTPS.

Dampak perubahan konfigurasi listener

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

Mengakses URL dengan karakter khusus

Karakter khusus dalam URL harus di-URL-encoded agar dapat diakses dengan benar. Misalnya, simbol hash (#) harus di-encode sebagai %23, dan URL harus dimasukkan sebagai http://www.example.com/%23/. Untuk aturan encoding lengkap, lihat RFC 3986.

Paket hilang meskipun bandwidth tersedia

Masalah ini dapat terjadi karena alasan berikut:

• Data pemantauan bandwidth Alibaba Cloud dirata-ratakan selama satu menit. Oleh karena itu, grafik mungkin menunjukkan penggunaan di bawah batas meskipun terjadi lonjakan lalu lintas sesaat yang melebihi batas tersebut, karena rata-rata satu menit tetap berada dalam batas.

• CLB menggunakan kluster server untuk mendistribusikan dan meneruskan permintaan. Bandwidth maksimum yang ditentukan dibagi bersama oleh server-server tersebut. Jika jumlah data yang diunduh oleh koneksi klien tunggal melebihi ambang batas server tunggal, paket mungkin di-drop. Untuk informasi lebih lanjut tentang cara menghitung batas atas traffic unduhan pada koneksi tunggal, lihat Gagal mencapai bandwidth maksimum.

Traffic yang dipantau melebihi batas laju

Sistem load balancing menggunakan penerapan kluster untuk menyediakan layanan bagi instans CLB dan menerapkan pembatasan laju terdistribusi. Batas laju puncak untuk node tunggal = Bandwidth total yang dikonfigurasi pada load balancer/(N-1), di mana N adalah jumlah node dalam kluster. Oleh karena itu, batas laju keseluruhan sedikit lebih tinggi daripada nilai yang dikonfigurasi.

Gagal mencapai bandwidth maksimum

• Skenario: Koneksi ke instans CLB publik berbayar-per-bandwidth mungkin tidak mencapai bandwidth maksimum yang dikonfigurasi dalam skenario tertentu, seperti uji stres klien tunggal atau transfer paket data yang sangat besar.

• Penyebab:

  CLB mendistribusikan permintaan eksternal di seluruh kluster server, dan bandwidth maksimum yang dikonfigurasi dibagi bersama oleh server-server tersebut.

  Traffic unduhan maksimum untuk koneksi tunggal dihitung menggunakan rumus berikut: Kecepatan unduh puncak per koneksi = Bandwidth total yang dikonfigurasi / (N-1). Dalam rumus ini, N adalah jumlah sub-node dalam kluster. Nilai N adalah 4 untuk listener Lapisan-4 dan 8 untuk listener Lapisan-7. Sebagai contoh, jika Anda menetapkan batas bandwidth 10 Mbps di Konsol, bandwidth total dapat mencapai 10 Mbps ketika beberapa klien mengunduh data secara bersamaan. Kecepatan unduh maksimum untuk klien tunggal adalah 10/(4-1) = 3,33 Mbps.

• Saran:

  • Gunakan metode pengukuran bayar-berdasarkan-transfer-data untuk instans CLB publik.

  • Gunakan instans Application Load Balancer (ALB) atau Network Load Balancer (NLB) dengan alamat IP elastis (EIP) dan paket bandwidth EIP. Solusi ini menyediakan elastisitas yang cukup dan menghilangkan batasan ini.

Gagal mencapai QPS maksimum

• Skenario: Dalam skenario dengan jumlah kecil koneksi persisten, tidak semua server dalam grup penerusan dialokasikan untuk menanganinya. Akibatnya, instans CLB tidak dapat mencapai QPS maksimumnya.

• Penyebab:

  CLB menggunakan kluster server untuk menyediakan layanan. Semua permintaan eksternal didistribusikan di seluruh server ini untuk diteruskan. Oleh karena itu, QPS maksimum instans CLB dibagi bersama oleh server-server dalam kluster.

  QPS maksimum untuk server backend tunggal dihitung menggunakan rumus berikut: QPS maksimum server backend tunggal = Total QPS instans / (N - 1). N adalah jumlah server backend dalam grup server. Sebagai contoh, instans CLB spesifikasi slb.s1.small menyediakan total 1.000 QPS. Jika grup server berisi 8 server backend, QPS maksimum untuk server backend tunggal adalah 1.000 / (8 - 1) = 142 QPS.

  Catatan

• Saran:

  • Gunakan koneksi singkat dari klien tunggal untuk uji stres.

  • Kurangi penggunaan ulang koneksi berdasarkan kebutuhan bisnis Anda.

  • Tingkatkan spesifikasi instans CLB. Untuk informasi selengkapnya, lihat Tingkatkan atau turunkan spesifikasi instans pay-as-you-go (berbayar-per-spesifikasi).

  • Gunakan instans ALB. Solusi ini menyediakan elastisitas yang cukup.

Gagal mencapai laju koneksi baru puncak

• Skenario: Saat Anda membeli instans CLB dan memilih metode penagihan berbayar-per-spesifikasi, laju koneksi baru (CPS) mungkin tidak mencapai tingkat yang tercantum dalam spesifikasi dalam skenario tertentu, seperti uji stres klien tunggal atau traffic dari sumber tunggal.

  Catatan

• Penyebab:

  CLB menggunakan arsitektur penerapan kluster untuk memastikan ketersediaan tinggi dan skalabilitas. Permintaan koneksi masuk didistribusikan di antara beberapa server dalam kluster. Oleh karena itu, CPS puncak instans CLB dibagi bersama oleh server-server ini.

  Rumus untuk CPS puncak server tunggal adalah: CPS puncak per server = Total CPS instans / (N-1), di mana N adalah jumlah server dalam grup penerusan.

  Sebagai contoh, jika Anda membeli instans CLB spesifikasi slb.s1.small, CPS-nya adalah 3.000. Saat beberapa klien mengakses instans secara konkuren, CPS keseluruhan dapat mencapai 3.000. Jika jumlah server adalah 4, batas CPS untuk server tunggal adalah 3.000 / (4 - 1) = 1.000 CPS.

• Saran:

  • Ubah metode penagihan menjadi pay-as-you-go. Instans CLB pay-as-you-go tidak memerlukan spesifikasi tertentu dan menawarkan batas kinerja yang lebih tinggi daripada sebagian besar instans berbasis spesifikasi, yang membantu mencegah bottleneck kinerja.

  • Tingkatkan ke Network Load Balancer (NLB): Untuk skenario dengan konkurensi tinggi dan laju koneksi baru yang tinggi, kami merekomendasikan penggunaan NLB. NLB menawarkan kinerja dan elastisitas yang unggul dibandingkan CLB. Satu instans NLB mendukung 100 juta koneksi bersamaan, menjadikannya ideal untuk skenario skala besar dan membantu Anda menghindari batasan CPS CLB.

Range timeout koneksi berdasarkan listener

• Timeout koneksi listener TCP: 10 hingga 900 detik.

• HTTP Listener:

  • Timeout koneksi idle: 1 hingga 60 detik.

  • Timeout permintaan: 1 hingga 180 detik.

• Listener HTTPS:

  • Timeout koneksi idle: 1 hingga 60 detik.

  • Timeout permintaan: 1 hingga 180 detik.

Timeout koneksi ke alamat layanan CLB

Masalah berikut dapat menyebabkan timeout koneksi ke alamat layanan CLB:

• Alamat layanan berada di bawah perlindungan keamanan.

  Ini termasuk blackholing traffic, scrubbing, dan perlindungan Web Application Firewall (WAF). Setelah koneksi terbentuk, WAF mungkin mengirim paket RST ke klien dan server backend.

• Kehabisan Port Klien

  Hal ini sering terjadi selama uji stres. Kehabisan port klien dapat menyebabkan kegagalan koneksi. Secara default, load balancer menghapus atribut timestamp koneksi TCP, sehingga mencegah fitur tw_reuse kernel Linux—yang memungkinkan penggunaan ulang koneksi dalam status TIME_WAIT—berfungsi. Akibatnya, terjadi penumpukan koneksi TIME_WAIT dan kekurangan port klien.

  Solusi: Gunakan koneksi persisten alih-alih koneksi singkat di sisi klien. Tutup koneksi dengan mengirim paket RST (dengan mengatur atribut socket SO_LINGER) alih-alih paket FIN.

• Antrian accept server backend penuh

  Jika antrian accept server backend penuh, server tidak membalas dengan paket SYN-ACK, menyebabkan klien mengalami timeout.

  Nilai default net.core.somaxconn adalah 128. Evaluasi traffic layanan Anda dan sesuaikan nilai ini agar memenuhi kebutuhan aktual Anda. Kemudian, jalankan perintah sysctl -w net.core.somaxconn=<nilai_baru> untuk mengubah parameter ini dan restart aplikasi di server backend.

• Mengakses alamat layanan load balancer Lapisan 4 dari server backend-nya sendiri

  Listener Lapisan 4 (TCP/UDP) tidak mengizinkan server backend mengakses alamat layanannya sendiri melalui load balancer. Konfigurasi ini akan menyebabkan kegagalan koneksi. Skenario umum adalah ketika aplikasi backend mengalihkan ke alamat layanan CLB dengan membuat URL.

  Solusi:

  • Akses layanan dari klien berbeda, bukan dari server backend load balancer Lapisan 4.

  • Migrasi ke Network Load Balancer (NLB) dan nonaktifkan fitur Client IP Preservation dalam grup server. Hal ini memungkinkan instance ECS dalam grup server bertindak sebagai server backend dan klien sekaligus. Untuk mendapatkan alamat IP sumber klien, aktifkan Proxy Protocol. Untuk informasi selengkapnya, lihat Bagaimana instance ECS dapat bertindak sebagai server backend dan klien sekaligus di NLB?.

• Penanganan paket RST yang tidak tepat untuk timeout koneksi

  Jika koneksi TCP idle selama 900 detik, load balancer mengirim paket RST ke klien dan server untuk menutupnya. Beberapa aplikasi menangani paket RST ini secara tidak tepat dan mungkin mencoba mengirim data pada koneksi yang sudah ditutup, menyebabkan timeout aplikasi.

  Catatan

  900 detik adalah nilai default sistem dan dapat disesuaikan sesuai kebutuhan.

Timeout koneksi HTTP dan HTTPS

• Untuk koneksi HTTP persisten, maksimal 100 permintaan berurutan dapat dikirim. Koneksi ditutup setelah batas ini terlampaui.

• Timeout idle antara dua permintaan HTTP atau HTTPS melalui koneksi persisten dapat dikonfigurasi dari 1 hingga 60 detik (dengan potensi kesalahan 1 hingga 2 detik). Koneksi TCP ditutup setelah timeout. Jika Anda memerlukan koneksi persisten, coba kirim permintaan heartbeat dalam waktu 13 detik.

• Timeout untuk jabat tangan tiga arah TCP antara load balancer dan instance ECS backend adalah 5 detik. Jika jabat tangan mengalami timeout, CLB memilih instance ECS berikutnya. Anda dapat mengidentifikasi hal ini dengan memeriksa waktu respons upstream di log akses.

• Timeout respons load balancer untuk instance ECS dapat dikonfigurasi dari 1 hingga 180 detik. Setelah periode ini, kode status 504 atau 408 biasanya dikembalikan ke klien. Memeriksa waktu respons upstream di log akses dapat membantu menemukan masalah.

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

Perilaku koneksi backend saat klien terputus

Load balancer tidak memutus koneksi dari server backend selama operasi baca dan tulis.

Mengaktifkan koneksi persisten ke server backend

Classic Load Balancer (CLB) tidak mendukung koneksi persisten ke server backend. Untuk fungsionalitas ini, gunakan instans Application Load Balancer (ALB), konfigurasikan listener HTTP atau HTTPS, dan aktifkan koneksi persisten di grup server ALB yang sesuai. Untuk informasi selengkapnya, lihat Buat dan kelola grup server.

Memecahkan masalah latensi tinggi pada CLB

Mengakses layanan melalui CLB memperkenalkan latensi yang sedikit lebih tinggi dibandingkan mengakses server backend secara langsung; hal ini diharapkan. Listener CLB Lapisan 7 menggunakan arsitektur reverse proxy (Tengine), di mana permintaan diteruskan oleh CLB. Hal ini menambah latensi dari hop jaringan tambahan dan pemrosesan protokol. Listener Lapisan 4 menggunakan LVS untuk penerusan, dan latensi tambahan biasanya minimal.

Jika latensi sangat tinggi, ikuti langkah-langkah berikut untuk troubleshooting:

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

   • request_time: Interval waktu dalam detik sejak CLB menerima paket permintaan pertama hingga mengembalikan respons.

   • upstream_response_time: Waktu dalam detik antara pembentukan koneksi dengan backend dan penutupan koneksi setelah menerima respons lengkap.

2. Identifikasi sumber latensi:

   • Jika upstream_response_time tinggi, latensi biasanya disebabkan oleh pemrosesan lambat di server backend. Periksa kinerja aplikasi backend Anda, efisiensi kueri database, dan penggunaan resource seperti CPU dan memori, atau tambahkan lebih banyak server backend untuk mendistribusikan beban.

   • Jika request_time jauh lebih besar daripada upstream_response_time, latensi kemungkinan berada di tautan jaringan dari klien ke CLB. Anda dapat menjalankan tes ping terus-menerus atau jejak rute MTR dari klien ke alamat layanan CLB untuk memecahkan masalah tautan jaringan.

3. Skenario akses lintas wilayah: Jika klien dan instans CLB berada di wilayah berbeda, latensi jaringan akibat jarak fisik tidak dapat dihindari. Kami merekomendasikan penggunaan layanan Global Accelerator (GA) untuk mengoptimalkan pengalaman akses lintas wilayah.

Memecahkan masalah error 502, 503, dan 504

Menerima error 502, 503, atau 504 saat mengakses layanan melalui CLB biasanya menunjukkan bahwa server backend tidak memproses permintaan dengan benar. Arti kode error ini adalah sebagai berikut:

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

• 503 Service Temporarily Unavailable: Hal ini biasanya disebabkan oleh traffic yang melebihi batas atau server backend yang tidak tersedia. Kode error ini dikembalikan ketika traffic instan permintaan melebihi batas spesifikasi instans CLB.

• 504 Gateway Time-out: Respons server backend mengalami timeout. Penyebab umum adalah waktu pemrosesan yang lama di backend atau timeout koneksi server backend.

Langkah 1: Periksa log akses

Kami menyarankan agar Anda terlebih dahulu mengaktifkan log akses CLB dan memeriksa bidang berikut di log: status (kode status yang dikembalikan CLB ke klien) dan upstream_status (kode status yang dikembalikan server backend ke CLB).

• Jika status sama dengan upstream_status, kemungkinan besar CLB langsung meneruskan kode status abnormal dari server backend. Anda harus terlebih dahulu menyelidiki mengapa server backend mengembalikan kode status ini.

• Jika upstream_status adalah "-" atau berbeda dari status, CLB mengembalikan kode error. Anda dapat merujuk pada poin berikut untuk troubleshooting.

Memecahkan masalah error 502

• Semua server backend gagal pemeriksaan kesehatan: Saat semua server backend yang terkait dengan listener gagal pemeriksaan kesehatan, CLB tidak dapat meneruskan permintaan dan mengembalikan error 502. Periksa status pemeriksaan kesehatan di Konsol dan pecahkan penyebab kegagalan, seperti security group yang tidak mengizinkan traffic dari 100.64.0.0/10 (rentang alamat sistem CLB), konfigurasi kode status pemeriksaan kesehatan yang tidak sesuai, atau path pemeriksaan kesehatan yang tidak ada. Lihat FAQ Pemeriksaan Kesehatan CLB.

• CLB mengonversi kode status error backend menjadi 502: Jika server backend mengembalikan kode status error tertentu, seperti 504 atau 444, CLB mungkin mengembalikan error 502 ke klien. Periksa bidang upstream_status di log akses untuk mengidentifikasi kode status aktual yang dikembalikan server backend dan pecahkan error server backend.

• Error layanan backend: Error 502 juga dapat disebabkan oleh beban tinggi di server backend, format respons abnormal, atau koneksi yang ditutup secara tidak tepat. Periksa log server backend dan penggunaan resource, seperti CPU dan memori.

Memecahkan masalah error 503

• Traffic melebihi batas spesifikasi instans: Error 503 dikembalikan saat QPS, bandwidth, atau jumlah koneksi baru untuk traffic masuk melebihi batas spesifikasi saat ini. Anda dapat memperoleh metrik pemantauan ini dari CloudMonitor.

• Traffic instan melebihi batas tetapi tidak ditampilkan di pemantauan: CloudMonitor menampilkan data dengan granularitas satu menit dan mungkin tidak mencerminkan lonjakan traffic yang melebihi batas dalam satu detik. Anda dapat memeriksa jumlah permintaan per detik di log akses. Saat upstream_status di log adalah "-", hal ini menunjukkan bahwa permintaan tidak dikirim ke server backend.

Memecahkan masalah error 504

• Timeout respons backend: Jika server backend tidak mengembalikan respons dalam periode timeout koneksi yang dikonfigurasi untuk listener, CLB mengembalikan error 504. Kami menyarankan agar Anda memeriksa bidang upstream_response_time di log akses untuk mengonfirmasi waktu respons aktual server backend, dan sesuaikan periode timeout koneksi listener yang sesuai.

• Timeout koneksi backend: Timeout untuk jabat tangan tiga arah TCP antara instans CLB dan instance ECS backend adalah 5 detik. Jika upstream_response_time di log akses terlalu lama, hal ini mungkin menunjukkan error koneksi dengan server backend. Anda dapat mengambil paket untuk menyelidiki penyebabnya.

• Beban backend tinggi: Penggunaan resource tinggi di server backend, seperti CPU atau memori, dapat menyebabkan waktu respons melebihi periode timeout. Pecahkan dan optimalkan kinerja layanan backend, atau tambahkan lebih banyak server backend untuk mendistribusikan beban.

Memecahkan masalah kegagalan akses layanan

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

1. Verifikasi resolusi DNS: Jika Anda menggunakan nama domain untuk akses, verifikasi bahwa nama domain telah di-resolve dengan benar ke alamat layanan instans CLB. Anda dapat menggunakan perintah nslookup atau dig untuk memverifikasi hasil resolusi. Resolusi DNS yang salah adalah penyebab umum kegagalan akses.

2. Konfirmasi konfigurasi listener: Di Konsol CLB, periksa apakah listener telah dibuat dan konfirmasi bahwa port dan protokol listener dikonfigurasi dengan benar. Jika listener tidak ditambahkan atau dikonfigurasi salah, permintaan tidak dapat diteruskan.

3. Konfirmasi status pemeriksaan kesehatan: Di Konsol CLB, periksa status pemeriksaan kesehatan server backend. Saat semua server backend gagal pemeriksaan kesehatan, CLB tidak dapat meneruskan permintaan.

4. Periksa security group dan firewall: Verifikasi bahwa aturan security group dan pengaturan firewall server backend mengizinkan traffic pada port layanan backend dan dari blok CIDR sistem CLB 100.64.0.0/10.

5. Verifikasi bahwa layanan backend berjalan dengan baik: Masuk ke server backend secara langsung dan jalankan perintah telnet <Alamat IP pribadi server backend> <Port> (untuk Lapisan 4) atau perintah curl -I http://<Alamat IP pribadi server backend> (untuk Lapisan 7) untuk mengonfirmasi bahwa layanan backend dapat merespons dengan baik.

6. Pecahkan masalah tautan jaringan: Uji akses ke alamat layanan CLB dari lingkungan jaringan berbeda. Jika masalah hanya terjadi di jaringan lokal Anda, Anda dapat melakukan troubleshooting lebih lanjut dengan menggunakan tes ping terus-menerus atau pelacakan rute MTR.

Kegagalan akses domain dengan akses IP berhasil

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

Sesuai persyaratan regulasi, saat Anda menggunakan nama domain untuk akses publik di Tiongkok daratan, nama domain harus memiliki Pendaftaran ICP. Akses ke nama domain tanpa Pendaftaran ICP akan diblokir, menghasilkan kode status 403 atau koneksi yang di-reset.

Kami menyarankan agar Anda mengikuti langkah-langkah berikut untuk memecahkan masalah dan menyelesaikan isu ini:

1. Konfirmasi status Pendaftaran ICP nama domain: Masuk ke sistem Pendaftaran ICP Alibaba Cloud untuk memeriksa apakah nama domain telah menyelesaikan pendaftarannya. Jika belum, selesaikan Pendaftaran ICP terlebih dahulu. Untuk informasi selengkapnya, lihat Proses Pendaftaran ICP.

2. Konfirmasi apakah transfer Pendaftaran ICP diperlukan: Jika nama domain memiliki Pendaftaran ICP dengan penyedia layanan cloud lain tetapi digunakan dengan Alibaba Cloud untuk pertama kalinya, Anda juga harus melakukan transfer Pendaftaran ICP untuk memindahkan informasi pendaftaran ke Alibaba Cloud. Transfer yang belum lengkap juga dapat mengakibatkan akses yang diblokir.

3. Menyingkirkan penyebab lain: Jika domain telah menyelesaikan Pendaftaran ICP dan pendaftaran akses, periksa bahwa domain di-resolve dengan benar ke alamat layanan CLB (Anda dapat menggunakan perintah nslookup atau dig untuk memverifikasi ini), dan bahwa konfigurasi port dan protokol listener CLB sesuai dengan cara akses domain.

Dampak kontrol akses pada jaringan pribadi

Ya. Kontrol akses diterapkan di tingkat listener dan memengaruhi akses jaringan pribadi maupun publik. Jika daftar izin Anda hanya mengizinkan alamat IP publik tertentu, permintaan dari alamat IP internal yang tidak ada dalam daftar akan diblokir. Untuk menghindari dampak pada layanan internal, tambahkan segmen jaringan internal yang relevan ke daftar izin, atau gunakan Cloud Firewall untuk membatasi akses publik ke EIP.

Memecahkan masalah timeout selama uji stres

Jika Anda melakukan uji stres pada CLB Lapisan-7 dan menerima kode status 504 serta 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 membuang paket untuk koneksi baru.

Masuk ke server backend untuk memeriksa log /var/log/messages. Masalah ini dikonfirmasi jika muncul pesan error berikut:

nf_conntrack: table full, dropping packet

Solusi: Sesuaikan parameter nf_conntrack (sesuaikan nilai parameter berdasarkan kebutuhan bisnis 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 dan tidak bertahan setelah instance direstart. Untuk membuat perubahan permanen, tambahkan parameter ke /etc/sysctl.conf.

Situs tidak dapat diakses akibat kegagalan database

Skenario: Beberapa website, seperti website statis www.example.com dan website dinamis app.example.com, dilampirkan ke listener CLB. Saat database backend website dinamis gagal, website statis juga menjadi tidak dapat diakses dan mengembalikan error HTTP 502.

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

Solusi: Gunakan instans CLB terpisah untuk website dinamis dan statis untuk mengisolasi layanan. Dengan cara ini, kegagalan di website dinamis tidak akan memengaruhi akses ke website statis.

Penyebab kegagalan persistensi sesi

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

• Masalah listener HTTP/HTTPS: Listener HTTP atau HTTPS tidak akan menyisipkan cookie persistensi sesi ke respons jika server backend mengembalikan kode status 4xx.

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

• Masalah pengalihan 302: Pengalihan 302 dapat memutus persistensi sesi dengan mengubah string SERVERID.

  Saat load balancer menyisipkan cookie, jika instance ECS backend mengembalikan respons pengalihan 302, string SERVERID dalam cookie berubah, menyebabkan kegagalan persistensi sesi.

  Memecahkan masalah: Tangkap permintaan dan respons di browser atau gunakan tool pengambilan paket untuk menganalisis apakah respons 302 ada. Bandingkan string SERVERID dalam cookie sebelum dan sesudah untuk melihat apakah berbeda.

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

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

Menampilkan string persistensi sesi

Anda dapat menekan F12 di browser untuk memeriksa apakah respons berisi string 'SERVERID' atau kata kunci yang ditentukan pengguna, atau menjalankan curl www.example.com -c /tmp/cookie123 untuk menyimpan cookie, lalu menggunakan curl www.example.com -b /tmp/cookie123 untuk mengakses URL.

Menguji persistensi sesi dengan curl

1. Buat halaman uji.

   Di setiap instance ECS backend, buat halaman uji yang menampilkan alamat IP pribadi instance tersebut. IP ini mengidentifikasi server mana yang menangani permintaan, memungkinkan Anda memverifikasi efektivitas persistensi sesi dengan memeriksa konsistensi IP.

   

2. Jalankan perintah curl pada sistem Linux.

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

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

   2. Jalankan perintah berikut untuk mengkueri nilai cookie yang disisipkan oleh CLB.

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

      Catatan

      Mode default untuk persistensi sesi Alibaba Cloud adalah penyisipan cookie. Namun, pengujian curl tidak menyimpan atau mengirim cookie secara default. Oleh karena itu, Anda harus terlebih dahulu menyimpan cookie untuk pengujian. Jika tidak, hasil pengujian curl akan acak, yang dapat membuat Anda salah mengira 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

      a≤30 menentukan jumlah pengujian berulang. Anda dapat memodifikasi nilai ini sesuai kebutuhan. grep '10.170.XX.XX' digunakan untuk memfilter informasi IP yang ditampilkan. Modifikasi alamat IP berdasarkan alamat IP internal instance ECS backend.

   4. Amati alamat IP yang dikembalikan oleh pengujian. Jika selalu merupakan alamat IP pribadi yang sama dari instance ECS backend, persistensi sesi efektif. Jika tidak, mungkin ada masalah dengan persistensi sesi.

Mengonfigurasi cookie backend untuk mode Rewrite Cookie

Jika Anda memilih mode Rewrite Cookie untuk persistensi sesi Lapisan 7 di CLB, Anda harus mengonfigurasi cookie dengan nama yang ditentukan di server backend. Nama cookie harus sesuai dengan nama cookie yang dikonfigurasi di Konsol CLB. Bagian berikut memberikan contoh konfigurasi untuk 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;
    }
}

Masalah pemuatan gaya dengan listener HTTPS

Gejala:

Anda membuat listener HTTP dan HTTPS, dan kedua listener menggunakan server backend yang sama. Saat Anda mengakses website melalui port listener HTTP, website ditampilkan dengan benar. Namun, saat Anda mengaksesnya melalui listener HTTPS, tata letak website menjadi rusak.

Penyebab:

Secara default, CLB tidak memblokir pemuatan dan transmisi file JavaScript. Penyebab yang mungkin termasuk:

• Sertifikat tidak kompatibel dengan tingkat keamanan browser.

• Sertifikat berasal dari penerbit pihak ketiga yang tidak sah. Anda perlu menghubungi penerbit sertifikat untuk memeriksa masalah.

Solusi:

1. Saat membuka website, muat skrip sesuai petunjuk browser.

2. Tambahkan sertifikat yang sesuai ke klien.

Sertifikat backend untuk pengalihan HTTP ke HTTPS

Tidak. Anda hanya perlu mengonfigurasi sertifikat terkait di listener HTTPS instans CLB. Untuk informasi selengkapnya, lihat Mengonfigurasi sertifikat SSL.

Browser menampilkan sertifikat usang setelah pembaruan

Situasi ini biasanya terjadi karena CLB terhubung ke WAF 2.0 dalam mode proxy transparan, dan sertifikat di sisi WAF belum diperbarui. WAF menyinkronkan sertifikat dari CLB secara berkala. Untuk memaksa sinkronisasi segera, Anda dapat menonaktifkan lalu mengaktifkan kembali pengalihan traffic di sisi WAF. Tindakan ini memaksa refresh status sertifikat. Perhatikan bahwa operasi ini menyebabkan gangguan layanan singkat selama 1 hingga 2 detik.

Versi protokol HTTP backend untuk listener

• Saat permintaan klien menggunakan HTTP/1.1 atau HTTP/2, listener Lapisan 7 menggunakan HTTP/1.1 untuk mengakses server backend.

• Saat permintaan klien menggunakan protokol selain HTTP/1.1 dan HTTP/2, listener Lapisan 7 menggunakan HTTP/1.0 untuk mengakses server backend.

Mendapatkan versi protokol klien di backend

Ya.

Dukungan pembatasan laju berbasis URL

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

ALB mendukung pembatasan laju berbasis URL. Anda dapat mengonfigurasi aturan penerusan listener untuk menetapkan batas QPS untuk path tertentu. Hal ini memerlukan penggunaan aksi "Forward To". Lihat gambar berikut:

Header Transfer-Encoding: chunked

Transfer-Encoding: chunked adalah bidang standar dalam protokol HTTP yang menunjukkan bahwa isi pesan ditransfer dalam potongan-potongan. CLB Lapisan-7 diimplementasikan berdasarkan reverse proxy Tengine dan menggunakan enkode transfer chunked saat meneruskan permintaan ke server backend. Oleh karena itu, server backend akan melihat bidang ini di header permintaan. Ini adalah perilaku normal untuk reverse proxy dan tidak memengaruhi layanan Anda. CLB Lapisan-4 hanya meneruskan traffic, sehingga bidang ini tidak muncul.

Header respons backend yang dihapus oleh CLB L7

Untuk mengimplementasikan persistensi sesi, CLB menghapus bidang seperti Date, Server, X-Pad, dan X-Accel-Redirect dari header respons. Jika Anda perlu mempertahankan bidang ini, Anda dapat menambahkan awalan ke header respons kustom Anda, seperti xl-server, atau gunakan listener TCP Lapisan 4 sebagai gantinya.

Menggunakan perlindungan WAF dengan CLB

Dampak menonaktifkan NIC publik

Jika instance ECS memiliki alamat IP publik, menonaktifkan network interface controller (NIC) publiknya akan mengganggu layanan load balancing.

Hal ini karena saat NIC publik ada, rute default melewati jaringan publik. Menonaktifkannya mencegah paket respons dikirim, sehingga memengaruhi layanan load balancing. Kami menyarankan agar Anda tidak menonaktifkan NIC publik. Jika Anda harus menonaktifkannya, Anda perlu mengubah rute default untuk menggunakan jaringan pribadi guna menghindari gangguan layanan. Namun, Anda harus terlebih dahulu mempertimbangkan apakah bisnis Anda bergantung pada jaringan publik, seperti untuk mengakses instance RDS.

Dukungan untuk permintaan dengan field TOA

Tidak. Field TCP Option Address (TOA) dalam permintaan klien bertentangan dengan field TOA yang digunakan secara internal oleh load balancer, yang mencegah Anda mendapatkan alamat IP asli klien.