Clustering in Windows has always been a bit of a mixed bag. The functionality was there, and it made a big leap forward in Windows Server 2008 in terms of configuration ease and reliability, but it always seemed fragile to administer because of dependencies and limitations.
Microsoft worked in Windows Server 2012 to
Support for read-only domain controllers: In Windows Server 2008 and Windows Server 2008 R2, you couldn't use read-only domain controllers (RODCs) in branch offices because the clustering service and nodes used Active Directory objects to store and change information about their state. This called for write access to the domain controller. But at some branch offices, there may be no communication with a writeable DC, thus preventing a cluster from operating. Microsoft removed this limitation in Windows Server 2012, so you can safely and securely deploy RODCs in branch offices and still be able to support a Windows cluster at that location.
Anyone who pays for a 2012 license can access clustering features previously reserved for licensees of the advanced edition.
To deploy RDOCs, you need to prepopulate the cluster information to Active Directory via a standard, read-write domain controller. The information can then be replicated down to a read-only domain controller. You may need access to a read-write domain controller if you want to rename a cluster after it already exists.
Clustering functionality is now available in Windows Server 2012 Standard: Because Microsoft did away with the Enterprise edition SKU in this operating system version, anyone who pays for a 2012 license can access clustering features previously reserved for licensees of the advanced edition. This makes failover clustering an option for a wider net of shops.
The cluster no longer needs access to Active Directory (AD) in order to bootstrap itself: A huge problem with clustering in the past, which would also become a chicken-egg problem when you added in Hyper-V virtualization, was the dependency on AD access. If a cluster tried to boot itself up and nodes tried to come online without access to virtual computer objects stored in AD, the whole enchilada would fall over. This is no longer the case in Windows Server 2012 because the cluster node that completes its boot process first initializes the cluster and gains quorum without talking to a domain controller. Once that node gains quorum, the rest of the nodes can come online without any problems. These improvements occur within the clustering service itself, so you don't have to extend the Active Directory schema or change your forest or domain functional levels.
The new cluster-aware updating feature takes the murky science out of patching cluster hosts and nodes: In the past, patching nodes on a cluster in production was a recipe for disaster. If you brought the wrong one down for updates at the wrong time, there was nothing graceful about it. As a result, clusters were consistently the least up-to-date and sometimes the most vulnerable to security problems. In Windows Server 2012, there is a new cluster update mode that works with Windows Update, the Microsoft-hosted service, or Windows Server Update Services, the locally installed network-wide update repository and distribution service. The administrator initiates the Cluster-Aware Update Wizard either through the GUI or a PowerShell command, which moves virtual machines on cluster nodes to another host one at a time via quick or live migration. Then it patches the node, reboots if necessary and brings all virtual machine guests back to the correct node once the update is complete. It repeats the process until all host nodes have been updated. Throw your complicated scripts away with this new update mode feature.
ABOUT THE AUTHOR
Jonathan Hassell is an author, consultant and speaker residing in Charlotte, N.C. Jonathan's books include RADIUS, Hardening Windows and Windows Vista: Beyond the Manual.
This was first published in October 2012