9 管理サーバーの高可用性
- 管理サーバーの役割
管理サーバーは、ドメイン全体を構成するための集中管理エンティティで、すべてのドメイン・リソースを管理およびモニターします。ドメインの構成ドキュメントを保持し、これらのドキュメント内の変更を管理対象サーバーに配布します。 - ノード・マネージャの役割
作成するWebLogic Serverドメインのそれぞれについて、ドメインごとのノード・マネージャ構成がデフォルトで作成されます。ノード・マネージャには、セキュリティ資格証明書、プロパティ・ファイル、ドメイン登録および起動スクリプトが付属しています - 管理サーバーの高可用性トポロジ
管理サーバーは、1つのホスト上でいつでもアクティブにできます。高可用性を設定するには、管理サーバーを仮想ホスト上に構成して、それを実行しているマシンに障害が発生した場合に、ドメイン内の別のホストにフェイルオーバーします。 - 管理サーバーの高可用性の構成
管理サーバーの高可用性環境では、ドメイン・ディレクトリが共有記憶域で維持されるため、両方のホストが共有記憶域にアクセスできる必要があります。 - 管理サーバーのフェイルオーバーまたはフェイルバック
ホストの障害発生後、管理サーバーをフェイルオーバーまたはフェイルバックします。
親トピック: 高可用性環境の作成
管理サーバーの役割
管理サーバーは、ドメイン全体を構成するための集中管理エンティティで、すべてのドメイン・リソースを管理およびモニターします。ドメインの構成ドキュメントを保持し、これらのドキュメント内の変更を管理対象サーバーに配布します。
各ドメインには、管理サーバーとして機能する1つのサーバーが必要です。管理サーバーおよびノード・マネージャの詳細は、次の各項目を参照してください。
表9-1 管理サーバーおよびノード・マネージャに関する項目
情報 | 参照先 |
---|---|
管理サーバーの起動と停止 |
Oracle Fusion Middlewareの管理の管理サーバーの起動と停止 |
仮想ホスティングの構成 |
Oracle WebLogic Serverサーバー環境の管理の「仮想ホスティングの構成」 |
ノード・マネージャの使用 |
Oracle WebLogic Serverノード・マネージャの管理の次の項: |
- 管理サーバーの障害と再起動
管理サーバーの障害は、ドメイン内の管理対象サーバーの動作には影響を与えません。 - 共有記憶域と管理サーバーの高可用性
共有記憶域を使用すると、バックアップ・ホストは、アクティブ・ホストがアクセスできる同じアーティファクト(Oracleバイナリ、構成ファイル、ドメイン・ディレクトリおよびデータ)にアクセスできます。
親トピック: 管理サーバーの高可用性
管理サーバーの障害と再起動
管理サーバーの障害は、ドメイン内の管理対象サーバーの動作には影響を与えません。
管理サーバーのホスト・コンピュータ上のハードウェアまたはソフトウェアの障害が原因で管理サーバーに障害が発生した場合は、同じコンピュータ上のその他のサーバー・インスタンスが影響を受けることがあります。
管理サーバーの障害の詳細は、Oracle Fusion Middlewareの管理の管理対象サーバーの障害の影響を参照してください。
管理サーバーを再起動する方法は、Oracle Fusion Middleware Oracle Serverクラスタの使用の管理サーバーの障害時の処理に関する項を参照してください。
親トピック: 管理サーバーの役割
ノード・マネージャの役割
作成するWebLogic Serverドメインのそれぞれについて、ドメインごとのノード・マネージャ・インスタンスがデフォルトで作成されます。ノード・マネージャには、セキュリティ資格証明書、プロパティ・ファイル、ドメイン登録および起動スクリプトが付属しています
ノード・マネージャの範囲は構成可能です。
-
ドメインごとのノード・マネージャは、ドメインと関連付けられ、マシン上のドメインのすべてのサーバーを制御します。デフォルトの構成です。
-
ホストごとのノード・マネージャは、ドメインではなく、特定のマシンに関連付けられます。サーバー・インスタンスがノード・マネージャ・プロセスと同じマシン上に存在しているかぎり、ノード・マネージャ・プロセスを使用して任意のドメインのサーバー・インスタンスを制御できます。ホストごとのノード・マネージャは、ノード・マネージャで制御するWebLogic Serverインスタンスをホストするそれぞれのコンピュータ上で、WebLogic Serverインスタンスが管理サーバーか管理対象サーバーであるかにかかわらず、実行する必要があります。
ノート:
ホスト・マシンが再起動した場合に、ノード・マネージャが自動的に再起動するよう、ノード・マネージャはオペレーティング・システムのサービスとして実行することをお薦めします。
ノード・マネージャに障害が発生しても、マシン上で実行しているサーバーには影響しません。
『Oracle Fusion Middleware Oracle Fusion Middlewareコンセプトの理解』のノード・マネージャに関する項を参照してください。
親トピック: 管理サーバーの高可用性
管理サーバーの高可用性トポロジ
管理サーバーは、1つのホスト上でいつでもアクティブ化できます。高可用性を設定するには、管理サーバーを仮想ホスト上に構成して、それを実行しているマシンに障害が発生した場合に、ドメイン内の別のホストにフェイルオーバーします。
管理サーバーは、仮想IPを使用して、バックアップ・ホストとオーバーラップするように構成されます。この仮想IPをリスニングするように、管理サーバーを構成します。仮想ホストおよび仮想IPの利点は第3のマシンを追加する必要がない点にあります。フェイルオーバーが発生した場合は仮想IPを移動することで、ドメイン内の障害の発生していないマシンに仮想ホストをマップできます。
2つのホストで、仮想ホスト名および仮想IPを共有します。ただし、この仮想IPを使用できるのは、常に1つのアクティブ・ホストに限定されます。アクティブ・ホストに障害が発生した場合はバックアップ・ホストがアクティブ化され、仮想IPを新しいアクティブ・ホストに(手動で)移動します。すべてのリクエストは、仮想IPを通じて、新しいアクティブ・ホストで処理されます。(この仮想IPをリスニングするように、高可用性デプロイメントを構成します。)
図9-1は、高可用性管理サーバーを示しています。
このトポロジでは、管理サーバーは仮想ホストAPPHOST0
上で実行されます。APPHOST0
は、仮想IPによってAPPHOST1
またはAPPHOST2
にオーバーラップされます。
最初、APPHOST0
はAPPHOST1
にマッピングされます。しかし、APPHOST1
の障害が原因で管理サーバーに障害が発生した場合は、仮想IPを移動することによって、APPHOST0
をAPPHOST2
にフェイルオーバーします。
親トピック: 管理サーバーの高可用性
管理サーバーの高可用性の構成
管理サーバーの高可用性環境では、ドメイン・ディレクトリが共有記憶域で維持されるため、両方のホストが共有記憶域にアクセスできる必要があります。
通常の運用時は、アクティブ・ホスト上の管理サーバーによってドメイン・ディレクトリが所有されます。アクティブ・ホストに障害が発生した場合は、バックアップ・ホストによって引き継がれ、管理サーバーは共有ドメイン・ディレクトリから再起動されます。
- 管理サーバーの高可用性の要件
高可用性の管理サーバーを構成するには、ご使用の環境が特定の要件を満たす必要があります。 - 高可用性の管理サーバーの構成
高可用性の管理サーバーを構成するには、まず1つのクラスタ(cluster_1
)を持つ標準高可用性トポロジを作成する必要があります。
親トピック: 管理サーバーの高可用性
管理サーバーの高可用性の要件
高可用性の管理サーバーを構成するには、ご使用の環境が特定の要件を満たす必要があります。
-
標準インストール・トポロジに準拠すること。Oracle Fusion Middlewareの標準HAトポロジについてと図1-1を参照してください。
-
2つのホスト、APPHOST1およびAPPHOST2を組み込んで、WebLogic Serverクラスタ(
cluster_1
)を実装すること。高可用性の管理サーバーの構成では、APPHOST1およびAPPHOST2のIPアドレスは、それぞれip1
およびip2
です。 -
APPHOST1およびAPPHOST2に、共有記憶域から共通のディレクトリがマウントされ、そのディレクトリの読取り/書込み権限が与えられること。このディレクトリは、製品のインストールおよびドメイン・ディレクトリの格納に使用されます。
-
予約済仮想IPアドレス(
vip0
)によって管理サーバーを実行しているホストを指し示すこと。この仮想サーバーを示す浮動IPアドレスが、管理サーバーを実行しているホスト上で動的に構成されること。 -
管理サーバーは、ノード・マネージャ・インスタンスによって管理され、障害の発生したホストから指定されたスタンバイ・ホストに移行されること。
親トピック: 管理サーバーの高可用性の構成
高可用性の管理サーバーの構成
高可用性の管理サーバーを構成するには、まず1つのクラスタ(cluster_1
)を持つ標準高可用性トポロジを作成する必要があります。
Oracle Fusion Middlewareの標準HAトポロジについてを参照してください。
高可用性の管理サーバーを設定するには、管理サーバーを別の仮想ホスト(APPHOST0
)上で実行します。APPHOST0
が、クラスタ内の既存のホストのうちの1つ(APPHOST1
またはAPPHOST2
)にマップされるように、APPHOST0
用の(仮想)サーバーIPをそのホストに設定します。フェイルオーバーが発生した場合は、障害が発生していないホストにこの仮想IPが移行されることで、APPHOST0
がフェイルオーバーされます。ドメイン設定は、障害の発生していないホストからアクセスできるように、共有記憶域に置かれます。
ノート:
管理サーバーのサービスで構成タスクを完了するには、複数の方法があります。いずれの方法を使用するにしても、構成を変更する際はクラスタの管理サーバーが稼働している必要があります。
表9-2 ホストおよびノード・マネージャの用語
用語 | 説明 |
---|---|
|
管理サーバーが実行される仮想マシン |
|
アプリケーション層がホストされるマシン |
|
管理サーバーによってリスリングされる仮想サーバーのIPアドレス |
|
APPHOST0で実行される管理サーバーを管理する、ドメインごとのノード・マネージャ |
|
APPHOST1およびAPPHOST2でそれぞれ実行されるノード・マネージャのインスタンス |
|
それぞれ、APPHOST1およびAPPHOST2のIPアドレス |
高可用性の管理サーバーを設定するには:
親トピック: 管理サーバーの高可用性の構成
管理サーバーのフェイルオーバーまたはフェイルバック
ホストの障害の発生後、管理サーバーをフェイルオーバーまたはフェイルバックします。
- 元のホストに障害が発生した場合の管理サーバーのフェイルオーバー
元のホスト(APPHOST1
)に障害が発生した場合、管理サーバーを別のホストにフェイルオーバーします。これを行うには、仮想IPアドレスを代わりのホスト(APPHOST2
)に構成して、ノード・マネージャと管理サーバーを起動します。 - 元のホストへの管理サーバーのフェイルバック
管理サーバーが再起動した後、元のホストにフェイルバックします。
親トピック: 管理サーバーの高可用性
元のホストに障害が発生した場合の管理サーバーのフェイルオーバー
元のホスト(APPHOST1
)で障害が発生した場合、管理サーバーを別のホストにフェイルオーバーします。これを行うには、仮想IPアドレスを代わりのホスト(APPHOST2
)に構成して、ノード・マネージャと管理サーバーを起動します。
APPHOST1
に障害が発生した場合に、管理サーバーをAPPHOST2
にフェイルオーバーするには、次のようにします。
vip0
をAPPHOST2
に構成します。APPHOST2
の共有記憶域のドメイン・ディレクトリで、ノード・マネージャNMa
を起動します。APPHOST2
でNMa
を使用して、管理サーバーを起動します。- 管理コンソールを起動して、管理サーバーが実行されていることを確認します。
親トピック: 管理サーバーのフェイルオーバーまたはフェイルバック
元のホストへの管理サーバーのフェイルバック
管理サーバーが再起動した後、元のホストにフェイルバックします。
APPHOST1
がオンラインに復帰してから、管理サーバーをAPPHOST1
にフェイルバックするには、次のようにします。
- ノード・マネージャ
NMa
を使用して、APPHOST2
の管理サーバーを停止します。 vip0
を、APPHOST2
から削除します。APPHOST2
で、ノード・マネージャNMa
を停止します。- vip0を
APPHOST1
に構成します。 - 共有記憶域のドメイン・ディレクトリを使用して、
APPHOST1
でノード・マネージャNMa
を起動します。 - ノード・マネージャ
NMa
を使用して、APPHOST1
で管理サーバーを起動します。 - 管理コンソールを起動して、管理サーバーが実行されていることを確認します。
親トピック: 管理サーバーのフェイルオーバーまたはフェイルバック