Distribusi permintaan untuk Load Balancer Aplikasi eksternal

Dokumen ini membahas seluk-beluk cara load balancer Aplikasi eksternal menangani koneksi, merutekan traffic, dan mempertahankan afinitas sesi.

Cara kerja koneksi

Load Balancer Aplikasi eksternalGoogle Cloud—global dan regional—menyederhanakan perutean menggunakan proxy terdistribusi (GFE) atau subnet yang dikelola Envoy. Dengan waktu tunggu yang dapat dikonfigurasi, TLS termination, dan keamanan bawaan, load balancer ini memastikan pengiriman aplikasi yang sesuai dan skalabel di seluruh dunia atau secara regional.

Koneksi Load Balancer Aplikasi eksternal global

Load Balancer Aplikasi eksternal global diimplementasikan oleh banyak proxy yang disebut Google Front End (GFE). Tidak hanya ada satu proxy. Di Paket Premium, alamat IP eksternal global yang sama diberitahukan dari berbagai titik kehadiran, dan permintaan klien diarahkan ke GFE terdekat klien.

Bergantung pada lokasi klien Anda, beberapa GFE dapat memulai koneksi HTTP(S) ke backend Anda. Untuk mempelajari lebih lanjut rentang proxy GFE, lihat Aturan firewall.

Catatan: Untuk NEG internet, permintaan dari load balancer berasal dari rentang IP yang berbeda, bergantung pada jenis NEG (global atau regional). Untuk mengetahui informasi selengkapnya, baca bagian Mengautentikasi permintaan.

Bergantung pada konfigurasi layanan backend, protokol yang digunakan oleh setiap GFE untuk terhubung ke backend Anda dapat berupa HTTP, HTTPS, atau HTTP/2. Untuk koneksi HTTP atau HTTPS, versi HTTP yang digunakan adalah HTTP 1.1.

Keepalive HTTP diaktifkan secara default, seperti yang ditentukan dalam spesifikasi HTTP 1.1. Keepalive HTTP berupaya menggunakan sesi TCP yang sama secara efisien; namun, tidak ada jaminan. GFE menggunakan waktu tunggu keepalive HTTP klien selama 610 detik dan nilai waktu tunggu keepalive backend default selama 600 detik. Anda dapat memperbarui waktu tunggu keepalive HTTP klien, tetapi nilai waktu tunggu keepalive backend bersifat tetap. Anda dapat mengonfigurasi waktu tunggu permintaan dan respons dengan menetapkan waktu tunggu layanan backend. Meskipun terkait erat, keepalive HTTP dan waktu tunggu tidak ada aktivitas TCP bukanlah hal yang sama. Untuk mengetahui informasi selengkapnya, lihat waktu tunggu habis dan percobaan ulang.

Untuk memastikan bahwa traffic di-load balance secara merata, load balancer secara berkala menutup koneksi klien yang berjalan lama. Misalnya, koneksi ditutup saat koneksi klien aktif mencapai usia maksimum 60 menit. Jika hal ini terjadi, GFE akan menutup koneksi klien di antara permintaan, baik dengan mengirimkan header respons Connection: close yang diikuti dengan paket FIN ACK (untuk HTTP/1.1) atau dengan mengeluarkan frame GOAWAY HTTP/2 atau HTTP/3 setelah menyelesaikan respons. Perilaku ini tidak mengganggu permintaan atau respons aktif, termasuk koneksi WebSocket yang diupgrade. Mengubah setelan layanan backend, seperti mengupdate penskala kapasitas (backendService.backends[].capacityScaler), akan memengaruhi cara GFE merutekan permintaan baru, tetapi tidak menyebabkan GFE menutup koneksi klien yang ada.

Jumlah koneksi HTTP dan sesi TCP bervariasi, bergantung pada jumlah GFE yang terhubung, jumlah klien yang terhubung ke GFE, protokol ke backend, dan tempat backend di-deploy.

Untuk mengetahui informasi selengkapnya, lihat Cara kerja Load Balancer Aplikasi eksternal dalam panduan solusi: Pengoptimalan Kapasitas Aplikasi dengan Load Balancing Global.

Koneksi Load Balancer Aplikasi eksternal regional

Load Balancer Aplikasi eksternal regional adalah layanan terkelola yang diimplementasikan 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 di jaringan dan region tertentu menggunakan 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-nya adalah HTTP 1.1. Keepalive HTTP diaktifkan secara default, seperti yang ditentukan dalam spesifikasi HTTP 1.1. Proxy Envoy menetapkan waktu tunggu keepalive HTTP klien dan waktu tunggu keepalive backend ke nilai default masing-masing 600 detik. Anda dapat memperbarui waktu tunggu keepalive HTTP klien, tetapi nilai waktu tunggu keepalive backend bersifat tetap. 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.0, HTTP/1.1, HTTP/2, atau HTTP/3.
• Jika HTTPS digunakan, klien modern akan menggunakan HTTP/2 secara default. 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 di setiap mode, lihat Fitur load balancer.

Alamat IP sumber untuk paket klien

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

Untuk Load Balancer Aplikasi eksternal global:

• Koneksi 1, dari klien asli ke load balancer (GFE):

  • 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 (GFE) ke VM atau endpoint backend:

  • Alamat IP sumber: alamat IP di salah satu rentang yang ditentukan dalam Aturan firewall.

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

Catatan: Untuk NEG internet, permintaan dari load balancer berasal dari rentang IP yang berbeda. Untuk mengetahui informasi selengkapnya, baca bagian Mengautentikasi permintaan.

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 digunakan bersama 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 backend atau container di jaringan VPC.

Jalur pemilihan rute khusus

Google Cloud menggunakan rute khusus yang tidak ditentukan dalam 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.

• Antara GFE dan backend Load Balancer Aplikasi eksternal global dan Load Balancer Aplikasi klasik. Untuk mengetahui informasi selengkapnya, lihat Jalur antara Google Front End dan backend.

Google 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, Google 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 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.

Port yang terbuka

GFE memiliki beberapa port terbuka untuk mendukung layanan Google lainnya yang berjalan pada arsitektur yang sama. Saat menjalankan pemindaian port, Anda mungkin melihat port terbuka lainnya untuk layanan Google lain yang berjalan di GFE.

Kedua load balancer berbasis GFE—Load Balancer Aplikasi eksternal global dan Load Balancer Aplikasi klasik—selalu menampilkan port 80 dan 443 sebagai terbuka (bersama dengan port lain yang telah Anda konfigurasi dalam aturan penerusan load balancer). Namun, jika Anda belum mengonfigurasi aturan penerusan untuk port 80 atau port 443, koneksi apa pun yang dikirim ke port tersebut akan ditolak. Sebaliknya, Load Balancer Aplikasi eksternal regional diimplementasikan menggunakan proxy Envoy dan tidak menampilkan port terbuka tambahan selama pemindaian.

Menjalankan pemindaian port pada alamat IP load balancer berbasis GFE tidak berguna dari perspektif audit karena alasan berikut:

• Pemindaian port (misalnya, dengan nmap) umumnya tidak mengharapkan paket respons atau paket TCP RST saat melakukan pemeriksaan TCP SYN. GFE mengirimkan paket SYN-ACK sebagai respons terhadap pemeriksaan SYN hanya untuk port yang telah Anda konfigurasi aturan penerusannya. GFE hanya mengirim paket ke backend Anda sebagai respons terhadap paket yang dikirim ke alamat IP load balancer Anda dan port tujuan yang dikonfigurasi pada aturan penerusannya. Paket yang dikirim ke alamat IP atau port yang berbeda tidak akan dikirim ke backend Anda.

• Paket yang dikirim ke alamat IP load balancer Anda dapat dijawab oleh GFE mana pun dalam fleet Google. Namun, pemindaian kombinasi alamat IP load balancer dan port tujuan hanya akan menginterogasi satu GFE per koneksi TCP. Alamat IP load balancer Anda tidak ditetapkan ke satu perangkat atau sistem. Oleh karena itu, memindai alamat IP load balancer berbasis GFE tidak akan memindai semua GFE di fleet Google.

Dengan mempertimbangkan hal tersebut, berikut adalah beberapa cara yang lebih efektif untuk mengaudit keamanan instance backend Anda:

• Auditor keamanan harus memeriksa konfigurasi aturan penerusan untuk konfigurasi load balancer. Aturan penerusan menentukan port tujuan tempat load balancer Anda menerima paket dan meneruskannya ke backend. Untuk load balancer berbasis GFE, setiap aturan penerusan eksternal hanya dapat mereferensikan satu port TCP tujuan. Untuk load balancer yang menggunakan port TCP 443, port UDP 443 digunakan saat koneksi diupgrade ke QUIC (HTTP/3).

• Auditor keamanan harus memeriksa konfigurasi aturan firewall yang berlaku untuk VM backend. Aturan firewall yang Anda tetapkan memblokir traffic dari GFE ke VM backend, tetapi tidak memblokir traffic masuk ke GFE. Untuk mengetahui praktik terbaik, lihat bagian aturan firewall.

TLS termination

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

Mode load balancer	TLS termination
Load Balancer Aplikasi eksternal global	TLS dihentikan di GFE, yang dapat berada di mana saja di seluruh dunia.
Load Balancer Aplikasi klasik	TLS dihentikan di GFE, yang dapat berada di mana saja di seluruh dunia.
Load Balancer Aplikasi eksternal regional	TLS dihentikan pada proxy Envoy yang terletak 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
		Global	Klasik	Regional
Waktu tunggu layanan backend^1 Waktu tunggu permintaan dan respons. Menunjukkan 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 dihapus.	Untuk NEG serverless di layanan backend: 60 menit Untuk semua jenis backend lainnya di layanan backend: 30 detik Untuk bucket backend: 24 jam (86.400 detik)
Waktu tunggu penyiapan koneksi habis Waktu maksimum yang diizinkan bagi proxy untuk membuat koneksi ke backend. Penyiapan yang berhasil mencakup penyelesaian handshake tiga arah TCP, dan—jika protokol backend-nya adalah HTTPS—menyelesaikan TLS handshake. Untuk Load Balancer Aplikasi eksternal global dan Load Balancer Aplikasi klasik, proxy load balancer adalah GFE lapisan kedua. Untuk Load Balancer Aplikasi eksternal regional, proxy load balancer adalah software Envoy.	4,5 detik
Waktu tunggu TLS klien Jumlah waktu maksimum yang ditunggu proxy load balancer hingga TLS handshake selesai. Untuk Load Balancer Aplikasi eksternal global dan Load Balancer Aplikasi klasik, proxy load balancer adalah GFE lapisan pertama. Untuk Load Balancer Aplikasi eksternal regional, proxy load balancer adalah software Envoy.	10 detik
Waktu tunggu keepalive HTTP klien Durasi maksimum koneksi TCP antara klien dan proxy load balancer dapat tidak aktif. (Koneksi TCP yang sama mungkin digunakan untuk beberapa permintaan HTTP.) Untuk Load Balancer Aplikasi eksternal global dan Load Balancer Aplikasi klasik, proxy load balancer adalah GFE lapisan pertama. Untuk Load Balancer Aplikasi eksternal regional, proxy load balancer adalah software Envoy.	610 detik
Waktu tunggu keepalive HTTP backend Jumlah waktu maksimum koneksi TCP antara proxy load balancer dan backend dapat tidak aktif. (Koneksi TCP yang sama mungkin digunakan untuk beberapa permintaan HTTP.) Untuk Load Balancer Aplikasi eksternal global dan Load Balancer Aplikasi klasik, proxy load balancer adalah GFE lapisan kedua. Untuk Load Balancer Aplikasi eksternal regional, proxy load balancer adalah software Envoy.	Untuk layanan backend: 10 menit (600 detik) Untuk bucket backend: 6 menit (360 detik)
Waktu tunggu tidak ada aktivitas sesi QUIC Durasi maksimum sesi QUIC dapat tidak ada aktivitas antara klien (downstream) dan GFE Load Balancer Aplikasi eksternal global atau Load Balancer Aplikasi klasik.	Untuk Load Balancer Aplikasi eksternal global dan Load Balancer Aplikasi klasik: Waktu tunggu tidak ada aktivitas sesi QUIC adalah nilai minimum dari waktu tunggu tidak ada aktivitas klien atau waktu tunggu tidak ada aktivitas GFE (240 detik). Waktu tunggu tidak ada aktivitas GFE ditetapkan pada 240 detik. Waktu tunggu tidak ada aktivitas klien dapat dikonfigurasi.

¹Tidak dapat dikonfigurasi untuk backend NEG serverless. Tidak dapat dikonfigurasi untuk bucket backend.

Waktu tunggu layanan backend

Waktu tunggu layanan backend yang dapat dikonfigurasi menunjukkan jumlah waktu maksimum yang diperlukan load balancer untuk menunggu backend memproses permintaan HTTP dan menampilkan respons HTTP yang sesuai. Kecuali untuk NEG serverless, 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 setidaknya telah menerima header respons HTTP dari backend, load balancer akan menampilkan header respons lengkap dan isi respons sebanyak mungkin yang dapat diperoleh dalam waktu tunggu layanan backend.

Sebaiknya tetapkan waktu tunggu layanan backend ke durasi waktu terlama yang Anda perkirakan diperlukan 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 waktu tunggu 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. Google Cloud juga tidak menjamin bahwa koneksi TCP yang mendasarinya dapat tetap terbuka selama keseluruhan nilai waktu tunggu layanan backend. Untuk Load Balancer Aplikasi global dan klasik, GFE menerapkan waktu tunggu layanan backend maksimum yang efektif selama 86,400 detik (1 hari). Sistem klien harus menerapkan logika percobaan ulang, bukan mengandalkan koneksi TCP yang terbuka untuk jangka waktu yang lama.

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

Konsol

Ubah kolom Timeout pada layanan backend load balancer.

gcloud

Gunakan perintah gcloud compute backend-services update untuk mengubah parameter --timeout dari resource layanan backend.

API

Untuk Load Balancer Aplikasi eksternal global atau Load Balancer Aplikasi klasik, ubah parameter timeoutSec untuk resource backendServices global.

Untuk Load Balancer Aplikasi eksternal regional, ubah parameter timeoutSec untuk resource regionBackendServices.

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 global	waktu tunggu layanan backend: 30 detik	Koneksi websocket aktif tidak menggunakan waktu tunggu layanan backend yang dikonfigurasi dari load balancer. Koneksi akan otomatis ditutup setelah 24 jam (86.400 detik). Batas 24 jam ini bersifat tetap dan menggantikan waktu tunggu layanan backend jika lebih dari 24 jam. Koneksi websocket yang tidak ada aktivitas akan ditutup setelah waktu tunggu layanan backend habis. Sebaiknya jangan gunakan nilai waktu tunggu layanan backend yang lebih besar dari 24 jam (86.400 detik) karena Google Cloud memulai ulang GFE secara berkala untuk update software dan pemeliharaan rutin lainnya. Nilai waktu tunggu layanan backend Anda tidak menunda aktivitas pemeliharaan. Makin lama nilai waktu tunggu layanan backend, makin besar kemungkinan Google Cloudmenghentikan koneksi TCP untuk pemeliharaan.
Load Balancer Aplikasi klasik	waktu tunggu layanan backend: 30 detik	Koneksi websocket, baik tidak ada aktivitas maupun aktif, akan otomatis ditutup setelah waktu tunggu layanan backend habis. Sebaiknya jangan gunakan nilai waktu tunggu layanan backend yang lebih besar dari 24 jam (86.400 detik) karena Google Cloud memulai ulang GFE secara berkala untuk update software dan pemeliharaan rutin lainnya. Nilai waktu tunggu layanan backend Anda tidak menunda aktivitas pemeliharaan. Makin lama nilai waktu tunggu layanan backend, makin besar kemungkinan Google Cloudmenghentikan koneksi TCP untuk pemeliharaan.
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 ada aktivitas akan ditutup setelah waktu tunggu layanan backend habis. Google Cloud secara berkala memulai ulang atau mengubah jumlah tugas software Envoy yang aktif. Semakin lama nilai waktu tunggu layanan backend, semakin besar kemungkinan tugas Envoy memulai ulang atau menghentikan koneksi TCP.

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

