Server Load Balancer：FAQ tentang listener CLB

Apakah Classic Load Balancer (CLB) mendukung port forwarding?

Ya, benar.

CLB mendukung pengalihan port. Untuk informasi selengkapnya, lihat Redirect requests from HTTP to HTTPS.

Apakah listener Lapisan 4 CLB dapat melakukan listening pada range port?

Tidak. Untuk mengonfigurasi listener TCP atau UDP agar mendengarkan pada range port, buat instans Network Load Balancer (NLB) dan aktifkan fitur full-port untuk listener TCP atau UDP tersebut. Untuk informasi selengkapnya, lihat Use the full-port listening feature of NLB to forward traffic from multiple ports.

Apa yang perlu saya pertimbangkan saat mengonfigurasi port listener untuk instans CLB?

Beberapa ISP menandai port seperti 25, 135, 139, 444, 445, 5800, dan 5900 sebagai port yang rentan dan memblokirnya secara default. Bahkan jika Anda menambahkan aturan ke security group untuk mengizinkan traffic ke port-port tersebut, pengguna di wilayah yang dibatasi tidak dapat mengakses layanan Anda. Kami menyarankan agar Anda menggunakan port lain yang tidak dianggap rentan untuk layanan Anda.

• Untuk informasi selengkapnya tentang port untuk aplikasi Windows Server, lihat Dokumentasi Microsoft: Service overview and network port requirements for Windows.

• Untuk informasi selengkapnya tentang port umum, lihat Common Ports.

Apakah Server Load Balancer mendukung permintaan client yang berisi field TOA?

Tidak. Field TCP Option Address (TOA) dalam permintaan client bertentangan dengan field TOA yang digunakan untuk interaksi internal di Server Load Balancer, sehingga mencegah SLB memperoleh alamat IP asal klien.

Bagaimana cara mengonfigurasi listener jika WebSocket atau WebSocket Secure diterapkan pada server backend?

• Jika WebSocket diterapkan pada server backend, Anda dapat mengonfigurasi listener TCP atau listener HTTP.

• Jika WebSocket Secure diterapkan pada server backend, Anda dapat mengonfigurasi listener TCP atau listener HTTPS.

Bagaimana modifikasi pada listener CLB diterapkan dan apa dampaknya?

Modifikasi diterapkan secara langsung dan hanya berlaku untuk permintaan baru. Koneksi yang sudah ada tidak terpengaruh.

Bagaimana cara mengaktifkan proteksi WAF untuk instans CLB?

Apakah menonaktifkan network interface card jaringan publik memengaruhi layanan Server Load Balancer?

Jika sebuah instans ECS memiliki alamat IP publik, menonaktifkan network interface card (NIC) jaringan publiknya akan memengaruhi layanan Server Load Balancer.

Hal ini karena rute default menggunakan jaringan publik saat NIC publik tersedia. Jika Anda menonaktifkan NIC tersebut, instans ECS tidak dapat mengirim paket respons, yang mengganggu layanan SLB. Kami menyarankan agar Anda tidak menonaktifkan NIC publik. Jika Anda harus menonaktifkannya, ubah rute default ke jaringan pribadi untuk memastikan kelangsungan layanan. Namun, pertimbangkan apakah bisnis Anda bergantung pada jaringan publik, misalnya mengakses ApsaraDB RDS melalui Internet.

Dalam beberapa skenario khusus, mengapa koneksi gagal mencapai bandwidth puncak?

• Skenario: Anda membeli instans CLB public-facing dengan metode penagihan bayar-per-bandwidth. Dalam beberapa skenario khusus, seperti melakukan uji stres pada satu client atau mentransmisikan paket data berukuran besar, koneksi mungkin gagal mencapai bandwidth puncak.

