Server Load Balancer：FAQ tentang listener CLB

Apakah CLB mendukung port forwarding?

Ya.

CLB mendukung port forwarding. Untuk informasi selengkapnya, lihat Mengalihkan permintaan dari HTTP ke HTTPS.

Apakah listener CLB Lapisan 4 dapat mendengarkan pada range port?

Tidak. Untuk mengonfigurasi listener TCP atau UDP yang mendengarkan pada range port, Anda dapat membuat instance Network Load Balancer (NLB) dan mengaktifkan fitur pendengaran full-port untuk listener TCP atau UDP. Untuk informasi selengkapnya, lihat Mengaktifkan pendengaran dan pengalihan multi-port untuk NLB.

Apa yang perlu saya ketahui sebelum mengonfigurasi port listener untuk CLB?

Beberapa penyedia layanan memblokir traffic melalui high-risk ports, seperti 25, 135, 139, 444, 445, 5800, dan 5900, secara default di wilayah tertentu. Bahkan jika Anda membuka port-port tersebut dalam aturan security group, pengguna di wilayah terbatas tidak dapat mengakses instance CLB Anda melalui port tersebut. Kami menyarankan agar Anda menggunakan port lain untuk layanan Anda.

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

• Untuk informasi selengkapnya tentang port umum, lihat Port umum.

Listener mana yang harus saya pilih untuk layanan backend yang menggunakan protokol WebSocket atau WebSocket Secure?

• Untuk layanan backend yang menggunakan protokol WebSocket, gunakan listener TCP atau HTTP.

• Untuk layanan backend yang menggunakan protokol WebSocket Secure, gunakan listener TCP atau HTTPS.

Berapa lama waktu yang dibutuhkan agar modifikasi konfigurasi listener CLB berlaku, dan apa dampaknya?

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

Mengapa terjadi packet loss meskipun data pemantauan menunjukkan bahwa bandwidth maksimum instance CLB belum tercapai?

Kemungkinan penyebab:

• Data pemantauan bandwidth dari Alibaba Cloud didasarkan pada rata-rata per menit. Jika traffic instan melebihi batas bandwidth selama beberapa detik dalam satu menit, rata-rata bandwidth untuk menit tersebut mungkin tetap di bawah batas yang dikonfigurasi. Dalam kasus ini, dasbor pemantauan menunjukkan bahwa penggunaan bandwidth keseluruhan berada di bawah batas, tetapi packet loss masih dapat terjadi.

• CLB menyediakan layanan load balancing dengan mendistribusikan permintaan ke kelompok server backend. Batas bandwidth yang dikonfigurasi didistribusikan ke beberapa server backend. Jika permintaan klien melebihi ambang batas untuk satu server, packet loss terjadi. Untuk informasi selengkapnya, lihat metode perhitungan batas unduhan per koneksi dalam Mengapa koneksi gagal mencapai bandwidth maksimum dalam beberapa skenario?.

Mengapa traffic yang ditampilkan di dasbor pemantauan melebihi batas laju yang dikonfigurasi?

CLB menggunakan cluster deployment dan rate limiting terdistribusi. Batas laju per node = Total bandwidth instance CLB/(N-1), di mana N adalah jumlah node dalam kluster. Akibatnya, total batas laju efektif mungkin sedikit melebihi nilai yang dikonfigurasi.

Mengapa koneksi gagal mencapai bandwidth maksimum dalam beberapa skenario?

• Deskripsi: Saat Anda melakukan uji stres dari satu klien atau mentransfer paket besar ke instance CLB yang menghadap Internet dengan metode penagihan bayar-per-bandwidth, koneksi mungkin gagal mencapai bandwidth maksimum.

• Prinsip (Alasan):

  CLB menyediakan layanan load balancing dengan mendistribusikan permintaan ke kelompok server backend. Batas bandwidth yang dikonfigurasi didistribusikan ke beberapa server backend.

  Batas atas data yang diunduh melalui satu koneksi dihitung sebagai berikut: Bandwidth maksimum per koneksi = Total bandwidth instance CLB/(N-1), di mana N adalah jumlah node dalam kluster. Untuk listener Lapisan 4, N adalah 4. Untuk listener Lapisan 7, N adalah 8. Misalnya, jika Anda menetapkan batas bandwidth 10 Mbps di konsol, bandwidth total dapat mencapai 10 Mbps saat beberapa klien mengakses instance CLB secara bersamaan. Satu klien dapat mengunduh hingga 10/(4-1)=3,33 Mbps.

• Solusi:

  • Gunakan metode penagihan bayar-berdasarkan-transfer-data untuk instance CLB.

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

Mengapa CLB gagal mencapai QPS maksimum dalam beberapa skenario?

• Deskripsi: Jika Anda hanya menggunakan beberapa koneksi persisten, tidak semua server backend dalam grup pengalihan menerima koneksi. Akibatnya, instance CLB mungkin gagal mencapai QPS maksimumnya.

• Alasan:

  CLB menyediakan layanan load balancing dengan mendistribusikan permintaan ke kelompok server backend. Batas QPS yang dikonfigurasi didistribusikan ke beberapa server backend.

  QPS maksimum per server backend dihitung sebagai berikut: QPS maksimum per server backend = Total QPS/(N-1). N adalah jumlah server backend dalam grup pengalihan. Misalnya, jika Anda membeli instance CLB Small I (slb.s1.small) di konsol, QPS maksimum adalah 1.000. Saat beberapa klien mengakses instance tersebut secara bersamaan, total QPS dapat mencapai 1.000. Jika terdapat delapan server backend, setiap server mendukung hingga 1.000/(8-1)=142 QPS.

  Catatan

• Solusi yang direkomendasikan:

  • Gunakan koneksi singkat dari satu klien untuk uji stres.

  • Kurangi reuse koneksi sesuai kebutuhan.

  • Tingkatkan spesifikasi instance CLB. Untuk informasi selengkapnya, lihat Upgrade atau downgrade pay-as-you-go (pay-by-specification) instances.

  • Gunakan instance ALB, yang menawarkan elastisitas lebih besar.

Dalam beberapa skenario, mengapa jumlah koneksi baru gagal mencapai batas atas?

• Deskripsi: Setelah Anda membeli instance CLB langganan, laju koneksi baru per detik (CPS) mungkin gagal mencapai batas yang ditentukan dalam skenario tertentu, seperti uji stres sisi klien atau akses dari satu sumber.

  Catatan

• Penyebab:

  CLB menggunakan cluster deployment untuk memastikan ketersediaan tinggi dan skalabilitas. Permintaan koneksi eksternal didistribusikan merata ke beberapa server sistem dalam kluster. Akibatnya, batas CPS didistribusikan ke server-server tersebut.

  CPS maksimum per server sistem dihitung sebagai berikut: CPS maksimum per server sistem = Total CPS instance CLB/(N-1), di mana N adalah jumlah server dalam grup pengalihan.

  Misalnya, jika Anda membeli instance CLB Small I (slb.s1.small), CPS yang dinyatakan adalah 3.000. Saat beberapa klien mengakses instance tersebut secara bersamaan, total CPS dapat mencapai 3.000. Jika terdapat empat server sistem, setiap server mendukung hingga 3.000/(4−1)=1.000 CPS.

• Solusi:

  • Ubah metode penagihan: Beralih dari langganan ke penagihan pay-as-you-go. Instance CLB pay-as-you-go tidak memerlukan spesifikasi dan menawarkan kinerja lebih tinggi daripada sebagian besar instance langganan. Ini menghindari masalah kinerja yang disebabkan oleh spesifikasi yang terlalu kecil.

  • Gunakan Network Load Balancer (NLB): NLB ideal untuk skenario konkurensi tinggi atau skenario yang memerlukan laju koneksi baru per detik yang tinggi. Dibandingkan dengan CLB, NLB memberikan kinerja dan elastisitas yang jauh lebih baik. Hal ini memungkinkan NLB menangani koneksi konkuren berskala besar secara efektif dan menghindari keterbatasan CPS yang disebabkan oleh jumlah server tetap dalam CLB.

