LINUX.ORG.RU

GlusterFS. Низкая производительность.

 , ,


2

5

Всем доброго времени суток. Прошу поделиться практическим опытом и советом в создании отказоустойчивого файлового хранилища. Задача обычная - NAS для хранения и подключения образов виртуальных машин. Что было сделано.

Исходные данные.

  1. Три десктопных сервера (Core 2 Duo / Core 2 Quard)
  2. Дисковая подсистема на всех серверах — 4 х 1 TB HDD (SATA 7200) собранных в RAID10 (Intel Matrix HostRaid + mdadm)
  3. Сеть — 3 гигабитных сетевых карты, 2 сети. Одна сетевуха смотрит в пользовательскую сеть для управления (management), 2 другие собраны в агрегированный канал (LACP bonding 802.3ad) для репликаций и подключения дисков виртуальных машин. После подключения были произведены замеры скорости — копировал большие и много мелких файлов по сети с одной ноды на другую. Максимальная скорость чтения/записи по сети — 150МБ/сек. Понятное дело — диски пустые.
  4. ОС — CentOS 7.

Создание томов glusterfs.

  1. На одном из логических разделов созданы lvm тома 100G и 1,7TB c xfs. Выглядит это так.

    sda                 8:0    0 931,5G  0 disk   
    └─md126             9:126  0   1,8T  0 raid10 
      ├─md126p1       259:0    0     1G  0 md     /boot
      ├─md126p2       259:1    0  28,9G  0 md     
      │ ├─cl-root     253:0    0    25G  0 lvm    /
      │ └─cl-swap     253:1    0   3,9G  0 lvm    [SWAP]
      └─md126p3       259:2    0   1,8T  0 md     
        ├─gluster-vd0 253:2    0   100G  0 lvm    /mnt/vmengn
        └─gluster-vd1 253:3    0   1,7T  0 lvm    /mnt/vmboot
    sdb                 8:16   0 931,5G  0 disk   
    └─md126             9:126  0   1,8T  0 raid10 
      ├─md126p1       259:0    0     1G  0 md     /boot
      ├─md126p2       259:1    0  28,9G  0 md     
      │ ├─cl-root     253:0    0    25G  0 lvm    /
      │ └─cl-swap     253:1    0   3,9G  0 lvm    [SWAP]
      └─md126p3       259:2    0   1,8T  0 md     
        ├─gluster-vd0 253:2    0   100G  0 lvm    /mnt/vmengn
        └─gluster-vd1 253:3    0   1,7T  0 lvm    /mnt/vmboot
    sdc                 8:32   0 931,5G  0 disk   
    └─md126             9:126  0   1,8T  0 raid10 
      ├─md126p1       259:0    0     1G  0 md     /boot
      ├─md126p2       259:1    0  28,9G  0 md     
      │ ├─cl-root     253:0    0    25G  0 lvm    /
      │ └─cl-swap     253:1    0   3,9G  0 lvm    [SWAP]
      └─md126p3       259:2    0   1,8T  0 md     
        ├─gluster-vd0 253:2    0   100G  0 lvm    /mnt/vmengn
        └─gluster-vd1 253:3    0   1,7T  0 lvm    /mnt/vmboot
    sdd                 8:48   0 931,5G  0 disk   
    └─md126             9:126  0   1,8T  0 raid10 
      ├─md126p1       259:0    0     1G  0 md     /boot
      ├─md126p2       259:1    0  28,9G  0 md     
      │ ├─cl-root     253:0    0    25G  0 lvm    /
      │ └─cl-swap     253:1    0   3,9G  0 lvm    [SWAP]
      └─md126p3       259:2    0   1,8T  0 md     
        ├─gluster-vd0 253:2    0   100G  0 lvm    /mnt/vmengn
        └─gluster-vd1 253:3    0   1,7T  0 lvm    /mnt/vmboot
    
  2. Средствами gluster, созданы 2 диска vmengn и vmboot replica 3. Вот так:

    # gluster volume info all
     
    Volume Name: vmboot
    Type: Replicate
    Volume ID: 0d9b0b50-fe76-4e8f-bba1-7860e0b04872
    Status: Started
    Number of Bricks: 1 x 3 = 3
    Transport-type: tcp
    Bricks:
    Brick1: vmboot1.ru:/mnt/vmboot/data
    Brick2: vmboot2.ru:/mnt/vmboot/data
    Brick3: vmboot3.ru:/mnt/vmboot/data
    Options Reconfigured:
    performance.readdir-ahead: on
    cluster.quorum-type: auto
    cluster.server-quorum-type: server
    diagnostics.latency-measurement: on
    diagnostics.count-fop-hits: on
    cluster.server-quorum-ratio: 35%
     
    Volume Name: vmengn
    Type: Replicate
    Volume ID: 4430f8ed-8108-4391-b30d-ac62205eb5f1
    Status: Started
    Number of Bricks: 1 x 3 = 3
    Transport-type: tcp
    Bricks:
    Brick1: vmboot1.ru:/mnt/vmengn/data
    Brick2: vmboot2.ru:/mnt/vmengn/data
    Brick3: vmboot3.ru:/mnt/vmengn/data
    Options Reconfigured:
    performance.readdir-ahead: on
    cluster.quorum-type: auto
    cluster.server-quorum-type: server
    diagnostics.latency-measurement: on
    diagnostics.count-fop-hits: on
    cluster.server-quorum-ratio: 35%
    
  3. На диске vmeng развернута ВМ ovirt HostedEngine, на vmboot образы различных виртуальных машин, управляемых через ovirt.

ИТОГИ

  1. Косяк номер раз.
    Крайне низкая производительность копирования/записи на glusterfs тома. Замеры скорости показывают в максимуме 10МБ / сек. Виртуалки тормозят со страшной силой. Переодически отваливаются ноды кластера и виртуальные машины ovirt по таймауту недоступности стораджа дата центра.
  2. Мегакосяк номер 2.
    После ребута узла glusterfs — сервис glusterd не стратует! В логах ошибки неудовлетворенных зависимостей glusterd. В итоге выяснилось, что проблема в том, что не стратует сервис rpcbind примерно с такими же ошибками — не удовлетворенные зависимости.

    # service rpcbind status
    Redirecting to /bin/systemctl status  rpcbind.service
    ● rpcbind.service - RPC bind service
       Loaded: loaded (/usr/lib/systemd/system/rpcbind.service; indirect; vendor preset: enabled)
       Active: inactive (dead)
    
    мар 28 11:55:41 aa76.ru systemd[1]: Dependency failed for RPC bind service.
    мар 28 11:55:41 aa76.ru systemd[1]: Job rpcbind.service/start failed with result 'dependency'.
    

    Причем при попытке вручную стартануть сервис — результат тот же. Получается только так.

    # systemctl enable rpcbind
    # systemctl start rpcbind
    # systemctl start glusterd
    


P.S. Попытки нагуглить похожую проблему, приводят к старым bugreport'ам на «красной пашечке», датированным 2011-2013 годами.
Из более менее свежих, нашел только вот это, но не помогло.

Прошу совета в какую сторону курить? Изначально строил NAS на базе nas4free из 2-х нод (FreeBSD + CARP + HAST + ZFS + iSCSI Target), но тоже не взлетело — первые же тесты на отказоустойчивость развалили узел из 2-х нод с полной деградацией, к тому же «на горячую» не получится заменить узел nas4free.



Последнее исправление: bearpuh (всего исправлений: 1)

Немного не по теме, но

4 х 1 TB HDD (SATA 7200) собранных в RAID10 (Intel Matrix HostRaid + mdadm)

это как ?
от псевдоаппаратного рейда лучше отказаться.

Deleted
()
Ответ на: комментарий от bearpuh

В продакшн будет железный RAID.

Это шутка? Рэйд в распределённой системе?

А Гластер лучше сразу выкинуть. Ну и конечно лучше почитать в интернетах, какие системы есть, и какие у них проблема. Низкая скорость Гластера в роли обычного хранилища - известная проблема, которой сто лет.

Mr_Alone ★★★★★
()

по 2.
скорей всего надо разрулить wants|before|after remote-fs-pre.target в обоих сервисах

bass ★★★★★
()
Ответ на: комментарий от bearpuh

Нужно описать требования. Что ожидается от схд ?
Алсо gluster везде поливают грязью и не считают её надёжной штукой.

Deleted
()

воткни в каждый сервер два ssd и два hdd(без рейда, особенно такого, как описал), по флешке 8+ гб и поставь nutanix ce, после чего нарезай на виртуалки с RF=2

anonymous
()
Ответ на: комментарий от bearpuh

По пункту 1 разобрался. Тут вот такая тема.

/etc/systemd/system/sockets.target.wants

[Unit]
Description=RPCbind Server Activation Socket

[Socket]
ListenStream=/var/run/rpcbind.sock
--->ListenStream=[::]:111<---
ListenStream=0.0.0.0:111
BindIPv6Only=ipv6-only

[Install]
WantedBy=sockets.target

При отключенном ipv6 через sysctl.conf будет ругань от rpcbind, так как в юните прописана прослушка 111 порта по ipv6. Тут либо править юнит ручками, либо включать ipv6.

По пункту 2, по совету bass, были немного потюнены параметры glusterfs, а именно:

  
# gluster volume info vmboot 
Volume Name: vmboot
Type: Replicate
Volume ID: 0d9b0b50-fe76-4e8f-bba1-7860e0b04872
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x 3 = 3
Transport-type: tcp
Bricks:
Brick1: vmboot1.niisi.ru:/mnt/vmboot/data
Brick2: vmboot2.niisi.ru:/mnt/vmboot/data
Brick3: vmboot3.niisi.ru:/mnt/vmboot/data
Options Reconfigured:
diagnostics.count-fop-hits: on
diagnostics.latency-measurement: on
cluster.server-quorum-type: server
cluster.quorum-type: auto
performance.readdir-ahead: on
performance.io-thread-count: 32
performance.flush-behind: on
performance.write-behind: on
performance.io-cache: on
performance.write-behind-window-size: 16MB
performance.cache-size: 2GB
cluster.server-quorum-ratio: 35%

Картина поменялась в цифрах
[img]http://savepic.ru/13374654m.png[/img]
Но на деле фризы и тормоза виртуалок остались.

bearpuh
() автор топика

У тебя:

HDDs (hard) -> RAID10 (soft) -> LVM (soft) -> GlusterFS (soft)

Когда достаточно:

HDDs (hard) -> GlusterFS (soft)

А отказоустойчивость обеспечит и сам GlusterFS.

AlexVR ★★★★★
()
Ответ на: комментарий от AlexVR

У тебя:

HDDs (hard) -> RAID10 (soft) -> LVM (soft) -> GlusterFS (soft)

Когда достаточно:

HDDs (hard) -> GlusterFS (soft)

А отказоустойчивость обеспечит и сам GlusterFS.


Не поверишь - шел на работу и как раз об этом думал. Вопрос только в downtime.
В случае с рейдом я могу вообще не отключать ноду при падении харда, а на горячую пересобрать рейд.
При этом данные с другой ноды не будут по новой с нуля синхронизироваться. Мысль ясна?
По твоему варианту, подскажи тогда как лучше - что есть good practice, так сказать:

Вариант 1.

  1. Группа томов из звух hdd (/dev/sda /dev/sdb)
  2. Два тома lvm нужного размера (100GB и 1,7TB)
  3. По одному «кирпичу» на каждый том gluster от каждой ноды - replica 3.


Вариант 2.

  1. Две группы томов из звух hdd (/dev/sda /dev/sdb)
  2. Три тома lvm 100GB (/dev/sda), 830GB (остаток от /dev/sda) и 930G (/dev/sdb)
  3. По одному «кирпичу» на первый том gluster (100G) от каждой ноды - replica 3
  4. По два «кирпича» на второй том gluster (830+930G) от каждой ноды - replica 3 + distributer/stripped

Вопроса два - отказоустойчивость и быстродействие.
Что лучше в плане восстановления работоспособности в случае выхода из строя скажем одного харда на ноде?

bearpuh
() автор топика
Ответ на: комментарий от bearpuh

Народ, вообще у кого нибудь была положительная практика внедрения GlusterSF?
Что то в интернетах не встречал нормальной информации по данной теме - только теория.

Кто нибудь щупал PetaSAN?

bearpuh
() автор топика

К сожалению, Гластер не подходит для стореджа виртуалок. Конечно, он может как-то работать, но тогда будь готов вот так периодически удивляться. Для виртуалок тебе нужен Ceph RBD, и тут без вариантов.

Касаемо скорости, гигабит для такого дела — ужас, не столько из-за скорости, сколько из-за задержек. На десятке, скажу я тебе, оно получше, но всё равно не сильно. Ещё репликация делит эту скорость на количество реплик, т.е., если у тебя гигабит (а считаем без LACP, т.к. там трафик может и не балансироваться равномерно), то больше 40 МиБ/с не жди, а с учётом задержки на каждый чих (flush, ack и т. д.), дели это ещё на 3. Вот и получишь свои 10 МиБ/с (примерно).

