Балансировка нагрузки между внутренними серверами

Вы просматриваете документацию Apigee Edge .
Перейдите к документации Apigee X. информация

Apigee Edge повышает доступность вашего API, предоставляя встроенную поддержку балансировки нагрузки и аварийного переключения на нескольких экземплярах внутреннего сервера.

Конфигурации TargetServer отделяют конкретные URL-адреса конечных точек от конфигураций TargetEndpoint. На каждый TargetServer ссылаются по имени в TargetEndpoint HTTPConnection. Вместо определения конкретного URL-адреса в конфигурации вы можете настроить один или несколько именованных TargetServers, как описано в разделе TargetEndpoint .

Определение TargetServer состоит из имени, хоста и порта, а также дополнительного элемента, указывающего, включен или отключен TargetServer.

Видео

Посмотрите следующие видеоролики, чтобы узнать больше о маршрутизации API и балансировке нагрузки с помощью целевых серверов.

Пример конфигурации TargetServer

Следующий код определяет целевой сервер:

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

Элементы конфигурации TargetServer

В следующей таблице описаны элементы, используемые для создания и настройки TargetServer:

Управление целевыми серверами с помощью пользовательского интерфейса

Управляйте целевыми серверами, как описано ниже.

Управление целевыми серверами с помощью API

Вы можете использовать Edge API для создания, удаления, обновления, получения и составления списка целевых серверов. Дополнительные сведения см. в разделе TargetServers .

Используйте следующий вызов 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

Пример ответа:

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

После создания первого TargetServer используйте следующий вызов API для создания второго TargetServer. Определив два TargetServer, вы предоставляете два URL-адреса, которые TargetEndpoint может использовать для балансировки нагрузки:

$ 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

Пример ответа:

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

Используйте следующий вызов API для получения списка TargetServers в среде:

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

Пример ответа:

[ "target2", "target1" ]

Теперь есть два TargetServer, доступных для использования прокси-серверами API, развернутыми в тестовой среде. Чтобы сбалансировать нагрузку трафика между этими TargetServers, вы настраиваете HTTP-соединение в целевой конечной точке прокси-сервера API для использования TargetServers.

Существует ограничение в 500 целевых серверов на среду, как описано в разделе «Ограничения» .

Настройка TargetEndpoint для балансировки нагрузки между именованными серверами TargetServers

Теперь, когда у вас есть два доступных сервера TargetServer, вы можете изменить настройку HTTP-соединения TargetEndpoint, чтобы ссылаться на эти два сервера TargetServer по имени:

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

Приведенная выше конфигурация является самой базовой возможной конфигурацией балансировки нагрузки. Балансировщик нагрузки поддерживает три алгоритма балансировки нагрузки: Round Robin, Weighted и Least Connection. Round Robin — алгоритм по умолчанию. Поскольку в приведенной выше конфигурации не указан алгоритм, исходящие запросы от прокси-сервера API к внутренним серверам будут чередоваться один за другим между целью 1 и целью 2.

Элемент <Path> формирует базовый путь URI TargetEndpoint для всех целевых серверов. Он используется только при использовании <LoadBalancer> . В противном случае оно игнорируется. В приведенном выше примере запрос, доходящий до «target1», будет http://target1/test , как и для других целевых серверов.

Настройка параметров балансировщика нагрузки

Вы можете настроить доступность, используя параметры балансировки нагрузки и аварийного переключения на уровне балансировщика нагрузки и TargetServer. В этом разделе описаны эти параметры.

Алгоритм

Устанавливает алгоритм, используемый <LoadBalancer> . Доступные алгоритмы: RoundRobin , Weighted и LeastConnections , каждый из которых описан ниже.

Круговая система

Алгоритм по умолчанию, циклический пересыл, перенаправляет запрос на каждый TargetServer в том порядке, в котором серверы перечислены в HTTP-соединении целевой конечной точки. Например:

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

Взвешенный

Алгоритм взвешенной балансировки нагрузки позволяет вам настроить пропорциональную нагрузку трафика для ваших целевых серверов. Взвешенный LoadBalancer распределяет запросы по вашим TargetServer прямо пропорционально весу каждого TargetServer. Таким образом, взвешенный алгоритм требует, чтобы вы установили атрибут weight для каждого TargetServer. Например:

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

В этом примере два запроса будут направлены на цель 2 на каждый запрос, направленный на цель 1.

Наименьшее соединение

Балансировщики нагрузки, настроенные на использование алгоритма наименьшего количества подключений, направляют исходящие запросы на TargetServer с наименьшим количеством открытых HTTP-соединений. Например:

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

Максимум отказов

Максимальное количество неудачных запросов от прокси-сервера API к TargetServer, в результате которых запрос перенаправляется на другой TargetServer.

Ошибка ответа означает, что Apigee не получает ответа от целевого сервера. Когда это происходит, счетчик ошибок увеличивается на единицу.

Однако когда Apigee получает ответ от целевого сервера, даже если ответ представляет собой ошибку HTTP (например, 500 ), это считается ответом от целевого сервера, и счетчик ошибок сбрасывается. Чтобы гарантировать, что плохие ответы HTTP (например, 500 ) также увеличивают счетчик ошибок, чтобы как можно скорее вывести неработоспособный сервер из ротации балансировки нагрузки, вы можете добавить элемент <ServerUnhealthyResponse> с дочерними элементами <ResponseCode> в конфигурацию балансировщика нагрузки. Edge также будет считать ответы с этими кодами неудачными.

В следующем примере target1 будет удален из ротации после пяти неудачных запросов, включая несколько ответов 5XX от целевого сервера.

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

Значение по умолчанию MaxFailures равно 0. Это означает, что Edge всегда пытается подключиться к цели для каждого запроса и никогда не удаляет целевой сервер из ротации.

Лучше всего использовать MaxFailures > 0 с HealthMonitor. Если вы настроите MaxFailures > 0, TargetServer будет удален из ротации, когда целевой объект выйдет из строя указанное вами количество раз. Когда HealthMonitor установлен, Apigee автоматически возвращает TargetServer в ротацию после того, как целевой объект снова запускается и работает, в соответствии с конфигурацией этого HealthMonitor. Дополнительную информацию см. в разделе Мониторинг состояния .

Альтернативно, если вы настроите MaxFailures > 0 и не настроите монитор работоспособности, Apigee автоматически выведет целевой сервер из ротации при обнаружении первого сбоя. Apigee будет проверять работоспособность целевого сервера каждые пять минут и возвращать его в ротацию, когда он отвечает нормально.

Повторить попытку

Если повторная попытка включена, запрос будет повторяться всякий раз, когда происходит сбой ответа (ошибка ввода-вывода или тайм-аут HTTP) или полученный ответ соответствует значению, установленному <ServerUnhealthyResponse> . Дополнительные сведения о настройке <ServerUnhealthyResponse> см. выше в разделе «Максимальное количество ошибок» .

По умолчанию для <RetryEnabled> установлено значение true . Установите значение false чтобы отключить повторную попытку. Например:

<RetryEnabled>false</RetryEnabled>

IsFallback

Один (и только один) TargetServer может быть установлен в качестве «резервного» сервера. Резервный TargetServer не включается в процедуры балансировки нагрузки до тех пор, пока все остальные TargetServer не будут определены балансировщиком нагрузки как недоступные. Когда балансировщик нагрузки определяет, что все TargetServer недоступны, весь трафик направляется на резервный сервер. Например:

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

Приведенная выше конфигурация приводит к циклическому балансированию нагрузки между целями 1 и 2 до тех пор, пока обе цели 1 и 2 не станут недоступны. Когда цели 1 и 2 недоступны, весь трафик направляется на цель 3.

Путь

Path определяет фрагмент URI, который будет добавляться ко всем запросам, отправляемым TargetServer к внутреннему серверу.

Этот элемент принимает буквальный строковый путь или шаблон сообщения . Шаблон сообщения позволяет выполнять замену строк переменных во время выполнения. Например, в следующем определении целевой конечной точки в качестве пути используется значение {mypath} :

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

Настройка целевого сервера для TLS/SSL

Если вы используете TargetServer для определения внутренней службы, а серверная служба требует подключения для использования протокола HTTPS, вам необходимо включить TLS/SSL в определении TargetServer. Это необходимо, поскольку тег <Host> не позволяет указать протокол подключения. Ниже показано определение TargetServer для одностороннего TLS/SSL, где Edge отправляет HTTPS-запросы к внутренней службе:

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

Если серверной службе требуется двусторонний или взаимный TLS/SSL, вы настраиваете TargetServer, используя те же параметры конфигурации TLS/SSL, что и 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 >

