翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
での Db2 IBM SAPでの のディザスタリカバリの設定 AWS
作成者: Ambarish Satarkar (AWS) と Debasis Sahoo (AWS)
概要
このパターンは、Amazon Web Services () クラウドで実行されているデータベースプラットフォームとして Db2 IBM を使用する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
製品バージョン
アーキテクチャ
ターゲットテクノロジースタック
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 は、エンドユーザーをインターネットアプリケーションにルーティングします。
リージョン AMI1 でアプリケーションサーバーの を作成し、 をリージョン 2 にコピーAMIします。を使用してAMI、災害発生時にリージョン 2 でサーバーを起動します。
本番データベース (リージョン 1) とスタンバイデータベース (リージョン 2) の間で Db2 HADRレプリケーションを設定します。
災害発生時に実稼働EC2インスタンスと一致するようにインスタンスタイプを変更します。
リージョン 1 では、LOGARCHMETH1
が db2remote: S3 path
に設定されます。
リージョン 2 では、LOGARCHMETH1
が db2remote: S3 path
に設定されます。
クロスリージョンレプリケーションは S3 バケット間で実行されます。
AWS サービス
ベストプラクティス
ネットワークは、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 AWS CloudTrail CloudWatch や などのサービスを使用して、基盤となるインフラストラクチャとAPIオペレーションをそれぞれモニタリングできます。詳細については、SAP「 - AWS IBM Db2 HADR with Pacemaker」の「」を参照してください。
エピック
タスク | 説明 | 必要なスキル |
---|
システムとログをチェックします。 | Db2 SAP システムの本稼働環境が設定されていることを確認します。 ログバックアップが有効になって、S3 バケットにログを保存するように設定されていることを確認します。Db2 パラメータ LOGARCHMETH1 で確認できます。 追加のアプリケーションサーバーの AMI を作成します。
| AWS 管理者、SAP基本管理者 |
タスク | 説明 | 必要なスキル |
---|
SAP および データベースサーバーを作成します。 | DR リージョンのインフラストラクチャをデプロイするには、 AWS CloudFormation スクリプトを使用するか、本番稼働用インスタンスAMIの を使用します。パイロットライトアプローチの一環として、本番稼働用EC2インスタンスと同じファミリーの小さなインスタンスを使用できます。たとえば、本番インスタンスタイプが r6i.12xlarge の場合、DR ビルドの r6i.xlarge のインスタンスタイプを使用できます。ただし、本番環境のデータベースバックアップを復元するには、必ず DR インスタンスに同じストレージ容量を割り当てます。 の Amazon Elastic File System (Amazon EFS) マウントポイントを作成し/sapmnt/<SID>/ 、プライマリシステムからレプリケートされるように設定されていることを確認します。 本番システムからFULLデータベースのバックアップ (オンラインまたはオフライン) を作成します。このバックアップを使用して DR データベースを構築します。 DR システムでは、SAPSoftware Provisioning Manager (SWPM) システムコピーメソッドを、DR システムを構築するbackup/restore for HA/DR目的でシステムコピーを使用するで使用します。 SAP から求められたらSWPM、本稼働環境から取得したバックアップを使用して DR でデータベースを復元します。DR データベースはロールフォワード保留状態になります。
ロールフォワード保留状態は、フルバックアップの復元後にデフォルトで設定されます。ロールフォワード保留状態は、データベースが復元中で、何らかの変更を適用する必要がある可能性があることを示します。詳細については、IBM のドキュメントを参照してください。 | SAP 基本管理者 |
設定を確認します。 | のログアーカイブを設定するにはHADR、本番データベースと DR データベースの両方が、すべてのログアーカイブの場所からログを自動的に取得できる必要があります。DR データベースの LOGARCHMETH1 パラメータが本番データベースと同じ場所に設定されていることを検証します。リージョンの制限により同じ場所がアクセス不能な場合、DR システムがプライマリシステムからログを自動的に取得できることを確保します。 データベースレプリケーションを有効にするために 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
両方のポートでは、プライマリとスタンバイ間のインバウンドトラフィックとアウトバウンドトラフィックが許可されていることを確認します。 本番ホストと DR ホストで /etc/hosts をチェックインして、本番ホストとスタンバイホストの両方のホスト名が正しい IP アドレスを指していることを確認します。
| AWS 管理者、SAP基本管理者 |
本番 DB から DR DB へのレプリケーションを設定します ( 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
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ドキュメントを参照してください。 次のコマンドを使用して、新しく作成されたスタンバイデータベースで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 基本管理者 |
タスク | 説明 | 必要なスキル |
---|
DR テストの本番ビジネスのダウンタイムを計画します。 | DR フェイルオーバーシナリオをテストするために、必ず本番環境で必要な業務停止時間を計画するようにします。 | SAP 基本管理者 |
テストユーザーを作成します。 | DR ホストで検証できるテストユーザー (または任意のテスト変更) を作成して、DR フェイルオーバー後のログの複製を確認します。 | SAP 基本管理者 |
コンソールで、本番稼働用EC2インスタンスを停止します。 | このステップでは、ディザスタシナリオを想定して不適切なシャットダウンが開始されます。 | AWS システム管理者 |
DR EC2インスタンスを要件に合わせてスケールアップします。 | EC2 コンソールで、DR リージョンのインスタンスタイプを変更します。 インスタンスを停止:インスタンスが実行中の場合、そのインスタンスを先に停止する必要があります。EC2 コンソールで、インスタンスを選択し、停止を選択します。 インスタンスタイプを変更する: EC2コンソールでインスタンスを選択し、アクション、インスタンス設定、インスタンスタイプの変更を選択します。プライマリインスタンスと一致するインスタンスタイプを選択し、[適用]を選択します。 インスタンスを起動する: インスタンスタイプの変更が完了したら、インスタンスを選択し、開始を選択してEC2、コンソールからインスタンスを起動します。 データベースを削除するには、次のコマンドを使用します。 db2start
db2 start HADR on db <SID> as standby
| SAP 基本管理者 |
テイクオーバーを初期化します。 | 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 基本管理者 |
DR リージョンSAPで のアプリケーションサーバーを起動します。 | 本稼働システムでAMI作成した を使用して、DR リージョンで新しい追加のアプリケーションサーバーを起動します。 | SAP 基本管理者 |
SAP アプリケーションを開始する前に検証を実行します。 | /etc/hosts および /etc/fstab のエントリを検証します。
DR システムに /sapmnt/<SID>/ をマウントします。 DRファイルシステム /sapmnt/<SID>/ が本番環境 /sapmnt/<SID>/ と同期していることを確認します。 <sid>adm ユーザーにログインして R3trans -d を実行し、trans.log ファイルの出力を確認します。trans.log ファイルが R3trans -d コマンドを実行した同じ場所に生成されます。
| AWS 管理者、SAP基本管理者 |
DR システムでSAPアプリケーションを起動します。 | <sid>adm ユーザーを使用して、DR システムでSAPアプリケーションを起動します。次のコードを使用します。このコードでは、 XX はSAPABAPSAPセントラルサービス (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 基本管理者 |
SAP 検証を実行します。 | DR テストとして実施され、エビデンスを提供したり、DR 領域へのデータ複製の成功を確認したりします。 | テストエンジニア |
タスク | 説明 | 必要なスキル |
---|
本番稼働用サーバーSAPとデータベースサーバーを起動します。 | コンソールで、本番稼働システムで SAPと データベースをホストするEC2インスタンスを起動します。 | SAP 基本管理者 |
本番データベースを起動し、 をセットアップしますHADR。 | 本番システム (host1 ) にログインし、以下のコマンドを使用して DB がリカバリモードになっていることを確認します。 db2start
db2 start HADR on db P3V as standby
db2 connect to <SID>
HADR ステータスが であることを確認しますconnected 。レプリケーションステータスが peer であるはずです。 db2pd -d <SID> -hadr
データベースに不一致がなく、connected と peer のステータスではない場合、現在アクティブなデータベース (DR リージョンの host2 )とデータベースを同期(host1 で)するために、バックアップと復元が必要になることがあります。その場合、DB バックアップを host2 DR のリージョンのデータベースから host1 本番リージョンのデータベースに復元します。 | SAP 基本管理者 |
データベースを本番リージョンにフェイルバックします。 | 通常の business-as-usualシナリオでは、このステップはスケジュールされたダウンタイムで実行されます。DR システムで実行されているアプリケーションが停止され、データベースが本番リージョン (リージョン 1) にフェイルバックされ、本番リージョンからのオペレーションが再開されます。 DR リージョンのSAPアプリケーションサーバーにログインし、SAPアプリケーションを停止します。 DRシステムから /sapmnt/<SID> をアンマウントし、本番システムの /sapmnt/<SID> に変更がリバースレプリケートされることを確認します。 本番リージョンのデータベースサーバー (host1 ) にログインし、テイクオーバーを実行します。 db2 takeover hadr on database <SID>
HADR ステータスを確認します。 は PRIMARY でhost1 、 HADR_ROLE は StandBy である必要がありますhost2 。 db2pd -d <SID> -hadr
| SAP 基本管理者 |
SAP アプリケーションを開始する前に検証を実行します。 | /etc/hosts および /etc/fstab のエントリを検証します。
本番システムに /sapmnt/<SID>/ をマウントします。 DR システム /sapmnt/<SID>/ と同期していることを確認します。 <sid>adm ユーザーにログインして R3trans -d を実行し、trans.log ファイルの出力を確認します。trans.log ファイルが R3trans -d コマンドを実行した同じ場所に生成されます。
| AWS 管理者、SAP基本管理者 |
SAP アプリケーションを起動します。 | <sid>adm ユーザーを使用して本番システムでSAPアプリケーションを起動します。次のコードを使用します。 XX はSAPASCSサーバーのインスタンス番号を表し、 は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し、 SICK および SM51トランザクションを使用してチェックを実行します。
| SAP 基本管理者 |
トラブルシューティング
問題 | ソリューション |
---|
HADR関連の問題をトラブルシューティングするための主要なログファイルとコマンド | |
SAP Db2 HADRの問題のトラブルシューティングに関する注意事項 UDB | SAP 「注 1154013 - DB6: HADR環境の DB の問題」を参照してください。(このノートにアクセスするにはSAPポータル認証情報が必要です)。 |
関連リソース
追加情報
このパターンを使用すると、Db2 データベースで実行されている システムのディザスタリカバリSAPシステムをセットアップできます。ディザスタの状況では、ビジネスは、定義された目標復旧時間 (RTO) と目標復旧時点 (RPO) の要件の範囲内で継続できる必要があります。
FAQs に関連する についてはHADR、SAPDb2 高可用性ディザスタリカバリ (HADR) FAQの注意 #1612105 - DB6: を参照してください。(このノートにアクセスするにはSAPポータル認証情報が必要です)。