Bitbucket Data Center の FAQ

このページでは、Bitbucket Data Center に関するよくある質問に対する回答の一部を紹介しています。このページで回答されていない質問があれば、アトラシアン エンタープライズ アドボケート、アトラシアン エンタープライズ チーム、またはアトラシアン エキスパートに連絡してください。

Bitbucket Data Center とは何ですか？

Bitbucket Data Center では遠く離れた場所でディザスタ リカバリを提供していますか？

はい。Bitbucket Data Center はディザスタ リカバリ戦略を実装および管理するように設定することができます。アトラシアンでは、データを継続的にバックアップするように設定できるコールド スタンバイ インスタンスのセットアップとデプロイのガイダンスを提供しています。ディザスタ リカバリ プランの一環として Bitbucket Data Center を含める手順については、「Bitbucket Data Center のディザスタ リカバリ ガイド」を参照してください。

Bitbucket Data Center は Windows をサポートしていますか？

いいえ、Windows はサポートされません。関連情報については、サポート対象プラットフォームを参照してください。

Microsoft Azure に Bitbucket Data Center をデプロイすることはできますか？

はい、Bitbucket Data Center は Microsoft Azure をサポートしています。詳細については、「Bitbucket Data Center を Azure にデプロイ」を参照してください。 

Bitbucket Data Center ディストリビューションはどこでダウンロードできますか？

Bitbucket Server と同じく、https://www.atlassian.com/software/bitbucket/download からダウンロードすることができます。Bitbucket Data Center と Bitbucket Server は、実際には同じビルドの Bitbucket であり、クラスタリング機能とスマート ミラーリング機能を有効にするには、Data Center ライセンス キーだけが必要です。

クラスタリング

クラスタ化された Bitbucket Data Center インスタンスの利点は何ですか？

Bitbucket Data Center はユーザーには Bitbucket の単一インスタンスとして表示されますが、実際にはロード バランサーの背後でそれぞれ Bitbucket web アプリケーションを実行する複数マシンのクラスターです。これは、単一ノードの Bitbucket Data Center にはない重要な利点を提供します。

さまざまな種類の「クラスタリング」がありますが、Bitbucket Data Center では正確にはどれのことですか？

Bitbucket Data Center は完全な（アクティブ - アクティブな）クラスタ構成です。すべてのクラスタ ノードは、ユーザー リクエストのサービスやその他の処理に均等に参加します。負荷はノード間で公平に分散されます。1つのノードがダウンすると、手動運用無しで、通常数秒以内に自動的に他のノードにフェイルオーバーします。ノードがクラスタに参加（または再参加）する場合、オンラインになるとすぐに、自動的にユーザー リクエストのサービスおよびその他の処理を開始します。 

「アクティブ - アクティブ」なクラスタリングは、Bitbucket Data Center の大規模なパフォーマンスおよび高可用性という利点にとって重要です。これは、「アクティブ - パッシブ」および「コールド スタンバイ」サーバにデータをレプリケートする必要があるその他の形式のクラスタリングと同じではありません。

Bitbucket Data Center インスタンスは、アメリカ、ヨーロッパ、アジア太平洋地域など、1つ以上の地域にクラスタ ノードを持つことができますか？

いいえ、Bitbucket Data Center クラスタは単一の地域のクラスタ ノードのみをサポートするように設計されています。

しかし、ミラーを使用して異なる地域にインスタンスを提供し、リモート チーム向けに (通常は長時間かかる) Git クローンおよびフェッチを高速化することができます。

Bitbucket Data Center 準拠のアプリまたはプラグインはどれですか?

Bitbucket Data Center でサポートされるプラグインを探す最良および最新の方法は、対応する Atlassian Marketplace リストで「Data Center」バッジを確認することです。

Bitbucket アプリを開発しました。Bitbucket Data Center 互換にするにはどうしたらよいですか?

一部のアプリは開発作業を一切必要とせず、大部分が変更なしで Bitbucket Data Center で動作します。しかし、暗黙的または明示的に単一の JVM で稼働することが前提であるアプリでは、互換性のために何らかの開発作業が必要な場合もあります。プラグイン開発者向けの Bitbucket API には、クラスタで安全に使用できるアプリを簡単に作成するための多数の新サービスが含まれています。これらのサービスは一般に、ConcurrentMap、Cache、および Lock などの標準 Java API に似た API を提供するため、多くの場合、いくつかのクラスを変更するだけで、アプリをクラスタで安全に使用できます。詳細は、「クラスタで安全に使用できるプラグインの作成」を参照してください。

Jira や Bamboo などの他の Atlassian 製品と統合する際、Bitbucket Data Center で特殊な設定は必要ですか？

いいえ、Jira や Bamboo を含む他の Atlassian 製品との統合はすべて、Bitbucket Server と同様に動作します。

クラスタリングの大規模なパフォーマンス

組織に展開する必要があるクラスタ ノードはいくつですか？

