Запуск службы Windows в качестве службы с полным состоянием в Service Fabric

Question

У меня есть три программы .net, которые в настоящее время работают как службы Windows. Мы переходим на Service Fabric, и у меня есть несколько вопросов. Наша цель - перенести службы в службу StateFul, поскольку нам необходимо отслеживать расположение файлов, размер пакета и т. Д., Которые в данный момент хранятся в файле app.config. Таким образом, мы можем «поднять и переместить» код из события onTimer в RunAsync, как обсуждалось в этом вопросе stackoverflow: Как выполнить миграцию службы Windows в Azure Service Fabric

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

Should we only deploy the service to one node and use the reliable 
collection to maintain the state of the process should the node go down and 
have to be brought back up?  

Or, should we deploy the application to say 3 nodes and just have each 
application on their node check the reliable collection to see if another 
application is processing files and to wait? 
files?

Приложение «проснется» через определенный интервали посмотрите на папку, если в ней есть какие-либо файлы, она их обработает. Это может занять от нескольких секунд до нескольких минут. Таким образом, если приложение находится на трех узлах, вполне возможно, что два других приложения на их узлах проснутся для обработки файлов. Если бы они могли проверить надежный словарь, чтобы увидеть, выполняет ли обработка файлов один из других экземпляров приложения, они бы просто подождали до следующего раза, когда они понадобятся.

Я знаю, что это расплывчато, яищете вход для запуска приложения на нескольких узлах или на одном узле?

Answer 1

Короче говоря: сервисы statefull имеют разделенные данные . Таким образом, у вас будет хотя бы один и, возможно, более одного раздела. Для каждого раздела будет запущен основной экземпляр, обслуживающий запросы или выполняющий работу. Тогда для каждого первичного экземпляра будут некоторые вторичные экземпляры, которые вступят во владение, когда первичный отказывает. Подробнее здесь .

В конфигурации службы вы указываете количество разделов и количество реплик:

<Service Name="Processing">
<StatefulService ServiceTypeName="ProcessingType" TargetReplicaSetSize="[Processing_TargetReplicaSetSize]" MinReplicaSetSize="[Processing_MinReplicaSetSize]">
    <UniformInt64Partition PartitionCount="[Processing_PartitionCount]" LowKey="0" HighKey="25" />
</StatefulService>
</Service>

Первичные и вторичные экземпляры (реплики)будет распределен по узлам кластера, поэтому, например, когда узел, на котором выполняется экземпляр primairy, выходит из строя, реплика на другом узле вступает во владение.

Это больше, чем я описал, но это основнойидея всего этого.

Итак, чтобы ответить на ваш вопрос: вы должны указать достаточно реплик на других узлах, чтобы гарантировать высокую доступность.