Azure VM 운영 체제 업그레이드로 인한 역할 인스턴스 다시 시작

아티클
11/19/2024

이 문서에서는 역할 인스턴스를 다시 시작할 때 Microsoft Azure VM(가상 머신) OS(운영 체제) 업그레이드가 미치는 영향에 대해 설명합니다. 여기에는 OS 및 게스트 에이전트 업그레이드 일정, 서비스 영향 및 요구 사항, 알림, 검색 및 일반적인 문제를 해결하는 방법에 대한 세부 정보가 포함되어 있습니다.

일정 업그레이드

Microsoft는 약 매월 Azure PaaS(Platform as a Service) VM에 대한 새 게스트 OS 버전을 릴리스합니다. 정확한 일정은 다양하며 Azure 게스트 OS 릴리스 및 SDK 호환성 매트릭스에서 기록 추세를 확인할 수 있습니다. 이 롤아웃 중에 Azure Fabric Controller 는 모든 데이터 센터를 통해 두 번의 패스(호스트 OS 패스 및 게스트 OS 패스)를 수행합니다. Azure 게스트 에이전트의 정기 업데이트도 VM 내에서 실행됩니다.

다음 섹션에서는 두 업그레이드 패스 및 게스트 에이전트 업그레이드에 대한 자세한 내용을 제공합니다.

패스 1: 호스트 OS

첫 번째 패스는 호스트 OS를 업그레이드합니다. 호스트 OS는 역할 인스턴스를 다시 시작하고 패브릭 컨트롤러는 한 번에 하나의 업그레이드 도메인의 인스턴스만 다시 시작되도록 합니다. 이 다시 시작하는 동안 역할 인스턴스는 표준 종료 프로세스를 거닐게 됩니다. 그런 다음 이벤트를 RoleEnvironment.OnStop 실행하여 인스턴스를 정상적으로 종료할 수 있습니다.

호스트 OS 업데이트는 패브릭이 데이터 센터 내의 모든 다른 호스팅 서비스 및 업그레이드 도메인에서 업그레이드를 조정하는 데 며칠이 걸릴 수 있습니다. 일반적으로 배포의 여러 인스턴스가 몇 시간 간격으로 업데이트됩니다.

호스트 OS 업그레이드 프로세스에 대한 자세한 내용은 Azure 호스트 업데이트: Azure 블로그 문서의 이유, 시기 및 방법을 참조하세요.

패스 2: 게스트 OS

호스트 OS가 데이터 센터에서 업그레이드를 완료하면 자동 게스트 OS 버전을 사용하도록 구성된 서비스에 대해 게스트 OS가 업그레이드됩니다. 이 업그레이드는 서비스에 대한 표준 업그레이드 도메인 규칙을 사용하여 계속됩니다. VM이 다시 시작되고 업그레이드된 OS를 사용하여 Windows 파티션(D 드라이브)이 이미지로 다시 설치됩니다.

게스트 OS 업데이트 프로세스는 호스트 OS 업데이트보다 훨씬 빠릅니다. 패브릭이 호스트된 서비스 및 업그레이드 도메인 내에서만 업데이트를 조정해야 하기 때문입니다. 서비스에 대한 게스트 OS 업데이트 프로세스의 기간은 주로 다음 요인에 따라 달라집니다.

역할 인스턴스 수
업그레이드 도메인 수
서비스를 종료하는 데 걸리는 시간(Stopping 및 OnStop 이벤트)
서비스를 시작하는 데 걸리는 시간(시작 작업 및 OnStart 이벤트)

게스트 에이전트

Azure 게스트 에이전트는 약 매월 업데이트됩니다. 게스트 에이전트가 업데이트되면 다음 작업이 수행됩니다.

역할을 실행하는 호스트 프로세스(일반적으로 WaWorkerHost 또는 WaWebHost)는 정상적으로 종료됩니다.
게스트 에이전트가 자체 업데이트합니다.
호스트 프로세스가 다시 시작됩니다.

게스트 에이전트 프로세스 및 서비스와 상호 작용하는 방법에 대한 자세한 내용은 Windows Azure 클래식 VM 아키텍처의 워크플로를 참조하세요.

서비스 영향 및 요구 사항

다음 목록에서는 클라우드 서비스에 미치는 영향 및 요구 사항에 대해 설명합니다.

역할에 인스턴스가 하나만 있는 경우 서비스에서 가동 중지 시간이 발생할 수 있습니다. SLA(서비스 수준 계약)에는 99.95%의 가동 시간이 필요하기 때문에 각 역할의 인스턴스가 두 개 이상 있어야 합니다.
호스트 OS 업데이트에 대한 역할 인스턴스가 매월 약 한 번 다시 시작될 것으로 예상합니다. 자동 게스트 OS 업데이트가 있는 경우 인스턴스가 다시 시작될 것으로 예상합니다. 일반적으로 다시 시작은 몇 시간 간격입니다. 그러나 이 시간 프레임은 데이터 센터 내에 있는 다양한 서비스의 구성에 따라 변경됩니다.
역할은 호스트 OS 업데이트를 제어하는 규칙을 준수해야 합니다. 특히 역할 인스턴스는 시작 작업을 시작한 후 30분 이내에 상태에 도달 Ready 해야 합니다. 이 제한 사항에 대한 자세한 내용은 업그레이드 진행 방법을 참조 하세요.
호스트 OS 업그레이드로 인해 역할 인스턴스가 다시 시작되고 게스트 OS 업그레이드로 인해 인스턴스가 이미지로 다시 설치됩니다. 이러한 이벤트로 인해 역할 인스턴스는 다음 절차를 처리할 수 있어야 합니다.
- 다시 시작
- 이미지로 다시 설치
- 재생

알림

현재 Azure 플랫폼은 OS 업그레이드가 발생할 때 사전 알림을 제공하지 않습니다. 역할 인스턴스는 종료되기 전에 이벤트를 받게 RoleEnvironment.Stopping 됩니다. 해당 이벤트를 사용하여 역할 인스턴스가 수행하는 모든 작업을 정상적으로 종료하거나 인스턴스가 종료되고 있음을 관리자에게 알릴 수 있습니다.

Azure OS 업데이트 RSS 피드를 구독할 수 있습니다. 이 피드는 OS 업데이트가 데이터 센터에 롤아웃되기 시작하는 날에 업데이트되어야 합니다. 피드는 일반적으로 고급 사전 알림을 제공하지 않지만 업데이트가 발생하는 시기를 식별하는 데 도움이 됩니다. 업데이트 프로세스를 완료하는 데 며칠이 걸릴 수 있습니다. 따라서 RSS 피드가 업데이트되고 호스트된 서비스가 업데이트되기 시작하는 시점까지 1일 이상 기다려야 할 수 있습니다.

Azure 게스트 OS 릴리스 목록과 Azure Portal에서 선택할 수 있는 OS 버전 목록은 일반적으로 게스트 OS 롤아웃이 완료된 후 업데이트됩니다. OS 업데이트가 진행 중인 시기를 나타내는 것으로 이러한 목록의 최신 항목을 사용하면 안 됩니다.

감지

현재 호스트 OS 업그레이드를 직접 검색할 수 있는 방법은 없습니다. 그러나 VM의 로그 내에서 다시 시작의 증거를 볼 수 있습니다. 그러기 위해 다음 중 하나를 수행합니다.

이벤트 뷰어 앱에서 시스템 이벤트 로그에서 이벤트 원본 USER32, 이벤트 ID 1074를 검색합니다. 이 이벤트에는 다음 메시지가 포함됩니다.

프로세스 D:\Packages\GuestAgent\WaAppAgent.exe (RD00155D50206D)는 다음과 같은 이유로 사용자 NT AUTHORITY\SYSTEM 을 대신하여 컴퓨터 RD00155D50206D 종료를 시작했습니다. 레거시 API 종료

이 메시지는 Azure 패브릭 게스트 에이전트(WaAppAgent.exe)가 VM의 종료를 시작했음을 나타냅니다.
텍스트 편집기에서 이전 앱 에이전트 런타임 로그 파일(AppAgentRuntime.log.old) _Context_Start 에서 Context 동일한 메시지를 검색합니다 StopContainer(). 앱 에이전트 런타임 로그에서 컨텍스트 항목을 검사하는 방법에 대한 자세한 내용은 Azure 블로그 보관 파일에서 일정 시간 동안 실행한 후 문제 해결 시나리오 6 – 역할 재활용을 참조하세요.

일반적인 문제 및 솔루션

다음 섹션에서는 역할 인스턴스 다시 시작과 관련된 몇 가지 일반적인 문제와 이를 해결하는 방법에 대해 설명합니다. 실행 중인 프로세스 및 문제 해결에 사용할 수 있는 로그 파일의 위치에 대한 자세한 내용은 Windows Azure 클래식 VM 아키텍처의 워크플로를 참조 하세요.

문제 1: 호스트 OS를 다시 시작한 후 시작 태스크 또는 코드가 두 번째로 실행되지 않습니다.

호스트 OS를 다시 시작한 후 시작 작업 또는 함수 Run 의 OnStart 코드가 두 번째로 실패할 수 있습니다. 다시 시작은 다시 실행하기 위해 시작 작업을 호출해야 합니다. 이 오류는 역할 인스턴스가 상태에 도달하지 못하게 합니다 Ready .

시작 작업에서 작업을 수행한 다음 두 번째로 실행한 후 오류를 반환하는 명령을 실행하면 어떻게 되나요? 이 경우 시작 작업이 실패하고 역할 인스턴스가 재활용을 시작합니다. 예를 들어 APPCMD 집합 구성 명령을 사용하여 인터넷 정보 서비스(IIS)에서 구성 섹션을 추가하는 경우 두 번째 실행 시 명령이 실패합니다. 이 명령은 오류 메시지를 생성합니다. "새 추가 개체에 필수 특성이 없습니다. 형식의 중복 컬렉션 항목을 추가할 수 없습니다..." 그런 다음 역할 인스턴스가 재활용을 시작합니다.

해결 방법 1: VM에 연결하고 원격으로 시작 또는 코드 오류 디버그

이러한 종류의 오류를 해결하려면 RDP(원격 데스크톱 프로토콜)를 사용하여 VM에 원격으로 연결합니다. 이벤트 로그에서 오류를 검사하고 WaHostBootstrapper.log 파일에서 시작 작업 실패를 확인합니다. 일반적인 개발 및 테스트 프로세스 중에는 Azure Portal에서 역할 인스턴스의 다시 시작을 사전에 시작해야 합니다. 이 단계는 서비스를 테스트하여 이 시나리오에서 제대로 작동하는지 확인하는 데 도움이 됩니다.

시작 작업 실패에 대한 일반적인 수정 사항은 시작 작업 스크립트의 끝에 명령을 추가하는 exit /b 0 것입니다. 이 종료 명령은 성공을 나타내는 종료 코드를 사용하여 스크립트를 종료합니다. 이 명령이 필요한 이유에 대한 자세한 내용은 Azure Cloud Service(클래식)에 대한 시작 작업을 구성하고 실행하는 방법을 참조하세요.

문제 2: Windows 파티션을 이미지로 다시 설치한 후 시작 작업 또는 코드가 실행되지 않음

Windows 파티션(D 드라이브)은 일반적으로 프로그램 설치 및 레지스트리 변경 내용이 저장되는 위치입니다. 업데이트의 게스트 OS 부분에서 Windows 파티션이 이미지로 다시 설치됩니다. 이로 인해 이러한 설치 및 변경 내용이 손실될 수 있습니다. Windows 파티션을 이미지로 다시 설치한 후에도 특정 레지스트리 변경 내용이 여전히 존재한다고 잘못 가정하는 시작 코드의 경우 역할 인스턴스가 제대로 작동하지 않을 수 있습니다. 이 오류는 역할 인스턴스가 상태에 도달하지 못하게 합니다 Ready .

예를 들어 시작 작업에서 레지스트리를 변경할 수 있습니다. 그런 다음, C 또는 E 드라이브에 해당 변경 내용의 레코드를 저장하여 레지스트리 변경 내용이 두 번째로 실행되지 않도록 합니다. 그러나 다시 이미지로 인해 D 드라이브의 레지스트리 변경 내용이 손실되고, 작업이 필요하다고 생각하지 않으므로 시작 작업이 해당 레지스트리 변경을 복원하지 않습니다. 레지스트리 변경이 누락되면 결국 나머지 시작 작업이 실패할 수 있습니다.

솔루션 2: Azure Portal에서 역할 인스턴스의 이미지 다시 설치 테스트

일반적인 개발 및 테스트 프로세스 중에 Azure Portal에서 역할 인스턴스의 이미지 다시 설치를 사전에 시작해야 합니다. 이 단계는 서비스를 테스트하고 이 시나리오에서 제대로 작동하는지 확인하는 데 도움이 됩니다.

문제 3: 시작 코드를 완료하는 데 30분 이상 걸립니다.

시작 코드를 완료하는 데 30분 이상이 걸리는 경우 동시에 서비스가 중단된 둘 이상의 역할 인스턴스가 있을 수 있습니다. 이 시나리오는 시작 태스크가 다음 작업 중 하나를 수행할 때 가장 일반적으로 발생합니다.

프로그램 또는 기능을 설치합니다.
캐시 데이터 다운로드
웹 사이트 정보 다운로드

솔루션 3: 서비스 영향 및 요구 사항 검토

서비스 영향 및 요구 사항 섹션을 검토하여 예상할 사항과 시작 지연을 방지하거나 완화할 수 있는 방법을 확인합니다.

문제 4: Azure는 업데이트 후 호스트 또는 게스트 OS를 다시 시작하지 않습니다.

드문 경우지만 Azure는 업데이트 후 호스트 또는 게스트 OS를 다시 시작하지 않을 수 있습니다. 이 시나리오에서는 포털에 30분 이상 후에 변경되지 않는 "호스트 대기 중" 메시지가 표시될 수 있습니다.

솔루션 4a: 시작 코드 수정

RDP(원격 데스크톱 프로토콜)를 사용하여 역할 인스턴스에 연결할 수 있는 경우 시작 코드에서 해결할 수 있는 오류가 있을 수 있습니다. 시작 코드를 수정하는 방법에 대한 자세한 내용은 솔루션 1: VM에 연결하고 원격으로 시작 또는 코드 오류를 디버그합니다.

솔루션 4b: 배포 삭제

RDP를 사용하여 역할 인스턴스에 연결할 수 없는 경우 인스턴스를 복구하는 유일한 방법은 배포를 삭제하는 것입니다.

문제 5: OS 업그레이드 중에 하나 이상의 역할 인스턴스를 사용할 수 없음

OS 업그레이드 중에 역할 인스턴스를 사용할 수 없는 경우 서비스 용량이 감소할 수 있습니다. 예를 들어 웹 역할의 인스턴스가 두 개 있고 두 인스턴스가 모두 일반적으로 75%의 CPU 사용량으로 실행한다고 가정해 보겠습니다. 업그레이드 중에 한 인스턴스가 다시 시작되면 트래픽이 나머지 인스턴스로 리디렉션됩니다. 해당 인스턴스는 추가 부하를 처리할 수 없습니다. 이로 인해 서비스 가용성이 감소합니다.

해결 방법 5: 서비스에 충분한 초과 용량 유지

서비스에 사용할 수 없는 역할 인스턴스의 특정 비율을 흡수할 수 있는 충분한 초과 용량이 있는지 확인합니다. 사용할 수 있도록 해야 하는 초과 용량의 양을 계산하려면 1번을 업그레이드 도메인 수로 나눕니다. 예를 들어 두 개의 업그레이드 도메인이 있는 경우 업그레이드 도메인을 사용할 수 없게 되는 것을 처리하려면 1/2 = 50% 초과 용량이 필요합니다. 5개의 업그레이드 도메인이 있는 경우 5개의 업그레이드 도메인 중 하나에서 가용성 손실을 처리하기 위해 1/5 = 20% 초과 용량이 필요합니다.

문제 6: 웹 사이트를 준비하는 데 너무 오래 걸리기 때문에 클라이언트가 중단 또는 시간 초과를 경험합니다.

웹 사이트를 준비하는 데 몇 분 정도 걸리나요? 예를 들어 웹 사이트 준비는 표준 IIS 또는 ASP.NET 미리 컴파일 및 모듈 로드로 구성되거나 캐시 또는 기타 앱 관련 작업을 예열할 수 있습니다. 이 경우 클라이언트에서 중단 또는 임의 시간 초과가 발생할 수 있습니다.

역할 인스턴스가 다시 시작되고 OnStart 코드가 실행을 완료하면 역할 인스턴스가 부하 분산 장치 회전으로 복원됩니다. 그러면 역할 인스턴스가 들어오는 요청을 수신하기 시작합니다. 웹 사이트가 여전히 예열 중인 경우 들어오는 모든 요청이 큐에 대기하고 시간이 초과됩니다. 웹 역할의 인스턴스가 두 개뿐이라고 가정합니다. 이 경우 인스턴스는 IN_0 게스트 OS 업데이트를 위해 인스턴스를 다시 시작하는 동안 IN_1 들어오는 요청의 100%를 받습니다. 그러나 인스턴스는 IN_0 여전히 예열 중입니다. 이 시나리오는 웹 사이트가 두 인스턴스에서 모두 준비될 때까지 서비스가 완전히 중단될 수 있습니다.

해결 방법 6: 준비 완료될 때까지 역할 인스턴스가 들어오는 요청을 수신하지 못하도록 중지

웹 사이트가 준비 작업을 OnStart 완료할 때까지 역할 인스턴스에 대한 이벤트 처리 코드가 완료되지 않도록 하는 것이 좋습니다. 이 이벤트 프로세스를 구현하려면 다음 예제 코드를 사용할 수 있습니다.

public class WebRole : RoleEntryPoint {
    public override bool OnStart () {
        // For information about handling configuration changes, see the article
        // "Customize the Lifecycle of a Web or Worker role in .NET" at
        // https://learn.microsoft.com/azure/cloud-services/cloud-services-role-lifecycle-dotnet.
        IPHostEntry ipEntry = Dns.GetHostEntry (Dns.GetHostName ());
        string ip = null;
        foreach (IPAddress ipaddress in ipEntry.AddressList) {
            if (ipaddress.AddressFamily.ToString () == "InterNetwork") {
                ip = ipaddress.ToString ();
            }
        }
        string urlToPing = "https://" + ip;
        HttpWebRequest req = HttpWebRequest.Create (urlToPing) as HttpWebRequest;
        WebResponse resp = req.GetResponse ();
        return base.OnStart ();
    }
}

자세한 정보

Azure VM OS 업그레이드에서 역할 인스턴스 다시 시작 FAQ

도움을 요청하십시오.

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

다음을 통해 공유