Допустим, вы столкнулись с несжатыми файлами журнала объемом 25 ТБ, и в вашем распоряжении имеется массив из 20 ящиков с обычными товарами с общим объемом бесплатного хранения 25 ТБ.
Как бы вы их хранили?
а) Какую распределенную файловую систему использовать?
б) Какой формат / алгоритм сжатия / распаковки?
c) Размер файла журнала составляет от 1 МБ до 7 МБ, весь текст и много пробелов.
г) Использование: а) людям нужны последние файлы журналов больше, чем предыдущие, поэтому какую систему кеширования использовать б) люди будут только читать файлы журналов, а не удалять их в) люди хотят перечислить файлы журналов по диапазону дат
д) Операционная система, работающая на обычных ящиках - Linux,
е) Что касается резервного копирования, у нас есть массив хранения, который позаботится об этом. Так что возможность восстановления данных из массива существует.
Я не хочу, чтобы они напрямую обращались к файловой системе. Что я должен делать ? Как мне получить для этого API на основе REST?
Пожалуйста, сэкономьте 2 цента, и что бы вы сделали?
Анкур
Я не ниндзя распределенной файловой системы, но после объединения как можно большего количества дисков на как можно меньшее количество машин я бы попытался использовать iSCSI для подключения большей части машин к одной основной машине. Там я мог бы объединить все в отказоустойчивое хранилище. Предпочтительно отказоустойчивый внутри машины (если диск выходит из строя) и между машинами (если вся машина отключена).
Лично мне нравится ZFS. В этом случае было бы полезно встроить сжатие, дедупликацию и отказоустойчивость. Однако я уверен, что есть много других способов сжать данные, сделав их отказоустойчивыми.
Хотел бы я порекомендовать реальное решение для распределенных файлов под ключ, я знаю, что это действительно беспорядочно, но я надеюсь, что оно укажет вам правильное направление.
Редактировать: Я все еще новичок в ZFS и настройке iSCSI, но вспомнил, что видел видео от Sun в Германии, где они демонстрировали отказоустойчивость ZFS. Они подключили к компьютеру три USB-концентратора и вставили по четыре флеш-накопителя в каждый концентратор. Затем, чтобы предотвратить отключение пула хранения каким-либо одним концентратором, они сделали том RAIDz, состоящий из одной флэш-памяти от каждого концентратора. Затем они разделяют четыре тома ZFS RAIDz вместе. Таким образом, для паритета использовались всего четыре флешки. Затем, конечно, отключился один концентратор, и это ухудшило работу каждого zpool, но все данные были доступны. В этой конфигурации может быть потеряно до четырех дисков, но только если любые два диска не находятся в одном пуле.
Если бы эта конфигурация использовалась с необработанным диском каждого бокса, то это позволило бы сохранить больше дисков для данных, а не для четности. я слышал FreeNAS может (или собирался иметь возможность) обмениваться дисками «сырым» способом через iSCSI, поэтому я предполагаю, что Linux может делать то же самое. Как я уже сказал, я все еще учусь, но этот альтернативный метод был бы менее расточительным с точки зрения паритета дисков, чем мое предыдущее предложение. Конечно, это будет полагаться на использование ZFS, что я не знаю, будет ли это приемлемо. Я знаю, что обычно лучше придерживаться того, что вы знаете, если вам придется что-то строить / поддерживать / ремонтировать, если это не учебный опыт.
Надеюсь, это лучше.
Редактировать: Покопался и нашел видео Я говорил о. Часть, в которой объясняется распространение USB-накопителя по концентраторам, начинается с 2:10. Видео демонстрирует их сервер хранения «Thumper» (X4500) и то, как распределить диски по контроллерам, чтобы в случае отказа контроллера жесткого диска ваши данные все равно были в порядке. (Лично я думаю, что это просто видео, на котором фанаты веселятся. Я бы хотел, чтобы у меня сам был ящик Thumper, но моя жена не хотела бы, чтобы я провожу домкрат по дому.: D Это одна большая коробка.)
Редактировать: Я вспомнил, как переходил через распределенную файловую систему под названием OpenAFS. Я не пробовал, я только кое-что читал об этом. Возможно, другие знают, как это работает в реальном мире.
Во-первых, файлы журнала можно сжимать с очень высоким коэффициентом сжатия. Я обнаружил, что мои файлы журналов сжимаются в соотношении 10: 1. Если они сжимаются даже до соотношения 5: 1, это всего 5 ГБ, или 20% вашей емкости хранилища.
Учитывая, что у вас более чем достаточно памяти, конкретный алгоритм сжатия не слишком важен. Ты мог...
Более важный вопрос: как вы собираетесь предоставить своим пользователям легкий доступ к этим файлам? Частично это зависит от того, как настроены ваши машины.
Если вы можете разместить достаточно памяти на одной машине, вы можете сделать что-то чрезвычайно простое, например, доступный только для чтения файловый ресурс Windows. Просто организуйте файлы в подкаталоги, и все готово.
Если вы не можете создать один файловый сервер для этих файлов, вы можете обнаружить, что необходимость распределенная файловая система. В Windows есть распределенная файловая система (DFS), которая может удовлетворить ваши потребности.
Если ваши потребности более сложны, вам может потребоваться веб-приложение в качестве интерфейса, где ваши пользователи могут просматривать и загружать файлы журналов. В этом случае я рекомендую использовать MogileFS, распределенную файловую систему, предназначенную для использования с сервером интерфейсных приложений. Его очень легко интегрировать с большинством языков веб-программирования. Вы не можете подключить его как общий диск на своем компьютере, но он отлично подходит для хранения данных для веб-приложения.
экспортировать эти папки через NFS
смонтировать их на одной машине с запущенным apache (в корне документа) в виде дерева
используйте zip для их сжатия - хорошая степень сжатия, zip можно открыть из всех ОС
список файлов в Apache - значит, вы предоставляете пользователям доступ только для чтения (файлы журналов не должны редактироваться, верно)
lessfs это файловая система с дедупликацией и сжатием. Хотя это не решит всю проблему, возможно, стоит взглянуть на него как на бэкэнд.
Вы когда-нибудь задумывались о сжатии файлов журналов? Затем сделайте что-нибудь в интерфейсе, чтобы распаковать их перед тем, как передать их конечному пользователю. Может быть, своего рода сценарий CGI.
@Ankur и @Porch. Я полностью согласен с необходимостью сжатия этих журналов.
@jet Я думаю, что более простая схема лучше - поэтому httpd для конечного пользователя близок к идеалу. А бэкэнд может быть любым.
Мое мнение - делите логи на 2 группы - папки «старые» и «новые».
Слейте их в корень документа httpd. Используйте сильное сжатие для старых (архивы xz или 7z, популярные для всех ОС) с большими словарями и размерами блоков, могут быть даже надежные архивы.
Используйте сжатие fs для новых: lessfs (rw, методы дедупликации + легкие методы сжатия), fusecompress 0.9.x (rw, методы сжатия от слабого до сильного), btrfs / zfs, squashfs (ro, методы сжатия от слабого до сильного, некоторые дедупликации, используйте для вновь повернутых бревен).
Вы даже можете прозрачно записывать журналы в сжатые файловые системы (fusecompress, lessfs, btrfs / zfs). Предоставьте httpd доступ для чтения / записи к записываемым журналам. Они будут прозрачными для пользователей и прозрачно распакованными для них.
Предупреждения о fusecompress: 1) используйте только 0.9.x - стабильно. Клонировать отсюда https://github.com/hexxellor/fusecompress
Более поздние версии либо плохо поддерживают lzma, либо теряют данные.
2) он использует только 1 ядро процессора для сжатия одного файла, поэтому может быть медленным.
Повторно сжимайте каждый журнал в «новой» папке, старше определенного времени (несколько месяцев), и переходите в «старую».