Perforceの複製機能

複製とは

複製とは、特定のPerforceサーバのデータを別のPerforceサーバに(可能な場合はリアルタイムで)複製するということです。複製機能を使用すると、以下のことが可能になります。

  • ウォームスタンバイサーバを設定する

    レプリカサーバは、最新の状態になっているウォームスタンバイサーバとして使用することができます。マスターサーバで障害が発生した場合は、このレプリカサーバが使用されます。こうしたレプリカサーバを使用するには、サーバのメタデータとバージョンファイルの両方を複製する必要があります。

  • プライマリサーバの負荷とダウンタイムを低減する

    長時間実行されるクエリー、レポート、ビルド、チェックポイントは、レプリカサーバに対して実行することができます。これにより、ロックの競合を減らすことができます。チェックポイントと一部のレポートタスクについては、メタデータのみ複製する必要があります。レポートとビルドタスクの場合、レプリカサーバはメタデータとバージョンファイルの両方にアクセスする必要があります。

  • ビルドファームをサポートする

    クライアントワークスペースとそのワークスペースの各haveリスト用の複製されていないローカルのストレージを持つレプリカは、ビルドファームとして実行することができます。

  • 書き込み要求を集中サーバに転送する

    転送レプリカは、バージョンファイルとメタデータ両方の読み取り可能キャッシュを保持し、メタデータまたはファイルのコンテンツを書き込むためのコマンドを集中サーバに転送します。

複製機能を集中認証サーバ(集中認証サーバ(P4AUTH)を参照)と組み合わせることにより、Perforceの管理者は、レプリカサーバにコマンドをリダイレクトするようにPerforceブローカ(“Perforceブローカ”を参照)を構成して、任意の数のレプリカサーバ間で負荷を効率的に分散することができます。

注意

ほとんどのレプリカ構成は、データの読み込みを目的としています。リモートサーバに対する読み取り/書き込みのクアセス権が必要な場合は、転送レプリカ、分散Perforceサービス、Perforceプロキシのいずれかを使用してください。詳細については、転送レプリカを構成する“コミットエッジアーキテクチャ”“Perforceプロキシ”を参照してください。

動作環境

  • 一般的なルールとして、すべてのレプリカサーバのリリースレベルがマスターサーバのリリースレベルと一致している必要があります。マスターサーバで特定の機能をアップグレードした場合は、レプリカサーバでもその機能をアップグレードする必要があります。レプリカサーバでアップグレードした場合も、マスターサーバでのアップグレードが必要になります。

  • すべてのレプリカサーバで、マスターサーバと同じユニコード設定が必要になります。

  • マスターサーバのファイルシステムと同じように大文字と小文字が区別されるファイルシステム上で、すべてのレプリカサーバをホストする必要があります。

  • p4 pullコマンド(メタデータを複製する場合)では、圧縮されたジャーナルは読み込まれません。レプリカサーバが古いジャーナルからすべてのジャーナルレコードをフェッチするまで、マスターサーバでジャーナルを圧縮しないでください。メタデータ更新スレッドのp4 pullは、一度に1つしかアクティブにすることはできません。

  • レプリカサーバでは、複製ライセンスファイルは必要ありません。

  • マスターサーバとレプリカサーバで、同じタイムゾーン設定にする必要があります。

    Windows

    Windowsの場合、タイムゾーン設定はシステム全体に適用されます。

    UNIXの場合、レプリカサーバの起動時に、TZ環境変数によってタイムゾーン設定が制御されます。

コマンドとコンセプト

Perforceサーバの複製では、いくつかのコマンド、構成可能変数、コンセプトが使用されます。以下に例を示します。

コマンドまたは機能

標準的な使用例

p4 pull

メタデータとバージョンファイルの両方を複製できるコマンド。保留中のコンテンツ転送処理に関する診断情報のレポートを作成することもできます。

レプリカサーバは、同じマスターサーバに対して複数のp4 pullコマンドを実行することができます。メタデータとファイルコンテンツの両方を複製するには、2つのp4 pullスレッドを同時に実行する必要があります。p4 pullスレッドを1つだけ実行すると(-uオプションは指定しない)、マスターサーバのメタデータが複製され、1つ以上のp4 pull -uスレッドを実行すると、サーバのバージョンファイルに更新内容が複製されます。

p4 configure

複数のサーバをサポートする構成メカニズム。

p4 configureコマンドを実行するとマスターサーバにデータが保存されるため、ユーザが行った変更がすべてのレプリカサーバによって自動的に取得されます。

p4 server

提供されるサービスの観点からサーバを定義する構成メカニズム。効率的な処理を行うため、p4 server形式のServerID:フィールドは、p4 serveridコマンドで定義されたサーバのserver.idファイルに対応している必要があります。

p4 serverid

Perforceサーバの固有IDの設定または表示を行うコマンド。サーバを起動すると、そのサーバのルートディレクトリのserver.idファイルからサーバIDが取得され、p4 serverコマンドによって定義された対応する仕様が確認されます。

サーバ名 
P4NAME
p4d -In name

Perforceサーバは、名前で識別して構成することができます。

マスターサーバでp4 configureコマンドを使用する場合は、各名前付きサーバに対して、異なる構成可能変数のセットを指定することができます。各名前付きサーバを起動すると、そのサーバ独自の構成可能変数のセットが参照され、他のサーバの構成可能変数のセットは無視されます。

サービスユーザ

p4d -u svcuser

サーバ間通信の認証で使用される新しいタイプのユーザ。サービスユーザは、ディポに対して非常に制限されたアクセス権しか割り当てられておらず、Perforceのライセンスを使用することもありません。

ログを読みやすくするには、Perforceサーバのネットワーク内の各レプリカまたはプロキシについて、マスターサーバ上にサービスユーザを1つだけ作成します。

メタデータへのアクセス


p4d -M readonly
db.replication

メタデータ(db.*ファイル)を変更しようとするユーザコマンドを自動的に拒否するようにレプリカサーバを構成することができます。

-M readonlyモードの場合、Perforceサーバは、サーバのメタデータへの書き込みを行うコマンドをすべて拒否します。このモードでは、サーバのhaveリストを更新するp4 syncなどのコマンドが拒否されますが、サーバのhaveリストを更新することなくクライアントのワークスペースにデータを取り込むp4 sync -pコマンドは許可されます。

メタデータのフィルタリング

クライアントワークスペースとファイルリビジョンのデータをフィルタリングするようにレプリカサーバを構成することができます。

-P serverIdオプションをp4dコマンドで指定すると、フィルタリングされたチェックポイントをserverIdの値に基づいて作成することができます。

-T tableexcludelistオプションをp4 pullコマンドで指定すると、データベーステーブル全体で更新内容を明示的にフィルタリングすることができます。

p4 server形式のClientDataFilter:RevisionDataFilter:ArchiveDataFilter:フィールドを使用すると、複製するデータを詳細に制御することができます。-P serveridオプションをp4 pullコマンドで使用し、必要なフィルタパターンのセットを保持するp4 server仕様を持つサーバのName:を指定してください。

ディポファイルへのアクセス


p4d -D readonly
p4d -D shared
p4d -D ondemand
p4d -D cache
p4d -D none
lbr.replication

アーカイブされているディポファイル(ライブラリ)を変更しようとするユーザコマンドを自動的に拒否するようにレプリカサーバを構成することができます。

  • -D readonlyモードの場合、Perforceサーバはディポファイルを読み込むコマンドを許可しますが、ディポファイルへの書き込みを行うコマンドは拒否します。このモードでp4 describeコマンドを実行すると、チェンジリストに関連する差分を表示できますが、p4 submitコマンドは拒否されます。

  • -D ondemandモードまたは-D sharedモード(どちらも同義)の場合、Perforceサーバはメタデータを読み込むコマンドを許可しますが、新しいファイルを転送したり、消去されたファイルをマスターサーバから削除したりすることはありません(アーカイブファイルを転送するp4 pull -uコマンドとp4 verify -tコマンドが無効になります)。アーカイブ内に存在しないファイルを参照するコマンドは失敗します。

    このモードは、同じマシン上で実行するかネットワーク共有経由で実行するかにかかわらず、同じ物理アーカイブをレプリカで直接共有する場合に使用する必要があります。このモードは、rsyncコマンドなどの外部のアーカイブ同期技術を使用してアーカイブを実行する場合にも使用することができます。

  • -D cacheモードの場合、Perforceサーバはファイルのコンテンツを参照するコマンドを許可しますが、新しいファイルを自動的に転送することはありません。ターゲットから消去されたファイルは、消去操作が複製されたときに、レプリカから削除されます。アーカイブ内に存在しないファイルについては、レプリカによってターゲットサーバから取得されます。

  • -D noneモードの場合、Perforceサーバは、ディポを構成するバージョンファイルにアクセスするすべてのコマンドを拒否します。このモードでは、p4 describe changenumなどのコマンドが拒否されます。これは、チェンジリストで表示される差分がバージョンファイルにアクセスする必要があるためです。ただし、p4 describe -s changenumコマンド(差分のセットを作成するために、ディポファイルを参照することなくチェンジリストを記述するコマンド)は許可されます。

ターゲットサーバ

P4TARGET

Perforceプロキシの場合と同様に、P4TARGETを使用して、レプリカサーバがデータを取得する際の参照先となるマスターサーバ(リリース2013.1の場合は別のレプリカサーバ)を指定することができます。

P4TARGETを明示的に設定するか、p4 configureコマンドを使用して、各名前付きレプリカサーバに対してP4TARGETを設定することができます。

P4TARGETが設定されているレプリカサーバの場合、-Mオプションと-Dオプションの両方を指定する必要があります。または、これらのオプションと同等のdb.replication変数とlbr.replication変数を正しく指定する必要があります。

起動コマンド

startup.1

起動時に複数のp4 pullプロセスを生成するには、構成可能変数のstartup.n (「n」は整数)を使用します。

ステートファイル

statefile

レプリカサーバは、バイトオフセットを持つサイズの小さなテキストファイル内で、最新のジャーナルの位置を追跡します。マスターサーバまたはレプリカサーバを停止すると、最新のジャーナルの位置がステートファイル内のレプリカに記録されます。

サーバを再起動すると、レプリカはステートファイルを読み込み、中止した位置を特定します。このファイルの名前や内容は変更しないでください。(ステートファイルを削除すると、ゼロのオフセット値で複製が開始され、レプリカが最初から作成されることになります。)

デフォルトでは、ステートファイルはstateという名前になり、レプリカサーバのルートディレクトリに格納されます。構成可能変数のstatefileを設定して、別のファイル名を指定することができます。

P4Broker

Perforceブローカを使用して、ロードバランシングやコマンドのリダイレクトなどを行うことができます。詳細については、“Perforceブローカ”を参照してください。

P4 pullコマンド

Perforceのp4 pullコマンドは、複製処理で最も一般的に使用されるコマンドです。p4 pullコマンドを使用して、以下のようなレプリカサーバを構成することができます。

  • マスターサーバからのみ一方向にバージョンファイル(新しいバージョンの送信時に生成された詳細情報が含まれている,vファイル)を複製するレプリカサーバ。

  • マスターサーバからのみ一方向にサーバのメタデータ(db.*ファイルに含まれている情報)を複製するレプリカサーバ。

  • 構成可能変数startup.nを使用して、必要な数のp4 pullプロセスを自動的に生成するレプリカサーバ。

    ウォームスタンバイサーバの一般的な構成では、p4 pullプロセスが1つだけ生成されて、マスターサーバのメタデータが複製されます。さらに、並行して実行される複数のp4 pull -uプロセスが生成され、マスターサーバのバージョンファイルのレプリカのコピーが継続的に更新されます。

  • 構成可能変数startup.nは、順番に処理されます。最初に欠番があった箇所で処理が停止し、欠番以降は、すべてのコマンドが無視されます。

テストやデバッグの目的でコマンドラインからp4 pullコマンドを実行できますが、構成可能変数のstartup.nによって制御されている場合に、名前付きサーバ、サービスユーザ、集中管理構成と組み合わせてこのコマンドを使用すると、特に便利です。

サーバ名とP4NAME

Perforceサーバの名前を設定するには、P4NAME環境変数を設定するか、サーバの起動時にp4dコマンドに対して-Inコマンドラインオプションを指定します。複製を構成する場合は、必ずサーバに名前を割り当てる必要があります。サーバに名前を割り当てると、起動オプションや環境変数の値を使用して構成の詳細を指定する代わりに、ほとんどの構成データをPerforce自体に保存できるようになります。複製環境では、他のPerforceメタデータとともにp4 configure設定がマスターサーバから複製されるため、名前付きサーバが必要になります。

例えば、以下のように指定してマスターサーバを起動したとします。

p4d -r /p4/master -In master -p master:11111

レプリカサーバは以下のようになっています。

p4d -r /p4/replica -In Replica1 -p replica:22222

この場合、構成設定はPerforceサーバのメタデータの一部であり、そのメタデータに従って構成設定が複製されるため、マスターサーバ上でp4 configureコマンドを使用して、マスターサーバとレプリカサーバ両方の設定を制御することができます。

例えば、マスターサーバ上で以下のコマンドを実行するとします。


p4 -p master:11111 configure set master#monitor=2
p4 -p master:11111 configure set Replica1#monitor=1

この場合、構成データが複製されると、2つのサーバの監視レベルがそれぞれ異なるレベルになります。つまり、p4 monitor showコマンドをmaster:11111に対して実行すると、アクティブなプロセスとアイドル状態のプロセスの両方が表示されることになります。これは、masterという名前のサーバに対して、構成可能変数のmonitorが「2」に設定されているためです。p4 monitor showコマンドをreplica:22222に対して実行すると、アクティブなプロセスだけが実行されます。これは、Replica1というサーバに対してmonitorの値が「1」に設定されているためです。

マスターと各レプリカには、独自のジャーナルとチェックポイントが設定されている場合が多いため、各名前付きサーバに対して構成可能変数のjournalPrefixを使用して、これらのジャーナルとチェックポイントのプレフィックスを固有の値にすることをお勧めします。


p4 configure set master#journalPrefix=/master_checkpoints/master
p4 configure set Replica1#journalPrefix=/replica_checkpoints/replica

詳細については、下記のサイトを参照してください。

http://answers.perforce.com/articles/KB_Article/Master-and-Replica-Journal-Setup

サーバID: p4 serverコマンドとp4 serveridコマンド

p4 serverコマンドとp4 serveridコマンドを使用して、Perforceサーバが提供する一連のサービスを詳細に定義することができます。以下のサーバを構成するには、サーバの仕様が必要になります。

  • コミットサーバ: 分散インストール環境内の集中サーバ

  • エッジサーバ: 分散インストール環境内のノード

  • ビルドサーバ: ビルドファームの統合をサポートするレプリカ

  • ディポマスター: 自動フェイルオーバー機能を備えたコミットサーバ

  • ディポスタンバイ: ディポマスターのスタンバイレプリカ

  • ワークスペースサーバ: クラスタ内のノード

  • スタンバイサーバ: p4 journalcopyコマンドを使用する読み取り専用レプリカ

  • 転送スタンバイ: p4 journalcopyコマンドを使用する転送レプリカ

p4 serveridコマンドは、server.idというサイズの小さなテキストファイルを作成(または更新)します。server.idファイルは、常にサーバのルートディレクトリに格納されます。

p4 serverコマンドを使用して、インストール環境内に存在するすべてのサーバのリストを保守することができます。また、このコマンドを使用して、p4 serveridコマンドに渡される固有のサーバIDを作成し、起動時にserver.idファイルからそのサーバIDを読み取るサーバによって提供されるサービスを定義することもできます。さらに、p4 serverコマンドを使用して、サーバ名(P4NAME)を設定することもできます。

サービスユーザ

Perforceユーザには、standardユーザ、operatorユーザ、serviceユーザという3つのタイプがあります。standardユーザは通常のPerforceユーザで、operatorユーザは、人または自動処理によるシステム管理者を対象とします。serviceユーザは、複製プロセスの一部として、サーバ間認証で使用されます。

サービスユーザは、単一サーバ環境のリモートディポの場合に使用すると便利です。ただし、マルチサーバ環境と分散環境では、必ずサービスユーザを使用する必要があります。

制御対象の各マスターサーバ、レプリカサーバ、またはプロキシサーバに対して、serviceユーザを作成してください。これにより、サーバログを簡単に読むことができるようになります。サービスユーザの場合、マスターサーバやコミットサーバとの通信を行う前に、エッジサーバと他のレプリカで有効なログインチケットが必要になるため、セキュリティの強化にも役立ちます。サービスユーザは、Perforceのライセンスを使用しません。

サービスユーザが実行できるのは、以下のコマンドだけです。

  • p4 dbschema

  • p4 export

  • p4 login

  • p4 logout

  • p4 passwd

  • p4 info

  • p4 user

サービスユーザを作成するには、次のコマンドを実行します。

p4 user -f service1

標準のユーザフォームが表示されます。改行を入力して、新しいユーザのType:serviceに設定します。以下に例を示します。

User:      service1
Email:     services@example.com
FullName:  Service User for Replica Server 1
Type:      service

デフォルトでは、p4 usersの出力にはサービスユーザが表示されません。サービスユーザを表示するには、p4 users -aを実行します。

サービスユーザのチケットとタイムアウト

特定のグループのメンバーではない新たに作成されたサービスユーザには、デフォルトのチケットタイムアウトである12時間が適用されます。サービスユーザのチケットの失効が原因で発生する問題を回避するには、サービスユーザ用として、タイムアウト値を非常に長く設定したグループを作成するか、タイムアウト値をunlimitedに設定してグループを作成します。マスターサーバで、次のコマンドを実行します。

p4 group service_users

グループのUsers:リストにservice1を追加して、Timeout:PasswordTimeout:に大きな値またはunlimitedを設定します。

Group:            service_users
Timeout:          unlimited
PasswordTimeout:  unlimited
Subgroups:
Owners:
Users:
        service1

重要

サービスユーザが複製を行うには、p4 loginコマンドで作成されたチケットを持っている必要があります

サービスユーザの権限

サービスユーザにsuper権限を付与するには、マスターサーバ上でp4 protectコマンドを使用します。サービスユーザが実行できるコマンドは非常に制限されているため、super権限を付与しても問題ありません。

メタデータとディポへのアクセスを制御するサーバオプション

マスターサーバを参照するレプリカをP4TARGETを使用して起動する場合、-Mオプション(メタデータへのアクセス)と-Dオプション(ディポへのアクセス)の両方を指定するか、構成可能変数のdb.replication(メタデータへのアクセス)とlbr.replication(バージョンンファイルのディポのライブラリへのアクセス)を設定して、レプリカサーバで拒否するPerforceコマンドと許可するPerforceコマンドを制御する必要があります。

P4TARGET

P4TARGETを、レプリカサーバのデータの取得元となるマスターサーバの完全修飾ドメイン名またはIPアドレスに設定します。P4TARGETを明示的に設定し、p4dコマンドラインで-t protocol:host:portオプションとともに指定することも、p4 configureコマンドを使用して、各名前付きレプリカサーバに対してP4TARGETを設定することもできます。使用可能なprotocolオプションについては、以下の表を参照してください。

