在Azure当中有地缘组的概念(http://maomaostyle.blog.51cto.com/2220531/1585696),之前的博文也提到过，这是一种提高“性能”或者说是尽可能减少系统间延迟的手段，是出于性能保障的，那么从可用性角度而言，就要提到“可用性集(Availability set)”，Availability set是目前云平台上非常流行的一项“基本”功能，主要是提供一种高可用性的保障，在Azure当中对虚拟机提供最高99.95%的SLA承诺，注意是最高，因为如果用户期望获得99.95%的可用性，前提是你的虚拟机实例要放置在可用性集中才可以，那么就来具体瞅瞅何为可用性集。

公有云服务无论是微软的，阿里的或者亚马逊的，都有类似的功能，只不过可能名称不一样，以Azure为例，默认创建虚机时提供可用性集的配置选项，如下图：

同样也可以在创建虚拟机之后再配置可用性集，如下图:

例如我创建了一个叫做AS01的可用性集，在门户中会显示一个提醒，也就是说，当前可用性集中只有一台VM，这并没有任何意义，因为可用性集是要保证至少两台或两台以上数量的VM放置在可用性集中才有效果，为什么呢，因为同一个可用性集中的VM会被部署在不同的RACK上面，这个RACK可以简单理解为一个机架，或者说是一个单故障点，那么假设你有三个VM实例，可能有一台被部署在RACK1，另外两台在RACK2上，因此即便RACK2出问题宕了，但是底层会保证RACK1上仍留存一个在运行的VM实例。

在我的Azure订阅中再创建一台VM放置在之前准备好的AS01可用性集中，如下图:

此时可以看到在AS01中包含了两台虚拟机实例，此时vm01与vm02一定是被部署在不同的“RACK”上面的，稍后会对此做更详尽的解释，如下图:

####################################################################

上面提到的是Azure公有云当中的可用性集，那么在私有云中是否也具备这样的能力呢，答案是肯定的，下图依然是基于微软的私有云解决方案system center，随便找一台云中的虚拟机查看属性，在硬件配置中可以看到可用性集的管理，通过UI界面可以直接创建和分配可用性集，如下图:

分配后通过刷新虚拟机的动作就可以显示出当前所属的可用性集，通过下图可以看出私有云方案中虚拟机可以同属于多个可用性集，也就是说如果一套业务系统中的某一台虚拟机与其他前端或后端可复用，那么就比较适合下图中的场景，例如我有两个web server公用一个SQL服务器，那么web server01与SQL是一个可用性集，web server02与SQL是另外一个可用性集。

上图中是对VMM中的虚拟机进行可用性集管理，同样也可以通过windows cluster进行操作，因为在cluster中的一个属性“antiaffinityclassnames”对应的就是VMM中的availability set，所以通过PowerShell对某一个对象赋值，例如下图：

然后回到VMM进行对该虚拟机进行刷新，依然可以达到同样的效果。

当虚拟机具备了可用性集的属性之后，那么他在迁移的时候底层架构会做判断，例如下图中我有两个节点，分别把一个可用性集中的两台虚拟机部署在了每一个节点上，那么在试图迁移其中一个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的下一版本中，通过私有云也能够实现更加灵活的可用性集配置。

云平台中的可用性集