The course is part of this learning path
Storage Solutions for SAP on Azure builds on storage topics discussed in Design an Azure Infrastructure for SAP Workloads and Design and Build High Availability and Disaster Recovery for SAP Workloads (coming soon). Data storage needs to be fast, responsive, and secure, but above all, continually available.
This course delves into greater detail on previously discussed topics and introduces new, more complex subject matter and its application to SAP workloads to ensure business continuity.
- Understand the various disk types available in Azure
- Learn how Azure Shared Managed Disks and Storage Spaces Direct can be used for SAP workloads
- Learn about scale-out file system
- Understand what disk striping and disk caching are
- Learn when and how to enable disk write acceleration and how to encrypt disks with SAP workloads
This course is designed for anyone looking to explore the Azure storage solutions available for SAP workloads.
To get the most out of this course, you should already have some experience working with SAP and Azure. Before embarking on this course, we recommend you take a look at Design an Azure Infrastructure for SAP Workloads and Design and Build High Availability and Disaster Recovery for SAP Workloads first.
Thinking purely about IaaS disk types, Azure offers Ultra, Premium, and Standard SSDs and HDDs. These types vary in IOPs performance and can be either managed or unmanaged. I won't delve too much into the difference between managed and unmanaged disks, as SAP virtual machines will pretty much always use managed disks. But for the sake of curiosity. VMs deployed in an Availability Zone must use managed disks. Gen2 VMs deployed to an Availability Set must use managed disks. That leaves us with Gen1 VMs deployed to an Availability Set or VMs deployed with no availability infrastructure. Unmanaged disks, which are page blobs within a storage account, are subject to size and data transfer quotas that managed disks are, in practical terms, free from. As the name implies, unmanaged means that scaling up or upgrading the disk type is much more complex than for managed disks. Unmanaged disks can be used for off-line backups and support local and geo-redundancy, while managed disks only support locally redundant storage.
This table shows the relative size and performance metrics of the four disk types. As you'd expect ultra, the top-tier disk has the maximum size, throughput, and IOPS and is recommended for intensive database workloads. In addition to these disk types, Azure NetApp Files is a high-performance and high-capacity storage solution that can be used in most scenarios apart from virtual machine operating system disks.
Performance is not for free, and ultra will cost more than premium. Premium disks come in preconfigures sizes where max IOPS, throughput, and cost increases as the disk size does. While ultra disk costs vary with the same metrics, those metrics aren't preconfigured and can vary independently of each other. Premium disks are the recommended minimum specification for all SAP workloads and the only recommended option for virtual machine OS disks.
Shared managed disks are precisely what they sound like, a managed disk that multiple Windows or Linux virtual machines can write to and read from. Shared disks have limitations that vary depending on whether the disk is ultra, premium, or standard SSD. No shared disks support Azure Disk Encryption or Azure Site Recovery. All VMs sharing a disk must be in the same Proximity Placement Group. Shared disks cannot be operating system disks, only data disks. When a shared disk is attached to VMs in an Availability Set, disk to VM fault domain alignment can't be guaranteed. A disk can't be aligned simultaneously to machines in different fault domains. The larger a disk is, the more maxShares it supports. For standard and premium disks, the least maxShares is three, and the most is 10. For ultra disks, the minimum is one, and the maximum is five regardless of disk size. Having said that, VMs sharing an ultra disk can't be placed in an Availability Set and, therefore, not supported for SAP workloads. Virtual machines sharing a premium disk are only supported in Availability Sets and not Availability Zones.
Shared disks combined with Windows Failover Cluster can be used in a highly available Central Services solution. Putting the sapmnt file share on the shared disk allows each node to access the SAP global host files via a UNC path. If the previously mentioned shared disk limitations are a show stopper, you can use third-party synchronous disk replication software SIOS DataKeeper to simulate disk sharing. SIOS DataKeeper is SAP certified and can be used to replicate disks hosting database files.
As an alternative to clustered shared disks for use with SAP Central Services hosted on a Windows Failover cluster, use an SMB 3.0 file share for global host files. SAP Message and Enqueue services are split from the global host files. SAP ASCS/SCS runs on a cluster with the global files on the SMB share and is accessed using the SAP global hostname combined with sapmnt and SID. SAP ASCS/SCS instances are deployed locally on each cluster node, with the ASCS/SCS virtual host network name being different from the SAP global host.
Hallam is a software architect with over 20 years experience across a wide range of industries. He began his software career as a Delphi/Interbase disciple but changed his allegiance to Microsoft with its deep and broad ecosystem. While Hallam has designed and crafted custom software utilizing web, mobile and desktop technologies, good quality reliable data is the key to a successful solution. The challenge of quickly turning data into useful information for digestion by humans and machines has led Hallam to specialize in database design and process automation. Showing customers how leverage new technology to change and improve their business processes is one of the key drivers keeping Hallam coming back to the keyboard.