Omstarter av rollinstanser som orsakas av uppgraderingar av operativsystemet för virtuella Azure-datorer

Den här artikeln beskriver effekterna av uppgraderingar av operativsystem för virtuella Microsoft Azure-datorer (VM) på omstart av rollinstanser. Den innehåller information om uppgraderingsscheman för operativsystem och gästagenter, tjänstpåverkan och krav, meddelande, identifiering och hur du löser vanliga problem.

Uppgraderingsscheman

Ungefär varje månad släpper Microsoft en ny gästoperativsystemversion för virtuella Datorer med Azure Platform as a Service (PaaS). Det exakta schemat varierar och den historiska trenden kan ses i Azure Guest OS-versionerna och SDK-kompatibilitetsmatrisen. Under den här distributionen utför Azure Fabric Controller två passerkort (ett värdoperativsystemspass och ett gästoperativsystemspass) via alla datacenter. En regelbunden uppdatering av Azure-gästagenten körs också på den virtuella datorn.

Följande avsnitt innehåller mer information om de två uppgraderingspassen och uppgraderingen av gästagenten.

Pass 1: Värdoperativsystem

Det första passet uppgraderar värdoperativsystemet. Värdoperativsystemet startar om rollinstanser och infrastrukturkontrollanten ser till att endast instanser från en uppgraderingsdomän i taget startas om. Under den här omstarten går rollinstanserna igenom standardavstängningsprocessen. RoleEnvironment.OnStop Sedan körs händelsen för att ge dig en möjlighet att stänga av instansen på ett smidigt sätt.

Uppdateringen av värdoperativsystemet kan ta flera dagar för infrastrukturresurserna att samordna uppgraderingarna mellan alla olika värdbaserade tjänster och uppgraderingsdomäner i ett datacenter. Vanligtvis uppdateras olika instanser av distributionen med flera timmars mellanrum.

Mer information om uppgraderingsprocessen för värdoperativsystemet finns i artikeln Azure-värduppdateringar: Varför, när och hur Azure-bloggen fungerar.

Pass 2: Gästoperativsystem

När värdoperativsystemet har uppgraderats över datacentret uppgraderas gästoperativsystemet för tjänster som är konfigurerade för att använda automatiska gästoperativsystemversioner. Den här uppgraderingen fortsätter med hjälp av standardregler för uppgraderingsdomäner för din tjänst. Den virtuella datorn startas om och Windows-partitionen (D-enheten) återskapas med hjälp av det uppgraderade operativsystemet.

Uppdateringsprocessen för gästoperativsystemet är mycket snabbare än uppdateringen av värdoperativsystemet. Det beror på att infrastrukturresurserna endast måste samordna uppdateringen i din värdbaserade tjänst och dina uppgraderingsdomäner. Varaktigheten för uppdateringsprocessen för gästoperativsystemet för din tjänst beror till stor del på följande faktorer:

• Antalet rollinstanser
• Antalet uppgraderingsdomäner
• Hur lång tid det tar för tjänsten att stänga av (Stopping och OnStop händelser)
• Hur lång tid det tar att starta tjänsten (startaktiviteter och OnStart händelsen)

Gästagent

Azure-gästagenten uppdateras ungefär varje månad. När gästagenten uppdateras utförs följande åtgärder:

• Värdprocessen som kör din roll (vanligtvis WaWorkerHost eller WaWebHost) stängs av korrekt.
• Gästagenten uppdateras själv.
• Värdprocessen startar igen.

Mer information om gästagentprocessen och hur den interagerar med din tjänst finns i Arbetsflöde för den klassiska windows Azure-arkitekturen för virtuella datorer.

Påverkan och krav för tjänsten

I följande lista beskrivs påverkan på och kraven för din molntjänst:

• Om någon av dina roller bara har en instans kan det uppstå avbrott i tjänsten. Du bör ha minst två instanser av varje roll eftersom serviceavtalet (SLA) kräver en drifttid på 99,95 procent.

• Förvänta dig att dina rollinstanser startar om för värdoperativsystemets uppdatering ungefär en gång i månaden. Om du har automatiska uppdateringar av gästoperativsystemet förväntar du dig att dina instanser startar om igen. Omstarterna är vanligtvis flera timmars mellanrum. Den här tidsramen kan dock ändras beroende på de olika tjänsternas sammansättning som finns i ett datacenter.

• Din roll måste följa de regler som styr värdoperativsystemets uppdateringar. I synnerhet bör rollinstanser nå Ready tillståndet inom 30 minuter efter att startaktiviteterna har startats. Mer information om den här begränsningen finns i Så här fortsätter en uppgradering.

• Uppgraderingen av värdoperativsystemet gör att rollinstansen startas om och uppgraderingen av gästoperativsystemet gör att instansen återskapas. På grund av dessa händelser måste dina rollinstanser kunna hantera följande procedurer:

  • Starta om
  • Reimage
  • Återvinna

Anmälan

Azure-plattformen erbjuder för närvarande inte proaktiva meddelanden när en uppgradering av operativsystemet sker. Dina rollinstanser får en RoleEnvironment.Stopping händelse innan de stängs av. Du kan använda den händelsen för att korrekt avsluta allt arbete som rollinstansen utför eller för att meddela en administratör att en instans stängs av.

Du kan prenumerera på RSS-feeden för Azure OS Uppdateringar. Den här feeden bör uppdateras samma dag som OS-uppdateringarna börjar distribueras till datacentret. Feeden ger vanligtvis inte avancerade proaktiva meddelanden, men det hjälper dig att identifiera när uppdateringarna inträffar. Uppdateringsprocessen kan ta flera dagar att slutföra. Därför kan du behöva vänta en eller flera dagar mellan när RSS-flödet uppdateras och den värdbaserade tjänsten börjar uppdateras.

Versionslistan för Azure-gästoperativsystem och listan över os-versioner som är tillgängliga för val i Azure Portal uppdateras vanligtvis när gästoperativsystemsdistributionen har slutförts. Du bör inte använda den senaste posten i de här listorna som en indikation på när os-uppdateringarna pågår.

Upptäckt

För närvarande finns det inget direkt sätt att identifiera en uppgradering av värdoperativsystemet. Du kan dock se bevis för omstarten i loggarna på den virtuella datorn. Detta gör du på något av följande sätt:

• I den Loggboken appen söker du i systemhändelseloggarna efter händelsekällan USER32, händelse-ID 1074. Den här händelsen innehåller följande meddelande:

  Processen D:\Packages\GuestAgent\WaAppAgent.exe (RD00155D50206D) har initierat avstängningen av datorn RD00155D50206D för användaren NT AUTHORITY\SYSTEM av följande anledning: Äldre API-avstängning

  Det här meddelandet anger att Gästagenten för Azure Fabric (WaAppAgent.exe) initierade en avstängning av den virtuella datorn.

• I en textredigerare söker du i en gammal appagents runtime-loggfil (AppAgentRuntime.log.old) efter ett _Context_Start meddelande där är lika StopContainer()med Context . Mer information om hur du undersöker kontextposter i appagentens körningslogg finns i Felsöka scenario 6 – Rollåtervinning efter att ha körts under en tid i Azure-bloggarkivet.

Vanliga problem och lösningar

I följande avsnitt beskrivs några vanliga problem som rör omstarter av rollinstanser och hur du kan lösa dem. Mer information om de processer som körs och var loggfiler som du kan använda för felsökning finns i Arbetsflöde för den klassiska vm-arkitekturen i Windows Azure.

Problem 1: Startuppgifter eller kod kan inte köras andra gången efter en omstart av värdoperativsystemet

Startåtgärder eller koden i OnStart funktionen eller Run kan misslyckas andra gången efter en omstart av värdoperativsystemet. Omstarten ska anropa startåtgärderna för att köras igen. Det här felet förhindrar att rollinstansen Ready når tillståndet.

Vad händer om du gör något i en startuppgift och sedan kör ett kommando som returnerar ett fel när det körs andra gången? I det här fallet misslyckas startuppgiften och gör att rollinstansen börjar återanvändas. Om du till exempel använder konfigurationskommandot FÖR APPCMD-uppsättning för att lägga till ett konfigurationsavsnitt i Internet Information Services (IIS) misslyckas kommandot vid den andra körningen. Kommandot genererar felmeddelandet "Nytt tilläggsobjekt saknar obligatoriska attribut. Det går inte att lägga till en duplicerad samlingspost av typen..." Sedan börjar rollinstansen återanvändas.

Lösning 1: Ansluta till den virtuella datorn och felsöka start- eller kodfelet via fjärranslutning

Om du vill felsöka den här typen av fel använder du Remote Desktop Protocol (RDP) för att fjärransluta till den virtuella datorn. Granska händelseloggarna efter fel och kontrollera om det finns fel i WaHostBootstrapper.log-filen . Under din typiska utveckling och testningsprocess bör du proaktivt initiera en omstart av dina rollinstanser från Azure Portal. Det här steget hjälper dig att testa din tjänst för att se till att den fungerar korrekt i det här scenariot.

En vanlig korrigering för startaktivitetsfel är att lägga till ett exit /b 0 kommando i slutet av startaktivitetsskriptet. Det här avslutskommandot avslutar skriptet med hjälp av en slutkod som indikerar att det lyckades. Mer information om varför det här kommandot är nödvändigt finns i Så här konfigurerar och kör du startuppgifter för en Azure Cloud Service (klassisk).

Problem 2: Startaktiviteten eller koden körs inte när Windows-partitionen har återskapats

Windows-partitionen (D-enheten) är vanligtvis där programinstallationer och registerändringar lagras. Under gäst-OS-delen av en uppdatering återskapas Windows-partitionen. Detta kan leda till att dessa installationer och ändringar går förlorade. Om startkoden av misstag förutsätter att vissa registerändringar fortfarande finns efter att Windows-partitionen har återskapats kanske rollinstansen inte fungerar korrekt. Det här felet förhindrar att rollinstansen Ready når tillståndet.

Startaktiviteten kan till exempel göra en registerändring. Sedan lagras en post för ändringen på C- eller E-enheten för att se till att registerändringen inte körs en andra gång. Registerändringen på D-enheten går dock förlorad på grund av avbildningen och startaktiviteten återställer inte registerändringen eftersom uppgiften inte tror att den är nödvändig. Den saknade registerändringen kan så småningom göra att resten av startuppgiften misslyckas.

Lösning 2: Testa återimering av rollinstanser från Azure Portal

Under din typiska utveckling och testningsprocess bör du proaktivt initiera en ny avbildning av dina rollinstanser från Azure Portal. Det här steget hjälper dig att testa tjänsten och se till att den fungerar korrekt i det här scenariot.

Problem 3: Startkoden tar mer än 30 minuter att slutföra

Om startkoden tar mer än 30 minuter att slutföra kan du ha fler än en rollinstans som är out-of-service på samma gång. Det här scenariot inträffar oftast när en startuppgift utför någon av följande åtgärder:

• Installerar ett program eller en funktion
• Laddar ned cachedata
• Laddar ned webbplatsinformation

Lösning 3: Granska tjänstpåverkan och krav

Gå igenom avsnittet Tjänstpåverkan och krav för att veta vad du kan förvänta dig och hur du kan förhindra eller minska eventuella startfördröjningar.

Problem 4: Azure startar inte om värden eller gästoperativsystemet efter en uppdatering

I sällsynta fall kanske Azure inte startar om värden eller gästoperativsystemet efter en uppdatering. I det här scenariot visas förmodligen meddelandet "Väntar på värd" i portalen som inte ändras efter 30 minuter eller mer.

Lösning 4a: Åtgärda startkoden

Om du kan använda RDP (Remote Desktop Protocol) för att ansluta till rollinstansen kan det uppstå ett fel i startkoden som du kan åtgärda. Mer information om hur du åtgärdar startkoden finns i Lösning 1: Ansluta till den virtuella datorn och felsöka start- eller kodfelet via fjärranslutning.

Lösning 4b: Ta bort distributionen

Om du inte kan använda RDP för att ansluta till rollinstansen är förmodligen det enda sättet att återställa instansen att ta bort distributionen.

Problem 5: En eller flera rollinstanser är inte tillgängliga under os-uppgraderingen

Om några rollinstanser inte är tillgängliga under os-uppgraderingen kan detta orsaka en minskning av tjänstkapaciteten. Anta till exempel att du har två instanser av en webbroll och att båda instanserna vanligtvis körs med 75 procent cpu-användning. Om en instans startas om under uppgraderingen omdirigeras trafiken till den återstående instansen. Den instansen kan inte hantera den extra belastningen. Detta medför en minskning av tjänstens tillgänglighet.

Lösning 5: Behåll tillräckligt med överkapacitet i din tjänst

Kontrollera att tjänsten har tillräckligt med överkapacitet för att absorbera en viss procentandel rollinstanser som inte är tillgängliga. Om du vill beräkna mängden överkapacitet som du måste göra tillgänglig dividerar du siffran ett med antalet uppgraderingsdomäner. Om du till exempel har två uppgraderingsdomäner behöver du 1/2 = 50 procent överkapacitet för att hantera att en uppgraderingsdomän blir otillgänglig. Om du har fem uppgraderingsdomäner behöver du 1/5 = 20 procent överkapacitet för att hantera förlust av tillgänglighet i någon av de fem uppgraderingsdomänerna.

Problem 6: Klienter drabbas av avbrott eller timeouter eftersom webbplatsen tar för lång tid att värma upp

Tar det flera minuter att värma upp din webbplats? (Till exempel kan webbplatsuppvärmning bestå av standard-IIS eller ASP.NET förkompilering och modulinläsning, eller så kan det värma upp en cache eller andra appspecifika uppgifter.) I det här fallet kan dina klienter drabbas av avbrott eller slumpmässiga timeouter.

När en rollinstans har startats om och OnStart koden har körts återställs rollinstansen till lastbalanserarens rotation. Rollinstansen börjar sedan ta emot inkommande begäranden. Om din webbplats fortfarande håller på att värmas upp köar alla inkommande begäranden och tidsgränsen överskrids. Anta att du bara har två instanser av din webbroll. I det här fallet tar instansen IN_0 emot 100 procent av inkommande begäranden medan instansen IN_1 startas om för uppdateringen av gästoperativsystemet. Instansen håller dock fortfarande på IN_0 att värmas upp. Det här scenariot kan orsaka ett fullständigt avbrott i tjänsten tills webbplatsen har värmts upp på båda instanserna.

Lösning 6: Stoppa en rollinstans från att ta emot inkommande begäranden tills uppvärmningen är klar

Vi rekommenderar att du behåller OnStart händelsehanteringskoden för rollinstansen från att slutföras tills webbplatsen har slutfört uppvärmningen. Om du vill implementera den här händelseprocessen kan du använda följande exempelkod:

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 ();
    }
}

Mer information

• Vanliga frågor och svar om rollinstanser startas om från uppgraderingar av virtuella Azure-datorer

Kontakta oss för att få hjälp

Om du har frågor eller behöver hjälp skapar du en supportförfrågan eller frågar Azure community support. Du kan också skicka produktfeedback till Azure-feedbackcommunityn.