IT团队希望确保IaaS的高可用性，如Azure，必须在后台工作。创建可用性组是防止中断的一种方式。

你无法像在私有数据中心那样控制云硬件，因此要采用一种新的应用部署决策方法，从而在IaaS上实现弹性。

默认情况，当管理员在Microsoft Azure或其他公有云基础设施中创建虚拟机时，没有真正的保护来防止单点故障（SPOF）的停机时间。如果该云中的物理节点发生故障，则VM将在一个单独的物理节点上重新启动——用户无法控制它，并且必须进行保护虚拟机工作负载的部署决策。

在企业部署其应用之前，要了解有关云计算的高可用性的一些问题和解决方法。

编者按：本文以Microsoft Azure基础设施即服务（IaaS）为例。虽然这里提供的信息可以作为通用指南，但请咨询您的公有云提供商，以获得与基础设施有关的具体细节。

区域高可用性

云概念是Azure设计的基础。可用性区域——在Azure中被视为单个位置——本质上是众多的在相对较近的地理位置的物理数据中心。因此，处理云应用部署的管理员可以选择将系统配置为在发生大规模中断故障时转移到区域内的备用数据中心。

在每个数据中心内运行的群集将数千个网络物理节点关联起来。当其中一个节点遇到故障时，其托管的VM将在群集中的另一个物理节点上重新启动。每个使用公有云的站点都有成百上千群集。

正如私有数据中心的虚拟机管理程序需要打补丁一样，在公有云中的物理刀片服务器上运行的管理程序也是如此。对于托管云应用部署的单个机器来说，这是个坏消息。一年都有那么几次，虚拟机必须在底层管理程序升级时迁移。管理员不必担心来自云提供商（如Microsoft的DNS和Azure Directory）的维护对服务的影响，但客户的工作负载是他们的责任。

Azure使用可用性集来处理客户虚拟机的中断问题。可用性集使管理员能够分配几台机器，例如放置在不同区域中的前端Web服务器。这种分散在云计算架构中创造了高可用性，因为前端服务都可以处理请求，而不管单个故障或服务器更新。Microsoft将可用性集定义为虚拟机的逻辑分组； 可用性集为云提供商提供了云应用部署的结构信息。

任何希望将Microsoft维持在99.95％的正常运行时间的服务级别协议的管理员都应该使用这些组来提供可用性。管理员需要在云计算中实现高可用性的最大教训之一就是像对待牲畜那样处理托管基础设施，而不是像对待宠物那样。管理员必须针对单个节点进行设计，从而对云应用部署的功能产生最小的影响。

磁盘在Azure中的呈现方式与在本地托管的IT基础设施中不同。即使是存储节点也需要升级，因此管理员将其视为单个节点的磁盘实际上在Azure数据中心中至少复制了三次。而额外的冗余也要很高的成本——云计算的高可用性不是免费的。

可用性集为云应用程序部署考虑到了故障域和升级域。故障域是一组基础设施项目，可能会受到单个问题的影响，例如局部电源故障。升级域由经过分组并以可控的方式打补丁的机器组成。

可用性集确保云托管服务对其接收的请求执行其职责。

虚拟机不能孤立地存在，而且仍然服务于流量，因此给定可用性集中的虚拟机依赖于负载均衡器进行网络控制。Microsoft的Azure负载均衡确保流量路由到可用的服务器——而不是故障服务器或升级中的服务器。

使高可用性成为现实

坏消息是，在初始云应用程序部署之后，您不能将虚拟机添加到可用性区域。现有虚拟机必须被销毁并重新创建。

云服务涉及全部层级——网络层，应用层，数据库层——每层都应该具有自己的可用性集。在设计云应用部署时不要混搭；集合中的所有机器都应具有相同的目的。

要创建可用性集，请在Azure资源管理控制台中创建新机器。使用托管磁盘为Azure VM提供持久性，安全磁盘存储复制到三个位置。选择创建可用性集的选项，如果这是一个新的可用性集，请给它一个有用的名称。根据需要重复构建云应用程序部署。

一旦服务器在可用性集中创建，就会连接负载均衡器。没有负载均衡器，前端IP将无法提供服务。有几种方法可以提供负载均衡，包括PowerShell。这是云操作的世界，代码是一等公民。

云计算的高可用性与您本地的数据中心一样可以实现，但它不会自行发生。使用云部署选项确保服务的可用性。迁移到云上的管理员们需要明白的一点是，一切不再是关于服务器的，而是关于服务的。