Arka uç sunucularında yük dengeleme

Apigee Edge belgelerini görüntülüyorsunuz.
. Git: Apigee X belgeleri. bilgi

Apigee Edge, yük için yerleşik destek sağlayarak API'nizin kullanılabilirliğini artırır birden fazla arka uç sunucu örneği arasında dengeleme ve yük devretme

TargetServer yapılandırmaları, somut uç nokta URL'lerini TargetEndpoint'ten ayırır yapılandırmanın üç yolu vardır. Her TargetServer'a bir TargetEndpoint'in adı gönderilir. HTTPConnection (Bağlantı Kurma) seçeneğini tıklayın. Yapılandırmada somut bir URL tanımlamak yerine, bölümünde açıklandığı gibi, daha fazla adlandırılmış TargetServers TargetEndpoint (Hedef Uç Noktası) öğesini seçin.

TargetServer tanımı bir ad, bir ana makine ve bir bağlantı noktasından oluşur. Bağlantı noktası; şunları yapar: TargetServer'ın etkin mi yoksa devre dışı mı olduğunu belirtin.

Videolar

Hedef kitle kullanarak API yönlendirmesi ve yük dengeleme hakkında daha fazla bilgi edinmek için aşağıdaki videoları izleyin: sunucular

Örnek TargetServer Yapılandırması

Aşağıdaki kod bir hedef sunucuyu tanımlar:

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

TargetServer Yapılandırma Öğeleri

Aşağıdaki tabloda TargetServer'ı oluşturmak ve yapılandırmak için kullanılan öğeler açıklanmaktadır:

Kullanıcı arayüzünü kullanarak hedef sunucuları yönetme

Hedef sunucuları aşağıda açıklandığı şekilde yönetin.

API'yi kullanarak hedef sunucuları yönetme

Hedef sunucuları oluşturmak, silmek, güncellemek, almak ve listelemek için Edge API'yi kullanabilirsiniz. Örneğin, Daha fazla bilgi için TargetServers'a bakın.

Hedef sunucu oluşturmak için aşağıdaki API çağrısını kullanın:

$ 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

Örnek Yanıt:

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

İlk TargetServer'ı oluşturduktan sonra, ikinci bir TargetServer oluşturmak için aşağıdaki API çağrısını kullanın. İki TargetServer tanımlayarak, bir TargetEndpoint'in yük dengeleme için kullanabileceği iki URL sağlarsınız:

$ 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

Örnek Yanıt:

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

Bir ortamdaki TargetServer'ların listesini almak için aşağıdaki API çağrısını kullanın:

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

Örnek yanıt:

[ "target2", "target1" ]

Artık testte dağıtılan API proxy'leri tarafından kullanılabilecek iki TargetServer var bahsedeceğim. Bu TargetServer'lar arasında trafiğin yük dengelemesi için HTTP API proxy'sinin hedef uç noktasındaki hedef uç noktasından bağlanmalıdır.

Ortam başına 500 TargetServer sınırı vardır, Sınırlar konusunda açıklanmaktadır.

Bir Adlandırılmış TargetServer'lar arasında yük dengelemek için TargetEndpoint

İki TargetServer'ınız olduğuna göre artık TargetEndpoint HTTP bağlantı ayarını kullanarak bu iki TargetServer'a (hedef sunucuya isme göre) referans gösterin:

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

Yukarıdaki yapılandırma, mümkün olan en temel yük dengeleme yapılandırmasıdır. Yük Dengeleyici üç tane yük dengeleme algoritmasını destekler: Döngüsel, Ağırlıklı ve En Az Bağlantı. Gruplama varsayılan algoritmadır. Yukarıdaki yapılandırmada algoritma belirtilmediğinden, API proxy'sinden arka uç sunucularına giden istekler, biri için bir tane olmak üzere hedef 1 ve hedef 2'dir.

<Path> öğesi, şunun için TargetEndpoint URI'sinin temel yolunu oluşturur tüm hedef sunucularda çalışır. Yalnızca <LoadBalancer> kullanıldığında kullanılır. Aksi halde yok sayılır. Yukarıdaki örnekte "target1" hedefine ulaşan bir istek olacak http://target1/test vb.

Yük dengeleyici seçeneklerini ayarlama

Yük sırasında yük dengeleme ve yük devretme seçeneklerini kullanarak kullanılabilirliği ayarlayabilirsiniz ve TargetServer seviyesinden erişebilirsiniz. Bu bölümde bu seçenekler açıklanmaktadır.

Algoritma

<LoadBalancer> tarafından kullanılan algoritmayı ayarlar. Mevcut RoundRobin, Weighted ve LeastConnections, Her biri aşağıda açıklanmıştır.

Çevrimsel sıralı

Varsayılan algoritma olan çevrimli sıralı, bir isteği her bir TargetServer'a Hedef uç nokta HTTP bağlantısında sunucuların listelendiği. Örneğin:

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

Ağırlıklı

Ağırlıklı yük dengeleme algoritması, yüksek dönüşüm hacmi için orantısal trafik yüklemelerini sunucularınızı kontrol etmeniz gerekir. Ağırlıklı LoadBalancer, isteği doğrudan TargetServer'larınıza dağıtır her TargetServer'ın ağırlığıyla orantılı hale gelecektir. Bu nedenle, ağırlıklı algoritma, videonuzun Her TargetServer için bir weight özelliği. Örneğin:

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

Bu örnekte, iki istek, hedef1.

En Az Bağlantı

En az bağlantı algoritmasını kullanacak şekilde yapılandırılan LoadBalancer'lar, giden istekleri En az açık HTTP bağlantısına sahip TargetServer. Örneğin:

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

Maksimum hata sayısı

API proxy'sinden TargetServer'a yapılan ve ile sonuçlanan maksimum başarısız istek sayısı isteğin başka bir TargetServer'a yönlendirilmesidir.

Yanıt hatası, Apigee'nin hedef sunucudan hiç yanıt almadığı anlamına gelir. Zaman bu durumda hata sayacı bir birim artar.

Ancak Apigee, hedeften yanıt aldığında yanıt bir HTTP hatası (500 gibi) olsa bile çalışır ve hata sayacı sıfırlanır. Kötü HTTP yanıtlarının (500 gibi) kötü durumdaki bir sunucuyu çıkarmak için hata sayacını da artırır en kısa sürede değiştirmek isterseniz <ResponseCode> içeren <ServerUnhealthyResponse> öğesi alt öğeleri eklemeniz gerekir. Edge, bunlarla ilişkili yanıtları da hata olarak kabul eder.

Aşağıdaki örnekte, target1 beş saniye sonra rotasyondan kaldırılacaktır hedef sunucudan gelen bazı 5XX yanıtları dahil olmak üzere başarısız istek sayısı.

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

MaxFailures'un varsayılan değeri 0'dır. Bu, Edge'in her zaman her istek için hedefe bağlanır ve hedef sunucuyu rotasyondan hiçbir zaman kaldırmaz.

En iyi seçenek MaxFailures > 0 olarak ayarlayın. MaxFailures > 0, TargetServer rotasyondan kaldırılır hedef, belirttiğiniz sayıda başarısız olduğunda. Bir HealthMonitor etkin olduğunda Apigee, Hedefe göre hedef yeniden çalışır duruma geldikten sonra TargetServer tekrar rotasyona alınır. yapılandırmasını ifade eder. Sağlık izleme başlıklı makaleyi inceleyin konulu videomuzu izleyin.

Alternatif olarak MaxFailures > 0 olarak çalışır ve HealthMonitor, Apigee, TargetServer'ı rotasyona yeniden dahil etmeyecektir otomatik olarak devreye girer. Bu durumda, Apigee, TargetServer'ı tekrar yerleştirmeden önce API proxy'sini sağlayabilir. Görüntüleyin API proxy'si dağıtma.

Yeniden dene

Yeniden deneme etkinleştirilirse her yanıt hatası (G/Ç hatası veya HTTP zaman aşımı) her seferinde istek yeniden denenir olur veya alınan yanıt <ServerUnhealthyResponse> tarafından ayarlanan bir değerle eşleşir. Ayar hakkında daha fazla bilgi için yukarıdaki Maksimum hata sayısı bölümüne bakın <ServerUnhealthyResponse>.

<RetryEnabled> varsayılan olarak true değerine ayarlıdır. Yeniden denemeyi devre dışı bırakmak için ayarı false olarak ayarlayın. Örneğin:

<RetryEnabled>false</RetryEnabled>

IsFallback

Bir (yalnızca bir) TargetServer "yedek" olarak ayarlanabilir sunucu. Yedek TargetServer diğer tüm TargetServer'lar aşağıdaki şekilde tanımlanana kadar yük dengeleme rutinlerine dahil edilmez: yük dengeleyici tarafından kullanılamaz. Yük dengeleyici tüm TargetServer'ların mevcut değilse tüm trafik yedek sunucuya yönlendirilir. Örneğin:

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

Yukarıdaki yapılandırma, hedef 1 ve 2 arasında döngülü yük dengelemesi yapılmasını sağlar. hem 1 hem de 2 mevcut değil. Hedef 1 ve 2 kullanılamadığında tüm trafik yönlendirilir 3 olarak ayarlayın.

Path

Yol, TargetServer tarafından yayınlanan tüm isteklere eklenecek bir URI parçası tanımlar. arka uç sunucusuna gönderilir.

Bu öğe, düz bir dize yolunu veya mesaj şablonunu kabul eder. Mesaj şablonu, çalışma zamanında değişken dizesi değişikliği yapmanıza olanak tanır. Örneğin, aşağıdaki hedef uç nokta tanımında yol için {mypath} değeri kullanılır:

<HTTPTargetConnection>
    <SSLInfo>
      <Enabled>true</Enabled>
    </SSLInfo>
    <LoadBalancer>
      <Server name="testserver"/>
    </LoadBalancer>
    <Path>{mypath}</Path>
</HTTPTargetConnection>

Şunun için hedef sunucu yapılandırma: TLS/SSL

Arka uç hizmetini ve arka uç hizmetini tanımlamak için TargetServer kullanıyorsanız HTTPS protokolünü kullanmak için bağlantıyı gerektiriyorsa, TargetServer tanımı. Bu gereklidir çünkü <Host> etiketi şunları yapmanıza izin vermez: bağlantı protokolünü belirtir. Aşağıda, tek yönlü için TargetServer tanımı verilmiştir Edge'in arka uç hizmetine HTTPS istekleri yaptığı TLS/SSL:

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

Arka uç hizmeti iki yönlü veya karşılıklı TLS/SSL gerektiriyorsa TargetEndpoints ile aynı TLS/SSL yapılandırma ayarlarını kullanarak TargetServer'ı yapılandırın:

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

<SSLInfo> özellikleri hakkında bilgi için <Ciphers> ve <ClientAuthEnabled>, bkz. API'ye TLS erişimini yapılandırma başlıklı makalede Sanal Ana Makine için bu özellikleri ayarlama hakkında bilgi inceleyin.

Giden TLS/SSL'nin yapılandırılmasına ilişkin talimatların tamamı için TLS'yi Yapılandırma uçtan uca (Bulut ve Private Cloud).

TargetServer şeması

üzerinde TargetServer ve diğer varlıkların şemasına bakın GitHub'ı tıklayın.

Sağlık durumu izleme

Durum izleme, TargetServer yapılandırmalarında tanımlanan arka uç hizmet URL'leri. Sağlık takibi etkinleştirildiğinde, HealthMonitor uygulaması tarafından belirlenen başarısız bir TargetServer otomatik olarak rotasyona TargetServer'ın etkin olduğundan emin olun.

Sağlık durumu izleme, <MaxFailures> ile çalışır. Sağlık durumu izleme etkin değilken <MaxFailures>, API proxy'sinden İsteğin başka bir TargetServer'a yönlendirilmesine neden olan TargetServer. Ardından, başarısız olan TargetServer, siz proxy'yi yeniden dağıtana kadar rotasyondan çıkarılır.

Durum izleme etkinken, başarısız olan bir TargetServer otomatik olarak rotasyona alınır ve proxy kullanılmaz Yeniden dağıtım gereklidir.

HealthMonitor, TCP veya HTTP üzerinden bir arka uç hizmetini çağıran basit bir istemci görevi görür:

• TCP istemcisi yalnızca bir yuvanın açılabilmesini sağlar.
• HTTP istemcisini arka uç hizmetine geçerli bir HTTP isteği gönderecek şekilde yapılandırırsınız. Siz HTTP GET, PUT, POST veya DELETE işlemlerini tanımlayabilir. HTTP izleme çağrısının yanıtı, <SuccessResponse> bloğundaki yapılandırılmış ayarlar.

Başarılar ve başarısızlıklar

Durum izlemeyi etkinleştirdiğinizde Edge, hedefinize durum denetimleri göndermeye başlar sunucu. Durum denetimi, hedef sunucuya gönderilen ve iyi olup olmadığını kontrol edin.

Durum denetiminde iki olası sonuçtan biri gösterilebilir:

• Başarılı: Başarılı bir durum başarılı olduğunda, hedef sunucunun iyi durumda olduğu kabul edilir. kontrol edilir. Bu durum genellikle aşağıdakilerden birinin veya daha fazlasının bir sonucudur:
  • Hedef sunucu, belirtilen bağlantı noktasına yeni bir bağlantıyı kabul eder, bu bağlantı noktasındaki bir isteğe yanıt verir ve ardından belirtilen zaman aralığı içinde bağlantı noktasını kapatır. Hedef sunucunun yanıtı "Connection: close" ifadesini içerir.
  • Hedef sunucu, durum denetimi isteğine 200 (Başarılı) veya kabul edilebilir olduğunu belirlediğiniz başka bir HTTP durum koduyla yanıt verir.
  • Hedef sunucu, beklenen ileti gövdesiyle eşleşen bir ileti gövdesiyle durum denetimi isteğine yanıt verir.

  Edge, bir sunucunun iyi durumda olduğunu belirlediğinde, Edge o sunucuya istek göndermeye devam eder veya devam eder.

• Hata: Hedef sunucu, durum denetiminde farklı şekillerde başarısız olabilir. değişebilmektedir. Hedef sunucu aşağıdaki işlemleri gerçekleştirdiğinde hata günlüğe kaydedilebilir:
  • Edge'den durum denetimi bağlantı noktasına olan bağlantıyı reddeder.
  • Belirli bir süre içinde durum denetimi isteğine yanıt vermez.
  • Beklenmeyen bir HTTP durum kodu döndürür.
  • Beklenen ileti gövdesiyle eşleşmeyen bir ileti gövdesiyle yanıt veriyor.

  Hedef sunucu durum denetiminde başarısız olursa Edge o sunucunun hata sayısını artırır. Eğer Söz konusu sunucunun önceden tanımlanmış bir eşiği karşıladığı veya aştığı hata sayısı (<MaxFailures>) ayarlanırsa Edge, bu sunucuya istek göndermeyi durdurur.

HealthMonitor'ü Etkinleştirme

HealthMonitor oluşturmak için TargetEndpoint'in HTTPConnection'a <HealthMonitor> öğesini ekleyin yapılandırmanın ne kadar önemli olduğu. Bunu kullanıcı arayüzünde yapamazsınız. Bunun yerine bir proxy yapılandırması oluşturup dosyayı Edge'e ZIP dosyası olarak yükleyin. Proxy yapılandırması tüm özelliklerin örneğidir. Proxy yapılandırmaları, önceden tanımlanmış dizin yapısındaki XML dosyalarından oluşur. Daha fazla daha fazla bilgi için API Proxy'si Yapılandırma Referansı.

Basit bir HealthMonitor, yaIntervalInSec TCPMonitor veya HTTPMonitor. <MaxFailures> öğesi, maksimum değeri belirtir API proxy'sinden TargetServer'a yapılan ve istekle sonuçlanan başarısız isteklerin sayısı başka bir TargetServer'a yönlendirilmek. <MaxFailures> varsayılan olarak 0'dır. Bu, şu anlama gelir: Edge herhangi bir düzeltme işlemi yapmaz. Durum izleyicisini yapılandırırken, şunları ayarladığınızdan emin olun: <MaxFailures> <HTTPTargetConnection> etiket <TargetEndpoint> etiketi sıfır olmayan bir değere ayarlayacağız.

TCPMonitor

Aşağıdaki yapılandırmada, bir her beş saniyede bir 80 numaralı bağlantı noktasından bağlanıyor. (Bağlantı noktası isteğe bağlıdır. Belirtilmezse TCPMonitor bağlantı noktası TargetServer bağlantı noktasıdır.)

• Bağlantı kurulamazsa veya bağlanması 10 saniyeden uzun sürerse hata sayısı o TargetServer için 1 artar.
• Bağlantı başarılı olursa TargetServer'ın hata sayısı 0'a sıfırlanır.

HealthMonitor'ü TargetEndpoint HTTPTargetConnetion alt öğesi olarak ekleyebilirsiniz. öğesini kullanın:

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

TCPMonitor yapılandırma öğeleriyle HealthMonitor

Aşağıdaki tabloda TCPMonitor yapılandırma öğeleri açıklanmaktadır:

HTTPMonitor

HTTPMonitor kullanan bir örnek HealthMonitor, arka uca bir GET isteği gönderir 10 veya 15 saniyede bir. Aşağıdaki örnekte, istek mesajıyla karşılaşırsınız. Yanıt yapılandırması, gerçek ile karşılaştırılacak ayarları tanımlar arka uç hizmetinden gelen yanıttır. Aşağıdaki örnekte, beklenen yanıt bir HTTP yanıt kodu 200 ve değeri şöyle bir özel HTTP üstbilgisi ImOK YourOK. Yanıt eşleşmezse istek, başarısız olarak değerlendirilir yük dengeleyici yapılandırmasına göre değişiyor.

HTTPMonitor, HTTP ve tek yönlü HTTPS kullanacak şekilde yapılandırılan arka uç hizmetlerini destekler. çok önemlidir. Ancak aşağıdakiler desteklenmez:

• İki yönlü HTTPS (iki yönlü TLS/SSL olarak da adlandırılır)
• Kendinden imzalı sertifikalar.

HTTP izleyicisindeki tüm İstek ve Yanıt ayarlarının arka uç hizmeti olabilir.

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

HTTPMonitor yapılandırma öğelerine sahip HealthMonitor

Aşağıdaki tabloda HTTPMonitor yapılandırma öğeleri açıklanmaktadır: