rgb000 2 мар 2015 в 14:37

Тестируем распределение контента в GlusterFS

11 мин

42K

Настройка Linux * Системное администрирование * Серверное администрирование *

+11

Комментарии 18

andvgal 2 мар 2015 в 17:58

Для тех, кто будет скоро обновляться с Debian wheezy до jessie с выходом последнего, будьте бдительны: GlusterFS 3.2 нельзя обновить до 3.5 «просто так».

Обязательно ознакомьтесь:

3.2 -> 3.3: vbellur.wordpress.com/2012/05/31/upgrading-to-glusterfs-3-3/
3.3 -> 3.4: vbellur.wordpress.com/2013/07/15/upgrading-to-glusterfs-3-4/
3.4 -> 3.5: www.gluster.org/community/documentation/index.php/Upgrade_to_3.5

script88 2 мар 2015 в 19:16

либо можно будет посидеть на 7 с lts репами :)

blind_oracle 3 мар 2015 в 16:25

А обещают ему LTS разве?

script88 3 мар 2015 в 17:46

Вообще, пишут что все зависит от успеха squeezy, если будет востребован, то будет LTS для wheezy и jessie

juffinhalli 2 мар 2015 в 19:13

Тогда и я добавлю до кучи (glusterfs-server 3.5.2-1): В случае если соединение между серверами содержащими replicated volume было какое-то отсутствовала, то произойдёт объединение содержимого brick. И в случае, если оба файла с имеют одно имя, то более старый будет затёрт.

juffinhalli 2 мар 2015 в 19:17

И ещё докину: (glusterfs-server 3.5.2-1): Для replicated volume сервера синхронизируют данные 1-м потоком, что весьма важно при выборе между IEEE 802.3ad и balance-rr

kt97679 2 мар 2015 в 21:02

В конфигурации distributed replicated volume будет ли GlusterFS нормально работать при потере сервера? Насколько безболезненно восстанавливается система при появлении сервера обратно? Как ведет себя GlusterFS в состоянии split brain (когда есть, скажем 2 сервера, клиент видит оба сервера, а вот они друг друга не видят)?

rgb000 3 мар 2015 в 09:46

В конфигурации distributed replicated volume будет ли GlusterFS нормально работать при потере сервера?

У нас на проекте был установлен и настроен glusterFS с 4-х серверов (по 20ТБ каждый) в distributed replicated режиме. Когда один из серверов падал — на клиенте никаких проблем не было, НО если при монтировании (с типом glusterfs) был прописан IP или домен сервера, который упал (mount.glusterfs dead-server.com:/testvol /mnt/glusterfs) — то клиент зависал при обращении к папке. Но я напишу, как бороться с этой проблемой в следующей статье.

Насколько безболезненно восстанавливается система при появлении сервера обратно?

Ничего делать не надо — восстановление вмешательств не требует.

Как ведет себя GlusterFS в состоянии split brain

За 11 месяцев работы — таких проблем не было. Но читал, что сталкивались люди с таким делом и даже tools для фикса есть.

cadmi 13 мая 2016 в 16:44

Со «следующей статьёй» (как это часто бывает на Хабре) не срослось :)

ColorPrint 2 мар 2015 в 22:13

С нетерпением жду вторую часть про тюнинг для гео-распределенной системы )
С год назад тестировал тоже, но времени не хватило подробно разобраться.
Заодно вопрос — работали ли с какими-то другими распределенными файловыми системами (особенно для задач когда ноды находятся в разных дата-центрах)? GlusterFS как лучшую выбирали или просто так сложилось? )
Спасибо.

rgb000 3 мар 2015 в 09:59

работали ли с какими-то другими распределенными файловыми системами?

Фирма разжилась на деньги, и купили супер-стореджы (2 x SuperServer 6047R-E1R36N x 110ТБ) и перешли на NFS из-за некоторых специфичных нюансов самой системы(не из-за проблем или прочего связанного с gluster-ом). Еще смотрим в сторону hadoop и ceph, но не хватает ресурсов(время и людей) для деплоя и теста.

GlusterFS как лучшую выбирали или просто так сложилось?

Когда пришел на проект — он уже был установлен и работал, деваться было некуда)

vasilisc 3 мар 2015 в 05:04

Немного визуального материала

rgb000 3 мар 2015 в 10:00

Спасибо, добавлю.

DLag 3 мар 2015 в 13:15

Сомнительно что реплицируемые данные будут храниться на одной физической железке в последнем варианте.
Можно конечно и так настроить, но это выстрел себе в ногу.