16、云端基础设施的灾难恢复与扩展策略

云端基础设施的灾难恢复与扩展策略

在云计算时代，云端基础设施的可靠性、可扩展性是企业关注的重点。这不仅涉及到如何应对各种可能出现的灾难情况，还包括如何合理规划资源以满足业务需求。下面将详细探讨云端基础设施的灾难恢复和扩展策略。

跨可用区部署

在亚马逊基础设施中，除块存储设备外，几乎所有资源都可在给定区域的所有可用区使用。尽管跨可用区的网络流量会产生费用，但为了实现跨可用区的冗余，这笔费用通常是值得的。

假设存在可用区 A 和可用区 B，当可用区 B 整体失效时，应用程序可能只是性能下降，但仍能正常运行。若可用区 A 失效，则需在可用区 B 启动新的负载均衡器，并将该可用区的从数据库提升为主数据库。若数据库服务器采用集群模式，且有备用负载均衡器在后台运行，可将旧负载均衡器的 IP 地址重新分配给备用负载均衡器，这样仅会出现几秒的停机时间，且不会造成数据丢失。

亚马逊服务级别协议（SLA）规定每个区域至少有两个可用区的正常运行时间达到 99.95%。若跨多个可用区部署，在拥有两个以上可用区的区域，甚至可以超越亚马逊的 SLA。例如，美国东海岸有三个可用区，两个可用区同时故障且恰好是你使用的那两个的概率仅为 33%。即便不幸遇到这种情况，只要所在区域有两个以上可用区，通过执行灾难恢复程序，在剩余可用区恢复基础设施，仍能在其他两个可用区仍处于故障状态时恢复运营。

跨区域运营

目前，亚马逊支持两个区域：美国东部（us - east - 1）和西欧（eu - west - 1）。这两个区域的基础设施几乎没有交集，其优势在于若跨区域运营，应用程序基本能在遭受美国或欧盟（不同时遭受）的重大灾难时存活下来。但缺点是缺乏共同基础设施，使得跨区域复制环境变得困难。

每个区域都有与之关联的亚马逊 S3 区域，因此不能使用美国的 AMI 在欧盟启动 EC2 实例，也不能将欧盟负载均衡器的 IP 地址用于美国的替代负载均衡器。

跨区域运营涉及多个方面的管理问题：
- DNS 管理 ：可以使用轮询 DNS 来解决 IP 地址不可跨区域移植的问题，但会导致欧洲访客被导向美国，反之亦然，造成网络流量管理效率低下，且当一个区域出现故障时会损失一半流量。可借助动态 DNS 系统（如 UltraDNS），根据源地址和可用性提供正确的 DNS 解析。
- 数据库管理 ：跨区域集群可能不太实际，但可以尝试。也可在一个区域设置主数据库，在另一个区域设置从数据库，写操作针对主数据库，从数据库所在区域的流量则从从数据库读取。还可将数据库进行分段，使欧洲区域存储“欧洲数据”，美国区域存储“美国数据”，每个区域在另一个区域都有一个从数据库作为区域完全故障时的恢复点。
- 监管问题 ：欧盟不允许某些数据存储在欧盟以外，因此，无论设计出多么巧妙的技术解决方案，从法律上讲，可能都不允许跨区域运营。实际上，采用亚马逊 + GoGrid 或亚马逊 + Rackspace 的冗余方案可能比使用亚马逊的两个跨司法管辖区的区域更有效。

对于大多数情况，建议定期将基础设施元素（AMIs、备份和配置）复制到另一个区域，并具备在核心区域完全、长时间故障时迅速启动该基础设施的能力。

组织冗余

即便拥有完善的基础设施，在业务层面仍存在风险。例如，若使用的云服务提供商（如亚马逊、Rackspace 或 GoGrid）倒闭或放弃云计算业务，可能会陷入困境。

物理灾难相对较少，但公司倒闭的情况每天都在发生，即便像亚马逊和 Rackspace 这样的大公司也不例外。因此，灾难恢复计划应考虑云服务提供商消失的可能性。

最佳的组织冗余方法是确定另一个云服务提供商，并在主提供商出现故障时在该提供商处建立备份环境。选择备用云服务提供商时，必须确保其不依赖主提供商的任何资源。例如，若备用云服务提供商使用主提供商的数据中心来托管其物理基础设施，将无法抵御主提供商的故障。

组织冗余还涉及以下几个方面的问题：
- 在备用云服务提供商处存储可移植的备份。
- 创建能够在备用提供商的虚拟化环境中运行应用程序的机器映像。
- 使机器映像与主提供商的对应映像保持同步更新。
- 并非所有云服务提供商和托管服务提供商都支持相同的操作系统或文件系统，若应用程序依赖特定的操作系统或文件系统，需确保选择的云服务提供商能够满足需求。

灾难管理

要完成灾难恢复场景，不仅要进行备份并建立具有适当冗余的基础设施，还需识别灾难何时发生，并具备执行恢复计划的工具和流程。云计算的一大优势是这些过程可以自动化，甚至可以在睡觉时从亚马逊美国数据中心的故障中恢复。

监控

监控云基础设施至关重要，若不知道服务器出现故障，就无法更换故障服务器或执行灾难恢复计划。监控系统必须独立于主云和备用云基础设施，若要实现自动化灾难恢复，监控系统还需具备从监控站点管理 EC2 基础设施的能力。

有许多工具（如 enStratus 和 RightScale）可用于管理基础设施，有些甚至能自动化灾难恢复过程，无需编写自定义代码。

监控的主要目标是在故障实际发生之前预测可能出现的问题。例如，在 EC2 中，常见的问题是服务器的本地文件 I/O 吞吐量逐渐下降，直至无法使用。通过监控可以在用户察觉之前发现并解决该问题，避免应用程序完全故障，因为这可能是更大规模云故障事件的先兆。

此外，还需在三个层面监控故障：
- 通过供应 API（如亚马逊的 EC2 网络服务 API）
- 通过自己的实例状态监控工具
- 通过应用程序健康监控工具

云服务提供商的供应 API 能告知实例的健康状况、挂载的卷以及运行的所在数据中心。当在此层面检测到故障时，可能意味着云本身出现问题。在进行任何灾难恢复之前，需确定故障是局限于一台服务器，还是影响不确定数量的服务器，甚至影响整个可用区或区域。

监控不仅是为了检测灾难，更多的是检查日常情况。例如，使用 enStratus 时，可在每台服务器上部署一个 Python 服务，检查各种服务器健康指标（主要与容量管理相关）。若服务器或其配置出现问题，该服务会通知监控系统，以便采取适当措施，同时还会检查实例上运行的应用程序的健康状况。

负载均衡器恢复

企业为物理负载均衡器支付高额费用，是为了大幅降低负载均衡器故障的可能性。使用像 GoGrid 这样的云供应商（未来可能包括亚马逊），可以在不承担高昂成本的情况下实现硬件负载均衡器的优势。在当前的 AWS 服务中，需使用可靠性较低的 EC2 实例，但在云端恢复负载均衡器速度极快，因此基于云的负载均衡器故障的负面影响较小。

恢复负载均衡器只需从 AMI 启动一个新的负载均衡器实例，并将应用服务器的 IP 地址告知它。还可通过在备用可用区运行一个负载均衡器，在主负载均衡器故障时重新映射静态 IP 地址，进一步减少停机时间。

应用服务器恢复

若在多个可用区运行多个应用服务器，系统整体能够承受任何一个实例甚至整个可用区的故障。但仍需恢复故障服务器，以避免未来的故障影响基础设施。

恢复故障应用服务器比恢复故障负载均衡器稍复杂。首先从应用服务器机器映像启动一个新实例，然后传递配置信息（包括数据库位置）。服务器正常运行后，需通知负载均衡器新服务器的存在（同时停用对旧服务器的认知），使新服务器加入负载均衡轮转。

数据库恢复

数据库恢复是云端灾难恢复中最困难的部分。灾难恢复算法需确定未损坏的数据库副本所在位置，这可能涉及将从数据库提升为主数据库、重新安排备份管理以及重新配置应用服务器。

最佳解决方案是采用集群数据库，这样可以在单个数据库服务器故障时无需执行复杂的恢复程序。若没有集群，最佳恢复计划是启动一个新的数据库实例，并挂载原故障实例仍可使用的 EC2 卷。但当实例出现故障时，可能会出现一系列相关问题，影响该策略的实施：
- 数据库可能因导致实例崩溃的原因而无法修复地损坏。
- 卷可能随实例一起故障。
- 实例所在的可用区（以及卷）可能不可用。
- 可能无法在卷所在的可用区启动新实例。

为应对这些情况，需要一个备用恢复计划，以下是通常涵盖所有数据库故障级别的恢复过程：
1. 在旧实例所在的可用区启动一个替换实例，并挂载其旧卷。
2. 若启动失败但卷仍在运行，对卷进行快照，在任何区域启动一个新实例，并根据快照在该区域创建一个卷。
3. 若步骤 1 中的卷或步骤 2 中的快照损坏，需退回到复制从数据库，并将其提升为数据库主服务器。
4. 若数据库从服务器未运行或损坏，下一步是从最近的数据库快照启动一个替换卷。
5. 若快照损坏，继续回溯时间，直到找到未损坏的备份。

步骤 4 通常代表最坏情况，若到了步骤 5，则说明备份方式可能存在问题。

为确保备份有效，需要测试灾难恢复程序。建议每季度测试一次，至少每年测试一次。数据库备份是灾难恢复过程中最容易出错的部分，若数据库备份不当，备份可能看似成功，但实际上会导致数据库备份损坏。

测试数据库备份工具的最简单方法是设置一些机器人对数据库施加高写入事务负载，在机器人运行时执行备份脚本，然后尝试从备份中恢复数据库。若备份过程存在问题，该测试将导致恢复的数据库损坏。

容量规划

云计算基础设施的一大优势是能够根据需求自动进行垂直和水平扩展，对基础设施中运行的应用程序影响极小。这一特性从根本上改变了 IT 经理与基础设施的关系，也改变了财务经理对 IT 资金的看法。但这是一把双刃剑。

云扩展的明显好处是只需为使用的资源付费，而传统非云方法是为峰值容量购买基础设施，导致资源浪费，且依赖准确的容量规划。然而，云扩展也可能成为懒惰的系统架构师避免进行容量规划的借口，过度依赖云扩展可能导致组织在需求无实际业务效益时增加云实例。

为了合理应用云的全部功能，避免其带来的风险，成功的关键在于合理的容量规划。容量规划的核心是制定策略，确保基础设施能够支持所面临的资源需求。虽然容量规划的细节可以写成一本书，但对于云计算扩展，主要关注以下核心问题：
- 了解预期的使用模式，包括一天内、一周内、节假日以及业务的季节性变化。
- 了解应用程序对负载的响应，以便确定何时以及需要何种额外容量。
- 了解系统对业务的价值，以便知道何时增加容量有价值，何时没有价值。

有些观点认为云计算环境可根据需求自动扩展，因此无需进行容量规划；还有些人认为容量规划意味着高额的咨询费用。这两种观点都是危险的误区。容量规划在云计算中与物理基础设施中同样重要，而且无需进行大规模的容量规划项目就能制定合理的计划。最终目标是确保在扩展基础设施产生额外成本时，这些成本能够支持基础设施的目标。

预期需求

必须了解对应用程序的预期需求，无需精确预测每天网站的页面浏览量，只需有一个量化的预期，以便：
- 规划基础设施以支持预期负载
- 识别实际负载与预期负载的显著偏差
- 理解应用程序需求变化对基础设施的影响

需求估计的最明显价值在于结合对系统负载响应的理解，确定所需服务器的数量、类型以及所需资源。若对使用网站或应用程序的人数一无所知，就无法确定所构建的基础设施是否能正常工作，可能在部署后一小时内就出现故障，或者在不必要的基础设施上浪费大量资金。

容量规划的目的不是消除意外的需求高峰，而是帮助规划预期情况，识别意外情况，并对偏差做出适当反应。

综上所述，云端基础设施的灾难恢复和扩展策略是一个复杂的系统工程，需要综合考虑多个方面的因素，通过合理的规划和管理，确保基础设施的可靠性和可扩展性，以满足业务的不断变化的需求。

云端基础设施的灾难恢复与扩展策略

水平扩展与垂直扩展

云基础设施具备自动进行水平和垂直扩展的能力，这是其显著优势之一。下面来详细了解这两种扩展方式。

水平扩展

水平扩展是指通过增加服务器数量来应对负载。当业务需求增长时，可以在现有架构中添加更多的服务器实例。例如，当网站的访问量增加时，可以启动更多的应用服务器来分担流量。这种扩展方式的优点在于可以灵活地根据需求调整服务器数量，成本相对较低。但也存在一些挑战，如需要解决服务器之间的负载均衡问题，确保流量均匀分配到各个服务器上。

垂直扩展

垂直扩展则是通过提升单个服务器的性能来满足需求。可以增加服务器的 CPU、内存、存储等资源。比如，将服务器的内存从 8GB 升级到 16GB。这种扩展方式的优点是操作相对简单，不需要对现有的架构进行大规模调整。然而，它也有局限性，因为单个服务器的性能提升是有上限的，当达到一定程度后，可能无法再满足业务的增长需求。

为了更直观地对比这两种扩展方式，我们来看下面的表格：
| 扩展方式 | 优点 | 缺点 | 适用场景 |
| — | — | — | — |
| 水平扩展 | 灵活调整服务器数量，成本较低 | 需要解决负载均衡问题 | 业务需求增长较为频繁，对成本敏感的场景 |
| 垂直扩展 | 操作简单，无需大规模调整架构 | 性能提升有上限 | 业务需求增长相对稳定，对性能要求较高的场景 |

云扩展的风险与应对措施

虽然云扩展带来了诸多便利，但也存在一些风险，需要采取相应的措施来应对。

过度依赖云扩展

有些系统架构师可能会过度依赖云扩展，而忽视了容量规划。这可能导致在需求无实际业务效益时盲目增加云实例，造成资源浪费和成本上升。为了避免这种情况，需要加强对容量规划的重视，结合业务需求和系统性能进行合理的资源分配。

云服务提供商的限制

不同的云服务提供商可能对扩展有不同的限制，如最大实例数量、资源配额等。在选择云服务提供商时，需要了解其扩展政策和限制，确保能够满足业务的未来发展需求。同时，也可以考虑使用多个云服务提供商，以降低单一提供商带来的风险。

数据一致性问题

在进行水平扩展时，多个服务器之间的数据一致性是一个重要问题。如果数据不一致，可能会导致应用程序出现错误。可以采用数据复制、分布式缓存等技术来确保数据的一致性。

监控与调整

为了确保云基础设施能够高效运行，需要进行持续的监控和调整。

监控指标

需要监控多个关键指标，如 CPU 使用率、内存使用率、磁盘 I/O、网络带宽等。通过监控这些指标，可以及时发现系统的性能瓶颈和潜在问题。例如，当 CPU 使用率持续超过 80% 时，可能需要考虑进行扩展。

下面是一个简单的监控指标表格：
| 监控指标 | 含义 | 作用 |
| — | — | — |
| CPU 使用率 | 服务器 CPU 的使用比例 | 评估服务器的计算能力是否充足 |
| 内存使用率 | 服务器内存的使用比例 | 判断是否需要增加内存 |
| 磁盘 I/O | 磁盘的读写操作频率 | 检查磁盘性能是否满足需求 |
| 网络带宽 | 服务器的网络传输速率 | 确保网络能够支持业务流量 |

自动化调整

利用自动化工具可以根据监控指标自动进行扩展或收缩操作。例如，当 CPU 使用率超过阈值时，自动启动新的服务器实例；当使用率下降时，自动关闭多余的实例。这样可以提高系统的响应速度，减少人工干预。

下面是一个简单的自动化调整流程 mermaid 流程图：

graph TD;
    A[监控指标] --> B{指标是否超过阈值};
    B -- 是 --> C[启动新实例];
    B -- 否 --> D{指标是否低于阈值};
    D -- 是 --> E[关闭多余实例];
    D -- 否 --> A;

总结

云端基础设施的灾难恢复和扩展策略是保障业务稳定运行的关键。通过跨可用区部署、跨区域运营、组织冗余等措施，可以提高基础设施的可靠性，应对各种可能的灾难情况。同时，合理的容量规划和对预期需求的准确把握，能够确保在扩展基础设施时，资源得到有效利用，为业务带来实际价值。

在扩展方面，水平扩展和垂直扩展各有优缺点，需要根据业务需求和场景进行选择。并且要注意云扩展带来的风险，通过监控和自动化调整来保障系统的高效运行。

总之，企业在云端基础设施的建设和管理中，需要综合考虑各个方面的因素，制定科学合理的策略，以适应不断变化的业务需求，实现业务的可持续发展。