The new Azure IaaS features are really promising, the ability to run hybrid workloads part form the private cloud and part from the public one can be an accelerator for new solutions deployments. With the release of System Center 2012 Service pack 1 I started investigating the ability of managing from a “single pane of glass” private and public resources. This task, in System Center 2012, is the AppController realm.
Since I found very scarce documentation on the subject, I decided to wrap up in this article all the steps needed to setup a mixed environment and how to move workloads backs and forth form public to private clouds.
Let’s start with some prerequisites to set a starting point for our efforts:
· System Center 2012 Virtual Machine Manager SP1 installed and clouds defined.
To be fully functional every private cloud shoud have a read/write library defined. This must be specified from VMM as “Stored VM path:”
· System Center 2012 AppController SP1 installed.
· All the VMs you want to manage must be part of a cloud in VMM, Azure ones can only be part of a cloud so this doesn’t matter for Azure
· A functional Azure subscription with at least one storage account defined with at least one container in it. It will be used to store the VHDs.
How to register the Azure subscription
The reference documentation can be found on Technet
In summary a X509v3 certificate is needed to setup the connection. The certificate can be a standard user certificate or a custom generated certificate (http://msdn.microsoft.com/library/gg551722.aspx). If you have an internal CA you can enroll for a standard user certificate, this is more than enough to establish a Windows Azure connection. I will go this way since the use of makecert or IIS are well explained on the Technet documentation previously referenced.
Once you get the certificate it needs to be exported in two formats:
· The public certificate key in .cer format
· The private key in pfx format
Then follow the wizard choosing not to export the private key
Finally chose the .CER format (in my test it doesn’t matter if DER o Base 64 encoded)
To export the private key re-run the same wizard, but this time chose to export the private key
Choose the pfx format and specify a password
Now we have what is needed to setup the connection to Azure. First of all the public part of the certificate (.cer) needs to registered with Azure. To achieve this goal go in Azure management portal, under Settings add management certificate, the current limit is 10 per subscription. The same certificate can be associated to multiple subscriptions.
While in the Azure management portal you must take note of the subscription ID, this info is needed to connect AppController. The subscription ID can be found in several places, the easiest one is on the Settings space after the certificate has been imported.
When you’re set on the Azure side, it’s time to register the subscription(s) in AppController. As a preliminary step you must grant the AppController system network access to Azure, if you need to use a proxy this must be configured under Settings\Connections\Proxy Connection
If everything is setup properly you can now connect AppController to Azure, in the subscriptions space just chose “Add” and enter the following information:
· The name of the subscription, it will become the name of the public cloud in AppController
· Your subscription ID, the one you just got from the Azure portal
· The certificate in pfx format and the password you associated with it when it was exported
That’s it, now AppController is able to manage your Windows Azure subscription.
How to setup a connection from Azure to your internal network
Azure IaaS premits to connect the workloads in the public cloud to your internal resources, in my scenario I definitely need to connect public and private workloads, if this is not your the case you can skip this step. You can find a good guide to setup the connection here.
To better explain the data that you need let’s take the following simplified scenario:
· Internal networks are 172.20.0.0 / 16 and 172.21.0.0 / 16
· The Internal DNS, to solve internal hosts addresses is 172.20.10.1
· The External firewall / VPN endpoint has the following public address 220.127.116.11
On Azure you must define an IP address space that do not collide with my internal ones, it must be chosen so that multiple subnetworks can be defined, the minimum number of subnets to define are two: one for VM connectivity and one for the VPN gateway. In our fictious example let’s chose the following:
· Base address space 10.0.0.0/16
· VM network 10.0.1.0/24
· Gateway network 10.0.0.0/24
When all this data has been collected you’re ready to connect Azure IaaS to your network. Obviously your network guys would want to add some spice, for example they could isolate the Azure facing resources to a specific VLAN or network zone. It mostly depends on their security requirements and there’s no fixed rule, so this must be worked out on a case by case basis.
To implement the scenario follow these steps:
In Azure Management Portal create a new Virtual Network, chose or create an affinity group and a region. Beware not all region are currently enabled for IaaS.
Following the wizard add the base address space and the network for VMs connectivity
Go on to add the internal DNS and to define the gateway network, remember to select “Create a New local network”
Define the internal network address space and the VPN endpoint public IP address.
Finally, you need to create a gateway and once the gateway has been provisioned you need to setup a shared key lan to lan VPN. To get the public gateway IP you need to wait until the gateway is up and running. From then on you can ask the the VOPN shared key and / or download the script to setup the VPN on your firewall (only a limited number of models are supported).
Remember, gateway provisioning takes typically a little while, you must me ready to setup the VPN on your side shortly after the gateway is running. In one of my first tests I tried to setup the VPN after about 24 hours without success, I had to delete and reprovision the gateway.
How to move a VM to the public cloud
No, you cannot live migrate a VM to the public cloud. It would be great, but we’re not quite there.
Remember dynamic memory will not be used in Azure and all VHD must be fixed size, I hope these limitations will be removed before the IaaS service goes final.
If you dare to move a dynamic VHD you’ll get this error at the end of the copy (so many hours too late):
Deploy Windows Azure Virtual Machine (Windows Azure Operation Id: 3e84f05fe88541c694e713a64bb1a37a) failed with error code: BadRequest. Error Message: The blob is an unsupported VHD format. It must be a fixed-type VHD. (StatusCode: Microsoft.SystemCenter.CloudManager.Providers.ProviderException)
To migrate (this is the verb) the VM to Azure the VM needs to be stored in a private cloud. To be stored the VM needs to be turned off and the private cloud hosting the VM must have a Stored VM path configured.
Once stored the VM can be migrated to Azure.
The migration is treated as a service deployment, the diagram will ask:
· The destination cloud (i.e. the Azure subscription)
· The cloud service to be deployed into, it is useful to create a specific service for each VM
· The deployment properties where you can choose the environment (staging or production) and more importantly the virtual network created
· Finally the VM properties, here again the two key properties are the container in Azure that will host the VHD(s) and the subnet that will be used to connect the VM, so that it can communicate with your internal network
Select the public cloud
Create a new cloud service or use an existing one
Define the deployment so that it will use the virtual network created in Azure
In the VM properties remember to connect the VM to the appropriate subnet
Once the deployment information are entered a job will start to copy the VM to Azure, you just need to patient and wait for the whole process to finish.
How to move a VM from the public cloud into the private one
Obviously is possible to move a VM from Azure back to your internal private cloud, but the process is far from being as automated as the inverse migration. Basically, It is a matter of copying the VHD(s) from Azure to an AppController share and from there use VMM to define a VM based on such a VHDs set.
To be able to perform copy and paste operations in AppController at least one share with read/write access needs to be defined in AppController. I didn’t find any best practice, but as a lesson learned from the field I find useful to use VMM library shares as shares in AppController as well. To register a share you need to step into the Library space and then in Shares node.
The steps are really easy and documented in TechNet.
Copy the VHD(s) from the Azure Cloud.
For private clouds AppController inherits and uses roles defined in VMM.
For public clouds a self service user role can be specified in AppController, alas the granularity is limited on a per subscription basis. This means you cannot delegate access to single virtual machines.
This posting is provided “AS IS” with no warranties, and confers no rights.