Участник или служба Service Fabric становятся случайными недоступными после обновления до SDK 2.3.301

После обновления SDK Service Fabric 2.0.135 до 2.3.301 мы начали сталкиваться с ситуациями, когда субъект или служба Service Fabric недоступны, несмотря на то, что в Service Fabric Explorer отображается как работоспособный. Находясь в этом состоянии, любой вызов субъекта или службы через ActorProxy или ServiceProxy будет зависать на 5 минут, прежде чем окончательно выдаст исключение TimeoutException. Находясь в этом состоянии, субъект или служба никогда не восстанавливаются сами по себе, даже если оставить их на час. Единственное решение - сбросить узлы, на которых находится субъект или служба, повторно развернуть субъект или службу (точно такой же EXE), сбросить весь кластер или перезагрузить все машины кластера.

Обычно он попадает в это состояние после развертывания или повторного развертывания приложения SF.

За последний год работы с Service Fabric (начиная с SDK v1.3) у нас никогда не было этой проблемы. Это началось только после перехода на 2.3.301.

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

Есть ли у кого-нибудь идеи, как мы могли бы решить эту проблему? Это похоже на ошибку в последней версии Service Fabric, но, возможно, мы делаем что-то не так со своей стороны.

Любая помощь приветствуется.

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

Большое спасибо

Шаги

У меня действительно нет шагов, чтобы постоянно воспроизводить проблему. Это просто то, что я иногда наблюдаю.

  1. Я скомпилировал, а затем повторно развернул свой проект SF из Visual Studio (Отладка -> Начать без отладки)
  2. Visual Studio сообщает, что успешно развернула проект.
  3. Service Fabric Explorer показывает все мои службы как работоспособные, включая привязку данных
  4. Рассматриваемый проект SF имеет 2 актера, которые являются частью одного EXE. Обозреватель Service Fabric показывает, что каждый из этих субъектов работает на разных узлах.
  5. Диспетчер задач Windows показывает две запущенные копии EXE, что имеет смысл, поскольку есть два узла, на которых запущен EXE.

Точно так же наш QA испытывает проблему после развертывания в Azure напрямую с помощью PowerShell. (Он не выполняет развертывание из Visual Studio.)

Резюме

  • Visual Studio сообщает, что развертывание прошло успешно
  • Service Fabric Explorer показывает, что все в порядке
  • Диспетчер задач показывает две запущенные копии EXE

Когда я вижу неудачу

У меня одна служба SF вызывает другую службу SF с использованием классов ServiceProxy или ActorProxy. Мы делаем это во всем нашем решении с комбинацией 13 различных приложений и около 25 различных сервисов и участников. Он успешно работает с тех пор, как мы начали работать с Service Fabric SDK v1.3 в ноябре 2015 года.

Теперь, после обновления до 2.3.301, мы периодически сталкиваемся с тем, что случайный Актер или Сервис попадает в состояние, когда он не может ответить на вызов метода при вызове из ServiceProxy или ActorProxy. После 5 минут зависания мы получаем исключение System.Timeout со следующим сообщением:

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

Обратите внимание, что служба НЕ занята и не выполняет длительную операцию. Как актер, служба вообще не выполняет каких-либо текущих операций. Он просто предоставляет общедоступные методы, которые могут использовать другие службы. Не получается с первого звонка.

Фактически, трассировка показывает нам, что даже первая строка метода в акторе never вызывается. Это как если бы коммуникационная инфраструктура Service Fabric не могла доставить сообщение.

Когда это началось

За последние 12 месяцев мы ни разу не видели эту проблему.

Теперь с момента обновления Service Fabric на прошлой неделе мы сталкиваемся с этой проблемой часто и при различных условиях.

Мы обновляем до Service Fabric SDK 2.3.301.9590 и Service Fabric 5.3.301.9590.

Сначала каждый разработчик в команде сталкивался с проблемой самостоятельно, и каждый думал, что это временная проблема, связанная только с нашими машинами. У Service Fabric есть некоторые проблемы, поэтому мы просто принимаем это и идем дальше. Но потом мы начали жаловаться друг другу и поняли, что все это видим. Даже наши QA видят это в облаке в нашей среде, которая скоро будет запущена в производство.

Опять же, это началось только тогда, когда мы на прошлой неделе обновились до последней версии Service Fabric.

Раньше мы использовали Service Fabric SDK 2.0.135.

Мы обновили нашу кодовую базу, установив SDK v 2.3.301, открыв каждое из наших решений и позволив Visual Studio выполнить обновление.

