У меня следующая проблема с кластером OenSuSE + Heartbeat + Pacemaker + Xen HA: когда узел, на котором работает Xen domU, "мертв", Xen domU, работающий на нем, является не перезапустился на втором узле.
Кластер состоит из двух узлов, на каждом из которых работает OpenSuSE-11.3, Heartbeat 3.0 и Pacemaker 1.0 в режиме CRM. Для хранения я использую LUN на устройстве iSCSI SAN; LUN отформатирован с помощью OCFS2 и управляется LVM. Xen domU имеет два логических тома; один для root, а другой для свопа. Я использую карты IPMI для устройств STONITH и выделенный канал Ethernet для связи с тактом.
Файл ha.cf выглядит следующим образом:
keepalive 1
deadtime 10
warntime 5
udpport 694
ucast eth1
auto_failback off
node dhcp-166
node stage
use_logd yes
crm yes
Мои ресурсы выглядят следующим образом:
shocrm(live)configure# show
node $id="5c1aa924-bba4-4f95-a367-6c9a58ac4a38" dhcp-166
node $id="cebc92eb-af24-4833-aaf0-672adf80b58e" stage
primitive Xen-Util ocf:heartbeat:Xen \
meta target-role="Started" \
operations $id="Xen-Util-operations" \
op start interval="0" timeout="60" start-delay="0" \
op stop interval="0" timeout="120" \
params xmfile="/etc/xen/vm/xen-util"
primitive my-stonith stonith:external/ipmi \
params hostname="dhcp-166" ipaddr="192.168.3.106" userid="ADMIN" passwd="xxx" \
op monitor interval="2m" timeout="60s"
primitive my-stonith2 stonith:external/ipmi \
params hostname="stage" ipaddr="192.168.3.105" userid="ADMIN" passwd="xxx" \
op monitor interval="2m" timeout="60s"
property $id="cib-bootstrap-options" \
dc-version="1.0.9-89bd754939df5150de7cd76835f98fe90851b677" \
cluster-infrastructure="Heartbeat"
Конфигурационный файл Xen domU выглядит следующим образом:
name = "xen-util"
bootloader = "/usr/lib/xen/boot/domUloader.py"
#bootargs = "xvda1:/vmlinuz-xen,/initrd-xen"
bootargs = "--entry=xvda1:/boot/vmlinuz-xen,/boot/initrd-xen"
memory = 4096
disk = [ 'phy:vg_xen/xen-util-root,xvda1,w',
'phy:vg_xen/xen-util-swap,xvda2,w', ]
root = "/dev/xvda1"
vif = [ 'mac=00:16:3e:42:42:06' ]
#vfb = [ 'type=vnc,vncunused=0,vnclisten=192.168.3.172' ]
extra = ""
Скажем, domU «Xen-Util» работает на узле «stage»; если "stage" выходит из строя, "Xen-Util" делает не перезапустите узел "dhcp-166". Кажется, он хочет попробовать, поскольку «список xm» покажет его в течение нескольких секунд, и если вы «xm console xen-util», он выдаст сообщение типа «копирование /boot/kernel.gz из xvda1 в / var / lib /xen/tmp/kernel.a53gs для загрузки ». Однако это никогда не проходит, в конце концов сдается и больше не появляется в «списке xm». Теперь, когда узел «stage» возвращается в режим онлайн после выключения и включения питания, он обнаруживает, что «Xen-Util» не работает, и запускает его (на сцене).
Я пробовал запустить "Xen-Util" на узле "dhcp-166" без кластер работает, и он работает нормально. Без проблем. Итак, я знаю, что в этом отношении это работает.
Любые идеи? Спасибо!
Я понял это после еще немного проб и ошибок. Я получал ошибки iSCSI при слишком быстром резервном копировании стека, как упоминалось в этот пост на ServerFault.
В дополнение к изменению переменных, описанных в сообщении выше, я также проследил некоторые сетевые кабели и обнаружил, что узел №2 находился на канале 100 Мбит, а узел №1 был на канале Gig вместе с SAN. После некоторого тщательного перемешивания все сетевые соединения теперь работают на гигабитных скоростях.
Наконец, я изменил MTU на интерфейсах Linux с 1500 до 9000, что, похоже, также немного ускорило работу.
Конечным результатом является рабочий кластер с загрузкой domU на узле №1 даже быстрее, чем раньше.
Привет,
Кендалл