Обновление облачной службы Azure (классической)

Процесс обновления облачной службы, включая ее роли и гостевую ОС, выполняет три шага. Сначала нужно передать двоичные файлы и файлы конфигурации новой облачной службы или новой версии ОС. Затем Azure резервирует вычислительные и сетевые ресурсы для облачной службы в соответствии с требованиями новой версии облачной службы. И, наконец, Azure выполняет процесс последовательного обновления клиента до новой версии службы или гостевой ОС, сохраняя при этом доступность. В этой статье подробно описан последний шаг этого процесса — последовательное обновление.

Обновление службы Azure

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

Количество доменов обновления по умолчанию равно 5. Вы можете указать любое другое количество доменов обновления, включив в файл определения службы (CSDEF) атрибут upgradeDomainCount. Дополнительные сведения об атрибуте upgradeDomainCount см. в статье Схема определения Облачных служб Azure (классических) (файл CSDEF).

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

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

В этой статье рассматриваются следующие сведения об обновлениях Azure:

• Допустимые изменения службы во время обновления
• Как происходит обновление
• Откат обновления
• Запуск нескольких операций изменения в текущем развертывании
• Распределение ролей в доменах обновления

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

Все допустимые изменения службы во время обновления приведены в следующей таблице.

¹ Размер можно изменять в пределах подмножества размеров, доступных для облачной службы.

² Требуется пакет SDK Azure 1.5 или более поздней версии.

Следующие элементы не поддерживаются во время обновления:

• Изменение имени роли. Роль следует удалить, а затем добавить с новым именем.
• Изменение количества доменов обновления.
• Уменьшение размера локальных ресурсов.

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

Как происходит обновление

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

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

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

В ходе автоматического обновления контроллер структуры Azure периодически проверяет работоспособность облачной службы, чтобы определить безопасный момент для перехода к следующему домену обновления. Эта оценка работоспособности выполняется на основе каждой роли и рассматривает только экземпляры в последней версии (т. е. экземпляры из уже обработанных UD). Он проверяет, что для каждой роли минимальное количество экземпляров ролей достигло удовлетворительного состояния терминала.

Время ожидания запуска экземпляра роли

Контроллер Fabric ожидает 30 минут, пока каждый экземпляр роли достигнет состояния "Запущен". По истечении времени ожидания контроллер структуры переходит к следующему экземпляру роли.

Влияние установки новой версии облачной службы на данные, хранящиеся на дисках

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

В приведенном выше списке диск E: представляет корневой диск роли и не должен быть жестко закодирован. Для обращения к этому диску используйте переменную среды %RoleRoot%.

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

Откат обновления

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

Откат выполняющегося обновления влияет на развертывание следующим образом.

• Все экземпляры ролей, которые остаются неуправляемыми или не обновлены до новой версии, не обновляются или обновляются, так как эти экземпляры уже выполняют целевую версию службы.
• Все экземпляры ролей, которые уже обновили или обновили до новой версии файла пакета службы (*.cspkg) или файла конфигурации службы (*.cscfg) возвращаются к предварительной версии этих файлов.

Следующие функции предоставляют эту функцию:

• Операция отката обновления или обновления, которая может вызываться в обновлении конфигурации (активируется путем вызова конфигурации развертывания изменений) или обновления (активируется путем вызова развертывания обновления), если в службе остается по крайней мере один экземпляр, который остается неподвержденным к новой версии.

• Элементы Locked и RollbackAllowed, которые возвращаются в теле ответа операциями Получить развертывание и Получить свойства облачной службы.

  1. Элемент Locked (Заблокировано) позволяет определить, можно ли выполнять операции изменения в этом развертывании.
  2. Элемент RollbackAllowed (Откат разрешен) позволяет определить, можно ли выполнять операцию Откатить обновление в этом развертывании.

  Чтобы выполнить откат, вам не нужно проверять как заблокированные, так и элементы RollbackAllowed. Достаточно удостовериться, что RollbackAllowed имеет значение True. Эти элементы возвращаются только в том случае, если в запросе при вызове метода указан заголовок x-ms-version: 2011-10-01 или с более поздней версией. Дополнительные сведения о заголовках управления версиями см . в разделе "Управление версиями" классической модели развертывания.

Существуют некоторые ситуации, когда откат обновления или обновления не поддерживается, следующие ситуации:

• Сокращение локальных ресурсов. Если обновление увеличивает локальные ресурсы для роли платформы Azure, не разрешает откат.
• Ограничения квоты — если обновление предусматривает уменьшение масштаба, вы можете выйти за рамки квоты на вычислительные ресурсы для завершения отката. Каждая подписка Azure имеет квоту, связанную с ней. Квота указывает максимальное количество ядер, которые могут использовать все размещенные службы, принадлежащие этой подписке. Если выполнение отката заданного обновления поместит подписку на квоту, то этот откат не будет включен.
• Состояние гонки — если начальное обновление завершается, откат невозможен.

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

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

Запуск нескольких операций изменения в текущем развертывании

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

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

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

Существуют следующие операции изменения: Изменить конфигурацию развертывания, Обновить развертывание, Обновить состояние развертывания, Удалить развертывание и Откатить обновление.

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

Чтобы вызвать версию этих методов, возвращающих заблокированный флаг, необходимо задать для заголовка запроса значение x-ms-version: 2011-10-01 или более поздней версии. Дополнительные сведения о заголовках управления версиями см . в разделе "Управление версиями" классической модели развертывания.

Распределение ролей в доменах обновления

Azure равномерно распределяет экземпляры роли по заданному количеству доменов обновления, которое можно указать в файле определения службы (CSDEF). По умолчанию используется 5 доменов обновления, а максимально возможное количество равно 20. Подробнее об изменении файла определения службы см. в разделе о схеме определения службы Azure (CSDEF-файл).

Например, если у вашей роли есть 10 экземпляров, по умолчанию каждый домен обновления содержит два экземпляра. Если роль содержит 14 экземпляров, в четырех доменах обновления будет по три экземпляра, а в пятом — два экземпляра.

Нумерация доменов обновления начинается с нуля: первый домен обновления имеет идентификатор 0, второй — идентификатор 1 и т. д.

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

Следующие шаги

Управление облачными службами
Мониторинг облачных служб
Настройка облачных служб