Memecahkan masalah Load Balancer Jaringan passthrough internal

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

Verifikasi aturan firewall

Pastikan aturan firewall izinkan masuk ditentukan untuk mengizinkan health check ke VM backend.
Pastikan aturan firewall izinkan masuk mengizinkan traffic ke VM backend dari klien.
Pastikan aturan firewall yang relevan ada untuk mengizinkan traffic mencapai 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 tepat.

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

Pastikan lingkungan Tamu berjalan di VM backend

Jika Anda dapat terhubung ke VM backend yang berfungsi dengan baik, tetapi tidak dapat terhubung ke load balancer, kemungkinan Lingkungan tamu (sebelumnya, Lingkungan Tamu Windows atau Lingkungan Tamu Linux) 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.

Verifikasi 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 Google Cloud image, agen tamu akan menginstal rute lokal untuk alamat IP load balancer. Instance Google Kubernetes Engine berdasarkan Container-Optimized OS menerapkan hal ini 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 binding port dan alamat IP layanan 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 permintaan (terikat ke) alamat IP load balancer atau alamat IP apa pun (0.0.0.0 atau ::)
Memproses permintaan pada (terikat ke) 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 mencapai 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 dalam kondisi baik dengan melihat status"Sehat" untuk backend.

Jika tidak ada instance yang responsif di backend, pastikan health check yang sesuai dikonfigurasi dan setiap VM di backend memproses di 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 konfigurasi 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 kesehatan.

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. Itu adalah masalah terpisah dengan gejala yang serupa. Untuk perutean, jalankan perintah ip route list table local dan verifikasi bahwa 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, verifikasi bahwa permintaan dari klien berfungsi dengan baik saat dikeluarkan langsung di server. Misalnya, jika klien mengirim permintaan HTTP ke server melalui load balancer dan tidak ada respons atau responsnya jauh lebih lambat dari biasanya, kirim permintaan HTTP yang sama di setiap server backend dan amati perilakunya.

Jika salah satu server backend tidak berfungsi 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 di 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, jalankan perintah ping konstan ke setiap server, sebagai berikut:

ping SERVER_IP_ADDRESS

Pengujian ini menunjukkan latensi jaringan bawaan dan apakah jaringan menghilangkan 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 yang terjadi.

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

Mengidentifikasi kombinasi klien-server yang bermasalah

Jika uji ping jaringan menunjukkan latensi rendah dan tidak ada kehilangan paket, langkah selanjutnya adalah mengidentifikasi kombinasi klien-server tertentu, jika ada, yang menghasilkan hasil bermasalah. Anda dapat melakukannya dengan mengurangi jumlah server backend sebanyak setengahnya hingga jumlah server mencapai 1, sambil secara bersamaan mereproduksi perilaku 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 klien-server yang bermasalah, lanjutkan ke pengujian performa.

Melakukan penangkapan dan analisis traffic

Jika Anda mengidentifikasi kombinasi klien-server tertentu yang bermasalah, Anda dapat menggunakan penangkapan paket untuk menunjukkan bagian komunikasi yang menyebabkan penundaan atau gangguan. Penangkapan paket dapat dilakukan dengan tcpdump sebagai berikut:

Instal tcpdump di server.
Mulai pengambilan tcpdump di server.
Dari klien, kirim contoh permintaan, seperti berikut:
```
curl URL
```
Analisis output tcpdump untuk mengidentifikasi masalah.

Lakukan pengujian performa

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

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

Hasil: Kombinasi hasil dari pengujian [1] dan [2] mengidentifikasi apakah load balancer menyebabkan masalah.
Satu klien dan beberapa server, dengan load balancing.

Hasil: Mengidentifikasi batas performa satu klien.
Beberapa klien dan satu server, dengan load balancing.

Hasil: Mengidentifikasi batas performa satu server.
Beberapa klien dan beberapa server, tanpa load balancing.

Hasil: Mengidentifikasi batas performa jaringan.

Saat menjalankan uji beban dengan beberapa klien dan server, resource klien atau server (CPU, memori, I/O) dapat menjadi hambatan dan mengurangi hasil gabungan. 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 pengalihan

Jika Anda telah mengonfigurasi failover untuk Network Load Balancer passthrough internal, gunakan langkah-langkah berikut untuk memverifikasi konfigurasi Anda:

Pastikan Anda telah mengonfigurasi aturan firewall izinkan masuk untuk mengizinkan health check.
Pastikan Anda memahami konsep Pelacakan pemilihan dan koneksi backend dan Pengalihan otomatis.
Pastikan Anda telah menetapkan setidaknya satu backend failover.
Tinjau backend mana yang responsif menggunakan konsol Google Cloud atau gcloud compute backend-services get-health sehingga Anda dapat menentukan VM mana yang merupakan backend yang memenuhi syarat.
Pastikan rasio failover ditetapkan dengan tepat.
Sebaiknya jangan gunakan grup instance terkelola yang mengaktifkan penskalaan otomatis bersama dengan failover karena penskalaan otomatis mengubah jumlah backend utama, backend failover, atau keduanya. Hal ini dapat menyebabkan set backend yang memenuhi syarat berubah secara tidak terduga karena rasio failover tetap.
Jika VM klien juga merupakan VM backend yang di-load balance, koneksi ke alamat IP aturan penerusan load balancer akan dikirim ke VM backend itu sendiri. Untuk mengetahui informasi selengkapnya, lihat Menguji dari satu klien.

Memecahkan masalah load balancer sebagai masalah next hop

Saat Anda menetapkan Load Balancer Jaringan passthrough internal sebagai next hop dari 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 pembuatan rute. Jika rute dibuat sebelum 15 Mei 2021, rute 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 dikirimkan ke VM backend yang sehat dari load balancer, terlepas dari protokol yang dikonfigurasi untuk layanan backend internal load balancer, dan terlepas dari port atau port yang dikonfigurasi pada aturan penerusan internal load balancer.
Pastikan Anda telah membuat aturan firewall yang mengizinkan masuk yang mengidentifikasi dengan benar sumber traffic yang harus dikirimkan ke VM backend melalui next hop rute statis kustom. Paket yang tiba di VM backend akan 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 mana pun 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 mengetahui informasi lebih lanjut.
Jika paket menuju tujuan yang tidak terduga, hapus rute lain di jaringan VPC Anda dengan tujuan yang lebih spesifik. Tinjau urutan perutean untuk memahami Google Cloud pemilihan rute.

Memecahkan masalah logging

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

Pengukuran RTT seperti nilai byte mungkin tidak ada di beberapa log jika sampel paket yang diambil tidak cukup untuk merekam 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 berikutnya

Lihat Logging dan Pemantauan Load Balancer Jaringan passthrough internal untuk mengetahui informasi tentang cara mengonfigurasi Logging dan Pemantauan untuk Load Balancer Jaringan passthrough internal.
Lihat Load Balancer Jaringan passthrough internal dan jaringan yang terhubung untuk mengetahui informasi tentang cara mengakses Load Balancer Jaringan passthrough internal dari jaringan peer yang terhubung ke jaringan VPC Anda.

Memecahkan masalah Load Balancer Jaringan passthrough internal Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.