Halaman ini diterjemahkan oleh Cloud Translation API.

Distribusi traffic untuk Load Balancer Jaringan passthrough internal

Halaman ini menjelaskan konsep tentang cara Load Balancer Jaringan passthrough internal mendistribusikan traffic.

Pemilihan backend dan pelacakan koneksi

Pemilihan backend dan pelacakan koneksi bekerja sama untuk menyeimbangkan beberapa koneksi di berbagai backend dan merutekan semua paket untuk setiap koneksi ke backend yang sama. Hal ini dilakukan dengan strategi dua bagian. Pertama, backend dipilih menggunakan hashing yang konsisten. Kemudian, pemilihan ini dicatat dalam tabel pelacakan koneksi.

Langkah-langkah berikut menangkap proses pemilihan backend dan pelacakan koneksi.

1. Periksa entri tabel pelacakan koneksi untuk menggunakan backend yang dipilih sebelumnya.

Untuk koneksi yang ada, load balancer menggunakan tabel pelacakan koneksi untuk mengidentifikasi backend yang dipilih sebelumnya untuk koneksi tersebut.

Load balancer mencoba mencocokkan setiap paket yang di-load balance dengan entri dalam tabel pelacakan koneksinya menggunakan proses berikut:

Jika paket adalah paket TCP dengan flag SYN:
- Jika mode pelacakan koneksi load balancer adalah PER_CONNECTION, lanjutkan ke langkah Mengidentifikasi backend yang memenuhi syarat. Dalam mode pelacakan PER_CONNECTION, paket TCP dengan flag SYN selalu mewakili koneksi baru, terlepas dari afinitas sesi yang dikonfigurasi.
- Jika mode pelacakan koneksi load balancer adalah PER_SESSION dan afinitas sesi adalah NONE atau CLIENT_IP_PORT_PROTO, lanjutkan ke langkah Mengidentifikasi backend yang memenuhi syarat. Dalam mode pelacakan PER_SESSION, paket TCP dengan flag SYN mewakili koneksi baru hanya saat menggunakan salah satu opsi afinitas sesi 5-tuple (NONE atau CLIENT_IP_PORT_PROTO).
Untuk semua paket lainnya, load balancer akan memeriksa apakah paket cocok dengan entri tabel pelacakan koneksi yang ada. Tuple koneksi (serangkaian karakteristik paket) yang digunakan untuk membandingkan paket dengan entri tabel pelacakan koneksi yang ada bergantung pada mode pelacakan koneksi dan afinitas sesi yang Anda konfigurasikan. Untuk informasi tentang tuple koneksi mana yang digunakan untuk pelacakan koneksi, lihat tabel di bagian Mode pelacakan koneksi.
- Jika paket cocok dengan entri tabel pelacakan koneksi, load balancer akan mengirimkan paket ke backend yang dipilih sebelumnya.
- Jika paket tidak cocok dengan entri tabel pelacakan koneksi, lanjutkan ke langkah Mengidentifikasi backend yang memenuhi syarat.
Untuk mengetahui informasi tentang berapa lama entri tabel pelacakan koneksi tetap ada dan dalam kondisi apa entri tersebut tetap ada, lihat langkah Membuat entri tabel pelacakan koneksi.

2. Pilih backend yang memenuhi syarat untuk koneksi baru.

Untuk koneksi baru, load balancer menggunakan algoritma hashing konsisten untuk memilih backend di antara backend yang memenuhi syarat dari kumpulan aktif.

Langkah-langkah berikut menguraikan proses untuk memilih backend yang memenuhi syarat untuk koneksi baru, lalu mencatat koneksi tersebut dalam tabel pelacakan koneksi.

2.1 Mengidentifikasi backend yang memenuhi syarat.

Langkah ini membuat model backend mana yang menjadi kandidat untuk menerima koneksi baru, dengan mempertimbangkan konfigurasi status dan kebijakan failover:

Tidak ada kebijakan failover: Kumpulan backend yang memenuhi syarat hanya bergantung pada health check:
- Jika setidaknya satu backend responsif, kumpulan backend yang memenuhi syarat terdiri dari semua backend responsif.
- Jika semua backend tidak responsif, kumpulan backend yang memenuhi syarat terdiri dari semua backend.
Kebijakan failover dikonfigurasi: Kumpulan backend yang memenuhi syarat bergantung pada health check dan konfigurasi kebijakan failover:
- Jika minimal satu backend responsif, kumpulan backend yang memenuhi syarat terdiri dari semua backend responsif di kumpulan aktif.
  - Kumpulan aktif mungkin terdiri dari semua backend utama yang sehat, atau mungkin terdiri dari semua backend failover yang sehat. Keanggotaan dalam kumpulan aktif ditentukan oleh rasio failover yang dikonfigurasi, jumlah backend utama yang responsif, dan jumlah total backend utama.
  - Terlepas dari rasio failover, jika tidak ada backend failover yang responsif, tetapi ada setidaknya satu backend utama yang responsif, kumpulan aktif akan terdiri dari semua backend utama yang responsif.
- Jika tidak ada backend yang responsif, dan kebijakan failover load balancer dikonfigurasi untuk menghentikan koneksi baru, dalam situasi ini, kumpulan backend yang memenuhi syarat akan kosong. Load balancer akan menghapus paket untuk koneksi.
- Jika tidak ada backend yang responsif, dan kebijakan failover load balancer tidak dikonfigurasi untuk menghentikan koneksi baru, dalam situasi ini, health check tidak relevan. Backend yang memenuhi syarat terdiri dari semua backend utama.

2.2 Pilih backend yang memenuhi syarat.

Load balancer menggunakan hashing konsisten untuk memilih backend yang memenuhi syarat. Load balancer mempertahankan hash backend yang memenuhi syarat, yang dipetakan ke lingkaran unit. Saat memproses paket untuk koneksi yang tidak ada dalam tabel pelacakan koneksi, load balancer menghitung hash karakteristik paket dan memetakan hash tersebut ke lingkaran unit yang sama, memilih backend yang memenuhi syarat pada lingkaran lingkaran. Kumpulan karakteristik paket yang digunakan untuk menghitung hash paket ditentukan oleh setelan afinitas sesi.

Jika afinitas sesi tidak dikonfigurasi secara eksplisit, afinitas sesi NONE adalah default.
Load balancer menetapkan koneksi baru ke backend yang memenuhi syarat dengan cara yang sekonsisten mungkin meskipun jumlah backend yang memenuhi syarat berubah. Manfaat hashing konsisten berikut menunjukkan cara load balancer memilih backend yang memenuhi syarat untuk kemungkinan koneksi baru yang tidak memiliki entri tabel pelacakan koneksi:
- Load balancer memilih backend yang sama untuk semua kemungkinan koneksi baru yang memiliki karakteristik paket yang identik, seperti yang ditentukan oleh afinitas sesi, jika kumpulan backend yang memenuhi syarat tidak berubah.
- Saat backend baru yang memenuhi syarat ditambahkan, sekitar 1/N kemungkinan koneksi baru akan dipetakan ke backend yang baru ditambahkan. Dalam situasi ini, N adalah jumlah backend yang memenuhi syarat setelah backend baru ditambahkan.
- Saat backend yang memenuhi syarat dihapus, sekitar 1/N kemungkinan koneksi baru akan dipetakan ke salah satu dari N-1 backend yang tersisa. Dalam situasi ini, N adalah jumlah backend sebelum backend yang memenuhi syarat dihapus.

2.3 Buat entri tabel pelacakan koneksi.

Setelah memilih backend, load balancer akan membuat entri tabel pelacakan koneksi. Entri tabel pelacakan koneksi memetakan karakteristik paket ke backend yang dipilih. Kolom header paket yang digunakan untuk pemetaan ini bergantung pada mode pelacakan koneksi dan afinitas sesi yang Anda konfigurasikan.

Load balancer menghapus entri tabel pelacakan koneksi sesuai dengan aturan berikut:

