High availability for Bitbucket
このページでは、高可用性設定での単一の Bitbucket Server サーバーのセットアップ方法について説明します。
For production installs, we highly recommend that you first read Use Bitbucket in the enterprise.
For Active/Active high availability with Bitbucket Server, see Bitbucket Data Center resources instead.
ディザスタ リカバリ戦略の一部としての Bitbucket Data Center の使用に関するガイダンスについては、「Bitbucket Data Center のディザスタ リカバリ ガイド」を参照してください。
If Bitbucket Server is a critical part of your development workflow, maximizing application availability becomes an important consideration. There are many possible configurations for setting up a HA environment for Bitbucket Server, depending on the infrastructure components and software (SAN, etc.) you have at your disposal. This guide provides a high-level overview and the background information you need to be able to set up a single Bitbucket Server in a highly available configuration.
Note that Atlassian's Bitbucket Data Center resources product uses a cluster of Bitbucket Server nodes to provide Active/Active failover. It is the deployment option of choice for larger enterprises that require high availability and performance at scale, and is fully supported by Atlassian. Read about Failover for Bitbucket Data Center.
高可用性
「高可用性」では、冗長性を通じて障害を排除/軽減し、特定のレベルの "可用性" を提供することを目的とした、一連のプラクティスを確認できます。障害は、ネットワーク エラー、ハードウェア障害、またはアプリケーション障害による予期しないダウンタイムや、アプリケーション アップグレードの失敗によって発生する可能性があります。高可用性システムのセットアップでは、次の点を考慮します。
プロアクティブな考慮事項
- 変更管理 (変更を適用するためのステージングおよび本番インスタンスを含む)
- ネットワーク、アプリケーション、ストレージ、およびデータベースの冗長性
- ネットワークとアプリケーションの両方でのシステムの監視
リアクティブな考慮事項
- 技術的なフェイルオーバー メカニズム (自動、または手動でのスイッチオーバーを伴うスクリプト化された半自動フェイルオーバー)
- 危機的状況におけるガイド アクションの標準操作手順
このガイドでは、変更管理などのプロセスがはすでに網羅されていると見なし、冗長性/レプリケーションとフェイルオーバー手順に焦点を当てます。システムやアプリケーション障害からすばやく復旧できるようにインフラストラクチャをセットアップする際には、さまざまなオプションがあります。これらのオプションでは、提供されるアップタイムのレベルが異なります。一般に、必要なアップタイムが増えると、インフラストラクチャや、環境を管理するために必要な知識の複雑性も増します (拡張によってコストも増加します)。
Bitbucket Server の可用性要件を理解する
Subversion、CVS、ClearCase およびその他の多くの中央バージョン管理システムでは、バージョン管理システムの任意の操作で利用可能な中央サーバーが必要です。コードのコミット、リポジトリからの最新の変更の取得、ブランチの切り替え、または差分の取得ではすべて、中央バージョン管理システムにアクセスする必要があります。このサーバーがダウンすると、開発者ができる作業は大幅に制限されます。コミットの準備が整うまでコーディングを続行することはできますが、その後はブロックされます。
Git は分散型バージョン管理システムであり、開発者は自身のマシンにリポジトリの完全なクローンを持ちます。その結果、バージョン管理システムに関連するほとんどの操作で、中央リポジトリにアクセスする必要がなくなります。Bitbucket Server が利用できない場合に、開発者が中央バージョン管理システムを使用している場合と同じレベルでブロックされることはありません。
結果として、Bitbucket Server の可用性要件は、Subversion の要件よりも厳しくない可能性があります。
Bitbucket Server が利用できない場合の結果 | |
|---|---|
 影響を受けない |  影響を受ける |
開発者
| 開発者
ビルド サーバー
継続的デプロイ
|
フェイルオーバー オプション
高可用性およびリカバリ ソリューションは次のように分類することができます。
フェイルオーバー オプション | 復旧時間 | 説明 | Bitbucket Server での利用可否 |
|---|---|---|---|
| 自動修正/再起動 | 2 ～ 10 分 (アプリケーションの不具合) 数日～数時間 (システムの不具合) |
| |
| コールド スタンバイ | 2 ~ 10 分 |
| |
| ウォーム スタンバイ | 0 ~ 30 秒 |
| |
| アクティブ/アクティブ | < 5 秒 |
| |
自動修正
Bitbucket Server インスタンスにフェイルオーバー ソリューションを実装する前に、自動修正策の評価と活用を検討してください。これらは、アプリケーションをウォッチし、サービスを開始、停止、中止、または再起動するためのスクリプトを実行する監視サービスを通じて実装できます。
- 管理サービスは、システムで障害が発生したことを検出します。
- 修正スクリプトは、エラーが発生したシステムのシャットダウンを試みます。
- 定義した時間が経過した後にシステムが適切にシャットダウンされない場合、修正スクリプトによってプロセスが終了されます。
- プロセスが実行されていないことを確認したら、再起動します。
- この再起動によって問題が解消された場合、メカニズムは終了します。
- 修正の一部または全部が失敗した場合、フェイルオーバー メカニズムがトリガーされことが想定されます (実装されている場合)。
コールド スタンバイ
The cold standby (also called Active/Passive) configuration consists of two identical Bitbucket Server instances, where only one server is ever running at a time. The Bitbucket home directory on each of the servers is replicated from the active to the standby Bitbucket Server instance. When a system failure is detected, Bitbucket Server is restarted on the active server. If the system failure persists, a failover mechanism is started that shuts down Bitbucket Server on the active server and starts Bitbucket Server on the standby server, which is promoted to 'active'. At this time, all requests should be routed to the newly active server.
高可用性対策のチェーンにある各コンポーネントにはさまざまな実装オプションがあります。アトラシアンでは特定のテクノロジーや製品は推奨していませんが、このガイドでは各ステップのオプションを提供します。
システム セットアップ
このセクションでは、Bitbucket Server の 1 つのインスタンスを高可用性を実現するためのセットアップ方法として、考えられる設定の 1 つについて説明します。
コンポーネント
リクエスト ルーター
ユーザーからアクティブな Bitbucket Server インスタンスにトラフィックを転送します。
高可用性マネージャー
- アプリケーション サーバーの健康状態を追跡し、スタンバイ サーバ ーへのフェイルオーバーのタイミングを判断し、それをアクティブとして指定します。
- フェイルオーバー メカニズムを管理し、システムの不具合が発生した際に通知を送信します。
Bitbucket Server インスタンス
- 各サーバーは同じ Bitbucket Server インストール(同一のバージョン) をホストします。
- 一度に実行される Bitbucket Serverは 1 台のみ (アクティブ サーバー) です。それ以外はすべてスタンバイとみなされます。
- すべてのアプリケーション サーバーで表示可能な、レプリケートされたファイル システムや共有ファイル システムに常駐します。
- サーバーがスタンバイ モードになっているときに変更を加えないでください。
Bitbucket Server DB
本番環境データベース。高可用性を実現している必要があります。この方法については、このドキュメントでは説明していません。次のデータベース ベンダー固有の情報で、利用可能な HA オプションを確認してください。
- Postgres
http://www.postgresql.org/docs/9.2/static/high-availability.htm - MySQL
http://dev.mysql.com/doc/refman/5.5/en/ha-overview.html - Oracle
http://www.oracle.com/technetwork/database/features/availability/index.html - SQL Server
http://technet.microsoft.com/en-us/library/ms190202.aspx
ライセンス
開発者ライセンスは、コールド スタンバイ サーバーにデプロイされた、Bitbucket Server の非本番インストールで使用できます。詳細は、開発者ライセンスを参照してください。