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

このページの内容

このセクションの項目

お困りですか?

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

コミュニティに質問

Jira Data Center は、Atlassian がサポートする、Jira 用の唯一の高可用性ソリューションです。ただし、Jira Data Center を選択しない場合も、Atlassian のエキスパートがお客様の環境向けにディザスタ リカバリ計画を作成するお手伝いができる場合があります。エキスパート チームにお問い合わせください。

このページでは、Jira のディザスタ リカバリ戦略の実装と管理に Jira Data Center 6.4 を使用する方法を説明しています。これは主要目標(RTO、RPO、RCO)や標準運用手順の設定などの幅広いビジネス プラクティスについてはカバーしていません。

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

このページの内容

高可用性とディザスタ リカバリの違いはなんですか?

「高可用性」、「ディザスタ リカバリ」、および「フェイルオーバー」という単語は混同されがちです。本ドキュメントでは、次のように使い分けます。

  • 「高可用性」 — 特定のレベルの可用性(Jira の場合、アプリケーションへのアクセス権限と許容応答時間)を提供するための戦略です。自動修正と(同じ場所での)フェイルオーバーは通常、高可用性計画の一部です。詳細については、「Jira の高可用性ガイド」を参照してください。
  • 「ディザスタ リカバリ」 – (災害などで)メインのデータ センターが利用できなくなる場合に、(通常、別の地域にある)別のデータ センターで運用を再開する戦略。(別の場所への)フェイルオーバーはディザスタ リカバリの基本的な部分です。 
  • 「フェイルオーバー」 - あるマシンが故障した際に、あるマシンが別のマシンから引き継ぐときのことを指します。これは同じデータ センター内またはあるデータ センターから別のデータ センターで行われます。フェイルオーバーは通常、高可用性戦略とディザスタ リカバリ計画の両方の一部です。

概要

開始する前に、このガイドで説明されている戦略を実装するには、Jira Data Center 6.4 が必要です。

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

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

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

すべての課題添付ファイルは Jira Data Center 共有ホームに保存され、スタンバイ インスタンスにレプリケートする必要があります。

検索インデックス

検索インデックスは主要な情報源ではなく、いつでもデータベースから再作成することができます。しかし、大規模なインストールの場合は長時間かかる可能性があり、インデックスが完全に復旧するまで Jira の機能は大幅に低下します。Jira Data Center 6.4 では、この復旧時間を最小限に抑えるツールを提供しています。

If index recovery is enabled, all index snapshots are stored in the Jira Data Center shared home and need to be replicated to the standby instance.

プラグイン ユーザーがインストールしたプラグインはJira Data Center 共有ホームに保存され、スタンバイ インスタンスにレプリケートする必要があります。
その他のデータ Jira Data Center 共有ホームに保存されている、重要性が低いその他の項目 (ユーザー、プロジェクト アバターなど) も、スタンバイ インスタンスに複製する必要があります。

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

ステップ 1. Jira Data Center 6.4 以降のインストール

スタンバイ システムに Jira の同じバージョンをインストールします。システムを構成してスタンバイ データベースに接続します。

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

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

disaster.recovery=true

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

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

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

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

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

データベース

以下の Jira がサポートするデータベース サプライヤーのはすべて独自のデータベース レプリケーション ソリューションを提供しています。

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

ファイル

Jira はセカンダリ ロケーションへのファイルのレプリケーションを自動的に管理することができます。これには、添付ファイル、アバター、インデックス スナップショット、インストールされているプラグインが含まれます。 

Jira のファイル レプリケーションを有効化するには、Jira 管理コンソールのレプリケーション設定ページに移動し、ファイル レプリケーションを有効化します。
 

はじめてファイル レプリケーションを有効化する場合、同期ボタンを押して同期を実行する必要があります。これはピーク時間外に実施することをお勧めします。Jira へのアクセスを妨げることはありませんが、長時間操作が実行される可能性があります。

初回同期の後、Jira は自動的にセカンダリ コピーを最新に保ちます。このセカンダリ コピーは非同期に書き込まれるため、プライマリ Jira インスタンスのパフォーマンスには影響しません。

メモ:

  • ファイル レプリケーション設定の変更 — ファイル レプリケーション設定のいずれかを変更する場合、(同期ボタンで)もう一度同期を実施する必要があります。これはピーク時間外に実施することをお勧めします。
  • レプリケーション フォルダの設定 — jira-config.properties ファイルで、jira.secondary.home プロパティを目的のパスに設定します。
    • クラスタ モードで Jira を実行している場合、セカンダリ ホームはすべてのノードからアクセスできるパスである必要があります。
  • その他のファイル タイプ — プラグインで追加されたファイルなど、他の手段で追加されたファイルには、別のレプリケーションの手段が必要です。これらの場合、推奨事項についてプラグイン ベンダーに問い合わせます。

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

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

スタンバイ クラスタ

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

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

ファイルの場所

同期する必要があるファイルの場所として <JIRA_SHARED_HOME> が示されている場合、それはクラスタの共有ホームとなります。

<JIRA_LOCAL_HOME> refers to the node specific home directory.

スタンバイ クラスタの起動 最初にクラスタのノードを1つだけ起動し、検索インデックスを復旧させ、他のノードを起動する前に正しく動作することを確認するのが重要です。

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

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

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

前提条件

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

スタンバイ インスタンスにフェイルオーバーした後、ユーザーがシステムにアクセスしてデータを変更し始めるに以下の項目を確認します。すべてのプロジェクトに対するプロジェクトの参照パーミッションを持つ Jira 管理者である必要があります。

管理 > システム > Atlassian サポート ツール > ヘルス チェック へ移動して、以下を確認します。 

データベースとインデックスの一貫性

ヘルス チェックのインデックス セクションから。

  • チェックが正常に行われた場合:
  • チェックが正常に行われなかった場合:

組織の RPO 内に入るアイテム数と更新日を検証します。

添付ファイル

ヘルス チェックの添付ファイル セクションから。

  • チェックが正常に行われた場合:
     
  • チェックが正常に行われなかった場合:

チェックが動作しない場合は、次のように、手動でリカバリ ポイントを決定できます。

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

    select issueid, created from fileattachment order by created desc limit 1;
  2. Jira で課題 > 課題の検索に移動し、以下の高度な (JQL) 検索を実行します。

    id=<issue_id>

    ここで、<issue_id> は前のステップで SQL クエリで返された issueid です。  

  3. 検索で返された課題を開き、課題の添付ファイルを表示できることを確認します。添付ファイルを表示できない場合は、少し古い添付ファイルを確認してください。利用可能な最新の添付ファイル、およびどの添付ファイルが不足しているかを決定する必要があります。

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

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

必要な操作:

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

準備

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

カットオーバーの実行

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

その他のリソース

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

Jira Data Center は、Atlassianがサポートする、Jira 用の唯一の高可用性ソリューションです。ただし、Jira Data Center を選択しない場合も、Atlassian のエキスパートがお客様の環境向けにディザスタ リカバリ計画を作成するお手伝いができる場合があります。エキスパート チームにお問い合わせください。

Atlassian Answers で調べる

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

トラブルシューティング

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

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

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

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

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

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

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

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

フェイルオーバー中、アプリケーションリンクはどうなりますか?

アプリケーション リンクはデータベース内に保存され、データベースのレプリカが最新であれば、アプリケーション リンクが保存されます。

ただし、リンクの両側が互いのアドレスをどのようにして知るかについても検討する必要があります。

  • リンク内のパートナーを解決するためにホスト名を使用しており、DNS への更新などを介して、バックアップ Jira サーバーが同じホスト名を使用している場合でも、リンクをそのままにし、機能する必要があります。 
  • アプリケーション リンクが異なる IP アドレスを使用して構築されている場合、アプリケーション リンクの再構築が必要となります。 
  • 社内ネットワークで有効な IP アドレスが使用され、バックアップ システムはリモートや元のファイアウォール街で行われるということがよくあります。その場合、アプリケーション リンクを再確立する必要があります。


定義

1 - 定義

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

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

はい
いいえ
この記事についてのフィードバックを送信する

このセクションの項目

Powered by Confluence and Scroll Viewport.