VxRail: Odstraňování problémů s nástrojem VxVerify před upgradem VxRail

Tento článek znalostní databáze je věnován odstraňování problémů, které brání úspěšnému spuštění nástroje VxVerify.

Na tento článek znalostní databáze se odkazuje z testů, které nemají článek zaměřený na příslušnou odpověď (například: Varování, Selhání a Kritické). Příkladem může být dotaz, který vrací neočekávanou odpověď z dotazu.

Nástroj VxVerify je určen k detekci problémů, které mohou způsobit komplikace nebo selhání během upgradů VxRail. Nástroj VxVerify vytváří programy Python, známé jako Minions, které se odesílají do uzlů VxRail. Níže jsou uvedeny typické výsledky testů, které lze očekávat vxverify_tests.json:

Pokud zjistíte falešně pozitivní výsledek testu, shromážděte protokoly VxVerify, zapojte podporu společnosti Dell a otevřete tiket Jira VXV u technického oddělení VxRail.

Existuje několik příčin, které mohou zabránit úspěšnému spuštění nástroje VxVerify.

• Nejčastější příčinou selhání je vypršení platnosti skriptu Python. Každá verze nástroje VxVerify je nastavena tak, aby fungovala pouze 2 týdny od data, kdy byla zveřejněna. To neplatí, pokud je nástroj VxVerify spuštěn jako doplněk pro rámec kontroly stavu VxRail (který mění funkci nástroje VxVerify).
• Dalšími důvody mohou být problémy s oprávněními v nástroji VxRail Manager nebo problémy s komunikací s hostiteli.
• Pokud je příčina události nejasná, obraťte se na podporu společnosti Dell a otevřete tiket VXV u technického oddělení VxRail.

Níže uvedená část obsahuje pokyny ke shromažďování protokolů a odstraňování problémů, pokud nástroj VxVerify nefunguje správně.

Shromažďování protokolů pro zapojení podpory

Při zapojení podpory ohledně problémů souvisejících s nástrojem VxVerify nahrajte celý archivovaný vxv pro analýzu, nebo vxverify Protokolu .zip . Aktuální samostatné verze nástroje VxVerify uloží archivovaný soubor do /tmp, který obsahuje všechny potřebné výsledky a protokoly pro analýzu.

Například: /tmp/vxverify-c9.zip

Kromě toho .zip z nejnovějšího spuštění nástroje VxVerify, může být v souboru přítomno až 5 sad předchozích protokolů /tmp Složky. Názvy mají v atributech souboru uvedené datum a čas, kdy byly spuštěny: 

vxv_previous_01.zip

Případně můžete pomocí následujícího příkazu archivovat všechny příslušné soubory:

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

Odstraňování problémů

Typický postup odstraňování problémů se spouštěním nástroje VxVerify 2 (pro verzi VxRail 4.5, 4.7 a 7.0.000)

• Nástroj VxVerify potřebuje ke spuštění jazyk Python a následující příkaz:

python /tmp/vxv/vxverify.pyc

• Pokud dojde k chybě Magic Number Error, obvykle to znamená, že pro verzi Python v softwaru VxRM se používá špatná verze nástroje VxVerify. K níže uvedené chybě dochází například při spuštění nástroje VxVerify 2 na verzi 7.0.320.

RuntimeError: Bad magic number in .pyc file

• Chcete-li zkontrolovat, zda je použita správná verze nástroje VxVerify, přečtěte si článek (níže uvedený odkaz vyžaduje ověření na portálu podpory společnosti Dell):
  • VxRail: Jak spustit nástroj VxRail Verify (část VxVerify Releases ) 
• Nástroj VxVerify vytváří programy, které se nazývají minion a které se odesílají, spouští a načítají pomocí SSH. Pokud SSH lze použít, i když ještě není povoleno, nástroj VxVerify se zapne SSH pro každého hostitele pro příkazy, které se mají spustit. Pokud jsou hostitelé uzamčeni, kde SSH Program nelze spustit, nelze spustit ani programy minion a testy hostitele vrátí kód výsledku: 2 (selhání) nebo 3 (kritické). Pokud k tomu dojde, proberte SSH oprávnění u správce.
• Nástroj VxVerify2 je navržený pro provoz ve verzi Python 2.7, který by měl být přítomný na virtuálním počítači VxRM a je obvykle jedinou dostupnou verzí Python. Pokud máte k dispozici více verzí Python, proveďte test pomocí následujícího příkazu (ten má -h možnost, která je --help):

