(pleasant upbeat music)
- Hey, everyone, I'm Adarsh.
I'm a Product Manager at Microsoft
and I'm here to
show you this skilling video.
Welcome to getting started with Azure Elastic SAN.
The goal of this session is to explain exactly
what Azure Elastic SAN is and how to provision one.
Azure Elastic SAN is the industry's first
fully managed storage area network offering in the cloud.
Combining SAN-like capabilities
with the benefits of being a cloud native service,
Azure Elastic SAN offers a scalable, cost-effective,
high performance and reliable storage solution.
It can connect to a variety of Azure compute services
enabling customers to seamlessly lift
and shift their SAN workloads to the cloud without having
to change their provisioning and management model.
Azure Elastic SAN offers the following features:
competitive TCO, which is Total Cost of Operations,
and dynamic resource sharing.
This enables you to make a bulk purchase
of storage capacity and provision performance at a low cost.
Azure Elastic SAN offers the flexibility
to scale storage capacity incrementally as needed,
to provision capacity and performance independently,
and to share the already provisioned performance
across volumes.
By leveraging the economies of scale
and resource pooling of Elastic SAN,
you can account for peak traffic
without needing to over provision,
which results in a more cost-effective solution.
Secondly, we offer a consolidated storage experience
for different compute options.
You can connect to Elastic SAN
from Azure virtual machines, containers, et cetera,
using the industry standard iSCSI protocol.
The consolidated experience also makes management easier.
Network configurations are set at the volume group level,
but they apply to all the volumes within that group.
And as you can see on the slides here,
you have the hierarchy being the Elastic SAN
under which we have volume groups,
which we can opt up to 20,
and then you have volumes underneath that.
So there can be up to 1,000 volumes per volume group.
So we provide a simplified volume management experience
through grouping and policy enforcement.
Third, we offer higher performance and scale.
This allows you to improve IOPS
and throughput across virtual machines and storage.
Built on top of our distributed storage platform,
you can scale up to millions of IOPS
and double digit GB-per-second throughput,
all while maintaining latency in the low milliseconds.
And finally, we have the most resilient
and highly available storage
with Zonal Redundant Storage, which is ZRS.
Azure Elastic SAN leverages the work of ZRS
and LRS, which is Locally Redundant Storage,
to provide high availability without having
to set up multiple deployments of SAN arrays
and a replication policy.
With ZRS, you get synchronous replication
across three zones in a region
and safeguard your data in the event of a zone failure.
So I'm going to talk to you guys
about some of the high-level benefits
and use cases that Elastic SAN will provide.
Number one, consolidate your storage
and achieve cost efficiency at scale.
Since Elastic SAN lets you share
the provision performance across volumes,
you can easily achieve higher performance.
For example, you can deploy 100 terabytes SAN,
which would give you 500,000 IOPS.
This could be shared across 101 terabyte volumes
where each volume can hit a maximum of 64,000 IOPS.
The larger SAN pool you have,
the more efficiency you will gain
by sharing a large provision performance pool.
And if your workloads require more storage,
at a later date,
Azure Elastic SAN offers capacity units
that provide only storage.
So if you need an extra 20 terabytes,
you can purchase just that at a significantly lower price
than if you had to purchase more performance along with it.
Secondly, we allow you to integrate
with your choice of compute options.
Azure, Elastic SAN can connect
to a variety of Azure compute options.
So it can be used when you are running workloads
on non-virtual machine based environments as well.
This enables you to lift and shift
your SAN workloads to the cloud
with the choice of whichever compute option
best suits your needs.
And finally, we drive higher storage throughput
over network attached storage.
When you have a workload that requires high throughput
you might run into the limits
of the disc throughput on your VM.
For example,
say you're using a standard E104 IS V5 VM
which is capped at 120,000 IOPS and 4,000 Mbps.
But for your quarter end reporting, you may need very
high throughput to complete the data processing in time.
With Azure Elastic SAN, you can drive throughput
over the VM network bandwidth, which is not limited
on IOPS and where your throughput can go up
to as high as 12,500 MBps.
Now, we'll take a look at a customer
for whom Azure Elastic SAN will be useful.
Meet John.
John is a storage administrator who wants a highly available
and scalable block storage solution for his workloads.
He wants to explore Azure Elastic SAN
as a solution for his needs.
His goal is to provision an Elastic SAN
with sufficient size and performance
to meet his workload and storage requirements.
To accomplish his goal,
he must plan for his required capacity and performance
and provision an Elastic SAN which matches those needs.
He must then connect a volume
to the VM to make use of the SAN.
He can then scale up the size
of an Elastic SAN and its volumes as needed.
This flexibility is what differentiates
Azure Elastic SAN from other options.
I'll now walk you guys through
the creation workflow for Elastic SAN.
So you have here the creation workflow.
So you start off by creating the SAN.
You have the Elastic SAN, the volume group,
and volumes, as mentioned before,
in terms of resource hierarchy.
Resources are provisioned on the SAN level.
So in filling out this information
you need to think about exactly what kind
of workloads you want to host on the SAN
and figure out the respective capacity
and performance requirements.
If you want more performance,
you should provision more base capacity.
If you want more storage,
you can provision just additional capacity.
The provision performances of the SAN will be shared
across all the volumes deployed.
If your application requires resiliency
against zone level failures, you should select ZRS over LRS.
ZRS provides higher availability than LRS does
as it replicates across three Azure
availability zones in the selected regions.
After filling out all the necessary fields
and making well considered selections
you can then create volume groups.
Volume groups are management constructs for volumes.
All the encryption, network security settings,
et cetera, will be set at the volume group level
and will correspondingly apply
to all the volumes under a volume group.
This allows for easier management of volumes overall.
There can be 20 volume groups to an Elastic SAN.
One additional thing to note is
that the volume group name cannot be changed after creation.
After naming the volume group,
you can then create volumes.
Here, you need to enter the volume group
that the volume will belong to,
as well as the size of the volume in gigabytes.
The larger the volume size that's provisioned
the more performance the volume will have up to the limits,
which you can find in our documentation.
Provisioning more storage directly relates
to more performance
at the volume level.
After completing all these steps,
you'll have an instance
of a SAN, a volume group, and a volume.
I'll now show you guys a demo of how exactly to do this.
We start off by entering the values
of the parameters as objects.
As you can see, we're deploying in South Central US stage.
We've got a base size of 100 and an extended size of 50.
Your skew tier is premium.
So now we are actually provisioning the Elastic SAN
with the parameters filled in,
the required parameters filled in
with these objects that we created just now.
So we've got the resource group name, the name,
the base size, the extended size, location,
Sku name, and Sku tier.
And now we're just waiting for it to provision.
And here you have it.
So as you can see, it's successfully provisioned
and the base size as mentioned before is 100
and the extended capacity size is 50.
So we're now going to provision the volume groups.
As you can see, we've got the resource group name,
the Elastic SAN name, and the volume group name,
and we're waiting for it to provision.
And there you have it.
As you can see, we have the encryption type
as encryption at rest with platform key,
protocol type is iSCSI,
and we have the volume ID ready as well.
There are no network ACLs set up yet.
We'll be covering that pretty soon.
Now we move on to provisioning a volume.
So same parameters as you'd expect,
you have the resource group name, the SAN name
the volume group name, as well
as the volume name and the size in gigabytes.
So now we just wait for it to finish provisioning.
There we go.
So as you can see, we have the size in gigabytes
as well as number of other
parameters that we'll need to use
in future in the future, and I'll explain exactly what
we'll do with them in future demos.
So yep, there you have it.
You've got yourself a San, a volume group, and a volume.
And now I'll move on to how to set up vNets.
So setting up vNet ACLs.
Here's the flow.
You select the vNet,
enable the Microsoft storage endpoint,
you create a new network rule,
and then you update the volume group
with this new network rule.
There you have it.
The vNet ACLs are configured.
You can do this both while creating a volume group
and while updating a volume group.
But in the demo that I'll be showing you soon
we're just going to be doing it in the update flow.
Why we need vNet ACLs.
Access to volumes is restricted
by virtual network access rules.
By default, data access from any client's to volumes
under a newly constructed volume group is blocked.
vNet ACLS are what you'll use to control data access
to the volumes in a volume group.
First, you need to enable the microsoft.storage
service endpoint in the vNet that you plan to grant access
to the volume group.
Next, you add the vNet rules
that you want to add to the volume group.
And then finally, you need to make sure
that the VM that you wish to connect is
on one of the vNets that you have added as a vNet rule.
So now I'll show you guys how to do this.
So first, we're going to set
up the microsoft.storage service endpoint.
So as you can see,
we're on the page of the vNet that we wish to connect.
So we move to the subnet,
we're on default.
And then you go to service endpoints,
you select microsoft.storage,
and there you have it.
It succeeded.
So the microsoft.storage service endpoint has
now been enabled.
After this, we go to PowerShell
and we'll be running a new network rule
object command with the resource ID parameter filled in.
So now we go back to PowerShell
and we run the new network rule object command
with the resource ID being the ID
of the subnet that we just enabled this storage endpoint in.
And the action is allow.
And we bind that to these
to this object called virtual network rule one.
We then run the update
Azure Elastic SAN volume group command
with the network ACLs
parameter being filled in
with this object that we have just bound.
So after this is succeeded,
we will see that there is a network ACLs section
in the parameter list that has been filled.
And there you have it.
The network ACLs virtual network rule parameter
has been filled with the resource ID
of the vNet and subnet that we set up.
So there you have it.
That's how you set up your vNet ACLs.
Moving on to connect.
So this is the connect workflow.
This is what you'll need to actually
connect your volume to the target.
To read and write to the volume you have provisioned,
you need to connect the volume from your compute resource.
Azure Elastic SAN will allow you to connect
to various options such as AKS and VMs.
Here I'm going to be demonstrating how to connect the volume
from an Azure VM.
As mentioned before,
the VM that needs to be connected should be
on one of the vNets that you granted network access to.
And we just saw that the setup
for this was done at the volume group level.
Once this is done, you can call the get volume API
and you can pull out the storage target IQ N
and storage target portal host name,
as well as the port
from the volume information that is returned.
Volumes can be accessed via the iSCSI protocol
and the IQN, which is the iSCSI qualified name
is what you use to gain access to them.
You can then paste this information
into the iSCSI connection commands
and run these commands on the VM.
You can refer to our documentation
for iSCSI connection best practices.
After successfully initializing the iSCSI connection,
you can then read and write to the volume.
One thing to note,
is that here I will be showing you guys the workflow
for a simple single session connect.
If you need higher performance,
you can use multi-session set up
with multipath io and you can find details
on how to do this in our documentation again.
So now, moving on to the actual demo.
So first off, we run the get volume command
and we pull out the parts that I had talked about before,
the storage target IQN
the storage target portal host name, and the port itself.
We then use these three parameters to
generate our iSCSI commands.
We're going to be generating two types of iSCSI commands.
The add target and the login target.
First, we run the iSCSI add target command
and as you can see, the operation is completed successfully.
We then move on to the iSCSI login command,
which I'll be showing you guys here shortly.
Yeah, so as you can see,
we've run the iSCSI login to target command.
We have a session ID, we have a connection ID,
and the operation is completed successfully.
Now if we move over to the right hand side of the screen
look at the partition manager, you can see that
a disc which previously did not exist has shown up.
This is how we can verify that the volume has
actually been successfully connected,
or at least this gives us another way
to verify that the volume has actually
successfully connected beyond just the
message that you receive on the PowerShell terminal.
So yep, this is the connection flow.
I'll now move on to the next scenario.
Scale up.
If you need to scale up your SAN,
either in terms of storage capabilities or performance,
you can easily do so by provisioning a mix of
base size and or additional capacity.
This can be done at runtime.
If you want to add additional storage on premises,
it will take a lot of time.
However, on the cloud,
we can do this on the fly.
Now that you've scaled up your SAN,
these resources are all shared by volumes.
You can split the resources between the volumes
however you want based on your workloads requirements.
Because they are sharing the SAN level resources,
each of the volumes can burst to a much higher value
than the total performance of all the volumes
since can pull on the SAN resources dynamically.
One important thing to note
is that there is no way to scale down.
You can only increase the provision size
both at volume and SAN level.
We implemented this restriction to prevent data corruption
or data loss that could occur upon downsizing.
So, I'll now show you guys
exactly how the scale out process works.
So, looking at the original SAN,
we can see that the base size is 250 tebibytes.
The extended size is also 250
and we have a total size of 500 tebibytes.
We now run the update Elastic SAN command
with the parameters resource group name, the name.
We're going to increase the base size as well
as the extended capacity size.
Again, you don't have to increase both, but here we are.
So now we're just waiting for it to provision.
As you can see, we have the new base size of 300,
the new extended size of 300.
Which brings us to a total size of 600 tebibytes.
We move onto the volumes.
So we first called the volume
that we want to increase the size of.
We see that the size is 200 gibibytes
and now we're just going to run the update volume command.
Again, pretty similar to create
except you're just entering a new, larger size.
So now we just wait for it to provision.
And there we have it.
As you can see, the size has increased to 250 gibibytes
and everything else seems to be what we want it to be.
And we can see that the provision state has is in succeeded.
So we should be good to go.
And there you have it folks.
That's how you scale up your SAN and your volumes.
So for more information about Elastic SAN,
you can refer to our blog as well as our documentation.
And I've provided some links to these below.
If you guys are feeling particularly inspired
by the content that I've shared with you today
please feel free to fill out the
onboarding survey and get started.
We'll be in touch with you shortly.
And if any of you have any questions based
off of what I've shared or would like to learn more
please contact the team at the alias provided below
and we'll be in touch with you as soon as we can.
(inspiring music begins)
Thank you for your time
and I hope you've had a great time watching this video.
I know I had a great time sharing it with you.
I hope you have a great rest of the day.
(inspiring music intensifies and fades out)