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

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 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
• Tetapkan layanan backend global dan regional sebagai layanan di aplikasi Pusat Aplikasi.

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

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.

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 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:

• Grup instance yang berisi instance virtual machine (VM). Grup instance dapat berupa grup instance terkelola (MIG), dengan atau tanpa penskalaan otomatis, atau dapat berupa grup instance tidak terkelola. Lebih dari satu layanan backend dapat mereferensikan grup instance, tetapi semua layanan backend yang mereferensikan grup instance harus menggunakan mode load balancing yang kompatibel. Untuk mengetahui informasi selengkapnya, lihat Batasan dan panduan untuk grup instance dalam dokumen ini.
• NEG Zona
• NEG tanpa server
• NEG Private Service Connect
• NEG Internet
• NEG dengan konektivitas hybrid
• NEG pemetaan port
• Binding layanan Service Directory (Pratinjau)
• Backend layanan yang dipublikasikan (Pratinjau)

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) lapisan pertama yang menghosting alamat IP eksternal load balancer Anda. GFE lapisan pertama berkomunikasi dengan GFE lapisan kedua, yang berada di region yang sama dengan VM atau endpoint backend. Setiap GFE lapisan kedua berkomunikasi dengan VM atau endpoint backend sesuai dengan aturan berikut:

  • Antarmuka jaringan yang di-load balance: Antarmuka jaringan yang digunakan GFE lapisan kedua untuk mengirim traffic permintaan bergantung pada jenis grup backend:

    • Untuk backend grup instance, load balancer selalu mengirimkan paket ke antarmuka nic0 setiap VM backend. Aturan ini berlaku meskipun VM memiliki beberapa antarmuka jaringan di jaringan VPC yang sama atau berbeda.

    • Untuk backend NEG zonal GCE_VM_IP_PORT, load balancer mengirimkan paket ke antarmuka jaringan yang terkait dengan alamat IP endpoint. Untuk VM backend dengan beberapa antarmuka jaringan, antarmuka jaringan dapat berada di jaringan VPC mana pun, dengan tunduk pada pengecualian berikut: Jika VM backend memiliki antarmuka nic0 dan satu atau beberapa antarmuka non-nic0 di jaringan VPC yang sama, maka dari kumpulan antarmuka jaringan di jaringan VPC yang sama, load balancer hanya mengirimkan paket ke antarmuka jaringan nic0.

  • Alamat IP tujuan di antarmuka yang di-load balance: GFE lapisan kedua mengirim traffic permintaan yang paketnya memiliki alamat IP tujuan berikut:

    • Untuk backend grup instance, tujuan paket adalah alamat IPv4 internal utama antarmuka jaringan nic0 atau alamat IPv6 /128 pertama dari rentang IPv6 /96 yang ditetapkan ke antarmuka nic0, bergantung pada kebijakan pemilihan alamat IP layanan backend dan jenis stack antarmuka jaringan.

    • Untuk backend NEG zona GCE_VM_IP_PORT, tujuan paket cocok dengan alamat IP endpoint yang ditentukan dalam NEG, bergantung pada kebijakan pemilihan alamat IP layanan backend dan jenis stack antarmuka jaringan. Untuk alamat IP endpoint yang valid, lihat NEG dengan GCE_VM_IP_PORT endpoint. Jika VM backend memiliki antarmuka nic0 dan satu atau beberapa antarmuka non-nic0 di jaringan VPC yang sama, maka dari kumpulan antarmuka jaringan di jaringan VPC yang sama, Anda hanya dapat menentukan alamat IP endpoint yang terkait dengan antarmuka jaringan nic0.

  Komunikasi antara GFE lapisan kedua dan backend difasilitasi melalui rute khusus.

