test

Sun Java System Application Server Enterprise Edition 8.1 2005Q2 高可用性 (HA) 管理ガイド

HTTP セッションフェイルオーバー

J2EE アプリケーションは一般に、大量のセッション状態データを保持しています。Web ショッピングカートは、セッション状態の古典的な例です。アプリケーションはまた、頻繁に必要になるデータをセッションオブジェクトにキャッシュすることもできます。実際、ユーザーとの対話が多いほぼすべてのアプリケーションには、セッション状態の保持が必要になります。

Web コンテナの可用性の設定

asadmin を使用して Web コンテナの可用性の有効化と設定を行うには、configure-ha-persistence(1) を参照してください。

あるいは、asadmin set コマンドを使用して、設定の availability-service.web-container-availability.availability-enabled プロパティーを true に設定し、次に configure-ha-persistence を使用して必要に応じてプロパティーを設定します。

たとえば、set コマンドを使用して次のように指定します。ここで、config1 は設定の名前です。


asadmin set --user admin --passwordfile password.txt 
--host localhost --port 4849 
config1.availability-service.web-container-availability.availability-enabled="true"
asadmin configure-ha-persistence --user admin --passwordfile secret.txt 
--type ha 
--frequency web-method 
--scope modified-session 
--store jdbc/hastore 
--property maxSessions=1000:reapIntervalSeconds=60 cluster1

Procedure管理コンソールを使用して Web コンテナの可用性を有効にする

  1. ツリーコンポーネントで、目的の設定を選択します。

  2. 「可用性サービス」をクリックします。

  3. 「Web コンテナの可用性」タブを選択します。

    「可用性サービス」ボックスにチェックマークを付けて、可用性を有効にします。無効にするには、このボックスのチェックマークを外します。

  4. 「可用性の設定」の説明に従って、ほかの設定を変更します。

  5. サーバーインスタンスを再起動します。

可用性の設定

「可用性サービス」の「Web コンテナの可用性」タブを使用すると、次の可用性設定を変更できます。

持続性のタイプ: 可用性が有効になっている SFSB のセッション持続性と不活性化メカニズムを指定します。使用できる値は、memory (持続性なし) file (ファイルシステム)、および ha (HADB) です。

ha セッション持続性を使用するには、HADB を設定し、有効にしておく必要があります。設定の詳細については、configure-ha-cluster(1) を参照してください。

Web コンテナの可用性が有効になっている場合、デフォルトは ha です。それ以外の場合、デフォルトは memory です。セッションの持続性が必要となる本稼動環境では、ha を使用します。最初の 2 つのタイプ (memory および file 持続性) では、高可用性セッション持続性は提供されません。

持続性の頻度: セッション状態を格納する頻度を指定します。持続性のタイプが ha の場合にのみ適用できます。使用できる値は次のとおりです。

持続性のスコープ: 格納するセッションオブジェクトの範囲と、セッション状態を格納する頻度を指定します。持続性のタイプが ha の場合にのみ適用できます。使用できる値は次のとおりです。

シングルサインオン状態: シングルサインオン状態の持続性を有効にするには、このボックスにチェックマークを付けます。無効にするには、このボックスのチェックマークを外します。詳細については、「セッションフェイルオーバーでのシングルサインオンの使用」を参照してください。

HTTP セッションストア: セッションの持続性のために HADB への接続に使用する JDBC リソースを変更した場合は、HTTP セッションストアを変更できます。詳細については、configure-ha-cluster(1) を参照してください。

個々の Web アプリケーションの可用性の設定

個々の Web アプリケーションの可用性の有効化と設定を行うには、アプリケーション配備記述子ファイル sun-web.xml を編集します。アプリケーションの配備記述子の設定は、Web コンテナの可用性の設定より優先されます。

session-manager 要素の persistence-type 属性によって、アプリケーションが使用するセッション持続性のタイプが決定されます。高可用性セッション持続性を有効にするには、この属性を ha に設定する必要があります。

sun-web.xml ファイルの詳細については、『Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Developer’s Guide』の「The sun-web.xml File」を参照してください。

例

<sun-web-app> ... 
  <session-config> 
    <session-manager persistence-type=ha> 
      <manager-properties> 
        <property name=persistenceFrequency value=web-method /> 
      </manager-properties> 
      <store-properties> 
        <property name=persistenceScope value=session /> 
      </store-properties> 
    </session-manager> ... 
</session-config> ...

セッションフェイルオーバーでのシングルサインオンの使用

単一のアプリケーションサーバーインスタンスにおいて、ユーザーがあるアプリケーションによって一度認証されると、同じインスタンス上で動作しているほかのアプリケーションに対する個別の再認証は必要ありません。これをシングルサインオンといいます。詳細については、『Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Developer’s Guide』の「User Authentication for Single Sign-on」を参照してください。

HTTP セッションがクラスタ内のほかのインスタンスにフェイルオーバーした場合でも、シングルサインオンが機能し続けるようにするには、シングルサインオン情報が HADB に対して持続される必要があります。シングルサインオン情報を持続させるには、最初にサーバーインスタンスと Web コンテナの可用性を有効にし、次にシングルサインオン状態のフェイルオーバーを有効にします。

シングルサインオン状態のフェイルオーバーは、「可用性サービス」の「Web コンテナの可用性」タブにある管理コンソールを使用して有効にできます。「Web コンテナの可用性の設定」で説明しているように、asadmin set コマンドを使用して、設定の availability-service.web-container-availability.sso-failover-enabled プロパティーを true に設定します。

たとえば、set コマンドを使用して次のように指定します。ここで、config1 は設定の名前です。

asadmin set --user admin --passwordfile password.txt 
--host localhost --port 4849 
config1.availability-service.web-container-availability.
sso-failover-enabled="true"

シングルサインオングループ

単一の名前とパスワードの組み合わせによってアクセス可能なアプリケーションは、シングルサインオングループを構成します。シングルサインオングループに属するアプリケーションに対応する HTTP セッションでは、1 つのセッションがタイムアウトになった場合、ほかのセッションは無効化されず、引き続き有効となります。これは、1 つのセッションがタイムアウトしてもほかのセッションの可用性には影響しないからです。

この動作の当然の結果として、あるセッションがタイムアウトして、セッションを実行していた同じブラウザウィンドウから対応するアプリケーションにアクセスを試みる場合、再度認証を行う必要はありません。ただし、新しいセッションが作成されます。

シングルサインオングループに属するショッピングカートアプリケーションの例を挙げます。このグループにはほかに 2 つのアプリケーションが含まれます。ほかの 2 つのアプリケーションのセッションタイムアウト値は、ショッピングカートアプリケーションのセッションタイムアウト値を上回るものと仮定します。ショッピングカートアプリケーションのセッションがタイムアウトして、セッションを実行していた同じブラウザウィンドウからショッピングカートアプリケーションの実行を試みる場合、再度認証を行う必要はありません。ただし、以前のショッピングカートは失われていて、新しいショッピングカートを作成する必要があります。ほかの 2 つのアプリケーションは、ショッピングカートアプリケーションを実行していたセッションのタイムアウト後も変わらず動作し続けます。

同様に、ほかの 2 つのアプリケーションのどちらかに対応するセッションがタイムアウトしたとします。セッションを実行していた同じブラウザウィンドウからアプリケーションに接続している間は、再度認証を行う必要はありません。

注 –

この動作は、セッションがタイムアウトした場合にのみ当てはまります。シングルサインオンが有効になっていて、HttpSession.invalidate() を使用してセッションの 1 つを無効にする場合、シングルサインオングループに属するすべてのアプリケーションのセッションが無効になります。シングルサインオングループに属する任意のアプリケーションへのアクセスを試みる場合、再認証が必要であり、アプリケーションにアクセスするクライアントに対して新しいセッションが作成されます。