VxRail: Усунення проблем з VxVerify перед оновленням VxRail

Ця стаття в базі присвячена усуненню несправностей, які заважають успішному запуску VxVerify.

Ця стаття з знаннями посилається на тести, які не мають відповідної відповіді (наприклад: Warning, Fail та Critical). Прикладом цього може бути запит, який несподівано повертає відповідь із запиту.

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

Якщо буде виявлено хибнопозитивний результат тесту, зберіть журнали VxVerify і зв'яжіться зі службою підтримки Dell, щоб відкрити заявку на Jira VXV у VxRail Engineering.

Існує кілька причин, які можуть завадити успішному запуску VxVerify.

• Найпоширенішою причиною збоїв є те, що скрипт на Python закінчився. Кожна версія VxVerify встановлена на тривалість лише два тижні з дати публікації. Це не застосовується, коли VxVerify запускається як плагін до фреймворку VxRail healthcheck (який змінює функціональність VxVeify).
• Іншими причинами можуть бути проблеми з дозволами на менеджері VxRail або проблеми зі зв'язком із хостами.
• Якщо причина події незрозуміла, зверніться до служби підтримки Dell, щоб відкрити заявку на VXV у VxRail Engineering.

Нижче наведено інструкції щодо збору журналів і усунення несправностей, якщо 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

• Якщо виникає помилка з магічним числом , це зазвичай означає, що для Python-версії на VxRM використовується неправильна версія VxVerify (Python). Наприклад, наведена нижче помилка виникає, якщо ви запустите VxVerify 2 на 7.0.320.

RuntimeError: Bad magic number in .pyc file

• Щоб перевірити, чи використовується правильна версія VxVerify, дивіться статтю (посилання нижче вимагає автентифікації до порталу підтримки Dell):
  • VxRail: Як запустити інструмент VxRail Verify (розділ VxVerify Releases ) 
• VxVerify створює програми, які називаються міньйонами, які надсилаються, запускаються та отримуються за допомогою SSH. Якщо SSH можна використовувати, навіть якщо він ще не увімкнений, VxVerify вмикається SSH для кожного хоста для виконання команд. Якщо хости заблоковані, де SSH не може запуститися, міньйони не можуть запуститися, а хост-тести повертають код результату: 2 (Відмовка) або 3 (Критична). Якщо це станеться, обговоріть SSH Дозволи у адміністратора.
• VxVerify2 розроблений для роботи на Python 2.7, який має бути на VM VxRM і зазвичай є єдиною доступною версією на Python. Якщо є більше версій на Python, запустіть наступне тестування (тут є -h Опціон, а саме --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 password потрібен для sudo доступ). Після виконання цієї команди видалення VxVerify потрібно встановити знову, використавши лише містичні дозволи:

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-користувача.

Тайм-аут

Якщо виконання міньйона займає більше 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

• Це слід перевірити, переглянувши журнал міньйонів цього хоста, щоб побачити, чи не зіткнувся міньйон із помилкою, яка призвела до зупинки, чи тестування тривало повільно і часу закінчилося.
• Якщо міньййон виконує правильний результат, наступні рядки мають бути останніми рядками в журналі:

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 не працює

Якщо результати міньйонів хоста не можуть бути передані за допомогою 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

• Це слід перевірити, переглянувши журнал міньйонів цього хоста, щоб побачити, чи зіткнувся міньйон із помилкою, яка призвела до зупинки, або чи був створений JSON-файл, який не вдається отримати доступ за допомогою SSH.
• Якщо міньйон завершує роботу правильно, наступні мають бути останніми рядками в журналі, які показують, що 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 log, як описано вище, і зверніться до підтримки 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 вимагають кореневого імені користувача та пароля, які можна вказати за допомогою -r та -w Варіанти відповідно. Тести vCenter запускаються лише якщо вони вказані (хоча кореневий користувач 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_hostname.txt - (віддалений текстовий вихід для кожного міньйона, що показує, який номер тесту триває)
• /json/host_uid.json - (файл, створений кожним міньйоном, з результатами тесту, який пізніше об'єднується з іншими даними хоста, а потім видаляється)
• vxverify_tests.json - (комбінований вихід для всіх тестів, який можна перевірити вручну для перегляду кожного результату тесту)
• vxtii.json - (об'єднані відповіді від хостів для запитів, таких як iDRAC Hardware Inventory)
• vxtii.txt - (звіт з узагальненою інформацією iDRAC та ESXi для кожного вузла)
• vxverify.txt - (таблиця підсумку, яка також відображається на екрані, якщо VxVerify не працює в тихому режимі)
• vxverify.html - (об'єднані звіти VxVerify та VxTii у форматі HTML) (присутні лише при прямому запуску VxVerify, а не вбудовані у перевірки здоров'я VxRail Manager)