Halaman ini diterjemahkan oleh Cloud Translation API.

Distribusi traffic untuk Load Balancer Jaringan passthrough eksternal

Halaman ini menjelaskan konsep berikut untuk membantu Anda lebih memahami dan menyesuaikan cara Load Balancer Jaringan passthrough eksternal mendistribusikan traffic: afinitas sesi, pelacakan koneksi, load balancing berbobot, pengosongan koneksi, fragmentasi UDP, dan failover.

Cara Load Balancer Jaringan passthrough eksternal mendistribusikan koneksi baru bergantung pada apakah Anda telah mengonfigurasi failover:

Jika Anda belum mengonfigurasi failover, Load Balancer Jaringan passthrough eksternal akan mendistribusikan koneksi baru ke VM backend-nya yang responsif jika setidaknya satu VM backend responsif. Jika semua VM backend tidak responsif, load balancer akan mendistribusikan koneksi baru di antara semua backend sebagai upaya terakhir. Dalam situasi ini, load balancer merutekan setiap koneksi baru ke VM backend yang tidak responsif.
Jika Anda telah mengonfigurasi failover, Load Balancer Jaringan passthrough eksternal akan mendistribusikan koneksi baru di antara VM backend yang responsif dalam kumpulan aktifnya, sesuai dengan kebijakan failover yang Anda konfigurasikan. Jika semua VM backend tidak sehat, Anda dapat memilih dari satu perilaku berikut:
- (Default) Load balancer hanya mendistribusikan traffic ke VM utama. Hal ini dilakukan sebagai upaya terakhir. VM cadangan dikecualikan dari distribusi koneksi sebagai upaya terakhir ini.
- Load balancer menghentikan traffic.

Untuk mengetahui detail tentang cara koneksi didistribusikan, lihat bagian berikutnya Pemilihan backend dan pelacakan koneksi.

Untuk mengetahui detail tentang cara kerja failover, lihat bagian Failover.

Pemilihan backend dan pelacakan koneksi

Load Balancer Jaringan passthrough eksternal menggunakan algoritma pelacakan koneksi dan pemilihan backend yang dapat dikonfigurasi untuk menentukan cara traffic didistribusikan ke VM backend.

Load Balancer Jaringan passthrough eksternal menggunakan algoritma berikut untuk mendistribusikan paket di antara VM backend (dalam kumpulan aktifnya, jika Anda telah mengonfigurasi failover):

Jika load balancer memiliki entri dalam tabel pelacakan koneksinya yang cocok dengan karakteristik paket yang masuk, paket akan dikirim ke backend yang ditentukan oleh entri tabel pelacakan koneksi. Paket dianggap sebagai bagian dari koneksi yang dibuat sebelumnya, sehingga paket dikirim ke VM backend yang sebelumnya ditentukan dan dicatat oleh load balancer dalam tabel pelacakan koneksinya.
Jika load balancer menerima paket yang tidak memiliki entri pelacakan koneksi, load balancer akan melakukan hal berikut:
1. Load balancer memilih backend. Load balancer menghitung hash berdasarkan afinitas sesi yang dikonfigurasi. Fitur ini menggunakan hash ini untuk memilih backend dari backend yang sehat (kecuali jika semua backend tidak sehat, dalam hal ini semua backend akan dipertimbangkan selama kebijakan failover belum dikonfigurasi untuk menghentikan traffic dalam situasi ini). Afinitas sesi default, NONE, menggunakan algoritma hashing berikut:
  - Untuk paket TCP dan UDP yang tidak terfragmentasi, hash 5-tuple dari alamat IP sumber, port sumber, alamat IP tujuan, port tujuan, dan protokol paket.
  - Untuk paket UDP yang terfragmentasi dan semua protokol lainnya, hash 3-tuple alamat IP sumber paket, alamat IP tujuan, dan protokol.
  Pemilihan backend dapat disesuaikan dengan menggunakan algoritma hash yang menggunakan lebih sedikit informasi. Untuk semua opsi yang didukung, lihat opsi afinitas sesi.
  
  Selain itu, perhatikan hal-hal berikut:
  
  Jika Anda mengaktifkan load balancing berbobot, pemilihan backend berbasis hash akan diberi bobot berdasarkan bobot yang dilaporkan oleh instance backend. Contoh:
  - Pertimbangkan layanan backend yang dikonfigurasi dengan afinitas sesi yang ditetapkan ke NONE dan aturan penerusan dengan protokol UDP. Jika ada dua instance backend yang sehat dengan bobot 1 dan 4, backend akan mendapatkan 20% dan 80% paket UDP.
  - Pertimbangkan layanan backend yang dikonfigurasi dengan afinitas sesi 3-tuple dan pelacakan koneksi. Afinitas sesi adalah CLIENT_IP_PROTO dan mode pelacakan koneksi adalah PER_SESSION. Jika ada tiga instance backend yang sehat dengan bobot 0, 2, dan 6, backend akan mendapatkan traffic untuk 0%, 25%, dan 75% alamat IP sumber baru (alamat IP sumber untuk yang tidak ada entri tabel pelacakan koneksi yang ada) masing-masing. Traffic untuk koneksi yang ada akan diarahkan ke backend yang ditetapkan sebelumnya.
    Perhatian: Jika bobot sering berubah, load balancing berbobot dapat merugikan afinitas sesi. Ada beberapa load-balancer dan pelacakan koneksi tidak direplikasi di seluruh load-balancer tersebut. Untuk afinitas sesi yang berkelanjutan, sebaiknya Anda tidak menggunakan load balancing berbobot atau jarang menggunakannya.
2. Load balancer menambahkan entri ke tabel pelacakan koneksinya. Entri ini mencatat backend yang dipilih untuk koneksi paket sehingga semua paket mendatang dari koneksi ini dikirim ke backend yang sama. Apakah pelacakan koneksi digunakan bergantung pada protokol:
  - Paket TCP. Pelacakan koneksi selalu diaktifkan, dan tidak dapat dinonaktifkan. Secara default, pelacakan koneksi adalah 5-tuple, tetapi dapat dikonfigurasi menjadi kurang dari 5-tuple. Jika 5-tuple, paket SYN TCP diperlakukan secara berbeda. Tidak seperti paket non-SYN, paket ini menghapus entri pelacakan koneksi yang cocok dan selalu memilih backend baru.
    
    Pelacakan koneksi 5-tuple default digunakan saat:
    - mode pelacakan adalah PER_CONNECTION (semua afinitas sesi), atau,
    - mode pelacakan adalah PER_SESSION dan afinitas sesi adalah NONE, atau,
    - mode pelacakan adalah PER_SESSION dan afinitas sesi adalah CLIENT_IP_PORT_PROTO.
  - Paket UDP, ESP, dan GRE. Pelacakan koneksi hanya diaktifkan jika afinitas sesi disetel ke sesuatu selain NONE.
  - Paket ICMP dan ICMPv6. Pelacakan koneksi tidak dapat digunakan.
  Untuk mengetahui detail tambahan tentang kapan pelacakan koneksi diaktifkan, dan metode pelacakan yang digunakan saat pelacakan koneksi diaktifkan, lihat mode pelacakan koneksi.
  
  Selain itu, perhatikan hal-hal berikut:
  - Masa berlaku entri dalam tabel pelacakan koneksi berakhir 60 detik setelah load balancer memproses paket terakhir yang cocok dengan entri. Untuk informasi selengkapnya, lihat Waktu tunggu tidak ada aktivitas.
  - Bergantung pada protokol, load balancer mungkin menghapus entri tabel pelacakan koneksi saat backend menjadi tidak responsif. Untuk mengetahui detail dan cara menyesuaikan perilaku ini, lihat Persistensi koneksi di backend yang tidak sehat.

Opsi afinitas sesi

Afinitas sesi mengontrol distribusi koneksi baru dari klien ke VM backend load balancer. Afinitas sesi ditentukan untuk seluruh layanan backend eksternal regional, bukan berdasarkan backend.

Load Balancer Jaringan passthrough eksternal mendukung opsi afinitas sesi berikut:

Tidak ada (NONE). Hash 5-tuple dari alamat IP sumber, port sumber, protokol, alamat IP tujuan, dan port tujuan
IP Klien, IP Tujuan (CLIENT_IP). Hash 2-tuple dari alamat IP sumber dan alamat IP tujuan
IP Klien, IP Tujuan, Protokol (CLIENT_IP_PROTO). Hash 3-tuple dari alamat IP sumber, alamat IP tujuan, dan protokol
IP Klien, Port Klien, IP Tujuan, Port Tujuan, Protokol (CLIENT_IP_PORT_PROTO). Hash 5-tuple dari alamat IP sumber, port sumber, protokol, alamat IP tujuan, dan port tujuan

