Distribusi permintaan untuk Load Balancer Aplikasi eksternal

Dokumen ini membahas secara mendalam seluk-beluk cara Load Balancer Aplikasi eksternal menangani koneksi, merutekan traffic, dan mempertahankan afinitas sesi.

Cara kerja koneksi

Load Balancer Aplikasi eksternalTrusted Cloud—global dan regional—menyederhanakan perutean menggunakan proxy terdistribusi (GFE) atau subnet yang dikelola Envoy. Dengan waktu tunggu yang dapat dikonfigurasi, penghentian TLS, dan keamanan bawaan, mereka memastikan pengiriman aplikasi yang sesuai dan dapat diskalakan di seluruh dunia atau secara regional.

Koneksi Load Balancer Aplikasi eksternal regional

Load Balancer Aplikasi eksternal regional adalah layanan terkelola yang diterapkan pada proxy Envoy. Load Balancer Aplikasi eksternal regional menggunakan subnet bersama yang disebut subnet khusus proxy untuk menyediakan serangkaian alamat IP yang digunakan Google untuk menjalankan proxy Envoy atas nama Anda. Flag --purpose untuk subnet khusus proxy ini ditetapkan ke REGIONAL_MANAGED_PROXY. Semua load balancer berbasis Envoy regional dalam jaringan dan region tertentu berbagi subnet ini.

Klien menggunakan alamat IP dan port load balancer untuk terhubung ke load balancer. Permintaan klien diarahkan ke subnet khusus proxy di region yang sama dengan klien. Load balancer menghentikan permintaan klien, lalu membuka koneksi baru dari subnet khusus proxy ke backend Anda. Oleh karena itu, paket yang dikirim dari load balancer memiliki alamat IP sumber dari subnet khusus proxy.

Bergantung pada konfigurasi layanan backend, protokol yang digunakan oleh proxy Envoy untuk terhubung ke backend Anda dapat berupa HTTP, HTTPS, atau HTTP/2. Jika HTTP atau HTTPS, versi HTTP adalah HTTP 1.1. Keep-alive HTTP diaktifkan secara default, seperti yang ditentukan dalam spesifikasi HTTP 1.1. Proxy Envoy menetapkan waktu tunggu keep-alive HTTP klien dan waktu tunggu keep-alive backend ke nilai default 600 detik. Anda dapat memperbarui waktu tunggu tetap aktif HTTP klien, tetapi nilai waktu tunggu tetap aktif backend sudah ditetapkan. Anda dapat mengonfigurasi waktu tunggu permintaan/respons dengan menetapkan waktu tunggu layanan backend. Untuk mengetahui informasi selengkapnya, lihat waktu tunggu dan percobaan ulang.

Komunikasi klien dengan load balancer

• Klien dapat berkomunikasi dengan load balancer menggunakan protokol HTTP 1.1 atau HTTP/2.
• Jika HTTPS digunakan, klien modern secara default menggunakan HTTP/2. Hal ini dikontrol di klien, bukan di load balancer HTTPS.
• Anda tidak dapat menonaktifkan HTTP/2 dengan membuat perubahan konfigurasi pada load balancer. Namun, Anda dapat mengonfigurasi beberapa klien untuk menggunakan HTTP 1.1, bukan HTTP/2. Misalnya, dengan curl, gunakan parameter --http1.1.
• Load Balancer Aplikasi Eksternal mendukung respons HTTP/1.1 100 Continue.

Untuk mengetahui daftar lengkap protokol yang didukung oleh aturan penerusan Load Balancer Aplikasi eksternal dalam setiap mode, lihat Fitur load balancer.

Alamat IP sumber untuk paket klien

Alamat IP sumber untuk paket, seperti yang terlihat oleh backend, bukan Trusted Cloud alamat IP eksternal load balancer. Dengan kata lain, ada dua koneksi TCP.

Untuk Load Balancer Aplikasi eksternal regional:

• Koneksi 1, dari klien asli ke load balancer (subnet khusus proxy):

  • Alamat IP sumber: klien asli (atau alamat IP eksternal jika klien berada di belakang gateway NAT atau proxy penerusan).
  • Alamat IP tujuan: alamat IP load balancer Anda.

• Koneksi 2, dari load balancer (subnet khusus proxy) ke VM atau endpoint backend:

  • Alamat IP sumber: alamat IP di subnet khusus proxy yang dibagikan di antara semua load balancer berbasis Envoy yang di-deploy di region dan jaringan yang sama dengan load balancer.

  • Alamat IP tujuan: alamat IP internal VM atau penampung backend di jaringan VPC.

