3 設定の検証

セカンダリ・システムは、特に初期設定後に定期的に検証する必要があります。Fusion Middlewareスタンバイ・データベースをスナップショット・スタンバイに変換することで、完全なスイッチオーバーを実行せずにスタンバイ・サイトを検証できます。これにより、セカンダリのFusion Middlewareサーバーがスタンバイ・サイトで起動されるため、セカンダリのFusion Middlewareシステムが正しく設定されていることを確認できます。セカンダリ・システムのテストは、正常で信頼性の高い障害保護戦略の重要な要素です。

MAAでは、定期的なスイッチオーバー(6か月から9か月ごと)をスケジュールして、セカンダリの信頼できる完全な検証を実行することをお薦めします。これにより、実際の障害状況を想定して業務やチームを準備することもできます。

ただし、企業が現在の本番サイトを停止せずに、完全なスイッチオーバー操作を回避しながらセカンダリ・サイトの定期的なテストを実行して、新しい変更やワークロードなどの動作を検証することを望む場合もあります。ほとんどのFusion Middlewareコンポーネント(主にWebLogic Server)ではデータベースへの書込みアクセス(永続ストアとサービス移行リース用)が必要であるため、これを可能にするには、スタンバイ・データベースをスナップショット・スタンバイに変換する(セカンダリ・データベースを書込み可能にする)必要があります。そうすることで、スタンバイの中間層Fusion Middlewareコンポーネントをセカンダリ・サイトで起動できるようになります。スナップショット・スタンバイ・モードの間にセカンダリ・サイトのデータベースで実行された変更は、フィジカル・スタンバイに戻ると破棄されるため、プライマリ・データはセカンダリ・サイトの検証の影響を受けません。この方法をOracle Data Guardスナップショット・スタンバイとともに使用すると、プライマリ・システムではワークロードの処理を続行でき、セカンダリ・データベースは機能レベルおよびパフォーマンス・レベルでの検証にアクティブに使用されます。セカンダリ・システムをこのように使用することで、本番データベースの最新のコピーを使用しながら、新しいパッチ、新しいバージョンのアプリケーション、インフラストラクチャおよび運用モデルの変更を検証できます。

これらの検証操作を実行する際には注意が必要です。保留中のJMSメッセージ、トランザクションまたは保留中の操作(未完了のSOAコンポジットや障害が発生したビジネス・プロセスなど)がデータベースに存在する場合、データベースがスナップショットに変換されると、スタンバイ・サイトのFusion Middlewareサーバーは起動時にそれらを処理します。スナップショット・スタンバイに変換する際には、Fusion Middlewareコンポーネントに対する保留中のアクションがデータベースに存在しないことを確認する必要があります。存在する場合は、スナップショット・スタンバイ・データベースに変換した後、セカンダリ・サイトのFusion Middlewareサーバーを起動する前に、スタンバイ・データベースのランタイム表(JMS永続ストアやJTA永続ストアなど)からレコードを削除してください。

設定のテスト

  1. 共有ストレージ・レプリケーションを使用して中間層のファイル・システムを同期している場合は、共有ストレージ・ベンダーが提供するクローニング・テクノロジを使用して、セカンダリ・サイトの共有ストレージにセカンダリ・サイトの読取り専用ボリュームのクローンを作成します。クローニングされたセカンダリ・サイトのボリュームが書込み可能であることを確認します。セカンダリ・サイトを1回のみテストする場合、これは1回かぎりのクローン操作にできます。ただし、セカンダリ・サイトを定期的にテストする場合は、セカンダリ・サイトの読取り専用ボリュームを、セカンダリ・サイトの読取りまたは書込みクローン・ボリュームに定期的にクローニングするように設定できます。セカンダリで適宜マウントを変更し、共有ストレージを使用してアクティブ化されたコピーを各ノードにマウントします。

  2. rsyncを使用する場合は、サンプル・スクリプトを使用して、プライマリ・サイトからセカンダリ・サイトへのコンテンツのリフレッシュを実行します。

  3. DBFSを使用する場合は、最新の情報のコピーがOracle Data Guardによってセカンダリに自動的に伝播されます。

  4. 次のステップを実行して、スタンバイ・データベースをスナップショット・スタンバイに変換します。

    1. プライマリ・データベース・ホストでData Guard Brokerを使用して、セカンダリ・データベースをスナップショット・スタンバイに変換します。

      例:

      
[oracle@primarydbhost~]$dgmgrl sys/ your_sys_password@primary_db_unqname
DGMGRL> convert database “secondary_db_unqname” to snapshot standby

    2. dgmgrl show configurationコマンドを使用して、変換が正しく実行されたことを確認します。

  5. セカンダリ環境に保留中のアクションがないことを確認します。スタンバイがスナップショットに変換されたときに保留中のアクション(トランザクション、メッセージ)がプライマリDBに存在する場合、セカンダリFusion Middlewareサーバーは起動時にそれらを処理しようとします。Oracle Fusion Middleware SOAの場合、SOA切捨てスクリプトを使用してセカンダリ・データベースのSOAランタイム表からレコードを削除することで、セカンダリ・サーバーを起動する前にランタイム・データを消去できます。表削除なしでの実行時表からのレコードの削除に関する項を参照してください。

  6. 検証用のホスト名マッピングを構成します。これはスイッチオーバーではなく、プライマリ・サイトがまだアクティブであるため、フロントエンド・アドレスはプライマリ・サイトのLBR IPアドレスに解決され、すべてのブラウザ・アクセスがアクティブなプライマリ・サイトにデフォルトでリダイレクトされるようになります。セカンダリ・サイトのサービスに直接アクセスするには、WLSノードと管理対象クライアント(ラップトップなど)で/etc/hostsファイルを更新してローカル・ホスト名解決を使用し、フロントエンドおよびアクセス・ポイントがセカンダリ・アドレスに解決されるようにします。詳細は、「ホスト名の解決」を参照してください。

    ノート:

    一部のHTTPプロキシは、クライアントの/etc/hostsにある名前に関係なく、プライマリ・サイトのLBR IPアドレスを使用して仮想フロントエンド名を解決し続ける可能性があるため、検証に使用されるクライアントがHTTPプロキシを介してFusion Middlewareシステムにアクセスしないことを確認してください。

    ノート:

    Linux以外のクライアントの場合、カスタマイズしたホスト・ファイル・エントリを使用してブラウザがIPアドレスを解決するには、ローカルDNSキャッシュのリセットが必要になることがあります。

  7. セカンダリ・サイトでWebLogic Serverを起動します。

    1. 次の例に示すように、セカンダリ管理サーバーを起動します。

      
$ cd /u01/app/oracle/middleware/oracle_common/common/bin
$ ./wlst.sh
wlst> nmConnect ('weblogic', 'password','sooahost1','5556','soaedgdomain','/u01/data/domains/soaedgdomain','SSL')
wlst> nmStart('Adminserver')

    2. セカンダリ管理対象サーバーを起動します(セカンダリのWebLogicリモート・コンソールまたはスクリプトを使用します)。

      GitHubにあるMAA提供の起動スクリプトまたは停止スクリプトを使用できます。これらのスクリプトは、より粒度が高く、改善された停止手順を提供します。

      ノート:

      Fusion Middleware SOAの場合、説明に従ってセカンダリ・サイトを検証する際に(完全なスイッチオーバーを実行せずに、スナップショット・スタンバイ・モードでスタンバイをオープンするときに)、「ORA-01403: データが見つかりません ORA-06512」エラーがスタンバイSOAサーバーのログに表示されることがあります。これらのエラーは、SOA自動パージ・ジョブに関連しています。これらのエラーが発生するのは、データベース内のジョブにDBロールの依存関係がある(データベースがプライマリ・ロールの場合にのみ有効になるようにジョブが定義されている)ためです。これは、ジョブが2回(プライマリで1回、スタンバイで1回)実行されるのを防止する、想定どおりの望ましい動作です。SOA自動パージ・ジョブはプライマリ・ロールで定義されているため、データベースがスナップショット・スタンバイ・モードの場合、DBA_SCHEDULER_JOBSビューに表示されません。各ジョブに定義されているdatabase_roleは、ビューDBA_SCHEDULER_JOB_ROLEに表示されます。つまり、これらのエラーは、スタンバイ・システムで発生するかぎり無視しても構いません。SOA自動パージのスケジューラ・ジョブは、インスタンスのロールがプライマリに変更された場合にのみ、DBで実行されます。

      要約すると、各WebLogic Serverを確認して、すべてのアプリケーションおよびサブシステムが正しく起動していることを確かめます。

  8. Fusion Middlewareシステムを検証します。まずWebLogicデータ・ソースをテストし、すべてのアプリケーションがWeblogicリモート・コンソールで実行中の状態であることを確認する必要があります。SOAの場合は、Enteprise Managerテスト・コンポジット・ユーティリティを使用して、特定のビジネス・ロジックが正しく機能することを確認します。データベースに永続化された情報は、DBが再度フィジカル・スタンバイ・モードになると破棄されます。

  9. セカンダリ・サイトでの検証が終了したら、次のステップを実行して、再度スタンバイ・ロールに戻します。

    1. セカンダリの管理対象サーバーおよび管理サーバーを停止します。

      セカンダリのWebLogicリモート・コンソールに接続して、セカンダリ・サイトの管理対象サーバーおよび管理サーバーを停止できます。

    2. スタンバイDBをフィジカル・スタンバイに再度変換します。プライマリDBホストでDG Brokerを使用し、次のようにoracleユーザーとしてセカンダリをフィジカル・スタンバイに再度変換します。

      
[oracle@drdbA ~]$ dgmgrl sys/your_sys_password@primary_db_unqname
DGMGRL> convert database “secondary_db_unqname” to physical standby

      show configurationコマンドを使用して、変換が正しく実行されたことを確認します。

    3. 更新されたクライアントの/etc/hostsファイルを元に戻します。

      クライアントの/etc/hostsファイルでセカンダリ・サイトを指すようにフロントエンド名を更新した場合は、元に戻して、仮想フロントエンド名がプライマリのフロントエンドIPを再度指すようにします。