[AWS] Storage Gateway (File Gateway) 구현하기

일반적으로 AWS 사용하지 않는 기업(고객)이 제일 첫 번째로 도입을 고려하는 것이 백업이다. 기존의 데이터는 그대로고 새로운 데이터를 넣는 것이기 때문에 시험 삼아 부담 없이 도입하는 게 아닌가 싶다. 오늘은 백업 솔루션 중 하나인 AWS Storage Gateway를 다뤄보려고 한다.

 

 

 

AWS Storage Gateway란

Storage Gateway란 AWS 스토리지를 On-Premise와 연결하여 마치 NAS처럼 사용하는 방법이라고 보면 된다. Storage Gateway에는 크게 다음 3종류로 구분된다.

 

1. File Gateway (NFS, SMB)

      - NFS: Network File System

      - SMB: System Message Blcok

2. Volume Gateway (iSCSI)

      - Stored Volume

      - Cached Volume

3. Tape Gateway (VTL)

 

먼저 File Gateway는 NFS 혹은 SMB 마운트 포인트로 전송받은 데이터를 S3에 저장하는 방법이다. 리눅스의 경우 Ownership, Permission, File created time은 메타데이터로 저장된다. S3에 저장된 데이터는 S3의 기능(Life Cycle, Versioning etc...)을 활용할 수 있다.

 

Volume Gateway는 Stored Volume과 Cached 두 개로 나뉜다. Stored Volume은 모든 데이터를 로컬에 저장하며 비동기적으로 AWS에 백업하는 방식이며 Cached Volume은 자주 사용하는 데이터는 로컬에 있고 나머지는 AWS에 백업된다. 추가로 백업은 EBS 스냅샷 형식으로 저장된다. Incremental 식으로 저장된다는 건데 즉, 이전 데이터에서 바뀌는 부분만 이후 저장된다는 의미다. 나름 이해하기 쉽게 아래 그림으로 정리해 봤다.

 

Tape Gateway는 NetBackup과 같은 Tape 기반 백업 애플리케이션을 위한 서비스며 iSCSI 기반이다.

 

 

 

File Gateway 작동 방식

앞서 설명했듯 File Gateway는 SMB, NFS 프로토콜을 사용한다고 했다. S3 버킷에 이 프로토콜로 파일 액세스 하기 위해 운영체제에서 SMB혹은 NFS 탑재 지점을 구성해야 한다. 대략적인 그림은 다음과 같다. 그림에 esxi Host로 표현한 VM은 클라우드에서 다운로드할 수 있는 OVA파일 설치하여 구성한다. On-Premise와 S3의 연결은 각자 사정에 맞는 방법을 택하면 되고 S3에 저장된 데이터는 액세스 빈도를 따져 Life Cycle 정책으로 과금을 줄이는 것도 고려해볼 수 있다.

 

 

File Gateway는 마치 NAS와 같이 사용할 수 있다. 다음 File Gateway 구성도 보자.

 

 

IDC A에 Storage Gateway VM을 설치하고 IDC B에 별도의  Storage Gateway VM을 설치해 같은 S3 버킷을 바라보게 한다면 S3 버킷으로부터 IDC A와 B를 사용하는 사용자는 NFS 혹은 SMB 프로토콜을 통해 같은 파일을 공유할 수도 있다. NAS역할을 한다면 당연한 결과물이지만 이 모든 것은 RefreshCacheAPI Call로 가능한 것이다.

 

(S3가 마치 내부망에 위치한 것처럼 구성도에 그려졌는데 사실 S3는 인터넷 액세스를 통해 호출을 한다. 이것이 문제가 된다면 interface gateway를 사용할 수 있지만 이번장의 성격과 맞지 않으니 넘어간다. 관련해서 이 글을 참고할 수 있다. https://bosungtea9416.tistory.com/21)

 

 

 

Volume Gateway 작동 방식

Volume Gateway도 File Gateway와 비슷한 활동을 한다. 하지만 그 내부 과정을 보면 전혀 다른 서비스란 것을 알 수 있다. Volume Gateway의 구성을 겉에서 보면 밑의 구성도로 보인다.

 

 

좀 더 자세히 들여다보면 밑의 구성도 처럼 동작한다. iSCSI 디바이스로 사용될 Storage Volume이 On-Premise 쪽에 크게 하나가 보인다. 

 

 

그램 맨 왼쪽 유저 혹은 애플리케이션으로부터 iSCSI 액세스를 받았을 때, Volume Gateway는 짧은 지연시간을 위해 Cache Storage에 저장된 데이터를 반환한다. 하늘색으로 표시한 부분이다.

 

Volume Gateway는 스테이징 영역에 들어오는 쓰기를 저장하는 Upload Buffer라는 것이 있다. 붉은색으로 강조한 부분이다. 이 Upload Buffer는 AWS에 데이터를 업로드할 때 버퍼링 역할을 한다. 업로드되는 데이터는 SSL로 암호화된다. 

 

만약 로컬 애플리케이션 혹은 유저가 Cache Storage에 없는 데이터를 읽어온다면 게이트웨이는 자동으로 AWS에서 해당 데이터를 검색해 끌어온다. 또한 S3버킷에 저장된 데이터로 EBS 스냅샷을 생성할 수 있는데 EC2에서 이것에 접근할 수도 있다.

 

 

 

Tape Gateway 작동 방식

NetBackup이나 Veeam 등 On-Premise에서 사용 중인 Backup Application과 Tape Gateway(VM or Hardware appliance etc...)를 연결해준다. Tape Gateway는 데이터를 압축 및 암호화하여 S3에 저장되어 있는 Virtual Tape Library로 보내는 방식이다. 만약 데이터 접근이 1년에 한 번 될까 말까 한다면 S3 Glacier Deep Archive 까지도 고려해 볼 수 있다. Retrive 하는 데는 약 12시간 정도 걸리지만 말이다.

 

 

 

 

실습을 위해 필요한 준비물

개념은 이쯤 하고 실습에 들어가 보자. 이번 장은 Storage Gateway의 File Gateway를 구현해 보겠다. S3 버킷을 마치 내 D드라이브처럼 사용해 볼 거다. 이를 위해 필요한 것은 다음과 같다.

 

1. Storage Gateway를 위한 VM

2. S3 버킷

 

 

 

실습

1. Console 검색창에 Storage gateway 서비스를 검색해 서비스를 생성한다. 셋 업 방법은 다음과 같다고 한다. 게이트웨이 생성 -> 게이트웨이 설정 -> 게이트웨이에 데이터 저장 및 접근을 위한 리소스 생성

 

 

2. Gateway 이름 작성, TimeZone 선택, Gateway Type 선택. 나중에 생성할 VM과 게이트웨이의 Time Zone이 일치해야 함을 알고 있자. 이번 장은 File Gateway를 하기로 했으니 File Gateway를 선택한다.

 

 

3. VM에 설치할 플랫폼을 선택하고 다운로드한다. 나는 VMware ESXi를 이용했다.

 

 

4. 다운로드한 OVA 파일을 VMware에서 열어 생성한다.

 

 

5. VM 생성이 완료되었다면 추가 구성해야 할 것이 있다. 바로 시간 동기화와 볼륨 추가하는 것이다. 추가 하드웨어 생성은 SCSI Type 선택 > Create a new virtual disk > 용량 선택 (필자는 150기가를 선택했다) > Store virtual disk as a single file > 생성하기

 

 

여기에 실제 데이터가 저장될 곳이다.

 

 

6. VM 접속한다. ID/PW는 디폴트 설정으로 'admin'과 'password'이다. VM을 클릭하고 윈도우 클릭이 안된다면 당황하지 말고 Ctrl + Alt를 눌러주면 된다. 접속해보면 여러 가지 옵션이 있다. 우선 VM의 통신환경이 정상임을 확인했다. 그 외에 시간 동기화 등 기타 등등을 체크해주자.

 

 

7. 다시 콘솔 환경으로 돌아와 다음으로 넘어가 준다. 자세히 읽어보면 이번장의 실습 내용이 잘 요약되어 있다. 그냥 넘기지 말고 꼭 한번 읽어보고 다음으로 넘어가자.

 

 

8. 별도의 VPN 작업을 해준 것이 없으니 'Publicly accessible'을 선택한다. 그리고 Gateway연결을 위한 IP 주소를 입력한다. IP 주소는 VM에 접속하면 바로 보인다. 다른 방법으로는 'Activation Key'값을 넣을 수 있다. 키 값은 VM 선택 창에서 생성해서 참고하자.

 

 

9. 여기까지 정상적으로 왔다면 Configure cache storage에서 로컬 VM을 인식할 것이다. 참고로 'Access objects using'은 리눅스도 Mac도 윈도우도 쓸 수 있는 NFS를 택했다. 밑의 그림처럼 진행하면 드디어 Storage Gateway 생성 완료다.

 

 

10. 이제 Fire share를 설정해준다. 아까 생성한 Storage Gateway를 선택하고 NAS처럼 사용할 S3를 선택한다. 필자는 미리 사전에 S3를 만들어 두었다. 참고로 S3는 Private 해도 Storage Gateway에서 붙을 수 있다.

 

 

11. FIle Share 생성 완료

 

 

12. 생성한 File Share를 클릭하면 밑의 그림처럼 친절하게 마운트 명령어가 보인다. 저 명령어를 자신이 사용하는 OS에 맞게 입력해주면 된다. 명령어 마지막 부분은 설치될 드라이버의 이름을 정하는 곳이다. 선호하는 이름을 넣자. 나는 'E:' 드라이브로 했다.

 

 

12. 만약 밑의 화면처럼 오류가 (윈도우 환경) 났다면 여러 가지 이유가 있을 수 있다. 필자의 경우 'Windows 기능 켜기/끄기'

수정으로 이를 해결했다. 'NFS용 서비스'를 활성화 해줘보자.

 

 

13. 마운트가 성공했다면 내 컴퓨터로 접근해 마운트 된 S3를 확인해보자. S3의 용량 제한이 무제한에 가깝다 보니 크기가 7.99EB로 잡힌다. 접속해 보니 S3의 데이터가 보인다. 테스트로 아무 파일이나 집어넣었더니 이름이 깨지긴 했지만 SS 콘솔 환경에서도 확인할 수 있었다. 로컬에서 데이터를 넣고 AWS 콘솔 화면에서 출력되기까지 약 3초 정도 딜레이가 있었는데 각자 환경이 다양하다 보니 사람마다 수치는 달라질 수 있을 것 같다.

 

 

 

 

 

 

 

 

 

긴 글 읽어주셔서 감사합니다.

잘못된 점 지적은 언제나 환영입니다.