本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # 运营可靠性 现代企业在维持 SAP 服务的持续可用性方面面临重大挑战，尤其是在区域中断或维护期间。在部署 SAP Business Technology Platform（SAP BTP）和 RISE with SAP 时，业务连续性和运营可靠性是需要重点关注的问题。 [Amazon Route 53](https://aws.amazon.com/route53/) 是一项高度可用、可扩展的全球分布式域名系统（DNS）Web 服务，能够高效应对这些挑战。它可让客户为其 SAP 环境实施 [AWS 多区域架构](https://docs.aws.amazon.com/prescriptive-guidance/latest/aws-multi-region-fundamentals/introduction.html)，从而提供强大的容错能力和更高的可靠性。通过利用 Route 53 的功能，企业可以构建具备韧性的 SAP 环境，以满足严苛的可用性要求。此 DNS 服务可与 SAP BTP 服务无缝集成，确保即使在区域中断期间，业务运营也能平稳进行。 **在 SAP 场景中理解 Amazon Route 53** Amazon Route 53 充当具备韧性的 SAP 环境的基础组件，能够提供智能 DNS 路由功能。在 SAP BTP 和 RISE with SAP 的场景中，Route 53 能够应对标准可用区（AZ）配置无法单独解决的关键可靠性挑战。虽然 SAP BTP 服务支持在单个区域内进行多AZs 部署，但这种方法仍然容易出现区域范围的故障。Route 53 通过支持跨多个地理区域的流量路由，进一步增强了韧性，从而高效地构建了面向任务关键型 SAP 应用的全球安全网。 Route 53 的架构旨在通过将控制面板功能与数据面板功能分离，最大限度地提升可靠性。数据面板经过专门设计，即便在发生控制面板故障或分区事件等情况时，也能保持[静态稳定性](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/)。这种架构分离确保 DNS 解析始终具备高可用性，使 Route 53 成为 SAP 环境中灾难恢复场景的理想基础组件。该服务会持续监控端点运行状况，一旦检测到故障，便自动将用户重定向至正常运行的资源。 除了基础失效转移功能外，Route 53 还提供可根据特定业务需求定制的高级路由策略。这些策略包括：基于延迟的路由（将用户定向到延迟最少的端点）、地理位置路由（用于满足数据主权法规要求），以及加权路由（按预设比例分配流量）。对于使用 SAP 服务的全球化企业而言，这些功能可为不同地理区域的用户提供一致的性能与可用性，在维护系统可靠性的同时，提升总体用户体验。 **用于实现 SAP BTP 多区域故障恢复能力的 Amazon Route 53 架构** 设计完善的多区域架构是通过 Amazon Route 53 构建高弹性 SAP BTP 环境的基础。此方法从地理冗余入手，将关键应用程序组件部署在不同的区域，以消除[单点故障](https://en.wikipedia.org/wiki/Single_point_of_failure)。在这个架构中，Route 53 充当智能流量指挥者，持续监控端点的运行状况，并依据可用性与性能指标制定实时路由决策。[与 SAP BTP 的自定义域服务集成](https://github.com/SAP-samples/btp-services-intelligent-routing/tree/launchpad_aws/04-Map%20Custom%20Domain%20Routes)后，即使在故障转移事件期间流量在区域之间重定向 URLs，Route 53 也能通过一致的方式提供无缝的用户体验。 您可以在 [SAP Architecture Center – Architecting Multi-Region Resiliency – Load Balancers](https://architecture.learning.sap.com/docs/ref-arch/81805673c0/3) 中找到更多信息。 **Amazon Route 53 路由选项** Route 53 为 SAP BTP 实施提供了多种[路由策略](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html)： + **简单路由**：将流量定向到单个资源 + **加权路由**：按指定比例在多个资源之间分配流量 + **基于延迟的路由**：将用户路由至网络延迟最少的区域 + **失效转移路由**：自动从运行状况不佳的主资源重定向至运行正常的辅助资源 + **地理位置路由**：根据用户的地理位置定向流量 + **地理位置临近度路由**：基于地理位置路由流量，支持可选的偏向性设置 + **多值应答路由**：随机选择最多 8 条健康记录作为响应 这些选项可组合使用，以创建符合特定 SAP 环境需求的复杂路由策略。 **适用于 SAP 环境的 Amazon Route 53 实施模式** SAP 环境拥有两大实施模式：主动-被动配置和主动-主动配置。 **模式 1. 主动-被动实施** 在主动-被动配置中，正常运行期间，Route 53 会将所有流量定向至主要 SAP BTP 区域，而辅助区域充当备用区域。此方法兼具简洁性与成本效益，同时仍能提供灾难恢复能力。对于 [SAP Build Work Zone](https://discovery-center.cloud.sap/serviceCatalog/sap-build-work-zone-standard-edition?region=all) 部署而言，主动-被动模式尤为适用，因为该部署中用户体验的一致性至关重要。 您可以通过在主区域种部署包含所有必要配置的 Work Zone 服务，然后使用 [SAP Cloud Transport Management 服务](https://www.sap.com/sea/products/technology-platform/cloud-transport-management.html)，将此设置复制到辅助区域。两个区域都使用 SAP BTP Custom Domain 服务配置了相同的域，而 Route 53 则配置了失效转移路由策略和用于监控主端点的运行状况检查。当主区域中出现问题时，Route 53 会自动将用户重定向到辅助区域，最大限度地减少中断。 TTL 优化直接影响失效转移速度和 DNS 查询量。较短的 TTL 值支持快速失效转移，但会增加 DNS 查询流量。具体的 TTL 值应与恢复点目标（RPO）要求保持一致。有关详细实施步骤，请参阅 [SAP blog post Route Multi-Region Traffic to SAP Build Work Zone using Amazon Route 53](https://community.sap.com/t5/technology-blog-posts-by-sap/route-multi-region-traffic-to-sap-build-work-zone-standard-edition-using/ba-p/13561468) 以及[此 github 存储库](https://github.com/SAP-samples/btp-services-intelligent-routing/tree/launchpad_aws)。 ![\[主动-被动实施\]](http://docs.aws.amazon.com/zh_cn/sap/latest/general/images/rise-jra-opsreliability-active-passive.png) **主动-主动实施** 主动-主动模式可同时在多个区域间分配流量，既能优化资源利用率，又能最大限度地减小区域故障影响。此方式非常适合用户遍布不同地理位置的全球化企业。在典型的 [SAP Cloud Application Programming (CAP)](https://pages.community.sap.com/topics/cloud-application-programming) 实施中，会在不同区域的多个 SAP BTP 子账户中部署相同的应用程序，这些应用程序连接至 [Amazon Aurora](https://aws.amazon.com/rds/aurora/)（一个跨多个区域的高性能全球数据库集群）。 通过配置 Aurora 进行 “ local/write 全局读取” 操作来维护数据一致性，将所有写入定向到主区域，同时允许从任何区域进行读取。Route 53 实施基于延迟的路由策略或地理位置路由策略，将用户定向至距离最近的正常运行区域。通过这一设置，不仅能实现对区域中断的故障恢复能力，还能通过降低全球分布的用户的延迟来提升性能。 有关实施详细信息，请参阅 [Distributed Resiliency of SAP CAP applications using Amazon Aurora with Amazon Route 53](https://community.sap.com/t5/-/-/m-p/13570134) 和 [SAP CAP Application Dynamic Data Source Routing](https://community.sap.com/t5/-/-/m-p/13558920)。您也可以参考此 [github 存储库](https://github.com/SAP-samples/cap-distributed-resiliency/tree/Data-Source-Routing/source)。 ![\[主动-主动实施\]](http://docs.aws.amazon.com/zh_cn/sap/latest/general/images/rise-jra-opsreliability-active-active.png) **解决方案指南和其他注意事项** 每种实施模式都需要仔细考虑数据一致性、身份验证机制和运营流程，以确保在正常运行和失效转移事件期间提供无缝的用户体验。 有关更广泛的架构指南，请参阅 [SAP BTP 高可用性多区域参考架构](https://community.sap.com/t5/-/-/m-p/13524196)和[使用 Amazon Route 53 创建灾难恢复机制 AWS](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)的指南。