Советы по эффективному хранению 25 ТБ + миллионов файлов в файловой системе


11

Допустим, вы сталкиваетесь с несжатыми файлами журналов на 25 ТБ и имеете в своем распоряжении массив из 20 коробок с общим объемом свободного хранения 25 ТБ.

Как бы вы сохранили это?

а) Какую распределенную файловую систему использовать?

б) Какой формат / алгоритм сжатия / распаковки?

c) Размер файла журнала составляет от 1 МБ до 7 МБ всего текста и много пробелов

г) Использование а) люди хотят, чтобы последние файлы журналов были больше, чем предыдущие, поэтому какую систему кэширования использовать б) люди будут только читать файлы журналов, а не удалять их в) люди хотят, чтобы список файлов журналов соответствовал диапазону дат

e) Операционная система, работающая на товарных коробках, - Linux

f) Что касается резервного копирования, у нас есть массив хранения, который позаботится об этом. Так что возможность восстановления данных из массива существует.

Я не хочу, чтобы они обращались к файловой системе напрямую. Что я должен делать ? Как мне получить для них API на основе REST?

Пожалуйста, сэкономьте 2 цента, и что бы вы сделали?

Анкур


На каких операционных системах работают товарные коробки? Требуется ли отказоустойчивость или если вы потеряете все данные, хранящиеся в одном ящике, это нормально?
Марк Хендерсон

@farseeker отредактировал вопрос, чтобы ответить на ваши вопросы. Спасибо
Анкур Гупта

Просто перечитайте вопрос, и первый вопрос, который я хотел бы задать: где хранятся 25 ТБ файлов журналов и могут ли они там оставаться?
Марк Хендерсон

@farseeker в файловой системе NFS
Анкур Гупта

Ответы:


7

Я не распределенная файловая система, ниндзя, но после объединения как можно большего количества дисков на как можно меньшее количество компьютеров я попытаюсь использовать iSCSI для подключения большей части компьютеров к одной основной машине. Там я мог бы объединить вещи в надежное хранилище. Предпочтительно, отказоустойчив в пределах машины (если диск отключен) и между машинами (если вся машина выключена).

Лично мне нравится ZFS. В этом случае полезно использовать сжатие, дедупликацию и отказоустойчивость. Тем не менее, я уверен, что есть много других способов сжатия данных, делая их отказоустойчивыми.

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

Редактировать: я все еще новичок в ZFS и настройке iSCSI, но вспомнил, что видел видео от Sun в Германии, где они демонстрировали отказоустойчивость ZFS. Они подключили три USB-концентратора к компьютеру и вставили четыре флэш-накопителя в каждый концентратор. Затем, чтобы любой концентратор не мог отключить пул хранения, они создали том RAIDz, состоящий из одного флэш-диска из каждого концентратора. Затем они объединяют четыре тома ZFS RAIDz вместе. Таким образом, только четыре флешки использовались для проверки четности. Затем, конечно, отключенный концентратор, который ухудшил работу каждого zpool, но все данные были доступны. В этой конфигурации может быть потеряно до четырех дисков, но только если два любых диска не находятся в одном пуле.

Если бы эта конфигурация использовалась с необработанным диском каждого блока, это позволило бы сохранить больше дисков для данных, а не для контроля четности. Я слышал, что FreeNAS может (или собирался иметь возможность) совместно использовать диски в «сыром» виде через iSCSI, поэтому я предполагаю, что Linux может делать то же самое. Как я уже сказал, я все еще учусь, но этот альтернативный метод будет менее расточительным с точки зрения четности привода, чем мое предыдущее предложение. Конечно, это будет зависеть от использования ZFS, который я не знаю, будет ли приемлемым. Я знаю, что лучше всего придерживаться того, что вы знаете, если вам придется что-то строить / поддерживать / ремонтировать, если только это не опыт обучения.

Надеюсь, это лучше.

Изменить: сделал некоторые копания и нашел видео, о котором я говорил. Часть, где объясняется распространение USB-флешки по концентраторам, начинается с 2m10s. Видео демонстрирует их сервер хранения «Thumper» (X4500) и рассказывает о том, как распределить диски между контроллерами, чтобы в случае сбоя контроллера жесткого диска ваши данные оставались хорошими. (Лично я думаю, что это просто видео о гиках, которые веселятся. Хотелось бы, чтобы у меня была коробка с Thumper, но моя жена не хотела бы, чтобы я управлял домкратом для паллет по дому.: D Это одна большая коробка.)