Berapa lama periode timeout koneksi untuk setiap jenis listener?

• Listener TCP: 10 hingga 900 detik.

• Listener HTTP:

  • Periode timeout koneksi idle: 1 hingga 60 detik.

  • Periode timeout permintaan koneksi: 1 hingga 180 detik.

• Listener HTTPS:

  • Periode timeout koneksi idle: 1 hingga 60 detik.

  • Periode timeout permintaan koneksi: 1 hingga 180 detik.

Mengapa koneksi ke alamat layanan CLB mengalami timeout?

Koneksi ke titik akhir layanan mengalami timeout di sisi server dalam situasi berikut:

• Titik akhir layanan dilindungi.

  Hal ini dapat disebabkan oleh traffic blackholing, traffic scrubbing, atau perlindungan Web Application Firewall (WAF). WAF mengirim paket Reset (RST) ke klien dan server backend setelah koneksi terbentuk.

• Kehabisan port klien

  Kehabisan port di sisi Klien sering terjadi selama uji stres. Secara default, CLB menghapus atribut timestamp dari koneksi TCP, sehingga pengaturan tw_reuse dalam kernel Linux—yang memungkinkan penggunaan ulang koneksi dalam status TIME_WAIT—tidak berlaku. Akibatnya, koneksi TIME_WAIT menumpuk dan menghabiskan port yang tersedia.

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

• Antrean accept server backend penuh

  Jika antrean accept pada server backend penuh, server berhenti merespons dengan paket SYN-ACK. Hal ini menyebabkan permintaan klien mengalami timeout.

  Solusi: Nilai default net.core.somaxconn adalah 128. Anda dapat mengevaluasi kebutuhan bisnis Anda dan menyesuaikan nilai ini. Kemudian, jalankan sysctl -w net.core.somaxconn=<Nilai yang diinginkan> untuk memperbarui parameter dan restart aplikasi pada server backend.

• Mengakses CLB dari server backend instance CLB Lapisan 4

  CLB Lapisan 4 (TCP/UDP) tidak mendukung skenario di mana server backend bertindak sebagai klien sekaligus server. Mengakses alamat layanan CLB dari server backend dalam skenario ini menyebabkan kegagalan koneksi. Pemicu umum adalah aplikasi backend yang mengalihkan ke alamat layanan CLB menggunakan penggabungan URL.

  Solusi:

  • Gunakan klien berbeda alih-alih server backend CLB Lapisan 4.

  • Migrasi ke Network Load Balancer (NLB) dan nonaktifkan fitur Preserve Client IP Address dalam grup server. Setelah Anda menonaktifkan fitur ini, instance ECS dalam grup server dapat bertindak sebagai server backend sekaligus klien untuk mengakses NLB. Untuk mendapatkan alamat IP asal, aktifkan ProxyProtocol. Untuk informasi selengkapnya, lihat Bagaimana instance ECS bertindak sebagai server backend sekaligus klien untuk NLB?.

• Penanganan paket RST yang tidak tepat untuk koneksi yang timeout

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

  Catatan

  Timeout default adalah 900 detik. Anda dapat menyesuaikan nilai ini sesuai kebutuhan.

Berapa nilai timeout yang ditentukan untuk listener HTTP dan HTTPS?

• Maksimal 100 permintaan dapat dikirim secara berurutan melalui koneksi persisten HTTP. Koneksi ditutup setelah batas ini tercapai.

• Timeout idle untuk koneksi persisten HTTP dapat dikonfigurasi dari 1 hingga 60 detik, dengan margin kesalahan potensial 1 hingga 2 detik. Koneksi TCP ditutup setelah timeout ini berakhir. Jika aplikasi Anda memerlukan koneksi persisten, konfigurasikan klien untuk mengirim permintaan heartbeat dengan interval 13 detik atau kurang.

• Timeout untuk jabat tangan tiga arah TCP antara instance CLB dan instance Elastic Compute Service (ECS) adalah 5 detik. Jika jabat tangan mengalami timeout, CLB memilih instance ECS berikutnya. Anda dapat memeriksa waktu respons upstream di log akses untuk menemukan masalah tersebut.

• Waktu tunggu instance CLB untuk respons dari instance ECS dapat dikonfigurasi dari 1 hingga 180 detik. Jika waktu tunggu mencapai timeout, CLB mengembalikan kode status HTTP 504 atau 408 ke klien. Anda dapat memeriksa waktu respons upstream di log akses untuk menemukan masalah tersebut.

• Reuse sesi HTTPS mengalami timeout setelah 300 detik. Setelah itu, klien harus melakukan jabat tangan SSL lengkap lagi.

Jika klien menutup koneksi dengan CLB sebelum klien menerima respons, apakah CLB menutup koneksi di sisi server backend?

Server Load Balancer mempertahankan koneksi ke server backend selama operasi baca/tulis.

Apakah saya dapat mengaktifkan koneksi persisten untuk instance CLB saya?

Tidak. CLB tidak mendukung pengaktifan koneksi persisten ke server backend. Untuk menerapkan fitur ini, Anda dapat membuat instance ALB dan mengonfigurasi listener HTTP atau HTTPS. Kemudian, aktifkan koneksi persisten dalam grup server ALB yang sesuai. Untuk informasi selengkapnya, lihat Buat dan kelola grup server.

Mengapa latensi jauh lebih tinggi saat mengakses layanan backend melalui CLB dibandingkan akses langsung?

Peningkatan latensi sedikit merupakan hal normal saat Anda mengakses layanan backend melalui CLB dibandingkan akses langsung. Hal ini karena listener CLB Lapisan 7 menggunakan arsitektur reverse proxy (Tengine), yang menambahkan satu hop jaringan dan overhead pemrosesan protokol. Listener Lapisan 4 menggunakan pengalihan LVS, yang menghasilkan latensi tambahan minimal.

Jika latensi jauh lebih tinggi, ikuti langkah-langkah berikut untuk troubleshooting masalah tersebut:

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

   • request_time: Waktu dari saat paket permintaan pertama diterima hingga respons dikembalikan, dalam satuan detik.

   • upstream_response_time: Waktu dari saat koneksi dibentuk dengan server backend hingga semua data diterima dan koneksi ditutup, dalam satuan detik.

2. Tentukan sumber latensi:

   • Jika nilai upstream_response_time tinggi, latensi kemungkinan berasal dari pemrosesan backend yang lambat. Selidiki kinerja aplikasi backend, efisiensi kueri database, serta penggunaan CPU dan memori, atau tambahkan server backend untuk mendistribusikan beban.

   • Jika nilai request_time jauh lebih besar daripada nilai upstream_response_time, latensi kemungkinan terjadi pada jalur jaringan antara klien dan instance CLB. Jalankan tes ping berkelanjutan atau traceroute MTR dari klien ke alamat layanan CLB untuk mengidentifikasi masalah jaringan.

3. Akses lintas wilayah: Jika klien dan instance CLB berada di wilayah berbeda, jarak fisik pasti memperkenalkan latensi jaringan. Anda dapat menggunakan Global Accelerator (GA) untuk mengoptimalkan akses lintas wilayah.

Bagaimana cara troubleshooting error 502/503/504 yang dikembalikan oleh CLB?

Saat instance CLB mengembalikan error 502, 503, atau 504, artinya permintaan tidak diproses dengan benar oleh server backend. Arti kode error tersebut adalah sebagai berikut:

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

• 503 Service Temporarily Unavailable: Error ini biasanya disebabkan oleh traffic yang melebihi batas atau ketidaktersediaan server backend. CLB mengembalikan error ini saat traffic instan melebihi batas spesifikasi instance.

• 504 Gateway Time-out: Respons server backend mengalami timeout. Penyebab umum termasuk waktu pemrosesan backend yang berlebihan atau timeout pembentukan koneksi backend.

Langkah 1: Periksa log akses

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

• Jika nilai status sama dengan nilai upstream_status, instance CLB kemungkinan meneruskan kode status abnormal dari server backend. Utamakan penyelidikan mengapa server backend mengembalikan kode status tersebut.

• Jika nilai upstream_status adalah "-" atau berbeda dari nilai status, kode error dihasilkan oleh CLB. Rujuk poin-poin berikut untuk troubleshooting.

Troubleshooting error 502

• Semua server backend gagal pemeriksaan kesehatan: Saat semua server backend yang terkait dengan listener gagal pemeriksaan kesehatan, instance CLB tidak dapat meneruskan permintaan dan mengembalikan error 502. Konfirmasi status pemeriksaan kesehatan di konsol dan selidiki penyebab kegagalannya. Misalnya, aturan security group tidak mengizinkan traffic dari 100.64.0.0/10 (blok CIDR sistem CLB), kode status pemeriksaan kesehatan tidak sesuai, atau path pemeriksaan kesehatan tidak ada. Untuk informasi selengkapnya, lihat FAQ tentang pemeriksaan kesehatan CLB.

• Server backend mengembalikan kode status abnormal yang dikonversi menjadi 502 oleh CLB: CLB mungkin mengembalikan error 502 ke klien saat server backend mengembalikan kode status abnormal tertentu, seperti 504 atau 444. Periksa field upstream_status di log akses untuk mengonfirmasi kode status aktual yang dikembalikan oleh server backend dan selidiki akar penyebabnya.

• Anomali layanan backend: Beban server backend yang tinggi, format respons yang salah, atau penutupan koneksi yang tidak terduga juga dapat menyebabkan error 502. Tinjau log server backend dan penggunaan resource, seperti CPU dan memori.

Troubleshooting error 503

• Traffic melebihi batas instance: CLB mengembalikan error 503 saat QPS, bandwidth, atau laju koneksi baru melebihi batas spesifikasi saat ini. Anda dapat memantau metrik ini menggunakan CloudMonitor.

• Traffic instan melebihi batas tetapi pemantauan tidak menunjukkannya: CloudMonitor menampilkan data tingkat menit dan mungkin melewatkan lonjakan tingkat detik. Periksa log akses untuk jumlah permintaan tingkat detik. Jika nilai upstream_status adalah "-", permintaan tidak dikirim ke server backend.

Troubleshooting error 504

• Timeout respons backend: CLB mengembalikan error 504 jika server backend tidak merespons dalam periode timeout permintaan koneksi yang dikonfigurasi. Periksa field upstream_response_time di log akses untuk memverifikasi waktu respons backend aktual dan sesuaikan periode timeout permintaan koneksi sesuai kebutuhan.

• Timeout pembentukan koneksi backend: Timeout untuk jabat tangan tiga arah TCP antara instance CLB dan instance ECS adalah 5 detik. Jika nilai upstream_response_time sangat panjang di log akses, pembentukan koneksi dengan server backend mungkin gagal. Anda dapat melakukan pengambilan paket untuk investigasi lebih lanjut.

• Beban server backend tinggi: Penggunaan CPU atau memori yang tinggi pada server backend dapat menyebabkan waktu respons melebihi timeout. Optimalkan kinerja layanan backend atau tambahkan server backend untuk mendistribusikan beban.

Bagaimana cara troubleshooting saat saya tidak dapat mengakses layanan melalui CLB?

Jika Anda tidak dapat mengakses layanan setelah mengonfigurasi CLB, ikuti langkah-langkah berikut untuk troubleshooting masalah tersebut:

1. Verifikasi resolusi nama domain: Jika Anda mengakses layanan menggunakan nama domain, verifikasi bahwa nama domain tersebut di-resolve ke alamat layanan instance CLB. Anda dapat menggunakan perintah nslookup atau dig untuk memvalidasi resolusi tersebut. Resolusi DNS yang salah merupakan penyebab umum kegagalan akses.

2. Verifikasi konfigurasi listener: Di konsol CLB, verifikasi bahwa listener telah dibuat dan port serta protokol listener dikonfigurasi dengan benar. Listener yang tidak ada atau konfigurasi port yang salah mencegah penerusan permintaan.

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

4. Konfirmasi pengaturan 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. Konfirmasi ketersediaan layanan backend: Masuk ke server backend dan gunakan telnet <IP pribadi server backend> <Port> (untuk Lapisan 4) atau curl -I http://<IP pribadi server backend> (untuk Lapisan 7) untuk memverifikasi bahwa layanan backend merespons sebagaimana mestinya.

6. Troubleshooting konektivitas jaringan: Uji akses ke alamat layanan CLB dari lingkungan jaringan berbeda. Jika hanya jaringan lokal Anda yang bermasalah, jalankan tes ping berkelanjutan atau traceroute MTR untuk investigasi lebih lanjut.

Saya tidak dapat mengakses CLB menggunakan nama domain, tetapi akses berfungsi dengan baik menggunakan alamat IP. Apa yang harus saya lakukan?

Penyebab paling umum adalah nama domain tersebut belum memiliki Pendaftaran ICP.

Sesuai peraturan, nama domain yang menyediakan akses jaringan publik di Tiongkok daratan harus memiliki Pendaftaran ICP. Nama domain yang belum terdaftar akan diblokir, yang mengakibatkan kode status 403 atau reset koneksi.

Ikuti langkah-langkah berikut untuk troubleshooting dan menyelesaikan masalah tersebut:

1. Konfirmasi status Pendaftaran ICP nama domain: Masuk ke Sistem Pendaftaran ICP Alibaba Cloud untuk memeriksa apakah nama domain telah terdaftar. Jika belum, lengkapi Pendaftaran ICP terlebih dahulu. Untuk informasi selengkapnya, lihat Proses Pendaftaran ICP.

2. Konfirmasi apakah pendaftaran penyedia layanan diperlukan: Jika nama domain telah didaftarkan dengan penyedia cloud lain tetapi digunakan di Alibaba Cloud untuk pertama kalinya, Anda harus melakukan pendaftaran penyedia layanan untuk menambahkan Alibaba Cloud sebagai penyedia layanan dalam informasi pendaftaran. Kegagalan menyelesaikan pendaftaran penyedia layanan juga dapat memblokir akses.

3. Hilangkan penyebab lain: Jika nama domain telah terdaftar dan pendaftaran penyedia layanan telah selesai, verifikasi bahwa resolusi DNS mengarah ke alamat layanan CLB. Anda dapat memvalidasi hal ini menggunakan nslookup atau dig. Selain itu, verifikasi bahwa konfigurasi port dan protokol listener CLB sesuai dengan metode akses nama domain.

Mengapa persistensi sesi gagal dalam beberapa skenario?

• Persistensi sesi tidak diaktifkan: Verifikasi bahwa persistensi sesi diaktifkan dalam konfigurasi listener.

• Masalah listener HTTP/HTTPS: Listener HTTP atau HTTPS tidak dapat menyisipkan cookie persistensi sesi ke respons yang memiliki kode status 4xx.

  Solusi: Gunakan listener TCP sebagai gantinya. Listener TCP mempertahankan sesi berdasarkan alamat IP sumber klien. Atau, Anda dapat mengonfigurasi instance ECS backend untuk menyisipkan dan memvalidasi cookie guna meningkatkan keandalan.

