2016-10-06 1 views
5

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

Состояние здоровья приложения «Ошибка», а статус «Удаление» Приложение имеет 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 
    } 
} 

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

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

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

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

ответ

4

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

Некоторые фона:

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

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

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

+0

Спасибо за повтор. Я решил это. Я уже пробовал использовать Remove-ServiceFabricReplica со сценарием в моем вопросе. Но из-за ошибки в скрипте, который я использовал, id не работал. Я исправил свой скрипт и исправил проблему. И на этом узле не было никакого процесса для этого приложения. После того, как приложение было удалено, предупреждение о дележе NamingService также исчезло. –

 Смежные вопросы

  • Нет связанных вопросов^_^