HTTP コネクターおよび負荷分散ガイド 5.4

Red Hat JBoss Web Server 5.4

Red Hat JBoss Web Server 5.4 向け

Red Hat Customer Content Services

概要

本ガイドでは、負荷分散ソリューション (mod_cluster および mod_jk) のインストールおよび設定と Red Hat JBCS の Apache HTTP Server の提供する他のモジュールのユーザーに役立つ情報を提供します。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、弊社 の CTO、Chris Wright のメッセージ を参照してください。

第1章 はじめに

本ガイドでは、Red Hat JBoss Core Services に含まれる 2 つの異なる負荷分散 HTTP コネクターのインストールおよび設定について説明します。

  • Apache Tomcat Connector (mod_jk) は、スティッキーセッションを維持し、AJP 経由で通信する一方で、一連のサーブレットコンテナーへの HTTP 呼び出しの負荷分散をサポートします。
  • mod_cluster は mod_jk よりも高度なロードバランサーで、mod_jk のすべての機能とその他の追加機能を提供します。これには、リアルタイムの負荷分散の計算、アプリケーションライフサイクル制御、自動プロキシー検出、複数のプロトコルサポートが含まれます。

本ガイドには、Online Certificate Status Protocol (OCSP) に関する情報と、基本的な負荷分散の作業例mod_auth_kerb を使用した Kerberos 認証 も含まれています。

重要

本ガイドのほとんどのファイルおよびディレクトリーパスは、Red Hat Enterprise Linux の JBoss Core Services の ZIP インストール用です。その他のプラットフォームの場合は、JBoss Core Services『インストールガイド』の説明に従って、対象のインストールの正しいパスを使用します。

第2章 Apache Tomcat Connector (mod_jk)

Apache Tomcat Connector の mod_jk は、Apache HTTP Server からサーブレットコンテナーへのリクエスト転送を可能にするプラグインです。モジュールは、スティッキーセッションを維持しながら、一連のサーブレットコンテナーへの HTTP 呼び出しの負荷分散にも対応します。

2.1. mod_jk のダウンロードおよびインストール

mod_jk モジュールは、JBoss Core Services インストールの Apache HTTP Server に含まれています。

JBoss Core Services インストールガイド の手順に従って、お使いのオペレーティングシステム用の Apache HTTP Server をダウンロードし、インストールします。

2.2. Apache HTTP Server および mod_jk を使用した負荷分散の設定

mod_jk コネクターを使用して Apache HTTP Server の負荷分散を設定できます。本項のタスクにしたがって、mod_jk を使用して負荷分散を設定します (ワーカーノードの設定を含む)。

mod_jk 用の設定ファイルのサンプルは JBCS_HOME/httpd/conf.d/ にあります。設定ファイルの例は mod_jk.conf.sampleworkers.properties.sample、および uriworkermap.properties.sample です。独自の設定ファイルを作成するのではなく、これらのサンプルを使用するには、.sample エクステンションを削除し、必要に応じてコンテンツを変更します。

注記

Red Hat のお客様は Red Hat カスタマーポータルにある Load Balancer Configuration Tool を使用して mod_jk や Tomcat ワーカーノードに最適な設定テンプレートを迅速に生成することもできます。

JBoss Web Server 5.4 にこのツールを使用する場合は、Apache バージョンを 2.4.x として選択し、バックエンド設定を Tomcat として選択してください。

2.2.1. mod_jk をロードする Apache HTTP Server の設定

  1. 新しいファイル JBCS_HOME/httpd/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 SSL 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>
    重要

    LoadModule ディレクティブは、インストールした mod_jk ネイティブバイナリーを参照する必要があります。

    注記

    JkMount ディレクティブは、Apache HTTP Server が mod_jk モジュールに転送する URL を指定します。ディレクティブの設定に基づいて、mod_jk は受信した URL を正しいサーブレットコンテナーに転送します。

    Apache HTTP Server が直接静的コンテンツ (または PHP コンテンツ) に対応し、Java アプリケーションのロードバランサーのみを使用するには、上記の推奨設定では、URL /application/* のあるリクエストのみが mod_jk ロードバランサーに送信されるように指定されます。

    JkMount/* を指定して、すべての URL を mod_jk に転送できます。

  2. オプション: JKMountFile ディレクティブ

    JkMount ディレクティブの他に、JkMountFile ディレクティブを使用してマウントポイントの設定ファイルを指定できます。設定ファイルには、Tomcat 転送の複数の URL マッピングが含まれます。

    1. JBCS_HOME/httpd/conf.d/ に移動し、uriworkermap.properties という名前のファイルを作成します。
    2. 以下の構文例をガイドとして使用し、転送する URL およびワーカー名を指定します。

      必要な構文は /URL=WORKER_NAME の形式を取ります。

      以下の例は、/application のリクエストを JBoss Web Server Tomcat バックエンドに転送するよう mod_jk を設定します。

      # Simple worker configuration file
      
      # Mount the Servlet context to the ajp13 worker
      /application=loadbalancer
      /application/*=loadbalancer
    3. JBCS_HOME/httpd/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
  3. 任意: Apache HTTP Server のロギングを設定します

    どのワーカーノードがリクエストを処理するかをログに記録するために負荷分散を実施している Apache HTTP サーバーを設定できます。これは、ロードバランサーのトラブルシューティングに役立ちます。

    この機能を mod_jk に対して有効にするには、以下のいずれかを行います。

    • JkRequestLogFormat%w を含めます (これは、上記の提案でデフォルトで設定されます)。または、
    • Apache HTTP Server LogFormat%{JK_WORKER_NAME}n が含まれるようにして、使用される mod_jk ワーカーの名前をログに記録します。

    JkRequestLogFormat の詳細は Apache Tomcat コネクタードキュメント を参照してください。ログローテーションを含む Apache HTTP Server ロギングの詳細は、ログファイルに関する Apache HTTP Server ドキュメント を参照してください。

2.2.2. mod_jk でのワーカーノードの設定

この手順では、2 つのサーブレットコンテナー間でスティッキーセッションがアクティブな加重ラウンドロビン設定での、2 つの mod_jk ワーカーノード定義を示しています。

要件

mod_jk ワーカーノードを設定するには以下を行います。

  1. JBCS_HOME/httpd/conf.d/ に移動し、workers.properties という名前のファイルを作成します。
  2. 以下の設定を 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

2.2.3. mod_jk と連携するように Tomcat を設定

Tomcat はデフォルトで、mod_jk から AJP トラフィックを受信するように設定されますが、mod_jk でワーカーを使用する前に追加の手順が 1 つ必要です。AJP コネクターは JBCS_HOME/tomcat<VERSION>/conf/server.xml でデフォルトで設定されます。

<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />

AJP 対応のコネクターに加えて、各ワーカーノードの Engine で jvmRoute 属性に一意の値を設定する必要もあります。

<Engine name="Catalina" jvmRoute="node1" >
重要

jvmRoute 属性値は、workers.properties に設定されたワーカー名と一致している必要があります。

第3章 mod_cluster コネクター

3.1. 概要

mod_cluster コネクターは縮小された設定の、JBoss EAP および JBoss Web Server Tomcat のインテリジェントな負荷分散ソリューションで、JBoss mod_cluster コミュニティープロジェクトによって開発された技術に基づいています。

mod_cluster モジュールは、Apache HTTP Server をプロキシーサーバーとして使用して JBoss EAP および JBoss Web Server Tomcat ワーカーノードに HTTP 要求を負荷分散します。

3.1.1. 主な特長

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

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

3.1.2. コンポーネント

プロキシーサーバーでは、mod_cluster は 4 つの Apache モジュールで構成されます。

表3.1 コンポーネント

コンポーネント説明

mod_cluster_slotmem.so

Shared Memory Manager モジュールは、リアルタイムのワーカーノード情報を複数の Apache HTTP Server プロセスと共有します。

mod_manager.so

Cluster Manager モジュールは、ノードの登録、ノードの負荷データ、ノードアプリケーションのライフサイクルイベントなど、ワーカーノードからメッセージを受信および確認します。

mod_proxy_cluster.so

Proxy Balancer モジュールは、クラスターノードへの要求ルーティングを処理します。Proxy Balancer は、クラスターのアプリケーションの場所、各クラスターノードの現在の状態、およびセッション ID (リクエストが確立されたセッションの一部である場合) に基づいて適切な宛先ノードを選択します。

mod_advertise.so

Proxy Advertisement Module は、UDP マルチキャストメッセージを介してプロキシーサーバーの存在をブロードキャストします。サーバーのアドバタイズメッセージには、負荷分散クラスターに参加するワーカーノードからの応答をプロキシーサーバーがリッスンしている IP アドレスとポート番号が含まれます。

利用可能なモジュール (user-configurable パラメーターなど) の詳細は、Apache HTTP Server Modules appendix を参照してください。

3.1.3. 文字の制限

mod_cluster は共有メモリーを使用してノードの記述を維持します。共有メモリーは Apache HTTP Server の起動時に作成され、各項目の構造は固定されます。プロキシーサーバーおよびワーカーノードのプロパティーを定義する際に、以下の文字制限に従うようにしてください。

  • エイリアスの最大長: 100 文字 (エイリアスはそれぞれの仮想ホストのネットワーク名に対応します。名前は Host 要素で定義されます)。
  • コンテキストの最大長: 40 文字 (例: myapp.war/myapp にデプロイされている場合 /myapp はコンテキストに含まれます)。
  • バランサー名の最大長: 40 文字 (mbean のバランサープロパティー)
  • JVMRoute 文字列の最大長: 80 文字 (<Engine> 要素の JVMRoute)。
  • ドメイン名の最大長: 20 文字 (mbean のドメインプロパティー)。
  • Maximum hostname length for a node: 64 文字 (<Connector> 要素のホスト名アドレス)。
  • ノードのポートの最大長: 7 文字 (<Connector> 要素の port プロパティー、8009 は 4 文字)。
  • ノードのスキームの最大長: 6 文字 (コネクターのプロトコル。利用できる値は httphttpsajp です)。
  • クッキー名の最大長: 30 文字 (セッション ID のヘッダークッキー名。デフォルト値: org.apache.catalina.Globals.SESSION_COOKIE_NAMEJSESSIONID)。
  • パス名の最大長: 30 文字 (セッション ID のパラメーター名。デフォルト値は org.apache.catalina.Globals.SESSION_PARAMETER_NAME からの JSESSIONID です。
  • セッション ID の最大長: 120 文字 (セッション ID: BE81FAA969BF64C8EC2B6600457EAAAA.node01 のようになります)。

3.2. mod_cluster のダウンロードおよびインストール

mod_cluster モジュールは、JBoss Core Services インストールの Apache HTTP Server に含まれています。

JBoss Core Services インストールガイド の手順に従って、お使いのオペレーティングシステム用の Apache HTTP Server をダウンロードし、インストールします。

3.3. Apache HTTP サーバーおよび mod_cluster を使用した負荷分散の設定

JBoss Web Server 2.1 以降では、デフォルトで Apache HTTP Server に対して mod_cluster が正しく設定されます。カスタム設定を設定するには、「基本的なプロキシーサーバーの設定」を参照してください。

mod_cluster を使用した Tomcat ワーカーノードの設定に関する詳細は、「ワーカーノードの設定」を参照してください。

注記

Red Hat のお客様は Red Hat カスタマーポータルにある Load Balancer Configuration Tool を使用して mod_cluster や Tomcat ワーカーに最適な設定テンプレートを迅速に生成することもできます。

JBoss Web Server 3 にこのツールを使用する場合は、Apache バージョンを 2.4.x として選択し、バックエンド設定を Tomcat として選択してください。

3.3.1. 基本のプロキシサーバーの設定

プロキシーサーバー設定は、1 つの必須手順と 1 つの任意ステップで構成されます。

  1. Proxy Server リスナーを、ワーカーノードの接続要求およびワーカーノードのフィードバックを受信するように設定します。
  2. 任意: サーバーのアドバタイズを無効にします。

サーバーアドバタイズメント

プロキシーサーバーは UDP マルチキャストを使用してアドバタイズします。プロキシーサーバーとワーカーノード間で UDP マルチキャストを利用できる場合、サーバーアドバタイズメントはプロキシーサーバーで追加設定なしでワーカーノードを追加し、ワーカーノードには最低限の設定のみが必要です。

UDP マルチキャストが利用できない、または望ましくない場合は ワーカーノードをプロキシーサーバーの静的リストで設定します。いずれの場合も、プロキシーサーバーはワーカーノードの一覧で設定する必要はありません。

3.3.1.1. mod_cluster を使用したロードバランシングプロキシーの設定

要件

  • JBoss Web Server をインストールし、インストール用に mod_cluster モジュールを設定します。詳細は、JBoss Web Server 『インストールガイド』 を参照してください。

管理チャネル用の仮想ホスト mod_cluster を使用してロードバランシングプロキシーを設定するには、以下を設定する必要があります。

注記

このアドレスとポートの組み合わせは mod_cluster 管理メッセージ用のみで、一般的なトラフィック用ではありません。

  1. プロキシーサーバーの Listen ディレクティブを作成します。

    mod_cluster 設定ファイル (通常 JBCS_HOME/httpd/conf.d/mod_cluster.conf) を編集して以下を追加します。

    Listen IP_ADDRESS:PORT_NUMBER

    IP_ADDRESS は、ワーカーノードと通信するためのサーバーネットワークインターフェースのアドレスで、PORT_NUMBER はリッスンするインターフェースのポートです。

    注記

    ポートは、受信 TCP 接続に対して開いている必要があります。

  2. 仮想ホストを作成します。

    以下を mod_cluster 設定ファイルに追加します。

    <VirtualHost IP_ADDRESS:PORT_NUMBER>
    
       <Directory />
          Require ip IP_ADDRESS
       </Directory>
    
       KeepAliveTimeout 60
       MaxKeepAliveRequests 0
    
       ManagerBalancerName mycluster
       AdvertiseFrequency 5
       EnableMCPMReceive On
    
    </VirtualHost>

    IP_ADDRESSPORT_NUMBERListen ディレクティブの値です。

  3. 任意: サーバーのアドバタイズを無効にします。

    AdvertiseFrequency ディレクティブにより、サーバーは UDP マルチキャストを介してサーバーアドバタイズメッセージを定期的に送信します。デフォルトでは、これは 10 秒ごとに発生します。

    これらのサーバー広告メッセージには、VirtualHost 定義で指定された IP _ADDRESS および PORT_NUMBER が含まれます。サーバーアドバタイズに応答するように設定されたワーカーノードは、この情報を使用してプロキシーサーバーに登録されます。

    サーバーのアドバタイズを無効にするには、以下のディレクティブを VirtualHost 定義に追加します。

    ServerAdvertise Off

    サーバーのアドバタイズが無効になっている場合や、UDP マルチキャストがプロキシーサーバーとワーカーノードの間のネットワークで利用できない場合、ワーカーノードをプロキシーサーバーの静的リストで設定します

  4. 任意: Apache HTTP Server のロギングを設定します。

    どのワーカーノードがリクエストを処理するかをログに記録するために負荷分散を実施している Apache HTTP サーバーを設定できます。これは、ロードバランサーのトラブルシューティングに役立ちます。

    mod_cluster に対してこれを有効にするには、Apache HTTP Server LogFormat ディレクティブに以下を追加します。

    %{BALANCER_NAME}e
    リクエストに対応したバランサーの名前。
    %{BALANCER_WORKER_NAME}e
    要求に対応したワーカーノードの名前。

    ログローテーションを含む Apache HTTP Server ロギングの詳細は、http://httpd.apache.org/docs/2.4/logs.html を参照してください。

  5. Apache HTTP Server サービスを停止して起動します。

    詳細な手順は、JBoss Core Services『インストールガイド』を参照してください。

3.3.2. ワーカーノードの設定

3.3.2.1. Tomcat ワーカーノードの設定

以下の手順に従って、JBoss Web Server ノードに mod_cluster をインストールし、クラスター化されていない操作に対して設定します。

注記

JBoss Web Server Tomcat ワーカーノードは、mod_cluster 機能のサブセットのみをサポートします。完全な mod_cluster 機能は JBoss EAP で利用できます。

サポートされるワーカーノードのタイプ

  • JBoss Web Server Tomcat サービス。

mod_cluster JBoss Web Server ノードの制限

  • 非クラスターモードのみ。
  • 負荷分散係数を計算するときに一度に使用できる負荷メトリックは 1 つだけです。

要件

Tomcat ワーカーノードを設定するには、以下を実行します。

  1. リスナーを Tomcat に追加します。

    JWS_HOME/tomcat<VERSION>/conf/server.xml の他の Listener 要素の下に、以下の Listener 要素を追加します。

    <Listener className="org.jboss.modcluster.container.catalina.standalone.ModClusterListener" advertise="true" stickySession="true" stickySessionForce="false" stickySessionRemove="true" />
  2. ワーカーに一意のアイデンティティーを付与します。

    JWS_HOME/tomcat<VERSION>/conf/server.xml を編集し、以下のように jvmRoute 属性と値を Engine 要素に追加します。

    <Engine name="Catalina" defaultHost="localhost" jvmRoute="worker01">
  3. STATUS MCMP メッセージ頻度を設定します。

    Tomcat ワーカーノードは、現在の負荷ステータスを含むステータスメッセージを Apache HTTP Server バランサーに定期的に送信します。これらのメッセージのデフォルトの頻度は 10 秒です。数百のワーカーノードがある場合、STATUS MCMP メッセージによって Apache HTTP Server ネットワークのトラフィック輻輳が増える可能性があります。

    MCMP メッセージ頻度を設定するには、org.jboss.modcluster.container.catalina.status-frequency Java システムプロパティーを変更します。デフォルトでは、プロパティーは秒に 10 を掛けた値を受け入れます。たとえば、プロパティーを 1 に設定すると 10 秒になります。以下の例では、頻度を 60 秒に設定します。

    -Dorg.jboss.modcluster.container.catalina.status-frequency=6
  4. 任意: プロキシーサーバーのアドバタイズにファイアウォールを設定します。

    mod_cluster を使用するプロキシーサーバーは UDP マルチキャストを介してアドバタイズできます。多くのオペレーティングシステムのファイアウォールは、デフォルトでこれをブロックします。サーバーのアドバタイズを有効にしてこのマルチキャストメッセージを受信するには、ワーカーノードのファイアウォールで UDP 接続の 23364 ポートを開きます。

    • Red Hat Enterprise Linux 7 の場合

      firewall-cmd --permanent --zone=public --add-port=23364/udp
    • PowerShell を使用する Microsoft Windows の場合

      Start-Process "$psHome\powershell.exe" -Verb Runas -ArgumentList '-command "NetSh Advfirewall firewall add rule name="UDP Port 23364" dir=in  action=allow protocol=UDP localport=23364"'
      Start-Process "$psHome\powershell.exe" -Verb Runas -ArgumentList '-command "NetSh Advfirewall firewall add rule name="UDP Port 23364" dir=out action=allow protocol=UDP localport=23364"'
重要

Red Hat Enterprise Linux 6 はサポートされなくなり、その後ドキュメントから削除されました。

3.3.2.2. 静的プロキシーリストを使用したワーカーノードの設定

サーバーのアドバタイズにより、ワーカーノードをプロキシーサーバーで自動的に検出し、登録することができます。UDP マルチキャストが利用できない場合やサーバーのアドバタイズが無効になっている場合、ワーカーノードはプロキシーサーバーアドレスおよびポートの静的リストで設定する必要があります。

以下の手順を使用して、プロキシーサーバーの静的リストで操作するよう JBoss Web Server ワーカーノードを設定します。

ワーカーノードを静的プロキシーリストで設定するには、以下を実行します。

  1. mod_cluster リスナーを定義し、動的プロキシー検出を無効にします。

    JWS_HOME/tomcat<VERSION>/conf/server.xml を編集し、ModClusterListenerListener 要素を追加するか、変更します。advertise プロパティーを false に設定します。例を以下に示します。

    <Listener className="org.jboss.modcluster.container.catalina.standalone.ModClusterListener" advertise="false" stickySession="true" stickySessionForce="false" stickySessionRemove="true"/>
  2. 静的プロキシーサーバーリストを作成します。

    プロキシーのコンマ区切りリストを IP_ADDRESS:PORT 形式で proxyList プロパティーとして Listener に追加します。例を以下に示します。

    <Listener className="org.jboss.modcluster.container.catalina.standalone.ModClusterListener" advertise="false" stickySession="true" stickySessionForce="false" stickySessionRemove="true" proxyList="10.33.144.3:6666,10.33.144.1:6666"/>

第4章 Online Certificate Status Protocol

OCSP (Online Certificate Status Protocol) は、Web ブラウザーおよび Web サーバーがセキュアな接続上で通信できるようにする技術です。暗号化したデータは送信側から送信され、処理前に受信側で復号化されます。Web ブラウザーと Web サーバーは、データの暗号化および復号化を行います。

Web サーバーとの通信時に、サーバーは証明書形式でクレデンシャルのセットを表示します。次に、ブラウザーはその証明書が有効かどうかを確認し、証明書のステータス情報の要求を送信します。サーバーは、ステータスを current、expired、または unknown として返信します。証明書は通信の構文を指定し、開始時間、終了時間、OCSP レスポンダーにアクセスするためのアドレス情報などの制御情報が含まれます。Web サーバーは、OCSP レスポンダーまたは証明書に記載されているものを使用して、ステータスを確認できます。OCSP では、期限切れの証明書の猶予期間が許可されます。これにより、証明書更新前の限られた時間内でサーバーにアクセスできます。

OCSP は、証明書失効リスト (CRL) の古いメソッドの制限を解消します。OCSP の詳細は、『Red Hat Certificate System Planning, Installation, and Deployment Guide』を参照してください。

4.1. SSL 接続用の Apache HTTP サーバーの設定

  1. 以下のコマンドを使用して mod_ssl をインストールします。

    # yum install jbcs-httpd24-mod_ssl
  2. JBCS_HOME/httpd/conf.d/ssl.conf を編集し、ServerNameSSLCertificateFile、および SSLCertificateKeyFile を追加します。

    <VirtualHost _default_:443>
    ServerName www.example.com:443
    SSLCertificateFile /opt/rh/jbcs-httpd24/root/etc/pki/tls/certs/localhost.crt
    SSLCertificateKeyFile /opt/rh/jbcs-httpd24/root/etc/pki/tls/private/localhost.key
    • ServerName は、SSL 証明書の Common Name(CN) と一致する必要があります。ServerName が CN に一致しない場合、クライアントブラウザーはドメイン名不一致エラーを表示します。
    • SSLCertificateFile は、証明書 (公開鍵) に関連付けられた秘密鍵です。
    • 設定に従って、ssl.conf ファイルの Listen ディレクティブが正しいことを確認します。たとえば、IP アドレスが指定されている場合は、httpd サービスがバインドされる IP アドレスと一致する必要があります。
  3. 以下のコマンドを使用して Apache HTTP Server を再起動します。

    # service jbcs-httpd24-httpd restart

4.2. Apache HTTP サーバーでの Online Certificate Status Protocol の使用

HTTPS に Online Certificate Status Protocol (OCSP) を使用する前に、SSL 接続用に Apache HTTP サーバーを設定 していることを確認してください。

Apache HTTP Server で OCSP を使用するには、認証局 (CA) および OCSP Responder が正しく設定されていることを確認してください。

CA の設定方法の詳細は、『Red Hat Enterprise Linux 7 Linux Domain Identity, Authentication, and Policy Guide』の「Managing Certificates and Certificate Authorities」を参照してください。

OCSP Responder の設定方法の詳細は、『Red Hat Enterprise Linux 7 Linux Domain Identity, Authentication, and Policy Guide』の「Configuring OCSP Responders」を参照してください。

注記

認証局が OCSP 証明書を発行できることを確認します。認証局は、次の属性を証明書に追加できる必要があります。

[ usr_cert ]
...
authorityInfoAccess=OCSP;URI:http://HOST:PORT
...
[ v3_OCSP ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = OCSP Signing

HOST および PORT は、設定する OCSP レスポンダーの詳細に置き換える必要があります。

4.3. OCSP 証明書を検証する Apache HTTP Server の設定

Apache HTTP Server を設定して OCSP 証明書を検証する前に、認証局 (CA) と OCSP Responder が正しく設定されていることを確認してください。以下の例は、クライアント証明書の OCSP 検証を有効にする方法を示しています。

SSLOCSPEnable 属性を使用して OCSP 検証を有効にします。

# Require valid client certificates (mutual auth)
  SSLVerifyClient require
  SSLVerifyDepth  3
  # Enable OCSP
  SSLOCSPEnable on
  SSLOCSPDefaultResponder http://10.10.10.25:3456
  SSLOCSPOverrideResponder on

4.4. OCSP 設定の確認

OpenSSL コマンドラインツールを使用して、設定を検証できます。

# openssl ocsp -issuer cacert.crt -cert client.cert -url http://HOST:PORT -CA ocsp_ca.cert -VAfile ocsp.cert
  • -issuer は認証局の証明書です。
  • -cert は検証する必要のあるクライアント証明書です。
  • -url は、HTTP サーバー検証証明書 (OCSP) です。
  • -CA は、Apache HTTP Server サーバー証明書を検証する CA 証明書です。
  • -VAfile は OCSP レスポンダー証明書です。

第5章 完全な作業例

5.1. mod_cluster の例

本セクションでは、Red Hat Enterprise Linux システムで mod_cluster を使用する方法の完全な実例の設定例を説明します。

ロードバランサー

JBoss Core Services を localhost 上でリッスンするプロキシーサーバーとして設定するには、JBCS_HOME/httpd/conf.d/mod_cluster.conf で設定ファイルを作成し、以下を追加します。

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>

Tomcat のワーカー設定

JWS_HOME/tomcat<VERSION>/conf/server.xml を編集し、以下の Listener 要素を追加して Tomcat ワーカーノードを設定します。

<Listener className="org.jboss.modcluster.container.catalina.standalone.ModClusterListener" advertise="true"/>

iptables ファイアウォールルールの例

以下は 192.168.1.0/24 サブネットのクラスターノードの iptables を使用したファイアウォールルールの例です。

/sbin/iptables -I INPUT 5 -p udp -d 224.0.1.0/24 -j ACCEPT -m comment --comment "mod_cluster traffic"
/sbin/iptables -I INPUT 6 -p udp -d 224.0.0.0/4 -j ACCEPT -m comment --comment "JBoss Cluster traffic"
/sbin/iptables -I INPUT 9 -p udp -s 192.168.1.0/24 -j ACCEPT -m comment --comment "cluster subnet for inter-node communication"
/sbin/iptables -I INPUT 10 -p tcp -s 192.168.1.0/24 -j ACCEPT -m comment --comment "cluster subnet for inter-node communication"
/etc/init.d/iptables save

5.2. mod_auth_kerb の例

本セクションでは、Red Hat Enterprise Linux で JBoss Core Services の Apache HTTP Server および mod_auth_kerb で Kerberos 認証を設定する基本的な手順を説明します。

5.2.1. mod_auth_kerb 例の要件

以下は、作業例の要件の一覧です。手順例を使用する前に、すべての要件を満たしていることを確認してください。

  • GSS がネゴシエートされたサポートで curl をインストールします (設定のテスト用)。
  • JBoss Core Services と同じホストで Kerberos または LDAP サーバー (ApacheDS など) を設定し、実行します。
  • LDAP サーバーを使用する場合は、以下の LDAP ユーザーを作成します。

    • krbtgt ユーザーを作成します。

      dn: uid=krbtgt,ou=Users,dc=example,dc=com
      objectClass: top
      objectClass: person
      objectClass: inetOrgPerson
      objectClass: krb5principal
      objectClass: krb5kdcentry
      cn: KDC Service
      sn: Service
      uid: krbtgt
      userPassword: secret
      krb5PrincipalName: krbtgt/EXAMPLE.COM@EXAMPLE.COM
      krb5KeyVersionNumber: 0
    • ldap ユーザーを作成します。

      dn: uid=ldap,ou=Users,dc=example,dc=com
      objectClass: top
      objectClass: person
      objectClass: inetOrgPerson
      objectClass: krb5principal
      objectClass: krb5kdcentry
      cn: LDAP
      sn: Service
      uid: ldap
      userPassword: randall
      krb5PrincipalName: ldap/localhost@EXAMPLE.COM
      krb5KeyVersionNumber: 0
    • HTTP ユーザーを作成します。

      dn: uid=HTTP,ou=Users,dc=example,dc=com
      objectClass: top
      objectClass: person
      objectClass: inetOrgPerson
      objectClass: krb5principal
      objectClass: krb5kdcentry
      cn: HTTP
      sn: Service
      uid: HTTP
      userPassword: secretpwd
      krb5PrincipalName: HTTP/localhost@EXAMPLE.COM
      krb5KeyVersionNumber: 0
    • ユーザー hnelson (テストユーザー) を作成します。

      dn: uid=hnelson,ou=Users,dc=example,dc=com
      objectClass: top
      objectClass: person
      objectClass: inetOrgPerson
      objectClass: krb5principal
      objectClass: krb5kdcentry
      cn: Horatio Nelson
      sn: Nelson
      uid: hnelson
      userPassword: secret
      krb5PrincipalName: hnelson@EXAMPLE.COM
      krb5KeyVersionNumber: 0

5.2.2. Kerberos クライアントの設定

  1. /etc ディレクトリーに krb5.conf 設定ファイルを作成し、以下をファイルに追加します。

    [logging]
      default = FILE:/var/log/krb5libs.log
      kdc = FILE:/var/log/krb5kdc.log
      admin_server = FILE:/var/log/kadmind.log
    
    [libdefaults]
      default_realm = EXAMPLE.COM
      default_tgs_enctypes = des-cbc-md5,des3-cbc-sha1-kd
      default_tkt_enctypes = des-cbc-md5,des3-cbc-sha1-kd
      dns_lookup_realm = false
      dns_lookup_kdc = false
      allow_weak_crypto = yes
      ticket_lifetime = 24h
      renew_lifetime = 7d
      forwardable = yes
    
    [realms]
      EXAMPLE.COM = {
        kdc = localhost:60088
        admin_server = localhost:60088
      }
    
    [domain_realm]
      .example.com = EXAMPLE.COM
      example.com = EXAMPLE.COM
  2. 以下の内容を含む JBCS_HOME/httpd/conf ディレクトリーにキータブを作成します。

    # ktutil
    ktutil: addent -password -p HTTP/localhost@EXAMPLE.COM -k 0 -e des-cbc-md5
    Password for HTTP/localhost@EXAMPLE.COM: secretpwd
    ktutil: list
    slot KVNO Principal
    ---- ---- ---------------------------------------------------------------------
       1    0               HTTP/localhost@EXAMPLE.COM
    ktutil: wkt JBCS_HOME/httpd/conf/krb5.keytab
    ktutil: quit
重要

環境変数は ktutil プロンプト内では拡張されません。ユーザーは JBCS_HOME 変数の完全パスを置き換える必要があります。

root ユーザーとして以下のコマンドを実行し、正しいグループとパーミッションをキータブに適用します。

# chgrp apache JBCS_HOME/httpd/conf/krb5.keytab
# chmod 640 JBCS_HOME/httpd/conf/krb5.keytab
  1. 以下のホスト設定が /etc/hosts ファイルに含まれていることを確認します。

    127.0.0.1 localhost

5.2.3. mod_auth_kerb の設定

JBCS_HOME/httpd/conf.d/ ディレクトリーに auth_kerb.conf 設定ファイルを作成し、以下の設定をファイルに追加します。

#
# The mod_auth_kerb module implements Kerberos authentication over HTTP, following the "Negotiate" protocol.
#

# The LoadModule statement is done in conf.d/10-auth_kerb.conf
# LoadModule auth_kerb_module modules/mod_auth_kerb.so

<Location /kerberostest>
  AuthType Kerberos
  AuthName "Kerberos Login"
  KrbMethodNegotiate On
  KrbMethodK5Passwd Off
  KrbAuthRealms EXAMPLE.COM
  KrbServiceName HTTP
  Krb5KeyTab $JBCS_HOME/httpd/krb5.keytab
  require valid-user
</Location>
重要

環境変数は、設定ファイル内で拡張されません。ユーザーは JBCS_HOME 変数の完全パスを置き換える必要があります。

5.2.4. Kerberos 認証のテスト

  1. JBCS_HOME/httpd/www/html/kerberostest/auth_kerb_page.html という名前のテストページを作成します。
  2. 以下のコンテンツをテストページ (auth_kerb_page.html) に追加します。

    <html>
    <body>
        <h1>mod_auth_kerb successfully authenticated!</h1>
    </body>
    </html>
  3. オプション: JBCS_HOME/httpd/conf/httpd.conf でデバッグするログレベルを設定します。
  4. Apache HTTP Server を開始します。詳細は 『インストールガイド』 を参照してください。
  5. 以下のように認証をテストします。

    1. テストユーザー hnelson の Kerberos 認証を開始します。

      $ kinit hnelson
    2. テストユーザー hnelson の詳細を表示します。

      $ klist

      以下のような結果が表示されます。

      Ticket cache: FILE:/tmp/krb5cc_18602
      Default principal: hnelson@EXAMPLE.COM
      
      Valid starting     Expires            Service principal
      06/03/13 14:21:13  06/04/13 14:21:13  krbtgt/EXAMPLE.COM@EXAMPLE.COM
      renew until 06/10/13 14:21:13
    3. 以下のように Apache HTTP Server Kerberos 認証をテストします。

      $ curl --negotiate -u : http://localhost/kerberostest/auth_kerb_page.html

      正常に機能している場合は、以下の結果が表示されます。

      <html>
      <body>
          <h1>mod_auth_kerb successfully authenticated!</h1>
      </body>
      </html>

mod_auth_kerb の詳細は、http://modauthkerb.sourceforge.net/ を参照してください。

付録A Apache HTTP Server のリファレンス

A.1. Apache HTTP Server モジュール

このセクションでは、「mod_cluster コンポーネント」で説明されている Apache HTTP Server プロキシーモジュールの定義を拡張します。

A.1.1. mod_manager.so

クラスターマネージャーモジュール mod_manager は、ワーカーノードの登録、ワーカーノードの負荷データ、およびワーカーノードのアプリケーションのライフサイクルイベントなどのノードからメッセージを受信および確認します。

LoadModule manager_module modules/mod_manager.so

<VirtualHost> 要素の設定可能なディレクティブは以下のとおりです。

EnableMCPMReceive
VirtualHost がノードから (MCPM) を受信できるようにします。mod_cluster が正常に動作できるように、Apache HTTP Server 設定に EnableMCPMReceive ディレクティブを 1 つ追加します。advertise が設定された場所の VirtualHost 設定にEnableMCPMReceive を追加する必要があります。
MaxMCMPMaxMessSize
mod_cluster Management Protocol (MCMP) メッセージの最大サイズを定義します。デフォルト値は、他の Max ディレクティブから計算されます。最小値は 1024 です。
AllowDisplay
mod_cluster-manager メインページで追加表示を切り替えます。デフォルト値は off で、mod_cluster-manager メインページにはバージョン情報のみが表示されます。
AllowCmd
mod_cluster-manager URL を使用してコマンドのパーミッションを切り替えます。デフォルト値は on で、コマンドを許可します。
ReduceDisplay
mod_cluster-manager ページに表示される情報の縮減を切り替えます。情報を減らすと、ページでより多くのノードを表示できます。デフォルト値は off で、利用可能な情報をすべて表示することができます。
MemManagerFile
mod_manager が設定の詳細を保存するファイルの場所を定義します。mod_manager は、共有メモリーおよびロックファイルに生成された鍵にもこの場所を使用します。絶対パス名である必要があります。NFS 共有ではなく、ローカルドライブ上のこのパスを使用することが推奨されます。デフォルト値は /logs/ です。
Maxcontext
mod_cluster が使用するコンテキストの最大数。デフォルト値は 100 です。
Maxnode
mod_cluster が使用するワーカーノードの最大数。デフォルト値は 20 です。
Maxhost
mod_cluster が使用するホスト (エイリアス) の最大数。これは、ロードバランサーの最大数にもなります。デフォルト値は 20 です。
Maxsessionid
保存されたアクティブなセッション識別子の最大数。セッションから情報が 5 分間受信されない場合、セッションは非アクティブとみなされます。これはデモおよびデバッグの目的のみで使用されます。デフォルト値は 0 で、このロジックを無効にします。
ManagerBalancerName
ワーカーノードがロードバランサー名を指定しない場合に使用するロードバランサーの名前。デフォルト値は mycluster です。
PersistSlots
on に設定された場合、ノード、エイリアス、およびコンテキストはファイルに永続化されます。デフォルト値は off です。
CheckNonce

on に設定された場合、セッション識別子をチェックして、一意で、これまでに発生していないことを確認します。デフォルトは on です。

警告

このディレクティブを off に設定すると、サーバーがリプレイ攻撃に対して脆弱になります。

SetHandler mod_cluster-manager

ハンドラーを定義して、クラスター内のワーカーノードについての情報を表示します。これは、Location 要素で定義されます。

<Location $LOCATION>
  SetHandler mod_cluster-manager
  Require ip 127.0.0.1
</Location>

ブラウザーの Location 要素で定義された $LOCATION にアクセスすると、以下のような出力が表示されます。(この場合は、$LOCATIONmod_cluster-handler として定義されました。)

Transferred は、ワーカーノードに送信された POST データに一致します。Connected は、このステータスページが要求されたときに処理されたリクエストの数に対応します。Sessions はアクティブなセッションの数に対応します。Maxsessionid0 の場合、このフィールドは存在しません。

A.1.2. mod_proxy_cluster.so

プロキシーロードバランサーモジュール mod_proxy_cluster は、クラスターノードへの要求のルーティングを処理します。プロキシーバランサーは、クラスターのアプリケーションの場所、各クラスターノードの現在の状態、およびセッション ID (要求が確立されたセッションの一部である場合) に基づいて要求を転送するために適切なノードを選択します。

LoadModule proxy_cluster_module modules/mod_proxy_cluster.so

<VirtualHost> 要素に以下のディレクティブを設定して、負荷分散の動作を変更することもできます。

CreateBalancers

ロードバランサーが Apache HTTP Server の仮想ホストでどのように作成されるかを定義します。CreateBalancers では、以下の値が使用できます。

  • 0: Apache HTTP Server で定義されたすべての仮想ホストにロードバランサーを作成します。ProxyPass ディレクティブでロードバランサーを設定するのを忘れないようにしてください。
  • 1: バランサーを作成しません。この値を使用する場合は、ProxyPass または ProxyPassMatch にロードバランサー名を定義する必要もあります。
  • 2: メインサーバーのみ作成します。これは CreateBalancers のデフォルト値です。
UseAlias

定義された AliasServerName に対応するかどうかを定義します。UseAlias については、以下の値有効です。

  • 0: ワーカーノードのエイリアス情報を無視します。これは UseAlias のデフォルト値です。
  • 1: 定義されたエイリアスがワーカーノードのサーバー名に対応していることを確認します。
LBstatusRecalTime
ワーカーノードのステータスを計算するプロキシーの間隔 (秒単位) を定義します。デフォルトの間隔は 5 秒です。
ProxyPassMatch; ProxyPass

ProxyPass は、リモートサーバーをローカルサーバーの名前空間にマッピングします。ローカルサーバーに http://local.com/ のアドレスがある場合、ProxyPass ディレクティブは http://local.com/requested/file1 のローカルリクエストを http://worker.local.com/file1 のプロキシーリクエストに変換します。

ProxyPass /requested/ http://worker.local.com/

ProxyPassMatch は正規表現を使用して、プロキシーされた URL が適用されるローカルパスを照合します。

いずれかのディレクティブで、! は指定したパスがローカルであることを示します。そのパスのリクエストはリモートサーバーにルーティングしないでください。たとえば、以下のディレクティブは gif ファイルをローカルで提供するように指定します。

ProxyPassMatch ^(/.*\.gif)$ !

A.1.3. mod_advertise.so

mod_advertise.so は、UDP マルチキャストメッセージを介してプロキシーサーバーの存在をブロードキャストします。サーバーのアドバタイズメッセージには、プロキシーが負荷分散クラスターに参加するノードからの応答をリッスンする IP アドレスとポート番号が含まれます。

このモジュールは、VirtualHost 要素の mod_manager とともに定義する必要があります。以下の例の識別子は advertise_module です。

LoadModule advertise_module modules/mod_advertise.so

mod_advertise は、以下のディレクティブを使用して設定できます。

ServerAdvertise

アドバタイズメカニズムの使用方法を定義します。

デフォルト値は Off です。Off に設定すると、プロキシーはその場所を公開しません。

On に設定された場合、アドバタイズメカニズムを使用して、ワーカーノードがこのプロキシーにステータス情報を送信するように指示します。以下の構文でホスト名およびポートを指定することもできます: ServerAdvertise On http://HOSTNAME:PORT/これは、名前ベースの仮想ホストを使用する場合や、仮想ホストが定義されていない場合にのみ必要です。

AdvertiseGroup

アドバタイズするマルチキャストアドレスを定義します。構文は AdvertiseGroup ADDRESS:PORT です。ここでは、ADDRESSAdvertiseGroupAddress に一致し、PORT がワーカーノードの AdvertisePort に一致している必要があります。

ワーカーノードが JBoss EAP ベースで、起動時に -u スイッチが使用される場合、デフォルト値 AdvertiseGroupAddress-u スイッチ経由で渡されます。

デフォルト値は 224.0.1.105:23364 です。ポートが指定されていない場合、ポートはデフォルトで 23364 に設定されます。

AdvertiseFrequency
IP アドレスとポートをアドバタイズするマルチキャストメッセージの間隔 (秒単位)。デフォルト値は 10 です。
AdvertiseSecurityKey
JBoss Web Server で mod_cluster を特定するために使用される文字列を定義します。デフォルトでは、このディレクティブは設定されず、情報は送信されません。
AdvertiseManagerUrl
ワーカーノードが情報をプロキシーサーバーに送信するために使用する URL を定義します。デフォルトでは、このディレクティブは設定されず、情報は送信されません。
AdvertiseBindAddress
マルチキャストメッセージを送信するアドレスとポートを定義します。構文は AdvertiseBindAddress ADDRESS:PORT です。これにより、複数の IP アドレスを持つマシンにアドレスを指定できます。デフォルト値は 0.0.0.0:23364 です。

A.1.4. mod_proxy.so

mod_proxy.so は標準の Apache HTTP Server モジュールです。このモジュールにより、サーバーは AJP (Apache JServe Protocol)、FTP、CONNECT (SSL)、および HTTP で転送されるデータのプロキシーとして動作します。このモジュールに追加の設定は必要ありません。その識別子は proxy_module です。

ProxyIOBufferSize などの Mod_proxy ディレクティブは mod_cluster の設定に使用されます。

A.1.5. mod_proxy_ajp.so

mod_proxy_ajp.so は、AJP (Apache JServe Protocol) プロキシーのサポートを提供する標準の Apache HTTP Server モジュールです。このモジュールを使用するには、mod_proxy.so が必要です。

A.1.6. mod_cluster_slotmem

mod_cluster_slotmem には設定ディレクティブは必要ありません。

A.2. workers.properties

Apache HTTP Server ワーカーノードは、mod_jk ロードバランサーにマップされるサーブレットコンテナーです。ワーカーノードは JBCS_HOME/httpd/conf/workers.properties で定義されます。このファイルは、異なるサーブレットコンテナーの場所と、全体で呼び出しが負荷分散される方法を指定します。

workers.properties ファイルには、2 つのセクションが含まれます。

グローバルプロパティー
このセクションには、すべてのワーカーに適用されるディレクティブが含まれます。
ワーカープロパティー
このセクションには、各ワーカーに適用されるディレクティブが含まれます。

各ノードはワーカープロパティーの命名規則を使用して定義されます。ワーカー名には、小文字、大文字、数字、および特定の特殊文字 (_/) のみを含めることができます。

worker プロパティーの構造は worker.WORKER_NAME.DIRECTIVE です。

worker
すべてのワーカープロパティーの定数接頭辞。
WORKER_NAME
ワーカーに指定された任意の名前。たとえば、node1node_01Node_1 など。
DIRECTIVE
必要な特定のディレクティブ。

ワーカーノードの設定に必要な主なディレクティブは以下のとおりです。

注記

worker.properties 設定ディレクティブの完全リストは『Apache Tomcat Connector - Reference Guide』を参照してください。

worker.properties グローバルディレクティブ

worker.list

mod_jk によって使用されるワーカー名の一覧を指定します。この一覧のワーカーは、要求をマップするために利用できます。

注記

ロードバランサーによって管理されない単一ノード設定は worker.list=WORKER_NAME に設定する必要があります。

workers.properties 必須ディレクティブ

type

ワーカーに適用されるディレクティブを決定するワーカーのタイプを指定します。デフォルト値は ajp13 です。これは、Web サーバーと Apache HTTP Server 間の通信に選択するワーカータイプです。

その他の値には、lb および status が含まれます。

AJPv13 の詳細は、『Apache Tomcat Connector - AJP Protocol Reference』 を参照してください。

workers.properties 接続ディレクティブ

host

ワーカーのホスト名または IP アドレス。ワーカーノードは ajp13 プロトコルスタックをサポートする必要があります。デフォルト値は localhost です。

ホスト名または IP アドレスの後にポート番号を追加すると、port ディレクティブを host ディレクティブの一部として指定できます。たとえば、worker.node1.host=192.168.2.1:8009 または worker.node1.host=node1.example.com:8009 のようになります。

port
定義されたプロトコルリクエストをリッスンしているバックエンドサーバーインスタンスのポート番号。デフォルト値は 8009 で、AJPv13 ワーカーのデフォルトのリッスンポートです。
ping_mode

現在のネットワークの正常性に対して接続がプローブされる条件を指定します。

プローブは、CPing に空の AJPv13 パケットを使用し、指定のタイムアウト内で CPong を返すことを想定します。

ディレクティブフラグの組み合わせを使用して条件を指定します。フラグはカンマ区切りではありません。たとえば、正しいディレクティブフラグセットは worker.node1.ping_mode=CI です。

C - Connect (接続)。
サーバーへの接続後に接続がプローブされるよう指定します。connect_timeout ディレクティブを使用してタイムアウトを指定します。指定しない場合は、ping_timeout の値が使用されます。
P (プレポスト)
各リクエストをサーバーに送信する前に接続がプローブされることを指定します。prepost_timeout ディレクティブを使用してタイムアウトを指定します。指定しない場合は、ping_timeout の値が使用されます。
I - Interval (間隔)。
定期的な内部メンテナンスサイクル中に接続がプローブされることを指定します。connection_ping_interval ディレクティブを使用してインターバルでアイドルのタイムアウトを指定します。指定しない場合は、ping_timeout の値が使用されます。
A - All (すべて)。
すべてのディレクティブフラグが適用されることを指定する最も一般的な設定。高度なディレクティブ \*_timeout の詳細は、『Apache Tomcat Connector - Reference Guide』を参照してください。
ping_timeout
CPing 接続プローブへの CPong 応答を待つ時間を指定します (ping_mode を参照)。デフォルトの値は 10000 ミリ秒です。

worker.properties 負荷分散ディレクティブ

lbfactor

個別のワーカーの負荷分散係数を指定します。ロードバランサーのメンバーワーカーにのみ指定されます。

このディレクティブは、クラスター内の他のワーカーと比較して、ワーカーに分散される HTTP 要求負荷の相対量を定義します。

このディレクティブが適用される一般的な例は、クラスターで処理能力の高いサーバーを他のサーバーと区別する場合です。たとえば、あるワーカーに他のワーカーの 3 倍の負荷を割り当てる場合は worker.WORKER_NAME.lbfactor=3 を指定します。

balance_workers
ロードバランサーが管理する必要があるワーカーノードを指定します。ディレクティブは同じロードバランサーに複数回使用でき、workers.properties ファイルに指定されるワーカー名のコンマ区切りリストで構成されます。
sticky_session

SESSION ID を持つワーカーのリクエストが同じワーカーにルーティングされるかどうかを指定します。デフォルトは 0 (false) です。1 (true) に設定すると、ロードバランサーの永続性が有効になります。

たとえば、worker.loadbalancer.sticky_session=0 を指定する場合、各要求はクラスター内の各ノード間で負荷分散されます。つまり、同じセッションの異なるリクエストは、サーバーの負荷に基づいて異なるサーバーに送信できます。

worker.loadbalancer.sticky_session=1 を指定した場合は、セッションが終了するまで各セッションが 1 台のサーバーに永続化されます (そのサーバーが使用可能な場合)。

付録B ワーカーノードのリファレンス

B.1. ワーカー設定

設定値は、以下の条件下でプロキシーに送信されます。

  • サーバーの起動時。
  • プロキシーがアドバタイズメカニズムで検出される場合。
  • エラーが発生すると、プロキシーの設定がリセットされます。

表B.1 Tomcat のプロキシー設定値

デフォルト説明

stickySession

true

あるセッションの後続リクエストを可能な限り同じノードへルーティングするべきかどうかを指定します。

stickySessionRemove

false

バランサーがリクエストをスタックしたノードへルーティングできない場合、Apache HTTP Server プロキシーがセッションのスティッキネスを削除するかどうかを指定します。stickySessionfalse の場合は、このプロパティーは無視されます。

stickySessionForce

true

バランサーがリクエストをスタックしたノードへルーティングできない場合、Apache HTTP Server プロキシーがエラーを返すかどうかを指定します。stickySessionfalse の場合は、このプロパティーは無視されます。

workerTimeout

-1

リクエストを処理するためにワーカーが利用可能になるまで待機する秒数を指定します。バランサーのすべてのワーカーが使用できなくなると、しばらく (workerTimeout/100) した後に mod_cluster を再試行して使用可能なワーカーを見つけます。-1 の値は、Apache HTTP Server がワーカーが利用可能になるまで待機せず、利用可能なワーカーがない場合にエラーを返すことを示します。

maxAttempts

1

Apache HTTP Server プロキシーがワーカーに指定のリクエストの送信を試みる回数を指定します。この回数試行した後に送信を断念します。最小値は 1 で、1 回送信を試みた後、断念します。

flushPackets

false

パケットのフラッシュが有効または無効化されるかどうかを指定します。

flushWait

-1

パケットをフラッシュするまでの待機時間を指定します。-1 を値として指定すると、永久に待機します。

ping

10

ping に対する pong 応答を待つ時間 (秒単位)。

smax

 

soft maximum アイドル接続数 を指定します。最大値は Apache HTTP Server スレッド設定 (ThreadsPerChild または 1) によって決まります。

ttl

60

smax しきい値を超えるアイドル接続の期間 (秒単位) を指定します。

nodeTimeout

-1

エラーを返す前に、バックエンドサーバーの応答を待つ時間 (秒単位) の mod_cluster を指定します。mod_cluster は、リクエストを転送する前に常に cping/cpong を使用します。mod_cluster によって使用される connectiontimeout 値は、ping の値です。

balancer

mycluster

ロードバランサーの名前を指定します。

loadBalancingGroup

 

同じ負荷分散グループ内の jvmRoutes 間の負荷分散を指定します。loadBalancingGroup はドメインディレクティブと論理的に同等です。

B.2. mod_cluster Proxy および Proxy Discovery 設定属性

以下の表には、mod_cluster プロキシーおよびプロキシー検出設定属性の属性および情報が含まれます。

表B.2 mod_cluster プロキシー検出設定属性

属性プロパティーデフォルト値

proxy-list

proxyList

 

proxy-url

proxyURL

 

advertise

advertise

true

advertise-security-key

advertiseSecurityKey

 

excluded-contexts

excludedContexts

 

auto-enable-contexts

autoEnableContexts

true

stop-context-timeout

stopContextTimeout

10 秒 (秒単位)

socket-timeout

nodeTimeout

20 秒 (ミリ秒単位)

注記

nodeTimeout が定義されていない場合は、ProxyTimeout ディレクティブ Proxy が使用されます。ProxyTimeout が定義されていない場合は、サーバーのタイムアウト (Timeout) が使用されます (JBCS httpd.conf ではデフォルトで 120 秒)。nodeTimeoutProxyTimeout、および Timeout はソケットレベルで設定されます。

表B.3 mod_cluster プロキシー設定属性

属性プロパティーデフォルト値

sticky-session

stickySession

true

sticky-session-remove

stickySessionRemove

false

sticky-session-force

stickySessionForce

true

node-timeout

workerTimeout

-1

max-attempts

maxAttempts

1

flush-packets

flushPackets

false

flush-wait

flushWait

-1

ping

ping

10 (秒)

smax

smax

-1 (デフォルト値を使用)

ttl

ttl

-1 (デフォルト値を使用)

domain

loadBalancingGroup

 

load-balancing-group

loadBalancingGroup

 

B.3. 負荷設定

以下の表に、mod_cluster が Tomcat で設定されている場合に使用される追加の設定プロパティーを示します。

表B.4 Tomcat の負荷設定

属性デフォルト値説明

loadMetricClass

org.jboss.modcluster.load.metric.impl.BusyConnectorsLoadMetric

org.jboss.load.metric.LoadMetric を実装するオブジェクトのクラス名。

loadMetricCapacity

1

loadMetricClass プロパティーにより定義された負荷メトリクスの容量。

loadHistory

9

負荷分散係数の計算で考慮する必要のある、過去の負荷値の数。

loadDecayFactor

2

この値で過去の負荷値が減少されます。

法律上の通知

Copyright © 2021 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.