いくつかのガイドラインについては、「Bitbucket Data Center パフォーマンス」で確認することができ、ご利用の環境のより具体的な推奨事項については、Enterprise Expert Partner に問い合わせることができます。ただし、これを決定する最も徹底的な方法は、テスト環境で2つのクラスノードから開始して、必要に応じてアップグレードしていくことです。

NFS が Bitbucket Data Center インスタンスのボトルネックとなることはありませんか？

特にファイル サーバーがリソース不足だったり設定に誤りがある場合、この問題が発生することがあります。しかしながら、アトラシアンが独自に行った Bitbucket Data Center のパフォーマンス テストでは、適切にリソース配分および設定された NFS サーバーは、非常に高い負荷下でも適切に動作することが確認されています。

クラスタリングの高可用性

使用する必要があるクラスタ ノードの最小数はいくつですか？

ホット フェイルオーバーを実現するには、最低 2 つのノード (最大 8 つまで) を用意することをお勧めします。

Bitbucket Data Center でフェイルオーバーはどれくらい早く動作しますか？

Bitbucket Data Center は完全なアクティブ - アクティブなクラスタリングを提供しているため、ノードがダウンした場合のフェイルオーバーは数秒で実施することができます。「コールド スタンバイ」の起動、すべてのデータの一貫したレプリケート、またはDNS にトラフィックがリダイレクトが伝播するまで待つ必要はありません。これらはすべて、Bitbucket Data Center で自動的およびシームレスに処理され、システム管理者の介入は不要です。詳細については、「Bitbucket Data Center のフェイルオーバー」を参照してください。

クラスタ ノードがダウンした場合、そのノードにログインしていたユーザーはどうなりますか？

クラスタ ノードがダウンした場合、ほとんどのロード バランサは障害を検出し、トラフィックを数秒以内に他のノードに誘導します。ただし、クラスタ ノードがダウンした際にそのノードをアクティブに使用していたユーザーは、いくつかの方法で障害に気づく可能性があります。

• 障害が発生したノードで処理されているオープンな Git クローン、フェッチ、またはプッシュ接続が破損している可能性があります（再試行すると成功します）。 

• 障害が発生したノードに誘導されているセッションを持つユーザーはログアウトさせられ（デフォルト）、再度 Bitbucket にログインする必要があります。ただし、この追加のログインは以下の方法で避けることができます。
  • ログイン時に「ログインしたままにする」をオンにしているユーザーは、再度ログインする必要はありません。 
  • Crowd によるシングル サインオン（SSO）を有効にしている場合、Crowd ディレクトリが SSO 向けに設定されているユーザーは、再度ログインする必要はありません。詳細については、「Bitbucket を Crowd に接続する」を参照してください。 
  • 独自のカスタム (社内またはサードパーティ) 認証プラグインを使用している場合、プラグインがクラスタ対応となるよう作成されていれば、追加でのログインを回避することができます。 

• ダウンしたノードのセッションに保存されているその他のデータ (複数ページ フォームの 1 つのページに入力されたフィールドなど) は失われ、再入力が必要となる場合があります。Bitbucket およびアトラシアンが提供するほとんどのアプリはセッションにこれらの状態を保存しませんが、Bitbucket Data Center 用に設計されていないサードパーティ製アプリでは保存される場合もあります。 

• 障害が発生したノードで実行されている、プル リクエストのリスコープ、コメント ドリフトの計算、またはユーザー ディレクトリの同期などのバックグラウンドの作業は別のクラスタに引き継がれるため、完了に少し時間がかかる可能性があります。 

詳細については、「Bitbucket Data Center のフェイルオーバー」を参照してください。

Bitbucket Data Center はダウンタイムなしでアップグレード（すなわちローリング アップグレード）することはできますか？

Bitbucket Data Center では、バグ修正アップグレード (たとえば Bitbucket 7.9.0 から 7.9.4) の場合に限り、ダウンタイムなしでローリング アップグレードできます。現在、プラットフォーム アップグレード (Bitbucket 7.0 から 8.0) または機能アップグレード (7.4 から 7.8) では、ローリング アップグレードを利用できません。詳細については「ダウンタイムなしで Bitbucket をアップグレードする方法」と「Bitbucket Data Center アップグレード ガイド」をご参照ください。

クラスタリングの技術要件

どのように Bitbucket Server インスタンスから Bitbucket Data Center に移動しますか？

単に「Bitbucket Server から Bitbucket Data Center にアップグレードする」の手順に従ってください。ライセンス キーを Bitbucket Data Center キーに更新することを忘れないでください。

Bitbucket Data Center のクラスタリングはマルチキャスト非対応ネットワークをサポートしていますか？

はい。マルチキャスト ディスカバリは、クラスタ ノードが互いを検出するための一般的な方法ですが、ネットワークがマルチキャストをサポートしていない場合、bitbucket.properties ファイルに hazelcast.network.tcpip=true を設定し、hazelcast.network.tcpip.members をクラスタ ノードのカンマ区切りリストに設定できます。詳細については、「Bitbucket Data Center のインストール」を参照してください。

Bitbucket Data Center のクラスタリングは、CIFS/SMB、iSCSI、GlusterFS、またはその他のファイル システム マウント タイプをサポートしていますか？

現時点ではサポートしていません。お問い合わせください。 

Bitbucket Data Center のクラスタリングは Amazon Web Services （AWS）をサポートしていますか？

はい。アトラシアンと Amazon は、Bitbucket Data Center 用の標準的で自動化されたリファレンス デプロイを公開しています。これには、クイック スタート ガイドや AWS CloudFormation テンプレートが含まれています。このテンプレートは、セキュリティや可用性についての AWS のベスト プラクティスに従って、AWS での Bitbucket Data Center の完全な本番デプロイに必要な AWS 計算、ネットワーク、ストレージ、その他のサービスを起動、設定、実行するものです。詳細については、「Amazon クイック スタート」や「AWS での Bitbucket Data Center」を参照してください。

Bitbucket Data Center のクラスタリングは Amazon EFS をサポートしていますか？

はい、Bitbucket Data Center は Amazon EFS をサポートしています。Bitbucket の共有ホーム ディレクトリから Bitbucket Mesh にすべての Git リポジトリを移行すると、ご利用になれます。クラウド プラットフォームのサポートに関する詳細

Bitbucket Data Center でサポートされる NFS のバージョンは何ですか?

NFSv3 がサポートされています。Bitbucket Meshを使用していて、すべての Git リポジトリを Bitbucket Mesh に移行している場合は、共有ホームディレクトリに NFSv4 を使用できます。

Bitbucket Data Center でサポートされるロード バランサは何ですか？

アトラシアンにロード バランサ (ハードウェアまたはソフトウェア) を提供するベンダーは非常にたくさんあり、そのすべてが特定のガイダンスを提供しています。サポートされているものであれば、任意のロード バランサを選択することができます。

• HTTP モード（web トラフィック用）および TCP モード（ssh トラフィック用）の両方
• Bitbucket からの HTTPS 暗号化および復号化をオフロードする SSL termination、および
• cookie ベースのセッション アフィニティ（「スティッキー セッション」）

ご使用のロード バランサに固有の設定がない場合、「Bitbucket Data Center のインストール」で、人気の高いオープン ソースのソフトウェア ロード バランサである haproxy の説明を参照してください。

Bitbucket Data Center でサポートされるデータベースは何ですか？

通常のデータベース (「サポートされるプラットフォーム」を参照) はすべて、Bitbucket Data Center でサポートされます。ただし例外として、現時点では MySQL (すべてのバージョン) は Bitbucket Data Center ではサポートされていません。これは、高負荷によってこのデータベース エンジン特有のデッドロックが発生する可能性があるためです。現在 MySQL を使用している場合は、まずサポートされている他のデータベース (PostgreSQL など) にデータを移行してください。詳細については、「Bitbucket を外部データベースに接続する」を参照してください。 

クラスタ化されている場合 Bitbucket Data Center のデータベースを移行することはできますか？

いいえ。複数のクラスタ ノードが実行されている場合、Bitbucket Data Center インスタンスではデータベース移行ウィザードはサポートされていません。Bitbucket Data Center インスタンスのデータベースを移行するには、複数のクラスタ ノードを起動する前に移行を実行する必要があります。

Bitbucket Data Center のクラスタ化されたインスタンスをバックアップするにはどのような方法がサポートされていますか？

ゼロ ダウンタイム バックアップは Bitbucket 4.8 で導入された技術であり、メンテナンス用にロックする必要なく、Bitbucket をバックアップします。共有ホーム ディレクトリがアトミック（ブロックレベル）スナップショットが可能なファイル システム ボリュームにある必要があり、データベースはアトミック バックアップかポイント イン タイム リカバリが可能である必要があります。これらの技術を使用すると、頻繁にダウンタイムを発生させてユーザーや構築エージェントに迷惑をかけずに、必要な頻度（毎時など）でバックアップを取ることができます。

DIY バックアップは Bitbucket Data Center の全バージョンで完全にサポートされています。DIY バックアップを実行するマシンがエンドポイントへの接続性を持っている場合、Bitbucket インスタンス（すなわちロード バランサ）や特定のクラスタ ノードの URL に対して DIY バックアップ スクリプトを指定するかどうかは関係ありません。DIY バックアップスクリプトが Bitbucket をロックして実行する限り、すべてのクラスタ ノードは実行中のデータベースやファイルシステム操作を排除して、「バックアップの実行中」ページを表示します。Bitbucket Server で動作するほとんどの DIY バックアップ スクリプトは、Bitbucket Data Center でほとんど変更せずに動作するはずです。 

シングル ノードに切り替えたとしても、Bitbucket Backup Client はクラスタ化された Bitbucket Backup Center インスタンスと互換性がありません。現時点では、Bitbucket Backup Client がクラスタ化された Bitbucket のインスタンスで動作するようにする計画はありません。

Bitbucket Data Center のバックアップのさまざまな方法については、「データ復旧とバックアップ」の記事を確認してください。

Elasticsearch データをバックアップ戦略の一部としてバックアップする必要がありますか？

いいえ。リモートの Elasticsearch インスタンスがある場合、検索インデックスは Elasticsearch のデータ ディレクトリに保持されます。これは必要に応じてホーム ディレクトリおよびデータベース データから完全に再構築できるため、バックアップに含める必要はありません。大規模なインスタンスの場合、Elasticsearch インデックスの再構築に数時間がかかる可能性があることにご注意ください。Elasticsearch インデックスが再構築される間は検索機能のパフォーマンスが低下する可能性があります。 

Bitbucket Mesh

Bitbucket Mesh のメリットは何ですか?

Bitbucket Mesh は、分散、複製された水平方向に拡張可能な Git リポジトリ ストレージで、パフォーマンスと可用性の向上を実現します。Mesh は、Git のホスティングとデータ処理を独立した複数のノードに分散します。これによって I/O レイテンシが大幅に減少して、パフォーマンスの低下を心配せずにスケーリングを実行できます。Bitbucket Mesh の詳細についてご確認ください。

Mesh ノードは少なくとも何個必要ですか?

高可用性を実現するには、最低 3 つの Mesh ノードを使用することをお勧めします。なお、ノード数に上限はありません。

Git ストレージ用の NFS で Bitbucket Data Center を引き続き実行できますか? または、8.x にアップグレード後に Mesh ノードをデプロイする必要がありますか?

実際は、8.x にアップグレードして共有ファイル システムを引き続き使用できます。Mesh の使用も選択できますが、Mesh をオプトインしなくてもすべてが 8.0 以前のように機能するはずです。内部では、これらのリポジトリへのアクセス方法にいくつか変更を加えました。Bitbucket が起動するとサイドカーと呼ばれるものも起動します。これは 2 番目の Java プロセスで、ディスク上のリポジトリとのすべてのやりとりを担当します。

Bitbucket Data Center は現在も NFS (ネットワーク ファイル システム) を使用していますか?

はい、レイテンシ耐性のあるデータ (Git LFS、プラグイン、添付ファイル、アバターなど) の格納は NFS に依存しています。サポート対象プラットフォームをご参照ください。

Mesh は LFS オブジェクトをサポートしますか?

A shared file system is still required to store non-repository data. LFS objects in your Git repositories are also still stored on the shared file system, and we’re tracking the ability to migrate that data in BSERV-13269 - Getting issue details... STATUS

Mesh ノードを別の場所や可用性ゾーンにデプロイできますか?

Currently, we will not be supporting deploying Mesh nodes into multiple availability zones. Just like the shared file system based deployments, the Mesh nodes (that is, the repository storage) and the application nodes must be co-located. We are exploring the ability to support the deployment of Mesh nodes to multiple Availability Zones in BSERV-13269 - Getting issue details... STATUS

Mesh ノードはどのようにアップグレードすべきですか?

Bitbucket Data Center と Bitbucket Mesh の各ノードは別々のアプリであり、バージョン間の互換性があります。これらは個別にアップグレードできます。

サードパーティ アプリは Mesh ノードに直接アクセスできますか?

いいえ。今後も Java API と REST API が、Bitbucket Mesh ノードとやり取りするための唯一の公開メカニズムとなります。

Bitbucket Mesh を AWS にデプロイできますか?

はい、Bitbucket Mesh は AWS をサポートしています。 

Bitbucket Mesh を Azure にデプロイできますか?

はい、Bitbucket Mesh は Azure をサポートしています。

Bitbucket Mesh は Windows をサポートしていますか?

いいえ、Windows はサポートされません。サポート対象プラットフォームを参照してください。

スマート ミラーリング

スマート ミラーリングの利点は何ですか？

"スマート ミラーリング" の用語は、スタンドアロンのミラーとミラー ファームの両方を指すように使用されます。大規模なリポジトリを使用する分散チームで、Git クローンの速度を大幅に改善することができます。世界の反対側からインターネットを通じて Bitbucket インスタンスからクローンするのに数時間かかるような大規模なリポジトリを高速なネットワーク上のローカル ミラーからクローンする場合、数分で完了できます。ミラー ファームを使用することで CI/CD のキャパシティが増加し、ミラーをクラスタ化することで可用性が高まります。

詳細については、「ミラー」を参照してください。 

ミラーはプライマリ Bitbucket インスタンスと同じバージョンである必要がありますか？

いいえ、その必要はありません。プライマリ Bitbucket インスタンスとすべての既存ミラーは、4.2.0 以降であれば任意のバージョンの Bitbucket を実行できます。6.7 よりも新しいミラーの場合、Bitbucket バージョン 6.7 以前のプライマリをポイントできません。さらに、8.13 よりも新しいミラーの場合、Bitbucket バージョン 8.13 以前のプライマリをポイントできません。

ミラーはファイル システムまたはデータベースをプライマリ Bitbucket インスタンスと共有する必要がありますか?

いいえ。ミラーおよびミラー ファームはファイル システムまたはデータベースをプライマリ Bitbucket インスタンスと共有しません。

データが一時ストレージに保存されている場合はどうなりますか?

ローカルに保存されているすべてのデータが失われた場合、ミラーまたはミラー ファームはプライマリ Bitbucket インスタンスとの認証を失い、再インストールする必要があるため、データを一時ストレージに保存する場合は、この点に留意する必要があります。 

プライマリ Bitbucket インスタンスはスマート ミラーリングを使用するクラスタである必要がありますか？

いいえ。スマート ミラーリングを使用するには Data Center ライセンスを持っている必要がありますが、実際にプライマリ Bitbucket インスタンスに複数のクラスタ ノードを持つ必要はありません。

スマート ミラーリングを使用して非 Bitbucket サーバーからリポジトリをミラーリングすることはできますか？

いいえ。Atlassian Marketplace にある Bitbucket 用のミラーリング アプリのいずれかをお試しください。

スタンドアロンのミラーからクローンした場合、プッシュもミラーに行うべきですか?

はい、同じ URL を使用してリポジトリにプッシュできます。Bitbucket はプライマリ リポジトリにプッシュをリレーします。

プライマリ Bitbucket インスタンスがダウンまたは到達不能になった場合、スマート ミラーリングは可用性を高めることができますか？

はい。認証キャッシングは 5.1 で追加されました。プライマリ インスタンスがダウンした場合でも、構成でキャッシュが保持されるかぎり、引き続き認証可能です。

資格情報がキャッシュされていない場合、プライマリ インスタンスが再び利用可能になるまで、ミラーはリクエストを提供できません。

継続的インテグレーション (CI) のビルドをミラー ファームにポイントできますか?

はい、できます。これにより、ノードをミラーに追加して、チームの CI/CD キャパシティを拡張できます。プライマリおよびミラー ファームの負荷を解放して、CI システムのニーズを拡張できます。さらに、ミラー ファームの使用は、CI システムの不具合からのアップストリームの保護にも役立ちます。

Bamboo でのスマート ミラー ファームの使用の詳細については、「スマート ミラーリング」を参照してください。

ミラーでアプリをインストールすることはできますか?

いいえ。

Git Large File Support（LFS）はスマート ミラーリングと連動しますか？

はい。LFS で管理されているファイルが初めてミラーからリクエストされると、それはユーザーにストリーミングされ、今後のリクエストのためにローカルにキャッシュされます。これにより、頻繁にリクエストされるファイルが高速アクセスのためにキャッシュされるパフォーマンスの要件と、ミラー ユーザーに関係しない、LFS で管理される履歴ファイルがアクティブに同期されないストレージ効率の要件とのバランスを実現します。

スマート ミラーリングはどのように守られていますか？

これに対する短い回答は、プライマリ Bitbucket インスタンスに劣らず安全ということです。 

詳細な説明として、Smart Mirroring は一貫したセキュアな通信を必要とし、すべての機能を適切な権限レベル (例: システム管理者) に制限することですべての機密情報のセキュリティを確保するように設計されています。ただし、ミラーはリポジトリ データのコピーを保存しなければならないわけではありません。したがって、他のルート経由での不正アクセスを防ぐために、プライマリの Bitbucket インスタンスだけでなくすべてのミラーで最高のセキュリティ プラクティスをセットアップしておく必要があります。Bitbucket は安全性が低いとみなされる一部の一般的な構成ミスを拒否するか、警告します。たとえば、Bitbucket で SSL を使用せずに新しいミラーをセットアップしようとすると、続行できなくなります。また、${BITBUCKET_HOME} ディレクトリ内のリポジトリ データの読み取り権限をすべてのユーザーに許可するように Bitbucket のユーザー アカウントを構成すると、警告が表示されます。発生しうるすべての設定ミスをとらえることはできません。プライマリ Bitbucket インスタンスと同じ厳重なセキュリティ プラクティスのミラーのセットアップについては、お客様ご自身での責任をお願いしています。

ミラーと標準 Bitbucket インストールの両方に推奨されるベスト プラクティスは以下のとおりです。

• プライマリ インスタンスとすべてのミラーが有効な SSL 証明書を持つことを確認し、プレーンな HTTP でのリクエストを許可しないようにします。
• 不正ログインやシステム管理者以外のアクセスからミラー環境を保護します。
• 標準インスタンスまたはミラーで Bitbucket アプリケーションを root として実行しないでください。
• たとえば、パスワードではなく SSH キーでのみログインを許可したり、既定で他のユーザーにファイルの読み取りおよび書き込みを許可しない umask を構成たりして、Bitbucket ユーザー アカウント（通常は atlbitbucket）の安全性を確保します。
• オペレーティング システムとすべてのパッケージ/コンポーネント（Java、Git、プロキシなど）に完全に最新の更新が適用されていることを確認します。
• Bitbucket のプライマリ インスタンスやミラーと同じ環境で、脆弱性がある他のサービスを実行しないでください。

サード パーティ製ソフトウェア コンポーネントの最小バージョンや、回避すべき既知のバージョンについては、「サポートされているプラットフォーム」を参照してください。その環境でのサービスのセキュリティの詳細については、ベンダーのオペレーティング システムのドキュメントを参照してください。 

スマート ミラーリングのパフォーマンス

ミラーはプライマリ Bitbucket インスタンスよりどれくらい高速ですか？

場合によって異なります。速度の向上は、リポジトリのサイズ、ネットワークの帯域幅とレイテンシ、ミラーがどの程度プロビジョニングされどの程度重い負荷がかかるか、git を実行するユーザーのマシンの CPU がどれくらい高速かに応じて変わります。小規模なリポジトリおよびフェッチの場合、大きな差はないことがあります。良好なネットワーク接続を持つ適度に大きなリポジトリでは、速度の向上は数倍となるでしょう（または絶対値でいうと数分）。あまり良好ではないネットワーク接続を持つ巨大な（数 GB）のリポジトリの場合、速度の向上はかなり大きくなります（絶対値でいうと数時間）。

簡単に言うとミラーはどれくらい速いですか？

アトラシアンでは常にローカル ミラーを使用しています。世界の反対側からクローンするのに通常は 2 分かかる小規模なリポジトリ (100 MB程度) について、ローカル ミラーからのクローンは約 40 秒で完了します (3 倍の速度)。世界の反対側からクローンすると 1 時間以上かかるような大規模なリポジトリ (4 GB 超) の場合、ローカル ミラーからのクローンには 2 ～ 3 分かかります (25 倍から 50 倍の速度向上)。

ミラー ファームについてはどうですか?

アトラシアンのパフォーマンス テストでは、大規模なエンタープライズを模した環境を使用しました。サンプル リポジトリの結果では、同時クローン操作での線形増加を確認しています。これは、各ノードがミラー ファームの 1 つの共有 NFS ストレージを使用するのではなくローカル ストレージからデータを提供する、アーキテクチャ設計によるものです。

ミラーに必要な CPU、メモリ、I/O などはどれくらいですか？

プライマリ Bitbucket Data Center インスタンスと同様に、ミラーリングにはピーク負荷を処理するのに十分な CPU、メモリ、I/O リソースが必要です。詳細は「Bitbucket Data Center を拡張する」をご参照ください。

もちろん、ミラーには、プライマリ Bitbucket インスタンスが専有するリポジトリのスペースと同じだけのリポジトリ データのディスク領域が必要です。（最初は、Git のガベージ コレクションと再パッキングのために、ミラーが使用するリポジトリ データの領域はプライマリ インスタンスの同じリポジトリよりもわずかに小さくなるかもしれませんが、この差異は時間経過とともに安定する傾向があります。標準の Bitbucket インスタンスと同様に、Bitbucket はディスクの空き領域を SCM キャッシュに使用するため、より多くのディスク領域をプロビジョニングするとパフォーマンスが向上します。 

ミラーによってプライマリ Bitbucket インスタンスの負荷は増加または減少しますか？

場合によって異なります。ミラーからのすべてのクローンまたはフェッチは、プライマリ インスタンスによる処理が不要な操作であるため、ミラーにより、プライマリ インスタンスから多少 (おそらく多く) の負荷を取り除くことができます。一方で、ミラーはミラーリングされているすべてのリポジトリのプッシュおよびその他のイベントの webhook 通知を受信し、定期的にプライマリからフェッチを実施してリポジトリの同期を維持するため、プライマリ インスタンスにわずかに負荷を追加します。この追加負荷は通常小さいですが、多くのプッシュを受け取るリポジトリや、あまりクローンされないリポジトリをミラーリングしているミラーを多数持つ場合、考慮に含めることをおすすめします。 

通常、ミラーがプライマリ インスタンスにもっとも多くの負荷を追加するのは、最初にミラーリングの開始をセットアップしたときです。これは、この処理はデータなしで開始され、プライマリ インスタンスのすべてをゼロから取得する必要があるためです。Bitbucket ミラーはプライマリ インスタンスに一度に多くの負荷をかけないよう、リポジトリの内容の初回同期では処理を段階的に行うように設計されていますが、特定の状況 (特にプライマリ インスタンスがすでにキャパシティの限界または限界近くにある) の場合、追加負荷が大きな影響を与える可能性があります。プライマリ インスタンスでのミラーの負荷と影響を最小化するための一般的なガイドラインをいくつか紹介します。

