本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
在 IBM Db2 SAP 上设置灾难恢复 AWS
由 Ambarish Satarkar (AWS) 和 Debasis Sahoo () 创作 AWS
环境：生产 | 技术：数据库；操作 | 工作量：SAP |
AWS服务：AmazonEC2；AWSElastic 灾难恢复 |
Summary
此模式概述了为以 IBM Db2 作为数据库平台、在 Amazon Web Services () 云上运行SAP的工作负载设置灾难恢复 (DRAWS) 系统的步骤。目标是提供一种低成本解决方案，以在发生中断时提供业务连续性。
该图案使用指示灯方法。通过开启指示灯灾难恢复AWS，您可以减少停机时间并保持业务连续性。试点方法侧重于在中设置与生产环境同步的最小灾难恢复环境AWS，包括SAP系统和备用 Db2 数据库。
该解决方案具有可扩展性。您可以根据需要将其扩展至全面的灾难恢复环境。
先决条件和限制
先决条件
产品版本
架构
目标技术堆栈
目标架构
该架构为以 Db2 作为数据库平台SAP的工作负载实现了灾难恢复解决方案。生产数据库部署在AWS区域 1 中，备用数据库部署在第二个区域。备用数据库称为灾难恢复系统。Db2 数据库支持多个备用数据库（最多三个）。它使用 Db2 HADR 来设置 DR 数据库并自动在生产数据库和备用数据库之间传送日志。
如果发生灾难导致区域 1 不可用，DR 区域中的备用数据库将接管生产数据库角色。SAP应用程序服务器可以提前构建，也可以使用 AWSElastic 灾难恢复或 Amazon 系统映像 (AMI) 来满足恢复时间目标 (RTO) 的要求。此模式使用AMI.
Db2 HADR 实现了生产-备用设置，其中生产服务器充当主服务器，所有用户都连接到它。所有事务都写入日志文件，然后使用 TCP /IP 将这些文件传输到备用服务器。备用服务器通过前滚传输的日志记录来更新其本地数据库，这有助于确保其与生产服务器保持同步。
VPC使用对等连接是为了使生产区域和灾难恢复区域中的实例可以相互通信。Amazon Route 53 将最终用户路由至互联网应用程序。
在区域 1 中@@ 创建应用程序服务器，然后将其复制AMI到区域 2。AMI发生灾难时AMI，使用启动区域 2 中的服务器。
在生产数据库（区域 1 中）和备用数据库（区域 2 中）之间设置 Db2 HADR 复制。
发生灾难时，更改EC2实例类型以匹配生产实例。
在区域 1 中，将 LOGARCHMETH1 设置为 db2remote: S3 path。
在区域 2 中，将 LOGARCHMETH1 设置为 db2remote: S3 path。
跨区域复制在S3存储桶之间执行。
AWS服务
最佳实践
操作说明
| 任务 | 描述 | 所需技能 |
|---|
检查系统和日志。 | 确认 Db2 系统SAP上的生产已设置完毕。 确认日志备份已打开，并配置为将日志保存在 S3 存储桶中。这可通过 Db2 参数 LOGARCHMETH1 进行检查。 创建AMI其他应用程序服务器中的一个。
| AWS管理员、Basi SAP s 管理员 |
| 任务 | 描述 | 所需技能 |
|---|
创建SAP和数据库服务器。 | 要为灾难恢复区域部署基础架构，请使用AWS CloudFormation 脚本或生产实例。AMI作为指示灯方法的一部分，您可以使用与生产EC2实例同一个系列中的较小实例。例如，如果您的生产实例类型为 r6i.12xlarge，则可以将 r6i.xlarge 实例类型用于灾难恢复构建。但是，请确保灾难恢复实例上分配相同的存储容量，以恢复生产数据库备份。 为其创建 Amazon Elastic File S /sapmnt/<SID>/ ystem (AmazonEFS) 挂载点，并确保将其设置为从主系统复制。 从生产系统进行FULL数据库备份（联机或离线）。您将使用此备份构建灾难恢复数据库。 在灾难恢复系统中，使用SAP软件配置管理器 (SWPM) 系统复制方法以及将系统副本与高可用/灾难恢复结合的备份/恢复来构建灾难恢复系统。SAP 当被要求时SWPM，使用从生产环境中获取的备份在 DR 中恢复数据库。DR 数据库将处于前滚挂起状态。
恢复完整备份后，默认设置前滚挂起状态。前滚挂起状态指示数据库正在恢复，并且可能需要应用一些更改。有关更多信息，请参阅IBM文档。 | SAP基础管理员 |
检查配置。 | 要为设置日志存档HADR，生产数据库和灾难恢复数据库都必须能够自动从所有日志存档位置检索日志。验证灾难恢复数据库中的 LOGARCHMETH1 参数是否设置为与生产数据库中的参数相同的位置。如果因区域限制而无法访问同一位置，请确保灾难恢复系统可以自动从主系统获取日志。 要启用 TCP /IP 端口以启用数据库复制，请通过添加以下两个条目/etc/services在生产和灾难恢复主机中进行修改。在代码中，<SID>引用 Db2 数据库的系统 ID (SID)（例如PR1）。 <SID>_HADR_1 55001/tcp # DB2 HADR Port1
<SID>_HADR_2 55002/tcp # DB2 HADR Port2
确认两个端口都允许主端口和备用端口间的入站和出站流量。 检查 /etc/hosts 生产主机和灾难恢复主机，确认生产主机和备用主机的主机名都指向正确的 IP 地址。
| AWS管理员、Basi SAP s 管理员 |
设置从生产数据库到灾难恢复数据库的复制（使用ASYNC模式）。 | 在生产数据库中，执行以下命令更新参数。 db2 UPDATE DB CFG FOR <SID> USING HADR_LOCAL_HOST HOST1
db2 UPDATE DB CFG FOR <SID> USING HADR_LOCAL_SVC <SID>_HADR_1
db2 UPDATE DB CFG FOR <SID> USING HADR_REMOTE_HOST HOST2
db2 UPDATE DB CFG FOR <SID> USING HADR_REMOTE_SVC <SID>_HADR_2
db2 UPDATE DB CFG FOR <SID> USING HADR_REMOTE_INST db2<sid>
db2 UPDATE DB CFG FOR <SID> USING HADR_TIMEOUT 120
db2 UPDATE DB CFG FOR <SID> USING HADR_SYNCMODE ASYNC
db2 UPDATE DB CFG FOR <SID> USING HADR_SPOOL_LIMIT 1000
db2 UPDATE DB CFG FOR <SID> USING HADR_PEER_WINDOW 240
db2 UPDATE DB CFG FOR <SID> USING indexrec RESTART logindexbuild ON
在灾难恢复数据库，中执行以下命令更新参数。 db2 UPDATE DB CFG FOR <SID> USING HADR_LOCAL_HOST HOST2
db2 UPDATE DB CFG FOR <SID> USING HADR_LOCAL_SVC <SID>_HADR_2
db2 UPDATE DB CFG FOR <SID> USING HADR_REMOTE_HOST HOST1
db2 UPDATE DB CFG FOR <SID> USING HADR_REMOTE_SVC <SID>_HADR_1
db2 UPDATE DB CFG FOR <SID> USING HADR_REMOTE_INST db2<sid>
db2 UPDATE DB CFG FOR <SID> USING HADR_TIMEOUT 120
db2 UPDATE DB CFG FOR <SID> USING HADR_SYNCMODE ASYNC
db2 UPDATE DB CFG FOR <SID> USING HADR_SPOOL_LIMIT 1000
db2 UPDATE DB CFG FOR <SID> USING HADR_PEER_WINDOW 240
db2 UPDATE DB CFG FOR <SID> USING indexrec RESTART logindexbuild ON
这些参数是向两个数据库提供HADR相关信息所必需的。在 Db2 数据库中HADR，根据先前设置的每个参数的值进行激活。有关这些参数的更多信息，请参阅IBM文档。 使用以下命令HADR首先在新创建的备用数据库上启动。 db2 deactivate db <SID>
db2 start hadr on db <SID> as standby
使用以下命令启动HADR生产数据库。 db2 deactivate db <SID>
db2 start hadr on db <SID> as primary
检查生产数据库和备用 Db2 数据库是否同步，以及日志传送是否正在进行中。 要监视HADR复制状态，请使用以下db2pd命令。 db2pd -d <SID> -hadr
有关监控的更多信息HADR，请参阅IBM文档。
| SAP基础管理员 |
| 任务 | 描述 | 所需技能 |
|---|
规划灾难恢复测试生产业务停机时间。 | 确保在生产环境中计划所需业务停机时间，以测试灾难恢复失效转移场景。 | SAP基础管理员 |
创建测试用户。 | 创建可在灾难恢复主机中进行验证的测试用户（或任何测试更改），以确认灾难恢复失效转移后的日志复制。 | SAP基础管理员 |
在控制台上，停止生产EC2实例。 | 在此步骤中启动非正常关闭，以模拟灾难场景。 | AWS系统管理员 |
扩展 DR EC2 实例以满足要求。 | 在EC2控制台上，更改灾难恢复区域中的实例类型。 停止实例：如果实例正在运行，您必须先停止，然后才能更改其实例类型。在EC2控制台上，选择实例，然后选择停止。 修改实例类型：在EC2控制台上，选择实例，然后选择操作、实例设置、更改实例类型。选择与主实例匹配的实例类型，然后选择应用。 启动实例：实例类型更改完成后，从EC2控制台启动实例，方法是选择实例并选择启动。 要启动 Db2 数据库，请使用以下命令： db2start
db2 start HADR on db <SID> as standby
| SAP基础管理员 |
发起接管。 | 在灾难恢复系统 (host2) 中，启动接管进程并启动灾难恢复数据库作为主数据库。 db2 takeover hadr on database <SID> by force
或者，您可设置以下参数，根据实例类型自动调整数据库内存分配。该 INSTANCE_MEMORY 值可以根据分配给 Db2 数据库的专用内存部分来决定。 db2 update db cfg for <SID> using INSTANCE_MEMORY <FIXED VALUE> IMMEDIATE;
db2 get db cfg for <SID> | grep -i DATABASE_MEMORY AUTOMATIC IMMEDIATE;
db2 update db cfg for <SID> using self_tuning_mem ON IMMEDIATE;
请使用以下命令验证更改。 db2 get db cfg for <SID> | grep -i MEMORY
db2 get db cfg for <SID> | grep -i self_tuning_mem
| SAP基础管理员 |
启动灾难恢复区域SAP中的应用程序服务器。 | 使用您在生产系统中创建的，在灾难恢复区域中启动一台新的附加应用程序服务器。AMI | SAP基础管理员 |
在启动SAP应用程序之前执行验证。 | 验证 /etc/hosts 和 /etc/fstab 条目。 在灾难恢复系统上安装 /sapmnt/<SID>/。 验证灾难恢复文件系统 /sapmnt/<SID>/ 是否与生产 /sapmnt/<SID>/ 文件系统同步。 登录 <sid>adm 用户，运行 R3trans -d 并验证 trans.log 文件中的输出。trans.log 文件是在运行 R3trans -d 命令的同一位置生成的。
| AWS管理员、Basi SAP s 管理员 |
在 DR 系统上启动SAP应用程序。 | 使用<sid>adm用户在灾难恢复系统上启动SAP应用程序。使用以下代码，它XX代表您的SAPABAPSAP中央服务 (ASCS) 服务器的实例号，YY代表您的SAP应用程序服务器的实例号。 sapconrol -nr XX -function StartService <SID>
sapconrol -nr XX -function StartSystem
sapconrol -nr YY -function StartService <SID>
sapconrol -nr YY -function StartSystem
| SAP基础管理员 |
执行SAP验证。 | 这是作为灾难恢复测试执行的，以提供证据或检查灾难恢复区域的数据复制是否成功。 | 测试工程师 |
| 任务 | 描述 | 所需技能 |
|---|
启动生产服务器SAP和数据库服务器。 | 在控制台上，启动生产系统中托管SAP和数据库的EC2实例。 | SAP基础管理员 |
启动生产数据库并进行设置HADR。 | 登录至生产系统 (host1)，使用以下命令验证数据库是否处于恢复模式。 db2start
db2 start HADR on db P3V as standby
db2 connect to <SID>
验证HADR状态是否为connected。复制状态应为 peer。 db2pd -d <SID> -hadr
如果数据库并非不一致且未处于 connected 和 peer 状态，则可能需要进行备份和恢复，以使数据库 (开启 host1) 与当前活动的数据库 (在灾难恢复区域 host2 中) 同步。在这种情况下，请将数据库备份从 host2 灾难恢复区域的数据库还原到 host1 生产区域的数据库。 | SAP基础管理员 |
将数据库故障恢复至生产区域。 | 在正常 business-as-usual情况下，此步骤是在计划停机时间内执行的。在灾难恢复系统上运行的应用程序将停止，数据库将故障恢复到生产区域 (区域 1)，以便从生产区域恢复操作。 登录灾难恢复区域中的SAP应用程序服务器，然后停止SAP应用程序。 /sapmnt/<SID> 从灾难恢复系统中卸载，确保将更改反向复制到 /sapmnt/<SID> 生产系统。
登录生产区域中的数据库服务器 (host1)，然后执行接管。 db2 takeover hadr on database <SID>
检查HADR状态：HADR_ROLE应处于PRIMARY开host1启StandBy状态host2。 db2pd -d <SID> -hadr
| SAP基础管理员 |
在启动SAP应用程序之前执行验证。 | 验证 /etc/hosts 和 /etc/fstab 条目。 在生产系统上安装 /sapmnt/<SID>/。 确保它与灾难恢复系统 /sapmnt/<SID>/ 同步。 登录 <sid>adm 用户，运行 R3trans -d 并验证 trans.log 文件中的输出。trans.log 文件是在运行 R3trans -d 命令的同一位置生成的。
| AWS管理员、Basi SAP s 管理员 |
启动SAP应用程序。 | 使用 <sid>adm user 在生产系统上启动SAP应用程序。使用以下代码，其中XX表示SAPASCS服务器的实例号和YYSAP应用程序服务器的实例号。 sapconrol -nr XX -function StartService <SID>
sapconrol -nr XX -function StartSystem
sapconrol -nr YY -function StartService <SID>
sapconrol -nr YY -function StartSystem
要确认应用程序服务器是否可用，请登录SAP并使用SICK和SM51事务执行检查。
| SAP基础管理员 |
故障排除
相关资源
其他信息
使用这种模式，您可以为在 Db2 数据库上运行的SAP系统设置灾难恢复系统。在灾难情况下，业务应该能够在您定义的恢复时间目标 (RTO) 和恢复点目标 (RPO) 要求内继续进行：
有关FAQs相关内容HADR，请参阅 Db2 高可用性灾难恢复 (HADR) FAQ 上的SAP注释 #1612105-DB6:。（您需要SAP门户凭据才能访问此笔记。）
