LinkedIn | FaceBook | Twitter
UPDATE - 09/14/2015: This is an older post. Check the http://azure.com site for more current information.
Windows Azure has added Infrastructure-as-a-Service (IaaS), the ability to deploy, run and manage Virtual Machines, to its growing list of services. You can create Virtual Machines from a gallery, upload them from images you create locally on Hyper-V (that's right, you can do that, even from PowerShell) and of course you can just jump right in and just click the "Plus" sign at the bottom of the Windows Azure Management Portal, then hit Compute, then Virtual Machine and then Quick Create. Enter a few fields and you're off to the races. (video here: http://www.youtube.com/watch?v=keGhdAqfqBA)
Of course, that works just fine - but if you do it that way you're doing it wrong. There's a better way - there are a few steps you should take before you deploy a Virtual Machine, and a few steps after. In general, the process looks like this:
Note - some of these steps need to be done only once, others once per logical group of Virtual Machines, and so on. Hit the links below for more info on when to do what.
An Affinity Group is a logical grouping that dictates how Windows Azure will lay out the resources assigned to it. When you create services, you can assign them to the Affinity Group, and the Fabric will deploy those into the same Datacenter cluster. Create one these per grouping that you want.
Steps to do that: http://msdn.microsoft.com/en-us/library/windowsazure/jj156209.aspx
The TCP/IP address for Windows Azure Virtual Machines come from a predefined range. You can just let us pick that for you, or you can create your own Virtual Network that has a user-defined range of DHCP addresses, and even place a DNS Server or connect your local network to the Windows Azure network for your Virtual Machines. When you create the Virtual Network, you can assign it to the Affinity Group. It's a way of grouping machine networks together. Create one of these per group of Virtual Machines that you want to have the same DHCP and DNS Server.
More Detail: http://msdn.microsoft.com/en-us/library/windowsazure/jj156007.aspx
Steps to do that: http://www.windowsazure.com/en-us/manage/services/networking/create-a-virtual-network/
Windows Azure Virtual Machine Disks are stored in Windows Azure Storage. That's a great benefit. If you don't define a Storage Account and a Container first, The Windows Azure Management Portal will do that for you as you create the machine. Defining that Storage Account and Container ahead of time allows more control, and a better naming convention than what we'll pick for you. Read more to find out the strategy you should use to group the disks. Also, some workloads such as SQL Server have a best-practice of creating a separate disk for data and backups.
More Detail: http://www.windowsazure.com/en-us/develop/net/how-to-guides/blob-storage/#what-is
Steps to do that: http://www.windowsazure.com/en-us/develop/net/how-to-guides/blob-storage/#header-3
You have a lot of choices here, from creating the Virtual Machine quickly, from a Gallery with pre-loaded software (like SQL Server), or even choosing from Windows or Linux. You can also create the Virtual Machines by uploading an image of your own, or create them through PowerShell. With the previous steps completed, you can select those pre-defined entries as you build the machine - just select them from the drop-down menus when prompted.
More Detail: http://msdn.microsoft.com/en-us/library/windowsazure/jj156003.aspx
Steps to do that:
When you build more than one Virtual Machine (always a good idea, and required for availability) you can load-balance the IP ports for them, and you can also specify that they are on separate "fault domains" for greater availability. This is called an Availability Set. Even if you think you're only going to build one VM, you can add the Availability Set it up now and use it when you grow the systems. Create one of these per group of Virtual Machines you want to add into your High Availability strategy.
More Detail: http://azure.microsoft.com/en-us/documentation/articles/virtual-machines-manage-availability/
How about assigning a VM to a vNet?
Is that doable?
Affinity groups are becoming legacy and new VNETS should be created a regional vnets and not bound to affinity groups. You can still create vnets with affinity groups if required for special cases through powershell.
Almost a year since its publication this remains a good article, except that in Step One one may want to reserve a public virtual IP (new feature, needs to be reserved before creating the VM) instead of creating an affinity group (deprecated feature, prevents the use of other resources later).
Reverse DNS is another new feature that became available after this article appeared, and thus could be an interesting additional step.