Ringkasan Load Balancer Jaringan passthrough eksternal berbasis layanan backend

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

Load Balancer Jaringan passthrough eksternal dapat menerima traffic dari:

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

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

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

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

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

    Dokumentasi GKE terkait:

Arsitektur

Diagram berikut mengilustrasikan komponen Load Balancer Jaringan passthrough eksternal:

Load Balancer Jaringan passthrough eksternal dengan layanan backend regional
Load Balancer Jaringan passthrough eksternal dengan layanan backend regional

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

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

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

Alamat IP

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

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

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

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

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

Aturan penerusan

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

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

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

  • Jika aturan penerusan merujuk ke alamat IPv4, aturan penerusan tidak akan dikaitkan dengan subnet mana pun. Artinya, alamat IP-nya berasal dari luar rentang subnet Google Cloud mana pun.

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

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

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

Protokol aturan penerusan

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

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

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

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

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

Tabel berikut merangkum cara menggunakan setelan ini untuk berbagai protokol.

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

Beberapa aturan penerusan

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

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

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

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

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

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

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

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

Pilihan aturan penerusan

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

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

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

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

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

    • Tetap ada satu aturan penerusan yang cocok dengan alamat IP, protokol, dan port tujuan paket, serta digunakan untuk merutekan paket.
    • Ada dua atau lebih kandidat aturan penerusan yang tetap cocok dengan alamat IP, protokol, dan port tujuan paket. Artinya, kandidat aturan penerusan yang tersisa mencakup aturan penerusan kemudi (dibahas di bagian berikutnya). Pilih aturan penerusan kemudi yang rentang sumber-nya mencakup CIDR paling spesifik (pencocokan awalan terpanjang) yang berisi alamat IP sumber paket. Jika tidak ada aturan penerusan pengarahan yang memiliki rentang sumber termasuk alamat IP sumber paket, pilih aturan penerusan induk.
    • Kandidat aturan penerusan tidak ada dan paket akan dihapus.

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

Pengarahan lalu lintas

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

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

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

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

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

Setiap aturan penerusan kemudi mengharuskan Anda membuat aturan penerusan induk terlebih dahulu. Aturan penerusan induk dan pengarah menggunakan alamat IP eksternal regional, protokol IP, dan informasi port yang sama; tetapi, aturan penerusan induk tidak memiliki informasi alamat IP sumber apa pun. Contoh:

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

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

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

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

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

Perilaku afinitas sesi di seluruh perubahan pengarahan

Bagian ini menjelaskan kondisi yang dapat menyebabkan afinitas sesi terganggu saat rentang IP sumber untuk aturan penerusan kemudi diupdate:

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

Mempertahankan afinitas sesi di seluruh perubahan pengarahan

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

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

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

Layanan backend regional

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

Setiap layanan backend menentukan parameter backend berikut:

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

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

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

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

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

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

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

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

    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.

Grup instance

Load Balancer Jaringan passthrough eksternal mendistribusikan koneksi antara VM backend yang terdapat dalam grup instance yang terkelola atau tidak terkelola. Grup instance dapat berupa cakupan regional atau zona.

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

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

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

    Contoh deployment menggunakan grup instance terkelola regional ditampilkan di sini. Grup instance memiliki template instance yang menetapkan cara penyediaan instance, dan setiap grup men-deploy instance dalam tiga zona region us-central1.

    Load Balancer Jaringan passthrough eksternal dengan grup instance terkelola regional
    Load Balancer Jaringan passthrough eksternal dengan grup instance terkelola regional

  • Grup instance yang dikelola zona atau tidak terkelola. Gunakan grup instance zona di zona yang berbeda (di region yang sama) untuk memberikan perlindungan dari potensi masalah di zona tertentu.

    Contoh deployment yang menggunakan grup instance zona ditampilkan di sini. Load balancer ini menyediakan ketersediaan di dua zona.

    Load Balancer Jaringan passthrough eksternal dengan grup instance zona
    Load Balancer Jaringan passthrough eksternal dengan grup instance zona

NEG Zona

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

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

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

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

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.

Layanan backend tidak dapat mendistribusikan traffic ke VM anggota grup instance pada antarmuka non-nic0. Jika ingin menerima traffic di antarmuka jaringan non-default (nic1 hingga nic7), Anda harus menggunakan NEG zona dengan endpoint GCE_VM_IP.

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.

Layanan backend dan jaringan VPC

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

Untuk mendistribusikan paket ke nic1 melalui nic7, Anda harus menggunakan backend NEG zona (dengan endpoint GCE_VM_IP) karena jaringan VPC yang terkait dengan grup instance selalu cocok dengan jaringan VPC yang digunakan oleh antarmuka nic0 dari semua instance anggota.

Backend stack ganda (IPv4 dan IPv6)

Jika Anda ingin load balancer mendukung traffic IPv6, backend harus memenuhi persyaratan berikut:

  • Backend harus dikonfigurasi dalam subnet stack dual yang berada di region yang sama dengan aturan penerusan IPv6 load balancer. Untuk backend, Anda dapat menggunakan subnet dengan ipv6-access-type yang ditetapkan ke EXTERNAL atau INTERNAL. Penggunaan subnet dengan ipv6-access-type yang ditetapkan ke INTERNAL mengharuskan Anda menggunakan subnet dual-stack terpisah dengan ipv6-access-type yang ditetapkan ke EXTERNAL untuk aturan penerusan eksternal load balancer. Untuk mengetahui petunjuknya, lihat Menambahkan subnet stack ganda.
  • Backend harus dikonfigurasi menjadi dual-stack dengan --ipv6-network-tier yang ditetapkan ke PREMIUM. Untuk mengetahui petunjuknya, lihat Membuat template instance dengan alamat IPv6.

Health check

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

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

Load Balancer Jaringan passthrough eksternal mendukung jenis health check berikut:

Health check untuk traffic protokol lainnya

Google Cloud tidak menawarkan health check khusus protokol selain yang tercantum di sini. Jika menggunakan Load Balancer Jaringan passthrough eksternal untuk melakukan load balancing pada protokol selain TCP, Anda tetap harus menjalankan layanan berbasis TCP di VM backend untuk memberikan informasi health check yang diperlukan.

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

Aturan firewall

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

Aturan penerusan dan kebijakan masuk memungkinkan aturan firewall atau kebijakan firewall hierarkis bekerja bersama dengan cara berikut: aturan penerusan menentukan protokol dan, jika ditentukan, persyaratan port yang harus dipenuhi sebuah paket untuk diteruskan ke VM backend. Aturan firewall mengizinkan firewall masuk mengontrol apakah paket yang diteruskan dikirim ke VM atau dihapus. Semua jaringan VPC memiliki aturan penolakan ingress tersirat yang memblokir paket masuk dari sumber mana pun. Jaringan VPC default Google Cloud mencakup sekumpulan aturan masuk dan izinkan firewall yang telah diisi sebelumnya.

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

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

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

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 IP eksternal yang terkait dengan VM Google Cloud atau alamat IP internet-routable dari sistem yang terhubung ke load balancer.
  • Tujuan: alamat IP dari aturan penerusan load balancer.

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, ESP, GRE, dan ICMP tidak memiliki koneksi. VM backend dapat mengirim paket respons yang alamat IP sumbernya cocok dengan alamat IP aturan penerusan atau cocok dengan alamat IP eksternal apa pun yang ditetapkan untuk VM tersebut. 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, ESP, GRE, ICMP Untuk sebagian besar kasus penggunaan, alamat IP dari aturan penerusan load balancer † Sumber paket yang meminta.

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

Jalur pengembalian

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

Load balancer menyimpan alamat IP sumber paket. Respons dari VM backend langsung dikirim ke klien, bukan melalui load balancer. Istilah industri untuk ini adalah direct server return.

Arsitektur VPC Bersama

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

Alamat IP Aturan penerusan Komponen backend
Alamat IP eksternal regional harus ditentukan dalam project yang sama dengan load balancer atau project host VPC Bersama. Aturan penerusan eksternal regional harus ditentukan dalam project yang sama dengan instance di layanan backend.

Layanan backend regional harus ditentukan dalam project dan region yang sama tempat backend (grup instance atau NEG zona) berada.

Health check yang terkait dengan layanan backend harus ditentukan dalam project yang sama dan region yang sama dengan layanan backend.

Distribusi traffic

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

  • Jika Anda belum mengonfigurasi failover, Load Balancer Jaringan passthrough eksternal akan mendistribusikan koneksi baru ke VM backend 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 eksternal akan mendistribusikan koneksi baru di antara VM backend yang responsif dalam kumpulan aktifnya, sesuai dengan kebijakan failover yang Anda konfigurasi. 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 menghentikan traffic.

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

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

Pemilihan backend dan pelacakan koneksi

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

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

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

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

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

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

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

      Selain itu, perhatikan hal-hal berikut:

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

      • Pertimbangkan layanan backend yang dikonfigurasi dengan afinitas sesi yang ditetapkan ke NONE dan aturan penerusan dengan protokol UDP. Jika ada dua backend instance responsif dengan bobot 1 dan 4, backend akan mendapatkan paket UDP masing-masing 20% dan 80%.
      • Pertimbangkan layanan backend yang dikonfigurasi dengan pelacakan koneksi dan afinitas sesi 3-tuple. Afinitas sesi adalah CLIENT_IP_PROTO dan mode pelacakan koneksi adalah PER_SESSION. Jika ada tiga instance backend yang responsif dengan bobot 0, 2, dan 6, backend akan mendapatkan traffic masing-masing sebesar 0%, 25%, dan 75% dari alamat IP sumber baru (alamat IP sumber yang tidak memiliki entri tabel pelacakan koneksi yang sudah ada). Traffic untuk koneksi yang ada akan diarahkan ke backend yang ditetapkan sebelumnya.

    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:

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

        Pelacakan koneksi 5 tuple default digunakan saat:

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

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

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

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

      Selain itu, perhatikan hal-hal berikut:

      • Masa berlaku entri dalam tabel pelacakan koneksi akan berakhir 60 detik setelah load balancer memproses paket terakhir yang cocok dengan entri tersebut. Nilai waktu tunggu tidak ada aktivitas selama 60 detik ini tidak dapat dikonfigurasi.
      • 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. Afinitas sesi ditetapkan untuk seluruh layanan backend eksternal regional, bukan per backend.

Load Balancer Jaringan passthrough eksternal mendukung opsi afinitas sesi berikut:

  • Tidak ada (NONE). Hash 5 tuple untuk alamat IP sumber, port sumber, protokol, alamat IP tujuan, dan port tujuan
  • IP Klien, IP Tujuan (CLIENT_IP). Hash 2 tuple untuk alamat IP sumber dan alamat IP tujuan
  • IP Klien, IP Tujuan, Protokol (CLIENT_IP_PROTO). Hash 3 tuple 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

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

Mode pelacakan koneksi

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

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

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

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

Pemilihan backend Mode pelacakan koneksi
Setelan afinitas sesi Metode hash untuk pemilihan backend PER_CONNECTION (default) PER_SESSION
Default: Tidak ada afinitas sesi

(NONE)

TCP dan UDP yang tidak terfragmentasi: Hash 5-tuple

UDP terfragmentasi dan semua protokol lainnya: Hash 3-tuple
  • TCP: Pelacakan koneksi 5-tuple
  • Semua protokol lainnya: pelacakan koneksi nonaktif
  • TCP: Pelacakan koneksi 5-tuple
  • Semua protokol lainnya: pelacakan koneksi nonaktif
IP Klien, IP Tujuan

(CLIENT_IP)

 Semua protokol: Hash 2-tuple
  • TCP dan UDP yang tidak terfragmentasi: Pelacakan koneksi 5 tuple
  • UDP, ESP, dan GRE yang terfragmentasi: Pelacakan koneksi 3-tuple
  • Semua protokol lainnya: pelacakan koneksi nonaktif
  • TCP, UDP, ESP, GRE: Pelacakan koneksi 2-tuple
  • Semua protokol lainnya: pelacakan koneksi nonaktif
IP Klien, IP Tujuan, Protokol

(CLIENT_IP_PROTO)

 Semua protokol: Hash 3-tuple
  • TCP dan UDP yang tidak terfragmentasi: Pelacakan koneksi 5 tuple
  • UDP, ESP, dan GRE yang terfragmentasi: Pelacakan koneksi 3-tuple
  • Semua protokol lainnya: pelacakan koneksi nonaktif
  • TCP, UDP, ESP, GRE: Pelacakan koneksi 3-tuple
  • Semua protokol lainnya: pelacakan koneksi nonaktif
IP Klien, Port Klien, IP Tujuan, Port Tujuan, Protokol

(CLIENT_IP_PORT_PROTO)

TCP dan UDP yang tidak terfragmentasi: Hash 5-tuple

UDP terfragmentasi dan semua protokol lainnya: Hash 3-tuple
  • TCP dan UDP yang tidak terfragmentasi: Pelacakan koneksi 5 tuple
  • UDP, ESP, dan GRE yang terfragmentasi: Pelacakan koneksi 3-tuple
  • Semua protokol lainnya: pelacakan koneksi nonaktif
  • TCP dan UDP yang tidak terfragmentasi: Pelacakan koneksi 5 tuple
  • UDP, ESP, dan GRE yang terfragmentasi: Pelacakan koneksi 3-tuple
  • Semua protokol lainnya: pelacakan koneksi nonaktif

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

Persistensi koneksi pada backend yang tidak responsif

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

Perilaku yang dijelaskan di bagian ini tidak berlaku untuk kasus ketika Anda menghapus instance backend dari grup instance, menghapus endpoint backend dari NEG-nya, atau menghapus grup instance atau NEG dari layanan backend. Dalam kasus tersebut, koneksi yang dibuat hanya akan dipertahankan seperti yang dijelaskan dalam 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)

Semua protokol lainnya: 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

Semua protokol lainnya: koneksi tidak pernah ada di backend yang tidak responsif
NEVER_PERSIST Semua protokol: koneksi tidak pernah ada di backend yang tidak responsif
ALWAYS_PERSIST

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

ESP, GRE, UDP: koneksi akan tetap ada di backend yang tidak responsif jika afinitas sesi tidak NONE

ICMP, ICMPv6: tidak berlaku karena tidak dapat dilacak koneksinya

Opsi ini hanya boleh digunakan untuk kasus penggunaan lanjutan.

 Konfigurasi tidak dimungkinkan

Perilaku persistensi koneksi TCP pada backend yang tidak responsif

Setiap kali koneksi TCP dengan pelacakan 5-tuple terus berlanjut di backend yang tidak responsif:

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

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

Load balancing berbobot

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

Load balancing berbobot mengharuskan Anda mengonfigurasi kedua hal berikut:

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

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

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

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

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

Load balancing berbobot dapat digunakan dalam skenario berikut:

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

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

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

Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi load balancing berbobot.

Pengosongan koneksi

Pengosongan koneksi adalah proses yang diterapkan pada koneksi yang tersambung dalam kasus berikut:

  • VM atau endpoint dihapus dari backend (grup instance atau NEG).
  • Backend menghapus VM atau endpoint (dengan penggantian, pengabaikan, saat meluncurkan upgrade, atau memperkecil skala).
  • Backend dihapus dari layanan backend.

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

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

Fragmentasi UDP

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

  • Paket UDP mungkin 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 atau L3_DEFAULT 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.

Menggunakan instance target sebagai backend

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

Failover

Anda dapat mengonfigurasi Load Balancer Jaringan passthrough eksternal untuk mendistribusikan koneksi antara instance atau endpoint VM di backend utama (grup instance atau NEG), lalu beralih, jika perlu, ke backend failover. Failover memberikan metode lain untuk meningkatkan ketersediaan, sekaligus memberi Anda kontrol yang lebih besar terkait cara mengelola beban kerja saat backend utama Anda tidak responsif.

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

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

Batasan

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

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

    Gunakan Google Cloud CLI atau REST API saja.

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

Langkah selanjutnya