Я настраиваю двухузловой кластер 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#Defining_The_Resources
или даже просто включить такие службы, как clvm и gfs2, для автоматического запуска при загрузке (http://pbraun.nethence.com/doc/filesystems/gfs2.html), лайк:
chkconfig gfs2 on
Если я правильно понимаю последний подход, такой кластер только контролирует, живы ли еще узлы, и может ли заблокировать ошибочные, но такой кластер не контролирует состояние своих ресурсов.
У меня есть некоторый опыт работы с Pacemaker, и я привык, что все ресурсы контролируются кластером, и можно предпринять действия, когда не только возникают проблемы с подключением, но и какие-либо ресурсы работают неправильно.
Итак, какой путь для меня правильный:
<script file="/etc/init.d/gfs2" name="gfs"/> для управления разделом GFS.Это может быть своего рода вопрос, на который нельзя ответить однозначно, поэтому для меня было бы очень полезно, если бы вы поделились своим опытом или высказали свои мысли по этому поводу. Как, например, выглядит /etc/cluster/cluster.conf при настройке gfs с Conga или ccs (они мне недоступны, поскольку сейчас я должен использовать Ubuntu для кластера)?
Спасибо большое!
Я немного поработал с кластерами. Это мое мнение по этому поводу.
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 на кластерном узле.
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Я также могу вспомнить несколько недостатков:
updatedb и другие задания, которые могут захотеть пересечь файловую систему, тем самым вызывая задержку диска (блокировку трафика)Я бы добавил сценарий инициализации как кластерный ресурс, и если вы решите добавить gfs и clvm в кластер в качестве ресурсов, я бы подумал о добавлении __independent_subtree к нему, поэтому в случае сбоя rgmanager не смонтирует файловую систему gfs повторно. Это, конечно, зависит от вашей конкретной ситуации. Обратите внимание на вложенную конфигурацию в ссылке, помеченную как своего рода дерево зависимостей.