Добавление 60 ТБ хранилища на сервер SLES 10
Я должен добавить некоторое архивное / промежуточное хранилище на сервер SLES 10. Требуется представить достаточно большие тома (каждый по 9-20 ТБ, около 60 ТБ или около того), которые будут использоваться для хранения архивных данных (буквально, для библиотеки), содержащих большие файлы изображений (по большей части 150Meg Tiff) и большие тарболы. Данные будут в подавляющем большинстве смещены для чтения IO, конечно,>95% и, вероятно, более 99%.
Хранилище уже куплено - массив массивов Dell MD3000 SAS, соединенный с 2 MD1000, полностью заполнен 2 ТБ дисками SATA 7200 об / мин, всего 45 дисков. Стек массивов подключается с помощью двух двухпортовых внешних адаптеров SAS, т. Е. Имеется 4 пути к стеку.
Я намерен настроить их как набор из 4 томов, расположенных в 4 группах RAID, с одним горячим резервом на массив. Все группы будут RAID 6 с 7 или 14 дисками, и каждая группа RAID будет представлена как один LUN с использованием всей емкости в этой группе. На стороне SLES они должны быть отформатированы как тома XFS.
У меня ограниченный опыт работы со SLES (и Linux в целом), и я ищу некоторые рекомендации по этому поводу, в частности:
- При настройке томов XFS такого размера в SLES 10 следует соблюдать особую осторожность, т. Е. Настройки по умолчанию будут нормальными с учетом профиля ввода-вывода?
- Каков наилучший способ инициализировать \ разделить \ отформатировать их? Я использовал Parted для установки метки диска и YAST Partition Manager (принимая все значения по умолчанию) для создания и форматирования тома XFS для моего начального теста.
- Как настроить многолучевое распространение? Когда я представляю начальный тестовый том, он отображается в виде четырех отдельных устройств (/dev/sdl,/dev/sdm,/dev/sdn и /dev/sdn). Что мне делать, чтобы работать с этим как с одним томом?
- In my initial testing I'm seeing transfer rates from an existing EMC Clariion SAN volume of around 30Meg/sec. This is a lot lower than I'd expect, even accounting for the RAID 6 write penalty I'd expected to see something in the ballpark of 70-100Meg/sec.
- How can I tell if everything is OK - where should I look for errors\warnings etc? The YAST Partition editor takes a very long time to launch for example and I'd like to understand why.
- Would you partition this differently and\or use a different filesystem and if so why?
The server is a Dell 2950 - I haven't checked the detailed specs but top shows utilization hovering in the low single digits at most.
2 ответа
На моей предыдущей работе у нас была похожая проблема. Мы занимались производством планетариев, и каждый кадр составлял 64 мегапикселя. Много больших изображений. Они будут обрабатываться для каждого театра в очень агрессивной операции чтения на кластере компьютеров.
Сервер в этом случае имел аналогичную настройку хранилища. Несколько внешних RAID-массивов с прямым подключением. Каждый из них находился в томах RAID6, доступных для хоста, и добавлялся в VG (группу томов) под LVM (менеджер логических томов). Каждое шоу / производство получало бы свой собственный LV (логический том), отформатированный XFS, который мы будем расширять с проектом по мере необходимости.
Если ваши наборы данных довольно статичны или растут предсказуемым образом, как этот, тогда этот подход должен работать хорошо для вас. Но будьте осторожны, у этого подхода есть обратная сторона. В конечном итоге вам придется микро-управлять LV на вашем хранилище. Некоторые администраторы предпочитают это таким образом, но другие пытаются избежать этого. Но это позволяет вам увеличивать каждую файловую систему LV и XFS по мере роста набора данных. Сохраняйте свои тома XFS как можно меньше, чтобы вы не застряли с fsck, на завершение которого уходят годы. И может действовать как контроль повреждений, если файловая система уйдет на юг.
Отказ от ответственности: если бы я настроил это сегодня, я бы использовал OpenSolaris и ZFS. Главным образом, он избегает проблем с микроуправлением и является превосходной файловой системой / менеджером томов. Так что вы можете посмотреть на это.
Я был бы гораздо больше включен, чтобы купить больше дисков и RAID 10 на них.
У меня были ужасные проблемы с сотнями дисков FATA (с волоконно-оптическим интерфейсом SATA) емкостью 1 ТБ, которые мы купили некоторое время назад, по 1 тыс. Фунтов стерлингов каждый, и я теряю 5% в месяц! По сути, они просто не предназначены для рабочего цикла 24x7, и поэтому у вас могут быть те же проблемы, поэтому я рекомендую R10.
RAID6 - это шаг в правильном направлении, но если у вас есть возможность, я бы оставил хотя бы один диск в качестве "горячего" резерва - если диск умирает где-нибудь на вашем массиве, он будет подпрыгивать и чередоваться, ожидая, пока вы заменить неисправный диск. В связи с этим убедитесь, что у вас есть как минимум 2 или 3 запасных диска, готовых к замене, а также убедитесь, что у вас есть все настройки оповещения, чтобы вы знали, когда возникает проблема 24x7.
Что касается производительности, то эти 2ГБ диски не такие громоздкие для дисков 7,2 КБ, а SAS может быть очень быстрым, поэтому я ожидаю, что вы упомянули последовательные операции чтения со скоростью 70 МБ / с - очевидно, что количество случайных операций и операций записи будет довольно низким.
Извините, если я выгляжу отрицательно, я только что боролся с хранилищем в течение многих лет и могу легко спать только с корпоративными дисковыми системами - я только что вытащил слишком много 48/72-часовых смен, фиксирующих более низкую передачу.