Tags

, , , , ,

Stripping away the marketing jargon, Microsoft’s Azure is essentially a platform onto which customers can deploy almost any kind of computing service relatively quickly. The service might be a public-facing web site, a HPC cluster, a test environment or an extension to the corporate network. Practically anything that could be done with a data centre is possible with Azure.
The pricing system is kind of messy. Not only is Azure usage billed by the time and number of CPUs, but there are several tiers for things like Visual Studio, TFS and Windows Server. A VM with 35 processor cores running Visual Studio Ultimate would cost far more than a VM with two cores running Visual Studio Express.

The Services
Azure has an extensive range of options for provisioning VMs, web applications, databases and other services. Some of them are actually developed by third-parties and resold by Microsoft.
By clicking the ‘NEW’ button, we can browse through the panels showing the available Azure services. One of the first things I did was set up a couple of Windows Server and Linux VMs, initially thinking I could run public-facing web applications with just these.

azure-setting-up-new-vm

Azure includes the admin dashboard, status messages and some fancy performance analytics for each VM.

azure-analytics

Connecting to the VM
Unless a desktop environment and remote desktop server are installed on a Linux VM, we must use SSH to access it. Of course, this could be done from another Linux machine or using PuTTY on Windows.

azure-ssh

Getting a remote desktop session with the Windows VMs is much easier, a matter of clicking the Connect button to start the local Remote Desktop program.

azure-dashboard-connect

Virtual Networks
At this stage there are virtual machines that we can connect to individually over SSH/RDP. Unfortunately it appears each VM runs in a sandbox with an isolated private address. To get several VMs sharing resources and communicating, they need to be placed in a virtual network.

In ‘NETWORK SERVICES’ – ‘VIRTUAL NETWORK’ – ‘CUSTOM CREATE’, enter the name of the network. On the next dialogue, we get options for setting the DNS Servers and VPN connectivity. These settings don’t really need to be configured at this point.
For the Virtual Network Address Spaces, we could divide the addresses into subnets. For example, we might have a subnet for client-facing machines, and a subnet for back-end database servers. We’ll come back to this shortly.

virtual-network-address-spaces

And that’s how simple it is to create a ‘virtual network’, which at this point, is merely an address space. At least one VM is added to make use of this ‘network’, and the image must be selected FROM GALLERY.
Proceed with the VM configuration as before. Under the REGION/AFFINITY GROUP/VIRTUAL NETWORK drop-down menu, the network is listed.

virtual-network-drop-down

If the VM was successfully added, it will be listed as a network resource.

virtual-network-resources

SSH/RDP connections to each VM can also be established from outside the virtual network, using the [name].cloudapp.net addresses. Connectivity between VMs can be tested by pinging each other. From here, all kinds of services can be added, from SQL back-end servers, to IDS and firewalls.

Joining Local Resources to the Virtual Network
Using a VPN connection it’s possible to join local and remote resources into a single logical network. The process for setting this up is pretty straightforward.
A root certificate needs to be supplied for VPN connections. This can be generated on the local machine using the makecert.exe program.

make-root-vpn-cert

Although a client certificate isn’t really required at this stage, it might be a good idea to create one using makecert.exe against the root certificate. Copy the root certificate to another location before doing this, as it’ll be overwritten.
Both files should have the .cer extension. We’ll come back to these shortly.

make-client-vpn-cert

Two more things are required for a VPN connection: a subnet from which IP addresses are allocated to clients, and a VPN gateway. Both are configured in the Azure portal. In the network configuration, tick the checkbox for ‘point-to-site connectivity’ and add a VPN subnet.

vpn-address-space

Next we create the VPN gateway in the main dashboard interface. It’s at this point the root certificate created earlier is uploaded. If successful, the interface will show the gateway’s public IP address and hyperlinks for the Client VPN Package.

created-gateway

The Client VPN Package, once installed, adds the network settings that enable us to establish a VPN connection from the Control Panel.

Advertisements