Editor’s Note: As of January 2022, iland is now 11:11 Systems, a managed infrastructure solutions provider at the forefront of cloud, connectivity, and security. As a legacy iland.com blog post, this article likely contains information that is no longer relevant. For the most up-to-date product information and resources, or if you have further questions, please refer to the 11:11 Systems Success Center or contact us directly.
Many companies 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. We’d like to share some of our experiences on these aspects of cloud migration in this blog.
As we mentioned in a recent article, while many organizations are deploying new, shiny, cloud-native apps in hyperscale clouds, there are still many that would like to migrate their legacy (even if they’re 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 and Shift vs. Replication
Over the past few years, both at 11:11 Systems and other cloud providers, we’ve seen customers migrate traditional client/server environments over to the cloud, either using “lift and shift,” replication, or cloud backup technology. Lift and 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. Occasionally, 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.
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 11:11 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, 11:11 can deploy 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 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 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. 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 eight 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, we did some tests using the well-known disk performance tool, IOmeter on some Azure and 11:11 VMs, using Windows 2012 R2 and Storage Spaces. We 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.
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 11:11 disk performance stays much the same for one disk as two (we did test four and six as well).
While Azure virtual disks cannot be larger than 1TB, 11:11 virtual disks can be up to 62TB in size (although we’re 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, 11:11 has chosen to adopt a somewhat different model. As previously discussed, with 11:11, 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). 11:11 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. There is a caveat: clearly this will depend on the capability of the underlying host! Rather than use the t-shirt or instance model, 11:11 offers 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 fit exactly what they need. 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, 11:11 Systems also offers 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. 11:11 offers a great environment to take existing Windows and Linux workloads to the cloud with minimal disruption, using either lift and shift or backup/replication technologies.
- 11:11’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. We hope you found these cloud migration insights useful and we’d love to hear about your experiences or challenges in migrating apps to the cloud.
References:
Azure Storage Scalability Targets