Waktu tunggu keepalive HTTP klien

Waktu tunggu keepalive HTTP klien menunjukkan jumlah waktu maksimum yang dapat digunakan koneksi TCP untuk tidak aktif antara klien (downstream) dan salah satu jenis proxy berikut:

• Untuk Load Balancer Aplikasi eksternal global atau Load Balancer Aplikasi klasik: Google Front End lapisan pertama

• Untuk Load Balancer Aplikasi eksternal regional: proxy Envoy

Waktu tunggu keepalive HTTP klien menunjukkan waktu tunggu tidak ada aktivitas TCP untuk koneksi TCP yang mendasarinya. Waktu tunggu keepalive HTTP klien tidak berlaku untuk websocket.

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

Untuk mengonfigurasi waktu tunggu keepalive HTTP klien, gunakan salah satu metode berikut:

Konsol

Ubah kolom HTTP keepalive timeout pada konfigurasi frontend load balancer.

gcloud

Untuk Load Balancer Aplikasi eksternal global, gunakan perintah gcloud compute target-http-proxies update atau perintah gcloud compute target-https-proxies update untuk mengubah parameter --http-keep-alive-timeout-sec dari proxy HTTP target atau resource proxy HTTPS target.

Untuk Load Balancer Aplikasi eksternal regional, Anda tidak dapat memperbarui parameter waktu tunggu keepalive proxy HTTP(S) target regional secara langsung. Untuk memperbarui parameter waktu tunggu keepalive proxy target regional, Anda harus melakukan hal berikut:

1. Buat proxy target baru dengan setelan waktu tunggu yang diinginkan.
2. Cerminkan semua setelan lain dari proxy target saat ini di proxy target baru. Untuk proxy HTTPS target, hal ini termasuk menautkan sertifikat SSL atau peta sertifikat ke proxy target baru.
3. Perbarui aturan penerusan agar mengarah ke proxy target baru.
4. Hapus proxy target sebelumnya.

API

Untuk Load Balancer Aplikasi eksternal global, ubah parameter httpKeepAliveTimeoutSec untuk resource targetHttpProxies atau resource targetHttpsProxies.

Untuk Load Balancer Aplikasi eksternal regional, Anda tidak dapat memperbarui parameter waktu tunggu keepalive proxy HTTP(S) target regional secara langsung. Untuk memperbarui parameter waktu tunggu keepalive proxy target regional, Anda harus melakukan hal berikut:

1. Buat proxy target baru dengan setelan waktu tunggu yang diinginkan.
2. Cerminkan semua setelan lain dari proxy target saat ini di proxy target baru. Untuk proxy HTTPS target, hal ini termasuk menautkan sertifikat SSL atau peta sertifikat ke proxy target baru.
3. Perbarui aturan penerusan agar mengarah ke proxy target baru.
4. Hapus proxy target sebelumnya.

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

Saat waktu tunggu keepalive HTTP klien berakhir, GFE atau proxy Envoy akan mengirim TCP FIN ke klien untuk menutup koneksi dengan baik.

Waktu tunggu keepalive HTTP backend

Load Balancer Aplikasi Eksternal adalah proxy yang menggunakan setidaknya dua koneksi TCP:

• Untuk Load Balancer Aplikasi eksternal global atau Load Balancer Aplikasi klasik, koneksi TCP pertama ada antara klien (downstream) dan GFE lapisan pertama. GFE lapisan pertama terhubung ke GFE lapisan kedua, lalu GFE lapisan kedua membuka koneksi TCP kedua ke backend Anda.

• 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 keepalive HTTP backend menentukan waktu tunggu tidak ada aktivitas TCP antara load balancer dan backend Anda. Waktu tunggu keepalive HTTP backend tidak berlaku untuk websocket.

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

Waktu tunggu keepalive backend load balancer harus lebih kecil daripada waktu tunggu keepalive yang digunakan oleh software yang berjalan di backend Anda. Hal ini menghindari kondisi race di mana sistem operasi backend Anda mungkin menutup koneksi TCP dengan reset TCP (RST). Karena waktu tunggu keepalive backend untuk load balancer tidak dapat dikonfigurasi, Anda harus mengonfigurasi software backend agar nilai waktu tunggu keepalive HTTP (TCP tidak ada aktivitas) lebih besar dari 600 detik.

Saat waktu tunggu keepalive HTTP backend berakhir, GFE atau proxy Envoy akan mengirim TCP FIN ke VM backend untuk menutup koneksi dengan baik.

Tabel berikut mencantumkan perubahan yang diperlukan untuk mengubah nilai waktu tunggu keepalive 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;

Waktu tunggu tidak ada aktivitas sesi QUIC

Waktu tunggu tidak ada aktivitas sesi QUIC menunjukkan jumlah waktu maksimum yang dapat digunakan sesi QUIC untuk tidak ada aktivitas antara klien dan GFE Load Balancer Aplikasi eksternal global atau Load Balancer Aplikasi klasik.

Nilai waktu tunggu tidak ada aktivitas sesi QUIC ditentukan sebagai nilai minimum dari waktu tunggu tidak ada aktivitas klien atau waktu tunggu tidak ada aktivitas GFE (240 detik). Waktu tunggu tidak ada aktivitas GFE ditetapkan pada 240 detik. Waktu tunggu tidak ada aktivitas klien dapat dikonfigurasi.

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 global	Dapat dikonfigurasi menggunakan kebijakan percobaan ulang di peta URL. Jumlah maksimum percobaan ulang (numRetries) yang dapat dikonfigurasi menggunakan kebijakan percobaan ulang adalah 25. perTryTimeout maksimum yang dapat dikonfigurasi adalah 24 jam. Jika ingin menonaktifkan percobaan ulang, Anda harus menetapkan numRetries ke 1 secara eksplisit. Hal ini karena parameter numRetries menentukan jumlah total upaya maksimum yang dilakukan load balancer untuk mengirim permintaan ke backend. Total ini mencakup permintaan awal ditambah upaya percobaan ulang berikutnya. Jika Anda menetapkan numRetries ke 1 untuk menonaktifkan percobaan ulang, artinya hanya permintaan awal yang dikirim dan tidak ada percobaan ulang tambahan yang dilakukan. Tanpa kebijakan percobaan ulang, permintaan yang gagal dan tidak memiliki isi HTTP (misalnya, permintaan GET) yang menghasilkan respons HTTP 502, 503, atau 504 (retryConditions=["gateway-error"]) akan dicoba ulang sekali. Permintaan POST HTTP tidak dicoba ulang. Permintaan yang dicoba ulang hanya menghasilkan satu entri log untuk respons akhir. Tabel berikut menentukan backend yang mendukung kebijakan percobaan ulang default dan kustom untuk Load Balancer Aplikasi eksternal global. Jenis backend Kebijakan percobaan ulang default Kebijakan percobaan ulang kustom Grup instance NEG Zona NEG Hybrid NEG Private Service Connect NEG Internet NEG Serverless Catatan: Jika kebijakan percobaan ulang kustom (routeAction.retryPolicy) tidak dikonfigurasi, load balancer akan otomatis membuat kebijakan percobaan ulang default. Waktu tunggu pada kebijakan percobaan ulang default sama dengan nilai waktu tunggu pada layanan backend, bukan pada rute. Akibatnya, load balancer akan mengabaikan nilai routeAction.timeout jika tidak ada kebijakan percobaan ulang kustom.
Load Balancer Aplikasi klasik	Kebijakan percobaan ulang tidak dapat diubah untuk percobaan ulang koneksi. Permintaan POST HTTP tidak dicoba ulang. Permintaan HTTP GET selalu dicoba ulang sekali selama 80% atau lebih backend responsif. Jika ada satu backend instance dalam grup dan koneksi ke backend instance tersebut gagal, persentase backend instance yang tidak responsif adalah 100%, sehingga GFE tidak akan mencoba ulang permintaan. Load balancer akan mencoba ulang permintaan GET yang gagal jika permintaan pertama gagal sebelum menerima header respons dari backend instance. Permintaan yang dicoba ulang hanya menghasilkan satu entri log untuk respons akhir. Untuk mengetahui informasi selengkapnya, lihat Logging dan pemantauan Load Balancer Aplikasi eksternal. Permintaan yang gagal akan menyebabkan load balancer menyintesis respons HTTP 502. Tabel berikut menentukan backend yang mendukung kebijakan percobaan ulang untuk Load Balancer Aplikasi Klasik. Jenis backend Kebijakan percobaan ulang default Kebijakan percobaan ulang kustom Grup instance NEG Zona NEG Hybrid NEG Internet NEG Serverless
Load Balancer Aplikasi eksternal regional	Dapat dikonfigurasi menggunakan kebijakan percobaan ulang di peta URL. Jumlah percobaan ulang default (numRetries) adalah 1. Jumlah maksimum percobaan ulang yang dapat dikonfigurasi menggunakan kebijakan percobaan ulang adalah 25. perTryTimeout maksimum yang dapat dikonfigurasi adalah 24 jam. Tanpa kebijakan percobaan ulang, permintaan yang gagal dan tidak memiliki isi HTTP (misalnya, permintaan GET) yang menghasilkan respons HTTP 502, 503, atau 504 akan dicoba ulang sekali. Permintaan POST HTTP tidak dicoba ulang. Permintaan yang dicoba ulang 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, karena sejumlah alasan. Beberapa alasan hanya untuk kepatuhan HTTP/1.1 dan alasan lainnya adalah untuk menghindari data yang tidak terduga diteruskan ke atau dari backend. Tidak ada pemeriksaan yang dapat dinonaktifkan.

Tabel berikut menentukan berbagai jenis permintaan yang diblokir oleh Load Balancer Aplikasi eksternal untuk kepatuhan HTTP/1.1.

Dalam tabel ini, menunjukkan permintaan yang diblokir oleh load balancer, dan menunjukkan permintaan yang diizinkan oleh load balancer.

Jenis permintaan	Load Balancer Aplikasi eksternal global	Load Balancer Aplikasi klasik	Load Balancer Aplikasi eksternal regional
Baris pertama permintaan tidak dapat diurai.
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 dipotong-potong dan tidak ada panjang konten yang ditentukan.		^1
Bagian isi tidak dapat diurai. Ini adalah satu-satunya kasus saat beberapa data mencapai backend. Load balancer menutup koneksi ke klien dan backend saat menerima potongan yang tidak dapat diurai.

¹ Proxy menampilkan respons HTTP 411 untuk permintaan, tetapi kemudian mencoba mengurai isi yang tidak dipotong sebagai permintaan berikutnya. Jika isi yang tidak dipotong itu sendiri adalah permintaan HTTP yang valid, isi tersebut akan diurai dan dikirim ke backend.

Penanganan permintaan

Tabel berikut menentukan Load Balancer Aplikasi eksternal yang memblokir permintaan jika memenuhi salah satu kondisi yang tercantum di kolom pertama tabel.

Dalam tabel ini, menunjukkan permintaan yang diblokir oleh load balancer, dan menunjukkan permintaan yang diizinkan oleh load balancer.

Kondisi	Load Balancer Aplikasi eksternal global	Load Balancer Aplikasi klasik	Load Balancer Aplikasi eksternal regional
Ukuran total header permintaan dan URL permintaan melebihi batas ukuran header permintaan maksimum untuk Load Balancer Aplikasi eksternal.
Metode permintaan tidak mengizinkan isi, tetapi permintaan memiliki isi.
Permintaan berisi header Upgrade, dan header Upgrade tidak digunakan untuk mengaktifkan koneksi WebSocket.
Versi HTTP tidak diketahui.

Penanganan respons

Tabel berikut menentukan Load Balancer Aplikasi eksternal yang memblokir permintaan jika memenuhi salah satu kondisi yang tercantum di kolom pertama tabel.

Dalam tabel ini, menunjukkan permintaan yang diblokir oleh load balancer, dan menunjukkan permintaan yang diizinkan oleh load balancer.

Kondisi	Load Balancer Aplikasi eksternal global	Load Balancer Aplikasi klasik	Load Balancer Aplikasi eksternal regional
Ukuran total header respons melebihi batas ukuran header respons maksimum untuk load balancer.
Versi HTTP tidak diketahui.

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

Distribusi traffic

Saat menambahkan grup backend instance 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 dilampaui 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 global

Sebelum Google Front End (GFE) mengirim permintaan ke backend instance, GFE memperkirakan backend instance mana yang memiliki kapasitas untuk menerima permintaan. Estimasi kapasitas ini dibuat secara proaktif, bukan pada saat permintaan masuk. GFE menerima informasi berkala tentang kapasitas yang tersedia dan mendistribusikan permintaan masuk sebagaimana mestinya.

Arti kapasitas sebagian bergantung pada mode balancing. Untuk mode RATE, prosesnya relatif sederhana: GFE menentukan dengan tepat jumlah permintaan yang dapat ditetapkan per detik. Load balancing berbasis UTILIZATION lebih kompleks: load balancer memeriksa pemakaian instance saat ini, lalu memperkirakan beban kueri yang dapat ditangani setiap instance. Estimasi ini berubah seiring waktu seiring perubahan pemakaian instance dan pola traffic.

Kedua faktor—estimasi kapasitas dan penetapan proaktif—memengaruhi distribusi di antara instance. Dengan demikian, Cloud Load Balancing berperilaku berbeda dari load balancer round-robin sederhana yang menyebarkan permintaan persis 50:50 di antara dua instance. Sebagai gantinya, Google Cloud load balancing mencoba mengoptimalkan pemilihan backend instance untuk setiap permintaan.

Untuk Load Balancer Aplikasi eksternal global, load balancing memiliki dua tingkat. Mode load balancing menentukan bobot atau fraksi traffic yang akan dikirim ke setiap backend (grup instance atau NEG). Kemudian, kebijakan load balancing (LocalityLbPolicy) menentukan cara traffic didistribusikan ke instance atau endpoint dalam grup. Untuk mengetahui informasi selengkapnya, lihat Kebijakan lokalitas load balancing (dokumentasi API layanan backend).

Untuk Load Balancer Aplikasi klasik, mode load balancing digunakan untuk memilih backend yang paling menguntungkan (grup instance atau NEG). Traffic kemudian didistribusikan secara round robin di antara instance atau endpoint dalam backend.

Cara permintaan didistribusikan

Load Balancer Aplikasi eksternal berbasis GFE menggunakan proses berikut untuk mendistribusikan permintaan masuk:

1. Dari klien ke GFE lapisan pertama. Router edge memberitahukan alamat IP eksternal aturan penerusan di batas jaringan Google. Setiap pemberitahuan mencantumkan next hop ke sistem load balancing Lapisan 3 dan Lapisan 4 (Maglev). Sistem Maglev mengarahkan traffic ke Google Front End (GFE) lapisan pertama.
   • Saat menggunakan Paket Premium, Google memberitahukan alamat IP load balancer Anda dari semua titik kehadiran, di seluruh dunia. Setiap alamat IP load balancer adalah anycast global.
   • Saat menggunakan Paket Standar, Google memberitahukan alamat IP load balancer Anda dari titik kehadiran yang terkait dengan region aturan penerusan. Load balancer menggunakan alamat IP eksternal regional. Menggunakan aturan penerusan Paket Standar membatasi Anda pada backend grup instance dan NEG zona di region yang sama dengan aturan penerusan load balancer.
2. Dari GFE lapisan pertama ke GFE lapisan kedua. GFE lapisan pertama menghentikan TLS jika diperlukan, lalu merutekan traffic ke GFE lapisan kedua sesuai dengan proses berikut:
   • GFE lapisan pertama mengurai peta URL dan memilih layanan backend atau bucket backend.
   • Untuk layanan backend dengan NEG internet, GFE lapisan pertama memilih gateway penerusan eksternal lapisan kedua yang ditempatkan bersama GFE lapisan pertama. Gateway penerusan mengirimkan permintaan ke endpoint NEG internet. Langkah ini mengakhiri proses distribusi permintaan untuk NEG internet.
   • Untuk layanan backend dengan NEG serverless dan NEG Private Service Connect (PSC), serta bucket backend satu region, GFE lapisan pertama memilih GFE lapisan kedua di region yang cocok dengan region NEG atau bucket. Untuk bucket Cloud Storage multi-region, GFE lapisan pertama memilih GFE lapisan kedua di region bucket, atau region yang sedekat mungkin dengan bucket multi-region (ditentukan oleh waktu round-trip jaringan).
   • Untuk layanan backend dengan grup instance, NEG zona dengan endpoint GCE_VM_IP_PORT, dan NEG hybrid, sistem pengelolaan kapasitas Google menginformasikan GFE lapisan pertama tentang kapasitas yang digunakan dan dikonfigurasi untuk setiap backend. Kapasitas yang dikonfigurasi untuk backend ditentukan oleh mode balancing, kapasitas target dari mode balancing, dan penskala kapasitas.
     • Paket Standar: GFE lapisan pertama memilih GFE lapisan kedua di region yang berisi backend.
     • Paket Premium: GFE lapisan pertama memilih GFE lapisan kedua dari sekumpulan region yang berlaku. Region yang berlaku adalah semua region tempat backend telah dikonfigurasi, kecuali region dengan backend yang dikonfigurasi yang memiliki kapasitas nol. GFE lapisan pertama memilih GFE lapisan kedua terdekat di region yang berlaku (ditentukan oleh waktu round-trip jaringan). Jika backend dikonfigurasi di dua region atau lebih, GFE lapisan pertama dapat mengalihkan permintaan ke region lain yang berlaku jika region pilihan pertama penuh. Limpahan ke region lain dapat terjadi jika semua backend di region pilihan pertama sudah mencapai kapasitas maksimum.
3. GFE lapisan kedua memilih backend. GFE lapisan kedua terletak di zona suatu region. Mereka menggunakan proses berikut untuk memilih backend:
   • Untuk layanan backend dengan NEG serverless, NEG Private Service Connect, dan bucket backend, GFE lapisan kedua meneruskan permintaan ke sistem produksi Google. Langkah ini mengakhiri proses distribusi permintaan untuk backend ini.

   • Untuk layanan backend dengan grup instance, NEG zona dengan endpoint GCE_VM_IP_PORT, dan NEG hybrid, sistem pemeriksaan health check Google memberi tahu GFE lapisan kedua tentang status health check instance atau endpoint backend.

     Khusus Paket Premium: Jika GFE lapisan kedua tidak memiliki backend instance atau endpoint yang responsif di regionnya, GFE tersebut dapat mengirim permintaan ke GFE lapisan kedua lain di region lain yang berlaku dengan backend yang dikonfigurasi. Spillover antara GFE lapisan kedua di berbagai region tidak menghabiskan semua kemungkinan kombinasi antar-region. Jika Anda perlu mengarahkan traffic dari backend di region tertentu, alih-alih mengonfigurasi backend agar gagal dalam health check, tetapkan penskala kapasitas backend ke nol sehingga GFE lapisan pertama mengecualikan region tersebut selama langkah sebelumnya.

   GFE lapisan kedua kemudian mengarahkan permintaan ke instance backend atau endpoint di zona dalam regionnya seperti yang dibahas pada langkah berikutnya.

4. GFE lapisan kedua memilih zona. Secara default, GFE lapisan kedua menggunakan algoritma WATERFALL_BY_REGION, dengan setiap GFE lapisan kedua lebih memilih untuk memilih backend instance atau endpoint di zona yang sama dengan zona yang berisi GFE lapisan kedua. Karena WATERFALL_BY_REGION meminimalkan traffic antarzona, pada rasio permintaan yang rendah, setiap GFE lapisan kedua mungkin secara eksklusif mengirim permintaan ke backend di zona yang sama dengan GFE lapisan kedua itu sendiri.

   Khusus untuk Load Balancer Aplikasi eksternal global, GFE lapisan kedua dapat dikonfigurasi untuk menggunakan salah satu algoritma alternatif berikut menggunakan serviceLbPolicy:

   • SPRAY_TO_REGION: GFE lapisan kedua tidak lebih memilih memilih backend instance atau endpoint di zona yang sama dengan GFE lapisan kedua. GFE lapisan kedua mencoba mendistribusikan traffic ke semua backend instance atau endpoint di semua zona region. Hal ini dapat menyebabkan distribusi beban yang lebih merata dengan mengorbankan peningkatan traffic antar-zona.
   • WATERFALL_BY_ZONE: GFE lapisan kedua sangat memilih untuk memilih backend instance atau endpoint di zona yang sama dengan GFE lapisan kedua. GFE lapisan kedua hanya mengarahkan permintaan ke backend di zona yang berbeda setelah semua backend di zona saat ini mencapai kapasitas yang dikonfigurasi.
5. GFE lapisan kedua memilih instance atau endpoint dalam zona. Secara default, GFE lapisan kedua mendistribusikan permintaan di antara backend secara round-robin. Khusus untuk Load Balancer Aplikasi eksternal global, Anda dapat mengubahnya menggunakan kebijakan lokalitas load balancing (localityLbPolicy). Kebijakan lokalitas load balancing hanya berlaku untuk backend dalam zona yang dipilih yang dibahas pada langkah sebelumnya.

Load Balancer Aplikasi eksternal regional

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

Mode load balancing 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 akan mengarahkan traffic ke backend (grup instance atau NEG) terlebih dahulu 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 load balancing
• 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 endpoint atau instance backend yang responsif tetap konstan, dan selama endpoint atau instance backend yang dipilih sebelumnya tidak mencapai kapasitas maksimum. Kapasitas target mode balancing menentukan kapan backend mencapai kapasitasnya.

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

Tabel: Setelan afinitas sesi yang didukung

Produk	Opsi afinitas sesi
Load Balancer Aplikasi eksternal global dan 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, nilai default untuk localityLbPolicy adalah MAGLEV. Untuk Load Balancer Aplikasi eksternal global, jangan mengonfigurasi afinitas sesi jika Anda menggunakan pemisahan traffic berbobot. Jika Anda melakukannya, konfigurasi pemisahan traffic berbobot akan diprioritaskan.
Load Balancer Aplikasi Klasik	Tidak ada (NONE) IP Klien (CLIENT_IP) Cookie yang dihasilkan (GENERATED_COOKIE)

Perhatikan hal-hal berikut saat mengonfigurasi afinitas sesi:

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

• Nilai default flag --session-affinity dan --subsetting-policy adalah NONE, dan hanya satu flag yang dapat ditetapkan ke nilai yang berbeda pada 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, asalkan 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 dikirim ke load balancer Google Cloud . Dalam situasi ketika banyak klien menggunakan 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 ke 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 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 dihasilkan selalu berupa garis miring (/), sehingga berlaku untuk semua layanan backend di peta URL yang sama, asalkan layanan backend lainnya juga menggunakan afinitas berbasis cookie.

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 di header permintaan Cookie dari 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 merujuk ke instance backend atau endpoint tertentu, dan dengan memastikan bahwa persyaratan afinitas sesi cookie yang dihasilkan terpenuhi.

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

• Untuk grup backend instance, gunakan mode penyeimbangan 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 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 ditambah 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 defaultnya adalah 0.

Saat klien menyertakan cookie afinitas sesi HTTP di header permintaan Cookie dari permintaan HTTP, load balancer akan mengarahkan permintaan tersebut ke backend instance atau endpoint yang sama, selama cookie afinitas sesi tetap valid. Hal ini dilakukan dengan memetakan nilai cookie ke indeks yang merujuk ke 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 backend instance, gunakan mode penyeimbangan 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 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, kecuali Load Balancer Aplikasi klasik, mendukung afinitas berbasis cookie stateful.

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

Nilai cookie mengidentifikasi backend instance atau endpoint 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 backend instance atau endpoint yang dipilih.

Tidak seperti metode afinitas sesi lainnya:

• Afinitas berbasis cookie stateful tidak memiliki persyaratan khusus untuk mode load balancing atau 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 jika 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 berbasis cookie, 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, mempertahankan cookie selama seluruh sesi penjelajahan. Artinya, cookie akan 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:

• Instance atau endpoint backend yang dipilih harus tetap dikonfigurasi sebagai backend. Afinitas sesi dapat terputus jika salah satu peristiwa berikut terjadi:
  • Anda menghapus instance yang dipilih dari grup instance-nya.
  • Penskalaan otomatis atau autohealing grup instance terkelola akan menghapus instance yang dipilih dari grup instance terkelola.
  • Anda menghapus endpoint yang dipilih dari NEG-nya.
  • Anda menghapus grup instance atau NEG yang berisi instance atau endpoint yang dipilih dari layanan backend.
• Instance atau endpoint backend yang dipilih harus tetap responsif. Afinitas sesi dapat terputus jika 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 untuk 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 zona dari grup instance yang berisi instance yang dipilih tidak boleh penuh.) Afinitas sesi dapat terputus jika grup instance atau NEG penuh, sedangkan grup instance atau NEG lainnya tidak. Karena kepenuhan dapat berubah dengan cara yang tidak dapat diprediksi saat menggunakan mode balancing UTILIZATION, Anda harus menggunakan mode balancing RATE atau CONNECTION untuk meminimalkan situasi saat afinitas sesi dapat rusak.

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

  • 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 akan 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 endpoint atau backend instance yang responsif harus tetap konstan. Jika setidaknya salah satu peristiwa berikut terjadi, jumlah backend instance atau endpoint yang responsif akan berubah, dan afinitas sesi dapat terganggu:

  • Setiap instance atau endpoint lulus health check, bertransisi dari tidak responsif menjadi responsif.
  • Setiap instance atau endpoint gagal dalam health check, bertransisi dari responsif menjadi tidak responsif atau waktu tunggu habis.