today again a post out of my daily business. When I’m out in the field and I plan a new cluster, I also need to decide how many and what type cluster redundancy I need to implement. For that I have some thing like a blueprint or decision matrix in my mind which I leverage.
Today I want to give you a small view into this matrix. 🙂
When to choose a redundancy where only one or two cluster nodes can fail?
That is the most common and easiest why for node redundancy in a cluster. It means you have enough nodes in your cluster to cover one or two node failures. You would choose that cluster config when all of your nodes are in one datacenter or server room and you have no additional space or need to replicate your virtual machines.
Cluster operating with one storage
Cluster operating with two storages
Hyper-V Hyperconverged with Windows Server 2016
When to choose a redundancy where you can choose half of the nodes?
In this scenario you can lose one half of your nodes but you need to fulfill some more requirements like storage replications or direct WAN links. You would normally use if you want to keep your services alive if one datacenter, server room or blade center fail.
Datacenter redundancy with storage
Redundancy with compute and storage blades
Different locations with Hyperconverged Hyper-V in Windows Server 2016
When to choose replication?
I normally prefer Hyper-V replication only as a warm standby option. That could be an option for example when you want to secure your datacenter and have no storage replication so that you can reboot your virtual machines on other hardware.
Replications is no replacement for a cluster and I would not recommend to replicate databases, exchange server, domain controller or other applications where the vendor officially supports replication.
today I will provide a short checklist what I do after I configured a Microsoft Failover Cluster.
I need to say, the blogpost is inspired by some consultants who think they are so gifted with fucking awesomeness that they can install a (mal)functioning Hyper-V Cluster incl. System Center Virtual Machine Manager with all Components and Software Defined Network in only 6 hours in whole and even don’t know what a VLAN or IP Subnet is.
So than let us start.
We are now on the point that you successfully installed your failover cluster.
- You need to configure the Cluster Quorum and Witness for your cluster. I would suggest you to use the same witness typ like the storage you use. So if you use a SMB File based storage you should use a fileshare witness or even with Server 2016 an Azure Witness. If you use a block storage, you should use a disk witness on the storage your hosting you LUNs with. Mixing up different types of storage and witness in a cluster could sometimes a bit troublemaking. Best Practice is to use disk witness if possible. When you are using fileshare witness never open a fileshare on a Host within you cluster or a virtual machine which is running on the cluster. The could properly result in some issues or even a split brain issue during maintenance or failure scenarios.
- After you configured the quorum, you should configure the communication of your cluster heartbeat. Therefor you can use the following small script.
$Cluster = "<your cluster network name>"
$MGM = "<your management network name>"
(Get-ClusterNetwork "$Cluster").Metric = 100
(Get-ClusterNetwork "$MGM").Metric = 300
Get-Clusternetwork | ft Name, Metric, AutoMetric -AutoSize
- Configure the firewalls of you cluster nodes. NO NOT DISABLE THE FIREWALL, configure it as it is needed for your service. The reason why you shouldn’t disable the firewall is that at first you lose a security layer and open gates for attacks within the network. The second is that some windows services and applications may not function right with disabled firewall.
- Afterwards you need to configure the Active Directory Organizational Unit delegation so that the cluster service can create and change objects within the active directory. That is needed to create cluster aware update or new cluster roles. Delegation of Cluster Machine Accounts with Active Directory
- If you need or wish to configure Kerberos constrained delegation, now is the point to do so for your cluster.
- Configure cluster aware updating for cluster. Starting with Cluster-Aware Updating: Self-Updating
- Configure your backup
- Make Failover tests for all cluster nodes, cluster roles and services and test you backup and the recovery
- Last but not DOCUMENTATION. Document what you have done, so that also your coworkers can see how awesome you are 😉
I hope that helps you a bit in your daily work.
Today I want to show you two ways to move the cluster ressource group and witness to another owner within the cluster. There are some scenarios where that could become necessary e.g. a planned maintenance.
To move the cluster resource is not that easy like moving a cluster shared volume. There is no option “move to best possible node” for the witness.
Cluster shared Volume options
So now there are two ways to move the Witness and cluster resources.
One you cluster node you run following command
Move-ClusterGroup “Your Cluster Name”
2. Failover Cluster Manager Interface
For that you click on your cluster name and navigate on the right action panel to “More Actions”. There you have “Move Core Cluster Ressources”
The Dell TechCenter global published a manuel, which discribes how to install Open Management Server Administrator on a Windows Server OS.
You can download it here.