File Gateway 모범 사례 - AWS Storage Gateway

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

File Gateway 모범 사례

이 섹션에는 게이트웨이, 파일 공유, 버킷 및 데이터 작업 모범 사례에 대한 정보를 제공하는 다음 주제가 포함되어 있습니다. AWS Storage Gateway와 관련된 문제를 방지하기 위해 이 단원에 설명된 정보를 숙지하고 이 지침을 따르는 것이 좋습니다. 배포 시 발생할 수 있는 일반적인 문제를 진단하고 해결하는 방법에 대한 자세한 내용은 Storage Gateway 배포 문제 해결 단원을 참조하세요.

모범 사례: 데이터 복구

드물긴 하지만 게이트웨이에 복구 불가능한 장애가 발생할 수 있습니다. 그러한 장애는 가상 머신(VM), 게이트웨이 자체, 로컬 스토리지 등에서 발생할 수 있습니다. 장애가 발생하면 이어지는 적절한 단원의 지침에 따라 테이프를 복구하는 것이 좋습니다.

중요

Storage Gateway는 하이퍼바이저에서 생성한 스냅샷 또는 Amazon EC2 Amazon Machine Image(AMI)에서 게이트웨이 VM을 복구하는 기능을 지원하지 않습니다. 게이트웨이 VM이 제대로 작동하지 않는 경우에는 다음 지침에 따라 새 게이트웨이를 활성화하고 그 게이트웨이에 데이터를 복구합니다.

가상 머신이 예기치 않게 종료된 상황에서 복구하기

예를 들어 정전으로 인해 VM이 예기치 않게 종료된 경우, 게이트웨이에 접속할 수 없습니다. 전원과 네트워크 연결이 복구되면 게이트웨이에 접속할 수 있고 게이트웨이가 정상적으로 작동하기 시작합니다. 다음은 이 시점에 수행할 수 있는 데이터 복구 지원 절차입니다.

  • 정전으로 인해 네트워크 연결에 문제가 발생하면 그 문제를 해결할 수 있습니다. 네트워크 연결을 테스트하는 방법에 대한 정보는 게이트웨이 네트워크 연결 테스트섹션을 참조하세요.

장애가 있는 캐시 디스크에서 데이터 복구

캐시 디스크에 장애가 발생하면 다음 절차에 따라 처한 상황에 맞는 방법으로 데이터를 복구하는 것이 좋습니다.

  • 호스트에서 캐시 디스크가 제거되어 장애가 발생한 경우, 게이트웨이를 종료하고 디스크를 다시 추가한 후 게이트웨이를 다시 시작합니다.

액세스할 수 없는 데이터 센터에서 데이터 복구

게이트웨이 또는 데이터 센터에 대한 액세스가 어떤 이유로 차단되는 경우에는 데이터를 다른 데이터 센터의 다른 게이트웨이로 복구하거나 Amazon EC2 인스턴스에서 호스팅되는 게이트웨이로 복구할 수 있습니다. 따라서 다른 데이터 센터에 액세스할 수 없다면 Amazon EC2 인스턴스에서 게이트웨이를 생성하는 것이 좋습니다. 생성 방법은 데이터를 복구하는 게이트웨이 유형에 따라 다릅니다.

액세스할 수 없는 데이터 센터의 File Gateway에서 데이터를 복구하려면

File Gateway의 경우 복구하려는 데이터가 포함된 Amazon S3 bucketFSx에 새 파일 매핑합니다.

  1. Amazon EC2 호스트에서 새 File Gateway를 생성하고 활성화합니다. 자세한 내용은 S3 File Gateway용 기본 Amazon EC2 호스트 배포 단원을 참조하십시오.

  2. 생성한 EC2 게이트웨이에서 새 생성합니다. 자세한 내용은 파일 공유 생성.

  3. 클라이언트에 파일 공유 탑재하고 복구하려는 데이터가 포함된 S3 bucketFSx에 매핑합니다. 자세한 내용은 파일 공유 탑재 및 사용.

모범 사례: 멀티파트 업로드 관리

대용량 파일을 전송할 때 S3 File Gateway는 Amazon S3 멀티파트 업로드 기능을 사용하여 파일을 더 작은 부분으로 분할하고 병렬로 전송하여 효율성을 개선합니다. 멀티파트 업로드에 대한 자세한 내용은 Amazon Simple Storage Service 사용 설명서멀티파트 업로드를 사용하여 객체 업로드 및 복사를 참조하세요.

