Обновление приложения Service Fabric: дополнительные темы

  • Статья

Добавление или удаление типов служб во время обновления приложения

Если в приложение, которое опубликовано как обновление, добавляется новый тип службы, то он добавляется в развернутое приложение. Подобное обновление не влияет на какие-либо экземпляры служб, которые уже были частью приложения. Однако чтобы активировать новый тип службы, необходимо создать экземпляр типа службы, который был добавлен (см. статью о командлете New-ServiceFabricService).

Точно так же типы служб могут быть удалены из приложения. Но в этом случае перед продолжением обновления все текущие экземпляры удаляемой службы должны быть удалены (см. статью о командлете Remove-ServiceFabricService).

Предотвращение прерываний подключения во время запланированного простоя службы без отслеживания состояния

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

Чтобы избежать этого, настройте функцию RequestDrain, указав в конфигурации службы длительность задержки закрытия экземпляра, чтобы позволить удалять имеющиеся запросы из кластера в открытых конечных точках. Это достигается в результате того, что конечная точка, объявленная экземпляром без отслеживания состояния, удаляется до начала задержки перед закрытием экземпляра. Эта задержка позволяет корректно удалять имеющиеся запросы до того, как экземпляр будет действительно остановлен. Клиенты получают уведомления об изменении конечной точки с помощью функции обратного вызова в самом начале задержки, благодаря чему они могут повторно разрешить конечную точку и избежать отправки новых запросов к экземпляру, который не работает. Эти запросы могут исходить от клиентов, использующих обратный прокси-сервер или API разрешения конечных точек службы с моделью уведомлений (ServiceNotificationFilterDescription) для обновления конечных точек.

Конфигурация службы

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

  • При создании новой службы укажите -InstanceCloseDelayDuration:

    New-ServiceFabricService -Stateless [-ServiceName] <Uri> -InstanceCloseDelayDuration <TimeSpan>

  • При определении службы в разделе по умолчанию манифеста приложения назначьте свойство InstanceCloseDelayDurationSeconds:

          <StatelessService ServiceTypeName="Web1Type" InstanceCount="[Web1_InstanceCount]" InstanceCloseDelayDurationSeconds="15">
          <SingletonPartition />
      </StatelessService>

  • При обновлении имеющейся службы укажите -InstanceCloseDelayDuration:

    Update-ServiceFabricService [-Stateless] [-ServiceName] <Uri> [-InstanceCloseDelayDuration <TimeSpan>]`

  • При создании или обновлении имеющейся службы с помощью шаблона ARM укажите значение InstanceCloseDelayDuration (минимальная поддерживаемая версия API: 2020-03-01):

    {
  "apiVersion": "2020-03-01",
  "type": "Microsoft.ServiceFabric/clusters/applications/services",
  "name": "[concat(parameters('clusterName'), '/', parameters('applicationName'), '/', parameters('serviceName'))]",
  "location": "[variables('clusterLocation')]",
  "dependsOn": [
    "[concat('Microsoft.ServiceFabric/clusters/', parameters('clusterName'), '/applications/', parameters('applicationName'))]"
  ],
  "properties": {
    "provisioningState": "Default",
    "serviceKind": "Stateless",
    "serviceTypeName": "[parameters('serviceTypeName')]",
    "instanceCount": "-1",
    "partitionDescription": {
      "partitionScheme": "Singleton"
    },
    "serviceLoadMetrics": [],
    "servicePlacementPolicies": [],
    "defaultMoveCost": "",
    "instanceCloseDelayDuration": "00:00:30.0"
  }
}

Настройка клиента

Чтобы получать уведомление об изменении конечной точки, клиенты должны зарегистрировать обратный вызов. См. раздел Выборка ServiceNotificationFilterDescription. Уведомление об изменении указывает на то, что конечные точки изменены. Клиент должен повторно разрешить конечные точки, а не использовать те, которые больше не объявлены, так как они скоро перестанут работать.

Необязательные переопределения обновления

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

Start-ServiceFabricApplicationUpgrade [-ApplicationName] <Uri> [-ApplicationTypeVersion] <String> [-InstanceCloseDelayDurationSec <UInt32>]

Start-ServiceFabricClusterUpgrade [-CodePackageVersion] <String> [-ClusterManifestVersion] <String> [-InstanceCloseDelayDurationSec <UInt32>]

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

Примечание

  • Параметры для запросов на удаление не могут запретить службе Azure Load Balancer отправлять новые запросы конечным точкам, которые находятся в процессе удаления.
  • Механизм разрешения на основе жалоб не обеспечивает корректное удаление запросов, так как активирует разрешение службы после сбоя. Как описано выше, это следует улучшить, чтобы подписаться на уведомления об изменениях конечной точки с помощью ServiceNotificationFilterDescription.
  • Параметры не учитываются, если обновление не оказывает влияния, то есть когда реплики не будут удалены во время обновления.
  • Максимально допустимое значение InstanceCloseDelayDuration в описание службы или значение InstanceCloseDelayDurationSec в описании обновления не могут превышать значение параметра кластера FailoverManager.MaxInstanceCloseDelayDurationInSeconds, которое по умолчанию равно 1800 секундам. Чтобы изменить это максимальное значение, необходимо обновить конфигурацию на уровне кластера. Эта конфигурация доступна только в среде выполнения версии 9.0 или более поздней.

Примечание

Как упоминалось выше, эту функцию можно настроить в имеющихся службах с помощью командлета Update-ServiceFabricService или шаблона ARM, если используется версия кода кластера 7.1.XXX или выше.

Ручной режим обновления

Примечание

Для всех обновлений Service Fabric рекомендуется использовать отслеживаемый (Monitored) режим обновления. Режим UnmonitoredManual (неотслеживаемый, ручной) следует использовать только для сбойных или отложенных обновлений.

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

В режиме UnmonitoredManual администратор приложения полностью контролирует процесс обновления. Этот режим удобен, когда применяются настраиваемые политики оценки работоспособности или выполняется нестандартное обновление, чтобы полностью обойти проверки работоспособности (например, приложение уже потеряло некоторые данные). Обновление, выполняющееся в этом режиме, самостоятельно приостанавливается после применения обновлений к каждому домену обновления. Его необходимо возобновить с помощью командлета Resume-ServiceFabricApplicationUpgrade. Когда обновление приостановлено и готово к возобновлению, его состояние изменится на RollforwardPending (Ожидание наката) (см. статью о команде ApplicationUpgradeState Enum).

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

Обновление при помощи пакета diff

Обновления могут выполняться путем подготовки пакетов разностных изменений (вместо полных пакетов приложений), содержащих только обновленные пакеты кода, конфигурации или данных, а также полные манифесты приложений и служб. Для первичной установки приложений в кластер необходимы полные пакеты приложений. При последующих обновлениях могут использоваться либо полные пакеты приложений, либо пакеты разностных изменений (diff).

Любая ссылка в манифесте приложения или манифесте служб пакета diff, которую невозможно найти в пакете приложения, автоматически заменяется текущей подготовленной версией.

Использование пакета diff оптимально в следующих случаях:

  • Когда используется объемный пакет приложения, который ссылается на несколько файлов манифеста службы или на несколько пакетов кода, пакетов конфигурации или пакетов данных.
  • Когда система развертывания формирует структуру сборки напрямую в ходе создания сборки приложения. В этом случае, хотя в самом коде ничего не изменилось, новые сборки будут обладать другой контрольной суммой. Использование полного пакета приложения потребует обновления версии всех пакетов кода. При использовании пакета diff вы предоставляете только измененные файлы и файлы манифеста, версия которых изменилась.

При обновлении приложения с помощью Visual Studio пакет diff публикуется автоматически. Чтобы создать пакет diff вручную, необходимо обновить манифест приложения и манифесты служб, но только измененные пакеты должны быть включены в финальный пакет приложения.

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

app1           1.0.0
  service1     1.0.0
    code       1.0.0
    config     1.0.0
  service2     1.0.0
    code       1.0.0
    config     1.0.0

Предположим, что необходимо обновить только код пакета service1, использующего пакет diff. Обновленное приложение включает следующие изменения версии:

app1           2.0.0      <-- new version
  service1     2.0.0      <-- new version
    code       2.0.0      <-- new version
    config     1.0.0
  service2     1.0.0
    code       1.0.0
    config     1.0.0

В этом случае вы обновляете манифест приложения до версии 2.0.0 и манифест службы для service1 для отражения обновления пакета кода. Структура папок для пакета приложения будет выглядеть следующим образом.

app1/
  service1/
    code/

Другими словами, создайте полный пакет приложения, а затем удалите все папки пакета кода, конфигурации или данных, для которых версия не изменилась.

Обновление параметров приложения независимо от версии

Иногда желательно изменить параметры приложения Service Fabric, не изменяя версию манифеста. Это можно сделать с помощью флага -ApplicationParameter с командлетом Start-ServiceFabricApplicationUpgrade Azure Service Fabric PowerShell. Предположим, что приложение Service Fabric имеет следующие свойства:

PS C:\> Get-ServiceFabricApplication -ApplicationName fabric:/Application1

ApplicationName        : fabric:/Application1
ApplicationTypeName    : Application1Type
ApplicationTypeVersion : 1.0.0
ApplicationStatus      : Ready
HealthState            : Ok
ApplicationParameters  : { "ImportantParameter" = "1"; "NewParameter" = "testBefore" }

Теперь обновите приложение, выполнив командлет Start-ServiceFabricApplicationUpgrade. В этом примере показано отслеживаемое обновление, но можно также использовать и неотслеживаемое обновление. Полное описание флагов, принятых этим командлетом, см. в справочнике по модулю PowerShell для Service Fabric Azure

PS C:\> $appParams = @{ "ImportantParameter" = "2"; "NewParameter" = "testAfter"}

PS C:\> Start-ServiceFabricApplicationUpgrade -ApplicationName fabric:/Application1 -ApplicationTypeVers
ion 1.0.0 -ApplicationParameter $appParams -Monitored

После обновления убедитесь, что приложение имеет обновленные параметры и ту же версию:

PS C:\> Get-ServiceFabricApplication -ApplicationName fabric:/Application1

ApplicationName        : fabric:/Application1
ApplicationTypeName    : Application1Type
ApplicationTypeVersion : 1.0.0
ApplicationStatus      : Ready
HealthState            : Ok
ApplicationParameters  : { "ImportantParameter" = "2"; "NewParameter" = "testAfter" }

Откат обновлений приложения

Хотя обновления можно выполнить в одном из трех режимов (Monitored, UnmonitoredAuto или UnmonitoredManual), откатить их можно только в режиме UnmonitoredAuto или UnmonitoredManual. Откат в режиме UnmonitoredAuto работает так же, как накат. Единственное исключение: другое значение по умолчанию UpgradeReplicaSetCheckTimeout (см. статью Параметры обновления приложений). Откат в режиме UnmonitoredManual работает так же, как и накат. Он приостанавливается после завершения работы с каждым доменом обновления. Возобновить его можно с помощью командлета Resume-ServiceFabricApplicationUpgrade .

Откат может запускаться автоматически, если нарушены политики работоспособности обновления в режиме Monitored с указанным для отката атрибутом FailureAction , (см. статью Параметры обновления приложения) или если используется командлет Start-ServiceFabricApplicationRollback.

Во время отката все еще можно изменить значение UpgradeReplicaSetCheckTimeout. Режим также можно изменить в любое время с помощью командлета Update-ServiceFabricApplicationUpgrade.

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

Руководство по обновлению приложений Service Fabric с помощью Visual Studio поможет вам выполнить поэтапное обновление приложения с помощью Visual Studio.

Руководство по обновлению приложения с помощью PowerShell поможет вам выполнить обновление приложения с помощью PowerShell.

Управление обновлениями приложения осуществляется с помощью параметров обновления.

Узнайте, как использовать сериализацию данных, чтобы обеспечить совместимость обновлений приложения.

Сведения об устранении распространенных проблем при обновлении приложений см. в статье Устранение неполадок при обновлениях приложений.