Arka uç sunucularında yük dengeleme

Apigee Edge belgelerini görüntülüyorsunuz.
Apigee X belgelerine gidin. info

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

TargetServer yapılandırmaları, belirli uç nokta URL'lerini TargetEndpoint yapılandırmalarından ayırır. Her TargetServer, TargetEndpoint HTTPConnection'da ada göre referans alır. Yapılandırmada belirli bir URL tanımlamak yerine, TargetEndpoint bölümünde açıklandığı gibi bir veya daha fazla adlandırılmış TargetServer yapılandırabilirsiniz.

TargetServer tanımı bir ad, ana makine ve bağlantı noktasından oluşur. Ayrıca, TargetServer'ın etkin olup olmadığını belirten ek bir öğe içerir.

Videolar

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

Ö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

Aşağıda açıklandığı şekilde hedef sunucuları 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. Daha fazla bilgi için TargetServers başlıklı makaleyi inceleyin.

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

Test ortamında dağıtılan API proxy'leri tarafından kullanılabilecek iki TargetServer artık mevcuttur. Trafiği bu hedef sunucularda dengelemek için API proxy'sinin hedef uç noktasındaki HTTP bağlantısını, hedef sunucuları kullanacak şekilde yapılandırırsınız.

Sınırlar konusunda belirtildiği gibi, ortam başına 500 TargetServer sınırı vardır.

Adlandırılmış TargetServer'lar arasında yük dengelemek için bir TargetEndpoint yapılandırması

Artık iki TargetServer'ınız olduğu için TargetEndpoint HTTP bağlantı ayarını, bu iki TargetServer'a adlarına göre referans verecek şekilde değiştirebilirsiniz:

<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, üç yük dengeleme algoritmasını (Çevrimsel Sıralı, Ağırlıklı ve En Az Bağlantı) destekler. Varsayılan algoritma sırayla döndürmedir. Yukarıdaki yapılandırmada herhangi bir algoritma belirtilmediğinden, API proxy'sinden arka uç sunuculara giden istekler hedef1 ve hedef 2 arasında bire bir olarak değişecektir.

<Path> öğesi, tüm hedef sunucular için TargetEndpoint URI'sinin temel yolunu oluşturur. Yalnızca <LoadBalancer> kullanılırken kullanılır. Aksi takdirde yoksayılır. Yukarıdaki örnekte, "target1"e ulaşan bir istek http://target1/test olur ve diğer hedef sunucular için de aynı durum geçerlidir.

Yük dengeleyici seçeneklerini ayarlama

Yük dengeleyici ve hedef sunucu düzeyinde yük dengeleme ve yük devretme seçeneklerini kullanarak kullanılabilirliği ayarlayabilirsiniz. Bu bölümde bu seçenekler açıklanmaktadır.

Algoritma

<LoadBalancer> tarafından kullanılan algoritmayı belirler. Kullanılabilen algoritmalar RoundRobin, Weighted ve LeastConnections'dir. Bunların her biri aşağıda açıklanmıştır.

Çevrimsel sıralı

Varsayılan algoritma olan dönen sıra, istekleri hedef uç nokta HTTP bağlantısında sunucuların listelendiği sırayla her bir hedef sunucuya yönlendirir. Ö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ı, hedef sunucularınız için orantılı trafik yükleri yapılandırmanıza olanak tanır. Ağırlıklı LoadBalancer, isteği hedef sunucularınıza her hedef sunucunun ağırlığına doğrudan orantılı olarak dağıtır. Bu nedenle, ağırlıklı algoritma her TargetServer için bir weight özelliği belirlemenizi gerektirir. Ö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, hedef1'e yönlendirilen her istek için hedef2'ye iki istek yönlendirilir.

En az bağlantı

En az bağlantı algoritmasını kullanacak şekilde yapılandırılmış LoadBalancer'lar, giden istekleri en az açık HTTP bağlantısına sahip hedef sunucuya yönlendirir. Ö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'den TargetServer'a gönderilen ve isteğin başka bir TargetServer'a yönlendirilmesine neden olan maksimum başarısız istek sayısı.

Yanıt hatası, Apigee'nin hedef sunucudan yanıt alamadığı anlamına gelir. Bu durumda, hata sayacı bir artar.

Ancak Apigee bir hedeften yanıt aldığında, yanıt bir HTTP hatası (500 gibi) olsa bile bu yanıt hedef sunucudan gelen bir yanıt olarak sayılır ve hata sayacı sıfırlanır. Kötü HTTP yanıtlarının (500 gibi) aynı zamanda hata sayacını artırarak sağlıklı olmayan bir sunucunun yük dengeleme rotasyonundan en kısa sürede çıkarılmasını sağlamak için yük dengeleyici yapılandırmanıza <ResponseCode> alt öğelerini içeren <ServerUnhealthyResponse> öğesini ekleyebilirsiniz. Edge, bu kodları içeren yanıtları da hata olarak sayar.

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

<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 varsayılan değeri 0'dır. Bu, Edge'in her istek için hedefe her zaman bağlanmaya çalıştığı ve hedef sunucuyu hiçbir zaman rotasyondan kaldırmadığı anlamına gelir.

HealthMonitor ile MaxFailures > 0 değerini kullanmak en iyisidir. MaxFailures değerini 0'dan büyük olarak yapılandırırsanız hedef, belirttiğiniz sayıda başarısız olduğunda TargetServer rotasyondan kaldırılır. Bir HealthMonitor kullanıldığında Apigee, hedef tekrar çalışır duruma geldikten sonra ilgili HealthMonitor'un yapılandırmasına göre TargetServer'ı otomatik olarak rotasyona geri ekler. Daha fazla bilgi için Sağlık izleme bölümüne bakın.

Alternatif olarak, MaxFailures değerini 0'dan büyük bir değere ayarlarsanız ve bir durum izleyici yapılandırmazsanız Apigee, ilk hata algılandığında hedef sunucuyu otomatik olarak rotasyondan çıkarır. Apigee, hedef sunucunun durumunu her beş dakikada bir kontrol eder ve normal yanıt verdiğinde sunucuya rotasyona dönmesini söyler.

Yeniden dene

Yeniden deneme etkinse yanıt hatası (G/Ç hatası veya HTTP zaman aşımı) oluştuğunda ya da alınan yanıt <ServerUnhealthyResponse> tarafından ayarlanan bir değerle eşleştiğinde istek yeniden denenir. <ServerUnhealthyResponse> ayarıyla ilgili daha fazla bilgi için yukarıdaki Maksimum hata sayısı bölümüne bakın.

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

<RetryEnabled>false</RetryEnabled>

IsFallback

"Yedek" sunucu olarak bir (ve yalnızca bir) TargetServer ayarlanabilir. Yük dengeleyici tarafından diğer tüm hedef sunucuların kullanılamadığı tespit edilene kadar yedek hedef sunucu, yük dengeleme rutinlerine dahil edilmez. Yük dengeleyici, tüm hedef sunucuların kullanılamadığını belirlediğinde 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, hem 1. hem de 2. hedef kullanılamadığında 1. ve 2. hedefler arasında dönen yük dengelemeyle sonuçlanır. 1. ve 2. hedefler kullanılamadığında tüm trafik 3. hedefe yönlendirilir.

Path

Yol, TargetServer tarafından arka uç sunucuya gönderilen tüm isteklere eklenecek bir URI fragmanını tanımlar.

Bu öğe, gerçek dize yolu veya mesaj şablonu kabul eder. Mesaj şablonları, çalışma zamanında değişken dize değiştirme işlemi yapmanıza olanak tanır. Örneğin, aşağıdaki hedef uç noktası 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>

