1

Я написал специальный сценарий выпуска для управления версиями для приложения автоматической автозагрузки EC2. Обработка работает так ...Ошибки подключения бэкэнд ELB при регистрации экземпляров ec2

  1. Создайте AMI на основе приложения git tag.
  2. Создать конфигурацию запуска.
  3. Настройте ASG для использования новой конфигурации запуска.
  4. Найдите требуемую мощность для ПГС.
  5. Установите желаемую мощность до 2x предыдущей емкости.
  6. Подождите, пока новые экземпляры станут здоровыми, запросив ELB.
  7. Установите желаемую мощность обратно на предыдущее значение.

Это все работает достаточно хорошо, за исключением случаев, когда я запускаю это, мониторинг для ELB показывает много ошибок подключения к серверу.

Я не знаю, почему это произошло, так как это должно (на основе моего понимания) по-прежнему обслуживать текущие соединения, если для ELB включена опция «Сливы подключения» (какая она есть).

Я подумал, что, возможно, ASG завершала экземпляры до того, как соединения завершились, поэтому я изменил свой сценарий, чтобы сначала отменить регистрацию экземпляров из ELB, а затем подождать некоторое время, прежде чем изменять желаемую емкость в ASG. Это, однако, не имело никакого значения. Как только экземпляры были отменены из ELB (хотя они все еще работают и здоровы), возникают ошибки подключения к серверу.

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

Это команда, я использую для дерегистрировать экземпляры ...

aws elb deregister-instances-from-load-balancer --load-balancer-name $elb_name --instances $old_instances 

Есть некоторый предпочтительный способ изящно удалить экземпляры из УДРА перед удалением их из ГАС?

+0

У вас есть подключение дренажа включено? – hellomichibye

+0

Да У меня включен слив соединения. На самом деле, похоже, я сделал неверное предположение о ошибках подключения. Это не старые экземпляры, а новые, но не готовые к обработке нагрузки. – user1751825

+1

следующий вопрос: у вас есть healthchecks? – hellomichibye

ответ

2

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

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

+2

Совет для масштабирования за пределами обновлений приложения: в вашей группе автомасштабирования есть параметр, называемый [Срок гарантии проверки работоспособности] (http://docs.aws.amazon.com/autoscaling/latest/userguide/healthcheck.html#health- check-grace-period), который будет ждать истечения льготного периода перед обработкой любых событий масштабирования на основе проверки работоспособности ELB нового экземпляра; независимо от того, в какой период вы заканчиваете тем, что задерживаете автоматизацию, чтобы разогнать ваши новые экземпляры, подумайте о том, чтобы установить срок гарантии на проверку работоспособности на одно и то же значение. –