Failover Cluster Manager showing wrong interface for node

failoverhyper-vnetworkingwindows-clusterwindows-server-2012-r2

I have a 2 node 2012 R2 Hyper-V setup that i am trying to configure Hyper-V HA. The network setup for both nodes are as follows:

Total: (8 x Ports):

4 x Adapters – (Teamed:Production/VM external access) @ 3 x 1Gbps and 1 x 10Gbps

Teaming Mode: Switch Independent

Load balancing mode: Dynamic

Stanby adapter: None (All adapters active)

Network: 192.168.100.x

2 x Adapters – iSCSI (MPIO) @ 10Gbps

Network: 192.168.115.x

1 x Adapters – Cluster (Managment,VM Migration and replication) @ 10Gbps

Network: 192.168.100.x

1 x Adapters – Phone Network @ 1Gbps

Network: 192.168.104.x

The problem is that the failover and cluster manager (FCM) is selecting the Production network for one node and the cluster for the other. I want the cluster network to be dedicated for managing the hyper-v, migrations and replication.

I have configured the adapter order on the nodes as follows:

vEthernet (vSwitch_Production)

Team_Production

NIC1 – Production

NIC2 – Production

NIC3 – Production

NIC4 – Production

NIC5 – Cluster

NIC6 – iSCSI

NIC7 – iSCSI

NIC8 – Phone

Can anyone please comment as to if this network setup will work with Hyper-V HA and, how I can ensure the correct adapters are selected by FCM?

Best Answer

Launch FCM, specify a required cluster and go Networks. Then select the network you want to modify settings for and click Properties. This way you can allow or forbid cluster/client communication on certain networks. You can also manually configure live migration channels over there.

More recommendations on how to isolate network traffic on Hyper-V cluster can be found here: https://technet.microsoft.com/en-us/library/dn550728(v=ws.11).aspx

As for your projected network design, it looks reasonable to me. But still refer to this article to learn more about different approaches to networking setup on Failover Cluster with Hyper-V: http://www.dell.com/support/article/us/en/19/SLN268062/EN

Related Solutions

RPC Server Unavailable on Hyper-V cluster when moving resources after the host adapter has failed

Great question!

The most likely reason for the RPC failure is that the cluster name resource (and IP address) were likely hosted on the server whose primary network connection was flapping.

Since the interface was going up and down, access to the cluster via the cluster name would likely fail due to the network interruptions.

You should be able to execute commands against the cluster from the command line (either cluster.exe or the FailoverClusters module in PowerShell). The FailOverClusters module can be used over PowerShell remoting if the appropriate credential delegation is configured (either CredSSP or Kerberos).

In the case of a failure of the network interface hosting the cluster name, you could use PowerShell to move that cluster group to one of the nodes that is accessible, or you could just execute commands against the cluster to migrate machines, etc..

To ensure that this does not happen again, you likely will need to make the NIC highly available (NIC teaming). This is dependent on where you are managing the cluster from.. one of the servers or a remote management station. If you are managing from a cluster machine in that same cluster, you could add an IP on the cluster network to the cluster name, but you would want to make sure that was not added to DNS, otherwise you might interrupt remote management clients from being able to connect.

To add an IP Address to the cluster group via PowerShell -

$Resource = Add-ClusterResource -Name SecondaryIP -ResourceType "IP Address" -Group 'Cluster Group' 
$Resource | Set-ClusterParameter -Name 'Address' -Value 'Your-IP-Here'
$Resource | Set-ClusterParameter -Name 'SubnetMask' -Value 'Your-SubnetMask-Here'

You'll need to disable dynamic dns registration and create static entries if you don't want remote management clients trying to talk to the private network.

How to speed up automatic failover of a Hyper-V 2012 cluster

In retrospect, I guess I should've known. The answer is in two parts, because, in my mind, there's planned failover and "real"/unplanned failover---and planned failover doesn't count.

Planned failover

Planned failover is actually just the Clustering system draining the node, then rebooting it for you. So when you directly reboot the node via RDP or "Stop Cluster Service" in the Clustering app's GUI, the first thing that happens is the VMs get Live Migrated off. Because you're really just Live Migrating the VMs, the time it takes is dependent on what needs to be transfered, and the network connection. If you have a 1Gb NIC, it's going to take a while (~118MB/sec). The more RAM your VMs have, the better served you will be by faster NICs.

Real failover

Unplanned/"Real" failover is when you unplug the machine. In that case, the cluster system automatically starts the VM up on another node. The behavior to the outside world is the same as if you'd rebooted the VM. To the VM, it's the same as if you'd "turned it off" then started it again. So a "real" failover is always going to be about how long it takes your VMs to boot.

Tangent

This is a let-down to me, conceptually, because I feel like all the clustering talk on the 'Net suggests that a ("hard") node failure is hidden by the clustering system---it's supposed to be like the services never went down. It's likely propagated by the fact that all the web pages I remember reading tested their cluster failover in software (planned failover). So all they're really doing is proving that Live Migration works as advertised (no downtime from the perspective of the client).

My main mistake was misunderstanding failover itself. In addition to the concept of having a hot/warm/cold backup server, where automatic failover occurs on a hot server, there is also hot/warm/cold failover. As mentioned here, hot failover is instant, warm failover is measured in seconds, and cold failover is measured in minutes. I was naive to assume that all automatic failure is "hot". I guess I was expecting some sort of magic with the RAM where the cluster would update a copy of the VM's RAM on another node---something like transaction log shipping with Sql Server. But that would require a communication channel between machines that is at least as fast as RAM to guarantee it would work.