Memecahkan masalah Load Balancer Jaringan passthrough internal

Panduan ini menjelaskan cara memecahkan masalah konfigurasi untuk Load Balancer Jaringan passthrough internal Google Cloud. 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

Jika Anda tidak dapat terhubung ke Load Balancer Jaringan passthrough internal, periksa masalah umum berikut.

Memverifikasi aturan firewall

  • Pastikan aturan firewall yang mengizinkan traffic masuk ditentukan untuk mengizinkan health check ke VM backend.
  • Pastikan aturan firewall izinkan masuk mengizinkan traffic ke VM backend dari klien.
  • Pastikan ada aturan firewall yang relevan untuk mengizinkan traffic menjangkau VM backend di port yang digunakan oleh load balancer.
  • Jika Anda menggunakan tag target untuk aturan firewall, pastikan VM backend load balancer diberi tag dengan benar.

Untuk mempelajari cara mengonfigurasi aturan firewall yang diperlukan oleh Load Balancer Jaringan passthrough internal, lihat Mengonfigurasi aturan firewall.

Memastikan lingkungan Tamu berjalan di VM backend

Jika Anda dapat terhubung ke VM backend yang sehat, tetapi tidak dapat terhubung ke load balancer, mungkin Lingkungan tamu (sebelumnya, Windows Guest Environment atau Linux Guest Environment) di VM tidak berjalan atau tidak dapat berkomunikasi dengan server metadata (metadata.google.internal, 169.254.169.254).

Periksa hal-hal berikut:

  • Pastikan lingkungan Tamu diinstal dan berjalan di VM backend.
  • Pastikan aturan firewall dalam sistem operasi tamu VM backend (iptables atau Windows Firewall) tidak memblokir akses ke server metadata.

Memverifikasi bahwa VM backend menerima paket yang dikirim ke load balancer

Setiap VM backend harus dikonfigurasi untuk menerima paket yang dikirim ke load balancer. Artinya, tujuan paket yang dikirim ke VM backend adalah alamat IP load balancer. Dalam sebagian besar situasi, hal ini dilakukan dengan rute lokal.

Untuk VM yang dibuat dari image Google Cloud, Agen tamu akan menginstal rute lokal untuk alamat IP load balancer. Instance Google Kubernetes Engine yang didasarkan pada Container-Optimized OS menerapkannya dengan menggunakan iptables.

Di VM backend Linux, Anda dapat memverifikasi keberadaan rute lokal dengan menjalankan perintah berikut. Ganti LOAD_BALANCER_IP dengan alamat IP load balancer:

sudo ip route list table local | grep LOAD_BALANCER_IP

Memverifikasi alamat IP layanan dan binding port di VM backend

Paket yang dikirim ke Load Balancer Jaringan passthrough internal tiba di VM backend dengan alamat IP tujuan load balancer itu sendiri. Jenis load balancer ini bukan proxy, dan ini adalah perilaku yang diharapkan.

Software yang berjalan di VM backend harus melakukan hal berikut:

  • Memproses (terikat dengan) alamat IP load balancer atau alamat IP apa pun (0.0.0.0 atau ::)
  • Mendengarkan (terikat dengan) port yang disertakan dalam aturan penerusan load balancer

Untuk mengujinya, hubungkan ke VM backend menggunakan SSH atau RDP. Kemudian, lakukan pengujian berikut menggunakan curl, telnet, atau alat serupa:

  • Coba jangkau layanan dengan menghubunginya menggunakan alamat IP internal VM backend itu sendiri, 127.0.0.1, atau localhost.
  • Coba jangkau layanan dengan menghubunginya menggunakan alamat IP aturan penerusan load balancer.

Periksa apakah VM klien berada di region yang sama dengan load balancer

Jika klien yang terhubung ke load balancer berada di region lain, pastikan akses global diaktifkan.

Memverifikasi bahwa traffic health check dapat menjangkau VM backend

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

Anda juga dapat memverifikasi bahwa fungsi load balancer berfungsi dengan baik dengan melihat status"Responsif" untuk backend.

Jika tidak ada instance yang responsif di backend, pastikan health check yang sesuai telah dikonfigurasi dan setiap VM di backend memproses port health check yang dikonfigurasi.

