비정상 상태인 Windows WorkSpace의 문제를 해결하려면 어떻게 해야 합니까?

5분 분량

Amazon WorkSpaces Windows WorkSpace의 상태가 비정상입니다.

간략한 설명

WorkSpaces는 정기적으로 각 WorkSpace에 상태 요청을 전송하여 WorkSpace의 상태를 확인합니다. WorkSpaces가 WorkSpace로부터 응답을 받지 못하면 WorkSpace의 상태가 비정상으로 변경됩니다.

다음과 같은 문제로 인해 상태가 비정상으로 변경될 수 있습니다.

WorkSpace의 CPU 사용률이 지속적으로 높습니다.
WorkSpaces에 응답하는 에이전트 또는 서비스가 실행 중이 아니거나 관리 인터페이스(ETH0)가 비활성화되어 있습니다.
Amazon DCV 또는 PCoIP 서비스가 실행되고 있지 않습니다.
바이러스 백신 소프트웨어가 WorkSpaces 구성 요소를 차단하고 있습니다.
WorkSpace의 애플리케이션 또는 그룹 정책이 WorkSpaces와 관리 인터페이스의 WorkSpace 간의 네트워크 연결을 차단하고 있습니다.
메타데이터 경로가 누락되었습니다.

해결 방법

참고: AWS Command Line Interface(AWS CLI) 명령을 실행할 때 오류가 발생하면 AWS CLI의 오류 해결을 참조하십시오. 또한 최신 AWS CLI 버전을 사용하고 있는지 확인하십시오.

CloudWatch 지표를 사용하여 WorkSpaces 검토

원인을 파악하는 데 도움이 되도록 Amazon CloudWatch에서 CPUUsage, MemoryUsage 및 Unhealthy WorkSpaces 지표를 검토합니다.

WorkSpace 재부팅

WorkSpace를 재부팅합니다. 재부팅해도 문제가 해결되지 않으면 원격 데스크톱 프로토콜(RDP)을 사용하여 WorkSpace에 연결합니다.

RDP를 사용하여 WorkSpace에 연결할 수 없는 경우 Amazon Elastic Compute Cloud(Amazon EC2) Windows 인스턴스의 RDP 연결 문제를 해결하려면 어떻게 해야 합니까?를 참조하십시오. 여전히 RDP를 사용하여 WorkSpace에 연결할 수 없는 경우 WorkSpace의 복원 또는 재구축 섹션을 참조하십시오.

reboot-workspaces AWS CLI 명령을 실행할 수도 있습니다.

CPU 사용률이 높은지 확인

Amazon EC2 인스턴스의 CPU 사용률이 높은지 확인하십시오.

관리 및 고객 인터페이스가 실행 중인지 확인

관리 및 고객 인터페이스 IP 주소를 식별하려면 다음 명령을 실행합니다.

ipconfig /all

관리 및 고객 인터페이스의 상태를 표시하려면 다음 명령을 실행합니다.

netsh interface show interface

인터페이스가 연결됨 상태가 아닌 경우 다음 명령을 실행하여 인터페이스를 활성화합니다.

netsh interface set interface "interface-name" enable

참고: interface-name을 인터페이스 이름으로 바꾸십시오.

WorkSpaces 서비스가 실행 중이고 응답하는지 확인

서비스 상태를 확인하려면 다음 단계를 완료하십시오.

RDP를 사용하여 WorkSpace에 연결합니다.
시작 메뉴를 선택한 다음, 서비스를 입력합니다.
서비스 탭을 선택합니다.
WorkSpace의 각 서비스 상태를 확인합니다.
PCoIP WorkSpace:
SkylightWorkSpacesConfigService
Windows용 PCoIP 표준 에이전트
DCV WorkSpace:
SkylightWorkSpacesConfigService
DC용 WSP 어댑터
DCV 서버
서비스가 실행 중 상태가 아닌 경우 컨텍스트 메뉴를 열고 서비스를 선택합니다.
참고: 서비스의 시작 유형이 자동으로 설정되어 있는지 확인하십시오.
시작을 선택합니다.

WorkSpaces 구성 확인

바이러스 백신이나 맬웨어 방지 소프트웨어와 같은 엔드포인트 보호 소프트웨어가 WorkSpaces 서비스 구성 요소를 허용하는지 확인합니다. PCoIP WorkSpaces에 대해 WorkSpaces 웹 액세스가 활성화된 경우 STXHD 호스팅 애플리케이션 서비스가 실행 중이고 시작 유형이 자동인지 확인합니다.

참고: WorkSpaces 웹 액세스를 사용하지 않는 경우 STXHD 에이전트를 비활성화하십시오.

또한 애플리케이션 또는 VPN이 관리 어댑터를 차단하고 있지 않은지 확인하십시오. 그런 다음, WorkSpace의 연결을 확인합니다.

Skylight 인증서가 인증서 저장소에 있는지 확인하려면 로컬 컴퓨터에서 certmgr.msc를 엽니다. 인증서는 Skylight 폴더에 있습니다.

그룹 정책이 관리 인터페이스 또는 필수 WorkSpaces 서비스의 통신을 차단하는지 확인하려면 다음 단계를 완료하십시오.

