Проверка работоспособности на конфигурации сервера 40TB

У меня 40 лет работы в области вычислительной техники, но мне никогда не приходилось создавать сервер, похожий на этот, так что это может быть вопрос n00b.

У меня есть клиент, который собирается предложить музыкальные файлы со сверхвысокой четкостью для загрузки. В данном случае это означает, что FLAC-сжатые 24/192 кГц = ~ 10 ГБ / альбом. (Нет, я не хочу говорить о желательности продукта, просто о конфигурации сервера.) В каталоге будет около 3000 альбомов с версиями как со сверхвысоким, так и с низким разрешением (для их iPod, я полагаю), дающих о 35-40 ТБ или около того первичных данных.

Поскольку это очень специализированный продукт, размер рынка относительно невелик (представьте: люди, которые тратят на свои аудиосистемы более $ 20 000), что означает, что большую часть времени сервер будет простаивать на 100% (или близок к нему). У меня есть то, что кажется хорошим предложением Colocation от ColocationAmerica с подключением 1 Гбит / с и пропускной способностью около 20 долларов США / ТБ, так что теперь мне просто нужно создать коробку для доставки товаров.

Вариант использования доступа к данным - однократная запись / многократное чтение, поэтому я подумываю только об использовании программного RAID 1 для пар дисков. Это позволило бы мне (я думаю ) перенастроить запасные диски на неисправные на лету, что позволило бы начать восстановление второго диска до того, как некоторые системные администраторы заметят красный свет в системе (они свободно меняются). Было бы здорово, если бы я мог заставить большинство приводов переходить в спящий режим / замедлять работу, если они не нужны, что будет большую часть времени для большинства накопителей.

Мне не нужно много вычислительных мощностей - эта штука просто выталкивает жирные объекты в трубу - и поэтому процессор / материнская плата могут быть довольно скромными, если они могут поддерживать такое количество дисков.

В настоящее время я рассматриваю следующую конфигурацию:

Chasis: Supermicro CSE-847E26-RJBOD1
Drives: 30 4TB SAS drives (Seagate ST4000NM0023 ?)
MB: SUPERMICRO MBD-X10SAE-O w/ 8GB
CPU: Xeon E3-1220V3 3.1GHz LGA 1150 80W Quad-Core Server

Итак, я иду в правильном направлении, или это полностью n00b / динозавр способ решения проблемы?

Обновите, чтобы уточнить пару моментов:

1. У меня нет опыта работы с ZFS, так как последний принадлежавший мне продукт Sun был в конце 80-х. Я сделаю немного RTFMing, чтобы увидеть, если он чувствует себя хорошо.
2. Мне действительно не нужна файловая система, чтобы делать что-то впечатляющее, поскольку имена файлов будут простыми UUID, а объекты будут сбалансированы по всем дискам (что-то вроде большой системы кэширования). Так что я действительно думал о них как о 40 отдельных файловых системах, и это заставляло звучать RAID 1 примерно так (но я допускаю невежество здесь).
3. Поскольку наши текущие ожидания состоят в том, что мы вряд ли будем загружать более пары дюжин файлов одновременно, и в большинстве случаев будет ровно один человек, загружающий любой данный файл, я не знаю, нужны ли нам тонны памяти для буферов. Может быть, 8 ГБ немного легковесны, но я не думаю, что 128 ГБ будут делать что-то большее, чем потреблять энергию.
4. Есть 2 отдельных машин , не упомянутые здесь: их текущий интернет - магазин, и почти полностью разъединено Download Master , который обрабатывает все аутентификации, новый продукт употребляет управление, обеспечение соблюдение политики ( в конце концов, это является площадкой в RIAA в), создании эфемерной URL (и , возможно , передача загрузок более чем одному из этих животных, если трафик превышает наши ожидания), отслеживание использования и генерация отчетов. Это означает, что эта машина может быть построена с использованием песчанок на Quaaludes.

ZFS? Где выгода?

Хорошо, я пробираюсь через несколько руководств по ZFS, часто задаваемые вопросы и т. Д. Простите за глупое звучание, но я действительно пытаюсь понять преимущество использования ZFS по сравнению с моим допотопным представлением о N парах RAID1. На этой странице Best Practices (с 2006 года) они даже предлагают не делать ZFS с 48 устройствами, а с 24 зеркалами с двумя устройствами - звучит как то, о чем я говорил. На других страницах указано количество устройств, к которым необходимо получить доступ для доставки 1 (одного) блока ZFS. Также, пожалуйста, помните, что при 10 ГБ на объект и 80% использования диска я храню в общей сложности 320 файлов на диск 4 ТБ . Мое время восстановления с N RAID 1s для любого данного отказа диска составляет 4 ТБ записи с одного устройства на другое.Как ZFS делает это лучше?

Я признаю, что был динозавром, но диск дешевый, RAID 1, насколько я понимаю, мои потребности в управлении файлами тривиальны, а ZFS в Linux (моя любимая ОС) все еще довольно молода. Может быть, я слишком консервативен, но когда я смотрю на производственную систему, я так и катаюсь.

Я благодарю всех вас за ваши комментарии, которые заставили меня задуматься над этим. Я до сих пор не совсем решил, и мне, возможно, придется вернуться и задать еще несколько вопросов.

Исходя из описания вашей проблемы, ваша проблема - не столько сервер, сколько хранилище.
Вам нужна надежная и надежная файловая система, такая как ZFS, которая хорошо справляется с большими объемами хранилища и имеет встроенные возможности управления, чтобы упростить управление этим концом системы.

Как было упомянуто в комментариях, я бы выбрал ZFS для пула хранения (вероятно, во FreeBSD, потому что я больше всего знаком с этой операционной системой и потому, что у нее длинный, проверенный послужной список стабильной производительности с ZFS - мой второй выбор ОС будет Illumos , опять же из-за хорошо протестированной поддержки ZFS).

Что касается обслуживания файлов, я согласен - вам не нужно много аппаратного обеспечения, чтобы просто вытолкнуть данные из сетевого порта. Ваш основной драйвер для CPU / RAM будет соответствовать требованиям файловой системы (ZFS).
Общее правило: ZFS требуется 1 ГБ ОЗУ, плюс 1 ГБ на каждые 10 ТБ дискового пространства, которым она управляет (поэтому для 40 ТБ вам понадобится 5 ГБ ОЗУ для ZFS) - хотя отношения не совсем линейные (существует множество хорошие книги / учебные пособия / документы по ZFS, которые помогут вам составить оценку для вашей среды).
Обратите внимание, что добавление в ZFS наворотов, таких как дедупликация, потребует больше оперативной памяти.

Очевидно, что округляйте требования к ОЗУ в большей степени, чем вниз, и не скупитесь: если ваша математика говорит, что вам нужно 5 ГБ ОЗУ, не загружайте сервер 8 ГБ - увеличьте до 16 ГБ.

Затем вы можете либо запустить сервер прямо в хранилище (что означает, что вам потребуется еще больше оперативной памяти в этом хранилище для поддержки процессов сервера), либо вы можете удаленно смонтировать хранилище на «интерфейсных» серверах, чтобы на самом деле обслуживать запросы клиентов.
(Первый изначально дешевле, а второй - лучше в долгосрочной перспективе.)

Помимо этого совета, лучшие предложения, которые я могу вам дать, уже хорошо освещены в нашей серии вопросов « Планирование мощности» - в основном «Нагрузочный тест, Нагрузочный тест , Нагрузочный тест ».

Я использую ZFS для мультитабитного сервера, и он отлично зарекомендовал себя. Я использовал OpenIndiana для начала и теперь перешел на FreeNAS, поскольку он делает то, что мне нужно.

Я бы рекомендовал использовать карту LSI HBA (9211-8i - хорошая базовая карта) с расширителями SAS (корпуса SuperMicro можно заказать со встроенными расширителями SAS, основанными на наборах микросхем LSI). Микропрограмма LSI поддерживается в FreeNAS и FreeBSD. Проверьте наличие соответствующих версий (V16 подходит для FreeBSD V9.x).

Учитывая, что запись когда-то читала многие особенности вашей системы, я бы использовал топологию ZFS Z2 (избегайте RAID-5 и Z1 с дисками такого размера). Учитывая, что вы используете диски объемом 4 ТБ, время восстановления (восстановления) для большого одиночного массива vDev будет долгим, если пул заполнен. Чтобы избежать длительного перестроения, распределите vDevs по 6 или 10 группам для создания пула (рекомендации из документации FreeNAS). Пул, состоящий из трех дисков vDev с 6 дисками (предполагается, что диски объемом 4 ТБ), будет иметь полезную емкость ~ 48 ТБ и обеспечивает хороший уровень отказоустойчивости (помните, что вам все равно необходимо выполнять резервное копирование, поскольку RAID не заменяет резервные копии :)).

Чтобы ускорить работу с файлами, к которым часто обращаются, вы можете добавить пару SSD для L2ARC (вероятно, не требуется для вашего приложения, но они довольно дешевы для 120GB SSD).

И, как указано, использовать много оперативной памяти. 64 ГБ не слишком дорого, учитывая другое оборудование в системе. К сожалению, меньший XEON не может использовать более 32 ГБ. Вы можете попробовать это, но больше оперативной памяти было бы лучше в соответствии с литературой по ZFS (я использую XEON, о котором вы упомянули, с 32 ГБ оперативной памяти и массивом Z2 емкостью 24 ТБ, и он отлично работает).

Еще одним преимуществом ZFS является то, что вы можете настроить периодические снимки. Таким образом, вы можете легко восстановить предыдущие версии, а снимки очень экономят место. Кроме того, вы можете реплицировать любой снимок на другой набор данных (локальный или удаленный), и это можно сделать по SSH для безопасности.

Мне очень нравится надежность системы ZFS. Мне также нравится тот факт, что это аппаратно НЕЗАВИСИМО! Любая система, которая может видеть диски, может импортировать пул. Никаких зависимостей от прошивки и т. Д., Которые могут случиться с аппаратным рейдом (это не проблема с лучшими картами, но они дороже, чем карты HBA и нуждаются в драйверах и т. Д. - это было в прошлом)

Учитывая, что этот пост старше, у вас, вероятно, есть решение. Если так, то расскажите нам, что вы построили?

Ура,