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 をデプロイすることはできますか?

Yes, Bitbucket Data Center supports Microsoft Azure. For more information, see Getting started with Bitbucket Data Center in 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 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 クローンおよびフェッチを高速化する異なる地域にインスタンスを提供することができます。

Which apps or plugins are compliant with Bitbucket Data Center?

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

I've developed a Bitbucket app, how do I make it compatible with Bitbucket Data Center?

Some apps may not need any development work at all, and will largely "just work" in Bitbucket Data Center without modification. But any app that assumes (implicitly or explicitly) that it is running in a single JVM may need some development work to be made compatible. The Bitbucket API for plugin developers includes a number of new services that make it easy to write cluster-safe apps. These services generally provide similar API's to standard Java API's such as ConcurrentMapCache, and  Lock, so in many cases an app can be made cluster safe by just changing a few classes.  See Making cluster-safe plugins for more information.

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

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

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

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

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

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

ファイル サーバーがリソース不足または設定ミスの場合は特に、そうなる可能性があります。ですが、Atlassian 独自の Bitbucket Data Center パフォーマンス テストでは、適切にリソース配分および設定された NFS サーバーは、非常に高い負荷をかけても上手く動作できることを確認しています。以下は、Bitbucket Data Center のファイル サーバーをセットアップする場合のガイドラインと推奨事項です。

  • SAN、NAS、または RAID サーバーなどの高性能のファイル サーバーへの投資を検討することを強くお勧めします。

  • クラスタ内で 10 GB イーサネットまたはファイバー チャネルなどの高速 LAN を使用します。 

  • ファイル サーバーは専用マシンで実行する必要があります。Bitbucket Data Center ファイル サーバーと他のサービスを同じ物理マシンでマルチ テナント化することは避けてください。 

  • 可能であれば、クラスタ ノード上にできるだけ多くのディスクまたは SSD 領域を持つ SCM Cache プラグイン(Bitbucket Data Center に同梱済み)を有効にしてください。有効な SCM Cache は共有ファイル サーバーの負荷を大幅に削減することができます。SCM Cache が使用するドライブまたはパーティションは、NFS マウントではなく各クラスタ ノードに対してローカルであることに注意してください。詳細については、「Bitbucket Server を拡張して連続結合性能を実現する」を参照してください。 

  • Linux ベースのファイル サーバーの場合、NFS が十分なサーバー プロセスで構成されていることを確認します。たとえば、RedHat Enterprise Linux および CentOS の一部のバージョンには、既定で 8 つのサーバー プロセスがあります。これらのシステムのいずれかを使用する場合、/etc/sysconfig/nfs ファイルを編集し、RPCNFSDCOUNT の値を増やし、nfs サービスを再起動する必要がある場合があります。

  • Linux ベースのファイル サーバおよびクラスタ ノードについて、不安定または NFS 関連の既知のバグがある、カーネルと NFS のバージョンの組み合わせは避けてください。以下を推奨します。

    • バージョン 3.2 から 3.8 までの Linux カーネルを避けてください。

    • NFS マウント オプション lookupcache=pos,noatime,intr,rsize=32768,wsize=32768 を使用する。

詳細については、「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 に接続する」を参照してください。 
    • 独自のカスタム (社内またはサードパーティ) 認証プラグインを使用している場合、プラグインがクラスタ対応となるよう作成されていれば、追加でのログインを回避することができます。 
  • Any other data stored in the session (such as fields entered in one page of a multi-page form) on the failing node may be lost and have to be re-entered. Bitbucket and most Atlassian-supplied apps do not store any such state in the session, but third party apps that were not designed for Bitbucket Data Center may. 

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

詳細については、「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 データをバックアップ戦略の一部としてバックアップする必要がありますか?

No. If you have a remote Elasticsearch instance then search indexes are maintained in Elasticsearch's data directory, but you don't have to include this in your backup as it can be completely rebuilt if necessary from the data in your home directory and database. Note that for large instances, rebuilding the Elasticsearch index can potentially take several hours. Search functionality could be degraded while an Elasticsearch index is rebuilt. 

