Ringkasan Load Balancer Jaringan passthrough eksternal berbasis layanan backend

Load Balancer Jaringan passthrough eksternal adalah load balancer Lapisan 4 regional yang mendistribusikan traffic eksternal di antara backend (grup instance atau grup endpoint jaringan (NEG)) di region yang sama dengan load balancer. Backend ini harus berada di region dan project yang sama, tetapi dapat berada di jaringan VPC yang berbeda. Load balancer ini dibangun di atas Maglev dan stack virtualisasi jaringan Andromeda.

Load Balancer Jaringan passthrough eksternal dapat menerima traffic dari:

• Klien mana pun di internet
• Google Cloud VM dengan IP eksternal
• Google Cloud VM yang memiliki akses internet melalui Cloud NAT atau NAT berbasis instance

Load Balancer Jaringan passthrough eksternal bukan proxy. Load balancer itu sendiri tidak menghentikan koneksi pengguna. Paket yang di-load balanced dikirim ke VM backend dengan alamat IP sumber dan tujuan, protokol, dan, jika berlaku, port yang tidak berubah. Kemudian, VM backend akan menghentikan koneksi pengguna. Respons dari VM backend langsung menuju klien, bukan kembali melalui load balancer. Proses ini dikenal sebagai direct server return (DSR).

Load Balancer Jaringan passthrough eksternal berbasis layanan backend mendukung fitur berikut:

• Backend grup instance terkelola dan tidak terkelola. Load Balancer Jaringan passthrough eksternal berbasis layanan backend mendukung grup instance terkelola dan tidak terkelola sebagai backend. Grup instance terkelola mengotomatiskan aspek tertentu dari pengelolaan backend dan memberikan skalabilitas dan keandalan yang lebih baik dibandingkan dengan grup instance tidak terkelola.
• Backend NEG zona. Load Balancer Jaringan passthrough eksternal berbasis layanan backend mendukung penggunaan NEG zona dengan endpoint GCE_VM_IP. Endpoint GCE_VM_IP NEG zona memungkinkan Anda melakukan hal berikut:
  • Meneruskan paket ke antarmuka jaringan mana pun, bukan hanya nic0.
  • Tempatkan endpoint GCE_VM_IP yang sama di dua NEG zona atau lebih yang terhubung ke layanan backend yang berbeda.
• Dukungan untuk beberapa protokol. Load Balancer Jaringan passthrough eksternal berbasis layanan backend dapat menyeimbangkan beban traffic TCP, UDP, ESP, GRE, ICMP, dan ICMPv6.
• Dukungan untuk konektivitas IPv6. Load Balancer Jaringan passthrough eksternal berbasis layanan backend dapat menangani traffic IPv4 dan IPv6.
• Kontrol distribusi traffic terperinci. Layanan backend memungkinkan traffic didistribusikan sesuai dengan afinitas sesi yang dikonfigurasi, kebijakan pelacakan koneksi, dan setelan load balancing berbobot. Layanan backend juga dapat dikonfigurasi untuk mengaktifkan penghentian koneksi dan menetapkan backend failover untuk load balancer. Sebagian besar setelan ini memiliki nilai default yang memungkinkan Anda memulai dengan cepat. Untuk mengetahui informasi selengkapnya, lihat Distribusi traffic untuk Load Balancer Jaringan passthrough eksternal.
• Dukungan untuk health check non-legacy. Load Balancer Jaringan passthrough eksternal berbasis layanan backend memungkinkan Anda menggunakan health check yang cocok dengan jenis traffic (TCP, SSL, HTTP, HTTPS, atau HTTP/2) yang didistribusikannya.
• Integrasi Google Cloud Armor. Google Cloud Armor mendukung perlindungan DDoS jaringan tingkat lanjut untuk Load Balancer Jaringan passthrough eksternal. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi perlindungan DDoS jaringan lanjutan.

• Integrasi GKE. Jika Anda membangun aplikasi di GKE, sebaiknya gunakan pengontrol Layanan GKE bawaan, yang men-deployGoogle Cloud load balancer atas nama pengguna GKE. Arsitektur ini sama dengan arsitektur load balancing mandiri yang dijelaskan di halaman ini, kecuali siklus prosesnya sepenuhnya otomatis dan dikontrol oleh GKE.

  Dokumentasi GKE terkait:

  • Konsep Service LoadBalancer
  • Mengekspos aplikasi menggunakan Service

Arsitektur

Diagram berikut mengilustrasikan komponen Load Balancer Jaringan passthrough eksternal:

Load balancer terdiri dari beberapa komponen konfigurasi. Satu load balancer dapat memiliki hal berikut:

• Satu atau beberapa alamat IP eksternal regional
• Satu atau beberapa aturan penerusan eksternal regional
• Satu layanan backend eksternal regional
• Satu atau beberapa backend: semua grup instance atau semua backend NEG zona (endpoint GCE_VM_IP)
• Health check yang terkait dengan layanan backend

Selain itu, Anda harus membuat aturan firewall yang mengizinkan traffic load balancing dan pemeriksaan health check menjangkau VM backend.

Alamat IP

Load Balancer Jaringan passthrough eksternal memerlukan minimal satu aturan penerusan. Aturan penerusan mereferensikan alamat IP eksternal regional yang dapat diakses di mana saja di internet.

• Untuk traffic IPv4, aturan penerusan mereferensikan satu alamat IPv4 eksternal regional. Alamat IPv4 eksternal regional berasal dari kumpulan yang unik untuk setiap Google Cloud region. Alamat IP dapat berupa alamat statis yang dicadangkan atau alamat sementara.

• Untuk traffic IPv6, aturan penerusan mereferensikan rentang alamat IPv6 /96 dari subnet dual-stack atau khusus IPv6 (Pratinjau). Subnet harus memiliki rentang subnet IPv6 eksternal yang ditetapkan di jaringan VPC. Alamat IPv6 eksternal hanya tersedia di Paket Premium.

  Untuk mengetahui detail selengkapnya tentang dukungan IPv6, lihat dokumentasi VPC tentang rentang subnet IPv6 dan alamat IPv6.

Gunakan alamat IP yang dicadangkan untuk aturan penerusan jika Anda perlu mempertahankan alamat yang terkait dengan project Anda untuk digunakan kembali setelah Anda menghapus aturan penerusan atau jika Anda memerlukan beberapa aturan penerusan untuk mereferensikan alamat IP yang sama.

Load Balancer Jaringan passthrough eksternal mendukung Paket Standar dan Paket Premium untuk alamat IPv4 eksternal regional. Alamat IP dan aturan penerusan harus menggunakan tingkat jaringan yang sama. Alamat IPv6 eksternal regional hanya tersedia di Paket Premium.

Aturan penerusan

Aturan penerusan eksternal regional menentukan protokol dan port yang digunakan load balancer untuk menerima traffic. Karena Load Balancer Jaringan passthrough eksternal bukan proxy, Load Balancer ini meneruskan traffic ke backend pada protokol dan port yang sama, jika paket membawa informasi port. Aturan penerusan yang dikombinasikan dengan alamat IP membentuk frontend load balancer.

Load balancer mempertahankan alamat IP sumber paket masuk. Alamat IP tujuan untuk paket masuk adalah alamat IP yang terkait dengan aturan penerusan load balancer.

Traffic masuk dicocokkan dengan aturan penerusan, yang merupakan kombinasi dari alamat IP tertentu (baik alamat IPv4 maupun rentang alamat IPv6), protokol, dan jika protokol berbasis port, salah satu port, rentang port, atau semua port. Aturan penerusan kemudian mengarahkan traffic ke layanan backend load balancer.

• Jika aturan penerusan mereferensikan alamat IPv4, aturan penerusan tidak dikaitkan dengan subnet apa pun. Artinya, alamat IP-nya berasal dari luar rentang subnetGoogle Cloud .

• Jika aturan penerusan mereferensikan rentang alamat IPv6 /96, aturan penerusan harus dikaitkan dengan subnet, dan subnet tersebut harus (a) dual-stack dan (b) memiliki rentang subnet IPv6 eksternal (--ipv6-access-type ditetapkan ke EXTERNAL). Subnet yang direferensikan oleh aturan penerusan dapat berupa subnet yang sama dengan yang digunakan oleh instance backend; namun, instance backend dapat menggunakan subnet terpisah jika dipilih. Saat instance backend menggunakan subnet terpisah, hal berikut harus benar:

Load Balancer Jaringan passthrough eksternal memerlukan minimal satu aturan penerusan. Aturan penerusan dapat dikonfigurasi untuk mengarahkan traffic yang berasal dari rentang alamat IP sumber tertentu ke layanan backend (atau instance target) tertentu. Untuk mengetahui detailnya, lihat pengalihan traffic. Anda dapat menentukan beberapa aturan penerusan untuk load balancer yang sama seperti yang dijelaskan dalam Beberapa aturan penerusan.

Jika Anda ingin load balancer menangani traffic IPv4 dan IPv6, buat dua aturan penerusan: satu aturan untuk traffic IPv4 yang mengarah ke backend IPv4 (atau dual-stack), dan satu aturan untuk traffic IPv6 yang hanya mengarah ke backend dual-stack. Anda dapat membuat aturan penerusan IPv4 dan IPv6 yang merujuk ke layanan backend yang sama, tetapi layanan backend harus merujuk ke backend stack ganda.

Protokol aturan penerusan

Load Balancer Jaringan passthrough eksternal mendukung opsi protokol berikut untuk setiap aturan penerusan: TCP, UDP, dan L3_DEFAULT.

Gunakan opsi TCP dan UDP untuk mengonfigurasi load balancing TCP atau UDP. Opsi protokol L3_DEFAULT memungkinkan Network Load Balancer passthrough eksternal untuk menyeimbangkan beban traffic TCP, UDP, ESP, GRE, ICMP, dan ICMPv6.

Selain mendukung protokol selain TCP dan UDP, L3_DEFAULT memungkinkan satu aturan penerusan melayani beberapa protokol. Misalnya, layanan IPsec biasanya menangani beberapa kombinasi traffic IKE dan NAT-T berbasis UDP dan ESP. Opsi L3_DEFAULT memungkinkan satu aturan penerusan dikonfigurasi untuk memproses semua protokol tersebut.

Aturan penerusan yang menggunakan protokol TCP atau UDP dapat mereferensikan layanan backend menggunakan protokol yang sama dengan aturan penerusan atau layanan backend yang protokolnya adalah UNSPECIFIED. Aturan penerusan L3_DEFAULT hanya dapat mereferensikan layanan backend dengan protokol UNSPECIFIED.

Jika menggunakan protokol L3_DEFAULT, Anda harus mengonfigurasi aturan penerusan untuk menerima traffic di semua port. Untuk mengonfigurasi semua port, tetapkan --ports=ALL menggunakan Google Cloud CLI, atau tetapkan allPorts ke True menggunakan API.

Tabel berikut merangkum cara menggunakan setelan ini untuk berbagai protokol.

Traffic yang akan di-load balancing	Protokol aturan penerusan	Protokol layanan backend
TCP	TCP	TCP atau UNSPECIFIED
	L3_DEFAULT	UNSPECIFIED
UDP	UDP	UDP atau UNSPECIFIED
	L3_DEFAULT	UNSPECIFIED
ESP, GRE, ICMP/ICMPv6 (hanya permintaan echo)	L3_DEFAULT	UNSPECIFIED

Beberapa aturan penerusan

Anda dapat mengonfigurasi beberapa aturan penerusan eksternal regional untuk Load Balancer Jaringan passthrough eksternal yang sama. Setiap aturan penerusan dapat memiliki alamat IP eksternal regional yang berbeda, atau beberapa aturan penerusan dapat memiliki alamat IP eksternal regional yang sama.

Mengonfigurasi beberapa aturan penerusan eksternal regional dapat berguna untuk kasus penggunaan berikut:

• Anda perlu mengonfigurasi lebih dari satu alamat IP eksternal untuk layanan backend yang sama.
• Anda harus mengonfigurasi protokol yang berbeda atau port atau rentang port yang tidak tumpang-tindih untuk alamat IP eksternal yang sama.
• Anda perlu mengarahkan traffic dari alamat IP sumber tertentu ke backend load balancer tertentu.

Google Cloud mensyaratkan bahwa paket masuk cocok dengan tidak lebih dari satu aturan penerusan. Kecuali untuk aturan penerusan pengarah, yang dibahas di bagian berikutnya, dua aturan penerusan atau lebih yang menggunakan alamat IP eksternal regional yang sama harus memiliki kombinasi protokol dan port yang unik sesuai dengan batasan berikut:

• Aturan penerusan yang dikonfigurasi untuk semua port protokol mencegah pembuatan aturan penerusan lain yang menggunakan protokol dan alamat IP yang sama. Aturan penerusan yang menggunakan protokol TCP atau UDP dapat dikonfigurasi untuk menggunakan semua port, atau dapat dikonfigurasi untuk port tertentu. Misalnya, jika Anda membuat aturan penerusan menggunakan alamat IP 198.51.100.1, protokol TCP, dan semua port, Anda tidak dapat membuat aturan penerusan lain menggunakan alamat IP 198.51.100.1 dan protokol TCP. Anda dapat membuat dua aturan penerusan, yang keduanya menggunakan alamat IP 198.51.100.1 dan protokol TCP, jika masing-masing memiliki port unik atau rentang port yang tidak tumpang-tindih. Misalnya, Anda dapat membuat dua aturan penerusan menggunakan alamat IP 198.51.100.1 dan protokol TCP, dengan satu aturan penerusan menggunakan port 80,443 dan aturan lainnya menggunakan rentang port 81-442.
• Hanya satu aturan penerusan L3_DEFAULT yang dapat dibuat per alamat IP. Hal ini karena protokol L3_DEFAULT menggunakan semua port berdasarkan definisi. Dalam konteks ini, istilah semua port mencakup protokol tanpa informasi port.

• Satu aturan penerusan L3_DEFAULT dapat berjalan bersama dengan aturan penerusan lainnya yang menggunakan protokol tertentu (TCP atau UDP). Aturan penerusan L3_DEFAULT dapat digunakan sebagai upaya terakhir jika ada aturan penerusan yang menggunakan alamat IP yang sama, tetapi protokol yang lebih spesifik. Aturan penerusan L3_DEFAULT memproses paket yang dikirim ke alamat IP tujuannya jika dan hanya jika alamat IP tujuan, protokol, dan port tujuan paket tidak cocok dengan aturan penerusan khusus protokol.
  

  Untuk mengilustrasikannya, pertimbangkan dua skenario berikut. Aturan penerusan dalam kedua skenario menggunakan alamat IP 198.51.100.1 yang sama.

  • Skenario 1. Aturan penerusan pertama menggunakan protokol L3_DEFAULT. Aturan penerusan kedua menggunakan protokol TCP dan semua port. Paket TCP yang dikirim ke port tujuan 198.51.100.1 diproses oleh aturan penerusan kedua. Paket yang menggunakan protokol yang berbeda diproses oleh aturan penerusan pertama.
  • Skenario 2. Aturan penerusan pertama menggunakan protokol L3_DEFAULT. Aturan penerusan kedua menggunakan protokol TCP dan port 8080. Paket TCP yang dikirim ke 198.51.100.1:8080 diproses oleh aturan penerusan kedua. Semua paket lainnya, termasuk paket TCP yang dikirim ke port tujuan berbeda, diproses oleh aturan penerusan pertama.

Pemilihan aturan penerusan

Google Cloud memilih satu atau nol aturan penerusan untuk memproses paket masuk menggunakan proses eliminasi ini, dimulai dengan kumpulan kandidat aturan penerusan yang cocok dengan alamat IP tujuan paket:

• Hapus aturan penerusan yang protokolnya tidak cocok dengan protokol paket, kecuali aturan penerusan L3_DEFAULT. Aturan penerusan yang menggunakan protokol L3_DEFAULT tidak pernah dihilangkan oleh langkah ini karena L3_DEFAULT cocok dengan semua protokol. Misalnya, jika protokol paket adalah TCP, hanya aturan penerusan yang menggunakan protokol UDP yang akan dihapus.

• Hapus aturan penerusan yang portnya tidak cocok dengan port paket. Aturan penerusan yang dikonfigurasi untuk semua port tidak pernah dihilangkan oleh langkah ini karena aturan penerusan semua port cocok dengan port apa pun.

• Jika kandidat aturan penerusan yang tersisa mencakup aturan penerusan khusus protokol L3_DEFAULT dan protokol, hapus aturan penerusan L3_DEFAULT. Jika kandidat aturan penerusan yang tersisa semuanya adalah aturan penerusan L3_DEFAULT, tidak ada yang dihilangkan pada langkah ini.

• Pada tahap ini, kandidat aturan penerusan yang tersisa termasuk dalam salah satu kategori berikut:

  • Satu aturan penerusan tetap ada yang cocok dengan alamat IP tujuan, protokol, dan port paket, serta digunakan untuk merutekan paket.
  • Dua atau lebih kandidat aturan penerusan tetap ada yang cocok dengan alamat IP tujuan, protokol, dan port paket. Artinya, kandidat aturan penerusan yang tersisa mencakup aturan penerusan pengarahan (dibahas di bagian berikutnya). Pilih aturan penerusan kemudi yang rentang sumbernya mencakup CIDR paling spesifik (kecocokan awalan terpanjang) yang berisi alamat IP sumber paket. Jika tidak ada aturan penerusan kemudi yang memiliki rentang sumber yang mencakup alamat IP sumber paket, pilih aturan penerusan induk.
  • Tidak ada lagi kandidat aturan penerusan dan paket akan dihapus.

Saat menggunakan beberapa aturan penerusan, pastikan Anda mengonfigurasi software yang berjalan di VM backend sehingga software tersebut terikat ke semua alamat IP eksternal dari aturan penerusan load balancer.

Pengarahan traffic

Aturan penerusan untuk Load Balancer Jaringan passthrough eksternal dapat dikonfigurasi untuk mengarahkan traffic yang berasal dari alamat IP sumber tertentu atau rentang alamat IP ke layanan backend (atau instance target) tertentu.

Pengalihan traffic berguna untuk pemecahan masalah dan konfigurasi lanjutan. Dengan pengarahan traffic, Anda dapat mengarahkan klien tertentu ke serangkaian backend yang berbeda, konfigurasi layanan backend yang berbeda, atau keduanya. Contoh:

