신규 고객은 더 이상 Amazon FSx File Gateway를 사용할 수 없습니다. 기존 FSx File Gateway 고객은 정상적으로 서비스를 계속 이용할 수 있습니다. FSx File Gateway와 유사한 기능에 대해서는 [이 블로그 게시물](https://aws.amazon.com/blogs/storage/switch-your-file-share-access-from-amazon-fsx-file-gateway-to-amazon-fsx-for-windows-file-server/)을 참조하세요.
기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 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-ha-issues.md) - VMware HA 환경에 배포된 게이트웨이에 문제가 발생하는 경우 취해야 할 조치에 대해 알아봅니다.
# 문제 해결: Storage Gateway 콘솔에서 게이트웨이 오프라인
다음 문제 해결 정보를 참조하여 AWS Storage Gateway 콘솔에서 게이트웨이가 오프라인 상태인 것으로 표시되는 경우에 취해야 할 조치를 결정하세요.
다음 중 하나 이상의 이유로 게이트웨이가 오프라인으로 표시될 수 있습니다.
+ 게이트웨이가 Storage Gateway 서비스 엔드포인트에 연결할 수 없습니다.
+ 게이트웨이가 예기치 않게 종료되었습니다.
+ 게이트웨이와 연결된 캐시 디스크가 연결 해제 또는 수정되었거나 실패했습니다.
게이트웨이를 다시 온라인 상태로 되돌리려면 게이트웨이를 오프라인 상태로 만든 문제를 파악하여 해결합니다.
## 연결된 방화벽 또는 프록시 확인
프록시를 사용하도록 게이트웨이를 구성했거나 게이트웨이를 방화벽 뒤에 배치한 경우 프록시 또는 방화벽의 액세스 규칙을 검토합니다. 프록시 또는 방화벽은 Storage Gateway에 필요한 네트워크 포트 및 서비스 엔드포인트와의 트래픽을 허용해야 합니다. 자세한 내용은 [네트워크 및 방화벽 요구 사항](https://docs.aws.amazon.com/filegateway/latest/filefsxw/Requirements.html#networks)을 참조하세요.
## 게이트웨이 트래픽에 대해 SSL 또는 딥패킷 검사가 진행 중인지 확인
게이트웨이와 간의 네트워크 트래픽에 대해 SSL 또는 딥 패킷 검사가 현재 수행 중인 AWS경우 게이트웨이가 필요한 서비스 엔드포인트와 통신하지 못할 수 있습니다. 게이트웨이를 다시 온라인 상태로 되돌리려면 검사를 비활성화해야 합니다.
## 재부팅 또는 소프트웨어 업데이트 후 IOWaitPercent 지표 확인
재부팅 또는 소프트웨어 업데이트 후 File Gateway의 `IOWaitPercent` 지표가 10 이상인지 확인합니다. 이 경우 인덱스 캐시를 RAM에 다시 빌드하는 동안 게이트웨이의 응답 속도가 느려질 수 있습니다. 자세한 내용은 [문제 해결: CloudWatch 지표 사용](https://docs.aws.amazon.com/filegateway/latest/filefsxw/troubleshooting-file-gateway-issues.html#gateway-not-responding)을 참조하세요.
## 하이퍼바이저 호스트의 정전 또는 하드웨어 장애 확인
게이트웨이의 하이퍼바이저 호스트에서 정전 또는 하드웨어 장애가 발생하면 게이트웨이가 예기치 않게 종료되어 연결이 불가능해질 수 있습니다. 전원 및 네트워크 연결을 복원하면 게이트웨이에 다시 연결할 수 있게 됩니다.
게이트웨이가 다시 온라인 상태가 되면 데이터 복구 조치를 취해야 합니다. 자세한 내용은 [모범 사례: 데이터 복구](https://docs.aws.amazon.com/filegateway/latest/filefsxw/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/filefsxw/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/filefsxw/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/filefsxw/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/filefsxw/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/filefsxw/troubleshooting-on-premises-gateway-issues.html) 그래도 게이트웨이 IP 주소를 찾기 어려운 경우: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/filegateway/latest/filefsxw/troubleshooting-on-premises-gateway-issues.html) |
| 네트워크 또는 방화벽에 문제가 있습니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/filegateway/latest/filefsxw/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/filefsxw/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/filefsxw/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의 복제 또는 스냅샷으로부터 생성된 경우 이 메시지를 수신하게 됩니다. 그렇지 않은 경우 지원에 문의하세요. |
## 온프레미스에서 호스팅되는 게이트웨이 문제를 해결하는 데 도움이 되는 지원 액세스 활성화
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/filefsxw/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에 배포한 게이트웨이 간의 차이점에 대한 자세한 내용은 [FSx File Gateway용 기본 Amazon EC2 호스트 배포FSx File Gateway용 사용자 지정 Amazon EC2 호스트 배포](ec2-gateway-file.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**
+ [오류: FileMissing](#troubleshoot-logging-errors-filemissing)
+ [오류: FsxFileSystemAuthenticationFailure](#troubleshoot-logging-errors-fsxfilesystemauthenticationfailure)
+ [오류: FsxFileSystemConnectionFailure](#troubleshoot-logging-errors-fsxfilesystemconnectionfailure)
+ [오류: FsxFileSystemFull](#troubleshoot-logging-errors-fsxfilesystemfull)
+ [오류: GatewayClockOutOfSync](#troubleshoot-logging-errors-gatewayclockoutofsync)
+ [오류: InvalidFileState](#troubleshoot-logging-errors-invalidfilestate)
+ [오류: ObjectMissing](#troubleshoot-logging-errors-objectmissing)
+ [오류: DroppedNotifications](#troubleshoot-logging-errors-droppednotifications)
+ [알림: HardReboot](#troubleshoot-hardreboot-notification)
+ [알림: 재부팅](#troubleshoot-reboot-notification)
+ [문제 해결: Active Directory 도메인 문제](#troubleshooting-ad-domain)
+ [문제 해결: CloudWatch 지표 사용](#troubleshooting-with-cw-metrics)
## 오류: FileMissing
`FileMissing` 오류는 `ObjectMissing` 오류와 유사하며 오류를 해결하는 단계는 동일합니다. 지정된 File Gateway 이외의 라이터가 Amazon FSx에서 지정된 파일을 삭제할 때 `FileMissing` 오류가 발생할 수 있습니다. 이후에 Amazon FSx에 업로드하거나 Amazon FSx에서 객체를 가져오는 작업이 모두 실패합니다.
**FileMissing 오류를 해결하려면**
1. SMB 클라이언트의 로컬 파일 시스템에 파일의 최신 복사본을 저장합니다(3단계에서 이 파일 복사본이 필요함).
1. SMB 클라이언트를 사용하여 File Gateway에서 파일을 삭제합니다.
1. SMB 클라이언트를 사용하여 1단계 Amazon FSx에서 저장한 파일의 최신 버전을 복사합니다. File Gateway를 통해 이 작업을 합니다.
## 오류: FsxFileSystemAuthenticationFailure
파일 시스템을 연결하는 동안 제공된 자격 증명이 만료되거나 권한이 취소되면 `FsxFileSystemAuthenticationFailure` 오류가 발생할 수 있습니다.
**FsxFileSystemAuthenticationFailure 오류를 해결하려면**
1. Amazon FSx 파일 시스템을 연결할 때 제공된 자격 증명이 여전히 유효한지 확인합니다.
1. [Amazon FSx for Windows File Server 파일 시스템 연결](https://docs.aws.amazon.com/filegateway/latest/filefsxw/attach-fsxw-filesystem.html)에 설명된 대로 사용자에게 필요한 모든 권한이 있는지 확인합니다.
## 오류: FsxFileSystemConnectionFailure
게이트웨이 시스템에서 Amazon FSx 서버에 액세스할 수 없는 경우 `FsxFileSystemConnectionFailure` 오류가 발생할 수 있습니다.
**FsxFileSystemConnectionFailure 오류를 해결하려면**
1. 모든 방화벽 및 VPC 규칙이 게이트웨이 시스템과 Amazon FSx 서버 간의 연결을 허용하는지 확인합니다.
1. Amazon FSx 서버가 실행되는지 확인합니다.
## 오류: FsxFileSystemFull
Amazon FSx 파일 시스템에 여유 디스크 공간이 충분하지 않은 경우 `FsxFileSystemFull` 오류가 발생할 수 있습니다.
**FsxFileSystemFull 오류를 해결하려면**
+ Amazon FSx 파일 시스템의 스토리지 공간을 늘립니다.
## 오류: 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/filefsxw/manage-on-premises-fgw.html#MaintenanceTimeSync-fgw)을 참조하세요.
## 오류: InvalidFileState
지정된 게이트웨이 이외의 라이터가 지정된 파일 공유에서 지정된 파일을 수정할 때 `InvalidFileState` 오류가 발생할 수 있습니다. 따라서 게이트웨이의 파일 상태가 Amazon FSx에서의 해당 상태와 일치하지 않습니다. 이후에 Amazon FSx로 파일을 업로드하거나 Amazon FSx에서 파일을 검색하지 못합니다.
**InvalidFileState 오류를 해결하려면**
1. SMB 클라이언트의 로컬 파일 시스템에 파일의 최신 복사본을 저장합니다(4단계에서 이 파일 복사본이 필요함). Amazon FSx에 있는 파일 버전이 최신이면 그 버전을 다운로드합니다. SMB 클라이언트를 사용하여 Amazon FSx 공유에 직접 액세스하여 이 작업을 수행할 수 있습니다.
1. Amazon FSx에서 파일을 직접 삭제합니다.
1. SMB 클라이언트를 사용하여 게이트웨이에서 파일을 삭제합니다.
1. SMB 클라이언트를 사용하여 1단계에서 저장한 파일의 최신 버전을 *File Gateway를 통해* Amazon FSx로 복사합니다.
## 오류: ObjectMissing
지정된 File Gateway 이외의 라이터가 Amazon FSx에서 지정된 파일을 삭제할 때 `ObjectMissing` 오류가 발생할 수 있습니다. 이후에 Amazon FSx에 업로드하거나 Amazon FSx에서 객체를 가져오는 작업이 모두 실패합니다.
**ObjectMissing 오류를 해결하려면**
1. SMB 클라이언트의 로컬 파일 시스템에 파일의 최신 복사본을 저장합니다(3단계에서 이 파일 복사본이 필요함).
1. SMB 클라이언트를 사용하여 File Gateway에서 파일을 삭제합니다.
1. SMB 클라이언트를 사용하여 1단계 Amazon FSx에서 저장한 파일의 최신 버전을 복사합니다. File Gateway를 통해 이 작업을 합니다.
## 오류: 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분 이내에 수행되는 경우 이 재부팅은 정상적인 현상일 수 있으며 문제의 징조가 아닙니다. 유지 관리 기간을 크게 벗어나 재부팅이 수행된 경우 게이트웨이가 수동으로 다시 시작되었는지 확인합니다.
## 문제 해결: Active Directory 도메인 문제
FSx File Gateway는 Active Directory 도메인 문제에 대한 특정 로그 메시지를 생성하지 않습니다. 게이트웨이를 Active Directory 도메인에 조인하는 데 문제가 있는 경우 다음을 수행합니다.
+ 게이트웨이가 읽기 전용 도메인 컨트롤러(RODC)를 사용하여 도메인에 조인하려고 하지 않는지 확인합니다.
+ 게이트웨이가 올바른 DNS 서버를 사용하도록 구성되어 있는지 확인합니다.
예를 들어 Amazon EC2 게이트웨이 인스턴스를 AWS관리형 Active Directory에 조인하려는 경우 EC2 VPC에 설정된 DHCP 옵션에 AWS관리형 Active Directory DNS 서버가 지정되어 있는지 확인합니다.
VPC DHCP 옵션 세트를 통해 구성하는 DNS 서버는 VPC의 모든 EC2 인스턴스에 제공됩니다. 개별 게이트웨이에 DNS 서버를 지정하려면 해당 게이트웨이의 EC2 로컬 콘솔을 사용하여 지정할 수 있습니다.
온프레미스 게이트웨이의 경우 VM 로컬 콘솔을 사용하여 DNS 서버를 지정합니다.
+ 게이트웨이의 로컬 콘솔에 있는 명령 프롬프트에서 다음 명령을 실행하여 게이트웨이 네트워크 연결을 확인합니다. 강조 표시된 변수를 배포의 실제 도메인 이름 및 IP 주소로 바꿉니다.
```
dig -d ExampleDomainName
ncport -d ExampleDomainControllerIPAddress -p 445
ncport -d ExampleDomainControllerIPAddress -p 389
```
+ Active Directory 서비스 계정에 필요한 권한이 있는지 확인합니다. 자세한 내용은 [Active Directory 서비스 계정 권한 요구 사항](https://docs.aws.amazon.com/filegateway/latest/filefsxw/ad-serviceaccount-permissions.html)을 참조하세요.
+ 게이트웨이가 올바른 조직 단위(OU)에 조인하는지 확인합니다.
도메인에 조인하면 게이트웨이의 **게이트웨이 ID**를 계정 이름(예: SGW-1234ADE)으로 사용하여 기본 컴퓨터 컨테이너(OU 아님)에 Active Directory 컴퓨터 계정이 생성됩니다. 이 계정의 이름은 사용자 지정할 수 없습니다.
Active Directory 환경에 새 컴퓨터 객체에 대해 지정된 OU가 있는 경우 도메인을 조인할 때 해당 OU를 지정해야 합니다.
지정된 OU에 조인하려고 할 때 액세스 거부 오류가 발생하면 Active Directory 도메인 관리자에게 문의하십시오. 관리자가 게이트웨이의 컴퓨터 계정을 미리 준비해야 도메인에 조인할 수 있습니다. 자세한 내용은 [Microsoft Active Directory 인증을 위해 Storage Gateway File Gateway를 도메인에 조인하는 것과 관련된 문제를 해결하려면 어떻게 해야 합니까?](https://aws.amazon.com/premiumsupport/knowledge-center/storage-gateway-domain-join-error/)를 참조하세요.
+ 게이트웨이의 로컬 콘솔에 있는 명령 프롬프트에서 다음 명령을 실행하여 게이트웨이의 호스트 이름을 DNS에서 확인할 수 있는지 확인합니다. 강조 표시된 변수를 게이트웨이의 실제 호스트 이름으로 바꿉니다.
```
dig -d ExampleHostName -r A
```
게이트웨이에 대한 사용자 지정 호스트 이름을 구성한 경우 IP 주소를 가리키는 DNS A 레코드를 수동으로 추가해야 합니다.
+ 게이트웨이와 도메인 컨트롤러 간의 네트워크 지연 시간이 상당히 낮은지 확인합니다. 게이트웨이가 20초 이내에 도메인 컨트롤러로부터 응답을 받지 못하면 도메인에 조인하기 위한 쿼리 시간이 초과될 수 있습니다.
[JoinDomain](https://docs.aws.amazon.com/storagegateway/latest/APIReference/API_JoinDomain.html) CLI 명령을 사용하여 게이트웨이를 도메인에 조인하는 경우 `--timeout-in-seconds` 플래그를 추가하여 제한 시간을 최대 3,600초로 늘릴 수 있습니다.
+ 게이트웨이를 도메인에 조인하는 데 사용하는 Active Directory 사용자에게 필요한 권한이 있는지 확인합니다.
## 문제 해결: CloudWatch 지표 사용
Storage Gateway에서 Amazon CloudWatch 지표를 사용하여 문제를 해결하는 작업에 대한 다음 정보를 찾을 수 있습니다.
**Topics**
+ [디렉터리를 찾아볼 때 게이트웨이가 느리게 반응](#slow-gateway)
+ [게이트웨이가 응답하지 않음](#gateway-not-responding)
+ [Amazon FSx 파일 시스템에 파일이 표시되지 않음](#files-missing-fsx)
+ [Amazon FSx 파일 시스템에 이전 스냅샷이 표시되지 않음](#snapshots-missing-fsx)
+ [게이트웨이에서 데이터를 Amazon FSx로 전송하는 속도가 느림](#slow-data-transfer-to-fsx)
+ [게이트웨이 백업 작업이 실패하거나 게이트웨이에 쓸 때 오류가 발생함](#backup-job-fails)
### 디렉터리를 찾아볼 때 게이트웨이가 느리게 반응
**ls** 명령을 실행하거나 디렉터리를 찾아볼 때 File Gateway가 느리게 반응하는 경우 `IndexFetch` 및 `IndexEviction` CloudWatch 지표를 확인합니다.
+ `ls` 명령을 실행하거나 디렉터리를 찾아볼 때 `IndexFetch` 지표가 0보다 큰 경우 File Gateway가 영향을 받은 디렉터리 콘텐츠에 대한 정보 없이 시작했으며 FSx for Windows File Server에 액세스해야 했습니다. 해당 디렉터리의 콘텐츠를 나열하려는 후속 노력이 더 빨리 이루어져야 합니다.
+ `IndexEviction` 지표가 0보다 크면 File Gateway가 해당 시점에 캐시에서 관리할 수 있는 항목 한계에 도달했음을 의미합니다. 이 경우 File Gateway는 새 디렉터리를 나열하기 위해 가장 이전에 액세스한 디렉터리에서 일부 스토리지 스페이스를 비워야 합니다. 이 문제가 자주 발생하고 성능에 영향을 미치는 경우에 문의하세요 지원.
관련 Amazon FSx 파일 시스템의 지원 내용과 사용 사례에 따라 성능을 개선하기 위한 권장 사항을 논의합니다.
### 게이트웨이가 응답하지 않음
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 FSx 파일 시스템에 파일이 표시되지 않음
게이트웨이의 파일이 Amazon FSx 파일 시스템에 반영되지 않는 경우 `FilesFailingUpload` 지표를 확인합니다. 지표에서 일부 파일이 업로드에 실패한다고 보고하는 경우 상태 알림을 확인합니다. 파일을 업로드하지 못하면 게이트웨이는 문제에 대한 세부 정보가 포함된 상태 알림을 생성합니다.
### Amazon FSx 파일 시스템에 이전 스냅샷이 표시되지 않음
최상위 폴더 이름 바꾸기 또는 권한 변경과 같은 FSx File Gateway의 일부 파일 작업으로 인해 여러 파일 작업이 발생하여 FSx for Windows File Server 파일 시스템에서 I/O 로드가 높아질 수 있습니다. 파일 시스템에 워크로드에 대한 성능 리소스가 충분하지 않은 경우 파일 시스템은 기록 섀도우 복사본 보존보다 지속적인 I/O의 가용성을 우선시하기 때문에 [섀도우 복사본](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/shadow-copies-fsxW.html)을 삭제할 수 있습니다.
Amazon FSx 콘솔에서 **모니터링 및 성능** 페이지를 확인하여 파일 시스템이 과소 프로비저닝되었는지 확인합니다. 그렇다면 SSD 스토리지로 전환하거나, 처리량 용량을 늘리거나, SSD IOPS를 늘려 워크로드를 처리할 수 있습니다.
### 게이트웨이에서 데이터를 Amazon FSx로 전송하는 속도가 느림
File Gateway가 Amazon FSx for Windows File Server로 데이터를 느리게 전송하는 경우 다음을 수행합니다.
+ `CachePercentDirty` 지표가 80 이상인 경우 File Gateway는 데이터를 Amazon FSx for Windows File Server에 업로드할 수 있는 것보다 더 빨리 디스크에 데이터를 쓰고 있습니다. File Gateway에서 업로드할 대역폭을 늘리거나, 하나 이상의 캐시 디스크를 추가하거나, 클라이언트 쓰기 속도를 늦추거나, 연결된 Amazon FSx for Windows File Server의 처리량 용량을 늘리는 것이 좋습니다.
+ `CachePercentDirty` 지표가 낮은 경우 `IoWaitPercent` 지표를 확인합니다. `IoWaitPercent`가 10보다 큰 경우 로컬 캐시 디스크의 속도로 인해 File Gateway에 병목 현상이 발생할 수 있습니다. 캐시에 로컬 SSD(Solid State Drive) 디스크를 사용하는 것이 좋습니다. 추천 제품은 NVMe(NVM Express)입니다. 이러한 디스크를 사용할 수 없는 경우 성능 향상을 위해 별도의 물리적 디스크에서 여러 캐시 디스크를 사용해 보십시오.
### 게이트웨이 백업 작업이 실패하거나 게이트웨이에 쓸 때 오류가 발생함
File Gateway 백업 작업이 실패하거나 File Gateway에 쓸 때 오류가 발생하는 경우 다음을 수행합니다.
+ `CachePercentDirty` 지표가 90% 이상이면 캐시 디스크에 사용 가능한 공간이 부족하기 때문에 File Gateway가 디스크에 대한 새 쓰기를 허용할 수 없습니다. File Gateway가 FSx for Windows File Server에 업로드되는 속도를 확인하려면 `CloudBytesUploaded` 지표를 확인합니다. 클라이언트가 File Gateway에 파일을 쓰는 속도를 보여 주는 `WriteBytes` 지표를 이 지표와 비교합니다. SMB 클라이언트가 FSx for Windows File Server로 업로드할 수 있는 것보다 더 빨리 File Gateway에 쓰는 경우 최소한 백업 작업의 크기를 처리할 수 있도록 캐시 디스크를 더 추가합니다. 또는 업로드 대역폭을 늘립니다.
+ 백업 작업과 같은 대용량 파일 복사가 실패했지만 `CachePercentDirty` 지표가 80% 미만인 경우 File Gateway가 클라이언트 측 세션 제한 시간에 도달할 수 있습니다. SMB의 경우 PowerShell 명령 `Set-SmbClientConfiguration -SessionTimeout 300`을 사용하여 이 제한 시간을 늘릴 수 있습니다. 이 명령을 실행하면 이 제한 시간이 300초로 설정됩니다.
## 고가용성 상태 알림
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 로그 그룹에 문의하십시오.