Jalur perutean khusus

Trusted Cloud menggunakan rute khusus yang tidak ditentukan di jaringan VPC Anda untuk merutekan paket untuk jenis traffic berikut:

• Untuk health check, kecuali health check Envoy terdistribusi. Untuk mengetahui informasi selengkapnya, lihat Jalur untuk health check.

Trusted Cloud menggunakan rute subnet untuk subnet khusus proxy guna merutekan paket untuk jenis traffic berikut:

• Saat menggunakan health check Envoy terdistribusi.

Untuk Load Balancer Aplikasi eksternal regional, Trusted Cloud menggunakan proxy Envoy open source untuk menghentikan permintaan klien ke load balancer. Load balancer menghentikan sesi TCP dan membuka sesi TCP baru dari subnet khusus proxy di region ke backend Anda. Rute yang ditentukan dalam jaringan VPC Anda memfasilitasi komunikasi dari proxy Envoy ke backend Anda dan dari backend Anda ke proxy Envoy.

TLS termination

Tabel berikut merangkum cara peniadaan TLS ditangani oleh Load Balancer Aplikasi eksternal.

Mode load balancer	TLS termination
Load Balancer Aplikasi eksternal regional	TLS dihentikan pada proxy Envoy yang berada di subnet khusus proxy di region yang dipilih oleh pengguna. Gunakan mode load balancer ini jika Anda memerlukan kontrol geografis atas region tempat TLS dihentikan.

Waktu tunggu dan percobaan ulang

Load Balancer Aplikasi Eksternal mendukung jenis waktu tunggu berikut untuk traffic HTTP atau HTTPS:

Jenis dan deskripsi waktu tunggu	Nilai default	Mendukung nilai waktu tunggu kustom
		Waktu tunggu layanan backend1 Waktu tunggu permintaan dan respons. Mewakili jumlah waktu maksimum yang diizinkan antara load balancer yang mengirim byte pertama permintaan ke backend dan backend yang menampilkan byte terakhir respons HTTP ke load balancer. Jika backend belum menampilkan seluruh respons HTTP ke load balancer dalam batas waktu ini, data respons yang tersisa akan dihilangkan.	Untuk semua jenis backend lainnya di layanan backend: 30 detik
Waktu tunggu aktif HTTP klien Waktu maksimum koneksi TCP antara klien dan proxy load balancer dapat tidak aktif. (Koneksi TCP yang sama dapat digunakan untuk beberapa permintaan HTTP.) Untuk Load Balancer Aplikasi eksternal regional, proxy load balancer adalah software Envoy.	610 detik
Waktu tunggu keep-alive HTTP backend Jumlah waktu maksimum koneksi TCP antara proxy load balancer dan backend dapat tidak aktif. (Koneksi TCP yang sama dapat digunakan untuk beberapa permintaan HTTP.) Untuk Load Balancer Aplikasi eksternal regional, proxy load balancer adalah software Envoy.	Untuk layanan backend: 10 menit (600 detik)

Waktu tunggu layanan backend

Waktu tunggu layanan backend yang dapat dikonfigurasi menunjukkan jumlah waktu maksimum yang ditunggu load balancer agar backend Anda memproses permintaan HTTP dan menampilkan respons HTTP yang sesuai. Kecuali untuk NEG tanpa server, nilai default untuk waktu tunggu layanan backend adalah 30 detik.

Misalnya, jika Anda ingin mendownload file berukuran 500 MB, dan nilai waktu tunggu layanan backend adalah 90 detik, load balancer akan mengharapkan backend mengirimkan seluruh file berukuran 500 MB dalam waktu 90 detik. Waktu tunggu layanan backend dapat dikonfigurasi agar tidak cukup bagi backend untuk mengirim respons HTTP lengkapnya. Dalam situasi ini, jika load balancer telah menerima header respons HTTP dari backend, load balancer akan menampilkan header respons lengkap dan isi respons sebanyak yang dapat diperoleh dalam waktu tunggu layanan backend.

Sebaiknya tetapkan waktu tunggu layanan backend ke waktu terlama yang Anda perkirakan dibutuhkan backend untuk memproses respons HTTP. Jika software yang berjalan di backend Anda memerlukan lebih banyak waktu untuk memproses permintaan HTTP dan menampilkan seluruh responsnya, sebaiknya tingkatkan waktu tunggu layanan backend. Misalnya, sebaiknya tingkatkan batas waktu jika Anda melihat respons kode status HTTP 408 dengan error jsonPayload.statusDetail client_timed_out.

Waktu tunggu layanan backend menerima nilai antara 1 dan 2,147,483,647 detik; namun, nilai yang lebih besar bukanlah opsi konfigurasi yang praktis. Trusted Cloud juga tidak menjamin bahwa koneksi TCP yang mendasarinya dapat tetap terbuka selama seluruh nilai waktu tunggu layanan backend. Sistem klien harus menerapkan logika percobaan ulang, bukan mengandalkan koneksi TCP agar tetap terbuka dalam jangka waktu yang lama.

Untuk mengonfigurasi waktu tunggu layanan backend, gunakan salah satu metode berikut:

Waktu tunggu koneksi Websocket tidak selalu sama dengan waktu tunggu layanan backend. Waktu tunggu koneksi Websocket bergantung pada jenis load balancer:

Mode load balancer	Nilai default	Deskripsi waktu tunggu untuk websocket
Load Balancer Aplikasi eksternal regional	waktu tunggu layanan backend: 30 detik	Koneksi websocket aktif tidak menggunakan waktu tunggu layanan backend load balancer. Koneksi websocket yang tidak aktif akan ditutup setelah layanan backend mengalami waktu tunggu. Trusted Cloud secara berkala memulai ulang atau mengubah jumlah tugas software Envoy yang melayani permintaan. Semakin lama nilai waktu tunggu layanan backend, semakin besar kemungkinan tugas Envoy dimulai ulang atau menghentikan koneksi TCP.

Load Balancer Aplikasi eksternal regional menggunakan parameter routeActions.timeout yang dikonfigurasi dari peta URL dan mengabaikan waktu tunggu layanan backend. Jika routeActions.timeout tidak dikonfigurasi, nilai waktu tunggu layanan backend akan digunakan. Jika routeActions.timeout diberikan, waktu tunggu layanan backend akan diabaikan, dan nilai routeActions.timeout akan digunakan sebagai waktu tunggu permintaan dan respons.

Waktu tunggu keep-alive HTTP klien

Waktu tunggu keep-alive HTTP klien menunjukkan jumlah waktu maksimum koneksi TCP dapat tidak aktif antara klien (downstream) dan salah satu jenis proxy berikut:

• Untuk Load Balancer Aplikasi eksternal regional: proxy Envoy

Waktu tunggu HTTP keep-alive klien mewakili waktu tunggu tidak ada aktivitas TCP untuk koneksi TCP yang mendasarinya. Waktu tunggu tetap aktif HTTP klien tidak berlaku untuk websocket.

Nilai default untuk waktu tunggu keep-alive HTTP klien adalah 610 detik. Untuk Load Balancer Aplikasi eksternal global dan regional, Anda dapat mengonfigurasi waktu tunggu keep-alive HTTP klien dengan nilai antara 5 dan 1.200 detik.

Untuk mengonfigurasi waktu tunggu habis keep-alive HTTP klien, gunakan salah satu metode berikut:

Waktu tunggu HTTP keep-alive klien load balancer harus lebih besar daripada waktu tunggu HTTP keep-alive (TCP idle) yang digunakan oleh klien atau proxy hilir. Jika klien hilir memiliki waktu tunggu HTTP keep-alive (TCP idle) yang lebih besar daripada waktu tunggu HTTP keep-alive klien load balancer, kondisi persaingan dapat terjadi. Dari perspektif klien hilir, koneksi TCP yang dibuat diizinkan untuk tidak aktif lebih lama daripada yang diizinkan oleh load balancer. Artinya, klien hilir dapat mengirim paket setelah load balancer menganggap koneksi TCP telah ditutup. Jika hal itu terjadi, load balancer akan merespons dengan paket reset TCP (RST).

Saat waktu tunggu keep-alive HTTP klien berakhir, proxy GFE atau Envoy akan mengirim TCP FIN ke klien untuk menutup koneksi dengan benar.

Waktu tunggu keep-alive HTTP backend

Load Balancer Aplikasi eksternal adalah proxy yang menggunakan minimal dua koneksi TCP:

• Untuk Load Balancer Aplikasi eksternal regional, koneksi TCP pertama ada antara klien (downstream) dan proxy Envoy. Proxy Envoy kemudian membuka koneksi TCP kedua ke backend Anda.

Koneksi TCP sekunder load balancer mungkin tidak ditutup setelah setiap permintaan; koneksi tersebut dapat tetap terbuka untuk menangani beberapa permintaan dan respons HTTP. Waktu tunggu tetap aktif HTTP backend menentukan waktu tunggu tidak ada aktivitas TCP antara load balancer dan backend Anda. Waktu tunggu HTTP keep-alive backend tidak berlaku untuk websocket.

Waktu tunggu tetap aktif backend ditetapkan pada 10 menit (600 detik) dan tidak dapat diubah. Hal ini membantu memastikan load balancer mempertahankan koneksi tidak aktif selama minimal 10 menit. Setelah periode ini, load balancer dapat mengirimkan paket penghentian ke backend kapan saja.

Waktu tunggu tetap aktif backend load balancer harus kurang dari waktu tunggu tetap aktif yang digunakan oleh software yang berjalan di backend Anda. Hal ini menghindari kondisi race di mana sistem operasi backend Anda dapat menutup koneksi TCP dengan reset TCP (RST). Karena waktu tunggu tetap aktif backend untuk load balancer tidak dapat dikonfigurasi, Anda harus mengonfigurasi software backend sehingga nilai waktu tunggu tetap aktif HTTP (TCP idle) lebih besar dari 600 detik.

Saat waktu tunggu keep-alive HTTP backend berakhir, GFE atau proxy Envoy akan mengirim TCP FIN ke VM backend untuk menutup koneksi dengan benar.

Tabel berikut mencantumkan perubahan yang diperlukan untuk mengubah nilai waktu tunggu tetap aktif untuk software server web umum.

Software server web	Parameter	Setelan default	Setelan yang direkomendasikan
Apache	KeepAliveTimeout	KeepAliveTimeout 5	KeepAliveTimeout 620
nginx	keepalive_timeout	keepalive_timeout 75s;	keepalive_timeout 620s;

Upaya coba lagi

Dukungan untuk logika percobaan ulang bergantung pada mode Load Balancer Aplikasi eksternal.

Mode load balancer

Logika percobaan ulang

Load Balancer Aplikasi eksternal regional

Dapat dikonfigurasi menggunakan kebijakan coba lagi di peta URL. Jumlah percobaan ulang default (numRetries) adalah 1. Jumlah maksimum percobaan ulang yang dapat dikonfigurasi menggunakan kebijakan percobaan ulang adalah 25. perTryTimeout yang dapat dikonfigurasi maksimum adalah 24 jam. Tanpa kebijakan percobaan ulang, permintaan yang gagal yang tidak memiliki isi HTTP (misalnya, permintaan GET) yang menghasilkan respons HTTP 502, 503, atau 504 akan dicoba ulang satu kali. Permintaan POST HTTP tidak dicoba lagi. Permintaan yang dicoba lagi hanya menghasilkan satu entri log untuk respons akhir.

Protokol WebSocket didukung dengan GKE Ingress.

Penanganan permintaan dan respons ilegal

Load balancer memblokir permintaan klien dan respons backend agar tidak mencapai backend atau klien, masing-masing, karena sejumlah alasan. Beberapa alasannya adalah untuk kepatuhan terhadap HTTP/1.1 dan yang lainnya adalah untuk menghindari data yang tidak terduga diteruskan ke atau dari backend. Tidak ada pemeriksaan yang dapat dinonaktifkan.

Load balancer memblokir permintaan berikut untuk kepatuhan HTTP/1.1:

• Tidak dapat mengurai baris pertama permintaan.
• Header tidak memiliki pemisah titik dua (:).
• Header atau baris pertama berisi karakter yang tidak valid.
• Panjang konten bukan angka yang valid, atau ada beberapa header panjang konten.
• Ada beberapa kunci encoding transfer, atau ada nilai encoding transfer yang tidak dikenali.
• Ada isi yang tidak di-chunk dan tidak ada panjang konten yang ditentukan.
• Chunk isi tidak dapat diuraikan. Ini adalah satu-satunya kasus saat beberapa data mencapai backend. Load balancer menutup koneksi ke klien dan backend saat menerima potongan yang tidak dapat diuraikan.

Penanganan permintaan

Load balancer memblokir permintaan jika salah satu hal berikut terpenuhi:

• Total ukuran header permintaan dan URL permintaan melebihi batas untuk ukuran header permintaan maksimum untuk Load Balancer Aplikasi eksternal.
• Metode permintaan tidak mengizinkan isi, tetapi permintaan memilikinya.
• Permintaan berisi header Upgrade, dan header Upgrade tidak digunakan untuk mengaktifkan koneksi WebSocket.
• Versi HTTP tidak diketahui.

Penanganan respons

Load balancer memblokir respons backend jika salah satu hal berikut benar:

• Total ukuran header respons melebihi batas ukuran header respons maksimum untuk Load Balancer Aplikasi eksternal.
• Versi HTTP tidak diketahui.

Saat menangani permintaan dan respons, load balancer dapat menghapus atau mengganti header hop-by-hop di HTTP/1.1 sebelum meneruskannya ke tujuan yang diinginkan.

Distribusi traffic

Saat menambahkan grup instance backend atau NEG ke layanan backend, Anda menentukan mode load balancing, yang menentukan metode pengukuran beban backend dan kapasitas target. Load Balancer Aplikasi Eksternal mendukung dua mode penyeimbangan:

• RATE, untuk grup instance atau NEG, adalah jumlah maksimum target permintaan (kueri) per detik (RPS, QPS). Target RPS/QPS maksimum dapat terlampaui jika semua backend berada pada atau di atas kapasitas.

• UTILIZATION adalah pemanfaatan backend VM dalam grup instance.

Cara traffic didistribusikan di antara backend bergantung pada mode load balancer.

Load Balancer Aplikasi eksternal regional

Untuk Load Balancer Aplikasi eksternal regional, distribusi traffic didasarkan pada mode load balancing dan kebijakan lokalitas load balancing.

Mode penyeimbangan menentukan bobot dan fraksi traffic yang akan dikirim ke setiap grup (grup instance atau NEG). Kebijakan lokalitas load balancing (LocalityLbPolicy) menentukan cara backend dalam grup di-load balance.

Saat menerima traffic, layanan backend pertama-tama mengarahkan traffic ke backend (grup instance atau NEG) sesuai dengan mode load balancing backend. Setelah backend dipilih, traffic akan didistribusikan di antara instance atau endpoint dalam grup backend tersebut sesuai dengan kebijakan lokalitas load balancing.

Untuk informasi selengkapnya, lihat referensi berikut:

• Mode penyeimbangan
• Kebijakan lokalitas load balancing (dokumentasi API layanan backend regional ).

Afinitas sesi

Afinitas sesi, yang dikonfigurasi pada layanan backend Load Balancer Aplikasi, memberikan upaya terbaik untuk mengirim permintaan dari klien tertentu ke backend yang sama selama jumlah instance atau endpoint backend yang responsif tetap konstan, dan selama instance atau endpoint backend yang dipilih sebelumnya tidak mencapai kapasitas maksimum. Kapasitas target mode balancing menentukan kapan backend mencapai kapasitas.

Tabel berikut menguraikan berbagai jenis opsi afinitas sesi yang didukung untuk berbagai Application Load Balancer. Di bagian berikutnya, Jenis afinitas sesi, setiap jenis afinitas sesi dibahas lebih mendetail.

Tabel: Setelan afinitas sesi yang didukung

Produk

Opsi afinitas sesi

Load Balancer Aplikasi eksternal regional

Tidak ada (NONE) IP Klien (CLIENT_IP) Cookie yang dihasilkan (GENERATED_COOKIE) Kolom header (HEADER_FIELD) Cookie HTTP (HTTP_COOKIE) Afinitas berbasis cookie stateful (STRONG_COOKIE_AFFINITY) Perhatikan juga: Nilai default efektif kebijakan lokalitas load balancing (localityLbPolicy) berubah sesuai dengan setelan afinitas sesi Anda. Jika afinitas sesi tidak dikonfigurasi—yaitu, jika afinitas sesi tetap pada nilai default NONE—maka nilai default untuk localityLbPolicy adalah ROUND_ROBIN. Jika afinitas sesi ditetapkan ke nilai selain NONE, maka nilai default untuk localityLbPolicy adalah MAGLEV.

Perhatikan hal-hal berikut saat mengonfigurasi afinitas sesi:

• Jangan mengandalkan afinitas sesi untuk tujuan autentikasi atau keamanan. Afinitas sesi, kecuali afinitas sesi berbasis cookie stateful, dapat terganggu setiap kali jumlah backend yang melayani dan sehat berubah. Untuk mengetahui detail selengkapnya, lihat Kehilangan afinitas sesi.

• Nilai default flag --session-affinity dan --subsetting-policy adalah NONE, dan hanya salah satu flag yang dapat disetel ke nilai yang berbeda dalam satu waktu.

Jenis afinitas sesi

Afinitas sesi untuk Load Balancer Aplikasi eksternal dapat diklasifikasikan ke dalam salah satu kategori berikut:

• Afinitas sesi berbasis hash (NONE, CLIENT_IP)
• Afinitas sesi berbasis header HTTP (HEADER_FIELD)
• Afinitas sesi berbasis cookie (GENERATED_COOKIE, HTTP_COOKIE, STRONG_COOKIE_AFFINITY)

Afinitas sesi berbasis hash