Entri tabel pelacakan koneksi dihapus setelah koneksi tidak ada aktivitas. Kecuali jika Anda mengonfigurasi waktu tunggu tidak ada aktivitas kustom, load balancer akan menggunakan waktu tunggu tidak ada aktivitas default 600 detik. Untuk informasi selengkapnya, lihat Waktu tunggu tidak ada aktivitas.
Entri tabel pelacakan koneksi tidak dihapus saat koneksi TCP ditutup dengan paket FIN atau RST. Setiap koneksi TCP baru selalu membawa flag SYN dan diproses seperti yang dijelaskan dalam langkah Memeriksa entri tabel pelacakan koneksi.
Jika kebijakan failover dikonfigurasi dan pengosongan koneksi saat setelan failover dan failback dinonaktifkan, load balancer akan menghapus semua entri dalam tabel pelacakan koneksi saat kumpulan aktif berubah selama failover atau failback. Untuk mengetahui informasi selengkapnya, lihat Pengosongan koneksi saat terjadi failover dan failback.
Entri dalam tabel pelacakan koneksi dapat dihapus jika backend menjadi tidak sehat. Perilaku ini bergantung pada mode pelacakan koneksi, protokol, dan persistensi koneksi pada setelan backend yang tidak responsif. Untuk mengetahui informasi selengkapnya, lihat Persistensi koneksi di backend yang tidak sehat.
Entri dalam tabel pelacakan koneksi dihapus setelah waktu tunggu pengosongan koneksi yang terjadi setelah peristiwa seperti menghapus VM backend atau menghapus VM backend dari grup instance atau NEG. Untuk informasi selengkapnya, lihat Mengaktifkan pengosongan koneksi.

Afinitas sesi

Afinitas sesi mengontrol distribusi koneksi baru dari klien ke backend load balancer. Load Balancer Jaringan passthrough internal menggunakan afinitas sesi untuk memilih backend dari kumpulan backend yang memenuhi syarat seperti yang dijelaskan dalam langkah Mengidentifikasi backend yang memenuhi syarat dan Memilih backend yang memenuhi syarat di bagian Pemilihan backend dan pelacakan koneksi. Anda mengonfigurasi afinitas sesi di layanan backend, bukan di setiap grup instance backend atau NEG.

Load Balancer Jaringan passthrough internal mendukung setelan afinitas sesi berikut. Setiap setelan afinitas sesi menggunakan hashing konsisten untuk memilih backend yang memenuhi syarat. Setelan afinitas sesi menentukan kolom dari header IP dan header Lapisan 4 yang digunakan untuk menghitung hash.

Metode hash untuk pemilihan backend	Setelan afinitas sesi
Hash 5-tuple (terdiri dari alamat IP sumber, port sumber, protokol, alamat IP tujuan, dan port tujuan) untuk paket yang tidak terfragmentasi yang menyertakan informasi port seperti paket TCP dan paket UDP yang tidak terfragmentasi ATAU Hash 3-tuple (terdiri dari alamat IP sumber, alamat IP tujuan, dan protokol) untuk paket UDP yang terfragmentasi dan paket dari semua protokol lainnya	`NONE`¹
Hash 5-tuple (terdiri dari alamat IP sumber, port sumber, protokol, alamat IP tujuan, dan port tujuan) untuk paket yang tidak terfragmentasi yang menyertakan informasi port seperti paket TCP dan paket UDP yang tidak terfragmentasi ATAU Hash 3-tuple (terdiri dari alamat IP sumber, alamat IP tujuan, dan protokol) untuk paket UDP yang terfragmentasi dan paket dari semua protokol lainnya	`CLIENT_IP_PORT_PROTO`
Hash 3-tuple (terdiri dari alamat IP sumber, alamat IP tujuan, dan protokol)	`CLIENT_IP_PROTO`
Hash 2-tuple (terdiri dari alamat IP sumber dan alamat IP tujuan)	`CLIENT_IP`
Hash 1-tuple (hanya terdiri dari IP sumber)	`CLIENT_IP_NO_DESTINATION`²

¹ Setelan afinitas sesi NONE tidak berarti tidak ada afinitas sesi. Artinya, tidak ada opsi afinitas sesi yang dikonfigurasi secara eksplisit.

Hashing selalu dilakukan untuk memilih backend. Selain itu, setelan afinitas sesi NONE berarti load balancer menggunakan hash 5-tuple atau hash 3-tuple untuk memilih backend—secara fungsional, perilakunya sama seperti saat CLIENT_IP_PORT_PROTO ditetapkan.

² CLIENT_IP_NO_DESTINATION adalah hash satu tuple berdasarkan alamat IP sumber dari setiap paket yang diterima. Setelan ini dapat berguna dalam situasi saat Anda memerlukan VM backend yang sama untuk memproses semua paket dari klien, hanya berdasarkan alamat IP sumber paket, tanpa mempertimbangkan alamat IP tujuan paket. Situasi ini biasanya muncul saat Load Balancer Jaringan passthrough internal adalah next hop untuk rute statis. Untuk mengetahui detailnya, lihat Afinitas sesi dan Load Balancer Jaringan passthrough internal next hop.

Untuk mempelajari pengaruh berbagai setelan afinitas sesi terhadap metode pemilihan backend dan pelacakan koneksi, lihat tabel di bagian Mode pelacakan koneksi.

Afinitas sesi dan next hop Load Balancer Jaringan passthrough internal

Saat Anda mengonfigurasi rute statis untuk menggunakan next hop Load Balancer Jaringan passthrough internal, load balancer akan menggunakan metode pelacakan koneksi dan pemilihan backend yang sama. Pemilihan backend masih dilakukan dengan menghitung hash sesuai dengan afinitas sesi yang dikonfigurasi. Kecuali untuk afinitas sesi CLIENT_IP_NO_DESTINATION (hash 1-tuple), hash pemilihan backend sebagian bergantung pada alamat IP tujuan paket.

Jika load balancer Network Load Balancer passthrough internal adalah next hop dari rute statis, alamat IP tujuan tidak terbatas pada alamat IP aturan penerusan load balancer. Sebagai gantinya, alamat IP tujuan paket dapat berupa alamat IP mana pun yang sesuai dengan rentang tujuan rute statis.

Jika jumlah VM backend yang dikonfigurasi dan responsif konstan (saat failover tidak dikonfigurasi, atau, saat failover dikonfigurasi tetapi tidak ada peristiwa failover atau failback yang terjadi), load balancer akan berperilaku sebagai berikut:

Jika hanya ada satu VM backend yang dikonfigurasi dan berfungsi (di kumpulan aktif, jika failover dikonfigurasi), tidak masalah afinitas sesi apa yang Anda gunakan karena semua hash dipetakan ke satu VM backend.
Jika ada dua atau lebih VM backend yang dikonfigurasi dan responsif (dalam kumpulan aktif, jika failover dikonfigurasi), pilihan afinitas sesi Anda penting:
- Jika Anda memerlukan VM backend yang sama untuk memproses semua paket dari klien, hanya berdasarkan alamat IP sumber paket, terlepas dari alamat IP tujuan paket, gunakan afinitas sesi CLIENT_IP_NO_DESTINATION. Bergantung pada pola traffic, beberapa VM backend mungkin menerima lebih banyak paket atau lebih banyak koneksi daripada VM backend lainnya.
- Jika Anda menggunakan opsi afinitas sesi yang bukan CLIENT_IP_NO_DESTINATION, load balancer akan memilih VM backend berdasarkan informasi yang setidaknya menyertakan baik alamat IP sumber dan alamat IP tujuan paket. Paket yang dikirim dari klien yang sama, menggunakan alamat IP sumber yang sama, tetapi alamat IP tujuan yang berbeda, dapat dirutekan ke VM backend yang berbeda.

Kebijakan pelacakan koneksi

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

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

Mode pelacakan koneksi

Tabel pelacakan koneksi load balancer memetakan tuple koneksi ke backend yang dipilih sebelumnya dalam tabel hash. Kumpulan karakteristik paket yang menyusun setiap tuple koneksi ditentukan oleh mode pelacakan koneksi dan afinitas sesi.

Load Balancer Jaringan passthrough internal melacak koneksi untuk semua protokol yang didukungnya.

Mode pelacakan koneksi mengacu pada tingkat perincian setiap tuple koneksi dalam tabel pelacakan koneksi load balancer. Tuple koneksi dapat berupa 5-tuple atau 3-tuple (mode PER_CONNECTION), atau dapat cocok dengan setelan afinitas sesi (mode PER_SESSION).

PER_CONNECTION. Ini adalah mode pelacakan koneksi default. Mode pelacakan koneksi ini menggunakan hash 5-tuple atau hash 3-tuple. Paket yang tidak terfragmentasi yang menyertakan informasi port seperti paket TCP dan paket UDP yang tidak terfragmentasi dilacak dengan hash 5-tuple. Semua paket lainnya dilacak dengan hash 3-tuple.
PER_SESSION. Mode pelacakan koneksi ini menggunakan hash yang terdiri dari karakteristik paket yang sama dengan yang digunakan oleh hash afinitas sesi. Bergantung pada afinitas sesi yang dipilih, PER_SESSION dapat menghasilkan koneksi yang lebih sering cocok dengan entri tabel pelacakan koneksi yang ada, sehingga mengurangi frekuensi backend yang perlu dipilih oleh hash afinitas sesi.

Tabel berikut merangkum cara mode pelacakan koneksi dan afinitas sesi berfungsi bersama untuk merutekan semua paket untuk setiap koneksi ke backend yang sama.

Pemilihan backend menggunakan afinitas sesi		Mode pelacakan koneksi
Setelan afinitas sesi	Metode hash untuk pemilihan backend	`PER_CONNECTION` (default)	`PER_SESSION`
`NONE`	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: Hash 5-tuple UDP yang terfragmentasi dan semua protokol lainnya: Hash 3-tuple	TCP dan UDP yang tidak terfragmentasi: Hash 5-tuple UDP yang terfragmentasi dan semua protokol lainnya: Hash 3-tuple
`CLIENT_IP_NO_DESTINATION`	Semua protokol: Hash 1-tuple	TCP dan UDP yang tidak terfragmentasi: Hash 5-tuple UDP yang terfragmentasi dan semua protokol lainnya: Hash 3-tuple	Semua protokol: Hash 1-tuple
`CLIENT_IP`	Semua protokol: Hash 2-tuple	TCP dan UDP yang tidak terfragmentasi: Hash 5-tuple UDP yang terfragmentasi dan semua protokol lainnya: Hash 3-tuple	Semua protokol: Hash 2-tuple
`CLIENT_IP_PROTO`	Semua protokol: Hash 3-tuple	TCP dan UDP yang tidak terfragmentasi: Hash 5-tuple UDP yang terfragmentasi dan semua protokol lainnya: Hash 3-tuple	Semua protokol: Hash 3-tuple
`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: Hash 5-tuple UDP yang terfragmentasi dan semua protokol lainnya: Hash 3-tuple	TCP dan UDP yang tidak terfragmentasi: Hash 5-tuple UDP yang terfragmentasi dan semua protokol lainnya: Hash 3-tuple

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).

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) UDP: koneksi tidak pernah tetap ada di backend yang tidak sehat	TCP: koneksi tetap ada di backend yang tidak responsif jika afinitas sesi adalah `NONE` atau `CLIENT_IP_PORT_PROTO` UDP: koneksi tidak pernah dipertahankan di backend yang tidak sehat
`NEVER_PERSIST`	TCP, UDP: koneksi tidak pernah dipertahankan di backend yang tidak sehat
`ALWAYS_PERSIST`	TCP, UDP: koneksi tetap ada di backend yang tidak sehat (semua afinitas sesi) Opsi ini hanya boleh digunakan untuk kasus penggunaan lanjutan.	Konfigurasi tidak memungkinkan

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

Catatan: Jika backend menjadi tidak responsif, load balancer akan menghapus entri tabel pelacakan koneksi yang ada sesuai dengan protokol paket dan opsi persistensi koneksi yang dipilih pada backend yang tidak responsif. Paket berikutnya untuk koneksi yang entrinya dihapus akan diperlakukan sebagai koneksi baru. Load balancer membuat entri tabel pelacakan koneksi pengganti—setelah memilih backend yang memenuhi syarat—untuk setiap koneksi. Entri tabel pelacakan koneksi pengganti tetap valid sesuai dengan kondisi yang sama seperti entri tabel pelacakan koneksi lainnya. Jika backend yang tidak responsif kembali menjadi responsif, peristiwa tersebut saja tidak menyebabkan entri tabel pelacakan koneksi pengganti dihapus, kecuali peristiwa tersebut memicu failback dan pengosongan koneksi saat failover dan failback dinonaktifkan.

Waktu tunggu tidak ada aktivitas

Secara default, masa berlaku entri dalam tabel pelacakan koneksi berakhir setelah 600 detik setelah load balancer memproses paket terakhir yang cocok dengan entri. Nilai waktu tunggu tidak ada aktivitas default ini hanya dapat diubah jika pelacakan koneksi kurang dari 5-tuple (yaitu, saat afinitas sesi dikonfigurasi menjadi CLIENT_IP atau CLIENT_IP_PROTO, dan mode pelacakannya adalah PER_SESSION).

Nilai waktu tunggu tidak ada aktivitas maksimum yang dapat dikonfigurasi adalah 57.600 detik (16 jam).

Untuk mempelajari cara mengubah nilai waktu tunggu tidak ada aktivitas, lihat Mengonfigurasi kebijakan tracking koneksi.

Koneksi untuk deployment satu klien

Saat menguji koneksi ke alamat IP Load Balancer Jaringan passthrough internal yang hanya memiliki satu klien, Anda harus mengingat hal berikut:

Jika VM klien bukan VM yang di-load balance—yaitu, VM tersebut juga bukan VM backend, koneksi baru akan dikirim ke VM backend load balancer yang sehat. Namun, karena semua opsi afinitas sesi bergantung setidaknya pada alamat IP sistem klien, koneksi dari klien yang sama mungkin didistribusikan ke VM backend yang sama lebih sering daripada yang Anda harapkan.

Secara praktis, ini berarti Anda tidak dapat memantau distribusi traffic secara akurat melalui Load Balancer Jaringan passthrough internal dengan menghubungkannya dari satu klien. Jumlah klien yang diperlukan untuk memantau distribusi traffic bervariasi bergantung pada jenis load balancer, jenis traffic, dan jumlah backend yang sehat.
Jika VM klien juga merupakan VM backend load balancer, koneksi yang dikirim ke alamat IP aturan penerusan load balancer selalu dijawab oleh VM backend yang sama (yang juga merupakan VM klien). Hal ini terjadi terlepas dari apakah VM backend responsif atau tidak. Hal ini terjadi untuk semua traffic yang dikirim ke alamat IP load balancer, bukan hanya traffic pada protokol dan port yang ditentukan dalam aturan penerusan internal load balancer.

Untuk mengetahui informasi selengkapnya, lihat artikel mengirim permintaan dari VM yang di-load balanced.

Pengosongan koneksi

Pengosongan koneksi memberikan jumlah waktu tambahan yang dapat dikonfigurasi agar koneksi yang dibuat tetap ada di tabel pelacakan koneksi load balancer saat salah satu tindakan berikut terjadi:

Instance virtual machine (VM) dihapus dari grup instance backend (termasuk mengabaikan instance di grup instance terkelola backend)
VM dihentikan atau dihapus (termasuk tindakan otomatis seperti update bergulir atau menskalakan turun grup instance terkelola backend)
Endpoint dihapus dari grup endpoint jaringan (NEG) backend

Secara default, pengosongan koneksi untuk tindakan yang disebutkan di atas dinonaktifkan. Untuk informasi tentang cara pengosongan koneksi dipicu dan cara mengaktifkan pengosongan koneksi, lihat Mengaktifkan pengosongan koneksi.

Fragmentasi UDP

Load Balancer Jaringan passthrough internal dapat memproses paket UDP fragmentasi dan tidak fragmentasi. Jika aplikasi Anda menggunakan paket UDP yang terfragmentasi, perhatikan hal-hal berikut:

Paket UDP mungkin menjadi terfragmentasi sebelum mencapai jaringan VPC Google Cloud.
Google Cloud Jaringan VPC meneruskan fragmen UDP saat 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 per alamat IP yang di-load balance, dan konfigurasikan aturan penerusan untuk menerima traffic di semua port. Hal 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

Load Balancer Jaringan passthrough internal memungkinkan Anda menetapkan beberapa backend sebagai backend failover. Backend ini hanya digunakan jika jumlah VM responsif di grup instance backend utama telah turun di bawah nilai minimum yang dapat dikonfigurasi. Secara default, jika semua VM utama dan failover tidak responsif, sebagai upaya terakhir, Google Cloud mendistribusikan koneksi baru hanya di antara semua VM utama.

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

Untuk informasi selengkapnya tentang cara failover digunakan untuk pemilihan backend dan pelacakan koneksi, lihat langkah-langkah Mengidentifikasi backend yang memenuhi syarat dan Membuat entri tabel pelacakan koneksi di bagian Pemilihan backend dan pelacakan koneksi.

Untuk mengetahui informasi selengkapnya tentang cara kerja failover, lihat Failover untuk Load Balancer Jaringan passthrough internal.

Langkah berikutnya

Untuk mengonfigurasi dan menguji Load Balancer Jaringan passthrough internal yang menggunakan failover, lihat Mengonfigurasi failover untuk Load Balancer Jaringan passthrough internal.
Untuk mengonfigurasi dan menguji Load Balancer Jaringan passthrough internal, lihat Menyiapkan Load Balancer Jaringan passthrough internal.