Nic Teaming (or something similar) across multiple servers?

[Sirius]

HI ,

I'm looking to implement a solution where I have two HP servers, I want one of the servers to take over when the other fails , I need to work it so that the server that takes over has the same IP address as the failed one.

Is there a NIC Teaming solution that works across multiple servers?

thanks.

[Torsten.]

This is what each cluster solution does. possible solutions depends on your OS needs - windows, linux, esx, xen, etc ...

[waaronb]

Yup, clustering is what you're talking about, probably.

Windows Server 2012 Hyper-V has "shared nothing" live migrations where you no longer need a cluster storage box as shared storage between 2 or more cluster nodes.  You'd setup the 2 servers as Hyper-V hosts and then your critical resource runs as a virtual server on one of them.  Then you just setup live migration so that virtual guest can fail over to the other node.

There are other considerations there... Hyper-V live migration requires the host machines to be domain-joined, so you need a domain controller or two in there somewhere.

Depending on the type of resource you're hoping to make highly-available, there are other options.  Is it a website or DB server?  You can look at front-end load balancers where client systems hit an IP on the load balancer and then it redirects back-end traffic to one or the other (or balances between multiple live systems).

For DB's you can use any of the MSSQL options (I only know about MSSQL, but Oracle, MySQL, etc have their own things too).  As simple as mirroring which requires a connection string on whatever client device to try the mirror server if the primary fails, or log shipping, the new "Always On" options in SQL 2012 and above, even full blown replication if you have the stomach for it.  None of those let you connect to the same IP address for the DB server irregardless of which back-end is hosting it, unless you wanted to go through some gateway to reach it (like the load balancer with websites...)  They all rely on the client being smart enough to know when to talk to the other server.

There are the NoSQL options out there... Membase, Couchbase... store your data in multiple nodes where the client can talk to any/all of them to get the data it needs.   The nodes replicate data with each other and can fail over as needed.

Or you could go totally low tech.  WAAY back when, the early Compaq Proliant cluster options involved two servers connected to some shared storage box, but one of the servers was started up in a "warm" state with a minimal heartbeat signal between the two systems.  If the primary server failed entirely, it's heartbeat would be lost and the "warm" server would finish powering up, including taking over the storage unit.

It was low tech and involved having a server basically just sitting there, kind of paused during POST, and the OS and data were all installed on that shared drive normally, no local storage.  Expensive, and it would typically only catch an entire hardware failure.

Point being, you could do something like that on a manual basis... have 2 identical systems and if the primary fails, you move the drives to the other system and boot off of it.  :)  Cold spare method.

You could take that cold spare method to the next level with software solutions like Double-Take (I haven't used it in years, but I guess there's still some work done on it).

As you can see, so many options, but you can narrow it down by defining what exact functions you want to make highly available and go from there.