Distribusi traffic untuk Load Balancer Jaringan passthrough internal

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

Pelacakan koneksi dan pemilihan backend

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 dapat dilakukan dengan strategi dua bagian. Pertama, backend dipilih menggunakan hashing yang konsisten. Kemudian, pilihan ini dicatat dalam tabel pelacakan koneksi.

Langkah-langkah berikut menjelaskan pemilihan backend dan pelacakan koneksi.

1. Periksa entri tabel pelacakan koneksi

Load balancer menentukan apakah paket yang di-load balance termasuk dalam koneksi baru atau koneksi yang ada menggunakan proses berikut:

• Paket TCP dengan flag SYN:

  • Jika mode pelacakan koneksi load balancer adalah PER_CONNECTION, lanjutkan ke langkah Identifikasi backend yang memenuhi syarat. Dalam mode pelacakan PER_CONNECTION, paket TCP dengan tanda SYN selalu merepresentasikan 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 Identifikasi backend yang memenuhi syarat. Dalam mode pelacakan PER_SESSION, paket TCP dengan tanda SYN mewakili koneksi baru hanya saat menggunakan salah satu opsi afinitas sesi 5-tuple (NONE atau CLIENT_IP_PORT_PROTO).

• Semua paket lainnya: load balancer memeriksa apakah paket cocok dengan entri tabel pelacakan koneksi yang ada. Perincian hash paket yang digunakan untuk memeriksa entri tabel pelacakan koneksi yang ada bergantung pada mode pelacakan koneksi dan afinitas sesi yang Anda konfigurasi. Untuk mengetahui informasi selengkapnya, 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 Identifikasi 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 Mengelola entri tabel pelacakan koneksi.

2. Langkah-langkah pemilihan backend

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

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

Backend yang memenuhi syarat adalah backend yang menjadi kandidat untuk menerima koneksi baru. Tabel berikut menentukan kumpulan backend yang memenuhi syarat, bergantung pada apakah Anda telah mengonfigurasi kebijakan failover.

Kebijakan failover	Backend yang memenuhi syarat
	Jika tidak ada kebijakan failover yang dikonfigurasi, semua backend yang dikonfigurasi adalah backend utama. Kumpulan backend yang memenuhi syarat didefinisikan sebagai berikut: Jika ada setidaknya satu backend yang responsif, kumpulan backend yang memenuhi syarat terdiri dari semua backend yang responsif. Jika semua backend tidak responsif, kumpulan backend yang memenuhi syarat terdiri dari semua backend.
	Jika kebijakan failover dikonfigurasi, load balancer akan menggunakan informasi health check dan konfigurasi kebijakan failover untuk menentukan kumpulan backend yang memenuhi syarat: Jika setidaknya satu backend (primer atau failover) responsif, backend yang memenuhi syarat adalah backend yang berasal dari kumpulan pertama berikut yang tidak kosong: Jika tidak ada backend utama yang responsif, backend yang memenuhi syarat adalah semua backend failover yang responsif. Jika tidak ada backend failover yang responsif, backend yang memenuhi syarat adalah semua backend utama yang responsif. Jika rasio failover ditetapkan ke 0.0 (nilai default), backend yang memenuhi syarat adalah semua backend utama yang responsif. Jika rasio jumlah backend utama yang responsif dibandingkan dengan jumlah total backend utama lebih besar dari atau sama dengan rasio failover yang dikonfigurasi, backend yang memenuhi syarat terdiri dari semua backend utama yang responsif. Backend yang memenuhi syarat terdiri dari semua backend failover yang responsif. Jika tidak ada backend yang responsif (primer dan failover), kumpulan backend yang memenuhi syarat hanya bergantung pada konfigurasi kebijakan failover: Jika kebijakan failover dikonfigurasi untuk menghentikan koneksi baru saat semua backend utama dan failover tidak responsif, set backend yang memenuhi syarat akan kosong. Akibatnya, load balancer menjatuhkan paket untuk koneksi baru. Jika kebijakan failover tidak dikonfigurasi untuk menghentikan koneksi baru saat semua backend utama dan failover tidak responsif, backend yang memenuhi syarat adalah semua backend utama yang tidak responsif.

