Sebagian atau seluruh informasi di halaman ini mungkin tidak berlaku untuk Trusted Cloud dari S3NS. Lihat Perbedaan dari Google Cloud untuk mengetahui detail selengkapnya.

Halaman ini diterjemahkan oleh Cloud Translation API.

Ringkasan grup endpoint jaringan konektivitas hybrid

Cloud Load Balancing mendukung traffic load balancing ke endpoint yang melampaui batas, seperti pusat data lokal dan cloud publik lainnya yang dapat Anda gunakan konektivitas hybrid untuk menjangkaunya. Trusted Cloud by S3NS

Strategi hybrid adalah solusi pragmatis bagi Anda untuk beradaptasi dengan perubahan permintaan pasar dan memodernisasi aplikasi secara bertahap. Hal ini dapat berupa deployment hybrid sementara untuk memungkinkan migrasi ke solusi berbasis cloud modern atau perlengkapan permanen infrastruktur IT organisasi Anda.

Menyiapkan load balancing hybrid juga memungkinkan Anda memperoleh manfaat dari kemampuan jaringan Cloud Load Balancing untuk layanan yang berjalan di infrastruktur Anda yang ada di luar Trusted Cloud.

Load balancing hybrid didukung di load balancer berikut: Trusted Cloud by S3NS

Layanan lokal dan cloud lainnya diperlakukan seperti backend Cloud Load Balancing lainnya. Perbedaan utamanya adalah Anda menggunakan NEG konektivitas hybrid untuk mengonfigurasi endpoint backend ini. Endpoint harus berupa kombinasi IP:port yang valid dan dapat dijangkau oleh load balancer Anda menggunakan produk konektivitas hybrid seperti Cloud VPN, Cloud Interconnect, atau VM Router appliance.

Kasus penggunaan: Merutekan traffic ke lokasi lokal atau cloud lain

Kasus penggunaan paling sederhana untuk menggunakan NEG hybrid adalah merutekan traffic dari Trusted Cloud load balancer ke lokasi lokal atau ke lingkungan cloud lain. Klien dapat memulai traffic dari internet publik, dari dalam Trusted Cloud, atau dari klien lokal.

Klien publik

Anda dapat menggunakan Load Balancer Aplikasi eksternal dengan backend NEG hibrida untuk merutekan traffic dari klien eksternal ke backend di infrastruktur lokal atau di jaringan cloud lain. Anda juga dapat mengaktifkan kemampuan jaringan bernilai tambah berikut untuk layanan Anda di lokal atau di jaringan cloud lainnya:

Dengan Load Balancer Aplikasi eksternal regional, Anda dapat merutekan traffic eksternal ke endpoint yang berada dalam Trusted Cloud region yang sama dengan resource load balancer. Gunakan load balancer ini jika Anda perlu menayangkan konten dari hanya satu geolokasi (misalnya, untuk mematuhi peraturan kepatuhan) atau jika Anda ingin menggunakan Tingkat Layanan Jaringan Standar.

Cara permintaan dirutekan (apakah ke backend Trusted Cloud atau ke endpoint on-premise/cloud) bergantung pada cara peta URL Anda dikonfigurasi. Bergantung pada peta URL Anda, load balancer memilih layanan backend untuk permintaan tersebut. Jika layanan backend yang dipilih telah dikonfigurasi dengan NEG konektivitas hybrid (hanya digunakan untuk endpoint non-Trusted Cloud ), load balancer meneruskan traffic di seluruh Cloud VPN, Cloud Interconnect, atau VM Router appliance, ke tujuan eksternal yang diinginkan.

Klien internal (dalam Trusted Cloud atau lokal)

Anda juga dapat menyiapkan deployment hybrid untuk klien internal ke Trusted Cloud. Dalam hal ini, traffic klien berasal dari Trusted Cloud jaringan VPC, jaringan lokal, atau dari cloud lain, dan dirutekan ke endpoint lokal atau di jaringan cloud lain.

Load Balancer Aplikasi internal regional adalah load balancer regional, yang berarti bahwa load balancer ini hanya dapat merutekan traffic ke endpoint dalam region Trusted Cloud yang sama dengan resource load balancer.

Diagram berikut menunjukkan deployment hybrid dengan Load Balancer Aplikasi internal regional.

Konektivitas hybrid dengan Load Balancer Aplikasi internal regional. — Konektivitas hybrid dengan Load Balancer Aplikasi internal regional (klik untuk memperbesar).

Kasus penggunaan: Bermigrasi ke Cloud

Memigrasikan layanan yang ada ke cloud memungkinkan Anda membebaskan kapasitas lokal dan mengurangi biaya serta beban pemeliharaan infrastruktur lokal. Anda dapat menyiapkan deployment hybrid untuk sementara yang memungkinkan Anda merutekan traffic ke layanan lokal saat ini dan endpoint layananTrusted Cloud yang sesuai.

Jika menggunakan Load Balancer Aplikasi internal untuk menangani klien internal, Anda dapat mengonfigurasi load balancer untuk menggunakan pembagian traffic berbasis bobot guna membagi traffic di kedua layanan. Trusted Cloud Pembagian traffic memungkinkan Anda memulai dengan mengirim 0% traffic ke layanan Trusted Cloud dan 100% ke layanan di lokasi. Kemudian, Anda dapat secara bertahap meningkatkan proporsi traffic yang dikirim ke layanan Trusted Cloud . Pada akhirnya, Anda mengirim 100% traffic ke layanan Trusted Cloud , dan Anda dapat menghentikan layanan lokal.

Arsitektur hybrid

Bagian ini menjelaskan arsitektur load balancing dan resource yang diperlukan untuk mengonfigurasi deployment load balancing hybrid.

Layanan lokal dan cloud lainnya seperti backend Cloud Load Balancing lainnya. Perbedaan utamanya adalah Anda menggunakan NEG konektivitas hybrid untuk mengonfigurasi endpoint backend ini. Endpoint harus berupa kombinasi IP:port yang valid dan dapat dijangkau klien Anda melalui konektivitas hybrid, seperti Cloud VPN, Cloud Interconnect, atau VM Router appliance.

Diagram berikut menunjukkan Trusted Cloud resource yang diperlukan untuk mengaktifkan load balancing hybrid.

HTTP(S) eksternal regional

Resource Load Balancer Aplikasi eksternal regional untuk konektivitas hybrid. — Resource Load Balancer Aplikasi eksternal regional untuk konektivitas hybrid (klik untuk memperbesar).

HTTP(S) internal regional

Resource Load Balancer Aplikasi internal regional untuk konektivitas hybrid. — Resource Load Balancer Aplikasi internal regional untuk konektivitas hybrid (klik untuk memperbesar).

Proxy internal regional

Perutean Cloud Load Balancing

Perutean Cloud Load Balancing bergantung pada cakupan load balancer yang dikonfigurasi:

Load Balancer Aplikasi internal regional dan Load Balancer Jaringan proxy internal regional. Ini adalah load balancer regional. Artinya, load balancer hanya dapat merutekan traffic ke endpoint dalam region yang sama dengan load balancer. Komponen load balancer harus dikonfigurasi di region yang sama dengan tempat konektivitas hybrid telah dikonfigurasi. Secara default, klien yang mengakses load balancer juga harus berada di region yang sama.

Misalnya, jika gateway Cloud VPN atau lampiran VLAN Cloud Interconnect dikonfigurasi di REGION_A, resource yang diperlukan oleh load balancer (seperti layanan backend, NEG hybrid, atau aturan penerusan) harus dibuat di region REGION_A. Secara default, klien yang mengakses load balancer juga harus berada di region REGION_A.

Persyaratan konektivitas jaringan

Sebelum mengonfigurasi deployment load balancing hybrid, Anda harus menyiapkan resource berikut:

Jaringan VPCTrusted Cloud . Jaringan VPC yang dikonfigurasi di dalam Trusted Cloud. Ini adalah jaringan VPC yang digunakan untuk mengonfigurasi Cloud Interconnect/Cloud VPN dan Cloud Router. Jaringan ini juga merupakan jaringan yang sama tempat Anda akan membuat resource load balancing (aturan penerusan, proxy target, layanan backend, dll.). Alamat IP dan rentang alamat IP subnet di lokal, cloud lain, dan subnet tidak boleh tumpang-tindih. Trusted Cloud Jika alamat IP tumpang-tindih, rute subnet akan diprioritaskan daripada konektivitas jarak jauh.
Konektivitas hybrid. Lingkungan Trusted Cloud dan lokal atau cloud lainnya harus terhubung melalui konektivitas hybrid, menggunakan lampiran VLAN Cloud Interconnect, tunnel Cloud VPN dengan Cloud Router, atau VM Router appliance. Sebaiknya gunakan koneksi dengan ketersediaan tinggi. Cloud Router yang diaktifkan dengan perutean dinamis global mempelajari endpoint tertentu menggunakan BGP dan memprogramnya ke jaringan VPC Trusted Cloud Anda. Perutean dinamis regional tidak didukung. Rute statis juga tidak didukung.

Cloud Interconnect/Cloud VPN/Router appliance harus dikonfigurasi di jaringan VPC yang sama yang ingin Anda gunakan untuk deployment load balancing hybrid. Cloud Router juga harus mengiklankan rute berikut ke lingkungan lokal Anda:
- Rentang yang digunakan oleh probe health check Google: 35.191.0.0/16 dan 130.211.0.0/22.
- Rentang subnet khusus proxy region: untuk load balancer berbasis Envoy—Load Balancer Aplikasi eksternal regional, Load Balancer Aplikasi internal regional, Load Balancer Jaringan proxy eksternal regional, dan Load Balancer Jaringan proxy internal regional.
  
  Subnet khusus proxy wilayah iklan juga diperlukan agar health check Envoy terdistribusi berfungsi. Health check Envoy terdistribusi adalah mekanisme health check default untuk NEG konektivitas hibrida zonal (yaitu, endpoint NON_GCP_PRIVATE_IP_PORT) di belakang load balancer berbasis Envoy.
Anda dapat menggunakan jaringan yang sama atau jaringan VPC yang berbeda dalam project yang sama untuk mengonfigurasi jaringan hybrid (Cloud Interconnect atau Cloud VPN) dan load balancer. Perhatikan hal berikut:
- Jika Anda menggunakan jaringan VPC yang berbeda, kedua jaringan harus dihubungkan menggunakan Peering Jaringan VPC atau harus berupa spoke VPC di hub Network Connectivity Center yang sama.
- Jika Anda menggunakan jaringan VPC yang sama, pastikan rentang CIDR subnet jaringan VPC Anda tidak berkonflik dengan rentang CIDR jarak jauh Anda. Jika alamat IP tumpang-tindih, rute subnet diprioritaskan daripada konektivitas jarak jauh.
Endpoint jaringan (IP:Port) di lokal atau di cloud lain. Satu atau beberapa endpoint jaringan IP:Port yang dikonfigurasi dalam lingkungan lokal atau cloud lainnya, yang dapat dirutekan menggunakan Cloud Interconnect, Cloud VPN, atau VM Router appliance. Jika ada beberapa jalur ke endpoint IP, perutean akan mengikuti perilaku yang dijelaskan dalam ringkasan rute VPC dan ringkasan Cloud Router.
Aturan firewall di lokal atau cloud lainnya. Aturan firewall berikut harus dibuat di lingkungan lokal atau cloud lainnya:
- Ingress mengizinkan aturan firewall untuk mengizinkan traffic dari pemeriksaan health check Google ke endpoint Anda. Rentang yang akan diizinkan adalah: 35.191.0.0/16 dan 130.211.0.0/22. Perhatikan bahwa rentang ini juga harus diiklankan oleh Cloud Router ke jaringan lokal Anda. Untuk mengetahui detail selengkapnya, lihat Aturan firewall dan rentang IP pemeriksaan.
- Aturan firewall izinkan masuk untuk mengizinkan traffic yang di-load balance untuk menjangkau endpoint.
- Untuk load balancer berbasis Envoy—Load Balancer Aplikasi eksternal regional, Load Balancer Aplikasi internal regional, Load Balancer Jaringan proxy eksternal regional, dan Load Balancer Jaringan proxy internal regional, Anda juga perlu membuat aturan firewall untuk mengizinkan traffic dari subnet khusus proxy region tersebut untuk menjangkau endpoint yang berada di lokal atau di lingkungan cloud lain.

Komponen load balancer

Load balancer hybrid memerlukan konfigurasi khusus hanya untuk layanan backend. Konfigurasi frontend sama dengan load balancer lainnya. Load balancer berbasis Envoy—Load Balancer Aplikasi eksternal regional, Load Balancer Aplikasi internal regional, Load Balancer Jaringan proxy eksternal regional, dan Load Balancer Jaringan proxy internal regional—memerlukan subnet khusus proxy tambahan untuk menjalankan proxy Envoy atas nama Anda.

Konfigurasi frontend

Tidak diperlukan konfigurasi frontend khusus untuk load balancing hybrid. Aturan penerusan digunakan untuk merutekan traffic menurut alamat IP, port, dan protokol ke proxy target. Kemudian, target proxy menghentikan koneksi dari klien.

Peta URL digunakan oleh load balancer HTTP(S) untuk menyiapkan perutean permintaan berbasis URL ke layanan backend yang sesuai.

Untuk mengetahui detail selengkapnya tentang setiap komponen ini, lihat bagian arsitektur di ringkasan load balancer tertentu:

Layanan backend

Layanan backend memberikan informasi konfigurasi ke load balancer. Load balancer menggunakan informasi dalam layanan backend untuk mengarahkan traffic masuk ke satu atau beberapa backend yang terpasang.

Untuk menyiapkan deployment load balancing hybrid, Anda mengonfigurasi load balancer dengan backend yang berada di dalam Trusted Clouddan di luar Trusted Cloud.

Backend non-Trusted Cloud (lokal atau cloud lain)

Tujuan apa pun yang dapat Anda jangkau menggunakan produk konektivitas hybrid Google (baik Cloud VPN maupun Cloud Interconnect atau VM Router appliance), dan yang dapat dijangkau dengan kombinasi IP:Port yang valid, dapat dikonfigurasi sebagai endpoint untuk load balancer.

Konfigurasi backend non-Trusted Cloud Anda sebagai berikut:
1. Tambahkan setiap kombinasi IP:Portendpoint jaringan non-Trusted Cloud ke grup endpoint jaringan (NEG) konektivitas hibrida. Pastikan alamat IP dan port ini dapat dijangkau dari Trusted Cloud dengan menggunakan konektivitas hybrid (baik dengan Cloud VPN atau Cloud Interconnect atau VM Router appliance). Untuk NEG konektivitas hybrid, Anda menetapkan network endpoint type ke NON_GCP_PRIVATE_IP_PORT.
2. Saat membuat NEG, tentukan Trusted Cloud zona yang meminimalkan jarak geografis antara Trusted Cloud dan lingkungan cloud lokal atau cloud lainnya. Misalnya, jika Anda menghosting layanan di lingkungan lokal di Frankfurt, Jerman, Anda dapat menentukan zona europe-west3-a Trusted Cloud saat membuat NEG.
3. Tambahkan NEG konektivitas hybrid ini sebagai backend untuk layanan backend.
  
  NEG dengan konektivitas hybrid hanya boleh menyertakan endpoint non-Trusted Cloud. Traffic dapat dihentikan jika NEG hibrida menyertakan endpoint untuk resource dalam jaringan VPC Trusted Cloud , seperti alamat IP aturan penerusan untuk Network Load Balancer passthrough internal. Konfigurasi endpoint Trusted Cloud seperti yang diarahkan di bagian berikutnya.
Trusted Cloud backend

Konfigurasi endpoint Trusted Cloud Anda sebagai berikut:
1. Buat layanan backend terpisah untuk Trusted Cloud backend.
2. Konfigurasi beberapa backend (baik GCE_VM_IP_PORTNEG zona atau grup instance) dalam region yang sama tempat Anda telah menyiapkan konektivitas hybrid.

Poin tambahan yang perlu dipertimbangkan:

Setiap NEG dengan konektivitas hybrid hanya dapat berisi endpoint jaringan dengan jenis yang sama (NON_GCP_PRIVATE_IP_PORT).
Anda dapat menggunakan satu layanan backend untuk mereferensikan backend berbasisTrusted Cloud(menggunakan NEG zonal dengan endpoint GCE_VM_IP_PORT) dan backend lokal atau cloud lainnya (menggunakan NEG konektivitas hibrida dengan endpoint NON_GCP_PRIVATE_IP_PORT). Kombinasi jenis backend campuran lainnya tidak diizinkan.

Catatan: Untuk deployment GKE, backend NEG campuran hanya didukung dengan NEG mandiri.

Skema load balancing layanan backend adalah INTERNAL_MANAGED untuk Load Balancer Aplikasi internal regional dan Load Balancer Jaringan proxy internal regional.

Protokol layanan backend harus berupa HTTP, HTTPS, atau HTTP2 untuk Load Balancer Aplikasi, dan TCP atau SSL untuk Load Balancer Jaringan proxy. Untuk daftar protokol layanan backend yang didukung oleh setiap load balancer, lihat Protokol dari load balancer ke backend.
Mode load balancing untuk backend NEG hybrid harus RATE untuk Load Balancer Aplikasi, dan CONNECTION untuk Load Balancer Jaringan proxy. Untuk mengetahui detail tentang mode penyeimbangan, lihat Ringkasan layanan backend.
Untuk menambahkan lebih banyak endpoint jaringan, perbarui backend yang terlampir ke layanan backend Anda.
Jika Anda menggunakan pemeriksaan kesehatan Envoy terdistribusi dengan backend NEG konektivitas hibrida (hanya didukung untuk load balancer berbasis Envoy), pastikan Anda mengonfigurasi endpoint jaringan unik untuk semua NEG yang terpasang ke layanan backend yang sama. Menambahkan endpoint jaringan yang sama ke beberapa NEG akan menghasilkan perilaku yang tidak ditentukan.

Health check Envoy terdistribusi

Konfigurasi health check Anda bervariasi, bergantung pada jenis load balancer:

Load Balancer Aplikasi eksternal regional, Load Balancer Aplikasi internal regional, Load Balancer Jaringan proxy eksternal regional, Load Balancer Jaringan proxy internal regional . Load balancer ini menggunakan health check Envoy terdistribusi untuk memeriksa kondisi NEG hibrida. Pemeriksaan health check berasal dari software proxy Envoy itu sendiri. Setiap layanan backend harus dikaitkan dengan health check yang memeriksa responsivitas backend. Pemeriksaan health check berasal dari proxy Envoy di subnet khusus proxy di region. Agar pemeriksaan health check berfungsi dengan benar, Anda harus membuat aturan firewall di lingkungan eksternal yang mengizinkan traffic dari subnet khusus proxy untuk menjangkau backend eksternal Anda.

Untuk endpoint NON_GCP_PRIVATE_IP_PORT di luar Trusted Cloud, Anda harus membuat aturan firewall ini di jaringan lokal dan cloud lainnya. Hubungi administrator jaringan Anda untuk mendapatkan bantuan terkait hal ini. Cloud Router yang Anda gunakan untuk konektivitas hybrid juga harus mengiklankan rentang subnet khusus proxy di region tersebut.

Health check Envoy terdistribusi dibuat dengan menggunakan proses Trusted Cloud konsol, gcloud CLI, dan API yang sama seperti health check terpusat. Tidak diperlukan konfigurasi lain.

Poin yang perlu diperhatikan:

Health check gRPC tidak didukung.
Pemeriksaan kesehatan dengan protokol PROXY v1 yang diaktifkan tidak didukung.
Jika Anda menggunakan NEG campuran di mana satu layanan backend memiliki kombinasi NEG zonal (endpoint GCE_VM_IP_PORT dalam Trusted Cloud) dan NEG hybrid (endpoint NON_GCP_PRIVATE_IP_PORT di luar Trusted Cloud), Anda perlu menyiapkan aturan firewall untuk mengizinkan traffic dari rentang IP pemeriksaan kondisi Google (130.211.0.0/22 dan 35.191.0.0/16) ke endpoint NEG zonal di Trusted Cloud. Hal ini karena NEG zonal menggunakan sistem pemeriksaan kondisi terpusat Google.
Karena bidang data Envoy menangani pemeriksaan kondisi, Anda tidak dapat menggunakan konsolTrusted Cloud , API, atau gcloud CLI untuk memeriksa status kondisi endpoint eksternal ini. Untuk NEG hybrid dengan load balancer berbasis Envoy, Trusted Cloud konsol menampilkan status health check sebagai N/A. Hal ini sudah diperkirakan.
Setiap proxy Envoy yang ditetapkan ke subnet khusus proxy di region dalam jaringan VPC memulai health check secara independen. Oleh karena itu, Anda mungkin melihat peningkatan traffic jaringan karena pemeriksaan kondisi. Peningkatan ini bergantung pada jumlah proxy Envoy yang ditetapkan ke jaringan VPC Anda di suatu region, jumlah traffic yang diterima oleh proxy ini, dan jumlah endpoint yang perlu diperiksa kondisinya oleh setiap proxy Envoy. Dalam skenario terburuk, traffic jaringan karena pemeriksaan health check meningkat pada tingkat kuadratik (O(n^2)).
Log health check untuk health check Envoy terdistribusi tidak menyertakan status kesehatan yang mendetail. Untuk mengetahui detail tentang apa yang dicatat, lihat Logging health check. Untuk memecahkan masalah konektivitas lebih lanjut dari proxy Envoy ke endpoint NEG Anda, Anda juga harus memeriksa log load balancer masing-masing.

Dokumentasi terkait:

Batasan

Cloud Router yang digunakan untuk konektivitas hybrid harus diaktifkan dengan perutean dinamis global. Perutean dinamis regional dan rute statis tidak didukung.
Untuk load balancer regional berbasis Envoy—Load Balancer Aplikasi eksternal regional, Load Balancer Jaringan proxy eksternal regional, Load Balancer Jaringan proxy internal regional, dan Load Balancer Aplikasi internal regional—konektivitas hybrid harus dikonfigurasi di region yang sama dengan load balancer. Jika dikonfigurasi di wilayah yang berbeda, Anda mungkin melihat backend sebagai berfungsi dengan baik, tetapi permintaan klien tidak akan diteruskan ke backend.
Pertimbangan untuk koneksi terenkripsi dari load balancer ke backend yang didokumentasikan di sini juga berlaku untuk endpoint backend non-Trusted Cloud yang dikonfigurasi di NEG konektivitas hybrid.

Pastikan Anda juga meninjau setelan keamanan pada konfigurasi konektivitas hybrid Anda. Koneksi VPN dengan ketersediaan tinggi (HA) dienkripsi secara default (IPsec). Koneksi Cloud Interconnect tidak dienkripsi secara default. Untuk mengetahui detail selengkapnya, lihat laporan resmi Enkripsi dalam transit.

Logging

Permintaan yang di-proxy ke endpoint di NEG hybrid dicatat ke Cloud Logging dengan cara yang sama seperti permintaan untuk backend lainnya.

Untuk informasi selengkapnya, lihat:

Kuota

Anda dapat mengonfigurasi NEG hybrid dengan endpoint jaringan sebanyak yang diizinkan oleh kuota grup endpoint jaringan yang ada. Untuk mengetahui informasi selengkapnya, lihat Backend NEG dan Endpoint per NEG.