• Masalah pengalihan 302: Pengalihan 302 dapat mengubah string SERVERID yang digunakan untuk persistensi sesi. Saat instance CLB menyisipkan cookie ke respons yang memiliki kode status HTTP 302, string SERVERID berubah, yang memutus persistensi sesi.

  Saat Server Load Balancer menyisipkan cookie, jika instance ECS backend mengembalikan pesan pengalihan 302, string SERVERID untuk persistensi sesi berubah, yang menyebabkan kegagalan persistensi sesi.

  Untuk mendiagnosis masalah ini, Anda dapat menangkap permintaan dan respons di browser atau menggunakan perangkat lunak pengambilan paket untuk memeriksa respons 302 dan membandingkan string SERVERID dalam cookie sebelum dan sesudah pengalihan.

  Solusi: Gunakan listener TCP sebagai gantinya. Listener TCP mempertahankan sesi berdasarkan alamat IP sumber klien. Atau, Anda dapat mengonfigurasi instance ECS backend untuk menyisipkan dan memvalidasi cookie guna meningkatkan keandalan.

• Timeout persistensi sesi terlalu singkat: Menetapkan periode timeout yang singkat dapat menyebabkan kegagalan persistensi sesi.

Bagaimana cara melihat string persistensi sesi?

Anda dapat membuka browser dan menekan F12 untuk memeriksa apakah respons berisi string SERVERID atau kata kunci yang ditentukan pengguna. Atau, Anda dapat menjalankan curl www.example.com -c /tmp/cookie123 untuk menyimpan cookie, lalu menjalankan curl www.example.com -b /tmp/cookie123 untuk mengakses situs tersebut.

Bagaimana cara menguji persistensi sesi menggunakan perintah curl Linux?

1. Buat halaman uji.

   Pada setiap instance ECS backend, buat halaman uji yang menampilkan alamat IP pribadi instance tersebut. Alamat IP pribadi mengidentifikasi server yang menangani permintaan. Jika alamat IP yang sama dikembalikan untuk setiap permintaan, persistensi sesi berhasil.

   

2. Jalankan perintah curl di 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 uji Linux.

   2. Jalankan perintah berikut untuk mengambil cookie yang ditetapkan oleh server CLB:

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

      Catatan

      Secara default, CLB mempertahankan sesi dengan menyisipkan cookie. Namun, curl tidak menyimpan atau mengirim cookie secara default. Oleh karena itu, Anda harus menyimpan cookie sebelum pengujian. Jika tidak, hasil uji curl akan tampak acak dan secara salah menunjukkan bahwa persistensi sesi gagal.

   3. Anda dapat menjalankan 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 iterasi uji dan dapat disesuaikan sesuai kebutuhan. Ganti grep '10.170.XX.XX' dengan alamat IP pribadi instance ECS Anda.

   4. Periksa alamat IP yang dikembalikan oleh pengujian. Jika alamat IP pribadi ECS yang sama muncul secara konsisten, persistensi sesi berfungsi. Jika tidak, persistensi sesi gagal.

Mengapa stylesheet gagal dimuat saat saya membuka website melalui listener HTTPS?

Fenomena:

Anda membuat listener HTTP dan listener HTTPS yang menggunakan server backend yang sama. Saat Anda mengakses website melalui listener HTTP dengan nomor port yang ditentukan, website ditampilkan dengan benar. Namun, saat Anda mengakses website melalui listener HTTPS, tata letaknya terdistorsi.

Penyebab:

Secara default, CLB tidak memblokir pemuatan atau transfer file JavaScript. Kemungkinan penyebab meliputi:

• Sertifikat tidak kompatibel dengan tingkat keamanan browser.

• Sertifikat adalah sertifikat pihak ketiga yang tidak valid. Hubungi penerbit sertifikat untuk memverifikasi validitas sertifikat tersebut.

