Ringkasan Load Balancer Jaringan passthrough eksternal berbasis layanan backend

Load Balancer Jaringan passthrough eksternal adalah load balancer regional lapisan 4 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 dibuat di Maglev dan stack virtualisasi jaringan Andromeda.

Load Balancer Jaringan passthrough eksternal dapat menerima traffic dari:

• Klien mana pun di internet
• VM Google Cloud dengan IP eksternal
• VM Google Cloud 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, tanpa perubahan. VM backend kemudian 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 yang tidak terkelola.
• Backend NEG zona. Load Balancer Jaringan passthrough eksternal berbasis layanan backend mendukung penggunaan NEG zonal dengan endpoint GCE_VM_IP. Endpoint GCE_VM_IP NEG Zona memungkinkan Anda melakukan hal berikut:
  • Teruskan paket ke antarmuka jaringan apa 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 melakukan load balancing 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 yang terperinci. Layanan backend memungkinkan traffic didistribusikan sesuai dengan afinitas sesi yang dapat dikonfigurasi, mode pelacakan koneksi, dan load balancing berbobot. Layanan backend juga dapat dikonfigurasi untuk mengaktifkan pengosongan koneksi dan menunjukkan backend failover untuk load balancer. Sebagian besar setelan ini memiliki nilai default yang memungkinkan Anda memulai dengan cepat.
• 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 didistribusikan.
• Integrasi Google Cloud Armor. Google Cloud Armor mendukung perlindungan DDoS jaringan lanjutan untuk Load Balancer Jaringan passthrough eksternal. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi perlindungan DDoS jaringan lanjutan.

• Integrasi GKE. Jika Anda mem-build aplikasi di GKE, sebaiknya gunakan pengontrol Layanan GKE bawaan, yang men-deploy load balancer Google Cloud atas nama pengguna GKE. Hal ini sama dengan arsitektur load balancing mandiri yang dijelaskan di halaman ini, kecuali bahwa 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 Jaringan passthrough eksternal dengan layanan backend regional

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 region Google Cloud. Alamat IP dapat berupa alamat statis yang dicadangkan atau alamat sementara.

• Untuk traffic IPv6, aturan penerusan mereferensikan rentang /96 dari subnet dual-stack dengan rentang subnet IPv6 eksternal di jaringan VPC. Alamat IPv6 eksternal hanya tersedia di Paket Premium. Rentang alamat IPv6 dapat berupa alamat statis yang dicadangkan atau alamat sementara.

  Catatan: 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 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 tempat load balancer menerima traffic. Karena Load Balancer Jaringan passthrough eksternal bukan proxy, Load Balancer Jaringan passthrough eksternal 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 yang 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 (alamat IPv4 atau 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 akan dikaitkan dengan subnet mana pun. Artinya, alamat IP-nya berasal dari luar rentang subnet Google 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 dirujuk oleh aturan penerusan dapat berupa subnet yang sama dengan yang digunakan oleh instance backend; namun, instance backend dapat menggunakan subnet terpisah jika dipilih. Jika 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 pengarah 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 memiliki aturan penerusan IPv4 dan IPv6 yang mereferensikan layanan backend yang sama, tetapi layanan backend harus mereferensikan 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 melakukan load balancing traffic TCP, UDP, ESP, GRE, ICMP, dan ICMPv6.

Selain mendukung protokol selain TCP dan UDP, L3_DEFAULT memungkinkan satu aturan penerusan menyalurkan beberapa protokol. Misalnya, layanan IPsec biasanya menangani beberapa kombinasi ESP dan traffic IKE dan NAT-T berbasis UDP. 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 protokol yang berbeda.

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 (khusus 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 perlu 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 mewajibkan paket masuk cocok dengan tidak lebih dari satu aturan penerusan. Kecuali untuk aturan penerusan kemudi, yang dibahas di bagian berikutnya, dua atau beberapa aturan penerusan yang menggunakan alamat IP eksternal regional yang sama harus memiliki kombinasi protokol dan port yang unik sesuai dengan batasan ini:

• 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, 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 port satu aturan penerusan adalah 80,443 dan port 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 menurut definisi. Dalam konteks ini, istilah semua port mencakup protokol tanpa informasi port.

• Satu aturan penerusan L3_DEFAULT dapat digunakan bersama dengan aturan penerusan lain yang menggunakan protokol tertentu (TCP atau UDP). Aturan penerusan L3_DEFAULT dapat digunakan sebagai upaya terakhir saat aturan penerusan menggunakan alamat IP yang sama, tetapi ada 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 mengilustrasikan hal ini, pertimbangkan dua skenario berikut. Aturan pengalihan 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 akan 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 pengalihan kedua. Semua paket lainnya, termasuk paket TCP yang dikirim ke port tujuan yang berbeda, diproses oleh aturan penerusan pertama.

Pemilihan aturan penerusan

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

• Menghapus aturan penerusan yang protokolnya tidak cocok dengan protokol paket, kecuali untuk aturan penerusan L3_DEFAULT. Aturan penerusan yang menggunakan protokol L3_DEFAULT tidak pernah dihapus 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 port-nya tidak cocok dengan port paket. Aturan penerusan yang dikonfigurasi untuk semua port tidak pernah dihapus oleh langkah ini karena aturan penerusan semua port cocok dengan port apa pun.

• Jika kandidat aturan penerusan yang tersisa menyertakan aturan penerusan L3_DEFAULT dan protokol tertentu, hapus aturan penerusan L3_DEFAULT. Jika kandidat aturan penerusan yang tersisa semuanya adalah aturan penerusan L3_DEFAULT, tidak ada yang dihapus 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, protokol, dan port tujuan paket, dan digunakan untuk merutekan paket.
  • Dua atau beberapa kandidat aturan penerusan tetap ada yang cocok dengan alamat IP, protokol, dan port tujuan paket. Artinya, kandidat aturan penerusan yang tersisa mencakup aturan penerusan kemudi (dibahas di bagian berikutnya). Pilih aturan penerusan kemudi yang rentang sumber-nya menyertakan CIDR yang paling spesifik (pencocokan awalan terpanjang) yang berisi alamat IP sumber paket. Jika tidak ada aturan penerusan kemudi yang memiliki rentang sumber yang menyertakan alamat IP sumber paket, pilih aturan penerusan induk.
  • Tidak ada kandidat aturan penerusan yang tersisa dan paket akan dihapus.

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

Pengendalian traffic

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

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

• Pengalihan 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 dengan bandwidth rendah ke layanan backend dengan bandwidth tinggi. Kedua layanan backend berisi kumpulan VM atau endpoint backend yang sama, tetapi di-load balancing 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 kumpulan alamat IP sumber tertentu dengan lebih baik.

Pengalihan traffic dikonfigurasi dengan parameter API aturan penerusan yang disebut sourceIPRanges. Aturan penerusan yang memiliki setidaknya satu rentang IP sumber yang dikonfigurasi disebut aturan penerusan kemudi.

Aturan penerusan kemudi dapat memiliki daftar hingga 64 rentang IP sumber. Anda dapat memperbarui daftar rentang IP sumber yang dikonfigurasi untuk aturan penerusan kemudi kapan saja.

Setiap aturan penerusan kemudi mengharuskan Anda membuat aturan penerusan induk terlebih dahulu. Aturan penerusan induk dan kemudi memiliki alamat IP eksternal regional, protokol IP, dan informasi port yang sama; tetapi, 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 IP sumber yang tumpang-tindih, tetapi tidak identik,. Misalnya, satu aturan penerusan kemudi dapat memiliki rentang IP sumber 203.0.113.0/24 dan aturan penerusan kemudi lain untuk induk yang sama dapat memiliki rentang IP sumber 203.0.113.0.

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

Untuk mempelajari cara paket masuk diproses saat aturan penerusan kemudi digunakan, lihat Pemilihan aturan penerusan.

Perilaku afinitas sesi di seluruh perubahan kemudi

Bagian ini menjelaskan kondisi saat afinitas sesi dapat rusak saat rentang IP sumber untuk aturan penerusan kemudi 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 rusak. Jika perubahan Anda menyebabkan koneksi yang ada cocok dengan aturan penerusan yang berbeda, maka:
• Afinitas sesi selalu rusak dalam situasi berikut:
  • Aturan penerusan yang baru dicocokkan akan mengarahkan koneksi yang dibuat ke layanan backend (atau instance target) yang tidak mereferensikan VM backend yang dipilih sebelumnya.
  • Aturan penerusan yang baru dicocokkan mengarahkan koneksi yang 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 rusak saat aturan penerusan yang baru cocok mengarahkan koneksi yang dibuat ke layanan backend, dan layanan backend memang mereferensikan VM yang dipilih sebelumnya, tetapi kombinasi layanan backend dari afinitas sesi dan mode pelacakan koneksi menghasilkan hash pelacakan koneksi yang berbeda.

Mempertahankan afinitas sesi di seluruh perubahan kemudi

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

• Aturan penerusan yang mengarahkan ke layanan backend. Jika aturan penerusan induk dan penerusan kemudi 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 konfigurasi tersebut tidak identik.
• Aturan penerusan kemudi yang mengarah ke instance target. Aturan penerusan induk yang mengarah ke layanan backend dapat dikaitkan dengan aturan penerusan kemudi yang mengarah ke instance target. Dalam hal ini, aturan penerusan kemudi mewarisi setelan afinitas sesi dan kebijakan pelacakan koneksi dari aturan penerusan induk.

Untuk mengetahui petunjuk tentang cara mengonfigurasi pengalihan traffic, lihat Mengonfigurasi pengalihan 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 sekaligus mempertahankan alamat IP sumber dan tujuan paket, protokol, dan, jika protokol berbasis port, port sumber dan tujuan.

  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 melihat tabel dengan kemungkinan kombinasi protokol aturan penerusan dan layanan backend.

• Distribusi traffic. Layanan backend memungkinkan traffic didistribusikan sesuai dengan afinitas sesi yang dapat dikonfigurasi, mode pelacakan koneksi, dan load balancing berbobot. Layanan backend juga dapat dikonfigurasi untuk mengaktifkan pengosongan koneksi dan menunjukkan backend failover untuk load balancer.

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

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

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

  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 serta Backend NEG zonal dan antarmuka jaringan.

Grup instance

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

Load Balancer Jaringan passthrough eksternal hanya mendistribusikan traffic ke antarmuka jaringan pertama (nic0) VM backend. Load balancer mendukung grup instance yang instance anggotanya menggunakan jaringan VPC di region yang sama, selama jaringan VPC berada dalam project yang sama dengan layanan backend. (Semua VM dalam grup instance tertentu harus menggunakan jaringan VPC yang sama.)

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

Catatan: Load Balancer Jaringan passthrough eksternal sangat tersedia karena desainnya. Tidak ada langkah khusus yang diperlukan untuk membuat load balancer memiliki ketersediaan tinggi karena mekanismenya tidak bergantung pada satu perangkat atau instance VM. Anda hanya perlu memastikan bahwa instance VM backend 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 ditampilkan di sini. Grup instance memiliki template instance yang menentukan cara penyediaan instance, dan setiap grup men-deploy instance dalam tiga zona di region us-central1.

  

  Load Balancer Jaringan passthrough eksternal dengan grup instance terkelola regional

• 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 ditampilkan di sini. Load balancer ini menyediakan ketersediaan di dua zona.

  

  Load Balancer Jaringan passthrough eksternal dengan grup instance zonal

NEG Zona

Load Balancer Jaringan passthrough eksternal mendistribusikan koneksi di antara endpoint GCE_VM_IP yang terdapat 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 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 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.

Antarmuka jaringan dan backend grup instance

Jaringan VPC yang terkait dengan grup instance adalah jaringan VPC yang digunakan oleh setiap antarmuka jaringan nic0 VM anggota.

• 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 instance VM pertama yang Anda tambahkan ke grup instance tidak terkelola.

Dalam grup instance tertentu (terkelola atau tidak terkelola), semua instance VM harus memiliki antarmuka jaringan nic0 di jaringan VPC yang sama. Setiap VM anggota secara opsional dapat memiliki antarmuka jaringan tambahan (nic1 melalui nic7), tetapi setiap antarmuka jaringan harus terhubung ke jaringan VPC yang berbeda. Jaringan ini juga harus berbeda dengan jaringan VPC yang terkait dengan grup instance.

Layanan backend tidak dapat mendistribusikan traffic ke VM anggota grup instance di antarmuka non-nic0. Jika ingin menerima traffic di antarmuka jaringan non-default (nic1 hingga nic7), 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 subjaringan jaringan VPC sebelum dapat menambahkan endpoint ke NEG. Baik 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 (nic0 hingga nic7). Dari perspektif sebagai endpoint di NEG, antarmuka jaringan diidentifikasi menggunakan alamat IPv4 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 mewajibkan VM memiliki antarmuka jaringan di subjaringan yang terkait dengan NEG. Alamat IP yang dipilih Google Cloud untuk endpoint adalah alamat IPv4 internal utama dari antarmuka jaringan VM di subjaringan yang terkait dengan NEG.
• 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 menentukan alamat IP bersifat redundan karena hanya boleh ada satu antarmuka jaringan yang berada di subnetwork yang terkait dengan NEG.

Layanan backend dan jaringan VPC

Layanan backend tidak dikaitkan dengan jaringan VPC apa pun; tetapi, setiap grup instance backend atau NEG zonal dikaitkan dengan jaringan VPC, seperti yang telah 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 nic1 melalui nic7, Anda harus menggunakan backend NEG zonal (dengan endpoint GCE_VM_IP) karena jaringan VPC terkait grup instance selalu cocok dengan jaringan VPC yang digunakan oleh antarmuka nic0 dari semua instance anggota.

Backend stack ganda (IPv4 dan IPv6)

Jika Anda ingin load balancer mendukung traffic IPv6, backend harus memenuhi 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 ditetapkan ke EXTERNAL atau INTERNAL. Menggunakan subnet dengan ipv6-access-type yang ditetapkan ke INTERNAL mengharuskan Anda menggunakan subnet dual-stack terpisah dengan ipv6-access-type yang ditetapkan ke EXTERNAL untuk aturan penerusan eksternal load balancer. Untuk mengetahui petunjuknya, lihat Menambahkan subnet stack ganda.
• Backend harus dikonfigurasi menjadi stack ganda dengan --ipv6-network-tier ditetapkan ke PREMIUM. Untuk mengetahui petunjuknya, lihat Membuat template instance dengan alamat 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 pemantauan status HTTP, HTTPS, dan HTTP/2.
• SSL atau TCP. Jika VM backend tidak menayangkan traffic jenis HTTP, Anda harus menggunakan SSL atau health check TCP. Untuk mengetahui detailnya, lihat Kriteria keberhasilan untuk health check SSL dan TCP.

Health check untuk traffic protokol lainnya

Google Cloud tidak menawarkan health check khusus protokol selain yang tercantum di bagian Health checks, sebelumnya di halaman ini. Saat menggunakan Load Balancer Jaringan passthrough eksternal untuk melakukan load balancing pada protokol selain TCP, Anda masih 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 mencapainya, Anda dapat menjalankan server HTTP di setiap VM backend yang menampilkan respons HTTP 200 ke prober pemeriksaan kesehatan. Anda harus menggunakan logika Anda sendiri yang berjalan di VM backend untuk memastikan bahwa server HTTP menampilkan 200 hanya 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 izinkan masuk atau kebijakan firewall hierarkis izinkan masuk untuk mengizinkan health check dan traffic yang Anda load balance.

Aturan penerusan dan aturan firewall izinkan traffic masuk atau Kebijakan firewall hierarkis berfungsi bersama dengan cara berikut: aturan penerusan menentukan protokol dan, jika ditentukan, persyaratan port yang harus dipenuhi paket agar dapat diteruskan ke VM backend. Ingress memungkinkan aturan firewall mengontrol apakah paket yang diteruskan dikirim ke VM atau dihapus. Semua jaringan VPC memiliki aturan firewall traffic masuk deny tersirat yang memblokir paket masuk dari sumber mana pun. Jaringan VPC default Google Cloud mencakup sekumpulan terbatas aturan firewall izinkan traffic masuk yang sudah terisi otomatis.

• 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 izin 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 disetel 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 health check Google Cloud. Oleh karena itu, Anda harus selalu mengizinkan traffic dari rentang alamat IP health check. Ingress ini memungkinkan aturan firewall dibuat khusus untuk protokol dan port health check load balancer.

Alamat IP untuk paket permintaan dan pengembalian

Saat VM backend menerima paket load balancing dari klien, sumber dan tujuan paket tersebut adalah:

• Sumber: alamat IP eksternal yang terkait dengan VM Google Cloud atau alamat IP yang dapat dirutekan 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 akan tiba dengan alamat IP tujuan dari aturan penerusan load balancer. Software yang berjalan di VM backend harus dikonfigurasi 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: Dengarkan (ikat ke) port yang disertakan dalam aturan penerusan load balancer

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

• TCP berorientasi pada koneksi sehingga VM backend harus membalas dengan paket yang alamat IP sumbernya cocok dengan alamat IP aturan penerusan sehingga 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 tempat mereka 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 ^†	Sumber paket yang meminta.

^† Jika VM memiliki alamat IP eksternal atau saat Anda menggunakan Cloud NAT, Anda juga dapat menetapkan alamat IP sumber paket respons ke alamat IPv4 internal utama NIC VM. Google Cloud atau Cloud NAT mengubah alamat IP sumber paket respons menjadi alamat IPv4 eksternal NIC atau alamat IPv4 eksternal Cloud NAT untuk mengirim paket respons ke alamat IP eksternal klien. Tidak menggunakan alamat IP aturan penerusan sebagai sumber adalah skenario lanjutan karena klien menerima paket respons dari alamat IP eksternal yang tidak cocok dengan alamat IP tempat klien mengirim paket permintaan.

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.

Arsitektur VPC Bersama

Kecuali alamat IP, semua komponen Load Balancer Jaringan passthrough eksternal harus ada di 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 di layanan backend.	Layanan backend regional harus ditentukan dalam project dan region yang sama tempat backend (grup instance atau NEG zona) berada. Pemeriksaan kesehatan yang terkait dengan layanan backend harus ditentukan dalam project dan region yang sama dengan layanan backend.

Distribusi traffic

Cara Load Balancer Jaringan passthrough eksternal mendistribusikan koneksi baru bergantung pada apakah Anda telah mengonfigurasi failover:

• Jika Anda belum mengonfigurasi failover, Load Balancer Jaringan passthrough eksternal akan mendistribusikan koneksi baru ke VM backend-nya yang responsif jika setidaknya satu VM backend responsif. Jika semua VM backend tidak responsif, load balancer akan mendistribusikan koneksi baru di antara semua backend sebagai upaya terakhir. Dalam situasi ini, load balancer merutekan setiap koneksi baru ke VM backend yang tidak responsif.
• Jika Anda telah mengonfigurasi failover, Load Balancer Jaringan passthrough eksternal akan mendistribusikan koneksi baru di antara VM backend yang responsif dalam kumpulan aktifnya, sesuai dengan kebijakan failover yang Anda konfigurasikan. Jika semua VM backend tidak responsif, Anda dapat memilih dari satu perilaku berikut:
  • (Default) Load balancer mendistribusikan traffic hanya ke VM utama. Hal ini dilakukan sebagai upaya terakhir. VM cadangan dikecualikan dari distribusi koneksi upaya terakhir ini.
  • Load balancer menghentikan traffic.

Untuk mengetahui detail tentang cara distribusi koneksi, lihat bagian berikutnya Pemilihan backend dan pelacakan koneksi.

Untuk mengetahui detail tentang cara kerja failover, lihat bagian Failover.

Pemilihan backend dan pelacakan koneksi

Load Balancer Jaringan passthrough eksternal menggunakan algoritma pelacakan koneksi dan pemilihan backend yang dapat dikonfigurasi untuk menentukan cara traffic didistribusikan ke VM backend.

Load Balancer Jaringan passthrough eksternal menggunakan algoritma berikut untuk mendistribusikan paket di antara VM backend (dalam kumpulan aktifnya, jika Anda telah mengonfigurasi failover):

1. Jika load balancer memiliki entri dalam tabel pelacakan koneksinya yang cocok dengan karakteristik paket yang masuk, paket akan dikirim ke backend yang ditentukan oleh entri tabel pelacakan koneksi. Paket dianggap sebagai bagian dari koneksi yang dibuat sebelumnya, sehingga paket dikirim ke VM backend yang sebelumnya ditentukan dan dicatat oleh load balancer dalam tabel pelacakan koneksinya.

2. Jika load balancer menerima paket yang tidak memiliki entri pelacakan koneksi, load balancer akan melakukan hal berikut:

   1. Load balancer memilih backend. Load balancer menghitung hash berdasarkan afinitas sesi yang dikonfigurasi. Load balancer menggunakan hash ini untuk memilih backend dari yang responsif (kecuali jika semua backend tidak responsif, dalam hal ini semua backend akan dipertimbangkan selama kebijakan failover belum dikonfigurasi untuk menghentikan traffic dalam situasi ini). Afinitas sesi default, NONE, menggunakan algoritma hashing berikut:

      • Untuk paket TCP dan UDP yang tidak terfragmentasi, hash 5-tuple dari alamat IP sumber, port sumber, alamat IP tujuan, port tujuan, dan protokol paket.
      • Untuk paket UDP yang terfragmentasi dan semua protokol lainnya, hash 3-tuple alamat IP sumber paket, alamat IP tujuan, dan protokol.

      Pemilihan backend dapat disesuaikan dengan menggunakan algoritma hash yang menggunakan lebih sedikit informasi. Untuk semua opsi yang didukung, lihat opsi afinitas sesi.

      Selain itu, perhatikan hal-hal berikut:

      Jika Anda mengaktifkan load balancing berbobot, pemilihan backend berbasis hash akan diberi bobot berdasarkan bobot yang dilaporkan oleh instance backend. Contoh:

      • Pertimbangkan layanan backend yang dikonfigurasi dengan afinitas sesi yang disetel ke NONE dan aturan penerusan dengan protokol UDP. Jika ada dua instance backend yang sehat dengan bobot 1 dan 4, backend akan mendapatkan 20% dan 80% paket UDP.
      • Pertimbangkan layanan backend yang dikonfigurasi dengan afinitas sesi 3-tuple dan pelacakan koneksi. Afinitas sesi adalah CLIENT_IP_PROTO dan mode pelacakan koneksi adalah PER_SESSION. Jika ada tiga instance backend yang sehat dengan bobot 0, 2, dan 6, backend akan mendapatkan traffic untuk 0%, 25%, dan 75% alamat IP sumber baru (alamat IP sumber untuk yang tidak ada entri tabel pelacakan koneksi yang ada) masing-masing. Traffic untuk koneksi yang ada akan diarahkan ke backend yang ditetapkan sebelumnya.
        Perhatian: Jika bobot sering berubah, load balancing berbobot dapat merugikan afinitas sesi. Ada beberapa load-balancer dan pelacakan koneksi tidak direplikasi di seluruh load-balancer tersebut. Untuk afinitas sesi yang berkelanjutan, sebaiknya Anda tidak menggunakan load balancing berbobot atau jarang menggunakannya.

   2. Load balancer menambahkan entri ke tabel pelacakan koneksinya. Entri ini mencatat backend yang dipilih untuk koneksi paket sehingga semua paket mendatang dari koneksi ini dikirim ke backend yang sama. Apakah pelacakan koneksi digunakan bergantung pada protokol:

      • Paket TCP. Pelacakan koneksi selalu diaktifkan, dan tidak dapat dinonaktifkan. Secara default, pelacakan koneksi adalah 5-tuple, tetapi dapat dikonfigurasi menjadi kurang dari 5-tuple. Jika 5-tuple, paket SYN TCP diperlakukan secara berbeda. Tidak seperti paket non-SYN, paket ini menghapus entri pelacakan koneksi yang cocok dan selalu memilih backend baru.
        
        Pelacakan koneksi 5-tuple default digunakan saat:

        • mode pelacakan adalah PER_CONNECTION (semua afinitas sesi), atau,
        • mode pelacakan adalah PER_SESSION dan afinitas sesi adalah NONE, atau,
        • mode pelacakan adalah PER_SESSION dan afinitas sesi adalah CLIENT_IP_PORT_PROTO.

      • Paket UDP, ESP, dan GRE. Pelacakan koneksi hanya diaktifkan jika afinitas sesi disetel ke sesuatu selain NONE.

      • Paket ICMP dan ICMPv6. Pelacakan koneksi tidak dapat digunakan.

      Untuk mengetahui detail tambahan tentang kapan pelacakan koneksi diaktifkan, dan metode pelacakan yang digunakan saat pelacakan koneksi diaktifkan, lihat mode pelacakan koneksi.

      Selain itu, perhatikan hal-hal berikut:

      • Masa berlaku entri dalam tabel pelacakan koneksi berakhir 60 detik setelah load balancer memproses paket terakhir yang cocok dengan entri. Lihat Waktu tunggu tidak ada aktivitas untuk mengetahui detailnya.
      • Bergantung pada protokol, load balancer mungkin menghapus entri tabel pelacakan koneksi saat backend menjadi tidak responsif. Untuk mengetahui detail dan cara menyesuaikan perilaku ini, lihat Persistensi koneksi di backend yang tidak sehat.

Opsi afinitas sesi

Afinitas sesi mengontrol distribusi koneksi baru dari klien ke VM backend load balancer. Afinitas sesi ditentukan untuk seluruh layanan backend eksternal regional, bukan berdasarkan backend.

Load Balancer Jaringan passthrough eksternal mendukung opsi afinitas sesi berikut:

• Tidak ada (NONE). Hash 5-tuple dari alamat IP sumber, port sumber, protokol, alamat IP tujuan, dan port tujuan
• IP Klien, IP Tujuan (CLIENT_IP). Hash 2-tuple dari alamat IP sumber dan alamat IP tujuan
• IP Klien, IP Tujuan, Protokol (CLIENT_IP_PROTO). Hash 3-tuple dari alamat IP sumber, alamat IP tujuan, dan protokol
• IP Klien, Port Klien, IP Tujuan, Port Tujuan, Protokol (CLIENT_IP_PORT_PROTO). Hash 5-tuple dari alamat IP sumber, port sumber, protokol, alamat IP tujuan, dan port tujuan

Untuk mempelajari pengaruh opsi afinitas sesi ini terhadap metode pelacakan koneksi dan pemilihan backend, lihat tabel ini.

Mode pelacakan koneksi

Apakah pelacakan koneksi diaktifkan hanya bergantung pada protokol traffic yang di-load balancing dan setelan afinitas sesi. Mode pelacakan menentukan algoritma pelacakan koneksi yang akan digunakan saat pelacakan koneksi diaktifkan. Ada dua mode pelacakan: PER_CONNECTION (default) dan PER_SESSION.

• PER_CONNECTION (default). Ini adalah mode pelacakan default. Dengan mode pelacakan koneksi ini, traffic TCP selalu dilacak per 5-tuple, terlepas dari setelan afinitas sesi. Untuk traffic UDP, ESP, dan GRE, pelacakan koneksi diaktifkan jika afinitas sesi yang dipilih bukan NONE. Paket UDP, ESP, dan GRE dilacak menggunakan metode pelacakan yang dijelaskan dalam tabel ini.

• PER_SESSION. Jika afinitas sesi adalah CLIENT_IP atau CLIENT_IP_PROTO, mengonfigurasi mode ini akan menghasilkan pelacakan koneksi 2-tuple dan 3-tuple, masing-masing, untuk semua protokol (kecuali ICMP dan ICMPv6, yang tidak dapat dilacak koneksinya). Untuk setelan afinitas sesi lainnya, mode PER_SESSION berperilaku sama dengan mode PER_CONNECTION.

Untuk mempelajari cara kerja mode pelacakan ini dengan setelan afinitas sesi yang berbeda untuk setiap protokol, lihat tabel berikut.

Pemilihan backend		Mode pelacakan koneksi
Setelan afinitas sesi	Metode hash untuk pemilihan backend	PER_CONNECTION (default)	PER_SESSION
Default: Tidak ada afinitas sesi (NONE)	TCP dan UDP yang tidak terfragmentasi: Hash 5-tuple UDP yang terfragmentasi dan semua protokol lainnya: Hash 3-tuple	TCP: Pelacakan koneksi 5-tuple Semua protokol lainnya: pelacakan koneksi nonaktif	TCP: Pelacakan koneksi 5-tuple Semua protokol lainnya: pelacakan koneksi nonaktif
IP Klien, IP Tujuan (CLIENT_IP)	Semua protokol: Hash 2-tuple	TCP dan UDP yang tidak terfragmentasi: Pelacakan koneksi 5-tuple UDP, ESP, dan GRE yang terfragmentasi: Pelacakan koneksi 3-tuple Semua protokol lainnya: pelacakan koneksi nonaktif	TCP, UDP, ESP, GRE: Pelacakan koneksi 2-tuple Semua protokol lainnya: pelacakan koneksi nonaktif
IP Klien, IP Tujuan, Protokol (CLIENT_IP_PROTO)	Semua protokol: Hash 3-tuple	TCP dan UDP yang tidak terfragmentasi: Pelacakan koneksi 5-tuple UDP, ESP, dan GRE yang terfragmentasi: Pelacakan koneksi 3-tuple Semua protokol lainnya: pelacakan koneksi nonaktif	TCP, UDP, ESP, GRE: Pelacakan koneksi 3-tuple Semua protokol lainnya: pelacakan koneksi nonaktif
IP Klien, Port Klien, IP Tujuan, Port Tujuan, Protokol (CLIENT_IP_PORT_PROTO)	TCP dan UDP yang tidak terfragmentasi: Hash 5-tuple UDP yang terfragmentasi dan semua protokol lainnya: Hash 3-tuple	TCP dan UDP yang tidak terfragmentasi: Pelacakan koneksi 5-tuple UDP, ESP, dan GRE yang terfragmentasi: Pelacakan koneksi 3-tuple Semua protokol lainnya: pelacakan koneksi nonaktif	TCP dan UDP yang tidak terfragmentasi: Pelacakan koneksi 5-tuple UDP, ESP, dan GRE yang terfragmentasi: Pelacakan koneksi 3-tuple Semua protokol lainnya: pelacakan koneksi nonaktif

Untuk mempelajari cara mengubah mode pelacakan koneksi, lihat Mengonfigurasi kebijakan pelacakan koneksi.

Persistensi koneksi di backend yang tidak responsif

Setelan persistensi koneksi mengontrol apakah koneksi yang ada tetap ada di VM atau endpoint backend yang dipilih setelah backend tersebut menjadi tidak sehat, selama backend tetap berada dalam grup backend yang dikonfigurasi load balancer (dalam grup instance atau NEG).

Perilaku yang dijelaskan di bagian ini tidak berlaku jika Anda menghapus instance backend dari grup instance atau menghapus endpoint backend dari NEG-nya, atau menghapus grup instance atau NEG dari layanan backend. Dalam kasus tersebut, koneksi yang dibuat hanya akan tetap ada seperti yang dijelaskan dalam pengosongan koneksi.

Opsi persistensi koneksi berikut tersedia:

• DEFAULT_FOR_PROTOCOL (default)
• NEVER_PERSIST
• ALWAYS_PERSIST

Tabel berikut merangkum opsi persistensi koneksi dan cara koneksi tetap ada untuk berbagai protokol, opsi afinitas sesi, dan mode pelacakan.

Opsi Persistensi koneksi pada backend yang tidak responsif	Mode pelacakan koneksi
	PER_CONNECTION	PER_SESSION
DEFAULT_FOR_PROTOCOL	TCP: koneksi tetap ada di backend yang tidak sehat (semua afinitas sesi) Semua protokol lainnya: koneksi tidak pernah bertahan di backend yang tidak responsif	TCP: koneksi tetap ada di backend yang tidak responsif jika afinitas sesi adalah NONE atau CLIENT_IP_PORT_PROTO Semua protokol lainnya: koneksi tidak pernah bertahan di backend yang tidak responsif
NEVER_PERSIST	Semua protokol: koneksi tidak pernah dipertahankan di backend yang tidak responsif
ALWAYS_PERSIST	TCP: koneksi tetap ada di backend yang tidak sehat (semua afinitas sesi) ESP, GRE, UDP: koneksi tetap ada di backend yang tidak sehat jika afinitas sesi bukan NONE ICMP, ICMPv6: tidak berlaku karena tidak dapat dilacak koneksinya Opsi ini hanya boleh digunakan untuk kasus penggunaan lanjutan.	Konfigurasi tidak memungkinkan

Catatan: Saat load balancer memindahkan koneksi dari backend yang tidak responsif, load balancer akan membuat entri tabel pelacakan baru. Entri baru memetakan koneksi ke backend yang berbeda berdasarkan afinitas sesi yang dikonfigurasi. Entri baru tetap valid seperti entri lainnya. Jika backend yang tidak sehat kembali menjadi sehat, hal itu saja tidak akan menyebabkan entri tabel pelacakan koneksi dihapus (kecuali jika memicu failback dan pengosongan koneksi saat failover dan failback telah dinonaktifkan).

Perilaku persistensi koneksi TCP di backend yang tidak responsif

Setiap kali koneksi TCP dengan pelacakan 5-tuple tetap ada di backend yang tidak sehat:

• Jika backend yang tidak sehat terus merespons paket, koneksi akan terus berlanjut hingga direset atau ditutup (oleh backend yang tidak sehat atau klien).
• Jika backend yang tidak sehat mengirim paket reset TCP (RST) atau tidak merespons paket, klien dapat mencoba lagi dengan koneksi baru, sehingga load balancer dapat memilih backend yang berbeda dan sehat. Paket TCP SYN selalu memilih backend baru yang sehat.

Untuk mempelajari cara mengubah perilaku persistensi koneksi, lihat Mengonfigurasi kebijakan tracking koneksi.

Waktu tunggu tidak ada aktivitas

Masa berlaku entri dalam tabel pelacakan koneksi akan berakhir 60 detik setelah load balancer memproses paket terakhir yang cocok dengan entri. Nilai waktu tunggu tidak ada aktivitas ini tidak dapat diubah.

Load balancing berbobot

Perhatian: Jika bobot sering berubah, load balancing berbobot dapat merugikan afinitas sesi. Ada beberapa load balancer dan pelacakan koneksi tidak direplikasi di seluruh load balancer tersebut. Untuk afinitas sesi yang berkelanjutan, sebaiknya Anda tidak menggunakan load balancing berbobot atau jarang menggunakannya.

Anda dapat mengonfigurasi load balancer jaringan untuk mendistribusikan traffic di seluruh instance backend load balancer berdasarkan bobot yang dilaporkan oleh health check HTTP menggunakan load balancing berbobot.

Load balancing berbobot mengharuskan Anda mengonfigurasi kedua hal berikut:

• Anda harus menetapkan kebijakan load balancer lokalitas (localityLbPolicy) dari layanan backend ke WEIGHTED_MAGLEV.
• Anda harus mengonfigurasi layanan backend dengan health check HTTP. Respons pemeriksaan kesehatan HTTP harus berisi kolom header respons HTTP kustom X-Load-Balancing-Endpoint-Weight untuk menentukan bobot dengan nilai dari 0 ke 1000 untuk setiap instance backend.

Jika Anda menggunakan backend yang sama (grup instance atau NEG) untuk beberapa Load Balancer Jaringan passthrough eksternal berbasis layanan backend menggunakan load balancing berbobot, sebaiknya gunakan request-path unik untuk setiap health check layanan backend. Hal ini memungkinkan instance endpoint menetapkan bobot yang berbeda ke layanan backend yang berbeda. Untuk mengetahui informasi selengkapnya, lihat Kriteria keberhasilan untuk pemeriksaan status HTTP, HTTPS, dan HTTP/2.

Untuk memilih backend untuk koneksi baru, backend diberi urutan prioritas yang ketat berdasarkan bobot dan status kesehatannya seperti yang ditunjukkan dalam tabel berikut:

Bobot	Responsif	Prioritas pemilihan backend
Berat lebih besar dari nol	Ya	4
Berat lebih besar dari nol	Tidak	3
Bobot sama dengan nol	Ya	2
Bobot sama dengan nol	Tidak	1

Hanya backend dengan prioritas tertinggi yang memenuhi syarat untuk pemilihan backend. Jika semua backend yang memenuhi syarat memiliki bobot nol, load balancer akan mendistribusikan koneksi baru di antara semua backend yang memenuhi syarat, dengan memperlakukannya dengan bobot yang sama. Untuk contoh load balancing berbobot, lihat Pemilihan backend dan pelacakan koneksi.

Load balancing berbobot dapat digunakan dalam skenario berikut:

• Jika beberapa koneksi memproses lebih banyak data daripada yang lain, atau beberapa koneksi berlangsung lebih lama daripada yang lain, distribusi beban backend mungkin menjadi tidak merata. Dengan memberikan sinyal bobot per instance yang lebih rendah, instance dengan beban tinggi dapat mengurangi pangsa koneksi barunya, sekaligus terus melayani koneksi yang ada.

• Jika backend kelebihan beban dan menetapkan lebih banyak koneksi dapat merusak koneksi yang ada, backend tersebut akan menetapkan bobot nol untuk dirinya sendiri. Dengan memberi sinyal bobot nol, instance backend berhenti melayani koneksi baru, tetapi terus melayani koneksi yang ada.

• Jika backend menghabiskan koneksi yang ada sebelum pemeliharaan, backend akan menetapkan bobot nol untuk dirinya sendiri. Dengan memberikan bobot nol, instance backend akan berhenti melayani koneksi baru, tetapi terus melayani koneksi yang ada.

Untuk informasi selengkapnya, lihat Mengonfigurasi load balancing berbobot.

Pengosongan koneksi

Pengosongan koneksi adalah proses yang diterapkan ke koneksi yang dibuat dalam kasus berikut:

• VM atau endpoint dihapus dari backend (grup instance atau NEG).
• Backend menghapus VM atau endpoint (dengan penggantian, penghentian, saat melakukan upgrade, atau menskalakan ke bawah).
• Backend dihapus dari layanan backend.

Secara default, pengosongan koneksi dinonaktifkan. Jika dinonaktifkan, koneksi yang sudah dibuat akan dihentikan secepat mungkin. Jika penghentian koneksi diaktifkan, koneksi yang dibuat diizinkan untuk tetap ada selama waktu tunggu yang dapat dikonfigurasi, setelah itu instance VM backend dihentikan.

Untuk mengetahui detail selengkapnya tentang cara pengosongan koneksi dipicu dan cara mengaktifkan pengosongan koneksi, lihat Mengaktifkan pengosongan koneksi.

Fragmentasi UDP

Catatan: Rekomendasi berikut tentang cara menangani paket UDP yang terfragmentasi dengan Load Balancer Jaringan passthrough eksternal berbasis layanan backend berbeda dengan rekomendasi untuk Load Balancer Jaringan passthrough eksternal berbasis kumpulan target lama.

Load Balancer Jaringan passthrough eksternal berbasis layanan backend dapat memproses paket UDP yang terfragmentasi dan tidak terfragmentasi. Jika aplikasi Anda menggunakan paket UDP yang terfragmentasi, perhatikan hal berikut:

• Paket UDP mungkin menjadi terfragmentasi sebelum mencapai jaringan VPC Google Cloud.
• Jaringan VPC Google Cloud meneruskan fragmen UDP saat fragmen tersebut tiba (tanpa menunggu semua fragmen tiba).
• Jaringan non-Google Cloud dan peralatan jaringan lokal mungkin meneruskan fragmen UDP saat tiba, menunda paket UDP yang terfragmentasi hingga semua fragmen tiba, atau menghapus paket UDP yang terfragmentasi. Untuk mengetahui detailnya, lihat dokumentasi untuk penyedia jaringan atau peralatan jaringan.

Jika Anda mengharapkan paket UDP yang terfragmentasi dan perlu merutekannya ke backend yang sama, gunakan aturan penerusan dan parameter konfigurasi layanan backend berikut:

• Konfigurasi aturan penerusan: Hanya gunakan satu aturan penerusan UDP atau L3_DEFAULT per alamat IP yang di-load balance, dan konfigurasikan aturan penerusan untuk menerima traffic di semua port. Hal ini memastikan bahwa semua fragmen tiba di aturan penerusan yang sama. Meskipun paket yang terfragmentasi (selain fragmen pertama) tidak memiliki port tujuan, mengonfigurasi aturan penerusan untuk memproses traffic untuk semua port juga mengonfigurasinya untuk menerima fragmen UDP yang tidak memiliki informasi port. Untuk mengonfigurasi semua port, gunakan Google Cloud CLI untuk menetapkan --ports=ALL atau gunakan API untuk menetapkan allPorts ke True.

• Konfigurasi layanan backend: Tetapkan afinitas sesi layanan backend ke CLIENT_IP (hash 2-tuple) atau CLIENT_IP_PROTO (hash 3-tuple) sehingga backend yang sama dipilih untuk paket UDP yang menyertakan informasi port dan fragmen UDP (selain fragmen pertama) yang tidak memiliki informasi port. Tetapkan mode pelacakan koneksi layanan backend ke PER_SESSION sehingga entri tabel pelacakan koneksi dibuat menggunakan hash 2-tuple atau 3-tuple yang sama.

Menggunakan instance target sebagai backend

Jika Anda menggunakan instance target sebagai backend untuk Load Balancer Jaringan passthrough eksternal dan Anda mengharapkan paket UDP yang terfragmentasi, hanya gunakan satu aturan penerusan UDP atau L3_DEFAULT per alamat IP, dan konfigurasikan aturan penerusan untuk menerima traffic di semua port. Hal ini memastikan bahwa semua fragmen tiba di aturan penerusan yang sama meskipun tidak memiliki port tujuan yang sama. Untuk mengonfigurasi semua port, tetapkan --ports=ALL menggunakan gcloud, atau tetapkan allPorts ke True menggunakan API.

Failover

Anda dapat mengonfigurasi Network Load Balancer passthrough eksternal untuk mendistribusikan koneksi di antara instance VM atau endpoint di backend utama (grup instance atau NEG), lalu beralih, jika diperlukan, untuk menggunakan backend failover. Failover menyediakan metode lain untuk meningkatkan ketersediaan, sekaligus memberi Anda kontrol yang lebih besar atas cara mengelola beban kerja saat backend utama tidak berfungsi.

Secara default, saat Anda menambahkan backend ke layanan backend Load Balancer Jaringan passthrough eksternal, backend tersebut adalah backend utama. Anda dapat menetapkan backend sebagai backend failover saat menambahkannya ke layanan backend load balancer, atau dengan mengedit layanan backend nanti.

Untuk mengetahui detail selengkapnya tentang cara kerja failover, lihat Ringkasan failover untuk Network Load Balancer passthrough eksternal.

Koneksi internet keluar dari backend

Instance VM yang dikonfigurasi sebagai endpoint backend Network Load Balancer 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 spesifikasi port dan protokol 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, setiap respons terhadap koneksi keluar VM tunduk pada load balancing, seperti semua paket masuk lainnya yang ditujukan untuk load balancer. Artinya, respons mungkin tidak muncul di VM backend yang sama yang memulai koneksi ke internet. Jika koneksi keluar dan koneksi masuk load-balanced menggunakan protokol dan port yang sama, Anda dapat mencoba salah satu sugesti berikut:

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

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

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

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.
  • Buat atau ubah Load Balancer Jaringan passthrough eksternal yang mengonfigurasi kebijakan pelacakan koneksi.
  • Buat atau ubah pemilihan traffic berbasis IP sumber untuk aturan penerusan.

  Sebagai gantinya, gunakan Google Cloud CLI atau REST API.

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

Harga

Untuk mengetahui informasi harga, lihat Harga.

Langkah selanjutnya

• Untuk mengonfigurasi Load Balancer Jaringan passthrough eksternal dengan layanan backend hanya untuk traffic TCP atau UDP (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.