Jira 向けディザスタ リカバリ ガイド

Jira 向けディザスタ リカバリ ガイド

このページの内容

お困りですか?

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

コミュニティに質問

このガイドでは、Jira Data Center を使用しない場合の Jira の代替ディザスタ リカバリ ソリューションの設定方法について説明します。このソリューションは、Atlassian ではサポートされていません。Atlassian がサポートする Jira のディザスタ リカバリ ソリューションは、「Jira のディザスタ リカバリ ガイド」で説明しています。これには Jira Data Center が必要です。  

ディザスタ リカバリ戦略は、事業継続計画の重要な部分です。これは災害発生時に従う必要があるプロセスをカバーしており、事業を復旧し、業務を継続することを保証します。Jira の場合、これはプライマリ サイトが利用できなくなった場合の Jira の可用性を保証することを意味しています。

このページの内容:


概要

このページでは、一般的に「コールド スタンバイ」と呼ばれる戦略について説明しています。これはスタンバイ Jira インスタンスが継続的に実行されておらず、 スタンバイ インスタンスを起動し、組織のビジネス ニーズに対するサービスを提供するのに適した状態にあることを確認するための管理手順の実行が必要であることを意味しています。

ディザスタ リカバリ計画で考慮する必要がある主なコンポーネントは以下のとおりです。

Jira インストール スタンバイ サイトには、本番サイトと完全に同じバージョンの Jira がインストールされている必要があります。
データベース これは Jira の主要な情報源であり、Jira データのほとんど(添付ファイル、アバター、インストールされているプラグインなどを除く)を含んでいます。データベースをレプリケートし、継続的に最新に維持し、RPO1 を満たす必要があります。
添付ファイル

すべての課題添付ファイルはローカル ファイル システムに保存され、スタンバイ インスタンスにレプリケートする必要があります。

検索インデックス 検索インデックスは主要な情報源ではなく、いつでもデータベースから再作成することができます。しかし、大規模なインストールの場合は長時間かかる可能性があり、インデックスが完全に復旧するまで Jira の機能は大幅に低下します。Jira では、この復旧時間を最小限に抑えるツールを提供しています。
プラグイン ユーザーがインストールしたプラグインはローカル ファイル システムに保存され、スタンバイ インスタンスにレプリケートする必要があります。
その他のデータ スタンバイ インスタンスにレプリケートする必要がある、ユーザーやプロジェクト アバターなどの重要ではないアイテムがいくつかあります。

スタンバイ システムのセットアップ

Step 1. Jira のインストール

スタンバイ システムに同じバージョンの Jira をインストールします。スタンバイ データベースにアタッチするようにシステムを設定します。

インスタンスをディザスタ リカバリ インストールとするように設定する必要もあります。これにより、Jira が起動したときに自動インデックス復旧メカニズムがキックされます。

スタンバイ インスタンスの Jira ホーム ディレクトリの jira-config.properties に、以下を追加します。

disaster.recovery=true

スタンバイ Jira システムを起動しないでください

Jira の起動 によって、データベースに不要なデータが書き込まれます。

一時的に異なるデータベースに接続して Jira を起動し、期待通りに動作することを確認して、インストールをテストすることができます。テスト後にスタンバイ データベースを参照するようにデータベース設定を更新することを忘れないでください。

ステップ2.データ レプリケーション戦略の実装

スタンバイの場所へのデータのレプリケートは、コールド スタンバイ フェイルオーバー戦略において不可欠です。スタンバイのデータが古かったり、インデックスの再作成に数時間かかると、スタンバイ Jira インスタンスにフェイルオーバーさせたくなくなります。

以下のように、外部ツールを使用してデータのレプリケーションを管理します。

データベース

Atlassian はデータベースのレプリケートについて、特定の戦略を提供または推奨していません。サポートされるデータベース サプライヤーのすべて(Oracle、PostgreSql、MySql、およびMicrosoft SQLServer)が、独自のデータベース レプリケーション ソリューションを提供しています。

PRO1 および RCO1 を満たすデータベース レプリケーション戦略を実装する必要があります。

添付ファイル

ディザスタ リカバリ用に添付ファイルを管理する方法は多数あります。


  • Jira に添付ファイルを複製させる:
    添付ファイルのコピーをセカンダリ ロケーションに書き込むように Jira を設定できます。このセカンダリ コピーは、通常の Jira のパフォーマンスに影響を与えないよう、非同期的に書き込まれます。Jira のセカンダリ ストレージでは、以下のことが可能です:
    • オペレーティング システム レベルのツールを使用する必要があるファイル システム マッピングを行い、NFS、CIFS、またはその他の仕組みを使用して、その場所をリモート スタンバイの場所にマッピングします。
    • 定義済みストレージでプラグインを使用します。または
    • Jira の SimpleAttachmentStore を実装しているプラグインを作成します。

    Jira はこれを有効にした時点から同期し続けます。JIRA はプライマリ ロケーションからセカンダリ ロケーションに、以前の添付ファイルをすべて移行しません
    セカンダリ ファイル システム ストレージを有効にすると、Jira は Jira ホームの同じ構造をマッピングする Jira_HOME/secondary のデフォルト ロケーションを提供し、セカンダリ ストレージをプライマリとして使用する必要があるときに一貫性を保ちます。このストレージにもプラグインとスナップショットをレプリケートできるため、このパスを編集するときは注意してください。
    RTO を改善するには、セカンダリ ストレージの物理的な場所がプライマリと同じパスである必要があります。これには、Jira がフェイルオーバー データ センターで起動するときに、新しい場所を設定する必要が無いという利点があります。 

  • 独自の DR を提供する添付ファイル ストアを保存します。
    Jira はプライマリ ストレージ場所としてさまざまなストレージ (Amazon の S3、Google Drive など) を利用するお客様向けのエントリー ポイントを提供します。これには、単独の添付ファイル ストレージやセカンダリ バックアップ ストレージが考えられます。 

  • ファイル システムまたはオペレーティング システムのツールを使用して添付ファイルをレプリケートします。
    既に企業 SAN またはこの機能を提供する同様のシステムを使用している場合、コスト効率が高く信頼性の高い方法で添付ファイルをレプリケートします。

検索インデックス

RTO 1 目標を満たすように検索インデックスを設定する手順は以下のとおりです。

  1. ライブ インスタンスでのインデックス復旧を有効にします。
    これは検索インデックスの一貫したスナップショットを定期的に取得します。この頻度はフェイルオーバー後のスタンバイの完全なインデックスの復旧にかかる時間に影響しますが、頻度が24時間であっても、復旧される量は通常、インデックスの1%未満(1日に作成されるインデックス)であるため、復旧にかかる時間は非常に短くなります。たとえば、完全なインデックスの再作成に5時間かかる場合、復旧にかかる時間は約5分と予想されます。
  2. インデックスのスナップショットをスタンバイ インスタンスにコピーします。
      • <yourjirahome>/export/indexsnapshots. に保存されているスナップショット。
      • スナップショットはスタンバイ サーバー上の <yourjirahome>/import/indexsnapshots にコピーする必要があります。
    Jira はこれらのファイルをコピーする仕組みを提供していません。定期ジョブを設定して、ファイル システム コピーを行う必要があります。少なくとも最新の2つのスナップショットは、スタンバイ サーバーに残しておく必要があります。 
  3. スタンバイ サーバーがディザスタ リカバリ インストールであることを確認します。 — 上記の「Jira のインストール」を参照してください。
プラグイン インストール済みのプラグインは、<yourjirahome>/plugins/installed-plugins ディレクトリに保持されます。スタンバイ インスタンスのこのディレクトリは、ライブ インスタンスの同ディレクトリと同期されている必要があります。これをファイル システム レベルで実行するように定期ジョブを設定する必要があります。
その他のデータ

<yourjirahome>/data/avatars ディレクトリのコンテンツも定期的にレプリケートする必要があります。

アトラシアン以外が提供しているプラグインがある場合、それらが <yourjirahome> ディレクトリにデータを書き込む可能性があります。このデータをスタンバイ サーバーにレプリケートする必要があるかどうかを確認するには、プラグインの提供元に問い合わせる必要があります。

ディザスタ リカバリ テスト

ディザスタ リカバリ計画をテストする際は、細心の注意を払ってください。たとえば、テストの更新が本番データベースに挿入された場合など、単純なミスによってライブ インスタンスが破損する可能性があります。ディザスタ リカバリのテスト中に、実際の災害から復旧する能力に悪影響を及ぼあす可能性があります。

(info)重要なことはメインのデータ センターをディザスタ リカバリ テストから可能な限り分離することです

要件

テストを実施する前に、本番データを分離する必要があります。

データベース
  1. スタンバイ データベースへのレプリケーションをすべて一時的に停止します。
  2. スタンバイ データベースから分離されてメインのデータベースへの接続を持たない別のデータベースにデータをレプリケートします。
添付ファイル、プラグイン、およびインデックス

テスト中にプラグインの更新やインデックスのバックアップが発生しないようにする必要があります。

  1. インデックス バックアップを無効化します。
  2. システム管理者に Jira で更新を行わないように指示します。

注: 添付ファイルはいかなる問題も発生させてはいけません。フォルダが書き込み権限を持つ場合、フェイルオーバー インスタンスのヘルスチェックによって十分な情報が与えられます。

インストール フォルダ
  1. ライブ インスタンスとスタンバイ インスタンスの両方から分離されたスタンバイ インストールをクローンします。
  2. JIRA_HOME/dbconfig.xml でデータベースへの接続を変更して競合を回避します。

このあと、データベースを含むスタンバイ インスタンスへのすべてのレプリケーションを再開することができます。

ディザスタ リカバリ テストの実施

本番データを分離したら、以下の手順に従い、ディザスタ リカバリ計画をテストします。

  1. 新しいデータベースの準備ができており、最新のスナップショットを持ち、レプリケーションを持たないことを確認します。
  2. 適切な dbconfig.xml コネクションが設定されたクリーンなサーバーに Jira のコピーがあることを確認します。
  3. スタンバイ インスタンスと同様にテスト サーバーで JIRA_HOME がマップされていることを確認します。JIRA_HOME/export folder に最新のスナップショットがあることが重要です。
  4. メールを無効化します。
  5. disaster.recovery=true パラメータを指定し、Jira をディザスタ リカバリ モードで起動します。

フェイルオーバーのハンドリング

プライマリ サイトが利用できなくなった場合、スタンバイ システムにフェイルオーバーする必要があります。このセクションでは、スタンバイ システムでのデータの確認方法の手順を含む、フェイルオーバーの方法を説明しています。

ステップ 1. スタンバイ インスタンスへのフェイルオーバー

スタンバイ インスタンスへのフェイルオーバーの基本的な手順は以下のとおりです。

  1. ライブ システムがシャットダウンされており、データベースの更新がなくなっていることを確認します。
  2. ディレクトリ <yourjirahome>/old がスタンバイ インスタンスに存在しないことを確認します。
  3. スタンバイ データベースをアクティブ化するのに必要な手順を実施します。
  4. スタンバイ インスタンスで Jira を起動します。
  5. Jira が起動するのを待ち、期待どおり動作することを確認する。
  6. DNS、HTTP プロキシまたはその他のフロント エンド プロキシがを更新し、スタンバイ サーバーへトラフィックをルーティングするようにする。

Jira の起動後、ログ (<yourjirahome>/log/atlassian-jira.log ) で、リカバリ状態に関する情報を確認します。

ステップ 2. スタンバイ インスタンスでデータを確認する

スタンバイ インスタンスにフェイルオーバーした後、ユーザーがシステムにアクセスしてデータを変更し始めるに以下の項目を確認します。

チェックマーク 手順説明
最新の課題の更新がデータベースに記録されている

データベースで、以下の SQL クエリを実行します。

SELECT max(updated) from jiraissue; 
最新の課題の更新が検索インデックスに記録されている

Jira で課題 > 課題の検索に移動し、以下の JQL を実行します。

order by updated desc
課題の総数を確認する

データベースで、以下の SQL クエリを実行します。

SELECT count(*) from jiraissue;
検索インデックス内の課題の総数を確認する

Jira で、課題 > 課題の検索に移動し、空のクエリで検索を実行します。

クラスタリングの考慮事項

クラスタ化された環境の場合、上記の情報に加え、以下に注意する必要があります。

スタンバイ クラスタ

スタンバイ クラスタがある場合、スタンバイ ノードのノード id はライブ クラスタの id と異なる必要があります。

スタンバイ クラスタがライブ クラスタの構成を反映する必要はありません。要件と予算に応じて、含まれるノードが増減する可能性があります。ノードが少なくなるとスループットが低下しますが、状況に応じて許容される可能性があります。

ファイルの場所 同期する必要があるファイルの場所として <yourjirahome> が示されている場合、それはクラスタの共有ホームとなります。
スタンバイ クラスタの起動 最初にクラスタのノードを1つだけ起動し、検索インデックスを復旧させ、他のノードを起動する前に正しく動作することを確認するのが重要です。

プライマリ インスタンスに戻る

ほとんどの場合、ディザスタの原因となった問題を解決した後、プライマリ インスタンスを使用して戻ることになります。妥当なサイズの停止期間をスケジュールできる場合は、この方法が最も簡単です。

必要な操作:

  • プライマリ データベースをセカンダリの状態と同期させる。
  • プライマリ添付ファイル ディレクトリをセカンダリの状態と同期させる。
  • プライマリ サーバーのインデックス状態を復元する。

準備

添付ファイルとその他のファイル
  1. スイッチオーバー プロセスを開始する前に、rsync または同様のユーティリティを使用して、添付ファイルの大部分をプライマリ サーバーと同期させます。
  2. 同様に、開始前にインストールされているプラグインとロゴを同期させる必要があります。
検索インデックス 最近のインデックス スナップショットを持つことができるように、スタンバイ ノードでインデックス スナップショットを有効にします。これはライブ ノードからアクセスできる場所にコピーする必要があります。

カットオーバーの実行

  1. スタンバイ ノードで Jira をシャットダウンします。
  2. データベースが要求どおり、正しく同期さおよび構成されていることを確認します。
  3. Jira を起動します。
  4. Jira にログインし、インデックス スナップショットからインデックスを復元します。スナップショット ファイルの名前と場所を把握しておく必要があります。
  5. Jira が期待どおり動作していることを確認します。
  6. DNS、HTTP プロキシまたはその他のフロント エンド プロキシがを更新し、プライマリ サーバーへトラフィックをルーティングするようにします。

その他のリソース

ソリューションパートナー

Jira Data Center は、唯一 Atlassian がサポートする Jira 用のディザスタ リカバリ ソリューションです。ただし、Jira Data Center を入手できない場合、弊社の多くのエキスパートが、数年間、Jira のディザスタ リカバリ ソリューションを実施しています。

ご利用の環境へディザスタ リカバリ ソリューションを実装するには、エキスパート チームに連絡します

Atlassian Answers で調べる

アトラシアンのコミュニティやスタッフも、アトラシアン Answers を見ています。ベスト プラクティス、質問やコメントにご協力お願いします。このページに関連する回答の例は次のようになります。

トラブルシューティング

スタンバイ インスタンスへのフェールオーバー後に問題が発生した場合、次の FAQ が役に立ちます。

データベースが正しく同期されない場合はどうすればよいですか?

データベースで必要なデータを利用できない場合は、データベースをバックアップから復元する必要があります。

データベースを復元すると、検索インデックスはデータベースと同期された状態ではなくなります。完全なインデックス再作成、バックグラウンドまたはフォアグラウンドを実行するか、ある場合は最新のインデックス スナップショットから復元できます。インデックス スナップショットはお使いのデータベース バックアップよりも古い/新しい可能性があり、復元プロセスの一部として同期されます。

検索インデックスが破損している場合はどうすればよいですか?

検索インデックスが破損している場合は、完全なインデックス再作成、バックグラウンドまたはフォアグラウンドを実行するか、ある場合は最新のインデックス スナップショットから復元できます。 

添付ファイルが欠落している場合はどうすればいですか?

ある場合はバックアップから復元したり、ハード ドライブへのアクセス権を持っている場合はプライマリ サイトから復元できる場合があります。このような場合には、rsync などツールが役に立つ場合があります。添付ファイルが欠落していても Jira は正常に動作しますが、欠落している添付ファイルは利用できません。そのため、ユーザーがそれらを再度アップロードできない可能性があります。

定義

1 - 定義

RPO Recovery Point Objective : 目標復旧地点 障害発生後、Jira インスタンスをどの程度最新の状態にする必要があるか
RTO Recovery Time Objective : 目標復旧時間 障害発生後、スタンバイ システムをどの程度の時間で利用できるようにする必要があるか
RCO Recovery Cost Objective : 目標復旧コスト ディザスタ リカバリ ソリューションにどの程度の金額をかける意思があるか
最終更新日 2018 年 1 月 12 日

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

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