Ringkasan layanan backend

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

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

  • Mengarahkan traffic langsung ke backend yang benar, yaitu grup instance atau grup endpoint jaringan (NEG).
  • Mendistribusikan traffic sesuai dengan mode penyeimbangan, yang merupakan setelan untuk setiap backend.
  • Tentukan health check mana yang memantau responsivitas 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
  • Menetapkan layanan backend global dan regional sebagai layanan di aplikasi App Hub.

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, pertimbangkan untuk menggunakan 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 dibagikan 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 backend grup instance terkelola dan tidak terkelola *
  • Semua NEG zona: Satu atau beberapa NEG zona jenis GCE_VM_IP_PORT*
  • Semua NEG dengan konektivitas hybrid: Satu atau beberapa NEG jenis NON_GCP_PRIVATE_IP_PORT
  • Kombinasi NEG zona dan hybrid: GCE_VM_IP_PORT dan NEG jenis NON_GCP_PRIVATE_IP_PORT †
  • Semua NEG serverless: Satu atau beberapa resource App Engine, Cloud Run, atau Cloud Run 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 backend grup instance terkelola dan tidak terkelola
  • Semua NEG zona: Satu atau beberapa NEG zona jenis GCE_VM_IP_PORT
  • Semua NEG dengan konektivitas hybrid: Satu atau beberapa NEG jenis NON_GCP_PRIVATE_IP_PORT
  • Kombinasi NEG zona dan hybrid: GCE_VM_IP_PORT dan NEG jenis NON_GCP_PRIVATE_IP_PORT †
  • Semua NEG serverless: Satu atau beberapa resource App Engine, Cloud Run, atau Cloud Run Functions, atau
  • Satu NEG internet global untuk backend eksternal
 EKSTERNAL#
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 backend grup instance terkelola dan tidak terkelola *
  • Semua NEG zona: Satu atau beberapa NEG zona jenis GCE_VM_IP_PORT *
  • Semua NEG dengan konektivitas hybrid: Satu atau beberapa NEG jenis NON_GCP_PRIVATE_IP_PORT
  • Kombinasi NEG zona dan hybrid: GCE_VM_IP_PORT dan NEG jenis NON_GCP_PRIVATE_IP_PORT †
  • Satu NEG serverless (hanya untuk Cloud Run atau Cloud Run Functions generasi ke-2)
  • 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 backend grup instance terkelola dan tidak terkelola *
  • Semua NEG zona: Satu atau beberapa NEG zona jenis GCE_VM_IP_PORT *
  • Semua NEG dengan konektivitas hybrid: Satu atau beberapa NEG jenis NON_GCP_PRIVATE_IP_PORT
  • Kombinasi NEG zona dan hybrid: GCE_VM_IP_PORT dan NEG jenis NON_GCP_PRIVATE_IP_PORT †
  • Satu NEG serverless (hanya untuk Cloud Run atau Cloud Run Functions generasi ke-2)
  • 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 backend grup instance terkelola dan tidak terkelola *
  • Semua NEG zona: Satu atau beberapa NEG zona jenis GCE_VM_IP_PORT *
  • Semua NEG dengan konektivitas hybrid: Satu atau beberapa NEG jenis NON_GCP_PRIVATE_IP_PORT
  • Kombinasi NEG zona dan hybrid: GCE_VM_IP_PORT dan NEG jenis NON_GCP_PRIVATE_IP_PORT †
  • Satu NEG serverless (hanya untuk Cloud Run atau Cloud Run Functions generasi ke-2)
  • 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 backend grup instance terkelola dan tidak terkelola *
  • Semua NEG zona: Satu atau beberapa NEG zona jenis GCE_VM_IP_PORT*
  • Semua NEG dengan konektivitas hybrid: Satu atau beberapa NEG jenis NON_GCP_PRIVATE_IP_PORT
  • Kombinasi NEG zona dan hybrid: GCE_VM_IP_PORT dan NEG jenis 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 backend grup instance terkelola dan tidak terkelola
  • Semua NEG zona: Satu atau beberapa NEG zona jenis GCE_VM_IP_PORT
  • Semua NEG dengan konektivitas hybrid: Satu atau beberapa NEG jenis NON_GCP_PRIVATE_IP_PORT
  • Kombinasi NEG zona dan hybrid: GCE_VM_IP_PORT dan NEG jenis 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 backend grup instance terkelola dan tidak terkelola *
  • Semua NEG zona: Satu atau beberapa NEG zona jenis GCE_VM_IP_PORT *
  • Semua NEG dengan 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 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 backend grup instance terkelola dan tidak terkelola *
  • Semua NEG zona: Satu atau beberapa NEG zona jenis GCE_VM_IP_PORT *
  • Semua NEG dengan 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 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 backend grup instance terkelola dan tidak terkelola *
  • Semua NEG zona: Satu atau beberapa NEG zona jenis GCE_VM_IP_PORT *
  • Semua NEG dengan 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
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 backend grup instance terkelola dan tidak terkelola
  • Semua NEG zona: Satu atau beberapa NEG zona jenis GCE_VM_IP
 EKSTERNAL
Load Balancer Jaringan 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 backend grup instance terkelola dan tidak terkelola
  • Semua NEG zona: Satu atau beberapa NEG zona jenis GCE_VM_IP
  • Satu NEG pemetaan port
 INTERNAL
Cloud Service Mesh 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 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 berjenis 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.
‡ Layanan backend yang digunakan oleh Load Balancer Aplikasi klasik dan Load Balancer Jaringan proxy klasik selalu memiliki cakupan global, baik di Paket Jaringan Standar maupun Premium. Namun, di Tingkat Standar, batasan berikut berlaku:
# Anda dapat melampirkan EXTERNAL_MANAGED layanan backend ke EXTERNAL aturan penerusan. 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 Anda memigrasikan resource EXTERNAL yang ada ke EXTERNAL_MANAGED dengan menggunakan proses migrasi yang dijelaskan di Memigrasikan resource dari Load Balancer Aplikasi klasik ke Load Balancer Aplikasi eksternal global.

Penamaan load balancer

Untuk Load Balancer Jaringan Proxy dan Load Balancer Jaringan Passthrough, nama load balancer selalu sama dengan nama layanan backend. Perilaku untuk setiap antarmuka Google Cloud adalah sebagai berikut:

  • Google Cloud console. Jika Anda membuat Load Balancer Jaringan proxy atau Load Balancer Jaringan passthrough menggunakan konsol Google Cloud , layanan backend akan otomatis diberi nama yang sama dengan yang Anda masukkan untuk nama load balancer.
  • Google Cloud CLI atau API. Jika membuat Load Balancer Jaringan proxy atau Load Balancer Jaringan passthrough menggunakan gcloud CLI atau API, Anda akan memasukkan nama pilihan saat membuat layanan backend. Nama layanan backend ini kemudian ditampilkan di konsol Google Cloud sebagai nama load balancer.

Untuk mempelajari cara kerja penamaan untuk Load Balancer Aplikasi, lihat Ringkasan peta URL: Penamaan load balancer.

Backend

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

Anda tidak dapat menghapus grup instance backend atau NEG yang terkait dengan layanan backend. Sebelum menghapus grup instance atau NEG, Anda harus terlebih dahulu menghapusnya 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. Proxy 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 dikirimkan ke backend dengan alamat IP sumber dan tujuan aslinya 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 nic0 VM.
    • Untuk endpoint GCE_VM_IP di NEG zonal, paket dikirimkan ke antarmuka jaringan VM yang berada di subnetwork 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 bernama 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 nomor dilakukan satu per satu untuk setiap backend grup instance.

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

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

Misalnya, Anda dapat menyetel port 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 hybrid dengan endpoint NON_GCP_PRIVATE_IP_PORT, dan NEG internet menentukan port menggunakan mekanisme yang berbeda, yaitu, pada 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 tersebut adalah load balancer pass-through yang merutekan koneksi langsung ke backend, bukan membuat koneksi baru. Paket dikirim ke backend dengan mempertahankan alamat IP dan port tujuan aturan penerusan load balancer.

Untuk mempelajari cara membuat port bernama, lihat petunjuk berikut:

Batasan dan panduan untuk grup instance

Perhatikan hal-hal berikut saat Anda menggunakan backend grup instance:

  • Instance VM hanya dapat menjadi bagian dari satu grup instance yang di-load balance. Misalnya, VM dapat menjadi anggota dari dua grup instance tidak terkelola, atau VM dapat menjadi anggota dari satu grup instance terkelola dan satu grup instance tidak terkelola. Jika VM adalah anggota dari dua grup instance atau lebih, hanya satu grup instance yang dapat dirujuk oleh satu atau beberapa layanan backend load balancer.

  • Grup instance yang sama dapat digunakan oleh dua layanan backend atau lebih. Setiap pemetaan antara grup instance dan layanan backend dapat menggunakan mode load balancing yang berbeda, kecuali untuk kombinasi mode load balancing yang tidak kompatibel.

    • Kombinasi mode penyeimbangan yang tidak kompatibel adalah sebagai berikut:

      • Mode penyeimbangan UTILIZATION tidak kompatibel dengan semua mode penyeimbangan lainnya. Jika grup instance adalah backend dari beberapa layanan backend, grup instance harus menggunakan mode penyeimbangan UTILIZATION di setiap layanan backend.

      • Mode penyeimbangan CUSTOM_METRICS tidak kompatibel dengan semua mode penyeimbangan lainnya. Jika grup instance adalah backend dari beberapa layanan backend, grup instance harus menggunakan mode penyeimbangan CUSTOM_METRICS di setiap layanan backend.

    • Sebagai konsekuensi dari kombinasi mode load balancing yang tidak kompatibel, jika grup instance menggunakan mode load balancing UTILIZATION atau CUSTOM_METRICS sebagai backend untuk setidaknya satu layanan backend, grup instance yang sama tidak dapat digunakan sebagai backend untuk Load Balancer Jaringan passthrough karena Load Balancer Jaringan passthrough memerlukan mode load balancing CONNECTION.

  • Tidak ada satu perintah yang dapat mengubah mode penyeimbangan grup instance yang sama di beberapa layanan backend. Untuk mengubah mode penyeimbangan bagi grup instance yang merupakan backend dari dua layanan backend atau lebih, Anda dapat menggunakan teknik ini:

    • Hapus grup instance sebagai backend dari semua layanan backend kecuali untuk satu layanan backend.
    • Ubah mode penyeimbangan grup instance untuk satu layanan backend yang tersisa.
    • Tambahkan kembali grup instance sebagai backend ke layanan backend lainnya.

Pertimbangkan praktik terbaik berikut, yang memberikan opsi yang lebih fleksibel:

  • Hindari penggunaan grup instance yang sama sebagai backend untuk dua atau beberapa layanan backend. Sebagai gantinya, gunakan beberapa NEG.

    • Tidak seperti grup instance, VM dapat memiliki endpoint di dua atau lebih NEG yang di-load balance.

    • Misalnya, jika VM perlu menjadi backend dari Load Balancer Jaringan passthrough dan Load Balancer Jaringan proxy atau Load Balancer Aplikasi secara bersamaan, gunakan beberapa NEG dengan load seimbang. Tempatkan endpoint VM di NEG unik yang kompatibel dengan setiap jenis load balancer. Kemudian, kaitkan setiap NEG dengan layanan backend load balancer yang sesuai.

  • Jangan menambahkan grup instance terkelola yang diskalakan otomatis ke lebih dari satu layanan backend saat menggunakan metrik penskalaan otomatis Penggunaan Load Balancing HTTP. Dua atau beberapa layanan backend yang mereferensikan grup instance terkelola dengan penskalaan otomatis yang sama dapat saling bertentangan kecuali jika metrik penskalaan otomatis tidak terkait dengan aktivitas load balancer.

Grup endpoint jaringan zona

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

NEG zona adalah resource zonal yang merepresentasikan kumpulan alamat IP atau kombinasi alamat IP dan port untuk resourceGoogle Cloud dalam satu subnet.

Layanan backend yang menggunakan NEG zonal sebagai backend-nya mendistribusikan traffic di antara aplikasi atau container yang berjalan di 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 zona, 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 di infrastruktur yang disediakan oleh pihak ketiga.

NEG internet adalah kombinasi dari 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 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 resource Cloud Run, App Engine, Cloud Run Functions, atau API Gateway.

NEG tanpa server dapat merepresentasikan salah satu hal berikut:

  • Resource Cloud Run atau sekelompok resource.
  • Fungsi atau grup fungsi Cloud Run (sebelumnya Cloud Run Functions generasi ke-2).
  • Fungsi atau grup fungsi Cloud Run (generasi ke-1)
  • Aplikasi lingkungan standar App Engine atau lingkungan fleksibel App Engine, layanan tertentu dalam aplikasi, versi tertentu dari aplikasi, 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.

Untuk menyiapkan NEG serverless bagi aplikasi serverless yang berbagi pola URL, 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 Run Functions, atau App Engine yang cocok dengan nama yang sama.

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

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

Pengikatan layanan

Pengikatan layanan adalah backend yang membuat koneksi antara layanan backend di Cloud Service Mesh dan layanan yang terdaftar di Service Directory. 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 zonal secara bersamaan.
  • Anda dapat menggunakan kombinasi berbagai jenis grup instance pada layanan backend yang sama. Misalnya, satu layanan backend dapat mereferensikan kombinasi grup instance terkelola dan tidak terkelola. Untuk 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 zonal (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 mana 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 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
Cloud Service Mesh HTTP, HTTPS, HTTP/2, gRPC, TCP

Mengubah protokol layanan backend 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 mengetahui 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 ke stack ganda.

Anda dapat menentukan nilai berikut untuk kebijakan pemilihan alamat IP:

Kebijakan pemilihan alamat IP Deskripsi
Hanya IPv4 Hanya mengirim traffic IPv4 ke backend layanan backend, terlepas dari traffic dari klien ke GFE. Health check hanya IPv4 digunakan untuk memeriksa kondisi backend.
Lebih memilih IPv6

Membuat koneksi IPv6 backend lebih diprioritaskan daripada koneksi IPv4 (asalkan ada backend yang berfungsi dengan baik dengan alamat IPv6).

Health check secara berkala memantau koneksi IPv6 dan IPv4 backend. GFE pertama-tama mencoba koneksi IPv6; jika koneksi IPv6 terputus atau lambat, GFE akan menggunakan happy eyeballs untuk melakukan penggantian dan terhubung ke IPv4.

Meskipun salah satu koneksi IPv6 atau IPv4 tidak sehat, backend tetap dianggap sehat, dan kedua koneksi dapat dicoba oleh GFE, dengan happy eyeballs pada akhirnya memilih koneksi mana yang akan digunakan.
Hanya IPv6

Hanya mengirim traffic IPv6 ke backend layanan backend, terlepas dari traffic dari klien ke proxy. Health check IPv6 saja 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 mencapai backend tersebut dan kode respons HTTP 503 ditampilkan ke klien.

Enkripsi antara load balancer dan backend

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

Mode penyeimbangan, kapasitas target, dan penghitung skala kapasitas

Untuk Load Balancer Aplikasi, Cloud Service Mesh, dan Load Balancer Jaringan proxy, mode penyeimbangan, kapasitas target, dan penskala kapasitas adalah parameter yang Anda berikan saat menambahkan backend yang didukung ke layanan backend. Load balancer menggunakan parameter ini untuk mengelola distribusi permintaan baru atau koneksi baru ke zona yang berisi backend yang didukung:

  • Mode load balancing menentukan cara load balancer mengukur kapasitas. Google Cloud memiliki mode load balancing berikut:
    • CONNECTION: menentukan kapasitas berdasarkan jumlah koneksi TCP baru.
    • RATE: menentukan kapasitas berdasarkan laju permintaan HTTP baru.
    • IN-FLIGHT (Pratinjau): menentukan kapasitas berdasarkan jumlah permintaan HTTP yang sedang diproses, bukan tingkat permintaan HTTP. Gunakan mode penyeimbangan ini, bukan RATE, jika permintaan memerlukan waktu lebih dari satu detik untuk diselesaikan.
    • UTILIZATION: menentukan kapasitas berdasarkan perkiraan penggunaan CPU VM dalam zona grup instance.
    • CUSTOM_METRICS: menentukan kapasitas berdasarkan metrik kustom yang ditentukan pengguna.
  • Kapasitas target menentukan jumlah kapasitas target.
    • Kapasitas target bukan pemutus arus listrik.
    • Saat penggunaan kapasitas mencapai kapasitas target, load balancer akan mengarahkan permintaan baru atau koneksi baru ke zona lain jika backend dikonfigurasi di dua zona atau lebih.
    • Load Balancer Aplikasi eksternal global, Load Balancer Jaringan proxy eksternal global, Load Balancer Aplikasi internal lintas region, dan Load Balancer Jaringan proxy internal lintas region juga menggunakan kapasitas untuk mengarahkan permintaan ke zona di region yang berbeda, jika Anda telah mengonfigurasi backend di lebih dari satu region.
    • Setelah semua zona mencapai kapasitas target, permintaan baru atau koneksi baru akan didistribusikan dengan pengisian berlebih secara proporsional.
  • Penskala kapasitas menyediakan cara untuk menskalakan kapasitas target secara manual. Nilai untuk penskala kapasitas adalah sebagai berikut:
    • 0: menunjukkan bahwa backend telah sepenuhnya dikosongkan. Anda tidak dapat menggunakan nilai 0 jika layanan backend hanya memiliki satu backend.
    • 0.1 (10%) - 1.0 (100%): menunjukkan persentase kapasitas backend yang sedang digunakan.

Load Balancer Jaringan passthrough secara simbolis menggunakan mode penyeimbangan CONNECTION, tetapi tidak mendukung kapasitas target atau penskala kapasitas. Untuk mengetahui informasi selengkapnya tentang cara Load Balancer Jaringan passthrough mendistribusikan koneksi baru, lihat artikel berikut:

Backend yang didukung

Untuk Load Balancer Aplikasi, Cloud Service Mesh, dan Load Balancer Jaringan proxy, jenis backend berikut mendukung parameter mode penyeimbangan, kapasitas target, dan penskala kapasitas:

NEG internet, NEG serverless, dan NEG Private Service Connect tidak mendukung parameter mode load balancing, kapasitas target, dan penskala kapasitas.

Mode load balancing untuk Load Balancer Aplikasi dan Cloud Service Mesh

Mode penyeimbangan yang tersedia untuk backend Load Balancer Aplikasi dan Cloud Service Mesh bergantung pada jenis backend yang didukung dan setelan durasi traffic (Pratinjau).

Setelan durasi traffic

Untuk backend Load Balancer Aplikasi dan Cloud Service Mesh, Anda dapat secara opsional menentukan setelan durasi traffic. Setelan ini unik untuk pemetaan antara backend yang didukung dan layanan backend. Setelan durasi traffic memiliki dua nilai yang valid:

  • SHORT: direkomendasikan untuk permintaan HTTP yang dijawab dengan respons dari backend dalam waktu kurang dari satu detik. Jika Anda tidak menentukan durasi traffic secara eksplisit, load balancer akan beroperasi seolah-olah Anda telah menentukan SHORT.
  • LONG: direkomendasikan untuk permintaan HTTP yang memerlukan waktu lebih dari satu detik bagi backend untuk menghasilkan respons.

Untuk menyetel durasi traffic secara eksplisit saat Anda menambahkan backend ke layanan backend, lakukan salah satu hal berikut:

Mode penyeimbangan untuk durasi traffic pendek

Jika setelan durasi traffic tidak ditentukan atau ditetapkan ke SHORT(Pratinjau), mode load balancing yang tersedia untuk backend Load Balancer Aplikasi dan Cloud Service Mesh bergantung pada jenis backend yang didukung.

Tabel: Mode load balancing untuk backend Cloud Service Mesh dan Load Balancer Aplikasi menggunakan setelan durasi traffic pendek
Backend yang didukung Balancing mode
CONNECTION RATE IN_FLIGHT UTILIZATION CUSTOM_METRICS
Grup instance
NEG zona dengan endpoint GCE_VM_IP_PORT
NEG dengan konektivitas hybrid zona

Mode penyeimbangan untuk durasi traffic yang panjang

Jika setelan durasi traffic adalah LONG, mode penyeimbangan yang tersedia untuk backend Application Load Balancer dan Cloud Service Mesh bergantung pada jenis backend yang didukung.

Tabel: Mode load balancing untuk backend Cloud Service Mesh dan Load Balancer Aplikasi menggunakan setelan durasi traffic panjang
Backend yang didukung Balancing mode
CONNECTION RATE IN_FLIGHT UTILIZATION CUSTOM_METRICS
Grup instance
NEG zona dengan endpoint GCE_VM_IP_PORT
NEG dengan konektivitas hybrid zona

Mode penyeimbangan untuk Load Balancer Jaringan Proxy

Mode penyeimbangan yang tersedia untuk backend Load Balancer Jaringan proxy bergantung pada jenis backend yang didukung.

Tabel: Mode penyeimbangan untuk Load Balancer Jaringan Proxy
Backend yang didukung Balancing mode
CONNECTION RATE IN_FLIGHT UTILIZATION CUSTOM_METRICS
Grup instance
NEG zona dengan endpoint GCE_VM_IP_PORT
NEG dengan konektivitas hybrid zona

Spesifikasi kapasitas target

Spesifikasi kapasitas target relevan dengan Load Balancer Aplikasi, Cloud Service Mesh, dan backend Load Balancer Jaringan proxy yang mendukung setelan mode penyeimbangan, kapasitas target, dan penskala kapasitas.

Spesifikasi kapasitas target tidak relevan dengan Load Balancer Jaringan passthrough.

Mode penyeimbangan koneksi

Backend Load Balancer Jaringan Proxy dapat menggunakan mode penyeimbangan CONNECTION dengan salah satu parameter kapasitas target yang diperlukan berikut:

Parameter kapasitas target untuk mode penyeimbangan CONNECTION
Parameter kapasitas target Backend yang didukung
Grup instance (terkelola atau tidak terkelola) zona Grup instance terkelola regional NEG zona dengan endpoint GCE_VM_IP_PORT NEG dengan konektivitas hybrid zona
max-connections
Koneksi TCP target per zona backend
max-connections-per-instance
Menargetkan koneksi TCP per instance VM. Cloud Load Balancing menggunakan parameter ini untuk menghitung koneksi TCP target per zona backend.
max-connections-per-endpoint
Target koneksi TCP per endpoint NEG. Cloud Load Balancing menggunakan parameter ini untuk menghitung koneksi TCP target per zona backend.

Menggunakan parameter max-connections

Saat Anda menentukan parameter max-connections, nilai yang Anda berikan menentukan kapasitas untuk seluruh zona.

  • Untuk grup instance zona dengan total N instance dan h instance yang responsif (dengan h ≤ N), perhitungannya adalah sebagai berikut:

    • Jika Anda menyetel max-connections ke X, kapasitas target zonal adalah X.
    • Rata-rata koneksi per instance adalah X / h.

  • Grup instance terkelola regional tidak mendukung parameter max-connections karena terdiri dari beberapa zona. Sebagai gantinya, gunakan parameter max-connections-per-instance.

  • Untuk NEG zonal dengan total N endpoint dan h endpoint yang sehat (dengan h ≤ N), perhitungannya adalah sebagai berikut:

    • Jika Anda menyetel max-connections ke X, kapasitas target zonal adalah X.
    • Rata-rata koneksi per endpoint adalah X / h.

Menggunakan parameter max-connections-per-instance atau max-connections-per-endpoint

Saat Anda menentukan parameter max-connections-per-instance atau max-connections-per-endpoint, load balancer menggunakan nilai yang Anda berikan untuk menghitung kapasitas per zona:

  • Untuk grup instance zona dengan total N instance dan h instance yang responsif (dengan h ≤ N), perhitungannya adalah sebagai berikut:

    • Jika Anda menyetel max-connections-per-instance ke X, kapasitas target zonal adalah N * X. Ini sama dengan menyetel max-connections ke N * X.
    • Rata-rata koneksi per instance adalah (N * X) / h.

  • Untuk grup instance terkelola regional, jika Anda menetapkan max-connections-per-instance ke X, Google Cloud menghitung kapasitas target per zona untuk setiap zona grup instance. Di setiap zona, jika ada total K instance dan h instance yang responsif (dengan h≤ K), perhitungannya adalah sebagai berikut:

    • Kapasitas target zona adalah K * X.
    • Rata-rata koneksi per instance di zona adalah (K * X) / h.

  • Untuk NEG zonal dengan total N endpoint dan h endpoint yang sehat (dengan h ≤ N), perhitungannya adalah sebagai berikut:

    • Jika Anda menyetel max-connections-per-endpoint ke X, kapasitas target zonal adalah N * X. Ini sama dengan menyetel max-connections ke N * X.
    • Rata-rata koneksi per endpoint adalah (N * X) / h.

Mode penyeimbangan rasio

Backend Application Load Balancer dan Cloud Service Mesh dengan setelan durasi traffic yang tidak ditentukan atau singkat (Pratinjau) dapat menggunakan mode penyeimbangan RATE dengan salah satu parameter kapasitas target yang diperlukan berikut:

Tabel: Parameter kapasitas target untuk mode penyeimbangan RATE
Parameter kapasitas target Backend yang didukung
Grup instance (terkelola atau tidak terkelola) zona Grup instance terkelola regional NEG zona dengan endpoint GCE_VM_IP_PORT NEG dengan konektivitas hybrid zona
max-rate
Target kecepatan permintaan HTTP per zona backend
max-rate-per-instance
Target kecepatan permintaan HTTP per instance VM. Cloud Load Balancing menggunakan parameter ini untuk menghitung rasio permintaan HTTP target per zona backend.
max-rate-per-endpoint
Target kecepatan permintaan HTTP per endpoint NEG. Cloud Load Balancing menggunakan parameter ini untuk menghitung rasio permintaan HTTP target per zona backend.

Menggunakan parameter max-rate

Saat Anda menentukan parameter max-rate, nilai yang Anda berikan menentukan kapasitas untuk seluruh zona.

  • Untuk grup instance zona dengan total N instance dan h instance yang responsif (dengan h ≤ N), perhitungannya adalah sebagai berikut:

    • Jika Anda menetapkan max-rate ke X, kapasitas target per zona adalah X permintaan per detik.
    • Rata-rata permintaan per detik per instance adalah X / h.

  • Grup instance terkelola regional tidak mendukung parameter max-rate karena terdiri dari beberapa zona. Sebagai gantinya, gunakan parameter max-rate-per-instance.

  • Untuk NEG zonal dengan total N endpoint dan h endpoint yang sehat (dengan h ≤ N), perhitungannya adalah sebagai berikut:

    • Jika Anda menetapkan max-rate ke X, kapasitas target per zona adalah X permintaan per detik.
    • Rata-rata permintaan per detik per endpoint adalah X / h.

Menggunakan parameter max-rate-per-instance atau max-rate-per-endpoint

Saat Anda menentukan parameter max-rate-per-instance atau max-rate-per-endpoint, load balancer menggunakan nilai yang Anda berikan untuk menghitung kapasitas per zona:

  • Untuk grup instance zona dengan total N instance dan h instance yang responsif (dengan h ≤ N), perhitungannya adalah sebagai berikut:

    • Jika Anda menetapkan max-rate-per-instance ke X, kapasitas target per zona adalah N * X permintaan per detik. Ini sama dengan menyetel max-rate ke N * X.
    • Rata-rata permintaan per detik per instance adalah (N * X) / h.

  • Untuk grup instance terkelola regional, jika Anda menetapkan max-rate-per-instance ke X, Google Cloud menghitung kapasitas target per zona untuk setiap zona grup instance. Di setiap zona, jika ada total K instance dan h instance yang responsif (dengan h≤ K), perhitungannya adalah sebagai berikut:

    • Kapasitas target zona adalah K * X permintaan per detik.
    • Rata-rata permintaan per detik per instance di zona adalah (K * X) / h.

  • Untuk NEG zonal dengan total N endpoint dan h endpoint yang sehat (dengan h ≤ N), perhitungannya adalah sebagai berikut:

    • Jika Anda menetapkan max-rate-per-endpoint ke X, kapasitas target per zona adalah N * X permintaan per detik. Ini sama dengan menyetel max-rate ke N * X.
    • Rata-rata permintaan per detik per endpoint adalah (N * X) / h.

Mode penyeimbangan dalam penerbangan

Backend Load Balancer Aplikasi dan Cloud Service Mesh dengan setelan durasi traffic yang panjang dapat menggunakan mode load balancing IN_FLIGHT dengan salah satu parameter kapasitas target yang diperlukan berikut:

Tabel: Parameter kapasitas target untuk mode penyeimbangan IN_FLIGHT
Parameter kapasitas target Backend yang didukung
Grup instance (terkelola atau tidak terkelola) zona Grup instance terkelola regional NEG zona dengan endpoint GCE_VM_IP_PORT NEG dengan konektivitas hybrid zona
max-in-flight-requests
Jumlah target permintaan HTTP yang sedang berlangsung per zona backend
max-in-flight-requests-per-instance
Jumlah target permintaan HTTP yang sedang berlangsung per instance VM. Cloud Load Balancing menggunakan parameter ini untuk menghitung jumlah target permintaan HTTP yang sedang berlangsung per zona backend.
max-in-flight-requests-per-endpoint
Jumlah target permintaan HTTP yang sedang berlangsung per endpoint NEG. Load balancing menggunakan parameter ini untuk menghitung target jumlah permintaan HTTP yang sedang berlangsung per zona backend.

Menggunakan parameter max-in-flight-requests

Saat Anda menentukan parameter max-in-flight-requests, nilai yang Anda berikan menentukan kapasitas untuk seluruh zona.

  • Untuk grup instance zona dengan total N instance dan h instance yang responsif (dengan h ≤ N), perhitungannya adalah sebagai berikut:

    • Jika Anda menyetel max-in-flight-requests ke X, kapasitas target zona adalah X permintaan HTTP yang sedang berlangsung.
    • Jumlah rata-rata permintaan HTTP yang sedang berlangsung per instance adalah X / h.

  • Grup instance terkelola regional tidak mendukung parameter max-in-flight-requests karena terdiri dari beberapa zona. Sebagai gantinya, gunakan parameter max-in-flight-requests-per-instance.

  • Untuk NEG zonal dengan total N endpoint dan h endpoint yang sehat (dengan h ≤ N), perhitungannya adalah sebagai berikut:

    • Jika Anda menyetel max-in-flight-requests ke X, kapasitas target zona adalah X permintaan HTTP yang sedang berlangsung.
    • Jumlah rata-rata permintaan HTTP yang sedang berlangsung per endpoint adalah X / h.

Menggunakan parameter max-in-flight-requests-per-instance atau max-in-flight-requests-per-endpoint

Saat Anda menentukan parameter max-in-flight-requests-per-instance atau max-in-flight-requests-per-endpoint, load balancer menggunakan nilai yang Anda berikan untuk menghitung kapasitas per zona:

  • Untuk grup instance zona dengan total N instance dan h instance yang responsif (dengan h ≤ N), perhitungannya adalah sebagai berikut:

    • Jika Anda menetapkan max-in-flight-requests-per-instance ke X, kapasitas target zona adalah N * X permintaan HTTP yang sedang berlangsung. Hal ini setara dengan menetapkan max-in-flight-requests ke N * X.
    • Rata-rata permintaan HTTP yang sedang berlangsung per instance adalah (N * X) / h.

  • Untuk grup instance terkelola regional, jika Anda menetapkan max-in-flight-requests-per-instance ke X, Google Cloud menghitung kapasitas target per zona untuk setiap zona grup instance. Di setiap zona, jika ada total K instance dan h instance yang responsif (dengan h≤ K), perhitungannya adalah sebagai berikut:

    • Kapasitas target zona adalah K * X permintaan HTTP yang sedang berlangsung.
    • Rata-rata permintaan HTTP yang sedang berlangsung per instance di zona adalah (K * X) / h.

  • Untuk NEG zonal dengan total N endpoint dan h endpoint yang sehat (dengan h ≤ N), perhitungannya adalah sebagai berikut:

    • Jika Anda menetapkan max-in-flight-requests-per-endpoint ke X, kapasitas target zona adalah N * X permintaan HTTP yang sedang berlangsung. Hal ini setara dengan menetapkan max-in-flight-requests ke N * X.
    • Rata-rata permintaan HTTP yang sedang berlangsung per endpoint adalah (N * X) / h.

Mode penyeimbangan pemakaian

Backend grup instance Load Balancer Aplikasi, Cloud Service Mesh, dan Load Balancer Jaringan proxy dapat menggunakan mode penyeimbangan UTILIZATION. Backend NEG tidak mendukung mode penyeimbangan ini.

Mode penyeimbangan UTILIZATION bergantung pada pemakaian CPU VM bersama dengan faktor lainnya. Saat faktor-faktor ini berfluktuasi, load balancer dapat menghitung pemanfaatan dengan cara yang menyebabkan beberapa VM menerima lebih banyak permintaan atau koneksi daripada yang lain. Oleh karena itu, perhatikan hal-hal berikut:

  • Hanya gunakan mode penyeimbangan UTILIZATION dengan afinitas sesi yang ditetapkan ke NONE. Jika layanan backend Anda menggunakan afinitas sesi yang berbeda dari NONE, gunakan mode balancing RATE, IN-FLIGHT, atau CONNECTION.

  • Jika pemakaian rata-rata VM di semua grup instance kurang dari 10%, beberapa load balancer lebih memilih untuk mendistribusikan permintaan atau koneksi baru ke zona tertentu. Preferensi zona ini menjadi kurang umum saat rasio permintaan atau jumlah koneksi meningkat.

Mode penyeimbangan UTILIZATION tidak memiliki setelan kapasitas target wajib, tetapi Anda dapat secara opsional menentukan kapasitas target dengan menggunakan salah satu parameter kapasitas target atau kombinasi parameter kapasitas target yang dijelaskan di bagian berikut.

Parameter kapasitas target pemanfaatan untuk backend Load Balancer Aplikasi dan Cloud Service Mesh dengan setelan durasi traffic yang tidak ditentukan atau singkat

Backend Application Load Balancer dan Cloud Service Mesh dengan setelan durasi traffic yang tidak ditentukan atau singkat (Pratinjau) dapat menggunakan mode penyeimbangan UTILIZATION dengan salah satu parameter kapasitas target berikut atau kombinasi parameter:

Tabel: Parameter kapasitas target mode penyeimbangan UTILIZATION dan kombinasi parameter untuk backend Load Balancer Aplikasi dan Cloud Service Mesh dengan setelan durasi traffic yang tidak ditentukan atau singkat
Parameter kapasitas target atau kombinasi parameter Backend yang didukung
Grup instance (terkelola atau tidak terkelola) zona Grup instance terkelola regional NEG zona dengan endpoint GCE_VM_IP_PORT NEG dengan konektivitas hybrid zona
max-utilization
Target pemanfaatan per zona backend
max-rate
Target kecepatan permintaan HTTP per zona backend
max-rate dan max-utilization
Target adalah yang pertama dicapai di zona backend:
  • Target pemanfaatan zona
  • Target kecepatan permintaan HTTP zona
max-rate-per-instance
Target kecepatan permintaan HTTP per instance VM. Cloud Load Balancing menggunakan parameter ini untuk menghitung rasio permintaan HTTP target per zona backend.
max-rate-per-instance dan max-utilization
Target adalah yang pertama kali dicapai di zona backend:
  • Target pemanfaatan zona
  • Target kecepatan permintaan HTTP zona (dihitung dari target kecepatan permintaan HTTP per instance VM dari VM di zona)

Untuk mengetahui informasi selengkapnya tentang parameter kapasitas target max-rate dan max-rate-per-instance, lihat Mode penyeimbangan kecepatan dalam dokumen ini.

Parameter kapasitas target pemanfaatan untuk backend Load Balancer Aplikasi dan Cloud Service Mesh dengan setelan durasi traffic yang panjang

Backend Load Balancer Aplikasi dan Cloud Service Mesh dengan setelan durasi traffic yang panjang (Pratinjau) dapat menggunakan mode penyeimbangan UTILIZATION dengan salah satu parameter kapasitas target berikut atau kombinasi parameter:

Tabel: Parameter dan kombinasi parameter kapasitas target mode penyeimbangan UTILIZATION untuk backend Cloud Service Mesh dan Application Load Balancer dengan setelan durasi traffic yang panjang (Pratinjau)
Parameter kapasitas target atau kombinasi parameter Backend yang didukung
Grup instance (terkelola atau tidak terkelola) zona Grup instance terkelola regional NEG zona dengan endpoint GCE_VM_IP_PORT NEG dengan konektivitas hybrid zona
max-utilization
Target pemanfaatan per zona backend
max-in-flight-requests
Jumlah target permintaan HTTP yang sedang berlangsung per zona backend
max-in-flight-requests dan max-utilization
Target adalah yang pertama dicapai di zona backend:
  • Target pemanfaatan zona
  • Jumlah target permintaan HTTP yang sedang berlangsung di zona
max-in-flight-requests-per-instance
Jumlah target permintaan HTTP yang sedang berlangsung per instance VM. Cloud Load Balancing menggunakan parameter ini untuk menghitung jumlah target permintaan HTTP yang sedang berlangsung per zona backend.
max-in-flight-requests-per-instance dan max-utilization
Target adalah yang pertama kali dicapai di zona backend:
  • Target pemanfaatan zona
  • Jumlah target permintaan HTTP yang sedang berlangsung di zona (dihitung dari jumlah target permintaan HTTP yang sedang berlangsung per instance VM dari VM di zona)

Untuk mengetahui informasi selengkapnya tentang parameter kapasitas target max-in-flight-requests dan max-in-flight-requests-per-instance, lihat Mode penyeimbangan dalam proses dalam dokumen ini.

Parameter kapasitas target pemanfaatan untuk Load Balancer Jaringan proxy

Backend grup instance Load Balancer Jaringan proxy dapat menggunakan mode penyeimbangan UTILIZATION dengan salah satu parameter kapasitas target berikut atau kombinasi parameter.

Tabel: Parameter dan kombinasi parameter kapasitas target mode penyeimbangan UTILIZATION untuk backend Load Balancer Jaringan proxy
Parameter kapasitas target atau kombinasi parameter Backend yang didukung
Grup instance (terkelola atau tidak terkelola) zona Grup instance terkelola regional NEG zona dengan endpoint GCE_VM_IP_PORT NEG dengan konektivitas hybrid zona
max-utilization
Target pemanfaatan per zona backend
max-connections
Koneksi TCP target per zona backend
max-connections dan max-utilization
Target adalah yang pertama dicapai di zona backend:
  • Target pemanfaatan zona
  • Koneksi TCP target zona
max-connections-per-instance
Menargetkan koneksi TCP per instance VM. Cloud Load Balancing menggunakan parameter ini untuk menghitung koneksi TCP target per zona backend.
max-connections-per-instance dan max-utilization
Target adalah yang pertama kali dicapai di zona backend:
  • Target pemanfaatan zona
  • Koneksi TCP target zona (dihitung dari koneksi TCP target per instance VM dari VM di zona)

Untuk mengetahui informasi selengkapnya tentang parameter kapasitas target max-connections dan max-connections-per-instance, lihat Mode penyeimbangan koneksi dalam dokumen ini.

Mode penyeimbangan metrik kustom

Backend Load Balancer Aplikasi dan Load Balancer Jaringan proxy dapat menggunakan mode load balancing CUSTOM_METRICS. Metrik kustom memungkinkan Anda menentukan kapasitas target berdasarkan data aplikasi atau infrastruktur yang paling penting bagi Anda. Untuk mengetahui informasi selengkapnya, lihat Metrik kustom untuk Load Balancer Aplikasi.

Mode penyeimbangan CUSTOM_METRICS tidak memiliki setelan kapasitas target wajib, tetapi Anda dapat menentukan kapasitas target secara opsional menggunakan salah satu parameter kapasitas target atau kombinasi parameter kapasitas target yang dijelaskan di bagian berikut.

Parameter kapasitas target metrik kustom untuk backend Load Balancer Aplikasi dengan setelan durasi traffic yang tidak ditentukan atau singkat

Backend Load Balancer Aplikasi dengan setelan durasi traffic yang tidak ditentukan atau singkat (Pratinjau) dapat menggunakan mode penyeimbangan CUSTOM_METRICS dengan salah satu parameter kapasitas target berikut atau kombinasi parameter:

Tabel: Parameter kapasitas target mode penyeimbangan CUSTOM_METRICS dan kombinasi parameter untuk backend Load Balancer Aplikasi dengan setelan durasi traffic yang tidak ditentukan atau singkat
Parameter kapasitas target atau kombinasi parameter Backend yang didukung
Grup instance (terkelola atau tidak terkelola) zona Grup instance terkelola regional NEG zona dengan endpoint GCE_VM_IP_PORT NEG dengan konektivitas hybrid zona
backends[].customMetrics[].maxUtilization
Target pemanfaatan metrik kustom per zona backend
max-rate
Target kecepatan permintaan HTTP per zona backend
max-rate dan backends[].customMetrics[].maxUtilization
Target adalah yang pertama kali dicapai di zona backend:
  • Penggunaan metrik kustom target zona
  • Target kecepatan permintaan HTTP zona
max-rate-per-instance
Target kecepatan permintaan HTTP per instance VM. Cloud Load Balancing menggunakan parameter ini untuk menghitung rasio permintaan HTTP target per zona backend.
max-rate-per-instance dan backends[].customMetrics[].maxUtilization
Target adalah yang pertama kali dicapai di zona backend:
  • Penggunaan metrik kustom target zona
  • Target kecepatan permintaan HTTP zona (dihitung dari target kecepatan permintaan HTTP per instance VM dari VM di zona)
max-rate-per-endpoint
Target kecepatan permintaan HTTP per endpoint NEG. Cloud Load Balancing menggunakan parameter ini untuk menghitung rasio permintaan HTTP target per zona backend.
max-rate-per-endpoint dan backends[].customMetrics[].maxUtilization
Target adalah yang pertama kali dicapai di zona backend:
  • Penggunaan metrik kustom target zona
  • Target kecepatan permintaan HTTP zona (dihitung dari target kecepatan permintaan HTTP per endpoint NEG dari endpoint di zona)

Untuk mengetahui informasi selengkapnya tentang parameter kapasitas target max-rate, max-rate-per-instance, dan max-rate-per-endpoint, lihat Mode penyeimbangan rasio dalam dokumen ini.

Parameter kapasitas target metrik kustom untuk backend Load Balancer Aplikasi dengan setelan durasi traffic yang panjang

Backend Load Balancer Aplikasi dengan setelan durasi traffic yang panjang dapat menggunakan mode penyeimbangan CUSTOM_METRICS dengan salah satu parameter kapasitas target berikut atau kombinasi parameter:

Tabel: Target mode penyeimbangan CUSTOM_METRICS kapasitas dan kombinasi parameter untuk backend Load Balancer Aplikasi dengan setelan durasi traffic yang panjang (Pratinjau)
Parameter kapasitas target atau kombinasi parameter Backend yang didukung
Grup instance (terkelola atau tidak terkelola) zona Grup instance terkelola regional NEG zona dengan endpoint GCE_VM_IP_PORT NEG dengan konektivitas hybrid zona
backends[].customMetrics[].maxUtilization
Target pemanfaatan metrik kustom per zona backend
max-in-flight-requests
Jumlah target permintaan HTTP yang sedang berlangsung per zona backend
max-in-flight-requests dan backends[].customMetrics[].maxUtilization
Target adalah yang pertama kali dicapai di zona backend:
  • Penggunaan metrik kustom target zona
  • Jumlah target permintaan HTTP yang sedang berlangsung di zona
max-in-flight-requests-per-instance
Jumlah target permintaan HTTP yang sedang berlangsung per instance VM. Cloud Load Balancing menggunakan parameter ini untuk menghitung jumlah target permintaan HTTP yang sedang berlangsung per zona backend.
max-in-flight-requests-per-instance dan backends[].customMetrics[].maxUtilization
Target adalah yang pertama kali dicapai di zona backend:
  • Penggunaan metrik kustom target zona
  • Jumlah target permintaan HTTP yang sedang berlangsung di zona (dihitung dari jumlah target permintaan HTTP yang sedang berlangsung per instance VM dari VM di zona)
max-in-flight-requests-per-endpoint
Jumlah target permintaan HTTP yang sedang berlangsung per endpoint NEG. Load balancing menggunakan parameter ini untuk menghitung target jumlah permintaan HTTP yang sedang berlangsung per zona backend.
max-in-flight-requests-per-endpoint dan backends[].customMetrics[].maxUtilization
Target adalah yang pertama kali dicapai di zona backend:
  • Penggunaan metrik kustom target zona
  • Jumlah target permintaan HTTP yang sedang berlangsung di zona (dihitung dari jumlah target permintaan HTTP yang sedang berlangsung per endpoint NEG dari endpoint di zona)

Untuk mengetahui informasi selengkapnya tentang parameter kapasitas target max-in-flight-requests, max-in-flight-requests-per-instance, dan max-flight-requests-per-endpoint, lihat Mode penyeimbangan dalam proses.

Kebijakan load balancing layanan

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

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

Selain itu, Anda dapat menetapkan backend tertentu sebagai backend pilihan. Backend ini harus digunakan hingga kapasitasnya (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.

Kebijakan lokalitas load balancing

Untuk layanan backend, distribusi traffic didasarkan pada mode load balancing 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 konstituen.

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

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

  • WEIGHTED_ROUND_ROBIN: Load balancer menggunakan metrik kustom yang ditentukan pengguna untuk memilih instance atau endpoint yang optimal dalam backend untuk melayani permintaan.

  • LEAST_REQUEST: Algoritma O(1) yang load balancernya 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 memiliki properti bahwa penambahan atau penghapusan host dari satu set host N hanya memengaruhi 1/N dari 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 asli 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: Menerapkan 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 mengetahui 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 respons health check diharapkan berisi kolom header respons HTTP non-standar, X-Load-Balancing-Endpoint-Weight, untuk menentukan bobot per instance. Keputusan penyeimbangan beban dibuat berdasarkan bobot per instance yang dilaporkan dalam respons health check terakhir yang 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. Untuk mengetahui contohnya, lihat Menyiapkan load balancing berbobot untuk Load Balancer Jaringan passthrough eksternal.

Mengonfigurasi kebijakan lokalitas load balancing hanya didukung pada 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 proxy eksternal global
  • Load Balancer Jaringan proxy eksternal regional
  • Load Balancer Jaringan proxy internal lintas region
  • Load Balancer Jaringan proxy internal regional
  • Load Balancer Jaringan passthrough eksternal

Perhatikan bahwa nilai default efektif kebijakan lokalitas load balancing (localityLbPolicy) berubah sesuai dengan setelan afinitas sesi Anda. Jika afinitas sesi tidak dikonfigurasi—yaitu, jika afinitas sesi tetap pada nilai default NONE—maka nilai default untuk localityLbPolicy adalah ROUND_ROBIN. Jika afinitas sesi ditetapkan ke nilai selain NONE, maka nilai default untuk localityLbPolicy adalah MAGLEV.

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

Subsetting backend

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

Subsetting backend didukung untuk berikut ini:

  • Load Balancer Aplikasi internal regional
  • Load Balancer Jaringan passthrough internal

Subkumpulan backend untuk Load Balancer Aplikasi internal regional

Load Balancer Aplikasi internal lintas region tidak mendukung subset backend.

Untuk Load Balancer Aplikasi internal regional, subset backend secara otomatis menetapkan hanya subset 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 subset, setiap proxy hanya membuka koneksi ke subset 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 subsetting backend, traffic dari kedua proxy didistribusikan ke semua backend di layanan backend 1. Dengan subset backend diaktifkan, traffic dari setiap proxy didistribusikan ke subset 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 subset backend.
Membandingkan Load Balancer Aplikasi internal tanpa dan dengan penyusunan subset backend (klik untuk memperbesar).

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

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

Peringatan terkait subset backend untuk Load Balancer Aplikasi internal

  • Meskipun dirancang untuk memastikan semua instance backend tetap dimanfaatkan dengan baik, subset backend dapat menimbulkan 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 subsetting akan menghentikan koneksi yang ada.
  • Subsetelan backend mengharuskan afinitas sesi adalah NONE (hash 5 tuple). Opsi afinitas sesi lainnya hanya dapat digunakan jika subset backend dinonaktifkan. Nilai default flag --subsetting-policy dan --session-affinity adalah NONE, dan hanya salah satu flag yang dapat disetel ke nilai yang berbeda dalam satu waktu.

Subset backend untuk Load Balancer Jaringan passthrough internal

Subsetelan 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 pembuatan subset terhadap batas ini, lihat Layanan backend di "Kuota dan batas".

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

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

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

Tanpa subset, set lengkap backend yang berfungsi baik akan dimanfaatkan dengan lebih baik, dan koneksi klien baru akan didistribusikan di antara semua backend yang berfungsi baik sesuai dengan distribusi traffic. Subsetting menerapkan batasan load balancing, tetapi memungkinkan load balancer mendukung lebih dari 250 backend.

Untuk mengetahui petunjuk konfigurasi, lihat Subsetting.

Peringatan terkait subset backend untuk Load Balancer Jaringan passthrough internal

  • Jika subset diaktifkan, tidak semua backend akan menerima traffic dari pengirim tertentu, meskipun jumlah backend kecil.
  • Untuk jumlah maksimum instance backend saat subset diaktifkan, lihat halaman kuota .
  • Hanya afinitas sesi 5-tuple yang didukung dengan subset.
  • Duplikasi Paket tidak didukung dengan subsetting.
  • Mengaktifkan atau menonaktifkan subsetting akan menghentikan koneksi yang ada.
  • Jika klien lokal perlu mengakses Load Balancer Jaringan passthrough internal, subsetting dapat secara signifikan 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. Subkumpulan yang berbeda digunakan di berbagai wilayah.

Harga subset backend

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

Afinitas sesi

Afinitas sesi memungkinkan Anda mengontrol cara load balancer memilih backend untuk koneksi baru secara terprediksi 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 mencakup server stateful yang digunakan oleh penayangan iklan, game, atau layanan dengan caching internal yang berat.

Load balancerGoogle Cloud menyediakan afinitas sesi berdasarkan upaya terbaik. Faktor-faktor seperti perubahan status pemeriksaan kondisi backend, penambahan atau penghapusan backend, perubahan bobot backend (termasuk mengaktifkan atau menonaktifkan penyeimbangan berbobot), atau perubahan kepenuhan backend, sebagaimana diukur oleh mode penyeimbangan, dapat merusak afinitas sesi.

Penyeimbangan beban 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 dari 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 mempelajari lebih lanjut afinitas sesi untuk Load Balancer Jaringan passthrough, lihat dokumen berikut:

Untuk mempelajari lebih lanjut afinitas sesi untuk Load Balancer Aplikasi, lihat dokumen berikut:

Untuk mempelajari lebih lanjut afinitas sesi untuk Load Balancer Jaringan proxy, lihat dokumen berikut:

Waktu tunggu layanan backend

Sebagian besar load balancer memiliki waktu tunggu layanan backend. Google Cloud Nilai default-nya 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 Jaringan proxy eksternal dan Load Balancer Jaringan proxy internal, waktu tunggu layanan backend yang dikonfigurasi adalah durasi waktu load balancer mempertahankan koneksi TCP tetap terbuka jika tidak ada data yang dikirim dari klien atau backend. Setelah waktu ini berlalu tanpa ada data yang ditransmisikan, proxy akan menutup koneksi.

    • Nilai default: 30 detik
    • Rentang yang dapat dikonfigurasi: 1 hingga 2.147.483.647 detik

  • 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 diabaikan. Waktu tunggu layanan backend tidak memiliki arti 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, konfigurasi 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 berupa grup instance atau NEG zonal harus memiliki health check terkait. Layanan backend yang menggunakan NEG serverless atau NEG internet global sebagai backend tidak boleh merujuk ke 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 mengetahui informasi selengkapnya, baca dokumen berikut:

Fitur tambahan diaktifkan pada 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 pada layanan backend yang digunakan oleh Load Balancer Aplikasi eksternal global. Load balancer menyediakan alamat IP dan port frontend yang menerima permintaan, serta 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.

Cloud Armor

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

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

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

IAP

Dengan IAP, Anda dapat membuat lapisan otorisasi pusat untuk aplikasi yang diakses oleh HTTPS, sehingga 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:

API dan referensi gcloud

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

Langkah berikutnya

Untuk dokumentasi terkait dan informasi tentang cara penggunaan layanan backend dalam penyeimbangan beban, tinjau artikel berikut:

Untuk video terkait: