詳細オプション

このドキュメントでは、ファイル システム転送の詳細設定のオプションについて説明します。

• CIFS または SMB ボリュームのデータをコピーする
• サービス アカウントの認証情報を使用する
• エージェントの最大メモリを調整する
• エージェントのディレクトリ アクセスを制限する
• Kubernetes でエージェントを調整する
• 転送プロキシを使用する
• 保持ポリシーが設定されたバケットにコピーする
• ネットワーク帯域幅を増やすためのオプション

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

転送エージェントは 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. 転送エージェントをインストールします。

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

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

注: サービス アカウント キーが正しく管理されていない場合は、セキュリティ リスクが発生します。可能であれば、サービス アカウント キーよりも安全な代替手段を選択してください。サービス アカウント キーで認証する必要がある場合は、秘密鍵のセキュリティと、サービス アカウント キーを管理するためのベスト プラクティスで説明されているその他の操作は、ユーザーの責任で実施してください。サービス アカウント キーを作成できない場合は、組織でサービス アカウント キーの作成が無効になっている可能性があります。詳細については、デフォルトで安全な組織リソースの管理をご覧ください。

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

2. エージェント作成コマンドにサービスキーのロケーションを渡します。

   gcloud transfer agents install --pool=POOL_NAME --count=NUM_AGENTS \
     --mount-directories=MOUNT_DIRECTORIES \
     --creds-file=RELATIVE_PATH_TO/KEY_FILE.JSON
   

   認証情報ファイルは、gcloud transfer によって自動的にマウントされます。--mount-directories フラグで指定する必要はありません。

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

転送エージェントはデフォルトで最大 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-mem 値	最大メモリ設定
6g	6 GB
6gb	6 GB
6GiB	6 GiB

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

転送ジョブを作成できるユーザーは、エージェントからアクセス可能な任意のファイル システム ディレクトリに対してデータの取得やダウンロードを行うことができます。

エージェントが root として実行され、ファイル システム全体にアクセスできる場合、悪意のある操作者がホストを乗っ取るおそれがあります。必要なディレクトリのみにエージェントのアクセスを制限することを強くおすすめします。

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

gcloud

エージェントがファイル システム上でアクセスできるディレクトリを指定するには、gcloud transfer agents install で --mount-directories フラグを使用します。

gcloud transfer agents install --pool=POOL_NAME --count=NUM_AGENTS \
  --mount-directories=MOUNT_DIRECTORIES

複数のディレクトリを指定するには、各ディレクトリをカンマで区切り、スペースは使用しません。

gcloud transfer agents install --pool=POOL_NAME --count=NUM_AGENTS \
  --mount-directories=MOUNT_DIRECTORY_1,MOUNT_DIRECTORY_2

--creds-file フラグを使用して認証情報ファイルを指定する場合、gcloud transfer は自動的に認証情報ファイルをマウントします。認証情報ファイルと同じディレクトリにある他のファイルはマウントされません。

docker run

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

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

エージェントがコピーするファイルを検出できるように、HOST_DIRECTORY と CONTAINER_DIRECTORY 同じにする必要があります。

このオプションを使用する場合:

• --enable-mount-directory を指定しないでください。
• ファイルパスの前に /transfer_root を付けないでください。

--enable-mount-directory オプションは、ファイル システム全体をコンテナの /transfer_root ディレクトリにマウントします。--enable-mount-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: 転送リソースをホストするプロジェクト 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 に接続できることを確認します。

   1. Cloud Storage API の場合は、転送エージェントと同じマシンから gcloud storage cp test.txt gs://MY-BUCKET コマンドを実行して、Cloud Storage バケットへのファイルの転送をテストします。ここで、MY-BUCKET は Cloud Storage バケットの名前です。転送が正常に行われたら、テストは成功です。

転送プロキシを使用する

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

例:

sudo docker run -d --ulimit memlock=64000000 --rm \
--volumes-from gcloud-config \
-v /usr/local/research:/usr/local/research \
--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: 転送リソースをホストするプロジェクト ID が作成され、課金されます。
• ID_PREFIX: Google Cloud コンソールでエージェントやそのマシンを識別しやすくするために、エージェント ID に追加される接頭辞。接頭辞を使用する場合、エージェント ID は prefix + hostname + Docker container ID の形式になります。

保持ポリシーが設定されたバケットにコピーする

保持ポリシーが設定されたバケットに転送するには、次の手順を実施することをおすすめします。

1. 最後のバケットと同じリージョン内に Cloud Storage バケットを作成します。この一時バケットに保持ポリシーが含まれていないことを確認します。

   リージョンの詳細については、バケットのロケーションをご覧ください。

2. Storage Transfer Service を使用して、保持ポリシーなしで作成した一時バケットにデータを転送します。

3. bucket-to-bucket 転送を実行して、保持ポリシーが設定されたバケットにデータを転送します。

4. データを一時保存するために作成した Cloud Storage バケットを削除します。

ネットワーク帯域幅を増やすためのオプション

ファイル システム転送のネットワーク帯域幅を増やす方法はいくつかあります。ネットワーク帯域幅を増やすと、特に、大規模なデータ転送の時間を短縮できます。

• Google とのピアリング - ピアリングは、Google と直接相互接続してトラフィック交換をサポートする場所です。世界中にダイレクト ピアリング ロケーションがあります。メリットとポリシーの概要は、ピアリングをご覧ください。

• Cloud Interconnect - Cloud Interconnect はピアリングに似ていますが、相互接続を使用して Google に接続します。選択できる相互接続には、次の 2 種類があります。

  • Dedicated Interconnect - 専用接続を介して、データセンターから Google データセンターに直接接続します。詳細については、Dedicated Interconnect の概要をご覧ください。

  • Partner Interconnect - サービス プロバイダと協力して、サービス パートナーのネットワークを介して Google データセンターへの接続を確立します。詳細については、Partner Interconnect の概要をご覧ください。

• ISP から帯域幅の提供を受ける - ご利用のインターネット サービス プロバイダ（ISP）で、帯域幅を増やせる場合があります。利用可能なオプションについては、プロバイダにお問い合わせください。