Pull to refresh

Comments 20

Да, пробовали, работает стабильно, но с ним слишком много ограничений. Например, максимальный размер файла = размер брика — уже занятое на нем пространство. В этом случае, конечно, должен помочь Sharding xlator, но мы пока мы его только тестируем и рано делать выводы
Не пойму из мануала, можно ли на glusterfs поднять что-то наподобие виндовых групп DFS-R (хотя бы без расписания), по описаниям похоже, что он синхронный в режимах replicated или distributed replicated, то есть будет упираться в самый медленный канал связи, что всерьез мешает работе по аналогии с DFS-R через самбовые шары.

И ещё, почему используете 3.13, а не 3.12? У гластера 3.12 описана как LTS, а 3.13 не поддерживается после выхода 4.0.
У него в доке есть отдельный раздел Geo Replication.
А, читал же — это немножко не то. DFS-R позволяет геораспределенный мультимастер-доступ к одному контенту, при этом доступ по умолчанию сперва идет к локальной (site-local) шаре, а изменения гоняются в обе стороны. (Точнее, топология у DFS-R настраиваемая, но каждое соединение двунаправленное) Гео-репликация гластера однонаправленная, и никаких колец.
На момент тестирования LTSкой была 3.10, на ней мы проводили большую часть тестирования, также мы пробовали стабильную версию от Red Hat (rhgs-3.3), но по сути разницы не было, основные проблемы со striped вольюмами оставались.
А что за режим такой «erasure coding» в glusterfs?
при отвале диска, описанных проблем можно избежать, используя монтирование по метке или 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
Согласен, еще мы рассматривали вариант монтировать по симлинку 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​
Мы словили багу при удалении данных из тиринга. Нода отвалилась ибез ряда манипуляций не завелась.
Очень рекомендую не использовать stripe volume, а использовать distributed и включить там sharding.
Кстати, disperced volume с sharding тоже хорошо себя показал в наших лабах.
Немного башевой магии уменьшит команду инициализации до вменяемых размеров сохранив гарантированный порядок:
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-)
Ловко, спасибо, приму на вооружение =)
Пара вопросов, если позволите:
1) почему именно XFS? Она при холодной (жёсткой) перезагрузке может рассыпаться. Везде её рекомендуют использовать только при отсутствии подобных выключений «по-живому». Из личного опыта — пару раз встречался с разваливанием этой ФС после жёсткого выключения на терабайтных дисках. Но в остальном да, ФС очень даже шустрая, особенно на огромном количестве больших и мелких файлов. Онлайновая дефрагментация к тому же рулит.

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

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

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

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

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

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