Problemen met toepassingsupgrades oplossen
In dit artikel worden enkele veelvoorkomende problemen behandeld met betrekking tot het upgraden van een Azure Service Fabric-toepassing en hoe u deze kunt oplossen.
Problemen met een mislukte toepassingsupgrade oplossen
Wanneer een upgrade mislukt, bevat de uitvoer van de opdracht Get-ServiceFabricApplicationUpgrade aanvullende informatie voor het opsporen van fouten. De volgende lijst geeft aan hoe de aanvullende informatie kan worden gebruikt:
- Identificeer het fouttype.
- Identificeer de reden van de fout.
- Isoleer een of meer mislukte onderdelen voor verder onderzoek.
Deze informatie is beschikbaar wanneer Service Fabric de fout detecteert, ongeacht of FailureAction de upgrade terugdraait of onderbreekt.
Het fouttype identificeren
In de uitvoer van Get-ServiceFabricApplicationUpgrade identificeert FailureTimestampUtc de tijdstempel (in UTC) waarop een upgradefout is gedetecteerd door Service Fabric en FailureAction is geactiveerd. FailureReason identificeert een van de drie mogelijke oorzaken op hoog niveau van de fout:
- UpgradeDomainTimeout - Geeft aan dat een bepaald upgradedomein te lang duurde om te voltooien en UpgradeDomainTimeout is verlopen.
- OverallUpgradeTimeout - Geeft aan dat de algehele upgrade te lang duurde om te voltooien en UpgradeTimeout is verlopen.
- HealthCheck - Geeft aan dat na het upgraden van een updatedomein de toepassing beschadigd bleef volgens het opgegeven statusbeleid en HealthCheckRetryTimeout is verlopen.
Deze vermeldingen worden alleen weergegeven in de uitvoer wanneer de upgrade mislukt en wordt teruggezet. Meer informatie wordt weergegeven, afhankelijk van het type fout.
Time-outs van upgrades onderzoeken
Time-outfouten bij de upgrade worden meestal veroorzaakt door problemen met de beschikbaarheid van de service. De uitvoer na deze alinea is gebruikelijk voor upgrades waarbij servicereplica's of exemplaren niet kunnen worden gestart in de nieuwe codeversie. Het veld UpgradeDomainProgressAtFailure legt een momentopname vast van een upgrade die in behandeling is op het moment van de fout.
Get-ServiceFabricApplicationUpgrade fabric:/DemoApp
ApplicationName : fabric:/DemoApp
ApplicationTypeName : DemoAppType
TargetApplicationTypeVersion : v2
ApplicationParameters : {}
StartTimestampUtc : 4/14/2015 9:26:38 PM
FailureTimestampUtc : 4/14/2015 9:27:05 PM
FailureReason : UpgradeDomainTimeout
UpgradeDomainProgressAtFailure : MYUD1
NodeName : Node4
UpgradePhase : PostUpgradeSafetyCheck
PendingSafetyChecks :
WaitForPrimaryPlacement - PartitionId: 744c8d9f-1d26-417e-a60e-cd48f5c098f0
NodeName : Node1
UpgradePhase : PostUpgradeSafetyCheck
PendingSafetyChecks :
WaitForPrimaryPlacement - PartitionId: 4b43f4d8-b26b-424e-9307-7a7a62e79750
UpgradeState : RollingBackCompleted
UpgradeDuration : 00:00:46
CurrentUpgradeDomainDuration : 00:00:00
NextUpgradeDomain :
UpgradeDomainsStatus : { "MYUD1" = "Completed";
"MYUD2" = "Completed";
"MYUD3" = "Completed" }
UpgradeKind : Rolling
RollingUpgradeMode : UnmonitoredAuto
ForceRestart : False
UpgradeReplicaSetCheckTimeout : 00:00:00
In dit voorbeeld is de upgrade mislukt bij upgradedomein MYUD1 en twee partities (744c8d9f-1d26-417e-a60e-cd48f5c098f0 en 4b43f4d8-b26b-424e-9307-7a7a62e79750) vastgelopen. De partities zijn vastgelopen omdat de runtime geen primaire replica's (WaitForPrimaryPlacement) kan plaatsen op doelknooppunten Node1 en Node4.
De opdracht Get-ServiceFabricNode kan worden gebruikt om te controleren of deze twee knooppunten zich in het upgradedomein MYUD1 bevinden. De UpgradePhase zegt PostUpgradeSafetyCheck, wat betekent dat deze veiligheidscontroles plaatsvinden nadat alle knooppunten in het upgradedomein de upgrade hebben voltooid. Al deze informatie verwijst naar een mogelijk probleem met de nieuwe versie van de toepassingscode. De meest voorkomende problemen zijn servicefouten in het openen of promoveren naar primaire codepaden.
Een UpgradePhase van PreUpgradeSafetyCheck betekent dat er problemen zijn met het voorbereiden van het upgradedomein voordat het werd uitgevoerd. De meest voorkomende problemen in dit geval zijn servicefouten in het sluiten of degraderen van primaire codepaden.
De huidige UpgradeState is RollingBackCompleted, dus de oorspronkelijke upgrade moet zijn uitgevoerd met een rollback FailureAction, waardoor de upgrade automatisch wordt teruggedraaid na een fout. Als de oorspronkelijke upgrade is uitgevoerd met een handmatige FailureAction, is de upgrade in plaats daarvan in een onderbroken status om live foutopsporing van de toepassing toe te staan.
In zeldzame gevallen is het veld UpgradeDomainProgressAtFailure mogelijk leeg als er een time-out optreedt voor de algehele upgrade, net zoals het systeem alle werkzaamheden voor het huidige upgradedomein voltooit. Als dit gebeurt, verhoogt u de parameterwaarden upgradeTimeout en UpgradeDomainTimeout en voert u de upgrade opnieuw uit.
Statuscontrolefouten onderzoeken
Statuscontrolefouten kunnen worden geactiveerd door verschillende problemen die kunnen optreden nadat alle knooppunten in een upgradedomein zijn bijgewerkt en alle veiligheidscontroles hebben doorgegeven. De uitvoer na deze alinea is gebruikelijk voor een upgradefout vanwege mislukte statuscontroles. Het veld UnhealthyEvaluations legt een momentopname vast van statuscontroles die zijn mislukt op het moment van de upgrade volgens het opgegeven statusbeleid.
Get-ServiceFabricApplicationUpgrade fabric:/DemoApp
ApplicationName : fabric:/DemoApp
ApplicationTypeName : DemoAppType
TargetApplicationTypeVersion : v4
ApplicationParameters : {}
StartTimestampUtc : 4/24/2015 2:42:31 AM
UpgradeState : RollingForwardPending
UpgradeDuration : 00:00:27
CurrentUpgradeDomainDuration : 00:00:27
NextUpgradeDomain : MYUD2
UpgradeDomainsStatus : { "MYUD1" = "Completed";
"MYUD2" = "Pending";
"MYUD3" = "Pending" }
UnhealthyEvaluations :
Unhealthy services: 50% (2/4), ServiceType='PersistedServiceType', MaxPercentUnhealthyServices=0%.
Unhealthy service: ServiceName='fabric:/DemoApp/Svc3', AggregatedHealthState='Error'.
Unhealthy partitions: 100% (1/1), MaxPercentUnhealthyPartitionsPerService=0%.
Unhealthy partition: PartitionId='3a9911f6-a2e5-452d-89a8-09271e7e49a8', AggregatedHealthState='Error'.
Error event: SourceId='Replica', Property='InjectedFault'.
Unhealthy service: ServiceName='fabric:/DemoApp/Svc2', AggregatedHealthState='Error'.
Unhealthy partitions: 100% (1/1), MaxPercentUnhealthyPartitionsPerService=0%.
Unhealthy partition: PartitionId='744c8d9f-1d26-417e-a60e-cd48f5c098f0', AggregatedHealthState='Error'.
Error event: SourceId='Replica', Property='InjectedFault'.
UpgradeKind : Rolling
RollingUpgradeMode : Monitored
FailureAction : Manual
ForceRestart : False
UpgradeReplicaSetCheckTimeout : 49710.06:28:15
HealthCheckWaitDuration : 00:00:00
HealthCheckStableDuration : 00:00:10
HealthCheckRetryTimeout : 00:00:10
UpgradeDomainTimeout : 10675199.02:48:05.4775807
UpgradeTimeout : 10675199.02:48:05.4775807
ConsiderWarningAsError :
MaxPercentUnhealthyPartitionsPerService :
MaxPercentUnhealthyReplicasPerPartition :
MaxPercentUnhealthyServices :
MaxPercentUnhealthyDeployedApplications :
ServiceTypeHealthPolicyMap :
Voor het onderzoeken van statuscontrolefouten is eerst een goed begrip van het Service Fabric-statusmodel vereist. Maar zelfs zonder zo'n diepgaand begrip kunnen we zien dat twee services beschadigd zijn: fabric:/DemoApp/Svc3 en fabric:/DemoApp/Svc2, samen met de foutstatusrapporten ('GeïnjecteerdFault' in dit geval). In dit voorbeeld zijn twee van de vier services niet in orde, wat lager is dan het standaarddoel van 0% beschadigd (MaxPercentUnhealthyServices).
De upgrade is onderbroken wanneer deze mislukt door een FailureAction van handmatig op te geven bij het starten van de upgrade. Met deze modus kunnen we het livesysteem in de status Mislukt onderzoeken voordat we verdere actie ondernemen.
Herstellen van een onderbroken upgrade
Met een rollback FailureAction is er geen herstel nodig omdat de upgrade automatisch wordt teruggedraaid bij een fout. Met een handmatige FailureAction zijn er verschillende herstelopties:
- een terugdraaiactie activeren
- Doorloop de rest van de upgrade handmatig
- De bewaakte upgrade hervatten
De opdracht Start-ServiceFabricApplicationRollback kan op elk gewenst moment worden gebruikt om de toepassing terug te draaien. Zodra de opdracht is geretourneerd, is de terugdraaiaanvraag geregistreerd in het systeem en wordt kort daarna gestart.
De opdracht Resume-ServiceFabricApplicationUpgrade kan worden gebruikt om de rest van de upgrade handmatig te doorlopen, één upgradedomein tegelijk. In deze modus worden alleen veiligheidscontroles uitgevoerd door het systeem. Er worden geen statuscontroles meer uitgevoerd. Deze opdracht kan alleen worden gebruikt wanneer de UpgradeState RollingForwardPending weergeeft. Dit betekent dat het huidige upgradedomein is voltooid, maar de volgende is niet gestart (in behandeling).
De opdracht Update-ServiceFabricApplicationUpgrade kan worden gebruikt om de bewaakte upgrade te hervatten met zowel veiligheids- als gezondheidscontroles die worden uitgevoerd.
Update-ServiceFabricApplicationUpgrade fabric:/DemoApp -UpgradeMode Monitored
UpgradeMode : Monitored
ForceRestart :
UpgradeReplicaSetCheckTimeout :
FailureAction :
HealthCheckWaitDuration :
HealthCheckStableDuration :
HealthCheckRetryTimeout :
UpgradeTimeout :
UpgradeDomainTimeout :
ConsiderWarningAsError :
MaxPercentUnhealthyPartitionsPerService :
MaxPercentUnhealthyReplicasPerPartition :
MaxPercentUnhealthyServices :
MaxPercentUnhealthyDeployedApplications :
ServiceTypeHealthPolicyMap :
De upgrade gaat verder vanuit het upgradedomein waar het voor het laatst is onderbroken en gebruik dezelfde upgradeparameters en statusbeleidsregels als voorheen. Indien nodig kunnen de upgradeparameters en statusbeleidsregels die in de voorgaande uitvoer worden weergegeven, worden gewijzigd in dezelfde opdracht wanneer de upgrade wordt hervat. In dit voorbeeld is de upgrade hervat in de bewaakte modus, waarbij de parameters en het statusbeleid ongewijzigd zijn gebleven.
Aanvullende probleemoplossing
Service Fabric volgt niet het opgegeven statusbeleid
Mogelijke oorzaak 1:
Service Fabric vertaalt alle percentages in werkelijke aantallen entiteiten (bijvoorbeeld replica's, partities en services) voor statusevaluatie en rondt altijd af op hele entiteiten. Als het maximum maxPercentUnhealthyReplicasPerPartition bijvoorbeeld 21% is en er vijf replica's zijn, staat Service Fabric maximaal twee beschadigde replica's toe (dat wil gezegd,Math.Ceiling (5*0.21)). Daarom moet het gezondheidsbeleid dienovereenkomstig worden ingesteld.
Mogelijke oorzaak 2:
Statusbeleid wordt opgegeven in termen van percentages van de totale services en niet van specifieke service-exemplaren. Bijvoorbeeld, vóór een upgrade, als een toepassing vier service-exemplaren A, B, C en D heeft, waarbij service D niet in orde is, maar met weinig invloed op de toepassing. We willen de bekende beschadigde service D tijdens de upgrade negeren en de parameter MaxPercentUnhealthyServices instellen op 25%, ervan uitgaande dat alleen A, B en C in orde moeten zijn.
Tijdens de upgrade kan D echter in orde zijn terwijl C beschadigd raakt. De upgrade zou nog steeds slagen omdat slechts 25% van de services beschadigd is. Het kan echter leiden tot onverwachte fouten omdat C onverwacht niet in orde is in plaats van D. In deze situatie moet D worden gemodelleerd als een ander servicetype dan A, B en C. Omdat statusbeleid per servicetype wordt opgegeven, kunnen verschillende drempelwaarden voor een beschadigd percentage worden toegepast op verschillende services.
Ik heb geen statusbeleid opgegeven voor de toepassingsupgrade, maar de upgrade mislukt nog steeds voor een aantal time-outs die ik nooit heb opgegeven
Wanneer er geen statusbeleid wordt opgegeven voor de upgradeaanvraag, worden deze opgehaald uit de ApplicationManifest.xml van de huidige toepassingsversie. Als u bijvoorbeeld Application X bijwerkt van versie 1.0 naar versie 2.0, worden toepassingsstatusbeleidsregels gebruikt die zijn opgegeven in versie 1.0. Als er een ander statusbeleid moet worden gebruikt voor de upgrade, moet het beleid worden opgegeven als onderdeel van de API-aanroep van de toepassingsupgrade. Het beleid dat is opgegeven als onderdeel van de API-aanroep, is alleen van toepassing tijdens de upgrade. Zodra de upgrade is voltooid, worden de beleidsregels die zijn opgegeven in de ApplicationManifest.xml gebruikt.
Onjuiste time-outs worden opgegeven
U hebt zich misschien afgevraagd wat er gebeurt wanneer time-outs inconsistent worden ingesteld. U hebt bijvoorbeeld een UpgradeTimeout die kleiner is dan de UpgradeDomainTimeout. Het antwoord is dat er een fout wordt geretourneerd. Er worden fouten geretourneerd als de UpgradeDomainTimeout kleiner is dan de som van HealthCheckWaitDuration en HealthCheckRetryTimeout, of als UpgradeDomainTimeout kleiner is dan de som van HealthCheckWaitDuration en HealthCheckStableDuration.
Mijn upgrades duren te lang
De tijd waarop een upgrade moet worden voltooid, is afhankelijk van de opgegeven statuscontroles en time-outs. Statuscontroles en time-outs zijn afhankelijk van hoe lang het duurt om de toepassing te kopiëren, implementeren en stabiliseren. Te agressief zijn met time-outs kan meer mislukte upgrades betekenen, dus we raden u aan conservatief te beginnen met langere time-outs.
Hier volgt een snelle vernieuwingsfunctie voor de interactie tussen time-outs en de upgradetijden:
Upgrades voor een upgradedomein kunnen niet sneller worden voltooid dan HealthCheckWaitDuration + HealthCheckStableDuration.
Upgradefout kan niet sneller optreden dan HealthCheckWaitDuration + HealthCheckRetryTimeout.
De upgradetijd voor een upgradedomein wordt beperkt door UpgradeDomainTimeout. Als HealthCheckRetryTimeout en HealthCheckStableDuration zowel nul zijn als de status van de toepassing heen en weer blijft schakelen, treedt er uiteindelijk een time-out op bij UpgradeDomainTimeout. UpgradeDomainTimeout begint te tellen zodra de upgrade voor het huidige upgradedomein wordt gestart.
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.