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 インスタンスのボトルネックとなることはありませんか?

It can be, especially if your file server is under-resourced or misconfigured. But in Atlassian's own Bitbucket Data Center Performance  testing, we have found that a properly resourced and configured NFS server can perform well even under very heavy load. 

For more information on setting up Bitbucket Data Center's shared file server, see  Step 2. Provision your shared file system (in  Install Bitbucket Data Center). This section contains the requirements and recommendations for setting up NFS for Bitbucket Data Center.
 

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

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

ホット フェイルオーバーを可能にするには、最低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 インデックスが再構築される間は検索機能のパフォーマンスが低下する可能性があります。 

スマート ミラーリング

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

Smart Mirroring is a term we use to cover standalone mirrors as well as mirror farms. It can greatly improve Git clone speeds for distributed teams working with large repositories. Large repositories that take hours to clone from a Bitbucket instance over the Internet from the other side of the world, can take minutes when cloned from a local mirror on a fast network. Mirror farms increase your CI/CD capacity and the clustering of mirrors provides higher availability.

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

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

No. Your primary Bitbucket instance and all existing mirrors can run any version of Bitbucket, provided it is 4.2.0 or higher. For mirrors that are newer than 6.7, they cannot point to a primary older than Bitbucket version 6.7.

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

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

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

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

Once I've cloned from a standalone mirror, am I supposed to push to the mirror as well?

Yes, you can push to the repository using the same URL and Bitbucket relays the push to the primary repository.

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

Yes. Auth caching was added in 5.1, so if the primary instance is down, authentication can still be done for as long as the cache lives through its configuration.

In the case where credentials are no longer cached, the mirror won’t be able to serve requests until the primary instance is available again.

Can I point my continuous integration (CI) builds to mirror farms?

Yes you can. This will allow you to scale your teams' CI/CD capacity simply by adding additional nodes to your mirror. This frees up the load on the primary and mirror farms can scale the needs of your CI system. In addition using mirror farms can help protect your upstream against miss behaving CI systems.

For information on using Smart mirror farms with bamboo see Smart Mirroring for more information.

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

いいえ。

Git Large File Support(LFS)はスマート ミラーリングと連動しますか?

Yes. When a file managed by LFS is first requested from a mirror, it will be streamed to the user and cached locally for future requests. This strikes a balance of performance, where commonly requested files are cached for fast access, and storage efficiency, where historical files managed by LFS that are not of interest to mirror users are not actively synced.

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

これに対する短い回答は、プライマリ 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)のリポジトリの場合、速度の向上はかなり大きくなります(絶対値でいうと数時間)。

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

We use local mirrors all the time, and we have some fairly small repositories (100's of MBytes) that normally take 2 minutes to clone from the other side of the world take about 40 seconds from a local mirror (3x speedup). Larger repositories (> 4 GBytes) that take over an hour to clone from the other side of the world take 2 – 3 minutes from a local mirror (anywhere from 25x to 50x speedup).

What about mirror farms?

In our performance testing, we used environments that represent large enterprises. The results for a sample repository were a linear increase in concurrent clone operations. This is due to the architectural design, in which each node serves data from local storage instead of using one shared NFS storage in a mirror farm.

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

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

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

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

It depends. Mirrors take some load (possibly a lot) off their primary instance as every clone or fetch from a mirror represents an operation that the primary instance doesn't have to handle. On the other hand mirrors also add a bit of load to their primary instance as they receive webhook notifications informing them of pushes and other events on all the repositories they are mirroring, and periodically perform fetches from the primary to keep those repositories in sync. This additional load is usually small, but if you have a lot of mirrors mirroring repositories that receive a lot of pushes and/or don't get cloned very much, it can add up. 

The time when mirrors generally add the most load to your primary instance is when they are first set up to start mirroring. This is because they start with no data and have to pull everything down from the primary instance from scratch. Bitbucket mirrors are designed to perform this initial sync of repository contents gradually so as not to place a lot of load on the primary instance all at once, but under some circumstances the added load can be significant – especially if your primary instance is already at or near capacity. To minimize the load and impact of mirrors on your primary instance, here's a few common sense guidelines:

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

Do mirrors sync everything?

No. Mirrors only synchronize the repositories in the Projects you specify. An option to sync all projects is available. Note that not all refs are synced to Smart Mirrors in real time. Certain refs, like those found under refs/pull-requests/, are only synced when a new change is pushed to the repository. All public refs, like branches, found under refs/heads/, and tags, found under refs/tags/, are synced in real time.  

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

プレーン(暗号化されない) 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.