云服务故障的基本对策

其实，云服务也会出现中断故障。云服务中断故障意味着一个云数据中心或整个地区的基本服务（如存储、计算能力或中间件）中断。随着后端和业务应用程序在云中应用的普及，如今这种故障影响的不仅仅是面向客户的网页和在线商店，所有应用程序都会受到影响，整个企业将陷入停顿，所有员工，无论是财务、人力资源、销售、生产、客户服务还是物流的员工都无法工作。

此外，中断可能不仅仅是暂时的。如果一个数据中心烧坏了，服务器和里面的所有数据也就永远消失了。因此，首席信息官（CIO）、首席信息安全官（CISO）和董事会必须决定在灾难恢复和业务连续性规划中接受哪些风险以及需要解决哪些风险。

传统的业务连续性管理（BCM）涵盖了物理领域的挑战：大量员工的缺席（例如，由于大流行病）或洪水和火灾摧毁了办公大楼和数据中心。云服务中断则是一种新的情况——解决这些问题需要深入理解各种技术和设计模式并将其纳入组织的企业架构。

公共云服务故障

故障发生时，云中断BCM设计必须确保以下资源的可用性。

· 存储和计算等资源

· 数据和应用。

· 云服务应用（除了SaaS应用）的一个特别之处在于，这些应用是以下列业务逻辑和数据的形式组成：

· 基础设施即服务（IaaS）工作负载与虚拟机

· 平台即服务（Platform-as-a-Service）工作负载，包括（不仅仅包括）对象存储或数据库即服务

公共云提供了在更广泛故障出现时的生存功能。尽管如此，IT部门和风险管理人员仍然必须了解这些机制，并为潜在的公共云中断做好准备。我们在下文里就来看看所选定的微软Azure概念，尽管其他云（如GCP或AWS）都非常相似。

Azure划分了分区服务、区域服务和全球永久在线服务（下图）。分区服务在一个数据中心运行——最具代表性的分区服务是Azure虚拟机。如果你订购了这样的虚拟机，Azure就会启动一个虚拟机分配给你。因此，如果这个数据中心发生故障，你的虚拟机就会挂掉。没有任何冗余。

区域服务是第一类有一定冗余的服务。许多Azure中用于存储数据或数据库即服务产品的Azure服务属于这一类。这些区域服务在一个区域内的多个分区运行（因此提供了冗余）。例如，Azure苏黎世区域由苏黎世市附近的三个分区组成。某个本地事件（例如飞机坠毁在一个数据中心）不会导致区域服务的瘫痪。所以，区域服务可以提供有限的韧性。然而，区域服务并不能提供对大规模事件的保护，例如瑞士各地都停电几天。

全球永久在线服务（如DNS或Azure活动目录）则属于另一个档次。Azure保证全球永久在线服务的可用性，无论世界上发生什么事情。客户不需要在全球云中断的情况下计划和准备灾难恢复。不过问题是属于这一类的服务非常少。大多数服务都只是区域性的，甚至只是分区性的，特别是与运行应用程序代码和处理数据有关的服务。

为云中断做准备意味着要在提高韧性的成本与中断的概率和影响之间取得平衡。你是否真的需要区域性或全球性服务？或是分区性服务（加上其他地方的一些备份）就足够了（下图）？所有需要的和使用的服务都能满足这些需求吗？如果一个应用在发生区域性灾难时也必须继续运行，那么很容易知道单个虚拟机显然不可行。在这样的场景里服务SLA和服务描述都不符合业务需求。

增强韧性

在面临云中断的情况下，韧性是至关重要的。当一项服务不能满足韧性需求时，韧性模式其实很简单：就是在不同的分区或区域复制服务。如果一个虚拟机上的应用程序在数据中心挂掉仍然必须继续运行，那么你就需要在一个隔得稍远的第二个数据中心运行另一个虚拟机。如果你要求苏黎世周围的区域停电不影响你的应用程序，那么就必须在日内瓦、芬兰或澳大利亚增加一个虚拟机。只需考虑两个细节：成本和改路由。

在苏黎世数据中心以外的地方运行额外的虚拟机只是为了应付紧急情况，但如果不能针对发来的请求改路由就帮不上忙。解决方案：负载平衡器。负载平衡器是一种区域性服务，即便苏黎世周围的一个数据中心完全崩溃，负载平衡器还是可以继续运行。负载平衡服务在运行初始虚拟机的数据中心崩溃时将流量重新分配到仍在运行的数据中心的虚拟机上。如果你必须在整个区域发生故障时重定向流量，那么诸如DNS或Azure前门（Azure Front Door）等始终在线的服务就是正确的选择。

有些选定的区域服务具有地理冗余功能，可以缓解问题或令问题复杂化。例如，Azure Cosmos数据库服务可以备份到不同区域并从这些备份恢复（下图A），甚至允许工程师将该服务配置为地理冗余（下图B）。

我们看看从两个维度（数据和资源容量）的角度设计故障转移系统（下图）会有所受益的。最昂贵的设计是在两个数据中心建立起运行日常操作的全部容量。一半的虚拟机（和其他容量）运行日常操作，另一半则是闲置的，希望不出故障永远不用这一半闲置的服务和容量。闲置的容量只是为了在故障转移的情况下存在。由于成本问题，一众公司只会对最关键的任务系统实施这种架构。

另一个极端是完全没有留出故障转移的能力。换句话说，IT部门是赌一赌，想靠云供应商有足够的容量来应对灾难情况，从而接受供应商可能并没有应对灾难情况容量的风险，或者只在遥远的数据中心有高延时的容量。当采用这种方法时，你永远不应该忘记一个事实：典型的云中断会影响成千上万的客户。云供应商不可能在同一区域的其他数据中心有这么多没人日常使用（和支付）的闲置虚拟机或服务能力。而且，在这两个极端（所有的东西都有重复的资源或对任何东西都没有容量保留）之间有很多选择。

设计故障转移系统时的第二个维度是数据备份和复制的可用性和及时性。两个主要的复制模式是 “异步复制”和“同步复制”。后一种模式是在确认写操作成功之前更新各个数据中心的所有数据副本。同步复制的好处是，所有的数据副本总是最新的，应用程序可以在第二个数据中心待命并处于活动状态（活动/活动）。

数据中心崩溃不会造成任何数据损失或服务中断。缺点是：由于延迟，可能造成吞吐量损失。最慢的数据中心决定了吞吐量。因此，典型的同步复制是一个区域内的复制，例如，苏黎世周围的各个数据中心，但不是从苏黎世到弗吉尼亚的美东1区域。对于区域之间的复制，异步复制是一个典型的选择。

异步复制意味着云服务（或你的应用程序）在本地区域提交更新；当异步复制服务将更新推送到同一个或另一个大陆的不同区域时，应用程序继续运行。更新传播时的延迟不会损害你的应用程序的性能。然而，发生故障时尚未转发的变化会丢失。第三种，最传统和最便宜的选择是配置定期备份而不是设置复制。在这最后一种情况下，云服务执行备份，例如，每4小时或每天一次。

所以，复制和冗余的选择会影响到一个公司在云计算数据中心中断甚至是区域性云计算中断时的生存能力。事实上，业界公司必须明确他们能接受哪些风险以及要为哪些风险做准备。这里的挑战在于，在后一种情况下如何设计一个一致的灾难恢复架构。云服务有不同的冗余选项。云架构师必须为建立在五个或十个云服务上的应用挖掘各种细节，即使所有的云服务都来自同一个云供应商，也要为云中断做好准备。董事会最终是希望IT部门能够交付云计算的主要营销承诺之一：在云中无服务中断，由于云计算可以提供冗余、复制和备份等神话般的功能。