# Microsoft Azure - 云中的容错问题和解决方法 通过 [Mario Szpuszta](https://msdn.microsoft.com/zh-cn/magazine/mt149362?author=Mario+Szpuszta) | 2015 年 9 月 有几种内置到 Microsoft Azure 以确保服务和应用程序保持在发生故障时可用的机制。此类故障可包括硬件故障，如硬盘故障或依赖的服务，如存储或网络服务的临时的可用性问题。Azure 和其软件控制的基础结构是以预测和管理此类故障的方式编写的。 出现故障时，Azure 基础结构 (Fabric Controller) 所作出的反应立即还原服务和基础结构。例如，如果虚拟机 (VM) 由于在物理主机上的硬件故障而失败，结构控制器移动到另一个物理节点的虚拟机基于同一个 Azure 存储中的硬盘上。Azure 是同样能够协调升级和更新的方式避免服务中断。 对于计算资源 （如云服务，传统的 IaaS Vm VM 扩展集），用于启用高可用性的最重要且基本概念是容错域和升级域。这些是 Azure 的一部分从诞生之初。本文将提供围绕这些概念不那么的已知澄清。 ## Azure 数据中心体系结构 若要完全了解故障域和升级域，它有助于直观显示的高级视图的方式 Azure 数据中心内的结构。Azure 数据中心内使用 Microsoft 担任量程 10 中引用的体系结构。它支持更高的吞吐量相比以前的数据中心体系结构。其拓扑实现为每个 Azure 数据中心，提供高带宽聚合底板的完整的、 非阻塞、 网状网络中所示 图 1。   图 1 高级 Azure 数据中心体系结构 节点排列到机架。机架的一组然后形成群集。每个数据中心都有大量的不同类型的群集。某些群集负责存储而有些则负责计算、 SQL 等。顶部的架 (TOR) 交换机是故障的单一有关整个机架点。 群集的结构控制器管理的计算机或节点。结构控制器协调跨群集内的节点的部署。每个群集上有多个结构控制器以实现容错功能。结构控制器必须注意的群集中的每个节点的运行状况。这有助于确定节点是否可以运行部署它。它还有助于检测故障以便它可以自动修复通过重新配置受影响的虚拟机位于不同物理节点上的部署结构控制器。 为了更好地帮助确定节点的运行状况的 Fabric Controller，运行在群集内的每台计算机具有不同的代理连续监视节点运行状况和通信结构控制器到相同的背面。若要了解不同组件如何协同工作来做到这一点至关重要。一些重要组件，如中所示 图 2, ，是： * 主机操作系统: 在物理计算机上运行的操作系统。 * 主机代理： 正在运行的进程在各个节点上提供从该计算机到结构控制器的通信点。 * 来宾操作系统： 在该 VM 中运行的操作系统。 * 来宾代理： 驻留在 VM 中，并且与主机代理以监视和维护虚拟机的运行状况进行通信。   图 2 的 Microsoft Azure 群集物理机内部 ## 容错域和升级域 对于维护任何平台作为-服务 (PaaS) 应用程序的高可用性，每个 PaaS 应用程序结构控制器主机将是分散在不同的容错域和更新域。 容错域是失败的物理单元。它与在数据中心中的物理基础结构密切相关。对于 Azure 中，每个服务器机架上的对应到某个故障域。Azure 可保证任何 PaaS 应用程序 （具有多个实例) 平台托管可跨多个故障域，而是由基于的数据中心内的计算机的可用性的结构控制器确定对其的应用程序实例分布在容错域的总数。 升级域是一个逻辑单元，可帮助您将更新推送到系统时保持应用程序可用性。对于 PaaS 应用程序，这是用户可配置的设置。在 Azure 上的应用程序可以有其分布在最多为五个升级域的实例 （请参阅 图 3)。   图 3 容错域和升级域配置 ## 故障域、 升级域和 IaaS 虚拟机 若要升级域分布在容错域的基础结构作为-服务 (IaaS) 虚拟机，Azure，引入了的可用性集的概念。在可用性集中的所有实例都分布在两个或多个故障域和分配单独的升级域值。 如果不将虚拟机分配到一个可用性集中，您不适合用于这些虚拟机的服务级别协议 (Sla)。请务必理解这一点因为它定义如何实现您的服务和应用程序的高可用性即使可能发生失败或升级到 Azure 数据中心推出。仅通过将您的虚拟机分配给可用性集，您可以避免会受到此类故障。 为了演示这的重要性，考虑以下方案： Azure 产品团队将在所有数据中心之间的操作系统更新推送定期进行。若要将更新推送到整个数据中心，主机操作系统 （物理机） 和来宾操作系统 (承载 PaaS 应用程序或您自己的 IaaS Vm 的 Vm) 必须更新为最新操作系统。若要前滚更新而不会影响应用程序的可用性： 1. 主机操作系统更新一次，所有可用的容错域执行跨数据中心的一个故障域。 2. 来宾操作系统更新在每个用户应用程序的一个升级域上执行一次，所有可用的升级域。 使用这些方法又称为 Azure 可以推送升级到其自己的基础结构同时保持服务可用性 — 只要您运行每个服务或在至少两台虚拟机的至少两个实例的可用性集 （例如负载平衡 Web 服务、 SQL Server AlwaysOn 可用性组节点等) 的一部分。 ## 多少容错域？ 容错域和升级域帮助 PaaS 式工作负荷，很大程度上无状态时保持可用性。无状态的 Web 应用程序可以与这些方法兼容。即使在节点的子集在升级周期或临时的停机时间的过程变得不可用，则整个 Web 应用程序或服务仍然可用。 这种情况获取相对要复杂就更有状态的性质，例如数据库服务器的基础结构 (是 RDBMS 或 NoSQL）。在这些情况下，了解您的服务器将分布在多个容错域可能不是足够。数据库群集可能需要大量的节点会在所有时间的群集运行状况的最小。请考虑基于仲裁的用来选择新的主节点在发生故障的方法。 有关 IaaS Vm Azure 可保证同一可用性组中的 Vm 将部署在至少两个故障域 （因此两个机架)。虽然某些在可用性集中的虚拟机部署在两个以上的容错域的概率，就不能保证。在实际测试中在过去几年，该项目时始终使用正好两个故障域将部署到北美或欧洲西部，以及几个美国区域 (如中所示 图 4)。   图 4 为示例 SQL AlwaysOn 可用性组群集的的故障域 图 4 显示通过 Azure PowerShell，然后在其 GridView 控件中显示结果发出的 Get AzureVM 命令的结果。它显示在群集中的虚拟机 — 这都是相同的可用性集 (不显示在网格中) 的一部分 — 跨两个故障域和三个升级域部署。 该示例部署的 sql1 和 sqlwitness 节点驻留在同一物理机架上。同一 TOR 连接到数据中心的其余部分的机架。Sql2 节点位于不同机架。 ## 只有两个故障域？ 对于无状态应用程序 （如 Web Api 或 Web 应用程序，在只有两个故障域部署不应是一个问题，至少从一致性角度来看。对于有状态的工作负荷如数据库服务器，它是另外一回事，至少从可用性角度来看。 具体取决于群集的工作原理，这可能是需要记住多少个节点向下发生故障时可以转以免影响群集的运行状况。如果群集取决于仲裁投票或基于大多数投票对于某些操作 （如选择新的主控形状或确认读取请求的一致性在最糟糕的情形中的节点数会下降的问题是更重要的。 即使的容错域自动恢复您的虚拟机，也是如此的多少个节点可能在同一时间失败的问题是相关的。恢复操作可能需要具体取决于它所花费的时间结构控制器来恢复虚拟机本身及其在 VM 上运行的数据库系统时间。 如果您了解升级 Azure automatism 的内部行为，整个主题变得更重要。在 IaaS Vm 的情况下为主机上运行每个物理节点上的虚拟机监控程序承载您的虚拟机的操作系统的所有升级都发生基于在容错域上 — — 因为假定广泛的开发人员社区中不升级域。升级域仅用于在 PaaS Vm 内部运行的应用程序更新。这意味着您将会受主机操作系统升级每个季度，这是典型的间隔。如果您的群集部署在两个故障域，但取决于大多数投票并类似，则可能有间歇性的停机时间。 常见的例子将部署在 Azure 中设置 MongoDB 副本。每个 MongoDB 副本集要求恰好一个母版。如果该主节点出现故障，新的主密钥者选择通过剩余的节点。这些选择需要的大部分投票要求选择母版。如果没有足够的节点是最新的主节点投票，整个副本集中声明的不正常状态并可被视为"已关闭。" MongoDB 文档 ([bit.ly/1SxKrYI](http://bit.ly/1SxKrYI)) 能够清楚地表明每个副本集大小容错。三个节点的副本集中的情况下只有一个节点可能会失败。在一组五个节点，两个是最大可能会失败而不向下，整个群集的节点数中所示 图 5。 图 5 MongoDB 副本设置容错功能 | 成员数 | 选择新的主副本所需的大多数 | 容错 | |---|---|---| | 3 | 2 | 1 | | 4 | 3 | 1 | | 5 | 3 | 2 | | 6 | 4 | 2 | 如果您需要运行在副本集中的数据库节点数甚至 （例如，为副本集的两个数据库节点），MongoDB 引入了仲裁器的概念。仲裁器充当投票的选举、 为服务器但不运行的整个数据库堆栈 （节省成本和资源）。如果您最终创建与 MongoDB 副本集其中两个数据库节点已经足够，因此您需要第三个节点 — 仲裁服务器 — — 这只是提供对大多数基于在发生故障的主选举其他投票。 它是 SQL Server AlwaysOn 可用性组，其中大多数节点需选择一个新的主节点与类似的情况。仅投票成员的原则是类似的。它只是在 SQL Server 的世界中称为见证服务器 （而不是仲裁器，即所谓 MongoDB 中)。 SQL Server 和返回中所示的部署考虑 图 4, 、 它清楚地状态 sql1 和 sqlwitness 位于一个故障域和 sql2 是在另一台。如果故障域"0"失败，母版和见证服务器均向下 — 保留仅 sql2。但是，单独的 sql2 是不足的大多数选择群集中新的主密钥。这意味着如果容错域"0"失败，您的整个群集都不正常。 这种情况将 sql1 和 sql2 得到在同一容错域上的情况下更糟。则这两个数据库节点就是向下直到结构控制器从潜在的故障中恢复节点或完成主机操作系统升级过程。 这种情况是使用 MongoDB 副本集类似。表中所示 图 5 从官方 MongoDB 文档能够清楚地表明在副本集中的三个节点时，失败的只有一个节点可以为整个群集保持活动状态并且可用。因此，它是关键如何将您的节点分布在给定数量的容错域。它可能会影响在 Azure 主机操作系统升级和潜在的故障。 ## 有状态的服务中的高可用性 一个有效的问题，然后，是如何实现高可用性时 Azure 主要将 Vm 部署在两个故障域。有中间的术语和短期的解答这个问题。 中期 Azure 产品组工作来显著改善这种情况。在部署时 （基于新的 Azure 资源管理器 API） 的版本 2 IaaS Vm，Azure 可以通过最少三个故障域部署您的工作负荷。这就是合理的理由使用第 2 版虚拟机和 Azure 资源管理器。 短期或只要您很快就会仍然依赖于传统的 Azure 服务管理和版本 1 IaaS Vm，就不这么简单。具体取决于您 SLA 恢复时间目标 (RTO) 和恢复点目标 (RPO) 目标具有降低停机时间的风险的两个选项。这两种方法所示 图 6, ，并且基于 SQL Server AlwaysOn 可用性组。   图 6 SQL Server AlwaysOn 可用性组部署 目标是始终以减少定期发生主机操作系统升级和最终失败的影响。对于在单个数据中心内的三个节点群集，将部署在虚拟机的可用性集之外的一个节点和两个节点作为同一个虚拟机的可用性集的一部分。 使用该方法几乎完全缓解主机操作系统升级的效果。虚拟机的可用性集内的升级的计时是不同的单一 VM 主机操作系统升级。正在运行的不可用性集的情况下的单个 Vm 的主机操作系统通常将升级大约一周早于那些使用虚拟机中的可用性集中。 在故障域故障的情况下只能减少受影响的概率。始终是可用性集克提克地区对其中一个可用性集内的虚拟机的故障域之外的节点的概率。很多取决于已使用并且在 Azure 数据中心中可用的资源。 有关 Active Directory 域中作为 图 6, ，此类解决方案无需。存在无论如何都是仅对高可用性、 主要和备份域控制器。这就是完全分布在两个故障域，这是 Azure 可保证有关版本 1 IaaS Vm 的两个节点。 这样仍然不会提供更好地正准备基础的 SQL 节点这一难题 图 6。可以通过不部署同一数据中心内的 sqlwitness 来降低该风险。这并不只是减少概率;它实质上是消除了风险。以解决方案还为单位表示 图 6: 将您的部署分布到两个区域。 ## 两个选项 具体取决于您 SLA RPO 和 RTO 需要和你愿意为之付款的高可用性，再次您有两个主要选项： 中的第二个区域或辅助区域中具有只需仲裁器/见证服务器的完全正常运行的备份部署。 完全正常运行的辅助部署是指将复制整个部署辅助区域中。也还可包括前端和中间层应用程序和服务。出现重大故障时的主要区域中，然后可以将客户转到辅助区域。 这种部署通常会为强 RPO/RTO 目标生成。对于如 MongoDB 或短 Rpo 和 rto 要求使用 SQL AlwaysOn 数据库系统，这种需求通常会导致跨两个区域跨越的副本集或 SQL 可用性组群集，与启用跨这些区域的正在进行复制。尽管可能会因延迟和性能问题而异步跨区域复制，复制将发生这种情况中任意位置毫秒为单位为分钟，而不是两位数分钟或几小时。 另一方面，虚拟机在作为单个辅助区域中运行仅见证服务器或仲裁器是一个更廉价的替代品。它是很好足够时您只需在故障域出现故障时保持您的主群集。它不会为您提供立即向整个辅助区域而无需一些严重的其他步骤，如启动新的节点和辅助区域中的虚拟机故障转移的选项。 在示例中所示 图 6, ，您还可以运行完整的 SQL 节点作为唯一的节点的次要区域中。由于它作为一个单独的 VM 中运行，它将具有不同的升级周期。此外，因为它运行在不同数据中心中，那么它正在升级的概率或在同一时间作为主可用性组中的节点的故障很小。 ## 总结 实现高可用性和容错功能的应用程序和服务并不是一个简单的过程。它要求您理解并对基本概念的调整。您需要了解的容错域、 升级域和可用性集。尤其被需要了解在您的基础结构中使用的迁移到 Azure 时的状态系统的容错功能要求。将这些容错功能要求映射到行为的容错域和升级在 Azure 中的域。 全新的 IaaS 部署来说，务必利用 IaaS Vm v2 作为 Azure 资源管理器和资源组工作的一部分。这样一来，您将受益于在至少三个容错域上所部署的容错能力。对于使用传统的服务管理的部署，请确保您了解并接受在本文中概述的现实。这些建议可以帮助减少故障域停机时间和维护事件如主机操作系统升级的影响。通过接受并调整到此处所述的概念，您将能够实现高可用性而不需要的意外事件。 * * * Mario Szpuszta *是 DX corp.的首席项目经理全局 ISV 团队。他是在世界各地若要启用其解决方案和 Microsoft Azure 上的服务与独立软件供应商。您可以通过他的博客与他联系 ([blog.mszcool.com](http://blog.mszcool.com/))，在 Twitter 上 ([twitter.com/mszcool](http://twitter.com/mszcool)) 或通过 [marioszp@microsoft.com](mailto:marioszp@microsoft.com)。* Srikumar Vaitinadin *是 DX corp.的软件开发工程师全局 ISV 团队。在此之前，他曾参与迁移到 Azure 的 Microsoft 属性。您可以获得与通过 Srikumar 联系 [srivaiti@microsoft.com](mailto:srivaiti@microsoft.com)。*