test

Sun Java Enterprise System 5 インストール計画ガイド

Java ES で推奨されるゾーンの使用法

複数ゾーン環境への Java ES の配備には製品コンポーネントが実行時に独立性を持ちリソースを効率的に活用できるようにするという大まかな目的がありますが、複数ゾーン環境を使用するより具体的な目的がいくつも存在します。これについては 「Java ES にゾーンを使用する理由」で論じています。複数ゾーン環境での Java ES のインストールと管理の方策は、そのうちのどの目的を実現しようとしているかによって大きく左右されます。

表 A–2 では、5 つのシナリオ、それぞれに対応するインストールと管理の方策、およびそれによって実現しようとする目的を示します。これらのシナリオを組み合わせることが可能な場合もありますが、問題のある結果になったり、管理が混乱する恐れもあります。そのため、Java ES Release 5 では一般にこれらのシナリオを組み合わせた配備はサポートしていません。

また、シナリオ 1 とシナリオ 5 には問題があるため、現在 Java ES Release 5 ではサポートしていません。ただし、シナリオ 5 の場合は特定の製品コンポーネント用に適合させることが可能です。

表 A–2 Java ES のゾーンインストールおよび管理の方策

シナリオ (インストールの方策) 

管理の方策 

目的 (「Java ES にゾーンを使用する理由」を参照)

コメント 

1: 製品コンポーネントと共有コンポーネントを大域ゾーンにインストールし、伝播を有効にする。非大域ゾーンにはコンポーネントをインストールしない。* 

コンポーネントのライフサイクル管理: 大域管理者 

設定およびランタイム管理: ゾーン管理者 

製品コンポーネントのライフサイクル管理を集約化 

製品コンポーネントの設定およびランタイム管理を組織別に独立化 

問題あり。Message Queue 以外の Java ES 製品コンポーネントにまだサポートされていない。 製品コンポーネントが、大域ゾーンへのインストールと非大域ゾーンでの設定およびランタイム管理をサポートしている必要がある。 

2: 共有コンポーネントを大域ゾーンに、製品コンポーネントを完全ルートゾーンにインストールする 

共有コンポーネントのライフサイクル管理: 大域管理者 

製品コンポーネントのライフサイクル管理: ゾーン管理者 

設定およびランタイム管理: ゾーン管理者 

共有コンポーネントのライフサイクル管理を集約化 

製品コンポーネントのライフサイクル、設定、およびランタイム管理の組織別の独立化 

すべてのコンポーネントが同じ Java ES バージョンを実行しているか、すべての完全ルートゾーンのすべての製品コンポーネントをアップグレードする場合は、おおかた適用可能。 

3: 共有コンポーネントを大域ゾーンに、製品コンポーネントを疎ルートゾーンにインストールする** 

シナリオ 2 と同じ 

共有コンポーネントのライフサイクルの管理を集約化 

製品コンポーネントのライフサイクル、設定、およびランタイム管理の組織別の独立化 

シナリオ 2 のリソース効率をさらに向上 (「完全ルートゾーンと疎ルートゾーンのどちらを選択するか」を参照)

疎ルートゾーンに製品コンポーネントをインストールする場合に、このシナリオを推奨します。一部の共有コンポーネントは疎ルートゾーンにインストールできない場合があるため、大域ゾーンへのインストールが必要となります。 

4: 製品コンポーネントと共有コンポーネントを完全ルートゾーンにインストールする 

コンポーネントのライフサイクル管理: ゾーン管理者。設定およびランタイム管理: ゾーン管理者 

バージョンの分離 

どの共有コンポーネントおよび製品コンポーネントも大域ゾーンにインストールしないようにします。完全ルートゾーンの場合に推奨されるシナリオです。 

5: 製品コンポーネントと共有コンポーネントを疎ルートゾーンにインストールする 

シナリオ 4 と同じ 

製品コンポーネントのライフサイクル、設定、およびランタイム管理の組織別の独立化 

シナリオ 4 のリソース効率をさらに向上 (「完全ルートゾーンと疎ルートゾーンのどちらを選択するか」を参照)

問題あり。疎ルートゾーンにインストールできない共有コンポーネントが多数あるため、通常は実現不可能。 

* シナリオ 1 では、ゾーン環境を完全ルートと疎ルートとに区別しません。このシナリオは、非大域ゾーンにインストールする製品コンポーネントがないことを前提としています。非大域ゾーンへの製品コンポーネントのインストールは、シナリオ 2 〜 5 で扱います。

** シナリオ 3 は、/opt が疎ルートゾーン内の読み取り専用ディレクトリになっていないことを前提とします。/opt が読み取り専用であると、ほとんどの Java ES 製品コンポーネントは疎ルートゾーンにインストールできないため、代わりにシナリオ 1 のように、それらを大域ゾーンにインストールすることが必要になります。

推奨されている実践事項

表 A–2 を踏まえ、推奨されている実践事項を次にいくつか紹介します。

配備アーキテクチャー

表 A–2 のシナリオの説明と前述の推奨されている実践事項には、複数ゾーン環境用に推奨されている Java ES 配備アーキテクチャーに関する内容は含まれていません。このアーキテクチャーは、複数台のコンピュータが接続されているネットワーク環境用に作成された配備アーキテクチャーの改良版です。別の言い方をすれば、複数ゾーン環境を利用するからといって、Java ES 配備システムの高パフォーマンス、高可用性、スケーラビリティー、セキュリティー、および保守性を実現する基本的な配備設計の手法は変わりません。複数ゾーン環境を使用することで、このような配備アーキテクチャーを整理統合してより少ない台数のコンピュータで運用することが可能になります。

しかし、これまでのセクションで論じられてきたように、具体的にどのように Java ES 配備アーキテクチャーを複数ゾーン環境に改良するかは、採用する管理方針によって大きく左右されます。また、配備アーキテクチャーは高可用性を実現する方策にも依存します。

表 A–2 と前述の推奨されている実践事項には、説明されているシナリオを実装する推奨手順は含まれていません。場合によっては、Java ES コンポーネントをインストールする順序と非ローカルゾーンを作成する順序が重要になることがあります。