• Penyebab:

  Sistem Server Load Balancer menggunakan kluster server untuk menyediakan layanan bagi instans CLB. Semua permintaan eksternal didistribusikan secara merata ke server-server tersebut untuk diteruskan. Oleh karena itu, bandwidth puncak yang ditentukan juga didistribusikan secara merata di antara server-server tersebut.

  Rumus untuk menghitung traffic unduh maksimum untuk satu koneksi adalah: Kecepatan unduh puncak per koneksi = Total bandwidth yang dikonfigurasi untuk CLB / (N - 1), di mana N adalah jumlah node pekerja dalam kluster. N bernilai 4 untuk listener Lapisan 4 dan 8 untuk listener Lapisan 7. Sebagai contoh, jika Anda menetapkan bandwidth maksimum menjadi 10 Mbit/s di konsol CLB, total bandwidth dapat mencapai 10 Mbit/s jika beberapa client digunakan secara bersamaan. Traffic unduh maksimum untuk satu client adalah 10 / (4 - 1) = 3,33 Mbit/s.

• Solusi:

  • Instans CLB menggunakan metode penagihan bayar-berdasarkan-transfer-data untuk traffic jaringan publik.

  • Gunakan instans NLB atau ALB dengan EIP dan instans Bandwidth Internet Bersama. Solusi ini memberikan elastisitas yang cukup untuk instans load balancer dan tidak memiliki batasan ini.

Mengapa terjadi kehilangan paket meskipun data pemantauan menunjukkan bahwa penggunaan bandwidth tidak melebihi spesifikasi?

Masalah ini biasanya terjadi karena alasan berikut:

• Data pemantauan bandwidth yang disediakan oleh Alibaba Cloud merupakan nilai rata-rata per menit. Jika traffic instan dalam satu detik tertentu dalam satu menit melebihi batas bandwidth instans, tetapi bandwidth rata-rata selama satu menit penuh tidak melebihi batas yang ditentukan, penggunaan bandwidth keseluruhan yang ditampilkan di grafik pemantauan akan lebih rendah daripada spesifikasi bandwidth.

• Sistem Server Load Balancer menggunakan penerapan kluster untuk menyediakan layanan bagi instans CLB. Semua permintaan akses eksternal didistribusikan secara merata ke server-server tersebut untuk diteruskan. Bandwidth puncak yang dikonfigurasi juga dialokasikan secara merata di seluruh server tersebut. Jika volume data dari unduhan yang diminta oleh koneksi client melebihi ambang batas satu server, traffic akan di-drop. Untuk informasi selengkapnya, lihat metode perhitungan batas atas traffic unduh untuk satu koneksi di Mengapa koneksi gagal mencapai bandwidth maksimum dalam skenario tertentu?.

Dalam beberapa skenario khusus, mengapa instans CLB gagal mencapai QPS puncak?

• Skenario: Dalam skenario bisnis yang menggunakan sejumlah kecil koneksi persisten, server sistem dalam grup penerusan mungkin tidak semuanya dialokasikan koneksi persisten. Hal ini menyebabkan instans CLB gagal mencapai permintaan per detik (QPS) puncak.

• Penyebab:

  Sistem Server Load Balancer menggunakan kluster server untuk menyediakan layanan bagi instans load balancer. Semua permintaan eksternal didistribusikan secara merata ke server-server tersebut untuk diteruskan. Oleh karena itu, QPS puncak instans CLB didistribusikan secara merata di antara server-server tersebut.

  QPS maksimum setiap server backend dihitung menggunakan rumus berikut: QPS maksimum setiap server backend = Total QPS/(N - 1). N adalah jumlah server backend dalam grup server. Sebagai contoh, jika Anda membeli instans CLB dengan spesifikasi Small I (slb.s1.small) di konsol CLB, QPS maksimumnya adalah 1.000. Saat beberapa client digunakan secara bersamaan, total QPS dapat mencapai 1.000. Jika jumlah server backend adalah 8, QPS maksimum setiap server backend adalah 1000/(8 - 1) = 142 QPS.

  Catatan

• Solusi:

  • Gunakan koneksi singkat pada satu client untuk uji stres.

  • Kurangi penggunaan ulang koneksi sesuai kebutuhan.

  • Tingkatkan spesifikasi instans CLB. Untuk informasi selengkapnya, lihat Pay-as-you-go (billed by specification) upgrade or downgrade.

  • Gunakan instans ALB. Solusi ini memberikan elastisitas yang cukup untuk instans load balancer.

Mengapa laju koneksi baru gagal mencapai nilai puncak dalam beberapa skenario?

• Skenario: Saat Anda membeli instans Classic Load Balancer (CLB) dengan metode penagihan berdasarkan spesifikasi, laju koneksi baru (CPS) mungkin gagal mencapai level yang ditentukan dalam beberapa skenario, seperti uji stres pada satu client atau akses dari satu sumber.

  Catatan

• Penyebab:

  Sistem Server Load Balancer menggunakan arsitektur penerapan kluster untuk memastikan ketersediaan tinggi dan skalabilitas. Operasi koneksi untuk semua permintaan akses eksternal didistribusikan secara merata ke beberapa server sistem dalam kluster untuk diproses. Oleh karena itu, CPS puncak instans CLB didistribusikan secara merata di antara server-server tersebut.

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

  Sebagai contoh, jika Anda membeli instans CLB dengan tipe instans slb.s1.small, CPS nominalnya adalah 3.000. Saat beberapa client mengakses instans CLB secara bersamaan, CPS keseluruhan dapat mencapai 3.000. Jika jumlah server sistem adalah 4, batas atas CPS satu server adalah 3000/(4−1)=1000 CPS.

• Solusi:

  • Ubah metode penagihan instans CLB: Ubah metode penagihan instans CLB dari berdasarkan spesifikasi ke metode pay-as-you-go yang lebih fleksibel. Anda tidak perlu menentukan tipe instans untuk instans CLB pay-as-you-go. Instans CLB pay-as-you-go menyediakan performa yang lebih tinggi daripada sebagian besar instans berbasis spesifikasi dan mencegah masalah performa akibat spesifikasi yang terlalu kecil.

  • Tingkatkan ke Network Load Balancer (NLB): Untuk skenario dengan konkurensi tinggi dan jumlah koneksi baru yang besar, kami menyarankan Anda menggunakan NLB. Dibandingkan dengan CLB, NLB menyediakan performa yang jauh lebih baik dan menawarkan elastisitas yang lebih tinggi. NLB dapat menangani koneksi konkuren berskala besar secara lebih efektif dan mencegah CPS yang tidak mencukupi akibat jumlah server sistem yang terbatas di CLB.

Berapa periode timeout koneksi yang didukung oleh listener yang berbeda?

• Timeout koneksi listener TCP: 10 hingga 900 detik.

• Pendengar HTTP:

  • Timeout koneksi idle: 1 hingga 60 detik.

  • Timeout permintaan koneksi: 1 hingga 180 detik.

• Listener HTTPS:

  • Timeout koneksi idle: 1 hingga 60 detik.

  • Timeout permintaan koneksi: 1 hingga 180 detik.

Mengapa koneksi ke titik akhir Server Load Balancer mengalami timeout?

Dari perspektif sisi server, situasi berikut dapat menyebabkan koneksi ke titik akhir mengalami timeout:

• Titik akhir dilindungi oleh fitur keamanan.

  Contohnya termasuk blackholing traffic, scrubbing, dan proteksi WAF. WAF mengirim pesan RST ke client dan kluster server setelah koneksi terbentuk.

• Client memiliki port yang tidak mencukupi.

  Masalah ini terutama umum terjadi selama uji stres. Port client yang tidak mencukupi dapat menyebabkan kegagalan koneksi. Secara default, Server Load Balancer menghapus atribut timestamp 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 port client tidak mencukupi.

  Solusi: Gunakan koneksi persisten alih-alih koneksi singkat di sisi client. Gunakan pesan RST untuk memutus koneksi dengan mengatur atribut SO_LINGER untuk socket, alih-alih mengirim paket FIN.

