Ringkasan Load Balancer Aplikasi Internal

Dokumen ini memperkenalkan konsep yang perlu Anda pahami untuk mengonfigurasi Load Balancer Aplikasi internal.

Load Balancer Aplikasi internal Cloud de Confiance by S3NS adalah load balancer Lapisan 7 berbasis proxy yang memungkinkan Anda menjalankan dan menskalakan layanan di balik satu alamat IP internal. Load Balancer Aplikasi internal mendistribusikan traffic HTTP dan HTTPS ke backend yang dihosting di berbagai Cloud de Confiance platform seperti Compute Engine, Google Kubernetes Engine (GKE), dan Cloud Run. Untuk mengetahui detailnya, lihat Kasus penggunaan.

Mode operasi

Load balancer ini tersedia untuk Anda dalam mode regional, dan selanjutnya disebut sebagai Load Balancer Aplikasi internal regional. Load balancer diimplementasikan sebagai layanan terkelola berdasarkan proxy Envoy open source. Fitur ini mencakup kemampuan pengelolaan traffic lanjutan seperti pencerminan traffic, pemisahan traffic berbasis bobot, transformasi header berbasis permintaan atau respons, dan lainnya. Mode regional mengharuskan backend berada di satu region Cloud de Confiance . Klien dapat dibatasi ke region tersebut atau dapat berada di region mana pun, berdasarkan apakah akses global dinonaktifkan atau diaktifkan pada aturan penerusan.

Arsitektur dan resource

Diagram berikut menunjukkan resource Cloud de Confiance yang diperlukan untuk Load Balancer Aplikasi internal:

Load Balancer Aplikasi internal regional

Diagram ini menunjukkan komponen deployment Load Balancer Aplikasi internal regional di Paket Premium.

Komponen Load Balancer Aplikasi internal regional.
Komponen Load Balancer Aplikasi internal regional (klik untuk memperbesar).

Resource berikut diperlukan untuk deployment Load Balancer Aplikasi internal:

Subnet khusus proxy

Subnet khusus proxy menyediakan sekumpulan alamat IP yang digunakan Google untuk menjalankan proxy Envoy atas nama Anda. Anda harus membuat satu subnet khusus proxy di setiap region jaringan VPC tempat Anda menggunakan Load Balancer Aplikasi internal regional. Flag --purpose untuk subnet khusus proxy ini ditetapkan ke REGIONAL_MANAGED_PROXY. Semua load balancer regional berbasis Envoy di suatu region dan jaringan VPC berbagi kumpulan proxy Envoy dari subnet khusus proxy yang sama.

Selanjutnya:

  • Subnet khusus proxy hanya digunakan untuk proxy Envoy, bukan backend Anda.
  • VM backend atau endpoint dari semua Load Balancer Aplikasi internal di suatu region dan jaringan VPC menerima koneksi dari subnet khusus proxy.
  • Untuk Load Balancer Aplikasi internal regional dan Load Balancer Aplikasi internal lintas region, subnet khusus proxy dapat dikonfigurasi dengan jenis stack IPV4_IPV6 (stack ganda).
  • Alamat IP virtual Load Balancer Aplikasi internal tidak berada di subnet khusus proxy. Alamat IP load balancer ditentukan oleh aturan penerusan terkelola internalnya, yang dijelaskan di bawah.

Aturan penerusan dan alamat IP

Aturan penerusan merutekan traffic berdasarkan alamat IP, port, dan protokol ke konfigurasi load balancing yang terdiri dari proxy target dan layanan backend.

Spesifikasi alamat IP. Setiap aturan penerusan merujuk ke satu alamat IP regional yang dapat Anda gunakan dalam data DNS untuk aplikasi Anda. Anda dapat memesan alamat IP statis yang dapat digunakan atau mengizinkan Cloud Load Balancing menetapkannya untuk Anda. Sebaiknya Anda mencadangkan alamat IP statis; jika tidak, Anda harus memperbarui data DNS dengan alamat IP sementara yang baru ditetapkan setiap kali Anda menghapus aturan penerusan dan membuat aturan baru.

Klien menggunakan alamat IP dan port untuk terhubung ke proxy Envoy load balancer—alamat IP aturan penerusan adalah alamat IP load balancer (terkadang disebut alamat IP virtual atau VIP). Klien yang terhubung ke load balancer harus menggunakan HTTP versi 1.1 atau yang lebih baru. Untuk mengetahui daftar lengkap protokol yang didukung, lihat Perbandingan fitur load balancer.

Alamat IP internal yang terkait dengan aturan penerusan dapat berasal dari subnet di jaringan dan region yang sama dengan backend Anda.

Spesifikasi port. Setiap aturan penerusan untuk Load Balancer Aplikasi dapat mereferensikan satu port dari 1—65535. Untuk mendukung beberapa port, Anda harus mengonfigurasi beberapa aturan penerusan. Anda dapat mengonfigurasi beberapa aturan penerusan untuk menggunakan alamat IP internal (VIP) yang sama dan untuk mereferensikan proxy HTTP atau HTTPS target yang sama, asalkan keseluruhan kombinasi alamat IP, port, dan protokol bersifat unik untuk setiap aturan penerusan. Dengan cara ini, Anda dapat menggunakan satu load balancer dengan peta URL bersama sebagai proxy untuk beberapa aplikasi.

Jenis aturan penerusan, alamat IP, dan skema load balancing yang digunakan oleh Load Balancer Aplikasi internal bergantung pada mode load balancer.

Load Balancer Aplikasi internal regional
Aturan penerusan

Metode forwardingRules.insert
Alamat IP regional

Metode addresses.insert
Skema load balancing

INTERNAL_MANAGED
Alamat IP (opsional)

SHARED_LOADBALANCER_VIP
Perutean dari klien ke frontend load balancer

Anda dapat mengaktifkan akses global untuk mengizinkan klien dari region mana pun di VPC mengakses load balancer Anda. Backend juga harus berada di region yang sama dengan load balancer.

Aturan penerusan dan jaringan VPC

Bagian ini menjelaskan cara aturan penerusan yang digunakan oleh Load Balancer Aplikasi internal dikaitkan dengan jaringan VPC.

Mode load balancer Pengaitan jaringan VPC
Load Balancer Aplikasi internal regional

Bergantung pada apakah Anda menggunakan rentang alamat IPv4 atau alamat IPv6, selalu ada jaringan VPC eksplisit atau implisit yang terkait dengan aturan penerusan.

Rentang alamat IPv4 internal regional dan alamat IPv6 selalu ada di dalam jaringan VPC. Saat membuat aturan penerusan, Anda harus menentukan subnet tempat alamat IP internal diambil. Subnet ini harus berada di region dan jaringan VPC yang sama dengan tempat subnet khusus proxy telah dibuat. Dengan demikian, ada pengaitan jaringan tersirat.

Persyaratan jaringan dan subnet. Untuk traffic IPv6, jaringan dan subnet Anda harus memenuhi persyaratan konfigurasi berikut:

  • Jaringan VPC: Anda harus menggunakan jaringan VPC mode kustom yang dikonfigurasi dengan flag --enable-ula-internal-ipv6.
  • Subnet aturan penerusan: subnet ini harus berupa subnet stack ganda (IPv4_IPv6) atau IPV6_ONLY dengan ipv6-access-type yang ditetapkan ke INTERNAL.

Opsi alokasi alamat IPv6. Aturan penerusan harus merujuk ke rentang alamat IPv6 /96 dari rentang alamat IPv6 internal /64 subnet. Saat Anda mengonfigurasi aturan penerusan dengan flag --ip-version=IPV6, Cloud de Confiance akan otomatis mengalokasikan awalan IPv6 /96 acak dari dalam rentang subnet.

Batasan. Untuk menentukan alamat IPv6 sementara kustom, Anda harus menggunakan Google Cloud CLI atau API. Konsol Cloud de Confiance tidak mendukung penentuan alamat IPv6 sementara kustom untuk aturan penerusan.

Proxy target

Proxy HTTP atau HTTPS target menghentikan koneksi HTTP(S) dari klien. Proxy HTTP(S) akan memeriksa peta URL untuk menentukan cara merutekan traffic ke backend. Proxy HTTPS target menggunakan sertifikat SSL untuk mengautentikasi dirinya ke klien.

Load balancer mempertahankan header Host dari permintaan klien asli.

Bergantung pada jenis traffic yang perlu ditangani aplikasi, Anda dapat mengonfigurasi load balancer dengan proxy HTTP target atau proxy HTTPS target.

Tabel berikut menunjukkan API proxy target yang diperlukan oleh Load Balancer Aplikasi internal:

Mode load balancer Proxy target
Load Balancer Aplikasi internal regional

Penanganan header X-Forwarded-For

Load balancer menambahkan dua alamat IP ke header X-Forwarded-For:

  • Alamat IP klien yang terhubung ke load balancer
  • Alamat IP aturan penerusan load balancer

Jika tidak ada header X-Forwarded-For pada permintaan masuk, kedua alamat IP ini adalah seluruh nilai header. Jika permintaan memiliki header X-Forwarded-For, informasi lain, seperti alamat IP yang dicatat oleh proxy dalam perjalanan ke load balancer, akan dipertahankan sebelum dua alamat IP.

Jika Anda menjalankan proxy sebagai server backend, proxy ini biasanya menambahkan informasi lainnya ke header X-Forwarded-For, dan software Anda mungkin perlu mempertimbangkannya. Permintaan yang di-proxy dari load balancer berasal dari alamat IP di subnet khusus proxy, dan proxy Anda di instance backend mungkin mencatat alamat ini serta alamat IP instance backend itu sendiri.

Load Balancer Aplikasi internal menggunakan langkah-langkah keamanan khusus untuk header X-Forwarded-For:

  • Sanitasi Header (Penghapusan). Jika ada proxy perantara antara klien dan load balancer, load balancer akan memperlakukan header X-Forwarded-For yang masuk sebagai tidak tepercaya dan menghapus header untuk mencegah spoofing IP. Tidak ada opsi konfigurasi untuk mengubah perilaku ini.
  • Perilaku Penambahan. Header kustom dapat digunakan untuk membuat header X-Forwarded-For baru dan menyisipkan IP klien dan IP server. Namun, dalam hal ini, IP klien dari perspektif load balancer adalah IP proxy perantara, bukan IP klien asli.

Mempertahankan IP Klien dengan proxy perantara

Jika traffic Anda melewati proxy perantara sebelum mencapai Load Balancer Aplikasi internal, IP klien asli akan dihapus jika hanya ada di header X-Forwarded-For.

Untuk mempertahankan IP klien dengan andal, ikuti rekomendasi berikut:

  • Gunakan header kustom. Konfigurasikan proxy perantara Anda untuk memasukkan IP klien terverifikasi ke dalam header kustom. Misalnya, X-Original-Client-IP atau X-Client-IP.
  • Konfigurasi passthrough. Load Balancer Aplikasi internal meneruskan header kustom ke backend tanpa diubah.
  • Update backend. Perbarui aplikasi backend Anda untuk membaca IP klien dari header kustom baru, bukan X-Forwarded-For.

Sertifikat SSL

Load Balancer Aplikasi Internal yang menggunakan proxy HTTPS target memerlukan kunci pribadi dan sertifikat SSL sebagai bagian dari konfigurasi load balancer.

Load Balancer Aplikasi internal regional mendukung sertifikat SSL Compute Engine yang dikelola sendiri.

Peta URL

Proxy HTTP(S) target menggunakan peta URL untuk membuat penentuan perutean berdasarkan atribut HTTP (seperti jalur permintaan, cookie, atau header). Berdasarkan keputusan perutean, proxy meneruskan permintaan klien ke layanan backend tertentu. Peta URL dapat menentukan tindakan tambahan yang harus dilakukan, seperti menulis ulang header, mengirim pengalihan ke klien, dan mengonfigurasi kebijakan waktu tunggu (antara lain).

Tabel berikut menentukan jenis peta URL yang diperlukan oleh Load Balancer Aplikasi internal dalam setiap mode:

Mode load balancer Jenis peta URL
Load Balancer Aplikasi internal regional regionUrlMaps

Layanan backend

Layanan backend memberikan informasi konfigurasi ke load balancer agar dapat mengarahkan permintaan ke backend-nya—misalnya, grup instance Compute Engine atau grup endpoint jaringan (NEG). Untuk informasi selengkapnya tentang layanan backend, lihat Ringkasan layanan backend.

Cakupan layanan backend

Tabel berikut menunjukkan resource dan cakupan layanan backend yang digunakan oleh Load Balancer Aplikasi internal:

Mode load balancer Resource layanan backend
Load Balancer Aplikasi internal regional regionBackendServices

Protokol ke backend

Layanan backend untuk Load Balancer Aplikasi harus menggunakan salah satu protokol berikut untuk mengirim permintaan ke backend:

  • HTTP, yang menggunakan HTTP/1.1 dan tanpa TLS
  • HTTPS, yang menggunakan HTTP/1.1 dan TLS
  • HTTP/2, yang menggunakan HTTP/2 dan TLS (HTTP/2 tanpa enkripsi tidak didukung.)
  • H2C, yang menggunakan HTTP/2 melalui TCP. TLS tidak diperlukan. H2C tidak didukung untuk Load Balancer Aplikasi klasik.

Load balancer hanya menggunakan protokol layanan backend yang Anda tentukan untuk berkomunikasi dengan backend-nya. Load balancer tidak akan beralih ke protokol lain jika tidak dapat berkomunikasi dengan backend menggunakan protokol layanan backend yang ditentukan.

Protokol layanan backend tidak harus cocok dengan protokol yang digunakan oleh klien untuk berkomunikasi dengan load balancer. Misalnya, klien dapat mengirim permintaan ke load balancer menggunakan HTTP/2, tetapi load balancer dapat berkomunikasi dengan backend menggunakan HTTP/1.1 (HTTP atau HTTPS).

Backend

Load Balancer Aplikasi eksternal regional mendukung jenis backend berikut:

  • Grup instance
  • NEG Zona
  • NEG Internet
  • NEG Hybrid

Backend dan jaringan VPC

