翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
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
製品バージョン
アーキテクチャ
ターゲットテクノロジースタック
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 CloudWatch や などのサービスはAWS CloudTrail 、基盤となるインフラストラクチャとAPIオペレーションをそれぞれモニタリングするために使用できます。詳細については、SAPAWS「 - 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) システムコピーメソッドを HA/DR 目的でバックアップ/復元でシステムコピーを使用して DR SAPシステムを構築します。 から求められたらSWPM、本番稼働環境から取得したバックアップを使用して、DR でデータベースを復元します。DR データベースはロールフォワード保留状態になります。
ロールフォワード保留状態は、フルバックアップの復元後にデフォルトで設定されます。ロールフォワード保留状態は、データベースが復元中で、何らかの変更を適用する必要がある可能性があることを示します。詳細については、IBM「 ドキュメント」を参照してください。 | SAP Basis 管理者 |
設定を確認します。 | のログアーカイブを設定するには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 Basis 管理者 |
タスク | 説明 | 必要なスキル |
---|
DR テストの本番ビジネスのダウンタイムを計画します。 | DR フェイルオーバーシナリオをテストするために、必ず本番環境で必要な業務停止時間を計画するようにします。 | SAP Basis 管理者 |
テストユーザーを作成します。 | DR ホストで検証できるテストユーザー (または任意のテスト変更) を作成して、DR フェイルオーバー後のログの複製を確認します。 | SAP Basis 管理者 |
コンソールで、本番EC2稼働インスタンスを停止します。 | このステップでは、ディザスタシナリオを想定して不適切なシャットダウンが開始されます。 | AWS システム管理者 |
DR EC2インスタンスを要件に合わせてスケールアップします。 | EC2 コンソールで、DR リージョンのインスタンスタイプを変更します。 インスタンスを停止:インスタンスが実行中の場合、そのインスタンスを先に停止する必要があります。EC2 コンソールでインスタンスを選択し、停止 を選択します。 インスタンスタイプを変更する: EC2コンソールでインスタンスを選択し、アクション、インスタンス設定、インスタンスタイプの変更 を選択します。プライマリインスタンスと一致するインスタンスタイプを選択し、[適用]を選択します。 インスタンスを開始する: インスタンスタイプの変更が完了したら、インスタンスを選択し、開始 を選択してEC2、コンソールからインスタンスを開始します。 データベースを削除するには、次のコマンドを使用します。 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 アプリケーションを開始する前に検証を実行します。 | /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 は 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
データベースに不一致がなく、connected と peer のステータスではない場合、現在アクティブなデータベース (DR リージョンの host2 )とデータベースを同期(host1 で)するために、バックアップと復元が必要になることがあります。その場合、DB バックアップを host2 DR のリージョンのデータベースから host1 本番リージョンのデータベースに復元します。 | SAP Basis 管理者 |
データベースを本番リージョンにフェイルバックします。 | 通常の business-as-usualシナリオでは、このステップはスケジュールされたダウンタイムで実行されます。DR システムで実行されているアプリケーションが停止され、データベースが本番リージョン (リージョン 1) にフェイルバックされ、本番リージョンからのオペレーションが再開されます。 DR リージョンのSAPアプリケーションサーバーにログインし、SAPアプリケーションを停止します。 DRシステムから /sapmnt/<SID> をアンマウントし、本番システムの /sapmnt/<SID> に変更がリバースレプリケートされることを確認します。 本番リージョンのデータベースサーバー (host1 ) にログインし、テイクオーバーを実行します。 db2 takeover hadr on database <SID>
HADR ステータスを確認します。 は PRIMARY にhost1 、 は StandBy にHADR_ROLE する必要がありますhost2 。 db2pd -d <SID> -hadr
| SAP Basis 管理者 |
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アプリケーションを起動します。次のコードを使用します。 は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
アプリケーションサーバーが使用可能であることを確認するには、 にログインSAPし、 SICK および SM51トランザクションを使用してチェックを実行します。
| SAP Basis 管理者 |
トラブルシューティング
問題 | ソリューション |
---|
HADR関連の問題をトラブルシューティングするための主要なログファイルとコマンド | |
SAP Db2 HADRに関する問題のトラブルシューティングに関する注意事項 UDB | SAP 「注 1154013 - DB6: HADR環境の DB の問題」を参照してください。(このノートにアクセスするにはSAPポータル認証情報が必要です)。 |
関連リソース
追加情報
このパターンを使用すると、Db2 データベースで実行されているSAPシステムのディザスタリカバリシステムをセットアップできます。災害状況では、ビジネスは定義された復旧時間目標 (RTO) および復旧ポイント目標 (RPO) の要件の範囲内で継続できる必要があります。
FAQs に関する詳細についてはHADR、SAPDb2 高可用性ディザスタリカバリ (HADR) FAQの注 #1612105 - DB6: を参照してください。(このノートにアクセスするにはSAPポータル認証情報が必要です)。