Описание перезапуска системы для виртуальной машины Azure

Область применения: ✔️ Виртуальные машины Linux ✔️ Виртуальные машины Windows

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

Настройка виртуальных машин для обеспечения высокой доступности

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

Чтобы обеспечить такой уровень избыточности приложения, мы рекомендуем включить две или несколько виртуальных машин в группу доступности. Эта конфигурация обеспечит доступность не менее одной виртуальной машины и достижение показателя 99,95 % в соответствии с соглашением об уровне обслуживания Azure при событиях запланированного и незапланированного обслуживания.

Дополнительные сведения о группах доступности см. в статье "Управление доступностью виртуальных машин"

Сведения о работоспособности ресурсов

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

Если в Azure есть дополнительные сведения о основной причине недоступности, инициированной платформой для виртуальной машины, эта информация может быть размещена в работоспособности ресурсов до 72 часов после первоначальной недоступности.

Отсутствие времени простоя виртуальной машины в журнале действий

Работоспособность ресурсов оповещения отправляются на основе сведений журнала действий. В некоторых случаях время простоя виртуальной машины может не отображаться в журнале действий. Если время простоя не отображается в журнале действий, Работоспособность ресурсов оповещения не будут отправляться для простоя. Время простоя по-прежнему отображается в Работоспособность ресурсов.

Ниже приведены случаи, когда время простоя виртуальной машины не отображается в журнале действий:

• При создании или переносе виртуальной машины на новый узел платформа Azure не отображает состояние виртуальной машины правильно, а состояние изменено на "Неизвестно". Только после установки всех процессов сетевого подключения и узлов состояние виртуальной машины изменяется на Доступно. Длительный период неизвестного состояния отфильтровывается из журнала действий.
• Когда состояние доступности виртуальной машины изменяется с "Доступно на недоступно", а затем возвращается в "Доступно" в течение 35 секунд, время простоя не отображается в журнале действий. Этот случай не будет возникать, если коррелированная простой отправляется в течение 15 минут до появления первого перехода.
• Если работоспособность виртуальной машины изменяется из состояния "Неизвестно", а затем возвращается к исходному состоянию, периодически отфильтровывается неизвестное состояние и связанные переходы из журнала действий.

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

Действия и события, которые могут привести к перезапуску виртуальной машины

Плановое техническое обслуживание

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

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

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

• Плановое обслуживание виртуальных машин Windows
• Как запланировать плановое обслуживание на виртуальных машинах Azure

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

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

Эти обновления с сохранением памяти выполняются с помощью технологии, позволяющей использовать динамическую миграцию на месте. На время обновления виртуальная машина переводится в состояние Приостановлена. Это состояние сохраняет память в ОЗУ, пока операционная система сервера виртуальных машин получает необходимые обновления и исправления. Виртуальная машина возобновляется в течение 30 секунд после приостановки. После возобновления работы часы виртуальной машины автоматически синхронизируются.

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

Обновления для нескольких экземпляров (для виртуальных машин в группе доступности) применяются для одного домена обновления за раз.

Инициированные пользователем действия перезапуска или завершения работы

Если выполнить перезагрузку из портал Azure, Azure PowerShell, интерфейса командной строки или REST API, можно найти событие в журнале действий Azure.

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

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

Microsoft Defender для облака и Обновл. Windows

Microsoft Defender для облака отслеживает ежедневные виртуальные машины Windows и Linux для отсутствующих обновлений операционной системы. Defender для облака извлекает список доступных обновлений безопасности и критически важных обновлений из Обновл. Windows или служб windows Server Update Services (WSUS), в зависимости от того, какая служба настроена на виртуальной машине Windows. Defender для облака также проверяет наличие последних обновлений для систем Linux. Если виртуальная машина отсутствует обновление системы, Defender для облака рекомендует применять обновления системы. Приложение этих обновлений системы управляется Defender для облака в портал Azure. После применения некоторых обновлений может потребоваться перезапуск виртуальной машины. Дополнительные сведения см. в разделе "Применение обновлений системы" в Microsoft Defender для облака.

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

Другие ситуации, влияющие на доступность виртуальной машины

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

Ошибки сервера узла

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

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

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

Автоматическое восстановление

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

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

Внеплановое техническое обслуживание

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

Незапланированное обслуживание включает в себя следующее:

• срочную дефрагментацию узла;
• срочные обновления сетевого коммутатора.

Сбои виртуальных машин

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

Принудительное завершение работы, связанное с хранилищем

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

Другие инциденты

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

Диагностика перезапусков виртуальных машин

Вы можете использовать колонку "Диагностика и решение" в колонке виртуальной машины для выполнения дополнительных диагностика. Это может выявить более конкретные причины для недавнего перезапуска виртуальной машины. Если возникла проблема с гостевой ОС, соберите дамп памяти и обратитесь в службу поддержки.

Свяжитесь с нами для получения помощи

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