[Project] - Datasync + storage gateway로 실시간 싱크-1

목표 : 온프레미스 스토리지와 aws클라우드상 S3 버킷의 실시간 데이터 싱크

 

방식 : AWS DataSync를 사용하여 온프레미스 NFS 서버에서 Amazon S3로 데이터를 마이그레이션하고

AWS Storage Gateway를 사용하여 S3에 있는 데이터를 온프레미스에서 NFS 액세스하여 사용.

 

 

 

공식 datasync 문서

https://aws.amazon.com/ko/datasync/faqs/

 

공식 storage gateway 문서

https://aws.amazon.com/ko/storagegateway/faqs/

 

 

datasync와 storage gateway 차이 비교 요약

	데이터싱크	스토리지 게이트웨이
설명	AWS DataSync는 인터넷 또는 AWS Direct Connect를 통해 AWS 스토리지 서비스에서 대량의 데이터를 복사하는 프로세스를 간소화, 자동화 및 가속화하는 온라인 데이터 전송 서비스입니다.	AWS Storage Gateway는 클라우드 스토리지를 S3에 연결하여 사실상 무제한의 클라우드 스토리지에 대한 온프레미스 액세스를 제공하는 하이브리드 클라우드 스토리지 서비스입니다. Storage Gateway는 온프레미스 애플리케이션을 위한 3가지 유형의 스토리지 인터페이스인 파일, 볼륨 및 테이프를 제공합니다.
작동 방식	사용자가 소유하고 스토리지 시스템에서 데이터를 읽거나 쓰는 데 사용되는 가상 머신(VM)인 에이전트를 사용합니다 . 관리 콘솔에서 에이전트를 활성화할 수 있습니다. 그런 다음 에이전트는 소스 위치에서 데이터를 읽고 데이터를 Amazon S3, Amazon EFS 또는 Amazon Fsx for Windows File Server와 동기화합니다.	데이터 센터에 설치 및 호스팅되는 Amazon의 VM인 Storage Gateway Appliance를 사용합니다 . 설정 후 AWS 콘솔을 사용하여 데이터가 Amazon S3에 저장되는 파일 게이트웨이, 캐시 볼륨 또는 저장 볼륨과 같은 스토리지 옵션을 프로비저닝할 수 있습니다. VM을 설치하는 대신 전송을 용이하게 하기 위해 하드웨어 어플라이언스를 구입할 수도 있습니다.
프로토콜	DataSync는 표준 스토리지 프로토콜(NFS, SMB)을 사용하거나 Amazon S3 API를 사용하여 기존 스토리지 시스템 및 데이터 소스에 연결합니다.	Storage Gateway는 iSCSI, SMB 및 NFS와 같은 표준 스토리지 프로토콜 세트를 제공합니다.
저장	AWS DataSync는 NFS(네트워크 파일 시스템), SMB 파일 서버 또는 자체 관리 객체 스토리지 간에 데이터를 복사할 수 있습니다. 또한 온프레미스 스토리지와 AWS Snowcone, Amazon S3, Amazon EFS 또는 Amazon FSx 간에 데이터를 이동할 수 있습니다.	파일 게이트웨이를 사용하면 NFS 및 SMB와 같은 파일 프로토콜을 사용하여 Amazon S3에서 객체를 저장하고 검색할 수 있습니다. 볼륨 게이트웨이는 데이터를 게이트웨이에 로컬로 저장하고 Amazon S3에 동기화합니다. 또한 EBS 스냅샷을 사용하여 볼륨의 특정 시점 복사본을 생성하여 iSCSI 장치로 어플라이언스에 마운트할 수 있습니다.  테이프 게이트웨이 데이터는 Amazon S3에 즉시 저장되며 Amazon S3 Glacier 또는 Amazon S3 Glacier Deep Archive에 보관할 수 있습니다.
가격	Amazon S3, Amazon EFS, AmazonFSx for Windows File Server 및 AWS KMS와 같은 AWS 서비스에서 읽고 쓰기 위한 표준 요청, 스토리지 및 데이터 전송 요금이 부과됩니다.	사용하는 스토리지의 유형과 양, 수행하는 요청 및 AWS 외부로 전송되는 데이터 양에 따라 요금이 부과됩니다.
콤비네이션	DataSync와 파일 게이트웨이의 조합을 사용하여 온프레미스 애플리케이션을 클라우드 스토리지에 원활하게 연결하면서 온프레미스 운영 비용을 최소화할 수 있습니다. AWS DataSync를 사용하면 AWS 스토리지 서비스로의 온라인 데이터 전송을 자동화하고 가속화할 수 있습니다. 그런 다음 파일 게이트웨이는 마이그레이션된 데이터에 대한 액세스 대기 시간이 짧은 온프레미스 애플리케이션을 제공합니다.

 

 

 

 

