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 untuk menjalankan dan menskalakan traffic layanan TCP di belakang 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 akan menghentikan koneksi TCP antara klien dan load balancer di proxy Envoy. Proxy akan 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 diterapkan sebagai layanan terkelola berdasarkan proxy Envoy open source. Mode regional memastikan bahwa semua klien dan backend berasal dari region yang ditentukan, yang membantu saat Anda membutuhkan kepatuhan regional.
  • Load Balancer Jaringan proxy internal lintas region. Ini adalah load balancer multi-region yang diterapkan sebagai layanan terkelola berdasarkan proxy Envoy open source. Mode lintas region memungkinkan Anda melakukan load balancing terhadap traffic ke layanan backend yang didistribusikan secara global, termasuk pengelolaan traffic yang memastikan traffic diarahkan ke backend terdekat. Load balancer ini juga memungkinkan ketersediaan tinggi. Menempatkan backend di beberapa region akan membantu menghindari kegagalan di satu region. Jika backend satu region tidak aktif, traffic dapat beralih ke region lain.

    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) untuk load balancer. Dialokasikan dari subnet di region Google Cloud tertentu. Dialokasikan dari subnet di region Google Cloud tertentu.

    Alamat VIP dari beberapa region dapat berbagi layanan backend global yang sama.

    Akses klien Tidak dapat diakses secara global secara default.
    Secara opsional, 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

Cloud Console

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

    Buka Load balancing

  2. Di tab Load Balancer, 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 Region
    Load Balancer Jaringan proxy internal regional Jaringan (Proxy) Internal Menentukan wilayah
    Load Balancer Jaringan proxy internal lintas region Jaringan (Proxy) Internal

gcloud

  1. 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

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.
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.
Komponen Load Balancer Jaringan proxy internal lintas region (klik untuk memperbesar).

Subnet khusus proxy

Pada diagram di atas, subnet khusus proxy memberikan sekumpulan 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 perbedaan antara subnet khusus proxy dalam mode regional dan lintas region:

Mode load balancer Nilai tanda --purpose subnet khusus proxy
Load Balancer Jaringan proxy internal regional

REGIONAL_MANAGED_PROXY

Load balancer regional dan lintas region tidak dapat berbagi subnet yang sama

Semua load balancer berbasis Envoy regional di satu region dan jaringan VPC memiliki subnet khusus proxy yang sama.

Load Balancer Jaringan proxy internal lintas region

GLOBAL_MANAGED_PROXY

Load balancer regional dan lintas region tidak dapat berbagi 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 memiliki subnet khusus proxy yang sama.

Lebih lanjut:

  • Subnet khusus proxy hanya digunakan untuk proxy Envoy, bukan backend Anda.
  • Instance atau endpoint virtual machine (VM) backend 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 yang dikelola secara internal.

Aturan penerusan dan alamat IP

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

Klien menggunakan port dan alamat IP 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 {i> load balancer<i} 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. Setiap aturan penerusan yang Anda gunakan dalam Load Balancer Jaringan proxy internal dapat mereferensikan persis satu port TCP. Alamat IP internal yang terkait dengan aturan penerusan dapat berasal dari subnet mana pun di jaringan dan region yang sama.

Tabel berikut menunjukkan perbedaan antara aturan penerusan dalam mode regional dan lintas region:

Mode load balancer Aturan penerusan, alamat IP, dan subnet khusus proxy --purpose Memilih rute dari klien ke frontend load balancer
Load Balancer Jaringan proxy internal regional

forwardingRules Regional

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

globalForwardingRules global

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.


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 menyimpan informasi ini dengan menggunakan protokol PROXY. Proxy target merutekan permintaan masuk secara langsung ke layanan backend load balancer.

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

Proxy target Load Balancer Jaringan proxy internal regional Load Balancer Jaringan proxy internal lintas region
TCP regionTargetTcpProxies Regional targetTcpProxies global

Layanan backend

Layanan backend mengarahkan traffic masuk ke satu atau beberapa backend yang terpasang. Backend bisa berupa grup instance atau grup endpoint jaringan. Backend berisi informasi mode penyeimbangan untuk menentukan kelengkapan berdasarkan koneksi (atau, khusus untuk backend grup instance, penggunaan).

Setiap Load Balancer Jaringan proxy internal memiliki satu resource layanan backend. Tabel berikut menentukan jenis layanan backend yang diperlukan oleh Load Balancer Jaringan proxy internal di setiap mode:

Load Balancer Jaringan proxy internal regional Load Balancer Jaringan proxy internal lintas region
Jenis layanan backend regionBackendServices Regional backendServices global

Backend yang didukung

Layanan backend mendukung jenis backend berikut:

Mode load balancer Backend yang didukung di layanan backend
Grup instance NEGARA ZONA NEG Internet NEG Tanpa Server NEG Hybrid NEG Private Service Connect GKE
Load Balancer Jaringan proxy internal regional Endpoint jenis
GCE_VM_IP_PORT
Khusus NEG regional Tambahkan NEG Private Service Connect
Load Balancer Jaringan proxy internal lintas region Endpoint jenis
GCE_VM_IP_PORT
Tambahkan 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 menggunakan berbagai jenis backend NEG secara bersamaan, tetapi Anda tidak dapat menggunakan grup instance dan backend NEG secara bersamaan pada layanan backend yang sama.

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

Untuk memastikan agar pengguna tidak terganggu, Anda dapat mengaktifkan pengurasan koneksi di layanan backend. Gangguan tersebut dapat terjadi saat backend dihentikan, dihapus secara manual, atau dihapus oleh penskala otomatis. Untuk mempelajari lebih lanjut cara menggunakan pengosongan koneksi guna meminimalkan gangguan layanan, lihat Mengaktifkan pengosongan koneksi.

Protokol untuk berkomunikasi dengan backend

Saat mengonfigurasi layanan backend untuk Load Balancer Jaringan proxy internal, Anda harus menetapkan protokol yang digunakan layanan backend untuk berkomunikasi dengan backend. Load balancer hanya menggunakan protokol yang Anda tentukan, dan tidak berupaya menegosiasikan koneksi dengan protokol lain. Load Balancer Jaringan proxy internal regional atau Load Balancer Jaringan proxy internal lintas region 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. Tindakan 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 diwajibkan dan tidak selalu memungkinkan, praktik terbaiknya adalah menggunakan 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 Fitur load balancing.

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

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

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

Aturan firewall

Load Balancer Jaringan proxy internal memerlukan aturan firewall berikut:

Port untuk aturan firewall ini harus dikonfigurasi sebagai berikut:

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

  • Untuk backend grup instance: Tentukan port yang akan dikonfigurasi dengan 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 pada persyaratan aturan firewall untuk load balancer ini:

  • Mengizinkan rentang pemeriksaan health check Google tidak diperlukan untuk NEG campuran. Namun, jika menggunakan kombinasi NEG campuran dan zona dalam satu layanan backend, Anda harus mengizinkan 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 dan kemudian diterjemahkan NAT (dengan menggunakan Cloud NAT) ke alamat IP NAT yang dialokasikan secara manual atau otomatis. Traffic ini mencakup pemeriksaan health check dan permintaan pengguna dari load balancer ke backend. Untuk mengetahui detailnya, lihat NEG Regional: Gunakan Cloud NAT untuk keluar.

Akses klien

Klien dapat berada di jaringan yang sama atau dalam 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 agar klien dari region mana pun dapat 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 meringkas 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. Komponen tersebut 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. Keduanya 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 saja.

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 dalam project layanan, dan tim infrastruktur jaringan dapat menyediakan serta 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 tempat VM backend berada, dan harus merujuk subnet di jaringan VPC Bersama yang diinginkan dalam project host. Alamat itu sendiri berasal dari rentang IP utama dari subnet yang dirujuk.

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 tempat VM backend berada, dan harus mereferensikan subnet yang sama (di jaringan VPC Bersama) yang dirujuk oleh alamat IP internal terkait.

Proxy target harus ditetapkan dalam project yang sama dengan backend. Dalam skenario VPC Bersama, VM backend biasanya berada di project layanan. Health check dan layanan backend internal regional 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 penyeimbangan. 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 akan 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.

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 responsif dan memiliki kapasitas.

Load Balancer Jaringan proxy internal menawarkan afinitas IP klien, yang meneruskan semua permintaan dari alamat IP klien yang sama ke backend yang sama, selama backend tersebut memiliki kapasitas dan tetap responsif.

Failover

Jika backend tidak responsif, traffic akan otomatis dialihkan ke backend yang responsif. Tabel berikut menjelaskan perilaku failover dalam setiap mode:

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

Load balancer menerapkan algoritma failover yang sederhana per zona. Load balancer tidak harus menunggu semua backend di suatu zona menjadi tidak responsif, melainkan mulai mengalihkan traffic ke zona berbeda ketika rasio backend yang sehat dan tidak responsif di zona mana pun lebih rendah dari batas persentase tertentu (70%; batas 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 mem-build aplikasi di Google Kubernetes Engine, 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 sehingga load balancer dapat terhubung ke Pod.

Dokumentasi GKE terkait:

Kuota dan batas

Untuk mengetahui informasi tentang kuota dan batas, lihat Kuota resource load balancing.

Batasan

  • Load Balancer Jaringan proxy internal tidak mendukung traffic IPv6.
  • Load Balancer Jaringan proxy internal tidak mendukung deployment VPC Bersama, jika frontend load balancer berada dalam satu host atau project layanan, dan layanan backend serta backend berada di project layanan lain (juga dikenal sebagai referensi layanan lintas project).

Langkah selanjutnya