Не удается удалить приложение Service Fabric

Я развернул приложение в автономном кластере из 5 узлов. Развертывание выполнено успешно. Но приложение не запускалось из-за какой-то ошибки в приложении. Я попытался удалить приложение из кластера с помощью Service Fabric Explorer, но это не удалось.

Состояние работоспособности приложения - «Ошибка», а состояние - «Удаление». Приложение имеет 9 служб. 6 служб показывают состояние здоровья «Неизвестно» со знаком вопроса и статус «Неизвестно». 3 службы показывают состояние работоспособности «ОК», но со статусом «Удаление».

Я также пытался удалить его с помощью PowerShell:

Remove-ServiceFabricApplication -ApplicationName fabric:/appname -Force -ForceRemove

В результате истекло время ожидания операции.

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

Connect-ServiceFabricCluster -ConnectionEndpoint localhost:19000

$nodes = Get-ServiceFabricNode

foreach($node in $nodes)
{
    $replicas = Get-ServiceFabricDeployedReplica -NodeName $node.NodeName -  ApplicationName "fabric:/MyApp"

    foreach ($replica in $replicas)
    {
        Remove-ServiceFabricReplica -ForceRemove -NodeName $node.NodeName -PartitionId $replica.Partitionid -ReplicaOrInstanceId $replica.ReplicaOrInstanceId
    }
}

Также безрезультатно, скрипт не нашел реплики для удаления.

В то же время мы начали удалять приложение, одна из системных служб также изменила состояние. Служба Fabric: / System / NamingService показывает состояние работоспособности «Предупреждение». Это в разделе 00000000-0000-0000-0000-000000001002. Первичная реплика показывает:
Неработоспособное событие: SourceId = 'System.NamingService', Property = 'Duration_PrimaryRecovery', HealthState = 'Warning', ThinkrWarningAsError = false. PrimaryRecovery, начатый 06.10.2016 07: 55: 21.252, занимает больше 30: 00.000.

Я также перезапустил каждый узел (1 на тот момент) безрезультатно.

Как принудительно удалить приложение без воссоздания кластера, потому что это не вариант для производственной среды.


azure-service-fabric
person Rob Koenis    schedule 06.10.2016    source источник

Ответы (2)


arrow_upward
7
arrow_downward

Да, это может произойти, если вы не позволите своему коду выйти из RunAsync или Open / Close вашего ICommunicationListener.

Немного предыстории:

У вашей службы есть жизненный цикл, управляемый Service Fabric. Этим управляет небольшой компонент в вашем сервисе - вы знаете его как FabricRuntime. Для экземпляров службы без сохранения состояния это простой жизненный цикл открытия / закрытия. Для сервисов с отслеживанием состояния это немного сложнее. Реплика службы с отслеживанием состояния открывается и закрывается, но также меняет роль между первичной, вторичной и нулевой. Изменения жизненного цикла инициируются Service Fabric и отображаются в вашем коде как вызов метода или триггер токена отмены. Например, когда реплика переключается на основную, мы вызываем ваш метод RunAsync. Когда он переключается с основного на что-то еще или ему необходимо выключить, срабатывает токен отмены. В любом случае система ждет, пока вы завершите свою работу.

Когда вы удаляете службу, мы говорим вашей службе сменить роль и закрыть. Если ваш код не отвечает, он застрянет в этом состоянии.

Чтобы выйти из этого состояния, вы можете запустить Remove-ServiceFabricReplica -ForceRemove. Это по существу удаляет реплику из системы - что касается Service Fabric, реплики больше нет. Но ваш процесс все еще работает. Так что вы должны пойти и убить процесс.

person Vaclav Turecek    schedule 08.10.2016
comment
Спасибо за повтор. Я решил это. Я уже пробовал использовать Remove-ServiceFabricReplica с образцом сценария в моем вопросе. Но из-за ошибки в скрипте, который я использовал, id не работал. Я исправил свой сценарий и устранил проблему. И для этого приложения не было запущено ни одного процесса на каком-либо узле. После удаления приложения исчезло и предупреждение на de NamingService. - person Rob Koenis; 10.10.2016
comment
Вы обновили свой сценарий выше, чтобы исправить обнаруженную ошибку? - person Stevieboy84; 21.09.2018

arrow_upward
0
arrow_downward

Ошибка в сценарии связана с «- ApplicationName» и должна быть «-ApplicationName».

И после исправления параметра этот DID удаляет замороженные части и возвращает меня, чтобы иметь возможность исправить и повторно развернуть приложение в кластере.

person Darren Ford    schedule 22.05.2019