Хранилище для небольшого кластера

Внутри каждой полки Raid6 из 10 дисков + 2 hot-spare.

Только учти что это (4тб * 10) будет ребилдится пару суток, если винт отвалится.

А затем собрать mdadm Raid0 из 4х Raid6

Плохая идея. Почему - ты сам ответил. Полка - независимый элемент со своими БП и т.п. Поэтому:

Что случится с Raid0 если, например, одна из полок отключится/включится?

Развалится нафиг. Если ты берёшь такой риск - можно делать.

Я бы отказался от RAID6 в пользу RAID10 из каждой полки и использовал бы их отдельно (разные NFS шары в твоём случае). В наше время огромных винтов RAID6 имеет смысл ИМХО только для бэкапа или для SSD.

Либо, если очень хочется одну шару - сделать поверх ещё RAID10 из полок. Да, это снизит объём вчетверо в итоге, но даст отличную надёжность, скорость и быстрый ребилд в случае отказа диска. Либо, если IOPSы не важны - RAID6 поверх полок.

Внутри каждой полки Raid6 из 10 дисков + 2 hot-spare

если «HP MSA 2400 SAS LFF + 3 полки расширения» представлено как одно логическое устройство, то 8 hot-spare - это много.

По поводу разбиения хранилища у меня например сделано так: 43 диска в Fujitsu DX80 S2 в CE+DE. На них 6*(RAID6 из 7 HDD) + 1 Global Hot Spare

Вообще говоря лучше про разбиение скажет производитель. Задай вопрос в тех.поддержку

А затем собрать mdadm Raid0 из 4х Raid6.

Не стоит. Это может взять на себя и кластерная ФС, дав возможность добавлять новые логические диски.

Для начала определись:

• Что у тебя будет в качестве ФС.
• Сколько серверов будет подключено к DAS? Нужна ли балансировка между ними и резервирование.

Lustre - конечно та ещё зараза, но шустрая, ей бы не такое ограниченное количество поддерживаемых ОС. Выбирай такую ФС, что бы мог добавлять в неё новые логические диски.

Плохая идея.

Чойто? Можно взять по 2 диска с каждой полки и собрать 6d+2p, сколько их там получится, учитывая по одному hot-spare на полку. Да и с чего бы полке отвалиться самой по себе, в них же всё продублировано? Хотя, этож msa :)

Либо, если IOPSы не важны - RAID6 поверх полок.

Вот это точно не лучшая идея.

Только учти что это (4тб * 10) будет ребилдится пару суток, если винт отвалится.

Да, я уже переживал несколько ребилдов больших групп: несколько дней на нервах - то еще развлечение. Но что делать?

Развалится нафиг. Если ты берёшь такой риск - можно делать.

Да, наверное, я все-таки погорячился с Raid0.

(разные NFS шары в твоём случае)

Этого, как раз, хотелось бы избежать. Просто расклад такой, что пользователей немного (<10), проекты очень лабильные: может взорваться до 30-40 Тб, а потом снова усохнуть до 10 Тб и проектов неопределенное количество. Так что придумать разумную схему разделения ресурсов довольно сложно.

Raid10 или Raid6 из целых полок это конечно интересно, но потерять 50% емкости какая-то печальная перспектива.

Да, устройство одно и, возможно, с количеством hot-spare я погорячился. Но по одному global hot spare на полку точно надо иметь. К тому же, на таких толстых дисковых группах, как уже заметили, т.к. ребилд идет несколько дней, то вероятность двойных и даже тройных отказов совершенно ненулевая. Так что береженного известно кто бережет :)

Я бы с удовольствием навернул Lustre. У меня сейчас есть в эксплуатации инсталляция на 280 Tb, которую я потихоньку дотягиваю до 400 Тb. И не смотря на все сопутствующие сложности, она оставляет довольно приятное впечатление.

Вот только в данном случае будет только один сервер хранения (то есть MGS+MDS+OSS на одной физической машине) + там нет ни 10к дисков ни SSD для MGT/MDT, что уже существенно снижает профит от люстры. К тому же, придется ставить кастомное ядро на MDS и клиентов.

Чойто?

Ну, возможно сделать сильно по-всякому :) Тут ещё прикол в том, что если полки соединены не кольцом, а последовательно - то отвалившаяся полка угробит и все те, которые за ней висят по SAS шине.

ZFS + RAID-Z2 не думал сделать? Оно и перестраиваться будет гораздо быстрее на таких дисках (копируются только те блоки, которые в данный момент заняты, а не тупо все 4Тб). Для этого нужно будет отдать серверу все диски напрямую, без RAID-а полки. Только дедупликацию не используй, на таких объёмах нужно пару ТБ оперативки для её нормальной работы)) Но и без дедупликации - тоже памяти неплохо бы побольше (для кеширования метаданных ФС) Вполне рабочее, стабильное решение.

А почему не RAID50 10 страйп-групп по 4 диска с 4 разных полок в страйп-группе? Такую конфигурацию может наверное собрать сама головная полка, без всяких заморочек на хостах. Переживает пропажу одной полки целиком, кроме головной, конечно.