ターゲットを指定した場合、p4dコマンドはstartup.nコマンドに対するそのターゲットの構成を検証します。有効なp4 pullコマンドが見つからなかった場合はp4dコマンドが実行され、ユーザが手動でp4 pullコマンドを実行するまで待機状態になります。ターゲットを指定しなかった場合、p4dコマンドは、p4 replicateなどの外部のメタデータ複製ソースが存在するものと仮定します。詳細については、p4 pullコマンドとp4 replicateコマンドの違いを参照してください。

プロトコル

動作

<not set>

tcp4:の動作が使用されますが、アドレスが数値で2つ以上のコロンが含まれている場合は、tcp6:が使用されます。構成可能変数のnet.rfc3484が設定されている場合、OSにより、どのトランスポートを使用するかが決まります。

tcp:

tcp4:の動作が使用されますが、アドレスが数値で2つ以上のコロンが含まれている場合は、tcp6:が使用されます。構成可能変数のnet.rfc3484が設定されている場合、OSにより、どのトランスポートを使用するかが決まります。

tcp4:

IPv4アドレス/ポートにのみ接続待機または接続します。

tcp6:

IPv6アドレス/ポートにのみ接続待機または接続します。

tcp46:

IPv4アドレス/ポートに対して接続待機または接続を試みます。失敗した場合、IPv6への接続または接続待機を試みます。

tcp64:

IPv6アドレス/ポートに対して接続待機または接続を試みます。失敗した場合、IPv4への接続または接続待機を試みます。

ssl:

ssl4:の動作が使用されますが、アドレスが数値で2つ以上のコロンが含まれている場合は、ssl6:が使用されます。構成可能変数のnet.rfc3484が設定されている場合、OSにより、どのトランスポートを使用するかが決まります。

ssl4:

IPv4アドレス/ポートにのみ、SSL暗号化を使用して接続待機または接続します。

ssl6:

IPv6アドレス/ポートにのみ、SSL暗号化を使用して接続待機または接続します。

ssl46:

IPv4アドレス/ポートに対して接続待機または接続を試みます。失敗した場合、IPv6への接続または接続待機を試みます。接続後は、SSLによる暗号化を必要とします。

ssl64:

IPv6アドレス/ポートに対して接続待機または接続を試みます。失敗した場合、IPv4への接続または接続待機を試みます。接続後は、SSLによる暗号化を必要とします。

P4TARGETは、ホストのホスト名にすることも、ホストのIPアドレスにすることもできます。IPv4アドレスとIPv6アドレスの両方がサポートされています。listen設定で、ワイルドカードの「*」を使用して、すべてのIPアドレスを参照することができます。ただし、CIDR表記を使用していない場合に限られます。

ワイルドカードの「*」をIPv6アドレスで使用する場合、IPv6アドレス全体を角括弧で囲む必要があります。例えば、[2001:db8:1:2:*][2001:db8:1:2::]/64は同じ意味になります。CIDR表記を使用してIPv6アドレスを角括弧で囲み、ワイルドカードの「*」は使用しないことをお勧めします。

サーバ起動コマンド

p4 configureコマンドを以下のように指定すると、起動時に自動的にコマンドを実行するようにPerforceサーバを構成することができます。

p4 configure set "servername#startup.n=command"

nは、コマンドの実行順序を表します。例えば、startup.1として指定されたコマンドが最初に実行され、startup.2として指定されたコマンドが次に実行されます。有効な起動コマンドは、p4 pullだけです。

p4 pullコマンドとp4 replicateコマンドの違い

Perforceでは、p4 replicateコマンドに基づくより限定的な形式の複製もサポートされます。このコマンドは、ファイルの内容は複製しませんが、各テーブルのメタデータのフィルタリングはサポートしています。

p4 replicateコマンドの詳細については、以下のページで、Perforceナレッジベースの「Perforce Metadata Replication」を参照してください。

http://answers.perforce.com/articles/KB_Article/Perforce-Metadata-Replication

SSLのサポートを有効にする

レプリカサーバとそのエンドユーザとの接続を暗号化するには、そのレプリカサーバ独自の有効なプライベートキーと証明書のペアを、P4SSLDIR環境変数で指定されたディレクトリに格納する必要があります。レプリカサーバに対する証明書とキーの生成および管理は、マスターサーバの場合と同じ方法で実行されます。詳細については、SSLのサポートを有効にするを参照してください。ユーザのPerforceアプリケーションは、レプリカサーバのフィンガープリントを信頼するように構成されている必要があります。

レプリカサーバとマスターサーバとの接続を暗号化するには、マスターサーバのフィンガープリントを信頼するようにレプリカサーバを構成する必要があります。そのため、レプリカサーバのp4dコマンドを実行するユーザ(通常はサービスユーザ)は、p4 trustコマンドを使用して、マスターのPerforceサーバのフィンガープリントを認識するP4TRUSTファイルを作成する必要があります。

P4TRUST変数は、SSL信頼ファイルのパスを指定します。この環境変数は、以下の場合に設定する必要があります。

  • SSLが有効になっているマスターサーバにレプリカを接続する必要がある場合

  • SSLが有効になっているコミットサーバにエッジサーバを接続する必要がある場合

複製機能の使用

レプリカサーバを使用すると便利なケースをいくつか紹介します。

  • フェイルオーバーサーバやウォームスタンバイサーバの場合、2つのp4 pullコマンドを並行して実行することにより、サーバのメタデータとバージョンファイルの両方を複製することができます。レプリカサーバごとに、バージョン化ファイルを複製するには1つ以上のp4 pull -uインスタンス、メタデータを複製するためには1つのp4 pullが必要になります。

    メタデータに対してp4 pull、バージョンファイルに対してp4 pull -uを両方とも使用する場合は、p4d -t protocol:host:port -Mreadonly -Dreadonlyコマンドを使用してレプリカサーバを起動します。サーバのメタデータとディポファイルに対する読み取り専用アクセス権を必要とするコマンドは、正常に実行されます。サーバのメタデータやディポファイルへの書き込みを行うコマンドは失敗します。

    この構成の詳細については、読み取り専用レプリカを構成するを参照してください。

  • オフラインのチェックポイントやレポートサーバを構成する場合は、マスターサーバのメタデータだけを複製します。バージョンファイルを複製する必要はありません。

    p4 pullコマンドを使用してメタデータだけを複製するには、p4d -t protocol:host:port -Mreadonly -Dnoneコマンドでサーバを起動します。その際、ターゲットを指定する必要があります。サーバを構成する際に、ディポファイルを複製するp4 pull -uコマンドを生成するような構成は行わないでください。

    いずれの場合も、サーバのメタデータに対する読み取り専用アクセス権を必要とするコマンドは正常に実行され、サーバのメタデータへの書き込みを行うコマンドや、ディポファイルにアクセスしようとするコマンドは、レプリカサーバによって拒否されます。

複製とプロテクション

レプリカユーザのワークステーションのIPアドレスをプロテクションテーブルに対して適用するには、そのワークステーションのIPアドレスの先頭にproxy-という文字列を追加します。

例えば、192.168.10.0/24というサブネット上のワークステーションでリモート開発を行っている組織を考えてみます。この組織には、ローカル開発を行っている中央オフィスもあり、この中央オフィスは10.0.0.0/8というサブネット上に存在しています。Perforceサービスはサブネット10.0.0.0/8上に存在し、レプリカはサブネット192.168.10.0/24上に存在しています。リモートサイトのユーザはremotedevグループに属しており、時々中央オフィスにアクセスします。各サブネットには、対応するIPv6アドレスのセットも存在しています。

remotedevグループのメンバーが、リモートサイトでの作業時にはレプリカを使用し、ローカルサイトにアクセスする際にブローカを使用しないようにするには、プロテクションテーブルに以下の行を追加します。

list    group    remotedev     192.168.10.0/24              -//...
list    group    remotedev     [2001:db8:16:81::]/48        -//...
write   group    remotedev     proxy-192.168.10.0/24         //...
write   group    remotedev     proxy-[2001:db8:16:81::]/48   //...
list    group    remotedev     proxy-10.0.0.0/8             -//...
list    group    remotedev     proxy-[2001:db8:1008::]/32   -//...
write   group    remotedev     10.0.0.0/8                    //...
write   group    remotedev     proxy-[2001:db8:1008::]/32    //...

1行目では、remotedevグループのユーザが、サブネット192.168.10.0/24上のワークステーションからレプリカを使用せずPerforceにアクセスしようとした場合、このグループ内のすべてのユーザに対してlistアクセスが拒否されます。2行目では、IPV6のサブネット[2001:db8:16:81::]/48からアクセスしようとした場合に、1行目と同じ方法でアクセスが拒否されます。

3行目では、remotedevグループのユーザがレプリカを使用してサブネット192.168.10.0/24から作業している場合に、このグループ内のすべてのユーザに対してwriteアクセスが許可されます。リモートサイトのワークステーションのユーザは、レプリカを使用する必要があります(レプリカ自体がこのサブネット内に存在している必要はありません。例えば、192.168.20.0に存在していても構いません)。4行目では、IPV6のサブネット[2001:db8:16:81::]/48からアクセスしようとした場合に、3行目と同じ方法でアクセスが許可されます。

同様に、5行目と6行目では、remotedevユーザが中央オフィスのサブネット(10.0.0.0/8[2001:db8:1008::]/32)上のワークステーションからレプリカを使用しようとした場合、このユーザに対してlistアクセスが拒否されます。7行目と8行目では、中央オフィスのサブネット上のワークステーションから直接Perforceサーバにアクセスするremotedevユーザに対して、書き込みアクセス権が許可されます。remotedevグループのユーザがローカルサイトにアクセスする場合は、Perforceサーバに直接アクセスする必要があります。

Perforceサービスがプロテクションテーブルのエントリを評価する際に、dm.proxy.protects構成も評価されます。

