Ringkasan layanan backend

Layanan backend menentukan cara Cloud Load Balancing mendistribusikan traffic. Konfigurasi layanan backend berisi kumpulan nilai, seperti protokol yang digunakan untuk terhubung ke backend, berbagai setelan sesi dan distribusi, health check, dan waktu tunggu. Setelan ini memberikan kontrol mendetail terhadap perilaku load balancer Anda. Untuk memulai, sebagian besar setelan memiliki nilai default yang memungkinkan konfigurasi cepat. Cakupan layanan backend bersifat global atau regional.

Load balancer, proxy Envoy, dan klien gRPC tanpa proxy menggunakan informasi konfigurasi di resource layanan backend untuk melakukan hal berikut:

• Arahkan traffic ke backend yang benar, yaitu grup instance atau grup endpoint jaringan (NEG).
• Mendistribusikan traffic sesuai dengan mode balancing, yang merupakan setelan untuk setiap backend.
• Tentukan health check yang memantau kondisi backend.
• Tentukan afinitas sesi.
• Tentukan apakah layanan lain diaktifkan, termasuk layanan berikut yang hanya tersedia untuk load balancer tertentu:
  • Cloud CDN
  • Kebijakan keamanan Google Cloud Armor
  • Identity-Aware Proxy
• Tetapkan layanan backend regional sebagai layanan di App Hub, yang dalam pratinjau.

Anda menetapkan nilai ini saat membuat layanan backend atau menambahkan backend ke layanan backend.

Catatan: Jika Anda menggunakan Load Balancer Aplikasi eksternal global atau Load Balancer Aplikasi klasik, dan backend Anda menayangkan konten statis, sebaiknya gunakan bucket backend, bukan layanan backend. Lihat bucket backend untuk Load Balancer Aplikasi eksternal global atau bucket backend untuk Load Balancer Aplikasi klasik.

Tabel berikut merangkum load balancer yang menggunakan layanan backend. Produk yang Anda gunakan juga menentukan jumlah maksimum layanan backend, cakupan layanan backend, jenis backend yang didukung, dan skema load balancing layanan backend. Skema load balancing adalah ID yang digunakan Google untuk mengklasifikasikan aturan penerusan dan layanan backend. Setiap produk load balancing menggunakan satu skema load balancing untuk aturan penerusan dan layanan backend-nya. Beberapa skema digunakan bersama di antara produk.

Tabel: Layanan backend dan jenis backend yang didukung

Produk	Jumlah maksimum layanan backend	Cakupan layanan backend	Jenis backend yang didukung	Skema load balancing
Load Balancer Aplikasi eksternal global	Beberapa	Global	Setiap layanan backend mendukung salah satu kombinasi backend berikut: Semua backend grup instance: Satu atau beberapa backend grup instance terkelola, tidak terkelola, atau kombinasi dari backend grup instance terkelola dan tidak terkelola ^* Semua NEG zona: Satu atau beberapa NEG zona jenis GCE_VM_IP_PORT^* Semua NEG konektivitas hybrid: Satu atau beberapa NEG jenis NON_GCP_PRIVATE_IP_PORT Kombinasi NEG zona dan hybrid: NEG jenis GCE_VM_IP_PORT dan NON_GCP_PRIVATE_IP_PORT ^† Semua NEG serverless: Satu atau beberapa layanan App Engine, Cloud Run, atau Cloud Functions Satu NEG internet global untuk backend eksternal NEG Private Service Connect: Google API: satu NEG Private Service Connect Layanan terkelola: satu atau beberapa NEG Private Service Connect	EXTERNAL_MANAGED
Load Balancer Aplikasi Klasik	Beberapa	Global^‡	Setiap layanan backend mendukung salah satu kombinasi backend berikut: Semua backend grup instance: Satu atau beberapa backend grup instance terkelola, tidak terkelola, atau kombinasi dari backend grup instance terkelola dan tidak terkelola Semua NEG zona: Satu atau beberapa NEG zona jenis GCE_VM_IP_PORT Semua NEG konektivitas hybrid: Satu atau beberapa NEG jenis NON_GCP_PRIVATE_IP_PORT Kombinasi NEG zona dan hybrid: NEG jenis GCE_VM_IP_PORT dan NON_GCP_PRIVATE_IP_PORT ^† Semua NEG serverless: Satu atau beberapa layanan App Engine, Cloud Run, atau Cloud Functions, atau Satu NEG internet global untuk backend eksternal	EXTERNAL^#
Load Balancer Aplikasi eksternal regional	Beberapa	Regional	Setiap layanan backend mendukung salah satu kombinasi backend berikut: Semua backend grup instance: Satu atau beberapa backend grup instance terkelola, tidak terkelola, atau kombinasi dari backend grup instance terkelola dan tidak terkelola ^* Semua NEG zona: Satu atau beberapa NEG zona jenis GCE_VM_IP_PORT ^* Semua NEG konektivitas hybrid: Satu atau beberapa NEG jenis NON_GCP_PRIVATE_IP_PORT Kombinasi NEG zona dan hybrid: NEG jenis GCE_VM_IP_PORT dan NON_GCP_PRIVATE_IP_PORT ^† Satu NEG serverless (khusus Cloud Run) Satu NEG Private Service Connect Semua NEG internet regional untuk backend eksternal	EXTERNAL_MANAGED
Load Balancer Aplikasi internal lintas region	Beberapa	Global	Setiap layanan backend mendukung salah satu kombinasi backend berikut: Semua backend grup instance: Satu atau beberapa backend grup instance terkelola, tidak terkelola, atau kombinasi dari backend grup instance terkelola dan tidak terkelola ^* Semua NEG zona: Satu atau beberapa NEG zona jenis GCE_VM_IP_PORT ^* Semua NEG konektivitas hybrid: Satu atau beberapa NEG jenis NON_GCP_PRIVATE_IP_PORT Kombinasi NEG zona dan hybrid: NEG jenis GCE_VM_IP_PORT dan NON_GCP_PRIVATE_IP_PORT ^† Satu NEG serverless (khusus Cloud Run) NEG Private Service Connect: Google API: satu NEG Private Service Connect Layanan terkelola: satu atau beberapa NEG Private Service Connect	INTERNAL_MANAGED
Load Balancer Aplikasi internal regional	Beberapa	Regional	Setiap layanan backend mendukung salah satu kombinasi backend berikut: Semua backend grup instance: Satu atau beberapa backend grup instance terkelola, tidak terkelola, atau kombinasi dari backend grup instance terkelola dan tidak terkelola ^* Semua NEG zona: Satu atau beberapa NEG zona jenis GCE_VM_IP_PORT ^* Semua NEG konektivitas hybrid: Satu atau beberapa NEG jenis NON_GCP_PRIVATE_IP_PORT Kombinasi NEG zona dan hybrid: NEG jenis GCE_VM_IP_PORT dan NON_GCP_PRIVATE_IP_PORT ^† Satu NEG serverless (khusus Cloud Run) Satu NEG Private Service Connect Semua NEG internet regional untuk backend eksternal	INTERNAL_MANAGED
Load Balancer Jaringan proxy eksternal global	1	Global^‡	Layanan backend mendukung salah satu kombinasi backend berikut: Semua backend grup instance: Satu atau beberapa backend grup instance terkelola, tidak terkelola, atau kombinasi dari backend grup instance terkelola dan tidak terkelola ^* Semua NEG zona: Satu atau beberapa NEG zona jenis GCE_VM_IP_PORT^* Semua NEG konektivitas hybrid: Satu atau beberapa NEG jenis NON_GCP_PRIVATE_IP_PORT Kombinasi NEG zona dan hybrid: NEG jenis GCE_VM_IP_PORT dan NON_GCP_PRIVATE_IP_PORT ^† NEG Private Service Connect: Google API: satu NEG Private Service Connect Layanan terkelola: satu atau beberapa NEG Private Service Connect	EXTERNAL_MANAGED
Load Balancer Jaringan proxy klasik	1	Global^‡	Layanan backend mendukung salah satu kombinasi backend berikut: Semua backend grup instance: Satu atau beberapa backend grup instance terkelola, tidak terkelola, atau kombinasi dari backend grup instance terkelola dan tidak terkelola Semua NEG zona: Satu atau beberapa NEG zona jenis GCE_VM_IP_PORT Semua NEG konektivitas hybrid: Satu atau beberapa NEG jenis NON_GCP_PRIVATE_IP_PORT Kombinasi NEG zona dan hybrid: NEG jenis GCE_VM_IP_PORT dan NON_GCP_PRIVATE_IP_PORT ^†	EKSTERNAL
Load Balancer Jaringan proxy eksternal regional	1	Regional	Layanan backend mendukung salah satu kombinasi backend berikut: Semua backend grup instance: Satu atau beberapa backend grup instance terkelola, tidak terkelola, atau kombinasi dari backend grup instance terkelola dan tidak terkelola ^* Semua NEG zona: Satu atau beberapa NEG zona jenis GCE_VM_IP_PORT ^* Semua NEG konektivitas hybrid: Satu atau beberapa NEG jenis NON_GCP_PRIVATE_IP_PORT Kombinasi NEG zonal dan hybrid: NEG jenis GCE_VM_IP_PORT dan NON_GCP_PRIVATE_IP_PORT Semua NEG internet regional untuk backend eksternal Satu NEG Private Service Connect	EXTERNAL_MANAGED
Load Balancer Jaringan proxy internal regional	1	Regional	Layanan backend mendukung salah satu kombinasi backend berikut: Semua backend grup instance: Satu atau beberapa backend grup instance terkelola, tidak terkelola, atau kombinasi dari backend grup instance terkelola dan tidak terkelola ^* Semua NEG zona: Satu atau beberapa NEG zona jenis GCE_VM_IP_PORT ^* Semua NEG konektivitas hybrid: Satu atau beberapa NEG jenis NON_GCP_PRIVATE_IP_PORT Kombinasi NEG zonal dan hybrid: NEG jenis GCE_VM_IP_PORT dan NON_GCP_PRIVATE_IP_PORT Semua NEG internet regional untuk backend eksternal Satu NEG Private Service Connect	INTERNAL_MANAGED
Load Balancer Jaringan proxy internal lintas region	Beberapa	Global	Layanan backend mendukung salah satu kombinasi backend berikut: Semua backend grup instance: Satu atau beberapa backend grup instance terkelola, tidak terkelola, atau kombinasi dari backend grup instance terkelola dan tidak terkelola ^* Semua NEG zona: Satu atau beberapa NEG zona jenis GCE_VM_IP_PORT ^* Semua NEG konektivitas hybrid: Satu atau beberapa NEG jenis NON_GCP_PRIVATE_IP_PORT Kombinasi NEG zonal dan hybrid: NEG jenis GCE_VM_IP_PORT dan NON_GCP_PRIVATE_IP_PORT NEG Private Service Connect: Google API: satu NEG Private Service Connect Layanan terkelola: satu atau beberapa NEG Private Service Connect	INTERNAL_MANAGED
Load Balancer Jaringan passthrough eksternal	1	Regional	Layanan backend mendukung salah satu kombinasi backend berikut: Semua backend grup instance: Satu atau beberapa backend grup instance terkelola, tidak terkelola, atau kombinasi dari backend grup instance terkelola dan tidak terkelola Semua NEG zona: Satu atau beberapa NEG zona jenis GCE_VM_IP	EKSTERNAL
Load Balancer Network passthrough internal	1	Regional, tetapi dapat dikonfigurasi agar dapat diakses secara global	Layanan backend mendukung salah satu kombinasi backend berikut: Semua backend grup instance: Satu atau beberapa backend grup instance terkelola, tidak terkelola, atau kombinasi dari backend grup instance terkelola dan tidak terkelola Semua NEG zona: Satu atau beberapa NEG zona jenis GCE_VM_IP Satu NEG pemetaan port	INTERNAL
Mesh Layanan Cloud	Beberapa	Global	Setiap layanan backend mendukung salah satu kombinasi backend berikut: Semua backend grup instance: Satu atau beberapa backend grup instance terkelola, tidak terkelola, atau kombinasi dari backend grup instance terkelola dan tidak terkelola Semua NEG zona: Satu atau beberapa NEG zona jenis GCE_VM_IP_PORT atau NON_GCP_PRIVATE_IP_PORT Satu NEG internet jenis INTERNET_FQDN_PORT Satu atau beberapa binding layanan	INTERNAL_SELF_MANAGED

^* Mendukung grup instance IPv4 dan IPv6 (dual-stack) serta backend NEG zonal. NEG zona mendukung stack ganda hanya pada endpoint jenis GCE_VM_IP_PORT.

^† Untuk deployment GKE, backend NEG campuran hanya didukung dengan NEG mandiri.

^‡ Cakupan layanan backend yang digunakan oleh Load Balancer Aplikasi klasik dan Load Balancer Jaringan proxy klasik selalu bersifat global, baik di Paket Jaringan Standar maupun Premium. Namun, di Paket Standar, batasan berikut berlaku:

• Aturan penerusan dan alamat IP eksternalnya bersifat regional.
• Semua backend yang terhubung ke layanan backend harus berada di region yang sama dengan aturan penerusan.

^# Anda dapat melampirkan layanan backend EXTERNAL_MANAGED ke aturan penerusan EXTERNAL. Namun, layanan backend EXTERNAL tidak dapat dilampirkan ke aturan penerusan EXTERNAL_MANAGED. Untuk memanfaatkan fitur baru yang hanya tersedia dengan Load Balancer Aplikasi eksternal global, sebaiknya migrasikan resource EXTERNAL yang ada ke EXTERNAL_MANAGED menggunakan proses migrasi yang dijelaskan di Memigrasikan resource dari Load Balancer Aplikasi klasik ke Load Balancer Aplikasi eksternal global.

Backend

Backend adalah satu atau beberapa endpoint yang menerima traffic dari load balancer Google Cloud, proxy Envoy yang dikonfigurasi Cloud Service Mesh, atau klien gRPC tanpa proxy. Ada beberapa jenis backend:

• Grup instance yang berisi instance virtual machine (VM). Grup instance dapat berupa grup instance terkelola (MIG), dengan atau tanpa penskalaan otomatis, atau dapat berupa grup instance tidak terkelola. Lebih dari satu layanan backend dapat mereferensikan grup instance, tetapi semua layanan backend yang mereferensikan grup instance harus menggunakan mode penyeimbangan yang sama.
• NEG Zona
• NEG Serverless
• NEG Internet
• NEG dengan konektivitas hybrid
• NEG Private Service Connect
• NEG pemetaan port
• Binding layanan Direktori Layanan

Anda tidak dapat menghapus grup instance backend atau NEG yang terkait dengan layanan backend. Sebelum menghapus grup instance atau NEG, Anda harus menghapusnya terlebih dahulu sebagai backend dari semua layanan backend yang mereferensikannya.

Grup instance

Bagian ini membahas cara kerja grup instance dengan layanan backend.

VM backend dan alamat IP eksternal

VM backend di layanan backend tidak memerlukan alamat IP eksternal:

• Untuk Load Balancer Aplikasi eksternal global dan Load Balancer Jaringan proxy eksternal: Klien berkomunikasi dengan Google Front End (GFE) yang menghosting alamat IP eksternal load balancer Anda. GFE berkomunikasi dengan VM atau endpoint backend dengan mengirimkan paket ke alamat internal yang dibuat dengan menggabungkan ID untuk jaringan VPC backend dengan alamat IPv4 internal backend. Komunikasi antara GFE dan VM atau endpoint backend difasilitasi melalui rute khusus.
  • Untuk backend grup instance, alamat IPv4 internal selalu berupa alamat IPv4 internal utama yang sesuai dengan antarmuka nic0 VM.
  • Untuk endpoint GCE_VM_IP_PORT di NEG zonal, Anda dapat menentukan alamat IP endpoint sebagai alamat IPv4 utama yang terkait dengan antarmuka jaringan VM atau alamat IPv4 dari rentang alamat IP alias yang terkait dengan antarmuka jaringan VM.

• Untuk Load Balancer Aplikasi eksternal regional: Klien berkomunikasi dengan proxy Envoy yang menghosting alamat IP eksternal load balancer Anda. Proksi Envoy berkomunikasi dengan VM atau endpoint backend dengan mengirim paket ke alamat internal yang dibuat dengan menggabungkan ID untuk jaringan VPC backend dengan alamat IPv4 internal backend.

  • Untuk backend grup instance, alamat IPv4 internal selalu berupa alamat IPv4 internal utama yang sesuai dengan antarmuka nic0 VM, dan nic0 harus berada di jaringan yang sama dengan load balancer.
  • Untuk endpoint GCE_VM_IP_PORT di NEG zonal, Anda dapat menentukan alamat IP endpoint sebagai alamat IPv4 utama yang terkait dengan antarmuka jaringan VM atau alamat IPv4 dari rentang alamat IP alias yang terkait dengan antarmuka jaringan VM, selama antarmuka jaringan berada di jaringan yang sama dengan load balancer.

• Untuk Load Balancer Jaringan passthrough eksternal: Klien berkomunikasi langsung dengan backend melalui infrastruktur load balancing passthrough Maglev Google. Paket dirutekan dan dikirim ke backend dengan alamat IP sumber dan tujuan asli yang dipertahankan. Backend merespons klien menggunakan direct server return. Metode yang digunakan untuk memilih backend dan melacak koneksi dapat dikonfigurasi.

  • Untuk backend grup instance, paket selalu dikirim ke antarmuka VM nic0.
  • Untuk endpoint GCE_VM_IP di NEG zonal, paket dikirim ke antarmuka jaringan VM yang berada di subjaringan yang terkait dengan NEG.

Port bernama

Atribut port bernama layanan backend hanya berlaku untuk load balancer berbasis proxy (Load Balancer Aplikasi dan Load Balancer Jaringan Proxy) yang menggunakan backend grup instance. Port yang dinamai menentukan port tujuan yang digunakan untuk koneksi TCP antara proxy (GFE atau Envoy) dan instance backend.

Port bernama dikonfigurasi sebagai berikut:

• Di setiap backend grup instance, Anda harus mengonfigurasi satu atau beberapa port bernama menggunakan pasangan nilai kunci. Kunci mewakili nama port yang bermakna yang Anda pilih, dan nilai mewakili nomor port yang Anda tetapkan ke nama. Pemetaan nama ke angka dilakukan satu per satu untuk setiap backend grup instance.

• Di layanan backend, Anda menentukan satu port bernama hanya menggunakan nama port (--port-name).

Berdasarkan backend per grup instance, layanan backend menerjemahkan nama port menjadi nomor port. Jika port bernama grup instance cocok dengan --port-name layanan backend, layanan backend akan menggunakan nomor port ini untuk komunikasi dengan VM grup instance.

Misalnya, Anda dapat menetapkan port yang bernama pada grup instance dengan nama my-service-name dan port 8888:

gcloud compute instance-groups unmanaged set-named-ports my-unmanaged-ig \
    --named-ports=my-service-name:8888

Kemudian, Anda merujuk ke port bernama di konfigurasi layanan backend dengan --port-name pada layanan backend yang ditetapkan ke my-service-name:

gcloud compute backend-services update my-backend-service \
    --port-name=my-service-name

Layanan backend dapat menggunakan nomor port yang berbeda saat berkomunikasi dengan VM di grup instance yang berbeda jika setiap grup instance menentukan nomor port yang berbeda untuk nama port yang sama.

Nomor port yang di-resolve yang digunakan oleh layanan backend load balancer proxy tidak perlu cocok dengan nomor port yang digunakan oleh aturan penerusan load balancer. Load balancer proxy memproses koneksi TCP yang dikirim ke alamat IP dan port tujuan aturan penerusannya. Karena proxy membuka koneksi TCP kedua ke backend-nya, port tujuan koneksi TCP kedua dapat berbeda.

Port bernama hanya berlaku untuk backend grup instance. NEG zonal dengan endpoint GCE_VM_IP_PORT, NEG campuran dengan endpoint NON_GCP_PRIVATE_IP_PORT, dan NEG internet menentukan port menggunakan mekanisme yang berbeda, yaitu, di endpoint itu sendiri. NEG serverless mereferensikan layanan Google dan NEG PSC mereferensikan lampiran layanan menggunakan abstraksi yang tidak melibatkan penentuan port tujuan.

Load Balancer Jaringan passthrough internal dan Load Balancer Jaringan passthrough eksternal tidak menggunakan port bernama. Hal ini karena load balancer ini adalah load balancer pass-through yang merutekan koneksi langsung ke backend, bukan membuat koneksi baru. Paket dikirim ke backend yang mempertahankan alamat IP dan port tujuan aturan penerusan load balancer.

Untuk mempelajari cara membuat port bernama, lihat petunjuk berikut:

• Grup instance tidak terkelola: Menggunakan port bernama
• Grup instance terkelola: Menetapkan port bernama ke grup instance terkelola

Batasan dan panduan untuk grup instance

Perhatikan batasan dan panduan berikut saat Anda membuat grup instance untuk load balancer:

• Jangan menempatkan VM di lebih dari satu grup instance yang di-load balancing. Jika VM adalah anggota dari dua grup instance tidak terkelola atau lebih, atau anggota dari satu grup instance terkelola dan satu atau beberapa grup instance tidak terkelola, Google Cloud akan membatasi Anda untuk hanya menggunakan salah satu grup instance tersebut pada satu waktu sebagai backend untuk layanan backend tertentu.

  Jika memerlukan VM untuk berpartisipasi dalam beberapa load balancer, Anda harus menggunakan grup instance yang sama sebagai backend di setiap layanan backend.

• Untuk load balancer proxy, saat Anda ingin menyeimbangkan traffic ke port yang berbeda, tentukan port bernama yang diperlukan di satu grup instance dan minta setiap layanan backend berlangganan ke port bernama yang unik.

• Anda dapat menggunakan grup instance yang sama sebagai backend untuk lebih dari satu layanan backend. Dalam situasi ini, backend harus menggunakan mode penyeimbangan yang kompatibel. Kompatibel berarti mode balancing harus sama, atau harus berupa kombinasi dari CONNECTION dan RATE.

  Kombinasi mode balancing yang tidak kompatibel adalah sebagai berikut:

  • CONNECTION dengan UTILIZATION
  • RATE dengan UTILIZATION

  Perhatikan contoh berikut:

  • Anda memiliki dua layanan backend: external-https-backend-service untuk Load Balancer Aplikasi eksternal dan internal-tcp-backend-service untuk Load Balancer Jaringan passthrough internal.
  • Anda menggunakan grup instance yang disebut instance-group-a di internal-tcp-backend-service.
  • Di internal-tcp-backend-service, Anda harus menerapkan mode pengimbangan CONNECTION karena Load Balancer Jaringan passthrough internal hanya mendukung mode pengimbangan CONNECTION.
  • Anda juga dapat menggunakan instance-group-a di external-https-backend-service jika menerapkan mode balancing RATE di external-https-backend-service.
  • Anda juga tidak dapat menggunakan instance-group-a di external-https-backend-service dengan mode balancing UTILIZATION.

• Untuk mengubah mode penyeimbangan bagi grup instance yang berfungsi sebagai backend untuk beberapa layanan backend:

  • Hapus grup instance dari semua layanan backend kecuali satu.
  • Ubah mode penyeimbangan untuk backend di satu layanan backend yang tersisa.
  • Tambahkan kembali grup instance sebagai backend ke layanan backend yang tersisa, jika mendukung mode penyeimbangan baru.

• Jika grup instance Anda dikaitkan dengan beberapa layanan backend, setiap layanan backend dapat mereferensikan port bernama yang sama atau port bernama yang berbeda di grup instance.

• Sebaiknya jangan menambahkan grup instance terkelola yang diskalakan secara otomatis ke lebih dari satu layanan backend. Tindakan ini dapat menyebabkan penskalaan instance yang tidak dapat diprediksi dan tidak perlu dalam grup, terutama jika Anda menggunakan metrik penskalaan otomatis HTTP Load Balancing Utilization.

  • Meskipun tidak direkomendasikan, skenario ini mungkin berfungsi jika metrik penskalaan otomatis adalah Penggunaan CPU atau Metrik Cloud Monitoring yang tidak terkait dengan kapasitas penyaluran load balancer. Menggunakan salah satu metrik penskalaan otomatis ini dapat mencegah penskalaan yang tidak stabil.

Grup endpoint jaringan zona

Endpoint jaringan merepresentasikan layanan berdasarkan alamat IP-nya atau kombinasi alamat IP dan port, bukan merujuk ke VM dalam grup instance. Grup endpoint jaringan (NEG) adalah pengelompokan endpoint jaringan yang logis.

Grup endpoint jaringan zonal (NEG) adalah resource zonal yang mewakili kumpulan alamat IP atau kombinasi alamat IP dan port untuk resource Google Cloud dalam satu subnet.

Layanan backend yang menggunakan NEG zonal sebagai backend-nya mendistribusikan traffic di antara aplikasi atau container yang berjalan dalam VM.

Ada dua jenis endpoint jaringan yang tersedia untuk NEG zonal:

• Endpoint GCE_VM_IP (hanya didukung dengan Load Balancer Jaringan passthrough internal dan Load Balancer Jaringan passthrough eksternal berbasis layanan backend).
• Endpoint GCE_VM_IP_PORT.

Untuk melihat produk yang mendukung backend NEG zonal, lihat Tabel: Layanan backend dan jenis backend yang didukung.

Untuk mengetahui detailnya, lihat Ringkasan NEG zonal.

Grup endpoint jaringan internet

NEG internet adalah resource yang menentukan backend eksternal. Backend eksternal adalah backend yang dihosting dalam infrastruktur lokal atau pada infrastruktur yang disediakan oleh pihak ketiga.

NEG internet adalah kombinasi nama host atau alamat IP, ditambah port opsional. Ada dua jenis endpoint jaringan yang tersedia untuk NEG internet: INTERNET_FQDN_PORT dan INTERNET_IP_PORT.

NEG internet tersedia dalam dua cakupan: global dan regional. Untuk melihat produk mana yang mendukung backend NEG internet di setiap cakupan, lihat Tabel: Layanan backend dan jenis backend yang didukung.

Untuk mengetahui detailnya, lihat Ringkasan grup endpoint jaringan internet.

Grup endpoint jaringan tanpa server

Grup endpoint jaringan (NEG) menentukan grup endpoint backend untuk load balancer. NEG serverless adalah backend yang mengarah ke layanan Cloud Run, App Engine, fungsi Cloud Run, atau API Gateway.

NEG tanpa server dapat mewakili salah satu hal berikut:

• Layanan Cloud Run atau sekelompok layanan.
• Fungsi Cloud Run Functions atau sekelompok fungsi.
• Aplikasi App Engine (Standar atau Fleksibel), layanan tertentu dalam aplikasi, versi aplikasi tertentu, atau grup layanan.
• API Gateway yang menyediakan akses ke layanan Anda melalui REST API yang konsisten di semua layanan, terlepas dari implementasi layanan. Kemampuan ini berada dalam Pratinjau.

Penting: Agar grup layanan berada di NEG tanpa server yang sama, grup layanan tersebut harus memiliki pola URL yang sama.

Untuk menyiapkan NEG serverless bagi aplikasi serverless yang memiliki pola URL yang sama, Anda menggunakan masker URL. Masker URL adalah template skema URL Anda (misalnya, example.com/<service>). NEG tanpa server akan menggunakan template ini untuk mengekstrak nama <service> dari URL permintaan masuk dan merutekan permintaan ke layanan Cloud Run, Cloud Functions, atau App Engine yang cocok dengan nama yang sama.

Untuk melihat load balancer mana yang mendukung backend NEG tanpa server, lihat Tabel: Layanan backend dan jenis backend yang didukung.

Untuk mengetahui informasi selengkapnya tentang NEG tanpa server, lihat Ringkasan grup endpoint jaringan tanpa server.

Pengikatan layanan

Penautan layanan adalah backend yang membuat koneksi antara layanan backend di Cloud Service Mesh dan layanan yang terdaftar di Direktori Layanan. Layanan backend dapat mereferensikan beberapa binding layanan. Layanan backend dengan binding layanan tidak dapat mereferensikan jenis backend lainnya.

Backend campuran

Pertimbangan penggunaan berikut berlaku saat Anda menambahkan berbagai jenis backend ke satu layanan backend:

• Satu layanan backend tidak dapat menggunakan grup instance dan NEG zona secara bersamaan.
• Anda dapat menggunakan kombinasi berbagai jenis grup instance di layanan backend yang sama. Misalnya, satu layanan backend dapat mereferensikan kombinasi grup instance terkelola dan tidak terkelola. Untuk mengetahui informasi lengkap tentang backend mana yang kompatibel dengan layanan backend mana, lihat tabel di bagian sebelumnya.
• Dengan load balancer proxy tertentu, Anda dapat menggunakan kombinasi NEG zona (dengan endpoint GCE_VM_IP_PORT) dan NEG konektivitas hybrid (dengan endpoint NON_GCP_PRIVATE_IP_PORT) untuk mengonfigurasi load balancing hybrid. Untuk melihat load balancer yang memiliki kemampuan ini, lihat Tabel: Layanan backend dan jenis backend yang didukung.

Protokol ke backend

Saat membuat layanan backend, Anda harus menentukan protokol yang digunakan untuk berkomunikasi dengan backend. Anda hanya dapat menentukan satu protokol per layanan backend — Anda tidak dapat menentukan protokol sekunder untuk digunakan sebagai pengganti.

Protokol mana yang valid bergantung pada jenis load balancer atau apakah Anda menggunakan Cloud Service Mesh.

Tabel: Protokol ke backend

Produk	Opsi protokol layanan backend
Load Balancer Aplikasi	HTTP, HTTPS, HTTP/2
Load Balancer Jaringan Proxy	TCP atau SSL Load Balancer Jaringan proxy regional hanya mendukung TCP.
Load Balancer Jaringan Passthrough	TCP, UDP, atau UNSPECIFIED
Mesh Layanan Cloud	HTTP, HTTPS, HTTP/2, gRPC, TCP

Mengubah protokol layanan backend akan membuat backend tidak dapat diakses melalui load balancer selama beberapa menit.

Kebijakan pemilihan alamat IP

Kolom ini berlaku untuk load balancer proxy. Anda harus menggunakan kebijakan pemilihan alamat IP untuk menentukan jenis traffic yang dikirim dari layanan backend ke backend Anda.

Saat Anda memilih kebijakan pemilihan alamat IP, pastikan backend Anda mendukung jenis traffic yang dipilih. Untuk informasi selengkapnya, lihat Tabel: Layanan backend dan jenis backend yang didukung.

Kebijakan pemilihan alamat IP digunakan saat Anda ingin mengonversi layanan backend load balancer untuk mendukung jenis traffic yang berbeda. Untuk mengetahui informasi selengkapnya, lihat Mengonversi dari stack tunggal menjadi stack ganda.

Anda dapat menentukan nilai berikut untuk kebijakan pemilihan alamat IP:

