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

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

This page demonstrates how you can use Confluence Data Center 5.9 or later in implementing and managing a disaster recovery strategy for Confluence. It doesn't, however, cover the broader business practices, like setting the key objectives (RTO, RPO & RCO1), and standard operating procedures.

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

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

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

概要

Before you start, configure and set up your Confluence Data Center. See Set up a Confluence Data Center cluster.

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

runbook のメンテナンス

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

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

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

Confluence インストールスタンバイ サイトには、本番サイトと完全に同じバージョンの Confluence がインストールされている必要があります。
データベースThis is the primary source of truth for Confluence and contains most of the Confluence data (except for attachments, avatars, etc). You need to replicate your database and continuously keep it up to date to satisfy your RPO1
添付ファイル

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

Amazon S3 オブジェクト ストレージを添付ファイル データの保存に使用する場合は、個別に処理する必要があります。

検索インデックス

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

OpenSearch を使用している場合は、スナップショットによる別の戦略を採用する必要があります。詳細については、ステップ 2 の「データ レプリケーション戦略の実装」を参照してください。

アプリユーザーがインストールしたアプリはデータベースに保存されており、データベースのレプリケーションでカバーされています。
その他のデータその他の重要ではないアイテムは Confluence Data Center の共有ホームに保存されています。これらがスタンバイ インスタンスにレプリケートされていることを確認します。

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

ステップ 1. Confluence Data Center のインストール

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

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

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

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

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

スタンバイの場所へのデータのレプリケートは、コールド スタンバイ フェイルオーバー戦略において不可欠です。スタンバイ Confluence インスタンスにフェイルオーバーしたときに、スタンバイのデータが古かったり、インデックス再作成に長い時間がかかったりする事態は避ける必要があります。

データベース

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

You need to implement a database replication strategy that meets your RTO, RPO and RCO1. 

ファイル

You also need to implement a file server replication strategy for the Confluence shared home directory that meets your RTO, RPO and RCO1.

オブジェクト ストレージ

添付ファイルに Amazon S3 オブジェクト ストレージを使用している場合は、これらにレプリケーション戦略を実装する必要があります。

OpenSearch インデックス

If your Confluence instance is configured to use an OpenSearch cluster that is installed and managed on-premises, you can configure Cross Cluster replication. 

Alternatively, you can take regular snapshots and then use a file server replication strategy for copying to a cold standby. See the OpenSearch documentation on how to setup automatic or manual snapshots on your OpenSearch cluster.

Confluence インスタンスが AWS OpenSearch クラスターなどのマネージド サービスを使用している場合は、サービス プロバイダーにサポートされているとおりにレプリケーションを構成してください。

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

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

スタンバイ クラスタ

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

ファイルの場所

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

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

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

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

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

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

Prerequisites

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

データベース
  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. Disable email (See atlassian.mail.senddisabled in Configuring System Properties)
  6. Confluence を起動します。

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

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

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

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

In most cases, you'll want to return to using your primary instance after you've resolved the problems that caused the disaster. This is easiest to achieve if you can schedule a reasonably-sized outage window.  

必要な操作: 

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

カットオーバーの実行 

  1. スタンバイ インスタンスで Confluence をシャットダウンします。
  2. データベースが要求どおり、正しく同期さおよび構成されていることを確認します。
  3. Use  rsync  or a similar utililty to synchronize the shared home directory to the primary server
  4. Confluence を起動します。
  5. Confluence が期待どおり動作していることを確認します。
  6. DNS、HTTP プロキシまたはその他のフロント エンド プロキシがを更新し、プライマリ サーバーへトラフィックをルーティングするようにします。

その他のリソース 

トラブルシューティング 

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

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

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

 

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

 

You may be able to recover them from backups if you have them, or recover from the primary site if you have access to the hard drives. Tools such as rsync may be useful in these circumstances. Missing attachments won't stop Confluence performing normally; the missing attachments won't be available, but users may be able to upload them again.

 

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

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

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

定義

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

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

  • ラベルなし