Поделиться через

Устранение неполадок при обновлениях приложений

  • Статья

В этой статье рассматриваются некоторые распространенные проблемы по обновлению приложения Azure Service Fabric и их устранению.

Устранение неполадок при сбое обновления приложения

При сбое обновления выходные данные команды Get-ServiceFabricApplicationUpgrade содержат дополнительные сведения об отладке сбоя. В следующем списке указывается, как можно использовать дополнительные сведения:

  1. Определите тип сбоя.
  2. Определите причину сбоя.
  3. Изоляция одного или нескольких компонентов сбоя для дальнейшего изучения.

Эта информация доступна, когда Service Fabric обнаруживает сбой независимо от того , требуется ли откат или приостановка обновления.

Определение типа сбоя

В выходных данных Get-ServiceFabricApplicationUpgradeFailureTimestampUtc указывает на момент времени (в формате UTC), когда Service Fabric обнаружил сбой обновления и было активировано FailureAction. FailureReason определяет одну из трех потенциальных причин сбоя:

  1. UpgradeDomainTimeout — указывает, что определенный домен обновления занял слишком много времени, и UpgradeDomainTimeout истек.
  2. Общий тайм-аут обновления — это указание на то, что процесс обновления занял слишком много времени и истекла продолжительность UpgradeTimeout.
  3. HealthCheck — указывает, что после обновления домена обновления приложение осталось неработоспособным в соответствии с указанными политиками работоспособности и истек срок действия HealthCheckRetryTimeout .

Эти записи отображаются только в выходных данных, когда обновление завершается сбоем и начинает откат. Дополнительные сведения отображаются в зависимости от типа сбоя.

Изучение времени ожидания обновления

Сбои времени ожидания обновления чаще всего вызваны проблемами доступности службы. Выходные данные ниже этого абзаца типичны для обновлений, когда реплики служб или экземпляры не запускались в новой версии кода. Поле UpgradeDomainProgressAtFailure фиксирует состояние незавершенной работы обновления на момент сбоя.

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

В этом примере обновление завершилось сбоем в домене обновления MYUD1, и два раздела (744c8d9f-1d26-417e-a60e-cd48f5c098f0 и 4b43f4d8-b26b-424e-9307-7a7a62e79750) были остановлены. Разделы зависли, так как среда выполнения не смогла разместить первичные реплики (WaitForPrimaryPlacement) на целевых узлах Node1 и Node4.

Команда Get-ServiceFabricNode может использоваться для проверки того, что эти два узла находятся в домене обновления MYUD1. UpgradePhase говорит PostUpgradeSafetyCheck, что означает, что эти проверки безопасности происходят после завершения обновления всех узлов в домене обновления. Все эти сведения указывают на потенциальную проблему с новой версией кода приложения. Наиболее распространенными проблемами являются ошибки обслуживания в открытых путях или при переключении на основные пути кода.

Этап обновленияPreUpgradeSafetyCheck означает, что возникли проблемы при подготовке домена обновления до выполнения процесса. Наиболее распространенными проблемами в этом случае являются системные ошибки при закрытии или переводе с основных кодовых путей.

Текущее состояние обновления UpgradeState — RollingBackCompleted, поэтому первоначальное обновление, видимо, было выполнено с откатом при сбое FailureAction, которое автоматически откатило обновление после сбоя. Если исходное обновление было выполнено вручную FailureAction, обновление вместо этого будет приостановлено, чтобы разрешить динамическую отладку приложения.

В редких случаях поле UpgradeDomainProgressAtFailure может быть пустым, если общее время обновления истекает так же, как система завершает всю работу для текущего домена обновления. В этом случае попробуйте увеличить значения параметров обновления UpgradeTimeout и UpgradeDomainTimeout и повторить обновление.

Изучение сбоев проверки работоспособности

Сбои проверки работоспособности могут быть вызваны различными проблемами, которые могут возникнуть после того, как все узлы в домене обновления завершат обновление и пройдут все проверки безопасности. Выходные данные, приведенные в этом абзаце, типичны для сбоя обновления из-за неудачных проверок работоспособности. Поле НеуспешныеОценки фиксирует моментальный снимок проверок работоспособности, которые завершились сбоем во время обновления в соответствии с указанной политикой работоспособности.

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              :

Для исследования сбоев проверки работоспособности необходимо сначала разобраться в модели работоспособности платформы Service Fabric. Но даже без такого глубокого понимания можно увидеть, что две службы неработоспособны: fabric:/DemoApp/Svc3 и fabric:/DemoApp/Svc2, а также отчеты о проблемах с работоспособностью ("InjectedFault" в этом случае). В этом примере два из четырех служб являются неработоспособными, что ниже целевого объекта по умолчанию 0% неработоспособных (MaxPercentUnhealthyServices).

Обновление было приостановлено при сбое, указав FailureAction вручную при запуске обновления. Этот режим позволяет исследовать динамическую систему в состоянии сбоя перед выполнением дальнейших действий.

Восстановитесь после приостановки обновления

При откате FailureAction восстановление не требуется, так как обновление автоматически откатывается после сбоя. При использовании вручную FailureAction существует несколько вариантов восстановления:

  1. запустить откат
  2. Продолжите выполнение остальной части обновления вручную
  3. Возобновление отслеживаемого обновления

Команду Start-ServiceFabricApplicationRollback можно использовать в любое время для запуска отката приложения. После успешного возврата команды запрос отката был зарегистрирован в системе и начнется вскоре после этого.

Команду Resume-ServiceFabricApplicationUpgrade можно использовать для продолжения обновления вручную, одного домена обновления за раз. В этом режиме система выполняет только проверки безопасности. Больше не выполняются проверки состояния. Эта команда может использоваться только в том случае, если в разделе UpgradeState отображается RollingForwardPending, что означает, что текущий домен обновления завершил обновление, но следующий не запущен (ожидается).

Команда Update-ServiceFabricApplicationUpgrade может использоваться для возобновления отслеживаемого обновления с выполнением проверок безопасности и работоспособности.

Update-ServiceFabricApplicationUpgrade fabric:/DemoApp -UpgradeMode Monitored

UpgradeMode                             : Monitored
ForceRestart                            :
UpgradeReplicaSetCheckTimeout           :
FailureAction                           :
HealthCheckWaitDuration                 :
HealthCheckStableDuration               :
HealthCheckRetryTimeout                 :
UpgradeTimeout                          :
UpgradeDomainTimeout                    :
ConsiderWarningAsError                  :
MaxPercentUnhealthyPartitionsPerService :
MaxPercentUnhealthyReplicasPerPartition :
MaxPercentUnhealthyServices             :
MaxPercentUnhealthyDeployedApplications :
ServiceTypeHealthPolicyMap              :

Обновление продолжается с домена обновления, в котором оно было приостановлено и использует те же параметры обновления и политики работоспособности, что и раньше. При необходимости любой из параметров обновления и политик работоспособности, отображаемых в предыдущих выходных данных, можно изменить в той же команде при возобновлении обновления. В этом примере обновление было возобновлено в режиме мониторинга без изменений в параметрах и политиках работоспособности.

Дальнейшее устранение неполадок

Service Fabric не соответствует указанным политикам работоспособности

Возможная причина 1.

Service Fabric преобразует все проценты в фактические числа сущностей (например, реплики, разделы и службы) для оценки работоспособности и всегда округляет до целых чисел сущностей. Например, если максимальное значение MaxPercentUnhealthyReplicasPerPartition равно 21% и имеется пять реплик, то Service Fabric разрешает до двух неработоспособных реплик (т. е.Math.Ceiling (5*0.21)). Таким образом, политики в области здравоохранения должны быть установлены соответствующим образом.

Возможная причина 2.

Политики здравоохранения указываются в процентах от общего объема сервисов, а не в отношении конкретных сервисов. Например, перед обновлением приложение имеет четыре экземпляра службы A, B, C и D, где служба D является неработоспособной, но с небольшим воздействием на приложение. Мы хотим игнорировать известную неисправную службу D во время обновления и задать параметр MaxPercentUnhealthyServices равным 25%, при условии, что работоспособными должны быть только A, B и C.

Однако во время обновления D может стать работоспособным, пока C становится неработоспособным. Обновление всё равно будет успешным, так как только 25% сервисов являются неисправными. Однако это может привести к непредвиденным ошибкам из-за неожиданно неработоспособного C вместо D. В этой ситуации D следует моделировать как другой тип службы от A, B и C. Так как политики работоспособности указаны для каждого типа службы, к разным службам можно применять разные неработоспособные процентные пороги.

Я не указал политику здоровья для обновления приложения, но обновление по-прежнему завершается сбоем из-за некоторых тайм-аутов, которые я никогда не указывал.

Если политики безопасности не предоставляются запросу на обновление, они берутся из ApplicationManifest.xml текущей версии приложения. Например, если вы обновляете Application X с версии 1.0 до версии 2.0, используются политики работоспособности приложений, указанные в версии 1.0. Если для обновления следует использовать другую политику здоровья, необходимо указать политику в составе вызова API обновления приложения. Политики, указанные в рамках вызова API, применяются только во время обновления. После завершения обновления используются политики, указанные в ApplicationManifest.xml .

Указаны неправильные интервалы времени ожидания

Возможно, вы задались вопросом о том, что происходит, когда тайм-ауты задаются несогласованно. Например, у вас может быть UpgradeTimeout, который меньше, чем UpgradeDomainTimeout. Ответ заключается в том, что возвращается ошибка. Ошибки возвращаются, если обновлениеDomainTimeout меньше суммы HealthCheckWaitDuration и HealthCheckRetryTimeout или если UpgradeDomainTimeout меньше суммы HealthCheckWaitDuration и HealthCheckStableDuration.

Мои обновления занимают слишком много времени

Время завершения обновления зависит от указанных проверок работоспособности и времени ожидания. Проверки работоспособности и время ожидания зависят от времени, необходимого для копирования, развертывания и стабилизации приложения. Слишком агрессивное время ожидания может означать больше неудачных обновлений, поэтому мы рекомендуем начать с более длительным временем ожидания.

Ниже приведены быстрые обновления о том, как время ожидания ожидания взаимодействуют с временем обновления:

Обновления для домена обновления не могут завершиться быстрее, чем HealthCheckWaitDuration + HealthCheckStableDuration.

Сбой обновления не может произойти быстрее, чем HealthCheckWaitDuration + HealthCheckRetryTimeout.

Время обновления для домена обновления ограничено UpgradeDomainTimeout. Если HealthCheckRetryTimeout и HealthCheckStableDuration оба ненулевые, и работоспособность приложения продолжает изменяться, то обновление в конечном итоге истекает по времени ожидания UpgradeDomainTimeout. UpgradeDomainTimeout начинает отсчет времени, как только начнется обновление текущего домена.

Дальнейшие действия

Обновление приложения с помощью Visual Studio описывает обновление приложения с помощью Visual Studio.

Обновление приложения с помощью PowerShell позволяет выполнить обновление приложения с помощью PowerShell .

Управление обновлением приложения с помощью параметров обновления.

Сделайте приложение совместимым, научившись использовать сериализацию данных.

Узнайте, как использовать расширенные функциональные возможности при обновлении приложения, ссылаясь на дополнительные разделы.