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

Вы просматриваете документацию 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 и не настроите HealthMonitor, Apigee не будет повторно включать TargetServer в ротацию автоматически после того, как Apigee обнаружит сбой. В этом случае вам необходимо повторно развернуть прокси-сервер API, прежде чем Apigee вернет TargetServer в ротацию. См. раздел «Развертывание прокси-сервера API» .

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

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