У меня 40 лет опыта в вычислениях, но мне никогда не приходилось строить сервер, подобный этому, так что это может быть вопрос n00b.
У меня есть клиент, который предлагает для скачивания музыкальные файлы сверхвысокой четкости. В данном случае это означает, что сжатие в формате FLAC 24/192 кГц = ~ 10 ГБ / альбом. (Нет, я не хочу обсуждать желательность продукта, только конфигурацию сервера.) В каталоге будет около 3000 альбомов, с версиями как с ультра-высоким, так и с низким разрешением (для их iPod, я думаю), что даст около 35-40 ТБ первичных данных.
Поскольку это очень специализированный продукт, размер рынка относительно невелик (подумайте: люди, которые тратят более 20000 долларов на свои аудиосистемы), что означает, что большую часть времени сервер будет на 100% простаивать (или близок к этому). У меня есть то, что выглядит как хорошее предложение по размещению от 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
Итак, иду ли я в правильном направлении, или это полностью динозавровый подход к проблеме?
Обновите, чтобы прояснить пару моментов:
ZFS? В чем выгода?
Хорошо, я изо всех сил просматриваю несколько руководств по ZFS, часто задаваемые вопросы и т. Д. Простите меня за глупость, но я действительно пытаюсь понять преимущество об использовании ZFS поверх моего допотопного представления о N пар RAID1. На этом Лучшие практики страница (с 2006 г.), они даже предлагают не создание ZFS на 48 устройств, но 24 зеркала на 2 устройства - это похоже на то, о чем я говорил. На других страницах указано количество устройств, к которым необходимо получить доступ, чтобы доставить 1 (один) блок ZFS. Также помните, что при 10 ГБ на объект и при использовании диска 80% я храню в общей сложности 320 файлов. на диск 4 ТБ. Мое время восстановления с N RAID 1 для любого сбоя диска составляет 4 ТБ записи с одного устройства на другое. Как ZFS делает это лучше?
Я признаю себя динозавром, но диск дешевый, RAID 1 я понимаю, мои потребности в управлении файлами тривиальны, а ZFS в Linux (моя предпочтительная ОС) все еще молод. Возможно, я слишком консервативен, но когда я смотрю на производственную систему, я так и поступаю.
Я благодарю всех вас за ваши комментарии, которые заставили меня задуматься об этом. Я все еще не совсем решил, и, возможно, мне придется вернуться и задать еще несколько вопросов.
Судя по описанию вашей проблемы, ваша проблема не столько в сервере, сколько в хранилище.
Вам нужна надежная и надежная файловая система, например ZFS он разработан для того, чтобы хорошо справляться с большими объемами хранения, и имеет встроенные возможности управления, которые упрощают управление этой частью системы.
Как упоминалось в комментариях, я бы выбрал ZFS для пула хранения (вероятно, на FreeBSD, потому что я больше всего знаком с этой операционной системой и потому, что у нее есть длинный, проверенный опыт стабильной производительности с ZFS - мой второй выбор ОС будет Иллюмосопять же из-за хорошо протестированной поддержки ZFS).
Что касается обслуживания файлов, я согласен - вам не нужно много оборудования, чтобы просто выталкивать данные через сетевой порт. Ваш основной драйвер для ЦП / ОЗУ будет соответствовать потребностям файловой системы (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 будет долгим, если пул заполнен. Чтобы избежать длительного перестроения, расположите виртуальные машины группами по 6 или 10 для создания пула (рекомендации из документации FreeNAS). Пул, состоящий из трех виртуальных устройств vDev на 6 дисков (предполагается, что диски 4 ТБ) будет иметь полезную емкость ~ 48 ТБ и обеспечивает хороший уровень отказоустойчивости (помните, что вам все равно нужно создавать резервные копии, поскольку RAID не заменяет резервные копии :)).
Чтобы ускорить работу с часто используемыми файлами, вы можете добавить пару SSD для L2ARC (вероятно, не требуется для вашего приложения, но они довольно дешевы для SSD на 120 ГБ).
И, как уже говорилось, используйте много оперативной памяти. 64 ГБ не слишком дорого, учитывая другое оборудование в системе. К сожалению, меньший XEON не может использовать более 32 ГБ. Вы можете попробовать это, но, согласно литературе ZFS, было бы лучше, если бы больше оперативной памяти (я использую упомянутый вами XEON с оперативной памятью 32 ГБ и массивом Z2 емкостью 24 ТБ, и он отлично работает).
Еще одно преимущество ZFS в том, что вы можете создавать периодические снимки. Таким образом, вы можете легко восстановить предыдущие версии, а снимки будут занимать очень мало места. Кроме того, вы можете реплицировать любой снимок в другой набор данных (локальный или удаленный), и это можно сделать через SSH в целях безопасности.
Мне очень нравится надежность системы ZFS. Еще мне нравится тот факт, что он НЕЗАВИСИМО от оборудования !! Любая система, которая может видеть диски, может импортировать пул. Никаких зависимостей от прошивки и т. Д., Которые могут произойти с аппаратным рейдом (не проблема с лучшими картами, но они дороже, чем карты HBA, и нуждаются в драйверах и т. Д. - это было немного раньше).
Учитывая, что этот пост старше, у вас, вероятно, есть решение. Если да, не могли бы рассказать нам, что вы построили?
Привет,