Отказ от ответственности Да, я прошу вас разработать для меня систему :)
Мне поручено разработать систему для хранения около 10 ТБ в день со сроком хранения 180 дней.
Моим первым подходом было бы пойти с GlusterFS и использовать такую настройку HW:
Единый узел в системе:
Мне нужно 9 узлов, чтобы получить сетевое хранилище (без репликации или рейда на локальных дисках), которое может хранить данные.
Плюсы:
Минусы:
У меня нет никакого реального предпочтительного направления, только некоторый опыт работы с GlusterFS, где у меня есть система 4 ТБ (распределенная, реплицированная, 4 узла), уже использующая GlusterFS.
Я почти уверен, что нет большой разницы, работает ли эта установка с Hadoop / Gluster / Netapp / EMC / Hitachi / EveryoneElse, но вариант использования (барабанная дробь):
ls -ltr | grep 'something' | xargs grep somethingelse
Да это страшно. Я пытался убедить людей выполнять настоящую аналитическую работу над этими данными, но, похоже, этого не произошло. (Хорошо, это не так уж плохо, но эти люди будут использовать простой сеанс ssh в какой-то «аналитической» системе, чтобы вручную перейти в какой-либо каталог, рекурсивно просмотреть некоторые файлы и затем определить, в порядке ли данные или нет, что звучит еще хуже, когда я это написал)
Я открыт для любых идей, у меня есть люди, которые используют «большое хранилище» в нашей компании (например, одна система резервного копирования имеет 2 ПБ), и я хотел бы использовать все, что у них уже работает. Но я также должен доказать, что они поступают правильно (пожалуйста, не спрашивайте об этом, это политический вопрос, я бы доверил свои данные команде хранилища, я понятия не имею, почему я должен дублировать работу)
Размышления о том, как на самом деле провести анализ данных, явно выходит за рамки.
Было бесчисленное количество встреч, и я рассказывал обо всем, от Splunk до аналитических заданий, разработанных собственными силами (с / или без системы Map / Reduce). В этом нет никакого интереса. Все, что волнует людей, это:
Вы не упомянули бюджет ... Так что купите это сейчас. Данные такого масштаба, вероятно, следует оставить в руках команды, имеющей опыт в этой области. Приятно иметь поддержку и на кого кричать :)
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) будет держать горячие данные доступными для анализа на скорости SSD.
Изменить: другое решение на основе ZFS - http://www.aberdeeninc.com/abcatg/petarack.htm
Кроме того, Red Hat теперь занимается горизонтально масштабируемыми системами хранения.
Видеть: http://www.redhat.com/products/storage/storage-software/
Как упоминает MDMarra, для этого вам нужен Splunk, я большой пользователь и поклонник очень похожих томов, которые вы обсуждаете, и сразу же избавит вас от необходимости покупать где-то рядом с таким объемом хранилища и упростит всю сложность. Один сервер приличного размера (может быть, 150-200 ТБ макс) выполнит эту работу, если используется со Splunk, его индексирование на лету идеально подходит для такого рода вещей, а его возможности поиска намного превосходят все, что вы управляете самостоятельно. Конечно, это не бесплатно, но я бы не стал рассматривать другие варианты.