Назад | Перейти на главную страницу

Как я могу создать в Linux файловый сервер, который мы можем постепенно увеличивать?

Я работаю в научной лаборатории с ограниченным бюджетом и постоянно растущей потребностью в хранении. Год назад нам нужно было ~ 2-3 ТБ хранилища, сегодня нам нужно 13+ ТБ, которые заполняют наш текущий сервер (linux, raid 6 с 9 дисками), и он будет только расти. Файлы огромные - 50 ГБ + каждый.

Я хочу построить сервер, который:

a) Может работать с дисками неравномерного размера, поэтому мы можем заменить старые диски на диски большего размера по мере их появления на рынке. б) Может обрабатывать добавления дисков (которые потенциально больше, чем любой другой диск) после создания начального «тома». В идеале я просто хочу вставить диск в отсек для горячей замены и сделать его частью тома. б) Имеет избыточность и может обрабатывать множественные отказы дисков. г) Быстрое "тискивание". В прошлый раз, когда наш текущий сервер сделал это, потребовалась целая вечность, чтобы восстановиться.

Могу ли я сделать (а) и (б) с RAID? Я знаю, что могу разделить raid-разделы одинакового размера с дисков разного размера, но я не хочу заниматься микроуправлением разделами с несколькими массивами raid. ZFS - вариант? (FreeBSD тоже подойдет.)

Честно говоря, производительность не является большой проблемой. Он будет хранить и предоставлять статический контент лишь горстке исследователей. Наша локальная сеть составляет 1 Гбит, а наша глобальная сеть - всего 100 Мбит.

Любые предложения приветствуются.

Я бы порекомендовал решения на основе ZFS, но со специально созданной ОС (NexentaStor), а не пытаться запустить дополнительные приложения в системе. Это дает вам возможность рассматривать ваше хранилище как устройство и устраняет зависимости приложений. Экспортируйте в свои системы Linux через NFS или iSCSI.

Остальные ваши требования полностью удовлетворяются решениями ZFS. У вас есть бюджет?

Я рекомендую обратиться к интегратору / партнеру, который поможет разработать надежную систему и решить любые проблемы с масштабированием / долговечностью. Скорее всего, они видели ситуацию, подобную вашей, или имели дело с аналогичными требованиями. Однако, если вы пойдете на это самостоятельно, сделайте свое Юридическая экспертиза и избегать ошибок других.

Хорошие места для начала:

http://www.zfsbuild.com/

http://hardforum.com/showthread.php?t=1573272

http://www.nex7.com/readme1st

Отделите потребности в хранилище от потребностей обработки. Вы можете приобрести сантехнику по относительно низким ценам (HP P2000 дешевы, если вы не покупаете их полностью заполненными, и вы можете расширить их до 6 полок по 3 ТБ дисков для 36x6 ТБ хранилища в формате RAW), и если вы придерживаетесь iSCSI вы можете избежать дорогостоящих HBA и оптоволокна. iSCSI также позволит вам продолжать использовать сервер, который вы в настоящее время используете в качестве файлового сервера, он просто позволяет вам подключать кучу дисков. Вы также можете посмотреть на более старые модели, такие как MSA 2000. У Dell также есть неплохие предложения. Затем подключите его к серверу с несколькими начальными дисками (2 для рейда 1, 3 для рейда 5 или рейда 1e, 4 для рейда 1 + 0 или рейда 6 в зависимости от ваших требований к хранилищу).

На сервере используйте LVM, чтобы сделать из них физический том, и создайте группу томов / логический том поверх этого. В будущем вы можете добавить дополнительные диски в шасси SAN и добавить их как новые физические тома, а затем расширить логический том. Затем, когда вы исчерпываете емкость дисковой полки SAN, вы просто добавляете еще одну полку с парой дисков и увеличиваете ее так же, как и первая полка. Мы используем это для многих наших систем хранения. Некоторое тщательное планирование может помочь вам избежать размещения данных для одного и того же логического тома на двух разных полках (в случае, если какой-то идиот решит, что они хотят споткнуться о кабель, соединяющий две полки san).

Что касается файловой системы, ext3, ZFS, ext4 поддерживают увеличение размера файловой системы на лету. Однако, если вы когда-либо беспокоитесь, вам нужно уменьшить его, наклонитесь к ext3. Это лучше документировано и поддерживается. Это простое решение, не требующее консультанта и позволяющее расширять ваше решение с помощью набора данных.

Вы действительно хотите удалить хранилище со своего сервера, если вам нужно так сильно его расширить.

Я думаю, что ewwhite прямо здесь, для чего-то такого большого, специализированного, коммерчески поддерживаемого устройства я бы выбрал.

В противном случае вы могли бы что-то накинуть вместе с Linux, используя md чтобы добавить пары зеркальных дисков (диски в паре должны быть одного размера, но могут отличаться от старых дисков), затем используя LVM для включения этой новой пары в вашу файловую систему путем переноса логических томов со старых физических томов и / или увеличения их на новый физический том. Избыточность будет проблемой (вы можете потерять половину дисков, но только если они право половина), но у вас будет гораздо больше гибкости при добавлении новых дисков и удалении старых.

... только убедитесь, что у вас есть резервные копии.

Следует учитывать, что ZFS вообще не поддерживает удаление файлов vdev. Это означает, что если вы неосознанно расширяете свой массив или решаете переключиться, например, с RAID6 на RAID10, вам не повезло. Если структура вашего диска исправлена ​​и вы обновляете каждый диск в vdev (например, оба диска в зеркале), я согласен, что ZFS, вероятно, является хорошим решением.

BTRFS поддерживает удаление устройств для своего эквивалента RAID10. За последние пару лет он также стал намного стабильнее.

Если вы хотите рассмотреть Windows, Windows Места для хранения на самом деле это довольно хорошее решение для того, чтобы добавить кучу разнородных дисков на сервер с избыточностью и заставить их хорошо работать.