방법 AWS Storage Gateway 작업(아키텍처) - AWS Storage Gateway

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

방법 AWS Storage Gateway 작업(아키텍처)

그 다음에는 사용 가능한 AWS Storage Gateway 솔루션의 아키텍처 개요를 제공합니다.

파일 게이트웨이

파일 게이트웨이를 사용하려면 파일 게이트웨이용 VM 이미지를 다운로드하는 것으로 시작합니다. 그런 다음 AWS Management 콘솔 또는 Storage Gateway API에서 파일 게이트웨이를 활성화합니다. 또한 Amazon EC2 이미지를 사용하여 파일 게이트웨이를 생성할 수도 있습니다.

이후 파일 게이트웨이 이 활성화되면 파일 공유를 생성 및 구성하고 해당 공유를 Amazon Simple Storage Service (Amazon S3) 버킷. 이렇게 하면 클라이언트가 NFS(네트워크 파일 시스템) 또는 SMB(서버 메시지 블록) 프로토콜을 사용하여 공유를 액세스할 수 있습니다. 파일 공유에 기록된 파일은 Amazon S3의 객체가 되고 키는 경로가 됩니다. 파일과 객체 간에 일대일 매핑이 되어 있고 파일을 변경할 때마다 게이트웨이는 Amazon S3 내부 객체를 비동기 방식으로 업데이트합니다. 의 기존 개체 Amazon S3 버킷이 파일 시스템에 파일로 나타나고 키가 경로로 바뀝니다. 객체는 Amazon S3 – 서버 측 암호화 키(SSE-S3)로 암호화됩니다. 모든 데이터 전송은 HTTPS를 통해 이루어집니다.

이 서비스는 게이트웨이와 AWS 다중 부분 병렬 업로드 또는 바이트 범위 다운로드를 사용하여 사용 가능한 대역폭을 더 잘 사용합니다. 로컬 캐시는 최근 액세스한 데이터에 대한 낮은 지연 시간 액세스를 제공하고 데이터 송신 요금을 줄이기 위해 유지됩니다. CloudWatch 메트릭을 통해 VM의 리소스 사용 및 데이터 전송에 대한 통찰력을 제공합니다. AWS. CloudTrail 모든 API 호출을 추적합니다.

파일 게이트웨이 스토리지를 사용하면 클라우드 워크로드를 수집하여 Amazon S3백업 및 아카이빙, 계층화 및 스토리지 데이터 마이그레이션을 AWS 클라우드. 다음 다이어그램은 Storage Gateway에 대한 파일 스토리지 배포를 간략하게 보여줍니다.

파일을 에 업로드할 때 파일 게이트웨이가 파일을 S3 개체로 변환합니다. Amazon S3. 파일 게이트웨이의 파일 공유에 대해 수행되는 파일 작업과 S3 객체 간의 상호 작용은 파일과 객체를 변환할 때 특정 작업을 신중하게 고려해야 합니다.

일반적인 파일 작업은 파일 메타데이터를 변경하여 현재 S3 객체를 삭제하고 새 S3 객체를 생성합니다. 다음 표에는 예제 파일 작업과 S3 객체에 미치는 영향이 나와 있습니다.

파일 작업 S3 개체 영향 스토리지 등급 영향

파일 이름 바꾸기

기존 S3 개체를 대체하고 각 파일에 대해 새 S3 개체를 만듭니다.

조기 삭제 수수료 및 검색 수수료가 적용될 수 있습니다.

폴더 이름 바꾸기

기존의 모든 S3 객체를 대체하고 각 폴더 및 폴더 구조의 파일에 대해 새 S3 객체를 생성합니다.

조기 삭제 수수료 및 검색 수수료가 적용될 수 있습니다.

파일/폴더 권한 변경

기존 S3 개체를 대체하고 각 파일 또는 폴더에 대해 새 S3 개체를 만듭니다.

조기 삭제 수수료 및 검색 수수료가 적용될 수 있습니다.

파일/폴더 소유권 변경

기존 S3 개체를 대체하고 각 파일 또는 폴더에 대해 새 S3 개체를 만듭니다.

조기 삭제 수수료 및 검색 수수료가 적용될 수 있습니다.

파일에 추가

기존 S3 개체를 대체하고 각 파일에 대해 새 S3 개체를 만듭니다.

조기 삭제 수수료 및 검색 수수료가 적용될 수 있습니다.

NFS 또는 SMB 클라이언트가 파일 게이트웨이에 파일을 쓸 때 파일 게이트웨이는 파일 데이터를 Amazon S3 메타데이터(소유권, 타임스탬프 등)가 뒤따릅니다. 파일 데이터를 업로드하면 S3 객체가 생성되고, 파일의 메타데이터를 업로드하면 S3 객체의 메타데이터가 업데이트됩니다. 이 프로세스는 다른 버전의 개체를 만들어 두 가지 버전의 개체로 만듭니다. S3 버전 관리가 활성화된 경우 두 버전이 모두 저장됩니다.

NFS 또는 SMB 클라이언트가 에 업로드한 후 파일 게이트웨이에서 파일을 수정한 경우 Amazon S3, 파일 게이트웨이는 전체 파일을 업로드하는 대신 새 데이터 또는 수정된 데이터를 업로드합니다. 파일을 수정하면 S3 객체의 새 버전이 생성됩니다.

파일 게이트웨이가 더 큰 파일을 업로드하는 경우 클라이언트가 파일 게이트웨이에 쓰기를 완료하기 전에 파일의 작은 청크를 업로드해야 할 수 있습니다. 캐시 공간 확보 또는 파일 공유에 대한 쓰기 속도 증가 등의 몇 가지 이유가 있습니다. 이로 인해 S3 버킷에 여러 버전의 개체가 생성될 수 있습니다.

수명주기 정책을 설정하여 객체를 다른 스토리지 클래스로 이동하기 전에 S3 버킷을 모니터링하여 객체의 버전이 얼마나 있는지 확인해야 합니다. S3 버킷의 개체에 대해 가지고 있는 버전 수를 최소화하려면 이전 버전에 대한 수명 주기 만료를 구성해야 합니다. S3 버킷 간에 SRR(동일 지역 복제) 또는 CRR(교차 지역 복제)을 사용하면 사용된 스토리지가 증가합니다.

볼륨 게이트웨이

볼륨 게이트웨이의 경우 캐시 볼륨이나 저장 볼륨을 사용할 수 있습니다.

캐시된 볼륨 아키텍처

캐시 볼륨으로 Amazon S3를 기본 데이터 스토리지로 사용함과 동시에 자주 액세스하는 데이터를 스토리지 게이트웨이에 로컬 보관할 수 있습니다. 또한 온프레미스 스토리지 인프라를 확장할 필요성이 최소화되는 한편, 애플리케이션이 자주 액세스하는 데이터에 액세스할 때의 지연 시간을 짧게 유지할 수 있습니다. 최대 32개의 스토리지 볼륨을 생성할 수 있습니다. TiB 온프레미스 애플리케이션 서버에서 iSCSI 디바이스로 연결할 수 있습니다. 게이트웨이는 이 볼륨에 작성하는 데이터는 Amazon S3에 저장하고 최근에 읽은 데이터는 온프레미스 스토리지 게이트웨이의 캐시 및 업로드 버퍼 스토리지에 보관합니다.

캐시된 볼륨의 범위는 1부터 GiB ~ 32명 TiB 가장 가까운 값으로 반올림해야 합니다. GiB. 캐시된 볼륨에 대해 구성된 각 게이트웨이는 최대 32개의 볼륨을 최대 1,024개의 총 스토리지 볼륨에 대해 지원할 수 있습니다. TiB (1개) PiB).

캐싱 볼륨 솔루션에서 AWS Storage Gateway는 모든 온프레미스 애플리케이션 데이터를 Amazon S3의 스토리지 볼륨에 저장합니다. 다음 다이어그램은 캐싱 볼륨 배포의 개요입니다.

Storage Gateway 소프트웨어 어플라이언스, 즉 VM을 데이터 센터의 호스트에 설치하고 활성화한 후 AWS Management 콘솔을 사용하여 Amazon S3에 백업된 스토리지 볼륨을 프로비저닝할 수 있습니다. AWS Storage Gateway API 또는 AWS SDK 라이브러리를 사용하여 스토리지 볼륨을 프로그래밍 방식으로 프로비저닝할 수도 있습니다. 그리고 나서 이러한 스토리지 볼륨을 iSCSI 장치로 온프레미스 애플리케이션 서버에 마운트합니다.

VM에 온 프레미스로 디스크를 할당할 수 있습니다. 이러한 온 프레미스 디스크는 다음의 목적을 달성합니다.

  • 게이트웨이에서 캐시 스토리지로 사용할 디스크 – 애플리케이션이 AWS에 있는 스토리지 볼륨에 데이터를 작성할 때, 게이트웨이는 먼저 캐시 스토리지에 사용되는 온프레미스 디스크에 데이터를 저장합니다. 그런 다음 게이트웨이는 데이터를 Amazon S3으로 업로드합니다. 캐시 스토리지는 업로드 버퍼에서 Amazon S3로 업로드될 때까지 대기 중인 데이터를 위한 온프레미스 내구성 저장소의 역할을 합니다.

    또한 캐시 스토리지는 지연 시간이 짧은 액세스를 위해 게이트웨이가 최근에 애플리케이션에서 액세스한 데이터를 온프레미스에 저장하도록 허용합니다. 애플리케이션에서 데이터를 요청하면 게이트웨이는 Amazon S3를 확인하기 전에 우선 캐시 스토리지에서 데이터를 확인합니다.

    다음 지침을 사용하여 캐시 스토리지를 할당할 디스크 공간의 크기를 결정할 수 있습니다. 일반적으로 기존 파일 저장소 크기의 최소 20퍼센트를 캐시 스토리지로 할당해야 합니다. 또한 캐시 스토리지는 업로드 버퍼보다 커야 합니다. 이렇게 하면 캐시 스토리지가 Amazon S3에 아직 업로드되지 않은 업로드 버퍼에 있는 모든 데이터를 일정하게 보유할 공간이 충분하도록 하는 데 도움이 됩니다.

  • 게이트웨이에서 업로드 버퍼로 사용할 디스크 – 게이트웨이는 Amazon S3에 업로드하기 위한 준비 작업으로 업로드 버퍼라고 하는 스테이징 영역에 수신 데이터를 저장합니다. 게이트웨이는 이 버퍼 데이터를 암호화된 Secure Sockets Layer(SSL) 연결을 통해 AWS에 업로드합니다. 데이터는 Amazon S3에 암호화된 상태로 저장됩니다.

Amazon S3의 스토리지 볼륨에 대해 스냅샷이라고 하는 증분식 백업을 실행할 수 있습니다. 이 특정 시점 스냅샷은 Amazon S3에 Amazon EBS 스냅샷으로도 저장됩니다. 새 스냅샷을 만들 때 마지막 스냅샷 저장 이후에 변경된 데이터만 저장됩니다. 스냅샷을 일정에 따라 또는 일회적으로 실행할 수 있습니다. 스냅샷을 삭제할 때 다른 스냅샷에 필요하지 않은 데이터만 제거됩니다. 다음에 대한 정보 Amazon EBS 스냅샷, 참조 아마존 EBS 스냅샷.

데이터 백업을 복구해야 하는 경우에는 Amazon EBS 스냅샷을 게이트웨이 스토리지 볼륨으로 복원할 수 있습니다. 또는 최대 16개의 스냅샷 TiB 스냅샷은 새 스냅샷의 시작점으로 사용할 수 있습니다. Amazon EBS 볼륨. 그 다음 이 새 Amazon EBS 볼륨을 Amazon EC2 인스턴스에 연결할 수 있습니다.

캐시 볼륨에 대한 모든 게이트웨이 데이터와 스냅샷 데이터는 Amazon S3에 저장되며 유휴 상태에서 서버 측 암호화(SSE)를 사용하여 암호화됩니다. 그러나 Amazon S3 API 또는 Amazon S3 Management Console 같은 기타 도구로는 이 데이터에 액세스할 수 없습니다.

저장된 볼륨 아키텍처

저장 볼륨을 사용하여 기본 데이터를 로컬에 저장하는 한편, 해당 데이터를 AWS에 비동기식으로 백업할 수 있습니다. 또한 저장 볼륨은 온프레미스 애플리케이션에서 전체 데이터 세트에 액세스할 때 지연 시간을 단축합니다. 이와 동시에 내구성이 우수한 오프사이트 백업을 제공합니다. 스토리지 볼륨을 생성하여 온프레미스 애플리케이션 서버에서 iSCSI 디바이스로 마운트할 수 있습니다. 저장 볼륨에 작성한 데이터는 온프레미스 스토리지 하드웨어에 저장됩니다. 이 데이터는 Amazon Elastic Block Store(Amazon EBS) 스냅샷 형태로 Amazon S3에 비동기 방식으로 백업됩니다.

저장된 볼륨의 범위: 1 GiB - 16개 TiB 가장 가까운 값으로 반올림해야 합니다. GiB. 저장된 볼륨에 대해 구성된 각 게이트웨이는 최대 32개의 볼륨과 512개의 총 볼륨 스토리지를 지원할 수 있습니다. TiB (0.5개) PiB).

저장 볼륨의 경우, 볼륨 스토리지를 데이터 센터에서 온프레미스 방식으로 유지 관리합니다. 다시 말하면, 모든 애플리케이션 데이터를 온 프레미스 스토리지 하드웨어에 저장하는 것입니다. 그 다음에 게이트웨이는 비용 효율적인 백업과 신속한 재해 복구를 위해 데이터 보안 유지에 도움이 되는 기능을 사용하여 AWS 클라우드로 데이터를 업로드합니다. 이 솔루션은 모든 데이터에 액세스할 때 지연 시간이 짧아야 하고 아울러 백업을 AWS에서 유지 관리해야 하는 이유로 인해 데이터를 온프레미스 방식으로 로컬에 저장하려는 경우에 가장 적합합니다.

다음 다이어그램은 저장 볼륨 배포의 개요입니다.

AWS Storage Gateway 소프트웨어 어플라이언스, 즉 VM을 데이터 센터의 호스트에 설치하고 활성화한 후 게이트웨이 스토리지 볼륨을 생성할 수 있습니다. 그러고 나면 온프레미스 직접 연결 스토리지(DAS) 또는 스토리지 영역 네트워크(SAN) 디스크로 매핑할 수 있습니다. 새 디스크로 진행해도 되고, 데이터를 이미 저장하고 있는 디스크로 진행해도 됩니다. 그리고 나서 이러한 스토리지 볼륨을 iSCSI 장치로 온프레미스 애플리케이션 서버에 마운트할 수 있습니다. 온프레미스 애플리케이션이 데이터를 게이트웨이 저장 볼륨에서/으로 읽고 작성하면 이 데이터는 볼륨의 지정된 디스크에 저장 및 복원됩니다.

게이트웨이는 Amazon S3에 데이터를 업로드하기 위한 준비 작업으로 업로드 버퍼라고 하는 스테이징 영역에 수신 데이터를 저장합니다. 온프레미스 DAS 또는 SAN 디스크를 작업 스토리지로 사용할 수 있습니다. 게이트웨이는 암호화된 Secure Sockets Layer(SSL) 연결을 통해 업로드 버퍼로부터 AWS 클라우드에서 실행 중인 AWS Storage Gateway 서비스로 데이터를 업로드합니다. 그러면 서비스는 해당 데이터를 암호화된 상태로 Amazon S3에 저장합니다.

스냅샷이라고 불리는 저장 볼륨에 대한 증분 백업을 실행할 수 있습니다. 게이트웨이는 이 스냅샷을 Amazon S3에 Amazon EBS 스냅샷으로 저장합니다. 새 스냅샷을 만들 때 마지막 스냅샷 저장 이후에 변경된 데이터만 저장됩니다. 스냅샷을 일정에 따라 또는 일회적으로 실행할 수 있습니다. 스냅샷을 삭제하면 다른 스냅샷이 필요하지 않은 데이터만 제거됩니다.

데이터 백업을 복구해야 하는 경우에는 Amazon EBS 스냅샷을 온프레미스 게이트웨이 스토리지 볼륨으로 복원할 수 있습니다. 스냅샷을 새로운 Amazon EBS 볼륨의 시작점으로 사용할 수도 있습니다. 이 시작점은 Amazon EC2 인스턴스에 연결할 수 있습니다.

테이프 게이트웨이

테이프 게이트웨이는 데이터를 내구성이 있고 비용 효율적인 방식으로 AWS 클라우드에 보관할 수 있는 솔루션을 제공합니다. 가상 테이프 라이브러리(VTL) 인터페이스를 통해 기존 테이프 기반 백업 인프라를 최대한 활용하여 테이프 게이트웨이에 생성하는 가상 테이프 카트리지에 데이터를 저장할 수 있습니다. 각 테이프 게이트웨이는 미디어 체인저 및 테이프 드라이브로 미리 구성됩니다. 이러한 테이프 드라이브와 미디어 체인저는 기존 클라이언트 백업 애플리케이션에서 iSCSI 디바이스로 사용할 수 있습니다. 필요에 따라 테이프 카트리지를 추가하여 데이터를 보관합니다.

다음 다이어그램은 테이프 게이트웨이 배포를 간략하게 보여줍니다.

이 다이어그램은 다음과 같은 테이프 게이트웨이 구성 요소를 보여줍니다.

  • 가상 테이프 – 가상 테이프는 물리적 테이프 카트리지와 유사합니다. 그러나 가상 테이프 데이터는 AWS 클라우드에 저장됩니다. 물리적 테이프처럼 가상 테이프는 공백 상태로 두거나 데이터를 기록할 수 있습니다. Storage Gateway 콘솔을 사용하거나 Storage Gateway API를 사용하여 프로그램 방식으로 가상 테이프를 생성할 수 있습니다. 각 게이트웨이는 최대 1,500개의 테이프 또는 최대 1개의 PiB 한 번에 총 테이프 데이터 개. 테이프를 생성할 때 구성할 수 있는 각 가상 테이프의 크기는 100개입니다. GiB 및 5 TiB.

  • 가상 테이프 라이브러리(VTL) – VTL은 로봇 팔과 테이프 드라이브로 온프레미스에서 사용할 수 있는 물리적 테이프 라이브러리와 유사합니다. VTL에는 저장된 가상 테이프 모음이 포함됩니다. 각 테이프 게이트웨이는 VTL이 한 개씩 제공됩니다.

    생성한 가상 테이프는 게이트웨이의 VTL에 표시됩니다. VTL의 테이프는 Amazon S3에 의해 백업됩니다. 백업 소프트웨어가 게이트웨이에 데이터를 기록하면 게이트웨이는 데이터를 로컬에 저장한 후 이를 VTL에 있는 가상 테이프, 즉 Amazon S3에 비동기 방식으로 업로드합니다.

    • 테이프 드라이브 – VTL 테이프 드라이브는 I/O를 수행하고 테이프에서 작업을 검색할 수 있는 물리적 테이프 드라이브와 유사합니다. 각 VTL에는 백업 애플리케이션에서 iSCSI 디바이스로 사용할 수 있는 테이프 드라이브 10개가 한 세트로 제공됩니다.

    • 미디어 체인저 – VTL 미디어 체인저는 물리적 테이프 라이브러리의 스토리지 슬롯 및 테이프 드라이브에서 테이프를 이동하는 로봇과 유사합니다. 각 VTL에는 백업 애플리케이션에서 iSCSI 디바이스로 사용할 수 있는 미디어 체인저가 한 개 제공됩니다.

  • 아카이브 – 아카이브는 외부 테이프 보유 시설과 유사합니다. 게이트웨이의 VTL에서 아카이브로 테이프를 보관할 수 있습니다. 필요 시 아카이브에서 게이트웨이의 VTL로 테이프를 다시 가져올 수 있습니다.

    • 테이프 보관 – 백업 소프트웨어가 테이프를 배출하면 게이트웨이는 장기 스토리지용 아카이브로 테이프를 옮깁니다. 아카이브는 게이트웨이를 활성화한 AWS 리전에 있습니다. 아카이브의 테이프는 VTS(Virtual Tape Shelf)에 저장됩니다. VTS는 S3 Glacier 또는 S3 Glacier Deep Archive(데이터 아카이브, 백업, 장기 데이터 보관을 위한 경제적인 스토리지 서비스)를 통해 백업됩니다.

    • 테이프 가져오기 – 보관된 테이프는 직접 읽을 수 없습니다. 아카이브된 테이프를 읽으려면 먼저 Storage Gateway 콘솔이나 Storage Gateway API를 사용하여 테이프 게이트웨이로 테이프를 가져와야 합니다.

      중요

      GLACIER에 테이프를 아카이브하면 일반적으로 3~5시간 내에 테이프를 가져올 수 있습니다. DEEP_ARCHIVE에 테이프를 아카이브하면 일반적으로 12시간 내에 테이프를 가져올 수 있습니다.

테이프 게이트웨이를 배포하고 활성화한 후 온프레미스 애플리케이션 서버에 가상 테이프 드라이브와 미디어 체인저를 iSCSI 디바이스로 마운트합니다. 필요 시 가상 테이프를 생성할 수 있습니다. 그러고 나면 기존 백업 소프트웨어 애플리케이션을 사용하여 데이터를 가상 테이프에 쓸 수 있습니다. 미디어 체인저는 가상 테이프를 가상 테이프 드라이브로 로드 및 언로드하여 잃기 및 쓰기 작업을 수행합니다.

게이트웨이 VM에 로컬 디스크 할당

게이트웨이 VM에는 로컬 디스크가 필요한데, 이를 할당하는 목적은 다음과 같습니다.

  • 캐시 스토리지 – 캐시 스토리지는 업로드 버퍼에서 Amazon S3로 업로드될 때까지 대기 중인 데이터를 위한 내구성 저장소의 역할을 합니다.

    애플리케이션이 가상 테이프에서 데이터를 읽으면 게이트웨이는 데이터를 캐시 스토리지에 저장합니다. 게이트웨이는 액세스 지연 시간을 줄이기 위해 최근에 액세스한 데이터를 캐시 스토리지에 저장합니다. 애플리케이션에서 테이프 데이터를 요청하면 게이트웨이는 AWS에서 데이터를 다운로드하기 전에 우선 캐시 스토리지에서 데이터를 확인합니다.

  • 업로드 버퍼 – 업로드 버퍼는 데이터를 가상 테이프에 업로드하기 전에 게이트웨이에 스테이징 영역을 제공합니다. 또한 업로드 버퍼는 예기치 않은 장애로부터 테이프를 복구하는 데 사용할 수 있는 복구 시점을 생성할 때 아주 중요한 역할을 합니다. 자세한 정보는 장애가 있는 테이프 게이트웨이에서 가상 테이프를 복구해야 하는 경우 단원을 참조하십시오.

백업 애플리케이션이 데이터를 게이트웨이에 쓸 때 게이트웨이는 데이터를 캐시 스토리지와 업로드 버퍼 모두로 복사합니다. 그런 다음 백업 애플리케이션에 대한 쓰기 작업 완료를 승인합니다.

캐시 스토리지 및 업로드 버퍼에 할당할 디스크 공간 크기에 대한 지침은 로컬 디스크 스토리지 용량 결정 단원을 참조하십시오.