Azure VM에 대한 시스템 다시 부팅 이해
적용 대상: ✔️ Linux VM ✔️ Windows 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에서 계속 표시됩니다.
다음은 활동 로그에 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에는 아무런 영향도 주지 않습니다. 이러한 많은 업데이트는 실행 중인 인스턴스를 방해하지 않고 업데이트할 수 있는 구성 요소 또는 서비스에 대한 업데이트입니다. 일부는 VM을 재부팅하지 않고 적용할 수 있는 호스트 운영 체제의 플랫폼 인프라 업데이트입니다.
이러한 메모리 유지 업데이트는 현재 위치 실시간 마이그레이션을 가능하게 하는 기술로 수행됩니다. 업데이트할 때 VM은 일시 중지된 상태로 배치됩니다 . 이 상태는 기본 호스트 운영 체제가 필요한 업데이트 및 패치를 수신하는 동안 RAM에서 메모리를 유지합니다. VM은 일반적으로 일시 중지된 후 30초 이내에 다시 시작됩니다. VM이 다시 시작된 후 시계는 자동으로 동기화됩니다.
짧은 일시 중지 기간 때문에 이 메커니즘을 통해 업데이트를 배포하면 VM에 미치는 영향이 크게 줄어듭니다. 그러나 모든 업데이트를 이러한 방식으로 배포할 수는 없습니다.
다중 인스턴스 업데이트(가용성 집합의 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 주소 설정 등을 예로 들 수 있습니다.
클라우드용 Microsoft Defender 및 Windows 업데이트
클라우드용 Microsoft Defender 매일 Windows 및 Linux VM에서 운영 체제 업데이트 누락을 모니터링합니다. 클라우드용 Defender Windows VM에 구성된 서비스에 따라 Windows 업데이트 또는 WSUS(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 사용을 적극적으로 일시 중단할 수 있는 다른 경우가 있습니다. 이 작업이 수행되기 전에 메일 알림 받게 되므로 기본 문제를 해결할 수 있습니다. 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 대시보드 및 Azure Portal에서 진행 중인 중단 및 과거 인시던트 상태를 확인할 수 있습니다.
VM 다시 시작 진단
VM 블레이드에서 진단 및 해결 블레이드를 사용하여 추가 진단을 실행할 수 있습니다. 이로 인해 최근 VM을 다시 시작하는 더 구체적인 이유가 발견 될 수 있습니다. 게스트 OS 문제가 있는 경우 메모리 덤프를 수집하고 지원에 문의하세요.
도움을 요청하십시오.
질문이 있거나 도움이 필요한 경우 지원 요청을 생성하거나Azure 커뮤니티 지원에 문의하세요. Azure 피드백 커뮤니티에 제품 피드백을 제출할 수도 있습니다.