deployment - tiene - infraestructura cloud aws

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

Question

He publicado esto en ServerFault, pero la comunidad Node.js parece pequeña allí, así que espero que esto traiga más exposición.

Tengo una aplicación Node.js (0.4.9) y estoy investigando cómo implementarla y mantenerla mejor. 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 resolver algunas preguntas y obtener retroalimentación.

1. Cluster es la utilidad multinúcleo más desarrollada y aparentemente más popular para Node.js, así que úselo para ejecutar 1 nodo "clúster" por servidor de aplicaciones en un puerto no privilegiado (digamos 3000). P1: ¿Se debería usar Forever para mantener vivo el clúster o simplemente es redundante?
2. Utilice 1 nginx por servidor de aplicaciones que se ejecute en el puerto 80, simplemente transfiera el proxy al nodo en el puerto 3000. P2: ¿El nodo-http-proxy sería más adecuado para esta tarea aunque no gzip o servidores de archivos estáticos rápidamente?
3. Tener un mínimo de servidores 2x como se describió anteriormente, con un servidor independiente que actúa como un equilibrador de carga a través de estos cuadros. Utilice Pound Listening 443 para terminar HTTPS y pasar HTTP a Varnish, lo que equilibraría el balance de carga entre las direcciones IP de los servidores anteriores. P3: ¿Debería usarse nginx para hacer ambas cosas? P4: ¿Debería considerarse en su lugar el equilibrador de carga AWS o RackSpace (este último no finaliza HTTPS)?

Preguntas generales:

1. ¿Ves la necesidad de (2) arriba en absoluto?
2. ¿Dónde está 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 las personas están configurando los entornos de producción actuales y qué combinación de herramientas prefieren. Muy apreciado.

Answer 1

¡Este es un excelente hilo! 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 startup.

Como se mencionó anteriormente, queríamos un entorno Node con soporte multinúcleo + web sockets + vhosts

Terminamos creando un híbrido entre el módulo de clúster nativo y http-proxy y lo llamamos Drone , por supuesto, es de fuente abierta:

https://github.com/makesites/drone

También lo lanzamos como un AMI 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 SSL. La configuración es mínima, mientras que las solicitudes SSL se convierten en http simple, pero supongo que es preferible cuando se transfiere tráfico entre puertos ...

No dudes en consultarlo y decirme si se ajusta a tus necesidades. Todos los comentarios fueron bienvenidos.

Answer 2

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

Aquí es a lo que me he acostumbrado en este punto para un sistema de producción, pero siempre se están haciendo mejoras adicionales. Espero que ayude a cualquiera en un escenario similar.

1. Use Cluster para engendrar tantos procesos secundarios como desee para manejar solicitudes entrantes en máquinas virtuales o físicas de múltiples 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 clúster 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. Tener un mínimo de servidores 2x como se describió anteriormente en un mínimo de 2 zonas de disponibilidad, y si está en AWS, use un ELB que termine HTTPS / SSL en el puerto 443 y se comunique en el puerto HTTP 80 con los servidores de la aplicación 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, así que nginx sigue siendo adecuado y volveré a tratar este tema cuando los WebSockets entren en escena.

Comentarios son bienvenidos.

Answer 3

He visto el equilibrador de carga de 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.

Answer 4

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 puedes 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 cierto soporte para el balanceo de carga HTTPS, pero no para 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.