Importance of Windows Azure Affinity Groups

Importance of Windows Azure Affinity Groups

Sometimes people wonder about Affinity Groups in Windows Azure, and their benefits since for some this is nothing more than a way to logically group both Compute and Storage.

In order to explain this we need to dig a little deep in terms of how Windows Azure Data Centers are created. Windows Azure Data Centers are built using “Containers” that contain clusters and racks. Each of those Containers have specific services, for example, Compute and Storage, SQL Azure, Service Bus, Access Control Service, and so on. Those containers are spread across the data center and each time we subscribe/deploy a service, the Fabric Controller (which chooses based on our solution configuration where the services should be deployed) can place our services spread across the data center.

We need to be very careful with where services are created, if we place a Hosted Service in North Central US and a Storage Account in South Central US the Latency and/or Costs increase as we’ll be charged whenever we get out of the Data Center. If we choose the same Data Center nothing tells us that the services will be physically close together, since one can be placed in one end of the Data Center and the other at the other end which reduces costs and improves latency. It would be great to go a little further and place them in the same Container or Cluster. The answer is Affinity Groups.

Affinity Groups tell the Fabric Controller that the two elements in the example above should always be placed together, close to one another. What this does is when the Fabric Controller is searching for the best suited Container it chooses where it can deploy both elements in the same Cluster, thereby reducing latency and increasing performance.

So in summary, Affinity Groups provide us:

  • Aggregation, since it aggregates our Compute and Storage services and provide the Fabric Controller the information needed for them to be kept in the same Data Center, and even more, in the same Cluster.
  • Reducing the Latency, because by providing information to the Fabric Controller that they should be kept together, allow us to get a lot better latency when accessing the Storage from the Compute Nodes, which makes difference in a highly available environment.
  • Lowering costs, by using Affinity Groups services are placed in the same cluster therefore communications between datacentres are not required.

Don’t forget to use Affinity Groups right from the start as it’s not possible after having deployed both the Compute or Storage to change them to use an Affinity Group.

To finalize, and since now you'll be thinking that this would be very interesting for other services as well, no other services are able to take advantage of this Affinity, since neither of them share the same Container.

Sort by: Published Date | Most Recent | Most Useful
Comments
  • Nice to hear that storage stamps can share the same container than compute nodes, great explanation about affinity groups usage!

  • Good and concise summary, thanks.

  • Slight correction: the fabric controller manages the nodes of a cluster. A higher-level process controls the choice of data center and cluster. This process is called RDFE which is short for Red Dog Front End (Red Dog was the Azure project's code name). The Azure developer portal web site and web service talks directly to RDFE. Mark Russinovich has discussed this in the past. I know about it because I worked on RDFE and the developer portal before I left Microsoft a year ago.

  • Good article! thanks!

  • This is a great article. It gives a nice summary and rationalization for the use of affinity groups.

Page 1 of 1 (5 items)