В ближайшей перспективе предполагается закупить хранилку IBM DS3524, т.е. будет 4 полки по 24 диска.
Требуется получить большую производительность и большой объем пространства. Диски будут 2,5" 10к по 600ГБ(полезный объем 558Гб). Харнилка будет работать в качестве файлового сервера (linux + samba)Особенности этой хранилки:
- она не позволяет создать raid 6 более, чем из 30 дисков
- она не может объединять рейды в логические диски (агрегаты)Отсюда проблемы:
- Объем массива ~15ТБ из 30 дисков маловат
- 30 дисков не дадут нужного кол-ва iopsТ.е. задача объеденить эти мелкие массивы (их объем и производительность).
С ходу пришло в голову такое решение:
Из каждой 24х дисковой полки создается raid 6, т.е. получается 4 массива по 24 диска (ну или по 23, если оставить по одному запасному диску на полку).
Эти 4 массива на уровне ОС объединяются в raid 0 с помощью mdadm. Получаю раздел ~50TB, плюс нужную производительность.
Работать это будет, я тестировал, была возможность покрутить DS3524 с двумя полками, в которых было 36 дисков, я создал два массива raid 6 по 18 дисков и объединил в нулевой с помощью mdadm, производительность реально выросла в два раза, т.е. все работает.Вопросы:
1) Насколько надежна такая схема с mdadm ? Какие могут быть проблемы? На виртуалке тестировал, отключал отдельные диски из 0-ого рейда, рейд не развалился, подключаешь - все цело и т.д. Но всего учесть не мог, в чем могут быть проблемы и стоит ли такое реализовывать?2) Какую ФС лучше использовать на таких больших разделах? XFS, JFS или EXT4 ? Планирую использовать XFS. На предыдущем проекте на 20ТБ разделе использовал JFS.
Если в одной рейд-группе(raid5, raid6) много дисков - сильно уменьшится скорость на запись и ребилд.Я бы сделал так:
В каждой полке - два raid6 по 11 винтов объединённые в страйпинг(raid0), + 2винта для hotspare. Итого 24 винта.
Таким образом разбить все 4 полки.
Это на уровне железа.На уровне ОС полученные 4 раздела объединить в LVM-группу(я бы на этом и остановился).Либо уже средствами mdadm собрать эти 4 раздела в страйп.
> Если в одной рейд-группе(raid5, raid6) много дисков - сильно уменьшится скорость на
> запись и ребилд.У меня более 98% операций - чтение
> Я бы сделал так:
> В каждой полке - два raid6 по 11 винтов объединённые в страйпинг(raid0),
> + 2винта для hotspare. Итого 24 винта.
> Таким образом разбить все 4 полки.Два рейда по 11 витов объеденить в страйпинг железкой в смысле? Так она этого не умеет.
Да и по 11 дисков дробить слишком накладно, из каждого массива всего по 9 дисков под данные остается.
1) Используется mdadm на "боевом" серваке без проблем уже года 4. Перед установкой в стойку делал всякие пакости типа вынимание дисков на лету, замена на другие, внезапные перезагрузки во время ребилда и т.п. - mdadm работал безукоризненно.2) XFS и Ext4 усиленно допиливают в данный момент в плане производительности. К примеру почитайте первые два пункта из http://kernelnewbies.org/LinuxChanges . Лично я предпочитаю Ext4 :)
> 2) XFS и Ext4 усиленно допиливают в данный момент в плане производительности.
> К примеру почитайте первые два пункта из http://kernelnewbies.org/LinuxChanges . Лично
> я предпочитаю Ext4 :)Ну это все в ванильном ядре, а у меня будет дебиан сквизи с ядром 2.6.32
А дебиановский инсталятор по-умолчанию предлагает ext3, а не ext4, что как бы намекает, ведь дебиановцы к стабильности очень серьезно относятся.
Или собирать руками последнее ядро?
> Ну это все в ванильном ядре, а у меня будет дебиан сквизи
> с ядром 2.6.32
> А дебиановский инсталятор по-умолчанию предлагает ext3, а не ext4, что как бы
> намекает, ведь дебиановцы к стабильности очень серьезно относятся.
> Или собирать руками последнее ядро?Нет, на стабильность в дебиане ext4 и xfs нареканий нет. Я сам буду использую/буду использовать debian :)
Просто я так понял что будет достаточно сильная нагрузка при больших объёмах данных - т.е. думается будет нужна довольно большая оптимизация.
> Просто я так понял что будет достаточно сильная нагрузка при больших объёмах
> данных - т.е. думается будет нужна довольно большая оптимизация.Для современных процессоров - это не нагрузка, так что проблем не будет.
>(linux + samba)почему самба, а не какой-нибудь kernel-mode nfs (хранилище я так понимаю экспортироваться будет через SAS) ?
а iops-сы вам почему критичны - файлы БД или бэкапы ? возможно в производительности
просядете как раз на самбе (если не кластер), а не на хранилище - сервер соответствующий нужен.с ext4 имхо лучше ядра >=2.6.36 брать - у вас все равно не RHEL/SLES с их заморочками внутри релизов. 37 ветка очень неплоха, но опять же имхо лучше немного подождать до 38 (как раз допилят до стабильности нужные вещи). вообще для стабильного и предсказуемого отклика zfs больше подойдет (при грамотной настройке), но раз уже вы ос выбрали...
p.s. если не секрет, где вы такие объемы юзаете - хранилище в госструктуре ?
> почему самба, а не какой-нибудь kernel-mode nfsДа можно и nfs, чем он принципиально лучше будет-то?
> (хранилище я так понимаю экспортироваться будет через SAS) ?
Да, через сас
> а iops-сы вам почему критичны - файлы БД или бэкапы ?
Большое кол-во клиентов работает с большим кол-ом мелких файлов + бекап параллельно
>возможно > в производительности просядете как раз на самбе (если не кластер), а не на хранилище - сервер соответствующий нужен.
Не должно просесть, будет просядать на самбе - будем использовать NFS
> с ext4 имхо лучше ядра >=2.6.36 брать - у вас все равно
> не RHEL/SLES с их заморочками внутри релизов. 37 ветка очень неплоха,
> но опять же имхо лучше немного подождать до 38 (как раз
> допилят до стабильности нужные вещи).Ну эту хранилку запустим только весной, поэтому 2.6.38 успеет выйти, думаю.
Что же делать, буду собирать руками ядро для дебиана.> вообще для стабильного и предсказуемого отклика
> zfs больше подойдет (при грамотной настройке), но раз уже вы ос
> выбрали...ZFS - это солярис, опен умер, платный не вижу смысла покупать, да и не уверен, что оно работать будет нормально с этой хранилкой.
А во freebsd ZFS пока сырой, да и отстает от основной ветки.> p.s. если не секрет, где вы такие объемы юзаете - хранилище в
> госструктуре ?На самом деле надо будет две хранилки по 50ТБ, т.е. в сумме 100ТБ, плюс еще 40ТБ(2 по 20) уже есть, всего 140ТБ :)))
Контора не секретная: inlayfilm.ru