Distribusi traffic untuk Load Balancer Jaringan passthrough internal

Halaman ini menjelaskan konsep berikut untuk membantu Anda lebih memahami dan menyesuaikan cara Load Balancer Jaringan passthrough internal mendistribusikan traffic: afinitas sesi, pelacakan koneksi, fragmentasi UDP, dan failover.

Cara Load Balancer Jaringan passthrough internal mendistribusikan koneksi baru bergantung pada apakah Anda telah mengonfigurasi failover:

• Jika Anda belum mengonfigurasi failover, Network Load Balancer passthrough internal akan mendistribusikan koneksi baru ke VM backend-nya yang responsif jika setidaknya satu VM backend responsif. Jika semua VM backend tidak responsif, load balancer akan mendistribusikan koneksi baru di antara semua backend sebagai upaya terakhir. Dalam situasi ini, load balancer merutekan setiap koneksi baru ke VM backend yang tidak responsif.

• Jika Anda telah mengonfigurasi failover, Load Balancer Jaringan passthrough internal akan mendistribusikan koneksi baru di antara VM dalam kumpulan aktifnya, sesuai dengan kebijakan failover yang Anda konfigurasikan. Jika semua VM backend tidak responsif, Anda dapat memilih salah satu perilaku berikut:

  • (Default) Load balancer hanya mendistribusikan traffic ke VM utama. Hal ini dilakukan sebagai upaya terakhir. VM cadangan dikecualikan dari distribusi koneksi sebagai upaya terakhir ini.
  • Load balancer dikonfigurasi untuk menurunkan traffic.

Metode untuk mendistribusikan koneksi baru bergantung pada setelan afinitas sesi load balancer.

Status health check mengontrol distribusi koneksi baru. Secara default, koneksi TCP tetap ada di backend yang tidak responsif. Untuk mengetahui detail selengkapnya dan cara mengubah perilaku ini, lihat Persistensi koneksi di backend yang tidak sehat.

Pemilihan backend dan pelacakan koneksi

Load Balancer Jaringan passthrough internal menggunakan algoritma pelacakan koneksi dan pemilihan backend yang dapat dikonfigurasi untuk menentukan cara traffic didistribusikan ke VM backend. Load Balancer Jaringan passthrough internal menggunakan algoritma berikut untuk mendistribusikan paket di antara VM backend (dalam kumpulan aktifnya, jika Anda telah mengonfigurasi failover):

1. Jika load balancer memiliki entri dalam tabel pelacakan koneksinya yang cocok dengan karakteristik paket yang masuk, paket akan dikirim ke backend yang ditentukan oleh entri tabel pelacakan koneksi. Paket dianggap sebagai bagian dari koneksi yang dibuat sebelumnya, sehingga paket dikirim ke VM backend yang sebelumnya ditentukan dan dicatat oleh load balancer dalam tabel pelacakan koneksinya.

