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

Przeglądasz dokumentację Apigee Edge.
Przejdź do Dokumentacja Apigee X. informacje.

Apigee Edge zwiększa dostępność interfejsu API, zapewniając wbudowaną obsługę wczytywania zrównoważenie i przełączanie awaryjne między wieloma instancjami serwera backendu.

Konfiguracje serwera docelowego odłączając konkretne adresy URL punktów końcowych od punktu docelowego konfiguracji. Do każdego serwera docelowego odwołuje się nazwa w docelowym punkcie końcowym HTTPConnection. Zamiast definiować w konfiguracji konkretny adres URL, lub więcej nazwanych serwerów docelowych zgodnie z opisem w sekcji TargetEndpoint (Punkt końcowy).

Definicja serwera docelowego składa się z nazwy, hosta i portu oraz dodatkowego elementu wskazują, czy serwer docelowy jest włączony czy wyłączony.

Filmy

Obejrzyj te filmy, aby dowiedzieć się więcej o routingu i równoważeniu obciążenia interfejsu API za pomocą wartości docelowej serwery

Przykładowa konfiguracja serwera docelowego

Ten kod określa serwer docelowy:

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

Elementy konfiguracji serwera docelowego

W poniższej tabeli opisano elementy używane do tworzenia i konfigurowania serwera docelowego:

Zarządzanie serwerami docelowymi za pomocą interfejsu użytkownika

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. Dla: więcej informacji znajdziesz w sekcji TargetServers (Serwery docelowe).

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 poniższego wywołania interfejsu API, aby utworzyć drugi serwer docelowy. Definiując 2 serwery docelowe, 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" ]

Serwery docelowe API wdrożone w teście mogą teraz używać 2 serwerów docelowych dla środowiska. Aby równoważyć obciążenie ruchu między tymi serwerami docelowymi, skonfigurujesz w docelowym punkcie końcowym serwera proxy interfejsu API w celu użycia serwerów docelowych.

Obowiązuje limit 500 serwerów docelowych na środowisko, omówione w temacie Limity.

Konfigurowanie Docelowy punkt końcowy do równoważenia obciążenia na nazwanych serwerach docelowych

Gdy masz już dwa serwery docelowe, możesz zmodyfikować połączenia, aby móc odwoływać się do tych dwóch 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 to najbardziej podstawowa konfiguracja równoważenia obciążenia. Obciążenie System równoważenia obciążenia obsługuje 3 algorytmy równoważenia obciążenia: Round Robin, Ważony i Najmniej połączenia. Domyślny algorytm to system kołowy. W powyższej konfiguracji nie określono żadnego algorytmu, żądania wychodzące z serwera proxy interfejsu API do serwerów backendu będą naprzemienne, jedna za drugą, cel1 i cel 2.

Element <Path> tworzy ścieżkę bazową identyfikatora URI TargetEndpoint dla wszystkich serwerów docelowych. Jest używane tylko wtedy, gdy jest używana zasada <LoadBalancer>. W przeciwnym razie jest ignorowany. W powyższym przykładzie żądanie docierające do celu „target1” zostanie http://target1/test itd. w przypadku innych serwerów docelowych.

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

Dostępność możesz dostosować, używając opcji równoważenia obciążenia i przełączania awaryjnego podczas wczytywania na poziomie systemu systemu równoważenia obciążenia i serwera docelowego. W tej sekcji opisano te opcje.

Algorytm

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

Algorytm karuzelowy

Domyślny algorytm (rota robin) przekazuje żądanie do każdego serwera docelowego w kolejności które serwery są wymienione w połączeniu HTTP z docelowym punktem końcowym. 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 równoważenia obciążenia umożliwia skonfigurowanie proporcjonalnych obciążeń dla serwerów docelowych. Ważony system równoważenia obciążenia rozdziela żądanie na serwery docelowe bezpośrednio proporcjonalną do wagi każdego serwera docelowego. Dlatego algorytm ważony wymaga ustawienia atrybut 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 w przypadku każdego żądania przekierowanego do lokalizacji target2 2 żądania zostaną przekierowane do cel1.