python2.7 vxverify.pyc -h

Nástroj VxVerify zapisuje protokoly a vytváří soubory do /tmp/vxv/. Pokud nemá dostatečná oprávnění, nebude jej možné spustit. Zkontrolujte oprávnění složky pomocí následujících příkazů. Pokud některý uživatel nemá oprávnění pro čtení/zápis, přidejte je pomocí chmod (mohou být vyžadována oprávnění uživatele root):

$ ls -lad /tmp/vxv

drwxrwxrwx  3 mystic   users      4096 Oct  1 07:42 vxv

• Pokud chyby oprávnění v nástroji VxVerify přetrvávají (například: "Permission denied for deleting previous logs"), zkuste odstranit vxv s následujícím příkazem (heslo uživatele root je potřeba pro sudo přístup). Po spuštění tohoto příkazu k odstranění je nutné nástroj VxVerify znovu nainstalovat pouze s oprávněními mystic:

sudo rm -r -d /tmp/vxv

• Další možností je uložit výstupní soubory VxVerify do nové složky. Pokud strom neexistuje, nástroj VxVerify jej vytvoří pomocí příkazu -l nebo --log následovaná cestou, do které mají být protokoly uloženy. Například:

python vxverify.pyc -l /tmp/vx1

Odstraňování problémů s rozdíly mezi nástrojem VxVerify2 a nástrojem VxVerify 3 (pro verzi VxRail 7.0.010+)

U verzí VxRail 7.0.010 a novějších je nutné použít nástroj VxVerify 3 kvůli zásadním změnám v nástroji VxRM.

Stejné kroky pro odstraňování problémů s nástrojem VxVerify2 platí také pro nástroj VxVerify3, s výjimkou:

• Verze Pythonu pro nástroj VxVerify3 je 3.6.
• Umístění balíčků pracoviště, které nástroj VxVerify vyžaduje změny, se nachází v jednom z níže uvedených umístění:
  • /mystic/telemetry/DCManager/venv/lib/python3.6/site-packages
  • /mystic/radar/venv/lib/python3.6/site-packages
• Pokud jsou obě tyto složky nepřístupné uživateli mystic, program VxVerify zobrazí chybovou zprávu ohledně balíčků pracoviště a ukončení.
  • Zástupným řešením je použití uživatele root.

Časové limity

Pokud dokončení procesu minion trvá déle než 20 minut, musí nástroj VxVerify v souhrnné tabulce uvést událost vypršení časového limitu.

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

• Odpovídající vxv.log Položky pro to jsou:

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

• To je třeba zkontrolovat tak, že se podíváte do protokolu minion daného hostitele, abyste zjistili, zda minion narazil na chybu, která způsobila jeho zastavení, nebo zda testování pokračovalo pomalu a vypršel mu čas na dokončení.
• Pokud se minion dokončí správně, měly by být následující poslední řádky v protokolu:

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.

Přenos souboru JSON nefunguje

Pokud nelze výsledky programů minion hostitele přenést pomocí SCP nebo SFTP zpět do nástroje VxRM, ve výstupní tabulce se mohou zobrazit následující informace:

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

• Odpovídající vxv.log Položky pro to jsou:

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

• To by mělo být zkontrolováno tak, že se podíváte na protokol minion pro daného hostitele, abyste zjistili, zda minion narazil na chybu, která způsobila zastavení, nebo zda byl vytvořen soubor JSON, ale nebylo možné k němu přistupovat pomocí SSH.
• Pokud se minion dokončí správně, měly by být následující poslední řádky v protokolu, které ukazují, že JSON byl úspěšně uložen do /tmp Složka uzlu:

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.

Doporučený postup pro odstranění výše uvedených problémů:

• Pokud používáte nástroj VxVerify3, zkuste spustit příkaz --fix příznak, který používá alternativu SSH Mechanismus. Některým se tak můžete vyhnout SSH Problémy s oprávněními.
• Zadejte novou cestu pomocí -1 (složku není nutné nejprve vytvořit), což může pomoci, pokud přenosu souboru brání chyby oprávnění VxRM:
• Například > python vxv2.pyc -l \tmp\vxv0
• Pokud výše uvedené kroky stále nefungují, pořiďte snapshot nástroje VxRM, než odstraníte všechny nepotřebné soubory a složky v /tmp a /home/mystic, jako jsou ty, které dříve používal nástroj VxVerify.
• Restartujte nástroj VxRM (VxRail Manager).

Pokud v nástroji VxVerify dojde k chybě, kterou nelze výše uvedenými kroky opravit, uložte balíček protokolu vxv, jak je podrobně popsáno výše, a eskalujte problém podpoře společnosti Dell.

Chyby přihlášení a přihlašovacích údajů v nástrojích VxVerify2 a VxVerify3

• Ke spouštění testů v nástroji VxRM (VxRail Manager) a uzlech VxRail nástroj VxVerify nevyžaduje žádné přihlašovací údaje. Nástroj VxVerify má přístup k šifrovaným přihlašovacím údajům přímo z databáze VxRM a před použitím je dešifruje. Někdy nelze získat přístup k přihlašovacím údajům pro správu VC. V takovém případě lze tyto přihlašovací údaje zadat v příkazovém řádku VxVerify:

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

• Použití některých speciálních znaků povolených systémem vCenter může způsobit problémy v nástroji VxRail Manager (zejména u všech příkazů, které využívají prostředí Linux Shell). Zkontrolujte, že v heslech systému vCenter nebo hostitelů ESXi není použit žádný z následujících znaků:

` $ % / \

• Máte-li pochybnosti o tom, které uživatelské jméno se používá pro správu, obraťte se na vxv.log. Například:

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

• Testy systému vCenter pomocí protokolu SSH vyžadují uživatelské jméno a heslo uživatele root, které lze zadat pomocí příkazu -r a -w možnosti, resp. Testy systému vCenter se spustí pouze v případě, že jsou tyto údaje zadány (i když pokud je uživatel root root, což je výchozí nastavení, pak je nutné zadat pouze heslo uživatele root). Například:

python vxverify.py --verbose -w R00tPassword!

Příklady kritických selhání testů

Příčinou mohou být závažné chyby, které brání spuštění dalších testů. Pokud například uživatelské jméno a heslo pro správu systému vCenter uložené v softwaru VxRM nejsou aktuální, všechny dotazy na rozhraní API VC selžou a nebude možné spustit další testování. Příklady:

#========================#======#=========#====================================================================#==============#
|  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

Soubory VxVerify

Nástroj VxVerify vytvoří v složce následující soubory /tmp/vxv/ nebo /var/log/mystic/vxv/ (pokud není pomocí příkazu -l argument).  Všechny tyto soubory jsou uloženy v jednom archivním souboru v /tmpNapříklad /tmp/vxverify-569ae010.zip nebo /tmp/vxv_previous_01.zip.
Ruční kontrola těchto souborů může pomoci najít problémy v clusteru, i když se skript VxVerify zcela nedokončí:   

• vxv.log - (soubor protokolu pro skript VxVerify)
• minion_hostname.log - (vzdálený log pro skript minion spuštěný na každém hostiteli)
• minion_hostname.txt - (vzdálený textový výstup pro každého miniona, který ukazuje, které číslo testu probíhá)
• /json/host_uid.json - (soubor vytvořený jednotlivými programy minion s výsledky testů, který se později sloučí s dalšími hostitelskými daty a poté se odstraní)
• vxverify_tests.json - (kombinovaný výstup pro všechny testy, který lze zkontrolovat ručně, aby se zobrazil výsledek každého testu)
• vxtii.json - (kombinované odpovědi od hostitelů na dotazy, jako je například inventář hardwaru řadiče iDRAC)
• vxtii.txt - (zpráva shrnující informace o řadiči iDRAC a ESXi pro každý uzel)
• vxverify.txt - (souhrnná tabulka, která se také zobrazí na obrazovce, pokud nástroj VxVerify není spuštěn v tichém režimu)
• vxverify.html - (kombinované reporty VxVerify a VxTii ve formátu HTML) (zobrazí se pouze při přímém spuštění nástroje VxVerify, nikoli při spuštění nástroje VxRail Manager)