Azure Stack – storage

Azure Stack – storage

Storage is a huge part of IT infrastructure. It’s been a problem since the beginning of time; from Solaris to Linux to Windows, from SAN to NAS to DAS, from SATA, to SAS to SSD. All of it requires a good understanding of the use cases and the limitations of the technology as well as usually requiring a heavy operational presence. This is an area cloud really has provided massive value. The concept of on-demand, managed storage where all you need to do is think about the type of data you have and, can then access limits volumes, is a kind of Nirvana. However, when we come to look at Azure through the eyes of a cloud consumer we need to be realistic about what it really can offer right now.

At a platform level Azure Stack storage is all served from the same pool of disks. This means Azure Stack can’t really be thought of in the same way as we think of cloud storage. To explain this I’ll explain what storage Azure Stack offers.

Blob storage

AKA object storage. It allows users to store large volumes of data cheaply to support many different applications from static web content to unstructured data to backups etc. Usually it’s higher latency and better at sequential read and write operations. In cloud this storage is usually considered “unlimited”. In UKCloud’s object storage service we have multiple petabytes of data.

Page Blob

AKA block storage. This is well suited to low latency, randomly accessed data. Azure (Stack) uses this to store vhd (virtual disks) to support the VMs. Generally in cloud and on-prem the use of block storage is similar although in most public clouds block storage has better performance consistency being able to request guaranteed throughput.

Table

AKA noSQL service. This allows users access to highly scalable managed noSQL databases. These databases are usually eventually consistent and whilst not generally regarded to be limitless the concept is they scale big!

Queue

AKA message bus. This allows users to access to develop loosely coupled micro-services using the message bus to asynchronously process work allowing horizontal scaling and targeted scaling of application functions.

What does all this really mean?

With these new ways of consuming “on-premise” storage we need to carefully think about how we should use Azure Stack, as consumption of any of these types of storage will eat into your, once again finite, allowance.

It means that whilst you get consistency in your deployment, your Azure code, to a large degree can be reused to deploy against Azure Stack. The mentality you need to have is that storage is once again a resource that needs consideration and planning. It is no longer limitless. With that in mind we advise you to think about the type of workloads you will be placing in Azure Stack. When you use blob storage, use it to support your application not to support an application requiring multiple petabytes of data storage. Once again think about housekeeping, implementing policies to clean up backups to conserve space (although likely you’ll be doing this in cloud to conserve cost). Or if large volume data retention is a requirement back this off to UKCloud object storage. Basically, think about the shape of your application in context of the well-publicised limits of the resources you have access to.

At UKCloud we have also taken efforts to try and conserve storage by reducing the size of temporary storage on your VMs to reduce their foot print. Try changing your use of temporary storage and only attach additional disks where it is really necessary.

Storage subtleties

The final point to highlight is that whilst there needs to be a big shift architecturally in the way you consider storage there are other subtle differences that could be a blocker to the way you consume these services.

For example, the maximum size blobs is significantly different between Azure and Azure Stack, block blobs being 4TB on Azure whilst only 195GB on Azure Stack, whilst page blobs are 8TB vs 1TB respectively. Or that whilst premium storage is supported as a construct to keep API consistency, Azure Stack cannot yet place guarantees around IOPs.

This article is not intended to explain every difference between the storage systems on Azure and Azure Stack but instead raise awareness so that people are educated when planning their Azure Stack deployments.

For more information on the subtle differences between the storage please refer to the Azure Stack storage documentation.


Post A Comment