Rozwiązywanie problemów z uaktualnieniami aplikacji
W tym artykule opisano niektóre typowe problemy związane z uaktualnianiem aplikacji usługi Azure Service Fabric i sposobem ich rozwiązywania.
Rozwiązywanie problemów z nieudanym uaktualnieniem aplikacji
Gdy uaktualnienie zakończy się niepowodzeniem, dane wyjściowe polecenia Get-ServiceFabricApplicationUpgrade zawierają dodatkowe informacje na temat debugowania błędu. Poniższa lista określa sposób użycia dodatkowych informacji:
- Zidentyfikuj typ błędu.
- Zidentyfikuj przyczynę błędu.
- Izoluj co najmniej jeden składnik, który kończy się niepowodzeniem w celu dalszego zbadania.
Te informacje są dostępne, gdy usługa Service Fabric wykryje błąd niezależnie od tego, czy działanie FailureAction ma wycofać lub wstrzymać uaktualnienie.
Identyfikowanie typu błędu
W danych wyjściowych polecenia Get-ServiceFabricApplicationUpgrade, FailureTimestampUtc identyfikuje sygnaturę czasową (w formacie UTC), o której wykryto błąd uaktualniania przez usługę Service Fabric, a element FailureAction został wyzwolony. FailureReason identyfikuje jedną z trzech potencjalnych przyczyn awarii wysokiego poziomu:
- UpgradeDomainTimeout — wskazuje, że ukończenie określonej domeny uaktualnienia trwało zbyt długo, a upłynął limit czasu uaktualnienia UpgradeDomainTimeout .
- OverallUpgradeTimeout — wskazuje, że ukończenie ogólnego uaktualnienia trwało zbyt długo i upłynął limit czasu uaktualnienia.
- HealthCheck — wskazuje, że po uaktualnieniu domeny aktualizacji aplikacja pozostała w złej kondycji zgodnie z określonymi zasadami kondycji, a właściwość HealthCheckRetryTimeout wygasła.
Te wpisy są wyświetlane tylko w danych wyjściowych, gdy uaktualnienie zakończy się niepowodzeniem i rozpocznie wycofywanie. Dalsze informacje są wyświetlane w zależności od typu błędu.
Badanie limitów czasu uaktualniania
Błędy przekroczenia limitu czasu uaktualniania są najczęściej spowodowane problemami z dostępnością usługi. Dane wyjściowe opisane w tym akapicie są typowe dla uaktualnień, w których nie można uruchomić replik usługi lub wystąpień w nowej wersji kodu. Pole UpgradeDomainProgressAtFailure przechwytuje migawkę wszystkich oczekujących prac uaktualniania w momencie awarii.
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
W tym przykładzie uaktualnienie nie powiodło się w domenie uaktualnienia MYUD1 i dwóch partycjach (744c8d9f-1d26-417e-a60e-cd48f5c098f0 i 4b43f4d8-b26b-424e-9307-7a7a62e79750). Partycje zostały zablokowane, ponieważ środowisko uruchomieniowe nie mogło umieścić replik podstawowych (WaitForPrimaryPlacement) w węzłach docelowych Node1 i Node4.
Za pomocą polecenia Get-ServiceFabricNode można sprawdzić, czy te dwa węzły znajdują się w domenie uaktualnienia MYUD1. UpgradePhase mówi PostUpgradeSafetyCheck, co oznacza, że te kontrole bezpieczeństwa są przeprowadzane po zakończeniu uaktualniania wszystkich węzłów w domenie uaktualnienia. Wszystkie te informacje wskazują na potencjalny problem z nową wersją kodu aplikacji. Najczęstszymi problemami są błędy usługi podczas otwierania lub podwyższania poziomu do podstawowych ścieżek kodu.
UpgradePhase preUpgradeSafetyCheck oznacza, że wystąpiły problemy z przygotowaniem domeny uaktualnienia przed jego wykonaniem. Najczęstsze problemy w tym przypadku to błędy usługi w zamknięciu lub degradacji z podstawowych ścieżek kodu.
Bieżący element UpgradeState to RollingBackCompleted, więc oryginalne uaktualnienie musi zostać wykonane z funkcją Niepowodzenia wycofywania, która automatycznie wycofała uaktualnienie po awarii. Jeśli oryginalne uaktualnienie zostało wykonane z ręcznym działaniem FailureAction, uaktualnienie będzie zamiast tego w stanie wstrzymania, aby umożliwić debugowanie na żywo aplikacji.
W rzadkich przypadkach pole UpgradeDomainProgressAtFailure może być puste, jeśli ogólny limit czasu uaktualniania przekracza limit czasu, tak jak system zakończy całą pracę dla bieżącej domeny uaktualnienia. Jeśli tak się stanie, spróbuj zwiększyć wartości parametrów upgradeTimeout i UpgradeDomainTimeout i ponowić próbę uaktualnienia.
Badanie błędów sprawdzania kondycji
Błędy sprawdzania kondycji mogą być wyzwalane przez różne problemy, które mogą wystąpić po zakończeniu uaktualniania wszystkich węzłów w domenie uaktualnienia i przekazaniu wszystkich kontroli bezpieczeństwa. Dane wyjściowe opisane w tym akapicie są typowe dla niepowodzenia uaktualniania z powodu nieudanych testów kondycji. Pole UnhealthyEvaluations przechwytuje migawkę kontroli kondycji, które zakończyły się niepowodzeniem w momencie uaktualnienia zgodnie z określonymi zasadami kondycji.
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 :
Najpierw badanie błędów kontroli kondycji wymaga zrozumienia modelu kondycji usługi Service Fabric. Ale nawet bez takiego szczegółowego zrozumienia możemy zobaczyć, że dwie usługi są w złej kondycji: fabric:/DemoApp/Svc3 i fabric:/DemoApp/Svc2 wraz z raportami o kondycji błędów ("InjectedFault" w tym przypadku). W tym przykładzie dwie z czterech usług są w złej kondycji, co jest poniżej domyślnego celu 0% w złej kondycji (MaxPercentUnhealthyServices).
Uaktualnienie zostało zawieszone po niepowodzeniu przez określenie błęduAkcja ręcznego podczas uruchamiania uaktualnienia. Ten tryb umożliwia nam zbadanie systemu na żywo w stanie niepowodzenia przed podjęciem dalszych działań.
Odzyskiwanie po zawieszonym uaktualnieniu
W przypadku niepowodzenia wycofywania nie jest wymagane odzyskiwanie, ponieważ uaktualnienie automatycznie cofa się po awarii. W przypadku ręcznej misji FailureAction dostępnych jest kilka opcji odzyskiwania:
- wyzwalanie wycofywania
- Przejdź do pozostałej części uaktualnienia ręcznie
- Wznawianie monitorowanego uaktualnienia
Polecenie Start-ServiceFabricApplicationRollback można użyć w dowolnym momencie, aby rozpocząć wycofywanie aplikacji. Po pomyślnym powrocie polecenia żądanie wycofania zostało zarejestrowane w systemie i rozpoczyna się wkrótce potem.
Za pomocą polecenia Resume-ServiceFabricApplicationUpgrade można ręcznie przejść przez pozostałą część uaktualnienia— jedną domenę uaktualnienia naraz. W tym trybie system przeprowadza tylko kontrole bezpieczeństwa. Nie są wykonywane żadne kontrole kondycji. To polecenie może być używane tylko wtedy, gdy w obszarze UpgradeState jest wyświetlana wartość RollingForwardPending, co oznacza, że bieżąca domena uaktualnienia zakończyła uaktualnianie, ale następne nie zostało uruchomione (oczekujące).
Polecenie Update-ServiceFabricApplicationUpgrade może służyć do wznowienia monitorowanego uaktualnienia zarówno przy przeprowadzaniu kontroli bezpieczeństwa, jak i kondycji.
Update-ServiceFabricApplicationUpgrade fabric:/DemoApp -UpgradeMode Monitored
UpgradeMode : Monitored
ForceRestart :
UpgradeReplicaSetCheckTimeout :
FailureAction :
HealthCheckWaitDuration :
HealthCheckStableDuration :
HealthCheckRetryTimeout :
UpgradeTimeout :
UpgradeDomainTimeout :
ConsiderWarningAsError :
MaxPercentUnhealthyPartitionsPerService :
MaxPercentUnhealthyReplicasPerPartition :
MaxPercentUnhealthyServices :
MaxPercentUnhealthyDeployedApplications :
ServiceTypeHealthPolicyMap :
Uaktualnienie jest kontynuowane z domeny uaktualniania, w której zostało ostatnio zawieszone, i użyj tych samych parametrów uaktualnienia i zasad kondycji, jak poprzednio. W razie potrzeby dowolny z parametrów uaktualnienia i zasad kondycji pokazanych w poprzednich danych wyjściowych można zmienić w tym samym poleceniu po wznowieniu uaktualniania. W tym przykładzie uaktualnienie zostało wznowione w trybie monitorowanym z parametrami i zasadami kondycji bez zmian.
Dalsze kroki rozwiązywania problemów
Usługa Service Fabric nie jest przestrzegana określonych zasad kondycji
Możliwa przyczyna 1:
Usługa Service Fabric tłumaczy wszystkie wartości procentowe na rzeczywistą liczbę jednostek (na przykład replik, partycji i usług) na potrzeby oceny kondycji i zawsze zaokrągla do całych jednostek. Jeśli na przykład maksymalna wartość MaxPercentUnhealthyReplicasPerPartition wynosi 21% i istnieje pięć replik, usługa Service Fabric zezwala na maksymalnie dwie repliki w złej kondycji (czyli).Math.Ceiling (5*0.21) W związku z tym należy odpowiednio ustawić zasady kondycji.
Możliwa przyczyna 2:
Zasady kondycji są określane pod względem wartości procentowych łącznej liczby usług, a nie określonych wystąpień usługi. Na przykład przed uaktualnieniem, jeśli aplikacja ma cztery wystąpienia usług A, B, C i D, gdzie usługa D jest w złej kondycji, ale z niewielkim wpływem na aplikację. Chcemy zignorować znaną usługę w złej kondycji podczas uaktualniania i ustawić parametr MaxPercentUnhealthyServices na 25%, przy założeniu, że tylko wartości A, B i C muszą być w dobrej kondycji.
Jednak podczas uaktualniania D może stać się w dobrej kondycji, gdy język C staje się w złej kondycji. Uaktualnienie nadal powiedzie się, ponieważ tylko 25% usług jest w złej kondycji. Jednak może to spowodować nieprzewidziane błędy z powodu nieoczekiwanej złej kondycji języka C zamiast D. W takiej sytuacji D należy modelować jako inny typ usługi niż A, B i C. Ponieważ zasady kondycji są określone dla typu usługi, do różnych usług można zastosować różne progi procentowe w złej kondycji.
Nie określono zasad kondycji dla uaktualnienia aplikacji, ale uaktualnienie nadal kończy się niepowodzeniem przez pewien limit czasu, którego nigdy nie określono
Jeśli zasady kondycji nie są dostarczane do żądania uaktualnienia, są pobierane z ApplicationManifest.xml bieżącej wersji aplikacji. Jeśli na przykład uaktualniasz aplikację X z wersji 1.0 do wersji 2.0, używane są zasady kondycji aplikacji określone w wersji 1.0. Jeśli do uaktualnienia należy użyć innych zasad kondycji, należy określić zasady w ramach wywołania interfejsu API uaktualniania aplikacji. Zasady określone w ramach wywołania interfejsu API mają zastosowanie tylko podczas uaktualniania. Po zakończeniu uaktualniania używane są zasady określone w ApplicationManifest.xml .
Określono nieprawidłowe limity czasu
Być może zastanawiasz się, co się stanie, gdy limity czasu są ustawione w spójny sposób. Na przykład może istnieć wartość UpgradeTimeout mniejsza niż wartość UpgradeDomainTimeout. Odpowiedź brzmi, że zwracany jest błąd. Błędy są zwracane, jeśli wartość UpgradeDomainTimeout jest mniejsza niż suma parametrów HealthCheckWaitDuration i HealthCheckRetryTimeout lub wartość UpgradeDomainTimeout jest mniejsza niż suma parametru HealthCheckWaitDuration i HealthCheckStableDuration.
Moje uaktualnienia trwają zbyt długo
Czas ukończenia uaktualnienia zależy od określonych kontroli kondycji i limitów czasu. Kontrole kondycji i przekroczenia limitu czasu zależą od tego, jak długo trwa kopiowanie, wdrażanie i stabilizacja aplikacji. Zbyt agresywny z przekroczeniami limitu czasu może oznaczać więcej nieudanych uaktualnień, dlatego zalecamy rozpoczęcie konserwatywnie z dłuższymi limitami czasu.
Poniżej przedstawiono szybsze odświeżanie sposobu interakcji limitu czasu z czasem uaktualniania:
Uaktualnienia domeny uaktualnienia nie mogą zakończyć się szybciej niż HealthCheckWaitDuration HealthCheckStableDuration + .
Niepowodzenie uaktualniania nie może wystąpić szybciej niż HealthCheckWaitDuration + HealthCheckRetryTimeout.
Czas uaktualniania domeny uaktualnienia jest ograniczony przez wartość UpgradeDomainTimeout. Jeśli healthCheckRetryTimeout i HealthCheckStableDuration są zarówno inne niż zero, jak i kondycja aplikacji nadal przełącza się tam i z powrotem, uaktualnienie zostanie ostatecznie przekroczone na upgradeDomainTimeout. UpgradeDomainTimeout rozpoczyna odliczanie po rozpoczęciu uaktualniania bieżącej domeny uaktualnienia.
Następne kroki
Uaktualnianie aplikacji przy użyciu programu Visual Studio przeprowadzi Cię przez proces uaktualniania aplikacji przy użyciu programu Visual Studio.
Uaktualnianie aplikacji przy użyciu programu PowerShell przeprowadzi Cię przez proces uaktualniania aplikacji przy użyciu programu PowerShell.
Kontrolowanie sposobu uaktualniania aplikacji przy użyciu parametrów uaktualniania.
Uściślij zgodność aplikacji, ucząc się, jak używać serializacji danych.
Dowiedz się, jak używać zaawansowanych funkcji podczas uaktualniania aplikacji, korzystając z tematów zaawansowanych.