Kebijakan pemilihan alamat IP	Deskripsi
Khusus IPv4	Hanya kirim traffic IPv4 ke backend layanan backend, terlepas dari traffic dari klien ke GFE. Hanya health check IPv4 yang digunakan untuk memeriksa kondisi backend.
Pilih IPv6	Prioritaskan koneksi IPv6 backend daripada koneksi IPv4 (asalkan ada backend yang sehat dengan alamat IPv6). Health check memantau koneksi IPv6 dan IPv4 backend secara berkala. GFE pertama-tama mencoba koneksi IPv6; jika koneksi IPv6 rusak atau lambat, GFE akan menggunakan happy eyeballs untuk kembali dan terhubung ke IPv4. Meskipun salah satu koneksi IPv6 atau IPv4 tidak sehat, backend masih diperlakukan sebagai sehat, dan kedua koneksi dapat dicoba oleh GFE, dengan happy eyeballs yang pada akhirnya memilih koneksi mana yang akan digunakan.
Hanya IPv6	Hanya kirim traffic IPv6 ke backend layanan backend, terlepas dari traffic dari klien ke proxy. Hanya health check IPv6 yang digunakan untuk memeriksa kondisi backend. Tidak ada validasi untuk memeriksa apakah jenis traffic backend cocok dengan kebijakan pemilihan alamat IP. Misalnya, jika Anda memiliki backend khusus IPv4 dan memilih Only IPv6 sebagai kebijakan pemilihan alamat IP, konfigurasi akan menghasilkan backend yang tidak sehat karena traffic gagal menjangkau backend tersebut dan kode respons 503 HTTP ditampilkan ke klien.

Enkripsi antara load balancer dan backend

Untuk mengetahui informasi tentang enkripsi antara load balancer dan backend, lihat Enkripsi ke backend.

Distribusi traffic

Nilai kolom berikut dalam resource layanan backend menentukan beberapa aspek perilaku backend:

• Mode balancing menentukan cara load balancer mengukur kesiapan backend untuk permintaan atau koneksi baru.
• Kapasitas target menentukan target jumlah maksimum koneksi, target kecepatan maksimum, atau target penggunaan CPU maksimum.
• Penghitung skala kapasitas menyesuaikan keseluruhan kapasitas yang tersedia tanpa mengubah kapasitas target.

Balancing mode

Mode balancing menentukan apakah backend load balancer atau Cloud Service Mesh dapat menangani traffic tambahan atau dimuat sepenuhnya.

Google Cloud memiliki tiga mode penyeimbangan:

• CONNECTION: Menentukan cara beban disebarkan berdasarkan jumlah total koneksi yang dapat ditangani backend.
• RATE: Target jumlah maksimum permintaan (kueri) per detik (RPS, QPS). Target RPS/QPS maksimum dapat terlampaui jika semua backend berada pada atau di atas kapasitas.
• UTILIZATION: Menentukan cara beban disebarkan berdasarkan penggunaan instance dalam grup instance.

Mode balancing yang tersedia untuk setiap load balancer

Anda menetapkan mode balancing saat menambahkan backend ke layanan backend. Mode penyeimbangan yang tersedia untuk load balancer bergantung pada jenis load balancer dan jenis backend.

Load Balancer Jaringan passthrough memerlukan mode penyeimbangan CONNECTION, tetapi tidak mendukung penetapan kapasitas target.

Load Balancer Aplikasi mendukung mode balancing RATE atau UTILIZATION untuk backend grup instance, mode balancing RATE untuk NEG zonaonal dengan endpoint GCE_VM_IP_PORT, dan mode balancing RATE untuk NEG hybrid (endpoint NON_GCP_PRIVATE_IP_PORT). Untuk jenis backend lain yang didukung, mode balancing harus dihilangkan.

• Untuk Load Balancer Aplikasi klasik, region dipilih berdasarkan lokasi klien dan apakah region tersebut memiliki kapasitas yang tersedia, berdasarkan kapasitas target mode load balancing. Kemudian, dalam suatu region, kapasitas target mode pengimbangan digunakan untuk menghitung proporsi jumlah permintaan yang harus dikirim ke setiap backend di region tersebut. Permintaan atau koneksi kemudian didistribusikan secara round robin di antara instance atau endpoint dalam backend.

• Untuk Load Balancer Aplikasi eksternal global, region dipilih berdasarkan lokasi klien dan apakah region tersebut memiliki kapasitas yang tersedia, berdasarkan kapasitas target mode load balancing. Dalam region, kapasitas target mode penyeimbangan digunakan untuk menghitung proporsi jumlah permintaan yang harus dikirim ke setiap backend (grup instance atau NEG) di region. Anda dapat menggunakan kebijakan load balancing layanan (serviceLbPolicy) dan setelan backend pilihan untuk memengaruhi pemilihan backend tertentu dalam suatu region. Selain itu, dalam setiap grup instance atau NEG, kebijakan load balancing (LocalityLbPolicy) menentukan cara traffic didistribusikan ke instance atau endpoint dalam grup.

• Untuk Load Balancer Aplikasi internal lintas region, Load Balancer Aplikasi eksternal regional, dan Load Balancer Aplikasi internal regional, kapasitas target mode penyeimbangan digunakan untuk menghitung proporsi jumlah permintaan yang harus dikirim ke setiap backend (grup instance atau NEG) di region. Dalam setiap grup instance atau NEG, kebijakan load balancing (LocalityLbPolicy) menentukan cara traffic didistribusikan ke instance atau endpoint dalam grup. Hanya Load Balancer Aplikasi internal lintas region yang mendukung penggunaan kebijakan load balancing layanan (serviceLbPolicy) dan setelan backend pilihan untuk memengaruhi pemilihan backend tertentu dalam suatu region.

Proxy Network Load Balancer mendukung mode balancing CONNECTION atau UTILIZATION untuk backend grup instance VM, mode balancing CONNECTION untuk NEG zonal dengan endpoint GCE_VM_IP_PORT, dan mode balancing CONNECTION untuk NEG campuran (endpoint NON_GCP_PRIVATE_IP_PORT). Untuk jenis backend lain yang didukung, mode balancing harus dihilangkan.

• Untuk Load Balancer Jaringan proxy eksternal global, region dipilih berdasarkan lokasi klien dan apakah region tersebut memiliki kapasitas yang tersedia, berdasarkan kapasitas target mode load balancing. Dalam region, kapasitas target mode penyeimbangan digunakan untuk menghitung proporsi jumlah permintaan yang harus dikirim ke setiap backend (grup instance atau NEG) di region. Anda dapat menggunakan kebijakan load balancing layanan (serviceLbPolicy) dan setelan backend pilihan untuk memengaruhi pemilihan backend tertentu dalam suatu region. Selain itu, dalam setiap grup instance atau NEG, kebijakan load balancing (LocalityLbPolicy) menentukan cara traffic didistribusikan ke instance atau endpoint dalam grup.

• Untuk Load Balancer Jaringan proxy internal lintas region, region yang dikonfigurasi akan dipilih terlebih dahulu. Dalam region, kapasitas target mode balancing digunakan untuk menghitung proporsi jumlah permintaan yang harus dikirim ke setiap backend (grup instance atau NEG) di region. Anda dapat menggunakan kebijakan load balancing layanan (serviceLbPolicy) dan setelan backend pilihan untuk memengaruhi pemilihan backend tertentu dalam suatu region. Selain itu, dalam setiap grup instance atau NEG, kebijakan load balancing (LocalityLbPolicy) menentukan cara traffic didistribusikan ke instance atau endpoint dalam grup.

• Untuk Load Balancer Jaringan proxy klasik, region dipilih berdasarkan lokasi klien dan apakah region memiliki kapasitas yang tersedia berdasarkan kapasitas target mode load balancing. Kemudian, dalam suatu region, kapasitas target mode load balancing digunakan untuk menghitung proporsi jumlah permintaan atau koneksi yang harus diarahkan ke setiap backend (grup instance atau NEG) di region tersebut. Setelah load balancer memilih backend, permintaan atau koneksi kemudian didistribusikan secara round robin di antara instance VM atau endpoint jaringan dalam setiap backend.

• Untuk Load Balancer Jaringan proxy eksternal regional dan Load Balancer Jaringan proxy internal regional, kapasitas target mode load balancing digunakan untuk menghitung proporsi jumlah permintaan yang harus diarahkan ke setiap backend (grup instance atau NEG). Dalam setiap grup instance atau NEG, kebijakan load balancing (localityLbPolicy) menentukan cara traffic didistribusikan ke instance atau endpoint dalam grup.

Tabel berikut meringkas mode load balancing yang tersedia untuk setiap kombinasi load balancer dan backend.

Tabel: Mode balancing yang tersedia untuk setiap load balancer

Load balancer	Backend	Mode balancing tersedia
Load Balancer Aplikasi	Grup instance	RATE atau UTILIZATION
	NEG Zona (endpoint GCE_VM_IP_PORT)	RATE
	NEG Hybrid (endpoint NON_GCP_PRIVATE_IP_PORT)	RATE
Load Balancer Jaringan Proxy Load Balancer Jaringan proxy eksternal global Load Balancer Jaringan proxy klasik Load Balancer Jaringan proxy eksternal regional Load Balancer Jaringan proxy internal regional Load Balancer Jaringan proxy internal lintas region	Grup instance	CONNECTION atau UTILIZATION
	NEG Zona (endpoint GCE_VM_IP_PORT)	CONNECTION
	NEG Hybrid (endpoint NON_GCP_PRIVATE_IP_PORT)	CONNECTION
Load Balancer Jaringan Passthrough	Grup instance	CONNECTION
	NEG Zona (endpoint GCE_VM_IP)	CONNECTION

Catatan:

Jika Anda mengamati distribusi traffic yang buruk saat menggunakan mode balancing UTILIZATION, sebaiknya gunakan RATE.

Mode balancing UTILIZATION bergantung pada instance VM atau penggunaan CPU beserta faktor lainnya. Saat faktor-faktor ini berfluktuasi, load balancer akan menghitung kapasitas secara tidak efektif, yang sering kali menyebabkan distribusi traffic yang buruk di antara grup backend. Sebaliknya, untuk mode balancing RATE, load balancer mengirimkan permintaan ke grup backend dengan latensi rata-rata terendah selama permintaan terbaru, atau untuk HTTP/2 dan HTTP/3, permintaan dikirim ke grup backend dengan permintaan tertunda paling sedikit.

Jika penggunaan rata-rata semua VM yang terkait dengan layanan backend kurang dari 10%, Google Cloud mungkin lebih memilih zona tertentu. Hal ini dapat terjadi saat Anda menggunakan grup instance terkelola regional, grup instance terkelola zona di zona yang berbeda, dan grup instance tidak terkelola zona. Ketidakseimbangan zona ini akan otomatis teratasi seiring semakin banyak traffic yang dikirim ke load balancer.

Untuk mengetahui informasi selengkapnya, lihat gcloud compute backend-services add-backend.

Kapasitas target

Setiap mode penyeimbangan memiliki kapasitas target yang sesuai, yang menentukan salah satu maksimum target berikut:

• Jumlah koneksi
• Rate
• Pemakaian CPU

Untuk setiap mode penyeimbangan, kapasitas target bukan pemutus arus. Load balancer dapat melebihi batas maksimum dalam kondisi tertentu, misalnya, jika semua VM atau endpoint backend telah mencapai batas maksimum.

Mode balancing koneksi

Untuk mode penyeimbangan CONNECTION, kapasitas target menentukan jumlah maksimum koneksi terbuka target. Kecuali untuk Load Balancer Jaringan passthrough internal dan Load Balancer Jaringan passthrough eksternal, Anda harus menggunakan salah satu setelan berikut untuk menentukan target jumlah maksimum koneksi:

• max-connections-per-instance (per VM): Target jumlah koneksi rata-rata untuk satu VM.
• max-connections-per-endpoint (per endpoint dalam NEG zonal): Target jumlah koneksi rata-rata untuk satu endpoint.
• max-connections (per NEG zonal dan untuk grup instance zonal): Target jumlah koneksi rata-rata untuk seluruh NEG atau grup instance. Untuk grup instance terkelola regional, gunakan max-connections-per-instance.

Tabel berikut menunjukkan cara parameter kapasitas target menentukan hal berikut:

• Kapasitas target untuk seluruh backend
• Kapasitas target yang diharapkan untuk setiap instance atau endpoint

Tabel: Kapasitas target untuk backend yang menggunakan mode balancing KONEKSI

Jenis backend	Kapasitas target
	Jika Anda menentukan	Kapasitas backend secara keseluruhan	Kapasitas per instance atau per endpoint yang diharapkan
Grup instance N instance, H sehat	max-connections-per-instance=X	X × N	(X × N)/H
Endpoint NEG zona N, H responsif	max-connections-per-endpoint=X	X × N	(X × N)/H
Grup instance (kecuali grup instance terkelola regional) H instance yang sehat	max-connections=Y	Y	Y/H

Seperti yang diilustrasikan, setelan max-connections-per-instance dan max-connections-per-endpoint adalah proxy untuk menghitung target jumlah maksimum koneksi untuk seluruh grup instance VM atau seluruh NEG zona:

• Dalam grup instance VM dengan instance N, setelan max-connections-per-instance=X memiliki arti yang sama dengan setelan max-connections=X × N.
• Dalam NEG zonal dengan endpoint N, setelan max-connections-per-endpoint=X memiliki arti yang sama dengan setelan max-connections=X × N.

Mode balancing kapasitas

Untuk mode penyeimbangan RATE, Anda harus menentukan kapasitas target menggunakan salah satu parameter berikut:

• max-rate-per-instance (per VM): Berikan target rata-rata kecepatan permintaan HTTP untuk satu VM.
• max-rate-per-endpoint (per endpoint dalam NEG zonal): Memberikan target rata-rata kapasitas permintaan HTTP untuk satu endpoint.
• max-rate (per NEG zona dan untuk grup instance zona): Berikan target rasio permintaan HTTP rata-rata untuk seluruh NEG atau grup instance. Untuk grup instance terkelola regional, gunakan max-rate-per-instance.

Tabel berikut menunjukkan cara parameter kapasitas target menentukan hal berikut:

• Kapasitas target untuk seluruh backend
• Kapasitas target yang diharapkan untuk setiap instance atau endpoint

Tabel: Kapasitas target untuk backend yang menggunakan mode balancing RATE

Jenis backend	Kapasitas target
	Jika Anda menentukan	Kapasitas backend secara keseluruhan	Kapasitas per instance atau per endpoint yang diharapkan
Grup instance N instance, H sehat	max-rate-per-instance=X	X × N	(X × N)/H
endpoint NEG zona N, H responsif	max-rate-per-endpoint=X	X × N	(X × N)/H
Grup instance (kecuali grup instance terkelola regional) H instance yang sehat	max-rate=Y	Y	Y/H

Seperti yang diilustrasikan, setelan max-rate-per-instance dan max-rate-per-endpoint adalah proxy untuk menghitung target rasio maksimum permintaan HTTP untuk seluruh grup instance atau seluruh NEG zona:

• Dalam grup instance dengan instance N, setelan max-rate-per-instance=X memiliki arti yang sama dengan setelan max-rate=X × N.
• Dalam NEG zonal dengan endpoint N, setelan max-rate-per-endpoint=X memiliki makna yang sama dengan setelan max-rate=X × N.

Mode balancing penggunaan

Mode balancing UTILIZATION tidak memiliki kapasitas target wajib. Anda memiliki beberapa opsi yang bergantung pada jenis backend, seperti yang dirangkum dalam tabel di bagian berikut.

Kapasitas target max-utilization hanya dapat ditentukan per grup instance dan tidak dapat diterapkan ke VM tertentu dalam grup.

Mode balancing UTILIZATION tidak memiliki kapasitas target wajib. Saat Anda menggunakan konsol Google Cloud untuk menambahkan grup instance backend ke layanan backend, konsol Google Cloud akan menetapkan nilai max-utilization ke 0,8 (80%) jika mode penyeimbangan UTILIZATION dipilih. Selain max-utilization, mode penyeimbangan UTILIZATION mendukung kapasitas target yang lebih kompleks, seperti dirangkum dalam tabel di bagian berikut.

Mengubah mode balancing load balancer

Untuk beberapa load balancer atau konfigurasi load balancer, Anda tidak dapat mengubah mode penyeimbangan karena layanan backend hanya memiliki satu kemungkinan mode penyeimbangan. Untuk yang lainnya, bergantung pada backend yang digunakan, Anda dapat mengubah mode balancing karena lebih dari satu mode tersedia untuk layanan backend tersebut.

Untuk melihat mode penyeimbangan yang didukung untuk setiap load balancer, lihat Tabel: Mode penyeimbangan yang tersedia untuk setiap load balancer

Setelan mode penyeimbangan dan kapasitas target

Untuk produk yang mendukung spesifikasi kapasitas target, kapasitas target bukan pemutus arus. Jika kapasitas maksimum target yang dikonfigurasi tercapai di zona tertentu, permintaan atau koneksi baru akan didistribusikan ke zona lain yang tidak memproses permintaan atau koneksi pada kapasitas target. Jika semua zona telah mencapai kapasitas target, permintaan atau koneksi baru akan didistribusikan dengan cara melampaui kapasitas.

Load Balancer Aplikasi dan Cloud Service Mesh

Tabel ini mencantumkan kombinasi mode penyeimbangan dan kapasitas target yang tersedia untuk Application Load Balancer dan Cloud Service Mesh.

Tabel: Kombinasi mode penyeimbangan dan kapasitas target untuk Load Balancer Aplikasi dan Cloud Service Mesh

Jenis backend	Balancing mode	Spesifikasi kapasitas target
Grup instance zonal yang tidak dikelola zonal terkelola dikelola secara regional	RATE	Anda harus menentukan salah satu dari hal berikut: max-rate  (hanya didukung oleh grup instance zona) max-rate-per-instance  (didukung oleh semua grup instance)
	UTILIZATION	Anda dapat secara opsional menentukan salah satu dari hal berikut: (1) max-utilization (2) max-rate  (hanya didukung oleh grup instance zona) (3) max-rate-per-instance  (didukung oleh semua grup instance) (1) dan (2) bersama-sama (1) dan (3) secara bersamaan
NEG Zona GCP_VM_IP_PORT NEG Hybrid NON_GCP_PRIVATE_IP_PORT	RATE	Anda harus menentukan salah satu dari hal berikut: max-rate per NEG zona max-rate-per-endpoint

Load Balancer Jaringan Proxy

Tabel ini mencantumkan mode penyeimbangan dan kombinasi kapasitas target yang tersedia untuk Load Balancer Jaringan Proxy.

Tabel: Kombinasi mode balancing dan kapasitas target untuk Load Balancer Jaringan Proxy

Jenis backend	Balancing mode	Spesifikasi kapasitas target
Grup instance zonal yang tidak dikelola zonal terkelola dikelola secara regional	CONNECTION	Anda harus menentukan salah satu dari hal berikut: max-connections  (hanya didukung oleh grup instance zona) max-rate-per-instance  (didukung oleh semua grup instance)
	UTILIZATION	Anda dapat secara opsional menentukan salah satu dari hal berikut: (1) max-utilization (2) max-connections  (hanya didukung oleh grup instance zona) (3) max-connections-per-instance  (didukung oleh semua grup instance) (1) dan (2) bersama-sama (1) dan (3) secara bersamaan
NEG Zona GCP_VM_IP_PORT NEG Hybrid NON_GCP_PRIVATE_IP_PORT	CONNECTION	Anda harus menentukan salah satu dari hal berikut: max-connections per NEG zona max-connections-per-endpoint

Load Balancer Jaringan Passthrough

Tabel ini mencantumkan kombinasi mode balancing dan kapasitas target yang tersedia untuk Load Balancer Jaringan Passthrough.

Tabel: Kombinasi mode balancing dan kapasitas target untuk Load Balancer Jaringan Passthrough

Jenis backend	Balancing mode	Spesifikasi kapasitas target
Grup instance zonal yang tidak dikelola zonal terkelola dikelola secara regional	CONNECTION	Anda tidak dapat menentukan target jumlah maksimum koneksi.
NEG Zona GCP_VM_IP	CONNECTION	Anda tidak dapat menentukan target jumlah maksimum koneksi.

Pengatur kapasitas

Gunakan penskala kapasitas untuk menskalakan kapasitas target (pemanfaatan maksimum, kecepatan maksimum, atau koneksi maksimum) tanpa mengubah kapasitas target.

Untuk dokumentasi referensi Google Cloud, lihat hal berikut:

• Google Cloud CLI: capacity-scaler
• API:
  • Regional
  • Global

Anda dapat menyesuaikan scaler kapasitas untuk menskalakan kapasitas target yang efektif tanpa mengubah salah satu parameter --max-* secara eksplisit.

Anda dapat menetapkan pengskala kapasitas ke salah satu nilai berikut:

• Nilai defaultnya adalah 1, yang berarti grup menayangkan hingga 100% kapasitas yang dikonfigurasi (bergantung pada balancingMode).
• Nilai 0 berarti grup benar-benar habis, menawarkan 0% dari kapasitas yang tersedia. Anda tidak dapat mengonfigurasi setelan 0 jika hanya ada satu backend yang terpasang ke layanan backend.
• Nilai dari 0.1 (10%) hingga 1.0 (100%).

Contoh berikut menunjukkan cara kerja penskala kapasitas bersama dengan setelan kapasitas target:

• Jika mode balancing adalah RATE, max-rate ditetapkan ke 80 RPS, dan scaler kapasitas adalah 1.0, kapasitas yang tersedia juga 80 RPS.

• Jika mode balancing adalah RATE, max-rate ditetapkan ke 80 RPS, dan penskala kapasitas adalah 0.5, kapasitas yang tersedia adalah 40 RPS (0.5 times 80).

• Jika mode balancing adalah RATE, max-rate ditetapkan ke 80 RPS, dan scaler kapasitas adalah 0.0, kapasitas yang tersedia adalah nol (0).

Catatan: Pengatur kapasitas tidak didukung untuk backend yang tidak mendukung mode penyeimbangan. Hal ini mencakup backend seperti NEG internet, NEG serverless, dan NEG PSC.

Kebijakan load balancing layanan

Kebijakan load balancing layanan (serviceLbPolicy) adalah resource yang terkait dengan layanan backend load balancer. Dengan kebijakan ini, Anda dapat menyesuaikan parameter yang memengaruhi cara traffic didistribusikan dalam backend yang terkait dengan layanan backend:

• Menyesuaikan algoritma load balancing yang digunakan untuk menentukan cara traffic didistribusikan di antara region atau zona.
• Aktifkan pengosongan kapasitas otomatis sehingga load balancer dapat dengan cepat menghabiskan traffic dari backend yang tidak sehat.

Selain itu, Anda dapat menetapkan backend tertentu sebagai backend pilihan. Backend ini harus digunakan sesuai kapasitas (yaitu, kapasitas target yang ditentukan oleh mode penyeimbangan backend) sebelum permintaan dikirim ke backend yang tersisa.

Untuk mempelajari lebih lanjut, lihat Pengoptimalan load balancing lanjutan dengan kebijakan load balancing layanan.

Kebijakan lokalitas load balancing

Untuk layanan backend, distribusi traffic didasarkan pada mode penyeimbangan dan kebijakan lokalitas load balancing. Mode penyeimbangan menentukan fraksi traffic yang harus dikirim ke setiap backend (grup instance atau NEG). Kebijakan lokalitas load balancing kemudian (LocalityLbPolicy) menentukan cara traffic didistribusikan di seluruh instance atau endpoint dalam setiap zona. Untuk grup instance terkelola regional, kebijakan lokalitas berlaku untuk setiap zona penyusun.

Kebijakan lokalitas load balancing dikonfigurasi per layanan backend. Setelan berikut tersedia:

• ROUND_ROBIN (default): Ini adalah setelan kebijakan lokalitas load balancing default tempat load balancer memilih backend yang sehat dalam urutan round robin.

• LEAST_REQUEST: Algoritme O(1) yang digunakan load balancer untuk memilih dua host sehat secara acak dan memilih host yang memiliki lebih sedikit permintaan aktif.

• RING_HASH: Algoritma ini menerapkan hashing yang konsisten ke backend. Algoritma ini memiliki properti bahwa penambahan atau penghapusan host dari kumpulan host N hanya memengaruhi 1/N permintaan.

• RANDOM: Load balancer memilih host sehat secara acak.

• ORIGINAL_DESTINATION: Load balancer memilih backend berdasarkan metadata koneksi klien. Koneksi dibuka ke alamat IP tujuan awal yang ditentukan dalam permintaan klien yang masuk, sebelum permintaan dialihkan ke load balancer.

  ORIGINAL_DESTINATION tidak didukung untuk Load Balancer Aplikasi eksternal global dan regional.

• MAGLEV: Mengimplementasikan hashing yang konsisten ke backend dan dapat digunakan sebagai pengganti kebijakan RING_HASH. Maglev tidak sestabil RING_HASH, tetapi memiliki waktu pembuatan pencarian tabel dan waktu pemilihan host yang lebih cepat. Untuk informasi selengkapnya tentang Maglev, lihat whitepaper Maglev.

• WEIGHTED_MAGLEV: Menerapkan load balancing berbobot per instance menggunakan bobot yang dilaporkan oleh health check. Jika kebijakan ini digunakan, layanan backend harus mengonfigurasi health check berbasis HTTP non-lama, dan balasan health check diharapkan berisi kolom header respons HTTP non-standar, X-Load-Balancing-Endpoint-Weight, untuk menentukan bobot per instance. Keputusan load balancing dibuat berdasarkan bobot per instance yang dilaporkan dalam balasan health check yang terakhir diproses, selama setiap instance melaporkan bobot yang valid atau melaporkan UNAVAILABLE_WEIGHT. Jika tidak, load balancing akan tetap berbobot sama.

  WEIGHTED_MAGLEV hanya didukung untuk Load Balancer Jaringan passthrough Eksternal. Sebagai contoh, lihat Menyiapkan load balancing berbobot untuk Load Balancer Jaringan passthrough eksternal.

Mengonfigurasi kebijakan lokalitas load balancing hanya didukung di layanan backend yang digunakan dengan load balancer berikut:

• Load Balancer Aplikasi eksternal global
• Load Balancer Aplikasi eksternal regional
• Load Balancer Aplikasi internal lintas region
• Load Balancer Aplikasi internal regional
• Load Balancer Jaringan passthrough eksternal

Perhatikan bahwa nilai default yang efektif dari 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—nilai default untuk localityLbPolicy adalah ROUND_ROBIN. Jika afinitas sesi ditetapkan ke nilai selain NONE, nilai default untuk localityLbPolicy adalah MAGLEV.

Untuk mengonfigurasi kebijakan lokalitas load balancing, Anda dapat menggunakan konsol Google Cloud, gcloud (--locality-lb-policy), atau API (localityLbPolicy).

Cloud Service Mesh dan distribusi traffic

Cloud Service Mesh juga menggunakan resource layanan backend. Secara khusus, Cloud Service Mesh menggunakan layanan backend yang skema load balancing-nya adalah INTERNAL_SELF_MANAGED. Untuk layanan backend internal yang dikelola sendiri, distribusi traffic didasarkan pada kombinasi mode load balancing dan kebijakan load balancing. Layanan backend mengarahkan traffic ke backend sesuai dengan mode balancing backend. Kemudian, Cloud Service Mesh mendistribusikan traffic sesuai dengan kebijakan load balancing.

Layanan backend internal yang dikelola sendiri mendukung mode penyeimbangan berikut:

• UTILIZATION, jika semua backend adalah grup instance
• RATE, jika semua backend adalah grup instance atau NEG zona

Jika memilih mode balancing RATE, Anda harus menentukan kapasitas maksimum, kapasitas maksimum per instance, atau kapasitas maksimum per endpoint.

Untuk mengetahui informasi selengkapnya tentang Cloud Service Mesh, lihat Konsep Cloud Service Mesh.

Sub-setelan backend

Subset backend adalah fitur opsional yang meningkatkan performa dan skalabilitas dengan menetapkan subset backend ke setiap instance proxy.

Subset backend didukung untuk hal berikut:

• Load Balancer Aplikasi internal regional
• Load Balancer Network passthrough internal

Subset backend untuk Load Balancer Aplikasi internal regional

Pratinjau

Produk atau fitur ini tunduk pada "Persyaratan Penawaran Pra-GA" di bagian Persyaratan Layanan Umum di Persyaratan Khusus Layanan. Produk dan fitur pra-GA tersedia "sebagaimana adanya" dan mungkin memiliki dukungan terbatas. Untuk mengetahui informasi selengkapnya, lihat deskripsi tahap peluncuran.

Load Balancer Aplikasi internal lintas region tidak mendukung subsetting backend.

Untuk Load Balancer Aplikasi internal regional, subkumpulan backend secara otomatis hanya menetapkan subkumpulan backend dalam layanan backend regional ke setiap instance proxy. Secara default, setiap instance proxy membuka koneksi ke semua backend dalam layanan backend. Jika jumlah instance proxy dan backend besar, membuka koneksi ke semua backend dapat menyebabkan masalah performa.

Dengan mengaktifkan subkumpulan, setiap proxy hanya membuka koneksi ke subkumpulan backend, sehingga mengurangi jumlah koneksi yang tetap terbuka ke setiap backend. Mengurangi jumlah koneksi yang terbuka secara bersamaan ke setiap backend dapat meningkatkan performa untuk backend dan proxy.

Diagram berikut menunjukkan load balancer dengan dua proxy. Tanpa subkumpulan backend, traffic dari kedua proxy didistribusikan ke semua backend di layanan backend 1. Dengan subkumpulan backend yang diaktifkan, traffic dari setiap proxy akan didistribusikan ke sebagian backend. Traffic dari proxy 1 didistribusikan ke backend 1 dan 2, dan traffic dari proxy 2 didistribusikan ke backend 3 dan 4.

Membandingkan Load Balancer Aplikasi internal tanpa dan dengan subkumpulan backend (klik untuk memperbesar).

Anda juga dapat menyaring traffic load balancing ke backend dengan menetapkan kebijakan localityLbPolicy. Untuk informasi selengkapnya, lihat Kebijakan traffic.

Untuk membaca cara menyiapkan subset backend untuk Load Balancer Aplikasi internal, lihat Mengonfigurasi subset backend.

Batasan terkait subkumpulan backend untuk Load Balancer Aplikasi internal

• Meskipun subkumpulan backend dirancang untuk memastikan bahwa semua instance backend tetap digunakan dengan baik, hal ini dapat menyebabkan beberapa bias dalam jumlah traffic yang diterima setiap backend. Menetapkan localityLbPolicy ke LEAST_REQUEST direkomendasikan untuk layanan backend yang sensitif terhadap keseimbangan beban backend.
• Mengaktifkan atau menonaktifkan subkumpulan akan memutuskan koneksi yang ada.
• Subsetelan backend mengharuskan afinitas sesi adalah NONE (hash 5 tuple). Opsi afinitas sesi lainnya hanya dapat digunakan jika subkumpulan backend dinonaktifkan. Nilai default flag --subsetting-policy dan --session-affinity adalah NONE, dan hanya satu flag saja yang dapat ditetapkan ke nilai yang berbeda.

Subsetelan backend untuk Load Balancer Jaringan passthrough internal

Subset backend untuk Load Balancer Jaringan passthrough internal memungkinkan Anda menskalakan Load Balancer Jaringan passthrough internal untuk mendukung lebih banyak instance VM backend per layanan backend internal.

Untuk mengetahui informasi tentang pengaruh subkumpulan terhadap batas ini, lihat bagian"Layanan backend" di Kuota dan batas resource load balancing.

Secara default, subkumpulan dinonaktifkan, yang membatasi layanan backend untuk mendistribusikan hingga 250 instance atau endpoint backend. Jika layanan backend Anda perlu mendukung lebih dari 250 backend, Anda dapat mengaktifkan subsetelan. Jika subset diaktifkan, subset instance backend akan dipilih untuk setiap koneksi klien.

Diagram berikut menunjukkan model yang diperkecil dari perbedaan antara dua mode operasi ini.

Membandingkan Load Balancer Jaringan passthrough internal tanpa dan dengan subsetelan (klik untuk memperbesar).

Tanpa subkumpulan, kumpulan lengkap backend yang sehat akan lebih dimanfaatkan, dan koneksi klien baru didistribusikan di antara semua backend yang sehat sesuai dengan distribusi traffic. Subset memberlakukan batasan load balancing, tetapi memungkinkan load balancer mendukung lebih dari 250 backend.

Untuk petunjuk konfigurasi, lihat Pembuatan subkumpulan.

Batasan terkait subsetelan backend untuk Load Balancer Jaringan passthrough internal

• Jika subkumpulan diaktifkan, tidak semua backend akan menerima traffic dari pengirim tertentu meskipun jumlah backend kecil.
• Untuk mengetahui jumlah maksimum instance backend saat subkumpulan diaktifkan, lihat halaman kuota .
• Hanya afinitas sesi 5-tuple yang didukung dengan subkumpulan.
• Duplikasi Paket tidak didukung dengan subkumpulan.
• Mengaktifkan atau menonaktifkan subkumpulan akan memutuskan koneksi yang ada.
• Jika klien lokal perlu mengakses Load Balancer Jaringan passthrough internal, subkumpulan dapat secara substansial mengurangi jumlah backend yang menerima koneksi dari klien lokal Anda. Hal ini karena region tunnel Cloud VPN atau lampiran VLAN Cloud Interconnect menentukan subset backend load balancer. Semua endpoint Cloud VPN dan Cloud Interconnect di region tertentu menggunakan subset yang sama. Subset yang berbeda digunakan di berbagai region.

Harga sub-setelan backend

Penggunaan subkumpulan backend tidak dikenai biaya. Untuk informasi selengkapnya, lihat Semua harga jaringan.

Afinitas sesi

Afinitas sesi memungkinkan Anda mengontrol cara load balancer memilih backend untuk koneksi baru dengan cara yang dapat diprediksi selama jumlah backend yang sehat tetap konstan. Hal ini berguna untuk aplikasi yang memerlukan beberapa permintaan dari pengguna tertentu untuk diarahkan ke backend atau endpoint yang sama. Aplikasi tersebut biasanya menyertakan server stateful yang digunakan oleh penayangan iklan, game, atau layanan dengan cache internal yang berat.

Load balancer Google Cloud memberikan afinitas sesi berdasarkan upaya terbaik. Faktor seperti mengubah status health check backend, menambahkan atau menghapus backend, perubahan bobot backend (termasuk mengaktifkan atau menonaktifkan pengimbangan berbobot), atau perubahan pada kelengkapan backend, seperti yang diukur oleh mode pengimbangan, dapat merusak afinitas sesi.

Load balancing dengan afinitas sesi berfungsi dengan baik jika ada distribusi koneksi unik yang cukup besar. Cukup besar berarti setidaknya beberapa kali jumlah backend. Menguji load balancer dengan sejumlah kecil koneksi tidak akan menghasilkan representasi yang akurat tentang distribusi koneksi klien di antara backend.

Secara default, semua load balancer Google Cloud memilih backend menggunakan hash lima tuple (--session-affinity=NONE), sebagai berikut:

• Alamat IP sumber paket
• Port sumber paket (jika ada di header paket)
• Alamat IP tujuan paket
• Port tujuan paket (jika ada di header paket)
• Protokol paket

Untuk load balancer pass-through, koneksi baru didistribusikan ke instance atau endpoint backend yang responsif (di kumpulan aktif, jika kebijakan failover dikonfigurasi). Anda dapat mengontrol hal berikut:

• Apakah koneksi yang dibuat tetap ada di backend yang bermasalah. Untuk mengetahui detailnya, lihat Persistensi koneksi pada backend yang tidak sehat dalam dokumentasi Load Balancer Jaringan passthrough internal dan Persistensi koneksi pada backend yang tidak sehat dalam dokumentasi Load Balancer Jaringan passthrough eksternal berbasis layanan backend.
• Apakah koneksi yang dibuat tetap ada selama failover dan failback, jika kebijakan failover dikonfigurasi. Untuk mengetahui detailnya, lihat Pengosongan koneksi saat terjadi failover dan failback dalam dokumentasi Load Balancer Jaringan passthrough internal dan Pengosongan koneksi saat terjadi failover dan failback dalam dokumentasi Load Balancer Jaringan passthrough eksternal berbasis layanan backend.
• Durasi koneksi yang dibuat dapat dipertahankan saat menghapus backend dari load balancer. Untuk mengetahui detailnya, lihat Mengaktifkan pengosongan koneksi.

Untuk load balancer berbasis proxy, selama jumlah instance atau endpoint backend yang responsif tetap konstan, dan selama instance atau endpoint backend yang dipilih sebelumnya tidak mencapai kapasitas, permintaan atau koneksi berikutnya akan mengarah ke VM atau endpoint backend yang sama. Kapasitas target mode balancing menentukan kapan backend mencapai kapasitas.

Tabel berikut menunjukkan opsi afinitas sesi yang didukung untuk setiap produk:

Tabel: Setelan afinitas sesi yang didukung

Produk	Opsi afinitas sesi
Load Balancer Aplikasi eksternal global 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 yang efektif dari kebijakan lokalitas load balancing (localityLbPolicy) berubah sesuai 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 konfigurasikan afinitas sesi jika Anda menggunakan pemisahan traffic berbobot. Jika Anda melakukannya, konfigurasi pemisahan traffic berbobot akan lebih diutamakan.
Load Balancer Aplikasi Klasik	Tidak ada (NONE) IP Klien (CLIENT_IP) Cookie yang dihasilkan (GENERATED_COOKIE)
Load Balancer Aplikasi internal lintas region Load Balancer Aplikasi internal 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 yang efektif dari kebijakan lokalitas load balancing (localityLbPolicy) berubah sesuai 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 internal, jangan konfigurasikan afinitas sesi jika Anda menggunakan pemisahan traffic berbobot. Jika Anda melakukannya, konfigurasi pemisahan traffic berbobot akan lebih diutamakan.
Load Balancer Jaringan passthrough internal	Tidak ada (NONE) IP KLIEN, tanpa tujuan (CLIENT_IP_NO_DESTINATION) IP Klien, IP Tujuan (CLIENT_IP) IP Klien, IP Tujuan, Protokol (CLIENT_IP_PROTO) IP Klien, Port Klien, IP Tujuan, Port Tujuan, Protokol (CLIENT_IP_PORT_PROTO) Untuk informasi spesifik tentang Load Balancer Jaringan passthrough internal dan afinitas sesi, lihat Ringkasan Load Balancer Jaringan passthrough internal.
Load Balancer Jaringan passthrough eksternal^*	Tidak ada (NONE) IP Klien, IP Tujuan (CLIENT_IP) IP Klien, IP Tujuan, Protokol (CLIENT_IP_PROTO) IP Klien, Port Klien, IP Tujuan, Port Tujuan, Protokol (CLIENT_IP_PORT_PROTO) Untuk informasi spesifik tentang Load Balancer Jaringan passthrough eksternal dan afinitas sesi, lihat Ringkasan TCP/UDP External passthrough Network Load Balancer.
Load Balancer Jaringan proxy eksternal global Load Balancer Jaringan proxy klasik Load Balancer Jaringan proxy eksternal regional Load Balancer Jaringan proxy internal regional Load Balancer Jaringan proxy internal lintas region	Tidak ada (NONE) IP Klien (CLIENT_IP)
Cloud Service Mesh	Tidak ada (NONE) IP Klien (CLIENT_IP) Cookie yang dihasilkan (GENERATED_COOKIE) (khusus protokol HTTP) Kolom header (HEADER_FIELD) (khusus protokol HTTP) Cookie HTTP (HTTP_COOKIE) (khusus protokol HTTP)

^* Tabel ini mendokumentasikan afinitas sesi yang didukung oleh Load Balancer Jaringan passthrough eksternal berbasis layanan backend. Load Balancer Jaringan passthrough eksternal berbasis kumpulan target tidak menggunakan layanan backend. Sebagai gantinya, Anda menetapkan afinitas sesi untuk Load Balancer Jaringan passthrough eksternal melalui parameter sessionAffinity di Kumpulan Target.

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, dirancang untuk rusak setiap kali jumlah penayangan dan backend yang sehat berubah. Untuk detail selengkapnya, lihat Kehilangan afinitas sesi.

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

Jenis afinitas sesi

Bagian berikut membahas berbagai jenis afinitas sesi:

IP klien, tanpa afinitas tujuan

Afinitas sesi IP klien, tanpa tujuan (CLIENT_IP_NO_DESTINATION) adalah hash satu tuple berdasarkan alamat IP sumber dari setiap paket yang diterima. Afinitas sesi ini hanya tersedia untuk Load Balancer Jaringan passthrough internal.

Opsi ini dapat berguna dalam situasi saat Anda memerlukan VM backend yang sama untuk memproses semua paket dari klien, hanya berdasarkan alamat IP sumber paket, tanpa mempertimbangkan alamat IP tujuan paket. Situasi ini biasanya muncul saat Load Balancer Jaringan passthrough internal adalah next hop untuk rute statis. Untuk mengetahui detailnya, lihat Afinitas sesi dan Load Balancer Jaringan passthrough internal next hop.

Afinitas IP klien

Afinitas sesi IP Klien (CLIENT_IP) adalah hash dua tuple yang dibuat dari alamat IP sumber dan tujuan paket. Afinitas sesi IP klien tersedia untuk semua load balancer Google Cloud yang menggunakan layanan backend. Load Balancer Jaringan passthrough eksternal memanggil opsi afinitas sesi ini Client IP, Destination IP.

Saat Anda menggunakan afinitas IP klien, perhatikan hal berikut:

• Alamat IP tujuan paket hanya sama dengan alamat IP aturan penerusan load balancer jika paket dikirim langsung ke load balancer.

• Paket yang dirutekan ke Load Balancer Jaringan passthrough internal next hop oleh rute statis memiliki alamat IP tujuan yang tidak cocok dengan alamat IP aturan penerusan load balancer. Untuk mengetahui detail penting, lihat Afinitas sesi dan next hop Load Balancer Jaringan passthrough internal.

• 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 saat banyak klien memiliki alamat IP sumber yang efektif yang sama, beberapa VM backend mungkin menerima lebih banyak koneksi atau permintaan daripada yang lain.

Afinitas berbasis cookie

Saat Anda menggunakan afinitas berbasis cookie yang dihasilkan, 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 berikut mendukung cookie yang dihasilkan:

Produk	Nama cookie
Load Balancer Aplikasi eksternal global	GCLB
Load Balancer Aplikasi Klasik	GCLB
Load Balancer Aplikasi eksternal regional	GCILB
Load Balancer Aplikasi internal lintas region	GCILB
Load Balancer Aplikasi internal regional	GCILB
Mesh Layanan Cloud	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 cookie yang dihasilkan.

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 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 mereferensikan instance backend atau endpoint tertentu, dan dengan memastikan bahwa persyaratan afinitas sesi cookie yang dihasilkan terpenuhi.

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

• Untuk grup instance backend, gunakan mode 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 kolom header

Dengan afinitas kolom header, permintaan akan 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.

Load balancer berikut menggunakan afinitas kolom header:

• Mesh Layanan Cloud
• Load Balancer Aplikasi internal lintas region
• Load Balancer Aplikasi eksternal global
• Load Balancer Aplikasi eksternal regional
• Load Balancer Aplikasi internal regional

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

Untuk mempelajari produk yang mendukung afinitas kolom header, lihat Tabel: Setelan afinitas sesi yang didukung.

Afinitas cookie HTTP

Jika Anda menggunakan afinitas berbasis cookie HTTP, 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.

Produk berikut mendukung afinitas berbasis cookie HTTP:

• Semua Load Balancer Aplikasi
• Mesh Layanan Cloud

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 unitnya 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 dalam 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 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 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, 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, 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 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 dalam header permintaan Cookie dari permintaan HTTP berikutnya, load balancer akan mengarahkan permintaan tersebut ke instance backend atau endpoint 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, mempertahankan cookie untuk seluruh sesi penjelajahan. Artinya, cookie akan tetap ada di beberapa permintaan hingga aplikasi ditutup.

• Klien lain memperlakukan sesi sebagai satu permintaan HTTP, yang langsung menghapus cookie setelah itu.

Kehilangan afinitas sesi

Semua opsi afinitas sesi untuk Load Balancer Aplikasi dan Load Balancer Jaringan Proxy memerlukan hal berikut:

• Instance atau endpoint backend yang dipilih harus tetap dikonfigurasi sebagai backend. Afinitas sesi dapat rusak saat 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 rusak saat instance atau endpoint yang dipilih gagal dalam pemeriksaan kesehatan.

• Untuk Load Balancer Aplikasi eksternal Global, Load Balancer Aplikasi Klasik, Load Balancer Jaringan proxy eksternal Global, dan Load Balancer Jaringan proxy Klasik, afinitas sesi dapat rusak jika Google Front End (GFE) lapisan pertama yang berbeda digunakan untuk permintaan atau koneksi berikutnya setelah perubahan pada jalur rute. GFE lapisan pertama yang berbeda mungkin dipilih jika jalur pemilihan rute dari klien di internet ke Google berubah di antara permintaan atau koneksi.

Kecuali untuk afinitas sesi berbasis cookie stateful, semua opsi afinitas sesi untuk Load Balancer Aplikasi dan Load Balancer Jaringan Proxy memiliki persyaratan tambahan berikut:

• Grup instance atau NEG yang berisi instance atau endpoint yang dipilih tidak boleh penuh seperti yang ditentukan oleh kapasitas target-nya. (Untuk grup instance terkelola regional, komponen zona grup instance yang berisi instance yang dipilih tidak boleh penuh.) Afinitas sesi dapat terputus jika grup instance atau NEG penuh dan grup instance atau NEG lainnya tidak. Karena kejenuhan 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 instance atau endpoint backend yang dikonfigurasi harus tetap konstan. Jika setidaknya salah satu peristiwa berikut terjadi, jumlah instance backend atau endpoint 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 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 instance atau endpoint backend yang sehat harus tetap konstan. Jika setidaknya salah satu peristiwa berikut terjadi, jumlah instance atau endpoint backend yang sehat akan berubah, dan afinitas sesi dapat rusak:

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

Waktu tunggu layanan backend

Sebagian besar load balancer Google Cloud memiliki waktu tunggu layanan backend. Nilai defaultnya adalah 30 detik. Rentang lengkap nilai waktu tunggu yang diizinkan adalah 1 - 2.147.483.647 detik.

• Untuk Load Balancer Aplikasi eksternal dan Load Balancer Aplikasi internal yang menggunakan protokol HTTP, HTTPS, atau HTTP/2, waktu tunggu layanan backend adalah waktu tunggu permintaan dan respons untuk traffic HTTP(S).

  Untuk mengetahui detail selengkapnya tentang waktu tunggu layanan backend untuk setiap load balancer, lihat artikel berikut:

  • Untuk Load Balancer Aplikasi eksternal global dan Load Balancer Aplikasi eksternal regional, lihat Waktu tunggu habis dan percobaan ulang.
  • Untuk Load Balancer Aplikasi internal, lihat Waktu tunggu habis dan percobaan ulang.

• Untuk Load Balancer Jaringan proxy eksternal, waktu tunggu adalah waktu tunggu tidak ada aktivitas. Untuk memberikan waktu lebih lama atau lebih singkat sebelum koneksi dihapus, ubah nilai waktu tunggu. Waktu tunggu tidak ada aktivitas ini juga digunakan untuk koneksi WebSocket.

• Untuk Load Balancer Jaringan passthrough internal dan Load Balancer Jaringan passthrough eksternal, Anda dapat menetapkan nilai waktu tunggu layanan backend menggunakan gcloud atau API, tetapi nilai tersebut akan diabaikan. Waktu tunggu layanan backend tidak ada artinya untuk load balancer pass-through ini.

• Untuk Cloud Service Mesh, kolom waktu tunggu layanan backend (ditentukan menggunakan timeoutSec) tidak didukung dengan layanan gRPC tanpa proxy. Untuk layanan tersebut, konfigurasikan waktu tunggu layanan backend menggunakan kolom maxStreamDuration. Hal ini karena gRPC tidak mendukung semantik timeoutSec yang menentukan jumlah waktu untuk menunggu backend menampilkan respons lengkap setelah permintaan dikirim. Waktu tunggu gRPC menentukan jumlah waktu untuk menunggu dari awal streaming hingga respons telah diproses sepenuhnya, termasuk semua percobaan ulang.

Health check

Setiap layanan backend yang backend-nya adalah grup instance atau NEG zona harus memiliki health check terkait. Layanan backend yang menggunakan NEG serverless atau NEG internet global sebagai backend tidak boleh mereferensikan health check.

Saat membuat load balancer menggunakan konsol Google Cloud, Anda dapat membuat health check, jika diperlukan, saat membuat load balancer, atau Anda dapat mereferensikan health check yang ada.

Saat membuat layanan backend menggunakan backend grup instance atau NEG zona menggunakan Google Cloud CLI atau API, Anda harus mereferensikan health check yang ada. Lihat panduan load balancer di Ringkasan Health Check untuk mengetahui detail tentang jenis dan cakupan health check yang diperlukan.

Untuk informasi selengkapnya, baca dokumen berikut:

• Ringkasan health check
• Membuat health check
• gcloud halaman health check
• Halaman pemeriksaan kondisi REST API

Fitur tambahan yang diaktifkan di resource layanan backend

Fitur opsional berikut didukung oleh beberapa layanan backend.

Cloud CDN

Cloud CDN menggunakan jaringan edge global Google untuk menyajikan konten lebih dekat ke pengguna, sehingga mempercepat situs dan aplikasi Anda. Cloud CDN diaktifkan di layanan backend yang digunakan oleh Load Balancer Aplikasi eksternal global. Load balancer menyediakan port dan alamat IP frontend yang menerima permintaan, dan backend yang merespons permintaan.

Untuk mengetahui detail selengkapnya, lihat dokumentasi Cloud CDN.

Cloud CDN tidak kompatibel dengan IAP. Keduanya tidak dapat diaktifkan di layanan backend yang sama.

Google Cloud Armor

Jika menggunakan salah satu load balancer berikut, Anda dapat menambahkan perlindungan tambahan ke aplikasi dengan mengaktifkan Google Cloud Armor di layanan backend selama pembuatan load balancer:

• Load Balancer Aplikasi eksternal global
• Load Balancer Aplikasi Klasik
• Load Balancer Jaringan proxy eksternal global
• Load Balancer Jaringan proxy klasik

Jika menggunakan konsol Google Cloud, Anda dapat melakukan salah satu tindakan berikut:

• Pilih kebijakan keamanan Google Cloud Armor yang ada.
• Setujui konfigurasi kebijakan keamanan pembatasan kapasitas Google Cloud Armor default dengan nama, jumlah permintaan, interval, kunci, dan parameter pembatasan kapasitas yang dapat disesuaikan. Jika Anda menggunakan Google Cloud Armor dengan layanan proxy upstream, seperti penyedia CDN, Enforce_on_key harus ditetapkan sebagai alamat IP XFF.
• Pilih untuk tidak menggunakan perlindungan Google Cloud Armor dengan memilih Tidak ada.

IAP

IAP memungkinkan Anda membuat lapisan otorisasi pusat untuk aplikasi yang diakses oleh HTTPS. Dengan begitu, Anda dapat menggunakan model kontrol akses tingkat aplikasi, bukan mengandalkan firewall tingkat jaringan. IAP didukung oleh Load Balancer Aplikasi tertentu.

IAP tidak kompatibel dengan Cloud CDN. Keduanya tidak dapat diaktifkan di layanan backend yang sama.

Fitur pengelolaan traffic lanjutan

Untuk mempelajari fitur pengelolaan traffic lanjutan yang dikonfigurasi di layanan backend dan peta URL yang terkait dengan load balancer, lihat artikel berikut:

• Ringkasan pengelolaan traffic untuk Load Balancer Aplikasi internal
• Ringkasan pengelolaan traffic untuk Load Balancer Aplikasi eksternal global
• Ringkasan pengelolaan traffic untuk Load Balancer Aplikasi eksternal regional

Referensi API dan gcloud

Untuk informasi selengkapnya tentang properti resource layanan backend, lihat referensi berikut:

• Referensi API layanan backend global

• Resource API layanan backend regional

• Halaman gcloud compute backend-services, untuk layanan backend global dan regional

Langkah selanjutnya

Untuk dokumentasi dan informasi terkait tentang cara layanan backend digunakan dalam load balancing, tinjau hal berikut:

• Membuat header kustom
• Membuat Load Balancer Aplikasi eksternal
• Ringkasan Load Balancer Aplikasi Eksternal
• Mengaktifkan pengosongan koneksi
• Enkripsi dalam pengiriman di Google Cloud

Untuk video terkait:

• Cara mengonfigurasi layanan backend untuk Load Balancer Aplikasi eksternal global