コミットエッジアーキテクチャ

はじめに

コミットエッジアーキテクチャとは、特定の複製構成のことです。これは地理的に離れたワークグループに最適なソリューションで、パフォーマンスにおいて大きな利点があります。少なくとも、以下の種類のサーバで構成されます。

  • コミットサーバは、正規のアーカイブと永続的なメタデータを保存します。動作はPerforceマスターサーバに似ていますが、ワークスペース情報の一部が含まれていない場合があります。

  • エッジサーバは、コミットサーバのデータの複製コピーと、ワークスペースの固有のローカルコピー、進行中の作業情報を含みます。読み取り専用の処理や、ローカルデータに書き込むだけのp4 editのような処理を実行することができます。動作は転送レプリカに似ていますが、ローカルのワークスペースデータを含み、コミットサーバから独立してより多くの処理を扱うことができます。複数のエッジサーバをコミットサーバに接続することができます。

エッジサーバはほぼすべてのルーチン処理をローカルで扱うことができるため、エッジコミットアーキテクチャはコミットサーバの処理の負荷を大幅に低減し、コミットサーバとエッジサーバの間のデータ伝送量を削減します。これにより、パフォーマンスが大幅に改善します。

ユーザから見て、サブミット時点までの一般的な処理のほとんどはエッジサーバにより実行されます。転送レプリカの場合と同様に、ファイル一覧の取得やファイル履歴の表示などの読み取り処理は、ローカルで行われます。また、エッジサーバを使用すると、ファイルの同期、チェックアウト、マージ、衝突解決、変更の破棄もローカルで処理されます。

コミットエッジアーキテクチャは、Perforceの複製技術を基盤としています。コミットエッジ構成を展開する前に、“Perforceの複製機能”をお読みください。

エッジサーバは、ビルドファームサーバの代わりに使用することができます。この使い方は、ビルドエッジサーバと呼ばれます。ビルドプロセスがエッジサーバの唯一のユーザである場合、ローカルのエッジサーバ固有のワークスペースおよびそれに関連する情報をバックアップする必要がないため、バックアップ(障害回復)戦略を簡素化できます。詳しくは、既存のインストールから移行するを参照してください。

次の図は、コミットエッジ構成の一例を示します。1台のコミットサーバが2台のエッジサーバと通信し、エッジサーバはそれぞれ複数のワークスペースを扱っています。

コミットエッジ構成をセットアップする

このセクションでは、Linuxでコミットエッジ構成をセットアップする方法について説明します。コミットサーバに変換したい既存のサーバがあると仮定します。この例では、既存のサーバはシカゴにあり、東京のリモートサイトにエッジサーバをセットアップする必要があるとします。


  • コミットサーバ P4PORT=chicago.perforce.com:1666 P4ROOT=/chicago/p4root


  • エッジサーバ P4PORT=tokyo.perforce.com:1666 P4ROOT=/tokyo/p4root

次のセクションで詳細を示すセットアッププロセスは、以下の主要ステップからなっています。

  1. コミットサーバ上で、作成する各エッジサーバにサービスユーザアカウントを作成します。

  2. コミットサーバ上で、コミットサーバおよびエッジサーバの構成を作成します。

  3. コミットサーバを複製してエッジサーバを作成し、エッジサーバを起動します。

これらの手順を実行するには、super権限が必要です。

エッジサーバにサービスユーザアカウントを作成する

コミットサーバとエッジサーバとの間の通信を安全にするために、展開する予定の各エッジサーバにサービスタイプのユーザアカウントを作成する必要があります。また、各エッジサーバサービスユーザに固有の名前を付けることをお勧めします。

  1. サービスユーザアカウントを作成します。 

    p4 user -f svc_tokyo_edge

    ユーザ仕様で、ユーザType:フィールドをserviceに設定します。

  2. タイムアウトを無制限にして、サービスユーザをグループに追加します。これにより、サービスユーザのエッジサーバへのログインがタイムアウトすることを防ぐことができます。 

    p4 group no_timeout

    group仕様で、Users:フィールドをsvc_tokyo_edgeに設定し、Timeout:フィールドをunlimitedに設定します。

  3. プロンプトで値を入力して、サービスユーザにパスワードを割り当てます。 

    p4 passwd svc_tokyo_edge

  4. プロテクション仕様で、svc_tokyo_edgeサービスユーザsuperプロテクションを割り当てます。 

    p4 protect

コミットサーバおよびエッジサーバの構成の作成

コミットサーバおよびエッジサーバを構成するには、以下の手順が必要です。

Note

最も望ましいのは、P4NAMEとサーバIDを同じ値に設定する方法です。これにより、分散環境の各サーバの構成変数を独立させることが簡単にできます。

  1. コミットサーバ仕様を作成する。 

    p4 server chicago_commit

    サーバ仕様で、Services: フィールドをcommit-serverに設定し、Name:フィールドをchicago_commitに設定します。

  2. エッジサーバ仕様を作成する。 

    p4 server tokyo_edge

    サーバ仕様で、Services: フィールドをedge-serverに設定し、Name:フィールドをtokyo_edgeに設定します。

  3. コミットサーバのサーバIDを設定する。 

    p4 serverid chicago_commit

  4. コミットサーバとエッジサーバのjournalPrefix値を設定して、サーバチェックポイントとローテーションしたジャーナルの名前と場所を管理するこの手順は、必須ではありませんが、ベストプラクティスとなっています。複製プロセス中に、エッジサーバのローテーションしたジャーナルをコミットサーバに置くことが必要になる場合があります。コミットサーバにjournalPrefixが定義されていることで、エッジサーバがローテーションしたジャーナルの名前と場所を容易に識別できるようになります。 

    p4 configure set chicago_commit#journalPrefix=/chicago/backup/p4d_backup
p4 configure set tokyo_edge#journalPrefix=/tokyo/backup/p4d_backup

  5. エッジサーバにP4TARGETを設定して、コミットサーバを識別する。 

    p4 configure set tokyo_edge#P4TARGET=chicago.perforce.com:1666

  6. エッジサーバ構成にサービスユーザを設定する。 

    p4 configure set tokyo_edge#serviceUser=svc_tokyo_edge

  7. エッジサーバのログファイルに場所を設定する。 

    p4 configure set tokyo_edge#P4LOG=/tokyo/logs/tokyo_edge.log

  8. エッジサーバ構成とコミットサーバ構成にサービスユーザのP4TICKETS場所を設定する。 

    p4 configure set chicago_commit#P4TICKETS=/chicago/p4root/.p4tickets
p4 configure set tokyo_edge#P4TICKETS=/tokyo/p4root/.p4tickets

  9. エッジサーバデータベースとアーカイブノードを構成する。 

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

  10. 定期的にメタデータとアーカイブデータをプルするために、エッジサーバの起動コマンドを定義します。 

    p4 configure set tokyo_edge#startup.1="pull -i 1"     \\get metadata every second
p4 configure set tokyo_edge#startup.2="pull -u -i 1"  \\get versioned data every second
p4 configure set tokyo_edge#startup.3="pull -u -i 1"  \\get versioned data every second

エッジサーバの作成と起動

コミットサーバの構成が完了したので、コミットサーバのチェックポイントからエッジサーバを準備することができるようになりました。あといくつかの手順で作成が完了します。

  1. コミットサーバのチェックポイントを取り出します。ただし、エッジサーバに必要ではないデータベースの内容は除外してください。 

    p4d -r /chicago/p4root -K db.have, db.working, db.resolve, db.locks, db.revsh,
      db.workingx, db.resolvex -jd edge.ckp

  2. エッジサーバのP4ROOTディレクトリに、チェックポイントを復元します。 

    p4d -r /tokyo/p4root -jr edge.ckp

  3. 新しく準備されたエッジサーバのサーバIDを設定します。 

    p4d -r /tokyo/p4root -xD tokyo_edge

  4. エッジサーバ構成の指定の場所に、サービスユーザのログインチケットを作成します。 

    export P4TICKETS=/tokyo/p4root/.p4tickets
p4 -u svc_tokyo_edge -p chicago.perforce.com:1666 login

  5. エッジサーバを起動し、エッジサーバに対して以下のコマンドを実行して、複製のステータスを確認します。 

    p4 pull -lj

  6. コミットサーバからエッジサーバに、サービスユーザのログインチケットを作成します。コミットサーバで、次のコマンドを入力します。 

    export P4TICKETS=/chicago/p4root/.p4tickets
p4 -u svc_tokyo_edge -p tokyo.perforce.com:1666 login

既存のインストールから移行する

以下のセクションでは、既存の複製アーキテクチャからエッジコミットアーキテクチャに移行する方法について説明します。

既存のプロキシとレプリカを置き換える

現在Perforceプロキシを使用している場合、これらをエッジサーバで置き換えるべきか検討します。プロキシのパフォーマンスが許容できる範囲であれば、そのままいつまでも設置しておくことができます。必要に応じて、プロキシをエッジサーバの手前に設定して使用することができます。コミットサーバとエッジサーバの展開は、マスターサーバとプロキシサーバの展開と比較して非常に複雑です。環境をよく検討してください。

使用できる3種類のレプリカのうち、エッジサーバと置き換える最有力候補は転送レプリカです。多くの用途において、エッジサーバは転送レプリカよりも優れたソリューションを提供します。

ビルドレプリカは、必要に応じて置き換えることができます。ビルドプロセスでp4 syncコマンド以外に書き出しコマンドを実行する必要がある場合、エッジサーバが適しています。しかし、ビルドレプリカが問題なく動作している場合、それらを引き続きいつまでも使用することができます。

読み取り専用レプリカは、特に障害回復に使用されるものですが、そのまま設置しておけます。読み取り専用レプリカを、エッジサーバのバックアップ計画の一部として使用できます。

コミットサーバおよびエッジサーバをインクリメンタルに展開する

コミットサーバおよびエッジサーバは、インクリメンタルに展開できます。例えば、既存のマスターサーバは、コミットサーバとしての役割を果たし、ハイブリッドモードで動作するように再構成することができます。コミットサーバは、動作が変更されることなく、すべての既存ユーザ、ワークスペース、プロキシ、レプリカにサービスを提供し続けます。唯一の明確な違いは、コミットサーバがエッジサーバをサポートできるようになることです。

コミットサーバが利用できるようになると、引き続き1台以上のエッジサーバを構成できるようになります。1台のエッジサーバを試験チームで展開することは、エッジサーバの動作と構成を把握する良い方法です。

定期的にエッジサーバを追加展開していけば、影響を受ける可能性のあるプロセスを調整し、ユーザにワークフローへの変更について知らせる時間が確保できます。

最初はコミットサーバとエッジサーバを同じマシンで実行することで、処理を完全に分割することができるため、以後のエッジサーバの展開が容易になります。

ハードウェア、サイズ、容量

分散Perforceサービスの最初の展開では、コミットサーバはハイブリッドモードで動作し、現在のマスターサーバハードウェアを使用します。時間が経ちエッジサーバを追加するごとに、コミットサーバのパフォーマンス負荷の減少を確認できるようになります。最初の1年間運用後に、コミットサーバのハードウェアのサイズを再評価することができます。

エッジサーバは、そのエッジサーバに接続しているユーザのために大量の作業を扱います。既存の転送レプリカを再利用し、そのハードウェア上のパフォーマンス負荷を監視するのが賢いやり方です。転送レプリカを再利用するには、以下の手順を実行します。

多くのエッジサーバを展開しようとする場合、オプションとして、より強力なハードウェア上に、より少ないエッジサーバを展開することができます。また、ユーザが少数の場合には、各ハードウェアを低スペックにして、エッジサーバの数を増やす展開も選択できます。

複製フィルタリングを活用してエッジサーバ上にあるメタデータとアーカイブコンテンツの量を減らすこともできます。

Note

エッジサーバはローカルワークスペースメタデータの固有のコピーを保持しますが、これは他のエッジサーバやコミットサーバとは共有されません。

エッジサーバコンテンツにフィルタリングを適用することで、ストレージやパフォーマンス能力への需要を削減することができます。

コミットエッジアーキテクチャへの移行を進め、コミットサーバがエッジサーバからの要求のみを処理するようになると、エッジサーバにはコミットサーバよりもハードウェアリソースが必要であることがわかるようになります。

移行のシナリオ

このセクションでは、いくつかの移行シナリオにおける手順について説明します。このセクションで必要な資料が見つからない場合、Perforceサポート()までお問い合わせください。

マスターサーバをコミットサーバとして構成する

シナリオ: すでにマスターサーバがあります。マスターサーバをコミットサーバに変換して、引き続きクライアントのサポートを行いながら、エッジサーバと連携できるようにします。

  1. まだサーバIDが存在しない場合、マスターサーバのサーバIDを選択し、p4 serveridを使用して保存します。

  2. マスターサーバのサーバ仕様を設定するか、すでにサーバ仕様が存在する場合は既存の仕様を編集し、Services: commit-serverを設定します。

転送レプリカをエッジサーバに変換する

シナリオ: すでにマスターサーバと転送レプリカがあります。マスターサーバをコミットサーバに変換して、転送レプリカをエッジサーバに変換します。

現在のマスターサーバと転送レプリカの設定によっては、これらの手順の一部が省略できる場合があります。

  1. 転送レプリカのすべてのユーザに、現在の作業をサブミット、保留、または元に戻させ、現在のワークスペースを削除させます。

  2. 転送レプリカを停止します。

  3. まだサーバIDが存在しない場合、マスターサーバのサーバIDを選択し、p4 serveridを使用して保存します。

  4. マスターサーバのサーバ仕様を定義するか、すでにサーバ仕様が存在する場合は既存の仕様を編集し、Services: commit-serverを設定します。

  5. p4 serverを使用して転送レプリカのサーバ仕様を更新して、Services: edge-serverを設定します。

  6. 次のいずれかの方法により、使用中の集中サーバのデータでレプリカサーバを更新します。

    • チェックポイントを使用します。

      1. 集中サーバのチェックポイントを取出し、以下のテーブルをフィルタリングして表示します。db.have、db.working、db.resolve、db.locks、db.revsh、db.workingx、db.resolvex。 

        p4d -K db.have db.working,db.resolve,db.locks,db.revsh,db.workingx,db.resolvex
        -jd my_filtered_checkpoint_file

        『Perforceサーバ管理者ガイド: 基本』の付録「Perforceサーバリファレンス」を参照して、フィルタリングされたジャーナルダンプファイルを生成するために使用するオプション、特に-kオプションと-Kオプションを確認してください。

      2. チェックポイントをレプリカに復元します。

      3. レプリカのステートファイルを削除します。

    • 複製を使用します。

      1. レプリカを、別のポートで起動します。これにより、ローカルユーザが使用するのを防ぎます。

      2. マスターから更新をプルするのを待ちます。

      3. レプリカを停止し、以下のテーブルを削除します。db.have、db.working、db.resolve、db.locks、db.revsh、db.workingx、db.resolvex。

  7. レプリカを起動すると、エッジサーバになります。

  8. 旧転送レプリカのユーザに、新規エッジサーバの利用を開始させます。

    1. 新規クライアントワークスペースを作成し、それらを同期します。

これで、新規エッジサーバのセットアップと実行が完了しました。

ビルドサーバをエッジサーバに変換する

シナリオ: すでにマスターサーバとビルドサーバがあります。マスターサーバをコミットサーバに変換して、ビルドサーバをエッジサーバに変換します。

ビルドサーバには、すでにローカルにバインドされたクライアントがあり、エッジサーバへの変換後も引き続きこのクライアントを使用できるとすれば、大変魅力的なことです。詳細は以下の通りです。

  • ビルドサーバでは、ローカルにバインドされたクライアントはそれぞれのhaveデータとviewデータをdb.have.rpとdb.view.rpに格納します。

  • エッジサーバでは、ローカルにバインドされたクライアントはそれぞれのhaveデータとviewデータをdb.haveとdb.viewに格納します。

したがって、非常にシンプルな手順でビルドサーバをエッジサーバに変換することができます。

  1. Services: commit-serverを設定して、マスターのサーバIDとサーバ仕様を定義します。

  2. ビルドサーバのサーバ仕様を編集して、Services: build-serverをServices: edge-serverに変更します。

  3. ビルドサーバをシャットダウンして、以下を実行します。

    1. rm db.have db.view db.locks db.working db.resolve db.revsh db.workingx db.resolvex

    2. mv db.have.rp db.have

    3. mv db.view.rp db.view

  4. サーバを起動すると、エッジサーバになり、ローカルにバインドされたクライアントはすべて引き続き使用することができます。

コミットサーバまたはリモートエッジサーバからローカルエッジサーバにワークスペースを移行する

シナリオ: コミットサーバまたはリモートエッジサーバにワークスペースがあり、それをローカルエッジサーバに移行します。

  1. ワークスペースのすべての所有者に、現在の作業をサブミットさせるか元に戻させ、すべての保留状態のファイルが削除されていることを確認します。

  2. p4 unload -c workspace

    ワークスペース移行元のPerforceサービスに対して、このコマンドを実行します。この場合は、コミットサーバまたはリモートエッジサーバです。

  3. p4 reload -c workspace -p protocol:host:port

    ワークスペース移行先のPerforceサービスに対して、このコマンドを実行します。protocol:host:portは、ワークスペース移行元のコミットサーバまたはリモートエッジサーバを参照します。

分散インストールを管理する

コミットエッジアーキテクチャには、理解して対処方法を知っておく必要のある特定の問題があります。このセクションでは、これらの問題について説明します。

  • 各エッジサーバは、コミットサーバとは別にバックアップする必要のある、ワークスペースと進行中作業データの固有のセットを保持します。詳細については、バックアップと高可用性/障害回復(HA/DR)計画を参照してください。

  • 排他的ロックはグローバルです。排他的ロックを確立するには、コミットサーバと通信する必要があります。これにより、ネットワークに遅延が生じる場合があります。

  • 分散環境での変更の保留は、一般的にエッジサーバで発生します。保留は、コミットサーバにバインドされたクライアントワークスペースを使用しているときのみ、コミットサーバで発生します。通常、エッジサーバ上で保留されているチェンジリストがエッジサーバ間で共有されることはありません。

    エッジサーバ上で保留されているチェンジリストをコミットサーバに昇格させて、他のエッジサーバでも使用できるようにすることができます。詳細については、保留状態のチェンジリストの昇格を参照してください。

  • エッジサーバでは、ユーザの自動作成はできません。

ユーザをエッジサーバに移動する

新規エッジサーバを作成するとき、そのエッジサーバを使用するように、ユーザやグループを割り当てることができます。

  • ユーザにはエッジサーバのP4PORT設定が必要です。

  • ユーザは、エッジサーバ上に新規ワークスペースを作成するか、既存ワークスペースを新規エッジサーバに転送する必要があります。既存ワークスペースの転送は、自動化できます。

認証トリガまたはシングルサインオンを使用する場合、関連するトリガをすべてのエッジサーバにインストールして、認証プロセスを検証してください。

保留状態のチェンジリストの昇格

エッジサーバ上の保留状態のチェンジリストは、通常他のエッジサーバからアクセスできませんが、自動的または明示的にコミットサーバに昇格することができます。昇格された保留状態のチェンジリストは、どのエッジサーバでも使用可能です。

  • 共有されたアーカイブ構成では、コミットサーバとエッジサーバは同じストレージデバイスでアーカイブされたコンテンツにアクセスできます。保留状態は、自動的にコミットサーバに昇格されます。詳細については、自動的に保留状態を昇格するを参照してください。

  • コミットサーバとエッジサーバがアーカイブを共有していない場合、保留状態を明示的に昇格する必要があります。詳細については、明示的に保留状態を昇格するを参照してください。

p4 describeコマンド、p4 changesコマンド、またはp4 change -oコマンドの-ztag出力を使用して、保留状態の昇格ステータスを表示できます。

昇格された保留状態の操作の制限に関する詳細については、昇格された保留状態を操作するを参照してください。

自動的に保留状態を昇格する

エッジサーバとコミットサーバが同じアーカイブコンテンツにアクセスできるように構成される場合、保留状態の昇格は、自動的に行われます。p4 shelve -pを使用した保留状態のフィールドの昇格は必要ありません。

エッジサーバとコミットサーバが同じアーカイブコンテンツにアクセスできるように構成するには、コミットサーバとエッジサーバの両方で同じパスにserver.depot.rootを設定してください。また、エッジサーバでlbr.replication構成可能変数をsharedに設定してください。例: 

p4 configure set commit#server.depot.root=/p4/depot/root
p4 configure set edge#server.depot.root=/p4/depot/root
p4 configure set edge#lbr.replication=shared

明示的に保留状態を昇格する

チェンジリストを明示的に保留するには、-pオプションをp4 shelveコマンドで使用します。

例えば、edge1とedge2の2つのエッジサーバがある場合、プロセスは以下のように実行されます。

  1. edge1からチェンジリストを保留し、昇格させます。 

    edge1> p4 shelve -p -c 89

  2. 保留状態のチェンジリストがedge2で使用できるようになります。 

    edge2> p4 describe -S 89

  3. 昇格が必要となるのは、一度のみです。

    続けてp4 shelveコマンドを入力することで、コミットサーバの保留状態のチェンジリストを、サーバロックプロテクションにより自動的に更新できます。例えば、edge1に変更を加えて、保留済みのチェンジリストを再表示します。 

    edge1> p4 shelve -r -c 89

    更新がedge2に表示されました。 

    edge2> p4 describe -S 89

昇格された保留状態を操作する

昇格された保留状態を操作する際に、以下の制限が適用されます。

  • 保留状態が一度昇格されると、昇格されたままになります。

    保留状態のチェンジリストを降格する仕組みはありません。チェンジリストから保留状態のファイルを削除してください。

  • リモートの昇格された保留状態を作業状態のローカルファイルへ保留解除することはできません。

  • 昇格された保留状態がある場合、エッジサーバワークスペースをアンロードすることはできません。

  • 変更を保持しているサーバでのみ、昇格された保留状態にp4 submit -eを実行できます。

  • p4 unshelveコマンドを使用すると、昇格された保留状態を、あるエッジサーバから別のエッジサーバに移動できます。

トリガ

このセクションでは、コミットエッジ構成で既存トリガを管理する方法と、エッジタイプトリガの使用方法について説明します。

トリガの場所を判断する

分散Perforceサービスで、トリガはコミットサーバ上、エッジサーバ上、またはその両方で実行される場合があります。トリガについての詳細情報は、『Perforceサーバ管理者ガイド:基本』を参照してください。

すべての関連するトリガスクリプトとプログラムが適切に展開されていることを確認してください。エッジサーバは、非エッジタイプのトリガに、以下のように影響を及ぼす場合があります。

  • トリガを含むポリシーを実行する場合、チェンジリストまたは保留トリガがコミットサーバとエッジサーバのどちらで実行されるべきか、検討してください。

  • エッジサーバは、ワークスペースやいくつかのタイプのラベルにフォームトリガを実行します。

トリガスクリプトは、以下の表に示されているトリガ変数を使用して、それらがコミットサーバとエッジサーバのどちらで実行されているか判別します。トリガがコミットサーバで実行されている場合、%peerip%が%clientip%と一致します。

トリガ変数

解説

%peerip%

プロキシ、ブローカ、レプリカ、またはエッジサーバのIPアドレス。

%clientip%

プロキシ、ブローカ、レプリカ、またはエッジサーバのどれを通じて接続しているかにかかわらず、コマンドを起動したユーザが使用するマシンのIPアドレス。

%submitserverid%

分散インストール中のchange-submit、change-content、change-commitトリガに対して、サブミットを実行したエッジサーバのserver.id。詳細情報は、『P4コマンドリファレンス』のp4 serveridを参照してください。

エッジトリガを利用する

さらに、エッジサーバはエッジコミットアーキテクチャに固有のedge-submitとedge-contentの2つのトリガタイプをサポートしています。これらについて、以下のテーブルで説明します。

トリガタイプ

解説

edge-submit

チェンジリストの作成後、クライアントからエッジサーバへのファイル転送の前にエッジサーバのサブミット前トリガを実行します。この時点では、ファイルがロックされている必要はありません。

edge-content

クライアントからエッジサーバへのファイル転送後、エッジサーバからコミットサーバへのファイル転送の前にエッジサーバのサブミット中トリガを実行します。この時点で、チェンジリストは保留されます。

エッジサーバのトリガは、p4 submit -e経由で実行される際に順番に実行されます。p4 submitでは、edge-submitトリガはチェンジリストが保留される直前に実行され、edge-contentトリガはチェンジリストが保留された直後に実行されます。edge-submitトリガは、ファイルがエッジサーバに転送される前に実行されるので、ファイルの内容にアクセスできません。

以下のedge-submitトリガは、サブミットしたユーザが、変更のレビューと承認を受けていない場合に、チェンジリストを拒否するMS-DOSバッチファイルです。このトリガは、//depot/qaブランチ内の少なくとも1つのファイルに影響するチェンジリストのサブミット試行に対してのみ実行されます。 

@echo off
rem REMINDERS
rem - If necessary, set Perforce environment vars or use config file
rem - Set PATH or use full paths (C:\PROGRA~1\Perforce\p4.exe)
rem - Use short pathnames for paths with spaces, or quotes
rem - For troubleshooting, log output to file, for instance:
rem - C:\PROGRA~1\Perforce\p4 info >> trigger.log
if not x%1==x goto doit
echo Usage is %0[change#]
:doit
p4 describe -s %1|findstr "Review Approved...\n\n\t" > nul
if errorlevel 1 echo Your code has not been revewed for changelist %1
p4 describe -s %1|findstr "Review Approved...\n\n\t" > nul

トリガを使用するには、次の行をトリガテーブルに追加します。 

sampleEdge   edge-submit //depot/qa/...   "reviewcheck.bat %changelist%"

バックアップと高可用性/障害回復(HA/DR)計画

コミットサーバは、マスターサーバと同じバックアップ戦略とHA/DR戦略を採用できます。エッジサーバには、固有の情報が含まれているため、バックアップ計画とHA/DR計画が必要です。エッジサーバの停止が、マスターサーバの停止と同じだけ緊急の事態かどうかは、要件によって異なります。したがって、エッジサーバのHA/DR計画の目標復旧時点(RPO)と目標復旧時間(RTO)は、コミットサーバに比べて低い場合もあります。

コミットサーバをバックアップから再構築する必要がある場合、コミットサーバのバックアップに先立って、各エッジサーバをバックアップまでロールバックする必要があります。また、コミットサーバにローカルユーザが存在しない場合、コミットサーバが完全複製されたエッジサーバから再構築できます(このシナリオでは、エッジサーバはコミットサーバの上位集合です)。

エッジサーバのバックアップと復元は、オフラインレプリカサーバのバックアップと復元と同様に行えます。具体的には、以下のことを行う必要があります。

  1. エッジサーバのチェックポイントのスケジュールを、コミットサーバで次回ジャーナルローテーションが検出される時に設定します。例: 

    p4 -p myedgehost:myedgeport admin checkpoint

    p4 pullコマンドは、コミットサーバで次回ジャーナルをローテーションするとき、チェックポイントを実行します。チェックポイントのスケジュールを記録するため、エッジサーバのP4ROOTディレクトリにstateCKPファイルが書き出されます。

  2. コミットサーバで、ジャーナルをローテーションします。 

    p4 -p mycommithost:mycommitport admin journal

エッジサーバの複製ステートファイルがバックアップに含まれる限り、エッジサーバを復元してサービスを再開することが可能です。エッジサーバが長期間オフラインだった場合、コミットサーバでのアクティビティをすべて取得するのに、時間がかかる場合があります。

コミットサーバのフェイルオーバ計画の一部として、エッジサーバが新規コミットサーバを使用するようにリダイレクトされることを確認してください。

Note

コミットサーバにローカルユーザが存在しない場合、エッジサーバがチェックポイントに到達するまで、コミットサーバと比較して非常に長い時間がかかる可能性があります。エッジサーバに対してコミットサーバとは異なるチェックポイントスケジュールを使用することを検討してください。エッジサーバのジャーナルローテーションは、コミットサーバのジャーナルローテーションと同じ時刻にスケジュールすることができます。

その他考慮すべき事項

エッジサーバを展開する上で、以下の分野を考慮に入れてください。

  • ラベル

    分散Perforceサービスで、ラベルはエッジサーバのローカルにすることも、グローバルにすることもできます。

  • 排他的オープン

    排他的オープン(+lファイルタイプ修飾子)はグローバルです。排他的オープンを確立するには、コミットサーバと通信する必要があります。これにより、ネットワークに遅延が生じる場合があります。

  • サードパーティツールとの統合

    障害追跡などのサードパーティツールをPerforceと統合する場合、それらのツールがマスターサーバ/コミットサーバに引き続き接続するか、代わりにエッジサーバを使用できるかを検討します。ツールがグローバルデータにのみアクセスする場合は、いつでも接続することができます。エッジサーバにローカルの情報(ワークスペースデータなど)を参照する場合は、特定のエッジサーバに接続する必要があります。

    ビルドプロセスは、専用のエッジサーバに接続できるため便利です。これにより、ビルドワークスペースメタデータを独立させるとともに、Perforceの機能がすべて使用できるようになります。エッジサーバをこのように使用することは、ビルドファームレプリカを使用することに似ています。ただし、ビルドプロセスの一部として書き出しコマンドを実行できるなど、柔軟性がさらに増します。

  • 伝搬属性を持つファイル

    分散環境で、以下のコマンドは伝搬属性を持つファイルに対してサポートされていません。p4 copy、p4 delete、p4 edit、p4 integrate、p4 reconcile、p4 resolve、p4 shelve、p4 submit、p4 unshelve。エッジサーバにある伝搬属性を持つファイルの統合はサポートされていません。統合のアクション、ターゲット、ソースによっては、p4 integrateコマンドまたはp4 resolveコマンドが失敗します。

    サイトがこの機能を使用している場合、これらのコマンドをエッジサーバではなくコミットサーバに送信してください。Perforceが提供しているソフトウェアは、現在ファイルに伝搬属性を設定していません。この制限の影響を受けるケースは報告されていません。

  • ログインおよび監査

    エッジサーバは、各自のサーバと監査ログのセットを保持します。エッジサーバでは構造化ログの使用を検討してください。それらは、ジャーナルローテーションを自動的にローテーションし、クリーンアップします。各エッジサーバのログを、監視と監査システム全体に組み込みます。

    特に、rpl.checksum.*構成可能変数の使用を検討してください。ジャーナルローテーション、チェンジリストのサブミット、テーブルのスキャンおよびアンロード中に、データベーステーブルの一貫性を自動的に検証します。整合性イベントについては、定期的にintegrity.csv構造化ログを監視してください。

  • アンロードディポ

    アンロードディポは、エッジサーバごとに異なる内容を含んでいる場合があります。エッジサーバにバインドされているクライアントとラベルは、エッジサーバのアンロードディポにアンロードされ、他のエッジサーバでp4 clients -Uコマンドとp4 labels -Uコマンドを実行しても表示されません。

    エッジサーババックアップの一部にアンロードディポを必ず含めてください。コミットサーバは、アンロードディポがすべてのエッジサーバ上で空であるかどうかの検証を行わないため、コミットサーバからアンロードディポを削除するにはp4 depot -d -fを指定する必要があります。

  • 将来のアップグレード

    コミットサーバとエッジサーバは、同時にアップグレードしてください。

  • 時間帯

    コミットサーバとエッジサーバは、同じタイムゾーンを使用する必要があります。

  • Perforce Swarm

    Swarmの初期リリースは、ハイブリッドモードで動作中のコミットサーバか、エッジサーバのユーザならそのエッジサーバに接続できるため便利です。Swarmの複数のエッジサーバとの完全な互換性については、今後のSwarmリリースで対応する予定です。Swarmとエッジサーバとの併用の詳細については、Perforceサポート()までお問い合わせください。

検証

コミットサーバとエッジサーバを展開する上で、以下の領域のテストおよび検証に重点を置いてください。

サポートされる展開の構成

  • ハイブリッドモード: マスターサーバとしても動作するコミットサーバ

  • コミットサーバとエッジサーバに組み込まれている読み取り専用レプリカ

  • エッジサーバに組み込まれているプロキシサーバ

バックアップ

コミットサーバとエッジサーバ上で、完全なバックアップ計画を実行します。エッジサーバ上での直接のジャーナルローテーションは許可されていないことにご注意ください。ジャーナルローテーションは、マスターサーバで実行された結果として、エッジサーバ上でも実行されます。