Dela via

Felsök programuppgraderingar

  • Artikel

Den här artikeln beskriver några vanliga problem med att uppgradera ett Azure Service Fabric-program och hur du löser dem.

Felsöka en misslyckad programuppgradering

När en uppgradering misslyckas innehåller utdata från kommandot Get-ServiceFabricApplicationUpgrade ytterligare information för felsökning av felet. Följande lista anger hur ytterligare information kan användas:

  1. Identifiera feltypen.
  2. Identifiera orsaken till felet.
  3. Isolera en eller flera komponenter som misslyckas för vidare undersökning.

Den här informationen är tillgänglig när Service Fabric identifierar felet oavsett om FailureAction är att återställa eller pausa uppgraderingen.

Identifiera feltypen

I utdata från Get-ServiceFabricApplicationUpgrade identifierar FailureTimestampUtc tidsstämpeln (i UTC) där ett uppgraderingsfel upptäcktes av Service Fabric och FailureAction utlöstes. FailureReason identifierar en av tre potentiella orsaker till felet på hög nivå:

  1. UpgradeDomainTimeout – anger att en viss uppgraderingsdomän tog för lång tid att slutföra och UpgradeDomainTimeout upphörde att gälla.
  2. OverallUpgradeTimeout – anger att den övergripande uppgraderingen tog för lång tid att slutföra och UpgradeTimeout upphörde att gälla.
  3. HealthCheck – anger att efter uppgraderingen av en uppdateringsdomän förblev programmet inte felfri enligt de angivna hälsoprinciperna och HealthCheckRetryTimeout upphörde att gälla.

Dessa poster visas bara i utdata när uppgraderingen misslyckas och börjar rulla tillbaka. Ytterligare information visas beroende på typen av fel.

Undersöka tidsgränser för uppgradering

Tidsgränsfel för uppgradering orsakas oftast av problem med tjänsttillgänglighet. Utdata efter det här stycket är typiska för uppgraderingar där tjänstrepliker eller instanser inte kan starta i den nya kodversionen. Fältet UpgradeDomainProgressAtFailure fångar en ögonblicksbild av väntande uppgraderingsarbete vid tidpunkten för felet.

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

I det här exemplet misslyckades uppgraderingen vid uppgraderingsdomänen MYUD1 och två partitioner (744c8d9f-1d26-417e-a60e-cd48f5c098f0 och 4b43f4d8-b26b-424e-9307-7a7a62e79750) fastnade. Partitionerna fastnade eftersom körningen inte kunde placera primära repliker (WaitForPrimaryPlacement) på målnoderna Node1 och Node4.

Kommandot Get-ServiceFabricNode kan användas för att verifiera att dessa två noder finns i uppgraderingsdomänen MYUD1. UpgradePhase säger PostUpgradeSafetyCheck, vilket innebär att dessa säkerhetskontroller sker när alla noder i uppgraderingsdomänen har slutfört uppgraderingen. All den här informationen pekar på ett potentiellt problem med den nya versionen av programkoden. De vanligaste problemen är tjänstfel i öppna eller befordran till primära kodsökvägar.

En UpgradePhase av PreUpgradeSafetyCheck innebär att det uppstod problem med att förbereda uppgraderingsdomänen innan den utfördes. De vanligaste problemen i det här fallet är tjänstfel i stängningen eller degraderingen från primära kodsökvägar.

Den aktuella UpgradeState är RollingBackCompleted, så den ursprungliga uppgraderingen måste ha utförts med en återställningsfelÅtgärd, som automatiskt återställde uppgraderingen vid fel. Om den ursprungliga uppgraderingen utfördes med en manuell FailureAction skulle uppgraderingen i stället vara i ett pausat tillstånd för att tillåta direkt felsökning av programmet.

I sällsynta fall kan fältet UpgradeDomainProgressAtFailure vara tomt om den övergripande uppgraderingen överskrider tidsgränsen på samma sätt som systemet slutför allt arbete för den aktuella uppgraderingsdomänen. Om detta händer kan du försöka öka parametervärdena UpgradeTimeout och UpgradeDomainTimeout och försöka uppgradera igen.

