24.6. 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.6.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.6.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.6.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.6.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.6.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)

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


このページには機械翻訳が使用されている場合があります (詳細はこちら)。