Общие сведения о перезагрузке системы для виртуальной машины 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.
Перезагрузить виртуальную машину
Вы можете запустить перезагрузку виртуальной машины и ее гостевой операционной системы. Обычно перезагрузка выполняется после обновлений или изменения конфигурации виртуальной машины.
- Перед началом работы
- Порядок действий
- Результат
Перед началом работы
Убедитесь, что статус виртуальной машины — Запущена .
Порядок действий
- Авторизуйтесь в личном кабинете.
- Перейдите в раздел Evolution и выберите сервис Виртуальные машины .
- Нажмите в строке виртуальной машины.
- Выберите Перезагрузить и подтвердите перезагрузку.
Результат
После запуска перезагрузки виртуальной машины ее статус перейдет в Перезагружается , а затем опять изменится на Запущена . Гостевая операционная система виртуальной машины также перезагрузится.
Перезагрузка в командной строке виртуальной машины Proxmox VE.
Если вы не слышали про такой проект Proxmox VE, то запомните это название, чтобы вспомнить его, когда вам потребуется удобное и бесплатное решение для внедрения виртуализации. Proxmox VE — это Debian Linux + веб интерфейс, благодаря которым вы получите доступ к мощному функционалу гипервизора KVM, Qemu, контейнерам LXC и СХД Ceph. У Proxmox VE есть развитый API, позволяющий реализовать альтернативный доступ к вашим виртуальным машинам. В данной статье речь пойдёт о консольной утилите pvesh, использующей API и помогающей админу в автоматизации его повседневных задач. Встала задача перезагружать виртуальную машину не собственными командами из планировщиков операционной системы (изнутри виртуальной машины), а снаружи, средствами Proxmox VE посылать сигнал, словно нажата виртуальная кнопка питания, приказывающая виртуальному серверу закругляться.
Хотелось бы создать решение, которое не было бы привязано к текущему расположению виртуальных машин на физических серверах в кластере виртуализации. Мы с коллегами активно используем Живую Миграцию, и сегодня VM1 работает на node2, а завтра её отправят в режиме онлайн на node3.
Данное требование сразу поставило крест на использовании низкоуровневой команды qm, которая требует отдачи ей приказа на той ноде кластера, где в данный момент трудится нужная виртуальная машина. Уже показывал мощь PveSh в примерах, так как он использует API Proxmox VE и позволяет реализовать задуманное.
Прежде чем начать перезагружать сервера, стоит напомнить, что для MS Windows Server неспроста даны ценные советы по их подготовке к работе в виртуализированной среде. При попытке их выключить через веб интерфейс или в консоли, у вас будет выведен запрос, и такое поведение нужно изменить.
К сожалению, нажимая виртуальную кнопку питания, вы выключаете виртуальный сервер, а не перезагружаете. То есть у нас не будет restart в том смысле, что будет shutdown + start. Для работы скрипта требуется лишь наличие jq, которая есть в стандартных репозиториях Debian и Ubuntu, и она облегчает работу с JSON ответами. Работа скрипта не сложна. Вначале получаем по-данному нам VMID имя ноды, на которой трудится в данный момент эта виртуальная машина. Делаем shutdown. Далее в вечном цикле опрашиваем статус и, когда он становится stopped, то смело прерываем цикл while, и выходим на финишную прямую, запуская виртуальную машину.
#!/bin/bash # vasilisc.com clear if ! [ -x "$(command -v jq)" ]; then echo 'Error: jq is not installed.' >&2 echo "apt-get install jq" exit 1 fi if [ -z $1 ]; then echo "Use "$0" VMID" exit 1 fi VMID=$1 NODE=`pvesh get /cluster/resources --type vm | jq --raw-output ".[] | select(.vmid == $) | .node"` # shutdown VM pvesh create /nodes/$/qemu/$/status/shutdown # get status while true do STATUS=`pvesh get /nodes/$/qemu/$/status/current | jq --raw-output ".status"` echo "NODE="$" VMID="$" is "$ sleep 5 if [ "$" == "stopped" ]; then break fi done # start sleep 5 pvesh create /nodes/$/qemu/$/status/start date exit 0
База знаний
Зайдите в личный кабинет и перейдите по следующему пути: Панель клиента > Продукты/услуги > Детали продукта > Управление сервером.
Нажмите кнопку «Перезагрузка» или «Завершение работы» и после того, как сервер выключится, нажмите кнопку «Включение».
Помог ли вам данный ответ?
Связанные статьи
Предоставляются ли лицензии на ОС и ПО для виртуальных машин? Какие?
Maxiplace является SPLA партнером Microsoft и может предоставить в аренду любые лицензии компании.
Как организовать VPN-тоннель от виртуальной машины (или нескольких) до моего офиса?
В рамках стандартных услуг бесплатно предоставляется возможность организовать 1 IPSEC VPN до.
Как сбросить пароль для пользователей Bitrix?
После миграции проектов с других площадок, очень часто возникает проблема со входом в панель.
Как найти файлы которые были недавно изменены на сервере?
Зачастую требуется найти файлы, которые были модифицированы/созданы недавно, или за какой-либо.