>> Today, we're going to cover how you can run clustered or
distributed applications on Azure with shared disks.
My name is Vybava Ramadoss,
and I'm a Program Manager on the Azure Disks team.
The agenda for today;
we're going to cover a quick overview of the Azure Disk portfolio,
and then we're going to cover a couple of
workload considerations for top workloads
running on Azure Shared Disks,
and then look at a demo of Windows Server Failover Cluster.
Azure Disks offers the best persistent performance block storage
for both Azure Virtual Machines
as well as container-based applications.
Azure Disks are the fastest virtual disks in the public Cloud.
With a single Ultra Disk,
you can get up to 160,000 IOPS,
and two gigabytes per second.
Next, Azure Disks offer
an industry-leading zero percent AFR guarantee.
What this means is that we never lose customer data.
How we ensure this is by making
three consistent copies of
all the data that's written to our platform.
Next, we offer an industry-leading single-instance SLA
for disks that are backed by SSDs.
This includes the Standard SSD,
Premium SSD, as well as Ultra Disk.
Last but not least,
we offer a flexible architecture that
enables you to control both IOPS and
bandwidth off the disk independent of the size of the disk.
This is offered on
our Ultra Disk platform and will be enabled on Premium SSD.
If you look at the Azure Disk portfolio,
we have four different types of disks.
On the left, you see standard HDD,
which is backed by magnetic drives.
Standard SSD, which is the lowest cost SSD offering in the market.
Premium SSD, which is our default option
for database and high I/O workloads.
Last but not least, Ultra Disk,
where you can get sub-millisecond latency for
very high IOPS and throughput applications.
Standard HDD is perfect for backup of low-cost storage.
Standard SSD is great for
low I/O workloads that require consistent latency,
for example web servers.
Premium SSD is great for high IOPS workloads like databases,
so think SQL, MySQL applications.
Ultra Disk is perfectly suited for
your tier 1 applications that require
extremely low sub-millisecond latency, like SAP HANA.
Now let's jump to Azure Shared Disks.
Azure Shared Disks enables you to mount
a single underlying disk to
multiple nodes or multiple virtual machines on Azure.
This is perfect for clustered databases,
parallel file system, as well as container volumes.
Azure Shared Disk is the only offering in the industry which
allows you to do both Linux and
Windows-based clustering in the public Cloud.
How we do this is by supporting SCSI-3 Persistent Reservations.
Shared disks is enabled both on Ultra Disk as well as Premium SSD.
On the Windows side, we support a number of different applications
including SQL Server Failover Cluster Instances,
Scale-Out File Servers, as well as SAP Application Servers.
On the Linux side, you can use your distribution of choice,
whether that's a Ubuntu,
Red Hat, or SUSE.
You can run both active-passive as well as
active-active workloads like distributed file systems, like GFS2.
Please note that with our GA,
we're removing a number of restrictions we had a preview.
Number 1, you no longer have to use a PPG,
you can choose a PPG or non-PPG option.
Number 2, we support FD or fault domain greater than
one options for both AvSet and Virtual Machines Scale Sets.
Last but not least, we rolled out to
a number of regions across the globe.
Now, let's look at a couple of typical scenarios.
Number 1, failover clusters.
In this scenario, there are two nodes at a minimum.
There's one node which is the primary,
and another node that's the secondary.
The primary is the node that is reading and writing to the disk.
The secondary virtual machine,
it's really waiting in anticipation for a point where it may
need to take over in case
the primary node loses access to the disk.
Really, there's only one virtual machine
that's active at one point in time.
Our second scenario is when there's
more than one virtual machine using the disk at the same time.
This can be in the form of write once, read many,
which you see in the diagram in front of you,
where the first virtual machine is writing to the disk and
the other virtual machines are reading off of the disk.
You could also enable
a multi-write scenario where
multiple nodes are accessing the disk at the same time.
Just note that the application must be
able to write order in case you do that.
Now let's look at different workload considerations
and Azure Shared Disk recommendations.
First up, we have SQL Server FCI
running on Windows Server Failover Cluster.
If you're running SQL Server FCI on-premises,
this offers a simple way
to lift and shift your application to Azure.
We support versions starting from
Windows Server and SQL Server 2008 and above.
Now when using Azure Shared Disk,
please note that Azure BlobCache is not available.
As well as if you're planning on striping disks,
ensure that you're using
the right Windows Server version that supports this.
Next up, our recommendations around
splitting log disk and data disk remain the same.
Whether you use shared disks and SQL Server FCI,
ensure that you actually split these to optimize performance.
Next up, let's look at SAP Application Servers.
SAP Application Servers consists
of a number of different components,
including the central services, message server,
enqueue server, and the host files
that are saved on the shared disk.
Now with SAP Application Servers,
we have both single and multi-SID options that are supported,
as well as ERS1 and ERS2.
Note that SAP Application Servers can be
deployed in a heterogeneous environment.
The actual SAP HANA database could be running in
a Linux environment while
these application servers are running on the Windows environment.
Next up, we recommend the use of
application servers running on Availability Set,
as well as PPGs for lowest latency.
Next, we also recommend using Windows Server 2019.
Next up, let's look at clustering on Linux.
In addition to being able to use your distribution of choice,
you also need to think about fencing options.
Here you have two options including
SCSI Persistent Reservations as well as SBD-based fencing.
Now, with SCSI Persistent Reservations,
you can use a utility called sg_persist,
which really simplifies your ability
to test SCSI Persistent Reservations to the disk.
Also remember that you will need
a cluster management layer with either Corosync for messaging,
as well as Pacemaker as a resource manager.
This is required whether you're setting up
an active-active or active-passive configurations.
If you're setting up as an active-active environment,
ensure that you also have a Distributed Lock Manager that
ensures that there is arbitrated access to the disk.
This is great for distributed file systems like GFS2.
Now let's look at Azure Shared Disk on containers.
On the Azure Disk drivers for Kubernetes,
we've enabled Azure Shared Disk to be usable as
ReadWriteMany volumes which are raw block devices.
This is specified as part of the storage class definition.
Next up, ensure that in the pod spec
that you provide a devicePath instead of a mountPath,
because a container will expect to see
a device rather than a mounted file system.
Last but not least, since it's ReadWriteMany volumes,
ensure that the application is able to write order.
Now, let's look at a quick demo of
Windows Server Failover Cluster on Azure Shared Disk.
What you see in front of you is
a Scale-Out File Server that is deployed
on top of Windows Server Failover Cluster
running on Azure Shared Disks.
Here you see that the Scale-Out File Server is actually set
up to be running with two nodes.
Here you see node 1,
which is shared volume 1,
and shared volume 2 is node 2.
Now let's look at the storage.
On the storage side, we actually see two sets of volumes,
which are the cluster disk 1 and clustered disk 2.
Now, cluster disk 2 was the actual data volume,
which is the clustered shared volume,
while cluster disk 1 is more of a disk witness,
that is hold the information about the cluster itself.
Both of these disks are mounted to both the VMs in the cluster.
Note here that the owner VM is marked as shared VM1.
What we're going to do next is simulate a failover.
Here, what we do is we drain shared VM1 to see what happens.
Draining this simulates a failover,
and so shared VM2 becomes the primary.
As you see for the Scale-Out File Server,
the owner node is now shared VM2.
What we also see is the owner node of
the cluster volumes is also shared VM2.
Now that we've seen how this looks
like in Windows Server Failover Cluster itself,
let us look at a quick example in
PowerShell on how to actually deploy this environment.
Now as you see in front of you,
the create disk and attach disk
PowerShell is similar to how you
would create and attach a disk today.
The only added property is maxShares.
MaxShares defines the number of
maximum virtual machines that can mount the same underlying disk.
Setting a value for maxShares is greater than one,
indicates that it's a shared disk.
In this scenario, maxShares 2 means
a maximum of two nodes can mount this disk.
Everything else remains the same.
Now once you actually deployed the disks,
then you can trigger the SCSI Persistent Reservations commands.
In this scenario, you see
that there's a number of different commands,
both PRO and PRI.
If you trigger a PR Reserve command,
then also ensure that you provide a reservation type.
In this example, the node that is asking
for the reservation is asking for a write exclusive access,
meaning that no other node should be able to write to this disk.
You can look at the full list of commands in the links provided.
Next up, let's look at a couple of considerations.
Number 1, shared disk is available on Premium and Ultra Disk only.
Number 2, shared disk can only be used as
data disk and not operating system disks.
Number 3, on Premium SSD,
ensure that you use sizes P15 and above,
and the number of maximum mounts that you can
set are defined by the disk size.
Next, there is a price which is
a flat fee per mount based on the disk size.
On Ultra Disk, there are
no size limitations as well
as the number of maximum mounts is five.
To learn more, please check out our website at aka.ms/AzureDisks.
We would love to get your feedback on Azure Backup,
ASR, and migration integration with Azure Shared Disk.
Please use the links specified to provide feedback.
Last but not least, as usual,
if you want to reach out to us for questions, queries,
or feedback, please reach out to AzureDisks@Microsoft.com.
With that, thank you so much for your time,
and we hope to see you again in our next skilling video.
[MUSIC]