Ringkasan Load Balancer Jaringan proxy internal

Load Balancer Jaringan proxy internal Google Cloud adalah load balancer berbasis proxy yang didukung oleh software proxy Envoy open source dan stack virtualisasi jaringan Andromeda.

Load Balancer Jaringan proxy internal adalah load balancer Lapisan 4 yang memungkinkan Anda menjalankan dan menskalakan traffic layanan TCP di balik alamat IP internal regional yang hanya dapat diakses oleh klien di jaringan VPC yang sama atau klien yang terhubung ke jaringan VPC Anda. Load balancer terlebih dahulu menghentikan koneksi TCP antara klien dan load balancer di proxy Envoy. Proxy membuka koneksi TCP kedua ke backend yang dihosting di Google Cloud, lokal, atau lingkungan cloud lainnya. Untuk kasus penggunaan lainnya, lihat Ringkasan Load Balancer Jaringan Proxy.

Mode operasi

Anda dapat mengonfigurasi Load Balancer Jaringan proxy internal dalam mode berikut:

• Load Balancer Jaringan proxy internal regional. Ini adalah load balancer regional yang diimplementasikan sebagai layanan terkelola berdasarkan proxy Envoy open source. Dengan mode regional, semua klien dan backend berasal dari region yang ditentukan, yang membantu saat Anda memerlukan kepatuhan regional.

• Load Balancer Jaringan proxy internal lintas region. Ini adalah load balancer multi-region yang diimplementasikan sebagai layanan terkelola berdasarkan proxy Envoy open source. Mode lintas region memungkinkan Anda melakukan load balancing traffic ke layanan backend yang didistribusikan secara global dengan backend di beberapa region, termasuk pengelolaan traffic yang memastikan traffic diarahkan ke backend terdekat. Load balancer ini juga memungkinkan ketersediaan tinggi. Menempatkan backend di beberapa region membantu menghindari kegagalan di satu region. Jika backend satu region nonaktif, traffic dapat dialihkan ke region lain. Alamat IP aturan penerusan load balancer selalu dapat diakses di semua region.

  Tabel berikut menjelaskan perbedaan penting antara mode regional dan lintas region:

  Fitur	Load Balancer Jaringan proxy internal regional	Load Balancer Jaringan proxy internal lintas region
  Alamat IP virtual (VIP) load balancer.	Dialokasikan dari subnet di region Google Cloud tertentu.	Dialokasikan dari subnet di region Google Cloud tertentu. Alamat VIP dari beberapa region dapat menggunakan layanan backend global yang sama.
  Akses klien	Tidak dapat diakses secara global secara default. Anda dapat mengaktifkan akses global.	Selalu dapat diakses secara global. Klien dari region Google Cloud mana pun dapat mengirim traffic ke load balancer.
  Backend yang di-load balanced	Backend regional. Load balancer hanya dapat mengirim traffic ke backend yang berada di region yang sama dengan proxy load balancer.	Backend global. Load balancer dapat mengirim traffic ke backend di region mana pun.
  Ketersediaan tinggi dan failover	Failover otomatis ke backend yang responsif di region yang sama.	Failover otomatis ke backend yang responsif di region yang sama atau berbeda.

Mengidentifikasi mode

Konsol

1. Di konsol Google Cloud , buka halaman Load balancing.

   Buka Load balancing

2. Di tab Load Balancers, Anda dapat melihat jenis, protokol, dan region load balancer. Jika region kosong, load balancer berada dalam mode lintas region. Tabel berikut merangkum cara mengidentifikasi mode load balancer.

   Mode load balancer	Jenis load balancer	Jenis akses	Wilayah
   Load Balancer Jaringan proxy internal regional	Jaringan (Proxy)	Internal	Menentukan region
   Load Balancer Jaringan proxy internal lintas region	Jaringan (Proxy)	Internal

gcloud

Untuk menentukan mode load balancer, jalankan perintah berikut:

gcloud compute forwarding-rules describe FORWARDING_RULE_NAME

Di output perintah, periksa skema load balancing, region, dan tingkat jaringan. Tabel berikut merangkum cara mengidentifikasi mode load balancer.

Mode load balancer	Skema load balancing	Aturan penerusan
Load Balancer Jaringan proxy internal regional	INTERNAL_MANAGED	Regional
Load Balancer Jaringan proxy internal lintas region	INTERNAL_MANAGED	Global

Penting: Setelah membuat load balancer, Anda tidak dapat mengedit modenya. Sebagai gantinya, Anda harus menghapus load balancer dan membuat yang baru.

Arsitektur

Diagram berikut menunjukkan resource Google Cloud yang diperlukan untuk Load Balancer Jaringan proxy internal.

Regional

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

Komponen Load Balancer Jaringan proxy internal regional (klik untuk memperbesar).

Lintas region

Diagram ini menunjukkan komponen deployment Load Balancer Jaringan proxy internal lintas region di Paket Premium dalam jaringan VPC yang sama. Setiap aturan penerusan global menggunakan alamat IP regional yang digunakan klien untuk terhubung.

Komponen Load Balancer Jaringan proxy internal lintas region (klik untuk memperbesar).

Subnet khusus proxy

Pratinjau — Load Balancer Jaringan proxy lintas region, eksternal regional, dan internal regional mendukung penghentian traffic IPv6

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

Pada diagram sebelumnya, subnet khusus proxy menyediakan serangkaian alamat IP yang digunakan Google untuk menjalankan proxy Envoy atas nama Anda. Anda harus membuat subnet khusus proxy di setiap region jaringan VPC tempat Anda menggunakan Load Balancer Jaringan proxy internal berbasis Envoy.

Tabel berikut menjelaskan persyaratan subnet khusus proxy untuk Load Balancer Jaringan proxy internal:

Mode load balancer	Nilai flag --purpose	Nilai flag --stack-type
Load Balancer Jaringan proxy internal regional	REGIONAL_MANAGED_PROXY Load balancer regional dan lintas region tidak dapat menggunakan subnet yang sama Semua load balancer regional berbasis Envoy di suatu region dan jaringan VPC menggunakan subnet khusus proxy yang sama.	IPV4_IPV6 untuk menghentikan traffic IPv6 atau IPv4 yang masuk IPV4_ONLY untuk menghentikan traffic IPv4 yang masuk
Load Balancer Jaringan proxy internal lintas region	GLOBAL_MANAGED_PROXY Load balancer regional dan lintas region tidak dapat menggunakan subnet yang sama Load balancer berbasis Envoy lintas region harus memiliki subnet khusus proxy di setiap region tempat load balancer dikonfigurasi. Proxy load balancer lintas region di region dan jaringan yang sama menggunakan subnet khusus proxy yang sama.	IPV4_IPV6 untuk menghentikan traffic IPv6 atau IPv4 yang masuk IPV4_ONLY untuk menghentikan traffic IPv4 yang masuk

Selanjutnya:

• Subnet khusus proxy hanya digunakan untuk proxy Envoy, bukan backend Anda.
• Instance virtual machine (VM) backend atau endpoint dari semua Load Balancer Jaringan proxy internal di suatu region dan jaringan VPC menerima koneksi dari subnet khusus proxy.
• Alamat IP Load Balancer Jaringan proxy internal tidak berada di subnet khusus proxy. Alamat IP load balancer ditentukan oleh aturan penerusan terkelola internalnya.

Aturan penerusan dan alamat IP

Pratinjau — Load Balancer Jaringan proxy lintas region, eksternal regional, dan internal regional mendukung penghentian traffic IPv6

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

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 TCP. 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 yang Anda gunakan di Load Balancer Jaringan proxy internal dapat mereferensikan satu port dari 1—65535. Untuk mendukung beberapa port, Anda harus mengonfigurasi beberapa aturan penerusan.

Tabel berikut menunjukkan persyaratan aturan penerusan untuk Load Balancer Jaringan proxy internal:

Mode load balancer	Aturan penerusan, alamat IP, dan subnet khusus proxy --purpose	Perutean dari klien ke frontend load balancer
Load Balancer Jaringan proxy internal regional	Regional forwardingRules Alamat IP regional Skema load balancing: INTERNAL_MANAGED Subnet khusus proxy --purpose: REGIONAL_MANAGED_PROXY Alamat IP --purpose: SHARED_LOADBALANCER_VIP	Anda dapat mengaktifkan akses global untuk mengizinkan klien dari region mana pun mengakses load balancer Anda. Backend juga harus berada di region yang sama dengan load balancer.
Load Balancer Jaringan proxy internal lintas region	Global globalForwardingRules Alamat IP regional Skema load balancing: INTERNAL_MANAGED Subnet khusus proxy --purpose: GLOBAL_MANAGED_PROXY Alamat IP --purpose: SHARED_LOADBALANCER_VIP	Akses global diaktifkan secara default untuk mengizinkan klien dari region mana pun mengakses load balancer Anda. Backend dapat berada di beberapa region.

Aturan penerusan dan jaringan VPC

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

Mode load balancer

Pengaitan jaringan VPC

Load Balancer Jaringan proxy internal regional Load Balancer Jaringan proxy internal lintas region

Bergantung pada apakah Anda menggunakan alamat IPv4 atau rentang alamat IPv6, selalu ada jaringan VPC eksplisit atau implisit yang terkait dengan aturan penerusan. Alamat IPv4 internal regional 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 dibuat. Dengan demikian, ada pengaitan jaringan tersirat. Rentang alamat IPv6 internal regional selalu ada di dalam jaringan VPC. Saat membuat aturan penerusan, Anda harus menentukan subnet tempat rentang alamat IP diambil. Subnet ini harus berada di region dan jaringan VPC yang sama dengan tempat subnet khusus proxy 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 dual-stack (IPv4_IPv6) atau IPV6_ONLY dengan ipv6-access-type ditetapkan ke INTERNAL. Opsi alokasi alamat IPv6. Aturan penerusan juga harus merujuk ke rentang alamat IPv6 /96 dari rentang alamat IPv6 internal /64 subnet. Anda dapat menetapkan rentang /96 ini menggunakan salah satu metode berikut: Menentukan alamat IPv6 internal yang dicadangkan. Menentukan alamat IPv6 sementara kustom. Membiarkan Google Cloud menetapkan alamat IPv6 sementara secara otomatis. Batasan. Untuk menentukan alamat IPv6 sementara kustom, Anda harus menggunakan Google Cloud CLI atau API. Konsol Google Cloud tidak mendukung penentuan alamat IPv6 sementara kustom untuk aturan penerusan.

Proxy target

Load Balancer Jaringan proxy internal menghentikan koneksi TCP dari klien dan membuat koneksi baru ke backend. Secara default, alamat IP klien dan informasi port asli tidak dipertahankan. Anda dapat mempertahankan informasi ini menggunakan protokol PROXY. Proxy target mengarahkan permintaan masuk langsung ke layanan backend load balancer.

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

Mode load balancer	Proxy target	Referensi
Load Balancer Jaringan proxy internal regional	Regional regionTargetTcpProxies	Proxy target mereferensikan satu layanan backend atau satu atau beberapa rute TLS.
Load Balancer Jaringan proxy internal lintas region	Global targetTcpProxies	Proxy target mereferensikan satu layanan backend atau satu atau beberapa rute TLS.

Rute TLS

Pratinjau

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

Resource rute TLS memungkinkan Anda menentukan cara traffic dirutekan ke layanan backend berdasarkan nama host SNI.

Jika proxy TCP target load balancer tidak direferensikan oleh rute TLS, hanya satu layanan backend default yang digunakan, dan nilai nama host SNI yang dikirim oleh klien atau ketiadaannya tidak relevan.

Anda dapat melampirkan konfigurasi rute TLS ke proxy target load balancer menggunakan perintah gcloud network-services tls-routes.

Tabel berikut menunjukkan API rute TLS yang diperlukan oleh Load Balancer Jaringan proxy internal:

Mode load balancer	Rute TLS	Referensi
Load Balancer Jaringan proxy internal regional	Regional tlsRoutes	Setiap rute TLS dapat merujuk ke satu atau beberapa layanan backend.
Load Balancer Jaringan proxy internal lintas region	Global tlsRoutes	Setiap rute TLS dapat merujuk ke satu atau beberapa layanan backend.

Layanan backend

Layanan backend mengarahkan traffic masuk ke satu atau beberapa backend yang terpasang. Backend dapat berupa grup instance atau grup endpoint jaringan. Backend berisi informasi mode load balancing untuk menentukan kepenuhan berdasarkan koneksi (atau, khusus untuk backend grup instance, pemakaian).

Setiap load balancer memiliki setidaknya satu resource layanan backend. Jika menggunakan rute TLS untuk mengonfigurasi perutean, Anda dapat mengonfigurasi beberapa layanan backend untuk load balancer. Tanpa rute TLS, Anda hanya dibatasi pada satu layanan backend per load balancer.

Tabel berikut menentukan API layanan backend untuk Load Balancer Jaringan proxy internal:

Mode load balancer	Jenis layanan backend
Load Balancer Jaringan proxy internal regional	Regional regionBackendServices
Load Balancer Jaringan proxy internal lintas region	Global backendServices

Backend yang didukung

Load Balancer Jaringan proxy internal mendukung jenis backend berikut:

Mode load balancer	Backend yang didukung di layanan backend
	Grup instance	NEG Zona	NEG Internet	NEG Serverless	NEG Hybrid	NEG Private Service Connect	GKE
Load Balancer Jaringan proxy internal regional		Endpoint jenis GCE_VM_IP_PORT	Khusus NEG regional			Menambahkan NEG Private Service Connect
Load Balancer Jaringan proxy internal lintas region		Endpoint jenis GCE_VM_IP_PORT				Menambahkan NEG Private Service Connect

Semua backend harus memiliki jenis yang sama (grup instance atau NEG). Anda dapat menggunakan berbagai jenis backend grup instance secara bersamaan, atau Anda dapat menggunakan berbagai jenis backend NEG secara bersamaan, tetapi Anda tidak dapat menggunakan backend grup instance dan NEG secara bersamaan di layanan backend yang sama.

Anda dapat menggabungkan NEG zona dan NEG hybrid dalam layanan backend yang sama.

Untuk meminimalkan gangguan layanan bagi pengguna, aktifkan pengosongan koneksi pada layanan backend. Gangguan tersebut dapat terjadi saat backend dihentikan, dihapus secara manual, atau dihapus oleh autoscaler. Untuk mempelajari lebih lanjut cara menggunakan pengosongan koneksi untuk meminimalkan gangguan layanan, lihat Mengaktifkan pengosongan koneksi.

Backend dan jaringan VPC

• 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 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, lampiran VLAN Cloud Interconnect, atau framework Network Connectivity Center.

  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 memungkinkan komunikasi antara subnet khusus proxy di jaringan VPC aturan penerusan dan subnet yang digunakan oleh backend instance atau endpoint.

  Persyaratan subnet IPv6 backend

  Pratinjau

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

  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 backend instance 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.

• Jaringan VPC backend dan jaringan VPC aturan penerusan harus berupa spoke VPC yang terpasang ke hub NCC yang sama. Filter impor dan ekspor harus mengizinkan komunikasi antara subnet khusus proxy di jaringan VPC aturan penerusan dan subnet yang digunakan oleh instance backend atau endpoint.

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

Backend dan antarmuka jaringan

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

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

Protokol untuk berkomunikasi dengan backend

Saat mengonfigurasi layanan backend untuk Load Balancer Jaringan proxy internal, Anda menetapkan protokol yang digunakan layanan backend untuk berkomunikasi dengan backend. Load balancer hanya menggunakan protokol yang Anda tentukan, dan tidak mencoba menegosiasikan koneksi dengan protokol lain. Load Balancer Jaringan proxy internal hanya mendukung TCP untuk berkomunikasi dengan backend.

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 tersebut. Health check tidak memeriksa apakah aplikasi itu sendiri berfungsi.

Protokol health check

Meskipun tidak wajib dan tidak selalu memungkinkan, sebaiknya gunakan health check yang protokolnya cocok dengan protokol layanan backend. Misalnya, health check TCP paling akurat menguji konektivitas TCP ke backend. Untuk mengetahui daftar protokol health check yang didukung, lihat bagian Health check di halaman Perbandingan fitur load balancer.

Tabel berikut menentukan cakupan health check yang didukung oleh Load Balancer Jaringan proxy internal dalam setiap mode:

Mode load balancer	Jenis health check
Load Balancer Jaringan proxy internal regional	Regional regionHealthChecks
Load Balancer Jaringan proxy internal lintas region	Global healthChecks

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

• Ringkasan health check
• Menggunakan health check

Aturan firewall

Load Balancer Jaringan proxy internal memerlukan aturan firewall berikut:

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

Port untuk aturan firewall ini harus dikonfigurasi sebagai berikut:

• Izinkan traffic ke port tujuan untuk setiap health check layanan backend.

• Misalnya backend grup instance: Tentukan port yang akan dikonfigurasi oleh pemetaan antara port bernama layanan backend dan nomor port yang terkait dengan port bernama tersebut di setiap grup instance. Nomor port dapat bervariasi di antara grup instance yang ditetapkan ke layanan backend yang sama.

• Untuk backend NEG GCE_VM_IP_PORT, izinkan traffic ke nomor port endpoint.

Ada pengecualian tertentu untuk persyaratan aturan firewall bagi load balancer berikut:

• 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 health check 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 NGFW untuk mengontrol akses klien ke aturan penerusan load balancer berbasis proxy Envoy, seperti Load Balancer Jaringan proxy internal regional dan Load Balancer Jaringan proxy internal lintas region. Cloud NGFW Essentials dan Cloud NGFW Standard mendukung fitur ini.

Untuk mengetahui informasi selengkapnya, lihat 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 Jaringan proxy 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 mengakses load balancer Anda.

Untuk Load Balancer Jaringan proxy internal lintas region, akses global diaktifkan secara default. Klien dari region mana pun dapat mengakses load balancer Anda.

Tabel berikut merangkum akses klien untuk Load Balancer Jaringan proxy internal regional:

Akses global dinonaktifkan	Akses global diaktifkan
Klien harus berada di region yang sama dengan load balancer. VM 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. VM tersebut harus tetap 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.

Arsitektur VPC Bersama

Load Balancer Jaringan proxy internal mendukung jaringan yang menggunakan VPC Bersama. VPC Bersama memungkinkan Anda mempertahankan pemisahan tanggung jawab yang jelas antara administrator jaringan dan developer layanan. Tim pengembangan Anda dapat berfokus pada pembuatan layanan di project layanan, dan tim infrastruktur jaringan dapat menyediakan dan mengelola load balancing. Jika Anda belum memahami VPC Bersama, baca dokumentasi ringkasan VPC Bersama.

Alamat IP	Aturan penerusan	Proxy target	Komponen backend
Alamat IP internal harus ditentukan dalam project yang sama dengan backend. Agar load balancer tersedia di jaringan VPC Bersama, alamat IP internal harus ditentukan dalam project layanan yang sama dengan lokasi VM backend, dan harus mereferensikan subnet di jaringan VPC Bersama yang diinginkan dalam project host. Alamat itu sendiri berasal dari rentang IP utama subnet yang direferensikan.	Aturan penerusan internal harus ditentukan dalam project yang sama dengan backend. Agar load balancer tersedia di jaringan VPC Bersama, aturan penerusan internal harus ditentukan dalam project layanan yang sama dengan tempat VM backend berada, dan harus mereferensikan subnet yang sama (di jaringan VPC Bersama) yang direferensikan oleh alamat IP internal terkait.	Proxy target harus ditentukan dalam project yang sama dengan backend.	Dalam skenario VPC Bersama, VM backend biasanya berada di project layanan. Layanan backend internal regional dan health check harus ditentukan dalam project layanan tersebut.

Distribusi traffic

Load Balancer Jaringan proxy internal mendistribusikan traffic ke backend-nya sebagai berikut:

1. Koneksi yang berasal dari satu klien dikirim ke zona yang sama selama backend yang responsif (grup instance atau NEG) dalam zona tersebut tersedia dan memiliki kapasitas, seperti yang ditentukan oleh mode balancing. Untuk Load Balancer Jaringan proxy internal regional, mode balancing dapat berupa CONNECTION (backend grup instance atau NEG) atau UTILIZATION (khusus backend grup instance).
2. Koneksi dari klien dikirim ke backend yang sama jika Anda telah mengonfigurasi afinitas sesi.
3. Setelah backend dipilih, traffic akan didistribusikan di antara instance (dalam grup instance) atau endpoint (dalam NEG) sesuai dengan kebijakan load balancing. Untuk algoritma kebijakan load balancing yang didukung, lihat setelan localityLbPolicy dalam dokumentasi API layanan backend regional.

Pemilihan rute berbasis SNI dengan rute TLS

Pratinjau

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

Pemilihan rute berbasis SNI memungkinkan Load Balancer Jaringan proxy TCP Anda merutekan traffic ke layanan backend tertentu berdasarkan nama host Server Name Indication (SNI) yang diberikan selama TLS handshake. SNI adalah ekstensi TLS yang memungkinkan klien menentukan nama domain yang ingin dijangkau sebelum tunnel terenkripsi dibuat. Nama host SNI dikirimkan dalam format yang tidak dienkripsi dalam pesan ClientHello sehingga load balancer dapat memeriksa nilai ini dan merutekan traffic ke layanan backend yang sesuai.

Anda dapat menggunakan resource konfigurasi rute TLS untuk memetakan nama host SNI tertentu ke layanan backend. Saat pemilihan rute berbasis SNI dikonfigurasi, load balancer mengaktifkan TLS passthrough, yang meneruskan byte stream terenkripsi langsung ke backend tanpa didekripsi oleh load balancer.

Fitur ini memungkinkan beberapa kasus penggunaan utama seperti:

• Gunakan satu alamat IP anycast global dan port untuk menyajikan beberapa aplikasi, sehingga mengurangi konsumsi alamat IPv4.
• Mendukung deployment terenkripsi end-to-end, yang memungkinkan sertifikat tetap berada di backend, sehingga memastikan traffic tidak pernah tidak terenkripsi saat dalam pengiriman.
• Memungkinkan administrator platform mengelola infrastruktur inti, sementara pemilik layanan mengelola rute dan backend spesifik mereka secara independen.
• Memungkinkan pemilihan rute ke shard tertentu untuk aplikasi non-HTTP stateful (seperti MongoDB) berdasarkan SNI yang disediakan oleh klien.

Cara traffic didistribusikan saat rute TLS digunakan

Jika pemilihan rute berbasis SNI dikonfigurasi, traffic akan dirutekan ke layanan backend sebagai berikut:

1. Load balancer memproses IP dan port yang ditentukan dalam aturan penerusan.
2. Saat klien memulai koneksi TLS, load balancer akan menangkap pesan ClientHello dan mengekstrak nama host SNI.

