Mamy serwer Debian z 8-dyskowym kontrolerem RAID 3Ware 9650SE z 5 dyskową macierzą RAID6, działającą jako host maszyny wirtualnej, wszystkie Linux. Występują problemy i podejrzewam, że nie wykryto uszkodzonego dysku.
Mieliśmy teraz kilka awarii, w których zarówno gospodarz, jak i wszyscy goście twierdzą, że system IO został zablokowany na 120 sekund lub dłużej. Podejrzewaliśmy wadliwy kontroler RAID, ale zastąpiliśmy go identycznym z identycznym oprogramowaniem układowym, co go nie naprawiło. Nie sądziłem, że tak, ponieważ druga macierz RAID1 działała poprawnie.
Prawie tydzień temu (niedziela), kiedy to działało, automatyczna weryfikacja wynosiła 66%. Ostatniej nocy (piątek rano) było to 67%. Zarówno przed uruchomieniem, jak i po nim, i oba podczas problemów. Kiedy wyłączyłem weryfikację za pomocą tw_cli /c0/u0 stop verify, wszystko znów zaczęło reagować.
Podejrzewam, że utknął na usterce dysku na poziomie około 66%. Automatyczna weryfikacja rozpocznie się w sobotę:
# tw_cli /c0 show verify
/c0 basic verify weekly preferred start: Saturday, 12:00AM
i zwykle będzie długo robione do piątku. Zważywszy na to, że niedziela wynosiła 66%, a piątek 67%, to raczej nie jest przypadek.
„smartctl -a -d 3ware, 0 / dev / twa0” i „smartctl -t long” (długi autotest SMART) na wszystkich dyskach nie ujawniły żadnych błędów. Ani też nie tw_cli /c0 show alarms.
Podejrzewałem, że dysk jest uszkodzony w sposób trudny do wykrycia, ale wyciągnąłem każdy dysk z tablicy jeden po drugim, utworzyłem z niego „pojedynczą” tablicę i dd'ed pełen zer. Brak dysku pokazującego błędy.
Czy jakaś inna rada?
Edytować:
to jest układ:
# tw_cli /c0 show
Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy
------------------------------------------------------------------------------
u0 RAID-6 OK - - 256K 5587.9 RiW OFF
u1 SPARE OK - - - 1863.01 - OFF
u2 RAID-1 OK - - - 1862.63 RiW ON
VPort Status Unit Size Type Phy Encl-Slot Model
------------------------------------------------------------------------------
p0 OK u0 1.82 TB SATA 0 - ST32000542AS
p1 OK u0 1.82 TB SATA 1 - ST32000542AS
p2 OK u0 1.82 TB SATA 2 - ST32000542AS
p3 OK u0 1.82 TB SATA 3 - ST32000542AS
p4 OK u0 1.82 TB SATA 4 - ST32000542AS
p5 OK u1 1.82 TB SATA 5 - WDC WD2002FYPS-02W3
p6 OK u2 1.82 TB SATA 6 - WDC WD2002FYPS-02W3
p7 OK u2 1.82 TB SATA 7 - WDC WD2002FYPS-02W3
Name OnlineState BBUReady Status Volt Temp Hours LastCapTest
---------------------------------------------------------------------------
bbu On Yes OK OK OK 0 xx-xxx-xxxx
Dana jednostka to u0.
edycja2:
tw_cli / c0 show diag pokazuje coś interesującego (edit3: to nieszkodliwe, dowiedziałem się, że jest to spowodowane wywołaniem smartctl -a -d 3ware,X /dev/twa0gdzie X jest nieprawidłowym portem):
QueueAtaPassthrough() called with invalid TargetHandle: 0x17, portHandle: 0xFF
Legacy opcode=0xB1 error=0x10E
E=010E T=14:15:51 : Invalid operation for specified port
E=010E T=14:15:51 U=0 : Return error status to host
Error, Unit 23: Invalid operation for specified port
(EC:0x10e, SK=0x05, ASC=0x24, ASCQ=0x00, SEV=01, Type=0x70)
No additional sense data
Error, Unit 23: 0x10E OVERRIDDEN due to invalid sense buffer descriptor
sense buffer: len=0, address=0x414ca2c7c
Send AEN (code, time): 0031h, 06/21/2013 14:26:16
Synchronize host/controller time
(EC:0x31, SK=0x00, ASC=0x00, ASCQ=0x00, SEV=04, Type=0x71)
Dostaję ich mnóstwo. Nie mam jednak pojęcia, co to znaczy. Nie mogę nawet stwierdzić, która to jednostka lub port. (edit3: Teraz wiem, to nieszkodliwe).
Biorąc pod uwagę moje edit3, wracam do pierwszego. Nic nie wskazuje na uszkodzenie dysku, z wyjątkiem tego, że weryfikacja zawiesza się na 66% i powoduje zawieszenie się tablicy, co czasami zdarza się losowo. Chciałbym, żeby weryfikator znalazł błąd ...
Odpowiedzi:
2 rzeczy, które dotychczas nie zostały poruszone:
źródło
Przyczyną tego problemu może być błąd odczytu na jednym z dysków i blokowanie całej macierzy, dopóki nie uda mu się ponownie przydzielić sektora lub kontroler RAID uzna, że dysk nie działa i uruchamia go poza macierzą, oznaczając go jako „Zdegradowany” (zależy to wyłącznie od kontrolera). Może się to zdarzyć często, gdy dysk zaczyna umierać, ale nadal przechodzi SMART. Większość dysków konsumenckich będzie kontynuować próbę odczytu na zawsze.
Ten problem został rozwiązany w przypadku niektórych dysków przeznaczonych dla macierzy RAID za pomocą czegoś o nazwie Kontrola odzyskiwania po błędzie . WD nazywa ten TLER. Ze strony:
RAID-specific time-limited error recovery (TLER) - Pioneered by WD, this feature prevents drive fallout caused by the extended hard drive error-recovery processes common to desktop drives.Zasadniczo mówi dyskowi, że jeśli nie może odczytać sektora, poddaje się po x sekundach. Jest to świetne w macierzy RAID, ponieważ dane można odzyskać z innego dysku.
Z tego, co przeczytałem, ST32000542AS nie implementuje żadnej formy ERC, więc każda z nich może zablokować całą tablicę. WD2002FYPS faktycznie implementuje TLER WD, więc nie spowoduje tego problemu.
źródło
Aby się upewnić, jaka jest wersja oprogramowania układowego?
Wystąpił problem, który brzmi bardzo podobnie do tego, co opisujesz, gdy spełnione są następujące wymagania:
W tym czasie nie było dostępnej poprawki oprogramowania układowego, więc przeprowadziłem migrację z rozmiaru paska 256k na 64k, co również rozwiązało problem. Możesz spróbować obejść ten problem, ale z pewnością zajmie to kilka dni.
Później wypróbowałem nowe oprogramowanie (* 4.10.00.021, myślę, że miałem poprawkę) z 256k i działało jak urok. 4.10.00.027 to najnowsza wersja.
źródło
Miałem problemy z kontrolerem 3ware i dyskami Seagate. Występuje subtelna niezgodność oprogramowania wewnętrznego. Przełączyłem się na dyski Samsung, problem rozwiązany.
źródło