From PaaS to IaaS… networks and machines in Microsofts Azure Cloud!

 As Microsoft announced “Azure 2.0” this summer, they extended their capabilities to offer Iaas (Infrastructure as a Service), creating support for new scenarios and setups.

Coming from the idea to provide you with a platform to develop your own cloud-based application, this was a very application centric approach, with certain drawbacks in terms of flexibility.

Azures new IaaS features empower you to make the next step and implement hybrid cloud or “fully cloud” scenarios.

This means you can now also create your own virtual networks, sub-nets, DNS servers, hosts, interconnect them with your on-premise network etc.

Unfortunately this mix creates some confusion when you come from the infrastructure department.

Let’s have a look at the “traditional” PaaS schema they use. As soon as you deploy your new platform, Azure will create some public DNS entry, internal DNS resolution, networking, DHCP, etc.

All of this would be encapsulated in what they call a “cloud service”. A cloud service can be seen as a logical compartment for you whole solution, so you, as a developer, don’t have to worry about all the infrastructure details.

And of course this would separate your solution from the other customers on the Azure platform.

Your frontend is accessible from the internet, DNS is set up, your machines can talk to each other, internal DNS resolution is fine, DB up and running, easy!

But what happens when you want to install a new, complete AD forest inside the cloud? With your own DNS installed on the DC, some subnets to separate traffic and servers…

Or you want to extend your local, on-premise network into the cloud to create a hybrid cloud scenario for failover and loadbalancing? How can you use your internal DNS server to ensure consistency across both worlds?

Let’s assume we want to create a new AD forest inside the cloud and use it for testing purpose.

We have two networks, one serves as the internal LAN and one is for DMZ services.

First thing we would do, is to create a new virtual network “OurNewVNet”, let’s call virtual networks VNet from now on, with both subnets.

The network will be 192.168.0.0/16, the LAN segment 192.168.1.0/24 and the DMZ 192.168.2.0/24.

In the last step we are asked to create a DNS server that comes with those networks. But we want to use the AD DNS service which is installed on the new domain controller.

Mmmh, doesn’t exist so far and we don’t know the IP yet…  ok, simply finish this and we will take care later.

Now we deploy our first machine. Every machine needs to be assigned to a cloud service, therefore we will also create one on the fly.

I am not going through all the details in deploying a new virtual machine, I will simply use the powershell commands to explain how it works.

As we define the new machine config with some basic details like size, name, etc. we will also assign the subnet already. 

$vm1 = New-AzureVMConfig -Name $vmName1 -InstanceSize ExtraSmall -ImageName $myImageToDeploy  | Add-AzureProvisioningConfig -Windows -Password $adminPassword -TimeZone $myTimeZone | Set-AzureSubnet "LAN"

Now we will create the new machine and as I said before, we also need a new cloud service for this one. Therefore we will also define some arguments to provision this service.

The cloud service requires a name (quite surprising, isn’t it?), the network it belongs to (and which contains the subnet defined before) and an affinity group.

New-AzureVM -ServiceName $myCloudSvc -VNetName “OurNewVnet” -AffinityGroup ZRH -VMs $vm1

As soon as this machine is provisioned we can  start and install our AD DS and DNS roles on this one. Windows will complain about the dynamic IP address assigned to the NIC but don’t worry, the lease is valid as long as the machine exists.

This is the first thing you need to adjust to, there are no static IPs in the cloud! And don’t try to change this, otherwise you will break your machine. For our example we assume that the IP of the domain controller is 192.168.1.4

Now we know our DNS server, so we can go back to the network configuration and change it for the rest of the machines.

What does this mean? With Azure you can’t change a network in use, except for subnets. Which means you would have to delete the newly installed AD machine to add the DNS server, which you just deleted…

This is when you discover the use of multiple cloud services in one VNet.

Let’s assume we want to install a SQL server now.

We will adjust our powershell commands a little bit:

 $dns = New-AzureDns -Name our-dns  -IPAddress 192.168.1.4

$vm2 = New-AzureVMConfig -Name $vmName2 -InstanceSize Small -ImageName $myImageToDeploy  | Add-AzureProvisioningConfig -WindowsDomain -Password $adminPassword -Domain $domain -DomainPassword $adminPassword -DomainUserName $domainAdmin -JoinDomain $joinDomain   -TimeZone $myTimeZone | Set-AzureSubnet "LAN"

New-AzureVM -ServiceName $myCloudSvc2 -VNetName “OurNewVnet” -AffinityGroup $myAffinityGrp -dnssettings $dns1 -VMs $vm2 

What did we do here? First we created a new Azure DNS Server object which represents the IP of the new domain controller.

In the second step we created our virtual machine config as we did before (there are some additional parameters we will talk later about).

And in the third step we will create again a cloud service $myCloudSvc2 which is tied to the same network but now has also a DNS server configuration.

Therefore all the new servers deployed to this service will receive the correct IP address of our domain controller.

Of course we could have also changed the DNS server directly on every NIC of each host, but this will make it much easier for you deploying multiple machines.

The second advantage of this approach, you might have noticed the additional parameters on the last deployment. This allows you to already add a machine to the Active Directory during the deployment.

As soon as the machine is up and running it is already a domain member, dynamically updated DNS records, group policies etc.

Another advantage of this is the capability to use Windows Azure load balancing options for every cloud service individually. And every cloud service can have dedicated endpoint configurations for internet access.

If you go for a really large deployment, also bear in mind that currently cloud services are limited to a maximum of 25 roles, which means 25 virtual machines.

Implementing the cloud service approach coming from the PaaS world gives you some new possibilities and features for new IaaS scenarios