Спустя три года с момента первого релиза (http://www.opennet.me/opennews/art.shtml?num=15561) сетевой распределённой файловой системы POHMELFS в списке рассылки разработчиков ядра Linux представлен (https://lkml.org/lkml/2011/12/23/161) полностью переработанный вариант данной ФС, в котором реализовано большинство из всех запланированных ранее возможностей. Код проекта распространяется под лицензией GPLv2.Новая реализация POHMELFS базируется на распределённом хранилище Elliptics (http://www.ioremap.net/projects/elliptics), представляющем собой (http://www.elliptics.ru/node/3) распределённую хэш таблицу. Изначально Elliptics развивался как часть POHMELFS, но два года назад был выделен в отдельный проект, который успешно используется в промышленной эксплуатации. Например, Elliptics используется для организации хранения около петабайта контента в сервисах компании Yandex (карты, фотографии, музыка). Хранилище рассчитано на организацию надёжного хранения большого объема данных в форм...
URL: http://www.ioremap.net/node/529
Новость: http://www.opennet.me/opennews/art.shtml?num=32667
о, восставший из пепла..
Автор уже четвертый день как Россию покинул, а тут такая новость:):)
Насовсем?
Не, так на лыжах покататься.
Решили под новогоднюю релевантность попасть?Вспоминается история с libsexy.rpm и dcpp.
Чем оно отличается от Tahoe-LAFS
Чё минусуете то, объяснить не в состоянии? Я по существу спросил, ибо интересно и действительно не знаю.
минусуют за то что сам не хочешь разбираться.
зайди прочти про POHMELFS в чём плюсы и минусы и сравни Tahoe-LAFS
а тебя за что минусуют
троллей не любят:)
во человек работает )
Мои поздравления. Как только она появилась в ядре в первый раз она меня сразу заинтересовала. Удачи проекту!
>"автоматическое восстановление сбоев"Сильная вещь! Т.е. если один раз сбойнет, то ремонтировать бесполезно...
Да не, просто многократное резервирование. Помер один из узлов? Да и хрен с ним!
Очевидно, соль шутки вы не уловили.
помер один из узлов - и кластер 3е суток синкает данные на востановленную ноду
Afs?
Я так понимаю прямой конкурент GlusterFS
Или ceph
Я думал GlusterFS -- это поверх существующих ФС. Я ошибкался?
Так и есть, но я смотрю по задаче - обеспечение отказоустойчивого хранилища(типа сетевого raid1), способного к клиентам цепляться как posix-фс
Конечно поверх ФС удобнее - можно, например, сканировать для анализа на контентных серверах локально, что будет быстрее чем через шластер, даже локально примонтированного
Этот Elliptics в юзерспейсе работает?
Вообще, что именно из всего этого комплекса реализовано на уровне ядра?
Как потестировать/посмотреть на это в убунте?
Оно уже перестало давать kernel panic при записи?
> Оно уже перестало давать kernel panic при записи?Спросите у админов Яндекса.
кто-нибудь применяет у себя в продакшн?
кроме Яндекса возможно никто.
откуда дровишки? на тестовых окружениях еще может быть но в продакшене не поверю.
> откуда дровишки? на тестовых окружениях еще может быть но в продакшене не поверю.Очевидно, новости вы не читали, сразу обсуждать бросились :D
>> откуда дровишки? на тестовых окружениях еще может быть но в продакшене не поверю.
> Очевидно, новости вы не читали, сразу обсуждать бросились :Dв блоге коментарий - "что-то никто не пишет сюда, и в lkml нету движухи"
Видимо оно так всем надо.
> в блоге коментарий - "что-то никто не пишет сюда, и в lkml нету движухи"
> Видимо оно так всем надо.Не, они просто еще читают и осмысливают. Не то что здешние - прочитали только заголовок (и то наискосок), и уже бегом обсуждать.
некоторые "местные" указывали автору на узкие места - а автор отмахивался - "мне так удобно и идите вон".Кстати - он до сих пор не дает читать и писать в конец файла одновременно?
frontend - внешний интерфейс. Зачем плодить лишние сущности?
какой смешной метод повышения отказо устойчивости.
надо будет послушать как у них будет ложиться сеть когда одна из нод умрет и все начнет синхронизироваться по сети.. ;-)
Видимо пока живет - пока ноды не умирали - или нагрузка в сети меньше 20% от пропускной :)а вообще попытка сделать новый map-reduce ;-)
> какой смешной метод повышения отказо устойчивости.Вас послушать - так они все смешные, а отказоустойчивость - это миф.
>какой смешной метод повышения отказо устойчивости.надо будет послушать как у них будет ложиться сеть когда одна из нод умрет и все начнет синхронизироваться по сети.. ;-)
Оптимизируют и это...
> надо будет послушать как у них будет ложиться сеть когда одна из
> нод умрет и все начнет синхронизироваться по сети.. ;-)Обычно в таких системах репликация данных делается заранее. Поэтому вылет узла тупо не заметен как класс. Или вы думаете что в ынтырпрайзе типа гугла или хотя-бы яндекса сервера никогда не ломаются? Агащаз, для большого ынтырпрайза вылет сервера - почти штатное событие. Если у вас есть миллион дисков - вы только и будете делать что заменять полетевшие. А если у вас их только 10, то может и за 5 лет ни 1 не замените. Чисто теория вероятности работает.
аха. было 3 реплики - вылетела 1 нода, стало 2, потом еще одна, осталась последная..
и что вы хотите сказать что эта система в отличии от Gluster (или ceph я их путаю) - не востанавливает количество реплик до заданного?
То есть не запускает режим востановления содержимого ноды аналогичного raid rebuild ?учитывая что сейчас 120T на ноду это нормально - я хотел бы послушать оценки - как долго 120T будут синхронизироваться с других нод по сети ;-) А значит - как долго кластер будет тормозить.
>>какой смешной метод повышения отказо устойчивости.
> надо будет послушать как у них будет ложиться сеть когда одна из
> нод умрет и все начнет синхронизироваться по сети.. ;-)
> Оптимизируют и это...А, собственно, в чем проблема? Во-первых, если точность / согласованность данных не сильно важна (как в случае с я.картами), то можно держать 3 реплики, при этом на чтение требовать только одну. Таким образом вылет 2 из 3х дисков для нас останется безболезненным. Ну и синхронизироваться никто никуда не будет при вылете, просто новый диск надо будет вставить.
А синхронизация нужна именно при удалении ноды из кластера (когда кластер уменьшать собираемся), или же при росте кластера (что тоже не так уж часто нужно).
>>>какой смешной метод повышения отказо устойчивости.
>> надо будет послушать как у них будет ложиться сеть когда одна из
>> нод умрет и все начнет синхронизироваться по сети.. ;-)
>> Оптимизируют и это...
> А, собственно, в чем проблема? Во-первых, если точность / согласованность данных не
> сильно важна (как в случае с я.картами), то можно держать 3
> реплики, при этом на чтение требовать только одну. Таким образом вылет
> 2 из 3х дисков для нас останется безболезненным. Ну и синхронизироваться
> никто никуда не будет при вылете, просто новый диск надо будет
> вставить.Да да. raid запускает в этот момент rebuild - вы не знали об этом?
так и тут - надо востановить требуемую избыточность - что бы при следующем вылете дисков не остаться вообще без данных.
Вот и вопрос - сколько ж будет напрягаться кластер при вылете одной из нод объемом 100T?
и учтите - кластер начнет терять в производительности пока идет синхронизация и восстановление содержимого ноды..
скорость синхронизации дозируется (добавление ноды производят в период наименьшей нагрузки) и никакого конца света не будет
> скорость синхронизации дозируется (добавление ноды производят в период наименьшей нагрузки)
> и никакого конца света не будетну да. осталось узнать когда это наименьшая нагрузка - и прикинуть что 120T будет писаться дня 3-4 на full time - а если "дозированно" то это будут недели, а за это время еще одна нода может сдохнуть - или не давать требуемой скорости.
Так что конец света или не конец - но дизаин кривой.
> надо будет послушать как у них будет ложиться сеть когда одна из
> нод умрет и все начнет синхронизироваться по сети.. ;-)ну почему ложится? новая нода получает свои стопятьсот терабайт от _многих_ нод хранища. то что новая нода не сможет отвечать сама не критично, а для остальных это появление всего одного дополнительного клиента.
свичи куда включены ноды обычно пропускают по своей шине полный суммарный трафик своих портов без проблем.
>> надо будет послушать как у них будет ложиться сеть когда одна из
>> нод умрет и все начнет синхронизироваться по сети.. ;-)
> ну почему ложится? новая нода получает свои стопятьсот терабайт от _многих_ нод
> хранища. то что новая нода не сможет отвечать сама не критично,
> а для остальных это появление всего одного дополнительного клиента.потому что - эти ноды они того... тоже бывают загружены - и с них забирают данные.
То есть загружать 120Т будут неделями. за это время может сдохнуть еще одна копия и....> свичи куда включены ноды обычно пропускают по своей шине полный суммарный трафик
> своих портов без проблем.Зато диски у "других" нод - имеют конечную пропускную способность. Которую почему-то все хотят израсходовать. А тут еще сливать копию потеряных реплик куда-то.
Не первый раз слышу об этой файловой системе. Но за название зачёт. Не что, что XEP от Apache :)
Да ты что, наш делает, Поляков, Евгений вроде...
Придумал с бадуна, потом придумал культурную расшифровку.
Скорее наоборот. Алкогольно-наркоманский "юмор". Вообще, алкогольная тематика в интеллектуальной среде - это оксюморон.
> Скорее наоборот. Алкогольно-наркоманский "юмор". Вообще, алкогольная тематика в интеллектуальной
> среде - это оксюморон.Да, настоящий интеллектуал должен всегда ходить в черном смокинге с похоронным выражением лица, и любой юмор презрительно называть "оксюмороном" (или "рододендроном", как раница, все равно никто не поймет).