Устранение неполадок при подготовке виртуальной машины с помощью cloud-init

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

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

Некоторые примеры проблем с подготовкой:

• API поставщика вычислительных ресурсов возвращает ошибку, и cloud-init сообщает о результирующей ошибке.
• Виртуальная машина зависает на "создании" в течение 40 минут, и создание виртуальной машины помечается как неудачное.
• Пользовательские данные или пользовательские данные не обрабатываются.
• Не удалось подключить эфемерный диск (для виртуальных машин с SKU, имеющих диски ресурсов SCSI).
• Пользователи не создаются или возникают проблемы с доступом пользователей.
• Сеть не настроена правильно.
• Сбои файла или секции.

В этой статье описывается устранение неполадок сloud-init. Больше подробностей см. в cloud-init deep dive.

Осторожность

В этой статье говорится о CentOS, дистрибутиве Linux, который больше не поддерживается (EOS). Думайте об использовании и планировании соответствующим образом. Для получения дополнительной информации смотрите руководство по окончанию поддержки CentOS.

Устранение неполадок, сообщаемых cloud-init и зарегистрированных как ошибок

Cloud-init выдает структурированные ошибки при сообщении о сбое в Azure во время развертывания. Эти сообщения об ошибках включают причину и вспомогательные данные (например, метку времени, идентификатор виртуальной машины, URL-адрес документации и т. д.), чтобы помочь изучить сбой.

Причина	Описание	Действие
не удается найти DHCP-интерфейс	Сетевой интерфейс не найден.	Удаление и повторное создание виртуальной машины. Если проблема не исчезнет, убедитесь, что установлены сетевые драйверы и ядро, специфичное для Azure, и проверьте диагностику загрузки, чтобы убедиться, что eth0 определен.
сбой при получении аренды DHCP	Служба DHCP не отвечает из-за временной проблемы платформы.	Повторное развертывание виртуальной машины (удаление и повторное создание) из-за временной проблемы с платформой DHCP Azure.
не удается найти основной DHCP-интерфейс	Основной DHCP-интерфейс не найден.	Проверьте диагностику загрузки, чтобы убедиться, что первичный сетевой интерфейс именован eth0 и не переименован.
тайм-аут подключения при запросе к IMDS	Подключения к IMDS могут истекать из-за временной проблемы с платформой, NSG или брандмауэра ОС.	Удаление и повторное создание виртуальной машины. Если проблема сохраняется, убедитесь, что брандмауэр NSG или ОС не предотвращает доступ к IMDS.
тайм-аут чтения при запросе к IMDS	Подключения к IMDS могут завершаться из-за временной проблемы платформы или конфигурации брандмауэра ОС.	Удаление и повторное создание виртуальной машины. Если проблема сохраняется, убедитесь, что брандмауэр ОС не предотвращает доступ к IMDS.
непредвиденный разбор метаданных ovf-env.xml	Неправильные метаданные виртуальной машины в ovf-env.xml.	Отправьте проблему в трекер cloud-init.
ошибка ожидания завершения работы узла	Сбой во время обработки завершения работы узла.	Отправьте проблему в трекер cloud-init.
Агент Azure-proxy-agent не найден	Отсутствует двоичный azure-proxy-agent файл.	Убедитесь, что агент прокси-сервера Azure установлен на образе. Дополнительные сведения об устранении неполадок см. в руководстве по устранению неполадок MSP.
Сбой статуса azure-proxy-agent	Агент прокси-сервера сообщил об ошибке статуса.	Проверьте журналы прокси-агента и при необходимости обновите их. Дополнительные сведения об устранении неполадок см. в руководстве по устранению неполадок MSP.
необработанное исключение	Непредвиденная ошибка произошла внутри cloud-init.	Отправьте проблему в трекер cloud-init.

Сведения о включении и проверке диагностики загрузки см. в разделе "Диагностика загрузки".

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

Устранение других сбоев, не связанных с cloud-init

