| Oracle® Fusion Middleware高可用性ガイド 12c (12.1.3.0.0) E56218-02 |
|
 前 |
 次 |
この章では、高可用性環境で共有記憶域を使用する際の推奨事項について説明します。また、複数のホストやサーバーが共有する共通の場所にアーティファクトを配置する利点についても説明します。通常は、この共通の場所を共有ファイル・システムに配置し、NFSやCIFSのような標準のオペレーティング・システム・プロトコルを使用して、各サーバーからマウントします。
一般的に次のようなアーティファクトが共有ファイル・システムに配置されます。
製品バイナリ: 製品の実行可能ファイル、JARファイル、スクリプトに関連するすべてのファイルとディレクトリ(製品のインストール時にインストールされます)
ドメイン・ディレクトリ: WebLogic Serverのドメインとその構成を含むディレクトリ
ファイル・ベースの永続ストア: JMS永続性ログやJTAトランザクション・ログに使用するファイル・ベースの永続ストア
この章には次のトピックが含まれます:
共有記憶域では、動的な状態およびサーバー構成を共有し、管理、構成、フェイルオーバー、バックアップ/リカバリを簡略化できます。
高可用性環境でファイル・ベースの永続ストア(JMSおよびJTAログ用)や特定のOracle製品を使用する場合は、共有記憶域が必要になります。製品バイナリやドメイン・ディレクトリの共有記憶域はオプションです。
共有記憶域の詳細は、表4-1を参照してください。
表4-1 共有記憶域に関する項目
| 項目/タスク | 参照先 |
|---|---|
|
Oracleホームの構造とコンテンツ |
『Oracle Fusion Middleware Oracle Fusion Middleware Infrastructureのインストールと構成』のOracle Fusion Middlewareインフラストラクチャのディレクトリ構造の理解に関する項 |
|
ファイル・ストアへのJMSおよびJTA情報の保存 |
『Oracle WebLogic Serverサーバー環境の構成』のWebLogic永続ストアの使用に関する項(永続ストアの高可用性に関する項) 『Oracle WebLogic Server JMSリソースの管理』の永続ストアの高可用性に関する項 『Oracle WebLogic Serverクラスタの管理』のJTAのデフォルト・ファイル・ストアの可用性に関する項 |
共有記憶域の次の前提条件は、ファイル・ベースの永続ストアを使用するときにのみ適用されます。
障害発生時に適切にリカバリできるようにするため、すべてのノードからアクセスできて、管理対象サーバーで障害が発生した後に操作を再開できる場所に、JMSとJTAトランザクションの両方のログを格納する必要があります。この設定には、複数のノードから参照できる共有記憶域の場所が必要です。推奨のディレクトリ構造については、第4.6項「ディレクトリ構造と構成」を参照してください。
共有記憶域のデバイスには、ネットワーク接続ストレージ(NAS)またはストレージ・エリア・ネットワーク(SAN)の使用をお薦めします。
NFSマウント・システムを使用する場合は、ファイルのロックに関連する問題および突然のノード障害が検出されます。第6.4.1項「NFSでのファイル・ストアの使用に関する考慮事項」を参照し、ストレージのベンダーに、マウント・オプションとして使用する主な推奨パラメータについて問い合せてください。
NASデバイス別のコマンド例を次に示します。この例のオプションは、ご使用の環境のものと異なる場合がありますので、mountコマンドおよびそのオプションの詳細は、UNIXまたはLinuxのドキュメントを参照してください。
mount nasfiler:/vol/vol1/u01/oracle /u01/oracle -t nfs -o rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,wsize=32768
可用性が最大になるよう、共有記憶域には高可用性NASデバイスまたはSANデバイスの使用をお薦めします。高可用性に対応していない共有記憶域デバイスはシングル・ポイント障害になる可能性があります。高可用性を実現するためのオプションについては、ストレージ・プロバイダに確認してください。
JMSおよびJTAに関する情報をファイル・ストアに保存する方法の詳細は、『Oracle WebLogic Serverサーバー環境の管理』のWebLogic永続ストアの使用に関する項を参照してください。
次の項では、Oracle Fusion Middleware Oracleホーム・ディレクトリで共有記憶域を使用するためのガイドラインについて説明します。
Oracle Fusion Middleware製品をインストールする際には、Oracleホーム(ORACLE_HOME)に製品バイナリをインストールします。このバイナリ・ファイルは読取り専用であり、Oracleホームにパッチが適用されるか新しいバージョンにアップグレードされるまで変更されることはありません。
通常の本番環境では、Oracleホーム・ファイルはドメイン構成ファイルとは別の場所に保存されます。その場所は、Oracle Fusion Middleware構成ウィザードを使用して作成されます。
Oracle Fusion Middlewareインストール用のOracleホームには、Oracle WebLogic Serverのバイナリ、Oracle Fusion Middlewareインフラストラクチャ・ファイルおよび任意のOracle Fusion Middleware製品固有のディレクトリが含まれています。
|
注意: デフォルトでは、構成ウィザードはOracleホーム内の |
|
関連項目: Oracleホームの構造とコンテンツの詳細は、『Oracle Fusion Middleware Oracle Fusion Middlewareコンセプトの理解』の「Oracle Fusion Middlewareの主要ディレクトリとは」を参照してください。 |
Oracle Fusion Middlewareでは、1つのOracleホームで複数のサーバーを構成できます。これにより、共有ボリューム上の1つの場所にOracleホームをインストールして、複数のサーバーをインストールするためにOracleホームを再利用できます。
Oracleホームが、異なるホスト上の複数のサーバーで共有されている場合、実施する必要のあるいくつかのベスト・プラクティスがあります。たとえば、Oracleインベントリ・ディレクトリ(oraInventory)は、Oracleホームが最初にインストールされたホストからのみ更新されるため、Oracleホームで実行するその後のすべての操作(パッチ適用やアップグレードなど)は、元のホストから実行することをお薦めします。そのホストが使用できない場合は、もう一方のホストからOracleホームにパッチやアップグレードを適用する前に、必ず別のホスト上でOracleインベントリが更新されるようにしてください。
oraInventoryの詳細は、Oracle Universal Installerコンセプト・ガイドのOracle Universal Installerインベントリに関する項を参照してください。
可用性が最大になるように、共有記憶域上でバイナリの冗長インストールを使用することをお薦めします。
このモデルでは、Oracle Fusion Middlewareソフトウェアの2つの同じOracleホームを2つの異なる共有ボリュームにインストールします。まず、Oracleホームの1つをサーバーの1セットにマウントし、もう一方を残りのサーバーにマウントします。いずれのOracleホームも同じマウント・ポイントを持つため、サーバーがどのOracleホームを使用しているかにかかわらず、Oracleホームは常に同じパスを持ちます。
片方のOracleホームが破損したり使用不可になっても、影響を受けるのは半分のサーバーのみです。さらに保護を強化するために、これらのボリュームのディスク・ミラーを行うことをお薦めします。影響を受けたサーバーの機能は、影響を受けていないOracle Homeを再マウントするだけで、完全にリストアできます。
共有記憶域で個別ボリュームが使用不可の場合、同じボリューム内の別々のディレクトリを使用して個別ボリュームをシミュレートしたり、ホスト側の同じマウント場所に個別ボリュームをマウントしたりすることをお薦めします。これによって複数のボリュームによる保護が保証されるわけではありませんが、ユーザーによる削除や個々のファイルの破損からは保護されます。
|
注意: 最大の保護を得るには、クラスタのメンバーを、冗長なバイナリOracleホーム全体に、均等に分散することをお薦めします。これは、クラスタのメンバーが使用可能なすべてのサーバー上で実行されてはいない場合に、特に重要です。 |
次の項では、エンタープライズ・デプロイメントでOracle Fusion Middleware製品を構成する際に作成するOracle WebLogic Serverドメイン構成ファイルで共有記憶域を使用するためのガイドラインについて説明します。
Oracle Fusion Middleware製品を構成すると、Oracle WebLogic Serverドメインが作成または拡張されます。各Oracle WebLogic Serverドメインは、1つの管理サーバーおよび1つ以上の管理対象サーバーで構成されます。
WebLogicは、管理サーバーの永続的な変更内容をすべての管理対象サーバーにプッシュするために、レプリケーション・プロトコルを使用します。これにより、管理サーバーが稼働していなくても、管理対象サーバーに冗長性がもたらされます。これを管理対象サーバーの独立モードと呼びます。
Oracle WebLogic Serverドメインの詳細は、Oracle WebLogic Serverドメイン構成の理解を参照してください。
この項では、管理サーバーおよび管理対象サーバーの構成ファイルの考慮事項について説明します。
管理サーバーの構成ディレクトリ
ドメイン構成ファイルを共有記憶域に格納することは必須ではありません。しかし、管理サーバーのリカバリをサポートするためには、管理サーバーの構成ディレクトリを共有記憶域に配置し、管理サーバーが稼働しているホストでマウントする必要があります。そのホストに障害が発生した場合は、そのディレクトリを別のホストでマウントし、障害の発生した管理サーバーを別のホストで復旧することができます。詳細は、第8章「管理サーバーの高可用性」を参照してください。
管理対象サーバーの構成ファイル
管理対象サーバーの構成ファイルは、ローカル(ホストのプライベート記憶域)に保存することをお薦めします。
また、管理対象サーバーの構成ファイルは共有記憶域に保存することもできます。ただし、そうすることで、複数のサーバーが同じ記憶域ボリュームにアクセスするようになるため、パフォーマンスに影響する可能性があります。
高可用性設定でファイル・ベースの永続性を使用する場合は、JMS永続ストアとJTAトランザクション・ログのディレクトリが共有記憶域に配置されるように構成する必要があります。詳細は、第6.4項「ファイル永続性を使用するうえでの考慮事項(WebLogic JMS)」を参照してください。
共有記憶域を使用する場合、記憶域の要素をレイアウトする方法は複数あります。次のベスト・プラクティスを使用することをお薦めします。
表4-2 共有記憶域要素のディレクトリ構造
| 要素 | 場所 |
|---|---|
|
ORACLE_HOME |
すべてのサーバーにより、読取り専用モードで共有されます。 |
|
JMSファイル・ストアおよびトランザクション・ログ |
ファイルベースの永続性を使用する場合は、共有記憶域に配置されます。 |
|
管理サーバー・ドメインの構成ディレクトリ |
管理サーバーの別のホストへのフェイルオーバーを容易にするため、共有記憶域に配置されます。 |
|
注意: 管理対象サーバーのドメイン構成ディレクトリは、対応するホストのローカル記憶域に配置します。詳細は、第4.4.2項「管理サーバーおよび管理対象サーバーのドメイン構成ファイル用の共有記憶域に関する考慮事項」を参照してください。 |
図4-1は、ディレクトリ構造を表しています。
