Настройка: Два свежих сервера CentOS 6.5 с последними обновлениями. У обоих есть свежая установка Gluster 3.5.2.
Что я сделал (с точки зрения сервера 2 shared1 и shared2 являются логическими томами):
wget -P /etc/yum.repos.d http://download.gluster.org/pub/gluster/glusterfs/LATEST/CentOS/glusterfs-epel.repo
yum -y install glusterfs glusterfs-fuse glusterfs-server -y
/etc/init.d/glusterd start
chkconfig --level 345 glusterd on
echo "1.2.3.4 server1" >> /etc/hosts
echo "4.3.2.1 server2" >> /etc/hosts
gluster peer probe server1
gluster volume create shared replica 2 transport tcp server2:/shared2 server1:/shared1 force
gluster volume start shared
mount.glusterfs server2:/shared /mnt/shared
gluster peer status
Это сработало отлично, и у меня есть хорошая общая файловая система на / mnt / shared на обоих серверах. Набор команд был выполнен на каждом сервере соответственно и изменен в соответствии с точкой зрения этого сервера.
Тестирование:
Если я нажму кнопку сброса на server1, у меня будет ужасная задержка ~ 45 секунд при использовании или доступе к файлам в / mnt / shared
Я искал решение в google, руководстве администратора glusterfs и на serverfault, но, похоже, ни у кого нет этой проблемы.
Есть какие-нибудь советы о том, как уменьшить таймауты или временно игнорировать неработающий узел? Состояние «только для чтения» во время аварийного переключения - это нормально, если нет задержек. Или просто скажите мне, что я сделал не так или не сделал.
Спасибо,
Возможно, вы страдаете от настройки тайм-аута клиентского пинга, поскольку по умолчанию он составляет 42 секунды. Выполните следующее, чтобы проверить:
gluster volume info shared
Требуемый параметр - «network.ping-timeout». Вы можете изменить это, запустив
gluster volume set shared network.ping-timeout "new timeout value"
Посмотрите, сокращает ли это период восстановления.