문제 해결: 파일 공유 문제 - AWS Storage Gateway
파일 공유가 CREATING 상태에서 멈춤파일 공유를 생성할 수 없음SMB 파일 공유는 여러 가지 다른 액세스 방법을 허용하지 않습니다.매핑된 S3 버킷에 여러 파일 공유를 쓸 수 없음감사 로그 사용 시 삭제된 로그 그룹에 대한 알림S3 버킷에 파일을 업로드할 수 없음기본 암호화를 SSE-KMS로 변경할 수 없음객체 버전 관리가 켜져 있는 S3 버킷에서 직접 변경하면 파일 공유에 표시되는 내용에 영향을 미칠 수 있습니다.버전 관리가 켜져 있는 S3 버킷에 쓸 때 Amazon S3 File Gateway는 여러 버전의 Amazon S3 객체를 생성할 수 있습니다.S3 버킷에 대한 변경 사항은 Storage Gateway에 반영되지 않습니다.ACL 권한이 예상대로 작동하지 않음재귀 작업 후 게이트웨이 성능이 저하됨

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

문제 해결: 파일 공유 문제

아래와 같이 파일 공유와 관련해 예기치 않은 문제를 겪는 경우 취해야 할 조치에 대한 정보를 얻을 수 있습니다.

파일 공유가 생성 중 상태로 멈춤

파일 공유가 생성되는 동안에는 상태가 CREATING입니다. 파일 공유가 생성되면 상태가 AVAILABLE 상태로 전환됩니다. 파일 공유가 CREATING 상태로 고착된 경우 다음을 수행합니다.

  1. https://console.aws.amazon.com/s3/에서 S3 콘솔을 엽니다.

  2. 파일 공유를 매핑한 S3 버킷이 존재하는지 확인합니다. 존재하지 않으면 버킷을 생성합니다. 버킷을 생성하면 파일 공유 상태가 AVAILABLE 상태로 전환됩니다. S3 버킷을 생성하는 방법에 대한 자세한 내용은 Amazon Simple Storage Service 사용 설명서의 버킷 생성을 참조하세요.

  3. 버킷 이름이 Amazon S3의 버킷 이름 지정 규칙을 준수하는지 확인합니다. 자세한 내용은 Amazon Simple Storage Service 사용 설명서의 버킷 이름 지정 규칙을 참조하세요.

    참고

    S3 File Gateway는 버킷 이름에 마침표(.)가 있는 Amazon S3 버킷을 지원하지 않습니다.

  4. S3 버킷에 액세스하는 데 사용한 IAM 역할에 올바른 권한이 있는지 확인하고 S3 버킷이 IAM 정책에 리소스로 나열되어 있는지 확인합니다. 자세한 내용은 Amazon S3 버킷에 대한 액세스 권한 부여 단원을 참조하십시오.

파일 공유를 생성할 수 없습니다.

  1. 파일 공유가 생성 중 상태로 유지되어 파일 공유를 생성할 수 없는 경우 파일 공유를 매핑한 S3 버킷이 존재하는지 확인합니다. 이에 관한 자세한 내용은 위 파일 공유가 생성 중 상태로 멈춤 단원을 참조하십시오.

  2. S3 버킷이 있는 경우 파일 공유를 생성하는 리전에서 AWS Security Token Service 가 활성화되어 있는지 확인합니다. 보안 토큰이 활성화되지 않은 경우 활성화해야 합니다. 를 사용하여 토큰을 활성화하는 방법에 대한 자세한 내용은 IAM 사용 설명서의 AWS 리전에서 AWS STS 활성화 및 비활성화를 AWS Security Token Service참조하세요.

SMB 파일 공유는 여러 가지 다른 액세스 방법을 허용하지 않습니다.

SMB 파일 공유에는 다음과 같은 제약 조건이 있습니다.

  1. 동일한 클라이언트가 Active Directory 및 게스트 액세스 SMB 파일 공유를 모두 탑재하려고 시도하면 다음 오류 메시지가 표시됩니다. Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again.

  2. Windows 사용자는 두 개의 게스트 액세스 SMB 파일 공유에 연결된 상태를 유지할 수 없으며 새 게스트 액세스 연결이 설정되면 연결이 끊어질 수 있습니다.

  3. Windows 클라이언트는 게스트 액세스와 동일한 게이트웨이에서 내보낸 Active Directory SMB 파일 공유를 모두 탑재할 수 없습니다.

매핑된 S3 버킷에 여러 파일 공유를 쓸 수 없음

여러 파일 공유가 하나의 S3 버킷에 쓸 수 있도록 S3 버킷을 구성하는 것은 권장하지 않습니다. 이 접근 방법은 예기치 않은 결과를 유발할 수 있습니다.

각 S3 버킷에 하나의 파일 공유만 쓸 수 있도록 허용하는 것이 좋습니다. 파일 공유와 연결된 역할만 버킷에 쓸 수 있도록 허용하는 버킷 정책을 생성합니다. 자세한 내용은 파일 게이트웨이 모범 사례를 참조하세요.

감사 로그 사용 시 삭제된 로그 그룹에 대한 알림

로그 그룹이 없는 경우 사용자는 해당 메시지 아래의 로그 그룹 링크를 선택하여 새 로그 그룹을 생성하거나 기존 로그 그룹을 사용하여 감사 로그의 대상으로 사용할 수 있습니다.

S3 버킷에 파일을 업로드할 수 없음

S3 버킷에 파일을 업로드할 수 없는 경우 다음을 수행합니다.

  1. Amazon S3 File Gateway가 S3 버킷에 파일을 업로드하는 데 필요한 액세스 권한을 부여했는지 확인합니다. 자세한 내용은 Amazon S3 버킷에 대한 액세스 권한 부여 단원을 참조하십시오.

  2. 버킷을 생성한 역할이 S3 버킷에 쓸 수 있는 권한이 있는지 확인합니다. 자세한 내용은 파일 게이트웨이 모범 사례를 참조하세요.

  3. 파일 게이트웨이가 암호화에 SSE-KMS 또는 DSSE-KMS를 사용하는 경우 파일 공유와 연결된 IAM 역할에 kms:Encrypt, kms:Decrypt, kms:ReEncrypt*, kms:GenerateDataKey 및 kms:DescribeKey 권한이 포함되어 있는지 확인합니다. 자세한 내용은 Storage Gateway에 자격 증명 기반 정책(IAM 정책) 사용을 참조하세요.

SSE-KMS를 사용하여 S3 버킷에 저장된 객체를 암호화하도록 기본 암호화를 변경할 수 없음

기본 암호화를 변경하고 SSE-KMS( AWS KMS관리형 키를 사용한 서버 측 암호화)를 S3 버킷의 기본값으로 설정하면 Amazon S3 File Gateway가 버킷에 저장하는 객체는 SSE-KMS로 암호화되지 않습니다. 기본적으로 S3 File Gateway는 S3 버킷에 데이터를 쓸 때 Amazon S3(SSE-S3)로 관리되는 서버 측 암호화를 사용합니다. 기본값을 변경해도 암호화가 자동으로 변경되지 않습니다.

자체 AWS KMS 키와 함께 SSE-KMS를 사용하도록 암호화를 변경하려면 SSE-KMS 암호화를 켜야 합니다. 이때는 파일 공유를 생성하면서 KMS 키의 Amazon 리소스 이름(ARN)을 입력합니다. 그 밖에 UpdateNFSFileShare 또는 UpdateSMBFileShare API 작업을 통해 파일 공유에 대한 KMS 설정을 업데이트할 수도 있습니다. 이 업데이트는 업데이트 후 S3 버킷에 저장된 객체에 적용됩니다. 자세한 내용은 를 사용한 데이터 암호화 AWS KMS 단원을 참조하십시오.

객체 버전 관리가 켜져 있는 S3 버킷에서 직접 변경하면 파일 공유에 표시되는 내용에 영향을 미칠 수 있습니다.

S3 버킷에 다른 클라이언트가 작성한 객체가 있는 경우 S3 버킷 객체 버전 관리로 인해 S3 버킷 보기가 up-to-date 아닐 수 있습니다. 관심 있는 파일을 검사하기 전에 항상 캐시를 새로 고쳐야 합니다.

객체 버전 관리는 동일한 이름의 객체 사본을 여러 개 저장하여 데이터를 보호해 주는 S3 버킷의 옵션 기능입니다. 각 사본에는 서로 다른 ID 값이 있습니다(예: file1.jpg: ID="xxx" 및 file1.jpg: ID="yyy"). 이름이 동일한 객체의 수와 수명은 Amazon S3 수명 주기 정책에 의해 제어됩니다. 이러한 Amazon S3 개념에 대한 자세한 내용은 Amazon S3 개발자 안내서의 버전 관리 및 객체 수명 주기 관리 사용을 참조하세요. Amazon S3

버전이 지정된 객체를 삭제할 경우 해당 객체에 삭제 마커가 표시되지만 보존됩니다. S3 버킷 소유자만 버전 관리가 켜져 있는 객체를 영구적으로 삭제할 수 있습니다.

S3 File Gateway에서 표시된 파일은 객체를 가져오거나 캐시를 새로 고친 시점의 S3 버킷에 있는 객체의 최신 버전입니다. S3 File Gateway는 이전 버전이나 삭제 대상으로 표시된 객체를 무시합니다. 파일을 읽을 때 최신 버전에서 데이터를 읽습니다. 파일 공유에 파일을 작성하면 S3 File Gateway가 변경 사항과 함께 명명된 객체의 새 버전을 생성하며 해당 버전은 최신 버전이 됩니다.

S3 File Gateway는 이전 버전에서 계속 읽으며, 새 버전을 애플리케이션 외부의 S3 버킷에 추가하는 경우 업데이트는 이전 버전을 기반으로 합니다. 최신 버전의 객체를 읽으려면 RefreshCache API 작업을 사용하거나 Amazon S3 버킷 객체 캐시 새로 고침에 설명된 대로 콘솔에서 새로 고칩니다.

중요

파일 공유 외부에서 S3 File Gateway S3 버킷에 객체 또는 파일을 쓰지 않는 것이 좋습니다.

버전 관리가 켜져 있는 S3 버킷에 쓸 때 Amazon S3 File Gateway는 여러 버전의 Amazon S3 객체를 생성할 수 있습니다.

객체 버전 관리를 켜면 NFS 또는 SMB 클라이언트의 파일을 업데이트할 때마다 Amazon S3에 여러 버전의 객체가 생성될 수 있습니다. 다음은 S3 버킷에 여러 버전의 객체가 생성될 수 있는 시나리오입니다.

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

  • NFS 또는 SMB 클라이언트가 S3 File Gateway에 파일을 쓰면 S3 File Gateway는 파일의 데이터를 Amazon S3에 업로드한 다음 메타데이터(소유권, 타임스탬프 등)를 업로드합니다. 파일 데이터를 업로드하면 Amazon S3 객체가 생성되고 파일의 메타데이터를 업로드하면 Amazon S3 객체의 메타데이터가 업데이트됩니다. 이 프로세스는 객체의 다른 버전을 생성하여 객체의 두 버전을 생성합니다.

  • S3 File Gateway가 더 큰 파일을 업로드하는 경우 클라이언트가 File Gateway에 쓰기를 완료하기 전에 작은 파일 청크를 업로드해야 할 수 있습니다. 여기에는 캐시 공간을 확보하거나 파일에 대한 쓰기 속도가 높은 경우가 포함됩니다. 이로 인해 S3 버킷에 여러 버전의 객체가 생성될 수 있습니다.

객체를 다른 스토리지 클래스로 이동하도록 수명 주기 정책을 설정하기 전에 S3 버킷을 모니터링하여 객체의 버전 수를 확인해야 합니다. S3 버킷의 객체에 대한 버전 수를 최소화하려면 이전 버전의 수명 주기 만료를 구성해야 합니다. S3 버킷 간에 동일 리전 복제(SRR) 또는 교차 리전 복제(CRR)를 사용하면 사용되는 스토리지가 증가합니다. 복제에 대한 자세한 내용은 복제를 참조하세요.

중요

객체 버전 관리가 켜져 있을 때 사용되는 스토리지의 양을 이해할 때까지 S3 버킷 간 복제를 구성하지 마십시오.

버전이 지정된 S3 버킷을 사용하면 파일을 수정할 때마다 새 버전의 Amazon S3 S3의 스토리지 양이 크게 증가할 수 있습니다. 기본적으로 Amazon S3는이 동작을 재정의하고 보관되는 버전 수를 제한하는 정책을 특별히 생성하지 않는 한 이러한 모든 버전을 계속 저장합니다. 객체 버전 관리가 켜져 있는 상태에서 스토리지 사용량이 비정상적으로 큰 경우 스토리지 정책이 적절하게 설정되어 있는지 확인합니다. 브라우저 요청에 대한 HTTP 503-slow down 응답 수 증가도 객체 버전 관리 문제로 인해 발생한 결과일 수 있습니다.

S3 File Gateway를 설치한 후 객체 버전 관리를 켜면 모든 고유 객체가 보존되고(ID=”NULL”) 파일 시스템에서 모든 객체를 볼 수 있습니다. 새 버전의 객체에는 고유한 ID가 할당됩니다(이전 버전은 유지됨). 객체의 타임스탬프를 기반으로 최신 버전의 객체만 NFS 파일 시스템에서 볼 수 있습니다.

객체 버전 관리를 켠 후에는 S3 버킷을 버전이 지정되지 않은 상태로 되돌릴 수 없습니다. 그러나 버전 관리를 일시 중지할 수는 있습니다. 버전 관리를 일시 중지하면 새 객체에 ID가 할당됩니다. 동일한 이름의 객체가 ID=”NULL” 값으로 존재하는 경우, 이전 버전을 덮어쓰게 됩니다. 그러나 NULL이 아닌 ID가 포함된 모든 버전은 유지됩니다. 타임스탬프는 새 객체를 최신 객체로 식별하며, 이 객체가 NFS 파일 시스템에 표시됩니다.

S3 버킷에 대한 변경 사항은 Storage Gateway에 반영되지 않습니다.

Storage Gateway는 파일 공유를 사용하여 로컬에서 캐시에 파일을 쓸 때 파일 공유 캐시를 자동으로 업데이트합니다. 그러나 파일을 Amazon S3에 직접 업로드할 때 Storage Gateway는 캐시를 자동으로 업데이트하지 않습니다. 이렇게 하려면 작업을 수행하여 파일 공유의 변경 사항을 RefreshCache 확인해야 합니다. 파일 공유가 두 개 이상인 경우 각 파일 공유에서 RefreshCache 작업을 실행해야 합니다.

Storage Gateway 콘솔과 (AWS CLI)를 사용하여 캐시를 새로 고칠 수 있습니다. AWS Command Line Interface

  • Storage Gateway 콘솔을 사용하여 캐시를 새로 고치려면 Amazon S3 버킷의 객체 새로 고침을 참조하세요.

  • 를 사용하여 캐시를 새로 고치려면 AWS CLI:

    1. 명령 실행 aws storagegateway list-file-shares

    2. 파일 공유의 Amazon 리소스 번호(ARN)를 새로 고치려는 캐시로 복사합니다.

    3. ARN을의 값으로 사용하여 refresh-cache 명령을 실행합니다--file-share-arn.

      aws storagegateway refresh-cache --file-share-arn arn:aws:storagegateway:eu-west-1:12345678910:share/share-FFDEE12

RefreshCache 작업을 자동화하려면 Storage Gateway에서 RefreshCache 작업을 자동화하려면 어떻게 해야 합니까?를 참조하세요.

ACL 권한이 예상대로 작동하지 않음

ACL(액세스 제어 목록) 권한이 SMB 파일 공유에서 예상대로 작동하지 않을 경우에는 테스트를 실시하십시오.

먼저 Microsoft Windows 파일 서버 또는 로컬 Windows 파일 공유에서 권한을 테스트해봅니다. 그런 다음 그 동작을 게이트웨이의 파일 공유와 비교합니다.

재귀 작업을 수행한 후 게이트웨이 성능이 저하되었습니다.

경우에 따라 디렉터리 이름을 바꾸거나 ACL에 대한 상속을 켜는 등의 재귀 작업을 수행하고 트리를 강제로 중단할 수 있습니다. 이렇게 하면 S3 File Gateway가 파일 공유의 모든 객체에 작업을 재귀적으로 적용합니다.

예를 들어 S3 버킷의 기존 객체에 상속을 적용한다고 가정해 보겠습니다. S3 File Gateway는 버킷의 모든 객체에 상속을 재귀적으로 적용합니다. 이러한 작업 때문에 게이트웨이 성능이 거부될 수 있습니다.