Допустим, вы сталкиваетесь с несжатыми файлами журналов на 25 ТБ и имеете в своем распоряжении массив из 20 коробок с общим объемом свободного хранения 25 ТБ.
Как бы вы сохранили это?
а) Какую распределенную файловую систему использовать?
б) Какой формат / алгоритм сжатия / распаковки?
c) Размер файла журнала составляет от 1 МБ до 7 МБ всего текста и много пробелов
г) Использование а) люди хотят, чтобы последние файлы журналов были больше, чем предыдущие, поэтому какую систему кэширования использовать б) люди будут только читать файлы журналов, а не удалять их в) люди хотят, чтобы список файлов журналов соответствовал диапазону дат
e) Операционная система, работающая на товарных коробках, - Linux
f) Что касается резервного копирования, у нас есть массив хранения, который позаботится об этом. Так что возможность восстановления данных из массива существует.
Я не хочу, чтобы они обращались к файловой системе напрямую. Что я должен делать ? Как мне получить для них API на основе REST?
Пожалуйста, сэкономьте 2 цента, и что бы вы сделали?
Анкур
источник
Ответы:
Я не распределенная файловая система, ниндзя, но после объединения как можно большего количества дисков на как можно меньшее количество компьютеров я попытаюсь использовать iSCSI для подключения большей части компьютеров к одной основной машине. Там я мог бы объединить вещи в надежное хранилище. Предпочтительно, отказоустойчив в пределах машины (если диск отключен) и между машинами (если вся машина выключена).
Лично мне нравится ZFS. В этом случае полезно использовать сжатие, дедупликацию и отказоустойчивость. Тем не менее, я уверен, что есть много других способов сжатия данных, делая их отказоустойчивыми.
Хотел бы я порекомендовать реальное решение для распределенных файлов «под ключ», я знаю, что это действительно круто, но я надеюсь, что оно направит вас в правильном направлении.
Редактировать: я все еще новичок в ZFS и настройке iSCSI, но вспомнил, что видел видео от Sun в Германии, где они демонстрировали отказоустойчивость ZFS. Они подключили три USB-концентратора к компьютеру и вставили четыре флэш-накопителя в каждый концентратор. Затем, чтобы любой концентратор не мог отключить пул хранения, они создали том RAIDz, состоящий из одного флэш-диска из каждого концентратора. Затем они объединяют четыре тома ZFS RAIDz вместе. Таким образом, только четыре флешки использовались для проверки четности. Затем, конечно, отключенный концентратор, который ухудшил работу каждого zpool, но все данные были доступны. В этой конфигурации может быть потеряно до четырех дисков, но только если два любых диска не находятся в одном пуле.
Если бы эта конфигурация использовалась с необработанным диском каждого блока, это позволило бы сохранить больше дисков для данных, а не для контроля четности. Я слышал, что FreeNAS может (или собирался иметь возможность) совместно использовать диски в «сыром» виде через iSCSI, поэтому я предполагаю, что Linux может делать то же самое. Как я уже сказал, я все еще учусь, но этот альтернативный метод будет менее расточительным с точки зрения четности привода, чем мое предыдущее предложение. Конечно, это будет зависеть от использования ZFS, который я не знаю, будет ли приемлемым. Я знаю, что лучше всего придерживаться того, что вы знаете, если вам придется что-то строить / поддерживать / ремонтировать, если только это не опыт обучения.
Надеюсь, это лучше.
Изменить: сделал некоторые копания и нашел видео, о котором я говорил. Часть, где объясняется распространение USB-флешки по концентраторам, начинается с 2m10s. Видео демонстрирует их сервер хранения «Thumper» (X4500) и рассказывает о том, как распределить диски между контроллерами, чтобы в случае сбоя контроллера жесткого диска ваши данные оставались хорошими. (Лично я думаю, что это просто видео о гиках, которые веселятся. Хотелось бы, чтобы у меня была коробка с Thumper, но моя жена не хотела бы, чтобы я управлял домкратом для паллет по дому.: D Это одна большая коробка.)
Редактировать: Я вспомнил, как общался через распределенную файловую систему под названием OpenAFS . Я не пробовал, я только читал об этом. Возможно, другие знают, как это происходит в реальном мире.
источник
Во-первых, файлы журналов могут быть сжаты в действительно высоких соотношениях. Я считаю, что мои файлы журналов сжимаются в соотношении 10: 1. Если они сжимаются даже до соотношения 5: 1, это всего лишь 5 ГБ, или 20% от емкости вашего хранилища.
Учитывая, что у вас более чем достаточно памяти, конкретный алгоритм сжатия не слишком важен. Вы могли бы...
Большой вопрос: как вы собираетесь предоставить своим пользователям легкий доступ к этим файлам? Частично это зависит от того, как настроены ваши машины.
Если вы можете разместить достаточно памяти на одном компьютере, вы можете сделать что-то чрезвычайно простое, например общий доступ к файлам Windows только для чтения. Просто организуйте файлы в подкаталогах, и вы готовы к работе.
Если вы не можете создать один файловый сервер для этих файлов, то вы можете обнаружить, что вам нужна распределенная файловая система. В Windows есть распределенная файловая система (DFS), которая может удовлетворить ваши потребности.
Если ваши потребности более продвинуты, вы можете использовать веб-приложение в качестве внешнего интерфейса, где ваши пользователи могут просматривать и загружать файлы журналов. В этом случае я рекомендую использовать MogileFS - распределенную файловую систему, предназначенную для использования с сервером приложений переднего плана. Это очень легко интегрировать с большинством языков веб-программирования. Вы не можете смонтировать его как общий диск на вашем компьютере, но это первоклассное хранилище данных для веб-приложения.
источник
lessfs - это дедуплицирующая , сжимающая файловая система. Хотя это не решит проблему в целом, стоит взглянуть на нее как на бэкэнд.
источник
экспортировать эти папки через NFS
смонтировать их на одной машине с запущенным apache (под корнем документа) в виде дерева
используйте zip для их сжатия - хорошее сжатие, zip можно открыть из любой ОС
список файлов в Apache - так что вы предоставляете пользователям доступ только для чтения (файлы журнала не должны редактироваться, верно)
источник
Вы когда-нибудь думали о сжатии файлов журнала? Затем сделайте что-нибудь на внешнем интерфейсе, чтобы распаковать их перед тем, как передать их конечному пользователю. Может быть, что-то вроде CGI-скрипта.
источник
@ Анкур и @ Порч. Я полностью согласен с необходимостью сжать эти журналы.
@ 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 процессорное ядро для сжатия одного файла, поэтому может быть медленным.
Повторно нажимайте каждый журнал в «новой» папке, старше чем некоторое время (несколько месяцев) и переходите к «старому».
источник