The essential guide to Microsoft Windows Server 2016
A comprehensive collection of articles, videos and more, hand-picked by our editors
Mission critical workloads running in a Windows Server environment are almost always clustered. The workload might...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
be running on top of a clustered Hyper-V deployment, a hardware-based failover cluster or even a guest cluster. All of these commonly used forms of clustering are based on the Failover Clustering Service.
Failover clustering has always presented a special challenge with regard to operating system (OS) upgrades. Failover clusters prevent a mission-critical workload from going offline during a hardware failure. Even so, the process of upgrading cluster nodes -- the Windows servers that make up the cluster -- to a newer Windows version has typically resulted in some downtime for the clustered workloads. Some administrators will build a new cluster and migrate workloads instead, but this approach requires extra hardware resources and comes with its own challenges. This is where rolling upgrades come in.
In Windows Server 2016, rolling cluster upgrade support will make it possible to upgrade existing Windows Server clusters to Windows Server 2016 without downtime.
Functionally, cluster OS rolling upgrades are very similar to Active Directory upgrades. Imagine an organization has an Active Directory forest based on domain controllers running Windows Server 2008 R2 and wants to upgrade its domain controllers to Windows Server 2012 R2. This upgrade does not require taking the Active Directory offline or rebuilding it from scratch. Instead, Microsoft makes it possible to blend the old with the new.
An administrator would upgrade Active Directory by upgrading one domain controller at a time to the new OS, perhaps also adding a few new domain controllers in the process. This workflow keeps the Active Directory functional throughout the entire upgrade because there is never more than one domain controller offline at a time.
It is possible to upgrade Active Directory this way because the new Windows Server OS -- in this case, Windows Server 2012 R2 -- is backward compatible with the existing OS, Windows Server 2008 R2. Once all the domain controllers have been upgraded, the Active Directory is technically running on Windows Server 2012 R2, but still behaves as if it is running on Windows Server 2008 R2. This is due to the use of functional levels. Functional levels essentially tell the domain controllers to act as if they were running a specific OS. If all the domain controllers were running Windows Server 2012 R2, but the domain and forest functional levels were set to Windows Server 2008 R2, then Active Directory would behave as if it were running on Windows Server 2008 R2 servers. None of the new features that were introduced after Windows Server 2008 R2 would be used, and it would continue to be possible to join Windows Server 2008 R2 domain controllers to the domain. Active Directory only behaves as though it is running on Windows Server 2012 R2 after the administrator raises the functional level.
Microsoft applies this approach to cluster upgrades in Windows Server 2016. Microsoft allows administrators to upgrade cluster nodes one by one, until all of the nodes are running the new OS. Even up to this point, the upgrade process is reversible. If the administrator decides to back away from using Windows Server 2016, they can revert to previously used OS.
The upgrade becomes permanent if the administrator raises the cluster functional level. Just as the forest functional level and the domain functional level settings determine the behavior of supported OSes for domain controllers, the cluster functional level tells Windows whether the cluster should behave as a native Windows Server 2016 cluster or as a legacy Windows Server cluster.
Currently, there are a number of restrictions and limitations to rolling cluster upgrades that may change when Windows Server 2016 is officially released. Some of the more significant restrictions include:
- The cluster being upgraded must be running Windows Server 2012 R2.
- In-place upgrades of cluster nodes are not supported. A clean installation of Windows Server 2016 is required.
- All cluster level management actions, including adding nodes to the cluster, must be performed using the Windows Server 2016 management tools.
Microsoft recommends that you avoid reconfiguring storage or adding storage to a mixed-mode cluster because of lingering compatibility issues.
Solve failover cluster headaches in Windows Server 2012
Changes to clustering in Windows Server 2012
Weighing a Windows Server 2016 upgrade