Helix Coreサーバ管理者ガイド (2020.1)

複製処理の実行中またはエッジサーバが連結されている状態でメタデータをフィルタリングする

HA/DRソリューションの一部として、通常、すべてのメタデータとバージョンファイルが複製されるようにすることが求められます。 それ以外の用途でも(特に、ビルドサーバや転送レプリカサーバの場合)、すべてのメタデータとバージョンファイルを複製した結果、非常に多くの冗長データが転送されることがよくあります。

多くの場合、クライアントワークスペースとファイルリビジョンのデータをフィルタリングするようにレプリカサーバを設定すると便利です。 以下に例を示します。

  • リモートサイトで特定のプロジェクトの作業を行っている開発者は、通常、他のプロジェクトの開発作業が行われている他の場所に存在するすべてのクライアントワークスペースの状態を知る必要はありません。
  • ビルドサーバは、大企業でよく見られるような延々と続く社内文書やスプレッドシートの変更内容にアクセスする必要はありません。

また、エッジサーバが連結されている場合(バージョン2019.1以降)、連結元から離れているエッジサーバでは、連結元に近いエッジサーバで必要になるデータの一部のみが使用されるというメリットもあります。

データベーステーブルを除外する

メタデータをフィルタリングする最も簡単な方法は、「-T tableexcludelist」オプションを「p4 pull」コマンドで使用する方法です。 例えば、すべてのユーザのhaveリストやユーザのクライアントワークスペースの状態をビルドサーバで参照する必要がない場合は、p4 pull -T db.have,db.workingコマンドを使用して、db.havedb.workingをフィルタリングで完全に除外することができます。

データベーステーブル全体を除外する方法は、サーバ間で受け渡されるデータ量を管理する方法としては粗すぎてお勧めできません。その理由としては、Helixサーバコマンドの実行時に参照される可能性が最も高いテーブルに関する知識が必要になることと、バージョンファイルの複製を制御する手段がないことが挙げられます。

フィールドを使用してフィルタリングを実行する

p4 serverフォームのClientDataFilter:フィールド、RevisionDataFilter:フィールド、ArchiveDataFilter:フィールドを使用すると、複製されるデータをより詳細に制御することができます。 これらのフィールドを使用して、サーバのメタデータとバージョン化ファイルのサブセットのみを、レプリカサーバやエッジサーバに複製することができます。

例   クライアントワークスペースのデータとファイルをフィルタリングで除外する

3つのサイトの各ユーザ名がsite[123]-ws-usernameとなっている場合、site1のユーザの部分的なバックアップとして機能するレプリカを、以下のように設定することができます。

ServerID:       site1-1668
Name:           site1-1668
Type:           server
Services:       replica
Address:        tcp:site1bak:1668
Description:
        Replicate all client workspace data, except the states of
        workspaces of users at sites 2 and 3.
        Automatically replicate .c files in anticipation of user
        requests. Do not replicate .mp4 video files, which tend
        to be large and impose high bandwidth costs.
ClientDataFilter:
        //...
        -//site2-ws-*
        -//site3-ws-*
RevisionDataFilter:
ArchiveDataFilter:
        //....c
        -//....mp4

レプリカを起動する場合、p4 pullメタデータスレッドは以下のようになります。

$ p4 configure set "site1-1668#startup.1=pull -i 30"

この構成では、site1に関連付けられたdb.haveのみが複製されます。 site2site3に関連付けられたワークスペースのメタデータはすべて無視されます。

ファイルに関連するメタデータは、すべて複製されます。 .mp4で終わるファイルを除き、ディポ内のすべてのファイルが複製されます。 .cで終わるファイルは、ファイルの送信時に自動的にレプリカに転送されます。

この仕組みを詳しく説明するため、ビルドサーバを例として考えてみます。 組織内で行われているコード開発、ビジネス文書の作成、ビデオの制作などの作業の内容は、ディポ内の任意の場所に保存することができます。ただし、このビルドファームは、リリース可能製品をビルドするための専用ビルドファームであるため、組織の他の出力情報を使用する必要はありません。

例   ディポのサブセットのメタデータとファイルコンテンツを複製する

リリース可能コードは//depot/releases/... に格納されます。自動ビルドは、このディポ内の変更に基づいています。 ディポの他の箇所に対する変更は、個々のユーザのクライアントワークスペースの状態と同様に、フィルタリングで除外されます。

ServerID:       builder-1669
Name:           builder-1669
Type:           server
Services:       build-server
Address:        tcp:built:1669
Description:
        Exclude all client workspace data
        Replicate only revisions in release branches
ClientDataFilter:
        -//...
RevisionDataFilter:
        -//...
        //depot/releases/...
ArchiveDataFilter:
        -//...
        //depot/releases/...

レプリカにデータを取り込むには、以下のようなコマンドを使用して、フィルタリングされたチェックポイントを作成します。

$ p4d -r /p4/master -P builder-1669 -jd myCheckpoint

builder-1669に指定されたフィルタはチェックポイントの作成に使用されます。 その後、p4 pullコマンドを使用して、レプリカの更新を続行します。

レプリカを起動する場合、p4 pullメタデータスレッドは以下のようになります。

$ p4 configure set "builder-1669#startup.1=pull -i 30"

このp4 pullスレッドには、複製用のメタデータが取り込まれます。このメタデータにより、すべてのユーザのすべてのクライアントワークスペースデータ(haveリストを含む)が除外されます。

p4 pull -uスレッドは、//depot/releases/... ブランチのリビジョンに影響する変更(ビルドサーバで必要となる唯一の変更)を除き、マスター上のすべての変更を無視します。 使用可能な唯一のメタデータは、リリースされたコードに関するメタデータです。 リリースされたすべてのコードは、何らかの要求が作成される前に、ビルドサーバに自動的に転送されるため、ビルドサーバがp4 syncを実行すると、同期処理がローカルで実行されます。