第24章 高可用性の設定

24.1. 高可用性

JBoss EAP はデプロイされた Jakarta EE アプリケーションの可用性を保証するために以下の高可用性サービスを提供します。

ロードバランシング
複数のサーバーにワークロードを分散し、サービスが大量のリクエストを処理できるようにします。リクエストが大量に発生しても、クライアントはサービスからタイムリーに応答を受け取ることができます。
フェイルオーバー
ハードウェアやネットワークの障害が発生してもクライアントのサービスへのアクセスが中断しないようにします。サービスに障害が発生すると、別のクラスターメンバーがクライアントのリクエストを引き継ぎ、処理が続行されます。

クラスタリングはこれらすべての機能を包括する言葉です。クラスターのメンバーを設定すると、ロードバランシングと呼ばれるワークロードの共有や、フェイルオーバーと呼ばれる他のクラスターメンバーの障害時におけるクライアント処理の引き継ぎを行うことができます。

注記

選択した JBoss EAP の操作モード (スタンドアロンサーバーまたは管理対象ドメイン) によってサーバーの管理方法が異なることに注意してください。操作モードに関係なく JBoss EAP で高可用性サービスを設定できます。

JBoss EAP は、さまざまなコンポーネントを使用した異なるレベルの高可用性をサポートします。高可用性を実現できるランタイムのコンポーネントおよびアプリケーションの一部は以下のとおりです。

  • アプリケーションサーバーのインスタンス
  • 内部 JBoss Web Server、Apache HTTP Server、Microsoft IIS、または Oracle iPlanet Web Server と併用される Web アプリケーション
  • ステートフルおよびステートレスセッション Enterprise JavaBean (EJB)
  • シングルサインオン (SSO) メカニズム
  • HTTP セッション
  • JMS サービスおよびメッセージ駆動型 Bean (MDB)
  • シングルトン MSC サービス
  • シングルトンデプロイメント

JBoss EAP では、jgroupsinfinispan、および modcluster サブシステムによってクラスタリングが使用できるようになります。ha および full-ha プロファイルではこれらのシステム有効になっています。JBoss EAP では、これらのサービスは必要に応じて起動およびシャットダウンしますが、分散可能と設定されたアプリケーションがサーバーにデプロイされた場合のみ起動します。

アプリケーションを分散可能とする 方法は、JBoss EAP『開発ガイド 』を参照してください。

24.2. JGroups を用いたクラスター通信

24.2.1. JGroups

JGroups は信頼できるメッセージングのためのツールキットで、お互いにメッセージを送信するノードを持つクラスターを作成するために使用できます。

jgroups サブシステムは JBoss EAP で高可用性サービスのグループ通信サポートを提供します。これにより、名前付きのチャネルおよびプロトコルスタックを設定でき、チャネルのランタイム統計を表示することもできます。jgroups サブシステムは高可用性の機能を提供する設定を使用する場合に使用できます (管理対象ドメインでは hafull-ha プロファイル、スタンドアロンサーバーは standalone-ha.xmlstandalone-full-ha.xml 設定ファイルなど)。

JBoss EAP には 2 つの JGroups スタックが事前に設定されています。

udp
クラスターのノードは UDP (User Datagram Protocol) マルチキャストを使用してお互いに通信します。これはデフォルトのスタックです。
tcp
クラスターのノードは TCP (Transmission Control Protocol) を使用してお互いに通信します。
注記

TCP はエラーのチェック、パケットの順番、および輻輳制御を処理するため、TCP のオーバーヘッドは UDP よりも大きく、速度も遅くなると考えられます。JGroups は UDP のこれらの機能を処理しますが、TCP はこれらの機能を独自で処理します。信頼できないネットワークや輻輳度の高いネットワークで JGroups を使用する場合やマルチキャストが使用できない場合は、TCP を選択するとよいでしょう。

事前設定されたスタックを使用できますが、システムの要件に合うように独自に定義をすることもできます。使用できるプロトコルとそれらの属性については、以下の項を参照してください。

24.2.2. デフォルトの JGroups チャネルが TCP を使用するよう設定

デフォルトでは、クラスターノードは UDP プロトコルを使用して通信します。デフォルトの ee JGroups は事前定義された udp プロトコルスタックを使用します。

<channels default="ee">
  <channel name="ee" stack="udp"/>
</channels>
<stacks>
  <stack name="udp">
    <transport type="UDP" socket-binding="jgroups-udp"/>
    <protocol type="PING"/>
    ...
  </stack>
  <stack name="tcp">
    <transport type="TCP" socket-binding="jgroups-tcp"/>
    <protocol type="MPING" socket-binding="jgroups-mping"/>
    ...
  </stack>
</stacks>

一部のネットワークでは TCP のみを使用できます。以下の管理 CLI コマンドを使用して、ee チャネルが事前設定された tcp スタックを使用するようにします。

/subsystem=jgroups/channel=ee:write-attribute(name=stack,value=tcp)

このデフォルトの tcp スタックは、IP マルチキャストを使用して初期クラスターメンバーシップを検出する MPING プロトコルを使用します。他のメンバーシップ検出プロトコルに対してスタックを設定する場合は以下の項を参照してください。

  • TCPPING プロトコルを使用して静的クラスターメンバーシップのリストを定義する。
  • TCPGOSSIP プロトコルを使用し、外部ゴシップルーターを使ってクラスターのメンバーを検出する。
  • JDBC_PING プロトコルを使用し、データベースを使ってクラスターのメンバーを検出する。

24.2.3. TCPPING の設定

この手順は TCPPING プロトコルを使用する新しい JGroups スタックを作成し、静的クラスターメンバーシップのリストを定義します。ベーススクリプトは、tcpping スタックを作成し、この新しいスタックを使用するようデフォルトの ee チャネルを設定します。このスクリプトの管理 CLI コマンドは環境に合わせてカスタマイズする必要があり、バッチで処理されます。

  1. 以下のスクリプトをテキストエディターにコピーし、ローカルファイルシステムに保存します。

    # Define the socket bindings
    /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=jgroups-host-a:add(host=HOST_A,port=7600)
    /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=jgroups-host-b:add(host=HOST_B,port=7600)
    batch
    # Add the tcpping stack
    /subsystem=jgroups/stack=tcpping:add
    /subsystem=jgroups/stack=tcpping/transport=TCP:add(socket-binding=jgroups-tcp)
    /subsystem=jgroups/stack=tcpping/protocol=TCPPING:add(socket-bindings=[jgroups-host-a,jgroups-host-b])
    /subsystem=jgroups/stack=tcpping/protocol=MERGE3:add
    /subsystem=jgroups/stack=tcpping/protocol=FD_SOCK:add
    /subsystem=jgroups/stack=tcpping/protocol=FD_ALL:add
    /subsystem=jgroups/stack=tcpping/protocol=VERIFY_SUSPECT:add
    /subsystem=jgroups/stack=tcpping/protocol=pbcast.NAKACK2:add
    /subsystem=jgroups/stack=tcpping/protocol=UNICAST3:add
    /subsystem=jgroups/stack=tcpping/protocol=pbcast.STABLE:add
    /subsystem=jgroups/stack=tcpping/protocol=pbcast.GMS:add
    /subsystem=jgroups/stack=tcpping/protocol=MFC:add
    /subsystem=jgroups/stack=tcpping/protocol=FRAG2:add
    # Set tcpping as the stack for the ee channel
    /subsystem=jgroups/channel=ee:write-attribute(name=stack,value=tcpping)
    run-batch
    reload

    定義されたプロトコルの順番が重要になることに注意してください。また、add-index の値を add コマンドに渡すと、特定のインデックスでプロトコルを挿入できます。インデックスはゼロベースであるため、以下の管理 CLI コマンドは UNICAST3 プロトコルを 7 つ目のプロトコルとして追加します。

    /subsystem=jgroups/stack=tcpping/protocol=UNICAST3:add(add-index=6)
  2. 環境に合わせてスクリプトを変更します。

    • 管理対象ドメインで実行している場合は、/subsystem=jgroups コマンドの前に /profile=PROFILE_NAME を追加し、更新するプロファイルを指定する必要があります。
    • 以下のプロパティーを環境に合わせて調整します。

      • socket-bindings: ウェルノウンとして見なされ、最初のメンバーシップの検索に利用できるホストとポートの組み合わせのカンマ区切りリスト。ソケットバインディングの定義に関する詳細は、「ソケットバインディングの設定」を参照してください
      • initial_hosts: ウェルノウンとして見なされ、最初のメンバーシップの検索に使用できる HOST[PORT] という構文を使用したホストとポートの組み合わせのカンマ区切りリスト (例: host1[1000],host2[2000])。
      • port_range: このプロパティーは、 initial_hosts ポート範囲を指定した値の分拡張するために使用されます。たとえば、initial_hostshost1[1000],host2[2000] に設定し、port_range1 に設定した場合 initial_hosts 設定は host1[1000],host1[1001],host2[2000],host2[2001] に拡張されます。このプロパティーは initial_hosts プロパティーと併用した場合のみ有効です。
  3. スクリプトファイルを管理 CLI に渡してスクリプトを実行します。

    $ EAP_HOME/bin/jboss-cli.sh --connect --file=/path/to/SCRIPT_NAME

TCPPING スタックが使用できるようになり、ネットワークの通信に TCP が使用されます。

24.2.4. TCPGOSSIP の設定

この手順は、TCPGOSSIP プロトコルを使用する新しい JGroups スタックを作成し、外部ゴシップルーターを使用してクラスターのメンバーを検索します。ベーススクリプトは、tcpgossip スタックを作成し、この新しいスタックを使用するようデフォルトの ee チャネルを設定します。このスクリプトの管理 CLI コマンドは環境に合わせてカスタマイズする必要があり、バッチで処理されます。

  1. 以下のスクリプトをテキストエディターにコピーし、ローカルファイルシステムに保存します。

    # Define the socket bindings
    /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=jgroups-host-a:add(host=HOST_A,port=13001)
    batch
    # Add the tcpgossip stack
    /subsystem=jgroups/stack=tcpgossip:add
    /subsystem=jgroups/stack=tcpgossip/transport=TCP:add(socket-binding=jgroups-tcp)
    /subsystem=jgroups/stack=tcpgossip/protocol=TCPGOSSIP:add(socket-bindings=[jgroups-host-a])
    /subsystem=jgroups/stack=tcpgossip/protocol=MERGE3:add
    /subsystem=jgroups/stack=tcpgossip/protocol=FD_SOCK:add
    /subsystem=jgroups/stack=tcpgossip/protocol=FD_ALL:add
    /subsystem=jgroups/stack=tcpgossip/protocol=VERIFY_SUSPECT:add
    /subsystem=jgroups/stack=tcpgossip/protocol=pbcast.NAKACK2:add
    /subsystem=jgroups/stack=tcpgossip/protocol=UNICAST3:add
    /subsystem=jgroups/stack=tcpgossip/protocol=pbcast.STABLE:add
    /subsystem=jgroups/stack=tcpgossip/protocol=pbcast.GMS:add
    /subsystem=jgroups/stack=tcpgossip/protocol=MFC:add
    /subsystem=jgroups/stack=tcpgossip/protocol=FRAG2:add
    # Set tcpgossip as the stack for the ee channel
    /subsystem=jgroups/channel=ee:write-attribute(name=stack,value=tcpgossip)
    run-batch
    reload

    定義されたプロトコルの順番が重要になることに注意してください。また、add-index の値を add コマンドに渡すと、特定のインデックスでプロトコルを挿入できます。インデックスはゼロベースであるため、以下の管理 CLI コマンドは UNICAST3 プロトコルを 7 つ目のプロトコルとして追加します。

    /subsystem=jgroups/stack=tcpgossip/protocol=UNICAST3:add(add-index=6)
  2. 環境に合わせてスクリプトを変更します。

    • 管理対象ドメインで実行している場合は、/subsystem=jgroups コマンドの前に /profile=PROFILE_NAME を追加し、更新するプロファイルを指定する必要があります。
    • 以下のプロパティーを環境に合わせて調整します。

      • socket-bindings: ウェルノウンとして見なされ、最初のメンバーシップの検索に利用できるホストとポートの組み合わせのカンマ区切りリスト。ソケットバインディングの定義に関する詳細は、「ソケットバインディングの設定」を参照してください
      • initial_hosts: ウェルノウンとして見なされ、最初のメンバーシップの検索に使用できる HOST[PORT] という構文を使用したホストとポートの組み合わせのカンマ区切りリスト (例: host1[1000],host2[2000])。
      • port_range: このプロパティーは、 initial_hosts ポート範囲を指定した値の分拡張するために使用されます。たとえば、initial_hostshost1[1000],host2[2000] に設定し、port_range1 に設定した場合 initial_hosts 設定は host1[1000],host1[1001],host2[2000],host2[2001] に拡張されます。このプロパティーは initial_hosts プロパティーと併用した場合のみ有効です。
      • reconnect_interval: 接続が切断されたスタブがゴシップルーターへの再接続を試みる間隔 (ミリ秒単位)。
      • sock_conn_timeout: ソケット作成の最大時間。デフォルトは 1000 ミリ秒です。
      • sock_read_timeout: 読み取りがブロックされる最大時間 (ミリ秒単位)。0 を値として指定すると無制限にブロックされます。
  3. スクリプトファイルを管理 CLI に渡してスクリプトを実行します。

    $ EAP_HOME/bin/jboss-cli.sh --connect --file=/path/to/SCRIPT_NAME

TCPGOSSIP スタックが使用できるようになり、ネットワークの通信に TCP が使用されます。このスタックはゴシップルーターと使用するように設定されるため、JGroups メンバーは他のクラスターメンバーを見つけることができます。

24.2.5. JDBC_PING の設定

JDBC_PING プロトコルを使用して、クラスターでメンバーシップを管理および検出できます。

JDBC_PING はデータソースに指定されたデータベースを使用して、クラスターのメンバーを一覧表示します。

  1. クラスターメンバーシップの管理に使用するデータベースに接続するデータソースを作成します。
  2. 以下のスクリプトをテキストエディターにコピーし、ローカルファイルシステムに保存します。

    batch
    # Add the JDBC_PING stack
    /subsystem=jgroups/stack=JDBC_PING:add
    /subsystem=jgroups/stack=JDBC_PING/transport=TCP:add(socket-binding=jgroups-tcp)
    /subsystem=jgroups/stack=JDBC_PING/protocol=JDBC_PING:add(data-source=ExampleDS)
    /subsystem=jgroups/stack=JDBC_PING/protocol=MERGE3:add
    /subsystem=jgroups/stack=JDBC_PING/protocol=FD_SOCK:add
    /subsystem=jgroups/stack=JDBC_PING/protocol=FD_ALL:add
    /subsystem=jgroups/stack=JDBC_PING/protocol=VERIFY_SUSPECT:add
    /subsystem=jgroups/stack=JDBC_PING/protocol=pbcast.NAKACK2:add
    /subsystem=jgroups/stack=JDBC_PING/protocol=UNICAST3:add
    /subsystem=jgroups/stack=JDBC_PING/protocol=pbcast.STABLE:add
    /subsystem=jgroups/stack=JDBC_PING/protocol=pbcast.GMS:add
    /subsystem=jgroups/stack=JDBC_PING/protocol=MFC:add
    /subsystem=jgroups/stack=JDBC_PING/protocol=FRAG2:add
    # Set JDBC_PING as the stack for the ee channel
    /subsystem=jgroups/channel=ee:write-attribute(name=stack,value=JDBC_PING)
    run-batch
    reload

    定義されたプロトコルの順番が重要になることに注意してください。また、add-index の値を add コマンドに渡すと、特定のインデックスでプロトコルを挿入できます。インデックスはゼロベースであるため、以下の管理 CLI コマンドは UNICAST3 プロトコルを 7 つ目のプロトコルとして追加します。

    /subsystem=jgroups/stack=JDBC_PING/protocol=UNICAST3:add(add-index=6)
  3. 環境に合わせてスクリプトを変更します。

    • 管理対象ドメインで実行している場合は、/subsystem=jgroups コマンドの前に /profile=PROFILE_NAME を追加し、更新するプロファイルを指定する必要があります。
    • ExampleDS」を、手順 1 で定義したデータソースの名前に置き換えます。
  4. スクリプトファイルを管理 CLI に渡してスクリプトを実行します。

    $ EAP_HOME/bin/jboss-cli.sh --connect --file=/path/to/SCRIPT_NAME

JDBC_PING スタックが使用できるようになり、ネットワークの通信に TCP が使用されます。

JDBC_PING: https://developer.jboss.org/wiki/JDBCPING

データソースの作成: 「JBoss EAP データソース

24.2.6. JGroups のネットワークインターフェースへのバインディング

デフォルトでは、JGroups は private ネットワークインターフェースのみへバインドし、デフォルト設定でローカルホストへ示されます。クラスタリングのトラフィックはパブリックネットワークインターフェースで公開するべきではないため、セキュリティー上の理由で JGroups は JBoss EAP の起動中に指定された -b 引数によって定義されたネットワークインターフェースにはバインドしません。

ネットワークインターフェースの設定方法については「ネットワークおよびポート設定」の章を参照してください。

重要

セキュリティー上の理由で、JGroups はパブリックではないネットワークインターフェースのみにバインドされる必要があります。また、パフォーマンス上の理由で JGroups トラフィックのネットワークインターフェースは専用の VLAN (Virtual Local Area Network) の一部にすることが推奨されます。

24.2.7. クラスターのセキュア化

クラスターをセキュアに実行するには、複数の課題に対応する必要があります。

  • 承認されていないノードがクラスターに参加しないようにします。これは認証を要求して対処します。
  • クラスターメンバーがクラスターメンバー以外と通信しないようにします。これはメッセージの暗号化で対処します。

24.2.7.1. 認証の設定

JGroups の認証は AUTH プロトコルによって実行されます。認証されたノードのみがクラスターに参加できるようにすることが目的です。

該当のサーバー設定ファイルに AUTH プロトコルと適切なプロパティー設定を追加します。AUTH プロトコルは pbcast.GMS プロトコルの直前に設定する必要があります。

以下は、AUTH を異なる承認トークンと使用する例になります。

AUTH とシンプルトークン
...
<protocol type="pbcast.STABLE"/>
<auth-protocol type="AUTH">
  <plain-token>
    <shared-secret-reference clear-text="my_password"/>
  </plain-token>
</auth-protocol>
<protocol type="pbcast.GMS"/>
...
AUTH とダイジェストアルゴリズムトークン

この形式は、MD5 や SHA-2 など、どのダイジェストアルゴリズムでも使用できます。JBoss EAP 7.3 でのデフォルトのダイジェストアルゴリズムは SHA-256 で、これは JVM によるサポートに必要な最強のダイジェストアルゴリズムです。多くの JVM は、追加で SHA-512 を実装します。

...
<protocol type="pbcast.STABLE"/>
<auth-protocol type="AUTH">
  <digest-token algorithm="SHA-512">
    <shared-secret-reference clear-text="my_password"/>
  </digest-token>
</auth-protocol>
<protocol type="pbcast.GMS"/>
...
AUTH と X509 トークン

この例は、elytron サブシステムで新しいキーストアを作成し、JGroups の AUTH 設定で参照します。

  1. キーストアを作成します。

    $ keytool -genkeypair -alias jgroups_key -keypass my_password -storepass my_password -storetype jks -keystore jgroups.keystore -keyalg RSA
  2. 管理 CLI を使用して、キーストアを elytron サブシステムに追加します。

    /subsystem=elytron/key-store=jgroups-token-store:add(type=jks,path=/path/to/jgroups.keystore,credential-reference={clear-text=my_password}, required=true)
  3. JGroups のスタック定義で AUTH を設定してキーストアを使用するようにします。

    ...
    <protocol type="pbcast.STABLE"/>
    <auth-protocol type="AUTH">
      <cipher-token algorithm="RSA" key-alias="jgroups_key" key-store="jgroups-token-store">
        <shared-secret-reference clear-text="my_password"/>
        <key-credential-reference clear-text="my_password"/>
      </cipher-token>
    </auth-protocol>
    <protocol type="pbcast.GMS"/>
    ...

24.2.7.2. 暗号化の設定

JGroups はクラスターのメンバーが共有する秘密鍵を使用してメッセージを暗号化します。送信元は共有する秘密鍵を使用してメッセージを暗号化し、受信先は同じ秘密鍵を使用してメッセージを復号化します。対称暗号化SYM_ENCRYPT プロトコルを使用して設定され、ノードは共有のキーストアを使用して秘密鍵を取得します。非対称暗号化ASYM_ENCRYPT プロトコルを使用して設定され、ノードは AUTH を使用して認証された後にクラスターのコーディネーターから秘密鍵を取得します。

対称暗号化の使用

SYM_ENCRYPT を使用するには、各ノードの JGroups 設定で参照されるキーストアを設定する必要があります。

  1. キーストアを作成します。

    以下のコマンドでは、VERSION を適切な JGroups JAR バージョンに置き換え、PASSWORD をキーストアパスワードに置き換えます。

    $ java -cp EAP_HOME/modules/system/layers/base/org/jgroups/main/jgroups-VERSION.jar org.jgroups.demos.KeyStoreGenerator --alg AES --size 128 --storeName defaultStore.keystore --storepass PASSWORD --alias mykey

    これにより、JGroups 設定で参照される defaultStore.keystore ファイルが生成されます。

  2. キーストアが生成されたら、2 つの方法の 1 つを使用して SYM_PROTOCOL で定義されます。

注記

SYM_ENCRYPT を使用する場合、AUTH の設定は任意です。

キーストアを直接参照して対称暗号化を使用
  1. jgroups サブシステムで SYM_ENCRYPT プロトコルを設定します。

    該当するサーバー設定ファイルに、SYM_ENCRYPT プロトコルと適切なプロパティー設定を追加します。このプロトコルは、以前作成されたキーストアを参照します。SYM_ENCRYPT プロトコルは pbcast.NAKACK2 の直前に設定する必要があります。

    <subsystem xmlns="urn:jboss:domain:jgroups:6.0">
      <stacks>
        <stack name="udp">
          <transport type="UDP" socket-binding="jgroups-udp"/>
          <protocol type="PING"/>
          <protocol type="MERGE3"/>
          <protocol type="FD_SOCK"/>
          <protocol type="FD_ALL"/>
          <protocol type="VERIFY_SUSPECT"/>
          <protocol type="SYM_ENCRYPT">
            <property name="provider">SunJCE</property>
            <property name="sym_algorithm">AES</property>
            <property name="encrypt_entire_message">true</property>
            <property name="keystore_name">/path/to/defaultStore.keystore</property>
            <property name="store_password">PASSWORD</property>
            <property name="alias">mykey</property>
          </protocol>
          <protocol type="pbcast.NAKACK2"/>
          <protocol type="UNICAST3"/>
          <protocol type="pbcast.STABLE"/>
          <protocol type="pbcast.GMS"/>
          <protocol type="UFC"/>
          <protocol type="MFC"/>
          <protocol type="FRAG2"/>
        </stack>
      </stacks>
    </subsystem>
