VxRail: rozwiązywanie problemów z VxVerify przed aktualizacją VxRail

Ten artykuł bazy wiedzy jest poświęcony rozwiązywaniu problemów, które uniemożliwiają pomyślne uruchomienie VxVerify.

Ten artykuł merytoryczny jest przywoływany z testów, które nie mają artykułu przeznaczonego do odpowiedniej odpowiedzi (na przykład: Ostrzeżenie, Błąd i Krytyczne). Przykładem tego może być zapytanie, które zwraca nieoczekiwaną odpowiedź z zapytania.

Narzędzie VxVerify służy do wykrywania problemów, które mogą powodować komplikacje lub awarie podczas uaktualniania VxRail. VxVerify tworzy programy w języku Python znane jako Minions, które są wysyłane do węzłów VxRail. Poniżej znajdują się typowe wyniki testów, których należy się spodziewać w vxverify_tests.json:

W przypadku wykrycia fałszywie dodatniego wyniku testu zbierz dzienniki VxVerify i skontaktuj się z działem pomocy technicznej firmy Dell, aby otworzyć zgłoszenie Jira VXV we współpracy z zespołem inżynierii VxRail.

Istnieje wiele przyczyn, które mogą uniemożliwić pomyślne uruchomienie VxVerify.

• Najczęstszą przyczyną niepowodzeń jest wygaśnięcie skryptu Pythona. Każda wersja VxVerify jest ustawiona tak, aby działała tylko przez dwa tygodnie od daty jej opublikowania. Nie ma to zastosowania, gdy VxVerify jest uruchamiany jako wtyczka do struktury kontroli poprawności działania VxRail (która zmienia funkcjonalność VxVerify).
• Innymi przyczynami mogą być problemy z uprawnieniami na poziomie VxRail Manager lub problemy z komunikacją z hostami.
• Jeśli przyczyna zdarzenia jest niejasna, skontaktuj się z działem pomocy technicznej firmy Dell, aby otworzyć zgłoszenie VXV w dziale inżynierii VxRail.

Poniższa sekcja zawiera instrukcje dotyczące zbierania dzienników i rozwiązywania problemów, jeśli VxVerify nie działa prawidłowo.

Gromadzenie dzienników na potrzeby działań pomocy technicznej

W przypadku korzystania z pomocy technicznej dotyczącej problemów związanych z VxVerify prześlij całe zarchiwizowane vxv do analizy lub vxverify Dziennika .zip . Bieżące autonomiczne wersje VxVerify zapisują zarchiwizowany plik w /tmp, który zawiera wszystkie niezbędne wyniki i dzienniki do analizy.

Oto przykład: /tmp/vxverify-c9.zip

Oprócz tego .zip z najnowszego uruchomienia VxVerify, maksymalnie pięć zestawów poprzednich dzienników może być również obecnych w /tmp Folder. Nazwy w atrybutach plików mają datę i godzinę, o której dzienniki zostały uruchomione: 

vxv_previous_01.zip

Możesz też uruchomić poniższe polecenie, aby zarchiwizować wszystkie odpowiednie pliki:

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

Rozwiązywanie problemów

Typowe kroki rozwiązywania problemów dotyczące programu VxVerify 2 (dla VxRail 4.5, 4.7 i 7.0.000)

• Program VxVerify wymaga uruchomienia Python, a wiersz poleceń do jego uruchomienia wygląda następująco:

python /tmp/vxv/vxverify.pyc

• Jeśli pojawi się błąd magic number , oznacza to zwykle, że niewłaściwa wersja VxVerify jest używana dla wersji Python na VxRM. Na przykład poniższy błąd występuje po uruchomieniu programu VxVerify 2 w wersji 7.0.320.

RuntimeError: Bad magic number in .pyc file

• Aby sprawdzić, czy używana jest prawidłowa wersja VxVerify, zapoznaj się z artykułem (poniższe łącze wymaga uwierzytelnienia w portalu pomocy technicznej firmy Dell):
  • VxRail: Uruchamianie narzędzia VxRail Verify (sekcja Wersje VxVerify ) 
• VxVerify tworzy programy nazywane minionami, które są wysyłane, uruchamiane i pobierane za pomocą SSH. Jeśli SSH może być używany, nawet jeśli nie jest jeszcze włączony, VxVerify włącza się SSH dla każdego hosta dla poleceń do uruchomienia. Jeśli hosty są zablokowane w miejscu, w którym SSH nie można uruchomić, miniony nie mogą zostać uruchomione, a testy hosta zwracają kod wyniku: 2 (awaria) lub 3 (krytyczny). Jeśli tak się stanie, należy omówić SSH uprawnienia u administratora.
• VxVerify2 jest przeznaczony do pracy w języku Python 2.7, który powinien być obecny na maszynie wirtualnej VxRM i jest zwykle jedyną dostępną wersją Python. Jeśli istnieje więcej wersji języka Python, uruchom następujące polecenie, aby go przetestować (ma -h opcja, która jest --help):