Najmniejszy kontakt

Systemy równoważenia obciążenia skonfigurowane w taki sposób, aby używać jak najmniejszego algorytmu połączeń, kierują żądania wychodzące do Serwer docelowy 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 zakończyły się wynikiem gdy żądanie jest przekierowywane do innego serwera docelowego.

Błąd odpowiedzi oznacza, że Apigee nie otrzymuje odpowiedzi z serwera docelowego. Kiedy tak się dzieje, licznik błędów zwiększa się o 1.

Jednak gdy Apigee otrzyma odpowiedź od celu, nawet jeśli odpowiedź to błąd HTTP (np. 500), liczy się to jako odpowiedź z na serwerze docelowym, a licznik błędów zostanie zresetowany. Aby mieć pewność, że nieprawidłowe odpowiedzi HTTP (np. 500) zwiększa też licznik błędów, aby usunąć serwer w złym stanie. systemu równoważenia obciążenia możesz dodać parę klucz-wartość <ServerUnhealthyResponse> element z wartością <ResponseCode> elementów podrzędnych do konfiguracji systemu równoważenia obciążenia. Edge będzie też liczyć odpowiedzi z tymi jako błędów.

W poniższym przykładzie pole target1 zostanie usunięte z rotacji po 5. nieudanych żądań, w tym niektórych odpowiedzi 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 MaxFailures to 0. Oznacza to, że Edge zawsze próbuje nawiązywać połączenia z miejscem docelowym w przypadku każdego żądania i nigdy nie usuwa serwera docelowego z rotacji.

Najlepiej jest używać MaxFailures > 0 z HealthMonitor. Jeśli skonfigurujesz MaxFailures > 0, serwer docelowy zostanie usunięty z rotacji gdy cel nie powiedzie się we wskazanej przez Ciebie liczbie. Gdy HealthMonitor jest dostępny, Apigee automatycznie umieszcza Serwer docelowy z powrotem w rotacji po uruchomieniu środowiska docelowego zgodnie z konfigurację HealthMonitor. Zobacz Monitorowanie zdrowia .

Możesz też skonfigurować MaxFailures > 0, a Ty nie skonfigurujesz HealthMonitor, Apigee nie uwzględni ponownie serwera docelowego w rotacji automatycznie, gdy Apigee wykryje błąd. W tym przypadku musisz wdrożyć ponownie serwer proxy API, zanim Apigee umieści serwer docelowy z powrotem i rotacji. Zobacz Wdrażanie serwera proxy interfejsu API.

Spróbuj ponownie

Jeśli włączone jest ponawianie, żądanie będzie ponawiane w przypadku niepowodzenia odpowiedzi (błąd wejścia-wyjścia lub przekroczenia limitu czasu HTTP). lub otrzymana odpowiedź pasuje do wartości ustawionej przez <ServerUnhealthyResponse>. Więcej informacji o ustawianiu znajdziesz w sekcji Maksymalna liczba błędów powyżej. <ServerUnhealthyResponse>

Domyślnie <RetryEnabled> ma wartość true. Aby wyłączyć ponawianie próby, ustaw wartość false. Na przykład:

<RetryEnabled>false</RetryEnabled>

IsFallback

Jeden (i tylko jeden) serwer docelowy można ustawić jako serwer zastępczy serwera. Zastępczy serwer docelowy nie jest uwzględniany w procedurach równoważenia obciążenia, dopóki wszystkie inne serwery docelowe nie zostaną zidentyfikowane jako niedostępne przez system równoważenia obciążenia. Gdy system równoważenia obciążenia określi, że wszystkie serwery docelowe niedostępny, cały ruch jest kierowany na serwer zastępczy. 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 w modelu „round robin” między celami 1 i 2 do momentu oba cele 1 i 2 są niedostępne. Gdy cele 1 i 2 są niedostępne, cały ruch jest kierowany do kierowania reklam. 3.

Ścieżka

Ścieżka definiuje fragment identyfikatora URI, który będzie dołączany do wszystkich żądań wysyłanych przez serwer docelowy do serwera backendu.

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

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

Konfigurowanie serwera docelowego dla TLS/SSL

Jeśli do definiowania usługi backendu używasz serwera docelowego, a usługa backendu wymaga, aby połączenie korzystało z protokołu HTTPS, musisz włączyć TLS/SSL w Definicja serwera docelowego. Jest to konieczne, ponieważ tag <Host> nie pozwala Ci określ protokół połączenia. Poniżej znajduje się definicja serwera docelowego dla połączenia jednokierunkowego Protokół TLS/SSL, gdy 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 lub wzajemnego protokołu TLS/SSL, skonfigurujesz serwer docelowy przy użyciu tych samych ustawień konfiguracji TLS/SSL co w 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 na temat właściwości <SSLInfo>, takich jak: <Ciphers> i <ClientAuthEnabled>, zobacz Więcej informacji na temat konfigurowania tych właściwości dla hosta wirtualnego znajdziesz w artykule Konfigurowanie dostępu TLS do interfejsu API dla chmury Private Cloud.

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

Schemat serwera docelowego

Zobacz schemat serwera docelowego i innych encji w GitHub.

Monitorowanie zdrowia

Monitorowanie stanu umożliwia ulepszenie konfiguracji równoważenia obciążenia przez aktywne odpytywanie URL-e usługi backendu zdefiniowane w konfiguracjach serwera docelowego. Po włączeniu monitorowania stanu niesprawny serwer docelowy zostanie automatycznie przywrócony do rotacji po określeniu przez HealthMonitor że serwer docelowy jest aktywny.

Monitorowanie zdrowia współpracuje z aplikacją <MaxFailures>. Bez włączonego monitorowania stanu <MaxFailures> określa liczbę nieudanych żądań z serwera proxy interfejsu API do Serwer docelowy, który powoduje przekierowanie żądania do innego serwera docelowego. Awaria serwera docelowego zostanie wycofana z rotacji do czasu ponownego wdrożenia serwera proxy.

Gdy monitorowanie stanu jest włączone, uszkodzony serwer docelowy jest automatycznie przywrócony do rotacji bez serwera proxy ponownych wdrożeń są wymagane.

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

• Klient TCP po prostu zapewnia możliwość otwarcia gniazda.
• Konfigurujesz klienta HTTP tak, aby przesyłał prawidłowe żądanie HTTP do usługi backendu. Ty mogą zdefiniować operacje HTTP GET, PUT, POST i DELETE. Odpowiedź wywołania monitorowania HTTP musi być zgodna z skonfigurowane ustawienia w bloku <SuccessResponse>.

Czynności zakończone powodzeniem i niepowodzeniem

Gdy włączysz monitorowanie stanu, Edge rozpocznie wysyłanie kontroli stanu do środowiska docelowego. serwera. Kontrola stanu to żądanie wysyłane do serwera docelowego, które określa, czy czy serwer docelowy jest sprawny.

Kontrola stanu może przynieść jeden z dwóch wyników:

• Sukces: jeśli stan serwera docelowego przebiegnie pomyślnie, uznaje się, że serwer docelowy jest sprawny. Zazwyczaj jest to spowodowane co najmniej jednym z tych problemów:
  • Serwer docelowy akceptuje nowe połączenie z określonym portem, odpowiada na żądanie z tego portu, a następnie zamyka ten port w określonym przedziale czasu. Odpowiedź z serwera docelowego zawiera tekst „Connection: close” (Połączenie: zamknij)
  • Serwer docelowy odpowiada na żądanie kontroli stanu, wysyłając kod stanu 200 (OK) lub inny kod stanu HTTP, który uznajesz za akceptowalny.
  • Serwer docelowy odpowiada na żądanie kontroli stanu, wysyłając wiadomość, która jest zgodna z jej oczekiwaną treścią.

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

• Błąd:serwer docelowy może nie przejść kontroli stanu na różne sposoby, w zależności od typu weryfikacji. Niepowodzenie może być rejestrowane, gdy serwer docelowy:
  • Odmawia połączenia między Edge a portem kontroli stanu.
  • Nie odpowiada na żądanie kontroli stanu w określonym czasie.
  • Zwraca nieoczekiwany kod stanu HTTP.
  • Treść wiadomości jest niezgodna z jej oczekiwaną treścią.

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

Włączanie monitorowania stanu

Aby utworzyć HealthMonitor, dodaj element <HealthMonitor> do interfejsu HTTPConnection docelowego punktu końcowego dla serwera proxy. Nie można tego zrobić w interfejsie użytkownika. Zamiast tego musisz utworzyć konfigurację proxy przesłać do Edge jako plik ZIP. Konfiguracja serwera proxy to uporządkowany opis wszystkich aspektów serwera proxy API. Konfiguracje serwera proxy składają się z plików XML we wstępnie zdefiniowanej strukturze katalogów. Więcej informacje znajdziesz w sekcji Serwer proxy interfejsu API: Dokumentacja konfiguracji.

Prosty HealthMonitor definiuje IntervalInSec w połączeniu z TCPMonitor lub HTTPMonitor. Element <MaxFailures> określa maksimum liczba nieudanych żądań z serwera proxy interfejsu API do serwera docelowego, które zakończyły się wykonaniem żądania zostanie przekierowany do innego serwera docelowego. Domyślnie <MaxFailures> ma wartość 0, co oznacza, że Edge nie wykonuje żadnych działań naprawczych. Konfigurując monitor stanu, upewnij się, że ustawiono <MaxFailures> w: Tag <HTTPTargetConnection> tagu <TargetEndpoint> na wartość inną niż zero.

TCPMonitor

Poniższa konfiguracja definiuje HealthMonitor, który odpytuje każdy serwer docelowy, otwierając i połączenie z portem 80 co pięć sekund. (Port jest opcjonalny. Jeśli nie określono tego portu, port TCPMonitor to port serwera docelowego).

• Jeśli nie uda się nawiązać połączenia lub trwa ono dłużej niż 10 sekund, wtedy wyświetla się liczba niepowodzeń. zwiększa się o 1 dla danego serwera docelowego.
• Jeśli uda się nawiązać połączenie, liczba błędów serwera docelowego zostanie zresetowana do 0.

Możesz dodać HealthMonitor jako element potomny połączenia HTTPTargetEndpoint z docelowym punktem końcowym tak jak 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>
. . .

HealthMonitor z elementami konfiguracji TCPMonitor

W poniższej tabeli opisano elementy konfiguracji TCPMonitor:

HTTPMonitor

Przykładowy HealthMonitor, który korzysta z HTTPMonitor, prześle żądanie GET do backendu co pięć sekund. W przykładzie poniżej dodano nagłówek podstawowej autoryzacji HTTP do z prośbą o połączenie. Konfiguracja odpowiedzi definiuje ustawienia, które będą porównywane z rzeczywistymi ustawieniami z usługi backendu. W poniższym przykładzie oczekiwaną odpowiedzią jest HTTP kod odpowiedzi 200 i niestandardowy nagłówek HTTP ImOK, którego wartość to YourOK Jeśli odpowiedź nie będzie zgodna, żądanie zostanie potraktowane jako nieudane. przez konfigurację systemu równoważenia obciążenia.

HTTPMonitor obsługuje usługi backendu skonfigurowane pod kątem użycia HTTP i jednokierunkowego protokołu HTTPS protokoły API. Nie obsługuje on jednak:

• Dwukierunkowa protokół HTTPS (zwana też dwukierunkowym TLS/SSL),
• podpisane samodzielnie,

Pamiętaj, że wszystkie ustawienia żądań i odpowiedzi w monitorze HTTP będą specyficzne dla usługi backendu, którą trzeba wywołać.

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

HealthMonitor z elementami konfiguracji HTTPMonitor

W poniższej tabeli opisano elementy konfiguracji HTTPMonitor: