Memecahkan masalah terkait Load Balancer Aplikasi eksternal

Panduan ini menjelaskan cara memecahkan masalah konfigurasi untuk Load Balancer Aplikasi eksternal. Sebelum menyelidiki masalah, biasakan diri Anda dengan halaman berikut:

• Ringkasan Load Balancer Aplikasi Eksternal
• Logging dan pemantauan Load Balancer Aplikasi Eksternal

Memecahkan masalah umum pada Network Analyzer

Network Analyzer secara otomatis memantau konfigurasi jaringan VPC Anda serta mendeteksi konfigurasi dan kesalahan konfigurasi yang kurang optimal. Alat ini mengidentifikasi kegagalan jaringan, memberikan informasi akar masalah, dan menyarankan kemungkinan penyelesaian. Untuk mempelajari berbagai skenario kesalahan konfigurasi yang otomatis terdeteksi oleh Network Analyzer, lihat Insight load balancer dalam dokumentasi Network Analyzer.

Network Analyzer tersedia di Google Cloud Console sebagai bagian dari Network Intelligence Center.

Buka Network Analyzer

Backend memiliki mode penyeimbangan yang tidak kompatibel

Saat membuat load balancer, Anda mungkin melihat error:

Validation failed for instance group INSTANCE_GROUP:

backend services 1 and 2 point to the same instance group
but the backends have incompatible balancing_mode. Values should be the same.

Hal ini terjadi saat Anda mencoba menggunakan backend yang sama dalam dua load balancer yang berbeda, dan backend tersebut tidak memiliki mode penyeimbangan yang kompatibel.

Untuk informasi selengkapnya, lihat referensi berikut:

• Batasan dan panduan untuk grup instance
• Mengubah mode balancing load balancer

Memecahkan masalah konektivitas umum

Error 5XX yang tidak dijelaskan

Untuk kondisi error yang disebabkan oleh masalah komunikasi antara proxy load balancer dan backend-nya, load balancer menghasilkan kode respons error HTTP (5XX) dan menampilkan kode respons error tersebut kepada klien. Tidak semua error HTTP 5XX dihasilkan oleh load balancer. Misalnya, jika backend mengirimkan respons HTTP 5XX ke load balancer, load balancer akan merelai respons tersebut ke kliennya. Untuk menentukan apakah respons HTTP 5XX direlai dari backend atau dihasilkan oleh proxy load balancer, lihat kolom statusDetails dari log load balancer.

Jika statusDetails menampilkan string log response_sent_by_backend, load balancer hanya meneruskan kode respons apa pun yang dikirim backend ke string tersebut, dalam hal ini, Anda perlu memecahkan masalah respons error HTTP di backend.

Untuk respons error HTTP dengan statusDetails yang tidak cocok dengan string log response_sent_by_backend:

• Load Balancer Aplikasi eksternal global dan Load Balancer Aplikasi eksternal regional menghasilkan kode error respons HTTP yang bermakna, seperti 503 (Layanan Tidak Tersedia) dan 504 (Gateway Timeout).

• Load Balancer Aplikasi klasik selalu menggunakan kode error respons HTTP 502.

Perubahan konfigurasi pada Load Balancer Aplikasi eksternal global, seperti penambahan atau penghapusan layanan backend, dapat menyebabkan pengguna melihat kode error respons HTTP 502 dalam waktu singkat. Saat perubahan konfigurasi ini diterapkan ke GFE secara global, Anda akan melihat entri log dengan kolom statusDetails cocok dengan string log failed_to_pick_backend.

Jika error HTTP 5XX terus ada lebih dari beberapa menit setelah Anda menyelesaikan konfigurasi load balancer, lakukan langkah-langkah berikut untuk memecahkan masalah respons HTTP 5XX:

1. Pastikan bahwa ada aturan firewall yang dikonfigurasi untuk mengizinkan health check. Jika tidak ada satu pun, log load balancer biasanya memiliki statusDetails yang cocok dengan failed_to_pick_backend, yang menunjukkan bahwa load balancer gagal memilih backend yang responsif untuk menangani permintaan tersebut.

2. Pastikan traffic health check mencapai VM backend Anda. Untuk melakukannya, aktifkan logging health check dan cari entri log yang berhasil.

   Untuk load balancer baru, kurangnya entri log health check yang berhasil bukan berarti traffic health check tidak mencapai backend Anda. Hal ini mungkin berarti bahwa status kesehatan awal backend belum berubah dari UNHEALTHY ke status yang berbeda. Anda hanya melihat entri log health check yang berhasil setelah health check menerima respons HTTP 200 OK dari backend.

