HA / failover support

[Dave Horton]

Are there any features in node relating to high availability or failover of a server?  I would like to be able to run a cluster of node servers (either physical or virtual) such that if any one dies the others will take over processing, including maintaining the state of running applications on the downed server.  In the simplest case, two servers share a virtual IP and if one fails the other takes over the IP and my node applications keep running on the other server.  Anything like this exist, or in the works?  Or is there alternative "best practice" on achieving this type of reliability?  Does v8 have any features to migrate a running execution context between servers?

[cole gillespie]

I have not seen anything like this currently. Would you also want all of the information from the failed server to fail over as well?

On Thu, Sep 20, 2012 at 9:15 AM, Dave Horton <da...@dchorton.com> wrote:

Are there any features in node relating to high availability or failover of a server?  I would like to be able to run a cluster of node servers (either physical or virtual) such that if any one dies the others will take over processing, including maintaining the state of running applications on the downed server.  In the simplest case, two servers share a virtual IP and if one fails the other takes over the IP and my node applications keep running on the other server.  Anything like this exist, or in the works?  Or is there alternative "best practice" on achieving this type of reliability?  Does v8 have any features to migrate a running execution context between servers?

--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

[Evan]

I wrote a blog post related to this a few weeks ago exploring what can be done from a deployment & uptime POV regarding node [[ http://blog.evantahler.com/production-deployment-with-node-js-clusters ]] 

In a nutshell, you can use the native cluster module to manage a number of workers which handle the processing of requests, can be started/stopped as needed, and can be re-spawned when they die.  You can also do 0 down-time deployments by rolling over your workers as there is new code to load in.  Cluster workers can share ports and open sockets, and requests will be shared between them.

The problem of storing state between failures/deployments is not really a node issue, but if you write to a persistant store (DB, disk, ect), you should be able to recover in the normal way.  Another fun addition node adds is that there is a message passing interface within the cluster module between master and slaves, so you might also investigate keeping a replica of any important data in the master's memory space to seed new children with.  You might want to look more into this if the "state" data moves too fast for redis or a database.  

[Evan]

HARedis looks awesome!   

On Friday, October 5, 2012 12:12:15 PM UTC-7, carlos8f wrote:

A downed server can't communicate, so it's impossible to transfer its state at that point. Thus it's better to have the servers check in with the "global state" frequently (i.e., redis) to prevent data/state loss.

Then what happens when redis master goes down? My solution is to implement high-availability on the redis client level, which enables redis slaves to take over for a downed redis master: https://github.com/carlos8f/haredis

I also developed a suite of modules called Amino (using haredis) which make it easy to create a failover-enabled cluster of node processes: https://github.com/amino/amino With this you don't need the core cluster module. You can have node processes across any number of physical servers, when node processes start up they are automatically added to the service pool, and removed when processes exit / become unavailable. The only configuration each process needs is a list of redis servers to use for global state (master is detected automatically by haredis).

good luck :)