SAP で Db2 IBM のディザスタリカバリを設定する AWS - AWS 規範ガイダンス

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

SAP で Db2 IBM のディザスタリカバリを設定する AWS

作成者: Ambarish Satarkar (AWS) および Debasis Sahoo (AWS)

環境:本稼働

テクノロジー: データベース、オペレーション

ワークロード: SAP

AWS サービス: Amazon EC2、AWSElastic Disaster Recovery

[概要]

このパターンは、Amazon Web Services () クラウドで実行されているデータベースプラットフォームとして IBM Db2 を使用するSAPワークロードのディザスタリカバリ (DRAWS) システムを設定する手順の概要を示しています。目的は、ディザスタが発生した場合でも、事業を継続できる低コストのソリューションを提供することです。

このパターンでは、「パイロットライト方式」 を使用します。にパイロットライト DR を実装することでAWS、ダウンタイムを短縮し、ビジネス継続性を維持できます。パイロットライトアプローチはAWS、SAPシステムやスタンバイ Db2 データベースなど、本番環境と同期された最小限の DR 環境を で設定することに焦点を当てています。

このソリューションはスケーラブルです。必要に応じて本格的なディザスタリカバリ環境に拡張できます。

前提条件と制限

前提条件

  • Amazon Elastic Compute Cloud (Amazon EC2) SAPインスタンスで実行されているインスタンス

  • IBM Db2 データベース

  • Product SAP Availability Matrix (PAM) でサポートされているオペレーティングシステム

  • 本番データベースホストとスタンバイデータベースホストで異なる物理データベースホスト名

  • クロスリージョンレプリケーション () が有効になっている各AWSリージョンの Amazon Simple Storage Service (Amazon S3) バケット CRR

製品バージョン

  • 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 を使用して DR データベースHADRを設定し、本番データベースとスタンバイデータベース間のログ配送を自動化します。

リージョン 1 が使用できなくなるようなディザスタが発生した場合、DR リージョンのスタンバイデータベースが本番データベースの役割を引き継ぎます。SAP アプリケーションサーバーは、事前に構築することも、AWSElastic Disaster Recovery または Amazon マシンイメージ (AMI) を使用して復旧時間目標 (RTO) 要件を満たすこともできます。このパターンは を使用しますAMI。

Db2 は、本番稼働用スタンバイ設定HADRを実装します。このセットアップでは、本番稼働用がプライマリサーバーとして機能し、すべてのユーザーが接続されます。すべてのトランザクションはログファイルに書き込まれ、TCP/IP を使用してスタンバイサーバーに転送されます。スタンバイサーバーは、転送されたログレコードをロールフォワードしてローカルデータベースを更新します。これにより、本番サーバーとの同期が保持されます。

VPC ピアリングは、本番稼働リージョンと DR リージョンのインスタンスが相互に通信できるように使用されます。Amazon Route 53 は、エンドユーザーをインターネットアプリケーションにルーティングします。

クロスリージョンレプリケーションAWSを使用した での Db2
  1. リージョン AMI1 でアプリケーションサーバーの を作成し、 をリージョン 2 にコピーAMIします。AMI を使用して、災害が発生した場合にリージョン 2 でサーバーを起動します。

  2. 本番稼働用データベース (リージョン 1) とスタンバイデータベース (リージョン 2) の間で Db2 HADRレプリケーションを設定します。

  3. 災害発生時に実稼働EC2インスタンスと一致するようにインスタンスタイプを変更します。

  4. リージョン 1 では、LOGARCHMETH1db2remote: S3 path に設定されます。

  5. リージョン 2 では、LOGARCHMETH1db2remote: S3 path に設定されます。

  6. クロスリージョンレプリケーションは S3 バケット間で実行されます。

ツール

AWS サービス

  • Amazon Elastic Compute Cloud (Amazon EC2) は、AWSクラウドでスケーラブルなコンピューティング容量を提供します。必要な数の仮想サーバーを起動することができ、迅速にスケールアップまたはスケールダウンができます。

  • Amazon Route 53 は、可用性が高くスケーラブルなDNSウェブサービスです。

  • Amazon Simple Storage Service (Amazon S3) は、どのようなデータ量であっても、データを保存、保護、取得することを支援するクラウドベースのオブジェクトストレージサービスです。

  • Amazon Virtual Private Cloud (Amazon VPC) は、定義した仮想ネットワークにAWSリソースを起動するのに役立ちます。この仮想ネットワークは、独自のデータセンターで運用する従来のネットワークに似ており、 のスケーラブルなインフラストラクチャを使用する利点がありますAWS。このパターンはVPCピアリング を使用します。

ベストプラクティス

  • ネットワークは、HADRレプリケーションモードを決定する際に重要な役割を果たします。AWS リージョン間の DR では、Db2 HADRASYNCまたは SUPERASYNC モードを使用することをお勧めします。 

  • Db2 のレプリケーションモードの詳細についてはHADR、IBMドキュメント を参照してください。

  • AWS マネジメントコンソールまたはAWSコマンドラインインターフェイス (AWS CLI) を使用して、既存のSAPシステムの新しい を作成できますAMI。その後、 を使用して既存のSAPシステムをAMI復旧したり、クローンを作成したりできます。

  • AWS Systems Manager Automation は、EC2インスタンスやその他のAWSリソースの一般的なメンテナンスおよびデプロイタスクに役立ちます。

  • AWS は、 でインフラストラクチャとアプリケーションをモニタリングおよび管理するための複数のネイティブサービスを提供しますAWS。Amazon CloudWatch や などのサービスはAWS CloudTrail 、基盤となるインフラストラクチャとAPIオペレーションをそれぞれモニタリングするために使用できます。詳細については、SAPAWS「 - IBM Db2 HADR with Pacemaker 」を参照してください。

エピック

タスク説明必要なスキル

システムとログをチェックします。

  1. Db2 SAP システムの本番稼働が設定されていることを確認します。

  2. ログバックアップが有効になって、S3 バケットにログを保存するように設定されていることを確認します。Db2 パラメータ LOGARCHMETH1 で確認できます。

  3. AMI 追加のアプリケーションサーバーの を作成します。

AWS 管理者、SAPベーシス管理者
タスク説明必要なスキル

SAP および データベースサーバーを作成します。

  1. DR リージョンのインフラストラクチャをデプロイするには、AWS CloudFormation スクリプトを使用するか、本番インスタンスAMIの を使用します。パイロットライトアプローチの一環として、本番EC2インスタンスと同じファミリー内の小さなインスタンスを使用できます。たとえば、本番インスタンスタイプが r6i.12xlarge の場合、DR ビルドの r6i.xlarge のインスタンスタイプを使用できます。ただし、本番環境のデータベースバックアップを復元するには、必ず DR インスタンスに同じストレージ容量を割り当てます。

  2. の Amazon Elastic File System (Amazon EFS) マウントポイントを作成し/sapmnt/<SID>/、プライマリシステムからレプリケートされるように設定されていることを確認します。

  3. 本番システムからFULLデータベースバックアップ (オンラインまたはオフライン) を実行します。このバックアップを使用して DR データベースを構築します。

  4. DR システムでは、SAPSoftware Provisioning Manager (SWPM) システムコピーメソッドを HA/DR 目的でバックアップ/復元でシステムコピーを使用して DR SAPシステムを構築します。

  5. から求められたらSWPM、本番稼働環境から取得したバックアップを使用して、DR でデータベースを復元します。DR データベースはロールフォワード保留状態になります。

ロールフォワード保留状態は、フルバックアップの復元後にデフォルトで設定されます。ロールフォワード保留状態は、データベースが復元中で、何らかの変更を適用する必要がある可能性があることを示します。詳細については、IBM「 ドキュメント」を参照してください。

SAP Basis 管理者

設定を確認します。

  1. のログアーカイブを設定するにはHADR、本番データベースと DR データベースの両方が、すべてのログアーカイブの場所からログを自動的に取得できる必要があります。DR データベースの LOGARCHMETH1 パラメータが本番データベースと同じ場所に設定されていることを検証します。リージョンの制限により同じ場所がアクセス不能な場合、DR システムがプライマリシステムからログを自動的に取得できることを確保します。

  2. データベースレプリケーションを有効にするために TCP/IP ポートを有効にするには、次の 2 つのエントリを追加して、本番ホストと DR ホスト/etc/servicesで を変更します。コードでは、 は Db2 データベースのシステム ID (SID) <SID>を参照します (例: PR1)。

    <SID>_HADR_1 55001/tcp # DB2 HADR Port1 <SID>_HADR_2 55002/tcp # DB2 HADR Port2

    両方のポートでは、プライマリとスタンバイ間のインバウンドトラフィックとアウトバウンドトラフィックが許可されていることを確認します。

  3. 本番ホストと DR ホストで /etc/hosts をチェックインして、本番ホストとスタンバイホストの両方のホスト名が正しい IP アドレスを指していることを確認します。

