Halaman ini diterjemahkan oleh Cloud Translation API.

Load balancing di berbagai server backend

Halaman ini berlaku untuk Apigee dan Apigee hybrid.

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

Server target memisahkan URL endpoint konkret dari endpoint target konfigurasi standar. Daripada menetapkan URL konkret dalam konfigurasi, Anda dapat mengonfigurasinya atau lebih server target bernama. Kemudian, setiap server target direferensikan berdasarkan nama di titik akhir target Koneksi HTTP.

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.

Tentang konfigurasi server target

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

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 Cloud Console.
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 pada bidang yang tersedia. Opsi untuk Protokol adalah: HTTP untuk server target berbasis REST, gRPC - Target untuk target berbasis gRPC server, atau gRPC - Info eksternal. Lihat Membuat proxy gRPC API untuk mengetahui informasi tentang dukungan proxy gRPC.
Anda dapat memilih Enable SSL (opsional). Lihat SSL ringkasan sertifikat.
Klik Create.

Apigee Klasik

Untuk membuat server target menggunakan UI Apigee klasik:

Login ke UI Apigee.
Pilih Admin > Lingkungan > TargetServers.
Dari menu drop-down Lingkungan, pilih lingkungan yang Anda inginkan untuk menentukan server target baru.
UI Apigee menampilkan daftar server target saat ini di lingkungan yang dipilih:
Klik +Server target untuk menambahkan yang baru server target ke lingkungan yang dipilih.
Kotak dialog Add target server akan ditampilkan:
Klik Enabled untuk mengaktifkan server target baru. definisinya segera setelah Anda membuatnya.
Masukkan nama, host, protokol, dan port pada bidang yang tersedia. Opsi untuk Protokol adalah HTTP atau GRPC.

Secara opsional, Anda dapat memilih 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 bisa mengedit proxy API dan mengubah <HTTPTargetConnection> untuk mereferensikan definisi baru.

API Apigee

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

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

Sebagai informasi selengkapnya, lihat TargetServers API.

Membuat server target di 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",
  }'

Jika $TOKEN ditetapkan ke token akses OAuth 2.0 Anda, seperti yang dijelaskan di 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 API Apigee.

Berikut ini 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 ini contoh responsnya:

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

Membuat daftar server target dalam lingkungan menggunakan API

Untuk menampilkan daftar 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 contoh responsnya:

[ "target2", "target1" ]

Sekarang ada dua server target yang tersedia untuk digunakan oleh proxy API yang di-deploy di test lingkungan fleksibel App Engine. Untuk melakukan load balancing pada traffic di semua server target ini, Anda mengonfigurasi di endpoint target proxy API untuk menggunakan server target.

Mengonfigurasi endpoint target untuk melakukan load balancing di seluruh server target yang diberi nama

Sekarang setelah Anda memiliki dua server target yang tersedia, Anda dapat memodifikasi <HTTPTargetConnection> 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 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 target2.

Elemen <Path> membentuk jalur dasar URI endpoint target untuk semua server target. Kolom ini hanya digunakan saat <LoadBalancer> digunakan. Jika tidak, akan akan diabaikan. Pada contoh di atas, permintaan yang sampai ke target1 akan http://target1/test, dan seterusnya 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 saat pemuatan pada level server target dan load balancer seperti yang dijelaskan di bagian berikut.

Algoritme

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

Panggilan acak

Algoritma {i>default<i}, {i>round robin<i}, meneruskan permintaan ke setiap server target 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>

Dengan Pemberat

Algoritma load balancing tertimbang memungkinkan Anda mengonfigurasi pemuatan traffic server target Anda. LoadBalancer berbobot mendistribusikan permintaan ke server target Anda secara langsung proporsi 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 permintaan yang dirutekan ke target1.

Koneksi Paling Jarang

LoadBalancer dikonfigurasi untuk menggunakan algoritma koneksi 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 yang menyebabkan permintaan dialihkan ke server target 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 404 atau 500), yang dihitung sebagai respons dari server target, dan penghitung kegagalan akan diatur ulang. Untuk memastikan bahwa respons HTTP yang buruk (seperti 500) juga menambah penghitung kegagalan untuk mengeluarkan server yang tidak responsif dari beban penyeimbangan rotasi sesegera mungkin, Anda bisa menambahkan Elemen <ServerUnhealthyResponse> dengan <ResponseCode> elemen turunan ke konfigurasi load balancer. Apigee juga akan menghitung respons dengan kode sebagai kegagalan.

Dalam contoh berikut, target1 akan dihapus dari rotasi setelah lima permintaan yang 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 pemantau kondisi kesehatan. Jika Anda mengonfigurasi MaxFailures > 0, server target dihapus dari rotasi jika target gagal, berapa kali yang Anda tentukan. Ketika seorang pemantau kondisi, Apigee secara otomatis menerapkan server target kembali secara rotasi setelah target aktif dan berjalan kembali, menurut konfigurasi pemantau kondisi tersebut. Lihat Pemantauan kesehatan untuk informasi selengkapnya.

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

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) server target dapat ditetapkan sebagai server penggantian. Server target penggantian tidak disertakan dalam rutinitas load balancing sampai semua server target lainnya diidentifikasi sebagai tidak tersedia oleh load balancer. Saat load balancer menentukan bahwa semua non-penggantian server target 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 round robin antara target1 dan target2 hingga target1 dan target2 tidak tersedia. Jika target1 dan target2 tidak tersedia, semua traffic dirutekan ke target3.

Jika server fallback tidak responsif, Apigee tidak akan mengarahkan traffic ke server tersebut. Sebagai gantinya, panggilan API akan menampilkan 503 "Layanan tidak tersedia untuk sementara" {i>error<i}.

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. 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 server target untuk menentukan layanan backend, dan layanan backend mengharuskan koneksi menggunakan protokol HTTPS, maka Anda harus mengaktifkan TLS/SSL di definisi server target. Hal ini diperlukan karena tag host tidak mengizinkan Anda menentukan protokol koneksi.

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

Mengonfigurasi TLS/SSL satu arah

Gunakan konfigurasi berikut untuk menentukan server target dengan satu arah TLS/SSL. 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 di 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 bersama, 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 secara aktif melakukan polling URL layanan backend yang ditentukan di konfigurasi server target. Dengan mengaktifkan pemantauan kondisi, server target yang tidak dapat dijangkau atau menampilkan respons {i>error<i} ditandai sebagai tidak responsif. Server target yang gagal akan secara otomatis dikembalikan ke rotasi saat pemantau kondisi kesehatan menentukan bahwa server target aktif. Tidak ada proxy deployment ulang diperlukan.

Anda harus menetapkan <MaxFailures> lebih besar dari 0 saat menggunakan pemantau kondisi. 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 kondisi 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 HTTP GET, PUT, POST, atau DELETE operasional bisnis. Respons panggilan monitor HTTP harus cocok dengan mengonfigurasi setelan di blok <SuccessResponse>.

Keberhasilan dan kegagalan

Saat Anda mengaktifkan pemantauan kondisi, Apigee mulai mengirimkan health check ke target Anda server tertentu. Health check adalah permintaan yang dikirim ke server target yang menentukan apakah server target responsif.

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 Apigee menentukan bahwa server responsif, Apigee 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 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 sesuai dengan isi pesan yang diharapkan.
Saat server target gagal dalam health check, Apigee akan menambah jumlah kegagalan server tersebut. Jika jumlah kegagalan untuk server tersebut yang memenuhi atau melampaui batas yang telah ditentukan (<MaxFailures>), Apigee berhenti mengirim permintaan ke server tersebut.

Mengaktifkan pemantau kondisi

Agar dapat membuat pemantau kondisi untuk proxy API, tambahkan elemen <HealthMonitor> ke elemen <HTTPTargetConnection endpoint target untuk proxy.

Pemantauan kesehatan tidak dapat dibuat di UI. Sebagai gantinya, Anda membuat konfigurasi {i>proxy<i} dan upload sebagai file ZIP ke Apigee. 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.

Elemen konfigurasi `<HealthMonitor>`

Tabel berikut menjelaskan elemen konfigurasi <HealthMonitor>:

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

Selain elemen-elemen tersebut, mengaktifkan pemantau kondisi mengharuskan Anda menyetel 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 pemantau kondisi, pastikan Anda menetapkan <MaxFailures> ke nilai bukan nol.

Pemantau kondisi menggunakan pemantau TCP

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

Dalam contoh konfigurasi pemantau kondisi ini:

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

Anda dapat menambahkan pemantau kondisi sebagai elemen turunan dari <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 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 server target.	0	Ya
`Port`	Opsional. Port tempat koneksi TCP akan dibuat. Jika tidak ditentukan, porta monitor TCP adalah porta server target.	0	Tidak

Pemantau kondisi menggunakan pemantau HTTP

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

Dalam contoh konfigurasi pemantau 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 dari layanan backend. Jika respons tidak cocok, permintaan akan dianggap gagal oleh konfigurasi load balancer.

Secara default, pemantau kondisi tidak dapat mengakses keystore, truststore, atau parameter SSL lainnya dari server targetnya. Untuk mengaktifkan akses ke parameter ini untuk pemantauan kondisi Anda guna mendukung TLS bersama, 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> level teratas:

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

<HTTPMonitor>/<Request> elemen konfigurasi

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

Nama	Deskripsi	Default	Wajib?
`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, menambah jumlah kegagalan LoadBalancer untuk server target. Catatan: Jika nilai yang ditentukan adalah 0, Apigee akan menggunakan waktu tunggu default selama 30 detik.	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 server target. Catatan: Jika nilai yang ditentukan adalah 0, Apigee akan menggunakan waktu tunggu default selama 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' pada layanan HTTP Anda. Perlu diperhatikan bahwa elemen `Path` tidak mendukung variabel.	T/A	Tidak
`UseTargetServerSSLInfo`	Jika `UseTargetServerSSLInfo` benar, permintaan pemantauan kondisi 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 kesehatan.	salah	Tidak
`IncludeHealthCheckIdHeader`	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
`Header`	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 server target yang disurvei akan bertambah sebesar Akun Layanan 1. Anda dapat menentukan beberapa elemen Header.	T/A	Tidak
`IsSSL`	Jika true (benar), menentukan bahwa permintaan pemantau kondisi akan dikirim menggunakan HTTPS.	Salah	Tidak
`TrustAllSSL`	Menentukan apakah pemeriksaan monitor HTTP akan otomatis memercayai semua sertifikat SSL.	Salah	Tidak

<HTTPMonitor>/<SuccessResponse> elemen konfigurasi

(Opsional) Opsi pencocokan untuk pesan respons HTTP masuk yang dibuat oleh backend yang diteliti layanan. 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 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
`Header`	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 server target yang disurvei akan bertambah sebesar Akun Layanan 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 di lingkungan menggunakan API

Membuat daftar server target dalam lingkungan menggunakan API

Mengonfigurasi endpoint target untuk melakukan load balancing di seluruh server target yang diberi nama

Mengonfigurasi opsi load balancer

Algoritme

Panggilan acak

Dengan Pemberat

Koneksi Paling Jarang

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 pemantau kondisi

Elemen konfigurasi <HealthMonitor>

Pemantau kondisi menggunakan pemantau TCP

Elemen konfigurasi <TCPMonitor>

Pemantau kondisi menggunakan pemantau HTTP

Elemen konfigurasi <HTTPMonitor>

&lt;HTTPMonitor&gt;/&lt;Request&gt; elemen konfigurasi

&lt;HTTPMonitor&gt;/&lt;SuccessResponse&gt; elemen konfigurasi

Elemen konfigurasi `<HealthMonitor>`

Elemen konfigurasi `<TCPMonitor>`

Elemen konfigurasi `<HTTPMonitor>`

<HTTPMonitor>/<Request> elemen konfigurasi

<HTTPMonitor>/<SuccessResponse> elemen konfigurasi