Batasan lokasi backend bergantung pada jenis backend.

  • Untuk grup instance, NEG zona, dan NEG konektivitas hybrid, semua backend harus berada di project dan region yang sama dengan layanan backend. Namun, load balancer dapat mereferensikan backend yang menggunakan jaringan VPC yang berbeda dalam project yang sama dengan layanan backend. Konektivitas antara jaringan VPC load balancer dan jaringan VPC backend dapat dikonfigurasi menggunakan Peering Jaringan VPC, tunnel Cloud VPN, atau lampiran VLAN Cloud Interconnect.

    Definisi jaringan backend

    • Untuk NEG zona dan NEG hybrid, Anda secara eksplisit menentukan jaringan VPC saat membuat NEG.
    • Untuk grup instance terkelola, jaringan VPC ditentukan dalam template instance.
    • Untuk grup instance tidak terkelola, jaringan VPC grup instance ditetapkan agar cocok dengan jaringan VPC antarmuka nic0 untuk VM pertama yang ditambahkan ke grup instance.

    Persyaratan jaringan backend

    Jaringan backend Anda harus memenuhi salah satu persyaratan jaringan berikut:

    • Jaringan VPC backend harus sama persis dengan jaringan VPC aturan penerusan.

    • Jaringan VPC backend harus terhubung ke jaringan VPC aturan penerusan menggunakan Peering Jaringan VPC. Anda harus mengonfigurasi pertukaran rute subnet untuk mengizinkan komunikasi antara subnet khusus proxy di jaringan VPC aturan penerusan dan subnet yang digunakan oleh instance atau endpoint backend.

    Persyaratan subnet IPv6 backend

    Versi IP yang digunakan untuk koneksi frontend tidak bergantung pada koneksi backend. Karena subnet khusus proxy adalah dual-stack (IPV4_IPV6), subnet khusus proxy dapat berkomunikasi dengan backend menggunakan IPv4 atau IPv6.

    Jika instance backend Anda menangani traffic IPv6, subnet backend dapat dikonfigurasi dengan jenis stack IPV4_ONLY atau IPV4_IPV6 (stack ganda). Jika jenis stack subnet backend menyertakan IPv6, Anda harus secara eksplisit menetapkan ipv6-access-type subnet ke INTERNAL.

  • Untuk semua jenis backend lainnya, semua backend harus berada di region dan jaringan VPC yang sama.

Backend dan antarmuka jaringan

Jika Anda menggunakan backend grup instance, paket akan selalu dikirimkan ke nic0. Jika Anda ingin mengirim paket ke antarmuka non-nic0 (vNIC atau Dynamic Network Interface), gunakan backend NEG.

Jika Anda menggunakan backend NEG zonal, paket akan dikirim ke antarmuka jaringan apa pun yang diwakili oleh endpoint di NEG. Endpoint NEG harus berada di jaringan VPC yang sama dengan jaringan VPC yang ditentukan secara eksplisit oleh NEG.

Subsetting backend

Subsetting backend adalah fitur opsional yang didukung oleh Load Balancer Aplikasi internal regional yang meningkatkan performa dan skalabilitas dengan menetapkan subset backend ke setiap instance proxy.

Secara default, subset backend dinonaktifkan. Untuk mengetahui informasi tentang cara mengaktifkan fitur ini, lihat Subset backend untuk Load Balancer Aplikasi internal regional.

Health check

Setiap layanan backend menentukan health check yang secara berkala memantau kesiapan backend untuk menerima koneksi dari load balancer. Hal ini mengurangi risiko permintaan dikirim ke backend yang tidak dapat melayani permintaan. Health check tidak memeriksa apakah aplikasi itu sendiri berfungsi.

Agar pemeriksaan health check berhasil, Anda harus membuat aturan firewall yang mengizinkan Ingress untuk mengizinkan pemeriksaan health check menjangkau instance backend Anda. Biasanya, pemeriksaan health check berasal dari mekanisme pemeriksaan kondisi terpusat Google. Namun, untuk NEG hybrid, health check berasal dari subnet khusus proxy. Untuk mengetahui detailnya, lihat Pemeriksaan kondisi Envoy terdistribusi.

Protokol health check

Meskipun tidak wajib dan tidak selalu memungkinkan, sebaiknya gunakan health check yang protokolnya cocok dengan protokol layanan backend. Misalnya, health check HTTP/2 paling akurat menguji konektivitas HTTP/2 ke backend. Sebaliknya, Load Balancer Aplikasi internal yang menggunakan backend NEG hibrida tidak mendukung health check gRPC. Untuk mengetahui daftar protokol health check yang didukung, lihat fitur load balancing di bagian Health check.

Tabel berikut menentukan cakupan health check yang didukung oleh Load Balancer Aplikasi internal:

Mode load balancer Jenis health check
Load Balancer Aplikasi internal regional regionHealthChecks

Untuk mengetahui informasi selengkapnya tentang health check, lihat artikel berikut:

Aturan firewall

Load Balancer Aplikasi internal memerlukan aturan firewall berikut:

  • Aturan izin masuk yang mengizinkan traffic dari rentang health check pusat Google. Untuk mengetahui informasi selengkapnya tentang rentang alamat IP pemeriksaan health check tertentu dan alasan mengapa perlu mengizinkan traffic dari rentang tersebut, lihat Rentang IP pemeriksaan dan aturan firewall.
  • Aturan izinkan masuk yang mengizinkan traffic dari subnet khusus proxy.

Ada pengecualian tertentu untuk persyaratan aturan firewall untuk rentang ini:

  • Mengizinkan traffic dari rentang pemeriksaan health check Google tidak diperlukan untuk NEG hybrid. Namun, jika Anda menggunakan kombinasi NEG hybrid dan zona dalam satu layanan backend, Anda harus mengizinkan traffic dari rentang pemeriksaan kondisi Google untuk NEG zona.
  • Untuk NEG internet regional, health check bersifat opsional. Traffic dari load balancer yang menggunakan NEG internet regional berasal dari subnet khusus proxy, lalu diterjemahkan NAT (menggunakan Cloud NAT) ke alamat IP NAT yang dialokasikan secara manual atau alokasi otomatis. Traffic ini mencakup pemeriksaan health check dan permintaan pengguna dari load balancer ke backend. Untuk mengetahui detailnya, lihat NEG regional: Menggunakan gateway Cloud NAT.

Gunakan aturan kebijakan firewall Cloud Next Generation Firewall (Cloud NGFW) untuk mengontrol akses klien ke aturan penerusan load balancer berbasis proxy Envoy, seperti Load Balancer Aplikasi internal regional dan Load Balancer Aplikasi internal lintas region. Cloud NGFW Essentials dan Cloud NGFW Standard mendukung fitur ini. Untuk Load Balancer Aplikasi internal lintas region, Cloud NGFW juga menyediakan pencegahan ancaman Lapisan 7 tingkat lanjut (Pratinjau). Untuk mengetahui informasi selengkapnya, lihat Menggunakan kebijakan firewall jaringan global untuk melindungi load balancer berbasis Envoy dan Menggunakan kebijakan firewall jaringan regional untuk melindungi Load Balancer Aplikasi internal dan Load Balancer Jaringan proxy internal.

Akses klien

Klien dapat berada di jaringan yang sama atau di jaringan VPC yang terhubung menggunakan Peering Jaringan VPC.

Untuk Load Balancer Aplikasi internal regional, klien harus berada di region yang sama dengan load balancer secara default. Anda dapat mengaktifkan akses global untuk mengizinkan klien dari region mana pun di VPC mengakses load balancer Anda.

Tabel berikut merangkum akses klien untuk Load Balancer Aplikasi internal regional:

Akses global dinonaktifkan Akses global diaktifkan
Klien harus berada di region yang sama dengan load balancer. Backend juga harus berada di jaringan VPC yang sama dengan load balancer atau di jaringan VPC yang terhubung ke jaringan VPC load balancer menggunakan Peering Jaringan VPC. Klien dapat berada di region mana pun. Backend tersebut tetap harus berada di jaringan VPC yang sama dengan load balancer atau di jaringan VPC yang terhubung ke jaringan VPC load balancer menggunakan Peering Jaringan VPC.
Klien lokal dapat mengakses load balancer melalui tunnel Cloud VPN atau lampiran VLAN. Tunnel atau lampiran ini harus berada di region yang sama dengan load balancer. Klien lokal dapat mengakses load balancer melalui tunnel Cloud VPN atau lampiran VLAN. Tunnel atau lampiran ini dapat berada di region mana pun.

Dukungan GKE

GKE menggunakan Load Balancer Aplikasi internal dengan cara berikut:

  • Gateway Internal yang dibuat menggunakan pengontrol Gateway GKE dapat menggunakan mode apa pun dari Load Balancer Aplikasi Internal. Anda mengontrol mode load balancer dengan memilih GatewayClass. Pengontrol GKE Gateway selalu menggunakan backend NEG zonal GCE_VM_IP_PORT.

  • Ingress internal yang dibuat menggunakan pengontrol Ingress GKE selalu berupa Load Balancer Aplikasi internal regional. Pengontrol GKE Ingress selalu menggunakan backend NEG zona GCE_VM_IP_PORT.

Arsitektur VPC Bersama

Load Balancer Aplikasi internal mendukung jaringan yang menggunakan VPC Bersama. VPC Bersama memungkinkan organisasi menghubungkan resource dari beberapa project ke jaringan VPC umum sehingga resource tersebut dapat berkomunikasi satu sama lain secara aman dan efisien menggunakan IP internal dari jaringan tersebut. Jika Anda belum memahami VPC Bersama, baca dokumentasi ringkasan VPC Bersama.

Ada banyak cara untuk mengonfigurasi Load Balancer Aplikasi internal dalam jaringan VPC Bersama. Terlepas dari jenis deployment, semua komponen load balancer harus berada di organisasi yang sama.

Subnet dan alamat IP Komponen frontend Komponen backend

Buat jaringan dan subnet yang diperlukan (termasuk subnet khusus proxy), di project host VPC Bersama.

Alamat IP internal load balancer dapat ditentukan dalam project host atau project layanan, tetapi harus menggunakan subnet di jaringan VPC Bersama yang diinginkan dalam project host. Alamat itu sendiri berasal dari rentang IP utama subnet yang direferensikan.

 Alamat IP internal regional, aturan penerusan, proxy HTTP(S) target, dan peta URL terkait harus ditentukan dalam project yang sama. Project ini dapat berupa project host atau project layanan. Anda dapat melakukan salah satu hal berikut:
  • Buat layanan backend dan backend (grup instance, NEG serverless, atau jenis backend lain yang didukung) di project layanan yang sama dengan komponen frontend.
  • Buat layanan backend dan backend (grup instance, NEG serverless, atau jenis backend lain yang didukung) di sebanyak mungkin project layanan yang diperlukan. Satu peta URL dapat mereferensikan layanan backend di berbagai project. Jenis deployment ini dikenal sebagai referensi layanan lintas project.

Setiap layanan backend harus ditentukan dalam project yang sama dengan backend yang dirujuknya. Health check yang terkait dengan layanan backend juga harus ditentukan dalam project yang sama dengan layanan backend.

Meskipun Anda dapat membuat semua komponen load balancing dan backend di project host VPC Bersama, jenis deployment ini tidak memisahkan tanggung jawab administrasi jaringan dan pengembangan layanan.

Semua komponen dan backend load balancer dalam project layanan

Diagram arsitektur berikut menunjukkan deployment VPC Bersama standar, dengan semua komponen load balancer dan backend berada dalam project layanan. Jenis deployment ini didukung oleh semua Load Balancer Aplikasi.

Load balancer menggunakan alamat IP dan subnet dari project host. Klien dapat mengakses Load Balancer Aplikasi internal jika berada di jaringan VPC Bersama dan region yang sama dengan load balancer. Klien dapat berada di project host, atau di project layanan yang terpasang, atau di jaringan yang terhubung.

Load Balancer Aplikasi Internal di jaringan VPC Bersama.
Load Balancer Aplikasi internal di jaringan VPC Bersama (klik untuk memperbesar).

Backend serverless di lingkungan VPC Bersama

Untuk Load Balancer Aplikasi internal yang menggunakan backend NEG serverless, layanan Cloud Run pendukung harus berada dalam project layanan yang sama dengan layanan backend dan NEG serverless. Komponen frontend load balancer (aturan penerusan, proxy target, peta URL) dapat dibuat di project host, project layanan yang sama dengan komponen backend, atau project layanan lain dalam lingkungan VPC Bersama yang sama.

Referensi layanan lintas project

Referensi layanan lintas project adalah model deployment tempat frontend dan peta URL load balancer berada dalam satu project, sedangkan layanan backend dan backend load balancer berada dalam project yang berbeda.

Referensi layanan lintas project memungkinkan organisasi mengonfigurasi satu load balancer pusat dan merutekan traffic ke ratusan layanan yang didistribusikan di beberapa project yang berbeda. Anda dapat mengelola semua aturan dan kebijakan perutean traffic secara terpusat dalam satu peta URL. Anda juga dapat mengaitkan load balancer dengan satu set nama host dan sertifikat SSL. Oleh karena itu, Anda dapat mengoptimalkan jumlah load balancer yang diperlukan untuk men-deploy aplikasi, serta menurunkan pengelolaan, biaya operasional, dan persyaratan kuota.

Dengan memiliki project yang berbeda untuk setiap tim fungsional, Anda juga dapat mencapai pemisahan peran dalam organisasi. Pemilik layanan dapat berfokus pada membangun layanan dalam project layanan, sementara tim jaringan dapat menyediakan dan memelihara load balancer di project lain, dan keduanya dapat dihubungkan menggunakan referensi layanan lintas project.

Pemilik layanan dapat mempertahankan otonomi atas eksposur layanan mereka dan mengontrol pengguna mana yang dapat mengakses layanan mereka menggunakan load balancer. Hal ini dicapai dengan peran IAM khusus yang disebut Compute Load Balancer Services User role (roles/compute.loadBalancerServiceUser).

Untuk Load Balancer Aplikasi internal, referensi layanan lintas project hanya didukung dalam lingkungan VPC Bersama.

Untuk mempelajari cara mengonfigurasi VPC Bersama untuk Load Balancer Aplikasi internal—dengan dan tanpa referensi layanan lintas project—lihat Menyiapkan Load Balancer Aplikasi internal dengan VPC Bersama.

Catatan penggunaan untuk referensi layanan lintas project

  • Anda tidak dapat mereferensikan layanan backend lintas project jika layanan backend memiliki backend NEG internet regional. Semua jenis backend lainnya didukung.
  • Cloud de Confiance tidak membedakan antara resource (misalnya, layanan backend) yang menggunakan nama yang sama di beberapa project. Oleh karena itu, saat menggunakan referensi layanan lintas project, sebaiknya Anda menggunakan nama layanan backend yang unik di seluruh project dalam organisasi Anda.

Contoh 1: Frontend dan backend load balancer di project layanan yang berbeda

Berikut adalah contoh deployment VPC Bersama tempat frontend dan peta URL load balancer dibuat di project layanan A dan peta URL mereferensikan layanan backend di project layanan B.

Dalam hal ini, Admin Jaringan atau Admin Load Balancer di project layanan A memerlukan akses ke layanan backend di project layanan B. Admin project layanan B memberikan peran Compute Load Balancer Services User (roles/compute.loadBalancerServiceUser) kepada Admin Load Balancer di project layanan A yang ingin mereferensikan layanan backend di project layanan B.

Frontend load balancer dan peta URL di project layanan.
Frontend dan backend load balancer di project layanan yang berbeda (klik untuk memperbesar).

Contoh 2: Frontend load balancer di project host dan backend di project layanan

Berikut adalah contoh deployment VPC Bersama tempat frontend dan peta URL load balancer dibuat di project host, serta layanan backend (dan backend) dibuat di project layanan.

Dalam hal ini, Admin Jaringan atau Admin Load Balancer di project host memerlukan akses ke layanan backend di project layanan. Admin project layanan memberikan peran Compute Load Balancer Services User (roles/compute.loadBalancerServiceUser) kepada Admin Load Balancer di project host A yang ingin mereferensikan layanan backend di project layanan.

Frontend load balancer dan peta URL di project host.
Frontend load balancer dan peta URL di project host (klik untuk memperbesar).

