この章では、Oracle Fusion Middlewareのバックアップおよびリカバリの概要(Oracle Fusion Middlewareコンポーネントに関するバックアップおよびリカバリの推奨事項を含む)について説明します。
内容は次のとおりです。
An Oracle Fusion Middleware環境は、様々なコンポーネントおよび構成で成り立ちます。通常のOracle Fusion Middleware環境は、Oracle SOA SuiteなどのJavaコンポーネントが含まれるOracle WebLogic Serverドメイン、およびIdentity Managementコンポーネントが含まれるWebLogic Serverドメインで構成されます。
Oracle Fusion Middleware環境内のインストールでは、構成情報、アプリケーションおよびデータの同期が保たれ、相互に依存します。たとえば、構成を変更すると、構成ファイル内の情報が更新されます。アプリケーションをデプロイすると、ドメインまたはクラスタ内のすべての管理対象サーバーへのデプロイが必要な場合があります。
したがって、バックアップおよびリカバリを実行するときは、Oracle Fusion Middleware全体の環境を考慮することが重要になります。Oracle Fusion Middleware環境全体を一度に、その後定期的にバックアップしてください。そうすれば、ファイルやデータなどが失われた場合でも、環境を一貫性のある状態にリストアできます。
次の各項目では、バックアップとリカバリを理解するために重要な概念について説明します。
関連項目: Oracle WebLogic Serverドメイン、管理サーバー、管理対象サーバーとクラスタ、およびノード・マネージャの概念の詳細は、『Oracle Fusion Middlewareコンセプトの理解』を参照してください。 |
管理サーバーで発生した障害が、ドメイン内の管理対象サーバーの操作に影響を与えることはありませんが、管理者がドメインの構成を変更できなくなります。管理サーバーのホスト・コンピュータ上のハードウェアまたはソフトウェアの障害が原因で管理サーバーに障害が発生した場合は、同じコンピュータ上のその他のサーバー・インスタンスが同様に影響を受けることがあります。
管理対象サーバー・インスタンス(クラスタ化されているものも、そうでないものも)が実行されている場合に、そのドメインの管理サーバーが使用できなくなっても、管理対象サーバーは継続して実行されます。周期的に、これらの管理対象サーバーは管理サーバーへの再接続を試みます。クラスタ化された管理対象サーバー・インスタンスでは、ドメイン構成でサポートされているロード・バランシングおよびフェイルオーバーの機能を引き続き使用できます。
管理対象サーバーを初めて起動する場合は、管理サーバーに接続して構成のコピーを取得する必要があります。これで、管理サーバーが実行されていない場合でも、管理対象サーバーを起動できます。この場合、管理対象サーバーでは、起動構成用にドメインの構成ファイルのローカル・コピーが使用され、周期的に管理サーバーとの接続が試行されます。管理サーバーに接続されると、管理対象サーバーの構成状態が管理サーバーの構成状態に同期されます。
管理対象サーバーでは、ドメイン構成のローカル・コピーが保持されます。管理対象サーバーは、起動時に管理サーバーに接続し、管理対象サーバーが前回停止してからドメイン構成に変更が行われた場合は、その変更を取得します。管理対象サーバーが起動時に管理サーバーに接続できない場合は、ローカルにキャッシュされている構成情報を使用できます。これは、管理対象サーバーが前回停止した時点での構成です。管理サーバーに接続して構成の更新を確認できずに起動した管理対象サーバーは、管理対象サーバーの独立(MSI)モードで実行されます。デフォルトでは、MSIモードが有効になっています。ただし、初めて起動する場合は、管理サーバーが停止しているとキャッシュされた構成を使用できないため、管理対象サーバーはMSIモードでも起動できません。
構成の変更は、次の場合に管理対象サーバーで更新されます。
管理対象サーバーが再起動するたびに、管理サーバーから最新の構成が取得されます。これは、その管理対象サーバーが実行されているノードのノード・マネージャが停止している場合でも行われます。管理対象サーバーの再起動時に管理サーバーが使用できない場合、およびMSI(管理対象サーバーの独立)モードが管理対象サーバーで有効になっている場合は、管理対象サーバーは構成のローカル・コピーを読み取って起動し、管理サーバーが使用可能になったときに管理サーバーと同期します。デフォルトでは、MSIモードが有効になっています。
構成の変更、アプリケーションのデプロイまたは再デプロイ、トポロジの変更など、管理上の変更がアクティブ化されるたびに、管理サーバーから管理対象サーバーに最新の構成がプッシュされます。管理対象サーバーが実行されていない場合は、管理対象サーバーが起動したときに、管理サーバーから管理対象サーバーに最新バージョンの構成がプッシュされます。
次に、Oracle Fusion Middleware Infrastructureをインストールした場合のOracle Fusion Middlewareのディレクトリ構造の簡易ビューを示します。
Oracle Fusion Middleware環境のバックアップまたはリカバリに使用できるものは、次のとおりです。
copy、xcopy、tar、jarなどのファイル・コピー用ユーティリティ。ユーティリティでは、次のことを確認してください。
シンボリック・リンクが保持されること
長いファイル名がサポートされること
ファイルの権限、タイムスタンプおよび所有権が保持されること
ファイルをバックアップおよびリストアする場合は、それに適したツールを使用します。次に例を示します。
Windowsでのオンライン・バックアップおよびリカバリには、copyまたはxcopyを使用し、オフライン・バックアップおよびリカバリには、copy、xcopyまたはjarを使用します。長いファイル名や拡張子には対応していないため、Winzipは使用しないでください。
一部のバージョンのWindowsでは、ファイル名が256文字を超えていると失敗します。この問題が発生しないようにするには、次のスイッチを指定したxcopyコマンドを使用できます。
xcopy /s/e "C:\Temp\*.*" "C:\copy"
構文と制限の詳細は、xcopyのヘルプを参照してください。
LinuxおよびUNIXの場合はtarを使用します。
長期間バックアップを保持する場合は、たとえばOracle Secure Backupを使用して、テープにバックアップできます。
Oracle Fusion Middlewareで使用されるデータベース・ベースのメタデータ・リポジトリとすべてのデータベースのバックアップまたはリカバリに使用するOracle Recovery Manager (RMAN)。RMANでは、全体バックアップまたは増分バックアップを実行できます。RMANを使用したデータベースのバックアップおよびリカバリの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
構成ファイルのバックアップ・コピーを作成するようにOracle WebLogic Serverを構成することもできます。これによって、構成の変更を元に戻す必要がある場合や、ほとんど可能性はなくとも構成ファイルが破損した場合のリカバリが簡単になります。管理サーバーの起動時に、構成ファイルを格納したconfig-booted.jarという名前の.jarファイルが保存されます。構成ファイルを変更した場合、変更前のファイルは、ドメイン・ディレクトリの下のconfigArchiveディレクトリに、config-1.jarなどの続き番号が付けられた.jarファイルとして保存されます。ただし、構成アーカイブは常に、管理サーバー・ホストのローカルとして保存されます。アーカイブは外部の場所にバックアップすることをお薦めします。
表16-1では、各Oracle Fusion Middlewareコンポーネントにおいて、バックアップおよびリカバリする必要がある項目について説明します。次の点に注意してください。
コンポーネントに、表に示されているデータベースへの依存性が存在する場合は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』の説明に従い、RMANを使用してデータベースのバックアップおよびリカバリを実行します。
バックアップの場合は、第17.3項の説明に従って、表に示されているエンティティをバックアップします。
リカバリの場合は、失敗した項目に応じて、第18章の説明に従って、次の項目をリカバリする必要があります。
ドメイン: 一部のコンポーネントでは、WebLogic Serverドメイン(第18.2.2項を参照)またはスタンドアロン・ドメイン(第18.2.3項を参照)のいずれか
管理サーバーの構成: 第18.2.4項を参照
管理対象サーバー: 第18.2.5項を参照
クラスタ: 第18.2.7項を参照
アプリケーション: 第18.2.8項を参照
ホストの破損後には、次のリカバリが必要になることがあります。
表16-1では、Oracle Fusion Middlewareコンポーネントでのバックアップとリカバリの推奨事項について説明します。
表16-1 バックアップとリカバリの推奨事項
コンポーネント | データベースへの依存性 | バックアップに関する推奨事項 | リカバリに関する推奨事項 | 追加情報 |
---|---|---|---|---|
Oracle WebLogic Server |
デフォルトでは、いずれのデータベース・リポジトリにも依存しません。ただし、Oracle WebLogic Serverにデプロイされたアプリケーションでは、データ・ソースとしてデータベースが使用される場合があります。 |
Oracleホームおよび管理サーバー・ドメイン・ディレクトリ |
失敗したエンティティ |
サーバー全体の移行を使用する場合は、第18.2.2.1項を参照してください。 |
Oracle WebLogic Server JMS |
JMSがデータベース・ベースの場合のみ |
Oracleホームおよび管理サーバー・ドメイン・ディレクトリ |
失敗したエンティティ |
第16.4.1項を参照してください。 |
Oracle Web Services Manager |
データベース・ベースのMDSリポジトリを使用する場合は、MDSスキーマ。 |
Oracleホームおよび管理サーバー・ドメイン・ディレクトリ。 Oracle WSMでファイルベースのMDSリポジトリが使用されている場合は、ファイル・コピー・メカニズムを使用してバックアップします。 |
管理対象サーバー Oracle WSMでファイルベースのMDSリポジトリが使用されている場合は、バックアップからリストアします。 |
NA |
Oracle Platform Security Services |
データベース・ベースのOracle Platform Securityリポジトリを使用する場合は、OPSSスキーマ。Oracle Internet Directoryベースのリポジトリを使用する場合は、Oracle Internet Directoryリポジトリ。 |
Oracleホームおよび管理サーバー・ドメイン・ディレクトリ。 Oracle Platform SecurityでOracle Internet Directoryベースのリポジトリを使用する場合は、Oracle Internet Directoryをバックアップします。 |
第18.2.6.1項にリストされているファイル。 |
|
Oracle User Messaging Service |
UMSスキーマ |
Oracleホームおよびドメイン(スタンドアロン・ドメインまたはOracle WebLogic Serverドメインのいずれか)。 |
ドメイン(スタンドアロン・ドメインまたはOracle WebLogic Serverドメインのいずれか) |
第18.3.5.5.1項または第18.3.5.5.2項の説明に従って、構成変更を実行します。 |
Oracle HTTP Server |
なし |
Oracleホームおよびドメイン(スタンドアロン・ドメインまたはOracle WebLogic Serverドメインのいずれか)。 |
管理サーバー・ドメイン・ディレクトリ |
NA |
Oracle SOA Suite |
MDSスキーマおよびSOAINFRAスキーマ |
Oracleホームおよび管理サーバー・ドメイン・ディレクトリ |
失敗したエンティティ |
ホスト破損の詳細は、第18.3.5.4項を参照してください。 データベースのバックアップおよびリカバリの詳細は、第16.4.2項を参照してください。 |
Oracle B2B |
MDSスキーマ |
Oracle B2B構成ファイルに変更が行われた場合は、管理サーバー・ドメイン・ディレクトリ、Oracleホームおよび製品ホーム |
管理対象サーバー |
Xengine.tar.gzファイルの詳細は、第18.2.6.2項を参照してください。 |
Oracle BPEL Process Manager |
MDSスキーマおよびSOAINFRAスキーマ |
Oracleホームおよび管理サーバー・ドメイン・ディレクトリ |
失敗したエンティティ |
データベースのバックアップおよびリカバリの詳細は、第16.4.2項を参照してください。 |
Oracle Business Activity Monitoring |
MDSスキーマおよびSOAINFRAスキーマ |
Oracleホーム、管理サーバー・ドメイン・ディレクトリ、管理対象サーバー・ディレクトリ。 |
障害の程度に応じて、管理対象サーバーとOracleホームのいずれかまたは両方 |
NA |
Oracle Business Process Management |
MDSスキーマ |
管理サーバー・ドメイン・ディレクトリおよびOracle BPEL Process Managerと同じデータ(第16.4.2項を参照)。 |
Oracle BPEL Process Managerと同じデータおよび管理対象サーバー |
NA |
Oracle Business Rules |
MDSスキーマ |
Oracleホームおよび管理サーバー・ドメイン・ディレクトリ |
soa-infraアプリケーションがデプロイされている管理対象サーバー |
NA |
Oracle Managed File Transfer |
MFTスキーマおよびMDSスキーマ |
Oracleホームおよび管理サーバー・ドメイン・ディレクトリ |
失敗したエンティティ |
|
Oracle Service Bus |
レポート機能が有効な場合、Oracle Service Busは、ユーザー指定のスキーマにWLI_QS_REPORT_DATAおよびWLI_QS_REPORT_ATTRIBUTEという2つの表を作成します。 |
Oracleホームおよび管理サーバー・ドメイン・ディレクトリ |
管理対象サーバー |
|
Oracle Mediator |
MDSスキーマおよびSOAINFRAスキーマ |
Oracleホームおよび管理サーバー・ドメイン・ディレクトリ |
soa-infraアプリケーションがデプロイされている管理対象サーバー |
|
Oracle Enterprise Scheduler |
ESSスキーマ |
Oracleホームおよび管理サーバー・ドメイン・ディレクトリ |
失敗したエンティティ |
NA |
Oracle Event Processing |
MDSスキーマ(.cqlxファイルを1つのMARにパッケージ化して格納) |
Oracleホームおよび管理サーバー・ドメイン・ディレクトリ |
管理対象サーバー |
NA |
Oracle Data Integrator |
ODI_REPOスキーマ |
Oracleホーム、Oracle Data Integratorがドメインにインストールされている場合はドメイン、およびスタンドアロン・エージェントがインストールされている各マシンのODI_Oracle_Home/oracledi/agentフォルダ |
管理対象サーバーとOracleホームのいずれかまたは両方。 環境にOracle Data Integratorスタンドアロン・エージェントまたは開発者向けOracle Data Integratorが含まれている場合は、第18.2.1項の説明に従ってOracleホームをリストアします。 環境に管理対象サーバーにデプロイされたOracle Data Integratorが含まれている場合は、第18.2.5項の説明に従って管理対象サーバーをリストアします。 |
ホストの破損からリカバリするには、第18.3.5.6項を参照してください。 |
Oracle Data Service Integrator |
MDSスキーマ |
Oracleホームおよび管理サーバー・ドメイン・ディレクトリ |
管理サーバー・ドメイン |
NA |
ファイル・ベースのJMSを使用している場合は、ストレージのスナップショット技術を使用して一貫性のあるオンライン・バックアップを取ります。または、ファイル・システムのコピーを使用してオフライン・バックアップを実行することもできます。
JMS永続ストアがファイルベースの場合は、バックアップからリカバリします。JMS永続ストアがデータベース・ベースの場合は、必要に応じて、データベースを直近の時点にリカバリします。次の点に注意してください。
JMSデータは常に、できるだけ最新に保つようにします。これを実現するには、データベース・ベースの永続性を確保する場合はOracle Databaseのポイント・イン・タイム・リカバリ機能を使用して直近の時間にリカバリするか、またはSAN/NASなど可用性の高いRAID対応ストレージ・デバイスを使用します。
ファイル・ベースのJMSを使用している場合は、ストレージのスナップショットを使用してリカバリできます。
どのような理由であれ、JMSデータを前の時点にリストアする必要がある場合、リストアによって影響が及ぶ可能性があります。システムの状態を前の時点にリストアすると、メッセージを複製する可能性だけでなく、メッセージを失う可能性もあります。この場合に失われたメッセージは、システムのリストア時点の前または後にエンキューされていた未処理のメッセージです。
重複メッセージを処理しないようにするには、リカバリの前に次の手順を実行して、永続ストアのリカバリ後にJMSキュー内のメッセージを排出する必要があります。
注意: メッセージを排出および破棄する前に、保存の必要なデータがメッセージに含まれていないことを確認してください。リカバリしたメッセージには、処理済の重複メッセージの他に、重要なアプリケーション・データが含まれる未処理のメッセージが含まれている可能性があります。 |
Oracle WebLogic Server管理コンソールにログインします。
新しいメッセージが生成されたり宛先に挿入されたりしないように、また失効したメッセージを排出する前に宛先から消費されないようにするため、リカバリの前に、起動時の生成、挿入、消費の各操作を休止するようにJMSサーバーを構成します。これを行うには:
「サービス」を開いてから「メッセージング」を開き、「JMSサーバー」をクリックします。
「JMSサーバー」ページの「サマリー」で、メッセージを休止するように構成するJMSサーバーをクリックします。
「構成: 全般」ページで「詳細」をクリックして、メッセージの休止オプションを定義します。「起動時に挿入を休止」、「起動時に生成を休止」および「起動時に消費を休止」を選択します。
「保存」をクリックします。
リカバリ後に実行する手順は次のとおりです。
永続ストアのリカバリ後に、管理対象サーバーを起動します。
次の手順を実行して、失効したメッセージをJMS宛先から排出します。
「サービス」を開いてから「メッセージング」を開き、「JMSモジュール」を開きます。
JMSモジュールを選択して、ターゲットを選択します。
「モニタリング」を選択して、「メッセージの表示」を選択します。
「すべて削除」をクリックします。
次の手順を実行して、操作を再開します。
「サービス」を開いてから「メッセージング」を開き、「JMSサーバー」を開きます。
「JMSサーバー」ページの「サマリー」で、メッセージを休止するように構成するJMSサーバーをクリックします。
「構成: 全般」ページで「詳細」をクリックします。「起動時に挿入を休止」、「起動時に生成を休止」および「起動時に消費を休止」を選択解除します。
「保存」をクリックします。
永続ストアがJMS専用でない場合は、Oracle WebLogic Server JMSメッセージ管理ツールを使用します。このツールでは、操作のインポート、エクスポート、移動および削除を、管理コンソール、MBeanおよびWLSTから実行できます。
キューイングの他に、パブリッシュおよびサブスクライブも使用するアプリケーションの場合は、キューに加えてトピック・サブスクリプションを操作する必要があります。
グローバル・フォルト・ポリシー、ワークフローのコールバック・クラス、スーツケースの外部にある可能性のあるリソース・バンドルに対する変更など、構成に変更があった場合はその変更後にデータベースをバックアップします。また、データベースは、新しいコンポジットのデプロイまたはコンポジットの再デプロイの後にもバックアップします。
必要に応じて、データベースを直近の時点にリカバリします。ポイント・イン・タイム・リカバリを使用すると、最新のプロセス定義および進行中のインスタンスがリストアされます。ただし、これによってプロセスの手順が再実行される場合があります。できるかぎり、Oracle BPEL Process Managerの冪等プロセスを使用することをお薦めします。冪等以外のプロセスがシステムに含まれている場合は、それらをデハイドレーション・ストアからクリーンアップしてからOracle Fusion Middlewareを起動する必要があります。詳細は、Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理を参照してください。
インスタンスでは、プロセス定義とアーティファクトがすべてデータベースから取得されるため、データベースを最新の状態にリカバリした後で構成をリカバリする必要はありません。インスタンスは、引き続き正常に機能します。
再デプロイしたコンポジットの場合、データベースのリカバリによって、デハイドレーションされた進行中のプロセスとそれに対応する定義との整合性が確保されます。これは、デハイドレーションされたインスタンスも格納されているデータベース・リポジトリにプロセス定義が格納されているためです。
次の前提と制限は、このマニュアルに記載されているバックアップおよびリカバリ手順に適用されます。第17.2項に一覧表示されている制限も参照してください。
バックアップおよびリカバリの操作は、製品をインストールするユーザーまたはOracle Fusion Middlewareがインストールされているディレクトリへのアクセス権限を持つユーザーのみが実行可能である必要があります。
1つの管理対象サーバーと管理サーバーが別々のホスト上で実行されていて、その管理対象サーバーがクラスタに属していない場合、管理対象サーバーでpackコマンドおよびunpackコマンドを使用して、適切な構成を取得する必要があります。
関連項目: Cold Failover ClusterまたはDisaster Recoveryを使用している場合、詳細は、Disaster Recoveryガイドを参照してください。 |