• Pengarahan traffic memungkinkan Anda membuat dua aturan penerusan yang mengarahkan traffic ke backend yang sama (grup instance atau NEG) melalui dua layanan backend. Kedua layanan backend dapat dikonfigurasi dengan health check yang berbeda, afinitas sesi yang berbeda, atau kebijakan kontrol distribusi traffic yang berbeda (pelacakan koneksi, pengosongan koneksi, dan failover).
• Pengarahan traffic memungkinkan Anda membuat aturan penerusan untuk mengalihkan traffic dari layanan backend bandwidth rendah ke layanan backend bandwidth tinggi. Kedua layanan backend berisi set VM atau endpoint backend yang sama, tetapi di-load balance dengan bobot yang berbeda menggunakan load balancing berbobot.
• Pengarahan traffic memungkinkan Anda membuat dua aturan penerusan yang mengarahkan traffic ke layanan backend yang berbeda, dengan backend yang berbeda (grup instance atau NEG). Misalnya, satu backend dapat dikonfigurasi menggunakan jenis mesin yang berbeda untuk memproses traffic dari alamat IP sumber tertentu dengan lebih baik.

Pengarahan traffic dikonfigurasi dengan parameter API aturan penerusan yang disebut sourceIPRanges. Aturan penerusan yang telah mengonfigurasi setidaknya satu rentang IP sumber disebut aturan penerusan pengarah.

Aturan penerusan kemudi dapat menggunakan parameter sourceIPRanges untuk menentukan daftar yang dipisahkan koma hingga 64 alamat IP sumber atau rentang alamat IP. Anda dapat memperbarui daftar rentang alamat IP sumber ini kapan saja.

Setiap aturan penerusan kemudi memerlukan pembuatan aturan penerusan induk terlebih dahulu. Aturan penerusan induk dan pengarah berbagi alamat IP eksternal regional, protokol IP, dan informasi port yang sama; namun, aturan penerusan induk tidak memiliki informasi alamat IP sumber. Contoh:

• Aturan penerusan induk: Alamat IP: 198.51.100.1, protokol IP: TCP, port: 80
• Aturan penerusan kemudi: Alamat IP: 198.51.100.1, protokol IP: TCP, port: 80, sourceIPRanges: 203.0.113.0/24

Aturan penerusan induk yang mengarah ke layanan backend dapat dikaitkan dengan aturan penerusan kemudi yang mengarah ke layanan backend atau instance target.

Untuk aturan penerusan induk tertentu, dua atau beberapa aturan penerusan kemudi dapat memiliki rentang alamat IP sumber dan alamat IP yang tumpang-tindih, tetapi tidak identik. Sebagai contoh, satu aturan penerusan kemudi dapat memiliki rentang IP sumber 203.0.113.0/24 dan aturan penerusan kemudi lainnya untuk induk yang sama dapat memiliki alamat IP sumber 203.0.113.0.

Anda harus menghapus semua aturan penerusan kemudi sebelum dapat menghapus aturan penerusan induk yang menjadi dasarnya.

Untuk mempelajari cara pemrosesan paket masuk saat aturan penerusan pengarah digunakan, lihat Pemilihan aturan penerusan.

Perilaku afinitas sesi di seluruh perubahan pengarahan

Bagian ini menjelaskan kondisi saat afinitas sesi dapat terganggu jika rentang alamat IP sumber yang dikonfigurasi untuk aturan penerusan pengarahan diperbarui:

• Jika koneksi yang ada terus cocok dengan aturan penerusan yang sama setelah Anda mengubah rentang IP sumber untuk aturan penerusan kemudi, afinitas sesi tidak akan terganggu. Jika perubahan Anda menyebabkan koneksi yang ada cocok dengan aturan penerusan yang berbeda, maka:
• Afinitas sesi selalu terganggu dalam situasi berikut:
  • Aturan penerusan yang baru dicocokkan mengarahkan koneksi yang sudah dibuat ke layanan backend (atau instance target) yang tidak mereferensikan VM backend yang dipilih sebelumnya.
  • Aturan penerusan yang baru dicocokkan mengarahkan koneksi yang sudah dibuat ke layanan backend yang mereferensikan VM backend yang dipilih sebelumnya, tetapi layanan backend tidak dikonfigurasi untuk mempertahankan koneksi saat backend tidak responsif, dan VM backend gagal dalam health check layanan backend.
• Afinitas sesi mungkin terganggu saat aturan penerusan yang baru dicocokkan mengarahkan koneksi yang sudah dibuat ke layanan backend, dan layanan backend tersebut mereferensikan VM yang dipilih sebelumnya, tetapi kombinasi afinitas sesi dan mode pelacakan koneksi layanan backend menghasilkan hash pelacakan koneksi yang berbeda.

Mempertahankan afinitas sesi di seluruh perubahan kemudi

Bagian ini menjelaskan cara menghindari gangguan afinitas sesi saat rentang IP sumber untuk aturan penerusan kemudi diperbarui:

• Mengarahkan aturan penerusan yang mengarah ke layanan backend. Jika aturan penerusan kemudi dan induk mengarah ke layanan backend, Anda harus memastikan secara manual bahwa setelan afinitas sesi dan kebijakan pelacakan koneksi identik.Google Cloud tidak otomatis menolak konfigurasi jika tidak identik.
• Mengarahkan aturan penerusan yang mengarah ke instance target. Aturan penerusan induk yang mengarah ke layanan backend dapat dikaitkan dengan aturan penerusan pengarah yang mengarah ke instance target. Dalam hal ini, aturan penerusan pengarah mewarisi setelan afinitas sesi dan kebijakan pelacakan koneksi dari aturan penerusan induk.

Untuk mengetahui petunjuk tentang cara mengonfigurasi pengarahan traffic, lihat Mengonfigurasi pengarahan traffic.

Layanan backend regional

Setiap Load Balancer Jaringan passthrough eksternal memiliki satu layanan backend regional yang menentukan perilaku load balancer dan cara traffic didistribusikan ke backend-nya. Nama layanan backend adalah nama Load Balancer Jaringan passthrough eksternal yang ditampilkan di konsol Google Cloud .

Setiap layanan backend menentukan parameter backend berikut:

• Protokol. Layanan backend menerima traffic di alamat IP dan port (jika dikonfigurasi) yang ditentukan oleh satu atau beberapa aturan penerusan eksternal regional. Layanan backend meneruskan paket ke VM backend sambil mempertahankan alamat IP sumber dan tujuan, protokol, dan jika protokol berbasis port, port sumber dan tujuan paket.

  Layanan backend yang digunakan dengan Load Balancer Jaringan passthrough eksternal mendukung opsi protokol berikut: TCP, UDP, atau UNSPECIFIED.

  Layanan backend dengan protokol UNSPECIFIED dapat digunakan dengan aturan penerusan apa pun, terlepas dari protokol aturan penerusan. Layanan backend dengan protokol tertentu (TCP atau UDP) hanya dapat dirujuk oleh aturan penerusan dengan protokol yang sama (TCP atau UDP). Aturan penerusan dengan protokol L3_DEFAULT hanya dapat merujuk ke layanan backend dengan protokol UNSPECIFIED.

  Lihat Spesifikasi protokol aturan penerusan untuk mengetahui tabel dengan kemungkinan kombinasi protokol aturan penerusan dan layanan backend.

• Distribusi traffic. Layanan backend memungkinkan traffic didistribusikan sesuai dengan afinitas sesi yang dikonfigurasi, kebijakan pelacakan koneksi, dan setelan load balancing berbobot. Layanan backend juga dapat dikonfigurasi untuk mengaktifkan penghentian koneksi dan menetapkan backend failover untuk load balancer. Sebagian besar setelan ini memiliki nilai default yang memungkinkan Anda memulai dengan cepat. Untuk mengetahui informasi selengkapnya, lihat Distribusi traffic untuk Load Balancer Jaringan passthrough eksternal.

• Health check. Layanan backend harus memiliki pemeriksaan kondisi regional terkait.

• Backend. Setiap layanan backend beroperasi di satu region dan mendistribusikan traffic ke grup instance atau NEG zonal di region yang sama. Anda dapat menggunakan grup instance atau NEG zonal, tetapi tidak keduanya secara bersamaan, sebagai backend untuk Load Balancer Jaringan passthrough eksternal:

  • Jika memilih grup instance, Anda dapat menggunakan grup instance tidak terkelola, grup instance terkelola menurut zona, grup instance terkelola regional, atau kombinasi jenis grup instance.
  • Jika memilih NEG zona, Anda harus menggunakan GCE_VM_IP NEG zona.

  Setiap backend grup instance atau NEG memiliki jaringan VPC terkait, meskipun grup instance atau NEG tersebut belum terhubung ke layanan backend. Untuk mengetahui informasi selengkapnya tentang cara jaringan dikaitkan dengan setiap jenis backend, lihat Backend grup instance dan antarmuka jaringan dan Backend NEG zonal dan antarmuka jaringan.

Grup instance

Load Balancer Jaringan passthrough eksternal mendistribusikan koneksi di antara VM backend yang ada dalam grup instance terkelola atau tidak terkelola. Grup instance dapat bersifat regional atau zonal dalam cakupan.

Setiap grup instance memiliki jaringan VPC terkait, meskipun grup instance tersebut belum terhubung ke layanan backend. Untuk mengetahui informasi selengkapnya tentang cara jaringan dikaitkan dengan grup instance, lihat Backend grup instance dan antarmuka jaringan.

Load Balancer Jaringan passthrough eksternal memiliki ketersediaan tinggi berdasarkan desainnya. Tidak ada langkah khusus yang diperlukan untuk membuat load balancer memiliki ketersediaan tinggi karena mekanisme ini tidak bergantung pada satu perangkat atau instance VM. Anda hanya perlu memastikan bahwa instance VM backend Anda di-deploy ke beberapa zona sehingga load balancer dapat mengatasi potensi masalah di zona tertentu.

• Grup instance terkelola regional. Gunakan grup instance terkelola regional jika Anda dapat men-deploy software menggunakan template instance. Grup instance terkelola regional secara otomatis mendistribusikan traffic di antara beberapa zona, sehingga memberikan opsi terbaik untuk menghindari potensi masalah di zona tertentu.

  Contoh deployment menggunakan grup instance terkelola regional ditunjukkan di sini. Grup instance memiliki template instance yang menentukan cara instance harus disediakan, dan setiap grup men-deploy instance dalam tiga zona di region us-central1.

  

• Grup instance terkelola atau tidak terkelola menurut zona. Gunakan grup instance zonal di zona yang berbeda (di region yang sama) untuk melindungi dari potensi masalah di zona tertentu.

  Contoh deployment menggunakan grup instance zonal ditunjukkan di sini. Load balancer ini memberikan ketersediaan di dua zona.

  

NEG Zona

Load Balancer Jaringan passthrough eksternal mendistribusikan koneksi di antara endpoint GCE_VM_IP yang ada dalam grup endpoint jaringan zona. Endpoint ini harus berada di region yang sama dengan load balancer. Untuk beberapa kasus penggunaan NEG zona yang direkomendasikan, lihat Ringkasan grup endpoint jaringan zona.

Endpoint di NEG harus berupa alamat IPv4 internal utama antarmuka jaringan VM yang berada di subnet dan zona yang sama dengan NEG zonal. Alamat IPv4 internal utama dari antarmuka jaringan instance VM multi-NIC dapat ditambahkan ke NEG selama alamat tersebut berada di subnet NEG.

NEG Zonal mendukung VM IPv4 dan dual-stack (IPv4 dan IPv6). Untuk VM IPv4 dan dual-stack, cukup tentukan instance VM saja saat melampirkan endpoint ke NEG. Anda tidak perlu menentukan alamat IP endpoint. Instance VM harus selalu berada di zona yang sama dengan NEG.

Setiap NEG zonal memiliki jaringan VPC dan subnet terkait, meskipun NEG zonal tersebut belum terhubung ke layanan backend. Untuk mengetahui informasi selengkapnya tentang cara jaringan dikaitkan dengan NEG zonal, lihat Backend NEG zonal dan antarmuka jaringan.

Backend grup instance dan antarmuka jaringan

Dalam grup instance (terkelola atau tidak terkelola) tertentu, semua instance VM harus memiliki antarmuka jaringan nic0 di jaringan VPC yang sama.

• Untuk grup instance terkelola (MIG), jaringan VPC untuk grup instance ditentukan dalam template instance.
• Untuk grup instance tidak terkelola, jaringan VPC untuk grup instance ditentukan sebagai jaringan VPC yang digunakan oleh antarmuka jaringan nic0 dari instance VM pertama yang Anda tambahkan ke grup instance tidak terkelola.

Layanan backend tidak dapat mendistribusikan traffic ke VM anggota grup instance pada antarmuka non-nic0. Jika Anda ingin menerima traffic di antarmuka jaringan non-nic0 (vNIC atau Antarmuka Jaringan Dinamis), Anda harus menggunakan NEG zonal dengan endpoint GCE_VM_IP.

Backend NEG zona dan antarmuka jaringan

Saat membuat NEG zonal baru dengan endpoint GCE_VM_IP, Anda harus secara eksplisit mengaitkan NEG dengan subnetwork jaringan VPC sebelum dapat menambahkan endpoint ke NEG. Subnet maupun jaringan VPC tidak dapat diubah setelah NEG dibuat.

Dalam NEG tertentu, setiap endpoint GCE_VM_IP sebenarnya mewakili antarmuka jaringan. Antarmuka jaringan harus berada di subnetwork yang terkait dengan NEG. Dari perspektif instance Compute Engine, antarmuka jaringan dapat menggunakan ID apa pun. Dari perspektif sebagai endpoint di NEG, antarmuka jaringan diidentifikasi menggunakan alamat IPv4 internal utamanya.

Ada dua cara untuk menambahkan endpoint GCE_VM_IP ke NEG:

• Jika Anda hanya menentukan nama VM (tanpa alamat IP) saat menambahkan endpoint, Google Cloud mensyaratkan agar VM memiliki antarmuka jaringan di subnet yang terkait dengan NEG. Alamat IP yang dipilih untuk endpoint adalah alamat IPv4 internal utama antarmuka jaringan VM di subnetwork yang terkait dengan NEG. Google Cloud
• Jika Anda menentukan nama VM dan alamat IP saat menambahkan endpoint, alamat IP yang Anda berikan harus berupa alamat IPv4 internal utama untuk salah satu antarmuka jaringan VM. Antarmuka jaringan tersebut harus berada di subnetwork yang terkait dengan NEG. Perhatikan bahwa penentuan alamat IP bersifat redundan karena hanya ada satu antarmuka jaringan yang berada di subnetwork yang terkait dengan NEG.

NIC Dinamis tidak dapat dihapus jika NIC Dinamis adalah endpoint dari grup endpoint jaringan yang di-load balance.

Layanan backend dan jaringan VPC

Layanan backend tidak dikaitkan dengan jaringan VPC apa pun; namun, setiap grup instance backend atau NEG zonal dikaitkan dengan jaringan VPC, seperti yang disebutkan sebelumnya. Selama semua backend berada di region dan project yang sama, dan selama semua backend memiliki jenis yang sama (grup instance atau NEG zona), Anda dapat menambahkan backend yang menggunakan jaringan VPC yang sama atau berbeda.

Untuk mendistribusikan paket ke antarmuka non-nic0, Anda harus menggunakan backend NEG zona (dengan endpoint GCE_VM_IP).

Backend stack ganda (IPv4 dan IPv6)

Jika Anda ingin load balancer menggunakan backend stack ganda yang menangani traffic IPv4 dan IPv6, perhatikan persyaratan berikut:

• Backend harus dikonfigurasi di subnet dual-stack yang berada di region yang sama dengan aturan penerusan IPv6 load balancer. Untuk backend, Anda dapat menggunakan subnet dengan ipv6-access-type yang disetel ke EXTERNAL atau INTERNAL. Jika ipv6-access-type subnet backend ditetapkan ke INTERNAL, Anda harus menggunakan subnet khusus IPv6 yang berbeda dengan ipv6-access-type yang ditetapkan ke EXTERNAL untuk aturan penerusan eksternal load balancer.
• Backend harus dikonfigurasi agar memiliki stack ganda dengan stack-type yang ditetapkan ke IPV4_IPV6. Jika ipv6-access-type subnet backend ditetapkan ke EXTERNAL, Anda juga harus menetapkan --ipv6-network-tier ke PREMIUM. Untuk mengetahui petunjuknya, lihat Membuat template instance dengan alamat IPv6.

Backend khusus IPv6

Jika Anda ingin load balancer menggunakan backend khusus IPv6, perhatikan persyaratan berikut:

• Instance khusus IPv6 hanya didukung di grup instance tidak terkelola. Tidak ada jenis backend lain yang didukung.
• Backend harus dikonfigurasi di subnet dual-stack atau khusus IPv6 yang berada di region yang sama dengan aturan penerusan IPv6 load balancer. Untuk backend, Anda dapat menggunakan subnet dengan ipv6-access-type yang ditetapkan ke INTERNAL atau EXTERNAL. Jika ipv6-access-type subnet backend ditetapkan ke INTERNAL, Anda harus menggunakan subnet khusus IPv6 lain dengan ipv6-access-type ditetapkan ke EXTERNAL untuk aturan penerusan eksternal load balancer.
• Backend harus dikonfigurasi agar hanya IPv6 dengan VM stack-type disetel ke IPV6_ONLY. Jika ipv6-access-type subnet backend ditetapkan ke EXTERNAL, Anda juga harus menetapkan --ipv6-network-tier ke PREMIUM. Untuk mengetahui petunjuknya, lihat Membuat template instance dengan alamat IPv6.

Perhatikan bahwa VM khusus IPv6 dapat dibuat di subnet dual-stack dan khusus IPv6, tetapi VM dual-stack tidak dapat dibuat di subnet khusus IPv6.

Health check

Load Balancer Jaringan passthrough eksternal menggunakan health check regional untuk menentukan instance mana yang dapat menerima koneksi baru. Setiap layanan backend Load Balancer Jaringan passthrough eksternal harus dikaitkan dengan health check regional. Load balancer menggunakan status health check untuk menentukan cara merutekan koneksi baru ke instance backend.

Untuk mengetahui detail selengkapnya tentang cara kerja health check Google Cloud , lihat Cara kerja health check.

Load Balancer Jaringan passthrough eksternal mendukung jenis health check berikut:

• HTTP, HTTPS, atau HTTP/2. Jika VM backend Anda menayangkan traffic menggunakan HTTP, HTTPS, atau HTTP/2, sebaiknya gunakan health check yang cocok dengan protokol tersebut. Untuk mengetahui detailnya, lihat Kriteria keberhasilan untuk pemeriksaan kondisi HTTP, HTTPS, dan HTTP/2.
• SSL atau TCP. Jika VM backend Anda tidak melayani traffic jenis HTTP, Anda harus menggunakan health check SSL atau TCP. Untuk mengetahui detailnya, lihat Kriteria keberhasilan untuk health check SSL dan TCP.

Health check untuk traffic protokol lain

Google Cloud tidak menawarkan health check khusus protokol di luar yang tercantum di bagian Health check, sebelumnya di halaman ini. Saat menggunakan Load Balancer Jaringan passthrough eksternal untuk menyeimbangkan beban protokol selain TCP, Anda tetap harus menjalankan layanan berbasis TCP di VM backend untuk memberikan informasi health check yang diperlukan.

Misalnya, jika Anda melakukan load balancing traffic UDP, permintaan klien akan di-load balance menggunakan protokol UDP, dan Anda harus menjalankan layanan TCP untuk memberikan informasi ke pemeriksa health check Google Cloud . Untuk melakukannya, Anda dapat menjalankan server HTTP di setiap VM backend yang menampilkan respons HTTP 200 ke pemeriksa health check. Anda harus menggunakan logika Anda sendiri yang berjalan di VM backend untuk memastikan bahwa server HTTP hanya menampilkan 200 jika layanan UDP dikonfigurasi dan berjalan dengan benar.

Aturan firewall

Karena Load Balancer Jaringan passthrough eksternal adalah load balancer passthrough, Anda mengontrol akses ke backend load balancer menggunakan aturan firewall. Google Cloud Anda harus membuat aturan firewall yang mengizinkan ingress atau kebijakan firewall hierarkis yang mengizinkan ingress untuk mengizinkan health check dan traffic yang Anda load balancing.

Aturan penerusan dan aturan firewall izinkan traffic masuk atau Kebijakan firewall hierarkis bekerja bersama dengan cara berikut: aturan penerusan menentukan protokol dan, jika ditentukan, persyaratan port yang harus dipenuhi paket agar dapat diteruskan ke VM backend. Aturan firewall izinkan masuk mengontrol apakah paket yang diteruskan dikirimkan ke VM atau dihentikan. Semua jaringan VPC memiliki aturan firewall masuk tolak tersirat yang memblokir paket masuk dari sumber mana pun. Jaringan VPC default Google Cloud mencakup serangkaian aturan firewall yang sudah terisi otomatis untuk mengizinkan traffic masuk.

• Untuk menerima traffic dari alamat IP mana pun di internet, Anda harus membuat aturan firewall izinkan masuk dengan rentang sumber 0.0.0.0/0. Untuk hanya mengizinkan traffic dari rentang alamat IP tertentu, gunakan rentang sumber yang lebih ketat.

• Sebagai praktik terbaik keamanan, aturan firewall izinkan koneksi masuk Anda hanya boleh mengizinkan protokol dan port IP yang Anda butuhkan. Membatasi konfigurasi protokol (dan, jika memungkinkan, port) sangat penting saat menggunakan aturan penerusan yang protokolnya ditetapkan ke L3_DEFAULT. Aturan penerusan L3_DEFAULT meneruskan paket untuk semua protokol IP yang didukung (di semua port jika protokol dan paket memiliki informasi port).

• Load Balancer Jaringan passthrough eksternal menggunakan Google Cloud health check. Oleh karena itu, Anda harus selalu mengizinkan traffic dari rentang alamat IP health check. Aturan firewall yang mengizinkan ingress ini dapat dibuat khusus untuk protokol dan port health check load balancer.

Alamat IP untuk paket permintaan dan respons

Saat VM backend menerima paket yang di-load balance dari klien, sumber dan tujuan paket adalah sebagai berikut:

• Sumber: alamat IP eksternal yang terkait dengan VM Google Cloud atau alamat IP yang dapat dirutekan ke internet dari sistem yang terhubung ke load balancer.
• Tujuan: alamat IP aturan penerusan load balancer.

Karena load balancer adalah load balancer pass-through (bukan proxy), paket tiba dengan alamat IP tujuan aturan penerusan load balancer. Konfigurasi software yang berjalan di VM backend untuk melakukan hal berikut:

• Memproses (mengikat ke) alamat IP aturan penerusan load balancer atau alamat IP apa pun (0.0.0.0 atau ::)
• Jika protokol aturan penerusan load balancer mendukung port: Lakukan pemantauan (bind ke) port yang disertakan dalam aturan penerusan load balancer

Paket kembali dikirim langsung dari VM backend load balancer ke klien. Alamat IP sumber dan tujuan paket yang ditampilkan bergantung pada protokol:

• TCP berorientasi koneksi sehingga VM backend harus membalas dengan paket yang alamat IP sumbernya cocok dengan alamat IP aturan penerusan agar klien dapat mengaitkan paket respons dengan koneksi TCP yang sesuai.
• UDP, ESP, GRE, dan ICMP tidak memiliki koneksi. VM backend dapat mengirim paket respons yang alamat IP sumbernya cocok dengan alamat IP aturan penerusan atau cocok dengan alamat IP eksternal yang ditetapkan untuk VM. Secara praktis, sebagian besar klien mengharapkan respons berasal dari alamat IP yang sama dengan alamat IP yang digunakan untuk mengirim paket.

Tabel berikut merangkum sumber dan tujuan untuk paket respons:

Jenis traffic	Sumber	Tujuan
TCP	Alamat IP aturan penerusan load balancer	Sumber paket yang meminta
UDP, ESP, GRE, ICMP	Untuk sebagian besar kasus penggunaan, alamat IP aturan penerusan load balancer 1	Sumber paket yang meminta.

Jalur kembali

Load Balancer Jaringan passthrough eksternal menggunakan rute khusus di luar jaringan VPC Anda untuk mengarahkan permintaan masuk dan probe health check ke setiap VM backend.

Load balancer mempertahankan alamat IP sumber paket. Respons dari VM backend langsung menuju klien, bukan kembali melalui load balancer. Istilah industri untuk hal ini adalah direct server return.

Konektivitas internet keluar dari backend

Instance VM yang dikonfigurasi sebagai endpoint backend Load Balancer Jaringan passthrough eksternal dapat memulai koneksi ke internet menggunakan alamat IP aturan penerusan load balancer sebagai alamat IP sumber koneksi keluar.

Umumnya, instance VM selalu menggunakan alamat IP eksternalnya sendiri atau Cloud NAT untuk memulai koneksi. Anda menggunakan alamat IP aturan penerusan untuk memulai koneksi dari endpoint backend hanya dalam skenario khusus seperti saat Anda memerlukan instance VM untuk memulai dan menerima koneksi di alamat IP eksternal yang sama, dan Anda juga memerlukan redundansi backend yang disediakan oleh Load Balancer Jaringan passthrough eksternal untuk koneksi masuk.

Paket keluar yang dikirim dari VM backend langsung ke internet tidak memiliki batasan pada protokol dan port traffic. Meskipun paket keluar menggunakan alamat IP aturan penerusan sebagai sumber, protokol dan port sumber paket tidak harus cocok dengan protokol dan spesifikasi port aturan penerusan. Namun, paket respons masuk harus cocok dengan alamat IP, protokol, dan port tujuan aturan penerusan. Untuk mengetahui informasi selengkapnya, lihat Jalur untuk Load Balancer Jaringan passthrough eksternal dan penerusan protokol eksternal.

Selain itu, semua respons terhadap koneksi keluar VM tunduk pada load balancing, seperti semua paket masuk lainnya yang ditujukan untuk load balancer. Artinya, respons mungkin tidak tiba di VM backend yang sama yang memulai koneksi ke internet. Jika koneksi keluar dan koneksi masuk yang di-load balance menggunakan protokol dan port yang sama, Anda dapat mencoba salah satu saran berikut:

• Menyinkronkan status koneksi keluar di seluruh VM backend, sehingga koneksi dapat ditayangkan meskipun respons tiba di VM backend selain yang telah memulai koneksi.

• Gunakan konfigurasi failover, dengan satu VM utama dan satu VM cadangan. Kemudian, VM backend aktif yang memulai koneksi keluar akan selalu menerima paket respons.

Jalur ke konektivitas internet dari backend Load Balancer Jaringan passthrough eksternal ini adalah perilaku default yang dimaksudkan sesuai dengan aturan firewall tersirat Google Cloud. Namun, jika Anda memiliki kekhawatiran keamanan terkait membiarkan jalur ini terbuka, Anda dapat menggunakan aturan firewall keluar yang ditargetkan untuk memblokir traffic keluar yang tidak diminta ke internet.

Arsitektur VPC Bersama

Kecuali alamat IP, semua komponen Load Balancer Jaringan passthrough eksternal harus ada dalam project yang sama. Tabel berikut meringkas komponen VPC Bersama untuk Load Balancer Jaringan passthrough eksternal:

Alamat IP	Aturan penerusan	Komponen backend
Alamat IP eksternal regional harus ditentukan dalam project yang sama dengan load balancer atau project host VPC Bersama.	Aturan penerusan eksternal regional harus ditentukan dalam project yang sama dengan instance dalam layanan backend.	Layanan backend regional harus ditentukan dalam project yang sama dan region yang sama dengan tempat backend (grup instance atau NEG zonal) berada. Pemeriksaan kesehatan yang terkait dengan layanan backend harus ditentukan dalam project yang sama dan region yang sama dengan layanan backend.

Distribusi traffic

Load Balancer Jaringan passthrough eksternal mendukung berbagai opsi penyesuaian distribusi traffic, termasuk afinitas sesi, pelacakan koneksi, load balancing berbobot, dan failover. Untuk mengetahui detail tentang cara Load Balancer Jaringan passthrough eksternal mendistribusikan traffic, dan cara opsi ini berinteraksi satu sama lain, lihat Distribusi traffic untuk Load Balancer Jaringan passthrough eksternal.

Batasan

• Anda tidak dapat menggunakan konsol Google Cloud untuk melakukan tugas berikut:

  • Buat atau ubah Load Balancer Jaringan passthrough eksternal yang aturan penerusannya menggunakan protokol L3_DEFAULT.
  • Buat atau ubah Load Balancer Jaringan passthrough eksternal yang protokol layanan backend-nya ditetapkan ke UNSPECIFIED.
  • Membuat atau mengubah Load Balancer Jaringan passthrough eksternal yang mengonfigurasi kebijakan pelacakan koneksi.
  • Buat atau ubah pengarahan traffic berbasis IP sumber untuk aturan penerusan.

  Gunakan Google Cloud CLI atau REST API sebagai gantinya.

• Load Balancer Jaringan passthrough eksternal tidak mendukung Peering Jaringan VPC.

Harga

Untuk mengetahui informasi harga, lihat Harga.

Langkah berikutnya

• Untuk mengonfigurasi Load Balancer Jaringan passthrough eksternal dengan layanan backend untuk traffic TCP atau UDP saja (mendukung traffic IPv4 dan IPv6), lihat Menyiapkan Load Balancer Jaringan passthrough eksternal dengan layanan backend.
• Untuk mengonfigurasi Load Balancer Jaringan passthrough eksternal untuk beberapa protokol IP (mendukung traffic IPv4 dan IPv6), lihat Menyiapkan Load Balancer Jaringan passthrough eksternal untuk beberapa protokol IP.
• Untuk mengonfigurasi Load Balancer Jaringan passthrough eksternal dengan backend NEG zona, lihat Menyiapkan Load Balancer Jaringan passthrough eksternal dengan NEG zona.
• Untuk mengonfigurasi Load Balancer Jaringan passthrough eksternal dengan kumpulan target, lihat Menyiapkan Load Balancer Jaringan passthrough eksternal dengan kumpulan target.
• Untuk mempelajari cara mentransisikan Load Balancer Jaringan passthrough eksternal dari backend kumpulan target ke layanan backend regional, lihat Mentransisikan Load Balancer Jaringan passthrough eksternal dari kumpulan target ke layanan backend.
• Untuk menggunakan template Terraform siap pakai guna menyederhanakan penyiapan dan pengelolaan infrastruktur jaringan Google Cloud, pelajari repositori GitHub Solusi Konfigurasi Jaringan Cloud yang Disederhanakan.