Dari klien di jaringan VPC yang sama, jalankan perintah berikut untuk memverifikasi bahwa VM backend memproses port TCP tertentu:

telnet SERVER_IP_ADDRESS PORT

Ganti kode berikut:

  • SERVER_IP_ADDRESS: Alamat IP VM backend.
  • PORT: Port yang Anda konfigurasikan untuk health check. Secara default, port health check adalah 80.

Atau, Anda dapat menggunakan SSH untuk menghubungkan VM backend dan menjalankan perintah berikut:

curl localhost:PORT

Sekali lagi, ganti PORT dengan port yang Anda konfigurasi untuk pemeriksaan status.

Cara lain untuk melakukan pengujian ini adalah dengan menjalankan perintah berikut:

netstat -npal | grep LISTEN

Pada output, periksa hal berikut:

  • <var>LB_IP_ADDRESS</var>:<var>PORT</var>
  • 0.0.0.0:<var>PORT</var>
  • :::<var>PORT</var>

Hal ini tidak menentukan apakah perutean disiapkan dengan benar untuk merespons alamat IP load balancer. Ini adalah masalah terpisah dengan gejala yang serupa. Untuk pemilihan rute, jalankan perintah ip route list table local dan pastikan alamat IP load balancer tercantum, seperti yang dijelaskan dalam Memverifikasi bahwa VM backend menerima paket yang dikirim ke load balancer.

Memecahkan masalah performa

Jika Anda melihat masalah performa dan peningkatan latensi, periksa masalah umum berikut.

Memverifikasi fungsi server

Jika semua server backend merespons health check, pastikan permintaan dari klien berfungsi dengan baik saat dikeluarkan di server secara langsung. Misalnya, jika klien mengirim permintaan HTTP ke server melalui load balancer dan tidak ada respons atau responsnya secara substansial lebih lambat dari biasanya, berikan permintaan HTTP yang sama di setiap server backend dan amati perilakunya.

Jika salah satu server backend tidak berperilaku dengan benar saat permintaan dikeluarkan dari dalam server itu sendiri, Anda dapat menyimpulkan bahwa stack aplikasi server tidak berfungsi dengan benar. Anda dapat lebih berfokus pada pemecahan masalah pada aplikasi itu sendiri. Jika semua server berperilaku dengan benar, langkah berikutnya adalah melihat sisi klien dan jaringan.

Memverifikasi konektivitas dan latensi jaringan

Jika semua server backend merespons permintaan dengan benar, verifikasi latensi jaringan. Dari VM klien, berikan perintah ping konstan ke setiap server, sebagai berikut:

ping SERVER_IP_ADDRESS

Pengujian ini menunjukkan latensi jaringan bawaan dan apakah jaringan menjatuhkan paket. Dalam beberapa kasus, aturan firewall mungkin memblokir traffic ICMP. Jika demikian, pengujian ini gagal menghasilkan hasil apa pun. Verifikasi dengan administrator aturan firewall Anda apakah hal ini terjadi.

Jika perintah ping menunjukkan latensi yang jauh lebih tinggi dari normal atau kehilangan paket yang signifikan, buka kasus dukungan Google Cloud untuk menyelidiki lebih lanjut.

Mengidentifikasi kombinasi klien-server yang bermasalah

Jika pengujian ping jaringan menunjukkan latensi rendah dan tidak ada kehilangan paket, langkah berikutnya adalah mengidentifikasi kombinasi server-klien tertentu, jika ada, yang menghasilkan hasil bermasalah. Anda dapat melakukannya dengan mengurangi jumlah server backend menjadi setengah hingga jumlah server mencapai 1, sekaligus mereproduksi perilaku yang bermasalah (misalnya, latensi tinggi atau tidak ada respons).

Jika Anda mengidentifikasi satu atau beberapa kombinasi klien-server yang bermasalah, lakukan perekaman dan analisis traffic.

Jika tidak ada kombinasi server-klien yang bermasalah yang diidentifikasi, lanjutkan ke pengujian performa.

Melakukan penangkapan dan analisis traffic

