Een Azure-cloudservice bijwerken (klassiek)

Belangrijk

Cloud Services (klassiek) is nu afgeschaft voor nieuwe klanten en wordt op 31 augustus 2024 buiten gebruik gesteld voor alle klanten. Nieuwe implementaties moeten gebruikmaken van het nieuwe op Azure Resource Manager gebaseerde implementatiemodel Azure Cloud Services (uitgebreide ondersteuning).

Het proces voor het bijwerken van een cloudservice, inclusief de rollen en het gastbesturingssystem, voert drie stappen uit. 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 incrementeel bij te werken naar de nieuwe versie of het gastbesturingssysteem, terwijl uw beschikbaarheid behouden blijft. In dit artikel worden de details van deze laatste stap besproken: de rolling upgrade.

Een Azure-service bijwerken

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

Het standaardaantal upgradedomeinen is 5. U kunt een ander aantal upgradedomeinen opgeven door het kenmerk upgradeDomainCount op te geven in het definitiebestand van de service (.csdef). Zie het 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, worden in Azure sets met rolinstanties bijgewerkt op basis van het upgradedomein waartoe ze behoren. Azure werkt alle exemplaren in een bepaald upgradedomein bij: stop ze, werk ze bij, breng ze weer online naar het volgende domein. Door alleen de exemplaren die worden uitgevoerd in het huidige upgradedomein te stoppen, zorgt Azure ervoor dat een update plaatsvindt met de minst mogelijke impact op de actieve service. Zie Hoe de update verderop in dit artikel wordt uitgevoerd voor meer informatie.

Notitie

Hoewel de termen bijwerken en upgraden iets anders betekenen in de context van Azure, kunnen ze door elkaar worden gebruikt voor de processen en beschrijvingen van de functies in dit document.

Uw service moet ten minste twee exemplaren van een rol definiëren die ter plaatse moeten worden bijgewerkt zonder uitvaltijd. 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 artikel worden de volgende informatie over Azure-updates behandeld:

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

Toegestane servicewijzigingen tijdens een update

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

Wijzigingen die zijn toegestaan voor hosting, services en rollen	In-place update	Gefaseerd (VIP-wissel)	Verwijderen en opnieuw implementeren
Besturingssysteemversie	Ja	Ja	Ja
.NET-vertrouwensniveau	Ja	Ja	Ja
Grootte van virtuele machine1	Ja2	Ja	Ja
Instellingen voor lokale opslag	Alleen 2 verhogen	Ja	Ja
Rollen toevoegen aan of verwijderen uit een service	Ja	Ja	Ja
Aantal exemplaren van een bepaalde rol	Ja	Ja	Ja
Aantal of het type eindpunten voor een service	Ja2	Nr.	Ja
Namen en waarden van configuratie-instellingen	Ja	Ja	Ja
Waarden (maar geen namen) van configuratie-instellingen	Ja	Ja	Ja
Nieuwe certificaten toevoegen	Ja	Ja	Ja
Bestaande certificaten wijzigen	Ja	Ja	Ja
Nieuwe code implementeren	Ja	Ja	Ja

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

² Vereist Azure SDK 1.5 of nieuwere versies.

Waarschuwing

Als u de grootte van de virtuele machine wijzigt, worden lokale gegevens vernietigd.

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 verlagen.

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 behoren tot 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 wordt voortgezet als u alle rollen in de service bijwerken:

In dit volgende diagram ziet u hoe de update wordt uitgevoerd 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 beschouwt alleen instanties in de nieuwste versie (dat wil gezegd, exemplaren van UD's die al zijn doorlopen). Er wordt gecontroleerd of voor elke rol een minimum aantal rolinstanties een bevredigende terminalstatus heeft bereikt.

Time-out voor starten van rolinstantie

De infrastructuurcontroller wacht 30 minuten totdat elke rolinstantie 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 bijwerken van één exemplaar naar meerdere exemplaren, worden uw services uitgeschakeld terwijl de upgrade wordt uitgevoerd. De service level agreement die de beschikbaarheid van de service garandeert, is alleen van toepassing op services die met meer dan één exemplaar zijn geïmplementeerd. In de volgende lijst wordt beschreven hoe elk upgradescenario van de Azure-service van invloed is op de gegevens op elk station:

Scenario	C-station	D-station	E-station
Virtuele machine (VM) opnieuw opstarten	Geconserveerd	Geconserveerd	Geconserveerd
Portal opnieuw opstarten	Geconserveerd	Geconserveerd	Vernietigd
Installatiekopie van portal	Geconserveerd	Vernietigd	Vernietigd
In-Place Upgrade	Geconserveerd	Geconserveerd	Vernietigd
Knooppuntmigratie	Vernietigd	Vernietigd	Vernietigd

In de voorgaande lijst vertegenwoordigt het station E: de hoofdschijf van de rol en mag niet in code worden vastgelegd. Gebruik in plaats daarvan de omgevingsvariabele %RoleRoot% om het station weer te geven.

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

Terugdraaien van een update

Azure biedt flexibiliteit bij het beheren van services tijdens een update door u meer bewerkingen voor een service te laten initiëren, nadat de Azure Fabric-controller de eerste updateaanvraag heeft geaccepteerd. Een terugdraaiactie kan alleen worden uitgevoerd wanneer een update (configuratiewijziging) of upgrade in de voortgangsstatus van de implementatie is. Een update of upgrade wordt als in behandeling beschouwd zolang er ten minste één exemplaar van de service is dat niet wordt bijgewerkt naar de nieuwe versie. Als u wilt testen of een terugdraaiactie is toegestaan, controleert u of de waarde van de vlag RollbackAllowed is ingesteld op true. Get Deployment and Get Cloud Service Properties operations return the RollbackAllowed flag for your reference.

Notitie

Het is alleen zinvol om terugdraaien aan te roepen voor een in-place update of upgrade, omdat VIP-wisselupgrades betrekking hebben op het vervangen van één volledig actief exemplaar van uw service door een andere.

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

• Rolinstanties die niet-bijgewerkt of niet-bijgewerkt blijven naar de nieuwe versie, worden niet bijgewerkt of bijgewerkt, omdat deze exemplaren al de doelversie van de service uitvoeren.
• Alle rolinstanties die al zijn bijgewerkt of bijgewerkt naar de nieuwe versie van het servicepakket -bestand (*.cspkg) of het serviceconfiguratiebestand (*.cscfg) (of beide bestanden) worden teruggezet naar de voorlopige versie van deze bestanden.

De volgende functies bieden deze functionaliteit:

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

• Het vergrendelde element 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 vergrendelde element 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 vergrendelde als de elementen 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 nieuwere versie. Zie de versiebeheer van het klassieke implementatiemodel voor meer informatie over versiebeheerheaders.

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

• 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 omlaagschaalbewerking was, beschikt u mogelijk niet meer over voldoende rekenquotum om de terugdraaibewerking te voltooien. Aan elk Azure-abonnement is een quotum gekoppeld. Het quotum geeft het maximum aantal kernen op dat alle gehoste services van dat abonnement kunnen gebruiken. Als u een terugdraaiactie van een bepaalde update uitvoert, wordt uw abonnement boven het quotum geplaatst, dan wordt die terugdraaiactie niet ingeschakeld.
• Racevoorwaarde: als de initiële update is voltooid, is een terugdraaiactie niet mogelijk.

Een voorbeeld van wanneer het terugdraaien van een update nuttig kan zijn, is als u de bewerking Upgrade-implementatie in de handmatige modus gebruikt om de snelheid te bepalen waarmee een belangrijke in-place upgrade wordt uitgerold naar uw gehoste Azure-service.

Tijdens de implementatie van de upgrade roept u Upgrade-implementatie aan in de handmatige modus en begint u upgradedomeinen te doorlopen. Als u de upgrade op een bepaald moment bewaakt, ziet u dat sommige rolinstanties in de eerste upgradedomeinen niet reageren, kunt u de update- of upgradebewerking voor terugdraaien aanroepen voor de implementatie. Met deze bewerking blijven de instanties ongewijzigd die niet-bijgewerkt blijven en worden bijgewerkte exemplaren teruggedraaid naar het vorige servicepakket en de vorige configuratie.

Meerdere mutatiebewerkingen initiëren voor een doorlopende implementatie

In sommige gevallen wilt u mogelijk meerdere gelijktijdige mutatiebewerkingen initiëren voor een doorlopende implementatie. U kunt bijvoorbeeld een service-update uitvoeren en, terwijl de update in uw service wordt geïmplementeerd, een aantal wijzigingen aanbrengen, zoals het terugdraaien van de update, het toepassen van een andere update of zelfs het verwijderen van de implementatie. Een geval waarin dit scenario zich kan voordoen, is als een service-upgrade buggycode bevat die ervoor zorgt dat een bijgewerkte rolinstantie herhaaldelijk vastloopt. In dit geval kan de Azure Fabric Controller geen voortgang boeken 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 loszetten door de update terug te draaien of een nieuwe update boven op de mislukte update toe te passen.

Zodra de Azure Fabric-controller de eerste aanvraag ontvangt om de service bij te werken of bij te werken, kunt u volgende dempingsbewerkingen starten. Dat wil gezegd, u hoeft niet te wachten totdat 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 afgespeeld als de terugdraaibewerking. Als de tweede update zich in de automatische modus bevindt, wordt het eerste upgradedomein onmiddellijk bijgewerkt, wat mogelijk leidt tot exemplaren van meerdere upgradedomeinen die tegelijkertijd 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 vergrendelde vlag. U kunt de vlag Vergrendeld onderzoeken om te bepalen of u een mutatiebewerking voor een bepaalde implementatie kunt aanroepen.

Als u de versie van deze methoden wilt aanroepen die de vlag Vergrendeld retourneren, moet u de aanvraagheader instellen op 'x-ms-version: 2011-10-01' of een nieuwer. Zie de versiebeheer van het klassieke implementatiemodel voor meer informatie over versiebeheerheaders.

Distributie van rollen tussen upgradedomeinen

Azure distribueert exemplaren van een rol gelijkmatig over een bepaald 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 File) voor meer informatie over het wijzigen van het servicedefinitiebestand.

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

Upgradedomeinen worden geïdentificeerd met een index op basis van nul: het eerste upgradedomein heeft een id van 0 en het tweede upgradedomein heeft een id van 1, enzovoort.

In het volgende diagram ziet u hoe de rollen in een service met twee rollen worden gedistribueerd wanneer de service twee upgradedomeinen definieert. De service voert acht exemplaren van de webrol en negen exemplaren van de werkrol uit.

Notitie

Houd er rekening mee dat Azure bepaalt hoe exemplaren worden toegewezen in upgradedomeinen. Het is niet mogelijk om op te geven welke exemplaren worden toegewezen aan welk domein.

Volgende stappen

Cloud Services beheren
Cloud Services bewaken
Cloud Services configureren