Memecahkan masalah terkait Load Balancer Aplikasi eksternal

Panduan ini menjelaskan cara memecahkan masalah konfigurasi untuk Load Balancer Aplikasi eksternal. Sebelum menyelidiki masalah, pahami halaman berikut:

Memecahkan masalah umum dengan Network Analyzer

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

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

Buka Network Analyzer

Backend memiliki mode balancing 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 di dua load balancer yang berbeda, dan backend tidak memiliki mode penyeimbangan yang kompatibel.

Untuk informasi selengkapnya, lihat referensi berikut:

Memecahkan masalah konektivitas umum

Error 5XX yang tidak dapat dijelaskan

Untuk kondisi error yang disebabkan oleh masalah komunikasi antara proxy load balancer dan backend-nya, load balancer akan menghasilkan kode respons error HTTP (5XX) dan menampilkan kode respons error tersebut ke klien. Tidak semua error HTTP 5XX dibuat oleh load balancer—misalnya, jika backend mengirim respons HTTP 5XX ke load balancer, load balancer akan meneruskan respons tersebut ke kliennya. Untuk menentukan apakah respons HTTP 5XX diteruskan dari backend atau apakah respons tersebut dihasilkan oleh proxy load balancer, lihat kolom statusDetails di log load balancer.

Jika statusDetails menampilkan string log response_sent_by_backend, load balancer hanya meneruskan kode respons apa pun yang dikirim backend ke load balancer. 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 akan 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 periode waktu singkat saat pengguna melihat kode error respons HTTP 502. Meskipun perubahan konfigurasi ini disebarkan ke GFE secara global, Anda akan melihat entri log dengan kolom statusDetails yang cocok dengan string log failed_to_pick_backend.

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

  1. Pastikan ada aturan firewall yang dikonfigurasi untuk mengizinkan health check. Jika tidak ada, 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.

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

    Untuk load balancer baru, tidak adanya entri log health check yang berhasil tidak berarti traffic health check tidak menjangkau backend Anda. Hal ini mungkin berarti bahwa status respons awal backend belum berubah dari UNHEALTHY menjadi status yang berbeda. Anda hanya akan melihat entri log health check yang berhasil setelah pemindai health check menerima respons HTTP 200 OK dari backend.

  3. Pastikan software di backend berjalan. Untuk melakukannya, periksa apakah respons 5xx ditayangkan oleh load balancer atau apakah respons tersebut dibuat 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 sukses, seperti response_sent_by_backend, backend itulah yang menayangkan 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 solusi
      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 dalam layanan backend.

      Rekomendasi:

      • Tetapkan port health check untuk menggunakan port penayangan. Artinya, backend akan ditemukan tidak responsif sebelum memenuhi syarat untuk menayangkan traffic sebenarnya.
      • Gunakan perintah berikut untuk memastikan bahwa ada layanan yang berjalan di port bernama layanan backend: 
        $ netstat -tnl | grep PORT
      failed_to_pick_backend

      Load balancer tidak dapat memilih backend. Hal ini dapat 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 tiba-tiba menutup koneksinya ke load balancer sebelum respons di-proxy ke klien. Hal ini dapat terjadi jika load balancer mengirimkan traffic ke entitas lain. Entitas lainnya mungkin adalah load balancer pihak ketiga yang memiliki waktu tunggu TCP yang lebih singkat daripada waktu tunggu load balancer. Untuk mengetahui detail selengkapnya, lihat Waktu tunggu dan percobaan ulang.
      backend_timeout Backend memerlukan waktu terlalu lama untuk merespons. Waktu tunggu layanan backend mungkin ditetapkan terlalu rendah agar layanan tertentu dapat merespons. Pertimbangkan untuk meningkatkan waktu tunggu layanan backend atau cari tahu alasan layanan Anda membutuhkan waktu lama untuk merespons.

  4. Verifikasi bahwa parameter konfigurasi keepalive untuk software server HTTP yang berjalan di instance backend tidak kurang dari waktu tunggu keepalive load balancer, yang nilainya tetap 10 menit (600 detik) dan tidak dapat dikonfigurasi.

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

Mengatasi error 408 HTTP

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