Elytron と対称暗号化の使用
  1. 管理 CLI を使用して、対称暗号化を使用して 作成された defaultStore.keystore を参照するキーストアを elytron サブシステムに作成します。

    /subsystem=elytron/key-store=jgroups-keystore:add(path=/path/to/defaultStore.keystore,credential-reference={clear-text=PASSWORD},type=JCEKS)
  2. SYM_ENCRYPT プロトコルと適切なプロパティー設定を jgroups サブシステムに追加します。以下の設定どおり、SYM_ENCRYPT プロトコルは pbcast.NAKACK2 プロトコルの直前に設定する必要があります。

    <subsystem xmlns="urn:jboss:domain:jgroups:6.0">
      <stacks>
        <stack name="udp">
          <transport type="UDP" socket-binding="jgroups-udp"/>
          <protocol type="PING"/>
          <protocol type="MERGE3"/>
          <protocol type="FD_SOCK"/>
          <protocol type="FD_ALL"/>
          <protocol type="VERIFY_SUSPECT"/>
          <encrypt-protocol type="SYM_ENCRYPT" key-alias="mykey" key-store="jgroups-keystore">
            <key-credential-reference clear-text="PASSWORD"/>
            <property name="provider">SunJCE</property>
            <property name="encrypt_entire_message">true</property>
          </encrypt-protocol>
          <protocol type="pbcast.NAKACK2"/>
          <protocol type="UNICAST3"/>
          <protocol type="pbcast.STABLE"/>
          <protocol type="pbcast.GMS"/>
          <protocol type="UFC"/>
          <protocol type="MFC"/>
          <protocol type="FRAG2"/>
        </stack>
      </stacks>
    </subsystem>
    注記

    上記の例はクリアテキストのパスワードを使用しますが、認証情報ストアを定義して設定ファイル外部にパスワードを定義することもできます。認証情報ストアの設定に関する詳細は、『How to Configure Server Security』の「Credential Store」を参照してください。

非対称暗号化の使用

ASYM_ENCRYPT を使用するには AUTH プロトコルを定義する必要があります。AUTH プロトコルを jgroups サブシステムで設定する手順は、「認証の設定」を参照してください。

ASYM_ENCRYPT は 2 つの方法の 1 つで設定されます。

秘密鍵を生成して非対象暗号化を使用
  1. jgroups サブシステムで ASYM_ENCRYPT プロトコルを設定します。

    該当のサーバー設定ファイルに ASYM_ENCRYPT プロトコルと適切なプロパティー設定を追加します。以下の設定どおり、ASYM_ENCRYPT プロトコルは pbcast.NAKACK2 プロトコルの直前に設定する必要があります。

    <subsystem xmlns="urn:jboss:domain:jgroups:6.0">
      <stacks>
        <stack name="udp">
          <transport type="UDP" socket-binding="jgroups-udp"/>
          <protocol type="PING"/>
          <protocol type="MERGE3"/>
          <protocol type="FD_SOCK"/>
          <protocol type="FD_ALL"/>
          <protocol type="VERIFY_SUSPECT"/>
          <protocol type="ASYM_ENCRYPT">
            <property name="encrypt_entire_message">true</property>
            <property name="sym_keylength">128</property>
            <property name="sym_algorithm">AES/ECB/PKCS5Padding</property>
            <property name="asym_keylength">512</property>
            <property name="asym_algorithm">RSA</property>
          </protocol>
          <protocol type="pbcast.NAKACK2"/>
          <protocol type="UNICAST3"/>
          <protocol type="pbcast.STABLE"/>
          <!-- Configure AUTH protocol here -->
          <protocol type="pbcast.GMS"/>
          <protocol type="UFC"/>
          <protocol type="MFC"/>
          <protocol type="FRAG2"/>
        </stack>
      </stacks>
    </subsystem>
Elytron と非対称暗号化の使用
  1. キーペアが含まれるキーストアを作成します。以下のコマンドは、mykey というエイリアスでキーストアを作成します。

    $ keytool -genkeypair -alias mykey -keyalg RSA -keysize 1024 -keystore defaultKeystore.keystore -dname "CN=localhost" -keypass secret -storepass secret
  2. 管理 CLI を使用して、defaultStore.keystore を参照するキーストアを elytron サブシステムに作成します。

    /subsystem=elytron/key-store=jgroups-keystore:add(path=/path/to/defaultStore.keystore,credential-reference={clear-text=PASSWORD},type=JCEKS)
  3. ASYM_ENCRYPT プロトコルと適切なプロパティー設定を jgroups サブシステムに追加します。以下の設定どおり、ASYM_ENCRYPT プロトコルは pbcast.NAKACK2 プロトコルの直前に設定する必要があります。

    <subsystem xmlns="urn:jboss:domain:jgroups:6.0">
      <stacks>
        <stack name="udp">
          <transport type="UDP" socket-binding="jgroups-udp"/>
          <protocol type="PING"/>
          <protocol type="MERGE3"/>
          <protocol type="FD_SOCK"/>
          <protocol type="FD_ALL"/>
          <protocol type="VERIFY_SUSPECT"/>
          <encrypt-protocol type="ASYM_ENCRYPT" key-alias="mykey" key-store="jgroups-keystore">
            <key-credential-reference clear-text="secret" />
            <property name="encrypt_entire_message">true</property>
          </encrypt-protocol>
          <protocol type="pbcast.NAKACK2"/>
          <protocol type="UNICAST3"/>
          <protocol type="pbcast.STABLE"/>
          <!-- Configure AUTH protocol here -->
          <protocol type="pbcast.GMS"/>
          <protocol type="UFC"/>
          <protocol type="MFC"/>
          <protocol type="FRAG2"/>
        </stack>
      </stacks>
    </subsystem>
    注記

    上記の例はクリアテキストのパスワードを使用しますが、認証情報ストアを定義して設定ファイル外部にパスワードを定義することもできます。認証情報ストアの設定に関する詳細は、『How to Configure Server Security』の「Credential Store」を参照してください。

24.2.8. JGroups スレッドプールの設定

jgroups サブシステムには defaultinternaloob、および timer スレッドプールが含まれます。これらのプールはすべての JGroups スタックに設定できます。

以下の表は、各スレッドプールに設定できる属性とデフォルト値を表しています。

スレッドプール名keepalive-timemax-threadsmin-threadsqueue-length

default

60000L

300

20

100

internal

60000L

4

2

100

oob

60000L

300

20

0

timer

5000L

4

2

500

以下の構文を使用して、管理 CLI で JGroups スレッドプールを設定します。

/subsystem=jgroups/stack=STACK_TYPE/transport=TRANSPORT_TYPE/thread-pool=THREAD_POOL_NAME:write-attribute(name=ATTRIBUTE_NAME, value=ATTRIBUTE_VALUE)

以下は、 udp スタックの default スレッドプールで max-threads の値を 500 に設定する管理 CLI コマンドの例になります。

/subsystem=jgroups/stack=udp/transport=UDP/thread-pool=default:write-attribute(name="max-threads", value="500")

24.2.9. JGroups の送受信バッファーの設定

バッファーサイズ警告の解決

デフォルトでは、JGroups は特定の送受信バッファー値で設定されています。しかし、可能なバッファーサイズがオペレーティングシステムによって制限され、JBoss EAP が設定されたバッファー値を使用できないことがあります。このような場合、以下と似た警告が JBoss EAP のログに記録されます。

WARNING [org.jgroups.protocols.UDP] (ServerService Thread Pool -- 68)
JGRP000015: the send buffer of socket DatagramSocket was set to 640KB, but the OS only allocated 212.99KB.
This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
WARNING [org.jgroups.protocols.UDP] (ServerService Thread Pool -- 68)
JGRP000015: the receive buffer of socket DatagramSocket was set to 20MB, but the OS only allocated 212.99KB.
This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)

これに対応するには、オペレーティングシステムのマニュアルでバッファーサイズを増やす方法を参照してください。Red Hat Enterprise Linux システムの場合は、root ユーザーとして /etc/sysctl.conf を編集し、システムの再起動後も維持されるバッファーサイズの最大値を設定します。例を以下に示します。

# Allow a 25MB UDP receive buffer for JGroups
net.core.rmem_max = 26214400
# Allow a 1MB UDP send buffer for JGroups
net.core.wmem_max = 1048576

/etc/sysctl.conf を編集後、sysctl -p を実行して変更を反映します。

JGroups バッファーサイズの設定

以下のトランスポートプロパティーを UDP および TCP JGroups スタックに設定すると、JBoss EAP が使用する JGroups バッファーサイズを設定できます。

UDP スタック
  • ucast_recv_buf_size
  • ucast_send_buf_size
  • mcast_recv_buf_size
  • mcast_send_buf_size
TCP スタック
  • recv_buf_size
  • send_buf_size

JGroups バッファーサイズは、管理コンソールまたは管理 CLI を使用して設定できます。

以下の構文を使用して、管理 CLI で JGroups バッファーサイズプロパティーを設定します。

/subsystem=jgroups/stack=STACK_NAME/transport=TRANSPORT/property=PROPERTY_NAME:add(value=BUFFER_SIZE)

以下は、tcp スタックで recv_buf_size プロパティーを 20000000 に設定する管理 CLI コマンドの例になります。

/subsystem=jgroups/stack=tcp/transport=TRANSPORT/property=recv_buf_size:add(value=20000000)

JGroups バッファーサイズは管理コンソールを使用して設定することもできます。 Configuration タブで JGroups サブシステムを選択し、表示 をクリックして Stack タブを選択し、該当するスタックを選びます。 Transport をクリックし、 Properties フィールドを編集します。

24.2.10. JGroups サブシステムの調整

jgroups サブシステムのパフォーマンスを監視および最適化するための情報は、『パフォーマンスチューニングガイド』の「JGroups サブシステムの調整」の項を参照してください。

24.2.11. JGroups トラブルシューティング

24.2.11.1. ノードがクラスターを形成しない

マシンで IP マルチキャストが正しくセットアップされていることを確認します。JBoss EAP には、IP マルチキャストのテストに使用できる McastReceiverTestMcastSenderTest の 2 つのテストプログラムが含まれています。

ターミナルで McastReceiverTest を開始します。

$ java -cp EAP_HOME/bin/client/jboss-client.jar org.jgroups.tests.McastReceiverTest -mcast_addr 230.11.11.11 -port 5555

別のターミナルウインドウで McastSenderTest を開始します。

$ java -cp EAP_HOME/bin/client/jboss-client.jar org.jgroups.tests.McastSenderTest -mcast_addr 230.11.11.11 -port 5555

特定のネットワークインターフェースカード (NIC) をバインドする場合は、-bind_addr YOUR_BIND_ADDRESS を使用します。YOUR_BIND_ADDRESS はバインドする NIC の IP アドレスに置き換えます。送信側と受信側の両方にこのパラメーターを使用します。

McastSenderTest ターミナルウインドウで入力すると McastReceiverTest ウインドウに出力が表示されます。表示されない場合は以下の手順に従います。

  • 送信側のコマンドに -ttl VALUE を追加して、マルチキャストパケットの TTL (time-to-live) を増やします。このテストプログラムによって使用されるデフォルトの値は 32 で、VALUE255 以下である必要があります。
  • マシンに複数のインターフェースがある場合は、適切なインターフェースを使用していることを確認します。
  • システム管理者に連絡し、マルチキャストが選択したインターフェースで動作することを確認します。

クラスターの各マシンでマルチキャストが適切に動作したら、送信側と受信側を別々のマシンに配置し、テストを繰り返します。

24.2.11.2. 障害検出での不明なハートビートの原因

ハートビートの確認が一定時間 (T) 受信されないと、障害検出 (FD) によってクラスターメンバーが原因として疑われることがあります。T は timeout および max_tries によって定義されます。

たとえば、ノード A、B、C、および D のクラスターがあり、A が B、B が C、C が D、D が A を ping する場合、以下のいずれかの理由で C が疑われます。

  • B または C が CPU の使用率が 100% の状態で T 秒よりも長く稼働している場合。この場合、 C がハートビート確認を B に送信しても CPU の使用率が 100% であるため B が確認を処理できないことがあります。
  • B または C がガベッジコレクションを実行している場合、上記と同じ結果になります。
  • 上記 2 件の組み合わせ。
  • ネットワークによるパケットの損失が発生する場合。通常、ネットワークに大量のトラフィックがあり、スイッチがパケットを破棄すると発生します (通常は最初にブロードキャスト、次に IP マルチキャスト、そして最後に TCP パケットが破棄されます)。
  • B または C がコールバックを処理する場合。C が処理に T + 1 秒かかるリモートメソッド呼び出しをチャネル上で受信した場合、C はハートビートを含む他のメッセージを処理できません。そのため、B はハートビート確認を受信せず、C が疑われます。

24.3. Infinispan

24.3.1. Infinispan

Infinispan は Java データグリッドプラットフォームで、キャッシュされたデータの管理に JSR-107 準拠のキャッシュインターフェースを提供します。キャッシュされたデータの管理と同等の Jakarta は Jakarta Persistence 2.2 です。

Infinispan の機能や設定オプションの詳細は Infinispan のドキュメント を参照してください。

infinispan サブシステムは JBoss EAP のキャッシュサポートを提供します。名前付きのキャッシュコンテナーやキャッシュのランタイムメトリックスを設定および表示できます。

高可用性の機能を提供する設定を使用する場合 (管理対象ドメインでは hafull-ha プロファイル、スタンドアロンサーバーは standalone-ha.xmlstandalone-full-ha.xml 設定ファイル)、infinispan サブシステムはキャッシング、状態のレプリケーション、および状態分散サポートを提供します。高可用性でない設定では、infinispan サブシステムはローカルのキャッシュサポートを提供します。

重要

Infinispan は JBoss EAP のプライベートモジュールとして含まれ、JBoss EAP のキャッシュ機能を提供します。アプリケーションによる Infinispan の直接使用はサポートされません。

24.3.2. キャッシュコンテナー

キャッシュコンテナーはサブシステムによって使用されるキャッシュのリポジトリーです。各キャッシュコンテナーは、使用されるデフォルトのキャッシュを定義します。

JBoss EAP 7 は以下のデフォルト Infinispan キャッシュコンテナーを定義します。

  • server (シングルトンキャッシング)
  • web (Web セッションクラスタリング)
  • ejb (ステートフルセッション Bean クラスタリング)
  • hibernate (エンティティーキャッシング)

例: Infinispan のデフォルト設定

<subsystem xmlns="urn:jboss:domain:infinispan:7.0">
  <cache-container name="server" aliases="singleton cluster" default-cache="default" module="org.wildfly.clustering.server">
    <transport lock-timeout="60000"/>
    <replicated-cache name="default">
      <transaction mode="BATCH"/>
    </replicated-cache>
  </cache-container>
  <cache-container name="web" default-cache="dist" module="org.wildfly.clustering.web.infinispan">
    <transport lock-timeout="60000"/>
    <distributed-cache name="dist">
      <locking isolation="REPEATABLE_READ"/>
      <transaction mode="BATCH"/>
      <file-store/>
    </distributed-cache>
  </cache-container>
  <cache-container name="ejb" aliases="sfsb" default-cache="dist" module="org.wildfly.clustering.ejb.infinispan">
    <transport lock-timeout="60000"/>
    <distributed-cache name="dist">
      <locking isolation="REPEATABLE_READ"/>
      <transaction mode="BATCH"/>
      <file-store/>
    </distributed-cache>
  </cache-container>
  <cache-container name="hibernate" default-cache="local-query" module="org.hibernate.infinispan">
    <transport lock-timeout="60000"/>
    <local-cache name="local-query">
      <object-memory size="1000"/>
      <expiration max-idle="100000"/>
    </local-cache>
    <invalidation-cache name="entity">
      <transaction mode="NON_XA"/>
      <object-memory size="1000"/>
      <expiration max-idle="100000"/>
    </invalidation-cache>
    <replicated-cache name="timestamps" mode="ASYNC"/>
  </cache-container>
</subsystem>

各キャッシュコンテナーで定義されたデフォルトのキャッシュに注目してください。この例では、web キャッシュコンテナーは dist 分散キャッシュをデフォルトとして定義します。そのため、Web セッションのクラスタリングでは dist キャッシュが使用されます。

デフォルトキャッシュの変更やキャッシュの追加に関する詳細は、「キャッシュコンテナーの設定」を参照してください。

重要

HTTP セッション、ステートフルセッション Bean、シングルトンサービスやデプロイメントなどのキャッシュやキャッシュコンテナーを追加できます。ユーザーアプリケーションによるこれらのキャッシュの直接使用はサポートされません。

24.3.2.1. キャッシュコンテナーの設定

キャッシュコンテナーやキャッシュ属性は、管理コンソールまたは管理 CLI を使用して設定できます。

警告

設定の他のコンポーネントが参照する可能性があるため、キャッシュまたはキャッシュコンテナーの名前を変更しないでください。

管理コンソールを使用したキャッシュの設定

管理コンソールの Configuration タブで Infinispan サブシステムを選択するとキャッシュやキャッシュコンテナーを設定できます。管理対象ドメインでは設定するプロファイルを選択してください。

  • キャッシュコンテナーを追加します。

    Cache Container の横にある追加 (+) ボタンをクリックし、Cache Container を追加 を選択して新しいキャッシュコンテナーの設定を入力します。

  • キャッシュコンテナー設定を更新します。

    該当するキャッシュコンテナーを選択し、表示 を選択します。必要に応じてキャッシュコンテナーの設定を行います。

  • キャッシュコンテナートランスポート設定を更新します。

    該当するキャッシュコンテナーを選択し、表示 を選択します。Transport タブで、必要に応じてキャッシュコンテナートランスポートを設定します。

  • キャッシュを設定します。

    該当するキャッシュコンテナーを選択し、表示 を選択します。キャッシュタブ (Replicated Cache など) でキャッシュを追加、更新、および削除できます。

管理 CLI を使用したキャッシュの設定

管理 CLI を使用してキャッシュおよびキャッシュコンテナーを設定できます。管理対象ドメインではコマンドの前に /profile=PROFILE_NAME を追加して更新するプロファイルを指定する必要があります。

  • キャッシュコンテナーを追加します。

    /subsystem=infinispan/cache-container=CACHE_CONTAINER:add
  • レプリケートされたキャッシュを追加します。

    /subsystem=infinispan/cache-container=CACHE_CONTAINER/replicated-cache=CACHE:add(mode=MODE)
  • キャッシュコンテナーのデフォルトキャッシュを設定します。

    /subsystem=infinispan/cache-container=CACHE_CONTAINER:write-attribute(name=default-cache,value=CACHE)
  • レプリケートされたキャッシュのバッチ処理を設定します。

    /subsystem=infinispan/cache-container=CACHE_CONTAINER/replicated-cache=CACHE/component=transaction:write-attribute(name=mode,value=BATCH)

以下の例は、concurrent 分散キャッシュを web キャッシュコンテナーに追加する方法を表しています。このキャッシュ設定はデフォルトキャッシュのロック制約を緩和し、複数の同時リクエストが同じ web セッションに同時にアクセスできるようにします。これは、ロックのない読み取りを許可し、排他的ロックをより頻繁により短期間で取得することで実現されます。

以下の CLI コマンドを使用して concurrent 分散キャッシュを web キャッシュコンテナーに追加し、デフォルトのキャッシュにします。

batch
/subsystem=infinispan/cache-container=web/distributed-cache=concurrent:add
/subsystem=infinispan/cache-container=web:write-attribute(name=default-cache,value=concurrent)
/subsystem=infinispan/cache-container=web/distributed-cache=concurrent/store=file:add
run-batch

これにより、サーバーが以下のように設定されます。

<cache-container name="web" default-cache="concurrent" module="org.wildfly.clustering.web.infinispan">
  ...
  <distributed-cache name="concurrent">
      <file-store/>
  </distributed-cache>
</cache-container>
デフォルト EJB キャッシュコンテナーの変更

以下のようにキャッシュコンテナーを ejb3 サブシステムで使用できます。

  • EJB セッション bean のパッシベーションをサポートするには、infinispan サブシステムに定義された ejb キャッシュコンテナーを使用してセッションを保存できます。
  • サーバー上でクラスター化されたデプロイメントに接続するリモート EJB クライアントの場合、クラスタートポロジーの情報をこれらのクライアントに提供して、これらのクライアントが対話するノードに障害が発生したときにクラスターの別のノードにフェイルオーバーできるようにする必要があります。

パッシベーションやトポロジー情報の提供をサポートするデフォルトのキャッシュコンテナー ejb を変更する場合や、その名前を変更する場合、以下の例のように cache-container 属性を passivation-stores 要素に追加し、cluster 属性を remote 要素に追加する必要があります。独自に使用するために新しいキャッシュを追加する場合は、このような変更を加える必要はありません。

<subsystem xmlns="urn:jboss:domain:ejb3:5.0">
    <passivation-stores>
        <passivation-store name="infinispan" cache-container="ejb-cltest" max-size="10000"/>
    </passivation-stores>

    <remote cluster="ejb-cltest" connector-ref="http-remoting-connector" thread-pool-name="default"/>
</subsystem>

<subsystem xmlns="urn:jboss:domain:infinispan:7.0">
    ...
    <cache-container name="ejb-cltest" aliases="sfsb" default-cache="dist" module="org.wildfly.clustering.ejb.infinispan">
</subsystem>
Hibernate キャッシュコンテナーのエビクション機能

hibernate キャッシュコンテナーのエビクション機能は、メモリーからキャッシュエントリーを削除します。この機能は、サブシステムのメモリー負荷を軽減するのに役立ちます。

size 属性は、キャッシュエントリーのエビクションの開始前に保存されるキャッシュエントリーの最大数を設定します。

例:エビクション機能

  <cache-container name="hibernate" default-cache="local-query" module="org.hibernate.infinispan">
    <transport lock-timeout="60000"/>
    <local-cache name="local-query">
      <object-memory size="1000"/>
      <expiration max-idle="100000"/>

エビクションはメモリー内でのみ実行されることに注意してください。キャッシュストアは、情報の永続的な損失を防ぐためにエビクトされたキャッシュエントリーを保持します。エビクション 機能についての詳細は、『Infinispan ユーザーガイド』の「エビクションおよびデータコンテナー」セクションを参照し てください。

24.3.3. クラスタリングモード

JBoss EAP で Infinispan を使用すると、2 つの方法でクラスタリングを設定できます。ご使用のアプリケーションに最も適した方法は要件によって異なります。各モードでは可用性、一貫性、信頼性、およびスケーラビリティーのトレードオフが発生します。クラスタリングモードを選択する前に、ネットワークで最も重要な点を特定し、これらの要件のバランスを取ることが必要となります。

キャッシュモード
Replication (レプリケーション)
Replication (レプリケーション) モードはクラスターの新しいインスタンスを自動的に検出し、追加します。これらのインスタンスに加えられた変更は、クラスター上のすべてのノードにレプリケートされます。ネットワークでレプリケートされる情報量が多いため、通常 Replication モードは小型のクラスターでの使用に最も適しています。UDP マルチキャストを使用するよう Infinispan を設定すると、ネットワークトラフィックの輻輳をある程度軽減できます。
Distribution (分散)

Distribution (分散) モードでは、Infinispan はクラスターを線形にスケールできます。Distribution モードは一貫性のあるハッシュアルゴリズムを使用して、クラスター内で新しいノードを配置する場所を決定します。保持する情報のコピー数 (または所有者数) は設定可能です。保持するコピー数、データの永続性、およびパフォーマンスにはトレードオフが生じます。保持するコピー数が多いほどパフォーマンスへの影響が大きくなりますが、サーバーの障害時にデータを損失する可能性は低くなります。ハッシュアルゴリズムは、メタデータのマルチキャストや保存を行わずにエントリーを配置し、ネットワークトラフィックを軽減します。

クラスターサイズが 6-8 ノードを超える場合は Distribution モードをキャッシュストラテジーとして使用することを考慮してください。Distribution モードでは、データはクラスター内のすべてのノードではなくノードのサブセットのみに分散されます。

Scattered (散在)

Scattered (散在) モードは、一貫したハッシュアルゴリズムを使用して所有者を判断する Distribution モードと似ています。しかし、所有者は 2 名のメンバーに限定され、オリジネーター (指定のセッションのリクエストを受信するノード) は常にロックを調整する所有者やキャッシュエントリーのアップデートを想定します。2 名の所有者を持つ分散キャッシュが頻繁に 2 つの RPC 呼び出しを使用できる場合、Scattered モードで使用されるキャッシュ書き込みアルゴリズムは、書き込み操作の結果が単一の RPC 呼び出しになることを保証します。これは、ロードバランサーのフェイルオーバーがプライマリー以外の所有者やバックアップノードにトラフィックを向ける可能性があるため、分散 Web セッションに便利です。これにより、競合の可能性を下げ、クラスタートポロジーの変更後にパフォーマンスを向上することが可能になります。

Scattered モードは、トランザクションや L1 キャッシュをサポートしません。しかし、一貫したハッシュによると所有者ではない場合でも、指定エントリーのキャッシュの書き込みを開始するノードは一定の期間は継続してそのエントリーの読み取りを継続する、バイアス読み取り (Biased read) をサポートします。バイアス読み取りと L1 キャッシュの設定属性は異なりますが、L1 キャッシュと同様の効果があります。

同期および非同期のレプリケーション

レプリケーションは同期または非同期モードで実行でき、選択するモードは要件やアプリケーションモードによって異なります。

重要

JBoss EAP 7.1 以降では、常に同期 (SYNC) キャッシュモードを使用する必要があります。sync はデフォルトのキャッシュモードです。非同期 (ASYNC) モードの使用は有効ではないため、ロック競合が発生します。セッションレプリケーションと適切なキャッシュモードの詳細は、「How to configure and tune the session replication for EAP」を参照してください。

同期のレプリケーション
同期のレプリケーションでは、レプリケーションプロセスはユーザーのリクエストを処理するのと同じスレッドで実行されます。セッションレプリケーションは、完了した応答がクライアントに返送された後に開始され、スレッドはレプリケーションの完了後のみに解放されます。同期レプリケーションはクラスターの各ノードからの応答を必要とするため、ネットワークトラフィックに影響を与えます。ただし、クラスターのすべてのノードへ確実に変更が加えられる利点があります。
非同期のレプリケーション
非同期のレプリケーションでは、Infinispan はスレードプールを使用してバックグラウンドでレプリケーションを実行します。送信元はクラスターの他のノードからの返答を待ちません。しかし、同じセッションを読み取るキャッシュはその前のレプリケーションが完了するまでブロックされるため、陳腐データは読み取られません。レプリケーションは時間ベースまたはキューのサイズによって引き起こされます。失敗したレプリケーションはログに書き込まれ、リアルタイムで通知されません。

24.3.3.1. キャッシュモードの設定

管理 CLI を使用してデフォルトキャッシュを変更できます。

注記

ここでは、デフォルトが Distribution モードである Web セッションキャッシュの設定に固有する手順を説明します。手順と管理 CLI コマンドは、他のキャッシュコンテナー向けに簡単に調整できます。

Replication キャッシュモードへの変更

Web セッションキャッシュのデフォルトの JBoss EAP 7 設定には、レプリケートされたキャッシュ repl が含まれていません。最初にこのキャッシュを追加する必要があります。

注記

以下はスタンドアロンサーバーの管理 CLI コマンドになります。管理対象ドメインで実行している場合は、/subsystem=infinispan コマンドの前に /profile=PROFILE_NAME を追加し、更新するプロファイルを指定する必要があります。

  1. レプリケーションキャッシュ repl を追加し、デフォルトのキャッシュとして設定します。

    batch
    /subsystem=infinispan/cache-container=web/replicated-cache=repl:add(mode=ASYNC)
    /subsystem=infinispan/cache-container=web/replicated-cache=repl/component=transaction:add(mode=BATCH)
    /subsystem=infinispan/cache-container=web/replicated-cache=repl/component=locking:add(isolation=REPEATABLE_READ)
    /subsystem=infinispan/cache-container=web/replicated-cache=repl/store=file:add
    /subsystem=infinispan/cache-container=web:write-attribute(name=default-cache,value=repl)
    run-batch
  2. サーバーをリロードします。

    reload
Distribution キャッシュモードへの変更

Web セッションキャッシュのデフォルトの JBoss EAP 7 設定にはすでに dist 分散キャッシュが含まれています。

注記

以下はスタンドアロンサーバーの管理 CLI コマンドになります。管理対象ドメインで実行している場合は、/subsystem=infinispan コマンドの前に /profile=PROFILE_NAME を追加し、更新するプロファイルを指定する必要があります。

  1. デフォルトのキャッシュを dist 分散キャッシュに変更します。

    /subsystem=infinispan/cache-container=web:write-attribute(name=default-cache,value=dist)
  2. 分散キャッシュの所有者数を設定します。以下のコマンドは所有者の数を 5 に設定します。デフォルトは 2 です。

    /subsystem=infinispan/cache-container=web/distributed-cache=dist:write-attribute(name=owners,value=5)
  3. サーバーをリロードします。

    reload
Scattered キャッシュモードの変更

web セッションキャッシュのデフォルトの JBoss EAP 設定には scattered-cache が含まれていません。以下の例は、scattered キャッシュを追加し、デフォルトのキャッシュとして設定する管理 CLI コマンドを示しています。

注記

以下は、HA プロファイルを使用するスタンドアロンサーバー向けの管理 CLI コマンドになります。管理対象ドメインで実行している場合は、/subsystem=infinispan コマンドの前に /profile=PROFILE_NAME を追加し、更新するプロファイルを指定する必要があります。

  1. 読み取りのバイアスライフスパンがデフォルトの web セッションタイムアウト値 (30 分) と同じになるよう、scattered キャッシュを作成します。

    /subsystem=infinispan/cache-container=web/scattered-cache=scattered:add(bias-lifespan=1800000)
  2. scattered をデフォルトキャッシュとして設定します。

    /subsystem=infinispan/cache-container=web:write-attribute(name=default-cache,value=scattered)

これにより、サーバーが以下のように設定されます。

<cache-container name="web" default-cache="scattered" module="org.wildfly.clustering.web.infinispan">
    ...
    <scattered-cache name="scattered" bias-lifespan="1800000"/>
    ...
</cache-container>

24.3.3.2. キャッシュストラテジーのパフォーマンス

SYNCキャッシュストラテジーを使用すると、レプリケーションが完了するまでリクエストが完了しないため、レプリケーションのコストを簡単に評価でき、直接応答時間に影響します。

ASYNC キャッシュストラテジーの応答時間は SYNCキャッシュストラテジーよりも短いと思われがちですが、一定の状況下でのみ短くなります。ASYNC キャッシュストラテジーの評価はより困難ですが、リクエスト間の時間がキャッシュ操作を完了できるほど長い場合はパフォーマンスが SYNC よりも良くなります。これは、レプリケーションのコストが応答時間に即影響しないためです。

同じセッションのリクエストの作成が早すぎると、先行リクエストからのレプリケーションが完了するまで待機しなければならないため、先行リクエストのレプリケーションコストが後続リクエストの前に移動します。応答の受信直後に後続リクエストが送信され、リクエストが急速に発生する場合、 ASYNC キャッシュストラテジーのパフォーマンスは SYNC よりも劣化します。そのため、同じセッションのリクエストの間には、SYNC キャッシュストラテジーのパフォーマンスが ASYNC キャッシュストラテジーよりも良くなる期間のしきい値があります。実際の使用状態では、通常同じセッションのリクエストが立て続けに受信されることはありませんが、一般的にリクエストの間に数秒程度の時間が存在します。その代わりに、通常、要求間に数秒以上の時間が経過します。この場合、ASYNC キャッシュストラテジーが適切なデフォルトで、応答時間が早くなります。

24.3.4. 状態遷移

状態遷移は、基本的なデータグリッドとクラスター化されたキャッシュ機能の両方です。状態遷移がない状態では、ノードがクラスターに追加されたり、クラスターから削除されるとデータが失われます。

状態遷移は、キャッシュメンバーシップの変更に応じて、キャッシュの内部状態を調整します。この変更は、ノードがクラスターに参加または退出するとき、2 つ以上のクラスターパーティションがマージするとき、またはこれらのイベントの組み合わせが発生した後に自動的に行われます。新しいキャッシュは、以下のキャッシュのモードを基にして、最大量の状態を受け取る必要があるため、新たに開始されたキャッシュの最初の状態遷移は最も多くのリソースが必要となります。

timeout 属性を使用すると、新たに開始されたキャッシュが状態を受け取る待ち時間を制御することができます。timeout 属性が正の値である場合、キャッシュはすべての初期状態を受け取るまで待機した後、リクエストに対応できるようになります。状態遷移が指定時間内 (デフォルトは 240000 ミリ秒) に完了しなかった場合、キャッシュによってエラーが発生し、開始がキャンセルされます。timeout0 に設定するとキャッシュは即座に利用可能になり、バックグラウンド操作中に最初の状態を受け取ります。最初の状態遷移が完了するまで、キャッシュが受け取っていないキャッシュエントリーのリクエストは、リモートノードから取得する必要があります。

timeout 属性を 0 に設定するには、以下のコマンドを実行します。

/subsystem=infinispan/cache-container=server/CACHE_TYPE=CACHE/component=state-transfer:write-attribute(name=timeout,value=0)

状態遷移の挙動はキャッシュのモードによって決まります。

  • Replicated (レプリケート) モードでは、キャッシュに参加する新規ノードは既存ノードからキャッシュの状態をすべて受け取ります。ノードがクラスターから退出すると、状態遷移はありません。
  • Distribution (分散) モードでは、新しいノードは既存のノードから状態の一部のみを受け取り、既存のノードは一貫したハッシュの決定どおりに、各キーの owners コピーを維持するために状態の一部を削除します。ノードがクラスターから退出する場合、分散キャッシュはそのノードに保存されたキーの追加コピーを作成し、各キーの所有者が存続するようにする必要デフォルトがあります。
  • Invalidation (インバリデーション) モードでは、最初の状態推移は Replicated モードと似ていますが、ノードが同じ状態でいられる保証がないことが唯一の違いです。ノードがクラスターから退出すると、状態遷移はありません。

デフォルトでは、状態遷移はインメモリーおよび永続状態の両方を遷移しますが、設定で無効にすることもできます。状態遷移が無効になっている場合、ClusterLoader を設定しないと、データをキャッシュにロードせずにノードがキーの所有者またはバックアップ所有者になります。さらに、Distribution モードで状態遷移が無効になっていると、キャッシュでキーのコピーが owners コピーよりも少なくなることがあります。

24.3.5. Infinispan スレッドプールの設定

infinispan サブシステムには async-operationsexpirationlistenerpersistenceremote-commandstate-transfer、および transport スレッドプールが含まれます。これらのプールはすべての Infinispan キャッシュコンテナーに設定できます。

以下の表は、infinispan サブシステムの各スレッドプールに設定できる属性とデフォルト値を表しています。

スレッドプール名keepalive-timemax-threadsmin-threadsqueue-length

async-operations

60000L

25

25

1000

expiration

60000L

1

該当なし

該当なし

listener

60000L

1

1

100000

persistence

60000L

4

1

0

remote-command

60000L

200

1

0

state-transfer

60000L

60

1

0

transport

60000L

25

25

100000

以下の構文を使用して、管理 CLI で Infinispan スレッドプールを設定します。

/subsystem=infinispan/cache-container=CACHE_CONTAINER_NAME/thread-pool=THREAD_POOL_NAME:write-attribute(name=ATTRIBUTE_NAME, value=ATTRIBUTE_VALUE)

以下は、 server キャッシュコンテナーの persistence スレッドプールで max-threads の値を 10 に設定する管理 CLI コマンドの例になります。

/subsystem=infinispan/cache-container=server/thread-pool=persistence:write-attribute(name="max-threads", value="10")

24.3.6. Infinispan の統計

監視目的で、Infinispan キャッシュやキャッシュコンテナーに関する実行時統計を有効にできます。パフォーマンス上の理由で、統計の収集はデフォルトでは無効になっています。

統計収集は、各キャッシュコンテナー、キャッシュ、または両方に対して有効にできます。各キャッシュの統計オプションはキャッシュコンテナーのオプションをオーバーライドします。キャッシュコンテナーの統計収集を無効または有効にすると、独自の設定が明示的に指定されている場合以外はそのコンテナーのすべてのキャッシュが設定を継承します。

24.3.6.1. Infinispan 統計の有効化

警告

Infinispan の統計を有効にすると、infinispan サブシステムのパフォーマンスに影響する可能性があります。統計は必要な場合のみ有効にしてください。

管理コンソールまたは管理 CLI を使用すると Infinispan の統計収集を有効または無効にできます。管理コンソールでは、Configuration タブで Infinispan サブシステム選択してキャッシュまたはキャッシュコンテナーを選択し、Statistics Enabled 属性を編集します。管理 CLI を使用する場合は以下のコマンドを実行して統計を有効にします。

キャッシュコンテナーの統計収集を有効にします。サーバーをリロードする必要があります。

/subsystem=infinispan/cache-container=CACHE_CONTAINER:write-attribute(name=statistics-enabled,value=true)

キャッシュの統計収集を有効にします。サーバーをリロードする必要があります。

/subsystem=infinispan/cache-container=CACHE_CONTAINER/CACHE_TYPE=CACHE:write-attribute(name=statistics-enabled,value=true)
注記

以下のコマンドを使用すると、キャッシュの statistics-enabled 属性の定義が解除され、キャッシュコンテナーの statistics-enabled 属性の設定を継承します。

/subsystem=infinispan/cache-container=CACHE_CONTAINER/CACHE_TYPE=CACHE:undefine-attribute(name=statistics-enabled)

24.3.7. Infinispan パーティションの処理

Infinispan クラスターは、データが保存される複数のノードで構築されます。複数のノードに障害が発生した場合のデータの損失を防ぐため、Infinispan は複数のノードで同じデータをコピーします。このレベルのデータ冗長性は owners 属性を使用して設定されます。設定されたノードの数未満のノードが同時にクラッシュしても、Infinispan はデータのコピーを利用できます。

しかし、クラスターから大量のノードが消滅すると最悪の事態を招く可能性があります。

スプリットブレイン

スプリットブレインはクラスターを独立して動作する 2 つ以上のパーティションまたはサブクラスターに分割します。このような場合、異なるパーティションから読み書きする複数のクライアントが同じキャッシュエントリーの異なるバージョンを見ることになり、多くのアプリケーションにとって問題となります。

注記

スプリットブレインの発生を軽減する方法には、冗長化ネットワークや IP ボンディングなどがあります。 しかし、これらの方法は問題発生のリードタイムを削減するだけです。

複数ノードの連続クラッシュ
複数のノード (所有者の数) が連続してクラッシュし、Infinispan がクラッシュ間の状態を適切に調整する時間がない場合、結果として部分的なデータの損失が発生します。

スプリットブレインや複数ノードの連続クラッシュが原因で、不適切なデータがユーザーに返されないようにすることが大切です。

24.3.7.1. スプリットブレイン

スプリットブレインが発生した場合、各ネットワークパーティションが独自の JGroups ビューをインストールし、他のパーティションからノードを削除します。パーティションはお互いを認識しないため、クラスターが 2 つ以上のパーティションに分割されたかどうかを直接判断することはできません。そのため、明示的な脱退メッセージを送信せずに、1 つ以上のノードが JGroups クラスターから消滅した場合にクラスターが分割されたと判断します。

パーティション処理が無効の場合、各パーティションは継続して独立したクラスターとして機能します。各パーティションはデータの一部のみを認識できる可能性があり、競合する更新をキャッシュに書き込む可能性があります。

パーティション処理が有効の場合、スプリットを検出したときに各パーティションは即座にリバランスを行わず、degrade モードにするかどうかを最初にチェックします。

  • 1 つ以上のセグメントがすべての所有者を失った場合 (最後に行ったリバランスが完了した後に指定した所有者の数以上が脱退した場合)、パーティションは degrade モードになります。
  • 最新の安定したトポロジーでパーティションに単純多数のノード (floor(numNodes/2) + 1) が含まれない場合も、パーティションは degrade モードになります。
  • その他の場合は、パーティションは通常通り動作し、リバランスを開始します。

安定したトポロジーは、リバランス操作が終了するたびに更新され、コーディネーターによって他のリバランスが必要ないと判断された場合に毎回更新されます。これらのルールは、1 つのパーティションが available モードを維持し、他のパーティションが degraded モードになるようにします。

パーティションが degraded モードの場合、完全に所有されたキーへのアクセスのみを許可します。

  • このパーティション内のノード上のコピーをすべて持つエントリーのリクエスト (読み取りおよび書き込み) は許可されます。
  • 消滅したノードによって完全所有または一部所有されたエントリーのリクエストは AvailabilityException によって拒否されます。

これにより、パーティションが同じキーに異なる値を書き込めないようにし (キャッシュの一貫性を保つ) 、さらにパーティションが他のパーティションで更新されたキーを読み取れないようにします (陳腐データをなくす)。

注記

2 つのパーティションは分離して開始できます。これらのパーティションはマージされなければ不整合なデータを読み書きできます。 将来的に、この状況に対処できるカスタムの可用性ストラテジーが許可される可能性があります (例: 特定のノードがクラスターの一部であるかを確認、外部のマシンにアクセスできるかどうかを確認など)。

24.3.7.2. パーティション処理の設定

現在、パーティションの処理はデフォルトで無効になっています。パーティションの処理を有効にするには、以下の管理 CLI コマンドを使用します。

/subsystem=infinispan/cache-container=web/distributed-cache=dist/component=partition-handling:write-attribute(name=enabled, value=true)

24.3.8. リモートキャッシュコンテナーの設定

24.3.9. リモートキャッシュコンテナーの作成

管理対象ドメインの各サーバーグループには、一意のリモートキャッシュが必要です。このキャッシュは、同じデータグリッドに所属することができます。そのため、ユーザーは、サーバーグループのソケットバインディングを定義し、ソケットバインディングをリモートキャッシュコンテナーに関連付けることにより、すべてのサーバーグループのリモートキャッシュを設定する必要があります。

手順

  1. socket-binding を定義します。 クラスターの各リモート Red Hat Data Grid インスタンスの必要に応じて、コマンドを繰り返し実行します。

    /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=SOCKET_BINDING:add(host=HOSTNAME,port=PORT)
  2. 新規作成されたソケットバインディングを参照する remote-cache-container を定義します。

    batch
    /subsystem=infinispan/remote-cache-container=CACHE_CONTAINER:add(default-remote-cluster=data-grid-cluster)
    /subsystem=infinispan/remote-cache-container=CACHE_CONTAINER/remote-cluster=data-grid-cluster:add(socket-bindings=[SOCKET_BINDING,SOCKET_BINDING_2,...])
    run-batch

24.3.10. リモートキャッシュコンテナーの統計の有効化

statistics-enabled 属性により、指定の remote-cache-container および関連するランタイムキャッシュについてのメトリクスのコレクションが有効になります。

  • 「foo」という remote-cache-container 場合は、次の操作を使用して統計を有効にします。
/subsystem=infinispan/remote-cache-container=foo:write-attribute(name=statistics-enabled, value=true)
  • 「foo」という remote-cache-container については、以下のメトリクスがランタイム時に表示されます。
/subsystem=infinispan/remote-cache-container=foo:read-attribute(name=connections)
/subsystem=infinispan/remote-cache-container=foo:read-attribute(name=active-connections)
/subsystem=infinispan/remote-cache-container=foo:read-attribute(name=idle-connections)
  • これらのメトリクスの説明は、remote-cache-container に read-resource-description 操作を実行します。
/subsystem=infinispan/remote-cache-container=foo:read-resource-description
  • 以下のメトリクスは、選択したデプロイメントによって使用されるリモートキャッシュに固有のものです。
/subsystem=infinispan/remote-cache-container=foo/remote-cache=bar.war:read-resource(include-runtime=true, recursive=true)
{
    "average-read-time" : 1,
    "average-remove-time" : 0,
    "average-write-time" : 2,
    "hits" : 9,
    "misses" : 0,
    "near-cache-hits" : 7,
    "near-cache-invalidations" : 8,
    "near-cache-misses" : 9,
    "near-cache-size" : 1,
    "removes" : 0,
    "time-since-reset" : 82344,
    "writes" : 8
}
  • これらのメトリクスの説明は、リモートキャッシュに対して read-resource-description 操作を実行します。
/subsystem=infinispan/remote-cache-container=foo/remote-cache=bar.war:read-resource-description
  • これらのメトリクスの一部は計算値 (例: average- *) であり、ヒットやミスなどのその他は集計値です。この集計メトリクスは、以下の操作でリセットできます。
/subsystem=infinispan/remote-cache-container=foo/remote-cache=bar.war:reset-statistics()

24.3.11. HTTP セッションの Red Hat Data Grid への外部化

注記

この機能を使用するには Red Hat Data Grid のサブスクリプションが必要です。

Red Hat Data Grid は、HTTP セッションなどの JBoss EAP のアプリケーション固有データの外部キャッシュコンテナーとして使用できます。これにより、アプリケーションとは独立したデータレイヤーのスケーリングが可能になり、さまざまなドメインに存在する可能性がある異なる JBoss EAP クラスターが同じ Red Hat Data Grid クラスターからデータにアクセスできるようになります。また、他のアプリケーションは Red Hat Data Grid によって提供されたキャッシュと対話できます。

以下の例は、HTTP セッションを外部化する方法を説明しています。これは、JBoss EAP のスタンドアロンインスタンスと管理対象ドメインの両方に適用されます。

  1. remote-cache-container を作成します。詳細は、「リモートキャッシュコンテナーの設定」を参照してください。
  2. HotRod ストアを設定します。HotRod ストアは、JBoss EAP サーバーによって作成された各キャッシュに対して専用のリモートキャッシュを 1 つ使用します。通常、以下の CLI スクリプトのように、JBoss EAP サーバーで 1 つのインバリデーション キャッシュが使用されます。

    注記

    Red Hat JDG サーバーでリモートキャッシュを手作業で設定する必要があります。これらのキャッシュに推奨される設定は、楽観的ロックを持つトランザクション分散モードです。キャッシュ名はデプロイメントファイル名に対応する必要があります (例: test.war)。

    リモートキャッシュコンテナーが設定されたら、hotrod ストアを設定して既存のストアを置き換えることができます。以下の CLI スクリプトは、インバリデーションキャッシュとともにセッションをオフロードする典型的なユースケースを示しています。

    batch
    /subsystem=infinispan/cache-container=web/invalidation-cache=CACHE_NAME:add()
    /subsystem=infinispan/cache-container=web/invalidation-cache=CACHE_NAME/store=hotrod:add(remote-cache-container=CACHE_CONTAINER,fetch-state=false,purge=false,passivation=false,shared=true)
    /subsystem=infinispan/cache-container=web/invalidation-cache=CACHE_NAME/component=transaction:add(mode=BATCH)
    /subsystem=infinispan/cache-container=web/invalidation-cache=CACHE_NAME/component=locking:add(isolation=REPEATABLE_READ)
    /subsystem=infinispan/cache-container=web:write-attribute(name=default-cache,value=CACHE_NAME)
    run-batch

    このスクリプトは新しいインバリデーションキャッシュを設定します。作成後、セッションデータはパフォーマンスの目的でキャッシュに維持され、復元の目的でストアに書き込まれます。

    @Resource アノテーションを使用すると、HotRod クライアントを直接 Jakarta EE アプリケーションにインジェクトすることができます。@Resource アノテーションは hotrod-client.properties ファイルで、クラスパスの設定プロパティーを検索します。

    @Resource(lookup = "java:jboss/infinispan/remote-container/web-sessions")
    private org.infinispan.client.hotrod.RemoteCacheContainer client;

    例: hotrod-client.properties ファイル

    infinispan.client.hotrod.transport_factory = org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory
    infinispan.client.hotrod.server_list = 127.0.0.1:11222
    infinispan.client.hotrod.marshaller = org.infinispan.commons.marshall.jboss.GenericJBossMarshaller
    infinispan.client.hotrod.async_executor_factory = org.infinispan.client.hotrod.impl.async.DefaultAsyncExecutorFactory
    infinispan.client.hotrod.default_executor_factory.pool_size = 1
    infinispan.client.hotrod.default_executor_factory.queue_size = 10000
    infinispan.client.hotrod.hash_function_impl.1 = org.infinispan.client.hotrod.impl.consistenthash.ConsistentHashV1
    infinispan.client.hotrod.tcp_no_delay = true
    infinispan.client.hotrod.ping_on_startup = true
    infinispan.client.hotrod.request_balancing_strategy = org.infinispan.client.hotrod.impl.transport.tcp.RoundRobinBalancingStrategy
    infinispan.client.hotrod.key_size_estimate = 64
    infinispan.client.hotrod.value_size_estimate = 512
    infinispan.client.hotrod.force_return_values = false
    
    ## below is connection pooling config
    
    maxActive=-1
    maxTotal = -1
    maxIdle = -1
    whenExhaustedAction = 1
    timeBetweenEvictionRunsMillis=120000
    minEvictableIdleTimeMillis=300000
    testWhileIdle = true
    minIdle = 1

リモートキャッシュコンテナーのセキュア化

SSL を使用してリモート Red Hat Data Grid インスタンスへの通信をセキュアにすることが可能です。これを行うには、JBoss EAP インスタンスで remote-cache-container を設定し、Red Hat Data Grid インスタンスで hotrod コネクターを調整してアクティブなセキュリティーレルムを使用するようにします。

  1. JBoss EAP で client-ssl-context を作成します。他の elytron コンポーネントの生成など、client-ssl-context 作成のその他の詳細は、JBoss EAP『How to Configure Server Security』の「Using a client-ssl-context」を参照してください。

    /subsystem=elytron/client-ssl-context=CLIENT_SSL_CONTEXT:add(key-manager=KEY_MANAGER,trust-manager=TRUST_MANAGER)
  2. クライアント SSL コンテキストを使用するよう、リモートキャッシュコンテナーを設定します。

    /subsystem=infinispan/remote-cache-container=CACHE_CONTAINER/component=security:write-attribute(name=ssl-context,value=CLIENT_SSL_CONTEXT)
  3. リモート Red Hat Data Grid インスタンスをセキュアにします。各インスタンスの必要に応じて手順を繰り返します。

    1. client-ssl-context で使用されるキーストアをリモート Red Hat Data Grid インスタンスにコピーします。
    2. ApplicationRealm を設定して、このキーストアを使用するようにします。

      /core-service=management/security-realm=ApplicationRealm/server-identity=ssl:add(keystore-path="KEYSTORE_NAME",keystore-relative-to="jboss.server.config.dir",keystore-password="KEYSTORE_PASSWORD")
    3. hotrod コネクターを調整して、このセキュリティーレルムを示すようにします。

      /subsystem=datagrid-infinispan-endpoint/hotrod-connector=hotrod-connector/encryption=ENCRYPTION:add(require-ssl-client-auth=false,security-realm="ApplicationRealm")
    4. リモート Red Hat Data Grid インスタンスをリロードします。

      reload

24.3.12. リモートストアを使用した HTTP セッションの Red Hat Data Grid への外部化

注記

この機能を使用するには Red Hat Data Grid のサブスクリプションが必要です。

この手順は、セッションを外部化する旧式の方法になります。JBoss EAP 7.2 には、elytron サブシステムと統合する HotRod プロトコルをベースとするカスタムの最適化されたキャッシュストアが導入されました。「HTTP セッションの JBoss Data Grid への外部化」の説明にしたがって、新しい hotrod ストアを使用することが推奨されます。

注記

分散可能なアプリケーションごとに完全に新しいキャッシュを作成する必要があります。新しいキャッシュは web などの既存のキャッシュコンテナーに作成できます。

HTTP セッションを外部化するには、以下を行います。

  1. ネットワーク情報を socket-binding-group に追加することにより、リモート Red Hat Data Grid サーバーの場所を定義します。

    例: リモートソケットバインディングの追加

    /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=remote-rhdg-server1:add(host=RHDGHostName1, port=11222)
    
    /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=remote-rhdg-server2:add(host=RHDGHostName2, port=11222)

    結果の XML

    <socket-binding-group name="standard-sockets" ... >
      ...
      <outbound-socket-binding name="remote-rhdg-server1">
        <remote-destination host="RHDGHostName1" port="11222"/>
      </outbound-socket-binding>
      <outbound-socket-binding name="remote-rhdg-server2">
        <remote-destination host="RHDGHostName2" port="11222"/>
      </outbound-socket-binding>
    </socket-binding-group>

    注記

    各 Red Hat Data Grid サーバーにリモートソケットバインディングを設定する必要があります。

  2. リモートキャッシュコンテナーが JBoss EAP の infinispan サブシステムで定義されているようにしてください。 以下の例では、remote-store 要素の cache 属性によって、リモート Red Hat Data Grid サーバーのキャッシュ名が定義されます。

    管理対象ドメインで実行している場合は、コマンドの前に /profile=PROFILE_NAME を追加してください。

    例: リモートキャッシュコンテナーの追加

    /subsystem=infinispan/cache-container=web/invalidation-cache=rhdg:add(mode=SYNC)
    
    /subsystem=infinispan/cache-container=web/invalidation-cache=rhdg/component=locking:write-attribute(name=isolation,value=REPEATABLE_READ)
    
    /subsystem=infinispan/cache-container=web/invalidation-cache=rhdg/component=transaction:write-attribute(name=mode,value=BATCH)
    
    /subsystem=infinispan/cache-container=web/invalidation-cache=rhdg/store=remote:add(remote-servers=["remote-rhdg-server1","remote-rhdg-server2"], cache=default, socket-timeout=60000, passivation=false, purge=false, shared=true)

    結果の XML

    <subsystem xmlns="urn:jboss:domain:infinispan:7.0">
      ...
      <cache-container name="web" default-cache="dist" module="org.wildfly.clustering.web.infinispan" statistics-enabled="true">
        <transport lock-timeout="60000"/>
        <invalidation-cache name="rhdg" mode="SYNC">
          <locking isolation="REPEATABLE_READ"/>
          <transaction mode="BATCH"/>
          <remote-store cache="default" socket-timeout="60000" remote-servers="remote-rhdg-server1 remote-rhdg-server2" passivation="false" purge="false" shared="true"/>
        </invalidation-cache>
        ...
      </cache-container>
    </subsystem>

  3. キャッシュ情報をアプリケーションの jboss-web.xml ファイルに追加します。以下の例では、web はキャッシュコンテナーの名前で、rhdg はこのコンテナーにある適切なキャッシュの名前になります。

    例: jboss-web.xml ファイル

    <?xml version="1.0" encoding="UTF-8"?>
    <jboss-web xmlns="http://www.jboss.com/xml/ns/javaee"
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
               xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-web_10_0.xsd"
               version="10.0">
        <replication-config>
            <replication-granularity>SESSION</replication-granularity>
            <cache-name>web.rhdg</cache-name>
        </replication-config>
    </jboss-web>

  4. オプション: オーバーレイ設定を指定して、<overlay> の HTML、イメージ、またはビデオなどの静的 Web リソースが含まれる外部ディレクトリーにリンクできます。<overlay> 要素はアプリケーションの jboss-web.xml ファイルにあります。この設定では、アプリケーションを再パッケージ化する必要はありません。

    以下の例は、<overlay> 要素のシステムプロパティーの置換を示しています。${example.path.to.overlay}/PATH/TO/STATIC/WEB/CONTENT の場所を定義します。

    例: jboss-web.xml ファイルの <overlay> 要素

    <jboss-web>
            <overlay>${example.path.to.overlay}</overlay>
    </jboss-web>

    jboss-descriptor-property-replacementtrue に設定されている場合、<overlay> 要素 にシステムプロパティーを指定できます。

    jboss-descriptor-property-replacement を設定するには、以下の管理 CLI コマンドを使用します。

    /subsystem=ee:write-attribute(name=jboss-descriptor-property-replacement,value=true)

    このコマンドは、以下の XML コンテンツを JBoss EAP 設定の ee サブシステムに追加します。

    <subsystem xmlns="urn:jboss:domain:ee:4.0">
        <jboss-descriptor-property-replacement>true</jboss-descriptor-property-replacement>
    </subsystem>

24.4. JBoss EAP をフロントエンドロードバランサーとして設定

バックエンド JBoss EAP サーバーへリクエストをプロキシーするフロントエンドロードバランサーとして動作するよう JBoss EAP と undertow サブシステムを設定できます。Undertow は非同期 IO を使用するため、リクエストに関与するスレッドは接続用の IO スレッドのみになります。同じスレッドがバックエンドサーバーへの接続に使用されます。

以下のプロトコルを使用できます。

  • HTTP/1 および HTTP/2 (h2c) をサポートするプレーンテキスト上の HTTP (http)
  • HTTP/1 および HTTP/2 (h2c) をサポートするセキュアの接続上の HTTP (http)
  • AJP (ajp)

静的ロードバランサーを定義して設定でバックエンドホストを指定するか、mod_cluster フロントエンドを使用してホストを動的に更新します。

HTTP/2 を使用するよう Undertow を設定する手順は、「HTTP/2 の設定」を参照してください。

24.4.1. mod_cluster を使用して Undertow をロードバランサーとして設定

組み込みの mod_cluster フロントエンドロードバランサーを使用して、他の EAP インスタンスを負荷分散できます。

この手順では、管理対象ドメインを実行し、以下が設定済みであることを前提としています。

  • ロードバランサーとして動作する JBoss EAP サーバー。

    • このサーバーは、load-balancer-sockets ソケットバインディンググループにバインドされる load-balancer プロファイルを使用します。

      注記

      このサーバーをフロントエンドロードバランサーとして使用するため、load-balancer プロファイルには、ソケットバインディング、mod-cluster Undertow フィルター、およびデフォルトホストでのフィルターへの参照がすでに事前設定されています。

  • バックエンドサーバーとして動作する 2 つの JBoss EAP サーバー。

    • これらのサーバーはクラスターで実行され、ha-sockets ソケットバインディンググループにバインドされる ha プロファイルを使用します。
  • バックエンドサーバーにデプロイされた負荷分散される分散可能なアプリケーション。

mod_cluster フロントエンドロードバランサーの設定

以下の手順は、管理対象ドメインのサーバーを負荷分散しますが、手順を変更するとスタンドアロンサーバーのセットに適用することができます。ご使用の環境に応じて管理 CLI コマンドの値を変更してください。

  1. mod_cluster アドバタイズセキュリティーキーを設定します。

    アドバタイズセキュリティーキーを追加すると、ロードバランサーとサーバーが検出中に認証されます。

    以下の管理 CLI コマンドを使用して、mod_cluster アドバタイズセキュリティーキーを設定します。

    /profile=ha/subsystem=modcluster/proxy=default:write-attribute(name=advertise-security-key, value=mypassword)
  2. mod_cluster ロードバランサーのセキュリティーキーを更新します。

    以下の管理 CLI コマンドを使用して、mod_cluster フィルターのセキュリティーキーを設定します。

    /profile=load-balancer/subsystem=undertow/configuration=filter/mod-cluster=load-balancer:write-attribute(name=security-key,value=mypassword)
重要

mod_cluster によって使用される管理およびアドバタイズソケットバインディングが内部ネットワークのみで公開され、パブリック IP アドレスで公開されないことが推奨されます。

ロードバランサーである JBoss EAP サーバーが 2 つのバックエンドである JBoss EAP サーバーを負荷分散できるようになります。

複数の mod_cluster 設定

mod_cluster サブシステムは名前の付いたプロキシー設定を複数サポートし、デフォルトでない undertow サーバーをリバースプロキシーに登録できます。さらに、単一のアプリケーションサーバーノードを異なるグループのプロキシーサーバーに登録することができます。

以下の例は、ajp-listener、サーバー、および undertow サーバーへのホストを追加します。また、アドバタイズのメカニズムを使用してホストを登録する新しい mod_cluster 設定も追加します。

/socket-binding-group=standard-sockets/socket-binding=ajp-other:add(port=8010)
/subsystem=undertow/server=other-server:add
/subsystem=undertow/server=other-server/ajp-listener=ajp-other:add(socket-binding=ajp-other)
/subsystem=undertow/server=other-server/host=other-host:add(default-web-module=root-other.war)
/subsystem=undertow/server=other-server/host=other-host
/location=other:add(handler=welcome-content)
/subsystem=undertow/server=other-server/host=other-host:write-attribute(name=alias,value=[localhost]))

/socket-binding-group=standard-sockets/socket-binding=modcluster-other:add(multicast-address=224.0.1.106,multicast-port=23364)
/subsystem=modcluster/proxy=other:add(advertise-socket=modcluster-other,balancer=other-balancer,connector=ajp-other)

reload

24.4.2. ロードバランサーでのランク付けされたセッションアフィニティーの有効化

distributable-web サブシステムで複数の順序付けされたルートを持つセッションアフィニティーを設定するには、ランク付けされたセッションアフィニティーをロードバランサーで有効にする必要があります。distributable-web サブシステムと各種アフィニティオプションの詳細は、JBoss EAP『開発ガイド』の「分散可能な Web セッション設定の distributable-web サブシステム」を参照してください。

ノードルートを分離するデフォルトの区切り文字は . です。別の値が必要な場合は、affinity リソースの delimiter 属性を設定できます。

手順

  1. ロードバランサーに対して、ランク付けされたセッションアフィニティを有効にします。

    /subsystem=undertow/configuration=filter/mod-cluster=load-balancer/affinity=ranked:add
  2. オプション: affinity リソースの delimiter 属性を設定します。

    /subsystem=undertow/configuration=filter/mod-cluster=load-balancer/affinity=ranked:write-attribute(name=delimiter,value=':')

24.4.3. Undertow を静的ロードバランサーとして設定

Undertow の静的ロードバランサーを設定するには、undertow サブシステムでプロキシーハンドラーを設定する必要があります。Undertow でプロキシーハンドラーを設定するには、静的ロードバランサーとして動作する JBoss EAP インスタンスで以下を行う必要があります。

  1. リバースプロキシーハンドラーを追加します。
  2. 各リモートホストのアウトバウンドソケットバインディングを定義します。
  3. 各リモートホストをリバースプロキシーハンドラーへ追加します。
  4. リバースプロキシーの場所を追加します。

以下の例は、JBoss EAP インスタンスを静的ロードバランサーとして設定する方法を示しています。JBoss EAP インスタンスは lb.example.com にあり、2 つの追加サーバーである server1.example.comserver2.example.com との間で負荷分散を行います。ロードバランサーは /app に逆プロキシーを行い、AJP プロトコルを使用します。

  1. リバースプロキシーハンドラーを追加するには、以下を指定します。

    /subsystem=undertow/configuration=handler/reverse-proxy=my-handler:add
  2. 各リモートホストのアウトバウンドソケットバインディングを定義するには、以下を指定します。

    /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=remote-host1/:add(host=server1.example.com, port=8009)
    
    /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=remote-host2/:add(host=server2.example.com, port=8009)
  3. 各リモートホストをリバースプロキシーハンドラーに追加するには、以下を指定します。

    /subsystem=undertow/configuration=handler/reverse-proxy=my-handler/host=host1:add(outbound-socket-binding=remote-host1, scheme=ajp, instance-id=myroute1, path=/test)
    
    /subsystem=undertow/configuration=handler/reverse-proxy=my-handler/host=host2:add(outbound-socket-binding=remote-host2, scheme=ajp, instance-id=myroute2, path=/test)
  4. リバースプロキシーの場所を追加するには、以下を指定します。

    /subsystem=undertow/server=default-server/host=default-host/location=\/test:add(handler=my-handler)

lb.example.com:8080/app にアクセスすると、server1.example.com および server2.example.com からプロキシーされた内容が表示されるようになります。

24.4.4. 外部 Web サーバーのプロキシーサーバーとしての使用

JBoss EAP は、外部 Web サーバーの設定に応じて、サポートされる HTTP、HTTPS、または AJP プロトコルを使用して外部 Web サーバーからリクエストを許可できます。

各 Web サーバーのサポートされる HTTP コネクターの詳細は、「HTTP コネクターの概要」を参照してください。使用する Web サーバーと HTTP コネクターを決定したら、適切なコネクターの設定情報の項を参照してください。

HTTP コネクターのサポートされる構成に関する最新情報は、「JBoss EAP でサポートされる構成」を参照してください。

また、JBoss EAP が外部 Web サーバーからのリクエストを許可するよう設定されている必要があります。

24.4.4.1. HTTP コネクターの概要

JBoss EAP には、Apache HTTP Server、Microsoft IIS、Oracle iPlanet などの外部 Web サーバーや Undertow より構築された負荷分散およびクラスタリングメカニズムを使用する機能があります。JBoss EAP はコネクターを使用して Web サーバーと通信します。これらのコネクターは JBoss EAP の undertow サブシステム内に設定されます。

Web サーバーには、HTTP リクエストが JBoss EAP ノードにルーティングされる方法を制御するソフトウェアモジュールが含まれています。これらのモジュールの挙動や設定方法はモジュールごとに異なります。モジュールは、複数の JBoss EAP ノード全体でワークロードを分散したり、障害発生時にワークロードを他のサーバーに移動したりするために設定されます。

JBoss EAP は複数のコネクターをサポートします。使用中の Web サーバーや必要な機能に応じてコネクターを選択します。以下の表を参照して、サポートされる構成と、JBoss EAP と互換性のある HTTP コネクターの機能を比較してください。

注記

JBoss EAP 7 をマルチプラットフォームロードバランサーとして使用する場合は 「mod_cluster を使用して Undertow をロードバランサーとして設定」を参照してください。

HTTP コネクターのサポートされる構成に関する最新情報は、「JBoss EAP でサポートされる構成」を参照してください。

表24.1 HTTP コネクターでサポートされる構成

コネクターWeb Serverサポート対象オペレーティングシステムサポート対象プロトコル

mod_cluster

Red Hat JBoss Core Services の Apache HTTP Server、Red Hat JBoss Web Server の Apache HTTP Server、JBoss EAP (Undertow)

Red Hat Enterprise Linux、Microsoft Windows Server、Oracle Solaris

HTTP、HTTPS、AJP、WebSocket

mod_jk

Red Hat JBoss Core Services の Apache HTTP Server、Red Hat JBoss Web Server の Apache HTTP Server

Red Hat Enterprise Linux、Microsoft Windows Server、Oracle Solaris

AJP

mod_proxy

Red Hat JBoss Core Services の Apache HTTP Server、Red Hat JBoss Web Server の Apache HTTP Server

Red Hat Enterprise Linux、Microsoft Windows Server、Oracle Solaris

HTTP、HTTPS、AJP

ISAPI コネクター

Microsoft IIS

Microsoft Windows Server

AJP

NSAPI コネクター

Oracle iPlanet Web Server

Oracle Solaris

AJP

表24.2 HTTP コネクターの機能

コネクタースティッキーセッションのサポートデプロイメント状態への適合

mod_cluster

可。アプリケーションのデプロイメントとアンデプロイメントを検出し、アプリケーションがそのサーバーにデプロイされたかどうかに基づいて、サーバーにクライアント要求を送信するかどうかを動的に決定します。

mod_jk

不可。 アプリケーションの状態に関係なく、コンテナーが利用可能な限り、クライアント要求をコンテナーに送信します。

mod_proxy

不可。 アプリケーションの状態に関係なく、コンテナーが利用可能な限り、クライアント要求をコンテナーに送信します。

ISAPI コネクター

不可。 アプリケーションの状態に関係なく、コンテナーが利用可能な限り、クライアント要求をコンテナーに送信します。

NSAPI コネクター

不可。 アプリケーションの状態に関係なく、コンテナーが利用可能な限り、クライアント要求をコンテナーに送信します。

24.4.4.2. Apache HTTP Server

スタンドアロン Apache HTTP Server バンドルは、Red Hat JBoss Core Services の個別ダウンロードとして利用できるようになりました。これにより、インストールと設定が容易になり、更新の一貫性が保たれます。

24.4.4.2.1. Apache HTTP Server のインストール

Apache HTTP Server のインストールに関する詳細は、JBoss Core Services の『Apache HTTP Server Installation Guide』を参照してください。

24.4.4.3. 外部 Web サーバーからのリクエストの許可

JBoss EAP に AJP、HTTP、 HTTPS などの適切なプロトコルハンドラーが設定されていれば、プロキシーサーバーからのリクエストを許可するための特別な設定は必要ありません。

プロキシーサーバーが mod_jk、mod_proxy、ISAPI、または NSAPI を使用する場合、リクエストを JBoss EAP に送信し、JBoss EAP は応答を返信します。mod_cluster の場合、リクエストをどこにルーティングするかを判断できるようにするため、JBoss EAP が現在の負荷、アプリケーションライフサイクルイベント、ヘルス状態などの情報をプロキシーサーバーへ送信できるようネットワークを設定する必要もあります。mod_cluster プロキシーサーバーの設定に関する詳細は「mod_cluster HTTP コネクター」を参照してください。

JBoss EAP 設定の更新

以下の手順では、例で使用されているプロトコルやポートを実際に設定する必要があるプロトコルやポートに置き換えてください。

  1. Undertow の instance-id 属性を設定します。

    外部 Web サーバーは instance-id を使用してコネクター設定の JBoss EAP インスタンスを識別します。以下の管理 CLI コマンドを使用して、Undertow で instance-id 属性を設定します。

    /subsystem=undertow:write-attribute(name=instance-id,value=node1)

    上記の例では、外部 Web サーバーは現在の JBoss EAP インスタンスを node1 として識別します。

  2. 必要なリスナーを Undertow に追加します。

    外部 Web サーバーが JBoss EAP に接続するには、Undertow にリスナーが必要です。各プロトコルにはソケットバインディングに関連する独自のリスナーが必要です。

    注記

    プロトコルやポート設定によってはこの手順は必要でないことがあります。HTTP リスナーはデフォルトの JBoss EAP 設定すべてに設定されており、ha または full-ha プロファイルを使用している場合、AJP リスナーは設定されています。

    デフォルトのサーバー設定を確認すると、必要なリスナーが設定済みであるかどうかを確認できます。

    /subsystem=undertow/server=default-server:read-resource

    リスナーを Undertow に追加するには、ソケットバインディングが必要です。ソケットバインディングは、サーバーまたはサーバーグループによって使用されるソケットバインディンググループに追加されます。以下の管理 CLI コマンドを使用すると ajp ソケットバインディングが追加され、ポート 8009standard-sockets ソケットバインディンググループにバインドされます。

    /socket-binding-group=standard-sockets/socket-binding=ajp:add(port=8009)

    以下の管理 CLI コマンドを使用すると ajp ソケットバインディングを使用して ajp リスナーが Undertow に追加されます。

    /subsystem=undertow/server=default-server/ajp-listener=ajp:add(socket-binding=ajp)

24.4.5. mod_cluster HTTP コネクター

mod_cluster コネクターは Apache HTTP Server ベースのロードバランサーです。通信チャネルを使用して、リクエストを Apache HTTP Server からアプリケーションサーバーノードのセットの 1 つに転送します。

他のコネクターと比べて mod_cluster コネクターには複数の利点があります。

  • mod_cluster Management Protocol (MCMP) は、JBoss EAP サーバーと mod_cluster が有効な Apache HTTP Server との間の追加的な接続です。HTTP メソッドのカスタムセットを使用してサーバー側の負荷分散係数およびライフサイクルイベントを Apache HTTP Server サーバーに返信するために JBoss EAP サーバーによって使用されます。
  • mod_cluster がある Apache HTTP Server を動的に設定すると、手動設定を行わずに JBoss EAP サーバーが負荷分散に参加できます。
  • JBoss EAP は、mod_cluster がある Apache HTTP Server に依存せずに負荷分散係数の計算を行います。これにより、負荷分散メトリックが他のコネクターよりも正確になります。
  • mod_cluster コネクターにより、アプリケーションライフサイクルを細かく制御できるようになります。各 JBoss EAP サーバーは Web アプリケーションコンテキストライフサイクルイベントを Apache HTTP Server サーバーに転送し、指定コンテキストのルーティングリクエストを開始または停止するよう通知します。これにより、リソースを使用できないことが原因の HTTP エラーがエンドユーザーに表示されないようになります。
  • AJP、HTTP、または HTTPS トランスポートを使用できます。

modcluster サブシステムの特定の設定オプションに関する詳細は、「ModCluster サブシステムの属性」を参照してください。

24.4.5.1. Apache HTTP Server の mod_cluster の設定

JBoss Core Services Apache HTTP Server をインストールする場合や JBoss Web Server を使用する場合、mod_cluster モジュールはすでに含まれており、デフォルトでロードされます。

注記

JBoss Web Server バージョン 3.1.0 より、Apache HTTP Server は配布されないようになりました。

以下の手順を参照し、お使いの環境に合った mod_cluster モジュールを設定します。

注記

Red Hat のお客様は Red Hat カスタマーポータルにある Load Balancer Configuration Tool を使用して mod_cluster やその他のコネクターに最適な設定テンプレートを迅速に生成することもできます。このツールを使用するにはログインする必要があります。

mod_cluster の設定

Apache HTTP Server には、mod_cluster モジュールをロードし、基本設定を提供する mod_cluster 設定ファイル mod_cluster.conf がすでに含まれています。このファイルに指定されている IP アドレス、ポート、およびその他の設定 (以下参照) は必要に応じて変更できます。

# mod_proxy_balancer should be disabled when mod_cluster is used
LoadModule proxy_cluster_module modules/mod_proxy_cluster.so
LoadModule cluster_slotmem_module modules/mod_cluster_slotmem.so
LoadModule manager_module modules/mod_manager.so
LoadModule advertise_module modules/mod_advertise.so

MemManagerFile cache/mod_cluster

<IfModule manager_module>
  Listen 6666
  <VirtualHost *:6666>
    <Directory />
      Require ip 127.0.0.1
    </Directory>
    ServerAdvertise on
    EnableMCPMReceive
    <Location /mod_cluster_manager>
      SetHandler mod_cluster-manager
      Require ip 127.0.0.1
   </Location>
  </VirtualHost>
</IfModule>

Apache HTTP Server サーバーはロードバランサーとして設定でき、JBoss EAP で実行されている modcluster サブシステムと動作します。JBoss EAP が mod_cluster を認識するよう mod_cluster ワーカーノードを設定する必要があります。

mod_cluster のアドバタイズを無効にし、代わりに静的プロキシーリストを設定する場合は「mod_cluster のアドバタイズの無効化」を参照してください。Apache HTTP Server で使用できる mod_cluster 設定オプションの詳細は、「Apache HTTP Server の mod_cluster ディレクティブ」を参照してください。

mod_cluster の設定に関する詳細は、JBoss Web Server『HTTP Connectors and Load Balancing Guide』の「Configure Load Balancing Using Apache HTTP Server and mod_cluster」を参照してください。

24.4.5.2. mod_cluster のアドバタイズの無効化

デフォルトでは、modcluster サブシステムのバランサーはマルチキャスト UDP を使用して可用性をバックグラウンドワーカーにアドバタイズします。アドバタイズを無効にし、代わりにプロキシーリストを使用する場合は、以下の手順に従ってください。

注記

以下の手順の管理 CLI コマンドは、管理対象ドメインで full-ha プロファイルを使用していることを前提としています。full-ha 以外のプロファイルを使用している場合は、コマンドに適切なプロファイル名を使用してください。スタンドアロンサーバーを実行している場合は /profile=full-ha を削除してください。

  1. Apache HTTP Server 設定を変更します。

    httpd.conf Apache HTTP Server 設定ファイルを編集します。EnableMCPMReceive ディレクティブを使用して、MCPM リクエストをリッスンする仮想ホストに以下の更新を加えてください。

    1. サーバーアドバタイズメントを無効にするディレクティブを追加します。

      ServerAdvertise ディレクティブを Off に設定し、サーバーのアドバタイズを無効にします。

      ServerAdvertise Off
    2. アドバタイズの頻度を無効にします。

      設定に AdvertiseFrequencyが指定されている場合は # 文字を使用してコメントアウトします。

      # AdvertiseFrequency 5
    3. MCPM メッセージの受信機能を有効にします。

      Web サーバーがワーカーノードから MCPM メッセージを受信できるようにするため、必ず EnableMCPMReceive ディレクティブが存在するようにしてください。

      EnableMCPMReceive
  2. modcluster サブシステムでアドバタイズを無効にします。

    以下の管理 CLI コマンドを使用してアドバタイズを無効にします。

    /profile=full-ha/subsystem=modcluster/proxy=default:write-attribute(name=advertise,value=false)
    重要

    必ず次のステップでプロキシーのリストを提供してください。プロキシーのリストが空であるとアドバタイズが無効になりません。

  3. JBoss EAP の modcluster サブシステムにプロキシーのリストを提供します。

    アドバタイズが無効になっていると modcluster サブシステムは自動的にプロキシーを検出できないため、プロキシーのリストを提供する必要があります。

    最初に、適切なソケットバインディンググループにアウトバウンドソケットバインディングを定義します。

    /socket-binding-group=full-ha-sockets/remote-destination-outbound-socket-binding=proxy1:add(host=10.33.144.3,port=6666)
    /socket-binding-group=full-ha-sockets/remote-destination-outbound-socket-binding=proxy2:add(host=10.33.144.1,port=6666)

    次に、プロキシーを mod_cluster 設定に追加します。

    /profile=full-ha/subsystem=modcluster/proxy=default:list-add(name=proxies,value=proxy1)
    /profile=full-ha/subsystem=modcluster/proxy=default:list-add(name=proxies,value=proxy2)

Apache HTTP Server のバランサーがその存在をワーカーノードにアドバタイズしなくなり、UDP マルチキャストが使用されないようになります。

24.4.5.3. mod_cluster ワーカーノードの設定

mod_cluster ワーカーノードは、JBoss EAP サーバーで構成されます。このサーバーは、スタンドアロンサーバーまたは管理対象ドメインのサーバーグループの一部になります。個別のプロセスが JBoss EAP 内で実行され、クラスターのワーカーノードをすべて管理します。これはマスターと呼ばれます。

管理対象ドメインのワーカーノードは、サーバーグループ全体で同じ設定を共有します。スタンドアロンサーバーとして実行しているワーカーノードは個別に設定されます。設定手順は同じです。

  • スタンドアロンサーバーは standalone-ha または standalone-full-ha プロファイルで起動する必要があります。
  • 管理対象ドメインのサーバーグループは ha または full-ha プロファイルを使用し、 ha-sockets または full-ha-sockets ソケットバインディンググループを使用する必要があります。JBoss EAP にはこれらの要件を満たし、クラスターが有効になっている other-server-group というサーバーグループが含まれます。
ワーカーノードの設定

この手順の管理 CLI コマンドは、full-ha プロファイルの管理対象ドメインを使用していることを前提としています。スタンドアロンサーバーを実行している場合は、コマンドの /profile=full-ha の部分を削除してください。

  1. ネットワークインターフェースの設定

    デフォルトでは、ネットワークインターフェースがすべて 127.0.0.1 に設定されます。スタンドアロンサーバーまたはサーバーグループ内の 1 つまたは複数のサーバーをホストする各物理ホストでは、インターフェースが他のサーバーが見つけることができるパブリック IP アドレスを使用するよう設定する必要があります。

    以下の管理 CLI コマンドを使用して、ご使用の環境に合うよう managementpublic、および unsecure インターフェースの外部 IP アドレスを変更します。コマンドの EXTERNAL_IP_ADDRESS をホストの実際の外部 IP アドレスに置き換えてください。

    /interface=management:write-attribute(name=inet-address,value="${jboss.bind.address.management:EXTERNAL_IP_ADDRESS}")
    /interface=public:write-attribute(name=inet-address,value="${jboss.bind.address.public:EXTERNAL_IP_ADDRESS}")
    /interface=unsecure:write-attribute(name=inet-address,value="${jboss.bind.address.unsecure:EXTERNAL_IP_ADDRESS}")

    サーバーをリロードします。

    reload
  2. ホスト名を設定します。

    管理対象ドメインに参加する各ホストに一意なホスト名を設定します。この名前はスレーブ全体で一意になる必要があり、スレーブがクラスターを識別するために使用されるため、使用する名前を覚えておくようにしてください。

    1. 適切な host.xml 設定ファイルを使用して JBoss EAP のスレーブホストを起動します。

      $ EAP_HOME/bin/domain.sh --host-config=host-slave.xml
    2. 以下の管理 CLI コマンドを使用して、一意なホスト名を設定します。この例では、slave1 が新しいホスト名として使用されます。

      /host=EXISTING_HOST_NAME:write-attribute(name=name,value=slave1)

      ホスト名の設定に関する詳細は、「ホスト名の設定」を参照してください。

  3. ドメインコントローラーに接続する各ホストを設定します。

    注記

    このステップはスタンドアロンサーバーには適用されません。

    新たに設定されたホストが管理対象ドメインに参加する必要がある場合、ローカル要素を削除し、ドメインコントローラーを示すリモート要素ホスト属性を追加する必要があります。

    1. 適切な host.xml 設定ファイルを使用して JBoss EAP のスレーブホストを起動します。

      $ EAP_HOME/bin/domain.sh --host-config=host-slave.xml
    2. 以下の管理 CLI コマンドを使用して、ドメインコントローラーを設定します。

      /host=SLAVE_HOST_NAME:write-remote-domain-controller(host=DOMAIN_CONTROLLER_IP_ADDRESS,port=${jboss.domain.master.port:9990},security-realm="ManagementRealm")

      これにより、host-slave.xml ファイルの XML が次のように変更されます。

      <domain-controller>
          <remote host="DOMAIN_CONTROLLER_IP_ADDRESS" port="${jboss.domain.master.port:9990}" security-realm="ManagementRealm"/>
      </domain-controller>

      詳細は、「ホストコントローラーの設定」を参照してください。

  4. 各スレーブホストの認証を設定します。

    各スレーブサーバーには、ドメインコントローラーまたはスタンドアロンマスターの ManagementRealm で作成されたユーザー名とパスワードが必要です。ドメインコントローラーまたはスタンドアロンマスターで、各ホストに対して EAP_HOME/bin/add-user.sh コマンドを実行します。スレーブのホスト名と一致するユーザー名で、各ホストの管理ユーザーを追加します。

    秘密の値が提供されるようにするため、必ず最後の質問 (Is this new user going to be used for one AS process to connect to another AS process?) に yes と返答してください。

    例: add-user.sh スクリプト出力 (抜粋)

    $ EAP_HOME/bin/add-user.sh
    
    What type of user do you wish to add?
     a) Management User (mgmt-users.properties)
     b) Application User (application-users.properties)
    (a): a
    
    Username : slave1
    Password : changeme
    Re-enter Password : changeme
    What groups do you want this user to belong to? (Please enter a comma separated list, or leave blank for none)[  ]:
    About to add user 'slave1' for realm 'ManagementRealm'
    Is this correct yes/no? yes
    Is this new user going to be used for one AS process to connect to another AS process?
    e.g. for a slave host controller connecting to the master or for a Remoting connection for server to server EJB calls.
    yes/no? yes
    To represent the user add the following to the server-identities definition <secret value="SECRET_VALUE" />

    ここで出力された Base64 でエンコードされた秘密の値 SECRET_VALUE をコピーします。 この値は次のステップで使用することがあります。

    詳細は、JBoss EAP『How To Configure Server Security』の「Adding a User to the Master Domain Controller」を参照してください。

  5. 新しい認証を使用するようスレーブホストのセキュリティーレルムを変更します。

    サーバー設定に秘密の値を指定する方法、認証情報ストアまたは vault からパスワードを取得する方法、またはパスワードをシステムプロパティーとして渡す方法のいずれかでパスワードを指定できます。

    • 管理 CLI を使用して、サーバー設定ファイルに Base64 でエンコードされたパスワード値を指定します。

      以下の管理 CLI コマンドを使用して秘密の値を指定します。必ず SECRET_VALUE を前のステップの add-user 出力から返された秘密の値に置き換えてください。

      /host=SLAVE_HOST_NAME/core-service=management/security-realm=ManagementRealm/server-identity=secret:add(value="SECRET_VALUE")

      サーバーをリロードする必要があります。--host 引数はスタンドアロンサーバーには適用されません。

      reload --host=HOST_NAME

      詳細は、JBoss EAP『How To Configure Server Security』の「Configuring the Slave Controllers to Use the Credential」を参照してください。

    • ホストを設定し、認証情報ストアからパスワードを取得します。

      秘密の値を認証情報ストアに保存した場合、以下のコマンドを使用してサーバーの秘密の値が認証情報ストアからの値になるよう設定できます。

      /host=SLAVE_HOST_NAME/core-service=management/security-realm=ManagementRealm/server-identity=secret:add(credential-reference={store=STORE_NAME,alias=ALIAS}

      サーバーをリロードする必要があります。--host 引数はスタンドアロンサーバーには適用されません。

      reload --host=HOST_NAME

      詳細は、JBoss EAP『How To Configure Server Security』の「 Credential Store」を参照してください。

    • ホストを設定し、vault からパスワードを取得します。

      1. EAP_HOME/bin/vault.sh スクリプトを使用してマスクされたパスワードを生成します。以下のような VAULT::secret::password::VAULT_SECRET_VALUE 形式の文字列が生成されます。

        VAULT::secret::password::ODVmYmJjNGMtZDU2ZC00YmNlLWE4ODMtZjQ1NWNmNDU4ZDc1TElORV9CUkVBS3ZhdWx0.
        注記

        vault でパスワードを作成する場合、Base64 エンコードではなくプレーンテキストで指定する必要があります。

      2. 以下の管理 CLI コマンドを使用して秘密の値を指定します。必ず VAULT_SECRET_VALUE を前のステップで生成したマスクされたパスワードに置き換えてください。

        /host=master/core-service=management/security-realm=ManagementRealm/server-identity=secret:add(value="${VAULT::secret::password::VAULT_SECRET_VALUE}")

        サーバーをリロードする必要があります。--host 引数はスタンドアロンサーバーには適用されません。

        reload --host=HOST_NAME

        詳細は、JBoss EAP 『How To Configure Server Security』の「Password Vault」を参照してください。

    • システムプロパティーとしてパスワードを指定します。

      次の例は、server.identity.password をパスワードのシステムプロパティー名として使用します。

      1. サーバー設定ファイルでパスワードのシステムプロパティーを指定します。

        以下の管理 CLI コマンドを使用して、システムプロパティーを使用する秘密のアイデンティティーを設定します。

        /host=SLAVE_HOST_NAME/core-service=management/security-realm=ManagementRealm/server-identity=secret:add(value="${server.identity.password}")

        サーバーをリロードする必要があります。--host 引数はスタンドアロンサーバーには適用されません。

        reload --host=master
      2. サーバーの起動時にシステムプロパティーのパスワードを設定します。

        server.identity.password システムプロパティーを設定するには、このプロパティーをコマンドライン引数として渡すか、プロパティーファイルで渡します。

        1. プレーンテキストのコマンドライン引数として渡します。

          サーバーを起動し、server.identity.password プロパティーを渡します。

          $ EAP_HOME/bin/domain.sh --host-config=host-slave.xml -Dserver.identity.password=changeme
          警告

          パスワードはプレーンテキストで入力する必要があります。 ps -ef コマンドを実行すると、このパスワードを確認できます。

        2. プロパティーファイルでプロパティーを設定します。

          プロパティーファイルを作成し、キーバリューペアをプロパティーファイルに追加します。 例を以下に示します。

          server.identity.password=changeme
          警告

          パスワードはプレーンテキストで、このプロパティーファイルにアクセスできるユーザーはパスワードを確認できます。

          コマンドライン引数を使用してサーバーを起動します。

          $ EAP_HOME/bin/domain.sh --host-config=host-slave.xml --properties=PATH_TO_PROPERTIES_FILE
  6. サーバーを再起動します。

    ホスト名をユーザー名として使用し、暗号化された文字列をパスワードとして使用してスレーブがマスターに対して認証されます。

スタンドアロンサーバーまたは管理対象ドメインのサーバーグループ内のサーバーが mod_cluster ワーカーノードとして設定されます。クラスター化されたアプリケーションをデプロイする場合、セッションはフェイルオーバーのためにすべてのクラスターサーバーに複製され、外部 Web サーバーまたはロードバランサーからのリクエストを許可できます。クラスターの各ノードは、デフォルトで自動検出を使用して他のノードを検出します。

24.4.5.4. mod_cluster の fail_on_status パラメーターの設定

fail_on_status パラメーターは、クラスターのワーカーノードによって返されるとそのノードの失敗を意味する HTTP ステータスコードをリストします。ロードバランサーはその後のリクエストをクラスターの別のワーカーノードに送信します。失敗したワーカーノードは、ロードバランサーに STATUS メッセージを送信するまで NOTOK の状態になります。

fail_on_status パラメーターはロードバランサーの httpd設定ファイルに設定する必要があります。fail_on_status の HTTP ステータスコードが複数ある場合はカンマで区切って指定します。以下の例は、HTTP ステータスコード 203 および 204fail_on_status に指定します。

例: fail_on_status の設定

ProxyPass / balancer://MyBalancer stickysession=JSESSIONID|jsessionid nofailover=on failonstatus=203,204
ProxyPassReverse / balancer://MyBalancer
ProxyPreserveHost on

24.4.5.5. クラスター間のトラフィックの移行

JBoss EAP を使用して新しいクラスターを作成した後、アップグレードプロセスの一部として以前のクラスターから新しいクラスターへトラフィックを移行できます。ここでは、停止時間やダウンライムを最小限に抑えてトラフィックを移行する方法について説明します。

  • 新しいクラスターの設定。このクラスターを ClusterNEW と呼びます。
  • 不要となった古いクラスターの設定。このクラスターを ClusterOLD と呼びます。
クラスターのアップグレードプロセス - ロードバランシンググループ
  1. 前提条件に従って、新しいクラスターを設定します。
  2. ClusterNEW および ClusterOLD の両方で、設定オプション sticky-session をデフォルト設定の true に設定してください。このオプションを有効にすると、クラスターのクラスターノードへの新しいリクエストはすべてそのクラスターノードに送信されます。

    /profile=full-ha/subsystem=modcluster/proxy=default:write-attribute(name=sticky-session,value=true)
  3. ClusterOLD のすべてのクラスターノードは ClusterOLD ロードバランシンググループのメンバーであることを仮定し、load-balancing-groupClusterOLD に設定します。

    /profile=full-ha/subsystem=modcluster/proxy=default:write-attribute(name=load-balancing-group,value=ClusterOLD)
  4. mod_cluster ワーカーノードの設定」の手順に従って ClusterNEW のノードを個別に mod_cluster 設定に追加します。また、この手順を使用してロードバランシンググループを ClusterNEW に設定します。

    この時点で、以下の簡易例に似た出力が mod_cluster-manager コンソールに表示されます。

                    mod_cluster/<version>
    
        LBGroup ClusterOLD: [Enable Nodes]   [Disable Nodes]   [Stop Nodes]
            Node node-1-jvmroute (ajp://node1.oldcluster.example:8009):
                [Enable Contexts]   [Disable Contexts]   [Stop Contexts]
                Balancer: qacluster, LBGroup: ClusterOLD, Flushpackets: Off, ..., Load: 100
                Virtual Host 1:
                    Contexts:
                        /my-deployed-application-context, Status: ENABLED Request: 0 [Disable]   [Stop]
    
            Node node-2-jvmroute (ajp://node2.oldcluster.example:8009):
                [Enable Contexts]   [Disable Contexts]   [Stop Contexts]
                Balancer: qacluster, LBGroup: ClusterOLD, Flushpackets: Off, ..., Load: 100
                Virtual Host 1:
                    Contexts:
                        /my-deployed-application-context, Status: ENABLED Request: 0 [Disable]   [Stop]
    
    
        LBGroup ClusterNEW: [Enable Nodes]   [Disable Nodes]   [Stop Nodes]
            Node node-3-jvmroute (ajp://node3.newcluster.example:8009):
                [Enable Contexts]   [Disable Contexts]   [Stop Contexts]
                Balancer: qacluster, LBGroup: ClusterNEW, Flushpackets: Off, ..., Load: 100
                Virtual Host 1:
                    Contexts:
                        /my-deployed-application-context, Status: ENABLED Request: 0 [Disable]   [Stop]
    
            Node node-4-jvmroute (ajp://node4.newcluster.example:8009):
                [Enable Contexts]   [Disable Contexts]   [Stop Contexts]
                Balancer: qacluster, LBGroup: ClusterNEW, Flushpackets: Off, ..., Load: 100
                Virtual Host 1:
                    Contexts:
                        /my-deployed-application-context, Status: ENABLED Request: 0 [Disable]   [Stop]
  5. ClusterOLD グループ内に古いアクティブなセッションがあり、新しいセッションは ClusterOLD または CLusterNEW グループ内に作成されます。次に、現在アクティブなクライアントのセッションにエラーが発生しないようにクラスターノードを停止するため、ClusterOLD グループ全体を無効にします。

    mod_cluster-manager Web コンソールで LBGroup ClusterOLDDisable Nodes リンクをクリックします。

    この後、すでに確立されたセッションに属するリクエストのみが ClusterOLD ロードバランシンググループのメンバーにルーティングされます。新しいクライアントのセッションは ClusterNEW グループのみに作成されます。ClusterOLD グループ内にアクティブなセッションがなくなったら、そのメンバーを安全に削除できます。

    注記

    Stop Nodes を使用すると、即座にこのドメインへのリクエストのルーティングを停止するようロードバランサーが指示されます。これにより、別のロードバランシンググループへのフェイルオーバーが強制され、ClusterNEWClusterOLD の間にセッションレプリケーションがない場合はクライアントへのセッションデータが損失する原因となります。

デフォルトのロードバランシンググループ

mod_cluster-manager コンソールの LBGroup を確認して、現在の ClusterOLD 設定にロードバランシンググループの設定が含まれていない場合でも、ClusterOLD ノードの無効化を利用できます。この場合、各 ClusterOLD ノードの Disable Contexts をクリックします。これらのノードのコンテンツは無効化され、アクティブなセッションがなくなったら削除することができます。新しいクライアントのセッションは、有効なコンテンツを持つノードのみに作成されます (この例では ClusterOLD メンバー)。

管理 CLI の使用

mod_cluster-manager web コンソールを使用する他に、JBoss EAP 管理 CLI を使用して特定のコンテキストを停止または無効化することもできます。

コンテキストの停止

/host=master/server=server-one/subsystem=modcluster:stop-context(context=/my-deployed-application-context, virtualhost=default-host, waittime=0)

waittime0 に設定してタイムアウトがない状態でコンテキストを停止すると、すべてのリクエストのルーティングを即座に停止するようバランサーに指示を出し、利用できる他のコンテキストへのフェイルオーバーを強制します。

waittime 引数を使用してタイムアウト値を設定すると、このコンテキストでは新しいセッションは作成されませんが、既存のセッションが完了するか、指定のタイムアウト値を経過するまで、既存のセッションはこのノードに引き続き転送されます。waittime 引数のデフォルト値は 10 秒です。

コンテキストの無効化

/host=master/server=server-one/subsystem=modcluster:disable-context(context=/my-deployed-application-context, virtualhost=default-host)

コンテキストを無効にすると、バランサーがこのコンテキストで新しいセッションを作成しないよう指示します。

24.4.6. Apache mod_jk HTTP コネクター

Apache mod_jk は、互換性の維持を目的に提供される HTTP コネクターです。

JBoss EAP は Apache HTTP プロキシーサーバーからのワークロードを許可します。プロキシーサーバーは Web フロントエンドからのクライアントリクエストを許可し、ワークを参加する JBoss EAP サーバーへ渡します。スティッキーセッションが有効な場合、同じクライアントリクエストは常に同じ JBoss EAP サーバーに送信されます (同じサーバーが使用できない場合を除く)。

mod_jk は AJP 1.3 プロトコルを介して通信します。mod_cluster または mod_proxy には他のプロトコルを使用できます。詳細は「HTTP コネクターの概要」を参照してください。

注記

mod_cluster は mod_jk よりも高度なロードバランサーで、推奨される HTTP コネクターです。mod_cluster は mod_jk のすべての機能と、それ以外の追加機能を提供します。JBoss EAP の mod_cluster HTTP コネクターとは違い、Apache mod_jk HTTP コネクターはサーバーまたはサーバーグループのデプロイメントの状態を認識せず、ワークの送信先に順応できません。

詳細は、Apache mod_jk ドキュメントを参照してください。

24.4.6.1. Apache HTTP Server での mod_jk の設定

JBoss Core Services Apache HTTP Server のインストール時または JBoss Web Server の使用時に mod_jk モジュールである mod_jk.so はすでに含まれていますが、デフォルトではロードされません。

注記

JBoss Web Server バージョン 3.1.0 より、Apache HTTP Server は配布されないようになりました。

以下の手順に従って、Apache HTTP Server の mod_jk をロードおよび設定します。この手順では、Apache HTTP Server の httpd/ ディレクトリーがカレントディレクトリーであることを前提としていますが、このディレクトリーはプラットフォームによって異なります。ご使用のプラットフォームに対応するインストール手順は、JBoss Core Services の『Apache HTTP Server Installation Guide』を参照してください。

注記

Red Hat のお客様は Red Hat カスタマーポータルにある Load Balancer Configuration Tool を使用して mod_jk やその他のコネクターに最適な設定テンプレートを迅速に生成することもできます。このツールを使用するにはログインする必要があります。

  1. mod_jk モジュールを設定します。

    注記

    mod_jk 設定ファイルの例は conf.d/mod_jk.conf.sampleにあります。独自のファイルを作成せずにこのファイルを使用するには、.sample 拡張子を削除し、必要に応じて内容を変更します。

    conf.d/mod_jk.conf という新しいファイルを作成します。以下の設定をファイルに追加し、必要に応じて内容を変更します。

    # Load mod_jk module
    # Specify the filename of the mod_jk lib
    LoadModule jk_module modules/mod_jk.so
    
    # Where to find workers.properties
    JkWorkersFile conf.d/workers.properties
    
    # Where to put jk logs
    JkLogFile logs/mod_jk.log
    
    # Set the jk log level [debug/error/info]
    JkLogLevel info
    
    # Select the log format
    JkLogStampFormat  "[%a %b %d %H:%M:%S %Y]"
    
    # JkOptions indicates to send SSK KEY SIZE
    JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories
    
    # JkRequestLogFormat
    JkRequestLogFormat "%w %V %T"
    
    # Mount your applications
    JkMount /application/* loadbalancer
    
    # Add shared memory.
    # This directive is present with 1.2.10 and
    # later versions of mod_jk, and is needed for
    # for load balancing to work properly
    JkShmFile logs/jk.shm
    
    # Add jkstatus for managing runtime data
    <Location /jkstatus/>
        JkMount status
        Require ip 127.0.0.1
    </Location>
    注記

    JkMount ディレクティブは、Apache HTTP Server が mod_jk モジュールに転送する必要がある URL を指定します。ディレクティブの設定に基づき、mod_jk は受信した URL を適切なワーカーに送信します。直接静的コンテンツに対応し、Java アプリケーションのロードバランサーのみを使用するには、URL パスは /application/* である必要があります。mod_jk をロードバランサーとして使用するには、値 /* を使用してすべての URL を mod_jk に転送します。

    一般的な mod_jk の設定の他に、このファイルは mod_jk.so モジュールをロードするよう指定し、workers.properties ファイルの場所を定義します。

  2. mod_jk ワーカーノードを設定します。

    注記

    ワーカー設定ファイルの例は conf.d/workers.properties.sample にあります。独自のファイルを作成せずにこのファイルを使用するには、.sample 拡張子を削除し、必要に応じて内容を変更します。

    conf.d/workers.properties という新しいファイルを作成します。以下の設定をファイルに追加し、必要に応じて内容を変更します。

    # Define list of workers that will be used
    # for mapping requests
    worker.list=loadbalancer,status
    
    # Define Node1
    # modify the host as your host IP or DNS name.
    worker.node1.port=8009
    worker.node1.host=node1.mydomain.com
    worker.node1.type=ajp13
    worker.node1.ping_mode=A
    worker.node1.lbfactor=1
    
    # Define Node2
    # modify the host as your host IP or DNS name.
    worker.node2.port=8009
    worker.node2.host=node2.mydomain.com
    worker.node2.type=ajp13
    worker.node2.ping_mode=A
    worker.node2.lbfactor=1
    
    # Load-balancing behavior
    worker.loadbalancer.type=lb
    worker.loadbalancer.balance_workers=node1,node2
    worker.loadbalancer.sticky_session=1
    
    # Status worker for managing load balancer
    worker.status.type=status

    mod_jk workers.properties ファイルの構文の詳細およびその他の高度な設定オプションの詳細は、「mod_jk ワーカープロパティー」を参照してください。

  3. 任意で JKMountFile ディレクティブを指定します。

    mod-jk.conf の JKMount ディレクティブの他に、mod_jk に転送される複数の URL パターンが含まれるファイルを指定できます。

    1. uriworkermap.properties ファイルを作成します。

      注記

      URI ワーカーマップ設定ファイルの例は conf.d/uriworkermap.properties.sample にあります。独自のファイルを作成せずにこのファイルを使用するには、.sample 拡張子を削除し、必要に応じて内容を変更します。

      conf.d/uriworkermap.properties という新しいファイルを作成します。以下の例のように、一致する各 URL パターンの行を追加します。

      # Simple worker configuration file
      /*=loadbalancer
    2. uriworkermap.properties ファイルを示すよう、設定を更新します。

      conf.d/mod_jk.conf の最後に以下を追加します。

      # Use external file for mount points.
      # It will be checked for updates each 60 seconds.
      # The format of the file is: /url=worker
      # /examples/*=loadbalancer
      JkMountFile conf.d/uriworkermap.properties

mod_jk の設定に関する詳細は、 JBoss Web Server『HTTP Connectors and Load Balancing Guide』の「Configuring Apache HTTP Server to Load mod_jk」を参照してください。

24.4.6.2. JBoss EAP が mod_jk と通信するよう設定

JBoss EAP の undertow サブシステムは、外部 Web サーバーからのリクエストを許可し、外部 Web サーバーへ返答を返送するために、リスナーを指定する必要があります。mod_jk は AJP プロトコルを使用するため、AJP リスナーを設定する必要があります。

デフォルトの高可用性設定の 1 つ (ha または full-ha) を使用している場合は、AJP リスナーはすでに設定されています。

手順は「外部 Web サーバーからのリクエストの許可」を参照してください。

24.4.7. Apache mod_proxy HTTP コネクター

Apache mod_proxy は、AJP、HTTP、および HTTPS プロトコルを介して接続をサポートする HTTP コネクターです。 mod_proxy は負荷分散された設定と負荷分散されていない設定が可能で、スティッキーセッションをサポートします。

mod_proxy モジュールを使用するには、使用するプロトコルに応じて JBoss EAP の undertow サブシステムに HTTP、HTTPS または AJP リスナーを設定する必要があります。

注記

mod_cluster は mod_proxy よりも高度なロードバランサーで、推奨される HTTP コネクターです。mod_cluster は mod_proxy のすべての機能と、それ以外の追加機能を提供します。JBoss EAP の mod_cluster HTTP コネクターとは違い、Apache mod_proxy HTTP コネクターはサーバーまたはサーバーグループのデプロイメントの状態を認識せず、ワークの送信先に順応できません。

詳細は Apache mod_proxy ドキュメント を参照してください。

24.4.7.1. Apache HTTP Server での mod_proxy の設定

JBoss Core Services Apache HTTP Server をインストールする場合や JBoss Web Server を使用する場合、mod_proxy モジュールはすでに含まれており、デフォルトでロードされます。

注記

JBoss Web Server バージョン 3.1.0 より、Apache HTTP Server は配布されないようになりました。

基本の ロードバランシング または 非ロードバランシング プロキシーを設定するには、以下のセクションを参照してください。この手順では、Apache HTTP Server の httpd/ ディレクトリーがカレントディレクトリーであることを前提としていますが、このディレクトリーはプラットフォームによって異なります。ご使用のプラットフォームに対応するインストール手順は、JBoss Core Services の『Apache HTTP Server Installation Guide』を参照してください。また、この手順は JBoss EAP の undertow サブシステムに必要な HTTP リスナーが設定されていることを前提としています。

注記

Red Hat のお客様は Red Hat カスタマーポータルにある Load Balancer Configuration Tool を使用して mod_proxy やその他のコネクターに最適な設定テンプレートを迅速に生成することもできます。このツールを使用するにはログインする必要があります。

非ロードバランシングプロキシーの追加

以下の設定を、他の <VirtualHost> ディレクティブの直下にある conf/httpd.conf ファイルに追加します。値を設定に適切な値に置き換えます。

<VirtualHost *:80>
# Your domain name
ServerName YOUR_DOMAIN_NAME

ProxyPreserveHost On

# The IP and port of JBoss
# These represent the default values, if your httpd is on the same host
# as your JBoss managed domain or server

ProxyPass / http://localhost:8080/
ProxyPassReverse / http://localhost:8080/

# The location of the HTML files, and access control information
DocumentRoot /var/www
<Directory /var/www>
Options -Indexes
Order allow,deny
Allow from all
</Directory>
</VirtualHost>
ロードバランシングプロキシーの追加
注記

デフォルトの Apache HTTP Server は mod_cluster との互換性がないため、mod_proxy_balancer.so モジュールが無効になっています。この作業を行うには、このモジュールをロードし、mod_cluster を無効にする必要があります。

mod_proxy をロードバランサーとして使用し、ワークを複数の JBoss EAP インスタンスに送信するには、以下の設定を conf/httpd.conf ファイルに追加する必要があります。IP アドレスの例は以下のようになります。ご使用の環境に適切な値に置き換えてください。

<Proxy balancer://mycluster>

Order deny,allow
Allow from all

# Add each JBoss Enterprise Application Server by IP address and port.
# If the route values are unique like this, one node will not fail over to the other.
BalancerMember http://192.168.1.1:8080 route=node1
BalancerMember http://192.168.1.2:8180 route=node2
</Proxy>

<VirtualHost *:80>
 # Your domain name
 ServerName YOUR_DOMAIN_NAME

 ProxyPreserveHost On
 ProxyPass / balancer://mycluster/

 # The location of the HTML files, and access control information DocumentRoot /var/www
 <Directory /var/www>
  Options -Indexes
  Order allow,deny
  Allow from all
 </Directory>

</VirtualHost>

上記の例はすべて HTTP プロトコルを使用して通信します。適切な mod_proxy モジュールをロードすれば AJP または HTTPS プロトコルを使用することもできます。詳細は Apache mod_proxy ドキュメントを参照してください。

スティッキーセッションの有効化

スティッキーセッション を使用すると、クライアントリクエストが特定の JBoss EAP ワーカーに送信された場合に、ワーカーが利用不可能にならない限り、後続のリクエストがすべて同じワーカーに送信されます。これは、ほとんどの場合で推奨される動作です。

mod_proxy のスティッキーセッションを有効にするには、stickysessionパラメーターを ProxyPass ステートメントに追加します。

ProxyPass / balancer://mycluster stickysession=JSESSIONID

追加のパラメーターを lbmethodnofailover などの ProxyPass ステートメントに指定できます。使用可能なパラメーターの詳細は、Apache mod_proxy ドキュメントを参照してください。

24.4.7.2. JBoss EAP が mod_proxy と通信するよう設定

JBoss EAP の undertow サブシステムは、外部 Web サーバーからのリクエストを許可し、外部 Web サーバーへ返答を返送するために、リスナーを指定する必要があります。使用するプロトコルによっては、リスナーを設定する必要があることがあります。

HTTP リスナーは JBoss EAP のデフォルト設定に設定されます。デフォルトの高可用性設定である ha または full-ha のいずれかを使用している場合は、AJP リスナーも事前設定されています。

手順は「外部 Web サーバーからのリクエストの許可」を参照してください。

24.4.8. Microsoft ISAPI コネクター

Internet Server API (ISAPI) は、Microsoft のインターネット情報サービス(IIS)などの Web サーバー用の Digital Server 拡張やフィルターを書き込むために使用される API のセットです。ISAPI_redirect.dll は IIS 向けに調整された mod_jk の拡張機能です。ISAPI_redirect.dll を使用すると、JBoss EAP インスタンスをワーカーノードとしてロードバランサーとして設定できます。

注記

Windows Server および IIS のサポートされる構成については、「JBoss Enterprise Application Platform (EAP) 7 でサポートされる構成」を参照してください。

24.4.8.1. Microsoft IIS が ISAPI コネクターを使用するよう設定

Red Hat カスタマーポータルから ISAPI コネクターをダウンロードします。

  1. ブラウザーを開き、Red Hat カスタマーポータルで JBoss の Software Downloads ページにログインします。
  2. Product ドロップダウンメニューから Web Connectors を選択します。
  3. Version ドロップダウンメニューで最新バージョンの JBoss Core Services を選択します。
  4. リストで Red Hat JBoss Core Services ISAPI Connector を見つけ、Download リンクをクリックします。
  5. アーカイブを抽出し、sbin ディレクトリーの内容をサーバーの場所にコピーします。以下の手順は、内容が C:\connectors\ にコピーされたことを前提としています。

IIS マネージャー (IIS 7) を使用して IIS リディレクターを設定するには、以下を行います。

  1. StartRunとクリックして IIS マネージャーを開き、inetmgr と入力します。
  2. 左側のツリービューペインで IIS 7 を展開します。
  3. ISAPI and CGI Registrations をダブルクリックし、新しいウインドウで開きます。
  4. Actions ペインで Add をクリックします。Add ISAPI or CGI Restriction ウインドウが開きます。
  5. 以下の値を指定します。

    • ISAPI or CGI Path: C:\connectors\isapi_redirect.dll
    • Description: jboss
    • Allow extension path to execute: チェックボックスを選択します。
  6. OK をクリックして Add ISAPI or CGI Restriction ウインドウを閉じます。
  7. JBoss ネイティブ仮想ディレクトリーの定義

    • Default Web Site を右クリックし、Add Virtual Directory をクリックします。Add Virtual Directory ウインドウが開きます。
    • 以下の値を指定して仮想ディレクトリーを追加します。

      • Alias: jboss
      • Physical Path: C:\connectors\
    • OK をクリックして値を保存し、Add Virtual Directory ウインドウを閉じます。
  8. JBoss ネイティブ ISAPI リダイレクトフィルターの定義

    • ツリービューペインで SitesDefault Web Site と展開します。
    • ISAPI Filters をダブルクリックします。ISAPI Filters Features ビューが表示されます。
    • Actions ペインで Add をクリックします。Add ISAPI Filter ウインドウが表示されます。
    • 以下の値を Add ISAPI Filter ウインドウに指定します。

      • Filter name: jboss
      • Executable: C:\connectors\isapi_redirect.dll
    • OK をクリックして値を保存し、Add ISAPI Filter ウインドウを閉じます。
  9. ISAPI-dll ハンドラーの有効化

    • ツリービューペインの IIS 7 をダブルクリックします。IIS 7 Home Features View が開きます。
    • Handler Mappings をダブルクリックします。Handler Mappings Features View が表示されます。
    • Group by コンボボックスで State を選択します。Handler MappingsEnabled and Disabled Groups に表示されます。
    • ISAPI-dll を見つけます。Disabled グループにある場合は右クリックし、Edit Feature Permissions を選択します。
    • 以下のパーミッションを有効にします。

      • Read
      • Script
      • Execute
    • OK をクリックして値を保存し、Edit Feature Permissions ウインドウを閉じます。

これで、ISAPI コネクターを使用するよう Microsoft IIS が設定されます。

24.4.8.2. ISAPI コネクターがクライアントリクエストを JBoss EAP に送信するよう設定

このタスクでは、JBoss EAP サーバーのグループが ISAPI コネクターからのリクエストを受け入れるよう設定します。ロードバランシングまたは高可用性フェイルオーバーの設定は含まれません。

この設定は IIS サーバーで行われ、外部 Web サーバーからのリクエストを許可するよう JBoss EAP が設定されていることを前提としています。また、IIS への完全な管理者アクセスが必要で、IIS が ISAPI コネクターを使用するよう設定されている必要があります。

プロパティーファイルの作成およびリダイレクトの設定
  1. ログ、プロパティーファイル、およびロックファイルを格納するディレクトリーを作成します。

    以下の手順では、ディレクトリー C:\connectors\ の使用を前提としています。異なるディレクトリーを使用する場合は、適切に手順を変更してください。

  2. isapi_redirect.properties ファイルを作成します。

    C:\connectors\isapi_redirect.properties という新しいファイルを作成します。このファイルに次の内容をコピーします。

    # Configuration file for the ISAPI Connector
    # Extension uri definition
    extension_uri=/jboss/isapi_redirect.dll
    
    # Full path to the log file for the ISAPI Connector
    log_file=c:\connectors\isapi_redirect.log
    
    # Log level (debug, info, warn, error or trace)
    log_level=info
    
    # Full path to the workers.properties file
    worker_file=c:\connectors\workers.properties
    
    # Full path to the uriworkermap.properties file
    worker_mount_file=c:\connectors\uriworkermap.properties
    
    #Full path to the rewrite.properties file
    rewrite_rule_file=c:\connectors\rewrite.properties

    rewrite.properties ファイルを使用しない場合は、行の先頭に # 文字を記入して最後の行をコメントアウトします。

  3. uriworkermap.properties ファイルの作成

    uriworkermap.properties ファイルには、デプロイされたアプリケーション URL と、それらへの要求を処理するワーカー間のマッピングが含まれます。以下のサンプルファイルはファイルの構文を示しています。uriworkermap.properties ファイルを C:\connectors\ に格納します。

    # images and css files for path /status are provided by worker01
    /status=worker01
    /images/*=worker01
    /css/*=worker01
    
    # Path /web-console is provided by worker02
    # IIS (customized) error page is used for http errors with number greater or equal to 400
    # css files are provided by worker01
    /web-console/*=worker02;use_server_errors=400
    /web-console/css/*=worker01
    
    # Example of exclusion from mapping, logo.gif won't be displayed
    # !/web-console/images/logo.gif=*
    
    # Requests to /app-01 or /app-01/something will be routed to worker01
    /app-01|/*=worker01
    
    # Requests to /app-02 or /app-02/something will be routed to worker02
    /app-02|/*=worker02
  4. workers.properties ファイルを作成します。

    workers.properties ファイルには、ワーカーラベルとサーバーインスタンス間のマッピング定義が含まれます。このファイルは、 Apache mod_jk ワーカープロパティー 設定で使用される同じファイルの構文を使用します。

    以下は workers.properties ファイルの例になります。ワーカー名、worker01、および worker02 は、JBoss EAP の undertow サブシステムで設定された instance-id に一致する必要があります。

    このファイルを C:\connectors\ ディレクトリーに格納してください。

    # An entry that lists all the workers defined
    worker.list=worker01, worker02
    
    # Entries that define the host and port associated with these workers
    
    # First JBoss EAP server definition, port 8009 is standard port for AJP in EAP
    worker.worker01.host=127.0.0.1
    worker.worker01.port=8009
    worker.worker01.type=ajp13
    
    # Second JBoss EAP server definition
    worker.worker02.host=127.0.0.100
    worker.worker02.port=8009
    worker.worker02.type=ajp13
  5. rewrite.properties ファイルを作成します。

    rewrite.properties ファイルには、特定のアプリケーションの単純な URL 書き換えルールが含まれます。以下の例で示されているように、書き換えられたパスは名前と値のペアを使用して指定されます。このファイルを C:\connectors\ ディレクトリーに格納してください。

    #Simple example
    # Images are accessible under abc path
    /app-01/abc/=/app-01/images/
  6. net stop および net start コマンドを使用して IIS サーバーを再起動します。

    C:\> net stop was /Y
    C:\> net start w3svc

アプリケーションごとに、設定した特定の JBoss EAP サーバーにクライアントリクエストを送信するよう IIS サーバーが設定されます。

24.4.8.3. ISAPI コネクターがクライアントリクエストを複数の JBoss EAP サーバーで分散するよう設定

この設定は、指定する JBoss EAP サーバー全体でクライアントリクエストを分散します。この設定は IIS サーバーで行われ、外部 Web サーバーからのリクエストを許可するよう JBoss EAP が設定されていることを前提としています。また、IIS への完全な管理者アクセスが必要で、IIS が ISAPI コネクターを使用するよう設定されている必要があります。

複数のサーバー間でのクライアント要求の分散
  1. ログ、プロパティーファイル、およびロックファイルを格納するディレクトリーを作成します。

    以下の手順では、ディレクトリー C:\connectors\ の使用を前提としています。異なるディレクトリーを使用する場合は、適切に手順を変更してください。

  2. isapi_redirect.properties ファイルを作成します。

    C:\connectors\isapi_redirect.properties という新しいファイルを作成します。このファイルに次の内容をコピーします。

    # Configuration file for the ISAPI Connector
    # Extension uri definition
    extension_uri=/jboss/isapi_redirect.dll
    
    # Full path to the log file for the ISAPI Connector
    log_file=c:\connectors\isapi_redirect.log
    
    # Log level (debug, info, warn, error or trace)
    log_level=info
    
    # Full path to the workers.properties file
    worker_file=c:\connectors\workers.properties
    
    # Full path to the uriworkermap.properties file
    worker_mount_file=c:\connectors\uriworkermap.properties
    
    #OPTIONAL: Full path to the rewrite.properties file
    rewrite_rule_file=c:\connectors\rewrite.properties

    rewrite.properties ファイルを使用しない場合は、行の先頭に # 文字を記入して最後の行をコメントアウトします。

  3. uriworkermap.properties ファイルを作成します。

    uriworkermap.properties ファイルには、デプロイされたアプリケーション URL と、それらへの要求を処理するワーカー間のマッピングが含まれます。以下のサンプルファイルは負荷分散が設定されたファイルの構文を示しています。ワイルドカード (*) はさまざまな URL サブディレクトリーのすべてのリクエストを router という名前のロードバランサーに送信します。ロードバランサーの設定は次のステップで説明します。

    uriworkermap.properties ファイルを C:\connectors\ に格納します。

    # images, css files, path /status and /web-console will be
    # provided by nodes defined in the load-balancer called "router"
    /css/*=router
    /images/*=router
    /status=router
    /web-console|/*=router
    
    # Example of exclusion from mapping, logo.gif won't be displayed
    # !/web-console/images/logo.gif=*
    
    # Requests to /app-01 and /app-02 will be routed to nodes defined
    # in the load-balancer called "router"
    /app-01|/*=router
    /app-02|/*=router
    
    # mapping for management console, nodes in cluster can be enabled or disabled here
    /jkmanager|/*=status
  4. workers.properties ファイルを作成します。

    workers.properties ファイルには、ワーカーラベルとサーバーインスタンス間のマッピング定義が含まれます。このファイルは、 Apache mod_jk ワーカープロパティー 設定で使用される同じファイルの構文を使用します。

    以下は workers.properties ファイルの例になります。ロードバランサーはファイルの末尾付近に設定され、ワーカー worker01 および worker02 で構成されます。これらのワーカーは、JBoss EAP の undertow サブシステムで設定された instance-id に一致する必要があります。

    このファイルを C:\connectors\ ディレクトリーに格納してください。

    # The advanced router LB worker
    worker.list=router,status
    
    # First EAP server definition, port 8009 is standard port for AJP in EAP
    #
    # lbfactor defines how much the worker will be used.
    # The higher the number, the more requests are served
    # lbfactor is useful when one machine is more powerful
    # ping_mode=A – all possible probes will be used to determine that
    # connections are still working
    
    worker.worker01.port=8009
    worker.worker01.host=127.0.0.1
    worker.worker01.type=ajp13
    worker.worker01.ping_mode=A
    worker.worker01.socket_timeout=10
    worker.worker01.lbfactor=3
    
    # Second EAP server definition
    worker.worker02.port=8009
    worker.worker02.host=127.0.0.100
    worker.worker02.type=ajp13
    worker.worker02.ping_mode=A
    worker.worker02.socket_timeout=10
    worker.worker02.lbfactor=1
    
    # Define the LB worker
    worker.router.type=lb
    worker.router.balance_workers=worker01,worker02
    
    # Define the status worker for jkmanager
    worker.status.type=status

  5. rewrite.properties ファイルを作成します。

    rewrite.properties ファイルには、特定のアプリケーションの単純な URL 書き換えルールが含まれます。以下の例で示されているように、書き換えられたパスは名前と値のペアを使用して指定されます。このファイルを C:\connectors\ ディレクトリーに格納してください。

    #Simple example
    # Images are accessible under abc path
    /app-01/abc/=/app-01/images/
    Restart the IIS server.
    
    Restart your IIS server by using the net stop and net start commands.
    C:\> net stop was /Y
    C:\> net start w3svc

IIS サーバーは、workers.properties ファイルで参照された JBoss EAP サーバーにクライアントリクエストを送信し、サーバー間で負荷を 1:3 の比率で分散するよう設定されます。この比率は、各サーバーに割り当てられた負荷分散係数 lbfactor から派生します。

24.4.9. Oracle NSAPI コネクター

Netscape Server API (NSAPI) は、拡張機能をサーバーに実装するために Oracle iPlanet Web Server (旧名 Netscape Web Server) によって提供される API です。これらの拡張機能はサーバープラグインと呼ばれます。NSAPI コネクターは、Oracle iPlanet Web Server 向けに調整された mod_jk の拡張機能である nsapi_redirector.so で使用されます。NSAPI コネクターを使用すると、JBoss EAP インスタンスをワーカーノード、Oracle iPlanet Web Server をロードバランサーとして設定できます。

注記

Solaris および Oracle iPlanet Web Server のサポートされる構成については、「JBoss Enterprise Application Platform (EAP) 7 でサポートされる構成」を参照してください。

24.4.9.1. iPlanet Web Server が NSAPI コネクターを使用するよう設定

要件

  • ワーカーとして動作する各サーバーに JBoss EAP がインストールおよび設定されます。

Red Hat カスタマーポータルから NSAPI コネクターをダウンロードします。

  1. ブラウザーを開き、Red Hat カスタマーポータルで JBoss の Software Downloads ページにログインします。
  2. Product ドロップダウンメニューから Web Connectors を選択します。
  3. Version ドロップダウンメニューで最新バージョンの JBoss Core Services を選択します。
  4. システムのプラットフォームとアーキテクチャーに対応する Red Hat JBoss Core Services NSAPI Connector を見つけ、Download リンクをクリックします。
  5. lib/ または lib64/ ディレクトリーにある nsapi_redirector.so ファイルを、IPLANET_CONFIG/lib/ または IPLANET_CONFIG/lib64/ ディレクトリーに展開します。

NSAPI コネクターを設定します。

注記

これらの手順では、IPLANET_CONFIG は Oracle iPlanet の設定ディレクトリーを意味します (通常 /opt/oracle/webserver7/config/ になります)。Oracle iPlanet 設定ディレクトリーが異なる場合は、適切に手順を変更してください。

  1. サーブレットマッピングを無効にします。

    IPLANET_CONFIG/default.web.xml ファイルを開き、Built In Server Mappings という見出しのセクションを見つけます。次の 3 つのサーブレットを XML コメント文字 (<!-- および -->) で囲み、これらのサーブレットへのマッピングを無効にします。

    • default
    • invoker
    • jsp

      以下の設定例は、無効にされたマッピングを示しています。

      <!-- ============== Built In Servlet Mappings =============== -->
      <!-- The servlet mappings for the built in servlets defined above. -->
      <!-- The mapping for the default servlet -->
      <!--servlet-mapping>
       <servlet-name>default</servlet-name>
       <url-pattern>/</url-pattern>
      </servlet-mapping-->
      <!-- The mapping for the invoker servlet -->
      <!--servlet-mapping>
       <servlet-name>invoker</servlet-name>
       <url-pattern>/servlet/*</url-pattern>
      </servlet-mapping-->
      <!-- The mapping for the JSP servlet -->
      <!--servlet-mapping>
       <servlet-name>jsp</servlet-name>
       <url-pattern>*.jsp</url-pattern>
      </servlet-mapping-->

      ファイルを保存し、終了します。

  2. iPlanet Web Server が NSAPI コネクターモジュールをロードするよう設定します。

    IPLANET_CONFIG/magnus.conf ファイルの最後に次の行を追加し、設定に合わせてファイルパスを変更します。これらの行は、nsapi_redirector.so モジュールと、ワーカーおよびそのプロパティーがリストされた workers.properties ファイルの場所を定義します。

    Init fn="load-modules" funcs="jk_init,jk_service" shlib="/lib/nsapi_redirector.so" shlib_flags="(global|now)"
    
    Init fn="jk_init" worker_file="IPLANET_CONFIG/connectors/workers.properties" log_level="info" log_file="IPLANET_CONFIG/connectors/nsapi.log" shm_file="IPLANET_CONFIG/connectors/tmp/jk_shm"

    上記の設定は 32 ビットアーキテクチャー向けです。64 ビット Solaris を使用している場合は、文字列 lib/nsapi_redirector.solib64/nsapi_redirector.so に変更します。

    ファイルを保存し、終了します。

  3. NSAPI コネクターを設定します。

    負荷分散のない基本設定または負荷分散設定向けに NSAPI コネクターを設定できます。以下のいずれかのオプションを選択します。 その後、設定が完了します。

24.4.9.2. NSAPI コネクターがクライアントリクエストを JBoss EAP に送信するよう設定

このタスクでは、NSAPI コネクターが負荷分散またはフェイルオーバーなしでクライアントリクエストを JBoss EAP サーバーにリダイレクトするよう設定します。リダイレクトは、デプロイメントごとに (つまり、URL ごとに) 行われます。

重要

このタスクを続行するには、NSAPI コネクターが設定されている必要があります。

基本的な HTTP コネクターの設定
  1. JBoss EAP サーバーにリダイレクトする URL パスを定義します。

    注記

    IPLANET_CONFIG/obj.conf では、前の行から継続する行以外は、行の最初にスペースを挿入しないでください。

    IPLANET_CONFIG/obj.conf ファイルを編集します。<Object name="default"> で始まるセクションを見つけ、一致する各 URL パターンを次のサンプルファイルで示された形式で追加します。文字列 jknsapi は、次の手順で定義される HTTP コネクターを示します。例は、ワイルドカードを使用したパターン一致を示しています。

    <Object name="default">
    [...]
    NameTrans fn="assign-name" from="/status" name="jknsapi"
    NameTrans fn="assign-name" from="/images(|/*)" name="jknsapi"
    NameTrans fn="assign-name" from="/css(|/*)" name="jknsapi"
    NameTrans fn="assign-name" from="/nc(|/*)" name="jknsapi"
    NameTrans fn="assign-name" from="/jmx-console(|/*)" name="jknsapi"
    </Object>
  2. 各パスを提供するワーカーを定義します。

    IPLANET_CONFIG/obj.conf ファイルの編集を続行します。編集したセクションの終了タグのすぐ後に、</Object> を追加します。

    <Object name="jknsapi">
    ObjectType fn=force-type type=text/plain
    Service fn="jk_service" worker="worker01" path="/status"
    Service fn="jk_service" worker="worker02" path="/nc(/*)"
    Service fn="jk_service" worker="worker01"
    </Object>

    上記の例は、URL パス /status へのリクエストを worker01 という名前のワーカーにリダイレクトし、/nc/ 以下のすべての URL パスを worker02 という名前のワーカーにリダイレクトします。3 番目の行は、前の行で一致しない jknsapi オブジェクトに割り当てられたすべての URL が worker01 に提供されることを示しています。

    ファイルを保存し、終了します。

  3. ワーカーとその属性を定義します。

    IPLANET_CONFIG/connectors/ ディレクトリーに workers.properties というファイルを作成します。以下の内容をそのファイルに貼り付けし、お使いの環境に合わせて変更します。

    # An entry that lists all the workers defined
    worker.list=worker01, worker02
    
    # Entries that define the host and port associated with these workers
    worker.worker01.host=127.0.0.1
    worker.worker01.port=8009
    worker.worker01.type=ajp13
    
    worker.worker02.host=127.0.0.100
    worker.worker02.port=8009
    worker.worker02.type=ajp13

    workers.properties ファイルは Apache mod_jk と同じ構文を使用します。

    ファイルを保存し、終了します。

  4. iPlanet Web Server の再起動

    以下のコマンドを実行し、iPlanet Web Server を再起動します。

    IPLANET_CONFIG/../bin/stopserv
    IPLANET_CONFIG/../bin/startserv

iPlanet Web Server が、JBoss EAP のデプロイメントに設定した URL へクライアントリクエストを送信します。

24.4.9.3. NSAPI コネクターがクライアントリクエストを複数の JBoss EAP サーバーで分散するよう設定

このタスクは、負荷分散の設定でクライアントリクエストを JBoss EAP サーバーに送信するよう NSAPI コネクターを設定します。

重要

このタスクを続行するには、NSAPI コネクターが設定されている必要があります。

ロードバランシングのコネクターの設定
  1. JBoss EAP サーバーにリダイレクトする URL パスを定義します。

    注記

    IPLANET_CONFIG/obj.conf では、前の行から継続する行以外は、行の最初にスペースを挿入しないでください。

    IPLANET_CONFIG/obj.conf ファイルを編集します。<Object name="default"> で始まるセクションを見つけ、一致する各 URL パターンを次のサンプルファイルで示された形式で追加します。文字列 jknsapi は、次の手順で定義される HTTP コネクターを示します。例は、ワイルドカードを使用したパターン一致を示しています。

    <Object name="default">
    [...]
    NameTrans fn="assign-name" from="/status" name="jknsapi"
    NameTrans fn="assign-name" from="/images(|/*)" name="jknsapi"
    NameTrans fn="assign-name" from="/css(|/*)" name="jknsapi"
    NameTrans fn="assign-name" from="/nc(|/*)" name="jknsapi"
    NameTrans fn="assign-name" from="/jmx-console(|/*)" name="jknsapi"
    NameTrans fn="assign-name" from="/jkmanager/*" name="jknsapi"
    </Object>
  2. 各パスを提供するワーカーを定義します。

    IPLANET_CONFIG/obj.conf ファイルの編集を続行します。前の手順で変更したセクションの終了タグ (</Object>) のすぐ後に、以下の新しいセクションを追加し、必要に応じて変更します。

    <Object name="jknsapi">
    ObjectType fn=force-type type=text/plain
    Service fn="jk_service" worker="status" path="/jkmanager(/*)"
    Service fn="jk_service" worker="router"
    </Object>

    この jksnapi オブジェクトは、default オブジェクトの name="jksnapi" マッピングにマップされた各パスを提供するために使用されるワーカーノードを定義します。/jkmanager/* に一致する URL 以外のすべてが、router という名前のワーカーにリダイレクトされます。

  3. ワーカーとその属性を定義します。

    workers.properties という名前のファイルを IPLANET_CONFIG/connector/ で作成します。以下の内容をそのファイルに貼り付けし、お使いの環境に合わせて変更します。

    # The advanced router LB worker
    # A list of each worker
    worker.list=router,status
    
    # First JBoss EAP server
    # (worker node) definition.
    # Port 8009 is the standard port for AJP
    #
    
    worker.worker01.port=8009
    worker.worker01.host=127.0.0.1
    worker.worker01.type=ajp13
    worker.worker01.ping_mode=A
    worker.worker01.socket_timeout=10
    worker.worker01.lbfactor=3
    
    # Second JBoss EAP server
    worker.worker02.port=8009
    worker.worker02.host=127.0.0.100
    worker.worker02.type=ajp13
    worker.worker02.ping_mode=A
    worker.worker02.socket_timeout=10
    worker.worker02.lbfactor=1
    
    # Define the load-balancer called "router"
    worker.router.type=lb
    worker.router.balance_workers=worker01,worker02
    
    # Define the status worker
    worker.status.type=status

    workers.properties ファイルは Apache mod_jk と同じ構文を使用します。

    ファイルを保存し、終了します。

  4. iPlanet Web Server 7.0 を再起動します。

    IPLANET_CONFIG/../bin/stopserv
    IPLANET_CONFIG/../bin/startserv

iPlanet Web Server は、設定した URL パターンを負荷分散設定の JBoss EAP サーバーにリダイレクトします。

24.4.10. Eclipse MicroProfile

24.4.10.1. Eclipse MicroProfile Config を使用した設定の管理

重要

Eclipse MicroProfile Config は、テクノロジープレビューとしてのみ提供されます。テクノロジープレビューの機能は、Red Hat の本番環境のサービスレベルアグリーメント (SLA) ではサポートされず、機能的に完全ではないことがあるため、Red Hat は本番環境での使用は推奨しません。テクノロジープレビューの機能は、最新の技術をいち早く提供して、開発段階で機能のテストやフィードバックの収集を可能にするために提供されます。

テクノロジープレビュー機能のサポート範囲については、Red Hat カスタマーポータルの「テクノロジープレビュー機能のサポート範囲」を参照してください。

24.4.10.1.1. MicroProfile Config SmallRye サブシステム

設定データは動的に変更でき、アプリケーションはサーバーを再起動せずに最新の設定情報にアクセスできる必要があります。Eclipse MicroProfile Config は設定データのポータブルな外部化を実現します。これにより、変更や再パッケージ化を必要とせずに、アプリケーションとマイクロサービスを複数の環境で実行するよう設定することができます。Eclipse MicroProfile Config 機能は、SmallRye Config を使用して JBoss EAP に実装され、microprofile-config-smallrye サブシステムによって提供されます。このサブシステムはデフォルトの JBoss EAP 7.3 設定に含まれています。

24.4.10.1.2. MicroProfile Config SmallRye サブシステムによってサポートされる ConfigSources

形式や元の場所が異なることがある MicroProfile Config 設定プロパティーは、org.eclipse.microprofile.config.spi.ConfigSource インターフェースの実装である ConfigSources によって提供されます。

MicroProfile Config 仕様は、設定値を取得するために、以下のデフォルト ConfigSource 実装を提供します。

  • System.getProperties() の使用。
  • System.getenv() の使用。
  • クラスパス上のすべての META-INF/microprofile-config.properties から。

microprofile-config-smallrye サブシステムは、設定値を取得するために ConfigSource リソースの以下の追加タイプをサポートします。

注記

以下のセクションでは、管理 CLI を使用して microprofile-config-smallrye サブシステムを設定しますが、管理コンソールを使用することもできます。 管理コンソールで ConfigurationSubsystemsMicroProfile Config と選択し、表示 をクリックすると、設定できます。

MicroProfile Config SmallRye サブシステムの設定に使用できる属性のリストは「MicroProfile Config SmallRye サブシステムの属性」を参照してください。

プロパティーからの ConfigSource 設定の取得

ConfigSource のアクセス用にプロパティーを直接保存するには、config-source 属性を追加し、properties をリストとして指定します。

以下の管理 CLI コマンドは property1 および property2 プロパティーの設定データが含まれる ConfigSource を作成します。

/subsystem=microprofile-config-smallrye/config-source=props:add(properties={property1=value1,property2=value2})

このコマンドを実行すると、microprofile-config-smallrye サブシステムに以下の XML 設定が指定されます。

<subsystem xmlns="urn:wildfly:microprofile-config-smallrye:1.0">
    <config-source name="props">
        <property name="property1" value="value1"/>
        <property name="property2" value="value2"/>
    </config-source>
</subsystem>
ディレクトリーからの ConfigSource 設定の取得

ConfigSource を作成してディレクトリーのファイルからプロパティーを読み取りするには、config-source 属性を追加して、ファイルが含まれるディレクトリーを指定します。dir ディレクトリーの各ファイルの名前はプロパティーの名前で、ファイルの内容はプロパティーの値になります。

以下の CLI コマンドは、/etc/config/numbers-app/ ディレクトリーのファイルから設定プロパティーを読み取る ConfigSource を作成します。

/subsystem=microprofile-config-smallrye/config-source=file-props:add(dir={path=/etc/config/numbers-app})

このコマンドを実行すると、microprofile-config-smallrye サブシステムに以下の XML 設定が指定されます。

<subsystem xmlns="urn:wildfly:microprofile-config-smallrye:1.0">
    <config-source name="file-props">
        <dir path="/etc/config/numbers-app"/>
    </config-source>
</subsystem>

この構造は、OpenShift の ConfigMaps によって使用される構造に対応します。dir の値は、OpenShift または Kubernetes の ConfigMap 定義にある mountPath に対応します。

JBoss EAP にデプロイされたすべてのアプリケーションは、ディレクトリーに保存されたプロパティーにプログラムを使用してアクセスできます。

/etc/config/numbers-app/ ディレクトリーに以下の 2 つのファイルが含まれていることを仮定します。

  • num.size: このファイルには 5 が値として含まれています。
  • num.max: このファイルには 100 が値として含まれています。

以下のコード例では、num.size5 を返し、num.max100 を返します。

@Inject
@ConfigProperty(name = "num.size")
int numSize;

@Inject
@ConfigProperty(name = "num.max")
int numMax;
ConfigSource クラスからの ConfigSource 設定の取得

カスタムの org.eclipse.microprofile.config.spi.ConfigSource 実装クラスを作成および設定して、設定値のソースを提供することができます。

以下の管理 CLI コマンドは、org.example という名前の JBoss Module によって提供される、org.example.MyConfigSource という名前の実装クラスの ConfigSource を作成します。

/subsystem=microprofile-config-smallrye/config-source=my-config-source:add(class={name=org.example.MyConfigSource, module=org.example})

このコマンドを実行すると、microprofile-config-smallrye サブシステムに以下の XML 設定が指定されます。

<subsystem xmlns="urn:wildfly:microprofile-config-smallrye:1.0">
    <config-source name="my-config-source">
        <class name="org.example.MyConfigSource" module="org.example"/>
    </config-source>
</subsystem>

この ConfigSource クラスによって提供されるプロパティーはすべての JBoss EAP デプロイメントで使用できます。

JBoss EAP サーバーにグローバルモジュールを追加する方法は「グローバルモジュールの定義」を参照してください。

ConfigSourceProvider クラスからの ConfigSource 設定の取得

複数の ConfigSource インスタンスの実装を登録する、カスタムの org.eclipse.microprofile.config.spi.ConfigSourceProvider 実装クラスを作成および設定できます。

以下の管理 CLI コマンドは、org.example という名前の JBoss Module によって提供される、org.example.MyConfigSourceProvider という名前の実装クラスの config-source-provider を作成します。

/subsystem=microprofile-config-smallrye/config-source-provider=my-config-source-provider:add(class={name=org.example.MyConfigSourceProvider, module=org.example})

このコマンドを実行すると、microprofile-config-smallrye サブシステムに以下の XML 設定が指定されます。

<subsystem xmlns="urn:wildfly:microprofile-config-smallrye:1.0">
    <config-source-provider name="my-config-source-provider">
         <class name="org.example.MyConfigSourceProvider" module="org.example"/>
    </config-source-provider>
</subsystem>

ConfigSourceProvider 実装によって提供されるプロパティーはすべての JBoss EAP デプロイメントで使用できます。

JBoss EAP サーバーにグローバルモジュールを追加する方法は「グローバルモジュールの定義」を参照してください。

24.4.10.1.3. ConfigSources にアクセスするアプリケーションのデプロイ

Java コードで MicroProfile Config にアクセスするアプリケーションは、CDI を有効にする必要があります。 これには、デプロイメントアーカイブに META-INF/beans.xml または WEB-INF/beans.xml ファイルが含まれるようにするか、CDI bean アノテーションが含まれるようにします。

CDI の詳細は、JBoss EAP『開発ガイド』の「コンテキストおよび依存関係の挿入 (CDI)」を参照してください。

24.4.10.2. MicroProfile OpenTracing SmallRye サブシステムでのリクエストのトレース

重要

Eclipse Microprofile OpenTracing は、テクノロジープレビューとしてのみ提供されます。テクノロジープレビューの機能は、Red Hat の本番環境のサービスレベルアグリーメント (SLA) ではサポートされず、機能的に完全ではないことがあるため、Red Hat は本番環境での使用は推奨しません。テクノロジープレビューの機能は、最新の技術をいち早く提供して、開発段階で機能のテストやフィードバックの収集を可能にするために提供されます。

テクノロジープレビュー機能のサポート範囲については、Red Hat カスタマーポータルの「テクノロジープレビュー機能のサポート範囲」を参照してください。

24.4.10.2.1. Eclipse MicroProfile OpenTracing

サービス境界全体でリクエストをトレースする機能は、ライフサイクル中にリクエストが複数のサービスを通過するマイクロサービス環境で特に重要となります。Eclipse Microprofile OpenTracing 仕様は、Jakarta RESTful Web Services アプリケーション内の Open Tacing 対応の Tracer オブジェクトにアクセスするための、動作および API を定義します。動作は、送受信リクエストに対してどのように Open Tracing Spans が自動的に作成されるかを指定します。API は、指定のエンドポイントのトレースをどのように明示的に無効または有効にするかを定義します。

24.4.10.2.2. MicroProfile OpenTracing SmallRye サブシステム

Eclipse MicroProfile Open Tracing 機能は、SmallRye OpenTracing コンポーネントを使用して JBoss EAP に実装され、microprofile-opentracing-smallrye サブシステムによって提供されます。このサブシステムは、JAX-RS エンドポイントへのリクエストのトレースと CDI bean のサポートが含まれる Microprofile 1.3.0 を実装し、デフォルトの JBoss EAP 7.3 設定に含まれています。

microprofile-opentracing-smallrye には Jaeger Client がデフォルトのトレーサーとして同梱されています。また、Jakarta RESTful Web Services や Contexts and Dependency Injection など Jakarta EE アプリケーションで一般的に使用されるコンポーネントのインスツルメンテーションライブラリーのセットも含まれています。JBoss EAP サーバーに自動的にデプロイされた各 WAR は、独自の Tracer インスタンスを持ちます。EAR 内の各 WAR は個別の WAR として扱われ、各 WAR には独自の Tracer インスタンスがあります。デフォルトでは、Jaeger Client と使用されるサービス名はデプロイメントの名前から派生し、通常これは WAR ファイル名になります。

24.4.10.2.3. MicroProfile OpenTracing SmallRye サブシステムの設定

microprofile-opentracing-smallrye サブシステムは、デフォルトの JBoss EAP 7.3 設定に含まれています。有効な OpenTracing にはメモリーまたはパフォーマンスコストが関係するため、このサブシステムを無効にしたい場合があります。

以下の管理 CLI コマンドを使用してサーバー設定からサブシステムを削除し、サーバーインスタンスに対して MicroProfile Open Tracing 機能をグローバルに無効にします。

  1. サブシステムを削除します。

    /subsystem=microprofile-opentracing-smallrye:remove()
  2. 変更を反映するためにサーバーをリロードします。

    reload

以下の管理 CLI コマンドを使用してサーバー設定にサブシステムを追加し、サーバーインスタンスに対して MicroProfile Open Tracing 機能をグローバルに有効にします。

  1. サブシステムを追加します。

    /subsystem=microprofile-opentracing-smallrye:add()
  2. 変更を反映するためにサーバーをリロードします。

    reload

microprofile-opentracing-smallrye サブシステムに使用できる別の設定オプションはありません。代わりに、システムプロパティーまたは環境変数を設定して Jaeger Client を設定します。Jaeger Client の設定方法に関する詳細は、Jaeger のドキュメント を参照してください。有効なシステムプロパティーのリストは Jaeger ドキュメントの「Configuration via Environment」を参照してください。

重要

この機能はテクノロジープレビューとして提供されるため、システムプロパティーや環境変数を使用した Jaeger Client トレーサーの設定に関する現在の設定オプションは特に今後のリリースで互換性のない状態で変更される可能性があります。

また、デフォルトでは Jakarta 用の Jaeger Client に 0.001 に設定されている確率的サンプリングストラテジーがあり、約 1000 トレースに 1 つの割合でのみサンプルが取られることに注意してください。すべてのリクエストのサンプルを取るには、システムプロパティー JAEGER_SAMPLER_TYPEconst に設定し、JAEGER_SAMPLER_PARAM1 に設定します。

デフォルトトレーサーをオーバーライドする方法と、CDI bean のトレース方法に関する詳細は、『開発ガイド』の「Eclipse MicroProfile OpenTracing を使用したリクエストのトレース」を参照してください。

24.4.10.3. Eclipse MicroProfile Health を使用したサーバー状態の監視

重要

Eclipse MicroProfile Health は、テクノロジープレビューとしてのみ提供されます。テクノロジープレビューの機能は、Red Hat の本番環境のサービスレベルアグリーメント (SLA) ではサポートされず、機能的に完全ではないことがあるため、Red Hat は本番環境での使用は推奨しません。テクノロジープレビューの機能は、最新の技術をいち早く提供して、開発段階で機能のテストやフィードバックの収集を可能にするために提供されます。

テクノロジープレビュー機能のサポート範囲については、Red Hat カスタマーポータルの「テクノロジープレビュー機能のサポート範囲」を参照してください。

24.4.10.3.1. MicroProfile Health SmallRye サブシステム

JBoss EAP には、microprofile-health-smallrye サブシステムを使用して Eclipse MicroProfile Health 機能を提供する SmallRye Health コンポーネントが含まれています。このサブシステムは、JBoss EAP インスタンスが想定どおりに応答しているかどうかを判断するために使用され、デフォルトで有効になっています。

重要

デフォルトでは、MicroProfile Health SmallRye サブシステムはサーバーが稼働していることのみを評価します。カスタムヘルスチェックを含める場合は、『開発ガイド』の「カスタムヘルスチェックの実装」を参照してください。

Microprofile Health は、JBoss EAP をスタンドアロンサーバーとして実行している場合のみ利用できます。

24.4.10.3.2. 管理 CLI の例を使用したヘルスチェック

ヘルスチェックは管理 CLI を使用して確認できます。

  • :check 属性は、サーバーの現在の状態 (liveness) および (readiness プローブ) を取得します。
/subsystem=microprofile-health-smallrye:check
{
    "outcome" => "success",
    "result" => {
        "outcome" => "UP",
        "checks" => []
    }
}
  • :check-live 属性は liveness プローブの正常データのみを取得します。
/subsystem=microprofile-health-smallrye:check-live
{
    "outcome" => "success",
    "result" => {
        "outcome" => "UP",
        "checks" => []
    }
}
  • :check-ready 属性は readiness プローブの正常データのみを取得します。
/subsystem=microprofile-health-smallrye:check-ready
{
    "outcome" => "success",
    "result" => {
        "outcome" => "UP",
        "checks" => []
    }
}
24.4.10.3.3. 管理コンソールを使用したヘルスチェックの検証

管理コンソールには、ヘルスチェックとグローバルの結果をブール値として表示するチェックランタイム操作が含まれます。

管理コンソールからサーバーの現在の状態を取得するには、以下を実行します。

  1. Runtime タブに移動し、サーバーを選択します。
  2. Monitor の列で MicroProfile HealthView の順にクリックします。
24.4.10.3.4. HTTP エンドポイントを使用したヘルスチェックの確認

ヘルスチェックは自動的に JBoss EAP の health コンテキストにデプロイされます。

That means that in addition to being able to examine it using the management CLI, you can also obtain the current health using the HTTP endpoint. The default address for the `/health` endpoint, accessible from the management interfaces, is `http://127.0.0.1:9990/health`.
  1. HTTP エンドポイントを使用して、サーバーの現在のヘルス状態を取得するには、以下の URL を使用します。
http://HOST:9990/health

このコンテキストにアクセスすると、サーバーの正常性を示すヘルスチェックが JSON 形式で表示されます。このエンドポイントは liveness プローブと readiness プローブの両方の正常性を確認します。

  1. /health/live エンドポイントは、liveness プローブの現在のヘルスをチェックします。
http://HOST:9990/health/live
  1. /health/ready エンドポイントは、readiness プローブの現在のヘルスをチェックします。
http://HOST:9990/health/ready
24.4.10.3.5. プローブが定義されていない場合のグローバルステータス

:empty-readiness-checks-status および :empty-liveness-checks-status は、readiness プローブまたは liveness プローブが定義されていない場合のグローバルステータスを指定する管理属性です。これらの属性により、アプリケーションは、そのアプリケーションが ready/live であることをプローブが確認するまで、’DOWN’ を報告できるようになります。デフォルトでは、これらの属性は ’UP’ を報告します。

  1. :empty-readiness-checks-status 属性は、readiness プローブが定義されていない場合に、readiness プローブのグローバルステータスを指定します。
/subsystem=microprofile-health-smallrye:read-attribute(name=empty-readiness-checks-status)
{
    "outcome" => "success",
    "result" => expression "${env.MP_HEALTH_EMPTY_READINESS_CHECKS_STATUS:UP}"
}
  1. :empty-liveness-checks-status 属性は、liveness プローブが定義されていない場合に、liveliness プローブのグローバルステータスを指定します。
/subsystem=microprofile-health-smallrye:read-attribute(name=empty-liveness-checks-status)
{
    "outcome" => "success",
    "result" => expression "${env.MP_HEALTH_EMPTY_LIVENESS_CHECKS_STATUS:UP}"
}

readiness および liveness プローブの両方を確認する /health HTTP エンドポイントと :check 操作は、これらの属性も考慮します。

24.4.10.3.6. HTTP エンドポイントの認証の有効化

health コンテキストを設定すると、このコンテキストへのアクセスにユーザーの認証を必要とすることができます。

このエンドポイントで認証を有効にするには、以下の手順に従います。

  1. microprofile-health-smallrye サブシステムで security-enabled 属性を true に設定します。

    /subsystem=microprofile-health-smallrye:write-attribute(name=security-enabled,value=true)
  2. 変更を反映するためにサーバーをリロードします。

    reload

health エンドポイントにアクセスしようとすると、認証プロンプトが表示されるようになります。

24.4.10.4. Eclipse MicroProfile Metrics

重要

Eclipse MicroProfile Metrics は、テクノロジープレビューとしてのみ提供されます。テクノロジープレビューの機能は、Red Hat の本番環境のサービスレベルアグリーメント (SLA) ではサポートされず、機能的に完全ではないことがあるため、Red Hat は本番環境での使用は推奨しません。テクノロジープレビューの機能は、最新の技術をいち早く提供して、開発段階で機能のテストやフィードバックの収集を可能にするために提供されます。

テクノロジープレビュー機能のサポート範囲については、Red Hat カスタマーポータルの「テクノロジープレビュー機能のサポート範囲」を参照してください。

24.4.10.4.1. MicroProfile Metrics サブシステムについて

JBoss EAP では、microprofile-metrics-smallrye サブシステムを使用して Eclipse MicroProfile Metrics 機能を提供する SmallRye Metrics コンポーネントが含まれるようになりました。このサブシステムは、JBoss EAP インスタンスのモニタリングデータを提供するために使用されます。これはデフォルトで有効です。

重要

microprofile-metrics-smallrye サブシステムは、スタンドアロン設定でのみ有効になります。

24.4.10.4.2. HTTP エンドポイントを使用したメトリクスの検証

メトリクスは JBoss EAP 管理インターフェースで自動的に利用できるようになり、以下のコンテキストを使用できます。

  • /metrics/: MicroProfile 3.0 仕様に指定されたメトリクスが含まれます。
  • /metrics/vendor: メモリープールなどのベンダー固有のメトリクスが含まれます。
  • /metrics/application: MicroProfile Metrics API を使用するデプロイしたアプリケーションおよびサブシステムのメトリクスが含まれます。

JBoss EAP サブシステムメトリクスは Prometheus 形式で公開されます。

メトリクス名はサブシステムと属性名に基づきます。たとえば、サブシステム undertow は、アプリケーションデプロイメントのすべてのサーブレットのメトリクス属性 request-count を公開します。このメトリクスの名前は jboss_undertow_request_count です。接頭辞 jboss はメトリクスソースを特定するのに役立ちます。

EAP で公開されるメトリクスの一覧を表示するには、CLI で以下のコマンドを実行します。

$ curl -v http://localhost:9990/metrics | grep -i type

例: JAX-RS アプリケーションの要求数の取得

以下の例は、JBoss EAP にデプロイされた web サービスへのリクエスト数を検索する方法を示しています。この例では、helloworld-rs クイックスタートを web サービスとして使用します。クイックスタートを jboss-eap-quickstarts からダウンロードします。

helloworld-rs クイックスタートの request-count メトリックを確認するには、以下の手順に従います。

  1. undertow サブシステムの統計を有効にします。

    • 統計が有効な状態でスタンドアロンサーバーを起動します。

      $ ./standalone.sh -Dwildfly.statistics-enabled=true
    • 既にサーバーが稼働している場合は、undertow サブシステムの統計を有効にします。

      /subsystem=undertow/:write-attribute(name=statistics-enabled,value=true)
  2. helloworld-rs クイックスタートをデプロイします。

    • クイックスタートのルートディレクトリーに、Maven を使用して web アプリケーションをデプロイします。

      $ mvn clean install wildfly:deploy
  3. curl コマンドを使用して CLI で http エンドポイントをクエリーし、request_count に対してフィルター処理を行います。

    $ curl -v http://localhost:9990/metrics |  grep request_count

    出力:

    jboss_undertow_request_count_total{server="default-server",http_listener="default",} 0.0

    返された属性値は 0.0 です。

  4. Web ブラウザーで http://localhost:8080/helloworld-rs/ にあるクイックスタートにアクセスし、任意のリンクをクリックします。
  5. CLI から http エンドポイントを再度クエリーします。

    $ curl -v http://localhost:9990/metrics |  grep request_count

    出力:

    jboss_undertow_request_count_total{server="default-server",http_listener="default",} 1.0

    値は 1.0 に更新されました。

    前回の 2 つの手順を繰り返して、要求数が正しく更新されていることを確認します。

24.4.10.4.3. 管理コンソールを使用した MicroProfile メトリクスの設定

管理コンソールでは、以下の設定を実行できます。

  • メトリクスの公開を有効または無効にします。
  • 公開されるメトリクスの接頭辞を編集します。
  • セキュリティーを有効または無効にします。
  • 必須でないフィールドを初期値またはデフォルト値にリセットします。

管理コンソールを使用して MicroProfile メトリクスを設定するには、以下の手順に従います。

  • 管理コンソールにアクセスし、ConfigurationSubsystemsMicroProfile Metrics の順に移動して View をクリックし、MicroProfile Metrics ページを開きます。
24.4.10.4.4. HTTP エンドポイントの認証の有効化

metroics コンテキストおよびすべてのサブコンテキストは、コンテキストのアクセスにユーザー許可を必須にするように設定できます。以下の手順は、このエンドポイントで認証を有効にします。

  1. microprofile-metrics-smallrye サブシステムで security-enabled 属性を true に設定します。

    /subsystem=microprofile-metrics-smallrye:write-attribute(name=security-enabled,value=true)
  2. 変更を反映するためにサーバーをリロードします。

    reload

サブシステムが metrics エンドポイントにアクセスを試みると、認証プロンプトが表示されるようになりました。