Failover Clustering

[cpjitservices]

Hi all,

 

Failover clustering is something I'm looking to setup within our current infrastructure.

 

Having never looked at it before - Ive setup a test bed.

 

I have 2x HP ProLiant ML110's - 4GB RAM 2x XEON Cpus and 2x 500GB hard drives in both machines.

 

iSCSI is setup and working between both servers - hyper-v installed and configured, however in cluster manager if I run validation I get yellow bang marks and cannot continue to create cluster as it fails but doesn't really tell me why it fails.

 

 

Wheres the best place to start ?

 

Thanks all

[Steve21]

You should get a massive HTML report from the validation that goes through all the steps and tells you where validation failed :s

 

Steve

[cpjitservices]

Yes got that

 

Can I post the results ?

[Oaktech]

Perhaps I'm missing something here, but doesn't the storage have to be independent of the servers for failover to work in any meaningful way? If a host fails with DAS, there wouldn't be enough time to shunt 30gb+ of VHD from one to the other without noticeable down time?

[cpjitservices]

Perhaps.. but this is just a test bed to test how it all works ... for my test bed I dont have a SAN to use.

[simpsonj]

I dipped my toe into failover clustering, and backed out of it last week after I realised I had made more points of failure than I'd fixed. This quick guide might put a bit of light on it, but essentially, as @Oaktech says, you definitely need independent storage, as well as multiple NICs on your servers and ideally a vLAN setup to carry just failover traffic between the servers and storage.

 

The ability to Live Migrate from one server to another quickly was good, but you're still dependent on:

 

1, Your storage being accessible 24/7/365 so I would imagine a SAN or similar (rather than just a NAS).

2, Your Hyper-V failover host being up all the time (I believe this can move from one server to another, but I found that a sudden drop of connection and the entire failover cluster would fail)

 

From my personal experience, if I were to attempt this again, I would want to ensure that the storage I used had built in redundancy, that the network I used was segmented away from the rest of the LAN, and that I had three servers in the cluster, rather than just two. One aspect I didn't look at, but would definitely look into now, would be having replication setup, so that one server had copies of all the VMs that the other server was running, which you can only (I think) do with a failover cluster.

[DrCheese]

would be having replication setup, so that one server had copies of all the VMs that the other server was running,

 

You don't need that, if using hyper-V it can detect a failed host & restart the VM's from shared storage on the other host.

[Steve21]

Yes got that

 

Can I post the results ?

 

Sure

 

As others mentioned you'd need a standalone storage, but if you want to test it you could always configure a random 3rd machine with 2012R2 and make it an iscsi target, just to play with in testing

 

Steve

[cpjitservices]

OK, i've setup iscsi on one of the servers and both machines can talk/use the storage so will this not work ? not even for testing ?

[Steve21]

OK, i've setup iscsi on one of the servers and both machines can talk/use the storage so will this not work ? not even for testing ?

 

It depends which way you're trying to test it.

 

If HOST1 (mr Iscsi server) is taken offline, HOST2 won't be able to failover to as it has no storage.

If HOST2 fails, HOST1 (Mr ISCSI server) can failover as it's got access to the storage still so yes you could do that (Unless there's something built in to stop it but don't see why)

 

What's the validation report list as the issue?

 

Steve

[cpjitservices]

There's many many things with the yellow bang mark.

 

Im just figuring out a way to save the Validation report as I have the servers on a separate network without internet access...

 

Ill post it shortly.

[mthomas08]

Been a while since I dealt with this but the storage doesn't have to be independent.

 

At the time (although that word, time* - was seriously limited due to current failures).

 

I setup a cluster for our main data storage, all stored on two servers that replicated to each other and were setup as a cluster as well. Instead of \\server\ it was \\custername\

 

It worked but then there was issues.. as I said I suffered from time limited before I could mass test everything. There was performance issues where things would go slow to the point of freezing up. In the end we used one server as the drives and the second box as a replication in the event of a failure of number 1.

[cpjitservices]

Log attached.

 

failover-clustering-log.txt

[Steve21]

I'll dig through it and have a look but when you say it won't let you proceed is it just greyed out or was there a red/code?

 

Steve

[cpjitservices]

I could proceed, and upon creating cluster id get a message saying it was taking longer than it should to create then it would say cleaning up nodes. Edited February 5, 2016 by cpjitservices

[Steve21]

I'm assuming no AV/Firewall running? Or if it it have ports been opened?

 

What's the event log look like? Other issues can be silly things like DNS/IPs not setup right for it

 

Steve

[cpjitservices]

Both Servers have firewall turned off for the purpose of testing

 

And I shall check the eventlog ... cheers.

[LytchettNM]

Had a quick scan over the logs and found

 

Validate Simultaneous Failover

Description: Validate that disks can fail over simultaneously with data intact.

Validate Simultaneous Failover

Start: 05/02/2016 10:22:50.

No disks were found on which to perform cluster validation tests.

Stop: 05/02/2016 10:22:50.

 

This is a fundamental component of failover clustering that all hosts can communicate with the the storage

plus it also says that the way you have network configured at the moment all traffic is going to pass over the same network which it won't like and will give you warning but should be OK for testing.