В моей группе в настоящее время есть два больших сервера хранения, на обоих NAS работает debian linux. Первый - это 24-дисковый (SATA) сервер «все в одном», которому несколько лет. У нас есть два аппаратных рейда с LVM поверх них. Второй сервер состоит из 64 дисков, разделенных на 4 корпуса, каждый из которых представляет собой аппаратный RAID 6, подключенный через внешний SAS. Мы используем XFS с LVM поверх этого, чтобы создать полезное хранилище 100 ТБ. Все это работает неплохо, но мы перерастаем эти системы. Создав два таких сервера и продолжая расти, мы хотим создать что-то, что обеспечит нам большую гибкость с точки зрения будущего роста, вариантов резервного копирования, которое лучше себя ведет при сбое диска (проверка более крупной файловой системы может занять день или больше) и может выдержать в сильно параллельной среде (представьте небольшой компьютерный кластер). У нас нет поддержки системного администрирования, поэтому мы администрируем все это сами (мы - лаборатория геномики).
Итак, мы ищем относительно недорогое решение для хранения данных с приемлемой производительностью, которое обеспечит будущий рост и гибкую конфигурацию (подумайте о ZFS с разными пулами, имеющими разные рабочие характеристики). Вероятно, мы находимся за пределами единого NAS. Мы думали о комбинации ZFS (например, на openindiana) или btrfs на сервер с запущенными поверх этого glusterfs, если мы сделаем это сами. Мы взвешиваем это против того, чтобы просто глотнуть пулю и инвестировать в решения для хранения данных Isilon или 3Par.
Любые предложения или опыт приветствуются.
Надеюсь, это немного поможет. Я старался, чтобы это не превратилось в целую стену текста. :)
Если вы можете и будете выделять фиксированное количество человеко-часов для кого-то, кто берет на себя роль администратора SAN и хочет наслаждаться безболезненной жизнью с ночным сном вместо ночной работы, тогда я бы пошел именно так.
SAN позволяет вам делать все, что ограничивает одно «хранилище» (например, подключать флеш-массив purestorage и большой монстр 3par sata к одному и тому же серверу), но вы также должны платить за это и поддерживать его в хорошем состоянии. время, если вы хотите использовать гибкость.
Amplidata
Плюсы: масштабируемость, дешевизна, продуманная концепция и выделенные слои кэша для чтения / записи. На самом деле это может быть лучшим вариантом для вас.
RisingTideOS
Их целевое программное обеспечение сейчас используется почти во всех Linux-хранилищах, и оно позволяет управлять немного лучше, чем обычные Linux / Gluster. (Imho) Возможно, стоит взглянуть на коммерческую версию.
Gluster / btrfs
ЗА: Масштабирование и «Кирпичи» дают вам уровень абстракции, который очень хорош для управления.
ПРОТИВ: Первая была для меня полной PITA. Он не был надежным, и сбои могли быть либо локальными для одного кирпича, либо выносить все. Теперь, когда RedHat под контролем, это может действительно превратиться во что-то работающее, и я даже встречал людей, которые жестяная банка приручите его, чтобы он работал годами. А второй пока что наполовину экспериментальный. Обычно FS требуется 3-4 года после того, как она «готова», пока она не будет проверена и станет надежной. Если вам важны данные, зачем вам вообще это рассматривать? Говоря об экспериментальном, коммерческая поддержка Ceph сейчас почти закончилась, но вам нужно придерживаться уровня «RBD», просто FS еще недостаточно хорошо протестирована. Я хочу прояснить, что в долгосрочной перспективе Ceph намного привлекательнее. :)
ZFS
Плюсы: Особенности, которые определенно забивают гвоздь в гроб с другими вещами. Эти функции хорошо спроектированы (подумайте о L2ARC), а сжатие / дедупликация - это весело. Иметь больше «кластеров хранения», что означает наличие небольших сбоев вместо одного большого консолидированного бум
Против: Хранение множества небольших программных коробок вместо реального хранилища. Необходимо интегрировать их и потратить $$$ часов, чтобы получить надежную настройку.
Маршрут XFS + LVM действительно является одним из лучших вариантов горизонтально масштабируемого решения для хранения данных на чистом Linux за последние несколько лет. Я рад, что ты уже там. Теперь, когда вам нужно больше расти, у вас есть еще несколько вариантов.
Как вы знаете, у крупных производителей оборудования есть NAS-головки для хранения данных. Это действительно дало бы вам возможность работать с одним поставщиком, чтобы все это произошло, и это работало бы очень хорошо. Это простые решения (по сравнению с DIY), и их ремонтопригодность ниже. Но стоят они довольно дорого. С одной стороны, у вас будет больше инженерных ресурсов для решения ваших основных проблем, чем проблем с инфраструктурой; с другой стороны, если вы похожи на большинство факультетов университетов, о которых я знаю, рабочая сила действительно дешевая по сравнению с оплатой наличными за вещи.
Идя по пути DIY, вы уже хорошо оцените доступные вам варианты DIY. ZFS / BTRFS - очевидный путь обновления с XFS + LVM для масштабируемого хранилища. Я бы держался подальше от BTRFS, пока он не был объявлен «стабильным» в основном ядре Linux, что должно произойти довольно скоро, когда несколько основных бесплатных дистрибутивов используют его в качестве файловой системы по умолчанию. Для ZFS я бы рекомендовал использовать базу BSD, а не OpenIndiana, просто потому, что она существует дольше и имеет исправления (больше).
Gluster был разработан для случая использования, который вы описываете здесь. Он может выполнять репликацию, а также представлять один виртуальный сервер с большим количеством подключенных хранилищ. Их Распределенные тома звучат именно то, что вы ищете, поскольку они распределяют файлы по всем серверам хранения на заявленном объеме. Вы можете продолжать добавлять дискретные серверы хранения, чтобы продолжать увеличивать видимый том. Единое пространство имен!
Проблема с Gluster заключается в том, что он работает лучше всего, когда ваши клиенты могут использовать Gluster Client для доступа к системе, а не параметры CIFS или NFS. Поскольку вы используете небольшой кластер-вычислительный кластер, вы можете просто использовать клиент GlusterFS.
Вы здесь на правильном пути.
Насколько я понимаю, вы можете использовать решение SAN на основе Linux SCST + FibreChannel или infiniband, что я создаю прямо сейчас. В качестве основы для LUN вы можете использовать LVM поверх аппаратных RAID-массивов и заботиться о снимках / репликации (например, DRBD) ниже уровня файловой системы. Как файловая система, я не знаю ни одного хорошего решения для параллелизма, поскольку я помещаю ESXi поверх узлов, поэтому хранилища данных управляются параллельной FS ESX. Я думаю, что GFS2 может работать с этой средой, но я не уверен на 100%, так как вам следует проверить свои точные требования. В любом случае, если у вас есть надежная SAN под вашими узлами, это довольно легко сделать.