В зависимости от сбоя рассмотрите эти действия.

Шаг 1. Тестирование развертывания с помощью customData

Cloud-init может принять customData, переданный ему при создании виртуальной машины. Во-первых, следует убедиться, что эта конфигурация не вызывает никаких проблем с развертываниями. Некоторые распространенные проблемы могут включать:

• YamL неправильно сформирован
• Скрипты внутри customData завершаются сбоем или зависанием
• Переопределите чем зависит cloud-init (например, настройка диска или сети)
• Данные содержат неподдерживаемые символы или проблемы с кодировкой. Попробуйте развернуть виртуальную машину без передачи какой-либо конфигурации. Если подготовка виртуальной машины не удалась, выполните рекомендуемые действия по устранению неполадок. Если конфигурация не применяется, обратитесь к шагу 4.

Шаг 2. Проверка требований к образу

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

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

• Подготовка виртуальной машины на основе CentOS для Azure
• Debian Linux
• Контейнер Flatcar Linux
• Oracle Linux
• Red Hat Enterprise Linux
• SLES & openSUSE
• Ubuntu
• Информация о нерекомендованных дистрибутивах

Для поддерживаемых образов Azure cloud-initдистрибутивы Linux уже имеют все необходимые пакеты и конфигурации, чтобы правильно подготавливать образ в Azure. Если вы обнаружите, что виртуальная машина не может создать данные из собственного проверенного образа, попробуйте использовать поддерживаемый образ Azure Marketplace, который уже настроен для Cloud-init, с необязательным customData. Если образ customData Azure Marketplace работает правильно, возможно, возникла проблема с выбранным изображением.

Шаг 3. Получение & проверки журналов виртуальных машин

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

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

• Включите диагностику загрузки перед созданием виртуальной машины и Просмотрите их во время загрузки.

• Последовательная консоль

• Выполните восстановление виртуальной машины AZ , чтобы подключить и подключить диск ОС (lvm, нет lvm), что позволит собирать и проверять эти журналы:

  /rescue/var/log/waagent*
  /rescue/var/log/syslog*
  /rescue/var/log/rsyslog*
  /rescue/var/log/messages*
  /rescue/var/log/kern*
  /rescue/var/log/dmesg*
  /rescue/var/log/boot*
  /rescue/ /var/log/cloud-init.log
  /rescue//var/log/cloud-init-output.log
  

Замечание

Кроме того, можно создать виртуальную машину спасения вручную с помощью портал Azure. Дополнительные сведения см. в статье "Устранение неполадок виртуальной машины Linux путем подключения диска ОС к виртуальной машине восстановления с помощью портал Azure". Чтобы начать начальное устранение неполадок, начните с серийных журналов и журналов cloud-init, чтобы понять, где произошел сбой. Затем используйте другие логи для более глубокого анализа, чтобы получить дополнительные аналитические сведения.

• /var/log/cloud-init.log
• /var/log/cloud-init-output.log
• Журналы сериализации и загрузки

Во всех журналах начните поиск слов "Ошибка", "ПРЕДУПРЕЖДЕНИЕ", "WARN", "err", "error" и "ERROR". Рекомендуется настроить конфигурацию для игнорирования регистра символов при поиске.

Кроме того, используйте команду cloud‑init collect‑logs для сбора всех необходимых журналов. Последние версии cloud-init в Azure (≥ 18.2) включают команду collect-logs, которая:

Собирает основные логи: /var/log/cloud-init*.log, метаданные экземпляра, системная информация.

Упаковывает все в архив .tar.gz с меткой времени.

Сохраняет архив локально (например, /tmp/cloud-init-logs-timestamp.tar.gz).

Подсказка

При устранении неполадок с пользовательским изображением следует добавить пользователя во время изображения. Если не удается настроить пользователя администратора, вы всё равно можете войти в ОС.

Анализ журналов

Представлены дополнительные сведения о том, на что следует обратить внимание в каждом журнале cloud-init.

/var/log/cloud-init.log

