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 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 dan apakah penyeimbangan beban berbobot diaktifkan.

Kebijakan failover Load balancing berbobot Backend yang memenuhi syarat

Jika tidak ada kebijakan failover yang dikonfigurasi dan load balancing berbobot dinonaktifkan, semua backend yang dikonfigurasi adalah backend utama. Kumpulan backend yang memenuhi syarat ditentukan 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 tidak ada kebijakan failover yang dikonfigurasi dan load balancing berbobot diaktifkan, backend yang memenuhi syarat adalah backend yang berasal dari set pertama berikut yang tidak kosong:

  • Semua backend responsif dengan bobot bukan nol
  • Semua backend yang tidak responsif dengan bobot bukan nol
  • Semua backend responsif dengan bobot nol
  • Semua backend tidak responsif dengan bobot nol

Jika kebijakan failover dikonfigurasi dan load balancing berbobot dinonaktifkan, 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 set pertama berikut yang tidak kosong:
    1. Jika tidak ada backend utama yang responsif, backend yang memenuhi syarat adalah semua backend failover yang responsif.
    2. Jika tidak ada backend failover yang responsif, backend yang memenuhi syarat adalah semua backend utama yang responsif.
    3. Jika rasio failover ditetapkan ke 0.0 (nilai default), backend yang memenuhi syarat adalah semua backend utama yang responsif.
    4. 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.
    5. 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.

Jika kebijakan failover dikonfigurasi dan load balancing berbobot diaktifkan, load balancer akan menggunakan informasi bobot, informasi health check, dan konfigurasi kebijakan failover untuk menentukan kumpulan backend yang memenuhi syarat:

  • Jika setidaknya ada satu backend dengan bobot bukan nol (primer atau failover) yang berstatus responsif, backend yang memenuhi syarat adalah backend yang berasal dari kumpulan pertama berikut yang tidak kosong:
    1. Jika set backend utama yang responsif dengan bobot bukan nol kosong, backend yang memenuhi syarat adalah semua backend failover yang responsif dengan bobot bukan nol.
    2. Jika set backend failover responsif dengan bobot bukan nol kosong, backend yang memenuhi syarat adalah semua backend utama responsif dengan bobot bukan nol.
    3. Jika rasio failover ditetapkan ke 0.0 (nilai default), backend yang memenuhi syarat adalah semua backend utama yang responsif dengan bobot bukan nol.
    4. Jika rasio jumlah backend utama yang responsif dengan 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 dengan bobot bukan nol.
    5. Backend yang memenuhi syarat terdiri dari semua backend failover yang responsif dengan bobot bukan nol.
  • Jika tidak ada backend yang responsif dan memiliki bobot bukan nol (backend utama dan failover), set backend yang memenuhi syarat bergantung pada konfigurasi kebijakan failover:
    • Jika kebijakan failover dikonfigurasi untuk memutus koneksi baru jika tidak ada backend failover dan backend utama yang responsif dengan bobot bukan nol, set backend yang memenuhi syarat akan kosong. Akibatnya, load balancer akan membuang paket untuk koneksi baru.
    • Jika kebijakan failover tidak dikonfigurasi untuk menghentikan koneksi baru saat tidak ada backend failover dan primer yang responsif dengan bobot bukan nol, backend yang memenuhi syarat adalah backend yang berasal dari set pertama berikut yang tidak kosong:
      1. Semua backend utama yang tidak responsif dengan bobot bukan nol
      2. Semua backend failover yang tidak responsif dengan bobot bukan nol
      3. Semua backend utama yang responsif dengan bobot nol
      4. Semua backend failover responsif dengan bobot nol
      5. Semua backend utama yang tidak responsif dengan bobot nol
      6. Semua backend failover yang tidak responsif dengan bobot nol

2.2 Pilih backend yang memenuhi syarat

Load balancer mempertahankan hash backend yang memenuhi syarat, dengan setiap hash backend dipetakan ke lingkaran satuan. Penyeimbangan beban tertimbang mengubah cara backend yang memenuhi syarat dipetakan 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. 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 atau bobotnya 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, 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.

    • 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 memenuhi syarat yang sama.

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

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

    • Jika load balancing berbobot dikonfigurasi, rasio kemungkinan hash paket yang dipetakan ke setiap backend yang memenuhi syarat adalah kira-kira: bobot backend yang memenuhi syarat dibagi dengan jumlah semua bobot backend yang memenuhi syarat.

  • Dua contoh berikut menunjukkan pengaruh load balancing berbobot terhadap probabilitas pemilihan setiap 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)).

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 dalam tabel pelacakan koneksi, lihat tabel di bagian Mode pelacakan koneksi.

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 selama 60 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 eksternal 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 eksternal 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

 NONE1
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

Afinitas sesi 1 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.

Kebijakan pelacakan koneksi

Bagian ini menjelaskan setelan dalam kebijakan pelacakan koneksi load balancer:

Mode pelacakan koneksi

Bagian ini menjelaskan kapan dan bagaimana load balancer membuat entri dalam tabel pelacakan koneksinya. Load Balancer Jaringan passthrough eksternal mendukung pelacakan koneksi berdasarkan protokol dan 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 NONE.

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

