После 16 месяцев разработки увидел свет (http://xtreemfs.blogspot.ru/2014/03/xtreemfs-15-released-imp...) релиз распределенной файловой системы XtreemFS 1.5 (http://www.xtreemfs.org/). XtreemFS позволяет организовать работу хранилища с распределением данных по нескольким серверам. Для обеспечения отказоустойчивости и обеспечения параллельного доступа данные могут реплицироваться между узлами. Процесс репликации оптимизирован для использования низкоскоростных соединений и возможных временных обрывов связи. Компоненты XtreemFS распространяются (http://code.google.com/p/xtreemfs/) под лицензией BSD (http://code.google.com/p/xtreemfs/source/browse/branches/Xtr...).При помощи XtreemFS в том числе можно обеспечить синхронизацию хранилища на нескольких серверах в разных дата-центрах. Предоставляется возможность гибкого контроля и управления работой ФС через подключение плагинов. Возможно создание снапшотов и бэкапа метаданных в асинхронном режиме. Для защиты передаваемых по сети данных от перехвата поддерживается использование SSL. Расширение размера хранилища производится через подключение к распределенному хранилищу дополнительных узлов хранения.
Серверная часть XtreemFS, обеспечивающая управление метаданными, написана (http://www.xtreemfs.org/download_sources.php) на языке Java. Клиент для работы с XtreemFS написан на С++ и доступен для Unix-подобных ОС, Windows и Mac OS X. Клиентская часть ФС работает в пространстве пользователя (user-space) с использованием FUSE. Для приложений работа с XtreemFS мало чем отличается от NFS (XtreemFS может использоваться как замена NFS), так же нет отличий от того, является ли файл реплицированным на локальную систему или доступен только с удаленного хоста.
Из новшеств, добавленных в XtreemFS 1.5, можно отметить:
- Улучшена поддержка платформы для организации распределённой обработки больших объёмов данных Hadoop. Добавлена дополнительная буферизация чтения и записи для увеличения производительности небольших запросов. Реализована поддержка работы с несколькими разделами для организации хранения данных для ввода и вывода в разделах с разными правилами репликации;- Добавлены оптимизации для организации оптимального хранения данных на SSD-накопителях. Ранее система была рассчитана на использование жестких дисков и применяла однопоточный метод доступа, учитывающий вращение дисков. Для SSD реализована возможность одновременного обращения в несколько потоков, что позволяет добиться более высокой пропускной способности;
- Поддержка Multi-Homing для организации работы XtreemFS поверх разных сетей с предоставлением средств для автоматического получения клиентом корректного адреса для обращения к хранилищу;
- Возможность создания нескольких хранилищ объектов (OSD) на одном сервере. Таким образом, для каждого диска на сервере может быть запущен отдельный OSD. Для упрощения запуска серии OSD подготовлен init.d-скрипт xtreemfs-osd-farm;
- Проведена работа по устранению ошибок в реализациях репликации, работающих в режимах "только чтение" или "чтение/запись". В частности, решены проблемы с отказоустойчивостью для файлов, реплицированных в режиме "чтение/запись", и устранена проблема с зависанием в режиме "только чтение";
- Добавлена страница с наглядным отображением состояния репликации для открытых файлов;
<center><a href="http://3.bp.blogspot.com/-UV2vqa2_fjQ/UyDf1frjlII/AAAAAAAAAC... src="https://www.opennet.ru/opennews/pics_base/0_1394803838.png" style="border-style: solid; border-color: #606060; border-width: 1px;max-width:100%;" title="" border=0></a></center>- Подготовлено (http://code.google.com/p/xtreemfs/wiki/ContrailSummerSchoolH...) руководство для быстрого знакомства с XtreemFS, в котором в том числе описывается простейшие примеры отказоустойчивых конфигураций и репликации данных.
URL: http://xtreemfs.blogspot.ru/2014/03/xtreemfs-15-released-imp...
Новость: https://www.opennet.ru/opennews/art.shtml?num=39315
чем оно лучше glusterfs, ceph и lustre?
тем, что написано на жаве, очевидно.
Не знаю как XtreemFS, но glusterfs не умеет следить за оставшимся местом на ноде на которую он кидает файл. Она годится только если у тебя все файлы одного размера, тогда место будет заполняться равномерно.
> Серверная часть XtreemFS .. написана на языке Java. Клиент для работы с XtreemFS написан на С++где эти люди потеряли логику?
С++ ибо FUSE на клиенте.
Сервер метаданных на Java - так проще писать сложную логику.
так быстрее писать сложную логику. // fixed
и вот зачем оно на яве нужно
А то что hadoop и производные, дефакто стандарт для big data, полностью на java написан, вас не смущает?
Теплое и мягкое.
> Теплое и мягкое.Эм.. hadoop/hdfs - распределенная файловая система, XtreemFS - распределенная файловая система. Не объясните - в чем их идеологические/концептуальные различия..?
Если честно, то оочень смущает. И по производительности, и, особенно, по безопасности этих big data.
И сколько дефейсов за время эксплуатации у вас было зафиксировано?
> особенно, по безопасности этих big data.Обоснуешь?
сразу видно знающего человека
//сарказм.
нифига не стандарт, это затычка для нищебро. А там где действительно big data хадуп со своими производными сосёт и люди юзают свои локальные поделки на с/с++ и etc.
Охтыж, что только не узнаешь на opennet. Facebook, Yahoo, ebay, adobe - нищеброды. А Oracle, IBM и пол дюжины других известных вендоров делают и продают решения на основе затычки для нищебродов. Наверное, тоже начали ориентироваться на рынок нищебродов.
Для тебя новость, что деньги делают всегда на нищебродах?
> Для тебя новость, что деньги делают всегда на нищебродах?а че, есть примеры контор где для вот этих вот штук используется не ходуп а что-то свое, на "С/С++" ? там же, помимо этой вот хдфс, как бы и матеметеги over дофига. мапят там, редьюсят, прочей фигней занимаются с данными. реально интересно, есть ли те, у кого столько бабла чтобы написать свой задуп.
математика это уже приложение, а не компонент хранилища и кластерного по. Свои С/C++ реализации всего этого добра есть хотя бы у более-менее вменяемых поисковиков, например google и yandex. Не нужно думать, что hdfs/hadoop это такое замечательное отлаженное решенре, на самом деле там довольно много косяков и много чего нужно долго и нудно допиливать напильником.
> Не нужно думать, что hdfs/hadoop это такое замечательное отлаженное решенре, на самом деле там довольно много косяков и много чего нужно долго и нудно допиливать напильником.а я и не считаю его готовым к использованию "как есть". но таки пилить его дешевле и проще, чем ваять аналог с нуля. не?
смотря чего хочется. Если захочется двигаться и развиваться дальше, то на определённом этапе придётся делать своё решение. Будет это на мясе из хадупа или нет уже не так важно, ибо разрабатывать нужно будет в обоих вараиантах много, архитектурно и алгоритмически. Но ява к этому ещё подкинет кучку инженерного гогна в виде аппетитов к памяти и внезапного GC.
> смотря чего хочется. Если захочется двигаться и развиваться дальше, то на определённом
> этапе придётся делать своё решение.верно
> Но ява к этому ещё
> подкинет кучку инженерного гогна в виде аппетитов к памяти и внезапного
> GC.так а аналоги-то тому же ходупу где, не на яве? в любом случае, не верится в то, что люди ,находясь в здравом уме, будут с нуля писать аналог на С/С++ не имея 100% гарантию того, что проект "выстрелит" => берется тотже ходуп, поначалу пытаются взлететь "как есть", потом наступает Просветление, изучается "сопроцессоры". Потом наступает еще 1 Просветление, начинают патчить ходуп "под себя". ну и уже после этого можно начать думать о чем-то своем. так что фраза про "для нищебродов" она как-то.. не вернА, мне по-прежнему кажется.
С страницы http://www.rekby.ru/2013/03/xtreemfs.html :"Итог - очень медленно работает с большим количеством файлов, например распаковка Joomla занимает около 15 минут в режиме синхронной записи в кластер и 20 минут в режиме асинхронной записи (на локальную файловую систему около 2-3 секунд).
Вход на страницу установки joomla занимает 20-40 секунд и так после каждого щелчка (т.е. после чтения файлы не кэшируются), настроек кэширования данных в этой файловой системе нет.Доступ к большому файлу так же не очень быстр. Запись архива на 70МБ идет со скоростью 140Кб/сек (настроена репликация на 3 сервера), чтение 4-5 МБ/сек."
>[оверквотинг удален]
> "Итог - очень медленно работает с большим количеством файлов, например распаковка Joomla
> занимает около 15 минут в режиме синхронной записи в кластер и
> 20 минут в режиме асинхронной записи (на локальную файловую систему около
> 2-3 секунд).
> Вход на страницу установки joomla занимает 20-40 секунд и так после каждого
> щелчка (т.е. после чтения файлы не кэшируются), настроек кэширования данных в
> этой файловой системе нет.
> Доступ к большому файлу так же не очень быстр. Запись архива на
> 70МБ идет со скоростью 140Кб/сек (настроена репликация на 3 сервера), чтение
> 4-5 МБ/сек."не удивительно, ведь через fuse
Да-да, тормозить может всё что угодно: сеть, ядро, драйвера, память, fuse, чёрт в ступе сглаз наложил, но только не жаба.
> Да-да, тормозить может всё что угодно: сеть, ядро, драйвера, память, fuse, чёрт
> в ступе сглаз наложил, но только не жаба.жаба на сервере метаданных, а тормозят операции I/O, которые работают через fuse и написаны на C++. Я конечно понимаю что вы никогда не видели нормальную имплементацию джавы в нормальных масштабах, но это просто потому что вы вообще никакой имплементации не видели, а не потому что таких имплементаций не бывает
Да-да, конечно-конечно, вы не волнуйтесь, поциент, это всё плюсы и fuse виноваты. У-у проклятые!
> Да-да, конечно-конечно, вы не волнуйтесь, поциент, это всё плюсы и fuse виноваты.
> У-у проклятые!то есть ответить нечего, ну я так и думал что имею дело с хомячком, спасибо за подтверждение
Что ж ты так кипишуешь-то болезный? Да, это всё мы, проклятые хомячки, криво пишем на плюсах, не даём светозарной жабе показать свою мощь. Это мы невовремя запускаем gc и калечим технику. От одного нашего взгляда требования к ресурсам у жаба-программ вырастают впятеро! Это мы тормозим прогресс, отчего вам не дают денег на память и железо. Мы смеем что-то возразить против нужности абстрактного генератора синглтонов фабрик фабрик. Еретики! Запретить!Истинно говорю вам, придёт день, и адепты самого правоверного языка перепишут всё на нём, и тогда наступит мир, покой и в человецах благорастворение. Покайтесь плюсовики! Плачьте ассемблерщики! Ибо близко воскрешение Сана, а оракл - пророк его!
>[оверквотинг удален]
> криво пишем на плюсах, не даём светозарной жабе показать свою мощь.
> Это мы невовремя запускаем gc и калечим технику. От одного нашего
> взгляда требования к ресурсам у жаба-программ вырастают впятеро! Это мы тормозим
> прогресс, отчего вам не дают денег на память и железо. Мы
> смеем что-то возразить против нужности абстрактного генератора синглтонов фабрик фабрик.
> Еретики! Запретить!
> Истинно говорю вам, придёт день, и адепты самого правоверного языка перепишут всё
> на нём, и тогда наступит мир, покой и в человецах благорастворение.
> Покайтесь плюсовики! Плачьте ассемблерщики! Ибо близко воскрешение Сана, а оракл -
> пророк его!это не просто хомячек, это еще и клоун
Дык клоуна и пародирую. Аль не признал?
> Дык клоуна и пародирую. Аль не признал?зачем ты сам себя пародируешь?тебе все правильно сказали, жаба там не при делах.
Не очень важно почему, главное что к реальному использованию, скорее всего, проект не готов. Разве что он идеально работает на медленных соединениях с частыми обрывами.
> Не очень важно почему, главное что к реальному использованию, скорее всего, проект
> не готов. Разве что он идеально работает на медленных соединениях с
> частыми обрывами.не готов, хотя swift, ceph, sheepdog и gluster тоже особой скоростью не отличаются. они собственно говоря и не для того придуманы, тут вся идея в масштабируемости и использовании локальных дисков с кучи хостов. если нужна еще и скорость, то надо поднимать инфраструктуру посерьезнее гигабитной сети, как впрочем и с обычным SAN
"Запись архива на 70МБ идет со скоростью 140Кб/сек"Это неоправданно низкая скорость на любой сети.
> "Запись архива на 70МБ идет со скоростью 140Кб/сек"
> Это неоправданно низкая скорость на любой сети.несомненно
чем это лучше PohmelFS ? :-/
> чем это лучше PohmelFS ? :-/Тем, что оно хотя бы живо?
пока в проекте "живо" - лишь бодро-написанный/выглядящий веб-сайт, очень любимого амер. правительственными/разведываетльными огранизациями, облика/функциональности.
Подскажите, а на чем лучше строить отказоустойчивый бекенд? Скажем, есть 4 сервера с веб-контентом, которые лоадбалансятся. Контент,в основном,мелкие файлы.
Чем лучше синхронизировать такой контент?Gluster?NFS?
если контент статический, то лучше rsynс'ать.
> если контент статический, то лучше rsynс'ать.как это будет выглядеть при, скажем, 2млн файлов на каждой машине ?
решение с БД и выгрузкой в статику (например по крону) и то выглядит сильно менее корявым.
нужно смотреть по факту, может быть хреново. Вариант с выгрузкой из БД очень даже хорош (~ строим очередь обновлений + на каждой машине докатываем новые файлы), но его же кодить нужно, хоть и не много.
> нужно смотреть по факту, может быть хреново. Вариант с выгрузкой из БД
> очень даже хорош (~ строим очередь обновлений + на каждой машине
> докатываем новые файлы), но его же кодить нужно, хоть и не
> много.да банальная проверка тем же ngx на наличие файла + обработчик 404 ошибки, который сходит в БД и покладет картинку куда нужно. это даже лучше чем cron, к примеру
Это уже хуже, будут задержки и из-за внезапного наплыва пользователей может быть временами очень плохо.
> Это уже хуже, будут задержки и из-за внезапного наплыва пользователей может быть
> временами очень плохо.ну значит AI должен быть чуть лучше, в зав-ти от фазы луны генерить статику и отдавать ее, либо ходить за ней в бд.
в прошлом комменте я затупил про 404, есть же try_files :)
Gluster генерирует очнь много вспомогательно траффика. На 100 Mb трафика gluster снегерит ещё 200 служебного
DRBD поможет?
Если это чистый вэб, то лучше использовать объектное хранилище (s3 подобное). Вариантов тут много:
dogsheep, ceph, яндекс пиарит свой Elliptics, swift (его многие считают нестабильным).
Если очень нужен posix, то наверное стоит посмотреть на moosefs.
На glaster на продакшене многие ругаются.
drdb
