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

Att uppdatera en molntjänst, inklusive både dess roller och gästoperativsystem, är en process i 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. Den här artikeln beskriver detaljerna i det sista steget – den löpande uppgraderingen.

Uppdatera en Azure-tjänst

Azure organiserar dina rollinstanser i logiska grupperingar som kallas uppgraderingsdomäner (UD). Uppgraderingsdomäner (UD) är logiska uppsättningar av rollinstanser som uppdateras som en grupp. Azure uppdaterar en molntjänst en UD i taget, vilket gör att instanser i andra UD:ar 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 din tjänst uppdaterar Azure uppsättningar av 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 endast 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.

Tjänsten måste definiera minst två instanser av en roll för att den rollen ska kunna 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.

Det här avsnittet beskriver följande information om Azure-uppdateringar:

• Tillåtna tjänständringar under en uppdatering
• Så här fortsätter en uppgradering
• Återställning av en uppdatering
• Initiera flera muterande åtgärder i en pågående distribution
• Distribution av roller mellan uppgraderingsdomäner

Tillåtna tjänständringar under en uppdatering

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

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

² Kräver Azure SDK 1.5 eller senare versioner.

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.
• Ändring av 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-växlingsuppdatering 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 tas alla instanser av varje roll som uppgraderas och tillhör den första uppgraderingsdomänen tillbaka online. När de är online igen stoppas instanserna i den andra uppgraderingsdomänen, uppgraderas och tas online igen. En molntjänst kan ha högst en aktiv uppgradering åt gången. Uppgraderingen utförs alltid mot den senaste versionen av molntjänsten.

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

Uppgradera

I nästa diagram visas hur uppdateringen fortsätter om du bara uppgraderar en enda roll:

Under en automatisk uppdatering utvärderar Azure Fabric Controller regelbundet molntjänstens hälsotillstånd för att avgöra när det är säkert att gå igenom 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:n som redan har gåtts). Den verifierar att ett minsta antal rollinstanser för varje roll har 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 enda instans till flera instanser tas tjänsten ned medan uppgraderingen utförs på grund av hur Azure uppgraderar tjänster. Servicenivåavtalet som garanterar tjänsttillgänglighet gäller endast för tjänster som distribueras med fler än en instans. I följande lista beskrivs hur data på varje enhet påverkas av varje azure-tjänstuppgraderingsscenario:

Observera att I listan ovan 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 låta dig initiera ytterligare åtgärder för en tjänst efter att den första uppdateringsbegäran har godkänts av Azure Fabric Controller. En återställning kan bara utföras när en uppdatering (konfigurationsändring) eller uppgradering 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 ännu inte har uppdaterats till den nya versionen. Om du vill testa om en återställning tillåts kontrollerar du att värdet för flaggan RollbackAllowed, som returneras av åtgärderna Get Deployment och Get Cloud Service Properties , är inställt på true.

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

• Rollinstanser som ännu inte har uppdaterats eller uppgraderats till den nya versionen uppdateras eller uppgraderas inte, 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 förhandsuppgraderingsversionen av dessa filer.

Detta tillhandahålls funktionellt av följande funktioner:

• Åtgärden Återställ uppdatering eller uppgradering , 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 ännu inte har uppdaterats till den nya versionen.

• Locked-elementet och RollbackAllowed-elementet, som returneras som en del av svarstexten i åtgärderna Hämta distribution och Hämta egenskaper för molntjänsten :

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

  För att utföra en återställning behöver du inte kontrollera både elementen Locked och RollbackAllowed. Det räcker att bekräfta att RollbackAllowed är inställt på true. Dessa element returneras bara 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 tjänsthantering.

Det finns vissa situationer där en återställning av en uppdatering eller uppgradering inte stöds. Dessa ä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äcklig beräkningskvot för att slutföra återställningsåtgärden. Varje Azure-prenumeration har en associerad kvot som anger det maximala antalet kärnor som kan användas av alla värdbaserade tjänster som tillhör den prenumerationen. Om en återställning av en viss uppdatering skulle innebära att prenumerationen överskrider kvoten kommer en återställning inte att aktiveras.
• Konkurrenstillstånd – Om den första uppdateringen har slutförts ä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 uppgraderingsdistributionen i manuellt läge för att styra den hastighet med vilken en större uppgradering på plats till din Azure-värdbaserade tjänst distribueras.

Under distributionen av uppgraderingen anropar du Uppgraderingsdistribution i manuellt läge och börjar gå på uppgraderingsdomäner. Om du någon gång, när du övervakar uppgraderingen, noterar att vissa rollinstanser i de första uppgraderingsdomänerna som du undersöker inte svarar kan du anropa återställningsuppdaterings- eller uppgraderingsåtgärden för distributionen, vilket lämnar orörda instanser som ännu inte hade uppgraderats och återställningsinstanser som hade uppgraderats 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 i en pågående distribution. Du kan till exempel utföra en tjänstuppdatering och medan uppdateringen distribueras i hela tjänsten vill du göra vissa ändringar, t.ex. för att återställa uppdateringen, tillämpa en annan uppdatering eller till och med ta bort distributionen. Ett fall där detta kan vara nödvändigt är om en tjänstuppgradering innehåller buggkod 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 fastnad distribution. Du kan lossa distributionen genom att återställa uppdateringen eller tillämpa en ny uppdatering ovanpå den som misslyckas.

När den första begäran om att uppdatera eller uppgradera tjänsten har tagits emot av Azure Fabric-kontrollanten 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 annan muterande åtgärd.

Att initiera en andra uppdateringsåtgärd medan den första uppdateringen pågår kommer att utföras på liknande 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 vid samma tidpunkt.

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

Två åtgärder, Get Deployment (Hämta distribution ) och Get Cloud Service Properties (Hämta molntjänstegenskaper), returnerar flaggan Locked (Låst) som kan undersökas för att avgöra om en muterande åtgärd kan anropas för en viss distribution.

För att kunna anropa versionen av dessa metoder som returnerar låst flagga måste du ange begärandehuvudet till "x-ms-version: 2011-10-01" eller senare. Mer information om versionshuvuden finns i Versionshantering av tjänsthantering.

Distribution av roller mellan uppgraderingsdomäner

Azure distribuerar instanser av en roll jämnt över ett angivet 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 tio 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 ID:t 0 och den andra uppgraderingsdomänen har ID:t 1 och så vidare.

Följande diagram illustrerar hur en tjänst än 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.

Nästa steg

Hantera Cloud Services
Övervaka Cloud Services
Konfigurera Cloud Services