Jira Data Center をクラスタで実行する

このページの内容

お困りですか?

アトラシアン コミュニティをご利用ください。

コミュニティに質問

Jira Data Center では複数の Jira ノードのクラスタを実行して、高可用性、拡張のためのキャパシティ、および大規模環境でのパフォーマンスを実現できます。このガイドでは、クラスタ化のメリットについて説明し、クラスタ化された環境で Jira を実行するために必要な情報の概要を提供します。

準備はよろしいですか?Jira Data Center クラスタのセットアップ」をご覧ください。

クラスタ化のメリット

クラスタリングは、連続アップタイム、すぐに利用できる拡張性、および高負荷下でのパフォーマンスを必要とする、大規模およびミッションクリティカルな Data Center デプロイメントを使用しているエンタープライズ向けに設計されています。

メリットの一部をご紹介します。

  • 高可用性とフェイルオーバー
    クラスタのいずれかのノードがダウンした場合、他のノードが負荷を引き受け、ユーザーは中断されることなく Jira にアクセスできます。

  • 大規模環境でのパフォーマンス
    クラスタにノードを追加すると、許容される同時ユーザー接続数が増え、ユーザーのアクティビティが増えた場合の応答時間が改善されます。

  • 即時に拡張可能
    ダウンタイムや追加のライセンス料金なしでクラスタに新しいノードを追加できます。インデックスとアプリは自動的に同期されます。

アーキテクチャ

次の画像は、一般的な構成を示しています。

クラスタ化された Data Center のアーキテクチャ。

Jira Data Center クラスタは以下で構成されます。

  • JIra Data Center を実行する複数の同一のアプリケーション ノード。

  • トラフィックをすべてのアプリケーション ノードに分散するロード バランサ。

  • 添付ファイルやその他の共有ファイルを保存する共有ファイル システム。 

  • すべてのノードが読み取るおよび書き込むデータベース

すべてのアプリケーション ノードがアクティブ状態にあり、リクエストを処理します。ユーザーは、セッションのタイム アウト、ログアウト、またはクラスタからノードが削除されるまで、すべてのリクエストで同じ Jira ノードにアクセスします。 

詳細

ライセンス

Data Center ライセンスは、ノードの数ではなくクラスタのユーザー数に基づきます。つまり、新しいサーバーや CPU に追加のライセンス料金は発生せず、いつでも環境を拡張できます。

管理コンソールのバージョンおよびライセンスページで、利用可能なライセンス数を監視できます。

このプロセスを自動化する(たとえば、割り当て限界に近づいた場合にアラートを送信する)場合は、REST API を使用することができます。

利用可能な機能やインフラストラクチャは、Jira ライセンスによって決定されます。Server ライセンスと Data Center ライセンスの違いの完全な一覧については、「Jira Server と Data Center の機能の比較」を参照してください。 

ホーム ディレクトリ

Jira をクラスタで実行するには、追加のホーム ディレクトリである "共有ホーム" が必要です。

各 Jira ノードには、ログ、キャッシュ、Lucene インデックス、および設定ファイルを含むローカル ホームがあります。他のすべてのデータは共有ホームに格納され、クラスタ内の各 Jira ノードからアクセスすることができます。

ローカル ホームと共有ホームの内容の概要は次のとおりです。

ローカル ホーム共有ホーム
  • logs
  • caches
  • Lucene インデックス
  • 設定ファイル
  • plugins
  • attachments
  • アバター / プロフィール写真
  • アイコン
  • エクスポート ファイル
  • インポート ファイル
  • plugins
  • クラスタのステータスと同期データ
キャッシング

Jira Data Center では、キャッシュ変更はノード間でレプリケートされ、すべての同期状態が維持されます。非同期キャッシュ レプリケーションを使用しているため、変更直後に変更のレプリケートが行われることはありません。変更はローカル キュー (各ノードには他の各ノード用のローカル キューがあります) に追加され、キュー内の順序に基づいてレプリケートされます。このアプローチを使用することで、クラスタの安定性を向上させ、キャッシュ不一致の量を減らし、レプリケーション自体を他のキャッシュ変更から分離して、プロセス全体を簡素化して速度を向上させます。

詳細については、「Jira Data Center のキャッシュ レプリケーション」をご参照ください。

インデックス

個々の Jira アプリケーション ノードは、インデックスの完全なコピーを自身で保存します。ジャーナル サービスが各インデックスの同期状態を保持します。

初めてクラスタをセットアップする場合、インデックスを含むローカル ホーム ディレクトリを1つ目のノードから新しい各ノードにコピーします。

既存のクラスタに新しい Jira のノードを追加するときは、新しいノードに既存のノードのローカル ホーム ディレクトリをコピーします。新しいノードを起動すると、Jira は、インデックスが最新のものかどうかを確認します。最新ではない場合、共有ホーム ディレクトリまたは実行中のノード (ビルド番号が一致するもの) にインデックスのリカバリ スナップショットを要求し、起動プロセスを続行する前にそれをインデックス ディレクトリに展開します。スナップショットが生成できないか、時間内に新しいノードで受信されない場合、既存のインデックス ファイルが削除され、Jira は完全な再インデックスを実行します。

