Ringkasan Load Balancer Jaringan passthrough internal

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

Load Balancer Jaringan passthrough internal mendistribusikan traffic ke instance virtual machine (VM) internal di region yang sama di jaringan Virtual Private Cloud (VPC). Dengan API ini, Anda dapat menjalankan dan menskalakan layanan melalui 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 keadaan berikut:

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

Load Balancer Jaringan passthrough internal menangani banyak kasus penggunaan. Untuk beberapa contoh tingkat tinggi, 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 GCE_VM_IP NEG zona sebagai backend di layanan backend. Contoh ini menunjukkan backend grup instance.

Contoh Load Balancer Jaringan passthrough internal tingkat tinggi.
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 responsif, tanpa gangguan. Respons dari VM backend yang responsif akan langsung dikirim ke klien, bukan melalui load balancer. Respons TCP menggunakan fungsi return server langsung. Untuk mengetahui informasi selengkapnya, lihat paket pengembalian dan permintaan TCP dan UDP.

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

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

Virtual networking Google Cloud mengelola pengiriman dan penskalaan traffic sebagaimana mestinya.

Protokol, skema, dan ruang lingkup

Setiap Load Balancer Jaringan passthrough internal mendukung hal berikut:

  • Satu layanan backend dengan skema load balancing INTERNAL dan protokol yang didukung. Untuk informasi selengkapnya, lihat layanan backend.
  • VM backend yang ditentukan sebagai salah satu dari yang berikut ini:
  • 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, berarti klien di region mana pun.
  • Jika akses global dinonaktifkan, berarti klien berada di region yang sama dengan load balancer.

Load Balancer Jaringan passthrough internal tidak mendukung:

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 untuk mengakses Load Balancer Jaringan passthrough internal Anda.

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

Tabel berikut meringkas akses klien.

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

Alamat IP untuk paket permintaan dan pengembalian

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

  • Sumber: alamat IPv4, IPv6, atau IPv4 internal klien dari salah satu rentang IPv4 alias klien.
  • Tujuan: alamat IP dari 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 masuk yang memuat alamat IP tujuan dari aturan penerusan load balancer. Software yang berjalan di VM backend harus dikonfigurasi untuk melakukan hal berikut:

  • Memproses (mengikat) alamat IP aturan penerusan load balancer atau setiap alamat IP (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 yang ditampilkan dikirim langsung dari VM backend load balancer ke klien. Alamat IP sumber dan tujuan paket yang dikembalikan 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 apa pun yang ditetapkan untuk VM. Secara praktis, sebagian besar klien mengharapkan respons berasal dari alamat IP yang sama 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 dari 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 tujuan pengiriman 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 zona, tetapi tidak bisa kombinasi keduanya, sebagai backend untuk Load Balancer Jaringan passthrough internal:

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

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

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 menyediakan 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 yang 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 yang menayangkan akan 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 sudah 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 di 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 merupakan frontend dari load balancer. Atribut ini menentukan protokol dan port yang diterima load balancer, serta 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 dari layanan backend.
• Mereferensikan subnet di jaringan dan region VPC yang sama dengan layanan backend.
Layanan backend internal regional Layanan backend internal regional menentukan protokol yang digunakan untuk berkomunikasi dengan backend, dan menetapkan 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 aturan penerusan.
• Memiliki health check terkait.
• Memiliki wilayah terkait. Aturan penerusan dan semua backend harus berada di region yang sama dengan layanan backend
• Dikaitkan dengan jaringan VPC tunggal. Jika tidak ditentukan, jaringan akan disimpulkan berdasarkan jaringan yang digunakan oleh setiap antarmuka jaringan default VM backend (nic0).

Meskipun layanan backend tidak terikat ke subnet tertentu, subnet aturan penerusan harus berada di jaringan VPC yang sama dengan layanan backend.
Health check Setiap layanan backend harus memiliki health check terkait. Health check menentukan parameter yang digunakan Google Cloud untuk menganggap backend yang dikelolanya 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:

Alamat IP internal

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

Load Balancer Jaringan passthrough internal memerlukan setidaknya satu aturan penerusan. Aturan penerusan merujuk ke alamat IP internal:

  • Untuk traffic IPv4, aturan penerusan merujuk ke alamat IPv4 dari rentang subnet IPv4 utama.
  • Untuk traffic IPv6, aturan penerusan merujuk pada rentang /96 alamat IPv6 internal dari rentang alamat IPv6 internal /64 pada 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:

Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi aturan firewall.

Aturan penerusan

Aturan penerusan menentukan protokol dan port tempat load balancer menerima traffic. Karena Load Balancer Jaringan passthrough internal bukan proxy, Load Balancer Jaringan 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 stack ganda. Ada kemungkinan bahwa IPv4 dan aturan penerusan IPv6 merujuk ke layanan backend yang sama, tetapi layanan backend harus mereferensikan backend stack ganda.

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

  • Subnet yang Anda tentukan untuk aturan penerusan tidak harus sama dengan subnet apa pun 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 (yang dicadangkan).
  • Untuk traffic IPv6, aturan penerusan merujuk pada rentang /96 alamat IPv6 dari rentang alamat IPv6 internal subnet. Subnet harus berupa subnet dual stack dengan ipv6-access-type yang ditetapkan ke INTERNAL. Rentang alamat IPv6 /96 akan 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 untuk protokol TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH, dan GRE.

Selain mendukung protokol selain TCP dan UDP, opsi L3_DEFAULT memungkinkan satu aturan penerusan dapat meneruskan traffic secara bersamaan untuk beberapa protokol. Misalnya, selain membuat permintaan HTTP, Anda juga dapat melakukan 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 yang 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 berbagai protokol:

Traffic yang akan di-load balanced 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, tanda allowGlobalAccess aturan penerusan internal regional akan ditetapkan ke true.

Aturan penerusan dan spesifikasi port

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

  • Tentukan minimal satu hingga lima port, berdasarkan angka.
  • 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 port-nya sendiri. Traffic yang dikirim ke port tertentu akan dikirimkan 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 Anda 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 kembali.

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 setidaknya 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 sekumpulan port tertentu, menggunakan alamat IP yang sama, ke load balancer. Anda dapat membuat beberapa aturan penerusan yang menggunakan alamat IP yang sama, dengan setiap aturan penerusan menggunakan kumpulan spesifik hingga lima port. Ini adalah alternatif untuk mengonfigurasi aturan penerusan tunggal yang menentukan semua port.

Untuk mengetahui informasi selengkapnya tentang skenario yang melibatkan dua atau beberapa aturan penerusan internal yang memiliki alamat IP internal yang sama, baca artikel 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 semua alamat IP aturan penerusan atau ke alamat mana 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 mengetahui informasi selengkapnya, lihat paket pengembalian dan permintaan TCP dan UDP.

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 mengirimkan paket ke VM backend pada port tujuan yang sama dengan yang dikirimi 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 dapat berupa grup instance atau NEG zona dengan GCE_VM_IP endpoint yang terletak di region yang sama dengan layanan backend dan aturan penerusan. Backend grup instance dapat berupa grup instance yang tidak dikelola, grup instance terkelola menurut zona, atau grup instance yang dikelola regional. Backend NEG zona harus menggunakan endpoint GCE_VM_IP.

  • Satu jaringan VPC. Setiap grup instance atau backend NEG memiliki jaringan VPC terkait, meskipun grup instance atau NEG tersebut belum terhubung ke layanan backend. Untuk mengetahui informasi selengkapnya tentang cara mengaitkan jaringan dengan setiap jenis backend, lihat backend grup instance dan antarmuka jaringan serta backend NEG Zona dan antarmuka jaringan. Resource layanan backend itu sendiri juga memiliki jaringan VPC terkait, yang dapat ditentukan secara eksplisit atau implisit. Untuk mengetahui informasi selengkapnya tentang jaringan layanan backend, lihat Spesifikasi jaringan layanan backend dan Aturan jaringan layanan backend.

Backend grup instance dan antarmuka jaringan

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

  • Untuk grup instance terkelola (MIG), jaringan VPC untuk grup instance ditentukan dalam template instance.
  • Untuk grup instance yang tidak dikelola, jaringan VPC untuk grup instance ditetapkan sebagai jaringan VPC yang digunakan oleh antarmuka jaringan nic0 dari 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 dalam jaringan VPC yang sama. Secara opsional, setiap VM anggota dapat memiliki antarmuka jaringan tambahan (nic1 hingga nic7), tetapi setiap antarmuka jaringan harus terhubung ke jaringan VPC yang berbeda. Jaringan ini juga harus berbeda dari jaringan VPC yang terkait dengan grup instance.

Backend NEG zona dan antarmuka jaringan

Saat membuat NEG zona baru dengan endpoint GCE_VM_IP, Anda harus secara eksplisit mengaitkan NEG dengan subnetwork 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 endpoint dalam 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 mengharuskan VM memiliki antarmuka jaringan di subnetwork yang terkait dengan NEG. Alamat IP yang dipilih Google Cloud untuk endpoint adalah alamat IPv4 internal utama antarmuka jaringan VM di subnetwork 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 penentuan alamat IP adalah hal yang berlebihan karena hanya boleh ada satu antarmuka jaringan yang ada di subnetwork yang terkait dengan NEG.

Spesifikasi jaringan layanan backend

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

Jika Anda menghapus flag --network saat membuat layanan backend, Google Cloud akan menggunakan salah satu peristiwa kualifikasi berikut untuk secara implisit menetapkan jaringan VPC terkait layanan backend. Setelah ditetapkan, jaringan VPC yang terkait dengan 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 tersebut 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 yang terkait dengan 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, semua aturan penerusan tambahan, grup instance backend, atau NEG zona 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 terpenuhi:

    • Jaringan VPC yang terkait dengan grup instance—yaitu, jaringan VPC yang digunakan oleh antarmuka jaringan nic0 dari setiap VM di grup instance—harus cocok dengan jaringan VPC yang terkait dengan 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 zona dengan endpoint GCE_VM_IP, jaringan VPC yang terkait dengan NEG harus cocok dengan jaringan VPC yang terkait dengan layanan backend.

Subsetelan backend

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

Anda hanya boleh mengaktifkan subset 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 yang 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 menyalurkan 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. Menyajikan traffic jenis HTTP melalui Load Balancer Jaringan passthrough internal berarti bahwa protokol load balancer adalah TCP.
  • SSL atau TCP. Jika VM backend Anda tidak menyalurkan traffic jenis HTTP, Anda harus menggunakan health check SSL atau TCP.

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

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 balanced menggunakan protokol UDP, dan layanan TCP digunakan untuk memberikan informasi kepada petugas health check 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 berdasarkan desain. Tidak ada langkah-langkah khusus untuk membuat load balancer menjadi sangat tersedia karena mekanismenya tidak bergantung pada satu perangkat atau instance VM.

Untuk memastikan bahwa 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, yang memberikan opsi terbaik untuk menghindari potensi masalah di zona tertentu.

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

Arsitektur VPC Bersama

Tabel berikut merangkum persyaratan komponen untuk Load Balancer Jaringan passthrough internal yang digunakan dengan jaringan VPC Bersama. Sebagai contoh, 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 dalam project layanan yang sama tempat VM backend berada, dan harus merujuk subnet di jaringan VPC Bersama yang diinginkan dalam project host. Alamat itu sendiri berasal dari rentang IP utama dari subnet yang dirujuk.

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 akan bersifat lokal untuk project layanan. Ini bukan 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 tempat VM backend berada, dan harus merujuk pada subnet yang sama (dalam jaringan VPC Bersama) yang digunakan sebagai referensi alamat IP internal terkait.

Jika Anda membuat aturan penerusan internal dalam project layanan dan subnet aturan penerusan berada di jaringan VPC project layanan, Load Balancer Jaringan passthrough internal Anda akan bersifat lokal untuk project layanan tersebut. Ini bukan 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, Load Balancer Jaringan passthrough internal akan mendistribusikan koneksi baru ke VM backend yang responsif jika setidaknya satu VM backend responsif. Jika semua VM backend tidak responsif, load balancer 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 mendistribusikan traffic hanya ke VM utama. Hal ini dilakukan sebagai upaya terakhir. VM cadangan dikecualikan dari distribusi koneksi terakhir ini.
    • Load balancer dikonfigurasi untuk mengurangi traffic.

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

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

Pemilihan backend dan pelacakan koneksi

Load Balancer Jaringan passthrough internal menggunakan pemilihan backend yang dapat dikonfigurasi dan algoritma pelacakan koneksi 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. Metode ini menggunakan hash ini untuk memilih backend:

      • Jika setidaknya satu backend responsif, hash akan memilih salah satu backend yang responsif.
      • Jika semua backend tidak responsif, dan tidak ada kebijakan failover 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

      Pemilihan backend dapat disesuaikan 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 akan mencatat backend yang dipilih untuk koneksi paket sehingga semua paket mendatang dari koneksi ini akan dikirim ke backend yang sama. Apakah pelacakan koneksi digunakan atau tidak 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 agar kurang dari 5 tuple.

      Jika hash pelacakan koneksi memiliki 5 tuple, paket TCP SYN selalu membuat entri baru dalam tabel pelacakan koneksi.

      Pelacakan koneksi 5 tuple default digunakan saat:

      • mode pelacakan adalah PER_CONNECTION (semua afinitas sesi), atau,
      • mode pelacakannya adalah PER_SESSION dan afinitas sesinya adalah NONE, atau,
      • mode pelacakannya adalah PER_SESSION dan afinitas sesinya 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, entri dalam tabel pelacakan koneksi akan berakhir 600 detik setelah load balancer memproses paket terakhir yang cocok dengan entri tersebut. Untuk mengetahui detail tentang cara menyesuaikan waktu tunggu tidak ada aktivitas, lihat Waktu tunggu tidak ada aktivitas.
      • Bergantung pada protokolnya, load balancer dapat menghapus entri tabel pelacakan koneksi saat backend menjadi tidak responsif. Untuk mengetahui detail dan cara menyesuaikan perilaku ini, lihat Persistensi koneksi pada backend yang tidak responsif.

Opsi minat sesi

Afinitas sesi mengontrol distribusi koneksi baru dari klien ke VM backend load balancer. Anda menetapkan afinitas sesi saat VM backend Anda perlu melacak informasi status untuk kliennya. Ini adalah persyaratan umum untuk aplikasi web.

Afinitas sesi bekerja 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 untuk alamat IP sumber, port sumber, protokol, alamat IP tujuan, dan port tujuan
  • IP klien, tanpa tujuan (CLIENT_IP_NO_DESTINATION). Hash 1-tuple dibuat hanya dari alamat IP sumber.
  • IP Klien (CLIENT_IP). Hash 2 tuple untuk alamat IP sumber dan alamat IP tujuan. Load Balancer Jaringan passthrough eksternal memanggil opsi afinitas sesi ini dengan IP Klien, IP Tujuan.
  • IP Klien, IP Tujuan, Protokol (CLIENT_IP_PROTO). Hash 3 tuple untuk alamat IP sumber, alamat IP tujuan, dan protokol
  • IP Klien, Port Klien, IP Tujuan, Port Tujuan, Protokol (CLIENT_IP_PORT_PROTO). Hash 5 tuple 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. Sebagai pertimbangan saat menggunakan load balancer sebagai next hop untuk rute statis kustom, Afinitas sesi dan next hop internal Load Balancer Jaringan.

Afinitas sesi dan next hop internal Load Balancer Jaringan

Saat menggunakan Load Balancer Jaringan passthrough internal sebagai next hop untuk rute statis kustom, tujuan paket kemungkinan besar bukan alamat IP dari aturan penerusan load balancer.

Paket dikirimkan ke load balancer jika tujuan paket sesuai dengan tujuan rute statis kustom dan rute statis kustom merupakan rute yang berlaku.

Semua opsi afinitas sesi kecuali IP Klien, tanpa tujuan menggunakan alamat IP tujuan paket. Saat menggunakan rute statis kustom yang next hopnya adalah Load Balancer Jaringan passthrough internal:

  • Jika load balancer hanya memiliki satu backend (kumpulan yang aktif, jika Anda telah mengonfigurasi failover), semua opsi afinitas sesi akan memilih backend tersebut. Pilihan afinitas sesi tidak ada bedanya jika ada satu backend (di kumpulan aktif).

  • Jika load balancer Anda memiliki lebih dari satu backend (dalam kumpulan aktifnya, jika Anda telah mengonfigurasi failover) dan Anda memilih opsi afinitas sesi kecuali IP Klien, tanpa tujuan, paket yang dikirim dari klien yang sama ke alamat IP mana pun di tujuan rute tidak dijamin akan diproses oleh backend yang sama. Hal ini karena hash afinitas sesi dihitung dari informasi yang juga menyertakan alamat IP tujuan paket, yang dapat berupa alamat apa pun dalam rentang tujuan rute.

  • Jika Anda perlu menjamin bahwa backend yang sama memproses semua paket yang dikirim dari klien yang sama ke alamat IP apa pun di tujuan rute, Anda harus menggunakan opsi afinitas sesi IP Klien, tanpa tujuan.

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. Ini menyiratkan bahwa kunci untuk pelacakan koneksi (5-tuple) dapat berbeda dengan setelan afinitas sesi yang dikonfigurasi (misalnya, 3-tuple dengan setelan CLIENT_IP_PROTO). Akibatnya, afinitas sesi dapat dipisah dan koneksi baru untuk sesi dapat memilih backend yang berbeda jika kumpulan backend atau kesehatannya 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 afinitas yang rusak mahal dan harus dihindari bahkan setelah lebih banyak backend ditambahkan.

Setelan mode pelacakan koneksi bersifat redundan jika afinitas sesi ditetapkan 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 seperti 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 pada backend yang tidak responsif

Persistensi koneksi pada setelan backend yang tidak responsif mengontrol apakah koneksi yang ada tetap ada di backend yang dipilih setelah backend tersebut menjadi tidak responsif (selama backend tersebut tetap berada dalam grup instance backend yang dikonfigurasi load balancer).

Perilaku yang dijelaskan di bagian ini tidak berlaku untuk kasus saat Anda menghapus VM backend dari grup instance-nya, atau menghapus grup instance dari layanan backend. Dalam kasus tersebut, koneksi yang dibuat hanya akan dipertahankan seperti yang dijelaskan dalam Mengaktifkan pengurasan koneksi.

Opsi persistensi koneksi berikut tersedia:

  • DEFAULT_FOR_PROTOCOL (default)
  • NEVER_PERSIST
  • ALWAYS_PERSIST

Tabel berikut merangkum opsi persistensi koneksi dan cara koneksi dipertahankan 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 responsif (semua afinitas sesi)

UDP: koneksi tidak pernah ada di backend yang tidak responsif

TCP: koneksi akan tetap ada di backend yang tidak responsif jika afinitas sesi adalah NONE atau CLIENT_IP_PORT_PROTO

UDP: koneksi tidak pernah ada di backend yang tidak responsif
NEVER_PERSIST TCP, UDP: koneksi tidak pernah dipertahankan di backend yang tidak responsif
ALWAYS_PERSIST

TCP, UDP: koneksi akan tetap ada di backend yang tidak responsif (semua afinitas sesi)

Opsi ini hanya boleh digunakan untuk kasus penggunaan lanjutan.

 Konfigurasi tidak dimungkinkan

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

Waktu tunggu tidak ada aktivitas

Secara default, entri dalam tabel pelacakan koneksi akan berakhir 600 detik setelah load balancer memproses paket terakhir yang cocok dengan entri tersebut. Nilai waktu tunggu tidak ada aktivitas default ini hanya dapat diubah saat pelacakan koneksi kurang dari 5 tuple (yaitu, jika 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 memperhatikan hal-hal berikut:

  • Jika sistem klien bukan VM yang melakukan load balancing dan bukan merupakan VM backend, koneksi baru akan dikirim ke VM backend yang responsif dari load balancer. Namun, karena semua opsi afinitas sesi setidaknya mengandalkan alamat IP sistem klien, koneksi dari klien yang sama mungkin akan didistribusikan ke VM backend yang sama lebih sering daripada yang mungkin Anda harapkan.

    Dari segi kepraktisan, hal 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 responsif.

  • Jika VM klien adalah VM backend dari 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 di protokol dan port yang ditentukan dalam aturan penerusan internal load balancer.

    Untuk mengetahui informasi lebih lanjut, lihat mengirim permintaan dari VM dengan load balancing.

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 terfragmentasi sebelum mencapai jaringan VPC Google Cloud.
  • Jaringan VPC Google Cloud meneruskan fragmen UDP saat tiba (tanpa menunggu semua fragmen tiba).
  • Jaringan non-Google Cloud dan peralatan jaringan lokal dapat meneruskan fragmen UDP saat tiba, menunda paket UDP yang terfragmentasi hingga semua fragmen tiba, atau membuang paket UDP yang terfragmentasi. Untuk detailnya, lihat dokumentasi untuk penyedia jaringan atau peralatan jaringan.

Jika Anda mengharapkan paket UDP yang terfragmentasi dan perlu mengarahkannya 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 balanced, dan konfigurasikan aturan penerusan untuk menerima traffic di semua port. Cara ini memastikan bahwa semua fragmen sampai 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 akan 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: Setel 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 saat jumlah VM yang responsif di grup instance backend utama telah berada di bawah batas yang dapat dikonfigurasi. Secara default, jika semua VM utama dan failover tidak responsif, sebagai upaya terakhir, Google Cloud akan mendistribusikan koneksi baru hanya di antara semua VM utama.

Saat Anda menambahkan backend ke layanan backend Load Balancer Jaringan passthrough internal, secara default backend tersebut adalah backend utama. Anda dapat menetapkan backend untuk menjadi 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 melakukan tugas-tugas berikut:

    • Buat atau ubah Load Balancer Jaringan passthrough internal yang aturan penerusannya menggunakan protokol L3_DEFAULT.
    • Buat atau ubah Load Balancer Jaringan passthrough internal dengan protokol layanan backend yang ditetapkan ke UNSPECIFIED.
    • Membuat Load Balancer Jaringan passthrough internal dengan backend NEG zona.

Langkah selanjutnya