Saturday, April 14, 2012

Vmware host busy/scsi parity error–solved

W lutym pisałem o problemach z transferem między hostami z ESXi a macierzami. Link

Po zamknięciu zgłoszenia zapomniałem dopisać jak się cała sprawa zakończyła[: Oficjalna odpowiedź od inżyniera drugiego lub trzeciego stopnia jest dość ciekawa.

W przypadku środowisk, w których występują urządzenia posiadające interfejsy FC z różnymi dopuszczalnymi prędkościami należy ustawić na wszystkich urządzeniach maksymalną prędkość równą wartości najwolniejszego interfejsu.

Można też stworzyć zony tak by urządzenia końcowe z szybszym HBA nie miały dostępu do urządzeń posiadających wolniejsze HBA.

W innym przypadku mogą nastąpić problemy z transferem między urządzeniami.

W moim środowisku tworzenie zone nie było możliwe. Obecnie wszystkie hosty z kartami FC 4G i 8G są w jednym klastrze i muszą mieć dostęp do macierzy FC z int. 4G i 8G. Dlatego ostatecznie na wszystkich hostach prędkość interfejsów FC zostało ograniczone do 4G. Podczas dodatkowych testów udało się ustalić, że obniżenie prędkości interfejsów po stronie nowszych macierzy FC nie było wymagane. Obecnie po czterech – pięciu tygodniach od zamknięcia zgłoszenia całe środowisko działa stabilnie.

Monday, February 27, 2012

VMware– SCSI NMP error

Czasem zdarzają się sytuacje, w których przy stosunkowo małym ruchu występują spore opóźnienia lub problemy w dostępie do macierzy. Sama diagnostyka zazwyczaj zaczyna się od analizy wykresów dostępnych w vCenter lub sprawdzenia wyników esxtop na konkretnym hoście. Na podstawie zebranych danych często próbujemy przenieść cześć maszyn na inne LUNy czy optymalizować konfigurację kontrolerów dostępnych na określonych macierzach. Podczas procesu optymalizacji warto lub nawet trzeba przeglądnąć log vmkernel. W logu tym zapisywane są komunikaty scsci device NMP error, które mogą nam ułatwić analizę problemów występujących w naszym środowisku.

Jak analizować błędy NMP?

Każdy wpis dotyczący błędów NMP zawiera kilka istotnych elementów:




    1. Data i godzina wystąpienia błędu, tutaj warto pamiętać, że hosty (ESXi) korzystają z czasu UTC.


    2. Identyfikator problematycznego LUNu (naaID). W celu pozyskania dodatkowych informacji na temat określonego urządzenia możemy skorzystać z vClienta lub narzędzi CLI. Np. esxcli storage core path list -d <naaID> zwróci nam dokładniejsze informacje o LUNie o okreslonym naaID.


    3. Status code – ogólny identyfikator problemu określający, który komponent/urządzenie zwróciło błąd:




        • H – błąd po stronie hosta


        • D – błąd zwrócony przez host docelowy


        • P – błąd wygenerowany przez plugin NMP


      Kod 0x0 jest zwracany gdy nie zaobserwowano, żadnego błędu. Przykładowo H: 0x0 mówi nam, że po stronie hosta wszystko działa poprawnie. W zależności od problemów, możemy zaobserwować różne numery błędów:




      • 0x2 – nieudane wykonanie określonej komendy, więcej informacji znajdziemy analizując dodatkowy numer (4)


      • 0x8 – określone urządzenie jest zajęte i nie akceptuje komend SCSI.

      Więcej informacji na temat najczęściej występujących  statusów możemy znaleźć bezpośrednio na stronie vmware [KB1030381].


    4. Valid sense data: dodatkowe informacje na temat błędu zwróconego przez określone urządzenie. Przykładowo jeśli urządzenie docelowe zwróci nam status 0x2 oznaczający błędne wykonanie określonej komendy to Valid sense data pozwoli nam określić powód błędu.




      • Pierwszy numer w ciągu to Sense Key, którego opis możemy znaleźć na stronie  [t10.org]


      • pozostałe dwa numery to  Additional Sense Code/ ASC Qualifier. Dokładny ich opis można znaleźć na stronie [t10.org]. Przy czym postać 0xX 0xY zapisana jest w postaci X/Y

Przykładowa analiza
Na wyżej zamieszczonym zrzucie można zobaczyć, że na lunie o id naa.600cf….. wystąpił błąd o identyfikatorze H:0x0 D:0x2 P:0x0 – problem po stronie urządzenia docelowego. Status 0x2 – nie udało się poprawnie wykonać komendy po stronie macierzy. Dodatkowy kod 0x0 0x47 0x0   zgodnie z opisem na stronie [t10.org] wskazuje:




  • sense code 0x0 – brak jakiegoś specyficznego błędu, wymagane sprawdzenie dodatkowych pól


  • additinal sense code 0x47 / ACS 0x0 – 47/00 SCSI PARITY ERROR – w zależności od konfiguracji problem może być związany nie z samym kontrolerem lecz z kablami lub urządzeniami występującymi między hostem a macierzą.

Konkluzje

Tak, wiem, po co analizować tak głęboko logi i studiować dokumentacje? Przecież od tego jest wsparcie techniczne.

Primo – warto wiedzieć gdzie mamy zgłosić błąd (H: 0x0 D:0x2 P:0x0 – błąd po stronie macierzy, otwarcie zgłoszenia w na stronie VMware zakończy się odbiciem do producenta macierzy[: ) Zamiast marnować czas na odbijanie piłeczki, warto wiedzieć gdzie pisać w pierwszej kolejności.

Secundo – jeśli skończy się nam wsparcie lub proces rozwiązania zgłoszenia będzie zbyt długi, warto mieć podstawowe informacje na temat problemu. Będziemy wiedzieli kiedy konsultant gra na zwłokę, a może własnymi siłami uda się rozwiązać problem.

Tuesday, February 7, 2012

Vmware host busy/scsi parity error

Jest nowa infrastruktura SAN, w której Blade HP mają nowe karty HBA QMH2652. Wszystko fajnie, wreszcie dostęp do macierzy po 2x8GB. Niby miało być szybciej, niby wydajniej a w statystykach opóźnienie większe niż na macierzach iSCSI. Wymian gibików, kabli, switchy czy uaktualnienie firmware dalej nie pomaga. 

Jeśli jakimś cudem na sporej ilości serwerów, które korzystają z LUNów rozrzuconych po różnych macierzach, otrzymujecie w logu vmkernel powiadomienia H:0x02 D:0x0 P:0x0 lub H:0x0 D:0x47 P:0x0 to czasem jedynym rozwiązaniem może być ograniczenie przepustowości na danym porcie z 8Gb na 4Gb. A i tutaj warto pamiętać, że na kartach dwuportowych obniżenie prędkości może być konieczne tylko na jednym z portów. Swoja drogą na razie nie dotarłem do prawidłowego rozwiązania tego problemu, tak więc cdn…