Ещё раз: распределённый сетевой сторедж *очень* чувствителен к network latency.

Вывод: для образов виртуалок — Ceph RBD, GlusterFS — только для файлового стореджа, если сумеешь его приготовить. Сеть крайне желательно побыстрее да с меньшими задержками (InfiniBand в идеале, но десятки тоже могут сойти).

post-factum ★★★★★
()
Ответ на: комментарий от bearpuh

положительная практика внедрения

Да, для файлопомойки. С ежедневным просмотром Gerrit'а, бекпортом патчей, багрепортами, сейшнами с разрабами в ирке и т.п.

post-factum ★★★★★
()
Ответ на: комментарий от post-factum

Да, для файлопомойки. С ежедневным просмотром Gerrit'а, бекпортом патчей, багрепортами, сейшнами с разрабами в ирке и т.п.


Млять...
Ок. Попробую еще PetaSAN - это Ceph с вебмордой. Расстраивает только, что там бубунта и нет ни ssh ни telnet.

bearpuh
() автор топика
Ответ на: комментарий от post-factum

положительная практика внедрения
Да, для файлопомойки.

Ну если только коллекцию фильмов/музыки хранить, и на пару компов шарить. Для чего-то большего не подходит.

Mr_Alone ★★★★★
()
Ответ на: комментарий от post-factum

В принципе, для заббикса кое-какие шаблоны есть в интернетах.

Опять колхозить? Что-то нет желания. Да и скрестить с гипервизором ovirt из коробки не получится.

bearpuh
() автор топика
Ответ на: комментарий от post-factum

Ну поставь Nutanix CE тогда.

Дык мне не гипервизор нужен, а NAS. Вопрос по Ceph - можни ли OSD устройства отдавать по iSCSI?

bearpuh
() автор топика
Ответ на: комментарий от post-factum

Так можно - блочное реплицируемое устройство Ceph RDB (3 ноды), на нем какая нибудь ФС, там файлы-экстенты отдаваемые по iSCSI как блочные устройства?

bearpuh
() автор топика
Ответ на: комментарий от post-factum

Зачем тебе лишние абстракции, если QEMU умеет Ceph RBD напрямую?

Ovirt не умеет. Поиграюсь сначала с PetaSAN, потом запилю Ceph + GVFS2 + iSCSI Target.
Спасибо за наводку.

bearpuh
() автор топика
Ответ на: комментарий от post-factum

Погугли, чё там у овирта с Cinder'ом.

Слишком толстый бутерброд получается. Не мой путь.

bearpuh
() автор топика

Если использовать gluster в качестве отказоустойчивого хранилища то проблем никаких нет. В плане быстродействия он не подходит. Нам пришлось выносить проекты на локальные диски а gluster используется как backup.
И здесь разве что поможет SSD + Intel X710 и чтобы все было в одной стойке и подключено на прямую.

aspel
()
Ответ на: комментарий от aspel

Также посмотри в сторону MooseFS там неплохие тесты.

Глянул. Выглядит, как всегда неплохо. Надо попробовать.
Вот неплохая статься с нужным концептом.
Вторая часть.

Но все равно это «паровоз», а мне нужен «велосипед». Чувствую кончится это покупкой двух стоечных synelogy.))

bearpuh
() автор топика
Ответ на: комментарий от bearpuh

Есть драйвер. У нас так стоял ceph+xen через multipath iscsi. Но по скорости был фейл. Если собираешься юзать такую хранилку, выкидывай овирт. OpenNebula вроде умеет ceph, при этом она легче ovirt (по крайней мере такие отзывы на канале https://t.me/ceph_ru )

stave ★★★★★
()
Ответ на: комментарий от Mr_Alone

Proxmox + Ceph - стильно, модно, молодёжно.

Debian based религия не позволяет поставить )). К тому же, это уже коммерческая фигня.

bearpuh
() автор топика
Ответ на: комментарий от stave

Плюсую OpenNebula - сам пользуюсь, как раз в связке с Ceph.

Pinkbyte ★★★★★
()
10 июля 2017 г.

GlusterFS, перезагрузка.


Попробовал много различных решений, в том числе - nas4free, PetaSan, quadstor.
Не добрался пока только до ceph и nexenta. В итоге вернулся на Gluster и хочу сказать, что удалось добиться
приемлемых результатов.

Нормально заработало в варианте Replicated Distributed, Replica 3 (2 + 1 Arbiter). Узлы строил на базе дистра Ovirt 4.1.
В идеале нужно 6 нод под такую конструкцию, но я пока сделал на 3-х - по 2 кирпича (bricks) на ноду.
Вот так: 3 nodes x 2 bricks..

Сеть под глюстер отдельная - на каждом узле bonding из 2-х гигабитный интерфейсов только для синхронизации и подключения
узлов виртуальных машин. Бондинг сделал на LACP (802.3ad - mode4), но думаю переделывать на balance-xor (mode2), так как
глюстер синхается в одну сессию, а LACP ее не делит.

LVM тома строил в строгом соответствии кирпичестроения глюстера и концепции овирт. Вот по этим манам:

Setting up GlusterFS Server Volumes
Creating Thinly-Provisioned Logical Volumes

Из особенностей отмечу, что при создании VolumeGroup, необходимо задать размер метаданных в 1G.
Это тупо подсмотрел у ovirt 4.1 развернутого «из коробки».
Делается это так:

vgcreate --physicalextentsize 1G volume_group_name /dev/sd*
В итоге получилось вот такое. Привожу вывод «кирпичей» на одном из узлов.

sdb                                                       8:16   0 931,5G  0 disk  
└─WDC_WD1002F9YZ-09H1JL1_WD-WMC5K0D7LHNY                253:5    0 931,5G  0 mpath 
  ├─gluster_vg_sdb-gluster_thinpool_sdb_tmeta           253:13   0     1G  0 lvm   
  │ └─gluster_vg_sdb-gluster_thinpool_sdb-tpool         253:15   0   900G  0 lvm   
  │   ├─gluster_vg_sdb-gluster_thinpool_sdb             253:16   0   900G  0 lvm   
  │   └─gluster_vg_sdb-vmboot1                          253:17   0   900G  0 lvm   /gluster_bricks/vmboot1
  └─gluster_vg_sdb-gluster_thinpool_sdb_tdata           253:14   0   900G  0 lvm   
    └─gluster_vg_sdb-gluster_thinpool_sdb-tpool         253:15   0   900G  0 lvm   
      ├─gluster_vg_sdb-gluster_thinpool_sdb             253:16   0   900G  0 lvm   
      └─gluster_vg_sdb-vmboot1                          253:17   0   900G  0 lvm   /gluster_bricks/vmboot1
sdc                                                       8:32   0 931,5G  0 disk  
└─ST31000524NS_9WK28WGG                                 253:6    0 931,5G  0 mpath 
  ├─gluster_vg_sdc-gluster_thinpool_sdc_tmeta           253:8    0     1G  0 lvm   
  │ └─gluster_vg_sdc-gluster_thinpool_sdc-tpool         253:10   0   900G  0 lvm   
  │   ├─gluster_vg_sdc-gluster_thinpool_sdc             253:11   0   900G  0 lvm   
  │   └─gluster_vg_sdc-vmboot4                          253:12   0   900G  0 lvm   /gluster_bricks/vmboot4
  └─gluster_vg_sdc-gluster_thinpool_sdc_tdata           253:9    0   900G  0 lvm   
    └─gluster_vg_sdc-gluster_thinpool_sdc-tpool         253:10   0   900G  0 lvm   
      ├─gluster_vg_sdc-gluster_thinpool_sdc             253:11   0   900G  0 lvm   
      └─gluster_vg_sdc-vmboot4                          253:12   0   900G  0 lvm   /gluster_bricks/vmboot4

Gluster тома не тюнинговал, это умеет сам овирт. Кому интересно, привожу настройки томов.

Что еще не реализовано.
Как я уже говорил, думаю что синхронизация томов ускорится при переходе на тип агрегации сетевых интерфейсов - balance-xor.
Стремно пробовать на рабочем кластере, буду собирать тестовую модель отдельно.
Еще есть мысль запилить Striped Replicated Distributed том, но вот только ovirt 4.1 это не умеет «из коробки», а «колхозить» пока не хочу.
Всем добра )))).

P.S. Данный том использую исключительно под образы виртуальных машин. Для пользовательских данных заказали 2 промышленных наса от Synelogy.

bearpuh
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.