форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Открытые системы на сервере (Файловые системы, диски)
Изначальное сообщение		[ Отслеживать ]

"вопрос по mdadm и ФС для больших разделов"	+/–
Сообщение от metallic (ok) on 12-Янв-11, 18:39
В ближайшей перспективе предполагается закупить хранилку 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.
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "вопрос по mdadm и ФС для больших разделов"	+/–
Сообщение от zd3n (ok) on 12-Янв-11, 21:32
Если в одной рейд-группе(raid5, raid6) много дисков - сильно уменьшится скорость на запись и ребилд. Я бы сделал так: В каждой полке - два raid6 по 11 винтов объединённые в страйпинг(raid0), + 2винта для hotspare. Итого 24 винта. Таким образом разбить все 4 полки. Это на уровне железа. На уровне ОС полученные 4 раздела объединить в LVM-группу(я бы на этом и остановился).Либо уже средствами mdadm собрать эти 4 раздела в страйп.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	3. "вопрос по mdadm и ФС для больших разделов"	+/–
	Сообщение от metallic (ok) on 13-Янв-11, 10:56
	> Если в одной рейд-группе(raid5, raid6) много дисков - сильно уменьшится скорость на > запись и ребилд. У меня более 98% операций - чтение > Я бы сделал так: > В каждой полке - два raid6 по 11 винтов объединённые в страйпинг(raid0), > + 2винта для hotspare. Итого 24 винта. > Таким образом разбить все 4 полки. Два рейда по 11 витов объеденить в страйпинг железкой в смысле? Так она этого не умеет. Да и по 11 дисков дробить слишком накладно, из каждого массива всего по 9 дисков под данные остается.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

2. "вопрос по mdadm и ФС для больших разделов"	+/–
Сообщение от gfh1gfh1 (ok) on 13-Янв-11, 10:18
1) Используется mdadm на "боевом" серваке без проблем уже года 4. Перед установкой в стойку делал всякие пакости типа вынимание дисков на лету, замена на другие, внезапные перезагрузки во время ребилда и т.п. - mdadm работал безукоризненно. 2) XFS и Ext4 усиленно допиливают в данный момент в плане производительности. К примеру почитайте первые два пункта из http://kernelnewbies.org/LinuxChanges . Лично я предпочитаю Ext4 :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	4. "вопрос по mdadm и ФС для больших разделов"	+/–
	Сообщение от metallic (ok) on 13-Янв-11, 10:57
	> 2) XFS и Ext4 усиленно допиливают в данный момент в плане производительности. > К примеру почитайте первые два пункта из http://kernelnewbies.org/LinuxChanges . Лично > я предпочитаю Ext4 :) Ну это все в ванильном ядре, а у меня будет дебиан сквизи с ядром 2.6.32 А дебиановский инсталятор по-умолчанию предлагает ext3, а не ext4, что как бы намекает, ведь дебиановцы к стабильности очень серьезно относятся. Или собирать руками последнее ядро?
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	5. "вопрос по mdadm и ФС для больших разделов"	+/–
	Сообщение от gfh1gfh1 (ok) on 13-Янв-11, 20:01
	> Ну это все в ванильном ядре, а у меня будет дебиан сквизи > с ядром 2.6.32 > А дебиановский инсталятор по-умолчанию предлагает ext3, а не ext4, что как бы > намекает, ведь дебиановцы к стабильности очень серьезно относятся. > Или собирать руками последнее ядро? Нет, на стабильность в дебиане ext4 и xfs нареканий нет. Я сам буду использую/буду использовать debian :) Просто я так понял что будет достаточно сильная нагрузка при больших объёмах данных - т.е. думается будет нужна довольно большая оптимизация.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	7. "вопрос по mdadm и ФС для больших разделов"	+/–
	Сообщение от metallic (ok) on 17-Янв-11, 16:03
	> Просто я так понял что будет достаточно сильная нагрузка при больших объёмах > данных - т.е. думается будет нужна довольно большая оптимизация. Для современных процессоров - это не нагрузка, так что проблем не будет.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	6. "вопрос по mdadm и ФС для больших разделов"	+/–
	Сообщение от diego on 15-Янв-11, 15:29
	>(linux + samba) почему самба, а не какой-нибудь kernel-mode nfs (хранилище я так понимаю экспортироваться будет через SAS) ? а iops-сы вам почему критичны - файлы БД или бэкапы ? возможно в производительности просядете как раз на самбе (если не кластер), а не на хранилище - сервер соответствующий нужен. с ext4 имхо лучше ядра >=2.6.36 брать - у вас все равно не RHEL/SLES с их заморочками внутри релизов. 37 ветка очень неплоха, но опять же имхо лучше немного подождать до 38 (как раз допилят до стабильности нужные вещи). вообще для стабильного и предсказуемого отклика zfs больше подойдет (при грамотной настройке), но раз уже вы ос выбрали... p.s. если не секрет, где вы такие объемы юзаете - хранилище в госструктуре ?
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	8. "вопрос по mdadm и ФС для больших разделов"	+/–
	Сообщение от metallic (ok) on 17-Янв-11, 16:15
	> почему самба, а не какой-нибудь 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
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема