Over the last 10 years or so many organisations have made the change from deploying applications and services on standalone physical servers to running them as Virtual Machines (VMs) within a Hypervisor farm. That offered many benefits including the reduced number of hosts in your data centre needed to run all those applications, centralised management of VMs, the ability to change a VM’s hardware allocation, improved Disaster Recovery etc.. You can think of that process as Virtualisation 1.0 where the way many servers are hosted and data centers operate has fundamentally changed for ever. This blog is about the next step in that evolution, Virtualisation 2.0, where moving your VMs to the Azure cloud provides you with a huge range of scalability and redundancy options that are typically not available within most Gen 1.0 on premise Hypervisor farms. In the last few years the massive investments being made in cloud infrastructure have opened up a whole new world of hosting options which means there are now many new choices that you can make in deploying a VM to the cloud. This first article is about some of the approaches and technical options that you should think about before moving a VM, rather than just doing a simple Virtual to Virtual (V2V) move.
Microsoft’s $15 Billion investment in the Azure cloud solution provides a huge global capacity to run customer VMs using the ‘Infrastructure as a Service’ (Iaas) part of Azure. What this means is that there is now a broader choice of server specifications that can be selected, from the simplest A0 type server all they way up to very large and super fast G series servers capable of running very demanding applications like SAP HANA. There are more choices for things like the types of local disks used i.e. standard or SSD drives; you can choose VMs that have greater network throughput or more compute capacity depending on your needs. More details of the VM server types can be found on the VM Pricing Pages. Likewise your choice of storage options for large Data drives are more varied both in terms of the number of copies kept & their geographical location. There are also a number of data protection service layers that can be added to maximize your applications uptime & recoverability. The items discussed here are about the target environment that you will be moving your VMs into i.e. Azure, so these architectural considerations apply to most of the virtual server types that people want to move into Azure; in part 2 of this series we will be looking more in detail about how this applies to the two most popular hypervisor systems, HyperV and VMware.
Can you run the application on the VM as service instead?
The proliferation of the Cloud has had a fundamental change in the way that applications are provided to end users, so one of the first thing to consider when looking at moving a VM to the cloud is ‘Can the application be provided as a Cloud Service instead?’. In the new world of Cloud services you may find that an application that you had to run on a dedicated server before, such as an Accounts or CRM package, is now available as service on Azure in association with the software provider. This approach also works for more mainstream applications like SQL server and SharePoint, that are also available in a ‘Platform as a Service’ (PaaS) offering. Running your application as a Service will usually work out to be significantly more cost effective than running the same application on a VM and can reduce the number of VMs you need to operate significantly. This is because VMs cost more to rent, you have to provide your own licences, you have to patch & maintain the VM etc.. whereas all that is done for you by the service provider if you move you application to a PaaS solution. Of course there are times when the PaaS version of the application may not do everything you want because you need to run extra software on the VM, have access to the console or scale out the service significantly etc.. However the number of common applications available as a Cloud Service is growing all of the time so this approach is defiantly one that you d not want to overlook. The up to date list of applications that you can run as a service is to be found in the Azure Marketplace.
Migrate current VM vs Build a new one then migrate data onto it?
Once you have decided that you want to move a VM that you currently run in your data centre to the Azure cloud, then the next thing to look at is how you want to do this. This is because sometimes it is better to build a new clean installation of that VM and synch the data to it rather than do a Virtual to Virtual (V2V) copy of that entire VM. An example of this would be for a Domain Controller where best practice is to build a clean server & then promote it to be a Domain Controller (DC) rather than trying to copy it. While doing this type of data replication will need a VPN connection to your on premises DCs and some time to sync the Active Directory (AD) databases, it means that can use a new clean VM image from the Marketplace, such as Windows Server 2012 R2, after which it is only a small job to configure the networking before promoting the server to be a DC. If you want to build new VMs within Azure and then get the data on them synchronised with servers back in your old on premises data centre, then this approach of starting with a new clean VM image can work well. This is because some common Applications like to do the data synchronisation at the application level and not use file level replication like a lot of systems do. Examples of this can be Exchange (on a VM), SQL server etc.. On the other hand if you have a bespoke application that would not be easy to build from scratch or cost too much in consultant’s time to rebuild then creating a copy of the server in Azure by using a V2V migration is often the best approach. We will look at the tools available to do this in Part 2 of this series.
Prerequisites: Networks & Storage account
There are a couple of things that you should have in place before you move or create new VMs, which are Networks and access to Storage for the large Non-OS data volumes. You should always have your Virtual networks & subnets defined before you add any VMs that will use them, as doing so later can cause problems. The Network design for an application suite is usually predefined by your IT Team’s designers unless you are talking about a simple 1 or 2 box solution. That network design will normally go hand in hand with a Security Design or Policy that dictates where the firewalls go, how the network security segments are laid out, how traffic will be kept separate and so on. The Network design should also include the things like Load balancers, Firewall locations, end points etc.. which ideally should be planned out on paper before you implement them within Azure. Only when all that is in place should you be adding in your VMs, for any kind of serious production implementation.
The other main item that you should have preconfigured is the storage for your data. When you build a VM in Azure it comes with local storage for the OS & an optional local storage drive that can be used for temporary files. It is important to understand that this local drive should not be used for storing data long term; they are limited in size and will be wiped when that VM is erased. Therefore you should create a storage account and have preconfigured storage created for the data drives that the VM will store it’s data on long term before you go ahead and build the VMs that will use it.
What Service Levels should you choose for your VM?
One of the next choices to make is the Service level you want the new VM to operate at. Here you have the choice between Basic and Standard. Many people who want to operate a VM in the cloud want a service level that provides a good solid infrastructure solution without having to pay for many of the more expensive feature that you can add to the mix for better redundancy or a quicker recovery time, in which case the Basic service may be the choice for them. This Basic service Tier is the best option for small scale deployments, Test environments and other non-production environments that do not need load balancing and super high availability features that are found in the Standard tier. It normally comes in at around 25% less than the equivalent Standard Tier VMs. The choice of servers that you can select is smaller here and you do not have access to the big VM server types without moving up to standard, but there is still plenty of good sized machines to choose from within the A0 to A4 range of servers. Likewise the number of Input Outputs per Second (IOPS) available at the Basic service level is restricted to around 300 IOPS compared to the 500 available on the same type of VM that is in a Standard Tier. The main difference between the Basic Tier and Standard Tier VMs is that the Basic VMs do not have the ability to do auto-scaling and load balancing, which for many is a must when it comes to Production VMs. For example the ability to scale out from say 2 to 5 VM during peak periods of demand is one of the huge advantages of having your VMs in the Standard service tier. The good news here is that it is easy to change a VM from say the Basic to Standard tier, which can be done in a few seconds, in the same way that you can change the VM type of server on the fly.
Server Hardware classes and sizes for VMs:
Now that you have chosen a service tier for you VM it is now the right time to think about the size of server that you will be running in the cloud. At the same time you also need to decide if the VM will be a Standard A class of server or if it will be one of the more high performance D or G class of servers that are available in Azure. For most VMs in Azure the standard A series of serves provides the best combination of performance and value for money. There are choices that go from the A0 servers with 1 Core and 0.7GB RAM in the Basic Tier up to A7 VMs with 8 cores and 56 GB of RAM in the Standard tier. The A series of VMs offers a wide range of performance levels for you to choose from & as ever in Azure, you have the power to increase or decrease the specification of a VM on the fly.
For even faster performance there are now a number of different options available. The top end A series machines can be ordered as an A8 or A9 server which has been optimised for high network throughput applications and then there are the A10 and A11 server types which have been designed for applications with large computational needs. For more performance orientated servers the next step up is the D series servers that offer up to 60% faster CPUs, more memory and offer fast local SSD storage to help maximise throughput. The fastest servers currently offered are the G-series VMs which come with the latest Intel® Xeon® processor E5 v3 family, two times more memory and four times more Solid State Drive storage (SSDs) than the D-series. Full details of the server specifications can be found on the VM Pricing Pages
Data Storage choices for a VM
When a VM is created within Azure it typically comes with 2 types of local disks. The first disk drive is intended to be used for the Operating System (OS) which will vary depending on the type of OS being deployed. For a Windows based system, you will get a standard C: drive or if it is a Linux type build then you typically see the OS disk defined as /dev/sda . There is also capacity for a local storage disk that can be configured on each VM. This will be a D: drive on a Windows system and will typically be /dev/sdb on a Linux system. This local storage is intended to be used for temporary calculations, cache files etc.. so should not be used to store your data long term. Your data should be therefore be stored on separate storage that is then attached to your individual VMs as needed. There are a number of choices that can be made in terms of storage speed & the amount of redundancy required so it is important that you select the right type of data storage and prepare it before building out the VMs. There are also a number of data storage mechanisms that you can choose to use such as block blob, page blob or NoSQL type data tables.
For most customers the standard storage option will provide fast, secure & redundant storage for the majority of VMs. There is now also a Premium storage solution that provides very fast SSD storage solution for systems that require high speed storage systems. You can also choose from 4 levels of Redundancy starting with Locally Redundant Storage (LRS) option with it’s 3 copies of your data within your local Data Centre (DC). The next level up is Zone Redundant Storage (ZRS) which also provides 3 copies of the data but some of those copies are located in one of the neighbouring Azure DCs. There are then two higher levels of storage redundancy that keep 6 copies of the data in multiple Geographic regions. The first of these is Geographically Redundant Storage (GRS) that keeps copies of your data in several regions and then there is Read-Access Geographic Redundant Storage that also allows you to read that data in another region quickly in the case of a disaster occurring. There is therefore more storage options than you might initially think so it is a good idea to plan out the size & type of storage that you will require before you start building VMs.
Azure offers a wider choice of features than is typically found in many Gen 1.0 Hypervisor farms, so it is wise to look at all the choices available for things like server specifications, storage types, redundancy levels etc.. That way you can pick out the best solution that will meet your needs while still being cost effective. It is also worth pointing out that some of these choices are locked in when you build your VM so that changing them afterwards can mean having to wipe and then rebuild the VM again. Taking the time to determine which of these service levels is often the best way to ensure that you have a solution that will stand the test of time. I hope that gave you an overview of some of the options to consider when building or moving VMs in Azure . In Part 2 of this series we will look at the typical source environments that your VMs will come from, how the Azure IaaS VM architecture is built and a number of different tools that you can use to move a VM into Azure.