Problemen met toepassingsupgrades oplossen
In dit artikel worden enkele veelvoorkomende problemen beschreven 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. In de volgende lijst wordt aangegeven hoe de aanvullende informatie kan worden gebruikt:
- Identificeer het fouttype.
- Identificeer de reden van de fout.
- Een of meer defecte onderdelen isoleren voor verder onderzoek.
Deze informatie is beschikbaar wanneer Service Fabric de fout detecteert, ongeacht of de FailureAction de upgrade moet terugdraaien of onderbreken.
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 hoofdoorzaken van de fout:
- UpgradeDomainTimeout - Geeft aan dat het voltooien van een bepaald upgradedomein te lang duurde 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. Er wordt meer informatie weergegeven, afhankelijk van het type fout.
Upgradetime-outs onderzoeken
Time-outfouten bij upgrades worden meestal veroorzaakt door problemen met de beschikbaarheid van de service. De uitvoer na deze alinea is typisch voor upgrades waarbij servicereplica's of exemplaren niet kunnen worden gestart in de nieuwe codeversie. In het veld UpgradeDomainProgressAtFailure wordt een momentopname vastgelegd van eventuele upgradewerkzaamheden die in behandeling zijn 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 zijn 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) op de doelknooppunten Node1 en Node4 kan plaatsen.
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 worden uitgevoerd nadat alle knooppunten in het upgradedomein de upgrade hebben voltooid. Al deze informatie wijst op 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 waren 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 is teruggedraaid bij een fout. Als de oorspronkelijke upgrade is uitgevoerd met een handmatige FailureAction, heeft de upgrade in plaats daarvan de status Onderbroken om live foutopsporing van de toepassing toe te staan.
In zeldzame gevallen kan het veld UpgradeDomainProgressAtFailure leeg zijn 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 upgradeparameterwaarden 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 de upgrade hebben voltooid en alle veiligheidscontroles hebben doorlopen. De uitvoer na deze alinea is typerend voor een upgradefout vanwege mislukte statuscontroles. In het veld UnhealthyEvaluations wordt een momentopname vastgelegd 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 :
Het onderzoeken van statuscontrolefouten vereist eerst inzicht in het Service Fabric-statusmodel. 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 ('In dit geval InjectedFault'). In dit voorbeeld zijn twee van de vier services beschadigd, wat lager is dan het standaarddoel van 0% beschadigd (MaxPercentUnhealthyServices).
De upgrade is onderbroken bij het mislukken door een FailureAction van handmatig op te geven bij het starten van de upgrade. Met deze modus kunnen we het livesysteem met 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 wanneer het mislukt. Met een handmatige FailureAction zijn er verschillende herstelopties:
- een terugdraaiactie activeren
- De rest van de upgrade handmatig doorlopen
- 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 aanvraag voor terugdraaien 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 UpgradeStateRollingForwardPending weergeeft, wat betekent dat het huidige upgradedomein is bijgewerkt, maar de volgende niet is gestart (in behandeling).
De opdracht Update-ServiceFabricApplicationUpgrade kan worden gebruikt om de bewaakte upgrade te hervatten, waarbij zowel veiligheids- als statuscontroles 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 wordt voortgezet vanuit het upgradedomein waar deze voor het laatst is onderbroken en gebruikt dezelfde upgradeparameters en hetzelfde statusbeleid 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 het opgegeven statusbeleid niet
Mogelijke oorzaak 1:
Service Fabric vertaalt alle percentages in werkelijke aantallen entiteiten (bijvoorbeeld replica's, partities en services) voor statusevaluatie en rondt altijd af naar 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 weten).Math.Ceiling (5*0.21) Daarom moet het gezondheidsbeleid dienovereenkomstig worden vastgesteld.
Mogelijke oorzaak 2:
Statusbeleid wordt opgegeven in percentages van het totale aantal services en niet in 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 gevolgen voor 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 slaagt nog steeds omdat slechts 25% van de services niet in orde zijn. Dit kan echter leiden tot onverwachte fouten omdat C onverwacht beschadigd is in plaats van D. In dit geval moet D worden gemodelleerd als een ander servicetype dan A, B en C. Omdat het statusbeleid per servicetype wordt opgegeven, kunnen verschillende drempelwaarden voor het percentage beschadigde statussen worden toegepast op verschillende services.
Ik heb geen statusbeleid opgegeven voor de toepassingsupgrade, maar de upgrade mislukt nog steeds voor enkele time-outs die ik nooit heb opgegeven
Wanneer er geen statusbeleid wordt opgegeven voor de upgradeaanvraag, worden ze overgenomen uit de ApplicationManifest.xml van de huidige toepassingsversie. Als u bijvoorbeeld Toepassing X upgradet van versie 1.0 naar versie 2.0, wordt het toepassingsstatusbeleid gebruikt dat is opgegeven in versie 1.0. Als een ander statusbeleid moet worden gebruikt voor de upgrade, moet het beleid worden opgegeven als onderdeel van de API-aanroep voor de upgrade van de toepassing. De beleidsregels die zijn opgegeven als onderdeel van de API-aanroep, zijn alleen van toepassing tijdens de upgrade. Zodra de upgrade is voltooid, worden de beleidsregels gebruikt die zijn opgegeven in de ApplicationManifest.xml .
Er zijn onjuiste time-outs 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. Fouten worden 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 statuscontroles en time-outs die zijn opgegeven. 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 voorzichtig te beginnen met langere time-outs.
Hier volgt een korte opfrisser over hoe de time-outs werken met 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 beide niet-nul zijn en de status van de toepassing steeds heen en weer schakelt, treedt er uiteindelijk een time-out op voor upgradeDomainTimeout. UpgradeDomainTimeout begint met het aftellen zodra de upgrade voor het huidige upgradedomein begint.
Volgende stappen
Uw toepassing upgraden met Visual Studio helpt u bij het uitvoeren van een toepassingsupgrade met behulp van Visual Studio.
Bij het upgraden van uw toepassing met behulp van PowerShell wordt u begeleid 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.