ロードバランサーはTomcatと直接通信しないワーカーです。代わりに、それは「実」ワーカー、つまりロードバランサーのメンバーまたはサブワーカーと呼ばれる複数のワーカーの管理を担当します。
この管理には以下が含まれます
- Webサーバーでワーカーをインスタンス化すること。
- ワーカーのロードバランシング係数を使用して、重み付けされたロードバランシング(ターゲットの定義された強度に応じて負荷を分散すること)を実行すること。
- 同じセッションに属するリクエストを同じTomcat上で実行し続けること(セッションのスティッキーネス)。
- 障害が発生したTomcatワーカーを特定し、それらへのリクエストを一時停止し、代わりにロードバランサーによって管理されている他のワーカーにフェイルオーバーすること。
- ステータスワーカーインターフェースを介して、ロードバランサー自体とすべてのメンバーのステータスと負荷メトリックを提供すること。
- ステータスワーカーインターフェースを介して、ロードバランシングを動的に再構成することを許可すること。
同じロードバランサーワーカーによって管理されるワーカーは、ロードバランシングされ(設定されたバランシング係数と現在のリクエストまたはセッション負荷に基づいて)、また同じロードバランサーの他のメンバーへのフェイルオーバーを提供することで障害から保護されます。そのため、単一のTomcatプロセスが停止しても、サイト全体が「停止」することはありません。
ロードバランサーが提供する機能の中には、単一のメンバーワーカー(ロードバランシングが不可能な場合)のみで動作する場合でも興味深いものがあります。
基本的なロードバランサーのプロパティ
ワーカーは、そのワーカーのtype
をlbに設定することでロードバランサーとして構成されます。
以下の表は、ロードバランサーワーカーの設定に使用されるいくつかのプロパティを示します
- balance_workersは、ロードバランサーのメンバーワーカーの名前をコンマで区切ったリストです。これらのワーカーは通常、タイプajp13です。メンバーワーカー自体が
worker.list
プロパティに現れる必要はなく、ロードバランサーをそこに追加するだけで十分です。 - sticky_sessionは、セッションIDを持つリクエストがセッションを作成した同じTomcatインスタンスにルーティングされるべきかどうかを指定します。Tomcatが複数のTomcatインスタンス間でセッションデータを共有できるセッションマネージャーを使用している場合、またはアプリケーションがステートレスである場合は、sticky_sessionをfalseに設定できます。デフォルトではsticky_sessionはtrueに設定されています。
- lbfactorは、各メンバーワーカーに追加して、メンバーごとの個別の強度を設定できます。
lbfactor
が高いほど、そのワーカーにより多くのリクエストがバランスされます。係数は整数で指定する必要があり、負荷は指定された係数に比例して分散されます。係数が高いほど、より多くのリクエストが処理されます。
# The load balancer worker balance1 will distribute
# load to the members worker1 and worker2
worker.balance1.type=lb
worker.balance1.balance_workers=worker1, worker2
worker.worker1.type=ajp13
worker.worker1.host=myhost1
worker.worker1.port=8009
worker.worker2.type=ajp13
worker.worker1.host=myhost2
worker.worker1.port=8009
jvmRoute
属性の値としてTomcatインスタンスの名前を設定する必要があります。Tomcatの名前は、対応するロードバランサーメンバーの名前と一致している必要があります。上記の例では、「myhost1」上のTomcatにはjvmRoute="worker1"
が必要で、「myhost2」上のTomcatにはjvmRoute="worker2"
が必要です。すべてのロードバランサー設定属性の完全なリファレンスについては、ワーカーのリファレンスを参照してください。
高度なロードバランサーワーカープロパティ
ロードバランサーは、複雑なトポロジとフェイルオーバー構成をサポートしています。メンバー属性distance
を使用すると、メンバーをグループ化できます。ロードバランサーは常に、最も低い距離のメンバーにリクエストを送信します。それらがすべて破損した場合にのみ、次に高い設定距離のメンバーにバランスします。これにより、異なるデータセンターロケーションにあるTomcatインスタンス間に優先順位を定義できます。
共有セッションで作業する場合、セッションレプリケーションまたは永続的なセッションマネージャー(データベース経由など)を使用すると、Tomcatファームをレプリケーショングループに分割することがよくあります。メンバーに障害が発生した場合、ロードバランサーはどの他のメンバーがセッションを共有しているかを知る必要があります。これはdomain
属性を使用して設定されます。同じドメインを持つすべてのワーカーはセッションを共有していると見なされます。
メンテナンス目的で、ロードバランサーに一部のメンバーで新しいセッションを許可しない、またはまったく使用しないように指示できます。これはメンバー属性activation
によって制御されます。値Activeはメンバーの通常の使用を許可し、disabledは新しいセッションを作成しませんが、スティッキーリクエストは引き続き許可し、stoppedはメンバーにリクエストを送信しなくなります。メンテナンスの少し前にアクティベーションを「active」から「disabled」に切り替えると、ワーカー上のセッションが枯渇し、中断が最小限に抑えられます。アプリケーションの使用パターンに応じて、枯渇には数分から数時間かかります。メンテナンス直前にワーカーを「stopped」に切り替えると、mod_jkによる誤ったエラーのロギングが減少します。
最後に、activation
をdisabledに設定し、他のワーカーにredirect
属性を追加することで、ホットスペアワーカーを構成することもできます
# The advanced router LB worker
worker.list=router
worker.router.type=lb
worker.router.balance_workers=worker1,worker2
# Define the first member worker
worker.worker1.type=ajp13
worker.worker1.host=myhost1
worker.worker1.port=8009
# Define preferred failover node for worker1
worker.worker1.redirect=worker2
# Define the second member worker
worker.worker2.type=ajp13
worker.worker2.host=myhost2
worker.worker2.port=8009
# Disable worker2 for all requests except failover
worker.worker2.activation=disabled
worker1のredirect
フラグは、worker1に問題がある場合に、ロードバランサーがリクエストをworker2にリダイレクトするように指示します。他のすべての場合、worker2はリクエストを受け取らないため、ホットスタンバイのように機能します。
activation
をdisabledに設定することに関する最後の注意:リクエストと共に送られてくるセッションIDは、リクエストURLの一部(;jsessionid=...
)として、またはクッキーを介して送信されます。ブックマークや長時間実行されているブラウザを使用している場合、無効化されたメンバーを指す古い無効なセッションIDを含むリクエストを送信する可能性があります。ロードバランサーは有効なセッションのリストを持っていないため、リクエストを無効化されたメンバーに転送します。したがって、ドレインには予想よりも時間がかかります。このようなケースを処理するには、WebアプリケーションにServletフィルターを追加し、リクエスト属性JK_LB_ACTIVATION
をチェックすることができます。この属性には、「ACT」、「DIS」、「STP」のいずれかの文字列が含まれます。「DIS」を検出し、リクエストのセッションがアクティブでなくなった場合は、セッションクッキーを削除し、自己参照URLを使用してリダイレクトします。リダイレクトされたリクエストはセッション情報を持たなくなるため、ロードバランサーはそれを無効化されたワーカーに送信しなくなります。リクエスト属性JK_LB_ACTIVATION
はバージョン1.2.32で追加されました。
ステータスワーカーのプロパティ
ステータスワーカーはTomcatと通信しません。代わりに、ワーカーの管理を担当します。ロードバランサーワーカーと組み合わせると特に便利です。
# Add the status worker to the worker list
worker.list=jkstatus
# Define a 'jkstatus' worker using status
worker.jkstatus.type=status
次に、jkstatusワーカーにリクエストをマウントします。Apache HTTPサーバーの場合は以下を使用します
# Add the jkstatus mount point
JkMount /jkmanager/* jkstatus
より高いレベルのセキュリティを得るには、以下を使用します
# Enable the JK manager access from localhost only
<Location /jkmanager/>
JkMount jkstatus
Require ip 127.0.0.1
</Location>