|
|
WebLogic Portal アプリケーションをクラスタ環境にデプロイする前に、WebLogic Configuration Wizard を使用してクラスタ環境向けの WebLogic Portal ドメインをコンフィグレーションする必要があります。この章では、ポータル アプリケーションでクラスタ環境をコンフィグレーションする場合の基本手順について説明します。
この章では、WebLogic Portal アプリケーションでクラスタ環境を設定する前に実行しなければならない一連の前提条件タスクについて説明します。前提条件タスクに関する説明の次に、WebLogic Configuration Wizard を使用してクラスタをコンフィグレーションする手順 (JMS サーバや管理対象サーバ ディレクトリなど) について説明します。
WebLogic Portal アプリケーションでクラスタ化されたプロダクション環境をコンフィグレーションする前に、いくつかの前提条件タスクを実行する必要があります。これらの前提条件タスクの詳細な内容は、この章の範囲外であるため、別のドキュメント (通常、WebLogic Server ドキュメント) を参照してください。また、ソース ドキュメントや補足ドキュメントとの相互参照が適宜記載されています。
| 注意 : | これらのタスクは任意の順序で実行できますが、必ずクラスタ環境のコンフィグレーションに進む前に実施する必要があります。 |
ポータル アプリケーションをプロダクションにデプロイするには、エンタープライズ品質のデータベースを設定する必要があります。エンタープライズ品質データベースの設定の詳細については、「データベースの管理」を参照してください。プロダクション データベースのコンフィグレーションの詳細については、『データベース管理ガイド』を参照してください。
| 注意 : | PointBase データベースのインスタンスは、WebLogic Server をインストールする際にインストールされ、デフォルト データベースになります。PointBase は、アプリケーションの設計、開発、および検証に関してのみサポートされています。プロダクション サーバのデプロイメントにはサポートされていません。 |
エンタープライズ品質のデータベース インスタンスをコンフィグレーションしたら、『データベース管理ガイド』に記述されているように、コマンドラインから必要なデータベースの DDL および DML をインストールできます。また、プロダクション環境をコンフィグレーションするときに、WebLogic Configuration Wizard を使用して DDL および DML を作成することもできます。
WebLogic Portal の JMS キューおよび JDBC 名は、DOMAIN_ROOT/config/config.xml ファイルで参照されます。WebLogic Portal の JMS キューは、DOMAIN_ROOT/config/jms/*.xml ファイルで設定されます。JDBC データ ソースは、DOMAIN_ROOT/config/jdbc/*.xml ファイルで設定されます。
| ヒント : | JMS キュー コンフィグレーションの詳細については、WebLogic Server ドキュメントの『WebLogic JMS のコンフィグレーションと管理』を参照してください。JDBC の詳細については、WebLogic Server ドキュメントの『WebLogic JDBC のコンフィグレーションと管理』を参照してください。 |
相互に連携して同時に稼働する複数の WebLogic Server インスタンスで構成されるクラスタを使用すると、スケーラビリティと信頼性を向上させることができます。クラスタにデプロイされた WebLogic Portal アプリケーションは、クライアントから見ると単一のアプリケーション インスタンスに見えます。
ポータル アプリケーションをクラスタ化することで、そのアプリケーションの高可用性およびスケーラビリティが実現されます。以下の節を参考に、採用するクラスタ コンフィグレーションを選択してください。
| ヒント : | サーバ クラスタの詳細については、WebLogic Server ドキュメントの『WebLogic Server クラスタ ユーザーズ ガイド』を参照してください。 |
| 注意 : | WebLogic Portal の初期のバージョンでは、JSP/サーブレットおよび EJB は個別のサーバにデプロイされるようにポータル アプリケーションをコンフィグレーションすることができました。この分割コンフィグレーションはサポートされなくなりました。 |
ポータル アプリケーションのプロダクション インスタンスをサポートする環境を設定する場合には、ポータル アプリケーションをクラスタに直接デプロイするコンフィグレーションを推奨します。このコンフィグレーションの詳細については、WebLogic Server ドキュメントの WebLogic の推奨基本アーキテクチャに関する説明を参照してください。
図 3-1 は、WebLogic Portal 専用の推奨基本アーキテクチャを示しています。
| 注意 : | WebLogic Portal は、EJB と JSP が 1 つのクラスタ内で異なるサーバに分割される分割コンフィグレーション アーキテクチャをサポートしていません。WebLogic Portal では、推奨基本アーキテクチャの方が、分割コンフィグレーションよりはるかに優れたパフォーマンスを実現します。 |
また、このアーキテクチャを使用すると、最初のプロダクション デプロイメントで 1 つのシングル サーバ インスタンスのみを実行する場合でも、必要な時点で新しいサーバ インスタンスを簡単に追加することができます。
マルチ クラスタ化されたアーキテクチャは、ポータル アプリケーションを常時アクセス可能にする必要がある場合に、ゼロ ダウンタイム環境をサポートするのに使用されます。シングル クラスタ環境では、ポータル アプリケーションを無期限に実行できる一方、クラスタやサーバに新しいコンポーネントをデプロイするときに、ポータルにアクセスできない時間が生じます。これは、新しい EAR アプリケーションが WebLogic Server にデプロイされる間、HTTP リクエストを処理できなくなるためです。ポータル アプリケーションを再デプロイする場合も、既存のセッションが失われます。
マルチ クラスタ コンフィグレーションの詳細については、WebLogic Server ドキュメントの「クラスタ アーキテクチャ」にある「推奨多層アーキテクチャ」を参照してください。
マルチ クラスタ環境には、一般に、主クラスタと副クラスタという 2 つのクラスタを設定する必要があります。通常の運用時は、すべてのトラフィックが主クラスタに送信されます。ポートレットなどの新しいコンポーネントをデプロイする必要があるときは、主クラスタを更新している間、副クラスタでリクエストを処理します。マルチ クラスタ化された環境を管理および更新するプロセスは、シングル クラスタよりも複雑になります。これについては、「ゼロ ダウンタイムのアーキテクチャ」で説明しています。この環境に関心がある方は、ここを参照してください。
WebLogic Configuration Wizard でドメインをビルドする前に、ドメインのネットワーク レイアウトについて検討する必要があります。ドメインを設定する前に、クラスタ内の管理対象サーバの総数について検討します。これには、次の情報が含まれます。
また、サーバの起動に WebLogic Node Manager を使用するかどうかも決定します。Node Manager の詳細については、『WebLogic Server のコンフィグレーションと管理』を参照してください。
WebLogic Portal は、すべての管理対象サーバ マシンと管理サーバにインストールする必要があります。
| 注意 : | クラスタ化された環境で WebLogic Portal を実行している場合は、管理サーバを常に実行しておく必要があります。これにより、クラスタのポリシー データが、WebLogic Portal がデータベースに格納した、そのデータへの参照と同期された状態になります。 |
この節では、WebLogic Portal ドメインでクラスタ環境を設定する方法について説明します。この節では、WebLogic Configuration Wizard を使用してクラスタを設定する手順について説明します。
クラスタの詳細については、「クラスタ アーキテクチャの選択」および WebLogic Server ドキュメントの『コンフィグレーション ウィザードを使用した WebLogic ドメインの作成』を参照してください。
| ヒント : | データベース ファイルおよびコンポーネントの一部は、作成後に WebLogic Portal ドメインから削除することができます。詳細については、「不要なデータベース コンポーネントの削除」を参照してください。 |
WebLogic Server 上でアプリケーションを稼働させるには、ドメインの定義と作成を行う必要があります。WebLogic Portal アプリケーションを実行するには、適切な WebLogic Portal コンポーネントを含むドメインを作成する必要があります。
ドメインは WebLogic Server の基本的な管理単位です。ドメインは 1 つまたは複数の WebLogic Server インスタンス、および論理的に関連するリソースやサービスで構成されています。これらは、まとめて 1 つのユニットとして管理されます。基本的なドメイン インフラストラクチャは、1 つの管理サーバとオプションの管理対象サーバおよびクラスタで構成されます。
| ヒント : | ドメインの概要およびこれらのコンポーネントの詳細については、WebLogic Server ドキュメントの『コンフィグレーション ウィザードを使用した WebLogic ドメインの作成』および「WebLogic Server ドメインについて」を参照してください。 |
Configuration Wizard を使用すると、対象環境で WebLogic Portal ドメインの作成または拡張を行うことができます。このプロセスは、WebLogic Portal ドメインの構築や拡張に必要な主要な属性とファイルを含む定義済みのコンフィグレーション テンプレートや拡張テンプレートを使用して実現されます。
| ヒント : | Configuration Template Builder を使用すると、既存のテンプレートやドメインからカスタム コンフィグレーション テンプレートや拡張テンプレートを作成できます。これらのテンプレートは、Configuration Wizard を使用してドメインを作成したり更新したりする場合に使用できます。ドメイン テンプレートの詳細および Configuration Template Builder を使用してドメイン テンプレートを作成する手順については、「WebLogic Configuration Template Builder によるコンフィグレーション テンプレートの作成」を参照してください。チーム開発環境で使用するカスタム ドメイン テンプレートを作成することがベスト プラクティスとして推奨されています。詳細については、「WebLogic Portal ドメイン テンプレートの作成」を参照してください。 |
WebLogic Configuration Wizard を使用してドメインを作成します。カスタマイズされたドメインは、次のタスクを使用して作成します。
| 注意 : | 以下の手順は、複雑な各種コンフィグレーション タスクを処理する WebLogic Configuration Wizard のスコープを反映しています。この手順を実行する際には、WebLogic Server ドキュメントの『コンフィグレーション ウィザードを使用した WebLogic ドメインの作成』を確認することを強く推奨します。このドキュメントには、個々のウィザード オプションに関する内容がここよりも詳しく記載されています。 |
この節では、WebLogic Configuration Wizard を使用して WebLogic Portal ドメインのコンフィグレーションを開始する方法について説明します。
WEBLOGIC_HOME/common/bin/config.cmd ファイル (または config.sh) を実行して起動することもできます。図 3-3 に示すように、[ようこそ] ダイアログが表示されます。 | ヒント : | Configuration Wizard を起動するために WebLogic Server を実行する必要はありません。 |
ウィザードで次の一連の手順に従うと、デフォルト設定を変更してドメインをカスタマイズできます。
| ヒント : | 各コンフィグレーション設定の詳細については、WebLogic Server ドキュメントの「環境のカスタマイズ」を参照してください。 |
Configuration Wizard で環境のカスタマイズが済むと、データベースと JMS オプションのコンフィグレーションを行うことができます。
この節に記載されている各オプションの詳細については、WebLogic Server ドキュメントの「JDBC と JMS の既存設定のカスタマイズ」を参照してください。また、『WebLogic JDBC のコンフィグレーションと管理』の「JDBC データ ソースのコンフィグレーション」も参照してください。
| 注意 : | XA 以外のデータ ソースには、XA 以外のドライバを選択してください。非同期の伝達設定に関連するデータベースの設定要件については、データベース ガイドを参照してください。 |
Configuration Wizard でデータベースと JMS オプションのコンフィグレーションが済むと、ドメイン コンフィグレーションの最後の手順に進みます。
| ヒント : | 変更が必要な場合には、[前へ] ボタンをクリックして前のウィンドウに戻ります。 |
管理サーバには WebLogic Portal をインストールする必要があります。ただし、管理サーバには WebLogic Portal アプリケーションをデプロイしないようにしてください。
| 注意 : | クラスタ化された環境で WebLogic Portal を実行している場合は、管理サーバを常に実行しておく必要があります。これにより、クラスタのポリシー データが、WebLogic Portal がデータベースに格納した、そのデータへの参照と同期された状態になります。 |
管理サーバの起動スクリプトのコンフィグレーションの詳細については、WebLogic Server ドキュメントの『サーバの起動と停止の管理』を参照してください。
基本的な JMS システム リソース (JMS サーバおよび JMS システム モジュールなど) のコンフィグレーションおよび管理の詳細については、WebLogic Server ドキュメントの『WebLogic JMS のコンフィグレーションと管理』を参照してください。
この節では、管理対象サーバ ディレクトリの作成に関して次のトピックについて説明します。
管理対象サーバの詳細については、WebLogic Server ドキュメントの「WebLogic Server ドメインについて」を参照してください。
管理対象サーバの定義を含めてドメインをコンフィグレーションしたので、各管理対象サーバのサーバ ルート ディレクトリを作成する必要があります。これには、管理対象サーバを管理サーバと同じマシン上に配置するか、または Node Manager を使用するかどうかによって、多数のオプションがあります。
![WebLogic Configuration Wizard の [ようこそ] ウィンドウ](wwimages/configwiz-1.gif)
![[環境とサービスの設定のカスタマイズ] ウィンドウ](wwimages/configwiz-2.gif)
![[WebLogic ドメインの確認] ウィンドウの例](wwimages/configwiz-10.gif)
config.xml は使用されません。その代わりに、管理サーバの config.xml ファイルが使用されます。管理対象サーバでは、サーバ ディレクトリの 1 階層上のディレクトリ (ドメインレベル ディレクトリに相当) に wsrpKeystore.jks ファイルを配置するだけで済みます。このファイルは、WebLogic Portal 8.1x のドメインと 9.2 のドメイン間またはその後のドメイン SAML セキュリティで WSRP を使用する場合に必要です。 | 注意 : | WebLogic Portal をすべての管理対象サーバにインストールする必要があります。 |
この節では、管理対象サーバで WebLogic Portal ドメインを作成する基本手順について説明します。管理対象サーバの詳細については、WebLogic Server ドキュメントの「WebLogic Server ドメインについて」を参照してください。
WEBLOGIC_HOME/common/bin/config.cmd ファイル (または config.sh) を実行して起動することもできます。図 3-3 に示すように、[ようこそ] ダイアログが表示されます。 | ヒント : | Configuration Wizard を起動するために WebLogic Server を実行する必要はありません。 |
| ヒント : | 管理対象サーバの起動スクリプトのコンフィグレーションの詳細については、WebLogic Server ドキュメントの『サーバの起動と停止の管理』を参照してください。 |
管理対象サーバにドメインを作成したら、startManagedWebLogic スクリプトに異なる servername パラメータを指定することで、同じマシンの他の管理対象サーバにも同じドメインを再利用できます。あるいは、ドメインの Configuration Wizard を使用して、新しい管理対象ドメインを作成することもできます。
| 注意 : | 管理対象サーバに完全なドメインを使用しない場合 (つまり、ドメインレベル ディレクトリに全ファイルを含めない場合) は、サーバ ディレクトリの 1 階層上のディレクトリ (ドメインレベル ディレクトリに相当) に、wsrpKeystore.jks のコピーを必ず保存または配置してください。このファイルは、WebLogic Portal 8.1x のドメインと 9.2 のドメイン間およびその後のドメイン SAML セキュリティで WSRP を使用する場合に必要です。 |
| ヒント : | WebLogic Portal では、プロダクションの再デプロイメントと呼ばれるゼロ ダウンタイムの別のメソッドをサポートしています。プロダクションの再デプロイメントは、限られた数の使用例でしかサポートされていません。このオプションに関する詳細については、「WebLogic Portal とのプロダクションの再デプロイメントの使用｣を参照してください。 |
WebLogic Server クラスタにポータル アプリケーションを再デプロイする際の制約は、再デプロイメントを実行している間、ユーザがサイトにアクセスできないことです。停止時間を設けてポータル アプリケーションを新しいポートレットや他のコンポーネントで更新することが不可能なエンタープライズ環境では、マルチ クラスタ コンフィグレーションを使用することで、再デプロイメント中もポータル アプリケーションを実行させておくことができます。
マルチ クラスタ環境の基本は、主クラスタでポータル アプリケーションを更新している間、ユーザ リクエストがルートされる副クラスタがあるという概念です。
通常の運用時は、図 3-8 に示すように、すべてのトラフィックが主クラスタに送信されます。トラフィックは、正常な状態である限り、副クラスタには送信されません。この 2 つのクラスタは、同じセッション キャッシュを使用できないためです。トラフィックが両方のクラスタに送信されている場合に、一方のクラスタに障害が発生すると、障害が発生したクラスタでセッション中だったユーザはもう一方のクラスタにルートされるため、そのユーザのセッション キャッシュは失われます。
主クラスタの更新中は、すべてのトラフィックを副クラスタにルートし、その後で主クラスタを新しい Portal EAR で更新します (図 3-9 を参照)。この EAR には、データベースにロードされる新しいポートレットが格納されています。副クラスタへのリクエストのルーティングは、段階的に行われます。最初に、主クラスタに対する既存のリクエストを、他のリクエストがなくなるまで、ある程度の時間をかけて終了させなければなりません。それが完了した時点で、主クラスタを新しいポータル アプリケーションで更新できます。
主クラスタの更新後は、すべてのトラフィックのルートを主クラスタに戻し、その後で副クラスタを新しい EAR で更新します (図 3-10 を参照)。データベースは主クラスタを更新したときに更新されているため、副クラスタの更新時にはデータベースは更新されません。
正常な状況では副クラスタはトラフィックを受信しませんが、それでも現行のポータル アプリケーションで副クラスタを更新する必要があります。ポータル アプリケーションを次に更新するときに、副クラスタが一時的にリクエストを受信することになるため、現行のアプリケーションを使用できるようにしておく必要があります。
以上をまとめると、マルチ クラスタ ポータル環境をアップグレードするには、まずトラフィックを主クラスタから、同じポータル データベース インスタンスで参照される副クラスタに切り替えます。次に、主クラスタを更新して、ユーザを副クラスタから主クラスタに戻します。この切り替えは瞬時に行われるため、サイトがダウンすることはありません。ただし、この場合、実行中のユーザ セッションは切り替え中に失われます。
より高度なシナリオは、段階的な切り替えです。この方法ではまず、新しいセッションを副クラスタに切り替え、主クラスタに既存のユーザ セッションがなくなったところで、主クラスタをアップグレードします。段階的な切り替えは、ハードウェアおよびソフトウェアのさまざまな専用ロード バランサを使用して管理できます。どちらのシナリオにも、アプリケーションをデプロイする前に理解しておかなければならない一般的な概念があります。そのうちのポータル キャッシュ、および単一データベース インスタンスを使用する場合の影響について、以下で説明します。
ポータル アプリケーションに複数のクラスタをコンフィグレーションすると、同じデータベース インスタンスが共有されます。このデータベース インスタンスには、ポータルのコンフィグレーション データが格納されます。このことが問題となる場合があります。主クラスタをアップグレードすると、データベース内のポータル コンフィグレーション情報も変更されるのが普通だからです。これらの変更は、その後、ユーザが使用している副クラスタに取り込まれます。
たとえば、ポータル アプリケーションを新しいポートレットと共に主クラスタに再デプロイすると、そのポートレットのコンフィグレーション情報がデータベースに追加されます。この新しいポートレットは、その後、副クラスタに取り込まれます。ただしポートレットによって参照されている新しいコンテンツ (JSP ページまたはページフロー) は、副クラスタにはデプロイされません。
ポートレットは、デスクトップにある場合のみ呼び出されます。そのため、副クラスタでポートレットを有効にしても、ユーザに表示されるポータルにはすぐに反映されません。しかし、WebLogic Portal Administration Console を使用して新しいポートレットをデスクトップに追加すると、副クラスタ上のユーザに表示されるデスクトップにも、すぐに反映されます。この場合、そのポートレットは呼び出すことができますが、ポートレットのコンテンツは表示されません。
| ヒント : | 既存ポートレットのコンテンツ URI を、それがまだデプロイされていない新しい場所に更新することができます。このため、ポートレットのコンテンツ URI を更新する場合は注意が必要です。ベスト プラクティスは、コンテンツ URI の更新を段階的な更新の一部として行うことです。 |
2 つのポータル クラスタを同じデータベースに対して同時に実行する場合は、次の節で説明するように、ポータル キャッシュについても考慮する必要があります。
WebLogic Portal には、高度なクラスタ対応のキャッシュ機能が搭載されています。このキャッシュは、さまざまなポータル フレームワークによって、マークアップの定義からポートレット プリファレンスにいたるあらゆるもののキャッシュに使用されます。この他に、開発者も、ポータル キャッシュ フレームワークを使用して、独自のキャッシュを定義できます。
ポータル キャッシュの設定の詳細については、『WebLogic のポータル開発ガイド』を参照してください。
いずれのキャッシュ エントリについても、キャッシュの有効化または無効化、有効期限の設定、最大キャッシュ サイズの設定、キャッシュ全体のフラッシュ、特定のキーの無効化などを行うことができます。
キャッシュに格納されているポータル フレームワーク資産が更新されると、一般にデータベースに何らかの書き込みが行われ、クラスタ内のすべてのマシンのキャッシュが自動的に無効になります。このプロセスにより、すべての管理対象サーバのユーザに対するキャッシュの同期が維持されます。
アプリケーションを再デプロイメントするためにマルチ クラスタ環境を操作するときは、キャッシュに関して特別な注意を払う必要があります。キャッシュを無効にするメカニズムは、両方のクラスタで機能するわけではありません。したがって、データベースには書き込まれても、もう一方のクラスタに反映されないような変更を、片方のクラスタで行うことが可能になります。このような状況はシステムが不安定になる要因となるため、ユーザを移行している間は、両方のクラスタでキャッシュを無効にすることをお勧めします。この点は、既存のユーザ セッションが失われるハード スイッチではなく、クラスタ間の段階的な切り替えを行う場合に重要です。
  
|
![[環境とサービスの設定のカスタマイズ] ウィンドウ](wwimages/configwiz-11.gif)