Untuk mempelajari pengaruh opsi afinitas sesi ini terhadap metode pelacakan koneksi dan pemilihan backend, lihat tabel ini.

Kebijakan pelacakan koneksi

Bagian ini menjelaskan setelan yang mengontrol perilaku pelacakan koneksi Load Balancer Jaringan passthrough eksternal. Kebijakan pelacakan koneksi mencakup setelan berikut:

Mode pelacakan
Persistensi koneksi di backend yang tidak responsif
Waktu tunggu tidak ada aktivitas

Mode pelacakan koneksi

Apakah pelacakan koneksi diaktifkan hanya bergantung pada protokol traffic yang di-load balance dan setelan afinitas sesi. Mode pelacakan menentukan algoritma pelacakan koneksi yang akan digunakan saat pelacakan koneksi diaktifkan. Ada dua mode pelacakan: PER_CONNECTION (default) dan PER_SESSION.

PER_CONNECTION (default). Ini adalah mode pelacakan default. Dengan mode pelacakan koneksi ini, traffic TCP selalu dilacak per 5-tuple, terlepas dari setelan afinitas sesi. Untuk traffic UDP, ESP, dan GRE, pelacakan koneksi diaktifkan jika afinitas sesi yang dipilih bukan NONE. Paket UDP, ESP, dan GRE dilacak menggunakan metode pelacakan yang dijelaskan dalam tabel ini.
PER_SESSION. Jika afinitas sesi adalah CLIENT_IP atau CLIENT_IP_PROTO, mengonfigurasi mode ini akan menghasilkan pelacakan koneksi 2-tuple dan 3-tuple, masing-masing, untuk semua protokol (kecuali ICMP dan ICMPv6, yang tidak dapat dilacak koneksinya). Untuk setelan afinitas sesi lainnya, mode PER_SESSION berperilaku sama dengan mode PER_CONNECTION.

Untuk mempelajari cara kerja mode pelacakan ini dengan setelan afinitas sesi yang berbeda untuk setiap protokol, lihat tabel berikut.

Pemilihan backend		Mode pelacakan koneksi
Setelan afinitas sesi	Metode hash untuk pemilihan backend	`PER_CONNECTION` (default)	`PER_SESSION`
Default: Tidak ada afinitas sesi (`NONE`)	TCP dan UDP yang tidak terfragmentasi: Hash 5-tuple UDP yang terfragmentasi dan semua protokol lainnya: Hash 3-tuple	TCP: Pelacakan koneksi 5-tuple Semua protokol lainnya: pelacakan koneksi nonaktif	TCP: Pelacakan koneksi 5-tuple Semua protokol lainnya: pelacakan koneksi nonaktif
IP Klien, IP Tujuan (`CLIENT_IP`)	Semua protokol: Hash 2-tuple	TCP dan UDP yang tidak terfragmentasi: Pelacakan koneksi 5-tuple UDP, ESP, dan GRE yang terfragmentasi: Pelacakan koneksi 3-tuple Semua protokol lainnya: pelacakan koneksi nonaktif	TCP, UDP, ESP, GRE: Pelacakan koneksi 2-tuple Semua protokol lainnya: pelacakan koneksi nonaktif
IP Klien, IP Tujuan, Protokol (`CLIENT_IP_PROTO`)	Semua protokol: Hash 3-tuple	TCP dan UDP yang tidak terfragmentasi: Pelacakan koneksi 5-tuple UDP, ESP, dan GRE yang terfragmentasi: Pelacakan koneksi 3-tuple Semua protokol lainnya: pelacakan koneksi nonaktif	TCP, UDP, ESP, GRE: Pelacakan koneksi 3-tuple Semua protokol lainnya: pelacakan koneksi nonaktif
IP Klien, Port Klien, IP Tujuan, Port Tujuan, Protokol (`CLIENT_IP_PORT_PROTO`)	TCP dan UDP yang tidak terfragmentasi: Hash 5-tuple UDP yang terfragmentasi dan semua protokol lainnya: Hash 3-tuple	TCP dan UDP yang tidak terfragmentasi: Pelacakan koneksi 5-tuple UDP, ESP, dan GRE yang terfragmentasi: Pelacakan koneksi 3-tuple Semua protokol lainnya: pelacakan koneksi nonaktif	TCP dan UDP yang tidak terfragmentasi: Pelacakan koneksi 5-tuple UDP, ESP, dan GRE yang terfragmentasi: Pelacakan koneksi 3-tuple Semua protokol lainnya: pelacakan koneksi nonaktif

Untuk mempelajari cara mengubah mode pelacakan koneksi, lihat Mengonfigurasi kebijakan pelacakan koneksi.

Persistensi koneksi di backend yang tidak responsif

Setelan persistensi koneksi mengontrol apakah koneksi yang ada tetap ada di VM atau endpoint backend yang dipilih setelah backend tersebut menjadi tidak sehat, selama backend tetap berada dalam grup backend yang dikonfigurasi load balancer (dalam grup instance atau NEG).

Perilaku yang dijelaskan di bagian ini tidak berlaku jika Anda menghapus instance backend dari grup instance atau menghapus endpoint backend dari NEG-nya, atau menghapus grup instance atau NEG dari layanan backend. Dalam kasus tersebut, koneksi yang dibuat hanya akan tetap ada seperti yang dijelaskan dalam pengosongan koneksi.

Opsi persistensi koneksi berikut tersedia:

DEFAULT_FOR_PROTOCOL (default)
NEVER_PERSIST
ALWAYS_PERSIST

Tabel berikut merangkum opsi persistensi koneksi dan cara koneksi tetap ada untuk berbagai protokol, opsi afinitas sesi, dan mode pelacakan.

Opsi Persistensi koneksi pada backend yang tidak responsif	Mode pelacakan koneksi
Opsi Persistensi koneksi pada backend yang tidak responsif	`PER_CONNECTION`	`PER_SESSION`
`DEFAULT_FOR_PROTOCOL`	TCP: koneksi tetap ada di backend yang tidak sehat (semua afinitas sesi) Semua protokol lainnya: koneksi tidak pernah bertahan di backend yang tidak responsif	TCP: koneksi tetap ada di backend yang tidak responsif jika afinitas sesi adalah `NONE` atau `CLIENT_IP_PORT_PROTO` Semua protokol lainnya: koneksi tidak pernah bertahan di backend yang tidak responsif
`NEVER_PERSIST`	Semua protokol: koneksi tidak pernah dipertahankan di backend yang tidak responsif
`ALWAYS_PERSIST`	TCP: koneksi tetap ada di backend yang tidak sehat (semua afinitas sesi) ESP, GRE, UDP: koneksi tetap ada di backend yang tidak sehat jika afinitas sesi bukan `NONE` ICMP, ICMPv6: tidak berlaku karena tidak dapat dilacak koneksinya Opsi ini hanya boleh digunakan untuk kasus penggunaan lanjutan.	Konfigurasi tidak memungkinkan

Perilaku persistensi koneksi TCP di backend yang tidak responsif

Setiap kali koneksi TCP dengan pelacakan 5-tuple tetap ada di backend yang tidak sehat:

Jika backend yang tidak responsif terus merespons paket, koneksi akan terus berlanjut hingga direset atau ditutup (oleh backend yang tidak responsif atau klien).
Jika backend yang tidak sehat mengirim paket reset TCP (RST) atau tidak merespons paket, klien mungkin akan mencoba lagi dengan koneksi baru, sehingga load balancer dapat memilih backend lain yang sehat. Paket TCP SYN selalu memilih backend baru yang sehat.

Untuk mempelajari cara mengubah perilaku persistensi koneksi, lihat Mengonfigurasi kebijakan tracking koneksi.

Waktu tunggu tidak ada aktivitas

Masa berlaku entri dalam tabel pelacakan koneksi akan berakhir setelah 60 detik setelah load balancer memproses paket terakhir yang cocok dengan entri. Nilai waktu tunggu tidak ada aktivitas ini tidak dapat diubah.

Load balancing berbobot

Anda dapat mengonfigurasi load balancer jaringan untuk mendistribusikan traffic di seluruh instance backend load balancer berdasarkan bobot yang dilaporkan oleh health check HTTP menggunakan load balancing berbobot.

Load balancing berbobot mengharuskan Anda mengonfigurasi kedua hal berikut:

Anda harus menetapkan kebijakan load balancer lokalitas (localityLbPolicy) dari layanan backend ke WEIGHTED_MAGLEV.
Anda harus mengonfigurasi layanan backend dengan health check HTTP. Respons pemeriksaan kesehatan HTTP harus berisi kolom header respons HTTP kustom X-Load-Balancing-Endpoint-Weight untuk menentukan bobot dengan nilai dari 0 ke 1000 untuk setiap instance backend.

Jika Anda menggunakan backend yang sama (grup instance atau NEG) untuk beberapa Load Balancer Jaringan passthrough eksternal berbasis layanan backend menggunakan load balancing berbobot, sebaiknya gunakan request-path unik untuk setiap health check layanan backend. Hal ini memungkinkan instance endpoint menetapkan bobot yang berbeda ke layanan backend yang berbeda. Untuk mengetahui informasi selengkapnya, lihat Kriteria keberhasilan untuk pemeriksaan status HTTP, HTTPS, dan HTTP/2.

Untuk memilih backend untuk koneksi baru, backend diberi urutan prioritas yang ketat berdasarkan bobot dan status kesehatannya seperti yang ditunjukkan dalam tabel berikut:

Bobot	Responsif	Prioritas pemilihan backend
Berat lebih besar dari nol	Ya	4
Berat lebih besar dari nol	Tidak	3
Bobot sama dengan nol	Ya	2
Bobot sama dengan nol	Tidak	1

Hanya backend dengan prioritas tertinggi yang memenuhi syarat untuk pemilihan backend. Jika semua backend yang memenuhi syarat memiliki bobot nol, load balancer akan mendistribusikan koneksi baru di antara semua backend yang memenuhi syarat, dengan memperlakukannya dengan bobot yang sama. Untuk contoh load balancing berbobot, lihat Pemilihan backend dan pelacakan koneksi.

Load balancing berbobot dapat digunakan dalam skenario berikut:

Jika beberapa koneksi memproses lebih banyak data daripada yang lain, atau beberapa koneksi berlangsung lebih lama daripada yang lain, distribusi beban backend mungkin menjadi tidak merata. Dengan memberikan sinyal bobot per instance yang lebih rendah, instance dengan beban tinggi dapat mengurangi pangsa koneksi barunya, sekaligus terus melayani koneksi yang ada.
Jika backend kelebihan beban dan menetapkan lebih banyak koneksi dapat merusak koneksi yang ada, backend tersebut akan menetapkan bobot nol untuk dirinya sendiri. Dengan memberi sinyal bobot nol, instance backend berhenti melayani koneksi baru, tetapi terus melayani koneksi yang ada.
Jika backend menghabiskan koneksi yang ada sebelum pemeliharaan, backend akan menetapkan bobot nol untuk dirinya sendiri. Dengan memberikan bobot nol, instance backend akan berhenti melayani koneksi baru, tetapi terus melayani koneksi yang ada.

Untuk informasi selengkapnya, lihat Mengonfigurasi load balancing berbobot.

Pengosongan koneksi

Pengosongan koneksi adalah proses yang diterapkan ke koneksi yang dibuat dalam kasus berikut:

VM atau endpoint dihapus dari backend (grup instance atau NEG).
Backend menghapus VM atau endpoint (dengan penggantian, penghentian, saat melakukan upgrade, atau menskalakan ke bawah).
Backend dihapus dari layanan backend.

Secara default, pengosongan koneksi dinonaktifkan. Jika dinonaktifkan, koneksi yang sudah dibuat akan dihentikan secepat mungkin. Jika penghentian koneksi diaktifkan, koneksi yang dibuat diizinkan untuk tetap ada selama waktu tunggu yang dapat dikonfigurasi, setelah itu instance VM backend dihentikan.

Untuk mengetahui detail selengkapnya tentang cara pengosongan koneksi dipicu dan cara mengaktifkan pengosongan koneksi, lihat Mengaktifkan pengosongan koneksi.

Fragmentasi UDP

Load Balancer Jaringan passthrough eksternal berbasis layanan backend dapat memproses paket UDP yang terfragmentasi dan tidak terfragmentasi. Jika aplikasi Anda menggunakan paket UDP yang terfragmentasi, perhatikan hal berikut:

Paket UDP mungkin terfragmentasi sebelum mencapai jaringan VPC Google Cloud.
Jaringan VPCGoogle Cloud meneruskan fragmen UDP saat fragmen tersebut datang (tanpa menunggu semua fragmen tiba).
Jaringan non-Google Cloud dan peralatan jaringan lokal mungkin meneruskan fragmen UDP saat tiba, menunda paket UDP yang terfragmentasi hingga semua fragmen tiba, atau menghapus paket UDP yang terfragmentasi. Untuk mengetahui detailnya, lihat dokumentasi untuk penyedia jaringan atau peralatan jaringan.

Jika Anda mengharapkan paket UDP yang terfragmentasi dan perlu merutekannya ke backend yang sama, gunakan aturan penerusan dan parameter konfigurasi layanan backend berikut:

Konfigurasi aturan penerusan: Hanya gunakan satu aturan penerusan UDP atau L3_DEFAULT per alamat IP yang di-load balance, dan konfigurasikan aturan penerusan untuk menerima traffic di semua port. Tindakan ini memastikan bahwa semua fragmen tiba di aturan penerusan yang sama. Meskipun paket yang terfragmentasi (selain fragmen pertama) tidak memiliki port tujuan, mengonfigurasi aturan penerusan untuk memproses traffic untuk semua port juga mengonfigurasinya untuk menerima fragmen UDP yang tidak memiliki informasi port. Untuk mengonfigurasi semua port, gunakan Google Cloud CLI untuk menetapkan --ports=ALL atau gunakan API untuk menetapkan allPorts ke True.
Konfigurasi layanan backend: Tetapkan afinitas sesi layanan backend ke CLIENT_IP (hash 2-tuple) atau CLIENT_IP_PROTO (hash 3-tuple) sehingga backend yang sama dipilih untuk paket UDP yang menyertakan informasi port dan fragmen UDP (selain fragmen pertama) yang tidak memiliki informasi port. Tetapkan mode pelacakan koneksi layanan backend ke PER_SESSION sehingga entri tabel pelacakan koneksi dibuat menggunakan hash 2-tuple atau 3-tuple yang sama.

Failover

Anda dapat mengonfigurasi Network Load Balancer passthrough eksternal untuk mendistribusikan koneksi di antara instance VM atau endpoint di backend utama (grup instance atau NEG), lalu beralih, jika diperlukan, untuk menggunakan backend failover. Failover menyediakan metode lain untuk meningkatkan ketersediaan, sekaligus memberi Anda kontrol yang lebih besar atas cara mengelola beban kerja saat backend utama tidak berfungsi.

Secara default, saat Anda menambahkan backend ke layanan backend Load Balancer Jaringan passthrough eksternal, backend tersebut adalah backend utama. Anda dapat menetapkan backend sebagai backend failover saat menambahkannya ke layanan backend load balancer, atau dengan mengedit layanan backend nanti.

Untuk mengetahui detail selengkapnya tentang cara kerja failover, lihat Ringkasan failover untuk Network Load Balancer passthrough eksternal.

Langkah selanjutnya

Untuk mengonfigurasi Load Balancer Jaringan passthrough eksternal dengan layanan backend hanya untuk traffic TCP atau UDP (mendukung traffic IPv4 dan IPv6), lihat Menyiapkan Load Balancer Jaringan passthrough eksternal dengan layanan backend.
Untuk mengonfigurasi Load Balancer Jaringan passthrough eksternal untuk beberapa protokol IP (mendukung traffic IPv4 dan IPv6), lihat Menyiapkan Load Balancer Jaringan passthrough eksternal untuk beberapa protokol IP.
Untuk mengonfigurasi Load Balancer Jaringan passthrough eksternal dengan backend NEG zona, lihat Menyiapkan Load Balancer Jaringan passthrough eksternal dengan NEG zona
Untuk mempelajari cara mentransisikan Load Balancer Jaringan passthrough eksternal dari backend kumpulan target ke layanan backend regional, lihat Mentransisikan Load Balancer Jaringan passthrough eksternal dari kumpulan target ke layanan backend.