Load balancing di seluruh server backend

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

Apigee Edge meningkatkan ketersediaan API Anda dengan memberikan 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 mencantumkan server target. Untuk 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 menyediakan dua URL yang dapat digunakan TargetEndpoint untuk load balancing:

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

Contoh Respons:

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

Gunakan panggilan API berikut untuk mengambil daftar TargetServer di lingkungan:

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

Contoh respons:

[ "target2", "target1" ]

Sekarang ada dua TargetServer yang tersedia untuk digunakan oleh proxy API yang di-deploy di lingkungan pengujian. Untuk menyeimbangkan beban 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 menyeimbangkan beban di seluruh TargetServer bernama

Setelah memiliki dua TargetServer yang tersedia, Anda dapat mengubah setelan koneksi HTTP TargetEndpoint untuk mereferensikan kedua TargetServer tersebut berdasarkan nama:

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

Konfigurasi di atas adalah konfigurasi load balancing paling dasar yang memungkinkan. Load balancer mendukung tiga algoritma load balancing, yaitu Round Robin, Berbobot, dan Koneksi Paling Sedikit. 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 basepath URI TargetEndpoint untuk semua server target. Hanya digunakan saat <LoadBalancer> digunakan. Jika tidak, perintah akan diabaikan. Dalam contoh di atas, permintaan yang mencapai "target1" akan 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>. Algoritma 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 Anda. 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 Terkecil

LoadBalancer yang dikonfigurasi untuk menggunakan algoritma koneksi paling sedikit akan 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, saat Apigee menerima respons dari target, meskipun responsnya adalah error HTTP (seperti 500), hal itu dihitung sebagai respons dari server target, dan penghitung kegagalan 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 Anda. 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 jika target gagal sebanyak jumlah yang Anda tunjukkan. Jika HealthMonitor sudah ada, Apigee akan otomatis mengembalikan TargetServer ke dalam rotasi setelah target aktif dan berjalan kembali, sesuai dengan konfigurasi HealthMonitor tersebut. Lihat Pemantauan kondisi untuk mengetahui informasi selengkapnya.

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

Coba lagi

Jika percobaan ulang diaktifkan, permintaan akan dicoba ulang setiap kali 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 menyetel <ServerUnhealthyResponse>.

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

<RetryEnabled>false</RetryEnabled>

IsFallback

Satu (dan hanya satu) TargetServer dapat ditetapkan sebagai server 'fallback'. TargetServer penggantian tidak disertakan dalam rutin 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. Tindakan ini diperlukan karena tag <Host> tidak memungkinkan Anda menentukan protokol koneksi. Di bawah ini adalah definisi TargetServer untuk TLS/SSL satu arah di mana 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, maka Anda 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 mengetahui informasi tentang properti <SSLInfo>, seperti <Ciphers> dan <ClientAuthEnabled>, lihat informasi tentang cara menyetel properti tersebut untuk Host Virtual di Mengonfigurasi akses TLS ke API untuk Private Cloud.

Untuk mengetahui 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 pada 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 kesehatan diaktifkan, TargetServer yang gagal akan otomatis dimasukkan kembali ke rotasi dan tidak ada deployment ulang proxy yang diperlukan.

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

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

Keberhasilan dan kegagalan

Saat Anda mengaktifkan pemantauan kondisi, Edge akan mulai mengirim pemeriksaan kondisi ke server target Anda. Pemeriksaan kondisi 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 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 lain yang Anda anggap dapat diterima.
  • Server target merespons permintaan health check dengan isi pesan yang cocok dengan isi pesan yang diharapkan.

  Saat Edge menentukan bahwa server responsif, Edge akan melanjutkan atau melanjutkan pengiriman permintaan ke server tersebut.

• Kegagalan: Server target dapat gagal dalam health check dengan berbagai cara, bergantung pada jenis pemeriksaan. Kegagalan dapat dicatat saat server target:
  • Menolak koneksi dari Edge ke port health check.
  • Tidak merespons permintaan health check dalam jangka waktu tertentu.
  • Menampilkan kode status HTTP yang tidak 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 melampaui nilai minimum yang telah ditentukan sebelumnya (<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 dikombinasikan dengan TCPMonitor atau HTTPMonitor. Elemen <MaxFailures> menentukan jumlah maksimum permintaan yang gagal dari proxy API ke TargetServer yang mengakibatkan permintaan dialihkan ke TargetServer lain. Secara default, <MaxFailures> adalah 0, yang berarti Edge tidak melakukan tindakan korektif. Saat mengonfigurasi pemantau kondisi, pastikan Anda menetapkan <MaxFailures> di tag <HTTPTargetConnection> dari tag <TargetEndpoint> ke nilai bukan nol.

TCPMonitor

Konfigurasi di bawah menentukan HealthMonitor yang melakukan polling 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

HealthMonitor contoh yang menggunakan HTTPMonitor akan mengirimkan permintaan GET ke layanan backend setiap lima detik. Contoh di bawah menambahkan header Otorisasi Dasar HTTP ke pesan permintaan. Konfigurasi Respons menentukan setelan yang akan dibandingkan dengan respons aktual dari layanan backend. Dalam 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 dianggap 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 khusus untuk layanan backend yang harus dipanggil.

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

HealthMonitor dengan elemen konfigurasi HTTPMonitor

Tabel berikut menjelaskan elemen konfigurasi HTTPMonitor: