Helixプロキシ
このトピックは、「展開アーキテクチャ」の内容を理解していることを前提としています。
複数のHelixサーバユーザがWANを通じて共有Helixサーバリポジトリにアクセスする際のパフォーマンスを向上するには、以下を実行します。
- ユーザに近い側のネットワークにP4Pを設定します。
- ユーザがP4Pを経由してサービスにアクセスするように設定します。
- P4PがマスターのPerforceサービスにアクセスするように構成します。
動作環境
Helixプロキシを使用するには、以下のものが必要です。
- リリース2002.2以降のHelixサーバ (SSLを使用するには2012.1以降)
- ファイルリビジョンのキャッシュを保持するために十分なプロキシホストのディスク容量
P4Pをインストールする
次に記載する基本的な手順に加えて、以下も参照してください。
UNIX
UNIXまたはLinuxにP4Pをインストールするには、以下のことを行います。
- プロキシを実行するマシン上に、
p4p実行ファイルをダウンロードします。 - このマシン(
P4PCACHE)上で、ファイルリビジョンをキャッシュするディレクトリを選択します。 p4pがHelixサーバアプリケーションからのリクエストを待機するポート(P4PORT)を選択します。- プロキシがキャッシュするターゲットHelixサーバ (
P4TARGET)を選択します。
Windows
Windows用のHelix Coreサーバインストーラを実行する場合は、P4Pをオプションとしてインストールします。
P4Pを実行する
Helixプロキシを実行するには、p4p実行ファイルを起動し、環境変数やコマンドラインオプションを設定します。 コマンドラインで指定したオプションは、環境変数設定をオーバーライドします。
例えば、以下のコマンドラインを実行すると、centralという名前のホストにありポート1666を待機している集中Helixサーバと通信するプロキシが起動します。
$ p4p -p tcp64:[::]:1999 -t central:1666 -r /var/proxyroot
プロキシを使用するため、Helixサーバアプリケーションは、プロキシが実行しているマシンのポート1999でP4Pに接続します。 プロキシはIPv6およびIPv4の両方のトランスポートを接続待機します。 P4Pファイルリビジョンは、/var/proxyrootという名前のディレクトリに保存されます。
P4Pは、IPv4に加えてIPv6ネットワークでの接続もサポートしています。 詳細については、『Helix Core P4コマンドリファレンス』の「P4PORT」を参照してください。
P4PをWindowsサービスとして実行する
P4PをWindowsサービスとして実行するには、WindowsインストーラからP4Pをインストールするか、p4p.exeの実行時に-sオプションを指定するか、P4P実行ファイルの名前をp4ps.exeに変更します。
P4プロキシサービスへパラメータを渡すには、P4POPTIONSレジストリ変数をp4
setコマンドを使用して設定します。 例えば、通常、以下のコマンドを使ってプロキシを実行するとします。
C:\> p4p -p 1999 -t ssl:mainserver:1666
コマンドでプロキシを実行するのであれば、Helixプロキシという名前のWindowsサービスで次のようにサービスパラメータを設定することでP4POPTIONS変数を設定できます。
C:\> p4 set -S "Perforce Proxy" P4POPTIONS="-p 1999 -t ssl:mainserver:1666"
"Helixプロキシ"サーバが起動すると、P4Pはポート1999でプレーンテキスト接続を待機し、ssl:mainserver:1666でHelix CoreサーバとSSL経由で通信します。
P4Pオプション
次のプロキシ固有のコマンドラインオプションがサポートされています。
プロキシオプション
| オプション | 意味 |
|---|---|
|
|
デーモンとして実行 - フォークしてから、実行します(UNIXのみ)。 |
|
|
フォークなし - シングルスレッドサーバとして実行します(UNIXのみ)。 |
|
|
|
|
|
起動メッセージを表示せずに実行します。 |
|
|
HelixサーバとP4Pとの間のデータストリームを圧縮しません。 (このオプションを選択すると、わずかに使用帯域幅を増加させる代わりに、集中サーバのCPU負荷を削減します。) |
|
|
Windowsサービスとして実行(Windowsのみ)。
|
|
|
キャッシュ障害調整を無効にします。 プロキシは、現在の同期処理を表す
|
全般オプション
| オプション | 意味 |
|---|---|
|
|
ヘルプメッセージを表示します。 |
|
|
Helixプロキシのバージョンを表示します。 |
|
|
リビジョンがキャッシュされるディレクトリを指定します。 デフォルトは |
|
|
ログファイルの場所を指定します。 デフォルトは |
|
|
P4PがHelixサーバアプリケーションからのリクエストを待機するポートを指定します。 デフォルトは |
|
|
ターゲットHelixサーバ(すなわち、P4Pがプロキシとして動作するHelixサーバ)のポートを指定します。 デフォルトは |
|
|
|
|
|
プロキシサーバの場合、集中サーバとの通信時に指定された |
|
|
サーバのトレースレベルを指定します。 デバッグメッセージはプロキシサーバのログファイルに保存されます。 |
証明書処理オプション
| オプション | 意味 |
|---|---|
|
-Gc |
プロキシのSSL資格情報ファイルを生成します。プライベートキー(
|
|
-Gf |
プロキシのパブリックキーのフィンガープリントを表示して、終了します。 管理者はこのフィンガープリントをエンドユーザに伝え、ユーザは |
プロキシ監視オプション
| オプション | 意味 |
|---|---|
|
|
作業中のアーカイブ転送を一覧表示します。 |
|
|
作業中のアーカイブ転送の概要を一覧表示します。 |
|
|
ファイルステータスの間隔を秒単位で設定します。 |
|
|
0: (デフォルト)監視機能を無効にします。 1: プロキシはファイル転送のみを監視します。 2: プロキシはすべての処理を監視します。 3: プロキシはすべての処理の全トラフィックを監視します。 |
|
|
プロキシ管理の間隔を秒単位で設定します。 未設定の場合のデフォルトは10秒間です。 |
|
|
現在アクティブである接続と、それらのステータスを表示します。 1に等しいか、1より大きい |
プロキシのアーカイブキャッシュオプション
『Helix Core P4コマンドリファレンス』のlbr.proxy.case構成可能変数の説明を参照してください。
P4Pを管理する
以下のセクションではプロキシの管理に関するタスクを説明しています。
バックアップは不要
P4Pのキャッシュディレクトリをバックアップする必要は一切ありません。
必要に応じて、P4PはHelixサーバのメタデータに基づいてキャッシュを再構築します。
P4Pを終了する
P4Pは実質的にステートレスです。UNIX環境下でP4Pを停止するには、p4pプロセスをSIGTERMまたはSIGKILLを使用してkillします。 Windows環境下では、［タスクマネージャ］から［プロセスの終了］を選択します。
P4Pをアップグレードする
p4p実行ファイルをアップグレードバージョンで置き換えたあと、アップグレードしたプロキシを起動する前に、(存在する場合)pdb.lbrファイルおよびpdb.monitorファイルをプロキシルートから削除する必要があります。
SSLのサポートを有効にする
Helixプロキシとエンドユーザとの間の接続を暗号化するには、プロキシのP4SSLDIR環境変数で指定されるディレクトリに、有効なプライベートキーと証明書のペアが存在する必要があります。 プロキシに対する証明書とキーの生成と管理は、Helix Coreサーバに対するものと同様に行われます。 詳細については、「SSLを使用してHelixサーバへの接続を暗号化する」を参照してください。 ユーザのHelixサーバアプリケーションは、プロキシのフィンガープリントを信頼するように設定されていなければなりません。
HelixプロキシとアップストリームPerforceサービスとの間の接続を暗号化するには、プロキシのインストールをアップストリームのPerforceサービスのフィンガープリントを信頼するように設定しておく必要があります。 そのため、p4pコマンドを実行するユーザ(通常はサービスユーザ)は、p4
trustコマンドを使用して、アップストリームPerforceサービスのフィンガープリントを認識するP4TRUSTファイルを作成する必要があります。
サポートナレッジベースの記事「サーバ/ブローカ/プロキシのSSLサポートを有効にする」を参照してください。
中間者攻撃から身を守る
net.mimcheck構成可能変数を使用することで、起こり得るデータの傍受または改変のチェックを有効にすることができます。 これらの設定はプロキシ管理と関連します。
- 値が3の場合、クライアント、プロキシ、およびブローカからの接続について、TCPフォワードの実行がチェックされます。
- 値が5の場合、プロキシ、ブローカ、およびすべてのHelixサーバ中間サーバに、有効なログイン済みサービスユーザが関連付けられている必要があります。 これにより、管理者は不正なプロキシやサービスの使用を防ぐことができます。
この構成可能変数の値の変更を行った後は、サーバを再起動する必要があります。 詳細については、「net.mimcheck」を参照してください。
P4Pをローカライズする
Helixサーバのエラーメッセージがローカライズされている場合(「サーバエラーメッセージをローカライズする」を参照)、プロキシをシャットダウンしてサーバのdb.messageファイルをプロキシルートにコピーし、プロキシを再起動することにより、プロキシのエラーメッセージがローカライズされます。
ディスク容量の消費を管理する
P4Pは、ファイルリビジョンをキャッシュディレクトリにキャッシュします。 これらのリビジョンは、削除するまで蓄積されます。 P4Pがキャッシュファイルを削除したり、別の方法でディスク容量の消費を管理したりすることはありません。
キャッシュファイルを削除しないと、最終的にはディスク容量が足りなくなります。 ディスクの空きを作るには、プロキシのルート配下にあるファイルを削除します。
キャッシュファイルまたはpdb.lbrファイルを削除するためにプロキシを停止する必要はありません。
プロキシを停止せずにキャッシュからファイルを削除する場合は、プロキシのルートディレクトリのpdb.lbrファイルも削除する必要があります。 (プロキシは、pdb.lbrファイルを使用してどのファイルに対して転送が予定されているかを追跡しています。これにより、複数ユーザが同時に同じファイルを要求した場合にも、ファイルの1つのコピーのみが転送されます。
Helixサーバアプリケーションがプロキシを使用しているかどうかを判断する
Helixサーバアプリケーションがプロキシを使用している場合、p4 infoの出力にプロキシのバージョン情報が表示されます。
例えば、Perforceサービスがssl:central:1666にホストされていて、Helixサーバアプリケーションをoutpost:1999にホストされているHelixプロキシに移送する場合、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とプロテクション
プロキシとブローカでプロテクションを設定する方法については、『p4 protectによるプロテクションを設定する』の「プロキシとプロテクション」を参照してください。
特定のファイルがプロキシから提供されたのかどうかを判断する
-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に変更を加えたら、プロキシを再起動する前にキャッシュをクリアする必要があります。
最大限にパフォーマンスを改善する
この章のトピックに加えて、サポートナレッジベースの記事「プロキシのパフォーマンス」で調整に関するヒントと小規模ファイルの同期を最小化する方法について参照してください。
ファイル圧縮を無効にして、サーバCPUの使用を削減する
デフォルトでは、P4PはP4PとHelixサーババージョン管理サービスとの間の通信を圧縮するため、サービスに追加のオーバーヘッドが生じます。 圧縮を無効にするには、-cオプションを指定してp4pを実行します。 このオプションは、ネットワークおよびディスクの使用量が過剰であり、多数のバイナリファイルのリビジョンをディポに格納している場合に特に効果的です。なぜなら、(アップストリームバージョン管理サービスではなく)プロキシが、キャッシュからバイナリファイルを解凍してからHelixサーバユーザに送信するからです。
ネットワーク形態とP4P
Perforceサービスを含むサブネット上の帯域幅がほぼ飽和状態にある場合、ルータをまたいだ反対側のサブネット上にプロキシを展開すれば、エンドユーザからプロキシへのトラフィックは、Perforceサービスを含むサブネットとは別のサブネット上に切り離されます。 サブネットを複数のサブネットに分割し、そのそれぞれにプロキシを展開できます。
キャッシュディレクトリを事前取得して初期パフォーマンスを最適化する
Helixプロキシがファイルリビジョンを保存するのは、ユーザの1人が新規リビジョンをディポに送信したとき、またはユーザの1人がディポから既存のリビジョンを要求したときのみです。 つまり、ファイルリビジョンを事前取得しているわけではありません。 P4Pによってパフォーマンスが改善できるのは、ファイルリビジョンがキャッシュされた後に限ります。
P4Pを起動した後、専用のクライアントワークスペースを作成して最新リビジョンに同期することによってキャッシュディレクトリを事前取得することができます。 続いてプロキシに接続したすべてのユーザは、直ちにP4Pによるパフォーマンス改善を享受することができます。 例えば、北米のHelixサーバをターゲットとしているP4Pサーバを持つアジアの開発サイトでは、Helixサーバディポ全体に対してp4 sync
デフォルトでは、p4 syncはクライアントワークスペースにファイルを書き出します。 しかし、プロキシ用にファイルを事前取得するために専用のクライアントワークスペースが用意されている場合、この手順は余計です。 また、マシンの入出力のパフォーマンスがHelixプロキシを実行しているマシンのパフォーマンスよりも遅い場合には、この手順に多くの時間を要することがあります。
クライアントワークスペースにもファイルを書き出すという冗長手順を省いてプロキシのキャッシュを事前取得するには、同期時に-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である場合、それがサポートするHelixサーバに//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に保存されるということです。
