プライマリ・コンテンツに移動
Oracle® Site Guard管理者ガイド
13g (13.2.2.0.0)
E92084-01
目次へ移動
目次

前
前へ

B バンドルされたスクリプト

データベース制御、ZFSストレージおよびZFS分析を示すスクリプトについて説明します。

この付録の内容は次のとおりです。

B.1 バンドルされたスクリプト

Oracle Site Guardにバンドルされているスクリプトです。

次のスクリプトはOracle Site Guardにバンドルされています。

B.2 Oracle Virtual Machine (OVM) DRスクリプト - siteguard_ovm_control.py

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リポジトリがクリーンアップされます。

操作の順序

一般的なスイッチオーバー操作では、構成済のスクリプトが操作の一環として次の順序で実行されます。
  1. 事前チェック・フェーズ

    • カスタム事前チェック・プライマリ・サイト(stop_precheckオプション)

    • カスタム事前チェック・スタンバイ・サイト(start_precheckオプション)

  1. プライマリ・サイトでの後処理スクリプト・フェーズ

    • 後処理スクリプト・プライマリ・サイト(stopオプション)

    • 後処理スクリプト・プライマリ・サイト(start_cleanupオプション)

  1. スタンバイ・サイトでの前処理スクリプト・フェーズ

    • 前処理スクリプト・スタンバイ・サイト(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またはリポジトリのリストに対して指定したアクションを実行します。次に例を示します。
  • ゲスト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

プライマリ・サイトでstop_precheckを実行して、リポジトリSiteA Repo Prod CRM (NAS)およびSiteA Repo Prod ERP (SAN)のゲストVMを停止できるかどうかを確認します。OVMサーバーとの通信時には、署名なし証明書/opt/ovmdr/cert/my-cert.pemを使用します。OVMマネージャから受け取った署名付き証明書の保存先として、/opt/ovmdr/cert/my-signed-cert.peファイルを使用します。
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

スタンバイ・サイトのリポジトリSiteA Repo Prod CRM (NAS)およびSiteA Repo Prod ERP (SAN)で、start_prepareを実行します。サーバー・プールStandby Server Pool DenverにすべてのVMを割り当てます。--forceフラグを使用して、これをフェイルオーバー操作の一環として行うように指定します。署名付き、署名なしを問わず証明書は使用せず、証明書関連の警告を非表示にします。
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

スタンバイ・サイトのリポジトリSiteA Repo Prod CRM (NAS)のゲストVMであるRAC DB VM1とRAC DB VM2、そしてリポジトリSiteA Repo Prod ERP (SAN)のすべてのゲストVMで、順番(順序付け)どおりにstartを実行します。--forceフラグを使用して、これをフェイルオーバー操作の一環として行うように指定します。署名付き、署名なしを問わず証明書は使用せず、証明書関連の警告を非表示にします。
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

プライマリ・サイトのリポジトリSiteA Repo Prod CRM (NAS)のゲストVMであるMid-Tier VM1とMid-Tier VM2で、順番(順序付け)どおりにstopを実行します。その後、リポジトリSiteA Repo Prod CRM (NAS)およびSiteA Repo Prod ERP (SAN)の残りすべてのゲストVMを(任意の順序で)停止します。署名付き、署名なしを問わず証明書は使用せず、証明書関連の警告を非表示にします。
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

プライマリ・サイトのリポジトリSiteA Repo Prod CRM (NAS)およびSiteA Repo Prod ERP (SAN)で、stop_cleanupを実行します。署名付き、署名なしを問わず証明書は使用せず、証明書関連の警告を非表示にします。
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]

B.3 Oracle Virtual Machine CLI (OVMCLI) DRスクリプト - siteguard_ovmcli_control.py

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リポジトリがクリーンアップされます。

操作の順序

一般的なスイッチオーバー操作では、構成済のスクリプトが操作の一環として次の順序で実行されます。
  1. 事前チェック・フェーズ

    • カスタム事前チェック・プライマリ・サイト(stop_precheckオプション)

    • カスタム事前チェック・スタンバイ・サイト(start_precheckオプション)

  1. プライマリ・サイトでの後処理スクリプト・フェーズ

    • 後処理スクリプト・プライマリ・サイト(stopオプション)

    • 後処理スクリプト・プライマリ・サイト(start_cleanupオプション)

  1. スタンバイ・サイトでの前処理スクリプト・フェーズ

    • 前処理スクリプト・スタンバイ・サイト(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またはリポジトリのリストに対して指定したアクションを実行します。次に例を示します。
  • ゲスト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

プライマリ・サイトでstop_precheckを実行して、リポジトリSiteA-Repo-CRMおよびSiteA-Repo-ERPのゲストVMを停止できるかどうかを確認します。デフォルト・ポート(10000)を使用してデフォルト・ホスト(localhost)に接続します。
siteguard_ovmcli_control.py 
     --action stop_precheck
     --vm "*:SiteA-Repo-CRM, *:SiteA-Repo-ERP"
  

例2

スタンバイ・サイトのストレージ・サーバーSAN-Server-100のISCCIリポジトリSiteA-Repo-CRM、そしてファイル・サーバーNFS-Server-200のNFSリポジトリSiteA-Repo-ERPで、start_prepareを実行します。サーバー・プールStandby Server Pool DenverにすべてのVMを割り当てます。--forceフラグを使用して、これをフェイルオーバー操作の一環として行うように指定します。デフォルト・ポート(10000)を使用してホストstbyovmm.mycompany.comに接続します。
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

リポジトリSiteA-Repo-CRMのゲストVMであるCRM-VM1とCRM-VM2、そしてリポジトリSiteA-Repo-ERPのすべてのゲストVMで、順番(順序付け)どおりにstartを実行します。--forceフラグを使用して、これをフェイルオーバー操作の一環として行うように指定します。ポート11000を使用してホストstbyovmm.mycompany.comに接続します。
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

プライマリ・サイトのリポジトリSiteA-Repo-CRMのゲストVMであるCRM-VM1とCRM-VM2で、順番(順序付け)どおりにstopを実行します。その後、リポジトリSiteA-Repo-CRMおよびSiteA-Repo-ERPの残りすべてのゲストVMを(任意の順序で)停止します。ホストおよびポートにはデフォルト値を使用します。
siteguard_ovmcli_control.py 
     --action stop
     --vm "CRM-VM1:SiteA-Repo-CRM, CRM-VM2:SiteA-Repo-CRM, *:SiteA-Repo-CRM, *:SiteA-Repo-ERP"
   

例5

プライマリ・サイトのストレージ・サーバーSAN-Server-100のISCCIリポジトリSiteA-Repo-CRM、そしてファイル・サーバーNFS-Server-200のNFSリポジトリSiteA-Repo-ERPで、stop_cleanupを実行します。ホストおよびポートにはデフォルト値を使用します。
siteguard_ovmcli_control.py 
     --action stop_cleanup
     --repo "SiteA-Repo-CRM:SAN-Server-100:iscsi, SiteA-Repo-ERP:NFS-Server-200:nfs"
    

B.4 WebLogic Server制御スクリプト - wls_control_wrapper.pl

操作計画の前処理フェーズまたは後処理フェーズでカスタム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インタープリタのパスを明示的に指定します。

B.5 ノード・マネージャ制御スクリプト - nm_control_wrapper.pl

操作計画の前処理フェーズまたは後処理フェーズでカスタム・ノード・マネージャ操作を構成するために使用できるスクリプトです。

以前のバージョンのサイト・ガードでは、ノード・マネージャ(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インタープリタのパスを明示的に指定します。

B.6 データベース制御スクリプト - db_control_wrapper.pl

操作計画の前処理フェーズまたは後処理フェーズでカスタム・データベース事前チェックを追加および構成するためにすぐに使用できるスクリプトです。

以前のバージョンのサイト・ガードでは、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
パラメータ 説明

--usecase

次のいずれか: 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

--oracle_home

データベースのORACLE_HOME

--oracle_sid

データベースのORACLE_SID

--is_rac_database

RACデータベースに対してはtrueに設定し、RACデータベース以外に対してはfalseに設定します。

--timeout

データベース・ロール・リバーサルのポーリング・タイムアウトの時間(秒)。

--target_db

ターゲット・データベース名。

--target_optional_parameters

ターゲット・ランタイムのオプション・パラメータ。

オプション: apply_lagtransport_lag

形式: 'apply_lag=-1&transport_lag=-1'

--operation_optional_parameters

ターゲット操作のオプション・パラメータ。

オプション

force=<true/false>

enable_trace=<true/false>

immediate_failover=<true/false>

lag_check=<true/false>

形式

'force=false&lag_check=false&enable_trace=false'

--help

簡単なヘルプ・メッセージを出力します。

--usage

簡単な使用方法メッセージを出力します。

--manual

マニュアル・ページを出力します。

注意:

このスクリプトを前処理スクリプトまたは後処理スクリプトとして構成する場合は、このスクリプトを実行するために使用するperlインタープリタとして、Enterprise Managerエージェントにバンドルされているperlバイナリを使用する必要があります。このperlインタープリタの正確なパスを確実に使用するために、次のいずれかを行います。
  • perlインタープリタのパスとして$PERL_HOME/perlを使用します。

  • このスクリプトが実行されるホストにEMエージェントとともにインストールされたperlを探し、(/home/oracle/emagent/ agent_13.2.0.0.0/perl/bin/perlのように) perlインタープリタのパスを明示的に指定します。

B.7 ZFSストレージ・スクリプト - zfs_storage_role_reversal.sh

操作計画のグローバル前処理フェーズ、グローバル後処理フェーズ、前処理フェーズまたは後処理フェーズでZFSストレージ関連の事前チェックを実行するためにすぐに使用できるスクリプトです。

以前のバージョンのサイト・ガードでは、ZFSストレージ・ロール・リバーサル操作をユーザーが操作計画の任意のポイントで直接構成できませんでした。ZFSストレージ関連の操作をユーザーが構成することは可能でしたが、これらの操作を操作計画のどこに挿入するかは構成できませんでした。このストレージ・ロール・リバーサル操作バケットは、常にサイト・ガードによって操作計画内の固定ポイントに事前に挿入されていました。

zfs_storage_role_reversal.shスクリプト(以前はストレージ・スクリプトとしてのみ使用可能)を使用することによってこの問題が解決します。

このスクリプトの使用方法の詳細は、「zfs_storage_role_reversal.sh」を参照してください。

B.8 ZFS分析スクリプト - zfs_analysis.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カスタム事前チェック・スクリプトとして構成するには、次のようにします。

  1. 「ソフトウェア・ライブラリ・エンティティ」フィールドで「ZFS Lag Analysis Scripts」というエンティティを検索して選択します。

  2. 次の例に示すように、「スクリプト・パス」を設定します。

    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
    
  3. スクリプトを実行するホスト(複数可)を選択します。

  4. 「詳細オプション」で、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

B.9 ZFSスタンバイ・サイト・レプリケーション・クリーンアップ・スクリプト - sg_zfs_utility.sh

マルチサイト・レプリケーション・アクションの中で失効した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サイト・レプリケーション・アクションの中でストレージ・レプリケーション・アクションが正しくリバースおよび再構成されるようにする方法を示しています。

  1. 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スクリプトを構成する必要があります。「エラー時も続行」モードを使用すると、エラーが発生し、障害時リカバリ操作に悪影響を及ぼします。
  2. 失効したレプリケーション・アクションの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

  3. 新規レプリケーション・アクションの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'