У нас есть сервер 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.
Я подозревал, что диск сломан так, что его трудно обнаружить, но я извлекал каждый диск из массива один за другим, создавал из него «единственный» массив и заполнял его нулями. Ни один диск не показал ошибок.
Или какой-нибудь другой совет?
Редактировать:
это макет:
# 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, проблема решена.