|
|
WebOTX Manual V10.4 (第4版) 目次を表示 |
|
|
|
WebOTX Manual V10.4 (第4版) 目次を表示 |
WebOTX ではシステムをドメインという構成単位で管理を行います。まずはドメインの構成について説明します。
WebOTX の基本的な構成単位をドメインと呼びます。このドメインはJMX 仕様で定義されているドメイン に対応します。
ドメインはWebOTX で管理するリソースやサービス群を論理的にグルーピングしています。 ドメインは独立して運用され、コンフィグレーション情報など構成情報はドメイン単位で独立したディレクトリに管理されます。
それぞれの業務システムの要件にあわせてドメインを構成することができます。 例えば1つのホストで商用環境と評価環境を構築したい場合、そのホスト上に商用のドメインと評価用のドメインを構成させることができます。 また稼動、待機構成のクラスタ構成を行いたい場合は、複数のホストで1つのドメインを定義できます。
ドメインを構成するモジュール群について説明します。 ドメインは主に、ドメイン情報を管理する運用管理エージェントとアプリケーションサーバとしての機能を提供するサービス群(以下の表で示します)で構成されます。
運用管理エージェントはそのドメイン内で動作するサービスやコンフィグレーションを管理します。 またリモートから運用操作が行えるためのインタフェースを外部に提供します。
サービスには次のものを提供しており、そのドメインで必要なサービスをドメイン作成時に指定します。
| サービス名称 | Express | Standard | Enterprise |
|---|---|---|---|
| HTTPサーバ | ○ | ○ | ○ |
| Webコンテナ | ○ | ○(*1) | ○(*1) |
| EJBコンテナ | ○ | ○(*2) | ○(*2) |
| JNDIサービス | ○ | ○ | ○ |
| JMSサービス | ○ | ○ | ○ |
| CORBAサービス | ○ | ○ | ○ |
| Transactionサービス | ○ | ○ | ○ |
| TPモニタ | × | ○ | ○ |
| WatchServer | × | × | ○ |
*1: Express のWebコンテナは運用管理エージェントのJava VM 内で動作します。 Standard および Enterprise の Webコンテナは運用管理エージェントとは独立したJava VM 上で動作します。 ただし従来どおり 運用管理エージェントのJava VM 内で動作させることも可能です。
*2: Express のEJBコンテナは運用管理エージェントのJava VM 内で動作します。 Standard および Enterprise のEJBコンテナは運用管理エージェントとは独立したJava VM 上で動作します。
WebOTXでは大きく2つのドメインにタイプ分けしています。
管理ドメインWebOTXをインストールした時点で、ホスト単位で1つ作成されます。 管理ドメインはそのホスト上で動作するユーザドメインの管理を行います。 管理ドメインを通して以下の操作を行うことができます。
システム構成によってユーザが任意に作成するドメインです。 ドメイン作成時に、そのドメイン上で管理するリソースやサービスを任意に指定することができます (WebOTXのエディションにより指定できるリソースやサービスに制限されます)。 ユーザドメインでは、実際の業務システムを構成するアプリケーションやサービスが動作します。
業務システムのユーザドメインの構成について説明します。 ドメイン構成は大きく次の5つのグループに分割することができます(DBサーバについては省略します)。 これらについてそれぞれ独立したドメインに割り当てることも、同一のドメインに割り当てることも可能ですが、基本的な構成について次に説明します。
Expressで動作するサービスを1つのドメインで動作させます。 Java EEアプリケーションシステムを構築する上でもっともシンプルなドメイン構成です。 1台のマシンで全て動作させる場合やWeb層とAP層を分割する必要のない場合は通常 この構成となり以下のサービスが起動します。
マルチサーバ構成の場合、マシン単位でドメインを1つ作成し負荷分散装置により分散を行います。
Standard/Enterpriseで動作するサービスを1つのドメインで動作させます。 システムを構築する上でもっともシンプルなドメイン構成です。 1台のマシンで全て動作させる場合やWeb層とAP層を分割する必要のない場合は 通常この構成となり以下のサービスが起動します。
マルチサーバ構成の場合、マシン単位でドメインを1つ作成し負荷分散装置により分散を行います。
Webサーバ層を構成するドメインでは次のサービスが動作します。
Webサーバはクラスタ化する場合、基本的にはマルチサーバ負荷分散構成となります。 さらに1つのマシンでは1つのWebサーバ、Webコンテナを動作させる構成が基本です。
また、パターンによっては1マシン内でWebサーバとWebコンテナが1対nになるような構成も可能です。 この場合はそれぞれ(Webサーバ、Webコンテナ)が独立したドメイン構成となります。
APサーバ層を構成するドメインでは次のサービスが動作します。
APサーバ層のクラスタとしては負荷分散がメインですが、 稼動待機構成(シングルスタンバイ、相互スタンバイ)も用いられ、 また業務の特性に応じてマルチシステム構成となるため、柔軟な構成が望まれています。
負荷分散構成:
シングルスタンバイ構成:
相互スタンバイ構成:
マルチシステム構成:
名前サーバ層を構成するドメインでは次のサービスが動作します。
名前サーバ自身は、負荷分散クラスタなどの負荷を分散する構成にする必要はありませんが、 基本的にはシステムで1つの存在であるので、 SPOF(Single Point of Failure)とならないための対策が必要となります。 また名前サーバ専用にマシンを割り当てる構成は、 コスト的に敬遠されるためさまざまな箇所に配置されることが想定されます。
Webサーバ上に配置する場合は、Webサーバと1対1で配置します。 各名前サーバには全てのAPサーバの名前情報が格納されるように設定します。 Webサーバ上の名前サーバは、APサーバ負荷分散実装するために、 全てのAPサーバ上の情報を持ち、 どのWebサーバ上の名前サーバも同一の情報を保持しています。
APサーバ上に配置する場合は、APサーバのクラスタ構成によって構成が変わります。
負荷分散構成:
負荷分散構成の場合、1マシンに1名前サーバを配置します。
APサーバ負荷分散実装するために、名前サーバ間でレプリケーションを行い、
全てのAPサーバ上の情報を格納します。
名前サーバは全て同一の情報を保持しています。
シングルスタンバイ構成:
シングルスタンバイ構成の場合、稼動系マシンに1名前サーバとなります。
異常時にはAPサーバと同様、名前サーバもフェイルオーバします。
この場合、フェイルオーバしても登録情報を引き継げるようにする必要があるため、情報を永続化します。
相互スタンバイ構成:
相互スタンバイ構成の場合、APサーバドメイン1つにつき1名前サーバとなります。
この場合、縮退時には1マシン上に複数の名前サーバが稼動します。
マルチシステム構成:
マルチシステム構成の場合、システムごとに名前サーバを配置するか、1つにするかは要件に依存します。
通常は1つで問題はありませんが、本番、
テスト系のような構成の場合、名前サーバも本番、
テスト系で別運用となるため独立して運用できるようにすることが必要です。
