データベース制御、ZFSストレージおよびZFS分析を示すスクリプトについて説明します。
この付録の内容は次のとおりです。
Oracle Site Guardにバンドルされているスクリプトです。
次のスクリプトはOracle Site Guardにバンドルされています。
OVM (Oracle Virtual Machine)デプロイメントに対して障害時リカバリ操作を実行するためのスクリプトです。
サイト・ガードには、OVMバージョン3.3.xまたは3.4.xを使用するOVMデプロイメントに対して障害時リカバリ操作を実行するためのsiteguard_ovm_control.py
スクリプトがバンドルされています。Oracle Fusion MiddlewareおよびOracle Fusion ApplicationsがOVMゲスト内にデプロイされたデプロイメント環境では、ミドルウェアおよびアプリケーションに対する障害時リカバリだけでなく、仮想マシン・ゲストの障害時リカバリも容易に実行できます。これは、ミドルウェアおよびアプリケーションが実行されているVMゲストもプライマリ・サイトからスタンバイ・サイトに再配置されることを意味します。
注意:
Oracle Databaseの障害時リカバリにはOVM DRの使用を避けることをお薦めします。Oracle Databaseの障害時リカバリでは、Active Data Guardを使用してデータベースを保護してください。siteguard_ovm_control.pyの構成
siteguard_ovm_control.py
スクリプトは、Oracle Virtual Machineデプロイメントに対する障害時リカバリ操作のすべてのステージで使用する多目的スクリプトです。スクリプトに渡すオプションおよびパラメータは、DR操作の特定のステージに応じて異なります。
siteguard_ovm_control.py
スクリプトは、後述の使用方法の項の例に示すように、OVM DR操作のステージに応じて、それぞれ該当するオプションを使用してサイト・ガードのカスタム事前チェック・スクリプト、前処理スクリプトまたは後処理スクリプトとして構成します。
カスタム事前チェック・スクリプト
start_precheckまたはstop_precheckオプションを使用してカスタム事前チェック・スクリプトとして構成したスクリプトでは、DR操作の一環としてOVMゲストを起動または停止できるかどうかを確認するための事前チェックが実行されます。
前スクリプト
start_prepareまたはstartオプションを使用して前処理スクリプトとして構成したスクリプトでは、OVMリポジトリが準備され、スタンバイ・サイトのOVMゲストが起動されます。
後スクリプト
stopまたはstop_cleanupオプションを使用して後処理スクリプトとして構成したスクリプトでは、OVMゲストが停止され、プライマリ・サイトのOVMリポジトリがクリーンアップされます。
操作の順序
事前チェック・フェーズ
カスタム事前チェック・プライマリ・サイト(stop_precheckオプション)
カスタム事前チェック・スタンバイ・サイト(start_precheckオプション)
プライマリ・サイトでの後処理スクリプト・フェーズ
後処理スクリプト・プライマリ・サイト(stopオプション)
後処理スクリプト・プライマリ・サイト(start_cleanupオプション)
スタンバイ・サイトでの前処理スクリプト・フェーズ
前処理スクリプト・スタンバイ・サイト(start_prepareオプション)
前処理スクリプト・スタンバイ・サイト(startオプション)
使用方法
python siteguard_ovm_control.py --action <action> --uri <uri> --pool <pool_name> --vm <vm_list> --repo <repo_list> --cert <cert_path> --signed <signed_cert_path> [--force] [--nocert]
これは、サイト・ガードOVM障害時リカバリ操作のトップレベル・エントリ・ポイントです。このスクリプトは、サイト・ガード操作計画を介して起動することも、スタンドアロン・モードのスクリプトとして実行することもできます。
ゲストVMのリストに対してstop_precheckアクションを指定すると、指定したすべてのVMがプライマリ・サイトに存在し、停止できるかどうかを確認するためのサイト・ガード事前チェックが実行されます。注意: 指定したゲストVMが実際に停止されるわけではありません。
ゲストVMのリストに対してstopアクションを指定すると、すべてのゲストVMが停止されます。一般に、別のサイトへのスイッチオーバーの一環としてプライマリ・サイトのゲストVMを停止する場合に、これを実行します。
ゲストVMのリストに対してstart_precheckアクションを指定すると、スタンバイ・サイトのすべてのゲストVMを起動できるかどうかを確認するためのサイト・ガード事前チェックが実行されます。注意: ゲストVMが実際に起動されるわけではありません。
リポジトリのリストに対してstart_prepareアクションを指定すると、ゲストVMの起動操作の準備が行われます。一般に、スイッチオーバーまたはフェイルオーバー操作でスタンバイ・サイトを起動する場合に、事前にこれを実行します。
ゲストVMのリストに対してstartアクションを指定すると、指定したサーバー・プールにすべてのゲストVMが割り当てられ、VMが起動されます。一般に、スイッチオーバーまたはフェイルオーバー操作でスタンバイ・サイトのゲストVMを起動する場合に、start_prepareの後にこれを実行します。
注意:
start_prepare (またはstart)アクションで--force
オプションを指定すると、リポジトリの所有権が強制的に取得されます(または、指定したゲストVMが起動されます)。一般に、プライマリ・サイトで何が発生したかに関係なく、フェイルオーバー操作でスタンバイ・サイトのゲストVMを強制的に起動する場合に、これを実行します。これが必要になるのは、プライマリ・サイトにアクセスできず、プライマリ・サイトのゲストVMが正常に停止されていない可能性があるためです。
オプション
-h、--help
ヘルプ・メッセージを表示して終了します。
-a ACTION、--action=ACTION
障害時リカバリのアクションとして<start | stop | start_prepare | stop_cleanup | start_precheck | start_prepare_precheck | stop_precheck | stop_cleanup_precheck>を実行します。
必須引数。デフォルト値: <該当なし>。
例: --action start_precheck
。
-f、--force
指定したアクションを強制的に実行します。不整合を無視し、指定したアクションを強制的に実行します。フェイルオーバー時に、スタンバイ・サイトの指定したリポジトリのゲストVMを強制的に起動するために使用できます。プライマリ・サイトにアクセスできず、ゲストVMを正常に停止できない場合は、このようにする必要があることがあります。このフラグは、startアクションにのみ適用されます。他のアクションでは無視されます。
オプション引数。デフォルト値: OFF (--forceは使用されません)。
例: --force
-u URI、--uri=URI
ポート番号を含むOVMマネージャのURI。
必須引数。デフォルト値: <該当なし>。
例: -uri https://ovmm.mycompany.com:7002
-r "Repository Name(s)"、--repo="Repository Name(s)"
アクションを実行する1つ以上のリポジトリのリスト。複数のリポジトリを指定する場合は、それらのリポジトリ名をカンマで区切ります。リポジトリは指定した順序で処理されます。
必須引数。デフォルト値: <該当なし>。
例: --repo "SiteA Repo Prod CRM (NAS), SiteA Repo Prod ERP (SAN), SiteA Repo Prod IDM DB (NAS)"
-v "Ordered list of VMs"、--vm="Ordered list of VMs
アクションを実行するVM (およびそれに含まれるリポジトリ)の順序付きリスト。指定したVMは指定した順序で処理されます。VMとそのリポジトリは、:文字を使用して区切る必要があります。複数のVM:リポジトリ・ペアを指定する場合は、それらのペアをカンマで区切ります。リポジトリ内のすべてのVMを指定するには、*文字をワイルドカードとして使用します。
必須引数。デフォルト値: <該当なし>。
例: --vm "*:SiteA Repo Prod CRM DB (SAN), Mid-Tier VM1:SiteA Repo Prod CRM MT (NAS), Mid-Tier VM2:SiteA Repo Prod CRM MT (NAS), *:SiteA Repo Prod IDM DB (NAS)"
-p "Pool Name"、--pool="Pool Name
アクションを実行するサーバー・プール名。startアクションを指定した場合、この引数は必須です。そうでない場合は、無視されます。
条件付き必須引数。デフォルト値: <該当なし>。
例: --pool "My Primary Pool"
-c /path/to/unsigned_certificate、--cert=/path/to/unsigned_certificate
署名なし公開SSL証明書(PEM)のパス。
オプション引数。デフォルト値: <該当なし>
例: --cert /opt/ovmdr/cert/my-unsigned-cert.pem
-s /path/to/signed_certificate、--signed=/path/to/signed_certificate
署名付きOVM SSL証明書(PEM)を格納するパス。
オプション引数。デフォルト値: <該当なし>
例: --signed /opt/ovmdr/cert/ovm-signed-cert.pem
-n、--nocert
証明書を使用しません。警告を非表示にします。
オプション引数。デフォルト値: OFF (--nocert
は使用されません)。
例: --signed /opt/ovmdr/cert/ovm-signed-cert.pem
使用例
例1
siteguard_ovm_control.py --action stop_precheck --uri https://primovmm.mycompany.com:7002 --vm "*:SiteA Repo Prod CRM (NAS), *:SiteA Repo Prod ERP (SAN)" --cert /opt/ovmdr/cert/my-cert.pem --signed /opt/ovmdr/cert/my-signed-cert.pem
例2
siteguard_ovm_control.py --action start_prepare --force --uri https://stbyovmm.mycompany.com:7002 --repo "SiteA Repo Prod CRM (NAS), SiteA Repo Prod ERP (SAN)" --pool "Standby Server Pool Denver" --nocert
例3
siteguard_ovm_control.py --action start --force --uri https://stbyovmm.mycompany.com:7002 --vm "RAC DB VM1:SiteA Repo Prod CRM (NAS), RAC DB VM2:SiteA Repo Prod CRM (NAS), *:SiteA Repo Prod ERP (SAN)" --nocert
例4
siteguard_ovm_control.py --action stop --uri https://primovmm.mycompany.com:7002 --vm "Mid-Tier VM1:SiteA Repo Prod CRM (NAS), Mid-Tier VM2:SiteA Repo Prod CRM (NAS), *:SiteA Repo Prod CRM (NAS), *:SiteA Repo Prod ERP (SAN)" --nocert
例5
siteguard_ovm_control.py --action stop_cleanup --uri https://primovmm.mycompany.com:7002 --repo "SiteA Repo Prod CRM (NAS), SiteA Repo Prod ERP (SAN)" --nocert
注意:
このスクリプトの実行場所として構成されているホストでスクリプトを実際に実行するためには、次のインストール前提条件を満たす必要があります。
python Requestモジュール(バージョン2.5.1)をインストールする必要があります。http://docs.python-requests.org/en/master/を参照してください。
このpythonインタープリタの正確なパスを確実に使用するために、次のように、スクリプト構成の一部として正しいpythonインストールのパスを指定してください。
/home/oracle/python2.6/bin/python siteguard_ovm_control.py {options]
OVMデプロイメントに対して障害時リカバリ操作を実行するためのスクリプトです。
OVMバージョン3.2.xを使用するOVMデプロイメントに対して障害時リカバリ操作を実行するためのスクリプトです。これらのOVMデプロイメントに対する障害時リカバリは、サイト・ガードOVM DRスクリプトのCLIバージョンを使用して管理できます。Oracle Fusion MiddlewareおよびOracle Fusion ApplicationsがOVMゲスト内にデプロイされたデプロイメント環境では、ミドルウェアおよびアプリケーションに対する障害時リカバリだけでなく、仮想マシン・ゲストの障害時リカバリも容易に実行できます。これは、ミドルウェアおよびアプリケーションが実行されているVMゲストもプライマリ・サイトからスタンバイ・サイトに再配置されることを意味します。
注意:
Oracle Databaseの障害時リカバリにはOVM DRの使用を避けることをお薦めします。Oracle Databaseの障害時リカバリでは、Active Data Guardを使用してデータベースを保護してください。siteguard_ovmcli_control.pyの構成
siteguard_ovmcli_control.py
スクリプトは、Oracle Virtual Machineデプロイメントに対する障害時リカバリ操作のすべてのステージで使用する多目的スクリプトです。スクリプトに渡すオプションおよびパラメータは、DR操作の特定のステージに応じて異なります。
siteguard_ovmcli_control.py
スクリプトは、後述の使用方法の項の例に示すように、OVM DR操作のステージに応じて、それぞれ該当するオプションを使用してサイト・ガードのカスタム事前チェック・スクリプト、前処理スクリプトまたは後処理スクリプトとして構成します。
カスタム事前チェック・スクリプト
start_precheckまたはstop_precheckオプションを使用してカスタム事前チェック・スクリプトとして構成したスクリプトでは、DR操作の一環としてOVMゲストを起動または停止できるかどうかを確認するための事前チェックが実行されます。
前スクリプト
start_prepareまたはstartオプションを使用して前処理スクリプトとして構成したスクリプトでは、OVMリポジトリが準備され、スタンバイ・サイトのOVMゲストが起動されます。
後スクリプト
stopまたはstop_cleanupオプションを使用して後処理スクリプトとして構成したスクリプトでは、OVMゲストが停止され、プライマリ・サイトのOVMリポジトリがクリーンアップされます。
操作の順序
事前チェック・フェーズ
カスタム事前チェック・プライマリ・サイト(stop_precheckオプション)
カスタム事前チェック・スタンバイ・サイト(start_precheckオプション)
プライマリ・サイトでの後処理スクリプト・フェーズ
後処理スクリプト・プライマリ・サイト(stopオプション)
後処理スクリプト・プライマリ・サイト(start_cleanupオプション)
スタンバイ・サイトでの前処理スクリプト・フェーズ
前処理スクリプト・スタンバイ・サイト(start_prepareオプション)
前処理スクリプト・スタンバイ・サイト(startオプション)
使用方法
python siteguard_ovmcli_control.py --action <action> --host <host> --port <port> --pool <pool_name> --vm <vm_list> --repo <repo_list> [--force]
これは、サイト・ガードOVM障害時リカバリ操作用のスクリプトです。このスクリプトは、サイト・ガード操作計画を介して起動することも、スタンドアロン・モードのスクリプトとして実行することもできます。
ゲストVMのリストに対してstop_precheckアクションを指定すると、指定したすべてのVMがプライマリ・サイトに存在し、停止できるかどうかを確認するためのサイト・ガード事前チェックが実行されます。注意: 指定したゲストVMが実際に停止されるわけではありません。
ゲストVMのリストに対してstopアクションを指定すると、すべてのゲストVMが停止されます。一般に、別のサイトへのスイッチオーバーの一環としてプライマリ・サイトのゲストVMを停止する場合に、これを実行します。
リポジトリのリストに対してstop_cleanupアクションを指定すると、(stopアクションを使用して)すべてのゲストVMを停止した後に、プライマリ・サイトがクリーンアップされます。一般に、別のサイトへのスイッチオーバーの一環としてプライマリ・サイトの評価を終了する場合に、これを実行します。
ゲストVMのリストに対してstart_precheckアクションを指定すると、スタンバイ・サイトのすべてのゲストVMを起動できるかどうかを確認するためのサイト・ガード事前チェックが実行されます。注意: ゲストVMが実際に起動されるわけではありません。
リポジトリのリストに対してstart_prepareアクションを指定すると、ゲストVMの起動操作の準備が行われます。一般に、スイッチオーバーまたはフェイルオーバー操作でスタンバイ・サイトを起動する場合に、事前にこれを実行します。
ゲストVMのリストに対してstartアクションを指定すると、指定したサーバー・プールにすべてのゲストVMが割り当てられ、VMが起動されます。一般に、スイッチオーバーまたはフェイルオーバー操作でスタンバイ・サイトのゲストVMを起動する場合に、start_prepareの後にこれを実行します。
注意:
start_prepare (またはstart)アクションで--force
オプションを指定すると、リポジトリの所有権が強制的に取得されます(または、指定したゲストVMが起動されます)。一般に、プライマリ・サイトで何が発生したかに関係なく、フェイルオーバー操作でスタンバイ・サイトのゲストVMを強制的に起動する場合に、これを実行します。これが必要になるのは、プライマリ・サイトにアクセスできず、プライマリ・サイトのゲストVMが正常に停止されていない可能性があるためです。
オプション
-h、--help
ヘルプ・メッセージを表示して終了します。
-a ACTION、--action=ACTION
障害時リカバリのアクションとして<start | stop | start_prepare | stop_cleanup | start_precheck | start_prepare_precheck | stop_precheck | stop_cleanup_precheck>を実行します。
必須引数。デフォルト値: <該当なし>。
例: --action start_precheck
。
-f、--force
指定したアクションを強制的に実行します。不整合を無視し、指定したアクションを強制的に実行します。フェイルオーバー時に、スタンバイ・サイトの指定したリポジトリのゲストVMを強制的に起動するために使用できます。プライマリ・サイトにアクセスできず、ゲストVMを正常に停止できない場合は、このようにする必要があることがあります。このフラグは、startアクションにのみ適用されます。他のアクションでは無視されます。
オプション引数。デフォルト値: OFF (--forceは使用されません)。
例: --force
-h、--host=HOST
SSH接続で接続先として使用するOVMマネージャ・ホスト
タイプ: オプション引数。デフォルト値: localhost。
例: --host ovmm.mycompany.com
-p、--port=PORT
OVMマネージャ・ホスト上の接続先SSHポート番号(--hostオプションを参照)。
タイプ: オプション引数。デフォルト値: 10000
例: --port 10000
-r "Repository Name(s)"、--repo="Repository Name(s)"
アクションを実行する1つ以上のリポジトリ(およびそれに含まれるストレージ・サーバーとストレージ・タイプ)のリスト。リポジトリ名、ストレージ・サーバー名およびストレージ・サーバー・タイプは、:文字を使用して区切る必要があります。リポジトリ名には、<repo_name>:<storage_server_name>:<storage_type>という形式を使用する必要があります。ストレージ・タイプは、nfs、iscsiまたはfcpのいずれかにする必要があります。複数のリポジトリを指定する場合は、それらのリポジトリ名をカンマで区切ります。リポジトリは指定した順序で処理されます。
必須引数。デフォルト値: <該当なし>。
例: --repo "SiteA-Repo1:SAN-Server-X:iscsi, SiteA-Repo2:SAN-Server-Y:fcp, SiteA-Repo3:File-Server-Z:nfs"
-v "Ordered list of VMs"、--vm="Ordered list of VMs
アクションを実行するVM (およびそれに含まれるリポジトリ)の順序付きリスト。指定したVMは指定した順序で処理されます。VMとそのリポジトリは、:文字を使用して区切る必要があります。複数のVM:リポジトリ・ペアを指定する場合は、それらのペアをカンマで区切ります。リポジトリ内のすべてのVMを指定するには、*文字をワイルドカードとして使用します。
必須引数。デフォルト値: <該当なし>。
例: --vm "*:SiteA-Repo-CRM, IDM-VM1:SiteA-Repo-IDM, IDM-VM2:SiteA-Repo-IDM, *:SiteA-Repo-IDM"
-p "Pool Name"、--pool="Pool Name
アクションを実行するサーバー・プール名。startアクションを指定した場合、この引数は必須です。そうでない場合は、無視されます。
条件付き必須引数。デフォルト値: <該当なし>。
例: --pool "My Primary Pool"
使用例
例1
siteguard_ovmcli_control.py --action stop_precheck --vm "*:SiteA-Repo-CRM, *:SiteA-Repo-ERP"
例2
siteguard_ovmcli_control.py --action start_prepare --force --host stbyovmm.mycompany.com --repo "SiteA-Repo-CRM:SAN-Server-100:iscsi, SiteA-Repo-ERP:NFS-Server-200:nfs" --pool "Standby Server Pool Denver"
例3
siteguard_ovmcli_control.py --action start --force --host stbyovmm.mycompany.com --port 11000 --vm "CRM-VM1:SiteA-Repo-CRM, CRM-VM2:SiteA-Repo-CRM, *:SiteA-Repo-ERP"
例4
siteguard_ovmcli_control.py --action stop --vm "CRM-VM1:SiteA-Repo-CRM, CRM-VM2:SiteA-Repo-CRM, *:SiteA-Repo-CRM, *:SiteA-Repo-ERP"
例5
siteguard_ovmcli_control.py --action stop_cleanup --repo "SiteA-Repo-CRM:SAN-Server-100:iscsi, SiteA-Repo-ERP:NFS-Server-200:nfs"
操作計画の前処理フェーズまたは後処理フェーズでカスタムOracle WebLogic Server操作を構成するために使用できるスクリプトです。
以前のバージョンのサイト・ガードでは、Oracle WebLogic Server (WLS)操作をユーザーが直接構成できませんでした。WLS操作は、WLS障害時リカバリが発生した操作計画バケット以外では構成できませんでした。このWLS操作バケットは、サイト・ガードによって操作計画内の固定ポイントに構成され、事前に挿入されていました。
wls_control_wrapper.pl
スクリプトを使用することによってこの問題が解決します。このスクリプトは、バンドルされた(即時利用可能な)スクリプトとして提供されており、操作計画の前処理ステージまたは後処理ステージの任意の場所に独自のカスタムWLS操作を追加および構成するために使用できます。
使用方法
perl wls_control_wrapper.pl --component '<component>' --usecase '<usecase>' --wls_home '<wls_home>' --mw_home '<mw_home>' --oracle_home '<oracle_home>' --domain_name '<domain_name>' --domain_dir '<domain_directory>' --server_name '<server_name>' --server_type '<server_type>' --admin_host '<admin_host>' --admin_port '<admin_port>' --nm_host '<node_manager_host>' --timeout '<3600>'
オプション
--component
操作を実行するコンポーネントのタイプ。サポートされているコンポーネント: ADMIN_SERVER、MANAGED_SERVERおよびCAM_COMPONENT。
--usecase
実行するユースケース。サポートされているユースケース: ADMIN_SERVER_STATUS、ADMIN_SERVER_START、ADMIN_SERVER_STOP、MANAGED_SERVER_STATUS、MANAGED_SERVER_START、MANAGED_SERVER_STOP、CAM_COMPONENT_STATUS、CAM_COMPONENT_STARTおよびCAM_COMPONENT_STOP
--wls_home
WebLogic Serverホーム・ディレクトリ。
--mw_home
Oracle Fusion Middlewareホーム・ディレクトリ。
--oracle_home
WebLogic ServerのORACLE_HOME。
--domain_name
ドメイン名。
--domain_dir
ドメイン・ディレクトリ。
--server_name
WebLogic管理サーバーの名前。
--server_type
WebLogic管理サーバーのタイプ。
--admin_host
WebLogic管理サーバーのホスト。
--admin_port
WebLogic管理サーバーのポート。
--nm_host
ノード・マネージャのホスト。
--help
簡単なヘルプ・メッセージを出力し、終了します。
--usage
使用方法ページを出力し、終了します
--manual
マニュアル・ページを出力し、終了します。
注意:
このスクリプトを前処理スクリプトまたは後処理スクリプトとして構成する場合は、このスクリプトを実行するために使用するperlインタープリタとして、Oracle Enterprise Managerエージェントにバンドルされているperlバイナリを使用する必要があります。このperlインタープリタの正確なパスを確実に使用するために、次のいずれかの方法を使用してください。perlインタープリタのパスとして$PERL_HOME/perl
を使用します。
このスクリプトが実行されるホストにEMエージェントとともにインストールされたperlを探し、/home/oracle/emagent/ agent_13.2.0.0.0/perl/bin/perl
のようにperlインタープリタのパスを明示的に指定します。
操作計画の前処理フェーズまたは後処理フェーズでカスタム・ノード・マネージャ操作を構成するために使用できるスクリプトです。
以前のバージョンのサイト・ガードでは、ノード・マネージャ(NM)操作をユーザーが直接構成できませんでした。NM操作は、NM障害時リカバリが発生した操作計画バケット以外では構成できませんでした。このNM操作バケットは、サイト・ガードによって操作計画内の固定ポイントに構成され、事前に挿入されていました。
nm_control_wrapper.pl
スクリプトを使用することによってこの問題が解決します。このスクリプトは、バンドルされた(即時利用可能な)スクリプトとして提供されており、操作計画の前処理ステージまたは後処理ステージの任意の場所に独自のカスタムNM操作を追加および構成するために使用できます
使用方法
perl nm_control_wrapper.pl --usecase '<usecase>' --wls_home '<wls_home>' --mw_home '<mw_home>' --oracle_home '<oracle_home>' --domain_name '<domain_name>' --domain_dir '<domain_directory>' --nm_host '<node_manager_host>' --timeout '<3600>'
オプション
--usecase
実行するユースケース。サポートされているユースケース: NM_STATUS、NM_STARTおよびNM_STOP。
--wls_home
WebLogic Serverホーム・ディレクトリ。
--mw_home
Middlewareホーム・ディレクトリ
--oracle_home
WebLogic ServerのORACLE_HOME。
--domain_name
ドメイン名
--domain_dir
ドメイン・ディレクトリ
--nm_host
ノード・マネージャのホスト。
--help
簡単なヘルプ・メッセージを出力し、終了します
--usage
使用方法ページを出力し、終了します。
--manual
マニュアル・ページを出力し、終了します。
注意:
このスクリプトを前処理スクリプトまたは後処理スクリプトとして構成する場合は、このスクリプトを実行するために使用するperlインタープリタとして、Oracle Enterprise Managerエージェントにバンドルされているperlバイナリを使用する必要があります。このperlインタープリタの正確なパスを確実に使用するために、次のいずれかの方法を使用してください。perlインタープリタのパスとして$PERL_HOME/perl
を使用します。
このスクリプトが実行されるホストにEMエージェントとともにインストールされたperlを探し、/home/oracle/emagent/ agent_13.2.0.0.0/perl/bin/perl
のようにperlインタープリタのパスを明示的に指定します。
操作計画の前処理フェーズまたは後処理フェーズでカスタム・データベース事前チェックを追加および構成するためにすぐに使用できるスクリプトです。
以前のバージョンのサイト・ガードでは、Oracleデータベース操作をユーザーが直接構成できませんでした。データベース操作は、データベース障害時リカバリが発生した操作計画バケット以外では構成できませんでした。このデータベース操作バケットは、Oracle Site Guardによって操作計画内の固定ポイントに構成され、事前に挿入されていました。
db_control_wrapper.pl
スクリプトを使用することによってこの問題が解決します。
説明
データベースの起動、停止、スイッチオーバー、フェイルオーバー、変換および元に戻す操作を実行し、さらにこれらのユースケースで事前チェックを実行します。
構文
perl db_control_wrapper.pl --usecase <usecase> --oracle_home <oracle_home> --oracle_sid <oracle_sid> --is_rac_database <true/false> --timeout <3600> --target_db <target_db> --target_optional_parameters <target_optional_parameters> --operation_optional_parameters <operation_optional_paramete
パラメータ | 説明 |
---|---|
|
次のいずれか: START、START_PRECHECK、STOP、STOP_PRECHECK、SWITCHOVER、SWITCHOVER_PRECHECK、FAILOVER、FAILOVER_PRECHECK、CONVERT_PHYSICAL_TO_SNAPSHOT_STANDBY、CONVERT_PHYSICAL_TO_SNAPSHOT_STANDBY_PRECHECK、REVERT_SNAPSHOT_TO_PHYSICAL_STANDBY、REVERT_SNAPSHOT_TO_PHYSICAL_STANDBY_PRECHECK |
|
データベースの |
|
データベースの |
|
RACデータベースに対しては |
|
データベース・ロール・リバーサルのポーリング・タイムアウトの時間(秒)。 |
|
ターゲット・データベース名。 |
|
ターゲット・ランタイムのオプション・パラメータ。 オプション: 形式: |
|
ターゲット操作のオプション・パラメータ。 オプション
形式
|
|
簡単なヘルプ・メッセージを出力します。 |
|
簡単な使用方法メッセージを出力します。 |
|
マニュアル・ページを出力します。 |
注意:
このスクリプトを前処理スクリプトまたは後処理スクリプトとして構成する場合は、このスクリプトを実行するために使用するperlインタープリタとして、Enterprise Managerエージェントにバンドルされているperlバイナリを使用する必要があります。このperlインタープリタの正確なパスを確実に使用するために、次のいずれかを行います。perlインタープリタのパスとして$PERL_HOME/perl
を使用します。
このスクリプトが実行されるホストにEMエージェントとともにインストールされたperlを探し、(/home/oracle/emagent/ agent_13.2.0.0.0/perl/bin/perl
のように) perlインタープリタのパスを明示的に指定します。
操作計画のグローバル前処理フェーズ、グローバル後処理フェーズ、前処理フェーズまたは後処理フェーズでZFSストレージ関連の事前チェックを実行するためにすぐに使用できるスクリプトです。
以前のバージョンのサイト・ガードでは、ZFSストレージ・ロール・リバーサル操作をユーザーが操作計画の任意のポイントで直接構成できませんでした。ZFSストレージ関連の操作をユーザーが構成することは可能でしたが、これらの操作を操作計画のどこに挿入するかは構成できませんでした。このストレージ・ロール・リバーサル操作バケットは、常にサイト・ガードによって操作計画内の固定ポイントに事前に挿入されていました。
zfs_storage_role_reversal.sh
スクリプト(以前はストレージ・スクリプトとしてのみ使用可能)を使用することによってこの問題が解決します。
このスクリプトの使用方法の詳細は、「zfs_storage_role_reversal.sh」を参照してください。
ZFSレプリケーション構成でラグを分析およびレポートするためにすぐに使用できるスクリプトです。
このスクリプトでは、レプリケーション・ラグが指定のしきい値(リカバリ・ポイント目標)を超えたときにすべてのオカレンスを分析し、それぞれのオカレンスにおける最大ラグの量とともに出力します。このスクリプトによる分析は、start_time
およびend_time
パラメータで指定した間隔で実行されます。
ZFSレプリケーション構成のヘルスを監視できるように、このスクリプトをデータ収集およびレポート用のスタンドアロン・ツールとして構成することをお薦めします。このスクリプトは、従来のサイト・ガード操作計画でカスタム事前チェック(およびヘルス・チェック)スクリプトとして実行することもできますが、従来の事前チェック・スクリプトを使用する場合と同様に、このスクリプトによって操作計画の失敗をトリガーすることはできません。
スクリプトの使用方法
zfs_analysis.sh [--zfs_appliance <ZFS Appliance>] [--zfs_appliance_user <ZFS Appliance Username>] [--zfs_appliance_password <ZFS Appliance Password>] [--zfs_project_name <ZFS Project Name>] [--start_time <Start Time>] [--end_time <End Time>] [--objective <Replica Objective>] [--cluster_member_file <Cluster Member File>] [--objective_file <Objective File>] [--force <Force analytic start time>] where, --zfs_appliance : [mandatory] ZFS zppliance host --zfs_appliance_user : [mandatory] ZFS zppliance username --zfs_appliance_password : [mandatory] ZFS zppliance password --zfs_project_name : [mandatory] Project name --start_time : [mandatory] Start date/time --end_time : [mandatory] End date/time --objective : [mandatory] Replica lag threshold --cluster_member_file : File that declares a common name to use for the two nodes in each clustered storage appliance --objective_file : File that declares replica lag thresholds for specific replication actions --force : Force the analysis interval to start at the specified date/time
スクリプトをOracle Site Guardカスタム事前チェック・スクリプトとして構成するには、次のようにします。
「ソフトウェア・ライブラリ・エンティティ」フィールドで「ZFS Lag Analysis Scripts」というエンティティを検索して選択します。
次の例に示すように、「スクリプト・パス」を設定します。
sh zfs_analysis.sh --zfs_appliance zfsappl01.mycompany.com --zfs_project_name rproject01 --end_time 2015-07-07 --objective 30m --start_time 2015-07-08
スクリプトを実行するホスト(複数可)を選択します。
「詳細オプション」で、ZFSアプライアンス用の資格証明を選択し、これをパラメータとしてスクリプトに渡すように構成します。
サンプル・スクリプトの出力は次のとおりです。
Action: zfsappl01sn01&zfsappl02sn02:rproject01 Replication of rproject01 from zfsappl01sn01 to zfsappl02sn02(label=zfsappl02sn-fe) during the 10172506 second analysis interval beginning 2015-02-12 06:18:14 UTC and ending 2015-06-10 00:00:00 UTC. Updates are manually initiated. Recovery Point Objective is 1800 seconds (30 minutes). Action UUID (unique identifier) = e1b57778-5e5a-4053-c96b-f5d6e15d3292 | | seconds replication update | at completion, replica lag | spent _______________________________________|____________________________| above started | completed | had grown to | then became | objective ___________________|___________________|______________|_____________|___________ 2015-02-12 06:18:14 2015-02-12 06:18:24 10 10 0 2015-02-12 06:50:21 2015-02-12 06:50:30 1936 9 136 2015-02-12 06:51:45 2015-02-12 06:51:53 92 8 0 2015-02-15 21:10:59 2015-02-15 21:11:19 310774 20 308974 2015-02-15 21:19:32 2015-02-15 21:19:52 533 20 0 2015-02-16 06:17:34 2015-02-16 06:17:43 32291 9 30491 2015-02-16 06:21:36 2015-02-16 06:21:44 250 8 0 2015-02-16 06:25:12 2015-02-16 06:25:23 227 11 0 2015-02-16 06:27:18 2015-02-16 06:27:30 138 12 0 2015-02-16 06:29:23 2015-02-16 06:29:35 137 12 0 2015-02-16 06:32:07 2015-02-16 06:32:19 176 12 0 2015-02-16 06:33:27 2015-02-16 06:33:39 92 12 0 2015-02-16 06:36:07 2015-02-16 06:36:22 175 15 0 2015-02-16 06:40:17 2015-02-16 06:40:35 268 18 0 2015-02-16 07:03:11 2015-02-16 07:03:33 1396 22 0 2015-02-16 07:26:19 2015-02-16 07:26:29 1398 10 0 2015-02-16 07:28:03 2015-02-16 07:28:15 116 12 0 2015-02-17 00:50:24 2015-02-17 00:50:36 62553 12 60753 2015-02-17 00:55:57 2015-02-17 00:56:09 345 12 0 2015-02-17 01:55:01 2015-02-17 01:55:13 3556 12 1756 2015-02-17 04:25:21 2015-02-17 04:25:32 9031 11 7231 2015-02-18 10:22:19 2015-02-18 10:22:31 107830 12 106030 2015-02-18 10:23:31 2015-02-18 10:23:43 84 12 0 2015-02-23 05:02:22 2015-02-23 05:02:34 412743 12 410943 2015-02-23 07:06:26 2015-02-23 07:06:38 7456 12 5656 at end of interval 2015-06-10 00:00:00 9219214 9217414 Replication actions that did not satisfy their Recovery Point Objective at some point during the 10172506 second analysis interval beginning 2015-02-12 06:18:14 UTC and ending 2015-06-10 00:00:00 UTC. replication updates | total | | peak replica lag | _____________________| seconds | |_____________________________| | above | above | | | | total | objective | objective | RPO | seconds | date and time | source&target:project/share ______ |_____________|___________|_____|_________|___________________|_____________________________ 59 48 81% 358352 4% 1800 340318 2015-06-08 17:47:55 zfsappl01sn01&zfsappl02sn02:1_WING 3 2 67% 1493546 15% 1800 994866 2015-06-04 04:28:59 zfsappl01sn01&zfsappl02sn02:2_SG 2 1 50% 1642394 16% 1800 1644194 2015-06-10 00:00:00 zfsappl01sn01&zfsappl02sn02:3_SG 2 1 50% 1642180 16% 1800 1643980 2015-06-10 00:00:00 zfsappl01sn01&zfsappl02sn02:4_SG 3 2 67% 1497621 15% 1800 1203470 2015-06-10 00:00:00 zfsappl01sn01&zfsappl02sn02:5_SG 2 1 50% 6757712 66% 1800 6759512 2015-06-10 00:00:00 zfsappl01sn01&zfsappl02sn02:SiteGuard 13 4 31% 9593787 94% 1800 9219201 2015-06-10 00:00:00 zfsappl01sn01&zfsappl02sn02:br_test 26 10 38% 10149384 100% 1800 9219214 2015-06-10 00:00:00 zfsappl01sn01&zfsappl02sn02:rproject01
マルチサイト・レプリケーション・アクションの中で失効したZFSレプリケーション構成アクションをクリーンアップし、正しく再構成するためにすぐに使用できるスクリプトです。
1つのプライマリ・サイトから2つのスタンバイ(DR)サイトへのZFSレプリケーション・アクションが構成されたマルチサイトDR構成では、プライマリ・サイトから一方のスタンバイ・サイトへのZFSストレージ・ロール・リバーサルを実行すると、もう一方(2つ目)のスタンバイ・サイトが孤立したままになり、最終的にレプリケーション・アクションが失効します。
次の3サイトの例はこの状況を示しています。
DR操作の実行前:
サイトA (プライマリ) → ZFSレプリケーション → サイトB (スタンバイ)
サイトA (プライマリ) → ZFSレプリケーション → サイトC (スタンバイ)
サイトAからサイトBへのスイッチオーバー後の不完全なストレージ・レプリケーション構成:
サイトB (新規プライマリ) → ZFSレプリケーション → サイトA (新規スタンバイ)
サイトB (新規プライマリ) → [レプリケーションなし] → サイトC (スタンバイ)
サイトAからサイトBへのスイッチ後の望ましいストレージ・レプリケーション構成:
サイトB (新規プライマリ) → ZFSレプリケーション → サイトA (新規スタンバイ)
サイトB (新規プライマリ) → ZFSレプリケーション → サイトC (スタンバイ)
sg_zfs_utility.shスクリプトを使用すると、この問題を解決するのに役立ちます。そのためには、通常どおり、zfs_storage_role_reversal.shスクリプトを使用してDRストレージ操作を構成します。これに加え、sg_zfs_utility.shスクリプトをサイト・ガード操作計画の終了時に実行されるグローバル後処理スクリプトとして構成します。sg_zfs_utility.shスクリプトは、失効したレプリケーション・アクションをクリーンアップし、適切に再構成するためのものです。
次の例は、3つのスクリプトを構成して、3サイト・レプリケーション・アクションの中でストレージ・レプリケーション・アクションが正しくリバースおよび再構成されるようにする方法を示しています。
ZFSロール・リバーサル(ストレージ・スクリプト)の構成
sh zfs_storage_role_reversal.sh --source_appliance siteA-zfs.mycompany.com --source_pool_name A_Pool --target_ siteB-zfs.mycompany.com --target_pool_name B_Pool --project_name myproject --is_sync_needed N --continue_on_sync_failure Y --sync_timeout 1800 --operation_type switchover
注意:
さらにsg_zfs_utility.shスクリプトを使用してストレージ・レプリケーションを再構成する場合は、「エラー時に停止」モードを使用してzfs_storage_role_reversal.shスクリプトを構成する必要があります。「エラー時も続行」モードを使用すると、エラーが発生し、障害時リカバリ操作に悪影響を及ぼします。失効したレプリケーション・アクションのZFSクリーンアップ
sh sg_zfs_utility.sh --operation_type CLEANUP_OLD_REPLICATION --project_name myproject --source_appliance siteA-zfs,mycompany.com --source_pool_name A_Pool --target_appliance siteC-zfs.mycompany.com --target_pool_name B_Pool
新規レプリケーション・アクションのZFS再作成
sh sg_zfs_utility.sh --operation_type SETUP_NEW_REPLICATION --project_name myproject --source_appliance siteB-zfs.mycompany.com --source_pool_name B_Pool --target_appliance siteC-zfs.mycompany.com --target_pool_name C_Pool --replication_properties enabled=true|continuous=true|include_snaps=true|max_bandwidth=unlimited|use_ssl=true|target=cAppliance|pool=C_Pool|syncImmediate=true'