Bitbucket Data Center の FAQ

このページでは、Bitbucket Data Center に関するよくある質問に対する回答の一部を紹介しています。このページで回答されていない質問があれば、Atlassian Enterprise Advocate、Atlassian のエンタープライズ チーム、または、Atlassian Expert に連絡してください。

Bitbucket Data Center とは何ですか?

Bitbucket Data Center は Bitbucket Server とどう違うのですか?

Bitbucket Data Center は Bitbucket Server の全機能に加えて、以下の機能を提供しています。

  1. クラスタリング: (高帯域幅、低ネットワーク遅延で接続された)複数ノードのクラスタ上で Bitbucket を実行し、拡張可能な容量、パフォーマンス、高可用性を提供することができます。詳細については、「Bitbucket Data Center によるクラスタリング」を参照してください。
  2. スマート ミラーリング: 地理的に分散した場所にローカル ミラー ノードを提供し、リモート チームへの Git クローンおよびフェッチを高速化することができます。詳細については、「スマート ミラーリング」を参照してください。
  3. ディザスタ リカバリ: データ バックアップまたはレプリケーション プランおよび復旧プロセスを持つコールドスタンバイ インスタンスを維持することができます。詳細については、「ディザスタ リカバリ」を参照してください。

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

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

Bitbucket Data Center にはどのようなサポートが含まれていますか?

Bitbucket Data Center のサポートは、既存の Bitbucket Server のサポートと同様です。

ただし、エンタープライズのお客様は、プレミア サポートや技術アカウント管理などの、提供されているその他の利点を利用することを選択することもできます。これらのサービスの詳細については、Atlassian Enterprise Advocate、sales@atlassian.com、または Atlassian Expert に連絡してください。

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

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

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

はい、Bitbucket Data Center は Microsoft Azure をサポートしています。詳細については、「Azure で Bitbucket Data Center の使用を開始する」を参照してください。 

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

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

クラスタリング

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

Bitbucket Server は単一マシンで実行されている Bitbucket の単一インスタンスです。負荷を処理するキャパシティは、単一マシンのリソースで制限され、何らかの理由マシンがダウンした場合(ハードウェア故障、ネットワーク障害、または計画メンテナンスなど)、ダウンタイム期間中は、ユーザーが Bitbucket を利用できません。

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

  • 大規模なパフォーマンス: それぞれ Bitbucket を実行している多数のマシンのクラスタによって、単一マシンの場合よりも多くの負荷を処理することができます。

  • 高可用性: 1 つのクラスタ ノードがダウンした場合、ユーザーが可用性の低下をほとんど、またはまったく意識することがないように、残りのクラスタ ノードがリクエストへのサービス提供を継続します。 

  • 即時に実現可能な拡張性: ダウンタイムなしで、迅速に追加の容量をプロビジョニングできます。

詳細については、「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 には、クラスタで安全に使用できるアプリを簡単に作成するための多数の新サービスが含まれています。これらのサービスは一般に、ConcurrentMapCacheおよび 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 サーバーは、非常に高い負荷下でも適切に動作することが確認されています。

Bitbucket Data Center の共有ファイル サーバーのセットアップの詳細については、「Bitbucket Data Center のインストール」の「ステップ 2. 共有ファイル システムのプロビジョニング」をご覧ください。このセクションでは、Bitbucket Data Center 用の NFS のセットアップの要件や推奨事項について説明しています。
 

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

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

ホット フェイルオーバーを可能にするには、最低2つのクラスタ ノードを用意することをお勧めします。Atlassian では、12台までのクラスタ ノードを使用するテストをしています。

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

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

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

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

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

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

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

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

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

いいえ、Bitbucket Data Center では、同じクラスタ内に混合したバージョンのクラスタ ノードを許可していません。一度に1つのノードをアップグレードする場合でも、古いバージョンと新しいバージョンの間には常にダウンタイム期間が必要です。ですが、適切に管理すれば、Bitbucket Data Center インスタンスのアップグレードには、同等の Bitbucket Server インスタンス以上のダウンタイムをかける必要はなく、大幅に削減することができます。Bitbucket Data Center では、ノードを1つずつオフラインにして、アップグレードを実行し、古いバージョンの最後のノードのシャットダウン時間と新しいバージョンの最初のノードの起動時間のみをダウンタイム期間内にすることができます。Bitbucket Data Center インスタンスでは、これはその目的のために同じバックアップ サーバーをプロビジョニングした場合のみ可能です。

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

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

単純に「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)をサポートしていますか?

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

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

現時点ではサポートしていません。Amazon EFS パフォーマンス には次のように記載されています。

Amazon EFS […] は分散型のため、ファイル処理あたりのレイテンシ オーバーヘッドが小さくなります。この処理あたりのレイテンシと、オーバーヘッドが大量のデータで分割されることを受けて、平均 I/O サイズの増加に伴って全体のスループットが向上します。

Git は一般的に数千の小さなファイル オペレーションを処理します。各ファイル処理に対して追加レイテンシが発生する git は、EFS などの分散型ファイル システムには適していません。EFS の最大 I/O オプションはさらにレイテンシが大きいため、こちらも Bitbucket Data Center には適していません。

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

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

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

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

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

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

クラスタ化されている場合 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 インデックスが再構築される間は検索機能のパフォーマンスが低下する可能性があります。 

スマート ミラーリング

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

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

詳細については、「スマート ミラーリング」を参照してください。 

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

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

プライマリ 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 Server のスケーリング」を参照してください。

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

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

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

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

  • プライマリ Bitbucket インスタンスの負荷とキャパシティを把握し、そのインスタンスの SCM キャッシュと scm-hosting チケットの制限を適宜調整します。詳細は、「継続的インテグレーション パフォーマンスのための Bitbucket Server のスケーリング」および「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 アクセスを有効にする手順については、「Bitbucket Server の 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.xmlconfig/ssh-server-keys.pembitbucket.properties ファイルなどの重要な構成ファイルを安全な場所にバックアップする必要はあります。しかし、これらの構成ファイルは通常はミラーの実行中に変更されないため、実行中のバックアップは不要です。

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

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

Bitbucket Data Center のライセンス

Bitbucket Data Center のライセンスはどのように購入しますか?

https://www.atlassian.com/software/bitbucket/enterprise/data-center に移動し、「今すぐ購入」をクリックします。 

永久ライセンスから Bitbucket Data Center に変更し、あとで Bitbucket Server に戻すことはできますか?戻す場合、費用がかかりますか?

Bitbucket Data Center に対するサブスクリプションは有効ですが、必要であれば簡単にノードを1つだけ実行することができます。サブスクリプションの有効期限が切れた場合、単一サーバー ライセンスを購入し、Bitbucket Server に戻すことができます。

各ノードに対してアプリのライセンスを購入する必要がありますか? 

いいえ。アプリは Bitbucket Server 用の価格で販売されていますが、ユーザー層は Bitbucket Data Center のライセンス層以上である必要があります。たとえば、Bitbucket Data Center に 3,000 ユーザーがいる場合、2,000 - 10,000 ユーザー用のアプリを購入します。

Bitbucket Data Center でアプリを使用するには、通常どおりにアプリをインストールします。各クラスタ ノードに個別にインストールする必要はありません。

無制限ユーザー ライセンスはありますか?

いいえ。 

引き続きテスト環境で開発者ライセンスを使用できますか?

はい。ステージング環境で開発者ライセンスを使用できます。

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

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

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

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

このエラーの一般的な理由は、NFS ロック サービスが無効、または誤って構成されていることです。lockdportmap、および 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 のインストール」を参照してください。  

この問題が解決されない場合、Atlassian Support にお問い合わせください。

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 Server のスケーリング」および「ヒープ領域のメモリ不足のデバッグ方法」のガイドラインに従います。
  3. クラスタ ノードのシステム クロックが同期されていないか、改ざんされている可能性があります。これは、仮想化環境でホスト OS とゲスト OS 間の時間同期が誤って設定されている場合に発生することがある問題です。 すべてのクラスタ ノードが同じタイムゾーンで設定され、同じ設定で NTP サービスを実行していることを確認します。 詳細については、「Bitbucket Data Center のインストール」を参照してください。 

この問題が解決されない場合、Atlassian Support にお問い合わせください。

最終更新日 2019 年 11 月 7 日

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

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