Date: 12月 18, 2020
计算云中的应用程序可用性
在云中部署关键业务应用程序时，您要确保它们具有高可用性。 好消息是，如果您进行适当的计划，则可以实现99.99％（4-nines）的可用性或更高。 但是，计算您的真实可用性可能并不像看起来那样简单。
在考虑可用性时，您必须考虑使访问应用程序成为可能的关键组件，我将其称为可用性链。 可用性链的组成部分是：
- 计算
- 网络
- 存储
- 应用
- 依赖服务
您的应用程序只有最弱的链接才可用，并且您向链中添加的每个其他链接的停机时间都会成倍增加。让我们检查每个链接。
计算可用性
三个主要的云服务提供商中的每一个都有一些相似之处。 这三个平台的共同点是它们将致力于计算的服务级别协议（SLA）。
当您在不同可用性区域中配置了两个或多个VM时，所有三个VM的公共云提供商的SLA为99.99％。请记住，此SLA仅保证在任何给定时间对其中一个VM的远程访问，它不保证VM内运行的服务或应用程序的可用性。如果在单个数据中心内部署单个VM，则此SLA的范围从“每小时90％”（AWS）到99.5％（Azure和GCP）或99.9％（使用Premium SSD时，Azure单个VM）。
真正的高可用性从99.99％开始，因此第一步是确保您的应用程序可用，是确保该应用程序分布在两个或多个跨越可用区的VM中。 通过将两个VM分布在两个可用区中，可以为您提供至少其中一个VM的99.99％的可用性，您可以得出以下理论：如果三个VM分布在三个可用区中，则您的可用性将甚至超过99.99％。 尽管云提供商的SLA永远不会保证可用性超过99.99％（无论正在使用的可用性区域有多少），但是如果您使用纯统计信息，您可能会得出结论，您的可用性可能会高达99.999999％或8倍可用性，每月停机时间为26.30毫秒。
1-（。0001 * .0001）= .99999999
具有三个可用区的99.999999％可用性？
不要四处引用那个数字。 但是请记住，如果两个可用性区域可以为您提供99.99％的可用性，这是有道理的。 可以肯定地说，三个可用区将为您提供超过99.99％的可用性。
计算只是可用性链中的一个环节。 我们仍然必须解决网络，存储和其他相关服务，这些都代表了可能的故障点。
网络可用性
为了使您的应用程序可用，客户端与应用程序之间的每个网络跃点以及应用程序依赖的所有资源都必须可用，并且必须在可容忍的延迟范围内工作。 您需要了解数据库服务器，应用程序服务器，Web服务器和客户端之间的网络链接，以准确了解网络可能在哪里发生故障。 请记住，可用性链中的链接越多，总体可用性就越低。
尽管标准计算SLA涵盖了同一vNet中虚拟机之间的网络可用性，但是您可能仍在使用其他网络服务。 这只是您可能会使用的网络服务的一些示例，这些示例会影响整体应用程序的可用性。
快速路线– 99.95％
VPN网关– 99.9％至99.95％
负载均衡器– 99.99％
流量管理器– 99.99％
弹性负载平衡器– 99.99％
直接连接– 99.9％– 99.99％
基于到目前为止所学的知识，让我们看一下跨两个可用区部署的应用程序的可用性。
99.99％的计算可用性
99.99％负载均衡器可用性
.9999 * .9999 = .9998
99.98％的可用性=每月约9分钟的停机时间
既然我们已经解决了计算和网络可用性问题，那么让我们继续进行存储。
存储空间
现在这里是故事多毛的地方。 看一下以下存储SLA
https://azure.microsoft.com/zh-CN/support/legal/sla/storage/v1_5/
https://cloud.google.com/storage/sla
https://aws.amazon.com/compute/sla/
显然，Azure和Google在块存储解决方案上提供了99.9％的SLA。 AWS在这里没有特别提及EBS。 他们只谈论虚拟机，并按小时而不是其他云提供商那样按月衡量其单实例虚拟机的可用性。 为了便于讨论，让我们使用Azure和GCP均已发布的99.9％可用性保证。
在前面的示例的基础上，让我们为方程式添加一些存储空间。
99.99％的计算可用性
99.99％负载均衡器可用性
99.9％托管磁盘
.9999 * .9999 * .999 = .9988
99.88％的可用性=每月约53分钟的停机时间。
53分钟的停机时间比我们在先前示例中计算的9分钟的停机时间要长得多。 我们如何才能最大程度地降低99.9％的存储可用性的影响？ 我们必须在存储中建立更多的冗余！
幸运的是，在计划应用程序可用性时，我们通常会包括存储冗余。 例如，当我们站起Web服务器时，每个Web服务器通常会将数据存储在本地连接的磁盘上。 部署域控制器时，Microsoft Active Directory负责在所有域控制器之间复制AD信息。 对于类似SQL Server的情况，我们利用AlwaysOn可用性组或SIOS DataKeeper来保持数据在本地连接的磁盘之间的同步。
我们跨不同可用性区域分布的数据副本越多，我们越有可能幸免于难。
例如，将数据存储在不同可用性区域中的两个不同磁盘上的应用程序将受益于冗余，而不是99.9％的可用性，它更有可能实现99.9999％的存储可用性。
1 –（.001 * .001）= .999999
如果将其放到先前的方程式中，图片将开始看起来更亮一些。
.9999 * .9999 * .999999 = .9998
99.98％的可用性=约9分钟的停机时间
通过跨多个可用区（因此跨多个磁盘）复制数据，我们有效地减轻了与云存储相关的停机时间。
应用程序和相关服务的可用性
您已尽力确保计算，网络和存储的可用性。 但是应用程序本身呢？ 某些应用程序可以通过在同一应用程序的多个实例之间进行负载平衡来横向扩展并提供冗余。 想想典型的Web服务器场，您通常可以在其中平衡五台服务器之间的Web请求。 如果您丢失一台服务器，则负载平衡器仅将其从旋转中删除，直到再次响应为止。
其他应用程序则需要更多的维护和监视。 以SQL Server为例。 通常，“始终在线可用性组”或“故障转移群集实例”用于监视数据库可用性，并在数据库由于应用程序或系统级故障而变得无响应时使用恢复操作。 尽管没有针对SQL Server可用性解决方案的已发布SLA，但通常公认的是，如果为高可用性进行了正确配置，则SQL Server可以提供99.99％的可用性。
您可能依赖于其他基于云的服务，例如托管的Active Directory，托管的DNS，微服务，甚至云门户本身的可用性都应纳入整体可用性方程中。
概要
应用程序可用性是所有活动部分的总和。 仅在一个区域中跳过会成倍地影响应用程序的整体可用性。 花点时间研究可用性链中的所有链接是否存在漏洞，包括计算，网络，存储，应用程序和相关服务。
总的来说，这里列出的数字是最坏的情况，希望您的实际可用性超过已发布的SLA。 做好家庭作业，并提防任何不能保证99.99％可用性的服务，这是被认为具有高可用性的典型阈值。
本文未解决人为错误和安全问题。 您可以使您的应用程序尽可能地高可用性。 但是，如果您尚未采取措施保护应用程序免受外部威胁和愚蠢的人为错误，那么在可用性方面，所有赌注都没有了。