Solusi:

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

2. Tambahkan sertifikat yang diperlukan ke klien.

Jika saya mengaktifkan pengalihan traffic dari listener HTTP ke listener HTTPS, apakah saya perlu menerapkan sertifikat pada server backend?

Tidak. Anda hanya perlu menerapkan sertifikat pada instance CLB dan mengonfigurasinya untuk listener HTTPS. Untuk informasi selengkapnya, lihat Konfigurasi sertifikat SSL.

Setelah CLB memperbarui sertifikat, waktu kedaluwarsa sertifikat nama domain yang ditampilkan di browser tetap tidak berubah.

Masalah ini biasanya terjadi jika instance CLB Anda diintegrasikan dengan WAF 2.0 dalam mode proxy transparan. Dalam mode ini, sertifikat di sisi WAF tidak segera diperbarui. WAF menyinkronkan sertifikat dari CLB secara berkala. Untuk memaksa pembaruan segera, Anda dapat membuka konsol WAF, menonaktifkan pengalihan traffic untuk domain yang dilindungi, lalu segera mengaktifkannya kembali. Tindakan ini memaksa WAF untuk menyegarkan status sertifikatnya dari CLB. Perhatikan bahwa operasi ini menyebabkan gangguan layanan singkat sekitar 1 hingga 2 detik.

Versi HTTP mana yang digunakan oleh listener HTTP dan HTTPS saat mengakses server backend?

• Jika klien mengirim permintaan melalui HTTP/1.1 atau HTTP/2, listener Lapisan 7 menggunakan HTTP/1.1 untuk meneruskan permintaan ke server backend.

• Jika klien mengirim permintaan melalui protokol selain HTTP/1.1 dan HTTP/2, listener Lapisan 7 menggunakan HTTP/1.0 untuk meneruskan permintaan ke server backend.

Apakah server backend dapat memperoleh versi protokol yang digunakan klien untuk mengakses listener HTTP atau HTTPS?

Ya.

Apakah CLB mendukung pembatasan laju QPS pada URL tertentu?

CLB tidak mendukung pembatasan laju berbasis URL. Pembatasan bandwidth hanya didukung pada dimensi listener.

ALB mendukung pembatasan laju berbasis URL. Anda dapat mengonfigurasi aturan pengalihan listener untuk menetapkan batas laju QPS untuk path tertentu. Hal ini memerlukan penggunaan aksi pengalihan Forward To. Untuk informasi selengkapnya, lihat gambar berikut:

Bagaimana cara mengaktifkan perlindungan WAF untuk CLB?

Jika saya menonaktifkan network interface controller (NIC) jaringan publik, apakah layanan CLB saya terpengaruh?

Ya. Jika instance Elastic Compute Service (ECS) memiliki alamat IP publik, menonaktifkan network interface controller (NIC) jaringan publik akan memengaruhi layanan CLB.

Secara default, jika instance ECS memiliki alamat IP publik, instance tersebut menggunakan alamat IP ini untuk komunikasi. Traffic mengalir melalui NIC publik instance ECS. Jika Anda menonaktifkan NIC publik, instance ECS tidak dapat mengirim respons ke Internet. Kami menyarankan agar Anda tidak menonaktifkan NIC publik instance ECS Anda. Jika Anda harus menonaktifkannya, ubah tujuan rute default ke alamat IP pribadi untuk menghindari gangguan layanan. Selain itu, konfirmasi apakah layanan Anda memerlukan akses Internet, seperti mengakses instance ApsaraDB RDS melalui Internet.

Jika permintaan sudah membawa header TCP Option Address (TOA) sebelum dikirim ke CLB, apakah CLB dapat mempertahankan alamat IP klien dalam header tersebut?

Tidak. Permintaan klien yang membawa header TCP Option Address (TOA) bertentangan dengan header TOA yang digunakan secara internal oleh CLB. Konflik ini mencegah pengambilan alamat IP asal klien.