Memecahkan masalah dengan Load Balancer Aplikasi internal

Panduan ini menjelaskan cara memecahkan masalah konfigurasi untuk Load Balancer Aplikasi internal Google Cloud. Sebelum mengikuti panduan ini, pahami hal-hal berikut:

Memecahkan masalah umum dengan Network Analyzer

Network Analyzer otomatis memantau konfigurasi jaringan VPC Anda dan mendeteksi konfigurasi dan kesalahan konfigurasi yang kurang optimal. Alat ini mengidentifikasi kegagalan jaringan, memberikan informasi akar masalah, dan menyarankan penyelesaian yang memungkinkan. Untuk mempelajari berbagai skenario kesalahan konfigurasi yang terdeteksi secara otomatis 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 tidak memiliki mode balancing yang kompatibel.

Untuk informasi selengkapnya, lihat referensi berikut:

Traffic load balanced tidak memiliki alamat sumber klien asli

Ini normal. Load Balancer Aplikasi internal beroperasi sebagai proxy terbalik HTTP(S) (gateway). Saat program klien membuka koneksi ke alamat IP aturan penerusan INTERNAL_MANAGED, koneksi akan berakhir pada proxy. {i>Proxy<i} memproses permintaan yang masuk melalui koneksi tersebut. Untuk setiap permintaan, proxy memilih backend untuk menerima permintaan berdasarkan peta URL dan faktor lainnya. Proxy kemudian mengirimkan permintaan ke backend yang dipilih. Akibatnya, dari sudut pandang backend, sumber paket masuk adalah alamat IP dari subnet khusus proxy di region tersebut.

Permintaan ditolak oleh load balancer

Untuk setiap permintaan, proxy akan memilih backend untuk menerima permintaan berdasarkan matcher jalur di peta URL load balancer. Jika peta URL belum memiliki pencocok jalur yang ditentukan untuk suatu permintaan, peta URL tidak dapat memilih layanan backend, sehingga menampilkan kode respons 404 HTTP (Not Found).

Load balancer tidak terhubung ke backend

Firewall yang melindungi server backend perlu dikonfigurasi untuk mengizinkan traffic masuk dari proxy dalam rentang subnet khusus proxy yang Anda alokasikan ke region load balancing HTTP(S) internal.

Proxy terhubung ke backend menggunakan setelan koneksi yang ditentukan oleh konfigurasi layanan backend Anda. Jika nilai ini tidak sesuai dengan konfigurasi server yang berjalan di backend Anda, proxy tidak dapat meneruskan permintaan ke backend.

Pemeriksaan health check tidak dapat menjangkau backend

Untuk memverifikasi bahwa traffic health check mencapai VM backend Anda, aktifkan logging health check dan telusuri entri log yang berhasil.

Klien tidak dapat terhubung ke load balancer

Proxy tersebut memproses koneksi ke alamat IP dan port load balancer yang dikonfigurasi dalam aturan penerusan (misalnya, 10.1.2.3:80), dan dengan protokol yang ditentukan dalam aturan penerusan (HTTP atau HTTPS). Jika klien Anda tidak dapat terhubung, pastikan mereka menggunakan alamat, port, dan protokol yang benar.

Pastikan firewall tidak memblokir traffic antara instance klien dan alamat IP yang di-load balanced.

Pastikan klien berada di region yang sama dengan load balancer. Load Balancing HTTP(S) internal adalah produk regional, sehingga semua klien (dan backend) harus berada di region yang sama dengan resource load balancer.

Pembatasan kebijakan organisasi untuk VPC Bersama

Jika Anda menggunakan VPC Bersama dan tidak dapat membuat Load Balancer Aplikasi internal baru yang baru di subnet tertentu, kebijakan organisasi mungkin menjadi penyebabnya. Pada kebijakan organisasi, tambahkan subnet ke daftar subnet yang diizinkan atau hubungi administrator organisasi Anda. Untuk informasi selengkapnya, lihat constraints/compute.restrictSharedVpcSubnetworks.

Load balancer tidak mendistribusikan traffic secara merata di seluruh zona

Anda mungkin melihat ketidakseimbangan dalam traffic Load Balancer Aplikasi internal di seluruh zona. Hal ini dapat terjadi terutama ketika kapasitas backend Anda rendah (< 10%).

Perilaku tersebut dapat memengaruhi keseluruhan latensi karena traffic dikirim hanya ke beberapa server dalam satu zona.

Untuk meratakan distribusi traffic di seluruh zona, Anda dapat membuat perubahan konfigurasi berikut:

  • Gunakan mode penyeimbangan RATE dengan kapasitas target max-rate-per-instance yang rendah.
  • Gunakan kebijakan traffic backend LocalityLbPolicy dengan algoritme load balancing LEAST_REQUEST.

5xx error yang tidak dijelaskan

Untuk kondisi error yang disebabkan oleh masalah komunikasi antara proxy load balancer dan backend-nya, load balancer menghasilkan kode status HTTP (5xx) dan menampilkan kode status tersebut ke klien. Tidak semua error HTTP 5xx dibuat oleh load balancer—misalnya, jika backend mengirimkan respons 5xx HTTP ke load balancer, load balancer akan menyampaikan respons tersebut ke kliennya. Untuk menentukan apakah respons 5xx HTTP direlai dari backend atau apakah dihasilkan oleh proxy load balancer, lihat kolom proxyStatus pada log load balancer.

Perubahan konfigurasi pada Load Balancer Aplikasi internal, seperti penambahan atau penghapusan layanan backend, dapat menyebabkan pengguna melihat kode status HTTP 503 dalam waktu singkat. Saat perubahan konfigurasi ini diterapkan ke Envoys secara global, Anda akan melihat entri log dengan kolom proxyStatus yang cocok dengan string log connection_refused.

Jika kode status 5xx HTTP bertahan lebih dari beberapa menit setelah Anda menyelesaikan konfigurasi load balancer, lakukan langkah-langkah berikut untuk memecahkan masalah respons 5xx HTTP:

  1. Pastikan ada aturan firewall yang dikonfigurasi untuk mengizinkan health check. Jika tidak ada satu pun, log load balancer biasanya memiliki proxyStatus yang cocok dengan destination_unavailable, yang menunjukkan bahwa load balancer menganggap backend tersebut tidak tersedia.

  2. Memastikan 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. Ini mungkin berarti bahwa status respons awal backend belum berubah dari UNHEALTHY menjadi status yang berbeda. Anda melihat entri log health check yang berhasil hanya setelah prober health check menerima respons 200 OK HTTP dari backend.

  3. Pastikan parameter konfigurasi keepalive untuk software server HTTP yang berjalan pada 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 status 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 di instance backend kurang dari waktu tunggu keepalive tetap untuk load balancer. Pastikan konfigurasi waktu tunggu keepalive untuk software server HTTP pada setiap backend disetel ke sedikit lebih besar dari 10 menit (nilai yang direkomendasikan adalah 620 detik).

Batasan

Jika Anda mengalami masalah saat menggunakan Load Balancer Aplikasi internal dengan fitur jaringan Google Cloud lainnya, perhatikan batasan kompatibilitas saat ini.