3. Pastikan software di backend sudah berjalan. Untuk melakukannya, periksa apakah respons 5xx disalurkan oleh load balancer atau apakah respons tersebut dihasilkan dari backend. Lakukan langkah-langkah berikut:

   1. Gunakan Cloud Logging untuk melihat log load balancer. Anda dapat membuat kueri untuk mencari kode respons 5xx saja.

   2. Periksa nilai kolom statusDetails:

      • Jika statusDetails menampilkan pesan berhasil, seperti response_sent_by_backend, maka backendlah yang akan memberikan respons HTTP 502. Periksa log di backend dan pecahkan masalah lebih lanjut, bergantung pada layanan yang berjalan di backend.
      • Jika statusDetails menampilkan pesan kegagalan, lihat daftar solusi berikut untuk beberapa kegagalan umum yang terkait dengan respons 5xx:

      pesan kegagalan statusDetail	Kemungkinan penyebab dan solusinya
      failed_to_connect_to_backend	Load balancer gagal membuat koneksi dengan backend. Hal ini dapat berarti bahwa layanan yang berjalan di backend tidak memproses port yang ditentukan di layanan backend. Rekomendasi: Tetapkan port health check untuk menggunakan port inferensi. Ini berarti backend akan dianggap tidak responsif sebelum memenuhi syarat untuk menyalurkan traffic sebenarnya. Gunakan perintah berikut untuk memastikan bahwa ada layanan yang berjalan pada port bernama pada layanan backend: $ netstat -tnl | grep PORT
      failed_to_pick_backend	Load balancer tidak dapat memilih backend. Ini bisa berarti bahwa semua backend tidak responsif. Pastikan Anda mengonfigurasi aturan firewall yang benar untuk health check.
      backend_connection_closed_before_data_sent_to_client	Backend secara tiba-tiba menutup koneksinya ke load balancer sebelum respons di-proxy-kan ke klien. Hal ini dapat terjadi jika load balancer mengirimkan traffic ke entitas lain. Entity lainnya mungkin berupa load balancer pihak ketiga yang memiliki waktu tunggu TCP lebih singkat dari waktu tunggu load balancer. Untuk detail selengkapnya, lihat Waktu tunggu dan percobaan ulang.
      backend_timeout	Backend membutuhkan waktu terlalu lama untuk merespons. Waktu tunggu layanan backend mungkin disetel terlalu rendah agar layanan yang diberikan merespons. Pertimbangkan untuk meningkatkan waktu tunggu layanan backend atau cari tahu mengapa layanan Anda membutuhkan waktu begitu lama untuk merespons.

4. Pastikan parameter konfigurasi keepalive untuk software server HTTP yang berjalan pada instance backend tidak kurang dari waktu tunggu keepalive load balancer, yang nilainya ditetapkan ke 10 menit (600 detik) dan tidak dapat dikonfigurasi.

   Load balancer menghasilkan kode respons HTTP 5XX saat koneksi ke backend tiba-tiba tertutup saat mengirim permintaan HTTP atau sebelum respons HTTP lengkap diterima. Hal ini dapat terjadi karena parameter konfigurasi keepalive untuk software server web yang berjalan pada instance backend kurang dari waktu tunggu keepalive tetap dari load balancer. Pastikan konfigurasi waktu tunggu keepalive untuk software server HTTP di setiap backend disetel sedikit lebih besar dari 10 menit (nilai yang direkomendasikan adalah 620 detik).

Mengatasi error 408 HTTP

Dengan traffic HTTP, waktu maksimum bagi klien untuk menyelesaikan pengiriman permintaannya sama dengan waktu tunggu layanan backend. Jika Anda melihat respons 408 HTTP dengan jsonPayload.statusDetail client_timed_out, artinya progres tidak memadai saat permintaan dari klien di-proxy-kan atau respons dari backend di-proxy-kan. Jika masalahnya disebabkan oleh klien yang mengalami masalah performa, Anda dapat menyelesaikan masalah ini dengan meningkatkan waktu tunggu layanan backend.

Traffic load balanced tidak memiliki alamat sumber klien asli

Alamat IP sumber untuk paket, seperti yang terlihat oleh backend, bukan alamat IP eksternal load balancer. Load balancer berbasis proxy seperti Load Balancer Aplikasi eksternal menggunakan dua koneksi TCP untuk mengirimkan traffic dari klien ke backend:

• Koneksi 1, dari klien asli ke load balancer (GFE atau subnet khusus proxy)
• Koneksi 2, dari load balancer (GFE atau subnet khusus proxy) ke VM backend atau endpoint

Alamat IP sumber dan tujuan untuk setiap koneksi berbeda berdasarkan jenis Load Balancer Aplikasi eksternal yang Anda gunakan. Untuk mengetahui detailnya, lihat Alamat IP sumber untuk paket klien .

