MadBOK

# 解决方案架构的可靠性设计

应用程序的可靠性是架构设计的重要方向之一，高可用性是应用程序的强制标准之一，可靠性是指系统从故障中恢复的能力，是应用程序应具备的容错能力，出现故障时能够在不影响体验的情况下恢复，系统应该为处理任何可能出现的故障做好对应的准备。

# 架构可靠性的设计原则

可靠性的目标是将故障的影响控制在最小范围内，为了应对系统最坏的情况，我们需要再故障发生前测试恢复过程，并将这个过程自动化，以减少人为错误发生的概率。所有的可靠性设计原则其实都是密切相关、相辅相成的，下述是架构可靠性的几条必备原则：

  • 使系统自愈。系统故障需要提前预测，在故障发生时，系统应该能自动响应并进行恢复，这就是系统自愈，具备自愈能力的系统能主动检测故障，并对故障进行响应。可以确定应用程序和业务的关键绩效指标（KPI），在用户层面这些KPI可能包括每秒的请求数或网站的页面加载延迟，在基层设施层面，可以定义CPU利用率的阈值，还可以定义内存利用率等，定义好KPI后，可以部署自动监控系统跟踪KPI达到阈值后的故障并进行通知。
  • 实现自动化。自动化是提高应用程序可靠性的关键，应尝试将应用程序部署和配置甚至整个基础设施自动化，可以根据日程流量来规划应用程序的自动伸缩功能，根据请求量来自动伸缩，以处理不可预知的工作负载。
  • 创建分布式系统。单体应用的可靠性很低，将应用程序划分为多个小服务，可以减小影响范围。在服务层面，可以通过对应用程序进行水平伸缩来提高系统的可用性，应将系统上合计为可以使用多个较小的组件协同工作，请求由系统的不同组件处理，一个组件的故障不会影响系统其他部分的功能。
  • 容量监控。CPU、内存或硬盘过载会使应用程序出现故障，我们需要一个无需预测容量的环境，这样英语程序就可以按需伸缩，我们要监控系统资源的供需情况，并按需自动添加或移除资源，这样就可以解决过度供应或供应不足的情况。
  • 验证恢复过程。应在一切都可能失败的假设下验证应用程序，基于模拟的验证可以帮助我们发现潜在风险，我们可以将可能导致系统出现故障的场景自动化，并准备好相应的事件响应方案，验证确保生产环境不会发生故障的方式来提高应用程序的可靠性。

# 架构可靠性的技术选型

有几个因素能够使应用程序高可用，其中容错性是指应用程序组件有内置冗余，可伸缩性是指应用程序的基础设施如何响应不断增长的容量需求，以确保应用程序始终可用并在所属标准内运行。为了使应用程序可靠，我们可以设计快速恢复服务，灾难恢复会涉及到恢复时间目标（RTO）和恢复点目标（RPO）及数据复制等等。

# 规划RTO和RPO

RPO是指组织可以容忍多长时间的数据丢失，其有助于定义数据备份策略，RTO涉及应用程序的停机时间，以及应用程序在故障发生后应该需要多长时间来恢复和进入正常运行状态。

组织通常会根据系统不可用时的用户体验和对业务的财务影响来决定可接受的RTO和RPO，IT部门根据定义的RTO和RPO来规划解决方案，以便在发生事故时能进行有效的系统恢复。

# 数据复制

数据复制和快照是灾难恢复和系统可靠性的关键，数据复制是指在备用站点上创建主站点的一个数据副本，当主系统发生故障时，系统可以将流量转移到备用站点上，并继续可靠的工作。该数据可以是存储在NAS驱动器中的文件数据、数据库快照或机器镜像快照。站点可以是两个不同地理位置的本地系统，也可以是同一本地环境下的两个独立设备，或者是物理隔离的公有云。

数据复制不仅有助于灾难恢复，而且可以通过快速创建新的测试和开发环境来提高组织的敏捷性。数据可以是同步复制，也可以是异步复制。

同步复制可以实时创建数据副本。实时数据复制有助于减少RPO，并在发生故障时提高可靠性。然而，它的成本很高，因为它需要主系统中的额外资源来进行持续的数据复制。异步复制以一定的延迟或按照定义的周期来创建数据副本。异步复制的成本较低，因为与同步复制相比，它使用的资源较少。如果系统可以在较长的RPO下工作，可以选择异步复制。

在数据库技术方面，如果我们创建了具备多可用区故障转移能力的分布式数据服务，就能够实现同步复制。对于只读副本，以使用异步复制来服务报告和读取请求。

数据复制是指从源系统中提取数据并创建副本以实现数据恢复，根据存储类型不同，有不同的方法可以存储数据，具体的方式如下：

  • 基于阵列的复制。可以使用内置软件自动复制数据。但是，源存储阵列和目标存储阵列应该同质且互相兼容，才能复制数据。存储阵列的机架上会包含多个存储磁盘。大型企业使用基子阵列的复制方法，因为它易于部署，还能够使主机所需的计算能力有所降低。选择基于阵列的复制产品，如HP存储、EMC SAN Copy和NetApp SnapMirror。
  • 基于网络的复制。它可以在不同类型的异构存储阵列之间复制数据，通过在不兼容的存储阵列之间使用额外的交换机或设备来复制数据。在基于网络的复制中，由于有多个参与者加入，复制成本可能会更高。可以选择基于网络的数据复制产品，如NetApp Replication X和MC RecoverPoint。
  • 基于主机的复制。需要在主机上安装一个软件代理，它可以将数据复制到任意存储系统，如NAS、SAN或DAS。
  • 基于虚拟机的复制。是虛拟机层面的数据复制，这意味着它可以将整个虛拟机从一台主机复制到另一台主机。由于企业大多使用虚拟机，它提供了一种非常有效的灾难恢复方法，以减少RTO。

# 规划灾难恢复

灾难恢复 (Disaster Recovery， DR）是指系统在发生故障的情况下，依然能够保持业务的连续性。它表明组织应对任何可能的系统故障，并从故障中恢复的能力。灾难恢复规划包括多个方面，其中包括硬件或软件故障。在规划灾难恢复的同时，一定要考虑其他的运维故障，包括停电、网络中断、供热和制冷系统故障、物理安全漏洞，以及火灾、洪水或其他人为错误等不同的事件。

应用程序的复杂度各有不同。DR场景分为四种，按RTO和RPO从高到低排列如下：

  • 备份和恢复：备份的成本最低，但RPO和RTO较高，在合适的场景下具有极高的成本效益。可以预装软件来构建自己的机器镜像，并将其存储在云端，如果主站点停机，可以从云端搜索备份并启动所需的基础设施，从备份中恢复数据，
  • 指示灯策略：指示灯策略是指在不同区域保持运行最低数量的核心服务，当灾难发生时就可以快速启动额外的资源。可以主动对数据库层进行复制，然后从虚拟机镜像启动实例，这种策略需要备份大多数组件并被动的存储它们。
  • 暖备策略：是指全功能低容量待机，我们可以决定灾备环境是否应该足以应对30%或50%的生产流量，在暖备中，所有组件必须全天运行，它们不会根据生产环境的流量二扩展规模。
  • 多站点策略：可以帮助实现接近零的RTO和RPO。在多站点中，灾备站是主站点的精确副本，具有不间断的数据复制功能，由于跨区域或本地和云之间的流量可以实现自动负载均衡，因此被称为多站点架构。多站点方案的优势在于，它随时可以承担全部生产负荷，如果主站出现故障，所有流量都可以立即转移到灾备站点。

# 灾难恢复的最佳实践

在考虑灾难恢复时，需要注意以下重点事项：

  • 从小处着手并根据需要进行构建：第一步是备份，我们要确保其简单有效。在大多数情況下，组织会因为缺少有效的备份策略而丢失数据。应备份所有内容，无论是文件服务器、机器镜像还是数据库。保留大量活动的备份可能会增加成本，因此请确保根招业务需要应用生命周期策略来存档和删除教据。
  • 检查软件许可证：软件许可证可能与软件的装机量、CPU数和使用用户相关联。当进行伸缩时，这就会变得很辣手。我们需要有足够的许可证来支持伸缩需求。水平伸缩需要增加更多安装好软件的实例，而在垂直伸缩中，则需要增加更多的CPU或内存。我们要了解软件许可协议，并确保具备相应的许可来支持系统伸缩，应确保像管理基础设施或软件一样管理许可证库存。
  • 经常测试解决方案：灾备站点是为罕见的灾难恢复事件而建立的，但往往被忽视。我们需要确保灾难恢复解决方案在事件发生时能按预期工作，以实现更高的可靠性。你可以选择一个生产负载较小的日子，召集所有负责维护生产环境的团队来模拟灾难事件（比如将生产环境的一部分服务停机），让团队进行处理以保特环境的正常运行。这能测试我们是否有可用的备份、 快照和机器镜像来处理灾难事件。

我们务必要建立监控系统，以确保在事件发生时，能自动将故障转移，监控结合自动化，可以帮助我们主动提高系统的可靠性，对容量的健康能预防可能会影响应用程序可靠性的资源饱和问题，应创建灾难恢复计划并定期执行恢复验证。

← 解决方案架构的运维设计 →