Bitbucket Data Center のディザスタ リカバリ ガイド

This feature is only for customers with an active Bitbucket Data Center resources license.

このページでは、ディザスタ リカバリ戦略を実装および管理するために Bitbucket Data Center を構成する方法について説明しています。ただし、主要目標 (RTO、RPO、RCO1) や標準運用手順の設定のような幅広いビジネス プラクティスは網羅していません。

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

概要

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

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

用語

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

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

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

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


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

"高可用性"、"ディザスタ リカバリ"、および "フェイルオーバー" の用語は混同されがちです。混乱を避けるため、ここではこれらの用語を次のように定義します。

高可用性 – 特定のレベルの可用性を提供する戦略。Bitbucket の場合は、アプリケーションへのアクセスと許容応答時間です。自動修正と (同じ場所内での) フェイルオーバーは通常、高可用性計画の一部です。

ディザスタ リカバリ – 災害が発生してメインのデータセンターが利用できなくなった場合に、(通常は地理的に離れた場所にある) 代替データセンターで運用を再開する戦略。(別の場所への) フェイルオーバーはディザスタ リカバリの基本的な部分です。 

フェイルオーバー - あるマシンが故障した際に、そのマシンから別のマシンに引き継ぐことを指します。これは同じデータセンター内またはあるデータセンターから別のデータセンターで行われます。フェイルオーバーは通常、高可用性戦略とディザスタ リカバリ計画の両方の一部です。

コンポーネント

ディザスタ リカバリ用のスタンバイを持つ Bitbucket の一般的なデプロイメントを、次の図で示します。スタンバイ Bitbucket インスタンスは "コールド" (実行されていない) で、共有ファイル サーバー、データベース、および (任意) Elasticsearch インスタンスは "ウォーム" (実行中) であるため、レプリケーションを発生させることができます。 

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

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

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

  1. 共有ホーム ディレクトリが、リモート スタンバイへの原子的なスナップショットレベルのレプリケーションをサポートしているファイル システム上にあること。
  2. データベースがリモート スタンバイへのレプリケーションを行えるものであること。

ファイル システム

共有ホーム ディレクトリには、リポジトリ データ、ログ ファイル、ユーザーがインストールしたプラグインなどが含まれます (詳細については「Bitbucket Server のホーム ディレクトリ」を参照)。共有ホーム ディレクトリをスタンバイ ファイルサーバーにレプリケートする必要があります。このプロセスは、素早く信頼性があり、スタンバイを可能な限り最新の情報に保てるように反復可能である必要があります。

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

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

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

データベース

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

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


Elasticsearch

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

Elasticsearch が利用できない場合も、Bitbucket の中核機能は引き続き通常どおり動作します。Elasticsearch がオフラインになったり、古くなってしまったりした場合、検索機能のみが影響を受けます。Bitbucket はインデックスの再構築中に検索クエリを提供しますが、インデックスの再構築が完全に完了するまでは、検索結果が不完全だったり、不正確だったりする場合があります。Bitbucket は Elasticsearch の検索インデックスを再帰的にのみ更新するため、Elasticsearch のレプリケーションはデータベースおよびファイル システムよりも低い頻度で行うことができます。たとえば、検索インデックスの同期が 1 日分遅れている場合、前日の変更のみがインデックスされる必要があります。Elasticsearch のレプリケーションのためのいくつかのサンプル戦略を紹介します。

  • レプリケーションなし – Bitbucket はスタンバイ インスタンスがオンラインになったときに検索インデックスを再構築します
  • バックアップおよびリストア (低頻度) – Elasticsearch の定期バックアップを作成し、それらをスタンバイ インスタンスにリストアします。Bitbucket はスタンバイがオンラインになったタイミングで検索インデックスを最新化します。
  • バックアップおよびリストア (高頻度) – プライマリのスナップショットを作成し、スタンバイにスナップショットを高頻度でリストアすることで、スタンバイがオンラインになったタイミングでインデックスを最新化するための時間を最小化します。

サンプル スクリプトでは、s3 または共有ファイルシステムをスナップショット リポジトリとして使用して Elasticsearch のスナップショットを実装しています。これらのスクリプトはスナップショット リポジトリを構成し、手動スナップショットを作成します。


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

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

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

ファイル システムデータベース
  • ZFS ファイルシステム

これらのスクリプトは、完全に動作する 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.

Update to the latest version of the backup scripts

When you create an EBS snapshot, the scripts now tag it with the name of the EBS volume. This 'Device' tag allows the snapshot to be automatically cleaned up, and without it you cannot restore your snapshot.

If you took your snapshot with scripts created before 18 September 2018, it won't have a 'Device' tag and you won't be able to restore it. To fix this, use the AWS console to add a tag to the EBS snapshot with with "Device" as the key and "<device_name>" as the value. <device_name> should be the device name of the EBS volume holding the shared home directory (e.g. "Device" : "/dev/xvdf").

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

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

プライマリ インスタンスをセットアップしたのと同じ方法で、スタンバイ インスタンスに Bitbucket Data Center をインストールします。スタンバイ インスタンスはプライマリ インスタンスの事実上の完全なレプリカであるため、プライマリにデプロイされたすべてのコンポーネントをスタンバイにもデプロイする必要があります。これには、単一ノードまたはクラスタ化されたデータセンター インスタンス、データベース、Elasticsearch、および共有ホーム フォルダを提供するためのファイル サーバーが含まれます。個々の詳細なインストール手順については「Bitbucket Data Center のインストール」をご確認ください。 

Bitbucket をスタンバイで開始しないでください

フェイルオーバー プロセスの前に 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. データベースのレプリケーションのセットアップ - スタンバイ データベースをプライマリ データベースの読み取りレプリカとしてセットアップします。詳細については、ご利用のデータベースのベンダーのドキュメントをご確認ください。

    動作確認済みのサンプル

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

    ./setup-db-replication.sh
  3. Elasticsearch のレプリケーションのセットアップ (オプション) - Elasticsearch の開発元は、スナップショット リポジトリのセットアップ方法や、それらのリポジトリに含まれるスナップショットをスタンバイ クラスタに転送する方法についての詳細な手順を提供しています。詳細については「Snapshot And Restore」というタイトルの記事をご確認ください。サンプル スクリプトは、s3 または共有ファイルシステム リポジトリを使用して、スナップショット リポジトリを構成し、手動スナップショットを作成します。

ステップ 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).

動作確認済みのサンプル

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

./replicate-disk.sh

Once file system replication is working, you may add a crontab entry for this command on a regular interval (e.g., every minute) as determined by your organization's RPO.

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

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

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

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

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

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

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

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

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

  1. スタンバイ インスタンスの検証が完了したら、Bitbucket を停止します。
  2. ファイル サーバーを、レプリケーションが開始可能な状態に復元します。
  3. データベースを、レプリケーションが開始可能な状態に復元します。 


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

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

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

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

    動作確認済みのサンプル

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

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

    動作確認済みのサンプル

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

    ./promote-home.sh
  3. 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.elasticsearch.baseurl=<the URL of your standby Elasticsearch instance>
    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.

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

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

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

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

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

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

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

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


その他のリソース 

トラブルシューティング 

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

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

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

    

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

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

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

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

  

最終更新日 2020 年 5 月 26 日

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

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