Waktu tunggu dan percobaan ulang

Load Balancer Aplikasi internal mendukung jenis waktu tunggu berikut:

Jenis dan deskripsi waktu tunggu Nilai default Mendukung nilai kustom
Waktu tunggu layanan backend

Batas waktu permintaan dan respons. Mewakili jumlah waktu maksimum yang diizinkan antara load balancer mengirim byte pertama permintaan ke backend dan backend menampilkan byte terakhir respons HTTP ke load balancer. Jika backend belum menampilkan seluruh respons HTTP ke load balancer dalam batas waktu ini, sisa data respons akan dihapus.
  • Untuk NEG serverless pada layanan backend: 60 menit
  • Untuk semua jenis backend lainnya di layanan backend: 30 detik
Waktu tunggu keepalive HTTP klien

Durasi maksimum koneksi TCP antara klien dan proxy Envoy terkelola load balancer dapat tidak aktif. (Koneksi TCP yang sama mungkin digunakan untuk beberapa permintaan HTTP.)

 610 detik
Waktu tunggu keep-alive HTTP backend

Jumlah waktu maksimum koneksi TCP antara proxy Envoy terkelola load balancer dan backend dapat tidak aktif. (Koneksi TCP yang sama mungkin digunakan untuk beberapa permintaan HTTP.)

 10 menit (600 detik)

Waktu tunggu layanan backend

Waktu tunggu layanan backend yang dapat dikonfigurasi menunjukkan jumlah waktu maksimum yang diperlukan load balancer untuk menunggu backend memproses permintaan HTTP dan menampilkan respons HTTP yang sesuai. Kecuali untuk NEG serverless, nilai default untuk waktu tunggu layanan backend adalah 30 detik.

Misalnya, jika Anda ingin mendownload file berukuran 500 MB, dan nilai waktu tunggu layanan backend adalah 90 detik, load balancer akan mengharapkan backend mengirimkan seluruh file berukuran 500 MB dalam waktu 90 detik. Waktu tunggu layanan backend dapat dikonfigurasi agar tidak cukup bagi backend untuk mengirim respons HTTP lengkapnya. Dalam situasi ini, jika load balancer setidaknya telah menerima header respons HTTP dari backend, load balancer akan menampilkan header respons lengkap dan isi respons sebanyak mungkin yang dapat diperoleh dalam waktu tunggu layanan backend.

Sebaiknya Anda menetapkan waktu tunggu layanan backend ke durasi terlama yang Anda perkirakan dibutuhkan backend untuk memproses respons HTTP. Jika software yang berjalan di backend Anda memerlukan lebih banyak waktu untuk memproses permintaan HTTP dan menampilkan seluruh responsnya, sebaiknya tingkatkan waktu tunggu layanan backend.

Waktu tunggu layanan backend menerima nilai antara 1 dan 2,147,483,647 detik; namun, nilai yang lebih besar bukanlah opsi konfigurasi yang praktis. Cloud de Confiance juga tidak menjamin bahwa koneksi TCP yang mendasarinya dapat tetap terbuka selama keseluruhan nilai waktu tunggu layanan backend. Sistem klien harus menerapkan logika percobaan ulang, bukan mengandalkan koneksi TCP agar tetap terbuka dalam jangka waktu yang lama.

Untuk koneksi websocket yang digunakan dengan Load Balancer Aplikasi internal, koneksi websocket aktif tidak mengikuti waktu tunggu layanan backend. Koneksi websocket yang tidak ada aktivitas akan ditutup setelah waktu tunggu layanan backend berakhir.

Cloud de Confiance secara berkala memulai ulang atau mengubah jumlah tugas software Envoy yang melayani. Semakin lama nilai waktu tunggu layanan backend, semakin besar kemungkinan bahwa mulai ulang atau penggantian tugas Envoy akan menghentikan koneksi TCP.

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

Konsol

Ubah kolom Waktu tunggu layanan backend load balancer.

gcloud

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

API

Mengubah parameter timeoutSec untuk resource regionBackendServices

Waktu tunggu keepalive HTTP klien

Waktu tunggu keep-alive HTTP klien menunjukkan jumlah waktu maksimum koneksi TCP dapat tidak ada aktivitas antara klien (downstream) dan proxy Envoy. Nilai waktu tunggu HTTP keep-alive klien default adalah 610 detik. Anda dapat mengonfigurasi waktu tunggu dengan nilai antara 5 dan 1.200 detik.

Waktu tunggu HTTP keep-alive juga disebut waktu tunggu tidak ada aktivitas TCP.

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

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

Waktu tunggu keepalive HTTP backend

Load Balancer Aplikasi internal adalah proxy yang menggunakan koneksi TCP pertama antara klien (downstream) dan proxy Envoy, serta koneksi TCP kedua antara proxy Envoy dan backend Anda.

Koneksi TCP sekunder load balancer mungkin tidak ditutup setelah setiap permintaan; koneksi tersebut dapat tetap terbuka untuk menangani beberapa permintaan dan respons HTTP. Waktu tunggu keepalive HTTP backend menentukan waktu tunggu tidak ada aktivitas TCP antara load balancer dan backend Anda. Waktu tunggu keepalive HTTP backend tidak berlaku untuk websocket.

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

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

Saat waktu tunggu keep-alive HTTP backend berakhir, proxy GFE atau Envoy akan mengirim TCP FIN ke VM backend untuk menutup koneksi dengan benar.

Tabel berikut mencantumkan perubahan yang diperlukan untuk mengubah nilai waktu tunggu keepalive untuk software server web umum.

Software server web Parameter Setelan default Setelan yang direkomendasikan
Apache KeepAliveTimeout KeepAliveTimeout 5 KeepAliveTimeout 620
nginx keepalive_timeout keepalive_timeout 75s; keepalive_timeout 620s;

Upaya coba lagi

Untuk mengonfigurasi percobaan ulang, Anda dapat menggunakan kebijakan percobaan ulang di peta URL. Jumlah percobaan ulang default (numRetries) adalah 1. perTryTimeout maksimum yang dapat dikonfigurasi adalah 24 jam.

Tanpa kebijakan percobaan ulang, permintaan yang gagal dan tidak memiliki isi HTTP (misalnya, permintaan GET) yang menghasilkan respons HTTP 502, 503, atau 504 akan dicoba ulang satu kali.

Permintaan HTTP POST tidak akan dicoba lagi.

Permintaan yang dicoba lagi hanya menghasilkan satu entri log untuk respons akhir.

Untuk mengetahui informasi selengkapnya, lihat Logging dan pemantauan Load Balancer Aplikasi internal.

Mengakses jaringan yang terhubung

Klien Anda dapat mengakses Load Balancer Aplikasi internal di jaringan VPC Anda dari jaringan yang terhubung menggunakan hal berikut:

  • Peering Jaringan VPC
  • Cloud VPN dan Cloud Interconnect

Untuk contoh mendetail, lihat Load Balancer Aplikasi internal dan jaringan yang terhubung.

Afinitas sesi

Afinitas sesi, yang dikonfigurasi pada layanan backend Load Balancer Aplikasi, memberikan upaya terbaik untuk mengirim permintaan dari klien tertentu ke backend yang sama selama jumlah instance atau endpoint backend yang responsif tetap konstan, dan selama instance atau endpoint backend yang dipilih sebelumnya tidak mencapai kapasitas. Kapasitas target mode balancing menentukan kapan backend mencapai kapasitas.

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

Tabel: Setelan afinitas sesi yang didukung
Produk Opsi afinitas sesi
  • Tidak ada (NONE)
  • IP Klien (CLIENT_IP)
  • Cookie yang dihasilkan (GENERATED_COOKIE)
  • Kolom header (HEADER_FIELD)
  • Cookie HTTP (HTTP_COOKIE)
  • Afinitas berbasis cookie stateful (STRONG_COOKIE_AFFINITY)