Информацию о свойствах <SSLInfo> , таких как <Ciphers> и <ClientAuthEnabled> , см. в информации о настройке этих свойств для виртуального хоста в разделе Настройка доступа TLS к API для частного облака .

Полные инструкции по настройке исходящего TLS/SSL см. в разделе Настройка TLS от Edge к серверной части (облако и частное облако) .

Схема таргетсервера

См. схему TargetServer и других сущностей на GitHub .

Мониторинг здоровья

Мониторинг работоспособности позволяет улучшить конфигурации балансировки нагрузки путем активного опроса URL-адресов серверных служб, определенных в конфигурациях TargetServer. При включенном мониторинге работоспособности вышедший из строя TargetServer автоматически возвращается в ротацию, когда HealthMonitor определяет, что TargetServer активен.

Мониторинг работоспособности работает с <MaxFailures> . Если мониторинг работоспособности не включен, <MaxFailures> указывает количество неудачных запросов от прокси-сервера API к TargetServer, в результате которых запрос перенаправляется на другой TargetServer. Неисправный TargetServer выводится из ротации до тех пор, пока вы не повторно развернете прокси.

При включенном мониторинге работоспособности вышедший из строя TargetServer автоматически возвращается в ротацию, и повторное развертывание прокси-сервера не требуется.

HealthMonitor действует как простой клиент, который вызывает серверную службу через TCP или HTTP:

• TCP-клиент просто гарантирует, что сокет может быть открыт.
• Вы настраиваете HTTP-клиент для отправки действительного HTTP-запроса внутренней службе. Вы можете определить операции HTTP GET, PUT, POST или DELETE. Ответ на вызов HTTP-монитора должен соответствовать настройкам, настроенным в блоке <SuccessResponse> .

Успехи и неудачи

Когда вы включаете мониторинг работоспособности, Edge начинает отправлять проверки работоспособности на ваш целевой сервер. Проверка работоспособности — это запрос, отправляемый на целевой сервер, который определяет, работоспособен ли целевой сервер или нет.

Проверка работоспособности может иметь один из двух возможных результатов:

• Успех: целевой сервер считается исправным, если происходит успешная проверка работоспособности. Обычно это является результатом одного или нескольких из следующих событий:
  • Целевой сервер принимает новое соединение с указанным портом, отвечает на запрос этого порта, а затем закрывает порт в течение указанного периода времени. Ответ от целевого сервера содержит «Соединение: закрыть».
  • Целевой сервер отвечает на запрос проверки работоспособности кодом 200 (ОК) или другим кодом состояния HTTP, который вы считаете приемлемым.
  • Целевой сервер отвечает на запрос проверки работоспособности телом сообщения, соответствующим ожидаемому телу сообщения.

  Когда Edge определяет, что сервер исправен, Edge продолжает или возобновляет отправку ему запросов.

• Сбой. Целевой сервер может не пройти проверку работоспособности по-разному, в зависимости от типа проверки. Сбой может быть зарегистрирован, когда целевой сервер:
  • Отказывает в соединении Edge с портом проверки работоспособности.
  • Не отвечает на запрос проверки работоспособности в течение определенного периода времени.
  • Возвращает неожиданный код состояния HTTP.
  • Отвечает телом сообщения, которое не соответствует ожидаемому телу сообщения.

  Если целевой сервер не проходит проверку работоспособности, Edge увеличивает счетчик ошибок этого сервера. Если количество сбоев на этом сервере соответствует или превышает заранее определенный порог ( <MaxFailures> ), Edge прекращает отправку запросов на этот сервер.

Включение HealthMonitor

Чтобы создать HealthMonitor, вы добавляете элемент <HealthMonitor> в конфигурацию HTTPConnection TargetEndpoint для прокси-сервера. Вы не можете сделать это в пользовательском интерфейсе. Вместо этого вы создаете конфигурацию прокси-сервера и загружаете ее в виде ZIP-файла в Edge. Конфигурация прокси — это структурированное описание всех аспектов прокси API. Конфигурации прокси-сервера состоят из XML-файлов в заранее определенной структуре каталогов. Для получения дополнительной информации см. Справочник по настройке прокси-сервера API .

Простой HealthMonitor определяет IntervalInSec в сочетании с TCPMonitor или HTTPMonitor. Элемент <MaxFailures> указывает максимальное количество неудачных запросов от прокси-сервера API к TargetServer, в результате которых запрос перенаправляется на другой TargetServer. По умолчанию <MaxFailures> равно 0, что означает, что Edge не выполняет корректирующих действий. При настройке монитора работоспособности убедитесь, что для <MaxFailures> в теге <HTTPTargetConnection> тега <TargetEndpoint> установлено ненулевое значение.

TCPMonitor

В приведенной ниже конфигурации определяется HealthMonitor, который опрашивает каждый TargetServer, открывая соединение через порт 80 каждые пять секунд. (Порт не является обязательным. Если он не указан, порт TCPMonitor является портом TargetServer.)

• Если соединение не установлено или для подключения требуется более 10 секунд, то счетчик неудач увеличивается на 1 для этого TargetServer.
• Если соединение установлено успешно, счетчик неудач для TargetServer сбрасывается до 0.

Вы можете добавить HealthMonitor в качестве дочернего элемента элемента HTTPTargetConnetion TargetEndpoint, как показано ниже:

<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 с элементами конфигурации TCPMonitor

В следующей таблице описаны элементы конфигурации TCPMonitor:

HTTPMonitor

Пример HealthMonitor, использующий HTTPMonitor, будет отправлять запрос GET серверной службе каждые пять секунд. В приведенном ниже примере к сообщению запроса добавляется заголовок базовой авторизации HTTP. Конфигурация ответа определяет параметры, которые будут сравниваться с фактическим ответом внутренней службы. В приведенном ниже примере ожидаемым ответом является код ответа HTTP 200 и пользовательский HTTP-заголовок ImOK со значением YourOK . Если ответ не совпадает, запрос будет рассматриваться как сбой в конфигурации балансировщика нагрузки.

HTTPMonitor поддерживает серверные службы, настроенные на использование протоколов HTTP и одностороннего HTTPS. Однако он не поддерживает следующее:

• Двусторонний HTTPS (также называемый двусторонним TLS/SSL)
• Самоподписанные сертификаты.

Обратите внимание, что все параметры запроса и ответа в HTTP-мониторе будут зависеть от внутренней службы, которую необходимо вызвать.

    <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 с элементами конфигурации HTTPMonitor

В следующей таблице описаны элементы конфигурации HTTPMonitor:

Вы просматриваете документацию Apigee Edge .
Перейдите к документации Apigee X. информация

Apigee Edge повышает доступность вашего API, предоставляя встроенную поддержку балансировки нагрузки и аварийного переключения на нескольких экземплярах внутреннего сервера.

Конфигурации TargetServer отделяют конкретные URL-адреса конечных точек от конфигураций TargetEndpoint. На каждый TargetServer ссылаются по имени в TargetEndpoint HTTPConnection. Вместо определения конкретного URL-адреса в конфигурации вы можете настроить один или несколько именованных TargetServers, как описано в разделе TargetEndpoint .

Определение TargetServer состоит из имени, хоста и порта, а также дополнительного элемента, указывающего, включен или отключен TargetServer.

Видео

Посмотрите следующие видеоролики, чтобы узнать больше о маршрутизации API и балансировке нагрузки с помощью целевых серверов.

Пример конфигурации TargetServer

Следующий код определяет целевой сервер:

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

Элементы конфигурации TargetServer

В следующей таблице описаны элементы, используемые для создания и настройки TargetServer:

Управление целевыми серверами с помощью пользовательского интерфейса

Управляйте целевыми серверами, как описано ниже.

Управление целевыми серверами с помощью API

Вы можете использовать Edge API для создания, удаления, обновления, получения и составления списка целевых серверов. Дополнительные сведения см. в разделе TargetServers .

Используйте следующий вызов 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

Пример ответа:

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

После создания первого TargetServer используйте следующий вызов API для создания второго TargetServer. Определив два TargetServer, вы предоставляете два URL-адреса, которые TargetEndpoint может использовать для балансировки нагрузки:

$ 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

Пример ответа:

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

Используйте следующий вызов API, чтобы получить список TargetServers в среде:

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

Пример ответа:

[ "target2", "target1" ]

Теперь есть два TargetServer, доступных для использования прокси-серверами API, развернутыми в тестовой среде. Чтобы сбалансировать нагрузку трафика между этими TargetServers, вы настраиваете HTTP-соединение в целевой конечной точке прокси-сервера API для использования TargetServers.

Существует ограничение в 500 целевых серверов на среду, как описано в разделе «Ограничения» .

Настройка TargetEndpoint для балансировки нагрузки между именованными серверами TargetServers

Теперь, когда у вас есть два доступных TargetServer, вы можете изменить настройку HTTP-соединения TargetEndpoint, чтобы ссылаться на эти два TargetServer по имени:

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

Приведенная выше конфигурация является самой простой возможной конфигурацией балансировки нагрузки. Балансировщик нагрузки поддерживает три алгоритма балансировки нагрузки: Round Robin, Weighted и Least Connection. Round Robin — алгоритм по умолчанию. Поскольку в приведенной выше конфигурации не указан алгоритм, исходящие запросы от прокси-сервера API к внутренним серверам будут чередоваться один за другим между целью 1 и целью 2.

Элемент <Path> формирует базовый путь URI TargetEndpoint для всех целевых серверов. Он используется только при использовании <LoadBalancer> . В противном случае оно игнорируется. В приведенном выше примере запрос, доходящий до «target1», будет http://target1/test , как и для других целевых серверов.

Настройка параметров балансировщика нагрузки

Вы можете настроить доступность, используя параметры балансировки нагрузки и аварийного переключения на уровне балансировщика нагрузки и TargetServer. В этом разделе описаны эти параметры.

Алгоритм

Устанавливает алгоритм, используемый <LoadBalancer> . Доступные алгоритмы: RoundRobin , Weighted и LeastConnections , каждый из которых описан ниже.

Круговая система

Алгоритм по умолчанию, циклический пересыл, перенаправляет запрос на каждый TargetServer в том порядке, в котором серверы перечислены в HTTP-соединении целевой конечной точки. Например:

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

Взвешенный

Алгоритм взвешенной балансировки нагрузки позволяет вам настроить пропорциональную нагрузку трафика для ваших целевых серверов. Взвешенный LoadBalancer распределяет запросы по вашим TargetServer прямо пропорционально весу каждого TargetServer. Таким образом, взвешенный алгоритм требует, чтобы вы установили атрибут weight для каждого TargetServer. Например:

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

В этом примере два запроса будут направлены на цель 2 на каждый запрос, направленный на цель 1.

Наименьшее соединение

Балансировщики нагрузки, настроенные на использование алгоритма наименьшего количества подключений, направляют исходящие запросы на TargetServer с наименьшим количеством открытых HTTP-соединений. Например:

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

Максимум отказов

Максимальное количество неудачных запросов от прокси-сервера API к TargetServer, в результате которых запрос перенаправляется на другой TargetServer.

Ошибка ответа означает, что Apigee не получает ответа от целевого сервера. Когда это происходит, счетчик ошибок увеличивается на единицу.

Однако когда Apigee получает ответ от целевого сервера, даже если ответ представляет собой ошибку HTTP (например, 500 ), это считается ответом от целевого сервера, и счетчик ошибок сбрасывается. Чтобы гарантировать, что плохие ответы HTTP (например, 500 ) также увеличивают счетчик ошибок, чтобы как можно скорее вывести неработоспособный сервер из ротации балансировки нагрузки, вы можете добавить элемент <ServerUnhealthyResponse> с дочерними элементами <ResponseCode> в конфигурацию балансировщика нагрузки. Edge также будет считать ответы с этими кодами неудачными.

В следующем примере target1 будет удален из ротации после пяти неудачных запросов, включая несколько ответов 5XX от целевого сервера.

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

Значение по умолчанию MaxFailures равно 0. Это означает, что Edge всегда пытается подключиться к цели для каждого запроса и никогда не удаляет целевой сервер из ротации.

Лучше всего использовать MaxFailures > 0 с HealthMonitor. Если вы настроите MaxFailures > 0, TargetServer будет удален из ротации, когда целевой объект выйдет из строя указанное вами количество раз. Когда HealthMonitor установлен, Apigee автоматически возвращает TargetServer в ротацию после того, как целевой объект снова запускается и работает, в соответствии с конфигурацией этого HealthMonitor. Дополнительную информацию см. в разделе Мониторинг работоспособности .

Альтернативно, если вы настроите MaxFailures > 0 и не настроите монитор работоспособности, Apigee автоматически выведет целевой сервер из ротации при обнаружении первого сбоя. Apigee будет проверять работоспособность целевого сервера каждые пять минут и возвращать его в ротацию, когда он отвечает нормально.

Повторить попытку

Если повторная попытка включена, запрос будет повторяться всякий раз, когда происходит сбой ответа (ошибка ввода-вывода или тайм-аут HTTP) или полученный ответ соответствует значению, установленному <ServerUnhealthyResponse> . Дополнительные сведения о настройке <ServerUnhealthyResponse> см. выше в разделе «Максимальное количество ошибок» .

По умолчанию для <RetryEnabled> установлено значение true . Установите значение false чтобы отключить повторную попытку. Например:

<RetryEnabled>false</RetryEnabled>

IsFallback

Один (и только один) TargetServer может быть установлен в качестве «резервного» сервера. Резервный TargetServer не включается в процедуры балансировки нагрузки до тех пор, пока все остальные TargetServer не будут определены балансировщиком нагрузки как недоступные. Когда балансировщик нагрузки определяет, что все TargetServer недоступны, весь трафик направляется на резервный сервер. Например:

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

Приведенная выше конфигурация приводит к циклическому балансированию нагрузки между целями 1 и 2 до тех пор, пока обе цели 1 и 2 не станут недоступны. Когда цели 1 и 2 недоступны, весь трафик направляется на цель 3.

Путь

Path определяет фрагмент URI, который будет добавляться ко всем запросам, отправляемым TargetServer к внутреннему серверу.

Этот элемент принимает буквальный строковый путь или шаблон сообщения . Шаблон сообщения позволяет выполнять замену строк переменных во время выполнения. Например, в следующем определении целевой конечной точки в качестве пути используется значение {mypath} :

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

Настройка целевого сервера для TLS/SSL

Если вы используете TargetServer для определения бэкэнд -службы, а сервис Backend требует, чтобы соединение использовало протокол HTTPS, то вы должны включить TLS/SSL в определении TargetServer. Это необходимо, потому что тег <Host> не позволяет вам указать протокол соединения. Ниже показано определение TargetServer для одностороннего TLS/SSL, где Edge делает HTTPS-запросы в сервис бэкэнд:

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

Если сервис Backend требует двусторонней или взаимной, TLS/SSL, то вы настраиваете TargetServer, используя те же настройки конфигурации TLS/SSL, что и 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 >

Для получения информации о свойствах <SSLInfo> , таких как <Ciphers> и <ClientAuthEnabled> , см. Информацию о настройке этих свойств для виртуального хоста при настройке доступа TLS к API для частного облака .

Для получения полных инструкций по настройке исходящего TLS/SSL см . Настройку TLS от Edge на бэкэнд (облако и частное облако) .

Целевая схема

Смотрите схему для TargetServer и других сущностей на GitHub .

Мониторинг здоровья

Мониторинг здоровья позволяет вам улучшить конфигурации балансировки нагрузки путем активного опроса URL -адресов сервисного обслуживания, определенных в конфигурациях TargetServer. При включении мониторинга здоровья, неудачный целевой сервер автоматически возвращается в вращение, когда HealthMonitor определяет, что целевой сервер активен.

Мониторинг здоровья работает с <MaxFailures> . Без включения мониторинга здоровья <MaxFailures> указывает количество неудачных запросов от прокси -сервера API на TargetServer, что приводит к перенаправлению запроса на другой целевой сервер. Затем сборочный целевой сервер выносится из вращения, пока вы не переплютно разверните прокси.

При включении мониторинга здоровья, неудачный целевой сервер автоматически возвращается в вращение, и повторные развертывания прокси не требуется.

Healthmonitor действует как простой клиент, который вызывает сервис по сравнению с TCP или HTTP:

• Клиент TCP просто гарантирует, что может быть открыт розетка.
• Вы настраиваете клиент HTTP, чтобы отправить действительный HTTP -запрос в сервис Backend. Вы можете определить HTTP GET, поставить, публиковать или удалять операции. Ответ вызова HTTP Monitor должен соответствовать настроенным параметрам в блоке <SuccessResponse> .

Успехи и неудачи

Когда вы включаете мониторинг здоровья, Edge начинает отправлять медицинские чеки на ваш целевой сервер. Проверка здоровья - это запрос, отправленный на целевой сервер, который определяет, является ли целевой сервер здоровым или нет.

Проверка здоровья может иметь один из двух возможных результатов:

• Успех: целевой сервер считается здоровым, когда происходит успешная проверка здоровья. Как правило, это результат одного или нескольких из следующих:
  • Target Server принимает новое подключение к указанному порту, отвечает на запрос на этом порту, а затем закрывает порт в указанный период времени. Ответ с целевого сервера содержит «соединение: закрыть»
  • Целевой сервер реагирует на запрос на проверку здоровья с помощью 200 (OK) или другого кода состояния HTTP, который вы определяете, является приемлемым.
  • Целевой сервер реагирует на запрос на проверку здоровья с помощью корпуса сообщений, который соответствует ожидаемому корпусу сообщений.

  Когда Edge определяет, что сервер является здоровым, Edge продолжается или возобновляет отправку запросов на него.

• Отказ: целевой сервер может по -разному проверять здоровье, в зависимости от типа проверки. Отказ может быть зарегистрирован при целевом сервере:
  • Отказывается от подключения от края к порту проверки здоровья.
  • Не отвечает на запрос на проверку здоровья в течение определенного периода времени.
  • Возвращает неожиданный код состояния HTTP.
  • Отвечает органом сообщений, который не соответствует ожидаемому телу сообщений.

  Когда целевой сервер не проходит проверку здоровья, преимущество увеличивает количество сбоев сервера. Если количество сбоев для этого сервера соответствует или превышает предопределенный порог ( <MaxFailures> ), Edge прекращает отправку запросов на этот сервер.

Включение HealthMonitor

Чтобы создать HealthMonitor, вы добавляете элемент <HealthMonitor> в конфигурацию HTTPConnection TargetEndPoint для прокси. Вы не можете сделать это в пользовательском интерфейсе. Вместо этого вы создаете конфигурацию прокси и загружаете ее в виде zip -файла в Edge. Конфигурация прокси - это структурированное описание всех аспектов прокси API. Конфигурации прокси состоят из XML-файлов в предварительно определенной структуре каталога. Для получения дополнительной информации см. Ссылку на конфигурацию прокси API .

Простой Healthmonitor определяет IntervalInSec в сочетании с TCPMonitor или Httpmonitor. Элемент <MaxFailures> определяет максимальное количество неудачных запросов от прокси -сервера API в TargetServer, что приводит к тому, что запрос будет перенаправлен на другой целевой сервер. По умолчанию <MaxFailures> равен 0, что означает, что Edge не выполняет корректирующие действия. При настройке монитора медицинского обслуживания убедитесь, что вы устанавливаете <MaxFailures> в теге <HTTPTargetConnection> тега <TargetEndpoint> до ненулевого значения.

Tcpmonitor

Конфигурация ниже определяет HealthMonitor, который опробовал каждый целевой сервер, открывая соединение на порту 80 каждые пять секунд. (Порт необязательно. Если не указано, порт TCPMonitor является портом TargetServer.)

• Если соединение не удается или занимает более 10 секунд для подключения, то количество сбоев увеличивается на 1 для этого целевого сервера.
• Если соединение преуспевает, то количество сбоев для TargetServer сбрасывается до 0.

Вы можете добавить HealthMonitor в качестве дочернего элемента элемента HttptArgetConnetion от TargetendPoint, как показано ниже:

<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 с элементами конфигурации TCPMonitor

В следующей таблице описываются элементы конфигурации TCPMonitor:

Httpmonitor

Образец HealthMonitor, который использует HTTPMonitor, отправит запрос GET в сервис Backend раз в пять секунд. Пример ниже добавляет основной заголовок авторизации HTTP к сообщению запроса. Конфигурация ответа определяет настройки, которые будут сравниваться с фактическим ответом от сервиса бэкэнд. В приведенном ниже примере ожидаемым ответом является код ответа HTTP 200 и пользовательский заголовок HTTP ImOK , значение которой является YourOK . Если ответ не соответствует, то запрос будет рассматриваться как сбой конфигурацией балансировщика нагрузки.

HTTPMonitor поддерживает сервис Backend, настроенные для использования HTTP и односторонних HTTPS-протоколов. Однако это не поддерживает следующее:

• Двусторонний HTTPS (также называемый двусторонним TLS/SSL)
• Саморевенные сертификаты.

Обратите внимание, что все настройки запроса и ответа в HTTP -мониторе будут специфичными для сервиса, которая должна быть вызвана.

    <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 с элементами конфигурации HTTPMonitor

В следующей таблице описываются элементы конфигурации HTTPMonitor: