Ringkasan Load Balancer Jaringan passthrough internal

Load Balancer Jaringan passthrough internal adalah load balancer regional yang dibuat di stack virtualisasi jaringan Andromeda.

Load Balancer Jaringan passthrough internal mendistribusikan traffic di antara instance virtual machine (VM) internal di region yang sama dalam jaringan Virtual Private Cloud (VPC). Hal ini memungkinkan Anda menjalankan dan menskalakan layanan di balik alamat IP internal yang hanya dapat diakses oleh sistem di jaringan VPC yang sama atau sistem yang terhubung ke jaringan VPC Anda.

Gunakan Load Balancer Jaringan passthrough internal dalam situasi berikut:

• Anda memerlukan load balancer Layer 4 pass-through berperforma tinggi untuk protokol TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH, dan GRE.
• Jika menyalurkan traffic melalui TLS (SSL), Anda dapat mengizinkan traffic SSL dihentikan oleh backend, bukan oleh load balancer. Load Balancer Jaringan passthrough internal tidak dapat menghentikan traffic SSL.
• Anda harus meneruskan paket asli tanpa proxy. Misalnya, jika Anda perlu mempertahankan alamat IP sumber klien.
• Anda memiliki penyiapan yang sudah ada yang menggunakan load balancer pass-through, dan Anda ingin memigrasikannya tanpa perubahan.

Load Balancer Jaringan passthrough internal menangani banyak kasus penggunaan. Untuk beberapa contoh umum, lihat Ringkasan Load Balancer Jaringan passthrough.

Cara kerja Load Balancer Jaringan passthrough internal

Load Balancer Jaringan passthrough internal memiliki frontend (aturan penerusan) dan backend (layanan backend). Anda dapat menggunakan grup instance atau NEG zonal GCE_VM_IP sebagai backend di layanan backend. Contoh ini menunjukkan backend grup instance.

Contoh Load Balancer Jaringan passthrough internal tingkat tinggi (klik untuk memperbesar).

Tidak seperti load balancer proxy, Load Balancer Jaringan passthrough internal tidak menghentikan koneksi dari klien, lalu membuka koneksi baru ke backend. Sebagai gantinya, Load Balancer Jaringan passthrough internal merutekan koneksi langsung dari klien ke backend yang sehat, tanpa gangguan apa pun. Respons dari VM backend yang responsif akan langsung ditujukan ke klien, bukan kembali melalui load balancer. Respons TCP menggunakan return server langsung. Untuk informasi selengkapnya, lihat Permintaan TCP dan UDP serta paket yang ditampilkan.

Load balancer memantau kondisi backend menggunakan probe health check. Untuk mengetahui informasi selengkapnya, lihat bagian Health check.

Lingkungan tamu Linux, lingkungan tamu Windows, atau proses yang setara di Google Cloud mengonfigurasi setiap VM backend dengan alamat IP load balancer. Untuk VM yang dibuat dari image Google Cloud, Agen tamu (sebelumnya, Lingkungan tamu Windows atau Lingkungan tamu Linux) akan menginstal rute lokal untuk alamat IP load balancer. Instance Google Kubernetes Engine berdasarkan OS yang Dioptimalkan untuk Container menerapkannya dengan menggunakan iptables.

Jaringan virtual Google Cloud mengelola pengiriman dan penskalaan traffic sesuai kebutuhan.

Protokol, skema, dan cakupan

Setiap Load Balancer Jaringan passthrough internal mendukung hal berikut:

• Satu layanan backend dengan skema load balancing INTERNAL dan protokol yang didukung. Untuk mengetahui informasi selengkapnya, lihat layanan backend.
• VM backend yang ditentukan sebagai salah satu dari berikut:
  • Grup instance terkelola dan tidak terkelola yang berada di satu region dan jaringan VPC.
  • Grup endpoint jaringan zonal (NEG) backend dengan endpoint jenis GCE_VM_IP yang berada di region dan jaringan VPC yang sama. Endpoint di NEG harus berupa alamat IP internal utama di subnet dan zona yang sama dengan yang digunakan oleh NEG.
• Dukungan untuk traffic IPv4 dan IPv6 saat menggunakan backend grup instance. Grup endpoint jaringan zona (NEG) dengan endpoint GCE_VM_IP hanya mendukung traffic IPv4.
• Satu atau beberapa aturan penerusan, masing-masing menggunakan protokol TCP, UDP, atau L3_DEFAULT yang cocok dengan protokol layanan backend.
• Setiap aturan penerusan dengan alamat IP uniknya sendiri atau beberapa aturan penerusan yang memiliki alamat IP yang sama.
• Setiap aturan penerusan dengan maksimal lima port atau semua port.
• Jika akses global diaktifkan, klien di region mana pun.
• Jika akses global dinonaktifkan, klien di region yang sama dengan load balancer.

Load Balancer Jaringan passthrough internal tidak mendukung:

• VM backend di beberapa region.
• Menyeimbangkan traffic yang berasal dari internet, kecuali jika Anda menggunakannya dengan load balancer eksternal.
• Paket IPv6 dengan header yang terfragmentasi.

Akses klien

Secara default, load balancer hanya mendukung klien yang berada di region yang sama dengan load balancer. Klien dapat berada di jaringan yang sama dengan load balancer atau di jaringan VPC yang terhubung menggunakan Peering Jaringan VPC. Anda dapat mengaktifkan akses global untuk mengizinkan klien dari region mana pun mengakses Load Balancer Jaringan passthrough internal.

Load Balancer Jaringan passthrough internal dengan akses global (klik untuk memperbesar).

Tabel berikut merangkum akses klien.

Akses global dinonaktifkan	Akses global diaktifkan
Klien harus berada di region yang sama dengan load balancer. VM juga harus berada di jaringan VPC yang sama dengan load balancer atau di jaringan VPC yang terhubung ke jaringan VPC load balancer menggunakan Peering Jaringan VPC.	Klien dapat berada di wilayah mana pun. VM tersebut tetap harus berada di jaringan VPC yang sama dengan load balancer atau di jaringan VPC yang terhubung ke jaringan VPC load balancer menggunakan Peering Jaringan VPC.
Klien lokal dapat mengakses load balancer melalui tunnel Cloud VPN atau lampiran VLAN. Tunnel atau lampiran ini harus berada di region yang sama dengan load balancer.	Klien lokal dapat mengakses load balancer melalui tunnel Cloud VPN atau lampiran VLAN. Tunnel atau lampiran ini dapat berada di region mana pun.

Alamat IP untuk paket permintaan dan pengembalian

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

• Sumber: IPv4 internal, IPv6, atau alamat IPv4 klien dari salah satu rentang IPv4 alias klien.
• Tujuan: alamat IP aturan penerusan load balancer. Aturan penerusan menggunakan satu alamat IPv4 internal atau rentang IPv6 internal.

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 tidak memiliki koneksi sehingga VM backend dapat mengirim paket respons yang alamat IP sumbernya cocok dengan alamat IP aturan penerusan atau cocok dengan alamat IP 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	Untuk sebagian besar kasus penggunaan, alamat IP aturan penerusan load balancer ^†	Sumber paket yang meminta

^† Anda dapat menetapkan sumber paket respons ke alamat IPv4 internal utama NIC VM atau rentang alamat IP alias. Jika VM mengaktifkan penerusan IP, sumber alamat IP arbitrer juga dapat digunakan. Tidak menggunakan alamat IP aturan penerusan sebagai sumber adalah skenario lanjutan karena klien menerima paket respons dari alamat IP internal yang tidak cocok dengan alamat IP tempat klien mengirim paket permintaan.

Arsitektur

Load Balancer Jaringan passthrough internal dengan beberapa backend mendistribusikan koneksi di antara semua backend tersebut. Untuk informasi tentang metode distribusi dan opsi konfigurasinya, lihat distribusi traffic.

Anda dapat menggunakan grup instance atau NEG zonal, tetapi tidak kombinasi keduanya, sebagai backend untuk Load Balancer Jaringan passthrough internal:

• Jika memilih grup instance, Anda dapat menggunakan grup instance tidak terkelola, 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.

Ketersediaan tinggi menjelaskan cara mendesain load balancer internal yang tidak bergantung pada satu zona.

Instance yang berpartisipasi sebagai VM backend untuk Load Balancer Jaringan passthrough internal harus menjalankan lingkungan tamu Linux atau Windows yang sesuai atau proses lain yang memberikan fungsi yang setara. Lingkungan tamu ini harus dapat menghubungi server metadata (metadata.google.internal, 169.254.169.254) untuk membaca metadata instance sehingga dapat membuat rute lokal untuk menerima traffic yang dikirim ke alamat IP internal load balancer.

Diagram ini menggambarkan distribusi traffic di antara VM yang terletak di dua grup instance terpisah. Traffic yang dikirim dari instance klien ke alamat IP load balancer (10.10.10.9) didistribusikan di antara VM backend di salah satu grup instance. Respons yang dikirim dari VM backend penayangan apa pun dikirim langsung ke VM klien.

Anda dapat menggunakan Load Balancer Jaringan passthrough internal dengan jaringan VPC mode kustom atau mode otomatis. Anda juga dapat membuat Load Balancer Jaringan passthrough internal dengan jaringan lama yang ada.

Load Balancer Jaringan passthrough internal terdiri dari komponen Google Cloud berikut.

Komponen	Tujuan	Persyaratan
Alamat IP internal	Ini adalah alamat untuk load balancer.	Alamat IP internal harus berada dalam subnet yang sama dengan aturan penerusan internal. Subnet harus berada di region dan jaringan VPC yang sama dengan layanan backend.
Aturan penerusan internal	Aturan penerusan internal yang dikombinasikan dengan alamat IP internal adalah frontend load balancer. File ini menentukan protokol dan port yang diterima load balancer, dan mengarahkan traffic ke layanan backend internal regional.	Aturan penerusan untuk Load Balancer Jaringan passthrough internal harus melakukan hal berikut: • Memiliki load-balancing-scheme INTERNAL. • Gunakan ip-protocol dari TCP atau UDP, yang cocok dengan protocol layanan backend. • Mereferensikan subnet di jaringan VPC dan region yang sama dengan layanan backend.
Layanan backend internal regional	Layanan backend internal regional menentukan protokol yang digunakan untuk berkomunikasi dengan backend, dan menentukan health check. Backend dapat berupa grup instance yang tidak dikelola, grup instance zona terkelola, grup instance regional terkelola, atau NEG zona dengan endpoint GCE_VM_IP.	Layanan backend harus melakukan hal berikut: • Memiliki load-balancing-scheme INTERNAL. • Gunakan protocol dari TCP atau UDP, yang cocok dengan ip-protocol dari aturan penerusan. • Memiliki health check terkait. • Memiliki region terkait. Aturan penerusan dan semua backend harus berada di region yang sama dengan layanan backend • Dikaitkan dengan satu jaringan VPC. Jika tidak ditentukan, jaringan akan disimpulkan berdasarkan jaringan yang digunakan oleh antarmuka jaringan default setiap VM backend (nic0). Meskipun layanan backend tidak terikat dengan subnet tertentu, subnet aturan penerusan harus berada di jaringan VPC yang sama dengan layanan backend.
Health check	Setiap layanan backend harus memiliki health check yang terkait. Health check menentukan parameter yang digunakan Google Cloud untuk mempertimbangkan backend yang dikelolanya agar memenuhi syarat untuk menerima traffic. Hanya VM backend yang responsif yang menerima traffic yang dikirim dari VM klien ke alamat IP load balancer.	Meskipun aturan penerusan dan layanan backend dapat menggunakan TCP atau UDP, Google Cloud tidak memiliki health check untuk traffic UDP. Untuk mengetahui informasi selengkapnya, lihat health check dan traffic UDP.

Load Balancer Jaringan passthrough internal tidak mendukung:

• VM backend di beberapa region.
• Menyeimbangkan traffic yang berasal dari internet, kecuali jika Anda menggunakannya dengan load balancer eksternal.
• Paket IPv6 dengan header yang terfragmentasi.

Alamat IP internal

Load Balancer Jaringan passthrough internal mendukung subnet khusus IPv4 (single-stack) dan subnet IPv4 dan IPv6 (dual-stack). Untuk mengetahui informasi selengkapnya, lihat Jenis subnet.

Load Balancer Jaringan passthrough internal memerlukan minimal satu aturan penerusan. Aturan penerusan mereferensikan alamat IP internal:

• Untuk traffic IPv4, aturan penerusan mereferensikan alamat IPv4 dari rentang subnet IPv4 utama.
• Untuk traffic IPv6, aturan penerusan mereferensikan rentang alamat IPv6 internal /96 dari rentang alamat IPv6 internal /64 subnet. Subnet harus berupa subnet dual-stack dengan rentang alamat IPv6 internal (ipv6-access-type ditetapkan ke INTERNAL).

Konfigurasi firewall

Load Balancer Jaringan passthrough internal memerlukan konfigurasi berikut untuk kebijakan firewall hierarkis dan aturan firewall VPC:

• Izinkan traffic masuk dari rentang sumber health check IPv4 atau IPv6.
• Mengizinkan traffic masuk dari rentang sumber alamat IPv4 atau IPv6 klien.

Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi aturan firewall.

Aturan penerusan

Aturan penerusan menentukan protokol dan port tempat load balancer menerima traffic. Karena bukan proxy, Load Balancer Jaringan passthrough internal meneruskan traffic ke backend pada protokol dan port yang sama.

Load Balancer Jaringan passthrough internal memerlukan setidaknya satu aturan penerusan internal. Anda dapat menentukan beberapa aturan penerusan untuk load balancer yang sama.

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.

Aturan penerusan harus mereferensikan subnet tertentu di jaringan dan region VPC yang sama dengan komponen backend load balancer. Persyaratan ini memiliki implikasi berikut:

• Subnet yang Anda tentukan untuk aturan penerusan tidak perlu sama dengan salah satu subnet yang digunakan oleh VM backend; namun, subnet harus berada di region yang sama dengan aturan penerusan.
• Untuk traffic IPv4, aturan penerusan internal mereferensikan alamat IPv4 internal regional dari rentang alamat IPv4 utama subnet yang Anda pilih. Alamat IPv4 ini dapat dipilih secara otomatis atau Anda dapat menggunakan alamat IPv4 statis (dicadangkan).
• Untuk traffic IPv6, aturan penerusan mereferensikan rentang alamat IPv6 /96 dari rentang alamat IPv6 internal subnet. Subnet harus berupa subnet dual-stack dengan ipv6-access-type ditetapkan ke INTERNAL. Rentang alamat IPv6 /96 ditetapkan secara otomatis atau Anda dapat menggunakan alamat IP internal yang dicadangkan.

Protokol aturan penerusan

Load Balancer Jaringan passthrough internal mendukung opsi protokol IPv4 berikut untuk setiap aturan penerusan: TCP, UDP, atau L3_DEFAULT.

Load Balancer Jaringan passthrough internal mendukung opsi protokol IPv6 berikut untuk setiap aturan penerusan: TCP atau UDP.

Opsi L3_DEFAULT memungkinkan Anda melakukan load balancing protokol TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH, dan GRE.

Selain mendukung protokol selain TCP dan UDP, opsi L3_DEFAULT memungkinkan satu aturan penerusan untuk meneruskan traffic secara bersamaan untuk beberapa protokol. Misalnya, selain membuat permintaan HTTP, Anda juga dapat mengirim ping ke alamat IP load balancer.

Aturan penerusan yang menggunakan protokol TCP atau UDP dapat mereferensikan layanan backend menggunakan protokol yang sama dengan aturan penerusan atau layanan backend menggunakan 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 (IPv4 atau IPv6)	TCP	TCP or UNSPECIFIED
UDP (IPv4 atau IPv6)	UDP	UDP or UNSPECIFIED
TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH, dan GRE	L3_DEFAULT	UNSPECIFIED

Aturan penerusan dan akses global

Aturan penerusan Load Balancer Jaringan passthrough internal bersifat regional, meskipun akses global diaktifkan. Setelah Anda mengaktifkan akses global, flag allowGlobalAccess aturan penerusan internal regional ditetapkan ke true.

Aturan penerusan dan spesifikasi port

Saat membuat aturan penerusan internal, Anda harus memilih salah satu spesifikasi port berikut:

• Tentukan minimal satu dan maksimal lima port, berdasarkan nomor.
• Tentukan ALL untuk meneruskan traffic di semua port.

Aturan penerusan internal yang mendukung semua port TCP atau semua port UDP memungkinkan VM backend menjalankan beberapa aplikasi, masing-masing di portnya sendiri. Traffic yang dikirim ke port tertentu akan dikirim ke aplikasi yang sesuai, dan semua aplikasi menggunakan alamat IP yang sama.

Jika Anda perlu meneruskan traffic di lebih dari lima port tertentu, gabungkan aturan firewall dengan aturan penerusan. Saat membuat aturan penerusan, tentukan semua port, lalu buat aturan firewall allow masuk yang hanya mengizinkan traffic ke port yang diinginkan. Terapkan aturan firewall ke VM backend.

Anda tidak dapat mengubah aturan penerusan setelah membuatnya. Jika perlu mengubah port yang ditentukan atau alamat IP internal untuk aturan penerusan internal, Anda harus menghapus dan membuatnya ulang.

Beberapa aturan penerusan untuk satu layanan backend

Anda dapat mengonfigurasi beberapa aturan penerusan internal yang semuanya mereferensikan layanan backend internal yang sama. Load Balancer Jaringan passthrough internal memerlukan minimal satu aturan penerusan internal.

Dengan mengonfigurasi beberapa aturan penerusan untuk layanan backend yang sama, Anda dapat melakukan hal berikut:

• Tetapkan beberapa alamat IP ke load balancer. Anda dapat membuat beberapa aturan penerusan, masing-masing menggunakan alamat IP unik. Setiap aturan penerusan dapat menentukan semua port atau kumpulan hingga lima port.

• Tetapkan kumpulan port tertentu, menggunakan alamat IP yang sama, ke load balancer. Anda dapat membuat beberapa aturan penerusan yang memiliki alamat IP yang sama, dengan setiap aturan penerusan menggunakan sekumpulan port tertentu hingga lima port. Ini adalah alternatif untuk mengonfigurasi satu aturan penerusan yang menentukan semua port.

Untuk informasi selengkapnya tentang skenario yang melibatkan dua atau beberapa aturan penerusan internal yang berbagi alamat IP internal yang sama, lihat Beberapa aturan penerusan dengan alamat IP yang sama.

Saat menggunakan beberapa aturan penerusan internal, pastikan Anda mengonfigurasi software yang berjalan di VM backend untuk mengikat ke semua alamat IP aturan penerusan atau ke alamat apa pun (0.0.0.0/0 untuk IPv4 atau ::/0 untuk IPv6). Alamat IP tujuan untuk paket yang dikirim melalui load balancer adalah alamat IP internal yang terkait dengan aturan penerusan internal yang sesuai. Untuk informasi selengkapnya, lihat Permintaan TCP dan UDP serta paket yang ditampilkan.

Layanan backend

Setiap Load Balancer Jaringan passthrough internal memiliki satu layanan backend internal regional yang menentukan parameter dan perilaku backend. Nama layanan backend adalah nama Load Balancer Jaringan passthrough internal yang ditampilkan di konsol Google Cloud.

Setiap layanan backend menentukan parameter backend berikut:

• Protokol. Layanan backend mendukung traffic IPv4 dan IPv6. Jika protokol memiliki konsep port (seperti TCP atau UDP), layanan backend akan mengirimkan paket ke VM backend di port tujuan yang sama dengan port tujuan yang digunakan untuk mengirim traffic.

  Layanan backend mendukung opsi protokol IPv4 berikut: TCP, UDP, atau UNSPECIFIED.

  Layanan backend mendukung opsi protokol IPv6 berikut: TCP atau UDP. Protokol layanan backend harus berkoordinasi dengan protokol aturan penerusan.

  Untuk tabel dengan kemungkinan kombinasi aturan penerusan dan protokol layanan backend, lihat Spesifikasi protokol aturan penerusan.

• Distribusi traffic. Layanan backend memungkinkan traffic didistribusikan sesuai dengan afinitas sesi yang dapat dikonfigurasi.

• Health check. Layanan backend harus memiliki health check terkait.

Setiap layanan backend beroperasi di satu region dan mendistribusikan traffic untuk VM backend dalam satu jaringan VPC:

• Satu jenis backend, satu region. Backend adalah grup instance atau NEG zonal dengan endpoint GCE_VM_IP yang berada di region yang sama dengan layanan backend dan aturan penerusan. Backend grup instance dapat berupa grup instance tidak terkelola, grup instance terkelola zona, atau grup instance terkelola regional. Backend NEG zona harus menggunakan endpoint GCE_VM_IP.

• Satu jaringan VPC. 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. Resource layanan backend itu sendiri juga memiliki jaringan VPC terkait, yang dapat ditentukan secara eksplisit atau implisit. Untuk informasi selengkapnya tentang jaringan layanan backend, lihat Spesifikasi jaringan layanan backend dan Aturan jaringan layanan backend.

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.

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.

Spesifikasi jaringan layanan backend

Anda dapat mengaitkan jaringan VPC secara eksplisit dengan layanan backend menggunakan tanda --network saat membuat layanan backend. Aturan jaringan layanan backend akan langsung diterapkan.

Jika Anda menghilangkan tanda --network saat membuat layanan backend, Google Cloud akan menggunakan salah satu peristiwa penentu berikut untuk secara implisit menetapkan jaringan VPC terkait layanan backend. Setelah ditetapkan, jaringan VPC terkait layanan backend tidak dapat diubah:

• Jika layanan backend belum memiliki backend terkait, dan Anda mengonfigurasi aturan penerusan pertama untuk mereferensikan layanan backend, Google Cloud akan menetapkan jaringan VPC terkait layanan backend ke jaringan VPC yang berisi subnet yang digunakan oleh aturan penerusan ini.

• Jika layanan backend belum memiliki aturan penerusan yang mereferensikannya, dan Anda menambahkan backend grup instance pertama ke layanan backend, Google Cloud akan menetapkan jaringan VPC layanan backend ke jaringan VPC yang terkait dengan backend grup instance pertama tersebut. Artinya, jaringan VPC terkait layanan backend adalah jaringan yang digunakan oleh antarmuka jaringan nic0 dari setiap VM di backend grup instance pertama.

• Jika layanan backend belum memiliki aturan penerusan yang mereferensikannya, dan Anda menambahkan backend NEG zona pertama (dengan endpoint GCE_VM_IP) ke layanan backend, Google Cloud akan menetapkan jaringan VPC layanan backend ke jaringan VPC yang terkait dengan backend NEG pertama tersebut.

Setelah jaringan VPC layanan backend ditetapkan oleh peristiwa yang memenuhi syarat, aturan penerusan tambahan, grup instance backend, atau NEG zonal backend yang Anda tambahkan harus mengikuti aturan jaringan layanan backend.

Aturan jaringan layanan backend

Aturan berikut berlaku setelah layanan backend dikaitkan dengan jaringan VPC tertentu:

• Saat mengonfigurasi aturan penerusan untuk mereferensikan layanan backend, aturan penerusan harus menggunakan subnet jaringan VPC layanan backend. Aturan penerusan dan layanan backend tidak dapat menggunakan jaringan VPC yang berbeda, meskipun jaringan tersebut terhubung menggunakan Peering Jaringan VPC.

• Saat menambahkan backend grup instance, salah satu hal berikut harus benar:

  • Jaringan VPC yang terkait dengan grup instance—yaitu, jaringan VPC yang digunakan oleh antarmuka jaringan nic0 setiap VM dalam grup instance—harus cocok dengan jaringan VPC terkait layanan backend.
  • Setiap VM backend harus memiliki antarmuka non-nic0 (nic1 hingga nic7) di jaringan VPC yang terkait dengan layanan backend.

• Saat menambahkan backend NEG zonal dengan endpoint GCE_VM_IP, jaringan VPC yang terkait dengan NEG harus cocok dengan jaringan VPC yang terkait dengan layanan backend.

Sub-setelan backend

Subset backend adalah fitur opsional yang meningkatkan performa dengan membatasi jumlah backend tempat traffic didistribusikan.

Anda hanya boleh mengaktifkan subsetting jika perlu mendukung lebih dari 250 VM backend di satu load balancer. Untuk mengetahui informasi selengkapnya, lihat Subsetelan backend untuk Load Balancer Jaringan passthrough internal.

Health check

Layanan backend load balancer harus dikaitkan dengan health check global atau regional. Rute khusus di luar jaringan VPC memfasilitasi komunikasi antara sistem health check dan backend.

Anda dapat menggunakan health check yang ada atau menentukan health check baru. Load Balancer Jaringan passthrough internal menggunakan status health check untuk menentukan cara merutekan koneksi baru, seperti yang dijelaskan dalam Distribusi traffic.

Anda dapat menggunakan salah satu protokol health check berikut; protokol health check tidak harus cocok dengan protokol load balancer:

• 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 karena health check berbasis HTTP menawarkan opsi yang sesuai dengan protokol tersebut. Menayangkan traffic jenis HTTP melalui Load Balancer Jaringan passthrough internal berarti protokol load balancer adalah TCP.
• SSL atau TCP. Jika VM backend tidak menayangkan traffic jenis HTTP, Anda harus menggunakan health check SSL atau TCP.

Terlepas dari jenis health check yang Anda buat, Google Cloud akan mengirim probe health check ke alamat IP aturan penerusan Load Balancer Jaringan passthrough internal, ke antarmuka jaringan di jaringan VPC yang dipilih oleh layanan backend load balancer. Hal ini menyimulasikan cara traffic dengan load balancing dikirim. Software yang berjalan di VM backend Anda harus merespons traffic load balanced dan probe health check yang dikirim ke setiap alamat IP aturan penerusan (software harus memproses di 0.0.0.0:<port>, bukan di alamat IP tertentu yang ditetapkan ke antarmuka jaringan). Untuk mengetahui informasi selengkapnya, lihat Tujuan untuk paket probe.

Health check dan traffic UDP

Google Cloud tidak menawarkan health check yang menggunakan protokol UDP. Saat menggunakan Load Balancer Jaringan passthrough internal dengan traffic UDP, Anda harus menjalankan layanan berbasis TCP di VM backend untuk memberikan informasi health check.

Dalam konfigurasi ini, permintaan klien di-load balance menggunakan protokol UDP, dan layanan TCP digunakan untuk memberikan informasi ke pemeriksa status Google Cloud. Misalnya, Anda dapat menjalankan server HTTP sederhana di setiap VM backend yang menampilkan respons HTTP 200 ke Google Cloud. Dalam contoh ini, 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.

Arsitektur ketersediaan tinggi

Load Balancer Jaringan passthrough internal sangat tersedia karena desainnya. Tidak ada langkah khusus untuk membuat load balancer memiliki ketersediaan tinggi karena mekanismenya tidak bergantung pada satu perangkat atau instance VM.

Untuk memastikan instance VM backend Anda di-deploy ke beberapa zona, ikuti rekomendasi deployment berikut:

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

• Jika Anda menggunakan grup instance terkelola zona atau grup instance tidak terkelola, gunakan beberapa grup instance di zona yang berbeda (di region yang sama) untuk layanan backend yang sama. Penggunaan beberapa zona akan melindungi dari potensi masalah di zona tertentu.

Arsitektur VPC Bersama

Tabel berikut merangkum persyaratan komponen untuk Network Load Balancer passthrough internal yang digunakan dengan jaringan VPC Bersama. Untuk contohnya, lihat membuat Load Balancer Jaringan passthrough internal di halaman Penyediaan VPC Bersama.

Alamat IP	Aturan penerusan	Komponen backend
Alamat IP internal harus ditentukan dalam project yang sama dengan VM backend. Agar load balancer tersedia di jaringan VPC Bersama, alamat IP internal Google Cloud harus ditentukan di project layanan yang sama dengan lokasi VM backend, dan harus mereferensikan subnet di jaringan VPC Bersama yang diinginkan di project host. Alamat itu sendiri berasal dari rentang IP utama dari subnet yang dirujuk. Jika Anda membuat alamat IP internal di project layanan dan subnet alamat IP berada di jaringan VPC project layanan, Load Balancer Jaringan passthrough internal Anda bersifat lokal untuk project layanan. Project ini tidak bersifat lokal untuk project host VPC Bersama.	Aturan penerusan internal harus ditentukan dalam project yang sama dengan VM backend. Agar load balancer tersedia di jaringan VPC Bersama, aturan penerusan internal harus ditentukan dalam project layanan yang sama dengan lokasi VM backend, dan harus mereferensikan subnet yang sama (di jaringan VPC Bersama) dengan referensi alamat IP internal terkait. Jika Anda membuat aturan penerusan internal di project layanan dan subnet aturan penerusan berada di jaringan VPC project layanan, Load Balancer Jaringan passthrough internal Anda bersifat lokal untuk project layanan. Project ini tidak bersifat lokal untuk project host VPC Bersama.	Dalam skenario VPC Bersama, VM backend berada di project layanan. Layanan backend internal regional dan health check harus ditentukan dalam project layanan tersebut.

Distribusi traffic

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

• Jika Anda belum mengonfigurasi failover, Network Load Balancer passthrough internal 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 internal akan mendistribusikan koneksi baru di antara VM dalam kumpulan aktifnya, sesuai dengan kebijakan failover yang Anda konfigurasikan. Jika semua VM backend tidak responsif, Anda dapat memilih salah satu perilaku berikut:

  • (Default) Load balancer hanya mendistribusikan traffic ke VM utama. Hal ini dilakukan sebagai upaya terakhir. VM cadangan dikecualikan dari distribusi koneksi upaya terakhir ini.
  • Load balancer dikonfigurasi untuk menurunkan traffic.

Metode untuk mendistribusikan koneksi baru bergantung pada setelan afinitas sesi load balancer.

Status health check mengontrol distribusi koneksi baru. Secara default, koneksi TCP tetap ada di backend yang tidak responsif. Untuk detail selengkapnya dan cara mengubah perilaku ini, lihat Persistensi koneksi di backend yang tidak sehat.

Pemilihan backend dan pelacakan koneksi

Load Balancer Jaringan passthrough internal menggunakan algoritma pelacakan koneksi dan pemilihan backend yang dapat dikonfigurasi untuk menentukan cara traffic didistribusikan ke VM backend. Load Balancer Jaringan passthrough internal 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. Fungsi ini menggunakan hash ini untuk memilih backend:

      • Jika setidaknya satu backend sehat, hash akan memilih salah satu backend yang sehat.
      • Jika semua backend tidak responsif, dan tidak ada kebijakan penggantian saat gagal yang dikonfigurasi, hash akan memilih salah satu backend.
      • Jika semua backend tidak responsif, ada kebijakan failover yang dikonfigurasi, dan kebijakan failover tidak dikonfigurasi untuk menghentikan traffic dalam situasi ini, hash akan memilih salah satu backend VM utama.

      Afinitas sesi default, NONE, menggunakan hash 5 tuple dari alamat IP sumber, port sumber, alamat IP tujuan, port tujuan, dan protokol paket

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

   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:

      Untuk paket TCP dan UDP, pelacakan koneksi selalu diaktifkan, dan tidak dapat dinonaktifkan. Secara default, pelacakan koneksi adalah 5-tuple, tetapi dapat dikonfigurasi menjadi kurang dari 5-tuple.

      Jika hash pelacakan koneksi adalah 5-tuple, paket SYN TCP selalu membuat entri baru di tabel pelacakan koneksi.
      
      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.

      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:

      • Secara default, masa berlaku entri dalam tabel pelacakan koneksi berakhir setelah 600 detik setelah load balancer memproses paket terakhir yang cocok dengan entri. Untuk mengetahui detail tentang cara menyesuaikan waktu tunggu tidak ada aktivitas, lihat Waktu tunggu tidak ada aktivitas.
      • 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. Anda menetapkan afinitas sesi saat VM backend perlu melacak informasi status untuk kliennya. Ini adalah persyaratan umum untuk aplikasi web.

Afinitas sesi berfungsi berdasarkan upaya terbaik.

Load Balancer Jaringan passthrough internal mendukung opsi afinitas sesi berikut, yang Anda tentukan untuk seluruh layanan backend internal, bukan per grup instance backend.

• Tidak ada (NONE). Hash 5-tuple dari alamat IP sumber, port sumber, protokol, alamat IP tujuan, dan port tujuan
• IP klien, tanpa tujuan (CLIENT_IP_NO_DESTINATION). Hash 1-tuple yang dibuat hanya dari alamat IP sumber.
• IP klien (CLIENT_IP). Hash 2-tuple dari alamat IP sumber dan alamat IP tujuan. Load Balancer Jaringan passthrough eksternal memanggil opsi afinitas sesi ini Client IP, Destination IP.
• 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

Kecuali jika Anda menggunakan load balancer sebagai next hop untuk rute statis kustom, alamat IP tujuan paket harus cocok dengan alamat IP aturan penerusan load balancer agar paket dapat dikirim ke load balancer. Untuk pertimbangan saat menggunakan load balancer sebagai next hop untuk rute statis kustom, lihat Afinitas sesi dan Load Balancer Jaringan passthrough internal next hop.

Catatan: Untuk load balancer UDP internal, menetapkan afinitas sesi didukung di gcloud CLI dan API. Saat ini, Anda tidak dapat menetapkan afinitas sesi untuk traffic UDP menggunakan konsol Google Cloud.

Afinitas sesi dan next hop Load Balancer Jaringan passthrough internal

Saat Anda mengonfigurasi rute statis untuk menggunakan Load Balancer Jaringan passthrough internal next hop, load balancer akan menggunakan metode pelacakan koneksi dan pemilihan backend yang sama seperti yang telah dibahas sebelumnya. Pemilihan backend masih dilakukan dengan menghitung hash sesuai dengan afinitas sesi yang dikonfigurasi. Kecuali untuk afinitas sesi CLIENT_IP_NO_DESTINATION, hash pemilihan backend, sebagian, bergantung pada alamat IP tujuan paket.

Jika load balancer Network Load Balancer passthrough internal adalah next hop dari rute statis, alamat IP tujuan tidak terbatas pada alamat IP aturan penerusan load balancer. Sebagai gantinya, alamat IP tujuan paket dapat berupa alamat IP mana pun yang sesuai dengan rentang tujuan rute statis.

Jika jumlah VM backend yang dikonfigurasi dan responsif konstan (jika failover tidak dikonfigurasi, atau, jika failover dikonfigurasi tetapi tidak ada peristiwa failover atau failback yang terjadi), load balancer akan berperilaku sebagai berikut:

• Jika hanya ada satu VM backend yang dikonfigurasi dan responsif (di kumpulan aktif, jika failover dikonfigurasi), tidak masalah afinitas sesi apa yang Anda gunakan karena semua hash dipetakan ke satu VM backend.

• Jika ada dua atau beberapa VM backend yang dikonfigurasi dan responsif (dalam kumpulan aktif, jika failover dikonfigurasi), pilihan afinitas sesi Anda penting:

  • Jika Anda memerlukan VM backend yang sama untuk memproses semua paket dari klien, hanya berdasarkan alamat IP sumber paket, terlepas dari alamat IP tujuan paket, gunakan afinitas sesi CLIENT_IP_NO_DESTINATION. Bergantung pada pola traffic, beberapa VM backend mungkin menerima lebih banyak paket atau lebih banyak koneksi daripada VM backend lainnya.

  • Jika Anda menggunakan opsi afinitas sesi yang bukan CLIENT_IP_NO_DESTINATION, load balancer akan memilih VM backend berdasarkan informasi yang setidaknya menyertakan baik alamat IP sumber dan alamat IP tujuan paket. Paket yang dikirim dari klien yang sama, menggunakan alamat IP sumber yang sama, tetapi alamat IP tujuan yang berbeda, dapat dirutekan ke VM backend yang berbeda.

Mode pelacakan koneksi

Mode pelacakan menentukan algoritma pelacakan koneksi yang akan digunakan. Ada dua mode pelacakan: PER_CONNECTION (default) dan PER_SESSION.

• PER_CONNECTION (default). Dalam mode ini, traffic TCP dan UDP selalu dilacak per 5-tuple, terlepas dari setelan afinitas sesi. Hal ini menyiratkan bahwa kunci untuk pelacakan koneksi (5-tuple) dapat berbeda dari setelan afinitas sesi yang dikonfigurasi (misalnya, 3-tuple dengan setelan CLIENT_IP_PROTO). Akibatnya, afinitas sesi dapat dibagi dan koneksi baru untuk sesi dapat memilih backend yang berbeda jika kumpulan backend atau statusnya berubah.

• PER_SESSION. Dalam mode ini, traffic TCP dan UDP dilacak sesuai dengan afinitas sesi yang dikonfigurasi. Artinya, jika afinitas sesi adalah CLIENT_IP atau CLIENT_IP_PROTO, mengonfigurasi mode ini akan menghasilkan pelacakan koneksi 2-tuple dan 3-tuple. Hal ini mungkin diinginkan dalam skenario saat pemutusan afinitas mahal dan harus dihindari bahkan setelah lebih banyak backend ditambahkan.

Setelan mode pelacakan koneksi bersifat redundan jika afinitas sesi disetel ke NONE atau CLIENT_IP_PORT_PROTO. 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	Hash 5-tuple	Pelacakan koneksi 5-tuple	Pelacakan koneksi 5-tuple
IP klien, tanpa tujuan CLIENT_IP_NO_DESTINATION	Hash 1-tuple	Pelacakan koneksi 5-tuple	Pelacakan koneksi 1-tuple
IP Klien CLIENT_IP (sama dengan IP Klien, IP Tujuan untuk Load Balancer Jaringan passthrough eksternal)	Hash 2-tuple	Pelacakan koneksi 5-tuple	Pelacakan koneksi 2-tuple
IP Klien, IP Tujuan, Protokol CLIENT_IP_PROTO	Hash 3-tuple	Pelacakan koneksi 5-tuple	Pelacakan koneksi 3-tuple
IP Klien, Port Klien, IP Tujuan, Port Tujuan, Protokol CLIENT_IP_PORT_PROTO	Hash 5-tuple	Pelacakan koneksi 5-tuple	Pelacakan koneksi 5-tuple

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

Persistensi koneksi di backend yang tidak responsif

Setelan persistensi koneksi pada backend yang tidak berfungsi mengontrol apakah koneksi yang ada tetap ada di backend yang dipilih setelah backend tersebut tidak berfungsi (selama backend tetap berada dalam grup instance backend yang dikonfigurasi load balancer).

Perilaku yang dijelaskan di bagian ini tidak berlaku jika Anda menghapus VM backend dari grup instance-nya, atau menghapus grup instance dari layanan backend. Dalam kasus tersebut, koneksi yang dibuat hanya akan tetap ada seperti yang dijelaskan dalam Mengaktifkan 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) UDP: koneksi tidak pernah dipertahankan di backend yang tidak sehat	TCP: koneksi tetap ada di backend yang tidak responsif jika afinitas sesi adalah NONE atau CLIENT_IP_PORT_PROTO UDP: koneksi tidak pernah dipertahankan di backend yang tidak sehat
NEVER_PERSIST	TCP, UDP: koneksi tidak pernah dipertahankan di backend yang tidak sehat
ALWAYS_PERSIST	TCP, UDP: koneksi tetap ada di backend yang tidak sehat (semua afinitas sesi) Opsi ini hanya boleh digunakan untuk kasus penggunaan lanjutan.	Konfigurasi tidak memungkinkan

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

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

Waktu tunggu tidak ada aktivitas

Secara default, masa berlaku entri dalam tabel pelacakan koneksi berakhir setelah 600 detik setelah load balancer memproses paket terakhir yang cocok dengan entri. Nilai waktu tunggu tidak ada aktivitas default ini hanya dapat diubah jika pelacakan koneksi kurang dari 5-tuple (yaitu, saat afinitas sesi dikonfigurasi menjadi CLIENT_IP atau CLIENT_IP_PROTO, dan mode pelacakannya adalah PER_SESSION).

Nilai waktu tunggu tidak ada aktivitas maksimum yang dapat dikonfigurasi adalah 57.600 detik (16 jam).

Untuk mempelajari cara mengubah nilai waktu tunggu tidak ada aktivitas, lihat Mengonfigurasi kebijakan pelacakan koneksi.

Menguji koneksi dari satu klien

Saat menguji koneksi ke alamat IP Load Balancer Jaringan passthrough internal dari satu sistem klien, Anda harus mengingat hal berikut:

• Jika sistem klien bukan VM yang di-load balancing—yaitu, bukan VM backend, koneksi baru akan dikirim ke VM backend load balancer yang responsif. Namun, karena semua opsi afinitas sesi bergantung setidaknya pada alamat IP sistem klien, koneksi dari klien yang sama mungkin didistribusikan ke VM backend yang sama lebih sering daripada yang Anda harapkan.

  Secara praktis, ini berarti Anda tidak dapat memantau distribusi traffic secara akurat melalui Load Balancer Jaringan passthrough internal dengan menghubungkannya dari satu klien. Jumlah klien yang diperlukan untuk memantau distribusi traffic bervariasi bergantung pada jenis load balancer, jenis traffic, dan jumlah backend yang sehat.

• Jika VM klien adalah VM backend load balancer, koneksi yang dikirim ke alamat IP aturan penerusan load balancer selalu dijawab oleh VM klien/backend. Hal ini terjadi terlepas dari apakah VM backend responsif atau tidak. Hal ini terjadi untuk semua traffic yang dikirim ke alamat IP load balancer, bukan hanya traffic pada protokol dan port yang ditentukan dalam aturan penerusan internal load balancer.

  Untuk mengetahui informasi selengkapnya, lihat artikel mengirim permintaan dari VM yang di-load balanced.

Fragmentasi UDP

Load Balancer Jaringan passthrough internal dapat memproses paket UDP yang terfragmentasi dan tidak terfragmentasi. Jika aplikasi Anda menggunakan paket UDP yang terfragmentasi, perhatikan hal-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 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.

Failover

Load Balancer Jaringan passthrough internal memungkinkan Anda menetapkan beberapa backend sebagai backend failover. Backend ini hanya digunakan jika jumlah VM responsif di grup instance backend utama telah turun di bawah nilai minimum yang dapat dikonfigurasi. Secara default, jika semua VM utama dan failover tidak responsif, sebagai upaya terakhir, Google Cloud mendistribusikan koneksi baru hanya di antara semua VM utama.

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

Untuk ringkasan konseptual mendetail tentang failover di Load Balancer Jaringan passthrough internal, lihat Failover untuk Load Balancer Jaringan passthrough internal.

Kuota dan batas

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

Batasan

• Anda tidak dapat menggunakan Konsol Google Cloud untuk membuat Load Balancer Jaringan passthrough internal dengan backend NEG zonal.

Langkah selanjutnya

• Untuk mengonfigurasi dan menguji Load Balancer Jaringan passthrough internal, lihat Menyiapkan Load Balancer Jaringan passthrough internal.
• Untuk mengonfigurasi Cloud Monitoring bagi Load Balancer Jaringan passthrough internal, lihat Logging dan pemantauan Load Balancer Jaringan passthrough internal.
• Untuk memecahkan masalah pada Load Balancer Jaringan passthrough internal, lihat Memecahkan masalah Load Balancer Jaringan passthrough internal.