Назад | Перейти на главную страницу

Отказоустойчивость NFS не выполняется из-за устаревших файловых дескрипторов при переносе ресурсов

Столкнувшись с небольшой проблемой, я установил два сервера (Centos 6) с Glusterfs и общий каталог между ними, я переместил каталог nfs в общую папку Gluster и создал символическую ссылку на обоих устройствах. Машины могут общаться друг с другом через имена хостов, а репликация Gluster выполняется через другую карту Ethernet между серверами.

Проблема, с которой я столкнулся, заключается в том, что, несмотря на то, что ресурсы отключаются правильно (хотя кажется, что при сбое он несколько раз поднимается и отключается), я получаю устаревшие дескрипторы nfs на клиенте. Ниже моя конфигурация crm; Что я делаю не так?

Монтирование nfs на клиенте максимально простое.

node GlusterFS01 
node GlusterFS02 
primitive ClusterIP ocf:heartbeat:IPaddr2 \ 
        params ip="10.10.10.167" cidr_netmask="24" clusterip_hash="sourceip" \ 
        op monitor interval="5s" 
primitive exportfs ocf:heartbeat:exportfs \ 
        params fsid="0" directory="/GlusterFS/Files" \
        options="rw,sync,no_subtree_check,no_root_squash" \ 
        clientspec="10.10.10.0/24" \        
        wait_for_leasetime_on_stop="false" \ 
        op monitor interval="5s" \ 
        op start interval="0s" timeout="240s" \ 
        op stop interval="0s" timeout="100s" \ 
        meta is-managed="true" target-role="Started" 
primitive nfs lsb:nfs \ 
        meta target-role="Started" \ 
        op monitor interval="5s" timeout="5s" 
colocation sitewithnfs inf: ClusterIP exportfs nfs 
order nfsorder inf: exportfs ClusterIP nfs 
property $id="cib-bootstrap-options" \ 
        dc-version="1.1.10-14.el6_5.2-368c726" \ 
        cluster-infrastructure="classic openais (with plugin)" \ 
        expected-quorum-votes="2" \ 
        stonith-enabled="false" \ 
        no-quorum-policy="ignore" \ 
last-lrm-refresh="1395246465" \ 
        default-resource-stickiness="100" 
rsc_defaults $id="rsc-options" \ 
        resource-stickiness="100" 

Спасибо за уделенное время.

Обновление1: я решил, что все усложняю. После разговора с Флорианом он убедил меня упростить. Я делюсь nfs напрямую из Gluster, и у меня просто ресурс ip обрабатывается corosync / pacemaker. Намного более простое решение, соответствующее моим потребностям.

Однако я скажу, что Док был полностью прав в своих оценках и предложениях, хотя мне не удалось запустить его на 100% в производственной среде (даже мысль, что это работает при тестировании).

место размещения с nfs inf: ClusterIP exportfs nfs

заказать информацию о nfsorder: exportfs ClusterIP nfs

Во-первых, я считаю, что вы хотите запустить nfsd перед экспортом.

Добавление unlock_on_stop="true" Параметр агента ресурсов exportfs также может помочь, но что действительно имело значение в моем тестировании, так это остановка виртуального IP во время отработки отказа. Я не совсем уверен, почему, но подозреваю, что это связано с закрытием соединений перед попыткой остановить экспорт.

Кроме того, я помню, что в более старых версиях кардиостимулятора были проблемы с «наборами ресурсов» (т. Е. С ограничениями упорядочения и размещения более двух ресурсов). Вместо этого я бы предложил удалить ваши ограничения порядка и размещения и заменить их одной группой ресурсов, например:

group g_nfs nfs exportfs ClusterIP

P.S. Агент ресурсов exportfs должен обрабатывать все операции экспорта. Ваш файл / etc / exports должен быть пустым.