Microsoft Azure作为大型公有云计算平台，企业将业务部署或迁移到该平台目的是为了更好的扩大业务规模，提升公司经济效益与形象，因此作为管理员的您有必要了解Azure中的虚拟机可用性管理，以确保您的业务实时可用。

本文将从以下几个方面说明Azure中的虚拟机可用性管理

    了解 VM 重启 – 维护和停机

Microsoft Azure中，主要有以下几个情况可能会导致Azure中的虚拟机受影响：计划外硬件维护、意外停机、计划内维护。

• 当Azure平台预测硬件或者与物理计算机关联的任何平台组件即将发生故障时，就会发生计划外硬件维护事件。当预测到故障时，平台会发出计划外硬件维护事件，以便减少对托管在该硬件上的虚拟机的影响。Azure 使用实时迁移技术将虚拟机从故障硬件迁移到正常的物理计算机。实时迁移是一项 VM 保留操作，只能短时间暂停虚拟机。将会保留内存、打开的文件以及网络连接，但事件前后的性能可能会降低。在无法使用实时迁移的情况下，VM 会出现意外停机。
  
• 意外停机指虚拟机的硬件或物理基础设施意外出现故障。此类故障可能包括：本地网络故障、本地磁盘故障，或者其他机架级别的故障。检测到此类故障时，Azure平台会自动将虚拟机迁移到同一数据中心内的正常物理机（进行修复）。在修复过程中，虚拟机会经历停机（重启），在某些情况下会丢失临时驱动器。但是始终会保留附加的 OS 和数据磁盘。
  
• 在发生会影响整个数据中心甚至整个区域的服务中断或灾难时（这种情况很少见），虚拟机也可能会停机。 针对这种情况，Azure 提供了保护选项，包括可用性区域和配对区域。
  
• 计划内维护事件是指由Microsoft对底层Azur平台进行定期更新，以改进虚拟机运行时所在的平台基础结构的总体可靠性、性能和安全性。大多数此类更新在执行时不会影响虚拟机或云服务。虽然Azure平台会尝试在所有可能的情况下都使用VM保留维护，但在罕见情况下，这些更新需要重启虚拟机，否则无法将所需更新应用到底层基础结构。在这种情况下，可以在合适的时间窗口为 VM 启动维护，通过”维护-重新部署″操作来执行 Azure 计划内维护。
  

因此作为企业管理员您，要减轻一个或多个此类事件引发的停机所造成的影响，Microsoft建议您遵循以下最佳做法以提高虚拟机的可用性：

• 在可用性集中配置多个虚拟机以确保冗余
  
• 在可用性集中对VM使用托管磁盘
  
• 使用计划事件主动响应影响事件的 VM
  
• 将每个应用程序层配置到不同的可用性集中
  
• 将负载均衡器与可用性集组合在一起
  
• 使用可用性区域防范数据中心级故障
  

使用可用性区域防范数据中心级故障

可用性区域是Azure区域中的物理上独立的数据中心。这些数据中心配置了独立电源、冷却和网络。为了确保复原能力，所有启用的区域中都至少有三个单独的区域。区域中可用性区域的物理隔离可以在发生数据中心故障的情况下保护应用程序和数据。区域冗余服务可跨可用性区域复制应用程序和数据，以防范单点故障。

每个可用性区域都由一个或多个数据中心组成，这些数据中心都配置了独立的电源、冷却和网络设备。可用性区域被设置为_隔离边界。如果一个区域出现故障，其他区域会继续正常工作。可用性区域通过高速专用光纤网络相连。

Azure凭借可用性区域提供一流的 99.99% VM 运行时间 SLA。通过构建解决方案以在区域中使用复制的 VM，你可以保护应用程序和数据免受数据中心的损失。如果一个区域发生故障，另一个区域会立即提供复制的应用和数据。

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

可用性集是另一种数据中心配置，用于提供 VM 冗余和可用性。数据中心内的这种配置可以确保在发生计划内或计划外维护事件时，至少有一个虚拟机可用，并满足99.95%的Azure SLA要求。

Azure平台为可用性集中的每个虚拟机分配一个更新域和一个容错域。 对于给定的可用性集，默认情况下会分配五个非用户可配置的更新域（可以增加 Resource Manager部署以最多提供20个更新域），以指示可同时重新启动的虚拟机和底层物理硬件组。在单个可用性集中配置了5个以上的虚拟机时，第 6 个虚拟机将放置在第1个虚拟机所在的更新域中，第7个虚拟机将放置在第 2 个虚拟机所在的更新域中，依此类推。在计划内维护期间，更新域的重启顺序可能不会按序进行，但一次只重启一个更新域。重启的更新域有30分钟的时间进行恢复，此时间过后，就会在另一更新域上启动维护操作。

容错域定义一组共用一个通用电源和网络交换机的虚拟机。 默认情况下，在可用性集中配置的虚拟机隔离在 Resource Manager 部署的最多三个容错域（经典部署的两个容错域）中。虽然将虚拟机置于可用性集中并不能让应用程序免受特定于操作系统或应用程序的故障的影响，但可以限制潜在物理硬件故障、网络中断或电源中断的影响。

为可用性集中的 VM 使用托管磁盘

Azure 托管磁盘是虚拟硬盘 (VHD)。 可以将其视为本地服务器中的物理磁盘，但它是虚拟化的。Azure 托管磁盘作为页blob 存储，后者是 Azure 中的随机IO 存储对象。我们之所以将托管磁盘称为”托管”是因为，它是对页 blob、blob 容器和Azure 存储帐户的抽象。对于托管磁盘，你所要做的就是预配磁盘，而Azure 负责其余的工作。

如果当前VM没有使用托管磁盘，则强烈建议在可用性集中转换VM，以便使用托管磁盘。

通过确保可用性集中的 VM 的磁盘彼此之间完全隔离以避免单点故障，托管磁盘为可用性集提供了更佳的可靠性。为此，会自动将磁盘放置在不同的存储容错域（存储群集）中，并使它们与VM容错域一致。如果某个存储容错域因硬件或软件故障而失败，则只有其磁盘在该存储容错域上的VM实例会失败。

如果您的业务因为一些特殊原因，无法使用托管磁盘，那么微软建议：

• 将与同一VM关联的所有磁盘（OS 和数据）放置在同一存储帐户中
  
• 在向存储帐户添加更多 VHD 之前，查看存储帐户中非托管磁盘的数量限制
  
• 为可用性集中的VM使用单独的存储帐户。同一可用性集中的多个VM 不能共享存储帐户。不同可用性集中 VM共享存储帐户是可以接受的，只要遵循上述最佳做法即可。
  

使用计划事件主动响应影响事件的 VM

如果订阅计划事件，则将通知VM即将发生会对VM造成影响的维护事件。 启用计划事件后，可在执行维护活动之前为虚拟机提供最少的时间。例如，可能会影响VM的主机OS更新将作为事件排队等候，通知中将详述其影响，以及在未采取任何操作的情况下执行维护的时间。当Azure检测到即将发生可能影响VM的硬件失败时，计划事件也会排队等候，以便决定执行修复的时间。客户可以使用事件在维护前执行任务，例如，保存状态、故障转移到辅助VM等。完成用于妥善处理维护事件的逻辑后，可批准未完成的计划事件，以允许平台继续进行维护。

将每个应用层配置为单独的可用性区域或可用性集

如果虚拟机几乎完全相同，并且业务系统提供相同的目的，微软建议为每个应用程序层配置可用性区域或可用性集。如果将两个不同的层置于同一可用性区域或集中，则同一应用程序层中的所有虚拟机都可以同时重启。通过在可用性区域中配置至少两个虚拟机或为每个层设置，可确保每个层中至少有一个虚拟机可用。

例如，可以将运行IIS、Apache和Nginx的应用程序前端的所有虚拟机放入单个可用性区域或集。请确保仅将前端虚拟机放置在同一可用性区域中。同样，请确保仅将数据层虚拟机置于其自身的可用性区域中或设置，如复制的 SQL Server 虚拟机或 MySQL 虚拟机。

结合使用负载均衡器和可用性区域

将Azure 负载均衡器与可用性区域相结合，或将其设置为最大程度地提高应用程序复原能力。Azure 负载均衡器将流量分布到多个虚拟机中。对于标准层虚拟机来说，Azure 负载均衡器已包括在内。并非所有虚拟机层都包括 Azure 负载均衡器。有关对虚拟机进行负载均衡的更多信息，请阅读对虚拟机进行负载均衡。

如果没有将负载均衡器配置为对多个虚拟机上的流量进行平衡，则任何计划内维护事件都会影响唯一的那个处理流量的虚拟机，导致应用程序层中断。将同一层的多个虚拟机置于相同的负载均衡器和可用性集下可以确保至少有一个虚拟机实例能够持续处理流量。

本文固定链接: http://365vcloud.azurewebsites.net/2019/11/19/azure-vm-availability/ | 365vCloud的云计算之旅