dm.proxy.protectsのデフォルト値は「1」ですが、この場合、各種の媒介(プロキシ、ブローカ、またはエッジサーバ)を経由して接続するすべてのクライアントホストのアドレスの先頭に、proxy-というプレフィックスが追加されます。このプレフィックスは、間接的な接続であることを示しています。

dm.proxy.protectsの値を「0」に設定すると、proxy-プレフィックスが削除され、プロテクションエントリを1セットだけ書き込むことができるようになります。このエントリは、直接接続しているクライアントと間接的に接続しているクライアントの両方に適用されます。これは便利ですが、媒介を経由して接続することに問題がある場合、安全性が低下します。この設定を使用する場合は、すべての媒介がリリース2012.1以降になっている必要があります。

レプリカのタイプによる要求の処理方法の違い

各種のレプリカタイプの違いを知る1つの方法は、それぞれのレプリカタイプがユーザからの要求をどのような方法で処理するのかを確認することです。例えば、ユーザからの要求をサーバがローカルで処理するのかどうか、ユーザからの要求をサーバが転送するのかどうか、サーバからエラーを返すのかどうか、などを確認します。以下の表で、レプリカタイプの違いを説明します。

  • 読み取り専用コマンド: p4 files, p4 filelog, p4 fstat, p4 user -o

  • 処理中 コマンド: p4 sync, p4 edit, p4 add, p4 delete, p4 integrate, p4 resolve, p4 revert, p4 diff, p4 shelve, p4 unshelve, p4 submit, p4 reconcile.

  • グローバル更新 コマンド: p4 user, p4 group, p4 branch, p4 label, p4 depot, p4 stream, p4 protect, p4 triggers, p4 typemap, p4 server, p4 configure, p4 counter.

レプリカタイプ

読み取り専用コマンド

p4 sync、p4 client

処理中コマンド

グローバル更新コマンド

ディポスタンバイ、スタンバイ、レプリカ

はい(ローカル)

エラー

エラー

エラー

転送スタンバイ、転送レプリカ

はい(ローカル)

転送

転送

転送

ビルドサーバ

はい(ローカル)

はい(ローカル)

エラー

エラー

エッジサーバ、ワークスペースサーバ

はい(ローカル)

はい(ローカル)

はい(ローカル)

転送

標準サーバ、ディポマスター、コミットサーバ

はい(ローカル)

はい(ローカル)

はい(ローカル)

はい(ローカル)

読み取り専用レプリカを構成する

ウォームスタンバイサーバをサポートするには、レプリカサーバで、マスターサーバのメタデータとバージョンファイル両方の最新のコピーが必要になります。

注意

複製は非同期の処理であり、複製サーバをバックアップや障害復旧の唯一の手段に利用することは推奨されません。データベース・チェックポイントとディポ・バックアップを(テープ、リモート・ストレージ、またはその他の方法で)別々に取っておくことをお勧めします。障害回復とフェイルオーバーの手順は複雑で、それぞれの現場によって異なります。Perforceのコンサルタントが、障害回復とフェイルオーバー手順の立案と策定をお手伝いいたします。詳細については、以下のページを参照してください。

http://www.perforce.com/services/consulting_overview

以下の例では、一定量のデータが存在する既存のPerforceサーバのウォームスタンバイサーバとしてレプリカを構成しています。例えば、以下のようなケースを考えてみます。

  • Masterという名前のマスターサーバが、ポート11111を使用してmasterという名前のホスト上で稼働しています。このサーバのルートディレクトリは/p4/masterです。

  • レプリカサーバはReplica1という名前になり、ポート22222を使用してreplicaという名前のホストマシン上で稼働するように構成されます。このサーバのルートディレクトリは/p4/replicaになります。

  • サービスユーザ名はserviceです。

  • 注意

    p4 configureコマンドで設定された値を使用するには、サーバが自身の名前を知っている必要があるため、p4 configureコマンドを使用してP4NAMEを定義することはできません。

    正しくないサーバルートが指定される可能性があるため、p4 configureコマンドを使用してP4ROOTを定義することはできません。

マスターサーバの設定

レプリカの動作を定義するには、p4 configure setコマンドを使用して、マスターサーバのdb.configファイルに構成情報を入力する必要があります。最初にマスターサーバを構成してください。マスタサーバの設定が、後でレプリカサーバに複製されます。

マスターサーバを構成するには、スーパーユーザとしてPerforceにログインし、以下の手順を実行します。

  1. master:11111をマスターサーバとして使用するようにReplica1という名前のサーバを設定し、メタデータとバージョンファイルを取得するには、以下のコマンドを実行します。

    p4 -p master:11111 configure set Replica1#P4TARGET=master:11111

    以下の応答が表示されます。

    For server 'Replica1', configuration variable 'P4TARGET' set to 'master:11111'

注意

同じようにみえる複数のサーバを操作する場合の混乱を避けるには、-uオプションを使用してスーパーユーザのアカウントを指定し、次に-pオプションを使用して、マスターのPerforceサーバのホストとポートを明示的に指定します。

説明を簡潔にするため、この例ではこれらのオプションを省略しています。実稼働環境のコマンドラインで、ホストとポートを指定してください。

  1. 指定のファイル名を使用してレプリカサーバのログファイルを保存するようにReplica1サーバを設定します。固有のログ名を指定すると、デバッグやパフォーマンス測定用のデータを収集する際の問題を回避することができます。

    p4 configure set Replica1#P4LOG=replica1Log.txt

  2. Replica1の構成可能変数serverを「1」に設定します。これは、サーバ起動オプションの「-vserver=1」を指定した場合と同じ結果になります。

    p4 configure set Replica1#server=1

  3. プロセスの監視を有効にするには、Replica1の構成可能変数monitorを「1」に設定します。

    p4 configure set Replica1#monitor=1

  4. Replica1の複製プロセスを処理するには、以下に示す3つのstartup.nコマンドを構成します(スペースで区切られた複数の値を受け渡す場合は、その値のセット全体を二重引用符で囲む必要があります)。

    以下に示す最初の起動プロセスにより、ジャーナルデータだけを1秒間隔でポーリングするようにp4 pullが設定されます。

    p4 configure set "Replica1#startup.1=pull -i 1"

    次の2つの設定では、起動時に2つのp4 pullスレッドを生成するようにサーバが構成されます。各スレッドは、アーカイブデータの転送を1秒間隔でポーリングします。


    p4 configure set "Replica1#startup.2=pull -u -i 1"
    p4 configure set "Replica1#startup.3=pull -u -i 1"

    p4 pull -uコマンドにより、アーカイブデータを複製するための個別のスレッドが作成されます。アーカイブデータの転送がメタデータの複製よりも遅れ始めた場合、負荷の高いサーバではより多くのスレッドが必要になることがあります。追加のp4 pull -uプロセスが必要かどうかを判断するには、rdb.lbrテーブルの内容を確認します。このテーブルには、マスターのPerforceサーバからレプリカサーバに転送されたアーカイブデータが記録されます。

    レプリカの稼働中にこのテーブルの内容を表示するには、以下のコマンドを実行します。

    p4 -p replica:22222 pull -l

    同様に、アクティブなファイル転送の数や保留中のファイル転送の数だけを確認する場合は、p4 -p replica:22222 pull -l -sコマンドを実行します。

    p4 pull -l -sコマンドで、保留中の転送数が多いことがわかった場合、"p4 pull -u" startup.nコマンドを追加して問題を解決することをお勧めします。

    特定のファイル転送が繰り返し失敗する場合は(マスター上で回復不能なエラーが発生していることが原因として考えられます)、p4 pull -d -f file -r revコマンドを使用して、保留中の転送をキャンセルすることができます。このコマンドのfileとrevは、それぞれファイル番号とリビジョン番号を示します。

  5. 以下のように、構成可能変数のdb.replication(メタデータへのアクセス)とlbr.replication(ディポファイルへのアクセス)を読み取り専用に設定します。


    p4 configure set Replica1#db.replication=readonly
    p4 configure set Replica1#lbr.replication=readonly

    このレプリカサーバはウォームスタンバイサーバ(フェイルオーバーサーバ)として使用されるため、マスターサーバのメタデータとバージョン付きディポファイルのライブラリの両方が複製されます。レプリカが稼働している場合、そのレプリカのユーザは、メタデータとサーバのディポファイルのライブラリの両方にアクセスするコマンドを実行することができます。

  6. 以下のコマンドを使用して、サービスユーザを作成します。

    p4 user -f service

    serviceユーザの仕様が、デフォルトのエディタで開きます。以下の行を、ユーザ仕様に追加します。

    Type: service

    ユーザ仕様を保存し、デフォルトのエディタを終了します。

    デフォルトでは、標準ユーザと同じ12時間のログインタイムアウトがサービスユーザに対して設定されます。サービスユーザのチケットがタイムアウトにならないようにするには、長いタイムアウト値が設定されたグループをマスターサーバ上で作成します。以下の例では、Timeout:フィールドの値を20億秒(約63年)に設定しています。

    p4 group service_group

    Users: service
    Timeout: 2000000000
    

    詳細については、サービスユーザのチケットとタイムアウトを参照してください。

  7. プロテクションテーブルで、サービスユーザのプロテクションをsuperに設定します。(サービスユーザの権限を参照。)すべてのPerforceサーバについて、セキュリティレベルを1以上に設定することをお勧めします(可能であれば3に設定することで、サービスユーザは強固なパスワードの入力が必要になります。理想としては4に設定し、許可されているサービスユーザだけが、複製処理やリモートディポトランザクションを実行できるようにします)。


    p4 configure set security=4
    p4 passwd

  8. serviceUserReplica1構成可能変数をserviceに設定します。

    p4 configure set Replica1#serviceUser=service

    この手順により、レプリカサーバがマスターサーバに対してserviceユーザとして認証されます。これは、-u serviceオプションを指定してp4dコマンドを実行した場合と同じ結果になります。

  9. レプリカサーバを実行しているユーザがホームディレクトリを持っていない場合や、デフォルトの.p4ticketsファイルが保存されるディレクトリへの書き込みをレプリカのPerforceサーバプロセスが実行できない場合は、以下のコマンドを使用して、レプリカのPerforceサーバのルートディレクトリ内の書き込み可能チケットを指すようにレプリカのP4TICKETSの値を設定します。

    p4 configure set "Replica1#P4TICKETS=/p4/replica/.p4tickets"

レプリカを作成する

レプリカサーバを構成して起動するには、以下の手順を実行します。

  1. マスターサーバでチェックポイントを作成し、そのチェックポイントをレプリカに復元することにより、レプリカサーバをブートストラップします。

    p4 admin checkpoint

    (新しいセットアップの場合、チェックポイントファイルの名前はcheckpoint.1になります)

  2. チェックポイントをレプリカサーバのP4ROOTディレクトリに移動して再生します。

    p4d -r /p4/replica -jr $P4ROOT/checkpoint.1

  3. マスターサーバのバージョンファイルをレプリカにコピーします。

    バージョンファイルには、テキストファイル(「,v」で終了するRCS形式のファイル)とバイナリファイル(個別のバイナリファイルが格納される、「,d」で終了するディレクトリ)の両方が含まれます。テキストファイルをコピーする場合は、レプリカホストのファイルシステム用に行末が正しく変換されるような方法でコピーする必要があります。

    マスター上の絶対パスを使用してディポが指定されている場合は、レプリカ上でも同じパスを使用する必要があります(または、各ディポのMap:フィールドの相対パスを使用してください。この場合、サーバのルートに関連する場所にバージョンファイルが格納されます)。

  4. 有効なチケットファイルを作成するには、p4 loginコマンドを使用してマスターサーバに接続し、レプリカサーバサービスユーザの代わりにチケットを取得します。レプリカサーバをホストするマシンで、以下のコマンドを実行します。

    p4 -u service -p master:11111 login

    次に、レプリカサーバのサービスユーザのP4TICKETSファイルが保存されている場所にチケットを移動します。

この時点で、マスターサーバにアクセスして複製を開始するようにレプリカサーバが構成されます。具体的には、以下の項目が複製されます。

  • 長いタイムアウト値が設定されたグループ(service_users)内のサービスユーザ(service)

  • レプリカサーバのサービスユーザの有効なチケット(p4 loginから)

  • Replica1P4NAMEを持つサーバに適用される、以下の事前定義設定を持つマスターサーバのdb.configの複製されたコピー

    • 指定されたサービスユーザ(serviceという名前)。コマンドラインで-u serviceを指定した場合と同じです。

    • master:11111というターゲットサーバ。コマンドラインで-t master:11111を指定した場合と同じです。

    • readonlyに設定されたdb.replicationlbr.replication。コマンドラインで-M readonly -D readonlyを指定した場合と同じです。

    • マスターサーバの起動時に実行されるように構成されている一連のp4 pullコマンド

レプリカサーバを起動する

Replica1サーバを指定するには、P4NAMEを設定するか、以下のように-Inオプションを設定してレプリカを起動します。

p4d -r /p4/replica -In Replica1 -p replica:22222 -d

レプリカが起動すると、以前にコピーしたdb.configテーブルのレプリカのコピーから、マスターサーバのすべての構成情報が読み込まれます。その後、レプリカによって3つのp4 pullスレッドが生成されます。1つは、マスターサーバにメタデータをポーリングするスレッドで、残りの2つは、マスターサーバにバージョンファイルをポーリングするスレッドです。

レプリカをテストする

p4 pullをテストする

p4 pullコマンド(Replica1startup.n構成で指定)が実行されているかどうかを確認するには、以下のコマンドを実行します。

p4 -u super -p replica:22222 monitor show -a

18835 R service00:04:46 pull -i 1
18836 R service00:04:46 pull -u -i 1
18837 R service00:04:46 pull -u -i 1
18926 R super 00:00:00 monitor show -a

何らかの理由で複製を停止する場合は、p4 monitor terminateコマンドを使用します。

p4 -u super -p replica:22222 monitor terminate 18837

** process '18837' marked for termination **

複製を再開する場合は、Perforceサーバプロセスを再起動するか、以下の複製コマンドを手動でもう一度実行します。

p4 -u super -p replica:22222 pull -u -i 1

p4 pullプロセスまたはp4 pull -uプロセスあるいはその両方が終了しても、レプリカサーバのp4dコマンドが稼働している間は、レプリカユーザに対して読み取り専用コマンドが引き続き実行されます。

ファイルの複製をテストする

自分のワークスペースに新しいファイルを作成します。

echo "hello world" > myfile

新しいファイルを追加用としてマーキングします。

p4 -p master:11111 add myfile

ファイルを送信します。

p4 -p master:11111 submit -d "testing replication"

レプリカ上でpullコマンドが実行されるまで数秒待ち、複製されたファイルのレプリカを確認します。

p4 -p replica:22222 print //depot/myfile

//depot/myfile#1 - add change 1 (text)
hello world

何らかの理由で転送処理が中断し、ユーザが要求したバージョンファイルが存在しない場合、レプリカサーバはそのファイルをバックグラウンドでマスターから取得します。

注意

-M readonly -D readonlyモードのレプリカサーバは、p4 pull -uコマンドを使用せずに起動された場合でも、マスターサーバからバージョンファイルを取得してバージョンファイルをレプリカに複製します。こうしたサーバは、-M readonly -D ondemandモードで稼働するサーバや、構成可能変数のlbr.replicationondemandに設定されているサーバと同じように、「オンデマンド」レプリカとして機能します。

管理者は、このようなオンデマンドレプリカを作成すると、サーバのパフォーマンスやリソースの利用率に影響する可能性があることに注意する必要があります。例えば、「p4 print //...」などのコマンドを入力すると、ディポ内のすべてのファイルが読み込まれることになります。

レプリカを検証する

マスターサーバのバージョンファイルをレプリカサーバにコピーすると、オペレーティングシステムによってそれらのファイルが転送されます。この転送プロセス中にデータの破損が発生していないかどうかを確認するには、レプリカサーバ上で以下のようにp4 verifyコマンドを実行します。

p4 verify //...

レプリカ上でエラーが発生し、マスター上では発生していない場合は、転送中にデータの破損が発生したか、元のコピー操作におけるディスクへの書き込みでデータの破損が発生しています(フェイルオーバーサーバのストレージは実稼働サーバのストレージと同じくらい破損しやすいため、p4 verifyコマンドを定期的に実行してください)。

レプリカを使用する

マスターサーバに対して、すべての通常の操作を実行することができます(p4 -p master:11111 command)。マスターサーバの負荷を減らすには、読み取り専用のレポートコマンドをレプリカサーバで実行します(p4 -p replica:22222 command)。レプリカは-M readonly -D readonlyモードで稼働するため、メタデータとディポファイルコンテンツの両方を読み取るコマンドがサポートされます。また、レポートコマンド(p4 annotatep4 changesp4 filelogp4 diff2p4 jobsなど)も正常に機能します。ただし、サーバのメタデータやディポファイルを更新するコマンドは拒否されます。

メタデータを更新するコマンド

一部のシナリオは比較的単純です。ここではp4 syncなどのコマンドについて考えてみます。ワークスペースを同期するたびにPerforceサーバのメタデータ(db.haveテーブルに格納されている「have」リスト)を更新する必要があるため、p4 syncコマンドを単純に実行しただけでは失敗します。代わりにp4 sync -pコマンドを使用すると、haveリストを更新することなくワークスペースにデータを取り込むことができます。

p4 -p replica:22222 sync -p //depot/project/...@1234

この操作が正常に実行されるのは、このコマンドがサーバのメタデータを更新しないためです。

メタデータに微妙な影響を与えるコマンドもあります。例えば、多くのPerforceコマンドは、ユーザやクライアントなどの仕様に関連する最終更新日時を更新します。こうしたコマンドをレプリカサーバ上で使用する場合、-oオプションを指定しないと、エラーが発生します。例えば、クライアント仕様のUpdate:フィールドとAccess:フィールドを更新する以下のp4 clientコマンドは失敗します。

p4 -p replica:22222 client replica_client

Replica does not support this command.

ただし、以下のp4 client -oコマンドは正常に実行されます。

p4 -p replica:22222 client -o replica_client

(client spec is output to STDOUT)

サーバのメタデータへの暗黙的な書き込み操作が原因でコマンドの実行がブロックされる場合は、回避策として上記の方法を試してください(p4 submitなどの一部のコマンドは、レプリカサーバのディポファイルへの書き込みを実行しようとするため、必ず失敗します。こうしたコマンドは、-D readonlyオプションによってブロックされます)。

Perforceブローカを使用してコマンドをリダイレクトする

レプリカサーバでPerforceブローカを使用して、読み取り専用コマンドをレプリカサーバにリダイレクトすることができます。この方法により、すべてのユーザが同じprotocol:host:port設定(ブローカ)に接続できるようになります。この構成では、主要なコマンドを適切なPerforceサーバに透過的にリダイレクトするようにブローカが設定されます。

このようなコマンドの例については、以下のサイトで、Perforceナレッジベースの「Using P4Broker With Replica Servers」を参照してください。

http://answers.perforce.com/articles/KB_Article/Using-P4Broker-With-Replica-Servers

Perforceブローカの詳細については、“Perforceブローカ”を参照してください。

レプリカサーバをアップグレードする

マスターサーバからの複製を行うサーバインスタンスを最初にアップグレードすることをお勧めします。レプリカが互いに連鎖している場合は、マスターから最も遠いダウンストリームに位置するレプリカからアップグレードを開始し、マスタサーバに対してアップストリームの方向へと順にアップグレードを行ってください。直近のアップストリームのサーバのアップグレードが完了するまで、ダウンストリームのレプリカは停止したままにしてください。

注意

リリース2013.3では、メタデータをdb.*ファイルに保存する方法に影響する大きな変更が導入されました。ただし、データベーススキーマ、チェックポイントの形式、ジャーナルファイルについては、2013.2と2013.3で違いはありません。

そのため、2013.2から2013.3にアップグレードする場合は、マスターのアップグレードが完了するまでレプリカを停止しておけばそれで済みますが、2013.3のマスターを再起動する前に、レプリカとそのダウンストリームのすべてのレプリカを2013.2以上にアップグレードする必要があります。

2013.2以前のリリースから2013.3以降のリリースにアップグレードする場合は、すべてのアーカイブの転送処理が完了してから、レプリカをシャットダウンしてアップグレードを開始することをお勧めします。レプリカを再起動する前に、レプリカサーバのルートにあるrdb.lbrファイルを手動で削除する必要があります。

詳細については、以下のサイトで、Perforceナレッジベースの「Upgrading Replica Servers」を参照してください。

http://answers.perforce.com/articles/KB_Article/Upgrading-Replica-Servers/

転送レプリカを構成する

転送レプリカは、Perforceプロキシの機能に加え、レプリカのパフォーマンスが改善されたものです。これに関連して、以下の点を考慮する必要があります。

Perforceプロキシの方が構成と保守は簡単ですが、キャッシュされるのはファイルの内容だけで、メタデータはキャッシュされません。転送レプリカではファイルの内容とメタデータの両方がキャッシュされるため、マスターサーバから追加のデータを要求することなく、多くのコマンドを処理することができます。転送レプリカのこのような動作によって、マスターサーバからより多くのタスクを開放して、パフォーマンスを向上させることができます。ただしその一方で、転送レプリカはプロキシに比べてより高度なマシンプロビジョニングと管理面での配慮を必要とします。

読み取り専用レプリカは、メタデータを更新するコマンドを拒否します。転送レプリカはそのようなコマンドを拒否しませんが、マスターサーバで処理するよう転送して、マスターサーバによってメタデータの更新が行われ転送レプリカに返されるまで待機します。転送レプリカに接続されているユーザはレプリカのメタデータに書き込むことはできませんが、整合性のあるデータベースビューを表示することができます。

サーバ上の操作を監査する場合、それぞれの転送レプリカサーバで独自のP4AUDITログを構成する必要があります。

マスターサーバを構成する

以下に示す例では、masterという名前の標準サーバと、forwardというホスト上のfwd-replicaという名前の転送レプリカサーバが存在する環境を想定しています。

  1. 最初に、ウォームスタンバイサーバ用の読み取り専用レプリカを構成します。詳細については、読み取り専用レプリカを構成するを参照してください(Replica1ではなくfwd-replicaという名前を使用します)。

  2. マスターサーバ上で、以下のように転送レプリカを構成します。

    p4 server fwd-1667

    The following form is displayed:

    ServerID:       fwd-1667
    Name:           fwd-replica
    Type:           server
    Services:       forwarding-replica
    Address:        tcp:forward:1667
    Description:
            Forwarding replica pointing to master:1666
    

転送レプリカを構成する

  1. レプリカマシン上で、レプリカサーバにサーバIDを割り当てます。

    p4 serverid fwd-1667

    serverID:fwd-1667のレプリカサーバ(以前はName:fwd-replicaが割り当てられていたサーバ)がマスターサーバから自身の構成情報を取得する場合、このレプリカサーバは転送レプリカサーバとして機能します。

  2. レプリカマシン上で、レプリカサーバを再起動します。

    p4 admin restart

ビルドファームサーバを構成する

継続的な統合などの開発プロセスは、Perforceインフラストラクチャに対して大きな負荷を与える可能性があります。自動化ビルドプロセスは、Perforceサーバに頻繁にアクセスして最近の変更を監視し、変更されたソースファイルを取得します。自動化ビルドプロセスのクライアントワークスペースの定義と関連するhaveリストも、サーバ上のストレージとメモリを占有します。

ビルドファームサーバを使用すると、自動化ビルドプロセスの負荷を個々のマシンに分散できるため、メインのPerforceサーバのリソースをユーザの日常業務で使用できるようになります。

ビルドファームサーバは、リリース2012.1のPerforceサーバで導入された機能です。リリース2013.2でエッジサーバが導入されたため、現在ではビルドファームサーバの代わりにエッジサーバを使用することをお勧めしています。“コミットエッジアーキテクチャ”で説明しているように、エッジサーバにはビルドファームサーバのすべての機能が組み込まれています。また、ビルドプロセスの一部として書き込みコマンドを実行できる柔軟な新機能により、ビルドファームサーバと比べてより多くのタスクをメインサーバからエッジサーバに移行して、パフォーマンスを向上させることができます。

ビルドファームサーバとして使用するPerforceサーバでは、以下の処理を実行できる必要があります。

  • クライアントワークスペースの作成と構成

  • クライアントワークスペースの同期

読み取り専用レプリカに対してビルドファームサーバを実装する場合の問題点は、Perforce環境の場合、上記のいずれの操作でもメタデータへの書き込みが必要になるということです。ビルド環境でクライアントワークスペースを使用するには、クライアントワークスペースのルートしかない場合であっても、そのワークスペース上にビルド環境固有の情報が存在している必要があります。また、ビルドツールを使用してクライアントワークスペースを効率的に同期するには、すでに同期されているファイルのレコードをビルドサーバで保存する必要があります。

これらの問題を解決するため、ビルドファームレプリカは、特定のメタデータの独自のローカルコピーをホストします。また、ビルドファームレプリカは、読み取り専用レプリカ環境でサポートされるPerforceコマンドのほかに、p4 clientコマンドとp4 syncコマンドもサポートします(対象のレプリカにバインドされるワークスペースに適用された場合)。

サーバ上の操作を監査する場合、それぞれのビルドファームレプリカサーバで独自のP4AUDITログを構成する必要があります。

マスターサーバを構成する

以下に示す例では、masterという名前の標準サーバと、builderというホスト上のbuildfarm1という名前のビルドファームレプリカサーバが存在する環境を想定しています。

  1. 最初に、ウォームスタンバイサーバ用の読み取り専用レプリカを構成します。詳細については、読み取り専用レプリカを構成するを参照してください(buildfarm1という名前の読み取り専用レプリカを作成します)。

  2. マスターサーバ上で、以下のようにマスターサーバを構成します。

    p4 server master-1666

    次のフォームが表示されます。

# A Perforce Server Specification.
#
#  ServerID:    The server identifier.
#  Type:        The server type: server/broker/proxy.
#  Name:        The P4NAME used by this server (optional).
#  Address:     The P4PORT used by this server (optional).
#  Description: A short description of the server (optional).
#  Services:    Services provided by this server, one of:
#          standard: standard Perforce server
#          replica: read-only replica server
#          broker: p4broker process
#          proxy: p4p caching proxy
#          commit-server: central server in a distributed installation
#          edge-server: node in a distributed installation
#          forwarding-replica: replica which forwards update commands
#          build-server: replica which supports build automation
#          P4AUTH: server which provides central authentication
#          P4CHANGE: server which provides central change numbers
#
# Use 'p4 help server' to see more about server ids and services.

ServerID:       master-1666
Name:           master
Type:           server
Services:       standard
Address:        tcp:master:1666
Description:
        Master server - regular development work
  1. マスターサーバのserver.idファイルを作成します。マスターサーバで、次のコマンドを実行します。

    p4 -p master:1666 serverid master-1666

  2. マスターサーバを再起動します。

    起動時に、マスターサーバは自身のサーバIDであるmaster-1666server.idファイルから読み込みます。マスターサーバは、masterP4NAMEを取得し、masterP4NAME設定に適用される構成可能変数を使用します。

ビルドファームレプリカを構成する

  1. マスターサーバ上で、以下のようにビルドファームレプリカサーバを構成します。

    p4 server builder-1667

    The following form is displayed:

    ServerID:       builder-1667
    Name:           buildfarm1
    Type:           server
    Services:       build-server
    Address:        tcp:builder:1667
    Description:
            Build farm - bind workspaces to builder-1667
            and use a port of tcp:builder:1667
    
  2. ビルドファームレプリカサーバのserver.idファイルを作成します。マスターサーバではなく、レプリカサーバで以下のコマンドを実行します。

    p4 -p builder:1667 serverid builder-1667

  3. レプリカサーバを再起動します。

    起動時に、レプリカビルドファームサーバは自身のサーバIDであるbuilder-1667server.idファイルから読み込みます。

    サーバレジストリはマスターサーバからすべてのレプリカサーバに対して自動的に複製されるため、再起動されたビルドファームサーバはbuildfarm1P4NAMEを取得し、buildfarm1P4NAME設定に適用される構成可能変数を使用します。

    この例のビルドファームサーバは、p4 serverフォームのServices:フィールド内のbuild-server設定も認識します。

ワークスペースをビルドファームレプリカにバインドする

この時点で、masterというマスターサーバ(サーバID: master-1666)と、buildfarm1というbuild-serverレプリカサーバ(サーバID: builder-1667)の2つのサーバが稼働しています。

  1. クライアントワークスペースをビルドファームサーバにバインドします。

    このサーバはbuild-serverサービスを提供するように構成されているため、クライアントワークスペース(db.domaindb.view.rp)のリストの独自のローカルコピーと、それぞれのhaveリスト(db.have.rp)を保持します。

    レプリカサーバで、以下のp4 clientコマンドを使用してクライアントワークスペースを作成します。

    p4 -c build0001 -p builder:1667 client build0001

    ビルドファームレプリカ上で新しいワークスペースを作成する場合は、現在のクライアントワークスペースに、builder:1667で必要なサーバIDに一致するIDが設定されている必要があります。ワークスペースbuild0001はまだ作成されていないため、-c clientnameオプションを指定して、build0001を現在のクライアントワークスペースとして手動で指定し、build0001p4 clientコマンドの引数として指定する必要があります。詳細については、下記のサイトを参照してください。

    http://answers.perforce.com/articles/KB_Article/Build-Farm-Client-Creation-Error

    p4 clientフォームが表示されたら、ServerID:フィールドの値をbuilder-1667に設定します。

  2. バインドされたワークスペースを同期します。

    クライアントワークスペースbuild0001builder-1667にバインドされているため、マスターサーバ上のユーザは影響を受けませんが、ビルドファームサーバ上のユーザはユーザ仕様を編集できるだけでなく、ユーザ仕様を同期することもできます。


    export P4PORT=builder:1667
    export P4CLIENT=build0001
    p4 sync

    レプリカのhaveリストは更新されますが、更新内容がマスターに伝播されることはありません。マスターサーバ上のユーザは影響を受けません。

実際のケースでは、組織内のビルドエンジニアが、ビルドファームサーバを直接ポイントするようにP4PORTを設定し直すことにより、新しいサーバを使用するようにサイトのビルドシステムを構成することになります。マスターサーバに送信されたすべての変更について、継続的な統合と自動化ビルドツールによってクライアントワークスペースの作成と同期が実行される環境であっても、マスターサーバのパフォーマンスが影響を受けることはありません。

実際のケースでは、すべてのユーザについて、マスターサーバのパフォーマンスが向上すると考えられます。これは、マスターサーバのデータベースに対する読み取り操作と書き込み操作の数が大幅に減るためです。

ビルドファームレプリカでは必要ないデータベーステーブルがある場合は、p4 pullコマンドに対して、フィルタオプションの-F-Tを使用することをお勧めします。また、レプリカのp4 serverフォームの各フィールド(ArchiveDataFilter:RevisionDataFilter:ClientDataFilter:)を指定することをお勧めします。

自動処理の負荷が1台のマシンのキャパシティを超えた場合は、追加のビルドファームサーバを構成することができます。インストール環境で稼働できるビルドファームサーバの数に制限はありません。

共有アーカイブを持つレプリカサーバを構成する

通常、Perforceレプリカサービスは、ユーザが定義したプル間隔(p4 pull -i 1など)で、メタデータとファイルのアーカイブを取得します。構成可能変数lbr.replicationondemandまたはsharedに設定されている場合(これら2つの値の意味は同じです)、メタデータはプル間隔に基づいて取得され、アーカイブファイルはクライアントが要求した場合のみ取得されます。そのため、新しいファイルは自動的には転送されず、消去されたファイルが自動的に削除されることもありません。

マスターサーバと同じ物理アーカイブファイルを直接共有するようにレプリカサーバが構成されている場合、レプリカサーバとマスターサーバが同じマシン上で稼働しているか、ネットワーク共有ストレージ経由で稼働しているかにかかわらず、レプリカサーバは直接アーカイブにアクセスします。その際、マスターサーバは、アーカイブファイルをレプリカサーバに送信する必要はありません。これにより、高可用性構成の一部を構築することができます。

警告:

レプリカサーバとマスターサーバ間でアーカイブファイルを直接共有する場合、レプリカサーバのlbr.replicationondemandまたはsharedに設定する必要があります。これを設定しないと、アーカイブが破損する場合があります。

マスターサーバとアーカイブファイルを共有するようにレプリカサーバを構成するには、以下の手順を実行します。

  1. マスターサーバとレプリカサーバのクロックが同期されていることを確認します。

    マスターサーバとレプリカサーバが同じオペレーティングシステムでホストされている場合は、何もする必要はありません。

    クロックの同期は、システム管理者が行います。通常は、Network Time Protocolクライアントを使用して、オペレーティングシステムのクロックとインターネット上の時刻サーバ(または、独自のネットワーク上の時刻サーバ)間で同期を行います。

    詳細については、http://support.ntp.org/bin/view/Support/InstallingNTPを参照してください。

  2. レプリカサーバを転送レプリカとして構成します(まだ構成されていない場合)。

    詳細については、読み取り専用レプリカを構成するを参照してください。

  3. lbr.replicationを設定します。

    例: p4 configure set REP13-1#lbr.replication=ondemand

  4. レプリカのルートの共有アーカイブの場所を指定して、レプリカを再起動します。

上記の手順が完了すると、以下の条件が有効になります。

  • 要求された場合のみ、アーカイブファイルの内容が取得されます。この要求は、共有アーカイブに対して行われます。

  • 複製中は、rdb.lbrライブラリアンファイルにエントリが書き込まれることはありません。

  • ファイルコンテンツの転送をスケジュールするコマンド(p4 pull -up4 verify -tなど)は拒否されます。

    p4 pull -u
    This command is not used with an ondemand replica server.
    
    p4 verify -t //depot/...
    This command is not used with an ondemand replica server.
    
  • startup.N=pull -uなどの起動用構成可能変数が定義されている場合、レプリカサーバはそうした構成可能変数が指定されたコマンドを実行しようとします。しかし、アーカイブコンテンツの取得操作は拒否されるため、レプリカのサーバログには以下のようなエラーが記録されます。

    Perforce server error:
            2014/01/23 13:02:31 pid 6952 service-od@21131 background 'pull -u -i 10'
            This command is not used with an ondemand replica server.
    

複製中にメタデータをフィルタリングする

HA/DRソリューションの一部として、通常、すべてのメタデータとバージョンファイルが複製されるようにすることが求められます。それ以外の用途でも(特に、ビルドファームや転送レプリカの場合)、すべてのメタデータとバージョンファイルを複製した結果、非常に多くの冗長データが転送されることがよくあります。

多くの場合、クライアントワークスペースとファイルリビジョンのデータをフィルタリングするようにレプリカサーバを構成すると便利です。例えば、リモートサイトで特定のプロジェクトの作業を行っている開発者は、通常、他のプロジェクトの開発が行われている他のオフィスに存在するすべてのクライアントワークスペースの状態を知る必要はありません。また、ビルドファームは、大企業でよく見られるような延々と続く社内文書の変更内容にアクセスする必要はありません。

メタデータをフィルタリングする最も簡単な方法は、-T tableexcludelistオプションをp4 pullコマンドで使用する方法です。例えば、ユーザのhaveリストやユーザのクライアントワークスペースの状態をビルドファームで参照する必要がない場合は、p4 pull -T db.have,db.workingコマンドを使用して、db.havedb.workingをフィルタリングで完全に除外することができます。

データベーステーブル全体を除外する方法は、サーバ間で受け渡されるデータ量を管理する方法としてはお勧めしません。その理由としては、Perforceコマンドの実行時に参照される可能性が最も高いテーブルに関する知識が必要になることと、バージョンファイルの複製を制御する手段がないことです。

p4 serverフォームのClientDataFilter:フィールド、RevisionDataFilter:フィールド、およびArchiveDataFilter:フィールドを使用すると、複製されるデータをより詳細に制御することができます。この方法では、レプリカサイトで必要なサーバのメタデータとバージョンファイルだけを複製(または、不要なメタデータとバージョンファイルを複製から除外)することができます。

Example 1. クライアントワークスペースのデータとファイルをフィルタリングで除外する

3つのサイトの各ユーザ名がsite[123]-ws-usernameとなっている場合、site1のユーザの部分的なバックアップとして機能するレプリカを、以下のように構成することができます。

ServerID:       site1-1668
Name:           site1backup
Type:           server
Services:       replica
Address:        tcp:site1bak:1668
Description:
        Replicate all client workspace data, except the states of
         workspaces of users at sites 2 and 3.
        Automatically replicate .c files in anticipation of user
         requests. Do not replicate .mp4 video files, which tend
         to be large and impose high bandwidth costs.
ClientDataFilter:
        -//site2-ws-*
        -//site3-ws-*
RevisionDataFilter:
ArchiveDataFilter:
        //....c
        -//....mp4

レプリカを起動する場合は、p4 pullメタデータスレッドで、フィルタを持つサーバ仕様に関連するサーバIDを指定する必要があります。

p4 configure set "site1backup#startup.1=pull -i 30 -P site1-1668"

この構成では、site1に関連するdb.haveだけが複製され、site2site3に関連するワークスペースのメタデータはすべて無視されます。

ファイルに関連するメタデータは、すべて複製されます。.mp4で終わるファイルを除き、ディポ内のすべてのファイルが複製されます。.cで終わるファイルは、ファイルの送信時に自動的にレプリカに転送されます。

この概念を詳しく説明するため、ビルドファームレプリカを例として考えてみます。組織内で行われている作業の内容は、コード開発、ビジネス文書の作成、最新のビデオコマーシャルの編集など、その作業内容にかかわらず、ディポ内の任意の場所に保存することができます。ただし、このビルドファームは、リリース可能製品をビルドするための専用ビルドファームであるため、組織の他の出力情報を即時に使用する必要はありません。

Example 2. ディポのサブセットのメタデータとファイルコンテンツを複製する

リリース可能コードは//depot/releases/...に格納されます。自動ビルドは、このディポ内の変更に基づいています。ディポの他の箇所に対する変更は、個々のユーザのクライアントワークスペースの状態と同様に、フィルタリングで除外されます。

ServerID:       builder-1669
Name:           relbuild
Type:           server
Services:       build-server
Address:        tcp:built:1669
Description:
        Exclude all client workspace data
        Replicate only revisions in release branches
ClientDataFilter:
        -//...
RevisionDataFilter:
        -//...
        //depot/releases/...
ArchiveDataFilter:
        -//...
        //depot/releases/...

レプリカにデータを取り込むには、以下のようなコマンドを使用して、フィルタリングされたチェックポイントを作成します。

p4d -r /p4/master -P builder-1669 -jd myCheckpoint

その後、p4 pullコマンドを使用して、レプリカの更新を続行します。

レプリカを起動する場合は、p4 pullメタデータスレッドで、フィルタを持つサーバ仕様に関連するサーバIDを指定する必要があります。

p4 configure set "relbuild#startup.1=pull -i 30 -P builder-1669"

複製用のメタデータを取得するp4 pullスレッドは、すべてのユーザについて、haveリストを含むすべてのクライアントワークスペースのデータをフィルタリングします。

p4 pull -uスレッドは、//depot/releases/...ブランチのリビジョンに影響する変更(ビルドファームで必要となる唯一の変更)を除き、マスター上のすべての変更を無視します。使用可能な唯一のメタデータは、リリースされたコードに関するメタデータです。リリースされたすべてのコードは、何らかの要求が作成される前に、ビルドファームに自動的に転送されるため、ビルドファームがp4 syncを実行すると、同期処理がローカルで実行されます。

レプリカの整合性を検証する

リリース2013.2には、マルチサーバのインストール環境内のデータの整合性を確保するためのツールセットが用意されています。これらのツールにアクセスするにはp4 journaldbchecksumsコマンドを使用し、ツールの動作を制御するには、3つの構成可能変数(rpl.checksum.autorpl.checksum.changerpl.checksum.table)を使用します。

特定のデータベーステーブル(または、構成可能変数rpl.checksum.autoによって事前に定義されたいずれかのレベルに関連するテーブルのセット)に対してp4 journaldbchecksumsを実行すると、アップストリームサーバにより、テーブルのチェックサム情報を持つジャーナルノートが書き込まれます。このジャーナルノートを受信したダウンストリームレプリカは、チェックサムの検証を行い、整合性に関するイベントの構造化ログにその検証結果を記録します。

この検証処理は、ジャーナルがローテーションされるたびに実行されます。

1つ以上のレプリカサーバを展開した管理者は、整合性イベントの構造化ロギングを有効にし、自分が展開したレプリカサーバに対して構成可能変数のrpl.checksum.*を設定して、整合性イベントのログを定期的に監視する必要があります。

構成

構造化サーバロギングは、すべてのサーバで有効にする必要があります。その際、タイプがintegrityのイベントを記録するログを1つ以上指定する必要があります。以下に例を示します。

p4 configure set serverlog.file.8=integrity.csv

構造化サーバロギングを有効にしたら、構成可能変数rpl.checksum.autorpl.checksum.changerpl.checksum.tableを、必要なレベルの整合性チェックに設定します。ほとんどのサイトでは、以下のように、パフォーマンスとログサイズとの間でバランスを取ることをお勧めします。

p4 configure set rpl.checksum.auto=1 (アップストリームサーバとそのレプリカとの間で変化する可能性の低い追加の検証処理を行う場合は2を指定します)

p4 configure set rpl.checksum.change=2 (この設定では、すべてのチェンジリストについて整合性がチェックされますが、エラーが見つかった場合のみ、ログに記録されます)

p4 configure set rpl.checksum.table=1 (この設定では、スキャン操作またはアップロード操作の実行時に、レプリカによってテーブルの整合性が検証されますが、エラーが見つかった場合のみ、ログに記録されます)

rpl.checksum.autoの有効な設定値を以下に示します。

rpl.checksum.auto

ジャーナルがローテンションされるたびに検証されるデータベーステーブル

0

チェックサムは実行されません。

1

以下に示す最も重要なシステムテーブルとリビジョンテーブルのみ検証されます。

db.configdb.userdb.groupdb.depotdb.streamdb.triggerdb.protectdb.integeddb.integtxdb.archmapdb.revdb.revcxdb.revdxdb.revhxdb.revtx

2

レベル1以上のすべてのデータベーステーブルと、以下のテーブルが検証されます。

db.countersdb.namevaldb.serverdb.svrviewdb.traitsdb.changedb.desc

3

異なる可能性のあるメタデータ(特に、アップストリームサーバをビルドファームまたはエッジサーバのレプリカと比較する場合)を含め、すべてのメタデータが検証されます。

rpl.checksum.changeの有効な設定値を以下に示します。

rpl.checksum.change

各チェンジリストで実行される検証処理

0

検証処理は実行されません。

1

p4 submitコマンドの完了時にジャーナルノートが書き込まれます。

2

レプリカによってチェンジリストのサマリーが検証され、チェンジリストが一致しない場合は、integrity.csvへの書き込みが実行されます。

3

レプリカによってチェンジリストのサマリーが検証され、チェンジリストが一致しない場合でも、整合性ログへの書き込みが実行されます。

rpl.checksum.tableの有効な設定値を以下に示します。

rpl.checksum.table

実行されるテーブル検証処理のレベル

0

テーブルレベルでのチェックサムだけが実行されます。

1

テーブルのアンロードまたはスキャンを実行すると、ジャーナルノートが書き込まれます。これらのノートはレプリカによって処理され、検証処理が失敗した場合は、integrity.csvに記録されます。

2

テーブルのアンロードまたはスキャンを実行するとジャーナルノートが書き込まれ、ジャーナルノートの処理結果が一致する場合でも、その結果がログに記録されます。

詳細については、p4 help journaldbchecksumsを参照してください。

警告、注記、制限事項

以下に示す警告、注記、制限事項は、特に記載されていない限り、すべての構成に適用されます。

  • レプリカの稼働中は、以下のレプリカ設定をマスターサーバ上で再構成しないでください。

    • P4TARGET

    • dm.domain.accessupdate

    • dm.user.accessupdate

  • レプリカのデータベースに誤って書き込むことがないように注意してください。完全パスを指定せずに誤って現在のパスを指定して-rオプションを使用した場合や、P4ROOTのデータベースファイルを削除した場合などに、レプリカのデータベースへの誤った書き込みが発生する可能性があります。例えば、p4d -r . -jcコマンドを使用する場合は、p4 journalcopyコマンドによるジャーナルファイルの書き込みが実行されているレプリカサーバまたはスタンバイサーバのルートディレクトリで作業を行わないようにしてください。

  • Perforce password (P4PASSWD) invalid or unset」というエラーがいくつもレプリカログに記録されている場合は、サービスユーザにログインしていないか、P4TICKETSファイルが書き込み可能な状態になっていません。

    読み取り専用ディレクトリまたはP4TICKETSファイルの場合、p4 loginコマンドは正常に実行されますが、p4 login -sコマンドの場合は「無効または設定されていない」という内容のエラーが発生します。その場合は、P4TICKETSファイルが存在するかどうか、存在する場合はレプリカサーバによる書き込みが可能な状態になっているかどうかを確認してください。

  • マスターサーバ上のクライアントワークスペースとレプリカサーバ上のクライアントワークスペースを重複させることはできません。ユーザは、レプリカサーバのファイルとマスターサーバで使用されるクライアントワークスペースが同期されないように、P4PORTP4CLIENTなどの設定を構成する必要があります。

  • レプリカサーバでは、各レプリカのユーザのテーブルが個別に管理されます。デフォルトでは、p4 usersコマンドを実行すると、対象のレプリカサーバを使用しているユーザだけが表示されます(マスターサーバのユーザリストを表示するには、p4 users -cコマンドを使用します)。

    db.user.rpのレプリカ内に保存されている個別のユーザテーブルを使用する利点は、一度ログインすれば、その後はマスターサーバに繰り返しアクセスすることなく、レプリカを継続して使用できるという点です。

  • すべてのサーバIDに固有の値が設定されている必要があります。ビルドファームサーバを構成するのセクションに記載されている例では、手動で指定された覚えやすい名前を使用していますが、非常に大規模な環境では、ビルドファーム内に覚えきれないほどの数のサーバが配置されることがあります。数値のサーバIDを持つ新しいサーバ仕様を作成するには、p4 server -gコマンドを使用します。数値のサーバIDの場合、必ず固有のIDになります。

    IDを手動で指定するか自動的に生成するかにかかわらず、システム管理者は、サーバのp4 serverフォームに関連するサーバIDが、p4 serveridコマンドで作成された(または読み込まれた)server.idファイルと正確に一致していることを確認する必要があります。

  • P4Vと転送レプリカを使用している場合は、P4V 2012.1以降にアップグレードすることをお勧めします。転送レプリカを使用する2012.1よりも前のバージョンのPerforceアプリケーションでは、特定の条件において、2つのチケットを取得するために2回ログインしなければならないことがあります。1つは初回読み込み用のチケットで(転送レプリカからの読み込み)、もう1つは初回書き込み用の個別のチケットです(マスターに転送)。P4V 2012.1以降を使用すると、この複雑な動作が解消されます。

  • リリース2013.1の時点では、複数のレプリカを連携させることができますが(レプリカのP4TARGETは、別のレプリカにすることも、集中サーバから取得することもできます)、管理者は、複数のレプリカを連携させる際に、誤ってループが作成されないように注意する必要があります。複数レベルの複製を行うこともできますが、これは意味のない処理です。例えば読み取り専用レプリカの場合、転送されたすべての書き込み操作が拒否されるため、読み取り専用レプリカの転送レプリカを使用してもメリットはありません。複数レベルのレプリカのインストールを検討している場合は、Perforceのテクニカルサポートまでお問い合わせください。

  • 構成可能変数のrpl.compressは、マスターとレプリカ間の接続で圧縮機能を使用するかどうかを制御します。この構成可能変数のデフォルト値はゼロ(0)です。圧縮機能を有効にすると、パフォーマンスが大幅に改善される場合があります。特に、マスターサーバとレプリカサーバが地理的に非常に離れた場所にある場合に、パフォーマンスが大幅に改善されます。

    圧縮機能を有効にするには、p4 configure set fwd-replica#rpl.compress=1コマンドを使用します。