SAS and Microsoft announced a strategic partnership that is going to influence the market in the upcoming years. Immediately, this has set Azure as the preferred cloud provider for SAS deployments. It is important for SAS Architects and SAS Deployment Engineers to become familiar with Azure technology. A layer of the architecture that deeply influences SAS performance is the IO stack, and in Azure it is possible to choose from different storage solutions. Which ones are best suited for SAS?
In this post I'll do my best to remain high-level enough so that you don't have to be storage experts to follow along; at the same time, I wish to provide enough knowledge to let you understand the how and the why of the different options and choices.
Although SAS on Azure can be deployed both on Windows and on Linux operating system, this post focuses on Linux only. Some of the content is available in the Azure documentation, explained in a clear way. Luckily for you, you don't have to go and dig into all these docs, they are all referenced here.
Since this post was getting too long, I decided to split it in two - this first installment describes Azure disk storage options, while the next one will focus on the options to mount/provide access to external storage resources.
Although resources on Azure are "virtual", virtual machines still need the same components as physical ones: CPUs, memory, network interfaces ... and disks. Virtual disks, of course. The good news is that on Azure, virtual disks are managed:
Managed disks are like a physical disk in an on-premises server but virtualized. With managed disks, all you have to do is specify the disk size, the disk type, and provision the disk. Once you provision the disk, Azure handles the rest.
Managed disks are designed for 99.999% availability. Managed disks achieve this by providing you with three replicas of your data
Azure provides different kinds of disks. Let's see how we can describe them.
Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.
Just as with OS disks, every virtual machine comes by default with one temporary disk. With SAS, you can use an ephemeral disk for SASWORK or CAS_DISK_CACHE. Just remember that, after a machine deallocation, not even an empty /mnt/resource/saswork directory will be there. You should use a startup script that recreates the directory at every reboot, similar to this example from the SAS Viya on Azure QuickStart.
OS and Data disks can survive virtual machine reallocations and even virtual machine deletion. This is possible because disk space is provisioned from remote Azure storage, similarly to a SAN storage on premise.
Ephemeral disks, on the other side, are lost every time a virtual machine is moved to new physical host, because they are created on the local SSD disks attached to the physical host.
Although OS and Data Disks are persistent, they cannot cross Availability Zone (AZ) boundary. As an example, a disk created in AZ 1 cannot be attached to a virtual machine running in AZ 2. By default, if you create a new disk while creating a virtual machine, they are created in the same AZ.
Azure currently offers four disk types, each with different performance levels. The size of the virtual machine determines the type of storage you can use to host the disks. The available types of disks are ultra disks, premium solid-state drives (SSD), standard SSDs, and standard hard disk drives (HDD).
The disk performance you get when selecting from the different Azure Disk types has a direct impact on the performance SAS can achieve. Virtual machines can pose a different and independent limit on the maximum I/O throughput. Both the chosen VM and the attached disks should meet SAS throughput requirements, to prevent performance degradation.
It does not matter if you provision a single 2000 MiB/s Ultra disk, or 4 P60 disks when using a Standard_E32s_v3 instance (one of the most popular Azure instances that is being used for SAS): the VM has a maximum limit of 768 MiB/s for "uncached disk throughput" and that will cap any available disk bandwidth.
Azure documentation does a nice job in explaining the different layers of disk caching and how they affect the max available I/O bandwidth, but the key point is to choose a machine type which can provide the required 100 MiB/s/core for data and 150 MiB/s/core for SASWORK/CAS_DISK_CACHE. When doing this selection, you may often find that it is not possible to satisfy these requirements, which have to be relaxed - and user expectations should be relaxed as well! As an example, none of the configuration proposed under "Reference Instances for SAS Compute Nodes" in Margaret Crevar's post can reach even 50 MiB/s/core for data disks.
As a workaround, when selecting a virtual machine instance size, you can utilize Constrained Cores to reduce the number of cores presented to the instance’s operating system. What does this mean for SAS? SAS licensing usually sets the number of CPUs that you can use. Let's say you have a license for 16 cores, which (usually) translates to 32 vCores. You could use a Standard_E32s_v3 instance, but we have just seen that it can only provide 768 MiB/s = 48 MiB/s/core. If, instead, you use a "constrained" Standard_E64-32s_v3, you still have 32 vCores, but you are effectively doubling the I/O bandwidth per core - because the machine is in all other effects a Standard_E64s_v3. Unfortunately, it is a Standard_E64s_v3 also in pricing; therefore, the available bandwidth comes with an associated increase of the bill at the end of the month!
In summary, chose a machine type that can provide enough maximum bandwidth (look at the "uncached disk throughput" column in the machine type specification) and attach enough Premium Disks to achieve that throughput (look at the “Provisioned Throughput per disk” row of this table).
There are many resource and configuration choices available within Azure, in order to select the proper storage to meet the needs of your SAS environment. It is possible you may have to overprovision the storage and use an instance type with more cores than needed in order to get enough I/O throughput required by SAS.
Be sure to read all of Margaret Crevar's latest post with additional Azure consideration and sample instances, and, when it will be published - spoiler alert - the upcoming paper by Raphael Poumarede about SAS Viya 3.5 on Azure.
In the next post, I’ll cover Azure external storage options, such as Azure Files, Azure NetApp Files, Blob storage, and more - including considerations for SAS Grid Manager.
Registration is open! SAS is returning to Vegas for an AI and analytics experience like no other! Whether you're an executive, manager, end user or SAS partner, SAS Innovate is designed for everyone on your team. Register for just $495 by 12/31/2023.
If you are interested in speaking, there is still time to submit a session idea. More details are posted on the website.
Data Literacy is for all, even absolute beginners. Jump on board with this free e-learning and boost your career prospects.