Да, устройство одно

Тогда нет смысла привязываться к полкам

вероятность двойных и даже тройных отказов совершенно ненулевая.

Согласен, у самого были дважды выходы 2 ЖД из RAID в течении недели.

К тому же, на таких толстых дисковых группах,

Уменьшай размер группы. Только вот как разделить 48 ещё тот вопрос. 2 в global hot spare, остальные, например:

• 4*(7 RAID6) + 3*(6 RAID6) , итого -9 на резерв.
• 5*(8 RAID6) + 1*(6 RAID6) , итого -8 на резерв.
• 5*(8 RAID6) + 1*(6 RAID1+0), тут доп.лог. диск для чего-нибудь
• ...

в данном случае будет только один сервер хранения

Посмотри на GlustreFS или что там ещё есть.

Потому что пятый рэйд на 4тб сата дисках - это конфигурация самоубийцы.

соединены не кольцом, а последовательно

Это ведь одно и то же, к тому же уже давно отошли от петли.

то отвалившаяся полка угробит и все те, которые за ней висят по SAS шине.

Не, даже с fc-al такого не произойдёт ибо по два enc на полку.

Ты не в ту степь лезешь. У автора одна полка с двумя мозгами, к которой по SAS каскадом подключены тупые полки-JBODы с дисками. КАСКАДОМ, Карл! Первая полка в каскаде по какой-либо причине отключится - остальные за ней тоже пропадут.

Вот по этому и нет смысла привязываться к полкам вообще. Рассматривать надо всю конструкцию как один узел с 48 HDD. Выход из строя «полки» рассматривать как выход из строя этого ОДНОГО узла, и заботиться о простом способе замены вышедших из строя HDD.

Всё же полки - это отдельные устройства, с отдельными БП и отдельным бэкплейном с SAS-экспандерами. Было бы неразумно не учитывать их возможный отказ в случае чего.

Да, я согласен что это маловероятно при грамотной архитектуре (два БП в разные ИБП включены, подключены к SAS оба бэкплейна и т.п.), но всё же это не одно и то же что и единственное устройство.

Что-то мне подсказывает, что стоимость учёта возможности выхода из строя одной полки в данном сценарии использования будет намного дороже стоимости хранящихся данных промежуточных расчётов.

Расскажи хоть по подробнее о самом проекте, сколько серверов, сеть, ОСи, а то заинтриговал, а я сам сейчас думаю как перенастроить свой HPC-кластер с исправлением наделанных интегратором косяков в конфигурации.

КАСКАДОМ, Карл!

Да хоть крестиком, если в голове два контроллера, то и полки подключаются двумя путями через одну полку и ничего им не будет, по крайней мере у нормальных производителей. Хотя, не берусь утверждать это про хапе и тем-более msa(чёт не найти мне схему соединения на них).

http://h50146.www5.hp.com/lib/products/storage/manual/array/729691-001.pdf страница 13

Вроде петелькой эдакой подключаются всё же, вылет одной полки остальные не угробит.

Ну вот, даже в таком шлаке(msa) об этом подумали :)

http://www8.hp.com/h20195/v2/GetPDF.aspx/4AA4-6892ENW.pdf

Ага, уже тоже увидел этот документ. Уже лучше. У меня пока просто даже не было возможности физически осмотреть инсталляцию.

Проблема в том, что это чужая площадка, куда я имею очень ограниченный доступ и где пользователи в состоянии легкой войны с местными IT.

Соответственно любые спецификации (сколько узлов, что куда подключено и прочее) достаются из них с огромным трудом.

Про этот проект сложно рассказывать (подробности в предыдущем посте). А про свою основную площадку запросто:

• 35 вычислительных узлов: 48Гб-1Тб памяти, 24-80 ядер (с HT)
• 6 серверов хранения: Lustre (4 OSS + 2 MDS (один cold резерв)), 280 Tб
• Еще ~60 Tb nfs шар и, приблизительно, столько же в разных резервах
• 12 дисковых полок Maxtronic (24 диска в каждой, диски 2Tb и 3Tb, FC и SAS)
• В силу специфики, MPI задач, фактически, нет. Поэтому интерконнект всего 1Gb.
• Сервера хранения подключены по 8Gb FC.
• Scientific Linux 6.6

Это если вкратце.

Наследства от интегратора тоже хватает (я пришел в это проект год назад, а самому кластеру уже 3 года). Включая такие прелести, как все 3 блока питания дисковой полки воткнутые в один(!) сетевой фильтр. Плюс на нем не самым лучшим образом сказалось эволюционное и, порой, немного хаотичное развитие (а что поделать, т.к. МГУ это гос. учреждение, то движение денег в нем непредсказуемое).

Сетевой фильтр^W^W блок розеток.

А выяснилось это ровно в момент передачи мне хозяйства, когда сгорел один из таких блоков (они ещё, как назло, длинные, по 10 гнезд, если я правильно помню). В итоге несколько полок и один из 2х шлюзовых серверов ушли в даун. Каждая такая «пасхалка» добавляет несколько седых волос.

Бугагец у вас интеграторы :D