기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 게이트웨이 문제 해결
다음에서 게이트웨이, 호스트 플랫폼, 볼륨, 고가용성, 데이터 복구 및 스냅샷과 관련된 모범 사례 및 문제 해결에 대한 정보를 찾을 수 있습니다. 온프레미스 게이트웨이 문제 해결 정보는 지원되는 가상화 플랫폼에 배포된 게이트웨이를 다룹니다. 고가용성 문제에 대한 문제 해결 정보는 VMware vSphere HA(고가용성) 플랫폼에서 실행 중인 게이트웨이를 다룹니다.
**주제**
+ [문제 해결: 게이트웨이 오프라인 문제](troubleshooting-gateway-offline.md) - Storage Gateway 콘솔에서 게이트웨이가 오프라인으로 표시될 수 있는 문제를 진단하는 방법에 대해 알아봅니다.
+ [문제 해결: 게이트웨이 활성화 중 내부 오류 발생](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) - Storage Gateway 하드웨어 어플라이언스에서 발생할 수 있는 문제를 해결하는 방법에 대해 알아봅니다.
+ [볼륨 문제 해결](troubleshoot-volume-issues.md) - 볼륨 관련 작업 시 겪을 수 있는 가장 일반적인 문제와 이 문제를 해결하기 위해 권장하는 조치에 대한 정보를 찾을 수 있습니다.
+ [고가용성 문제 해결](troubleshooting-ha-issues.md) - VMware HA 환경에 배포된 게이트웨이에 문제가 발생하는 경우 취해야 할 조치에 대해 알아봅니다.
# 문제 해결: 게이트웨이 오프라인 문제
다음 문제 해결 정보를 참조하여 AWS Storage Gateway 콘솔에서 게이트웨이가 오프라인 상태인 것으로 표시되는 경우에 취해야 할 조치를 결정하세요.
다음 중 하나 이상의 이유로 게이트웨이가 오프라인으로 표시될 수 있습니다.
+ 게이트웨이가 Storage Gateway 서비스 엔드포인트에 연결할 수 없습니다.
+ 게이트웨이가 예기치 않게 종료되었습니다.
+ 게이트웨이와 연결된 캐시 디스크가 연결 해제 또는 수정되었거나 실패했습니다.
게이트웨이를 다시 온라인 상태로 되돌리려면 게이트웨이를 오프라인 상태로 만든 문제를 파악하여 해결합니다.
## 연결된 방화벽 또는 프록시 확인
프록시를 사용하도록 게이트웨이를 구성했거나 게이트웨이를 방화벽 뒤에 배치한 경우 프록시 또는 방화벽의 액세스 규칙을 검토합니다. 프록시 또는 방화벽은 Storage Gateway에 필요한 네트워크 포트 및 서비스 엔드포인트와의 트래픽을 허용해야 합니다. 자세한 내용은 [네트워크 및 방화벽 요구 사항](https://docs.aws.amazon.com/storagegateway/latest/vgw/Requirements.html#networks)을 참조하세요.
## 게이트웨이 트래픽에 대해 SSL 또는 딥패킷 검사가 진행 중인지 확인
게이트웨이와 간의 네트워크 트래픽에 대해 SSL 또는 딥 패킷 검사가 현재 수행 중인 AWS경우 게이트웨이가 필요한 서비스 엔드포인트와 통신하지 못할 수 있습니다. 게이트웨이를 다시 온라인 상태로 되돌리려면 검사를 비활성화해야 합니다.
## 하이퍼바이저 호스트의 정전 또는 하드웨어 장애 확인
게이트웨이의 하이퍼바이저 호스트에서 정전 또는 하드웨어 장애가 발생하면 게이트웨이가 예기치 않게 종료되어 연결이 불가능해질 수 있습니다. 전원 및 네트워크 연결을 복원하면 게이트웨이에 다시 연결할 수 있게 됩니다.
게이트웨이가 다시 온라인 상태가 되면 데이터 복구 조치를 취해야 합니다. 자세한 내용은 [데이터 복구 모범 사례](https://docs.aws.amazon.com/storagegateway/latest/vgw/recover-data-from-gateway.html)를 참조하세요.
## 연결된 캐시 디스크에 문제가 있는지 확인
게이트웨이와 연결된 캐시 디스크 중 하나 이상이 제거, 변경 또는 크기 조정되었거나 손상된 경우 게이트웨이가 오프라인 상태가 될 수 있습니다.
**하이퍼바이저 호스트에서 작동 중인 캐시 디스크를 제거한 경우**
1. 게이트웨이를 종료합니다.
1. 디스크를 다시 추가합니다.
**참고**
동일한 디스크 노드에 디스크를 추가해야 합니다.
1. 게이트웨이를 다시 시작합니다.
**캐시 디스크가 손상되었거나 교체되었거나 크기가 조정된 경우**
1. 게이트웨이를 종료합니다.
1. 캐시 디스크를 재설정합니다.
1. 캐시 스토리지를 위해 디스크를 재구성합니다.
1. 게이트웨이를 다시 시작합니다.
# 문제 해결: 게이트웨이 활성화 중 내부 오류 발생
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/storagegateway/latest/vgw/manage-on-premises-common.html#MaintenanceTestGatewayConnectivity-common)를 참조하세요.
**참고**
게이트웨이 콘솔의 기본 로그인 사용자 이름은 `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/storagegateway/latest/vgw/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
## 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/storagegateway/latest/vgw/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/storagegateway/latest/vgw/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/storagegateway/latest/vgw/troubleshooting-on-premises-gateway-issues.html) 그래도 게이트웨이 IP 주소를 찾기 어려운 경우: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/storagegateway/latest/vgw/troubleshooting-on-premises-gateway-issues.html) |
| 네트워크 또는 방화벽에 문제가 있습니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/storagegateway/latest/vgw/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/storagegateway/latest/vgw/troubleshooting-on-premises-gateway-issues.html) |
| 업로드 버퍼 공간으로 할당된 디스크를 제거해야 합니다. 예를 들어 게이트웨이의 업로드 버퍼 공간을 줄이거나 업로드 버퍼로 사용하는 디스크에 장애가 있어 교체해야 할 경우가 있습니다. | 업로드 버퍼 공간으로 할당된 디스크를 제거하는 작업에 대한 지침은 [게이트웨이에서 디스크 제거](add-remove-disks.md) 섹션을 참조하세요. |
| 게이트웨이와 AWS간 대역폭을 개선해야 합니다. | 애플리케이션 및 게이트웨이 VM을 연결하는 것과 별도로 네트워크 어댑터(NIC) AWS 에서에 대한 인터넷 연결을 설정 AWS 하여 게이트웨이에서 로 대역폭을 개선할 수 있습니다. 이 접근 방식은에 고대역폭으로 연결되어 AWS 있고 특히 스냅샷 복원 중에 대역폭 경합을 피하려는 경우에 유용합니다. 고처리량 워크로드 요구 사항을 충족하기 위해 [Direct Connect](https://aws.amazon.com/directconnect/)를 사용하여 온프레미스 게이트웨이와 AWS간에 전용 네트워크 연결을 설정할 수 있습니다. 게이트웨이에서 로의 연결 대역폭을 측정하려면 게이트웨이의 `CloudBytesDownloaded` 및 `CloudBytesUploaded` 지표를 AWS사용합니다. 이에 관한 자세한 내용은 [게이트웨이와 간의 성능 측정 AWS](PerfGatewayAWS-common.md) 섹션을 참조하세요. 인터넷 연결성을 개선하면 업로드 버퍼가 꽉 차지 않도록 하는 데 도움이 됩니다. |
| 게이트웨이로의 처리량 또는 게이트웨이로부터의 처리량이 0으로 떨어집니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/storagegateway/latest/vgw/troubleshooting-on-premises-gateway-issues.html) 게이트웨이와 주고받는 처리량은 Amazon CloudWatch 콘솔에서 확인할 수 있습니다. 게이트웨이 및 와의 처리량 측정에 대한 자세한 내용은 섹션을 AWS참조하세요[게이트웨이와 간의 성능 측정 AWS](PerfGatewayAWS-common.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**를 입력하여 게이트웨이 콘솔에서 로그아웃합니다.
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/storagegateway/latest/vgw/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 요구 사항에 대한 자세한 내용은 [Volume Gateway 설정 요구 사항](Requirements.md) 섹션을 참조하세요. |
| 게이트웨이 VM을 시작하려고 하는데 다음과 같은 오류 메시지가 나타납니다. “선택한 가상 머신을 시작하는 동안 오류가 발생했습니다. 'AWS-Storage-Gateway'를 초기화할 수 없습니다. (가상 머신 ID [...]) 파티션을 생성하지 못했습니다. 요청된 서비스를 완료하는 데 필요한 시스템 리소스가 부족합니다. (0x800705AA)" | 이 오류는 게이트웨이에 필요한 RAM과 호스트에서 사용 가능한 RAM 사이의 RAM 불일치로 인해 발생할 수 있습니다. Storage Gateway 요구 사항에 대한 자세한 내용은 [Volume Gateway 설정 요구 사항](Requirements.md) 섹션을 참조하세요. |
| 스냅샷 및 게이트웨이 소프트웨어 업데이트는 예상과 약간 다른 시각에 실행됩니다. | 게이트웨이 VM의 클럭은 실제 시간과 약간 오차가 있을 수 있는데, 이를 클럭 드리프트라고 합니다. 로컬 게이트웨이 콘솔의 시간 동기화 옵션을 사용하여 VM의 시간을 점검하고 수정합니다. 자세한 내용은 [Hyper-V 또는 Linux KVM 호스트 시간과 VM 시간 동기화](MaintenanceTimeSync-hyperv.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에 배포한 게이트웨이 간의 차이점에 대한 자세한 내용은 [Volume Gateway용 사용자 지정 Amazon EC2 인스턴스 배포](ec2-gateway-common.md) 섹션을 참조하세요.
**Topics**
+ [몇 분 후 게이트웨이가 활성화되지 않음](#activation-issues)
+ [인스턴스 목록에서 EC2 게이트웨이 인스턴스를 찾을 수 없음](#find-instance)
+ [Amazon EBS 볼륨을 생성했지만 EC2 게이트웨이 인스턴스에 연결할 수 없음](#ebs-volume-issue)
+ [EC2 게이트웨이의 볼륨 대상에 이니시에이터를 연결할 수 없음](#initiator-issue)
+ [스토리지 볼륨을 추가하려고 할 때 사용 가능한 디스크가 없다는 메시지가 표시되는 경우](#no-disk)
+ [업로드 버퍼 공간으로 할당된 디스크를 제거하여 업로드 버퍼 공간을 줄이려는 경우](#uploadbuffer-issue)
+ [EC2 게이트웨이와 주고받는 데이터의 처리량이 0으로 떨어짐](#gateway-throughput-issue)
+ [EC2 게이트웨이 문제를 해결하는 지원 데 도움이 필요한 경우](#EC2-EnableAWSSupportAccess)
+ [Amazon EC2 직렬 콘솔을 사용하여 게이트웨이 인스턴스에 연결하려는 경우](#ec2-serial-console)
## 몇 분 후 게이트웨이가 활성화되지 않음
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 EBS 볼륨을 생성했지만 EC2 게이트웨이 인스턴스에 연결할 수 없음
해당 Amazon EBS 볼륨이 게이트웨이 인스턴스와 동일한 가용 영역에 있는지 확인합니다. 가용 영역이 불일치하는 경우, 인스턴스와 동일한 가용 영역에 새 Amazon EBS 볼륨을 생성합니다.
## EC2 게이트웨이의 볼륨 대상에 이니시에이터를 연결할 수 없음
인스턴스를 실행한 보안 그룹에 iSCSI 액세스에 사용 중인 포트를 허용하는 규칙이 포함되어 있는지 확인합니다. 포트는 대개 3260으로 설정되어 있습니다. 볼륨 연결에 대한 자세한 내용은 [Windows 클라이언트에서 볼륨 연결](ConfiguringiSCSIClient.md) 단원을 참조하십시오.
## 스토리지 볼륨을 추가하려고 할 때 사용 가능한 디스크가 없다는 메시지가 표시되는 경우
새로 활성화된 게이트웨이에 볼륨 스토리지가 정의되지 않았습니다. 볼륨 스토리지를 정의하려면 먼저 게이트웨이에 업로드 버퍼 및 캐시 스토리지로 사용할 로컬 디스크를 할당해야 합니다. Amazon EC2에 배포된 게이트웨이의 경우, 로컬 디스크는 인스턴스에 연결된 Amazon EBS 볼륨입니다. 이 오류 메시지는 해당 인스턴스에 Amazon EBS 볼륨을 정의하지 않았기 때문에 표시되는 것일 수 있습니다.
게이트웨이를 실행하는 인스턴스에 정의된 블록 디바이스를 확인합니다. 블록 디바이스(AMI와 함께 제공되는 기본 디바이스)가 두 개뿐이라면 스토리지를 추가해야 합니다. 이에 대한 자세한 내용은 [Volume Gateway용 사용자 지정 Amazon EC2 인스턴스 배포](ec2-gateway-common.md) 섹션을 참조하세요. Amazon EBS 볼륨을 두 개 이상 연결한 후 게이트웨이에 볼륨 스토리지를 생성합니다.
## 업로드 버퍼 공간으로 할당된 디스크를 제거하여 업로드 버퍼 공간을 줄이려는 경우
[할당할 업로드 버퍼의 크기 결정](decide-local-disks-and-sizes.md#CachedLocalDiskUploadBufferSizing-common) 섹션의 단계를 따르세요.
## EC2 게이트웨이와 주고받는 데이터의 처리량이 0으로 떨어짐
게이트웨이 인스턴스가 실행 중인지 확인합니다. 예를 들어 해당 인스턴스가 재부팅되고 있는 중이라면 인스턴스가 다시 시작할 때까지 기다립니다.
또한 게이트웨이 IP가 변경되지 않았는지 확인합니다. 인스턴스를 중단했다가 다시 시작한 경우, 인스턴스의 IP 주소가 변경되었을 수 있습니다. 이 경우 새 게이트웨이를 활성화해야 합니다.
게이트웨이와 주고받는 처리량은 Amazon CloudWatch 콘솔에서 확인할 수 있습니다. 게이트웨이 및 와의 처리량 측정에 대한 자세한 내용은 섹션을 AWS참조하세요[게이트웨이와 간의 성능 측정 AWS](PerfGatewayAWS-common.md).
## 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**를 입력하여 세션을 종료합니다. 가 지원 세션이 완료되었음을 지원 알릴 때까지 세션을 닫지 마십시오.
1. **exit**를 입력하여 Storage Gateway 콘솔을 종료합니다.
1. 콘솔 메뉴에 따라 Storage Gateway 인스턴스에서 로그아웃합니다.
## Amazon EC2 직렬 콘솔을 사용하여 게이트웨이 인스턴스에 연결하려는 경우
Amazon EC2 직렬 콘솔을 사용하여 부팅, 네트워크 구성 및 기타 문제를 해결할 수 있습니다. 지침과 문제 해결 팁은 *Amazon Elastic Compute Cloud 사용 설명서*의 [Amazon EC2 직렬 콘솔](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-serial-console.html) 섹션을 참조하십시오.
# 하드웨어 어플라이언스 문제 해결
다음 주제에서는 Storage Gateway Hardware Appliance에서 발생할 수 있는 문제와 이러한 문제를 해결하기 위한 제안 사항에 대해 설명합니다.
## 서비스 IP 주소를 확인할 수 없음
서비스에 연결할 때 호스트 IP 주소가 아닌 서비스의 IP 주소를 사용하고 있는지 확인합니다. 서비스 콘솔에서 서비스 IP 주소를 구성하고 하드웨어 콘솔에서 호스트 IP 주소를 구성합니다. 하드웨어 어플라이언스를 시작하면 하드웨어 콘솔이 표시됩니다. 하드웨어 콘솔에서 서비스 콘솔로 이동하려면 **Open Service Console(서비스 콘솔 열기)**을 선택합니다.
## 공장 초기화는 어떻게 수행하나요?
어플라이언스에서 공장 초기화를 수행해야 하는 경우, 다음 지원 섹션에 설명된 대로 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 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. 포트 번호를 기록하여에 제공합니다 지원.
# 볼륨 문제 해결
볼륨 관련 작업 시 겪을 수 있는 가장 일반적인 문제와 이 문제를 해결하기 위해 취해야 할 조치에 대한 정보를 얻을 수 있습니다.
**Topics**
+ [볼륨을 구성하지 않았다고 콘솔이 표시하는 경우](#troubleshoot-volume-issues.VolumeNotConfigured)
+ [볼륨을 복구할 수 없다고 콘솔이 표시하는 경우](#troubleshoot-volume-issues.VolumeIrrecoverable)
+ [캐싱된 게이트웨이에 액세스할 수 없어서 데이터 복구를 원하는 경우](#RecoverySnapshotTroubleshooting)
+ [볼륨이 PASS THROUGH 상태라고 콘솔이 표시하는 경우](#troubleshoot-volume-issues.VolumePassthrough)
+ [볼륨 무결성을 확인하고 가능한 오류를 수정하고자 하는 경우](#troubleshoot-volume-issues.VerifyIntegrity)
+ [Windows 디스크 관리 콘솔이 볼륨의 iSCSI 대상을 표시하지 않는 경우](#troubleshoot-volume-issues.DoesNotAppear)
+ [볼륨의 iSCSI 대상 이름을 변경하고자 하는 경우](#troubleshoot-volume-issues.ChangeISCSI)
+ [예약 볼륨 스냅샷이 생기지 않은 경우](#troubleshoot-volume-issues.NoSnapshot)
+ [장애를 일으킨 디스크를 제거하거나 교체해야 하는 경우](#troubleshoot-volume-issues.RemoveVolume)
+ [애플리케이션에서 볼륨까지 처리량이 0으로 떨어진 경우](#troubleshoot-volume-issues.ThroughputZero)
+ [게이트웨이의 캐시 디스크에 장애가 발생한 경우](#troubleshoot-volume-issues.CacheDiskFail)
+ [볼륨 스냅샷이 예상보다 오래 PENDING 상태에 있는 경우](#SnapshotTroubleshooting.Pending)
+ [고가용성 상태 알림](#troubleshooting-ha-notifications)
## 볼륨을 구성하지 않았다고 콘솔이 표시하는 경우
볼륨이 UPLOAD BUFFER NOT CONFIGURED 상태에 있다고 Storage Gateway 콘솔에 표시되는 경우, 게이트웨이에 업로드 버퍼 용량을 추가합니다. 게이트웨이에 업로드 버퍼를 구성하지 않은 경우, 게이트웨이를 사용하여 애플리케이션 데이터를 저장할 수 없습니다. 자세한 내용은 [게이트웨이에 대한 추가 업로드 버퍼 또는 캐시 스토리지를 구성하려면](ConfiguringLocalDiskStorage.md#GatewayWorkingStorageCachedTaskBuffer) 단원을 참조하십시오.
## 볼륨을 복구할 수 없다고 콘솔이 표시하는 경우
저장 볼륨의 경우, 볼륨이 IRRECOVERABLE 상태에 있다고 Storage Gateway 콘솔에 표시되면 더 이상 이 볼륨을 사용할 수 없습니다. Storage Gateway 콘솔에서 볼륨 삭제를 시도할 수 있습니다. 볼륨에 데이터가 있는 경우, 볼륨을 생성하기 위해 처음 사용한 VM의 로컬 디스크를 기반으로 하여 새 볼륨을 생성할 때 해당 데이터를 복구할 수 있습니다. 새 볼륨을 생성할 때 **Preserve existing data(기존 데이터 보존)**를 선택합니다. 볼륨을 삭제하기 전에 볼륨에서 보류 중인 스냅샷을 삭제해야 합니다. 자세한 내용은 [스토리지 볼륨의 스냅샷 삭제](DeletingASnapshot.md) 단원을 참조하십시오. Storage Gateway 콘솔에서 볼륨을 삭제하려고 하는데 잘 되지 않는 경우, 볼륨에 할당한 디스크가 VM에서 부적절하게 제거되어 어플라이언스에서 제거할 수 없기 때문일 수 있습니다.
캐시 볼륨의 경우, 볼륨이 IRRECOVERABLE 상태에 있다고 Storage Gateway 콘솔에 표시되면 더 이상 이 볼륨을 사용할 수 없습니다. 볼륨에 데이터가 있는 경우 볼륨의 스냅샷을 생성하고 스냅샷에서 데이터를 복구하거나 마지막 복구 시점에서 볼륨을 복제할 수 있습니다. 데이터를 복구한 후에는 볼륨을 삭제할 수 있습니다. 자세한 내용은 [캐싱된 게이트웨이에 액세스할 수 없어서 데이터 복구를 원하는 경우](#RecoverySnapshotTroubleshooting) 단원을 참조하십시오.
저장 볼륨의 경우, 복구할 수 없는 볼륨을 생성하는 데 사용한 디스크에서 새 볼륨을 생성할 수 있습니다. 자세한 내용은 [스토리지 볼륨 생성](GettingStartedCreateVolumes.md) 단원을 참조하십시오. 볼륨 상태에 대한 내용은 [볼륨 상태 및 전환 이해](StorageVolumeStatuses.md) 단원을 참조하십시오.
## 캐싱된 게이트웨이에 액세스할 수 없어서 데이터 복구를 원하는 경우
게이트웨이를 종료한 경우와 같이 게이트웨이에 접속할 수 없을 때는 볼륨 복구 시점에서 스냅샷을 생성하여 그 스냅샷을 사용하거나 기존 볼륨의 마지막 복구 시점에서 새 볼륨을 복제하는 옵션이 있습니다. 볼륨 복구 시점에서 복제하는 것이 스냅샷을 생성하는 것보다 빠르고 비용 효과적입니다. 볼륨 복제에 대한 자세한 내용은 [복구 시점에서 캐시 볼륨 복제](clone-volume.md) 단원을 참조하십시오.
Storage Gateway는 캐시된 Volume Gateway 아키텍처의 각 볼륨마다 복구 지점을 제공합니다. *볼륨 복구 시점*은 볼륨의 모든 데이터가 일관되고 스냅샷을 생성하거나 볼륨을 복제할 수 있는 시점입니다.
## 볼륨이 PASS THROUGH 상태라고 콘솔이 표시하는 경우
어떤 경우에는 볼륨이 PASSTHROUGH 상태에 있다고 Storage Gateway 콘솔에 표시될 수 있습니다. 한 볼륨은 여러 가지 이유로 PASSTHROUGH 상태가 될 수 있습니다. 조치가 필요한 이유가 있고 필요 없는 이유가 있습니다.
볼륨이 PASS THROUGH 상태일 때 조치를 취해야 하는 경우의 한 가지 예로 게이트웨이에 업로드 버퍼 공간이 모자란 경우를 들 수 있습니다. 이전에 업로드 버퍼를 초과했는지 확인하려면 Amazon CloudWatch 콘솔에서 `UploadBufferPercentUsed` 지표를 찾아볼 수 있습니다. 이에 관한 자세한 내용은 [업로드 버퍼 모니터링](PerfUploadBuffer-common.md) 섹션을 참조하세요. 업로드 버퍼 공간이 부족하여 게이트웨이가 PASS THROUGH 상태인 경우 게이트웨이에 더 많은 업로드 버퍼 공간을 할당해야 합니다. 버퍼 공간을 더 추가하면 볼륨이 PASS THROUGH에서 BOOTSTRAPPING을 거쳐 AVAILBAILLE로 자동 전환됩니다. 볼륨이 BOOTSTRAPPING 상태인 동안에 게이트웨이는 볼륨의 디스크에서 데이터를 읽고 이 데이터를 Amazon S3에 업로드하며 필요에 따라 갱신합니다. 게이트웨이가 갱신되어 볼륨 데이터를 Amazon S3에 저장하면 볼륨 상태가 AVAILABLE로 변경되고 스냅샷을 다시 시작할 수 있습니다. 볼륨이 PASS THROUGH 또는 BOOTSTRAPPING 상태인 경우, 볼륨 디스크에서 데이터를 계속 읽고 쓸 수 있다는 점에 유의하십시오. 업로드 버퍼 공간 추가에 대한 자세한 내용은 [할당할 업로드 버퍼의 크기 결정](decide-local-disks-and-sizes.md#CachedLocalDiskUploadBufferSizing-common) 단원을 참조하십시오.
업로드 버퍼를 초과하기 전에 조치를 취하려면 게이트웨이의 업로드 버퍼에 임계값 경보를 설정합니다. 자세한 내용은 [게이트웨이의 업로드 버퍼에 대한 경보 상한값을 설정하려면](PerfUploadBuffer-common.md#GatewayAlarm1-common) 단원을 참조하십시오.
이와 대조적으로 볼륨이 PASS THROUGH 상태인데도 조치를 취할 필요가 없는 경우의 한 가지 예로 현재 다른 볼륨을 부트스트래핑 중이어서 해당 볼륨이 부트스트래핑을 기다리고 있는 경우를 들 수 있습니다. 게이트웨이는 볼륨을 한 번에 하나씩 부트스트래핑합니다.
드물게 PASS THROUGH 상태가 업로드 버퍼에 할당한 디스크에 장애가 있음을 나타내는 경우가 있습니다. 이 경우 해당 디스크를 제거해야 합니다. 자세한 내용은 [Volume Gateway 스토리지 리소스 작업](resource-volume-gateway.md) 단원을 참조하십시오. 볼륨 상태에 대한 내용은 [볼륨 상태 및 전환 이해](StorageVolumeStatuses.md) 단원을 참조하십시오.
## 볼륨 무결성을 확인하고 가능한 오류를 수정하고자 하는 경우
볼륨 무결성을 확인하고 가능한 오류를 수정하고자 하는 경우, 그리고 게이트웨이에서 Microsoft Windows 초기자를 사용하여 볼륨에 연결하는 경우, Windows CHKDSK 유틸리티를 사용하여 볼륨의 무결성을 확인하고 볼륨에 있는 모든 오류를 수정할 수 있습니다. 볼륨 손상을 감지하면 Windows는 자동으로 CHKDSK 도구를 실행합니다. 아니면 수동으로 실행할 수도 있습니다.
## Windows 디스크 관리 콘솔이 볼륨의 iSCSI 대상을 표시하지 않는 경우
Windows에서 디스크 관리 콘솔이 볼륨의 iSCSI 대상을 표시하지 않는 경우에는 게이트웨이에 업로드 버퍼를 구성했는지 확인합니다. 자세한 내용은 [게이트웨이에 대한 추가 업로드 버퍼 또는 캐시 스토리지를 구성하려면](ConfiguringLocalDiskStorage.md#GatewayWorkingStorageCachedTaskBuffer) 단원을 참조하십시오.
## 볼륨의 iSCSI 대상 이름을 변경하고자 하는 경우
볼륨의 iSCSI 대상 이름을 변경하고자 하는 경우에는 해당 볼륨을 삭제한 후 새 대상 이름으로 다시 추가해야 합니다. 이렇게 하면 볼륨의 데이터를 보존할 수 있습니다.
## 예약 볼륨 스냅샷이 생기지 않은 경우
예약 볼륨 스냅샷이 생기지 않은 경우에는 볼륨이 PASSTHROUGH 상태인지, 아니면 게이트웨이의 업로드 버퍼가 예약된 스냅샷 시간 바로 전에 가득 찼는지 여부를 확인합니다. Amazon CloudWatch 콘솔에서 게이트웨이에 대한 `UploadBufferPercentUsed` 지표를 확인하고 이 지표에 대한 경보를 생성할 수 있습니다. 자세한 내용은 [업로드 버퍼 모니터링](PerfUploadBuffer-common.md) 및 [게이트웨이의 업로드 버퍼에 대한 경보 상한값을 설정하려면](PerfUploadBuffer-common.md#GatewayAlarm1-common) 섹션을 참조하세요.
## 장애를 일으킨 디스크를 제거하거나 교체해야 하는 경우
장애를 일으킨 볼륨 디스크를 교체하거나, 혹은 필요 없는 볼륨을 제거해야 하는 경우에는 먼저 Storage Gateway 콘솔을 사용하여 해당 볼륨을 제거해야 합니다. 자세한 내용은 [볼륨을 삭제하려면](ApplicationStorageVolumesCached-Removing.md#CachedRemovingAStorageVolume) 단원을 참조하십시오. 그 다음에는 다음과 같이 하이퍼바이저 클라이언트를 사용하여 지원 스토리지를 제거합니다.
+ VMware ESXi의 경우, [스토리지 볼륨 삭제](ApplicationStorageVolumesCached-Removing.md) 단원의 지침에 따라 지원 스토리지를 제거합니다.
+ Microsoft Hyper-V의 경우, 지원 스토리지를 제거합니다.
## 애플리케이션에서 볼륨까지 처리량이 0으로 떨어진 경우
애플리케이션에서 볼륨까지 처리량이 0으로 떨어진 경우에는 다음과 같이 합니다.
+ VMware vSphere 클라이언트를 사용하는 경우, 볼륨의 **호스트 IP** 주소가 **요약** 탭의 vSphere 클라이언트에 표시되는 주소 중 하나와 일치하는지 확인합니다. 스토리지 볼륨의 **호스트 IP** 주소는 Storage Gateway 콘솔의 볼륨 **세부 정보** 탭에서 찾을 수 있습니다. 예를 들어 게이트웨이에 새로운 고정 IP 주소를 할당하면 IP 주소 불일치가 발생할 수 있습니다. 불일치하는 경우, [게이트웨이 VM 종료](MaintenanceShutDown-common.md)에 표시된 대로 Storage Gateway 콘솔에서 게이트웨이를 다시 시작합니다. 다시 시작한 후에는 스토리지 볼륨의 **ISCSI 대상 정보** 탭에 있는 **호스트 IP** 주소가 게이트웨이의 **요약** 탭에 있는 vSphere 클라이언트에 표시된 IP 주소와 일치해야 합니다.
+ 볼륨에 대한 **호스트 IP** 상자에 IP 주소가 없고 게이트웨이가 온라인인 경우. 예를 들어 네트워크 어댑터가 두 개 이상인 게이트웨이에 있는 네트워크 어댑터 한 개의 IP 주소와 연결된 볼륨을 생성할 경우 이 오류가 발생할 수 있습니다. 볼륨이 연결된 네트워크 어댑터를 제거하거나 비활성화하면 **호스트 IP** 상자에 IP 주소가 표시되지 않을 수 있습니다. 이 문제를 해결하려면 볼륨을 삭제한 후 다시 생성하여 기존 데이터를 보존합니다.
+ 애플리케이션에서 사용하는 iSCSI 초기자가 스토리지 볼륨의 iSCSI 대상에 올바르게 매핑되어 있는지 확인합니다. 스토리지 볼륨 연결에 대한 자세한 내용은 [Windows 클라이언트에서 볼륨 연결](ConfiguringiSCSIClient.md) 단원을 참조하십시오.
Amazon CloudWatch 콘솔에서 볼륨에 대한 처리량을 보고 경보를 생성할 수 있습니다. 애플리케이션에서 볼륨까지 처리량 측정에 대한 자세한 내용은 [애플리케이션과 게이트웨이 간 성능 측정](PerfAppGateway-common.md) 단원을 참조하십시오.
## 게이트웨이의 캐시 디스크에 장애가 발생한 경우
게이트웨이에 있는 하나 이상의 캐시 디스크에 오류가 발생하는 경우, 게이트웨이가 가상 테이프 및 볼륨에 읽기 및 쓰기 작업이 수행되지 않도록 막습니다. 정상 기능을 재개하려면 다음과 같이 게이트웨이를 다시 구성하십시오.
+ 캐시 디스크를 액세스할 수 없거나 사용할 수 없으면, 게이트웨이 구성에서 디스크를 삭제합니다.
+ 캐시 디스크를 액세스할 수 없거나 사용할 수 없으면, 게이트웨이에 이를 다시 연결합니다.
**참고**
캐시 디스크를 삭제하면 게이트웨이가 정상 기능을 재개할 때 클린 데이터(즉, 캐시 디스크 및 Amazon S3에 있는 데이터가 동기화된 데이터)가 있는 테이프 또는 볼륨을 계속해서 사용할 수 있습니다. 예를 들어, 게이트웨이에 3개의 캐시 디스크가 있는데 이 중 2개를 삭제하면, 클린 상태인 테이프나 볼륨의 상태가 AVAILABLE이 됩니다. 다른 테이프나 볼륨의 상태는 IRRECOVERABLE이 됩니다.
임시 디스크를 게이트웨이의 캐시 디스크로 사용하거나 임시 디스크에 캐시 디스크를 탑재하는 경우, 게이트웨이를 닫으면 캐시 디스크를 잃게 됩니다. 캐시 디스크 및 Amazon S3가 동기화되지 않은 상태에서 게이트웨이를 닫으면 데이터가 손실됩니다. 따라서, 임시 드라이브나 디스크를 사용하지 않는 것이 좋습니다.
## 볼륨 스냅샷이 예상보다 오래 PENDING 상태에 있는 경우
볼륨 스냅샷이 예상보다 오래 PENDING 상태에 있는 경우에는 게이트웨이 VM이 예기치 않게 충돌했거나 볼륨의 상태가 PASSTHROUGH 또는 IRRECOVERABLE로 변경되었기 때문일 수 있습니다. 이 중 어떤 경우에도 스냅샷은 PENDING 상태를 유지하고 성공적으로 완료되지 않습니다. 이러한 경우 스냅샷은 삭제하는 것이 좋습니다. 자세한 내용은 [스토리지 볼륨의 스냅샷 삭제](DeletingASnapshot.md) 단원을 참조하십시오.
볼륨이 AVAILABLE 상태로 돌아가면 볼륨의 새 스냅샷을 생성합니다. 볼륨 상태에 대한 내용은 [볼륨 상태 및 전환 이해](StorageVolumeStatuses.md) 단원을 참조하십시오.
## 고가용성 상태 알림
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 로그 그룹에 문의하십시오.