Load balancing di berbagai server backend

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

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

Konfigurasi TargetServer memisahkan URL endpoint konkret dari TargetEndpoint konfigurasi standar. Setiap TargetServer direferensikan oleh nama di TargetEndpoint Koneksi HTTP. Daripada menetapkan URL konkret dalam konfigurasi, Anda dapat mengonfigurasinya atau lebih bernama TargetServers seperti yang dijelaskan di bagian TargetEndpoint.

Definisi TargetServer terdiri dari nama, {i>host<i} dan porta, dengan elemen tambahan untuk menunjukkan apakah TargetServer diaktifkan atau dinonaktifkan.

Video

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

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. Sebagai 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 Anda 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 TargetServers di lingkungan:

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

Contoh respons:

[ "target2", "target1" ]

Saat ini ada dua TargetServer yang tersedia untuk digunakan oleh proxy API yang di-deploy dalam pengujian lingkungan fleksibel App Engine. Untuk melakukan load balancing pada traffic di seluruh TargetServers ini, Anda mengonfigurasi di endpoint target proxy API untuk menggunakan TargetServers.

Ada batas 500 TargetServers per lingkungan, karena didokumentasikan dalam topik Batas.

Mengonfigurasi TargetEndpoint untuk melakukan load balancing di seluruh TargetServers yang diberi nama

Sekarang setelah Anda memiliki dua TargetServers yang tersedia, Anda dapat memodifikasi pengaturan koneksi 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 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 target 2.

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

Menetapkan opsi load balancer

Anda dapat menyesuaikan ketersediaan dengan menggunakan opsi untuk load balancing dan failover saat pemuatan dan TargetServer di Google Cloud. Bagian ini menjelaskan opsi tersebut.

Algoritma

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

Round robin

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

Berbobot

Algoritma load balancing tertimbang memungkinkan Anda mengonfigurasi pemuatan traffic TargetServers Anda. LoadBalancer tertimbang mendistribusikan permintaan ke TargetServers Anda secara langsung proporsi untuk setiap bobot 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 Jarang

LoadBalancer dikonfigurasi untuk menggunakan algoritma koneksi paling sedikit mengarahkan 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. Kapan ini terjadi, penghitung kegagalan bertambah satu.

Namun, ketika Apigee menerima respons dari target, meskipun responsnya adalah error HTTP (seperti 500), yang dihitung sebagai respons dari server target, dan penghitung kegagalan akan diatur ulang. Untuk membantu memastikan bahwa respons HTTP yang buruk (seperti 500) juga akan menambah penghitung kegagalan untuk mengeluarkan server yang tidak responsif rotasi load balancing sesegera mungkin, Anda dapat menambahkan Elemen <ServerUnhealthyResponse> dengan <ResponseCode> elemen turunan ke konfigurasi load balancer. Edge juga akan menghitung respons kode sebagai kegagalan.

Dalam contoh berikut, target1 akan dihapus dari rotasi setelah lima permintaan yang 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. Hal ini berarti bahwa 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 dihapus dari rotasi jika target gagal, berapa kali yang Anda tentukan. Ketika seorang HealthMonitor sudah diterapkan, Apigee secara otomatis menempatkan TargetServer kembali berputar setelah target aktif dan berjalan lagi, sesuai dengan konfigurasi HealthMonitor tersebut. Lihat Pemantauan kesehatan untuk informasi selengkapnya.

Atau, jika Anda mengonfigurasi MaxFailures > 0, dan Anda tidak mengonfigurasi HealthMonitor, Apigee tidak akan menyertakan kembali TargetServer ke dalam rotasi secara otomatis setelah Apigee mendeteksi kegagalan. Dalam hal ini, Anda harus men-deploy ulang proxy API sebelum Apigee mengembalikan TargetServer ke kunci. Lihat Men-deploy proxy API.

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) TargetServer dapat disetel sebagai 'fallback' server tertentu. TargetServer penggantian tidak disertakan dalam rutinitas load balancing sampai semua TargetServer lainnya diidentifikasi sebagai tidak tersedia oleh load balancer. Saat load balancer menentukan bahwa semua TargetServer 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 {i>round robin<i} antara target 1 dan 2 hingga target 1 dan 2 tidak tersedia. Jika target 1 dan 2 tidak tersedia, semua traffic akan dirutekan yang ditargetkan 3.

Jalur

Jalur 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. 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 TargetServer untuk menentukan layanan backend dan layanan backend mengharuskan koneksi menggunakan protokol HTTPS, maka Anda harus mengaktifkan TLS/SSL di Definisi TargetServer. Hal ini diperlukan karena tag <Host> tidak mengizinkan Anda menentukan protokol koneksi. Di bawah ini adalah definisi TargetServer untuk satu arah TLS/SSL 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 bersama, Anda TargetServer dengan 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 setelan properti tersebut untuk Host Virtual di Mengonfigurasi akses TLS ke API untuk Private Cloud.

Untuk petunjuk selengkapnya tentang 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 URL layanan backend yang ditentukan dalam konfigurasi TargetServer. Dengan mengaktifkan pemantauan kesehatan, TargetServer yang gagal secara otomatis dikembalikan ke rotasi ketika HealthMonitor menentukan bahwa TargetServer aktif.

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

Dengan pemantauan kondisi aktif, TargetServer yang gagal akan otomatis dikembalikan ke rotasi dan tanpa proxy deployment ulang 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 mengonfigurasi setelan di blok <SuccessResponse>.

Keberhasilan dan kegagalan

Saat Anda mengaktifkan pemantauan kondisi, Edge mulai mengirim health check ke target Anda server tertentu. 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 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 Edge menentukan bahwa server responsif, Edge 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 Edge 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, Edge akan menambah jumlah kegagalan server tersebut. Jika jumlah kegagalan untuk server tersebut yang memenuhi atau melampaui batas yang telah ditentukan (<MaxFailures>), Edge berhenti mengirim permintaan ke server tersebut.

Mengaktifkan HealthMonitor

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

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

TCPMonitor

Konfigurasi di bawah ini menentukan HealthMonitor yang memeriksa setiap TargetServer dengan membuka pada porta 80 setiap lima detik. (Port bersifat opsional. Jika tidak ditentukan, porta TCPMonitor adalah porta TargetServer.)

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

Anda dapat menambahkan HealthMonitor sebagai elemen turunan dari 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 backend layanan setiap lima detik. Contoh di bawah ini menambahkan header Otorisasi Dasar HTTP ke bagian pesan permintaan. Konfigurasi Respons menetapkan pengaturan yang akan dibandingkan dengan yang sebenarnya respons dari layanan backend. Dalam contoh di bawah ini, respons yang diharapkan adalah permintaan HTTP kode respons 200 dan header HTTP kustom ImOK yang nilainya YourOK. Jika respons tidak cocok, permintaan akan dianggap gagal oleh konfigurasi load balancer.

HTTPMonitor mendukung layanan backend yang dikonfigurasi untuk menggunakan HTTP dan HTTPS satu arah protokol yang sama. 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: