ディザスタ リカバリ戦略は、事業継続計画の重要な部分です。これは、災害発生時に従う必要があるプロセスを定義し、事業を復旧してスタンバイ システムから業務を継続することを保証します。つまり、プライマリ システムが利用できなくなった場合でも、Bitbucket インスタンス、および Bitbucket が管理しているデータ (ソース コード) を利用できるようにします。

概要

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

最初に、以降のサブセクションに目を通し、このガイドで使用されるさまざまなコンポーネントや用語、このガイドの内容に従うために実現する必要がある要件、および、このガイドで説明される操作を実行するために使用されるサンプル スクリプトをご確認ください。

用語

コールド スタンバイ - このガイドでは、一般に "コールド スタンバイ" 戦略と呼ばれるものについて説明しています。つまり、スタンバイ Bitbucket インスタンスは継続的に実行されておらず、災害が発生した場合はスタンバイ インスタンスを開始するための管理手順が必要です。
 

目標復旧ポイント (RPO) - 障害発生後に Bitbucket インスタンスをどの程度最新の状態にする必要があるか。

目標復旧時間 (RTO) - 障害発生後にスタンバイ システムをどの程度の時間で利用できるようにする必要があるか。

目標復旧コスト (RCO) - ディザスタ リカバリ ソリューションにどの程度の金額をかける意思があるか。

コンポーネント

A typical deployment of Bitbucket with a standby for Disaster Recovery is depicted in the following diagram. The standby Bitbucket and Mesh instances are "cold" (i.e., not running) and the shared file server, database and (optionally) search server are "warm" (i.e., running) so that replication can occur. 

^{一般的な DR デプロイメントのコンポーネント図}

データ ソースのレプリケーション

プライマリ Bitbucket システムをスタンバイ システムにレプリケーションするには、次の内容が必要です。

1. 共有ホーム ディレクトリが、リモート スタンバイへの原子的なスナップショットレベルのレプリケーションをサポートしているファイル システム上にあること。
2. your database to be capable of replication to a remote standby, and
3. your Mesh home directories to be on a file system that supports atomic snapshot-level replication to a remote standby, if you use Mesh for managing your repositories.

ファイル システム

The shared home directory contains your repository data, log files, user-installed plugins, and so on (see Set the home directory for more detail). You need to replicate your shared home directory onto your standby file server. This process needs to be quick, reliable, and incremental to ensure the standby is as up to date as possible.

  ディスクの Git リポジトリのデータ整合性を保持する、ファイル システム レプリケーション テクノロジーを選択する必要があります。 

たとえば、転送中にリポジトリが変更されて破損が発生する可能性があるため、RSync などのレプリケーション テクノロジーはこの要件を満たしません。

必要なレベルの一貫性を実現するための最適な方法は、原子ブロック レベルのスナップショットをサポートするファイル システムを使用することです。スタンバイへのレプリケーションの所要時間にかかわらず、スナップショットのすべてのファイルは同じタイミングで凍結されます。サンプル スクリプトでは ZFS を Bitbucket の共有ホームとして実装しています。これは、リモート システムに転送およびリストア可能な軽量なスナップショットを実現します。

データベース

データベースには、プル リクエスト、コメント、ユーザー、グループ、権限などについてのデータが含まれます。RPO を実現するには、データベースをレプリケートし、最新の状態を継続的に維持する必要があります。

サポート対象のデータベース テクノロジーを選択する際の詳細については「サポート対象のプラットフォーム - データベース」をご確認ください。

Mesh nodes

If you use Mesh to manage your Git repositories, you’ll also need to create cold standby instances for each of your Mesh nodes. We’re exploring support for multi-region deployments of Mesh to ensure each repository is replicated to multiple regions. In such a deployment, Mesh would support hot standby nodes that would be kept in sync by Mesh itself.

検索サーバー

Elasticsearch のデータはデータベースとリポジトリのコンテンツから取得されるため、これは技術的には主要なデータの保存先ではありません。Bitbucket 検索は古いインデックスを検出し、それを再帰的に再構築します。しかしながら、特に大規模なインストールの場合、検索インデックスの再構築は時間がかかるほか、再構築中は検索機能が影響を受ける可能性があります。

When the search server is unavailable the core Bitbucket functionality continues to operate normally. Only the search functionality is impacted if the search server is offline or out of date. Bitbucket will serve search queries while its index is being rebuilt, but the search results will not be entirely complete or accurate until the index is completely rebuilt. The search server can be replicated at a lower frequency than the database and file system as Bitbucket only incrementally updates its search index. For example if the search index is a day out of sync, only the changes for the last day need to be indexed. Here are some examples of strategies for search server replication:

• レプリケーションなし – Bitbucket はスタンバイ インスタンスがオンラインになったときに検索インデックスを再構築します
• Backup and restore (low frequency) – Make regular backups of the search server and restore them on the standby instance. Bitbucket will bring the search index up to date when the standby comes online
• バックアップおよびリストア (高頻度) – プライマリのスナップショットを作成し、スタンバイにスナップショットを高頻度でリストアすることで、スタンバイがオンラインになったタイミングでインデックスを最新化するための時間を最小化します。

The example scripts implement search server snapshots using either s3 or the shared filesystem as the snapshot repository. These scripts will configure the snapshot repository and take manual snapshots.

これらのデータ ソースが Bitbucket インスタンスの全体的な状態を保持します。プラグインで追加されたファイルなどの他の手段で追加されたファイルには、別のレプリケーション手段が必要です。このような場合、プラグイン ベンダー推奨事項についてお問い合わせください。

動作確認ずみのサンプル スクリプト

アトラシアンでは atlassian-bitbucket-diy-backup リポジトリで動作確認済みのサンプル スクリプトを提供しています。ディザスタ リカバリのレプリケーションおよびフェイルオーバー プロセスを自動化するために、これを任意で使用できます。動作確認済みのサンプルは現在、次のテクノロジーについてのみ提供されています。

これらのスクリプトは、完全に動作する DR ソリューションではなく開始点として提供されており、ご利用の環境に合わせて構成およびカスタマイズしたあとにのみ使用する必要があります。

スクリプトを取得するには、atlassian-bitbucket-diy-backup の最新バージョンをクローンまたはプルします。

git clone git@bitbucket.org:atlassianlabs/atlassian-bitbucket-diy-backup.git

The scripts must be configured before use by copying the appropriate bitbucket.diy-backup.vars.sh.example to bitbucket.diy-backup.vars.sh, and editing to match your environment. Valid configurations for Disaster Recovery are:

STANDBY_HOME_TYPE=
              
                zfs
              
            
          

STANDBY_DATABASE_TYPE=
                
                  amazon-rds
                
              
               or   postgresql 

You must configure additional variables for these home and database types, and install the same scripts on both the primary and standby systems to use them for Disaster Recovery. Refer to bitbucket.diy-backup.vars.sh.example in the atlassian-bitbucket-diy-backup repository for more information on configuring the scripts for Disaster Recovery.

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

ステップ 1. Bitbucket Data Center 4.8 以降をインストールする

Install Bitbucket Data Center on the standby instance the same way you would set up a primary instance. The standby instance is effectively an exact replica of the primary instance, and therefore requires all the components deployed in the primary to be deployed in the standby. This includes a single node or clustered data center instance, database, search server and a file server to serve the shared home folder. See Installing Bitbucket Data Center for specific, detailed installation procedures. 

If you use Mesh to manage your repository data, provision a standby Mesh node for each node in your primary instance. Install Mesh on the standby instance the same way you would set up the primary instance, but DO NOT start Mesh on the standby and don’t register the node with Bitbucket.

ステップ 2. スタンバイ インスタンスへのレプリケーションのセットアップ

このセクションでは、災害が発生したときに最小限のデータ損失でフェイルオーバーを行えるようにする、スタンバイ インスタンスへのレプリケーションのセットアップ手順について説明します。

1. Set up file server replication - Set up your standby file server as a replica of your primary. Only the volume containing Bitbucket's shared home directory and any added data stores need to be replicated. Refer to your file server vendor's documentation for more information.

   動作確認済みのサンプル

   atlassian-bitbucket-diy-backup にある動作確認済みのサンプル スクリプトを使用する場合、プライマリ ファイル サーバーで次のコマンドを実行できます。

   ./setup-disk-replication.sh

2. Set up Mesh home directory replication - For each of your Mesh nodes, set up the standby node as a replica of the primary node. Only the volume containing Mesh's home directory need to be replicated. Refer to your file server vendor's documentation for more information.  

   動作確認済みのサンプル

   If using the atlassian-bitbucket-diy-backup worked example scripts, then you can run this command on the primary Mesh node:

   ./setup-disk-replication.sh

3. Set up database replication - Set up your standby database as a read replica of your primary database. Refer to your database vendor's documentation for more information.
   

   動作確認済みのサンプル

   atlassian-bitbucket-diy-backup にある動作確認済みのサンプル スクリプトを使用する場合、スタンバイ データベースで次のコマンドを実行できます。

   ./setup-db-replication.sh

4. Set up search server replication (optional)  - The developers of Elasticsearch, provide detailed instructions on setting up snapshot repositories and how the snapshots contained in these repositories can be transferred to the standby cluster. See their article titled  Snapshot And Restore  for more information. The example scripts   will configure the snapshot repository and take manual snapshots using either an s3 or shared filesystem repository.

ステップ 3. レプリケーションの初期化

Once you setup replication, ensure the primary instance is replicating to the standby instance. The method of replication varies depending on the chosen technology. Once set up correctly, most database replication technologies are automatic and do not require ongoing manual steps. File system replication technologies may require the ongoing transfer of snapshots from the primary system to the standby to be automated (for example, via cron).

./replicate-disk.sh

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

Practice makes perfect, and this applies to verifying your DR failover process, but there is a serious caveat. As Bitbucket's configuration lives in the shared home folder which is replicated from the primary, the settings in the bitbucket.properties file points at production instances, which must be changed before starting the standby instance for testing.

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

スタンバイ インスタンスはプライマリと同様に構成されているため、ディザスタ リカバリ プランのテスト時に問題が発生する可能性がある点にご注意ください。Bitbucket をディザスタ リカバリ モードで実行していて、ファイル サーバーとデータベースとの動機が失われていることを整合性チェッカーが検出した場合、エラーの修正が試行される可能性があります。これには、プル リクエストのマージ、再オープン、および却下が含まれ、これによってアプリケーション リンク経由で Jira チケットが更新されたり、メール通知が送信されたりする可能性があります。

DR デプロイメントをテストする前に

スタンバイ インスタンスがプライマリ インスタンスから分離されていることを確認する方法

1. データベースの分離 - スタンバイ インスタンスへのすべてのレプリケーションを一時的に停止し、スタンバイ データベースをプロモートします。

   動作確認済みのサンプル

   atlassian-bitbucket-diy-backup にある動作確認済みのサンプル スクリプトを使用する場合、スタンバイ データベースで次のコマンドを実行できます。

   ./promote-db.sh

2. ファイル システムの分離 - スタンバイ インスタンスへのすべてのレプリケーションを一時的に停止し、スタンバイ ファイル システムをプロモートします。

   動作確認済みのサンプル

   atlassian-bitbucket-diy-backup にある動作確認済みのサンプル スクリプトを使用する場合、スタンバイ ファイル サーバーで次のコマンドを実行できます。

   ./promote-home.sh

3. Isolate your Mesh nodes - Temporarily pause replication to each of your standby Mesh nodes' home directory, then promote the standby file system.

   動作確認済みのサンプル

   If using the atlassian-bitbucket-diy-backup worked example scripts, you can run this command on each of the standby Mesh nodes:

   ./promote-home.sh

4. Edit the bitbucket.properties file on the standby -  Update the bitbucket.properties file located in the Bitbucket shared home on the standby file server. C hange these properties:
   1. JDBC 接続のプロパティ。
   2. The search server connection properties.
   3. Set disaster.recovery=true .
   4. スタンバイの要素を使用するよう、本番環境インスタンスの他の任意の設定を更新します。

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

スタンバイ インスタンスを分離したら、ディザスタ リカバリ プランをテストできます。

DR デプロイメントのテスト方法

1. スタンバイ データベースがプロモートされ、書き込み可能であることを確認します。
2. 新しい共有ホーム ディレクトリの準備が整っていることを確認します。
3. For each of your Mesh nodes, ensure that the new home directory is ready and start Mesh.
4. Ensure your bitbucket.properties file is correctly configured.
5. Bitbucket を開始します。
6. 「Bitbucket Data Center で整合性チェックを実行する」の記述に従い、Bitbucket のログ ファイルを監視して一貫性の問題を確認します。

テストの完了後、DR デプロイメントをリセット

DR デプロイメントのリセットにはスタンバイ コンポーネントをレプリケーション可能な状態に戻す作業が含まれますが、この状態は選択したファイル サーバーおよびデータベースのレプリケーション テクノロジーに応じて異なります。ほとんどの場合、スタンバイ インフラストラクチャをセットアップする方が簡単です。

DR デプロイメントのリセット方法

1. スタンバイ インスタンスの検証が完了したら、Bitbucket を停止します。
2. ファイル サーバーを、レプリケーションが開始可能な状態に復元します。
3. Restore each of Mesh nodes to a state in which replication can begin.
4. データベースを、レプリケーションが開始可能な状態に復元します。 

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

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

スタンバイ インスタンスへのフェイルオーバー方法

1. スタンバイ データベースのプロモート - スタンバイ データベースでコネクションを許可する準備が整っていて、プライマリから更新を受け取らないようになっていることを確認します。詳細については、ご利用のデータベースのベンダーのドキュメントをご確認ください。

   動作確認済みのサンプル

   If using the atlassian-bitbucket-diy-backup worked example scripts, then you can run this command on the standby database:

   ./promote-db.sh

2. スタンバイ ファイル サーバーのプロモート - スタンバイ ファイル サーバーがプライマリから更新を受け取らないようになっていることを確認します。詳細については、ご利用のファイル サーバーのベンダーのドキュメントをご確認ください。

   動作確認済みのサンプル

   If using the atlassian-bitbucket-diy-backup worked example scripts, then you can run this command on the standby file server:

   ./promote-home.sh

3. Promote and start your standby Mesh nodes - For each Mesh node:
   a. Ensure the the standby Mesh node can not receive any further updates from its corresponding primary. Refer to your file system provider’s documentation for more information.

   動作確認済みのサンプル

   If using the atlassian-bitbucket-diy-backup worked example scripts, then you can run this command on the standby Mesh node:

   ./promote-home.sh

   
   b. Once the Mesh home directory has been promoted, start Mesh.
   c. Connect to the (promoted) standby database and update the Mesh node URL to the (promoted) standby Mesh node instead of the primary.

   update bb_mesh_node set rpc_url='<standby_url>' where rpc_url='<primary_url>';

4. Edit the bitbucket.properties file on the standby - Update the bitbucket.properties file located in the Bitbucket shared home on the standby file server. Set  disaster.recovery=true , and ensure all the properties are appropriate for the standby environment. At a minimum, check that these properties are defined:

   disaster.recovery=true

   jdbc.url=<the URL of your standby database>

   plugin.search.config.baseurl=<the URL of your standby search server>

   hazelcast.network.tcpip.members=<the IP addresses of your standby cluster nodes>

   Note that during normal replication, bitbucket.properties on the standby is identical to the primary system. During failover, it is important to ensure the configuration of your bitbucket.properties file matches the standby system's configuration before you start Bitbucket on the standby, or the standby may not start or attempt to connect to services in the primary's environment.

5. スタンバイ インスタンスの 1 つのノードで Bitbucket を開始します。

6. 「Bitbucket Data Center で整合性チェックを実行する」の記述に従い、Bitbucket のログ ファイルを監視して一貫性の問題を確認します。

7. 必要に応じて他の Bitbucket ノードを開始します。

8. トラフィックをスタンバイ サーバーに転送するように、DNS、HTTP プロキシ、または他のフロントエンド デバイスを更新します。

9. メール サーバーが本番環境のメール サーバーと異なる場合、メール サーバーの構成を更新します。

10. If you’re using Mesh, continue to monitor the Bitbucket logs and check for failing pushes; they may be an indication of inconsistent repository replicas. For any such repository, try to push a new branch or tag to the repository to trigger repairs. For more details, see BSERV-13312 - Getting issue details... STATUS

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

ほとんどの場合、災害の原因となった問題を解決したら、プライマリ インスタンスを使用する状態に戻すことになります。これには基本的に 2 つのアプローチがあります。

1. 適切な長さの停止期間をスケジュールします。スタンバイ システムのホーム ディレクトリとデータベースの完全なバックアップを作成し (例: 「データ リカバリとバックアップ」で説明されているツールを使用)、それをプライマリ システムにリストアします。
2. Take a full backup of each Mesh node’s home directory and restore it on the primary system.
3. レプリケーションとフェイルオーバーを逆に実行し、移行が完了するまでの間、スタンバイ システムをプライマリ、元のプライマリ システムをスタンバイとして扱います。 

その他のリソース 

トラブルシューティング 

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