Azure VM에 대한 시스템 재부팅 이해

  • 아티클

Azure VM(가상 머신)은 재부팅 작업을 시작했다는 증거 없이 명백한 이유 없이 다시 부팅될 수 있습니다. 이 문서에서는 VM을 다시 부팅할 수 있는 작업 및 이벤트를 나열하고 예기치 않은 다시 부팅 문제를 방지하거나 이러한 문제의 영향을 줄이는 방법에 대한 인사이트를 제공합니다.

고가용성을 위해 VM 구성

VM 재부팅 및 가동 중지 시간으로부터 Azure에서 실행되는 애플리케이션을 보호하는 가장 좋은 방법은 고가용성을 위해 VM을 구성하는 것입니다.

애플리케이션에 이러한 수준의 중복성을 제공하려면 가용성 집합에서 두 개 이상의 VM을 그룹화하는 것이 좋습니다. 이 구성은 계획되거나 계획되지 않은 유지 관리 이벤트 중에 하나 이상의 VM을 사용할 수 있고 99.95%의 Azure SLA를 충족하도록 합니다.

가용성 집합에 대한 자세한 내용은 VM의 가용성 관리를 참조하세요.

Resource Health 정보

Azure Resource Health 개별 Azure 리소스의 상태를 노출하고 문제 해결을 위한 실행 가능한 지침을 제공하는 서비스입니다. 서버 또는 인프라 요소에 직접 액세스할 수 없는 클라우드 환경에서 Resource Health 목표는 문제 해결에 소요되는 시간을 줄이는 것입니다. 특히 문제의 근본 원인을 애플리케이션에 있는지 아니면 Azure 플랫폼 내의 이벤트에 있는지 확인하는 데 소요되는 시간을 줄이는 것이 목표입니다. 자세한 내용은 Resource Health 이해 및 사용을 참조하세요.

Azure에 가상 머신에 대한 플랫폼 시작 사용 불가의 근본 원인에 대한 추가 정보가 있는 경우 해당 정보는 초기 사용 불가 후 최대 72시간 후에 리소스 상태에 게시될 수 있습니다.

활동 로그에서 VM 가동 중지 시간 누락

Resource Health 경고는 활동 로그 정보에 따라 전송됩니다. 경우에 따라 VM 가동 중지 시간이 활동 로그에 표시되지 않을 수 있습니다. 가동 중지 시간이 활동 로그에 표시되지 않으면 가동 중지 시간에 대한 Resource Health 경고가 전송되지 않습니다. 가동 중지 시간은 여전히 Resource Health 표시됩니다.

다음은 활동 로그에 VM 가동 중지 시간이 표시되지 않는 경우입니다.

  • VM을 만들거나 새 호스트로 마이그레이션할 때 Azure 플랫폼은 VM 상태를 올바르게 표시하지 않으며 상태가 알 수 없음으로 변경됩니다. 모든 네트워크 연결 및 노드 프로세스가 설정된 후에만 VM 상태가 사용 가능으로 변경됩니다. 알 수 없는 상태의 장기간 활동 로그에서 필터링됩니다.
  • VM 가용성 상태가 사용 가능에서 사용할 수 없음으로 변경된 후 35초 이내에 사용 가능으로 돌아가면 가동 중지 시간이 활동 로그에 표시되지 않습니다. 이 경우 첫 번째 전환이 발생하기 15분 전에 상관 관계가 있는 가동 중지 시간이 전송되는 경우에는 발생하지 않습니다.
  • VM 상태가 상태에서 알 수 없음으로 변경된 다음 원래 상태로 돌아가면 일시적인 알 수 없음 상태 및 관련 전환이 활동 로그에서 필터링됩니다.

활동 로그에 표시되지 않는 VM 가동 중지 시간은 일시적인 오류가 고객에게 잘못된 가동 중지 시간을 표시하지 않도록 Azure 플랫폼 쪽에서 필터링됩니다. VM 상태 품질에 대한 지속적인 투자를 통해 필터가 더 이상 필요하지 않을 수 있으며 VM 상태의 빠른 변경이 보고되지 않은 상태로 남을 수 있습니다. Microsoft는 최상의 고객 환경을 제공하기 위해 단계적 계획을 수립하고 있습니다.

VM을 다시 부팅할 수 있는 작업 및 이벤트

계획된 유지 관리

Microsoft Azure는 VM의 기반이 되는 호스트 인프라의 안정성, 성능 및 보안을 개선하기 위해 전 세계에 주기적으로 업데이트를 수행합니다. 메모리 유지 업데이트를 포함하여 이러한 업데이트의 대부분은 VM 또는 클라우드 서비스에 영향을 주지 않고 수행됩니다.

그러나 일부 업데이트에는 다시 부팅이 필요합니다. 이러한 경우 인프라를 패치하는 동안 VM이 종료된 다음 VM이 다시 시작됩니다.

Azure 계획된 유지 관리의 내용과 Linux VM의 가용성에 미치는 영향을 이해하려면 여기에 나열된 문서를 참조하세요. 이 문서에서는 Azure 계획된 유지 관리 프로세스 및 계획된 유지 관리를 예약하여 영향을 더 줄이는 방법에 대한 배경을 제공합니다.

메모리 보존 업데이트

Microsoft Azure의 이 업데이트 클래스의 경우 사용자는 실행 중인 VM에 영향을 주지 않습니다. 이러한 업데이트의 대부분은 실행 중인 instance 방해하지 않고 업데이트할 수 있는 구성 요소 또는 서비스에 대한 것입니다. 일부는 VM을 다시 부팅하지 않고 적용할 수 있는 호스트 운영 체제의 플랫폼 인프라 업데이트입니다.

이러한 메모리 보존 업데이트는 현재 위치 실시간 마이그레이션을 가능하게 하는 기술로 수행됩니다. 업데이트되는 경우 VM은 일시 중지된 상태로 배치됩니다. 이 상태는 기본 호스트 운영 체제가 필요한 업데이트 및 패치를 수신하는 동안 RAM에서 메모리를 유지합니다. VM은 일반적으로 일시 중지된 후 30초 이내에 다시 시작됩니다. VM이 다시 시작된 후 시계가 자동으로 동기화됩니다.

일시 중지 기간이 짧기 때문에 이 메커니즘을 통해 업데이트를 배포하면 VM에 미치는 영향이 크게 줄어듭니다. 그러나 모든 업데이트를 이러한 방식으로 배포할 수 있는 것은 아닙니다.

다중 instance 업데이트(가용성 집합의 VM용)는 한 번에 하나의 업데이트 도메인에 적용됩니다.

참고

이전 커널 버전이 있는 Linux 컴퓨터는 이 업데이트 방법 중에 커널 패닉의 영향을 받습니다. 이 문제를 방지하려면 커널 버전 3.10.0-327.10.1 이상으로 업데이트합니다. 자세한 내용은 호스트 노드 업그레이드 후 3.10 기반 커널 패닉의 Azure Linux VM을 참조하세요.

사용자가 시작한 다시 부팅 또는 종료 작업

Azure Portal, Azure PowerShell, 명령줄 인터페이스 또는 REST API에서 다시 부팅을 수행하는 경우 Azure 활동 로그에서 이벤트를 찾을 수 있습니다.

VM의 운영 체제에서 작업을 수행하는 경우 시스템 로그에서 이벤트를 찾을 수 있습니다.

일반적으로 VM을 다시 부팅하는 다른 시나리오에는 여러 구성 변경 작업이 포함됩니다. 일반적으로 특정 작업을 실행하면 VM이 다시 부팅된다는 경고 메시지가 표시됩니다. 예를 들어 VM 크기 조정 작업, 관리 계정의 암호 변경 및 고정 IP 주소 설정이 있습니다.

클라우드 및 Windows 업데이트 대한 Microsoft Defender

클라우드용 Microsoft Defender 운영 체제 업데이트가 누락된 경우 매일 Windows 및 Linux VM을 모니터링합니다. 클라우드용 Defender는 Windows VM에 구성된 서비스에 따라 WSUS(Windows 업데이트 또는 Windows Server Update Services)에서 사용 가능한 보안 및 중요 업데이트 목록을 검색합니다. 클라우드용 Defender는 Linux 시스템의 최신 업데이트도 확인합니다. VM에 시스템 업데이트가 누락된 경우 클라우드용 Defender에서 시스템 업데이트를 적용하는 것이 좋습니다. 이러한 시스템 업데이트의 애플리케이션은 Azure Portal 클라우드용 Defender를 통해 제어됩니다. 일부 업데이트를 적용한 후에는 VM 재부팅이 필요할 수 있습니다. 자세한 내용은 클라우드용 Microsoft Defender 시스템 업데이트 적용을 참조하세요.

온-프레미스 서버와 마찬가지로 이러한 컴퓨터는 사용자가 관리하기 위한 것이므로 Azure는 업데이트를 Windows 업데이트 Windows VM으로 푸시하지 않습니다. 그러나 자동 Windows 업데이트 설정을 사용하도록 설정하는 것이 좋습니다. Windows 업데이트 업데이트를 자동으로 설치하면 업데이트가 적용된 후 다시 부팅이 발생할 수도 있습니다. 자세한 내용은 Windows 업데이트 FAQ를 참조하세요.

VM의 가용성에 영향을 주는 기타 상황

Azure에서 VM 사용을 적극적으로 일시 중단할 수 있는 다른 경우도 있습니다. 이 작업이 수행되기 전에 메일 알림 받게 되므로 기본 문제를 resolve 수 있습니다. VM 가용성에 영향을 주는 문제의 예로는 보안 위반 및 결제 방법 만료가 있습니다.

호스트 서버 오류

VM은 Azure 데이터 센터 내에서 실행되는 물리적 서버에서 호스트됩니다. 물리적 서버는 몇 가지 다른 Azure 구성 요소 외에도 호스트 에이전트라는 에이전트를 실행합니다. 물리적 서버의 이러한 Azure 소프트웨어 구성 요소가 응답하지 않는 경우 모니터링 시스템은 호스트 서버의 재부팅을 트리거하여 복구를 시도합니다. 대부분의 경우 VM은 10-15분 내에 다시 사용할 수 있으며 이전과 동일한 호스트에서 계속 사용할 수 있습니다.

서버 오류는 일반적으로 하드 디스크 또는 반도체 드라이브의 오류와 같은 하드웨어 오류로 인해 발생합니다. Azure는 이러한 발생을 지속적으로 모니터링하고, 기본 버그를 식별하고, 완화를 구현하고 테스트한 후 업데이트를 롤아웃합니다.

일부 호스트 서버 오류는 해당 서버와 관련이 있을 수 있으므로 VM을 다른 호스트 서버에 수동으로 다시 배포하여 반복되는 VM 다시 부팅 상황이 개선될 수 있습니다. 이 작업은 VM의 세부 정보 페이지에서 다시 배포 옵션을 사용하거나 Azure Portal VM을 중지하고 다시 시작하여 트리거할 수 있습니다.

자동 복구

어떤 이유로든 호스트 서버를 다시 부팅할 수 없는 경우 Azure 플랫폼은 추가 조사를 위해 잘못된 호스트 서버를 순환에서 제외하는 자동 복구 작업을 시작합니다.

해당 호스트의 모든 VM은 다른 정상 호스트 서버로 자동으로 재배치됩니다. 이 프로세스는 일반적으로 15분 이내에 완료되지만, 복구에 필요한 시간은 호스트 메모리의 크기 및 사용된 복구 방법을 비롯한 여러 요인에 따라 달라질 수 있습니다. 자동 복구 프로세스에 대한 자세한 내용은 VM 자동 복구를 참조하세요.

계획되지 않은 유지 관리

드문 경우지만 Azure 운영 팀은 Azure 플랫폼의 전반적인 상태를 보장하기 위해 유지 관리 작업을 수행해야 할 수 있습니다. 이 동작은 VM 가용성에 영향을 줄 수 있으며 일반적으로 앞에서 설명한 것과 동일한 자동 복구 작업을 수행합니다.

계획되지 않은 유지 관리에는 다음이 포함됩니다.

  • 긴급 노드 조각 모음
  • 긴급 네트워크 스위치 업데이트

VM 크래시

VM 자체 내의 문제로 인해 VM이 다시 시작될 수 있습니다. VM에서 실행되는 워크로드 또는 역할은 게스트 운영 체제 내에서 버그 검사 트리거할 수 있습니다. 충돌 원인을 확인하는 데 도움이 되도록 Windows VM의 시스템 및 애플리케이션 로그와 Linux VM에 대한 직렬 로그를 확인하세요.

Azure의 VM은 Azure Storage 인프라에서 호스트되는 운영 체제 및 데이터 스토리지에 가상 디스크를 사용합니다. VM과 연결된 가상 디스크 간의 가용성 또는 연결이 120초 이상 영향을 받을 때마다 Azure 플랫폼은 데이터 손상을 방지하기 위해 VM의 강제 종료를 수행합니다. 스토리지 연결이 복원된 후 VM은 자동으로 다시 전원이 켜집니다. 종료 기간은 5분 정도 짧을 수 있지만 훨씬 더 길어질 수 있습니다.

기타 인시던트

드문 경우지만 광범위한 문제는 Azure 데이터 센터의 여러 서버에 영향을 줄 수 있습니다. 이 문제가 발생하면 Azure 팀은 영향을 받는 구독에 메일 알림 보냅니다. 지속적인 중단 및 과거 인시던트 상태 대한 Azure Service Health dashboard 및 Azure Portal 검사 수 있습니다.

VM 다시 시작 진단

VM 블레이드에서 진단 및 해결 블레이드를 사용하여 추가 진단 실행할 수 있습니다. 이렇게 하면 최근 VM을 다시 시작하는 보다 구체적인 이유가 발견할 수 있습니다. 게스트 OS 문제가 있는 경우 메모리 덤프를 수집하고 지원에 문의하세요.

도움을 요청하십시오.

질문이 있거나 도움이 필요한 경우 지원 요청을 생성하거나Azure 커뮤니티 지원에 문의하세요. Azure 피드백 커뮤니티에 제품 피드백을 제출할 수도 있습니다.