Storage Transfer Service では、クラウドとオンプレミスの Hadoop Distributed File System(HDFS)からの転送がサポートされます。
HDFS からの転送では、宛先として Cloud Storage を使用する必要があります。
使用例には、オンプレミス ストレージから Cloud Storage への移行、オンプレミス ストレージの空き容量を増やすためのデータのアーカイブ、ビジネスの継続性のための Google Cloud へのデータの複製、分析と処理のための Google Cloud へのデータ転送などがあります。
権限を構成する
転送を作成する前に、次のエンティティの権限を構成する必要があります。
転送の作成に使用されるユーザー アカウント。これは、Google Cloud コンソールにログインするアカウント、または gcloud CLI の認証時に指定されたアカウントです。ユーザー アカウントは、通常のユーザー アカウントでも、ユーザーが管理するサービス アカウントでもかまいません。 | |
Storage Transfer Service で使用される Google 管理のサービス アカウント(サービス エージェントとも呼ばれる)。通常、このアカウントは、project-PROJECT_NUMBER@storage-transfer-service.iam.gserviceaccount.com という形式を使用するメールアドレスで識別されます。 |
|
転送エージェントに Google Cloud 権限を付与する転送エージェント アカウント。転送エージェント アカウントは、インストールしたユーザーの認証情報またはユーザー管理のサービス アカウントの認証情報を使用して認証を行います。 |
手順については、エージェント ベースの転送権限をご覧ください。
エージェント プールにエージェントをインストールする
エージェント ベースの転送では、ソフトウェア エージェントを使用して転送をオーケストレートします。これらのエージェントは、ファイル システムにアクセスできる 1 台以上のマシンにインストールする必要があります。エージェントは、名前ノード、すべてのデータノード、Hadoop 鍵管理サーバー(KMS)、Kerberos 鍵配布センター(KDC)にアクセスできる必要があります。
転送エージェントは、エージェント プール内で連携します。エージェント数を増やすとジョブの全体的なパフォーマンスが向上しますが、これはいくつかの要因によって異なります。
エージェントを追加すると、HDFS クラスタ内の最大半分のノード数を指定できます。たとえば、30 ノードクラスタでは、エージェントを 5 から 15 に増やすと、パフォーマンスは向上しますが、15 を超えても大きな違いはありません。
小規模な HDFS クラスタの場合は、1 つのエージェントで十分です。
転送に小さなファイルが多数含まれている場合、追加のエージェントがパフォーマンスに大きな影響を与える傾向があります。Storage Transfer Service では、複数のエージェント間で転送タスクを並列化することで、高スループットを実現します。ワークロード内のファイルが多いほど、エージェントの追加によるメリットが大きくなります。
エージェント プールの作成
エージェント プールの作成この操作には、ユーザー アカウント を使用します。
エージェントのインストール
エージェント プールにエージェントをインストールします。このアクションには、転送エージェント アカウント を使用します。
Google Cloud コンソール
Google Cloud コンソールで、[エージェント プール] ページに移動します。
新しいエージェントを追加するエージェント プールを選択します。
[エージェントをインストール] をクリックします。
表示された手順でエージェントをインストールして実行します。
エージェントのコマンドライン オプションの詳細については、エージェントのコマンドライン オプションをご覧ください。
gcloud CLI
gcloud CLI を使用して 1 つ以上のエージェントをインストールするには、gcloud transfer agents install
を実行します。
gcloud transfer agents install --pool=POOL_NAME \
--count=NUM_AGENTS \
--mount-directories=MOUNT_DIRECTORIES \
--hdfs-namenode-uri=HDFS_NAMENODE_URI \
--hdfs-username=HDFS_USERNAME \
--hdfs-data-transfer-protection=HDFS_DATA_TRANSFER_PROTECTION \
--kerberos-config-file=KERBEROS_CONFIG_FILE \
--kerberos-keytab-file=KERBEROS_KEYTAB_FILE \
--kerberos-user-principal=KERBEROS_USER_PRINCIPAL \
--kerberos-service-principal=KERBEROS_SERVICE_PRINCIPAL \
ここで
--hdfs-namenode-uri
は、スキーマ、名前ノード、ポートを含む HDFS クラスタを URI 形式で指定します。次に例を示します。rpc://my-namenode:8020
http://my-namenode:9870
WebHDFS に HTTP または HTTPS を使用します。スキーマが指定されていない場合は、RPC が使用されます。ポートが指定されていない場合、デフォルトは、RPC の場合は
8020
、HTTP の場合は9870
、HTTPS の場合は9871
になります。たとえば、入力my-namenode
はrpc://my-namenode:8020
になります。クラスタが複数の名前ノードで構成されている場合は、現在のプライマリ ノードを指定します。詳細については、複数の名前ノードを持つクラスタをご覧ください。
--hdfs-username
は、単純な認証で HDFS クラスタに接続するためのユーザー名です。Kerberos で認証する場合や、認証なしで接続する場合は、このフラグを省略します。--hdfs-data-transfer-protection
(省略可)は、Kerberos クラスタのクライアント側の保護品質(QOP)の設定です。この値は、サーバー側の QOP 値よりも制限する値は設定できません。有効な値はauthentication
とintegrity
とprivacy
です。
Kerberos で認証する場合は、次のフラグも指定します。
--kerberos-config-file
は、Kerberos 構成ファイルのパスです。例:--kerberos-config-file=/etc/krb5.conf
--kerberos-user-principal
は、使用する Kerberos ユーザー プリンシパルです。例:--kerberos-user-principal=user1
--kerberos-keytab-file
は、--kerberos-user-principal
フラグで指定されたユーザー プリンシパルを含む Keytab ファイルへのパスです。例:--kerberos-keytab-file=/home/me/kerberos/user1.keytab
--kerberos-service-principal
は、使用する Kerberos サービス プリンシパルです。形式は<primary>/<instance>
です。レルムは Kerberos 構成ファイルからマッピングされます。指定したレルムは無視されます。このフラグが指定されていない場合、デフォルトはhdfs/<namenode_fqdn>
です。ここで、<namenode_fqdn>
は構成ファイルで指定された完全修飾ドメイン名です。例:
--kerberos-service-principal=hdfs/my-namenode.a.example.com
手順に沿って、エージェントのインストール手順を確認します。このコマンドを実行すると、POOL_NAME として指定したプール名にマッピングされた NUM_AGENTS エージェントがマシンにインストールされ、gcloud
認証情報を使用してエージェントが認証されます。存在するプール名を使用する必要があります。存在しない場合、エラーが返されます。
--mount-directories
フラグは省略可能ですが、使用することを強くおすすめします。この値は、エージェントにアクセス権を付与するファイル システム上のディレクトリのカンマ区切りのリストです。このフラグを省略すると、ファイル システム全体がエージェント コンテナにマウントされます。詳細については、gcloud
のリファレンスをご覧ください。
docker run
docker run
を使用してエージェントをインストールする前に、手順に沿って Docker をインストールしてください。
docker run
コマンドにより、1 つのエージェントがインストールされます。プール内のエージェント数を増やすには、このコマンドを必要な回数だけ再実行します。
必要なコマンドフラグは、使用している認証タイプによって異なります。
Kerberos
Kerberos を使用してファイル システムを認証するには、次のコマンドを使用します。
sudo docker run -d --ulimit memlock=64000000 --rm \
--network=host \
-v /:/transfer_root \
gcr.io/cloud-ingest/tsop-agent:latest \
--enable-mount-directory \
--project-id=${PROJECT_ID} \
--hostname=$(hostname) \
--creds-file="service_account.json" \
--agent-pool=${AGENT_POOL_NAME} \
--hdfs-namenode-uri=cluster-namenode \
--kerberos-config-file=/etc/krb5.conf \
--kerberos-user-principal=user \
--kerberos-keytab-file=/path/to/folder.keytab
ここで
- このマシンで複数のエージェントを実行している場合は、
--network=host
を省略する必要があります。 --hdfs-namenode-uri
: HDFS クラスタを表す、URI 形式のスキーマ、namenode、ポート。次に例を示します。rpc://my-namenode:8020
http://my-namenode:9870
WebHDFS に HTTP または HTTPS を使用します。スキーマが指定されていない場合は、RPC が使用されます。ポートが指定されていない場合、デフォルトは、RPC の場合は 8020
、HTTP の場合は 9870
、HTTPS の場合は 9871
になります。たとえば、入力 my-namenode
は rpc://my-namenode:8020
になります。
クラスタが複数の名前ノードで構成されている場合は、現在のプライマリ ノードを指定します。詳細については、複数の名前ノードを持つクラスタをご覧ください。
--kerberos-config-file
: Kerberos 構成ファイルへのパス。デフォルトは/etc/krb5.conf
です。--kerberos-user-principal
: Kerberos ユーザー プリンシパル。--kerberos-keytab-file
:--kerberos-user-principal
で指定されたユーザー プリンシパルを含む Keytab ファイルへのパス。--kerberos-service-principal
: 使用する Kerberos サービス プリンシパル。「サービス/インスタンス」の形式です。レルムは Kerberos 構成ファイルからマッピングされます。指定したレルムは無視されます。このフラグが指定されていない場合、デフォルトはhdfs/<namenode_fqdn>
です。ここで、fqdn
は完全修飾ドメイン名です。
シンプルな認証
単純な認証を使用してファイル システムに対する認証を行うには、次のようにします。
sudo docker run -d --ulimit memlock=64000000 --rm \
--network=host \
-v /:/transfer_root \
gcr.io/cloud-ingest/tsop-agent:latest \
--enable-mount-directory \
--project-id=${PROJECT_ID} \
--hostname=$(hostname) \
--creds-file="${CREDS_FILE}" \
--agent-pool="${AGENT_POOL_NAME}" \
--hdfs-namenode-uri=cluster-namenode \
--hdfs-username="${USERNAME}"
ここで
--hdfs-username
: 単純な認証を使用して HDFS クラスタに接続するときに使用するユーザー名。--hdfs-namenode-uri
: HDFS クラスタを表す、URI 形式のスキーマ、namenode、ポート。たとえば、次のような情報が得られます。rpc://my-namenode:8020
http://my-namenode:9870
WebHDFS に HTTP または HTTPS を使用します。スキーマが指定されていない場合は、RPC が使用されます。
ポートが指定されていない場合、デフォルトは、RPC の場合は 8020
、HTTP の場合は 9870
、HTTPS の場合は 9871
です。たとえば、入力 my-namenode
は rpc://my-namenode:8020
になります。
クラスタが複数の名前ノードで構成されている場合は、現在のプライマリ ノードを指定します。詳細については、複数の名前ノードを持つクラスタをご覧ください。
認証なし
認証なしでファイル システムに接続するには:
sudo docker run -d --ulimit memlock=64000000 --rm \
--network=host \
-v /:/transfer_root \
gcr.io/cloud-ingest/tsop-agent:latest \
--enable-mount-directory \
--project-id=${PROJECT_ID} \
--hostname=$(hostname) \
--creds-file="${CREDS_FILE}" \
--agent-pool="${AGENT_POOL_NAME}" \
--hdfs-namenode-uri=cluster-namenode \
ここで
--hdfs-namenode-uri
: HDFS クラスタを表す、URI 形式のスキーマ、namenode、ポート。たとえば、次のような情報が得られます。rpc://my-namenode:8020
http://my-namenode:9870
WebHDFS に HTTP または HTTPS を使用します。スキーマが指定されていない場合は、RPC が使用されます。
ポートが指定されていない場合、デフォルトは、RPC の場合は 8020
、HTTP の場合は 9870
、HTTPS の場合は 9871
です。たとえば、入力 my-namenode
は rpc://my-namenode:8020
になります。
クラスタが複数の名前ノードで構成されている場合は、現在のプライマリ ノードを指定します。詳細については、複数の名前ノードを持つクラスタをご覧ください。
転送オプション
HDFS から Cloud Storage への転送では、次の Storage Transfer Service 機能を使用できます。
HDFS から転送されたファイルには、メタデータが保持されません。
転送を作成
転送ジョブ名に、個人を特定できる情報(PII)やセキュリティ データなどの機密情報を含めないでください。リソース名は、他の Google Cloud リソースの名前に反映され、プロジェクト外部の Google 内部システムに公開される場合があります。
Storage Transfer Service には、転送を作成するための複数のインターフェースが用意されています。
Google Cloud コンソール
Google Cloud コンソールのストレージの [Data Transfer] ページに移動します。
[転送ジョブを作成] をクリックします。[転送ジョブの作成] ページが表示されます。
[ソースタイプ] として [Hadoop Distributed File System] を選択します。宛先は Google Cloud Storage にする必要があります。
[次のステップ] をクリックします。
ソースを構成する
この転送に必要な情報を指定します。
この転送に構成したエージェント プールを選択します。
転送元のパス(ルート ディレクトリからの相対パス)を入力します。
必要に応じて、ソースデータに適用するフィルタを指定します。
[次のステップ] をクリックします。
シンクを構成する
[バケットまたはフォルダ] フィールドに、ソースバケットと(必要に応じて)フォルダ名を入力するか、[参照] をクリックして、現在のプロジェクトにある既存のバケットリストからバケットを選択します。新しいバケットを作成するには、[新しいバケットを作成] をクリックします。
[次のステップ] をクリックします。
転送のスケジュールを設定する
転送は 1 回だけ実行するようにスケジュールすることも、定期的な転送を構成することもできます。
[次のステップ] をクリックします。
転送の設定を選択する
[説明] フィールドに、転送の説明を入力します。ジョブを区別できるように、意味のある一意の説明を入力することをおすすめします。
[メタデータのオプション] で、Cloud Storage ストレージ クラスと各オブジェクトの作成時間を保存するかどうかを選択します。詳細については、メタデータの保持をご覧ください。
[上書きの条件] で、次のいずれかを選択します。
なし: 宛先ファイルを上書きしません。同じ名前のファイルが存在する場合は転送されません。
異なる場合: ソースファイルの名前が同じで ETag またはチェックサムの値が異なる場合、宛先ファイルを上書きします。
常に: ソースファイルが同じ名前の場合、同一であっても常に宛先ファイルを上書きします。
[削除のタイミング] で、次のいずれかを選択します。
なし: ソースと宛先のどちらからもファイルを削除しません。
転送元にもないファイルを転送先から削除する: 転送先の Cloud Storage バケット内のファイルが転送元にもない場合は、Cloud Storage バケットからファイルを削除します。
このオプションにより、宛先の Cloud Storage バケットが移行元と完全に一致することが保証されます。
転送ロギングと Pub/Sub 通知を有効にするかどうかを選択します。
[作成] をクリックして転送を作成します。
gcloud CLI
新しい転送ジョブを作成するには、gcloud transfer jobs create
コマンドを使用します。スケジュールまたは --do-not-run
が指定されていない限り、新しいジョブを作成すると、指定された転送が開始します。
gcloud transfer jobs create \
hdfs:///PATH/ gs://BUCKET_NAME/PATH/
--source-agent-pool=AGENT_POOL_NAME
ここで
PATH
は、HDFS クラスタのルートからの絶対パスです。クラスタ名ノードとポートはエージェント レベルで構成されるため、ジョブ作成コマンドで指定する必要があるのは、(オプションの)パスとエージェント プールのみです。--source-agent-pool
には、この転送に使用するソース エージェント プールを指定します。
上記以外に次のようなオプションがあります。
--do-not-run
は、コマンドの送信時に Storage Transfer Service がジョブを実行しないようにします。ジョブを実行するには、更新してスケジュールを追加するか、jobs run
を使用して手動で開始します。--manifest-file
には、ソースから転送するファイルのリストを含む Cloud Storage 内の CSV ファイルのパスを指定します。マニフェスト ファイルの形式については、マニフェストを使用して特定のファイルまたはオブジェクトを転送するをご覧ください。ジョブ情報:
--name
と--description
を指定できます。スケジュール:
--schedule-starts
、--schedule-repeats-every
、--schedule-repeats-until
、または--do-not-run
を指定します。オブジェクト条件: 条件を使用して、転送するオブジェクトを決定します。これには、
--include-prefixes
と--exclude-prefixes
、--include-modified-[before | after]-[absolute | relative]
の時間ベースの条件が含まれます。ソースでフォルダを指定した場合、接頭辞フィルタはそのフォルダを基準とします。詳細については、ソース オブジェクトを前方一致でフィルタするをご覧ください。転送オプション: 宛先ファイルを上書き (
--overwrite-when=different
またはalways
) するかどうか、および転送中または転送後に特定のファイルを削除 (--delete-from=destination-if-unique
またはsource-after-transfer
) するかどうかを指定します。オプションで、転送されたオブジェクトにストレージ クラスを設定 (--custom-storage-class
) します。通知:
--notification-pubsub-topic
、--notification-event-types
、--notification-payload-format
を使用して、転送の Pub/Sub 通知を構成します。
すべてのオプションを表示するには、gcloud transfer jobs create --help
を実行するか、gcloud
リファレンス ドキュメントをご覧ください。
REST API
REST API を使用して HDFS ソースから転送を作成するには、次のような JSON オブジェクトを作成します。
POST https://storagetransfer.googleapis.com/v1/transferJobs
{
...
"transferSpec": {
"source_agent_pool_name":"POOL_NAME",
"hdfsDataSource": {
"path": "/mount"
},
"gcsDataSink": {
"bucketName": "SINK_NAME"
},
"transferOptions": {
"deleteObjectsFromSourceAfterTransfer": false
}
}
}
サポートされているその他のフィールドについては、transferJobs.create
のリファレンスをご覧ください。
複数の NameNode を持つクラスタ
Storage Transfer Service エージェントは、1 つの名前ノードでのみ構成できます。HDFS クラスタが複数の NameNode(「高可用性」)で構成され、フェイルオーバー イベントによって新しいプライマリ ネームノードが作成される場合は、正しい名前ノードを使用してエージェントを再インストールする必要があります。
古いエージェントを削除するには、エージェントを削除するをご覧ください。
次のコマンドを実行すると、クラスタのアクティブな Namespace を取得できます。
hdfs haadmin -getAllServiceState