Comments 20
Тип distributed replicated не пробовали?
0
Не пойму из мануала, можно ли на glusterfs поднять что-то наподобие виндовых групп DFS-R (хотя бы без расписания), по описаниям похоже, что он синхронный в режимах replicated или distributed replicated, то есть будет упираться в самый медленный канал связи, что всерьез мешает работе по аналогии с DFS-R через самбовые шары.
И ещё, почему используете 3.13, а не 3.12? У гластера 3.12 описана как LTS, а 3.13 не поддерживается после выхода 4.0.
И ещё, почему используете 3.13, а не 3.12? У гластера 3.12 описана как LTS, а 3.13 не поддерживается после выхода 4.0.
0
У него в доке есть отдельный раздел Geo Replication.
0
А, читал же — это немножко не то. DFS-R позволяет геораспределенный мультимастер-доступ к одному контенту, при этом доступ по умолчанию сперва идет к локальной (site-local) шаре, а изменения гоняются в обе стороны. (Точнее, топология у DFS-R настраиваемая, но каждое соединение двунаправленное) Гео-репликация гластера однонаправленная, и никаких колец.
0
На момент тестирования LTSкой была 3.10, на ней мы проводили большую часть тестирования, также мы пробовали стабильную версию от Red Hat (rhgs-3.3), но по сути разницы не было, основные проблемы со striped вольюмами оставались.
+1
А что за режим такой «erasure coding» в glusterfs?
0
Erasure coding применяется в dispersed volume, у Redhat есть хорошая документация с примерами access.redhat.com/documentation/en-us/red_hat_gluster_storage/3.2/html/administration_guide/sect-recommended-configuration_dispersed
+1
при отвале диска, описанных проблем можно избежать, используя монтирование по метке или UUID:
и в fstab пишем:
LABEL=you_name_it /mount_point xfs 0 0
либо используем UUID:
UUID=4712c507-ae48-4e9c-8646-d859ad9406bc /mount_point xfs 0 0
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
+2
Тиринг не включали в гластере?
0
Очень рекомендую не использовать stripe volume, а использовать distributed и включить там sharding.
0
Немного башевой магии уменьшит команду инициализации до вменяемых размеров сохранив гарантированный порядок:
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
Пара вопросов, если позволите:
1) почему именно XFS? Она при холодной (жёсткой) перезагрузке может рассыпаться. Везде её рекомендуют использовать только при отсутствии подобных выключений «по-живому». Из личного опыта — пару раз встречался с разваливанием этой ФС после жёсткого выключения на терабайтных дисках. Но в остальном да, ФС очень даже шустрая, особенно на огромном количестве больших и мелких файлов. Онлайновая дефрагментация к тому же рулит.
2) Вы не проводили тестирования, что лучше — добавить кучу дисков для избыточности или добавить кучу отзеркалированных томов в качестве базовых единиц?
3) А оно не умеет по GUUID диска монтировать тома?
4) Почему «вольюмы», когда на русском вполне себе используется термин «том»? Или это какая-то специфика именно у вас?
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) и тд.
1) XFS была выбрана, так как мы практически везде используем Centos 7, а она уже давно стала их дефолтной файловой системой. Так же RedHat во всех мануалах рекомендует именно ее. XFS мы, так же, давно используем в Ceph, и массовых проблем с развалом файлухи не наблюдаем. Да, бывало, что она сыпалась, причем даже не только в случае холодной перезагрузки, но в основном она нас полностью устраивает.
2) Я наблюдаю сейчас тенденции именно к использованию JBOD, а всю логику по репликации на себя берут уже SDS решения. Если у вас есть острая необходимость в повышении уровня надежности сохранности данных, вы можете собрать под Гластером зеркала, или RAID5, но это значительно увеличит стоимость вашего хранилища. Касательно производительномсти, тут ответ разный в зависимости от типа вольюма(тома). Для striped лучше куча дисков, так как данные ровными слоями пишутся на все брики одновременно. Для разных distributed с включенным шардингом производительность одного потока записи не изменится, но при нескольких потоках, общая производительность кластера будет выше. В остальных типах производительность не изменится.
3) Если речь идет о UUID, то пробовали, но уже после публикации статьи.
4) Вся документация, что мы читали, была на английском языке и так вышло, что к нам в обиход пришли слова в raw формате =) брик(brick), вольюм(volume) и тд.
0
Sign up to leave a comment.
Как мы ломали Glusterfs