プロダクション業務ユーザーズ ガイド
|
 |
 |
|
この章では、ポータル アプリケーションのデプロイ先となるクラスタを設定するための必要手順について説明します。この章のトピックは、以下のとおりです。
ポータル アプリケーションをプロダクションにデプロイするには、エンタープライズ品質のデータベース インスタンスを設定する必要があります。PointBase は、アプリケーションの設計、開発、および検証に関してのみサポートされています。プロダクション サーバのデプロイメントにはサポートされていません。
プロダクション データベースのコンフィグレーションの詳細については、『WebLogic Portal データベース管理ガイド』を参照してください。
エンタープライズ品質のデータベース インスタンスをコンフィグレーションしたら、『WebLogic Portal データベース管理ガイド』に記述されているように、コマンドラインから必要なデータベースの DDL および DML をインストールできます。しかし、もっと簡単な方法は、この章で説明するように、プロダクション環境をコンフィグレーションするときに、ドメインの Configuration Wizard を使用して DDL および DML を作成する方法です。
ドメインの Configuration Wizard でプロダクション サーバまたはプロダクション クラスタをコンフィグレーションする場合は、WebLogic Workshop で生成されて実行時にデプロイされるコンポーネントに必要な JMS キューをデプロイする必要があります。必要な JMS キューの名前を検索するには、ポータル アプリケーションの /META-INF ディレクトリにある wlw-manifest.xml ファイルを開きます。
このファイルで、<con:async-request-queue> および <con:async-request-error-queue> という要素に値として定義されている JMS キューの JNDI 名を検索します。これらの定義で見つかった JMS キューの JNDI 名は、プロダクション システムをコンフィグレーションするときに使用できるよう記録しておきます。
wlw-manifest.xml では、他の設定のコンフィグレーションも必要な場合があります。詳細については、「WebLogic Workshop アプリケーションをプロダクション サーバにデプロイするには」を参照してください。
ポータル アプリケーションをクラスタ化することで、そのアプリケーションの高可用性およびスケーラビリティが実現されます。以下の節を参考に、採用するクラスタ コンフィグレーションを選択してください。
ポータル アプリケーションのプロダクション インスタンスをサポートする場合、最も一般的に使用されるコンフィグレーションは、「推奨基本アーキテクチャ」です。
図 4-1 は、WebLogic Portal 専用の推奨基本アーキテクチャを示しています。
図 4-1 WebLogic Portal のシングル クラスタ アーキテクチャ
注意 : WebLogic Portal は、EJB と JSP が 1 つのクラスタ内で異なるサーバに分割される分割コンフィグレーション アーキテクチャをサポートしていません。Portal では、推奨基本アーキテクチャの方が、分割コンフィグレーションよりはるかに優れたパフォーマンスを実現します。
また、このアーキテクチャを使用すると、最初のプロダクション デプロイメントで 1 つのシングル サーバ インスタンスのみを実行する場合でも、必要な時点で新しいサーバ インスタンスを簡単に追加することができます。
マルチ クラスタ化されたアーキテクチャは、ポータル アプリケーションを常時アクセス可能にする必要がある場合に、ゼロ ダウンタイム環境をサポートするのに使用されます。シングル クラスタ環境では、ポータル アプリケーションを無期限に実行できる一方、クラスタやサーバに新しいコンポーネントをデプロイするときに、ポータルにアクセスできない時間が生じます。これは、新しい EAR アプリケーションが WebLogic Server にデプロイされる間、HTTP リクエストを処理できなくなるためです。ポータル アプリケーションを再デプロイする場合も、既存のセッションが失われます。
マルチ クラスタ環境には、一般に、主クラスタと副クラスタという 2 つのクラスタを設定する必要があります。通常の運用時は、すべてのトラフィックが主クラスタに送信されます。ポートレットなどの新しいコンポーネントをデプロイする必要があるときは、主クラスタを更新している間、副クラスタでリクエストを処理します。マルチクラスタ化された環境を管理および更新するプロセスは、シングル クラスタよりも複雑になります。これについては、「ゼロ ダウンタイムのアーキテクチャ」で説明しています。この環境に関心がある方は、ここを参照してください。
図 4-2 WebLogic Portal のマルチ クラスタ アーキテクチャ
Configuration Wizard でドメインをビルドする前に、ドメインのネットワーク レイアウトを決める必要があります。クラスタ内でコンフィグレーションする管理対象サーバの数、それらのサーバを実行するマシン、リスン ポート、および DNS アドレスを決定します。また、サーバの起動に WebLogic Node Manager を使用するかどうかも決定します。Node Manager の詳細については、『WebLogic Server のコンフィグレーションと管理』を参照してください。
WebLogic Portal は、クラスタの管理サーバ マシンとすべての管理対象サーバ マシンにインストールする必要があります。
ドメインの Configuration Wizard を使用して、新しいプロダクション環境を作成します。『コンフィグレーション ウィザードの使い方』を参照してください。
ここでは、WebLogic Portal のプロダクション クラスタ環境を作成する手順を説明します。
注意 : デフォルトの [All Local Addresses] をそのまま設定しないでください。
詳細については、『WebLogic Server クラスタ ユーザーズ ガイド』の「クラスタ アドレス」を参照してください。
[cgJMSPool-nonXA] タブおよび [portalPool] タブでも、同じ変更を行います。
[cgJMSPool-nonXA] の場合は、[Driver] フィールドで、必ず非 XA ドライバを選択してください。
警告 : データベース インスタンスにポータル データベース オブジェクトがすでに存在していると、スクリプトによってそれらが削除されるため、データベースをロードする際に警告が表示されます。この操作では、大量の SQL 文が表示されます。スクリプトは以前に作成されたオブジェクトがあれば削除するので、スクリプトの実行に伴い多数のエラー文が生成されますが、これは正常な動作です。
cgJMSStore_auto_1、cgJMSStore_auto_2 などの名前が付いています。 /META-INF/wlw-manifest.xml ファイルで検索できます。 これらの名前は、WEB_APP.queue.AsyncDispacher および WEB_APP.queue.AsyncDispacher_error のようになります。キューごとに、[追加] ボタンで新しい JMS 分散キューを追加します。wlw-manifest.xml でリストされた名前に、[Name] エントリと [JNDI name] エントリを設定します。[Load balancing policy] と [Forward delay] をアプリケーションにとって適切になるように設定します。
ポータル アプリケーションの 各 Web アプリケーション (ポータル Web プロジェクト) には、キュー エントリが 1 組ずつ存在します。終了したら、キューごとに分散キューを持つことになります。つまり、エンタープライズ アプリケーションに 3 つの Web アプリケーションがあれば、Web アプリケーションごとに 2 個ずつ、合計 6 個の分散キューを持つことになります。
WebLogic Administration Portal Web アプリケーション用のキューを作成する必要はありません。
注意 : 複数のクラスタを使用している場合は、クラスタごとにキューのセットを追加作成します。たとえば、basicWebApp という名前の Web アプリケーションで 2 つ目のクラスタを使用する場合は、そのクラスタ用に basicWebApp.queue.AsyncDispatcher.2 などの、ユニークな名前の basicWebApp キューを作成します。その際には、Configuration Wizard で、複数のキューに同じ JNDI 名を入力することはできません。この例では、JNDI 名の末尾に「.2」を入力します。このセットアップ手順では、各 Web アプリケーションの WebLogic Administration Console で JNDI 名を統一する方法について後述します。
ここまでの操作で、管理サーバ ドメインは、ドメインの Configuration Wizard によって構成されました。管理サーバを起動して他のコンフィグレーション作業を行う前に、次のいずれかまたは両方のセットアップ タスクを実行することができます。
管理サーバに割り当てられているデフォルトのメモリ サイズを増やすには、ドメインのルート ディレクトリにある startWebLogic スクリプトを修正して、メモリの引数を変更する必要があります。次に例を示します。
set MEM_ARGS=-Xms256m %memmax% を set MEM_ARGS=-Xms512m -Xmx512m に変更
MEM_ARGS="-Xms256m ${memmax}" を MEM_ARGS="-Xms512m -Xmx512m" に変更
サーバに割り当てる必要がある正確なメモリ容量は、ポータル アプリケーションのサイズなど、さまざまな要因に基づいて変化しますが、一般には、512 MB のデフォルトのメモリ容量が推奨されます。
認証なしでサーバを起動できるようにするには、ログインに使用するユーザ名とパスワードを含む boot.properties ファイルを、ドメインのルート ディレクトリに作成します。次に例を示します。
username=weblogic
password=weblogic
このファイルを使用してサーバを初めて起動した後に、ユーザ名とパスワードはファイル内で暗号化されます。
この手順では、JMS サーバのコンフィグレーションを完了します。
basicWebApp.queue.AsyncDispatcher.2 を選択)、[一般] タブをクリックして、「.2」サフィックス (または、Configuration Wizard で使用した他のユニークな識別子) を削除します。各 Web アプリケーションで、JNDI 名がすべて同じになります。たとえば、basicWebApp の JNDI 名はすべて basicWebApp.queue.AsyncDispatcher にする必要があります。変更するたびに、[適用] をクリックします。アプリケーションの META-INF/wlw-manifest.xml ファイルを参照して、作成する必要のあるキューを確認します。「wlw-manifest.xml ファイルの読み込み」を参照してください。
たとえば、basicWebApp と bigWebApp の 2 つの Web アプリケーションがある場合、管理サーバである JMS サーバ用に以下のキューを作成します。
basicWebApp.queue.AsyncDispatcher
basicWebApp.queue.AsyncDispatcher_error
bigWebApp.queue.AsyncDispatcher
bigWebApp.queue.AsyncDispatcher_error
jws.queue というキューが存在しない場合は、このキューも 1 つだけ作成する必要があります。
管理対象サーバを含めてドメインをコンフィグレーションしたので、各管理対象サーバのサーバ ルート ディレクトリを作成する必要があります。これには、管理対象サーバを管理サーバと同じマシン上に配置するか、または Node Manager を使用するかどうかによって、多数のオプションがあります。
config.xml は使用されません。その代わりに、管理サーバの config.xml ファイルが使用されます。「Node Manager を使用する場合」も参照してください。 WebLogic Portal をすべての管理対象サーバにインストールする必要があります。
managedServer1」、「managedServer2」などの名前を付けます。boot.properties ファイルを作成します。次に例を示します。username=weblogic
password=weblogic
管理対象サーバにファイル システム ドメイン ディレクトリを作成したら、startManagedWebLogic スクリプトに異なる servername パラメータを指定することで、同じマシンの他の管理対象サーバにも同じドメインを再利用できます。あるいは、ドメインの Configuration Wizard を使用して、新しい管理対象ドメインを作成することもできます。
注意 : 管理対象サーバに完全なドメインを使用しない場合 (つまり、ドメインレベル ディレクトリに全ファイルを含めない場合) は、サーバ ディレクトリの 1 階層上のディレクトリ (ドメインレベル ディレクトリに相当) に、wsrpKeystore.jks のコピーを必ず保存または配置してください。
WebLogic Portal ドメインで Node Manager を使用する場合、次の手順を実行する必要があります。
wsrpKeystore.jks ファイルを、各管理対象サーバ ホストの WEBLOGIC_HOME/common/nodemanager/wsrpKeystore.jks にコピーする。WebLogic Portal では、各管理対象サーバのルート ディレクトリの「1 つ上のディレクトリ」に wsrpKeystore.jks ファイルが存在する必要があります。デフォルトでは、Node Manager は WEBLOGIC_HOME/common/nodemanager のサブディレクトリでサーバを実行します。たとえば、WEBLOGIC_HOME/common/nodemanager/ms1 などです。CLASSPATH にあることを確認する。WEBLOGIC_HOME/server/libwlxbean.jar および WEBLOGIC_HOME/server/lib/xqrl.jar
この CLASSPATH の設定方法については、WebLogic Server ドキュメント「クラスパスへの起動クラスおよび停止クラスの追加」を参照してください。
管理対象サーバに割り当てられているデフォルトのメモリ サイズを増やすには (Node Manager を使用していない場合)、管理対象サーバのルート ディレクトリにある startManagedWebLogic スクリプトを修正して、メモリの引数を変更する必要があります。次に例を示します。
set MEM_ARGS=-Xms256m %memmax% を set MEM_ARGS=-Xms512m -Xmx512m に変更
MEM_ARGS="-Xms256m ${memmax}" を MEM_ARGS="-Xms512m -Xmx512m" に変更
サーバに割り当てる必要がある正確なメモリ容量は、ポータル アプリケーションのサイズなど、さまざまな要因に基づいて変化しますが、一般には、512 MB のデフォルトのメモリ容量が推奨されます。
この節では、管理サーバに依存する WebLogic Portal のコンポーネントについて説明します。この情報は、管理サーバが何らかの理由で一時的に無効になった場合に役立ちます。この節では、クラスタ デプロイメント時の、管理サーバを安全に停止できるタイミングおよび管理サーバの役割について説明します。
次の機能を「除く」すべての WebLogic Portal 機能が、管理サーバがオフラインの状態で正常に機能します。
クラスタに WebLogic Portal アプリケーションをデプロイするときは、管理サーバが実行されている必要があります。これは、WebLogic Portal アプリケーションの datasync データのマスター コピーが管理サーバにあるためです。
クラスタ デプロイメント後、管理サーバを停止した場合、管理対象サーバを再起動またはウォームアップすることなく管理サーバを再起動できます。管理サーバまたはバックアップ管理サーバを再起動するときに、クラスタを再起動する必要はありません。ウォームアップは不要です。この場合、WebLogic Server の discoverManagedServer オプションを有効にする必要があります。
注意 : 管理サーバをオフラインにする前に、いずれかの管理対象サーバで少なくとも 1 回、ブラウザでポータル Web アプリケーションと Administration Portal にアクセスする必要があります。このときの最初のアクセスで、特定のポリシー情報がブートストラップされ、データベースに格納されます。この最初のアクセスの後は、再びこのアクセス操作を行うことなくいつでも管理サーバをオフラインにできます。
Administration Portal を使用して新しいデスクトップを作成する場合は、管理サーバがオンラインになっている必要があります。ただし、管理サーバがオフラインの状態でも、Administration Portal を使用して新しいページの追加やポートレットの配置調整を行うことはできます。
管理サーバがオフラインの場合、管理対象サーバが管理サーバに接続しようとすると例外が発生します。これらの例外は管理対象サーバのログに記録されます。
ポータル ライブラリには、ブック、ページ、レイアウト、ポートレット、デスクトップなど、ポータル固有のリソースがあります。WebLogic Administration Portal を使用すると、これらのリソースの作成、変更、資格付与、調整を行って、エンド ユーザがアクセスするポータル デスクトップを形成できます。
図 4-3 は、WebLogic Administration Portal で表示したポータル リソース ツリーのイメージです。ツリーには、ライブラリ ノードとポータル ノードの 2 つの主要なノードがあります。ライブラリ ノードにはポートレットなどのリソースのグローバル セットが含まれていますが、ポータル ノードには、それらのリソースのインスタンスとして、colorsSample デスクトップとそのページ、ブックおよびポートレットなどが含まれています。
これらのリソースはそれぞれポータル データベースで部分的に定義されているため、実行時に簡単に変更できます。存在するリソースの大部分は管理者に新規に作成されたか、または WebLogic Workshop で作成された既存の .portal テンプレートから新しいデスクトップを作成することにより作成されたものです。
ただし、ポートレット自体は開発者によって作成され、最初は XML ファイルとして格納されます。プロダクション環境では、ポータル アプリケーションに存在するすべての .portlet ファイルがデータベースに自動的に読み込まれ、WebLogic Administration Portal で使用できるようになります。
以下の節では、ポートレットのライフサイクルおよびストレージ メカニズムについて説明します。ポートレットのデプロイメント プロセスは、ポータルの運用および管理において重要です。
開発時段階では、.portlet ファイルは XML として、ポータル EAR の既存のポータル Web アプリケーションに格納されます。開発者が新しい .portlet ファイルを作成すると、ファイル ポーラー スレッドによって変更内容がモニタされ、開発データベースが .portlet 情報とともにロードされます。
プロダクション環境では、.portlet ファイルを保持するポータル Web アプリケーションを管理サーバに再デプロイするときに .portlet ファイルがロードされます。この再デプロイメントのタイミングにより、.portlet ファイルがポータル ライブラリで使用可能になると同時に、JSP やページフローなどのポートレットのコンテンツも使用可能になります。管理サーバがデータベースの更新を担うマスターとして選択されているため、プロダクション クラスタ内のそれぞれのサーバが、新しいポートレット情報をデータベースに同時に書き込もうとする問題は発生しません。新しいポートレットをプロダクション環境にデプロイするときは、再デプロイメント用のポータル アプリケーションを管理サーバに割り当てます。
ポートレットがデータベースにロードされると、ポートレットの XML が解析され、ポートレット情報が入った複数のテーブルが生成されます (PF_PORTLET_DEFINITION、PF_MARKUP_DEFINITION、PF_PORTLET_INSTANCE、PF_PORTLET_PREFERENCE、L10N_RESOURCE、L10N_INTERSECTION など)。
PF_PORTLET_DEFINITION はポートレットのマスター レコードで、ポートレットに定義された定義ラベル、フォーク可能設定、編集 URI、ヘルプ URI などのプロパティ行を保持します。定義ラベルおよび Web アプリケーション名は、ポートレットの一意の識別レコードです。ポートレット定義は、PF_MARKUP_DEF に格納されている残りのポートレットの実際の XML を参照します。
PF_MARKUP_DEF は、.portlet ファイルの格納済みのトークン化された XML を保持します。つまり、.portlet XML がデータベース内で解析され、プロパティがトークンに置き換わります。たとえば、次のコード例ではトークン化されたポートレットを示します。
<netuix:portlet $(definitionLabel) $(title) $(renderCacheable) $(cacheExpires)>
これらのトークンは、PF_PORTLET_DEFINITION のマスター定義テーブルの値、または PF_PORTLET_INSTANCE に格納されているポートレットのカスタマイズされたインスタンスによって置換されます。
次の 4 種類のポートレット インスタンスがデータベースに記録されることにより、ポートレットのプロパティが格納されます。
PF_PORTET_INSTANCE は、DEFAULT_MINIMIZED、TITLE_BAR_ORIENTATION、PORTLET_LABEL などの属性に関するポートレットのプロパティを保持します。
ポートレットに定義済みのポートレット プリファレンスがある場合、それらは PF_PORTLET_PREFERENCE テーブルに格納されます。
最後に、ポートレットのタイトルはインターナショナライズできます。これらの名前は、L10N_INTERSECTION によって PF_PORTLET_DEFINITION にリンクされている L10N_ RESOURCE テーブルに格納されます。
新しくデプロイしたポータル アプリケーションからポートレットを削除する際に、そのポートレットがプロダクション データベースにすでに定義されている場合は、PF_PORTLET_DEFINITION テーブルで IS_PORTLET_FILE_DELETED とマークされます。WebLogic Administration Portal では、削除されたポートレットはグレー表示になります。削除されたポートレットがデスクトップ インスタンスにまだ表示されている場合は、ユーザがそのポートレットへのリクエストを発行すると、ポートレットが使用不可であることを示すメッセージが表示されます。
WebLogic Server クラスタにポータル アプリケーションを再デプロイする際の制約は、再デプロイメントを実行している間、ユーザがサイトにアクセスできないことです。停止時間を設けてポータル アプリケーションを新しいポートレットや他のコンポーネントで更新することが不可能なエンタープライズ環境では、マルチ クラスタ コンフィグレーションを使用することで、再デプロイメント中もポータル アプリケーションを実行させておくことができます。
マルチ クラスタ環境の基本は、主クラスタでポータル アプリケーションを更新している間、ユーザ リクエストがルートされる副クラスタがあるという概念です。
通常の運用時は、図 4-4 に示すように、すべてのトラフィックが主クラスタに送信されます。トラフィックは、正常な状態である限り、副クラスタには送信されません。この 2 つのクラスタは、同じセッション キャッシュを使用できないためです。トラフィックが両方のクラスタに送信されている場合に、一方のクラスタに障害が発生すると、障害が発生したクラスタでセッション中だったユーザはもう一方のクラスタにルートされるため、そのユーザのセッション キャッシュは失われます。
図 4-4 通常の運用時は、トラフィックは主クラスタに送信される
図 4-5 に示すように、すべてのトラフィックを副クラスタにルートし、その後で主クラスタを新しいポータル EAR で更新します。この EAR には、データベースにロードされる新しいポートレットが格納されています。副クラスタへのリクエストのルーティングは、段階的に行われます。最初に、主クラスタに対する既存のリクエストを、他のリクエストがなくなるまで、ある程度の時間をかけて終了させなければなりません。それが完了した時点で、主クラスタを新しいポータル アプリケーションで更新できます。
図 4-5 トラフィックが副クラスタにルートされ、主クラスタが更新される
図 4-6 に示すように、すべてのトラフィックのルートを主クラスタに戻し、その後で副クラスタを新しい EAR で更新します。データベースは主クラスタを更新したときに更新されているため、副クラスタの更新時にはデータベースは更新されません。
図 4-6 トラフィックのルートが主クラスタに戻され、副クラスタが更新される
正常な状況では副クラスタはトラフィックを受信しませんが、それでも現行のポータル アプリケーションで副クラスタを更新する必要があります。ポータル アプリケーションを次に更新するときに、副クラスタが一時的にリクエストを受信することになるため、現行のアプリケーションを使用できるようにしておく必要があります。
以上をまとめると、マルチ クラスタ ポータル環境をアップグレードするには、まずトラフィックを主クラスタから、同じポータル データベース インスタンスで参照される副クラスタに切り替えます。次に、主クラスタを更新して、ユーザを副クラスタから主クラスタに戻します。この切り替えは瞬時に行われるため、サイトがダウンすることはありません。ただし、この場合、実行中のユーザ セッションは切り替え中に失われます。
より高度なシナリオは、段階的な切り替えです。この方法ではまず、新しいセッションを副クラスタに切り替え、主クラスタに既存のユーザ セッションがなくなったところで、主クラスタをアップグレードします。段階的な切り替えは、ハードウェアおよびソフトウェアのさまざまな専用ロード バランサを使用して管理できます。どちらのシナリオにも、アプリケーションをデプロイする前に理解しておかなければならない一般的な概念があります。そのうちのポータル キャッシュ、および単一データベース インスタンスを使用する場合の影響について、以下で説明します。
ポータル アプリケーションに複数のクラスタをコンフィグレーションすると、同じデータベース インスタンスが共有されます。このデータベース インスタンスには、ポータルのコンフィグレーション データが格納されます。このことが問題となる場合があります。主クラスタをアップグレードすると、データベース内のポータル コンフィグレーション情報も変更されるのが普通だからです。これらの変更は、その後、ユーザが使用している副クラスタに取り込まれます。
たとえば、ポータル アプリケーションを新しいポートレットとともに主クラスタに再デプロイすると、そのポートレットのコンフィグレーション情報がデータベースに追加されます。この新しいポートレットは、その後、副クラスタに取り込まれます。ただしポートレットによって参照されている新しいコンテンツ (JSP ページまたはページフロー) は、副クラスタにはデプロイされません。
ポートレットは、デスクトップにある場合のみ呼び出されます。そのため、副クラスタでポートレットを有効にしても、ユーザに表示されるポータルにはすぐに反映されません。しかし、WebLogic Administration Portal を使用して新しいポートレットをデスクトップに追加すると、副クラスタ上のユーザに表示されるデスクトップにも、すぐに反映されます。この場合、そのポートレットは呼び出すことができますが、ポートレットのコンテンツは表示されません。
このような状況に対応するには、いくつかの方法があります。その 1 つは、すべてのユーザが主クラスタに戻されるまで、デスクトップにポートレットを追加するのを遅らせる方法です。もう 1 つの方法は、副クラスタ上のユーザに表示されないように、ライブラリ内でポートレットに資格を与えます。その後、ポートレットをデスクトップに追加し、すべてのユーザが主クラスタに戻されたら、資格を削除するか、変更します。
ヒント : 既存ポートレットのコンテンツ URI を、それがまだデプロイされていない新しい場所に更新することができます。このため、ポートレットのコンテンツ URI を更新する場合は注意が必要です。ベスト プラクティスは、コンテンツ URI の更新を段階的な更新の一部として行うことです。
2 つのポータル クラスタを同じデータベースに対して同時に実行する場合は、次の節で説明するように、ポータル キャッシュについても考慮する必要があります。
WebLogic Portal には、高度なクラスタ対応のキャッシュ機能が搭載されています。このキャッシュは、さまざまなポータル フレームワークによって、マークアップの定義からポートレット プリファレンスにいたるあらゆるもののキャッシュに使用されます。この他に、開発者も、ポータル キャッシュ フレームワークを使用して、独自のキャッシュを定義できます。ポータル キャッシュは、WebLogic Administration Console で、[コンフィグレーション設定｜サービス管理｜Cache Manager] でコンフィグレーションします。いずれのキャッシュ エントリについても、キャッシュの有効化または無効化、有効期限の設定、最大キャッシュ サイズの設定、キャッシュ全体のフラッシュ、特定のキーの無効化などを行うことができます。
キャッシュに格納されているポータル フレームワーク資産が更新されると、一般にデータベースに何らかの書き込みが行われ、クラスタ内のすべてのマシンのキャッシュが自動的に無効になります。このプロセスにより、すべての管理対象サーバのユーザに対するキャッシュの同期が維持されます。
アプリケーションを再デプロイメントするためにマルチ クラスタ環境を操作するときは、キャッシュに関して特別な注意を払う必要があります。キャッシュを無効にするメカニズムは、両方のクラスタで機能するわけではありません。したがって、データベースには書き込まれても、もう一方のクラスタに反映されないような変更を、片方のクラスタで行うことが可能になります。このような状況はシステムが不安定になる要因となるため、ユーザを移行している間は、両方のクラスタでキャッシュを無効にすることをお勧めします。この点は、既存のユーザ セッションが失われるハード スイッチではなく、クラスタ間の段階的な切り替えを行う場合に重要です。
|
|
|
