Как развернуть Node.js в облаке для обеспечения высокой доступности, используя многоядерный, обратный прокси и SSL

Question

Я опубликовал это в ServerFault, но сообщество Node.js там кажется крошечным, поэтому я надеюсь, что это принесет больше внимания.

У меня есть приложение Node.js (0.4.9), и яисследуя, как лучше развернуть и поддерживать его.Я хочу запустить его в облаке (EC2 или RackSpace) с высокой доступностью.Приложение должно работать на HTTPS.Позже я буду беспокоиться о полном восстановлении после отказа Восток / Запад / ЕС.

Я много читал о средствах поддержки активности (Upstart, Forever), многоядерных утилитах (Fugue, multi-node, Cluster)) и балансировщики прокси / нагрузки (node-http-proxy, nginx, Varnish и Pound).Тем не менее, я не уверен, как объединить различные доступные мне утилиты.

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

1. Cluster является наиболее активно разработанной и, казалось бы, популярной многоядерной утилитой для Node.js, поэтому используйте ее для запуска «кластера» 1 узла на сервер приложений на непривилегированном порту (скажем, 3000). Q1: Следует ли Навсегда использовать для поддержания работоспособности кластера или это просто избыточно?
2. Использовать 1 nginx на сервер приложений, работающий на порту80, просто обратное проксирование к узлу на порту 3000. Q2: Будет ли node-http-proxy более подходящим для этой задачи, даже если он не работает с gzip или статическими файлами сервера быстро?
3. Минимум 2x сервера, как описано выше, с независимым сервером, выполняющим роль балансировщика нагрузки для этих блоков.Используйте Pound прослушивания 443, чтобы завершить HTTPS и передать HTTP на Varnish , который округлит баланс загрузки робота по IP-адресам серверов выше. Q3: Следует ли использовать nginx , чтобы сделать оба вместо этого? Q4: Если вместо этого рассмотреть балансировщик нагрузки AWS или RackSpace (последний не завершает HTTPS)

Общие вопросы:

1. Считаете ли вы вообще необходимость в (2) выше?
2. Где лучше всего прекратить HTTPS?
3. Если в будущем понадобятся WebSockets Какие замены nginx вы бы сделали?

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

Answer 1

Прошло уже несколько месяцев с тех пор, как я задал этот вопрос, а поток ответов не так много. У Самьяка Бхуты и nponeccop были хорошие предложения, но я хотел обсудить найденные ответы на мои вопросы.

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

1. Используйте Cluster, чтобы порождать столько дочерних процессов, сколько вы хотите обрабатывать входящие запросы на многоядерных виртуальных или физических машинах. Это привязывает к одному порту и облегчает обслуживание. Мое эмпирическое правило: n - 1 кластерные работники. Вы не нуждаетесь в этом навсегда, поскольку кластер вызывает рабочие процессы, которые умирают. Чтобы обеспечить отказоустойчивость даже на родительском уровне кластера, убедитесь, что вы используете сценарий Upstart (или его эквивалент), чтобы демонизировать приложение Node.js, и используете Monit (или его эквивалент), чтобы посмотреть PID родительского кластера и повторно вызвать его, если он умрет , Вы можете попробовать использовать функцию возрождения в Upstart, но я предпочитаю, чтобы Monit следил за вещами, поэтому вместо того, чтобы разделять обязанности, я считаю, что Monit лучше всего справится с возрождением.

2. Используйте 1 nginx на сервер приложений, работающий на порте 80, просто обратное проксирование к вашему кластеру на любом порту, к которому вы привязаны (1). Можно использовать node-http-proxy, но nginx более зрелый, более функциональный и быстрее обрабатывает статические файлы. Запустите nginx lean (не регистрируйте, не архивируйте крошечные файлы), чтобы минимизировать его накладные расходы.

3. Минимум 2 сервера, как описано выше, в минимум 2 зонах доступности, а если в AWS, используйте ELB, который завершает HTTPS / SSL на порту 443 и обменивается данными через порт 80 HTTP с серверами приложений node.js , ELB просты и, если хотите, упрощают автоматическое масштабирование. Вы можете запустить несколько nginx либо с общим IP-адресом, либо с помощью циклического перебора, уравновешенного вашим DNS-провайдером, но я обнаружил, что это излишнее. В этот момент вы должны удалить экземпляр nginx на каждом сервере приложений.

Мне не нужны WebSockets, поэтому nginx по-прежнему подходит, и я снова вернусь к этой проблеме, когда появятся WebSockets.

Обратная связь приветствуется.

Answer 2

Это отличная тема! Спасибо всем, кто предоставил полезную информацию.

В последние несколько месяцев я сталкивался с такими же проблемами при настройке инфраструктуры для нашего стартапа.

Как уже упоминалось ранее, нам нужна среда Node с поддержкой нескольких ядер + веб-сокеты + vhosts

В итоге мы создали гибрид между собственным модулем кластера и http-прокси и назвали его Drone - конечно, это с открытым исходным кодом:

https://github.com/makesites/drone

Мы также выпустили его как AMI с Monit и Nginx

https://aws.amazon.com/amis/drone-server

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

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

Не стесняйтесь заглянуть в него и сообщить, соответствует ли он вашим потребностям. Все отзывы приветствуются.

Answer 3

Вам не следует быстро обслуживать статические файлы. Если ваша нагрузка мала - подойдут статические файловые серверы узла. Если ваша нагрузка большая - лучше использовать CDN (Akamai, Limelight, CoralCDN).

Вместо вечности вы можете использовать monit.

Вместо nginx вы можете использовать HAProxy. Известно, что хорошо работает с веб-сокетами. Также рассмотрите возможность использования прокси-флеш-сокетов, так как это хороший обходной путь, пока поддержка веб-сокетов не станет повсеместной (см. Socket.io).

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

Балансовая балансировка нагрузки (или другая статистическая) на практике работает довольно хорошо, поэтому в большинстве случаев нет необходимости знать о нагрузке других серверов.

Также рассмотрите возможность использования ZeroMQ или RabbitMQ для связи между узлами.

Answer 4

Я видел балансировщик нагрузки AWS для балансировки и завершения нагрузки + http-node-proxy для обратного прокси-сервера, если вы хотите запустить несколько служб на box + cluster.js для поддержки многоядерных процессоров и аварийного переключения на уровне процессов, которые работают очень хорошо.

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