2.2 Menyesuaikan backend yang memenuhi syarat untuk afinitas zona

Langkah ini dilewati jika salah satu kondisi berikut terpenuhi:

• Afinitas zonal dinonaktifkan
• Klien tidak kompatibel dengan afinitas zonal
• Pencocokan zona dengan zona klien yang kompatibel tidak terjadi

Jika afinitas zona diaktifkan, klien kompatibel dengan afinitas zona, dan kecocokan zona terjadi, koneksi baru dari klien akan dirutekan ke kumpulan backend yang memenuhi syarat yang disesuaikan. Untuk informasi selengkapnya, lihat referensi berikut:

• Cara kerja ZONAL_AFFINITY_STAY_WITHIN_ZONE

• Cara kerja ZONAL_AFFINITY_SPILL_CROSS_ZONE dan rasio peluberan

2.3 Pilih backend yang memenuhi syarat

Load balancer mempertahankan hash backend yang memenuhi syarat, dengan setiap hash backend dipetakan ke lingkaran satuan.

Saat memproses paket untuk koneksi yang tidak ada dalam tabel pelacakan koneksi, load balancer menghitung hash karakteristik paket dan memetakan hash tersebut ke lingkaran satuan yang sama, dengan memilih backend yang memenuhi syarat di keliling lingkaran. Kumpulan karakteristik paket yang digunakan untuk menghitung hash paket ditentukan oleh setelan afinitas sesi. Misalnya, jika afinitas sesi yang dipilih menghasilkan hash pemilihan backend 2-tuple atau 3-tuple, semua koneksi TCP dari alamat IP sumber dipetakan ke backend yang sama dan memenuhi syarat.

• Jika afinitas sesi tidak dikonfigurasi secara eksplisit, afinitas sesi NONE adalah defaultnya.

• Hashing yang konsisten memastikan load balancer menetapkan koneksi baru ke backend yang memenuhi syarat dengan cara yang meminimalkan gangguan pemetaan meskipun jumlah backend yang memenuhi syarat berubah.

  • Load balancer selalu memilih backend yang sama dan memenuhi syarat untuk koneksi, dan secara umum, selalu memilih backend yang sama dan memenuhi syarat untuk semua paket dengan karakteristik paket yang identik seperti yang ditentukan oleh setelan afinitas sesi, jika set backend yang memenuhi syarat tidak berubah.

  • Jika backend yang memenuhi syarat ditambahkan atau dihapus, hashing yang konsisten bertujuan untuk meminimalkan gangguan pemetaan ke backend lain yang memenuhi syarat—yaitu, sebagian besar koneksi yang dipetakan ke backend lain yang memenuhi syarat akan terus dipetakan ke backend yang sama yang memenuhi syarat.

• Selain itu, hashing yang konsisten memastikan load balancer mendistribusikan koneksi baru di antara backend yang memenuhi syarat seadil mungkin. Untuk semua kemungkinan hash paket seperti yang ditentukan oleh setelan afinitas sesi yang dikonfigurasi (dan lebih khusus lagi, untuk semua kemungkinan koneksi saat afinitas sesi menghasilkan hash 5-tuple untuk pemilihan backend):

  • Saat backend yang memenuhi syarat ditambahkan, sekitar 1/N koneksi baru dipetakan ke backend yang baru ditambahkan. Dalam situasi ini, N adalah jumlah backend setelah backend baru ditambahkan.

  • Jika backend yang memenuhi syarat dihapus, sekitar 1/N 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.4 Membuat 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 konfigurasi.

3. Mengelola entri tabel pelacakan koneksi

Load balancer mengelola entri tabel pelacakan koneksi sesuai dengan peristiwa dan aturan berikut:

• Entri tidak aktif dihapus: entri tabel pelacakan koneksi dihapus setelah koneksi tidak aktif. Kecuali jika Anda mengonfigurasi waktu tunggu tidak ada aktivitas kustom, load balancer akan menggunakan waktu tunggu tidak ada aktivitas default 600 detik. Untuk mengetahui informasi selengkapnya, lihat Waktu tunggu tidak ada aktivitas.

• Koneksi TCP tertutup: entri tabel pelacakan koneksi untuk koneksi TCP tidak dihapus saat koneksi TCP ditutup dengan paket FIN atau RST. Entri tersebut mungkin dihapus nanti sebagai entri tidak aktif. Setiap koneksi TCP baru selalu membawa tanda SYN, dan tunduk pada pemrosesan yang dijelaskan dalam langkah Periksa entri tabel pelacakan koneksi.

• Penghentian koneksi saat failover: jika setidaknya satu backend failover dikonfigurasi dan setelan penghentian koneksi saat failover dinonaktifkan, load balancer akan menghapus semua entri dalam tabel pelacakan koneksi saat kumpulan backend yang memenuhi syarat beralih antara backend utama dan failover. Untuk mengetahui informasi selengkapnya, lihat Penghentian koneksi saat failover.

• Persistensi koneksi di backend yang tidak sehat: entri dalam tabel pelacakan koneksi dapat dihapus jika backend menjadi tidak sehat. Perilaku ini bergantung pada faktor yang dijelaskan dalam Persistensi koneksi pada backend yang tidak sehat.

  • Jika entri tabel pelacakan koneksi dihapus karena backend yang sebelumnya dipilih berubah dari responsif menjadi tidak responsif, paket berikutnya untuk koneksi tersebut akan diperlakukan seolah-olah termasuk dalam koneksi baru. Setelah memilih backend baru yang memenuhi syarat untuk paket berikutnya, load balancer membuat entri tabel pelacakan koneksi pengganti.

  • Entri tabel pelacakan koneksi pengganti berperilaku persis seperti entri tabel pelacakan koneksi lainnya, dan tunduk pada peristiwa dan aturan langkah ini.

  • Jika backend yang dipilih sebelumnya kembali responsif dari tidak responsif, perubahan health check saja tidak menyebabkan entri tabel pelacakan koneksi pengganti dihapus. Pengecualian terjadi jika setidaknya satu backend failover dikonfigurasi dan setelan pengurasan koneksi saat failover dinonaktifkan; jika perubahan status health check backend yang sebelumnya dipilih bertepatan dengan set backend yang memenuhi syarat beralih antara backend failover dan backend utama, entri tabel pelacakan koneksi akan dihapus.

• Pengosongan koneksi untuk backend yang dihapus, dihentikan, atau dihapus: jika pengosongan koneksi untuk backend yang dihapus, dihentikan, atau dihapus diaktifkan, entri tabel pelacakan koneksi akan dihapus setelah waktu tunggu pengosongan koneksi yang dapat dikonfigurasi. Penghitungan waktu tunggu dimulai saat perintah untuk menghapus, menghentikan, atau menghapus backend diterima. Jika pengurasan koneksi untuk backend yang dihapus, dihentikan, atau dihapus dinonaktifkan, entri tabel pelacakan koneksi akan dihapus saat perintah untuk menghapus, menghentikan, atau menghapus backend diterima. Untuk informasi selengkapnya, lihat Mengaktifkan pengurasan koneksi.

Afinitas sesi

Setelan afinitas sesi Load Balancer Jaringan passthrough internal menentukan hash paket untuk pemilihan backend, dan, berdasarkan mode pelacakan koneksi, hash paket untuk pelacakan koneksi.

Anda mengonfigurasi afinitas sesi pada layanan backend, bukan pada setiap grup instance atau NEG backend. Afinitas sesi menentukan header IP dan Lapisan 4 mana yang digunakan untuk menghitung hash karakteristik paket. Hash karakteristik paket digunakan dalam langkah pemilihan Backend.

Load Balancer Jaringan passthrough internal mendukung setelan afinitas sesi berikut.

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 (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^1 ATAU 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 (terdiri dari IP sumber saja)	CLIENT_IP_NO_DESTINATION

Afinitas sesi ¹ NONE tidak menunjukkan bahwa tidak ada afinitas sesi. Sebaliknya, afinitas sesi dilakukan dengan hash 5-tuple atau hash 3-tuple dari karakteristik paket—secara fungsional perilaku yang sama seperti saat CLIENT_IP_PORT_PROTO ditetapkan.

Afinitas sesi dan next hop load balancer

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 apa pun yang sesuai dengan rentang tujuan rute statis.

Memilih backend yang memenuhi syarat bergantung pada penghitungan hash karakteristik paket. Kecuali afinitas sesi CLIENT_IP_NO_DESTINATION (hash 1 tuple), hash sebagian bergantung pada alamat IP tujuan paket.

Load balancer memilih backend yang sama untuk semua kemungkinan koneksi baru yang memiliki karakteristik paket yang identik, seperti yang ditentukan oleh afinitas sesi, jika setelan backend yang memenuhi syarat tidak berubah. Jika Anda memerlukan VM backend yang sama untuk memproses semua paket dari klien, hanya berdasarkan alamat IP sumber, terlepas dari alamat IP tujuan, gunakan afinitas sesi CLIENT_IP_NO_DESTINATION.

Kebijakan pelacakan koneksi

Bagian ini menjelaskan setelan dalam kebijakan pelacakan koneksi load balancer:

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

Mode pelacakan koneksi

Bagian ini menjelaskan cara load balancer membuat entri dalam tabel pelacakan koneksinya. Load Balancer Jaringan passthrough internal melacak koneksi untuk semua protokol yang didukung dan untuk semua opsi afinitas sesi.

Mode pelacakan koneksi, protokol, dan afinitas sesi menentukan serangkaian karakteristik paket yang digunakan untuk membuat hash paket di setiap entri tabel pelacakan koneksi.

Mode pelacakan koneksi dapat berupa salah satu dari berikut:

• PER_CONNECTION. Ini adalah mode pelacakan koneksi default dan paling terperinci. Setiap koneksi ditentukan sebagai hash 5-tuple atau hash 3-tuple karakteristik paket, bergantung pada apakah informasi port ada dalam paket. Paket yang tidak terfragmentasi yang mencakup 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 yang kurang terperinci ini menggunakan hash yang cocok dengan hash afinitas sesi. Bergantung pada afinitas sesi yang dipilih, mode pelacakan PER_SESSION dapat memperlakukan beberapa koneksi yang berbeda sebagai satu koneksi untuk tujuan pelacakan koneksi. Tindakan ini mengurangi frekuensi koneksi dianggap baru dan tunduk pada Langkah-langkah pemilihan backend.

Tabel berikut merangkum:

• Hash paket yang digunakan untuk pemilihan backend; dan
• Hash paket yang digunakan untuk pelacakan koneksi, berdasarkan mode pelacakan koneksi, protokol, dan afinitas sesi.

Afinitas sesi	Hash paket untuk pemilihan backend	Hash paket untuk pelacakan koneksi
		Saat menggunakan mode pelacakan PER_CONNECTION (default)	Saat menggunakan mode pelacakan PER_SESSION
NONE (Default) ATAU 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 aktif, hash 5-tuple UDP yang terfragmentasi dan semua protokol lainnya: pelacakan koneksi aktif, hash 3-tuple	TCP dan UDP yang tidak terfragmentasi: pelacakan koneksi aktif, hash 5-tuple UDP yang terfragmentasi dan semua protokol lainnya: pelacakan koneksi aktif, hash 3-tuple
CLIENT_IP_PROTO	Semua protokol: hash 3-tuple	TCP dan UDP yang tidak terfragmentasi: pelacakan koneksi aktif, hash 5-tuple UDP yang terfragmentasi dan semua protokol lainnya: pelacakan koneksi aktif, hash 3-tuple	Semua protokol: pelacakan koneksi aktif, hash 3-tuple
CLIENT_IP	Semua protokol: Hash 2-tuple	TCP dan UDP yang tidak terfragmentasi: pelacakan koneksi aktif, hash 5-tuple UDP yang terfragmentasi dan semua protokol lainnya: pelacakan koneksi aktif, hash 3-tuple	Semua protokol: pelacakan koneksi aktif, hash 2-tuple
CLIENT_IP_NO_DESTINATION	Semua protokol: hash 1-tuple	TCP dan UDP yang tidak terfragmentasi: pelacakan koneksi aktif, hash 5-tuple UDP yang terfragmentasi dan semua protokol lainnya: pelacakan koneksi aktif, hash 3-tuple	Semua protokol: pelacakan koneksi aktif, hash 1-tuple

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

Persistensi koneksi pada backend yang tidak responsif

Persistensi koneksi pada backend yang tidak sehat mengontrol apakah koneksi yang ada tetap ada di VM atau endpoint backend yang dipilih sebelumnya setelah backend menjadi tidak sehat, asalkan backend tetap berada di grup instance atau NEG yang di-load balance.

Opsi persistensi koneksi berikut tersedia:

• DEFAULT_FOR_PROTOCOL (default)
• NEVER_PERSIST
• ALWAYS_PERSIST

Tabel berikut merangkum apakah koneksi tetap ada berdasarkan backend yang tidak sehat, bergantung pada opsi persistensi koneksi, afinitas sesi, mode pelacakan koneksi, dan protokol.

Persistensi koneksi pada backend yang tidak responsif option	Perilaku persistensi koneksi pada backend yang tidak responsif
	Saat menggunakan mode pelacakan PER_CONNECTION (default)	Saat menggunakan mode pelacakan 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 bertahan di backend yang tidak responsif
ALWAYS_PERSIST Opsi ini hanya boleh digunakan untuk kasus penggunaan tingkat lanjut.	TCP, UDP: koneksi tetap ada di backend yang tidak sehat (semua afinitas sesi)	Konfigurasi tidak memungkinkan

Jika persistensi koneksi pada backend yang tidak sehat berlaku untuk traffic, setiap koneksi akan tetap ada selama ada entri tabel pelacakan koneksi yang sesuai. Untuk mengetahui informasi selengkapnya, lihat langkah Mengelola entri tabel pelacakan koneksi.

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

Perilaku persistensi koneksi TCP pada backend yang tidak responsif

Load balancer menggunakan pelacakan koneksi hash 5 tuple untuk koneksi TCP dalam situasi berikut:

• Saat menggunakan mode pelacakan PER_CONNECTION (semua afinitas sesi), atau
• Saat menggunakan mode pelacakan PER_SESSION, dan afinitas sesi adalah NONE atau CLIENT_IP_PORT_PROTO.

Saat load balancer menggunakan pelacakan koneksi hash 5-tuple untuk koneksi TCP, perhatikan perilaku berikut:

• Jika backend yang tidak sehat terus merespons paket, koneksi akan berlanjut hingga direset atau ditutup (oleh backend yang tidak sehat atau klien).
• Jika backend yang tidak sehat mengirim paket reset TCP (RST) atau tidak merespons paket, klien dapat mencoba lagi dengan koneksi baru, sehingga load balancer dapat memilih backend lain yang memenuhi syarat. (Paket TCP SYN diperlakukan sebagai koneksi baru pada langkah Identifikasi backend yang memenuhi syarat.)

Waktu tunggu tidak ada aktivitas

Entri tabel pelacakan koneksi dihapus setelah koneksi tidak aktif selama jangka waktu tertentu. Kecuali jika Anda mengonfigurasi batas waktu tidak ada aktivitas kustom, load balancer akan menggunakan nilai batas waktu tidak ada aktivitas default 600 detik (10 menit).

Tabel berikut menunjukkan nilai waktu tunggu tidak ada aktivitas yang dapat dikonfigurasi minimum dan maksimum untuk berbagai kombinasi setelan afinitas sesi dan mode pelacakan koneksi.

Afinitas sesi	Mode pelacakan koneksi	Waktu tunggu tidak ada aktivitas default	Waktu tunggu tidak ada aktivitas minimum yang dapat dikonfigurasi	Waktu tunggu tidak ada aktivitas maksimum yang dapat dikonfigurasi
Tuple koneksi apa pun	PER_CONNECTION	600 detik	60 detik	600 detik
1-tuple (CLIENT_IP_NO_DESTINATION) 2-tuple (CLIENT_IP) 3-tuple (CLIENT_IP_PROTO)	PER_SESSION	600 detik	60 detik	57.600 detik
5-tuple (NONE, CLIENT_IP_PORT_PROTO)	PER_SESSION	600 detik	60 detik	600 detik

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

Pengosongan koneksi untuk backend yang dihapus, dihentikan, atau dihapus

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

• Instance virtual machine (VM) dihapus dari grup instance backend (termasuk mengabaikan instance dalam grup instance terkelola backend)
• VM dihentikan atau dihapus (termasuk tindakan otomatis seperti update bertahap atau menurunkan skala grup instance terkelola backend)
• Endpoint dihapus dari grup endpoint jaringan (NEG) backend

Secara default, pengosongan koneksi saat backend dihapus, dihentikan, atau dihapus dinonaktifkan. Untuk mengetahui informasi selengkapnya, lihat Mengaktifkan penghentian koneksi.

Failover

Failover memungkinkan Anda memengaruhi kumpulan backend yang memenuhi syarat untuk koneksi baru dengan mengklasifikasikan setiap grup instance backend atau NEG sebagai primer atau failover.

Secara default, saat Anda menambahkan grup instance atau NEG ke layanan backend, VM atau endpoint anggota adalah backend utama, dan grup instance atau NEG adalah grup backend utama. Dengan failover, Anda dapat menambahkan grup backend failover (grup instance atau NEG) yang VM atau endpoint anggotanya adalah backend failover:

• Failover memerlukan layanan backend untuk memiliki setidaknya satu grup backend utama dan setidaknya satu grup backend failover.
• Anda dapat menambahkan hingga 50 grup backend utama dan 50 grup backend failover ke layanan backend.

Dengan failover, faktor berikut menentukan kumpulan backend yang memenuhi syarat:

• Status kondisi setiap backend
• Rasio failover yang telah Anda konfigurasi
• Setelan drop traffic if backends are unhealthy

Kebijakan failover

Jika layanan backend memiliki setidaknya satu grup backend utama dan setidaknya satu grup backend failover, Anda dapat menyesuaikan setelan berikut dalam kebijakan failover:

• Rasio failover: angka antara 0.0 dan 1.0, inklusif.
• Hentikan traffic jika backend tidak responsif: boolean yang menentukan perilaku upaya terakhir load balancer. Setelan rasio failover dan hentikan traffic jika backend tidak responsif bekerja bersama dengan faktor lain untuk mengontrol kumpulan backend yang memenuhi syarat.
• Penghentian koneksi saat failover: boolean yang mengontrol apakah koneksi tetap ada di backend yang dipilih sebelumnya saat kumpulan backend yang memenuhi syarat beralih antara backend primer dan failover.

Rasio failover

Rasio failover yang dikonfigurasi menentukan kapan set backend yang memenuhi syarat beralih antara backend utama dan failover. Rasio dapat berupa angka antara 0.0 hingga 1.0, inklusif. Jika Anda tidak menentukan rasio failover, Google Cloud akan menggunakan nilai default 0.0. Sebaiknya tetapkan rasio failover ke angka yang sesuai untuk kasus penggunaan Anda daripada mengandalkan nilai default ini.

Pengosongan koneksi saat failover

Penghentian koneksi saat failover mengontrol apakah koneksi yang ada tetap ada di VM atau endpoint backend yang dipilih sebelumnya saat setelan backend yang memenuhi syarat beralih antara backend failover dan backend utama.

Pengosongan koneksi saat failover diaktifkan secara default. Tabel berikut merangkum apakah koneksi tetap ada, bergantung pada opsi penghentian koneksi saat failover dan protokol:

Opsi pengosongan koneksi saat failover	Perilaku saat set backend yang memenuhi syarat beralih antara backend utama dan failover
Diaktifkan (default)	Semua protokol: koneksi tetap ada, selama ada entri tabel pelacakan koneksi yang sesuai, saat set backend yang memenuhi syarat beralih antara backend utama dan failover. Untuk mengetahui informasi selengkapnya, lihat langkah Mengelola entri tabel pelacakan koneksi.
Nonaktif	Semua protokol: koneksi tidak tetap ada saat kumpulan backend yang memenuhi syarat beralih antara backend utama dan failover

Menonaktifkan penghentian koneksi saat failover dan failback berguna untuk skenario berikut:

• Melakukan patching pada VM backend. Sebelum melakukan patching, Anda dapat mengonfigurasi backend utama yang responsif agar gagal dalam health check, sehingga backend yang memenuhi syarat dapat menjadi backend failover yang responsif. Dengan menonaktifkan penghentian koneksi saat failover dan failback, load balancer akan menghapus entri tabel pelacakan koneksi, menerapkan langkah pemilihan Backend ke paket berikutnya dan mengirimkannya ke backend lain yang memenuhi syarat. Backend yang berbeda kemudian menutup koneksi dengan reset TCP, sehingga VM klien dapat dengan cepat membuat koneksi baru ke load balancer.

• VM backend tunggal untuk konsistensi data. Jika Anda perlu memastikan bahwa kumpulan backend yang memenuhi syarat tidak memiliki lebih dari satu VM atau endpoint anggota, menonaktifkan penghentian koneksi saat failover dan failback akan mengurangi kemungkinan inkonsistensi data.

Untuk mempelajari cara menonaktifkan pengosongan koneksi saat failover dan failback, lihat Menonaktifkan pengosongan koneksi saat failover dan failback.

Praktik terbaik dan panduan

Anda dapat mengoptimalkan Load Balancer Jaringan passthrough internal dengan mengikuti panduan operasional berikut. Bagian berikut memberikan persyaratan teknis untuk mengelola paket UDP yang terfragmentasi dan praktik terbaik untuk menguji distribusi beban dari satu klien.

Menangani fragmentasi UDP

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

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

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

• Konfigurasi aturan penerusan: Gunakan hanya satu aturan penerusan UDP per alamat IP yang di-load balance, dan konfigurasi 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: Setel 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.

Pengujian dari satu klien

Saat menguji Load Balancer Jaringan passthrough internal dari satu klien, perhatikan hal berikut:

• Jika VM klien bukan backend load balancer: koneksi baru diproses seperti yang dijelaskan dalam langkah-langkah Pemilihan backend dan pelacakan koneksi. Pada langkah Pilih backend yang memenuhi syarat, load balancer membuat hash karakteristik paket sesuai dengan afinitas sesi.

  Ingatlah bahwa semua opsi afinitas sesi mengandalkan setidaknya alamat IP klien, koneksi dari klien yang sama mungkin didistribusikan ke backend yang memenuhi syarat yang sama lebih sering daripada yang Anda harapkan. Akibatnya, Anda tidak dapat memodelkan distribusi keseluruhan koneksi baru secara akurat dengan menghubungkan ke Load Balancer Jaringan passthrough internal dari satu klien.

• Jika VM klien juga merupakan VM backend load balancer: koneksi baru sebenarnya tidak diproses oleh load balancer sama sekali. Paket keluar dengan alamat IP tujuan aturan penerusan load balancer dirutekan secara lokal dalam OS tamu klien karena adanya rute lokal untuk aturan penerusan.

Langkah berikutnya

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