Server Load Balancer:FAQ tentang pendengar CLB

Apakah Classic Load Balancer (CLB) mendukung pengalihan port?

Fitur ini didukung.

CLB mendukung pengalihan port. Untuk contoh, lihat Mengalihkan permintaan HTTP ke HTTPS menggunakan CLB.

Apakah pendengar Lapisan 4 CLB mendukung range port?

Tidak. Untuk mengonfigurasi pendengar TCP atau UDP untuk range port, Anda dapat membuat instance Network Load Balancer (NLB) dan mengaktifkan fitur full-port untuk pendengar TCP atau UDP tersebut. Untuk informasi selengkapnya, lihat Menggunakan fitur pendengaran full-port NLB untuk meneruskan traffic dari beberapa port.

Apa yang perlu saya ketahui saat mengonfigurasi port pendengar untuk instance 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 mengizinkan port-port tersebut dalam aturan security group, pengguna di wilayah yang terkena dampak tidak dapat mengaksesnya. Oleh karena itu, sebaiknya gunakan port non-rentan lainnya untuk layanan Anda.

• Untuk informasi lebih lanjut tentang port yang digunakan oleh Windows Server, lihat dokumentasi Microsoft Ikhtisar layanan dan persyaratan port jaringan untuk Windows.

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

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

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

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

Kapan dan bagaimana perubahan konfigurasi pendengar CLB berlaku, serta apa dampaknya?

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

Mengapa saya tidak dapat mengakses URL yang berisi karakter khusus setelah mengonfigurasi aturan pengalihan URL?

Karakter khusus dalam URL harus dikodekan dengan URL encoding sebelum dapat diakses. Misalnya, tanda pagar (#) harus dikodekan sebagai %23. URL aksesnya harus berupa http://www.example.com/%23/. Untuk aturan pengkodean lengkap, lihat RFC 3986.

Bagaimana cara mengelola server backend untuk aturan pengalihan CLB?

Pada halaman aturan pengalihan, klik nama grup server target di kolom vServer Group. Pada halaman yang muncul, Anda dapat menambahkan, menghapus, atau mengubah port atau bobot server backend.

Mengapa traffic dibuang meskipun data pemantauan menunjukkan bahwa bandwidth tidak melebihi spesifikasi?

Masalah ini biasanya disebabkan oleh alasan berikut:

• Data pemantauan bandwidth dari Alibaba Cloud dihitung berdasarkan rata-rata satu menit. Jika traffic instan melebihi batas bandwidth instance, traffic akan dibuang. Grafik pemantauan mungkin tidak menunjukkan hal ini karena menampilkan nilai rata-rata. Selama bandwidth rata-rata selama satu menit tidak melebihi batas, grafik akan menunjukkan bahwa penggunaan bandwidth masih dalam spesifikasi.

• Sistem SLB menyediakan layanan untuk instance CLB dalam penerapan kluster. Semua permintaan akses eksternal didistribusikan secara merata ke server sistem SLB ini untuk diteruskan. Batas bandwidth yang ditentukan didistribusikan di antara beberapa server sistem. Jika jumlah data yang diunduh oleh koneksi client melebihi ambang batas server tunggal, traffic akan dibuang. Untuk informasi lebih lanjut tentang cara menghitung traffic maksimum untuk koneksi tunggal, lihat Mengapa koneksi tidak dapat mencapai batas bandwidth dalam beberapa skenario?

Mengapa traffic pendengar yang ditampilkan dalam data pemantauan lebih besar daripada batas kecepatan yang dikonfigurasi?

Sistem SLB menyediakan layanan untuk instance CLB dalam penerapan kluster dan menggunakan pembatasan kecepatan terdistribusi. Rumusnya adalah: Batas bandwidth node tunggal = Total bandwidth instance SLB / (N - 1), di mana N adalah jumlah node anak dalam kluster. Oleh karena itu, batas kecepatan keseluruhan sedikit lebih tinggi daripada nilai yang dikonfigurasi.

Mengapa koneksi tidak dapat mencapai batas bandwidth dalam beberapa skenario?

• Skenario: Saat Anda menggunakan instance CLB yang menghadap publik dengan metode penagihan bayar-per-bandwidth, koneksi mungkin tidak mencapai batas bandwidth dalam beberapa skenario, seperti selama uji stres dari client tunggal atau saat mentransmisikan paket data berukuran besar.

• Cara kerja:

  Sistem SLB menyediakan layanan untuk instance load balancer dalam penerapan kluster. Semua permintaan akses eksternal didistribusikan secara merata ke server sistem SLB untuk diteruskan. Oleh karena itu, batas bandwidth yang ditentukan didistribusikan di antara server-server sistem ini.

  Rumus untuk menghitung bandwidth unduh maksimum untuk koneksi tunggal adalah: Bandwidth unduh maksimum untuk koneksi tunggal = Total bandwidth instance SLB / (N - 1), di mana N adalah jumlah node anak dalam kluster. N bernilai 4 untuk pendengar Lapisan 4 dan 8 untuk pendengar Lapisan 7. Misalnya, jika Anda menetapkan batas bandwidth menjadi 10 Mbps di konsol, total bandwidth dapat mencapai 10 Mbps saat beberapa client digunakan secara bersamaan. Bandwidth unduh maksimum untuk client tunggal adalah 10 / (4 - 1) = 3,33 Mbps.

• Solusi yang direkomendasikan:

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

  • Gunakan instance Network Load Balancer (NLB) atau Application Load Balancer (ALB) dengan EIP dan instance Internet Shared Bandwidth. Solusi ini memberikan elastisitas yang cukup untuk instance load balancer dan tidak memiliki batasan ini.

Mengapa instance CLB tidak dapat mencapai batas QPS dalam beberapa skenario?

• Skenario: Dalam skenario bisnis yang menggunakan sejumlah kecil koneksi persisten, server sistem dalam grup penerusan mungkin tidak semuanya diberi koneksi persisten. Hal ini dapat menyebabkan instance CLB gagal mencapai batas queries-per-second (QPS).

• Penyebab:

  Sistem SLB menyediakan layanan untuk instance load balancer dalam penerapan kluster. Semua permintaan akses eksternal didistribusikan secara merata ke server sistem SLB untuk diteruskan. Oleh karena itu, batas QPS instance CLB didistribusikan di antara server-server sistem ini.

  Rumus untuk menghitung batas QPS server sistem tunggal adalah: Batas QPS server sistem tunggal = Total QPS instance / (N - 1), di mana N adalah jumlah server sistem dalam grup penerusan. Misalnya, jika Anda membeli instance CLB tipe instans slb.s1.small, QPS-nya adalah 1.000. Saat beberapa client digunakan secara bersamaan, total QPS dapat mencapai 1.000. Jika jumlah server sistem adalah 8, QPS maksimum server sistem tunggal adalah 1.000 / (8 - 1) = 142.

  Catatan

• Solusi:

  • Gunakan koneksi singkat dari client tunggal untuk uji stres.

  • Kurangi penggunaan ulang koneksi sesuai kebutuhan.

  • Tingkatkan tipe instans instance CLB. Untuk informasi selengkapnya, lihat Tingkatkan atau turunkan spesifikasi instance berbayar sesuai penggunaan (bayar-per-spesifikasi).

  • Gunakan instance Application Load Balancer (ALB). Solusi ini memberikan elastisitas yang cukup untuk instance load balancer.

Mengapa laju koneksi baru tidak dapat mencapai batas dalam beberapa skenario?

• Skenario: Saat Anda menggunakan instance Classic Load Balancer (CLB) dengan metode penagihan bayar-per-spesifikasi, laju koneksi baru per detik (CPS) mungkin tidak mencapai tingkat yang ditentukan dalam beberapa skenario, seperti selama uji stres dari client tunggal atau sumber akses tunggal.

  Catatan

• Penyebab:

  Sistem SLB menggunakan arsitektur penerapan kluster untuk memastikan ketersediaan tinggi dan skalabilitas. Semua operasi koneksi untuk permintaan akses eksternal didistribusikan secara merata ke beberapa server sistem dalam kluster untuk diproses. Oleh karena itu, batas CPS instance CLB didistribusikan di antara server-server ini.

  Rumus untuk menghitung batas CPS server sistem tunggal adalah: Batas CPS server sistem tunggal = Total CPS instance / (N - 1), di mana N adalah jumlah server sistem dalam grup penerusan.

  Misalnya, jika Anda membeli instance CLB tipe instans slb.s1.small, CPS nominalnya adalah 3.000. Saat beberapa client mengakses instance secara bersamaan, CPS keseluruhan dapat mencapai 3.000. Jika jumlah server sistem adalah 4, batas CPS server tunggal adalah 3.000 / (4 - 1) = 1.000.

• Solusi:

  • Ubah metode penagihan instance CLB: Ubah metode penagihan instance CLB dari bayar-per-spesifikasi ke metode pay-as-you-go yang lebih fleksibel. Instance CLB pay-as-you-go tidak mengharuskan Anda menentukan tipe instans dan memiliki batas kinerja yang lebih tinggi daripada sebagian besar instance bayar-per-spesifikasi. Hal ini mencegah masalah kinerja yang disebabkan oleh spesifikasi yang terlalu kecil.

  • Tingkatkan ke Network Load Balancer (NLB): Untuk skenario dengan konkurensi tinggi dan permintaan tinggi terhadap koneksi baru, gunakan layanan NLB. NLB menyediakan kinerja dan elastisitas yang lebih baik daripada CLB. Satu instance NLB mendukung 100 juta koneksi bersamaan, sehingga cocok untuk skenario koneksi bersamaan berskala besar. Hal ini membantu menghindari CPS yang tidak mencukupi akibat jumlah terbatas server sistem dalam CLB.

Apa saja rentang timeout koneksi untuk pendengar yang berbeda?

• Timeout koneksi pendengar TCP: 10 hingga 900 detik.

• Pendengar HTTP:

  • Timeout koneksi idle: 1 hingga 60 detik.

  • Timeout permintaan: 1 hingga 180 detik.

• Pendengar HTTPS:

  • Timeout koneksi idle: 1 hingga 60 detik.

  • Timeout permintaan: 1 hingga 180 detik.

Mengapa koneksi ke titik akhir SLB mengalami timeout?

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

• Proteksi keamanan pada titik akhir

  Ini mencakup blackholing traffic, pembersihan lalu lintas, dan proteksi Web Application Firewall (WAF). WAF mengirim paket RST ke client dan kluster server setelah koneksi terbentuk.

• Port client tidak mencukupi

  Hal ini terutama umum terjadi selama uji stres. Port client yang tidak mencukupi dapat menyebabkan kegagalan koneksi. Secara default, SLB menghapus atribut timestamp dari koneksi TCP. Hal ini mencegah fitur `tw_reuse` dari tumpukan protokol Linux berlaku untuk menggunakan kembali koneksi dalam status `time_wait`. Penumpukan koneksi dalam status `time_wait` menyebabkan kekurangan port client.

  Solusi: Gunakan koneksi persisten alih-alih koneksi singkat di sisi client. Gunakan paket RST untuk menutup koneksi (atur atribut SO_LINGER untuk socket) alih-alih paket FIN.

• Antrian accept server backend penuh

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

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

• Mengakses titik akhir instance SLB Lapisan 4 dari salah satu server backend-nya

  Untuk pendengar Lapisan 4 (TCP/UDP) CLB, server backend tidak dapat bertindak sebagai client sekaligus server. Mengakses titik akhir instance CLB dari salah satu server backend-nya menyebabkan kegagalan koneksi. Skenario umum adalah ketika aplikasi backend menggunakan penggabungan URL untuk mengakses titik akhir CLB.

  Solusi:

  • Gunakan client yang berbeda alih-alih server backend instance SLB Lapisan 4.

  • Migrasi ke Network Load Balancer (NLB) dan nonaktifkan fitur Preserve Client IP dalam grup server. Setelah fitur ini dinonaktifkan, instance ECS dalam grup server dapat bertindak sebagai server backend sekaligus client yang mengakses instance NLB. Untuk mendapatkan alamat IP sumber client, aktifkan Proxy Protocol. Untuk informasi selengkapnya, lihat Bagaimana instance ECS dapat bertindak sebagai server backend sekaligus client instance NLB?.

• Penanganan paket RST yang tidak tepat untuk timeout koneksi

  Setelah SLB membentuk koneksi TCP, SLB mengirim paket RST ke client dan server untuk menutup koneksi jika tidak ada aktivitas selama 900 detik. Beberapa aplikasi tidak menangani pengecualian RST dengan baik dan mungkin mengirim data melalui koneksi yang sudah ditutup, yang menyebabkan aplikasi mengalami timeout.

  Catatan

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

Apa aturan timeout untuk koneksi HTTP dan HTTPS?

• Maksimal 100 permintaan berurutan dapat dikirim melalui koneksi HTTP persisten. Koneksi akan ditutup jika batas ini terlampaui.

• Periode timeout antara dua permintaan HTTP atau HTTPS melalui koneksi persisten dapat dikonfigurasi dari 1 hingga 60 detik, dengan margin kesalahan 1 hingga 2 detik. Jika periode timeout terlampaui, koneksi TCP akan ditutup. Untuk menggunakan koneksi persisten, Anda harus mengirim permintaan heartbeat dengan interval kurang dari 13 detik.

• Periode timeout untuk jabat tangan tiga arah TCP antara SLB dan instance ECS backend adalah 5 detik. Jika terjadi timeout, SLB memilih instance ECS berikutnya. Anda dapat memeriksa waktu respons upstream di log akses untuk menemukan masalahnya.

• Periode timeout untuk SLB menunggu respons dari instance ECS dapat dikonfigurasi dari 1 hingga 180 detik. Jika terjadi timeout, SLB biasanya mengembalikan kode status 504 atau 408 ke client. Anda dapat memeriksa waktu respons upstream di log akses untuk membantu menemukan masalahnya.

• Periode timeout untuk penggunaan ulang sesi HTTPS adalah 300 detik. Jika periode timeout terlampaui, client yang sama harus melakukan jabat tangan SSL penuh lagi.

Jika client memutus koneksi secara aktif sebelum menerima respons dari server backend, apakah SLB juga memutus koneksi dari server backend?

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

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

Instance CLB tidak mendukung pengaktifan koneksi persisten backend. Untuk menerapkan fitur ini, Anda dapat membuat instance Application Load Balancer (ALB), mengonfigurasi pendengar HTTP atau HTTPS, dan mengaktifkan koneksi persisten backend untuk grup server ALB yang sesuai. Untuk informasi selengkapnya, lihat Buat dan kelola grup server.

Bagaimana cara melakukan troubleshooting latensi tinggi saat mengakses layanan backend melalui CLB?

Saat Anda mengakses layanan backend melalui CLB, peningkatan kecil latensi dibandingkan akses langsung adalah hal yang wajar. Pendengar Lapisan 7 CLB menggunakan arsitektur reverse proxy (Tengine). Permintaan diteruskan oleh CLB, yang menambahkan latensi untuk satu hop jaringan dan pemrosesan protokol. Pendengar Lapisan 4 menggunakan LVS untuk penerusan, dan latensi tambahan biasanya kecil.

Jika latensinya sangat tinggi, lakukan troubleshooting sebagai berikut:

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

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

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

2. Tentukan sumber latensi:

   • Jika upstream_response_time tinggi: Latensi biasanya disebabkan oleh pemrosesan lambat di server backend. Periksa kinerja aplikasi backend, efisiensi kueri database, dan penggunaan sumber daya seperti CPU dan memori. Anda juga dapat menambahkan lebih banyak server backend untuk berbagi beban.

   • Jika request_time jauh lebih besar daripada upstream_response_time: Latensi mungkin berada pada tautan jaringan dari client ke CLB. Jalankan pengujian ping berkelanjutan atau jejak rute MTR dari client ke titik akhir CLB untuk melakukan troubleshooting masalah tautan jaringan.

3. Akses lintas wilayah: Jika client dan instance CLB berada di wilayah yang berbeda, latensi jaringan akibat jarak fisik tidak dapat dihindari. Gunakan Global Accelerator (GA) untuk mengoptimalkan pengalaman akses lintas wilayah.

Bagaimana cara melakukan troubleshooting error 502, 503, dan 504 yang dikembalikan oleh CLB?

Saat Anda mengakses layanan backend melalui CLB, error 502, 503, dan 504 biasanya menunjukkan bahwa permintaan tidak diproses dengan benar oleh server backend. Arti dari tiga kode error tersebut adalah sebagai berikut:

• 502 Bad Gateway: CLB tidak dapat meneruskan permintaan ke server backend atau tidak dapat mendapatkan respons dari server backend. 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 QPS instance CLB.

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

Langkah 1: Lihat log akses

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

• Jika nilai status sama dengan nilai upstream_status, kemungkinan besar CLB meneruskan kode status pengecualian dari server backend. Dalam kasus ini, prioritaskan troubleshooting penyebab kode status yang dikembalikan oleh server backend.

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

Troubleshooting error 502

• Semua server backend gagal pemeriksaan kesehatan: Saat semua server backend yang terkait dengan pendengar gagal pemeriksaan kesehatan, CLB tidak dapat meneruskan permintaan dan mengembalikan error 502. Periksa status pemeriksaan kesehatan di konsol dan lakukan troubleshooting penyebab kegagalan pemeriksaan kesehatan. Penyebabnya dapat mencakup iptables atau perangkat lunak keamanan pihak ketiga yang memblokir blok CIDR 100.64.0.0/10 (blok CIDR sistem CLB), konfigurasi kode status pemeriksaan kesehatan yang tidak sesuai, atau path pemeriksaan kesehatan yang tidak ada. Untuk informasi selengkapnya, lihat FAQ tentang pemeriksaan kesehatan CLB.

• CLB mengonversi kode status pengecualian dari backend menjadi error 502: Jika server backend mengembalikan kode status pengecualian tertentu (seperti 504 atau 444), CLB mungkin mengembalikan error 502 ke client. Periksa bidang upstream_status di log akses untuk mengonfirmasi kode status aktual yang dikembalikan oleh backend dan lakukan troubleshooting penyebab pengecualian server backend.

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

Troubleshooting error 503

• Traffic melebihi batas spesifikasi instance: Error 503 dikembalikan ketika QPS, bandwidth, atau jumlah koneksi baru untuk traffic yang mengakses CLB melebihi batas spesifikasi saat ini. Anda dapat memperoleh metrik ini dari Cloud Monitor.

• Traffic instan melebihi batas tetapi tidak ditampilkan di pemantauan: Cloud Monitor menampilkan data tingkat menit dan mungkin tidak menunjukkan saat batas terlampaui pada tingkat detik. Periksa jumlah permintaan per detik di log akses. Jika bidang upstream_status di log adalah "-", artinya permintaan tidak dikirim ke server backend.

Troubleshooting error 504

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

• 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, mungkin ada masalah koneksi dengan server backend. Lakukan pengambilan paket untuk melakukan troubleshooting penyebabnya.

• Beban backend tinggi: Penggunaan sumber daya seperti CPU dan memori yang tinggi di server backend menyebabkan waktu respons melebihi periode timeout. Lakukan troubleshooting dan optimalkan kinerja layanan backend, atau tambahkan lebih banyak server backend untuk berbagi beban.

Bagaimana cara melakukan troubleshooting kegagalan akses ke layanan melalui CLB?

Jika Anda tidak dapat mengakses layanan setelah mengonfigurasi CLB, lakukan troubleshooting dengan mengikuti langkah-langkah berikut:

1. Periksa resolusi nama domain: Jika Anda mengakses layanan melalui nama domain, pastikan nama domain tersebut telah di-resolve dengan benar ke titik akhir instance CLB. Anda dapat menggunakan perintah nslookup atau dig untuk memverifikasi hasil resolusi. Kesalahan resolusi nama domain adalah penyebab umum kegagalan akses.

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

3. Periksa status pemeriksaan kesehatan: Di konsol CLB, lihat status pemeriksaan kesehatan server backend. Saat semua server backend gagal pemeriksaan kesehatan, CLB tidak dapat meneruskan permintaan.

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

5. Periksa apakah layanan backend berjalan dengan baik: Masuk ke server backend dan jalankan telnet <private_IP_of_backend_server> <port> (untuk Lapisan 4) atau curl -I http://<private_IP_of_backend_server> (untuk Lapisan 7) untuk memastikan layanan backend dapat merespons secara normal.

6. Periksa tautan jaringan: Uji akses ke titik akhir CLB dari lingkungan jaringan yang berbeda. Jika hanya jaringan on-premises yang bermasalah, Anda dapat menjalankan pengujian ping berkelanjutan atau jejak rute MTR untuk melakukan troubleshooting lebih lanjut.

Apa yang harus saya lakukan jika saya dapat mengakses instance CLB menggunakan alamat IP-nya tetapi tidak menggunakan nama domain-nya?

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

Sesuai peraturan yang berlaku, jika Anda menggunakan nama domain untuk mengakses layanan melalui jaringan publik di Tiongkok daratan, nama domain tersebut harus memiliki Pendaftaran ICP. Akses ke nama domain tanpa Pendaftaran ICP akan diblokir, yang mengakibatkan kode status 403 atau koneksi yang di-reset.

Lakukan troubleshooting dan penanganan sebagai berikut:

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

2. Periksa untuk menambahkan Alibaba Cloud ke informasi Pendaftaran ICP sebagai penyedia layanan: Jika nama domain telah menyelesaikan Pendaftaran ICP dengan penyedia layanan cloud lain tetapi digunakan dengan Alibaba Cloud untuk pertama kalinya, Anda juga perlu menambahkan Alibaba Cloud ke informasi Pendaftaran ICP sebagai penyedia layanan. Kegagalan melakukan hal ini juga dapat mengakibatkan akses yang diblokir.

3. Eliminasi penyebab lain: Jika nama domain telah menyelesaikan Pendaftaran ICP dan Anda telah menambahkan Alibaba Cloud ke informasi Pendaftaran ICP, periksa apakah resolusi nama domain mengarah dengan benar ke titik akhir CLB. Anda dapat memverifikasi hal ini dengan perintah nslookup atau dig. Juga, periksa apakah konfigurasi port dan protokol pendengar CLB sesuai dengan metode akses nama domain.

Apakah mengonfigurasi kontrol akses untuk instance CLB yang menghadap privat dan terikat ke EIP memengaruhi akses jaringan internal?

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

Bagaimana cara melakukan troubleshooting timeout permintaan selama uji stres pada instance CLB?

Jika Anda mengalami kode status 504 dan timeout permintaan selama uji stres pada instance CLB Lapisan 7, dan upstream_response_time di log konsisten sekitar 5 detik, masalahnya biasanya merupakan timeout koneksi yang disebabkan oleh kegagalan jabat tangan tiga arah TCP antara CLB dan server backend. Alasan umum adalah tabel pelacakan koneksi (nf_conntrack) di server backend penuh, yang menyebabkannya membuang paket koneksi baru.

Masuk ke server backend dan periksa log /var/log/messages. Jika muncul error berikut, penyebabnya telah dikonfirmasi:

nf_conntrack: table full, dropping packet

Solusi: Sesuaikan parameter nf_conntrack. Nilai berikut hanya sebagai referensi. Sesuaikan sesuai kebutuhan.

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 akan tidak berlaku setelah instance di-restart. Untuk membuat perubahan permanen, tulis parameter ke file /etc/sysctl.conf.

Bagaimana cara menangani situasi di mana kegagalan database backend menyebabkan semua situs di bawah pendengar yang sama menjadi tidak dapat diakses?

Skenario: Beberapa situs dipasang di bawah pendengar CLB, seperti situs statis di www.example.com dan situs dinamis di app.example.com. Saat database backend situs dinamis gagal, situs statis juga menjadi tidak dapat diakses dan melaporkan error HTTP 502.

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

Solusi: Gunakan instance CLB yang berbeda untuk situs dinamis dan statis untuk mengisolasi layanan. Dengan cara ini, kegagalan situs dinamis tidak memengaruhi akses ke situs statis.

Mengapa persistensi sesi kadang-kadang gagal?

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

• Masalah dengan pendengar HTTP/HTTPS: Untuk pendengar HTTP atau HTTPS, SLB tidak dapat menyisipkan cookie yang diperlukan untuk persistensi sesi ke dalam pesan respons yang memiliki kode status 4xx.

  Solusi: Gunakan pendengar TCP. Pendengar TCP menggunakan alamat IP sumber client untuk persistensi sesi. Anda juga dapat menyisipkan cookie di instance ECS backend dan menambahkan pemeriksaan cookie untuk jaminan tambahan.

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

  Saat SLB menyisipkan cookie, jika instance ECS backend membalas dengan pesan pengalihan 302, string `SERVERID` dalam cookie persistensi sesi berubah, yang menyebabkan persistensi sesi gagal.

  Troubleshooting: Tangkap permintaan dan respons di browser atau gunakan perangkat lunak pengambilan paket untuk menganalisis apakah ada pesan respons 302. Bandingkan string `SERVERID` dalam cookie pesan sebelum dan sesudah pengalihan untuk melihat apakah berbeda.

  Solusi: Gunakan pendengar TCP. Pendengar TCP menggunakan alamat IP sumber client untuk persistensi sesi. Anda juga dapat menyisipkan cookie di instance ECS backend dan menambahkan pemeriksaan cookie untuk jaminan tambahan.

• Periode timeout persistensi sesi terlalu singkat: Jika periode timeout persistensi sesi diatur terlalu singkat, persistensi sesi mungkin gagal.

Bagaimana cara melihat string persistensi sesi?

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

Bagaimana cara menggunakan perintah curl Linux untuk menguji persistensi sesi SLB?

1. Buat halaman uji.

   Di semua instance ECS backend instance SLB, 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 SLB.

   

2. Jalankan perintah curl di Linux.

   Asumsikan alamat IP layanan SLB adalah 10.170.X.X dan URL halaman uji adalah http://10.170.X.X/check.jsp.

   1. Masuk ke server Linux yang digunakan untuk pengujian.

   2. Jalankan perintah berikut untuk mengkueri nilai cookie server SLB.

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

      Catatan

      Mode persistensi sesi default untuk Alibaba Cloud SLB adalah injeksi cookie. Perintah `curl` tidak menyimpan atau mengirim cookie secara default. Anda harus terlebih dahulu menyimpan cookie yang sesuai untuk pengujian. Jika tidak, hasil pengujian `curl` acak, dan Anda mungkin salah menyimpulkan bahwa persistensi sesi SLB 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

      Bagian `a<=30` menentukan jumlah pengulangan. Anda dapat mengubahnya sesuai kebutuhan. Bagian grep '10.170.X.X' menyaring informasi IP yang ditampilkan. Modifikasi berdasarkan alamat IP pribadi instance ECS backend Anda.

   4. Amati alamat IP yang dikembalikan oleh pengujian. Jika alamat IP pribadi instance ECS-nya sama, persistensi sesi SLB berfungsi. Jika tidak, ada masalah dengan persistensi sesi SLB.

Bagaimana cara mengonfigurasi cookie di server backend saat saya menggunakan mode Rewrite Cookie?

Jika Anda memilih mode Rewrite Cookie untuk persistensi sesi Lapisan 7 di CLB, Anda perlu mengonfigurasi cookie dengan nama yang sesuai di server backend. Nama cookie harus sama dengan yang dikonfigurasi di konsol CLB. Berikut adalah 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;
    }
}

Bagaimana cara melakukan troubleshooting ketidakseimbangan beban di antara server backend?

Jika beban pada satu server backend jauh lebih tinggi daripada yang lain setelah Anda memasang beberapa server backend ke instance CLB, lakukan troubleshooting dengan mengikuti langkah-langkah berikut:

1. Periksa apakah persistensi sesi diaktifkan: Pendengar HTTP/HTTPS CLB mendukung persistensi sesi melalui injeksi cookie. Saat persistensi sesi diaktifkan, semua permintaan dari client yang sama diarahkan ke server backend yang sama. Jika beberapa client menghasilkan banyak permintaan, traffic terkonsentrasi pada server backend tertentu, yang menyebabkan ketidakseimbangan beban.

2. Nonaktifkan persistensi sesi untuk distribusi beban yang merata: Jika layanan Anda tidak bergantung pada status sesi, seperti cookie atau status login, Anda dapat menonaktifkan persistensi sesi untuk pendengar tersebut. Setelah dinonaktifkan, CLB mendistribusikan permintaan secara merata ke semua server backend berdasarkan algoritma penjadwalan, seperti round-robin berbobot. Lakukan operasi ini selama jam sepi dan segera verifikasi ketersediaan layanan. Menonaktifkan persistensi sesi memengaruhi layanan yang bergantung pada status pengguna, seperti keranjang belanja dan persistensi status login. Sebelum melakukan operasi ini, Anda harus mengevaluasi ketergantungan layanan Anda pada persistensi sesi.

3. Periksa beban aplikasi di server backend: Bahkan jika CLB mendistribusikan traffic secara merata, perbedaan penggunaan sumber daya seperti CPU dan memori pada server backend itu sendiri dapat menyebabkan beberapa server memiliki beban yang lebih tinggi. Masuk ke setiap server backend, bandingkan penggunaan sumber daya aplikasi, dan periksa adanya bottleneck kinerja.

Mengapa situs web dimuat secara normal melalui pendengar HTTP tetapi gagal memuat gaya melalui pendengar HTTPS?

Gejala:

Anda membuat pendengar HTTP dan pendengar HTTPS, dan kedua pendengar menggunakan server backend yang sama. Saat Anda mengakses situs web melalui HTTP, situs web ditampilkan secara normal. Namun, saat Anda mengaksesnya melalui pendengar HTTPS, tata letak situs web menjadi kacau.

Penyebab:

Secara default, SLB tidak memblokir pemuatan dan transmisi file JS. Penyebab yang mungkin adalah:

• Sertifikat tidak kompatibel dengan tingkat keamanan browser.

• Sertifikat berasal dari penyedia pihak ketiga yang tidak resmi. Hubungi penerbit sertifikat untuk memeriksa masalah pada sertifikat.

Solusi:

1. Saat membuka situs web, ikuti petunjuk browser untuk memuat skrip.

2. Tambahkan sertifikat yang sesuai ke client.

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

Tidak perlu. Anda hanya perlu mengonfigurasi sertifikat yang relevan di pendengar HTTPS instance CLB. Untuk informasi selengkapnya, lihat Mengonfigurasi sertifikat SSL.

Setelah saya memperbarui sertifikat pada instance CLB, mengapa browser masih menampilkan tanggal kedaluwarsa lama?

Hal ini biasanya terjadi karena instance 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 menyinkronkan segera, Anda dapat menonaktifkan lalu mengaktifkan kembali pengalihan traffic di sisi WAF untuk memaksa refresh status sertifikat. Perhatikan bahwa operasi ini menyebabkan pemutusan sementara selama 1 hingga 2 detik untuk layanan Anda.

Apakah CLB mendukung HSTS?

CLB tidak mendukung mengonfigurasi header respons HSTS. Untuk mengaktifkan HSTS, Anda dapat menggunakan salah satu metode berikut:

• Tambahkan header respons Strict-Transport-Security sendiri di server backend.

• Hubungkan ke WAF dan aktifkan HSTS melalui WAF.

Versi protokol HTTP apa yang digunakan pendengar HTTP atau HTTPS untuk mengakses server backend?

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

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

Apakah server backend dapat memperoleh versi protokol permintaan client ke pendengar HTTP atau HTTPS?

