Upgrade van Service Fabric-toepassing uitvoeren

Een Azure Service Fabric-toepassing is een verzameling services. Tijdens een upgrade vergelijkt Service Fabric het nieuwe toepassingsmanifest met de vorige versie en bepaalt welke services in de toepassing updates vereisen. Service Fabric vergelijkt de versie in de servicemanifesten met de versie in de vorige versie. Als de serviceversie niet is gewijzigd, wordt die service niet bijgewerkt.

Notitie

ApplicationParameters blijven niet behouden tijdens een toepassingsupgrade. Om de huidige toepassingsparameters te behouden, moet de gebruiker eerst de parameters ophalen en deze doorgeven aan de upgrade-API-aanroep, zoals hieronder:

$myApplication = Get-ServiceFabricApplication -ApplicationName fabric:/myApplication
$appParamCollection = $myApplication.ApplicationParameters

$applicationParameterMap = @{}
foreach ($pair in $appParamCollection)
{
    $applicationParameterMap.Add($pair.Name, $pair.Value);
}

Start-ServiceFabricApplicationUpgrade -ApplicationName fabric:/myApplication -ApplicationTypeVersion 2.0.0 -ApplicationParameter $applicationParameterMap -Monitored -FailureAction Rollback

Overzicht van rolling upgrades

In een rolling toepassingsupgrade wordt de upgrade in fasen uitgevoerd. In elke fase wordt de upgrade toegepast op een subset van knooppunten in het cluster, een updatedomein genoemd. Als gevolg hiervan blijft de toepassing beschikbaar tijdens de upgrade. Tijdens de upgrade kan het cluster een combinatie van de oude en nieuwe versies bevatten.

Daarom moeten de twee versies voorwaarts en achterwaarts compatibel zijn. Als ze niet compatibel zijn, is de toepassingsbeheerder verantwoordelijk voor het faseren van een upgrade met meerdere fasen om de beschikbaarheid te behouden. In een upgrade met meerdere fasen voert u een upgrade uit naar een tussenliggende versie van de toepassing die compatibel is met de vorige versie. De tweede stap is het upgraden van de uiteindelijke versie die de compatibiliteit met de versie vóór de update onderbreekt, maar compatibel is met de tussenliggende versie.

Updatedomeinen worden opgegeven in het clustermanifest wanneer u het cluster configureert. Updatedomeinen ontvangen geen updates in een bepaalde volgorde. Een updatedomein is een logische implementatie-eenheid voor een toepassing. Met updatedomeinen kunnen de services tijdens een upgrade op hoge beschikbaarheid blijven.

Niet-rolling upgrades zijn mogelijk als de upgrade wordt toegepast op alle knooppunten in het cluster, wat het geval is wanneer de toepassing slechts één updatedomein heeft. Deze methode wordt niet aanbevolen, omdat de service uitvalt en niet beschikbaar is op het moment van de upgrade. Daarnaast biedt Azure geen garanties wanneer een cluster is ingesteld met slechts één updatedomein.

Nadat de upgrade is voltooid, blijven alle services en replica's (exemplaren) in dezelfde versie, dus als de upgrade slaagt, worden ze bijgewerkt naar de nieuwe versie; als de upgrade mislukt en teruggedraaid wordt, worden ze teruggedraaid naar de oude versie.

Statuscontroles tijdens upgrades

Voor een upgrade moeten statusbeleidsregels worden ingesteld (of standaardwaarden kunnen worden gebruikt). Een upgrade krijgt de term geslaagd wanneer alle updatedomeinen worden bijgewerkt binnen de opgegeven time-outs en wanneer alle updatedomeinen als in orde worden beschouwd. Een goed updatedomein betekent dat het updatedomein alle statuscontroles heeft doorgegeven die zijn opgegeven in het statusbeleid. Een statusbeleid kan bijvoorbeeld vereisen dat alle services binnen een toepassingsexemplaren in orde moeten zijn, omdat de status wordt gedefinieerd door Service Fabric.

Statusbeleid en controles tijdens de upgrade door Service Fabric zijn service- en toepassingsneutraal. Dat wil gezegd, er worden geen servicespecifieke tests uitgevoerd. Uw service heeft bijvoorbeeld mogelijk een doorvoervereiste, maar Service Fabric beschikt niet over de informatie om de doorvoer te controleren. Raadpleeg de statusartikelen voor de controles die worden uitgevoerd. De controles die plaatsvinden tijdens een upgrade, bevatten tests voor of het toepassingspakket correct is gekopieerd, of het exemplaar is gestart, enzovoort.

De toepassingsstatus is een aggregatie van de onderliggende entiteiten van de toepassing. Kortom, Service Fabric evalueert de status van de toepassing via de status die op de toepassing wordt gerapporteerd. Het evalueert ook de status van alle services voor de toepassing op deze manier. Service Fabric evalueert de status van de toepassingsservices verder door de status van hun kinderen samen te stellen, zoals de servicereplica. Zodra aan het statusbeleid van de toepassing is voldaan, kan de upgrade worden voortgezet. Als het statusbeleid wordt geschonden, mislukt de upgrade van de toepassing.

Upgrademodi

De modus die we aanbevelen voor toepassingsupgrade is de bewaakte modus. Dit is de veelgebruikte modus. De bewaakte modus voert de upgrade uit op één updatedomein en als alle statuscontroles worden doorgegeven (volgens het opgegeven beleid), gaat u automatisch naar het volgende updatedomein. Als statuscontroles mislukken en/of time-outs worden bereikt, wordt de upgrade teruggedraaid voor het updatedomein of wordt de modus gewijzigd in handmatige controle. U kunt de upgrade configureren om een van deze twee modi te kiezen voor mislukte upgrades.

Niet-bewaakte handmatige modus vereist handmatige interventie na elke upgrade op een updatedomein om de upgrade te starten op het volgende updatedomein. Er worden geen Service Fabric-statuscontroles uitgevoerd. De beheerder voert de status- of statuscontroles uit voordat de upgrade in het volgende updatedomein wordt gestart.

Standaardservices upgraden

Sommige standaardserviceparameters die zijn gedefinieerd in het toepassingsmanifest , kunnen ook worden bijgewerkt als onderdeel van een toepassingsupgrade. Alleen de serviceparameters die worden gewijzigd via Update-ServiceFabricService kunnen worden gewijzigd als onderdeel van een upgrade. Het gedrag van het wijzigen van standaardservices tijdens de upgrade van de toepassing is als volgt:

1. Standaardservices in het nieuwe toepassingsmanifest die nog niet aanwezig zijn in het cluster, worden gemaakt.
2. Standaardservices die bestaan in zowel de vorige als de nieuwe toepassingsmanifesten, worden bijgewerkt. De parameters van de standaardservice in het nieuwe toepassingsmanifest overschrijven de parameters van de bestaande service. De upgrade van de toepassing wordt automatisch teruggedraaid als het bijwerken van een standaardservice mislukt.
3. Standaardservices die niet aanwezig zijn in het nieuwe toepassingsmanifest, worden verwijderd als ze in het cluster aanwezig zijn. Houd er rekening mee dat het verwijderen van een standaardservice resulteert in het verwijderen van alle statussen van die service en niet ongedaan kan worden gemaakt.

Wanneer een toepassingsupgrade wordt teruggedraaid, worden de standaardserviceparameters teruggezet naar hun oude waarden voordat de upgrade werd gestart, maar kunnen verwijderde services niet opnieuw worden gemaakt met hun oude status.

Tip

De configuratie-instelling EnableDefaultServicesUpgrade-cluster moet waar zijn om regels 2 en 3) hierboven in te schakelen (standaardservice-update en -verwijdering). Deze functie wordt ondersteund vanaf Service Fabric versie 5.5.

Meerdere toepassingen upgraden met HTTPS-eindpunten

U moet ervoor zorgen dat u niet dezelfde poort gebruikt voor verschillende exemplaren van dezelfde toepassing wanneer u HTTPS gebruikt. De reden hiervoor is dat Service Fabric het certificaat niet kan upgraden voor een van de toepassingsexemplaren. Als toepassing 1 of toepassing 2 bijvoorbeeld beide hun certificaat 1 willen upgraden naar certificaat 2. Wanneer de upgrade plaatsvindt, heeft Service Fabric de registratie van certificaat 1 mogelijk opgeschoond met http.sys, zelfs als de andere toepassing deze nog steeds gebruikt. Om dit te voorkomen, detecteert Service Fabric dat er al een ander toepassingsexemplaren zijn geregistreerd op de poort met het certificaat (vanwege http.sys) en mislukt de bewerking.

Service Fabric biedt daarom geen ondersteuning voor het upgraden van twee verschillende services met behulp van dezelfde poort in verschillende toepassingsexemplaren. Met andere woorden, u kunt hetzelfde certificaat niet gebruiken voor verschillende services op dezelfde poort. Als u een gedeeld certificaat op dezelfde poort moet hebben, moet u ervoor zorgen dat de services op verschillende computers met plaatsingsbeperkingen worden geplaatst. Of overweeg indien mogelijk dynamische Service Fabric-poorten te gebruiken voor elke service in elk toepassingsexemplaren.

Als er een upgrade mislukt met https, wordt er een foutbericht weergegeven met de melding 'De Windows HTTP Server-API biedt geen ondersteuning voor meerdere certificaten voor toepassingen die een poort delen'.

Stroomdiagram voor toepassingsupgrade

Het stroomdiagram na deze alinea kan u helpen het upgradeproces van een Service Fabric-toepassing te begrijpen. In het bijzonder wordt in de stroom beschreven hoe de time-outs, waaronder HealthCheckStableDuration, HealthCheckRetryTimeout en UpgradeHealthCheckInterval, helpen bepalen wanneer de upgrade in één updatedomein wordt beschouwd als geslaagd of mislukt.

Volgende stappen

Als u uw toepassing bijwerken met Visual Studio , wordt u begeleid bij het uitvoeren van een toepassingsupgrade met behulp van Visual Studio.

Als u uw toepassing bijwerkt met Behulp van PowerShell , wordt u begeleid bij het uitvoeren van een toepassingsupgrade met behulp van PowerShell.

Bepalen hoe uw toepassing wordt bijgewerkt met behulp van upgradeparameters.

Zorg ervoor dat uw toepassing compatibel is door te leren hoe u gegevensserialisatie gebruikt.

Meer informatie over het gebruik van geavanceerde functionaliteit tijdens het upgraden van uw toepassing door te verwijzen naar Geavanceerde onderwerpen.

Los veelvoorkomende problemen in toepassingsupgrades op door te verwijzen naar de stappen in Het oplossen van problemen met toepassingsupgrades.