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

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

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コマンドを使用して、マスターサーバとレプリカサーバ両方の設定を制御することができます。

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

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

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

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

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

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

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 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を実行します。

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

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

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コマンドの違いを参照してください。

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だけです。

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

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

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

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

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

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

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

レプリカユーザのワークステーションの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以降になっている必要があります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

# 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

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

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

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

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

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

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

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

構造化サーバロギングを有効にしたら、構成可能変数rpl.checksum.auto、rpl.checksum.change、rpl.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.changeの有効な設定値を以下に示します。

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

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