Helix Coreサーバ管理者ガイド (2020.1)

展開アーキテクチャ

小規模な組織ではユーザのニーズを満たすために単一サーバがあれば十分と判断されることが少なくありません。 ただし、ビジネスの規模が拡大し、地域を含め使用範囲が広がると、多くの組織はより強力なインフラストラクチャをサーバ側に実装します。

分散アーキテクチャ

アーキテクチャ メリット デメリット

コミットエッジ

  • ほとんどのコマンドがローカルで実行されるため全体的なパフォーマンスが最良になる
  • エッジサーバのローカルデータはビルド時にのみ必要になるため、自動化プロセス(ビルド処理など)専用のエッジサーバは、バックアップやリカバリの手段を講じることなく導入することができる
  • スタンバイサーバとして使用できない
  • 各エッジサーバのバックアップなど(ビルドエッジサーバの場合を除く)、マシンのプロビジョニングと管理に関する作業が必要になる
    including backups of each edge (except in the case of a build edge server)

転送レプリカ

注意

マスターサーバは、エッジサーバをサポートしない標準タイプのサーバです。
  • フィルタリングをカスタマイズできる
  • 追加サイトへの「デイジーチェーン」がサポートされる。 例えば、フィリピンのサイトが台湾のサイトに転送を行い、台湾のサイトが日本のサイトに転送を行い、日本のサイトがフランスのマスターサーバに転送を行うとします。 アジアの各サイトをヨーロッパと直接接続する代わりにこのようにすると、次のメリットがあります。
    • マスターサーバでのメタデータ複製の負荷を低減できる
    • ヨーロッパからアジアにWAN経由で転送されるデータ量を低減できる

    詳細については、サーバ間の配置に関するナレッジベースの記事「Helix複製ルール」を参照してください。
  • ローカルメタデータをマスターサーバからプルする必要があるため「書き込み」コマンドが低速になる
  • マシンのプロビジョニングと管理が必要になる 詳細については、「転送レプリカ」を参照してください。
ヒント

2018.2以降では、高可用性と障害復旧のため、スタンバイサーバでrpl.journalcopy.location=1と設定することをお勧めします。

エッジサーバ同士の連結

  • 任意の数のエッジサーバを連結できる
  • 各部門が地理的に分散している場合、すべてのユーザが近くのエッジサーバを使用するように設定することができる
  • フィルタリング
  • 連結するエッジサーバの数が多くなると、複製にかかる時間が長くなる
  • 地理的に最も離れたエッジサーバで、最も長い遅延が発生する
 

Helixブローカ

  • 次の処理を実行できる: コマンドを許可する、オプションが正しくない場合などにコマンドを拒否する、別のサーバにコマンドをリダイレクトする、コマンドをフィルタリングする、コマンドに応答する (「コマンドハンドラの仕様」を参照してください)
  • 保守作業のためにp4dプロセスがオフラインになっている場合、「このサーバは現在保守作業中です」などのメッセージをブローカで表示することができる(ユーザにとっては、TCP接続エラーの場合よりもわかりやすい)
ヒント

フェイルオーバープロセスの実行中は、ブローカを使用しなくても、上記のようなメッセージをエンドユーザに対して表示することができます。

Helixプロキシ

  • インストール、構成、保守が簡単である

  • 頻繁に転送されるファイルリビジョンをキャッシュすることによりパフォーマンスが向上する

  • Perforceサービスおよびそれが動作するネットワークへの要求が低減する

  • プロキシのキャッシュをバックアップする必要がない
  • 大規模ファイルでは特にメリットが大きい

  • 小規模ファイルを大量に同期するのに向いていない

ヒント

 

  • 転送レプリカの前にプロキシを配置できない
  • プロキシのパフォーマンスに関するサポートナレッジベースの記事を参照してください。

サービスの割り当て

サービスをサーバに割り当てる場合、管理者は、p4 serverコマンドで表示されるServices:フィールドを使用する必要があります。

ヒント

さらに詳しくは、以下のリンクを参照してください。

追加の製品ドキュメント
Perforceトレーニングポータル
Perforceビデオライブラリ
Perforceナレッジベース
Perforceカスタマーサポート
電子メール: manual@perforce.com