If you would like to read the other parts in this article series please go to:
- Planning a Hybrid IT Infrastructure using Windows Azure Infrastructure Services (Part 1)
- Planning a Hybrid IT Infrastructure using Windows Azure Infrastructure Services (Part 3)
- Planning a Hybrid IT Infrastructure using Windows Azure Infrastructure Services (Part 4)
Introduction
In Part 1 of this series, we talked about the phenomenon of hybrid IT, the hybrid cloud, and advantages of hybridization. Then we looked at questions you can ask to guide the planning and design process, and the steps involved in that process. This time, we’re going to zero in on Windows Azure Infrastructure Services and Azure Virtual Networks.
Advantages of Windows Azure Infrastructure Services
As we noted in Part 1, Windows Azure Infrastructure Services makes it easy for you to put virtual machines into the Windows Azure cloud in a fashion similar to the way you stand up virtual machines on your own corporate network. I talked a little about Azure Infrastructure Services in the ISAServer.org newsletter in March, so if you read that, you know I’m pretty excited about this new Microsoft offering.
The goal of Azure Infrastructure Services is to make it possible for you to move some or all of the virtual machines you currently run on-premises to Azure Infrastructure Services in the cloud. The rationale behind this is that because Windows Azure is so large, you can benefit from the economies of scale so that you may be able to actually run your IT infrastructure at a lower cost in Azure Infrastructure Services than you could on-premises.
That may or may not prove to be true in your particular case, but one thing is for sure: if you’re running a virtualized infrastructure now, there is a good chance that you may be using a public cloud infrastructure service provider at some time in the future. There are a number of reasons that you might want to consider doing so. Which provider you choose is going to be based on the features and capabilities you require. Infrastructure as a Service providers vary in terms of what they offer in regard to networking, storage and compute services, as well as uptime guarantees and performance offerings. To make the best decision for your organization, you’ll have to determine what you need in advance and then compare your requirements with what each of the different vendors has to offer.
Components of Windows Azure Infrastructure Services
Azure Infrastructure Services can be thought of as a combination of Azure Virtual Networks and Azure Virtual Machines. You can put virtual machines on an Azure Virtual Network and those virtual machines will be able to communicate with each other and with other network entities.
In some ways, you can think of an Azure Virtual Network as being similar to the Hyper-V virtual switch. The exception to this is that Azure Virtual Networks suffer from the PaaS history of Windows Azure in that if two virtual machines are on the same Azure Virtual Network but part of different “cloud services” then they won’t be able to communicate with one another. I hope that’s something that will be fixed in the future, because it’s totally unintuitive and is likely to drive many potential customers bananas.
All about Azure Virtual Networks
If you are new to Windows Azure, there are some key things to know about Azure Virtual Networks:
- When you create an Azure Virtual Network, you need to use a private IP addressing scheme. You cannot use public IP addresses. In addition, you need to make sure that you don’t use addresses that are in use on your private network, because you might want to connect your private network to the Azure Virtual Network. If you have overlapping IP addresses, you won’t be able to do that.
- You can connect your corporate network to one or more Azure Virtual Networks. To do this, you create a site to site VPN between your network and the Azure Virtual Network. If you have multiple Azure Virtual Networks, you can connect your corporate network to all of them. However, if you have multiple corporate points of presence, a single Azure Virtual Network can only connect to one of them.
- Azure Virtual Network does not support high availability protocols such as BGP and it does not support NLB for your on-premises VPN gateway. If you want high availability, you’ll have to use some other method, such as having a cold standby that can spin up in the event that the primary VPN gateway goes down.
The site to site VPN between your on-premises network and the Azure Virtual Network is created by establishing an IPsec tunnel mode connection. Note that Microsoft only supports specific on-premises VPN gateway devices. The good news is that if you don’t have a supported device, you can use Windows Server 2012 RRAS to create the site to site VPN connection and that’s considered a supported device. In other good news, Microsoft provides configuration scripts that you can use to configure your on-premises VPN gateway. The bad news is that the scripts are not pre-configured based on what Azure knows about your network – you will have to edit the scripts yourself.
Virtual machines on an Azure Virtual Network are assigned IP addresses via DHCP. You cannot configure any virtual machine on an Azure Virtual Network with a static IP address. If you do that, you will not be able to connect to that virtual machine, because the Azure Virtual Network system will detect that device as an “unknown” and will shut down communications.
Although virtual machines on an Azure Virtual Network receive their IP addressing information through DHCP, they keep their IP addresses for the lifetime of the virtual machine. The only exception to this is if a virtual machine goes through something called “service healing”. If a virtual machine is service healed, it will be moved to another server in the Azure datacenter. If you created the virtual machine through the Azure portal, the virtual machine will lose its IP address. If you created the virtual machine by using PowerShell, then the IP address will not be lost. Why does it work this way? I don’t know; I wasn’t privy to the thinking that went into making that decision.
When you create an Azure Virtual Network, you can ask for a collection of IP addresses that represent a summarized network ID for all the subnets you create within the Azure Virtual Network. While you can subnet your summarized block, there is no routing between these subnets and there is no way to execute access controls between the subnets (at least not at the infrastructure layers). If you want to create some kind of isolation between the subnets you create, you will need to use something like IPsec on the virtual machines themselves to get this kind of network access control.
Note:
There might be changes in the future that allow you to create network ACLs to allow or deny traffic, but at the time of this writing, such network ACLs are not available.
Name resolution
Azure Virtual Network includes some built in DNS capabilities. However, these are limited to machines that are part of the same “cloud service”. This can be confusing, because most of us think in terms of machines that are connected to the same virtual switch as being able to communicate with each other, and therefore we think about the network as the partition for communications. However, with Azure Virtual Networks, only machines that are in the same “cloud service” will register with the Azure DNS. This is a very limited DNS functionality, as this only allows the virtual machines in the same “cloud service” to resolve each other’s names.
If you want virtual machines to resolves the names of other computers, such as those on the Internet or on the corporate network, you can add DNS servers to the Azure Virtual Network configuration. This is similar to configuring a DHCP option to assign a DNS server address. The DNS server that you assign to the virtual machines can be one that you create on the Azure Virtual Network itself, or it can be an Internet DNS server, or it can be an on-premises DNS server. If you put a domain controller on an Azure Virtual Network, then make sure you configure it as a DNS server too, and make sure that you create the domain controller using PowerShell, since you don’t want it to get service healed and have its IP address changed.
Connecting to virtual machines
There are multiple ways to connect to the virtual machines on an Azure Virtual Network. By default, the Azure Virtual Network will make each of your virtual machines an RDP “endpoint” and open an inbound port that you can RDP into. Note that Azure doesn’t use the default RDP port. You do have the option to disable the endpoint if you don’t want to expose your virtual machines’ RDP connections to the world.
Another way to connect to virtual machines is by going through a site to site VPN connection between your on-premises network and the Azure Virtual Network. This is the same method by which you would connect to computers in a branch office over an RDP connection when you have a site to site VPN between main and branch offices.
If you are off the corporate network and don’t want to VPN into the corporate network, you can use what Microsoft calls a “point to site” connection to connect to the virtual machines on your Azure Virtual Network. This connection is just an SSTP remote access VPN client connection to the Azure Virtual Network. While this option wouldn’t be used to connect on-premises infrastructure to the Azure Virtual Network, it’s more secure than allowing the entire world to have RDP access to the virtual machines on your Azure Virtual Network.
Terminology
Azure uses some unusual new terminology with which you’ll need to acquaint yourself. For example, the IP address that’s used to connect to virtual machines from over the Internet is called a VIP (virtual IP address). This is the public address on the Azure network that ports forward connections to virtual machines on an Azure Virtual Network. Ah, but you thought that a VIP was the virtual IP address used in an NLB solution, didn’t you? Well, it’s not the same thing in Azure. I’m not sure why they called it by that name, but remember that it’s not the VIP that you knew before and it’s not load balanced, as far as I know.
They also used the term DIP (I’m not sure what the “D” stands for, because when you do a search for “Azure DIP” it might mean “direct” or it might mean “dynamic” depending on the source document). Regardless of what the “D” means, the fact is that once again, it is not related to an NLB DIP – which is a dedicated IP address that is not shared among members of the NLB array. An Azure DIP is completely different; an Azure DIP is the DHCP assigned IP address that is provided to the virtual machines on an Azure Virtual Network.
Summary
If you understand these basics of Azure Virtual Networks, you’ll have a leg up on the competition and you’ll be ready to create an Azure Virtual Network. In the next article in this series, we’ll do just that: create a real Azure Virtual Network in Azure! See you then. –Deb.
If you would like to read the other parts in this article series please go to:
