Обслуживание виртуальных машин Linux в Azure
Применимо к: ✔️ Виртуальные машины Linux ✔️ Виртуальные машины Windows ✔️ Универсальные масштабируемые наборы
Azure периодически выполняет обновления своей платформы, чтобы повысить надежность, производительность и безопасность инфраструктуры узлов, в которой работают виртуальные машины. Причины этих обновлений разные: от исправлений программных компонентов в среде размещения до обновления сетевых компонентов или вывода оборудования из эксплуатации.
Обновления редко влияют на размещенные виртуальные машины. Когда они все же оказывают определенное воздействие, Azure выбирает для обновлений метод, сводящий его к минимуму.
- Если возможно обновление без перезагрузки, виртуальная машина приостанавливается во время обновления узла или динамически переносится на узел, который уже обновлен.
- Если обслуживание требует перезагрузки, вы получаете уведомление о плановом обслуживании. Azure также предоставляет период, в который можно начать обслуживание самостоятельно, когда это будет удобно. Период самостоятельного обслуживания обычно составляет 35 дней (для хост-компьютеров), если обслуживание не является срочным. Azure вкладывается в технологии, позволяющие сократить число случаев, когда для планового обслуживания платформы требуется перезагрузка виртуальных машин. Инструкции по управлению плановым обслуживанием см. в статье "Обработка уведомлений о плановом обслуживании с помощью Azure CLI, PowerShell или портала".
На этой странице описано, как Azure выполняет обслуживание обоих типов. Дополнительные сведения о внеплановых событиях (простоях) см. в статье Управление доступностью виртуальных машин Windows или соответствующей статье для Linux.
Вы можете получать внутренние уведомления виртуальной машины о предстоящем обслуживании с помощью запланированных событий для Windows или Linux.
Обслуживание, не требующее перезагрузки
Большинство обновлений платформы не влияет на виртуальные машины клиента. Если обновление без такого влияния невозможно, Azure выбирает механизм обновления, который в наименьшей мере затрагивает виртуальные машины клиентов.
Если требуется обслуживание виртуальной машины, она почти всегда будет завершена с помощью приостановки виртуальной машины менее 10 секунд. В редких случаях не более одного раза каждые 18 месяцев для размеров виртуальных машин общего назначения Azure использует механизм, который приостанавливает виртуальную машину около 30 секунд. После любой операции приостановки часы виртуальной машины автоматически синхронизируются при возобновлении.
Обслуживание с сохранением памяти доступно более чем для 90 % виртуальных машин Azure. Оно не работает для серий G, M, N и H. В Azure все чаще используются технологии динамической миграции и вносятся улучшения в механизмы обслуживания с сохранением памяти, необходимые для уменьшения длительности приостановок.
Эти операции обслуживания, для которых не требуется перезагрузка, выполняются поочередно для каждого домена сбоя. Они останавливаются, если получают предупреждающие сигналы от средств мониторинга платформы. Операции обслуживания, которые не требуют перезагрузки, могут выполняться одновременно в парных регионах или Зонах доступности. Для конкретного изменения развертывание в основном выполняется последовательно в Зонах доступности и парах регионов, но может перекрываться в концевой части.
Эти типы обновлений могут повлиять на некоторые приложения. Когда виртуальная машина динамически перемещается на другой узел, для некоторых чувствительных рабочих нагрузок может наблюдаться небольшое снижение производительности в течение нескольких минут перед приостановкой работы виртуальной машины. При подготовке к обслуживанию виртуальной машины и снижения воздействия обслуживания Azure на такие приложения будет полезно использовать запланированные события для Windows или Linux.
Для более детального контроля за всеми действиями по обслуживанию, включая обновления с нулевым влиянием и без перезагрузки, можно создать функцию конфигурации обслуживания. Создание конфигурации обслуживания дает возможность пропустить все обновления платформы и применить обновления на выбранный момент времени. Дополнительные сведения см. в разделе Управление обновлениями платформы в конфигурациях обслуживания.
Динамическая миграция
Динамическая миграция — это операция, которая не требует перезагрузки и сохраняет содержимое памяти виртуальной машины. Она вызывает паузу или замораживание, обычно не превышающие 5 секунд. Кроме серии G, L, N и H, все виртуальные машины инфраструктуры как услуги (IaaS) имеют право на динамическую миграцию. Динамическая миграция доступна на большинстве номеров SKU серии M. Подходящие виртуальные машины составляют более 90 процентов виртуальных машин IaaS, развернутых в парке Azure.
Примечание.
Вы не получите уведомление в портал Azure для операций динамической миграции, которые не требуют перезагрузки. Чтобы просмотреть список динамических миграций, которые не нуждаются в перезагрузке, следует создать запрос для запланированных событий.
Платформа Azure запускает динамическую миграцию в следующих сценариях.
- Плановое техническое обслуживание
- Аппаратный сбой
- Оптимизация распределения
В некоторых сценариях планового обслуживания используется динамическая миграция. Они позволяют использовать Запланированные события, чтобы заранее получить сведения о начале операций динамической миграции.
Динамическая миграция также может использоваться для перемещения виртуальных машин, когда алгоритмы Машинного обучения Azure прогнозируют незапланированный сбой оборудования или если требуется оптимизировать выделение ресурсов виртуальной машины. Дополнительные сведения о прогнозном моделировании, которое обнаруживает случаи понижения функциональности оборудования, см. в статье Улучшение устойчивости виртуальной машины Azure с помощью прогнозного машинного обучения и динамической миграции. Уведомления динамической миграции отображаются на портале Microsoft Azure в журналах мониторинга и работоспособности служб, а также в Запланированных событиях при использовании этих служб.
Обслуживание, требующее перезагрузки
В редких случаях, когда виртуальные машины необходимо перезагрузить при плановом обслуживании, об этом уведомляется заранее. Плановое обслуживание выполняется в два этапа: этап самостоятельного обслуживания и этап запланированного обслуживания.
На этапе самостоятельного обслуживания, который обычно длится четыре недели, вы сами запускаете обслуживание своих виртуальных машин. В рамках самостоятельного обслуживания вы можете отправить запрос на каждую виртуальную машину, чтобы оценить ее состояние и проверить результат последнего запроса на обслуживание.
Примечание.
Данные локальных (временных) дисков на виртуальных машинах серий, которые не поддерживают динамическую миграцию, могут быть потеряны во время обслуживания. Сведения о поддержке динамической миграции см. в разделах для каждой отдельной серии виртуальных машин.
При запуске самостоятельного обслуживания виртуальная машина повторно развертывается на уже обновленном узле. Так как виртуальная машина повторно развертывается, временный диск теряется и обновляются общедоступные динамические IP-адреса, связанные с виртуальным сетевым интерфейсом.
Если во время самостоятельного обслуживания происходит ошибка, операция приостанавливается, виртуальная машина не обновляется, а вы получаете возможность повторить попытку самостоятельного обслуживания.
После завершения этапа самостоятельного обслуживания начинается этап запланированного обслуживания. В течение этого этапа вы все еще можете запрашивать период обслуживания, но вы не сможете инициировать обслуживание самостоятельно.
Дополнительные сведения по управлению обслуживанием, требующим перезагрузки, см. в статье "Обработка уведомлений о плановом обслуживании с помощью Azure CLI, PowerShell или портала".
Рекомендации по обеспечению доступности во время запланированного обслуживания
Если вы решили дождаться запланированного периода обслуживания, нужно учесть несколько факторов, чтобы обеспечить наивысшую доступность своих виртуальных машин.
Пары регионов
Каждый регион Azure образует пару с другим регионом в пределах одной географической территории. Вместе они образуют пару регионов. Во время этапа запланированного обслуживания Azure обновляет виртуальные машины только в одном регионе из пары. Например, во время обновления виртуальных машин в центрально-северной части США Azure не будет одновременно обновлять виртуальные машины в центрально-южной части США. Однако в других регионах, например в Северной Европе, обслуживание может происходить одновременно с обслуживанием в восточной части США. Чтобы лучше распределить виртуальные машины по регионам, ознакомьтесь с принципами работы пар регионов. Дополнительные сведения см. в статье Непрерывность бизнес-процессов и аварийное восстановление в службах BizTalk: пары регионов Azure.
Зоны доступности
Зоны доступности — уникальные физические расположения в пределах одного региона Azure. Каждая зона состоит из одного или нескольких центров обработки данных, оснащенных независимыми системами электроснабжения, охлаждения и сетевого взаимодействия. Чтобы обеспечить отказоустойчивость, во всех включенных регионах используются минимум три отдельные зоны.
Зона доступности — это сочетание домена сбоя и домена обновления. Если вы создаете три или более виртуальных машин в трех зонах региона Azure, виртуальные машины эффективно распределяются между тремя доменами сбоя и тремя доменами обновления. Платформа Azure поддерживает такое распределение между доменами обновления, чтобы виртуальные машины в различных зонах не обновлялись одновременно.
Каждое обновление инфраструктуры разворачивается от зоны к зоне в пределах одного региона. Одно развертывание можно выполнять в зоне 1, а другое развертывание в то же время — в зоне 2. Развертывания не всегда являются сериализованными. Однако в одиночном развертывании, которое требует перезагрузки, зоны разворачиваются последовательно, чтобы снизить риск. Как правило, обновления, требующие перезагрузки, не разворачиваются, если это возможно, и Azure пытается использовать динамическую миграцию или обеспечить управление клиентами.
Масштабируемые наборы виртуальных машин
Масштабируемые наборы виртуальных машин в режиме оркестрации Гибкий — это вычислительный ресурс Azure, позволяющий сочетать масштабируемость наборов масштабирования виртуальных машин в режиме согласованности с региональными гарантиями доступности групп доступности.
С помощью гибкой оркестрации вы можете выбрать, будут ли ваши экземпляры распределены по нескольким зонам или по доменам сбоя в одном регионе.
Группы доступности и однородные масштабируемые наборы
При развертывании рабочей нагрузки на виртуальных машинах Azure вы можете создать виртуальные машины в группе доступности, чтобы обеспечить высокую доступность приложения. С помощью групп доступности можно гарантировать, что во время сбоя или события обслуживания, требующего перезагрузки, останется доступна по крайней мере одна виртуальная машина.
Отдельные виртуальные машины в группе доступности могут быть распределены между максимум 20 доменами обновления. Во время запланированного обслуживания в конкретный момент времени всегда изменяется только один домен обновления. Домены обновления не обязательно обновляются последовательно.
Масштабируемые наборы виртуальных машин в режиме универсальной оркестрации — это вычислительный ресурс Azure, который можно использовать для развертывания набора идентичных виртуальных машин и управления ими как единым ресурсом. Масштабируемый набор автоматически развертывается в доменах обновления, как и виртуальные машины в группе доступности. Как и в случае с группами доступности, в каждый конкретный момент времени запланированного обслуживания масштабируемый набор изменяется только в одном домене обновления.
Дополнительные сведения о настройке виртуальных машин для обеспечения высокого уровня доступности см. в статье Управление доступностью виртуальных машин Windows или соответствующей статье для Linux.
Следующие шаги
Для управления плановым обслуживанием можно использовать Azure CLI, Azure PowerShell или портал.