У нас есть сервер Debian с 8-дисковым RAID-контроллером 3Ware 9650SE, с 5-ти дисковым массивом RAID6, выступающим в роли хоста виртуальной машины, во всех системах Linux. Проблемы продолжают возникать, и я подозреваю, что необнаруженный сломанный диск.
У нас было несколько сбоев, когда хост и все гости говорили, что система ввода-вывода заблокирована на 120 или более секунд. Мы подозревали неисправный RAID-контроллер, но заменили его на идентичный с идентичной прошивкой, что не помогло. Я не думал, что так будет, потому что второй массив RAID1 продолжал работать должным образом.
Почти неделю назад (в воскресенье), когда это происходило, автоматическая проверка была на 66%. Прошлой ночью (утро пятницы) было 67%. Как до, так и после загрузки, и оба при возникновении проблем. Когда я выключил проверку tw_cli /c0/u0 stop verify, все снова стало отзывчивым.
Я подозреваю, что он застрял на диске около 66%. Автоматическая проверка начинается в субботу:
# tw_cli /c0 show verify
/c0 basic verify weekly preferred start: Saturday, 12:00AM
и, как правило, будет долго сделано к пятнице. Учитывая, что в воскресенье было 66%, а в пятницу 67%, вряд ли это совпадение.
'smartctl -a -d 3ware, 0 / dev / twa0' и 'smartctl -t long' (длинная самопроверка SMART) на всех дисках не выявили ошибок. Ни один не делает tw_cli /c0 show alarms.
Я подозревал, что диск сломан таким образом, что его трудно обнаружить, но я вынул каждый диск из массива один за другим, создал из него «одиночный» массив и dd'ed полон нулей. На диске нет ошибок.
Или любой другой совет?
Редактировать:
это макет:
# 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
Рассматриваемая единица измерения - u0.
edit2:
tw_cli / c0 show diag показывает что-то интересное (edit3: это безвредно, я обнаружил, что это вызвано вызовом, smartctl -a -d 3ware,X /dev/twa0где X - неверный порт):
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)
Я получаю тонны этих. Я понятия не имею, что это значит, хотя. Я даже не могу разобрать, какой это юнит или порт. (edit3: теперь я знаю, это безвредно).
Учитывая мой edit3, я вернулся на круги своя. Ничто не указывает на неисправность диска, за исключением того, что проверка зависает на 66% и приводит к зависанию массива, что также иногда происходит случайным образом. Я хотел бы, чтобы проверить нашел ошибку ...
Ответы:
2 вещи, которые не были подняты до сих пор:
источник
Эта проблема может быть связана с тем, что один из дисков обнаружил ошибку чтения и заблокировал весь массив, пока ему не удастся перераспределить сектор или контроллер RAID не решит, что диск не работает, и загрузит его из массива, пометив его как «Degraded» (это полностью зависит от контроллера). Это может часто случаться, если диск начинает умирать, но все еще проходит SMART. Большинство потребительских дисков будут продолжать попытки чтения навсегда.
Эта проблема решается на некоторых дисках, предназначенных для RAID, с помощью так называемого контроля восстановления после ошибок . WD называет это TLER. С сайта:
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.По сути, он сообщает диску, что если он не может прочитать сектор, он должен сдаться через x секунд. Это прекрасно в RAID, так как данные могут быть восстановлены с другого диска.
Из того, что я прочитал, ST32000542AS не реализует какую-либо форму ERC, поэтому любой из них может блокировать весь массив. WD2002FYPS фактически реализует TLER WD, поэтому они не будут вызывать эту проблему.
источник
Просто чтобы убедиться, какая у вас версия прошивки?
У меня возникла проблема, которая очень похожа на то, что вы описываете, когда были выполнены следующие требования:
В то время не было доступного исправления прошивки, поэтому я перешел с 256k на 64k, что также решило проблему. Вы можете попробовать как обходной путь, хотя, конечно, это займет несколько дней.
Позже я попробовал новую прошивку (* 4.10.00.021, думаю, исправил) с 256k и работал как шарм. 4.10.00.027 - последняя версия.
источник
Раньше у меня были проблемы с контроллером 3ware и дисками Seagate. Тонкая несовместимость прошивки. Я перешел на диски Samsung, проблема решена.
источник