Confluence Data Center のディザスタ リカバリ

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

Confluence Data Center は、アトラシアンがサポートする Confluence 用の唯一高可用性ソリューションです。

Confluence Server から Data Center へのアップグレードでお悩みですか? Confluence Data Center のメリットについて詳細を参照してください。

このページでは、Confluence用のディザスタ リカバリ戦略に Confluence Data Center 5.9 以降を使用する方法を説明しています。ただし、主要目標(RTO、RPO、RCO1)や標準運用手順の設定のような幅広いビジネス プラクティスについてはカバーしていません。

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

「高可用性」、「ディザスタ リカバリ」、および「フェイルオーバー」という単語は混同されがちです。このページでは、これらの言葉を次のように定義します。

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

概要

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

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

runbook のメンテナンス

詳細な手順は組織によって異なるため、完全な手順の runbook は参照する本番システムから離れたファイルに保持することをお勧めします。runbook は、事前知識や経験にかかわらず、関連するチームの誰もが手順を実施してサービスを復旧できるように十分に詳細化します。runbook にはディザスタ リカバリ プロセスの以下の部分をカバーする手順が含まれていることが期待されます。

  1. 問題の検出
  2. 現在の本番環境の分離と正常終了
  3. 障害が発生した本番環境と目的の復旧ポイント間のデータの同期
  4. 復旧インスタンスへのウォーム アップ命令
  5. ドキュメント、コミュニケーション、およびエスカレーション ガイドライン

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

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

すべての添付ファイルは Confluence Data Center の共有ホーム ディレクトリに保存されており、スタンバイ インスタンスにレプリケートされていることを確認する必要があります。

検索インデックス 検索インデックスは主要な情報源ではなく、いつでもデータベースから再作成することができます。大規模なインストールの場合は長時間かかる可能性があり、インデックスが完全に復旧するまで Confluence の機能は大幅に低下します。Confluence Data Center は検索インデックスのバックアップを共有ホーム ディレクトリに保存しています。これは共有ホーム ディレクトリのレプリケーションでカバーされています。
プラグイン ユーザーがインストールしたプラグインはデータベースに保存されており、データベースのレプリケーションでカバーされています。
その他のデータ その他の重要ではないアイテムは Confluence Data Center の共有ホームに保存されています。これらがスタンバイ インスタンスにレプリケートされていることを確認します。

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

手順1.Confluence Data Center 5.9 以降のインストール

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

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

Confluence の起動によって、データベースと共有ホームに不要なデータが書き込まれます。

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

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

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

データベース

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

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

ファイル

RTO、RPO、および RCO1 を満たす Confluence 共有ホーム ディレクトリ用のファイル サーバ レプリケーション戦略も実装する必要があります。

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

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

スタンバイ クラスタ

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

ファイルの場所

同期が必要なファイルの場所として <confluencesharedhome> を記述した場合、クラスタの共有ホームを参照しています。<confluencelocalhome> はクラスタ内のノードのローカル ホームを参照します。

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

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

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

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

この手順は、スタンバイ環境が正しいデータをすべて持つことを保証しますが、テスト環境はスタンバイ環境から完全に分離されているため、スタンバイ インスタンスで起こりうる構成の問題はカバーされていません。

前提条件

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

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

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

  1. インデックス バックアップを無効化します。
  2. システム管理者に Confluence で更新を行わないように指示します。
  3. スタンバイ共有ホーム ディレクトリへのレプリケーションをすべて一時的に停止します。
  4. スタンバイ共有ホーム ディレクトリから分離されてメインの共有ホーム ディレクトリへの接続を持たない別のディレクトリにデータをレプリケートします。


インストール フォルダ
  1. ライブ インスタンスとスタンバイ インスタンスの両方から分離されたスタンバイ インストールをクローンします。
  2. <confluencelocalhome>/confluence.cfg.xml ファイルでデータベースへの接続を変更して競合を回避します。
  3. <confluencelocalhome>/confluence.cfg.xml ファイルで共有ホーム ディレクトリの場所を変更して競合を回避します。
  4. クラスタのセットアップに TCP/IP を使用する場合、宛先の IP アドレスを <confluencelocalhome>/confluence.cfg.xml のテスト インスタンスの IP アドレスに変更します。



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

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

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

  1. 新しいデータベースの準備ができており、最新のスナップショットを持ち、レプリケーションを持たないことを確認します。
  2. 新しい共有ホーム ディレクトリの準備ができており、最新のスナップショットを持ち、レプリケーションを持たないことを確認します。
  3. クリーン サーバーに、適切なデータベースおよび共有ホーム ディレクトリ設定 (<confluencelocalhome>/confluence.cfg.xml) を含む Confluence のコピーがあることを確認します。
  4. スタンバイ インスタンスと同様に、テスト サーバーで confluence.home がマッピングされていることを確認します。
  5. メールを無効化します (「システム プロパティの設定」の atlassian.mail.senddisabled を参照)。
  6. Confluence を起動します。

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

プライマリ サイトが利用できなくなった場合、スタンバイ システムにフェイルオーバーする必要があります。手順は以下のとおりです。  

  1. ライブ システムがシャットダウンされており、データベースの更新がなくなっていることを確認します。
  2.  <confluencesharedhome の内容がスタンバイ インスタンスに同期されていることを確認します。
  3. スタンバイ データベースをアクティブ化するのに必要な手順を実施します。
  4. スタンバイ インスタンスの1つのノードで Confluence を起動します。
  5. Confluence が起動するのを待ち、期待通りに動作することを確認します。
  6. 他の Confluence ノードを起動します。
  7. DNS、HTTP プロキシ、またはその他のフロント エンド デバイスを更新し、トラフィックをスタンバイ サーバーにルーティングします。 

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

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

必要な操作: 

  • プライマリ データベースをセカンダリの状態と同期させる。
  • プライマリ共有ホーム ディレクトリをセカンダリの状態と同期させる。

カットオーバーの実行 

  1. スタンバイ インスタンスで Confluence をシャットダウンします。
  2. データベースが要求どおり、正しく同期さおよび構成されていることを確認します。
  3. rsync または類似のユーティリティを使用して、共有ホーム ディレクトリをプライマリ サーバーに同期します。
  4. Confluence を起動します。
  5. Confluence が期待どおり動作していることを確認します。
  6. DNS、HTTP プロキシまたはその他のフロント エンド プロキシがを更新し、プライマリ サーバーへトラフィックをルーティングするようにします。

その他のリソース 

Atlassian Answers で調べる

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

トラブルシューティング 

スタンバイ インスタンスへのフェールオーバー後に問題が発生した場合、ガイドラインの以下の FAQ を確認してください。

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

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

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

 

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

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

 

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

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

 

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

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

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

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

定義

RPO Recovery Point Objective : 目標復旧地点 障害発生後、Confluence インスタンスをどの程度最新の状態にする必要があるか
RTO Recovery Time Objective : 目標復旧時間 障害発生後、スタンバイ システムをどの程度の時間で利用できるようにする必要があるか
RCO Recovery Cost Objective : 目標復旧コスト

ディザスタ リカバリ ソリューションにどの程度の金額をかける意思があるか

最終更新日 2018 年 8 月 13 日

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

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