目录
[1.1 常见灾备表格](#1.1 常见灾备表格)
[1.2 解释各类型的特点](#1.2 解释各类型的特点)
[1.3 选择适合的方案](#1.3 选择适合的方案)
[2.1 需要跨区域的灾备方案](#2.1 需要跨区域的灾备方案)
[2.2 不需要跨区域的灾备方案](#2.2 不需要跨区域的灾备方案)
[2.3 总结](#2.3 总结)
[3.1 跨Region（跨区域）](#3.1 跨Region（跨区域）)
[3.2 跨AZ（跨可用区）](#3.2 跨AZ（跨可用区）)
[3.3 主要区别总结](#3.3 主要区别总结)
[4.1 架构图](#4.1 架构图)
[4.2 整体概述](#4.2 整体概述)
[4.2.1 北京四（生产站点）](#4.2.1 北京四（生产站点）)
[4.2.2 上海（异地容灾站点）](#4.2.2 上海（异地容灾站点）)
[4.2.3 关键特性解析](#4.2.3 关键特性解析)
[4.2.4 总结](#4.2.4 总结)
1.常见的灾备方案和架构类型
1.1 常见灾备表格
|---------------------------------------|-------------------|---------------------|--------------|----------------------|------------------|---------------------|
| 灾备类型 | 备用系统状态 | 是否提供服务 | 数据同步情况 | 恢复时间 | 成本与资源使用 | 适用场景 |
| 热备（Hot Standby） | 备用系统开启并实时同步主系统数据 | 不直接提供服务，主要进行数据同步 | 实时同步 | 故障发生时恢复迅速，几秒到几分钟 | 高，备用系统常驻且同步数据 | 高可用性要求高，且可接受少量资源开销 |
| 冷备（Cold Standby） | 备用系统关闭，故障时才启动 | 不提供服务，直到启动备用系统 | 无实时同步，需从备份恢复 | 恢复时间较长，几分钟到几小时 | 低，备用系统关闭且不消耗资源 | 成本敏感，故障恢复时间较长的场景 |
| 双活（Active-Active） | 所有系统都在运行，多个节点并行工作 | 所有节点都处理请求并提供服务 | 实时同步或负载均衡 | 无故障，负载均衡流量，故障切换几乎无延迟 | 非常高，所有节点都在处理流量 | 高可用性、高性能要求，多个数据中心支持 |
| 主备（Active-Passive） | 主系统运行，备用系统关闭或待命 | 备用系统不提供服务，只有主系统处理流量 | 实时同步或异步同步 | 故障时备用系统激活，恢复时间短 | 中，备用系统在待命状态下同步数据 | 适合对成本敏感但又需要灾备的场景 |
| 异地容灾（Geographically Redundant DR） | 多个地理位置的数据中心或可用区 | 可根据需要激活不同的站点 | 异地备份，数据同步 | 故障发生时，自动或手动切换到其他站点 | 高，涉及多个地理位置的资源 | 高容灾要求，尤其是面对自然灾害的场景 |
| 数据备份（Backup） | 备用系统不运行，只有备份数据 | 备份文件、磁带、云存储等 | 备份数据，非实时同步 | 恢复时间较长，几小时到几天 | 较低，通常为离线备份或云备份 | 适用于不需要实时恢复的场景 |
1.2 解释各类型的特点
热备（Hot Standby）：
- 备用系统实时同步数据，但不处理流量。只有在主系统发生故障时，备用系统会立刻接管服务。恢复时间很短，但备用系统始终保持同步，资源消耗较高。
冷备（Cold Standby）：
- 备用系统关闭，只有在主系统发生故障时才会启动并恢复服务。恢复时间较长，且可能存在数据丢失或恢复不完全的风险，资源消耗较低。
双活（Active-Active）：
- 所有系统都在运行，多个节点并行处理流量，保证高可用性和负载均衡。即使一个节点发生故障，其他节点也能继续提供服务。适用于对高可用性、性能和负载均衡要求高的业务。
主备（Active-Passive）：
- 只有主系统提供服务，备用系统待命或关闭。备用系统实时同步或异步同步主系统的数据，在故障发生时快速切换。恢复时间比热备稍长，但比冷备短。
异地容灾（Geographically Redundant DR）：
- 采用多个地理位置的备份数据中心，确保灾难发生时，不同地区的数据中心可以接管服务。常用于防止自然灾害、区域性网络故障等大范围问题。
数据备份（Backup）：
- 定期对数据进行备份存储（如在磁带、云存储等地方）。恢复时间较长，通常用于长期存储和对恢复时间要求不高的场景，成本较低。
1.3 选择适合的方案
- 高可用性与性能要求 ：如果你的应用需要持续的高性能和高可用性，且可以接受较高的资源开销，双活 或 热备 是最适合的选择。
- 成本敏感 ：如果你的预算较紧张，且容忍恢复时间较长，冷备 和 数据备份 是更合适的选择。
- 灾难防范和地理分布 ：如果你需要防范自然灾害或需要跨地区冗余保护，异地容灾 是最佳方案。
2.跨区域和非跨区域的灾备方案
2.1 需要跨区域的灾备方案
这些方案通常要求在不同的地理位置、数据中心或可用区中提供备份或冗余，以防止自然灾害、区域性网络中断等影响业务连续性。
异地容灾（Geographically Redundant DR）：
- 需要跨区域：此方案要求将数据和服务部署到不同的地理区域或数据中心，确保当一个地区发生灾难时，其他地区可以接管服务，保证业务不受影响。
- 适用场景：大规模企业、金融行业、电商平台等，需要确保在任何情况下都能恢复服务，尤其是在大范围的自然灾害、地震、区域性断网等情况发生时。
双活（Active-Active）：
- 通常需要跨区域：双活架构通常要求多个数据中心或可用区同时提供服务，因此，跨区域是常见的实现方式。双活架构的多个站点可以分布在不同区域，以实现负载均衡和高可用性。
- 适用场景：要求极高可用性和性能的场景，如全球化的电商、在线金融服务等，需要处理大量并发请求，并且要求最小化故障恢复时间。
跨区域备份（Cross-region Backup）：
- 需要跨区域：一些灾备策略会将备份数据存储在不同的地理区域，确保一旦某个区域出现故障，备份数据仍然可以从其他区域恢复。
- 适用场景：需要高安全性的企业，尤其是政府、金融或医疗领域，需要备份数据存储在异地以应对灾难恢复。
跨区域高可用部署（Cross-region High Availability）：
- 需要跨区域：类似于双活，跨区域高可用部署在多个地理区域配置服务，保证在一个区域故障时，业务能够无缝迁移到另一区域继续提供服务。
- 适用场景：面向全球用户的应用，如国际电商平台、社交媒体平台等。
2.2 不需要跨区域的灾备方案
这些方案可以在单一数据中心或单一区域内完成灾备工作，不涉及地理区域的分布。
热备（Hot Standby）：
- 通常不需要跨区域：热备架构通常是在同一数据中心或同一区域内配置主系统和备用系统，备用系统在主系统故障时快速接管。虽然也有可能将热备系统部署在不同区域，但大多数情况下，它们是在同一数据中心或可用区内。
- 适用场景：中小型企业，或者对跨区域容灾要求不高的场景，例如一些区域性服务平台。
冷备（Cold Standby）：
- 不需要跨区域：冷备通常是在单一数据中心或同一区域内配置备用系统，备用节点只有在主系统发生故障时才会启动，且通常是关闭状态。
- 适用场景：对灾备恢复时间要求不高，成本敏感的小型企业或特定应用，如较小的本地化服务。
主备（Active-Passive）：
- 通常不需要跨区域：主备架构可以在同一数据中心或同一可用区内实现，备用系统处于待命状态，只有在主系统故障时才会激活。虽然也有可能实现跨区域，但常见配置是在同一区域内。
- 适用场景：对高可用性有一定要求，但又不需要极高的容灾能力的企业，尤其是对成本控制较严格的场景。
数据备份（Backup）：
- 不需要跨区域：数据备份通常在同一数据中心或区域内进行，备份数据可能存在于本地磁带、硬盘或云存储中，但这些备份并不涉及跨区域存储。数据备份更关注的是防止数据丢失，而不是灾难恢复。
- 适用场景：不需要实时恢复，只需确保数据不丢失的应用，适合一些对恢复时间不敏感的小型企业或长期数据存储需求。
2.3 总结
| 灾备方案 | 是否需要跨区域 | 适用场景 |
|---|---|---|
| 异地容灾 | 是 | 需要防范大范围灾难、区域性故障的高可用性需求 |
| 双活 | 通常是 | 高可用、高性能要求，全球化业务、电商、金融等 |
| 跨区域备份 | 是 | 高安全性、合规性要求的企业，尤其是金融和医疗领域 |
| 跨区域高可用部署 | 是 | 面向全球用户的服务平台，如国际电商、社交媒体等 |
| 热备 | 不一定 | 中小型企业或灾备恢复时间要求较短的场景 |
| 冷备 | 不一定 | 成本敏感，灾备恢复时间不敏感的场景 |
| 主备 | 不一定 | 中小型企业，灾备需求不高但希望有备份的场景 |
| 数据备份 | 不一定 | 数据存储和恢复，不涉及跨区域灾备的应用 |
选择是否跨区域的建议
- 如果你的业务涉及跨国或全球化服务 （例如全球电商平台、国际金融机构），跨区域灾备（如异地容灾、双活架构）是非常必要的，以保证无论在哪个地区发生灾难，都能迅速恢复服务。
- 如果你的业务只在一个地区运营，且对灾备恢复时间的要求不高，选择不需要跨区域的方案（如热备、冷备、数据备份等）可能更为经济实用。
3.跨az和跨region有什么区别
3.1 跨Region（跨区域）
区域（Region）是云平台的一个更大范围的地理划分，通常跨越城市、国家或大洲。每个区域内有多个可用区（AZ）。跨Region部署意味着在不同区域之间进行冗余部署，通常覆盖多个地理位置。
特点：
- 地理位置：跨Region架构位于不同的地理区域，可能跨越不同的城市、国家或大洲。这样可以提供更强的容灾能力，应对区域性灾难。
- 网络延迟：跨Region部署的延迟较高，因为数据需要跨越更远的物理距离，可能影响一些实时应用的性能。
- 容灾能力：跨Region能够应对大范围灾难（如大规模自然灾害、大范围网络中断等），提高系统的全球容灾能力。
- 恢复时间：由于涉及到跨区域通信，故障恢复时间较长，可能需要几小时甚至更长时间来恢复服务。
- 成本：跨Region通信的成本较高，尤其是数据传输费用和跨地域的服务费用。
适用场景：
- 全球业务：需要全球范围的容灾和数据冗余，尤其是跨国或跨洲的应用（如国际电商平台、全球金融系统等）。
- 大范围灾难防护：对区域性灾难具有高容忍度，确保在一个区域出现灾难时，另一个区域能够完全接管服务。
- 合规性要求：某些行业（如金融、医疗、政府）可能需要将数据存储在特定区域，或根据不同区域的法律和合规要求进行数据隔离。
3.2 跨AZ（跨可用区）
可用区（AZ）是云平台内部的一种隔离区域。每个区域（Region）内包含多个可用区，它们位于不同的数据中心，且相互隔离。跨AZ部署意味着在同一区域内的不同可用区之间进行冗余部署。
特点：
- 地理位置：在同一个区域内，不同的可用区通常位于物理上分隔较远的位置，防止某一灾难影响到整个区域。
- 网络延迟：跨AZ的延迟通常较低，因为它们位于同一区域内，网络连接较快。
- 容灾能力：跨AZ架构可以容忍局部硬件故障、数据中心故障等，但是不可防止区域性灾难（例如自然灾害或大规模网络中断）。
- 恢复时间：一般较短，故障切换可以在几分钟内完成，适合需要较高可用性的业务。
- 成本：由于同一区域内的跨AZ通信成本相对较低，因此跨AZ部署的成本较为经济。
适用场景：
- 需要高可用性，但不必跨区域进行部署。
- 网络延迟敏感的应用，如实时数据处理、数据库、高性能计算等。
- 云平台中大多数应用，尤其是需要容忍硬件或局部故障的场景。
3.3 主要区别总结
| 特性 | 跨AZ（可用区） | 跨Region（跨区域） |
|---|---|---|
| 地理位置 | 同一地区内的不同数据中心（隔离区域） | 跨越不同的地理位置、城市、国家或大洲 |
| 网络延迟 | 较低，通常位于相对较近的地理位置 | 较高，可能跨越较大的物理距离，影响性能 |
| 容灾能力 | 能应对硬件故障、局部灾难等，但无法应对区域性灾难 | 能应对大范围灾难，如自然灾害、国家级网络中断等 |
| 恢复时间 | 通常较短，几分钟到几十分钟 | 通常较长，可能需要几小时或更长时间 |
| 成本 | 较低，通信成本较低 | 较高，跨区域通信和数据传输费用较贵 |
| 适用场景 | 对高可用性要求较高，但不必跨区域的场景 | 对全球业务、跨国灾难恢复有需求的场景 |
选择跨AZ或跨Region的建议
- 如果你的业务对恢复时间有很高要求，且只需要防范硬件故障或局部灾难 ，则跨AZ是最合适的选择。它能提供较短的故障恢复时间，且具有较低的成本。
- 如果你的业务需要应对大范围的灾难（如自然灾害、区域性网络故障），并且有全球化需求 ，那么选择跨Region会更合适。它能提供更强的灾难恢复能力，但成本较高，且恢复时间较长。
4.架构图与解析
4.1 架构图
这张架构图是一个云上系统的高可用与容灾设计，包含本地容灾（跨AZ）和异地容灾（跨Region）两个部分。
4.2 整体概述
- 主要区域 ：
- 北京四：生产站点，包含两个可用区（可用区1和可用区2）。
- 上海：异地容灾站点，用于跨区域容灾。
- 组件服务 ：
- 生产站点在北京，负责主要服务运行。
- 使用存储容灾服务（SDRS）实现本地容灾。
- 使用云备份服务（CBR）和数据库复制服务（DRS）实现异地容灾。
- 异地容灾站点通过虚拟专有网络（VPN）和DNS解析连接到生产站点。
4.2.1 北京四（生产站点）
可用区1
- ecs-security ：
- 运行应用服务的弹性云服务器（ECS）。
- 提供生产环境中的核心安全服务。
- RDS-wp-production（主） ：
- 关系型数据库服务的主节点。
- 存储主要的生产业务数据。
- 子网：subnet-web 和 subnet-db ：
- subnet-web：用于运行ECS实例。
- subnet-db：用于运行数据库服务。
可用区2
- ecs-access ：
- 运行辅助应用服务的弹性云服务器（ECS）。
- 用于负载均衡或其他业务扩展。
- RDS-wp-production（备） ：
- 关系型数据库服务的从节点（备份）。
- 与主节点同步数据，作为本地容灾的一部分。
- 存储容灾服务（SDRS） ：
- 实现可用区1和可用区2之间的同步，确保本地数据的高可用性。
4.2.2 上海（异地容灾站点）
可用区X
- ecs-wp-disaster ：
- 弹性云服务器（ECS），作为异地容灾站点的核心计算资源。
- 在生产站点发生灾难时接管服务。
- RDS-wp-disaster（备） ：
- 关系型数据库服务的异地备份节点。
- 通过数据库复制服务（DRS）与生产站点的主数据库同步。
- 子网：subnet-web-sh1 和 subnet-db-sh1 ：
- 用于容灾站点的网络划分，分别对应应用服务和数据库服务。
关键服务
- 云备份服务（CBR） ：
- 将生产站点的数据定期备份到异地容灾站点。
- 数据库复制服务（DRS） ：
- 实现生产站点和异地站点之间的数据库同步，确保异地站点有最新的数据。
- 虚拟专有网络（VPN） ：
- 用于实现两个站点之间的专线连接，保证数据传输的安全和稳定。
- 云解析服务（DNS） ：
- 在生产站点不可用时，将服务流量快速切换到异地站点。
4.2.3 关键特性解析
本地容灾（北京四）：
- 跨AZ设计：通过SDRS在可用区1和可用区2之间实现数据的实时同步，确保在一个可用区出现故障时，服务可以快速切换到另一个可用区。
- RDS主备架构：主节点与从节点之间进行数据同步，确保数据库的高可用性。
异地容灾（上海）：
- 跨Region设计：通过CBR和DRS实现生产站点与容灾站点的数据备份与同步。
- 灾难切换：在生产站点发生灾难（如自然灾害或大规模故障）时，异地容灾站点接管服务。
- 网络连接：通过VPN建立安全的专线连接，确保数据同步的稳定性。
高可用与容灾策略：
- 本地容灾：适用于局部硬件故障或可用区级别的灾难。
- 异地容灾：适用于区域性灾难（如大规模自然灾害、网络中断等）。
4.2.4 总结
- 北京四作为生产站点，承担主要服务运行，跨AZ实现本地容灾。
- 上海作为异地容灾站点，通过备份和复制服务同步数据，在生产站点出现问题时接管服务。
- 核心技术：SDRS实现本地容灾，CBR和DRS实现异地容灾，VPN和DNS保证站点间连接和流量切换。