Distribusi traffic untuk Load Balancer Jaringan passthrough eksternal

Halaman ini menjelaskan konsep tentang cara Load Balancer Jaringan passthrough eksternal 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 mencakup 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 sebelumnya dipilih untuk koneksi tersebut.

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

  • Jika paket adalah paket TCP dengan tanda 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 flag 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).

  • Jika afinitas sesi yang dikonfigurasi tidak mendukung pelacakan koneksi untuk protokol paket, lanjutkan ke langkah Identifikasi backend yang memenuhi syarat. Untuk mengetahui informasi tentang protokol mana yang dapat dilacak koneksinya, lihat tabel di bagian Mode pelacakan koneksi.

  • Untuk semua paket lainnya, load balancer memeriksa apakah paket cocok dengan entri tabel pelacakan koneksi yang ada. Tuple koneksi (sekumpulan karakteristik paket) yang digunakan untuk membandingkan paket dengan entri tabel pelacakan koneksi yang ada bergantung pada mode pelacakan koneksi dan afinitas sesi yang Anda konfigurasi. Untuk mengetahui informasi tentang tuple koneksi 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 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 Buat entri tabel pelacakan koneksi.

2. Memilih backend yang memenuhi syarat untuk koneksi baru

Untuk koneksi baru, load balancer menggunakan algoritma 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

Langkah ini memodelkan backend mana yang menjadi kandidat untuk menerima koneksi baru, dengan mempertimbangkan konfigurasi health check, penyeimbangan beban berbobot, dan kebijakan failover.

Tabel berikut menguraikan pengaruh kebijakan failover dan load balancing berbobot terhadap backend yang memenuhi syarat.

Kebijakan failover Load balancing berbobot Backend yang memenuhi syarat
Lihat Tidak ada kebijakan failover, load balancing berbobot dinonaktifkan
Lihat Kebijakan tanpa failover, load balancing berbobot diaktifkan
Lihat Kebijakan failover dikonfigurasi, load balancing berbobot dinonaktifkan
Lihat Kebijakan failover dikonfigurasi, load balancing berbobot diaktifkan

Tidak ada kebijakan failover, load balancing berbobot dinonaktifkan

Kumpulan backend yang memenuhi syarat hanya bergantung pada health check:

  • Jika setidaknya ada 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.

Tidak ada kebijakan failover, load balancing berbobot diaktifkan

Kumpulan backend yang memenuhi syarat bergantung pada health check dan bobot, serta terdiri dari yang pertama dari berikut ini yang tidak kosong:

  • Semua backend yang responsif dan memiliki bobot tidak nol
  • Semua backend yang tidak responsif dan memiliki bobot bukan nol
  • Semua backend responsif, dengan bobot nol
  • Semua backend tidak responsif, backend dengan bobot nol

Kebijakan failover dikonfigurasi, load balancing berbobot dinonaktifkan

Kumpulan backend yang memenuhi syarat bergantung pada konfigurasi kebijakan failover dan health check:

  • Jika setidaknya satu backend dalam kondisi baik, kumpulan backend yang memenuhi syarat ditentukan sebagai berikut, menggunakan kondisi pertama yang benar dari daftar berurutan ini:

    • 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, kumpulan backend yang memenuhi syarat ditentukan sebagai berikut:

    • Jika kebijakan failover load balancer dikonfigurasi untuk memutus koneksi baru saat tidak ada backend yang responsif, set backend yang memenuhi syarat akan kosong. Load balancer akan membuang paket untuk koneksi baru.
    • Jika kebijakan failover load balancer tidak dikonfigurasi untuk memutus koneksi baru saat tidak ada backend yang responsif, health check tidak relevan. Backend yang memenuhi syarat terdiri dari semua backend utama.

Kebijakan failover dikonfigurasi, load balancing berbobot diaktifkan

Kumpulan backend yang memenuhi syarat bergantung pada health check, bobot, dan konfigurasi kebijakan failover:

  • Jika setidaknya satu backend dalam kondisi baik dan memiliki bobot bukan nol, kumpulan backend yang memenuhi syarat ditentukan sebagai berikut, menggunakan kondisi pertama yang benar dari daftar berurutan ini:

    • Jika tidak ada backend utama yang responsif dan memiliki bobot bukan nol, backend yang memenuhi syarat adalah semua backend failover yang responsif dan memiliki bobot bukan nol.
    • Jika tidak ada backend failover yang responsif dan memiliki bobot bukan nol, backend yang memenuhi syarat adalah semua backend utama yang responsif dan memiliki bobot bukan nol.
    • Jika rasio failover ditetapkan ke 0.0 (nilai default), backend yang memenuhi syarat adalah semua backend utama yang responsif dan memiliki bobot bukan nol.
    • Jika rasio jumlah backend utama yang responsif dan memiliki bobot bukan nol 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 dan memiliki bobot bukan nol.
    • Backend yang memenuhi syarat terdiri dari semua backend failover dengan bobot non-nol yang responsif.

  • Jika tidak ada backend yang responsif dan memiliki bobot bukan nol, kumpulan backend yang memenuhi syarat ditentukan sebagai berikut:

    • Jika kebijakan failover load balancer dikonfigurasi untuk memutus koneksi baru saat tidak ada backend yang responsif, set backend yang memenuhi syarat akan kosong. Load balancer akan membuang paket untuk koneksi baru.

    • Jika kebijakan failover load balancer tidak dikonfigurasi untuk memutus koneksi baru saat tidak ada backend yang responsif, kumpulan backend yang memenuhi syarat adalah yang pertama dari berikut ini yang tidak kosong:

      • Semua backend utama yang tidak responsif dan memiliki bobot bukan nol
      • Semua backend failover yang tidak responsif dan memiliki bobot bukan nol
      • Semua backend utama yang responsif dengan bobot nol
      • Semua backend failover berat nol responsif
      • Semua backend utama tidak responsif dan memiliki bobot nol
      • Semua backend tidak responsif, nol backend pengganti

2.2 Pilih backend yang memenuhi syarat

Load balancer menggunakan hashing yang konsisten untuk memilih backend yang memenuhi syarat. Load balancer mempertahankan hash backend yang memenuhi syarat, yang dipetakan ke lingkaran satuan. Penyeimbangan beban tertimbang mengubah cara pemetaan backend yang memenuhi syarat ke lingkaran sehingga backend dengan bobot yang lebih tinggi lebih mungkin dipilih, secara proporsional dengan bobotnya.

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.

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

  • Dua contoh berikut menunjukkan cara load balancing berbobot memengaruhi pemilihan backend yang memenuhi syarat:

    • Jika layanan backend memiliki dua backend yang memenuhi syarat—yang pertama memiliki bobot 1 dan yang kedua memiliki bobot 4—backend pertama yang memenuhi syarat memiliki probabilitas pemilihan 20% (1÷(1+4)), dan backend kedua yang memenuhi syarat memiliki probabilitas pemilihan 80% (4÷(1+4)).

    • Jika layanan backend memiliki tiga backend yang memenuhi syarat—backend a yang memenuhi syarat dengan bobot 0, backend b yang memenuhi syarat dengan bobot 2, dan backend c yang memenuhi syarat dengan bobot 6—backend a memiliki probabilitas pemilihan 0% (0÷(0+2+6)), backend b memiliki probabilitas pemilihan 25% (2÷(0+2+6)), dan backend c memiliki probabilitas pemilihan 75% (6÷(0+2+6)).

  • Load balancer menetapkan koneksi baru ke backend yang memenuhi syarat dengan cara yang sekonsisten mungkin meskipun jumlah backend yang memenuhi syarat atau bobotnya berubah. Manfaat hashing yang 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, dalam situasi berikut:

      • Jika load balancing berbobot tidak dikonfigurasi, saat set backend yang memenuhi syarat tidak berubah.

      • Jika load balancing berbobot dikonfigurasi, saat set backend yang memenuhi syarat tidak berubah, dan bobot setiap backend yang memenuhi syarat tetap konstan.

    • Load balancer mendistribusikan kemungkinan koneksi baru di antara backend yang memenuhi syarat seadil mungkin:

      • Jika load balancing berbobot tidak dikonfigurasi, sekitar 1/N kemungkinan koneksi baru dipetakan ke setiap backend yang memenuhi syarat, dengan N adalah jumlah backend yang memenuhi syarat.

      • Jika load balancing berbobot dikonfigurasi, rasio kemungkinan koneksi baru yang dipetakan ke setiap backend yang memenuhi syarat adalah sekitar: bobot backend yang memenuhi syarat dibagi dengan jumlah semua bobot backend yang memenuhi syarat.

      • Jika backend yang memenuhi syarat ditambahkan, dihapus, atau bobotnya diubah, 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.

2.3 Membuat entri tabel pelacakan koneksi

Setelah memilih backend, load balancer akan membuat entri tabel pelacakan koneksi jika afinitas sesi yang dikonfigurasi mendukung pelacakan koneksi untuk protokol paket.

  • Jika afinitas sesi yang dikonfigurasi tidak mendukung pelacakan koneksi untuk protokol paket, lewati langkah ini.

  • Jika afinitas sesi yang dikonfigurasi mendukung pelacakan koneksi untuk protokol paket, entri tabel pelacakan koneksi yang dibuat 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.

Untuk mengetahui informasi tentang protokol mana yang dapat dilacak koneksinya berdasarkan pilihan konfigurasi Anda, dan karakteristik paket apa yang digunakan untuk hash, lihat bagian Mode pelacakan koneksi.

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

  • Entri tabel pelacakan koneksi dihapus setelah koneksi tidak aktif selama 60 detik. Untuk mengetahui 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 tanda SYN dan diproses seperti yang dijelaskan dalam langkah Periksa entri tabel pelacakan koneksi.

  • Jika kebijakan failover dikonfigurasi dan setelan penghentian koneksi saat failover dan failback dinonaktifkan, load balancer akan menghapus semua entri dalam tabel pelacakan koneksi saat backend yang memenuhi syarat beralih dari backend utama ke backend failover (failover), atau beralih dari backend failover ke backend utama (failback). Untuk mengetahui informasi selengkapnya, lihat Penghentian koneksi saat failover dan failback.

  • Entri dalam tabel pelacakan koneksi dapat dihapus jika backend menjadi tidak sehat. Perilaku ini bergantung pada mode pelacakan koneksi, protokol, dan setelan persistensi koneksi pada 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 mengetahui informasi selengkapnya, lihat Mengaktifkan pengurasan koneksi.

Afinitas sesi

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

Load Balancer Jaringan passthrough eksternal mendukung setelan afinitas sesi berikut. Setiap setelan afinitas sesi menggunakan hashing yang konsisten untuk memilih backend yang memenuhi syarat. Setelan afinitas sesi menentukan kolom mana dari header IP dan header TCP/UDP yang digunakan untuk menghitung hash.

Metode hash untuk pemilihan backend Setelan afinitas sesi1

Hash 5 tuple (terdiri dari alamat IP sumber, port sumber, protokol, alamat IP tujuan, dan port tujuan) untuk paket yang tidak terfragmentasi yang mencakup 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 semua protokol lainnya

 NONE2

Hash 5 tuple (terdiri dari alamat IP sumber, port sumber, protokol, alamat IP tujuan, dan port tujuan) untuk paket yang tidak terfragmentasi yang mencakup 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 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
1 Afinitas sesi ini didukung oleh Load Balancer Jaringan passthrough eksternal berbasis layanan backend. Load Balancer Jaringan passthrough eksternal berbasis kumpulan target tidak menggunakan layanan backend, dan mendukung lebih sedikit opsi afinitas sesi. Untuk Load Balancer Jaringan passthrough eksternal berbasis kumpulan target, Anda menetapkan parameter session affinity di setiap kumpulan target.

2 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, perilaku yang sama seperti saat CLIENT_IP_PORT_PROTO disetel.

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

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 koneksi

Jika pelacakan koneksi memungkinkan, tabel pelacakan koneksi load balancer memetakan tuple koneksi ke backend yang sebelumnya dipilih dalam tabel hash. Kumpulan karakteristik paket yang membentuk setiap tuple koneksi bergantung pada mode pelacakan koneksi dan afinitas sesi.

Load Balancer Jaringan passthrough eksternal mendukung pelacakan koneksi berdasarkan protokol dan opsi afinitas sesi:

  • Koneksi TCP selalu dapat dilacak koneksinya, untuk semua opsi afinitas sesi.

  • Koneksi UDP, ESP, dan GRE dapat dilacak koneksinya untuk semua opsi afinitas sesi kecuali untuk NONE.

  • Semua protokol lainnya, seperti ICMP dan ICMPv6, tidak dapat dilacak koneksinya.

Mode pelacakan koneksi mengacu pada 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 kerja mode pelacakan koneksi dan afinitas sesi bersama-sama 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
Default

(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 dinonaktifkan
  • TCP: Pelacakan koneksi 5-tuple
  • Semua protokol lainnya: pelacakan koneksi dinonaktifkan
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 dinonaktifkan
  • TCP, UDP, ESP, GRE: Pelacakan koneksi 2-tuple
  • Semua protokol lainnya: pelacakan koneksi dinonaktifkan
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 dinonaktifkan
  • TCP, UDP, ESP, GRE: Pelacakan koneksi 3-tuple
  • Semua protokol lainnya: pelacakan koneksi dinonaktifkan
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 dinonaktifkan
  • 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 dinonaktifkan

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

Persistensi koneksi pada 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 di 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.

Persistensi koneksi pada backend yang tidak responsif option Mode pelacakan koneksi
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 bertahan 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 tidak NONE

ICMP, ICMPv6: tidak berlaku karena tidak dapat dilacak koneksinya

Opsi ini hanya boleh digunakan untuk kasus penggunaan tingkat lanjut.

 Konfigurasi tidak memungkinkan

Perilaku persistensi koneksi TCP pada backend yang tidak responsif

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

  • 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 mungkin akan mencoba lagi dengan koneksi baru, sehingga load balancer dapat memilih backend lain yang sehat. Paket TCP SYN selalu memilih backend baru yang berfungsi dengan baik.

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

Waktu tunggu tidak ada aktivitas

Entri dalam tabel pelacakan koneksi akan berakhir 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

Load balancing berbobot untuk Load Balancer Jaringan passthrough eksternal menggunakan informasi bobot yang dilaporkan oleh pemeriksaan kondisi HTTP. Load balancing berbobot mengharuskan Anda mengonfigurasi semua hal berikut:

  • Kebijakan lokalitas load balancer layanan backend (localityLbPolicy) harus WEIGHTED_MAGLEV.
  • Layanan backend harus menggunakan health check HTTP.
  • Respons health check dari setiap VM backend atau endpoint backend harus berisi header respons HTTP kustom. Nama kolom header respons adalah X-Load-Balancing-Endpoint-Weight, dan nilai kolom yang valid berkisar dari 0 hingga 1000.

Jika Anda perlu menggunakan grup instance atau NEG yang sama sebagai backend untuk dua atau beberapa layanan backend, sebaiknya gunakan strategi berikut agar setiap instance atau endpoint backend umum dapat memberikan informasi bobot unik untuk setiap layanan backend:

  • Gunakan health check HTTP unik untuk setiap layanan backend. Misalnya, gunakan parameter health check request-path yang unik.
  • Konfigurasi instance atau endpoint backend untuk merespons dengan informasi bobot yang sesuai untuk setiap health check.

Saat menggunakan load balancing berbobot, load balancer memberi peringkat pada VM atau endpoint backend, pertama berdasarkan bobot yang lebih besar dari nol atau sama dengan nol, lalu berdasarkan health check. Status health check ditentukan oleh kriteria keberhasilan untuk health check HTTP, HTTPS, dan HTTP/2.

Bobot Sehat atau tidak sehat Peringkat
Berat lebih besar dari nol Responsif Pilihan pertama
Berat lebih besar dari nol Tidak responsif Pilihan kedua
Berat sama dengan nol Responsif Pilihan ketiga
Berat sama dengan nol Tidak responsif Pilihan keempat (terakhir)

Untuk mengetahui informasi selengkapnya tentang pengaruh load balancing berbobot terhadap backend yang memenuhi syarat, lihat langkah-langkah Identifikasi backend yang memenuhi syarat dan Pilih backend yang memenuhi syarat di bagian Pemilihan backend dan pelacakan koneksi.

Load balancing berbobot dapat digunakan dalam skenario berikut:

  • Jika beberapa koneksi memproses lebih banyak data daripada koneksi lainnya, atau beberapa koneksi berlangsung lebih lama daripada koneksi lainnya, distribusi beban backend mungkin menjadi tidak merata. Dengan menandakan bobot per instance yang lebih rendah, instance dengan beban tinggi dapat mengurangi bagiannya dari koneksi baru, sambil terus melayani koneksi yang ada.

  • Jika backend kelebihan beban dan menetapkan lebih banyak koneksi dapat merusak koneksi yang ada, backend tersebut 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 menghentikan koneksi yang ada sebelum pemeliharaan, backend akan menetapkan bobot nol untuk dirinya sendiri. Dengan menandakan bobot nol, instance backend berhenti melayani koneksi baru, tetapi terus melayani koneksi yang ada.

Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi load balancing berbobot.

Pengosongan koneksi

Pengosongan koneksi memberikan waktu tambahan yang dapat dikonfigurasi agar koneksi yang sudah 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 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, pengurasan koneksi untuk tindakan yang disebutkan di atas dinonaktifkan. Untuk mengetahui informasi tentang cara pemicuan pengurasan koneksi dan cara mengaktifkan pengurasan koneksi, lihat Mengaktifkan pengurasan 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 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 atau L3_DEFAULT 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.

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, ke penggunaan backend failover. Pengalihan adalah metode lain untuk meningkatkan ketersediaan, sekaligus memberi Anda kontrol yang lebih besar tentang cara mengelola workload saat backend utama Anda tidak dalam kondisi baik.

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 informasi selengkapnya tentang cara failover digunakan untuk pemilihan backend dan pelacakan koneksi, lihat langkah-langkah Identifikasi backend yang memenuhi syarat dan Buat entri tabel pelacakan koneksi di bagian Pemilihan backend dan pelacakan koneksi.

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

Langkah berikutnya