Azure Availability Set vs Affinity Group

azure

https://stackoverflow.com/questions/25472549/azure-availability-set-vs-affinity-group

Affinity Group

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.

https://docs.microsoft.com/zh-cn/azure/virtual-machines/windows/manage-availability

在可用性集中配置多个虚拟机以确保冗余

要为应用程序提供冗余，建议将两个或更多虚拟机组合到一个可用性集中。 数据中心内的这种配置可以确保在发生计划内或计划外维护事件时，至少有一个虚拟机可用，并满足 99.95% 的 Azure SLA 要求。 有关详细信息，请参阅虚拟机的 SLA。
重要
避免将单实例虚拟机单独地置于可用性集中。 此配置中的 VM 并不符合 SLA 保证，在出现 Azure 计划内维护事件时会停机，除非某个 VM 正在使用 Azure 高级存储。 对于使用高级存储的单一 VM，Azure SLA 适用。
基础 Azure 平台为可用性集中的每个虚拟机分配一个更新域和一个容错域。 对于给定的可用性集，默认情况下会分配五个非用户可配置的更新域（可以增加 Resource Manager 部署以最多提供 20 个更新域），以指示可同时重新启动的虚拟机和底层物理硬件组。 在单个可用性集中配置了 5 个以上的虚拟机时，第 6 个虚拟机将放置在第 1 个虚拟机所在的更新域中，第 7 个虚拟机将放置在第 2 个虚拟机所在的更新域中，依此类推。 在计划内维护期间，更新域的重启顺序可能不会按序进行，但一次只重启一个更新域。 重启的更新域有 30 分钟的时间进行恢复，此时间过后，就会在另一更新域上启动维护操作。
容错域定义一组共用一个通用电源和网络交换机的虚拟机。 默认情况下，在可用性集中配置的虚拟机隔离在 Resource Manager 部署的最多三个容错域（经典部署的两个容错域）中。 虽然将虚拟机置于可用性集中并不能让应用程序免受特定于操作系统或应用程序的故障的影响，但可以限制潜在物理硬件故障、网络中断或电源中断的影响。