Shulou(Shulou.com)06/02 Report--

The previous migration from 2003 to 2008R2 and from 2008R2 to 2012R2 introduced how traditional cluster roles and virtual machine roles migrate across clusters. During the migration process, you can find that whether it is from 2003 to 2008R2 or from 2008R2 to 2012R2, we need to build two clusters, whether it is single node or multi-node. In the end, we want to complete the cross-cluster migration from cluster to cluster. Through the cross-cluster migration wizard that comes with the cluster, we can complete the cross-cluster migration of applications with few operations, achieving downtime when only the old cluster is offline and the new cluster is online.

At WSFC2016, rolling upgrade was introduced, changing the previous migration thinking. Simply put, we can now complete zero downtime migration upgrade in one cluster. We don't need multiple clusters to do cross-cluster migration wizard. We can directly withdraw nodes from 2012R2 cluster, reassemble them into 2016, and then join the cluster. Clusters now implement a mixed mode, allowing both 2012R2 nodes and 2016 nodes in the cluster. For virtual machines and SOFS resources, you can directly migrate from 2012R2 node to 2016 node in the cluster. For virtual machines, you can move them in real time. After the move is completed, you can redo the nodes and join the cluster. Finally, the nodes are upgraded to 2016. As you can see, this method is very good. It is a disruptive thinking. Now we can complete the cluster upgrade in one cluster, and there is no need for offline and online downtime. Unfortunately, only Hyper-V and SOFS can be upgraded through this rolling upgrade; other clustered roles still need to go through the Cross-Cluster Migration Wizard.

In this article, Lao Wang will introduce Hyper-V rolling upgrade for everyone, and put forward the points that need to be paid attention to in practical operation.

Rolling upgrade involves the first new concept, namely ClusterFunctionalLevel. Simply put, it can be understood as a cluster function. The default FunctionalLevel of 2012R2 cluster is 8, which is somewhat similar to the concept of forest level and domain level in the domain. The higher the level, the more functions. The lower level cannot use the functions of the higher level. Therefore, in the first stage of rolling upgrade, all nodes are 2012R2. At this time, the cluster FunctionLevel is 8. Enjoy all cluster functions under Level 8. In the second stage, when the 2016 node joins, the cluster is in mixed mode. At this time, the FunctionLevel will still be 8, because there are still nodes that have not been upgraded to 2016, so the cluster as a whole cannot fully use the new features of the 2016 cluster. In the third stage, all cluster nodes have been upgraded to 2016. You can manually upgrade the cluster FunctionLevel to 9, and fully enjoy the new features of the 2016 cluster.

Technet Rolling Upgrade Operation Flowchart

The rolling upgrade environment is as follows

08dc&iscsi

lan：10.0.0.2 255.0.0.0

iscsi：30.0.0.2 255.0.0.0

12R2 Cluster

HV01

MGMET:10.0.0.9 255.0.0.0 DNS 10.0.0.2

ISCSI：30.0.0.9 255.0.0.0

CLUS：18.0.0.9 255.0.0.0

HV02

MGMET:10.0.0.10 255.0.0.0 DNS 10.0.0.2

ISCSI：30.0.0.10 255.0.0.0

CLUS：18.0.0.10 255.0.0.0

This time, we're going to do a two-point upgrade.

There are currently three VMs running on a 12R2 cluster

Before the production environment starts rolling upgrades, it is recommended that backups be made against clustered databases and clustered applications, and then that the cluster be checked to see if the cluster-aware update CAU role is currently running, and if so, that role be suspended during rolling upgrades

Use the Get-CauRun command to see if the current cluster is running CAU. If it is not running, you will get the following warning, which is normal.

If the CAU is running, you need to pause it using the Stop-CauRun command

Next, we need to carry out rolling upgrade, starting from HV02 node, using maintenance mode to drain all loads above HV02 in real time.

Drain end, HV02 is currently in pause mode, all VMs have been migrated to HV01

After making sure that the node has been cleared of roles, click on the node, check the pause mode node, click on more actions, select evict node, and make sure that we have cleared the node from the cluster.

Now that HV02 has been culled, we'd better drop it directly out of the domain

Shut down and insert the 2016 image, do not use the upgrade installation, but directly use the clean installation method

Configure the NIC, modify the machine name, and rejoin the domain. Lao Wang also selects the same machine name here. You can also re-name the 16 nodes.

After 16 nodes join the domain, Hyper-V roles and failover clustering are installed

Connect shared storage to ensure that and 12R2 nodes can see the same storage

Configure Hyper-V virtual switches to ensure consistency with 12R2 nodes, as live migration is required afterwards

Connect to cluster on 16 nodes

Add nodes to an existing 12R2 cluster

The cluster is currently operating in mixed mode, you can see that HV02 node system is 2016, HV01 node system is 2012R2

Run Get-Cluster on 16 nodes| Select ClusterFunctionalLevel, you can see the current cluster level of 8, i.e. 12R2

Now that we've come to mixed mode, the following things need to be noted when operating clusters in mixed mode

Mixed mode always uses 16 nodes to manage the operations cluster

Hybrid mode should not run for too long, Microsoft recommends hybrid mode for up to four weeks

Do not resize storage space on top of 16 nodes or it may be incompatible when failing over to 12R2 nodes

In hybrid mode, fallback can be selected. If 16 nodes are found to be incompatible with existing applications, it is completely possible to redo 16 nodes and go back to 12R2. It can be directly migrated in real time without downtime.

So far there has been no downtime, now that 16 nodes have joined, we need to move virtual machine resources online from 12R2 nodes to 16 nodes. This operation needs to be performed on 16 nodes!

Follow the same steps to upgrade other nodes

Pause node, drain character

Eviction node

Clean installation of 2016 system

Modify computer name, join domain, configure network, install Hyper-V, failover clustering feature

Configuring Virtual Switches

join the cluster

Move resources back online manually, or move them using a placement strategy.

After HV01 is upgraded, there are two 2016OS nodes in the current cluster.

But run Get-Cluster at this point| Select ClusterFunctionalLevel View Discovery Cluster Level is still 8

Why? According to many people's understanding, since the cluster nodes are now 2016, the cluster functional level should be automatically upgraded to the latest A, but in fact it is not. The reason is that this operation is left to us to decide. It is very simple to update the cluster functional level, but once it is updated, it means that the nodes in the cluster can only have 2016 nodes. After that, there is no way to join the cluster when there are 2012R2 nodes. Upgrading cluster functional level means completely cutting the rolling upgrade process, which means that all nodes of the cluster have been upgraded to 2016 OS. After you are sure that your application can work well on 16OS, you can enjoy the full 2016 cluster function after manually upgrading cluster functional level. Upgrading cluster functional level is no regret medicine, so you must make this decision carefully. The next command is very simple. However, after downloading, the cluster is completely cut to the 2016 level, and there is no way to fall back. The 2012R2 node can no longer be added.

#Upgrade cluster functional level

Update-ClusterFunctionalLevel

You can see that it has been upgraded to the 2016 cluster functional level and is now fully functional with the new features of the 2016 cluster

If you have disabled the cluster CAU function before, you can restart it at this time.

Here we go back and think about why rolling upgrades within a cluster can be done. There are two key innovative technologies.

1.16 nodes can be added to existing 12R2 clusters

2. Virtual machines can be moved online from 12R2 nodes to 16 nodes

First, Lao Wang thinks that the core technology is mixed mode clustering. Microsoft has added a backward compatibility mechanism to the 16 cluster. When we try to add 16 nodes to the 12R2 cluster, 16 nodes detect that the cluster function level is 8, which meets my minimum requirements. I can join in. In mixed mode, help them gradually complete the rolling upgrade, so 16 nodes can join the 12R2 cluster. This is impossible to join the cluster in the previous cross-large version, so Lao Wang thinks that the first point of rolling upgrade is to realize the mixed mode, and this premise can be continued later.

Second, although we have implemented hybrid mode, 16 nodes can join the 12R2 cluster, and things at the cluster level, the key to completing the rolling upgrade is that virtual machines can be directly migrated from 2012R2 nodes to 2016 nodes in real time. This is the function of Hyper-V level, that is to say, to complete the rolling upgrade, not only the cluster level must support hybrid mode, but also the application must be backward compatible to complete the rolling upgrade. Hyper-V 2016 is designed to be compatible with 2012R2 and 2012R2Hype-V. Whether it is through live migration or virtual machine import and export, virtual machines can be moved to run on 2016. From this, we can see that to complete the rolling upgrade, cluster application cooperation is also needed. At present, 16 can only be backward compatible with Hyper-V and SOFS roles. Maybe more applications will be allowed to roll upgrade in the future.

In Hyper-V 2016 we can manually control the configuration level of virtual machines. By default, if a virtual machine is imported and exported to a newer OS or upgraded in-place in a previous version, the configuration file of the virtual machine will be automatically updated to the new version. This changed in 2016. When we moved virtual machines from 2012R2 or imported virtual machines from 2012 R2, by default, does not automatically upgrade its VM profile version, meaning that although the VM is running on 2016, the VM is still configured at 2012R2

This has a benefit, that is, we have one more regret medicine to eat. By default, we have completed the rolling upgrade. The cluster functional level has been upgraded to brand new 2016. 2012R2 nodes cannot join the cluster. However, it does not matter. As long as the virtual machine configuration level has not been upgraded, we can still migrate the virtual machines that have not upgraded the virtual machine configuration level from the 16 clusters back to the standalone Hyper-v2012R2 in real time. This way, if the VM on cluster 16 gets uncomfortable, or if cluster 16 has problems, we can drop the cluster and migrate the VM back to running on 12R2 standalone nodes.

If we choose to upgrade the virtual machine configuration level, then you need to shut down the virtual machine first. After shutdown, you can upgrade its configuration level. After upgrading, the virtual machine can take advantage of the full functions of Hyper-V 2016 and there will be new configuration file formats. However, once the virtual machine configuration is upgraded to the latest 16, you will have no regrets. After the virtual machine configuration is upgraded, you can never move back to 12R2. Here some companies may have virtual machines running some key applications. Migrating the new environment needs to be tested. Lao Wang suggests that this step of upgrading the virtual machine configuration can be done without hurry. After the cluster function is upgraded to the latest, you can observe for 3-4 weeks to ensure that everything can run normally on 16Hyper-v. At this time, you can choose to shut down and upgrade the virtual machine configuration at a suitable time.

First, shut down the virtual machine.

#Upgrade virtual machine configuration level

Update-VMVersion -VMName

#Check node VM configuration level

Get-VM * | Format-Table Name, Version

#Upgrade all virtual machines

#Boot all virtual machines

As you can see, the VM configuration file has changed to VMCX VMRS format instead of xml as it was in 12R2

About 16 Hyper-V new features are described as follows, if you upgrade to 16 you can get all the features mentioned inside, interested friends can see if there are any features worth upgrading

https://docs.microsoft.com/en-us/windows-server/virtualization/hyper-v/deploy/upgrade-virtual-machine-version-in-hyper-v-on-windows-or-windows-server

Scroll to upgrade Adventure Cheats

Guest clusters using share vhdx are not supported using rolling upgrade

SCVMM 2016 can be used with WSFC rolling upgrade function to trigger rolling upgrade operation in VMM console

Rolling upgrades support multiple simultaneous upgrades. For example, you can reinstall cluster nodes by multiple people, but only if you plan to have enough available nodes.

16 nodes must be installed cleanly, do not upgrade!

Mixed mode always uses 16-node management to operate clusters!

At this point, the WSFC migration article ends and the WSFC2016 new feature introduction article begins. Lao Wang plans to deploy migration from three angles, maintenance management, and troubleshooting optimization. I hope that friends who do not know or understand rolling upgrades can bring new thinking and harvest after reading Lao Wang's article.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.