AWS 管理者、SAPベーシス管理者

本番 DB から DR DB へのレプリケーションを設定します ( ASYNC モードを使用)。

  1. 本番データベースで、次のコマンドを実行してパラメータを更新します。

    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
  2. DR データベースで、次のコマンドを実行してパラメータを更新します。

    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「 ドキュメント」を参照してください。

  3. 次のコマンドを使用して、新しく作成されたスタンバイデータベースでHADR最初に開始します。

    db2 deactivate db <SID> db2 start hadr on db <SID> as standby
  4. 次のコマンドを使用して、本番稼働用データベースHADRを起動します。

    db2 deactivate db <SID> db2 start hadr on db <SID> as primary
  5. 本番とスタンバイの Db2 データベースが同期していて、ログ配信が進行中であるかどうかを確認します。

    HADR レプリケーションステータスをモニタリングするには、次のdb2pdコマンドを使用します。

    db2pd -d <SID> -hadr

    のモニタリングの詳細についてはHADR、IBM「 ドキュメント」を参照してください。

SAP Basis 管理者
タスク説明必要なスキル

DR テストの本番ビジネスのダウンタイムを計画します。

DR フェイルオーバーシナリオをテストするために、必ず本番環境で必要な業務停止時間を計画するようにします。

SAP Basis 管理者

テストユーザーを作成します。

DR ホストで検証できるテストユーザー (または任意のテスト変更) を作成して、DR フェイルオーバー後のログの複製を確認します。

SAP Basis 管理者

コンソールで、本番EC2稼働インスタンスを停止します。

このステップでは、ディザスタシナリオを想定して不適切なシャットダウンが開始されます。

AWS システム管理者

DR EC2インスタンスを要件に合わせてスケールアップします。

EC2 コンソールで、DR リージョンのインスタンスタイプを変更します。

  1. インスタンスを停止:インスタンスが実行中の場合、そのインスタンスを先に停止する必要があります。EC2 コンソールでインスタンスを選択し、停止 を選択します。

  2. インスタンスタイプを変更する: EC2コンソールでインスタンスを選択し、アクション、インスタンス設定インスタンスタイプの変更 を選択します。プライマリインスタンスと一致するインスタンスタイプを選択し、[適用]を選択します。

  3. インスタンスを開始する: インスタンスタイプの変更が完了したら、インスタンスを選択し、開始 を選択してEC2、コンソールからインスタンスを開始します。

  4. データベースを削除するには、次のコマンドを使用します。

    db2start db2 start HADR on db <SID> as standby
SAP Basis 管理者

テイクオーバーを初期化します。

DR システム (host2) から、テイクオーバープロセスを開始し、DR データベースをプライマリとして起動します。

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 Basis 管理者

DR リージョンSAPで のアプリケーションサーバーを起動します。

本番稼働システムでAMI作成した を使用して、DR リージョンで新しい追加のアプリケーションサーバーを起動します。

SAP Basis 管理者

SAP アプリケーションを開始する前に検証を実行します。

  1. /etc/hosts および /etc/fstab のエントリを検証します。

  2. DR システムに /sapmnt/<SID>/ をマウントします。

  3. DRファイルシステム /sapmnt/<SID>/ が本番環境 /sapmnt/<SID>/ と同期していることを確認します。

  4. <sid>adm ユーザーにログインして R3trans -d を実行し、trans.log ファイルの出力を確認します。trans.log ファイルが R3trans -d コマンドを実行した同じ場所に生成されます。

AWS 管理者、SAPベーシス管理者

DR システムでSAPアプリケーションを起動します。

<sid>adm ユーザーを使用して、DR システムでSAPアプリケーションを起動します。次のコードを使用します。 XXは Central SAP ABAP SAP Services (ASCS) サーバーのインスタンス番号を表し、 はSAPアプリケーションサーバーのインスタンス番号YYを表します。

sapconrol -nr XX -function StartService <SID> sapconrol -nr XX -function StartSystem sapconrol -nr YY -function StartService <SID> sapconrol -nr YY -function StartSystem
SAP Basis 管理者

SAP 検証を実行します。

DR テストとして実施され、エビデンスを提供したり、DR 領域へのデータ複製の成功を確認したりします。

テストエンジニア
タスク説明必要なスキル

本番稼働サーバーSAPとデータベースサーバーを起動します。

コンソールで、ホストするEC2インスタンスSAPと、本番稼働システムのデータベースを起動します。

SAP Basis 管理者

本番稼働用データベースを起動し、 をセットアップしますHADR。

本番システム (host1) にログインし、以下のコマンドを使用して DB がリカバリモードになっていることを確認します。

db2start db2 start HADR on db P3V as standby db2 connect to <SID>

HADR ステータスが であることを確認しますconnected。レプリケーションステータスが peer であるはずです。

db2pd -d <SID> -hadr

データベースに不一致がなく、connectedpeer のステータスではない場合、現在アクティブなデータベース (DR リージョンの host2)とデータベースを同期(host1 で)するために、バックアップと復元が必要になることがあります。その場合、DB バックアップを host2 DR のリージョンのデータベースから host1 本番リージョンのデータベースに復元します。

SAP Basis 管理者

データベースを本番リージョンにフェイルバックします。

通常の business-as-usualシナリオでは、このステップはスケジュールされたダウンタイムで実行されます。DR システムで実行されているアプリケーションが停止され、データベースが本番リージョン (リージョン 1) にフェイルバックされ、本番リージョンからのオペレーションが再開されます。

  1. DR リージョンのSAPアプリケーションサーバーにログインし、SAPアプリケーションを停止します。

  2. DRシステムから /sapmnt/<SID> をアンマウントし、本番システムの /sapmnt/<SID> に変更がリバースレプリケートされることを確認します。

  3. 本番リージョンのデータベースサーバー (host1) にログインし、テイクオーバーを実行します。

    db2 takeover hadr on database <SID>
  4. HADR ステータスを確認します。 は PRIMARYhost1、 は StandByHADR_ROLEする必要がありますhost2

    db2pd -d <SID> -hadr
SAP Basis 管理者

SAP アプリケーションを開始する前に検証を実行します。

  1. /etc/hosts および /etc/fstab のエントリを検証します。

  2. 本番システムに /sapmnt/<SID>/ をマウントします。

  3. DR システム /sapmnt/<SID>/ と同期していることを確認します。

  4. <sid>adm ユーザーにログインして R3trans -d を実行し、trans.log ファイルの出力を確認します。trans.log ファイルが R3trans -d コマンドを実行した同じ場所に生成されます。

AWS 管理者、SAPベーシス管理者

SAP アプリケーションを起動します。

  1. <sid>adm ユーザーを使用して本番稼働システムでSAPアプリケーションを起動します。次のコードを使用します。 はSAPASCSサーバーのインスタンス番号XXを表し、 はSAPアプリケーションサーバーのインスタンス番号YYを表します。

    sapconrol -nr XX -function StartService <SID> sapconrol -nr XX -function StartSystem sapconrol -nr YY -function StartService <SID> sapconrol -nr YY -function StartSystem
  2.  アプリケーションサーバーが使用可能であることを確認するには、 にログインSAPし、 SICK および SM51トランザクションを使用してチェックを実行します。

SAP Basis 管理者

トラブルシューティング

問題ソリューション

HADR関連の問題をトラブルシューティングするための主要なログファイルとコマンド

  • db2 get db cfg | grep -i hadr

  • db2pd -d sid -hadr

  • Db2diag.log (このファイルは通常 db2dump ディレクトリにあり、db2dump パスがパラメータ DIAGPATH によって定義されます)。

SAP Db2 HADRに関する問題のトラブルシューティングに関する注意事項 UDB

SAP 「注 1154013 - DB6: HADR環境の DB の問題」を参照してください。(このノートにアクセスするにはSAPポータル認証情報が必要です)。

関連リソース

追加情報

このパターンを使用すると、Db2 データベースで実行されているSAPシステムのディザスタリカバリシステムをセットアップできます。災害状況では、ビジネスは定義された復旧時間目標 (RTO) および復旧ポイント目標 (RPO) の要件の範囲内で継続できる必要があります。

  • RTO は、サービスの中断からサービスの復旧までの最大許容遅延時間です。これにより、サービスが利用できなくなったときに許容できる時間枠が決まります。

  • RPO は、最後のデータ復旧時点からの最大許容時間です。これにより、最後の回復時点からサービスが中断されるまでの間に許容できるデータ損失の程度が決まります。

FAQs に関する詳細についてはHADR、SAPDb2 高可用性ディザスタリカバリ (HADR) FAQの注 #1612105 - DB6: を参照してください。(このノートにアクセスするにはSAPポータル認証情報が必要です)。