python2.7 vxverify.pyc -h

VxVerify zapisuje dzienniki i pliki wyjściowe w /tmp/vxv/. Jeśli nie ma wystarczających uprawnień, nie może zostać uruchomiony. Sprawdź uprawnienia folderu za pomocą poniższych poleceń. Jeśli nie ma uprawnień do odczytu/zapisu dla wszystkich użytkowników, dodaj je za pomocą chmod (mogą być wymagane uprawnienia roota):

$ ls -lad /tmp/vxv

drwxrwxrwx  3 mystic   users      4096 Oct  1 07:42 vxv

• Jeśli błędy uprawnień będą się powtarzać w VxVerify (na przykład: "Odmowa uprawnień do usuwania poprzednich dzienników."), spróbuj usunąć plik vxv za pomocą następującego polecenia (hasło główne jest potrzebne do sudo dostępu). Po uruchomieniu tego polecenia usunięcia należy ponownie zainstalować program VxVerify tylko przy użyciu uprawnień mystic:

sudo rm -r -d /tmp/vxv

• Inną opcją jest zapisanie plików wyjściowych VxVerify w nowym folderze. VxVerify tworzy drzewo, jeśli nie istnieje, używając -l lub --log , a następnie ścieżkę, w której powinny być zapisywane logi. Oto przykład:

python vxverify.pyc -l /tmp/vx1

Rozwiązywanie problemów z różnicami między VxVerify2 i VxVerify 3 (dla VxRail 7.0.010+)

W przypadku wersji VxRail 7.0.010 i nowszych należy zastosować program VxVerify 3 ze względu na fundamentalne zmiany w VxRM.

Te same kroki rozwiązywania problemów dla VxVerify2 dotyczą również VxVerify3, Z WYJĄTKIEM:

• Wersja języka Python dla VxVerify3 to 3.6.
• Lokalizacja pakietów strony, które VxVerify wymagają zmian, które znajdują się w jednej z poniższych lokalizacji:
  • /mystic/telemetry/DCManager/venv/lib/python3.6/site-packages
  • /mystic/radar/venv/lib/python3.6/site-packages
• Jeśli oba te foldery są niedostępne dla użytkownika mystic, program VxVerify wysyła komunikat o błędzie dotyczący pakietów strony i wyjścia.
  • Obejściem problemu jest użycie użytkownika root.

Limity czasu

Jeśli ukończenie minion trwa dłużej niż 20 minut, VxVerify musi podać zdarzenie przekroczenia limitu czasu w tabeli podsumowania.

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

• Odpowiedni vxv.log Wpisy na ten temat to:

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

• Należy to sprawdzić, zaglądając do dziennika stronników tego hosta, aby sprawdzić, czy stronnik napotkał błąd, który spowodował jego zatrzymanie, czy też testowanie trwało powoli i zabrakło czasu na jego ukończenie.
• Jeśli minion zostanie ukończony poprawnie, ostatnie wiersze w dzienniku powinny być następujące:

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.

Przesyłanie plików JSON nie działa

Jeśli nie można przenieść wyników minion hosta za pomocą SCP lub SFTP z powrotem do VxRM, w tabeli danych wyjściowych mogą być widoczne następujące informacje:

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

• Odpowiedni vxv.log Wpisy na ten temat to:

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

• Należy to sprawdzić, przeglądając dziennik minion tego hosta, aby sprawdzić, czy minion napotkał błąd, który spowodował jego zatrzymanie, czy też plik JSON został utworzony, ale nie można było uzyskać do niego dostępu za pomocą SSH.
• Jeśli minion zostanie ukończony poprawnie, poniżej powinny być ostatnie wiersze dziennika, które pokazują, że plik JSON został pomyślnie zapisany w /tmp Folder węzła:

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.

Aby rozwiązać powyższy problem, zalecane są następujące czynności:

