Migrating Apps to the Cloud – Performance and Sizing Issues in Azure

ByAugust 4, 2016
azure-disk-performance-stripingMany companies I work with grapple with the challenge of migrating apps to the cloud while ensuring no adverse effects on performance and cost. Paying attention to migration methods as well as VM sizing as it relates to disk performance and billing is essential for successful cloud migration projects. I’d like to share some of my experiences on these aspects of cloud migration in this blog.
As my colleague Lilac mentioned in her recent blog article, while many organizations are deploying new, shiny, cloud-native apps in hyper-scale clouds, there are still many that would like to migrate their legacy (even if they’re actually quite new) apps to a cloud provider. This could be driven by all sorts of needs:
  • Co-lo contract coming to an end
  • On-premises data center/room/cupboard getting full
  • Power and cooling costs or availability
  • Need to refresh hardware
  • Need to upgrade software
  • Compliance requirements driving new deployment and DR methods
Lift & Shift Vs. Replication
Over the past few years, both at iland and other cloud providers, I’ve seen customers migrate traditional client/server environments over to the cloud, either using ‘lift & shift’, or via replication or cloud backup technology. Clearly, lift & shift requires downtime for the VMs, as they are exported out of the source environment onto large USB drives, and then imported into the new cloud platform. Or, bandwidth permitting, they are transferred over the internet. Sometimes, the virtual machine format has to be changed from one virtualization standard to another, and this can introduce some complications as well.

Replication technologies allow for VMs to be migrated over in a ‘trickle’, and then cut over fairly quickly at a suitable point in time, depending on the speed of the network between the customer premises and the cloud data center. This can be achieved with as little as 5Mbps of internet bandwidth.

The iland cloud platform allows for both methods of migration.  VMs can be transferred using the Open Virtualization Format (OVF), which also has a compressed version called OVA.  Alternatively, iland can deployed replication- or backup-based solutions in partnership with Zerto and Veeam.

Considering Disk Performance
However, one aspect of this near-legacy migration is that, for most customers, their VMs are made up of either just an operating system disk, or perhaps an OS disk and one or two data disks. Having been on-premises or in co-lo, their infrastructure was made up of servers and shared, usually SAN or NAS, storage.  They were used to disks performing with thousands of IOPS and many 10s of MB/s throughput.

So when customers migrate to the cloud, they expect the same level of performance.

But, are all cloud providers the same in this respect?

In the case of the hyperscale vendors – the answer is ‘No’. Azure, for example, limits a ‘standard’ data disk to 500 IOPS and 1TB in size. So, if a customer migrates a VM from on-premises to the Azure cloud, they could notice a marked drop in the performance of their virtual disks.

The answer in Azure is to provision several small disks, and then use disk striping to join the disks together, perhaps using Storage Spaces in Windows, or LVM in Linux  – similar to RAID 0. That way, if you had four disks, you might expect to get 2000 IOPS performance. Or eight disks might give you 4000 IOPS performance.  So there’s quite a bit of jiggery-pokery to be done. And will the extra performance scale linearly?

The next consideration is that the ‘t-shirt’ or instance size of the VM in Azure determines how many virtual disks you can connect. So, if you had a relatively small VM CPU/RAM requirement of, say, 2 vCPUs and 4GB RAM, you would actually have to choose a VM with 4 vCPUs and 8GB RAM in order to get 8 data disks, and this will cost more per hour or month. For 16 disks, you may have to choose 8 vCPU and 14GB RAM.

To demonstrate the issue, I did some tests using the well-known disk performance tool, IOmeter on some Azure and iland VMs, using Windows 2012 R2 and Storage Spaces. I used fairly standard settings in IOmeter to simulate a read/write workload, mixing both random and sequential reads and writes for a 30 second duration.

Disk performance using striping
Disk performance using striping
As you can see from the charts, the Azure IOPS and MB throughput increases in a somewhat linear fashion for the Azure data disks, while the iland disk performance stays much the same for one disk as two (I did test four and six as well).
While Azure virtual disks cannot be larger than 1TB, iland virtual disks can be up to 62TB in size (although I’m not aware of anyone using that size!).
VM Sizing Really Does Matter!
On the subject of VM T-shirt or instance sizes, and the amount of vCPU and RAM supported by each instance– iland has chosen to adopt a somewhat different model. As previously discussed, with iland, the VM size does not determine how many virtual disks or virtual network adapters you can attach (network adapters are also a function of the VM size on Azure). iland customers are only constrained by the virtual limits of the platform, underpinned by VMware vSphere.  Typically, this means up to 128vCPUs, 4080GB RAM, 60 disks and 10 vNICs – per VM. Caveat: clearly this will depend on the capability of the underlying host! Rather than use the t-shirt or instance model, iland instead offer the concept of a bucket of resources, or resource pool. With this model, a customer can sign up to a resource pool of x vCPU, y GB RAM, and z GB of storage. Into this pool they can deploy whatever VM sizes they like – even really weird values – to absolutely fit what they need. And moreover, they only get billed for what they actually consume. So, even if they’ve provisioned a VM with 4 GHz of CPU, and they only ever run at 25% CPU, they’ll only get billed for that.
If a customer has a good idea of their required Resource Pool size (and data can be pulled from tools such as Virtual Center) then they can save a substantial amount of money going with a Reservation model.
However, iland also offer Pay As You Go (PAYG) and Burst models. PAYG as the name suggests only bills customers for what they consume, while the Burst model uses an amalgam of Reservation and PAYG.
So, in summary:
  • While shiny, new, cloud-native apps are a big thing, an even bigger thing is the migration of existing, not quite legacy apps to the cloud.
  • Not all clouds are equal – iland offers a great environment to take existing Windows and Linux workloads to the cloud with minimal disruption and jiggery-pokery, using either Lift & Shift or backup/replication technologies.
  • iland’s billing models help customers right-size VM requirements, without the need to over-specify their VM t-shirt or instance sizes just to get the desired disk performance.
Migrating legacy apps to the cloud can be challenging – but with careful consideration and planning for performance maintenance and VM sizing, successful migrations are indeed possible. I hope you found these cloud migration insights useful and I’d love to hear about your experiences or challenges in migrating apps to the cloud.
Richard Stinton

Richard Stinton

Richard is an Enterprise Solutions Architect for the iland EMEA business and has over 30 years’ experience in the IT industry, most recently in the Cloud space with iland, Microsoft Azure and VMware. Starting out in Engineering CAD/CAM and GIS systems with McDonnell Douglas and EDS, he moved to mainstream IT and Systems/Service Management with HP, BMC Software and Mercury Interactive, before joining VMware in its early days. Richard has a breadth of experience having worked in customer support, sales, partner management and product marketing. In his current role as EMEA solutions architect, Richard works with customers to implement and optimise cloud technologies.