Untuk afinitas sesi berbasis hash, load balancer menggunakan algoritma hashing yang konsisten untuk memilih backend yang memenuhi syarat. Setelan afinitas sesi menentukan kolom mana dari header IP yang digunakan untuk menghitung hash.

Afinitas sesi berbasis hash dapat berupa salah satu jenis berikut:

• Tidak ada
• Afinitas IP klien

Tidak ada

Setelan afinitas sesi NONE tidak berarti tidak ada afinitas sesi. Artinya, tidak ada opsi afinitas sesi yang dikonfigurasi secara eksplisit.

Hashing selalu dilakukan untuk memilih backend. Setelan afinitas sesi NONE berarti load balancer menggunakan hash 5 tuple untuk memilih backend. Hash 5 tuple terdiri dari alamat IP sumber, port sumber, protokol, alamat IP tujuan, dan port tujuan.

Afinitas sesi NONE adalah nilai default.

Afinitas IP klien

Afinitas sesi IP klien (CLIENT_IP) adalah hash 2-tuple yang dibuat dari alamat IP sumber dan tujuan paket. Afinitas IP klien meneruskan semua permintaan dari alamat IP klien yang sama ke backend yang sama, selama backend tersebut memiliki kapasitas dan tetap responsif.

Saat Anda menggunakan afinitas IP klien, perhatikan hal-hal berikut:

• Alamat IP tujuan paket hanya sama dengan alamat IP aturan penerusan load balancer jika paket dikirim langsung ke load balancer.
• Alamat IP sumber paket mungkin tidak cocok dengan alamat IP yang terkait dengan klien asli jika paket diproses oleh sistem NAT atau proxy perantara sebelum dikirimkan ke load balancer Trusted Cloud . Dalam situasi ketika banyak klien berbagi alamat IP sumber efektif yang sama, beberapa VM backend mungkin menerima lebih banyak koneksi atau permintaan daripada yang lain.

Afinitas sesi berbasis header HTTP

Dengan afinitas kolom header (HEADER_FIELD), permintaan dirutekan ke backend berdasarkan nilai header HTTP di kolom consistentHash.httpHeaderName layanan backend. Untuk mendistribusikan permintaan di semua backend yang tersedia, setiap klien harus menggunakan nilai header HTTP yang berbeda.

Afinitas kolom header didukung jika kondisi berikut terpenuhi:

• Kebijakan lokalitas load balancing adalah RING_HASH atau MAGLEV.
• consistentHash layanan backend menentukan nama header HTTP (httpHeaderName).

Afinitas sesi berbasis cookie

Afinitas sesi berbasis cookie dapat berupa salah satu jenis berikut:

• Afinitas berbasis cookie
• Afinitas cookie HTTP
• Afinitas sesi berbasis cookie stateful

Afinitas berbasis cookie

Saat Anda menggunakan afinitas berbasis cookie yang dihasilkan (GENERATED_COOKIE), load balancer akan menyertakan cookie HTTP di header Set-Cookie sebagai respons terhadap permintaan HTTP awal.

Nama cookie yang dihasilkan bervariasi, bergantung pada jenis load balancer.

Produk	Nama cookie
Load Balancer Aplikasi eksternal global	GCLB
Load Balancer Aplikasi Klasik	GCLB
Load Balancer Aplikasi eksternal regional	GCILB

Atribut jalur cookie yang dibuat selalu berupa garis miring (/), sehingga berlaku untuk semua layanan backend di peta URL yang sama, asalkan layanan backend lainnya juga menggunakan afinitas cookie yang dibuat.

Anda dapat mengonfigurasi nilai time to live (TTL) cookie antara 0 dan 1,209,600 detik (inklusif) menggunakan parameter layanan backend affinityCookieTtlSec. Jika affinityCookieTtlSec tidak ditentukan, nilai TTL defaultnya adalah 0.

Saat klien menyertakan cookie afinitas sesi yang dihasilkan dalam header permintaan Cookie permintaan HTTP, load balancer akan mengarahkan permintaan tersebut ke instance atau endpoint backend yang sama, selama cookie afinitas sesi tetap valid. Hal ini dilakukan dengan memetakan nilai cookie ke indeks yang mereferensikan instance backend atau endpoint tertentu, dan dengan memastikan bahwa persyaratan afinitas sesi cookie yang dihasilkan terpenuhi.

Untuk menggunakan afinitas cookie yang dihasilkan, konfigurasi mode penyeimbangan dan setelan localityLbPolicy berikut:

• Untuk grup instance backend, gunakan mode load balancing RATE.
• Untuk localityLbPolicy layanan backend, gunakan RING_HASH atau MAGLEV. Jika Anda tidak menetapkan localityLbPolicy secara eksplisit, load balancer akan menggunakan MAGLEV sebagai default tersirat.

Untuk mengetahui informasi selengkapnya, lihat kehilangan afinitas sesi.

Afinitas cookie HTTP

Saat Anda menggunakan afinitas berbasis cookie HTTP (HTTP_COOKIE), load balancer akan menyertakan cookie HTTP di header Set-Cookie sebagai respons terhadap permintaan HTTP awal. Anda menentukan nama, jalur, dan time to live (TTL) untuk cookie.

Semua Load Balancer Aplikasi mendukung afinitas berbasis cookie HTTP.

Anda dapat mengonfigurasi nilai TTL cookie menggunakan detik, pecahan detik (sebagai nanodetik), atau detik dan pecahan detik (sebagai nanodetik) menggunakan parameter layanan backend dan nilai yang valid berikut:

• consistentHash.httpCookie.ttl.seconds dapat ditetapkan ke nilai antara 0 dan 315576000000 (inklusif).
• consistentHash.httpCookie.ttl.nanos dapat ditetapkan ke nilai antara 0 dan 999999999 (inklusif). Karena satuannya adalah nanodetik, 999999999 berarti .999999999 detik.

Jika consistentHash.httpCookie.ttl.seconds dan consistentHash.httpCookie.ttl.nanos tidak ditentukan, nilai parameter layanan backend affinityCookieTtlSec akan digunakan. Jika affinityCookieTtlSec tidak ditentukan, nilai TTL default adalah 0.

Saat klien menyertakan cookie afinitas sesi HTTP di header permintaan Cookie permintaan HTTP, load balancer akan mengarahkan permintaan tersebut ke instance atau endpoint backend yang sama, selama cookie afinitas sesi tetap valid. Hal ini dilakukan dengan memetakan nilai cookie ke indeks yang mereferensikan instance backend atau endpoint tertentu, dan dengan memastikan bahwa persyaratan afinitas sesi cookie yang dihasilkan terpenuhi.

Untuk menggunakan afinitas cookie HTTP, konfigurasikan mode penyeimbangan dan setelan localityLbPolicy berikut:

• Untuk grup instance backend, gunakan mode load balancing RATE.
• Untuk localityLbPolicy layanan backend, gunakan RING_HASH atau MAGLEV. Jika Anda tidak menetapkan localityLbPolicy secara eksplisit, load balancer akan menggunakan MAGLEV sebagai default tersirat.

Untuk mengetahui informasi selengkapnya, lihat kehilangan afinitas sesi.

Afinitas sesi berbasis cookie stateful

Saat Anda menggunakan afinitas berbasis cookie stateful (STRONG_COOKIE_AFFINITY), load balancer akan menyertakan cookie HTTP di header Set-Cookie sebagai respons terhadap permintaan HTTP awal. Anda menentukan nama, jalur, dan time to live (TTL) untuk cookie.

Load balancer berikut mendukung afinitas berbasis cookie stateful:

• Load Balancer Aplikasi eksternal regional
• Load Balancer Aplikasi internal regional

Anda dapat mengonfigurasi nilai TTL cookie menggunakan detik, pecahan detik (sebagai nanodetik), atau detik plus pecahan detik (sebagai nanodetik). Durasi yang diwakili oleh strongSessionAffinityCookie.ttl tidak boleh ditetapkan ke nilai yang mewakili lebih dari dua minggu (1.209.600 detik).

Nilai cookie mengidentifikasi instance atau endpoint backend yang dipilih dengan mengenkode instance atau endpoint yang dipilih dalam nilai itu sendiri. Selama cookie valid, jika klien menyertakan cookie afinitas sesi di header permintaan Cookie dari permintaan HTTP berikutnya, load balancer akan mengarahkan permintaan tersebut ke instance atau endpoint backend yang dipilih.

Tidak seperti metode afinitas sesi lainnya:

• Afinitas berbasis cookie stateful tidak memiliki persyaratan khusus untuk mode penyeimbangan atau untuk kebijakan lokalitas load balancing (localityLbPolicy).

• Afinitas berbasis cookie stateful tidak terpengaruh saat penskalaan otomatis menambahkan instance baru ke grup instance terkelola.

• Afinitas berbasis cookie stateful tidak terpengaruh saat penskalaan otomatis menghapus instance dari grup instance terkelola kecuali instance yang dipilih dihapus.

• Afinitas berbasis cookie stateful tidak terpengaruh saat autohealing menghapus instance dari grup instance terkelola kecuali instance yang dipilih dihapus.

Untuk mengetahui informasi selengkapnya, lihat kehilangan afinitas sesi.