По умолчанию все события cloud-init с приоритетом отладки или выше записываются в /var/log/cloud-init.log. Этот журнал предоставляет подробные записи о каждом событии, которое произошло во время инициализации cloud-init.

Рассмотрим пример.

2019-10-10 04:51:25,321 - util.py[DEBUG]: Failed mount of '/dev/sr0' as 'auto': Unexpected error while running command.
Command: ['mount', '-o', 'ro,sync', '-t', 'auto', u'/dev/sr0', '/run/cloud-init/tmp/tmpLIrklc']
Exit code: 32
Reason: -
Stdout:
Stderr: mount: unknown filesystem type 'udf'
2020-01-31 00:21:53,352 - DataSourceAzure.py[WARNING]: /dev/sr0 was not mountable

При обнаружении ошибки или предупреждения, прочитайте по журналу cloud-init назад, чтобы понять, что cloud-init пытался сделать до возникновения ошибки или предупреждения. Во многих случаях cloud-init запускает команды ОС или выполняет шаги подготовки до возникновения ошибки. Эти действия помогут объяснить, почему ошибка отображается в журналах. В следующем примере показано, что cloud-init попыталась подключить устройство прямо перед тем, как возникла проблема.

2019-10-10 04:51:24,010 - util.py[DEBUG]: Running command ['mount', '-o', 'ro,sync', '-t', 'auto', u'/dev/sr0', '/run/cloud-init/tmp/tmpXXXXX'] with allowed return codes [0] (shell=False, capture=True)

Если у вас есть доступ к последовательной консоли, можно попробовать повторно выполнить команду, которую пытался запустить cloud-init.

Ведение журнала для /var/log/cloud-init.log можно также перенастроить в /etc/cloud/cloud.cfg.d/05_logging.cfg. Дополнительные сведения о ведении журнала cloud-init см. в документации по cloud-init.

/var/log/cloud-init-output.log

Вы можете получить сведения из stdout и stderr во время этапов сloud-init. Обычно эти данные включают сведения о таблице маршрутизации, сведения о сети, сведения stdout, о проверке ключа узла SSH и stderr для каждого этапа cloud-init, а также метки времени. При необходимости ведение журналов stderrstdout можно перенастроить в /etc/cloud/cloud.cfg.d/05_logging.cfg.

Последовательный журнал/журнал загрузки

Cloud-init имеет несколько зависимостей. Эти зависимости описаны в необходимых предварительных требованиях для образов в Azure, таких как сеть, хранилище, возможность подключения ISO и форматирования временного диска. Любая из этих зависимостей может вызвать ошибки и вызвать сбой cloud-init. Например, если виртуальная машина не может получить аренду DHCP, cloud-init завершается ошибкой.

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

Шаг 4. Выясните, почему конфигурация не применяется

Не все сбои в Cloud-init приводят к неустранимой ошибке подготовки. Например, если вы используете runcmd модуль в конфигурации cloud-init, ненулевой код выхода из команды приводит к сбою развертывания виртуальной машины. Это поведение наблюдается потому, что модуль выполняется после основных этапов подготовки на первых трех стадиях cloud-init. Чтобы устранить неполадки и выяснить, почему конфигурация не была применена, просмотрите журналы на третьем шаге и модули cloud-init вручную. Рассмотрим пример.

• runcmd — запускаются ли сценарии без ошибок? Чтобы убедиться, что они выполняются должным образом, запустите конфигурацию вручную из терминала.
• Установка пакетов. у виртуальной машины есть доступ к репозиториям пакетов?
• customData Проверьте конфигурацию, предоставленную виртуальной машине. Этот файл находится в /var/lib/cloud/instances/<unique-instance-identifier>/user-data.txt.

Дальнейшие шаги

Если cloud-init пропускает конфигурацию, изучите каждый этап cloud-init и время выполнения модуля, чтобы определить причину. См. дополнительные сведения в разделе «Подробное рассмотрение конфигурации cloud-init».