Dokumen ini memperkenalkan konsep yang Anda perlukan untuk memahami cara mengonfigurasi Load Balancer Aplikasi eksternal.
Load Balancer Aplikasi eksternal adalah load balancer Lapisan 7 berbasis proxy yang memungkinkan Anda menjalankan dan menskalakan layanan melalui satu alamat IP eksternal. Load Balancer Aplikasi eksternal mendistribusikan traffic HTTP dan HTTPS ke backend yang dihosting di berbagai platform Google Cloud (seperti Compute Engine, Google Kubernetes Engine (GKE), Cloud Storage, dan sebagainya), serta backend eksternal yang terhubung melalui internet atau melalui konektivitas hybrid. Untuk mengetahui detailnya, lihat Ringkasan Load Balancer Aplikasi: Kasus penggunaan.
Mode operasi
Anda dapat mengonfigurasi Load Balancer Aplikasi eksternal dalam mode berikut:
- Load Balancer Aplikasi eksternal global. Ini adalah load balancer global yang diterapkan sebagai layanan terkelola di Google Front End (GFE). Solusi ini menggunakan proxy Envoy open source untuk mendukung kemampuan pengelolaan traffic lanjutan seperti pencerminan traffic, pemisahan traffic berbasis bobot, transformasi header berbasis permintaan/respons, dan banyak lagi.
- Load Balancer Aplikasi Klasik. Ini adalah Load Balancer Aplikasi eksternal klasik yang bersifat global di Paket Premium, tetapi dapat dikonfigurasi sebagai regional di Tingkat Standar. Load balancer ini diimplementasikan di Google Front Ends (GFE). GFE didistribusikan secara global dan beroperasi bersama menggunakan jaringan global dan bidang kontrol Google.
- Load Balancer Aplikasi eksternal regional. Ini adalah load balancer regional yang diterapkan sebagai layanan terkelola pada proxy Envoy open source. Ini mencakup kemampuan pengelolaan traffic lanjutan seperti pencerminan traffic, pemisahan traffic berbasis bobot, transformasi header berbasis permintaan/respons, dan banyak lagi.
| Mode load balancer | Kasus penggunaan yang direkomendasikan | Kapabilitas |
|---|---|---|
| Load Balancer Aplikasi eksternal global | Gunakan load balancer ini untuk workload HTTP(S) eksternal dengan pengguna yang tersebar secara global atau layanan backend di beberapa region. |
|
| Load Balancer Aplikasi Klasik | Load balancer ini bersifat global dalam Paket Premium, tetapi dapat dikonfigurasi agar bersifat regional secara efektif di Paket Standar. Pada Paket Layanan Jaringan Premium, load balancer ini menawarkan load balancing multi-region, berupaya mengarahkan traffic ke backend responsif terdekat yang memiliki kapasitas, dan menghentikan traffic HTTP(S) sedekat mungkin dengan pengguna Anda. Untuk mengetahui detail tentang proses distribusi permintaan, lihat Distribusi traffic. Pada Tingkat Layanan Jaringan Standar, load balancing ditangani secara regional. |
|
| Load Balancer Aplikasi eksternal regional | Load balancer ini berisi banyak fitur Load Balancer Aplikasi klasik yang sudah ada, beserta kemampuan pengelolaan traffic lanjutan. Gunakan load balancer ini jika Anda ingin menayangkan konten hanya dari satu geolokasi (misalnya, untuk memenuhi peraturan kepatuhan). Load balancer ini dapat dikonfigurasi dalam Paket Premium atau Paket Standar. |
|
Mengidentifikasi mode
Cloud Console
- Di Konsol Google Cloud, buka halaman Load balancing.
Buka Load balancing Di tab Load Balancer, jenis, protokol, dan region load balancer ditampilkan. Jika region ini kosong, load balancernya bersifat global. Tabel berikut merangkum cara mengidentifikasi mode load balancer.
Mode load balancer Jenis load balancer Jenis akses Region Load Balancer Aplikasi eksternal global Aplikasi Eksternal Load Balancer Aplikasi Klasik Aplikasi(Klasik) Eksternal Load Balancer Aplikasi eksternal regional Aplikasi Eksternal Menentukan wilayah
gcloud
Untuk menentukan mode load balancer, jalankan perintah berikut:
gcloud compute forwarding-rules describe FORWARDING_RULE_NAME
Di output perintah, periksa skema load balancing, region, dan tingkat jaringan. Tabel berikut merangkum cara mengidentifikasi mode load balancer.
Mode load balancer Skema load balancing Aturan penerusan Tingkat jaringan Load Balancer Aplikasi eksternal global EXTERNAL_MANAGED Global Premium Load Balancer Aplikasi Klasik EKSTERNAL Global Standar atau Premium Load Balancer Aplikasi eksternal regional EXTERNAL_MANAGED Menentukan wilayah Standar atau Premium
Arsitektur
Resource berikut diperlukan untuk deployment Load Balancer Aplikasi eksternal:
Khusus untuk Load Balancer Aplikasi eksternal regional, subnet khusus proxy digunakan untuk mengirim koneksi dari load balancer ke backend.
Aturan penerusan eksternal menentukan alamat IP eksternal, port, dan proxy HTTP(S) target. Klien menggunakan port dan alamat IP untuk terhubung ke load balancer.
Proxy HTTP(S) target menerima permintaan dari klien. Proxy HTTP(S) mengevaluasi permintaan menggunakan peta URL untuk membuat keputusan perutean traffic. {i>Proxy<i} juga dapat mengautentikasi komunikasi menggunakan sertifikat SSL.
- Untuk load balancing HTTPS, proxy HTTPS target menggunakan sertifikat SSL untuk membuktikan identitasnya kepada klien. Proxy HTTPS target mendukung hingga jumlah terdokumentasi sertifikat SSL.
Proxy HTTP(S) menggunakan peta URL untuk membuat penentuan pemilihan rute berdasarkan atribut HTTP (seperti jalur permintaan, cookie, atau header). Berdasarkan keputusan pemilihan rute, proxy akan meneruskan permintaan klien ke layanan backend atau bucket backend tertentu. Peta URL dapat menentukan tindakan tambahan, seperti mengirim pengalihan ke klien.
Layanan backend mendistribusikan permintaan ke backend yang responsif. Load Balancer Aplikasi eksternal global juga mendukung bucket backend.
- Satu atau beberapa backend harus terhubung ke layanan backend atau bucket backend.
Health check secara berkala memantau kesiapan backend Anda. Tindakan ini akan mengurangi risiko pengiriman permintaan ke backend yang tidak dapat melayani permintaan tersebut.
Aturan firewall agar backend Anda dapat menerima pemeriksaan health check. Load Balancer Aplikasi eksternal regional memerlukan aturan firewall tambahan untuk mengizinkan traffic dari subnet khusus proxy menjangkau backend.
Global
Diagram ini menunjukkan komponen deployment Load Balancer Aplikasi eksternal global. Arsitektur ini berlaku untuk Load Balancer Aplikasi eksternal global, dan Load Balancer Aplikasi klasik di Paket Premium.
Regional
Diagram ini menunjukkan komponen deployment Load Balancer Aplikasi eksternal regional.
Subnet khusus proxy
Subnet khusus proxy hanya diperlukan untuk Load Balancer Aplikasi eksternal regional.
Subnet khusus proxy menyediakan sekumpulan alamat IP yang digunakan Google untuk menjalankan proxy Envoy atas nama Anda. Anda harus membuat satu subnet khusus proxy di setiap region jaringan VPC tempat Anda menggunakan Load Balancer Aplikasi eksternal regional. Flag --purpose untuk subnet khusus proxy ini
ditetapkan ke REGIONAL_MANAGED_PROXY. Semua load balancing berbasis Envoy regional di region dan jaringan VPC yang sama memiliki kumpulan proxy Envoy dari subnet khusus proxy yang sama. Lebih lanjut:
- Subnet khusus proxy hanya digunakan untuk proxy Envoy, bukan backend Anda.
- VM backend atau endpoint dari semua Load Balancer Aplikasi eksternal regional di suatu region dan jaringan VPC menerima koneksi dari subnet khusus proxy.
- Alamat IP Load Balancer Aplikasi eksternal regional tidak berada di subnet khusus proxy. Alamat IP load balancer ditentukan oleh aturan penerusan terkelola eksternalnya, yang dijelaskan di bawah ini.
Jika sebelumnya Anda membuat subnet khusus proxy dengan --purpose=INTERNAL_HTTPS_LOAD_BALANCER, Anda harus memigrasikan tujuan subnet ke REGIONAL_MANAGED_PROXY agar dapat membuat load balancer berbasis Envoy lain di region yang sama dengan jaringan VPC.
Aturan dan alamat penerusan
Aturan penerusan merutekan traffic menurut alamat IP, port, dan protokol ke konfigurasi load balancing yang terdiri dari proxy target, peta URL, dan satu atau beberapa layanan backend.
Setiap aturan penerusan menyediakan satu alamat IP yang dapat digunakan dalam data DNS untuk aplikasi Anda. Load balancing berbasis DNS tidak diperlukan. Anda dapat menentukan alamat IP yang akan digunakan atau mengizinkan Cloud Load Balancing menetapkan alamat IP untuk Anda.
Setiap aturan penerusan untuk Load Balancer Aplikasi dapat mereferensikan port tunggal dari 1-65535. Untuk mendukung beberapa port, Anda harus mengonfigurasi beberapa aturan penerusan. Anda dapat mengonfigurasi beberapa aturan penerusan untuk menggunakan alamat IP eksternal (VIP) yang sama dan untuk mereferensikan proxy HTTP(S) target yang sama, asalkan kombinasi alamat IP, port, dan protokol tersebut unik untuk setiap aturan penerusan. Dengan cara ini, Anda dapat menggunakan satu load balancer dengan peta URL bersama sebagai proxy untuk beberapa aplikasi.
Jenis aturan penerusan, alamat IP, dan skema load balancing yang digunakan oleh Load Balancer Aplikasi eksternal bergantung pada mode load balancer dan Tingkat Layanan Jaringan tempat load balancer berada.
| Mode load balancer | Network Service Tier | Aturan penerusan, alamat IP, dan skema Load balancing | Memilih rute dari internet ke frontend load balancer |
|---|---|---|---|
| Load Balancer Aplikasi eksternal global | Paket Premium |
Aturan penerusan eksternal global Skema load balancing: |
Permintaan dirutekan ke GFE yang terdekat dengan klien di internet. |
| Load Balancer Aplikasi Klasik | Paket Premium |
Aturan penerusan eksternal global Skema load balancing: |
Permintaan diarahkan ke GFE yang terdekat dengan klien di internet. |
| Paket Standar |
Aturan penerusan eksternal regional Skema load balancing: |
Permintaan diarahkan ke GFE di region load balancer. | |
| Load Balancer Aplikasi eksternal regional | Paket Premium atau Standar |
Aturan penerusan eksternal regional Skema load balancing: |
Permintaan diarahkan ke proxy Envoy di region yang sama dengan load balancer. |
Untuk mengetahui daftar lengkap protokol yang didukung oleh aturan penerusan Load Balancer Aplikasi eksternal dalam setiap mode, lihat Fitur load balancer.
Proxy target
Proxy target menghentikan koneksi HTTP(S) dari klien. Satu atau beberapa aturan penerusan mengarahkan traffic ke proxy target, dan proxy target akan memeriksa peta URL untuk menentukan cara mengarahkan traffic ke backend.
Jangan mengandalkan proxy untuk mempertahankan nama header
permintaan atau respons. Misalnya, header respons Server: Apache/1.0 mungkin muncul di
klien sebagai server: Apache/1.0.
Tabel berikut menentukan jenis proxy target yang diperlukan oleh Load Balancer Aplikasi eksternal di setiap mode.
| Mode load balancer | Jenis proxy target | Header yang ditambahkan proxy | Header kustom didukung | Cloud Trace didukung |
|---|---|---|---|---|
| Load Balancer Aplikasi eksternal global | HTTP Global, HTTPS Global |
Proxy menetapkan header permintaan/respons HTTP sebagai berikut:
Proxy juga dapat menetapkan header |
Dikonfigurasi di
layanan backend atau bucket backend
Tidak didukung Cloud CDN |
|
| Load Balancer Aplikasi Klasik | HTTP Global, HTTPS Global |
Proxy menetapkan header permintaan/respons HTTP sebagai berikut:
Proxy juga dapat menetapkan header |
Dikonfigurasi di layanan backend atau bucket backend | |
| Load Balancer Aplikasi eksternal regional | HTTP Regional, HTTPS Regional |
|
Selain header yang ditambahkan oleh proxy target, load balancer menyesuaikan header HTTP lainnya dengan cara berikut:
Untuk Load Balancer Aplikasi eksternal global, header permintaan dan respons selalu dikonversi menjadi huruf kecil. Misalnya,
Hostmenjadihost, danKeep-ALIVEmenjadikeep-alive.Satu-satunya pengecualian adalah saat Anda menggunakan backend NEG internet global dengan HTTP/1.1. Untuk mengetahui detail tentang cara header HTTP/1.1 diproses dengan NEG internet global, lihat Ringkasan NEG Internet.
Untuk Load Balancer Aplikasi klasik, header permintaan dan respons dikonversi ke huruf kecil, kecuali jika Anda menggunakan HTTP/1.1. Pada HTTP/1.1, {i> header<i} ditulis dengan huruf yang sesuai. Huruf pertama kunci header dan setiap huruf setelah tanda hubung (
-) menggunakan huruf besar untuk menjaga kompatibilitas dengan klien HTTP/1.1. Misalnya,user-agentdiubah menjadiUser-Agent, dancontent-encodingdiubah menjadiContent-Encoding.Beberapa header digabungkan. Jika ada beberapa instance kunci header yang sama (misalnya,
Via), load balancer akan menggabungkan nilainya ke dalam satu daftar yang dipisahkan koma untuk satu kunci header. Hanya header yang nilainya dapat direpresentasikan sebagai daftar yang dipisahkan koma yang akan digabungkan. Header lain, sepertiSet-Cookie, tidak pernah digabungkan.
Header host
Saat load balancer membuat permintaan HTTP, load balancer mempertahankan header Host permintaan asli.
Header X-Forwarded-For
Load balancer menambahkan dua alamat IP yang dipisahkan oleh satu koma ke header X-Forwarded-For dengan urutan berikut:
- Alamat IP klien yang terhubung ke load balancer
- Alamat IP aturan penerusan load balancer
Jika tidak ada header X-Forwarded-For pada permintaan masuk, kedua alamat IP ini adalah seluruh nilai header:
X-Forwarded-For: <client-ip>,<load-balancer-ip>
Jika permintaan menyertakan header X-Forwarded-For, load balancer akan mempertahankan nilai yang diberikan sebelum <client-ip>,<load-balancer-ip>:
X-Forwarded-For: <supplied-value>,<client-ip>,<load-balancer-ip>
Saat menjalankan software reverse proxy HTTP di backend load balancer, software tersebut mungkin menambahkan salah satu atau kedua alamat IP berikut ke akhir header X-Forwarded-For:
Alamat IP Google Front End (GFE) yang terhubung ke backend. Alamat IP ini berada dalam rentang
130.211.0.0/22dan35.191.0.0/16.Alamat IP dari sistem backend itu sendiri.
Dengan demikian, proses upstream setelah backend load balancer Anda mungkin menerima header X-Forwarded-For dalam bentuk:
<existing-values>,<client-ip>,<load-balancer-ip><GFE-IP><backend-IP>
Peta URL
Peta URL menentukan pola yang cocok untuk perutean permintaan berbasis URL ke layanan backend yang sesuai. Layanan default ditentukan untuk menangani permintaan apa pun yang tidak cocok dengan aturan host atau aturan pencocokan jalur yang ditentukan. Dalam beberapa situasi, seperti contoh load balancing multi-region, Anda mungkin tidak menentukan aturan URL apa pun dan hanya mengandalkan layanan default. Untuk perutean permintaan, peta URL memungkinkan Anda membagi traffic dengan memeriksa komponen URL untuk mengirim permintaan ke kumpulan backend yang berbeda.
Peta URL yang digunakan dengan Load Balancer Aplikasi eksternal global dan Load Balancer Aplikasi eksternal regional mendukung beberapa fitur pengelolaan traffic lanjutan seperti pengarahan traffic berbasis header, pemisahan traffic berbasis bobot, dan pencerminan permintaan. Untuk informasi selengkapnya, lihat referensi berikut:
- Ringkasan pengelolaan traffic untuk Load Balancer Aplikasi eksternal global.
- Ringkasan pengelolaan traffic untuk Load Balancer Aplikasi eksternal regional.
Tabel berikut menentukan jenis peta URL yang diperlukan oleh Load Balancer Aplikasi eksternal di setiap mode.
| Mode load balancer | Jenis peta URL |
|---|---|
| Load Balancer Aplikasi eksternal global | Global |
| Load Balancer Aplikasi Klasik | Global (hanya dengan sebagian fitur yang didukung) |
| Load Balancer Aplikasi eksternal regional | Regional |
Sertifikat SSL
Load Balancer Aplikasi Eksternal yang menggunakan proxy HTTPS target memerlukan kunci pribadi dan sertifikat SSL sebagai bagian dari konfigurasi load balancer:Google Cloud menyediakan dua metode konfigurasi untuk menetapkan kunci pribadi dan sertifikat SSL ke proxy HTTPS target: sertifikat SSL Compute Engine dan Pengelola Sertifikat. Untuk deskripsi setiap konfigurasi, lihat Metode konfigurasi sertifikat di ringkasan sertifikat SSL.
Google Cloud menyediakan dua jenis sertifikat: Dikelola sendiri dan dikelola Google. Untuk deskripsi setiap jenis, lihat Jenis sertifikat di ringkasan sertifikat SSL.
Jenis Load Balancer Aplikasi eksternal (global, regional, atau klasik) menentukan metode konfigurasi dan jenis sertifikat yang didukung. Untuk mengetahui detailnya, lihat Load balancer sertifikat dan Google Cloud di ringkasan sertifikat SSL.
TLS bersama
Biasanya pada komunikasi HTTPS, autentikasi hanya berfungsi dengan satu cara: klien memverifikasi identitas server. Untuk aplikasi yang memerlukan load balancer untuk mengautentikasi identitas klien yang terhubung ke aplikasi tersebut, Load Balancer Aplikasi eksternal global dan Load Balancer Aplikasi klasik mendukung TLS bersama (mTLS).
Dengan mTLS, load balancer meminta klien untuk mengirimkan sertifikat untuk mengautentikasi dirinya sendiri selama handshake TLS dengan load balancer. Anda dapat mengonfigurasi penyimpanan kepercayaan yang digunakan load balancer untuk memvalidasi rantai kepercayaan sertifikat klien.
Google Cloud menggunakan resource TrustConfig di
Certificate Manager untuk menyimpan sertifikat yang digunakan server
untuk memverifikasi sertifikat yang diberikan oleh klien. Jika Anda menggunakan Load Balancer Aplikasi klasik di Paket Layanan Jaringan Premium atau Load Balancer Aplikasi eksternal global, Anda dapat menggunakan Pengelola Sertifikat untuk menyediakan dan mengelola sertifikat SSL atau TrustConfig di beberapa instance load balancer dalam skala besar. Untuk mengetahui informasi selengkapnya, lihat
Ringkasan Certificate Manager.
Untuk informasi selengkapnya tentang mTLS, lihat Autentikasi TLS bersama.
Kebijakan SSL
Kebijakan SSL menentukan rangkaian fitur SSL yang digunakan load balancer Google Cloud saat menegosiasikan SSL dengan klien.
Secara default, Load Balancing HTTPS menggunakan serangkaian fitur SSL yang memberikan keamanan yang baik dan kompatibilitas yang luas. Beberapa aplikasi memerlukan kontrol lebih besar atas versi dan cipher SSL mana yang digunakan untuk koneksi HTTPS atau SSL. Anda dapat menentukan kebijakan SSL untuk menentukan rangkaian fitur SSL yang digunakan load balancer Anda saat menegosiasikan SSL dengan klien. Selain itu, Anda dapat menerapkan kebijakan SSL tersebut ke proxy HTTPS target.
Tabel berikut menentukan dukungan kebijakan SSL untuk load balancer dalam setiap mode.
| Mode load balancer | Kebijakan SSL yang didukung |
|---|---|
| Load Balancer Aplikasi eksternal global | |
| Load Balancer Aplikasi Klasik | |
| Load Balancer Aplikasi eksternal regional |
Layanan dan bucket backend
Layanan backend memberikan informasi konfigurasi ke load balancer. Load balancer menggunakan informasi di layanan backend untuk mengarahkan traffic masuk ke satu atau beberapa backend yang terpasang. Untuk contoh yang menunjukkan cara menyiapkan load balancer dengan layanan backend dan backend Compute Engine, baca artikel Menyiapkan Load Balancer Aplikasi eksternal dengan backend Compute Engine.
Bucket backend mengarahkan traffic masuk ke bucket Cloud Storage. Untuk contoh yang menunjukkan cara menambahkan bucket ke Load Balancer Aplikasi eksternal, lihat Menyiapkan load balancer dengan bucket backend.
Tabel berikut menentukan fitur backend yang didukung oleh Load Balancer Aplikasi eksternal di setiap mode.
|
Mode load balancer |
Backend yang didukung di layanan backend | Mendukung bucket backend | Mendukung Google Cloud Armor | Mendukung Cloud CDN4 | Mendukung IAP4 | Mendukung Ekstensi Layanan | |||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Grup instance | NEGARA ZONA | NEG Internet | NEG Tanpa Server | NEG Hybrid | NEG Private Service Connect | ||||||
| Load Balancer Aplikasi eksternal global | 2 | ||||||||||
| Load Balancer Aplikasi Klasik | 1 |
saat menggunakan Paket Premium |
|
||||||||
| Load Balancer Aplikasi eksternal regional | 1 | ||||||||||
1 Gunakan endpoint jenis GCE_VM_IP_PORT dengan GKE:
Gunakan NEG zona mandiri atau
gunakan Ingress
2 Menggunakan endpoint jenis GCE_VM_IP_PORT dengan GKE:
Menggunakan NEG zona mandiri
3 Hanya didukung dengan pengontrol Gateway GKE
4 IAP dan Cloud CDN tidak kompatibel satu sama lain. Opsi ini tidak dapat diaktifkan di layanan backend yang sama.
Untuk informasi selengkapnya, lihat referensi berikut:
Backend dan jaringan VPC
Batasan tempat backend dapat ditemukan bergantung pada jenis load balancer.
- Untuk Load Balancer Aplikasi eksternal global dan Load Balancer Aplikasi klasik, semua instance backend dari backend grup instance dan semua endpoint backend dari backend NEG harus berada di project yang sama. Namun, backend atau NEG grup instance dapat menggunakan jaringan VPC yang berbeda dalam project tersebut. Berbagai jaringan VPC tidak perlu dihubungkan menggunakan Peering Jaringan VPC karena GFE berkomunikasi langsung dengan backend di jaringan VPC-nya masing-masing.
- Untuk Load Balancer Aplikasi eksternal regional, semua backend harus berada di jaringan dan region VPC yang sama.
Protokol ke backend
Saat mengonfigurasi layanan backend untuk load balancer, Anda menetapkan protokol yang digunakan layanan backend untuk berkomunikasi dengan backend. Anda dapat memilih HTTP, HTTPS, atau HTTP/2. Load balancer hanya menggunakan protokol yang Anda tentukan. Load balancer tidak akan beralih kembali ke salah satu protokol lain jika tidak dapat menegosiasikan koneksi ke backend dengan protokol yang ditentukan.
Jika menggunakan HTTP/2, Anda harus menggunakan TLS. HTTP/2 tanpa enkripsi tidak didukung.
Untuk mengetahui daftar lengkap protokol yang didukung, lihat Fitur load balancing: Protokol dari load balancer ke backend.
Dukungan WebSocket
Load balancer berbasis HTTP(S) Google Cloud memiliki dukungan bawaan untuk protokol WebSocket saat Anda menggunakan HTTP atau HTTPS sebagai protokol ke backend. Load balancer tidak memerlukan konfigurasi apa pun untuk melakukan proxy koneksi WebSocket.
Protokol WebSocket menyediakan saluran komunikasi full-duplex antara klien dan server. Permintaan HTTP(S) akan memulai saluran. Untuk mengetahui informasi selengkapnya tentang protokol, lihat RFC 6455.
Jika load balancer mengenali permintaan Upgrade WebSocket dari klien HTTP(S) diikuti dengan respons Upgrade yang berhasil dari instance backend, load balancer akan melakukan proxy traffic dua arah selama durasi koneksi saat ini. Jika backend instance tidak menampilkan respons Upgrade yang berhasil, load balancer akan menutup koneksi.
Afinitas sesi untuk WebSockets berfungsi sama seperti permintaan lainnya. Untuk mengetahui informasinya, lihat Afinitas sesi.
Menggunakan gRPC dengan aplikasi Google Cloud
gRPC adalah framework open source untuk panggilan prosedur jarak jauh. Ini didasarkan pada standar HTTP/2. Kasus penggunaan untuk gRPC mencakup hal berikut:
- Sistem berlatensi rendah, sangat skalabel, dan terdistribusi
- Mengembangkan klien seluler yang berkomunikasi dengan server {i>cloud<i}
- Merancang protokol baru yang harus akurat, efisien, dan tidak bergantung pada bahasa
- Desain berlapis untuk mengaktifkan ekstensi, autentikasi, dan logging
Untuk menggunakan gRPC dengan aplikasi Google Cloud, Anda harus membuat proxy permintaan secara menyeluruh melalui HTTP/2. Untuk melakukan ini:
- Mengonfigurasi load balancer HTTPS.
- Mengaktifkan HTTP/2 sebagai protokol dari load balancer ke backend.
Load balancer menegosiasikan HTTP/2 dengan klien sebagai bagian dari handshake SSL dengan menggunakan ekstensi TLS ALPN.
Load balancer mungkin masih menegosiasikan HTTPS dengan beberapa klien, atau menerima permintaan HTTP yang tidak aman pada load balancer yang dikonfigurasi untuk menggunakan HTTP/2 antara load balancer dan backend instance. Permintaan HTTP atau HTTPS tersebut diubah oleh load balancer untuk mem-proxy permintaan melalui HTTP/2 ke backend instance.
Anda harus mengaktifkan TLS di backend. Untuk mengetahui informasi selengkapnya, lihat Enkripsi dari load balancer ke backend.
Jika Anda ingin mengonfigurasi Load Balancer Aplikasi eksternal menggunakan HTTP/2 dengan Google Kubernetes Engine Ingress atau menggunakan gRPC dan HTTP/2 dengan Ingress, lihat HTTP/2 untuk load balancing dengan Ingress.
Untuk informasi tentang memecahkan masalah dengan HTTP/2, lihat Memecahkan masalah HTTP/2 ke backend.
Untuk mengetahui informasi tentang batasan HTTP/2, lihat batasan HTTP/2.
Health check
Setiap layanan backend menentukan health check yang secara berkala memantau kesiapan backend untuk menerima koneksi dari load balancer. Tindakan ini mengurangi risiko permintaan dikirim ke backend yang tidak dapat melayani permintaan tersebut. Health check tidak memeriksa apakah aplikasi itu sendiri berfungsi.
Untuk pemeriksaan health check, Anda harus membuat aturan firewall masuk yang diizinkan yang memungkinkan pemeriksaan health check mencapai instance backend Anda. Biasanya, pemeriksaan health check berasal dari mekanisme health check terpusat Google.
Load Balancer Aplikasi eksternal regional yang menggunakan backend NEG hybrid merupakan pengecualian untuk aturan ini karena health check-nya berasal dari subnet khusus proxy. Untuk mengetahui detailnya, lihat ringkasan NEG Hybrid.
Protokol health check
Meskipun tidak diwajibkan dan tidak selalu memungkinkan, praktik terbaiknya adalah menggunakan health check yang protokolnya cocok dengan protokol layanan backend. Misalnya, health check HTTP/2 paling akurat menguji konektivitas HTTP/2 ke backend. Sebaliknya, Load Balancer Aplikasi eksternal regional yang menggunakan backend NEG hybrid tidak mendukung health check gRPC. Untuk mengetahui daftar protokol health check yang didukung, lihat Fitur load balancing.
Tabel berikut menetapkan cakupan health check yang didukung oleh Load Balancer Aplikasi eksternal di setiap mode.
| Mode load balancer | Jenis health check |
|---|---|
| Load Balancer Aplikasi eksternal global | Global |
| Load Balancer Aplikasi Klasik | Global |
| Load Balancer Aplikasi eksternal regional | Regional |
Untuk mengetahui informasi selengkapnya tentang health check, lihat berikut ini:
Aturan firewall
Load balancer memerlukan aturan firewall berikut:
- Untuk Load Balancer Aplikasi eksternal global, aturan masuk memungkinkan
traffic dari
Google Front End (GFE) untuk menjangkau backend Anda.
Untuk Load Balancer Aplikasi eksternal regional, aturan izin masuk untuk mengizinkan traffic dari subnet khusus proxy untuk menjangkau backend Anda. - Aturan izinkan masuk untuk mengizinkan traffic dari rentang pemeriksaan health check. Untuk mengetahui informasi selengkapnya tentang pemeriksaan health check dan alasan pentingnya mengizinkan traffic dari pemeriksaan tersebut, baca Memeriksa rentang IP dan aturan firewall.
Aturan firewall diterapkan di level instance VM, bukan pada proxy GFE. Anda tidak dapat menggunakan aturan firewall Google Cloud untuk mencegah traffic mencapai load balancer. Untuk Load Balancer Aplikasi eksternal global dan Load Balancer Aplikasi klasik, Anda dapat menggunakan Google Cloud Armor untuk melakukannya.
Port untuk aturan firewall ini harus dikonfigurasi sebagai berikut:
Mengizinkan traffic ke port tujuan untuk setiap health check layanan backend.
Untuk backend grup instance: Tentukan port yang akan dikonfigurasi dengan pemetaan antara port bernama layanan backend dan nomor port yang terkait dengan port bernama tersebut di setiap grup instance. Nomor port dapat bervariasi di antara grup instance yang ditetapkan ke layanan backend yang sama.
Untuk backend NEG
GCE_VM_IP_PORT: Izinkan traffic ke nomor port endpoint.
Tabel berikut meringkas rentang alamat IP sumber yang diperlukan untuk aturan firewall:
| Mode load balancer | Rentang sumber health check | Rentang sumber permintaan |
|---|---|---|
| Load Balancer Aplikasi eksternal global |
|
Sumber traffic GFE bergantung pada jenis backend:
|
| Load Balancer Aplikasi Klasik |
|
Sumber traffic GFE bergantung pada jenis backend:
|
| Load Balancer Aplikasi eksternal regional |
Izin rentang pemeriksaan health check Google tidak diperlukan untuk NEG hybrid. Namun, jika menggunakan kombinasi NEG campuran dan zona dalam satu layanan backend, Anda harus mengizinkan rentang pemeriksaan health check Google untuk NEG zona. |
Subnet khusus proxy yang Anda konfigurasi. |
Arsitektur VPC Bersama
Load Balancer Aplikasi Eksternal mendukung jaringan yang menggunakan VPC Bersama. Dengan VPC Bersama, organisasi menghubungkan resource dari beberapa project ke jaringan VPC umum, sehingga mereka dapat berkomunikasi satu sama lain secara aman dan efisien menggunakan alamat IP internal dari jaringan tersebut. Jika Anda belum memahami VPC Bersama, baca ringkasan VPC Bersama.
Ada banyak cara untuk mengonfigurasi Load Balancer Aplikasi eksternal dalam jaringan VPC Bersama. Apa pun jenis deployment, semua komponen load balancer harus berada dalam organisasi yang sama.
| Load balancer | Komponen {i>frontend<i} | Komponen backend |
|---|---|---|
| Load Balancer Aplikasi eksternal global |
Alamat IP eksternal global, aturan penerusan, proxy HTTP(S) target, dan peta URL terkait harus ditetapkan dalam project yang sama. Project ini dapat berupa project host atau project layanan. |
Layanan backend global harus ditentukan dalam host atau project layanan yang sama dengan backend (grup instance atau NEG). Health check yang terkait dengan layanan backend juga harus ditentukan dalam project yang sama dengan layanan backend. |
| Load Balancer Aplikasi Klasik | Alamat IP eksternal global, aturan penerusan, proxy HTTP(S) target, dan peta URL terkait harus ditetapkan dalam host atau project layanan yang sama dengan backend. | Layanan backend global harus ditentukan dalam host atau project layanan yang sama dengan backend (grup instance atau NEG). Health check yang terkait dengan layanan backend juga harus ditentukan dalam project yang sama dengan layanan backend. |
| Load Balancer Aplikasi eksternal regional | Buat jaringan dan subnet khusus proxy yang diperlukan pada project host VPC Bersama. Alamat IP eksternal regional, aturan penerusan, proxy HTTP(S) target, dan peta URL terkait harus ditetapkan dalam project yang sama. Project ini dapat berupa project host atau project layanan. |
Anda dapat melakukan salah satu tindakan berikut:
Setiap layanan backend harus ditentukan dalam project yang sama dengan backend yang direferensikannya. Health check yang terkait dengan layanan backend harus ditentukan dalam project yang sama dengan layanan backend juga. |
Meskipun Anda dapat membuat semua komponen dan backend load balancing di project host VPC Bersama, jenis deployment ini tidak memisahkan tanggung jawab administrasi jaringan dan pengembangan layanan.
Semua komponen dan backend load balancer dalam sebuah project layanan
Diagram arsitektur berikut menunjukkan deployment VPC Bersama standar tempat semua komponen dan backend load balancer berada dalam sebuah project layanan. Jenis deployment ini didukung oleh semua Load Balancer Aplikasi.
Komponen dan backend load balancer harus menggunakan jaringan VPC yang sama.
Backend serverless di lingkungan VPC Bersama
Untuk load balancer yang menggunakan backend NEG serverless, layanan Cloud Run atau Cloud Functions backend harus berada dalam project yang sama dengan NEG serverless.
Selain itu, untuk Load Balancer Aplikasi eksternal regional yang mendukung referensi layanan lintas-project, layanan backend, NEG serverless, dan layanan Cloud Run harus selalu berada dalam project layanan yang sama.
Rujukan layanan lintas project
Dalam model ini, peta URL dan frontend load balancer berada dalam project layanan atau host. Layanan backend dan backend load balancer dapat didistribusikan ke seluruh project di lingkungan VPC Bersama. Layanan backend lintas project dapat direferensikan di satu peta URL. Hal ini disebut sebagai referensi layanan lintas-project.
Dengan referensi layanan lintas project, organisasi dapat mengonfigurasi satu load balancer pusat dan merutekan traffic ke ratusan layanan yang didistribusikan di berbagai project. Anda dapat mengelola semua aturan dan kebijakan rute lalu lintas secara terpusat dalam satu peta URL. Anda juga dapat mengaitkan load balancer dengan satu set nama host dan sertifikat SSL. Oleh karena itu, Anda dapat mengoptimalkan jumlah load balancer yang diperlukan untuk men-deploy aplikasi, serta mengelola pengelolaan, biaya operasional, dan persyaratan kuota yang lebih rendah.
Dengan memiliki project yang berbeda untuk setiap tim fungsional, Anda juga dapat mencapai pemisahan peran dalam organisasi Anda. Pemilik layanan dapat berfokus pada pembuatan layanan di project layanan, sementara tim jaringan dapat menyediakan dan mempertahankan load balancer di project lain, dan keduanya dapat dihubungkan dengan menggunakan referensi layanan lintas project.
Pemilik layanan dapat mempertahankan otonomi atas eksposur layanan mereka dan mengontrol pengguna mana yang dapat mengakses layanan mereka menggunakan load balancer. Hal ini dicapai oleh peran IAM khusus yang disebut peran Pengguna Layanan Load Balancer Compute (roles/compute.loadBalancerServiceUser).
Untuk mempelajari cara mengonfigurasi VPC Bersama untuk Load Balancer Aplikasi eksternal regional—dengan atau tanpa perujukan layanan lintas project, lihat Menyiapkan Load Balancer Aplikasi eksternal regional dengan VPC Bersama.
Batasan umum pada referensi layanan lintas-project
-
Rujukan layanan lintas project dapat digunakan dengan grup instance, NEG serverless, dan sebagian besar jenis backend lainnya yang didukung. Namun, batasan berikut berlaku:
- Dengan Load Balancer Aplikasi eksternal regional, Anda tidak dapat mereferensikan layanan backend lintas project jika layanan backend memiliki backend NEG internet regional.
- Referensi layanan lintas-project tidak didukung untuk Load Balancer Aplikasi eksternal global dan Load Balancer Aplikasi klasik.
- Google Cloud tidak membedakan beberapa resource (misalnya, layanan backend) yang menggunakan nama yang sama di beberapa project. Oleh karena itu, saat Anda menggunakan referensi layanan lintas-project, sebaiknya gunakan nama layanan backend yang unik di seluruh project dalam organisasi Anda.
Contoh 1: Frontend dan backend load balancer di berbagai project layanan
Berikut adalah contoh deployment dengan frontend dan peta URL load balancer yang dibuat di project layanan A dan peta URL mereferensikan layanan backend di project layanan B.
Dalam hal ini, Admin Jaringan atau Admin Load Balancer di project layanan A akan
memerlukan akses ke layanan backend di project layanan B. Admin project layanan B memberikan peran IAM compute.loadBalancerServiceUser kepada Admin Load Balancer di project layanan A yang ingin mereferensikan layanan backend di project layanan B.
Contoh 2: Frontend load balancer di project host dan backend di project layanan
Pada jenis deployment ini, peta URL dan frontend load balancer dibuat di project host, sedangkan layanan backend (serta backend) dibuat dalam project layanan.
Dalam hal ini, Admin Jaringan atau Admin Load Balancer di project host akan memerlukan akses ke layanan backend dalam project layanan. Admin project layanan memberikan peran IAM compute.loadBalancerServiceUser kepada Admin Load Balancer di project host A yang ingin mereferensikan layanan backend di project layanan.
Cara kerja koneksi
Koneksi Load Balancer Aplikasi eksternal global
Load Balancer Aplikasi eksternal global diimplementasikan oleh banyak proxy yang disebut Google Front Ends (GFE). Tidak hanya ada satu {i>proxy<i}. Pada Paket Premium, alamat IP eksternal global yang sama diiklankan dari berbagai titik kehadiran, dan permintaan klien diarahkan ke GFE terdekat klien.
Bergantung pada lokasi klien Anda, beberapa GFE dapat memulai koneksi HTTP(S) ke backend Anda. Paket yang dikirim dari GFE memiliki alamat IP sumber dari rentang yang sama dengan yang digunakan oleh prober health check: 35.191.0.0/16 dan 130.211.0.0/22.
Bergantung pada konfigurasi layanan backend, protokol yang digunakan oleh setiap GFE untuk terhubung ke backend Anda dapat berupa HTTP, HTTPS, atau HTTP/2. Untuk koneksi HTTP atau HTTPS, versi HTTP yang digunakan adalah HTTP 1.1.
Keepalive HTTP diaktifkan secara default, seperti yang ditentukan dalam spesifikasi HTTP 1.1. Keepalive HTTP mencoba menggunakan sesi TCP yang sama secara efisien; namun, tidak ada jaminan. GFE menggunakan waktu tunggu keepalive HTTP klien selama 610 detik dan nilai waktu tunggu keepalive backend default selama 600 detik. Anda dapat memperbarui waktu tunggu keepalive HTTP klien, tetapi nilai waktu tunggu keepalive backend telah diperbaiki. Anda dapat mengonfigurasi waktu tunggu permintaan/respons dengan menyetel waktu tunggu layanan backend. Meskipun terkait erat, keepalive HTTP dan waktu tunggu tidak ada aktivitas TCP bukanlah hal yang sama. Untuk mengetahui informasi selengkapnya, lihat waktu tunggu dan percobaan ulang.
Untuk memastikan bahwa traffic mengalami load balancing secara merata, load balancer dapat menutup koneksi TCP bersih dengan mengirimkan paket FIN ACK setelah menyelesaikan respons yang menyertakan header Connection: close, atau mungkin mengeluarkan frame HTTP/2 GOAWAY setelah menyelesaikan respons. Perilaku ini tidak mengganggu permintaan atau respons aktif apa pun.
Jumlah koneksi HTTP dan sesi TCP bervariasi, bergantung pada jumlah GFE yang terhubung, jumlah klien yang terhubung ke GFE, protokol ke backend, dan tempat backend di-deploy.
Untuk mengetahui informasi selengkapnya, baca Cara kerja Load Balancer Aplikasi eksternal di panduan solusi: Pengoptimalan Kapasitas Aplikasi dengan Load Balancing Global.
Koneksi Load Balancer Aplikasi eksternal regional
Load Balancer Aplikasi eksternal regional adalah layanan terkelola yang diterapkan pada proxy Envoy. Load Balancer Aplikasi eksternal regional menggunakan subnet bersama yang disebut subnet khusus proxy untuk menyediakan sekumpulan alamat IP yang digunakan Google untuk menjalankan proxy Envoy atas nama Anda. Flag --purpose untuk subnet khusus proxy ini disetel ke
REGIONAL_MANAGED_PROXY. Semua load balancing berbasis Envoy regional di jaringan dan region tertentu berbagi subnet ini.
Klien menggunakan port dan alamat IP load balancer untuk terhubung ke load balancer. Permintaan klien diarahkan ke subnet khusus proxy di region yang sama dengan klien. Load balancer menghentikan permintaan klien, lalu membuka koneksi baru dari subnet khusus proxy ke backend Anda. Oleh karena itu, paket yang dikirim dari load balancer memiliki alamat IP sumber dari subnet khusus proxy.
Bergantung pada konfigurasi layanan backend, protokol yang digunakan oleh proxy Envoy untuk terhubung ke backend Anda dapat berupa HTTP, HTTPS, atau HTTP/2. Jika HTTP atau HTTPS, versi HTTP adalah HTTP 1.1. Keepalive HTTP diaktifkan secara default, seperti yang ditetapkan dalam spesifikasi HTTP 1.1. Proxy Envoy menetapkan waktu tunggu keepalive HTTP klien dan waktu tunggu keepalive backend ke nilai default masing-masing 600 detik. Anda dapat memperbarui waktu tunggu keepalive HTTP klien, tetapi nilai waktu tunggu keepalive backend telah diperbaiki. Anda dapat mengonfigurasi waktu tunggu permintaan/respons dengan menyetel waktu tunggu layanan backend. Untuk mengetahui informasi selengkapnya, lihat waktu tunggu dan percobaan ulang.
Komunikasi klien dengan load balancer
- Klien dapat berkomunikasi dengan load balancer menggunakan protokol HTTP 1.1 atau HTTP/2.
- Saat HTTPS digunakan, klien modern ditetapkan secara default ke HTTP/2. Hal ini dikontrol pada klien, bukan di load balancer HTTPS.
- Anda tidak dapat menonaktifkan HTTP/2 dengan membuat perubahan konfigurasi pada load balancer. Namun, Anda dapat mengonfigurasi beberapa klien agar menggunakan HTTP 1.1,
bukan HTTP/2. Misalnya, dengan
curl, gunakan parameter--http1.1. - Load Balancer Aplikasi Eksternal mendukung respons
HTTP/1.1 100 Continue.
Untuk mengetahui daftar lengkap protokol yang didukung oleh aturan penerusan Load Balancer Aplikasi eksternal dalam setiap mode, lihat Fitur load balancer.
Alamat IP sumber untuk paket klien
Alamat IP sumber untuk paket, seperti yang terlihat oleh backend, bukan alamat IP eksternal Google Cloud untuk load balancer. Dengan kata lain, ada dua koneksi TCP.
Untuk Load Balancer Aplikasi eksternal global:Koneksi 1, dari klien asli ke load balancer (GFE):
- Alamat IP sumber: klien asli (atau alamat IP eksternal jika klien berada di belakang NAT atau proxy penerusan).
- Alamat IP tujuan: alamat IP load balancer Anda.
Koneksi 2, dari load balancer (GFE) ke endpoint atau VM backend:
Alamat IP sumber: Alamat IP di salah satu rentang yang ditentukan dalam Aturan firewall.
Alamat IP tujuan: alamat IP internal VM backend atau container di jaringan VPC.
Koneksi 1, dari klien asli ke load balancer (subnet khusus proxy):
- Alamat IP sumber: klien asli (atau alamat IP eksternal jika klien berada di belakang NAT atau proxy penerusan).
- Alamat IP tujuan: alamat IP load balancer Anda.
Koneksi 2, dari load balancer (subnet khusus proxy) ke VM backend atau endpoint:
Alamat IP sumber: alamat IP di subnet khusus proxy yang digunakan bersama oleh semua load balancer berbasis Envoy yang di-deploy di region dan jaringan yang sama dengan load balancer.
Alamat IP tujuan: alamat IP internal VM backend atau container di jaringan VPC.
Jalur pengembalian
Untuk Load Balancer Aplikasi eksternal global, Google Cloud menggunakan rute khusus yang tidak ditentukan di jaringan VPC Anda untuk health check. Untuk mengetahui informasi selengkapnya, lihat Jalur yang ditampilkan load balancer.
Untuk Load Balancer Aplikasi eksternal regional, Google Cloud menggunakan proxy Envoy open source untuk menghentikan permintaan klien ke load balancer. Load balancer menghentikan sesi TCP dan membuka sesi TCP baru dari subnet khusus proxy region ke backend Anda. Rute yang ditentukan dalam jaringan VPC Anda memfasilitasi komunikasi dari proxy Envoy ke backend Anda dan dari backend Anda ke proxy Envoy.
Port yang terbuka
GFE memiliki beberapa port terbuka untuk mendukung layanan Google lainnya yang berjalan pada arsitektur yang sama. Saat menjalankan pemindaian port, Anda mungkin melihat port terbuka lainnya untuk layanan Google lainnya yang berjalan di GFE.
Load balancer berbasis GFE, yaitu Load Balancer Aplikasi eksternal global dan Load Balancer Aplikasi klasik, selalu menampilkan port 80 dan 443 sebagai terbuka (beserta port lain yang telah Anda konfigurasikan di aturan penerusan load balancer). Namun, jika Anda belum mengonfigurasi aturan penerusan untuk port 80 atau untuk port 443, semua koneksi yang dikirim ke port tersebut akan ditolak. Sebaliknya, Load Balancer Aplikasi eksternal regional diimplementasikan menggunakan proxy Envoy dan tidak menampilkan port yang terbuka tambahan selama pemindaian.Menjalankan pemindaian port pada alamat IP load balancer berbasis GFE tidak berguna dari perspektif audit karena alasan berikut:
Pemindaian port (misalnya, dengan
nmap) umumnya mengharapkan tidak ada paket respons atau paket TCP RST saat melakukan pemeriksaan TCP SYN. GFE akan mengirim paket SYN-ACK sebagai respons terhadap pemeriksaan SYN hanya untuk port yang aturan penerusannya telah Anda konfigurasi. GFE hanya mengirim paket ke backend Anda sebagai respons terhadap paket yang dikirim ke alamat IP load balancer Anda dan port tujuan yang dikonfigurasi pada aturan penerusannya. Paket yang dikirim ke alamat IP atau port yang berbeda tidak dikirim ke backend Anda.GFE menerapkan fitur keamanan seperti Google Cloud Armor. Dengan Google Cloud Armor Standard, GFE memberikan perlindungan yang selalu aktif dari serangan DDoS berbasis protokol dan volumetrik serta SYN flood. Perlindungan ini tersedia meskipun Anda belum mengonfigurasi Google Cloud Armor secara eksplisit. Anda hanya akan dikenai biaya jika mengonfigurasi kebijakan keamanan, atau jika mendaftar ke Managed Protection Plus.
Paket yang dikirim ke alamat IP load balancer Anda dapat dijawab oleh GFE apa pun di fleet Google. Namun, pemindaian alamat IP load balancer dan kombinasi port tujuan hanya akan menginterogasi satu GFE per koneksi TCP. Alamat IP load balancer Anda tidak ditetapkan ke satu perangkat atau sistem. Oleh karena itu, pemindaian alamat IP load balancer berbasis GFE tidak memindai semua GFE di fleet Google.
Dengan mempertimbangkan hal itu, berikut adalah beberapa cara yang lebih efektif untuk mengaudit keamanan instance backend Anda:
Auditor keamanan harus memeriksa konfigurasi aturan penerusan untuk konfigurasi load balancer. Aturan penerusan menentukan port tujuan tempat load balancer menerima paket dan meneruskannya ke backend. Untuk load balancer berbasis GFE, setiap aturan penerusan eksternal hanya dapat mereferensikan satu port TCP tujuan. Untuk load balancer yang menggunakan port TCP 443, port UDP 443 digunakan saat koneksi diupgrade ke QUIC (HTTP/3).
Auditor keamanan harus memeriksa konfigurasi aturan firewall yang berlaku untuk VM backend. Aturan firewall yang Anda tetapkan akan memblokir traffic dari GFE ke VM backend, tetapi tidak memblokir traffic masuk ke GFE. Untuk praktik terbaik, lihat bagian aturan firewall.
Penghentian TLS
Tabel berikut merangkum cara penghentian TLS ditangani oleh Load Balancer Aplikasi eksternal di setiap mode.
| Mode load balancer | Penghentian TLS |
|---|---|
| Load Balancer Aplikasi eksternal global | TLS dihentikan di GFE, yang bisa berada di mana saja di seluruh dunia. |
| Load Balancer Aplikasi Klasik | TLS dihentikan di GFE, yang bisa jadi berada di mana saja di seluruh dunia. |
| Load Balancer Aplikasi eksternal regional | TLS dihentikan pada proxy Envoy yang terletak di subnet khusus proxy di region yang dipilih oleh pengguna. Gunakan mode load balancer ini jika Anda memerlukan kontrol geografis atas region tempat TLS dihentikan. |
Waktu tunggu dan percobaan ulang
Load Balancer Aplikasi Eksternal mendukung jenis waktu tunggu berikut:| Jenis dan deskripsi waktu tunggu | Nilai default | Mendukung nilai kustom | ||
|---|---|---|---|---|
| Global | Klasik | Regional | ||
| Waktu tunggu layanan backend1
Waktu tunggu permintaan dan respons. Menyatakan jumlah waktu maksimum yang dapat berlalu dari saat load balancer mengirimkan byte pertama permintaan HTTP ke backend Anda hingga saat backend menampilkan byte terakhir dari respons HTTP. Jika seluruh respons HTTP belum ditampilkan ke load balancer selama waktu tunggu permintaan atau respons habis, data respons yang tersisa akan dihapus. Untuk WebSocket yang digunakan dengan Load Balancer Aplikasi klasik, durasi maksimum WebSocket, baik tidak ada aktivitas maupun aktif. |
|
2 | 2 | |
| Waktu tunggu HTTP klien habis
Jumlah waktu maksimum saat koneksi TCP antara klien dan proxy load balancer boleh tidak ada aktivitas. (Koneksi TCP yang sama dapat digunakan untuk beberapa permintaan HTTP.)
|
|
|||
| Waktu tunggu keepalive HTTP backend
Jumlah waktu maksimum saat koneksi TCP antara proxy load balancer dan backend dapat tidak ada aktivitas. (Koneksi TCP yang sama mungkin digunakan untuk beberapa permintaan HTTP.)
|
|
|||
| Waktu tunggu tidak ada aktivitas sesi QUIC
Jumlah waktu maksimum sesi QUIC dapat tidak ada aktivitas antara klien (downstream) dan GFE dari Load Balancer Aplikasi eksternal global atau Load Balancer Aplikasi klasik. |
Untuk Load Balancer Aplikasi eksternal global dan Load Balancer Aplikasi klasik: Waktu tunggu tidak ada aktivitas sesi QUIC adalah waktu minimum waktu tunggu tidak ada aktivitas klien atau waktu tunggu tidak ada aktivitas GFE (300 detik). Waktu tunggu tidak ada aktivitas GFE ditetapkan ke 300 detik. Waktu tunggu tidak ada aktivitas klien dapat dikonfigurasi. |
|||
1Tidak dapat dikonfigurasi untuk backend NEG serverless. Tidak dapat dikonfigurasi untuk bucket backend.
2Dukungan konfigurasi tidak berlaku untuk WebSockets.
Waktu tunggu layanan backend
Waktu tunggu layanan backend yang dapat dikonfigurasi menunjukkan jumlah waktu maksimum yang dihabiskan load balancer untuk menunggu backend Anda memproses permintaan HTTP dan menampilkan respons HTTP yang sesuai. Kecuali untuk NEG serverless, nilai default waktu tunggu layanan backend adalah 30 detik.
Misalnya, jika Anda ingin mendownload file berukuran 500 MB dan nilai waktu tunggu layanan backend adalah 90 detik, load balancer mengharapkan backend mengirimkan seluruh file berukuran 500 MB dalam waktu 90 detik. Anda dapat mengonfigurasi waktu tunggu layanan backend agar tidak cukup bagi backend untuk mengirim respons HTTP secara lengkap. Dalam situasi ini, jika load balancer setidaknya telah menerima header respons HTTP dari backend, load balancer akan menampilkan header respons lengkap dan isi respons sebanyak mungkin yang dapat diperoleh selama waktu tunggu layanan backend habis.
Anda harus menetapkan waktu tunggu layanan backend ke jangka waktu terlama yang
Anda harapkan akan diperlukan backend untuk memproses respons HTTP. Anda harus meningkatkan waktu tunggu layanan backend jika software yang berjalan di backend memerlukan lebih banyak waktu untuk memproses permintaan HTTP dan menampilkan seluruh responsnya.
Misalnya, Anda harus meningkatkan waktu tunggu jika
Anda melihat respons 408 HTTP dengan
jsonPayload.statusDetail client_timed_out.
Waktu tunggu layanan backend menerima nilai antara 1 dan 2,147,483,647 detik; namun, nilai yang lebih besar bukanlah opsi konfigurasi yang praktis.
Google Cloud tidak menjamin bahwa koneksi TCP dasar dapat
tetap terbuka selama keseluruhan nilai waktu tunggu layanan backend. Sistem
klien harus mengimplementasikan logika mencoba ulang, bukan mengandalkan koneksi TCP agar
terbuka dalam jangka waktu yang lama.
Waktu tunggu koneksi WebSocket bergantung pada jenis load balancer:
- Untuk Load Balancer Aplikasi klasik, waktu tunggu untuk koneksi WebSocket bergantung pada waktu tunggu layanan backend yang dapat dikonfigurasi dari load balancer, yaitu 30 detik secara default. Waktu tunggu ini berlaku untuk koneksi WebSocket terlepas dari apakah sedang digunakan atau tidak.
- Untuk Load Balancer Aplikasi eksternal Global dan Load Balancer Aplikasi eksternal regional, koneksi WebSocket yang aktif tidak mengikuti waktu tunggu layanan backend. Koneksi WebSocket tidak ada aktivitas ditutup setelah waktu tunggu layanan backend habis.
- Selain itu, koneksi WebSocket yang digunakan oleh Load Balancer Aplikasi eksternal global dan Load Balancer Aplikasi klasik akan otomatis ditutup setelah 24 jam. Batas 24 jam ini tidak dapat disesuaikan dan terjadi terlepas dari apakah koneksi sedang digunakan atau apakah nilai waktu tunggu layanan backend ditetapkan ke nilai yang lebih besar dari 86.400 detik (24 jam).
Untuk Load Balancer Aplikasi eksternal global atau Load Balancer Aplikasi klasik, nilai waktu tunggu layanan backend yang lebih besar dari satu hari (86.400 detik) tidak direkomendasikan karena Google Cloud secara berkala memulai ulang Google Front Ends untuk update software dan pemeliharaan rutin lainnya. Nilai waktu tunggu layanan backend Anda tidak menunda aktivitas pemeliharaan Google. Makin lama nilai waktu tunggu layanan backend, makin besar kemungkinan Google akan menghentikan koneksi TCP untuk pemeliharaan.
Untuk Load Balancer Aplikasi eksternal regional, Google Cloud akan memulai ulang atau mengubah jumlah penayangan tugas software Envoy secara berkala. Makin lama nilai waktu tunggu layanan backend, makin besar kemungkinan tugas Envoy dimulai ulang atau penggantian akan menghentikan koneksi TCP.
Load Balancer Aplikasi eksternal regional mendukung parameter routeActions.timeout peta URL, yang dapat menggantikan waktu tunggu layanan backend. Jika routeActions.timeout dihilangkan, nilai waktu tunggu layanan backend akan digunakan. Jika routeActions.timeout disediakan, waktu tunggu layanan backend akan diabaikan, dan nilai routeActions.timeout digunakan sebagai waktu tunggu permintaan dan respons.
Untuk mengonfigurasi waktu tunggu layanan backend, gunakan salah satu metode berikut:
- Konsol Google Cloud: Ubah kolom Timeout di layanan backend load balancer.
- Google Cloud CLI: Gunakan perintah
gcloud compute backend-services updateuntuk mengubah parameter--timeoutdari resource layanan backend. - API: Untuk Load Balancer Aplikasi eksternal global atau Load Balancer Aplikasi klasik, ubah parameter
timeoutSecuntuk resourcebackendServicesglobal. - API: Untuk Load Balancer Aplikasi eksternal regional, ubah parameter
timeoutSecuntuk resourceregionBackendServices.
Waktu tunggu keepalive HTTP klien
Waktu tunggu keepalive HTTP klien menunjukkan jumlah waktu maksimum saat koneksi TCP dapat tidak ada aktivitas antara klien (downstream) dan salah satu jenis proxy berikut:
- Untuk Load Balancer Aplikasi eksternal global atau Load Balancer Aplikasi klasik: Google Front End lapis pertama
- Untuk Load Balancer Aplikasi eksternal regional: proxy Envoy
Waktu tunggu keepalive HTTP mewakili waktu tunggu tidak ada aktivitas TCP untuk koneksi TCP yang mendasarinya. Waktu tunggu keepalive HTTP klien tidak berlaku untuk WebSockets.
- Untuk Load Balancer Aplikasi eksternal global, nilai defaultnya adalah 610 detik. Anda dapat mengonfigurasi waktu tunggu keepalive HTTP klien dengan nilai antara 5 dan 1.200 detik.
- Untuk Load Balancer Aplikasi klasik, waktu tunggu keepalive HTTP klien ditetapkan ke 610 detik.
- Untuk Load Balancer Aplikasi eksternal regional, waktu tunggu keepalive HTTP klien ditetapkan ke 600 detik.
Untuk mengonfigurasi parameter waktu tunggu keepalive, gunakan salah satu metode berikut:
- Konsol Google Cloud: Ubah kolom HTTP keepalive timeout pada konfigurasi frontend load balancer.
- Google Cloud CLI: Gunakan perintah
gcloud compute target-http-proxies updateatau perintahgcloud compute target-https-proxies updateuntuk mengubah parameter--http-keep-alive-timeout-secpada proxy HTTP target atau resource proxy HTTPS target. - API: Ubah parameter
httpKeepAliveTimeoutSecuntuk resourcetargetHttpProxiesatau resourcetargetHttpsProxies.
Waktu tunggu keepalive HTTP klien load balancer harus lebih besar daripada waktu tunggu HTTP keepalive (TCP tidak ada aktivitas) yang digunakan oleh klien atau proxy downstream. Jika klien downstream memiliki waktu tunggu keepalive HTTP (TCP tidak ada aktivitas) yang lebih besar daripada waktu tunggu keepalive HTTP klien load balancer, kondisi race dapat terjadi. Dari perspektif klien downstream, koneksi TCP yang dibuat diizinkan untuk tidak ada aktivitas selama lebih lama dari yang diizinkan oleh load balancer. Ini berarti bahwa klien downstream dapat mengirim paket setelah load balancer menganggap koneksi TCP ditutup. Jika hal itu terjadi, load balancer merespons dengan paket reset TCP (RST).
Waktu tunggu keepalive HTTP backend
Load Balancer Aplikasi Eksternal adalah proxy yang menggunakan setidaknya dua koneksi TCP:
Untuk Load Balancer Aplikasi eksternal global atau Load Balancer Aplikasi klasik, ada koneksi TCP pertama antara klien (downstream) dan GFE lapis pertama. GFE lapisan pertama terhubung ke GFE lapisan kedua, lalu GFE lapisan kedua membuka koneksi TCP kedua ke backend Anda.
Untuk Load Balancer Aplikasi eksternal regional, ada koneksi TCP pertama antara klien (downstream) dan proxy Envoy. Proxy Envoy kemudian membuka koneksi TCP kedua ke backend Anda.
Koneksi TCP sekunder load balancer mungkin tidak ditutup setelah setiap permintaan. Koneksi TCP sekunder load balancer mungkin tidak ditutup setelah setiap permintaan. Koneksi TCP sekunder load balancer dapat tetap terbuka untuk menangani beberapa permintaan dan respons HTTP. Waktu tunggu keepalive HTTP backend menentukan waktu tunggu tidak ada aktivitas TCP antara load balancer dan backend Anda. Waktu tunggu keepalive HTTP backend tidak berlaku untuk WebSockets.
Waktu tunggu keepalive backend ditetapkan tetap 10 menit (600 detik) dan tidak dapat diubah. Waktu tunggu keepalive backend load balancer harus kurang dari waktu tunggu keepalive yang digunakan oleh software yang berjalan di backend Anda. Hal ini akan menghindari kondisi race saat sistem operasi backend Anda mungkin menutup koneksi TCP dengan reset TCP (RST). Karena waktu tunggu keepalive backend untuk load balancer tidak dapat dikonfigurasi, Anda harus mengonfigurasi software backend agar nilai waktu tunggu HTTP keepalive (TCP tidak ada aktivitas) lebih besar dari 600 detik.
Tabel berikut mencantumkan perubahan yang diperlukan untuk mengubah nilai waktu tunggu keepalive untuk software server web umum.
| Software server web | Parameter | Setelan default | Setelan yang direkomendasikan |
|---|---|---|---|
| Apache | KeepAliveTimeout | KeepAliveTimeout 5 |
KeepAliveTimeout 620 |
| nginx | keepalive_timeout | keepalive_timeout 75s; |
keepalive_timeout 620s; |
Waktu tunggu tidak ada aktivitas sesi QUIC
Waktu tunggu tidak ada aktivitas sesi QUIC menunjukkan jumlah waktu maksimum saat sesi QUIC tidak ada aktivitas antara klien dan GFE dari Load Balancer Aplikasi eksternal global atau Load Balancer Aplikasi klasik.
Nilai waktu tunggu tidak ada aktivitas sesi QUIC didefinisikan sebagai waktu minimum waktu tunggu tidak ada aktivitas klien atau waktu tunggu tidak ada aktivitas GFE (300 detik). Waktu tunggu tidak ada aktivitas GFE ditetapkan ke 300 detik. Waktu tunggu tidak ada aktivitas klien dapat dikonfigurasi.
Upaya coba lagi
Dukungan untuk logika percobaan ulang bergantung pada mode Load Balancer Aplikasi eksternal.
| Mode load balancer | Mencoba ulang logika |
|---|---|
| Load Balancer Aplikasi eksternal global |
Dapat dikonfigurasi menggunakan kebijakan coba lagi di peta URL. Jumlah default percobaan ulang ( Tanpa kebijakan percobaan ulang, permintaan yang gagal yang tidak memiliki isi HTTP (misalnya, permintaan Permintaan Permintaan yang dicoba lagi hanya akan menghasilkan satu entri log untuk respons akhir. |
| Load Balancer Aplikasi Klasik |
Kebijakan percobaan ulang tidak dapat diubah untuk percobaan ulang koneksi. Permintaan Permintaan Load balancer akan mencoba kembali permintaan Permintaan yang dicoba lagi hanya akan menghasilkan satu entri log untuk respons akhir. Untuk mengetahui informasi selengkapnya, lihat Logging dan pemantauan Load Balancer Aplikasi Eksternal. Permintaan yang gagal menyebabkan load balancer menyintesis respons |
| Load Balancer Aplikasi eksternal regional |
Dapat dikonfigurasi menggunakan kebijakan coba lagi di peta URL. Jumlah default percobaan ulang ( Tanpa kebijakan percobaan ulang, permintaan yang gagal yang tidak memiliki isi HTTP (misalnya, permintaan Permintaan Permintaan yang dicoba lagi hanya akan menghasilkan satu entri log untuk respons akhir. |
Protokol WebSocket didukung dengan GKE Ingress.
Penanganan permintaan dan respons ilegal
Load balancer memblokir permintaan klien dan respons backend masing-masing agar tidak mencapai backend atau klien karena sejumlah alasan. Beberapa alasan hanya untuk kepatuhan HTTP/1.1 dan alasan lainnya adalah untuk menghindari data yang tidak terduga diteruskan ke atau dari backend. Tidak ada pemeriksaan yang dapat dinonaktifkan.
Load balancer memblokir hal berikut untuk kepatuhan HTTP/1.1:
- Fungsi ini tidak dapat mengurai baris pertama permintaan.
- Header tidak memiliki pemisah
:. - Header atau baris pertama berisi karakter yang tidak valid.
- Panjang konten bukan angka yang valid, atau ada beberapa header panjang konten.
- Ada beberapa kunci encoding transfer, atau ada nilai encoding transfer yang tidak dikenal.
- Ada bagian isi yang tidak terpotong dan panjang konten tidak ditentukan.
- Potongan isi tidak dapat diurai. Ini adalah satu-satunya kasus saat beberapa data sampai ke backend. Load balancer menutup koneksi ke klien dan backend ketika menerima potongan yang tidak dapat diurai.
Load balancer akan memblokir permintaan jika salah satu kondisi berikut terpenuhi:
- Ukuran total header permintaan dan URL permintaan melebihi batas ukuran header permintaan maksimum untuk Load Balancer Aplikasi eksternal.
- Metode permintaan tidak mengizinkan isi, tetapi permintaan memilikinya.
- Permintaan berisi header
Upgrade, dan headerUpgradetidak digunakan untuk mengaktifkan koneksi WebSocket. - Versi HTTP tidak dikenal.
Load balancer memblokir respons backend jika salah satu kondisi berikut benar:
- Ukuran total header respons melebihi batas ukuran header respons maksimum untuk Load Balancer Aplikasi eksternal.
- Versi HTTP tidak dikenal.
Distribusi traffic
Saat menambahkan grup instance backend atau NEG ke layanan backend, Anda menentukan mode penyeimbangan, yang menentukan metode yang mengukur beban backend dan kapasitas target. Load Balancer Aplikasi Eksternal mendukung dua mode penyeimbangan:
RATE, untuk grup instance atau NEG, adalah jumlah maksimum permintaan (kueri) per detik (RPS, QPS) target. RPS/QPS maksimum target dapat dilampaui jika semua backend mencapai atau di atas kapasitas.UTILIZATIONadalah pemakaian backend VM dalam grup instance.
Cara traffic didistribusikan di antara backend bergantung pada mode load balancer.
Load Balancer Aplikasi eksternal global
Sebelum Google Front End (GFE) mengirim permintaan ke instance backend, GFE memperkirakan instance backend mana yang memiliki kapasitas untuk menerima permintaan. Estimasi kapasitas ini dibuat secara proaktif, tidak pada saat permintaan masuk. GFE menerima informasi berkala tentang kapasitas yang tersedia dan mendistribusikan permintaan yang masuk sebagaimana mestinya.
Arti kapasitas bergantung sebagian pada mode penyeimbangan. Untuk mode RATE, caranya relatif sederhana: GFE menentukan dengan tepat jumlah permintaan yang dapat
ditetapkan per detik. Load balancing berbasis UTILIZATION lebih kompleks: load balancer memeriksa pemakaian instance saat ini, lalu memperkirakan pemuatan kueri yang dapat ditangani setiap instance. Estimasi ini berubah dari waktu ke waktu seiring perubahan penggunaan
instance dan pola traffic.
Kedua faktor tersebut—estimasi kapasitas dan penetapan proaktif—memengaruhi distribusi di antara instance. Dengan demikian, Cloud Load Balancing berperilaku berbeda dengan load balancer round-robin sederhana yang menyebarkan permintaan tepat 50:50 di antara dua instance. Sebagai gantinya, Google Cloud load balancing akan mencoba mengoptimalkan pemilihan instance backend untuk setiap permintaan.
Untuk Load Balancer Aplikasi eksternal global, load balancing memiliki dua tingkat. Mode balancing menentukan pembobotan atau fraksi traffic yang harus dikirim ke setiap backend (grup instance atau NEG). Kemudian, kebijakan load balancing (LocalityLbPolicy) menentukan cara traffic didistribusikan ke instance atau endpoint dalam grup. Untuk informasi selengkapnya, lihat Kebijakan lokalitas
load balancing (dokumentasi API
layanan backend).
Untuk Load Balancer Aplikasi klasik, mode balancing digunakan untuk memilih backend yang paling disukai (grup instance atau NEG). Traffic kemudian didistribusikan secara round robin di antara instance atau endpoint dalam backend.
Cara permintaan didistribusikan
Load Balancer Aplikasi eksternal berbasis GFE menggunakan proses berikut untuk mendistribusikan permintaan masuk:
- Dari klien hingga GFE lapisan pertama. Router edge memberitahukan alamat IP eksternal aturan penerusan di batas jaringan Google.
Setiap iklan mencantumkan hop berikutnya ke sistem load balancing Lapisan 3/4 (Maglev). Sistem Maglev merutekan traffic ke Google Front End (GFE) lapisan pertama.
- Saat menggunakan Paket Premium, Google mengiklankan alamat IP load balancer Anda dari semua titik kehadiran di seluruh dunia. Setiap alamat IP load balancer adalah anycast global.
- Saat menggunakan Paket Standar, Google memberitahukan alamat IP load balancer Anda dari titik kehadiran yang terkait dengan region aturan penerusan. Load balancer tersebut menggunakan alamat IP eksternal regional. Penggunaan aturan penerusan Tingkat Standar membatasi Anda ke backend NEG grup dan zona di region yang sama dengan aturan penerusan load balancer.
- Dari GFE lapis pertama hingga GFE lapis kedua. GFE lapisan pertama
menghentikan TLS jika diperlukan, lalu merutekan traffic ke GFE lapisan kedua
sesuai dengan proses berikut:
- GFE lapisan pertama mengurai peta URL dan memilih layanan backend atau bucket backend.
- Untuk layanan backend dengan NEG internet, GFE lapisan pertama memilih gateway penerusan eksternal lapis kedua yang ditempatkan bersama GFE lapisan pertama. Gateway penerusan mengirimkan permintaan ke endpoint NEG internet. Ini mengakhiri proses distribusi permintaan untuk NEG internet.
- Untuk layanan backend dengan NEG Serverless, NEG Private Service Connect (PSC), dan bucket backend, GFE lapisan pertama memilih GFE lapis kedua di region yang cocok dengan region NEG atau bucket. Untuk bucket Cloud Storage multi-region, GFE lapis pertama memilih GFE lapis kedua di suatu region sedekat mungkin dengan GFE lapis pertama (ditentukan oleh waktu round trip jaringan).
- Untuk layanan backend dengan grup instance,
NEG zona dengan
endpoint
GCE_VM_IP_PORT, dan NEG campuran, sistem pengelolaan kapasitas Google memberi tahu GFE lapisan pertama tentang kapasitas yang digunakan dan dikonfigurasi untuk setiap backend. Kapasitas yang dikonfigurasi untuk backend ditentukan oleh mode penyeimbangan, kapasitas target dari mode penyeimbangan, dan penskala kapasitas.- Tingkat Standar: GFE lapisan pertama memilih GFE lapisan kedua di region yang berisi backend.
- Paket Premium: GFE lapis pertama memilih GFE lapis kedua dari serangkaian wilayah yang berlaku. Region yang berlaku adalah semua region tempat backend telah dikonfigurasi, kecuali region dengan backend terkonfigurasi yang memiliki kapasitas nol. GFE lapisan pertama memilih GFE lapis kedua yang terdekat di region yang berlaku (ditentukan oleh waktu round-trip jaringan). Jika backend dikonfigurasi di dua region atau lebih, GFE lapisan pertama dapat memindahkan permintaan ke region lain yang berlaku jika region pilihan pertama penuh. Spillover ke region lain dapat terjadi saat semua backend di region pilihan pertama mencapai kapasitasnya.
- GFE lapisan kedua memilih backend. GFE lapis kedua terletak di
zona suatu region. Mereka menggunakan proses berikut untuk memilih backend:
- Untuk layanan backend dengan NEG serverless, NEG Private Service Connect, dan bucket backend, GFE lapis kedua meneruskan permintaan ke sistem produksi Google. Langkah ini mengakhiri proses distribusi permintaan untuk backend ini.
Untuk layanan backend dengan grup instance, NEG zona dengan endpoint
GCE_VM_IP_PORT, dan NEG campuran, sistem pemeriksaan health check Google memberi tahu GFE lapis kedua tentang status health check instance atau endpoint backend.Paket Premium saja: Jika GFE lapis kedua tidak memiliki instance backend atau endpoint yang responsif di regionnya, GFE lapis kedua mungkin akan mengirim permintaan ke GFE lapis kedua lainnya di region yang berlaku dengan backend yang telah dikonfigurasi. Tumpahan antara GFE lapis kedua di region yang berbeda tidak menghabiskan semua kemungkinan kombinasi region-ke-region. Jika perlu mengarahkan traffic keluar dari backend di region tertentu, daripada mengonfigurasi backend untuk gagal dalam health check, Anda harus menetapkan scaler kapasitas backend ke nol agar GFE lapisan pertama mengecualikan region tersebut selama langkah sebelumnya.
GFE lapisan kedua kemudian mengarahkan permintaan ke instance backend atau endpoint di zona dalam region-nya seperti yang dibahas di langkah berikutnya.
GFE lapisan kedua memilih sebuah zona. Secara default, GFE lapis kedua menggunakan algoritma
WATERFALL_BY_REGION, di mana setiap GFE lapis kedua lebih memilih untuk memilih endpoint atau instance backend di zona yang sama dengan zona yang berisi GFE lapis kedua. KarenaWATERFALL_BY_REGIONmeminimalkan traffic antarzona, dengan rasio permintaan yang rendah, setiap GFE lapis kedua dapat secara eksklusif mengirim permintaan ke backend di zona yang sama dengan GFE lapis kedua itu sendiri.Khusus untuk Load Balancer Aplikasi eksternal global, GFE lapisan kedua dapat dikonfigurasi untuk menggunakan salah satu dari algoritma alternatif berikut menggunakan
serviceLbPolicy:SPRAY_TO_REGION: GFE lapisan kedua tidak lebih memilih untuk memilih backend atau instance backend di zona yang sama dengan GFE lapisan kedua. GFE lapisan kedua mencoba mendistribusikan traffic ke semua endpoint atau instance backend di semua zona region. Hal ini dapat menghasilkan distribusi beban yang lebih merata dengan mengorbankan peningkatan traffic antarzona.WATERFALL_BY_ZONE: GFE lapisan kedua lebih memilih untuk memilih endpoint atau instance backend di zona yang sama dengan GFE lapis kedua. GFE lapisan kedua hanya mengarahkan permintaan ke backend di zona yang berbeda setelah semua backend di zona saat ini mencapai kapasitas yang telah dikonfigurasi.
- GFE lapisan kedua memilih instance atau endpoint dalam zona. Secara
default, GFE lapis kedua mendistribusikan permintaan di antara backend dengan cara round-robin. Khusus untuk Load Balancer Aplikasi eksternal global, Anda dapat mengubah setelan ini menggunakan kebijakan lokalitas load balancing (
localityLbPolicy). Kebijakan lokalitas load balancing hanya berlaku untuk backend dalam zona yang dipilih yang dibahas pada langkah sebelumnya.
Load Balancer Aplikasi eksternal regional
Untuk Load Balancer Aplikasi eksternal regional, distribusi traffic didasarkan pada mode load balancing dan kebijakan lokalitas load balancing.
Mode balancing menentukan bobot dan fraksi traffic yang harus dikirim ke setiap grup (grup instance atau NEG). Kebijakan lokalitas load balancing
(LocalityLbPolicy) menentukan cara backend dalam grup di-load balanced.
Saat layanan backend menerima traffic, layanan tersebut akan mengarahkan traffic ke backend (grup instance atau NEG) terlebih dahulu sesuai dengan mode penyeimbangan backend. Setelah backend dipilih, traffic kemudian didistribusikan di antara instance atau endpoint di grup backend tersebut sesuai dengan kebijakan lokalitas load balancing.
Untuk informasi selengkapnya, lihat referensi berikut:
Afinitas sesi
Afinitas sesi memberikan upaya terbaik untuk mengirim permintaan dari klien tertentu ke backend yang sama selama backend responsif dan memiliki kapasitas, sesuai dengan mode penyeimbangan yang dikonfigurasi.
Saat Anda menggunakan afinitas sesi, sebaiknya gunakan mode penyeimbangan RATE, bukan
UTILIZATION. Afinitas sesi akan berfungsi optimal jika Anda menetapkan mode penyeimbangan
ke permintaan per detik (RPS).
Load Balancer Aplikasi Eksternal menawarkan jenis afinitas sesi berikut:
- TIDAK ADA. Afinitas sesi belum ditetapkan untuk load balancer.
- Afinitas IP Klien
- Afinitas cookie yang dihasilkan
- Afinitas kolom header
- Afinitas Cookie HTTP
Tabel berikut meringkas opsi afinitas sesi yang didukung oleh Load Balancer Aplikasi eksternal di setiap mode:
| Mode load balancer | Opsi minat sesi | ||||
|---|---|---|---|---|---|
| Tidak ada | IP Klien | Cookie yang dihasilkan | Kolom header | Cookie HTTP | |
| Load Balancer Aplikasi eksternal global | |||||
| Load Balancer Aplikasi Klasik | |||||
| Load Balancer Aplikasi eksternal regional | |||||
Dukungan HTTP/2
HTTP/2 adalah revisi utama dari protokol HTTP/1. HTTP/2 didukung untuk koneksi antara klien dan Load Balancer Aplikasi eksternal, serta untuk koneksi antara load balancer dan backend-nya.
Load balancer menegosiasikan HTTP/2 dengan klien secara otomatis sebagai bagian dari handshake TLS menggunakan ekstensi TLS ALPN. Meskipun load balancer dikonfigurasi untuk menggunakan HTTPS, klien modern akan ditetapkan secara default ke HTTP/2. Hal ini dikontrol di sisi klien, bukan di load balancer.
Jika klien tidak mendukung HTTP/2 dan load balancer dikonfigurasi untuk menggunakan HTTP/2 antara load balancer dan backend instance, load balancer mungkin masih menegosiasikan koneksi HTTPS atau menerima permintaan HTTP yang tidak aman. Permintaan HTTPS atau HTTP tersebut kemudian diubah oleh load balancer untuk mem-proxy permintaan melalui HTTP/2 ke backend instance.
Untuk menggunakan HTTP/2, Anda harus mengaktifkan TLS di backend Anda. Untuk informasi selengkapnya, lihat Enkripsi dari load balancer ke backend.
Streaming serentak maksimum HTTP/2
Setelan SETTINGS_MAX_CONCURRENT_STREAMS HTTP/2 menjelaskan jumlah aliran maksimum yang diterima endpoint, yang dimulai oleh peer. Nilai yang diiklankan oleh klien HTTP/2 ke load balancer Google Cloud tidaklah bermakna karena load balancer tidak memulai streaming ke klien.
Jika load balancer menggunakan HTTP/2 untuk berkomunikasi dengan server
yang berjalan di VM, load balancer akan mematuhi
nilai SETTINGS_MAX_CONCURRENT_STREAMS yang diiklankan oleh server. Jika nilai nol diiklankan, load balancer tidak dapat meneruskan permintaan ke server, dan hal ini dapat menyebabkan error.
Batasan HTTP/2
- HTTP/2 antara load balancer dan instance mungkin memerlukan koneksi TCP yang jauh lebih banyak ke instance daripada HTTP(S). Penggabungan koneksi, pengoptimalan yang mengurangi jumlah koneksi ini dengan HTTP(S), saat ini tidak tersedia dengan HTTP/2. Akibatnya, Anda mungkin melihat latensi backend yang tinggi karena koneksi backend dibuat lebih sering.
- HTTP/2 antara load balancer dan backend tidak mendukung pengoperasian Protokol WebSocket melalui aliran tunggal koneksi HTTP/2 (RFC 8441).
- HTTP/2 antara load balancer dan backend tidak mendukung server push.
- Tingkat error gRPC dan volume permintaan tidak terlihat di Google Cloud API atau Konsol Google Cloud. Jika endpoint gRPC menampilkan error, log load balancer dan data pemantauan akan melaporkan kode respons
HTTP
OK 200.
Dukungan HTTP/3
HTTP/3 adalah protokol internet generasi berikutnya. API ini dibuat berdasarkan IETF QUIC, sebuah protokol yang dikembangkan dari protokol Google QUIC asli. HTTP/3 didukung antara Load Balancer Aplikasi eksternal, Cloud CDN, dan klien.
Secara khusus:
- IETF QUIC adalah protokol lapisan transpor yang memberikan kontrol kemacetan dan keandalan yang mirip dengan TCP, menggunakan TLS 1.3 untuk keamanan, dan meningkatkan performa.
- HTTP/3 adalah lapisan aplikasi yang dibangun di atas IETF QUIC, dan bergantung pada QUIC untuk menangani multiplexing, kontrol kemacetan, deteksi kehilangan, dan transmisi ulang.
- HTTP/3 memungkinkan inisiasi koneksi klien yang lebih cepat, menghilangkan pemblokiran head-of-line di stream multipleks, dan mendukung migrasi koneksi saat alamat IP klien berubah.
- HTTP/3 didukung untuk koneksi antara klien dan load balancer, bukan koneksi antara load balancer dan backend-nya.
- Koneksi HTTP/3 menggunakan algoritma kontrol kemacetan BBR.
HTTP/3 di load balancer Anda dapat mempercepat waktu muat halaman, mengurangi buffering ulang video, dan meningkatkan throughput pada koneksi latensi yang lebih tinggi.
Tabel berikut menentukan dukungan HTTP/3 untuk Load Balancer Aplikasi eksternal di setiap mode.
| Mode load balancer | Dukungan HTTP/3 |
|---|---|
| Load Balancer Aplikasi eksternal global (selalu Paket Premium) | |
| Load Balancer Aplikasi Klasik di Paket Premium | |
| Load Balancer Aplikasi Klasik di Tingkat Standar | |
| Load Balancer Aplikasi eksternal regional (Paket Premium atau Standar) |
Cara HTTP/3 dinegosiasikan
Saat HTTP/3 diaktifkan, load balancer memberitahukan dukungan ini kepada klien, sehingga klien yang mendukung HTTP/3 dapat mencoba membuat koneksi HTTP/3 dengan load balancer HTTPS.
- Klien yang diterapkan dengan benar selalu kembali ke HTTPS atau HTTP/2 jika tidak dapat membuat koneksi HTTP/3.
- Klien yang mendukung HTTP/3 menggunakan pengetahuan mereka yang disimpan dalam cache tentang dukungan HTTP/3 untuk menyimpan perjalanan bolak-balik yang tidak perlu di masa mendatang.
- Karena penggantian ini, mengaktifkan atau menonaktifkan HTTP/3 di load balancer tidak akan mengganggu kemampuan load balancer untuk terhubung ke klien.
Dukungan diiklankan di header respons HTTP Alt-Svc. Jika HTTP/3 diaktifkan, respons dari load balancer akan menyertakan nilai header alt-svc berikut:
alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000"
Jika HTTP/3 telah secara eksplisit ditetapkan ke DISABLE, respons tidak akan menyertakan header respons alt-svc.
Jika Anda mengaktifkan HTTP/3 di load balancer HTTPS, beberapa keadaan dapat menyebabkan klien kembali ke HTTPS atau HTTP/2, bukan menegosiasikan HTTP/3. Contoh ini meliputi:
- Jika klien mendukung versi HTTP/3 yang tidak kompatibel dengan versi HTTP/3 yang didukung oleh load balancer HTTPS.
- Saat load balancer mendeteksi bahwa traffic UDP diblokir atau dibatasi kapasitasnya dengan cara yang akan mencegah HTTP/3 berfungsi.
- Klien sama sekali tidak mendukung HTTP/3, sehingga tidak mencoba menegosiasikan koneksi HTTP/3.
Saat koneksi beralih kembali ke HTTPS atau HTTP/2, kami tidak menganggap ini sebagai kegagalan load balancer.
Sebelum mengaktifkan HTTP/3, pastikan perilaku yang dijelaskan sebelumnya dapat diterima untuk beban kerja Anda.
Mengonfigurasi HTTP/3
NONE (default) dan ENABLE mengaktifkan dukungan HTTP/3 untuk load balancer Anda.
Saat HTTP/3 diaktifkan, load balancer akan memberitahukannya kepada klien, sehingga klien yang mendukungnya dapat menegosiasikan versi HTTP/3 dengan load balancer. Klien yang tidak mendukung HTTP/3 tidak menegosiasikan koneksi HTTP/3. Anda tidak perlu menonaktifkan HTTP/3 secara eksplisit kecuali jika Anda telah mengidentifikasi implementasi klien yang rusak.
Load Balancer Aplikasi Eksternal menyediakan tiga cara untuk mengonfigurasi HTTP/3 seperti yang ditunjukkan dalam tabel berikut.
| Nilai quicOverride | Perilaku |
|---|---|
NONE |
Dukungan untuk HTTP/3 diiklankan kepada klien. |
ENABLE |
Dukungan untuk HTTP/3 diiklankan kepada klien. Catatan: TLS 0-RTT (juga dikenal sebagai TLS Early Data) belum didukung untuk HTTP/3. |
DISABLE |
Secara eksplisit menonaktifkan iklan HTTP/3 dan Google QUIC kepada klien. |
Untuk mengaktifkan (atau menonaktifkan) HTTP/3 secara eksplisit, ikuti langkah-langkah berikut.
Konsol: HTTPS
Di Konsol Google Cloud, buka halaman Load balancing.
Pilih load balancer yang ingin diedit.
Klik Frontend configuration.
Pilih alamat IP dan port frontend yang ingin diedit. Untuk mengedit konfigurasi HTTP/3, protokolnya harus berupa HTTPS.
Mengaktifkan HTTP/3
- Pilih drop-down QUIC negotiation.
- Untuk mengaktifkan HTTP/3 secara eksplisit untuk frontend ini, pilih Enabled.
- Jika Anda memiliki beberapa aturan frontend yang mewakili IPv4 dan IPv6, pastikan untuk mengaktifkan HTTP/3 pada setiap aturan.
Menonaktifkan HTTP/3
- Pilih drop-down QUIC negotiation.
- Untuk menonaktifkan HTTP/3 secara eksplisit untuk frontend ini, pilih Disabled.
- Jika Anda memiliki beberapa aturan frontend yang mewakili IPv4 dan IPv6, pastikan untuk menonaktifkan HTTP/3 untuk setiap aturan.
gcloud: HTTPS
Sebelum menjalankan perintah ini, Anda harus membuat resource sertifikat SSL untuk setiap sertifikat.
gcloud compute target-https-proxies create HTTPS_PROXY_NAME \
--global \
--quic-override=QUIC_SETTING
Ganti QUIC_SETTING dengan salah satu dari yang berikut ini:
NONE(default): memungkinkan Google mengontrol kapan HTTP/3 diiklankan.Jika Anda memilih
NONE, HTTP/3 akan diiklankan kepada klien, tetapi Google QUIC tidak diiklankan. Di konsol Google Cloud, opsi ini disebut Automatic (Default).ENABLE: mengiklankan HTTP/3 kepada klien.DISABLE: tidak mengiklankan HTTP/3 kepada klien.
API: HTTPS
POST https://www.googleapis.com/v1/compute/projects/PROJECT_ID/global/targetHttpsProxies/TARGET_PROXY_NAME/setQuicOverride
{
"quicOverride": QUIC_SETTING
}
Ganti QUIC_SETTING dengan salah satu dari yang berikut ini:
NONE(default): Mengizinkan Google mengontrol kapan HTTP/3 diiklankan.Saat ini, jika Anda memilih
NONE, HTTP/3 akan diiklankan kepada klien, tetapi Google QUIC tidak diiklankan.Di konsol Google Cloud, opsi ini disebut Automatic (Default).
ENABLE: Mengiklankan HTTP/3 dan Google QUIC kepada klien.DISABLE: Tidak mengiklankan HTTP/3 atau Google QUIC kepada klien.
Batasan
- Load balancer HTTPS tidak mengirim pemberitahuan penutupan
close_notifysaat menghentikan koneksi SSL. Artinya, load balancer menutup koneksi TCP, bukan melakukan penonaktifan SSL. - Load balancer HTTPS hanya mendukung karakter huruf kecil di
domain dalam atribut nama umum (
CN) atau atribut nama alternatif subjek (SAN) dari sertifikat. Sertifikat dengan karakter huruf besar dalam domain hanya ditampilkan jika ditetapkan sebagai sertifikat utama di proxy target. - Load balancer HTTPS tidak menggunakan ekstensi Server Name Indication (SNI) saat terhubung ke backend, kecuali untuk load balancer dengan backend Internet NEG. Untuk detail selengkapnya, lihat Enkripsi dari load balancer ke backend.
- Saat menggunakan Load Balancer Aplikasi eksternal regional dengan Cloud Run di lingkungan VPC Bersama, jaringan VPC yang berdiri sendiri dalam project layanan dapat mengirim traffic ke layanan Cloud Run lain yang di-deploy di project layanan lain dalam lingkungan VPC Bersama yang sama. Ini adalah masalah umum dan bentuk akses ini akan diblokir di masa mendatang.
- Google Cloud tidak menjamin bahwa koneksi TCP dasar dapat tetap terbuka selama keseluruhan nilai waktu tunggu layanan backend. Sistem klien harus menerapkan logika mencoba ulang, bukan mengandalkan koneksi TCP agar terbuka dalam waktu yang lama.
- Anda tidak dapat membuat Load Balancer Aplikasi eksternal regional di Paket Premium menggunakan Konsol Google Cloud. Sebagai gantinya, gunakan gcloud CLI atau API.
Langkah selanjutnya
- Untuk mempelajari cara men-deploy Load Balancer Aplikasi eksternal global, lihat Menyiapkan Load Balancer Aplikasi eksternal dengan backend Compute Engine.
- Untuk mempelajari cara men-deploy Load Balancer Aplikasi eksternal regional, lihat Menyiapkan Load Balancer Aplikasi eksternal regional dengan backend Compute Engine.
- Jika Anda adalah pengguna Load Balancer Aplikasi klasik yang sudah ada, pastikan Anda meninjau Merencanakan migrasi ke Load Balancer Aplikasi eksternal global saat merencanakan deployment baru dengan Load Balancer Aplikasi eksternal global.
- Untuk mempelajari cara mengotomatiskan penyiapan Load Balancer Aplikasi eksternal Anda dengan Terraform, lihat contoh modul Terraform untuk Load Balancer Aplikasi eksternal.
- Untuk mempelajari cara mengonfigurasi kemampuan pengelolaan traffic lanjutan yang tersedia dengan Load Balancer Aplikasi eksternal global, lihat Ringkasan pengelolaan traffic untuk Load Balancer Aplikasi eksternal global.
- Untuk mempelajari cara mengonfigurasi kemampuan pengelolaan traffic lanjutan yang tersedia dengan Load Balancer Aplikasi eksternal regional, lihat Ringkasan pengelolaan traffic untuk Load Balancer Aplikasi eksternal regional.
- Untuk menemukan lokasi PoP Google, lihat lokasi GFE.
- Untuk mempelajari pengelolaan kapasitas, lihat Tutorial pengelolaan kapasitas dengan load balancing dan Pengoptimalan kapasitas aplikasi dengan load balancing global.
- Untuk mempelajari cara menayangkan situs, lihat Menayangkan situs.
- Untuk mempelajari cara menggunakan Certificate Manager guna menyediakan dan mengelola sertifikat SSL, lihat Ringkasan Certificate Manager.
- Untuk memasukkan logika kustom ke jalur data load balancing, konfigurasikan info Ekstensi Layanan.