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

弊社では公式にどのロードバランサもサポートしていませんが、多くのお客様が Apache または F5 を使用しています。


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

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


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

Cookie 名
Cookie 値
ドメイン
パス
有効期限
作成元
JESESSIONID DDFACF910F0F807930AE2A382956018F backend1 /jira/ セッション バックエンドの Tomcat
ROUTEID .perftest1 backend1 / セッション apache


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 が作成されます:

Cookie 名
Cookie 値
ドメイン
パス
有効期限
作成元
JSESSIONID 9CA086750138E6FC6965D1A82E652E96.perftest1 backend1 /jira/ セッション バックエンドの Tomcat

ルート情報は、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


*「 永続性にアプリケーション cookie を使用する」セクションの「ロードバランシング、アフィニティ、永続性、スティッキーセッションの例: 知っておくべきこと」の例。

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

Cookie 名
Cookie 値
ドメイン
パス
有効期限
作成元
JSESSIONID 9CA086750138E6FC6965D1A82E652E96 backend1 /jira/ セッション バックエンドの Tomcat
JSESSIONID s1~9CA086750138E6FC6965D1A82E652E96 backend1 /jira/ セッション HAproxy によって更新

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

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

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

URL
期待される内容
予想 HTTP ステータス
http://backend1/status
{"state":"RUNNING"}
200 OK


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

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

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


アトラシアンの Web サイトで、Jira Software Data Center および Jira Service Desk Data Center の詳細をご確認ください。

最終更新日 2019 年 5 月 10 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.