Storage Transfer Service는 클라우드 및 온프레미스 Hadoop 분산 파일 시스템(HDFS) 소스에서 전송을 지원합니다.
HDFS에서 전송에서는 Cloud Storage를 대상으로 사용해야 합니다.
사용 사례에는 온프레미스 스토리지에서 Cloud Storage로 마이그레이션, 데이터 보관처리로 온프레미스 저장공간 확보, 비즈니스 연속성을 위해 Google Cloud에 데이터 복제, 분석 및 처리를 위해 Google Cloud로 데이터 전송 등이 포함됩니다.
권한 구성
전송을 만들기 전에 다음 항목에 대한 권한을 구성해야 합니다.
전송을 만드는 데 사용되는 사용자 계정. 이 계정은 Google Cloud 콘솔에 로그인된 계정이거나 `gcloud` CLI에 인증할 때 지정된 계정입니다. 사용자 계정은 일반 사용자 계정이나 사용자 관리형 서비스 계정일 수 있습니다. | |
Google 관리 서비스 계정은 서비스 에이전트라고도 하며 Storage Transfer Service에서 사용됩니다. 이 계정은 일반적으로 project-PROJECT_NUMBER@storage-transfer-service.iam.gserviceaccount.com 형식을 사용하는 이메일 주소로 식별됩니다.
|
|
전송 에이전트에 Google Cloud 권한을 제공하는 전송 에이전트 계정. 전송 에이전트 계정은 설치하는 사용자의 사용자 인증 정보나 사용자 관리형 서비스 계정의 사용자 인증 정보를 사용하여 인증합니다. |
자세한 내용은 에이전트 기반 전송 권한을 참조하세요.
에이전트 풀에 에이전트 설치
에이전트 기반 전송은 소프트웨어 에이전트를 사용하여 전송을 조정합니다. 이러한 에이전트는 파일 시스템에 대한 액세스 권한이 있는 머신 하나 이상에 설치해야 합니다. 에이전트는 이름 노드, 모든 데이터 노드, Hadoop 키 관리 서버(KMS), Kerberos 키 배포 센터(KDC)에 액세스할 수 있어야 합니다.
전송 에이전트는 에이전트 풀에서 함께 작동합니다. 에이전트 수를 늘리면 전반적인 작업 성능이 향상될 수 있지만 이는 몇 가지 요인에 따라 달라집니다.
에이전트를 추가하면 HDFS 클러스터에 있는 노드 수의 최대 절반 정도가 도움이 될 수 있습니다. 예를 들어 노드가 30개인 클러스터를 사용하는 경우 에이전트를 5개에서 15개로 늘리면 성능이 향상되지만, 15개를 초과하면 큰 차이는 없을 수 있습니다.
소규모 HDFS 클러스터의 경우 에이전트 하나만으로 충분할 수 있습니다.
전송에 작은 파일이 다수 포함된 경우 추가 에이전트가 성능에 더 큰 영향을 미칠 수 있습니다. Storage Transfer Service는 여러 에이전트 간에 전송 태스크를 병렬 처리하여 높은 처리량을 달성합니다. 워크로드에 파일이 많을수록 에이전트 추가하는 것이 도움이 됩니다.
에이전트 풀 만들기
에이전트 풀을 만듭니다. 이 작업의 사용자 계정 을 사용합니다.
에이전트 설치
에이전트 풀에 에이전트를 설치합니다. 이 작업의 전송 에이전트 계정 을 사용합니다.
Google Cloud 콘솔
Google Cloud 콘솔에서 에이전트 풀 페이지로 이동합니다.
새 에이전트를 추가할 에이전트 풀을 선택합니다.
에이전트 설치를 클릭합니다.
안내를 따라 에이전트를 설치 및 실행합니다.
에이전트의 명령줄 옵션에 대한 자세한 내용은 에이전트 명령줄 옵션을 참조하세요.
gcloud CLI
gcloud CLI를 사용하여 하나 이상의 에이전트를 설치하려면 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
명령어는 에이전트 하나를 설치합니다. 풀의 에이전트 수를 늘리려면 이 명령어를 필요한 횟수만큼 다시 실행합니다.
필수 명령어 플래그는 사용 중인 인증 유형에 따라 달라집니다.
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 형식의 스키마, 이름 노드, 포트입니다. 예를 들면 다음과 같습니다.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 형식의 스키마, 이름 노드, 포트입니다. 예를 들면 다음과 같습니다.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 형식의 스키마, 이름 노드, 포트입니다. 예를 들면 다음과 같습니다.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 콘솔의 Storage Transfer Service 페이지로 이동합니다.
전송 작업 만들기를 클릭합니다. 전송 작업 만들기 페이지가 표시됩니다.
Hadoop 분산 파일 시스템을 소스 유형으로 선택합니다. 대상 위치는 Google Cloud Storage여야 합니다.
다음 단계를 클릭합니다.
소스 구성
이 전송에 필요한 정보를 지정합니다.
이 전송에 대해 구성한 에이전트 풀을 선택합니다.
루트 디렉터리를 기준으로 전송할 경로를 입력합니다.
필요한 경우 소스 데이터에 적용할 필터를 지정합니다.
다음 단계를 클릭합니다.
싱크 구성
버킷 또는 폴더 필드에 대상 버킷과 폴더 이름(선택사항)을 입력하거나 찾아보기를 클릭하여 현재 프로젝트의 기존 목록에서 버킷을 선택합니다. 새 버킷을 만들려면 새 버킷 만들기를 클릭합니다.
다음 단계를 클릭합니다.
전송 예약
전송을 한 번만 실행하도록 예약하거나 반복 전송을 구성할 수 있습니다.
다음 단계를 클릭합니다.
전송 설정 선택
설명 필드에 전송 설명을 입력합니다. 작업을 구분할 수 있도록 의미 있고 고유한 설명을 입력하는 것이 좋습니다.
메타데이터 옵션에서 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
참조를 확인하세요.
이름 노드가 여러 개 있는 클러스터
Storage Transfer Service 에이전트는 단일 이름 노드로만 구성될 수 있습니다. HDFS 클러스터가 이름 노드 여러 개('고가용성')로 구성되었고 장애 조치 이벤트로 인해 새로운 기본 이름 노드가 발생하면 올바른 이름 노드로 에이전트를 다시 설치해야 합니다.
이전 에이전트를 삭제하려면 에이전트 삭제를 참조하세요.
다음을 실행하여 클러스터의 활성 이름 노드를 검색할 수 있습니다.
hdfs haadmin -getAllServiceState