Traffic load balanced tidak memiliki alamat sumber klien asli

Alamat IP sumber untuk paket, seperti yang dilihat 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 (subnet khusus proxy atau GFE)
  • Koneksi 2, dari load balancer (subnet khusus proxy atau GFE) ke VM atau endpoint backend

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 saya

Untuk menayangkan objek melalui load balancing, objek Cloud Storage harus dapat diakses publik. Pastikan untuk memperbarui izin objek yang ditayangkan agar dapat dibaca oleh 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 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 objek:


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 ditayangkan oleh load balancer tidak dikompresi, tetapi seharusnya dikompresi, periksa untuk memastikan bahwa software server web yang berjalan di instance Anda dikonfigurasi untuk mengompresi respons. Secara default, beberapa software server web otomatis menonaktifkan kompresi untuk permintaan yang menyertakan header Via, yang menunjukkan bahwa permintaan 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 untuk memberi tahu server untuk mengompresi respons meskipun permintaan memiliki header Via.

Untuk mengonfigurasi backend nginx guna menayangkan respons terkompresi yang di-proxy melalui Load Balancer Aplikasi eksternal:

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

Memecahkan masalah backend yang tidak responsif

Memecahkan masalah terkait HTTP/2 ke backend

Pastikan instance backend Anda responsif dan mendukung protokol HTTP/2. Anda dapat memverifikasinya dengan menguji konektivitas ke instance backend 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, pahami halaman berikut:

Traffic tidak mencapai endpoint

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

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

Jika traffic tidak dapat menjangkau endpoint, yang menyebabkan kode error 502, buat kueri data TXT DNS _cloud-eoips.googleusercontent.com menggunakan alat seperti dig atau nslookup. Perhatikan CIDR (mengikuti ip4:) dan pastikan rentang ini diizinkan oleh firewall atau daftar kontrol akses cloud (ACL) Anda.

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 tersebut dapat di-resolve melalui Google Public DNS. Anda dapat memverifikasi bahwa FQDN dapat di-resolve 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 origin Anda mengharapkan nama host, pastikan Anda mengirim 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 layanan backend) yang dikonfigurasi sebagai endpoint backend eksternal INTERNET_FQDN_PORT, pastikan origin Anda menampilkan sertifikat TLS (SSL) yang valid dan FQDN yang dikonfigurasi cocok dengan SAN (Subject Alternative Name) dalam daftar SAN sertifikat. Sertifikat valid didefinisikan sebagai sertifikat yang ditandatangani oleh Certificate Authority publik dan belum habis masa berlakunya.
  • Saat menggunakan endpoint backend eksternal INTERNET_FQDN_PORT, sertifikat yang ditandatangani sendiri tidak diterima oleh load balancer, dan ditolak.
  • Saat menggunakan HTTPS atau HTTP/2 dengan endpoint jenis INTERNET_IP_PORT, tidak ada validasi sertifikat SSL/pemeriksaan SAN yang dilakukan. 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 dengan menetapkan enableCDN ke benar (true).
  • Respons yang ditayangkan oleh backend eksternal Anda memenuhi persyaratan penyimpanan cache Cloud CDN. Misalnya, Anda mengirim header respons Cache-Control: public, max-age=3600 dari origin.

Memecahkan masalah NEG serverless

Sebelum menyelidiki masalah, pahami halaman berikut:

Permintaan gagal dengan error 404

Pastikan resource serverless yang mendasarinya (seperti App Engine, fungsi Cloud Run, atau layanan 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. Hal ini akan 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 Run Functions, atau App Engine di region tersebut beroperasi secara normal, Load Balancer Aplikasi eksternal Anda tidak akan otomatis mengalihkan traffic ke region lain. Pastikan Anda menguji versi baru layanan secara menyeluruh sebelum merutekan traffic pengguna ke versi tersebut.

Menangani ketidakcocokan masker URL

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

Cloud Run: Jika terjadi ketidakcocokan mask URL, load balancer akan menampilkan error HTTP 404 (Not Found).

Fungsi Cloud Run: Jika terjadi ketidakcocokan masker URL, load balancer akan menampilkan error HTTP 404 (Not Found).

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