Что делает автоматический контроль здоровья Amazon ELB и что он ожидает?

Вот что:

  • Мы реализовали сервер API С++ RESTful со встроенным анализатором HTTP и стандартным HTTP-сервером, таким как apache или что-то в этом роде
  • Он использовался несколько месяцев в структуре Amazon, используя как обычную, так и SSL-связь, и никаких проблем не было обнаружено, связанных с инфраструктурой Amazon.
  • Мы развертываем наш первый бэкэнд с помощью Amazon ELB
  • Amazon ELB имеет настраиваемую систему проверки работоспособности, но также как автоматическую, как указано здесь
  • Мы не обнаружили никакой документации о том, какие данные отправляются системой проверки работоспособности
  • Бэкэнд просто зависает в инструкции чтения сокета и, в конце концов, соединение закрывается

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

Помощь очень ценится. Спасибо.

ОТВЕТЫ

Ответ 1

Amazon ELB имеет настраиваемую систему проверки работоспособности, но также как автоматический, как указано здесь

С настраиваемым вы, вероятно, ссылаетесь на проверку работоспособности, настраиваемую с помощью консоли управления AWS (см. Настройка параметров проверки работоспособности) или через API ( см. ConfigureHealthCheck).

Требования для передачи настроенных таким образом проверок работоспособности описаны в поле Цель HealthCheck документации по типу данных:

Задает проверяемый экземпляр. Протокол является либо протоколом TCP, HTTP, HTTPS или SSL. Диапазон допустимых портов - один (1) через 65535.

Примечание

  • TCP является значением по умолчанию, указанным как пара TCP: порт, например "TCP: 5000". В этом случае проверка работоспособности просто пытается открыть TCP соединение с экземпляром на указанном порту. Невозможность подключения в течение настроенного таймаута считается нездоровым.

  • SSL также указывается как пара SSL: порт, например SSL: 5000.

  • Для протокола HTTP или HTTPS ситуация отличается. Вы должны включить в строку пинг-путь. HTTP указывается как HTTP: порт; /; PathToPing; группировка, например "HTTP: 80/погода/нам/ва/Сиэттл". В этом случае запрос HTTP GET выданный экземпляру на данном порту и пути. Любой ответ другой чем "200 OK" в течение периода ожидания считается нездоровым.

  • Общая длина HTTP-запроса ping должна быть 1024 16-разрядной Символы Unicode или меньше.

[акцент мой]

С автоматическим вы предположительно ссылаетесь на проверку работоспособности, описанную в параграфе "Причина" в Почему URL проверки работоспособности отличается от URL-адреса, отображаемого в API и консоли?:

В дополнение к проверке работоспособности, которую вы настраиваете для своего балансировщика нагрузки, вторая проверка работоспособности выполняется службой для защиты от потенциальные побочные эффекты, вызванные прекращением за исключением регистрации. Чтобы выполнить эту проверку, балансировка нагрузки открывает TCP-соединение на том же порту, что и проверка работоспособности использовать, а затем закрывает соединение после проверки работоспособности завершено. [акцент мой]

В пункте "Решение" разъясняется, что полезная нагрузка равна нулю здесь, то есть она аналогична методу non HTTP/HTTPS, описанному для настраиваемой проверки работоспособности выше:

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

Резюме/решение

Предполагая, что ваш сервер API RESTful со встроенным анализатором HTTP должен обслуживать только HTTP, вам нужно будет обрабатывать две проверки работоспособности:

  • Сначала вы настроили себя как HTTP: port;/; PathToPing - вы получите запрос HTTP GET и должны ответить с 200 OK в течение указанного периода ожидания, чтобы считаться здоровым.
  • Второй, настроенный автоматически службой - он откроет TCP-соединение на указанном выше HTTP-порту, не отправит никаких данных, а затем закроет соединение после завершения проверки работоспособности.

В заключение кажется, что ваш сервер может вести себя отлично, и вас просто раздражает второе поведение проверки работоспособности - действительно ли ELB считает ваш сервер нездоровым?

Ответ 2

Насколько я знаю, это просто HTTP-запрос GET, ищущий ответ 200 OK http.