TLS/SSL için hedef sunucuyu yapılandırma

Arka uç hizmetini tanımlamak için bir TargetServer kullanıyorsanız ve arka uç hizmeti, bağlantının HTTPS protokolünü kullanmasını gerektiriyorsa TargetServer tanımında TLS/SSL'yi etkinleştirmeniz gerekir. <Host> etiketi bağlantı protokolünü belirtmenize izin vermediğinden bu gereklidir. Aşağıda, Edge'in arka uç hizmetine HTTPS istekleri gönderdiği tek yönlü TLS/SSL için TargetServer tanımı gösterilmektedir:

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

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

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

<Ciphers> ve <ClientAuthEnabled> gibi <SSLInfo> mülkleri hakkında bilgi edinmek için Özel Cloud için bir API'ye TLS erişimini yapılandırma başlıklı makalede sanal ana makine için bu mülkleri ayarlama hakkındaki bilgilere bakın.

Giden TLS/SSL'yi yapılandırmayla ilgili tam talimatlar için Edge'den arka uca (Cloud ve Özel Cloud) TLS yapılandırması başlıklı makaleyi inceleyin.

TargetServer şeması

TargetServer ve diğer öğelerin şemasını GitHub'da bulabilirsiniz.

Sağlık durumu izleme

Sağlık izleme, TargetServer yapılandırmalarında tanımlanan arka uç hizmet URL'lerini etkin bir şekilde yoklayarak yük dengeleme yapılandırmalarını iyileştirmenize olanak tanır. Cihaz sağlığı izleme etkinleştirildiğinde, HealthMonitor TargetServer'ın etkin olduğunu belirlediğinde başarısız bir TargetServer otomatik olarak rotasyona geri alınır.

Cihaz sağlığı izleme, <MaxFailures> ile çalışır. Sağlık izleme etkin değilse <MaxFailures>, API proxy'sinden TargetServer'a gönderilen ve isteğin başka bir TargetServer'a yönlendirilmesine neden olan başarısız isteklerin sayısını belirtir. Ardından, proxy'yi yeniden dağıtana kadar başarısız olan TargetServer rotasyondan çıkarılır.

Durum izleme etkinleştirildiğinde, başarısız olan TargetServer otomatik olarak rotasyona geri alınır ve proxy'nin yeniden dağıtılması gerekmez.

HealthMonitor, TCP veya HTTP üzerinden arka uç hizmetini çağıran basit bir istemci gibi çalışır:

• TCP istemcisi, yalnızca bir soketin açılmasını sağlar.
• HTTP istemcisini, arka uç hizmetine geçerli bir HTTP isteği gönderecek şekilde yapılandırırsınız. HTTP GET, PUT, POST veya DELETE işlemlerini tanımlayabilirsiniz. HTTP izleyici çağrısının yanıtı, <SuccessResponse> bloğundaki yapılandırılmış ayarlarla eşleşmelidir.

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

Cihaz sağlığı izlemeyi etkinleştirdiğinizde Edge, hedef sunucunuza sağlık kontrolleri göndermeye başlar. Durum denetimi, hedef sunucuya gönderilen ve hedef sunucunun sağlıklı olup olmadığını belirleyen bir istektir.

Durum denetimi iki olası sonuçtan birine sahip olabilir:

• Başarılı: Başarılı bir durum denetimi yapıldığında hedef sunucu sağlıklı kabul edilir. Bu durum genellikle aşağıdakilerden biri veya birkaçının sonucunda ortaya çıkar:
  • Hedef sunucu, belirtilen bağlantı noktasına yönelik yeni bir bağlantıyı kabul eder, bu bağlantı noktasındaki bir isteğe yanıt verir ve ardından bağlantı noktasını belirtilen zaman aralığında kapatır. Hedef sunucudan gelen yanıtta "Connection: close" ifadesi yer alıyor
  • Hedef sunucu, durum denetimi isteğine 200 (OK) veya kabul edilebilir olduğunu belirlediğiniz başka bir HTTP durum koduyla yanıt verir.
  • Hedef sunucu, bir durum denetimi isteğine beklenen ileti gövdesiyle eşleşen bir ileti gövdesiyle yanıt verir.

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

• Başarısız: Hedef sunucu, denetim türüne bağlı olarak farklı şekillerde durum denetiminde başarısız olabilir. Hedef sunucu aşağıdaki durumlarda başarısız olabilir:
  • Edge'den durum denetimi bağlantı noktasına gelen bağlantıları 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 verir.

  Bir hedef sunucu durum denetiminde başarısız olduğunda Edge, söz konusu sunucunun hata sayısını artırır. Söz konusu sunucunun hata sayısı önceden tanımlanmış bir eşiği (<MaxFailures>) karşılıyorsa veya aşıyorsa Edge, söz konusu sunucuya istek göndermeyi durdurur.

HealthMonitor'u etkinleştirme

HealthMonitor oluşturmak için <HealthMonitor> öğesini, proxy için TargetEndpoint'in HTTPConnection yapılandırmasına ekleyin. Bu işlemi kullanıcı arayüzünde yapamazsınız. Bunun yerine, bir proxy yapılandırması oluşturup bunu ZIP dosyası olarak Edge'e yüklersiniz. Proxy yapılandırması, API proxy'sinin tüm yönlerinin yapılandırılmış bir açıklamasıdır. Proxy yapılandırmaları, önceden tanımlanmış bir dizin yapısındaki XML dosyalarından oluşur. Daha fazla bilgi için API Proxy'si Yapılandırma Referansı başlıklı makaleyi inceleyin.

Basit bir HealthMonitor, bir TCPMonitor veya HTTPMonitor ile birlikte bir IntervalInSec tanımlar. <MaxFailures> öğesi, API proxy'sinden TargetServer'a gönderilen ve isteğin başka bir TargetServer'a yönlendirilmesine neden olan maksimum başarısız istek sayısını belirtir. Varsayılan olarak <MaxFailures> 0'dır. Bu, Edge'in düzeltici işlem yapmadığı anlamına gelir. Bir sağlık izleyiciyi yapılandırırken <TargetEndpoint> etiketinin <HTTPTargetConnection> etiketindeki <MaxFailures> değerini sıfır olmayan bir değere ayarladığınızdan emin olun.

TCPMonitor

Aşağıdaki yapılandırma, her beş saniyede bir 80 numaralı bağlantı noktasında bağlantı açarak her TargetServer'ı yoklayan bir HealthMonitor tanımlar. (Bağlantı noktası isteğe bağlıdır. Belirtilmemişse TCPMonitor bağlantı noktası, hedef sunucu bağlantı noktasıdır.)

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

TargetEndpoint öğesinin HTTPTargetConnetion öğesinin alt öğesi olarak aşağıdaki gibi bir HealthMonitor ekleyebilirsiniz:

<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 örnek bir HealthMonitor, arka uç hizmetine beş saniyede bir GET isteği gönderir. Aşağıdaki örnekte, istek mesajına bir HTTP Temel Kimlik Doğrulaması üst bilgisi eklenmektedir. Yanıt yapılandırması, arka uç hizmetinden gelen gerçek yanıtla karşılaştırılacak ayarları tanımlar. Aşağıdaki örnekte, beklenen yanıt bir HTTP yanıt kodu 200 ve değeri YourOK olan özel bir HTTP üst bilgisi ImOK'dir. Yanıt eşleşmezse istek, yük dengeleyici yapılandırması tarafından başarısızlık olarak değerlendirilir.

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

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

Bir HTTP izleyicisindeki tüm istek ve yanıt ayarlarının, çağrılması gereken arka uç hizmetine özgü olacağını unutmayın.

    <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 öğeleriyle HealthMonitor

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