Два инфортренда на одном контроллере. Проблема.

Поломалось, посыпалось, не работает...

Модераторы: Trinity admin`s, Free-lance moderator`s

Ответить
Данила Ш.
Junior member
Сообщения: 17
Зарегистрирован: 02 май 2007, 08:38
Откуда: Екатеринбург
Контактная информация:

Два инфортренда на одном контроллере. Проблема.

Сообщение Данила Ш. » 02 май 2007, 12:07

Доброго времени суток.

У меня есть Infortrend A16U-G2421 (LUN 6.3 терабайта, raid5+spare, файловая система ext3). Подключен он через LSI 20320-R (отключен raid, на счет модели в последнее время предываю в сомнениях, чип LSI53C1030). Работает в качестве файлового архива, в день раздает 400-500 гигабайт, полгода работы в режиме 24x7, полет отличный.

ОС - Linux Debian, ядро актуальное.

Место закончилось и был приобретен еще один аналогичный Infortrend (теперь, понятное дело, A16U-G2421-1).

Устанавливаем в стойку, подключаем к первому массиву (последовательно по SCSI), настраиваем, инициализируем, mkfs. Все увиделось и заработало. Почти.

При одновременно работающих массивах при попытке записи некоторого объема данных (3-5 гигабайт непрерывно) на любой из них этот массив перемонтировался в r/o и сыпал в dmesg ошибками типа

Код: Выделить всё

target0:0:0: FAST-160 WIDE SCSI 320.0 MB/s DT IU QAS PCOMP (6.25 ns, offset 127)
 target0:0:1: Beginning Domain Validation
EXT3-fs error (device sda) in ext3_new_blocks: Journal has aborted
 target0:0:1: Ending Domain Validation
 target0:0:1: FAST-160 WIDE SCSI 320.0 MB/s DT IU QAS PCOMP (6.25 ns, offset 127)
__journal_remove_journal_head: freeing b_frozen_data
ext3_abort called.
EXT3-fs error (device sda): ext3_remount:
Abort forced by user
ext3_abort called.
EXT3-fs error (device sda): ext3_remount: Abort forced by user
и дальше

Код: Выделить всё

sd 0:0:0:0: SCSI error: return code = 0x000b0000
end_request: I/O error, dev sda, sector 8366493248
Buffer I/O error on device sda, logical block 1045811656
lost page write due to I/O error on sda
Buffer I/O error on device sda, logical block 1045811657
lost page write due to I/O error on sda
Buffer I/O error on device sda, logical block 1045811658
lost page write due to I/O error on sda
....
При этом, если отключить новый массив - все снова работало замечтаельно.
Долго шаманили с бубном, но в итоге победили проблему заменой кабеля, соединяющего массивы. Полтора часа гоняли туда-сюда данные, все работало. Радостоно решили, что проблема устранена и приготовились открывать шампанское. Однако.

Через день стали переносить реальные данные и столкнулись с теми же граблями. На новый массив спокойно перенесли все необходимые файлы (порядка 3.5 терабайт), однако при записи на старый (пробовали варианты "с нового массива", "с другого носителя") порядка ста гигабайт (уже не пять!) получаем те же внешние симптомы - массив перемонтируется в r/o. В dmesg:

Код: Выделить всё

May 2 00:56:27 localhost kernel: mptbase: ioc0: IOCStatus(0x0043): SCSI Device Not There
May 2 00:56:27 localhost kernel: sd 1:0:0:0: SCSI error: return code = 0x00010000
May 2 00:56:27 localhost kernel: end_request: I/O error, dev sdb, sector 5663423392
....
sdb: rw=0, want=23122118584, limit=13667340288
attempt to access beyond end of device
sdb: rw=0, want=15805571280, limit=13667340288
attempt to access beyond end of device
sdb: rw=0, want=15805571280, limit=13667340288
attempt to access beyond end of device
sdb: rw=0, want=23122118584, limit=13667340288
attempt to access beyond end of device
sdb: rw=0, want=15805571280, limit=13667340288
attempt to access beyond end of device
sdb: rw=0, want=23122118584, limit=13667340288
attempt to access beyond end of device
sdb: rw=0, want=15805571280, limit=13667340288
attempt to access beyond end of device
sdb: rw=0, want=15805571280, limit=13667340288
attempt to access beyond end of device
Вариант с проблемами файловой системы мы отмели сразу - перед началом переноса данных отработал fsck.

Попробовали еще раз перенести данные:

Код: Выделить всё

mptscsih: ioc0: attempting task abort! (sc=ded80980)
sd 1:0:0:0:
 command: Read(16): 88 00 00 00 00 01 73 10 00 00 00 00 00 08 00 00
mptbase: Initiating ioc0 recovery
mptscsih: ioc0: task abort: SUCCESS (sc=ded80980)
EXT3-fs error (device sdb): ext3_new_block: Allocating block in system zone - blocks from 778174464, length 1
Aborting journal on device sdb.
А теперь, внимание, вопрос.
Что мне делать с этим зоопарком различных ошибок и как заставить все это хозяйство работать как следует?

Может быть кто-то уже сталкивался?

Данила Ш.
Junior member
Сообщения: 17
Зарегистрирован: 02 май 2007, 08:38
Откуда: Екатеринбург
Контактная информация:

Сообщение Данила Ш. » 02 май 2007, 12:08

Единственное что пока не пробовали - воткнуть еще один контроллер и "рассадить" массивы.

Но если честно - вариант так себе. По логике вещей оно ведь должно работать и на одном?

Аватара пользователя
Tert
Advanced member
Сообщения: 4233
Зарегистрирован: 19 янв 2003, 08:09
Откуда: Москва
Контактная информация:

Сообщение Tert » 02 май 2007, 18:54

Данила Ш.
По логике вещей оно ведь должно работать и на одном?
Может по логике и должно, но производители подобных дисковых массивов не рассчитывают на такие конфигурации. Два совершенно независимых массива лучше на одну шину не вешать.
Лучше, действительно купите второй LSI 20320 и подключите к нему новый Infortrend.

and3008
Заслуженный сетевик
Сообщения: 1109
Зарегистрирован: 03 янв 2004, 23:30
Откуда: Н.Новгород

Сообщение and3008 » 06 май 2007, 14:08

У Линукса на 32-х битных платформах имеется ограничение на объем одного блокового устройства. Точных данных не скажу, но по моему ограничение в районе 9 Тб. Уж не на эти грабли вы наступили?

Если наступили, то выхода два.
1. Купить 64-х битную систему и поставить 64-х битную ОС.
2. Купить второй контроллер. Используя LVM объединить емкости двух массивов в один большой кусок и уже его отформатировать в EXT3 и перенести на него данные.

Логи: sdb: rw=0, want=23122118584, limit=13667340288
attempt to access beyond end of device

говорят в пользу моей версии про граничение размера блокового уст-ва.

Данила Ш.
Junior member
Сообщения: 17
Зарегистрирован: 02 май 2007, 08:38
Откуда: Екатеринбург
Контактная информация:

Сообщение Данила Ш. » 08 май 2007, 11:52

and3008, но у меня ДВА независимых устройства.

Каждое по 6.3 терабайта.

Данила Ш.
Junior member
Сообщения: 17
Зарегистрирован: 02 май 2007, 08:38
Откуда: Екатеринбург
Контактная информация:

Сообщение Данила Ш. » 15 май 2007, 00:46

Не вдаваясь в подробности экспериментов:

Взяли у поставщика новый контроллер.
Подключили к новому контроллеру оба массива. Полет нормальный уже
неделю под ПОВЫШЕННОЙ нагрузкой (гоняется в тестовых целях).

Так что грабля, судя по всему, была именно в старом контроллере.

Для информации:
старый контроллер - что-то с ярлыком hp, на базе LSI20320-R, ревизия A
новый контроллер - что-то с ярлыком hp, на базе LSI20320, ревизия C, firmware с пометкой HP build

Так что виновата или старая ревизия, или рэйд-функции контроллера
(хотя и отключенные).

Ответить

Вернуться в «Массивы - Технические вопросы, решение проблем.»

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 21 гость