RHCS: GFS2 в кластере A/A с общим хранилищем. Конфигурирование GFS с помощью rgmanager

Я настраиваю двухузловой кластер A/A с общим хранилищем, подключенным через iSCSI, который использует GFS2 поверх кластерного LVM. Пока что я подготовил простую конфигурацию, но не уверен, какой правильный способ настроить ресурс gfs.

Вот раздел rm /etc/cluster/cluster.conf:

<rm>
    <failoverdomains>
        <failoverdomain name="node1" nofailback="0" ordered="0" restricted="1">
            <failoverdomainnode name="rhc-n1"/>
        </failoverdomain>
        <failoverdomain name="node2" nofailback="0" ordered="0" restricted="1">
            <failoverdomainnode name="rhc-n2"/>
        </failoverdomain>
    </failoverdomains>
    <resources>
        <script file="/etc/init.d/clvm" name="clvmd"/>
        <clusterfs name="gfs" fstype="gfs2" mountpoint="/mnt/gfs"  device="/dev/vg-cs/lv-gfs"/>
    </resources>
    <service name="shared-storage-inst1" autostart="0" domain="node1" exclusive="0" recovery="restart">
        <script ref="clvmd">
            <clusterfs ref="gfs"/>
        </script>
    </service>
    <service name="shared-storage-inst2" autostart="0" domain="node2" exclusive="0" recovery="restart">
        <script ref="clvmd">
            <clusterfs ref="gfs"/>
        </script>
    </service>
</rm>

Вот что я имею в виду: при использовании агента ресурса clusterfs для обработки раздела GFS он не отключается по умолчанию (если не указана опция force_unmount). Таким образом, когда я выпускаю

clusvcadm -s shared-storage-inst1

clvm остановлен, но GFS не размонтирована, поэтому узел больше не может изменять структуру LVM в общем хранилище, но все же может получать доступ к данным. И хотя узел может сделать это довольно безопасно (dlm все еще работает), это кажется мне неуместным, так как clustat сообщает, что служба на конкретном узле остановлена. Более того, если позже я попытаюсь остановить cman на этом узле, он обнаружит блокировку dlm, созданную GFS, и не сможет остановиться.

Я мог бы просто добавить force_unmount="1", но я хотел бы знать, что является причиной поведения по умолчанию. Почему это не размонтировано? Большинство примеров там молча используют force_unmount="0", некоторые нет, но ни один из них не дает никакой подсказки о том, как было принято решение.

Кроме того, я нашел примеры конфигураций, где люди управляют разделами GFS с помощью сценария инициализации gfs2 - https://alteeve.ca/w/2-Node_Red_Hat_KVM_Cluster_Tutorial

или даже просто включив такие службы, как clvm и gfs2, для автоматического запуска при загрузке ( http://pbraun.nethence.com/doc/filesystems/gfs2.html), например:

chkconfig gfs2 on

Если я правильно понимаю последний подход, такой кластер только контролирует, все ли узлы еще живы, и может блокировать ошибочные, но такой кластер не контролирует состояние своих ресурсов.

У меня есть некоторый опыт работы с Pacemaker, и я привык к тому, что все ресурсы контролируются кластером, и действие может быть предпринято, если не только проблемы с подключением, но и любой из ресурсов ведет себя неправильно.

Итак, какой путь для меня правильный:

  1. оставить раздел GFS монтированным (какие-либо причины для этого?)
  2. set force_unmount = "1". Это ничего не сломает? Почему это не по умолчанию?
  3. использовать ресурс скрипта <script file="/etc/init.d/gfs2" name="gfs"/> управлять разделом GFS.
  4. запустите его при загрузке и не включайте в cluster.conf (какие-либо причины для этого?)

Это может быть своего рода вопрос, на который нельзя ответить однозначно, поэтому для меня было бы также очень полезно, если бы вы поделились своим опытом или высказали свои мысли по этому вопросу. Как, например, /etc/cluster/cluster.conf выглядит при настройке gfs с Conga или ccs (они мне недоступны, так как на данный момент я должен использовать Ubuntu для кластера)?

Большое вам спасибо!

Источник

1 ответ

Я немного работал с кластерами. Это мои мнения по этому вопросу.

could have simply added force_unmount="1",  but I would like to know what is
the reason behind the default behavior. Why is it not unmounted?

Если вы решите настроить GFS как кластерный ресурс, и добавьте clvmd а также gfs диск в качестве ресурсов, то при переключении с rgmanager он попытается размонтировать диск, поэтому сначала я проверю логи (или lsof/fuser и т. д.) для указания причины сбоя при монтировании. Вероятно, есть процесс с открытым файлом или чем-то в этом роде, препятствующий "чистому" размонтированию.

Может быть потому, что вы не используете rgmanager для запуска кластерного приложения? Я не вижу этого в вашем cluster.conf. Это, если правда, объяснит поведение.

Если вы решитеforce_unmountто, что rgmanager сделает при сбое / восстановлении, принудительно уничтожит любой ресурс, используя диск перед размонтированием диска. Погода это хорошая идея или нет, зависит.

clvm is stopped, but GFS is not unmounted, so a node cannot alter LVM structure 
on shared storage anymore, but can still access data. And even though a node can 
do it quite safely (dlm is still running), [...]  
Moreover if I later try to stop cman on that node, it will find a dlm locking,
produced by GFS, and fail to stop.

Если вы хотите изменить структуру LVM в этом сценарии, вы можете вручную запустить демон clvmd. если вы размонтируете диск gfs до остановки cman, это должно сработать. С другой стороны, в производственном сценарии я редко бываю в ситуации, когда я хочу остановить CMAN на кластерном узле.

Я предпочитаю использовать вариант 4.

If I understand the latest approach correctly, such cluster only controls 
whether nodes are still alive and can fence errant ones, but such cluster
has no control over the status of its resources.

Это правда, что если вы не добавитеgfs2а такжеclvmdресурс как кластерный ресурс, rgmanager не смогу это контролировать. Что я обычно делаю при настройке кластеров upp A/A (в зависимости от конкретного случая), так это то, что я добавляю стартовый скрипт для моей службы в качестве кластерного ресурса. (rgmanager затем вызовет скрипт с statusаргумент на регулярной основе, чтобы определить погоду, необходимо принять настроенные действия). Поскольку мой сценарий зависит от файловой системы gfs, он не будет работать, если он не смонтирован.

Подход 4 подразумевает ручное включениеclvmd,cmanа также gfs2(и, возможно, другие демоны тоже в зависимости от ситуации).

Поскольку файловая система GFS находится поверх устройства iSCSI, добавление _netdevвариант для крепления в/etc/fstabэто требование для его работы.

  • Таким образом, я не получаю слишком сложную конфигурацию кластера, добавление большего количества сервисов позже будет меньшей головной болью (скажем, например, два сервиса, использующие один и тот же диск или что-либо еще)
  • когда что-то случается, мой опыт показывает, что ручное вмешательство намного проще с ресурсами,не управляемыми rgmanager
  • По моему опыту, не кластер gfs2 или clvmd больше всего работает неправильно в кластере, а сервисы на вершине, поэтому их повторный запуск / монтирование часто займет у вас дополнительное время.

У меня есть несколько недостатков:

  • Как вы сказали, rgmanager не будет управлять этими ресурсами и не будет предпринимать никаких действий, если, например, файловая система gfs каким-то образом выйдет из строя / размонтируется
  • много файловой системы gfs может привести к ненужной нагрузке на устройство, например,updatedbи другие задания, которые могут потребоваться для обхода файловой системы, что приводит к задержке диска (блокировка трафика)

Неважно, что вы решите

Я хотел бы добавить сценарий инициализации в качестве кластерного ресурса, и если вы решили добавитьgfsа такжеclvmдля кластера в качестве ресурсов, я хотел бы рассмотреть возможность добавления к нему атрибута __independent_subtree, поэтому в случае сбоя rgmanager не будет повторно монтировать файловую систему gfs. Это зависит, конечно, от вашей конкретной ситуации. Обратите внимание на вложенную конфигурацию в ссылке, отмечая своего рода дерево зависимостей.

Источник
Другие вопросы по тегам