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 dzięki wbudowanej obsłudze równoważenia obciążenia i przełączania awaryjnego w wielu instancjach serwera zaplecza.

Konfiguracje serwera docelowego odłączają konkretne adresy URL punktów końcowych od konfiguracji punktu końcowego docelowego. Każdy serwer docelowy jest wskazywany po nazwie w ustawieniu TargetEndpoint w HTTPConnection. Zamiast definiowania konkretnego adresu URL w konfiguracji możesz skonfigurować co najmniej 1 nazwany serwer docelowy zgodnie z opisem w sekcji TargetEndpoint.

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

Filmy

Aby dowiedzieć się więcej o routingu interfejsu API i równoważeniu obciążenia za pomocą serwerów docelowych, obejrzyj te filmy

Wideo Opis
Równoważenie obciążenia za pomocą serwerów docelowych równoważenia obciążenia interfejsów API na serwerach docelowych.
Routing API na podstawie środowiska za pomocą serwerów docelowych Przekierowywanie interfejsu API do innego serwera docelowego w zależności od środowiska.
Routing API i równoważenie obciążenia za pomocą serwerów docelowych (Edge klasyczny) Przekierowywanie interfejsu API do innego serwera docelowego na podstawie środowiska i równoważenie obciążenia interfejsu API na serwerach docelowych w interfejsie klasycznego Edge.

Przykładowa konfiguracja serwera docelowego

Ten 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 opisano elementy używane do tworzenia i konfigurowania serwera docelowego:

Nazwa Opis Domyślny Wymagany?
name Nazwa konfiguracji serwera docelowego, która musi być niepowtarzalna w danym środowisku. Nazwa serwera docelowego może zawierać tylko znaki alfanumeryczne. Nie dotyczy Tak
Host

Adres URL hosta usługi backendu (bez protokołu).

Nie dotyczy Tak
Port Port, na którym nasłuchuje usługa backendu Nie dotyczy Tak
IsEnabled Wartość logiczna, która wskazuje, czy konfiguracja TargetServer jest włączona czy wyłączona. Dzięki temu możesz wyjąć serwery docelowe z rotacji bez modyfikowania konfiguracji serwera proxy interfejsu API. Typowym zastosowaniem jest napisanie aplikacji lub skryptu, który automatycznie włącza lub wyłącza TargetServers na podstawie oczekiwanych wymagań dotyczących przepustowości, harmonogramów konserwacji itp. true Tak

Zarządzanie serwerami docelowymi za pomocą interfejsu

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

Edge

Aby zarządzać serwerami docelowymi za pomocą interfejsu Edge:

  1. Zaloguj się na stronie apigee.com/edge.
  2. Na pasku nawigacyjnym po lewej stronie kliknij Administracja > Środowiska > Serwery docelowe.
  3. Wybierz odpowiednie środowisko, np. test lub produkcyjne.
  4. Aby utworzyć serwer docelowy:
    1. Kliknij + Serwer docelowy.
    2. Wpisz nazwę, hosta i port serwera docelowego.

      Na przykład:

      • Nazwa: target1
      • Host: 1.mybackendservice.com
      • Port: 80
    3. W razie potrzeby wybierz SSL (protokół SSL).
    4. Aby włączyć serwer docelowy, wybierz Włączono.
    5. Kliknij Dodaj.
  5. Aby edytować serwer docelowy:
    1. Umieść kursor na serwerze docelowym, który chcesz edytować, aby wyświetlić menu działań.
    2. Kliknij .
    3. Edytuj wartości serwera docelowego.
    4. Kliknij Aktualizuj.
  6. Aby usunąć serwer docelowy:
    1. Umieść kursor na serwerze docelowym, który chcesz usunąć, aby wyświetlić menu działań.
    2. Kliknij .
    3. Aby potwierdzić operację, kliknij Usuń.

Classic Edge (Private Cloud)

Aby uzyskać dostęp do kreatora tworzenia serwera proxy za pomocą interfejsu klasycznej wersji Edge:

  1. Zaloguj się na stronie http://ms-ip:9000, gdzie ms-ip to adres IP lub nazwa DNS węzła serwera zarządzania.
  2. Na pasku nawigacyjnym po lewej stronie kliknij Interfejsy API > Konfiguracja środowiska > Serwery docelowe.
  3. Wybierz odpowiednie środowisko, np. test lub produkcyjne.
  4. Aby utworzyć serwer docelowy:
    1. Kliknij Edytuj.
    2. Kliknij + Serwer docelowy.
    3. Wpisz nazwę, hosta i port serwera docelowego.

      Na przykład:

      • Nazwa: target1
      • Host: 1.mybackendservice.com
      • Port: 80
    4. Aby włączyć serwer docelowy, wybierz Włączono.
    5. Kliknij Zapisz.
  5. Aby edytować serwer docelowy:
    1. Kliknij Edytuj.
    2. Edytuj wartości serwera docelowego.
    3. Kliknij Zapisz.
  6. Aby usunąć serwer docelowy:
    1. Kliknij Edytuj.
    2. Kliknij Usuń.

Zarządzanie serwerami docelowymi za pomocą interfejsu API

Za pomocą interfejsu Edge API możesz tworzyć, usuwać, aktualizować, pobierać i wyświetlać listę serwerów docelowych. 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 obiektu TargetServer użyj tego wywołania interfejsu API, aby utworzyć drugi obiekt TargetServer. Definiując 2 usługi TargetServer, podajesz 2 adresy URL, których może używać punkt końcowy docelowy 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 danym ś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 dostępne są teraz 2 serwery docelowe, które mogą używać serwerów proxy API. Aby zrównoważyć obciążenie na tych serwerach docelowych, skonfiguruj połączenie HTTP w punkcie końcowym docelowym serwera proxy API, aby używać tych serwerów.

W każdym środowisku można ustawić maksymalnie 500 serwerów docelowych, zgodnie z opisem w artykule Limity.

Konfigurowanie obiektu końcowego docelowego do równoważenia obciążenia na nazwanych serwerach docelowych

Teraz, gdy masz dostępne 2 serwery docelowe, możesz zmodyfikować ustawienie połączenia HTTP serwera docelowego, aby odwoływać się do tych 2 serwerów docelowych po nazwie:

<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, Weighted i Least Connection. Algorytm losowy jest domyślnym algorytmem. Ponieważ w powyższej konfiguracji nie jest określone żadne algorytm, wychodzące żądania z serwera proxy interfejsu API do serwerów zaplecza będą się naprzemiennie kierować do target1 i target2.

Element <Path> tworzy ścieżkę podstawową identyfikatora URI miejsca docelowego dla wszystkich serwerów docelowych. Jest używany tylko wtedy, gdy używana jest funkcja <LoadBalancer>. W przeciwnym razie jest ignorowany. W przykładzie powyżej żądanie docierające do serwera „target1” będzie http://target1/test, tak samo w przypadku innych serwerów docelowych.

Konfigurowanie 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 serwera docelowego. W tej sekcji opisujemy te opcje.

Algorytm

Określa algorytm używany przez <LoadBalancer>. Dostępne algorytmy to RoundRobin, WeightedLeastConnections. Każdy z nich jest opisany poniżej.

Algorytm karuzelowy

Domyślny algorytm, czyli metoda okrężna, przekazuje żądanie do każdego serwera docelowego w kolejności, w jakiej serwery są wymienione w docelowym połączeniu HTTP. 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 zważonego równoważenia obciążenia umożliwia konfigurowanie proporcjonalnych obciążeń ruchu dla serwerów docelowych. Wagowy LoadBalancer rozprowadza żądania do serwerów docelowych w prostej proporcji do wagi każdego z nich. Dlatego algorytm ważonych wartości 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 wysłane do target1 będą wysyłane 2 żądania do target2.

Najmniejsze połączenie

Systemy równoważenia obciążenia skonfigurowane pod kątem korzystania z algorytmu najmniejszego obciążenia kierują wychodzące żądania do serwera docelowego 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 API do serwera TargetServer, które powodują przekierowanie żądania do innego serwera TargetServer.

Brak odpowiedzi oznacza, że Apigee nie otrzymuje żadnej odpowiedzi od serwera docelowego. W takim przypadku licznik niepowodzeń zwiększa się o 1.

Jeśli jednak Apigee otrzyma odpowiedź od celu, nawet jeśli jest to błąd HTTP (np. 500), zostanie ona uznana za odpowiedź od serwera docelowego, a licznik błędów zostanie zresetowany. Aby zapewnić, że złe odpowiedzi HTTP (takie jak 500) będą również zwiększać licznik niepowodzeń, aby jak najszybciej wykluczyć niesprawne serwery z rotacji równoważenia obciążenia, możesz dodać do konfiguracji systemu równoważenia obciążenia element <ServerUnhealthyResponse> z elementami podrzędnymi <ResponseCode>. Edge również liczy odpowiedzi z tymi kodami jako niepowodzenia.

W tym przykładzie usługa target1 zostanie usunięta z rotacji po 5 nieudanych żądaniach, w tym po otrzymaniu niektórych odpowiedzi 5XX od 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ść parametru MaxFailures to 0. Oznacza to, że Edge zawsze próbuje nawiązać połączenie z docelowym serwerem w przypadku każdego żądania i nigdy nie usuwa go z rotacji.

Najlepiej użyć parametru MaxFailures > 0 z HealthMonitor. Jeśli skonfigurujesz parametr MaxFailures > 0, serwer docelowy zostanie usunięty z rotacji, gdy wystąpi określona przez Ciebie liczba niepowodzeń. Gdy jest aktywny interfejs HealthMonitor, Apigee automatycznie umieszcza serwer docelowy z powrotem w rotacji po ponownym uruchomieniu celu zgodnie z konfiguracją interfejsu HealthMonitor. Więcej informacji znajdziesz w artykule Monitorowanie stanu.

Jeśli zdefiniujesz parametr MaxFailures > 0, ale nie skonfigurujesz monitora stanu, Apigee automatycznie wykluczy serwer docelowy z rotacji po wykryciu pierwszego błędu. Apigee będzie co 5 minut sprawdzać stan serwera docelowego i zwracać go do rotacji, gdy zacznie normalnie odpowiadać.

Spróbuj ponownie

Jeśli ponawianie prób jest włączone, żądanie zostanie powtórzone, gdy wystąpi błąd odpowiedzi (błąd we/wy lub przekroczenie limitu czasu HTTP) lub gdy otrzymana odpowiedź będzie pasować do wartości ustawionej przez <ServerUnhealthyResponse>. Więcej informacji o ustawieniu <ServerUnhealthyResponse> znajdziesz w sekcji Maksymalna liczba niepowodzeń.

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

<RetryEnabled>false</RetryEnabled>

IsFallback

Jako „serwer zapasowy” można ustawić jeden (i tylko jeden) serwer docelowy. Serwer docelowy zastępczy nie jest uwzględniany w rutynach równoważenia obciążenia, dopóki system równoważenia obciążenia nie zidentyfikuje wszystkich innych serwerów docelowych jako niedostępnych. 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>

W przypadku tej konfiguracji docel 1 i 2 są równomiernie obciążane do momentu, gdy obie te wartości staną się niedostępne. Gdy cele 1 i 2 są niedostępne, cały ruch jest kierowany do celu 3.

Ścieżka

Ścieżka definiuje fragment URI, który zostanie dołączony do wszystkich żądań wysyłanych przez serwer docelowy do serwera backendu.

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

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

Konfigurowanie serwera docelowego na potrzeby TLS/SSL

Jeśli do zdefiniowania usługi backendu używasz elementu TargetServer, a ta usługa wymaga korzystania 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 serwera docelowego w przypadku jednokierunkowego TLS/SSL, w którym Edge wysyła żądania HTTPS do usługi backendowej:

<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 TLS/SSL, skonfiguruj serwer docelowy, używając tych samych ustawień konfiguracji TLS/SSL co w przypadku punktów końcowych docelowych:

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

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

Pełne instrukcje konfigurowania wychodzącego TLS/SSL znajdziesz w artykule Konfigurowanie TLS na urządzeniach Edge do zaplecza (chmury publiczne i prywatne).

Schemat serwera docelowego

Schemat serwera docelowego i innych jednostek znajdziesz na GitHubie.

Monitorowanie stanu

Monitorowanie stanu umożliwia ulepszanie konfiguracji równoważenia obciążenia przez aktywne odpytywanie adresów URL usług backendu zdefiniowanych w konfiguracjach serwera docelowego. Gdy monitorowanie stanu jest włączone, awaria serwera docelowego powoduje automatyczne umieszczenie go z powrotem w rotacji, gdy HealthMonitor stwierdzi, że serwer docelowy jest aktywny.

Monitorowanie stanu działa z usługą <MaxFailures>. Bez włączonego monitorowania stanu: <MaxFailures> określa liczbę nieudanych żądań z serwera proxy interfejsu API do serwera TargetServer, które powodują przekierowanie żądania do innego serwera TargetServer. Serwer docelowy, który nie działa prawidłowo, jest wtedy wykluczany z rotacji, dopóki nie ponownie wdrożysz serwer proxy.

Gdy monitorowanie stanu jest włączone, serwer TargetServer, który przestał działać, jest automatycznie umieszczany z powrotem w rotacji i nie trzeba ponownie wdrażać serwerów proxy.

<MaxFailures>

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

  • Klient TCP po prostu zapewnia, że gniazdo może zostać otwarte.
  • Konfigurujesz klienta HTTP tak, aby przesyłał prawidłowe żądanie HTTP do usługi backendu. Możesz definiować 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ć sondy kontroli stanu do docelowego serwera. Kontrola stanu to żądanie wysłane do serwera docelowego, które określa, czy serwer docelowy działa prawidłowo.

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

  • Powodzenie: serwer docelowy jest uznawany za sprawny, gdy kontrola stanu zakończy się powodzeniem. Jest to zwykle spowodowane jednym lub kilkoma z tych czynników:
    • Serwer docelowy akceptuje nowe połączenie z wybranym portem, odpowiada na żądanie dotyczące tego portu, a następnie zamyka port w określonym czasie. Odpowiedź serwera docelowego zawiera „Connection: close” (Połączenie: close).
    • Serwer docelowy odpowiada na żądanie kontroli stanu kodem 200 (OK) lub innym kodem stanu HTTP, który uznasz za akceptowalny.
    • Serwer docelowy odpowiada na żądanie kontroli stanu, zwracając treść wiadomości zgodną z oczekiwaną treścią.

    Gdy Edge stwierdzi, że serwer działa prawidłowo, będzie nadal wysyłać do niego żądania.

  • Błąd: serwer docelowy może nie przejść kontroli stanu na różne sposoby w zależności od typu kontroli. 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;
    • Odpowiedź zawiera treść wiadomości, która nie jest zgodna z oczekiwaną treścią wiadomoś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 zdefiniowany limit (<MaxFailures>), przeglądarka Edge przestanie wysyłać do niego żądania.

Włączanie HealthMonitor

Aby utworzyć HealthMonitor, dodaj element <HealthMonitor> do konfiguracji HTTPConnection punktu końcowego docelowego dla serwera proxy. Nie możesz tego zrobić w interfejsie. Zamiast tego utwórz konfigurację serwera proxy i prześlij ją do przeglądarki Edge jako plik ZIP. Konfiguracja serwera proxy to ustrukturyzowany opis wszystkich aspektów serwera proxy interfejsu API. Konfiguracje serwera proxy składają się z plików XML w zdefiniowanej strukturze katalogów. Więcej informacji znajdziesz w artykule Referencje dotyczące konfiguracji interfejsu API Proxy.

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 TargetServer, które powodują przekierowanie żądania do innego serwera TargetServer. Domyślnie <MaxFailures> ma wartość 0, co oznacza, że Edge nie wykonuje żadnych działań naprawczych. Podczas konfigurowania monitora stanu upewnij się, że wartość parametru <MaxFailures> w tagu <HTTPTargetConnection> tagu <TargetEndpoint> ma wartość niezerową.

TCPMonitor

Konfiguracja poniżej definiuje HealthMonitor, który odpytuje każdy serwer docelowy, otwierając połączenie na porcie 80 co 5 sekund. (Port jest opcjonalny. Jeśli nie określisz tego ustawienia, port TCPMonitor będzie miał wartość portu serwera docelowego.

  • Jeśli połączenie się nie powiedzie lub jego ustanowienie zajmie więcej niż 10 sekund, liczba niepowodzeń dla serwera docelowego wzrośnie o 1.
  • Jeśli połączenie się powiedzie, liczba niepowodzeń dla serwera docelowego zostanie zresetowana do 0.

Możesz dodać HealthMonitor jako element podrzędny elementu HTTPTargetConnection obiektu 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>
. . .

HealthMonitor z elementami konfiguracji TCPMonitor

W tabeli poniżej opisano elementy konfiguracji TCPMonitor:

Nazwa Opis Domyślny Wymagany?
IsEnabled Wartość logiczna, która włącza lub wyłącza HealthMonitor. fałsz Nie
IntervalInSec Przedział czasu (w sekundach) między kolejnymi żądaniami TCP. 0 Tak
ConnectTimeoutInSec Czas, w którym musi zostać nawiązane połączenie z portem TCP, aby test został uznany za udany. Niemożność nawiązania połączenia w określonym zakresie czasu jest traktowana jako błąd i powoduje zwiększenie liczby błędów systemu równoważenia obciążenia dla serwera TargetServer. 0 Tak
Port Opcjonalnie: Port, na którym zostanie utworzone połączenie TCP. Jeśli nie określisz tego ustawienia, port TCPMonitor będzie miał wartość portu serwera docelowego. 0 Nie

HTTPMonitor

Przykładowa klasa HealthMonitor, która korzysta z klasy HTTPMonitor, co 5 sekund wysyła żądanie GET do usługi backendowej. Przykład poniżej dodaje do żądania nagłówek HTTP Basic Authorization. Konfiguracja odpowiedzi określa ustawienia, które zostaną porównane z rzeczywistą odpowiedzią z usługi backendu. W przykładzie poniżej oczekiwaną odpowiedzią jest kod odpowiedzi HTTP 200 i niestandardowy nagłówek HTTP ImOK o wartości YourOK. Jeśli odpowiedź nie pasuje, żądanie zostanie potraktowane jako nieudane przez konfigurację systemu równoważenia obciążenia.

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

  • dwukierunkowy HTTPS (zwany też dwukierunkowym TLS/SSL);
  • podpisane samodzielnie,

Pamiętaj, że wszystkie ustawienia żądania i odpowiedzi w monitorze HTTP będą specyficzne dla usługi backendu, którą należy 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 tabeli poniżej opisano elementy konfiguracji HTTPMonitor:

Nazwa Opis Domyślny Wymagany?
IsEnabled Wartość logiczna, która włącza lub wyłącza HealthMonitor. fałsz Nie
IntervalInSec Przedział czasu (w sekundach) między kolejnymi żądaniami sprawdzania. 0 Tak
Request

Opcje konfiguracji wiadomości z żądaniem wychodzącym wysyłanej przez HealthMonitor do serwerów docelowych w ramach rotacji.

Ścieżka nie obsługuje zmiennych.

Nie dotyczy Tak
IsSSL Określa, czy do monitorowania połączeń ma być używany protokół HTTPS (zabezpieczony HTTP).

Możliwe wartości:
  • true: używany jest protokół HTTPs.
  • false: używany jest protokół HTTP.
  • Nieokreślony: używa konfiguracji serwera docelowego.
fałsz Nie
ConnectTimeoutInSec Czas w sekundach, w którym inicjacja połączenia TCP z usługą HTTP musi zostać ukończona, aby została uznana za udaną. Niemożność nawiązania połączenia w określonym przedziale czasu jest traktowana jako błąd i powoduje zwiększenie liczby błędów LoadBalancera dla serwera TargetServer. 0 Nie
SocketReadTimeoutInSec Czas (w sekundach), w którym dane muszą zostać odczytane z usługi HTTP, aby uznać to za sukces. Niemożność odczytania w określonym przedziale czasu jest traktowana jako błąd i powoduje zwiększenie liczby błędów LoadBalancera dla serwera docelowego. 0 Nie
Port Port, na którym zostanie nawiązane połączenie HTTP z usługą backendu. Nie dotyczy Nie
Verb Słowo kluczowe HTTP używane w przypadku każdego żądania HTTP do usługi backendowej . Nie dotyczy Nie
Path Ścieżka dodana do adresu URL zdefiniowanego w ustawieniu TargetServer. Użyj elementu ścieżki, aby skonfigurować „punkt końcowy sprawdzania” w usłudze HTTP. Nie dotyczy Nie

IncludeHealthCheckIdHeader

Umożliwia śledzenie żądań kontroli stanu w systemach nadrzędnych. Argument IncludeHealthCheckIdHeader przyjmuje wartość logiczną i domyślnie ma wartość false. Jeśli ustawisz wartość true, w żądaniu kontroli stanu zostanie wstrzyknięty Header o nazwie X-Apigee-Healthcheck-Id. Wartość nagłówka jest przypisywana dynamicznie i ma postać ORG/ENV/SERVER_UUID/N, gdzie ORG to nazwa organizacji, ENV to nazwa środowiska, SERVER_UUID to unikalny identyfikator identyfikujący MP, a N to liczba milisekund od 1 stycznia 1970 r.

Przykład nagłówka żądania:

X-Apigee-Healthcheck-Id: orgname/envname/E8C4D2EE-3A69-428A-8616-030ABDE864E0/1586802968123
fałsz Nie
Payload Treść HTTP wygenerowana dla każdego żądania HTTP sondowania. Pamiętaj, że ten element nie jest wymagany w przypadku żądań GET. Nie dotyczy Nie
SuccessResponse Opcje dopasowania dla przychodzącej wiadomości odpowiedzi HTTP wygenerowanej przez ankietowaną usługę backendową. Odpowiedzi, które nie pasują, zwiększają liczbę niepowodzeń o 1. Nie dotyczy Nie
ResponseCode Kod odpowiedzi HTTP oczekiwany od serwera docelowego. Kod inny niż podany spowoduje niepowodzenie i zwiększenie liczby dla usługi backendowej, z którą przeprowadzono sondę. Możesz zdefiniować większą liczbę elementów ResponseCode. Nie dotyczy Nie
Headers Lista co najmniej 1 nagłówka i wartości HTTP, które mają zostać odebrane od ankietowanego backendu. Wszelkie nagłówki lub wartości HTTP w odpowiedzi, które różnią się od podanych, powodują niepowodzenie, a liczba serwerów docelowych, których dotyczyło zapytanie, wzrasta o 1. Możesz zdefiniować wiele elementów nagłówka. Nie dotyczy Nie