- Hi everyone, welcome to another episode of OEM TV.
I'm Eric Mills with Microsoft,
I do Windows Server marketing and in this video,
we're gonna talk about cluster OS rolling updates.
You're really gonna like this video if you are,
if you have a cluster, and you're thinking about moving
from 2012 R2, to 2016.
This is definitely some functionality that
you're gonna want to know about.
So Paul is going to take you step by step through
what this looks like and really why you should care.
You should care if you've got that 2012 R2 cluster.
And you want a way to automate the upgrade process.
So Paul's gonna show you what that looks like,
he's gonna talk about the benefits of using this tool
rather than doing everything manually.
He's gonna talk about mixed OS mode,
which is a mode you can get into when you're in the middle
of that transfer and how that's supported.
He's gonna talk about what you need to do
to prepare your cluster to do this upgrade.
So a lot of really good information in this video,
I hope you like it, we'll see you next time on OEM TV.
- [Paul Voiceover] Hello everybody, this is a quick
overview of Windows Server 2016
and the Cluster OS rolling upgrade.
So the first question is, what is it?
It's a new feature of Windows Server 2016.
When I say it's a new feature, it means it's not an add on,
there's no extra cost for it, it is included.
And it enables an administrator to upgrade
the operating system of cluster nodes
from Windows Server 2012 R2 to Windows Server 2016.
It is designed to minimize effort, reduce costs,
and improve application availability
when upgrading a cluster.
So it's really an excellent feature for organizations
that want to upgrade their cluster,
and do it easily, save money and improve the uptime of
the application that's on the cluster.
So some of the benefits.
In organizations of a wide variety of sizes,
they have clusters, and those clusters generally
are there to provide some degree of uptime,
and there may be a Service Level
Agreement associated with that.
So if their system is down for a period of time,
they might suffer penalties from that down time.
Down time penalties against SLA's can be avoided.
And then you can reduce costs also.
So you can use the existing cluster hardware.
You don't have to buy a separate cluster,
so a new cluster is not required.
In the past, you'd have to buy all the hardware,
have that cluster set up,
move the workloads over, on and on.
That's not what's necessary today.
So less planning and actual implementation time
is a benefit as well, under reduced costs.
Because it reduces the man hours
required for the cluster upgrade.
You know if you gotta buy new hardware,
and bring it in and put asset tags on it,
and plan it, plan the cluster upgrade
and do everything that's necessary,
this feature actually saves a lot of time.
And that reduces man hour costs.
And it minimizes the effects of application downtime.
So the cluster itself doesn't
need to be stopped and restarted.
The cluster can stay running,
the applications can stay available,
and some applications will have downtime obviously,
it depends on the application,
but it is minimized significantly.
And then the process can also be automated.
I'll go through the process in a step-by-step manner,
but it can be automated with PowerShell,
Windows Management Instrumentation, and
System Center Virtual Machine Manager 2016.
And one of the keys here is this mixed mode operation.
So that enables patching and testing during the upgrade,
and the cluster can be rolled back if there are issues.
In the past you couldn't do that.
Now we have this mixed OS mode, where the cluster can run
with Windows Server 2012 R2, and also Windows Server 2016.
And there's some scenarios here that we need to call out.
Supported scenarios are Windows Server
2012 R2 Hyper-V clusters,
and then also Widows Server 2012 R2
Scale-out File Server Clusters.
And you can also, like I mentioned, use systems that are
Virtual Machine Manager 2016.
So the unsupported are clusters that are
using Virtual Hard Disks as shared storage.
And some people might do that.
The VHD or VHDX is actually a share of some sort,
for the applications that want to get to data.
And then hardware systems without
the Second Level Address Translation can't run it either.
So there are transition states with this cluster upgrade.
And on the left-hand side you can see
it's a 2012 R2 Failover Cluster
and it only contains 2012 R2 nodes.
And so you would manage that with
a windows server 2012 R2 Failover Cluster manager.
And then once you start the rolling upgrade,
you're now in this mixed OS mode, Failover Cluster.
Where it contains both 2012 R2
and Windows Server 2016 nodes.
So in that case, you have to manage it with
the Windows Server 2016 Failover Cluster manager,
and you can also use PowerShell.
And then when it becomes fully Windows Server 2016,
and it contains only Windows Server 2016 nodes,
then again, you manage it with Windows Server 2016
Failover Cluster manager and PowerShell.
You cannot manage either the mixed OS mode
or the full Windows Server 2016 mode with
the 2012 R2 Failover Cluster manager.
If we look at this, here's a three node cluster.
You want to move the workload, so you have to drain
and evict one of the nodes.
And so you're going to first move the applications
and storage over to another one of the nodes.
And then you go ahead and turn that
into a Windows Server 2016 node.
And then the workload can go back over,
one of the workloads can go back over to Windows Server 2016
but then to do the next node,
you also need to get rid of the workloads and storage
that are on that second node.
And then that one turns into Windows Server 2016
and the workload can come back,
and then get rid of the workloads of Virtue Machines on
the last node that you're updating and update that.
And then the workloads can be redistributed again.
Okay so the process for all this.
The first thing you have to do is prepare the cluster.
So you need to check for sufficient capacity on the cluster
to maintain the high availability SLA's
when one of the cluster nodes is removed from the cluster
for an OS upgrade.
The workloads that are on that first node
that you want to start with the upgrade,
need to be put somewhere.
And there are a couple different situations here.
What if every node in the cluster
is actually maxed out with Virtual Machines?
Well you may want to bring in another piece of hardware
to join that to the cluster and then move the applications
or Virtual Machine or whatever
over to that additional node.
If there's room on the other two,
then you just take those workloads off of the node
that you want to upgrade and put them on
the nodes that have room in the cluster.
And then for Hyper-V workloads, check that all
Windows Server 2016 Hyper-V hosts have CPU support
for Second-Level Address Table or SLAT.
So only SLAT capable machines can use the Hyper-V role
in Windows Server 2016.
So if you've got older hardware, you definitely need to
figure out if you've got, if you're SLAT capable or not,
because it won't work with Windows Server 2016.
And then check that any workload backups are completed
and consider backing up the cluster itself.
So be sure to stop backup operations
while adding nodes to the cluster.
And you need to ensure that the backup operations
aren't going to kick off at some point
during your cluster upgrade.
'Cause that's really gonna mess things up.
And then check that all your cluster nodes are online,
running, up using the Get-ClusterNode command,
you want to make sure that they're all there,
and then check if the Cluster Aware Updates are running.
And if so, disable it.
So you don't want the cluster itself to be updating
in addition to the workloads and the Virtual Machine.
You need to make sure that the systems are really stable
before you do this.
And then continuing the process, there's node actions.
So in the cluster manager, you select a node
and use pause drain to drain the nodes.
You want to drain that cluster node of all of it's workload
and then you evict the node that
you just drained from the cluster.
So you've got a node that has no workloads on it,
it's not doing anything for the cluster,
and then you just evict the node
until it's now separate from the cluster.
You then reformat the drive that you're gonna install
Windows Server 2016 on, and then install Windows Server 2016
with a clean operating system installation.
And it's got to be a new install.
It can't be an upgraded install, that'll cause problems.
Now after installation, add the node to the appropriate
Active Directory domain, so you gotta join the domain.
And then add users to the administrator's group,
and then install the Windows Feature Powershell cmdlet.
So you want the, the latest
PowerShell features installed on that system.
And then install the server roles for your cluster,
whether that's Hyper-V, or other roles that you may have
that server running as.
And then install the Failover clustering feature,
and then install any additional features, workloads and data
needed by your cluster workloads.
And then continuing with the process,
now there's cluster actions,
there's things you have to do on the clusters.
So you started with things on the clusters,
then you had to do things on the node,
and now you've got some more cluster actions.
From the Failover Cluster Manager, check the network
and storage connectivity settings, make sure that you have
all the same ones for your cluster.
And if Windows Firewall is used,
check that the firewall settings
are correct for the cluster.
They should uniform across the cluster,
and then for Hyper-V workload, use Hyper-V manager
to verify the names of the virtual switches are identical
to all Hyper-V nodes in the cluster.
You should see all the same virtual switches
in the virtual switch manager.
And then on Windows Server 2016 node,
remember not a 2012 node, use the Failover Cluster manager
to connect the node to the cluster.
So now that cluster is in mixed OS mode, right,
you've got 2012 R2 and you've got one, or more 2016.
The mixed OS mode is meant to be
a transitional mode and not permanent.
Though it's great to leave it there for some period of time
where you can do testing and make sure everything works
before you upgrade the next node, I mean that's prudent.
But the clusters are expected
to be updated within four weeks.
And then move workloads as appropriate
to include the new cluster nodes.
Some of the workloads that you moved in the beginning
to get them off of that cluster node,
they need to be moved back,
and maybe some other workloads need to be moved there
as well so you can upgrade another one of the nodes.
And then once the cluster is completely updated
to Windows Server 2016, verify all the cluster nodes
are running and update the cluster functional level.
And then that's it.
For what it's accomplishing,
compared how clusters were upgraded in the past,
it's an easy process.
So once again, here's what it looks like.
You move that first workload,
drain and evict that node, and then update it.
And now you're in Mixed OS mode.
And then you move the other workloads
from another node, upgrade that node,
and then move a workload back.
Go to the last node, get the workloads off of there,
upgrade that node, redistribute the workloads,
and there you are.
You've got a complete new Windows Server 2016 cluster.
So, summary.
It's a new feature in Windows Server 2016.
It enables easy cluster upgrade
from Windows Server 2012 R2 to Windows Server 2016.
And it's for Hyper-V and Scale-Out file systems.
And it's enabled really by this
mixed OS management capability in Windows Server 2016.
Without that mixed mode management,
it'd be really hard to do.
And it can be automated with
System Center Virtual Machine manager and PowerShell.