Guest User!

You are not Sophos Staff.

[NOTABUG] [7.386] Setting 2 nodes as cluster actif/actif does not work (properly) ?

Hi

I've just installed 2 news asg into 2 differents VMs both with 4 interfaces and bridged at VM level...
both astaro are working fines independantly... then I go in HA to set:

- for asg1:
operation mode: cluster actif/actif
sync interface: eth0
device name: asg1
device node id: 1
encryption key: ...
repeat: ...

so asg1 is becoming MASTER

- then on asg2 (I intentionnaly test that way):
operation mode: cluster actif/actif
sync interface: eth0
device name: asg2
device node id: 2
encryption key: ... (same as on asg1)
repeat: ...

then when connecting on asg1 I get first snapshot with only one line for asg1 MASTER then on system status I get 2 nodes... I think there is something wrong with HA detection/statuses ?

when on the asg1 console I get a  prompt and when on asg2 I get a  prompt

maybe related to that bug from CraigD ?

[7.385] Did something change for HA, can't get it to work?

thx
Parents
  • I did a reboot of asg2 it did not helped...

    then I did reboot asg1 and now I see both nodes.... so probably something wrong and not started/restarted properly ?

    thx
  • oh forgot something maybe important...

    initial version for asg1 was 7.386 and I intentionnaly installed 7.380 on asg2 to see what happening in that case... then I activated cluster as described...

    thx
  • Can you enter the command "hs" on both nodes and post the output ?

    Is the ASG Master node connected to the Internet, so the Slave can download the necessary up2date packages to update to the master version ?


    unfortunately I rebooted both astaro since... and messages are differents... here are the attached screenshots..

    [ATTACH]1178[/ATTACH]

    [ATTACH]1179[/ATTACH]
  • have you tried to disable HA then manually Update the Astaros to the same Firmware Verson (7.386) and then enable HA again if this fix the error?
  • Ok seems there is an connectivity error. Slave can see the Master,
    however Master has now knowledge of the Slave.

    Slave probably hangs in the state of validating the HA secret key.

    Can you try to ping the HA Master from Slave node?
    ping 198.19.250.1
  • have you tried to disable HA then manually Update the Astaros to the same Firmware Verson (7.386) and then enable HA again if this fix the error?


    will do.. but how can we be sure it will be done correctly when 7.400 will be final.. as upgrade is supposedly supported that way ! [:)]

    thx
  • Thought about it again and found probably the error:

    VMware disables Ethernet interfaces in case of mac address conflicts.
    Official ASG VMware images have for each Ethernet interface this line
    in the vmware vmx configuration file:

    ethernet0.ignoreMACAddressConflict = "TRUE"

    Please add this line for each Ethernet interface, replace ethernet0 with ethernet1 etc...

    ASG HA/Cluster adds virtual MAC addresses on each interface,
    which are equal on all HA/Cluster nodes.
  • Thought about it again and found probably the error:

    VMware disables Ethernet interfaces in case of mac address conflicts.
    Official ASG VMware images have for each Ethernet interface this line
    in the vmware vmx configuration file:

    ethernet0.ignoreMACAddressConflict = "TRUE"

    Please add this line for each Ethernet interface, replace ethernet0 with ethernet1 etc...

    ASG HA/Cluster adds virtual MAC addresses on each interface,
    which are equal on all HA/Cluster nodes.


    oups sorry this is not VMware VMs... but Citrix XenServer VMs (xenserver 5.0 express edition) which is to me far better than vmware [:)]
    I think first times I tested cluster active/active with 7.200 or 7.300 (I did not remember actually...) that was working fine on a xenserver 4.1...
    but I'm setting up 2 news VMs which will be exact same version 7.386 and will test with 7.305 if it's not working with 7.386 and will let you know..

    thx
  • ok I've setup 2 new astaro 7.386 with cluster active/active as described earlier...

    and I get asg2 as WORKER with state UNINITIALIZED and asg1 ACTIVE when runing hs on asg2.
    and only asg1 as MASTER with state ACTIVE when running hs on asg1

    what does mean UNINITIALIZED ? can I run anything manually to update the state ?

    thx
  • i have looked at your config and you use eth0 as sync interface. have you tried to use eth1 or something else as sync interface? In my Enviroment i have setup eth0 as WAN Interface eth1 as LAN Interface and eth2 as sync Interface (not shown in Network/Interface Tab) and all seems to work fine
  • ok this is really a problem with the 7.400 beta !!!!!

    I did install 7.305 and did configuration exactly the same way as I did for 7.386 and this is working fine with 7.305 (with same hardware, same xenserver, and same way of configuration) whereas it still does not work with 7.386 !!!!!

    so this is really a BUG for 7.400 betas [:(]

    note1: during my tests of course only both astaro 7.305 were running, and when tested with 7.386 only both 7.386 astaro were running
    edit1: after one day configuration for 7.386 active/active cluster all things still at same state ! when executing hs I have only one line for asg1 ACTIVE on asg1, and asg1 ACTIVE and asg2 UNINITIALIZED on asg2
  • Is it possible to get ssh access to the Master Node?

    have you tried to ping each nodes? e.g. ping 198.19.250.1
Reply Children
  • Is it possible to get ssh access to the Master Node?

    have you tried to ping each nodes? e.g. ping 198.19.250.1


    I can't ping anything from the asg2, I get Operation not permitted.. I've also tried to add eth3 manually through console and set an ip for it with same result...

    I'm about to PM infos to connect to both astaro...

    thx
  • Thanks for the possibility to login!

    Seems your HA interface (eth0) is not separated from the other two Ethernet interfaces.


    The default behavior of Linux is to answer from all interfaces for ARP requests. So the ARP request is send from eth0 on Master to the Slave and Slave receives multiple requests on all interfaces.

    So its random, which interface answers first. In case its the wrong interface, the packets will have the destination MAC address of another interface, means packets will not be received on HA interface and be dropped by packet filter.

    There's no difference in 7.300 or 7.400 here. Its just luck if the right interface answers first...
  • Thanks for the possibility to login!

    Seems your HA interface (eth0) is not separated from the other two Ethernet interfaces.


    The default behavior of Linux is to answer from all interfaces for ARP requests. So the ARP request is send from eth0 on Master to the Slave and Slave receives multiple requests on all interfaces.

    So its random, which interface answers first. In case its the wrong interface, the packets will have the destination MAC address of another interface, means packets will not be received on HA interface and be dropped by packet filter.

    There's no difference in 7.300 or 7.400 here. Its just luck if the right interface answers first...



    ok thx for the explanations... and sorry for that one...
    so HA iface should never be connected on the same switch as other interface ? or at least isolated in a dedicated vlan ?

    so basically what can I do to make it recognized in my test case ? any command to run ? maybe ifconfig down all interfaces and restart something ? or arping with the right iface to send gARP ?

    finally once the things are set with the right HA iface I should have no other problems due to random arp advertising ?

    thx
  • Yes, HA or Cluster should have their own designated switch oder vlan tag.

    You can make it "work" by assigning static arp entries, e.g. "arp -s 198.19.250.2 00:11:22:33:44:55"
    on both nodes. But thats not recommended.

    Just assign the HA interface on a designated Virtual Switch, should be possible with vmware or xen.
    Thats the proper way and you can be sure not to run in any other problems, caused by that.