• プライマリ Bitbucket インスタンスの負荷とキャパシティを把握して、そのインスタンスの SCM キャッシュと scm-hosting チケットの制限を適宜調整します。詳細は、「継続的インテグレーション パフォーマンスのために Bitbucket Data Center を拡張する」と「Bitbucket Server がリソース制限に達しつつある場合」をご参照ください。
• プライマリ Bitbucket インスタンスのスペア キャパシティをわずかにプロビジョニングします。インスタンスが維持できる同時 Git ホスティング操作数は、利用可能な CPU、メモリ、IOPS リソースの量に直接関係します。空きディスク領域は SCM キャッシュに使用され、他のリソースへの負荷を減らすため、空きディスク領域を増やすのも有効です。
• 可能であれば、ピーク期間の負荷ではなく、通常の負荷よりも軽くなる期間（週末や、ほとんどのユーザーおよびビルド エージェントがアクティブでないときなど）に新しいミラーをスピン アップします。 
• 新しいミラーを複数スピン アップさせて同時にすべてをミラーリングしないようにします。一定時間空けて一度に1つづつスピン アップさせます。 
• リモート地点で一部のプロジェクトについてのみ定期的に作業が必要な場合、すべてのプロジェクトではなく、そこで必要なプロジェクトのみのミラーを作成することを検討してください。
• ミラーが利用可能になったら、プライマリ インスタンスからできるだけ多くの負荷を取り除けるよう、可能な限りミラーを使用するようにユーザーに推奨します。 

ミラーはすべてを同期しますか?

いいえ。ミラーは指定したプロジェクト内のリポジトリのみを同期します。すべてのプロジェクトを同期するオプションも利用可能です。すべての参照情報がリアルタイムでスマート ミラーに同期されるわけではありません。refs/pull-requests/ にあるものなどの特定の参照情報は、新たな変更がリポジトリにプッシュされるときのみ同期されます。refs/heads/ にあるブランチや refs/tags/ にあるタグなどのパブリックな参照情報はすべてリアルタイムで同期されます。  

スマート ミラーリング技術要件

プレーン（暗号化されない） HTTP をミラーに使用することができますか？

いいえ。プライマリ Bitbucket インスタンスおよびすべてのミラーは、セキュア HTTP （HTTPS）を使用し、認証局（CA）が発行する有効な SSL 証明書を持つ必要があります。これは、プライマリ インスタンスおよびすべてのミラーでのスマート ミラーリングの厳密な要件であり、避けることはできません。ミラー セットアップ ウィザードは、ミラーまたはプライマリ インスタンスが有効な SSL 証明書を持たない場合、処理を続行できません。  

スマート ミラーリングを使用する際に SSH を無効化することができますか？

いいえ、できません。ミラーリングは SSH でプライマリ インスタンスとのリポジトリの同期を維持します。HTTP または HTTPS は使用できません。さらに、ユーザーによるミラーリングへの SSH アクセスの無効化も行えません。プライマリ インスタンスで SSH アクセスを有効にする手順は、「Git リポジトリへの SSH アクセスを有効にする」をご参照ください。

自分の SSH キーまたは HTTPS 認証情報を使用してミラーからクローンまたはフェッチすることはできますか？

片方または両方が可能です。ミラーによって、SSH および HTTPS でクローンおよびフェッチが可能であり、プライマリ インスタンスと同じ認証方式（SSH キー、プロジェクト/リポジトリ アクセス キー、HTTP 認証情報）および認可ポリシー（グローバル権限、プロジェクト権限、リポジトリ権限、および/またはその他のカスタマイズ）を提供しています。

ミラーは CAPTCHA をサポートしていますか？

はい。実際にはミラーは CAPTCHA そのものをサポートしませんが、これをすべてプライマリ Bitbucket インスタンスに委任します。そのため、プライマリ インスタンスまたはミラーのどちらで認証が失敗したかにかからわず、多数の認証が実施されると、プライマリ インスタンスでアカウントの CAPTCHA がトリガされ、これを解除するには CAPTCHA を通過する必要があります。 

スマート ミラーリングではどの外部データベースがサポートされていますか。

ミラーで外部データベースをセットアップする必要はありません。内部の H2 データベースで十分です。

もちろん、プライマリ Bitbucket インスタンスは、サポートされているプラットフォームに示されているサポートされている外部データベースのいずれかを使用する必要があります。 

スマート ミラーリングは Amazon Web Services (AWS) をサポートしていますか？

はい。

ミラーに必要なライセンスはどれですか？

ミラー自体にはライセンスは必要ありません。ですが、プライマリ Bitbucket インスタンスには、ミラーを実行するために有効な Data Center ライセンスが必要です。

ミラーのバックアップはどのように行いますか？

ミラーは、同じプライマリ Bitbucket Data Center インスタンスを再び最初からセットアップするだけでは再構築できない永続的ステータスは、実際には保持しません。ミラーにはバックアップ戦略は不要です。もちろん、SSL 証明書、server.xml、config/ssh-server-keys.pem、bitbucket.properties ファイルなどの重要な構成ファイルを安全な場所にバックアップする必要はあります。しかし、これらの構成ファイルは通常はミラーの実行中に変更されないため、実行中のバックアップは不要です。