참고용 공식 실습자료

https://catalog.us-east-1.prod.workshops.aws/datasync-nfs-server-migration-with-storage-gateway/en-US

 

나의 경우에는 진짜 찐 온프레미스랑 클라우드 사이에서 데이터싱크를 진행할것이므로

위 실습자료랑 좀 달리 간다. (실습자료는 온프레미스 생색만 낸 클라우드 to 클라우드다..)

 

 

AWS DataSync 에이전트 배포 (vmware등)

https://docs.aws.amazon.com/datasync/latest/userguide/deploy-agents.html

 

 

https://docs.aws.amazon.com/datasync/latest/userguide/datasync-in-vpc.html

 

 

 

TCP 443 = https

UDP123 = NTP

TCP/UDP 53 = DNS

TCP/UDP 2049 = NFS

 

 

 

0. nfs-server 구축

위 토폴로지 보고, agent가 마운트할 디렉토리가 있는 nfs-server를 구축해서

2049번 포트로 리스닝 하고있는 서버를 한대 마련한다.

 

 

 

1. DataSync Agent 설치

 

이미지 다운로드 링크 눌러서 ova파일 받고

vmware에서 해당 머신 실행.

 

AWS CLI를 사용하여 AWS DataSync 에이전트 생성 문서

https://docs.aws.amazon.com/datasync/latest/userguide/create-agent-cli.html

 

여기 보면 기본 OVA 자격 증명은 admin, password라고 한다.

치고 들어가니까 음.. 이건 모바엑스텀으로 들어가기 힘들겠는데...?

192.168.0.17

 

 

 

2. DataSync Agent 설정

 

Datasync Agent 설정 모범 사례. (내용중 로컬 콘솔이라는 링크 누르면 로컬cli 창에서 해야되는 명령어 보기 가능)

https://aws.amazon.com/ko/blogs/storage/best-practices-for-setting-up-your-aws-datasync-agent/

 

AWS DataSync 네트워크 요구 사항을 참조해서 설정해보자.

https://docs.aws.amazon.com/datasync/latest/userguide/datasync-network.html

 

 

우선 내 토폴로지는 어플단 서버가 NFS 클라이언트고, 진짜 데이터가 저장된 스토리지 서버가 NFS 서버다.

그리고 그 NFS 서버의 해당 디렉토리를 통째로 또 Datasync 에이전트에서 마운트할것이다.

아래 그림 참조

 

 

설정 순서

• 시스템 리소스 확인
• 네트워크 연결 확인
• 에이전트 활성화 키 가져오기
• 에이전트가 활성화된 에이전트 ID 및 AWS 리전 보기

 

시스템 리소스 확인

DataSync 에이전트는 충분한 리소스가 할당되었는지 자동으로 확인한다.

부팅 시 시스템 리소스 검사 중에 오류가 발견되면 에이전트는 로컬 콘솔에 로그인하는 즉시 빨간색 배너를 표시한다.

가상 프로세서 수, 디스크 공간 크기, 에이전트 VM에 할당된 RAM 크기 등이 적합한지 확인한다.

아래 빨간색 배너에서 2코어밖에 없다고 잔소리를 한다.

 

오류가 감지되면 시스템 리소스 확인 보기를 선택하여 모든 인프라 진단을 더 자세히 볼 수 있다.

4번을 입력해서 자세한 설명을 더 보면 코어 4개가 최소 요구사항임을 알수있다.

VMware를 조작해서 4코어로 올려주자

 

반영시키려면 VMware 머신을 재시작 해줘야한다.

짜잔 아래와같이 빨간 경고창이 사라졌다. 노란색 경고는 넘어가보자.

 

 

 

네트워크 연결 확인

에이전트에 적절한 호스트 시스템 리소스가 있음을 확인했으니 다음으로 확인할 항목은 네트워크 연결이다.

AWS DataSync 에이전트는 서비스 엔드포인트를 사용하여 AWS와 통신한다.

• 퍼블릭 서비스 엔드포인트,
• FIPS(Federal Information Processing Standard) 엔드포인트
• Amazon Virtual Private Cloud(VPC) 엔드포인트 (AWS PrivateLink)

이 세가지 유형의 엔드포인트에 에이전트쪽에서 연결할 수 있다.

엔드포인트에 대해 에이전트는 특정 네트워크 포트를 통해 AWS와 통신할 수 있어야 한다.

Amazon VPC 엔드포인트를 사용하는 경우 에이전트는 DataSync 서비스 사용에 인터넷에 연결할 필요가 없다.

에이전트는 VPC 엔드포인트에 대한 트래픽만 허용하는 것이 이상적이다.

 

Datasync 에이전트에 대한 서비스 엔드포인트 선택과 각자 연결법

https://docs.aws.amazon.com/datasync/latest/userguide/choose-service-endpoint.html

 

잘 모르겠고 해봐야 정확하게 알겠지만,

읽어보고 난 뒤 느낀바론 vpc AWS PrivateLink 엔드포인트는 VPN 및 AWS Direct Connect를 통해 온프레미스에 있거나 VPC 피어링을 통해 다른 AWS 리전에 있는 애플리케이션에서 직접 액세스할 때 쓰는 것 같다.

VPN 쪽은 한번 실패했어서 퍼블릭 서비스 엔드포인트로 골랐다.

 

 

 

퍼블릭 엔드 포인트 생성

 

에이전트 상단에 띄워진 인터넷 ip를 입력해준다.

이렇게 하지 않고 에이전트 쪽에서 0번을 입력해 활성화키를 직접 얻어 여기에 수동으로 입력할 수도 있다.

 

연결 수립

 

에이전트 쪽에서 2번을 입력해 aws 엔드포인트와 네트워킹이 잘 되나 확인한다.

원래는 엔드포인트 종류를 고르는 123번 선택지가 뜨는데,

나는 위에서 이미 에이전트-엔드포인트 연결을 수립해버려서 바로 파블릭 엔드포인트라고 확정돼서 뜬다.

암튼 다 패스하는거 보니까 정상인가보다.

 

 

 

 

 

 

3.  AWS DataSync의 소스 위치 생성

 

https://docs.aws.amazon.com/datasync/latest/userguide/configure-source-location.html

 

머신을 바꿔서 에이전트 주소가 192.168.38.66 로 바뀌었다.

정품 인증 키 BR6JK-OTC7T-GLHLK-BO9KS-39TPF

 

 

 

온프레 스토리지 위치 (NFS서버) 192.168.108.3

 

확인용으로 대충 nfs 서버인척 마운트용 디렉토리 하나 만들기.

내용물도 그냥 touch로 두개 만들어놨다.

 

 

온프레미스 NFS 서버의 위치를 ​​생성

이제 온프레쪽 소스 위치를 aws gui에 입력해주자.

 

 

클라우드의 S3 위치 생성

 

폴더 항목에 "/"를 입력하면 모든 파일이 버킷의 최상위 수준으로 복사된다.

 

 

아래 IAM 역할은 S3조작에 대한 권한을 datasync 서비스에 부여해줘야하는데, 자동생성 누르면 편하다.

자동생성 버튼 누르고 IAM으로 한번 찾아가서 어떤 권한을 만들었나 살펴보자.

 

대충 요약하면 목록, 읽기, 쓰기, 태그 지정, 리소스 여러개 사용 가능 정도의 권한이다.

 

두 개의 위치가 만들어졌다. 하나는 NFS 서버용이고 다른 하나는 S3 버킷용이다.

 

 

 

 

4. 태스크 생성

 

이전에 했던 DMS 서비스랑 되게 비슷한 구성과정인 느낌이다.

온프레미스와 클라우드 네트워크를 연결한 다음, 양쪽 엔드포인트를 정의하고 (이경우 NFS쪽과 S3버킷)

그다음에 task (어떤 작업을 할지)를 만들어서 돌리는 구조이다.

 

 

 

일정은 만약 사용자 지정으로 선택한다면 크론 (cron) 형식으로 지정할 수 있는데,

그러면 설정 가능한 최소 주기가 1시간이라 너무 RPO가 길다. 

그래서 예약하지 않겠다.

 

 

작업 상태가 "사용 가능"으로 보고될 때까지 기다린뒤, 준비 되면 시작버튼을 눌러 기본값으로 시작한다.

 

작업은 즉시 "실행 중" 상태로 전환

 

 

 

 

 

 

 

5. 트러블슈팅

 

아래와 같이 기록 탭이 생겼다.

 

작업이 실행되면 실행 상태가 "실행 중"에서 "준비 중", "전송 중", "확인 중", 마지막으로 "성공"으로 진행된다.

근데 아래처럼 시작중이 뜨더니

한참 기다렸는데 시작중이란 상태에서 다음으로 못넘어가고 오류를 띄웠다.

심지어 클라우드워치에서도 진짜 별 말이 없다.

 

NFS server 쪽에선 agent랑 통신(핑)도 되고 방화벽도 아예 죽어있어서 vm머신 선에서 막힐일이 없다.

 

내 컴퓨터 방화벽에서 의심되는 포트 다 개방~~~~

 

아차, 생각해보니 아마 진짜 nfs서버가 아니라 nfs관련 프로그램들 설치 안돼있을테고

agent가 nfs-server에 마운트를 못해서 인식 못하는듯?

nfs 서버로 만들어주자..

(이글 맨 위에 0번으로 해당 내용 추가해줬다)

 

https://docs.aws.amazon.com/datasync/latest/userguide/create-nfs-location.html

 

지정한 폴더의 모든 데이터를 전송하려면 DataSync에 모든 데이터를 읽을 수 있는 권한이 있어야 합니다. 이렇게 하려면 NFS 내보내기를 구성하거나 no_root_squashDataSync가 전송하려는 파일의 권한이 모든 사용자에게 읽기 액세스를 허용하는지 확인하십시오. 둘 중 하나를 수행하면 에이전트가 파일을 읽을 수 있습니다. 에이전트가 디렉터리에 액세스하려면 모든 실행 액세스도 설정해야 합니다.

그리고 나서 agent가 인식을 해야하니까 agent재부팅 해준다.

 

분명 NFS exportfs 설정시 'rw' 허가권을 설정했는데도 안되는 것이다.

이렇게 리눅스랑 타 프로그램이 인증 체계가 뭔가 안맞는 부분이 있어서 권한문제가 생긴다.

other에 rw 권한을 주던가 윈도우 쪽 레지스트리값을 수정해서 UID 와 GID 값을 일치 시키던지 해야한다.

 

 # chmod o+w /nfs-serverq

 

 

그리고 혹시 모르니까 agent설정에서  NTP 서버도 잘 맞춰서 시간도 동기화 해줬다.

(관련 내용은 여기 있는 링크중에 있으니 검색해보자)

 

여기까지 하니까 오류 내용이 제대로 뜬다.

 

agent의 로컬 콘솔 작업 (네트워킹) 가이드

https://docs.aws.amazon.com/datasync/latest/userguide/local-console-vm.html

 

 

 

 

일단 nfs-server 192.168.108.3에선 2049번 포트로 잘 리스닝 하고 있으니 서버쪽 문제는 없다.

 

