Общие сведения о перезагрузке системы для виртуальной машины Azure
Виртуальные машины Azure иногда могут перезагружать без видимой причины, без подтверждения того, что вы инициировали операцию перезагрузки. В этой статье перечислены действия и события, которые могут привести к перезагрузке виртуальных машин, а также приводятся сведения о том, как избежать непредвиденных проблем с перезагрузкой или уменьшить влияние таких проблем.
Настройка виртуальных машин для обеспечения высокого уровня доступности
Лучший способ защитить приложение, работающее в Azure от перезагрузок виртуальных машин и простоя, — это настроить виртуальные машины для обеспечения высокого уровня доступности.
Чтобы обеспечить такой уровень избыточности для приложения, рекомендуется сгруппировать две или более виртуальных машин в группе доступности. Эта конфигурация гарантирует, что во время запланированного или незапланированного обслуживания по крайней мере одна виртуальная машина будет доступна и соответствует 99,95 процентам azure SLA.
сведения Работоспособность ресурсов
Azure Работоспособность ресурсов — это служба, которая предоставляет сведения о работоспособности отдельных ресурсов Azure и предоставляет практические рекомендации по устранению неполадок. В облачной среде, где невозможно получить прямой доступ к серверам или элементам инфраструктуры, цель Работоспособность ресурсов — сократить время, затрачивается на устранение неполадок. В частности, цель состоит в том, чтобы сократить время, затрачивается на определение того, лежит ли корень проблемы в приложении или в событии на платформе Azure. Дополнительные сведения см. в статье Общие сведения и использование Работоспособность ресурсов.
Если в Azure есть дополнительные сведения о первопричине недоступности виртуальной машины, инициированной платформой, эти сведения могут быть размещены в работоспособности ресурсов в течение 72 часов после первоначальной недоступности.
Отсутствие простоев виртуальной машины в журнале действий
Работоспособность ресурсов оповещения отправляются на основе сведений журнала действий. В некоторых случаях простои виртуальных машин могут не отображаться в журнале действий. Если время простоя не отображается в журнале действий, Работоспособность ресурсов оповещения о простое не будут отправляться. Время простоя по-прежнему отображается в Работоспособность ресурсов.
Ниже приведены случаи, когда простои виртуальных машин не отображаются в журнале действий:
- При создании или миграции виртуальной машины на новый узел платформа Azure неправильно отображает состояние виртуальной машины, а состояние изменяется на Неизвестно. Только после установки всех процессов сетевого подключения и узлов состояние виртуальной машины изменится на Доступно. Длительный период состояния Unknown отфильтровывается из журнала действий.
- Когда состояние доступности виртуальной машины изменится с «Доступно» на «Недоступно», а затем возвращается к «Доступно» в течение 35 секунд, время простоя не отображается в журнале действий. Этот случай не будет возникать, если коррелированные простои отправляются в течение 15 минут до начала первого перехода.
- Если работоспособность виртуальной машины изменяется с состояния На Неизвестно, а затем возвращается в исходное состояние, периодические неизвестные состояния и связанные переходы отфильтровываются из журнала действий.
Время простоя виртуальной машины, которое не отображается в журнале действий, фильтруется на стороне платформы Azure, чтобы предотвратить появление временных ошибок при отображении неверных простоев для клиентов. При текущих инвестициях в качество работоспособности виртуальных машин фильтры больше не требуются и могут привести к тому, что быстрые изменения в работоспособности виртуальных машин останутся незарегистрированными. Корпорация Майкрософт работает над планом поэтапного отказа, чтобы обеспечить оптимальное взаимодействие с клиентами.
Действия и события, которые могут привести к перезагрузке виртуальной машины
Плановое обслуживание
Microsoft Azure периодически выполняет обновления по всему миру, чтобы повысить надежность, производительность и безопасность инфраструктуры узла, лежащей в основе виртуальных машин. Многие из этих обновлений, включая обновления с сохранением памяти, выполняются без какого-либо влияния на виртуальные машины или облачные службы.
Однако для некоторых обновлений требуется перезагрузка. В таких случаях виртуальные машины завершаются, пока мы исправляем инфраструктуру, а затем они перезапускаются.
Чтобы понять, что такое плановое обслуживание Azure и как оно может повлиять на доступность виртуальных машин Linux, см. в статьях, перечисленных здесь. В статьях приводятся общие сведения о процессе планового обслуживания Azure и планировании планового обслуживания для дальнейшего снижения влияния.
- Плановое обслуживание виртуальных машин в Azure
- Планирование планового обслуживания на виртуальных машинах Azure
Обновления с сохранением памяти
Для этого класса обновлений в Microsoft Azure пользователи не оказывают влияния на работающие виртуальные машины. Многие из этих обновлений относятся к компонентам или службам, которые можно обновить без вмешательства в работу работающего экземпляра. Некоторые из них — обновления инфраструктуры платформы в операционной системе узла, которые можно применить без перезагрузки виртуальных машин.
Эти обновления, сохраняющие память, выполняются с помощью технологии, которая обеспечивает динамическую миграцию на месте. При обновлении виртуальная машина помещается в приостановленное состояние. Это состояние сохраняет память в ОЗУ, а базовая операционная система узла получает необходимые обновления и исправления. Виртуальная машина обычно возобновляется в течение 30 секунд после приостановки. После возобновления работы виртуальной машины ее часы автоматически синхронизируются.
Из-за короткого периода приостановки развертывание обновлений с помощью этого механизма значительно снижает влияние на виртуальные машины. Однако не все обновления можно развернуть таким образом.
Обновления с несколькими экземплярами (для виртуальных машин в группе доступности) применяются по одному домену обновления за раз.
На компьютеры Linux со старыми версиями ядра влияет ошибка ядра во время этого метода обновления. Чтобы избежать этой проблемы, обновите ядро до версии 3.10.0-327.10.1 или более поздней. Дополнительные сведения см. в статье Виртуальная машина Linux Azure на базе ядра 3.10 вызывает панику после обновления узла узла.
Инициированные пользователем действия по перезагрузке или завершению работы
Если вы выполняете перезагрузку из портал 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 на физическом сервере перестают отвечать, система мониторинга активирует перезагрузку сервера узла для попытки восстановления. Виртуальная машина, как правило, снова доступна в течение пяти минут и продолжает работать на том же узле, что и ранее.
Сбои сервера обычно вызваны сбоем оборудования, например сбоем жесткого диска или твердотельного диска. Azure постоянно отслеживает эти вхождений, выявляет базовые ошибки и развертывает обновления после реализации и тестирования мер по устранению рисков.
Так как некоторые ошибки сервера узла могут быть характерными для этого сервера, ситуация с повторной перезагрузкой виртуальной машины может быть улучшена путем повторного развертывания виртуальной машины вручную на другом сервере узла. Эту операцию можно запустить с помощью параметра повторного развертывания на странице сведений о виртуальной машине или путем остановки и перезапуска виртуальной машины в портал Azure.
Автоматическое восстановление
Если по какой-либо причине не удается перезагрузить сервер узла, платформа Azure инициирует действие автоматического восстановления, чтобы вывести неисправный сервер узла из ротации для дальнейшего изучения.
Все виртуальные машины на этом узле автоматически перемещаются на другой, работоспособный сервер узла. Хотя этот процесс обычно завершается в течение 15 минут, время, необходимое для восстановления, может отличаться в зависимости от нескольких факторов, включая размер памяти узла и используемые методы восстановления. Дополнительные сведения о процессе автоматического восстановления см. в статье Автоматическое восстановление виртуальных машин.
Незапланированное обслуживание
В редких случаях операционной группе Azure может потребоваться выполнить действия по обслуживанию, чтобы обеспечить общую работоспособность платформы Azure. Это поведение может повлиять на доступность виртуальной машины, и обычно это приводит к тому же автоматическому восстановлению, как описано выше.
Внеплановое обслуживание включает следующее:
- Дефрагментация срочного узла
- Срочные обновления сетевых коммутаторов
Сбои виртуальной машины
Виртуальные машины могут перезапуститься из-за проблем внутри самой виртуальной машины. Рабочая нагрузка или роль, запущенные на виртуальной машине, могут вызвать ошибку проверка в гостевой операционной системе. Чтобы определить причину сбоя, просмотрите системные журналы и журналы приложений для виртуальных машин Windows, а также последовательные журналы для виртуальных машин Linux.
Принудительное завершение работы, связанное с хранилищем
Виртуальные машины в Azure используют виртуальные диски для операционной системы и хранилища данных, размещенные в инфраструктуре службы хранилища Azure. Каждый раз, когда на доступность или подключение между виртуальной машиной и связанными виртуальными дисками влияет более чем на 120 секунд, платформа Azure выполняет принудительное завершение работы виртуальных машин, чтобы избежать повреждения данных. После восстановления подключения к хранилищу виртуальные машины автоматически будут включены. Длительность завершения работы может составлять всего пять минут, но может быть значительно больше.
Другие инциденты
В редких случаях широко распространенная проблема может повлиять на несколько серверов в центре обработки данных Azure. В случае возникновения этой проблемы команда Azure отправляет Уведомления по электронной почте в затронутые подписки. Вы можете проверка панели мониторинга работоспособности служб Azure и портал Azure о состоянии текущих сбоев и прошлых инцидентов.
Диагностика перезапусков виртуальных машин
Для запуска дополнительных диагностика можно использовать колонку Диагностика и решение в колонке виртуальной машины. Это может выявить более конкретные причины недавнего перезапуска виртуальной машины. Если возникла какая-либо проблема с гостевой ОС, соберите дамп памяти и обратитесь в службу поддержки.
Свяжитесь с нами для получения помощи
Если у вас есть вопросы или вам нужна помощь, создайте запрос в службу поддержки или обратитесь за поддержкой сообщества Azure. Вы также можете отправить отзыв о продукте в сообщество отзывов Azure.
База знаний
Зайдите в личный кабинет и перейдите по следующему пути: Панель клиента > Продукты/услуги > Детали продукта > Управление сервером.
Нажмите кнопку «Перезагрузка» или «Завершение работы» и после того, как сервер выключится, нажмите кнопку «Включение».
Помог ли вам данный ответ?
Связанные статьи
Предоставляются ли лицензии на ОС и ПО для виртуальных машин? Какие?
Maxiplace является SPLA партнером Microsoft и может предоставить в аренду любые лицензии компании.
Как организовать VPN-тоннель от виртуальной машины (или нескольких) до моего офиса?
В рамках стандартных услуг бесплатно предоставляется возможность организовать 1 IPSEC VPN до.
Как сбросить пароль для пользователей Bitrix?
После миграции проектов с других площадок, очень часто возникает проблема со входом в панель.
Как найти файлы которые были недавно изменены на сервере?
Зачастую требуется найти файлы, которые были модифицированы/созданы недавно, или за какой-либо.
Как перезагрузить виртуальную машину
- Актуально для:
- Parallels Desktop for Mac Standard Edition
- Parallels Desktop for Mac Pro Edition
- Parallels Desktop for Mac Business Edition
- Последняя проверка: Июн 22, 2022
- Доступные переводы:
- Получить обновленияСкачать
Симптомы
Вы не можете остановить или перезапустить виртуальную машину через интерфейс пользователя Parallels Desktop, так как все кнопки неактивны.
Решение
В таких ситуациях необходимо принудительно завершить процесс виртуальной машины в приложении «Мониторинг системы». Для этого выполните следующие действия:
- На компьютере Mac откройте программу Мониторинг системы(Finder >Программы >Служебные программы) и найдите следующий процесс: В Parallels Desktop имя процесса — это имя виртуальной машины.
- Выделите этот процесс, щелкните X в левом верхнем углу и выберите параметр Принудительно завершить.
- Перезапустите виртуальную машину.
Была ли эта статья полезной?
Как, по вашему мнению, можно улучшить эту статью?
Как перезапустить зависшую виртуальную машину в VMWare ESXi?
При работе с виртуальными машинами VMWare vSphere иногда случается так, что виртуальная машина зависает и ее нельзя никаким средствами перезагрузить с помощью интерфейса клиента vSphere. В этих случаях единственный способ отключения и перезагрузки виртуальной машины – перезагрузка всего сервера ESXi, что не всегда возможно, особенно если ESXi один, или оставшиеся машины DRS кластера не потянут дополнительной нагрузки в виде виртуальных машин с перезагружаемого сервера. В таких случаях можно вручную остановить зависшую виртуальную машины с помощью CLI. Эту операцию можно выполнить несколькими способами (vCLI, PowerCLI и т.д), я покажу как это сделать через консоль SSH.
Вначале на сервере ESXi 5 нужно активировать протокол SSH. Это можно сделать из графического интерфейса клиента vSphere, для чего выберите нужный хост (сервер ESXi) -> Configuration-> Security profile -> Properties -> SSH->Start, после чего нужно подключиться к серверу ESXi 5 по SSH.
В данной методике останавливать зависшую виртуалку будем с помощью команды esxtop.
В CLI введите команду esxtop, затем нажмите “c” для отображения ресурсов CPU и shift + V , чтобы отображать только процессы вириальных машин
Затем нажмите “f” (выбрать отображаемы поля) и “c” (отобразить поле LWID- Leader World Id) и нажмите Enter.
В столбце Name найдите виртуальную машину, которую нужно остановить, и определите номер ее LWID по соответствующему столбцу.
Затем осталось нажать кнопку «k» (kill) и набрать LWID номер той машины, которую нужно аварийно отключить. После такого “hard reset”, установленная ОС система запустится в режиме аварийной перезагрузки. В случае гостевой Windows, скрин будет выглядеть так.