DAG：超过“A”
原文发布于 2011 年 9 月 16 日（星期五）
定义
我们都知道在 Microsoft Exchange 领域中，DAG 代表“数据库可用性组”。
数据库 – 因为在高度可用的 Exchange 2010 邮箱服务器上，数据库而非服务器是可用性 的单位，并且它是可以在 DAG 中的多台服务器之间进行故障转移或切换的数据库。此概念称为数据库移动性。
组 – 因为可用性 的范围由组合在故障转移群集中并作为组一起工作的 DAG 中的邮箱服务器决定。
可用性 – 这个词似乎是此处最不易理解、最令人困惑的术语（并且还被其他两个术语引用）。具有讽刺意味的是，它具有简单的数学定义，并且在理解总体 Exchange 设计原理方面发挥着重要作用。
Wikipedia 将“可用性”定义为以下意思之一：
- 在未知（即 随机）时间需要执行任务时，系统、子系统或设备在任务开始时处于指定的可操作且可提交状态的程度。简单地说，可用性是系统处于运行状态的时间比例。这通常描述为任务执行率。在数学上，这表示为 1 减去不可用性（该链接可能指向英文页面）。
- (a) 功能单元（该链接可能指向英文页面）在给定的时间间隔内可以使用的总时间与 (b) 时间间隔长度的比率。
用概率论的话来说这两种定义的意思相同：给定系统或组件在任意随机时间点（我们测试它时）“可操作”或“可以使用”（即可用）的概率。
在数学上，这可以通过以下方法进行测量：计算在某个具有统计代表性的大期间（通常为一年）中系统可用（“运行”）的时间长度，然后将它除以期间的总长度。使用广泛采用的术语平均故障间隔时间 (MTBF) 和平均修复时间（该链接可能指向英文页面） (MTTR) – 前者表示故障之间的系统可用性/运行时间，而后者表示任何给定故障期间的系统停机时间 – 可用性 可表示为以下分数：
相反的数学特征将为故障概率（视为“不可用性”）：
可用性通常根据下表表示为“几个九”：
可用性级别 |
可用性值 |
故障概率 |
每年接受的停机时间 |
两个九 |
99% |
1% |
5256 分钟 = 3.65 天 |
三个九 |
99.9% |
0.1% |
525.6 分钟 = 8.76 小时 |
四个九 |
99.99% |
0.01% |
52.56 分钟 |
五个九 |
99.999% |
0.001% |
5.26 分钟 |
当然，可用性值将随我们是同时考虑计划和未计划停机还是仅考虑未计划停机而不同。表示业务可用性要求的服务级别协议必须对此非常明确。但在所有情况下，任何给定系统或组件的可用性都依赖许多因素，并且识别和理解这些依赖项及其如何影响可用性十分重要。
服务依赖项如何影响可用性
Exchange 邮箱数据库的可用性依赖许多其他服务和组件的可用性 – 例如，托管数据库的存储子系统、操作此数据库的服务器、与此服务器的网络连接等。所有这些都是关键组件，并且其中任何一个组件出现故障都将意味着丧失服务，即使数据库本身完全正常也是如此。这意味着若要使数据库可用作服务，数据库的每个依赖项也都必须可用。如果我们正确识别并隔离了依赖组件，我们可以采用数学方法计算它们如何确定 Exchange 邮箱数据库本身的最终可用性。
对于给定的 Exchange 邮箱数据库，可以将以下组件视为关键依赖项：
- 数据库磁盘/存储子系统 – 让我们假定其可用性为 A1；
- 邮箱服务器（硬件和软件组件）– 假定其可用性为 A2；
- 客户端访问服务器（硬件和软件组件）– 请记住，在 Exchange 2010 中，所有客户端仅通过客户端访问服务器连接到邮箱数据库，并在本例中让我们假定 CAS 与邮箱服务器分开安装 – 假定其可用性为 A3；
- 客户端与客户端访问服务器之间以及客户端访问服务器与邮箱服务器之间的网络连接 – 假定其可用性为 A4；
- 服务器和存储所在的数据中心的电源 – 假定其可用性为 A5；
此列表可以继续…例如，Active Directory 和 DNS 也都表示 Exchange 的关键依赖项。另外，除了纯技术依赖项，可用性还受操作成熟度等过程依赖项的影响：人为错误、操作定义不正确、缺少团队协作都可导致服务中断。我们不会在此处尝试搜集任何依赖项详细列表，而是关注它们如何影响总体服务可用性。
由于这些组件本身各自相互独立，因此其中每个组件的可用性表示一个独立事件，并且 Exchange 邮箱数据库的最终可用性表示所有这些事件的组合（换句话说，若要使邮箱数据库可供客户端使用，所有这些组件都必须可用）。根据概率论，独立事件的组合概率为每个事件的各自概率的乘积：
例如，如果您投掷三枚硬币，三枚硬件全部正面朝上的概率是 (1/2)*(1/2)*(1/2) = 1/8。
请务必认识到由于每个单独的可用性值不能大于 1（或 100%），并且最终服务可用性仅是各个组件可用性的乘积，因此最终可用性值不能大于最低的依赖组件可用性。
这可以使用下表中提供的示例进行说明（此处的数字是示例但非常切合实际）：
关键依赖组件 |
故障概率 |
可用性值 |
邮箱服务器和存储 |
5% |
95% |
客户端访问服务器 |
1% |
99% |
网络 |
0.5% |
99.5% |
电源 |
0.1% |
99.9% |
总体服务（依赖以上所有组件） |
6.51383% |
95% x 99% x 99.5% x 99.9% = 93.48617% |
从此示例中，您可以发现重要服务依赖项是多么关键。甚至对于从未失败（从未损坏、从未感染任何病毒等）的邮箱数据库，可用性仍低于 93.5%！
结论：大量服务依赖项会降低可用性。
您为减少服务依赖项的数量或影响而做的任何事情都将必然影响总体服务可用性。例如，您可以通过简化并保护服务器管理以及优化操作过程来提高操作成熟度。在技术方面，您可以尝试通过简化设计来减少服务依赖项的数量 – 例如，淘汰复杂的基于 SAN 的存储设计（其中包括 HBA 卡、光纤交换机、阵列控制器，甚至 RAID 控制器），取而代之的是具有最少移动部件的简单 DAS 设计。
仅减少服务依赖项可能不足以使可用性达到所需级别。另一种可提高最终可用性并最大程度降低关键服务依赖项的影响的非常高效的方法是利用各种冗余方法，例如使用双电源、合作的网卡、将服务器连接到多个网络交换机、对操作系统使用 RAID 保护、为客户端访问服务器部署负载平衡器以及邮箱数据库的多个副本。但冗余到底如何提高可用性？让我们更仔细地了解作为重要示例的负载平衡和多个数据库副本。
冗余如何影响可用性
从概念上说，所有冗余方法都意味着一件事情：组件有多个可用实例，并且可以与其他实例同时使用（如在负载平衡中）或用作替代品（如在多个数据库副本中）。让我们假定给定组件有 n 个实例（CAS 阵列中的 n 台服务器，或 DAG 中的 n 个数据库副本）。即使其中一个失败，其他实例仍可以使用，因而保持可用性。我们将面临实际停机的唯一情况是所有 实例都失败时。
正如前面所定义的，任何给定实例的故障概率是 P = 1 – A。所有实例在统计上相互独立，这意味着其中任一实例的可用性或故障不会影响其他实例的可用性。例如，给定数据库副本的故障不会影响该数据库的另一个副本的故障概率（此处可能存在的说明是从第一个已损坏数据库副本传播到所有其他副本的逻辑数据库损坏，但现在让我们忽略此可能性非常低的因素 – 毕竟，您始终可以实现延迟的数据库副本或传统的时间点备份来解决此问题）。
再次使用相同的概率论定理，一组 n 个独立组件的故障概率是每个组件的概率的乘积。由于此处的所有组件相同（同一对象的不同实例），因此乘积变成幂：
显然，由于 P < 1，Pn 小于 P，这意味着故障概率降低，而可用性相应地提高：
让我们考虑某个实际生活示例来进行阐述。假定我们将部署多个邮箱数据库副本；每个副本托管在单个 SATA 驱动器上。从统计上说，SATA 驱动器每年的故障率约为 5%[1]，这为我们提供了 5% 的故障概率：P = 0.05（这意味着可用性为 95%：A = 0.95）。可用性将如何随我们添加其他数据库副本而变化？查看下表，一切都不言而喻了：
数据库副本数 |
故障概率 |
可用性值 |
1 |
P1 = P = 5% |
A1 = 1 – P1 = 95% |
2 |
P2 = P2 = 0.25% |
A2 = 1 – P2 = 99.75% |
3 |
P3 = P3 = 0.0125% |
A3 = 1 – P3 = 99.9875% |
4 |
P4 = P4 = 0.000625% |
A4 = 1 – P4 = 99.9994% |
相当震憾是不是？基本上，SATA 驱动器上增加的每个数据库副本都会引入乘数 5% 或 1/20，因此每增加使用一个副本，故障概率就降低 20 倍（相应地可用性也会提高）。您可以看到即使使用最不可靠的 SATA 驱动器，仅部署 4 个数据库副本就可使数据库可用性达到五个九。
这已经非常好了，但您是否可以使其更好？您是否可以不更改体系结构而进一步提高可用性（例如，如果不可能添加其他数据库副本）？
实际上，您可以。如果您提高任何依赖组件本身的可用性，它将是提高总体服务可用性的重要因素，并将通过添加冗余组件产生更强大的影响。例如，实现此目的的一个不太昂贵的可能方法是使用 Nearline SAS 驱动器代替 SATA 驱动器。Nearline SAS 驱动器的年故障率约为 2.75% 而非 SATA 的约 5%。这会降低上述计算中的存储组件的故障概率，进而提高总体服务可用性。仅比较通过添加多个数据库副本产生的影响：
- 5% AFR = 1/20 乘数 = 每个新副本使数据库故障可能降低 20 倍。
- 2.75% AFR = 1/36 乘数 = 每个新副本使数据库故障可能降低 36 倍。
添加的数据库副本对数据库可用性的此显著影响还说明了我们的有关使用 Exchange 本机数据保护的指南，该指南讲述如果部署了足够数量（三个或更多）的数据库副本，多个数据库副本可以取代传统的备份。
同样的逻辑适用于部署 CAS 阵列中的多台客户端访问服务器、多个网络交换机等等。让我们假定我们部署了 4 个数据库副本和 4 台客户端访问服务器，并让我们重新查看我们在前面分析的组件可用性表：
关键依赖组件 |
故障概率 |
可用性值 |
邮箱服务器和存储（4 个副本） |
5% ^ 4 = 0.000625% |
99.999375% |
客户端访问服务器（4 台服务器，分开安装） |
1% ^ 4 = 0.000001% |
99.999999% |
网络 |
0.5% |
99.5% |
电源 |
0.1% |
99.9% |
总体服务（依赖以上所有组件） |
0.6% |
99.399878% |
您可以看到仅仅因为我们部署了 4 台客户端访问服务器和 4 个数据库副本，总体服务的故障概率就降低了 10 倍多（从 6.5% 降低到 0.6%），相应地，服务可用性从 93.5% 提高到更高的值 99.4%！
结论：为服务依赖项添加冗余可提高可用性。
综合起来考虑
从前面的结论中产生一个有趣的问题。我们分析了以两种不同方式影响总体服务可用性的两个不同因素，并得到了两个明确的结论：
- 添加其他系统依赖项可降低可用性
- 为系统依赖项添加冗余可提高可用性
如果这二者都是给定解决方案的因素，会发生什么？哪种趋势更强？
考虑以下方案：
我们为 DAG 中的两个邮箱服务器部署两个邮箱数据库副本（每台服务器上一个副本），并且在负载平衡阵列中部署两台客户端访问服务器。（为简单起见，我们将仅考虑用于客户端连接的邮箱数据库的可用性，而暂时不考虑集线器传输和统一消息。）假定每台服务器具有自己的故障概率 P，此类系统的可用性是将优于还是不如部署了邮箱和客户端访问服务器角色的单台独立 Exchange 服务器的可用性？
在第一个方案中，邮箱服务器是独立的，并且将仅在两台服务器都失败时才不可用。一组两台邮箱服务器的故障概率将为 P × P = P2。相应地，其可用性将为 AMBX = 1 – P2。按照相同的逻辑，CAS 服务将仅在两台客户端访问服务器都失败时才不可用，因此一组两台客户端访问服务器的故障概率将再次为 P × P = P2，并且相应地，其可用性将为 ACAS = 1 – P2。
在本例中，正如您可能已意识到的，两台邮箱服务器或两台客户端访问服务器是冗余系统组件的示例。
继续使用此方案…为使整个系统可用，两组服务器（一组邮箱服务器和一组客户端访问服务器）必须同时可用。不是同时失败，而是同时可用，因为现在它们表示系统依赖项而非冗余组件。这意味着总体服务可用性是各组的可用性的乘积：
当然，第二个方案简单得多，因为只考虑一台服务器，并且其可用性仅为 A = 1 – P。
那么现在我们计算了两个方案的可用性值，哪个值较高，(1-P2)2 还是 1-P？
如果我们绘制这两个函数的图形，我们会看到以下行为：
（我使用 Wolfram Alpha Mathematica Online（该链接可能指向英文页面） 免费计算引擎来快速轻松地进行绘图。）
我们可以看到对于小 P 值，复杂的 4 台服务器系统的可用性高于单台服务器的可用性。这没什么奇怪的；它完全符合我们的预期，不是吗？不过，在 P 约为 0.618（更准确地说为 
）时，两个绘图交叉，并且对于较大的 P 值，单台服务器系统实际上具有更高的可用性。当然，在实际生活中，您将期望 P 值非常接近于零；但如果您计划通过非常 不可靠的组件构建解决方案，您使用单台服务器可能会更好。
故障域的影响
不幸的是，实际生活的部署方案很少像上面讨论的情况那样简单。例如，如果您部署多角色服务器，服务器可用性如何变化？我们在上面的方案中注意到组合服务器角色可有效减少服务依赖项的数量，因此这可能是一件好事？如果您将同一数据库的两个数据库副本置于同一 SAN 阵列或 DAS 存储模块上，会发生什么？如果所有邮箱服务器连接到同一网络交换机，会怎样呢？如果您具有上述所有情况及其他情况，又会怎样呢？
所有这些情况都涉及故障域的概念。在上述示例中，服务器硬件或 SAN 阵列或网络交换机均表示一个故障域。故障域破坏了它所组合的组件的独立性或冗余 – 例如，多角色服务器中的服务器硬件故障意味着此服务器上的所有 Exchange 角色都变得不可用；相应地，磁盘存储模块或 SAN 阵列的故障意味着此存储模块或阵列上托管的所有数据库副本都变得不可用。
故障域不一定是坏事。重要的区别是哪种组件构成了故障域 – 它们是不同的系统依赖项还是冗余系统组件。让我们考虑上述两个示例来理解此区别。
多角色服务器方案
让我们比较两个不同系统的可用性：
- 邮箱和客户端访问服务器角色都托管在同一服务器上，该服务器的硬件故障概率为 P；
- 相同角色托管在两台不同的服务器上，每台服务器具有相同的硬件故障概率；
在第一个案例中，单台服务器的硬件表示一个故障域。这意味着所有托管角色全部可用或全部不可用。这很简单；此类系统的总体可用性为 A = 1 – P。
在第二个案例中，总体服务将仅在两台服务器都独立可用时才可用（因为每个角色表示一个关键依赖项）。因此，根据概率论，其可用性将为 A × A = A2。
此外，由于 A < 1，这意味着 A2 < A，因此在第二个案例中，可用性将较低。
显然，我们可以向同一方案中添加其他 Exchange 服务器角色（如果需要，可添加集线器传输和统一消息）而不破坏此逻辑。
结论：在多角色服务器上并置 Exchange 服务器角色可提高总体服务可用性。
共享存储方案
现在让我们考虑另一个故障域方案（两个数据库副本共享同一存储阵列），并比较以下两个案例中的数据库可用性：
- 两个数据库副本托管在同一共享存储（SAN 阵列或 DAS 存储模块）上，该存储的故障概率为 P；
- 相同数据库副本托管在两个不同的存储系统上，每个系统具有相同的故障概率；
在第一个案例中，共享存储表示一个故障域。正如在前一个方案中，这意味着两个数据库副本同时可用或不可用，因此总体可用性再次为 A = 1 – P。
在第二个案例中，总体服务将在至少一个系统可用时可用，并且仅在两个系统都失败时才不可用。这些存储系统是独立的；因此，总体服务的故障概率为 P × P = P2，并且相应地，总体服务可用性为 A = 1 – P2。
此外，由于 P < 1，这意味着 P2 < P，因此 1 – P2 > 1 – P。这意味着第二个案例中的可用性较高。
结论：在同一存储系统上并置数据库副本会降低总体服务可用性。
那么这两个方案之间有何区别，为什么引入故障域在第一个案例中会提高可用性而在第二个案例中会降低可用性？
这是因为第一个案例中的故障域组合了服务依赖项，从而有效减少了其数量并因此提高了可用性，而第二个案例中的故障域组合了冗余组件，从而有效减少了冗余并因此降低了可用性。
可以使所有这些概念和结论直观化，如下所示：
（不，我们没有使用 Wolfram Alpha 绘制此图形！）
摘要
Exchange 2010 体系结构为在 Exchange 级别上添加冗余（例如部署多个数据库副本或 CAS 阵列中的多台客户端访问服务器）和减少系统依赖项的数量（通过在多角色服务器中组合 Exchange 服务器角色或使用没有过多关键组件的较简单的存储体系结构）提供了强大的可能性。利用本文中提供的简单规则和公式，您可以计算通过部署其他数据库副本或通过组合 Exchange 服务器角色对可用性值产生的影响；您还可以计算故障域的影响。请务必注意我们尝试使用这些简单的数学模型来说明概念，而非妄想获取准确的可用性值。实际生活很少符合简单的基本方案，您需要更复杂的计算才能获得实际系统的可用性的合理估计；仅在统计上测量可用性，然后验证它是否满足 SLA 要求可能比较简单。不过，了解影响可用性的因素及其如何在复杂的工程解决方案中一起发挥作用应有助于您正确设计解决方案并大大提高总体服务可用性，从而满足最苛刻的业务要求。
Boris Lokhvitsky
交付架构师
[1] Carnegie Mellon University、Google 和 Microsoft Research 进行的以下研究显示 SATA 驱动器的 AFR 为 5%：
https://www.usenix.org/events/fast07/tech/schroeder/schroeder.pdf（该链接可能指向英文页面）
https://labs.google.com/papers/disk_failures.pdf（该链接可能指向英文页面）
https://research.microsoft.com/apps/pubs/default.aspx?id=64599（该链接可能指向英文页面）
这是一篇本地化的博客文章。请访问 DAG: Beyond the “A” 以查看原文