Równoważenie obciążenia na serwerach backendu

Wyświetlasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. info

Apigee Edge zwiększa dostępność interfejsu API, zapewniając wbudowaną obsługę równoważenia obciążenia i przełączania awaryjnego w wielu instancjach serwera backendu.

Konfiguracje TargetServer oddzielają konkretne adresy URL punktów końcowych od konfiguracji TargetEndpoint. Do każdego elementu TargetServer odwołuje się nazwa w elemencie TargetEndpoint HTTPConnection. Zamiast definiować konkretny adres URL w konfiguracji, możesz skonfigurować co najmniej 1 nazwany serwer docelowy zgodnie z opisem w sekcji TargetEndpoint.

Definicja TargetServer składa się z nazwy, hosta i portu oraz dodatkowego elementu wskazującego, czy TargetServer jest włączony czy wyłączony.

Filmy

Obejrzyj poniższe filmy, aby dowiedzieć się więcej o routingu interfejsów API i równoważeniu obciążenia za pomocą serwerów docelowych.

Przykładowa konfiguracja TargetServer

Poniższy kod definiuje serwer docelowy:

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

Elementy konfiguracji TargetServer

W tabeli poniżej opisujemy elementy używane do tworzenia i konfigurowania elementu TargetServer:

Zarządzanie serwerami docelowymi za pomocą interfejsu

Zarządzaj serwerami docelowymi w sposób opisany poniżej.

Zarządzanie serwerami docelowymi za pomocą interfejsu API

Za pomocą interfejsu Edge API możesz tworzyć, usuwać, aktualizować, pobierać i wyświetlać serwery docelowe. Więcej informacji znajdziesz w sekcji TargetServers.

Aby utworzyć serwer docelowy, użyj tego wywołania interfejsu API:

$ 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

Przykładowa odpowiedź:

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

Po utworzeniu pierwszego serwera docelowego użyj tego wywołania interfejsu API, aby utworzyć drugi serwer docelowy. Definiując 2 elementy TargetServer, podajesz 2 adresy URL, których element TargetEndpoint może używać do równoważenia obciążenia:

$ 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

Przykładowa odpowiedź:

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

Aby pobrać listę serwerów docelowych w środowisku, użyj tego wywołania interfejsu API:

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

Przykładowa odpowiedź:

[ "target2", "target1" ]

Obecnie dostępne są 2 serwery docelowe, które mogą być używane przez proxy interfejsu API wdrożone w środowisku testowym. Aby równoważyć obciążenie ruchem między tymi serwerami docelowymi, skonfiguruj połączenie HTTP w docelowym punkcie końcowym serwera proxy interfejsu API, aby korzystać z serwerów docelowych.

Obowiązuje limit 500 serwerów docelowych na środowisko, co zostało opisane w artykule Limity.

Konfigurowanie elementu TargetEndpoint do równoważenia obciążenia między nazwanymi elementami TargetServer

Teraz, gdy masz 2 serwery docelowe, możesz zmodyfikować ustawienie połączenia HTTP TargetEndpoint, aby odwoływać się do tych 2 serwerów docelowych według nazwy:

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

Powyższa konfiguracja jest najbardziej podstawową konfiguracją równoważenia obciążenia. System równoważenia obciążenia obsługuje 3 algorytmy równoważenia obciążenia: Round Robin, ważony i najmniejsze połączenie. Domyślnym algorytmem jest Round Robin. Ponieważ w powyższej konfiguracji nie określono żadnego algorytmu, żądania wychodzące z proxy interfejsu API do serwerów backendu będą naprzemiennie kierowane do elementów docelowych 1 i 2.

Element <Path> tworzy ścieżkę podstawową identyfikatora URI TargetEndpoint dla wszystkich serwerów docelowych. Jest używana tylko wtedy, gdy używana jest właściwość <LoadBalancer>. W przeciwnym razie jest ignorowane. W powyższym przykładzie żądanie docierające do „target1” będzie http://target1/test, podobnie jak w przypadku innych serwerów docelowych.

Ustawianie opcji systemu równoważenia obciążenia

Dostępność możesz dostosować, korzystając z opcji równoważenia obciążenia i przełączania awaryjnego na poziomie systemu równoważenia obciążenia i elementu TargetServer. W tej sekcji opisujemy te opcje.

Algorytm

Ustawia algorytm używany przez <LoadBalancer>. Dostępne algorytmy to RoundRobin, Weighted i LeastConnections. Każdy z nich został opisany poniżej.

Algorytm karuzelowy

Domyślny algorytm, czyli algorytm karuzelowy, przekazuje żądanie do każdego serwera TargetServer w kolejności, w jakiej serwery są wymienione w połączeniu HTTP punktu końcowego docelowego. Na przykład:

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

Ważona

Algorytm ważonego równoważenia obciążenia umożliwia skonfigurowanie proporcjonalnych obciążeń ruchem dla serwerów docelowych. Obciążony równoważnik obciążenia rozdziela żądania do serwerów docelowych w bezpośredniej proporcji do wagi każdego serwera docelowego. Dlatego algorytm ważony wymaga ustawienia atrybutu weight dla każdego serwera docelowego. Na przykład:

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

W tym przykładzie na każde żądanie kierowane do target1 będą kierowane 2 żądania do target2.

Najmniejsza liczba połączeń

Systemy równoważenia obciążenia skonfigurowane do korzystania z algorytmu najmniejszej liczby połączeń kierują żądania wychodzące do TargetServer z najmniejszą liczbą otwartych połączeń HTTP. Na przykład:

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

Maksymalna liczba błędów

Maksymalna liczba nieudanych żądań z serwera proxy interfejsu API do serwera docelowego, które powodują przekierowanie żądania do innego serwera docelowego.

Brak odpowiedzi oznacza, że Apigee nie otrzymuje żadnej odpowiedzi z serwera docelowego. Gdy to nastąpi, licznik niepowodzeń zwiększy się o 1.

Jeśli jednak Apigee otrzyma odpowiedź z miejsca docelowego, nawet jeśli jest to błąd HTTP (np. 500), jest to traktowane jako odpowiedź z serwera docelowego, a licznik niepowodzeń jest resetowany. Aby mieć pewność, że nieprawidłowe odpowiedzi HTTP (np. 500) również zwiększają licznik błędów i jak najszybciej wyłączają z rotacji równoważenia obciążenia serwer w złej kondycji, możesz dodać do konfiguracji systemu równoważenia obciążenia element <ServerUnhealthyResponse> z elementami podrzędnymi <ResponseCode>. Edge będzie też traktować odpowiedzi z tymi kodami jako nieudane.

W tym przykładzie adres target1 zostanie usunięty z rotacji po 5 nieudanych żądaniach, w tym po kilku odpowiedziach 5XX z serwera docelowego.

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

Domyślna wartość MaxFailures to 0. Oznacza to, że Edge zawsze próbuje połączyć się z elementem docelowym w przypadku każdego żądania i nigdy nie usuwa serwera docelowego z rotacji.

Najlepiej jest używać wartości MaxFailures > 0 z elementem HealthMonitor. Jeśli skonfigurujesz wartość MaxFailures > 0, serwer docelowy zostanie usunięty z rotacji, gdy nie powiedzie się określoną liczbę razy. Gdy jest włączony HealthMonitor, Apigee automatycznie przywraca TargetServer do rotacji po ponownym uruchomieniu serwera docelowego zgodnie z konfiguracją tego HealthMonitora. Więcej informacji znajdziesz w sekcji Monitorowanie stanu.

Jeśli skonfigurujesz MaxFailures > 0 i nie skonfigurujesz monitora stanu, Apigee automatycznie wyłączy serwer docelowy z rotacji po wykryciu pierwszej awarii. Apigee będzie sprawdzać stan serwera docelowego co 5 minut i przywracać go do rotacji, gdy będzie on odpowiadać w normalny sposób.

Spróbuj ponownie

Jeśli ponawianie jest włączone, żądanie zostanie ponowione za każdym razem, gdy wystąpi błąd odpowiedzi (błąd wejścia/wyjścia lub przekroczenie limitu czasu HTTP) lub otrzymana odpowiedź będzie zgodna z wartością ustawioną przez <ServerUnhealthyResponse>. Więcej informacji o ustawianiu wartości <ServerUnhealthyResponse> znajdziesz w sekcji Maksymalna liczba niepowodzeń powyżej.

Domyślnie wartość <RetryEnabled> jest ustawiona na true. Ustaw wartość false, aby wyłączyć ponawianie. Na przykład:

<RetryEnabled>false</RetryEnabled>

IsFallback

Jeden (i tylko jeden) serwer docelowy może być ustawiony jako serwer „rezerwowy”. Zastępczy serwer docelowy nie jest uwzględniany w procedurach równoważenia obciążenia, dopóki system równoważenia obciążenia nie uzna wszystkich pozostałych serwerów docelowych za niedostępne. Gdy system równoważenia obciążenia stwierdzi, że wszystkie serwery docelowe są niedostępne, cały ruch jest kierowany na serwer rezerwowy. Na przykład:

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

