Dela via

Så här uppdaterar du en Azure Cloud Service (klassisk)

  • Artikel

Viktigt!

Cloud Services (klassisk) är nu inaktuellt för nya kunder och kommer att dras tillbaka den 31 augusti 2024 för alla kunder. Nya distributioner bör använda den nya Azure Resource Manager-baserade distributionsmodellen Azure Cloud Services (utökad support).

Processen för att uppdatera en molntjänst, inklusive både dess roller och gästoperativsystem, tar tre steg. Först måste binärfilerna och konfigurationsfilerna för den nya molntjänsten eller os-versionen laddas upp. Därefter reserverar Azure beräknings- och nätverksresurser för molntjänsten baserat på kraven i den nya molntjänstversionen. Slutligen utför Azure en löpande uppgradering för att stegvis uppdatera klientorganisationen till den nya versionen eller gästoperativsystemet, samtidigt som tillgängligheten bevaras. I den här artikeln beskrivs information om det här sista steget – den löpande uppgraderingen.

Uppdatera en Azure-tjänst

Azure organiserar dina rollinstanser i logiska grupper som kallas uppgraderingsdomäner (UD). Uppgraderingsdomäner (UD) är logiska uppsättningar med rollinstanser som uppdateras som en grupp. Azure uppdaterar en molntjänst en UD i taget, vilket gör att instanser i andra UD:er kan fortsätta att betjäna trafik.

Standardantalet uppgraderingsdomäner är 5. Du kan ange ett annat antal uppgraderingsdomäner genom att inkludera attributet upgradeDomainCount i tjänstens definitionsfil (.csdef). Mer information om attributet upgradeDomainCount finns i Azure Cloud Services Definition Schema (.csdef File).

När du utför en uppdatering på plats av en eller flera roller i tjänsten uppdaterar Azure uppsättningar med rollinstanser enligt den uppgraderingsdomän som de tillhör. Azure uppdaterar alla instanser i en viss uppgraderingsdomän – stoppar dem, uppdaterar dem, tar dem tillbaka online – och går sedan vidare till nästa domän. Genom att bara stoppa de instanser som körs i den aktuella uppgraderingsdomänen ser Azure till att en uppdatering sker med minsta möjliga inverkan på den tjänst som körs. Mer information finns i Så här fortsätter uppdateringen senare i den här artikeln.

Kommentar

Även om termerna uppdatering och uppgradering har en något annorlunda betydelse i kontexten Azure, kan de användas omväxlande för processerna och beskrivningarna av funktionerna i det här dokumentet.

Tjänsten måste definiera minst två instanser av en roll för att den rollen ska uppdateras på plats utan driftstopp. Om tjänsten bara består av en instans av en roll är tjänsten inte tillgänglig förrän uppdateringen på plats har slutförts.

Den här artikeln beskriver följande information om Azure-uppdateringar:

Tillåtna tjänständringar under en uppdatering

I följande tabell visas de tillåtna ändringarna i en tjänst under en uppdatering:

Ändringar som tillåts för värdtjänster, tjänster och roller Uppdatering på plats Mellanlagrad (VIP-växling) Ta bort och distribuera om
Operativsystemets version Ja Ja Ja
.NET-förtroendenivå Ja Ja Ja
Storlek 1 för virtuell dator Ja2 Ja Ja
Inställningar för lokal lagring Öka endast2 Ja Ja
Lägga till eller ta bort roller i en tjänst Ja Ja Ja
Antal instanser av en viss roll Ja Ja Ja
Antal eller typ av slutpunkter för en tjänst Ja2 Nej Ja
Namn och värden för konfigurationsinställningar Ja Ja Ja
Värden (men inte namn) för konfigurationsinställningar Ja Ja Ja
Lägga till nya certifikat Ja Ja Ja
Ändra befintliga certifikat Ja Ja Ja
Distribuera ny kod Ja Ja Ja

1 Storleksändring begränsad till den delmängd av storlekar som är tillgängliga för molntjänsten.

2 Kräver Azure SDK 1.5 eller senare versioner.

Varning

Om du ändrar storleken på den virtuella datorn förstörs lokala data.

Följande objekt stöds inte under en uppdatering:

  • Ändra namnet på en roll. Ta bort och lägg sedan till rollen med det nya namnet.
  • Ändra antalet uppgraderingsdomäner.
  • Minska storleken på de lokala resurserna.

Om du gör andra uppdateringar av tjänstens definition, till exempel om du minskar storleken på den lokala resursen, måste du utföra en VIP-uppdatering i stället. Mer information finns i Växla distribution.

Så här fortsätter en uppgradering

Du kan bestämma om du vill uppdatera alla roller i din tjänst eller en enda roll i tjänsten. I båda fallen stoppas, uppgraderas och återansluts alla instanser av varje roll som uppgraderas och tillhör den första uppgraderingsdomänen. När de är online igen stoppas instanserna i den andra uppgraderingsdomänen, uppgraderas och online igen. En molntjänst kan ha högst en uppgradering aktiv i taget. Uppgraderingen utförs alltid mot den senaste versionen av molntjänsten.

Följande diagram visar hur uppgraderingen fortsätter om du uppgraderar alla roller i tjänsten:

Uppgraderingstjänst

Det här nästa diagrammet visar hur uppdateringen fortsätter om du bara uppgraderar en enda roll:

Uppgraderingsroll

Under en automatisk uppdatering utvärderar Azure Fabric Controller regelbundet hälsotillståndet för molntjänsten för att avgöra när det är säkert att gå nästa UD. Den här hälsoutvärderingen utförs per roll och tar endast hänsyn till instanser i den senaste versionen (dvs. instanser från UD:ar som redan har gått). Den kontrollerar att för varje roll har ett minsta antal rollinstanser uppnått ett tillfredsställande terminaltillstånd.

Timeout för start av rollinstans

Infrastrukturkontrollanten väntar 30 minuter på att varje rollinstans ska nå tillståndet Startad. Om tidsgränsen förflutit fortsätter infrastrukturkontrollanten att gå till nästa rollinstans.

Påverkan på att driva data under cloud service-uppgraderingar

När du uppgraderar en tjänst från en enskild instans till flera instanser tar Azure ned dina tjänster medan uppgraderingen utförs. Servicenivåavtalet som garanterar tjänsttillgänglighet gäller endast för tjänster som distribueras med mer än en instans. I följande lista beskrivs hur varje Azure-tjänstuppgraderingsscenario påverkar data på varje enhet:

Scenario C-enhet D-enhet E-enhet
Omstart av virtuell dator (VM) Bevarad Bevarad Bevarad
Omstart av portalen Bevarad Bevarad Förstörd
Omimering av portalen Bevarad Förstörd Förstörd
Uppgradering på plats Bevarad Bevarad Förstörd
Nodmigrering Förstörd Förstörd Förstörd

I föregående lista representerar E: -enheten rollens rotenhet och bör inte vara hårdkodad. Använd i stället miljövariabeln %RoleRoot% för att representera enheten.

För att minimera stilleståndstiden när du uppgraderar en tjänst med en enskild instans distribuerar du en ny tjänst för flera instanser till mellanlagringsservern och utför ett VIP-byte.

Återställning av en uppdatering

Azure ger flexibilitet när det gäller att hantera tjänster under en uppdatering genom att du kan initiera fler åtgärder för en tjänst, efter att Azure Fabric Controller har godkänt den första uppdateringsbegäran. En återställning kan bara utföras när en uppdatering (konfigurationsändring) eller uppgraderingen pågår för distributionen. En uppdatering eller uppgradering anses vara pågående så länge det finns minst en instans av tjänsten som förblir ouppdaterad till den nya versionen. Om du vill testa om en återställning tillåts kontrollerar du att värdet för flaggan RollbackAllowed är inställt på true. Get Deployment and Get Cloud Service Properties operations return the RollbackAllowed flag for your reference .Get Deployment and Get Cloud Service Properties operations return the RollbackAllowed flag for your reference .

Kommentar

Det är bara meningsfullt att anropa Återställning på en uppdatering eller uppgradering på plats eftersom VIP-växlingsuppgraderingar innebär att ersätta en hel instans av tjänsten som körs med en annan.

Återställning av en pågående uppdatering har följande effekter på distributionen:

  • Rollinstanser som förblir ouppdaterade eller ouppgraderade till den nya versionen uppdateras inte eller uppgraderas, eftersom dessa instanser redan kör målversionen av tjänsten.
  • Alla rollinstanser som redan har uppdaterats eller uppgraderats till den nya versionen av tjänstpaketfilen (*.cspkg) eller tjänstkonfigurationsfilen (*.cscfg) (eller båda filerna) återställs till den fördefinierade versionen av dessa filer.

Följande funktioner tillhandahåller den här funktionen:

  • Återställningsuppdateringen eller uppgraderingsåtgärden , som kan anropas för en konfigurationsuppdatering (utlöses genom att anropa Konfiguration av ändringsdistribution) eller en uppgradering (utlöses genom att anropa uppgraderingsdistribution) så länge det finns minst en instans i tjänsten som förblir ouppdaterad till den nya versionen.

  • Elementet Locked och RollbackAllowed, som returneras som en del av svarstexten i åtgärderna Get Deployment och Get Cloud Service Properties :

    1. Med elementet Låst kan du identifiera när en muterande åtgärd kan anropas vid en viss distribution.
    2. Med elementet RollbackAllowed kan du identifiera när återställningsuppdateringen eller uppgraderingsåtgärden kan anropas för en viss distribution.

    För att kunna utföra en återställning behöver du inte kontrollera både elementen Locked och RollbackAllowed. Det räcker med att bekräfta att RollbackAllowed är inställt på true. Dessa element returneras endast om dessa metoder anropas med hjälp av begärandehuvudet inställt på "x-ms-version: 2011-10-01" eller en senare version. Mer information om versionshuvuden finns i versionshantering av den klassiska distributionsmodellen.

Det finns vissa situationer där en återställning av en uppdatering eller uppgradering inte stöds. Dessa situationer är följande:

  • Minskning av lokala resurser – Om uppdateringen ökar de lokala resurserna för en roll tillåter Inte Azure-plattformen återställning.
  • Kvotbegränsningar – Om uppdateringen var en nedskalningsåtgärd kanske du inte längre har tillräckligt med beräkningskvot för att slutföra återställningsåtgärden. Varje Azure-prenumeration har en associerad kvot. Kvoten anger det maximala antalet kärnor som alla värdbaserade tjänster som tillhör den prenumerationen kan använda. Om en återställning av en viss uppdatering skulle placera prenumerationen över kvoten aktiveras inte återställningen.
  • Konkurrensvillkor – Om den första uppdateringen slutförs är en återställning inte möjlig.

Ett exempel på när återställningen av en uppdatering kan vara användbar är om du använder uppgraderingsdistributionsåtgärden i manuellt läge för att styra den hastighet med vilken en större uppgradering på plats distribueras till din Azure-värdbaserade tjänst.

Under distributionen av uppgraderingen anropar du Uppgraderingsdistribution i manuellt läge och börjar gå över uppgraderingsdomäner. Om du någon gång, när du övervakar uppgraderingen, noterar att vissa rollinstanser i de första uppgraderingsdomänerna inte svarar, kan du anropa återställningsuppdateringen eller uppgraderingsåtgärden i distributionen. Den här åtgärden lämnar orörda instanser som förblir ouppgraderade och återställer uppgraderade instanser till det tidigare tjänstpaketet och konfigurationen.

Initiera flera muterande åtgärder i en pågående distribution

I vissa fall kanske du vill initiera flera samtidiga muterande åtgärder för en pågående distribution. Du kan till exempel utföra en tjänstuppdatering och medan uppdateringen distribueras i tjänsten vill du göra vissa ändringar, till exempel att återställa uppdateringen, tillämpa en annan uppdatering eller till och med ta bort distributionen. Ett fall där det här scenariot kan uppstå är om en tjänstuppgradering innehåller buggig kod som gör att en uppgraderad rollinstans kraschar upprepade gånger. I det här fallet kan Inte Azure Fabric-kontrollanten göra framsteg med att tillämpa uppgraderingen eftersom ett otillräckligt antal instanser i den uppgraderade domänen är felfria. Det här tillståndet kallas för en fast distribution. Du kan ta bort distributionen genom att återställa uppdateringen eller tillämpa en ny uppdatering ovanpå den misslyckade uppdateringen.

När Azure Fabric Controller tar emot den första begäran om att uppdatera eller uppgradera tjänsten kan du starta efterföljande muterande åtgärder. Du behöver alltså inte vänta tills den inledande åtgärden har slutförts innan du kan starta en ny muterande åtgärd.

Att initiera en andra uppdateringsåtgärd medan den första uppdateringen pågår utspelar sig på samma sätt som återställningsåtgärden. Om den andra uppdateringen är i automatiskt läge uppgraderas den första uppgraderingsdomänen omedelbart, vilket kan leda till att instanser från flera uppgraderingsdomäner är offline samtidigt.

De muterande åtgärderna är följande: Ändra distributionskonfiguration, Uppgraderingsdistribution, Uppdateringsdistributionsstatus, Ta bort distribution och Återställningsuppdatering eller uppgradering.

Två åtgärder, Get Deployment och Get Cloud Service Properties, returnerar flaggan Låst. Du kan undersöka flaggan Låst för att avgöra om du kan anropa en muterande åtgärd för en viss distribution.

För att kunna anropa den version av dessa metoder som returnerar flaggan Låst måste du ange begärandehuvudet till "x-ms-version: 2011-10-01" eller senare. Mer information om versionshuvuden finns i versionshantering av den klassiska distributionsmodellen.

Distribution av roller mellan uppgraderingsdomäner

Azure distribuerar instanser av en roll jämnt över ett visst antal uppgraderingsdomäner, som kan konfigureras som en del av tjänstdefinitionsfilen (.csdef). Det maximala antalet uppgraderingsdomäner är 20 och standardvärdet är 5. Mer information om hur du ändrar tjänstdefinitionsfilen finns i Azure Service Definition Schema (.csdef File).

Om din roll till exempel har 10 instanser innehåller varje uppgraderingsdomän som standard två instanser. Om din roll har 14 instanser innehåller fyra av uppgraderingsdomänerna tre instanser och en femte domän innehåller två.

Uppgraderingsdomäner identifieras med ett nollbaserat index: den första uppgraderingsdomänen har ett ID på 0 och den andra uppgraderingsdomänen har ett ID på 1 och så vidare.

Följande diagram visar hur rollerna i en tjänst som innehåller två roller distribueras när tjänsten definierar två uppgraderingsdomäner. Tjänsten kör åtta instanser av webbrollen och nio instanser av arbetsrollen.

Distribution av uppgraderingsdomäner

Kommentar

Observera att Azure styr hur instanser allokeras mellan uppgraderingsdomäner. Det går inte att ange vilka instanser som ska allokeras till vilken domän.

Nästa steg

Hantera molntjänster
Så här övervakar du Cloud Services
Så här konfigurerar du Cloud Services