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

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

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

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

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

Видео

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

Пример конфигурации целевого сервера

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

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

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

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

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

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

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

С помощью Edge API можно создавать, удалять, обновлять, получать и отображать список целевых серверов. Дополнительную информацию см. в разделе «Целевые серверы» .

Для создания целевого сервера используйте следующий вызов 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:

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

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

[ "target2", "target1" ]

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

В разделе «Ограничения» указано ограничение в 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-прокси к бэкэнд-серверам будут чередоваться, один к одному, между target1 и target2.

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

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

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

Алгоритм

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

круговой турнир

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

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

Взвешенный

Алгоритм взвешенной балансировки нагрузки позволяет настроить пропорциональное распределение трафика для ваших целевых серверов. Взвешенный балансировщик нагрузки распределяет запросы между вашими целевыми серверами в прямой пропорции к весу каждого целевого сервера. Поэтому для использования взвешенного алгоритма необходимо задать атрибут weight для каждого целевого сервера. Например:

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

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

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

Балансировщики нагрузки, настроенные на использование алгоритма маршрутизации наименьшего количества соединений, направляют исходящие запросы к целевому серверу с наименьшим количеством открытых 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. Если вы настроите MaxFailures > 0, целевой сервер будет исключен из ротации, когда целевой сервер выйдет из строя указанное вами количество раз. При наличии монитора состояния системы Apigee автоматически вернет целевой сервер в ротацию после того, как целевой сервер снова заработает, в соответствии с конфигурацией этого монитора. Дополнительную информацию см. в разделе «Мониторинг состояния системы» .

В качестве альтернативы, если вы настроите 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

Схему 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 начинает отправлять запросы на проверку состояния целевому серверу. Проверка состояния — это запрос, отправляемый целевому серверу, который определяет, находится ли целевой сервер в рабочем состоянии или нет.

Результаты медицинского обследования могут быть одним из двух:

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

  Когда 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 сбрасывается до 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 Basic Authorization. Конфигурация Response определяет параметры, которые будут сравниваться с фактическим ответом от бэкэнд-сервиса. В приведенном ниже примере ожидаемый ответ — это код ответа 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: