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 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:

Memecahkan masalah konektivitas umum

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

Memverifikasi aturan firewall

  • Pastikan bahwa ingress mengizinkan aturan firewall ditetapkan untuk mengizinkan health check ke VM backend.
  • Pastikan bahwa ingress mengizinkan aturan firewall mengizinkan traffic ke VM backend dari klien.
  • Pastikan adanya aturan firewall yang relevan agar traffic dapat mencapai VM backend pada 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 Anda, 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 di 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 kebanyakan 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 menerapkan ini dengan menggunakan iptables.

Pada 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 pada 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 ::)
  • Memproses (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.

Memeriksa 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 responsif dengan melihat status"Sehat" untuk backend.

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

Dari klien di jaringan VPC yang sama, jalankan perintah berikut untuk memastikan bahwa VM backend memproses di 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 konfigurasikan untuk health check.

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>

Parameter ini tidak menentukan apakah perutean disiapkan dengan benar untuk merespons alamat IP load balancer. Itu adalah masalah lain dengan gejala serupa. Untuk perutean, jalankan perintah ip route list table local dan pastikan 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 menemukan masalah performa dan latensi yang meningkat, 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 mengirimkan permintaan HTTP ke server melalui load balancer dan tidak ada respons atau responsnya jauh lebih lambat dari biasanya, berikan permintaan HTTP yang sama di setiap server backend dan amati perilakunya.

Jika salah satu server backend individu 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 selanjutnya 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 mengurangi paket. Dalam beberapa kasus, aturan firewall mungkin memblokir traffic ICMP. Jika ya, pengujian ini gagal memberikan hasil apa pun. Verifikasi dengan administrator aturan firewall Anda untuk mengetahui apakah hal ini terjadi.

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

Mengidentifikasi kombinasi klien-server yang bermasalah

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

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

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

Melakukan penangkapan dan analisis traffic

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

  1. Instal {i>tcpdump<i} di server.
  2. Mulai penangkapan tcpdump di server.

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

    curl URL

  4. Menganalisis {i>output<i} {i>tcpdump<i} untuk mengidentifikasi masalahnya.

Melakukan pengujian performa

Jika Anda tidak mengidentifikasi kombinasi klien-server yang bermasalah dan performa gabungan 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: Identifikasi batas performa dari 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 daya tahan dengan beberapa klien dan server, resource klien atau server (CPU, memori, I/O) mungkin 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. Pada kebijakan organisasi, tambahkan subnet ke daftar subnet yang diizinkan atau hubungi administrator organisasi Anda. Untuk 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 setidaknya satu backend failover.
  • Verifikasi setelan kebijakan failover Anda:
    • Rasio failover
    • Menurunkan 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 (mengayunkan jari) antara backend utama dan failover.
  • Kemungkinan alasan: Menggunakan grup instance terkelola dengan penskalaan otomatis dan failover dapat menyebabkan kumpulan aktif mengalami failover dan failover berulang kali antara backend utama dan failover. Google Cloud tidak mencegah Anda mengonfigurasi failover dengan grup instance terkelola, karena deployment Anda mungkin akan mendapatkan manfaat dari penyiapan ini.

Nonaktifkan batasan pengosongan koneksi untuk grup failover

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

Pesan error berikut 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 dari load balancer, perilaku yang diharapkan adalah bahwa koneksi yang dikirim ke alamat IP aturan penerusan load balancer selalu dijawab oleh VM backend itu sendiri. Untuk mengetahui informasi selengkapnya, lihat menguji koneksi dari satu klien dan mengirim permintaan dari VM yang di-load balanced.

Jika VM klien bukan VM backend dari load balancer:

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

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

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

    • Gunakan konsol Google Cloud untuk memeriksa jumlah VM backend yang responsif di setiap grup instance backend. Konsol Google Cloud juga menunjukkan VM mana yang berada di kumpulan aktif.

    • Pastikan rasio failover load balancer Anda ditetapkan dengan benar. Misalnya, jika Anda memiliki sepuluh VM utama dan rasio failover yang ditetapkan ke 0.2, ini berarti Google Cloud akan melakukan failover saat kurang dari dua (10 × 0.2 = 2) VM utama responsif. Rasio failover 0.0 memiliki arti khusus: Google Cloud melakukan failover saat 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 menjadi next-hop dari rute statis kustom, masalah berikut mungkin akan terjadi:

Terjadi masalah konektivitas

  • Jika Anda tidak dapat melakukan ping ke alamat IP di rentang tujuan rute yang next hop-nya adalah aturan penerusan untuk Load Balancer Jaringan passthrough internal, perhatikan bahwa rute yang menggunakan jenis next hop ini mungkin tidak memproses traffic ICMP, bergantung pada kapan rute tersebut dibuat. Jika rute dibuat sebelum 15 Mei 2021, rute tersebut hanya akan 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 yang lama.

  • Saat menggunakan Load Balancer Jaringan passthrough internal sebagai next hop untuk rute statis kustom, semua traffic akan dikirimkan ke VM backend responsif 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 masuk dan izinkan yang mengidentifikasi dengan benar sumber traffic yang harus dikirimkan ke VM backend melalui next hop rute statis kustom. Paket yang tiba di VM backend mempertahankan alamat IP sumbernya, bahkan saat dikirimkan melalui rute statis kustom.

Nilai tidak valid untuk rentang tujuan

Rentang tujuan dari rute statis kustom tidak boleh lebih spesifik daripada rute subnet apa 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 informasi selengkapnya.

  • Jika paket pergi ke tujuan yang tidak terduga, hapus rute lain di jaringan VPC Anda yang memiliki tujuan yang lebih spesifik. Tinjau urutan pemilihan rute 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 hilang di beberapa log jika tidak ada cukup paket yang diambil sampelnya 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