Блог компании КРОК Облачные сервисы
IT-инфраструктура
Виртуализация
Серверное администрирование
Хранение данных
Комментарии 20
+1
Да, пробовали, работает стабильно, но с ним слишком много ограничений. Например, максимальный размер файла = размер брика — уже занятое на нем пространство. В этом случае, конечно, должен помочь Sharding xlator, но мы пока мы его только тестируем и рано делать выводы
0
Не пойму из мануала, можно ли на glusterfs поднять что-то наподобие виндовых групп DFS-R (хотя бы без расписания), по описаниям похоже, что он синхронный в режимах replicated или distributed replicated, то есть будет упираться в самый медленный канал связи, что всерьез мешает работе по аналогии с DFS-R через самбовые шары.

И ещё, почему используете 3.13, а не 3.12? У гластера 3.12 описана как LTS, а 3.13 не поддерживается после выхода 4.0.
0
А, читал же — это немножко не то. DFS-R позволяет геораспределенный мультимастер-доступ к одному контенту, при этом доступ по умолчанию сперва идет к локальной (site-local) шаре, а изменения гоняются в обе стороны. (Точнее, топология у DFS-R настраиваемая, но каждое соединение двунаправленное) Гео-репликация гластера однонаправленная, и никаких колец.
+1
На момент тестирования LTSкой была 3.10, на ней мы проводили большую часть тестирования, также мы пробовали стабильную версию от Red Hat (rhgs-3.3), но по сути разницы не было, основные проблемы со striped вольюмами оставались.
+2
при отвале диска, описанных проблем можно избежать, используя монтирование по метке или UUID:
e2label device [ new-label ]

и в fstab пишем:
LABEL=you_name_it /mount_point xfs 0 0
либо используем UUID:
UUID=4712c507-ae48-4e9c-8646-d859ad9406bc /mount_point xfs 0 0
0
Согласен, еще мы рассматривали вариант монтировать по симлинку by-path
udevadm info -q symlink /dev/sdb
disk/by-id/scsi-36d4ae52074d938002256460a3c3bc21d disk/by-id/wwn-0x6d4ae52074d938002256460a3c3bc21d disk/by-path/pci-0000:02:00.0-scsi-0:2:1:0 disk/by-uuid/c6ff2798-7302-4d52-a499-5a0109ceeb70​
0
Мы словили багу при удалении данных из тиринга. Нода отвалилась ибез ряда манипуляций не завелась.
0
Очень рекомендую не использовать stripe volume, а использовать distributed и включить там sharding.
+1
Кстати, disperced volume с sharding тоже хорошо себя показал в наших лабах.
+1
Немного башевой магии уменьшит команду инициализации до вменяемых размеров сохранив гарантированный порядок:
gluster volume create holodilnik stripe 10 replica 3 arbiter 1 transport tcp $( for brick in {0..9}; do echo {server1,server2}:/export/brick${brick}/holodilnik; done)
Жаль, нельзя указывать порядок brace expansion, было бы ещё лучше 8-)
0
Пара вопросов, если позволите:
1) почему именно XFS? Она при холодной (жёсткой) перезагрузке может рассыпаться. Везде её рекомендуют использовать только при отсутствии подобных выключений «по-живому». Из личного опыта — пару раз встречался с разваливанием этой ФС после жёсткого выключения на терабайтных дисках. Но в остальном да, ФС очень даже шустрая, особенно на огромном количестве больших и мелких файлов. Онлайновая дефрагментация к тому же рулит.

2) Вы не проводили тестирования, что лучше — добавить кучу дисков для избыточности или добавить кучу отзеркалированных томов в качестве базовых единиц?

3) А оно не умеет по GUUID диска монтировать тома?

4) Почему «вольюмы», когда на русском вполне себе используется термин «том»? Или это какая-то специфика именно у вас?
0
Спасибо за вопросы:
1) XFS была выбрана, так как мы практически везде используем Centos 7, а она уже давно стала их дефолтной файловой системой. Так же RedHat во всех мануалах рекомендует именно ее. XFS мы, так же, давно используем в Ceph, и массовых проблем с развалом файлухи не наблюдаем. Да, бывало, что она сыпалась, причем даже не только в случае холодной перезагрузки, но в основном она нас полностью устраивает.

2) Я наблюдаю сейчас тенденции именно к использованию JBOD, а всю логику по репликации на себя берут уже SDS решения. Если у вас есть острая необходимость в повышении уровня надежности сохранности данных, вы можете собрать под Гластером зеркала, или RAID5, но это значительно увеличит стоимость вашего хранилища. Касательно производительномсти, тут ответ разный в зависимости от типа вольюма(тома). Для striped лучше куча дисков, так как данные ровными слоями пишутся на все брики одновременно. Для разных distributed с включенным шардингом производительность одного потока записи не изменится, но при нескольких потоках, общая производительность кластера будет выше. В остальных типах производительность не изменится.

3) Если речь идет о UUID, то пробовали, но уже после публикации статьи.

4) Вся документация, что мы читали, была на английском языке и так вышло, что к нам в обиход пришли слова в raw формате =) брик(brick), вольюм(volume) и тд.
Только полноправные пользователи могут оставлять комментарии. , пожалуйста.