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

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

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

Конфигурации TargetServer отделяют URL конечных точек от конфигураций TargetEndpoint. На каждый TargetServer ссылается TargetEndpoint HTTPConnection по имени. Вместо того чтобы указывать в конфигурации конкретный URL, вы можете настроить один или несколько именованных целевых серверов, как описано в разделе 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
}

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

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

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

[ "target2", "target1" ]

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

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

Как настроить TargetEndpoint для балансировки нагрузки между именованными TargetServer

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

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

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

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

Как задать параметры балансировщика нагрузки

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

Алгоритм

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

Циклический перебор

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

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

Взвешенная

Алгоритм балансировки нагрузки с весами позволяет настроить пропорциональную нагрузку на целевые серверы. Взвешенный балансировщик нагрузки распределяет запросы между целевыми серверами пропорционально весу каждого из них. Поэтому для каждого TargetServer необходимо задать атрибут 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.

Наименьшее количество подключений

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

Путь

Путь определяет фрагмент 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".
  • Целевой сервер отвечает на запрос проверки работоспособности кодом статуса HTTP 200 (OK) или другим кодом, который вы считаете приемлемым.
  • Целевой сервер отвечает на запрос проверки работоспособности с телом сообщения, которое соответствует ожидаемому.

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

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

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

Как включить HealthMonitor

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

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

TCPMonitor

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

• Если подключение не удается или занимает более 10 секунд, счетчик ошибок увеличивается на единицу для этого целевого сервера.
• Если подключение будет установлено, счетчик ошибок для 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. В конфигурации ответа задаются настройки, которые будут сравниваться с фактическим ответом от бэкенд-службы. В приведенном ниже примере ожидается код ответа 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.