Jira Data Center ロード バランサの例

ロードバランシング スティッキーネス戦略

Jira には、スティッキー HTTP セッションが必要です。これに cookie 戦略アプローチを使用することで、ネットワークや VPN の構成によって発生するユーザー IP の変更をよりうまく制御することができます。
最低でも、ブラウザー セッション中にはユーザーがサーバーにスティッキーとなる必要があります。最適な配信/スティッキーネス率を実現するには、有効期限なしまたは有効期限 = -1 でセッション cookie 寿命を使用します。 

次の例は、cookie と Apache 2.2. 24、および他のロードバランサソリューションと同様にmod_proxy_balancer を使用したセッション スティッキーネス戦略を示しています。例ではバックエンドに HTTP を使用していますが、AJP コネクタにも同様に適用されます。 

1) 固有のロード バランシング cookie

この方法は、同じセッションのすべてのリクエストを同じバックエンド サーバーにルーティングする特有の cookie をロードバランサが作成する場合、負担が少ないアプローチです。
この例では、Apache に対して、ROUTEID と呼ばれる cookie を作成し、stickysession で使用するよう指示します。

mod_proxy_balancer と特有の cookie

Header add Set-Cookie "ROUTEID=.%{BALANCER_WORKER_ROUTE}e; path=/" env=BALANCER_ROUTE_CHANGED

<Proxy balancer://jira-cluster>

    BalancerMember http://backend1:8090 route=perftest1

    BalancerMember http://backend2:8090 route=perftest2

</Proxy>

ProxyPass / balancer://jira-cluster/ stickysession=ROUTEID

2) Tomcat JSESSIONID の cookie

Tomcat は -DjvmRoute=<nodeName> パラメーターで開始した場合、JSESSIONID cookie のルーティング情報をサポートします。この情報は Apache でも使用されます。

mod_proxy_balancer と JSESSIONID cookie

<Proxy balancer://jira-cluster>
    BalancerMember http://backend1:8090 route=perftest1
    BalancerMember http://backend2:8090 route=perftest2
</Proxy>
ProxyPass / balancer://jira-cluster/ stickysession=JSESSIONID

ユーザーが Jira にアクセスすると、次の cookie が作成されます:

ルート情報は、JSESSIONID 値のサフィックスとして追加されます

2b) HA プロキシの例*

次の例は、ロードバランサ (Tomcat ではない) によって、スティッキーネスを提供する JSESSIONID cookie が変更される仕組みを示しています。HAProxy はユーザー ブラウザーに cookie を送信する際にプレフィックスを追加し、バックエンド サーバーへルーティングする際に、プレフィックスを削除します。このアプローチでは、jvmRoute パラメーターを追加する必要はありません。

HAProxy cookie のプレフィックス構成

frontend ft_web
  bind 0.0.0.0:80
  default_backend bk_web
  
backend bk_web
  balance roundrobin
  cookie JSESSIONID prefix nocache
  server s1 backend1:8090 check cookie s1
  server s2 backend2:8090 check cookie s2

ユーザーが Jira にアクセスすると、次の cookie が作成されます:

ルート情報は、JSESSIONID 値のプレフィックスとして追加されます

ロードバランシング ヘルス チェック URL

通常、ロード バランサでは、自動的にプールからバックエンドを削除するため、バックエンドの正常性を常に確認するための URL が必要です。これには安定しており高速であるが不要なリソースを消費しない程度に十分軽量な URL を使用することが重要です。
Jira はこれに使用できるシステム ステータスを返す URL を表示します。 

{"state":"RUNNING"}

1 つのノードがダウンした場合のユーザー エクスペリエンス

ノードがダウンした場合、ユーザーに与える影響は、ロードバランサが、バックアップ サーバーの稼働を確認する点検間隔のサイズによって異なります。

チェック間隔が 1 分間で、ユーザーがスティッキーとなっているサーバーがダウンすると、ロードバランサがプールからノードを削除して新しいノードをユーザーに割り当てるまで、エラーメッセージが表示されます。ユーザー セッションが、あるサーバーから別のサーバーへ移動すると、ログイン資格情報を含むすべてのセッションが失われます。「ログイン情報を記憶する」を選択している場合を除き、ユーザーは再びログインする必要があります (Jira Cookiesを参照)。セッション データに依存する機能はほんの一握りですが、ほとんどが複数のステップでのウィザードです (一括更新やプロジェクトのインポートなど)。