在Azure当中有地缘组的概念(
此时可以看到在AS01中包含了两台虚拟机实例，此时vm01与vm02一定是被部署在不同的“RACK”上面的，稍后会对此做更详尽的解释，，如下图:
当虚拟机具备了可用性集的属性之后，那么他在迁移的时候底层架构会做判断，例如下图中我有两个节点，分别把一个可用性集中的两台虚拟机部署在了每一个节点上，那么在试图迁移其中一个VM实例时，会有提醒告诉用户当前主机之允许一个可用性集成员，当然这是个warning，并不会强制限制后续操作。
###################################################################
但是从我个人角度来看，winserver+system center私有云当中的可用性集并无法和公有云比拟，可以说完全无可比性，为什么呢，因为首先在多租户场景中可用性集的存在是非常有必要的，但是私有云的方案并无法满足租户粒度的隔离，也就是说，在VMM中创建一个可用性集就是唯一的，但是在真正的云平台上，不同租户一定要在自己的隔离边界中创建可用性集，而不是仅依赖平台级的能力，那么Azure中的可用性集又是如何实现的呢？
首先Azure中的可用性集适用于两个场景，一个就是计划性维护，就是世纪互联会做顶定期的平台维护，好比网游公司的定期维护一样，这种维护窗口内的reboot是用户无法选择的，是一定要接受的。另外一种就是非计划性维护，也就是因为的RACK宕机。
两种维护都依赖于两个关键词，即FD(fault domain)和UD(update domain)，可以称为故障域和更新域，故障域就好比一个单故障点，好似上面提到的“RACK”而更新域则是针对每一台虚拟机实例，例如在计划维护时需要对租户的虚拟机进行reboot，此时如果Azure发现某个租户的虚拟机不在可用性集中，那么直接就reboot了，如果发现在一个可用性集中，就会按照UD顺序来进行重启，而不会一下子全reboot，以此来保障业务连续性。
同理在部署时，可用性集会考虑FD的分布，来尽量打散多个VM实例，以通过在不同的故障域中放置资源来抵消单点故障带来的破坏性影响。
因此在理解了可用性集的工作机制后，对于如何配置和规划资源也需要动动脑筋，从最佳实践上来看，对于一套应用系统，不同层次中的虚拟机应该放置在不同的可用性集中，以避免在一个可用性集中混淆了不同功能的虚拟机实例，例如下图中若是错误的将Web层与Data层的虚机放置在一个可用性集中，那么在例行维护中可能会导致错误的reboot顺序而产生业务中断。
回到刚才的demo中，在AS01中存在两台虚拟机时，可以在云服务中查看到当前的FD与UD信息，比如这里故障域和更新域都是不一样的，下图中分别是0和1。
而在三台实例的时候，更新域是0，1，2，而故障域则是0，1，0，也就是说如果故障域0出现了问题，但至少故障域1上还会有VM02在运行，同理在reboot时候，更新域0，1，2会依照顺序来启动而不会同时发生reboot，对于一个可用性集中的更新域数量，msdn中表示是5个，第六台虚拟机将会按照第一台来做放置计数，第七台按照第二台来识别，以此类推。
#################################################################
可用性集是一个非常实用且必要的功能，希望在windows和system center的下一版本中，通过私有云也能够实现更加灵活的可用性集配置。
人生的小河，总要流过森林，荒漠，