Undersöka fel vid hälsokontroll

Hälsokontrollfel kan utlösas av olika problem som kan inträffa när alla noder i en uppgraderingsdomän har slutfört uppgraderingen och klarat alla säkerhetskontroller. Utdata efter det här stycket är typiska för ett uppgraderingsfel på grund av misslyckade hälsokontroller. Fältet UnhealthyEvaluations avbildar en ögonblicksbild av hälsokontroller som misslyckades vid tidpunkten för uppgraderingen enligt den angivna hälsoprincipen.

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              :

För att undersöka hälsokontrollfel måste du först förstå Service Fabric-hälsomodellen. Men även utan en sådan djupgående förståelse kan vi se att två tjänster inte är felfria: fabric:/DemoApp/Svc3 och fabric:/DemoApp/Svc2, tillsammans med felhälsorapporterna ("InjectedFault" i det här fallet). I det här exemplet är två av fyra tjänster inte felfria, vilket är under standardmålet på 0 % inte felfri (MaxPercentUnhealthyServices).

Uppgraderingen avbröts när den misslyckades genom att ange en FailureAction för manuell när uppgraderingen startades. Med det här läget kan vi undersöka livesystemet i det misslyckade tillståndet innan vi vidtar ytterligare åtgärder.

Återställa från en pausad uppgradering

Med en återställningsfelÅtgärd behövs ingen återställning eftersom uppgraderingen automatiskt återställs när den misslyckas. Med en manuell FailureAction finns det flera återställningsalternativ:

  1. utlösa en återställning
  2. Gå igenom resten av uppgraderingen manuellt
  3. Återuppta den övervakade uppgraderingen

Kommandot Start-ServiceFabricApplicationRollback kan användas när som helst för att börja återställa programmet. När kommandot har returnerats har återställningsbegäran registrerats i systemet och startar kort därefter.

Kommandot Resume-ServiceFabricApplicationUpgrade kan användas för att fortsätta med resten av uppgraderingen manuellt, en uppgraderingsdomän i taget. I det här läget utförs endast säkerhetskontroller av systemet. Inga fler hälsokontroller utförs. Det här kommandot kan bara användas när UpgradeState visar RollingForwardPending, vilket innebär att den aktuella uppgraderingsdomänen har slutfört uppgraderingen men att nästa inte har startats (väntar).

Kommandot Update-ServiceFabricApplicationUpgrade kan användas för att återuppta den övervakade uppgraderingen med både säkerhets- och hälsokontroller som utförs.

Update-ServiceFabricApplicationUpgrade fabric:/DemoApp -UpgradeMode Monitored

UpgradeMode                             : Monitored
ForceRestart                            :
UpgradeReplicaSetCheckTimeout           :
FailureAction                           :
HealthCheckWaitDuration                 :
HealthCheckStableDuration               :
HealthCheckRetryTimeout                 :
UpgradeTimeout                          :
UpgradeDomainTimeout                    :
ConsiderWarningAsError                  :
MaxPercentUnhealthyPartitionsPerService :
MaxPercentUnhealthyReplicasPerPartition :
MaxPercentUnhealthyServices             :
MaxPercentUnhealthyDeployedApplications :
ServiceTypeHealthPolicyMap              :

Uppgraderingen fortsätter från uppgraderingsdomänen där den senast pausades och använder samma uppgraderingsparametrar och hälsoprinciper som tidigare. Om det behövs kan någon av de uppgraderingsparametrar och hälsoprinciper som visas i föregående utdata ändras i samma kommando när uppgraderingen återupptas. I det här exemplet återupptogs uppgraderingen i övervakat läge, med parametrarna och hälsoprinciperna oförändrade.

Ytterligare felsökning

Service Fabric följer inte de angivna hälsoprinciperna

Möjlig orsak 1:

Service Fabric översätter alla procentandelar till det faktiska antalet entiteter (till exempel repliker, partitioner och tjänster) för hälsoutvärdering och avrundar alltid upp till hela entiteter. Om till exempel max MaxPercentUnhealthyReplicasPerPartition är 21 % och det finns fem repliker tillåter Service Fabric upp till två repliker med feltillstånd (dvsMath.Ceiling (5*0.21). ). Därför bör hälsoprinciper anges i enlighet med detta.

