WebSphere Portal での HTTP セッション・マネージャーの構成

WebSphere® Portal の HTTP セッションをデータ・グリッドに保持できます。

始める前に

WebSphere eXtreme Scale クライアント と WebSphere Portal 環境が、次の要件を満たしている必要があります。

このタスクについて

WebSphere DataPower® XC10 アプライアンス を WebSphere Portal 環境に導入することは、以下の シナリオでメリットがあります。
重要: 以下のシナリオでは、 メリットについて紹介しますが、WebSphere DataPower XC10 アプライアンス を環境に 導入することにより、WebSphere Portal 層での プロセッサー使用量が増える場合もあります。

手順

  1. セッションをデータ・グリッドに格納できるように、wps WebSphere Portal アプリケーションと任意のカスタム・ポートレットを構成します。

    詳しくは、データ・グリッド (data grid)へのセッション・パーシスタンスの作成を参照してください。この操作により、カスタム・ポートレットが接合され、データ・グリッドでセッション・パーシスタンスが有効になります。

  2. WebSphere Portal サーバーとアプライアンスに対して Transport Layer Security/Secure Sockets Layer (TLS/SSL) が構成されている場合は、TLS/SSL トラストストアを構成する必要があります。
    • この結果、WebSphere Portal サーバーからアプライアンスへのアウトバウンド通信で TL/SSL 通信が使用される場合は、アプライアンス証明書を WebSphere Application Server 構成に追加する必要があります。以下のように addXC10PublicCert.py スクリプトを使用します。このスクリプトは was_root/bin ディレクトリーにあります。
      wsadmin.bat -conntype SOAP -port <PORTAL_SERVER_SOAP_PORT> -lang jython 
      -user wpsadmin -password wpsadmin -f addXC10PublicCert.py
    • この結果、アプライアンスから WebSphere Portal サーバーへのインバウンド通信で TLS/SSL が使用される場合、WebSphere Portal サーバーの公開証明書を組み込むようにアプライアンス・トラストストアを更新してください。トラストストアを更新することで、アプライアンスと WebSphere Portal の間の通信が可能になります。
    1. Portal Server 個人証明書の公開鍵を抽出します。 IKEYMAN ユーティリティーを使用します。 このユーティリティーにより .arm ファイルが作成されます。詳しくは、『トラストストア・ファイル用の公開証明書の抽出』を参照してください。
    2. アプライアンスのパブリック・トラストストアをダウンロードします。 詳しくは、Transport Layer Security (TLS) の構成を参照してください。
    3. iKeyman ユーティリティーを使用して、アプライアンスから抽出した truststore.jks ファイルを、.arm ファイル内の Portal Server 公開証明書で更新します。 詳しくは、『署名者証明書のインポート』を参照してください。
    4. 更新したトラストストア・ファイルをアプライアンスにアップロードします。 トラストストアをアップロードした後に、「TLS 設定の送信」をクリックします。TLS 設定を送信し、新規トラストストアが集合内の他のアプライアンスに追加されると、集合が自動的に再始動します。詳しくは、Transport Layer Security (TLS) の構成を参照してください。
  3. WebSphere Portal Server を再始動します。 詳しくは、『WebSphere Portal Version 7: Starting and stopping servers, deployment managers, and node agents (WebSphere Portal バージョン 7: サーバー、デプロイメント・マネージャー、およびノード・エージェントの開始と停止)』を参照してください。

タスクの結果

WebSphere Portal Server にアクセスでき、構成されているカスタム・ポートレットの HTTP セッション・データはデータ・グリッドに保持されます。
アプリケーション・セッション・データを ホスティングしている全データ・グリッドに Web コンテナー・クライアントから到達できない場合、クライアントは、 代わりに WebSphere Application Server の基本 Web コンテナーをセッション管理に使用します。 次のようなシナリオでは、データ・グリッドに到達できないことがあります。
  • Web コンテナーとリモート・コンテナー・サーバー間のネットワークの問題
  • リモート・コンテナー・サーバーのプロセスが停止した場合
sessionTableSize パラメーターによって 指定される、メモリー内に保持されるセッション参照の数は、セッションが基本 Web コンテナー内に 保管されている場合、そのまま維持されます。 セッション数が sessionTableSize の値を超えると、最長未使用時間を基にセッションが Web コンテナー・セッション・キャッシュで無効化されます。リモート・データ・グリッドが使用可能になると、Web コンテナー・キャッシュで 無効化されたセッションは、リモート・データ・グリッドからデータを取得し、データを 新規セッションにロードできます。リモート・データ・グリッド全体が使用不可なまま、セッションが セッション・キャッシュで無効化されると、ユーザーのセッション・データは失われます。このような問題があるため、負荷の下で システムを実行する場合、実動リモート・データ・グリッド全体をシャットダウンすることはしないでください。