2. Jika load balancer menerima paket yang tidak memiliki entri pelacakan koneksi, load balancer akan melakukan hal berikut:

   1. Load balancer memilih backend. Load balancer menghitung hash berdasarkan afinitas sesi yang dikonfigurasi. Fungsi ini menggunakan hash ini untuk memilih backend:

      • Jika setidaknya satu backend sehat, hash akan memilih salah satu backend yang sehat.
      • Jika semua backend tidak berfungsi, dan tidak ada kebijakan penggantian saat gagal yang dikonfigurasi, hash akan memilih salah satu backend.
      • Jika semua backend tidak responsif, ada kebijakan failover yang dikonfigurasi, dan kebijakan failover tidak dikonfigurasi untuk menghentikan traffic dalam situasi ini, hash akan memilih salah satu backend VM utama.

      Afinitas sesi default, NONE, menggunakan hash 5 tuple dari alamat IP sumber, port sumber, alamat IP tujuan, port tujuan, dan protokol paket

      Pemilihan backend dapat disesuaikan dengan menggunakan algoritma hash yang menggunakan lebih sedikit informasi. Untuk semua opsi yang didukung, lihat opsi afinitas sesi.

   2. Load balancer menambahkan entri ke tabel pelacakan koneksinya. Entri ini mencatat backend yang dipilih untuk koneksi paket sehingga semua paket mendatang dari koneksi ini dikirim ke backend yang sama. Apakah pelacakan koneksi digunakan bergantung pada protokol:

      Untuk paket TCP dan UDP, pelacakan koneksi selalu diaktifkan, dan tidak dapat dinonaktifkan. Secara default, pelacakan koneksi adalah 5-tuple, tetapi dapat dikonfigurasi menjadi kurang dari 5-tuple.

      Jika hash pelacakan koneksi adalah 5-tuple, paket SYN TCP selalu membuat entri baru di tabel pelacakan koneksi.
      
      Pelacakan koneksi 5-tuple default digunakan saat:

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

      Untuk mengetahui detail tambahan tentang kapan pelacakan koneksi diaktifkan, dan metode pelacakan yang digunakan saat pelacakan koneksi diaktifkan, lihat mode pelacakan koneksi.

      Selain itu, perhatikan hal-hal berikut:

      • Secara default, masa berlaku entri di tabel pelacakan koneksi berakhir setelah 600 detik setelah load balancer memproses paket terakhir yang cocok dengan entri tersebut. Untuk mengetahui detail tentang cara menyesuaikan waktu tunggu tidak ada aktivitas, lihat Waktu tunggu tidak ada aktivitas.
      • Bergantung pada protokol, load balancer mungkin menghapus entri tabel pelacakan koneksi saat backend menjadi tidak responsif. Untuk mengetahui detail dan cara menyesuaikan perilaku ini, lihat Persistensi koneksi di backend yang tidak sehat.

Opsi afinitas sesi

Afinitas sesi mengontrol distribusi koneksi baru dari klien ke VM backend load balancer. Anda menetapkan afinitas sesi saat VM backend perlu melacak informasi status untuk kliennya. Ini adalah persyaratan umum untuk aplikasi web.

Afinitas sesi berfungsi berdasarkan upaya terbaik.

Load Balancer Jaringan passthrough internal mendukung opsi afinitas sesi berikut, yang Anda tentukan untuk seluruh layanan backend internal, bukan per grup instance backend.

• Tidak ada (NONE). Hash 5-tuple dari alamat IP sumber, port sumber, protokol, alamat IP tujuan, dan port tujuan
• IP klien, tanpa tujuan (CLIENT_IP_NO_DESTINATION). Hash 1-tuple yang dibuat hanya dari alamat IP sumber.
• IP klien (CLIENT_IP). Hash 2-tuple dari alamat IP sumber dan alamat IP tujuan. Load Balancer Jaringan passthrough eksternal menyebut opsi afinitas sesi ini sebagai Client IP, Destination IP.
• Client IP, Destination IP, Protocol (CLIENT_IP_PROTO). Hash 3-tuple dari alamat IP sumber, alamat IP tujuan, dan protokol
• IP Klien, Port Klien, IP Tujuan, Port Tujuan, Protokol (CLIENT_IP_PORT_PROTO). Hash 5-tuple dari alamat IP sumber, port sumber, protokol, alamat IP tujuan, dan port tujuan

Kecuali jika Anda menggunakan load balancer sebagai next hop untuk rute statis kustom, alamat IP tujuan paket harus cocok dengan alamat IP aturan penerusan load balancer agar paket dapat dikirim ke load balancer. Untuk pertimbangan saat menggunakan load balancer sebagai next hop untuk rute statis kustom, baca artikel Afinitas sesi dan Load Balancer Jaringan passthrough internal next hop.

Catatan: Untuk load balancer UDP internal, menetapkan afinitas sesi didukung di gcloud CLI dan API. Anda tidak dapat menetapkan afinitas sesi untuk traffic UDP menggunakan konsol Google Cloud .

Afinitas sesi dan next hop Load Balancer Jaringan passthrough internal

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

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

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

• Jika hanya ada satu VM backend yang dikonfigurasi dan responsif (di kumpulan aktif, jika failover dikonfigurasi), tidak masalah afinitas sesi apa yang Anda gunakan karena semua hash dipetakan ke satu VM backend.

• Jika ada dua atau beberapa VM backend yang dikonfigurasi dan responsif (dalam kumpulan aktif, jika failover dikonfigurasi), pilihan afinitas sesi Anda penting:

  • Jika Anda memerlukan VM backend yang sama untuk memproses semua paket dari klien, hanya berdasarkan alamat IP sumber paket, terlepas dari alamat IP tujuan paket, gunakan afinitas sesi CLIENT_IP_NO_DESTINATION. Bergantung pada pola traffic, beberapa VM backend mungkin menerima lebih banyak paket atau lebih banyak koneksi daripada VM backend lainnya.

  • Jika Anda menggunakan opsi afinitas sesi yang bukan CLIENT_IP_NO_DESTINATION, load balancer akan memilih VM backend berdasarkan informasi yang setidaknya menyertakan baik alamat IP sumber dan alamat IP tujuan paket. Paket yang dikirim dari klien yang sama, menggunakan alamat IP sumber yang sama, tetapi alamat IP tujuan yang berbeda, dapat dirutekan ke VM backend yang berbeda.

Kebijakan pelacakan koneksi

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

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

Mode pelacakan koneksi

Mode pelacakan menentukan algoritma pelacakan koneksi yang akan digunakan. Ada dua mode pelacakan: PER_CONNECTION (default) dan PER_SESSION.

• PER_CONNECTION (default). Dalam mode ini, traffic TCP dan UDP selalu dilacak per 5-tuple, terlepas dari setelan afinitas sesi. Hal ini menyiratkan bahwa kunci untuk pelacakan koneksi (5-tuple) dapat berbeda dari setelan afinitas sesi yang dikonfigurasi (misalnya, 3-tuple dengan setelan CLIENT_IP_PROTO). Akibatnya, afinitas sesi dapat dibagi dan koneksi baru untuk sesi dapat memilih backend yang berbeda jika kumpulan backend atau statusnya berubah.

• PER_SESSION. Dalam mode ini, traffic TCP dan UDP dilacak sesuai dengan afinitas sesi yang dikonfigurasi. Artinya, jika afinitas sesi adalah CLIENT_IP atau CLIENT_IP_PROTO, mengonfigurasi mode ini akan menghasilkan pelacakan koneksi 2-tuple dan 3-tuple. Hal ini mungkin diinginkan dalam skenario saat pemutusan afinitas mahal dan harus dihindari bahkan setelah lebih banyak backend ditambahkan.

Setelan mode pelacakan koneksi bersifat redundan jika afinitas sesi ditetapkan ke NONE atau CLIENT_IP_PORT_PROTO. Untuk mempelajari cara kerja mode pelacakan ini dengan setelan afinitas sesi yang berbeda untuk setiap protokol, lihat tabel berikut.

Pemilihan backend		Mode pelacakan koneksi
Setelan afinitas sesi	Metode hash untuk pemilihan backend	PER_CONNECTION (default)	PER_SESSION
Default: Tidak ada afinitas sesi NONE	Hash 5-tuple	Pelacakan koneksi 5-tuple	Pelacakan koneksi 5-tuple
IP klien, tanpa tujuan CLIENT_IP_NO_DESTINATION	Hash 1 tuple	Pelacakan koneksi 5-tuple	Pelacakan koneksi 1-tuple
IP Klien CLIENT_IP (sama dengan IP Klien, IP Tujuan untuk Load Balancer Jaringan passthrough eksternal)	Hash 2-tuple	Pelacakan koneksi 5-tuple	Pelacakan koneksi 2-tuple
IP Klien, IP Tujuan, Protokol CLIENT_IP_PROTO	Hash 3-tuple	Pelacakan koneksi 5-tuple	Pelacakan koneksi 3-tuple
IP Klien, Port Klien, IP Tujuan, Port Tujuan, Protokol CLIENT_IP_PORT_PROTO	Hash 5-tuple	Pelacakan koneksi 5-tuple	Pelacakan koneksi 5-tuple

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

Persistensi koneksi di backend yang tidak responsif

Setelan persistensi koneksi pada backend yang tidak berfungsi mengontrol apakah koneksi yang ada tetap ada di backend yang dipilih setelah backend tersebut tidak berfungsi (selama backend tetap berada dalam grup instance backend yang dikonfigurasi load balancer).

Perilaku yang dijelaskan di bagian ini tidak berlaku jika Anda menghapus VM backend dari grup instance-nya, atau menghapus grup instance dari layanan backend. Dalam kasus tersebut, koneksi yang dibuat hanya akan tetap ada seperti yang dijelaskan dalam Mengaktifkan pengosongan koneksi.

Opsi persistensi koneksi berikut tersedia:

• DEFAULT_FOR_PROTOCOL (default)
• NEVER_PERSIST
• ALWAYS_PERSIST

Tabel berikut merangkum opsi persistensi koneksi dan cara koneksi tetap ada untuk berbagai protokol, opsi afinitas sesi, dan mode pelacakan.

Opsi Persistensi koneksi pada backend yang tidak responsif	Mode pelacakan koneksi
	PER_CONNECTION	PER_SESSION
DEFAULT_FOR_PROTOCOL	TCP: koneksi tetap ada di backend yang tidak sehat (semua afinitas sesi) UDP: koneksi tidak pernah dipertahankan di backend yang tidak sehat	TCP: koneksi tetap ada di backend yang tidak responsif jika afinitas sesi adalah NONE atau CLIENT_IP_PORT_PROTO UDP: koneksi tidak pernah dipertahankan di backend yang tidak sehat
NEVER_PERSIST	TCP, UDP: koneksi tidak pernah dipertahankan di backend yang tidak sehat
ALWAYS_PERSIST	TCP, UDP: koneksi tetap ada di backend yang tidak sehat (semua afinitas sesi) Opsi ini hanya boleh digunakan untuk kasus penggunaan lanjutan.	Konfigurasi tidak memungkinkan

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

Catatan: Saat load balancer memindahkan koneksi dari backend yang tidak responsif, load balancer akan membuat entri tabel pelacakan baru. Entri baru memetakan koneksi ke backend yang berbeda berdasarkan afinitas sesi yang dikonfigurasi. Entri baru tetap valid seperti entri lainnya. Jika backend yang tidak sehat kembali sehat, hal itu saja tidak akan menyebabkan entri tabel pelacakan koneksi dihapus (kecuali jika memicu failback dan pengosongan koneksi saat failover dan failback telah dinonaktifkan).

Waktu tunggu tidak ada aktivitas

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

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

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

Koneksi untuk deployment satu klien

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

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

  Secara praktis, ini berarti Anda tidak dapat memantau distribusi traffic secara akurat melalui Load Balancer Jaringan passthrough internal dengan menghubungkannya dari satu klien. Jumlah klien yang diperlukan untuk memantau distribusi traffic bervariasi bergantung pada jenis load balancer, jenis traffic, dan jumlah backend yang sehat.

• Jika VM klien juga merupakan VM backend load balancer, koneksi yang dikirim ke alamat IP aturan penerusan load balancer selalu dijawab oleh VM backend yang sama (yang juga merupakan VM klien). Hal ini terjadi terlepas dari apakah VM backend responsif atau tidak. Hal ini terjadi untuk semua traffic yang dikirim ke alamat IP load balancer, bukan hanya traffic pada protokol dan port yang ditentukan dalam aturan penerusan internal load balancer.

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

Pengosongan koneksi

Pengosongan koneksi adalah proses yang diterapkan ke koneksi yang dibuat dalam kasus berikut:

• VM atau endpoint dihapus dari backend (grup instance atau NEG).
• Backend menghapus VM atau endpoint (dengan penggantian, penghentian, saat melakukan upgrade, atau menskalakan ke bawah).

Secara default, pengosongan koneksi dinonaktifkan. Jika dinonaktifkan, koneksi yang sudah dibuat akan dihentikan secepat mungkin. Jika penghentian koneksi diaktifkan, koneksi yang dibuat diizinkan untuk tetap ada selama waktu tunggu yang dapat dikonfigurasi, setelah itu instance VM backend dihentikan.

Untuk mengetahui detail selengkapnya tentang cara pengosongan koneksi dipicu dan cara mengaktifkan pengosongan koneksi, lihat Mengaktifkan pengosongan koneksi.

Fragmentasi UDP

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

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

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

• Konfigurasi aturan penerusan: Hanya gunakan satu aturan penerusan UDP per alamat IP yang di-load balance, dan konfigurasikan aturan penerusan untuk menerima traffic di semua port. 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.

Failover

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

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

Untuk ringkasan konseptual mendetail tentang failover di Load Balancer Jaringan passthrough internal, lihat Failover untuk Load Balancer Jaringan passthrough internal.

Langkah selanjutnya

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