150 ТБ и растет, но как расти?

В моей группе в настоящее время есть два больших сервера хранения, оба из которых работают под управлением Debian Linux. Первый - это универсальный 24-дисковый сервер (SATA), которому несколько лет. У нас есть два аппаратных RAIDS с LVM над ними. Второй сервер состоит из 64 дисков, разделенных на 4 корпуса, каждый из которых представляет собой аппаратный RAID 6, подключенный через внешний SAS. Мы используем XFS с LVM для этого, чтобы создать 100 ТБ полезного хранилища. Все это работает довольно хорошо, но мы перерастаем эти системы. Создав два таких сервера и продолжая расти, мы хотим создать что-то, что позволит нам быть более гибкими с точки зрения будущего роста, вариантов резервного копирования, которые будут лучше себя вести при сбое диска (проверка файловой системы большего размера может занять день или больше) и может выдержать в сильно параллельной среде (например, небольшой компьютерный кластер). У нас нет поддержки системного администрирования,

Итак, мы ищем относительно недорогое, приемлемое решение для хранения данных, которое обеспечит будущий рост и гибкую конфигурацию (представьте себе ZFS с разными пулами, имеющими разные рабочие характеристики). Вероятно, мы находимся за пределами одного NAS. Мы думали о комбинации ZFS (например, на openindiana) или btrfs на сервер с glusterfs, работающей поверх этого, если мы сделаем это сами. То, против чего мы взвесим, - это просто укусить пулю и инвестировать в решения для хранения Isilon или 3Par.

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

Надеюсь, это немного поможет. Я пытался не дать ему превратиться в полную стену текста. :)

3Par / Isilon

Если вы можете и будете посвящать фиксированное количество человеко-часов тому, кто берет на себя роль администратора SAN и хочет наслаждаться безболезненной жизнью с ночным сном вместо ночной работы, то я бы пошел именно так.

SAN позволяет вам делать все, что ограничивает вас единое «хранилище» (то есть подключать флеш-массив purestorage и большой 3par sata monster к одному и тому же серверу), но вы также должны платить за него и поддерживать его в хорошем состоянии. время, если вы хотите использовать гибкость.

альтернативы

Amplidata

Плюсы: масштабируемый, дешевый, разработанный с хорошей концепцией и выделенными слоями кэша чтения / записи. Это может быть лучше для вас.

RisingTideOS

Их целевое программное обеспечение сейчас используется почти во всех хранилищах Linux, и оно обеспечивает немного лучшее управление, чем обычные Linux / Gluster. (Imho) Коммерческая версия может стоить посмотреть.

Gluster / Btrfs

PRO: масштабирование и «кирпичи» дают вам слой абстракции, который очень хорош для управления.

CON: Первая была для меня полной PITA. Это не было надежно, и сбои могли быть либо локальными для одного кирпича, либо уничтожать все. Теперь, когда RedHat находится под контролем, он может фактически превратиться во что-то работающее, и я даже встречал людей, которые могут приручить его, чтобы он работал годами. И второй все еще полуэкспериментальный. Обычно ФС требуется 3-4 года после того, как она «сделана», пока она не будет доказана и надежна. Если вы заботитесь о данных, почему бы вам никогда не рассмотреть это? Говоря об эксперименте, коммерческая поддержка Ceph уже почти отсутствует, но вам нужно придерживаться уровня «RBD», FS пока еще недостаточно хорошо протестирован. Я хочу прояснить, хотя, что Ceph намного более привлекательный в конечном счете. :)

ZFS

Pro: Особенности, которые определенно помещают гвоздь в гроб другого материала. Эти функции хорошо разработаны (думаю, что L2ARC) и сжатие / дедупликация это весело. Иметь больше «кластеров хранения», то есть иметь только небольшие сбои вместо одного большого консолидированного бума

Против: Поддержка множества небольших программных блоков вместо реального хранилища. Нужно интегрировать их и тратить $$$ часы на надежную настройку.

Маршрут XFS + LVM действительно является одним из лучших вариантов для масштабируемого решения для хранения данных на основе чистого Linux за последние несколько лет. Я рад, что ты уже там. Теперь, когда вам нужно больше расти, у вас есть еще несколько вариантов.

Как вы знаете, у крупных производителей оборудования есть NAS-головки для хранения. Это действительно даст вам одного поставщика для работы, и это будет работать довольно хорошо. Это простые решения (по сравнению с 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 под вашими узлами, довольно легко добиться цели.