Powyższa konfiguracja powoduje równoważenie obciążenia algorytmem karuzelowym między elementami docelowymi 1 i 2 do momentu, gdy oba te elementy staną się niedostępne. Gdy cele 1 i 2 są niedostępne, cały ruch jest kierowany do celu 3.

Ścieżka

Ścieżka określa fragment URI, który będzie dołączany do wszystkich żądań wysyłanych przez TargetServer do serwera backendu.

Ten element akceptuje ścieżkę w postaci ciągu znaków lub szablon wiadomości. Szablon wiadomości umożliwia zastępowanie ciągów zmiennych w czasie działania. Na przykład w tej definicji docelowego punktu końcowego wartość {mypath} jest używana w ścieżce:

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

Konfigurowanie serwera docelowego pod kątem protokołu TLS/SSL

Jeśli do zdefiniowania usługi backendu używasz elementu TargetServer, a usługa backendu wymaga, aby połączenie korzystało z protokołu HTTPS, musisz w definicji elementu TargetServer włączyć TLS/SSL. Jest to konieczne, ponieważ tag <Host> nie pozwala określić protokołu połączenia. Poniżej znajduje się definicja TargetServer dla jednokierunkowego protokołu TLS/SSL, w którym Edge wysyła żądania HTTPS do usługi backendu:

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

Jeśli usługa backendu wymaga dwukierunkowego protokołu TLS/SSL, skonfiguruj element TargetServer, używając tych samych ustawień konfiguracji TLS/SSL co w przypadku elementu 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 >

Informacje o właściwościach <SSLInfo>, takich jak <Ciphers> i <ClientAuthEnabled>, znajdziesz w sekcji Konfigurowanie dostępu TLS do interfejsu API w chmurze prywatnej.

Pełne instrukcje konfigurowania wychodzącego protokołu TLS/SSL znajdziesz w artykule Konfigurowanie protokołu TLS od Edge do backendu (Cloud i Private Cloud).

Schemat TargetServer

Schemat TargetServer i innych podmiotów znajdziesz na GitHubie.

Monitorowanie stanu

Monitorowanie stanu umożliwia ulepszanie konfiguracji równoważenia obciążenia przez aktywne sprawdzanie adresów URL usługi backendu zdefiniowanych w konfiguracjach TargetServer. Jeśli monitorowanie stanu jest włączone, niesprawny serwer docelowy jest automatycznie przywracany do rotacji, gdy monitor stanu stwierdzi, że serwer docelowy jest aktywny.

Monitorowanie stanu działa z modelem <MaxFailures>. Jeśli monitorowanie stanu jest wyłączone, parametr <MaxFailures> określa liczbę nieudanych żądań z proxy interfejsu API do serwera docelowego, które powodują przekierowanie żądania do innego serwera docelowego. Nieprawidłowy serwer docelowy jest następnie wyłączany z rotacji, dopóki nie wdrożysz ponownie serwera proxy.

Gdy monitorowanie stanu jest włączone, nieudany serwer docelowy jest automatycznie przywracany do rotacji i nie wymaga ponownego wdrażania serwera proxy.

HealthMonitor działa jako prosty klient, który wywołuje usługę backendu przez TCP lub HTTP:

• Klient TCP po prostu sprawdza, czy można otworzyć gniazdo.
• Konfigurujesz klienta HTTP tak, aby przesyłał do usługi backendu prawidłowe żądanie HTTP. Możesz zdefiniować operacje HTTP GET, PUT, POST lub DELETE. Odpowiedź wywołania monitora HTTP musi być zgodna z konfigurowanymi ustawieniami w bloku <SuccessResponse>.

Sukcesy i niepowodzenia

Gdy włączysz monitorowanie stanu, Edge zacznie wysyłać sprawdzanie stanu do serwera docelowego. Kontrola stanu to żądanie wysyłane do serwera docelowego, które określa, czy serwer docelowy jest w dobrym stanie.

Kontrola stanu może dać jeden z 2 wyników:

• Sukces: serwer docelowy jest uznawany za działający prawidłowo, gdy kontrola stanu zakończy się powodzeniem. Zwykle jest to spowodowane co najmniej jednym z tych czynników:
  • Serwer docelowy akceptuje nowe połączenie z określonym portem, odpowiada na żądanie w tym porcie, a następnie zamyka port w określonym czasie. Odpowiedź serwera docelowego zawiera „Connection: close”.
  • Serwer docelowy odpowiada na żądanie kontroli stanu kodem 200 (OK) lub innym kodem stanu HTTP, który uznasz za dopuszczalny.
  • Serwer docelowy odpowiada na żądanie kontroli stanu treścią wiadomości, która jest zgodna z oczekiwaną treścią wiadomości.

  Gdy Edge stwierdzi, że serwer jest sprawny, kontynuuje lub wznawia wysyłanie do niego żądań.

• Niepowodzenie: serwer docelowy może nie przejść kontroli stanu na różne sposoby, w zależności od jej typu. Błąd może zostać zarejestrowany, gdy serwer docelowy:
  • Odrzuca połączenie z Edge do portu kontroli stanu.
  • nie odpowiada na żądanie kontroli stanu w określonym czasie,
  • Zwraca nieoczekiwany kod stanu HTTP.
  • Odpowiada treścią wiadomości, która nie pasuje do oczekiwanej treści.

  Gdy serwer docelowy nie przejdzie kontroli stanu, Edge zwiększa liczbę niepowodzeń tego serwera. Jeśli liczba błędów na tym serwerze osiągnie lub przekroczy wstępnie zdefiniowany próg (<MaxFailures>), Edge przestanie wysyłać do niego żądania.

Włączanie monitora stanu

Aby utworzyć HealthMonitor, dodaj element <HealthMonitor> do konfiguracji HTTPConnection elementu TargetEndpoint w przypadku serwera proxy. Nie możesz tego zrobić w interfejsie. Zamiast tego utwórz konfigurację serwera proxy i prześlij ją do Edge jako plik ZIP. Konfiguracja serwera proxy to strukturalny opis wszystkich aspektów proxy interfejsu API. Konfiguracje serwera proxy składają się z plików XML w wstępnie zdefiniowanej strukturze katalogów. Więcej informacji znajdziesz w dokumentacji konfiguracji serwera proxy API.

Prosty HealthMonitor definiuje IntervalInSec w połączeniu z TCPMonitor lub HTTPMonitor. Element <MaxFailures> określa maksymalną liczbę nieudanych żądań z serwera proxy interfejsu API do serwera docelowego, które powodują przekierowanie żądania do innego serwera docelowego. Domyślnie wartość <MaxFailures> wynosi 0, co oznacza, że Edge nie podejmuje żadnych działań naprawczych. Podczas konfigurowania monitora stanu upewnij się, że w tagu <MaxFailures> w tagu <HTTPTargetConnection> tagu <TargetEndpoint> ustawiono wartość inną niż zero.

TCPMonitor

Poniższa konfiguracja definiuje HealthMonitor, który co 5 sekund wysyła zapytanie do każdego serwera docelowego, otwierając połączenie na porcie 80. (Port jest opcjonalny. Jeśli nie podasz żadnej wartości, port TCPMonitor będzie portem TargetServer).

• Jeśli połączenie się nie uda lub nawiązanie połączenia trwa dłużej niż 10 sekund, licznik niepowodzeń zostanie zwiększony o 1 w przypadku tego serwera docelowego.
• Jeśli połączenie się powiedzie, liczba nieudanych połączeń z elementem TargetServer zostanie zresetowana do 0.

Element HealthMonitor możesz dodać jako element podrzędny elementu HTTPTargetConnetion w elemencie TargetEndpoint, jak pokazano poniżej:

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

Elementy konfiguracji HealthMonitor z TCPMonitor

W tabeli poniżej znajdziesz opis elementów konfiguracji TCPMonitor:

HTTPMonitor

Przykładowy HealthMonitor, który używa HTTPMonitor, będzie wysyłać żądanie GET do usługi backendu co 5 sekund. W przykładzie poniżej do wiadomości z żądaniem dodano nagłówek HTTP Basic Authorization. Konfiguracja odpowiedzi określa ustawienia, które będą porównywane z rzeczywistą odpowiedzią usługi backendu. W przykładzie poniżej oczekiwana odpowiedź to kod odpowiedzi HTTP 200 i niestandardowy nagłówek HTTP ImOK, którego wartość to YourOK. Jeśli odpowiedź nie pasuje, system równoważenia obciążenia uzna żądanie za nieudane.

Monitor HTTP obsługuje usługi backendu skonfigurowane do korzystania z protokołów HTTP i jednokierunkowego HTTPS. Nie obsługuje jednak tych funkcji:

• Dwukierunkowy protokół HTTPS (nazywany też dwukierunkowym protokołem TLS/SSL)
• podpisane samodzielnie,

Pamiętaj, że wszystkie ustawienia żądania i odpowiedzi w monitorze HTTP będą dotyczyć usługi backendu, która musi zostać wywołana.

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

Elementy konfiguracji HealthMonitor z HTTPMonitor

W tabeli poniżej znajdziesz opis elementów konfiguracji HTTPMonitor: