Note that there are some explanatory texts on larger screens.

plurals
  1. POHow to deploy Node.js in cloud for high availability using multi-core, reverse-proxy, and SSL
    primarykey
    data
    text
    <p>I have posted this to ServerFault, but the Node.js community seems tiny there, so I'm hoping this bring more exposure.</p> <p>I have a Node.js (0.4.9) application and am researching how to best deploy and maintain it. I want to run it in the cloud (EC2 or RackSpace) with high availability. The app should run on HTTPS. I'll worry about East/West/EU full-failover later.</p> <p>I have done a lot of reading about keep-alive (Upstart, Forever), multi-core utilities (Fugue, multi-node, Cluster), and proxy/load balancers (node-http-proxy, nginx, Varnish, and Pound). However, I am unsure how to combine the various utilities available to me.</p> <p>I have this setup in mind and need to iron out some questions and get feedback.</p> <ol> <li><strong>Cluster</strong> is the most actively developed and seemingly popular multi-core utility for Node.js, so use that to run 1 node "cluster" per app server on non-privileged port (say 3000). <strong>Q1:</strong> Should <strong>Forever</strong> be used to keep the cluster alive or is that just redundant?</li> <li>Use 1 <strong>nginx</strong> per app server running on port 80, simply reverse proxying to node on port 3000. <strong>Q2:</strong> Would <strong>node-http-proxy</strong> be more suitable for this task even though it doesn't gzip or server static files quickly?</li> <li>Have minimum 2x servers as described above, with an independent server acting as a load balancer across these boxes. Use <strong>Pound</strong> listening 443 to terminate HTTPS and pass HTTP to <strong>Varnish</strong> which would round robin load balance across the IPs of servers above. <strong>Q3:</strong> Should <strong>nginx</strong> be used to do both instead? <strong>Q4:</strong> Should AWS or RackSpace load balancer be considered instead (the latter doesn't terminate HTTPS)</li> </ol> <p><strong>General Questions:</strong></p> <ol> <li>Do you see a need for (2) above at all?</li> <li>Where is the best place to terminate HTTPS?</li> <li>If <strong>WebSockets</strong> are needed in the future, what nginx substitutions would you make?</li> </ol> <p>I'd really like to hear how people are setting up current production environments and which combination of tools they prefer. Much appreciated.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. CONote that Cluster etc. do not provide multi-threading, they simply provide usage of multiple cores through multiple processes. This is entirely different. Note also that Cluster will not provide high availability if your master goes down. The childs will suicide and the master will not respawn. Maybe you can use something like Forever to restart the master. Also, note that Nginx is incapable of routing websocket connections. Finally, "an independent server acting as a load balancer across these boxes": what if this server goes down?
      singulars
    2. CO@Tom, all excellent points. I will update the question to note multi-core usage, not multi-threading, but the former is what I meant. I'd use Monit on each server to watch Cluster's PID and restart it if necessary. I understand nginx's current WS/WSS limitation but don't need that yet. I'd use Monit on the load balancer too, but don't as of yet have a good solution for that single point of failure, short of multiple availability zones (duplicates of this entire setup).
      singulars
    3. CO@ChrisF go talk to the nodejitsu guys in #nodejitsu on freenode. If you want to know about node architecture that's the place to be.
      singulars
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload