Řešení potíží s upgrady aplikací
Tento článek se zabývá některými běžnými problémy souvisejícími s upgradem aplikace Azure Service Fabric a jejich řešením.
Řešení potíží s neúspěšným upgradem aplikace
Pokud dojde k selhání upgradu, výstup příkazu Get-ServiceFabricApplicationUpgrade obsahuje další informace pro ladění selhání. Následující seznam určuje, jak se dají další informace použít:
- Identifikujte typ selhání.
- Určete důvod selhání.
- Izolujte jednu nebo více neúspěšných komponent pro další šetření.
Tyto informace jsou k dispozici, když Service Fabric zjistí selhání bez ohledu na to, jestli je ChybaAction vrácena zpět nebo pozastavit upgrade.
Identifikace typu selhání
Ve výstupu get-ServiceFabricApplicationUpgrade identifikuje FailureTimestampUtc časové razítko (v UTC), ve kterém se aktivovalo selhání upgradu service Fabric a FailureAction. FailureReason identifikuje jednu ze tří potenciálních hlavních příčin selhání:
- UpgradeDomainTimeout – označuje, že dokončení konkrétní domény upgradu trvalo příliš dlouho a vypršela platnost UpgradeDomainTimeout .
- OverallUpgradeTimeout – označuje, že dokončení celkového upgradu trvalo příliš dlouho a vypršela platnost upgradu .
- HealthCheck – označuje, že po upgradu aktualizační domény aplikace zůstala v pořádku podle zadaných zásad stavu a vypršela platnost HealthCheckRetryTimeout .
Tyto položky se ve výstupu zobrazí jenom v případě, že se upgrade nezdaří a začne se vracet zpět. Další informace se zobrazí v závislosti na typu selhání.
Prozkoumání časových limitů upgradu
Selhání časového limitu upgradu jsou nejčastěji způsobená problémy s dostupností služeb. Výstup následující po tomto odstavci je typický pro upgrady, kdy repliky služby nebo instance se nespustí v nové verzi kódu. Pole UpgradeDomainProgressAtFailure zachycuje snímek jakékoli čekající práce 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 došlo k selhání upgradu domény MYUD1 a dvou oddílů (744c8d9f-1d26-417e-a60e-cd48f5c098f098f0 a 4b43f4d8-b26b-424e-9307-7a7a62e79750). Oddíly byly zablokované, protože modul runtime nemohl umístit primární repliky (WaitForPrimaryPlacement) na cílové uzly Node1 a Node4.
Pomocí příkazu Get-ServiceFabricNode můžete ověřit, že tyto dva uzly jsou v upgradované doméně MYUD1. UpgradePhase říká PostUpgradeSafetyCheck, což znamená, že tyto bezpečnostní kontroly probíhají po dokončení upgradu všech uzlů v doméně upgradu. Všechny tyto informace odkazuje 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.
UpgradePhase PreUpgradeSafetyCheck znamená, že došlo k problémům s přípravou domény upgradu před provedením. Nejběžnějšími problémy v tomto případě jsou chyby služby při zavření nebo snížení úrovně z primárních cest kódu.
Aktuální UpgradeState je RollingBackCompleted, takže původní upgrade musel být proveden s vrácením zpět FailureAction, který automaticky vrátil upgrade při selhání. Pokud byl původní upgrade proveden s ruční chybou FailureAction, upgrade by místo toho byl 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ší časový limit celkového upgradu stejně jako systém dokončí veškerou práci pro aktuální doménu upgradu. Pokud k tomu dojde, zkuste zvýšit hodnoty parametrů UpgradeTimeout a UpgradeDomainTimeout a zkuste upgrade zopakovat.
Zkoumání selhání kontroly stavu
Selhání kontroly stavu můžou být aktivovány různými problémy, ke kterým může dojít po dokončení upgradu všech uzlů v upgradované doméně a předání všech bezpečnostních kontrol. Výstup následující po tomto odstavci je typickým selháním upgradu kvůli neúspěšným kontrolám stavu. Pole Není v pořádkuEvaluations zachycuje 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 :
Zkoumání selhání kontroly stavu nejprve vyžaduje pochopení modelu stavu Service Fabric. Ale i bez takového podrobného porozumění 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 nejsou v pořádku dvě ze čtyř služeb, které jsou pod výchozím cílem 0 % není v pořádku (MaxPercentUnhealthyServices).
Upgrade se při selhání pozastavil zadáním chyby 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
Při vrácení zpět FailureAction není potřeba žádné obnovení, protože upgrade se při selhání automaticky vrátí zpět. Při ruční chybě 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
Příkaz Start-ServiceFabricApplicationRollback lze kdykoli použít k zahájení 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 za chvíli se spustí.
Pomocí příkazu Resume-ServiceFabricApplicationUpgrade můžete pokračovat zbývající částí upgradu ručně, jednou doménou upgradu najednou. V tomto režimu systém provádí pouze bezpečnostní kontroly. Neprovádí se žádné další kontroly stavu. Tento příkaz lze použít pouze v případě , že UpgradeState zobrazuje RollingForwardPending, což znamená, že aktuální upgradovací doména dokončila upgrade, ale další se nespustil (čeká na vyřízení).
Příkaz Update-ServiceFabricApplicationUpgrade lze použít k obnovení monitorovaného upgradu při provádění bezpečnostních kontrol i kontrol stavu.
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 domény upgradu, kde byla naposledy pozastavena, a používá stejné parametry upgradu a zásady stavu jako předtím. V případě potřeby se při obnovení upgradu dají některé parametry upgradu a zásady stavu uvedené v předchozím výstupu změnit ve stejném příkazu. V tomto příkladu byl upgrade obnoven v monitorovaném režimu s parametry a zásadami stavu beze změny.
Další řešení potíží
Service Fabric neslouchá se zadanými zásadami stavu
Možná příčina 1:
Service Fabric překládá všechny procenta na skutečný počet entit (například repliky, oddíly a služby) pro vyhodnocení stavu a vždy zaokrouhlí 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 (tjMath.Ceiling (5*0.21). Zásady stavu by proto měly být nastaveny odpovídajícím způsobem.
Možná příčina 2:
Zásady stavu se zadává v procentech celkových služeb a ne z konkrétních instancí služeb. Například před upgradem platí, že pokud má aplikace čtyři instance služby A, B, C a D, kde služba D není v pořádku, ale s malým dopadem na aplikaci. Během upgradu chceme ignorovat známou službu, která není v pořádku, a nastavit parametr MaxPercentUnhealthyServices na 25 %, za předpokladu, že musí být v pořádku pouze A, B a C.
Během upgradu se ale může stát, že D bude v pořádku, když C přestane být v pořádku. Upgrade by stále byl úspěšný, protože pouze 25 % služeb není v pořádku. Může ale vést k neočekávaným chybám kvůli neočekávanému špatnému stavu jazyka C místo D. V této situaci by se měl modelovat jako jiný typ služby od A, B a C. Vzhledem k tomu, že jsou zásady stavu zadané pro jednotlivé typy služeb, je možné u různých služeb použít různé prahové hodnoty v procentech, které nejsou v pořádku.
Neurčil(a) jsem zásady stavu pro upgrade aplikace, ale upgrade stále selže po určité časové limity, které jsem nikdy nezadali
Pokud nejsou pro žádost o upgrade poskytnuty 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í určené pro verzi 1.0. Pokud by se pro upgrade měla použít jiná zásada stavu, je potřeba ji zadat jako součást volání rozhraní API pro upgrade aplikace. Zásady zadané jako součást volání rozhraní API se vztahují 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 nastavené časové limity 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 je UpgradeDomainTimeout menší než součet HealthCheckWaitDuration a HealthCheckRetryTimeout nebo pokud UpgradeDomainTimeout je menší než součet HealthCheckWaitDuration a HealthCheckStableDuration.
Upgrady trvá příliš dlouho
Doba dokončení upgradu závisí na zadaných kontrolách stavu a časových limitech. Kontroly stavu a časové limity závisí na tom, jak dlouho trvá kopírování, nasazování a stabilizace aplikace. Příliš agresivní s časovými limity můžou znamenat více neúspěšných upgradů, proto doporučujeme začít konzervativně s delšími časovými limity.
Tady je rychlý aktualizační postup interakce časových limitů s časy upgradu:
Upgrady pro doménu upgradu nelze dokončit rychleji než HealthCheckWaitDuration HealthCheckStableDuration + .
Selhání upgradu nemůže nastat rychleji než HealthCheckWaitDuration + HealthCheckRetryTimeout.
Čas upgradu domény upgradu je omezený upgradem UpgradeDomainTimeout. Pokud HealthCheckRetryTimeout a HealthCheckStableDuration jsou nenulové a stav aplikace neustále přepíná zpět, upgrade nakonec vyprší na UpgradeDomainTimeout. UpgradeDomainTimeout se spustí odpočítávání po zahájení upgradu aktuální domény upgradu.
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.
Díky tomu, že se naučíte používat serializaci dat, vaše aplikace upgraduje.
Informace o používání pokročilých funkcí při upgradu aplikace najdete v části Pokročilá témata.