Ранее я спрашивал о монтировании GlusterFS при загрузке на сервере Ubuntu 12.04. и ответ заключался в том, что это было ошибкой в 12.04 и работало в 14.04. Любопытно, что я попробовал его на виртуальной машине, работающей на моем ноутбуке, и в 14.04 он заработал. Поскольку это было критично для меня, я решил обновить свои работающие серверы до 14.04 только для того, чтобы обнаружить, что GlusterFS также не монтирует тома localhost автоматически.
Это сервер Linode, и fstab выглядит так:
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
/dev/xvda / ext4 noatime,errors=remount-ro 0 1
/dev/xvdb none swap sw 0 0
/dev/xvdc /var/lib/glusterfs/brick01 ext4 defaults 1 2
koraga.int.example.com:/public_uploads /var/www/shared/public/uploads glusterfs defaults,_netdev 0 0
Процесс загрузки выглядит примерно так (только в части сетевого монтажа, которая не работает):
* Stopping Mount network filesystems [ OK ]
* Starting set sysctls from /etc/sysctl.conf [ OK ]
* Stopping set sysctls from /etc/sysctl.conf [ OK ]
* Starting configure virtual network devices [ OK ]
* Starting Bridge socket events into upstart [ OK ]
* Starting Waiting for state [fail]
* Stopping Waiting for state [ OK ]
* Starting Block the mounting event for glusterfs filesystems until the [fail]k interfaces are running
* Starting Waiting for state [fail]
* Starting Block the mounting event for glusterfs filesystems until the [fail]k interfaces are running
* Stopping Waiting for state [ OK ]
* Starting Signal sysvinit that remote filesystems are mounted [ OK ]
* Starting GNU Screen Cleanup [ OK ]
Я считаю, что файл журнала /var/log/glusterfs/var-www-shared-public-uploads.log содержит основной ключ к разгадке проблемы, так как он единственный, который действительно отличается между этим сервером, где установка не работает, и моим локальным виртуальным сервером, где он находится:
[2014-07-10 05:51:49.762162] I [glusterfsd.c:1959:main] 0-/usr/sbin/glusterfs: Started running /usr/sbin/glusterfs version 3.5.1 (/usr/sbin/glusterfs --volfile-server=koraga.int.example.com --volfile-id=/public_uploads /var/www/shared/public/uploads)
[2014-07-10 05:51:49.774248] I [socket.c:3561:socket_init] 0-glusterfs: SSL support is NOT enabled
[2014-07-10 05:51:49.774278] I [socket.c:3576:socket_init] 0-glusterfs: using system polling thread
[2014-07-10 05:51:49.775573] E [socket.c:2161:socket_connect_finish] 0-glusterfs: connection to 192.168.134.227:24007 failed (Connection refused)
[2014-07-10 05:51:49.775634] E [glusterfsd-mgmt.c:1601:mgmt_rpc_notify] 0-glusterfsd-mgmt: failed to connect with remote-host: koraga.int.example.com (No data available)
[2014-07-10 05:51:49.775649] I [glusterfsd-mgmt.c:1607:mgmt_rpc_notify] 0-glusterfsd-mgmt: Exhausted all volfile servers
[2014-07-10 05:51:49.776284] W [glusterfsd.c:1095:cleanup_and_exit] (-->/usr/lib/x86_64-linux-gnu/libgfrpc.so.0(rpc_transport_notify+0x23) [0x7f6718bf3f83] (-->/usr/lib/x86_64-linux-gnu/libgfrpc.so.0(rpc_clnt_notify+0x90) [0x7f6718bf7da0] (-->/usr/sbin/glusterfs(+0xcf13) [0x7f67192bbf13]))) 0-: received signum (1), shutting down
[2014-07-10 05:51:49.776314] I [fuse-bridge.c:5475:fini] 0-fuse: Unmounting '/var/www/shared/public/uploads'.
Состояние тома:
Volume Name: public_uploads
Type: Distribute
Volume ID: 52aa6d85-f4ea-4c39-a2b3-d20d34ab5916
Status: Started
Number of Bricks: 1
Transport-type: tcp
Bricks:
Brick1: koraga.int.example.com:/var/lib/glusterfs/brick01/public_uploads
Options Reconfigured:
auth.allow: 127.0.0.1,192.168.134.227
client.ssl: off
server.ssl: off
nfs.disable: on
Если я сбегу mount -a после загрузки том смонтирован правильно:
koraga.int.example.com:/public_uploads on /var/www/shared/public/uploads type fuse.glusterfs (rw,default_permissions,allow_other,max_read=131072)
Несколько связанных файлов журнала показывают это:
/var/log/upstart/mounting-glusterfs-_var_www_shared_public_uploads.log:
start: Job failed to start
/var/log/upstart/wait-for-state-mounting-glusterfs-_var_www_shared_public_uploadsstatic-network-up.log:
status: Unknown job: static-network-up
start: Unknown job: static-network-up
но на моем тестовом сервере он показывает то же самое, поэтому я не думаю, что это актуально.
Есть идеи, что сейчас не так?
Обновить: Я пробовал изменить WAIT_FOR со статического сетевого на сетевой, но он все еще не работал, но все сообщения [сбой] при загрузке исчезают. Это файлы журналов при следующих условиях:
/var/log/glusterfs/var-www-shared-public-uploads.log содержит:
wait-for-state stop/waiting
/var/log/upstart/wait-for-state-mounting-glusterfs-_var_www_shared_public_uploadsstatic-network-up.log содержит:
start: Job is already running: networking
/var/log/glusterfs/var-www-shared-public-uploads.log содержит:
[2014-07-11 17:19:38.000207] I [glusterfsd.c:1959:main] 0-/usr/sbin/glusterfs: Started running /usr/sbin/glusterfs version 3.5.1 (/usr/sbin/glusterfs --volfile-server=koraga.int.example.com --volfile-id=/public_uploads /var/www/shared/public/uploads)
[2014-07-11 17:19:38.029421] I [socket.c:3561:socket_init] 0-glusterfs: SSL support is NOT enabled
[2014-07-11 17:19:38.029450] I [socket.c:3576:socket_init] 0-glusterfs: using system polling thread
[2014-07-11 17:19:38.030288] E [socket.c:2161:socket_connect_finish] 0-glusterfs: connection to 192.168.134.227:24007 failed (Connection refused)
[2014-07-11 17:19:38.030331] E [glusterfsd-mgmt.c:1601:mgmt_rpc_notify] 0-glusterfsd-mgmt: failed to connect with remote-host: koraga.int.example.com (No data available)
[2014-07-11 17:19:38.030345] I [glusterfsd-mgmt.c:1607:mgmt_rpc_notify] 0-glusterfsd-mgmt: Exhausted all volfile servers
[2014-07-11 17:19:38.030984] W [glusterfsd.c:1095:cleanup_and_exit] (-->/usr/lib/x86_64-linux-gnu/libgfrpc.so.0(rpc_transport_notify+0x23) [0x7fd9495b7f83] (-->/usr/lib/x86_64-linux-gnu/libgfrpc.so.0(rpc_clnt_notify+0x90) [0x7fd9495bbda0] (-->/usr/sbin/glusterfs(+0xcf13) [0x7fd949c7ff13]))) 0-: received signum (1), shutting down
[2014-07-11 17:19:38.031013] I [fuse-bridge.c:5475:fini] 0-fuse: Unmounting '/var/www/shared/public/uploads'.
Обновление 2: Я тоже пробовал это в файле upstart:
start on (started glusterfs-server and mounting TYPE=glusterfs)
но компьютер не загрузился (пока не знаю почему).
Мне удалось выполнить эту работу с помощью комбинации ответов в этой теме и этой: GlusterFS не монтируется при загрузке
Согласно @Dan Pisarski править /etc/init/mounting-glusterfs.conf читать:
exec start wait-for-state WAIT_FOR=networking WAITER=mounting-glusterfs-$MOUNTPOINT
Согласно изменению @ dialt0ne /etc/fstab читать:
[serverip]:[vol] [mountpoint] glusterfs defaults,nobootwait,_netdev,backupvolfile-server=[backupserverip],direct-io-mode=disable 0 0
Работает для меня (tm) в Ubuntu 14.04.2 LTS
Я столкнулся с той же проблемой на AWS на ubuntu 12.04. Вот несколько вещей, которые сработали для меня:
Это позволит вам повторить попытку сервера volfile, пока сеть недоступна.
Это позволит вам смонтировать файловую систему с другого члена сервера gluster, если основной по какой-то причине не работает.
nobootwait в вашем fstabЭто позволяет экземпляру продолжить загрузку, пока эта файловая система не смонтирована.
Пример записи из моего текущего fstab:
10.20.30.40:/fs1 /example glusterfs defaults,nobootwait,_netdev,backupvolfile-server=10.20.30.41,fetch-attempts=10 0 2
Я не тестировал это 14.04, но он работает нормально для моих экземпляров 12.04.
Это действительно ошибка (статическое подключение к сети - это не работа, это сигнал события).
Более того, использование сетевого задания, как предлагается в других ответах, не является самым правильным решением.
Итак, я создал это отчет об ошибке и отправил патч к этой проблеме.
В качестве обходного пути вы можете применить предложенное мной решение (в конце этого ответа) и использовать _netdev вариант в вашем fstab.
Выше также показано лучшее объяснение, но вы можете пропустить это объяснение, если хотите.
Это ошибка в mounting-glusterfs.conf. Это может увеличить ненужные 30 секунд при загрузке на сервере Ubuntu или даже приостановить процесс загрузки.
Из-за этой ошибки процесс монтирования считает, что монтирование не удалось (вы увидите ошибки «Сбой монтирования» в /var/log/boot.log). Итак, когда не используется nobootwait/nofail флаги в /etc/fstab, ошибка может привести к зависанию процесса монтирования (и процесса загрузки тоже). При использовании nobootwait/nofail flags, ошибка увеличит время загрузки примерно на 30 секунд.
Ошибка вызвана следующими ошибками:
_netdev флаг монтирования, который будет повторять попытку монтирования при каждом запуске интерфейса;wait-for-state задача-выскочка ждать сигнала. Раньше ждал работы. static-network-up это сигнал о событии, а не о работе; WAIT_STATE=running env var, потому что это не по умолчанию в wait-for-state./etc/init/mounting-glusterfs.conf:
author "Louis Zuckerman <me@louiszuckerman.com>"
description "Block the mounting event for glusterfs filesystems until the glusterfs-server is running"
instance $MOUNTPOINT
start on mounting TYPE=glusterfs
task
script
if status glusterfs-server; then
start wait-for-state WAIT_FOR=glusterfs-server WAIT_STATE=running \
WAITER=mounting-glusterfs-$MOUNTPOINT
fi
end script
PS: Используйте также _netdev вариант в вашем fstab.
Спасибо за подробное объяснение, я думаю, что понимаю намного больше, чем раньше. Последнее решение почти работает. Проблемы (собственно одна, поскольку первое подразумевает второе):
127.0.0.1:/share) еще не смонтирован mounted TYPE=glusterfs никогда не устраивает, поэтому услуги, которые зависят от смонтированных TYPE=glusterfs штат/etc/fstab:
127.0.0.1:/control-share /mnt/glu-control-share glusterfs defaults,_netdev 0 0
/etc/init/mounting-glusterfs.conf: скопировано сверху
/etc/init/salt-master.conf:
description "Salt Master"
start on (mounted TYPE=glusterfs
and runlevel [2345])
stop on runlevel [!2345]
limit nofile 100000 100000
...
Локальный общий ресурс должен быть смонтирован вручную или каким-то автоматическим способом, salt-master должен запускаться вручную после всех перезагрузок.
Замечено позже: приведенный выше сценарий WAIT в mount-glusterfs ... блокирует всю процедуру загрузки, похоже, что состояние glusterfs-server никогда не достигает выполнения.
Я тоже столкнулся с этим и хочу предварять этот ответ заявлением о том, что я не эксперт в этой области, поэтому, возможно, есть лучшее решение для этого!
Но проблема, похоже, в том, что статическая сеть это событие, а не название выскочки. Тем не мение, состояние ожидания сценарий ожидает, что имя задания будет передано как значение WAIT_FOR. Таким образом, ошибка «Неизвестное задание», как вы обнаружили выше.
Чтобы решить эту проблему, я изменил /etc/init/mounting-glusterfs.conf, изменив:
exec start wait-for-state WAIT_FOR=static-network-up WAITER=mounting-glusterfs-$MOUNTPOINT
в:
exec start wait-for-state WAIT_FOR=networking WAITER=mounting-glusterfs-$MOUNTPOINT
сеть - это имя фактического задания (/etc/init/networking.conf), и я считаю, что задание, которое обычно вызывает static-network-up.
Это изменение сработало для меня в Ubuntu 14.04.
Мне удалось это с помощью действительно простого решения:
добавить точку монтирования в / etc / fstab
gluster:/VOLUME_NAME/local/mount/point glusterfs defaults,_netdev 0 0
добавьте одну строчку в свой /etc/rc.local, так это будет выглядеть так:
mount -a
exit 0
Теперь все Glusterfs тома будут монтироваться при запуске.