У меня есть реплицированный том x3 в 16.04.1-Ubuntu, Kernel 4.15.0-1023-azure # 24, со следующей конфигурацией:
Volume Name: gvol1
Type: Replicate
Volume ID: 384acec2-5b5f-40da-bf0e-5c53d12b3ae2
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x 3 = 3
Transport-type: tcp
Bricks:
Brick1: vm0:/srv/brick1/gvol1
Brick2: vm1:/srv/brick1/gvol1
Brick3: vm2:/srv/brick1/gvol1
Options Reconfigured:
storage.ctime: on
features.utime: on
storage.fips-mode-rchecksum: on
performance.client-io-threads: off
nfs.disable: on
transport.address-family: inet
Этот том был фактически создан в v3.8, но, поскольку он был обновлен (версия за версией) до v4.1.4, и он работает нормально (по большей части):
Client connections for volume gvol1
----------------------------------------------
Brick : vm0:/srv/brick1/gvol1
Clients connected : 6
Hostname BytesRead BytesWritten OpVersion
-------- --------- ------------ ---------
10.X.0.5:49143 2096520 2480212 40100
10.X.0.6:49141 14000 12812 40100
10.X.0.4:49134 258324 333456 40100
10.X.0.4:49141 565372566 1643447105 40100
10.X.0.5:49145 491262003 291782440 40100
10.X.0.6:49139 482629418 328228888 40100
----------------------------------------------
Brick : vm1:/srv/brick1/gvol1
Clients connected : 6
Hostname BytesRead BytesWritten OpVersion
-------- --------- ------------ ---------
10.X.0.6:49146 658516 508904 40100
10.X.0.5:49133 4142848 7139858 40100
10.X.0.4:49138 4088 3696 40100
10.X.0.4:49140 471405874 284488736 40100
10.X.0.5:49140 585193563 1670630439 40100
10.X.0.6:49138 482407454 330274812 40100
----------------------------------------------
Brick : vm2:/srv/brick1/gvol1
Clients connected : 6
Hostname BytesRead BytesWritten OpVersion
-------- --------- ------------ ---------
10.X.0.6:49133 1789624 4340938 40100
10.X.0.5:49137 3010064 3005184 40100
10.X.0.4:49143 4268 3744 40100
10.X.0.4:49139 471328402 283798376 40100
10.X.0.5:49139 491404443 293342568 40100
10.X.0.6:49140 561683906 830511730 40100
----------------------------------------------
Я сейчас получаю много ошибок в файле журнала кирпича,например:
The message "W [MSGID: 113117] [posix-metadata.c:627:posix_set_ctime] 0-gvol1-posix: posix set mdata failed, No ctime : /srv/brick1/gvol1/.glusterfs/18/d0/18d04927-1ec0-4779-8c5b-7ebb82e4a614 gfid:18d04927-1ec0-4779-8c5b-7ebb82e4a614 [Function not implemented]" repeated 2 times between [2018-09-21 08:21:52.480797] and [2018-09-21 08:22:07.529625]
Для разных файлов, но наиболее распространенным является файл, который приложение Node.js запускает поверх кластера через клиент-предохранитель (glusterfs), статистику каждые 5 с для изменений usin Fs.stathttps://nodejs.org/api/fs.html#fs_fs_stat_path_options_callback
Я думаю, это также связано с другой проблемой: при чтении файла возвращается пустой результат (не всегда), как сообщает приложение:
2018-09-21 08:22:00 | [vm0] [nobody] sync hosts: invalid applications.json, response was empty.
Doing gluster volume heal gvol1 info дает 0 для всех кирпичей.
Должен ли я быть обеспокоен предупреждением, это известная проблема?Если нет, то что может иногда вызывать возврат пустого файла?Могут ли они быть связаны?
Приложение, которое запускается поверх кластера, создает и порождает другие приложения node.js с небольшими файлами, у вас есть какие-либо советы по оптимизации?
К вашему сведениюприложение представляет собой слегка измененную версию https://github.com/totaljs/superadmin для работы в качестве веб-фермы.
ОБНОВЛЕНИЕ 1
Я прочитал список рассылки,и перенастроил том, который нужно оптимизировать для небольших файлов с большим количеством операций чтения / записи, со следующими переконфигурированными параметрами:
cluster.readdir-optimize: on
performance.read-ahead: on
performance.cache-size: 1GB
server.event-threads: 4
client.event-threads: 4
cluster.lookup-optimize: on
network.inode-lru-limit: 90000
performance.md-cache-timeout: 600
performance.cache-invalidation: on
performance.cache-samba-metadata: on
performance.stat-prefetch: on
features.cache-invalidation-timeout: 600
features.cache-invalidation: on
performance.client-io-threads: off
nfs.disable: on
transport.address-family: inet
storage.fips-mode-rchecksum: on
features.utime: on
storage.ctime: on
До сих пор я не сталкивался с проблемой пустых файлов, и количество ошибокзначительно сократилось.Тем не менее, исходное предупреждение все еще происходит или другие файлы.
ОБНОВЛЕНИЕ 2
Кажется, что известная проблема и должна быть решена в будущих версиях, см. https://lists.gluster.org/pipermail/gluster-users/2018-September/034931.html
Я все ещеоставьте вопрос открытым для любых советов по улучшению производительности, см. также https://lists.gluster.org/pipermail/gluster-users/2018-September/034934.html