了解 Code Engine 的高可用性和灾难恢复
高可用性服务或工作负载根据预先定义的服务级别承受故障并继续提供处理能力的能力。 （HA）是指服务在出现意外故障时仍能保持运行和访问的能力。 灾难恢复服务或工作负载从罕见重大事故和大规模故障（如服务中断）中恢复的能力。 这包括影响整个地区的自然灾害、数据库损坏或导致工作负荷增加的服务中断。 这种影响超出了高可用性设计所能承受的范围。是指在发生重大故障后恢复服务运行的过程。
Code Engine Code Engine 符合标准计划的 服务水平目标(SLO)。
有关 IBM Cloud 中高可用性和灾难恢复标准的更多信息，请参阅 《 IBM Cloud 如何确保高可用性和冗余 》。 您还可以找到有关服务级别协议的信息。
Code Engine 实例的可用性
IBM Cloud® Code Engine 在多个地点（地区）提供。 每个区域包含三个数据中心（区），以实现冗余。
供应 Code Engine 项目时，请选择创建实例的位置 (MZR)。 区域决定了工作负载（如应用程序、作业、功能和机群）的托管位置。
默认情况下，您的工作负载部署在单个区域内。 如果托管区域发生故障，工作负载会自动在其余区域中重新创建。
在服务维护和软件升级等正常运行期间，该服务可在区域间执行受控的工作负载移动。 这些推出重启都是优雅地执行的，以尽量减少中断。 在运行环境中发生意外事件时，可能会出现计划外故障切换。
Code Engine 存储元数据（包括项目、应用程序、功能、任务、机群和映像构建定义），并将其复制到区域内的所有区域，以确保可用性。 作为纯计算服务，Code Engine 不负责确保工作负载数据或容器映像的高可用性。 有关确保高可用性的指导，请查阅相应云服务的文档。 对于容器映像可用性，请遵循 IBM Cloud Container Registry 中的指导，以确保工作负载在分区中断期间保持运行。 如果您在 IBM Cloud Object Storage 或任何其他 IBM Cloud 数据库或存储服务中读取或存储数据，请参阅各服务的文档了解高可用性功能。
Code Engine 区域
下表列出了 Code Engine 可用的区域及其高可用性状态。
| 地域 | 区域 | 高可用性 |
|---|---|---|
| 亚太地区 | 澳大利亚，悉尼（au-syd ） |
MZR |
| 亚太地区 | 印度，金奈（in-che ） |
MZR |
| 亚太地区 | 日本，大阪（jp-osa ） |
MZR |
| 亚太地区 | 日本，东京（jp-tok ） |
MZR |
| 欧洲 | 德国，法兰克福（eu-de ） |
MZR |
| 欧洲 | 西班牙，马德里（eu-es ） |
MZR |
| 欧洲 | 英国，伦敦（eu-gb ） |
MZR |
| 北美洲 | 加拿大，多伦多（ca-tor ） |
MZR |
| 北美洲 | 美国，达拉斯（us-south ） |
MZR |
| 北美洲 | 美国，华盛顿（us-east ） |
MZR |
| 南美洲 | 巴西，圣保罗（br-sao ） |
MZR |
地理区是指包含一个或多个地区的地理区域。 每个区域都包含 多个可用区， 以满足本地访问、低延迟和安全方面的要求。 每个 多区区域(MZR) 由 3 个或更多独立区域组成，确保单一故障事件只影响一个区域。
Code Engine 实例的灾难恢复
在重大地区性灾害中，如地震、洪水或恶劣天气事件，整个地区都可能受到影响。 为确保您的工作负载能够应对此类事件，可将它们部署到多个 MZR 上，并使用边缘代理服务实施自动故障切换机制。 例如，您可以使用 IBM Cloud® Internet Services. 有关在多个区域中部署应用程序的更多信息，请参阅 使用定制域名在多个区域中部署应用程序。
IBM 如何帮助确保灾难恢复
备份 Code Engine 实例
IBM Cloud 自动备份 Code Engine 项目元数据，并将其存储在跨区域存储器中，以备灾难恢复之用。
| Code Engine 区域 | 跨区域端点 |
|---|---|
au-syd |
AP |
br-sao |
BR |
ca-tor |
CA |
eu-de |
EU |
eu-es |
EU |
eu-gb |
EU |
jp-osa |
AP |
jp-tok |
AP |
us-east |
US |
us-south |
US |
为避免对工作负载造成意外影响（如重复作业或部署不需要的应用程序实例），Code Engine 不会自动恢复工作负载。 恢复工作量是你们的责任。 有关更多信息，请参阅 了解使用 Code Engine时的责任。
恢复时间目标（RTO）和恢复点目标（RPO）
-
恢复时间目标 （RTO）是系统、应用程序或业务流程在造成重大业务影响之前可接受的最长离线时间。
-
恢复点目标 (RPO) 定义了 HA 或 DR 事件后可接受的最大数据丢失量（以时间衡量）。
IBM 定期进行 HA/DR 测试，包括 HA 故障切换、隔离 DR 情景（不包括客户自有数据和工作负载定义）、数据恢复和非技术参数模拟。
在这些测试中，对 RTO（恢复时间）和 RPO（恢复点）目标进行了测量和验证。
| 目标 | 目标 |
|---|---|
| 分区中断期间自动故障切换 | RTO = 秒，RPO = 0 |
| 灾难恢复，不包括恢复客户拥有的人工制品 | RTO = 小时，RPO = 1 天 |
规划灾难恢复
除了 IBM 的 HA/DR 测试外，您还必须定期练习灾难恢复程序。 在制定计划时，请考虑以下失败情况和解决办法。
| 事件 | 解决方法 |
|---|---|
| 硬件故障（计算基础设施） | IBM 提供可抵御区域内单点硬件故障的基础设施，无需配置。 |
| 区域故障 | 自动故障切换（请参阅 Code Engine 实例的可用性 ）。 工作负载会自动转移到可用区域。 |
| 数据损坏 | 您有责任创建数据备份。 |
| 地区性失败 | 无自动故障切换。 如 Code Engine 实例的灾难恢复 中所述，应将工作负载部署到第二个多区区域。 |
| 工作量可用性 | 您负责实施业务应用程序，以便从外部存储或数据库中恢复状态。 |
| HA/DR 恢复能力 | 您有责任确保有训练有素的员工来管理您的组件，并在故障期间恢复您的工作负载和客户拥有的数据。 |
您对 HA 和 DR 的责任
使用以下与每个功能相关的核对表来帮助您创建和实践您的计划。
-
用于 IBM Cloud® Code Engine 应用程序、工作和车队的容器映像
验证您的 IBM Cloud Container Registry 备份区域中是否有容器映像。
-
用于 IBM Cloud® Code Engine 功能的代码包
验证您的代码捆绑包是否可在 IBM Cloud Container Registry 备份区域中使用。
全面的高可用性（HA）和灾难恢复（DR）测试计划包括定义 RTO 和 RPO 目标、确定关键系统、验证备份完整性、网络故障切换和数据同步。 关键步骤包括模拟故障（如节点故障或站点中断）、执行故障切换程序、验证系统功能以及记录回退过程。
-
测试准备
- 确定目标：确认恢复时间目标（RTO）和恢复点目标（RPO）。
- 确定关键系统：列出需要进行故障切换的所有系统、数据和应用程序。
- 确定团队角色：确定灾难恢复团队的职责，并指定一名关键联系人。
- 备份验证：确认备份有效且可访问。
- 环境隔离：隔离测试系统，防止对生产环境造成意外影响。
-
测试执行
- 模拟故障场景：启动计划中的故障，如切断网络连接、停止服务或关闭主服务器。
- 执行故障切换：执行记录在案的故障切换程序到辅助/灾难恢复站点。
- 验证数据完整性：使用校验和或哈希值确保数据不被破坏。
- 应用程序验证：测试灾难恢复站点上应用程序的功能。
- DNS/Traffic 重定向：验证用户流量是否重定向到新的活动节点。
-
事后测试和记录
- 执行故障恢复：优雅地将主站点重新联机并重新同步数据。
- 记录结果：记录时间、成功之处以及与计划的任何偏差。
- 找出差距：找出计划中的不足，并相应地更新程序。
- 通信审计：核实是否向所有利益相关者发送了通知。
-
常见测试场景
- HA 测试：本地故障切换到备用节点（例如，在同一数据中心内）。
- 灾难恢复测试：完全故障切换到地理位置独立的地点。
- 数据恢复：将客户拥有的数据和工作负载工件从备份数据存储完全恢复到主备份位置或选定的备份位置。
- 人员可用性：测试关键人员无法使用或无法连接系统时对运行的影响。