Halaman ini diterjemahkan oleh Cloud Translation API.

Load balancing di seluruh server backend

Halaman ini berlaku untuk Apigee dan Apigee hybrid.

Lihat dokumentasi Apigee Edge.

Apigee meningkatkan ketersediaan API Anda dengan menyediakan dukungan bawaan untuk load balancing dan failover di beberapa instance server backend.

Server target memisahkan URL endpoint konkret dari konfigurasi endpoint target. Daripada menentukan URL konkret dalam konfigurasi, Anda dapat mengonfigurasi satu atau beberapa server target bernama. Kemudian, setiap server target direferensikan berdasarkan nama di endpoint target HTTPConnection.

Video

Tonton video berikut untuk mempelajari lebih lanjut perutean API dan load balancing menggunakan server target

Video	Deskripsi
Load balancing menggunakan server target	API load balancing di seluruh server target.
Pemilihan rute API berdasarkan lingkungan menggunakan server target	Merutekan API ke server target yang berbeda berdasarkan lingkungan.

Tentang konfigurasi server target

Konfigurasi server target terdiri dari nama, host, protokol, dan port, dengan elemen tambahan untuk menunjukkan apakah server target diaktifkan atau dinonaktifkan. Server target juga dapat memiliki objek <sSLInfo> opsional.

Kode berikut memberikan contoh konfigurasi server target:

{
  "name": "target1",
  "host": "1.mybackendservice.com",
  "protocol": "http",
  "port": "80",
  "isEnabled": "true"
}

Untuk informasi selengkapnya tentang TargetServers API, lihat organizations.environments.targetservers.

Lihat skema untuk TargetServer dan entitas lainnya di GitHub.

Membuat server target

Buat server target menggunakan UI atau API Apigee seperti yang dijelaskan di bagian berikut.

Apigee di konsol Cloud

Untuk membuat server target menggunakan Apigee di Konsol Cloud:

Login ke UI Apigee di konsol Cloud.
Pilih Pengelolaan > Lingkungan.
Pilih lingkungan tempat Anda ingin menentukan server target baru.
Klik Target Server di bagian atas panel.
Klik + Buat Server Target.
Masukkan nama, host, protokol, dan port di kolom yang disediakan. Opsi untuk Protokol adalah: HTTP untuk server target berbasis REST, gRPC - Target untuk server target berbasis gRPC, atau gRPC - Panggilan eksternal. Lihat Membuat proxy gRPC API untuk mengetahui informasi tentang dukungan proxy gRPC.
Jika ingin, Anda dapat memilih Enable SSL. Lihat Ringkasan sertifikat SSL.
Klik Create.

Apigee Klasik

Untuk membuat server target menggunakan UI Apigee klasik:

Login ke UI Apigee.
Pilih Admin > Environments > TargetServers.
Dari menu drop-down Environment, pilih lingkungan tempat Anda ingin menentukan server target baru.
UI Apigee menampilkan daftar server target saat ini di lingkungan yang dipilih:
Klik +Target server untuk menambahkan server target baru ke lingkungan yang dipilih.
Kotak dialog Add target server akan menampilkan:
Klik Aktif untuk mengaktifkan server target baru. definisi segera setelah Anda membuatnya.
Masukkan nama, host, protokol, dan port di kolom yang disediakan. Opsi untuk Protocol adalah HTTP atau GRPC.

Atau, Anda dapat memilih kotak centang SSL. Untuk informasi selengkapnya tentang kolom ini, lihat TargetServers (video 4MV4D).
Klik Tambahkan.
Apigee membuat definisi server target baru.
Setelah membuat server target baru, Anda dapat mengedit proxy API dan mengubah elemen <HTTPTargetConnection> untuk mereferensikan definisi baru.

Apigee API

Bagian berikut memberikan contoh penggunaan Apigee API untuk membuat dan mencantumkan server target.

Membuat server target di lingkungan menggunakan API
Mencantumkan server target di lingkungan menggunakan API

Untuk informasi selengkapnya, lihat TargetServers API.

Membuat server target di lingkungan menggunakan API

Untuk membuat server target bernama target1 yang terhubung ke 1.mybackendservice.com di port 80, gunakan panggilan API berikut:

curl "https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers" \
  -X POST \
  -H "Content-Type:application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '
  {
  "name": "target1",
  "host": "1.mybackendservice.com",
  "protocol": "http",
  "port": "80",
  "isEnabled": "true",
  }'

Dengan $TOKEN ditetapkan ke token akses OAuth 2.0 Anda, seperti yang dijelaskan dalam Mendapatkan token akses OAuth 2.0. Untuk informasi tentang opsi curl yang digunakan dalam contoh ini, lihat Menggunakan curl. Untuk deskripsi variabel lingkungan yang digunakan, lihat Menetapkan variabel lingkungan untuk permintaan Apigee API.

Berikut adalah contoh responsnya:

{
  "host" : "1.mybackendservice.com",
  "protocol": "http",
  "isEnabled" : true,
  "name" : "target1",
  "port" : 80
}

Buat server target kedua menggunakan panggilan API berikut. Dengan menentukan dua server target, Anda menyediakan dua URL yang dapat digunakan endpoint target untuk load balancing:

curl "https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers" \
  -X POST \
  -H "Content-Type:application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '
  {
  "name": "target2",
  "host": "2.mybackendservice.com",
  "protocol": "http",
  "port": "80",
  "isEnabled": "true",
  }'

Berikut adalah contoh responsnya:

{
  "host" : "2.mybackendservice.com",
  "protocol": "http",
  "isEnabled" : true,
  "name" : "target2",
  "port" : 80
}

Mencantumkan server target di lingkungan menggunakan API

Untuk mencantumkan server target di lingkungan, gunakan panggilan API berikut:

curl https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers \
  -H "Authorization: Bearer $TOKEN"

Berikut adalah contoh responsnya:

[ "target2", "target1" ]

Sekarang ada dua server target yang tersedia untuk digunakan oleh proxy API yang di-deploy di lingkungan test. Untuk melakukan load balancing traffic di seluruh server target ini, Anda mengonfigurasi koneksi HTTP di endpoint target proxy API untuk menggunakan server target.

Mengonfigurasi endpoint target untuk melakukan load balancing di seluruh server target yang dinamai

Setelah memiliki dua server target, Anda dapat mengubah elemen <HTTPTargetConnection> endpoint target untuk mereferensikan dua server target tersebut berdasarkan namanya:

<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. Load balancer mendukung tiga algoritma load balancing, Round Robin, Berbobot, 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 per satu, antara target1 dan target2.

Elemen <Path> membentuk jalur dasar URI endpoint target untuk semua server target. Ini hanya digunakan saat <LoadBalancer> digunakan. Jika tidak, akan diabaikan. Pada contoh di atas, permintaan yang menjangkau target1 akan menjadi http://target1/test, begitu juga untuk server target lainnya.

Untuk informasi selengkapnya, lihat TargetEndpoint.

Mengonfigurasi opsi load balancer

Anda dapat menyesuaikan ketersediaan dengan mengonfigurasi opsi untuk load balancing dan failover di tingkat load balancer dan server target seperti yang dijelaskan di bagian berikut.

Algoritme

Menetapkan algoritma yang digunakan oleh <LoadBalancer>. Algoritma yang tersedia adalah RoundRobin, Weighted, dan LeastConnections, yang masing-masing didokumentasikan di bawah.

Panggilan acak

Algoritma default, round robin, meneruskan permintaan ke setiap server target dalam urutan server tercantum 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 berbobot memungkinkan Anda mengonfigurasi beban traffic yang proporsional untuk server target. LoadBalancer berbobot mendistribusikan permintaan ke server target Anda secara proporsional langsung dengan bobot setiap server target. Oleh karena itu, algoritma berbobot mengharuskan Anda menetapkan atribut weight untuk setiap server target. 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 Sedikit

LoadBalancer yang dikonfigurasi untuk menggunakan algoritma koneksi paling sedikit merutekan permintaan keluar ke server target 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 server target yang menyebabkan permintaan dialihkan ke server target lain.

Kegagalan respons berarti Apigee tidak menerima respons apa pun dari server target. Jika hal ini terjadi, penghitung kegagalan akan bertambah satu.

Namun, jika Apigee menerima respons dari target, meskipun respons tersebut berupa error HTTP (seperti 404 atau 500), respons tersebut akan dihitung sebagai respons dari server target, dan penghitung kegagalan akan direset. Untuk memastikan bahwa respons HTTP yang buruk (seperti 500) juga menambah penghitung kegagalan untuk mengeluarkan server yang tidak responsif dari rotasi load balancing sesegera mungkin, Anda dapat menambahkan elemen <ServerUnhealthyResponse> dengan elemen turunan <ResponseCode> ke konfigurasi load balancer. Apigee juga akan menghitung respons dengan kode tersebut sebagai kegagalan.

Dalam contoh berikut, target1 akan dihapus dari rotasi setelah lima permintaan gagal, termasuk 404 dan 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>404</ResponseCode>
            <ResponseCode>500</ResponseCode>
            <ResponseCode>502</ResponseCode>
            <ResponseCode>503</ResponseCode>
        </ServerUnhealthyResponse>
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

Default MaxFailures adalah 0. Artinya, Apigee selalu mencoba terhubung ke target untuk setiap permintaan dan tidak pernah menghapus server target dari rotasi.

Sebaiknya gunakan MaxFailures > 0 dengan health monitor. Jika Anda mengonfigurasi MaxFailures > 0, server target akan dihapus dari rotasi saat target gagal sebanyak yang Anda tunjukkan. Saat health monitor diterapkan, Apigee akan otomatis menempatkan server target kembali dalam rotasi setelah target aktif dan berjalan lagi, sesuai dengan konfigurasi health monitor tersebut. Lihat Pemantauan kondisi untuk mengetahui informasi selengkapnya.

Perhatikan bahwa panggilan API reguler dan panggilan yang dimulai oleh pemantauan kesehatan akan diperhitungkan dalam jumlah MaxFailures.

Perhatikan juga bahwa jumlah kegagalan yang berjalan untuk setiap server target dipertahankan berdasarkan load balancer. Misalnya, proxy memiliki dua endpoint target, dan masing-masing memiliki load balancer, dan kedua load balancer dikonfigurasi untuk menggunakan kumpulan server target yang sama. Dalam hal ini, kegagalan dari satu endpoint target hanya diperhitungkan terhadap load balancer yang sesuai. Hal ini tidak memengaruhi rotasi endpoint target lainnya.

Atau, jika Anda mengonfigurasi MaxFailures > 0 dan tidak mengonfigurasi health monitor, Apigee akan otomatis mengeluarkan server target dari rotasi saat kegagalan pertama terdeteksi. Apigee akan memeriksa kondisi server target setiap lima menit dan mengembalikannya ke rotasi saat merespons secara normal.

Coba lagi

Jika percobaan ulang diaktifkan, permintaan akan dicoba ulang setiap kali terjadi kegagalan respons (error I/O atau waktu tunggu HTTP) atau respons yang diterima cocok dengan nilai yang ditetapkan oleh <ServerUnhealthyResponse>. Lihat Kegagalan maksimum di atas untuk mengetahui selengkapnya tentang cara menetapkan <ServerUnhealthyResponse>.

Secara default, <RetryEnabled> disetel ke true. Tetapkan ke false untuk menonaktifkan percobaan ulang. Contoh:

<RetryEnabled>false</RetryEnabled>

IsFallback

Satu (dan hanya satu) server target dapat ditetapkan sebagai server penggantian. Load balancer tidak akan menggunakan server penggantian hingga saat semua server target lainnya telah dihapus dari rotasi oleh load balancer. Jika hal ini terjadi, semua traffic akan dirutekan ke server penggantian hingga salah satu server target lainnya melaporkan bahwa server tersebut sudah berfungsi kembali dan dikembalikan ke rotasi. 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 round robin antara target1 dan target2 hingga target1 dan target2 tidak tersedia. Jika target1 dan target2 tidak tersedia, semua traffic akan dirutekan ke target3.

Jika server pengganti tidak responsif, Apigee tidak akan merutekan traffic ke server tersebut. Sebagai gantinya, panggilan API akan menampilkan error 503 "Layanan tidak tersedia untuk sementara".

Jalur

Jalur menentukan fragmen URI yang akan ditambahkan ke semua permintaan yang dikeluarkan oleh server target ke server backend.

Elemen ini menerima jalur string literal atau template pesan. Template pesan memungkinkan Anda melakukan penggantian 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 server target untuk menentukan layanan backend, dan layanan backend memerlukan koneksi untuk menggunakan protokol HTTPS, Anda harus mengaktifkan TLS/SSL dalam definisi server target. Hal ini diperlukan karena tag host tidak memungkinkan Anda menentukan protokol koneksi.

Catatan: Jika Anda menentukan blok sSLInfo di endpoint target dan definisi server target, blok di server target akan diprioritaskan.

Mengonfigurasi TLS/SSL satu arah

Gunakan konfigurasi berikut untuk menentukan server target dengan TLS/SSL satu arah. Dalam contoh ini, Apigee membuat permintaan HTTPS ke layanan backend:

{
  "name": "target1",
  "host": "mocktarget.apigee.net",
  "protocol": "http",
  "port": "443",
  "isEnabled": "true",
  "sSLInfo": {
    "enabled": "true"
  }
}

Mengonfigurasi penerapan SSL yang ketat

Untuk menentukan penerapan SSL yang ketat dalam definisi server target, tetapkan enforce ke true dalam blok sSLInfo, seperti yang ditunjukkan dalam contoh berikut:

  {
    "name": "target1",
    "host": "mocktarget.apigee.net",
    "protocol": "http",
    "port": "443",
    "isEnabled": "true",
    "sSLInfo": {
      "enabled": "true",
      "enforce": "true"
    }
  }

Mengonfigurasi TLS/SSL dua arah

Jika layanan backend memerlukan TLS/SSL dua arah atau timbal balik, Anda dapat mengonfigurasi server target dengan setelan konfigurasi TLS/SSL yang sama dengan endpoint target:

{
  "name": "TargetServer 1",
  "host": "www.example.com",
  "protocol": "http",
  "port": "443",
  "isEnabled": "true",
  "sSLInfo": {
    "enabled": "true",
    "clientAuthEnabled": "true",
    "keyStore": "keystore-name",
    "keyAlias": "keystore-alias",
    "trustStore": "truststore-name",
    "ignoreValidationErrors": "false",
    "ciphers": []
  }
}

Mengonfigurasi SSL ketat menggunakan API

Untuk membuat server target dengan penerapan SSL yang ketat menggunakan panggilan API:

curl "https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers" \
  -X POST \
  -H "Content-Type:application/json"  \
  -H "Authorization: Bearer $TOKEN" \
  -d '
  {
    "name": "TargetServer 1",
    "host": "www.example.com",
    "protocol": "http",
    "port": 443,
    "isEnabled": true,
    "sSLInfo":
    {
      "enabled":true,
      "enforce":true,
      "clientAuthEnabled":true,
      "keyStore":"keystore-name",
      "keyAlias":"keystore-alias",
      "ciphers":[],
      "protocols":[],
      "clientAuthEnabled":true,
      "ignoreValidationErrors":false,
      "trustStore":"truststore-name"
    }
  }'

Pemantauan kesehatan

Pemantauan kondisi memungkinkan Anda meningkatkan konfigurasi load balancing dengan melakukan polling secara aktif terhadap URL layanan backend yang ditentukan dalam konfigurasi server target. Dengan pemantauan kondisi diaktifkan, server target yang tidak dapat dijangkau atau menampilkan respons error akan ditandai sebagai tidak responsif. Server target yang gagal akan otomatis dimasukkan kembali ke rotasi saat health monitor menentukan bahwa server target aktif. Tidak perlu deployment ulang proxy.

Anda harus menetapkan <MaxFailures> lebih besar dari 0 saat menggunakan health monitor. Jika nilai <MaxFailures> ditetapkan ke 0, Apigee akan selalu mencoba terhubung ke target untuk setiap permintaan dan tidak akan menghapus server target dari rotasi.

Health monitor 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 setelan yang dikonfigurasi di blok <SuccessResponse>.

Keberhasilan dan kegagalan

Saat Anda mengaktifkan pemantauan kondisi, Apigee akan mulai mengirim pemeriksaan kondisi ke server target Anda. 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:

Sukses: Server target dianggap responsif saat health check berhasil. Hal ini biasanya disebabkan oleh satu atau beberapa hal berikut:
- Server target menerima koneksi baru ke port yang ditentukan, merespons permintaan di 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 tentukan dapat diterima.
- Server target merespons permintaan health check dengan isi pesan yang cocok dengan isi pesan yang diharapkan.
Jika Apigee menentukan bahwa server responsif, Apigee akan melanjutkan atau melanjutkan pengiriman permintaan ke server tersebut.
Kegagalan: Server target dapat gagal dalam health check dengan berbagai cara, bergantung pada jenis pemeriksaan. Kegagalan dapat dicatat ke dalam log saat server target:
- Menolak koneksi dari Apigee ke port health check.
- Tidak merespons permintaan health check dalam jangka waktu tertentu.
- Menampilkan kode status HTTP yang tidak terduga.
- Merespons dengan isi pesan yang tidak cocok dengan isi pesan yang diharapkan.
Jika server target gagal dalam health check, Apigee akan menambah jumlah kegagalan server tersebut. Jika jumlah kegagalan untuk server tersebut memenuhi atau melebihi nilai minimum yang telah ditentukan (<MaxFailures>), Apigee akan berhenti mengirim permintaan ke server tersebut.

Mengaktifkan pemantauan kondisi

Untuk membuat health monitor bagi proxy API, tambahkan elemen <HealthMonitor> ke konfigurasi elemen <HTTPTargetConnection endpoint target untuk proxy.

Monitor kesehatan tidak dapat dibuat di UI. Sebagai gantinya, Anda membuat konfigurasi proxy dan menguploadnya sebagai file ZIP ke Apigee. Konfigurasi proxy adalah deskripsi terstruktur dari semua aspek proxy API. Konfigurasi proxy terdiri dari file XML dalam struktur direktori yang telah ditentukan sebelumnya. Untuk informasi selengkapnya, lihat Referensi Konfigurasi Proxy API.

Elemen konfigurasi `<HealthMonitor>`

Tabel berikut menjelaskan elemen konfigurasi <HealthMonitor>:

Nama	Deskripsi	Default	Wajib?
`IsEnabled`	Boolean yang mengaktifkan atau menonaktifkan pemantauan kondisi.	false	Tidak
`IntervalInSec`	Interval waktu, dalam detik, antara setiap permintaan TCP atau HTTP polling.	0	Ya
`HTTPMonitor` atau `TCPMonitor`	Definisi klien TCP atau HTTP yang akan digunakan untuk melakukan polling pada server target.	T/A	Ya

Selain elemen ini, mengaktifkan monitor kesehatan mengharuskan Anda menetapkan elemen <MaxFailures> di blok <HTTPTargetConnection> elemen <TargetEndpoint> ke nilai yang lebih besar dari 0. <MaxFailures> digunakan untuk menentukan jumlah maksimum permintaan yang gagal dari proxy API ke server target yang dapat terjadi sebelum permintaan dialihkan ke server target lain.

Secara default, <MaxFailures> adalah 0, yang berarti Apigee tidak melakukan tindakan korektif. Saat mengonfigurasi health monitor, pastikan Anda menetapkan <MaxFailures> ke nilai non-nol.

Health monitor menggunakan monitor TCP

Contoh health monitor yang dijelaskan dalam konfigurasi berikut menggunakan monitor TCP untuk melakukan polling pada setiap server target dengan membuka koneksi di port 80 setiap lima detik. (Port bersifat opsional. Jika tidak ditentukan, port monitor TCP adalah port server target.)

Dalam contoh konfigurasi health monitor ini:

Jika koneksi gagal atau memerlukan waktu lebih dari 10 detik untuk terhubung, jumlah kegagalan akan bertambah 1 untuk server target tersebut.
Jika koneksi berhasil, jumlah kegagalan untuk server target akan direset ke 0.

Anda dapat menambahkan health monitor sebagai elemen turunan dari elemen <HTTPTargetConnection> endpoint target, 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>
</TargetEndpoint>

Elemen konfigurasi `<TCPMonitor>`

Tabel berikut menjelaskan elemen konfigurasi <TCPMonitor>:

Nama	Deskripsi	Default	Wajib?
`ConnectTimeoutInSec`	Waktu saat koneksi ke port TCP harus dibuat agar dianggap berhasil. Kegagalan untuk terhubung dalam interval yang ditentukan dihitung sebagai kegagalan, sehingga meningkatkan jumlah kegagalan load balancer untuk server target.	0	Ya
`Port`	Opsional. Port tempat koneksi TCP akan dibuat. Jika tidak ditentukan, port monitor TCP adalah port server target.	0	Tidak

Monitor kesehatan menggunakan monitor HTTP

Contoh monitor kondisi yang dijelaskan dalam konfigurasi berikut menggunakan monitor HTTP yang mengirimkan permintaan GET ke layanan backend setiap lima detik dan menambahkan header HTTP Basic Authorization ke pesan permintaan.

Dalam contoh konfigurasi health monitor ini:

Respons yang diharapkan dari layanan backend adalah kode respons HTTP 200.
Nilai yang diharapkan untuk header Otorisasi Dasar HTTP kustom ImOK adalah YourOK.
Elemen <UseTargetServerSSLInfo> ditetapkan ke true untuk menggunakan parameter SSL dari blok <SSLInfo> server target.

Dengan konfigurasi ini, kode respons dan nilai header yang diharapkan akan dibandingkan dengan respons sebenarnya dari layanan backend. Jika respons tidak cocok, permintaan akan diperlakukan sebagai kegagalan oleh konfigurasi load balancer.

Secara default, health monitor tidak dapat mengakses keystore, truststore, atau parameter SSL lainnya dari server targetnya. Untuk mengaktifkan akses ke parameter ini bagi pemantauan kondisi Anda guna mendukung TLS timbal balik, misalnya, tambahkan <UseTargetServerSSLInfo>true</UseTargetServerSSLInfo> di blok <Request>.

    <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>
          <HTTPMonitor>
            <Request>
              <UseTargetServerSSLInfo>true</UseTargetServerSSLInfo>
              <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>
      </HTTPTargetConnection>
    </TargetEndpoint>

Elemen konfigurasi `<HTTPMonitor>`

Tabel berikut menjelaskan elemen konfigurasi <HTTPMonitor> tingkat teratas:

Nama	Deskripsi	Default	Wajib?
`Request`	Pesan permintaan keluar yang dikirim oleh health monitor ke server target dalam rotasi.	T/A	Ya
`SuccessResponse`	(Opsional) Opsi pencocokan untuk pesan respons HTTP masuk yang dihasilkan oleh layanan backend yang di-polling.	T/A	Tidak

Elemen konfigurasi <HTTPMonitor>/<Request>

Opsi konfigurasi untuk pesan permintaan keluar yang dikirim oleh health monitor ke server target dalam rotasi. Perhatikan bahwa <Request> adalah elemen wajib.

Nama	Deskripsi	Default	Wajib?
`ConnectTimeoutInSec`	Waktu, dalam detik, saat handshake koneksi TCP ke layanan HTTP harus selesai agar dianggap berhasil. Kegagalan untuk terhubung dalam interval yang ditentukan dihitung sebagai kegagalan, yang menambah jumlah kegagalan LoadBalancer untuk server target. Catatan: Jika nilai yang ditentukan adalah 0, Apigee akan menggunakan waktu tunggu default 30 detik.	0	Tidak
`SocketReadTimeoutInSec`	Waktu, dalam satuan detik, saat data harus dibaca dari layanan HTTP agar dianggap berhasil. Kegagalan membaca dalam interval yang ditentukan dihitung sebagai kegagalan, sehingga meningkatkan jumlah kegagalan LoadBalancer untuk server target. Catatan: Jika nilai yang ditentukan adalah 0, Apigee akan menggunakan waktu tunggu default 30 detik.	0	Tidak
`Port`	Port tempat koneksi HTTP ke layanan backend akan dibuat.	Port server target	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 server target. Gunakan elemen `Path` untuk mengonfigurasi 'endpoint polling' di layanan HTTP Anda. Perhatikan bahwa elemen `Path` tidak mendukung variabel.	T/A	Tidak
`UseTargetServerSSLInfo`	Jika `UseTargetServerSSLInfo` bernilai benar, permintaan health monitor ke server target akan menggunakan parameter SSL dari blok SSLInfo ("sSLInfo") server target. Jika tidak, parameter SSL seperti protokol, keystore, truststore, dan sebagainya tidak akan tersedia untuk health monitor.	false	Tidak
`IncludeHealthCheckIdHeader`	Memungkinkan Anda melacak permintaan pemeriksaan kesehatan di sistem upstream. `IncludeHealthCheckIdHeader` menggunakan nilai Boolean, dan default-nya adalah `false`. Jika Anda menetapkannya ke `true`, maka akan ada `Header` bernama `X-Apigee-Healthcheck-Id` yang dimasukkan ke dalam permintaan healthcheck. Nilai header ditetapkan secara dinamis, dan memiliki 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`	false	Tidak
`Payload`	Isi HTTP yang dibuat untuk setiap permintaan HTTP polling. Perhatikan bahwa elemen ini tidak diperlukan untuk permintaan `GET`.	T/A	Tidak
`Header`	Satu atau beberapa header dan nilai HTTP yang diharapkan akan diterima dari layanan backend yang di-poll. Header atau nilai HTTP apa pun pada respons yang berbeda dengan yang ditentukan akan menyebabkan kegagalan, dan jumlah untuk server target yang di-polling akan bertambah sebesar 1. Anda dapat menentukan beberapa elemen Header.	T/A	Tidak
`IsSSL`	Jika benar, menentukan bahwa permintaan health monitor dikirim menggunakan HTTPS.	Salah	Tidak
`TrustAllSSL`	Menentukan apakah pemeriksaan monitor HTTP akan otomatis memercayai semua sertifikat SSL.	Salah	Tidak

Elemen konfigurasi <HTTPMonitor>/<SuccessResponse>

(Opsional) Opsi pencocokan untuk pesan respons HTTP masuk yang dihasilkan oleh layanan backend yang di-poll. Respons yang tidak cocok akan menambah jumlah kegagalan sebesar 1.

Nama	Deskripsi	Default	Wajib?
`ResponseCode`	Kode respons HTTP yang diharapkan akan diterima dari server target yang di-polling. Kode yang berbeda dengan kode yang ditentukan akan menyebabkan kegagalan, dan jumlah yang bertambah untuk layanan backend yang di-poll. Anda dapat menentukan beberapa elemen ResponseCode.	T/A	Tidak
`Header`	Satu atau beberapa header dan nilai HTTP yang diharapkan akan diterima dari layanan backend yang di-poll. Header atau nilai HTTP apa pun pada respons yang berbeda dengan yang ditentukan akan menyebabkan kegagalan, dan jumlah untuk server target yang di-polling akan bertambah sebesar 1. Anda dapat menentukan beberapa elemen Header.	T/A	Tidak

Load balancing di seluruh server backend

Video

Tentang konfigurasi server target

Membuat server target

Apigee di konsol Cloud

Apigee Klasik

Apigee API

Membuat server target di lingkungan menggunakan API

Mencantumkan server target di lingkungan menggunakan API

Mengonfigurasi endpoint target untuk melakukan load balancing di seluruh server target yang dinamai

Mengonfigurasi opsi load balancer

Algoritme

Panggilan acak

Berbobot

Koneksi Paling Sedikit

Kegagalan maksimum

Coba lagi

IsFallback

Jalur

Mengonfigurasi server target untuk TLS/SSL

Mengonfigurasi TLS/SSL satu arah

Mengonfigurasi penerapan SSL yang ketat

Mengonfigurasi TLS/SSL dua arah

Mengonfigurasi SSL ketat menggunakan API

Pemantauan kesehatan

Keberhasilan dan kegagalan

Mengaktifkan pemantauan kondisi

Elemen konfigurasi <HealthMonitor>

Health monitor menggunakan monitor TCP

Elemen konfigurasi <TCPMonitor>

Monitor kesehatan menggunakan monitor HTTP

Elemen konfigurasi <HTTPMonitor>

Elemen konfigurasi <HTTPMonitor>/<Request>

Elemen konfigurasi <HTTPMonitor>/<SuccessResponse>

Elemen konfigurasi `<HealthMonitor>`

Elemen konfigurasi `<TCPMonitor>`

Elemen konfigurasi `<HTTPMonitor>`