SAP on AWS Multi-AZ (HA) working with Oracle Data Guard

众多企业客户在SAP ERP系统规划阶段选择Oracle作为ERP后端数据库。随着企业本地数据中心硬件设备全生命即将结束或客户计划以云平台作为其下一步IT投资方向，客户希望将保持现有运行环境作为前提将现有SAP系统迁移入云。本文以云上合规作为前置条件说明AWS平台上基于Oracle原生功能的跨可用区高可用实现。

SAP 使用Oracle Database云上合规性说明

用户正在使用云平台上所提供的基础架构服务进行SAP应用的部署前，需要了解SAP运行在云平台上的一些合规性要求从而获得SAP以及Oracle的全面技术支持。下面从以下几点说明获得SAP的技术支持的限制条件。

操作系统要求：依据SAP Note 2358420 – Oracle Database Support for Amazon Web Services EC2 ，Oracle Database 11g R2（2.0.4），12c R1（12.1.0.2），12c R2（12.2.0.1），18c（最低18.5.0）或19c（最低19.5.0）需在Oracle Enterprise Linux（OEL）6.4或更高版本上运行。
SAP产品可用矩阵要求：依据SAP Product Availability Matrix (PAM)，确定数据库、SAP Kernel、操作系统版本满足当前SAP系统版本运行的要求。
Oracle运行环境要求：目前Oracle 已授权在AWS Amazon Elastic Compute Cloud（EC2）和Amazon Relational Database Service（RDS）中运行Oracle软件产品[1]。Amazon RDS Aurora Database（MySQL）现已获得SAP Hybris Commerce认证[2]。截止目前为止Oracle Cloud是唯一经过认证并支持运行Oracle Real Application Clusters（RAC）[3]。
SAP对于Oracle功能的支持说明：依据SAP Note 105047 – Support for Oracle functions in the SAP environment，客户在启用Oracle的一些额外功能时（例如：Oracle Data Guard）需确定SAP对于这些功能的支持。

Oracle Data Guard HA Multiple AZ技术实现

一般谈高可用时很容易联想通过商业套件产品例如SIOS Protection Suite、Veritas InfoScale提供的解决方案实现Oracle核心服务跨可用区的自动故障切换转移。但正如之前文章中所讲述的HA解决方案落地应从合规性要求、RTO/RPO、成本、故障场景的广度、架构复杂程度等多维护进行衡量（详见Blog：SAP on AWS 架构部署）。

例如客户SAP ERP系统使用Oracle Database作为数据库，客户要求数据库需采用跨AZ部署且对于RTO/RPO拥有较高要求，同时客户对于成本限制比较严格。在这种情况下可能采用商业套件并不能达到客户对于成本的限制要求，需要考虑如何使用Oracle原生功能实现Oracle跨可用区高可用的架构设计和部署。Oracle Data Guard 是 Oracle Database Enterprise Edition 的一项功能，利用该功能所提供的工具可进行管理一个或多个 Oracle 备用数据库从而实现高可用性和灾难恢复。任何主数据库的更改都可以复制到备用数据库，从而确保两个数据库内容的同步。客户可在相同的AWS区域中不同可用区中的两个Oracle虚拟机之间建立 Oracle主数据库和备用数据库关系，通过AWS可用区之间高速网络链路以实现数据的复制。根据SAP合规性要求，SAP对于Oracle Data Guard支持以下使用场景。[3]

允许使用“Physical Standby”，不允许使用“Logical Standby”。
允许使用快速启动故障转移 (FSFO)，但不提供 SAP 支持。
允许使用Data Guard Broker。
允许使用“Maximum Performance Mode”、“Maximum Availability Mode”和“Maximum Protection Mode”。

方案概述

通过Oracle Data Guard可实现如下高可用架构:

Oracle数据库部署逻辑架构图

1.SAP应用服务器端配置/sapmnt/<SID>/profile/oracle路径下的ora、sqlnet.ora。

- 配置ora ADDRESS_LIST，将Oracle 主从节点加入到列表清单中。
- 通过ora设置LOAD_BALANCE = yes参数实现应用节点随机轮询访问ADDRESS_LIST中配置的实例。
- 通过ora设置SQLNET.OUTBOUND_CONNECT_TIMEOUT参数。客户端可以在发生故障时快速循环遍历ADDRESS_LIST直到建立连接为止。

2.通过AWS AMI方式配合Oracle数据库备份命令创建数据库Standby初始运行环境减少传统RMAN方式备份恢复所需的时间和工作量。通过AWS Instance Snapshot功能无需在卷级别上通过dmsetup suspend来实现数据和日志卷的I/O冻结，从而保障系统数据一致性。并根据Oracle Data Guard文档要求配置Oracle数据库主从节点的参数以及配置数据同步方式。 [4]

AWS Instance Snapshot配置

Oracle Primary Database 参数配置

Oracle Standby Database 参数配置

Oracle 监听配置

3.配置Data Guard Broker以实现轻松进行切换/故障转移。

- 将Oracle 主从节点加到Broker中并激活此配置。
- 开启主从数据库的flashback功能。设定flashback区域大小和保留时间。
- 启动Oracle Data Guard Fast-Start Failover（FSFO），实现快速启动故障转移。并根据实际场景以及系统优先级的要求配置故障转移阈值，通过设置合理的配置避免由于短暂的网络中断而进行系统切换。
- 创建Observer观察者，可安装Oracle Client“管理员类型”后创建配置管理者，使该客户端具有到主数据库和备用数据库的永久网络连接，也可使用已有的Oracle主目录。作为观察者通过在Oracle DGMGRL上发起START OBSERVER命令，一旦启动观察者将将立即开始检测主备用数据库的连接状态。
- 为了避免明文的用户密码出现可使用Oracle Walet Manager进行配置。

observer启动脚本配置

Data Guard Broker最终效果

4.通过Amazon CloudWatch Logs 监控 Observer 所在EC2节点所产生的Log信息，设定特定字段筛选日志信息并创建触发规则。当Oracle Primary Instance无法访问时可在第一时间内通知到系统管理人员，为了避免出现“脑裂”的情况，当切换成功后主库所在EC2主机将由Lambda函数自动关闭。[5]可通过使用AWS Auto-reboot和Auto-recovery配合自启动脚本进一步提升Observer节点的高可用。[6]

CloudWatch 告警配置

Oracle Data Guard主节点自动关机脚本实现

import boto3
region = 'ap-northeast-1'
instances = ['Primary Database EC2 Instance ID']
ec2 = boto3.client('ec2', region_name=region)

def lambda_handler(event, context):
    ec2.stop_instances(InstanceIds=instances)
    print('stopped your instances: ' + str(instances))

Oracle Data Guard主节点异常触发效果