Сообщество Gluster объявило (http://www.gluster.org/2014/05/glusterfs-3-5-unveiled/) о выходе распределенной файловой системы GlusterFS 3.5 (http://www.gluster.org/), позволяющей организовать работу распределённого на несколько узлов хранилища, развёртываемого поверх штатных POSIX ФС, таких как Ext4, XFS и Btrfs, с использованием механизма FUSE (ФС в пользовательском пространстве). GlusterFS предоставляет средства автоматического восстановления после сбоев и обеспечивает практически неограниченную масштабируемость, благодаря отсутствию привязки к централизованному серверу мета-данных (используются распределённые хэш-таблицы). Готовые для установки бинарные пакеты с GlusterFS 3.5 подготовлены (http://download.gluster.org/pub/gluster/glusterfs/3.5/3.5.0/) для Fedora, RHEL, CentOS, Debian, openSUSE, SLES и Ubuntu.Основные новшества (https://github.com/gluster/glusterfs/blob/release-3.5/doc/re...):
- Поддержка создания снапшотов отдельных файлов. С практической стороны данная возможность может быть востребована для создания снапшотов образов работающих виртуальных машин, что позволяет вернуть состояние виртуальной машины на момент в прошлом только силами GlusterFS без задействования дополнительных инструментов. В будущих выпусках ожидается поддержка создания снапшотов разделов;
- Возможность сжатия данных при передаче по сети, что позволяет сократить общую нагрузку на сеть при выполнении операций, инициированных клиентом. В зависимости от характера данных применение сжатия может существенно повысить производительность работы с разделами при незначительном увеличении нагрузки на CPU, особенно в ситуациях когда пропускная способность канала связи клиента является узким местом;- Поддержка шифрования данных дисковых разделов на стороне сервера с использованием ключей, доступных только клиенту. Шифруется только содержимое файлов, имена и метаданные остаются незашифрованными. Кроме того, шифрование не применимо при использовании NFS;
- Автоматическое обнаружение отказа отдельного хранилища (Brick Failure Detection);
- Увеличено качество ведения логов, добавлено отображение дополнительной статистики и указание причин возникновения тех или иных событий, а также данных о том, какие файлы затрагивают данные события;
- Новый метод прямого доступа к данным через GFID, позволяющий обратиться к данным в трансляторе изменений;
- Уход от необходимости перезапуска NFS-сервера при изменении параметров раздела;
- Расширение числа возможных конфигураций квот от нескольких сотен до 65536 для раздела;
- Поддержка упреждающего чтения (readdir_ahead) списка директорий для увеличения производительности последовательного чтения директорий;
- Поддержка операции zerofill для заполнения нулями новых образов виртуальных машин;
- Переработана архитектура системы геораспределённой репликации (Geo-Replication). Если раньше процесс репликации gsyncd выступал в качестве единой точки отказа, так как он запускался на одном узле кластера, выход которого из строя сулил прекращение geo-репликации, то в новой реализации репликация выполняется на всех узлах, обслуживающих раздел (каждый узел теперь отвечает за синхронизацию хранимых на нём данных). Для определения изменившихся файлов, для которых необходимо выполнить синхронизацию, теперь используется журнал изменений (changelog xlator). Кроме rsync добавлена поддержка нового метода синхронизации "tar+ssh", который может быть востребован в конфигурациях с большим числом мелких файлов.URL: http://www.gluster.org/2014/05/glusterfs-3-5-unveiled/
Новость: https://www.opennet.ru/opennews/art.shtml?num=39692
Хм...
>> Уход от необходимости перезапуска NFS-сервера при изменении параметров разделаА причём тут он? Простите, давно смотрю на сию поделку, но не в курсе тонкостей.
А вам ничего не говорит о том, что FS распределенная, а это делают через сеть?
FibreChannel? Не, не слышал.
> FibreChannel? Не, не слышал.Ну давай, протени FibreChannel через океан, морским кабелем.
И что в этом такого? wdm, tdm вещицы заказываешь у оператора и будет fc через океан.
> И что в этом такого? wdm, tdm вещицы заказываешь у оператора и
> будет fc через океан.Ты забыл уточнить сколько это будет стоить.
> Ты забыл уточнить сколько это будет стоить.Стоить будет не болше денег.
> Стоить будет не болше денег.Какое либо использование такого кабеля в сколь-нибудь явном виде будет стоить совершенно конских денег, в отличие от просто пинков пакетов через уже существующую инфраструктуру.
Не говоря о том что привязываться к местоположению такого кабеля для размещения инфраструктуры - бред собачий.
> И что в этом такого? wdm, tdm вещицы заказываешь у оператора и
> будет fc через океан.задержки, даже за деньги не уменьшишь, а если задержки большие, FC не сильно эффективен, соответственно его целесообразность под сомнением.
И где это написано - про связь задержек с неэффективностью fc?
> задержки, даже за деньги не уменьшишь, а если задержки большие, FC не
> сильно эффективен, соответственно его целесообразность под сомнением.Да что ты говоришь?
прикинь, да, такая ерунда, задержки мешают.
А расшифровать? Чему и как мешают. И как другим, не-fc вещичкам, эти задержки помогают.
задержки всем кровь портят, речь идёт о целесообразности использования FC на каналах с большими задержками, тут нужно каждый случай рассматривать отдельно.
> задержки всем кровь портят, речь идёт о целесообразности использования FC на каналах
> с большими задержками, тут нужно каждый случай рассматривать отдельно.Значит, у спутников на геостационарных орбитах пинг 10 секунд не портит кровь, а пара-тройка тысяч км через атлантику это пипец насколько больше геостационарной орбиты?
Мешки, тово, уже готовы, товарищ.
> Значит, у спутников на геостационарных орбитах пинг 10 секунд не портит кровь,Знаешь ли, протоколы разные бывают. Некоторые предпринимают специальные меры для сохранения приличной производительности даже при больших задержках, некоторые - нет.
Ну расскажи уже как эти задержки скажутся на fc.
не будет, у FC есть жёсткие ограничения на RTT, максимум это один ДЦ
у FC нет таких огрничений.
> у FC нет таких огрничений.А тут вопрос в реализации протокола - умеет ли он упреждающую отсылку с окнами без подтверждений или нет. Если не умеет - по мере роста RTT скорость просто скатится в cpaнoe гoвнo, да и все дела.
Понимаешь, если ты кидаешь данные на скорости 100500 гигабитов - это круто. Но если ты потом 200 мс ждешь ответа, средняя скорость будет отвратительной и более похожей на диалап. Работа на скоростном линке с большим пингом - отдельный раздел сетевых грабель, требующий некислого твикинга протоколов.
200ms это что? мобильная связь? FC over LTE? :))) трансатлантика < 80ms
так что соединить 2 ЦОДа на расстоянии 20-25 км не проблема, дальшечитать Buffer Credits, WAN optimization, FCIP WAN optimization, HyperIP, SANSlide, Brocade 7800 ну и так далее.
Про кредиты они и не слыхали. Зачем ты страусов такими словами пугаешь?
а ты не знаешь случайно, что nfs не распределённая fs? И она распределённости никак добавить не может ничему.
А вот тут рекомендую почитать про pNFS и заглянуть на http://www.pnfs.com/> а ты не знаешь случайно, что nfs не распределённая fs? И она
> распределённости никак добавить не может ничему.
Ты походу ваще не в курсе как оно работает. Ты точно !!!ДАВНО111 смотришь на эту, как ты выразился, поделку?
Она умеет экспортироваться по NFS.
Кст, спасибо редактору за превращение коротенькой заметки в полнотекстовую новость.
Ceph круче, точка.
> Ceph круче, точка.это другой подход. и скорее всего скоро их объединят в один продукт, где можно выбирать то как оно будет работать
> Ceph кручеЧем?
Чем GlusterFS
Скоростью как минимум. Архитектура лучше, перспективы гораздо лучше. Не зря редхатовцы его выкупили, а не сделали ставку на свой glusterfs
Глустер имеет фатальный недостаток, система распределяет запись файлов не учитывая размер файла и размер хранилища, тупо пихает последовательно на каждую ноду. В итоге хранилища на нодах забиваются неравномерно и нужно следить сторонними средствами за забитостью винтов и подпихивать новые объемы. Перераспределить данные нельзя, так как в названии файла хэшируется путь к нему, тоесть нода на которой лежит файл.
> Глустер имеет фатальный недостаток, система распределяет запись файлов не учитывая размер
> файла и размер хранилища, тупо пихает последовательно на каждую ноду. В
> итоге хранилища на нодах забиваются неравномерно и нужно следить сторонними средствами
> за забитостью винтов и подпихивать новые объемы. Перераспределить данные нельзя, так
> как в названии файла хэшируется путь к нему, тоесть нода на
> которой лежит файл.ребаланс не работает?
> ребаланс не работает?Типа работает, но работы его я не увидел.
>> Ceph круче
> Чем?глустер на операциях с метаданными медленный как чёрт знает что.
и это не лечится. вообще никак.
> глустер на операциях с метаданными медленный как чёрт знает что.
> и это не лечится. вообще никак.багрепорт есть?
> багрепорт есть?Багрепорты не спасают. Почитайте их список рассылки.
если backend-fs ext4 - то да
на reiserfs, zfs, xfs - быстрее в 100500 раз.
> на reiserfs, zfs, xfs - быстрее в 100500 раз.Поначалу кажется, что быстро, но при заполнении хранилища возвращаются старые тормоза.
> если backend-fs ext4 - то да
> на reiserfs, zfs, xfs - быстрее в 100500 раз.фс тут роли не играет.
на глустерной шаре:
for i in `seq 0 255`; do mkdir $i; done
for i in `seq 0 10`; do time ls; done
и вы увидите, что время за которое отрабатывает ls никак не меняется, т.к. ничего не кешируется.
глустер на каждый ls обходит все брики, получает содержимое каталогов и потом "склеивает" результаты. если сделать еще второй уровень каталогов, глустер превращается в тыкву, а find по такому дереву всегда выполняется минуты.
мне кажется использование не правильное.
в распределённых ФС потенциально миллиарды файлов и вызывать ls не стоит.к примеру у HadoopFS ограничение на количество файлов - размер оперативной памяти ответствееоного за метаданные узла. у GlusterFS как я понимаю такого ограничения нет.
> мне кажется использование не правильное.
> в распределённых ФС потенциально миллиарды файлов и вызывать ls не стоит.т.е. вот если в каталоге у нас 10 файлов, то всё, readdir() - низя?
и то, что тормознутость readdir() зависит от того, в каком каталоге вы это делаете - это вообще зачёт.
>т.е. вот если в каталоге у нас 10 файлов, то всё, readdir() - низя?можно. но если файлов так мало, то может распределённую фс делать не надо? можно конечно раскидывать по директориям,то как я понимаю Ceph будет лучше.
Я сам (да и не только я)в программах делаю так: в базе данных записи содержащие ссылки на файл(напимер картинки, видео), все файлы в одной директории. ls не нужно- вместо этого select с нужными критериями.
а если файлов в директории от сотен тысяч, то любая фс будет тормозить при ls, даже локальная
> Ceph круче, точка.Чем грузины?
Будущее за облаками!Скоро на планшете будет только маленькая быстрая клиентская часть ОС, а всё остальное будет подгружаться из специльной системы, соединяющей все компьютеры в мире, по мере необходимости с помощью специальных волн, распостраняющихся по воздуху, благодаря спутникам и башням с антеннами.
Облака ох как нужны тем кто хочет нас контролировать.
> Облака ох как нужны тем кто хочет нас контролировать.А прикинь как клево - США ввинчивают санкции, а у тебя получается бесполезный кирпич.
> А прикинь как клево - США ввинчивают санкции, а у тебя получается
> бесполезный кирпич.Санкции — хорошее лекарство от тупости ІТ-руководства.
Извините, но что значит "скоро"? У тех, кто хотел иметь копию чего бы там ни было на некотором сервере (обычно своём) - те уже давно это реализовали так или иначе. А вот идея "облака в массы" не так уж и хороша хотя бы потому, что люди явно не понимают, что вариант "за мной не будут следить, потому что неуловимый Джо" не канает, ибо роботы делают этот процесс прозрачным, простым и совершенно не отягощающим. Data Mining вообще страшная штука.
> Скоро на планшете будет только маленькая быстрая клиентская часть ОС, а всё
> остальное будет подгружаться из специльной системы, соединяющей все компьютеры в мире,...а при отпадении интернета, планшет будет превращаться в тыкву, даааа?
Так он и сейчас при отпадании инета в тыкву превращается, кучеры в мышей и тд.
У кого-то - в тыкву, а у кого-то - в читалку, и заодно плеер.
Вредно все время в интернете сидеть. Лучше книжки почитай, за одно ничего в тыкву превращаться не будет.
> Вредно все время в интернете сидеть. Лучше книжки почитай, за одно ничего
> в тыкву превращаться не будет.Оно и видно, как ты читаешь. "Заодно" пишется слитно. Эй, двумя Розенталями этого гаврика по вафлу!
он и так тыква, даже с интернетом
Всё тупое хомячьё, которое хотело подсесть на облако, уже это сделало. Лошарорынок в этом направлении больше расти не будет
> Будущее за облаками!
> Скоро на планшете будет только маленькая быстрая клиентская часть ОС, а всё
> остальное будет подгружаться из специльной системы, соединяющей все компьютеры в мире,
> по мере необходимости с помощью специальных волн, распостраняющихся по воздуху, благодаря
> спутникам и башням с антеннами.Мне лет десять тому назад что-то подобное похапэшники говорили.
у сабжа перед хаммерфс2, только одиен плюс - портируемость на линукс.
впрочем, скоро обоих - зарулит pohmelfs, скорее всего :-)
Ну и где он? Евгений судя по всему положил на это дело.
он заканчивает тестирование phomeliquid, пока.
коючевой компонент, на работу которого - будет завязано 60% функциональности будующих версия pohmelfs :)
> впрочем, скоро обоих - зарулит pohmelfs, скорее всего :-)Сразу после того, как фря окончательно выбьет линукс с серверов :)
>> впрочем, скоро обоих - зарулит pohmelfs, скорее всего :-)
> Сразу после того, как фря окончательно выбьет линукс с серверов :)стрекоза, если быть точным.
фряха хаммер2 не подымет по тем-же причинам, по каким у линукса поджилки слабоваты для, увы.
Вы его вживую новый видели?
А то они только на конфе говорили, что сделали поверх elliptics новый pohmelfs и пытались патчи в ядро протащить, но тесты у них не прошли (rsync mirror.yandex.ru загнулся на каталоге с симлинками).
Хотелось бы в виде модуля пощупать его, но что-то найти не могу