Oracle Data Guard (Fast-Start Failover)とSAP NetWeaver – 高可用性設計とソリューション

はじめに

多くのSAPのお客様はまだオンプレミス環境で、OracleデータベースとさまざまなOS (IBM AIX、HP-UX、Red Hat Enterprise Linux / SUSE Linux Enterprise Server)の組み合わせで、ミッションクリティカルなSAPワークロードを稼働しています。お客様のクラウド導入のジャーニーの課題は、クラウドTCO（総所有コスト）削減のメリットをすぐに得るように、Oracleベースのワークロードを「リフト＆シフト」というアプローチでそのまま移行することです。お客様はこのアプローチを選択し、2027年以降の長期的なSAP戦略を決定するまでの暫定的なステップとするパターンがよくあります。

移行準備の間によくある質問は、「AWSクラウドでOracleデータベースを高可用性構成にするにはどうしたらよいか」ということです。答えは、Amazon Web Services (AWS)では、Oracleネイティブとサードパーティソのリューションに分けられた複数のオプションがあります。

1. Oracle Data Guard
2. SIOS Life Keeper
3. Veritas Infoscale

オンプレミスでは、Oracleのワークロードを高可用性に構成するための典型的なアプローチは、「共有ストレージソリューション」とネットワークフェイルオーバー用の仮想IPに依存しており、これらはすべて独自のハードウェアベンダーのツールの下で管理されています。

このブログでは、AWS上でプライマリからスタンバイへのフェイルオーバーを完全に自動化したOracle Data Guard Fast Start Failover (FSFO)機能が搭載された、Oracleネイティブのデータベース高可用性ソリューションであるOracle Data Guardについてご紹介します。

注：このシナリオは、Oracle Database release 12.1.0.2.0とOracle Enterprise Linux OL7.9-x86_64でテストされています。オペレーティングシステムとデータベースの必要な組み合わせは、SAP社のPAM (Product Availability Matrix)を参照して選択することができます。Oracle Database 18c (18.5.0以上) または 19c (19.5.0以上) を必要とする SAP NetWeaver (7.0x ～ 7.5) 製品は、Oracle Enterprise Linux (OEL) 6.4 以上で稼働する必要があります。これはSAPノート105047に従って、Oracle Clientを必要とするデータベースとアプリケーションサーバーの両方にも適用されます（SAPノートを読むには、SAP ONE Support Launchpadに接続できる有効なSユーザーが必要です）。

アーキテクチャ図

アーキテクチャのコンポーネントの概要説明

• プライマリノード：Data Guardを構成するには、プライマリノードの役割を果たす1つの本番用データベース（プライマリデータベースとも呼ばれる）が含まれます。これは、すべてのアプリケーションサーバからアクセスされるデータベースです。
• スタンバイノード：スタンバイデータベースは、プライマリデータベー スのトランザクションレベルで一貫したコピーです。プライマリデータベースに障害が発生した場合、スタンバイデータベースがプライマリデータベースに昇格します。
• オブザーバーノード：OCI (Oracle Client Interface)であるクライアント側の独立したコンポーネントで、プライマリデータベースやスタンバイデータベースとは別のサーバー上で動作し、プライマリデータベースの可用性を監視します。

このブログでは、Fast Start Failoverとオブザーバーノードを備えたOracle Data Guard (DG)の構築方法に焦点を当て、SAPアプリケーションレイヤーの部分については触れません。同じOracle Data Guardソリューションは、分散型または高可用性型のインストールに関わらず、すべてのSAPアプリケーションシナリオに利用できます。また、Linux環境でOracle Data Guardを使用した場合のコスト面でのメリットについては一部カバーします。

アプリケーションレイヤーでは、アプリケーションサーバーを2つ以上のアベイラビリティーゾーン(AZ)に分散して配置するというベストプラクティスに従うことをお勧めします。データベース(DB)レイヤーでは、AZ障害時の高可用性を確保するために、プライマリノードとスタンバイノードを2つの異なるAZに配置し、オブザーバーノードを3つ目のAZに配置する必要があります。各AZは完全に隔離されており、低遅延ネットワークで接続されています。1つのDBインスタンスに障害が発生した場合、フェイルオーバー後の別のAZにあるインスタンスが、障害が発生したインスタンスのリクエストを処理します。

Oracle Data Guardソリューションでは、SAP NetWeaverベースのアプリケーション向けに、リージョン内のAWS AZを跨いで高可用性(HA)クラスタを展開することができます。Data Guardは、これらのスタンバイデータベースを、本番データベースのトランザクションレベルで一貫したコピーとして維持します。そして、計画的または非計画的な障害により本番データベースが利用できなくなった場合、Oracle Data Guardはスタンバイデータベースの役割をプライマリに切り替えることができ、障害に伴うダウンタイムを最小限に抑えることができます。

インシデントやネットワーク損失によってプライマリデータベースがダウンした場合、Fast Start Failover (FSFO)はスタンバイデータベースへの自動フェイルオーバーを可能にします。オブザーバープロセスは、ネットワークの接続性とデータベースの可用性を監視するために使用されます。オブザーバーは、プライマリデータベースやスタンバイデータベースとは別のサーバー上で動作し、プライマリデータベースの可用性を監視する、独立したOCIクライアントサイドコンポーネントです。万が一、両方のAZで障害が発生した場合に備えて、オブザーバーノードを別のAZ（プライマリおよびスタンバイのOracleノードとは別の場所）に設置することをお勧めします。

前提条件

コンピューティング

Fast Start FailoverによるOracleデータベースのHAソリューションを構成するには、3つのノードが必要です。

1. 2つのノードは、Oracleデータベースのプライマリおよびスタンバイノードとして動作します。
2. Auto Scalingグループ（リージョン内のすべてのAZで最小数1、最大数1、希望キャパシティ1との設定）内の3番目のノードは、オブザーバーノードとして動作し、高可用クラスタのOracle Data Guard構成の作成、メンテナンス、監視を一元で管理します。オブザーバーノードはこのドキュメントのセクション「オブザーバーノードのセットアップ」の手順を使用して、起動テンプレートAMIを構築します。

推奨サイズ

* これはあくまでも一例です。インスタンスサイズはお客様のOracle DBサイズに合わせてください。

ストレージ

下記はOracle向けて、オンプレミスからAWSへのAmazon Elastic Block Store (Amazon EBS)の割り当てに関する推奨事項です。オンプレミスからAWSへの既存SAPワークロードの同機種間または異機種間移行を検討している場合は、適宜調整する必要があります。

データベースから最高のパフォーマンスを得るために、データベースが必要とするIOPSとスループットを提供するようにストレージ層を設定する必要があります。これはAmazon Elastic Compute Cloud (Amazon EC2)上で動作するOracleデータベースの要件です。ストレージレイヤーはデータベースのワークロードをサポートするのに十分なIOPSを提供していない場合、データベースのパフォーマンスが低くなり、トランザクションのバックログが発生します。しかし、データベースが実際に必要とするよりもはるかに高いIOPSをプロビジョニングした場合、未使用のキャパシティが出てきます。

Oracle のワークロードをオンプレミスから AWS に移行する場合、データベースに必要な実際の IOPS を見積もる最適な方法は、一定期間にわたってシステムテーブルにクエリを実行し、既存のデータベースのピーク時の IOPS 使用量を調べることです。これを行うには、一定期間のIOPSを測定し、最も高い値を選択します。データベースのパフォーマンス情報を提供する Oracleデータベースの特別なビューである GV$SYSSTAT ダイナミックパフォーマンスビューから、この情報を得ることができます。

ほとんどの Oracleデータベースワークロードでは、汎用 (SSD) ボリューム (GP3) で十分です。GP3 が提供できる以上の IOPS とスループットが必要な場合は、Provisioned IOPS (PIOPS)が最適です。PIOPS は、Nitro ベースのインスタンスではボリュームあたり最大 64,000 IOPS、その他のインスタンスファミリーではボリュームあたり 32,000 IOPS を提供できます。EBSのスループットを向上させ、ディスク破損のリスクを回避するために、LVMの論理ボリュームをストライピングで使用し、REDOログファイルを複数のディスクに分散させて管理します。

EBSのスループットを向上させ、最適なコストで最高のパフォーマンスを実現するために、ストライピング付きのLVM (Logical Volume Manager)を使用する点を含めて、ディスクレイアウトの設計については、Oracle向けの推奨事項に記載されています。Oracleデータベースは読み取り/書き込み操作にディスクストレージを多用するため、Amazon Elastic Block Store (Amazon EBS)に最適化されたインスタンスのみを使用することを強く推奨します。Amazon EBSに最適化されたインスタンスは、Amazon EC2とAmazon EBSの間に専用のスループットを提供します。ストレージサブシステム向けの帯域幅とスループットはデータベースパフォーマンスに非常に重要です。また、複数のディスクにREDOログファイルを分散させることで、ディスク破損によるリスクを軽減することができます。

ストレージの推奨レイアウトとサイズ

* これはあくまでも一例です。インスタンスサイズはお客様のOracle DBサイズに合わせてください。

Elastic File Systems (EFS)

プライマリおよびスタンバイデータベースノードの両方にも、/sapmnt/<SID>と/usr/sap/trans/の二つのAmazon Elastic File Systemsを追加でマウントします。これらのファイルシステムのサイズは、開発システムと本番システムが異なり、完全にシステムの使用状況に依存します。

ソリューション導入

インフラ構築

複数のAZを使用し、高可用性構成のOracleデータベースノードをデプロイします。AWSアベイラビリティーゾーン (AZ)は他のAZと物理的に何キロも離れていますが、低遅延のネットワーク接続の確保、データベースの同期レプリケーションのサポート、また、高可用性の要件を満たすために、すべてのAZは100km（60マイル）以内にあります。Oracle Data Guardをセットアップする際の主な要件は、Oracle Data Guardを動作させるためにプライマリとスタンバイの両方のデータベースホストが同一であることです。これは以下のことを意味します。

1. 両ホストのOracle Enterprise Linuxのパッチレベルとカーネルが同じであること
2. データベースとオペレーティングシステムのパラメータ設定が同じであること（例：nfiles）
3. Oracle Enterprise Linux 6.4以上のバージョンでは、ファイアウォールがデフォルトで有効になっており、通信のためにはデータベースとオブザーバーのノードで無効にする必要がある
4. 両ホストで、同一のOracleバージョン、同一のデータベースパッチセットレベルを使用することが推奨される
5. 同一のファイルシステム構造であること（特にSAP dataとOracle homeについて）
6. データベースはARCHIVELOGモードで運用する必要がある
7. サーバパラメータファイル(SPFILE)を使用する
8. 「SAP ONE Support Launchpad」へのアクセスが必要である

SAP 環境での Oracle Data Guard に関する詳細情報について、SAPノート105047 をご参照ください。

プライマリノードとスタンバイノードへのデータベースのインストール

SAP Marketplaceから下記のソフトウェアをダウンロードします。（ダウンロードには認証情報が必要です）

1. 最新パッチレベルのSoftware Provisioning Manager 1.0 (SWPM)
2. SAP Netweaver 7.5 DVD (必須バージョン)
3. ORACLE 12.1 64-BIT RDBMS
4. ORACLE 12.1.0.2 Client
5. 最新の SAP Kernel
6. SAP Host Agent
7. SAPCAR

分散化または高可用性(HA)構成で SAP システムをデプロイする最初のステップは、ABAP セントラルサービスインスタンス(ASCS)をインストールすることです。これが完了したら、データベースのインストールに進みます。その後、Primary Application Server instance (PAS)のインストールを行います。

プライマリDBノードでは、SWPM を使用して Oracle 12.1 64-bit RDBMS on Linux on x86_64 64bit のインストールを完了します。スタンバイノードでは、Oracle バイナリをインストールするだけで、残りのデータベースと REDO ログファイルは Oracle Standby セットアッププロセスで作成されます。

詳細情報について、SAPノート1915301 – Database Software 12c Installation on UNIXをご参照ください。

スタンバイノードの設定とプライマリノードとの同期

