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 secara otomatis memantau konfigurasi jaringan VPC Anda dan mendeteksi konfigurasi yang kurang optimal dan kesalahan konfigurasi. Alat ini mengidentifikasi kegagalan jaringan, memberikan informasi penyebab utama, dan menyarankan kemungkinan solusi. Untuk mempelajari berbagai skenario kesalahan konfigurasi yang otomatis dideteksi oleh Penganalisis Jaringan, lihat Insight load balancer dalam dokumentasi Penganalisis Jaringan.

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

Buka Penganalisis Jaringan

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 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 membuat kode respons error HTTP (5XX) dan menampilkan kode respons error tersebut kepada 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 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 kepadanya. 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 (Waktu Tunggu Gateway).

  • 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 singkat saat pengguna melihat kode error respons HTTP 502. Saat perubahan konfigurasi ini diterapkan 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 mencapai backend Anda. Hal ini mungkin berarti status respons awal backend belum berubah dari UNHEALTHY ke status yang berbeda. Anda hanya melihat entri log health check yang berhasil setelah prober health check menerima respons HTTP 200 OK dari backend.

  3. Pastikan software di backend berjalan. Untuk melakukannya, periksa apakah respons 5xx disajikan oleh load balancer atau 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 keberhasilan, seperti response_sent_by_backend, berarti backend-lah yang menampilkan respons HTTP 502. Periksa log di backend dan lakukan pemecahan 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 dalam layanan backend.

      Rekomendasi:

      • Tetapkan port health check yang akan digunakan port penayangan. Artinya, backend akan dianggap tidak responsif sebelum memenuhi syarat untuk menayangkan traffic nyata.
      • 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 menutup koneksinya ke load balancer secara tidak terduga sebelum respons di-proxy ke klien. Hal ini dapat terjadi jika load balancer mengirimkan traffic ke entitas lain. Entitas lain mungkin berupa 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 disetel terlalu rendah agar layanan tersebut dapat merespons. Pertimbangkan untuk memperpanjang waktu tunggu layanan backend atau selidiki mengapa layanan Anda membutuhkan waktu yang lama untuk merespons.

  4. Verifikasi bahwa parameter konfigurasi keep-alive untuk software server HTTP yang berjalan di instance backend tidak kurang dari waktu tunggu keep-alive load balancer, yang nilainya ditetapkan pada 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 keep-alive untuk software server web yang berjalan di instance backend kurang dari waktu tunggu keep-alive tetap load balancer. Pastikan konfigurasi waktu tunggu tetap aktif untuk software server HTTP di setiap backend ditetapkan sedikit lebih besar dari 10 menit (nilai yang direkomendasikan adalah 620 detik).

Mengatasi error HTTP 408

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

Traffic yang di-load balance 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 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 secara publik. Pastikan untuk memperbarui izin objek yang ditayangkan agar objek tersebut dapat dibaca oleh publik.

URL tidak menyajikan 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 objek:


NoSuchKey
The specified key does not exist.

Kompresi tidak berfungsi

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

Jika respons yang disajikan oleh load balancer tidak dikompresi, padahal 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 sebagaimana diwajibkan oleh spesifikasi HTTP. Untuk mengaktifkan kompresi, Anda mungkin harus mengganti konfigurasi default server web untuk memberi tahu server agar mengompresi respons sekalipun permintaan itu menyertakan header Via.

Untuk mengonfigurasi backend nginx agar 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 memverifikasi hal ini dengan menguji konektivitas ke instance backend menggunakan HTTP/2. Pastikan VM menggunakan rangkaian cipher 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 konfigurasi firewall Anda mengizinkan pemeriksa kondisi dan load balancer untuk lewat.

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 di-resolve DNS dengan berhasil (jika Anda menggunakan jenis endpoint FQDN).
  • Endpoint dapat diakses melalui internet.

Jika traffic tidak dapat menjangkau endpoint, yang menghasilkan kode error 502, kueri data TXT DNS _cloud-eoips.googleusercontent.com menggunakan alat seperti dig atau nslookup. Catat CIDR (setelah ip4:) dan pastikan rentang ini diizinkan oleh firewall atau daftar kontrol akses (ACL) cloud 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 asal 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 menyajikan sertifikat TLS (SSL) yang valid dan FQDN yang dikonfigurasi cocok dengan SAN (Subject Alternative Name) dalam daftar SAN sertifikat. Sertifikat yang valid didefinisikan sebagai sertifikat yang ditandatangani oleh Otoritas Sertifikat publik dan yang masa berlakunya belum habis.
  • 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, Anda 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 di-cache oleh Cloud CDN

Pastikan bahwa:

  • Anda telah mengaktifkan Cloud CDN di layanan backend yang berisi NEG yang mengarah ke backend eksternal dengan menyetel enableCDN ke benar (true).
  • Respons yang disajikan oleh backend eksternal Anda memenuhi persyaratan caching 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, Cloud Run Functions, 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 infrastruktur Cloud Run, Cloud Run Functions, atau App Engine secara keseluruhan 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 penerapan masker URL yang dikonfigurasi ke URL permintaan pengguna tidak menghasilkan nama layanan, atau jika menghasilkan nama layanan yang tidak ada, load balancer dapat menangani ketidakcocokan ini secara berbeda, bergantung pada platform komputasi tanpa server yang digunakan.

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

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

API Gateway: Jika terjadi ketidakcocokan mask 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 yang akan menerima permintaan.