VxRail. Устранение проблем с VxVerify перед модернизацией VxRail

Эта статья базы знаний посвящена устранению неполадок, которые препятствуют успешному запуску VxVerify.

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

Программа VxVerify предназначена для обнаружения проблем, которые могут привести к сложностям или сбоям во время модернизации VxRail. VxVerify создает программы Python, известные как Minions, которые отправляются на узлы VxRail. Ниже приведены типичные результаты испытаний, которые следует ожидать в vxverify_tests.json:

При обнаружении ложноположительных результатов теста соберите журналы VxVerify и обратитесь в службу поддержки Dell, чтобы открыть заявку Jira VXV в VxRail Engineering.

Существует несколько причин, препятствующих успешному запуску VxVerify.

• Наиболее распространенной причиной сбоев является истечение срока действия скрипта Python. Каждая версия VxVerify действует только две недели с даты ее публикации. Это не применяется, если VxVerify работает как подключаемый модуль для инфраструктуры проверки VxhealthRail (что изменяет функциональность VxVerify).
• Другими причинами могут быть проблемы с разрешениями в VxRail Manager или проблемы связи с хостами.
• Если причина события неясна, обратитесь в службу поддержки Dell, чтобы открыть заявку VXV в технических отделах VxRail.

Ниже приведены инструкции по сбору журналов и устранению неполадок, если VxVerify работает неправильно.

Сбор журналов для привлечения службы поддержки

При обращении в службу поддержки для решения проблем, связанных с VxVerify, загрузите весь архивный файл vxv для анализа, или vxverify Журнала .zip . Текущие автономные версии VxVerify сохраняют архивированный файл в /tmp, в котором есть все необходимые результаты и логи для анализа.

Пример. /tmp/vxverify-c9.zip

Кроме того, .zip из последнего запуска VxVerify, в файле также может присутствовать до пяти наборов предыдущих журналов /tmp Папку. Имена содержат дату и время, когда в атрибутах файлов были запущены следующие команды: 

vxv_previous_01.zip

Либо выполните следующую команду, чтобы архивировать все соответствующие файлы:

tar cvzf vxverify-2020-12-31.tgz /tmp/vxv/

Поиск и устранение неисправностей

Стандартные шаги по поиску и устранению неисправностей для работы VxVerify 2 (для VxRail 4.5, 4.7 и 7.0.000)

• Для работы VxVerify требуется Python, а для его запуска необходима командная строка:

python /tmp/vxv/vxverify.pyc

• Если возникает ошибка «magic number », это обычно означает, что для версии Python в VxRM используется неверная версия VxVerify. Например, следующая ошибка возникает при запуске VxVerify 2 на 7.0.320.

RuntimeError: Bad magic number in .pyc file

• Чтобы проверить, используется ли правильная версия VxVerify, см. статью (ссылка ниже требует аутентификации на портале поддержки Dell):
  • VxRail: запуск инструмента VxRail Verify (раздел «Выпуски VxVerify») 
• VxVerify создает программы minions, которые отправляются, выполняются и извлекаются с помощью SSH. Если SSH можно использовать, даже если он еще не включен, включается VxVerify SSH для каждого хоста для выполнения команд. Если хосты заблокированы, где SSH не удается запустить, minions не могут запуститься, а тесты узла возвращают код результата: 2 (сбой) или 3 (критический). В этом случае обсудите SSH у администратора.
• VxVerify2 предназначена для работы на Python 2.7, который должен присутствовать на виртуальной машине VxRM и обычно является единственной доступной версией Python. Если имеются другие версии Python, выполните следующие действия для проверки (у этого приложения есть свойство -h option, который является --help).

python2.7 vxverify.pyc -h

VxVerify записывает журналы и выходные файлы в /tmp/vxv/. Если у папки недостаточно прав, команду нельзя запустить. Проверьте разрешения папки с помощью следующих команд. Если у всех пользователей нет прав на чтение/запись, добавьте их с помощью команды chmod (могут потребоваться разрешения root):

$ ls -lad /tmp/vxv

drwxrwxrwx  3 mystic   users      4096 Oct  1 07:42 vxv

• Если в VxVerify сохраняются ошибки разрешений (например: «Отказано в разрешении для удаления предыдущих журналов»), попробуйте удалить файл vxv с помощью следующей команды (пароль root необходим для sudo доступа). После выполнения этой команды удаления необходимо снова установить VxVerify с использованием только разрешений mystic:

sudo rm -r -d /tmp/vxv

• Другой вариант — сохранить выходные файлы VxVerify в новую папку. VxVerify создает дерево, если оно не существует, с помощью метода -l или --log , за которым следует путь, по которому должны быть сохранены журналы. Пример.

python vxverify.pyc -l /tmp/vx1

Устранение различий между VxVerify2 и VxVerify 3 (для VxRail 7.0.010+)

Для VxRail 7.0.010 и более поздних версий необходимо использовать VxVerify 3 из-за фундаментальных изменений в VxRM.

Те же действия по устранению неполадок для VxVerify2 применимы и к VxVerify3, ЗА ИСКЛЮЧЕНИЕМ:

• Версия Python для VxVerify3 — 3.6.
• Расположение пакетов сайта, которые требуется изменить для VxVerify, которые находятся в одном из следующих расположений:
  • /mystic/telemetry/DCManager/venv/lib/python3.6/site-packages
  • /mystic/radar/venv/lib/python3.6/site-packages
• Если обе эти папки недоступны для пользователя mystic, программа VxVerify выдает сообщение об ошибке пакетов сайта и закрывается.
  • Временное решение проблемы — использование пользователя root.

Времени ожидания

Если выполнение minion занимает более 20 минут, VxVerify должен указать событие окончания времени ожидания в сводной таблице.

| Node-name  |Critical 66460| minion: Maximum run time for minion exceeded

• Соответствующая vxv.log Записи для этого:

2022-10-06 06:42:51-WARNING  Creating a fault json for missing minion

2022-10-06 06:42:51-WARNING  [fail_minion] Producing result file for lab-esx22, due to: Maximum run time for minion exceeded. See minion logs in /tmp/vxv

• Это можно проверить, просмотрев журнал minion этого хоста, чтобы узнать, не произошла ли ошибка minion, которая привела к его остановке, или тестирование продолжается медленно и для завершения не хватает времени.
• Если minion заполняется правильно, последними строками в журнале должны быть следующие:

2022-10-06 06:39:30 INFO    Writing to JSON: /tmp/xc882-61f1f3b9-7cb2-130a-35b0-minion.json

2022-10-06 06:39:30 INFO    JSON save: os.stat_result(st_mode=33206, st_ino=47144, st_dev=1, st_nlink=1, st_uid=0, st_gid=0, st_size=499562, st_atime=1665038370, st_mtime=1665038370, st_ctime=1665038370)

2022-10-06 06:39:30 DEBUG   ESXi minion's work is done.

Передача файла JSON не работает

Если результаты minion хоста невозможно передать с помощью SCP или SFTP обратно в VxRM, в таблице вывода можно просмотреть следующее:

| Node-name  |Critical 66460| minion: No JSON downloaded from node via SSH

• Соответствующая vxv.log Записи для этого:

2022-10-06 06:42:51-WARNING  Creating a fault json for missing minion

2022-10-06 06:42:51-WARNING  [fail_minion] Producing result file for lab-esx22, due to: No JSON downloaded from node via SSH. See minion logs in /tmp/vxv

• Это следует проверить, просмотрев журнал minion этого хоста, чтобы узнать, не произошла ли ошибка minion, которая привела к его остановке, или был создан файл JSON, к которому не удалось получить доступ с помощью SSH.
• Если minion завершается правильно, следующими должны быть последние строки в журнале, которые показывают, что JSON был успешно сохранен в /tmp папка узла:

2022-10-06 06:39:30 INFO    Writing to JSON: /tmp/xc882-61f1f3b9-7cb2-130a-35b0-minion.json

2022-10-06 06:39:30 INFO    JSON save: os.stat_result(st_mode=33206, st_ino=47144, st_dev=1, st_nlink=1, st_uid=0, st_gid=0, st_size=499562, st_atime=1665038370, st_mtime=1665038370, st_ctime=1665038370)

2022-10-06 06:39:30 DEBUG   ESXi minion's work is done.

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

• При использовании VxVerify3 попробуйте запустить команду --fix , который использует альтернативный флаг SSH Механизм. Это поможет избежать некоторых SSH Проблемы с разрешениями.
• Укажите новый путь с помощью -1 (папку предварительно создавать не требуется), что может помочь, если ошибки разрешений VxRM препятствуют передаче файла:
• Например: > python vxv2.pyc -l \tmp\vxv0
• Если описанные выше действия по-прежнему не помогают устранить проблему, сделайте снимок файловой системы VxRM, прежде чем приступать к очистке ненужных файлов и папок в /tmp и /home/mystic, например те, которые ранее использовались в VxVerify.
• Перезапустите VxRM (VxRail Manager).

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

Ошибки входа и учетных данных в VxVerify2 и VxVerify3

• Для выполнения тестов на VxRM (VxRail Manager) и узлах VxRail VxVerify не требуется никаких учетных данных. VxVerify может получить доступ к зашифрованным учетным данным непосредственно из базы данных VxRM и расшифровать их перед использованием. Иногда доступ к учетным данным управления VC невозможен, и в этом случае эти учетные данные можно указать в командной строке VxVerify:

python vxverify.py --verbose -u vxrailmgmt@localos -p ChangeMe1!

• Использование некоторых специальных символов, разрешенных vCenter, может вызвать проблемы в VxRail Manager (особенно для любых команд, использующих оболочку Linux). Убедитесь, что в паролях для vCenter или хостов ESXi не используется ни один из следующих символов:

` $ % / \

• Если у вас возникли сомнения относительно того, какое имя пользователя используется для управления, обратитесь к vxv.log. Пример.

... - DEBUG Users from runtime & settings records:     vxrailmgmt@localos & vxrailmgmt@localos

• Для тестов vCenter с использованием SSH требуется имя пользователя и пароль root, которые можно указать с помощью команды -r и -w опционов соответственно. Тесты vCenter выполняются только в том случае, если они указаны (хотя если пользователь root root, который используется по умолчанию, то необходимо указать только пароль root). Пример.

python vxverify.py --verbose -w R00tPassword!

Примеры критических неудачных тестов

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

#========================#======#=========#====================================================================#==============#
|  Hostname / Category   |Status  Dell_KB |  Warnings or Failures, unless tests Passed                         | Product S.N. |
#========================#======#=========#====================================================================#==============#
| VxRM                   | Critical 66460 | vc_external: VC MOB API connection failed                                        .| <- Stored vCenter password rejected
| VxRail                 | Critical 66460 | vxtii_err: Internal DO host query failed. See vxv.log for details in /tmp/vxv    .| <- ESXi node data cannot be retrieved from the VxRM config service
| _cluster               | Critical 66460 | esx_vers: No valid ESXi test results found                                       .| <- No ESXi tests could be run

Файлы VxVerify

VxVerify создает следующие файлы в /tmp/vxv/ или /var/log/mystic/vxv/ (если не указана другая папка журнала с помощью метода -l аргумента).  Все эти файлы сохраняются в одном архивном файле в /tmp, например, /tmp/vxverify-569ae010.zip или /tmp/vxv_previous_01.zip.
Проверка этих файлов вручную может помочь найти проблемы в кластере, даже если сценарий VxVerify не завершен полностью:   

• vxv.log - (файл журнала для сценария VxVerify)
• minion_hostname.log - (удаленный журнал для скрипта minion, запущенного на каждом хосте)
• minion_hostname.txt - (удаленный текстовый вывод для каждого миньона, показывающий, какой номер теста выполняется)
• /json/host_uid.json - (файл, созданный каждым minion, с результатами тестирования, который позже объединяется с другими данными хоста, а затем удаляется)
• vxverify_tests.json - (объединенный вывод для всех тестов, который можно проверить вручную, чтобы увидеть каждый результат теста)
• vxtii.json - (объединенные ответы хостов на такие запросы, как iDRAC Hardware Inventory)
• vxtii.txt - (отчет с обобщением информации о iDRAC и ESXi для каждого узла)
• vxverify.txt - (сводная таблица, которая также отображается на экране, если VxVerify не запущен в тихом режиме)
• vxverify.html - (объединенные отчеты VxVerify и VxTii в формате HTML) (присутствует только при непосредственном запуске VxVerify, а не встроен в проверки работоспособности VxRail Manager)