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 dapat bersifat global atau regional dalam cakupannya.

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

  • Mengarahkan traffic 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 kesehatan 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 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 menyajikan 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: NEG jenis GCE_VM_IP_PORT dan NON_GCP_PRIVATE_IP_PORT †
  • Semua NEG serverless: Satu atau beberapa resource App Engine, Cloud Run, atau fungsi Cloud Run
  • 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: NEG jenis GCE_VM_IP_PORT dan NON_GCP_PRIVATE_IP_PORT †
  • Semua NEG serverless: Satu atau beberapa resource App Engine, Cloud Run, atau fungsi Cloud Run, 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: NEG jenis GCE_VM_IP_PORT dan NON_GCP_PRIVATE_IP_PORT †
  • Satu NEG serverless (khusus 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: NEG jenis GCE_VM_IP_PORT dan NON_GCP_PRIVATE_IP_PORT †
  • Satu NEG serverless (khusus 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: NEG jenis GCE_VM_IP_PORT dan NON_GCP_PRIVATE_IP_PORT †
  • Satu NEG serverless (khusus 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: 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 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 †
 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
  • NEG pemetaan port tunggal
 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 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 Tingkat 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 eksternal klasik ke 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 nama load balancer yang Anda masukkan.
  • 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 penamaan 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 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. Proxy Envoy 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.

    • 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 asli 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 dikirimkan 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 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 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 akan menggunakan nomor port ini untuk berkomunikasi 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 tanpa server 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 batasan dan panduan berikut saat Anda membuat grup instance untuk load balancer:

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

    Jika Anda ingin VM 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 buat 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 penyeimbangan harus sama, atau harus berupa kombinasi mode penyeimbangan yang kompatibel—misalnya, CONNECTION dan RATE.

    Kombinasi mode penyeimbangan yang tidak kompatibel adalah sebagai berikut:

    • CONNECTION dengan UTILIZATION
    • RATE dengan UTILIZATION
    • CUSTOM_METRICS dengan UTILIZATION
    • CUSTOM_METRICS dengan RATE
    • CUSTOM_METRICS dengan CONNECTION

    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 bernama instance-group-a di internal-tcp-backend-service.
    • Di internal-tcp-backend-service, Anda harus menerapkan mode penyeimbangan CONNECTION karena Load Balancer Jaringan passthrough internal hanya mendukung mode penyeimbangan CONNECTION.
    • Anda juga dapat menggunakan instance-group-a di external-https-backend-service jika Anda menerapkan mode penyeimbangan RATE di external-https-backend-service.
    • Anda juga tidak dapat menggunakan instance-group-a di external-https-backend-service dengan mode penyeimbangan 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 pada satu layanan backend yang tersisa.
    • Tambahkan kembali grup instance sebagai backend ke layanan backend yang tersisa, jika layanan tersebut 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 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 Penggunaan Load Balancing HTTP.

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

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.

Grup endpoint jaringan (NEG) zona adalah resource zonal yang merepresentasikan 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 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 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 di 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 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, fungsi Cloud Run, atau API Gateway.

NEG tanpa server dapat merepresentasikan salah satu hal berikut:

  • Resource Cloud Run atau sekelompok resource.
  • Fungsi Cloud Run atau grup fungsi (sebelumnya Cloud Run functions generasi ke-2).
  • Cloud Run function (generasi ke-1) atau grup fungsi
  • 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 tanpa server bagi aplikasi tanpa server 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, fungsi Cloud Run, 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

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 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 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
Mesh Layanan Cloud 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 sehat 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 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 yang pada akhirnya memilih koneksi mana yang akan digunakan.
Khusus IPv6

Hanya mengirim traffic IPv6 ke backend layanan backend, terlepas dari traffic dari klien ke proxy. Health check IPv6 saja 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 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.

Distribusi traffic

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

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

Balancing mode

Mode load balancing menentukan apakah backend load balancer atau Cloud Service Mesh dapat menangani traffic tambahan atau sudah memiliki beban penuh.

Google Cloud memiliki empat mode penyeimbangan:

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

Mode penyeimbangan yang tersedia untuk setiap load balancer

Anda menetapkan mode load 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 target kapasitas.

Load Balancer Aplikasi mendukung mode balancing RATE, UTILIZATION, atau CUSTOM_METRICS untuk backend grup instance, dan mode balancing RATE atau CUSTOM_METRICS untuk NEG zonal (endpoint GCE_VM_IP_PORT) dan NEG hybrid (endpoint NON_GCP_PRIVATE_IP_PORT). Untuk jenis backend lain yang didukung, mode penyeimbangan 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 load balancing digunakan untuk menghitung proporsi jumlah permintaan yang harus ditujukan 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 suatu region, kapasitas target mode load balancing digunakan untuk menghitung proporsi jumlah permintaan yang harus ditujukan ke setiap backend (grup instance atau NEG) di region tersebut. 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 load balancing digunakan untuk menghitung proporsi jumlah permintaan yang harus ditujukan 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 hybrid (endpoint NON_GCP_PRIVATE_IP_PORT). Untuk jenis backend lain yang didukung, mode penyeimbangan 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 suatu region, kapasitas target mode load balancing digunakan untuk menghitung proporsi jumlah permintaan yang harus ditujukan ke setiap backend (grup instance atau NEG) di region tersebut. 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 suatu region, kapasitas target mode load balancing digunakan untuk menghitung proporsi jumlah permintaan yang harus ditujukan ke setiap backend (grup instance atau NEG) di region tersebut. 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 ditujukan ke setiap backend (grup instance atau NEG) di region tersebut. Setelah load balancer memilih backend, permintaan atau koneksi akan 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 ditujukan 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 merangkum mode load balancing yang tersedia untuk setiap kombinasi load balancer dan backend.

Tabel: Mode penyeimbangan yang tersedia untuk setiap load balancer
Load balancer Backend Mode penyeimbangan yang tersedia
Load Balancer Aplikasi Grup instance RATE, UTILIZATION, atau CUSTOM_METRICS
NEG zona (endpoint GCE_VM_IP_PORT) RATE atau CUSTOM_METRICS
NEG Hybrid (endpoint NON_GCP_PRIVATE_IP_PORT) RATE atau CUSTOM_METRICS

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

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 zonal di zona yang berbeda, dan grup instance tidak terkelola zonal. Ketidakseimbangan per zona ini akan otomatis teratasi saat lebih banyak traffic 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 bukanlah pemutus sirkuit. Load balancer dapat melampaui nilai maksimum dalam kondisi tertentu, misalnya, jika semua VM atau endpoint backend telah mencapai nilai maksimum.

Mode penyeimbangan koneksi

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

  • max-connections-per-instance (per VM): Jumlah koneksi rata-rata target untuk satu VM.
  • max-connections-per-endpoint (per endpoint di NEG zona): Jumlah target rata-rata koneksi untuk satu endpoint.
  • max-connections (per NEG zona dan untuk grup instance zona): Jumlah koneksi rata-rata target 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: Target kapasitas untuk backend menggunakan mode load balancing KONEKSI
Jenis backend Kapasitas target
Jika Anda menentukan Kapasitas backend keseluruhan Kapasitas yang diharapkan per instance atau per endpoint
Grup instance
N instance,
H sehat
 max-connections-per-instance=X X × N (X × N)/H
Endpoint NEG
N zona,
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 koneksi maksimum untuk seluruh grup instance VM atau seluruh NEG zona:

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

Mode penyeimbangan rasio

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

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

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: Target kapasitas untuk backend menggunakan mode load balancing RATE
Jenis backend Kapasitas target
Jika Anda menentukan Kapasitas backend keseluruhan Kapasitas yang diharapkan per instance atau per endpoint
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 laju maksimum permintaan HTTP untuk seluruh grup instance atau seluruh NEG zona:

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

Mode penyeimbangan pemakaian

Mode balancing UTILIZATION tidak memiliki kapasitas target wajib. Anda memiliki sejumlah opsi yang bergantung pada jenis backend, seperti yang diringkas 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 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.

Mode penyeimbangan metrik kustom

Mode balancing CUSTOM_METRICS memungkinkan Anda menentukan metrik kustom sendiri yang dapat digunakan untuk menentukan cara penyebaran beban. Metrik kustom memungkinkan Anda mengonfigurasi perilaku distribusi traffic load balancer agar didasarkan pada metrik khusus untuk persyaratan aplikasi atau infrastruktur Anda, bukan metrik berbasis tarif atau penggunaan standarGoogle Cloud.

Untuk mengetahui informasi selengkapnya, lihat Metrik kustom untuk Load Balancer Aplikasi.

Mengubah mode load 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 lain, bergantung pada backend yang digunakan, Anda dapat mengubah mode penyeimbangan 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 target maksimum 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 pengisian berlebih.

Load Balancer Aplikasi dan Cloud Service Mesh

Tabel ini mencantumkan kombinasi mode penyeimbangan dan kapasitas target yang tersedia untuk Load Balancer Aplikasi 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
  • tidak dikelola zonal
  • terkelola zonal
  • dikelola regional
 RATE Anda harus menentukan salah satu opsi 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 opsi 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) bersama-sama
CUSTOM_METRICS Anda dapat secara opsional menentukan salah satu opsi berikut:
  • (1) max-utilization metrik (yaitu, kolom backends[].customMetrics[].maxUtilization metrik)
  • (2) max-rate
     (hanya didukung oleh grup instance zonal)
  • (3) max-rate-per-instance
     (didukung oleh semua grup instance)
  • (1) dan (2) bersama-sama
  • (1) dan (3) bersama-sama
max-utilization per backend tidak didukung.

NEG Zona

  • GCP_VM_IP_PORT

NEG Hybrid

  • NON_GCP_PRIVATE_IP_PORT
 RATE Anda harus menentukan salah satu opsi berikut:
  • max-rate per NEG zona
  • max-rate-per-endpoint
CUSTOM_METRICS Anda dapat secara opsional menentukan salah satu opsi berikut:
  • (1) max-utilization metrik (yaitu, kolom backends[].customMetrics[].maxUtilization metrik)
  • (2) max-rate per NEG zona
  • (3) max-rate-per-endpoint
  • (1) dan (2) bersama-sama
  • (1) dan (3) bersama-sama
max-utilization per backend tidak didukung.

Load Balancer Jaringan Proxy

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

Tabel: Kombinasi mode penyeimbangan dan kapasitas target untuk Load Balancer Jaringan Proxy
Jenis backend Balancing mode Spesifikasi kapasitas target
Grup instance
  • tidak dikelola zonal
  • terkelola zonal
  • dikelola regional
 CONNECTION Anda harus menentukan salah satu opsi 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 opsi 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) bersama-sama

NEG Zona

  • GCP_VM_IP_PORT

NEG Hybrid

  • NON_GCP_PRIVATE_IP_PORT
 CONNECTION Anda harus menentukan salah satu opsi berikut:
  • max-connections per NEG zona
  • max-connections-per-endpoint

Load Balancer Jaringan passthrough

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

Tabel: Kombinasi mode penyeimbangan dan kapasitas target untuk Load Balancer Jaringan Passthrough
Jenis backend Balancing mode Spesifikasi kapasitas target
Grup instance
  • tidak dikelola zonal
  • terkelola zonal
  • dikelola regional
 CONNECTION Anda tidak dapat menentukan jumlah maksimum target koneksi.
NEG Zona
  • GCP_VM_IP
 CONNECTION Anda tidak dapat menentukan jumlah maksimum target koneksi.

Penskala kapasitas

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

Untuk dokumentasi referensi Google Cloud , lihat berikut ini:

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

Anda dapat menyetel penskala 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 terlampir 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 pengubah skala 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 penskala kapasitas adalah 0.0, kapasitas yang tersedia adalah nol (0).

Kebijakan load balancing layanan

Kebijakan load balancing layanan (serviceLbPolicy) adalah resource yang terkait dengan backend service load balancer. Dengan fitur ini, 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 lainnya.

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

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 load balancing backend. Kemudian, Cloud Service Mesh mendistribusikan traffic sesuai dengan kebijakan load balancing.

Layanan backend yang dikelola sendiri secara internal mendukung mode penyeimbangan berikut:

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

Jika memilih mode penyeimbangan RATE, Anda harus menentukan laju maksimum, laju maksimum per instance, atau laju maksimum per endpoint.

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

Sub-setelan backend

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

Subkumpulan 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 subsetting, 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. Jika subset backend diaktifkan, traffic dari setiap proxy akan 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 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 Mengonfigurasi subset backend.

Peringatan terkait subset backend untuk Load Balancer Aplikasi internal
  • Meskipun subset backend dirancang untuk memastikan semua instance backend tetap dimanfaatkan dengan baik, hal ini 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 jumlah instance VM backend yang lebih besar per layanan backend internal.

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

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 subsetting. 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 subsetting, set lengkap backend yang sehat akan lebih baik dimanfaatkan, dan koneksi klien baru didistribusikan di antara semua backend yang sehat sesuai dengan distribusi traffic. Subset 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 mengetahui 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 sub-setelan 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.

Penyeimbang bebanGoogle 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 Network Load Balancer passthrough, lihat dokumen berikut:

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 maksimum, permintaan atau koneksi berikutnya akan menuju 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
  • Tidak ada (NONE)
  • IP Klien (CLIENT_IP)
  • Cookie yang dihasilkan (GENERATED_COOKIE)
  • Kolom header (HEADER_FIELD)
  • Cookie HTTP (HTTP_COOKIE)
  • Afinitas berbasis cookie stateful (STRONG_COOKIE_AFFINITY)

Perhatikan juga:

  • Nilai default efektif kebijakan lokalitas load balancing (localityLbPolicy) berubah sesuai dengan setelan afinitas sesi Anda. Jika afinitas sesi tidak dikonfigurasi—yaitu, jika afinitas sesi tetap pada nilai default NONE—maka nilai default untuk localityLbPolicy adalah ROUND_ROBIN. Jika afinitas sesi ditetapkan ke nilai selain NONE, maka nilai default untuk localityLbPolicy adalah MAGLEV.
  • Untuk Load Balancer Aplikasi eksternal global, jangan konfigurasi afinitas sesi jika Anda menggunakan pembagian 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)
  • Tidak ada (NONE)
  • IP Klien (CLIENT_IP)
  • Cookie yang dihasilkan (GENERATED_COOKIE)
  • Kolom header (HEADER_FIELD)
  • Cookie HTTP (HTTP_COOKIE)
  • Afinitas berbasis cookie stateful (STRONG_COOKIE_AFFINITY)

Perhatikan juga:

  • Nilai default efektif kebijakan lokalitas load balancing (localityLbPolicy) berubah sesuai dengan setelan afinitas sesi Anda. Jika afinitas sesi tidak dikonfigurasi—yaitu, jika afinitas sesi tetap pada nilai default NONE—maka nilai default untuk localityLbPolicy adalah ROUND_ROBIN. Jika afinitas sesi ditetapkan ke nilai selain NONE, maka nilai default untuk localityLbPolicy adalah MAGLEV.
  • Untuk Load Balancer Aplikasi internal, jangan konfigurasi afinitas sesi jika Anda menggunakan pembagian 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 mengetahui informasi spesifik tentang Load Balancer Jaringan passthrough internal dan afinitas sesi, lihat Distribusi traffic untuk 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 mengetahui informasi spesifik tentang Load Balancer Jaringan passthrough eksternal dan afinitas sesi, lihat Distribusi traffic untuk Load Balancer Jaringan passthrough eksternal.
  • 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) (hanya 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 afinitas sesi berbasis cookie stateful, dirancang untuk terputus setiap kali jumlah backend yang melayani dan sehat berubah. Untuk mengetahui detail selengkapnya, lihat Kehilangan afinitas sesi.

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

Jenis afinitas sesi

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 hanya alamat IP sumber 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 memperhatikan alamat IP tujuan paket. Situasi ini biasanya terjadi saat Load Balancer Jaringan passthrough internal menjadi 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 yang menggunakan layanan backend. Google Cloud Load Balancer Jaringan passthrough eksternal memanggil opsi afinitas sesi ini IP Klien, IP Tujuan.

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

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

  • 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 dikirimkan ke load balancer Google Cloud . Dalam situasi ketika banyak klien berbagi alamat IP sumber efektif yang sama, beberapa VM backend mungkin menerima lebih banyak koneksi atau permintaan daripada yang lain.

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

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 default adalah 0.

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

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

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

Untuk mengetahui informasi selengkapnya, lihat kehilangan afinitas sesi.

Afinitas kolom header

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

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.

Saat 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 dan pecahan detik (sebagai nanodetik) menggunakan parameter layanan backend dan nilai yang valid berikut:

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

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

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

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

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

Untuk mengetahui informasi selengkapnya, lihat kehilangan afinitas sesi.

Afinitas sesi berbasis cookie stateful

Saat Anda menggunakan afinitas berbasis cookie stateful, 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 plus pecahan detik (sebagai nanodetik). Durasi yang diwakili oleh strongSessionAffinityCookie.ttl tidak boleh ditetapkan ke nilai yang mewakili lebih dari dua minggu (1.209.600 detik).

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

Tidak seperti metode afinitas sesi lainnya:

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

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

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

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

Untuk mengetahui informasi selengkapnya, lihat kehilangan afinitas sesi.

Arti TTL nol untuk afinitas berbasis cookie

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

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

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

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

Kehilangan afinitas sesi

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

  • Endpoint atau instance backend yang dipilih harus tetap dikonfigurasi sebagai backend. Afinitas sesi dapat terganggu saat salah satu peristiwa berikut terjadi:

    • Anda menghapus instance yang dipilih dari grup instancenya.

    • Penskalaan otomatis atau autohealing grup instance terkelola 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.

  • Endpoint atau instance backend yang dipilih harus tetap responsif. Afinitas sesi dapat terganggu saat instance atau endpoint yang dipilih gagal dalam pemeriksaan kondisi.

  • 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 terganggu jika Google Front End (GFE) lapisan pertama yang berbeda digunakan untuk permintaan atau koneksi berikutnya setelah perubahan jalur perutean. GFE lapisan pertama yang berbeda mungkin dipilih jika jalur perutean dari klien di internet ke Google berubah di antara permintaan atau koneksi.

Kecuali afinitas sesi berbasis cookie stateful, semua opsi afinitas sesi 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 targetnya. (Untuk grup instance terkelola regional, komponen zonal grup instance yang berisi instance yang dipilih tidak boleh penuh.) Afinitas sesi dapat terganggu saat grup instance atau NEG penuh dan grup instance atau NEG lainnya tidak. Karena kepenuhan dapat berubah dengan cara yang tidak dapat diprediksi saat menggunakan mode penyeimbangan UTILIZATION, Anda harus menggunakan mode penyeimbangan RATE atau CONNECTION untuk meminimalkan situasi saat afinitas sesi dapat terganggu.

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

    • Menambahkan instance atau endpoint baru:

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

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

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

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

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

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, waktu tunggu adalah waktu tunggu tidak ada aktivitas. Untuk mengizinkan lebih banyak atau lebih sedikit waktu 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 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 zonasi harus memiliki health check terkait. Layanan backend yang menggunakan NEG tanpa server 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 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 pada layanan backend yang digunakan oleh Load Balancer Aplikasi eksternal global. Load balancer menyediakan port dan alamat IP 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.

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:

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

  • Pilih kebijakan keamanan Google Cloud Armor yang ada.
  • Terima konfigurasi kebijakan keamanan pembatasan frekuensi default Google Cloud Armor dengan nama, jumlah permintaan, interval, kunci, dan parameter pembatasan frekuensi 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 menonaktifkan perlindungan Google 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: