Arka uç sunucularında yük dengeleme

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

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

TargetServer yapılandırmaları, somut uç nokta URL'lerini TargetEndpoint yapılandırmalarından ayırır. Her TargetServer, bir TargetEndpoint HTTPConnection'da ada göre referans verilir. Yapılandırmada somut 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ı; ad, ana makine ve bağlantı noktasından oluşur. Ayrıca TargetServer'ın etkin veya devre dışı olduğunu 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

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. Daha fazla bilgi için TargetServers başlıklı makaleye 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, 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 test ortamında dağıtılan API proxy'leri tarafından kullanılabilen iki TargetServer var. Bu TargetServer'lar arasında trafiği yük dengelemek için bir API proxy'sinin hedef uç noktasındaki HTTP bağlantısını TargetServer'ları 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 dengeleme için TargetEndpoint yapılandırma

Artık iki TargetServer'ınız olduğuna göre, TargetEndpoint HTTP bağlantı ayarını bu iki TargetServer'a adıyla 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; çevrimsel sıralı, ağırlıklı ve en az bağlantı olmak üzere üç yük dengeleme algoritmasını destekler. Varsayılan algoritma, Sırayla Dağıtım'dır. Yukarıdaki yapılandırmada herhangi bir algoritma belirtilmediğinden, API proxy'sinden arka uç sunucularına yapılan giden istekler hedef1 ve hedef2 arasında bire bir değişir.

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

Yük dengeleyici seçeneklerini ayarlama

Yük dengeleyici ve TargetServer 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ı ayarlar. Kullanılabilen algoritmalar RoundRobin, Weighted ve LeastConnections'dir. Her biri aşağıda belgelenmiştir.

Çevrimsel sıralı

Varsayılan algoritma olan çevrimsel sıralı, sunucuların hedef uç nokta HTTP bağlantısında listelendiği sırayla her TargetServer'a bir istek iletir. Ö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ı, TargetServer'larınız için orantılı trafik yüklerini yapılandırmanıza olanak tanır. Ağırlıklı LoadBalancer, istekleri her bir TargetServer'ın ağırlığıyla doğru orantılı olarak TargetServer'larınıza dağıtır. Bu nedenle, ağırlıklı algoritma her TargetServer için bir weight özelliği ayarlamanızı 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 iki istek hedef2'ye yönlendirilir.

En Az Bağlantı

En az bağlantı algoritmasını kullanacak şekilde yapılandırılmış yük dengeleyiciler, giden istekleri en az açık HTTP bağlantısına sahip TargetServer'a 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ı

İsteğin başka bir TargetServer'a yönlendirilmesiyle sonuçlanan, API proxy'sinden TargetServer'a yapılan başarısız isteklerin maksimum sayısı.

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

Ancak Apigee bir hedeften yanıt aldığında, yanıt bir HTTP hatası (ör. 500) olsa bile bu, hedef sunucudan gelen bir yanıt olarak kabul edilir ve hata sayacı sıfırlanır. Kötü HTTP yanıtlarının (ör. 500) da hata sayacını artırarak sağlıksız bir sunucunun en kısa sürede yük dengeleme rotasyonundan çıkarılmasını sağlamak için yük dengeleyici yapılandırmanıza <ResponseCode> alt öğeleriyle birlikte <ServerUnhealthyResponse> öğesini ekleyebilirsiniz. Edge, bu kodları içeren yanıtları da başarısızlık olarak değerlendirir.

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

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

Varsayılan MaxFailures değeri 0'dır. Bu, Edge'in her istek için her zaman hedefe bağlanmaya çalıştığı ve hedef sunucuyu rotasyondan hiçbir zaman kaldırmadığı anlamına gelir.

MaxFailures > 0 değerini HealthMonitor ile birlikte kullanmak en iyisidir. MaxFailures > 0 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 mevcut olduğunda Apigee, hedef tekrar çalışmaya başladıktan sonra bu HealthMonitor'un yapılandırmasına göre TargetServer'ı otomatik olarak tekrar kullanıma alır. Daha fazla bilgi için Sağlık izleme başlıklı makaleyi inceleyin.

Alternatif olarak, MaxFailures > 0 değerini yapılandırır ve bir sağlık izleyicisi yapılandırmazsanız Apigee, ilk hata algılandığında hedef sunucuyu otomatik olarak rotasyonun dışına çıkarır. Apigee, hedef sunucunun durumunu beş dakikada bir kontrol eder ve normal şekilde yanıt verdiğinde sunucuyu rotasyona geri döndürür.

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ı hakkında 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 olarak ayarlayın. Örneğin:

<RetryEnabled>false</RetryEnabled>

IsFallback

Yalnızca bir TargetServer, "yedek" sunucu olarak ayarlanabilir. Yedek TargetServer, yük dengeleyici tarafından diğer tüm TargetServer'lar kullanılamaz olarak tanımlanana kadar yük dengeleme rutinlerine dahil edilmez. Yük dengeleyici, tüm TargetServer'ları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 hedef 1 hem de hedef 2 kullanılamayana kadar hedefler 1 ve 2 arasında çevrimsel sıralı yük dengeleme ile sonuçlanır. 1. ve 2. hedefler kullanılamadığında tüm trafik 3. hedefe yönlendirilir.

Yol

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

Bu öğe, değişmez dize yolu veya mesaj şablonu kabul eder. İleti şablonu, ç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ç 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>

TLS/SSL için hedef sunucu 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ği için 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 iki yönlü veya karşılıklı TLS/SSL gerektiriyorsa TargetServer'ı TargetEndpoints ile aynı TLS/SSL yapılandırma ayarlarını kullanarak 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 >

<SSLInfo> özellikleri (ör. <Ciphers> ve <ClientAuthEnabled>) hakkında bilgi edinmek için Configuring TLS access to an API for the Private Cloud (Özel bulut için API'ye TLS erişimini yapılandırma) başlıklı makalede bu özelliklerin sanal ana makine için ayarlanmasıyla ilgili bilgilere bakın.

Giden TLS/SSL'yi yapılandırma ile ilgili tüm talimatlar için TLS'yi Edge'den arka uca (Cloud ve Private Cloud) yapılandırma başlıklı makaleyi inceleyin.

TargetServer şeması

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

Sağlık durumu izleme

Durum izleme, TargetServer yapılandırmalarında tanımlanan arka uç hizmeti URL'lerini etkin bir şekilde yoklayarak yük dengeleme yapılandırmalarını geliştirmenize olanak tanır. Durum izleme etkinleştirildiğinde, durum denetimi TargetServer'ın etkin olduğunu belirlediğinde başarısız olan bir TargetServer otomatik olarak tekrar rotasyona alınır.

Cihaz sağlığı izleme özelliği <MaxFailures> ile çalışır. Sağlık izleme etkinleştirilmeden, <MaxFailures>, API proxy'sinden TargetServer'a yapılan ve isteğin başka bir TargetServer'a yönlendirilmesiyle sonuçlanan başarısız isteklerin sayısını belirtir. Ardından, başarısız olan TargetServer, proxy'yi yeniden dağıtana kadar rotasyondan çıkarılır.

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

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

• TCP istemcisi yalnızca bir soketin açılabileceğinden emin olur.
• 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 izleme çağrısının yanıtı, <SuccessResponse> bloğunda yapılandırılan ayarlarla eşleşmelidir.

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

Durum izlemeyi etkinleştirdiğinizde Edge, hedef sunucunuza durum kontrolleri göndermeye başlar. Durum denetimi, hedef sunucunun iyi durumda olup olmadığını belirleyen, hedef sunucuya gönderilen bir istektir.

Durum denetimi iki olası sonuçtan birini verebilir:

• Başarılı: Hedef sunucu, başarılı bir sağlık kontrolü yapıldığında sağlıklı kabul edilir. Bu durum genellikle aşağıdakilerden birinin veya daha fazlasının sonucudur:
  • Hedef sunucu, belirtilen bağlantı noktasına yeni bir bağlantı kabul eder, bu bağlantı noktasındaki bir isteğe yanıt verir ve ardından belirtilen zaman aralığında bağlantı noktasını 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, durum denetimi isteğine beklenen e-posta mesajıyla eşleşen bir e-posta mesajıyla yanıt verir.

  Edge, bir sunucunun iyi durumda olduğunu belirlediğinde istek göndermeye devam eder veya yeniden başlar.

• Başarısızlık: Hedef sunucu, denetimin türüne bağlı olarak farklı şekillerde durum denetimini geçemeyebilir. Hedef sunucu:
  • Edge'in durum denetimi bağlantı noktasına bağlanmasını reddediyor.
  • Belirli bir süre içinde durum denetimi isteğine yanıt vermiyor.
  • Beklenmeyen bir HTTP durum kodu döndürüyor.
  • Beklenen e-posta mesajıyla eşleşmeyen bir ileti gövdesiyle yanıt veriyor.

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

HealthMonitor'u etkinleştirme

HealthMonitor oluşturmak için <HealthMonitor> öğesini bir proxy'nin TargetEndpoint'inin HTTPConnection yapılandırmasına eklersiniz. Bu işlemi kullanıcı arayüzünde yapamazsınız. Bunun yerine bir proxy yapılandırması oluşturup Edge'e ZIP dosyası olarak yüklersiniz. Proxy yapılandırması, bir 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 Yapılandırma Referansı'na bakın.

Basit bir HealthMonitor, bir TCPMonitor veya HTTPMonitor ile birlikte bir IntervalInSec tanımlar. <MaxFailures> öğesi, isteğin başka bir TargetServer'a yönlendirilmesiyle sonuçlanan, API proxy'sinden TargetServer'a yapılan başarısız isteklerin maksimum sayısını belirtir. Varsayılan olarak <MaxFailures> değeri 0'dır. Bu, Edge'in düzeltici işlem yapmadığı anlamına gelir. Sağlık izleyicisi yapılandırırken <MaxFailures> etiketinin <TargetEndpoint> etiketindeki <HTTPTargetConnection> etiketinde sıfır olmayan bir değere ayarladığınızdan emin olun.

TCPMonitor

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

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

Aşağıda gösterildiği gibi, TargetEndpoint'in HTTPTargetConnetion öğesinin alt öğesi olarak 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 öğeleri içeren 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 Yetkilendirme üstbilgisi 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ız olarak değerlendirilir.

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

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

HTTP izleyicideki tüm İstek ve Yanıt ayarlarının, çağrılması gereken arka uç hizmetine özel 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 öğeleri içeren HealthMonitor

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