Jira ノードが短時間 (数時間) クラスタから切断された場合、クラスタに再接続した際にジャーナル サービスを使用して最新のインデックスのコピーを取得できます。ノードが長時間 (数日) ダウンした場合、Lucene インデックスは失効し、ノードの起動プロセスの一部として、既存のノードにリカバリ スナップショットをリクエストします。 

すべてのノードのインデックスに問題がある疑いがある場合は、一時的に残りの各ノードに新しいインデックスをコピーし、そのノード上のインデックスを再構築し、1ノード上のインデックスの回復を無効にすることができます。  

詳細については、「Jira Data Center の検索インデックス」を参照してください。

ClusterLocks

アクションが 1 つのノードでのみ実行される必要がある場合 (例: スケジュールされたジョブまたは日次のメール通知の送信)、Jira はクラスタ ロックを使用して、そのアクションが 1 つのノードでのみ実行されるようにします。  

クラスタ ロックは取得後、ノード別に解放されます。1 つのノードがオフラインになったときにクラスタ ロックによってクラスタ全体がブロックされないよう、ロックを取得したノードが引き続きアクティブであるかどうかを定期的に確認するハートビート メカニズムを使用しています。このメカニズムは必要に応じてロックを解放できます。

クラスタ ノード検出

クラスタ ノードを設定する場合、各クラスタノードの IP アドレスかマルチキャスト アドレスのいずれかを指定します。

マルチキャストを使用する場合:

Jira はマルチキャスト ネットワーク アドレスでジョイン リクエストをブロードキャストします。Jira はこのマルチキャスト アドレスで UDP ポートを開くことができる必要があります。これが行えない場合、他のクラスタ ノードを検出できません。ノードが検出されると、それぞれのノードは、キャッシュ更新のために接続できるユニキャスト (通常の) IP アドレスとポートで応答します。Jira は他のノードとの通常の通信のために、UDP ポートを開くことができる必要があります。

マルチキャスト アドレスはクラスタ名から自動生成されるか、最初のノードのセットアップ時に自分で入力することができます。 

インフラストラクチャと要件

ハードウェアやインフラの選択はあなた次第です。以下はハードウェアおよびインフラストラクチャ要件を計画するときに考える必要がある領域です。

AWS および Azure に Jira Data Center をデプロイする

AWS または Azure で Jira Data Center を実行する予定がある場合、アトラシアンのテンプレートを使用してインフラストラクチャ全体をデプロイできます。Jira Data Center ノード、データベース、およびストレージのすべてが数分で構成され、使用できるようになります。詳しくは、次のリソースをご覧ください。

サーバー要件

Jira と同じサーバーで他のアプリケーション (コア オペレーティング システム サービスを除く) を実行しないでください。アトラシアン ソフトウェアの専用サーバーでの Jira、Confluence、および Bamboo の実行は、小規模なインストールではうまく動作しますが、大規模に実行する場合はうまくいきません。 

Jira Data Center は仮想マシンで正常に実行できます。

クラスタ ノードの要件

各ノードはまったく同じである必要はありませんが、一貫性のあるパフォーマンスのために、可能な限り同質になるようにします。すべてのクラスタ ノードは以下を満たす必要があります。

  • 同じデータ センターまたはリージョン内にあること (AWS と Azure の場合)
  • 同じ Jira バージョンを実行していること
  • 同じ OS、Java、およびアプリケーション サーバー バージョン
  • 同じメモリ設定(JVM と物理メモリの両方)(推奨)
  • 同じタイムゾーンで設定されている(および現在の同期された時間を維持する)。これを保証するには ntpd または同様なサービスを使用することをお勧めします。

クラスタで発生するさまざまな問題を回避するため、ノードのクロックが正常であることを確認する必要があります。

いくつのノードが必要ですか?

Data Center ライセンスでは、クラスタのノード数は制限されません。ノードの適切な数は、Jira インスタンスのサイズや特徴、およびノードのサイズによって異なります。インスタンスのサイズの検討については、「Jira Data Center のサイズ プロファイル」を参照してください。小さく開始し、必要に応じて拡張することをおすすめします。

メモリ要件

各 Jira ノードの RAM は、最小 8 GB にすることをおすすめします。これは、少数のプロジェクト (最大 100)、1,000 ~ 5,000 件の課題、約 100 ~ 200 ユーザーを持つ単一の Server インスタンスに十分です。

自身の Jira インスタンスの大きさと複雑さを判断するには、「Jira Data Center のサイズ プロファイル」を参照してください。

Jira アプリケーションの最大ヒープ (-Xmx) は、setenv.sh または setenv.bat ファイルで設定されます。Data Center の場合、既定値を増やす必要があります。最小ヒープ (Xms) と最大 (Xmx) ヒープを同じ値に維持することをおすすめします。 

また、アトラシアンの公開 Jira Data Center インスタンスの詳細を確認することもできます。「Jira Data Center のサンプル デプロイメント」を参照してください。

データベース

使用する予定のデータベースが現在のサポート対象プラットフォームの一覧に記載されていることを確認する必要があります。平均的なクラスタ ソリューションの負荷はスタンドアロン インストールよりも高くなるため、サポート対象のデータベースを使用することは非常に重要です。

サポート対象のデータベース ドライバを使用する必要もあります。これらのドライバは、上述のサポート対象プラットフォームに記載されています。Jira をデータベースに接続する方法の詳細な手順については、「Jira アプリケーションのデータベースへの接続」を参照してください。

データベースの高可用性のための追加要件

Jira Data Center をクラスタで実行する場合、アプリケーション サーバーは単一障害点になりません。これは、サポートされている次の構成を使用して、データベースでも実現できます。

  • Amazon RDS Multi-AZ: このデータベース セットアップは、別のアベイラビリティ ゾーンのスタンバイにレプリケートするプライマリ データベースを備えています。プライマリが停止した場合、スタンバイが代わりになります。

  • Amazon PostgreSQL 互換 Aurora: 1 つ以上のリーダー (別のアベイラビリティ ゾーンを推奨) にレプリケートするデータベース ノードを備えたクラスタです。ライターが停止した場合、Aurora はライターの 1 つをプロモートして代わりにします。

AWS クイック スタート デプロイ オプションを使用するといずれかの方法で Jira Data Center を最初からデプロイできます。既存の Jira Data Center インスタンスで Amazon Aurora クラスタをセットアップする場合、「Amazon Aurora を使用するために Jira Data Center を構成する」をご参照ください。

共有ホームおよびストレージの要件

すべての Jira クラスタは同じパスで共有ディレクトリへのアクセス権限を持っている必要があります。NFS および SMB/CIFS 共有が共有ディレクトリの場所としてサポートされています。このディレクトリには大量のデータ (添付ファイルやバックアップを含む) が格納されるため、十分なサイズを用意し、必要に応じて利用可能なディスク領域を増やす方法を計画しておく必要があります。

ロード バランサ

もっとも慣れ親しんだロード バランサを使用することをおすすめします。ロード バランサは "セッション アフィニティ" をサポートしている必要があります。AWS でデプロイしている場合、Application Load Balancer (ALB) を使用する必要があります。

ロードバランサを設定するときの推奨事項は、次のとおりです。

  • キューは、ロード バランサでリクエストします。ノードに渡されるリクエストの最大数が、Tomcat が受け入れ可能な HTTP スレッドの合計数を超えないようにします。これにより、処理可能な量を超えたリクエストがノードに転送されるのを避けることができます。<install-directory>/conf/server.xml の maxThreads をご確認ください。

  • 非常に迅速に、すべてのノード間での問題を伝播できるため、他のノードに失敗した、べき等の要求を再生しないでください。

  • 最小接続 の使用で、ラウンドロビンとしてではなく、 負荷バランスを行う方法はノードがクラスタに参加または削除された後に再結合する際に、よりよい負荷のバランスをとることができます。 

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

URL期待される内容予想 HTTP ステータス
http://<jiraurl>/status{"state":"RUNNING"}200 OK
すべてのステータス コードとレスポンスを表示する...
HTTP ステータス コードレスポンス エンティティ説明
200{"state":"RUNNING"}

通常実行

500{"state":"ERROR"}エラー状態
503{"state":"STARTING"}アプリケーションが起動
503{"state":"STOPPING"}アプリケーションが停止中
200{"state":"FIRST_RUN"}アプリケーションが初めて実行され、まだ設定されていない
404
アプリケーションが予期しない方法で起動に失敗(web アプリケーションのデプロイが失敗)

ノードが長いGCの一時停止などの小さな問題を、生き残ることができるよう監視を設定するときは、いくつかの推奨事項は、以下のとおりです。 

  • ノードを削除する前に2回連続して失敗を待ちます。
  • ノードへの既存の接続の終了を 30 秒程度許可してから、ノードをプールから削除します。

詳細については、「ロード バランサの構成オプション」よび「ロード バランサの例」を参照してください。

ネットワークアダプタ

サーバー間の通信に個別のネットワーク アダプタを使用します。クラスタ ノードはサーバー間通信用の個別の物理ネットワーク(個別の NIC など)を持っている必要があります。これはクラスタの実行を高速および信頼性を高くするのに最適な方法です。その他のデータ ストリーミングを多数持つネットワークを介してクラスタ ノードに接続する場合、パフォーマンスの問題が発生する可能性があります。

アプリの互換性

Jira クラスタにおける Marketplace アプリ (アドオン、プラグイン) のインストール プロセスは、Jira のスタンドアロン インスタンスと同じです。アプリのインストールまたは更新の際に、クラスタを停止したり、ノードをダウンさせたりする必要はありません。 

Atlassian Marketplace では、アプリが Jira Data Center との互換性を持っているかどうかを確認できます。Data Center 認証アプリの詳細をご覧ください

準備はよろしいですか? 

クラスタを有効化および構成するためのステップ バイ ステップ ガイドについては、「Jira Data Center クラスタのセットアップ」をご参照ください。

Last modified on Mar 22, 2021

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

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