Модернизация и обновление кластеров Azure Service Fabric
Кластер Service Fabric Azure представляет собой ресурс, который принадлежит вам, но частично управляется корпорацией Майкрософт. В этой статье описаны варианты и способы обновления кластера Azure Service Fabric.
Автоматическое и ручное обновление
Крайне важно убедиться, что кластер Service Fabric всегда работает под управлением поддерживаемой версии среды выполнения. Когда корпорация Майкрософт объявляет о выпуске новой версии Service Fabric, для предыдущей версии определяется срок завершения жизненного цикла. Этот срок составляет по меньшей мере 60 дней. О доступности новых выпусков сообщается в блоге группы разработчиков Service Fabric.
За 14 дней до истечения жизненного цикла выпуска, под управлением которого работает ваш кластер, будет создано событие работоспособности, которое переводит кластер в состояние предупреждения. Состояние предупреждения изменится, когда кластер будет обновлен до поддерживаемой версии среды выполнения.
Вы можете настроить в кластере получение автоматических обновлений Service Fabric по мере их выпуска корпорацией Майкрософт или же выбрать вручную поддерживаемые версии в списке. Эти параметры доступны в разделе Обновления Fabric ресурса кластера Service Fabric.
Можно также задать режим обновления кластера и выбрать версию среды выполнения с помощью шаблона Resource Manager.
Для режима обновления рекомендуется использовать автоматическое обновление, так как этот параметр гарантирует, что кластер остается в поддерживаемом состоянии и обеспечивает преимущества последних исправлений и функций, а также позволяет запланировать обновления так, чтобы они находились в соответствии с нагрузкой с использованием стратегии развертывания волнами.
Примечание
Если вы измените существующий кластер на автоматический, кластер будет зарегистрирован в течение следующего периода обновления, начиная с нового выпуска. О доступности новых выпусков сообщается в блоге группы разработчиков Service Fabric. За период обновления выбран самый высокий из возможных путей обновления, см. поддерживаемые версии. Режим ручного обновления запускает немедленное обновление.
Развертывание автоматического обновления волнами
С помощью развертывания волнами можно минимизировать перебои в обновлении до кластера, выбрав уровень зрелости обновления в зависимости от рабочей нагрузки. Например, можно настроить конвейер развертывания волнами Тестирование ->Промежуточная среда ->Производственная среда для различных кластеров Service Fabric, чтобы проверить совместимость обновления среды выполнения перед применением его к рабочим нагрузкам.
Чтобы принять участие в развертывании волнами, укажите одно из следующих значений для кластера (в его шаблоне развертывания):
- Волна 0. Кластеры обновляются сразу после выпуска новой сборки Service Fabric. Предназначена для тестирования и разработки кластеров.
- Волна 1. Кластеры обновляются через одну неделю (семь дней) после выпуска новой сборки. Предназначена для предварительных и промежуточных кластеров.
- Волна 2. Кластеры обновляются через две недели (14 дней) после выпуска новой сборки. Предназначена для рабочих кластеров.
Вы можете зарегистрироваться для получения уведомлений по электронной почте со ссылками для дальнейшей помощи в случае сбоя обновления кластера. Чтобы приступить к работе, см. раздел Развертывание автоматического обновления волнами.
Этапы автоматического обновления
Корпорация Майкрософт поддерживает код и конфигурацию среды выполнения Service Fabric, которая выполняется в кластере Azure. По мере необходимости мы выполняем автоматические контролируемые обновления программного обеспечения. Эти обновления могут затрагивать код, конфигурацию или и то, и другое. Чтобы снизить влияние этих обновлений на приложения, они выполняются на следующих этапах.
Этап 1. Выполнение обновления с помощью всех политик работоспособности кластера
В ходе этого этапа обновления применяются к одному домену обновления за раз, а приложения, которые были запущены в кластере, продолжают работать без простоев. Политики работоспособности кластера (для работоспособности узла и работоспособности приложения) выполняются во время обновления.
Если политики работоспособности кластера не выполняются, выполняется откат обновления и владелец подписки отправляет сообщение электронной почты. Оно содержит следующую информацию:
- Уведомление о том, что нам пришлось выполнить откат обновления кластера.
- Рекомендуемые действия по решению проблемы, при их наличии.
- Количество дней (n) до выполнения этапа 2.
Мы постараемся выполнить аналогичное обновление еще несколько раз в случае, если причины неудачи связаны с инфраструктурой. Через n дней с момента отправки сообщения мы переходим к этапу 2.
Если политики работоспособности кластера соблюдены, обновление считается успешным и помечается как завершенное. Это может произойти во время первоначального или повторного запусков обновлений на этом этапе. По электронной почте нет подтверждения успешного выполнения, чтобы избежать отправки избыточных сообщений электронной почты. Получение сообщения электронной почты указывает на отклонение от обычной работы. Мы надеемся, что большинство обновлений кластера будет выполнено без ущерба для доступности вашего приложения.
Этап 2. Выполнение обновления с помощью только политик работоспособности по умолчанию
Политики работоспособности на этом этапе задаются таким образом, что ряд приложений, которые были работоспособны в начале обновления, остаются неизменными в течение всего процесса обновления. Как и в ходе этапа 1, на этапе 2 обновления применяются к одному домену обновления за раз, а приложения, которые были запущены в кластере, продолжают работать без простоев. В ходе обновления соблюдаются все политики работоспособности кластера (политики, определяющие состояние работоспособности для узлов и всех приложений, выполняющихся в кластере).
Если применяемые политики работоспособности кластера фактически не соблюдаются, выполняется откат обновления. Затем владельцу подписки отправляется сообщение электронной почты. Оно содержит следующую информацию:
- Уведомление о том, что нам пришлось выполнить откат обновления кластера.
- Рекомендуемые действия по решению проблемы, при их наличии.
- Количество дней (n) до выполнения этапа 3.
Мы постараемся выполнить аналогичное обновление еще несколько раз в случае, если причины неудачи связаны с инфраструктурой. За несколько дней до назначенного срока владельцу подписки отправляется сообщение с напоминанием. Через n дней с момента отправки сообщения мы переходим к этапу 3. К сообщениям, которые отправляются на этапе 2, следует отнестись серьезно и выполнить действия по устранению ошибок.
Если политики работоспособности кластера соблюдены, обновление считается успешным и помечается как завершенное. Это может произойти во время первоначального или повторного запусков обновлений на этом этапе. В случае успешного выполнения сообщение с подтверждением не отправляется.
Этап 3. Выполнение обновления с помощью жестких политик работоспособности кластера
Эти политики работоспособности на данном этапе предназначены для выполнения обновления, а не обеспечения работоспособности приложений. Этот этап редко применяется для обновления кластера. Если ваш кластер достигает этого этапа, есть высокая вероятность того, что ваше приложение перейдет в неработоспособное состояние и (или) будет недоступно.
Как и на других двух этапах, обновления на этапе 3 применяются к одному домену обновления за раз.
Если требования политик работоспособности кластера не реализуются, выполняется откат обновления. Мы постараемся выполнить аналогичное обновление еще несколько раз в случае, если причины неудачи связаны с инфраструктурой. После этого кластер закрепляется и больше не будет получать поддержку и обновления.
Сообщение с этими сведениями и корректирующими действиями отправляется владельцу подписки. Мы не ожидаем перехода кластеров в состояние, в котором произошел сбой этапа 3.
Если политики работоспособности кластера соблюдены, обновление считается успешным и помечается как завершенное. Это может произойти во время первоначального или повторного запусков обновлений на этом этапе. В случае успешного выполнения сообщение с подтверждением не отправляется.
Пользовательские политики для обновления вручную
Можно указать настраиваемые политики для обновлений вручную в кластере. Эти политики применяются каждый раз при выборе новой версии среды выполнения, которая активирует систему для запуска обновления кластера. Если политики не переопределить, будут использоваться значения по умолчанию. Дополнительные сведения см. в разделе Настройка пользовательских политик для обновления вручную.
Другие обновления кластера
За пределами обновления среды выполнения необходимо выполнить ряд других действий, которые могут потребоваться для обновления кластера, включая следующие.
Управление сертификатами
Service Fabric использует сертификаты сервера X.509, указываемые при создании кластера, для защиты обмена данными между узлами кластера и проверки подлинности клиентов. Вы можете добавлять, обновлять или удалять сертификаты для кластера и клиента с помощью портала Azure, PowerShell или Azure CLI. Подробнее о добавлении или удалении сертификатов.
Открытие портов приложений
Порты приложения можно изменить путем изменения свойств ресурса балансировщика нагрузки, связанных с типом узла. Для этого можно использовать портал Azure, PowerShell или Azure CLI. Дополнительные сведения см. в статье Открытие портов для кластера Service Fabric.
Определение свойств узла
Иногда необходимо обеспечить выполнение конкретных рабочих нагрузок только на узлах определенных типов в кластере. Например, для одних рабочих нагрузок могут требоваться графические процессоры или накопители SSD, а для других — нет. Для каждого из типов узлов в кластере можно добавить пользовательские свойства. Ограничения размещения представляют собой операторы, привязанные к отдельным службам и включающие одно или несколько свойств узла. Ограничения размещения определяют, где должны запускаться службы.
Сведения об использовании ограничений на размещение, свойств узла и способах их определения см. здесь.
Добавление метрик емкости
Для каждого типа узла можно добавить настраиваемые метрики емкости, которые будут использоваться в приложениях для передачи данных о нагрузке. Дополнительные сведения об использовании метрик емкости для отчетах о нагрузке см. в документах по диспетчеру кластерных ресурсов Service Fabric на страницах Описание кластера Service Fabric и Управление потреблением ресурсов и нагрузкой в Service Fabric с помощью метрик.
Настройка параметров вашего кластера
В кластере можно настроить множество разных параметров конфигурации, например, уровень надежности кластера и свойства узла. Дополнительные сведения см. в статье Настройка параметров кластера Service Fabric.
Обновление образов ОС для узлов кластера
Рекомендуется включить автоматическое обновление образов ОС для узлов кластера Service Fabric. Для этого необходимо выполнить несколько требований к кластеру и предпринять ряд действий. Другой вариант — использовать приложение для управления исправлениями (POA): это приложение Service Fabric, которое позволяет автоматизировать установку исправлений операционной системы в кластере Service Fabric без прерывания работы. Дополнительные сведения об этих параметрах см. в статье Исправление операционной системы Windows в кластере Service Fabric.