Jika pelacakan koneksi memungkinkan, mode pelacakan koneksi, protokol, dan afinitas sesi akan 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)
  • TCP dan UDP yang tidak terfragmentasi: hash 5-tuple
  • UDP yang terfragmentasi dan semua protokol lainnya: Hash 3-tuple
  • TCP: pelacakan koneksi aktif, hash 5-tuple
  • Semua protokol lainnya: pelacakan koneksi dinonaktifkan
  • TCP: pelacakan koneksi aktif, hash 5-tuple
  • Semua protokol lainnya: pelacakan koneksi dinonaktifkan
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, ESP, dan GRE yang terfragmentasi: pelacakan koneksi aktif, hash 3-tuple
  • Semua protokol lainnya: pelacakan koneksi dinonaktifkan
  • TCP dan UDP yang tidak terfragmentasi: pelacakan koneksi aktif, hash 5-tuple
  • UDP, ESP, dan GRE yang terfragmentasi: pelacakan koneksi aktif, hash 3-tuple
  • Semua protokol lainnya: pelacakan koneksi dinonaktifkan
CLIENT_IP_PROTO
  • Semua protokol: hash 3-tuple
  • TCP dan UDP yang tidak terfragmentasi: pelacakan koneksi aktif, hash 5-tuple
  • UDP, ESP, dan GRE yang terfragmentasi: pelacakan koneksi aktif, hash 3-tuple
  • Semua protokol lainnya: pelacakan koneksi dinonaktifkan
  • TCP, UDP, ESP, GRE: pelacakan koneksi aktif, hash 3-tuple
  • Semua protokol lainnya: pelacakan koneksi dinonaktifkan
CLIENT_IP
  • Semua protokol: Hash 2-tuple
  • TCP dan UDP yang tidak terfragmentasi: pelacakan koneksi aktif, hash 5-tuple
  • UDP, ESP, dan GRE yang terfragmentasi: pelacakan koneksi aktif, hash 3-tuple
  • Semua protokol lainnya: pelacakan koneksi dinonaktifkan
  • TCP, UDP, ESP, GRE: pelacakan koneksi aktif, hash 2-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

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: 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
  • Semua protokol lainnya: tidak berlaku karena tidak dapat dilacak koneksinya
 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 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.

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.

Load balancing berbobot

Load balancing berbobot memengaruhi backend yang memenuhi syarat di Langkah pemilihan backend. Setiap VM atau endpoint backend melaporkan bobotnya ke load balancer menggunakan pemeriksaan kondisi HTTP dan header respons kustom. Untuk menggunakan load balancing berbobot, Anda harus mengonfigurasi hal berikut pada layanan backend load balancer:

  • Kebijakan lokalitas (localityLbPolicy) harus ditetapkan ke WEIGHTED_MAGLEV.

  • Health check harus berupa health check HTTP yang mengirimkan header respons khusus:

    • Nama kolom header respons harus berupa X-Load-Balancing-Endpoint-Weight.
    • Nilai kolom header respons dapat berkisar dari 0 hingga 1000, inklusif.

Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi load balancing berbobot.

Pertimbangan untuk load balancing berbobot

Load balancing berbobot berguna dalam skenario berikut, yang memungkinkan backend terus memproses koneksi yang ada:

  • Penyeimbangan beban berbobot memungkinkan backend yang memproses koneksi yang berjalan lama atau koneksi yang melibatkan sejumlah besar data untuk memberi tahu load balancer agar mengurangi jumlah koneksi baru yang diterimanya.

  • Load balancing berbobot memungkinkan backend yang kelebihan muatan atau sedang dalam pemeliharaan untuk menghapus dirinya sendiri dari backend yang memenuhi syarat untuk koneksi baru. Untuk melakukannya, backend yang kelebihan beban mengirimkan header respons X-Load-Balancing-Endpoint-Weight: 0 (dan dapat terus lulus atau gagal dalam health check load balancer). Hal ini berfungsi karena semua backend dengan bobot tidak nol (terlepas dari status health check) adalah backend yang lebih disukai dan memenuhi syarat dalam langkah Identifikasi backend yang memenuhi syarat.

Perhatikan hal-hal berikut saat menggunakan load balancing:

  • Jika backend yang memenuhi syarat sering mengubah bobotnya, penyeimbangan beban berbobot dapat merugikan afinitas sesi. Untuk mengetahui informasi selengkapnya, lihat langkah Pilih backend yang memenuhi syarat.

  • Jika Anda menggunakan grup instance atau NEG yang sama sebagai backend dari dua atau lebih layanan backend load balancer, Anda dapat melaporkan bobot unik untuk setiap layanan backend menggunakan strategi berikut:

    • Gunakan health check HTTP unik untuk setiap layanan backend. Setiap health check dapat menggunakan parameter request-path atau port tujuan yang unik.

    • Konfigurasi instance atau endpoint backend untuk merespons dengan informasi bobot yang sesuai untuk setiap health check.

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
  • Apakah Anda menggunakan failover dengan sendirinya atau bersama dengan load balancing berbobot

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)
  • Protokol yang dapat dilacak koneksinya: 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.
  • Koneksi protokol yang tidak dapat dilacak koneksinya: tidak bertahan saat set backend yang memenuhi syarat beralih antara backend utama dan failover.

Untuk mengetahui informasi tentang protokol mana yang dapat dilacak koneksinya, lihat tabel di bagian Mode 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 dengan bobot bukan nol agar gagal dalam health check, atau Anda dapat menyetel bobotnya ke nol. Dengan cara ini, backend yang memenuhi syarat dapat menjadi backend failover yang responsif dengan bobot bukan nol. 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 eksternal 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 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.

Pengujian dari satu klien

Saat menguji Load Balancer Jaringan passthrough eksternal 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 eksternal 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