Реплики и экземпляры

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

Экземпляры бессостояных служб

Экземпляр службы без отслеживания состояния — это копия логики службы, которая выполняется на одном из узлов кластера. Экземпляр в разделе однозначно определяется идентификатором InstanceId. Жизненный цикл экземпляра моделиируется на следующей схеме:

InBuild (IB)

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

Если узел или хост приложения для этого экземпляра выходит из строя, он переходит в состояние сброса.

Готово (RD)

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

Если хост приложения или узел для этого экземпляра завершается сбоем, он переходит в состояние сбоя.

Закрытие (CL)

На этапе завершения Azure Service Fabric завершает работу экземпляра на этом узле. Это завершение может быть вызвано многими причинами, например обновление приложения, балансировка нагрузки или удаленная служба. После завершения завершения работы он переходит в удаленное состояние.

Удалено (DD)

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

Примечание.

Вы можете перейти от любого состояния к удаленному состоянию с помощью параметра ForceRemove в Remove-ServiceFabricReplica.

Реплики служб с отслеживанием состояния

Реплика службы с сохранением состояния — это копия служебной логики, работающей на одном из узлов кластера. Кроме того, реплика сохраняет копию состояния этой службы. Две связанные концепции описывают жизненный цикл и поведение состояния реплик.

• Жизненный цикл реплики
• Роль реплики

В следующем обсуждении описываются сервисы с сохранением состояния. Для служб с переменным состоянием (или в памяти) состояние "вниз" и состояние "удалено" эквивалентны.

InBuild (IB)

Реплика InBuild — это реплика, созданная или подготовленная для присоединения к набору реплик. В зависимости от роли реплики IB имеет другую семантику.

Если хост приложения или узел для реплики InBuild завершается с ошибкой, он переходит в состояние неработоспособности.

• Основные реплики InBuild: первичные InBuild — это первые реплики для секции. Эта копия обычно создаётся при создании раздела. Первичные реплики InBuild также возникают, когда все реплики раздела перезапускаются или удаляются.

• Реплики IdleSecondary InBuild: это либо новые реплики, созданные диспетчером ресурсов кластера, либо существующие реплики, которые вышли из строя и нуждаются в добавлении обратно в набор. Эти реплики заполняются или создаются основными, прежде чем они смогут присоединиться к набору реплик как ActiveSecondary и участвовать в подтверждении кворума операций.

• Реплики ActiveSecondary InBuild: это состояние наблюдается в некоторых запросах. Это оптимизация, в которой набор реплик не изменяется, но необходимо создать реплику. Сама реплика следует обычным переходам машины состояний (как описано в разделе о ролях копии).

Готово (RD)

Готовая реплика — это реплика, которая участвует в репликации и признании кворума во время выполнения операций. Готовое состояние применимо к основным и активным вторичным репликам.

Если хост приложения или узел для готовой реплики дает сбой, он переходит в нерабочее состояние.

Закрытие (CL)

Реплика входит в состояние закрытия в следующих сценариях:

• Завершение работы кода для реплики: Service Fabric может потребоваться завершить выполнение кода для реплики. Это отключение может быть по многим причинам. Например, это может произойти из-за обновления приложения, структуры или инфраструктуры или из-за сбоя, сообщаемого репликой. После завершения процедуры закрытия реплика переходит в неактивное состояние. Сохраненное состояние, связанное с этой репликой, которое хранится на диске, не очищается.

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

Удалено (DD)

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

Вниз (D)

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

При необходимости нерабочая реплика активируется Service Fabric, например, когда обновление на узле завершено.

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

Открытие (OP)

Реплика в нерабочем состоянии входит в состояние инициализации, когда Service Fabric необходимо восстановить реплику. Например, это состояние может быть после завершения обновления кода для приложения на узле.

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

Роль реплики не имеет значения в состоянии инициализации.

StandBy (SB)

Реплика StandBy — это реплика службы с постоянным сохранением, которая выключилась и затем была снова запущена. Эта копия может использоваться Service Fabric, если необходимо добавить ещё одну копию в набор копий (поскольку эта копия уже содержит часть состояния, и процесс сборки происходит быстрее). После истечения срока действия StandByReplicaKeepDuration резервная реплика удаляется.

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

Роль реплики не имеет значения в режиме ожидания.

Примечание.

Любая реплика, которая не отключена или не удалена, считается в рабочем состоянии.

Примечание.

Вы можете перейти от любого состояния к удаленному состоянию с помощью параметра ForceRemove в Remove-ServiceFabricReplica.

Роль реплики

Роль реплики определяет ее функцию в наборе реплик:

• Primary (P): в наборе реплик есть один основной объект, отвечающий за выполнение операций чтения и записи.
• ActiveSecondary (S): это реплики, которые получают обновления состояния от основного, применяют их, а затем отправляют обратное подтверждение. В наборе реплики имеются несколько активных вторичных узлов. Число этих активных вторичных файлов определяет количество сбоев, которые может обрабатывать служба.
• IdleSecondary (I): эти реплики создаются основными. Они получают состояние от первичного, прежде чем они могут быть повышены до активной вторичной.
• Нет (N): эти реплики не отвечают за ничего в наборе реплик.
• Неизвестно (U): это начальная роль реплики перед получением любого вызова API ChangeRole из Service Fabric.

На следующей схеме показаны переходы ролей реплик и некоторые примеры сценариев, в которых такие переходы могут происходить:

• U -> P: создание новой первичной реплики.
• U — I:> создание новой пассивной реплики.
• U -> N: удаление резервной реплики.
• I -> S: Продвижение бездействующего вторичного на активную вторичную, чтобы ее признание способствовало кворуму.
• I -> P: перевод бездействующей вторичной в первичную. Это может произойти при специальных перенастройках, когда простой вторичный является правильным кандидатом на роль основного.
• I -> N: удаление неактивной вторичной реплики.
• S -> P: повышение активного вторичного до первичного. Это может быть связано с переключением на резервный сервер основного сервера или перемещением основного сервера, инициированного менеджером ресурсов кластера. Например, это может быть ответом на обновление приложения или балансировку нагрузки.
• S -> N: удаление активной вторичной реплики.
• P -> S: понижение первичной реплики. Это может быть связано с основным перемещением, инициированным диспетчером кластерных ресурсов. Например, это может быть ответом на обновление приложения или балансировку нагрузки.
• P -> N: удаление первичной реплики.

Примечание.

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

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

Дополнительные сведения о концепциях Service Fabric см. в следующей статье:

Жизненный цикл надежных служб — C#