Möjlig orsak 2:

Hälsoprinciper anges i procent av de totala tjänsterna och inte specifika tjänstinstanser. Om ett program till exempel har fyra tjänstinstanser A, B, C och D före en uppgradering, där tjänst D är inte felfri men har liten inverkan på programmet. Vi vill ignorera den kända felaktiga tjänsten D under uppgraderingen och ange parametern MaxPercentUnhealthyServices till 25 %, förutsatt att endast A, B och C måste vara felfria.

Under uppgraderingen kan D dock bli felfri medan C blir felfritt. Uppgraderingen skulle fortfarande lyckas eftersom endast 25 % av tjänsterna inte är felfria. Det kan dock leda till oväntade fel på grund av att C oväntat är felfritt i stället för D. I den här situationen bör D modelleras som en annan tjänsttyp än A, B och C. Eftersom hälsoprinciper anges per tjänsttyp kan olika tröskelvärden för felprocent tillämpas på olika tjänster.

Jag har inte angett någon hälsoprincip för programuppgradering, men uppgraderingen misslyckas fortfarande under vissa tidsgränser som jag aldrig har angett

När hälsoprinciper inte tillhandahålls till uppgraderingsbegäran hämtas de från ApplicationManifest.xml av den aktuella programversionen. Om du till exempel uppgraderar Program X från version 1.0 till version 2.0 används de hälsoprinciper för program som anges i version 1.0. Om en annan hälsoprincip ska användas för uppgraderingen måste principen anges som en del av API-anropet för programuppgradering. De principer som anges som en del av API-anropet gäller endast under uppgraderingen. När uppgraderingen är klar används de principer som anges i ApplicationManifest.xml .

Felaktiga tidsgränser har angetts

Du kanske har undrat över vad som händer när tidsgränser anges inkonsekvent. Du kan till exempel ha en UpgradeTimeout som är mindre än UpgradeDomainTimeout. Svaret är att ett fel returneras. Fel returneras om UpgradeDomainTimeout är mindre än summan av HealthCheckWaitDuration och HealthCheckRetryTimeout, eller om UpgradeDomainTimeout är mindre än summan av HealthCheckWaitDuration och HealthCheckStableDuration.

Mina uppgraderingar tar för lång tid

Hur länge uppgraderingen ska slutföras beror på vilka hälsokontroller och tidsgränser som anges. Hälsokontroller och tidsgränser beror på hur lång tid det tar att kopiera, distribuera och stabilisera programmet. Att vara för aggressiv med tidsgränser kan innebära fler misslyckade uppgraderingar, så vi rekommenderar att du börjar försiktigt med längre tidsgränser.

Här är en snabb uppdatering om hur tidsgränserna interagerar med uppgraderingstiderna:

Uppgraderingar för en uppgraderingsdomän kan inte slutföras snabbare än HealthCheckWaitDuration + HealthCheckStableDuration.

Uppgraderingsfel kan inte inträffa snabbare än HealthCheckWaitDuration + HealthCheckRetryTimeout.

Uppgraderingstiden för en uppgraderingsdomän begränsas av UpgradeDomainTimeout. Om HealthCheckRetryTimeout och HealthCheckStableDuration både är icke-noll och hälsotillståndet för programmet fortsätter att växla fram och tillbaka, överskrider uppgraderingen slutligen UpgradeDomainTimeout. UpgradeDomainTimeout börjar räknas ned när uppgraderingen för den aktuella uppgraderingsdomänen börjar.

Nästa steg

När du uppgraderar ditt program med Visual Studio får du hjälp med en programuppgradering med Hjälp av Visual Studio.

När du uppgraderar ditt program med PowerShell får du hjälp med en programuppgradering med hjälp av PowerShell.

Kontrollera hur programmet uppgraderas med hjälp av uppgraderingsparametrar.

Gör dina programuppgraderingar kompatibla genom att lära dig hur du använder data serialisering.

Lär dig hur du använder avancerade funktioner när du uppgraderar ditt program genom att referera till Avancerade ämnen.