TOPIC:

Hi,
many thanks for your reply.

I have just run commmand /etc/ha-lizard/scripts/recover_fenced_host on slave and when I turned off master, slave become a master. Nice!

but:(

1.In XenCenter, pool is still identifies with old master IP address. Should be the new one, yes ?
I can only connect to pool by defining new connection in XenCEnter and create connect to pool with new master IP address.

2. When I turn on master, I have to masters in pool and assigned virtual IP address 10.10.10.3 in two machines. Now no one want be a slave.

I send logs from two machines.
I hope you can help me once again.

When re-introducing the former master into the pool - it will automatically become a slave. Also - xencenter will alert you of this when you attempt to connect to the pool and ask if you would like to connect to the new master. This all works as long as the management interfaces of the 2 hosts can see eachother. Are you perhaps starting the former master with its manaagent interface disconnected?

Also, the log shows DRBD is disconnected - is the DRBD link removed when you start the former master? It is important that the replication link be dedicated (direct cable) and always connected. This prevents both hosts from becoming the master storage node.

If the above is all OK - please send a cabling diagram of how the hosts are connected and the exact procedure you used to test

Ok, it is working but only if I completely turn of the master machine.
1. Slave become a master
2. I can connect manualy to pool from XenCenter by a ip address of new master

3. When master back to live, it automatically become now a slave in pool.



What I did previously, and why it not working ? Logs from this situations I sent You in my last answer

1. If I unlink network from master (all network - managment and iSCSI target) slave become a master
2. When master back to live, I link all networks, I have two masters in pool and two the same virtual ip address on them

Where I am making a logical error. I wonder, because only the network cards may faild and what happens then ?

How it looks my network connection:
XCP1 and XCP2 have two cards, managment XCP1 has 192.168.1.100 address, managment XCP2 has 192.168.1.200, they are connected to the same network switch.

Second network on both machines is for iSCSI connection target, and now they are connected to each other by cross cable.

Thanks

To avoid this situation you should set some additional IPs in the list of heuristic IPs. The settings should be placed in the override configration file for each host and not shared globally as usual.

For XCP1 - set 8.8.8.8 AND 10.10.10.2 (the replication IP of the slave)
for XCP2 - set 8.8.8.8 AND 10.10.10.1 (the replication IP of the Master)

Now - if you remove the replication link, the slave will not promote itself to Master and will instead reboot once and enter the "Suspended" HA mode.

How to use the heuristic IP list is discussed in the documentation. You can customize to suit your needs with the above settings.

Hi,
I have added a configuration to pool like you said, I made many attempts, but still I have a issue when network interface is unplugged

Now I have configurations:
XCP2 - master 192.168.1.200, 10.10.10.2, 10.10.10.3
XCP1 - slave 192.168.1.100, 10.10.10.1

Switch IP address is 10.10.10.254, this is switch where NICs from 10.10.10.x class are connected to it.

In "heuristics_ips" I added switch IP address

FENCE_HEURISTICS_IPS=10.10.10.254

If I unlink network cable 10.10.10.2 from XCP2 machine virtual IP address 10.10.10.3 is still assigned to XCP2, even if it does not have connection with 10.10.10.x class

In XenCenter I have status of iSCSI = Broken, XCP2 is connected, XCP1 Unplugged

XCP1

HOST ROLE: SLAVE
VIRTUAL IP: 10.10.10.3 is not local
ISCSI TARGET: tgtd is stopped
DRBD ROLE: iscsi1=Secondary
DRBD CONNECTION: iscsi1 in WFConnection state

XCP2

HOST ROLE: MASTER
DRBD ROLE: iscsi1=Primary
DRBD CONNECTION: iscsi1 in WFConnection state
ISCSI TARGET: tgtd (pid 9009 9008) is running...
VIRTUAL IP: 10.10.10.3 is local

In attachments I send You logs from this situation.

I have also the same problem when I added in XCP1 in /etc/ha-lizard/ha-lizard.cfg FENCE_HEURISTICS_IPS=10.10.10.2 and on XCP2 FENCE_HEURISTICS_IPS=10.10.10.1

Regards

It looks like you have your replication interfaces connected via a switch and your test procedure involves removing the replication link from your master.


You should avoid putting any switches in the replication path (see our documentation). This link should be directly attached between the hosts.


Also - it is not possible for this solution or any HA solution to recover from all failure scenarios, so, the configuration settings should be considered and tailored to the type of failure you would like to recover from. Selection of the heuristic IP addresses will give you control over what needs to happen. Most implementations are designed to recover from a host failure rather than loss of the replication link which would be a less likely scenario.



Regarding your test results: Since you are removing just the replication link, there is no failure event triggered (as it relates to HA). The master will continue to operate with its VM unaffected. When the replication link becomes re-attached - the slave's storage will apply all changes that were written to the master's storage while the link was down.

An HA event is triggered only when the management port of the peer host becomes unavailable. You may want to consider an alternate test scenario such as crashing one of the hosts or removing the management interface from one of the hosts.