Mendapatkan error izin saat mencoba melihat objek di bucket Cloud Storage

Agar dapat menyajikan objek melalui load balancing, objek Cloud Storage harus dapat diakses secara publik. Pastikan untuk memperbarui izin objek yang ditampilkan agar dapat dibaca secara publik.

URL tidak menayangkan objek Cloud Storage yang diharapkan

Objek Cloud Storage yang akan ditayangkan ditentukan berdasarkan peta URL dan URL yang Anda minta. Jika jalur permintaan dipetakan ke bucket backend di peta URL Anda, objek Cloud Storage ditentukan dengan menambahkan jalur permintaan lengkap ke bucket Cloud Storage yang ditentukan oleh peta URL.

Misalnya, jika Anda memetakan /static/* ke gs://[EXAMPLE_BUCKET], permintaan ke https://<GCLB IP or Host>/static/path/to/content.jpg akan mencoba menayangkan gs://[EXAMPLE_BUCKET]/static/path/to/content.jpg. Jika objek tersebut tidak ada, Anda akan mendapatkan pesan error berikut, bukan objeknya:

NoSuchKey
The specified key does not exist.

Kompresi tidak berfungsi

Load Balancer Aplikasi eksternal tidak mengompresi atau mendekompresi respons itu sendiri, tetapi dapat menyalurkan respons yang dihasilkan oleh layanan backend Anda yang dikompresi menggunakan alat seperti gzip atau DEFLATE.

Jika respons yang disalurkan oleh load balancer tidak dikompresi tetapi seharusnya, periksa untuk memastikan bahwa software server web yang berjalan pada instance Anda telah dikonfigurasi untuk mengompresi respons. Secara default, beberapa software server web otomatis menonaktifkan kompresi untuk permintaan yang menyertakan header Via, yang menunjukkan bahwa permintaan tersebut diteruskan oleh proxy. Karena merupakan proxy, Load Balancer Aplikasi eksternal menambahkan header Via ke setiap permintaan seperti yang diwajibkan oleh spesifikasi HTTP. Untuk mengaktifkan kompresi, Anda mungkin harus mengganti konfigurasi default server web Anda untuk memerintahkannya mengompresi respons meskipun permintaan memiliki header Via.

Untuk mengonfigurasi backend nginx agar menyalurkan respons yang dikompresi melalui proxy melalui Load Balancer Aplikasi eksternal:

• Tetapkan perintah gzip_proxied dengan benar (misalnya, ke any), dan
• Tetapkan perintah gzip_vary ke on.

Untuk mengonfigurasi backend Apache agar menyalurkan respons terkompresi yang di-proxy-kan melalui Load Balancer Aplikasi eksternal:

• Gunakan filter DEFLATE, dan
• Tambahkan Vary Accept-Encoding ke header respons menggunakan modul mod_headers.

Memecahkan masalah backend yang tidak responsif

Memecahkan masalah terkait HTTP/2 ke backend

Pastikan backend instance Anda responsif dan mendukung protokol HTTP/2. Anda dapat memverifikasi hal ini dengan menguji konektivitas ke backend instance menggunakan HTTP/2. Pastikan VM menggunakan cipher suite yang sesuai dengan spesifikasi HTTP/2. Misalnya, cipher suite TLS 1.2 tertentu tidak diizinkan oleh HTTP/2. Lihat Daftar Hitam Suite Cipher TLS 1.2.

Setelah Anda memverifikasi bahwa VM menggunakan protokol HTTP/2, pastikan penyiapan firewall Anda mengizinkan health checker dan load balancer untuk melewatinya.

Jika tidak ada masalah dengan penyiapan firewall, pastikan load balancer dikonfigurasi untuk berkomunikasi dengan port yang benar di VM.

Memecahkan masalah backend eksternal dan NEG internet

Sebelum menyelidiki masalah, biasakan diri Anda dengan halaman berikut:

• Ringkasan NEG Internet
• Menyiapkan Load Balancer Aplikasi eksternal global dengan backend eksternal (NEG internet)

Traffic tidak mencapai endpoint

Setelah Anda mengonfigurasi layanan, endpoint baru dapat dijangkau melalui Load Balancer Aplikasi eksternal jika:

• Endpoint terpasang ke NEG internet.
• FQDN yang terkait dapat berhasil di-resolve DNS (jika Anda menggunakan jenis endpoint FQDN).
• Endpoint dapat diakses melalui internet.

Jika traffic tidak dapat mencapai endpoint, yang menghasilkan kode error 502, buat kueri data TXT DNS _cloud-eoips.googleusercontent.com menggunakan alat seperti dig atau nslookup. Catat CIDR (mengikuti ip4:) dan pastikan rentang ini diizinkan oleh firewall atau cloud access control list (ACL).

Setelah mengonfigurasi backend eksternal, permintaan ke backend eksternal gagal dengan error 5xx

• Centang Logging.
• Pastikan grup endpoint jaringan dikonfigurasi dengan IP:Port atau FQDN:Port yang benar untuk backend eksternal Anda.
• Jika Anda menggunakan FQDN, pastikan FQDN dapat diselesaikan melalui Google Public DNS. Anda dapat memverifikasi bahwa FQDN dapat diselesaikan melalui Google Public DNS menggunakan langkah-langkah ini atau antarmuka web secara langsung.
• Jika Anda mengakses load balancer hanya di IP eksternalnya dan server web asal mengharapkan nama host, pastikan Anda mengirimkan header Host HTTP yang valid ke backend dengan mengonfigurasi header permintaan kustom.
• Jika Anda berkomunikasi dengan backend melalui HTTPS atau HTTP2 (seperti yang ditetapkan di kolom protocol pada layanan backend) yang dikonfigurasi sebagai endpoint backend eksternal INTERNET_FQDN_PORT, pastikan origin Anda menyajikan sertifikat TLS (SSL) yang valid dan FQDN yang dikonfigurasi cocok dengan SAN (Nama Alternatif Subjek) dalam daftar sertifikat SAN. Sertifikat yang valid didefinisikan sebagai sertifikat yang ditandatangani oleh Certificate Authority publik dan belum kedaluwarsa.
• Saat menggunakan endpoint backend eksternal INTERNET_FQDN_PORT, sertifikat yang ditandatangani sendiri tidak diterima oleh load balancer, dan akan ditolak.
• Saat menggunakan HTTPS atau HTTP/2 dengan endpoint jenis INTERNET_IP_PORT, tidak ada validasi sertifikat SSL/pemeriksaan SAN. Artinya, seseorang dapat menggunakan sertifikat yang ditandatangani sendiri. Saat menggunakan SSL, sebaiknya gunakan endpoint INTERNET_FQDN_PORT untuk memastikan sertifikat server dan SAN dapat divalidasi.

Respons dari backend eksternal saya tidak disimpan dalam cache oleh Cloud CDN

Pastikan bahwa:

• Anda telah mengaktifkan Cloud CDN di layanan backend yang berisi NEG yang mengarah ke backend eksternal Anda dengan menetapkan enableCDN ke true.
• Respons yang disalurkan oleh backend eksternal Anda memenuhi persyaratan penyimpanan dalam cache Cloud CDN. Misalnya, Anda mengirim header respons Cache-Control: public, max-age=3600 dari origin.

Memecahkan masalah NEG serverless

Sebelum menyelidiki masalah, biasakan diri Anda dengan halaman berikut:

• Ringkasan NEG Serverless
• Menyiapkan Load Balancer Aplikasi eksternal global dengan NEG serverless

Permintaan gagal dengan error 404

Pastikan resource serverless yang mendasarinya (seperti layanan App Engine, Cloud Functions, atau Cloud Run) masih berjalan. Jika resource serverless dihapus tetapi NEG serverless masih ada, Load Balancer Aplikasi eksternal akan terus mencoba merutekan permintaan ke layanan yang tidak ada. Ini menghasilkan respons 404.

Secara umum, Load Balancer Aplikasi eksternal tidak dapat mendeteksi apakah resource serverless yang mendasarinya berfungsi seperti yang diharapkan. Artinya, jika layanan Anda di satu region menampilkan error, tetapi keseluruhan infrastruktur Cloud Run, Cloud Functions, atau App Engine di region tersebut beroperasi secara normal, Load Balancer Aplikasi eksternal Anda tidak akan otomatis mengarahkan traffic ke region lain. Pastikan Anda menguji versi baru layanan secara menyeluruh sebelum mengarahkan traffic pengguna ke layanan tersebut.

Menangani ketidakcocokan mask URL

Jika penerapan mask URL yang dikonfigurasi ke URL permintaan pengguna tidak menghasilkan nama layanan, atau jika menghasilkan nama layanan yang tidak ada, load balancer mungkin akan menangani ketidakcocokan ini secara berbeda, bergantung pada platform komputasi serverless yang digunakan.

Cloud Run: Jika ada ketidakcocokan mask URL, load balancer akan menampilkan error HTTP 404 (Tidak Ditemukan).

Cloud Functions: Jika ada ketidakcocokan mask URL, load balancer akan menampilkan error HTTP 404 (Tidak Ditemukan).

App Engine: Jika ketidakcocokan mask URL, App Engine menggunakan dispatch.yaml dan logika perutean default App Engine untuk menentukan layanan mana yang akan dikirimi permintaan.