スタンバイノードを設定するには様々な方法があります。最も簡単で推奨される方法は、Oracle Recovery Manager (RMAN) を使用することです。スタンバイDBは、本番DBのOFFLINEまたはONLINEバックアップから作成することができます。リストアのために、Amazon Simple Storage Service（Amazon S3）を利用して、データベースのバックアップを取ることができます。

Oracle Help Centerの手順に従って、環境変数の設定、スタンバイログファイルの追加、フラッシュバックの有効化など、スタンバイノードの設定を行います。両方のデータベースノードが通信可能であることを確認し、tnspingコマンドで接続性を検証します。

Oracle Data Guard Fast-Start Failover (FSFO)の設定

この時点では、プライマリデータベースとスタンバイデータベースができましたので、それらを管理するためにData Guardブローカーを設定する必要があります。Data Guardコマンドラインインターフェイス（DGMGRL）を使用すると、Data Guardブローカーの設定を管理することができます。Oracle Data Guardで保護モードを設定する際には、いくつかのオプションがあります。以下をご参照ください。

「Max Availability Mode」機能を使用し、Fast-Start Failoverを設定します。手順は以下の通りです。

1. Data Guardブローカーを設定します。まず、プライマリDBを開き、スタンバイDBをマウントします。dg_broker_startをTRUEに設定して、両方のDBノードのDMONプロセス（Data Guard Monitor）をアクティブにします。スタンバイDBのリスナーが開始され、SQL*Netでデータベースにアクセスできることを確認します。
   DG_BROKER PROCESS を両方のDBノードでも開始します。
   SQL> ALTER SYSTEM SET dg_broker_start=true;
System altered.
2. プライマリDBサーバーで、下記のコマンドを実行し、dgmgrlにログインします。
   dbprnode3:oraab3 44> dgmgrl sys/"Password"@AB3
DGMGRL for Linux: Version 12.1.0.2.0 - 64bit Production
Copyright (c) 2000, 2013, Oracle. All rights reserved.
Welcome to DGMGRL, type "help" for information.
Connected as SYSDBA.
3. プライマリDBサーバーで、下記のコマンドを実行し、プライマリDBサーバーをブローカーに登録します。
   DGMGRL> create configuration my_dg_config_1 AS PRIMARY DATABASE IS AB3 CONNECT IDENTIFIER IS AB3;
Configuration "my_dg_config_1" created with primary database "ab3"
DGMGRL>
4. スタンバイDBを追加します。下記のコマンドはどのノードでも実行できます。
   DGMGRL> ADD DATABASE AB3_STBY AS CONNECT IDENTIFIER IS AB3_STBY MAINTAINED AS PHYSICAL;
Database "ab3_stby" added
DGMGRL>
5. 両方のノードも登録したうえ、設定を有効化します。
   DGMGRL> ENABLE CONFIGURATION;
Enabled.
DGMGRL>
6. 下記のコマンドで設定を確認します。
   DGMGRL> SHOW CONFIGURATION;
Configuration - my_dg_config_1
Protection Mode: MaxPerformance
Members:
ab3 - Primary database
ab3_stby - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS (status updated 23 seconds ago)
7. デフォルトでは、Max Performance保護モードが有効になっていますが、後にMax Availabilityに変更する必要があります。オブザーバーノードのセットアップ後に、この設定をMax Availabilityに変更し、オブザーバーノードのセットアップの一部として含めることができます。ブローカーからスタンバイDBの状態を確認します。（設定が有効になっていれば、どのノードからでも下記のコメントを実行できます）。
   DGMGRL> show database AB3_STBY
Database - ab3_stby
Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Transport Lag: 0 seconds (computed 1 second ago)
Apply Lag: 0 seconds (computed 1 second ago)
Average Apply Rate: 1.00 KByte/s
Real Time Query: OFF
Instance(s): AB3
Database Status:
SUCCESS
8. ブローカーからプライマリデータベースの状態を確認します。
   DGMGRL> show database AB3
Database - ab3
Role: PRIMARY
Intended State: TRANSPORT-ON
Instance(s): AB3
Database Status:
SUCCESS

注：スタンバイノードでは、データベースのマウントのみを行い、いつでもオープンできる状態ではないことです。リスナーは両方のノードでも稼動する必要があります。

FSFOおよび他のパラメータ設定を有効にする前に、構成を検証するために、データベースをプライマリノードからスタンバイノードに、またはその逆に手動で切り替えることができるかを確認してください。

SAPインスタンスをデータベースに再接続する

フェイルオーバーや災害後に SAP インスタンスを Oracle データベースに接続するには、さまざまな方法があります。データベーストリガーを作成することで、データベースのサービス起動時に、データベースレベルのロールを変更するということをお勧めします。これにより、フェイルオーバーや災害時に SAP プロファイルや SQL*Net プロファイルの変更を回避することができます。

データベーストリガを作成し、以下のコマンドを実行します。

SQL> !more /home/oraab3/cre_trig1.sql
create trigger my_sap_trig1 after startup on database
declare
v_role varchar(30);
begin
select database_role into v_role from v$database;
if v_role = 'PRIMARY' then
DBMS_SERVICE.START_SERVICE('AB3-HA1');
else
DBMS_SERVICE.STOP_SERVICE('AB3-HA1');
end if;
end;
/

SQL> connect /as sysdba;
Connected.

SQL> @/home/oraab3/cre_trig1.sql

Trigger created.

注：StaticConnectIdentifierパラメータがプライマリとスタンバイの両方のデータベースノードのlistener.oraファイルに正しく反映されていることを確認してください。異なる静的記述子プロパティを使用するためで、DGMGRLコマンドを使用して設定および検証することができます。

DGMGRL> edit database 'AB3' set property
staticconnectidentifier='(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=dbprnode3)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=AB3_DGMGRL)(INSTANCE_NAME=AB3)(SERVER=DEDICATED)))';

DGMGRL> edit database 'AB3_STBY' set property
staticconnectidentifier='(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=dbprnode4)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=AB3_STBY_DGMGRL)(INSTANCE_NAME=AB3)(SERVER=DEDICATED)))';

DGMGRL> show database AB3_STBY StaticConnectIdentifier
StaticConnectIdentifier = '(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=dbprnode4)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=AB3_STBY_DGMGRL)(INSTANCE_NAME=AB3)(SERVER=DEDICATED)))'

両方のノードのlistener.oraファイルで、データベースとオブザーバーに下記のSID_DESCエントリを推奨しています。リスナーの再起動後は、これらのエントリを検証してください。

オブザーバーノードの設定

このセクションでは、オブザーバーノードの設定を行い、プライマリノードとスタンバイノードの両方もオブザーバーノード経由で管理できることを検証します。

1. 同じOracle Enterprise Linuxイメージ (OL7.9-x86_64-HVM-2020-12-07)を使用してオブザーバーノードをセットアップし、Oracleクライアント(Oracle 12.1.0.2 Client)をインストールします。
2. オブザーバーノードにユーザー名「observer」を追加します。
3. プライマリノードからオブザーバーノードのsqlnet.ora、tnsnames.oraと環境変数を調整します。
   setenv PATH /oracle/AB3/121/bin:/usr/lib64/qt-3.3/bin:/usr/local/bin:/bin:/usr/sbin:/usr/local/sbin
setenv DB_SID AB3
setenv dbms_type ORA
setenv dbs_ora_tnsname AB3
setenv ORACLE_SID AB3
setenv ORACLE_HOME /oracle/AB3/121
setenv ORACLE_BASE /oracle/AB3
setenv NLS_LANG AMERICAN_AMERICA.UTF8
setenv LD_LIBRARY_PATH $ORACLE_HOME/lib
setenv TNS_ADMIN $ORACLE_HOME/network/admin
4. tnspingコマンドで、プライマリノードとスタンバイノードの両方にpingできるはずです。
   [observer@dbprnobs1 ~]$ tnsping AB3
TNS Ping Utility for Linux: Version 12.1.0.2.0 - Production on 11-APR-2021 11:11:34
Copyright (c) 1997, 2014, Oracle. All rights reserved.
Used parameter files:
/oracle/AB3/121/network/admin/sqlnet.ora
Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP) (HOST = dbprnode3) (PORT = 1521))) (CONNECT_DATA = (SID = AB3) (GLOBAL_NAME = AB3.WORLD)))
OK (0 msec)
[observer@dbprnobs1 ~]$ tnsping AB3_STBY
TNS Ping Utility for Linux: Version 12.1.0.2.0 - Production on 11-APR-2021 11:11:29
Copyright (c) 1997, 2014, Oracle. All rights reserved.
Used parameter files:
/oracle/AB3/121/network/admin/sqlnet.ora
Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP) (HOST = dbprnode4) (PORT = 1521))) (CONNECT_DATA = (SID = AB3) (GLOBAL_NAME = AB3.WORLD)))
OK (0 msec)
5. 保護モードを変更します。まず、保護モードを確認します。
   SQL> SELECT PROTECTION_MODE, PROTECTION_LEVEL FROM V$DATABASE;
PROTECTION_MODE PROTECTION_LEVEL
-------------------- --------------------
MAXIMUM PERFORMANCE MAXIMUM PERFORMANCE
DGMGRL> EDIT DATABASE ab3 SET PROPERTY LogXptMode='SYNC';
Property "logxptmode" updated
DGMGRL> EDIT DATABASE ab3_stby SET PROPERTY LogXptMode='SYNC';
Property "logxptmode" updated
   その後、構成の保護モードをMax Availability Protectionに変更します。
   次、保護レベルが変更されたかを確認します。
   SQL> SELECT PROTECTION_MODE, PROTECTION_LEVEL FROM V$DATABASE;
PROTECTION_MODE PROTECTION_LEVEL
-------------------- --------------------
MAXIMUM AVAILABILITY MAXIMUM AVAILABILITY
6. Data Guardのプロパティ：スタンバイノードにログを適用するために、「REDO適用の遅延」を2分に設定します（データベースの要件に応じて適宜調整できます）。
   DGMGRL> EDIT DATABASE AB3 SET PROPERTY DelayMins='2';
DGMGRL> EDIT DATABASE AB3_STBY SET PROPERTY DelayMins='2';
7. Fast-Start Failoverを設定します。FastStartFailoverTargetプロパティでターゲットとなるスタンバイデータベースを指定し、FSFOターゲットとしてプライマリとスタンバイを指定します。
   DGMGRL> EDIT DATABASE ab3 SET PROPERTY FastStartFailoverTarget = 'ab3_stby';
Property "faststartfailovertarget" updated
DGMGRL> EDIT DATABASE ab3_stby SET PROPERTY FastStartFailoverTarget = 'ab3';
Property "faststartfailovertarget" updated
DGMGRL>
8. FastStartFailoverThresholdプロパティを設定します。このプロパティは、フェイルオーバーの時間を管理します。デフォルトでは30秒に設定されていますが、別の値に設定するとデフォルトが上書きされ、DBAがカウントダウンを停止できる期間が長くなります。
   DGMGRL> EDIT CONFIGURATION SET PROPERTY FastStartFailoverThreshold = 600;
Property "faststartfailoverthreshold" updated
9. DGMGRLとオブザーバーを起動します。すべてのセットアップが完了したら、プライマリノードまたはスタンバイノードからこれらのコマンドを発行することができます。
   [observer@dbprnobs1 ~]$ dgmgrl sys/PASSWORD@AB3
DGMGRL for Linux: Version 12.1.0.2.0 - 64bit ProductionCopyright (c) 2000, 2013, Oracle. All rights reserved.Welcome to DGMGRL, type "help" for information.
Connected as SYSDBA.
DGMGRL>DGMGRL> connect sys@AB3
Password:
Connected as SYSDBA.
DGMGRL> START OBSERVER;
Observer started
10. オブザーバーのプロセスを（バックグラウンドで）起動したり停止したりするには、以下のコマンドを推奨します。
    [observer@dbprnobs1 ~]$ dgmgrl -logfile observer.log sys/Password@AB3 "start observer" & 5666
[observer@dbprnobs1 ~]$ dgmgrl -logfile observer.log sys/Password@AB3 "stop observer"
11. Fast-Start Failoverを有効にします。Fast-Startフェイルオーバーを有効にする前に、プライマリノードとスタンバイノードの両方でフラッシュバックがオンになっていることを確認してください。
    DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;
Succeeded.
DGMGRL>DGMGRL> EDIT CONFIGURATION SET PROPERTY FastStartFailoverThreshold = 3600;
Property "faststartfailoverthreshold" updated
DGMGRL>DGMGRL> ENABLE FAST_START FAILOVER;
Enabled.DGMGRL> show fast_start failover
Fast-Start Failover: ENABLED
Threshold: 3600 seconds
Target: ab3_stby
Observer: dbprnobs1
Lag Limit: 30 seconds (not in use)
Shutdown Primary: TRUE
Auto-reinstate: TRUE
Observer Reconnect: (none)
Observer Override: FALSEConfigurable Failover Conditions
Health Conditions:
Corrupted Controlfile YES
Corrupted Dictionary YES
Inaccessible Logfile NO
Stuck Archiver NO
Datafile Offline YESOracle Error Conditions:
(none)

ソリューションのテスト

ミッションクリティカルなSAPアプリケーションの稼動前には、稼働即応性(Operational readiness)が重要な意味を持ちます。ソリューションアーキテクトとして、本番稼動前にアプリケーションがRTOおよびRPOの要件を満たしていることを確認する必要があります。

お勧めのアプローチは、SAPアプリケーションレベルのテストとともに、プライマリノードからスタンバイノードへのフェイルオーバーによって、以下のシナリオを検証することです。

Data Guard モニタープロセス (DMON) は、ブローカーが管理するすべてのデータベースインスタンスで実行される Oracle のバックグラウンドプロセスです。Data Guard ブローカーを起動すると、DMON プロセスが作成され、ブローカー構成の健全性を監視し、データベース構成の一貫性を確保します。

プライマリDBのノードがディスク障害やその他のネットワーク障害によりダウンした場合、プライマリDBはクエリに利用できなくなり、SAPワークプロセスは「再接続」モードでスタンバイノード上でデータベースが再び立ち上がるのを待ちます。データベースがスタンバイノード上に移動すると、SAPワークプロセスはスタンバイデータベースに再接続し、通常の操作を再開することができます。これは、オブザーバーが手動で介入することなくノード間でデータベースを移動できることを証明しています。

最初に手動でフェイルオーバーをテストすることもお勧めします。以下のコマンドを使用し、双方向の切り替えのようなフェイルオーバーシナリオを検証することができます。

DGMGRL> switchover to ab3_stby;
Performing switchover NOW, please wait...
Operation requires a connection to instance "AB3" on database "ab3_stby"
Connecting to instance "AB3"...
Connected as SYSDBA.
New primary database "ab3_stby" is opening...
Operation requires start up of instance "AB3" on database "ab3"
Starting instance "AB3"...
ORACLE instance started.
Database mounted.
Switchover succeeded, new primary is "ab3_stby"
DGMGRL>

AWS上のOracle Enterprise Linuxへ移行する複数オプションの利点と注意点

まとめ

このブログでは、SAPアプリケーション向け、オブザーバーノード付きのOracle Data Guardを使用することで、Fast-Start Failoverオプションが有効化されたOracleデータベースのネイティブHAソリューションをAWS上で構築する方法を紹介しました。SAPから取得したOracleランタイムライセンスがあれば、Fast-Start Failoverオプション付きのOracle Data Guardをセットアップして使用することができますが、SAPはFast-Start Failoverコンポーネントのサポートを提供しませんのでご注意ください。Fast-Start FailoverコンポーネントにもOracleのサポートが必要な場合は、Oracleから直接サポート契約を結ぶ必要があります。

5000を超えるSAPのお客様がAWSを選択し、SAPをAWS上で稼働する理由について、https://thinkwithwp.com/jp/sap_japan/をご覧ください。

翻訳はSpecialist SA アッシュが担当しました。原文はこちらです。