3. SNI yang diekstrak dibandingkan dengan nama host yang ditentukan dalam rute TLS yang dikonfigurasi. Load balancer menggunakan logika berikut untuk menentukan layanan backend mana yang harus menerima traffic:

   1. Jika klien tidak menggunakan protokol TLS, load balancer akan menutup koneksi.
   2. Jika klien tidak mengirim nama host SNI dalam pesan ClientHello-nya, load balancer akan menutup koneksi.
   3. Jika klien mengirim nama host SNI yang bukan nama DNS yang valid, load balancer akan menutup koneksi.
   4. Jika klien mengirim nama host SNI yang tidak cocok dengan nama host SNI mana pun yang terkait dengan rute TLS, load balancer akan menutup koneksi.

   5. Dalam semua situasi lainnya: Load balancer memilih layanan backend menggunakan proses pencocokan berikut:

      Pencocokan dilakukan berdasarkan akhiran terpanjang (terpanjang dalam hal jumlah subdomain). Untuk mengilustrasikan metode pencocokan, pertimbangkan rute TLS yang SNI-nya adalah *.foo.com, rute TLS lain yang SNI-nya adalah *.bar.foo.com, dan rute TLS ketiga yang SNI-nya adalah baz.bar.foo.com.

      • Jika nama host SNI klien adalah baz.bar.foo.com, load balancer akan memilih layanan backend yang direferensikan oleh rute TLS yang SNI-nya adalah baz.bar.foo.com.
      • Jika nama host SNI klien adalah qux.bar.foo.com, load balancer akan memilih layanan backend yang direferensikan oleh rute TLS yang SNI-nya adalah *.bar.foo.com.
      • Jika nama host SNI klien adalah qux.qux.foo.com, load balancer akan memilih layanan backend yang direferensikan oleh rute TLS yang SNI-nya adalah *.foo.com.

   Setelah kecocokan ditemukan, byte stream terenkripsi akan di-proxy-kan langsung ke layanan backend yang ditetapkan tanpa menghentikan koneksi TLS (untuk passthrough TLS).

Batasan

Batasan berikut berlaku saat Anda menggunakan rute TLS untuk mengonfigurasi pemilihan rute berbasis SNI:

• Proxy TCP target dapat merujuk ke satu layanan backend atau satu atau beberapa rute TLS. Anda tidak dapat mengonfigurasi keduanya.

• Load Balancer Jaringan Proxy tidak dapat mendeteksi penggabungan koneksi HTTP, yang dapat menyebabkan permintaan HTTP salah rute.

  Secara default, browser sudah menggabungkan koneksi HTTP. Misalnya, saat browser membuka koneksi ke www.example.com dan server menampilkan sertifikat untuk *.example.com selama TLS handshake, browser akan menggunakan kembali koneksi ini untuk semua permintaan ke *.example.com, selama nama host di-resolve ke alamat IP yang sama. Hal ini sesuai dengan RFC 7540.

  Dengan pemilihan rute berbasis SNI, setelah koneksi dibuat, koneksi tersebut akan terikat secara permanen ke backend tujuannya. Pertimbangkan deployment tempat *.example.com disajikan oleh satu backend HTTPS dengan sertifikat TLS *.example.com, dan my.example.com disajikan oleh backend HTTPS lain. Jika koneksi ke *.example.com dibuat terlebih dahulu, permintaan HTTP berikutnya ke my.example.com akan digabungkan ke koneksi yang sama, menggunakan backend HTTPS *.example.com.

Afinitas sesi

Afinitas sesi memungkinkan Anda mengonfigurasi layanan backend load balancer untuk mengirim semua permintaan dari klien yang sama ke backend yang sama, selama backend tersebut responsif dan memiliki kapasitas.

Load Balancer Jaringan proxy internal menawarkan jenis afinitas sesi 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, asalkan 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 Google Cloud . Dalam situasi ketika banyak klien menggunakan alamat IP sumber efektif yang sama, beberapa VM backend mungkin menerima lebih banyak koneksi atau permintaan daripada yang lain.

Perhatikan hal-hal berikut saat mengonfigurasi afinitas sesi:

• Jangan mengandalkan afinitas sesi untuk tujuan autentikasi atau keamanan. Afinitas sesi 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.

Kehilangan afinitas sesi

Semua opsi afinitas sesi memerlukan hal berikut:

• Instance atau endpoint backend yang dipilih harus tetap dikonfigurasi sebagai backend. Afinitas sesi dapat terputus jika 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.

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 zona 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 balancing UTILIZATION, Anda harus menggunakan mode balancing RATE atau CONNECTION untuk meminimalkan situasi saat afinitas sesi dapat rusak.

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

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

• Jumlah total endpoint atau backend instance 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:

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

Failover

Jika backend menjadi tidak responsif, traffic akan otomatis dialihkan ke backend yang responsif.

Tabel berikut menjelaskan perilaku failover untuk Load Balancer Jaringan proxy internal:

Mode load balancer	Perilaku failover	Perilaku saat semua backend tidak responsif
Load Balancer Jaringan proxy internal regional	Load balancer menerapkan algoritma failover yang lancar per zona. Daripada menunggu semua backend di suatu zona menjadi tidak responsif, load balancer mulai mengalihkan traffic ke zona lain saat rasio backend responsif terhadap backend tidak responsif di zona mana pun kurang dari nilai minimum persentase tertentu (70%; nilai minimum ini tidak dapat dikonfigurasi). Jika semua backend di semua zona tidak responsif, load balancer akan segera menghentikan koneksi klien. Proxy Envoy mengirimkan traffic ke backend yang responsif di suatu region berdasarkan distribusi traffic yang dikonfigurasi.	Menghentikan koneksi
Load Balancer Jaringan proxy internal lintas region	Failover otomatis ke backend yang responsif di region yang sama atau region lain. Traffic didistribusikan di antara backend yang responsif yang mencakup beberapa region berdasarkan distribusi traffic yang dikonfigurasi.	Menghentikan koneksi

Load balancing untuk aplikasi GKE

Jika Anda membangun aplikasi di Google Kubernetes Engine (GKE), Anda dapat menggunakan NEG zona mandiri untuk melakukan load balancing traffic langsung ke container. Dengan NEG mandiri, Anda bertanggung jawab untuk membuat objek Service yang membuat NEG zona, lalu mengaitkan NEG dengan layanan backend agar load balancer dapat terhubung ke Pod.

Dokumentasi GKE terkait:

• Load balancing berbasis container melalui NEG mandiri

Kuota dan batas

Untuk mengetahui informasi tentang kuota dan batas, lihat Kuota dan batas.

Batasan

• Load Balancer Jaringan proxy internal tidak mendukung deployment VPC Bersama yang frontend load balancer-nya berada di satu project host atau layanan dan layanan backend serta backend-nya berada di project layanan lain (juga dikenal sebagai referensi layanan lintas project).
• Google Cloud tidak memberikan jaminan apa pun terkait masa aktif koneksi TCP saat Anda menggunakan Load Balancer Jaringan proxy internal. Klien harus tahan terhadap koneksi yang terputus, baik karena masalah internet yang lebih luas maupun karena mulai ulang terjadwal secara rutin pada proxy Envoy yang mengelola koneksi.

Langkah berikutnya

• Menyiapkan Load Balancer Aplikasi internal lintas region dengan backend grup instance VM

• Menyiapkan Load Balancer Aplikasi internal lintas region dengan konektivitas hybrid

• Menyiapkan Load Balancer Jaringan proxy internal regional dengan backend grup instance

• Menyiapkan Load Balancer Jaringan proxy internal regional dengan backend NEG zona

• Menyiapkan Load Balancer Jaringan proxy internal regional dengan backend NEG hybrid

• Menyiapkan Load Balancer Jaringan proxy internal regional dengan backend NEG internet

• Melihat metrik dengan Cloud Monitoring