Server Load Balancer:FAQ layanan pendengar CLB

Apakah CLB mendukung pengalihan port?

Ya.

CLB mendukung pengalihan port. Untuk petunjuk lengkapnya, lihat Alihkan permintaan HTTP ke HTTPS menggunakan CLB.

Apakah pendengar CLB Lapisan 4 mendukung pendengaran pada rentang port?

Tidak. Untuk mendengarkan rentang port, buat instance Network Load Balancer (NLB) dan aktifkan fitur pendengaran rentang port untuk pendengar TCP atau UDP-nya. Untuk informasi lebih lanjut, lihat Aktifkan pendengaran dan pengalihan multi-port untuk NLB.

Pertimbangan port pendengar

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

• Untuk informasi tentang port yang digunakan oleh aplikasi pada sistem Windows Server, lihat Service overview and network port requirements for Windows dalam dokumentasi Microsoft.

• Untuk informasi tentang port umum, lihat Common ports.

Konfigurasi pendengar untuk WebSocket atau WebSocket Secure

• Untuk layanan backend yang menggunakan protokol WebSocket, Anda dapat mengonfigurasi pendengar TCP atau pendengar HTTP.

• Untuk layanan backend yang menggunakan protokol WebSocket Secure, Anda dapat mengonfigurasi pendengar TCP atau pendengar HTTPS.

Perubahan konfigurasi pendengar

Perubahan berlaku segera. Perubahan hanya berlaku untuk permintaan baru dan tidak memengaruhi koneksi yang sudah ada.

Pelepasan paket di bawah bandwidth maksimum

Masalah ini dapat disebabkan oleh alasan berikut:

• Alibaba Cloud menyediakan data pemantauan bandwidth berdasarkan rata-rata per 1 menit. Jika lalu lintas instan dalam satu detik tertentu melebihi batas bandwidth instance, tetapi rata-rata bandwidth per 1 menit tidak melebihi batas, grafik pemantauan tidak akan menunjukkan bahwa batas telah dilampaui.

• CLB dideploy pada kluster server untuk melayani instance CLB. Semua permintaan eksternal didistribusikan secara merata ke server sistem untuk diteruskan. Jika permintaan unduh dari satu klien melebihi ambang batas bandwidth dari satu server individu, paket akan di-drop. Untuk informasi lebih lanjut, lihat rumus perhitungan batas atas lalu lintas unduh untuk satu koneksi dalam Mengapa koneksi gagal mencapai bandwidth maksimum dalam beberapa skenario?.

Traffic yang dipantau melebihi batas laju

CLB berjalan pada kluster, dan pembatasan laju diterapkan secara terdistribusi. Batas laju puncak per node dihitung menggunakan rumus Batas laju puncak per node = Total bandwidth yang dikonfigurasi pada load balancer / (N - 1), di mana N adalah jumlah node kluster. Akibatnya, batas laju total efektif bisa sedikit lebih tinggi daripada nilai yang dikonfigurasi.

Koneksi tidak mencapai bandwidth maksimum

• Kasus penggunaan: Jika Anda membeli instance CLB yang menghadap internet dan menggunakan metode penagihan pay-by-bandwidth, koneksi mungkin gagal mencapai bandwidth maksimum dalam skenario seperti uji stres dengan satu klien atau transfer paket data berukuran sangat besar.

• Cara kerja (penyebab):

  CLB berjalan pada kluster, dan permintaan inbound didistribusikan ke beberapa server sistem untuk diteruskan. Oleh karena itu, bandwidth maksimum yang dikonfigurasi dibagi di antara server-server sistem tersebut.

  Batas atas lalu lintas unduh untuk satu koneksi dihitung menggunakan rumus berikut: Traffic unduh puncak per koneksi = Total bandwidth yang dikonfigurasi pada load balancer / (N - 1), di mana N adalah jumlah server sistem dalam kluster. N bernilai 4 untuk pendengar Lapisan 4 dan 8 untuk pendengar Lapisan 7. Sebagai contoh, jika Anda mengatur bandwidth maksimum menjadi 10 Mbps di Konsol, bandwidth total dapat mencapai 10 Mbps ketika menggunakan banyak klien. Namun, lalu lintas unduh maksimum untuk satu klien adalah 10 / (4 - 1) = 3,33 Mbps.

• Solusi yang direkomendasikan:

  • Ubah metode penagihan instance CLB yang menghadap internet menjadi pay-by-data-transfer.

  • Gunakan instance NLB atau Application Load Balancer (ALB) dengan Elastic IP Address (EIP) dan Shared Bandwidth. Solusi ini memberikan elastisitas lebih besar dan menghindari keterbatasan ini.

Instance CLB tidak mencapai QPS maksimum

• Kasus penggunaan: Instance CLB mungkin gagal mencapai queries per second (QPS) maksimum saat menangani sejumlah kecil koneksi persisten. Hal ini terjadi karena beban mungkin tidak didistribusikan ke semua server dalam kluster.

• Cara kerja (penyebab):

  CLB berjalan pada kluster, dan permintaan inbound didistribusikan ke beberapa server sistem untuk diteruskan. Oleh karena itu, QPS maksimum instance CLB dibagi di antara server-server sistem tersebut.

  Batas QPS atas dari satu server sistem dihitung menggunakan rumus berikut: QPS maksimum per server sistem = Total QPS instance / (N - 1), di mana N adalah jumlah server sistem dalam grup penerusan. Sebagai contoh, jika Anda membeli instance CLB dengan spesifikasi slb.s1.small, yang setara dengan QPS 1.000, total QPS dapat mencapai 1.000 saat menggunakan banyak klien. Jika terdapat 8 server sistem, QPS maksimum satu server sistem adalah 1.000 / (8 - 1) = 142 QPS.

  Catatan

• Solusi yang direkomendasikan:

  • Gunakan koneksi singkat dari satu klien untuk uji stres.

  • Kurangi penggunaan ulang koneksi sesuai kebutuhan bisnis Anda.

  • Tingkatkan spesifikasi instance CLB. Untuk informasi lebih lanjut, lihat Tingkatkan atau turunkan spesifikasi instance bayar sesuai penggunaan (berbasis spesifikasi).

  • Gunakan instance ALB, yang menyediakan elastisitas yang cukup.

Laju koneksi baru tidak mencapai nilai puncak

• Kasus penggunaan: Jika Anda membeli instance Classic Load Balancer (CLB) berbasis spesifikasi, laju Connections Per Second (CPS)-nya mungkin gagal mencapai nilai maksimum dalam skenario seperti uji stres dengan satu klien atau satu sumber lalu lintas.

  Catatan

• Cara kerja (penyebab):

  CLB menggunakan arsitektur berkluster untuk ketersediaan tinggi dan skalabilitas. Semua permintaan koneksi dari klien eksternal didistribusikan ke beberapa server sistem dalam kluster. Oleh karena itu, CPS puncak instance CLB dibagi di antara server-server tersebut.

  Rumus untuk CPS puncak satu server sistem adalah: CPS puncak satu server sistem = Total CPS instance / (N - 1), di mana N mewakili jumlah server sistem dalam grup penerusan.

  Sebagai contoh, instance CLB dengan spesifikasi slb.s1.small memiliki CPS nominal sebesar 3.000. Dalam skenario akses konkuren multi-klien, CPS total dapat mencapai 3.000 CPS. Jika terdapat 4 server backend, batas CPS satu server adalah 3.000/(4-1) = 1.000 CPS.

• Solusi yang direkomendasikan:

  • Atur ulang metode penagihan CLB: Pertimbangkan beralih dari berbasis spesifikasi ke bayar sesuai penggunaan. Instance bayar sesuai penggunaan memiliki batas kinerja lebih tinggi dan tidak terikat pada ukuran instance tertentu, sehingga membantu menghindari bottleneck kinerja.

  • Tingkatkan ke NLB: Untuk skenario dengan konkurensi tinggi dan permintaan koneksi baru yang besar, kami merekomendasikan menggunakan NLB. NLB menawarkan peningkatan kinerja signifikan dan elastisitas lebih besar dibanding CLB, sehingga mampu menangani koneksi konkuren berskala besar secara lebih efektif dan menghindari keterbatasan CPS pada arsitektur CLB.

Rentang timeout koneksi untuk pendengar

• Timeout koneksi pendengar TCP: 10 hingga 900 detik.

• Pendengar HTTP:

  • Periode timeout koneksi idle: 1 hingga 60 detik.

  • Periode timeout permintaan koneksi: 1 hingga 180 detik.

• Pendengar HTTPS:

  • Periode timeout koneksi idle: 1 hingga 60 detik.

  • Periode timeout permintaan koneksi: 1 hingga 180 detik.

Timeout koneksi titik akhir CLB

Masalah berikut dapat menyebabkan koneksi ke titik akhir mengalami timeout:

• Titik akhir dilindungi oleh layanan keamanan.

  Contohnya, lalu lintas di-blackhole atau di-scrub, atau WAF diaktifkan. Setelah koneksi terbentuk, WAF mengirim paket RST ke klien dan kluster server.

• Port klien tidak mencukupi.

  Masalah ini sering terjadi selama uji stres. Port klien yang tidak mencukupi dapat menyebabkan kegagalan koneksi. Secara default, load balancer menghapus atribut timestamp dari koneksi TCP. Akibatnya, pengaturan tw_reuse pada tumpukan protokol Linux, yang menggunakan ulang koneksi dalam status TIME_WAIT, tidak berlaku. Akumulasi koneksi dalam status TIME_WAIT menyebabkan kekurangan port klien.

  Solusi: Gunakan koneksi persisten alih-alih koneksi singkat di sisi klien. Gunakan paket RST untuk menutup koneksi dengan mengatur atribut socket SO_LINGER, bukan mengirim paket FIN.

• Antrian accept server backend penuh.

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

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

• Server backend mengakses load balancer Lapisan 4 miliknya sendiri.

  Server backend tidak dapat sekaligus bertindak sebagai klien untuk pendengar Lapisan 4 (TCP/UDP) CLB-nya sendiri. Skenario hairpinning ini, di mana server backend mengakses titik akhir CLB, menyebabkan kegagalan koneksi. Contoh umumnya adalah aplikasi backend yang menggunakan penggabungan URL untuk mengarahkan ke titik akhir CLB.

  Solusi:

  • Gunakan klien berbeda untuk mengakses titik akhir, bukan server backend milik load balancer Lapisan 4 itu sendiri.

  • Migrasi ke NLB dan nonaktifkan fitur Client IP Preservation dalam grup server. Setelah dinonaktifkan, instance ECS dalam grup server dapat bertindak sebagai server backend sekaligus klien yang mengakses 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 di NLB?.

• Penanganan RST yang tidak tepat untuk timeout koneksi.

  Setelah koneksi TCP terbentuk, jika koneksi tetap idle selama 900 detik, load balancer mengirim paket RST ke klien dan server untuk menutup koneksi. Beberapa aplikasi tidak menangani pengecualian RST dengan benar dan mungkin mengirim data melalui koneksi yang sudah ditutup, menyebabkan aplikasi mengalami timeout.

  Catatan

  Nilai default adalah 900 detik. Anda dapat menyesuaikannya sesuai kebutuhan.

Apa aturan timeout untuk koneksi HTTP dan HTTPS?

• Koneksi HTTP persisten dibatasi hingga maksimal 100 permintaan berurutan. Koneksi ditutup setelah batas ini tercapai.

• Periode timeout antara dua permintaan HTTP atau HTTPS melalui koneksi HTTP persisten dapat dikonfigurasi dari 1 hingga 60 detik, dengan margin kesalahan 1 hingga 2 detik. Koneksi TCP ditutup setelah timeout. Jika Anda memerlukan koneksi berumur panjang, kirim permintaan heartbeat dalam rentang 13 detik.

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

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

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

Penanganan koneksi saat klien terputus

Load balancer tidak menutup koneksi ke server backend selama operasi baca dan tulis.

Aktifkan koneksi backend persisten

Instance CLB tidak mendukung fitur ini. Untuk mengaktifkan koneksi persisten ke server backend, Anda dapat membuat instance ALB, mengonfigurasi pendengar HTTP atau HTTPS, lalu mengaktifkan koneksi persisten untuk grup server ALB yang sesuai. Untuk informasi lebih lanjut, lihat Buat dan kelola grup server.

Atasi latensi tinggi pada CLB

Saat Anda mengakses layanan backend melalui CLB, sedikit peningkatan latensi dibandingkan akses langsung ke server backend adalah hal normal. Pendengar Lapisan 7 CLB menggunakan arsitektur reverse proxy (Tengine), di mana permintaan diteruskan melalui CLB. Hal ini menambah overhead satu hop jaringan dan pemrosesan protokol. Pendengar Lapisan 4 menggunakan LVS untuk penerusan, dan latensi tambahan biasanya minimal.

Jika latensinya sangat tinggi, kami merekomendasikan langkah troubleshooting berikut:

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

   • request_time: Interval waktu, dalam detik, antara saat CLB menerima paket permintaan pertama dan saat mengembalikan respons.

   • upstream_response_time: Waktu, dalam detik, dari saat koneksi terbentuk dengan server backend hingga respons lengkap diterima dan koneksi ditutup.

2. Identifikasi sumber latensi:

   • Jika upstream_response_time tinggi, latensi biasanya disebabkan oleh pemrosesan lambat di server backend. Selidiki kinerja aplikasi backend, 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 pada jalur jaringan dari klien ke CLB. Kami merekomendasikan menjalankan uji ping berkelanjutan atau pelacakan rute MTR dari klien ke alamat layanan CLB untuk mengatasi masalah tautan jaringan.

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

Atasi error 502, 503, dan 504

Saat mengakses layanan melalui CLB, error 502, 503, atau 504 biasanya menunjukkan bahwa server backend tidak memproses permintaan dengan benar.

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

• 503 Service Temporarily Unavailable: Biasanya disebabkan oleh lalu lintas berlebihan atau server backend tidak tersedia. Kode error ini dikembalikan saat lalu lintas instan suatu permintaan melebihi batas spesifikasi instance CLB.

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

Langkah 1: Periksa log akses

Kami merekomendasikan Anda terlebih dahulu mengaktifkan log akses CLB. Di log tersebut, periksa bidang status (kode status yang dikembalikan CLB ke klien) dan upstream_status (kode status yang dikembalikan server backend ke CLB).

• Jika status dan upstream_status sama, kemungkinan besar CLB langsung meneruskan kode status error dari server backend. Anda harus terlebih dahulu menyelidiki penyebab kode status yang dikembalikan oleh server backend.

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

Atasi error 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 mengembalikan error 502. Periksa status pemeriksaan kesehatan di Konsol dan selidiki penyebab kegagalannya, seperti security group yang tidak mengizinkan lalu lintas dari 100.64.0.0/10 (blok alamat sistem CLB), konfigurasi kode status pemeriksaan kesehatan yang tidak sesuai, atau path pemeriksaan kesehatan yang tidak ada. Untuk informasi lebih lanjut, lihat FAQ Pemeriksaan Kesehatan CLB.

• CLB mengonversi kode status abnormal dari server backend menjadi 502: Jika server backend mengembalikan kode status abnormal, seperti 504 atau 444, CLB mungkin mengembalikan kode status 502 ke klien. Kami merekomendasikan Anda memeriksa bidang upstream_status di log akses untuk mengidentifikasi kode status aktual yang dikembalikan server backend dan mengatasi penyebab error tersebut.

• Error layanan backend: Error 502 juga dapat disebabkan oleh beban tinggi di server backend, format respons abnormal, atau penutupan koneksi abnormal. Kami merekomendasikan Anda memeriksa log server backend dan penggunaan resource seperti CPU dan memori.

Atasi error 503

• Lalu lintas melebihi batas spesifikasi instance: Error 503 dikembalikan saat QPS, bandwidth, atau jumlah koneksi baru dari lalu lintas yang mengakses CLB melebihi batas spesifikasi saat ini. Anda dapat memperoleh metrik pemantauan ini dari CloudMonitor.

• Lonjakan lalu lintas instan tidak ditampilkan di pemantauan: CloudMonitor menampilkan data per menit dan mungkin tidak menunjukkan kejadian pelanggaran batas yang terjadi per detik. Anda dapat memeriksa jumlah permintaan per detik di log akses. Jika upstream_status dalam log berupa "-", artinya permintaan tidak dikirim ke server backend.

Atasi error 504

• Timeout respons backend: CLB mengembalikan error 504 jika server backend tidak merespons dalam batas waktu timeout permintaan koneksi yang dikonfigurasi untuk pendengar. Periksa bidang upstream_response_time di log akses untuk menentukan waktu respons aktual server backend dan sesuaikan timeout permintaan koneksi untuk pendengar tersebut.

• Timeout koneksi backend: Periode timeout untuk jabat tangan tiga arah TCP antara CLB dan instance ECS backend adalah 5 detik. Jika upstream_response_time di log akses terlalu lama, hal ini mungkin disebabkan oleh masalah dalam membentuk koneksi ke server backend. Kami merekomendasikan Anda melakukan pengambilan paket untuk menyelidiki penyebabnya.

• Beban backend tinggi: Penggunaan resource tinggi di server backend, seperti CPU atau memori, menyebabkan waktu respons melebihi periode timeout. Kami merekomendasikan Anda menyelidiki dan mengoptimalkan kinerja layanan backend atau menambahkan lebih banyak server backend untuk mendistribusikan beban.

Atasi ketidakaksesan melalui CLB

Jika layanan tidak dapat diakses melalui CLB, atasi masalah tersebut secara berjenjang menggunakan langkah-langkah berikut:

1. Konfirmasi resolusi nama domain: Jika Anda mengakses layanan menggunakan nama domain, pastikan nama domain tersebut di-resolve ke titik akhir instance CLB. Anda dapat menggunakan perintah nslookup atau dig untuk memverifikasi hasil resolusi. Resolusi nama domain yang salah adalah penyebab umum kegagalan akses.

2. Verifikasi konfigurasi pendengar: Di Konsol CLB, periksa apakah pendengar telah dibuat dan pastikan port serta protokol pendengar dikonfigurasi dengan benar. Jika tidak ada pendengar yang ditambahkan atau port pendengar salah dikonfigurasi, permintaan tidak dapat diteruskan.

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

4. Periksa security group dan firewall: Pastikan aturan security group dan pengaturan firewall untuk server backend mengizinkan lalu lintas pada port layanan backend dari blok CIDR sistem CLB 100.64.0.0/10.

5. Verifikasi bahwa server backend berfungsi dengan benar: Masuk langsung ke server backend dan gunakan telnet <backend_server_private_ip> <port> (Lapisan 4) atau curl -I http://<backend_server_private_ip> (Lapisan 7) untuk memverifikasi bahwa layanan backend merespons dengan benar.

6. Atasi tautan jaringan: Uji akses ke titik akhir CLB dari lingkungan jaringan berbeda. Jika masalah hanya terjadi di jaringan lokal Anda, Anda dapat melakukan troubleshooting lebih lanjut dengan uji ping berkelanjutan atau pelacakan rute MTR.

Akses melalui IP berhasil tetapi nama domain gagal

Alasan paling umum adalah nama domain belum menyelesaikan Pendaftaran ICP yang diperlukan.

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

Kami merekomendasikan Anda mengatasi dan menangani masalah tersebut dengan langkah-langkah berikut:

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

2. Verifikasi apakah diperlukan transfer Pendaftaran ICP: Jika nama domain telah terdaftar ICP di penyedia layanan cloud lain, tetapi digunakan pertama kali dengan Alibaba Cloud, Anda juga perlu melakukan transfer Pendaftaran ICP untuk memindahkan informasi pendaftaran ke Alibaba Cloud. Kegagalan menyelesaikan transfer juga dapat mengakibatkan akses diblokir.

3. Kesampingkan penyebab lain: Jika domain telah menyelesaikan Pendaftaran ICP dan transfer Pendaftaran ICP, periksa apakah resolusi nama domain mengarah dengan benar ke titik akhir CLB (yang dapat Anda verifikasi menggunakan perintah nslookup atau dig), serta pastikan konfigurasi port dan protokol pendengar CLB sesuai dengan cara akses domain tersebut.

Dampak kontrol akses pada jaringan internal

Ya. Kontrol akses diterapkan pada level pendengar dan memengaruhi jaringan internal maupun publik. Jika daftar izin hanya mengizinkan alamat IP publik tertentu, permintaan akses internal dari alamat IP yang tidak ada dalam daftar izin akan diblokir. Untuk menghindari dampak pada layanan internal, kami merekomendasikan Anda juga menambahkan segmen jaringan internal yang relevan ke daftar izin, atau menggunakan produk cloud firewall untuk membatasi akses jaringan publik ke EIP.

Kegagalan persistensi sesi

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

• Masalah pada pendengar HTTP/HTTPS: Pendengar HTTP atau HTTPS tidak dapat menyisipkan cookie yang diperlukan untuk persistensi sesi ke dalam paket respons yang berisi kode status 4xx dari server backend.

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

• Masalah pada pengalihan 302: Pengalihan 302 mengubah string SERVERID dalam cookie persistensi sesi.

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

  Metode troubleshooting: Tangkap paket permintaan dan respons di browser, atau gunakan tool pengambilan paket untuk menganalisis apakah terdapat paket respons 302. Bandingkan nilai cookie SERVERID sebelum dan sesudah pengalihan untuk melihat apakah nilainya berubah.

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

• Timeout persistensi sesi terlalu singkat: Mengatur timeout persistensi sesi ke durasi yang sangat singkat juga dapat menyebabkan kegagalan persistensi sesi.

Lihat 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 tersebut.

Uji persistensi sesi dengan curl

1. Buat halaman uji.

   Di semua instance ECS backend load balancer, buat halaman uji yang menampilkan alamat IP pribadi mesin lokal. Alamat IP pribadi digunakan untuk menentukan server fisik mana yang ditugaskan untuk permintaan. Dengan mengamati konsistensi alamat IP ini, Anda dapat menentukan efektivitas persistensi sesi load balancer.

   

2. Jalankan perintah curl di sistem Linux.

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

   1. Masuk ke server Linux yang digunakan untuk pengujian.

   2. Jalankan perintah berikut untuk mengkueri nilai cookie server load balancer.

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

      Catatan

      Persistensi sesi load balancer Alibaba Cloud secara default menggunakan penyisipan cookie. Namun, pengujian curl tidak menyimpan atau mengirim cookie secara default, sehingga Anda harus terlebih dahulu menyimpan cookie yang sesuai untuk pengujian. Jika tidak, hasil pengujian curl akan acak, yang mungkin 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 adalah jumlah pengujian berulang dan dapat dimodifikasi sesuai kebutuhan. grep '10.170.XX.XX' memfilter informasi IP yang ditampilkan. Modifikasi alamat IP sesuai dengan alamat IP internal instance ECS backend.

   4. Amati alamat IP yang dikembalikan oleh pengujian. Jika alamat IP pribadi instance ECS-nya sama, hal ini membuktikan bahwa persistensi sesi efektif. Jika tidak, berarti terdapat masalah pada persistensi sesi.

Pendengar HTTPS gagal memuat gaya

Gejala:

Pendengar HTTP dan HTTPS dibuat, dan keduanya menggunakan server backend yang sama. Saat saya mengakses website melalui pendengar HTTP, website ditampilkan dengan benar. Namun, gaya (CSS) website gagal dimuat, menyebabkan tata letak menjadi rusak.

Penyebab:

Secara default, load balancer tidak memblokir pemuatan dan transmisi file JS. 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 sertifikat tersebut.

Solusi:

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

2. Tambahkan sertifikat yang sesuai ke klien.

Sertifikat di server backend setelah pengalihan

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

Browser menampilkan sertifikat lama setelah pembaruan

Situasi ini biasanya terjadi karena CLB terhubung ke WAF 2.0 melalui integrasi transparan, dan sertifikat di WAF belum diperbarui. WAF menyinkronkan sertifikat dari CLB secara berkala. Untuk menyinkronkan segera, Anda dapat menonaktifkan lalu mengaktifkan kembali penerusan lalu lintas di WAF untuk memaksa penyegaran sertifikat. Perhatikan bahwa operasi ini akan menyebabkan gangguan layanan selama 1 hingga 2 detik.

Versi HTTP untuk akses backend

• Jika permintaan klien menggunakan HTTP 1.1 atau HTTP 2.0, pendengar Lapisan 7 menggunakan HTTP 1.1 untuk mengakses server backend.

• Jika permintaan klien menggunakan versi selain HTTP 1.1 atau HTTP 2.0, pendengar Lapisan 7 menggunakan HTTP 1.0 untuk mengakses server backend.

Dapatkan versi protokol klien di backend

Ya.

Pembatasan laju berbasis URL

CLB tidak mendukung pembatasan laju berbasis URL. CLB hanya mendukung pembatasan laju berbasis bandwidth pada level pendengar.

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

Aktifkan perlindungan WAF untuk CLB

Dampak menonaktifkan antarmuka jaringan publik

Jika instance ECS memiliki alamat IP publik, menonaktifkan antarmuka jaringan publiknya akan memengaruhi layanan load balancing.

Hal ini karena dengan antarmuka jaringan publik, rute default melewati jaringan publik. Menonaktifkannya mencegah paket balasan, sehingga memengaruhi layanan load balancing. Kami merekomendasikan agar Anda tidak menonaktifkan antarmuka jaringan publik. Jika Anda harus menonaktifkannya, Anda perlu mengubah rute default ke jaringan pribadi untuk menghindari gangguan layanan. Namun, Anda perlu mempertimbangkan apakah bisnis Anda bergantung pada jaringan publik, seperti mengakses RDS melalui jaringan publik.

Dukungan untuk permintaan klien dengan field TOA

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