Я хочу настроить автомасштабирование в AWS. Я не хочу использовать Elastic Load Balancer.
При автоматическом вызове в Amazon инстансы EC2 беспрепятственно создаются во время пиков спроса для поддержания производительности и автоматически уменьшаются во время затишья спроса для минимизации затрат.
Поскольку эти экземпляры EC2 создаются автоматически, их имена хостов неизвестны NGINX.
Я знаю и уже настроил апстрим в nginx до 10 экземпляров EC2.
Я хочу иметь возможность добавлять / обновлять / удалять автоматически имена серверов в мою конфигурацию восходящего потока nginx, когда автоматическое масштабирование добавляет / обновляет / удаляет экземпляры EC2.
Это может быть достигнуто с помощью Amazon SDK (я почти закончил с ним, выложу на github), с использованием сервисов SNS, EC2 и Autoscaling.
Для этого я выполнил следующие шаги:
Пожалуйста, найдите сценарий здесь https://github.com/singhupendra/aws-autoscale
Спасибо @talonx, я провел небольшое исследование, у Amazon Autoscale есть API для запроса текущего статуса группы автомасштабирования и перечисления ее участников. Возвращает идентификатор экземпляра (http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/api_requests.html#query-example), то вы можете использовать инструменты описания, чтобы получить имя сервера (http://docs.aws.amazon.com/AWSEC2/latest/CommandLineReference/ApiReference-cmd-DescribeInstances.html) и, наконец, воссоздайте включаемый файл восходящего потока. Я чувствовал, что уведомления автомасштабирования запускают процесс, выполняющий эти задачи.
Я все еще не реализовал это, но это путь.
Можно также использовать Autocaling с SNS http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/ASGettingNotifications.html
Я сам еще не реализовал это, но я собираюсь использовать Изменение конфигурации на лету из NGiNX Plus. Я думаю, что либо AMI, либо управление конфигурацией (Puppet, Salt или подобное), которое устанавливает экземпляр Auto Scaling Group, может достичь API реконфигурации NGiNX (возможно, через внутреннее доменное имя Route53, поэтому фиксированный IP-адрес не будет необходимо использовать) и добавить себя в восходящий кластер для обратного прокси. После этого встроенная проверка работоспособности NGiNX возьмет на себя этот [добавленный] экземпляр и отключит его, если он станет недоступен. Это кажется наиболее чистым решением, и при добавлении экземпляра нет задержки и почти не возникает задержки при его удалении, поскольку NGiNX Plus поддерживает внеполосную проверку работоспособности.
Этот подход позволяет избежать необходимости настраивать систему автоматического обнаружения (Consul, Serf и т. Д.), Что для небольших настроек часто кажется большими накладными расходами как с точки зрения настройки / администрирования, так и с точки зрения требуемых экземпляров EC2. Consul, например, требует минимум трех экземпляров для стабильной работы. Serf, возможно, мог бы работать на самих экземплярах ASG, но все еще есть накладные расходы на его обслуживание, и если ASG уменьшится до одного или двух экземпляров, вы потеряете кворум.
Наконец, это может быть объединено с автоматическим уведомлением об изменениях Auto Scaling Group, возможно, на сервере (ах) NGiNX, который используется / используются для балансировки нагрузки. Слушатель, запускаемый таким уведомлением (это может быть то, что также упоминал Упендра), может затем мгновенно добавить новый экземпляр в NGiNX через API модификации на лету. Помимо стоимости NGiNX Plus, это заставляет задуматься, зачем вообще кому-то использовать Elastic Load Balancer с его многочисленными проблемами.
Изменить 2015-12-07: ngx_openrestyс балансировщик на lua (см. эту ветку GitHub) предлагает еще одно возможное решение с открытым исходным кодом для горячего добавления / удаления серверов из вышестоящей группы NGiNX. Я сам еще не экспериментировал с этим, но хотел бы добавить сюда упоминание для всех, кто наткнется на этот пост.