More and more people realize that Microsoft Azure can be a huge benefit in their day to day business. The scalability of services and speed with which you can run your business on a global scale is unprescedented to anything you would be able to accomplish in your own datacenter.
The Azure web interface looks straight-forward enough, but after working with it for a few days, weeks, months or after following one of my Azure classes, people soon realize that Azure really consists out of a lot of “moving parts”. This blogpost I’ll focus on all moving parts surrounding a Virtual Machine in Azure. Lots of readers will surely think:”Come on, it’s not that different from an on-prem VM, is it?” I could just give you the answer right away, but that would make for a really short blog post, wouldn’t it?
Part 2: Set up the prerequisites
Welcome back to part 2! You’ve already made it through part 1 of this series, which hopefully means I’ve succeeded in convincing you to plan ahead, when starting to deploy services on the Microsoft Azure platform. It is still all about the application, in this Cloud first, Mobile first world we currently appearently live in… So before doing anything remotely technical in Azure, be sure that the application or service you are planning to deploy on Azure is in fact supported by the vendor when placed on Microsoft’s public cloud platform.
Being part of the “consolidation and virtualization” generation, this really takes me back to the early times of virtualization, where application developers incisted on running their apps on physical servers to provide support. It was only when you encountered issues or during maintenance you (and they) had to admit it had been running flawlessly inside a virtualized environment for ages. This currently is the state with applications and “cloud”. Will it run ok? Probably…. Is it supported? Not always… So be sure to check, and check again to ensure yourself of support.
Having said that, now it’s finally time to take a look of all moving parts within the Virtual Machine. In the drawing below I’ve tried to map out all relations between a Virtual machine and relations with other direct objects in Microsoft Azure.
Now, where to start? Since we’re “only” setting up the prerequisites during this post, and not the Virtual Machine itself, first we’ll start by doing a little inventory on-premiss. We’ll have to know a few basic values of the workloads we’re moving, to be able to garantuee performance and stability on the cloud platform. The questions I generally ask, and they differ somewhat by workload, customer, situation are:
How is the service currently sized?
What I’d like to recieve in my answer are:
- number and type of (virtual) cpu,
- amount of memory
- allocated diskspace
How is the network connected?
- Kind of NIC
- Expected network load
- Expected amount of traffic between internet and Virtual Machine
- Expected amount of traffic between on-premise datacenter and Azure Virtual Machine
How is the application designed?
- No SLA on single deployments
- Ports used for applications?
- Can the application handle a scaled-out front-end?
- Do we need connectivity to on-premiss datasources?
- Do we expect latency issues? In that case we could use Affinity groups.
How will we take care of the data in Azure?
- Is there a specific back-up and restore procedure in place for services in Azure?
- What’s your backup target? Another Azure region? Will you back-up to a target on-prem? (Yes it happens)
With all of the answers in a spreadsheet, we can finally make a start to create the vm in a planned matter.
Step1: Create the affinity group (when needed)
Since we might expect some latency issues with our application, it could be a wise decision to use an “Affinity Group” this affinity group makes sure that the resources within this group are kept as close together as possible. More information on these groups can be found here.
Affinity groups can be created in advance in the Azure Portal. You navigate to settings, Affinity groups, and click “new”. In the next field you’ll define the name, specify some description (e.g. name of the application it concerns), and in what Azure datacenter region your services will be kept as close together as possible.
Step 2: Create the Cloud Service.
Cloud services are a remainder of the time when Azure was a SaaS only platform, but still, in today’s world they still serve a purpose, they in fact provide us with access to vm’s and services they host. It’s important to know, even with Iaas, that the cloud service holds the Public IP address in Azure, and you gain access to the vm through the public ip address or cloud service name (cloudservicename.cloudapp.net) followed by a colon (:) and the portnumber of the vm.
Today, we’ll only create the cloudservice, or to speak in pictures, the doorway to our services.
When you have multiple applications you want to deploy to Azure Iaas, be sure to create separate cloud services for applications that use the same port numbers; e.g. you could technically put an ADFS server and a web application server in the same cloud service, but that will not give you the expected results, since both items like to use port 80 and 443.
We can create a new cloud service through “New” (the big + mark on the lefthand side of the screen), Compute, Cloud Service, Quick Create.
We use “Quick create” this time, since we didn’t receive an application package from our dev(-ops) friends to deploy this time. More information on how to implement those cspkg and cscfg files can be found here. Something to take notice of is that when you use a pay-per-use subscription, you will have a limitation of 20 cloud services at the start. You can contact “Billing Support” to remove this limitation.
Step 3: Create a virtual network
Before we just create something from the top our minds, it is a best practice to consult your friends over at the networking department. You really don’t want to be using a subnet already in use somewhere in your company in Azure, especially when you are creating a hybrid datacenter, like we will in this serie of posts. I know it can take some time, getting the answers you need, but in the end, it’s going to be worth it.
Before you start creating your happy Virtual Network, you’ll also want to know whether you’ll use it for cross-site connectivity. When you have all information, you can create the virtual network as needed at once. Why you ask? Since network operations in Azure can take significant times to complete… That’s why….
Step 3: Create the Storage Account
Finally we’ve come to the last step in our long list of pre-requisites; and it’s to create the container (service) to host our virtual hard drives, VM configs, and so on… The Storage Account. Again, there are some limitations here, people… So plan ahead…
Operational Limitations on storage accounts:
- Maximum number of IOPS in a storage account: 20.000
- Maximum amount of storage in a single storage account: 500TB
- Maximum amount of storage accounts in a pay-per-use subscribtion: 100
I know these values don’t look like “limiting factors” to the most of us, but this could be a reason to divide the storage of vm’s between several storage accounts, IOPS wise.. Be sure to check these specifications for your specific servers/usecase in Azure.
You create a storage account in the User Interface through “New” -> Data Services -> Storage -> Quick Create
Provide a name (in all lowercase), a region or affinity group and the type of storage you need. When the Storage account is created, please take note of the following warning…. Please, keep the storage account credentials as secret as you possibly can. When those credentials are out there, in the big and evil world… Anyone with those credentials and tools like “Cloudberry Explorer” can connect up to that storage account and have their way with your data. So be very, very carefull.
Another thing with this storage account is that it’s a (personal) best practice to enable monitoring of it right from the start. Yes, it will consume some additional storage, but when issues occur, you’ll thank me. Even Microsoft support will thank you, since they are not monitoring the data in your blobs, since… it’s your data…
The only thing we can’t really set up in advance is the availability sets. These availability sets will provide uptime for your service, even when Microsoft is restarting one of the vm’s in this set for maintenance purposes. We’ll cover this special group of servers when we create our vm in the next post. This functionality is ofcourse directly tied to the application. Does it support to be balanced across multiple vm’s?
With these words of warning and advice it’s time to wrap up this blogpost on the pre-requisites that are in play when you “just create a virtual machine”. In the next one we’ll finally get to the (not so) exciting bit, create the virtual machine! In the mean-time, stay safe and cloudy!