Антипаттерн: балансировка нагрузки с одним целевым сервером и значением MaxFailures, отличным от нуля

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

Конфигурация TargetEndpoint определяет, как Apigee Edge подключается к бэкенд-службе или API. Он отправляет запросы и получает ответы от бэкенд-службы. Бэкенд-служба может быть сервером HTTP/HTTPS, NodeJS или размещенной целевой службой.

Вызвать бэкенд-службу в TargetEndpoint можно одним из следующих способов:

  • Прямой URL HTTP- или HTTPS-сервера.
  • ScriptTarget для скрипта Node.js, размещенного на пограничном сервере
  • HostedTarget в NodeJS, развернутый в Hosted Target Environment
  • Конфигурация TargetServer

Аналогичным образом, с помощью правила Service Callout можно вызвать любой внешний сервис из потока прокси API. Это правило позволяет задавать целевые URL HTTP/HTTPS непосредственно в правиле или с помощью конфигурации TargetServer.

Конфигурация TargetServer

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

Вот пример конфигурации TargetServer:

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

TargetServer позволяет задавать разные конфигурации для каждой среды. Правило TargetEndpoint/Service Callout можно настроить с одним или несколькими именованными TargetServer с помощью LoadBalancer. Встроенная поддержка балансировки нагрузки повышает доступность API и обеспечивает отработку отказа между настроенными экземплярами бэкенд-сервера.

Вот пример конфигурации TargetEndpoint с использованием TargetServers:

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

MaxFailures

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

Пример конфигурации с указанным значением MaxFailures:

<TargetEndpoint name="default">
    <HTTPTargetConnection>
      <LoadBalancer>
        <Server name="target1"/>
       <Server name="target2"/>
       <MaxFailures>5</MaxFailures>
      </LoadBalancer>
    </HTTPTargetConnection>
</TargetEndpoint>

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

Антипаттерн

Не рекомендуется использовать один TargetServer в конфигурации LoadBalancer правила TargetEndpoint или Service Callout, если для MaxFailures задано ненулевое значение, поскольку это может привести к нежелательным последствиям.

Ниже приведен пример конфигурации с одним TargetServer под названием target1, для которого задано значение MaxFailures, равное 5 (ненулевое значение): 

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <MaxFailures>5</MaxFailures>
      </LoadBalancer>
  </HTTPTargetConnection>

Если запросы к TargetServer "target1" пять раз завершатся неудачно (число, указанное в MaxFailures), TargetServer будет удален из ротации. Поскольку других целевых серверов для перехода нет, все последующие запросы к прокси API с этой конфигурацией будут завершаться с ошибкой 503 Service Unavailable.

Даже если целевой сервер "target1" вернется в нормальное состояние и сможет отправлять успешные ответы, запросы к прокси API будут по-прежнему возвращать ошибки 503. Это связано с тем, что Edge не возвращает TargetServer в ротацию автоматически, даже если целевой сервер снова запущен. Чтобы устранить эту проблему, необходимо повторно развернуть прокси API, чтобы Edge снова начал использовать TargetServer.

Если та же конфигурация используется в правиле Service Callout, то после пяти неудачных запросов к TargetServer "target1" запросы API будут возвращать ошибку 500.

Результат

Использование одного TargetServer в конфигурации LoadBalancer TargetEndpoint или правила вызова сервиса с параметром MaxFailures, имеющим ненулевое значение, приводит к следующим последствиям:

  • Запросы к API будут постоянно завершаться ошибками 503/500 (после того как запросы завершатся ошибкой MaxFailures раз) до тех пор, пока не будет повторно развернут прокси API.
  • Более длительный сбой, поскольку диагностика причины этой проблемы может быть сложной и занять больше времени (если ранее вы не сталкивались с этим антипаттерном).

Рекомендации

  1. Чтобы повысить доступность, в конфигурации LoadBalancer должно быть несколько элементов TargetServer.

  2. Всегда задавайте монитор состояния, если для параметра MaxFailures установлено ненулевое значение. Целевой сервер будет исключен из ротации, когда количество ошибок достигнет значения, указанного в MaxFailures. Наличие HealthMonitor гарантирует, что TargetServer будет возвращен в ротацию, как только целевой сервер снова станет доступен. Это означает, что повторно развертывать прокси не нужно.

    Чтобы проверка работоспособности выполнялась на том же порту, который Edge использует для подключения к целевым серверам, Apigee рекомендует опустить дочерний элемент <Port> в элементе <TCPMonitor>, если только он не отличается от порта TargetServer. По умолчанию <Port> совпадает с портом TargetServer.

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

    <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>
      </TCPMonitor>
    </HealthMonitor>
  </HTTPTargetConnection>
</TargetEndpoint>

  3. Если есть ограничение, согласно которому можно использовать только один TargetServer и если HealthMonitor не используется, не указывайте MaxFailures в конфигурации LoadBalancer.

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

Дополнительные материалы