Perhatikan juga:

  • Nilai default efektif kebijakan lokalitas load balancing (localityLbPolicy) berubah sesuai dengan setelan afinitas sesi Anda. Jika afinitas sesi tidak dikonfigurasi—yaitu, jika afinitas sesi tetap pada nilai default NONE—maka nilai default untuk localityLbPolicy adalah ROUND_ROBIN. Jika afinitas sesi ditetapkan ke nilai selain NONE, nilai default untuk localityLbPolicy adalah MAGLEV.
  • Untuk Load Balancer Aplikasi internal, jangan konfigurasikan afinitas sesi jika Anda menggunakan pemisahan traffic berbobot. Jika Anda melakukannya, konfigurasi pemisahan traffic berbobot akan diprioritaskan.

Perhatikan hal-hal berikut saat mengonfigurasi afinitas sesi:

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

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

Jenis afinitas sesi

Afinitas sesi untuk Load Balancer Aplikasi internal dapat diklasifikasikan ke dalam salah satu kategori berikut:
  • Afinitas sesi berbasis hash (NONE, CLIENT_IP)
  • Afinitas sesi berbasis header HTTP (HEADER_FIELD)
  • Afinitas sesi berbasis cookie (GENERATED_COOKIE, HTTP_COOKIE, STRONG_COOKIE_AFFINITY)

Afinitas sesi berbasis hash

Untuk afinitas sesi berbasis hash, load balancer menggunakan algoritma hashing yang konsisten untuk memilih backend yang memenuhi syarat. Setelan afinitas sesi menentukan kolom mana dari header IP yang digunakan untuk menghitung hash.

Afinitas sesi berbasis hash dapat berupa salah satu jenis berikut:

Tidak ada

Setelan afinitas sesi NONE tidak berarti tidak ada afinitas sesi. Artinya, tidak ada opsi afinitas sesi yang dikonfigurasi secara eksplisit.

Hashing selalu dilakukan untuk memilih backend. Setelan afinitas sesi NONE berarti load balancer menggunakan hash 5 tuple untuk memilih backend. Hash 5-tuple terdiri dari alamat IP sumber, port sumber, protokol, alamat IP tujuan, dan port tujuan.

Afinitas sesi NONE adalah nilai default.

Afinitas IP klien

Afinitas sesi IP Klien (CLIENT_IP) adalah hash 2 tuple yang dibuat dari alamat IP sumber dan tujuan paket. Afinitas IP klien meneruskan semua permintaan dari alamat IP klien yang sama ke backend yang sama, selama backend tersebut memiliki kapasitas dan tetap responsif.

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

  • Alamat IP tujuan paket hanya sama dengan alamat IP aturan penerusan load balancer jika paket dikirim langsung ke load balancer.
  • Alamat IP sumber paket mungkin tidak cocok dengan alamat IP yang terkait dengan klien asli jika paket diproses oleh sistem NAT atau proxy perantara sebelum dikirim ke load balancer Cloud de Confiance . 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.

Afinitas sesi berbasis header HTTP

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

Afinitas kolom header didukung jika kondisi berikut terpenuhi:

  • Kebijakan lokalitas load balancing adalah RING_HASH atau MAGLEV.
  • consistentHash layanan backend menentukan nama header HTTP (httpHeaderName).

Afinitas sesi berbasis cookie dapat berupa salah satu jenis berikut:

Saat Anda menggunakan afinitas berbasis cookie yang dihasilkan (GENERATED_COOKIE), load balancer menyertakan cookie HTTP di header Set-Cookie sebagai respons terhadap permintaan HTTP awal.

Nama cookie yang dihasilkan bervariasi, bergantung pada jenis load balancer.

Produk Nama cookie
Load Balancer Aplikasi internal lintas region GCILB
Load Balancer Aplikasi internal regional GCILB

Atribut jalur cookie yang dibuat selalu berupa garis miring (/), sehingga berlaku untuk semua layanan backend pada peta URL yang sama, asalkan layanan backend lainnya juga menggunakan afinitas cookie yang dibuat.

Anda dapat mengonfigurasi nilai time to live (TTL) cookie antara 0 dan 1,209,600 detik (inklusif) menggunakan parameter layanan backend affinityCookieTtlSec. Jika affinityCookieTtlSec tidak ditentukan, nilai TTL defaultnya adalah 0.

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

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

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

Untuk mengetahui informasi selengkapnya, lihat kehilangan afinitas sesi.

Saat Anda menggunakan afinitas berbasis cookie HTTP (HTTP_COOKIE), load balancer menyertakan cookie HTTP di header Set-Cookie sebagai respons terhadap permintaan HTTP awal. Anda menentukan nama, jalur, dan time to live (TTL) untuk cookie.

Semua Load Balancer Aplikasi mendukung afinitas berbasis cookie HTTP.

Anda dapat mengonfigurasi nilai TTL cookie menggunakan detik, pecahan detik (sebagai nanodetik), atau detik ditambah pecahan detik (sebagai nanodetik) menggunakan parameter layanan backend dan nilai yang valid berikut:

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

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

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

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

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

Untuk mengetahui informasi selengkapnya, lihat kehilangan afinitas sesi.

Afinitas sesi berbasis cookie stateful

Saat Anda menggunakan afinitas berbasis cookie stateful (STRONG_COOKIE_AFFINITY), load balancer 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.

Load balancer berikut mendukung afinitas berbasis cookie stateful:

  • Load Balancer Aplikasi eksternal regional
  • Load Balancer Aplikasi internal regional

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 dapat ditetapkan ke nilai yang mewakili lebih dari dua minggu (1.209.600 detik).

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

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

Untuk mengetahui informasi selengkapnya, lihat kehilangan afinitas sesi.

Arti TTL nol untuk afinitas berbasis cookie

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

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

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

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

Kehilangan afinitas sesi

Semua opsi afinitas sesi memerlukan hal berikut:

  • Instance atau endpoint backend yang dipilih harus tetap dikonfigurasi sebagai backend. Afinitas sesi dapat terganggu saat salah satu peristiwa berikut terjadi:
    • Anda menghapus instance yang dipilih dari grup instance-nya.
    • Penskalaan otomatis atau autohealing grup instance terkelola akan menghapus instance yang dipilih dari grup instance terkelolanya.
    • Anda menghapus endpoint yang dipilih dari NEG-nya.
    • Anda menghapus grup instance atau NEG yang berisi instance atau endpoint yang dipilih dari layanan backend.
  • Instance atau endpoint backend yang dipilih harus tetap responsif. Afinitas sesi dapat terganggu jika instance atau endpoint yang dipilih gagal dalam health check.
Kecuali untuk afinitas sesi berbasis cookie stateful, semua opsi afinitas sesi memiliki persyaratan tambahan berikut:

  • Grup instance atau NEG yang berisi instance atau endpoint yang dipilih tidak boleh penuh seperti yang ditentukan oleh kapasitas targetnya. (Untuk grup instance terkelola regional, komponen zonal dari grup instance yang berisi instance yang dipilih tidak boleh penuh.) Afinitas sesi dapat terganggu jika grup instance atau NEG penuh, sedangkan grup instance atau NEG lainnya tidak. Karena kepenuhan dapat berubah dengan cara yang tidak dapat diprediksi saat menggunakan mode penyeimbangan UTILIZATION, Anda harus menggunakan mode penyeimbangan RATE atau CONNECTION untuk meminimalkan situasi saat afinitas sesi dapat terganggu.

  • Jumlah total endpoint atau backend instance 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 apa pun dari backend NEG.
      • Anda menghapus grup instance backend atau NEG yang ada dan tidak kosong dari layanan backend.

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

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

Failover

Jika backend bermasalah, traffic akan otomatis dialihkan ke backend yang responsif.

Tabel berikut menjelaskan perilaku failover di setiap mode:

Mode load balancer Perilaku failover Perilaku saat semua backend tidak responsif
Load Balancer Aplikasi internal regional

Failover otomatis ke backend yang responsif di region yang sama.

Proxy Envoy mengirimkan traffic ke backend yang responsif di suatu region berdasarkan distribusi traffic yang dikonfigurasi.

 Menampilkan HTTP 503

Ketersediaan tinggi dan failover lintas region

Untuk Load Balancer Aplikasi internal regional

Untuk mencapai ketersediaan tinggi, deploy beberapa Load Balancer Aplikasi internal regional individual di region yang paling mendukung traffic aplikasi Anda. Kemudian, Anda menggunakan kebijakan perutean geolokasi Cloud DNS untuk mendeteksi apakah load balancer merespons selama pemadaman layanan regional. Kebijakan geolokasi merutekan traffic ke region terdekat berikutnya yang tersedia berdasarkan asal permintaan klien. Health check tersedia secara default untuk Load Balancer Aplikasi internal.

Dukungan WebSocket

Cloud de Confiance Load balancer berbasis HTTP(S) mendukung protokol WebSocket saat Anda menggunakan HTTP/1.1 (HTTP atau HTTPS) atau HTTP/2 sebagai protokol ke backend. Load balancer tidak memerlukan konfigurasi apa pun untuk mem-proxy koneksi WebSocket.

Protokol WebSocket menyediakan saluran komunikasi full-duplex antara klien dan load balancer. Untuk mengetahui informasi selengkapnya, lihat RFC 6455.

Untuk koneksi HTTP/1.1, protokol WebSocket menggunakan mekanisme Upgrade HTTP/1.1 untuk mentransisikan koneksi TCP dari HTTP ke koneksi WebSocket. Protokol WebSocket melalui HTTP/1.1 berfungsi sebagai berikut:

  1. Load balancer mengenali permintaan Upgrade WebSocket dari klien HTTP atau HTTPS. Permintaan berisi header Connection: Upgrade dan Upgrade: websocket, diikuti dengan header permintaan terkait WebSocket lainnya yang relevan.
  2. Backend mengirimkan respons Upgrade WebSocket. Respons ini terdiri dari respons 101 Switching Protocols dengan header Connection: Upgrade dan Upgrade: websocket, serta header respons terkait WebSocket lainnya.
  3. Load balancer mem-proxy traffic dua arah selama durasi koneksi saat ini.

Jika backend instance menampilkan kode status HTTP 426 atau HTTP 502, load balancer akan menutup koneksi.

Untuk koneksi HTTP/2, protokol WebSocket menggunakan metode CONNECT yang diperluas bersama dengan kolom pseudo-header (seperti :protocol) untuk membuat tunnel pada satu aliran HTTP/2 yang dapat membawa data untuk WebSockets (RFC 8441). Protokol WebSocket melalui HTTP/2 berfungsi sebagai berikut:

  1. Server backend mengirimkan frame SETTINGS HTTP/2 yang berisi parameter SETTINGS_ENABLE_CONNECT_PROTOCOL yang ditetapkan ke 1. Tindakan ini memberi tahu load balancer bahwa backend mendukung metode CONNECT yang diperluas.

  2. Setelah menerima setelan ini, load balancer akan mengenalinya dan dapat meneruskan permintaan upgrade WebSocket. Layanan ini mengirimkan permintaan upgrade ke backend menggunakan metode CONNECT yang diperluas. Permintaan berisi header semu :method: CONNECT dan :protocol: websocket, beserta header permintaan terkait WebSocket lainnya yang relevan.

  3. Backend mengirimkan respons berhasil WebSocket. Server backend mengirimkan respons 200 OK (bukan respons 101 Switching Protocols yang digunakan di HTTP/1.1) untuk membuat tunnel WebSocket melalui satu aliran koneksi HTTP/2.

  4. Load balancer memproksi traffic dua arah melalui stream HTTP/2 yang dibuat.

Jika backend instance menampilkan kode status 426 atau 502, upgrade WebSocket tidak akan terjadi, dan kode status akan disebarkan ke klien.

Afinitas sesi untuk WebSocket berfungsi sama seperti untuk permintaan lainnya. Untuk mengetahui informasi selengkapnya, lihat Afinitas sesi.

Dukungan HTTP/2

HTTP/2 adalah revisi besar dari protokol HTTP/1. Ada 2 mode dukungan HTTP/2:

  • HTTP/2 melalui TLS
  • HTTP/2 Cleartext melalui TCP

HTTP/2 melalui TLS

HTTP/2 melalui TLS didukung untuk koneksi antara klien dan Load Balancer Aplikasi eksternal, serta untuk koneksi antara load balancer dan backend-nya.

Load balancer otomatis menegosiasikan HTTP/2 dengan klien sebagai bagian dari TLS handshake menggunakan ekstensi TLS ALPN. Meskipun load balancer dikonfigurasi untuk menggunakan HTTPS, klien modern akan menggunakan HTTP/2 secara default. Hal ini dikontrol di klien, bukan di load balancer.

Jika klien tidak mendukung HTTP/2 dan load balancer dikonfigurasi untuk menggunakan HTTP/2 antara load balancer dan instance backend, load balancer mungkin masih menegosiasikan koneksi HTTPS atau menerima permintaan HTTP yang tidak aman. Permintaan HTTPS atau HTTP tersebut kemudian diubah oleh load balancer untuk mem-proxy permintaan melalui HTTP/2 ke backend instance.

Untuk menggunakan HTTP/2 melalui TLS, Anda harus mengaktifkan TLS di backend dan menetapkan protokol layanan backend ke HTTP2. Untuk mengetahui informasi selengkapnya, lihat Enkripsi dari load balancer ke backend.

Streaming serentak maksimum HTTP/2

Setelan HTTP/2 SETTINGS_MAX_CONCURRENT_STREAMS menjelaskan jumlah maksimum streaming yang diterima endpoint, yang dimulai oleh peer. Nilai yang diiklankan oleh klien HTTP/2 ke load balancerCloud de Confiance pada dasarnya tidak berarti karena load balancer tidak memulai stream ke klien.

Jika load balancer menggunakan HTTP/2 untuk berkomunikasi dengan server yang berjalan di VM, load balancer akan mengikuti nilai SETTINGS_MAX_CONCURRENT_STREAMS yang diiklankan oleh server, hingga nilai maksimum 100. Dalam arah permintaan (Cloud de Confiance load balancer → server gRPC), load balancer menggunakan frame SETTINGS awal dari server gRPC untuk menentukan jumlah streaming per koneksi yang dapat digunakan secara bersamaan. Jika server mengiklankan nilai yang lebih tinggi dari 100, load balancer akan menggunakan 100 sebagai jumlah maksimum streaming serentak. Jika nilai nol diiklankan, load balancer tidak dapat meneruskan permintaan ke server, dan hal ini dapat menyebabkan error.

Ukuran tabel header dinamis HTTP/2

HTTP/2 meningkatkan HTTP/1.1 secara signifikan dengan fitur seperti multiplexing dan kompresi header HPACK. HPACK menggunakan tabel dinamis yang meningkatkan kompresi header, sehingga semuanya menjadi lebih cepat. Untuk memahami dampak perubahan ukuran tabel header dinamis di HTTP/2, cara fitur ini dapat meningkatkan performa, dan cara bug tertentu di berbagai library klien HTTP dapat menyebabkan masalah dalam kompresi header HPACK, lihat artikel komunitas.

Batasan HTTP/2

  • HTTP/2 antara load balancer dan instance dapat memerlukan koneksi TCP yang jauh lebih banyak ke instance daripada HTTP atau HTTPS. Penggabungan koneksi, pengoptimalan yang mengurangi jumlah koneksi ini dengan HTTP atau HTTPS, tidak tersedia dengan HTTP/2. Akibatnya, Anda mungkin melihat latensi backend yang tinggi karena koneksi backend dibuat lebih sering.
  • HTTP/2 antara load balancer dan backend tidak mendukung push server.
  • Tingkat error gRPC dan volume permintaan tidak terlihat di Cloud de Confiance API atau konsol Cloud de Confiance . Jika endpoint gRPC menampilkan error, log load balancer dan data pemantauan akan melaporkan kode status HTTP 200 OK.

HTTP/2 melalui TCP cleartext

HTTP/2 melalui TCP cleartext, yang diwakili oleh string "h2c" per RFC 7540, memungkinkan Anda menggunakan HTTP/2 tanpa enkripsi TLS. Fitur ini didukung untuk koneksi berikut:

  • Klien ke load balancer: Didukung secara otomatis; tidak memerlukan konfigurasi khusus.

Dukungan H2C juga tersedia untuk load balancer yang dibuat menggunakan pengontrol Gateway GKE dan Cloud Service Mesh.

Dukungan gRPC

gRPC adalah framework open source untuk remote procedure call. gRPC didasarkan pada standar HTTP/2. Kasus penggunaan untuk gRPC mencakup hal berikut:

  • Sistem terdistribusi yang sangat skalabel dan berlatensi rendah
  • Mengembangkan klien seluler yang berkomunikasi dengan server cloud
  • Merancang protokol baru yang harus akurat, efisien, dan tidak bergantung pada bahasa
  • Desain berlayer untuk mengaktifkan ekstensi, autentikasi, dan logging

Untuk menggunakan gRPC dengan aplikasi Cloud de Confiance , Anda harus mem-proxy permintaan end-to-end melalui HTTP/2. Untuk melakukannya, buat Load Balancer Aplikasi dengan salah satu konfigurasi berikut:

  • HTTP/2 melalui TLS antara klien dan load balancer serta H2C antara load balancer dan backend: Anda membuat load balancer HTTPS (yang dikonfigurasi dengan proxy HTTPS target dan sertifikat SSL). Selain itu, Anda mengonfigurasi load balancer untuk menggunakan HTTP/2 untuk koneksi yang tidak dienkripsi antara load balancer dan backend-nya dengan menetapkan protokol layanan backend ke H2C.

  • Traffic yang dienkripsi secara end-to-end menggunakan HTTP/2 melalui TLS: Anda membuat load balancer HTTPS (yang dikonfigurasi dengan proxy HTTPS target dan sertifikat SSL). Load balancer menegosiasikan HTTP/2 dengan klien sebagai bagian dari handshake SSL menggunakan ekstensi TLS ALPN.

    Selain itu, Anda harus memastikan bahwa backend dapat menangani traffic TLS dan mengonfigurasi load balancer untuk menggunakan HTTP/2 untuk koneksi terenkripsi antara load balancer dan backend-nya dengan menetapkan protokol layanan backend ke HTTP2.

    Load balancer mungkin masih menegosiasikan HTTPS dengan beberapa klien atau menerima permintaan HTTP yang tidak aman pada load balancer yang dikonfigurasi untuk menggunakan HTTP/2 antara load balancer dan backend instance. Permintaan HTTP atau HTTPS tersebut diubah oleh load balancer untuk mem-proxy permintaan melalui HTTP/2 ke backend instance.

Dukungan TLS

Secara default, proxy target HTTPS hanya menerima TLS 1.0, 1.1, 1.2, dan 1.3 saat menghentikan permintaan SSL klien.

Jika menggunakan HTTPS sebagai protokol layanan backend, Load Balancer Aplikasi internal dapat menegosiasikan TLS 1.2 atau 1.3 ke backend.

Dukungan TLS bersama

Mutual TLS, atau mTLS, adalah protokol standar industri untuk autentikasi bersama antara klien dan server. mTLS membantu memastikan bahwa klien dan server saling mengautentikasi dengan memverifikasi bahwa masing-masing memiliki sertifikat valid yang dikeluarkan oleh certificate authority (CA) tepercaya. Tidak seperti TLS standar, yang hanya mengautentikasi server, mTLS mewajibkan klien dan server untuk menyajikan sertifikat, yang mengonfirmasi identitas kedua pihak sebelum komunikasi dilakukan.

Semua Load Balancer Aplikasi mendukung mTLS. Dengan mTLS, load balancer meminta klien mengirimkan sertifikat untuk mengautentikasi dirinya sendiri selama TLS handshake dengan load balancer. Anda dapat mengonfigurasi penyimpanan tepercaya Certificate Manager yang kemudian digunakan load balancer untuk memvalidasi rantai kepercayaan sertifikat klien.

Untuk mengetahui informasi selengkapnya tentang mTLS, lihat Autentikasi TLS bersama.

Batasan

  • Tidak ada jaminan bahwa permintaan dari klien di satu zona region dikirim ke backend yang berada di zona yang sama dengan klien. Afinitas sesi tidak mengurangi komunikasi antar-zona.

  • Load Balancer Aplikasi internal tidak kompatibel dengan fitur berikut:

  • Untuk menggunakan sertifikat Certificate Manager dengan Load Balancer Aplikasi internal, Anda harus menggunakan API atau gcloud CLI. KonsolCloud de Confiance tidak mendukung sertifikat Certificate Manager.

  • Klien yang terhubung ke Load Balancer Aplikasi internal harus menggunakan HTTP versi 1.1 atau yang lebih baru. HTTP 1.0 tidak didukung.

  • Cloud de Confiance tidak akan memperingatkan Anda jika subnet khusus proxy kehabisan alamat IP.

  • Aturan penerusan internal yang digunakan oleh Load Balancer Aplikasi internal Anda harus memiliki tepat satu port.

  • Saat menggunakan Load Balancer Aplikasi internal dengan Cloud Run di lingkungan VPC Bersama, jaringan VPC mandiri dalam project layanan dapat mengirim traffic ke layanan Cloud Run lainnya yang di-deploy di project layanan lain dalam lingkungan VPC Bersama yang sama. Ini adalah masalah umum.

  • Cloud de Confiance tidak menjamin bahwa koneksi TCP yang mendasarinya dapat tetap terbuka selama durasi nilai waktu tunggu layanan backend. Sistem klien harus menerapkan logika percobaan ulang, bukan mengandalkan koneksi TCP agar tetap terbuka dalam jangka waktu yang lama.

  • Anda tidak dapat menentukan alamat IP non-RFC 1918 literal (misalnya, 100.64.0.0/10 atau rentang publik yang digunakan secara pribadi) secara langsung menggunakan flag --address saat membuat aturan penerusan. Tindakan ini akan memicu error validasi API yang menyatakan bahwa alamat tersebut bukan alamat RFC 1918.

    Untuk menggunakan alamat IP non-RFC 1918, lakukan salah satu hal berikut saat Anda membuat aturan penerusan:

    • Hapus flag --address agar Cloud de Confiance dapat mengalokasikan alamat IP yang valid dari subnet secara dinamis.
    • Cadangkan resource alamat IP bernama terlebih dahulu di dalam subnet target dengan --purpose=SHARED_LOADBALANCER_VIP. Saat membuat aturan penerusan, rujuk nama yang dicadangkan menggunakan flag --address.

Langkah berikutnya