Řešení potíží s upgrady aplikací
Tento článek popisuje některé běžné problémy související s upgradem aplikace Azure Service Fabric a jejich řešení.
Řešení potíží s neúspěšným upgradem aplikace
Při selhání upgradu obsahuje výstup příkazu Get-ServiceFabricApplicationUpgrade další informace pro ladění selhání. Následující seznam určuje, jak lze další informace použít:
- Identifikujte typ selhání.
- Identifikujte důvod selhání.
- Izolujte jednu nebo více chybových komponent pro účely dalšího šetření.
Tyto informace jsou k dispozici, když Service Fabric zjistí selhání bez ohledu na to, jestli má akce Selhání vrátit zpět nebo pozastavit upgrade.
Identifikace typu selhání
Ve výstupu rutiny Get-ServiceFabricApplicationUpgradeidentifikuje FailureTimestampUtc časové razítko (ve standardu UTC), ve kterém služba Service Fabric zjistila selhání upgradu a aktivovala se akce FailureAction . FailureReason identifikuje jednu ze tří možných hlavních příčin selhání:
- UpgradeDomainTimeout – označuje, že dokončení určité upgradované domény trvalo příliš dlouho a platnost upgraduDomainTimeout vypršela.
- OverallUpgradeTimeout – označuje, že dokončení celkového upgradu trvalo příliš dlouho a platnost upgradu vypršela .
- HealthCheck – označuje, že po upgradu aktualizační domény zůstala aplikace v pořádku podle zadaných zásad stavu a platnost healthCheckRetryTimeout vypršela.
Tyto položky se ve výstupu zobrazí pouze v případě, že upgrade selže a začne se vracet zpět. Další informace se zobrazí v závislosti na typu selhání.
Zkoumání časových limitů upgradu
Příčinou selhání časového limitu upgradu jsou nejčastěji problémy s dostupností služby. Výstup následující za tímto odstavcem je typický pro upgrady, kdy se repliky nebo instance služby nepodaří spustit v nové verzi kódu. Pole UpgradeDomainProgressAtFailure zaznamenává snímek všech čekajících prací na upgradu v době selhání.
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
V tomto příkladu upgrade domény MYUD1 selhal a dva oddíly (744c8d9f-1d26-417e-a60e-cd48f5c098f0 a 4b43f4d8-b26b-424e-9307-7a7a62e79750) byly zablokované. Oddíly se zablokovaly, protože modul runtime nemohl umístit primární repliky (WaitForPrimaryPlacement) na cílové uzly Node1 a Node4.
Příkaz Get-ServiceFabricNode lze použít k ověření, že tyto dva uzly jsou v upgradované doméně MYUD1. UpgradePhase říká PostUpgradeSafetyCheck, což znamená, že k těmto kontrolám zabezpečení dochází po dokončení upgradu všech uzlů v doméně upgradu. Všechny tyto informace odkazují na potenciální problém s novou verzí kódu aplikace. Nejběžnějšími problémy jsou chyby služby při otevření nebo povýšení na primární cesty kódu.
UpgradePhasepreUpgradeSafetyCheck znamená, že před provedením upgradu došlo k problémům s přípravou domény upgradu. Nejběžnějšími problémy v tomto případě jsou chyby služby při zavření nebo degradaci z primárních cest kódu.
Aktuální UpgradeState je RollingBackCompleted, takže původní upgrade musí být proveden s vrácením selháníAction, která automaticky vrátila upgrade zpět při selhání. Pokud byl původní upgrade proveden s ruční akcí FailureAction, pak by upgrade byl místo toho v pozastaveném stavu, aby bylo možné živé ladění aplikace.
Ve výjimečných případech může být pole UpgradeDomainProgressAtFailure prázdné, pokud vyprší celkový časový limit upgradu, stejně jako systém dokončí všechny práce pro aktuální doménu upgradu. Pokud k tomu dojde, zkuste zvýšit hodnoty parametrů upgradu UpgradeTimeout a UpgradeDomainTimeout a zkuste upgrade zopakovat.
Zkoumání selhání kontroly stavu
Selhání kontroly stavu můžou být aktivována různými problémy, ke kterým může dojít poté, co všechny uzly v upgradované doméně dokončí upgrade a projdou všemi bezpečnostními kontrolami. Výstup následující za tímto odstavcem je typický pro selhání upgradu kvůli neúspěšným kontrolám stavu. Pole Nezdravé hodnocení zaznamenává snímek kontrol stavu, které selhaly v době upgradu podle zadaných zásad stavu.
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 :
Prošetření selhání kontroly stavu nejprve vyžaduje znalost modelu stavu Service Fabric. Ale i bez takového důkladného pochopení vidíme, že dvě služby nejsou v pořádku: fabric:/DemoApp/Svc3 a fabric:/DemoApp/Svc2, spolu se zprávami o stavu chyb (v tomto případě InjectedFault). V tomto příkladu jsou dvě ze čtyř služeb v pořádku, což je nižší než výchozí cíl 0 % – není v pořádku (MaxPercentUnhealthyServices).
Upgrade byl při selhání pozastaven zadáním akce Selhání ruční při spuštění upgradu. Tento režim nám umožňuje prozkoumat živý systém ve stavu selhání před provedením jakékoli další akce.
Obnovení z pozastaveného upgradu
S vrácením funkce FailureAction není potřeba žádné obnovení, protože upgrade se při selhání automaticky vrátí zpět. U ruční akce FailureAction existuje několik možností obnovení:
- aktivace vrácení zpět
- Pokračujte zbývající částí upgradu ručně.
- Obnovení monitorovaného upgradu
Pomocí příkazu Start-ServiceFabricApplicationRollback můžete kdykoli spustit vrácení aplikace zpět. Jakmile se příkaz úspěšně vrátí, žádost o vrácení zpět se zaregistruje v systému a krátce poté se spustí.
Příkaz Resume-ServiceFabricApplicationUpgrade můžete použít k ručnímu přechodu na zbývající část upgradu po jednotlivých upgradovaných doménách. V tomto režimu systém provádí pouze bezpečnostní kontroly. Žádné další kontroly stavu se neprovádí. Tento příkaz lze použít pouze v případě, že upgradeState zobrazuje RollingForwardPending, což znamená, že aktuální upgradovaná doména dokončila upgrade, ale další se nezačala (čeká na vyřízení).
Pomocí příkazu Update-ServiceFabricApplicationUpgrade můžete pokračovat v monitorovaném upgradu s prováděním bezpečnostních a zdravotních kontrol.
Update-ServiceFabricApplicationUpgrade fabric:/DemoApp -UpgradeMode Monitored
UpgradeMode : Monitored
ForceRestart :
UpgradeReplicaSetCheckTimeout :
FailureAction :
HealthCheckWaitDuration :
HealthCheckStableDuration :
HealthCheckRetryTimeout :
UpgradeTimeout :
UpgradeDomainTimeout :
ConsiderWarningAsError :
MaxPercentUnhealthyPartitionsPerService :
MaxPercentUnhealthyReplicasPerPartition :
MaxPercentUnhealthyServices :
MaxPercentUnhealthyDeployedApplications :
ServiceTypeHealthPolicyMap :
Upgrade pokračuje z upgradované domény, ve které byl naposledy pozastaven, a používá stejné parametry a zásady stavu jako předtím. V případě potřeby můžete při obnovení upgradu změnit kterýkoli z parametrů upgradu a zásad stavu zobrazených v předchozím výstupu ve stejném příkazu. V tomto příkladu byl upgrade obnoven v monitorovaném režimu, přičemž parametry a zásady stavu se nezměnily.
Další řešení potíží
Service Fabric nedosažuje zadané zásady stavu.
Možná příčina 1:
Service Fabric překládá všechna procenta na skutečný počet entit (například replik, oddílů a služeb) pro vyhodnocení stavu a vždy zaokrouhlí nahoru na celé entity. Pokud je například maximální hodnota MaxPercentUnhealthyReplicasPerPartition 21 % a existuje pět replik, Service Fabric umožňuje až dvě repliky, které nejsou v pořádku (to znamená).Math.Ceiling (5*0.21) Zásady stavu by se proto měly nastavit odpovídajícím způsobem.
Možná příčina 2:
Zásady stavu se zadává v procentech celkového počtu služeb, a ne v konkrétních instancích služeb. Například před upgradem, pokud má aplikace čtyři instance služby A, B, C a D, kde služba D není v pořádku, ale má malý dopad na aplikaci. Během upgradu chceme ignorovat známou službu D, která není v pořádku, a nastavit parametr MaxPercentUnhealthyServices na 25 %, za předpokladu, že pouze A, B a C musí být v pořádku.
Během upgradu ale může být jazyk D v pořádku, zatímco jazyk C přestane být v pořádku. Upgrade by stále proběhl úspěšně, protože pouze 25 % služeb není v pořádku. Může to ale vést k neočekávaným chybám kvůli tomu, že jazyk C není neočekávaně v pořádku místo D. V této situaci by měl být model D modelován jako jiný typ služby než A, B a C. Vzhledem k tomu, že zásady stavu jsou zadané pro každý typ služby, je možné pro různé služby použít různé prahové hodnoty procenta, které nejsou v pořádku.
Nezadá(a) jsem zásadu stavu pro upgrade aplikace, ale upgrade stále selže po určité časové limity, které jsem nikdy nezadal(a)
Pokud žádost o upgrade neposkytne zásady stavu, převezmou se z ApplicationManifest.xml aktuální verze aplikace. Pokud například upgradujete aplikaci X z verze 1.0 na verzi 2.0, použijí se zásady stavu aplikací zadané ve verzi 1.0. Pokud se pro upgrade mají použít jiné zásady stavu, je potřeba zásady zadat jako součást volání rozhraní API pro upgrade aplikace. Zásady zadané jako součást volání rozhraní API platí pouze během upgradu. Po dokončení upgradu se použijí zásady zadané v ApplicationManifest.xml .
Jsou zadány nesprávné časové limity.
Možná jste přemýšleli o tom, co se stane, když jsou časové limity nastaveny nekonzistentně. Můžete mít například UpgradeTimeout , který je menší než UpgradeDomainTimeout. Odpověď je, že se vrátí chyba. Chyby se vrátí, pokud upgradeDomainTimeout je menší než součet HealthCheckWaitDuration a HealthCheckRetryTimeout nebo pokud UpgradeDomainTimeout je menší než součet HealthCheckWaitDuration a HealthCheckStableDuration.
Upgrady trvají příliš dlouho
Doba dokončení upgradu závisí na zadaných kontrolách stavu a časových limitech. Kontroly stavu a vypršení časových limitů závisí na tom, jak dlouho trvá kopírování, nasazení a stabilizace aplikace. Příliš agresivní s vypršením časových limitů může znamenat více neúspěšných upgradů, proto doporučujeme začít konzervativně s delšími časovými limity.
Tady je rychlá aktualizace toho, jak časové limity interagují s časy upgradu:
Upgrady pro upgradovanou doménu nelze dokončit rychleji než HealthCheckWaitDuration + HealthCheckStableDuration.
K selhání upgradu nemůže dojít rychleji než HealthCheckWaitDuration + HealthCheckRetryTimeout.
Čas upgradu upgradované domény je omezený upgradem DoményTimeout. Pokud jsou HealthCheckRetryTimeout a HealthCheckStableDuration nenulové a stav aplikace stále přepíná tam a zpět, pak nakonec vyprší časový limit upgradu v UpgradeDomainTimeout. UpgradeDomainTimeout začne odpočítávat, jakmile začne upgrade aktuální upgradovací domény.
Další kroky
Upgrade aplikace pomocí sady Visual Studio vás provede upgradem aplikace pomocí sady Visual Studio.
Upgrade aplikace pomocí PowerShellu vás provede upgradem aplikace pomocí PowerShellu.
Pomocí parametrů upgradu můžete řídit, jak se vaše aplikace upgraduje.
Zajistěte kompatibilitu upgradů aplikací tím, že se naučíte používat serializaci dat.
Informace o používání pokročilých funkcí při upgradu aplikace najdete v části Rozšířená témata.