スマート ミラーリング

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

スマートミラーリングは、大規模なリポジトリを使用する分散チームで、Git クローンの速度を大幅に改善することができます。世界の反対側からインターネットを通じて Bitbucket インスタンスから大規模なリポジトリをクローンするのに数時間かかるような大規模なリポジトリは、高速なネットワーク上のローカル ミラーからクローンする場合、数分で取得することができます。

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

スマート ミラーリングを使用する必要があるのはどのバージョンの Bitbucket ですか?

4.2.0 以降です。

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

いいえ。プライマリ Bitbucket インスタンスとすべてのミラーは、4.2.0以降であればどのバージョンの Bitbucket でも実行することができます。好きなときにプライマリ Bitbucket インスタンスとミラーをアップグレードすることができ、すべてを同時にアップグレードする必要はありません。

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

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

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

No. Try one of the several mirroring apps for Bitbucket listed on Atlassian Marketplace.

スマート ミラーリングで Bitbucket Cloud の自分のアカウントからリポジトリをミラーリングすることはできますか?

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

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

はい。認証キャッシングは 5.1 で追加されました。プライマリ インスタンスがダウンした場合でも、認証は可能です。

いいえ。ミラーはプライマリ Bitbucket インスタンスに委任することですべてのユーザーの認証情報を認証および認可するため、プライマリ インスタンスがダウンまたは到達不能になった場合、ミラーはユーザーに対するリクエストに答えることができません。 

ミラーをクラスタ化することはできますか?

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

継続的インテグレーション サーバー(Bamboo、Jenkins、…)をミラーに向けることができますか?

はい、できます。ですが、Bitbucket サーバーは現在 Bamboo、Jenkins、またはその他の継続的インテグレーション サーバーとのネイティブな統合をサポートしていないため、(「Bitbucket」や「Stash」ではなく)通常の「Git」タイプでリポジトリを設定し、プッシュ通知の代わりにポーリング モードのトリガを使用する必要があります。この詳細については、お問い合わせください。

Can I install apps on a mirror?

いいえ。

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

はい。Bitbucket Data Center 4.5から、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倍の速度向上)。

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

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

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

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

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

通常、ミラーがプライマリ インスタンスに多くの負荷を追加するのは、最初にミラーリングを開始したときです。これは、データを持たずに開始され、プライマリ インスタンスのすべてを1から引き出す必要があるためです。Bitbucket ミラーは、最初にリポジトリの内容を徐々に同期するように設計されているため、プライマリ インスタンスに一度に多くの負荷を掛けないようにしていますが、特定の状況、特にプライマリ インスタンスが既にキャパシティの限界または限界近くにある場合、追加される負荷が重大になる可能性があります。プライマリ インスタンスへのミラーの負荷と影響を最小化するため、ここでは常識的なガイドラインをいくつか紹介します。

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

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

いいえ。Smart Mirrors は指定したプロジェクト内のリポジトリのみを同期します。すべてのプロジェクトを同期するオプションも利用可能です。すべての ref がリアルタイムで Smart Mirrors に同期されるわけではないことにご注意ください。refs/pull-requests/, にあるものなどの特定の ref は、定期的にのみ同期されます。refs/heads/, にあるブランチや refs/tags/ にあるタグなどのパブリックな ref は、すべてリアルタイムで同期されます。  

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

プレーン(暗号化されない) 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 に戻すことができます。

Do I have to buy licenses for apps on each node? 

No. Apps are sold at the Bitbucket Server rate, but the user tier has to exceed or match the Bitbucket Data Center license tier. For example, if you have 3,000 users in Bitbucket Data Center, then you would buy the app for 2,000-10,000 users.

To use apps with Bitbucket Data Center, simply install the app once as normal. You do not need to install on each cluster node individually.

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

いいえ。 

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

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

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 年 3 月 28 日

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

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