Een Azure-cloudservice bijwerken (klassiek)

Het bijwerken van een cloudservice, met inbegrip van zowel de rollen als het gastbesturingssystemen, is een proces in drie stappen. Eerst moeten de binaire bestanden en configuratiebestanden voor de nieuwe cloudservice of versie van het besturingssysteem worden geüpload. Vervolgens reserveert Azure reken- en netwerkresources voor de cloudservice op basis van de vereisten van de nieuwe cloudserviceversie. Ten slotte voert Azure een rolling upgrade uit om de tenant stapsgewijs bij te werken naar de nieuwe versie of het gastbesturingssysteem, met behoud van uw beschikbaarheid. In dit artikel worden de details van deze laatste stap, de rolling upgrade, besproken.

Een Azure-service bijwerken

Azure organiseert uw rolinstanties in logische groeperingen die upgradedomeinen (UD) worden genoemd. Upgradedomeinen (UD) zijn logische sets rolinstanties die als groep worden bijgewerkt. Azure werkt een cloudservice één UD tegelijk bij, waardoor exemplaren in andere UD's verkeer kunnen blijven bedienen.

Het standaardaantal upgradedomeinen is 5. U kunt een ander aantal upgradedomeinen opgeven door het kenmerk upgradeDomainCount op te slaan in het definitiebestand van de service (.csdef). Zie Azure Cloud Services Definition Schema (.csdef File) voor meer informatie over het kenmerk upgradeDomainCount.

Wanneer u een in-place update uitvoert van een of meer rollen in uw service, werkt Azure sets rolinstanties bij op basis van het upgradedomein waartoe ze behoren. Azure werkt alle exemplaren in een bepaald upgradedomein bij, stopt ze, werkt ze bij, brengt ze weer online en gaat vervolgens naar het volgende domein. Door alleen de exemplaren te stoppen die worden uitgevoerd in het huidige upgradedomein, zorgt Azure ervoor dat er een update plaatsvindt met zo min mogelijk gevolgen voor de actieve service. Zie Hoe de update verloopt verderop in dit artikel voor meer informatie.

Uw service moet ten minste twee exemplaren van een rol definiëren om die rol ter plaatse te kunnen bijwerken zonder downtime. Als de service uit slechts één exemplaar van één rol bestaat, is uw service niet beschikbaar totdat de in-place update is voltooid.

In dit onderwerp wordt de volgende informatie over Azure-updates behandeld:

• Toegestane servicewijzigingen tijdens een update
• Hoe een upgrade verloopt
• Terugdraaien van een update
• Meerdere mutatiebewerkingen initiëren in een doorlopende implementatie
• Distributie van rollen over upgradedomeinen

Toegestane servicewijzigingen tijdens een update

In de volgende tabel ziet u de toegestane wijzigingen in een service tijdens een update:

¹ Groottewijziging beperkt tot de subset van grootten die beschikbaar zijn voor de cloudservice.

² Hiervoor is Azure SDK 1.5 of latere versies vereist.

De volgende items worden niet ondersteund tijdens een update:

• De naam van een rol wijzigen. Verwijder de rol en voeg deze vervolgens toe met de nieuwe naam.
• Wijzigen van het aantal upgradedomeinen.
• De grootte van de lokale resources verkleinen.

Als u andere updates aanbrengt in de definitie van uw service, zoals het verkleinen van de grootte van de lokale resource, moet u in plaats daarvan een VIP-wisselupdate uitvoeren. Zie Implementatie wisselen voor meer informatie.

Hoe een upgrade verloopt

U kunt bepalen of u alle rollen in uw service of één rol in de service wilt bijwerken. In beide gevallen worden alle exemplaren van elke rol die wordt bijgewerkt en die deel uitmaken van het eerste upgradedomein, gestopt, bijgewerkt en weer online gebracht. Zodra ze weer online zijn, worden de exemplaren in het tweede upgradedomein gestopt, bijgewerkt en weer online gebracht. Een cloudservice kan maximaal één upgrade tegelijk actief hebben. De upgrade wordt altijd uitgevoerd op basis van de nieuwste versie van de cloudservice.

In het volgende diagram ziet u hoe de upgrade verloopt als u alle rollen in de service bijwerken:

In dit volgende diagram ziet u hoe de update verloopt als u slechts één rol bijwerkt:

Tijdens een automatische update evalueert de Azure Fabric Controller periodiek de status van de cloudservice om te bepalen wanneer het veilig is om de volgende UD te doorlopen. Deze statusevaluatie wordt per rol uitgevoerd en houdt alleen rekening met exemplaren in de nieuwste versie (dat wil zeggen instanties van UD's die al zijn doorlopen). Er wordt gecontroleerd of een minimum aantal rolinstanties voor elke rol een bevredigende terminale status heeft bereikt.

Time-out voor het starten van rolinstantie

De infrastructuurcontroller wacht 30 minuten totdat elk rolexemplaren de status Gestart heeft bereikt. Als de time-outduur is verstreken, blijft de infrastructuurcontroller naar het volgende rolexemplaren lopen.

Invloed op het stimuleren van gegevens tijdens cloudservice-upgrades

Wanneer u een service upgradet van één exemplaar naar meerdere exemplaren, wordt uw service uitgeschakeld terwijl de upgrade wordt uitgevoerd vanwege de manier waarop Azure services upgradet. De serviceovereenkomst die de beschikbaarheid van de service garandeert, is alleen van toepassing op services die zijn geïmplementeerd met meer dan één exemplaar. In de volgende lijst wordt beschreven hoe de gegevens op elk station worden beïnvloed door elk upgradescenario van de Azure-service:

Houd er rekening mee dat in de bovenstaande lijst het station E: het hoofdstation van de rol vertegenwoordigt en niet in code mag zijn vastgelegd. Gebruik in plaats daarvan de omgevingsvariabele %RoleRoot% om het station weer te geven.

Als u de downtime bij het upgraden van een service met één exemplaar wilt minimaliseren, implementeert u een nieuwe service met meerdere exemplaren op de faseringsserver en voert u een VIP-wissel uit.

Een update terugdraaien

Azure biedt flexibiliteit bij het beheren van services tijdens een update doordat u extra bewerkingen op een service kunt initiëren nadat de initiële updateaanvraag is geaccepteerd door de Azure Fabric Controller. Een terugdraaiactie kan alleen worden uitgevoerd wanneer een update (configuratiewijziging) of upgrade de status wordt uitgevoerd voor de implementatie. Een update of upgrade wordt beschouwd als in uitvoering zolang er ten minste één exemplaar van de service is dat nog niet is bijgewerkt naar de nieuwe versie. Als u wilt testen of terugdraaien is toegestaan, controleert u de waarde van de vlag RollbackAllowed, die wordt geretourneerd door de bewerkingen Implementatie ophalen en Eigenschappen van cloudservice ophalen , is ingesteld op true.

Het terugdraaien van een update die wordt uitgevoerd, heeft de volgende gevolgen voor de implementatie:

• Alle rolinstanties die nog niet zijn bijgewerkt of bijgewerkt naar de nieuwe versie, worden niet bijgewerkt of bijgewerkt, omdat op die exemplaren al de doelversie van de service wordt uitgevoerd.
• Alle rolinstanties die al zijn bijgewerkt of bijgewerkt naar de nieuwe versie van het servicepakketbestand (*.cspkg) of het serviceconfiguratiebestand (*.cscfg) (of beide bestanden), worden teruggezet naar de versie van vóór de upgrade van deze bestanden.

Dit wordt functioneel geleverd door de volgende functies:

• De update - of upgradebewerking terugdraaien , die kan worden aangeroepen bij een configuratie-update (geactiveerd door het aanroepen van Change Deployment Configuration) of een upgrade (geactiveerd door het aanroepen van Upgrade-implementatie) zolang er ten minste één exemplaar in de service is die nog niet is bijgewerkt naar de nieuwe versie.

• Het element Locked en het element RollbackAllowed, die worden geretourneerd als onderdeel van de antwoordtekst van de bewerkingen Get Deployment en Get Cloud Service Properties :

  1. Met het element Vergrendeld kunt u detecteren wanneer een mutatiebewerking kan worden aangeroepen voor een bepaalde implementatie.
  2. Met het element RollbackAllowed kunt u detecteren wanneer de update- of upgradebewerking voor terugdraaien kan worden aangeroepen voor een bepaalde implementatie.

  Als u een terugdraaiactie wilt uitvoeren, hoeft u niet zowel de elementen Locked als RollbackAllowed te controleren. Het volstaat om te bevestigen dat RollbackAllowed is ingesteld op true. Deze elementen worden alleen geretourneerd als deze methoden worden aangeroepen met behulp van de aanvraagheader die is ingesteld op 'x-ms-version: 2011-10-01' of een latere versie. Zie Versiebeheer voor servicebeheer voor meer informatie over versiebeheerheaders.

Er zijn enkele situaties waarin het terugdraaien van een update of upgrade niet wordt ondersteund. Dit zijn de volgende:

• Vermindering van lokale resources: als de update de lokale resources voor een rol verhoogt, staat het Azure-platform het terugdraaien niet toe.
• Quotumbeperkingen: als de update een bewerking voor omlaag schalen was, beschikt u mogelijk niet meer over voldoende rekenquotum om de terugdraaibewerking te voltooien. Aan elk Azure-abonnement is een quotum gekoppeld dat het maximum aantal kernen aangeeft dat kan worden gebruikt door alle gehoste services die deel uitmaken van dat abonnement. Als het terugdraaien van een bepaalde update uw abonnement boven het quotum plaatst, wordt het terugdraaien niet ingeschakeld.
• Racevoorwaarde: als de eerste update is voltooid, is terugdraaien niet mogelijk.

Een voorbeeld van wanneer het terugdraaien van een update nuttig kan zijn, is als u de upgrade-implementatiebewerking in de handmatige modus gebruikt om de snelheid te bepalen waarmee een grote in-place upgrade naar uw door Azure gehoste service wordt geïmplementeerd.

Tijdens de implementatie van de upgrade roept u Upgrade-implementatie aan in de handmatige modus en begint u upgradedomeinen te doorlopen. Als u tijdens het controleren van de upgrade op een bepaald moment ziet dat sommige rolinstanties in de eerste upgradedomeinen die u onderzoekt, niet meer reageren, kunt u de update- of upgradebewerking terugdraaien aanroepen voor de implementatie, waardoor de exemplaren die nog niet zijn bijgewerkt en terugdraaiexemplaren die zijn bijgewerkt naar het vorige servicepakket en de vorige configuratie ongewijzigd blijven.

Meerdere mutatiebewerkingen initiëren in een doorlopende implementatie

In sommige gevallen wilt u mogelijk meerdere gelijktijdige mutatiebewerkingen initiëren tijdens een lopende implementatie. U kunt bijvoorbeeld een service-update uitvoeren en terwijl die update wordt geïmplementeerd in uw service, wilt u een wijziging aanbrengen, bijvoorbeeld om de update terug te draaien, een andere update toe te passen of zelfs de implementatie te verwijderen. Een geval waarin dit nodig kan zijn, is als een service-upgrade buggy-code bevat, waardoor een bijgewerkte rolinstantie herhaaldelijk vastloopt. In dit geval kan de Azure Fabric Controller geen voortgang maken bij het toepassen van die upgrade omdat een onvoldoende aantal exemplaren in het bijgewerkte domein in orde is. Deze status wordt een vastgelopen implementatie genoemd. U kunt de implementatie ongedaan maken door de update terug te draaien of een nieuwe update toe te passen boven op de mislukte update.

Zodra de eerste aanvraag voor het bijwerken of upgraden van de service is ontvangen door de Azure Fabric Controller, kunt u de volgende mutatiebewerkingen starten. U hoeft dus niet te wachten tot de eerste bewerking is voltooid voordat u een andere mutatiebewerking kunt starten.

Het initiëren van een tweede updatebewerking terwijl de eerste update wordt uitgevoerd, wordt op dezelfde manier uitgevoerd als de terugdraaibewerking. Als de tweede update zich in de automatische modus bevindt, wordt het eerste upgradedomein onmiddellijk geüpgraded, waardoor exemplaren van meerdere upgradedomeinen op hetzelfde moment offline zijn.

De mutatiebewerkingen zijn als volgt: Implementatieconfiguratie wijzigen, Upgrade-implementatie, Update-implementatiestatus, Implementatie verwijderen en Update of Upgrade terugdraaien.

Twee bewerkingen, Get Deployment en Get Cloud Service Properties, retourneren de vlag Locked die kan worden onderzocht om te bepalen of een mutatiebewerking kan worden aangeroepen voor een bepaalde implementatie.

Als u de versie van deze methoden wilt aanroepen die de vergrendelde vlag retourneert, moet u aanvraagheader instellen op 'x-ms-version: 2011-10-01' of hoger. Zie Versiebeheer voor servicebeheer voor meer informatie over versiebeheerheaders.

Distributie van rollen over upgradedomeinen

Azure distribueert exemplaren van een rol gelijkmatig over een ingesteld aantal upgradedomeinen, die kunnen worden geconfigureerd als onderdeel van het servicedefinitiebestand (.csdef). Het maximum aantal upgradedomeinen is 20 en de standaardwaarde is 5. Zie Azure Service Definition Schema (.csdef-bestand) voor meer informatie over het wijzigen van het servicedefinitiebestand.

Als uw rol bijvoorbeeld tien exemplaren heeft, bevat elk upgradedomein standaard twee exemplaren. Als uw rol 14 exemplaren heeft, bevatten vier van de upgradedomeinen drie exemplaren en een vijfde domein twee.

Upgradedomeinen worden aangeduid met een op nul gebaseerde index: het eerste upgradedomein heeft de id 0 en het tweede upgradedomein heeft een id van 1, enzovoort.

In het volgende diagram ziet u hoe een service die twee rollen bevat, wordt gedistribueerd wanneer de service twee upgradedomeinen definieert. De service voert acht exemplaren van de webrol uit en negen exemplaren van de werkrol.

Volgende stappen

Cloud Services beheren
Cloud Services bewaken
Cloud Services configureren