• Antrean accept server backend penuh.

  Jika antrean accept server backend penuh, server backend tidak membalas dengan pesan SYN-ACK, dan client mengalami timeout.

  Solusi: Nilai default net.core.somaxconn adalah 128. Sesuaikan nilai ini berdasarkan beban kerja Anda untuk memenuhi kebutuhan aktual. Jalankan perintah sysctl -w net.core.somaxconn=<new_value> untuk mengubah parameter tersebut. Kemudian, restart aplikasi di server backend.

• Titik akhir load balancer Lapisan 4 diakses dari server backend load balancer tersebut.

  Untuk load balancing Lapisan 4, mengakses titik akhir load balancer dari salah satu server backend-nya menyebabkan kegagalan koneksi. Skenario umum adalah ketika aplikasi backend menggunakan penggabungan URL untuk mengarahkan ulang akses.

• Penanganan RST yang tidak tepat untuk timeout koneksi.

  Setelah Server Load Balancer membentuk koneksi TCP, jika tidak ada aktivitas selama 900 detik, ia mengirim pesan RST ke client dan server untuk memutus koneksi. Beberapa aplikasi tidak menangani pengecualian RST dengan baik dan mungkin mengirim data lagi pada koneksi yang sudah ditutup, menyebabkan aplikasi mengalami timeout.

  Catatan

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

Bagaimana periode timeout koneksi HTTP dan HTTPS ditentukan?

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

• Periode timeout antara dua permintaan HTTP atau HTTPS melalui koneksi persisten HTTP dapat dikonfigurasi. Nilainya berkisar antara 1 hingga 60 detik, dengan kemungkinan margin kesalahan 1 hingga 2 detik. Koneksi TCP akan ditutup setelah periode timeout berakhir. Untuk menggunakan koneksi persisten, coba kirim permintaan heartbeat dalam waktu kurang dari 13 detik.

• Timeout jabat tangan tiga arah TCP antara Server Load Balancer dan instans ECS backend adalah 5 detik. Setelah timeout, instans ECS yang tersedia berikutnya dipilih. Anda dapat mengidentifikasi masalah ini dengan mengkueri waktu respons upstream di log akses.

• Waktu tunggu Server Load Balancer untuk respons dari instans ECS dapat dikonfigurasi. Nilainya berkisar antara 1 hingga 180 detik. Setelah timeout, kode respons 504 atau 408 biasanya dikembalikan ke client. Anda dapat mengidentifikasi masalah ini dengan mengkueri waktu respons upstream di log akses.

• Timeout reuse sesi HTTPS adalah 300 detik. Setelah periode ini, client yang sama perlu melakukan jabat tangan SSL penuh lagi.

Jika client memutus koneksi dari Server Load Balancer sebelum menerima respons dari server backend, apakah Server Load Balancer juga memutus koneksi dari server backend?

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

Bagaimana cara mengaktifkan koneksi persisten backend untuk instans Classic Load Balancer (CLB)?

Instans CLB tidak mendukung koneksi backend persisten. Untuk menggunakan fitur ini, buat instans ALB, konfigurasikan listener HTTP atau HTTPS, dan aktifkan koneksi backend persisten pada grup server ALB yang sesuai. Untuk informasi selengkapnya, lihat Create and manage server groups.

Mengapa persistensi sesi kadang-kadang gagal?

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

• Masalah listener HTTP/HTTPS: Listener HTTP atau HTTPS tidak dapat menyisipkan cookie yang diperlukan untuk persistensi sesi ke dalam pesan respons dengan kode respons 4xx dari server backend.

  Solusi: Gunakan listener TCP sebagai gantinya. Listener TCP melakukan persistensi sesi berdasarkan alamat IP asal klien. Selain itu, Anda dapat menyisipkan cookie di instans ECS backend dan menambahkan pemeriksaan cookie untuk jaminan tambahan.

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

  Saat Server Load Balancer menyisipkan cookie, jika instans ECS backend mengembalikan pesan respons dengan pengalihan 302, string SERVERID dalam cookie persistensi sesi berubah, sehingga menyebabkan kegagalan persistensi sesi.

  Pemecahan masalah: Tangkap permintaan dan respons di sisi browser, atau gunakan perangkat lunak pengambilan paket untuk menganalisis apakah ada pesan respons 302. Bandingkan string SERVERID dalam cookie pesan sebelum dan sesudah untuk memeriksa apakah nilainya berbeda.

  Solusi: Gunakan listener TCP sebagai gantinya. Listener TCP melakukan persistensi sesi berdasarkan alamat IP asal klien. Selain itu, Anda dapat menyisipkan cookie di instans 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.

Bagaimana cara melihat string persistensi sesi?

Anda dapat menekan F12 di browser untuk memeriksa pesan respons guna mencari string 'SERVERID' atau kata kunci yang ditentukan pengguna, atau jalankan curl www.example.com -c /tmp/cookie123 untuk menyimpan cookie, lalu jalankan curl www.example.com -b /tmp/cookie123 untuk mengakses website.

Bagaimana cara menggunakan perintah curl Linux untuk menguji fitur persistensi sesi Server Load Balancer?

1. Buat halaman uji.

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

   

2. Jalankan perintah curl di sistem Linux.

   Dalam contoh ini, alamat IP layanan Server 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 digunakan untuk pengujian.

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

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

      Catatan

      Mode persistensi sesi default Alibaba Cloud Server Load Balancer adalah menyisipkan cookie. Namun, pengujian curl tidak menyimpan atau mengirim cookie secara default. Oleh karena itu, Anda harus terlebih dahulu menyimpan cookie yang sesuai untuk pengujian. Jika tidak, hasil pengujian curl bersifat acak, dan Anda mungkin 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 menunjukkan jumlah pengujian yang akan dilakukan. Anda dapat mengatur nilai ini sesuai kebutuhan. Atur alamat IP di grep '10.170.XX.XX' ke alamat IP pribadi instans ECS Anda.

   4. Amati alamat IP yang dikembalikan oleh pengujian di atas. Jika alamat IP pribadi yang sama dari instans ECS dikembalikan, persistensi sesi berfungsi. Jika tidak, terdapat masalah pada persistensi sesi.

Mengapa saya dapat mengakses website melalui listener HTTP tetapi tampilan website gagal dimuat saat saya mengakses website melalui listener HTTPS?

Gejala:

Anda membuat listener HTTP dan listener HTTPS yang menggunakan server backend yang sama. Saat Anda mengakses website yang sesuai dengan port listening melalui HTTP, website ditampilkan secara normal. Namun, saat Anda mengakses website melalui listener HTTPS, tata letak website menjadi rusak.

Penyebab:

Secara default, Server Load Balancer tidak memblokir pemuatan dan transmisi file JS. Penyebab yang mungkin adalah sebagai berikut:

• Sertifikat tidak kompatibel dengan tingkat keamanan browser.

• Sertifikat berasal dari 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 client.

Versi protokol HTTP mana yang digunakan saat listener HTTP atau HTTPS mengakses server backend?

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

• Jika permintaan client menggunakan protokol selain HTTP 1.1 dan HTTP 2.0, listener Lapisan 7 menggunakan HTTP 1.0 untuk mengakses server backend.

Dapatkah server backend memperoleh versi protokol yang digunakan client untuk mengakses listener HTTP atau HTTPS?

Ya, bisa.

Setelah saya mengonfigurasi pengalihan HTTP-ke-HTTPS untuk instans CLB, apakah saya masih perlu mengonfigurasi sertifikat di server backend?

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

Apakah CLB mendukung pembatasan bandwidth berdasarkan URL?

CLB tidak mendukung pembatasan bandwidth berdasarkan URL. CLB hanya mendukung pembatasan bandwidth untuk listener.

ALB mendukung pembatasan laju berdasarkan URL. Anda dapat mengonfigurasi aturan pengalihan listener untuk menetapkan batas laju berbasis QPS untuk path tertentu. Fitur ini memerlukan aksi pengalihan 'Forward to'. Lihat gambar berikut: