Ringkasan Load Balancer Jaringan passthrough eksternal berbasis layanan backend

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

Load Balancer Jaringan passthrough eksternal dapat menerima traffic dari:

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

Load Balancer Jaringan passthrough eksternal bukan proxy. Load balancer itu sendiri tidak menghentikan koneksi pengguna. Paket yang di-load balanced dikirim ke VM backend dengan alamat IP sumber dan tujuan, protokol, dan, jika berlaku, port, tanpa perubahan. VM backend kemudian akan menghentikan koneksi pengguna. Respons dari VM backend langsung menuju 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 dan keandalan yang lebih baik dibandingkan dengan grup instance yang tidak dikelola.
  • Backend NEG zona. Load Balancer Jaringan passthrough eksternal berbasis layanan backend mendukung penggunaan NEG zonal dengan endpoint GCE_VM_IP. Endpoint GCE_VM_IP NEG Zona memungkinkan Anda melakukan hal berikut:
    • Teruskan paket ke antarmuka jaringan apa pun, bukan hanya nic0.
    • Tempatkan endpoint GCE_VM_IP yang sama di dua NEG zona atau lebih yang terhubung ke layanan backend yang berbeda.
  • Dukungan untuk beberapa protokol. Load Balancer Jaringan passthrough eksternal berbasis layanan backend dapat melakukan load balancing traffic TCP, UDP, ESP, GRE, ICMP, dan ICMPv6.
  • Dukungan untuk konektivitas IPv6. Load Balancer Jaringan passthrough eksternal berbasis layanan backend dapat menangani traffic IPv4 dan IPv6.
  • Kontrol distribusi traffic yang terperinci. Layanan backend memungkinkan traffic didistribusikan sesuai dengan afinitas sesi yang dikonfigurasi, kebijakan pelacakan koneksi, dan setelan load balancing berbobot. Layanan backend juga dapat dikonfigurasi untuk mengaktifkan pengosongan koneksi dan menetapkan backend failover untuk load balancer. Sebagian besar setelan ini memiliki nilai default yang memungkinkan Anda memulai dengan cepat. Untuk mengetahui informasi selengkapnya, lihat Distribusi traffic untuk Load Balancer Jaringan passthrough eksternal.
  • Dukungan untuk health check non-legacy. Load Balancer Jaringan passthrough eksternal berbasis layanan backend memungkinkan Anda menggunakan health check yang cocok dengan jenis traffic (TCP, SSL, HTTP, HTTPS, atau HTTP/2) yang didistribusikan.
  • Integrasi Google Cloud Armor. Google Cloud Armor mendukung perlindungan DDoS jaringan tingkat lanjut untuk Load Balancer Jaringan passthrough eksternal. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi perlindungan DDoS jaringan lanjutan.

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

    Dokumentasi GKE terkait:

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 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 traffic load balancing dan pemeriksaan health check menjangkau VM backend.

Alamat IP

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

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

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

Aturan penerusan

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

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

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

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

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

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

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

Protokol aturan penerusan

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

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

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

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

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

Tabel berikut merangkum cara menggunakan setelan ini untuk protokol yang berbeda.

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

Beberapa aturan penerusan

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

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

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

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

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

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

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

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

Pemilihan aturan penerusan

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

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

  • Menghapus aturan penerusan yang port-nya tidak cocok dengan port paket. Aturan penerusan yang dikonfigurasi untuk semua port tidak pernah dihapus oleh langkah ini karena aturan penerusan semua port cocok dengan port apa pun.

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

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

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

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

Pengendalian traffic

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

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

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

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

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

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

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

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

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

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

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

Perilaku afinitas sesi di seluruh perubahan kemudi

Bagian ini menjelaskan kondisi saat afinitas sesi dapat rusak saat rentang IP sumber untuk aturan penerusan kemudi diperbarui:

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

Mempertahankan afinitas sesi di seluruh perubahan kemudi

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

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

Untuk mengetahui petunjuk tentang cara mengonfigurasi pengalihan traffic, lihat Mengonfigurasi pengalihan traffic.

Layanan backend regional

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

Setiap layanan backend menentukan parameter backend berikut:

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

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

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

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

  • Distribusi traffic. Layanan backend memungkinkan traffic didistribusikan sesuai dengan afinitas sesi yang dikonfigurasi, kebijakan pelacakan koneksi, dan setelan load balancing berbobot. Layanan backend juga dapat dikonfigurasi untuk mengaktifkan pengosongan koneksi dan menetapkan backend failover untuk load balancer. Sebagian besar setelan ini memiliki nilai default yang memungkinkan Anda memulai dengan cepat. Untuk mengetahui informasi selengkapnya, lihat Distribusi traffic untuk Load Balancer Jaringan passthrough eksternal.

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

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

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

    Setiap backend grup instance atau NEG memiliki jaringan VPC terkait, meskipun grup instance atau NEG tersebut belum terhubung ke layanan backend. Untuk mengetahui informasi selengkapnya tentang cara jaringan dikaitkan dengan setiap jenis backend, lihat Backend grup instance dan antarmuka jaringan serta Backend NEG zonal dan antarmuka jaringan.

Grup instance

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

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

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

Load Balancer Jaringan passthrough eksternal sangat tersedia karena desainnya. Tidak ada langkah khusus yang diperlukan untuk membuat load balancer memiliki ketersediaan tinggi karena mekanismenya tidak bergantung pada satu perangkat atau instance VM. Anda hanya perlu memastikan bahwa instance VM backend di-deploy ke beberapa zona sehingga load balancer dapat mengatasi potensi masalah di zona tertentu.

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

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

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

  • Grup instance terkelola atau tidak terkelola menurut zona. Gunakan grup instance zonal di zona yang berbeda (di region yang sama) untuk melindungi dari potensi masalah di zona tertentu.

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

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

NEG Zona

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

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

NEG zonal mendukung VM IPv4 dan dual-stack (IPv4 dan IPv6). Untuk VM IPv4 dan dual-stack, cukup tentukan instance VM 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 zonal memiliki jaringan VPC dan subnet terkait, meskipun NEG zonal tersebut belum terhubung ke layanan backend. Untuk mengetahui informasi selengkapnya tentang cara jaringan dikaitkan dengan NEG zonal, lihat Backend NEG zonal dan antarmuka jaringan.

Antarmuka jaringan dan backend grup instance

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

  • Untuk grup instance terkelola (MIG), jaringan VPC untuk grup instance ditentukan dalam template instance.
  • Untuk grup instance tidak terkelola, jaringan VPC untuk grup instance ditentukan sebagai jaringan VPC yang digunakan oleh antarmuka jaringan nic0 instance VM pertama yang Anda tambahkan ke grup instance tidak terkelola.

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

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

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.

Layanan backend dan jaringan VPC

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

Untuk mendistribusikan paket ke antarmuka non-nic0, Anda harus menggunakan backend NEG zona (dengan endpoint GCE_VM_IP).

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 disetel ke EXTERNAL atau INTERNAL. Jika ipv6-access-type subnet backend ditetapkan ke INTERNAL, Anda harus menggunakan subnet khusus IPv6 yang berbeda dengan ipv6-access-type ditetapkan ke EXTERNAL untuk aturan penerusan eksternal load balancer.
  • 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 petunjuknya, 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 INTERNAL, Anda harus menggunakan subnet khusus IPv6 yang berbeda dengan ipv6-access-type ditetapkan ke EXTERNAL untuk aturan penerusan eksternal 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 petunjuknya, 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.

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 Google Cloud health check, 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 bagian Health check, sebelumnya di halaman ini. Saat 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 traffic UDP, permintaan klien akan di-load balance menggunakan protokol UDP, dan Anda harus menjalankan layanan TCP untuk memberikan informasi ke Google Cloud prober health check. Untuk melakukannya, Anda dapat menjalankan server HTTP di setiap VM backend yang menampilkan respons HTTP 200 ke prober pemeriksaan kesehatan. Anda harus menggunakan logika Anda sendiri yang berjalan di VM backend untuk memastikan bahwa server HTTP menampilkan 200 hanya jika layanan UDP dikonfigurasi dan berjalan dengan benar.

Aturan firewall

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

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

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

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

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

Alamat IP untuk paket permintaan dan pengembalian

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

  • Sumber: alamat IP eksternal yang terkait dengan VM Google Cloud atau alamat IP yang dapat dirutekan internet dari sistem yang terhubung ke load balancer.
  • Tujuan: alamat IP aturan penerusan load balancer.

Karena load balancer adalah load balancer pass-through (bukan proxy), paket akan tiba dengan alamat IP tujuan dari aturan penerusan load balancer. Software yang berjalan di VM backend harus dikonfigurasi untuk melakukan hal berikut:

  • Memproses (mengikat ke) alamat IP aturan penerusan load balancer atau alamat IP apa pun (0.0.0.0 atau ::)
  • Jika protokol aturan penerusan load balancer mendukung port: Dengarkan (ikat ke) port yang disertakan dalam aturan penerusan load balancer

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

  • TCP berorientasi pada koneksi sehingga VM backend harus membalas dengan paket yang alamat IP sumbernya cocok dengan alamat IP aturan penerusan sehingga klien dapat mengaitkan paket respons dengan koneksi TCP yang sesuai.
  • UDP, ESP, GRE, dan ICMP bersifat connectionless. VM backend dapat mengirim paket respons yang alamat IP sumbernya cocok dengan alamat IP aturan penerusan atau cocok dengan alamat IP eksternal yang ditetapkan untuk VM. Secara praktis, sebagian besar klien mengharapkan respons berasal dari alamat IP yang sama dengan alamat IP tempat mereka mengirim paket.

Tabel berikut merangkum sumber dan tujuan untuk paket respons:

Jenis traffic Sumber Tujuan
TCP Alamat IP aturan penerusan load balancer Sumber paket yang meminta
UDP, ESP, GRE, ICMP Untuk sebagian besar kasus penggunaan, alamat IP aturan penerusan load balancer † Sumber paket yang meminta.

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

Jalur kembali

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

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

Koneksi internet keluar dari backend

Instance VM yang dikonfigurasi sebagai endpoint backend Network Load Balancer passthrough eksternal dapat memulai koneksi ke internet menggunakan alamat IP aturan penerusan load balancer sebagai alamat IP sumber koneksi keluar.

Umumnya, instance VM selalu menggunakan alamat IP eksternalnya sendiri atau Cloud NAT untuk memulai koneksi. Anda menggunakan alamat IP aturan penerusan untuk memulai koneksi dari endpoint backend hanya dalam skenario khusus seperti saat Anda memerlukan instance VM untuk memulai dan menerima koneksi di alamat IP eksternal yang sama, dan Anda juga memerlukan redundansi backend yang disediakan oleh Load Balancer Jaringan passthrough eksternal untuk koneksi masuk.

Paket keluar yang dikirim dari VM backend langsung ke internet tidak memiliki batasan pada protokol dan port traffic. Meskipun paket keluar menggunakan alamat IP aturan penerusan sebagai sumber, protokol dan port sumber paket tidak harus cocok dengan spesifikasi port dan protokol aturan penerusan. Namun, paket respons masuk harus cocok dengan alamat IP, protokol, dan port tujuan aturan penerusan. Untuk mengetahui informasi selengkapnya, lihat Jalur untuk Load Balancer Jaringan passthrough eksternal dan penerusan protokol eksternal.

Selain itu, setiap respons terhadap koneksi keluar VM tunduk pada load balancing, seperti semua paket masuk lainnya yang ditujukan untuk load balancer. Artinya, respons mungkin tidak muncul di VM backend yang sama yang memulai koneksi ke internet. Jika koneksi keluar dan koneksi masuk load-balanced menggunakan protokol dan port yang sama, Anda dapat mencoba salah satu sugesti berikut:

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

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

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

Arsitektur VPC Bersama

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

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

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

Pemeriksaan kesehatan yang terkait dengan layanan backend harus ditentukan dalam project dan region yang sama dengan layanan backend.

Distribusi traffic

Load Balancer Jaringan passthrough eksternal mendukung berbagai opsi penyesuaian distribusi traffic, termasuk afinitas sesi, pelacakan koneksi, load balancing berbobot, dan failover. Untuk mengetahui detail tentang cara Load Balancer Jaringan passthrough eksternal mendistribusikan traffic, dan cara opsi ini berinteraksi satu sama lain, lihat Distribusi traffic untuk Load Balancer Jaringan passthrough eksternal.

Batasan

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

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

    Sebagai gantinya, gunakan Google Cloud CLI atau REST API.

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

Harga

Untuk mengetahui informasi harga, lihat Harga.

Langkah berikutnya