agent에서 6번 command prompt 를 선택해서

2049번이나 111번이나 635번포트로 핑 보내보자.

 

2049번은 고사하고 80번도 핑이 안간다. 문제가 있군.

분명 방화벽 다 내렸는데??????

그리고 반대편인 192.168.108.3에선 여기로 핑이 보내지는데?????

뭐 192.168.108.3으로 들어오는 트레픽을 방화벽 하나 더 있나?

음.....그냥 위치를 못찾는건가 설마사카 vmware 내에서 네트워킹 알아서 해줄줄 알았는데.

그럼 라우팅 테이블...만져야지뭐

 

 

agent 1번 옵션으로 들어가서 네트워킹 설정을 해보겠다.

eth0 어뎁터의 설정을 보니 이녀석은 192.168.0.0/16 을 쓰고 있어서 내 사설 192.168.108.3/24 과 통신은 될듯?

 

그리고 8번 라우팅 테이블이 이렇다...

 

아니 근데 왜 통신이 안되지 하고 고민 겁나하고 검색때리다가 깨달은점은

다른 외국인들은 다 이렇게 콘솔까지 들어가서 뭘 만질 필요가 없어보인다. 질문도 안보인다.

아니그럼 난 왜?

생각해보니 그 이유는 vmware에 있었다...

 

이 agent자식 브릿지카드를 쓰고있다.

bridged 브릿지 카드는 딴  vmware머신과 통신 못하고 바로 인터넷카드에 연결되는 놈이다.

ova파일 준대로 생성했는데 왜 카드는 이런거 꼽아준걸까 진짜로..

 

바로 nat카드로 바꿔줘버리기~~~~

그리고 agent 재시작

 

와 바로 라우팅 테이블 들어가보니 자동으로 사설ip 대역으로 바뀌었다.

 

와아아ㅏ아아아아아아아아 핑이 간다!!!!

이제 간다!!!!! 에이전트가 드디어 내 nfs server와 같은 네트워크망에 들어와서 말을 걸수 있게 됐다.

 

다시 데이터싱크 테스크를 돌려보니 처음보는 준비중이라는 상태!

 

작업이 실행되면 실행 상태가 "실행 중"에서 "준비 중", "전송 중", "확인 중", 마지막으로 "성공"으로 진행된다.

 

 

트러블 슈팅 요약 : nfs-server가 잘 만들어져 있나 확인할것.

Agent가 VMware에 올라왔을때 네트워크 어뎁터를 NAT말고 다른거 꼽고있는지 확인하고 바꿔줄것.

방화벽문제나 디렉토리 other소유권은 사실 영향 있는지 잘 모르겠다. 만약 다 안되면 손대보자.

 

 

 

 

 

 

6. 결과 확인

 

좀 잡다한게 두개 있지만 일단 온프레에서 클라우드 쪽으로 잘 넘어왔다.

 

 

 

 

 

7. 역방향 전송

 

이제 응용해서 클라우드S3버킷에서 온프레미스 스토리지로 파일을 역방향 전송 해보겠다.

내가 진짜 원하는건 데이터 양방향 싱크니까..

 

S3버켓에 모나리자 파일 업로드

 

음 역시 테스크 시작버튼 안눌러주면 자동으로 안되고 스케쥴링 (예약) 해야 최소 1시간주기로 백업하나보다.

최소 설정 가능한 주기가 1시간이라서 datasync는 실시간 양방향 싱크에 부적합하다.

PRO가 1시간이면 장애시에 1시간분량 데이터는 까딱하면 버려진단 뜻이다.

 

그래서 storage gateway랑 같이쓰려고 이짓한것이다.

내 목표는 실시간 양방향 데이터싱크니까.

 

 

시작버튼 눌러서 테스크 실행해주고,

양방향 데이터 싱크 성공.

 

 

 

 

 

다음 글에 이어서 [Project] - Datasync + storage gateway로 실시간 싱크-2 로 찾아오겠다.

https://raid-1.tistory.com/193