統合サービスの概要

Perforceの統合アーキテクチャの目的は、単純なタスクを簡単に実行できるようにし、複雑なタスクを実行可能な状態にすることです。最初はシンプルな環境から開始し、ビジネスニーズの変化に合わせて規模を拡大していくことができます。

この章では、各種のPerforceサーバを紹介し、これらのサーバを組み合わせて、操作性とパフォーマンスに関する問題を解決する方法について説明します。また、使用されている特定のタイプのサービスから独立したサービス統合に影響を与える問題と、ユーザ認証や統合サービス間の通信などに関する問題についても説明します。この章以降の各章では、各タイプのサービスについて詳しく説明します。

このガイドの内容を正しく理解するには、『Perforceサーバ管理者ガイド: 基本』の内容を理解している必要があります。

概要

『Perforceサーバ管理者ガイド: 基本』では、単一のPerforceサーバの作成、構成、保守を行う方法について説明しています。多くの場合、すべてのユーザがアクセスできるサーバが1台あれば、特に問題はありません。ただし、ビジネスの規模が拡大してシステムの使用範囲が広がると、サーバ側のインフラストラクチャを拡張しなければならない場合があります。その場合は、以下に示す3種類のPerforceサーバを使用します。

  • プロキシ

    リモートサイトに対する帯域幅が制限されている場合、Perforceプロキシを使用してPerforceクライアントとバージョニングサービス間を仲介することにより、パフォーマンスを改善することができます。転送されたファイルのリビジョンは、プロキシによって頻繁にキャッシュに格納されます。プロキシは、キャッシュに格納されたリビジョンに対する要求をインターセプトすることにより、サーバに対する負荷を減らし、ネットワークトラフィックの量を最小限に抑えます。

    プロキシのインストールと構成作業は簡単です。管理者がユーザ側のネットワーク上にプロキシを構成し、そのプロキシを経由してユーザがサービスにアクセスするように設定して、Perforceのバージョニングサービスにアクセスするようにプロキシを構成するだけです。プロキシのキャッシュディレクトリのバックアップを作成する必要はありません。障害が発生した場合、プロキシはPerforceサーバのメタデータに基づいてキャッシュを再作成します。プロキシの詳しい使用方法については、“Perforceプロキシ”を参照してください。

  • ブローカ

    Perforceブローカは、クライアントとサーバのプロセス(プロキシを含む)を仲介することにより、統合環境に各種ポリシーを実装します。これらのポリシーにより、特定のコマンドを特定のサーバに対して実行したり、実行可能なコマンドを制限したりすることができます。ブローカを使用して、1台以上のPerforceサーバに対する要求をソートすることにより、ロードバランシングやセキュリティなどに関する問題を解決することができます。

    ブローカのインストールと構成作業は簡単です。管理者がブローカを構成し、そのブローカを経由してユーザがPerforceサーバにアクセスするように設定するだけです。ブローカを構成するには、各ユーザが実行できるコマンドを指定するためのルールと、適切なPerforceサービスにコマンドをリダイレクトする方法が定義された構成ファイルを使用する必要があります。ブローカのバックアップを作成する必要はありません。障害が発生した場合は、ブローカを再起動し、構成ファイルが破損していないかどうかを確認するだけです。ブローカの詳しい使用方法については、“Perforceブローカ”を参照してください。

  • レプリカ

    レプリカは、サーバデータを複製します。これは、統合アーキテクチャにおける最も汎用的な要素の1つです。レプリカを使用してウォームスタンバイサーバを準備することにより、プライマリサーバの負荷とダウンタイムの削減、ビルドファームのサポート、中央サーバへの要求の転送を行うことができます。この転送レプリカと呼ばれる機能は、リモートアクセスの問題を解決してパフォーマンスを改善するコミットエッジアーキテクチャを使用して実装することができます。

    レプリカのインストール、構成、管理で必要になる作業量は、使用するレプリカのタイプによって異なります。異なるタイプのレプリカを処理する方法については、“Perforceの複製機能”を参照してください。コミットエッジの展開環境については、“コミットエッジアーキテクチャ”を参照してください。

管理作業を簡素化するため、上記の3種類のサーバのほかに、一元化された認証処理とチェンジリストの番号処理専用のサーバが統合アーキテクチャで使用される場合もあります。詳細については、集中認証サーバとチェンジリストサーバを構成するを参照してください。次のセクションでは、これらのタイプのサーバを組み合わせてさまざまなユーザのニーズを満たす方法について説明します。

ユーザのシナリオ

使用するサーバのタイプと、それらのサーバを組み合わせる方法は、ニーズに応じて異なります。ここでは、高可用性、地理的な分散、ビルドの自動化、スケーラビリティ、管理処理をサポートするためのサーバの選択方法について説明します。

可用性

ユーザによるPerforceサーバの使用頻度が高くなると、サーバのダウンタイムを最小限に抑える必要があります。追加のレプリカとブローカを展開してオンラインのチェックポイントを設定することにより、通常のバックアップ処理中も、ユーザはシステム上で継続して操作を実行できるようになります。また、この高度なインフラストラクチャでp4 verifyまたはp4 dbverifyを使用することにより、サーバのダウンタイムを発生させることなく、通常の保守作業を実行することができます。システムの定期的な保守作業やオペレーティングシステムのアップグレードの実行中に、特定のマシンに対する要求を別のマシンに送信することができます。

プライマリーサーバで障害が発生した場合、このサーバインフラストラクチャにより、ダウンタイムを最小限に抑えながら、スタンバイマシンにフェイルオーバーすることができます。バックアップサーバが別のマシンに展開されている場合は、このアーキテクチャを使用して障害回復を実行することもできます。フェイルオーバーと障害回復に最適なタイプのレプリカは、読み取り専用レプリカと転送レプリカです。

リモートオフィス

組織の規模が拡大し、ユーザがリモートオフィスに配置されるようになった場合、それらのリモートユーザがPerforceサーバにアクセスする際のパフォーマンスを最適化する必要があります。

地理的に分散した環境では、ネットワークの待機時間と帯域幅の制約に関する問題が、パフォーマンスを改善するための主要な課題になります。どちらの問題も、Perforceのプロキシとレプリカを使用して解決することができます。プロキシとレプリカは、リモートオフィスのファイルコンテンツとメタデータをキャッシュに格納し、可能な場合は常にローカルで要求を処理することにより、ネットワークトラフィックを削減します。最大98%のユーザ要求を、リモートオフィスのサーバで処理することができます。

また、ブローカを構成して、停電が発生した場合に要求の送信先を変更したり、海外のユーザによる営業時間外の要求を管理することもできます。

ビルド/テストの自動化

ビルドとテストの自動化の使用頻度が高まってくると、増加する作業負荷に対応可能なサーバアーキテクチャの展開が重要になってきます。自動化されたビルドツールとテストツールは、Perforceサーバのストレージサブシステムとネットワークサブシステムに対して大きな負荷を与える可能性があります。この負荷には、アジャイルプロセスと継続的な配信ワークフロー、複雑なクエリーを頻繁に実行するレポートツール、サーバデータとの緊密な統合を必要とするプロジェクト管理ツール、コード検索ツール、統計分析ツール、自動化されたブランチの統合とマージを実行するリリースエンジニアリングツールが含まれます。

ユーザエクスペリエンスを改善するには、この増加を続ける負荷を専用のレプリカサーバに移行してマスターサーバの負荷を減らすことにより、ユーザからの対話式の要求をマスターサーバで集中的に処理できるようにする必要があります。

スケーラビリティ

組織の規模が拡大すると、組織のニーズに合わせてインフラストラクチャも拡張する必要があります。

  • 先進的なソフトウェアエンジニアリングツールを使用した場合、サーバ側で追加のリソースを利用できるという利点があります。Perforceのプロキシ、レプリカ、ブローカを展開すると、ハードウェアリソースをさらに追加することができます。また、優先順位の低い処理を予備のマシンや使用率の低いマシンにリダイレクトし、最もパフォーマンスの高いインフラストラクチャを使用して最も重要な処理を実行することにより、要求の各クラスを適切にプロビジョニングされたサーバに送信できるようになります。

  • ユーザとオフィスの数が増えた場合に備え、追加の装置をプロビジョニングすることにより、あらかじめ計画を立てることができます。Perforceのプロキシ、レプリカ、ブローカを展開してシステムのキャパシティを拡張することにより、作業負荷を複数のマシンに分散し、ネットワークとストレージの使用負荷をプライマリのデータセンターから代替のデータセンターに移行し、作業負荷の自動処理をサポートすることができます。

ポリシーベースの管理

システムの規模が拡大し、使用環境が複雑になってきたら、各種のポリシーを作成して管理作業を効率化することをお勧めします。

たとえば、リポジトリの命名規則を使用すると、各種のリポジトリを適切に分類して簡単にアクセスできるようになります。また、変更確認プロセスやリリース配信プロセスなどのカスタムワークフローは、バージョン管理インフラストラクチャと緊密に統合すると、適切に管理できる場合があります。

統合展開環境でブローカを使用すると、要求のフィルタリング、ポリシーの適用、代替宛先へのコマンドの送信を行うことができます。これにより、組織内の各種ポリシーを適用するための強力なインフラストラクチャが実現します。サーバインスタンスでトリガスクリプトを展開すると、他のソフトウェア開発ツールやソフトウェア管理ツールとの追加の統合を行うことができます。

統合サービスを設定する

このセクションでは、統合環境を設定する際に管理者が解決する必要があるいくつかの問題について説明します。

一般的なガイドライン

以下のガイドラインに従うと、統合環境の管理と保守が容易になります。

  • すべてのサーバに、サーバIDを割り当ててください。サーバIDをサーバ名と同じにすることをお勧めします。ネットワーク内の各サーバを識別するには、p4 serverコマンドを使用します。

  • すべてのサーバに、サービスユーザ名(固有のものが望ましい)を割り当ててください。サービスユーザ名を割り当てると、ログを読むのが簡単になり、サーバ間通信用の認証と監査証跡が可能になります。サービスユーザには、強度の高いパスワードを割り当ててください。サービスユーザ名を割り当てるには、p4 serverコマンドを使用します。

  • すべてのサービスで構造化ロギングを有効にしてください。構造化ロギングを有効にすると、デバッグと分析処理が非常に簡単になります。また、p4 journaldbchecksumsコマンドを使用してレプリカの整合性を検証する場合も、構造化ロギングが必要になります。

  • 対象サービスの構成可能変数filesys.*.minに定義されている最小ディスクスペースを下回る操作を拒否するように各サーバを構成してください。

  • 構造化サーバログintegrity.csvとp4 journaldbchecksumsコマンドを使用して、レプリカの整合性を監視してください。詳細については、レプリカの整合性を検証するを参照してください。

ユーザを認証する

ユーザは、統合環境内でアクセスする各サーバのチケットを持っている必要があります。この要件を処理する最適な方法は、マスターに対してシングルログイン(シングルサインオン)を設定する方法です。これにより、すべてのレプリカインスタンスにログインできるようになります。これは、フェイルオーバー構成の場合に特に便利です。シングルログインが設定されていないと、フェイルオーバーが発生した場合に、新しいマスターサーバにログインし直す必要があります。

以下に示す2つの構成可能変数を使用して、シングルサインオン認証を設定することができます。

  • 分散構成環境内のすべてのサーバに対して、cluster.idを同じ値に設定します。

  • 分散構成環境内の各レプリカについて、rpl.forward.loginを有効にします(値を「1」に設定)。

各インスタンスでターゲットサーバからdb.userレコードが複製されるまで、多少時間がかかる場合があります。

サービスを接続する

統合環境内で相互に連携して機能しているサービスは、サービス間での相互認証を実行できる必要があります。

  • SSLを使用して、サーバ、ブローカ、プロキシの相互リンクを安全に行う場合、チェーン内の各リンクはアップストリームリンクを信頼する必要があります。

  • パスワードベースの認証ではなく、チケットベースの認証を使用することをお勧めします(セキュリティレベル4の場合は、必ずチケットベースの認証を使用する必要があります)。チケットベースの認証を使用するには、チェーン内の各サーバの各サービスユーザも、チェーン内のアップストリームリンクに対する有効なログインチケットを持っている必要があります。

サービス間の信頼を管理する

サーバプロセス、ブローカプロセス、プロキシプロセスを所有するユーザは、通常、サービスユーザになります。管理者は、アップストリームPerforceサービスのフィンガープリントを認識するp4 trustコマンドを使用して、サービスユーザの代わりにP4TRUSTファイルを作成する必要があります。

デフォルトでは、ユーザのP4TRUSTファイルは、そのユーザのホームディレクトリに.p4trustという名前で格納されています。P4TRUST変数が正しく設定されていることを確認してください。この変数により、各種の実行可能ファイル(p4d、p4p、またはp4broker)を実際に呼び出すユーザ(多くの場合、スクリプトまたは他の自動化ツール)の環境内で、P4TRUSTによって指定されたファイル名をそのユーザが読み取ることができるようになります。

詳細については、『Perforceサーバ管理者ガイド: 基本』を参照してください。

サービス間のチケットを管理する

サーバ、ブローカ、プロキシを相互にリンクする場合、各サービスユーザは、アップストリームリンクにおける有効なサービスユーザでなければなりません。また、有効なログインチケットを使用して認証を実行できる必要があります。サービス認証を設定するには、以下の手順を実行します。

  1. アップストリームサーバで、p4 userコマンドを使用してタイプがserviceのユーザを作成し、次にp4 groupコマンドを使用して、長いタイムアウト値またはunlimitedのタイムアウト値を持つグループにこのユーザを割り当てます。

    p4 passwdコマンドを使用して、上記のサービスユーザに強度の高いパスワードを割り当てます。

  2. ダウンストリームサーバで、p4 loginコマンドを使用して上記の新しいサービスユーザとしてマスターサーバにログインし、ダウンストリームサーバ上に存在するサービスユーザに対してログインチケットを作成します。

  3. ユーザ(多くの場合、スクリプトまたは他の自動化ツール)が実際にダウンストリームサービスを呼び出す際に、P4TICKET変数が正しく設定されていることを確認します。この変数により、ダウンストリームサービスでチケットファイルを正しく読み取り、アップストリームサービスに対してそのダウンストリームサービス自体をサービスユーザとして認証できるようになります。

SSLキーペアを管理する

SSL接続を許可するように構成されている場合、すべてのサーバプロセス(p4d、p4p、p4broker)の起動時に、有効な証明書とキーペアが必要になります。

キーペアを作成するプロセスは、他のサーバでのプロセスと同じです。P4SSLDIRの値を、適切な権限を持つ有効なディレクトリに設定し、以下のいずれかのコマンドを使用してprivatekey.txtファイルとcertificate.txtファイルのペアを作成し、キーのフィンガープリントのレコードを作成します。

  • サーバの場合: p4d -Gcコマンドを使用してキーと証明書のペアを作成し、p4d -Gfコマンドを使用して、このペアのフィンガープリントを表示します。

  • ブローカの場合: p4broker -Gcコマンドを使用してキーと証明書のペアを作成し、p4broker -Gfコマンドを使用して、このペアのフィンガープリントを表示します。

  • プロキシの場合: p4p -Gcコマンドを使用してキーと証明書のペアを作成し、p4p -Gfコマンドを使用して、このペアのフィンガープリントを表示します。

独自のプライベートキーと証明書を指定することもできます。詳細については、『Perforceサーバ管理者ガイド: 基本』を参照してください。

サービスのバックアップとアップグレードを実行する

統合環境でサービスのバックアップとアップグレードを実行する場合、特別な考慮事項があります。このセクションでは、統合環境で解決する必要がある問題について説明します。

サービスのバックアップを実行する

統合サービスのバックアップ方法は、サービスタイプによって異なります。

  • サーバの場合

    『Perforceサーバ管理者ガイド: 基本』に記載されているバックアップの手順を実行します。エッジコミットアーキテクチャを使用している場合、コミットサーバとエッジサーバの両方をバックアップする必要があります。バックアップと高可用性/障害回復(HA/DR)計画に記載されている手順を実行してください。

    エッジサーバ以外のレプリカのバックアップ要件は、サイトの要件によって異なります。

  • ブローカの場合: ブローカは、データをローカルに保存することはありません。そのため、ブローカの構成ファイルを手動でバックアップする必要があります。

  • プロキシの場合: プロキシは、バックアップを必要としません。また、見つからないファイルがある場合は、そのファイルのデータのキャッシュが自動的に再作成されます。プロキシには、ディスクスペースが少なくなっていることを検出するロジックは組み込まれていません。定期的にプロキシを監視して、操作を継続するための十分なディスクスペースがあるかどうかを確認するようにしてください。

サービスをアップグレードする

統合環境内では、サーバ、ブローカ、プロキシのリリースレベルがすべて一致している必要があります。アップグレードは、以下の手順で実行します。

  1. 最上位のアップストリームサービスまたはコミットサーバをシャットダウンし、システムを停止します。

  2. 最初にダウンストリームサービスをアップグレードします。その際、最下位のダウンストリームのレプリカから開始し、次にアップストリームのマスターサーバまたはコミットサーバに向かって順にアップグレードしていきます。

  3. 直近のアップストリームサービスのアップグレードが完了するまで、ダウンストリームサービスは停止したままにします。

集中認証サーバとチェンジリストサーバを構成する

統合サービスを使用するのではなく、共有ユーザベースを持つ複数のサーバを使用したい場合があります。その際、専用のサーバを使用してユーザ認証を簡素化し、チェンジリストの番号が組織全体で固有の番号になるようにしたい場合があります。以下のサブセクションでは、こうした専用サーバを作成する方法について説明します。集中認証サーバを作成する場合はP4AUTHを使用し、固有のチェンジリスト番号を生成する場合はP4CHANGEを使用します。

集中認証サーバ(P4AUTH)

複数のPerforceサーバが稼働している場合は、集中認証サーバからプロテクションとライセンスのデータを取得するようにPerforceサーバを構成することができます。集中サーバを使用すると、すべてのサーバ上に同じユーザエントリとプロテクションエントリが存在するかどうかを確認する必要がなくなります。

Note

集中認証サーバを使用する場合は、すべての外側のサーバのリリースレベルが集中サーバのリリースレベルと一致しているか、それよりも新しいレベルになっている必要があります。

集中認証サーバ上に存在しないユーザは、外側のサーバにも存在しないユーザとして表示されます。集中認証サーバと外側のサーバの両方に存在するユーザには、プロテクションテーブル内の最も制限の緩い2行が割り当てられます。

組織内の任意のPerforceサーバを、集中認証サーバとして使用することができます。集中認証サーバのライセンスファイルにより、外側のサーバ上での存在が許可されるライセンス済みユーザの数が管理されるため、正しいライセンスファイルを使用する必要があります。集中認証サーバを使用するようにPerforceサーバを構成するには、サーバを起動する前にP4AUTHを設定するか、サーバの起動時にコマンドラインでP4AUTHを指定します。

Perforceサーバで集中認証サーバを使用している場合は、p4 infoコマンドの出力情報に以下の行が表示されます。 

...
Authorization Server: [protocol:]host:port

[protocol:]host:portの部分は、集中認証サーバのプロトコル、ホスト、ポート番号です。詳細については、ホストを指定するを参照してください。

以下の例では、外側のサーバ(server2とする)が集中認証サーバ(centralとする)を使用するように構成されています。この外側のサーバは、ポート1999でユーザからの要求を待機し、ユーザ、グループ、プロテクション、レビュー、ライセンスの情報については、集中サーバのデータを使用します。また、この外側のサーバは、サーバから取得したプロテクションテーブルを、central:1666で独自のプロテクションテーブルに結合します。

例:

p4d -In server2 -a central:1666 -p 1999

Windows

Windowsでは、p4 set -Sコマンドを使用して、以下のように外側のサーバを構成します。 

p4 set -S "Outer Server" P4NAME=server2
p4 set -S "Outer Server" P4AUTH=central:1666
p4 set -S "Outer Server" P4PORT=1999

集中認証サーバを構成すると、外側のサーバは、以下の各コマンドを集中サーバに処理用として転送します。

コマンド

認証サーバに転送?

注記

p4 group

はい

ローカルのグループデータは、集中サーバから派生します。

p4 groups

はい

ローカルのグループデータは、集中サーバから派生します。

p4 license

はい

ライセンスの制限は、集中サーバから派生します。ライセンスのアップデートは、集中サーバに転送されます。

p4 passwd

はい

パスワード設定は、集中サーバに格納され、集中サーバのセキュリティレベルの要件を満たしている必要があります。

p4 review

いいえ

サービスユーザ(またはremote)は、集中サーバに対するアクセス権を持っている必要があります。

p4 reviews

いいえ

サービスユーザ(またはremote)は、集中サーバに対するアクセス権を持っている必要があります。

p4 user

はい

ローカルユーザのデータは、集中サーバから派生します。

p4 users

はい

ローカルユーザのデータは、集中サーバから派生します。

p4 protect

いいえ

ユーザによるローカルサーバのプロテクションテーブルの編集が許可されている場合(結合されたプロテクションテーブルとして定義されている場合)、そのプロテクションテーブルが表示されます。

p4 protects

はい

プロテクションは、外側のサーバのプロテクションテーブルに付加された集中サーバのプロテクションテーブルから派生します。

p4 login

はい

チケットを生成するため、コマンドが集中サーバに転送されます。

p4 logout

はい

チケットを無効にするため、コマンドが集中サーバに転送されます。

制限事項と注記

  • P4AUTHを使用するすべてのサーバは、集中認証サーバと同じユニコード設定を使用する必要があります。

  • p4 configure set P4AUTH=[protocol:server:portコマンドを使用してP4AUTHを設定するには、外側のサーバを再起動する必要があります。

  • p4 reviewコマンドとp4 reviewsコマンドを正常に機能させるには、集中サーバ上でサービスユーザ(サービスユーザが指定されていない場合は、remoteという名前のユーザ)によるリモートディポへのアクセスを有効にする必要があります。

  • 転送されたコマンドと、信頼されている直接接続ユーザによって発行されたコマンドを認証サーバで正しく区別するには、proxy-という文字列を[protocol:host定義の先頭に付加することにより、PerforceサービスでIPベースのプロテクションエントリを定義する必要があります。

  • 転送されないコマンドのプロテクションは、外側のサーバによって適用されます。集中サーバのプロテクションテーブル内の行からプロテクションが派生している場合であっても、クライアントのプレーンIPアドレスを使用する必要があります。

チェンジリストサーバ(P4CHANGE)

デフォルトでは、Perforceサーバがチェンジリストの番号付けを調整することはありません。各Perforceサーバは、サーバ上のチェンジリストの番号付けを独自に行います。複数のサーバが稼働している場合は、チェンジリスト番号の取得元となる集中チェンジリストサーバを参照するように各サーバを構成することができます。このように構成することにより、どのサーバにチェンジリスト番号を送信するかにかかわらず、組織全体でチェンジリスト番号が固有の番号になります。

Note

チェンジリストサーバを使用する場合は、すべての外側のサーバのリリースレベルが集中サーバのリリースレベルと一致しているか、それよりも新しいレベルになっている必要があります。

チェンジリストサーバを使用するようにPerforceサーバを構成するには、2番目のサーバを起動する前にP4CHANGEを設定するか、p4dコマンドラインで-gオプションとともにP4CHANGEを指定します。

p4d -In server2 -g central:1666 -p 1999

Windows

Windowsでは、p4 set -Sコマンドを使用して、以下のように外側のサーバを構成します。 

p4 set -S "Outer Server" P4NAME=server2
p4 set -S "Outer Server" P4CHANGE=central:1666
p4 set -S "Outer Server" P4PORT=1999

この例では、外側のサーバ(server2とする)がチェンジリストサーバー(centralとする)を使用するように構成されています。外側のサーバのユーザがチェンジリスト番号を割り当てる必要がある場合(ユーザが作業中チェンジリストの作成や送信を行う場合)は常に、使用可能な次のチェンジリスト番号が代わりに使用されます。

チェンジリストサーバを参照するサーバの数に制限はありません。この構成は、p4 changesコマンドの出力には影響しません。p4 changesコマンドを実行すると、現在接続されているサーバ上のチェンジリストだけが表示されます。そのサーバが独自のチェンジリスト番号を生成しているのか、あるいは集中サーバのデータを使用して生成しているのかは関係ありません。

Perforceサーバでチェンジリストサーバを使用している場合は、p4 infoコマンドの出力情報に以下の行が表示されます。 

...
Changelist Server: [protocol:]host:port

[protocol:]host:portの部分は、チェンジリストサーバのプロトコル、ホスト、ポート番号です。