• Jeśli używasz VxVerify3, spróbuj uruchomić z --fix flaga, która używa alternatywy SSH Mechanizm. Można w ten sposób uniknąć niektórych SSH Problemy z uprawnieniami.
• Określ nową ścieżkę za pomocą -1 (nie trzeba najpierw tworzyć folderu), co może pomóc, jeśli błędy uprawnień VxRM uniemożliwiają transfer plików:
• Na przykład, > python vxv2.pyc -l \tmp\vxv0
• Jeśli powyższe polecenia nadal nie działają, przed przystąpieniem do czyszczenia niepotrzebnych plików i folderów w katalogu VxRM wykonaj migawkę /tmp i /home/mystic, takie jak te wcześniej używane przez VxVerify.
• Uruchom ponownie VxRM (VxRail Manager).

Jeśli VxVerify napotka błąd, którego nie można naprawić w powyższych krokach, zapisz pakiet dzienników vxv zgodnie z powyższym opisem i eskaluj problem do działu pomocy technicznej firmy Dell.

Błędy logowania i poświadczeń w VxVerify2 i VxVerify3

• Aby uruchomić testy na VxRM (VxRail Manager) i węzłach VxRail, VxVerify nie wymaga żadnych poświadczeń. VxVerify może uzyskać dostęp do zaszyfrowanych poświadczeń bezpośrednio z bazy danych VxRM i odszyfrować je przed użyciem ich. Czasami nie można uzyskać dostępu do poświadczeń zarządzania VC, w takim przypadku można je określić w wierszu poleceń VxVerify:

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

• Użycie niektórych znaków specjalnych, które są dozwolone przez vCenter, może spowodować problemy dla programu VxRail Manager (szczególnie dla wszystkich poleceń korzystających z powłoki systemu Linux). Sprawdź, czy w hasłach do vCenter lub hostów ESXi nie użyto żadnego z poniższych znaków:

` $ % / \

• W razie wątpliwości co do nazwy użytkownika używanego do zarządzania należy zapoznać się z vxv.log. Oto przykład:

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

• Testy dotyczące serwera vCenter przeprowadzane za pomocą połączenia SSH wymagają podania nazwy użytkownika root i hasła, które można określić za pomocą -r i -w opcji. Testy vCenter są uruchamiane tylko wtedy, gdy zostały określone (chociaż jeśli użytkownik root root, co jest ustawieniem domyślnym, należy określić tylko hasło główne). Oto przykład:

python vxverify.py --verbose -w R00tPassword!

Przykłady krytycznych niepowodzeń testów

Mogą one być wynikiem poważnych błędów, które uniemożliwiają przeprowadzenie dalszych testów. Na przykład jeśli nazwa użytkownika i hasło zarządzania vCenter zapisane w VxRM nie są aktualne, wszystkie zapytania do interfejsu API VC kończą się niepowodzeniem i nie można przeprowadzić żadnych dalszych testów. Przykłady:

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

Pliki VxVerify

VxVerify tworzy następujące pliki w /tmp/vxv/ lub /var/log/mystic/vxv/ (chyba, że określono inny folder rejestrowania za pomocą -l argument).  Wszystkie te pliki są zapisywane w jednym pliku archiwum w /tmp, takich jak /tmp/vxverify-569ae010.zip lub /tmp/vxv_previous_01.zip.
Ręczne sprawdzenie tych plików może pomóc w znalezieniu problemów w klastrze, nawet jeśli skrypt VxVerify nie zostanie w pełni ukończony:   

• vxv.log - (plik dziennika dla skryptu VxVerify)
• minion_hostname.log - (zdalny dziennik skryptu minion uruchomionego na każdym hoście)
• minion_hostname.txt - (zdalne wyświetlanie tekstu dla każdego miniona, pokazujące, który numer testu jest w toku)
• /json/host_uid.json - (plik utworzony przez poszczególne skrypty minion z wynikami testu, który jest później scalony z innymi danymi hosta, a następnie usunięty)
• vxverify_tests.json - (łączne dane wyjściowe dla wszystkich testów, które można sprawdzić ręcznie, aby zobaczyć każdy wynik testu)
• vxtii.json - (połączone odpowiedzi z hostów na zapytania, takie jak inwentaryzacja sprzętu kontrolera iDRAC)
• vxtii.txt - (raport podsumowujący informacje o kontrolerach iDRAC i ESXi dla każdego węzła)
• vxverify.txt - (tabela podsumowująca, która jest również wyświetlana na ekranie, jeśli VxVerify nie jest uruchomiony w trybie cichym)
• vxverify.html - (połączone raporty VxVerify i VxTii w formacie HTML) (dostępne tylko podczas bezpośredniego uruchamiania VxVerify, a nie osadzone w kontrolach poprawności działania VxRail Manager)