RDP를 사용하여 WorkSpace에 연결합니다.
명령 프롬프트를 시작한 후 다음 명령을 실행하여 policy.html 파일을 생성합니다.
```
gpresult /h policy.html
```
policy.html 문서를 연 다음, 네트워크 인터페이스 또는 WorkSpaces 서비스와의 통신을 차단하는 정책을 검색합니다.
차단 정책을 찾은 경우 WorkSpace 컴퓨터 객체를 Microsoft Active Directory에서 별도의 조직 단위(OU)로 이동합니다. 객체의 상속 차단 설정을 사용합니다. 상속 차단을 사용하는 방법에 대한 자세한 내용은 Microsoft 웹 사이트에서 그룹 정책 재정의 및 차단을 참조하십시오.
WorkSpace를 재부팅합니다.

방화벽 규칙 확인

방화벽이 관리 네트워크 인터페이스에 나열된 트래픽을 허용해야 합니다. 또한 운영 체제(OS) 방화벽이나 타사 방화벽에 필수 포트를 허용하는 규칙이 있는지 확인하십시오.

메타데이터 경로가 누락되었는지 확인

필요한 모든 메타데이터 경로가 WorkSpace에 있는지 확인하려면 다음 Windows PowerShell 명령을 실행합니다.

Get-NetRoute

메타데이터 경로가 누락된 경우 다음 스크립트를 실행하여 WorkSpace에 추가합니다.

$mgmtIp = (Get-ItemProperty "hklm:\software\Amazon\SkyLight\ConfigurationData").ManagementIp
$mgmtGW = (Get-WmiObject win32_networkAdapterConfiguration | where IPAddress -eq $mgmtIp |select DefaultIPGateway).DefaultIPGateway

if($mgmtGW){

route delete 169.254.169.123
route delete 169.254.169.249
route delete 169.254.169.250
route delete 169.254.169.251
route delete 169.254.169.252
route delete 169.254.169.253
route delete 169.254.169.254

route -P add 169.254.169.249 MASK 255.255.255.255 $mgmtGW METRIC 1000
route -P add 169.254.169.250 MASK 255.255.255.255 $mgmtGW METRIC 1000
route -P add 169.254.169.251 MASK 255.255.255.255 $mgmtGW METRIC 1000
route -P add 169.254.169.252 MASK 255.255.255.255 $mgmtGW METRIC 1000
route -P add 169.254.169.253 MASK 255.255.255.255 $mgmtGW METRIC 1000
route -P add 169.254.169.254 MASK 255.255.255.255 $mgmtGW METRIC 1000
route -P add 169.254.169.123 MASK 255.255.255.255 $mgmtGW METRIC 1000

}

누락된 메타데이터 경로를 추가한 후 WorkSpace를 재부팅합니다.

WorkSpace 복원 또는 재구축

RDP를 사용하여 WorkSpace에 연결할 수 없는 경우 WorkSpace를 복원하여 최신 스냅샷으로 롤백하십시오. WorkSpace가 여전히 비정상인 경우 WorkSpace를 재구축하십시오.

WorkSpace를 복원하거나 재구축하려면 AWS Systems Manager AWSSupport-RecoverWorkSpace 런북을 사용하는 것이 모범 사례입니다.

중요: WorkSpace를 복원하거나 재구축할 때 데이터 손실이 발생할 수 있습니다. 복원을 통해 최대 12시간이 지난 사용 가능한 마지막 스냅샷에서 WorkSpace가 복원됩니다. 재구축은 가장 최근 스냅샷에서 사용자 볼륨을 다시 생성하고, WorkSpace를 생성한 번들 이미지에서 WorkSpace를 다시 생성합니다. 설치한 애플리케이션이나 WorkSpace를 생성한 후 변경한 시스템 설정이 손실됩니다.

자동화를 실행하기 전에 AWS Identity and Access Management(IAM) 사용자 또는 역할에 필요한 권한이 있는지 확인하십시오. 자세한 내용은 AWSSupport-RecoverWorkSpace의 필수 IAM 권한 섹션을 참조하십시오.

런북을 사용하려면 다음 단계를 수행하십시오.

AWSSupport-RecoverWorkSpace 런북을 엽니다.
자동화 실행을 선택합니다.
입력 파라미터에 다음 값을 입력합니다.
(선택 사항) AutomationAssumeRole에 자동화에서 작업을 수행하도록 허용하는 IAM 역할의 Amazon 리소스 이름(ARN)을 입력합니다. 역할을 지정하지 않으면 자동화에서는 런북을 시작하는 사용자의 권한을 사용합니다.
확인에 예를 입력하여 복원 및 재구축 작업으로 가장 최근 스냅샷에서 WorkSpace가 복구됨을 확인합니다.
재부팅, 재구축 또는 복원에서 원하는 옵션에 예를 선택합니다.
WorkspaceId에 복구할 WorkSpace의 ID를 입력합니다.
실행을 선택합니다.
런북의 출력 섹션에서 WorkSpace 상태를 확인합니다.

restore-workspace 또는 rebuild-workspaces AWS CLI 명령을 실행할 수도 있습니다.

위의 문제 해결 단계로도 문제가 해결되지 않으면 클라이언트 측 로그를 수집하고 AWS Support 사례를 엽니다.