Anda sedang melihat dokumentasi Apigee Edge.
Buka
Dokumentasi Apigee X. info
Apigee Edge meningkatkan ketersediaan API dengan menyediakan dukungan bawaan untuk pemuatan balancing dan failover di beberapa backend instance server.
Konfigurasi TargetServer memisahkan URL endpoint konkret dari TargetEndpoint konfigurasi standar. Setiap TargetServer direferensikan oleh nama di TargetEndpoint Koneksi HTTP. Daripada menetapkan URL konkret dalam konfigurasi, Anda dapat mengonfigurasinya atau lebih bernama TargetServers seperti yang dijelaskan di bagian TargetEndpoint.
Definisi TargetServer terdiri dari nama, {i>host<i} dan porta, dengan elemen tambahan untuk menunjukkan apakah TargetServer diaktifkan atau dinonaktifkan.
Video
Tonton video berikut untuk mempelajari lebih lanjut tentang perutean dan load balancing API menggunakan target server
Video | Deskripsi |
---|---|
Load balancing menggunakan server target | Load balancing API di seluruh server target. |
Berbasis perutean API di lingkungan menggunakan server target | Rutekan API ke server target yang berbeda berdasarkan lingkungan. |
Perutean API dan load balancing menggunakan server target (Edge Klasik) | Merutekan API ke server target yang berbeda berdasarkan lingkungan dan load balancing API Anda di seluruh server target di UI Classic Edge. |
Contoh Konfigurasi TargetServer
Kode berikut menentukan server target:
<TargetServer name="target1"> <Host>1.mybackendservice.com</Host> <Port>80</Port> <IsEnabled>true</IsEnabled> </TargetServer >
Elemen Konfigurasi TargetServer
Tabel berikut menjelaskan elemen yang digunakan untuk membuat dan mengonfigurasi TargetServer:
Nama | Deskripsi | Default | Wajib? |
---|---|---|---|
name |
Nama konfigurasi TargetServer, yang harus unik dalam lingkungan fleksibel App Engine. Nama TargetServer hanya boleh berisi karakter alfanumerik. | T/A | Ya |
Host |
URL host layanan backend (tanpa protokol). | T/A | Ya |
Port |
Port tempat layanan backend mendeteksi | T/A | Ya |
IsEnabled |
Boolean yang menunjukkan apakah konfigurasi TargetServer diaktifkan atau dinonaktifkan. Hal ini memungkinkan Anda untuk mengeluarkan TargetServers dari rotasi tanpa memodifikasi proxy API konfigurasi Anda. Penggunaan yang umum adalah menulis aplikasi atau skrip yang mengaktifkan atau menonaktifkan TargetServer secara otomatis berdasarkan persyaratan kapasitas yang diharapkan, jadwal pemeliharaan, dll. | true |
Ya |
Mengelola server target menggunakan UI
Kelola server target, seperti yang dijelaskan di bawah.
Edge
Untuk mengelola server target menggunakan UI Edge:
- Login ke apigee.com/edge.
- Pilih Admin > Lingkungan > Target Servers di menu navigasi sebelah kiri.
- Pilih lingkungan yang diinginkan, seperti test atau prod.
- Untuk membuat server target:
- Klik + Target server.
- Masukkan nama, host, dan port untuk server target.
Contoh:
- Nama: target1
- Host: 1.mybackendservice.com
- Port: 80
- Pilih SSL, jika diperlukan.
- Pilih Enabled untuk mengaktifkan server target.
- Klik Tambahkan.
- Untuk mengedit server target:
- Posisikan kursor pada server target yang ingin Anda edit untuk menampilkan menu tindakan.
- Klik .
- Edit nilai server Targer.
- Klik Perbarui.
- Untuk menghapus server target:
- Posisikan kursor di atas server target yang ingin Anda hapus untuk menampilkan menu tindakan.
- Klik .
- Klik Delete untuk mengonfirmasi operasi.
Edge Klasik (Private Cloud)
Untuk mengakses wizard Create Proxy menggunakan UI Classic Edge:
- Login ke
http://ms-ip:9000
, dengan ms-ip sebagai Alamat IP atau nama DNS node Server Pengelolaan. - Pilih API > Konfigurasi Lingkungan > Target Servers di menu navigasi sebelah kiri.
- Pilih lingkungan yang diinginkan, seperti test atau prod.
- Untuk membuat server target:
- Klik Edit.
- Klik + Target server.
- Masukkan nama, host, dan port untuk server target.
Contoh:
- Nama: target1
- Host: 1.mybackendservice.com
- Port: 80
- Pilih Enabled untuk mengaktifkan server target.
- Klik Simpan.
- Untuk mengedit server target:
- Klik Edit.
- Edit nilai server Targer.
- Klik Simpan.
- Untuk menghapus server target:
- Klik Edit.
- Klik Hapus.
Mengelola server target menggunakan API
Anda dapat menggunakan Edge API untuk membuat, menghapus, memperbarui, mendapatkan, dan membuat daftar server target. Sebagai informasi selengkapnya, lihat TargetServers.
Gunakan panggilan API berikut untuk membuat server target:
$ curl -H "Content-Type:text/xml" -X POST -d \ '<TargetServer name="target1"> <Host>1.mybackendservice.com</Host> <Port>80</Port> <IsEnabled>true</IsEnabled> </TargetServer>' \ -u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers
Contoh Respons:
{ "host" : "1.mybackendservice.com", "isEnabled" : true, "name" : "target1", "port" : 80 }
Setelah Anda membuat TargetServer pertama, gunakan panggilan API berikut untuk membuat TargetServer kedua. Dengan menentukan dua TargetServer, Anda menyediakan dua URL yang dapat digunakan TargetEndpoint untuk load balancing:
$ curl -H "Content-type:text/xml" -X POST -d \ '<TargetServer name="target2"> <Host>2.mybackendservice.com</Host> <Port>80</Port> <IsEnabled>true</IsEnabled> </TargetServer >' \ -u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers
Contoh Respons:
{ "host" : "2.mybackendservice.com", "isEnabled" : true, "name" : "target2", "port" : 80 }
Gunakan panggilan API berikut untuk mengambil daftar TargetServers di lingkungan:
$ curl -u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers
Contoh respons:
[ "target2", "target1" ]
Saat ini ada dua TargetServer yang tersedia untuk digunakan oleh proxy API yang di-deploy dalam pengujian lingkungan fleksibel App Engine. Untuk melakukan load balancing pada traffic di seluruh TargetServers ini, Anda mengonfigurasi di endpoint target proxy API untuk menggunakan TargetServers.
Ada batas 500 TargetServers per lingkungan, karena didokumentasikan dalam topik Batas.
Mengonfigurasi TargetEndpoint untuk melakukan load balancing di seluruh TargetServers yang diberi nama
Sekarang setelah Anda memiliki dua TargetServers yang tersedia, Anda dapat memodifikasi pengaturan koneksi untuk mereferensikan kedua TargetServer tersebut berdasarkan nama:
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Server name="target1" /> <Server name="target2" /> </LoadBalancer> <Path>/test</Path> </HTTPTargetConnection> </TargetEndpoint>
Konfigurasi di atas adalah konfigurasi load balancing yang paling dasar. Beban load balancer mendukung tiga algoritma load balancing, yaitu Round Robin, Weighted, dan Least Connection. Round Robin adalah algoritma default. Karena tidak ada algoritma yang ditentukan dalam konfigurasi di atas, permintaan keluar dari proxy API ke server backend akan bergantian, satu untuk satu, target1 dan target 2.
Elemen <Path>
membentuk jalur dasar URI TargetEndpoint untuk
semua server target. Kolom ini hanya digunakan saat <LoadBalancer>
digunakan. Jika tidak, akan
akan diabaikan. Pada contoh di atas, permintaan yang menjangkau "target1" akan menjadi
http://target1/test
, dan seterusnya untuk server target lainnya.
Menetapkan opsi load balancer
Anda dapat menyesuaikan ketersediaan dengan menggunakan opsi untuk load balancing dan failover saat pemuatan dan TargetServer di Google Cloud. Bagian ini menjelaskan opsi tersebut.
Algoritma
Menetapkan algoritma yang digunakan oleh <LoadBalancer>
. Ketersediaan
algoritmanya adalah RoundRobin
, Weighted
, dan LeastConnections
,
yang masing-masing didokumentasikan di bawah ini.
Round robin
Algoritma {i>default<i}, {i>round robin<i}, meneruskan permintaan ke setiap TargetServer sesuai urutan server yang terdaftar dalam koneksi HTTP endpoint target. Contoh:
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Algorithm>RoundRobin</Algorithm> <Server name="target1" /> <Server name="target2" /> </LoadBalancer> <Path>/test</Path> </HTTPTargetConnection> </TargetEndpoint>
Berbobot
Algoritma load balancing tertimbang memungkinkan Anda mengonfigurasi pemuatan traffic
TargetServers Anda. LoadBalancer tertimbang mendistribusikan permintaan ke TargetServers Anda secara langsung
proporsi untuk setiap bobot TargetServer. Oleh karena itu, algoritma berbobot
mengharuskan Anda menetapkan
atribut weight
untuk setiap TargetServer. Contoh:
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Algorithm>Weighted</Algorithm> <Server name="target1"> <Weight>1</Weight> </Server> <Server name="target2"> <Weight>2</Weight> </Server> </LoadBalancer> <Path>/test</Path> </HTTPTargetConnection> </TargetEndpoint>
Dalam contoh ini, dua permintaan akan dirutekan ke target2 untuk setiap satu permintaan yang dirutekan ke target1.
Koneksi Paling Jarang
LoadBalancer dikonfigurasi untuk menggunakan algoritma koneksi paling sedikit mengarahkan permintaan keluar ke TargetServer dengan koneksi HTTP terbuka paling sedikit. Contoh:
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Algorithm>LeastConnections</Algorithm> <Server name="target1" /> <Server name="target2" /> </LoadBalancer> </HTTPTargetConnection> <Path>/test</Path> </TargetEndpoint>
Kegagalan maksimum
Jumlah maksimum permintaan yang gagal dari proxy API ke TargetServer yang menyebabkan permintaan dialihkan ke TargetServer lain.
Kegagalan respons berarti Apigee tidak menerima respons apa pun dari server target. Kapan ini terjadi, penghitung kegagalan bertambah satu.
Namun, ketika Apigee menerima respons dari target,
meskipun responsnya adalah error HTTP (seperti 500
), yang dihitung sebagai respons dari
server target, dan penghitung
kegagalan akan diatur ulang. Untuk membantu memastikan bahwa respons HTTP yang buruk
(seperti 500
) juga akan menambah penghitung kegagalan untuk mengeluarkan server yang tidak responsif
rotasi load balancing sesegera mungkin, Anda dapat menambahkan
Elemen <ServerUnhealthyResponse>
dengan <ResponseCode>
elemen turunan ke konfigurasi load balancer. Edge juga akan menghitung respons
kode sebagai kegagalan.
Dalam contoh berikut, target1
akan dihapus dari rotasi setelah lima
permintaan yang gagal, termasuk beberapa respons 5XX
dari server target.
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Algorithm>RoundRobin</Algorithm> <Server name="target1" /> <Server name="target2" /> <MaxFailures>5</MaxFailures> <ServerUnhealthyResponse> <ResponseCode>500</ResponseCode> <ResponseCode>502</ResponseCode> <ResponseCode>503</ResponseCode> </ServerUnhealthyResponse> </LoadBalancer> <Path>/test</Path> </HTTPTargetConnection> </TargetEndpoint>
Default MaxFailures adalah 0. Hal ini berarti bahwa Edge selalu mencoba terhubung ke target untuk setiap permintaan dan tidak pernah menghapus server target dari rotasi.
Sebaiknya gunakan MaxFailures > 0 dengan HealthMonitor. Jika Anda mengonfigurasi MaxFailures > 0, TargetServer dihapus dari rotasi jika target gagal, berapa kali yang Anda tentukan. Ketika seorang HealthMonitor sudah diterapkan, Apigee secara otomatis menempatkan TargetServer kembali berputar setelah target aktif dan berjalan lagi, sesuai dengan konfigurasi HealthMonitor tersebut. Lihat Pemantauan kesehatan untuk informasi selengkapnya.
Atau, jika Anda mengonfigurasi MaxFailures > 0, dan Anda tidak mengonfigurasi HealthMonitor, Apigee tidak akan menyertakan kembali TargetServer ke dalam rotasi secara otomatis setelah Apigee mendeteksi kegagalan. Dalam hal ini, Anda harus men-deploy ulang proxy API sebelum Apigee mengembalikan TargetServer ke kunci. Lihat Men-deploy proxy API.
Coba lagi
Jika percobaan ulang diaktifkan, permintaan akan dicoba lagi setiap kali kegagalan respons (error I/O atau waktu tunggu HTTP habis)
terjadi atau respons yang diterima cocok dengan nilai yang ditetapkan oleh <ServerUnhealthyResponse>
.
Lihat Kegagalan maksimum di atas untuk mengetahui informasi selengkapnya tentang setelan
<ServerUnhealthyResponse>
.
Secara default, <RetryEnabled>
disetel ke true
. Tetapkan ke false
untuk menonaktifkan percobaan ulang.
Contoh:
<RetryEnabled>false</RetryEnabled>
IsFallback
Satu (dan hanya satu) TargetServer dapat disetel sebagai 'fallback' server tertentu. TargetServer penggantian tidak disertakan dalam rutinitas load balancing sampai semua TargetServer lainnya diidentifikasi sebagai tidak tersedia oleh load balancer. Saat load balancer menentukan bahwa semua TargetServer tidak tersedia, semua traffic dirutekan ke server penggantian. Contoh:
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Algorithm>RoundRobin</Algorithm> <Server name="target1" /> <Server name="target2" /> <Server name="target3"> <IsFallback>true</IsFallback> </Server> </LoadBalancer> <Path>/test</Path> </HTTPTargetConnection> </TargetEndpoint>
Konfigurasi di atas menghasilkan load balancing {i>round robin<i} antara target 1 dan 2 hingga target 1 dan 2 tidak tersedia. Jika target 1 dan 2 tidak tersedia, semua traffic akan dirutekan yang ditargetkan 3.
Jalur
Jalur menentukan fragmen URI yang akan ditambahkan ke semua permintaan yang dikeluarkan oleh TargetServer ke server backend.
Elemen ini menerima jalur string literal atau template pesan. Pesan
yang memungkinkan Anda melakukan substitusi string variabel saat runtime.
Misalnya, dalam definisi endpoint target berikut, nilai {mypath}
digunakan untuk jalur:
<HTTPTargetConnection> <SSLInfo> <Enabled>true</Enabled> </SSLInfo> <LoadBalancer> <Server name="testserver"/> </LoadBalancer> <Path>{mypath}</Path> </HTTPTargetConnection>
Mengonfigurasi server target untuk TLS/SSL
Jika Anda menggunakan TargetServer untuk menentukan layanan backend dan layanan backend
mengharuskan koneksi menggunakan protokol HTTPS, maka Anda harus mengaktifkan TLS/SSL di
Definisi TargetServer. Hal ini diperlukan karena tag <Host>
tidak mengizinkan Anda
menentukan protokol koneksi. Di bawah ini adalah definisi TargetServer untuk satu arah
TLS/SSL tempat Edge membuat permintaan HTTPS ke layanan backend:
<TargetServer name="target1"> <Host>mocktarget.apigee.net</Host> <Port>443</Port> <IsEnabled>true</IsEnabled> <SSLInfo> <Enabled>true</Enabled> </SSLInfo> </TargetServer>
Jika layanan backend memerlukan TLS/SSL dua arah, atau bersama, Anda TargetServer dengan menggunakan setelan konfigurasi TLS/SSL yang sama dengan TargetEndpoints:
<TargetServer name="TargetServer 1"> <IsEnabled>true</IsEnabled> <Host>www.example.com</Host> <Port>443</Port> <SSLInfo> <Ciphers/> <ClientAuthEnabled>true</ClientAuthEnabled> <Enabled>true</Enabled> <IgnoreValidationErrors>false</IgnoreValidationErrors> <KeyAlias>keystore-alias</KeyAlias> <KeyStore>keystore-name</KeyStore> <Protocols/> <TrustStore>truststore-name</TrustStore> </SSLInfo> </TargetServer >
Untuk informasi tentang properti <SSLInfo>
, seperti
<Ciphers>
dan <ClientAuthEnabled>
, lihat
informasi tentang setelan properti tersebut untuk Host Virtual di Mengonfigurasi akses TLS ke API
untuk Private Cloud.
Untuk petunjuk selengkapnya tentang mengonfigurasi TLS/SSL keluar, lihat Mengonfigurasi TLS dari Edge ke backend (Cloud dan Private Cloud).
Skema TargetServer
Lihat skema untuk TargetServer dan entitas lainnya di GitHub.
Pemantauan kesehatan
Pemantauan kondisi memungkinkan Anda meningkatkan konfigurasi load balancing dengan secara aktif melakukan polling URL layanan backend yang ditentukan dalam konfigurasi TargetServer. Dengan mengaktifkan pemantauan kesehatan, TargetServer yang gagal secara otomatis dikembalikan ke rotasi ketika HealthMonitor menentukan bahwa TargetServer aktif.
Pemantauan kondisi berfungsi dengan <MaxFailures>
. Jika pemantauan kondisi tidak diaktifkan,
<MaxFailures>
menentukan jumlah permintaan yang gagal dari proxy API ke
TargetServer yang menyebabkan permintaan dialihkan ke TargetServer lain.
TargetServer yang gagal kemudian akan diambil dari rotasi hingga Anda men-deploy ulang proxy.
Dengan pemantauan kondisi aktif, TargetServer yang gagal akan otomatis dikembalikan ke rotasi dan tanpa proxy deployment ulang diperlukan.
HealthMonitor bertindak sebagai klien sederhana yang memanggil layanan backend melalui TCP atau HTTP:
- Klien TCP hanya memastikan bahwa soket dapat dibuka.
- Anda mengonfigurasi klien HTTP untuk mengirimkan permintaan HTTP yang valid ke layanan backend. Anda
dapat menentukan operasi HTTP GET, PUT, POST, atau DELETE. Respons panggilan monitor HTTP harus cocok dengan
mengonfigurasi setelan di blok
<SuccessResponse>
.
Keberhasilan dan kegagalan
Saat Anda mengaktifkan pemantauan kondisi, Edge mulai mengirim health check ke target Anda server tertentu. Health check adalah permintaan yang dikirim ke server target yang menentukan apakah server target responsif atau tidak.
Health check dapat memiliki salah satu dari dua kemungkinan hasil:
- Berhasil: Server target dianggap responsif jika responsnya berhasil
dilakukan. Hal ini biasanya disebabkan oleh satu atau beberapa hal berikut:
- Server target menerima koneksi baru ke port yang ditentukan, merespons permintaan pada port tersebut, lalu menutup port dalam jangka waktu yang ditentukan. Respons dari server target berisi “Connection: close”
- Server target merespons permintaan health check dengan 200 (OK) atau kode status HTTP lainnya yang Anda anggap dapat diterima.
- Server target merespons permintaan health check dengan isi pesan yang cocok dengan isi pesan yang diharapkan.
Saat Edge menentukan bahwa server responsif, Edge akan melanjutkan atau melanjutkan pengiriman permintaan ke server tersebut.
- Gagal: Server target dapat gagal dalam health check dengan berbagai cara,
tergantung pada jenis pemeriksaan. Kegagalan dapat dicatat saat server target:
- Menolak koneksi dari Edge ke port health check.
- Tidak merespons permintaan health check dalam jangka waktu tertentu.
- Menampilkan kode status HTTP yang tidak diharapkan.
- Merespons dengan isi pesan yang tidak sesuai dengan isi pesan yang diharapkan.
Saat server target gagal dalam health check, Edge akan menambah jumlah kegagalan server tersebut. Jika jumlah kegagalan untuk server tersebut yang memenuhi atau melampaui batas yang telah ditentukan (
<MaxFailures>
), Edge berhenti mengirim permintaan ke server tersebut.
Mengaktifkan HealthMonitor
Untuk membuat HealthMonitor, tambahkan elemen <HealthMonitor>
ke HTTPConnection TargetEndpoint
untuk sebuah proxy. Anda tidak dapat melakukannya di UI. Sebagai gantinya, Anda membuat
konfigurasi {i>proxy<i} dan
unggah sebagai file ZIP ke Edge. Konfigurasi {i>proxy<i} adalah deskripsi
terstruktur dari semua aspek
dari proxy API. Konfigurasi proxy terdiri dari file XML dalam struktur direktori yang telah ditentukan sebelumnya. Untuk selengkapnya
informasi, lihat Proxy API
Referensi Konfigurasi.
HealthMonitor sederhana menentukan IntervalInSec
yang dikombinasikan dengan
TCPMonitor atau HTTPMonitor. Elemen <MaxFailures>
menentukan nilai maksimum
jumlah permintaan yang gagal dari proxy API ke TargetServer yang menghasilkan permintaan
sedang dialihkan ke TargetServer lain. Secara default, <MaxFailures>
adalah 0, yang berarti
Edge tidak melakukan tindakan korektif. Saat mengonfigurasi pemantau kondisi, pastikan Anda menetapkan
<MaxFailures>
dalam
Tag <HTTPTargetConnection>
dari tag <TargetEndpoint>
ke nilai bukan nol.
TCPMonitor
Konfigurasi di bawah ini menentukan HealthMonitor yang memeriksa setiap TargetServer dengan membuka pada porta 80 setiap lima detik. (Port bersifat opsional. Jika tidak ditentukan, porta TCPMonitor adalah porta TargetServer.)
- Jika koneksi gagal atau membutuhkan waktu lebih dari 10 detik untuk terhubung, maka jumlah kegagalan bertambah sebesar 1 untuk TargetServer tersebut.
- Jika koneksi berhasil, jumlah kegagalan untuk TargetServer direset ke 0.
Anda dapat menambahkan HealthMonitor sebagai elemen turunan dari HTTPTargetConnetion TargetEndpoint , seperti yang ditunjukkan di bawah ini:
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Algorithm>RoundRobin</Algorithm> <Server name="target1" /> <Server name="target2" /> <MaxFailures>5</MaxFailures> </LoadBalancer> <Path>/test</Path> <HealthMonitor> <IsEnabled>true</IsEnabled> <IntervalInSec>5</IntervalInSec> <TCPMonitor> <ConnectTimeoutInSec>10</ConnectTimeoutInSec> <Port>80</Port> </TCPMonitor> </HealthMonitor> </HTTPTargetConnection> . . .
HealthMonitor dengan elemen konfigurasi TCPMonitor
Tabel berikut menjelaskan elemen konfigurasi TCPMonitor:
Nama | Deskripsi | Default | Wajib? |
---|---|---|---|
IsEnabled |
Boolean yang mengaktifkan atau menonaktifkan HealthMonitor. | salah | Tidak |
IntervalInSec |
Interval waktu, dalam detik, antara setiap permintaan TCP polling. | 0 | Ya |
ConnectTimeoutInSec |
Waktu koneksi ke porta TCP harus dibuat untuk dianggap kesuksesan. Kegagalan untuk terhubung dalam interval yang ditentukan dianggap sebagai kegagalan, menambah jumlah kegagalan load balancer untuk TargetServer. | 0 | Ya |
Port |
Opsional. Port tempat koneksi TCP akan dibuat. Jika tidak ditentukan, porta TCPMonitor adalah porta TargetServer. | 0 | Tidak |
HTTPMonitor
Contoh HealthMonitor yang menggunakan HTTPMonitor akan mengirimkan permintaan GET ke backend
layanan setiap lima detik. Contoh di bawah ini menambahkan header Otorisasi Dasar HTTP ke bagian
pesan permintaan. Konfigurasi Respons menetapkan pengaturan yang akan dibandingkan dengan yang sebenarnya
respons dari layanan backend. Dalam contoh di bawah ini, respons yang diharapkan adalah permintaan HTTP
kode respons 200
dan header HTTP kustom ImOK
yang nilainya
YourOK
. Jika respons tidak cocok, permintaan akan dianggap gagal
oleh konfigurasi load balancer.
HTTPMonitor mendukung layanan backend yang dikonfigurasi untuk menggunakan HTTP dan HTTPS satu arah protokol yang sama. Namun, fitur ini tidak mendukung hal berikut:
- HTTPS Dua Arah (juga disebut TLS/SSL dua arah)
- Sertifikat yang ditandatangani sendiri.
Perhatikan bahwa semua setelan Permintaan dan Respons di monitor HTTP akan khusus untuk layanan backend yang harus dipanggil.
<HealthMonitor> <IsEnabled>true</IsEnabled> <IntervalInSec>5</IntervalInSec> <HTTPMonitor> <Request> <IsSSL>true</IsSSL> <ConnectTimeoutInSec>10</ConnectTimeoutInSec> <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec> <Port>80</Port> <Verb>GET</Verb> <Path>/healthcheck</Path> <Header name="Authorization">Basic 12e98yfw87etf</Header> <IncludeHealthCheckIdHeader>true</IncludeHealthCheckIdHeader> </Request> <SuccessResponse> <ResponseCode>200</ResponseCode> <Header name="ImOK">YourOK</Header> </SuccessResponse> </HTTPMonitor> </HealthMonitor>
HealthMonitor dengan elemen konfigurasi HTTPMonitor
Tabel berikut menjelaskan elemen konfigurasi HTTPMonitor:
Nama | Deskripsi | Default | Wajib? |
---|---|---|---|
IsEnabled |
Boolean yang mengaktifkan atau menonaktifkan HealthMonitor. | salah | Tidak |
IntervalInSec |
Interval waktu, dalam detik, antara setiap permintaan polling. | 0 | Ya |
Request |
Opsi konfigurasi untuk pesan permintaan keluar yang dikirim oleh HealthMonitor ke TargetServers dalam rotasi. Jalur tidak mendukung variabel. |
T/A | Ya |
IsSSL |
Menentukan apakah akan menggunakan HTTPS (HTTP aman) untuk memantau koneksi. Potensi nilai-nilai:
|
salah | Tidak |
ConnectTimeoutInSec |
Waktu, dalam detik, saat koneksi TCP ke layanan HTTP harus diselesaikan agar dianggap sukses. Kegagalan untuk terhubung dalam interval yang ditentukan dihitung sebagai kegagalan, yang menambah jumlah kegagalan LoadBalancer untuk TargetServer. | 0 | Tidak |
SocketReadTimeoutInSec |
Waktu, dalam detik, saat data harus dibaca dari layanan HTTP agar dianggap kesuksesan. Kegagalan melakukan pembacaan dalam interval yang ditentukan akan dihitung sebagai kegagalan, sehingga menambah Jumlah kegagalan LoadBalancer untuk TargetServer. | 0 | Tidak |
Port |
Port tempat koneksi HTTP ke layanan backend akan dibuat. | T/A | Tidak |
Verb |
Kata kerja HTTP yang digunakan untuk setiap permintaan HTTP polling ke layanan backend . | T/A | Tidak |
Path |
Jalur yang ditambahkan ke URL yang ditentukan di TargetServer. Gunakan elemen jalur untuk mengonfigurasi 'endpoint polling' pada layanan HTTP Anda. | T/A | Tidak |
| Memungkinkan Anda
untuk melacak permintaan health check di sistem upstream. Tujuan
IncludeHealthCheckIdHeader mengambil nilai Boolean, dan
nilai defaultnya adalah false . Jika Anda menyetelnya ke true ,
ada Header yang bernama X-Apigee-Healthcheck-Id
yang memuat
yang dimasukkan ke dalam permintaan health check. Nilai {i>header<i} adalah
ditetapkan secara dinamis, dan mengambil bentuk
ORG/ENV/SERVER_UUID/N, dengan ORG adalah
nama organisasi, ENV adalah nama lingkungan,
SERVER_UUID adalah ID unik yang mengidentifikasi MP, dan
N adalah jumlah milidetik yang berlalu sejak 1 Januari 1970.
Contoh header permintaan yang dihasilkan: X-Apigee-Healthcheck-Id: orgname/envname/E8C4D2EE-3A69-428A-8616-030ABDE864E0/1586802968123
|
salah | Tidak |
Payload |
Isi HTTP yang dihasilkan untuk setiap permintaan HTTP polling. Perhatikan bahwa elemen ini tidak yang diperlukan untuk permintaan GET. | T/A | Tidak |
SuccessResponse |
Opsi pencocokan untuk pesan respons HTTP masuk yang dihasilkan oleh backend yang diteliti layanan. Respons yang tidak cocok akan menambah jumlah kegagalan sebesar 1. | T/A | Tidak |
ResponseCode |
Kode respons HTTP yang diharapkan akan diterima dari TargetServer yang disurvei. Kode berbeda dari kode yang ditentukan menyebabkan kegagalan, dan hitungan meningkat untuk layanan backend yang di-polling. Anda dapat menentukan beberapa elemen ResponseCode. | T/A | Tidak |
Headers |
Daftar satu atau beberapa header dan nilai HTTP yang diharapkan akan diterima dari polling layanan backend. Header atau nilai HTTP apa pun pada respons yang berbeda dengan yang yang ditentukan akan mengakibatkan kegagalan, dan jumlah TargetServer yang di-polling bertambah sebesar Akun Layanan 1. Anda dapat menentukan beberapa elemen Header. | T/A | Tidak |