• Untuk Load Balancer Aplikasi eksternal regional dan Load Balancer Jaringan proxy eksternal regional: Klien berkomunikasi dengan proxy Envoy terkelola yang menghosting alamat IP eksternal load balancer Anda. Proxy Envoy berada di subnet khusus proxy. Setiap proxy Envoy berkomunikasi dengan VM atau endpoint backend sesuai dengan aturan berikut:

  • Antarmuka jaringan yang di-load balance: Antarmuka jaringan tempat proxy Envoy mengirimkan traffic permintaan bergantung pada jenis grup backend:

    • Untuk backend grup instance, load balancer selalu mengirimkan paket ke antarmuka nic0 setiap VM backend. Aturan ini berlaku meskipun VM memiliki beberapa antarmuka jaringan di jaringan VPC yang sama atau berbeda.

    • Untuk backend NEG zona GCE_VM_IP_PORT, load balancer mengirimkan paket ke antarmuka jaringan yang terkait dengan alamat IP endpoint. Untuk VM backend dengan beberapa antarmuka jaringan, antarmuka jaringan dapat berada di jaringan VPC mana pun, dengan tunduk pada pengecualian berikut: Jika VM backend memiliki antarmuka nic0 dan satu atau beberapa antarmuka non-nic0 di jaringan VPC yang sama, maka dari kumpulan antarmuka jaringan di jaringan VPC yang sama, load balancer hanya mengirimkan paket ke antarmuka jaringan nic0.

  • Alamat IP tujuan pada antarmuka yang di-load balance: Proxy Envoy mengirimkan traffic permintaan yang paketnya memiliki alamat IP tujuan berikut:

    • Untuk backend grup instance, tujuan paket adalah alamat IPv4 internal utama antarmuka jaringan nic0 atau alamat IPv6 /128 pertama dari rentang IPv6 /96 yang ditetapkan ke antarmuka nic0, bergantung pada kebijakan pemilihan alamat IP layanan backend dan jenis stack antarmuka jaringan.

    • Untuk backend NEG zona GCE_VM_IP_PORT, tujuan paket cocok dengan alamat IP endpoint yang ditentukan dalam NEG, bergantung pada kebijakan pemilihan alamat IP layanan backend dan jenis stack antarmuka jaringan. Untuk alamat IP endpoint yang valid, lihat NEG dengan GCE_VM_IP_PORT endpoint. Jika VM backend memiliki antarmuka nic0 dan satu atau beberapa antarmuka non-nic0 di jaringan VPC yang sama, maka dari kumpulan antarmuka jaringan di jaringan VPC yang sama, Anda hanya dapat menentukan alamat IP endpoint yang terkait dengan antarmuka jaringan nic0.

• Untuk Load Balancer Jaringan passthrough eksternal global dan Load Balancer Jaringan passthrough eksternal regional: Klien berkomunikasi langsung dengan backend menggunakan infrastruktur Maglev Google. Paket dirutekan dan dikirim ke backend dengan alamat IP sumber dan tujuan asli dipertahankan. Load balancer mengirimkan paket ke salah satu antarmuka jaringan berikut:

  • Untuk Load Balancer Jaringan passthrough eksternal global dengan backend grup instance, load balancer selalu mengirimkan paket ke antarmuka nic0. Untuk mengetahui informasi selengkapnya, lihat Backend grup instance dan antarmuka jaringan.

  • Untuk Load Balancer Jaringan passthrough eksternal global dengan backend NEG GCE_VM_IP, load balancer mengirimkan paket ke antarmuka jaringan yang berada di subnetwork yang terkait dengan NEG. Untuk mengetahui informasi selengkapnya, lihat Backend NEG zonal dan antarmuka jaringan.

  • Untuk Load Balancer Jaringan passthrough eksternal regional berbasis layanan backend dengan backend grup instance, load balancer selalu mengirimkan paket ke antarmuka nic0. Untuk mengetahui informasi selengkapnya, lihat Backend grup instance dan antarmuka jaringan.

  • Untuk Load Balancer Jaringan passthrough eksternal regional berbasis layanan backend dengan backend NEG GCE_VM_IP, load balancer mengirimkan paket ke antarmuka jaringan yang berada di subnetwork yang terkait dengan NEG. Untuk mengetahui informasi selengkapnya, lihat Backend NEG zonal dan antarmuka jaringan.

  • Untuk Load Balancer Jaringan passthrough eksternal regional berbasis kumpulan target, load balancer selalu mengirimkan paket ke antarmuka nic0.

  • Jika VM backend memiliki antarmuka nic0 dan satu atau beberapa antarmuka non-nic0 dalam jaringan VPC yang sama, maka dari kumpulan antarmuka jaringan dalam jaringan VPC yang sama, load balancer hanya mengirimkan paket ke antarmuka jaringan nic0.

• Untuk Load Balancer Jaringan passthrough internal: Klien berkomunikasi langsung dengan backend menggunakan stack virtualisasi jaringan Andromeda. Paket dirutekan dan dikirim ke backend dengan alamat IP sumber dan tujuan aslinya dipertahankan. Untuk backend grup instance dan backend NEG GCE_VM_IP, load balancer mengirimkan paket ke antarmuka jaringan di jaringan VPC layanan backend:

  • Jaringan VPC layanan backend dapat ditentukan secara eksplisit, atau dapat diwarisi dari grup instance backend atau NEG pertama yang ditambahkan ke layanan backend atau aturan penerusan pertama yang mereferensikan layanan backend. Untuk mengetahui informasi selengkapnya, lihat Spesifikasi jaringan layanan backend.

  • Jika VM backend memiliki antarmuka nic0 dan satu atau beberapa antarmuka non-nic0 dalam jaringan VPC yang sama, maka dari kumpulan antarmuka jaringan dalam jaringan VPC yang sama, load balancer hanya mengirimkan paket ke antarmuka jaringan nic0.

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, di endpoint itu sendiri. NEG serverless mereferensikan layanan Google dan NEG PSC mereferensikan lampiran layanan menggunakan abstraksi yang tidak melibatkan penentuan port tujuan.

Load Balancer Jaringan passthrough internal dan Load Balancer Jaringan passthrough eksternal regional 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:

• Grup instance tidak terkelola: Bekerja dengan port bernama
• Grup instance terkelola: Menetapkan port bernama ke grup instance terkelola

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 dua grup instance tidak terkelola, atau VM dapat menjadi anggota 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 internal dan Load Balancer Jaringan passthrough eksternal regional. Hal ini karena backend grup instance Load Balancer Jaringan passthrough regional (Load Balancer Jaringan passthrough internal dan Load Balancer Jaringan passthrough eksternal regional) menggunakan CONNECTION sebagai mode penyeimbangannya.

• Tidak ada satu perintah yang dapat mengubah mode penyeimbangan grup instance yang sama pada beberapa layanan backend. Jika grup instance adalah backend untuk dua atau beberapa layanan backend, dan mode penyeimbangannya perlu diperbarui ke mode baru yang tidak kompatibel dengan mode saat ini, Anda dapat menggunakan teknik berikut:

  • Hapus grup instance sebagai backend dari semua layanan backend kecuali untuk satu layanan backend.
  • Ubah mode load balancing 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 yang didukung oleh semua load balancer passthrough, kecuali Load Balancer Jaringan passthrough eksternal regional berbasis kumpulan target.

• endpoint GCE_VM_IP_PORT yang didukung oleh semua load balancer berbasis proxy (Load Balancer Aplikasi dan Load Balancer Jaringan Proxy) dan Cloud Service Mesh.

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.

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 Gateway API.

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.
• Gateway API 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 Service Directory

Pengikatan layanan Service Directory adalah resource backend yang membuat koneksi antara layanan backend di Cloud Service Mesh dan layanan yang terdaftar di Service Directory. Layanan backend dapat merujuk ke beberapa binding layanan Service Directory. Namun, layanan backend dengan pengikatan layanan Direktori Layanan tidak dapat mereferensikan jenis resource backend lainnya. Untuk mengetahui informasi selengkapnya, lihat Integrasi Cloud Service Mesh dengan Service Directory.

Backend layanan yang dipublikasikan

Jika jaringan VPC produsen dan konsumen termasuk dalam organisasi yang sama, Anda dapat mengakses layanan yang dipublikasikan menggunakan backend layanan yang dipublikasikan. Backend layanan yang dipublikasikan memungkinkan Anda mengonfigurasi load balancer yang didukung atau Cloud Service Mesh untuk merutekan traffic ke layanan yang dipublikasikan melalui endpoint Private Service Connect. Untuk merutekan traffic ke layanan yang dipublikasikan, Anda mengaitkan layanan backend regional dengan lampiran layanan. Konfigurasi ini dikenal sebagai backend layanan yang dipublikasikan.

Backend ini menyediakan konektivitas terpadu dengan mengizinkan load balancer yang didukung dan Cloud Service Mesh untuk berbagi endpoint Private Service Connect. Anda membuat koneksi ini dengan memberikan referensi ke lampiran layanan produsen. Backend layanan yang dipublikasikan juga memungkinkan pengelolaan traffic dan kemampuan observasi tingkat lanjut, seperti menerapkan kebijakan keamanan terpusat dan mengumpulkan metrik terpusat.

Untuk mengetahui informasi selengkapnya tentang cara mengonfigurasi backend layanan yang dipublikasikan untuk load balancer, lihat Mengakses layanan yang dipublikasikan melalui backend dan endpoint layanan yang dipublikasikan.

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 jenis grup instance yang berbeda 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.

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:

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, Load Balancer Jaringan proxy, dan Load Balancer Jaringan passthrough eksternal global, mode load balancing, 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 (untuk load balancing HTTP), atau koneksi baru (untuk load balancing proxy TCP dan load balancing teruskan global) ke zona yang berisi backend yang didukung:

• Mode load balancing menentukan cara load balancer mengukur kapasitas. Dengan kata lain, mode balancing adalah unit yang digunakan untuk menentukan kapasitas.

  Google Cloud memiliki mode penyeimbangan berikut:

  • CONNECTION: menentukan kapasitas berdasarkan jumlah koneksi TCP baru.
  • RATE: menentukan kapasitas berdasarkan laju permintaan HTTP baru per detik (untuk Load Balancer Aplikasi) atau paket per detik (untuk Load Balancer Jaringan passthrough eksternal global).
  • IN-FLIGHT: menentukan kapasitas berdasarkan jumlah permintaan HTTP yang sedang berlangsung, bukan rasio 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 global dan lintas region juga menggunakan kapasitas untuk mengarahkan permintaan atau koneksi baru 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.

Backend yang didukung

Untuk load balancer berbasis proxy (Load Balancer Aplikasi dan Load Balancer Jaringan proxy) dan Cloud Service Mesh, jenis backend berikut mendukung parameter mode load balancing, kapasitas target, dan penskala kapasitas:

• Backend grup instance
• NEG zona dengan endpoint GCE_VM_IP_PORT
• NEG dengan konektivitas hybrid zona

Untuk Load Balancer Jaringan passthrough eksternal global, jenis backend berikut mendukung parameter mode penyeimbangan, kapasitas target, dan penskala kapasitas:

• Backend grup instance
• NEG zona dengan endpoint GCE_VM_IP

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 load balancing yang tersedia untuk backend Load Balancer Aplikasi dan Cloud Service Mesh bergantung pada jenis backend yang didukung dan setelan durasi traffic.

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:

• Jalankan perintah gcloud compute backend-services add-backend dengan flag --traffic-duration.
• Buat layanan backend atau perbarui layanan backend dengan atribut trafficDuration.

Mode penyeimbangan untuk durasi traffic singkat

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

Mode penyeimbangan untuk durasi traffic yang panjang

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