Доступен (http://blog.gluster.org/2015/05/glusterfs-3-7-0-has-been-rel... релиз распределенной файловой системы GlusterFS 3.7 (http://www.gluster.org/), позволяющей организовать работу распределённого на несколько узлов хранилища, развёртываемого поверх штатных POSIX ФС, таких как Ext4, XFS и Btrfs, с использованием механизма FUSE (ФС в пользовательском пространстве). GlusterFS предоставляет средства автоматического восстановления после сбоев и обеспечивает практически неограниченную масштабируемость, благодаря отсутствию привязки к централизованному серверу мета-данных (используются распределённые хэш-таблицы).
По сравнению с прошлым выпуском в GlusterFS 3.7 закрыто более 600 отчётов об ошибках и принято 1220 патчей. Готовые для установки бинарные пакеты с GlusterFS 3.5 подготовлены (http://download.gluster.org/pub/gluster/glusterfs/3.7/3.7.0/) для Fedora, RHEL, CentOS, Debian, openSUSE, SLES и Ubuntu. Новый выпуск будет по умолчанию поставляться в ожидаемом на следующей неделе релизе Fedora 23.Основные новшества (https://github.com/gluster/glusterfs/blob/release-3.7/doc/re...:
- Реализована (http://www.gluster.org/community/documentation/index.php/Fea... техника выявления скрытых дисковых ошибок, приводящих к повреждению хранимых данных без индикации наличия проблемы со стороны диска и драйверов. Техника выявления подобных проблем (BitRot Detection) основана на использовании цифровых подписей для всех файлов и объектов с их периодической фоновой проверкой.- Использование (http://www.gluster.org/community/documentation/index.php/Fea... многопоточного варианта обработки событий от epoll, при котором запускается несколько обработчиков очередей epoll. Ускорение обработки ввода/вывода при таком подходе наиболее заметно при выполнении операций с большим числом мелких файлов.
- Экспериментальная возможность (http://www.gluster.org/community/documentation/index.php/Fea... определения правил для многоуровневого размещения файлов, при котором файлы размещаются по разделам не случайным образом, а в соответствии с определённой закономерностью. В дальнейшем, механизм послужит основой для создания механизма классификации данных, при котором данные смогут размещаться с учётом их локальной востребованности.
- Механизм Trashcan (http://www.gluster.org/community/documentation/index.php/Fea... позволяющий организовать временное сохранение удалённых файлов в отдельной области с их автоматическим удалением после истечения заданного времени.
- Поддержка (https://github.com/gluster/glusterfs/blob/master/doc/feature... задания квот на i-node, которая появилась благодаря новой эффективной системе подсчёта числа объектов/файлов в директориях
и разделах, реализованной через хранение счётчика в расширенных атрибутах директории.
- Поддержка экспорта разделов через NFSv4, NFSv4.1 и pNFS. В NFSv3-сервере добавлена (http://www.gluster.org/community/documentation/index.php/Fea... возможность применения Linux-модели экспорта и аутентификации по группам, что позволяет администратору ограничить определённым клиентам и группам доступ к экспортируемым через NFSv3 разделам и поддиректориям.
- Добавлена новая утилита GlusterFind (https://github.com/gluster/glusterfs/blob/release-3.7/doc/to... при помощи которой можно отслеживать связанные с данными события, например, для выявления модификации файлов.
- Увеличена (http://www.gluster.org/community/documentation/index.php/Fea... производительность операции ребалансировки хранилища за счёт ускорения идентификации файлов, требующих перемещения, и организации их переноса в многопоточном режиме.
- Возможность (http://www.gluster.org/community/documentation/index.php/Fea... создания снапшотов по расписанию.
- Экспериментальная поддержка (http://www.gluster.org/community/documentation/index.php/Fea... шардинга, позволяющего решить проблемы с фрагментацией дискового пространства за счёт хранения файлов большого размера в виде цепочки связанных друг с другом блоков, размер которых определяется в настройках.
- Использование механизма RCU (http://en.wikipedia.org/wiki/Read-copy-update) (Read-copy-update) для синхронизации нитей glusterd и организации доступа к важным секциям.URL: http://blog.gluster.org/2015/05/glusterfs-3-7-0-has-been-rel.../
Новость: http://www.opennet.me/opennews/art.shtml?num=42257
Кто нибудь использует в продакшене сие? Как будет работать на медленных каналах? И кстати как решаются конфликты: например два пользователя с небольшой задержкой изменяют файлы на двух распределенных серверах...
Года полтора назад пробовал, тупит и сильно грузит проц
Пытались использовать в связке с qemu-kvm для хранения томов ВМ. В качестве транспорта был использован rdma (InfiniBand). Как только начиналась нагрузка - начинали сыпаться ошибки IO. Причем нестабильно, иногда были иногда нет. По ethernet 1gb года 2-3 уже исошники инсталляционные синхронизирует между кучкой машин без проблем, но там редко что-то менается. Так что выходит что-то там работает, что-то нет :) Все надо щупать самому.
Используем в продакшене несколько хранилищ на Gluster (сотни терабайт).
Если ничего не трогать в ФС бриков и не добавлять или удалять брики — работает на приём и на отдачу хорошо. Не дай бог, если что-то произошло с FS или отвалился брик, а в это время юзер что-то записал на оставшеся — всё, начинаются проблемы. Кошмаром для админов будет состояние split brain.> Как будет работать на медленных каналах?
Огромной проблемой является листинг каталогов (DHT феерически тормозит). Листинг каталога в несколько тысяч файлов через WAN превратится для ваших пользователей в мучительный процесс с неизвестным исходом. Оно то и через LAN тормозит не меньше.
Хочется перейти на что-то более вменяемое. Но вот буквально сегодня тестировал Ceph Hammer в 3-хнодовой конфигурации. По питанию рубанул два узла. Один OSD (хранилище) не поднялся по причине порчи журнального файла. И пока вручную не скажешь, что отсутствие одного OSD — это нормально, ввод-вывод на всё хранилище замораживается. По поводу восстановления журнального файла разработчики предлагают с помощью какой-то утилитки из бета-версии (testing) вручную вытягивать сотни Placement Groups. Затем убивать хранилище, создавать новое, с новым журналом, и заполнять его сохранёнными Placement Group-ами на свой страх и риск. — Ну, это не на много лучше ада с gfid-ами в Gluster.
Ceph можно изначально сконфигурировать (или потом) на предмет работы в degraded-состоянии.
И, да, три узла - это ни о чём. Ну и отсутствие бесперебойника может "Убить" любую FS при определённом стечении обстоятельств. А при чётном количестве мониторов и у Ceph может случиться раздвоение личности...
> Ceph можно изначально сконфигурировать (или потом) на
> предмет работы в degraded-состоянии.Указано было в конфиге:
osd pool default min size = 1> три узла - это ни о чём
Для тестирования достаточно.
> отсутствие бесперебойника может "Убить" любую FS при определённом стечении обстоятельств
С FS всё нормально. Накрылся журнальный файл OSD во время самовосстановления. OSD вываливается по Assertion failure через некоторое время после запуска.
Хм, видимо сыроват, гонял 0.87 - на подобное не нарывался. А какой дистр использовался и откуда ставился ceph?
А какой дистр использовался и откуда ставился ceph?CentOS 7.1.1503.
Ceph Hammer устанавливался по документации из репозитария ceph.com.
У нас уже года 2 кластер ceph где-то 150 терабайт по-моему. Точно не помню. Нужно делить на 4 потому что 4 копии хранятся (по 2 на датацентр).
Вроде ничего. Проблемы только когда IO/s от клиентов превышают возможность кластера (чего нужно избегать и расширять или улучшать кэширующий слой преждевременно).
Ceph FS еще не готов, хотя в ограниченом виде мы его используем тоже. В принципе, года через 1.5 возможно можно будет использовать. Но, опять же, это для ленивых или Windows по сути. Программно без файловой системы через S3 например вполне все хорошо работает.
> У нас уже года 2 кластер ceph где-то 150 терабайт по-моему. Точно
> не помню. Нужно делить на 4 потому что 4 копии хранятся
> (по 2 на датацентр).
> Вроде ничего. Проблемы только когда IO/s от клиентов превышают возможность кластера (чего
> нужно избегать и расширять или улучшать кэширующий слой преждевременно).
> Ceph FS еще не готов, хотя в ограниченом виде мы его используем
> тоже. В принципе, года через 1.5 возможно можно будет использовать. Но,
> опять же, это для ленивых или Windows по сути. Программно без
> файловой системы через S3 например вполне все хорошо работает.Я имел ввиду ceph с самого начала.
"Кто-нибудь"
На паре десятков миллионов мелких файлов живет очень медленно.
> Кто нибудь использует в продакшене сие? Как будет работать на медленных каналах?
> И кстати как решаются конфликты: например два пользователя с небольшой задержкой
> изменяют файлы на двух распределенных серверах...На гигабите живёт на грани приемлемого, потому лучше бы поиметь десяточку или воспользоваться пондингом, в интернетах пишут, что отличается от ceph и hdfs способностью отдать по сети 100гигабит в секунду, тормоза возникают только при доступе к метаданным фс. Медленнные каналы — не для распределённой фс, но по ним кое-как можно заставить работать гео-репликацию. Конфликты решаются блокировками, как и везде.
> воспользоваться бондингомбыстрофикс
Вообще 3.4 работала очень неплохо. 3.7 обещает быть очень вкусной, надо тестить. Конфликты не решаются никак - синхронное хранилище, соответственно на медленных каналах будет задница.
> И кстати как решаются конфликты: например два пользователя с небольшой задержкой изменяют файлы на двух распределенных сервераха если бы этот файл хранился бы на локальной файловой системе (ext4 например) -- и два пользователя бы примерно-одновременно его меняли бы его -- то как разрешился бы этот конфликт? :-)
> Кто нибудь использует в продакшене сие? Как будет работать на медленных каналах?Я думаю таких чудаков в продакшене нет.
Последний раз когда тестировал гластер, скорость была ужасающе низкой.
Но тема очень перспективная.
У нас на glasterfs живут/жили в продакшене данные нескольких puppet мастеров и была организована копия мастер-ноды хадупа. Проблем не было
> У нас на glasterfs живут/жили в продакшене данные нескольких puppet мастеров и
> была организована копия мастер-ноды хадупа. Проблем не было"По сравнению с прошлым выпуском в GlusterFS 3.7 закрыто более 600 отчётов об ошибках"
>> У нас на glasterfs живут/жили в продакшене данные нескольких puppet мастеров и
>> была организована копия мастер-ноды хадупа. Проблем не было
> "По сравнению с прошлым выпуском в GlusterFS 3.7 закрыто более 600 отчётов
> об ошибках"Ошибка ошибке рознь (С)
...А сколько открыто...
> Я думаю таких чудаков в продакшене нет.
> Последний раз когда тестировал гластер, скорость была ужасающе низкой.Да ладно, я его под большой кластер вебморды личного кабинета юзерам и под хранилку конфигов+записей разговоров юзал - причём через fuse заметно шустрее NFS на мелочи.
Единственный нюанс - сырое слегонца. Особенно в части блокировок. Сессии и почту на нём лучше не хранить.
Работает и в продакшн варианте, в одной сети живут 5 инсталляций. 45 терабайт видео и картинок вполне себе существуют уже 3 год как. Да, медленно листаются каталоги и поиск медленно происходит, но если знаешь полный путь то все работает на ура. С восстановлением в случае сбоев танцевать приходится, но в остальном все хорошо, легко и дёшево!
> 45 терабайт видео и картинокРаспределенный архив порнухи студенческого кампуса? Круто!!!