高度なエージェントの設定

このドキュメントでは、次のような Transfer Service for On Premises Data の高度な設定オプションについて説明します。

CIFS または SMB ボリュームのデータをコピーする

オンプレミス用 Transfer エージェントは、Windows サーバーで直接サポートされません。ただし、POSIX 準拠のファイル システムに保存されているデータを Linux サーバーまたは仮想マシン(VM)にマウントし、Linux サーバーまたは VM からエージェントを実行して Cloud Storage にコピーできます。

CIFS または SMB ボリュームからデータを移動するには:

  1. Linux サーバーまたは VM をプロビジョニングします。

    サポートされているオペレーティング システムについては、前提条件をご覧ください。

  2. プロビジョニングした Linux サーバーまたは VM で次のコマンドを実行して、ボリュームをマウントします。

    sudo mount -t cifs -o
    username=WINDOWS-SHARE-USER,password=WINDOWS-SHARE-PASSWORD //IP-ADDRESS/SHARE-NAME /mnt
    

    次のように置き換えます。

    • IP-ADDRESS: CIFS または SMB ボリュームが配置されている Microsoft Windows サーバーの IP アドレス。
    • SHARE-NAME: マウントする共有名。
    • WINDOWS-SHARE-USER: CIFS または SMB ボリュームにアクセスするための承認済みユーザー。
    • WINDOWS-SHARE-PASSWORD: CIFS または SMB ボリュームの承認済みユーザーのパスワード。
  3. 次のコマンドを実行して、CIFS ボリュームがマウントされていることを確認します。

    findmnt -l
    
  4. 次のコマンドを実行して、エージェントを実行するユーザーがマウントされたボリュームでファイルを一覧表示してコピーできることを確認します。

    sudo -u USERNAME cp /mnt/FILE1 /mnt/FILE2
    

    次のように置き換えます。

    • USERNAME: エージェントを実行するユーザー。
    • FILE1: コピー元のファイル。
    • FILE2: コピー先のファイル名。
  5. オンプレミス用 Transfer エージェントをインストールします

サービス アカウントの認証情報を使用する

サービス アカウントの認証情報を使用してエージェントを実行できます。サービス アカウントの認証情報を使用すると、単一のユーザー アカウントに依存せずに転送エージェントを認証できます。アカウント タイプの詳細については、プリンシパルをご覧ください。

エージェントでサービス アカウントの認証情報を使用する前に、次の点をチェックして、Transfer Service for On Premises Data の準備ができていることを確認します。

  1. オンプレミス用 Transfer を設定します

  2. 転送ジョブが存在すること

エージェントでサービス アカウントの認証情報を使用するには:

  1. すべてのエージェント コンテナを停止します

  2. サービス アカウント キーを作成します。詳細については、サービス アカウント キーの作成と管理をご覧ください。

  3. 次のコマンドを実行してエージェントの Docker コンテナを起動します。

    sudo docker run --ulimit memlock=64000000 -d --rm -v /:/transfer_root \
    gcr.io/cloud-ingest/tsop-agent:latest \
    --enable-mount-directory \
    --project-id=PROJECT-ID \
    --creds-file=CREDENTIAL-FILE \
    --hostname=$(hostname) \
    --agent-id-prefix=ID-PREFIX
    

    次のように置き換えます。

  • PROJECT-ID: 転送をホストし、Pub/Sub リソースの作成と課金が行われるプロジェクト ID
  • CREDENTIAL-FILE: サービス アカウントの JSON 形式の認証情報ファイル。サービス アカウントの認証情報ファイルを生成する方法については、サービス アカウント キーの作成と管理をご覧ください。
  • ID-PREFIX: Google Cloud Console でエージェントやそのマシンを識別しやすくするために、エージェント ID に追加される接頭辞。接頭辞を使用する場合、エージェント ID は prefix + hostname + Docker container ID の形式になります。

エージェントの最大メモリを調整する

Transfer Service for On Premises Data エージェントは、デフォルトで最大 8 GiB のシステムメモリを使用します。エージェントが使用する最大メモリ量を環境に合わせて調整するには、--max-physical-mem=MAXIMUM-MEMORY を渡します。このとき、MAXIMUM-MEMORY は環境に合った値に置き換えます。

Transfer Service for On Premises Data エージェントのメモリ要件は次のとおりです。
  • 最小メモリ: 1 GiB
  • ハイ パフォーマンス アップロードをサポートする場合の最小メモリ: 6 GiB

デフォルトの 8 GiB をおすすめします。

MAXIMUM-MEMORY で使用できる書式の例を、次の表に示します。

max-physical-memory 最大メモリ設定
6g 6 GB
6gb 6 GB
6GiB 6 GiB

エージェントのディレクトリ アクセスを制限する

転送の実行中にエージェントがアクセスできるディレクトリを指定するには、-v HOST-DIRECTORY:CONTAINER-DIRECTORY をエージェントに渡します。ここで:

  • HOST-DIRECTORY は、コピー元のホストマシン上のディレクトリです。
  • CONTAINER-DIRECTORY は、エージェント コンテナ内でマッピングされたディレクトリです。

複数の -v フラグを使用して、コピー元のディレクトリをさらに指定できます。例:

sudo docker run --ulimit memlock=64000000 -d -rm --volumes-from gcloud-config \
-v /usr/local/research:/usr/local/research \
-v /usr/local/billing:/usr/local/billing \
-v /tmp:/tmp \
gcr.io/cloud-ingest/tsop-agent:latest \
--project-id=PROJECT-ID \
--hostname=$(hostname) \
--agent-id-prefix=ID-PREFIX

サービス アカウントを使用している場合は、認証情報ファイルをコンテナにマウントし、--creds-file=CREDENTIAL-FILE を渡します。例:

sudo docker run --ulimit memlock=64000000 -d -rm \
-v HOST-DIRECTORY:CONTAINER-DIRECTORY \
-v /tmp:/tmp
-v FULL-CREDENTIAL-FILE-PATH:FULL-CREDENTIAL-FILE-PATH
gcr.io/cloud-ingest/tsop-agent:latest \
--project-id=PROJECT-ID \
--creds-file=CREDENTIAL-FILE \
--hostname=$(hostname) \
--agent-id-prefix=ID-PREFIX

次のように置き換えます。

  • HOST-DIRECTORY: コピー元のホストマシン上のディレクトリ。
  • CONTAINER-DIRECTORY: エージェント コンテナ内でマッピングされたディレクトリ。
  • FULL-CREDENTIAL-FILE-PATH: 認証情報ファイルの完全修飾パス。
  • PROJECT-ID: 転送をホストし、Pub/Sub リソースの作成と課金が行われるプロジェクト ID
  • CREDENTIAL-FILE: サービス アカウントの JSON 形式の認証情報ファイル。サービス アカウントの認証情報ファイルを生成する方法については、サービス アカウント キーの作成と管理をご覧ください。
  • ID-PREFIX: Google Cloud Console でエージェントやそのマシンを識別しやすくするために、エージェント ID に追加される接頭辞。接頭辞を使用する場合、エージェント ID は prefix + hostname + Docker container ID の形式になります。

Kubernetes でエージェントを調整する

Docker は、Kubernetes でサポートされているコンテナ ランタイムです。Kubernetes を使用すると、同時に多数のエージェントの起動と停止をオーケストレートできます。Kubernetes から見ると、エージェント コンテナはステートレス アプリケーションになるため、Kubernetes でステートレス アプリケーションをデプロイする際の手順を利用できます。

Cloud Interconnect で非公開 API エンドポイントを使用する

Cloud Interconnect で非公開 API エンドポイントを使用するには:

  1. エージェントを実行するオンプレミス ホストにログインします。

  2. 限定公開の Google アクセスを構成します。詳細については、オンプレミス ホスト用の限定公開の Google アクセスの構成をご覧ください。

  3. Cloud Storage API と Pub/Sub API に接続できることを確認します。

    1. Cloud Storage API の場合は、転送エージェントと同じマシンから gsutil cp test.txt gs://MY-BUCKET コマンドを実行して、Cloud Storage バケットへのファイルの転送をテストします。ここで、MY-BUCKET は Cloud Storage バケットの名前です。転送が正常に行われたら、テストは成功です。
    2. Pub/Sub API の場合は、転送エージェントと同じマシンから gcloud pubsub topics list --project=PROJECT-ID コマンドを実行して、既存の Pub/Sub トピックが見つかることを確認します。ここで、PROJECT-ID は Google Cloud プロジェクト名です。Pub/Sub トピックのリストが表示されたら、テストは成功です。

転送プロキシを使用する

Transfer Service for On Premises Data エージェントは、HTTPS_PROXY 環境変数を渡すことで、ネットワークでの転送プロキシの使用をサポートします。

例:

sudo docker run -d --ulimit memlock=64000000 --rm \
--volumes-from gcloud-config \
-v /:/transfer_root \
--env HTTPS_PROXY=PROXY\
gcr.io/cloud-ingest/tsop-agent:latest \
--enable-mount-directory \
--project-id=PROJECT-ID \
--hostname=$(hostname) \
--agent-id-prefix=ID-PREFIX

次のように置き換えます。

  • PROXY: プロキシ サーバーの HTTP URL とポート。TLS 暗号化で二重ラップ リクエストを回避するため、HTTPS URL ではなく、HTTP URL を指定します。二重ラップ リクエストが発生すると、プロキシ サーバーから有効な送信リクエストが送信できなくなります。
  • PROJECT-ID: 転送をホストし、Pub/Sub リソースの作成と課金が行われるプロジェクト ID
  • ID-PREFIX: Google Cloud Console でエージェントやそのマシンを識別しやすくするために、エージェント ID に追加される接頭辞。接頭辞を使用する場合、エージェント ID は prefix + hostname + Docker container ID の形式になります。