Обновление приложения Service Fabric

  • Статья

Приложение Azure Service Fabric представляет собой коллекцию служб. Во время обновления структура служб сравнивает новый манифест приложения с предыдущей версией и определяет, каким службам в приложении требуется обновление. Service Fabric сравнивает версию в манифестах службы с версией в предыдущей версии. Если версия службы не изменилась, эта служба не будет обновлена.

Примечание

Параметры ApplicationParameters не сохраняются после обновления приложения. Чтобы сохранить текущие параметры приложения, пользователь должен сначала получить параметры и передать их в вызов API обновления, как показано ниже:

$myApplication = Get-ServiceFabricApplication -ApplicationName fabric:/myApplication
$appParamCollection = $myApplication.ApplicationParameters

$applicationParameterMap = @{}
foreach ($pair in $appParamCollection)
{
    $applicationParameterMap.Add($pair.Name, $pair.Value);
}

Start-ServiceFabricApplicationUpgrade -ApplicationName fabric:/myApplication -ApplicationTypeVersion 2.0.0 -ApplicationParameter $applicationParameterMap -Monitored -FailureAction Rollback

Обзор последовательных обновлений

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

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

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

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

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

Проверки работоспособности во время обновления

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

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

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

Режимы обновления

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

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

Обновление служб по умолчанию

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

  1. Если службы по умолчанию, определенные в новом манифесте приложения, еще не существуют в кластере, то они создаются.
  2. Службы по умолчанию, существующие в предыдущей и новой версиях манифеста приложения, обновляются. Параметры службы по умолчанию в новом манифесте приложения перезаписывают параметры существующей службы. При сбое обновления служб по умолчанию автоматически выполняется откат обновления приложения.
  3. Службы по умолчанию, которые не существуют в манифесте нового приложения, удаляются из кластера, если они там существуют. Обратите внимание, что удаление службы по умолчанию невозможно отменить.

В случае отката обновления приложения восстанавливаются значения параметров службы по умолчанию на момент до начала обновления. Но создать удаленные службы будет невозможно.

Совет

Чтобы выполнялись вышеупомянутые правила 2 и 3 (обновление и удаление службы по умолчанию), параметр конфигурации кластера EnableDefaultServicesUpgrade должен иметь значение true. Эта функция поддерживается, начиная с Service Fabric версии 5.5.

Обновление нескольких приложений с помощью конечных точек HTTPS

Не используйте один и тот же порт для разных экземпляров одного и того же приложения при использовании HTTPS. Это связано с тем, что Service Fabric не сможет обновить сертификат одного из экземпляров приложения. Например, если для приложений 1 и 2 необходимо обновить сертификат 1 до сертификата 2. При обновлении Service Fabric может очистить данные регистрации сертификата 1 с помощью процесса http.sys, даже если он используется другим приложением. Чтобы избежать этого, Service Fabric определяет, что другой экземпляр приложения уже зарегистрирован на порте с сертификатом (из-за http.sys) и завершает операцию.

Поэтому Service Fabric не поддерживает обновление двух разных служб, использующих один порт в разных экземплярах приложения. Другими словами нельзя использовать один сертификат для разных служб в одном порте. Если необходимо иметь сертификат с общим доступом в одном порте, убедитесь, что службы размещены на разных компьютерах с ограничениями на размещение. Или по возможности используйте динамические порты Service Fabric для каждой службы в экземпляре приложения.

Если при обновлении произойдет ошибка HTTP, появится предупреждение о том, что API сервера HTTP Windows не поддерживает несколько сертификатов для приложений, которые совместно используют порт.

Блок-схема обновления приложения

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

Процесс обновления приложения структуры служб

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

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

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

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

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

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

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