Arti TTL nol untuk afinitas berbasis cookie

Semua afinitas sesi berbasis cookie, seperti afinitas cookie yang dihasilkan, afinitas cookie HTTP, dan afinitas berbasis cookie stateful, memiliki atribut TTL.

TTL nol detik berarti load balancer tidak menetapkan atribut Expires ke cookie. Dalam hal ini, klien memperlakukan cookie sebagai cookie sesi. Definisi sesi bervariasi bergantung pada klien:

• Beberapa klien, seperti browser web, menyimpan cookie selama seluruh sesi penjelajahan. Artinya, cookie tetap ada di beberapa permintaan hingga aplikasi ditutup.

• Klien lain memperlakukan sesi sebagai satu permintaan HTTP, dan langsung menghapus cookie setelahnya.

Kehilangan afinitas sesi

Semua opsi afinitas sesi memerlukan hal berikut:

• Endpoint atau instance backend yang dipilih harus tetap dikonfigurasi sebagai backend. Afinitas sesi dapat terganggu saat salah satu peristiwa berikut terjadi:
  • Anda menghapus instance yang dipilih dari grup instancenya.
  • Penskalaan otomatis atau autohealing grup instance terkelola akan menghapus instance yang dipilih dari grup instance terkelolanya.
  • Anda menghapus endpoint yang dipilih dari NEG-nya.
  • Anda menghapus grup instance atau NEG yang berisi instance atau endpoint yang dipilih dari layanan backend.
• Endpoint atau instance backend yang dipilih harus tetap responsif. Afinitas sesi dapat terganggu saat instance atau endpoint yang dipilih gagal dalam health check.
• Untuk Load Balancer Aplikasi eksternal Global dan Load Balancer Aplikasi Klasik, afinitas sesi dapat terganggu jika Google Front End (GFE) lapisan pertama yang berbeda digunakan untuk permintaan atau koneksi berikutnya setelah perubahan jalur perutean. GFE lapisan pertama yang berbeda mungkin dipilih jika jalur perutean dari klien di internet ke Google berubah di antara permintaan atau koneksi.

Kecuali afinitas sesi berbasis cookie stateful, semua opsi afinitas sesi memiliki persyaratan tambahan berikut:

• Grup instance atau NEG yang berisi instance atau endpoint yang dipilih tidak boleh penuh seperti yang ditentukan oleh kapasitas targetnya. (Untuk grup instance terkelola regional, komponen zonal grup instance yang berisi instance yang dipilih tidak boleh penuh.) Afinitas sesi dapat terganggu saat grup instance atau NEG penuh dan grup instance atau NEG lainnya tidak. Karena kepenuhan dapat berubah dengan cara yang tidak dapat diprediksi saat menggunakan mode penyeimbangan UTILIZATION, Anda harus menggunakan mode penyeimbangan RATE atau CONNECTION untuk meminimalkan situasi saat afinitas sesi dapat terganggu.

• Jumlah total instance atau endpoint backend yang dikonfigurasi harus tetap konstan. Jika setidaknya salah satu peristiwa berikut terjadi, jumlah instance atau endpoint backend yang dikonfigurasi akan berubah, dan afinitas sesi dapat terganggu:

  • Menambahkan instance atau endpoint baru:

    • Anda menambahkan instance ke grup instance yang ada di layanan backend.
    • Penskalaan otomatis grup instance terkelola menambahkan instance ke grup instance terkelola di layanan backend.
    • Anda menambahkan endpoint ke NEG yang ada di layanan backend.
    • Anda menambahkan grup instance atau NEG yang tidak kosong ke layanan backend.

  • Menghapus instance atau endpoint apa pun, bukan hanya instance atau endpoint yang dipilih:

    • Anda menghapus instance apa pun dari backend grup instance.
    • Penskalaan otomatis atau autohealing grup instance terkelola menghapus instance apa pun dari backend grup instance terkelola.
    • Anda menghapus endpoint apa pun dari backend NEG.
    • Anda menghapus grup instance backend atau NEG yang ada dan tidak kosong dari layanan backend.

• Jumlah total instance atau endpoint backend yang responsif harus tetap konstan. Jika setidaknya salah satu peristiwa berikut terjadi, jumlah instance atau endpoint backend yang sehat akan berubah, dan afinitas sesi dapat terganggu:

  • Setiap instance atau endpoint lulus health check-nya, bertransisi dari tidak responsif menjadi responsif.
  • Instance atau endpoint apa pun gagal dalam health check-nya, yang bertransisi dari responsif menjadi tidak responsif atau waktu tunggu habis.