你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

Azure 上的 Red Hat Enterprise Linux 的业务连续性和灾难恢复注意事项

本文介绍如何在 Azure 上改进 Red Hat Enterprise Linux(RHEL)环境的业务连续性和灾难恢复(BCDR)准备情况。 它提供了可用于支持 RHEL 工作负载和部署 RHEL 平台管理组件的建议。 Red Hat 管理订阅包含平台组件,可帮助管理一个或多个 RHEL 登陆区域中的工作负荷。 这些组件提供自己的 BCDR 配置。

设计注意事项

实现以下注意事项以提高 RHEL 工作负荷的复原能力。

恢复时间目标

恢复时间目标(RTO)是系统在发生灾难后恢复到其原始状态所需的时间。 RTO 包括以下时间:

  • 将最小功能还原到虚拟机(VM)和应用程序。
  • 还原应用程序所需的数据。

在业务方面,RTO 表示业务流程服务不足的时间量。 低 RTO 非常适合 任务关键型工作负荷 ,以便业务流程能够快速恢复。 对于低优先级工作负荷,较高的 RTO 可能对公司业绩产生明显影响。

恢复点目标

若要成功操作云环境,必须实现备份、复制或同时实现两者来保护数据免受故障的影响。 恢复点目标(RPO)是指上次捕获数据的时间。 当系统发生故障时,只能将其还原到最新的恢复点。

将 RPO 从最近的恢复点度量为发生中断的时间。 如果以小时为单位度量 RPO,则系统故障会导致最后一个恢复点与中断之间的小时数据丢失。 如果以天为单位度量 RPO,则系统故障会导致最后一个恢复点与中断之间的天数数据丢失。 从理论上讲,一天 RPO 会导致导致失败的一天中的所有交易丢失。

对于任务关键型系统,测量 RPO(以分钟或秒为单位)以帮助避免收入或利润损失。 短 RPO 通常会导致管理成本增加。 为了帮助降低这些成本,应创建一个专注于最长可接受的 RPO 的管理基线。 然后,可以减少需要更多投资的特定平台或工作负载的 RPO。

工作负荷 BCDR 注意事项

基于 RHEL 的工作负荷的高可用性和灾难恢复设计注意事项取决于支持这些工作负荷的技术。 许多新式工作负荷可以利用本机 Azure 服务来跨可用性区域和跨区域提供冗余。 使用 Azure 服务管理数据复制、自动缩放可用性集以及控制更新和容错域。 通过这些做法,可以更轻松地确保 RHEL 部署的可用性。

数据库解决方案和其他有状态应用程序可能需要以操作系统为中心的解决方案来提供高可用性和灾难恢复。 请咨询应用程序开发人员或供应商,验证应用程序支持的解决方案。 有关详细信息,请参阅 IaaS 应用的高可用性和灾难恢复

Azure 功能或服务 定义 注意事项
区域 一组彼此靠近的数据中心,以提供低网络延迟。 为了确保快速数据传输,特定的区域网络连接数据中心。 选择 Azure 区域时,请考虑数据中心、用户和后端数据的位置。 检查所选区域中所需的服务的可用性。 对于 RHEL 部署,可能需要启动一个区域,然后可以在未来为 BCDR 添加更多区域。
Azure ExpressRoute 一种 Azure 服务,可用于建立从Microsoft数据中心到你自己的基础结构或归置设施的专用连接。 ExpressRoute 绕过公共 Internet 并提供专用连接。 此配置是大规模 RHEL 部署的常见要求。 ExpressRoute 是一项共享服务,因此需要仔细规划带宽容量以满足企业的总体带宽需求。

如果带宽不足,可能会损害用户体验或对数据中心中关键服务的访问权限。 确保跨区域和对等互连位置以弹性方式部署 ExpressRoute。
可用性区域 单独的数据中心组,这些数据中心在 Azure 区域中具有自己的电源、冷却和网络系统。 可用性区域为数据中心故障提供高可用性和复原能力。 若要确保 达成高级别协议(SLA),请尽可能将可用性区域与 RHEL 基础结构配合使用。 可用性区域在区域中提供数据中心冗余。 但并非每个区域都有可用性区域,因此需要仔细规划。 RHEL 服务(如 Azure Red Hat OpenShift 和登陆区域管理服务)支持可用性区域。
可用性集 VM 的逻辑分组。 至少有一个 VM 在计划内或计划外维护事件期间始终启动并运行。 容错域是共享公共物理基础结构(如电源或网络)的可用性集的子集。 跨不同的容错域分配 VM 时,可用性集可减少硬件故障对 VM 可用性的影响。 可用性集提供 高 SLA。 当区域缺少可用性区域时,可用性集适用于 RHEL 基础结构。 可用性集只有硬件冗余,这类似于虚拟机监控程序反关联规则。 因此,如果区域没有可用性区域,则需要一个多区域策略来实现数据中心和地理冗余。
Azure 负载均衡器 网络负载均衡服务。 可以将负载均衡器配置为跨多个 Red Hat Enterprise 服务器高效提供大容量网络流量。 该服务以低延迟和高吞吐量运行,从而提高应用程序的性能和可用性。

负载均衡器可以根据需求自动缩放。 为了促进应用程序的混合部署,负载均衡器可以在 Azure 中的多个区域以及本地环境和 Azure 之间分配网络流量。
负载均衡器跨多个服务器分配网络流量,以提供不间断的应用程序可用性并防止单点故障。 如果发生灾难,负载均衡器将流量重定向到操作服务器,以提供快速故障转移和恢复。 此操作可最大程度地减少停机时间并维护业务运营。

负载均衡器可以平衡跨本地服务器到 Azure 云或多个 Azure 区域中的服务器之间的流量。 有关详细信息,请参阅 负载均衡选项
托管磁盘 Azure 管理的虚拟化磁盘。 选择磁盘大小和类型。 Azure 跨各种存储单元分配磁盘,以保护数据免受硬件故障的影响。 托管磁盘是所有 RHEL 基础结构的最佳选择。 不要使用非托管磁盘。 有关详细信息,请参阅 VM 的 SLA。

不同类型的磁盘具有不同的性能和成本。 对于 RHEL 基础结构计算机,建议使用 Azure 高级 SSD。 选择磁盘类型时,请考虑成本、性能和可用性。 解除分配系统时,将删除本地 SSD 和临时磁盘。 根据需要备份这些磁盘上的数据。
Azure 备份 提供经济高效的解决方案的服务,用于备份数据并从 Azure 云中恢复数据。 备份是一种可靠且经济高效的解决方案,可保护 RHEL 基础结构免受 VM 故障或损坏的影响。 使用备份从云中轻松还原整个 VM 或特定文件和文件夹,而无需重新创建 VM 或丢失任何数据。 还可以使用其他受支持的合作伙伴解决方案。
Azure Arc 一个扩展 Azure 服务的平台,以便它们跨各种环境(包括数据中心、边缘设备和多云体系结构)运行。 使用 Azure Arc 为应用程序和服务提供一致的开发、操作和安全管理。 使用 Azure Arc 实现集中式自动备份和监视,从而从 BCDR 的角度提高复原能力。
Azure Site Recovery 提供灾难恢复功能以确保业务连续性的服务。 可以跨不同区域复制和管理工作负荷,包括 Azure VM 和本地 VM。 使用 Site Recovery,可以设置复制、故障转移和恢复过程,以保护应用程序在计划内中断和计划外中断期间。 使用 Site Recovery 将恢复问题降到最低,降低基础结构成本,并确保 Azure 区域或从本地位置到 Azure 之间的安全且可靠的恢复。
资源锁 可用于限制组织中的用户和角色的 Azure 功能。 防止关键资源意外或恶意更改。 可以在各种级别的范围内锁定资源,例如订阅、资源组或单个资源级别。 根据锁的类型,可以阻止用户删除或修改资源,但仍可以读取其配置。 若要保护所有 RHEL 基础结构和黄金映像 VM,请使用资源锁。 若要防止意外丢失重要计算机,请至少应用 Delete 锁。 将 ReadOnly 锁应用于 RHEL 基础结构计算机,因为它们不会经常更改。 仅在适当的更改控制窗口期间进行更改。

RHEL 平台 BCDR 注意事项

有关 RHEL 平台基础结构的 BCDR 功能的详细信息,请参阅:

设计建议

对于 Linux 容器中的云原生应用程序,请使用基于 Kubernetes 的平台来确保可伸缩性、高可用性和冗余性。 请考虑使用 Azure Red Hat OpenShift 平台或具有复制或异地复制存储的自托管 OpenShift 部署。

对于本机 Web 应用程序前端和无状态应用程序,可以使用许多提供应用程序可用性的 Azure 本机服务。 有关使用此类服务的体系结构,请参阅:

上述体系结构对可用性区域使用各种 Azure 服务。 多区域体系结构将内容和 Azure Front Door 的异地复制功能用作负载均衡服务。

对于许多需要高可用性的传统有状态应用程序,RHEL 提供 Pacemaker 高可用性加载项。 可以从Azure 市场获取具有此功能的系统,也可以使用嵌入所需的软件组件部署自定义映像。 有关详细信息,请参阅 在 Microsoft Azure 上配置 Red Hat 高可用性群集。

可用性问题会影响服务中断和服务响应时间。 可能会发生服务降级,这可能会降低客户的服务体验。 为了确保在所需区域中保持性能级别和足够的容量,请使用 Azure 按需容量预留 功能。

可靠性

许多适用于基础结构即服务 VM 基础结构的概念也适用于 RHEL 体系结构。 有关详细信息,请参阅 可靠性设计原则

群集

Azure 不支持在单个 RHEL Pacemaker 群集中合并 Application Server Central Services 和数据库高可用性。 若要解决此限制,请将它们分成单独的群集。 最多可以在一对 VM 中组合五 个中心服务群集

对于 SAP 上的 BCDR,请考虑以下服务来运行 SAP 中心服务群集:

  • RHEL Pacemaker 群集:不支持 STONITH 块设备,但可以依赖于 Azure 隔离代理。
  • SAP 认证的非Microsoft群集软件:如果此选项符合你的要求,请浏览此选项。

根据特定需求和操作系统选择适当的服务。

有关详细信息,请参阅:

可以使用计算库存储用于部署的黄金映像。 使用这些映像进行应用程序和工具的灾难恢复。 计算库可以在支持可用性区域的区域中将高度可用的 资源与区域冗余存储(ZRS)帐户 配合使用。 ZRS 提供针对区域性故障的复原能力。 还可以将库映像复制到其他区域或地理位置。

注意

建议在不同的区域中至少有两个库。

Site Recovery

Site Recovery 可以增强某些 RHEL 组件的复原能力。 有关支持的 RHEL 站点恢复服务器的列表,请参阅 使用 Site Recovery 进行 Azure VM 灾难恢复的支持矩阵。 还可以将 Site Recovery 设置为 从本地环境故障转移到云。 若要估算 Site Recovery 成本,请使用 Site Recovery 部署规划器

恢复群集节点

若要减少 RTO 并提高复原能力,可以使用主动或备用远程 恢复群集 节点。 必须手动配置灾难恢复群集项。 例如,必须应用配置来设置资源和复制数据。

后续步骤