If you’ve been wanting to learn more about Azure, don’t miss out Azure Week at the Microsoft Virtual Academy.  Every day during the week of January 27th through the 31st, a different Azure topic will be covered.

• Monday: Overview Day – Get Started with Windows Azure Today Jump Start
• Tuesday: Architecture Day – Designing Applications for Windows Azure Jump Start 
• Wednesday: Developer Day – Building Windows Azure Applications Jump Start 
• Thursday: Infrastructure Day – Windows Azure IaaS Deep Dive Jump Start 
• Friday: Mobile Services Day – Mobile Apps to IoT: Connected Devices with Windows Azure

If you just want a quick primer on some Azure concepts, check out my Pieces of Azure mini-series:

• Cloud Services and VMs 
• Virtual Networks and DHCP
• Input Endpoints
• Affinity Groups and Availability Sets

Microsoft has several regional datacenters for hosting Azure IaaS. There are two on the west coast, two on the east coast and two each in Europe and Asia. When you create a VM you are required to select a region, at minimum, where your VM will be located.  If you just go with a regional selection, you leave it up to the Azure fabric to control where your machine is placed.

For more granular control, you have two other components you need to take advantage of – Affinity Groups and Availability Sets.

By creating an affinity group, you are giving the Azure fabric some additional logic to keep your VMs physically closer together within the datacenter. This might be important if you are hosting an application or service that has multiple server components and you want them to closer together to reduce any potential latency across the internal network.

To create an affinity group, you provide a name and create a network that is associated with it.  Then all the VMs added to that affinity group also will be given addressing from the associated virtual network. Affinity groups are created in your Azure settings area.

Having your servers close together in the physical fabric is good, but being TOO close could be bad.  For high availability, you’ll also want to make sure that your servers aren’t all on the same rack or within the same fault domain in the datacenter.  If a whole rack goes down due to a hardware issue, you wouldn’t want an entire cloud service to go with it.

That’s where “Availability Sets” come in.  An “availability set” allows you to define a group of servers that perform the same role and Windows Azure separates them across fault domains and ensures that at least one of them is always available. 

You can set up availability sets in two places: within the autoscale properties for a cloud services (as they are required for autoscale to function), or from the configuration settings of an individual server.

Used with Affinity Groups, you can then get all your servers close together for performance, but separate enough to ensure that your environment can survive fabric maintenance windows or fault events. 

Close, but not too close. Perfect!

Go ahead, say that three times fast! Yes, it’s a tongue twister and when it comes to virtual machines and cloud services, it can be a bit of mind-bender too.  (If you haven’t had a chance to read my previous posts about Cloud Services for IaaS and Virtual Networks and DHCP, you might want to check those out for background.)

In a nutshell, input endpoints are openings in your cloud service firewall.

Because a cloud service has only one external IP address, port forwarding is used to direct various access requirements to the right location.

In this screen shot, you can see that my single cloud service (with a public IP of 137.135.42.10) has four endpoints open, two for the server named “sabina” and two for “franka”.

In this case, the port numbers were randomly assigned and as this is a Windows Server the default ports are for RDP and PowerShell.

By looking at the specific endpoints assigned to “Franka”, we can se that Remote Desktop is using the public port 58155 and PowerShell is using 58392.

Because this Windows Server was spun up using the image from the Azure gallery, I can trust that the Windows Firewall on the OS has the appropriate rules open to allow traffic that is passed through the Azure endpoints to be received by the server.

If I was to add on a different service, like HTTP or FTP, I would need add the endpoint to Azure AND add the appropriate rules to server OS, so it will listen on the proper port. When creating a new endpoint, Azure will suggest the default port numbers, but they can be customized easily.

An important point to remember is that opening the endpoint in Azure won’t guarantee your server will be accessible via that protocol.  You must open the corresponding listener port from within your operating system. This is critical if you are bring your own server image to Azure, as it’s important to make sure that RDP (or your management protocol of choice) is also open on the OS otherwise you will be unable to manage your server once it’s in the cloud.

If you require more fine tuning of your endpoint access with customized ACL lists, that’s not available via the Azure GUI.  However, you can use PowerShell for that level of detail – read more here.

Depending on the work that your servers are doing within your cloud service, you can also configure basic round-robin load balances on those endpoints.  Learn more about that here.

Haven’t tried out Azure yet? Sign up for a free trial today.