1. Inicio
  2. Pregunta y respuesta
  3. Cómo implementar Node.js en la nube para alta disponibilidad usando multi-core, proxy inverso y SSL

Cómo implementar Node.js en la nube para alta disponibilidad usando multi-core, proxy inverso y SSL

2011-08-31 18 views
46

Lo he publicado en ServerFault, pero la comunidad Node.js parece pequeña allí, así que espero que esto traiga más exposición.Cómo implementar Node.js en la nube para alta disponibilidad usando multi-core, proxy inverso y SSL

Tengo una aplicación Node.js (0.4.9) y estoy buscando la mejor manera de implementarla y mantenerla. Quiero ejecutarlo en la nube (EC2 o RackSpace) con alta disponibilidad. La aplicación debe ejecutarse en HTTPS. Me preocuparé más tarde por la conmutación por error de East/West/EU.

He leído mucho sobre keep-alive (Upstart, Forever), utilidades multi-core (Fugue, multinodo, Cluster) y proxy/load balancers (node-http-proxy, nginx, Varnish y Pound). Sin embargo, no estoy seguro de cómo combinar las diversas utilidades disponibles para mí.

Tengo esta configuración en mente y necesito aclarar algunas preguntas y obtener comentarios.

  1. Cluster es la utilidad de varios núcleos desarrollado la mayor parte de forma activa y aparentemente popular para Node.js, a fin de utilizar eso para ejecutar el nodo 1 "grupo" por servidor de aplicaciones en el puerto no privilegiado (por ejemplo 3000). Q1: ¿Debería Forever utilizarse para mantener vivo el clúster o simplemente es redundante?
  2. Uso 1 nginx por servidor de aplicaciones que se ejecutan en el puerto 80, basta con invertir proxy al nodo en el puerto 3000. P2: ¿Podríanodo-http-proxy ser más adecuado para esta tarea a pesar de que no gzip o servidor de archivos estáticos rápidamente?
  3. Tenga un mínimo de 2 servidores como se describió anteriormente, con un servidor independiente que actúa como equilibrador de carga en estos cuadros. Use Pound escuchando 443 para finalizar HTTPS y pase HTTP a Varnish que equilibraría el balance de carga entre las direcciones IP de los servidores anteriores. Q3: ¿Debería usar nginx para hacer ambas cosas? P4: En caso de AWS o Rackspace equilibrador de carga se considerará lugar (este último no termina HTTPS)

Preguntas generales:

  1. Cómo ves la necesidad de (2) anterior en ¿todas?
  2. ¿Cuál es el mejor lugar para finalizar HTTPS?
  3. Si se necesitan WebSockets en el futuro, ¿qué sustituciones de nginx haría?

Realmente me gustaría escuchar cómo la gente está configurando los entornos de producción actuales y qué combinación de herramientas prefieren. Muy apreciado.

Fuente

2011-08-31 Chris F

+4

Tenga en cuenta que el clúster, etc. no proporciona multi-threading, simplemente proporcionan el uso de múltiples núcleos a través de múltiples procesos. Esto es completamente diferente. Tenga en cuenta también que Cluster no proporcionará alta disponibilidad si su master falla. El niño se suicidará y el maestro no reaparecerá. Tal vez puedas usar algo como Forever para reiniciar el maestro. Además, tenga en cuenta que Nginx no puede enrutar las conexiones de websocket. Finalmente, "un servidor independiente que actúa como un equilibrador de carga a través de estos cuadros": ¿y si este servidor se cae? – Tom

+0

@Tom, todos excelentes puntos. Actualizaré la pregunta para tener en cuenta el uso de varios núcleos, no multi-threading, pero el primero es lo que quise decir. Usaría Monit en cada servidor para ver el PID de Cluster y reiniciarlo si fuera necesario. Comprendo la limitación actual de WS/WSS de nginx, pero aún no la necesito. Yo también usaría Monit en el equilibrador de carga, pero todavía no tengo una buena solución para ese único punto de falla, salvo las zonas de disponibilidad múltiple (duplicados de toda esta configuración). –

+0

@ChrisF ve a hablar con los chicos de nodejitsu en #nodejitsu en freenode. Si quieres saber sobre la arquitectura de nodo, ese es el lugar donde debes estar. – Raynos

Respuesta

20

Han pasado varios meses desde que hice esta pregunta y no hubo mucho flujo de respuesta. Tanto Samyak Bhuta como nponeccop tuvieron buenas sugerencias, pero quería analizar las respuestas que he encontrado a mis preguntas.

Esto es lo que he decidido en este punto para un sistema de producción, pero siempre se están realizando mejoras. Espero que ayude a cualquiera en un escenario similar.

  1. Utilice Cluster para generar tantos procesos secundarios como desee para gestionar las solicitudes entrantes en máquinas virtuales o físicas de varios núcleos. Esto se une a un solo puerto y facilita el mantenimiento. Mi regla de oro es n - 1 Cluster workers. No necesita a Forever en esto, ya que Cluster reaparece los procesos de los trabajadores que mueren. Para tener capacidad de recuperación incluso en el nivel primario del clúster, asegúrese de utilizar un script Upstart (o equivalente) para demonizar la aplicación Node.js y use Monit (o equivalente) para ver el PID del padre del clúster y reagudiarlo si muere. . Puedes intentar usar la función de reaparición de Upstart, pero prefiero que Monit esté mirando cosas, así que en lugar de dividir las responsabilidades, creo que es mejor dejar que Monit maneje el reaparición también.

  2. Utilice 1 nginx por servidor de aplicaciones que se ejecute en el puerto 80, simplemente transfiera el proxy a su Cluster en cualquier puerto al que esté vinculado (1). node-http-proxy se puede usar, pero nginx es más maduro, más funcional y más rápido al servir archivos estáticos. Ejecute nginx lean (no inicie sesión, no gzip archivos pequeños) para minimizar su sobrecarga.

  3. Tenga un mínimo de 2 servidores como se describió anteriormente en un mínimo de 2 zonas de disponibilidad y en AWS use un ELB que termine HTTPS/SSL en el puerto 443 y se comunique en el puerto HTTP 80 a los servidores de aplicaciones node.js. Los ELB son simples y, si lo deseas, facilitan la escalación automática. Podrías ejecutar múltiples nginx, ya sea compartiendo una IP o round-robin balanceados por tu proveedor de DNS, pero encontré esto demasiado por ahora. En ese punto, eliminaría la instancia de nginx en cada servidor de aplicaciones.

No he necesitado WebSockets por lo nginx sigue siendo adecuada y voy a examinar esta cuestión cuando WebSockets entran en escena.

Los comentarios son bienvenidos.

Fuente

2012-01-24 16:12:26

+4

¿por qué usaste nginx? para servir contenido estático o como un enrutador a diferentes servidores de aplicaciones? Si solo sirve contenido estático, ¿por qué no s3? – GJain

+0

Tengo mucha curiosidad por saber si ha considerado utilizar la herramienta PM2 y el conjunto de herramientas 'slc' de strong-loops, principalmente 'scl deploy' y 'scl pm' –

2

No debería molestarse en servir archivos estáticos rápidamente. Si su carga es pequeña, los servidores de archivos estáticos lo harán. Si su carga es grande, es mejor usar un CDN (Akamai, Limelight, CoralCDN).

En lugar de siempre puedes usar monit.

En lugar de nginx puede usar HAProxy. Se sabe que funciona bien con websockets.Considere también proxys flash sockets, ya que son una buena solución hasta que el soporte de websocket sea omnipresente (consulte socket.io).

HAProxy tiene algo de soporte para el balanceo de carga HTTPS, pero no la terminación. Puede intentar usar stunnel para la terminación de HTTPS, pero creo que es demasiado lento.

El equilibrio de carga por turnos (u otro equilibrio estadístico) funciona bastante bien en la práctica, por lo que no es necesario conocer la carga de otros servidores en la mayoría de los casos.

Considere también usar ZeroMQ o RabbitMQ para comunicaciones entre nodos.

Fuente

2011-09-10 21:17:45 nponeccop

+1

Curioso, ¿qué ventaja tendría Zero/RabbitMQ con solo usar sockets nodeJS nativos para la comunicación entre nodos? –

+1

@ XHR: el uso de MQ puede proporcionar una comunicación más sofisticada entre varios nodos, incluidos los mensajes de difusión y los mensajes en una cola de trabajos que puede ser atendida exactamente por uno de los siguientes nodos disponibles. Piense en MQ como conectores autoorganizados y autocurativos. –

0

He visto el equilibrador de carga AWS para cargar el saldo y la terminación + http-node-proxy para proxy inverso, si desea ejecutar múltiples servicios por caja + cluster.js para soporte mulicore y failover de nivel de proceso funcionando muy bien.

forever.js en cluster.js podría ser una buena opción para el cuidado extremo que desea tomar en términos de conmutación por error, pero eso apenas se necesita.

Fuente

2011-12-01 17:40:57

2

¡Este es un hilo excelente! Gracias a todos los que contribuyeron con información útil.

He estado lidiando con los mismos problemas en los últimos meses al configurar la infraestructura para nuestra puesta en marcha.

medida que la gente se ha mencionado anteriormente, queríamos un entorno de nodos con múltiples núcleos tomas de apoyo + web + vhosts

Terminamos creando un híbrido entre el módulo de agrupación nativa y http-proxy y lo llamamos Drone - por supuesto que es de código abierto:

https://github.com/makesites/drone

también se lanzó como un IAM con Monit y Nginx

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

Encontré este hilo investigando cómo agregar soporte SSL a Drone-tnx para recomendar ELB pero no confiaría en una solución patentada para algo tan crucial.

En su lugar, extendí el proxy predeterminado para manejar todas las solicitudes de SSL. La configuración es mínima, mientras que las solicitudes SSL se convierten en http simple, pero supongo que es preferible cuando está pasando tráfico entre los puertos ...

No dude en consultar y dejarme saber si se ajusta a sus necesidades. Todos los comentarios fueron bienvenidos.

Fuente

2013-02-12 12:48:09 tracend

Cuestiones relacionadas

 Cuestiones relacionadas