Вопросы Теги

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

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

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

Я сделал большое чтение об активном (Выскочка, Навсегда), многоядерные утилиты (Фуга, мультиузел, Кластер), и прокси/подсистемы балансировки нагрузки (прокси HTTP узла, nginx, Лак и Фунт). Однако я не уверен, как объединить различные утилиты, доступные мне.

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

  1. Кластер является наиболее активно разработанной и на вид популярной многоядерной утилитой для Node.js, так использование, что для выполнения 1 узла "кластер" на сервер приложений на непривилегированном порте (говорят 3000). Q1: Должен Навсегда использоваться для поддержания кластера, или это просто избыточно?
  2. Используйте 1 nginx на работу сервера приложений порта 80, просто проксирование реверса к узлу на порте 3000. Q2: прокси HTTP узла более подошел бы для этой задачи даже при том, что это не делает gzip или сервера статические файлы быстро?
  3. Имейте минимум 2x серверы, как описано выше с независимым сервером, действующим как подсистема балансировки нагрузки через эти поля. Используйте Фунт, слушая 443, чтобы завершить HTTPS и передать HTTP для Лакировки, который был бы круговой баланс загрузки через дюйм/с серверов выше. Q3: nginx должен использоваться, чтобы сделать обоих вместо этого? Q4: Если AWS или подсистему балансировки нагрузки RackSpace рассматривают вместо этого (последний не завершает HTTPS),

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

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

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

4
задан 31 August 2011 в 18:38
1 ответ

Hat hosszú évek óta, és senki sem kapott választ. Nos, van egy kis utólagos áttekintésem a tapasztalatok kiegészítésére, így továbbadom.

Q1. Talán. Ha nem bánja, ha hozzáadja a fürt összetettségét az alkalmazásához, és ügyel arra, hogy elkerülje mindazt, ami belekerülhet a fő folyamatba, akkor a fürt remekül működik. Ellenkező esetben biztosan szeretné, ha valami kezelné a csomópont-folyamat felügyeletét és az alkalmazás újraindítását az alkalmazás összeomlásakor. Az operációs rendszer olyan alternatívákat kínálhat, mint a démon vagy a systemd. Q2. Nem. Legjobb esetben, ha jó nap van a széllel, a node-http-proxy majdnem olyan jó, mint a nginx vagy a haproxi. Az SSL kivételével, ahol a haproxia és az nginx is sokkal jobb. Borzasztóan nehéz lenne tokot építeni, hogy az megfelelőbb legyen.

Q3. Igen, vagy haproxi. Amíg nincs szükség lakk bevezetésére. Amikor eljut erre a pontra, nem kell azon gondolkodnia, hogy lakkot kellene-e használnia. (Vagy CDN-t fog használni).

Q4. Hívásod. A Haproxy az alapértelmezett eszközem a TLS felszámolásához és a proxykhoz. Nem utálom magam annyira, hogy oly kritikus dolgot helyezzek el, mint egy terheléselosztót valaki más szerverére, ahol nem tudom futtatni a tcpdump vagy más hibaelhárító eszközöket.

  1. Igen. Ha jól ismerte az nginx szolgáltatást, akkor használja a HTTPS felmondás kezelésére és a kérések proxykozására az alkalmazáskiszolgálóira. Ha még nem foglalkozol erősen a nginx-szel, akkor inkább a haproxi -ot vegye fontolóra. Olyan névvel, mint a haproxi, elvárható, hogy valóban nagyon jó legyen a HA-ban és a proxy-ban, és ez nem okoz csalódást.

  2. haproxy / nginx. Mindig. Jobb tanúsítványkezelés, lista a következő címen: cipherli.st , stb. Kevesebb hatással van az alkalmazásodra is a proxy frissítése, amikor az openssl biztonsági rések megjelennek.

  3. haproxy. (Az nginx most már támogatja a proxyvezetők használatát, ezért ez a kérdés már lejárt.)

  4. Több webhely és BGP. Olyan eszközök bevezetése a verembe, mint a keepalived vagy más peer-to-peer TCP feladatátvételi mechanizmus, ugyanolyan valószínűsíthetően a leállás oka, mint annak megakadályozása. Az ilyen eszközök használata jellemzően ritka, így az ember, aki ismeri a helyszínt, gyakorlaton kívül van, amikor erre szükség van. Tartsa a verem egyszerűbbé, és függjön a hálózati csapat képességeitől.

0
ответ дан 3 December 2019 в 04:32

Теги

Похожие вопросы