Jika mengidentifikasi kombinasi server-klien tertentu yang bermasalah, Anda dapat menggunakan penangkap paket untuk menentukan bagian komunikasi yang menyebabkan keterlambatan atau kerusakan. Perekaman paket dapat dilakukan dengan tcpdump sebagai berikut:

  1. Instal tcpdump di server.
  2. Mulai perekaman tcpdump di server.

  3. Dari klien, berikan contoh permintaan, seperti berikut:

    curl URL

  4. Analisis output tcpdump untuk mengidentifikasi masalah.

Melakukan pengujian performa

Jika Anda tidak mengidentifikasi kombinasi klien-server yang bermasalah dan performa agregat dari semua klien dan server secara bersamaan lebih rendah dari yang diharapkan, pertimbangkan pengujian berikut:

  1. Satu klien dan satu server, tanpa load balancing.

  2. Satu klien dan satu server, dengan load balancing.

    Hasil: Kombinasi hasil dari pengujian [1] dan [2] mengidentifikasi apakah load balancer menyebabkan masalah.

  3. Satu klien dan beberapa server, dengan load balancing.

    Hasil: Mengidentifikasi batas performa satu klien.

  4. Beberapa klien dan satu server, dengan load balancing.

    Hasil: Mengidentifikasi batas performa satu server.

  5. Beberapa klien dan beberapa server, tanpa load balancing.

    Hasil: Identifikasi batas performa jaringan.

Saat menjalankan pengujian stres dengan beberapa klien dan server, resource klien atau server (CPU, memori, I/O) dapat menjadi bottleneck dan mengurangi hasil agregat. Hasil gabungan yang menurun dapat terjadi meskipun setiap klien dan server berperilaku dengan benar.

Memecahkan masalah VPC Bersama

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

Memecahkan masalah failover

Jika Anda telah mengonfigurasi failover untuk Load Balancer Jaringan passthrough internal, bagian berikut menjelaskan masalah yang dapat terjadi.

Konektivitas

  • Pastikan Anda telah menetapkan minimal satu backend failover.
  • Verifikasi setelan kebijakan failover Anda:
    • Rasio failover
    • Menghentikan traffic saat semua VM backend tidak responsif
    • Menonaktifkan pengosongan koneksi saat failover

Masalah terkait grup instance terkelola dan failover

  • Gejala: Kumpulan aktif berubah bolak-balik (berkibar) antara backend utama dan failover.
  • Kemungkinan alasan: Menggunakan grup instance terkelola dengan penskalaan otomatis dan failover dapat menyebabkan kumpulan aktif berulang kali melakukan failover dan failback antara backend utama dan failover. Google Cloud tidak mencegah Anda mengonfigurasi failover dengan grup instance terkelola, karena deployment Anda mungkin mendapatkan manfaat dari penyiapan ini.

Menonaktifkan batasan pengosongan koneksi untuk grup failover

Menonaktifkan pengosongan koneksi hanya berfungsi jika layanan backend disiapkan dengan protokol TCP.

Pesan error berikut akan muncul jika Anda membuat layanan backend dengan UDP saat pengosongan koneksi dinonaktifkan:

gcloud compute backend-services create my-failover-bs \
    --global-health-checks \
    --load-balancing-scheme=internal \
    --health-checks=my-tcp-health-check \
    --region=us-central1 \
    --no-connection-drain-on-failover \
    --drop-traffic-if-unhealthy \
    --failover-ratio=0.5 \
    --protocol=UDP
ERROR: (gcloud.compute.backend-services.create) Invalid value for
[--protocol]: can only specify --connection-drain-on-failover if the protocol is
TCP.

Traffic dikirim ke VM backend yang tidak terduga

Pertama, periksa hal berikut: Jika VM klien juga merupakan VM backend load balancer, perilaku yang diharapkan adalah koneksi yang dikirim ke alamat IP aturan penerusan load balancer selalu dijawab oleh VM backend itu sendiri. Untuk informasi selengkapnya, lihat menguji koneksi dari satu klien dan mengirim permintaan dari VM yang di-load balanced.

Jika VM klien bukan VM backend load balancer:

  • Untuk permintaan dari satu klien, lihat menguji koneksi dari satu klien agar Anda memahami batasan metode ini.

  • Pastikan Anda telah mengonfigurasi aturan firewall izinkan masuk untuk mengizinkan health check.

  • Untuk konfigurasi failover, pastikan Anda memahami cara kerja keanggotaan di kumpulan aktif, dan kapan Google Cloud melakukan failover dan failback. Periksa konfigurasi load balancer Anda:

    • Gunakan konsol Google Cloud untuk memeriksa jumlah VM backend yang berfungsi dengan baik di setiap grup instance backend. Konsol Google Cloud juga menampilkan VM mana yang ada dalam kumpulan aktif.

    • Pastikan rasio failover load balancer Anda ditetapkan dengan benar. Misalnya, jika Anda memiliki sepuluh VM utama dan rasio failover ditetapkan ke 0.2, ini berarti Google Cloud melakukan failover jika kurang dari dua VM utama (10 × 0.2 = 2) responsif. Rasio failover 0.0 memiliki makna khusus: Google Cloud melakukan failover jika tidak ada VM utama yang responsif.

Koneksi yang ada dihentikan selama failover atau failback

Edit kebijakan failover layanan backend Anda. Pastikan pengosongan koneksi saat failover diaktifkan.

Memecahkan masalah load balancer sebagai next hop

Saat Anda menetapkan Load Balancer Jaringan passthrough internal sebagai next hop rute statis kustom, masalah berikut mungkin terjadi:

Terjadi masalah konektivitas

  • Jika Anda tidak dapat melakukan ping ke alamat IP dalam rentang tujuan rute yang next hop-nya adalah aturan penerusan untuk Network Load Balancer passthrough internal, perhatikan bahwa rute yang menggunakan jenis next hop ini mungkin tidak memproses traffic ICMP, bergantung pada waktu rute dibuat. Jika dibuat sebelum 15 Mei 2021, rute tersebut hanya memproses traffic TCP dan UDP hingga 16 Agustus 2021. Mulai 16 Agustus 2021, semua rute akan otomatis meneruskan semua traffic protokol (TCP, UDP, dan ICMP) terlepas dari kapan rute dibuat. Jika tidak ingin menunggu hingga saat itu, Anda dapat mengaktifkan fungsi ping sekarang dengan membuat rute baru dan menghapus rute lama.

  • Saat menggunakan Load Balancer Jaringan passthrough internal sebagai next hop untuk rute statis kustom, semua traffic dikirim ke VM backend load balancer yang sehat, terlepas dari protokol yang dikonfigurasi untuk layanan backend internal load balancer, dan terlepas dari port yang dikonfigurasi pada aturan penerusan internal load balancer.

  • Pastikan Anda telah membuat aturan firewall izin masuk yang dengan benar mengidentifikasi sumber traffic yang harus dikirim ke VM backend melalui next hop rute statis kustom. Paket yang tiba di VM backend mempertahankan alamat IP sumbernya, meskipun dikirim melalui rute statis kustom.

Nilai tidak valid untuk rentang tujuan

Rentang tujuan rute statis kustom tidak boleh lebih spesifik daripada rute subnet di jaringan VPC Anda. Jika Anda menerima pesan error berikut saat membuat rute statis kustom:

Invalid value for field 'resource.destRange': [ROUTE_DESTINATION].
[ROUTE_DESTINATION] hides the address space of the network .... Cannot change
the routing of packets destined for the network.

  • Anda tidak dapat membuat rute statis kustom dengan tujuan yang sama persis atau lebih spesifik (dengan mask yang lebih panjang) daripada rute subnet. Lihat pemberlakuan dan urutan untuk informasi selengkapnya.

  • Jika paket menuju ke tujuan yang tidak terduga, hapus rute lain di jaringan VPC Anda dengan tujuan yang lebih spesifik. Tinjau urutan perutean untuk memahami pemilihan rute Google Cloud.

Memecahkan masalah logging

Jika Anda mengonfigurasi logging untuk Load Balancer Jaringan passthrough internal, masalah berikut mungkin terjadi:

  • Pengukuran RTT seperti nilai byte mungkin tidak ada di beberapa log jika sampel yang diambil tidak cukup untuk menangkap RTT. Hal ini lebih mungkin terjadi untuk koneksi bervolume rendah.
  • Nilai RTT hanya tersedia untuk alur TCP.
  • Beberapa paket dikirim tanpa payload. Jika paket khusus header diambil sampelnya, nilai byte-nya adalah 0.

Langkah selanjutnya