The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Выпуск распределенной файловой системы GlusterFS 3.7

19.05.2015 10:59

Доступен релиз распределенной файловой системы GlusterFS 3.7, позволяющей организовать работу распределённого на несколько узлов хранилища, развёртываемого поверх штатных POSIX ФС, таких как Ext4, XFS и Btrfs, с использованием механизма FUSE (ФС в пользовательском пространстве). GlusterFS предоставляет средства автоматического восстановления после сбоев и обеспечивает практически неограниченную масштабируемость, благодаря отсутствию привязки к централизованному серверу мета-данных (используются распределённые хэш-таблицы).

По сравнению с прошлым выпуском в GlusterFS 3.7 закрыто более 600 отчётов об ошибках и принято 1220 патчей. Готовые для установки бинарные пакеты с GlusterFS 3.7 подготовлены для Fedora, RHEL, CentOS, Debian, openSUSE, SLES и Ubuntu. Новый выпуск будет по умолчанию поставляться в релизе Fedora 23.

Основные новшества:

  • Реализована техника выявления скрытых дисковых ошибок, приводящих к повреждению хранимых данных без индикации наличия проблемы со стороны диска и драйверов. Техника выявления подобных проблем (BitRot Detection) основана на использовании цифровых подписей для всех файлов и объектов с их периодической фоновой проверкой.
  • Использование многопоточного варианта обработки событий от epoll, при котором запускается несколько обработчиков очередей epoll. Ускорение обработки ввода/вывода при таком подходе наиболее заметно при выполнении операций с большим числом мелких файлов.
  • Экспериментальная возможность определения правил для многоуровневого размещения файлов, при котором файлы размещаются по разделам не случайным образом, а в соответствии с определённой закономерностью. В дальнейшем, механизм послужит основой для создания механизма классификации данных, при котором данные смогут размещаться с учётом их локальной востребованности.
  • Механизм Trashcan, позволяющий организовать временное сохранение удалённых файлов в отдельной области с их автоматическим удалением после истечения заданного времени.
  • Поддержка задания квот на i-node, которая появилась благодаря новой эффективной системе подсчёта числа объектов/файлов в директориях и разделах, реализованной через хранение счётчика в расширенных атрибутах директории.
  • Поддержка экспорта разделов через NFSv4, NFSv4.1 и pNFS. В NFSv3-сервере добавлена возможность применения Linux-модели экспорта и аутентификации по группам, что позволяет администратору ограничить определённым клиентам и группам доступ к экспортируемым через NFSv3 разделам и поддиректориям.
  • Добавлена новая утилита GlusterFind, при помощи которой можно отслеживать связанные с данными события, например, для выявления модификации файлов.
  • Увеличена производительность операции ребалансировки хранилища за счёт ускорения идентификации файлов, требующих перемещения, и организации их переноса в многопоточном режиме.
  • Возможность создания снапшотов по расписанию.
  • Экспериментальная поддержка шардинга, позволяющего решить проблемы с фрагментацией дискового пространства за счёт хранения файлов большого размера в виде цепочки связанных друг с другом блоков, размер которых определяется в настройках.
  • Использование механизма RCU (Read-copy-update) для синхронизации нитей glusterd и организации доступа к важным секциям.


  1. Главная ссылка к новости (http://blog.gluster.org/2015/0...)
  2. OpenNews: Для развития GlusterFS сформирован независимый управляющий совет
  3. OpenNews: Red Hat покупает компанию-разработчика распределенной файловой системы GlusterFS
  4. OpenNews: Вышел релиз кластерной файловой системы GlusterFS 2.0
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/42257-glusterfs
Ключевые слова: glusterfs
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (24) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 11:32, 19/05/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Кто нибудь использует в продакшене сие? Как будет работать на медленных каналах? И кстати как решаются конфликты: например два пользователя с небольшой задержкой изменяют файлы на двух распределенных серверах...
     
     
  • 2.10, manefesto (??), 13:27, 19/05/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Года полтора назад пробовал, тупит и сильно грузит проц
     
  • 2.11, Vee Nee (?), 13:51, 19/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Пытались использовать в связке с qemu-kvm для хранения томов ВМ. В качестве транспорта был использован rdma (InfiniBand). Как только начиналась нагрузка - начинали сыпаться ошибки IO. Причем нестабильно, иногда были иногда нет. По ethernet 1gb года 2-3 уже исошники инсталляционные синхронизирует между кучкой машин без проблем, но там редко что-то менается. Так что выходит что-то там работает, что-то нет :) Все надо щупать самому.
     
  • 2.12, Demo (??), 14:21, 19/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Используем в продакшене несколько хранилищ на Gluster (сотни терабайт).
    Если ничего не трогать в ФС бриков и не добавлять или удалять брики — работает на приём и на отдачу хорошо. Не дай бог, если что-то произошло с FS или отвалился брик, а в это время юзер что-то записал на оставшеся — всё, начинаются проблемы. Кошмаром для админов будет состояние split brain.

    > Как будет работать на медленных каналах?

    Огромной проблемой является листинг каталогов (DHT феерически тормозит). Листинг каталога в несколько тысяч файлов через WAN превратится для ваших пользователей в мучительный процесс с неизвестным исходом. Оно то и через LAN тормозит не меньше.

    Хочется перейти на что-то более вменяемое. Но вот буквально сегодня тестировал Ceph Hammer в 3-хнодовой конфигурации. По питанию рубанул два узла. Один OSD (хранилище) не поднялся по причине порчи журнального файла. И пока вручную не скажешь, что отсутствие одного OSD — это нормально, ввод-вывод на всё хранилище замораживается. По поводу восстановления журнального файла разработчики предлагают с помощью какой-то утилитки из бета-версии (testing) вручную вытягивать сотни Placement Groups. Затем убивать хранилище, создавать новое, с новым журналом, и заполнять его сохранёнными Placement Group-ами на свой страх и риск. — Ну, это не на много лучше ада с gfid-ами в Gluster.

     
     
  • 3.15, Аноним (-), 16:19, 19/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Ceph можно изначально сконфигурировать (или потом) на предмет работы в degraded-состоянии.
    И, да, три узла - это ни о чём. Ну и отсутствие бесперебойника может "Убить" любую FS при определённом стечении обстоятельств. А при чётном количестве мониторов и у Ceph может случиться раздвоение личности...
     
     
  • 4.18, Demo (??), 19:25, 19/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Ceph можно изначально сконфигурировать (или потом) на
    > предмет работы в degraded-состоянии.

    Указано было в конфиге:
    osd pool default min size = 1

    > три узла - это ни о чём

    Для тестирования достаточно.

    > отсутствие бесперебойника может "Убить" любую FS при определённом стечении обстоятельств

    С FS всё нормально. Накрылся журнальный файл OSD во время самовосстановления. OSD вываливается по Assertion failure через некоторое время после запуска.

     
     
  • 5.19, тот же самый (?), 21:00, 19/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Хм, видимо сыроват, гонял 0.87 - на подобное не нарывался. А какой дистр использовался и откуда ставился ceph?
     
     
  • 6.27, Demo (??), 11:48, 21/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    А какой дистр использовался и откуда ставился ceph?

    CentOS 7.1.1503.
    Ceph Hammer устанавливался по документации из репозитария ceph.com.

     
  • 3.24, mrd (??), 23:39, 19/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    У нас уже года 2 кластер ceph где-то 150 терабайт по-моему. Точно не помню. Нужно делить на 4 потому что 4 копии хранятся (по 2 на датацентр).
    Вроде ничего. Проблемы только когда IO/s от клиентов превышают возможность кластера (чего нужно избегать и расширять или улучшать кэширующий слой преждевременно).
    Ceph FS еще не готов, хотя в ограниченом виде мы его используем тоже. В принципе, года через 1.5 возможно можно будет использовать. Но, опять же, это для ленивых или Windows по сути. Программно без файловой системы через S3 например вполне все хорошо работает.
     
     
  • 4.25, mrd (??), 23:40, 19/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > У нас уже года 2 кластер ceph где-то 150 терабайт по-моему. Точно
    > не помню. Нужно делить на 4 потому что 4 копии хранятся
    > (по 2 на датацентр).
    > Вроде ничего. Проблемы только когда IO/s от клиентов превышают возможность кластера (чего
    > нужно избегать и расширять или улучшать кэширующий слой преждевременно).
    > Ceph FS еще не готов, хотя в ограниченом виде мы его используем
    > тоже. В принципе, года через 1.5 возможно можно будет использовать. Но,
    > опять же, это для ленивых или Windows по сути. Программно без
    > файловой системы через S3 например вполне все хорошо работает.

    Я имел ввиду ceph с самого начала.

     
  • 2.13, GrammarNarziss (?), 15:20, 19/05/2015 [^] [^^] [^^^] [ответить]  
  • –2 +/
    "Кто-нибудь"
     
  • 2.14, Аноним (-), 16:07, 19/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    На паре десятков миллионов мелких файлов живет очень медленно.
     
  • 2.16, Аноним (-), 17:59, 19/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Кто нибудь использует в продакшене сие? Как будет работать на медленных каналах?
    > И кстати как решаются конфликты: например два пользователя с небольшой задержкой
    > изменяют файлы на двух распределенных серверах...

    На гигабите живёт на грани приемлемого, потому лучше бы поиметь десяточку или воспользоваться пондингом, в интернетах пишут, что отличается от ceph и hdfs способностью отдать по сети 100гигабит в секунду, тормоза возникают только при доступе к метаданным фс. Медленнные каналы — не для распределённой фс, но по ним кое-как можно заставить работать гео-репликацию. Конфликты решаются блокировками, как и везде.

     
     
  • 3.17, Аноним (-), 18:01, 19/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > воспользоваться бондингом

    быстрофикс

     
  • 2.20, AlexAT (ok), 21:09, 19/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Вообще 3.4 работала очень неплохо. 3.7 обещает быть очень вкусной, надо тестить. Конфликты не решаются никак - синхронное хранилище, соответственно на медленных каналах будет задница.
     
  • 2.22, Xasd (ok), 21:25, 19/05/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > И кстати как решаются конфликты: например два пользователя с небольшой задержкой изменяют файлы на двух распределенных серверах

    а если бы этот файл хранился бы на локальной файловой системе (ext4 например) -- и два пользователя бы примерно-одновременно его меняли бы его -- то как разрешился бы этот конфликт? :-)

     

  • 1.3, Shodan (ok), 12:36, 19/05/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > Кто нибудь использует в продакшене сие? Как будет работать на медленных каналах?

    Я думаю таких чудаков в продакшене нет.
    Последний раз когда тестировал гластер, скорость была ужасающе низкой.
    Но тема очень перспективная.

     
     
  • 2.4, svr (?), 12:48, 19/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    У нас на glasterfs живут/жили в продакшене данные нескольких puppet мастеров и была организована копия мастер-ноды хадупа. Проблем не было
     
     
  • 3.5, Shodan (ok), 12:53, 19/05/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > У нас на glasterfs живут/жили в продакшене данные нескольких puppet мастеров и
    > была организована копия мастер-ноды хадупа. Проблем не было

    "По сравнению с прошлым выпуском в GlusterFS 3.7 закрыто более 600 отчётов об ошибках"

     
     
  • 4.7, Fomalhaut (?), 13:15, 19/05/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> У нас на glasterfs живут/жили в продакшене данные нескольких puppet мастеров и
    >> была организована копия мастер-ноды хадупа. Проблем не было
    > "По сравнению с прошлым выпуском в GlusterFS 3.7 закрыто более 600 отчётов
    > об ошибках"

    Ошибка ошибке рознь (С)

     
  • 4.9, Аноним (-), 13:17, 19/05/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ...А сколько открыто...
     
  • 2.21, AlexAT (ok), 21:10, 19/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Я думаю таких чудаков в продакшене нет.
    > Последний раз когда тестировал гластер, скорость была ужасающе низкой.

    Да ладно, я его под большой кластер вебморды личного кабинета юзерам и под хранилку конфигов+записей разговоров юзал - причём через fuse заметно шустрее NFS на мелочи.

    Единственный нюанс - сырое слегонца. Особенно в части блокировок. Сессии и почту на нём лучше не хранить.

     

  • 1.23, Аноним (-), 21:52, 19/05/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Работает и в продакшн варианте, в одной сети живут 5 инсталляций. 45 терабайт видео и картинок вполне себе существуют уже 3 год как. Да, медленно листаются каталоги и поиск медленно происходит, но если знаешь полный путь то все работает на ура. С восстановлением в случае сбоев танцевать приходится, но в остальном все хорошо, легко и дёшево!
     
     
  • 2.26, Аноним (-), 15:05, 20/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > 45 терабайт видео и картинок

    Распределенный архив порнухи студенческого кампуса? Круто!!!

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру