기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # Storage Gateway 배포 문제 해결 다음에서 게이트웨이, 호스트 플랫폼, 가상 테이프, 고가용성, 데이터 복구 및 보안과 관련된 모범 사례 및 문제 해결에 관한 정보를 찾을 수 있습니다. 온프레미스 게이트웨이 문제 해결 정보는 지원되는 가상화 플랫폼에 배포된 게이트웨이를 다룹니다. 고가용성 문제에 대한 문제 해결 정보는 VMware vSphere HA(고가용성) 플랫폼에서 실행 중인 게이트웨이를 다룹니다. **주제** + [문제 해결: 게이트웨이 오프라인 문제](troubleshooting-gateway-offline.md) - Storage Gateway 콘솔에서 게이트웨이가 오프라인으로 표시될 수 있는 문제를 진단하는 방법에 대해 알아봅니다. + [문제 해결: Active Directory 문제](troubleshooting-active-directory.md) - File Gateway를 Microsoft Active Directory 도메인에 조인하려고 할 때 `NETWORK_ERROR`, `TIMEOUT` 또는 `ACCESS_DENIED`와 같은 오류 메시지가 수신되면 어떻게 해야 하는지 알아봅니다. + [문제 해결: 게이트웨이 활성화 문제](troubleshooting-gateway-activation.md) - Storage Gateway 활성화를 시도할 때 내부 오류 메시지가 표시되는 경우에 취해야 할 조치에 대해 알아봅니다. + [문제 해결: 온프레미스 게이트웨이 문제](troubleshooting-on-premises-gateway-issues.md) - 온프레미스 게이트웨이 작업 시 발생할 수 있는 일반적인 문제와가 게이트웨이에 지원 연결하여 문제 해결을 지원하는 방법을 알아봅니다. + [문제 해결: Microsoft Hyper-V 설정 관련 문제](troubleshooting-hyperv-setup.md) - Microsoft Hyper-V 플랫폼에 Storage Gateway를 배포할 때 발생할 수 있는 일반적인 문제에 대해 알아봅니다. + [문제 해결: Amazon EC2 게이트웨이 문제](troubleshooting-EC2-gateway-issues.md) - Amazon EC2에 배포된 게이트웨이로 작업할 때 발생할 수 있는 일반적인 문제에 대한 정보를 찾을 수 있습니다. + [문제 해결: 하드웨어 어플라이언스 문제](troubleshooting-hardware-appliance-issues.md) - AWS Storage Gateway 하드웨어 어플라이언스에서 발생할 수 있는 문제를 해결하는 방법을 알아봅니다. + [문제 해결: File Gateway 문제](troubleshooting-file-gateway-issues.md) - File Gateway의 CloudWatch 로그에 나타나는 오류 및 상태 알림의 원인을 이해하는 데 도움이 되는 정보를 찾습니다. + [문제 해결: 파일 공유 문제](troubleshooting-file-share-issues.md) - 파일 공유에 예기치 않은 문제가 발생하는 경우 취할 수 있는 조치에 대해 알아봅니다. + [문제 해결: 고가용성 문제](troubleshooting-ha-issues.md) - VMware HA 환경에 배포된 게이트웨이에 문제가 발생하는 경우 취해야 할 조치에 대해 알아봅니다. # 문제 해결: Storage Gateway 콘솔에서 게이트웨이 오프라인 다음 문제 해결 정보를 참조하여 AWS Storage Gateway 콘솔에서 게이트웨이가 오프라인 상태인 것으로 표시되는 경우에 취해야 할 조치를 결정하세요. 다음 중 하나 이상의 이유로 게이트웨이가 오프라인으로 표시될 수 있습니다. + 게이트웨이가 Storage Gateway 서비스 엔드포인트에 연결할 수 없습니다. + 게이트웨이가 예기치 않게 종료되었습니다. + 게이트웨이와 연결된 캐시 디스크가 연결 해제 또는 수정되었거나 실패했습니다. 게이트웨이를 다시 온라인 상태로 되돌리려면 게이트웨이를 오프라인 상태로 만든 문제를 파악하여 해결합니다. ## 연결된 방화벽 또는 프록시 확인 프록시를 사용하도록 게이트웨이를 구성했거나 게이트웨이를 방화벽 뒤에 배치한 경우 프록시 또는 방화벽의 액세스 규칙을 검토합니다. 프록시 또는 방화벽은 Storage Gateway에 필요한 네트워크 포트 및 서비스 엔드포인트와의 트래픽을 허용해야 합니다. 자세한 내용은 [네트워크 및 방화벽 요구 사항](https://docs.aws.amazon.com/filegateway/latest/files3/Requirements.html#networks)을 참조하세요. ## 게이트웨이 트래픽에 대해 SSL 또는 딥패킷 검사가 진행 중인지 확인 게이트웨이와 간의 네트워크 트래픽에 대해 SSL 또는 딥 패킷 검사가 현재 수행 중인 AWS경우 게이트웨이가 필요한 서비스 엔드포인트와 통신하지 못할 수 있습니다. 게이트웨이를 다시 온라인 상태로 되돌리려면 검사를 비활성화해야 합니다. ## 재부팅 또는 소프트웨어 업데이트 후 IOWaitPercent 지표 확인 재부팅 또는 소프트웨어 업데이트 후 File Gateway의 `IOWaitPercent` 지표가 10 이상인지 확인합니다. 이 경우 인덱스 캐시를 RAM에 다시 빌드하는 동안 게이트웨이의 응답 속도가 느려질 수 있습니다. 자세한 내용은 [문제 해결: CloudWatch 지표 사용](https://docs.aws.amazon.com/filegateway/latest/files3/troubleshooting-file-gateway-issues.html#gateway-not-responding)을 참조하세요. ## 하이퍼바이저 호스트의 정전 또는 하드웨어 장애 확인 게이트웨이의 하이퍼바이저 호스트에서 정전 또는 하드웨어 장애가 발생하면 게이트웨이가 예기치 않게 종료되어 연결이 불가능해질 수 있습니다. 전원 및 네트워크 연결을 복원하면 게이트웨이에 다시 연결할 수 있게 됩니다. 게이트웨이가 다시 온라인 상태가 되면 데이터 복구 조치를 취해야 합니다. 자세한 내용은 [모범 사례: 데이터 복구](https://docs.aws.amazon.com/filegateway/latest/files3/recover-data-from-gateway.html)를 참조하세요. ## 연결된 캐시 디스크에 문제가 있는지 확인 게이트웨이와 연결된 캐시 디스크 중 하나 이상이 제거, 변경 또는 크기 조정되었거나 손상된 경우 게이트웨이가 오프라인 상태가 될 수 있습니다. **하이퍼바이저 호스트에서 작동 중인 캐시 디스크를 제거한 경우** 1. 게이트웨이를 종료합니다. 1. 디스크를 다시 추가합니다. **참고** 동일한 디스크 노드에 디스크를 추가해야 합니다. 1. 게이트웨이를 다시 시작합니다. **캐시 디스크가 손상되었거나 교체되었거나 크기가 조정된 경우** + [기존 S3 File Gateway를 새 인스턴스로 교체](https://docs.aws.amazon.com/filegateway/latest/files3/migrate-data.html#replace-instance-file-gateway)에 설명된 **방법 2** 절차에 따라 새 게이트웨이를 설정하고 AWS 클라우드에서 캐시 디스크 정보를 다시 다운로드합니다. # 문제 해결: 게이트웨이를 Active Directory에 조인하는 문제 다음 문제 해결 정보를 사용하여 File Gateway를 Microsoft Active Directory 도메인에 조인하려고 할 때 `NETWORK_ERROR`, `TIMEOUT` 또는 `ACCESS_DENIED`와 같은 오류 메시지가 수신되는 경우 수행할 작업을 결정합니다. 이러한 오류를 해결하려면 다음 확인 및 구성을 수행합니다. ## nping 테스트를 실행하여 게이트웨이가 도메인 컨트롤러에 도달할 수 있는지 확인 **nping 테스트를 실행하려면:** 1. 온프레미스 게이트웨이용 하이퍼바이저 관리 소프트웨어(VMware, Hyper-V 또는 KVM) 또는 Amazon EC2 게이트웨이용 ssh를 사용하여 게이트웨이 로컬 콘솔에 연결합니다. 1. 해당 숫자를 입력하여 **게이트웨이 콘솔**을 선택한 다음 `h`를 입력하여 사용 가능한 모든 명령을 나열합니다. Storage Gateway 가상 머신과 도메인 간의 연결을 테스트하려면 다음 명령을 실행합니다. `nping -d corp.domain.com -p 389 -c 1 -t tcp` **참고** `corp.domain.com`을 Active Directory 도메인 DNS 이름으로 바꾸고 `389`를 환경의 LDAP 포트로 바꿉니다. 방화벽 내에서 필요한 포트를 열었는지 확인합니다. 다음은 게이트웨이가 도메인 컨트롤러에 도달할 수 있었던 성공적인 nping 테스트의 예입니다. ``` nping -d corp.domain.com -p 389 -c 1 -t tcp Starting Nping 0.6.40 ( http://nmap.org/nping ) at 2022-06-30 16:24 UTC SENT (0.0553s) TCP 10.10.10.21:9783 > 10.10.10.10:389 S ttl=64 id=730 iplen=40 seq=2597195024 win=1480 RCVD (0.0556s) TCP 10.10.10.10:389 > 10.10.10.21:9783 SA ttl=128 id=22332 iplen=44 seq=4170716243 win=8192 Max rtt: 0.310ms | Min rtt: 0.310ms | Avg rtt: 0.310ms Raw packets sent: 1 (40B) | Rcvd: 1 (44B) | Lost: 0 (0.00%) Nping done: 1 IP address pinged in 1.09 seconds
``` 다음은 `corp.domain.com` 대상과의 연결 또는 응답이 없는 nping 테스트의 예입니다. ``` nping -d corp.domain.com -p 389 -c 1 -t tcp Starting Nping 0.6.40 ( http://nmap.org/nping ) at 2022-06-30 16:26 UTC SENT (0.0421s) TCP 10.10.10.21:47196 > 10.10.10.10:389 S ttl=64 id=30318 iplen=40 seq=1762671338 win=1480 Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A Raw packets sent: 1 (40B) | Rcvd: 0 (0B) | Lost: 1 (100.00%) Nping done: 1 IP address pinged in 1.07 seconds ``` ## Amazon EC2 게이트웨이 인스턴스의 VPC에 설정된 DHCP 옵션 확인 File Gateway가 Amazon EC2 인스턴스에서 실행 중인 경우 DHCP 옵션 세트가 올바르게 구성되고 게이트웨이 인스턴스가 포함된 Amazon Virtual Private Cloud(Amazon VPC)에 연결되어 있는지 확인해야 합니다. 자세한 정보는 [Amazon VPC의 DHCP 옵션 세트](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html)를 참조하세요. ## 게이트웨이가 dig 쿼리를 실행하여 도메인을 확인할 수 있는지 확인 게이트웨이에서 도메인을 확인할 수 없는 경우 게이트웨이는 도메인에 조인할 수 없습니다. **dig 쿼리를 실행하려면:** 1. 온프레미스 게이트웨이용 하이퍼바이저 관리 소프트웨어(VMware, Hyper-V 또는 KVM) 또는 Amazon EC2 게이트웨이용 ssh를 사용하여 게이트웨이 로컬 콘솔에 연결합니다. 1. 해당 숫자를 입력하여 **게이트웨이 콘솔**을 선택한 다음 `h`를 입력하여 사용 가능한 모든 명령을 나열합니다. 게이트웨이가 도메인을 확인할 수 있는지 테스트하려면 다음 명령을 실행합니다. `dig -d corp.domain.com` **참고** `corp.domain.com`을 Active Directory 도메인 DNS 이름으로 바꿉니다. 다음은 성공적인 응답의 예입니다. ``` ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.5.2 <<>> corp.domain.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24817 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4000 ;; QUESTION SECTION: ;corp.domain.com. IN A ;; ANSWER SECTION: corp.domain.com. 600 IN A 10.10.10.10 corp.domain.com. 600 IN A 10.10.20.10 ;; Query time: 0 msec ;; SERVER: 10.10.20.228#53(10.10.20.228) ;; WHEN: Thu Jun 30 16:36:32 UTC 2022 ;; MSG SIZE rcvd: 78 ``` ## 도메인 컨트롤러 설정 및 역할 확인 도메인 컨트롤러가 읽기 전용으로 설정되어 있지 않고 도메인 컨트롤러에 컴퓨터가 조인할 수 있는 충분한 역할이 있는지 확인합니다. 이를 테스트하려면 게이트웨이 VM과 동일한 VPC 서브넷의 다른 서버를 도메인에 조인해 보십시오. ## 게이트웨이가 가장 가까운 도메인 컨트롤러에 조인되었는지 확인 게이트웨이 어플라이언스와 지리적으로 가까운 도메인 컨트롤러에 게이트웨이를 조인하는 것이 좋습니다. 게이트웨이 어플라이언스가 네트워크 지연 시간으로 인해 20초 이내에 도메인 컨트롤러와 통신할 수 없는 경우 도메인 조인 프로세스가 시간 초과될 수 있습니다. 예를 들어 게이트웨이 어플라이언스가 미국 동부(버지니아 북부)에 AWS 리전 있고 도메인 컨트롤러가 아시아 태평양(싱가포르)에 있는 경우 프로세스가 시간 초과될 수 있습니다 AWS 리전. **참고** 기본 제한 시간 값을 20초로 늘리려면 AWS Command Line Interface (AWS CLI)에서 [join-domain 명령을](https://docs.aws.amazon.com/cli/latest/reference/storagegateway/join-domain.html) 실행하고 시간을 늘리는 `--timeout-in-seconds` 옵션을 포함할 수 있습니다. [JoinDomain API 호출](https://amazonaws.com/storagegateway/latest/APIReference/API_JoinDomain.html)을 사용하고 `TimeoutInSeconds` 파라미터를 포함하여 시간을 늘릴 수도 있습니다. 최대 제한 시간 값은 3,600초입니다. AWS CLI 명령을 실행할 때 오류가 발생하면 최신 AWS CLI 버전을 사용하고 있는지 확인합니다. ## Active Directory가 기본 조직 단위(OU)에 새 컴퓨터 객체를 생성하는지 확인 Microsoft Active Directory에 기본 OU 이외의 위치에 새 컴퓨터 객체를 생성하는 그룹 정책 객체가 없는지 확인합니다. 게이트웨이를 Active Directory 도메인에 조인하려면 먼저 기본 OU에 새 컴퓨터 객체가 있어야 합니다. 일부 Active Directory 환경은 새로 생성된 객체에 대해 서로 다른 OU를 갖도록 사용자 지정됩니다. 게이트웨이 VM의 새 컴퓨터 객체가 기본 OU에 있는지 확인하려면 게이트웨이를 도메인에 조인하기 전에 도메인 컨트롤러에서 수동으로 컴퓨터 객체를 생성해 보십시오. AWS CLI를 사용하여 [join-domain 명령](https://docs.aws.amazon.com/cli/latest/reference/storagegateway/join-domain.html)을 실행할 수도 있습니다. 그런 다음 `--organizational-unit`에 대한 옵션을 지정합니다. **참고** 컴퓨터 객체를 생성하는 프로세스를 사전 스테이징이라고 합니다. ## 도메인 컨트롤러 이벤트 로그 확인 이전 섹션에 설명된 다른 모든 검사 및 구성을 시도한 후 게이트웨이를 도메인에 조인할 수 없는 경우 도메인 컨트롤러 이벤트 로그를 검사하는 것이 좋습니다. 도메인 컨트롤러의 이벤트 뷰어에 오류가 있는지 확인합니다. 게이트웨이 쿼리가 도메인 컨트롤러에 도달했는지 확인합니다. # 문제 해결: 게이트웨이 활성화 중 내부 오류 발생 Storage Gateway 활성화 요청은 두 개의 네트워크 경로를 통과합니다. 클라이언트에서 보낸 수신 활성화 요청은 포트 80을 통해 게이트웨이의 가상 머신(VM) 또는 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스에 연결됩니다. 게이트웨이가 활성화 요청을 성공적으로 수신하면 게이트웨이는 Storage Gateway 엔드포인트와 통신하여 활성화 키를 받습니다. 게이트웨이가 Storage Gateway 엔드포인트에 연결할 수 없는 경우 게이트웨이는 내부 오류 메시지를 표시하며 클라이언트에 응답합니다. 다음 문제 해결 정보를 참조하여 AWS Storage Gateway를 활성화하려고 할 때 내부 오류 메시지가 표시되는 경우에 취해야 할 조치를 결정하세요. **참고** 최신 가상 머신 이미지 파일 또는 Amazon Machine Image(AMI) 버전을 사용하여 새 게이트웨이를 배포해야 합니다. 오래된 AMI를 사용하는 게이트웨이를 활성화하려고 하면 내부 오류가 발생합니다. AMI를 다운로드하기 전에 배포하려는 올바른 게이트웨이 유형을 선택해야 합니다. 각 게이트웨이 유형의 .ova 파일과 AMI는 서로 다르므로 서로 바꾸어 사용할 수 없습니다. ## 퍼블릭 엔드포인트를 사용하여 게이트웨이를 활성화할 때 발생하는 오류 해결 퍼블릭 엔드포인트를 사용하여 게이트웨이를 활성화할 때 발생하는 활성화 오류를 해결하려면 다음 확인 및 구성을 수행합니다. ### 필수 포트 확인 온프레미스에 배포된 게이트웨이의 경우 로컬 방화벽에서 포트가 열려 있는지 확인합니다. Amazon EC2 인스턴스에 배포된 게이트웨이의 경우 인스턴스의 보안 그룹에서 포트가 열려 있는지 확인합니다. 포트가 열려 있는지 확인하려면 서버의 퍼블릭 엔드포인트에서 텔넷 명령을 실행합니다. 이 서버는 게이트웨이와 동일한 서브넷에 있어야 합니다. 예를 들어 다음 텔넷 명령은 포트 443에 대한 연결을 테스트합니다. ``` telnet d4kdq0yaxexbo.cloudfront.net 443 telnet storagegateway.region.amazonaws.com 443 telnet dp-1.storagegateway.region.amazonaws.com 443 telnet proxy-app.storagegateway.region.amazonaws.com 443 telnet client-cp.storagegateway.region.amazonaws.com 443 telnet anon-cp.storagegateway.region.amazonaws.com 443 ``` 게이트웨이 자체가 엔드포인트에 접속할 수 있는지 확인하려면 게이트웨이의 로컬 VM 콘솔에 액세스합니다(온프레미스에 배포된 게이트웨이의 경우). 또는 게이트웨이 인스턴스에 SSH로 접속할 수 있습니다(Amazon EC2에 배포된 게이트웨이의 경우). 그런 다음 네트워크 연결 테스트를 실행합니다. 테스트가 `[PASSED]`를 반환하는지 확인합니다. 자세한 내용은 [게이트웨이의 네트워크 연결 테스트](https://docs.aws.amazon.com/filegateway/latest/files3/manage-on-premises-fgw.html#MaintenanceTestGatewayConnectivity-fgw)를 참조하세요. **참고** 게이트웨이 콘솔의 기본 로그인 사용자 이름은 `admin`이고 기본 암호는 `password`입니다. ### 방화벽 보안으로 게이트웨이에서 퍼블릭 엔드포인트로 전송되는 패킷이 수정되지 않도록 확인 SSL 검사, 심층 패킷 검사 또는 기타 형태의 방화벽 보안으로 인해 게이트웨이에서 전송된 패킷이 방해받을 수 있습니다. SSL 인증서가 활성화 엔드포인트에서 예상하는 것과 다르게 수정되면 SSL 핸드셰이크가 실패합니다. 진행 중인 SSL 검사가 없는지 확인하려면 포트 443의 기본 활성화 엔드포인트(`anon-cp.storagegateway.region.amazonaws.com`)에서 OpenSSL 명령을 실행합니다. 이 명령은 게이트웨이와 동일한 서브넷에 있는 시스템에서 실행해야 합니다. ``` $ openssl s_client -connect anon-cp.storagegateway.region.amazonaws.com:443 -servername anon-cp.storagegateway.region.amazonaws.com ``` **참고** *region*을 로 바꿉니다 AWS 리전. 진행 중인 SSL 검사가 없는 경우 명령은 다음과 유사한 응답을 반환합니다. ``` $ openssl s_client -connect anon-cp.storagegateway.us-east-2.amazonaws.com:443 -servername anon-cp.storagegateway.us-east-2.amazonaws.com CONNECTED(00000003) depth=2 C = US, O = Amazon, CN = Amazon Root CA 1 verify return:1 depth=1 C = US, O = Amazon, OU = Server CA 1B, CN = Amazon verify return:1 depth=0 CN = anon-cp.storagegateway.us-east-2.amazonaws.com verify return:1 --- Certificate chain 0 s:/CN=anon-cp.storagegateway.us-east-2.amazonaws.com i:/C=US/O=Amazon/OU=Server CA 1B/CN=Amazon 1 s:/C=US/O=Amazon/OU=Server CA 1B/CN=Amazon i:/C=US/O=Amazon/CN=Amazon Root CA 1 2 s:/C=US/O=Amazon/CN=Amazon Root CA 1 i:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./CN=Starfield Services Root Certificate Authority - G2 3 s:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./CN=Starfield Services Root Certificate Authority - G2 i:/C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification Authority --- ``` SSL 검사가 진행 중이면 다음과 같이 변경된 인증서 체인이 응답에 표시됩니다. ``` $ openssl s_client -connect anon-cp.storagegateway.ap-southeast-1.amazonaws.com:443 -servername anon-cp.storagegateway.ap-southeast-1.amazonaws.com CONNECTED(00000003) depth=0 DC = com, DC = amazonaws, OU = AWS, CN = anon-cp.storagegateway.ap-southeast-1.amazonaws.com verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 DC = com, DC = amazonaws, OU = AWS, CN = anon-cp.storagegateway.ap-southeast-1.amazonaws.com verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/DC=com/DC=amazonaws/OU=AWS/CN=anon-cp.storagegateway.ap-southeast-1.amazonaws.com i:/C=IN/O=Company/CN=Admin/ST=KA/L=New town/OU=SGW/emailAddress=admin@company.com --- ``` 활성화 엔드포인트는 SSL 인증서를 인식하는 경우에만 SSL 핸드셰이크를 허용합니다. 즉, 엔드포인트에 대한 게이트웨이의 아웃바운드 트래픽은 네트워크의 방화벽에서 수행하는 검사에서 제외되어야 합니다. 이러한 검사는 SSL 검사 또는 심층 패킷 검사일 수 있습니다. ### 게이트웨이 시간 동기화 확인 시간 편차가 지나치게 크면 SSL 핸드셰이크 오류가 발생할 수 있습니다. 온프레미스 게이트웨이의 경우 게이트웨이의 로컬 VM 콘솔을 사용하여 게이트웨이의 시간 동기화를 확인할 수 있습니다. 시간 편차는 60초 이내여야 합니다. 자세한 내용은 [게이트웨이 VM 시간 동기화](https://docs.aws.amazon.com/filegateway/latest/files3/MaintenanceTimeSync-hyperv.html)를 참조하세요. Amazon EC2 인스턴스에서 호스팅되는 게이트웨이에서는 **시스템 시간 관리** 옵션을 사용할 수 없습니다. Amazon EC2 게이트웨이의 시간 동기화가 제대로 이루어질 수 있도록 하려면 Amazon EC2 인스턴스가 포트 UDP 및 TCP 123을 통해 다음 NTP 서버 풀 목록에 연결할 수 있는지 확인합니다. + time.aws.com + 0.amazon.pool.ntp.org + 1.amazon.pool.ntp.org + 2.amazon.pool.ntp.org + 3.amazon.pool.ntp.org ## Amazon VPC 엔드포인트를 사용하여 게이트웨이를 활성화할 때 발생하는 오류 해결 Amazon Virtual Private Cloud(Amazon VPC) 엔드포인트를 사용하여 게이트웨이를 활성화할 때 발생하는 활성화 오류를 해결하려면 다음 확인 및 구성을 수행합니다. ### 필수 포트 확인 필수 포트가 로컬 방화벽(온프레미스에 배포된 게이트웨이의 경우) 또는 보안 그룹(Amazon EC2에 배포된 게이트웨이의 경우) 내에서 열려 있는지 확인합니다. 게이트웨이를 Storage Gateway VPC 엔드포인트에 연결하는 데 필요한 포트는 게이트웨이를 퍼블릭 엔드포인트에 연결할 때 필요한 포트와 다릅니다. Storage Gateway VPC 엔드포인트에 연결하려면 다음 포트가 필요합니다. + TCP 443 + TCP 1026 + TCP 1027 + TCP 1028 + TCP 1031 + TCP 2222 자세한 내용은 [Storage Gateway용 VPC 엔드포인트 생성](https://docs.aws.amazon.com/filegateway/latest/files3/gateway-private-link.html#create-vpc-endpoint)을 참조하세요. 또한 Storage Gateway VPC 엔드포인트에 연결된 보안 그룹을 확인합니다. 엔드포인트에 연결된 기본 보안 그룹에서 필수 포트를 허용하지 않을 수 있습니다. 게이트웨이의 IP 주소 범위에서 필수 포트를 통해 트래픽을 허용하는 새 보안 그룹을 생성합니다. 그런 다음 해당 보안 그룹을 VPC 엔드포인트에 연결합니다. **참고** [Amazon VPC 콘솔](https://console.aws.amazon.com//vpc/)을 사용하여 VPC 엔드포인트에 연결된 보안 그룹을 확인합니다. 콘솔에서 Storage Gateway VPC 엔드포인트를 확인한 후 **보안 그룹** 탭을 선택합니다. 필수 포트가 열려 있는지 확인하려면 Storage Gateway VPC 엔드포인트에서 텔넷 명령을 실행할 수 있습니다. 이 명령은 게이트웨이와 동일한 서브넷에 있는 서버에서 실행해야 합니다. 가용 영역을 지정하지 않은 첫 번째 DNS 이름에 대해 테스트를 실행할 수 있습니다. 예를 들어 다음 텔넷 명령은 DNS 이름 vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com을 사용하여 필수 포트 연결을 테스트합니다. ``` telnet vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com 443 telnet vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com 1026 telnet vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com 1027 telnet vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com 1028 telnet vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com 1031 telnet vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com 2222 ``` ### 방화벽 보안으로 게이트웨이에서 Storage Gateway Amazon VPC 엔드포인트로 전송되는 패킷이 수정되지 않도록 확인 SSL 검사, 심층 패킷 검사 또는 기타 형태의 방화벽 보안으로 인해 게이트웨이에서 전송된 패킷이 방해받을 수 있습니다. SSL 인증서가 활성화 엔드포인트에서 예상하는 것과 다르게 수정되면 SSL 핸드셰이크가 실패합니다. 진행 중인 SSL 검사가 없는지 확인하려면 Storage Gateway VPC 엔드포인트에서 OpenSSL 명령을 실행합니다. 이 명령은 게이트웨이와 동일한 서브넷에 있는 시스템에서 실행해야 합니다. 각 필수 포트에 대해 명령을 실행합니다. ``` $ openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:443 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com $ openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:1026 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com $ openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:1027 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com $ openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:1028 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com $ openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:1031 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com $ openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:2222 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com ``` 진행 중인 SSL 검사가 없는 경우 명령은 다음과 유사한 응답을 반환합니다. ``` openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:1027 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com CONNECTED(00000005) depth=2 C = US, O = Amazon, CN = Amazon Root CA 1 verify return:1 depth=1 C = US, O = Amazon, OU = Server CA 1B, CN = Amazon verify return:1 depth=0 CN = anon-cp.storagegateway.us-east-1.amazonaws.com verify return:1 --- Certificate chain 0 s:CN = anon-cp.storagegateway.us-east-1.amazonaws.com i:C = US, O = Amazon, OU = Server CA 1B, CN = Amazon 1 s:C = US, O = Amazon, OU = Server CA 1B, CN = Amazon i:C = US, O = Amazon, CN = Amazon Root CA 1 2 s:C = US, O = Amazon, CN = Amazon Root CA 1 i:C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Services Root Certificate Authority - G2 3 s:C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Services Root Certificate Authority - G2 i:C = US, O = "Starfield Technologies, Inc.", OU = Starfield Class 2 Certification Authority --- ``` SSL 검사가 진행 중이면 다음과 같이 변경된 인증서 체인이 응답에 표시됩니다. ``` openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:1027 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com CONNECTED(00000005) depth=2 C = US, O = Amazon, CN = Amazon Root CA 1 verify return:1 depth=1 C = US, O = Amazon, OU = Server CA 1B, CN = Amazon verify return:1 depth=0 DC = com, DC = amazonaws, OU = AWS, CN = anon-cp.storagegateway.us-east-1.amazonaws.com verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/DC=com/DC=amazonaws/OU=AWS/CN=anon-cp.storagegateway.us-east-1.amazonaws.com i:/C=IN/O=Company/CN=Admin/ST=KA/L=New town/OU=SGW/emailAddress=admin@company.com --- ``` 활성화 엔드포인트는 SSL 인증서를 인식하는 경우에만 SSL 핸드셰이크를 허용합니다. 즉, 필수 포트를 통과하는 게이트웨이의 VPC 엔드포인트 아웃바운드 트래픽은 네트워크 방화벽에서 수행하는 검사에서 제외됩니다. 이러한 검사는 SSL 검사 또는 심층 패킷 검사일 수 있습니다. ### 게이트웨이 시간 동기화 확인 시간 편차가 지나치게 크면 SSL 핸드셰이크 오류가 발생할 수 있습니다. 온프레미스 게이트웨이의 경우 게이트웨이의 로컬 VM 콘솔을 사용하여 게이트웨이의 시간 동기화를 확인할 수 있습니다. 시간 편차는 60초 이내여야 합니다. 자세한 내용은 [게이트웨이 VM 시간 동기화](https://docs.aws.amazon.com/filegateway/latest/files3/MaintenanceTimeSync-hyperv.html)를 참조하세요. Amazon EC2 인스턴스에서 호스팅되는 게이트웨이에서는 **시스템 시간 관리** 옵션을 사용할 수 없습니다. Amazon EC2 게이트웨이의 시간 동기화가 제대로 이루어질 수 있도록 하려면 Amazon EC2 인스턴스가 포트 UDP 및 TCP 123을 통해 다음 NTP 서버 풀 목록에 연결할 수 있는지 확인합니다. + 0.amazon.pool.ntp.org + 1.amazon.pool.ntp.org + 2.amazon.pool.ntp.org + 3.amazon.pool.ntp.org ### HTTP 프록시 확인 및 관련 보안 그룹 설정 확인 활성화하기 전에 온프레미스 게이트웨이 VM에서 Amazon EC2의 HTTP 프록시가 포트 3128에서 Squid 프록시로 구성되어 있는지 확인합니다. 이 경우 다음 사항을 확인합니다. + Amazon EC2의 HTTP 프록시에 연결된 보안 그룹에는 인바운드 규칙이 있어야 합니다. 이 인바운드 규칙은 게이트웨이 VM의 IP 주소에서 포트 3128의 Squid 프록시 트래픽을 허용해야 합니다. + Amazon EC2 VPC 엔드포인트에 연결된 보안 그룹에는 인바운드 규칙이 있어야 합니다. 이러한 인바운드 규칙은 Amazon EC2의 HTTP 프록시 IP 주소에서 포트 1026-1028, 1031, 2222 및 443의 트래픽을 허용해야 합니다. ## 퍼블릭 엔드포인트를 사용하여 게이트웨이를 활성화하는 중 동일한 VPC에 Storage Gateway VPC 엔드포인트가 있을 때 발생하는 오류 해결 퍼블릭 엔드포인트를 사용하여 게이트웨이를 활성화하는 중 동일한 VPC에 Amazon Virtual Private Cloud(Amazon VPC) 엔드포인트가 있을 때 발생하는 오류를 해결하려면 다음 확인 및 구성을 수행합니다. ### Storage Gateway VPC 엔드포인트에서 **프라이빗 DNS 이름 활성화** 설정이 활성화되어 있지 않은지 확인합니다. **프라이빗 DNS 이름 활성화**가 활성화된 경우 해당 VPC에서 퍼블릭 엔드포인트로의 게이트웨이를 활성화할 수 없습니다. **프라이빗 DNS 이름 옵션을 비활성화하려면** 1. [Amazon VPC 콘솔](https://console.aws.amazon.com//vpc/)을 엽니다. 1. 탐색 창에서 **엔드포인트**를 선택합니다. 1. Storage Gateway VPC 엔드포인트를 선택합니다. 1. **작업**을 선택합니다. 1. **프라이빗 DNS 이름 관리**를 선택합니다. 1. **프라이빗 DNS 이름 활성화**에서 **이 엔드포인트에 대해 활성화**를 선택 취소합니다. 1. **프라이빗 DNS 이름 수정**을 선택하여 설정을 저장합니다. # 문제 해결: 온프레미스 게이트웨이 문제 온프레미스 게이트웨이에서 발생할 수 있는 일반적인 문제와가 게이트웨이에 지원 연결하여 문제 해결을 지원하는 방법에 대한 다음 정보를 찾을 수 있습니다. 다음 표는 온프레미스 게이트웨이 관련 작업 시 발생할 수 있는 전형적인 문제를 나열한 것입니다. | 문제 | 취할 조치 | | --- | --- | | 게이트웨이의 IP 주소를 찾을 수 없습니다. | 하이퍼바이저 클라이언트로 호스트에 접속하여 게이트웨이 IP 주소를 찾습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/filegateway/latest/files3/troubleshooting-on-premises-gateway-issues.html) 그래도 게이트웨이 IP 주소를 찾기 어려운 경우: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/filegateway/latest/files3/troubleshooting-on-premises-gateway-issues.html) | | 네트워크 또는 방화벽에 문제가 있습니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/filegateway/latest/files3/troubleshooting-on-premises-gateway-issues.html) | | Storage Gateway Management Console에서 **활성화 진행** 버튼을 클릭하면 게이트웨이 활성화가 실패합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/filegateway/latest/files3/troubleshooting-on-premises-gateway-issues.html) | | 게이트웨이와 AWS간 대역폭을 개선해야 합니다. | 애플리케이션 및 게이트웨이 VM을 연결하는 것과 별도로 네트워크 어댑터(NIC) AWS 에서에 대한 인터넷 연결을 설정 AWS 하여 게이트웨이에서 로 대역폭을 개선할 수 있습니다. 이 접근 방식은에 고대역폭으로 연결되어 AWS 있고 특히 스냅샷 복원 중에 대역폭 경합을 피하려는 경우에 유용합니다. 고처리량 워크로드 요구 사항을 충족하기 위해 [Direct Connect](https://aws.amazon.com/directconnect/)를 사용하여 온프레미스 게이트웨이와 AWS간에 전용 네트워크 연결을 설정할 수 있습니다. 게이트웨이에서 로의 연결 대역폭을 측정하려면 게이트웨이의 `CloudBytesDownloaded` 및 `CloudBytesUploaded` 지표를 AWS사용합니다. 이에 관한 자세한 내용은 [성능 및 최적화](Performance.md) 섹션을 참조하세요. 인터넷 연결성을 개선하면 업로드 버퍼가 꽉 차지 않도록 하는 데 도움이 됩니다. | | 게이트웨이로의 처리량 또는 게이트웨이로부터의 처리량이 0으로 떨어집니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/filegateway/latest/files3/troubleshooting-on-premises-gateway-issues.html) 게이트웨이와 주고받는 처리량은 Amazon CloudWatch 콘솔에서 확인할 수 있습니다. 게이트웨이와 주고받는 처리량 측정에 대한 자세한 내용은 섹션을 AWS참조하세요[성능 및 최적화](Performance.md). | | Microsoft Hyper-V에서 Storage Gateway를 가져오기(배포)하는 데 문제가 있습니다. | Microsoft Hyper-V에서 게이트웨이를 배포할 때 흔히 겪는 몇 가지 문제를 다루는 [문제 해결: Microsoft Hyper-V 설](troubleshooting-hyperv-setup.md) 섹션을 참조하세요. | | "게이트웨이의 볼륨에 기록된 데이터가 AWS에 안전하게 저장되지 않았습니다."라는 메시지가 표시됩니다. | 게이트웨이 VM이 또 다른 게이트웨이 VM의 복제 또는 스냅샷으로부터 생성된 경우 이 메시지를 수신하게 됩니다. 그렇지 않은 경우 지원에 문의하세요. | ## 문제 해결: 보안 스캔에서 열린 NFS 포트 표시 특정 NFS 포트는 SMB 파일 공유에만 사용하는 게이트웨이에서도 기본적으로 활성화됩니다. Qualys와 같은 타사 보안 소프트웨어를 사용하여 File Gateway가 배포된 네트워크를 스캔하는 경우 스캔 결과에서 이러한 열린 NFS 포트를 잠재적 보안 취약성으로 보고할 수 있습니다. 게이트웨이를 SMB 파일 공유에만 사용하고 보안상의 이유로 사용하지 않는 NFS 포트를 비활성화하려는 경우 다음 절차를 사용합니다. **File Gateway에서 NFS 포트를 비활성화하려면:** 1. [로컬 콘솔에서 Storage Gateway 명령 실행](MaintenanceGatewayConsole-fgw.md)에 설명된 절차를 사용하여 게이트웨이 로컬 콘솔 명령 프롬프트에 액세스합니다. 1. NFS 트래픽을 비활성화하려면 다음 명령을 입력하십시오. **IPv4** ``` iptables -I INPUT -p udp -m udp --dport 111 -j DROP iptables -I INPUT -p udp -m udp --dport 2049 -j DROP iptables -I INPUT -p udp -m udp --dport 20048 -j DROP iptables -I INPUT -p tcp -m tcp --dport 111 -j DROP iptables -I INPUT -p tcp -m tcp --dport 2049 -j DROP iptables -I INPUT -p tcp -m tcp --dport 20048 -j DROP ``` **IPv6** ``` ip6tables -I INPUT -p udp -m udp --dport 111 -j DROP ip6tables -I INPUT -p udp -m udp --dport 2049 -j DROP ip6tables -I INPUT -p udp -m udp --dport 20048 -j DROP ip6tables -I INPUT -p tcp -m tcp --dport 111 -j DROP ip6tables -I INPUT -p tcp -m tcp --dport 2049 -j DROP ip6tables -I INPUT -p tcp -m tcp --dport 20048 -j DROP ``` 1. 다음 명령을 입력하여 차단된 NFS 포트가 IP 테이블에 나타나는지 확인합니다. **IPv4** ``` iptables -n -L -v --line-numbers ``` **IPv6** ``` ip6tables -n -L -v --line-numbers ``` ## 온프레미스에서 호스팅되는 게이트웨이 문제를 해결하는 데 도움이 되는 지원 액세스 활성화 Storage Gateway는 게이트웨이 문제 해결을 지원하기 위해가 게이트웨이에 지원 액세스할 수 있도록 허용하는 등 여러 유지 관리 작업을 수행하는 데 사용할 수 있는 로컬 콘솔을 제공합니다. 기본적으로 게이트웨이에 대한 지원 액세스는 꺼져 있습니다. 호스트의 로컬 콘솔을 통해 이 액세스 권한을 활성화합니다. 게이트웨이에 대한 지원 액세스 권한을 부여하려면 먼저 호스트의 로컬 콘솔에 로그인하고 Storage Gateway의 콘솔로 이동한 다음 지원 서버에 연결합니다. **게이트웨이에 대한 지원 액세스를 켜려면** 1. 호스트의 로컬 콘솔에 로그인합니다. + VMware ESXi - 자세한 내용은 [VMware ESXi를 사용하여 게이트웨이 로컬 콘솔에 액세스](accessing-local-console.md#MaintenanceConsoleWindowVMware-common) 섹션을 참조하세요. + Microsoft Hyper-V - 자세한 내용은 [Microsoft Hyper-V를 사용하여 게이트웨이 로컬 콘솔에 액세스](accessing-local-console.md#MaintenanceConsoleWindowHyperV-common) 섹션을 참조하세요. 1. 프롬프트에서 해당 숫자를 입력하여 **게이트웨이 콘솔**을 선택합니다. 1. **h**를 입력하여 사용 가능한 명령 목록을 엽니다. 1. 다음 중 하나를 수행하세요. + 게이트웨이에서 퍼블릭 엔드포인트를 사용 중인 경우 **사용 가능한 명령** 창에 **open-support-channel**을 입력하여 Storage Gateway의 고객 지원에 연결합니다. AWS에 대한 지원 채널을 열 수 있도록 TCP 포트 22를 허용합니다. 고객 지원에 연결할 때 Storage Gateway는 지원 번호를 할당합니다. 지원 번호를 기록해 둡니다. + 게이트웨이가 VPC 엔드포인트를 사용 중인 경우 **AVAILABLE COMMANDS(사용 가능한 명령)** 창에 **open-support-channel**을 입력합니다. 게이트웨이가 활성화되지 않은 경우 Storage Gateway에 대한 고객 지원에 연결할 VPC 엔드포인트 또는 IP 주소를 제공합니다. AWS에 대한 지원 채널을 열 수 있도록 TCP 포트 22를 허용합니다. 고객 지원에 연결할 때 Storage Gateway는 지원 번호를 할당합니다. 지원 번호를 기록해 둡니다. **참고** 채널 번호는 TCP/UDP(Transmission Control Protocol/User Datagram Protocol) 포트 번호가 아닙니다. 그 대신에 게이트웨이는 Storage Gateway 서버에 Secure Shell(SSH)(TCP 22)로 접속하여 해당 연결에 지원 채널을 제공합니다. 1. 지원 채널이 설정되면가 문제 해결 지원을 제공할 지원 수 지원 있도록에 지원 서비스 번호를 제공합니다. 1. 지원 세션이 완료되면 **q**를 입력하여 세션을 종료합니다. Amazon Web Services Support에서 지원 세션이 완료되었음을 알릴 때까지 세션을 닫지 마십시오. 1. **exit**를 입력하여 Storage Gateway 콘솔에서 로그아웃합니다. 1. 프롬프트 메시지에 따라 로컬 콘솔을 종료합니다. # 문제 해결: Microsoft Hyper-V 설 다음 표는 Microsoft Hyper-V 플랫폼에 Storage Gateway를 배포할 때 발생할 수 있는 일반적인 문제를 나열한 것입니다. | 문제 | 취할 조치 | | --- | --- | | 게이트웨이를 가져오려고 하는데 다음과 같은 오류 메시지가 표시됩니다. "가상 머신을 가져오는 동안 서버 오류가 발생했습니다. 가져오기에 실패했습니다. [...] 위치에서 가상 머신 가져오기 파일을 찾을 수 없습니다. Hyper-V를 사용하여 가상 머신을 생성하고 내보낸 경우에만 가상 머신을 가져올 수 있습니다." | 이 오류는 다음과 같은 이유로 발생할 수 있습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/filegateway/latest/files3/troubleshooting-hyperv-setup.html) | | 게이트웨이를 가져오려고 하는데 다음과 같은 오류 메시지가 표시됩니다. "가상 머신을 가져오는 동안 서버 오류가 발생했습니다. 가져오기에 실패했습니다. 가져오기 작업이 [...]에서 파일을 복사하지 못했습니다. 파일이 존재합니다. (0x80070050)" | 이미 게이트웨이를 배포하고 가상 하드 디스크 및 가상 머신 구성 파일이 저장된 기본 폴더를 다시 사용하는 경우, 이 오류가 발생합니다. 이 문제를 해결하려면 **Hyper-V 설정** 대화 상자의 왼쪽 패널에서 **서버** 아래에 새 위치를 지정합니다. | | 게이트웨이를 가져오려고 하는데 다음과 같은 오류 메시지가 표시됩니다. "가상 머신을 가져오는 동안 서버 오류가 발생했습니다. 가져오기에 실패했습니다. Import failed because the virtual machine must have a new identifier. Select a new identifier and try the import again."라는 오류 메시지가 표시됩니다. | 게이트웨이를 가져올 때 **가상 머신 가져오기** 대화 상자에서 **가상 머신 복사** 옵션과 **모든 파일 복제** 옵션을 선택하여 VM의 새 고유 ID를 생성해야 합니다. | | 게이트웨이 VM을 시작하려고 하는데 다음과 같은 오류 메시지가 나타납니다. “선택한 가상 머신을 시작하는 동안 오류가 발생했습니다. 하위 파티션 프로세서 설정이 상위 파티션과 호환되지 않습니다. 'AWS-Storage-Gateway'를 초기화할 수 없습니다. (가상 머신 ID [...])" | 이 오류는 게이트웨이에 필요한 CPU와 호스트에서 사용 가능한 CPU 사이의 CPU 불일치로 인해 발생할 수 있습니다. 기본 하이퍼바이저가 VM CPU 개수를 지원하도록 해야 합니다. Storage Gateway 요구 사항에 대한 자세한 내용은 [File Gateway 설정 요구 사항](Requirements.md) 섹션을 참조하세요. | | 게이트웨이 VM을 시작하려고 하는데 다음과 같은 오류 메시지가 나타납니다. “선택한 가상 머신을 시작하는 동안 오류가 발생했습니다. 'AWS-Storage-Gateway'를 초기화할 수 없습니다. (가상 머신 ID [...]) 파티션을 생성하지 못했습니다. 요청된 서비스를 완료하는 데 필요한 시스템 리소스가 부족합니다. (0x800705AA)" | 이 오류는 게이트웨이에 필요한 RAM과 호스트에서 사용 가능한 RAM 사이의 RAM 불일치로 인해 발생할 수 있습니다. Storage Gateway 요구 사항에 대한 자세한 내용은 [File Gateway 설정 요구 사항](Requirements.md) 섹션을 참조하세요. | | 스냅샷 및 게이트웨이 소프트웨어 업데이트는 예상과 약간 다른 시각에 실행됩니다. | 게이트웨이 VM의 클럭은 실제 시간과 약간 오차가 있을 수 있는데, 이를 클럭 드리프트라고 합니다. 로컬 게이트웨이 콘솔의 시간 동기화 옵션을 사용하여 VM의 시간을 점검하고 수정합니다. 자세한 내용은 [게이트웨이의 네트워크 시간 프로토콜(NTP) 서버 구성](MaintenanceTimeSync-fgw.md) 단원을 참조하십시오. | | 압축 해제된 Microsoft Hyper-V Storage Gateway 파일은 호스트 파일 시스템에 저장해야 합니다. | 일반적인 Microsoft Windows 서버에 액세스하듯이 호스트에 액세스합니다. 예를 들어 하이퍼바이저 호스트의 이름이 `hyperv-server`인 경우에는 다음과 같이 UNC 경로인 `\\hyperv-server\c$`를 사용할 수 있습니다. 이 경로는 `hyperv-server`라는 이름을 로컬 호스트 파일에서 확인할 수 있거나 정의한다고 가정합니다. | | 하이퍼바이저에 접속할 때 자격 증명을 요구하는 메시지가 표시됩니다. | Sconfig.cmd 도구를 사용하여 사용자 자격 증명을 하이퍼바이저 호스트용 로컬 관리자로 추가합니다. | | Broadcom 네트워크 어댑터를 사용하는 Hyper-V 호스트에 대해 가상 머신 대기열(VMQ)을 켜면 네트워크 성능이 저하될 수 있습니다. | 해결 방법에 대한 자세한 내용은 Microsoft 설명서 [VMQ가 켜져 있는 경우 Windows Server 2012 Hyper-V 호스트의 가상 머신에서 네트워크 성능이 저하됨](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/poor-network-performance-hyper-v-host-vm)을 참조하세요. | # 문제 해결: Amazon EC2 게이트웨이 문제 다음 섹션에서는 Amazon EC2에 배포된 게이트웨이를 사용할 때 발생할 수 있는 일반적인 문제를 확인할 수 있습니다. 온프레미스 게이트웨이와 Amazon EC2에 배포한 게이트웨이 간의 차이점에 대한 자세한 내용은 [S3 File Gateway용 기본 Amazon EC2 호스트 배포S3 File Gateway용 사용자 지정 Amazon EC2 호스트 배포](ec2-gateway-file.md) 섹션을 참조하세요. 휘발성 스토리지 사용에 대한 자세한 내용은 [휘발성 스토리지와 EC2 게이트웨이를 함께 사용](ephemeral-disk-cache.md) 섹션을 참조하세요. **Topics** + [몇 분 후 게이트웨이가 활성화되지 않음](#activation-issues) + [인스턴스 목록에서 EC2 게이트웨이 인스턴스를 찾을 수 없음](#find-instance) + [Amazon EC2 직렬 콘솔을 사용하여 게이트웨이 인스턴스에 연결하려는 경우](#ec2-serial-console) + [Amazon EC2 게이트웨이 문제를 해결하는 지원 데 도움이 필요한 경우](#EC2-EnableAWSSupportAccess) ## 몇 분 후 게이트웨이가 활성화되지 않음 Amazon EC2 콘솔에서 다음 사항을 확인하세요. + 인스턴스와 연결한 보안 그룹에서 포트 80이 열려 있습니다. 보안 그룹 규칙 추가에 대한 자세한 내용은 *Amazon EC2 사용 설명서*에서 [보안 그룹 규칙 추가](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html#adding-security-group-rule)를 참조하세요. + 게이트웨이 인스턴스는 실행 중으로 표시됩니다. Amazon EC2 콘솔에서 인스턴스의 **상태** 값은 RUNNING이어야 합니다. + [스토리지 요구 사항](Requirements.md#requirements-storage)에 설명된 대로 Amazon EC2 인스턴스 유형은 최소 요구 사항을 충족하는지 여부. 문제를 해결한 후 게이트웨이를 다시 활성화합니다. 이렇게 하려면 Storage Gateway 콘솔을 열고 **Amazon EC2에 새 게이트웨이 배포**를 선택한 다음 인스턴스의 IP 주소를 다시 입력합니다. ## 인스턴스 목록에서 EC2 게이트웨이 인스턴스를 찾을 수 없음 인스턴스에 리소스 태그를 지정하지 않았는데 많은 수의 인스턴스가 실행 중인 경우에는 어떤 인스턴스를 실행했는지 파악하기 어려울 수 있습니다. 이 경우 다음 작업을 수행하여 해당 게이트웨이 인스턴스를 찾을 수 있습니다. + 인스턴스의 **설명** 탭에서 Amazon Machine Image(AMI)의 이름을 확인합니다. Storage Gateway AMI 기반 인스턴스는 **aws-storage-gateway-ami**라는 텍스트로 시작해야 합니다. + Storage Gateway AMI 기반 인스턴스가 여러 개인 경우, 인스턴스 시작 시간을 확인하여 올바른 인스턴스를 찾습니다. ## Amazon EC2 직렬 콘솔을 사용하여 게이트웨이 인스턴스에 연결하려는 경우 Amazon EC2 직렬 콘솔을 사용하여 부팅, 네트워크 구성 및 기타 문제를 해결할 수 있습니다. 지침과 문제 해결 팁은 *Amazon Elastic Compute Cloud 사용 설명서*의 [Amazon EC2 직렬 콘솔](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-serial-console.html) 섹션을 참조하세요. ## Amazon EC2 게이트웨이 문제를 해결하는 지원 데 도움이 필요한 경우 Storage Gateway는 게이트웨이 문제 해결을 지원하기 위해가 게이트웨이에 지원 액세스할 수 있도록 허용하는 등 여러 유지 관리 작업을 수행하는 데 사용할 수 있는 로컬 콘솔을 제공합니다. 기본적으로 게이트웨이에 대한 지원 액세스는 꺼져 있습니다. Amazon EC2 로컬 콘솔을 통해 이 액세스 권한을 활성화 합니다. Secure Shell(SSH)을 통해 Amazon EC2 로컬 콘솔에 로그인합니다. SSH를 통해 성공적으로 로그인하려면 인스턴스의 보안 그룹에 TCP 포트 22를 개방하는 규칙이 있어야 합니다. **참고** 기존 보안 그룹에 새 규칙을 추가할 경우, 해당 보안 그룹을 사용하는 모든 인스턴스에 새 규칙이 적용됩니다. 보안 그룹 및 보안 그룹 규칙을 추가하는 방법에 대한 자세한 내용은 Amazon EC2 사용 설명서에서 [Amazon EC2 보안 그룹](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html)을 참조하세요.** 가 게이트웨이에 지원 연결되도록 하려면 먼저 Amazon EC2 인스턴스의 로컬 콘솔에 로그인하고 Storage Gateway의 콘솔로 이동한 다음 액세스를 제공합니다. **Amazon EC2 인스턴스에 배포된 게이트웨이에 대한 지원 액세스를 켜려면** 1. Amazon EC2 인스턴스의 로컬 콘솔에 로그인합니다. 지침은 Amazon EC2 사용 설명서에서 [인스턴스에 연결](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstances.html)을 참조하세요.** 다음 명령을 사용하여 EC2 인스턴스의 로컬 콘솔에 로그인할 수 있습니다. ``` ssh –i PRIVATE-KEY admin@INSTANCE-PUBLIC-DNS-NAME ``` **참고** *PRIVATE-KEY*는 Amazon EC2 인스턴스를 시작할 때 사용한 EC2 키 페어의 프라이빗 인증서를 포함하는 `.pem` 파일입니다. 자세한 내용은 Amazon EC2 사용 설명서에서 [키 페어의 퍼블릭 키 검색](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html#retriving-the-public-key)을 참조하세요.** The *INSTANCE-PUBLIC-DNS-NAME*은 게이트웨이가 실행 중인 Amazon EC2 인스턴스의 퍼블릭 도메인 이름 시스템(DNS) 이름입니다. 이 퍼블릭 DNS 이름을 확인하려면 EC2 콘솔에서 Amazon EC2 인스턴스를 선택하고 **설명** 탭을 클릭합니다. 1. 프롬프트에 **6 - Command Prompt**를 입력하여 지원 채널 콘솔을 엽니다. 1. **h**를 입력하여 **AVAILABLE COMMANDS(사용 가능한 명령)** 창을 엽니다. 1. 다음 중 하나를 수행하세요. + 게이트웨이에서 퍼블릭 엔드포인트를 사용 중인 경우 **사용 가능한 명령** 창에 **open-support-channel**을 입력하여 Storage Gateway의 고객 지원에 연결합니다. AWS에 대한 지원 채널을 열 수 있도록 TCP 포트 22를 허용합니다. 고객 지원에 연결할 때 Storage Gateway는 지원 번호를 할당합니다. 지원 번호를 기록해 둡니다. + 게이트웨이가 VPC 엔드포인트를 사용 중인 경우 **AVAILABLE COMMANDS(사용 가능한 명령)** 창에 **open-support-channel**을 입력합니다. 게이트웨이가 활성화되지 않은 경우 Storage Gateway에 대한 고객 지원에 연결할 VPC 엔드포인트 또는 IP 주소를 제공합니다. AWS에 대한 지원 채널을 열 수 있도록 TCP 포트 22를 허용합니다. 고객 지원에 연결할 때 Storage Gateway는 지원 번호를 할당합니다. 지원 번호를 기록해 둡니다. **참고** 채널 번호는 TCP/UDP(Transmission Control Protocol/User Datagram Protocol) 포트 번호가 아닙니다. 그 대신에 게이트웨이는 Storage Gateway 서버에 Secure Shell(SSH)(TCP 22)로 접속하여 해당 연결에 지원 채널을 제공합니다. 1. 지원 채널이 설정되면가 문제 해결 지원을 제공할 지원 수 지원 있도록에 지원 서비스 번호를 제공합니다. 1. 지원 세션이 완료되면 **q**를 입력하여 세션을 종료합니다. Amazon Web Services Support에서 지원 세션이 완료되었음을 알릴 때까지 세션을 닫지 마십시오. 1. **exit**를 입력하여 Storage Gateway 콘솔을 종료합니다. 1. 콘솔 메뉴에 따라 Storage Gateway 인스턴스에서 로그아웃합니다. # 문제 해결: 하드웨어 어플라이언스 문제 **참고** 가용성 종료 공지: 2025년 5월 12일부터 AWS Storage Gateway 하드웨어 어플라이언스가 더 이상 제공되지 않습니다. AWS Storage Gateway 하드웨어 어플라이언스를 사용하는 기존 고객은 2028년 5월까지를 계속 사용하고 지원을 받을 수 있습니다. 또는 AWS Storage Gateway 서비스를 사용하여 온프레미스 및 클라우드 내 애플리케이션에 사실상 무제한의 클라우드 스토리지에 대한 액세스 권한을 부여할 수 있습니다. 다음 주제에서는 AWS Storage Gateway 하드웨어 어플라이언스에서 발생할 수 있는 문제와 이러한 문제 해결에 대한 제안 사항에 대해 설명합니다. **Topics** + [서비스 IP 주소를 확인할 수 없음](#service_ip_address) + [공장 초기화는 어떻게 수행하나요?](#factory_reset) + [원격 재시작은 어떻게 수행하나요?](#remote-restart) + [Dell iDRAC 지원은 어디에서 받을 수 있나요?](#iDRAC_support) + [하드웨어 어플라이언스 일련 번호를 찾을 수 없음](#appliance_serial_number) + [하드웨어 어플라이언스 지원은 어디에서 받을 수 있나요?](#appliance_support) ## 서비스 IP 주소를 확인할 수 없음 서비스에 연결할 때 호스트 IP 주소가 아닌 서비스의 IP 주소를 사용하고 있는지 확인합니다. 서비스 콘솔에서 서비스 IP 주소를 구성하고 하드웨어 콘솔에서 호스트 IP 주소를 구성합니다. 하드웨어 어플라이언스를 시작하면 하드웨어 콘솔이 표시됩니다. 하드웨어 콘솔에서 서비스 콘솔로 이동하려면 **Open Service Console(서비스 콘솔 열기)**을 선택합니다. ## 공장 초기화는 어떻게 수행하나요? 어플라이언스에서 공장 초기화를 수행해야 하는 경우 다음 지원 섹션에 설명된 대로 AWS Storage Gateway 하드웨어 어플라이언스 팀에 지원을 문의하세요. ## 원격 재시작은 어떻게 수행하나요? 어플라이언스를 원격으로 재시작해야 하는 경우 Dell iDRAC 관리 인터페이스를 사용하여 재시작할 수 있습니다. 자세한 내용은 Dell Technologies InfoHub 웹 사이트에서 [iDRAC9 Virtual Power Cycle: Remotely power cycle Dell EMC PowerEdge Servers](https://infohub.delltechnologies.com/en-us/p/idrac9-virtual-power-cycle-remotely-power-cycle-dell-emc-poweredge-servers/)를 참조하세요. ## Dell iDRAC 지원은 어디에서 받을 수 있나요? Dell PowerEdge 서버에는 Dell iDRAC 관리 인터페이스가 함께 제공됩니다. 다음과 같이 하는 것이 좋습니다: + iDRAC 관리 인터페이스를 사용하는 경우 기본 암호를 변경해야 합니다. iDRAC 자격 증명에 대한 자세한 내용은 [Dell PowerEdge - iDRAC의 기본 로그인 자격 증명은 무엇입니까?](https://www.dell.com/support/article/en-us/sln306783/dell-poweredge-what-is-the-default-username-and-password-for-idrac?lang=en)를 참조하세요. + 보안 위반을 막기 위해 펌웨어가 최신 버전인지 확인합니다. + iDRAC 네트워크 인터페이스를 일반(`em`) 포트로 이동하면 성능 문제가 발생하거나 어플라이언스가 정상적으로 작동하지 않을 수 있습니다. ## 하드웨어 어플라이언스 일련 번호를 찾을 수 없음 Storage AWS Storage Gateway 콘솔을 사용하여 Storage Gateway 하드웨어 어플라이언스의 일련 번호를 찾을 수 있습니다. **하드웨어 어플라이언스 일련 번호를 찾으려면** 1. Storage Gateway 콘솔([https://console.aws.amazon.com/storagegateway/home](https://console.aws.amazon.com/storagegateway/))을 엽니다. 1. 페이지 왼쪽의 탐색 메뉴에서 **하드웨어**를 선택합니다. 1. 목록에서 하드웨어 어플라이언스를 선택합니다. 1. 어플라이언스의 **세부 정보** 탭에서 **일련 번호** 필드를 찾습니다. ## 하드웨어 어플라이언스 지원은 어디에서 받을 수 있나요? 하드웨어 어플라이언스의 기술 지원에 AWS 대한 문의는 섹션을 참조하세요[지원](https://aws.amazon.com/contact-us). 지원 팀이 지원 채널을 활성화하여 게이트웨이 문제를 원격으로 해결하도록 요청할 수 있습니다. 게이트웨이의 정상 작업 중에는 이 포트를 열어둘 필요가 없지만, 문제 해결 시에는 필요합니다. 다음 절차에 나온 것처럼 하드웨어 콘솔에서 지원 채널을 활성화할 수 있습니다. **에 대한 지원 채널을 열려면 AWS** 1. 하드웨어 콘솔을 엽니다. 1. 하드웨어 콘솔의 메인 페이지 하단에서 **지원 채널 열기**를 선택한 다음 `Enter` 키를 누릅니다. 네트워크 연결 또는 방화벽 문제가 없는 경우 할당된 포트 번호가 30초 이내에 표시되어야 합니다. 예제: **상태: 포트 19599에서 열림** 1. 포트 번호를 기록하여에 제공합니다 지원. # 문제 해결: File Gateway 문제 Amazon CloudWatch 로그 그룹에 로그 항목을 기록하도록 File Gateway를 구성할 수 있습니다. 이 경우 게이트웨이의 상태 및 게이트웨이에서 발생한 오류에 대한 알림을 받습니다. 이러한 오류 및 상태 알림에 대한 정보는 CloudWatch Logs에서 찾을 수 있습니다. 이 섹션에서는 각 오류의 원인 및 상태 알림과 문제 해결 방법을 이해하는 데 도움이 되는 정보를 찾을 수 있습니다. **Topics** + [오류: 1344(0x00000540)](#troubleshoot-copying-files-to-s3) + [오류: GatewayClockOutOfSync](#troubleshoot-logging-errors-gatewayclockoutofsync) + [오류: InaccessibleStorageClass](#troubleshoot-logging-errors-inaccessiblestorageclass) + [오류: InvalidObjectState](#troubleshoot-logging-errors-invalidobjectstate) + [오류: ObjectMissing](#troubleshoot-logging-errors-objectmissing) + [오류: RoleTrustRelationshipInvalid](#misconfig-trust) + [오류: S3AccessDenied](#troubleshoot-logging-errors-s3accessdenied) + [오류: DroppedNotifications](#troubleshoot-logging-errors-droppednotifications) + [알림: HardReboot](#troubleshoot-hardreboot-notification) + [알림: 재부팅](#troubleshoot-reboot-notification) + [문제 해결: 보안 스캔에서 열린 NFS 포트 표시](#troubleshoot-open-nfs-ports) + [문제 해결: CloudWatch 지표 사용](#troubleshooting-with-cw-metrics) ## 오류: 1344(0x00000540) Amazon S3로 파일을 마이그레이션하는 동안 ACE(ACEs 제어 항목)가 10개 이상인 파일을 Amazon S3로 복사하려는 `ERROR 1344 (0x00000540)`가 발생할 수 있습니다. 액세스 제어 항목은 액세스 제어 목록(ACL)에 나열됩니다. Amazon S3 File Gateway는 지정된 파일 또는 폴더당 10개의 ACE 항목만 보존할 수 있습니다. **오류 1344 해결 방법: 대상 디렉터리에 NTFS 보안 복사.** 10개 이상의 항목이 포함된 파일 또는 폴더에 대한 Windows 권한의 항목 수를 줄입니다. 일반적인 접근 방식은 전체 항목 목록이 포함된 그룹을 생성한 다음 항목 목록을 해당 단일 그룹으로 바꾸는 것입니다. 항목 수가 10개보다 작으면 파일 또는 폴더를 게이트웨이에 다시 복사할 수 있습니다. ## 오류: GatewayClockOutOfSync 게이트웨이가 로컬 시스템 시간과 AWS Storage Gateway 서버에서 보고한 시간 간에 5분 이상의 차이를 감지하면 `GatewayClockOutOfSync` 오류가 발생할 수 있습니다. 클록 동기화 문제는 게이트웨이와 간의 연결에 부정적인 영향을 미칠 수 있습니다 AWS. 게이트웨이 클럭이 동기화되지 않은 경우 NFS 및 SMB 연결에 I/O 오류가 발생할 수 있으며 SMB 사용자에게 인증 오류가 발생할 수 있습니다. **GatewayClockOutOfSync 오류를 해결하려면** + 게이트웨이와 NTP 서버 간의 네트워크 구성을 확인합니다. 게이트웨이 VM 시간 동기화 및 NTP 서버 구성 업데이트에 대한 자세한 내용은 [게이트웨이의 NTP(Network Time Protocol) 서버 구성](https://docs.aws.amazon.com/filegateway/latest/files3/manage-on-premises-fgw.html#MaintenanceTimeSync-fgw)을 참조하세요. ## 오류: InaccessibleStorageClass 객체가 Amazon S3 Standard 스토리지 클래스에서 벗어나면 `InaccessibleStorageClass` 오류가 발생할 수 있습니다. 일반적으로 File Gateway는 지정된 객체를 Amazon S3 버킷에 업로드하거나 Amazon S3 버킷에서 객체를 읽으려고 할 때 오류가 발생합니다. 일반적으로 이 오류는 객체가 Amazon Glacier로 이동했으며 S3 Glacier Flexible Retrieval 또는 S3 Glacier Deep Archive 스토리지 클래스에 있음을 의미합니다. S3 File Gateway는 이 오류로 인해 현재 Amazon S3에 업로드하지 못한 게이트웨이 캐시의 모든 파일을 나열하는 캐시 보고서를 생성할 수 있습니다. 이 보고서의 정보는를 사용하여 게이트웨이, Amazon S3 또는 IAM 구성 문제를 해결하는 지원 데 도움이 될 수 있습니다. 자세한 내용은 [캐시 보고서 생성](https://docs.aws.amazon.com/filegateway/latest/files3/create-cache-report.html)을 참조하세요. **InaccessibleStorageClass 오류를 해결하려면** + S3 Glacier Flexible Retrieval 또는 S3 Glacier Deep Archive 스토리지 클래스에서 S3의 원래 스토리지 클래스로 객체를 복원합니다. 업로드 오류를 수정하기 위해 객체를 S3 버킷으로 복원하면 파일이 결국 업로드됩니다. 읽기 오류를 수정하기 위해 객체를 복원하면 File Gateway의 SMB 또는 NFS 클라이언트가 파일을 읽을 수 있습니다. ## 오류: InvalidObjectState 지정된 File Gateway 이외의 라이터가 지정된 Amazon S3 버킷에서 지정된 파일을 수정할 때 `InvalidObjectState` 오류가 발생할 수 있습니다. 따라서 File Gateway의 파일 상태가 Amazon S3에서의 해당 상태와 일치하지 않습니다. 이후에 Amazon S3으로 파일을 업로드하거나 Amazon S3에서 파일을 검색하지 못합니다. S3 File Gateway는 이 오류로 인해 현재 Amazon S3에 업로드하지 못한 게이트웨이 캐시의 모든 파일을 나열하는 캐시 보고서를 생성할 수 있습니다. 이 보고서의 정보는를 사용하여 게이트웨이, Amazon S3 또는 IAM 구성 문제를 해결하는 지원 데 도움이 될 수 있습니다. 자세한 내용은 [캐시 보고서 생성](https://docs.aws.amazon.com/filegateway/latest/files3/create-cache-report.html)을 참조하세요. **InvalidObjectState 오류를 해결하려면** 파일을 수정하는 작업이 `S3Upload` 또는 `S3GetObject`인 경우 다음을 수행합니다. 1. SMB 또는 NFS 클라이언트의 로컬 파일 시스템에 파일의 최신 복사본을 저장합니다(4단계에서 이 파일 복사본이 필요함). Amazon S3에 있는 파일 버전이 최신이면 그 버전을 다운로드합니다. AWS Management Console 또는를 사용하여이 작업을 수행할 수 있습니다 AWS CLI. 1. AWS Management Console 또는를 사용하여 Amazon S3에서 파일을 삭제합니다 AWS CLI. 1. SMB 또는 NFS 클라이언트를 사용하여 File Gateway에서 파일을 삭제합니다. 1. SMB 또는 NFS 클라이언트를 사용하여 1단계에서 저장한 파일의 최신 버전을 Amazon S3에 복사합니다. File Gateway를 통해 이 작업을 합니다. ## 오류: ObjectMissing 지정된 File Gateway 이외의 라이터가 S3 버킷에서 지정된 파일을 삭제할 때 `ObjectMissing` 오류가 발생할 수 있습니다. 이후에 Amazon S3에 업로드하거나 Amazon S3에서 객체를 가져오는 작업이 모두 실패합니다. S3 File Gateway는 이 오류로 인해 현재 Amazon S3에 업로드하지 못한 게이트웨이 캐시의 모든 파일을 나열하는 캐시 보고서를 생성할 수 있습니다. 이 보고서의 정보는를 사용하여 게이트웨이, Amazon S3 또는 IAM 구성 문제를 해결하는 지원 데 도움이 될 수 있습니다. 자세한 내용은 [캐시 보고서 생성](https://docs.aws.amazon.com/filegateway/latest/files3/create-cache-report.html)을 참조하세요. **ObjectMissing 오류를 해결하려면** 파일을 수정하는 작업이 `S3Upload` 또는 `S3GetObject`인 경우 다음을 수행합니다. 1. SMB 또는 NFS 클라이언트의 로컬 파일 시스템에 파일의 최신 복사본을 저장합니다(3단계에서 이 파일 복사본이 필요함). 1. SMB 또는 NFS 클라이언트를 사용하여 File Gateway에서 파일을 삭제합니다. 1. SMB 또는 NFS 클라이언트를 사용하여 1단계에서 저장한 파일의 최신 버전을 복사합니다. File Gateway를 통해 이 작업을 합니다. ## 오류: RoleTrustRelationshipInvalid 파일 공유에 대한 IAM 역할에 잘못 구성된 IAM 신뢰 관계가 있는 경우(즉, IAM 역할이 `storagegateway.amazonaws.com`이라는 Storage Gateway 보안 주체를 신뢰하지 않는 경우) 이 오류가 발생합니다. 따라서 File Gateway는 파일 공유를 지원하는 S3 버킷에서 작업을 실행하기 위한 자격 증명을 가져올 수 없습니다. **RoleTrustRelationshipInvalid 오류를 해결하려면** + `storagegateway.amazonaws.com`을 파일 공유의 IAM 역할에서 신뢰하는 있는 보안 주체로 포함하려면 IAM 콘솔 또는 IAM API를 사용합니다. IAM 역할에 대한 자세한 내용은 [자습서: IAM 역할을 사용하여 AWS 계정 간에 액세스 위임](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html)을 참조하세요. ## 오류: S3AccessDenied 파일 공유의 Amazon S3 버킷 액세스 AWS Identity and Access Management (IAM) 역할에 `S3AccessDenied` 오류가 발생할 수 있습니다. 이 경우 오류에서 `roleArn`에 의해 지정된 S3 버킷 액세스 IAM 역할은 관련 작업을 허용하지 않습니다. Amazon S3 접두사에 의해 지정된 디렉터리의 객체에 대한 권한 때문에 해당 작업이 허용되지 않습니다. S3 File Gateway는 이 오류로 인해 현재 Amazon S3에 업로드하지 못한 게이트웨이 캐시의 모든 파일을 나열하는 캐시 보고서를 생성할 수 있습니다. 이 보고서의 정보는를 사용하여 게이트웨이, Amazon S3 또는 IAM 구성 문제를 해결하는 지원 데 도움이 될 수 있습니다. 자세한 내용은 [캐시 보고서 생성](https://docs.aws.amazon.com/filegateway/latest/files3/create-cache-report.html)을 참조하세요. **S3AccessDenied 오류를 해결하려면** + File Gateway 상태 로그에서 `roleArn`에 연결된 Amazon S3 액세스 정책을 수정하여 Amazon S3 작업을 위한 권한을 허용합니다. 액세스 정책이 오류를 일으킨 작업에 대한 권한을 허용하는지 확인합니다. 또한 `prefix`에 대한 로그에 지정된 디렉터리에 대한 권한을 허용합니다. Amazon S3 권한에 대한 자세한 내용은 *Amazon Simple Storage Service 사용 설명서*의 [정책에서 권한 지정](https://docs.aws.amazon.com/AmazonS3/latest/dev/using-with-s3-actions.html)을 참조하세요. 다음 작업으로 인해 `S3AccessDenied` 오류가 발생할 수 있습니다. + `S3HeadObject` + `S3GetObject` + `S3ListObjects` + `S3DeleteObject` + `S3PutObject` ## 오류: DroppedNotifications 게이트웨이 루트 디스크의 여유 스토리지 공간이 1GB 미만이거나 1분 간격 내에 100개 이상의 상태 알림이 생성되는 경우 다른 예상 유형의 CloudWatch 로그 항목 대신 `DroppedNotifications` 오류가 발생할 수 있습니다. 이러한 상황에서 게이트웨이는 예방 조치로 자세한 CloudWatch 로그 알림 생성을 중지합니다. **DroppedNotifications 오류를 해결하려면** 1. Storage Gateway 콘솔의 게이트웨이 **모니터링** 탭에서 `Root Disk Usage` 지표를 확인하여 사용 가능한 루트 디스크 공간이 부족한지 확인합니다. 1. 사용 가능한 공간이 1GB 미만인 경우 게이트웨이의 루트 스토리지 디스크 크기를 늘립니다. 지침은 가상 머신 하이퍼바이저 설명서를 참조하세요. Amazon EC2 게이트웨이의 루트 디스크 크기를 늘리려면 *Amazon Elastic Compute Cloud 사용 설명서*의 [EBS 볼륨에 대한 수정 요청](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/requesting-ebs-volume-modifications.html)을 참조하세요. **참고** AWS Storage Gateway Hardware Appliance의 루트 디스크 크기를 늘릴 수 없습니다. 1. 게이트웨이 다시 시작합니다. ## 알림: HardReboot 게이트웨이 VM이 예기치 않게 다시 시작될 때 `HardReboot` 알림을 받을 수 있습니다. 이러한 다시 시작의 원인은 정전, 하드웨어 오류 또는 다른 이벤트일 수 있습니다. VMware 게이트웨이의 경우 vSphere 고가용성 애플리케이션 모니터링을 통해 재설정하면 이 이벤트가 시작될 수 있습니다. 게이트웨이가 이러한 환경에서 실행되는 경우 `HealthCheckFailure` 알림이 있는지 확인하고 VM에 대한 VMware 이벤트 로그를 참조하세요. ## 알림: 재부팅 게이트웨이 VM을 다시 시작할 때 재부팅 알림을 받을 수 있습니다. VM 하이퍼바이저 관리 콘솔 또는 Storage Gateway 콘솔을 사용하여 게이트웨이 VM을 다시 시작할 수 있습니다. 게이트웨이의 유지 관리 주기 동안 게이트웨이 소프트웨어를 사용하여 다시 시작할 수도 있습니다. 재부팅이 게이트웨이에서 구성된 [유지 관리 시작 시간](MaintenanceManagingUpdate-common.md) 10분 이내에 수행되는 경우 이 재부팅은 정상적인 현상일 수 있으며 문제의 징조가 아닙니다. 유지 관리 기간을 크게 벗어나 재부팅이 수행된 경우 게이트웨이가 수동으로 다시 시작되었는지 확인합니다. ## 문제 해결: 보안 스캔에서 열린 NFS 포트 표시 특정 NFS 포트는 SMB 파일 공유에만 사용하는 게이트웨이에서도 기본적으로 활성화됩니다. Qualys와 같은 타사 보안 소프트웨어를 사용하여 File Gateway가 배포된 네트워크를 스캔하는 경우 스캔 결과에서 이러한 열린 NFS 포트를 잠재적 보안 취약성으로 보고할 수 있습니다. 게이트웨이를 SMB 파일 공유에만 사용하고 보안상의 이유로 사용하지 않는 NFS 포트를 비활성화하려는 경우 다음 절차를 사용합니다. **File Gateway에서 NFS 포트를 비활성화하려면:** 1. [로컬 콘솔에서 Storage Gateway 명령 실행](MaintenanceGatewayConsole-fgw.md)에 설명된 절차를 사용하여 게이트웨이 로컬 콘솔 명령 프롬프트에 액세스합니다. 1. NFS 트래픽을 비활성화하려면 다음 명령을 입력하십시오. **IPv4** ``` iptables -I INPUT -p udp -m udp --dport 111 -j DROP iptables -I INPUT -p udp -m udp --dport 2049 -j DROP iptables -I INPUT -p udp -m udp --dport 20048 -j DROP iptables -I INPUT -p tcp -m tcp --dport 111 -j DROP iptables -I INPUT -p tcp -m tcp --dport 2049 -j DROP iptables -I INPUT -p tcp -m tcp --dport 20048 -j DROP ``` **IPv6** ``` ip6tables -I INPUT -p udp -m udp --dport 111 -j DROP ip6tables -I INPUT -p udp -m udp --dport 2049 -j DROP ip6tables -I INPUT -p udp -m udp --dport 20048 -j DROP ip6tables -I INPUT -p tcp -m tcp --dport 111 -j DROP ip6tables -I INPUT -p tcp -m tcp --dport 2049 -j DROP ip6tables -I INPUT -p tcp -m tcp --dport 20048 -j DROP ``` 1. 다음 명령을 입력하여 차단된 NFS 포트가 IP 테이블에 나타나는지 확인합니다. **IPv4** ``` iptables -n -L -v --line-numbers ``` **IPv6** ``` ip6tables -n -L -v --line-numbers ``` ## 문제 해결: CloudWatch 지표 사용 Storage Gateway에서 Amazon CloudWatch 지표를 사용하여 문제를 해결하는 작업에 대한 다음 정보를 찾을 수 있습니다. **Topics** + [디렉터리를 찾아볼 때 게이트웨이가 느리게 반응](#slow-gateway) + [게이트웨이가 응답하지 않음](#gateway-not-responding) + [게이트웨이에서 데이터를 Amazon S3로 전송하는 속도가 느림](#slow-data-transfer-to-S3) + [게이트웨이가 예상보다 많은 Amazon S3 작업을 수행하고 있습니다.](#gateway-performing-more-s3-operations) + [Amazon S3 버킷에 파일이 표시되지 않음](#files-missing-s3-bucket) + [게이트웨이 백업 작업이 실패하거나 게이트웨이에 쓸 때 오류가 발생함](#backup-job-fails) ### 디렉터리를 찾아볼 때 게이트웨이가 느리게 반응 **ls** 명령을 실행하거나 디렉터리를 찾아볼 때 File Gateway가 느리게 반응하는 경우 `IndexFetch` 및 `IndexEviction` CloudWatch 지표를 확인합니다. + `ls` 명령을 실행하거나 디렉터리를 찾아볼 때 `IndexFetch` 지표가 0보다 큰 경우 File Gateway가 영향을 받은 디렉터리 콘텐츠에 대한 정보 없이 시작했으며 Amazon S3에 액세스해야 했습니다. 해당 디렉터리의 콘텐츠를 나열하려는 후속 노력이 더 빨리 이루어져야 합니다. + `IndexEviction` 지표가 0보다 크면 File Gateway가 해당 시점에 캐시에서 관리할 수 있는 항목 한계에 도달했음을 의미합니다. 이 경우 File Gateway는 새 디렉터리를 나열하기 위해 가장 이전에 액세스한 디렉터리에서 일부 스토리지 스페이스를 비워야 합니다. 이 문제가 자주 발생하고 성능에 영향을 미치는 경우에 문의하세요 지원. 관련 S3 버킷의 지원 내용과 사용 사례에 따라 성능을 개선하기 위한 권장 사항을 논의합니다. ### 게이트웨이가 응답하지 않음 File Gateway가 응답하지 않는 경우 다음을 수행합니다. + 최근 재부팅 또는 소프트웨어 업데이트가 있었다면 `IOWaitPercent` 지표를 확인하십시오. 이 지표는 처리되지 않은 디스크 I/O 요청이 있을 때 CPU가 유휴 상태인 시간의 백분율을 보여줍니다. 경우에 따라 이 값이 높고(10 이상) 서버가 재부팅되거나 업데이트된 후에 증가했을 수 있습니다. 이러한 경우 인덱스 캐시를 RAM으로 재구성함에 따라 느린 루트 디스크로 인해 File Gateway에 병목 현상이 발생할 수 있습니다. 루트 디스크에 더 빠른 물리적 디스크를 사용하여 이 문제를 해결할 수 있습니다. + `MemUsedBytes` 지표가 `MemTotalBytes` 지표와 같거나 거의 같으면 File Gateway에 사용 가능한 RAM이 부족해집니다. File Gateway에 필요한 최소 RAM이 있는지 확인합니다. 이미 이를 확인했다면 워크로드 및 사용 사례에 따라 File Gateway에 RAM을 추가해 보십시오. 파일 공유가 SMB인 경우 파일 공유에 연결된 SMB 클라이언트 수 때문일 수도 있습니다. 지정된 시간에 연결된 클라이언트 수를 확인하려면 `SMBV(1/2/3)Sessions` 지표를 확인합니다. 연결된 클라이언트가 많은 경우 File Gateway에 RAM을 더 추가해야 할 수 있습니다. ### 게이트웨이에서 데이터를 Amazon S3로 전송하는 속도가 느림 File Gateway에서 Amazon S3로의 데이터 전송 속도가 느리면 다음을 수행합니다. + `CachePercentDirty` 지표가 80 이상인 경우 File Gateway는 데이터를 Amazon S3에 업로드할 수 있는 것보다 더 빨리 디스크에 데이터를 쓰고 있습니다. File Gateway에서 업로드를 위한 대역폭을 늘리거나, 캐시 디스크를 하나 이상 추가하거나, 클라이언트 쓰기 속도를 늦추는 것이 좋습니다. + `CachePercentDirty` 지표가 낮은 경우 `IoWaitPercent` 지표를 확인합니다. `IoWaitPercent`가 10보다 큰 경우 로컬 캐시 디스크의 속도로 인해 File Gateway에 병목 현상이 발생할 수 있습니다. 캐시에 로컬 SSD(Solid State Drive) 디스크를 사용하는 것이 좋습니다. 추천 제품은 NVMe(NVM Express)입니다. 이러한 디스크를 사용할 수 없는 경우 성능 향상을 위해 별도의 물리적 디스크에서 여러 캐시 디스크를 사용해 보십시오. + `S3PutObjectRequestTime`, `S3UploadPartRequestTime` 또는 `S3GetObjectRequestTime`이 높으면 네트워크 병목 현상이 발생할 수 있습니다. 네트워크를 분석하여 게이트웨이에 예상 대역폭이 있는지 확인합니다. ### 게이트웨이가 예상보다 많은 Amazon S3 작업을 수행하고 있습니다. File Gateway가 예상보다 많은 Amazon S3 작업을 수행하는 경우 `FilesRenamed` 지표를 확인합니다. 이름 바꾸기 작업은 Amazon S3에서 실행하는 데 비용이 많이 듭니다. 워크플로를 최적화하여 이름 바꾸기 작업 수를 최소화합니다. ### Amazon S3 버킷에 파일이 표시되지 않음 게이트웨이의 파일이 Amazon S3 버킷에 반영되지 않는 경우 `FilesFailingUpload` 지표를 확인합니다. 지표에서 일부 파일이 업로드에 실패한다고 보고하는 경우 상태 알림을 확인합니다. 파일을 업로드하지 못하면 게이트웨이는 문제에 대한 세부 정보가 포함된 상태 알림을 생성합니다. ### 게이트웨이 백업 작업이 실패하거나 게이트웨이에 쓸 때 오류가 발생함 File Gateway 백업 작업이 실패하거나 File Gateway에 쓸 때 오류가 발생하는 경우 다음을 수행합니다. + `CachePercentDirty` 지표가 90% 이상이면 캐시 디스크에 사용 가능한 공간이 부족하기 때문에 File Gateway가 디스크에 대한 새 쓰기를 허용할 수 없습니다. File Gateway가 Amazon S3에 업로드되는 속도를 확인하려면 `CloudBytesUploaded` 지표를 확인합니다. 클라이언트가 File Gateway에 파일을 쓰는 속도를 보여 주는 `WriteBytes` 지표를 이 지표와 비교합니다. SMB 클라이언트가 Amazon S3로 업로드할 수 있는 것보다 더 빨리 File Gateway에 쓰는 경우 최소한 백업 작업의 크기를 처리할 수 있도록 캐시 디스크를 더 추가합니다. 또는 업로드 대역폭을 늘립니다. + 백업 작업과 같은 대용량 파일 복사가 실패했지만 `CachePercentDirty` 지표가 80% 미만인 경우 File Gateway가 클라이언트 측 세션 제한 시간에 도달할 수 있습니다. SMB의 경우 PowerShell 명령 `Set-SmbClientConfiguration -SessionTimeout 300`을 사용하여 이 제한 시간을 늘릴 수 있습니다. 이 명령을 실행하면 이 제한 시간이 300초로 설정됩니다. NFS의 경우 소프트 마운트 대신 하드 마운트를 사용하여 클라이언트를 마운트해야 합니다. # 문제 해결: 파일 공유 문제 아래와 같이 파일 공유와 관련해 예기치 않은 문제를 겪는 경우 취해야 할 조치에 대한 정보를 얻을 수 있습니다. **Topics** + [파일 공유가 CREATING, UPDATING 또는 DELETING 상태에서 멈춤](#troubleshooting-file-share-stuck-states) + [파일 공유를 생성할 수 없음](#create-file-troubleshoot) + [SMB 파일 공유가 여러 다른 액세스 방법을 허용하지 않음](#smb-fileshare-troubleshoot) + [여러 파일 공유가 매핑된 S3 버킷에 쓸 수 없음](#multiwrite) + [감사 로그 사용 시 삭제된 로그 그룹에 대한 알림](#multiwrite) + [S3 버킷에 파일을 업로드할 수 없음](#access-s3bucket) + [SSE-KMS를 사용하여 내 S3 버킷에 저장된 개체를 암호화하도록 기본 암호화를 변경할 수 없음](#encryption-issues) + [객체 버전 관리가 켜져 있는 S3 버킷에서 직접 변경하면 파일 공유에 표시되는 내용에 영향을 미칠 수 있습니다.](#s3-object-versioning-file-share-issue) + [버전 관리가 켜져 있는 S3 버킷에 쓸 때 Amazon S3 File Gateway는 여러 버전의 Amazon S3 객체를 생성할 수 있습니다.](#s3-object-versioning-file-gateway-issue) + [S3 버킷에 대한 변경 사항은 Storage Gateway에 반영되지 않습니다.](#s3-changes-issue) + [ACL 권한이 예상대로 작동하지 않음](#smb-acl-issues) + [재귀 작업을 수행한 후 게이트웨이 성능 저하됨](#recursive-operation-issues) ## 파일 공유가 CREATING, UPDATING 또는 DELETING 상태에서 멈춤 파일 공유 상태는 파일 공유의 상태를 요약합니다. S3 File Gateway 파일 공유가 `CREATING`, `UPDATING`또는 `DELETING` 상태에서 멈춘 경우 다음 문제 해결 단계를 사용하여 문제를 식별하고 해결합니다. ### IAM 역할 권한 및 신뢰 관계 확인 파일 공유와 연결된 AWS Identity and Access Management (IAM) 역할에는 Amazon S3 버킷에 액세스할 수 있는 충분한 권한이 있어야 합니다. 또한 역할의 신뢰 정책은 역할을 수임할 수 있는 권한을 Storage Gateway 서비스에 부여해야 합니다. **IAM 역할 권한을 확인하려면:** 1. IAM 콘솔([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/))을 엽니다. 1. 탐색 창에서 **역할**을 선택합니다. 1. 파일 공유와 연결된 IAM 역할을 선택합니다. 1. **신뢰 관계** 탭을 선택합니다. 1. Storage Gateway가 신뢰할 수 있는 엔터티로 나열되어 있는지 확인합니다. Storage Gateway가 신뢰할 수 있는 엔터티가 아닌 경우 **신뢰 관계 편집**을 선택한 후 다음 정책을 추가합니다. ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "", "Effect": "Allow", "Principal": { "Service": "storagegateway.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` 1. IAM 역할에 올바른 권한이 있고 Amazon S3 버킷이 IAM 정책에 리소스로 나열되어 있는지 확인합니다. 자세한 내용은 [Amazon S3 버킷에 액세스할 수 있는 권한 부여](grant-access-s3.md) 단원을 참조하십시오. **참고** 교차 서비스 혼동된 대리자 방지 문제를 방지하려면 조건 컨텍스트 키가 포함된 신뢰 관계 정책을 사용합니다. 자세한 내용은 [교차 서비스 혼동된 대리인 방지](cross-service-confused-deputy-prevention.md) 단원을 참조하십시오. ### 해당 리전에서 AWS STS가 활성화되었는지 확인 AWS 리전에서 AWS Security Token Service (AWS STS)가 비활성화된 경우 파일 공유가 `CREATING` 또는 `UPDATING` 상태에서 멈출 수 있습니다. **AWS STS 상태를 확인하려면:** 1. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) AWS Identity and Access Management 콘솔을 엽니다. 1. 탐색 창에서 **계정 설정(Account settings)**를 선택합니다. 1. **보안 토큰 서비스(STS)** 섹션에서 파일 공유를 생성하려는 AWS 리전의 **상태가** **활성**인지 확인합니다. 1. 상태가 **비활성**인 경우 **활성화**를 선택하여 해당 리전 AWS STS 에서를 활성화합니다. ### S3 버킷이 존재하고 이름 지정 규칙을 따르는지 확인 파일 공유에는 Amazon S3 명명 규칙을 따르는 유효한 Amazon S3 버킷이 필요합니다. **S3 버킷을 확인하려면:** 1. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 S3 콘솔을 엽니다. 1. 파일 공유에 매핑된 Amazon S3 버킷이 있는지 확인합니다. 버킷이 없는 경우 버킷을 생성합니다. 버킷을 생성한 후 파일 공유 상태가 로 변경됩니다`AVAILABLE`. 자세한 내용은 *Amazon Simple Storage Service 사용 설명서*에서 [버킷 생성](https://docs.aws.amazon.com/AmazonS3/latest/gsg/CreatingABucket.html)을 참조하세요. 1. Amazon *Simple Storage Service 사용 설명서*의 버킷 이름이 [버킷 이름 지정 규칙을](https://docs.aws.amazon.com/AmazonS3/latest/dev/BucketRestrictions.html#bucketnamingrules) 준수하는지 확인합니다. **참고** S3 File Gateway는 버킷 이름에 마침표(`.`)가 있는 Amazon S3 버킷을 지원하지 않습니다. ### 삭제 중 상태에서 멈춘 파일 공유 강제 삭제 파일 공유를 삭제하면 게이트웨이는 연결된 Amazon S3 버킷에서 공유를 제거합니다. 그러나 현재 업로드 중인 데이터는 삭제가 완료되기 전에 계속 업로드됩니다. 이 프로세스 중에 파일 공유에 `DELETING` 상태가 표시됩니다. **중요** `CachePercentDirty` 게이트웨이의 Amazon CloudWatch 지표를 확인하여 업로드 보류 중인 데이터의 양을 확인합니다. Storage Gateway 지표에 대한 자세한 내용은 섹션을 참조하세요[S3 File Gateway 모니터링](monitoring-file-gateway.md). 진행 중인 모든 업로드가 완료될 때까지 기다리지 않으려면 파일 공유를 강제로 삭제할 수 있습니다. **파일 공유를 강제로 삭제하려면:** 1. [https://console.aws.amazon.com/storagegateway/](https://console.aws.amazon.com/storagegateway/) Storage Gateway 콘솔을 엽니다. 1. 탐색 창에서 **파일 공유**를 선택합니다. 1. 삭제할 파일 공유를 선택합니다. 1. **세부 정보** 탭을 선택하고 **이 파일 공유가 삭제 중입니다** 메시지를 검토합니다. 1. 메시지에서 파일 공유의 ID를 확인한 다음 확인 상자를 선택합니다. **참고** 강제 삭제 작업은 취소할 수 없습니다. 1. **지금 강제 삭제**를 선택합니다. 또는 `--force-delete` 파라미터가 로 설정된 상태에서 AWS CLI [delete-file-share](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/storagegateway/delete-file-share.html) 명령을 사용할 수 있습니다`true`. **중요** 파일 공유를 강제로 삭제하기 전에 게이트웨이가 `OFFLINE` 상태가 아닌지 확인합니다. 게이트웨이가 오프라인 상태인 경우 먼저 오프라인 문제를 해결합니다. 자세한 내용은 [문제 해결: Storage Gateway 콘솔에서 게이트웨이 오프라인](troubleshooting-gateway-offline.md) 단원을 참조하십시오. 게이트웨이 가상 머신(VM)이 이미 삭제된 경우 Storage Gateway 콘솔에서 게이트웨이를 삭제하여 `DELETING` 상태에서 멈춘 파일 공유를 포함하여 연결된 모든 파일 공유를 제거해야 합니다. 자세한 내용은 [게이트웨이 삭제 및 연결된 리소스 제거](deleting-gateway-common.md) 단원을 참조하십시오. ### 네트워크 연결 문제 해결 네트워크 문제로 인해 파일 공유가 `CREATING`, `UPDATING`또는 `DELETING` 상태에서 전환되지 않을 수 있습니다. 일반적인 네트워크 문제는 다음과 같습니다. + 게이트웨이가 오프라인 상태이거나 게이트웨이 VM이 삭제됩니다. + Storage Gateway와 Amazon S3 서비스 엔드포인트 간의 네트워크 액세스가 차단됩니다. + 게이트웨이가 Amazon S3와 통신하는 데 사용하는 Amazon S3 Amazon VPC 엔드포인트가 삭제되었습니다. + 필요한 네트워크 포트가 열려 있지 않거나 네트워크 라우팅이 잘못 구성되었습니다. #### 게이트웨이 로컬 콘솔에서 S3 연결 테스트 **S3 연결을 테스트하려면:** 1. 게이트웨이의 로컬 콘솔에 로그인합니다. 자세한 내용은 [File Gateway 로컬 콘솔에 로그인](LocalConsole-login-fgw.md) 단원을 참조하십시오. 1. **Storage Gateway - 구성** 기본 메뉴에서 ** S3 연결 테스트**에 해당하는 번호를 입력합니다. 1. Amazon S3 엔드포인트 유형을 선택합니다. + 인터넷 게이트웨이, NAT 게이트웨이, 전송 게이트웨이 또는 Amazon S3 게이트웨이 Amazon VPC 엔드포인트를 통해 흐르는 Amazon S3 트래픽의 경우 **퍼블릭**을 선택합니다. + Amazon S3 인터페이스 Amazon VPC 엔드포인트를 통해 흐르는 Amazon S3 트래픽의 경우 **VPC(PrivateLink)**를 선택합니다. + FIPS 엔드포인트의 경우 FIPS 옵션을 선택합니다. 1. Amazon S3 버킷 리전을 입력합니다. 1. Amazon VPC 엔드포인트를 사용하는 경우 Amazon S3 Amazon VPC 엔드포인트 DNS 이름(예: `vpce-0329c2790456f2d01-0at85l34`)을 입력합니다. 게이트웨이는 네트워크 연결과 SSL 연결을 모두 검증하는 연결 테스트를 자동으로 수행합니다. 테스트가 실패하는 경우: + **네트워크 테스트 실패** - 일반적으로 방화벽 규칙, 보안 그룹 구성 또는 부적절한 네트워크 라우팅으로 인해 발생합니다. 필요한 포트가 열려 있고 네트워크 라우팅이 올바르게 구성되어 있는지 확인합니다. + **SSL 테스트 실패** - 게이트웨이 VM과 Amazon S3 서비스 엔드포인트 간에 SSL 검사 또는 심층 패킷 검사가 발생하고 있음을 나타냅니다. Storage Gateway 트래픽에 대한 SSL 및 심층 패킷 검사를 비활성화합니다. #### 프록시 구성 확인 게이트웨이가 프록시 서버를 사용하는 경우 프록시가 네트워크 통신을 차단하지 않는지 확인합니다. **프록시 구성을 확인하려면:** 1. **Storage Gateway - 구성** 기본 메뉴에서 **HTTP/SOCKS 프록시 구성**에 해당하는 번호를 입력합니다. 1. 현재 네트워크 프록시 구성을 보려면 옵션을 선택합니다. 1. 프록시가 구성된 경우 Amazon S3 트래픽이 포트 3128(또는 구성된 리스너 포트)을 통해 Storage Gateway에서 프록시 서버로 흐른 다음 포트 443을 통해 Amazon S3 엔드포인트로 흐를 수 있는지 확인합니다. 1. 프록시 또는 방화벽이 Storage Gateway에 필요한 네트워크 포트 및 서비스 엔드포인트와의 트래픽을 허용하는지 확인합니다. 자세한 내용은 필요한 네트워크 포트를 참조하세요. 문제가 지속되면 프록시 구성을 일시적으로 제거하여 프록시가 문제를 일으키는지 확인할 수 있습니다. #### 보안 그룹 및 네트워크 라우팅 확인 + **Amazon EC2의 게이트웨이의 경우** - 보안 그룹에 Amazon S3 엔드포인트에 개방된 포트 443이 있는지 확인합니다. Amazon EC2 서브넷의 라우팅 테이블이 Amazon S3 트래픽을 Amazon S3 엔드포인트로 올바르게 라우팅하는지 확인합니다. 자세한 내용은 필요한 네트워크 포트를 참조하세요. + **온프레미스 게이트웨이의 경우** - 방화벽 규칙이 필요한 포트를 허용하고 로컬 라우팅 테이블이 Amazon S3 트래픽을 Amazon S3 엔드포인트로 올바르게 라우팅하는지 확인합니다. 자세한 내용은 필요한 네트워크 포트를 참조하세요. + **VPC 엔드포인트** - 게이트웨이에서 사용하는 Amazon S3 Amazon VPC 엔드포인트가 삭제되지 않았는지 확인합니다. Amazon VPC 엔드포인트가 삭제되고 게이트웨이에 퍼블릭 IP 주소가 없는 경우 게이트웨이가 Amazon S3와 통신할 수 없습니다. ## 파일 공유를 생성할 수 없음 1. 파일 공유가 CREATING 상태로 고착되어 파일 공유를 생성할 수 없는 경우 파일 공유를 매핑한 S3 버킷이 존재하는지 확인합니다. 이에 관한 자세한 내용은 위 [파일 공유가 CREATING, UPDATING 또는 DELETING 상태에서 멈춤](#troubleshooting-file-share-stuck-states) 섹션을 참조하세요. 1. S3 버킷이 있는 경우 파일 공유를 생성하는 리전에서 AWS Security Token Service 가 활성화되어 있는지 확인합니다. 보안 토큰이 활성화되지 않은 경우 활성화해야 합니다. 를 사용하여 토큰을 활성화하는 방법에 대한 자세한 내용은 *IAM 사용 설명서*의 [AWS 리전에서 AWS STS 활성화 및 비활성화](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html)를 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.` 1. Windows 사용자는 두 개의 게스트 액세스 SMB 파일 공유에 연결된 상태를 유지할 수 없으며 새 게스트 액세스 연결이 설정되면 연결이 끊어질 수 있습니다. 1. Windows 클라이언트는 게스트 액세스와 동일한 게이트웨이에서 내보낸 Active Directory SMB 파일 공유를 모두 탑재할 수 없습니다. ## 여러 파일 공유가 매핑된 S3 버킷에 쓸 수 없음 여러 파일 공유가 하나의 S3 버킷에 쓸 수 있도록 S3 버킷을 구성하는 것은 권장하지 않습니다. 이 접근 방법은 예기치 않은 결과를 유발할 수 있습니다. 각 S3 버킷에 하나의 파일 공유만 쓸 수 있도록 허용하는 것이 좋습니다. 파일 공유와 연결된 역할만 버킷에 쓸 수 있도록 허용하는 버킷 정책을 생성합니다. 자세한 내용은 [File Gateway의 모범 사례](https://docs.aws.amazon.com/filegateway/latest/files3/best-practices.html) 섹션을 참조하세요. ## 감사 로그 사용 시 삭제된 로그 그룹에 대한 알림 로그 그룹이 없는 경우 사용자는 해당 메시지 아래의 로그 그룹 링크를 선택하여 새 로그 그룹을 생성하거나 기존 로그 그룹을 사용하여 감사 로그의 대상으로 사용할 수 있습니다. ## S3 버킷에 파일을 업로드할 수 없음 S3 버킷에 파일을 업로드할 수 없는 경우 다음을 수행합니다. 1. Amazon S3 File Gateway가 파일을 S3 버킷으로 업로드하는 데 필요한 액세스 권한을 부여했는지 확인합니다. 자세한 내용은 [Amazon S3 버킷에 액세스할 수 있는 권한 부여](grant-access-s3.md) 단원을 참조하십시오. 1. 버킷을 생성한 역할이 S3 버킷에 쓸 수 있는 권한이 있는지 확인합니다. 자세한 내용은 [File Gateway의 모범 사례](https://docs.aws.amazon.com/filegateway/latest/files3/best-practices.html) 섹션을 참조하세요. 1. File Gateway가 암호화에 SSE-KMS 또는 DSSE-KMS를 사용하는 경우 파일 공유와 연결된 IAM 역할에 *kms:Encrypt*, *kms:Decrypt*, *kms:ReEncrypt\$1*, *kms:GenerateDataKey* 및 *kms:DescribeKey* 권한이 포함되어 있는지 확인합니다. 자세한 내용은 [Storage Gateway에 대한 자격 증명 기반 정책(IAM 정책) 사용](https://docs.aws.amazon.com/filegateway/latest/files3/using-identity-based-policies.html)을 참조하세요. ## 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](encryption.md) 단원을 참조하십시오. ## 객체 버전 관리가 켜져 있는 S3 버킷에서 직접 변경하면 파일 공유에 표시되는 내용에 영향을 미칠 수 있습니다. S3 버킷에 다른 클라이언트가 기록한 객체가 있는 경우, S3 버킷 객체 버전 관리의 결과로 S3 버킷 보기가 최신이 아닐 수 있습니다. 관심 있는 파일을 검사하기 전에 항상 캐시를 새로 고쳐야 합니다. *객체 버전 관리*는 동일한 이름의 객체 사본을 여러 개 저장하여 데이터를 보호해 주는 S3 버킷의 옵션 기능입니다. 각 사본에는 서로 다른 ID 값이 있습니다(예: `file1.jpg`: `ID="xxx"` 및 `file1.jpg`: `ID="yyy"`). 동일한 이름의 객체 수와 수명은 Amazon S3 수명 주기 정책으로 제어됩니다. 이러한 Amazon S3 개념에 대한 자세한 내용은 *Amazon S3 개발자 안내서*의 [버전 관리 사용](https://docs.aws.amazon.com/AmazonS3/latest/dev/Versioning.html) 및 [객체 수명 주기 관리](https://docs.aws.amazon.com/AmazonS3/latest/dev/object-lifecycle-mgmt.html)를 참조하세요. 버전이 지정된 객체를 삭제할 경우 해당 객체에 삭제 마커가 표시되지만 보존됩니다. S3 버킷 소유자만 버전 관리가 켜져 있는 객체를 영구적으로 삭제할 수 있습니다. S3 File Gateway에서 표시되는 파일은 객체를 가져왔거나 캐시를 새로 고쳤을 당시에 S3 버킷의 최신 객체 버전입니다. S3 File Gateway는 삭제 표시된 모든 객체 또는 이전 버전을 무시합니다. 파일을 읽을 때 최신 버전에서 데이터를 읽습니다. 파일 공유에 파일을 쓰면 S3 File Gateway는 변경 사항이 있는 새 버전의 명명된 객체를 만들며, 이 버전이 최신 버전이 됩니다. S3 File Gateway는 이전 버전에서 계속 읽으며, 애플리케이션 외부의 S3 버킷에 새 버전이 추가되면 이전 버전을 기반으로 업데이트를 수행합니다. 최신 버전의 객체를 읽으려면 [RefreshCache](https://docs.aws.amazon.com/storagegateway/latest/APIReference/API_RefreshCache.html) API 작업을 사용하거나 [Amazon S3 버킷 객체 새로 고침](refresh-cache.md)에 설명된 대로 콘솔에서 새로 고칩니다. **중요** 파일 공유 외부에서 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)를 사용하면 사용되는 스토리지가 증가합니다. 복제에 대한 자세한 내용은 [복제](https://docs.aws.amazon.com/AmazonS3/latest/dev/replication.html) 섹션을 참조하세요. **중요** 객체 버전 관리가 켜져 있을 때 사용되는 스토리지의 양을 이해할 때까지 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 Command Line Interface (AWS CLI)를 사용하여 캐시를 새로 고칠 수 있습니다. + Storage Gateway 콘솔을 사용하여 캐시를 새로 고치려면 Amazon S3 버킷의 객체 새로 고침을 참조하세요. + AWS CLI를 사용하여 캐시를 새로 고치려면: 1. `aws storagegateway list-file-shares` 명령 실행 1. 파일 공유의 Amazon 리소스 번호(ARN)를 새로 고치려는 캐시로 복사합니다. 1. ARN을 `--file-share-arn`의 값으로 사용하여 `refresh-cache` 명령을 실행합니다. `aws storagegateway refresh-cache --file-share-arn arn:aws:storagegateway:eu-west-1:12345678910:share/share-FFDEE12` `RefreshCache` 작업을 자동화하려면 [ Storage Gateway에서 RefreshCache 작업을 자동화하려면 어떻게 해야 합니까?](https://aws.amazon.com/premiumsupport/knowledge-center/storage-gateway-automate-refreshcache/)를 참조하세요. ## ACL 권한이 예상대로 작동하지 않음 ACL(액세스 제어 목록) 권한이 SMB 파일 공유에서 예상대로 작동하지 않을 경우에는 테스트를 실시하십시오. 먼저 Microsoft Windows 파일 서버 또는 로컬 Windows 파일 공유에서 권한을 테스트해봅니다. 그런 다음 그 동작을 게이트웨이의 파일 공유와 비교합니다. ## 재귀 작업을 수행한 후 게이트웨이 성능 저하됨 일부 경우에서는 재귀 작업을 수행하고(예: 디렉터리 이름 바꾸기 또는 ACL 상속 활성화) 트리에 적용할 수 있습니다. 이 경우 S3 File Gateway가 파일 공유의 모든 객체에 이 작업을 재귀적으로 적용합니다. 예를 들어, S3 버킷의 기존 객체에 상속을 적용하는 경우, S3 File Gateway는 버킷의 모든 객체에 상속을 재귀적으로 적용합니다. 이러한 작업 때문에 게이트웨이 성능이 거부될 수 있습니다. ## 고가용성 상태 알림 VMware vSphere HA(고가용성) 플랫폼에서 게이트웨이를 실행할 때 상태 알림을 받을 수 있습니다. 상태 알림에 대한 자세한 내용은 [문제 해결: 고가용성 문제](troubleshooting-ha-issues.md) 섹션을 참조하세요. # 문제 해결: 고가용성 문제 가용성 문제가 발생할 경우 수행할 작업에 대한 다음 정보를 찾을 수 있습니다. **Topics** + [상태 알림](#ha-health-notifications) + [Metrics](#ha-health-notification-metrics) ## 상태 알림 VMware vSphere HA에서 게이트웨이를 실행하면 모든 게이트웨이에서는 구성된 Amazon CloudWatch 로그 그룹에 다음과 같은 상태 알림을 생성합니다. 이러한 알림은 `AvailabilityMonitor`라는 로그 스트림으로 이동합니다. **Topics** + [알림: 재부팅](#troubleshoot-reboot-notification) + [알림: HardReboot](#troubleshoot-hardreboot-notification) + [알림: HealthCheckFailure](#troubleshoot-healthcheckfailure-notification) + [알림: AvailabilityMonitorTest](#troubleshoot-availabilitymonitortest-notification) ### 알림: 재부팅 게이트웨이 VM을 다시 시작할 때 재부팅 알림을 받을 수 있습니다. VM 하이퍼바이저 관리 콘솔 또는 Storage Gateway 콘솔을 사용하여 게이트웨이 VM을 다시 시작할 수 있습니다. 게이트웨이의 유지 관리 주기 동안 게이트웨이 소프트웨어를 사용하여 다시 시작할 수도 있습니다. **취할 조치** 재부팅이 게이트웨이에서 구성된 [유지 관리 시작 시간](MaintenanceManagingUpdate-common.md) 10분 이내에 수행되는 경우 이는 정상적인 현상일 수 있으며 문제의 징조가 아닙니다. 유지 관리 기간을 크게 벗어나 재부팅이 수행된 경우 게이트웨이가 수동으로 다시 시작되었는지 확인합니다. ### 알림: HardReboot 게이트웨이 VM이 예기치 않게 다시 시작될 때 `HardReboot` 알림을 받을 수 있습니다. 이러한 다시 시작의 원인은 정전, 하드웨어 오류 또는 다른 이벤트일 수 있습니다. VMware 게이트웨이의 경우 vSphere 고가용성 애플리케이션 모니터링을 통해 재설정하면 이 이벤트가 시작될 수 있습니다. **취할 조치** 게이트웨이가 이러한 환경에서 실행되는 경우 `HealthCheckFailure` 알림이 있는지 확인하고 VM에 대한 VMware 이벤트 로그를 참조하세요. ### 알림: HealthCheckFailure VMware vSphere HA에 대한 게이트웨이의 경우 상태 확인에 실패하고 VM 다시 시작을 요청하면 `HealthCheckFailure` 알림을 받을 수 있습니다. 이 이벤트는 `AvailabilityMonitorTest` 알림으로 표시된 가용성을 모니터하기 위한 테스트 도중에도 발생합니다. 이 경우 `HealthCheckFailure` 알림이 예상됩니다. **참고** 이 알림은 VMware 게이트웨이에만 적용됩니다. **취할 조치** `AvailabilityMonitorTest` 알림 없이 이 이벤트가 반복적으로 발생하면 VM 인프라(스토리지, 메모리 등)에 문제가 있는지 확인하십시오. 추가 지원이 필요한 경우에 문의하십시오 지원. ### 알림: AvailabilityMonitorTest VMware vSphere HA의 게이트웨이의 경우 VMware에서 [가용성 및 애플리케이션 모니터링](https://docs.aws.amazon.com/storagegateway/latest/APIReference/API_StartAvailabilityMonitorTest.html) 시스템 [테스트를 실행](vmware-ha.md#vmware-ha-test-failover)할 때 `AvailabilityMonitorTest` 알림을 받을 수 있습니다. ## Metrics `AvailabilityNotifications` 지표는 모든 게이트웨이에서 사용할 수 있습니다. 이 지표는 게이트웨이에 의해 생성된 가용성 관련 상태 알림의 개수입니다. `Sum` 통계를 사용하여 게이트웨이에 가용성 관련 이벤트가 발생하는지 여부를 확인할 수 있습니다. 이벤트에 대한 자세한 내용은 구성된 CloudWatch 로그 그룹에 문의하십시오.