你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure 专用 5G 核心的可靠性
本文介绍 Azure 专用 5G 核心中的可靠性支持。 它涵盖了可用性区域的区域复原能力以及跨区域灾难恢复和业务连续性。 有关 Azure 中可靠性的概述，请参阅 Azure 可靠性。
还可以在一对 Azure Stack Edge (ASE) 设备上将 Azure 专用 5G 核心部署为高可用性 (HA) 服务。 有关详细信息，请参阅完成部署专用移动网络的先决条件任务。
可用性区域支持
Azure 可用性区域是每个 Azure 地区内的至少三个在物理上独立的数据中心组。 每个区域中的数据中心都配备了独立的电源、冷却系统和网络基础结构。 在本地区域发生故障的情况下，设计可用性区域，以便一个区域受到影响时，其余两个区域支持区域服务、容量和高可用性。
故障范围包括软件和硬件故障，以及地震、洪水和火灾等事件。 容错是通过 Azure 服务的冗余和逻辑隔离来实现的。 有关 Azure 中可用性区域的详细信息，请参阅地区和可用性区域。
已启用 Azure 可用性区域的服务旨在提供适当级别的可靠性和灵活性。 可以通过两种方式进行相关配置。 可以采用区域冗余配置，实现跨区域自动复制，也可以采用区域性配置，将实例固定到特定区域。 还可以将这些方法结合。 有关区域与区域冗余体系结构的详细信息，请参阅有关使用可用性区域和地区的建议。
Azure 专用 5G 核心服务在支持可用性区域的 Azure 区域中自动部署为区域冗余，如可用性区域服务和区域支持中所列。 如果某个区域支持一些可用性区域，则可以从任何这些可用性区域中管理在区域中创建的所有 Azure 专用 5G 核心资源。
无需进一步操作即可配置或管理可用性区域。 可用性区域之间的故障转移是自动的。
先决条件
若要了解可使用 Azure 专用 5G 核心的 Azure 区域，请参阅各区域的产品可用性。
区域故障体验
在区域范围的中断场景中，用户应该不会受到任何影响，因为服务会自动移动以利用正常的区域。 在区域范围的中断开始时，你可能会看到正在进行的 ARM 请求超时或失败。 新请求将定向到正常的节点，不会对用户造成任何影响，并且应重试任何失败的操作。 在中断期间，你仍然能够创建新资源并更新、监视和管理现有资源。
安全部署技术
应用程序可确保在区域中的可用性区域之间复制所有云状态，使所有管理操作不间断地继续进行。 数据包核心在 Edge 上运行，不受区域故障影响，因此将继续为用户提供服务。
跨区域灾难恢复和业务连续性
灾难恢复 (DR) 是指从会导致故障时间和数据丢失的高影响事件（例如自然灾害或部署失败）中恢复。 不管灾难的原因是什么，最好的补救措施就是一个定义全面且经过测试的 DR 计划，以及一个主动支持 DR 的应用程序设计。 在开始考虑创建灾难恢复计划之前，请参阅设计灾难恢复策略的建议。
在 DR 方面，Microsoft 使用责任共担模型。 在共担责任模型中，Microsoft 会确保基线基础结构和平台服务可用。 同时，许多 Azure 服务不会自动复制数据，也不会从失败区域回退以交叉复制到另一个启用的区域。 对于这些服务，你负责设置适用于工作负载的灾难恢复计划。 大多数在 Azure 平台即服务 (PaaS) 产品/服务上运行的服务都提供支持 DR 的功能和指导，你可以使用特定于服务的功能来支持快速恢复，从而帮助制定 DR 计划。
Azure 专用 5G 核心仅在多区域 (3+N) 地理位置提供。 该服务自动将 SIM 凭据复制到同一地理位置的备份区域。 这意味着，在发生区域故障时不会丢失数据。 在发生故障的四小时内，故障区域中的所有资源都可以通过 Azure 门户和 ARM 工具进行查看，但在恢复故障区域之前，这些资源均为只读。 在 Edge 上运行的数据包核心继续运行而不会中断，且网络连接将保持。
Microsoft 负责 Azure 专用 5G 核心服务的 Azure 云方面的中断检测、通知和支持。
服务中断检测、通知和管理
Microsoft 监视在每个区域中提供 Azure 专用 5G 核心服务的基础资源。 如果这些资源开始显示不限于单个可用性区域的故障或运行状况监视警报，则 Microsoft 会将服务移动到同一地理位置中另一个受支持的区域。 这是一种主动-主动模式。 有关特定区域的服务运行状况，请参阅 Azure 服务运行状况（Azure 专用 5G 核心列在“网络”部分）。 你将通过正常的 Azure 信道收到任何区域故障的通知。
该服务使用 Cosmos DB 多区域写入自动将服务拥有的 SIM 凭据复制到备份区域，使得在发生区域故障时不会丢失数据。
在故障区域中部署的 Azure 专用 5G 核心资源将变为只读，但所有其他区域中的资源将继续运行，不受影响。 如果需要能够随时写入资源，请按照设置灾难恢复和中断检测中的说明执行自己的灾难恢复操作，并在另一个区域中设置服务。
在 Edge 上运行的数据包核心继续运行而不会中断，且网络连接将保持。
设置灾难恢复和中断检测
本部分介绍在发生区域故障时，可以采取何种操作来确保 Azure 专用 5G 核心服务具有完全主动的管理平面。 如果希望在发生区域故障时能够修改资源，则这是必需的。
请注意，这将导致数据包核心服务中断，并中断与 UE 的网络连接长达 8 小时，因此建议仅在 Azure 区域关闭时出于业务关键原因管理资源的情况下才使用此过程。
在发生灾难恢复事件之前，必须将资源配置备份到另一个支持 Azure 专用 5G 核心的区域。 发生区域故障时，可使用备份区域中的资源重新部署数据包核心。
准备工作
需要备份两种类型的 Azure 专用 5G 核心配置数据进行灾难恢复：移动网络配置和 SIM 凭据。 建议：
- 每次向主要区域添加新 SIM 时，更新备份区域中的 SIM 凭据
- 每周至少备份一次移动网络配置，如果频繁或大量更改配置（例如创建新站点），则可以更频繁地备份。
移动网络配置
按照将资源移动到其他区域中的说明导出 Azure 专用 5G 核心资源配置，并将其上传到新区域。 建议对备份配置使用新的资源组，将其与活动配置明确分开。 必须为这些资源指定新名称，将它们与主要区域中的资源区分开来。 此新区域是被动备份，因此为了避免冲突，尚不得将数据包核心配置链接到边缘硬件。 而请将每个数据包核心的 packetCoreControlPlanes.platform 字段中的值存储在一个可由执行恢复过程的任何人访问的安全位置（例如内部文档中引用的存储帐户）。
SIM 数据
出于安全原因，Azure 专用 5G 核心永远不会返回在创建 SIM 期间提供给服务的 SIM 凭据。 因此，无法以与其他 Azure 资源相同的方式导出 SIM 配置。 建议每当将新的 SIM 添加到主服务时，也会通过对备份移动网络重复预配新 SIM 过程，将相同的 SIM 添加到备份服务。
其他资源
Azure 专用 5G 核心部署可以利用 Azure Key Vault 来存储 SIM 加密密钥或 HTTPS 证书以进行本地监视。 必须遵循 Azure Key Vault 文档，确保密钥和证书在备份区域中可用。
恢复
如果发生区域故障，请首先通过 Azure 门户或 API 查询配置来验证备份区域中的所有资源均存在（请参阅将资源移到其他区域）。 如果所有的资源都不存在，请在此处停止，不要执行此过程的其余部分。 如果没有资源配置，则可能无法在边缘站点恢复服务。
每个数据包核心的恢复过程分为三个阶段：
- 通过执行重置，断开 Azure Stack Edge 设备与故障区域的连接
- 将 Azure Stack Edge 设备连接到备份区域
- 重新安装并验证安装。
必须对移动网络中的每个数据包核心重复此过程。
注意
恢复过程将导致数据包核心服务中断，并且每个数据包核心与 UE 的网络连接中断长达 8 小时。 建议仅在区域故障期间有通过 Azure 管理 Azure 专用 5G 核心部署的业务关键需求时执行此过程。
断开 Azure Stack Edge 设备与故障区域的连接
Azure Stack Edge 设备当前正在运行数据包核心软件，并从故障区域进行控制。 若要断开 Azure Stack Edge 设备与故障区域的连接并删除正在运行的数据包核心，必须按照重置并重新激活 Azure Stack Edge 设备中的重置和重新激活说明进行操作。 请注意，这将删除 Azure Stack Edge 设备上当前正在运行的所有软件，而不仅仅是数据包核心软件，因此请确保你能够在设备上重新安装任何其他软件。 这将为连接到此 Azure Stack Edge 设备上的数据包核心的所有设备启动网络中断。
将 Azure Stack Edge 设备连接到新区域
按照委托 AKS 群集中的说明在 Azure Stack Edge 设备上重新部署 Azure Kubernetes 服务群集。 确保对此新安装使用不同的名称，避免故障区域恢复时发生冲突。 在此过程中，你将获得群集的新自定义位置 ID，应记下该 ID。
重新安装和验证
获取在准备工作中存储的 packetCoreControlPlanes.platform 值的副本，并使用上面记下的自定义位置 ID 更新 packetCoreControlPlane.platform.customLocation 字段。 确保 packetCoreControlPlane.platform.azureStackEdgeDevice 与要安装数据包核心的 Azure Stack Edge 设备的 ID 匹配。 现在，按照修改数据包核心进行操作，使用平台值更新备份数据包核心。 这将在 Azure Stack Edge 设备上触发数据包核心部署。
应遵循验证新站点安装的正常过程，确认 UE 连接已还原且所有网络功能均正常运行。 具体而言，应确认 Azure 门户中的站点仪表板显示 UE 注册，并且数据正在流经数据平面。
已还原故障区域
故障区域恢复时，应按照准备工作中的步骤，执行从活动备份区域到恢复的主要区域的备份，确保两个区域中的配置同步。
还必须检查并删除恢复的区域中尚未通过上述步骤销毁的任何资源：
- 对于移动到备份区域的每个 Azure Stack Edge 设备（按照恢复中的步骤），必须查找并删除旧的 ARC 群集资源。 此资源的 ID 位于准备工作中备份的值的 packetCoreControlPlane.platform.customLocation 字段中。 此资源的状态将为“已断开连接”，因为相应的 Kubernetes 群集在恢复过程中已删除。
- 对于移动到备份区域的每个数据包核心（按照 恢复中的步骤），必须查找并删除恢复的区域中的任何 NFM 对象。 这些对象将与数据包核心控制平面资源列在同一资源组中，且“区域”值将与恢复的区域匹配。
然后，你有两种持续管理选择：
- 使用操作备份区域作为新的主要区域，并使用恢复的区域作为备份。 无需进一步执行操作。
- 按照将资源移动到不同的区域中的说明切换回恢复的区域，使恢复的区域成为新的活动主要区域。
测试
若要测试灾难恢复计划，可随时按照单个数据包核心的恢复过程进行操作。 请注意，这将导致数据包核心服务的服务中断，并中断与 UE 的网络连接长达 4 小时，因此建议仅在非生产数据包核心部署中执行此操作，或者在服务中断不会对业务造成负面影响时执行此操作。