Load balancing di seluruh server backend

Anda sedang melihat dokumentasi Apigee Edge.
Buka dokumentasi Apigee X. info

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

Konfigurasi TargetServer memisahkan URL endpoint konkret dari konfigurasi TargetEndpoint. Setiap TargetServer dirujuk berdasarkan nama di HTTPConnection TargetEndpoint. Daripada menentukan URL konkret dalam konfigurasi, Anda dapat mengonfigurasi satu atau beberapa TargetServer bernama seperti yang dijelaskan di bagian TargetEndpoint.

Definisi TargetServer terdiri dari nama, host, dan port, dengan elemen tambahan untuk menunjukkan apakah TargetServer diaktifkan atau dinonaktifkan.

Video

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

Contoh Konfigurasi TargetServer

Kode berikut menentukan server target:

<TargetServer  name="target1">
  <Host>1.mybackendservice.com</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer >

Elemen Konfigurasi TargetServer

Tabel berikut menjelaskan elemen yang digunakan untuk membuat dan mengonfigurasi TargetServer:

Mengelola server target menggunakan UI

Kelola server target, seperti yang dijelaskan di bawah.

Mengelola server target menggunakan API

Anda dapat menggunakan Edge API untuk membuat, menghapus, memperbarui, mendapatkan, dan membuat daftar server target. Untuk mengetahui informasi selengkapnya, lihat TargetServers.

Gunakan panggilan API berikut untuk membuat server target:

$ curl -H "Content-Type:text/xml" -X POST -d \
'<TargetServer name="target1">
   <Host>1.mybackendservice.com</Host>
   <Port>80</Port>
   <IsEnabled>true</IsEnabled>
 </TargetServer>' \
-u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

Contoh Respons:

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

Setelah membuat TargetServer pertama, gunakan panggilan API berikut untuk membuat TargetServer kedua. Dengan menentukan dua TargetServer, Anda memberikan dua URL yang dapat digunakan TargetEndpoint untuk load balancing:

$ curl -H "Content-type:text/xml" -X POST -d \
'<TargetServer  name="target2">
  <Host>2.mybackendservice.com</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer >' \
-u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

Contoh Respons:

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

Gunakan panggilan API berikut untuk mengambil daftar TargetServer di lingkungan:

$ curl -u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

Contoh respons:

[ "target2", "target1" ]

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

Ada batas 500 TargetServer per lingkungan, seperti yang didokumentasikan dalam topik Batas.

Mengonfigurasi TargetEndpoint untuk melakukan load balancing di seluruh TargetServer yang dinamai

Setelah memiliki dua TargetServer, Anda dapat mengubah setelan koneksi HTTP TargetEndpoint untuk mereferensikan dua TargetServer 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 paling dasar yang memungkinkan. 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 target 2.

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

Menetapkan opsi load balancer

Anda dapat menyesuaikan ketersediaan menggunakan opsi untuk load balancing dan failover di tingkat load balancer dan TargetServer. Bagian ini menjelaskan opsi tersebut.

Algoritma

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

Round robin

Algoritma default, round robin, meneruskan permintaan ke setiap TargetServer 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 proporsional untuk TargetServer. LoadBalancer berbobot mendistribusikan permintaan ke TargetServer Anda secara proporsional langsung dengan bobot setiap TargetServer. Oleh karena itu, algoritma berbobot mengharuskan Anda menetapkan atribut weight untuk setiap TargetServer. Contoh:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <LoadBalancer>
      <Algorithm>Weighted</Algorithm>
      <Server name="target1">
        <Weight>1</Weight>
      </Server>
      <Server name="target2">
        <Weight>2</Weight>
      </Server>
    </LoadBalancer>
    <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

Dalam contoh ini, dua permintaan akan dirutekan ke target2 untuk setiap satu permintaan yang dirutekan ke target1.

Koneksi Paling Sedikit

LoadBalancer yang dikonfigurasi untuk menggunakan algoritma koneksi paling sedikit merutekan permintaan keluar ke TargetServer dengan koneksi HTTP terbuka paling sedikit. Contoh:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>LeastConnections</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
      </LoadBalancer>
  </HTTPTargetConnection>
  <Path>/test</Path>
</TargetEndpoint>

Kegagalan maksimum

Jumlah maksimum permintaan yang gagal dari proxy API ke TargetServer yang menyebabkan permintaan dialihkan ke TargetServer lain.

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

Namun, jika Apigee menerima respons dari target, meskipun respons tersebut berupa error HTTP (seperti 500), respons tersebut akan dihitung sebagai respons dari server target, dan penghitung kegagalan akan direset. Untuk membantu 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. Edge juga akan menghitung respons dengan kode tersebut sebagai kegagalan.

Dalam contoh berikut, target1 akan dihapus dari rotasi setelah lima permintaan gagal, termasuk beberapa respons 5XX dari server target.

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <MaxFailures>5</MaxFailures>
        <ServerUnhealthyResponse>
            <ResponseCode>500</ResponseCode>
            <ResponseCode>502</ResponseCode>
            <ResponseCode>503</ResponseCode>
        </ServerUnhealthyResponse>
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

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

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

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) TargetServer dapat ditetapkan sebagai server 'penggantian'. TargetServer penggantian tidak disertakan dalam rutinitas load balancing hingga semua TargetServer lainnya diidentifikasi sebagai tidak tersedia oleh load balancer. Jika load balancer menentukan bahwa semua TargetServer 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 target 1 dan 2 hingga target 1 dan 2 tidak tersedia. Jika target 1 dan 2 tidak tersedia, semua traffic akan dirutekan ke target 3.

Jalur

Path menentukan fragmen URI yang akan ditambahkan ke semua permintaan yang dikeluarkan oleh TargetServer ke server backend.

Elemen ini menerima jalur string literal atau template pesan. 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 TargetServer untuk menentukan layanan backend, dan layanan backend memerlukan koneksi untuk menggunakan protokol HTTPS, Anda harus mengaktifkan TLS/SSL dalam definisi TargetServer. Hal ini diperlukan karena tag <Host> tidak memungkinkan Anda menentukan protokol koneksi. Di bawah ini adalah definisi TargetServer untuk TLS/SSL satu arah tempat Edge membuat permintaan HTTPS ke layanan backend:

<TargetServer name="target1">
  <Host>mocktarget.apigee.net</Host>
  <Port>443</Port>
  <IsEnabled>true</IsEnabled>
  <SSLInfo>
      <Enabled>true</Enabled>
  </SSLInfo> 
</TargetServer>

Jika layanan backend memerlukan TLS/SSL dua arah atau timbal balik, Anda harus mengonfigurasi TargetServer menggunakan setelan konfigurasi TLS/SSL yang sama dengan TargetEndpoints:

<TargetServer  name="TargetServer 1">
    <IsEnabled>true</IsEnabled>
    <Host>www.example.com</Host>
    <Port>443</Port>
    <SSLInfo>
        <Ciphers/>
        <ClientAuthEnabled>true</ClientAuthEnabled>
        <Enabled>true</Enabled>
        <IgnoreValidationErrors>false</IgnoreValidationErrors>
        <KeyAlias>keystore-alias</KeyAlias>
        <KeyStore>keystore-name</KeyStore>
        <Protocols/>
        <TrustStore>truststore-name</TrustStore>
    </SSLInfo>
</TargetServer >

Untuk informasi tentang properti <SSLInfo>, seperti <Ciphers> dan <ClientAuthEnabled>, lihat informasi tentang cara menetapkan properti tersebut untuk Host Virtual di Mengonfigurasi akses TLS ke API untuk Cloud Pribadi.

Untuk petunjuk lengkap tentang cara mengonfigurasi TLS/SSL keluar, lihat Mengonfigurasi TLS dari Edge ke backend (Cloud dan Private Cloud).

Skema TargetServer

Lihat skema untuk TargetServer dan entitas lainnya di GitHub.

Pemantauan kesehatan

Pemantauan kondisi memungkinkan Anda meningkatkan konfigurasi load balancing dengan secara aktif melakukan polling terhadap URL layanan backend yang ditentukan dalam konfigurasi TargetServer. Dengan pemantauan kondisi diaktifkan, TargetServer yang gagal akan otomatis dimasukkan kembali ke rotasi saat HealthMonitor menentukan bahwa TargetServer aktif.

Pemantauan kesehatan berfungsi dengan <MaxFailures>. Tanpa pemantauan kondisi diaktifkan, <MaxFailures> menentukan jumlah permintaan yang gagal dari proxy API ke TargetServer yang menyebabkan permintaan dialihkan ke TargetServer lain. TargetServer yang gagal kemudian dikeluarkan dari rotasi hingga Anda men-deploy ulang proxy.

Dengan pemantauan status diaktifkan, TargetServer yang gagal akan otomatis dimasukkan kembali ke rotasi dan tidak perlu deployment ulang proxy.

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

• Klien TCP hanya memastikan bahwa soket dapat dibuka.
• Anda mengonfigurasi klien HTTP untuk mengirimkan permintaan HTTP yang valid ke layanan backend. Anda dapat menentukan operasi HTTP GET, PUT, POST, atau DELETE. Respons panggilan monitor HTTP harus cocok dengan setelan yang dikonfigurasi di blok <SuccessResponse>.

Keberhasilan dan kegagalan

Saat Anda mengaktifkan pemantauan kondisi, Edge 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 kode status HTTP 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 Edge menentukan bahwa server responsif, Edge 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 Edge ke port health check.
  • Tidak merespons permintaan health check dalam jangka waktu yang ditentukan.
  • 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, Edge akan menambah jumlah kegagalan server tersebut. Jika jumlah kegagalan untuk server tersebut memenuhi atau melebihi nilai minimum yang telah ditentukan (<MaxFailures>), Edge akan berhenti mengirim permintaan ke server tersebut.

Mengaktifkan HealthMonitor

Untuk membuat HealthMonitor, Anda menambahkan elemen <HealthMonitor> ke konfigurasi HTTPConnection TargetEndpoint untuk proxy. Anda tidak dapat melakukannya di UI. Sebagai gantinya, Anda membuat konfigurasi proxy dan menguploadnya sebagai file ZIP ke Edge. 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.

HealthMonitor sederhana menentukan IntervalInSec yang digabungkan dengan TCPMonitor atau HTTPMonitor. Elemen <MaxFailures> menentukan jumlah maksimum permintaan yang gagal dari proxy API ke TargetServer yang mengakibatkan permintaan tersebut dialihkan ke TargetServer lain. Secara default, <MaxFailures> adalah 0, yang berarti Edge tidak melakukan tindakan korektif. Saat mengonfigurasi health monitor, pastikan Anda menetapkan <MaxFailures> dalam tag <HTTPTargetConnection> dari tag <TargetEndpoint> ke nilai bukan nol.

TCPMonitor

Konfigurasi di bawah menentukan HealthMonitor yang melakukan polling pada setiap TargetServer dengan membuka koneksi di port 80 setiap lima detik. (Port bersifat opsional. Jika tidak ditentukan, port TCPMonitor adalah port TargetServer.)

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

Anda dapat menambahkan HealthMonitor sebagai elemen turunan dari elemen HTTPTargetConnetion TargetEndpoint, seperti yang ditunjukkan di bawah ini:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <MaxFailures>5</MaxFailures>
      </LoadBalancer>
      <Path>/test</Path>
      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <TCPMonitor>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
            <Port>80</Port>
        </TCPMonitor>
      </HealthMonitor>
  </HTTPTargetConnection>
. . .

HealthMonitor dengan elemen konfigurasi TCPMonitor

Tabel berikut menjelaskan elemen konfigurasi TCPMonitor:

HTTPMonitor

Contoh HealthMonitor yang menggunakan HTTPMonitor akan mengirimkan permintaan GET ke layanan backend sekali setiap lima detik. Contoh di bawah menambahkan header Otorisasi Dasar HTTP ke pesan permintaan. Konfigurasi Respons menentukan setelan yang akan dibandingkan dengan respons sebenarnya dari layanan backend. Pada contoh di bawah, respons yang diharapkan adalah kode respons HTTP 200 dan header HTTP kustom ImOK yang nilainya adalah YourOK. Jika respons tidak cocok, permintaan akan diperlakukan sebagai kegagalan oleh konfigurasi load balancer.

HTTPMonitor mendukung layanan backend yang dikonfigurasi untuk menggunakan protokol HTTP dan HTTPS satu arah. Namun, fitur ini tidak mendukung hal berikut:

• HTTPS dua arah (juga disebut TLS/SSL dua arah)
• Sertifikat yang ditandatangani sendiri.

Perhatikan bahwa semua setelan Permintaan dan Respons di monitor HTTP akan spesifik untuk layanan backend yang harus dipanggil.

    <HealthMonitor>
      <IsEnabled>true</IsEnabled>
      <IntervalInSec>5</IntervalInSec>
      <HTTPMonitor>
        <Request>
          <IsSSL>true</IsSSL>
          <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
          <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
          <Port>80</Port>
          <Verb>GET</Verb>
          <Path>/healthcheck</Path>
          <Header name="Authorization">Basic 12e98yfw87etf</Header>
          <IncludeHealthCheckIdHeader>true</IncludeHealthCheckIdHeader>
        </Request>
        <SuccessResponse>
          <ResponseCode>200</ResponseCode>
          <Header name="ImOK">YourOK</Header>
        </SuccessResponse>
      </HTTPMonitor>
    </HealthMonitor>
    

HealthMonitor dengan elemen konfigurasi HTTPMonitor

Tabel berikut menjelaskan elemen konfigurasi HTTPMonitor: