Distribusi traffic untuk Load Balancer Jaringan passthrough eksternal regional

Load Balancer Jaringan Passthrough mendistribusikan traffic masuk ke seluruh backend instance yang tersedia. Dokumen ini menjelaskan cara load balancer memilih backend, melacak koneksi, dan mengelola afinitas sesi, load balancing berbobot, dan failover.

Memahami cara kerja semua fitur ini secara bersamaan akan membantu Anda mengoptimalkan konfigurasi load balancing untuk performa yang andal dan pemanfaatan resource yang efisien. Mekanisme ini sangat penting untuk aplikasi yang memerlukan persistensi sesi, sehingga aplikasi dapat mempertahankan perilaku yang konsisten untuk setiap interaksi pengguna.

Pemilihan backend dan pelacakan koneksi

Pemilihan backend dan pelacakan koneksi bekerja sama untuk menyeimbangkan beberapa koneksi di berbagai backend dan merutekan semua paket untuk setiap koneksi ke backend yang sama. Hal ini dilakukan dengan strategi yang terdiri dari 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. Memeriksa entri tabel pelacakan koneksi

Load balancer menentukan apakah paket yang di-load balanced termasuk dalam koneksi baru atau koneksi yang sudah ada dengan 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 flag SYN selalu mewakili koneksi baru, terlepas dari afinitas sesi yang dikonfigurasi.

    • Jika mode pelacakan koneksi load balancer adalah PER_SESSION dan afinitas sesi adalah NONE atau CLIENT_IP_PORT_PROTO, lanjutkan ke langkah Identifikasi backend yang memenuhi syarat. Dalam mode pelacakan PER_SESSION, paket TCP dengan flag SYN mewakili koneksi baru hanya saat menggunakan salah satu opsi afinitas sesi 5-tuple (NONE atau CLIENT_IP_PORT_PROTO).

  • 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 load balancer menggunakan failover dan apakah load balancing berbobot diaktifkan.

Failover Load balancing berbobot Backend yang memenuhi syarat

Jika fitur failover dan load balancing berbobot dinonaktifkan, semua backend yang dikonfigurasi adalah backend utama. Kumpulan backend yang memenuhi syarat ditentukan sebagai berikut:

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

Jika fitur load balancing failover dinonaktifkan, dan fitur 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 tidak responsif dengan bobot bukan nol
  • Semua backend responsif dengan bobot nol
  • Semua backend tidak responsif dengan bobot nol

Jika fitur load balancing failover diaktifkan, dan fitur 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 (utama 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 berfungsi dengan baik.
    4. Jika rasio jumlah backend utama yang responsif dibandingkan dengan total jumlah 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, kumpulan backend yang memenuhi syarat akan kosong. Akibatnya, load balancer menghapus 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 fitur failover 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 satu backend dengan bobot bukan nol (utama atau failover) responsif, backend yang memenuhi syarat adalah backend yang berasal dari set 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 kumpulan 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 dan berbobot 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 responsif dengan bobot bukan nol.
  • Jika tidak ada backend responsif dengan bobot bukan nol (utama dan failover), set backend yang memenuhi syarat bergantung pada konfigurasi kebijakan failover:
    • Jika kebijakan failover dikonfigurasi untuk menghentikan koneksi baru saat tidak ada backend utama dan failover yang responsif dan berbobot 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 utama dan failover yang responsif dan berbobot 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 tidak responsif dengan bobot bukan nol
      3. Semua backend utama yang sehat 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 tidak responsif dengan bobot nol

2.2 Memilih 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 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 unit 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 akan dipetakan ke backend yang sama yang 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 memenuhi syarat yang sama untuk koneksi, dan secara umum, selalu memilih backend yang memenuhi syarat yang sama 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 akan 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 sekitar: 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 kombinasi protokol dan afinitas sesi tidak mendukung pelacakan koneksi, lewati langkah ini.

  • Jika afinitas sesi yang dikonfigurasi mendukung pelacakan koneksi untuk protokol paket, entri tabel pelacakan koneksi yang dibuat akan 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 koneksinya dapat dilacak 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, jika kombinasi protokol dan afinitas sesi mendukung pelacakan koneksi, sesuai dengan peristiwa dan aturan berikut:

  • Entri tidak ada aktivitas dihapus: entri tabel pelacakan koneksi dihapus setelah 60 detik jika tidak ada paket ingress baru yang diproses oleh Maglev. 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 akan dihapus nanti sebagai entri tidak ada aktivitas. Setiap koneksi TCP baru selalu membawa flag SYN, dan tunduk pada pemrosesan yang dijelaskan dalam langkah Memeriksa entri tabel pelacakan koneksi.

  • Saat koneksi tidak tetap pada failover: saat setidaknya satu backend failover dikonfigurasi dan setelan pengurasan koneksi pada failover dinonaktifkan, load balancer akan menghapus semua entri dalam tabel pelacakan koneksi setelah kumpulan backend yang memenuhi syarat beralih antara backend primer dan failover, dengan tunduk pada aturan berikut:

    • Load balancer tidak menghapus entri tabel pelacakan koneksi secara proaktif pada saat set backend yang memenuhi syarat beralih antara backend utama dan failover. Sebagai gantinya, load balancer akan menghapus setiap entri tabel pelacakan koneksi saat paket berikutnya untuk koneksi tiba, asalkan set backend yang memenuhi syarat belum beralih kembali.

    • Jika kumpulan backend yang memenuhi syarat beralih antara backend utama dan backend failover, lalu kembali lagi (misalnya, dari utama ke failover, lalu kembali ke utama), dan tidak ada paket untuk koneksi yang tiba di antara peristiwa peralihan, entri tabel pelacakan koneksi akan dipertahankan, kecuali jika ada alasan atau peristiwa lain yang menghapus entri tabel pelacakan koneksi.

    Untuk mengetahui informasi selengkapnya, lihat Pengosongan koneksi saat terjadi failover.

  • Jika koneksi tidak dipertahankan di backend yang tidak responsif: jika persistensi koneksi di backend yang tidak responsif dinonaktifkan untuk protokol paket, load balancer akan menghapus entri tabel pelacakan koneksi di backend yang tidak responsif sesuai dengan aturan berikut:

    • Load balancer tidak secara proaktif menghapus entri tabel pelacakan koneksi ke backend yang dipilih sebelumnya pada saat backend menjadi tidak sehat. Sebagai gantinya, load balancer akan menghapus entri tabel pelacakan koneksi saat paket berikutnya untuk koneksi tersebut tiba, asalkan backend yang dipilih sebelumnya tetap tidak responsif. Paket berikutnya untuk koneksi diperlakukan sebagai koneksi baru, karena load balancer memilih backend baru yang memenuhi syarat dan membuat entri tabel pelacakan koneksi baru.

    • Jika backend yang dipilih sebelumnya berubah dari responsif menjadi tidak responsif, lalu kembali responsif, dan tidak ada paket untuk koneksi yang tiba saat backend yang dipilih sebelumnya tidak responsif, entri tabel pelacakan koneksi akan dipertahankan, kecuali jika ada alasan atau peristiwa lain yang menghapus entri tabel pelacakan koneksi.

  • 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 (mengabaikan), menghentikan, atau menghapus backend diterima (termasuk perintah penghapusan yang merupakan hasil dari perkecil skala grup instance terkelola). Jika pengosongan 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 mengetahui informasi selengkapnya, lihat Mengaktifkan pengosongan koneksi.

Afinitas sesi

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

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

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

1 Afinitas sesi NONE tidak menunjukkan bahwa tidak ada afinitas sesi. Sebaliknya, hal ini berarti 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 regional 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 untuk NONE. Untuk afinitas sesi NONE, protokol ini tidak dapat dilacak koneksinya.

  • Semua protokol lainnya, seperti ICMP dan ICMPv6, tidak dapat dilacak koneksinya, untuk semua opsi afinitas sesi.

Jika pelacakan koneksi memungkinkan, mode pelacakan koneksi, protokol, dan afinitas sesi menentukan kumpulan 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 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 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. Hal ini mengurangi frekuensi koneksi yang 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 terfragmentasi dan semua protokol lainnya: Hash 3 tuple
  • TCP: pelacakan koneksi aktif, hash 5-tuple
  • Semua protokol lainnya: pelacakan koneksi nonaktif
  • 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 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 nonaktif
  • TCP, UDP, ESP, GRE: pelacakan koneksi aktif, hash 3-tuple
  • Semua protokol lainnya: pelacakan koneksi nonaktif
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 pelacakan koneksi, lihat Mengonfigurasi kebijakan pelacakan koneksi.

Persistensi koneksi pada backend yang tidak responsif

Persistensi koneksi pada backend yang tidak responsif mengontrol apakah koneksi yang ada dapat dipertahankan pada VM backend yang dipilih sebelumnya jika VM yang dipilih sebelumnya menjadi tidak responsif. Persistensi koneksi pada backend yang tidak responsif mengharuskan backend VM tetap menjadi anggota grup instance atau NEG yang di-load balanced, dan kombinasi protokol serta afinitas sesi mendukung pelacakan koneksi.

Tersedia opsi persistensi koneksi berikut:

  • DEFAULT_FOR_PROTOCOL (default)
  • NEVER_PERSIST
  • ALWAYS_PERSIST

Tabel berikut menjelaskan perilaku persistensi koneksi pada backend yang tidak responsif, bergantung pada opsi persistensi koneksi pada backend yang tidak responsif, mode pelacakan koneksi, afinitas sesi, dan protokol.

Opsi persistensi koneksi pada backend yang tidak responsif 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 (semua afinitas sesi): koneksi tetap ada di backend yang tidak sehat, tunduk pada peristiwa dan aturan lain dalam langkah entri tabel pelacakan koneksi yang dikelola
  • Semua protokol lainnya: koneksi tidak bertahan di backend yang tidak responsif
  • TCP (afinitas sesi NONE dan CLIENT_IP_PORT_PROTO): koneksi tetap ada di backend yang tidak sehat, tunduk pada peristiwa dan aturan lain dalam langkah mengelola entri tabel pelacakan koneksi
  • TCP (semua afinitas sesi lainnya) dan semua protokol lainnya: koneksi tidak dipertahankan di backend yang tidak responsif
NEVER_PERSIST Semua protokol: koneksi tidak bertahan di backend yang tidak responsif
ALWAYS_PERSIST

Opsi ini hanya boleh digunakan untuk kasus penggunaan lanjutan.
  • TCP (semua afinitas sesi); ESP, GRE, UDP (semua afinitas sesi kecuali NONE): koneksi tetap ada di backend yang tidak responsif, tunduk pada peristiwa dan aturan lain dalam langkah Mengelola entri tabel pelacakan koneksi
  • ESP, GRE, UDP (afinitas sesi NONE): tidak berlaku karena tidak dapat dilacak koneksinya
 Konfigurasi tidak memungkinkan

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 responsif mengirimkan 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 untuk koneksi yang ada agar tetap ada dalam 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 (ini mencakup tindakan otomatis seperti update bertahap atau penurunan 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 pengosongan koneksi.

Load balancing berbobot

Load balancing berbobot memengaruhi backend mana yang memenuhi syarat dalam Langkah-langkah pemilihan backend. Setiap VM atau endpoint backend melaporkan bobotnya ke load balancer menggunakan health check 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 data dalam jumlah besar untuk memberi tahu load balancer agar mengurangi jumlah koneksi baru yang diterimanya.

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

Perhatikan hal-hal berikut saat menggunakan load balancing:

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

  • Jika Anda menggunakan grup instance atau NEG yang sama sebagai backend dari dua layanan backend load balancer atau lebih, 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 port tujuan atau parameter request-path yang unik.

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

Failover

Fitur failover memungkinkan Anda memengaruhi kumpulan backend yang memenuhi syarat dengan mengklasifikasikan grup instance backend atau NEG dan endpoint-nya seperti ini:

  • Backend utama adalah VM atau endpoint dalam grup instance atau NEG yang dikonfigurasi sebagai grup backend utama.
  • Backend failover adalah VM atau endpoint dalam grup instance atau NEG yang dikonfigurasi sebagai grup backend failover.

Secara default, saat Anda menambahkan grup instance atau NEG ke layanan backend, grup instance atau NEG tersebut adalah grup backend utama. Anda dapat menambahkan hingga 50 grup backend utama dan 50 grup backend failover ke layanan backend.

Untuk mengaktifkan fitur failover, Anda harus mengonfigurasi layanan backend load balancer dengan kedua hal berikut:

  • Setidaknya satu grup backend utama yang tidak kosong
  • Setidaknya satu grup backend failover yang tidak kosong

Jika failover diaktifkan, faktor berikut akan menentukan kumpulan backend yang memenuhi syarat:

  • Status responsivitas setiap backend
  • Rasio failover dalam kebijakan failover
  • Setelan drop traffic if backends are unhealthy dalam kebijakan failover
  • Apakah Anda menggunakan failover dengan sendirinya atau bersama dengan load balancing tertimbang

Kebijakan failover

Anda dapat menyesuaikan setelan berikut dalam kebijakan failover layanan backend. Kebijakan failover hanya relevan jika failover diaktifkan.

  • Rasio failover: angka antara 0.0 dan 1.0, inklusif.
  • Hentikan traffic jika backend tidak responsif: boolean yang menentukan perilaku upaya terakhir load balancer. Rasio failover dan setelan drop traffic if backends are unhealthy bekerja sama dengan faktor lain untuk mengontrol set backend yang memenuhi syarat.
  • Pengosongan 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 menentukan kapan kumpulan backend yang memenuhi syarat beralih antara backend utama dan backend 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. Praktik terbaiknya adalah menetapkan rasio failover ke angka yang sesuai untuk kasus penggunaan Anda, bukan mengandalkan default ini.

Pengosongan koneksi saat failover

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

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

Pengosongan koneksi pada opsi failover Perilaku saat set backend yang memenuhi syarat beralih antara backend utama dan failover
Diaktifkan (default)
  • Protokol yang koneksinya dapat dilacak: koneksi akan tetap ada, selama entri tabel pelacakan koneksi yang sesuai ada, saat kumpulan backend yang memenuhi syarat beralih antara backend utama dan backend failover. Untuk mengetahui informasi selengkapnya, lihat langkah mengelola entri tabel pelacakan koneksi.
  • Protokol yang tidak dapat dilacak koneksinya: koneksi tidak dipertahankan saat kumpulan 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 bertahan saat set backend yang memenuhi syarat beralih antara backend utama dan backend failover

Menonaktifkan pengosongan koneksi saat failover berguna untuk skenario berikut:

  • Melakukan patching pada VM backend. Sebelum melakukan patching, Anda dapat mengonfigurasi backend utama responsif dengan bobot bukan nol agar gagal dalam health check, atau Anda dapat menetapkan bobotnya ke nol. Dengan cara ini, backend yang memenuhi syarat dapat menjadi backend failover yang responsif dengan bobot bukan nol. Dengan menonaktifkan pengosongan koneksi pada failover, load balancer akan menghapus entri tabel pelacakan koneksi, menerapkan Langkah-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 pengosongan koneksi saat failover mengurangi kemungkinan inkonsistensi data.

Untuk mempelajari cara menonaktifkan pengosongan koneksi saat failover, lihat Menentukan kebijakan failover.

Praktik terbaik dan panduan

Anda dapat mengoptimalkan Load Balancer Jaringan passthrough eksternal regional 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 regional berbasis layanan backend dapat memproses paket UDP yang terfragmentasi dan tidak terfragmentasi. Jika aplikasi Anda menggunakan paket UDP yang terfragmentasi, perhatikan hal berikut:

  • Paket UDP mungkin terfragmentasi sebelum mencapai jaringan VPC Google Cloud.
  • Jaringan VPCGoogle Cloud meneruskan fragmen UDP saat 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 untuk 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 konfigurasikan aturan penerusan untuk menerima traffic di semua port. Tindakan ini memastikan bahwa semua fragmen tiba di aturan penerusan yang sama. Meskipun paket yang terfragmentasi (selain fragmen pertama) tidak memiliki port tujuan, mengonfigurasi aturan penerusan untuk memproses traffic untuk semua port juga mengonfigurasinya untuk menerima fragmen UDP yang tidak memiliki informasi port. Untuk mengonfigurasi semua port, gunakan Google Cloud CLI untuk menetapkan --ports=ALL atau gunakan API untuk menetapkan allPorts ke True.

  • Konfigurasi layanan backend: Tetapkan afinitas sesi layanan backend ke CLIENT_IP (hash 2-tuple) atau CLIENT_IP_PROTO (hash 3-tuple) sehingga backend yang sama dipilih untuk paket UDP yang menyertakan informasi port dan fragmen UDP (selain fragmen pertama) yang tidak memiliki informasi port. Tetapkan mode pelacakan koneksi layanan backend ke PER_SESSION sehingga entri tabel pelacakan koneksi dibuat menggunakan hash 2-tuple atau 3-tuple yang sama.

Pengujian dari satu klien

Saat menguji Load Balancer Jaringan passthrough eksternal regional 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 Select an eligible backend, 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 terhubung ke Load Balancer Jaringan passthrough eksternal regional dari satu klien.

  • Jika VM klien juga merupakan VM backend load balancer: koneksi baru sebenarnya tidak diproses sama sekali oleh load balancer. 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