Exploring Azure Elastic SAN: Combing the old and the new
Stephen Tulp
September 16, 2024
8 minutes to read
Overview
In the ever-evolving landscape of cloud computing, Azure Elastic SAN is a service which is provided as a fully managed, cloud-native Storage Area Network (SAN) offering. Azure Elastic SAN became GA in Feb 2024 but there hasn’t been a lot of information online around it. This blog post will summarise what Azure Elastic SAN is and its key features. The main focus will be on how to create a reusable Bicep template for the service.
The TLDR, show me the code! is available here - Azure Elastic SAN Bicep Modules
What is Azure Elastic SAN?
Azure Elastic SAN is designed to bring the capabilities of traditional on-premises SANs to the cloud. It offers a scalable, high-performance, and cost-effective storage solution that simplifies the deployment, management, and scaling of SANs in the cloud. Whether you’re migrating from an on-premises SAN or building new applications in the cloud, Azure Elastic SAN provides a seamless and efficient experience.
Key Features of Azure Elastic SAN
- Scalability and Flexibility: Azure Elastic SAN allows scaling storage capacity and performance independently. This means you can start small and grow as your needs increase, without the need for significant upfront investments.
- High Performance: You provision IOPS (Input/Output Operations Per Second) and throughput for your SAN resource and share it across multiple volumes. This ensures that your applications get the performance they need, when they need it.
- Cost-Effective: By enabling dynamic resource sharing and competitive Total Cost of Ownership (TCO), Azure Elastic SAN helps you optimize costs while maintaining high performance and reliability.
- Ease of Management: Azure Elastic SAN uses a familiar resource hierarchy, making it easy for users of traditional SANs to transition to the cloud. You can manage multiple volumes through volume groups, simplifying service management and policy enforcement.
- iSCSI Support: Azure Elastic SAN volumes are accessible using iSCSI, an industry-standard remote block storage interface. This provides simplicity and ease of transition for users familiar with on-premises SAN environments.
Creating a repeatable IaC template using Bicep
Generally, my starting point when creating Bicep IaC templates is to first look at the Azure Verified Modules repository to see if there ia an existing Bicep module that I can use. Even though Elastic SAN is GA there are limited IaC examples online. That’s ok, lets see how we can solve that.
To get a good starting point, I will provision an Azure Elastic SAN resource so that we can export it from within the portal. The process will include:
- Export the resource from the portal to a
.json file. - Convert the
.json fileinto a bicep file. - Refactor the decompiled .bicep file to leverage some of the new capabilities
Export the resource from the portal
From within the Azure Portal, we have the ability to be able to export resources into a .json template.
The exported file can be found here
Convert the export into a Bicep file
Converting .json templates into Bicep is quite straight forward, we just need to run the following command.
az bicep decompile --file esanExport.json
The converted file is able to be deployed but there is things we can clean up to make it easier to understand. The decompiled Bicep file can be found here
Refactor the decompiled Bicep file
So we have a bicep file that gives us something that we can deploy, but there are quite a few optimisations that we can leverage to make it better.
- Add a .Bicepparam parameter file.
- Include For Loops for the Elastic SAN Volumes.
- Add User Defined Types to provide data validation for parameter objects.
To help with the refactoring, there are a couple of things that we can leverage.
- Azure Elastic SAN Resource Definition (Microsoft Learn) - This will help to understand the structure of the resource name, property names and allowed values.
- Azure Resource Naming Constraints (Microsoft Learn) - Understand the constraints when it comes to naming some of the parameters.
.Biceparam Parameter File
There are 2 parameter objects defined in the parameter files, the tags object is pretty straight forward and includes value key pairs for a set of required tags.
The elasticSan object is a little more complex but includes all the properties and values needed for the elastic SAN resource.
The complete Bicep parameter is here - Azure Elastic SAN .bicepparam File
For loops for Elastic SAN Volumes
If we look at the exported bicep file we can see there is 2 volumes volume1 and volume2 and are basically the same except for the name property.
A simple loop statement will achieve the same as the above.
User Defined Types
In Azure Bicep, data types define the nature of values assigned to variables and parameters and support types such as int, string, bool, object, and array. When a resource has many configuration values to be set, having parameters for all of these can be quite cumbersome and this is where using an object can help with a module. However the challenge is you will need to understand the structure of the object and also there isn’t a lot of help from intellisense.
User Defined Types allow us to control the inputs to the object and provide validation on the allowed values, lets first look at the Tag object.
So you can see applicationName and iac have set values and environment, criticality, and dataClassification have allowed values so these values have to be one of the ones defined here. owner, costCenter and contactEmail can be any sting value and the *: means we can add other tag names to the object if we wanted to extend the Tag object.
Now if we look at the Elastic SAN object, its gets a little more complicated but we can also use @description decorator to give some context and explain if they are required or optional values.
The object has values that either take a string or int values, we can leverage naming constraint lengths here for the names as well. When it comes to the availabilityZones: array? values the ? indicates that it is optional and you don’t have to have this in the object and will happily deploy if it isn’t defined. The VolumeGroup and Volume child resources are also addressed here.
The complete module is here - Azure Elastic SAN Bicep Module
Conclusion
We could make further improvements to this bicep module to have allowed regions and redundancy options, this is due to the current constraints on the number of regions that the service is currently hosted in. If you plan to adopt Azure Elastic SAN today, be aware that if you are using the AustraliaEast region then you will only have access to locally redundant storage (LRS). All region and redundancy information is available at Azure Elastic SAN Allowed Regions and Redundancy Options (Microsoft Learn)
Azure Elastic SAN represents a significant leap forward in cloud storage technology. By bringing the capabilities of traditional SANs to the cloud, it offers a scalable, high-performance, and cost-effective solution for modern storage needs. Whether you’re migrating from an on-premises SAN or building new applications in the cloud, Azure Elastic SAN provides the tools and features you need to succeed.
Explore Azure Elastic SAN today and take your cloud storage to the next level!