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. Każdy element TargetServer jest przywoływany po nazwie w elemencie HTTPConnection w elemencie TargetEndpoint. Zamiast definiować konkretny adres URL w konfiguracji, możesz skonfigurować jeden lub więcej nazwanych serwerów docelowych 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 interfejsu API i równoważeniu obciążenia za pomocą serwerów docelowych.

Przykładowa konfiguracja serwera docelowego

Poniższy kod definiuje serwer docelowy:

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

Elementy konfiguracji serwera docelowego

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 zgodnie z opisem 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 artykule 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 obiekty TargetServer, podajesz 2 adresy URL, których punkt końcowy 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" ]

W środowisku testowym są teraz dostępne 2 serwery docelowe, które mogą być używane przez serwery proxy interfejsu API. 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 tak, aby korzystało z serwerów docelowych.

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

Konfigurowanie elementu TargetEndpoint w celu równoważenia obciążenia między nazwanymi serwerami docelowymi

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 target1 i target2.

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 przykładzie powyżej żądanie docierające do serwera „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ć za pomocą 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

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

Algorytm karuzelowy

Domyślny 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 elementu TargetServer. 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 elementu 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.

Gdy jednak Apigee otrzyma odpowiedź z miejsca docelowego, nawet jeśli jest to błąd HTTP (np. 500), jest ona traktowana jako odpowiedź z serwera docelowego, a licznik niepowodzeń zostaje zresetowany. 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 nieprawidłowo działający serwer, 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 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>

Wartość domyślna parametru MaxFailures to 0. Oznacza to, że Edge zawsze próbuje połączyć się z serwerem docelowym w przypadku każdego żądania i nigdy nie usuwa go z rotacji.

Zalecamy używanie wartości MaxFailures > 0 z elementem HealthMonitor. Jeśli skonfigurujesz wartość MaxFailures > 0, serwer docelowy zostanie usunięty z rotacji, gdy docelowy serwer nie odpowie 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 TargetServer można ustawić 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 zapasowy. 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 znaków zmiennymi 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 na potrzeby 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łączyć TLS/SSL w definicji elementu TargetServer. Jest to konieczne, ponieważ tag <Host> nie pozwala określić protokołu połączenia. Poniżej znajduje się definicja elementu 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 TargetServer, używając tych samych ustawień konfiguracji TLS/SSL co 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 odpytywanie adresów URL usługi backendu zdefiniowanych w konfiguracjach TargetServer. Gdy 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 nie jest włą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 są wymagane żadne ponowne wdrożenia serwera proxy.

Monitor stanu działa jak 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ł prawidłowe żądanie HTTP do usługi backendu. Możesz zdefiniować operacje HTTP GET, PUT, POST lub DELETE. Odpowiedź wywołania monitora HTTP musi być zgodna z ustawieniami skonfigurowanymi w bloku <SuccessResponse>.

Sukcesy i niepowodzenia

Gdy włączysz monitorowanie stanu, Edge zacznie wysyłać sondy kontroli stanu do serwera docelowego. Kontrola stanu to żądanie wysyłane do serwera docelowego, które określa, czy serwer docelowy działa prawidłowo.

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 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 stanu HTTP 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ą.

  Gdy Edge stwierdzi, że serwer działa prawidłowo, 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 jest zgodna z oczekiwaną treścią.

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

Włączanie HealthMonitor

Aby utworzyć HealthMonitor, dodaj element <HealthMonitor> do konfiguracji HTTPConnection w elemencie TargetEndpoint 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 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 proxy interfejsu 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óra powoduje 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 sprawdza każdy TargetServer, otwierając połączenie na porcie 80. (Port jest opcjonalny. Jeśli nie określisz tu żadnej wartości, port TCPMonitor będzie taki sam jak port TargetServer).

• Jeśli połączenie nie powiedzie się lub trwa dłużej niż 10 sekund, licznik niepowodzeń dla tego serwera docelowego zwiększa się o 1.
• Jeśli połączenie się powiedzie, liczba nieudanych połączeń z TargetServerem 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. Poniższy przykład dodaje do wiadomości żądania nagłówek podstawowego uwierzytelniania HTTP. 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 o wartości YourOK. Jeśli odpowiedź nie pasuje, system równoważenia obciążenia uzna żądanie za nieudane.

HTTPMonitor 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ć konkretnej 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 opisano elementy konfiguracji HTTPMonitor: