SAP 自适应方案的架构变种

发布于: Jul 29, 2022

借助自适应方案的编排能力，可以衍生出一些变种方案，以进一步提升自适应方案带来的价值,以下架构变种均保留了与自适应方案同样的低延迟访问特性

借助自适应方案的编排能力，我们甚至可以衍生出一些变种方案，以进一步提升自适应方案带来的价值

注：以下架构变种均保留了与自适应方案同样的低延迟访问特性

架构变种之一：弹性的传统数据库复制

在亚马逊云科技专业咨询服务团队的实际实施案例中，我们的 SAP 客户所使用的 SAP 系统不一定跑在 SAP HANA 数据库上，但这不妨碍我们帮助那些运行在传统数据库的客户获得 SAP 系统的自适应能力。

同时对于传统数据库来说，其存储资源往往在资源总成本构成中是最大的，运行于 Oracle 数据库之上的 SAP 系统，为满足动辄 TB 级别的数据文件与性能要求，必须配置大容量的高性能磁盘；而在一个主备双机环境中，其成本将翻倍；但作为备节点的数据库往往只承载数据写入的请求，因此备节点的 I/O 需求与主节点存在天壤之别（尤其是 OLTP 类型的系统）；此时，如果我们利用 Amazon EBS 带来的磁盘类型弹性调整特性，在平时保持备节点的数据卷使用较低性能且满足写入需求的低成本磁盘，而只在切换时利用自适应流程对磁盘类型提升至高性能的 gp3 或者 io1/io2，将为客户带来显著的成本降低。

主备库之间的复制技术可以选择数据库原生复制方案或者类似 DRBD 的块复制方案，并由集群管理，同时由于备库日志卷的写入要求可能较高，完全可以将体量较小的日志卷独立出来并配置高性能磁盘来满足分流复制的 I/O 写入压力。在此方案下，对于 10TB 的数据卷使用 st1 作为磁盘类型，每套 SAP 生产系统的日常的磁盘费用可以降低近 25%。

这个架构变种的缺点是备库在拉起之后需要一段时间（通常为数小时）才能使得 I/O 性能恢复到最佳状态，考虑到 I/O 子系统的满负荷运行并不是常态，客户可以根据实际需求选择是否采用这个架构变种。

架构变种之二：重用 SAP HANA 备节点

在一套以 SAP HANA 作为数据库的 SAP 系统中，资源利用率最低的部分是其 SAP HANA 的备节点，为了切换过程本身的顺利完成以及切换之后 SAP HANA 能够正常运行，客户需要配置一台与 SAP HANA 主节点同等大小的 EC2 实例。对此 SAP 与亚马逊云科技提供了一个降低费用的选项 Automatic Recovery & HSR without Data Preload (Warm Standby + Dev/QA)；在关闭备节点的列存储 preload 参数后，可以将该 SAP 系统的 DEV/QAS SAP HANA 数据库运行于备节点上以最大化提升资源利用率；但在传统做法中，其最大的缺点是客户需要自己确保 SAP HANA 在切换前，这些 DEV/QAS 的 SAP HANA 实例被关闭，从而避免切换过程的失败，这直接引入了不可控的人为介入并造成了 RTO 时间的极大延长。如果依托于自适应方案，这个过程完全可以被自适应流程自动化，并且停止 DEV/QAS SAP HANA 库的操作完全能与 PRD SAP HANA 备节点的接管过程并行触发，从而在获得成本节省的同时不必为 RTO 的延长妥协。