Halaman ini diterjemahkan oleh Cloud Translation API.

Load balancing di berbagai server backend

Halaman ini berlaku untuk Apigee dan Apigee Hybrid.

Baca dokumentasi Apigee Edge.

Apigee meningkatkan ketersediaan API 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 menetapkan URL konkret dalam konfigurasi, Anda dapat mengonfigurasi satu atau beberapa server target yang telah diberi nama. Kemudian, setiap server target dirujuk oleh nama dalam HTTPConnection endpoint target.

Video

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

Video	Deskripsi
Load balancing menggunakan server target	API load balancing di seluruh server target.
Pemilihan rute API berdasarkan lingkungan yang menggunakan server target	Rutekan 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 lebih lanjut tentang API TargetServers, lihat organizations.environments.targetservers.

Lihat skema untuk TargetServer dan entity 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 Cloud Console:

Login ke UI Apigee di Konsol Cloud.
Pilih Pengelolaan > Lingkungan.
Pilih lingkungan tempat Anda ingin menetapkan server target baru.
Klik Target Servers di bagian atas panel.
Klik + Create Target Server.
Masukkan nama, host, protokol, dan port di kolom yang disediakan. Opsi untuk Protocol adalah: HTTP untuk server target berbasis REST, gRPC - Target untuk server target berbasis gRPC, atau gRPC - External callout. Lihat Membuat proxy gRPC API untuk informasi tentang dukungan proxy gRPC.
Anda juga dapat memilih Aktifkan 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 menetapkan 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 Enabled untuk mengaktifkan server target baru. definisinya segera setelah Anda membuatnya.
Masukkan nama, host, protokol, dan port di kolom yang disediakan. Opsi untuk Protokol adalah HTTP atau GRPC.

Jika ingin, Anda dapat memilih kotak centang SSL. Untuk mengetahui 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 merujuk definisi baru.

API Apigee

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

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

Untuk mengetahui informasi selengkapnya, lihat TargetServers API.

Membuat server target dalam lingkungan menggunakan API

Untuk membuat server target bernama target1 yang terhubung ke 1.mybackendservice.com pada 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, seperti yang dijelaskan dalam Mendapatkan token akses OAuth 2.0. Untuk mengetahui informasi tentang opsi curl yang digunakan dalam contoh ini, lihat Menggunakan curl. Untuk deskripsi tentang variabel lingkungan yang digunakan, lihat Menetapkan variabel lingkungan untuk permintaan Apigee API.

Berikut ini memberikan contoh respons:

{
  "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 memberikan 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 ini memberikan contoh respons:

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

Mencantumkan server target dalam 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 ini memberikan contoh respons:

[ "target2", "target1" ]

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

Mengonfigurasi endpoint target untuk melakukan load balancing di berbagai server target bernama

Setelah memiliki dua server target yang tersedia, Anda dapat memodifikasi elemen <HTTPTargetConnection> endpoint target untuk mereferensikan kedua server target 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 paling dasar. Load balancer ini mendukung tiga algoritma load balancing, yakni Round Robin, Berbobot, dan Koneksi Terkecil. Round Robin adalah algoritma {i>default<i}. 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 dasar jalur URI endpoint target untuk semua server target. Ini hanya digunakan saat <LoadBalancer> digunakan. Jika tidak, akan diabaikan. Pada contoh di atas, permintaan yang mencapai target1 adalah http://target1/test, dan begitu juga untuk server target lainnya.

Untuk mengetahui 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.

Algoritma

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

Panggilan acak

Algoritma default, round robin, meneruskan permintaan ke setiap server target sesuai urutan daftar server 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 tertimbang mendistribusikan permintaan ke server target dalam proporsi 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 Terendah

LoadBalancers yang dikonfigurasi untuk menggunakan algoritma koneksi yang paling sedikit mengarahkan 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 sehingga permintaan dialihkan ke server target lainnya.

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

Namun, saat Apigee menerima respons dari target, meskipun responsnya adalah error HTTP (seperti 404 atau 500), yang dihitung sebagai respons dari server target, dan penghitung kegagalan 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. Ini berarti Apigee selalu mencoba terhubung ke target untuk setiap permintaan dan tidak pernah menghapus server target dari rotasi.

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

Atau, jika Anda mengonfigurasi MaxFailures > 0 dan Anda tidak mengonfigurasi monitor kesehatan, 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 lagi setiap kali terjadi kegagalan respons (error I/O atau waktu tunggu HTTP) terjadi atau respons yang diterima cocok dengan nilai yang ditetapkan oleh <ServerUnhealthyResponse>. Lihat Kegagalan maksimum di atas untuk mengetahui informasi selengkapnya tentang cara menetapkan <ServerUnhealthyResponse>.

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

<RetryEnabled>false</RetryEnabled>

IsFallback

Satu (dan hanya satu) server target yang dapat disetel sebagai server fallback. Server target penggantian tidak disertakan dalam rutinitas load balancing hingga semua server target lainnya diidentifikasi sebagai tidak tersedia oleh load balancer. Saat load balancer menentukan bahwa semua server target non-penggantian tidak tersedia, semua traffic akan 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 round robin antara target1 dan target2 hingga target1 dan target2 tidak tersedia. Jika target1 dan target2 tidak tersedia, semua traffic akan dialihkan ke target3.

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

Jalur

Path 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 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, yang ada di server target akan lebih diutamakan.

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 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 bersama, Anda dapat mengonfigurasi server target dengan setelan konfigurasi TLS/SSL yang sama seperti 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 yang 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

Dengan pemantauan kondisi, Anda dapat meningkatkan konfigurasi load balancing dengan secara aktif melakukan polling pada URL layanan backend yang ditentukan dalam konfigurasi server target. Dengan mengaktifkan pemantauan kesehatan, server target yang tidak dapat dijangkau atau menampilkan respons error akan ditandai sebagai tidak responsif. Server target yang gagal akan otomatis dikembalikan ke rotasi saat monitor kesehatan menentukan bahwa server target aktif. Deployment ulang proxy tidak diperlukan.

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

Pemantau kesehatan bertindak sebagai klien sederhana yang memanggil layanan backend melalui TCP atau HTTP:

Klien TCP memastikan bahwa soket dapat dibuka.
Anda akan 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 sesuai dengan setelan yang dikonfigurasi dalam blok <SuccessResponse>.

Keberhasilan dan kegagalan

Jika Anda mengaktifkan pemantauan kondisi, Apigee akan mulai mengirimkan health check 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:

Berhasil: Server target dianggap responsif jika health check berhasil terjadi. 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 lain yang Anda anggap dapat diterima.
- Server target merespons permintaan health check dengan isi pesan yang cocok dengan isi pesan yang diharapkan.
Saat Apigee menentukan bahwa server responsif, Apigee akan melanjutkan pengiriman atau melanjutkan pengiriman permintaan ke server tersebut.
Kegagalan: Server target dapat menggagalkan health check dengan berbagai cara, bergantung pada jenis pemeriksaan. Kegagalan dapat dicatat 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 diharapkan.
- 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 melampaui ambang batas yang telah ditentukan (<MaxFailures>), Apigee akan berhenti mengirim permintaan ke server tersebut.

Mengaktifkan monitor kesehatan

Guna membuat pemantauan kondisi untuk proxy API, tambahkan elemen <HealthMonitor> ke konfigurasi elemen <HTTPTargetConnection endpoint target untuk proxy tersebut.

Pemantau 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 mengetahui 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 dari klien TCP atau HTTP yang akan digunakan untuk melakukan polling pada server target.	T/A	Ya

Selain elemen-elemen tersebut, untuk mengaktifkan monitor kondisi, Anda harus menetapkan elemen <MaxFailures> dalam 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 lainnya.

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

Monitor kondisi menggunakan monitor TCP

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

Dalam contoh konfigurasi monitor kondisi ini:

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

Anda dapat menambahkan monitor kesehatan sebagai elemen turunan dari elemen <HTTPTargetConnection> endpoint target, seperti 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 membuat koneksi ke port TCP agar dianggap berhasil. Kegagalan terhubung dalam interval yang ditentukan akan dihitung sebagai kegagalan, sehingga menambah jumlah kegagalan load balancer untuk server target.	0	Ya
`Port`	Opsional. Porta tempat koneksi TCP akan dibuat. Jika tidak ditentukan, port monitor TCP adalah port server target.	0	Tidak

Health monitor menggunakan monitor HTTP

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

Dalam contoh konfigurasi monitor kondisi 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> disetel 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 responsnya tidak cocok, permintaan akan dianggap gagal oleh konfigurasi load balancer.

Secara default, pemantau kesehatan tidak dapat mengakses keystore, truststore, atau parameter SSL lainnya dari server targetnya. Untuk mengaktifkan akses ke parameter ini untuk pemantauan kondisi Anda agar dapat mendukung TLS bersama, misalnya, tambahkan <UseTargetServerSSLInfo>true</UseTargetServerSSLInfo> dalam 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 atas:

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

Elemen konfigurasi <HTTPMonitor>/<Request>

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

Nama	Deskripsi	Default	Wajib?
`ConnectTimeoutInSec`	Waktu, dalam detik, saat handshake koneksi TCP ke layanan HTTP harus diselesaikan agar dianggap berhasil. Kegagalan terhubung dalam interval yang ditentukan akan dihitung sebagai kegagalan, yang meningkatkan 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 detik, saat data harus dibaca dari layanan HTTP agar dianggap berhasil. Kegagalan membaca dalam interval yang ditentukan akan dihitung sebagai kegagalan, sehingga menambah 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 true, permintaan pemantau kondisi kesehatan 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 pemantau kondisi.	false	Tidak
`IncludeHealthCheckIdHeader`	Memungkinkan Anda melacak permintaan health check di sistem upstream. `IncludeHealthCheckIdHeader` menggunakan nilai Boolean, dan secara default disetel ke `false`. Jika Anda menetapkannya ke `true`, maka akan ada `Header` bernama `X-Apigee-Healthcheck-Id` yang dimasukkan ke permintaan healthcheck. Nilai header ditetapkan secara dinamis, dan berbentuk `ORG/ENV/SERVER_UUID/N`, dengan `ORG` sebagai 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 dihasilkan 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-polling. Header atau nilai HTTP apa pun pada respons yang berbeda dengan yang telah ditentukan akan menyebabkan kegagalan, dan jumlah untuk server target yang di-polling bertambah 1. Anda dapat menentukan beberapa elemen Header.	T/A	Tidak
`IsSSL`	Jika true (benar), menentukan bahwa permintaan pemantauan kondisi 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 dibuat oleh layanan backend yang di-polling. 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 dari kode yang ditentukan akan menghasilkan kegagalan, dan jumlah meningkat untuk layanan backend yang di-polling. 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-polling. Header atau nilai HTTP apa pun pada respons yang berbeda dengan yang telah ditentukan akan menyebabkan kegagalan, dan jumlah untuk server target yang di-polling bertambah 1. Anda dapat menentukan beberapa elemen Header.	T/A	Tidak

Load balancing di berbagai server backend

Video

Tentang konfigurasi server target

Membuat server target

Apigee di Konsol Cloud

Apigee Klasik

API Apigee

Membuat server target dalam lingkungan menggunakan API

Mencantumkan server target dalam lingkungan menggunakan API

Mengonfigurasi endpoint target untuk melakukan load balancing di berbagai server target bernama

Mengonfigurasi opsi load balancer

Algoritma

Panggilan acak

Berbobot

Koneksi Terendah

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 yang ketat menggunakan API

Pemantauan kesehatan

Keberhasilan dan kegagalan

Mengaktifkan monitor kesehatan

Elemen konfigurasi <HealthMonitor>

Monitor kondisi menggunakan monitor TCP

Elemen konfigurasi <TCPMonitor>

Health monitor menggunakan monitor HTTP

Elemen konfigurasi <HTTPMonitor>

Elemen konfigurasi <HTTPMonitor>/<Request>

Elemen konfigurasi <HTTPMonitor>/<SuccessResponse>

Elemen konfigurasi `<HealthMonitor>`

Elemen konfigurasi `<TCPMonitor>`

Elemen konfigurasi `<HTTPMonitor>`