ミラー ノードのアップグレードはどのように行いますか？

標準の Bitbucket Server インスタンスと同様に行います。「Bitbucket Server アップグレード ガイド」を参照してください。

Bitbucket Data Center サブスクリプション サービスへの支払いを停止した場合どうなりますか？

Bitbucket の情報にアクセスすることはできます。ですが、インスタンスにプッシュしたりその他の変更を加えることはできません。 

Bitbucket Data Center のクラスタリングのトラブルシューティング

「ホーム ディレクトリでロック ファイル .../shared/.lock が取得できません」というメッセージが表示されます。これは何ですか？

このエラーの一般的な理由は、NFS ロック サービスが無効、または誤って構成されていることです。lockd、portmap、および dbus サービスがすべて NFS サーバーで実行されていることを確認し、Bitbucket を再起動します。詳細については、「Bitbucket Data Center のインストール」を参照してください。

Bitbucket のすべてのインスタンスをシャット ダウンしたあとも .lock ファイルが残っている場合、それらを削除してやり直すことができます。

Bitbucket は本当に共有ホーム ディレクトリをロックしますか？

はい。Bitbucket は .lock ファイルを ${BITBUCKET_HOME} および ${BITBUCKET_HOME}/shared の両方に作成します。

Bitbucket Server は両方のディレクトリで排他ロックを取得し、他の Bitbucket （Server または Data Center）インスタンスが使用できないようにします。

Bitbucket Data Center は ${BITBUCKET_HOME} で排他ロックを (他の Bitbucket インスタンスが使用できないようにします)、 ${BITBUCKET_HOME}/shared で共有ロックを取得します (他の Bitbucket Data Center クラスタ ノードとは共有されますが Bitbucket Server インスタンスとは共有されません)。

これらのチェックは厳密に見えますが、同じホーム ディレクトリを使用するように誤って設定された Bitbucket インスタンスによるデータ損失が起こらないようにしています。 

高負荷時に Bitbucket Data Center インスタンスが遅くなるまたは応答しなくなり、ログ ファイルに「org.hibernate.exception.JDBCConnectionException: Could not open connection」や「java.sql.SQLException: Timed out waiting for a free available connection」というメッセージが大量に出力されます。これは何ですか？

これらのエラーは以下の原因により、Bitbucket が使用するデータベースへのコネクションが不足していることを意味しています。

1. データベースが十分な同時コネクションを許可しないように誤って構成されている可能性があります。既定では、Bitbucket はクラスタ ノードあたり 最大で 80 接続を同時に使用しますが、これは一部のデータベースの既定のコネクション制限を超える可能性があります。たとえば、PostgreSQL の既定のコネクション制限は通常 100 です。PostgreSQL を使用する場合、postgresql.conf ファイルを編集し、max_connections の値を増やして Postgres を再起動する必要がある場合があります。詳細は、「Bitbucket Data Center のインストール」を参照してください。
2. クラスタ ノードのシステム クロックが同期されていないか、改ざんされている可能性があります。これは、仮想化環境でホスト OS とゲスト OS 間の時間同期が誤って設定されている場合に発生することがある問題です。すべてのクラスタ ノードが同じタイムゾーンで設定され、同じ設定で NTP サービスを実行していることを確認します。詳細については、「Bitbucket Data Center のインストール」を参照してください。  

この問題が解決されない場合、アトラシアン サポートにお問い合わせください。

Bitbucket Data Center インスタンスが不明確な理由で遅くなるまたは応答しなくなり、ログファイルに「com.hazelcast.core.OperationTimeoutException: No response for 60000 ms. Aborting invocation!」または「c.a.s.i.s.s.DefaultPublicKeyAuthenticator Timed out while authenticating SSH user at ...」というメッセージが大量に出力されます。これは何ですか？

これらのエラーは以下の原因により、1つ以上の Bitbucket クラスタ ノードがネットワーク上で互いに通信できないことを意味しています。

1. ネットワーク障害。すべてのクラスタ ノードが大幅な遅延やパケット損失なく互いに ping を送信でき、ポート5701のトラフィックがルータやファイアウォール設定で許可されていることを確認します。 
2. Bitbucket を実行している Java 仮想マシンがメモリ不足である可能性があります。「Bitbucket Data Center のスケーリング」および「ヒープ領域のメモリ不足のデバッグ方法」のガイドラインに従います。
3. クラスタ ノードのシステム クロックが同期されていないか、改ざんされている可能性があります。これは、仮想化環境でホスト OS とゲスト OS 間の時間同期が誤って設定されている場合に発生することがある問題です。 すべてのクラスタ ノードが同じタイムゾーンで設定され、同じ設定で NTP サービスを実行していることを確認します。 詳細については、「Bitbucket Data Center のインストール」を参照してください。 

この問題が解決されない場合、アトラシアン サポートにお問い合わせください。