Microsoft recently announced a number of improvements to the storage options in the Azure Site Recovery (ASR) disaster recovery-as-a-service (DRaaS) solution in Azure. This post will break down the news on support for premium storage, encrypted storage, and support for locally redundant storage (LRS) accounts.
Replicate to Premium Storage
If a workload requires high throughput and low latency storage on-premises, then wouldn’t it require the same when running in the cloud? Before this announcement, you had only once choice when replicating to Azure; you had to replicate to standard (HDD) storage, which limits each data disk to 500 IOPS. You can aggregate data disks but this would require that you split up your volumes in your production on-premises machines, which to be frank, are probably using one VMDK/VHD/VHDX per data volume, and that re-engineering would be quite disruptive.
Today, you can choose to replicate to Premium Storage which can offer up to 5000 IOPS per data disk (P30 size/spec/pricing). If a particular volume requires more IOPS, then you’ll need to split that volume across more virtual hard disks, and replicate those disks to Premium Storage.
There are a number of things to know at this point:
- Replication to Premium Storage is limited to VMware virtual machines and physical servers (InMage Scout) at this time. Support for Hyper-V/SCVMM machines should come soon.
- This new feature is supported by classic and Azure Resource Manager (ARM) storage accounts.
- The virtual machine in Azure must be either a DS-Series or GS-Series virtual machine. There’s no news in the announcement about the new F-Series with SSD support.
- You still need a Standard Storage account to track changes to the on-premises disks.
In the real world, you will have a mix of machines. Some will require HDD storage and some will require SSD storage. ASR supports this by allowing you to create multiple replication policies. The policy will associate machines with a storage account, and this means you could have one policy for Standard Storage machines and another for Premium Storage machines.
Azure Storage Encryption
Microsoft is continuing the march towards ensuring that no one can get at your data but you. The next step in that march is the ability to use Azure Storage Service encryption (SSE) for at rest data. Your data is encrypted as it is stored and decrypted as it is retrieved. ASR now supports the usage of SSE (in preview).
There are some things to know:
- Microsoft manages all encryption keys. So you are not protected against the NSA, GCHQ, and so on, yet, but you are protected against rogue operators or the low probability theft as a result of a breakout attack in Azure.
- At this time, you can only use SSE-enabled Standard Storage accounts. Premium Storage support is on the way.
- You can only use storage accounts created in ARM.
- Replication to SSE storage is supported by Hyper-V, SCVMM, VMware and physical machine scenarios.
- This is a preview feature and should not be used in production until general availability is announced.
Replication to LRS
I have been pitching ASR to customers for around 18 months. One of the questions I have been asked repeatedly is: if I have fault tolerant on-premises infrastructure, and I replicate to one Azure region, then why is Microsoft forcing me into replicating my Azure storage into another region (adding costs)?
ASR has always required that you replicate to a GRS Standard Storage account, where you replicate to a datacenter in Azure Region A, and your storage account is replicated to another datacenter in the designated neighboring Azure region, Region B. The forced choice of GRS over LRS doubles the cost of storage in the ASR solution.
Today, you can choose to replicate to LRS storage in Azure. However, this means that you need to understand that LRS exists in a single facility in the Azure region, albeit in separate fault and upgrade domains. GRS is still recommended, but if a customer needs to trim costs, or doesn’t want “another copy” then LRS is available.