HW/SW Design: 2 петабайта памяти

Отказ от ответственности Да, я прошу вас разработать систему для меня:)

Мне поручено разработать систему для хранения около 10 ТБ / день со сроком хранения 180 дней.

Мой первый подход - использовать GlusterFS и использовать настройку HW, например:

Единственный узел в системе:

Мне нужно 9 узлов, чтобы получить сетевое хранилище (без репликации или рейда на локальных дисках), которое может хранить данные.

Плюсы:

  • Я могу начать с одного сервера без полок
  • Выращивайте, добавляя полки к одному серверу (или добавляйте серверы, просто подумайте о масштабировании, сначала добавив узлы или сначала добавив полки или некоторое сочетание обоих)
  • масштабируется "бесконечно" (для некоторых определений "бесконечно")

Минусы:

  • В целом: на самом деле я понятия не имею, как проверить, будет ли это жизнеспособной установкой, как только я достигну финальной стадии расширения (приблизительно 1,8 ПБ)

У меня нет какого-либо предпочтительного направления, только некоторый опыт работы с GlusterFS, где у меня есть система 4 ТБ (распределенная, реплицированная, 4 узла), уже использующая GlusterFS.

Я почти уверен, что нет особой разницы, запускает ли эта установка Hadoop/Gluster/Netapp/EMC/Hitachi/EveryoneElse, но вариант использования (барабанная дробь):

ls -ltr | grep 'something' | xargs grep somethingelse

Да, это страшно. Я пытался убедить людей на самом деле выполнять реальные аналитические работы над этими данными, но, похоже, этого не произойдет. (Хорошо, это не так уж и плохо, но эти люди будут использовать простой ssh-сеанс в какой-то "аналитической" системе, чтобы вручную перейти к некоторому каталогу, рекурсивно просмотреть некоторые файлы и затем определить, в порядке ли данные, в порядке или нет, что сейчас звучит еще хуже это я написал)

Я открыт для любых идей, у меня есть люди, которые управляют "большим хранилищем" в нашей компании (например, одна система резервного копирования имеет 2 ПБ), и я бы хотел использовать то, что у них уже работает. Но я также должен доказать, что они делают правильные вещи (пожалуйста, не спрашивайте об этом, это политическая вещь, я бы доверил свои данные команде хранения, я понятия не имею, почему я должен дублировать работу)

Размышление о проблеме, как на самом деле запустить анализ данных, явно выходит за рамки.

Были бесчисленные встречи, и я поднял все от Splunk до аналитических заданий, разработанных на дому (с и / или без системы Map/Reduce System). Там нет интереса в этом. Все люди заботятся о том, чтобы:

  • 10 ТБ / день
  • Храните данные 180 дней
  • Сделайте его высокодоступным (еще не полностью определенным, но что-то вроде 99,9, 99,99...)
Источник

2 ответа

Ну, вы не упомянули бюджет... Так что купите это сейчас. Данные такого масштаба, вероятно, следует оставить в руках команды, имеющей опыт в этой области. Приятно иметь поддержку и кричать на кого-то:)

http://www.racktopsystems.com/products/brickstor-superscalar/

http://www.racktopsystems.com/products/brickstor-superscalar/tech-specs/

4 x Storage Heads BrickStor Foundation Units
10 x BrickStor Bricks (36 x 3.5″ Bay JBOD)
2 x 16-port SAS switch
1 x pullout rackmount KVM
1 x 48U Rack
1 x 10Gb Network Switch (24 x 10Gb non-Blocking)
NexentaStor Plug-ins:VMDC, WORM, HA-cluster or Simple-HA
Onsite installation 5-days
24/7/365 day email and phone support
Onsite Support

Поскольку описываемое вами приложение в действительности не относится к области кластерного хранилища (с учетом варианта использования), используйте ZFS. Вы получите бесконечную масштабируемость. У вас будет возможность переложить часть сжатия в систему хранения, и вы сможете рассказать об этом всем своим друзьям:)

Более того, кеширование L2ARC (с использованием твердотельных накопителей) будет держать горячие данные доступными для анализа со скоростью SSD.

Изменить: еще одно решение на основе ZFS- http://www.aberdeeninc.com/abcatg/petarack.htm

Кроме того, Red Hat сейчас находится в области масштабируемой индустрии хранения.

Смотрите: http://www.redhat.com/products/storage/storage-software/

Источник

Как MDMarra упоминает, что для этого вам нужен Splunk, я большой пользователь и поклонник, для очень похожих объемов, как вы обсуждаете, и сразу же это избавит вас от необходимости покупать где-то рядом с таким большим объемом памяти и уменьшит всю сложность. Один сервер приличного размера (может быть, максимум 150-200 ТБ) справится с этой задачей, если использовать его с Splunk, он индексируется на лету и идеально подходит для такого рода задач, а его возможности поиска намного превосходят все, что вы будете управлять самостоятельно. Конечно, это не бесплатно, но я бы больше ничего не рассматривал.

Источник
Другие вопросы по тегам