Alternative disaster recovery guide for Jira
概要
このページでは、一般的に「コールド スタンバイ」と呼ばれる戦略について説明しています。これはスタンバイ Jira インスタンスが継続的に実行されておらず、 スタンバイ インスタンスを起動し、組織のビジネス ニーズに対するサービスを提供するのに適した状態にあることを確認するための管理手順の実行が必要であることを意味しています。
ディザスタ リカバリ計画で考慮する必要がある主なコンポーネントは以下のとおりです。
| Jira インストール | スタンバイ サイトには、本番サイトと完全に同じバージョンの Jira Data Center がインストールされている必要があります。 |
|---|---|
| データベース | これは Jira の主要な情報源であり、Jira データのほとんど（添付ファイル、アバター、インストールされているプラグインなどを除く）を含んでいます。データベースをレプリケートし、継続的に最新に維持し、RPO1 を満たす必要があります。 |
| 添付ファイル | すべての課題添付ファイルはローカル ファイル システムに保存され、スタンバイ インスタンスにレプリケートする必要があります。 |
| 検索インデックス | 検索インデックスは主要な情報源ではなく、いつでもデータベースから再作成することができます。しかし、大規模なインストールの場合は長時間かかる可能性があり、インデックスが完全に復旧するまで Jira の機能は大幅に低下します。Jira では、この復旧時間を最小限に抑えるツールを提供しています。 |
| プラグイン | ユーザーがインストールしたプラグインはローカル ファイル システムに保存され、スタンバイ インスタンスにレプリケートする必要があります。 |
| その他のデータ | スタンバイ インスタンスにレプリケートする必要がある、ユーザーやプロジェクト アバターなどの重要ではないアイテムがいくつかあります。 |
スタンバイ システムのセットアップ
ステップ 1. Jira Data Center のインストール
スタンバイ システムに同じバージョンの Jira をインストールします。スタンバイ データベースにアタッチするようにシステムを設定します。
インスタンスをディザスタ リカバリ インストールとするように設定する必要もあります。これにより、Jira が起動したときに自動インデックス復旧メカニズムがキックされます。
スタンバイ インスタンスの Jira ホーム ディレクトリの jira-config.properties に、以下を追加します。
disaster.recovery=trueスタンバイ Jira システムを起動しないでください
Jira の起動 によって、データベースに不要なデータが書き込まれます。
一時的に異なるデータベースに接続して Jira を起動し、期待通りに動作することを確認して、インストールをテストすることができます。テスト後にスタンバイ データベースを参照するようにデータベース設定を更新することを忘れないでください。
ステップ2.データ レプリケーション戦略の実装
スタンバイの場所へのデータのレプリケートは、コールド スタンバイ フェイルオーバー戦略において不可欠です。スタンバイのデータが古かったり、インデックスの再作成に数時間かかると、スタンバイ Jira インスタンスにフェイルオーバーさせたくなくなります。
以下のように、外部ツールを使用してデータのレプリケーションを管理します。
| データベース | アトラシアンは、データベースのレプリケートについて、特定の戦略を提供または推奨していません。サポートされるデータベース サプライヤーのすべて (Oracle、PostgreSql、MySql、および Microsoft SQLServer) がそれぞれ独自のデータベース レプリケーション ソリューションを提供しています。
|
|---|---|
| 添付ファイル | ディザスタ リカバリ用に添付ファイルを管理する方法は多数あります。
|
| 検索インデックス | RTO 1 目標を満たすように検索インデックスを設定する手順は以下のとおりです。
|
| プラグイン | インストール済みのプラグインは、<yourjirahome ディレクトリに保持されます。スタンバイ インスタンスのこのディレクトリは、ライブ インスタンスの同ディレクトリと同期されている必要があります。これをファイル システム レベルで実行するように定期ジョブを設定する必要があります。 |
| その他のデータ |
アトラシアン以外が提供しているプラグインがある場合、それらが |
ディザスタ リカバリ テスト
ディザスタ リカバリ計画をテストする際は、細心の注意を払ってください。たとえば、テストの更新が本番データベースに挿入された場合など、単純なミスによってライブ インスタンスが破損する可能性があります。ディザスタ リカバリのテスト中に、実際の災害から復旧する能力に悪影響を及ぼあす可能性があります。
重要なことはメインのデータ センターをディザスタ リカバリ テストから可能な限り分離することです。
Prerequisites
テストを実施する前に、本番データを分離する必要があります。
| データベース |
|
|---|---|
| 添付ファイル、プラグイン、およびインデックス | テスト中にプラグインの更新やインデックスのバックアップが発生しないようにする必要があります。
注： 添付ファイルはいかなる問題も発生させてはいけません。フォルダが書き込み権限を持つ場合、フェイルオーバー インスタンスのヘルスチェックによって十分な情報が与えられます。 |
| インストール フォルダ |
|
このあと、データベースを含むスタンバイ インスタンスへのすべてのレプリケーションを再開することができます。
ディザスタ リカバリ テストの実施
本番データを分離したら、以下の手順に従い、ディザスタ リカバリ計画をテストします。
- 新しいデータベースの準備ができており、最新のスナップショットを持ち、レプリケーションを持たないことを確認します。
- 適切な
dbconfig.xmlコネクションが設定されたクリーンなサーバーに Jira のコピーがあることを確認します。 - スタンバイ インスタンスと同様にテスト サーバーで
JIRA_HOMEがマップされていることを確認します。JIRA_HOME/export folderに最新のスナップショットがあることが重要です。 - メールを無効化します。
- disaster.recovery=true パラメータを指定し、Jira をディザスタ リカバリ モードで起動します。
フェイルオーバーのハンドリング
プライマリ サイトが利用できなくなった場合、スタンバイ システムにフェイルオーバーする必要があります。このセクションでは、スタンバイ システムでのデータの確認方法の手順を含む、フェイルオーバーの方法を説明しています。
ステップ 1. スタンバイ インスタンスへのフェイルオーバー
スタンバイ インスタンスへのフェイルオーバーの基本的な手順は以下のとおりです。
- ライブ システムがシャットダウンされており、データベースの更新がなくなっていることを確認します。
- ディレクトリ
<yourjirahomeがスタンバイ インスタンスに存在しないことを確認します。>/old - スタンバイ データベースをアクティブ化するのに必要な手順を実施します。
- スタンバイ インスタンスで Jira を起動します。
- Jira が起動するのを待ち、期待どおり動作することを確認する。
- 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つだけ起動し、検索インデックスを復旧させ、他のノードを起動する前に正しく動作することを確認するのが重要です。 |
プライマリ インスタンスに戻る
ほとんどの場合、ディザスタの原因となった問題を解決した後、プライマリ インスタンスを使用して戻ることになります。妥当なサイズの停止期間をスケジュールできる場合は、この方法が最も簡単です。
必要な操作:
- プライマリ データベースをセカンダリの状態と同期させる。
- プライマリ添付ファイル ディレクトリをセカンダリの状態と同期させる。
- プライマリ サーバーのインデックス状態を復元する。
準備
| 添付ファイルとその他のファイル |
|
|---|---|
| 検索インデックス | 最近のインデックス スナップショットを持つことができるように、スタンバイ ノードでインデックス スナップショットを有効にします。これはライブ ノードからアクセスできる場所にコピーする必要があります。 |
カットオーバーの実行
- スタンバイ ノードで Jira をシャットダウンします。
- データベースが要求どおり、正しく同期さおよび構成されていることを確認します。
- Jira を起動します。
- Jira にログインし、インデックス スナップショットからインデックスを復元します。スナップショット ファイルの名前と場所を把握しておく必要があります。
- Jira が期待どおり動作していることを確認します。
- DNS、HTTP プロキシまたはその他のフロント エンド プロキシがを更新し、プライマリ サーバーへトラフィックをルーティングするようにします。
その他のリソース
ソリューションパートナー
Jira Data Center ドキュメントは、唯一アトラシアンがサポートする Jira 用のディザスタ リカバリ ソリューションです。ただし、Jira Data Center を入手できないお客様に対しては、アトラシアンの多くのエキスパートが数年間にわたって Jira 用のディザスタ リカバリ ソリューションを実装しています。
ご利用の環境へディザスタ リカバリ ソリューションを実装するには、エキスパート チームに連絡します。
Atlassian Answers
アトラシアンのコミュニティやスタッフも、アトラシアン Answers を見ています。ベスト プラクティス、質問やコメントにご協力お願いします。このページに関連する回答の例は次のようになります。
トラブルシューティング
スタンバイ インスタンスへのフェールオーバー後に問題が発生した場合、次の FAQ が役に立ちます。
定義
1 - 定義
| RPO | Recovery Point Objective : 目標復旧地点 | 障害発生後、Jira インスタンスをどの程度最新の状態にする必要があるか |
| RTO | Recovery Time Objective : 目標復旧時間 | 障害発生後、スタンバイ システムをどの程度の時間で利用できるようにする必要があるか |
| RCO | Recovery Cost Objective : 目標復旧コスト | ディザスタ リカバリ ソリューションにどの程度の金額をかける意思があるか |