Perforceプロキシ
Perforceは、多様なネットワーク形態において分散開発を扱えるようになっています。リモートサイトへの帯域幅が限られている場合、P4P(Perforceプロキシ)は頻繁に転送されるファイルリビジョンをキャッシュすることによってPerforceアプリケーションとバージョニングサービスとの間を調整し、パフォーマンスを改善します。キャッシュされたファイルリビジョンに対する要求をインターセプトすることで、P4PはPerforceサービスおよびそれが動作するネットワークへの要求を減らします。
複数のPerforceユーザが、WANを通じて共有のPerforceリポジトリへアクセスする際のパフォーマンスを改善するためには、ユーザに近い側のネットワークにP4Pを構成し、ユーザがそのP4Pを経由してサービスにアクセスするように構成し、さらにP4PがマスターのPerforceサービスへアクセスするように構成します。(LANでは、マスターサーバのCPUおよびディスクから負荷を分散させるようプロキシを設定することにより、パフォーマンスを改善することができます。)
次の図は、典型的なP4Pの構成を示します。
この構成で、リモート開発サイトにいるユーザから要求されたファイルリビジョンは、まず集中Perforceサーバ(centralで実行中のp4d)から取得され、次に比較的低速のWANを通じて転送されます。ただし、同じリビジョンに対する以降のリクエストは、Perforceプロキシ(outpostで実行中のp4p)から提供されます。リモート開発サイトのLANを通じて提供されるため、WANのネットワークトラフィックおよび集中サーバのCPUの負荷を削減できます。
動作環境
Perforceプロキシを使用するには、以下のものが必要です。
-
リリース2002.2以降のPerforceサーバ(SSLを使用する場合は2012.1以降)
-
ファイルリビジョンのキャッシュを保持するために十分なプロキシホストのディスク容量
P4Pをインストールする
UNIX
UNIXまたはLinuxにP4Pをインストールするには、以下のことを行います。
-
プロキシを実行するマシン上に、p4p実行ファイルをダウンロードします。
-
このマシン(
P4PCACHE)上で、ファイルリビジョンをキャッシュするディレクトリを選択します。 -
p4pがPerforceアプリケーションからのリクエストを待機するポート(
P4PORT)を選択します。 -
プロキシがキャッシュするターゲットPerforceサーバ(
P4TARGET)を選択します。
Windows
Windowsインストーラのカスタム/管理者インストールダイアログからP4Pをインストールします。
P4Pを実行する
P4Pを実行するには、p4p実行ファイルを起動し、環境変数やコマンドラインオプションを構成します。コマンドラインで指定したオプションは、環境変数設定をオーバーライドします。
例えば、以下のコマンドラインを実行すると、centralという名前のホストにありポート1666を待機している集中Perforceサーバと通信するプロキシが起動します。
p4p -p tcp64:[::]:1999 -t central:1666 -r /var/proxyroot
プロキシを使用するには、Perforceアプリケーションは、プロキシが実行しているマシンのポート1999でP4Pに接続します。プロキシはIPV6およびIPV4の両方のトランスポートを接続待機します。P4Pファイルリビジョンは、/var/proxyrootという名前のディレクトリに保存されます。
Perforceプロキシは、IPv4に加えてIPv6ネットワークでの接続もサポートしています。詳細については、『Perforceサーバ管理者ガイド: 基本』を参照してください。
P4PをWindowsサービスとして実行する
P4PをWindowsサービスとして実行するには、WindowsインストーラからP4Pをインストールするか、p4p.exeの実行時に-sオプションを指定するか、P4P実行ファイルの名前をp4ps.exeに変更します。
P4プロキシサービスへパラメータを渡すには、P4POPTIONSレジストリ変数をp4
setコマンドを使用して設定します。例えば、通常は
p4p -p 1999 -t ssl:mainserver:1666
コマンドでプロキシを実行するのであれば、Perforce Proxyという名前のWindowsサービスで次のようにサービスパラメータを設定することでP4POPTIONS変数を設定できます。
p4 set -S "Perforce Proxy" P4POPTIONS="-p 1999 -t ssl:mainserver:1666"
"Perforce Proxy"サーバが起動すると、P4Pはポート1999でプレーンテキスト接続を待機し、ssl:mainserver:1666でPerforceサーバとのSSL経由の通信を待機します。
P4Pオプション
次のプロキシ固有のコマンドラインオプションがサポートされています。
プロキシオプション:
|
オプション |
意味 |
|---|---|
|
|
デーモンとして実行 - フォークしてから、実行します(UNIXのみ)。 |
|
|
フォークなし - シングルスレッドサーバとして実行します(UNIXのみ)。 |
|
|
inetdに対して実行します( |
|
|
起動メッセージを表示せずに実行します。 |
|
|
PerforceサーバとP4Pとの間のデータストリームを圧縮しません。(このオプションを選択すると、わずかに使用帯域幅を増加させる代わりに、集中サーバのCPU負荷を削減します。) |
|
|
Windowsサービスとして実行(Windowsのみ)。 p4p.exe -sを実行することは、p4ps.exeを起動することと同等です。 |
|
|
キャッシュ障害調整を無効にします。
プロキシは、現在の同期処理を表す
|
全般オプション:
|
オプション |
意味 |
|---|---|
|
|
ヘルプメッセージを表示します。 |
|
|
Perforceプロキシのバージョンを表示します。 |
|
|
リビジョンがキャッシュされるディレクトリを指定します。デフォルトは |
|
|
ログファイルの場所を指定します。デフォルトは |
|
|
P4PがPerforceアプリケーションからのリクエストを待機するポートを指定します。デフォルトは |
|
|
ターゲットPerforceサーバ(すなわち、P4Pがプロキシとして動作するPerforceサーバ)のポートを指定します。デフォルトは |
|
|
|
|
|
プロキシサーバの場合、集中サーバとの通信時に指定された |
|
|
サーバのトレースレベルを指定します。デバッグメッセージはプロキシサーバのログファイルに保存されます。p4pからのデバッグメッセージはp4dに渡されず、p4dからのデバッグメッセージはp4pのインスタンスに渡されません。デフォルトは |
証明書処理オプション:
|
オプション |
意味 |
|---|---|
|
-Gc |
プロキシのSSL資格情報ファイルを生成します。プライベートキー(
|
|
-Gf |
プロキシのパブリックキーのフィンガープリントを表示して、終了します。 管理者はこのフィンガープリントをエンドユーザに伝え、ユーザはp4 trustコマンドを使用して(接続先のサーバの)フィンガープリントが正確かどうかを知ることができます。 |
プロキシ監視オプション:
|
オプション |
意味 |
|---|---|
|
|
作業中のアーカイブ転送を一覧表示します。 |
|
|
作業中のアーカイブ転送の概要を一覧表示します。 |
|
|
ファイルステータスの間隔を秒単位で設定します。未設定の場合のデフォルトは10秒間です。 |
|
|
|
|
|
プロキシ管理の間隔を秒単位で設定します。未設定の場合のデフォルトは10秒間です。 |
|
|
現在アクティブである接続と、それらのステータスを表示します。
1に等しいか、1より大きい |
プロキシのアーカイブキャッシュオプション:
|
オプション |
意味 |
|---|---|
|
|
|
P4Pを管理する
バックアップは不要
P4Pのキャッシュディレクトリをバックアップする必要は一切ありません。
もし必要ならば、P4PはPerforceサーバのメタデータに基づいてキャッシュを再構築します。
P4Pを終了する
P4Pは実質的にステートレスです。UNIX環境下でP4Pを停止するには、p4pプロセスをSIGTERMまたはSIGKILLを使用してkillします。Windows環境下では、からを選択します。
P4をアップグレードする
p4p実行ファイルをアップグレードバージョンで置き換えたあと、アップグレードしたプロキシを起動する前に、(存在する場合)pdb.lbrファイルおよびpdb.monitorファイルをプロキシルートから削除する必要があります。
SSLのサポートを有効にする
Perforceプロキシとエンドユーザとの間の接続を暗号化するには、プロキシのP4SSLDIR環境変数で指定されるディレクトリに、有効なプライベートキーと証明書のペアが存在する必要があります。プロキシに対する証明書とキーの生成と管理は、Perforceサーバに対するものと同様に行います。詳細については、SSLのサポートを有効にするを参照してください。ユーザのPerforceアプリケーションは、プロキシのフィンガープリントを信頼するように構成しておく必要があります。
PerforceプロキシとアップストリームPerforceサービスとの間の接続を暗号化するには、プロキシのインストールをアップストリームのPerforceサービスのフィンガープリントを信頼するように構成しておく必要があります。そのため、p4pコマンドを実行するユーザ(通常はサービスユーザ)は、p4 trustコマンドを使用して、アップストリームPerforceサーバのフィンガープリントを認識するP4TRUSTファイルを作成する必要があります。
P4Pをローカライズする
Perforceサーバにローカライズされたエラーメッセージが含まれている場合(『Perforceサーバ管理者ガイド: 基本』の「サーバエラーメッセージをローカライズする」を参照)、次のようにしてプロキシのエラーメッセージ出力をローカライズできます。まずプロキシをシャットダウンし、サーバのdb.messageファイルをプロキシルートにコピーしてから、プロキシを再起動します。
ディスク容量の消費を管理する
ファイルリビジョンは、キャッシュディレクトリにキャッシュされます。これらのリビジョンは、削除するまで蓄積されます。P4Pがキャッシュファイルを削除したり、別の方法でディスク容量の消費を管理したりすることはありません。
警告:
キャッシュファイルを削除しないと、最終的にはディスク容量が足りなくなります。ディスクの空きを作るには、プロキシのルート配下にあるファイルを削除します。
キャッシュファイルまたはpdb.lbrファイルを削除するためにプロキシを停止する必要はありません。
プロキシを停止せずにキャッシュからファイルを削除する場合は、プロキシのルートディレクトリのpdb.lbrファイルも削除する必要があります。(プロキシは、pdb.lbrファイルを使用してどのファイルに対して転送が予定されているかを追跡しています。これにより、複数ユーザが同時に同じファイルを要求した場合にも、ファイルの1つのコピーのみが転送されます。
Perforceアプリケーションがプロキシを使用しているかどうかを判断する
Perforceアプリケーションがプロキシを使用している場合、p4 infoの出力にプロキシのバージョン情報が表示されます。
例えば、Perforceサービスがssl:central:1666にホストされていて、Perforceアプリケーションをoutpost:1999にホストされているPerforceプロキシに移送する場合、p4
infoの出力は次のようなものになります。
$ export P4PORT=tcp:outpost:1999 $ p4 info User name: p4adm Client name: admin-temp Client host: remotesite22 Client root: /home/p4adm/tmp Current directory: /home/p4adm/tmp Client address: 192.168.0.123 Server address: central:1666 Server root: /usr/depot/p4d Server date: 2012/03/28 15:03:05 -0700 PDT Server uptime: 752:41:23 Server version: P4D/FREEBSD4/2012.1/406375 (2012/01/25) Server encryption: encrypted Proxy version: P4P/SOLARIS26/2012.1/406884 (2012/01/25) Server license: P4 Admin <p4adm> 20 users (expires 2013/01/01) Server license-ip: 10.0.0.2 Case handling: sensitive
P4Pとプロテクション
PerforceプロキシユーザのワークステーションのIPアドレスをプロテクションテーブルに適用するには、ワークステーションのIPアドレスの先頭にproxy-という文字列を追加します。
例えば、192.168.10.0/24というサブネット上のワークステーションでリモート開発を行っている組織を考えてみます。この組織には、ローカル開発を行っている中央オフィスもあり、この中央オフィスは10.0.0.0/8というサブネット上に存在しています。Perforceサービスは10.0.0.0/8のサブネット上に存在し、Perforceプロキシは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行目では、192.168.10.0/24のサブネット上のワークステーションからプロキシを使用せずPerforceにアクセスしようと試みた場合に、remotedevグループのすべてのユーザに対してlistアクセスが拒否されます。2行目では、IPV6のサブネット[2001:db8:16:81::]/48からアクセスしようとした場合に、1行目と同じ方法でアクセスが拒否されます。
3行目では、remotedevグループのユーザがPerforceプロキシサーバを使用してサブネット192.168.10.0/24から作業している場合に、このグループ内のすべてのユーザに対してwriteアクセスが許可されます。リモートサイトにあるワークステーションのユーザは、プロキシを使用しなければなりません。(プロキシサーバ自体がこのサブネット上に存在している必要はありません。例えば、192.168.20.0に存在していても構いません。)4行目では、IPV6 [2001:db8:16:81::]/48サブネットからアクセスが試みられた場合に、同様にアクセスが拒否されます。
同様に、5行目と6行目では、中央オフィスのサブネット(10.0.0.0/8と[2001:db8:1008::]/32)上のワークステーションからプロキシの使用を試みた場合、remotedevユーザに対してlistアクセスが拒否されます。7行目と8行目では、中央オフィスのサブネット上のワークステーションから直接Perforceサーバにアクセスするremotedevユーザに対して、書き込みアクセス権が許可されます。remotedevグループのユーザがローカルサイトにアクセスする場合は、Perforceサーバに直接アクセスする必要があります。
Perforceサービスがプロテクションテーブルのエントリを評価する際に、dm.proxy.protects構成も評価されます。
dm.proxy.protectsのデフォルト値は「1」ですが、この場合、各種の媒介(プロキシ、ブローカ、またはエッジサーバ)を経由して接続するすべてのクライアントホストのアドレスの先頭に、proxy-というプレフィックスが追加されます。このプレフィックスは、間接的な接続であることを示しています。
dm.proxy.protectsを0に設定すると、proxy-プレフィックスが削除され、プロテクションエントリを1セット書き込むことができます。これは、直接接続しているクライアントと媒介を経由して接続しているクライアントの両方に適用されます。これは便利ですが、媒介を経由して接続することに問題がある場合、安全性が低下します。この設定を使用する場合は、すべての媒介がリリース2012.1以降になっている必要があります。
特定のファイルがプロキシから提供されたのかどうかを判断する
-Zproxyverboseオプションを付けてp4を実行すると、ファイルリビジョンがプロキシ(p4p)から転送されるのか、集中サーバ(p4d)から転送されるのかを示すメッセージが表示されます。例:
$ p4 -Zproxyverbose sync noncached.txt //depot/main/noncached.txt - refreshing /home/p4adm/tmp/noncached.txt $ p4 -Zproxyverbose sync cached.txt //depot/main/cached.txt - refreshing /home/p4adm/tmp/cached.txt File /home/p4adm/tmp/cached.txt delivered from proxy server
大文字と小文字の区別の問題とプロキシ
大文字と小文字を区別するプラットフォーム(UNIXなど)上でプロキシを実行していて、ユーザが大文字と小文字を区別しないプラットフォーム(Windowsなど)からファイルを送信する場合、プロキシのデフォルトの動作では、大文字と小文字を区別しません。つまり、「FILE.TXT」が「File.txt」や「file.txt」を上書きする場合があります。
テキストファイルやソースコードの場合、この動作によるパフォーマンスへの影響は無視できるかもしれません。しかし、.ISO画像オブジェクトや.VOB動画オブジェクトなどの大きいバイナリを処理する場合、この動作に関連してパフォーマンスの問題が発生する可能性があります。
|
lbr.proxy.case |
動作 |
|---|---|
|
|
プロキシは大文字と小文字の区別を無視します。同じ名前を持つすべてのファイルは大文字と小文字の違いに関係なく、同じファイルとして扱われます。 |
|
|
プロキシは、アップストリームのサーバが大文字と小文字を区別しない(つまり、アップストリームのサーバがWindowsである)場合にのみ、その違いを無視します。 |
|
|
プロキシは大文字と小文字を常に区別します。 |
lbr.proxy.caseに変更を加えたら、プロキシを再起動する前にキャッシュをクリアする必要があります。
最大限にパフォーマンスを改善する
ファイル圧縮を無効にして、サーバCPUの使用を削減する
デフォルトでは、P4PはP4PとPerforceバージョニングサービスとの間の通信を圧縮するため、サービスに追加のオーバーヘッドが生じます。圧縮を無効にするには、-cオプションを指定してp4pを実行します。このオプションは、ネットワークおよびディスクの使用量が過剰であり、多数のバイナリファイルのリビジョンをディポに格納している場合に特に効果的です。なぜなら、(アップストリームバージョニングサービスではなく)プロキシが、キャッシュからバイナリファイルを解凍してからPerforceユーザに送信するからです。
ネットワーク形態とP4P
Perforceサービスと同じサブネット上にあるネットワークの帯域幅がほぼ飽和状態にあるとき、同じサブネット上にプロキシサーバを展開しても、パフォーマンスを改善することはできません。その代わり、ルータをまたいだ反対側のサブネット上にプロキシを展開すれば、エンドユーザからプロキシへのトラフィックは、Perforceサービスを含むサブネットから切り離された別のサブネット上に独立します。
例:
ネットワークの帯域幅がほぼ飽和状態にあるとき、そのサブネット上に追加のプロキシを展開しても、パフォーマンスの改善を改善することはできません。その代わり、サブネットを複数のサブネットに分割し、そのそれぞれにプロキシを展開します。
図示されている構成で、サーバルームには、会社のPerforceサービス(p4d)、ネットワークストレージデバイス(NAS)、データベースサーバ(RDBMS)が含まれています。営業担当者は常にデータベースにライブ更新のクエリを送信し、開発者やグラフィックアーティストはPerforceがバージョン管理している大きいファイルに頻繁にアクセスするため、サーバルームのネットワークは高い負荷にさらされ、飽和状態にあります。
2つのPerforceプロキシインスタンスを展開し、1つは開発者のサブネット、もう1つはグラフィックアーティストのサブネットに置くことにします。これにより、サーバルームのネットワークセグメントの使用率が下がり、3部門すべてにとってパフォーマンスが改善します。
キャッシュディレクトリを事前取得して初期パフォーマンスを最適化する
P4Pがファイルリビジョンを保存するのは、ユーザの1人が新規リビジョンをディポに送信したとき、またはユーザの1人がディポから既存のリビジョンを要求したときのみです。つまり、ファイルリビジョンを事前取得しているわけではありません。P4Pによってパフォーマンスが改善できるのは、ファイルリビジョンがキャッシュされた後に限ります。
P4Pを起動した後、専用のクライアントワークスペースを作成して最新リビジョンに同期することによって、効果的にキャッシュディレクトリを事前取得することができます。続いてプロキシに接続したすべてのユーザは、直ちにP4Pによるパフォーマンス改善を享受することができます。例えば、北米のPerforceサーバをターゲットとしているP4Pサーバを持つアジアの開発サイトでは、Perforceディポ全体に対してp4 syncを実行する自動ジョブを使用して、キャッシュディレクトリを事前に取得できます。北米サイトの開発作業が完了した頃から、開発者たちが出社するまでの間に行います。
デフォルトでは、p4 syncはクライアントワークスペースにファイルを書き出します。しかし、プロキシ用にファイルを事前取得するために専用のクライアントワークスペースが用意されている場合、この手順は余計です。また、マシンの入出力のパフォーマンスがPerforceプロキシの起動マシンのパフォーマンスよりも遅い場合には、この手順に多くの時間を要することがあります。
クライアントワークスペースにもファイルを書き出すという冗長手順を省いてプロキシのキャッシュを事前取得するには、同期時に-Zproxyloadオプションを使用します。例:
$ export P4CLIENT=prefetch $ p4 sync //depot/main/written.txt //depot/main/written.txt - refreshing /home/prefetch/main/written.txt $ p4 -Zproxyload sync //depot/main/nonwritten.txt //depot/main/nonwritten.txt - file(s) up-to-date.
両方のファイルがキャッシュされますが、nonwritten.txtがprefetchクライアントワークスペースに書き出されることはありません。ディポ全体を事前取得する上で、これによりかなりの時間を節約できます。
ディスク容量の消費を分散する
P4Pは、ディポツリーが1つのみであるかのようにリビジョンを保存します。もし、これにより1つのファイルシステムにあまりに多くのファイルが保存されるのであれば、シンボリックリンクを使ってリビジョンを複数のファイルシステムに分散させることもできます。
例えば、P4Pキャッシュルートが/disk1/proxyである場合、それがサポートするPerforceサーバに//depotと//releasedという名の2つのディポを存在させます。次のようにして//depotをdisk1に、//releasedをdisk2に保存することで、データを別々のディスクに分散させることができます。
mkdir /disk2/proxy/released cd /disk1/proxy ln -s /disk2/proxy/released released
シンボリックリンクが意味することは、P4Pが//releasedディポのファイルを/disk1/proxy/releasedにキャッシュしようとしている場合、そのファイルが/disk2/proxy/releasedに保存されるということです。