Alkalmazásfrissítések hibaelhárítása
Ez a cikk az Azure Service Fabric-alkalmazások frissítésével és azok megoldásával kapcsolatos gyakori problémákat ismerteti.
Sikertelen alkalmazásfrissítés hibaelhárítása
Ha egy frissítés sikertelen, a Get-ServiceFabricApplicationUpgrade parancs kimenete további információkat tartalmaz a hibakereséshez. Az alábbi lista a további információk felhasználási módját határozza meg:
- Azonosítsa a hiba típusát.
- Azonosítsa a hiba okát.
- Egy vagy több hibás összetevő elkülönítése további vizsgálat céljából.
Ezek az információk akkor érhetők el, ha a Service Fabric észleli a hibát, függetlenül attól, hogy a FailureAction a frissítés visszaállítására vagy felfüggesztésére szolgál-e.
A hibatípus azonosítása
A Get-ServiceFabricApplicationUpgrade kimenetében a FailureTimestampUtc azonosítja azt az időbélyeget (UTC-ben), amikor a Service Fabric frissítési hibát észlelt, és a FailureAction aktiválódott. A FailureReason a hiba három lehetséges magas szintű oka közül az egyiket azonosítja:
- UpgradeDomainTimeout – Azt jelzi, hogy egy adott frissítési tartomány túl sokáig tartott, és az UpgradeDomainTimeout lejárt.
- OverallUpgradeTimeout – Azt jelzi, hogy a teljes frissítés túl sokáig tartott, és az UpgradeTimeout lejárt .
- HealthCheck – Azt jelzi, hogy a frissítési tartomány frissítése után az alkalmazás a megadott állapotszabályzatoknak megfelelően nem kifogástalan állapotú maradt, és a HealthCheckRetryTimeout lejárt .
Ezek a bejegyzések csak akkor jelennek meg a kimenetben, ha a frissítés meghiúsul, és visszagördül. A hiba típusától függően további információk jelennek meg.
Frissítési időtúllépések vizsgálata
A frissítés időtúllépési hibáit leggyakrabban a szolgáltatás rendelkezésre állásával kapcsolatos problémák okozzák. A bekezdést követő kimenet általában olyan frissítésekre jellemző, amelyekben a szolgáltatásreplikák vagy -példányok nem indulnak el az új kódverzióban. Az UpgradeDomainProgressAtFailure mező pillanatképet készít a hiba időpontjában függőben lévő frissítési munkákról.
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
Ebben a példában a frissítés a MYUD1 frissítési tartománynál meghiúsult, és két partíció (744c8d9f-1d26-417e-a60e-cd48f5c098f0 és 4b43f4d8-b26b-424e-9307-7a7a62e79750) elakadt. A partíciók elakadtak, mert a futtatókörnyezet nem tudott elsődleges replikákat (WaitForPrimaryPlacement) elhelyezni a Node1 és a Node4célcsomópontokon.
A Get-ServiceFabricNode paranccsal ellenőrizheti, hogy ez a két csomópont a MYUD1 frissítési tartományban van-e. Az UpgradePhase a PostUpgradeSafetyCheck feliratot jelzi, ami azt jelenti, hogy ezek a biztonsági ellenőrzések akkor történnek, ha a frissítési tartomány összes csomópontja befejezte a frissítést. Ezek az információk az alkalmazáskód új verziójával kapcsolatos lehetséges problémára mutatnak. A leggyakoribb problémák a nyitott vagy az elsődleges kódútvonalakra való előléptetés szolgáltatáshibái.
A PreUpgradeSafetyCheckUpgradePhase eleme azt jelenti, hogy problémák merültek fel a frissítési tartomány előkészítésekor a végrehajtás előtt. Ebben az esetben a leggyakoribb problémák a szolgáltatáshibák az elsődleges kód elérési útjaiból való bezáráskor vagy lefokozáskor.
Az aktuális UpgradeStatea RollingBackCompleted, ezért az eredeti frissítést egy visszaállítási FailureAction művelettel kell végrehajtani, amely hiba esetén automatikusan visszaállította a frissítést. Ha az eredeti frissítést manuális FailureAction művelettel hajtották végre, akkor a frissítés felfüggesztett állapotban lenne, hogy lehetővé tegye az alkalmazás élő hibakeresését.
Ritka esetekben az UpgradeDomainProgressAtFailure mező üres lehet, ha a teljes frissítés túllépi az időkorlátot, ahogy a rendszer befejezi az aktuális frissítési tartomány összes munkáját. Ha ez történik, próbálja meg növelni az UpgradeTimeout és az UpgradeDomainTimeout frissítési paraméterértékét, és próbálkozzon újra a frissítéssel.
Állapot-ellenőrzési hibák kivizsgálása
Az állapot-ellenőrzési hibákat különböző problémák válthatják ki, amelyek akkor fordulhatnak elő, ha a frissítési tartomány összes csomópontja befejezi a frissítést, és átadja az összes biztonsági ellenőrzést. A bekezdést követő kimenet a sikertelen állapotellenőrzések miatti frissítési hibára jellemző. A UnhealthyEvaluations mező pillanatképet készít azokról az állapotellenőrzésekről, amelyek a frissítés időpontjában a megadott állapotszabályzatnak megfelelően meghiúsultak.
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 :
Az állapot-ellenőrzési hibák kivizsgálásához először ismernie kell a Service Fabric-állapotmodellt. De még ilyen alapos megértés nélkül is láthatjuk, hogy két szolgáltatás állapota nem megfelelő: fabric:/DemoApp/Svc3 és fabric:/DemoApp/Svc2, valamint a hibaállapot-jelentések ("InjektáltFault" ebben az esetben). Ebben a példában négy szolgáltatás közül kettő nem kifogástalan, ami az alapértelmezett 0%-os nem megfelelő (MaxPercentUnhealthyServices) cél alatt van.
A frissítés a sikertelenség után fel lett függesztve egy manuális FailureAction utasítás megadásával a frissítés indításakor. Ez a mód lehetővé teszi az élő rendszer sikertelen állapotban történő vizsgálatát, mielőtt további lépéseket hajtanánk végre.
Helyreállítás felfüggesztett frissítésből
Visszaállítási FailureAction esetén nincs szükség helyreállításra, mivel a frissítés automatikusan visszaválik a sikertelen működés után. Manuális FailureAction esetén több helyreállítási lehetőség is rendelkezésre áll:
- visszaállítás aktiválása
- Folytassa a frissítés hátralévő részét manuálisan
- A figyelt frissítés folytatása
A Start-ServiceFabricApplicationRollback parancs bármikor használható az alkalmazás visszaállításának megkezdéséhez. A parancs sikeres visszaadása után a visszaállítási kérés regisztrálva lett a rendszerben, és röviddel ezután elindul.
A Resume-ServiceFabricApplicationUpgrade paranccsal manuálisan folytathatja a frissítés hátralévő részét, egyszerre egy frissítési tartományt. Ebben a módban a rendszer csak biztonsági ellenőrzéseket végez. Nincs több állapotellenőrzés. Ez a parancs csak akkor használható, ha az UpgradeState a RollingForwardPending értéket jeleníti meg, ami azt jelenti, hogy az aktuális frissítési tartomány befejezte a frissítést, de a következő nem indult el (függőben).
Az Update-ServiceFabricApplicationUpgrade paranccsal folytathatja a figyelt frissítést mind a biztonsági, mind az egészségügyi ellenőrzés végrehajtásával.
Update-ServiceFabricApplicationUpgrade fabric:/DemoApp -UpgradeMode Monitored
UpgradeMode : Monitored
ForceRestart :
UpgradeReplicaSetCheckTimeout :
FailureAction :
HealthCheckWaitDuration :
HealthCheckStableDuration :
HealthCheckRetryTimeout :
UpgradeTimeout :
UpgradeDomainTimeout :
ConsiderWarningAsError :
MaxPercentUnhealthyPartitionsPerService :
MaxPercentUnhealthyReplicasPerPartition :
MaxPercentUnhealthyServices :
MaxPercentUnhealthyDeployedApplications :
ServiceTypeHealthPolicyMap :
A frissítés attól a frissítési tartománytól folytatódik, ahol legutóbb felfüggesztették, és ugyanazokat a frissítési paramétereket és állapotszabályzatokat használja, mint korábban. Szükség esetén az előző kimenetben látható frissítési paraméterek és állapotszabályzatok bármelyike módosítható ugyanabban a parancsban a frissítés folytatásakor. Ebben a példában a frissítés monitorozott módban folytatódott, a paraméterek és az állapotszabályzatok változatlanul maradtak.
További hibaelhárítás
A Service Fabric nem követi a megadott állapotszabályzatokat
Lehetséges ok 1:
A Service Fabric az összes százalékot az entitások tényleges számára fordítja le (például replikákra, partíciókra és szolgáltatásokra) állapotértékelés céljából, és mindig egész entitásokra kerekít. Ha például a MaxPercentUnhealthyReplicasPerPartition maximális mérete 21%, és öt replika van, akkor a Service Fabric legfeljebb két nem kifogástalan replikát engedélyez (azazMath.Ceiling (5*0.21)). Ezért az egészségügyi politikákat ennek megfelelően kell meghatározni.
2. lehetséges ok:
Az állapotszabályzatok az összes szolgáltatás százalékában vannak megadva, nem pedig adott szolgáltatáspéldányokban. Például a frissítés előtt, ha egy alkalmazás négy A, B, C és D szolgáltatáspéldánysal rendelkezik, ahol a D szolgáltatás állapota nem megfelelő, de kevés hatással van az alkalmazásra. A frissítés során figyelmen kívül szeretnénk hagyni az ismert nem megfelelő állapotú D szolgáltatást, és a MaxPercentUnhealthyServices paramétert 25%-ra szeretnénk állítani, feltéve, hogy csak az A, a B és a C állapotnak kell kifogástalannak lennie.
A frissítés során azonban a D állapota kifogástalanná válhat, míg a C állapota nem megfelelő. A frissítés továbbra is sikeres lesz, mert a szolgáltatásoknak csak 25%-a nem megfelelő állapotú. Előfordulhat azonban, hogy nem várt hibákat eredményez, mivel a C állapota váratlanul nem megfelelő a D helyett. Ebben az esetben a D-t az A, B és C szolgáltatástípustól eltérő szolgáltatástípusként kell modellezni. Mivel az állapotszabályzatok szolgáltatástípusonként vannak megadva, különböző, nem megfelelő állapotú százalékos küszöbértékek alkalmazhatók a különböző szolgáltatásokra.
Nem adtam meg állapotszabályzatot az alkalmazásfrissítéshez, de a frissítés továbbra is meghiúsul bizonyos időtúllépések esetén, amelyeket soha nem adott meg
Ha a frissítési kérelemhez nem adták meg az állapotszabályzatokat, azok az aktuális alkalmazásverzió ApplicationManifest.xml származnak. Ha például az X alkalmazást az 1.0-s verzióról a 2.0-s verzióra frissíti, a rendszer az 1.0-s verzióhoz megadott alkalmazásállapot-szabályzatokat használja. Ha a frissítéshez más állapotszabályzatot kell használni, akkor a szabályzatot az alkalmazásfrissítési API-hívás részeként kell megadni. Az API-hívás részeként megadott szabályzatok csak a frissítés során érvényesek. A frissítés befejezése után a rendszer aApplicationManifest.xml megadott szabályzatokat használja.
Helytelen időtúllépések vannak megadva
Felmerülhetett a kérdés, hogy mi történik, ha az időtúllépések inkonzisztensen vannak beállítva. Előfordulhat például, hogy az UpgradeTimeout értéke kisebb, mint az UpgradeDomainTimeout. A válasz az, hogy a rendszer hibát ad vissza. A rendszer hibát ad vissza, ha az UpgradeDomainTimeout kisebb, mint a HealthCheckWaitDuration és a HealthCheckRetryTimeout összege, vagy ha az UpgradeDomainTimeout kisebb, mint a HealthCheckWaitDuration és a HealthCheckStableDuration összege.
A frissítéseim túl sokáig tartanak
A frissítés befejezésének ideje a megadott állapot-ellenőrzésektől és időtúllépéstől függ. Az állapotellenőrzések és időtúllépések attól függenek, hogy mennyi ideig tart az alkalmazás másolása, üzembe helyezése és stabilizálása. Ha túl agresszív az időtúllépésekkel, az több sikertelen frissítést jelenthet, ezért javasoljuk, hogy konzervatív módon kezdjen el hosszabb időtúllépésekkel.
Az alábbiakban egy gyors frissítőt talál arról, hogy az időtúllépések hogyan működnek együtt a frissítési idővel:
A frissítési tartomány frissítései nem fejeződnek be gyorsabban , mint a HealthCheckWaitDuration + HealthCheckStableDuration.
A frissítési hiba nem fordulhat elő gyorsabban, mint a HealthCheckWaitDuration + HealthCheckRetryTimeout.
A frissítési tartomány frissítési idejét az UpgradeDomainTimeout korlátozza. Ha a HealthCheckRetryTimeout és a HealthCheckStableDuration nem nulla, és az alkalmazás állapota folyamatosan oda-vissza vált, akkor a frissítés végül túllépi az időkorlátot az UpgradeDomainTimeout esetében. Az UpgradeDomainTimeout az aktuális frissítési tartomány frissítésének megkezdésekor kezdi meg a visszaszámlálást.
Következő lépések
Az alkalmazás Visual Studio használatával történő frissítése végigvezeti a Visual Studio használatával végzett alkalmazásfrissítésen.
Az alkalmazás PowerShell használatával történő frissítése végigvezeti a PowerShell használatával végzett alkalmazásfrissítésen.
Az alkalmazás frissítési paramétereivel szabályozhatja, hogy az alkalmazás hogyan frissüljön.
Az adat szerializálás használatának elsajátításával kompatibilissé teheti az alkalmazásfrissítéseket.
A Speciális témakörök című témakörből megtudhatja, hogyan használhatja a speciális funkciókat az alkalmazás frissítése során.