고급 옵션

이 문서에서는 다음을 포함한 파일 시스템 전송의 고급 설정 옵션을 설명합니다.

CIFS 또는 SMB 볼륨에 데이터 복사
서비스 계정 사용자 인증 정보 사용
최대 에이전트 메모리 조정
에이전트 디렉터리 액세스 제한
Kubernetes와 에이전트 조정
전달 프록시 사용
보관 정책이 적용된 버킷에 복사
네트워크 대역폭을 더 많이 확보하기 위한 옵션

CIFS 또는 SMB 볼륨에 데이터 복사

전송 에이전트는 Windows 서버에서 직접 지원되지 않습니다. 그러나 POSIX 규격 파일 시스템에 저장된 데이터를 Linux 서버나 가상 머신(VM)에 마운트한 다음 Linux 서버 또는 VM에서 에이전트를 실행하면 데이터를 Cloud Storage에 복사할 수 있습니다.

CIFS 또는 SMB 볼륨에서 데이터를 이동하려면 다음 안내를 따르세요.

Linux 서버 또는 VM을 프로비저닝합니다.

지원되는 운영체제는 기본 요건을 참조하세요.
프로비저닝한 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 볼륨의 승인된 사용자의 비밀번호입니다.
다음 명령어를 실행하여 CIFS 볼륨이 마운트되었는지 확인합니다.
```
findmnt -l
```
에이전트를 실행할 사용자가 다음 명령어를 실행하여 마운트된 볼륨의 파일을 나열하고 복사할 수 있는지 확인합니다.
```
sudo -u USERNAME cp /mnt/FILE1 /mnt/FILE2
```
다음을 바꿉니다.
- USERNAME: 에이전트를 실행할 사용자입니다.
- FILE1: 복사할 원본 파일입니다.
- FILE2: 복사할 대상 파일 이름입니다.
전송 에이전트를 설치합니다.

서비스 계정 사용자 인증 정보 사용

서비스 계정 사용자 인증 정보를 사용하여 에이전트를 실행할 수 있습니다. 서비스 계정 사용자 인증 정보를 사용하면 단일 사용자 계정을 사용하지 않고 전송 에이전트를 인증할 수 있습니다. 계정 유형에 대한 자세한 내용은 주 구성원을 참조하세요.

서비스 계정 키를 만듭니다. 자세한 내용은 서비스 계정 키 생성 및 관리를 참조하세요.
서비스 키 위치를 에이전트 생성 명령어에 전달합니다.
```
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 플래그로 지정할 필요가 없습니다.

최대 에이전트 메모리 조정

전송 에이전트는 기본적으로 최대 8GiB 시스템 메모리를 사용합니다. --max-physical-mem=MAXIMUM-MEMORY를 전달하고 MAXIMUM-MEMORY를 사용자 환경에 적합한 값으로 바꿔 에이전트가 사용하는 최대 메모리를 조정할 수 있습니다.

다음은 Transfer Service for On Premises Data 에이전트의 메모리 요구사항입니다.

최소 메모리: 1GiB
고성능 업로드를 지원하기 위한 최소 메모리: 6GiB

기본값 8GiB를 사용하는 것이 좋습니다.

다음 표에서는 MAXIMUM-MEMORY에 허용되는 형식의 예시를 설명합니다.

`max-physical-mem`값	최대 메모리 설정
`6g`	6GB
`6gb`	6GB
`6GiB`	6GB

에이전트 디렉터리 액세스 제한

전송 작업을 만들 수 있는 사용자는 에이전트가 액세스할 수 있는 모든 파일 시스템 디렉터리에서 데이터를 검색하고 다운로드할 수 있습니다.

에이전트가 루트로 실행되고 전체 파일 시스템에 대한 액세스 권한이 부여되면 악의적인 행위자가 호스트를 인계받을 수 있습니다. 필요한 에이전트로만 에이전트 액세스를 제한하는 것이 좋습니다.

특정 디렉터리에 대한 에이전트의 액세스를 제한하려면 다음 안내를 따르세요.

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 관점에서 에이전트 컨테이너는 스테이트리스(Stateless) 애플리케이션으로 간주되므로 스테이트리스(Stateless) 애플리케이션 배포를 위한 Kubernetes 안내를 따를 수 있습니다.

Cloud Interconnect에서 비공개 API 엔드포인트 사용

Cloud Interconnect에서 비공개 API 엔드포인트를 사용하려면 다음 단계를 따르세요.

에이전트를 실행하려는 온프레미스 호스트에 로그인합니다.
비공개 Google 액세스를 구성합니다. 자세한 내용은 온프레미스 호스트의 비공개 Google 액세스 구성을 참조하세요.
Cloud Storage API에 연결할 수 있는지 확인합니다.
1. Cloud Storage API의 경우 전송 에이전트와 동일한 머신에서 gsutil 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로 지정됩니다.

보관 정책이 적용된 버킷에 복사

보관 정책이 적용된 버킷으로 전송하려면 다음 프로세스를 수행하는 것이 좋습니다.

최종 버킷과 동일한 리전 내에 Cloud Storage 버킷을 만듭니다. 이 임시 버킷에 보관 정책이 적용되지 않았는지 확인합니다.

리전에 대한 자세한 내용은 버킷 위치를 참조하세요.
Storage Transfer Service를 사용하여 보관 정책 없이 만든 임시 버킷으로 데이터를 전송합니다.
버킷 간 전송을 수행하여 보관 정책이 적용된 버킷으로 데이터를 전송합니다.
데이터를 임시로 저장하기 위해 만든 Cloud Storage 버킷을 삭제합니다.

네트워크 대역폭을 더 많이 확보하기 위한 옵션

파일 시스템 전송을 위해 더 많은 네트워크 대역폭을 얻을 수 있는 몇 가지 옵션이 있습니다. 네트워크 대역폭을 늘리면 특히 대용량 데이터 세트의 전송 시간을 줄일 수 있습니다.

Google을 통한 피어링—피어링은 Google과 직접 상호 연결하여 트래픽 교환을 지원합니다. 전 세계에 다이렉트 피어링 위치가 있습니다. 이점 및 Google 정책에 대한 자세한 내용은 피어링을 참조하세요.
Cloud Interconnect -Cloud Interconnect는 피어링과 비슷하지만 상호 연결을 사용하여 Google에 연결합니다. 상호 연결에 선택할 수 있는 유형에는 두 가지가 있습니다.
- Dedicated Interconnect— 비공개 전용 연결을 통해 데이터 센터에서 Google 데이터 센터로 직접 연결합니다. 자세한 내용은 Dedicated Interconnect 개요를 참조하세요.
- Partner Interconnect—서비스 제공업체와 협력하여 서비스 파트너의 네트워크를 통해 Google 데이터 센터에 연결합니다. 자세한 내용은 Partner Interconnect 개요를 참조하세요.
ISP로부터 대역폭 가져오기—인터넷 서비스 제공업체(ISP)가 니즈에 맞게 더 많은 대역폭을 제공할 수 있습니다. 어떤 옵션을 사용할 수 있는지 문의하세요.