기계 고장 대처
이 섹션에서는 다양한 오류 시나리오에서 복구하는 방법을 자세히 설명합니다. 모든 오류 복구 시나리오에서는 백업에 나열된 백업 유형 중 하나 이상을 사용해야 합니다.
회원 실패
HA가 없는 경우 풀 코디네이터 노드는 정기적인 하트비트 메시지를 수신하여 구성원의 오류를 감지합니다. 600초 동안 하트비트가 수신되지 않은 경우 풀 코디네이터는 구성원이 비활성인 것으로 간주합니다. 이 문제를 복구하는 방법에는 두 가지가 있습니다.
-
고장난 호스트를 복구합니다 (예: 물리적으로 재부팅). 구성원에 대한 연결이 복원되면 풀 코디네이터가 구성원을 다시 활성 상태로 표시합니다.
-
호스트를 종료하고 풀 코디네이터에게
xe host-forgetCLI 명령을 사용하여 멤버 노드를 삭제하도록 지시합니다. 구성원이 잊혀지면 여기에서 실행 중이었던 모든 VM이 오프라인으로 표시되고 다른 XenServer 호스트에서 다시 시작할 수 있습니다.XenServer 호스트가 실제로 오프라인 상태인지 확인하는 것이 중요합니다. 그렇지 않으면 VM 데이터가 손상될 수 있습니다.
xe host-forget를 사용하여 풀을 단일 호스트의 여러 풀로 분할하지 마십시오. 이 작업을 수행하면 동일한 공유 스토리지를 모두 매핑하고 VM 데이터가 손상될 수 있습니다.
경고:
- 잊어버린 호스트를 활성 호스트로 다시 사용하려면 XenServer 소프트웨어를 새로 설치합니다.
- 풀에서 HA가 활성화된 경우
xe host-forget명령을 사용하지 마십시오. 먼저 HA를 사용하지 않도록 설정한 다음 호스트를 삭제한 다음 HA를 다시 사용하도록 설정합니다.
구성원 XenServer 호스트가 실패해도 실행 상태로 등록된 VM이 있을 수 있습니다. 구성원 XenServer 호스트가 확실히 다운된 경우 xe vm-reset-powerstate CLI 명령을 사용하여 VM의 전원 상태를 halted로 설정합니다. 자세한 내용은 vm-reset-powerstate를 참조하십시오.
경고:
이 명령을 올바르지 않게 사용하면 데이터 손상이 발생할 수 있습니다. 필요한 경우에만 이 명령을 사용합니다.
다른 XenServer 호스트에서 VM을 시작하려면 먼저 VM 스토리지에 대한 잠금을 해제해야 합니다. 한 번에 호스트에서만 SR의 각 디스크를 사용할 수 있습니다. 호스트에 장애가 발생한 경우 다른 XenServer 호스트에서 디스크에 액세스할 수 있도록 하는 것이 중요합니다. 이렇게 하려면 영향을 받는 VM의 디스크가 포함된 각 SR에 대해 풀 코디네이터에서 다음 스크립트를 실행합니다. /opt/xensource/sm/resetvdis.py host_UUID SR_UUID master
장애 발생 시 장애가 발생한 호스트가 SR 풀 코디네이터였던 경우 세 번째 문자열(“마스터”)만 제공하면 됩니다. (SR 풀 코디네이터는 풀 코디네이터이거나 로컬 스토리지를 사용하는 XenServer 호스트입니다.)
경고:
이 명령을 실행하기 전에 호스트가 다운되었는지 확인하십시오. 이 명령을 올바르지 않게 사용하면 데이터 손상이 발생할 수 있습니다.
resetvdis.py 스크립트를 실행하기 전에 다른 XenServer 호스트에서 VM을 시작하려고 하면 다음과 같은 오류 메시지가 나타납니다. VDI <UUID> already attached RW
풀 코디네이터 실패
리소스 풀의 모든 구성원은 필요한 경우 풀 코디네이터 역할을 인수하는 데 필요한 모든 정보를 포함합니다. 풀 코디네이터 노드에 장애가 발생하면 다음과 같은 일련의 이벤트가 발생합니다.
-
HA가 활성화되면 다른 풀 코디네이터가 자동으로 선택됩니다.
-
HA가 활성화되지 않은 경우 각 구성원은 풀 코디네이터가 돌아올 때까지 기다립니다.
풀 코디네이터가 이 시점에서 다시 돌아오면 구성원과의 통신을 다시 설정하고 작업이 정상으로 돌아갑니다.
풀 코디네이터가 비활성 상태인 경우 구성원 중 하나를 선택하고 해당 구성원에 대해 xe pool-emergency-transition-to-master 명령을 실행합니다. 풀 코디네이터가 되고 나서 xe pool-recover-slaves 명령을 실행하면 구성원이 새 풀 코디네이터를 가리킵니다.
원래 풀 코디네이터였던 호스트를 복구하거나 교체하는 경우 해당 서버를 불러와서 XenServer 소프트웨어를 설치한 다음 풀에 추가하기만 하면 됩니다. 풀의 XenServer 호스트는 동종적으로 적용되므로 교체된 호스트를 풀 코디네이터로 만들 필요가 없습니다.
구성원 XenServer 호스트가 풀 코디네이터로 전환되면 기본 풀 저장소 리포지토리가 적절한 값으로 설정되어 있는지 확인합니다. 이 검사는 xe pool-param-list 명령을 사용하여 default-SR 매개 변수가 유효한 스토리지 저장소를 가리키는지 확인할 수 있습니다.
풀 실패
전체 리소스 풀이 실패하는 불행한 경우 풀 데이터베이스를 처음부터 다시 만들어야 합니다. xe pool-dump-database CLI 명령을 사용하여 풀 메타데이터를 정기적으로 백업해야 합니다(pool-dump-database 참조).
완전히 실패한 풀을 복원하려면 다음과 같이 하십시오.
-
새로운 호스트 집합을 설치합니다. 이 단계에서는 풀을 구성하지 마십시오.
-
풀 코디네이터로 지정된 호스트의 경우
xe pool-restore-database명령을 사용하여 백업에서 풀 데이터베이스를 복원합니다 ( pool-restore-database참조). -
XenCenter를 사용하여 풀 코디네이터에 연결하고 모든 공유 스토리지 및 VM을 다시 사용할 수 있는지 확인합니다.
-
새로 설치된 나머지 구성원 호스트에서 풀 참가 작업을 수행하고 적절한 호스트에서 VM을 시작합니다.
구성 오류로 인한 장애 대처
물리적 호스트 컴퓨터가 작동하지만 소프트웨어 또는 호스트 구성이 손상된 경우:
-
다음 명령을 실행하여 호스트 소프트웨어 및 구성을 복원합니다.
xe host-restore host=host file-name=hostbackup <!--NeedCopy--> -
호스트 설치 CD로 재부팅하고 Restore from backup(백업에서 복원)을 선택합니다.
물리적 시스템 장애
물리적 호스트 시스템이 실패한 경우 다음 목록의 적절한 절차를 사용하여 복구합니다.
경고:
실패한 이전 구성원(또는 이전 호스트)에서 실행 중인 모든 VM은 여전히 데이터베이스에서
Running로 표시됩니다. 이 동작은 안전을 위한 것입니다. 서로 다른 두 호스트에서 동시에 VM을 시작하면 심각한 디스크 손상이 발생할 수 있습니다. 시스템 (및 VM) 이 오프라인 상태인 경우 VM 전원 상태를Halted:
xe vm-reset-powerstate vm=vm_uuid --force로 재설정할 수 있습니다. 그러면 Citrix Hypervisor 센터 또는 CLI를 사용하여 VM을 다시 시작할 수 있습니다.
실패한 풀 코디네이터를 아직 실행 중인 구성원으로 바꾸려면 다음과 같이 하십시오.
-
다음 명령을 실행합니다.
xe pool-emergency-transition-to-master xe pool-recover-slaves <!--NeedCopy--> -
명령이 성공하면 VM을 다시 시작합니다.
모든 호스트가 있는 풀을 복원하지 못했습니다.
-
다음 명령을 실행합니다.
xe pool-restore-database file-name=backup <!--NeedCopy-->경고:
이 명령은 대상 시스템에 적절한 수의 NIC가 있는 경우에만 성공합니다.
-
대상 시스템의 스토리지 뷰가 원래 머신과 다른 경우
pbd-destroy명령을 사용하여 스토리지 구성을 수정합니다. 그런 다음pbd-create명령을 사용하여 스토리지 구성을 다시 만듭니다. 이러한 명령에 대한 설명서는 pbd 명령을 참조하십시오. -
스토리지 구성을 만든 경우 Citrix Hypervisor 센터에서
pbd-plug또는 저장소 > 스토리지 저장소 복구 메뉴 항목으로 새 구성을 사용합니다. -
모든 VM을 다시 시작합니다.
VM 스토리지를 사용할 수 없을 때 VM을 복원하려면 다음과 같이 하십시오.
-
다음 명령을 실행합니다.
xe vm-import filename=backup metadata=true <!--NeedCopy--> -
메타데이터 가져오기에 실패하면 다음 명령을 실행합니다.
xe vm-import filename=backup metadata=true --force <!--NeedCopy-->이 명령은 ‘최선의 노력’ 기준으로 VM 메타데이터를 복원하려고 시도합니다.
-
모든 VM을 다시 시작합니다.