翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # AWS の IBM Db2 に SAP のディザスタリカバリをセットアップ *Amazon Web Services、Ambarish Satarkar、Debasis Sahoo* ## 概要 このパターンでは、Amazon Web Services（AWS）クラウドで稼働する IBM Db2 をデータベースプラットフォームとして使用する、SAP ワークロードのディザスタリカバリ（DR）システムをセットアップする手順の概要を示します。目的は、ディザスタが発生した場合でも、事業を継続できる低コストのソリューションを提供することです。 このパターンでは、「[パイロットライト方式](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/)」 を使用します。AWS にパイロットライト DR を実装することで、ダウンタイムを削減し、ビジネスの継続性を維持できます。パイロットライトアプローチは、SAP システムやスタンバイ Db2 データベースなど、本番環境と同期する最小限の DR 環境を AWS に設定することに重点を置いています。 このソリューションはスケーラブルです。必要に応じて本格的なディザスタリカバリ環境に拡張できます。 ## 前提条件と制限 **前提条件** + レプリケーションインスタンスは、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスで実行されます。 + IBM Db2 データベース + SAP 製品可用性マトリックス (PAM) が適用されるオペレーティングシステム + 本番データベースホストとスタンバイデータベースホストで異なる物理データベースホスト名 + 各 AWS リージョンでは、「[クロスリージョンレプリケーション (CRR)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html)」 が有効になっている Amazon Simple Storage Service (Amazon S3) バケット **製品バージョン** + IBM Db2 データベースバージョン 11.5.7 以降 ## アーキテクチャ **ターゲットテクノロジースタック** + Amazon EC2 + Amazon Simple Storage Service (Amazon S3) + Amazon Virtual Private Cloud (VPC ピアリング) + Amazon Route 53 + IBM Db2 高可用性ディザスタリカバリ (HADR) **ターゲットアーキテクチャ** このアーキテクチャーは、データベースプラットフォームとして Db2 を使用する SAP ワークロード用の DR ソリューションを実装します。本番データベースは AWS リージョン 1 にデプロイされ、スタンバイデータベースは 2 番目のリージョンにデプロイされます。スタンバイデータベースは DR システムを指します。Db2 Database には、複数のスタンバイデータベース (最大 3 つ) が適用されます。Db2 HADR を使用して DR データベースを設定し、本番データベースとスタンバイデータベース間のログ配布を自動化します。 リージョン 1 が使用できなくなるようなディザスタが発生した場合、DR リージョンのスタンバイデータベースが本番データベースの役割を引き継ぎます。SAP アプリケーションサーバーは、目標復旧時間 (RTO) の要件を満たすために、事前に構築することも、「[AWS エラスティックディザスタリカバリ](https://aws.amazon.com/disaster-recovery/)」 や Amazon マシンイメージ (AMI) を使用して構築することもできます。このパターンでは AMI を使用します。 Db2 HADR は、本番がプライマリサーバーとして機能し、すべてのユーザーがそのサーバーに接続されます。本番とスタンバイのセットアップを実装しています。すべてのトランザクションがログファイルに書き込まれ、TCP/IP を使用してスタンバイサーバーに転送されます。スタンバイサーバーは、転送されたログレコードをロールフォワードしてローカルデータベースを更新します。これにより、本番サーバーとの同期が保持されます。 VPC ピアリングは、本番リージョンと DR リージョンのインスタンスが相互に通信できるようにするために使用されます。Amazon Route 53 は、エンドユーザーをインターネットアプリケーションにルーティングします。 ![\[クロスリージョンレプリケーションのAWSのDb2\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/06edfa4c-0827-4d05-95cf-2d2651e74323/images/e77c1e4e-36f3-4af4-89d0-8eec72348f0a.png) 1. リージョン 1 にアプリケーションサーバーの 「[AMI を作成](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html#creating-an-ami)」し、その AMI をリージョン 2 に「[コピーします](https://repost.aws/knowledge-center/copy-ami-region)」 。ディザスタが発生した場合、AMI を使用してリージョン 2 のサーバーを起動します。 1. 本番データベース (リージョン 1) とスタンバイデータベース (リージョン 2) の間で Db2 HADR レプリケーションを設定します。 1. ディザスタが発生した時、本番インスタンスに合わせて EC2 インスタンスタイプを変更します。 1. リージョン 1 では、`LOGARCHMETH1` が `db2remote: S3 path` に設定されます。 1. リージョン 2 では、`LOGARCHMETH1` が `db2remote: S3 path` に設定されます。 1. クロスリージョンレプリケーションは S3 バケット間で実行されます。 ## ツール ** サービス** + 「[Amazon Elastic Compute Cloud (Amazon EC2)](https://docs.aws.amazon.com/ec2/)」は、AWS クラウドでスケーラブルなコンピューティング容量を提供します。必要な数の仮想サーバーを起動することができ、迅速にスケールアップまたはスケールダウンができます。 + [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) は、高可用性でスケーラブルな DNS Web サービスです。 + [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、どのようなデータ量であっても、データを保存、保護、取得することを支援するクラウドベースのオブジェクトストレージサービスです。 + [Amazon Virtual Private Cloud (Amazon VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) を使用すると、定義した仮想ネットワーク内で AWS リソースを起動できます。この仮想ネットワークは、お客様自身のデータセンターで運用されていた従来のネットワークに似ていますが、AWS のスケーラブルなインフラストラクチャを使用できるというメリットがあります。このパターンでは、「[VPC ピアリング](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-peering.html)」を使用します。 ## ベストプラクティス + ネットワークは HADR のレプリケーションモードを決定する上で重要な役割を果たします。AWS リージョン間の DR には、Db2 HADR ASYNC モードまたは SUPERASYNC モードを使用することを推奨します。  + Db2 HADR のレプリケーションモードの詳細については、「[IBM のドキュメント](https://ibm.github.io/db2-hadr-wiki/hadrSyncMode.html#Description_of_the_Modes)」 を参照してください。 + 既存の SAP システムの「[新しい AMI を作成](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html#creating-an-ami)」するには、AWS マネジメントコンソールまたはAWS コマンドラインインターフェイス (AWS CLI) を使用できます。その後、AMI を使用して既存の SAP システムを復元したり、クローンを作成したりできます。 + [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) は、Amazon EC2 インスタンスおよび他の AWS リソースの一般的なメンテナンスとデプロイのタスクを簡略化します。 + AWS では、AWS のインフラストラクチャとアプリケーションを監視および管理するための複数のネイティブサービスを提供します。Amazon CloudWatch や AWS CloudTrail などのサービスを使用して、基盤となるインフラストラクチャと API オペレーションをそれぞれ監視できます。詳細については、「[SAP on AWS — IBM Db2 HADR with Pacemaker](https://docs.aws.amazon.com/sap/latest/sap-AnyDB/sap-ibm-pacemaker.html)」 を参照してください。 ## エピック ### 環境の準備 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | システムとログをチェックします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-disaster-recovery-for-sap-on-ibm-db2-on-aws.html) | AWS 管理者、SAP ベーシス管理者 | ### サーバーとレプリケーションをセットアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | SAP サーバーとデータベースサーバーを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-disaster-recovery-for-sap-on-ibm-db2-on-aws.html)ロールフォワード保留状態は、フルバックアップの復元後にデフォルトで設定されます。ロールフォワード保留状態は、データベースが復元中で、何らかの変更を適用する必要がある可能性があることを示します。詳細については、「[IBM ドキュメント](https://www.ibm.com/docs/en/db2/11.5?topic=commands-rollforward-database)」を参照してください。 | SAP ベーシス管理者 | | 設定を確認します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-disaster-recovery-for-sap-on-ibm-db2-on-aws.html) | AWS 管理者、SAP ベーシス管理者 | | 本番 DB から DR DB へのレプリケーションを設定します (ASYNC モードを使用)。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-disaster-recovery-for-sap-on-ibm-db2-on-aws.html) | SAP ベーシス管理者 | ### DR フェイルオーバータスクをテスト | タスク | 説明 | 必要なスキル | | --- | --- | --- | | DR テストの本番ビジネスのダウンタイムを計画します。 | DR フェイルオーバーシナリオをテストするために、必ず本番環境で必要な業務停止時間を計画するようにします。 | SAP ベーシス管理者 | | テストユーザーを作成します。 | DR ホストで検証できるテストユーザー (または任意のテスト変更) を作成して、DR フェイルオーバー後のログの複製を確認します。 | SAP ベーシス管理者 | | コンソールで、本番環境の EC2 インスタンスを停止します。 | このステップでは、ディザスタシナリオを想定して不適切なシャットダウンが開始されます。 | AWS システム管理者 | | DR EC2 インスタンスを要件に合わせてスケールアップします。 | EC2 コンソールで、DR リージョンのインスタンスタイプを変更します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-disaster-recovery-for-sap-on-ibm-db2-on-aws.html) | SAP ベーシス管理者 | | テイクオーバーを初期化します。 | DR システム (`host2`) から、テイクオーバープロセスを開始し、DR データベースをプライマリとして起動します。
db2 takeover hadr on database  by force
オプションとして、以下のパラメータを設定して、インスタンスタイプに基づいてデータベースのメモリ割り当てを自動的に調整できます。`INSTANCE_MEMORY` の値は、Db2 データベースに割り当てられるメモリの専用部分に基づいて決定できます。
db2 update db cfg for  using INSTANCE_MEMORY  IMMEDIATE;
db2 get db cfg for  | grep -i DATABASE_MEMORY AUTOMATIC IMMEDIATE; 
db2 update db cfg for  using self_tuning_mem ON IMMEDIATE;
次のコマンドを使用して変更を確認します。
db2 get db cfg for  | grep -i MEMORY
db2 get db cfg for  | grep -i self_tuning_mem
| SAP ベーシス管理者 | | DR リージョンで SAP のアプリケーションサーバーを起動します。 | 本番システムで作成した AMI を使用して、DR リージョンに「[新しい追加のアプリケーションサーバーを起動](https://aws.amazon.com/premiumsupport/knowledge-center/launch-instance-custom-ami/)」 します。 | SAP ベーシス管理者 | | SAP アプリケーションを起動する前に検証を行います。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-disaster-recovery-for-sap-on-ibm-db2-on-aws.html) | AWS 管理者、SAP ベーシス管理者 | | DR システムで SAP アプリケーションを起動します。 | `adm` ユーザーを使用して、 DR システムで SAP アプリケーションを起動します。次のコードを使用したら、`XX` が SAP ABAP SAP セントラルサービス (ASCS)を表し、`YY` がSAPアプリケーションサーバーのインスタンス数を表します。
sapconrol -nr XX -function StartService 
sapconrol -nr XX -function StartSystem
sapconrol -nr YY -function StartService 
sapconrol -nr YY -function StartSystem
| SAP ベーシス管理者 | | SAP 検証を実行します。 | DR テストとして実施され、エビデンスを提供したり、DR 領域へのデータ複製の成功を確認したりします。 | テストエンジニア | ### DR フェイルバックタスクの実行 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 本番環境の SAP サーバーとデータベースサーバーを起動します。 | コンソールで、SAP と本番システムのデータベースをホストするEC2インスタンスを起動します。 | SAP ベーシス管理者 | | 本番データベースを起動し、HADR を設定します。 | 本番システム (`host1`) にログインし、以下のコマンドを使用して DB がリカバリモードになっていることを確認します。
db2start
db2 start HADR on db P3V as standby
db2 connect to
HADRの状態が `connected` であることを確認します。レプリケーションステータスが `peer` であるはずです。
db2pd -d  -hadr
データベースに不一致がなく、`connected` と `peer` のステータスではない場合、現在アクティブなデータベース (DR リージョンの `host2`)とデータベースを同期(`host1` で)するために、バックアップと復元が必要になることがあります。その場合、DB バックアップを `host2` DR のリージョンのデータベースから `host1` 本番リージョンのデータベースに復元します。 | SAP ベーシス管理者 | | データベースを本番リージョンにフェイルバックします。 | 通常の業務シナリオでは、このステップがスケジュール済みのダウンタイムに実行されます。DR システムで実行されているアプリケーションが停止され、データベースが本番リージョン (リージョン 1) にフェイルバックされ、本番リージョンからのオペレーションが再開されます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-disaster-recovery-for-sap-on-ibm-db2-on-aws.html) | SAP ベーシス管理者 | | SAP アプリケーションを起動する前に検証を行います。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-disaster-recovery-for-sap-on-ibm-db2-on-aws.html) | AWS 管理者、SAP ベーシス管理者 | | SAP アプリケーションを起動します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-disaster-recovery-for-sap-on-ibm-db2-on-aws.html) | SAP ベーシス管理者 | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | HADR 関連の問題をトラブルシューティングするためのキーログファイルとコマンド | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-disaster-recovery-for-sap-on-ibm-db2-on-aws.html) | | Db2 UDB の HADR 問題のトラブルシューティングに関する SAP ノート | 「[SAP ノート 1154013-DB6:HADR 環境のDBの問題](https://service.sap.com/sap/support/notes/1154013)」 を参照してください。(このノートにアクセスするには SAP ポータルの認証情報が必要です)。 | ## 関連リソース + 「[AWS 上の Db2 データベースのディザスタリカバリアプローチ](https://aws.amazon.com/blogs/architecture/disaster-recovery-approaches-for-db2-databases-on-aws/)」 (ブログ記事) + 「[SAP on AWS — ペースメーカー搭載の IBM Db2 HADR](https://docs.aws.amazon.com/sap/latest/sap-AnyDB/sap-ibm-pacemaker.html)」 + 「[DB2 データベース間で HADR レプリケーションをセットアップするステップバイステップの手順](https://www.ibm.com/support/pages/step-step-procedure-set-hadr-replication-between-db2-databases)」 + 「[DB2 HADR ウィキ](https://ibm.github.io/db2-hadr-wiki/index.html)」 ## 追加情報 このパターンを使用して、Db2 データベースで稼働している SAP システムのディザスタリカバリシステムを設定できます。ディザスタの時、定義された目標復旧時間 (RTO) と目標復旧時点 (RPO) の要件の範囲でビジネスを継続できる必要があります: + **RTO** とは、サービスが中断してから復旧するまでに経過した時間の、許容される最大値のことです。これにより、サービスが使用不可のときに許容される時間枠が決まります。 + **RPO** とは、データが最後に復旧した時点を起点とする経過時間の、許容される最大値のことです。これにより、最後の回復時点からサービスが中断されるまでの間に許容できるデータ損失の程度が決まります。 HADR に関するよくある質問については、「[SAP ノート \$11612105-DB6: Db2 高可用性ディザスタリカバリ (HADR) に関する FAQ](https://launchpad.support.sap.com/#/notes/1612105)」 を参照してください。(このノートにアクセスするには SAP ポータルの認証情報が必要です)。