Contents
Part 5, the end of the series! This has been a fun series to write, and I hope it was helpful to some of you. The impetus for this whole thing was the number of times I’ve been asked how to setup shared storage between systems (primarily VMs) in Azure. As we’ve covered, you can see there are a handful of different strategies with pros and cons to each. I’m going to close this series with a final Pros and Cons list and a few general design pattern directions.
- Part 1: Azure Shared Disks
- Part 2: IaaS Storage Server
- Part 3: Azure Storage Services
- Part 4: Azure NetApp Files
- Part 5: Conclusion
Pros and Cons:
Shared Storage Options in Azure: Part 1 – Azure Shared Disks « The Tech L33T
Pros:
- Azure Shared disks allows for the use of what is considered “legacy clustering technology” in Azure.
- Can be leveraged by familiar tools such as Windows Failover Cluster Manager, Scale-out File Server, and Linux Pacemaker/Corosync.
- Premium and Ultra Disks are supported so performance shouldn’t be an issue in most cases.
- Supports SCSI Persistent Reservations
- Fairly simple to setup
Cons:
- Does not scale well, similar to what would be expected with a SAN mapping.
- Only certain disk types are supported.
- Read-Only host caching is not available for Premium SSDs with maxShares >1.
- When using Availability Sets and Virtual Machine Scale sets, storage fault domain alignment with the VMs are not enforced on the shared data disk.
- Azure Backup is not yet supported.
- Azure Site Recovery is not yet supported.
Azure IaaS Storage:
Shared Storage Options in Azure: Part 2 – IaaS Storage Server « The Tech L33T
Pros:
- More control, greater flexibility of protocols and configuration.
- Ability to migrate many workloads as-is and use existing storage configurations.
- Ability to use older, or more “traditional” protocols and configurations.
- Allows for the use of Shared Disks.
- Integration with Azure Backup.
- Incredible storage performance if the data can be cached/ephemeral (up to 3.8 million IOPS on L80s_v2).
Cons:
- Significantly more management overhead as compared to PaaS.
- More complex configurations, and cost calculations compared to PaaS.
- Higher potential for operational failure with a higher number of components.
- Broader attack surface, and more security responsibilities.
- Maximum of 80,000 uncached IOPS on any VM SKU.
Azure Storage Services (Blob and File):
Shared Storage Options in Azure: Part 3 – Azure Storage Services « The Tech L33T
Pros:
- Both are PaaS and fully managed which greatly reduces operational overhead.
- Significantly higher capacity limits as compared to IaaS.
- Ability to migrate some workloads as-is and use existing storage configurations when using SMB or BlobFuse compared to using native API connections.
- Ability to use Active Directory Authentication in Azure Files, and Azure AD Authentication in Blob and Files.
- Both integrate with Azure Backup.
- Much easier to geo-replicate compared to IaaS.
- Azure File Sync makes distributed File Share services and DFS a much better experience with Backup, Administration, Synchronization, and Disaster Recovery.
Cons:
- BlobFuse (by default) stores credentials in a text file.
- Does not support older access protocols like iSCSI.
- NFS is not yet Generally Available.
- Azure Files is limited to 100,000 IOPS (per share).
Azure NetApp Files:
Shared Storage Options in Azure: Part 4 – Azure NetApp Files « The Tech L33T
Pros:
- Incredibly high performance, depending on configuration (up to ~3.2 million IOPS/volume).
- SMB and NFS Shares both supported, with Kerberos and AD integration.
- More performance and capacity than is available on any single IaaS VM.
Cons:
- While it is deployed in most major regions, it may not yet be available where you need it yet (submit feedback if this is the case).
- Does not yet support Availability Zones, Cross-Region Replication is in Preview.
There we have it, my final list of Pros and Cons between Azure Shared Disks, DIY IaaS Storage, Azure Blob/Files, and Azure NetApp Files. Lastly, I want to end with some notes on general patterns when considering shared storage like the ones discussed in this series.
Patterns by Workload Type:
Quorum:
- If the reason you need shared storage is for a quorum vote, look into using a Cloud Witness for Failover Clusters (including SQL AlwaysOn).
- If the cloud quorum isn’t an option, shared disks is going to be an easy option, and I would go there second.
Block Storage:
- If you need shared block storage (iSCSI) for more than just quorum, chances are you need a lot of it, so I’d first recommend running IaaS storage. Start planning a migration away from this pattern though, Blob block storage on Azure is amazing and if you can port your application to use it – I would highly recommend doing so.
- For most generic file shares, Azure Files is going to be your best bet – with a potential use of Azure File Sync.
- Azure NetApp Files is also a strong option here since the Standard Tier is cost effective enough for it to be feasible, though ANF requires a bit more configuration than Azure Files.
- Lastly, you could always run your File Share in custom IaaS storage, but I would first look to a PaaS solution.
High-Performance File Storage:
- If your application doesn’t support the use of Blob storage, like most commercial products, Azure NetApp files is likely going to be your best bet.
- Once NFS becomes generally available, NFS on Azure Files and Blob store are going to be strong competitors – especially on Blob and ADLS.
- Depending on what “high-performance” means, and whether or not you use a scale-out software configuration, storage on IaaS could potentially be an option. This is a much more feasible option when the bulk of the data can be cached or ephemeral.
We’ve come to the end! I hope that was a useful blog series. As technologies and features advance, I’ll go back and update these, but please feel free to comment if I miss something. Please reach out to me in the comments, on LinkedIn, or Twitter with any questions about this post, the series, or anything else!