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 oraz sposoby ich rozwiązywania.
Rozwiązywanie problemów z nieudanym uaktualnieniem aplikacji
W przypadku niepowodzenia uaktualniania 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ę niepowodzenia.
- Wyizoluj co najmniej jeden składnik, który kończy się niepowodzeniem w celu dalszego badania.
Te informacje są dostępne, gdy usługa Service Fabric wykryje błąd niezależnie od tego, czy usługa FailureAction ma wycofać lub wstrzymać uaktualnienie.
Identyfikowanie typu błędu
W danych wyjściowych polecenia Get-ServiceFabricApplicationUpgradeelement FailureTimestampUtc identyfikuje sygnaturę czasową (w formacie UTC), o której wykryto błąd uaktualniania przez usługę Service Fabric i wyzwolono polecenie FailureAction . 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, a 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 następujące po 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 nad uaktualnieniem 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.
Polecenie Get-ServiceFabricNode umożliwia sprawdzenie, 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 wskazuje 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.
UpgradePhasepreUpgradeSafetyCheck oznacza, że wystąpiły problemy z przygotowaniem domeny uaktualnienia przed jej 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ą FailureAction 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 ukończy całą pracę dla bieżącej domeny uaktualnienia. W takim przypadku spróbuj zwiększyć wartości parametrów upgradeTimeout i UpgradeDomainTimeout uaktualnienia, a następnie ponów próbę uaktualnienia.
Badanie błędów kontroli kondycji
Błędy kontroli 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 następujące po tym akapicie są typowe dla niepowodzenia uaktualniania z powodu nieudanych kontroli 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 :
Badanie błędów kontroli kondycji wymaga najpierw 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
Po wycofaniu elementu FailureAction nie jest wymagane odzyskiwanie, ponieważ uaktualnienie jest automatycznie wycofywało się po awarii. W przypadku ręcznego działania FailureAction dostępnych jest kilka opcji odzyskiwania:
- wyzwalanie wycofania
- Przejdź do pozostałej części uaktualnienia ręcznie
- Wznawianie monitorowanego uaktualnienia
Polecenia 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. Tego polecenia można użyć 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 przy użyciu kontroli bezpieczeństwa 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 wykonuje 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 repliki, partycje i usługi) na potrzeby oceny kondycji i zawsze zaokrągla do całości. 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 (czyliMath.Ceiling (5*0.21)). Dlatego należy odpowiednio ustawić zasady kondycji.
Możliwa przyczyna 2:
Zasady dotyczące kondycji są określane jako wartości procentowe łącznej liczby usług, a nie określone wystąpienia usług. 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 język D powinien być modelowany jako inny typ usługi niż A, B i C. Ponieważ zasady kondycji są określane 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 program Application X z wersji 1.0 do wersji 2.0, używane są zasady kondycji aplikacji określone dla 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ą ustawiane spójnie. Możesz na przykład mieć wartość UpgradeTimeout mniejszą niż parametr UpgradeDomainTimeout. Odpowiedź brzmi, że zwracany jest błąd. Błędy są zwracane, jeśli parametr UpgradeDomainTimeout jest mniejszy niż suma parametrów HealthCheckWaitDuration i HealthCheckRetryTimeout lub wartość UpgradeDomainTimeout jest mniejsza niż suma parametrów 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 limity czasu zależą od tego, jak długo trwa kopiowanie, wdrażanie i stabilizacja aplikacji. Zbyt agresywna z limitami 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 limitów czasu z czasem uaktualniania:
Uaktualnienia domeny uaktualnienia nie mogą zakończyć się szybciej niż HealthCheckWaitDurationHealthCheckStableDuration + .
Niepowodzenie uaktualniania nie może wystąpić szybciej niż HealthCheckWaitDuration + HealthCheckRetryTimeout.
Czas uaktualniania domeny uaktualnienia jest ograniczony przez wartość UpgradeDomainTimeout. Jeśli parametr HealthCheckRetryTimeout i HealthCheckStableDuration nie są zerowe, a kondycja aplikacji będzie się przełączać tam iz powrotem, wówczas uaktualnienie zostanie ostatecznie przekroczone limit czasu dla elementu UpgradeDomainTimeout. UpgradeDomainTimeout rozpoczyna odliczanie po rozpoczęciu uaktualniania dla 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.
Opinia
Dostępne już wkrótce: W 2024 r. będziemy stopniowo wycofywać zgłoszenia z serwisu GitHub jako mechanizm przesyłania opinii na temat zawartości i zastępować go nowym systemem opinii. Aby uzyskać więcej informacji, sprawdź: https://aka.ms/ContentUserFeedback.
Prześlij i wyświetl opinię dla