Мне нужно добавить какое-то архивное \ промежуточное хранилище на сервер SLES 10. Требуется предоставить достаточно большие тома (примерно 9-20 ТБ каждый, всего около 60 ТБ), которые будут использоваться для хранения архивных данных (буквально, это библиотека), содержащих большие файлы изображений (по большей части 150 МБ Tiff). и большие архивы. Данные будут в подавляющем большинстве смещены в сторону ввода-вывода, определенно> 95% и, вероятно, более 99%.
Хранилище уже было приобретено - массив Dell MD3000 SAS в гирляндную цепочку с двумя MD1000, полностью заполненный дисками SATA 2 ТБ 7200 об / мин, всего 45 дисков. Стек массивов подключается с помощью двух двухпортовых внешних адаптеров SAS, т. Е. Существует 4 пути к стеку.
Я намерен сконфигурировать их как набор из 4 томов, расположенных в 4 группах RAID, с одним горячим резервом на каждый массив. Все группы будут RAID 6 с 7 или 14 дисками, и каждая группа RAID будет представлена как один LUN, использующий всю емкость этой группы. На стороне SLES они должны быть отформатированы как тома XFS.
У меня ограниченный опыт работы с SLES (и Linux в целом), и я ищу некоторые рекомендации по этому поводу, в частности:
Сервер - это Dell 2950 - я не проверял подробные спецификации, но вверху показывает коэффициент использования, колеблющийся не более низкими однозначными цифрами.
Я бы намного больше включился, чтобы купить больше дисков и RAID 10 на них.
У меня были ужасные проблемы с сотнями дисков FATA (SATA с оптоволоконным подключением) емкостью 1 ТБ, которые мы купили некоторое время назад, они стоят 1 тысячу фунтов стерлингов каждый, и я теряю 5% в месяц! По сути, они просто не предназначены для работы в режиме 24x7, и что у вас могут быть те же проблемы, поэтому я бы рекомендовал R10.
RAID6 - это шаг в правильном направлении, но если у вас есть возможность, я бы оставил хотя бы один диск в качестве горячего резерва - если диск умирает в любом месте вашего массива, он прыгнет и разобьется, пока он ждет, пока вы заменить вышедший из строя диск. По этому поводу убедитесь, что у вас есть как минимум 2 или 3 запасных диска, готовых к замене, а также убедитесь, что у вас есть все настройки предупреждений, чтобы вы знали, когда возникнет проблема 24x7.
Что касается производительности, ну, эти 2-гигабайтные диски не так уж и неудобны для диска 7.2k, а SAS может быть очень быстрым, поэтому я ожидаю, что 70 МБ / с для последовательных чтений, о которых вы упомянули, - очевидно, случайность и запись будут довольно низкими.
Извините, если я выгляжу отрицательно, я только что боролся с хранилищем в течение многих лет и могу спокойно спать только с корпоративными дисковыми системами - я просто потянул слишком много 48/72-часовых смен для исправления низкочастотного оборудования.
На моей предыдущей работе у нас была похожая проблема. Мы делали производство для планетариев, и каждый кадр был 64 мегапикселя. Множество больших изображений. Они будут обрабатываться для каждого кинотеатра в очень агрессивной операции чтения на кластере компьютеров.
Сервер в этом случае имел аналогичную настройку хранилища. Несколько внешних RAID-массивов с прямым подключением. Каждый из них находился в томах RAID6, доступных для хоста и добавленных в VG (группу томов) в LVM (диспетчер логических томов). Каждое шоу / постановка получит свой собственный LV (логический том) в формате XFS, который мы будем расширять вместе с проектом по мере необходимости.
Если ваши наборы данных довольно статичны или растут предсказуемым образом, как этот, то этот подход должен вам подойти. Но будьте осторожны, у этого подхода есть обратная сторона. В конечном итоге вам придется микроуправлять LV в вашем хранилище. Некоторые админы предпочитают этот способ, но другие постараются этого избежать. Но это позволяет увеличивать каждую файловую систему LV и XFS по мере роста набора данных. Сохраняйте ваши тома XFS как можно меньше, чтобы вы не застряли с fsck, на выполнение которого уйдут годы. И может действовать как средство защиты от повреждений в случае выхода файловой системы из строя.
Отказ от ответственности: если бы я настроил это сегодня, я бы использовал OpenSolaris и ZFS. В основном b / c, он позволяет избежать проблем с микроуправлением и является превосходным менеджером файловой системы / тома. Так что вы, возможно, захотите взглянуть и на это.