어떤 이유로든 멀티파트 업로드가 성공적으로 완료되지 않으면 게이트웨이는 일반적으로 전송을 중지하고, 부분적으로 전송된 파일을 Amazon S3에서 삭제하고, 전송을 다시 시도합니다. 드문 경우지만 하드웨어 또는 네트워크 장애로 인해 멀티파트 업로드 실패 후 게이트웨이가 정리되지 않는 경우 부분적으로 전송된 파일의 일부가 Amazon S3에 남아 있어 스토리지 요금이 발생할 수 있습니다.

불완전한 멀티파트 업로드로 인한 Amazon S3 스토리지 비용을 최소화하는 모범 사례로, 지정된 일수 후에 AbortIncompleteMultipartUpload API 작업을 사용하여 전송 실패를 자동으로 중지하고 연결된 파일 부분을 삭제하는 Amazon S3 버킷 수명 주기 규칙을 구성하는 것이 좋습니다. 지침은 Amazon Simple Storage Service 사용 설명서불완전한 멀티파트 업로드를 삭제하도록 버킷 수명 주기 구성 구성을 참조하세요.

모범 사례: 게이트웨이에 복사하기 전에 압축된 파일의 압축을 로컬에서 풉니다.

게이트웨이에 저장되어 있는 동안 수천 개의 파일이 포함된 압축된 아카이브의 압축을 풀려고 하면 상당한 성능 관련 지연이 발생할 수 있습니다. 모든 유형의 네트워크 파일 공유에서 많은 수의 파일이 포함된 아카이브의 압축을 풀려면 기본적으로 많은 양의 입력/출력 작업, 메타데이터 캐시 조작, 네트워크 오버헤드 및 지연 시간이 필요합니다. 또한 Storage Gateway는 아카이브의 각 파일의 압축 해제가 완료된 시기를 확인할 수 없으며, 프로세스가 완료되기 전에 파일 업로드를 시작할 수 있어 성능에 추가 영향을 미칩니다. 이러한 문제는 아카이브 내의 파일이 많지만 크기가 작을 때 복잡해집니다.

압축된 아카이브를 압축 해제하기 전에 먼저 게이트웨이에서 로컬 시스템으로 전송하는 것이 좋습니다. 그런 다음 필요한 경우 robocopy 또는 rsync와 같은 도구를 사용하여 압축을 푼 파일을 게이트웨이로 다시 전송할 수 있습니다.

Windows Server에서 데이터를 복사할 때 파일 속성 유지

Microsoft Windows의 기본 copy 명령을 사용하여 파일을 File Gateway에 복사할 수 있지만이 명령은 기본적으로 파일 데이터만 복사하여 보안 설명자와 같은 특정 파일 속성을 생략합니다. 파일이 해당 보안 제한 및 DACL(일임 액세스 제어 목록) 정보 없이 게이트웨이에 복사되는 경우 권한이 없는 사용자가 파일에 액세스할 수 있습니다.

Microsoft Windows Server의 게이트웨이에 파일을 복사할 때 모든 파일 속성과 보안 정보를 보존하는 모범 사례로 또는 robocopy xcopy 명령을 각각 /copy:DS 또는 /o 플래그와 함께 사용하는 것이 좋습니다. 자세한 내용은 Microsoft Windows Server 명령 참조 설명서의 robocopy and xcopy를 참조하세요.

모범 사례: 캐시 디스크의 적절한 크기 조정

최상의 성능을 얻으려면 총 디스크 캐시 크기가 활성 작업 세트의 크기를 충당할 수 있을 만큼 커야 합니다. 읽기 중심 및 혼합 읽기/쓰기 워크로드의 경우 읽기에 대한 캐시 적중률을 높일 수 있습니다. S3 File Gateway의 CacheHitPercent 지표를 통해 이를 모니터링할 수 있습니다.

쓰기 작업이 많은 워크로드(예: 백업 및 아카이브용)의 경우 S3 File Gateway는이 데이터를 Amazon S3에 비동기식으로 복사하기 전에 디스크 캐시의 수신 쓰기를 버퍼링합니다. 작성된 데이터를 버퍼링할 수 있는 충분한 캐시 용량이 있는지 확인해야 합니다. CachePercentDirty 지표는 아직 유지되지 않은 디스크 캐시의 백분율을 나타냅니다 AWS.

의 낮은 값이 바람CachePercentDirty직합니다. 일관되게 100%에 가까운 값은 S3 File Gateway가 수신 쓰기 트래픽 속도를 따라갈 수 없음을 나타냅니다. 프로비저닝된 디스크 캐시 용량을 늘리거나 S3 File Gateway에서 Amazon S3로 사용 가능한 전용 네트워크 대역폭을 늘리거나 둘 다 늘리면 이를 방지할 수 있습니다.

캐시 디스크 크기 조정에 대한 자세한 내용은 공식 Amazon Web Services YouTube 채널의 Amazon S3 File Gateway 캐시 크기 조정 모범 사례를 참조하세요. YouTube

여러 파일 공유 및 Amazon S3 버킷 작업

여러 게이트웨이 또는 파일 공유가 버킷에 쓸 수 있도록 단일 Amazon S3 버킷을 구성하면 결과를 예측할 수 없습니다. 예측할 수 없는 결과를 방지하기 위해 두 가지 방법 중 하나로 버킷을 구성할 수 있습니다. 다음 옵션 중에서 사용 사례에 가장 적합한 구성 방법을 선택합니다.

  • 각 버킷에 하나의 파일 공유만 쓸 수 있도록 S3 버킷을 구성합니다. 다른 파일 공유를 사용하여 각 버킷에 씁니다.

    이렇게 하려면 특정 파일 공유에 사용되는 역할을 제외한 모든 역할을 거부하여 버킷에 객체를 넣거나 삭제하는 S3 버킷 정책을 생성합니다. 각 버킷에 작성할 다른 파일 공유를 지정하여 각 버킷에 유사한 정책을 연결합니다.

    다음 예제 정책은 버킷을 생성한 역할을 제외한 모든 역할에 대한 S3 버킷 쓰기 권한을 거부합니다. s3:DeleteObject를 제외한 모든 역할에 대해 s3:PutObject"TestUser" 작업이 거부됩니다. 이 정책은 "arn:aws:s3:::amzn-s3-demo-bucket/*" 버킷의 모든 객체에 적용됩니다.

    JSON
    { "Version":"2012-10-17", "Statement":[ { "Sid":"DenyMultiWrite", "Effect":"Deny", "Principal":"*", "Action":[ "s3:DeleteObject", "s3:PutObject" ], "Resource":"arn:aws:s3:::amzn-s3-demo-bucket/*", "Condition":{ "StringNotLike":{ "aws:userid":"TestUser:*" } } } ] }
  • 여러 파일 공유를 동일한 Amazon S3 버킷에 쓰려면 파일 공유가 동일한 객체에 동시에 쓰려고 시도하지 않도록 해야 합니다.

    이렇게 하려면 각 파일 공유에 대해 별도의 고유한 객체 접두사를 구성합니다. 즉, 각 파일 공유는 해당 접두사가 있는 객체에만 쓰고 배포의 다른 파일 공유와 연결된 객체에는 쓰지 않습니다. 새 파일 공유를 생성할 때 S3 접두사 이름 필드에서 객체 접두사를 구성합니다.

불필요한 리소스 정리

예기치 않거나 불필요한 요금이 발생하지 않도록 Storage Gateway 리소스를 정리하는 것이 가장 좋습니다. 예를 들어 데모 연습 또는 테스트로 게이트웨이를 생성한 경우 배포에서 게이트웨이와 가상 어플라이언스를 삭제하는 것이 좋습니다. 다음 절차에 따라 리소스를 정리합니다.

필요 없는 리소스를 정리하려면
  1. 더 이상 게이트웨이를 계속 사용할 계획이 없는 경우 삭제합니다. 자세한 내용은 게이트웨이 삭제 및 연결된 리소스 제거 단원을 참조하십시오.

  2. 온프레미스 호스트에서 Storage Gateway VM을 삭제합니다. Amazon EC2 인스턴스에서 게이트웨이를 생성한 경우에는 해당 인스턴스를 종료합니다.