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 zona GCE_VM_IP 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 sehat, tanpa gangguan apa pun. Respons dari VM backend yang responsif akan langsung mengarah 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.

Google Cloud 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, 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 virtualGoogle 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:
  • 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:

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

Load Balancer Jaringan passthrough internal dengan akses global.
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 tempatnya mengirim paket permintaan.

Arsitektur

Load Balancer Jaringan passthrough internal dengan beberapa backend mendistribusikan koneksi di antara semua backend tersebut. Untuk mengetahui 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 tidak mendukung:

Alamat IP internal

Load Balancer Jaringan passthrough internal mendukung subnet khusus IPv4, dual-stack, dan khusus IPv6. Untuk mengetahui informasi selengkapnya tentang setiap jenis, 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 IPv6 khusus stack ganda atau satu stack (Pratinjau) dengan rentang alamat IPv6 internal (ipv6-access-type ditetapkan ke INTERNAL). Rentang alamat IPv6 dapat berupa alamat statis yang dicadangkan atau alamat sementara.

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

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 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 /64 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 kumpulan 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 tujuan pengiriman 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.

Antarmuka jaringan dan backend NEG zona

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 memerlukan 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 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 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 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 (misalnya, 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.

Backend stack ganda (IPv4 dan IPv6)

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

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

Backend khusus IPv6

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

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

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

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 Google Cloud pemeriksa kondisi. 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 zonal 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, Google Cloud alamat IP internal harus ditentukan di project layanan yang sama dengan tempat VM backend berada, 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

Load Balancer Jaringan passthrough internal mendukung berbagai opsi penyesuaian distribusi traffic, termasuk afinitas sesi, pelacakan koneksi, dan failover. Untuk mengetahui detail tentang cara Load Balancer Jaringan passthrough internal mendistribusikan traffic, dan cara opsi ini berinteraksi satu sama lain, lihat Distribusi traffic 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 berikutnya