Ya, bisa.

Apakah CLB mendukung pembatasan kecepatan berbasis URL?

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

Application Load Balancer (ALB) mendukung pembatasan kecepatan berbasis URL. Anda dapat mengonfigurasi aturan penerusan untuk pendengar untuk menetapkan batas QPS untuk path tertentu. Hal ini memerlukan penggunaan aksi "Forward to". Lihat gambar berikut:

Mengapa bidang `Transfer-Encoding: chunked` muncul di header permintaan HTTP instance CLB Lapisan 7?

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

Setelah permintaan diteruskan oleh instance CLB Lapisan 7, mengapa beberapa parameter di header respons backend dihapus?

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

Apakah `proxy_buffering` dan `proxy_cache` diaktifkan untuk CLB?

Fitur proxy_buffering dan proxy_cache tidak diaktifkan untuk CLB. CLB tidak melakukan buffering atau caching data permintaan atau respons. Sebagai gantinya, CLB langsung meneruskan permintaan client ke server backend dalam mode proxy transparan. Ini adalah konfigurasi default CLB dan tidak memerlukan pengaturan tambahan.

Petunjuk untuk mengaktifkan proteksi WAF untuk CLB

Apakah menonaktifkan NIC publik memengaruhi layanan SLB?

Jika instance ECS memiliki alamat IP publik, menonaktifkan network interface controller (NIC) publik memengaruhi layanan SLB.

Hal ini karena saat NIC publik ada, rute default melewati jaringan publik. Menonaktifkan NIC publik mencegah paket respons dikirim kembali, yang memengaruhi layanan SLB. Jangan menonaktifkan NIC publik. Jika Anda harus menonaktifkannya, Anda perlu mengubah rute default ke jaringan pribadi untuk menghindari memengaruhi layanan. Namun, Anda harus mempertimbangkan apakah layanan Anda bergantung pada jaringan publik, seperti mengakses RDS melalui jaringan publik.

Apakah SLB mendukung permintaan client yang berisi bidang TOA?

Tidak. Bidang TCP Option Address (TOA) dalam permintaan client bertentangan dengan bidang TOA yang digunakan SLB untuk komunikasi internal. Konflik ini mencegah alamat IP asal client diperoleh.