Окружающая среда

Я запускаю новую установку Windows 10 Enterprise (установил ее менее двух недель назад) на i7 с 16 гигабайтами ОЗУ. У меня свежая установка Visual Studio 2015 Update 3 и SF 2.3.301.9590. Установил все чисто. Никаких обновлений.

Это также происходит на всех машинах моих коллег (разного возраста, конфигурации и «свежести»). Это случается спорадически с каждым из нас.

Что наиболее важно, это также происходит на наших виртуальных машинах Service Fabric в Azure. Это машины, которые наш QA создал около месяца назад с использованием стандартных шаблонов для виртуальных машин Service Fabric в Azure. На нем была предустановлена ​​версия 5.3.301.9590. Он не устанавливал вручную никаких обновлений для Service Fabric. Наше приложение на основе SF не сталкивалось с этой проблемой в Azure (или на наших собственных машинах разработчиков) до тех пор, пока разработчики не обновились до новой версии.

Это не моя машина и не изолирована только от среды разработки. Единственное последовательное изменение для всех нас - это обновление версии SF.

Причина

Мы не знаем, чем это вызвано.

Обычно это происходит сразу после развертывания нового приложения SF. Да, мы ждем обычные 2 или 3 минуты, необходимые SF, чтобы «разобраться» после развертывания. Мы оставили его на час или больше, и он просто не работает.

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

Возможности

Как только служба SF окажется в этом «недоступном» состоянии, Service Fabric больше не сможет выйти из этого состояния. Приложение полностью непригодно для использования. С разной степенью успеха мы делаем следующее:

  • Повторно разверните недоступное приложение SF
  • Перезапустите узлы (через Service Fabric Explorer, перейдя к узлу, нажав кнопку с многоточием и выбрав параметр «Перезапустить»), на которых размещены недоступные службы и субъекты SF.
  • Перезагрузите весь кластер SF (остановите, затем запустите)
  • Перезагрузите все машины, на которых запущен узел SF.
  • Сбросьте весь кластер и повторно разверните все (в крайнем случае, но это было необходимо несколько раз)

Интересно, что не помогает использование диспетчера задач для уничтожения вредоносных процессов. Если я убью вызывающий нарушение процесс, Service Fabric перезапустит его (как и ожидалось), но он по-прежнему не будет отвечать на сообщения.

Таким образом, проблема, похоже, связана с самой Service Fabric, а не с EXE.

Конечно, это вовсе не «решения», потому что они оставляют все наше приложение недоступным до тех пор, пока SF не перезапустится / не перебалансируется. Даже перезапуск нескольких узлов отключает кучу вещей.

По сути, это остановка для нас. Мы не сможем запустить наше приложение в производственную (или даже бета-версию) с таким поведением Service Fabric.

Исключение C # при использовании прокси-сервера службы или прокси-исполнителя:

Отображение исключения в формате JSON, созданного ActorProxy или ServicePRoxy

"exception": {
    "ClassName": "System.TimeoutException",
    "Message": "This can happen if message is dropped when service is busy or its long running operation and taking more time than configured Operation Timeout.",
    "Data": null,
    "InnerException": null,
    "HelpURL": null,
    "StackTraceString": "   at Microsoft.ServiceFabric.Services.Communication.Client.ServicePartitionClient`1.<InvokeWithRetryAsync>d__7`1.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n   at Microsoft.ServiceFabric.Services.Remoting.Client.ServiceRemotingPartitionClient.<InvokeAsync>d__8.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n   at Microsoft.ServiceFabric.Services.Remoting.Builder.ProxyBase.<InvokeAsync>d__0.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n   at Microsoft.ServiceFabric.Services.Remoting.Builder.ProxyBase.<ContinueWithResult>d__7`1.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n   at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()\r\n   at RenderingCachingEngine.RenderingCachingEngine.<Render>d__10.MoveNext() in C:\\Code\\Ink\\Dev\\Current\\Source\\Rendering Service Fabric\\RenderingCachingEngine\\RenderingCachingEngine.cs:line 381",
    "RemoteStackTraceString": null,
    "RemoteStackIndex": 0,
    "ExceptionMethod": "8\nMoveNext\nMicrosoft.ServiceFabric.Services, Version=5.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35\nMicrosoft.ServiceFabric.Services.Communication.Client.ServicePartitionClient`1+<InvokeWithRetryAsync>d__7`1\nVoid MoveNext()",
    "HResult": -2146233083,
    "Source": "Microsoft.ServiceFabric.Services",
    "WatsonBuckets": null
  }

Вот рендеринг информации Service Fabric в формате JSON:

  "serviceFabricInfo": {
    "serviceFabricServiceName": "fabric:/Rendering/RenderingCachingEngine",
    "serviceFabricServiceTypeName": "RenderingCachingEngineType",
    "serviceFabricReplicaId": 131225099453058851,
    "serviceFabricPartitionId": "e400087d-8a08-4dab-bcdd-1f5ce82f374f",
    "serviceFabricApplicationName": "fabric:/Rendering",
    "serviceFabricApplicationTypeName": "RenderingType",
    "serviceFabricNodeName": "_Node_4"
  }

Журналы средства просмотра событий при повторном развертывании

Средство просмотра событий Windows показывает некоторые заслуживающие внимания журналы в разделе «Журналы приложений и служб -> Microsoft-Service Fabric -> Администратор».

Следующие журналы произошли, когда я повторно развертывал обновленную версию своего приложения (обратите внимание, что DataBinding.exe - это имя EXE, содержащего два моих субъекта SF):

Log Name:      Microsoft-ServiceFabric/Admin
Source:        Microsoft-ServiceFabric
Date:          11/2/2016 2:38:53 PM
Event ID:      256
Task Category: Common
Level:         Error
Keywords:      Default
User:          NETWORK SERVICE
Computer:      shayward10.ovx.local
Description:
WriteNode failed. HRESULT=-2147467259, Output=CustomOutput
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-ServiceFabric" Guid="{CBD93BC2-71E5-4566-B3A7-595D8EECA6E8}" />
    <EventID>256</EventID>
    <Version>0</Version>
    <Level>2</Level>
    <Task>1</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8000000000000001</Keywords>
    <TimeCreated SystemTime="2016-11-02T18:38:53.678587200Z" />
    <EventRecordID>7620</EventRecordID>
    <Correlation />
    <Execution ProcessID="4440" ThreadID="7360" />
    <Channel>Microsoft-ServiceFabric/Admin</Channel>
    <Computer>shayward10.ovx.local</Computer>
    <Security UserID="S-1-5-20" />
  </System>
  <EventData>
    <Data Name="id">
    </Data>
    <Data Name="type">XmlLiteWriter</Data>
    <Data Name="text">WriteNode failed. HRESULT=-2147467259, Output=CustomOutput</Data>
  </EventData>
</Event>

Log Name:      Microsoft-ServiceFabric/Admin
Source:        Microsoft-ServiceFabric
Date:          11/2/2016 2:38:54 PM
Event ID:      23073
Task Category: Hosting
Level:         Warning
Keywords:      Default
User:          SYSTEM
Computer:      shayward10.ovx.local
Description:
ServiceHostProcess: DataBinding.exe for ApplicationId 805915c7-456c-49d3-af95-62cc44650664 terminated unexpectedly with exit code 3221225786 on node id bf865279ba277deb864a976fbf4c200e
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-ServiceFabric" Guid="{CBD93BC2-71E5-4566-B3A7-595D8EECA6E8}" />
    <EventID>23073</EventID>
    <Version>0</Version>
    <Level>3</Level>
    <Task>90</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8000000000000001</Keywords>
    <TimeCreated SystemTime="2016-11-02T18:38:54.820567800Z" />
    <EventRecordID>7621</EventRecordID>
    <Correlation />
    <Execution ProcessID="6944" ThreadID="3812" />
    <Channel>Microsoft-ServiceFabric/Admin</Channel>
    <Computer>shayward10.ovx.local</Computer>
    <Security UserID="S-1-5-18" />
  </System>
  <EventData>
    <Data Name="id">bf865279ba277deb864a976fbf4c200e</Data>
    <Data Name="AppId">805915c7-456c-49d3-af95-62cc44650664</Data>
    <Data Name="ReturnCode">3221225786</Data>
    <Data Name="ProcessName">DataBinding.exe</Data>
  </EventData>
</Event>

Log Name:      Microsoft-ServiceFabric/Admin
Source:        Microsoft-ServiceFabric
Date:          11/2/2016 2:38:56 PM
Event ID:      256
Task Category: Common
Level:         Error
Keywords:      Default
User:          NETWORK SERVICE
Computer:      shayward10.ovx.local
Description:
WriteNode failed. HRESULT=-2147467259, Output=CustomOutput
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-ServiceFabric" Guid="{CBD93BC2-71E5-4566-B3A7-595D8EECA6E8}" />
    <EventID>256</EventID>
    <Version>0</Version>
    <Level>2</Level>
    <Task>1</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8000000000000001</Keywords>
    <TimeCreated SystemTime="2016-11-02T18:38:56.261857600Z" />
    <EventRecordID>7627</EventRecordID>
    <Correlation />
    <Execution ProcessID="4440" ThreadID="8564" />
    <Channel>Microsoft-ServiceFabric/Admin</Channel>
    <Computer>shayward10.ovx.local</Computer>
    <Security UserID="S-1-5-20" />
  </System>
  <EventData>
    <Data Name="id">
    </Data>
    <Data Name="type">XmlLiteWriter</Data>
    <Data Name="text">WriteNode failed. HRESULT=-2147467259, Output=CustomOutput</Data>
  </EventData>
</Event>

Средство просмотра событий регистрирует время ожидания

Когда служба находится в недоступном состоянии, попытка ее вызова дает следующий журнал для каждого запроса (после ожидания в течение 5 минут):

Log Name:      Microsoft-ServiceFabric/Admin
Source:        Microsoft-ServiceFabric
Date:          11/2/2016 2:44:55 PM
Event ID:      44289
Task Category: FabricTransport
Level:         Warning
Keywords:      Default
User:          NETWORK SERVICE
Computer:      shayward10.ovx.local
Description:
Error While Sending Message : FABRIC_E_TIMEOUT
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-ServiceFabric" Guid="{CBD93BC2-71E5-4566-B3A7-595D8EECA6E8}" />
    <EventID>44289</EventID>
    <Version>0</Version>
    <Level>3</Level>
    <Task>173</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8000000000000001</Keywords>
    <TimeCreated SystemTime="2016-11-02T18:44:55.349048200Z" />
    <EventRecordID>7629</EventRecordID>
    <Correlation />
    <Execution ProcessID="18600" ThreadID="8076" />
    <Channel>Microsoft-ServiceFabric/Admin</Channel>
    <Computer>shayward10.ovx.local</Computer>
    <Security UserID="S-1-5-20" />
  </System>
 <EventData>
    <Data Name="id">
    </Data>
    <Data Name="type">ServiceCommunicationClient</Data>
    <Data Name="text">Error While Sending Message : FABRIC_E_TIMEOUT</Data>
  </EventData>
</Event>

person Shaun    schedule 03.11.2016    source источник


Ответы (2)


Эта проблема может возникнуть в двух случаях.

  1. Если обработка вашего метода ActorService занимает больше времени, чем время ожидания по умолчанию, вам необходимо изменить значение OperationTimeout. По умолчанию это 5 минут. Если вы хотите изменить время ожидания, вы можете изменить его, добавив сборку FabricTransportServiceRemotingProviderAttribute в свою клиентскую сборку.

https://msdn.microsoft.com/en-us/library/microsoft.servicefabric.services.remoting.fabrictransport.fabrictransportserviceremotingproviderattribute.aspx

  1. If first scenario is not the case, then you can try below mitigation for a known bug.
    • Specify Port 0 in the Service Manifest for the ActorService endpoint. By default, ActorEndpoint will be listed in ServiceManifest but port won’t be there.

Так будет выглядеть ActorService после внесения изменений.

<Endpoint Name="Actor1ActorServiceEndpoint" Port="0" />

Мы знаем о проблеме, и ее решение уже готово.

person MSFT-SuchiAgicha    schedule 04.11.2016
comment
Привет @ MSFT-TheniAgicha, является ли проблема конкретным субъектом или нужно применить один и тот же обходной путь ко всем службам с отслеживанием состояния? Как насчет конечных точек Replicator? Было бы очень полезно немного больше деталей. Спасибо - person d_z; 22.11.2016
comment
@ MSFT-TheniAgicha было ли исправление для этого, или есть где-нибудь, где мы можем отследить проблему? - person jflood.net; 20.07.2017

В случае, если это поможет кому-то, мы видели эти таймауты при длительных (более 5 минут) операциях. Следуя подсказке Сучи о FabricTransportServiceRemotingProviderAttribute, мы добавили следующие строки в наши проекты SF AssemblyInfo.cs, чтобы увеличить время ожидания до 1 часа.

[assembly: FabricTransportServiceRemotingProvider(OperationTimeoutInSeconds = 3600)]
[assembly: FabricTransportActorRemotingProvider(OperationTimeoutInSeconds = 3600)]

(Также обратите внимание, что если вы используете служебные шины Azure, максимальное время блокировки составляет 5 минут, поэтому вам придется реализовать код обновления блокировки для поддержки длительных операций)

person Taran    schedule 16.05.2018