Service Fabric-toepassingsupgrade

Een Azure Service Fabric-toepassing is een verzameling services. Tijdens een upgrade vergelijkt Service Fabric het nieuwe toepassingsmanifest met de vorige versie en bepaalt deze 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. Als u de huidige toepassingsparameters wilt 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 gedurende de upgrade. Tijdens de upgrade kan het cluster een combinatie van de oude en nieuwe versie 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. Bij een upgrade met meerdere fasen bestaat de eerste stap uit het upgraden naar een tussenliggende versie van de toepassing die compatibel is met de vorige versie. De tweede stap bestaat uit het bijwerken van de definitieve versie die de compatibiliteit met de pre-updateversie breekt, 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 aanpak wordt niet aanbevolen, omdat de service uitvalt en niet beschikbaar is op het moment van de upgrade. Bovendien 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, dat wil zeggen, als de upgrade slaagt, worden ze bijgewerkt naar de nieuwe versie; Als de upgrade mislukt en wordt teruggedraaid, worden ze teruggezet naar de oude versie.

Statuscontroles tijdens upgrades

Voor een upgrade moet statusbeleid worden ingesteld (of standaardwaarden kunnen worden gebruikt). Een upgrade wordt geslaagd genoemd wanneer alle updatedomeinen binnen de opgegeven time-outs worden bijgewerkt en wanneer alle updatedomeinen als in orde worden beschouwd. Een goed updatedomein betekent dat het updatedomein alle statuscontroles heeft doorstaan 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. Er worden dus geen servicespecifieke tests uitgevoerd. Uw service kan bijvoorbeeld een doorvoervereiste hebben, 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 tijdens een upgrade plaatsvinden, omvatten tests om te controleren 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 aan de hand van de status die in de toepassing wordt gerapporteerd. Ook wordt op deze manier de status van alle services voor de toepassing geëvalueerd. Service Fabric evalueert de status van de toepassingsservices verder door de status van de onderliggende elementen te aggregeren, 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 het upgraden van de toepassing is de bewaakte modus. Dit is de veelgebruikte modus. De bewaakte modus voert de upgrade uit op één updatedomein en als alle statuscontroles slagen (volgens het opgegeven beleid), wordt automatisch naar het volgende updatedomein verplaatst. Als statuscontroles mislukken en/of time-outs zijn bereikt, wordt de upgrade teruggedraaid voor het updatedomein of wordt de modus gewijzigd in niet-bewaakte handmatig. 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 in een updatedomein om de upgrade op het volgende updatedomein te starten. Er worden geen Service Fabric-statuscontroles uitgevoerd. De beheerder voert de status- of statuscontroles uit voordat de upgrade wordt gestart in het domein van de volgende update.

Standaardservices upgraden

Sommige standaardserviceparameters die zijn gedefinieerd in het toepassingsmanifest , kunnen ook worden bijgewerkt als onderdeel van een toepassingsupgrade. Alleen de serviceparameters die ondersteuning bieden voor het wijzigen 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 in het cluster bestaan, worden gemaakt.
2. Standaardservices die aanwezig zijn 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 toepassingsupgrade 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 de status van die service en kan niet ongedaan worden gemaakt.

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

Tip

De instelling EnableDefaultServicesUpgrade-clusterconfiguratie moet waar zijn om de 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 voor een van de toepassingsexemplaren niet kan upgraden. Als toepassing 1 of toepassing 2 bijvoorbeeld beide hun certificaat 1 willen upgraden naar certificaat 2. Wanneer de upgrade wordt uitgevoerd, heeft Service Fabric mogelijk de certificaat 1-registratie opgeschoond met http.sys, ook al gebruikt de andere toepassing deze nog. Om dit te voorkomen, detecteert Service Fabric dat er al een ander toepassingsexemplaren is 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 nodig hebt, moet u ervoor zorgen dat de services op verschillende computers worden geplaatst met plaatsingsbeperkingen. Of overweeg het gebruik van dynamische Service Fabric-poorten, indien mogelijk, voor elke service in elk toepassingsexemplaren.

Als u ziet dat een upgrade mislukt met https, krijgt u de foutmelding 'De Windows HTTP Server-API biedt geen ondersteuning voor meerdere certificaten voor toepassingen die een poort delen'.

Stroomdiagram voor toepassingsupgrade

Het stroomdiagram dat volgt op deze alinea kan u inzicht bieden in het upgradeproces van een Service Fabric-toepassing. De stroom beschrijft met name hoe de time-outs, waaronder HealthCheckStableDuration, HealthCheckRetryTimeout en UpgradeHealthCheckInterval, helpen bepalen wanneer de upgrade in één updatedomein als geslaagd of mislukt wordt beschouwd.

Volgende stappen

Uw toepassing upgraden met Visual Studio begeleidt u bij het uitvoeren van een toepassingsupgrade met behulp van Visual Studio.

Uw toepassing upgraden met PowerShell helpt u bij het uitvoeren van een toepassingsupgrade met behulp van PowerShell.

Bepaal hoe uw toepassing wordt bijgewerkt met behulp van upgradeparameters.

Maak uw toepassingsupgrades compatibel door te leren hoe u gegevensserialisatie gebruikt.

Raadpleeg Geavanceerde onderwerpen voor meer informatie over het gebruik van geavanceerde functionaliteit tijdens het upgraden van uw toepassing.

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