Редактировать: Я вспомнил, как общался через распределенную файловую систему под названием OpenAFS . Я не пробовал, я только читал об этом. Возможно, другие знают, как это происходит в реальном мире.


4

Во-первых, файлы журналов могут быть сжаты в действительно высоких соотношениях. Я считаю, что мои файлы журналов сжимаются в соотношении 10: 1. Если они сжимаются даже до соотношения 5: 1, это всего лишь 5 ГБ, или 20% от емкости вашего хранилища.

Учитывая, что у вас более чем достаточно памяти, конкретный алгоритм сжатия не слишком важен. Вы могли бы...

  • Используйте zip-файлы, если пользователи Windows будут обращаться к ним напрямую.
  • Используйте gzip, если они будут доступны через Linux, и важна быстрая распаковка.
  • Используйте bzip2, если они будут доступны через Linux, и важно иметь как можно меньше файлов.

Большой вопрос: как вы собираетесь предоставить своим пользователям легкий доступ к этим файлам? Частично это зависит от того, как настроены ваши машины.

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

Если вы не можете создать один файловый сервер для этих файлов, то вы можете обнаружить, что вам нужна распределенная файловая система. В Windows есть распределенная файловая система (DFS), которая может удовлетворить ваши потребности.

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


К сведению: Windows DFS - это способ синхронизации файлов и папок на нескольких серверах. Это не позволит вам использовать хранилище на нескольких серверах как один накопитель. microsoft.com/windowsserversystem/dfs/default.mspx
Скотт МакКленнинг,

Подумав об этом, вы правы; Можно использовать DFS, если у вас есть корневая точка DFS для папок, находящихся на других компьютерах. Таким образом, пользователь будет видеть одну файловую структуру, и ему не нужно будет знать, на каких машинах фактически живут данные, знает DFS. Это будет работать. Обычно, когда меня спрашивают о Windows DFS, они обычно думают, что это способ объединить пространство памяти, и поэтому я просто делаю такой вывод. Извините и ваше право, что может сработать.
Скотт МакКленнинг


2

экспортировать эти папки через NFS

смонтировать их на одной машине с запущенным apache (под корнем документа) в виде дерева

используйте zip для их сжатия - хорошее сжатие, zip можно открыть из любой ОС

список файлов в Apache - так что вы предоставляете пользователям доступ только для чтения (файлы журнала не должны редактироваться, верно)


1
Согласитесь на nfs + httpd, не согласен на zip. GZIP лучше взаимодействует с http.
Тобу

+1 за комментарий gzip от @Tobu - При правильной конфигурации Apache может подавать файлы gzip в веб-браузер, который будет прозрачно распаковывать и отображать их. Пользователям даже не нужно знать о сжатии.
Кристофер Кашелл

0

Вы когда-нибудь думали о сжатии файлов журнала? Затем сделайте что-нибудь на внешнем интерфейсе, чтобы распаковать их перед тем, как передать их конечному пользователю. Может быть, что-то вроде CGI-скрипта.


0

@ Анкур и @ Порч. Я полностью согласен с необходимостью сжать эти журналы.

@ jet Я думаю, что более простая схема лучше - поэтому httpd для конечного пользователя близок к идеальному. И бэкэнд может быть любым.

Мое мнение - разделить логи на 2 группы - папки «старые» и «новые».

Объедините их в корень документа httpd. Используйте сильное сжатие для старых (xz или 7z архивов, популярных для всех ОС) с большими словарями и размерами блоков, может быть даже сплошные архивы.

Используйте сжатие fs для новых: lessfs (rw, дедупликация + легкие методы сжатия), fusecompress 0.9.x (rw, легкие в сильные методы сжатия), btrfs / zfs, squashfs (ro, легкие в сильные методы сжатия, некоторые дедупликации, использование для вновь повернутых бревен).

Вы даже можете прозрачно записывать логи в сжатые фс (fusecompress, lessfs, btrfs / zfs). Предоставить R / O доступ по httpd к записываемым журналам. Они будут прозрачны для пользователей и прозрачно распакованы для них.

Предупреждения о fusecompress: 1) используйте только 0.9.x - он стабилен. Клон отсюда https://github.com/hexxellor/fusecompress

Более поздние версии либо плохо поддерживают lzma, либо теряют данные.

2) он использует только 1 процессорное ядро ​​для сжатия одного файла, поэтому может быть медленным.

Повторно нажимайте каждый журнал в «новой» папке, старше чем некоторое время (несколько месяцев) и переходите к «старому».

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.