David Martin (IT | 14 Oct 11:18 2011
Picon

Re: Cluster Activeonbothnodesatthesametime

In my tests you can do it without downing the interface but I think it will still confuse UCARP.

 

On the ARP front, I’ve just done a preliminary test on the switches by debugging ARP traffic. I’ve cut the logs down quite a bit (each of these switches has at least 8 10Gig ports and they are pretty busy).

 

Oct 14 09:53:28.205 UTC: IP ARP: rcvd req src 10.200.28.172 0050.5602.8172, dst 10.200.28.254 Vlan28

Oct 14 09:53:28.205 UTC: IP ARP: sent rep src 10.200.28.254 0000.0c07.ac01, dst 10.200.28.172 0050.5602.8172 Vlan28

Oct 14 09:53:39.797 UTC: IP ARP: rcvd req src 10.200.28.171 0050.5602.8171, dst 10.200.28.254 Vlan28

Oct 14 09:53:39.797 UTC: IP ARP: sent rep src 10.200.28.254 0000.0c07.ac01, dst 10.200.28.171 0050.5602.8171 Vlan28

Oct 14 09:53:50.145 UTC: IP ARP: rcvd req src 10.200.28.175 0050.5602.8172, dst 10.200.28.175 Vlan28

Oct 14 09:53:50.145 UTC: IP ARP: rcvd req src 10.200.28.175 0050.5602.8172, dst 10.200.28.175 Vlan28

Oct 14 09:53:51.145 UTC: IP ARP: rcvd req src 10.200.28.175 0050.5602.8172, dst 10.200.28.175 Vlan28

Oct 14 09:53:51.145 UTC: IP ARP: rcvd req src 10.200.28.175 0050.5602.8172, dst 10.200.28.175 Vlan28

Oct 14 09:54:14.953 UTC: IP ARP: rcvd req src 10.200.28.172 0050.5602.8172, dst 10.200.28.171 Vlan28

Oct 14 09:54:14.953 UTC: IP ARP: rcvd req src 10.200.28.172 0050.5602.8172, dst 10.200.28.171 Vlan28

Oct 14 09:54:15.953 UTC: IP ARP: rcvd req src 10.200.28.172 0050.5602.8172, dst 10.200.28.171 Vlan28

Oct 14 09:54:15.953 UTC: IP ARP: rcvd req src 10.200.28.172 0050.5602.8172, dst 10.200.28.171 Vlan28

 

This is taken just as I pull the network card on node 1 (10.200.28.171). the eth0:cl address is 10.200.28.175 and the eth0:vip01 address (my test farm) is 10.200.28.173.  Interestingly, the :cl interface ARP gets updated but the 10.200.28.173 does not.

 

I have tried ping tests on the :cl interface and that does failover correctly….. it’s just the farms that don’t work

 

David

 

From: laura Garcia [mailto:nevola-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 14 October 2011 08:24
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Definitely, it's not possible to change the MAC address. To change the MAC address we've to do a down of the physical interface, change the MAC, and then, up the interface again. Meanwhile this process is done, the CARP diagnoses a problem with the network interface (that it has been down) and then, try to failover again.

CARP doesn't wait for the timeout of ARP tables, like you said, it sends gratuitous ARP packets that would be enough to update the ARP tables on the switches. Did you have analyzed the traffic between vmware servers?

Regards,
Laura.

On Thu, Oct 13, 2011 at 5:26 PM, David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org> wrote:

You are right, sorry. It looks like it is quite involved to get more than one mac on a card. There are some linux TAP/TUN drivers that can do it but it looks pretty complex.

 

From: laura Garcia [mailto:nevola-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 13 October 2011 16:07
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

You're right, but I've been doing some testing and the system doesn't allow to change a MAC address of a virtual interface. You've to change the physical parent MAC to get it works.

On Thu, Oct 13, 2011 at 4:59 PM, David Martin (IT) <dmartin-ANfHjr1BzNdhl2p70BpVqQ@public.gmane.org.uk> wrote:

Emilio,

 

I’d love to help with any testing you want.

 

In the meantime, I’ve been looking through the ucarp documentation and the zen source so I can get a better idea of how failover is working.

 

It looks from the documentation like ucarp should be sending a Gratuitous ARP when the failover occurs so that the router can update the arp table. I’m going to have a play with wireshark later today to see if I can capture and examine this packet. If that is not working with VMware for some reason, then that might be why my failover times are so long.

 

On the mac address front, I think it should be relatively easy to change the MAC address of the vip as it comes up. In the  zenlatancy-start script you could do something like the following to change the mac address of the VIP:

 

# You already do this bit to ‘up’ the interface

ip addr add 10.200.28.174\/255.255.255.0 dev eth0\:test label eth0\:test

#This tells the kernel to reset the link address

ip link set eth0\:test address 00:11:22:33:44:55

 

You would need to have a place on the interface to edit the virtual mac address (and a way of setting it to default if someone changed it automatically), and you would have to change the interface definition file but otherwise I think everything else should just work.

 

Please don’t think I’m telling you how to develop or what direction to take Zen. It’s a great product and I’m just enthusiastic.

 

Cheers

 

David

 

 

From: Emilio Campos [mailto:emilio.campos.martin <at> gmail.com]
Sent: 13 October 2011 14:51
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Hi David, at this moment UCARP can't share the mac address but we could study for add this new property

We have to study the time for develope this, maybe a process that generate an automatic mac could be interesting, or one process for introduce your own personalized mac.

We could add this but not on stable version, only release candidate, if you are interested on this, you could help us with the test

At the moment we can send you a work around for test this on your environment.

And you feel free for do donations :P

Regards

2011/10/13 David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org>

Laura,

 

This has not made any difference, sorry. I have done a bit more digging and given the issue a lot of thought and I think the following (very long, sorry) describes what is going on, at least in my environment.

 

When testing this using a local zen cluster (i.e. on the same subnet) the failover happens fairly quickly, within about 30 seconds.

 

When the cluster is on a remote subnet, the failover takes anything up to an hour.

 

The reason behind this, as far as I can see, it that Windows 7 has a very short ARP timeout (randomly selected between 15-45 seconds). The ARP entry that was mapping say:

MAC Address 00:0c:29:06:d0:a5 to    IP address   159.180.232.243

In my previous example will quickly time out and be replaced by

MAC Address 00:0c:29:8e:91:fa to    IP address   159.180.232.243

as the second node takes over.

 

When the cluster is remote, you are relying on the ARP table in the last router in the chain. By default, Cisco use and recommend an ARP timeout of four hours. This can be changed, but at the expense of increased ARP traffic, CPU load and in some cases latency. To better suit our VMWare environment, we have reduced this timeout to just one hour which we found to be a good compromise.

 

To get around this very long timeout, protocols like HSRP, GLBP, VRRP and CARP create a virtual mac address that both nodes share. When a node dies the network interface goes down and the switch immediately flushes its CAM table, meaning that the mac address almost instantly is available on the second node.

 

I suspect that by introducing the concept of a virtual mac address to Zen, this fast switchover can be achieved.

 

On the other hand, I could be doing something very wrong and, if so, please point it out! I’d be especially grateful if any other users could share their experience of Zen on a non-local subnet and what ARP timeouts are in use on the Zen VLAN.

 

Thanks for your patience once again, I definitely feel a donation will be in order soon!

 

David

 

 

 

From: laura Garcia [mailto:nevola-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 13 October 2011 13:37


To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

David, could you try to execute the following commands under the 2 ZLB nodes?

echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 0 > /proc/sys/net/ipv4/conf/all/arp_announce

Then, try failback again.

Thanks.

On Thu, Oct 13, 2011 at 1:44 PM, David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org> wrote:

Thanks, I realise I’m being a pain but I’m really keen to get this into production!

 

From: laura Garcia [mailto:nevola <at> gmail.com]
Sent: 13 October 2011 12:38


To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Actually, you can't modify a MAC address through the zen GUI.
Let me see what can I do to support it.

About how Zen integrates CARP, maybe Emilio could give us more details.

Regards,
Laura.

On Thu, Oct 13, 2011 at 1:06 PM, David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org> wrote:

Is there anywhere in the Zen interface definition file I can specify a mac address for the :cl interface? I can’t see a way forward without it without building a new VLAN just for Zen.

 

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 13 October 2011 11:04


To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Sorry for replying to myself again. This page suggests that CARP should be using a virtual MAC address:

 

http://www.countersiege.com/doc/pfsync-carp/

 

David

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 13 October 2011 10:48
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

So by design Zen/CARP won’t failover until the ARP timeout has expired? That might be a bit of a showstopper for us, the default value for that is 4 hours on Cisco devices. We run at one hour but can’t really go lower on our production networks.

 

David

 

From: laura Garcia [mailto:nevola-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 13 October 2011 10:41
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

It's correct. For linux, every virtual or vlan interface uses the MAC of its physical network interface.
There is several ways to force to change a MAC, but the network driver has to support it.

Cheers,
Laura.

On Thu, Oct 13, 2011 at 10:32 AM, David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org> wrote:

I may have spoken too soon. Can you confirm something about the architecture please?

 

When both nodes are up eth0:cl only exists on node1, and ifconfig on node1 looks something like this:

 

eth0      Link encap:Ethernet  HWaddr 00:0c:29:06:d0:a5

          inet addr:159.180.232.241  Bcast:159.180.232.255  Mask:255.255.255.0

          inet6 addr: fe80::20c:29ff:fe06:d0a5/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:4653 errors:0 dropped:0 overruns:0 frame:0

          TX packets:82 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:359096 (350.6 KiB)  TX bytes:16870 (16.4 KiB)

          Interrupt:19 Base address:0x2000

 

eth0:cl   Link encap:Ethernet  HWaddr 00:0c:29:06:d0:a5

          inet addr:159.180.232.243  Bcast:0.0.0.0  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          Interrupt:19 Base address:0x2000

 

But when node 1 goes down, eth0:cl appears on node 2 and ifconfig on that node looks like this:

 

eth0      Link encap:Ethernet  HWaddr 00:0c:29:8e:91:fa

          inet addr:159.180.232.242  Bcast:159.180.232.255  Mask:255.255.255.0

          inet6 addr: fe80::20c:29ff:fe8e:91fa/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:17913 errors:0 dropped:0 overruns:0 frame:0

          TX packets:610 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:1585419 (1.5 MiB)  TX bytes:56683 (55.3 KiB)

          Interrupt:19 Base address:0x2000

 

eth0:cl   Link encap:Ethernet  HWaddr 00:0c:29:8e:91:fa

          inet addr:159.180.232.243  Bcast:0.0.0.0  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          Interrupt:19 Base address:0x2000

 

The MAC address of eth1:cl is a clone of the base eth0 address on whatever node is active. On our network, which has long ARP timeouts, this means that clients will not respond to the secondary host until the timeout period has expired (which can be over an hour). I would have thought that the virtual IP should have a virtual MAC address which floats between the two hosts (like VRRP and HSRP), but I don’t know enough about CARP to know if it works in this way too.

 

Can you tell me if ZEN is behaving correctly in this case or do I have another VMWare issue to solve?

 

Thanks again.

 

David

 

 

 

 

 

From: Emilio Campos [mailto:emilio.campos.martin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 12 October 2011 23:02


To: zenloadbalancer-support-5NWGOfrQmncRDUWM+popnw@public.gmane.orgforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Thanks to you David, your problems has been used for detected some bug with the cluster configuration and RSA communications. ;)

Welcomed!

2011/10/12 David Martin (IT) <dmartin <at> jpress.co.uk>

Success!

 

It is a VMWare issue. By default, our vSwitch security policy disables Promiscuous Mode, Mac Address Changes and Forged Transmits. Since CARP uses these features to establish the virtual mac and virtual IP addresses, it didn’t work. VMWare player does not have these security features and works fine.

 

By enabling these settings on the VMware port group for the VLAN that is in use, the virtual NIC can access the required functionality to support CARP (and VRRP, HSRP and similar).

 

I also found this document which describes another potential issue with CARP. It might be useful for others:

http://roggyblog.blogspot.com/2010/05/using-hsrpcarp-and-vrrp-within-vmware.html

 

Sorry to be such a pain over the last few days, I’ll keep the volume of email down now, honest!

 

On the plus side, I’m putting together some documentation on how to build for VMware and, if you want, I’d be happy to share it. I know Nick Furnell is working on an appliance that will take some of the nasty bits away (VMXnet drivers and the like) but I think there will still be some little tweaks that need to be made on the vCenter/ESX side.

 

Anyway, thanks again for the welcome and the support.

 

Regards

 

David

 

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 11 October 2011 23:06


To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

I should be able to do those tests in the morning.

 

I used ssh-copy-id to push the public keys onto opposite nodes, ssh login without password was working fine when I checked last.

 

Regards

 

David

Sent from my iPhone


On 11 Oct 2011, at 22:59, "Emilio Campos" <emilio.campos.martin <at> gmail.com> wrote:

Hi David, I just configured my environment similar to your and I can't reproduce the error, for me all is working fine, I need more information:

please eject this commands on both nodes and send me the output:

on node1:

ps -ef| grep ucarp
ifconfig -a
ps -ef | grep inotify
ip addr list

on node2:

ps -ef | grep ucarp
ifconfig -a
ps -ef| grep inotify
ip addr list


from node1 try to connect to node2 via ssh
node1# ssh root <at> ip_node2
and from node try to connect to node1 via ssh
node2# ssh root <at> ip_node1
try before the configuration cluster, this should work writing the root password, confirm this please
try ffter the configuration cluster, this should work without write the root password, confirm this please


Access to web gui,and after RSA configuration try to test the connection clicking "Test RSA connections" buttom on both nodes please.


Also I checked the logs that you send me ,and all is fine, only errors about RSA connection, that on the end of file don't appear

Please run the test and attach to this lines the output.

The name hope it's not the cause, but if it should be the cause we could modify the sourcecode to accept these naming, no problem.

Thanks!

We are waiting your feedback

2011/10/11 David Martin (IT) <dmartin <at> jpress.co.uk>

I will try in the morning. I think in my VMWare player environment I just used node1 and node2 as names. I have to be a bit more careful to use our naming conventions in the vSphere system so I used the full names.

 

If this is the cause, then is it something that can be accommodated or do I need to 'bend' my naming rules?

 

David

Sent from my iPhone


On 11 Oct 2011, at 20:50, "Emilio Campos" <emilio.campos.martin <at> gmail.com> wrote:

Hi David, I think I detected the problem, at the moment try to configure the other cluster type "node1 or node2 can be masters" and tell us!

I tell you the possible error:
On the cluster type, with failback on the file that configure the cluster /usr/local/zenloadbalancer/config/cluster.conf there is a line with this:


I am working on development environment and I suspect where is the bug!

TYPECLUSTER:GRP-ZEN-01s-GRP-ZEN-02s:UP

I defined the separator "-" to know the hostname for node master and the hostname for node backup, on this case with the hostname that you configured with "-" character the process can't  identify the two nodes.


Can you try the other cluster type and tell us if the configuration process work like a charm? :P


we hope your feedback!

Interesting, the same build in the vSphere 5 environment is not working.

 

I will do some more digging.

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 11 October 2011 17:04


To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Active on bothnodesatthesametime

 

I have just built a completely new pair of servers on VMWare Player, using a single NIC and the patch that you supplied. They seem to be working fine.

 

Next I will repeat the procedure on the vSphere 5 production environment, completely building each node from scratch and applying the RC5 update and the patch you gave me. I might take a snapshot inbetween RC5 and the patch and see if there is any difference.

 

Thanks for your continued patience.

 

David

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 11 October 2011 16:37
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodesatthesametime

 

Here are the config and logs.

 

Note that on zen-02, it was complaining about rsync ssh failures. I swapped public keys on the two nodes and that seems to have gone away (see further down zeninotify.log).

 

Nick, thanks for that. I didn’t really suspect VMWare as there is no multicast or other unusual ‘traffic’ going on. In the latest attempt I ditched the extra NIC (which was provisioned though VMWare) and am just using eth0 with the same result.

 

I’m convincing myself I’ve made a daft error or am labouring under a false assumption. If someone could confirm that my clustering method is correct, that would be useful.

 

Regards


David

 

From: Emilio Campos [mailto:emilio.campos.martin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 11 October 2011 15:26
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodesatthesame time

 

David please, can you send us a tar.gz file from both nodes, with content of /usr/local/zenloadbalancer/config and /usr/local/zenloadbalancer/logs

I would like study why not on your environtment it's not working fine!

by other hand, can you try to configure all only with one eth? disable eth1 on both nodes and try again!

Tanks!

Still not working (assuming the procedure I gave was correct):

 

Zen latency is UP on GRP-ZEN-01s 10.200.28.173 | Zen latency is UP on GRP-ZEN-02s 10.200.28.174 <image001.png>
Cluster IP 10.200.28.175 is active on GRP-ZEN-01s Cluster is active on GRP-ZEN-02s 
<image002.png>
Zen Inotify is running on GRP-ZEN-01s GRP-ZEN-02s 
<image002.png>


Global status: <image002.png>

 

<image003.jpg>

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 11 October 2011 14:51


To: zenloadbalancer-support <at> lists.sourceforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodes atthesame time

 

Hmm, not so fast. I think I deleted a vmware snapshot that contained the patched version by accident. Give me five minutes.

 

Sorry.

 

David

 

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 11 October 2011 14:46
To: zenloadbalancer-support <at> lists.sourceforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodes at thesame time

 

Emilio,

 

I have applied on both nodes.

 

Because I have done quite a bit of messing about, I’m tempted to start again. It should only take half an hour or so.

 

Before I do, can you confirm that the following procedure is ok please?

 

On Node1

1. Configure real IP address of eth1 = 10.200.28.173

 

On Node2

2. Configure real IP address of eth1 = 10.200.28.174

 

On Node1

3. Create virtual interface called eth1:cl = 10.200.28.175

4. Select eth1:cl as the virtual IP for a new Cluster and press "Save VIP"

5. Enter Node2's name and eth1 IP address in the "Remote" section and press "Save"

6. Type password in box and press "Configure RSA connection"

7. Select the first option from the cluster type menu "Node1 master and Node2 backup automatic failback"

8. Select "Configure Cluster Type"

 

The only other thing I can think of is that eth0 and eth1 are on the same subnet. Could this be causing confusion?

 

Regards

 

David

 

From: Emilio Campos [mailto:emilio.campos.martin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 11 October 2011 13:43
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodes at the same time

 

David, please confirm me.

 applied the patch on both zen servers ?

Did you deleted the cluster interface on both nodes? and repeated the process from begining?

 Remember:  You don't need connect to both node members for configure the cluster, the secondary node will be configured automaticaly.

I'm waiting your feedback

Regards!

Hmm, looks a bit different but still not right:

 

Node 1:

 

Zen latency is UP on GRP-ZEN-01s 10.200.28.173 | Zen latency is DOWN on GRP-ZEN-02s 10.200.28.174 <image002.png>
Cluster IP 10.200.28.175 is active on GRP-ZEN-01s Host key verification failed. 
<image001.png>
Zen Inotify is running on GRP-ZEN-01s Host key verification failed. 
<image001.png>
Global status: <image002.png>

 

Node 2:

 

Zen latency is UP on GRP-ZEN-02s 10.200.28.174 | Zen latency is DOWN on GRP-ZEN-01s 10.200.28.173 <image002.png>
Cluster IP 10.200.28.175 is active on GRP-ZEN-02s Host key verification failed. 
<image001.png>
Zen Inotify is running on GRP-ZEN-02s Host key verification failed
<image001.png>.
Global status: <image002.png>

 

David

 

From: Emilio Campos [mailto:emilio.campos.martin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 10 October 2011 22:28
To: zenloadbalancer-support <at> lists.sourceforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodes at the same time

 

David, I just developed the patch that fix the problem reported by you, could you help us with your test and send us your feedback?

Please write my file attached on /usr/local/zenloadbalancer/www/, rewriting the actual file
Disable the cluster configuration, delete the eth0:cl interface on both nodes and repeat the proccess from the begining.


We would like to know if with this change all is working fine

We are waiting your feedback!

Thanks and regards

2011/10/10 Emilio Campos <emilio.campos.martin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

HI David, I just detected a problem on cluster configuration, from node backup to node master


We going to solve for v1 stable


Thanks about your reports!

Hi,

 

I’m new to Zen and was hoping to get some advice. I have configured two boxes, grp-zen-01s and grp-zen-02s, and am struggling to get clustering to work.

 

I get no errors when configuring the cluster, but when I am finished I get the following status:

 

 

 

Zen latency is UP on GRP-ZEN-02s 10.200.28.174 | Zen latency is UP on GRP-ZEN-01s 10.200.28.173 <image001.png>
Cluster IP 10.200.28.175 is active on GRP-ZEN-02s Cluster is active on GRP-ZEN-01s 
<image002.png>
Zen Inotify is running on GRP-ZEN-02s GRP-ZEN-01s 
<image002.png>
Global status: <image002.png>

 

 

 

From what I can see, the VIP and Inotify should only be active on one node. I’m guessing the Passive node is having difficulty seeing the active node so it is ‘going active’ too.

 

The only ‘unusual’ bit of my setup is that both nodes are running on VMWare vSphere 5 hosts (the same host for testing, actually). I’m wondering if that could be part of the issue but I can’t see how.

 

I built one node (but no cluster or farm config) and then cloned it to get the second. I think I have caught all the IDs that I need to change (IP address, hostname, mac address, etc) but, in case I have missed something, I am going to build another node from scratch tomorrow and see if that makes a difference. Is there anything else that uniquely identifies a Zen node?

 

Thanks in advance.

 

Regards

 

David

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 

 

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneHXe+LvDLADg@public.gmane.orgrceforge.net
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster <at> jpress.co.uk

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster <at> jpress.co.uk

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support <at> lists.sourceforge.net

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmndRYHbF4JBHZw@public.gmane.orgge.net
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support <at> lists.sourceforge.net

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster <at> jpress.co.uk

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support <at> lists.sourceforge.net

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc Registered in Scotland no. SC015382 Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed. This e-mail and any files with it are solely for the use of the addressee(s). If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email at postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
laura Garcia | 14 Oct 11:49 2011
Picon

Re: Cluster Activeonbothnodesatthesametime

Great news! I think we can force the ARP updating for every farm easily while failover.
I let you know.


Regards,
Laura.

On Fri, Oct 14, 2011 at 11:18 AM, David Martin (IT) <dmartin <at> jpress.co.uk> wrote:

In my tests you can do it without downing the interface but I think it will still confuse UCARP.

 

On the ARP front, I’ve just done a preliminary test on the switches by debugging ARP traffic. I’ve cut the logs down quite a bit (each of these switches has at least 8 10Gig ports and they are pretty busy).

 

Oct 14 09:53:28.205 UTC: IP ARP: rcvd req src 10.200.28.172 0050.5602.8172, dst 10.200.28.254 Vlan28

Oct 14 09:53:28.205 UTC: IP ARP: sent rep src 10.200.28.254 0000.0c07.ac01, dst 10.200.28.172 0050.5602.8172 Vlan28

Oct 14 09:53:39.797 UTC: IP ARP: rcvd req src 10.200.28.171 0050.5602.8171, dst 10.200.28.254 Vlan28

Oct 14 09:53:39.797 UTC: IP ARP: sent rep src 10.200.28.254 0000.0c07.ac01, dst 10.200.28.171 0050.5602.8171 Vlan28

Oct 14 09:53:50.145 UTC: IP ARP: rcvd req src 10.200.28.175 0050.5602.8172, dst 10.200.28.175 Vlan28

Oct 14 09:53:50.145 UTC: IP ARP: rcvd req src 10.200.28.175 0050.5602.8172, dst 10.200.28.175 Vlan28

Oct 14 09:53:51.145 UTC: IP ARP: rcvd req src 10.200.28.175 0050.5602.8172, dst 10.200.28.175 Vlan28

Oct 14 09:53:51.145 UTC: IP ARP: rcvd req src 10.200.28.175 0050.5602.8172, dst 10.200.28.175 Vlan28

Oct 14 09:54:14.953 UTC: IP ARP: rcvd req src 10.200.28.172 0050.5602.8172, dst 10.200.28.171 Vlan28

Oct 14 09:54:14.953 UTC: IP ARP: rcvd req src 10.200.28.172 0050.5602.8172, dst 10.200.28.171 Vlan28

Oct 14 09:54:15.953 UTC: IP ARP: rcvd req src 10.200.28.172 0050.5602.8172, dst 10.200.28.171 Vlan28

Oct 14 09:54:15.953 UTC: IP ARP: rcvd req src 10.200.28.172 0050.5602.8172, dst 10.200.28.171 Vlan28

 

This is taken just as I pull the network card on node 1 (10.200.28.171). the eth0:cl address is 10.200.28.175 and the eth0:vip01 address (my test farm) is 10.200.28.173.  Interestingly, the :cl interface ARP gets updated but the 10.200.28.173 does not.

 

I have tried ping tests on the :cl interface and that does failover correctly….. it’s just the farms that don’t work

 

David

 

From: laura Garcia [mailto:nevola-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 14 October 2011 08:24
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Definitely, it's not possible to change the MAC address. To change the MAC address we've to do a down of the physical interface, change the MAC, and then, up the interface again. Meanwhile this process is done, the CARP diagnoses a problem with the network interface (that it has been down) and then, try to failover again.

CARP doesn't wait for the timeout of ARP tables, like you said, it sends gratuitous ARP packets that would be enough to update the ARP tables on the switches. Did you have analyzed the traffic between vmware servers?

Regards,
Laura.

On Thu, Oct 13, 2011 at 5:26 PM, David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org> wrote:

You are right, sorry. It looks like it is quite involved to get more than one mac on a card. There are some linux TAP/TUN drivers that can do it but it looks pretty complex.

 

From: laura Garcia [mailto:nevola-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 13 October 2011 16:07
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

You're right, but I've been doing some testing and the system doesn't allow to change a MAC address of a virtual interface. You've to change the physical parent MAC to get it works.

On Thu, Oct 13, 2011 at 4:59 PM, David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org> wrote:

Emilio,

 

I’d love to help with any testing you want.

 

In the meantime, I’ve been looking through the ucarp documentation and the zen source so I can get a better idea of how failover is working.

 

It looks from the documentation like ucarp should be sending a Gratuitous ARP when the failover occurs so that the router can update the arp table. I’m going to have a play with wireshark later today to see if I can capture and examine this packet. If that is not working with VMware for some reason, then that might be why my failover times are so long.

 

On the mac address front, I think it should be relatively easy to change the MAC address of the vip as it comes up. In the  zenlatancy-start script you could do something like the following to change the mac address of the VIP:

 

# You already do this bit to ‘up’ the interface

ip addr add 10.200.28.174\/255.255.255.0 dev eth0\:test label eth0\:test

#This tells the kernel to reset the link address

ip link set eth0\:test address 00:11:22:33:44:55

 

You would need to have a place on the interface to edit the virtual mac address (and a way of setting it to default if someone changed it automatically), and you would have to change the interface definition file but otherwise I think everything else should just work.

 

Please don’t think I’m telling you how to develop or what direction to take Zen. It’s a great product and I’m just enthusiastic.

 

Cheers

 

David

 

 

From: Emilio Campos [mailto:emilio.campos.martin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 13 October 2011 14:51
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Hi David, at this moment UCARP can't share the mac address but we could study for add this new property

We have to study the time for develope this, maybe a process that generate an automatic mac could be interesting, or one process for introduce your own personalized mac.

We could add this but not on stable version, only release candidate, if you are interested on this, you could help us with the test

At the moment we can send you a work around for test this on your environment.

And you feel free for do donations :P

Regards

2011/10/13 David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org>

Laura,

 

This has not made any difference, sorry. I have done a bit more digging and given the issue a lot of thought and I think the following (very long, sorry) describes what is going on, at least in my environment.

 

When testing this using a local zen cluster (i.e. on the same subnet) the failover happens fairly quickly, within about 30 seconds.

 

When the cluster is on a remote subnet, the failover takes anything up to an hour.

 

The reason behind this, as far as I can see, it that Windows 7 has a very short ARP timeout (randomly selected between 15-45 seconds). The ARP entry that was mapping say:

MAC Address 00:0c:29:06:d0:a5 to    IP address   159.180.232.243

In my previous example will quickly time out and be replaced by

MAC Address 00:0c:29:8e:91:fa to    IP address   159.180.232.243

as the second node takes over.

 

When the cluster is remote, you are relying on the ARP table in the last router in the chain. By default, Cisco use and recommend an ARP timeout of four hours. This can be changed, but at the expense of increased ARP traffic, CPU load and in some cases latency. To better suit our VMWare environment, we have reduced this timeout to just one hour which we found to be a good compromise.

 

To get around this very long timeout, protocols like HSRP, GLBP, VRRP and CARP create a virtual mac address that both nodes share. When a node dies the network interface goes down and the switch immediately flushes its CAM table, meaning that the mac address almost instantly is available on the second node.

 

I suspect that by introducing the concept of a virtual mac address to Zen, this fast switchover can be achieved.

 

On the other hand, I could be doing something very wrong and, if so, please point it out! I’d be especially grateful if any other users could share their experience of Zen on a non-local subnet and what ARP timeouts are in use on the Zen VLAN.

 

Thanks for your patience once again, I definitely feel a donation will be in order soon!

 

David

 

 

 

From: laura Garcia [mailto:nevola <at> gmail.com]
Sent: 13 October 2011 13:37


To: zenloadbalancer-support-5NWGOfrQmnfLDRD5uJR0wg@public.gmane.orgeforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

David, could you try to execute the following commands under the 2 ZLB nodes?

echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 0 > /proc/sys/net/ipv4/conf/all/arp_announce

Then, try failback again.

Thanks.

On Thu, Oct 13, 2011 at 1:44 PM, David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org> wrote:

Thanks, I realise I’m being a pain but I’m really keen to get this into production!

 

From: laura Garcia [mailto:nevola <at> gmail.com]
Sent: 13 October 2011 12:38


To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Actually, you can't modify a MAC address through the zen GUI.
Let me see what can I do to support it.

About how Zen integrates CARP, maybe Emilio could give us more details.

Regards,
Laura.

On Thu, Oct 13, 2011 at 1:06 PM, David Martin (IT) <dmartin <at> jpress.co.uk> wrote:

Is there anywhere in the Zen interface definition file I can specify a mac address for the :cl interface? I can’t see a way forward without it without building a new VLAN just for Zen.

 

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 13 October 2011 11:04


To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Sorry for replying to myself again. This page suggests that CARP should be using a virtual MAC address:

 

http://www.countersiege.com/doc/pfsync-carp/

 

David

 

From: David Martin (IT) [mailto:dmartin <at> jpress.co.uk]
Sent: 13 October 2011 10:48
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

So by design Zen/CARP won’t failover until the ARP timeout has expired? That might be a bit of a showstopper for us, the default value for that is 4 hours on Cisco devices. We run at one hour but can’t really go lower on our production networks.

 

David

 

From: laura Garcia [mailto:nevola-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 13 October 2011 10:41
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

It's correct. For linux, every virtual or vlan interface uses the MAC of its physical network interface.
There is several ways to force to change a MAC, but the network driver has to support it.

Cheers,
Laura.

On Thu, Oct 13, 2011 at 10:32 AM, David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org> wrote:

I may have spoken too soon. Can you confirm something about the architecture please?

 

When both nodes are up eth0:cl only exists on node1, and ifconfig on node1 looks something like this:

 

eth0      Link encap:Ethernet  HWaddr 00:0c:29:06:d0:a5

          inet addr:159.180.232.241  Bcast:159.180.232.255  Mask:255.255.255.0

          inet6 addr: fe80::20c:29ff:fe06:d0a5/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:4653 errors:0 dropped:0 overruns:0 frame:0

          TX packets:82 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:359096 (350.6 KiB)  TX bytes:16870 (16.4 KiB)

          Interrupt:19 Base address:0x2000

 

eth0:cl   Link encap:Ethernet  HWaddr 00:0c:29:06:d0:a5

          inet addr:159.180.232.243  Bcast:0.0.0.0  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          Interrupt:19 Base address:0x2000

 

But when node 1 goes down, eth0:cl appears on node 2 and ifconfig on that node looks like this:

 

eth0      Link encap:Ethernet  HWaddr 00:0c:29:8e:91:fa

          inet addr:159.180.232.242  Bcast:159.180.232.255  Mask:255.255.255.0

          inet6 addr: fe80::20c:29ff:fe8e:91fa/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:17913 errors:0 dropped:0 overruns:0 frame:0

          TX packets:610 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:1585419 (1.5 MiB)  TX bytes:56683 (55.3 KiB)

          Interrupt:19 Base address:0x2000

 

eth0:cl   Link encap:Ethernet  HWaddr 00:0c:29:8e:91:fa

          inet addr:159.180.232.243  Bcast:0.0.0.0  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          Interrupt:19 Base address:0x2000

 

The MAC address of eth1:cl is a clone of the base eth0 address on whatever node is active. On our network, which has long ARP timeouts, this means that clients will not respond to the secondary host until the timeout period has expired (which can be over an hour). I would have thought that the virtual IP should have a virtual MAC address which floats between the two hosts (like VRRP and HSRP), but I don’t know enough about CARP to know if it works in this way too.

 

Can you tell me if ZEN is behaving correctly in this case or do I have another VMWare issue to solve?

 

Thanks again.

 

David

 

 

 

 

 

From: Emilio Campos [mailto:emilio.campos.martin <at> gmail.com]
Sent: 12 October 2011 23:02


To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Thanks to you David, your problems has been used for detected some bug with the cluster configuration and RSA communications. ;)

Welcomed!

2011/10/12 David Martin (IT) <dmartin-ANfHjr1BzNdHPrDE71CqTQ@public.gmane.orguk>

Success!

 

It is a VMWare issue. By default, our vSwitch security policy disables Promiscuous Mode, Mac Address Changes and Forged Transmits. Since CARP uses these features to establish the virtual mac and virtual IP addresses, it didn’t work. VMWare player does not have these security features and works fine.

 

By enabling these settings on the VMware port group for the VLAN that is in use, the virtual NIC can access the required functionality to support CARP (and VRRP, HSRP and similar).

 

I also found this document which describes another potential issue with CARP. It might be useful for others:

http://roggyblog.blogspot.com/2010/05/using-hsrpcarp-and-vrrp-within-vmware.html

 

Sorry to be such a pain over the last few days, I’ll keep the volume of email down now, honest!

 

On the plus side, I’m putting together some documentation on how to build for VMware and, if you want, I’d be happy to share it. I know Nick Furnell is working on an appliance that will take some of the nasty bits away (VMXnet drivers and the like) but I think there will still be some little tweaks that need to be made on the vCenter/ESX side.

 

Anyway, thanks again for the welcome and the support.

 

Regards

 

David

 

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 11 October 2011 23:06


To: zenloadbalancer-support-5NWGOfrQmnfLDRD5uJR0wg@public.gmane.orgeforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

I should be able to do those tests in the morning.

 

I used ssh-copy-id to push the public keys onto opposite nodes, ssh login without password was working fine when I checked last.

 

Regards

 

David

Sent from my iPhone


On 11 Oct 2011, at 22:59, "Emilio Campos" <emilio.campos.martin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

Hi David, I just configured my environment similar to your and I can't reproduce the error, for me all is working fine, I need more information:

please eject this commands on both nodes and send me the output:

on node1:

ps -ef| grep ucarp
ifconfig -a
ps -ef | grep inotify
ip addr list

on node2:

ps -ef | grep ucarp
ifconfig -a
ps -ef| grep inotify
ip addr list


from node1 try to connect to node2 via ssh
node1# ssh root <at> ip_node2
and from node try to connect to node1 via ssh
node2# ssh root <at> ip_node1
try before the configuration cluster, this should work writing the root password, confirm this please
try ffter the configuration cluster, this should work without write the root password, confirm this please


Access to web gui,and after RSA configuration try to test the connection clicking "Test RSA connections" buttom on both nodes please.


Also I checked the logs that you send me ,and all is fine, only errors about RSA connection, that on the end of file don't appear

Please run the test and attach to this lines the output.

The name hope it's not the cause, but if it should be the cause we could modify the sourcecode to accept these naming, no problem.

Thanks!

We are waiting your feedback

2011/10/11 David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org>

I will try in the morning. I think in my VMWare player environment I just used node1 and node2 as names. I have to be a bit more careful to use our naming conventions in the vSphere system so I used the full names.

 

If this is the cause, then is it something that can be accommodated or do I need to 'bend' my naming rules?

 

David

Sent from my iPhone


On 11 Oct 2011, at 20:50, "Emilio Campos" <emilio.campos.martin <at> gmail.com> wrote:

Hi David, I think I detected the problem, at the moment try to configure the other cluster type "node1 or node2 can be masters" and tell us!

I tell you the possible error:
On the cluster type, with failback on the file that configure the cluster /usr/local/zenloadbalancer/config/cluster.conf there is a line with this:


I am working on development environment and I suspect where is the bug!

TYPECLUSTER:GRP-ZEN-01s-GRP-ZEN-02s:UP

I defined the separator "-" to know the hostname for node master and the hostname for node backup, on this case with the hostname that you configured with "-" character the process can't  identify the two nodes.


Can you try the other cluster type and tell us if the configuration process work like a charm? :P


we hope your feedback!

2011/10/11 David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org>

Interesting, the same build in the vSphere 5 environment is not working.

 

I will do some more digging.

 

From: David Martin (IT) [mailto:dmartin <at> jpress.co.uk]
Sent: 11 October 2011 17:04


To: zenloadbalancer-support-5NWGOfrQmnfLDRD5uJR0wg@public.gmane.orgeforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Active on bothnodesatthesametime

 

I have just built a completely new pair of servers on VMWare Player, using a single NIC and the patch that you supplied. They seem to be working fine.

 

Next I will repeat the procedure on the vSphere 5 production environment, completely building each node from scratch and applying the RC5 update and the patch you gave me. I might take a snapshot inbetween RC5 and the patch and see if there is any difference.

 

Thanks for your continued patience.

 

David

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 11 October 2011 16:37
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodesatthesametime

 

Here are the config and logs.

 

Note that on zen-02, it was complaining about rsync ssh failures. I swapped public keys on the two nodes and that seems to have gone away (see further down zeninotify.log).

 

Nick, thanks for that. I didn’t really suspect VMWare as there is no multicast or other unusual ‘traffic’ going on. In the latest attempt I ditched the extra NIC (which was provisioned though VMWare) and am just using eth0 with the same result.

 

I’m convincing myself I’ve made a daft error or am labouring under a false assumption. If someone could confirm that my clustering method is correct, that would be useful.

 

Regards


David

 

From: Emilio Campos [mailto:emilio.campos.martin <at> gmail.com]
Sent: 11 October 2011 15:26
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodesatthesame time

 

David please, can you send us a tar.gz file from both nodes, with content of /usr/local/zenloadbalancer/config and /usr/local/zenloadbalancer/logs

I would like study why not on your environtment it's not working fine!

by other hand, can you try to configure all only with one eth? disable eth1 on both nodes and try again!

Tanks!

2011/10/11 David Martin (IT) <dmartin <at> jpress.co.uk>

Still not working (assuming the procedure I gave was correct):

 

Zen latency is UP on GRP-ZEN-01s 10.200.28.173 | Zen latency is UP on GRP-ZEN-02s 10.200.28.174 <image001.png>
Cluster IP 10.200.28.175 is active on GRP-ZEN-01s Cluster is active on GRP-ZEN-02s 
<image002.png>
Zen Inotify is running on GRP-ZEN-01s GRP-ZEN-02s 
<image002.png>


Global status: <image002.png>

 

<image003.jpg>

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 11 October 2011 14:51


To: zenloadbalancer-support-5NWGOfrQmnfLDRD5uJR0wg@public.gmane.orgeforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodes atthesame time

 

Hmm, not so fast. I think I deleted a vmware snapshot that contained the patched version by accident. Give me five minutes.

 

Sorry.

 

David

 

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 11 October 2011 14:46
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodes at thesame time

 

Emilio,

 

I have applied on both nodes.

 

Because I have done quite a bit of messing about, I’m tempted to start again. It should only take half an hour or so.

 

Before I do, can you confirm that the following procedure is ok please?

 

On Node1

1. Configure real IP address of eth1 = 10.200.28.173

 

On Node2

2. Configure real IP address of eth1 = 10.200.28.174

 

On Node1

3. Create virtual interface called eth1:cl = 10.200.28.175

4. Select eth1:cl as the virtual IP for a new Cluster and press "Save VIP"

5. Enter Node2's name and eth1 IP address in the "Remote" section and press "Save"

6. Type password in box and press "Configure RSA connection"

7. Select the first option from the cluster type menu "Node1 master and Node2 backup automatic failback"

8. Select "Configure Cluster Type"

 

The only other thing I can think of is that eth0 and eth1 are on the same subnet. Could this be causing confusion?

 

Regards

 

David

 

From: Emilio Campos [mailto:emilio.campos.martin <at> gmail.com]
Sent: 11 October 2011 13:43
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodes at the same time

 

David, please confirm me.

 applied the patch on both zen servers ?

Did you deleted the cluster interface on both nodes? and repeated the process from begining?

 Remember:  You don't need connect to both node members for configure the cluster, the secondary node will be configured automaticaly.

I'm waiting your feedback

Regards!

Hmm, looks a bit different but still not right:

 

Node 1:

 

Zen latency is UP on GRP-ZEN-01s 10.200.28.173 | Zen latency is DOWN on GRP-ZEN-02s 10.200.28.174 <image002.png>
Cluster IP 10.200.28.175 is active on GRP-ZEN-01s Host key verification failed. 
<image001.png>
Zen Inotify is running on GRP-ZEN-01s Host key verification failed. 
<image001.png>
Global status: <image002.png>

 

Node 2:

 

Zen latency is UP on GRP-ZEN-02s 10.200.28.174 | Zen latency is DOWN on GRP-ZEN-01s 10.200.28.173 <image002.png>
Cluster IP 10.200.28.175 is active on GRP-ZEN-02s Host key verification failed. 
<image001.png>
Zen Inotify is running on GRP-ZEN-02s Host key verification failed
<image001.png>.
Global status: <image002.png>

 

David

 

From: Emilio Campos [mailto:emilio.campos.martin <at> gmail.com]
Sent: 10 October 2011 22:28
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodes at the same time

 

David, I just developed the patch that fix the problem reported by you, could you help us with your test and send us your feedback?

Please write my file attached on /usr/local/zenloadbalancer/www/, rewriting the actual file
Disable the cluster configuration, delete the eth0:cl interface on both nodes and repeat the proccess from the begining.


We would like to know if with this change all is working fine

We are waiting your feedback!

Thanks and regards

2011/10/10 Emilio Campos <emilio.campos.martin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

HI David, I just detected a problem on cluster configuration, from node backup to node master


We going to solve for v1 stable


Thanks about your reports!

Hi,

 

I’m new to Zen and was hoping to get some advice. I have configured two boxes, grp-zen-01s and grp-zen-02s, and am struggling to get clustering to work.

 

I get no errors when configuring the cluster, but when I am finished I get the following status:

 

 

 

Zen latency is UP on GRP-ZEN-02s 10.200.28.174 | Zen latency is UP on GRP-ZEN-01s 10.200.28.173 <image001.png>
Cluster IP 10.200.28.175 is active on GRP-ZEN-02s Cluster is active on GRP-ZEN-01s 
<image002.png>
Zen Inotify is running on GRP-ZEN-02s GRP-ZEN-01s 
<image002.png>
Global status: <image002.png>

 

 

 

From what I can see, the VIP and Inotify should only be active on one node. I’m guessing the Passive node is having difficulty seeing the active node so it is ‘going active’ too.

 

The only ‘unusual’ bit of my setup is that both nodes are running on VMWare vSphere 5 hosts (the same host for testing, actually). I’m wondering if that could be part of the issue but I can’t see how.

 

I built one node (but no cluster or farm config) and then cloned it to get the second. I think I have caught all the IDs that I need to change (IP address, hostname, mac address, etc) but, in case I have missed something, I am going to build another node from scratch tomorrow and see if that makes a difference. Is there anything else that uniquely identifies a Zen node?

 

Thanks in advance.

 

Regards

 

David

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS  Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed. This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error.Please delete it or return it to the sender or notify us by email at postmaster <at> jpress.co.uk 

 

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmnd4wTydcyPnfg@public.gmane.orgceforge.net




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmncRDUWM+popnw@public.gmane.orgforge.net

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org  Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org 
Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS  Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s). If you are not the intended recipient, you have received this e-mail in error.Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org  


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org  Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org 
Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS  Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s). If you are not the intended recipient, you have received this e-mail in error.Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org  


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmncRDUWM+popnw@public.gmane.orgforge.net

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct

Johnston Press plc  Registered in Scotland no. SC015382 Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed. This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error.Please delete it or return it to the sender or notify us by email at postmaster <at> jpress.co.uk 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct

Johnston Press plc  Registered in Scotland no. SC015382 Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed. This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error.Please delete it or return it to the sender or notify us by email at postmaster <at> jpress.co.uk 
Johnston Press plc  Registered in Scotland no. SC015382 Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed. This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error.Please delete it or return it to the sender or notify us by email at postmaster <at> jpress.co.uk 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org  Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org 
Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc Registered in Scotland no. SC015382 Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed. This e-mail and any files with it are solely for the use of the addressee(s). If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email at postmaster <at> jpress.co.uk

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
David Martin (IT | 14 Oct 12:40 2011
Picon

Re: Cluster Activeonbothnodesatthesametime

Wow, great!

Sent from my iPhone

On 14 Oct 2011, at 10:49, "laura Garcia" <nevola <at> gmail.com> wrote:

Great news! I think we can force the ARP updating for every farm easily while failover.
I let you know.


Regards,
Laura.

On Fri, Oct 14, 2011 at 11:18 AM, David Martin (IT) <dmartin <at> jpress.co.uk> wrote:

In my tests you can do it without downing the interface but I think it will still confuse UCARP.

 

On the ARP front, I’ve just done a preliminary test on the switches by debugging ARP traffic. I’ve cut the logs down quite a bit (each of these switches has at least 8 10Gig ports and they are pretty busy).

 

Oct 14 09:53:28.205 UTC: IP ARP: rcvd req src 10.200.28.172 0050.5602.8172, dst 10.200.28.254 Vlan28

Oct 14 09:53:28.205 UTC: IP ARP: sent rep src 10.200.28.254 0000.0c07.ac01, dst 10.200.28.172 0050.5602.8172 Vlan28

Oct 14 09:53:39.797 UTC: IP ARP: rcvd req src 10.200.28.171 0050.5602.8171, dst 10.200.28.254 Vlan28

Oct 14 09:53:39.797 UTC: IP ARP: sent rep src 10.200.28.254 0000.0c07.ac01, dst 10.200.28.171 0050.5602.8171 Vlan28

Oct 14 09:53:50.145 UTC: IP ARP: rcvd req src 10.200.28.175 0050.5602.8172, dst 10.200.28.175 Vlan28

Oct 14 09:53:50.145 UTC: IP ARP: rcvd req src 10.200.28.175 0050.5602.8172, dst 10.200.28.175 Vlan28

Oct 14 09:53:51.145 UTC: IP ARP: rcvd req src 10.200.28.175 0050.5602.8172, dst 10.200.28.175 Vlan28

Oct 14 09:53:51.145 UTC: IP ARP: rcvd req src 10.200.28.175 0050.5602.8172, dst 10.200.28.175 Vlan28

Oct 14 09:54:14.953 UTC: IP ARP: rcvd req src 10.200.28.172 0050.5602.8172, dst 10.200.28.171 Vlan28

Oct 14 09:54:14.953 UTC: IP ARP: rcvd req src 10.200.28.172 0050.5602.8172, dst 10.200.28.171 Vlan28

Oct 14 09:54:15.953 UTC: IP ARP: rcvd req src 10.200.28.172 0050.5602.8172, dst 10.200.28.171 Vlan28

Oct 14 09:54:15.953 UTC: IP ARP: rcvd req src 10.200.28.172 0050.5602.8172, dst 10.200.28.171 Vlan28

 

This is taken just as I pull the network card on node 1 (10.200.28.171). the eth0:cl address is 10.200.28.175 and the eth0:vip01 address (my test farm) is 10.200.28.173.  Interestingly, the :cl interface ARP gets updated but the 10.200.28.173 does not.

 

I have tried ping tests on the :cl interface and that does failover correctly….. it’s just the farms that don’t work

 

David

 

From: laura Garcia [mailto:nevola <at> gmail.com]
Sent: 14 October 2011 08:24
To: zenloadbalancer-support <at> lists.sourceforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Definitely, it's not possible to change the MAC address. To change the MAC address we've to do a down of the physical interface, change the MAC, and then, up the interface again. Meanwhile this process is done, the CARP diagnoses a problem with the network interface (that it has been down) and then, try to failover again.

CARP doesn't wait for the timeout of ARP tables, like you said, it sends gratuitous ARP packets that would be enough to update the ARP tables on the switches. Did you have analyzed the traffic between vmware servers?

Regards,
Laura.

On Thu, Oct 13, 2011 at 5:26 PM, David Martin (IT) <dmartin <at> jpress.co.uk> wrote:

You are right, sorry. It looks like it is quite involved to get more than one mac on a card. There are some linux TAP/TUN drivers that can do it but it looks pretty complex.

 

From: laura Garcia [mailto:nevola <at> gmail.com]
Sent: 13 October 2011 16:07
To: zenloadbalancer-support <at> lists.sourceforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

You're right, but I've been doing some testing and the system doesn't allow to change a MAC address of a virtual interface. You've to change the physical parent MAC to get it works.

On Thu, Oct 13, 2011 at 4:59 PM, David Martin (IT) <dmartin <at> jpress.co.uk> wrote:

Emilio,

 

I’d love to help with any testing you want.

 

In the meantime, I’ve been looking through the ucarp documentation and the zen source so I can get a better idea of how failover is working.

 

It looks from the documentation like ucarp should be sending a Gratuitous ARP when the failover occurs so that the router can update the arp table. I’m going to have a play with wireshark later today to see if I can capture and examine this packet. If that is not working with VMware for some reason, then that might be why my failover times are so long.

 

On the mac address front, I think it should be relatively easy to change the MAC address of the vip as it comes up. In the  zenlatancy-start script you could do something like the following to change the mac address of the VIP:

 

# You already do this bit to ‘up’ the interface

ip addr add 10.200.28.174\/255.255.255.0 dev eth0\:test label eth0\:test

#This tells the kernel to reset the link address

ip link set eth0\:test address 00:11:22:33:44:55

 

You would need to have a place on the interface to edit the virtual mac address (and a way of setting it to default if someone changed it automatically), and you would have to change the interface definition file but otherwise I think everything else should just work.

 

Please don’t think I’m telling you how to develop or what direction to take Zen. It’s a great product and I’m just enthusiastic.

 

Cheers

 

David

 

 

From: Emilio Campos [mailto:emilio.campos.martin <at> gmail.com]
Sent: 13 October 2011 14:51
To: zenloadbalancer-support <at> lists.sourceforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Hi David, at this moment UCARP can't share the mac address but we could study for add this new property

We have to study the time for develope this, maybe a process that generate an automatic mac could be interesting, or one process for introduce your own personalized mac.

We could add this but not on stable version, only release candidate, if you are interested on this, you could help us with the test

At the moment we can send you a work around for test this on your environment.

And you feel free for do donations :P

Regards

2011/10/13 David Martin (IT) <dmartin <at> jpress.co.uk>

Laura,

 

This has not made any difference, sorry. I have done a bit more digging and given the issue a lot of thought and I think the following (very long, sorry) describes what is going on, at least in my environment.

 

When testing this using a local zen cluster (i.e. on the same subnet) the failover happens fairly quickly, within about 30 seconds.

 

When the cluster is on a remote subnet, the failover takes anything up to an hour.

 

The reason behind this, as far as I can see, it that Windows 7 has a very short ARP timeout (randomly selected between 15-45 seconds). The ARP entry that was mapping say:

MAC Address 00:0c:29:06:d0:a5 to    IP address   159.180.232.243

In my previous example will quickly time out and be replaced by

MAC Address 00:0c:29:8e:91:fa to    IP address   159.180.232.243

as the second node takes over.

 

When the cluster is remote, you are relying on the ARP table in the last router in the chain. By default, Cisco use and recommend an ARP timeout of four hours. This can be changed, but at the expense of increased ARP traffic, CPU load and in some cases latency. To better suit our VMWare environment, we have reduced this timeout to just one hour which we found to be a good compromise.

 

To get around this very long timeout, protocols like HSRP, GLBP, VRRP and CARP create a virtual mac address that both nodes share. When a node dies the network interface goes down and the switch immediately flushes its CAM table, meaning that the mac address almost instantly is available on the second node.

 

I suspect that by introducing the concept of a virtual mac address to Zen, this fast switchover can be achieved.

 

On the other hand, I could be doing something very wrong and, if so, please point it out! I’d be especially grateful if any other users could share their experience of Zen on a non-local subnet and what ARP timeouts are in use on the Zen VLAN.

 

Thanks for your patience once again, I definitely feel a donation will be in order soon!

 

David

 

 

 

From: laura Garcia [mailto:nevola <at> gmail.com]
Sent: 13 October 2011 13:37


To: zenloadbalancer-support <at> lists.sourceforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

David, could you try to execute the following commands under the 2 ZLB nodes?

echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 0 > /proc/sys/net/ipv4/conf/all/arp_announce

Then, try failback again.

Thanks.

On Thu, Oct 13, 2011 at 1:44 PM, David Martin (IT) <dmartin <at> jpress.co.uk> wrote:

Thanks, I realise I’m being a pain but I’m really keen to get this into production!

 

From: laura Garcia [mailto:nevola <at> gmail.com]
Sent: 13 October 2011 12:38


To: zenloadbalancer-support <at> lists.sourceforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Actually, you can't modify a MAC address through the zen GUI.
Let me see what can I do to support it.

About how Zen integrates CARP, maybe Emilio could give us more details.

Regards,
Laura.

On Thu, Oct 13, 2011 at 1:06 PM, David Martin (IT) <dmartin <at> jpress.co.uk> wrote:

Is there anywhere in the Zen interface definition file I can specify a mac address for the :cl interface? I can’t see a way forward without it without building a new VLAN just for Zen.

 

 

From: David Martin (IT) [mailto:dmartin <at> jpress.co.uk]
Sent: 13 October 2011 11:04


To: zenloadbalancer-support <at> lists.sourceforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Sorry for replying to myself again. This page suggests that CARP should be using a virtual MAC address:

 

http://www.countersiege.com/doc/pfsync-carp/

 

David

 

From: David Martin (IT) [mailto:dmartin <at> jpress.co.uk]
Sent: 13 October 2011 10:48
To: zenloadbalancer-support <at> lists.sourceforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

So by design Zen/CARP won’t failover until the ARP timeout has expired? That might be a bit of a showstopper for us, the default value for that is 4 hours on Cisco devices. We run at one hour but can’t really go lower on our production networks.

 

David

 

From: laura Garcia [mailto:nevola <at> gmail.com]
Sent: 13 October 2011 10:41
To: zenloadbalancer-support <at> lists.sourceforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

It's correct. For linux, every virtual or vlan interface uses the MAC of its physical network interface.
There is several ways to force to change a MAC, but the network driver has to support it.

Cheers,
Laura.

On Thu, Oct 13, 2011 at 10:32 AM, David Martin (IT) <dmartin <at> jpress.co.uk> wrote:

I may have spoken too soon. Can you confirm something about the architecture please?

 

When both nodes are up eth0:cl only exists on node1, and ifconfig on node1 looks something like this:

 

eth0      Link encap:Ethernet  HWaddr 00:0c:29:06:d0:a5

          inet addr:159.180.232.241  Bcast:159.180.232.255  Mask:255.255.255.0

          inet6 addr: fe80::20c:29ff:fe06:d0a5/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:4653 errors:0 dropped:0 overruns:0 frame:0

          TX packets:82 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:359096 (350.6 KiB)  TX bytes:16870 (16.4 KiB)

          Interrupt:19 Base address:0x2000

 

eth0:cl   Link encap:Ethernet  HWaddr 00:0c:29:06:d0:a5

          inet addr:159.180.232.243  Bcast:0.0.0.0  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          Interrupt:19 Base address:0x2000

 

But when node 1 goes down, eth0:cl appears on node 2 and ifconfig on that node looks like this:

 

eth0      Link encap:Ethernet  HWaddr 00:0c:29:8e:91:fa

          inet addr:159.180.232.242  Bcast:159.180.232.255  Mask:255.255.255.0

          inet6 addr: fe80::20c:29ff:fe8e:91fa/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:17913 errors:0 dropped:0 overruns:0 frame:0

          TX packets:610 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:1585419 (1.5 MiB)  TX bytes:56683 (55.3 KiB)

          Interrupt:19 Base address:0x2000

 

eth0:cl   Link encap:Ethernet  HWaddr 00:0c:29:8e:91:fa

          inet addr:159.180.232.243  Bcast:0.0.0.0  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          Interrupt:19 Base address:0x2000

 

The MAC address of eth1:cl is a clone of the base eth0 address on whatever node is active. On our network, which has long ARP timeouts, this means that clients will not respond to the secondary host until the timeout period has expired (which can be over an hour). I would have thought that the virtual IP should have a virtual MAC address which floats between the two hosts (like VRRP and HSRP), but I don’t know enough about CARP to know if it works in this way too.

 

Can you tell me if ZEN is behaving correctly in this case or do I have another VMWare issue to solve?

 

Thanks again.

 

David

 

 

 

 

 

From: Emilio Campos [mailto:emilio.campos.martin <at> gmail.com]
Sent: 12 October 2011 23:02


To: zenloadbalancer-support <at> lists.sourceforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Thanks to you David, your problems has been used for detected some bug with the cluster configuration and RSA communications. ;)

Welcomed!

2011/10/12 David Martin (IT) <dmartin <at> jpress.co.uk>

Success!

 

It is a VMWare issue. By default, our vSwitch security policy disables Promiscuous Mode, Mac Address Changes and Forged Transmits. Since CARP uses these features to establish the virtual mac and virtual IP addresses, it didn’t work. VMWare player does not have these security features and works fine.

 

By enabling these settings on the VMware port group for the VLAN that is in use, the virtual NIC can access the required functionality to support CARP (and VRRP, HSRP and similar).

 

I also found this document which describes another potential issue with CARP. It might be useful for others:

http://roggyblog.blogspot.com/2010/05/using-hsrpcarp-and-vrrp-within-vmware.html

 

Sorry to be such a pain over the last few days, I’ll keep the volume of email down now, honest!

 

On the plus side, I’m putting together some documentation on how to build for VMware and, if you want, I’d be happy to share it. I know Nick Furnell is working on an appliance that will take some of the nasty bits away (VMXnet drivers and the like) but I think there will still be some little tweaks that need to be made on the vCenter/ESX side.

 

Anyway, thanks again for the welcome and the support.

 

Regards

 

David

 

 

From: David Martin (IT) [mailto:dmartin <at> jpress.co.uk]
Sent: 11 October 2011 23:06


To: zenloadbalancer-support <at> lists.sourceforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

I should be able to do those tests in the morning.

 

I used ssh-copy-id to push the public keys onto opposite nodes, ssh login without password was working fine when I checked last.

 

Regards

 

David

Sent from my iPhone


On 11 Oct 2011, at 22:59, "Emilio Campos" <emilio.campos.martin <at> gmail.com> wrote:

Hi David, I just configured my environment similar to your and I can't reproduce the error, for me all is working fine, I need more information:

please eject this commands on both nodes and send me the output:

on node1:

ps -ef| grep ucarp
ifconfig -a
ps -ef | grep inotify
ip addr list

on node2:

ps -ef | grep ucarp
ifconfig -a
ps -ef| grep inotify
ip addr list


from node1 try to connect to node2 via ssh
node1# ssh root <at> ip_node2
and from node try to connect to node1 via ssh
node2# ssh root <at> ip_node1
try before the configuration cluster, this should work writing the root password, confirm this please
try ffter the configuration cluster, this should work without write the root password, confirm this please


Access to web gui,and after RSA configuration try to test the connection clicking "Test RSA connections" buttom on both nodes please.


Also I checked the logs that you send me ,and all is fine, only errors about RSA connection, that on the end of file don't appear

Please run the test and attach to this lines the output.

The name hope it's not the cause, but if it should be the cause we could modify the sourcecode to accept these naming, no problem.

Thanks!

We are waiting your feedback

2011/10/11 David Martin (IT) <dmartin <at> jpress.co.uk>

I will try in the morning. I think in my VMWare player environment I just used node1 and node2 as names. I have to be a bit more careful to use our naming conventions in the vSphere system so I used the full names.

 

If this is the cause, then is it something that can be accommodated or do I need to 'bend' my naming rules?

 

David

Sent from my iPhone


On 11 Oct 2011, at 20:50, "Emilio Campos" <emilio.campos.martin <at> gmail.com> wrote:

Hi David, I think I detected the problem, at the moment try to configure the other cluster type "node1 or node2 can be masters" and tell us!

I tell you the possible error:
On the cluster type, with failback on the file that configure the cluster /usr/local/zenloadbalancer/config/cluster.conf there is a line with this:


I am working on development environment and I suspect where is the bug!

TYPECLUSTER:GRP-ZEN-01s-GRP-ZEN-02s:UP

I defined the separator "-" to know the hostname for node master and the hostname for node backup, on this case with the hostname that you configured with "-" character the process can't  identify the two nodes.


Can you try the other cluster type and tell us if the configuration process work like a charm? :P


we hope your feedback!

2011/10/11 David Martin (IT) <dmartin <at> jpress.co.uk>

Interesting, the same build in the vSphere 5 environment is not working.

 

I will do some more digging.

 

From: David Martin (IT) [mailto:dmartin <at> jpress.co.uk]
Sent: 11 October 2011 17:04


To: zenloadbalancer-support <at> lists.sourceforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Active on bothnodesatthesametime

 

I have just built a completely new pair of servers on VMWare Player, using a single NIC and the patch that you supplied. They seem to be working fine.

 

Next I will repeat the procedure on the vSphere 5 production environment, completely building each node from scratch and applying the RC5 update and the patch you gave me. I might take a snapshot inbetween RC5 and the patch and see if there is any difference.

 

Thanks for your continued patience.

 

David

 

From: David Martin (IT) [mailto:dmartin <at> jpress.co.uk]
Sent: 11 October 2011 16:37
To: zenloadbalancer-support <at> lists.sourceforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodesatthesametime

 

Here are the config and logs.

 

Note that on zen-02, it was complaining about rsync ssh failures. I swapped public keys on the two nodes and that seems to have gone away (see further down zeninotify.log).

 

Nick, thanks for that. I didn’t really suspect VMWare as there is no multicast or other unusual ‘traffic’ going on. In the latest attempt I ditched the extra NIC (which was provisioned though VMWare) and am just using eth0 with the same result.

 

I’m convincing myself I’ve made a daft error or am labouring under a false assumption. If someone could confirm that my clustering method is correct, that would be useful.

 

Regards


David

 

From: Emilio Campos [mailto:emilio.campos.martin <at> gmail.com]
Sent: 11 October 2011 15:26
To: zenloadbalancer-support <at> lists.sourceforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodesatthesame time

 

David please, can you send us a tar.gz file from both nodes, with content of /usr/local/zenloadbalancer/config and /usr/local/zenloadbalancer/logs

I would like study why not on your environtment it's not working fine!

by other hand, can you try to configure all only with one eth? disable eth1 on both nodes and try again!

Tanks!

2011/10/11 David Martin (IT) <dmartin <at> jpress.co.uk>

Still not working (assuming the procedure I gave was correct):

 

Zen latency is UP on GRP-ZEN-01s 10.200.28.173 | Zen latency is UP on GRP-ZEN-02s 10.200.28.174 <image001.png>
Cluster IP 10.200.28.175 is active on GRP-ZEN-01s Cluster is active on GRP-ZEN-02s 
<image002.png>
Zen Inotify is running on GRP-ZEN-01s GRP-ZEN-02s 
<image002.png>


Global status: <image002.png>

 

<image003.jpg>

 

From: David Martin (IT) [mailto:dmartin <at> jpress.co.uk]
Sent: 11 October 2011 14:51


To: zenloadbalancer-support <at> lists.sourceforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodes atthesame time

 

Hmm, not so fast. I think I deleted a vmware snapshot that contained the patched version by accident. Give me five minutes.

 

Sorry.

 

David

 

 

From: David Martin (IT) [mailto:dmartin <at> jpress.co.uk]
Sent: 11 October 2011 14:46
To: zenloadbalancer-support <at> lists.sourceforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodes at thesame time

 

Emilio,

 

I have applied on both nodes.

 

Because I have done quite a bit of messing about, I’m tempted to start again. It should only take half an hour or so.

 

Before I do, can you confirm that the following procedure is ok please?

 

On Node1

1. Configure real IP address of eth1 = 10.200.28.173

 

On Node2

2. Configure real IP address of eth1 = 10.200.28.174

 

On Node1

3. Create virtual interface called eth1:cl = 10.200.28.175

4. Select eth1:cl as the virtual IP for a new Cluster and press "Save VIP"

5. Enter Node2's name and eth1 IP address in the "Remote" section and press "Save"

6. Type password in box and press "Configure RSA connection"

7. Select the first option from the cluster type menu "Node1 master and Node2 backup automatic failback"

8. Select "Configure Cluster Type"

 

The only other thing I can think of is that eth0 and eth1 are on the same subnet. Could this be causing confusion?

 

Regards

 

David

 

From: Emilio Campos [mailto:emilio.campos.martin <at> gmail.com]
Sent: 11 October 2011 13:43
To: zenloadbalancer-support <at> lists.sourceforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodes at the same time

 

David, please confirm me.

 applied the patch on both zen servers ?

Did you deleted the cluster interface on both nodes? and repeated the process from begining?

 Remember:  You don't need connect to both node members for configure the cluster, the secondary node will be configured automaticaly.

I'm waiting your feedback

Regards!

2011/10/11 David Martin (IT) <dmartin <at> jpress.co.uk>

Hmm, looks a bit different but still not right:

 

Node 1:

 

Zen latency is UP on GRP-ZEN-01s 10.200.28.173 | Zen latency is DOWN on GRP-ZEN-02s 10.200.28.174 <image002.png>
Cluster IP 10.200.28.175 is active on GRP-ZEN-01s Host key verification failed. 
<image001.png>
Zen Inotify is running on GRP-ZEN-01s Host key verification failed. 
<image001.png>
Global status: <image002.png>

 

Node 2:

 

Zen latency is UP on GRP-ZEN-02s 10.200.28.174 | Zen latency is DOWN on GRP-ZEN-01s 10.200.28.173 <image002.png>
Cluster IP 10.200.28.175 is active on GRP-ZEN-02s Host key verification failed. 
<image001.png>
Zen Inotify is running on GRP-ZEN-02s Host key verification failed
<image001.png>.
Global status: <image002.png>

 

David

 

From: Emilio Campos [mailto:emilio.campos.martin <at> gmail.com]
Sent: 10 October 2011 22:28
To: zenloadbalancer-support <at> lists.sourceforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodes at the same time

 

David, I just developed the patch that fix the problem reported by you, could you help us with your test and send us your feedback?

Please write my file attached on /usr/local/zenloadbalancer/www/, rewriting the actual file
Disable the cluster configuration, delete the eth0:cl interface on both nodes and repeat the proccess from the begining.


We would like to know if with this change all is working fine

We are waiting your feedback!

Thanks and regards

2011/10/10 Emilio Campos <emilio.campos.martin <at> gmail.com>

HI David, I just detected a problem on cluster configuration, from node backup to node master


We going to solve for v1 stable


Thanks about your reports!

2011/10/10 David Martin (IT) <dmartin <at> jpress.co.uk>

Hi,

 

I’m new to Zen and was hoping to get some advice. I have configured two boxes, grp-zen-01s and grp-zen-02s, and am struggling to get clustering to work.

 

I get no errors when configuring the cluster, but when I am finished I get the following status:

 

 

 

Zen latency is UP on GRP-ZEN-02s 10.200.28.174 | Zen latency is UP on GRP-ZEN-01s 10.200.28.173 <image001.png>
Cluster IP 10.200.28.175 is active on GRP-ZEN-02s Cluster is active on GRP-ZEN-01s 
<image002.png>
Zen Inotify is running on GRP-ZEN-02s GRP-ZEN-01s 
<image002.png>
Global status: <image002.png>

 

 

 

From what I can see, the VIP and Inotify should only be active on one node. I’m guessing the Passive node is having difficulty seeing the active node so it is ‘going active’ too.

 

The only ‘unusual’ bit of my setup is that both nodes are running on VMWare vSphere 5 hosts (the same host for testing, actually). I’m wondering if that could be part of the issue but I can’t see how.

 

I built one node (but no cluster or farm config) and then cloned it to get the second. I think I have caught all the IDs that I need to change (IP address, hostname, mac address, etc) but, in case I have missed something, I am going to build another node from scratch tomorrow and see if that makes a difference. Is there anything else that uniquely identifies a Zen node?

 

Thanks in advance.

 

Regards

 

David

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS  Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed. This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error.Please delete it or return it to the sender or notify us by email at postmaster <at> jpress.co.uk 

 

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support <at> lists.sourceforge.net




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support <at> lists.sourceforge.net

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster <at> jpress.co.uk 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support <at> lists.sourceforge.net

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster <at> jpress.co.uk  Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster <at> jpress.co.uk 
Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS  Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s). If you are not the intended recipient, you have received this e-mail in error.Please delete it or return it to the sender or notify us by email atpostmaster <at> jpress.co.uk  


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support <at> lists.sourceforge.net

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster <at> jpress.co.uk  Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster <at> jpress.co.uk 
Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS  Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s). If you are not the intended recipient, you have received this e-mail in error.Please delete it or return it to the sender or notify us by email atpostmaster <at> jpress.co.uk  


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support <at> lists.sourceforge.net

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct

_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

Johnston Press plc  Registered in Scotland no. SC015382 Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed. This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error.Please delete it or return it to the sender or notify us by email at postmaster <at> jpress.co.uk 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support <at> lists.sourceforge.net

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct

_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

Johnston Press plc  Registered in Scotland no. SC015382 Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed. This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error.Please delete it or return it to the sender or notify us by email at postmaster <at> jpress.co.uk 
Johnston Press plc  Registered in Scotland no. SC015382 Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed. This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error.Please delete it or return it to the sender or notify us by email at postmaster <at> jpress.co.uk 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support <at> lists.sourceforge.net

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster <at> jpress.co.uk 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster <at> jpress.co.uk  Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster <at> jpress.co.uk 
Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster <at> jpress.co.uk 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster <at> jpress.co.uk 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster <at> jpress.co.uk 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support <at> lists.sourceforge.net

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster <at> jpress.co.uk 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster <at> jpress.co.uk 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc Registered in Scotland no. SC015382 Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed. This e-mail and any files with it are solely for the use of the addressee(s). If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email at postmaster <at> jpress.co.uk

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support
Johnston Press plc Registered in Scotland no. SC015382 Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed. This e-mail and any files with it are solely for the use of the addressee(s). If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email at postmaster <at> jpress.co.uk
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
laura Garcia | 14 Oct 12:56 2011
Picon

Re: Cluster Activeonbothnodesatthesametime

In my testing, when a new ip address has been added to a network interface, the system sends ARP packets with the new state.
Could you run this command on the node 2 and try the failover again?

> tcpdump -i eth0 arp src host 10.200.28.173

The output should show the change of the MAC address when the failover is in process.

Regards,
Laura.


On Fri, Oct 14, 2011 at 11:18 AM, David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org> wrote:

In my tests you can do it without downing the interface but I think it will still confuse UCARP.

 

On the ARP front, I’ve just done a preliminary test on the switches by debugging ARP traffic. I’ve cut the logs down quite a bit (each of these switches has at least 8 10Gig ports and they are pretty busy).

 

Oct 14 09:53:28.205 UTC: IP ARP: rcvd req src 10.200.28.172 0050.5602.8172, dst 10.200.28.254 Vlan28

Oct 14 09:53:28.205 UTC: IP ARP: sent rep src 10.200.28.254 0000.0c07.ac01, dst 10.200.28.172 0050.5602.8172 Vlan28

Oct 14 09:53:39.797 UTC: IP ARP: rcvd req src 10.200.28.171 0050.5602.8171, dst 10.200.28.254 Vlan28

Oct 14 09:53:39.797 UTC: IP ARP: sent rep src 10.200.28.254 0000.0c07.ac01, dst 10.200.28.171 0050.5602.8171 Vlan28

Oct 14 09:53:50.145 UTC: IP ARP: rcvd req src 10.200.28.175 0050.5602.8172, dst 10.200.28.175 Vlan28

Oct 14 09:53:50.145 UTC: IP ARP: rcvd req src 10.200.28.175 0050.5602.8172, dst 10.200.28.175 Vlan28

Oct 14 09:53:51.145 UTC: IP ARP: rcvd req src 10.200.28.175 0050.5602.8172, dst 10.200.28.175 Vlan28

Oct 14 09:53:51.145 UTC: IP ARP: rcvd req src 10.200.28.175 0050.5602.8172, dst 10.200.28.175 Vlan28

Oct 14 09:54:14.953 UTC: IP ARP: rcvd req src 10.200.28.172 0050.5602.8172, dst 10.200.28.171 Vlan28

Oct 14 09:54:14.953 UTC: IP ARP: rcvd req src 10.200.28.172 0050.5602.8172, dst 10.200.28.171 Vlan28

Oct 14 09:54:15.953 UTC: IP ARP: rcvd req src 10.200.28.172 0050.5602.8172, dst 10.200.28.171 Vlan28

Oct 14 09:54:15.953 UTC: IP ARP: rcvd req src 10.200.28.172 0050.5602.8172, dst 10.200.28.171 Vlan28

 

This is taken just as I pull the network card on node 1 (10.200.28.171). the eth0:cl address is 10.200.28.175 and the eth0:vip01 address (my test farm) is 10.200.28.173.  Interestingly, the :cl interface ARP gets updated but the 10.200.28.173 does not.

 

I have tried ping tests on the :cl interface and that does failover correctly….. it’s just the farms that don’t work

 

David

 

From: laura Garcia [mailto:nevola-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 14 October 2011 08:24
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Definitely, it's not possible to change the MAC address. To change the MAC address we've to do a down of the physical interface, change the MAC, and then, up the interface again. Meanwhile this process is done, the CARP diagnoses a problem with the network interface (that it has been down) and then, try to failover again.

CARP doesn't wait for the timeout of ARP tables, like you said, it sends gratuitous ARP packets that would be enough to update the ARP tables on the switches. Did you have analyzed the traffic between vmware servers?

Regards,
Laura.

On Thu, Oct 13, 2011 at 5:26 PM, David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org> wrote:

You are right, sorry. It looks like it is quite involved to get more than one mac on a card. There are some linux TAP/TUN drivers that can do it but it looks pretty complex.

 

From: laura Garcia [mailto:nevola-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 13 October 2011 16:07
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

You're right, but I've been doing some testing and the system doesn't allow to change a MAC address of a virtual interface. You've to change the physical parent MAC to get it works.

On Thu, Oct 13, 2011 at 4:59 PM, David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org> wrote:

Emilio,

 

I’d love to help with any testing you want.

 

In the meantime, I’ve been looking through the ucarp documentation and the zen source so I can get a better idea of how failover is working.

 

It looks from the documentation like ucarp should be sending a Gratuitous ARP when the failover occurs so that the router can update the arp table. I’m going to have a play with wireshark later today to see if I can capture and examine this packet. If that is not working with VMware for some reason, then that might be why my failover times are so long.

 

On the mac address front, I think it should be relatively easy to change the MAC address of the vip as it comes up. In the  zenlatancy-start script you could do something like the following to change the mac address of the VIP:

 

# You already do this bit to ‘up’ the interface

ip addr add 10.200.28.174\/255.255.255.0 dev eth0\:test label eth0\:test

#This tells the kernel to reset the link address

ip link set eth0\:test address 00:11:22:33:44:55

 

You would need to have a place on the interface to edit the virtual mac address (and a way of setting it to default if someone changed it automatically), and you would have to change the interface definition file but otherwise I think everything else should just work.

 

Please don’t think I’m telling you how to develop or what direction to take Zen. It’s a great product and I’m just enthusiastic.

 

Cheers

 

David

 

 

From: Emilio Campos [mailto:emilio.campos.martin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 13 October 2011 14:51
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Hi David, at this moment UCARP can't share the mac address but we could study for add this new property

We have to study the time for develope this, maybe a process that generate an automatic mac could be interesting, or one process for introduce your own personalized mac.

We could add this but not on stable version, only release candidate, if you are interested on this, you could help us with the test

At the moment we can send you a work around for test this on your environment.

And you feel free for do donations :P

Regards

2011/10/13 David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org>

Laura,

 

This has not made any difference, sorry. I have done a bit more digging and given the issue a lot of thought and I think the following (very long, sorry) describes what is going on, at least in my environment.

 

When testing this using a local zen cluster (i.e. on the same subnet) the failover happens fairly quickly, within about 30 seconds.

 

When the cluster is on a remote subnet, the failover takes anything up to an hour.

 

The reason behind this, as far as I can see, it that Windows 7 has a very short ARP timeout (randomly selected between 15-45 seconds). The ARP entry that was mapping say:

MAC Address 00:0c:29:06:d0:a5 to    IP address   159.180.232.243

In my previous example will quickly time out and be replaced by

MAC Address 00:0c:29:8e:91:fa to    IP address   159.180.232.243

as the second node takes over.

 

When the cluster is remote, you are relying on the ARP table in the last router in the chain. By default, Cisco use and recommend an ARP timeout of four hours. This can be changed, but at the expense of increased ARP traffic, CPU load and in some cases latency. To better suit our VMWare environment, we have reduced this timeout to just one hour which we found to be a good compromise.

 

To get around this very long timeout, protocols like HSRP, GLBP, VRRP and CARP create a virtual mac address that both nodes share. When a node dies the network interface goes down and the switch immediately flushes its CAM table, meaning that the mac address almost instantly is available on the second node.

 

I suspect that by introducing the concept of a virtual mac address to Zen, this fast switchover can be achieved.

 

On the other hand, I could be doing something very wrong and, if so, please point it out! I’d be especially grateful if any other users could share their experience of Zen on a non-local subnet and what ARP timeouts are in use on the Zen VLAN.

 

Thanks for your patience once again, I definitely feel a donation will be in order soon!

 

David

 

 

 

From: laura Garcia [mailto:nevola <at> gmail.com]
Sent: 13 October 2011 13:37


To: zenloadbalancer-support-5NWGOfrQmnfLDRD5uJR0wg@public.gmane.orgeforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

David, could you try to execute the following commands under the 2 ZLB nodes?

echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 0 > /proc/sys/net/ipv4/conf/all/arp_announce

Then, try failback again.

Thanks.

On Thu, Oct 13, 2011 at 1:44 PM, David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org> wrote:

Thanks, I realise I’m being a pain but I’m really keen to get this into production!

 

From: laura Garcia [mailto:nevola <at> gmail.com]
Sent: 13 October 2011 12:38


To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Actually, you can't modify a MAC address through the zen GUI.
Let me see what can I do to support it.

About how Zen integrates CARP, maybe Emilio could give us more details.

Regards,
Laura.

On Thu, Oct 13, 2011 at 1:06 PM, David Martin (IT) <dmartin <at> jpress.co.uk> wrote:

Is there anywhere in the Zen interface definition file I can specify a mac address for the :cl interface? I can’t see a way forward without it without building a new VLAN just for Zen.

 

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 13 October 2011 11:04


To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Sorry for replying to myself again. This page suggests that CARP should be using a virtual MAC address:

 

http://www.countersiege.com/doc/pfsync-carp/

 

David

 

From: David Martin (IT) [mailto:dmartin <at> jpress.co.uk]
Sent: 13 October 2011 10:48
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

So by design Zen/CARP won’t failover until the ARP timeout has expired? That might be a bit of a showstopper for us, the default value for that is 4 hours on Cisco devices. We run at one hour but can’t really go lower on our production networks.

 

David

 

From: laura Garcia [mailto:nevola-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 13 October 2011 10:41
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

It's correct. For linux, every virtual or vlan interface uses the MAC of its physical network interface.
There is several ways to force to change a MAC, but the network driver has to support it.

Cheers,
Laura.

On Thu, Oct 13, 2011 at 10:32 AM, David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org> wrote:

I may have spoken too soon. Can you confirm something about the architecture please?

 

When both nodes are up eth0:cl only exists on node1, and ifconfig on node1 looks something like this:

 

eth0      Link encap:Ethernet  HWaddr 00:0c:29:06:d0:a5

          inet addr:159.180.232.241  Bcast:159.180.232.255  Mask:255.255.255.0

          inet6 addr: fe80::20c:29ff:fe06:d0a5/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:4653 errors:0 dropped:0 overruns:0 frame:0

          TX packets:82 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:359096 (350.6 KiB)  TX bytes:16870 (16.4 KiB)

          Interrupt:19 Base address:0x2000

 

eth0:cl   Link encap:Ethernet  HWaddr 00:0c:29:06:d0:a5

          inet addr:159.180.232.243  Bcast:0.0.0.0  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          Interrupt:19 Base address:0x2000

 

But when node 1 goes down, eth0:cl appears on node 2 and ifconfig on that node looks like this:

 

eth0      Link encap:Ethernet  HWaddr 00:0c:29:8e:91:fa

          inet addr:159.180.232.242  Bcast:159.180.232.255  Mask:255.255.255.0

          inet6 addr: fe80::20c:29ff:fe8e:91fa/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:17913 errors:0 dropped:0 overruns:0 frame:0

          TX packets:610 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:1585419 (1.5 MiB)  TX bytes:56683 (55.3 KiB)

          Interrupt:19 Base address:0x2000

 

eth0:cl   Link encap:Ethernet  HWaddr 00:0c:29:8e:91:fa

          inet addr:159.180.232.243  Bcast:0.0.0.0  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          Interrupt:19 Base address:0x2000

 

The MAC address of eth1:cl is a clone of the base eth0 address on whatever node is active. On our network, which has long ARP timeouts, this means that clients will not respond to the secondary host until the timeout period has expired (which can be over an hour). I would have thought that the virtual IP should have a virtual MAC address which floats between the two hosts (like VRRP and HSRP), but I don’t know enough about CARP to know if it works in this way too.

 

Can you tell me if ZEN is behaving correctly in this case or do I have another VMWare issue to solve?

 

Thanks again.

 

David

 

 

 

 

 

From: Emilio Campos [mailto:emilio.campos.martin <at> gmail.com]
Sent: 12 October 2011 23:02


To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Thanks to you David, your problems has been used for detected some bug with the cluster configuration and RSA communications. ;)

Welcomed!

2011/10/12 David Martin (IT) <dmartin-ANfHjr1BzNdHPrDE71CqTQ@public.gmane.orguk>

Success!

 

It is a VMWare issue. By default, our vSwitch security policy disables Promiscuous Mode, Mac Address Changes and Forged Transmits. Since CARP uses these features to establish the virtual mac and virtual IP addresses, it didn’t work. VMWare player does not have these security features and works fine.

 

By enabling these settings on the VMware port group for the VLAN that is in use, the virtual NIC can access the required functionality to support CARP (and VRRP, HSRP and similar).

 

I also found this document which describes another potential issue with CARP. It might be useful for others:

http://roggyblog.blogspot.com/2010/05/using-hsrpcarp-and-vrrp-within-vmware.html

 

Sorry to be such a pain over the last few days, I’ll keep the volume of email down now, honest!

 

On the plus side, I’m putting together some documentation on how to build for VMware and, if you want, I’d be happy to share it. I know Nick Furnell is working on an appliance that will take some of the nasty bits away (VMXnet drivers and the like) but I think there will still be some little tweaks that need to be made on the vCenter/ESX side.

 

Anyway, thanks again for the welcome and the support.

 

Regards

 

David

 

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 11 October 2011 23:06


To: zenloadbalancer-support-5NWGOfrQmnfLDRD5uJR0wg@public.gmane.orgeforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

I should be able to do those tests in the morning.

 

I used ssh-copy-id to push the public keys onto opposite nodes, ssh login without password was working fine when I checked last.

 

Regards

 

David

Sent from my iPhone


On 11 Oct 2011, at 22:59, "Emilio Campos" <emilio.campos.martin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

Hi David, I just configured my environment similar to your and I can't reproduce the error, for me all is working fine, I need more information:

please eject this commands on both nodes and send me the output:

on node1:

ps -ef| grep ucarp
ifconfig -a
ps -ef | grep inotify
ip addr list

on node2:

ps -ef | grep ucarp
ifconfig -a
ps -ef| grep inotify
ip addr list


from node1 try to connect to node2 via ssh
node1# ssh root <at> ip_node2
and from node try to connect to node1 via ssh
node2# ssh root <at> ip_node1
try before the configuration cluster, this should work writing the root password, confirm this please
try ffter the configuration cluster, this should work without write the root password, confirm this please


Access to web gui,and after RSA configuration try to test the connection clicking "Test RSA connections" buttom on both nodes please.


Also I checked the logs that you send me ,and all is fine, only errors about RSA connection, that on the end of file don't appear

Please run the test and attach to this lines the output.

The name hope it's not the cause, but if it should be the cause we could modify the sourcecode to accept these naming, no problem.

Thanks!

We are waiting your feedback

2011/10/11 David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org>

I will try in the morning. I think in my VMWare player environment I just used node1 and node2 as names. I have to be a bit more careful to use our naming conventions in the vSphere system so I used the full names.

 

If this is the cause, then is it something that can be accommodated or do I need to 'bend' my naming rules?

 

David

Sent from my iPhone


On 11 Oct 2011, at 20:50, "Emilio Campos" <emilio.campos.martin <at> gmail.com> wrote:

Hi David, I think I detected the problem, at the moment try to configure the other cluster type "node1 or node2 can be masters" and tell us!

I tell you the possible error:
On the cluster type, with failback on the file that configure the cluster /usr/local/zenloadbalancer/config/cluster.conf there is a line with this:


I am working on development environment and I suspect where is the bug!

TYPECLUSTER:GRP-ZEN-01s-GRP-ZEN-02s:UP

I defined the separator "-" to know the hostname for node master and the hostname for node backup, on this case with the hostname that you configured with "-" character the process can't  identify the two nodes.


Can you try the other cluster type and tell us if the configuration process work like a charm? :P


we hope your feedback!

2011/10/11 David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org>

Interesting, the same build in the vSphere 5 environment is not working.

 

I will do some more digging.

 

From: David Martin (IT) [mailto:dmartin <at> jpress.co.uk]
Sent: 11 October 2011 17:04


To: zenloadbalancer-support-5NWGOfrQmnfLDRD5uJR0wg@public.gmane.orgeforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Active on bothnodesatthesametime

 

I have just built a completely new pair of servers on VMWare Player, using a single NIC and the patch that you supplied. They seem to be working fine.

 

Next I will repeat the procedure on the vSphere 5 production environment, completely building each node from scratch and applying the RC5 update and the patch you gave me. I might take a snapshot inbetween RC5 and the patch and see if there is any difference.

 

Thanks for your continued patience.

 

David

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 11 October 2011 16:37
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodesatthesametime

 

Here are the config and logs.

 

Note that on zen-02, it was complaining about rsync ssh failures. I swapped public keys on the two nodes and that seems to have gone away (see further down zeninotify.log).

 

Nick, thanks for that. I didn’t really suspect VMWare as there is no multicast or other unusual ‘traffic’ going on. In the latest attempt I ditched the extra NIC (which was provisioned though VMWare) and am just using eth0 with the same result.

 

I’m convincing myself I’ve made a daft error or am labouring under a false assumption. If someone could confirm that my clustering method is correct, that would be useful.

 

Regards


David

 

From: Emilio Campos [mailto:emilio.campos.martin <at> gmail.com]
Sent: 11 October 2011 15:26
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodesatthesame time

 

David please, can you send us a tar.gz file from both nodes, with content of /usr/local/zenloadbalancer/config and /usr/local/zenloadbalancer/logs

I would like study why not on your environtment it's not working fine!

by other hand, can you try to configure all only with one eth? disable eth1 on both nodes and try again!

Tanks!

2011/10/11 David Martin (IT) <dmartin <at> jpress.co.uk>

Still not working (assuming the procedure I gave was correct):

 

Zen latency is UP on GRP-ZEN-01s 10.200.28.173 | Zen latency is UP on GRP-ZEN-02s 10.200.28.174 <image001.png>
Cluster IP 10.200.28.175 is active on GRP-ZEN-01s Cluster is active on GRP-ZEN-02s 
<image002.png>
Zen Inotify is running on GRP-ZEN-01s GRP-ZEN-02s 
<image002.png>


Global status: <image002.png>

 

<image003.jpg>

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 11 October 2011 14:51


To: zenloadbalancer-support-5NWGOfrQmnfLDRD5uJR0wg@public.gmane.orgeforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodes atthesame time

 

Hmm, not so fast. I think I deleted a vmware snapshot that contained the patched version by accident. Give me five minutes.

 

Sorry.

 

David

 

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 11 October 2011 14:46
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodes at thesame time

 

Emilio,

 

I have applied on both nodes.

 

Because I have done quite a bit of messing about, I’m tempted to start again. It should only take half an hour or so.

 

Before I do, can you confirm that the following procedure is ok please?

 

On Node1

1. Configure real IP address of eth1 = 10.200.28.173

 

On Node2

2. Configure real IP address of eth1 = 10.200.28.174

 

On Node1

3. Create virtual interface called eth1:cl = 10.200.28.175

4. Select eth1:cl as the virtual IP for a new Cluster and press "Save VIP"

5. Enter Node2's name and eth1 IP address in the "Remote" section and press "Save"

6. Type password in box and press "Configure RSA connection"

7. Select the first option from the cluster type menu "Node1 master and Node2 backup automatic failback"

8. Select "Configure Cluster Type"

 

The only other thing I can think of is that eth0 and eth1 are on the same subnet. Could this be causing confusion?

 

Regards

 

David

 

From: Emilio Campos [mailto:emilio.campos.martin <at> gmail.com]
Sent: 11 October 2011 13:43
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodes at the same time

 

David, please confirm me.

 applied the patch on both zen servers ?

Did you deleted the cluster interface on both nodes? and repeated the process from begining?

 Remember:  You don't need connect to both node members for configure the cluster, the secondary node will be configured automaticaly.

I'm waiting your feedback

Regards!

Hmm, looks a bit different but still not right:

 

Node 1:

 

Zen latency is UP on GRP-ZEN-01s 10.200.28.173 | Zen latency is DOWN on GRP-ZEN-02s 10.200.28.174 <image002.png>
Cluster IP 10.200.28.175 is active on GRP-ZEN-01s Host key verification failed. 
<image001.png>
Zen Inotify is running on GRP-ZEN-01s Host key verification failed. 
<image001.png>
Global status: <image002.png>

 

Node 2:

 

Zen latency is UP on GRP-ZEN-02s 10.200.28.174 | Zen latency is DOWN on GRP-ZEN-01s 10.200.28.173 <image002.png>
Cluster IP 10.200.28.175 is active on GRP-ZEN-02s Host key verification failed. 
<image001.png>
Zen Inotify is running on GRP-ZEN-02s Host key verification failed
<image001.png>.
Global status: <image002.png>

 

David

 

From: Emilio Campos [mailto:emilio.campos.martin <at> gmail.com]
Sent: 10 October 2011 22:28
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodes at the same time

 

David, I just developed the patch that fix the problem reported by you, could you help us with your test and send us your feedback?

Please write my file attached on /usr/local/zenloadbalancer/www/, rewriting the actual file
Disable the cluster configuration, delete the eth0:cl interface on both nodes and repeat the proccess from the begining.


We would like to know if with this change all is working fine

We are waiting your feedback!

Thanks and regards

2011/10/10 Emilio Campos <emilio.campos.martin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

HI David, I just detected a problem on cluster configuration, from node backup to node master


We going to solve for v1 stable


Thanks about your reports!

Hi,

 

I’m new to Zen and was hoping to get some advice. I have configured two boxes, grp-zen-01s and grp-zen-02s, and am struggling to get clustering to work.

 

I get no errors when configuring the cluster, but when I am finished I get the following status:

 

 

 

Zen latency is UP on GRP-ZEN-02s 10.200.28.174 | Zen latency is UP on GRP-ZEN-01s 10.200.28.173 <image001.png>
Cluster IP 10.200.28.175 is active on GRP-ZEN-02s Cluster is active on GRP-ZEN-01s 
<image002.png>
Zen Inotify is running on GRP-ZEN-02s GRP-ZEN-01s 
<image002.png>
Global status: <image002.png>

 

 

 

From what I can see, the VIP and Inotify should only be active on one node. I’m guessing the Passive node is having difficulty seeing the active node so it is ‘going active’ too.

 

The only ‘unusual’ bit of my setup is that both nodes are running on VMWare vSphere 5 hosts (the same host for testing, actually). I’m wondering if that could be part of the issue but I can’t see how.

 

I built one node (but no cluster or farm config) and then cloned it to get the second. I think I have caught all the IDs that I need to change (IP address, hostname, mac address, etc) but, in case I have missed something, I am going to build another node from scratch tomorrow and see if that makes a difference. Is there anything else that uniquely identifies a Zen node?

 

Thanks in advance.

 

Regards

 

David

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS  Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed. This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error.Please delete it or return it to the sender or notify us by email at postmaster <at> jpress.co.uk 

 

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmnd4wTydcyPnfg@public.gmane.orgceforge.net




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmncRDUWM+popnw@public.gmane.orgforge.net

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org  Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org 
Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS  Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s). If you are not the intended recipient, you have received this e-mail in error.Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org  


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org  Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org 
Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS  Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s). If you are not the intended recipient, you have received this e-mail in error.Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org  


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmncRDUWM+popnw@public.gmane.orgforge.net

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct

Johnston Press plc  Registered in Scotland no. SC015382 Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed. This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error.Please delete it or return it to the sender or notify us by email at postmaster <at> jpress.co.uk 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct

Johnston Press plc  Registered in Scotland no. SC015382 Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed. This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error.Please delete it or return it to the sender or notify us by email at postmaster <at> jpress.co.uk 
Johnston Press plc  Registered in Scotland no. SC015382 Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed. This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error.Please delete it or return it to the sender or notify us by email at postmaster <at> jpress.co.uk 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org  Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org 
Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc Registered in Scotland no. SC015382 Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed. This e-mail and any files with it are solely for the use of the addressee(s). If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email at postmaster <at> jpress.co.uk

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
David Martin (IT | 14 Oct 14:33 2011
Picon

Re: Cluster Activeonbothnodesatthesametime

I will try it now.

 

Thanks

 

David

 

From: laura Garcia [mailto:nevola-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 14 October 2011 11:56
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

In my testing, when a new ip address has been added to a network interface, the system sends ARP packets with the new state.
Could you run this command on the node 2 and try the failover again?

> tcpdump -i eth0 arp src host 10.200.28.173

The output should show the change of the MAC address when the failover is in process.

Regards,
Laura.

On Fri, Oct 14, 2011 at 11:18 AM, David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org> wrote:

In my tests you can do it without downing the interface but I think it will still confuse UCARP.

 

On the ARP front, I’ve just done a preliminary test on the switches by debugging ARP traffic. I’ve cut the logs down quite a bit (each of these switches has at least 8 10Gig ports and they are pretty busy).

 

Oct 14 09:53:28.205 UTC: IP ARP: rcvd req src 10.200.28.172 0050.5602.8172, dst 10.200.28.254 Vlan28

Oct 14 09:53:28.205 UTC: IP ARP: sent rep src 10.200.28.254 0000.0c07.ac01, dst 10.200.28.172 0050.5602.8172 Vlan28

Oct 14 09:53:39.797 UTC: IP ARP: rcvd req src 10.200.28.171 0050.5602.8171, dst 10.200.28.254 Vlan28

Oct 14 09:53:39.797 UTC: IP ARP: sent rep src 10.200.28.254 0000.0c07.ac01, dst 10.200.28.171 0050.5602.8171 Vlan28

Oct 14 09:53:50.145 UTC: IP ARP: rcvd req src 10.200.28.175 0050.5602.8172, dst 10.200.28.175 Vlan28

Oct 14 09:53:50.145 UTC: IP ARP: rcvd req src 10.200.28.175 0050.5602.8172, dst 10.200.28.175 Vlan28

Oct 14 09:53:51.145 UTC: IP ARP: rcvd req src 10.200.28.175 0050.5602.8172, dst 10.200.28.175 Vlan28

Oct 14 09:53:51.145 UTC: IP ARP: rcvd req src 10.200.28.175 0050.5602.8172, dst 10.200.28.175 Vlan28

Oct 14 09:54:14.953 UTC: IP ARP: rcvd req src 10.200.28.172 0050.5602.8172, dst 10.200.28.171 Vlan28

Oct 14 09:54:14.953 UTC: IP ARP: rcvd req src 10.200.28.172 0050.5602.8172, dst 10.200.28.171 Vlan28

Oct 14 09:54:15.953 UTC: IP ARP: rcvd req src 10.200.28.172 0050.5602.8172, dst 10.200.28.171 Vlan28

Oct 14 09:54:15.953 UTC: IP ARP: rcvd req src 10.200.28.172 0050.5602.8172, dst 10.200.28.171 Vlan28

 

This is taken just as I pull the network card on node 1 (10.200.28.171). the eth0:cl address is 10.200.28.175 and the eth0:vip01 address (my test farm) is 10.200.28.173.  Interestingly, the :cl interface ARP gets updated but the 10.200.28.173 does not.

 

I have tried ping tests on the :cl interface and that does failover correctly….. it’s just the farms that don’t work

 

David

 

From: laura Garcia [mailto:nevola-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 14 October 2011 08:24
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uuRhgaa4a2kL@public.gmane.orgnet
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Definitely, it's not possible to change the MAC address. To change the MAC address we've to do a down of the physical interface, change the MAC, and then, up the interface again. Meanwhile this process is done, the CARP diagnoses a problem with the network interface (that it has been down) and then, try to failover again.

CARP doesn't wait for the timeout of ARP tables, like you said, it sends gratuitous ARP packets that would be enough to update the ARP tables on the switches. Did you have analyzed the traffic between vmware servers?

Regards,
Laura.

On Thu, Oct 13, 2011 at 5:26 PM, David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org> wrote:

You are right, sorry. It looks like it is quite involved to get more than one mac on a card. There are some linux TAP/TUN drivers that can do it but it looks pretty complex.

 

From: laura Garcia [mailto:nevola-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 13 October 2011 16:07
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

You're right, but I've been doing some testing and the system doesn't allow to change a MAC address of a virtual interface. You've to change the physical parent MAC to get it works.

On Thu, Oct 13, 2011 at 4:59 PM, David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org> wrote:

Emilio,

 

I’d love to help with any testing you want.

 

In the meantime, I’ve been looking through the ucarp documentation and the zen source so I can get a better idea of how failover is working.

 

It looks from the documentation like ucarp should be sending a Gratuitous ARP when the failover occurs so that the router can update the arp table. I’m going to have a play with wireshark later today to see if I can capture and examine this packet. If that is not working with VMware for some reason, then that might be why my failover times are so long.

 

On the mac address front, I think it should be relatively easy to change the MAC address of the vip as it comes up. In the  zenlatancy-start script you could do something like the following to change the mac address of the VIP:

 

# You already do this bit to ‘up’ the interface

ip addr add 10.200.28.174\/255.255.255.0 dev eth0\:test label eth0\:test

#This tells the kernel to reset the link address

ip link set eth0\:test address 00:11:22:33:44:55

 

You would need to have a place on the interface to edit the virtual mac address (and a way of setting it to default if someone changed it automatically), and you would have to change the interface definition file but otherwise I think everything else should just work.

 

Please don’t think I’m telling you how to develop or what direction to take Zen. It’s a great product and I’m just enthusiastic.

 

Cheers

 

David

 

 

From: Emilio Campos [mailto:emilio.campos.martin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 13 October 2011 14:51
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Hi David, at this moment UCARP can't share the mac address but we could study for add this new property

We have to study the time for develope this, maybe a process that generate an automatic mac could be interesting, or one process for introduce your own personalized mac.

We could add this but not on stable version, only release candidate, if you are interested on this, you could help us with the test

At the moment we can send you a work around for test this on your environment.

And you feel free for do donations :P

Regards

2011/10/13 David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org>

Laura,

 

This has not made any difference, sorry. I have done a bit more digging and given the issue a lot of thought and I think the following (very long, sorry) describes what is going on, at least in my environment.

 

When testing this using a local zen cluster (i.e. on the same subnet) the failover happens fairly quickly, within about 30 seconds.

 

When the cluster is on a remote subnet, the failover takes anything up to an hour.

 

The reason behind this, as far as I can see, it that Windows 7 has a very short ARP timeout (randomly selected between 15-45 seconds). The ARP entry that was mapping say:

MAC Address 00:0c:29:06:d0:a5 to    IP address   159.180.232.243

In my previous example will quickly time out and be replaced by

MAC Address 00:0c:29:8e:91:fa to    IP address   159.180.232.243

as the second node takes over.

 

When the cluster is remote, you are relying on the ARP table in the last router in the chain. By default, Cisco use and recommend an ARP timeout of four hours. This can be changed, but at the expense of increased ARP traffic, CPU load and in some cases latency. To better suit our VMWare environment, we have reduced this timeout to just one hour which we found to be a good compromise.

 

To get around this very long timeout, protocols like HSRP, GLBP, VRRP and CARP create a virtual mac address that both nodes share. When a node dies the network interface goes down and the switch immediately flushes its CAM table, meaning that the mac address almost instantly is available on the second node.

 

I suspect that by introducing the concept of a virtual mac address to Zen, this fast switchover can be achieved.

 

On the other hand, I could be doing something very wrong and, if so, please point it out! I’d be especially grateful if any other users could share their experience of Zen on a non-local subnet and what ARP timeouts are in use on the Zen VLAN.

 

Thanks for your patience once again, I definitely feel a donation will be in order soon!

 

David

 

 

 

From: laura Garcia [mailto:nevola-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 13 October 2011 13:37


To: zenloadbalancer-support <at> lists.sourceforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

David, could you try to execute the following commands under the 2 ZLB nodes?

echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 0 > /proc/sys/net/ipv4/conf/all/arp_announce

Then, try failback again.

Thanks.

On Thu, Oct 13, 2011 at 1:44 PM, David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org> wrote:

Thanks, I realise I’m being a pain but I’m really keen to get this into production!

 

From: laura Garcia [mailto:nevola-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 13 October 2011 12:38


To: zenloadbalancer-support-5NWGOfrQmnetEtDZOKyKiw@public.gmane.orgrge.net
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Actually, you can't modify a MAC address through the zen GUI.
Let me see what can I do to support it.

About how Zen integrates CARP, maybe Emilio could give us more details.

Regards,
Laura.

On Thu, Oct 13, 2011 at 1:06 PM, David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org> wrote:

Is there anywhere in the Zen interface definition file I can specify a mac address for the :cl interface? I can’t see a way forward without it without building a new VLAN just for Zen.

 

 

From: David Martin (IT) [mailto:dmartin <at> jpress.co.uk]
Sent: 13 October 2011 11:04


To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Sorry for replying to myself again. This page suggests that CARP should be using a virtual MAC address:

 

http://www.countersiege.com/doc/pfsync-carp/

 

David

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 13 October 2011 10:48
To: zenloadbalancer-support <at> lists.sourceforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

So by design Zen/CARP won’t failover until the ARP timeout has expired? That might be a bit of a showstopper for us, the default value for that is 4 hours on Cisco devices. We run at one hour but can’t really go lower on our production networks.

 

David

 

From: laura Garcia [mailto:nevola-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 13 October 2011 10:41
To: zenloadbalancer-support <at> lists.sourceforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

It's correct. For linux, every virtual or vlan interface uses the MAC of its physical network interface.
There is several ways to force to change a MAC, but the network driver has to support it.

Cheers,
Laura.

On Thu, Oct 13, 2011 at 10:32 AM, David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org> wrote:

I may have spoken too soon. Can you confirm something about the architecture please?

 

When both nodes are up eth0:cl only exists on node1, and ifconfig on node1 looks something like this:

 

eth0      Link encap:Ethernet  HWaddr 00:0c:29:06:d0:a5

          inet addr:159.180.232.241  Bcast:159.180.232.255  Mask:255.255.255.0

          inet6 addr: fe80::20c:29ff:fe06:d0a5/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:4653 errors:0 dropped:0 overruns:0 frame:0

          TX packets:82 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:359096 (350.6 KiB)  TX bytes:16870 (16.4 KiB)

          Interrupt:19 Base address:0x2000

 

eth0:cl   Link encap:Ethernet  HWaddr 00:0c:29:06:d0:a5

          inet addr:159.180.232.243  Bcast:0.0.0.0  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          Interrupt:19 Base address:0x2000

 

But when node 1 goes down, eth0:cl appears on node 2 and ifconfig on that node looks like this:

 

eth0      Link encap:Ethernet  HWaddr 00:0c:29:8e:91:fa

          inet addr:159.180.232.242  Bcast:159.180.232.255  Mask:255.255.255.0

          inet6 addr: fe80::20c:29ff:fe8e:91fa/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:17913 errors:0 dropped:0 overruns:0 frame:0

          TX packets:610 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:1585419 (1.5 MiB)  TX bytes:56683 (55.3 KiB)

          Interrupt:19 Base address:0x2000

 

eth0:cl   Link encap:Ethernet  HWaddr 00:0c:29:8e:91:fa

          inet addr:159.180.232.243  Bcast:0.0.0.0  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          Interrupt:19 Base address:0x2000

 

The MAC address of eth1:cl is a clone of the base eth0 address on whatever node is active. On our network, which has long ARP timeouts, this means that clients will not respond to the secondary host until the timeout period has expired (which can be over an hour). I would have thought that the virtual IP should have a virtual MAC address which floats between the two hosts (like VRRP and HSRP), but I don’t know enough about CARP to know if it works in this way too.

 

Can you tell me if ZEN is behaving correctly in this case or do I have another VMWare issue to solve?

 

Thanks again.

 

David

 

 

 

 

 

From: Emilio Campos [mailto:emilio.campos.martin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 12 October 2011 23:02


To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Thanks to you David, your problems has been used for detected some bug with the cluster configuration and RSA communications. ;)

Welcomed!

2011/10/12 David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org>

Success!

 

It is a VMWare issue. By default, our vSwitch security policy disables Promiscuous Mode, Mac Address Changes and Forged Transmits. Since CARP uses these features to establish the virtual mac and virtual IP addresses, it didn’t work. VMWare player does not have these security features and works fine.

 

By enabling these settings on the VMware port group for the VLAN that is in use, the virtual NIC can access the required functionality to support CARP (and VRRP, HSRP and similar).

 

I also found this document which describes another potential issue with CARP. It might be useful for others:

http://roggyblog.blogspot.com/2010/05/using-hsrpcarp-and-vrrp-within-vmware.html

 

Sorry to be such a pain over the last few days, I’ll keep the volume of email down now, honest!

 

On the plus side, I’m putting together some documentation on how to build for VMware and, if you want, I’d be happy to share it. I know Nick Furnell is working on an appliance that will take some of the nasty bits away (VMXnet drivers and the like) but I think there will still be some little tweaks that need to be made on the vCenter/ESX side.

 

Anyway, thanks again for the welcome and the support.

 

Regards

 

David

 

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 11 October 2011 23:06


To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

I should be able to do those tests in the morning.

 

I used ssh-copy-id to push the public keys onto opposite nodes, ssh login without password was working fine when I checked last.

 

Regards

 

David

Sent from my iPhone


On 11 Oct 2011, at 22:59, "Emilio Campos" <emilio.campos.martin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

Hi David, I just configured my environment similar to your and I can't reproduce the error, for me all is working fine, I need more information:

please eject this commands on both nodes and send me the output:

on node1:

ps -ef| grep ucarp
ifconfig -a
ps -ef | grep inotify
ip addr list

on node2:

ps -ef | grep ucarp
ifconfig -a
ps -ef| grep inotify
ip addr list


from node1 try to connect to node2 via ssh
node1# ssh root <at> ip_node2
and from node try to connect to node1 via ssh
node2# ssh root <at> ip_node1
try before the configuration cluster, this should work writing the root password, confirm this please
try ffter the configuration cluster, this should work without write the root password, confirm this please


Access to web gui,and after RSA configuration try to test the connection clicking "Test RSA connections" buttom on both nodes please.


Also I checked the logs that you send me ,and all is fine, only errors about RSA connection, that on the end of file don't appear

Please run the test and attach to this lines the output.

The name hope it's not the cause, but if it should be the cause we could modify the sourcecode to accept these naming, no problem.

Thanks!

We are waiting your feedback

2011/10/11 David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org>

I will try in the morning. I think in my VMWare player environment I just used node1 and node2 as names. I have to be a bit more careful to use our naming conventions in the vSphere system so I used the full names.

 

If this is the cause, then is it something that can be accommodated or do I need to 'bend' my naming rules?

 

David

Sent from my iPhone


On 11 Oct 2011, at 20:50, "Emilio Campos" <emilio.campos.martin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

Hi David, I think I detected the problem, at the moment try to configure the other cluster type "node1 or node2 can be masters" and tell us!

I tell you the possible error:
On the cluster type, with failback on the file that configure the cluster /usr/local/zenloadbalancer/config/cluster.conf there is a line with this:


I am working on development environment and I suspect where is the bug!

TYPECLUSTER:GRP-ZEN-01s-GRP-ZEN-02s:UP

I defined the separator "-" to know the hostname for node master and the hostname for node backup, on this case with the hostname that you configured with "-" character the process can't  identify the two nodes.


Can you try the other cluster type and tell us if the configuration process work like a charm? :P


we hope your feedback!

Interesting, the same build in the vSphere 5 environment is not working.

 

I will do some more digging.

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 11 October 2011 17:04


To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Active on bothnodesatthesametime

 

I have just built a completely new pair of servers on VMWare Player, using a single NIC and the patch that you supplied. They seem to be working fine.

 

Next I will repeat the procedure on the vSphere 5 production environment, completely building each node from scratch and applying the RC5 update and the patch you gave me. I might take a snapshot inbetween RC5 and the patch and see if there is any difference.

 

Thanks for your continued patience.

 

David

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 11 October 2011 16:37
To: zenloadbalancer-support-5NWGOfrQmncRDUWM+popnw@public.gmane.orgforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodesatthesametime

 

Here are the config and logs.

 

Note that on zen-02, it was complaining about rsync ssh failures. I swapped public keys on the two nodes and that seems to have gone away (see further down zeninotify.log).

 

Nick, thanks for that. I didn’t really suspect VMWare as there is no multicast or other unusual ‘traffic’ going on. In the latest attempt I ditched the extra NIC (which was provisioned though VMWare) and am just using eth0 with the same result.

 

I’m convincing myself I’ve made a daft error or am labouring under a false assumption. If someone could confirm that my clustering method is correct, that would be useful.

 

Regards


David

 

From: Emilio Campos [mailto:emilio.campos.martin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 11 October 2011 15:26
To: zenloadbalancer-support <at> lists.sourceforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodesatthesame time

 

David please, can you send us a tar.gz file from both nodes, with content of /usr/local/zenloadbalancer/config and /usr/local/zenloadbalancer/logs

I would like study why not on your environtment it's not working fine!

by other hand, can you try to configure all only with one eth? disable eth1 on both nodes and try again!

Tanks!

Still not working (assuming the procedure I gave was correct):

 

Zen latency is UP on GRP-ZEN-01s 10.200.28.173 | Zen latency is UP on GRP-ZEN-02s 10.200.28.174 <image001.png>
Cluster IP 10.200.28.175 is active on GRP-ZEN-01s Cluster is active on GRP-ZEN-02s 
<image002.png>
Zen Inotify is running on GRP-ZEN-01s GRP-ZEN-02s 
<image002.png>


Global status: <image002.png>

 

<image003.jpg>

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 11 October 2011 14:51


To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodes atthesame time

 

Hmm, not so fast. I think I deleted a vmware snapshot that contained the patched version by accident. Give me five minutes.

 

Sorry.

 

David

 

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNdJMcDr3E8U/A@public.gmane.orgk]
Sent: 11 October 2011 14:46
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodes at thesame time

 

Emilio,

 

I have applied on both nodes.

 

Because I have done quite a bit of messing about, I’m tempted to start again. It should only take half an hour or so.

 

Before I do, can you confirm that the following procedure is ok please?

 

On Node1

1. Configure real IP address of eth1 = 10.200.28.173

 

On Node2

2. Configure real IP address of eth1 = 10.200.28.174

 

On Node1

3. Create virtual interface called eth1:cl = 10.200.28.175

4. Select eth1:cl as the virtual IP for a new Cluster and press "Save VIP"

5. Enter Node2's name and eth1 IP address in the "Remote" section and press "Save"

6. Type password in box and press "Configure RSA connection"

7. Select the first option from the cluster type menu "Node1 master and Node2 backup automatic failback"

8. Select "Configure Cluster Type"

 

The only other thing I can think of is that eth0 and eth1 are on the same subnet. Could this be causing confusion?

 

Regards

 

David

 

From: Emilio Campos [mailto:emilio.campos.martin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 11 October 2011 13:43
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodes at the same time

 

David, please confirm me.

 applied the patch on both zen servers ?

Did you deleted the cluster interface on both nodes? and repeated the process from begining?

 Remember:  You don't need connect to both node members for configure the cluster, the secondary node will be configured automaticaly.

I'm waiting your feedback

Regards!

Hmm, looks a bit different but still not right:

 

Node 1:

 

Zen latency is UP on GRP-ZEN-01s 10.200.28.173 | Zen latency is DOWN on GRP-ZEN-02s 10.200.28.174 <image002.png>
Cluster IP 10.200.28.175 is active on GRP-ZEN-01s Host key verification failed. 
<image001.png>
Zen Inotify is running on GRP-ZEN-01s Host key verification failed. 
<image001.png>
Global status: <image002.png>

 

Node 2:

 

Zen latency is UP on GRP-ZEN-02s 10.200.28.174 | Zen latency is DOWN on GRP-ZEN-01s 10.200.28.173 <image002.png>
Cluster IP 10.200.28.175 is active on GRP-ZEN-02s Host key verification failed. 
<image001.png>
Zen Inotify is running on GRP-ZEN-02s Host key verification failed
<image001.png>.
Global status: <image002.png>

 

David

 

From: Emilio Campos [mailto:emilio.campos.martin <at> gmail.com]
Sent: 10 October 2011 22:28
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodes at the same time

 

David, I just developed the patch that fix the problem reported by you, could you help us with your test and send us your feedback?

Please write my file attached on /usr/local/zenloadbalancer/www/, rewriting the actual file
Disable the cluster configuration, delete the eth0:cl interface on both nodes and repeat the proccess from the begining.


We would like to know if with this change all is working fine

We are waiting your feedback!

Thanks and regards

2011/10/10 Emilio Campos <emilio.campos.martin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

HI David, I just detected a problem on cluster configuration, from node backup to node master


We going to solve for v1 stable


Thanks about your reports!

Hi,

 

I’m new to Zen and was hoping to get some advice. I have configured two boxes, grp-zen-01s and grp-zen-02s, and am struggling to get clustering to work.

 

I get no errors when configuring the cluster, but when I am finished I get the following status:

 

 

 

Zen latency is UP on GRP-ZEN-02s 10.200.28.174 | Zen latency is UP on GRP-ZEN-01s 10.200.28.173 <image001.png>
Cluster IP 10.200.28.175 is active on GRP-ZEN-02s Cluster is active on GRP-ZEN-01s 
<image002.png>
Zen Inotify is running on GRP-ZEN-02s GRP-ZEN-01s 
<image002.png>
Global status: <image002.png>

 

 

 

From what I can see, the VIP and Inotify should only be active on one node. I’m guessing the Passive node is having difficulty seeing the active node so it is ‘going active’ too.

 

The only ‘unusual’ bit of my setup is that both nodes are running on VMWare vSphere 5 hosts (the same host for testing, actually). I’m wondering if that could be part of the issue but I can’t see how.

 

I built one node (but no cluster or farm config) and then cloned it to get the second. I think I have caught all the IDs that I need to change (IP address, hostname, mac address, etc) but, in case I have missed something, I am going to build another node from scratch tomorrow and see if that makes a difference. Is there anything else that uniquely identifies a Zen node?

 

Thanks in advance.

 

Regards

 

David

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster <at> jpress.co.uk

 

 

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uuRhgaa4a2kL@public.gmane.orgnet

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster <at> jpress.co.uk

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uuRhgaa4a2kL@public.gmane.orgnet

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster <at> jpress.co.uk

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNdHPrDE71CqTQ@public.gmane.orguk

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneHXe+LvDLADg@public.gmane.orgrceforge.net

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster <at> jpress.co.uk

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNdhl2p70BpVqQ@public.gmane.org.uk

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc Registered in Scotland no. SC015382 Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed. This e-mail and any files with it are solely for the use of the addressee(s). If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email at postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
David Martin (IT | 14 Oct 15:26 2011
Picon

Re: Cluster Activeonbothnodesatthesametime

Interesting.

 

First with 10.200.28.175, which is the eth0:cl interface:

 

root <at> zen2:~# tcpdump -i eth0 arp src host 10.200.28.175

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

14:19:33.345966 ARP, Request who-has 10.200.28.175 (00:50:56:02:81:72 (oui Unknown)) tell 10.200.28.175, length 28

14:19:34.346096 ARP, Request who-has 10.200.28.175 (00:50:56:02:81:72 (oui Unknown)) tell 10.200.28.175, length 28

 

And now with 10.200.28.173, which is the eth0:vip0 interface:

 

root <at> zen2:~# tcpdump -i eth0 arp src host 10.200.28.173

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

^C

0 packets captured

1 packets received by filter

0 packets dropped by kernel

 

No ARP packets for the vip01 interface. I’m going to move the 10.200.28.173 VIP onto eth1 and see if that produces a different result. I can’t see why it would though.

 

Regards

 

David

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 14 October 2011 13:34
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

I will try it now.

 

Thanks

 

David

 

From: laura Garcia [mailto:nevola-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 14 October 2011 11:56
To: zenloadbalancer-support <at> lists.sourceforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

In my testing, when a new ip address has been added to a network interface, the system sends ARP packets with the new state.
Could you run this command on the node 2 and try the failover again?

> tcpdump -i eth0 arp src host 10.200.28.173

The output should show the change of the MAC address when the failover is in process.

Regards,
Laura.

On Fri, Oct 14, 2011 at 11:18 AM, David Martin (IT) <dmartin <at> jpress.co.uk> wrote:

In my tests you can do it without downing the interface but I think it will still confuse UCARP.

 

On the ARP front, I’ve just done a preliminary test on the switches by debugging ARP traffic. I’ve cut the logs down quite a bit (each of these switches has at least 8 10Gig ports and they are pretty busy).

 

Oct 14 09:53:28.205 UTC: IP ARP: rcvd req src 10.200.28.172 0050.5602.8172, dst 10.200.28.254 Vlan28

Oct 14 09:53:28.205 UTC: IP ARP: sent rep src 10.200.28.254 0000.0c07.ac01, dst 10.200.28.172 0050.5602.8172 Vlan28

Oct 14 09:53:39.797 UTC: IP ARP: rcvd req src 10.200.28.171 0050.5602.8171, dst 10.200.28.254 Vlan28

Oct 14 09:53:39.797 UTC: IP ARP: sent rep src 10.200.28.254 0000.0c07.ac01, dst 10.200.28.171 0050.5602.8171 Vlan28

Oct 14 09:53:50.145 UTC: IP ARP: rcvd req src 10.200.28.175 0050.5602.8172, dst 10.200.28.175 Vlan28

Oct 14 09:53:50.145 UTC: IP ARP: rcvd req src 10.200.28.175 0050.5602.8172, dst 10.200.28.175 Vlan28

Oct 14 09:53:51.145 UTC: IP ARP: rcvd req src 10.200.28.175 0050.5602.8172, dst 10.200.28.175 Vlan28

Oct 14 09:53:51.145 UTC: IP ARP: rcvd req src 10.200.28.175 0050.5602.8172, dst 10.200.28.175 Vlan28

Oct 14 09:54:14.953 UTC: IP ARP: rcvd req src 10.200.28.172 0050.5602.8172, dst 10.200.28.171 Vlan28

Oct 14 09:54:14.953 UTC: IP ARP: rcvd req src 10.200.28.172 0050.5602.8172, dst 10.200.28.171 Vlan28

Oct 14 09:54:15.953 UTC: IP ARP: rcvd req src 10.200.28.172 0050.5602.8172, dst 10.200.28.171 Vlan28

Oct 14 09:54:15.953 UTC: IP ARP: rcvd req src 10.200.28.172 0050.5602.8172, dst 10.200.28.171 Vlan28

 

This is taken just as I pull the network card on node 1 (10.200.28.171). the eth0:cl address is 10.200.28.175 and the eth0:vip01 address (my test farm) is 10.200.28.173.  Interestingly, the :cl interface ARP gets updated but the 10.200.28.173 does not.

 

I have tried ping tests on the :cl interface and that does failover correctly….. it’s just the farms that don’t work

 

David

 

From: laura Garcia [mailto:nevola <at> gmail.com]
Sent: 14 October 2011 08:24
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Definitely, it's not possible to change the MAC address. To change the MAC address we've to do a down of the physical interface, change the MAC, and then, up the interface again. Meanwhile this process is done, the CARP diagnoses a problem with the network interface (that it has been down) and then, try to failover again.

CARP doesn't wait for the timeout of ARP tables, like you said, it sends gratuitous ARP packets that would be enough to update the ARP tables on the switches. Did you have analyzed the traffic between vmware servers?

Regards,
Laura.

On Thu, Oct 13, 2011 at 5:26 PM, David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org> wrote:

You are right, sorry. It looks like it is quite involved to get more than one mac on a card. There are some linux TAP/TUN drivers that can do it but it looks pretty complex.

 

From: laura Garcia [mailto:nevola-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 13 October 2011 16:07
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

You're right, but I've been doing some testing and the system doesn't allow to change a MAC address of a virtual interface. You've to change the physical parent MAC to get it works.

On Thu, Oct 13, 2011 at 4:59 PM, David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org> wrote:

Emilio,

 

I’d love to help with any testing you want.

 

In the meantime, I’ve been looking through the ucarp documentation and the zen source so I can get a better idea of how failover is working.

 

It looks from the documentation like ucarp should be sending a Gratuitous ARP when the failover occurs so that the router can update the arp table. I’m going to have a play with wireshark later today to see if I can capture and examine this packet. If that is not working with VMware for some reason, then that might be why my failover times are so long.

 

On the mac address front, I think it should be relatively easy to change the MAC address of the vip as it comes up. In the  zenlatancy-start script you could do something like the following to change the mac address of the VIP:

 

# You already do this bit to ‘up’ the interface

ip addr add 10.200.28.174\/255.255.255.0 dev eth0\:test label eth0\:test

#This tells the kernel to reset the link address

ip link set eth0\:test address 00:11:22:33:44:55

 

You would need to have a place on the interface to edit the virtual mac address (and a way of setting it to default if someone changed it automatically), and you would have to change the interface definition file but otherwise I think everything else should just work.

 

Please don’t think I’m telling you how to develop or what direction to take Zen. It’s a great product and I’m just enthusiastic.

 

Cheers

 

David

 

 

From: Emilio Campos [mailto:emilio.campos.martin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 13 October 2011 14:51
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Hi David, at this moment UCARP can't share the mac address but we could study for add this new property

We have to study the time for develope this, maybe a process that generate an automatic mac could be interesting, or one process for introduce your own personalized mac.

We could add this but not on stable version, only release candidate, if you are interested on this, you could help us with the test

At the moment we can send you a work around for test this on your environment.

And you feel free for do donations :P

Regards

2011/10/13 David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org>

Laura,

 

This has not made any difference, sorry. I have done a bit more digging and given the issue a lot of thought and I think the following (very long, sorry) describes what is going on, at least in my environment.

 

When testing this using a local zen cluster (i.e. on the same subnet) the failover happens fairly quickly, within about 30 seconds.

 

When the cluster is on a remote subnet, the failover takes anything up to an hour.

 

The reason behind this, as far as I can see, it that Windows 7 has a very short ARP timeout (randomly selected between 15-45 seconds). The ARP entry that was mapping say:

MAC Address 00:0c:29:06:d0:a5 to    IP address   159.180.232.243

In my previous example will quickly time out and be replaced by

MAC Address 00:0c:29:8e:91:fa to    IP address   159.180.232.243

as the second node takes over.

 

When the cluster is remote, you are relying on the ARP table in the last router in the chain. By default, Cisco use and recommend an ARP timeout of four hours. This can be changed, but at the expense of increased ARP traffic, CPU load and in some cases latency. To better suit our VMWare environment, we have reduced this timeout to just one hour which we found to be a good compromise.

 

To get around this very long timeout, protocols like HSRP, GLBP, VRRP and CARP create a virtual mac address that both nodes share. When a node dies the network interface goes down and the switch immediately flushes its CAM table, meaning that the mac address almost instantly is available on the second node.

 

I suspect that by introducing the concept of a virtual mac address to Zen, this fast switchover can be achieved.

 

On the other hand, I could be doing something very wrong and, if so, please point it out! I’d be especially grateful if any other users could share their experience of Zen on a non-local subnet and what ARP timeouts are in use on the Zen VLAN.

 

Thanks for your patience once again, I definitely feel a donation will be in order soon!

 

David

 

 

 

From: laura Garcia [mailto:nevola-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 13 October 2011 13:37


To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

David, could you try to execute the following commands under the 2 ZLB nodes?

echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 0 > /proc/sys/net/ipv4/conf/all/arp_announce

Then, try failback again.

Thanks.

On Thu, Oct 13, 2011 at 1:44 PM, David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org> wrote:

Thanks, I realise I’m being a pain but I’m really keen to get this into production!

 

From: laura Garcia [mailto:nevola-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 13 October 2011 12:38


To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Actually, you can't modify a MAC address through the zen GUI.
Let me see what can I do to support it.

About how Zen integrates CARP, maybe Emilio could give us more details.

Regards,
Laura.

On Thu, Oct 13, 2011 at 1:06 PM, David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org> wrote:

Is there anywhere in the Zen interface definition file I can specify a mac address for the :cl interface? I can’t see a way forward without it without building a new VLAN just for Zen.

 

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 13 October 2011 11:04


To: zenloadbalancer-support <at> lists.sourceforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Sorry for replying to myself again. This page suggests that CARP should be using a virtual MAC address:

 

http://www.countersiege.com/doc/pfsync-carp/

 

David

 

From: David Martin (IT) [mailto:dmartin <at> jpress.co.uk]
Sent: 13 October 2011 10:48
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

So by design Zen/CARP won’t failover until the ARP timeout has expired? That might be a bit of a showstopper for us, the default value for that is 4 hours on Cisco devices. We run at one hour but can’t really go lower on our production networks.

 

David

 

From: laura Garcia [mailto:nevola-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 13 October 2011 10:41
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

It's correct. For linux, every virtual or vlan interface uses the MAC of its physical network interface.
There is several ways to force to change a MAC, but the network driver has to support it.

Cheers,
Laura.

On Thu, Oct 13, 2011 at 10:32 AM, David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org> wrote:

I may have spoken too soon. Can you confirm something about the architecture please?

 

When both nodes are up eth0:cl only exists on node1, and ifconfig on node1 looks something like this:

 

eth0      Link encap:Ethernet  HWaddr 00:0c:29:06:d0:a5

          inet addr:159.180.232.241  Bcast:159.180.232.255  Mask:255.255.255.0

          inet6 addr: fe80::20c:29ff:fe06:d0a5/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:4653 errors:0 dropped:0 overruns:0 frame:0

          TX packets:82 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:359096 (350.6 KiB)  TX bytes:16870 (16.4 KiB)

          Interrupt:19 Base address:0x2000

 

eth0:cl   Link encap:Ethernet  HWaddr 00:0c:29:06:d0:a5

          inet addr:159.180.232.243  Bcast:0.0.0.0  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          Interrupt:19 Base address:0x2000

 

But when node 1 goes down, eth0:cl appears on node 2 and ifconfig on that node looks like this:

 

eth0      Link encap:Ethernet  HWaddr 00:0c:29:8e:91:fa

          inet addr:159.180.232.242  Bcast:159.180.232.255  Mask:255.255.255.0

          inet6 addr: fe80::20c:29ff:fe8e:91fa/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:17913 errors:0 dropped:0 overruns:0 frame:0

          TX packets:610 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:1585419 (1.5 MiB)  TX bytes:56683 (55.3 KiB)

          Interrupt:19 Base address:0x2000

 

eth0:cl   Link encap:Ethernet  HWaddr 00:0c:29:8e:91:fa

          inet addr:159.180.232.243  Bcast:0.0.0.0  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          Interrupt:19 Base address:0x2000

 

The MAC address of eth1:cl is a clone of the base eth0 address on whatever node is active. On our network, which has long ARP timeouts, this means that clients will not respond to the secondary host until the timeout period has expired (which can be over an hour). I would have thought that the virtual IP should have a virtual MAC address which floats between the two hosts (like VRRP and HSRP), but I don’t know enough about CARP to know if it works in this way too.

 

Can you tell me if ZEN is behaving correctly in this case or do I have another VMWare issue to solve?

 

Thanks again.

 

David

 

 

 

 

 

From: Emilio Campos [mailto:emilio.campos.martin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 12 October 2011 23:02


To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Thanks to you David, your problems has been used for detected some bug with the cluster configuration and RSA communications. ;)

Welcomed!

2011/10/12 David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org>

Success!

 

It is a VMWare issue. By default, our vSwitch security policy disables Promiscuous Mode, Mac Address Changes and Forged Transmits. Since CARP uses these features to establish the virtual mac and virtual IP addresses, it didn’t work. VMWare player does not have these security features and works fine.

 

By enabling these settings on the VMware port group for the VLAN that is in use, the virtual NIC can access the required functionality to support CARP (and VRRP, HSRP and similar).

 

I also found this document which describes another potential issue with CARP. It might be useful for others:

http://roggyblog.blogspot.com/2010/05/using-hsrpcarp-and-vrrp-within-vmware.html

 

Sorry to be such a pain over the last few days, I’ll keep the volume of email down now, honest!

 

On the plus side, I’m putting together some documentation on how to build for VMware and, if you want, I’d be happy to share it. I know Nick Furnell is working on an appliance that will take some of the nasty bits away (VMXnet drivers and the like) but I think there will still be some little tweaks that need to be made on the vCenter/ESX side.

 

Anyway, thanks again for the welcome and the support.

 

Regards

 

David

 

 

From: David Martin (IT) [mailto:dmartin <at> jpress.co.uk]
Sent: 11 October 2011 23:06


To: zenloadbalancer-support <at> lists.sourceforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

I should be able to do those tests in the morning.

 

I used ssh-copy-id to push the public keys onto opposite nodes, ssh login without password was working fine when I checked last.

 

Regards

 

David

Sent from my iPhone


On 11 Oct 2011, at 22:59, "Emilio Campos" <emilio.campos.martin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

Hi David, I just configured my environment similar to your and I can't reproduce the error, for me all is working fine, I need more information:

please eject this commands on both nodes and send me the output:

on node1:

ps -ef| grep ucarp
ifconfig -a
ps -ef | grep inotify
ip addr list

on node2:

ps -ef | grep ucarp
ifconfig -a
ps -ef| grep inotify
ip addr list


from node1 try to connect to node2 via ssh
node1# ssh root <at> ip_node2
and from node try to connect to node1 via ssh
node2# ssh root <at> ip_node1
try before the configuration cluster, this should work writing the root password, confirm this please
try ffter the configuration cluster, this should work without write the root password, confirm this please


Access to web gui,and after RSA configuration try to test the connection clicking "Test RSA connections" buttom on both nodes please.


Also I checked the logs that you send me ,and all is fine, only errors about RSA connection, that on the end of file don't appear

Please run the test and attach to this lines the output.

The name hope it's not the cause, but if it should be the cause we could modify the sourcecode to accept these naming, no problem.

Thanks!

We are waiting your feedback

2011/10/11 David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org>

I will try in the morning. I think in my VMWare player environment I just used node1 and node2 as names. I have to be a bit more careful to use our naming conventions in the vSphere system so I used the full names.

 

If this is the cause, then is it something that can be accommodated or do I need to 'bend' my naming rules?

 

David

Sent from my iPhone


On 11 Oct 2011, at 20:50, "Emilio Campos" <emilio.campos.martin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

Hi David, I think I detected the problem, at the moment try to configure the other cluster type "node1 or node2 can be masters" and tell us!

I tell you the possible error:
On the cluster type, with failback on the file that configure the cluster /usr/local/zenloadbalancer/config/cluster.conf there is a line with this:


I am working on development environment and I suspect where is the bug!

TYPECLUSTER:GRP-ZEN-01s-GRP-ZEN-02s:UP

I defined the separator "-" to know the hostname for node master and the hostname for node backup, on this case with the hostname that you configured with "-" character the process can't  identify the two nodes.


Can you try the other cluster type and tell us if the configuration process work like a charm? :P


we hope your feedback!

Interesting, the same build in the vSphere 5 environment is not working.

 

I will do some more digging.

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 11 October 2011 17:04


To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Active on bothnodesatthesametime

 

I have just built a completely new pair of servers on VMWare Player, using a single NIC and the patch that you supplied. They seem to be working fine.

 

Next I will repeat the procedure on the vSphere 5 production environment, completely building each node from scratch and applying the RC5 update and the patch you gave me. I might take a snapshot inbetween RC5 and the patch and see if there is any difference.

 

Thanks for your continued patience.

 

David

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 11 October 2011 16:37
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodesatthesametime

 

Here are the config and logs.

 

Note that on zen-02, it was complaining about rsync ssh failures. I swapped public keys on the two nodes and that seems to have gone away (see further down zeninotify.log).

 

Nick, thanks for that. I didn’t really suspect VMWare as there is no multicast or other unusual ‘traffic’ going on. In the latest attempt I ditched the extra NIC (which was provisioned though VMWare) and am just using eth0 with the same result.

 

I’m convincing myself I’ve made a daft error or am labouring under a false assumption. If someone could confirm that my clustering method is correct, that would be useful.

 

Regards


David

 

From: Emilio Campos [mailto:emilio.campos.martin <at> gmail.com]
Sent: 11 October 2011 15:26
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodesatthesame time

 

David please, can you send us a tar.gz file from both nodes, with content of /usr/local/zenloadbalancer/config and /usr/local/zenloadbalancer/logs

I would like study why not on your environtment it's not working fine!

by other hand, can you try to configure all only with one eth? disable eth1 on both nodes and try again!

Tanks!

Still not working (assuming the procedure I gave was correct):

 

Zen latency is UP on GRP-ZEN-01s 10.200.28.173 | Zen latency is UP on GRP-ZEN-02s 10.200.28.174 <image001.png>
Cluster IP 10.200.28.175 is active on GRP-ZEN-01s Cluster is active on GRP-ZEN-02s 
<image002.png>
Zen Inotify is running on GRP-ZEN-01s GRP-ZEN-02s 
<image002.png>


Global status: <image002.png>

 

<image003.jpg>

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 11 October 2011 14:51


To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodes atthesame time

 

Hmm, not so fast. I think I deleted a vmware snapshot that contained the patched version by accident. Give me five minutes.

 

Sorry.

 

David

 

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 11 October 2011 14:46
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodes at thesame time

 

Emilio,

 

I have applied on both nodes.

 

Because I have done quite a bit of messing about, I’m tempted to start again. It should only take half an hour or so.

 

Before I do, can you confirm that the following procedure is ok please?

 

On Node1

1. Configure real IP address of eth1 = 10.200.28.173

 

On Node2

2. Configure real IP address of eth1 = 10.200.28.174

 

On Node1

3. Create virtual interface called eth1:cl = 10.200.28.175

4. Select eth1:cl as the virtual IP for a new Cluster and press "Save VIP"

5. Enter Node2's name and eth1 IP address in the "Remote" section and press "Save"

6. Type password in box and press "Configure RSA connection"

7. Select the first option from the cluster type menu "Node1 master and Node2 backup automatic failback"

8. Select "Configure Cluster Type"

 

The only other thing I can think of is that eth0 and eth1 are on the same subnet. Could this be causing confusion?

 

Regards

 

David

 

From: Emilio Campos [mailto:emilio.campos.martin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 11 October 2011 13:43
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5urNAH6kLmebB@public.gmane.org.net
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodes at the same time

 

David, please confirm me.

 applied the patch on both zen servers ?

Did you deleted the cluster interface on both nodes? and repeated the process from begining?

 Remember:  You don't need connect to both node members for configure the cluster, the secondary node will be configured automaticaly.

I'm waiting your feedback

Regards!

Hmm, looks a bit different but still not right:

 

Node 1:

 

Zen latency is UP on GRP-ZEN-01s 10.200.28.173 | Zen latency is DOWN on GRP-ZEN-02s 10.200.28.174 <image002.png>
Cluster IP 10.200.28.175 is active on GRP-ZEN-01s Host key verification failed. 
<image001.png>
Zen Inotify is running on GRP-ZEN-01s Host key verification failed. 
<image001.png>
Global status: <image002.png>

 

Node 2:

 

Zen latency is UP on GRP-ZEN-02s 10.200.28.174 | Zen latency is DOWN on GRP-ZEN-01s 10.200.28.173 <image002.png>
Cluster IP 10.200.28.175 is active on GRP-ZEN-02s Host key verification failed. 
<image001.png>
Zen Inotify is running on GRP-ZEN-02s Host key verification failed
<image001.png>.
Global status: <image002.png>

 

David

 

From: Emilio Campos [mailto:emilio.campos.martin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 10 October 2011 22:28
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodes at the same time

 

David, I just developed the patch that fix the problem reported by you, could you help us with your test and send us your feedback?

Please write my file attached on /usr/local/zenloadbalancer/www/, rewriting the actual file
Disable the cluster configuration, delete the eth0:cl interface on both nodes and repeat the proccess from the begining.


We would like to know if with this change all is working fine

We are waiting your feedback!

Thanks and regards

2011/10/10 Emilio Campos <emilio.campos.martin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

HI David, I just detected a problem on cluster configuration, from node backup to node master


We going to solve for v1 stable


Thanks about your reports!

Hi,

 

I’m new to Zen and was hoping to get some advice. I have configured two boxes, grp-zen-01s and grp-zen-02s, and am struggling to get clustering to work.

 

I get no errors when configuring the cluster, but when I am finished I get the following status:

 

 

 

Zen latency is UP on GRP-ZEN-02s 10.200.28.174 | Zen latency is UP on GRP-ZEN-01s 10.200.28.173 <image001.png>
Cluster IP 10.200.28.175 is active on GRP-ZEN-02s Cluster is active on GRP-ZEN-01s 
<image002.png>
Zen Inotify is running on GRP-ZEN-02s GRP-ZEN-01s 
<image002.png>
Global status: <image002.png>

 

 

 

From what I can see, the VIP and Inotify should only be active on one node. I’m guessing the Passive node is having difficulty seeing the active node so it is ‘going active’ too.

 

The only ‘unusual’ bit of my setup is that both nodes are running on VMWare vSphere 5 hosts (the same host for testing, actually). I’m wondering if that could be part of the issue but I can’t see how.

 

I built one node (but no cluster or farm config) and then cloned it to get the second. I think I have caught all the IDs that I need to change (IP address, hostname, mac address, etc) but, in case I have missed something, I am going to build another node from scratch tomorrow and see if that makes a difference. Is there anything else that uniquely identifies a Zen node?

 

Thanks in advance.

 

Regards

 

David

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 

 

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmnfLDRD5uJR0wg@public.gmane.orgeforge.net
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5urNAH6kLmebB@public.gmane.org.net




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster <at> jpress.co.uk

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5urNAH6kLmebB@public.gmane.org.net

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster <at> jpress.co.uk

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster <at> jpress.co.uk

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster <at> jpress.co.uk

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmnc@public.gmane.orgurceforge.net
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 

Johnston Press plc Registered in Scotland no. SC015382 Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed. This e-mail and any files with it are solely for the use of the addressee(s). If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email at postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
laura Garcia | 14 Oct 17:57 2011
Picon

Re: Cluster Activeonbothnodesatthesametime

Ok, it's the behaviour I though.

Meanwhile we find a way to force the ARP replication, you could use the cluster interface (eth0:cl) to start the farm service as workaround.

Regards,
Laura.


On Fri, Oct 14, 2011 at 3:26 PM, David Martin (IT) <dmartin <at> jpress.co.uk> wrote:

Interesting.

 

First with 10.200.28.175, which is the eth0:cl interface:

 

root <at> zen2:~# tcpdump -i eth0 arp src host 10.200.28.175

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

14:19:33.345966 ARP, Request who-has 10.200.28.175 (00:50:56:02:81:72 (oui Unknown)) tell 10.200.28.175, length 28

14:19:34.346096 ARP, Request who-has 10.200.28.175 (00:50:56:02:81:72 (oui Unknown)) tell 10.200.28.175, length 28

 

And now with 10.200.28.173, which is the eth0:vip0 interface:

 

root <at> zen2:~# tcpdump -i eth0 arp src host 10.200.28.173

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

^C

0 packets captured

1 packets received by filter

0 packets dropped by kernel

 

No ARP packets for the vip01 interface. I’m going to move the 10.200.28.173 VIP onto eth1 and see if that produces a different result. I can’t see why it would though.

 

Regards

 

David

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 14 October 2011 13:34
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

I will try it now.

 

Thanks

 

David

 

From: laura Garcia [mailto:nevola-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 14 October 2011 11:56
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

In my testing, when a new ip address has been added to a network interface, the system sends ARP packets with the new state.
Could you run this command on the node 2 and try the failover again?

> tcpdump -i eth0 arp src host 10.200.28.173

The output should show the change of the MAC address when the failover is in process.

Regards,
Laura.

On Fri, Oct 14, 2011 at 11:18 AM, David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org> wrote:

In my tests you can do it without downing the interface but I think it will still confuse UCARP.

 

On the ARP front, I’ve just done a preliminary test on the switches by debugging ARP traffic. I’ve cut the logs down quite a bit (each of these switches has at least 8 10Gig ports and they are pretty busy).

 

Oct 14 09:53:28.205 UTC: IP ARP: rcvd req src 10.200.28.172 0050.5602.8172, dst 10.200.28.254 Vlan28

Oct 14 09:53:28.205 UTC: IP ARP: sent rep src 10.200.28.254 0000.0c07.ac01, dst 10.200.28.172 0050.5602.8172 Vlan28

Oct 14 09:53:39.797 UTC: IP ARP: rcvd req src 10.200.28.171 0050.5602.8171, dst 10.200.28.254 Vlan28

Oct 14 09:53:39.797 UTC: IP ARP: sent rep src 10.200.28.254 0000.0c07.ac01, dst 10.200.28.171 0050.5602.8171 Vlan28

Oct 14 09:53:50.145 UTC: IP ARP: rcvd req src 10.200.28.175 0050.5602.8172, dst 10.200.28.175 Vlan28

Oct 14 09:53:50.145 UTC: IP ARP: rcvd req src 10.200.28.175 0050.5602.8172, dst 10.200.28.175 Vlan28

Oct 14 09:53:51.145 UTC: IP ARP: rcvd req src 10.200.28.175 0050.5602.8172, dst 10.200.28.175 Vlan28

Oct 14 09:53:51.145 UTC: IP ARP: rcvd req src 10.200.28.175 0050.5602.8172, dst 10.200.28.175 Vlan28

Oct 14 09:54:14.953 UTC: IP ARP: rcvd req src 10.200.28.172 0050.5602.8172, dst 10.200.28.171 Vlan28

Oct 14 09:54:14.953 UTC: IP ARP: rcvd req src 10.200.28.172 0050.5602.8172, dst 10.200.28.171 Vlan28

Oct 14 09:54:15.953 UTC: IP ARP: rcvd req src 10.200.28.172 0050.5602.8172, dst 10.200.28.171 Vlan28

Oct 14 09:54:15.953 UTC: IP ARP: rcvd req src 10.200.28.172 0050.5602.8172, dst 10.200.28.171 Vlan28

 

This is taken just as I pull the network card on node 1 (10.200.28.171). the eth0:cl address is 10.200.28.175 and the eth0:vip01 address (my test farm) is 10.200.28.173.  Interestingly, the :cl interface ARP gets updated but the 10.200.28.173 does not.

 

I have tried ping tests on the :cl interface and that does failover correctly….. it’s just the farms that don’t work

 

David

 

From: laura Garcia [mailto:nevola <at> gmail.com]
Sent: 14 October 2011 08:24
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Definitely, it's not possible to change the MAC address. To change the MAC address we've to do a down of the physical interface, change the MAC, and then, up the interface again. Meanwhile this process is done, the CARP diagnoses a problem with the network interface (that it has been down) and then, try to failover again.

CARP doesn't wait for the timeout of ARP tables, like you said, it sends gratuitous ARP packets that would be enough to update the ARP tables on the switches. Did you have analyzed the traffic between vmware servers?

Regards,
Laura.

On Thu, Oct 13, 2011 at 5:26 PM, David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org> wrote:

You are right, sorry. It looks like it is quite involved to get more than one mac on a card. There are some linux TAP/TUN drivers that can do it but it looks pretty complex.

 

From: laura Garcia [mailto:nevola-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 13 October 2011 16:07
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

You're right, but I've been doing some testing and the system doesn't allow to change a MAC address of a virtual interface. You've to change the physical parent MAC to get it works.

On Thu, Oct 13, 2011 at 4:59 PM, David Martin (IT) <dmartin <at> jpress.co.uk> wrote:

Emilio,

 

I’d love to help with any testing you want.

 

In the meantime, I’ve been looking through the ucarp documentation and the zen source so I can get a better idea of how failover is working.

 

It looks from the documentation like ucarp should be sending a Gratuitous ARP when the failover occurs so that the router can update the arp table. I’m going to have a play with wireshark later today to see if I can capture and examine this packet. If that is not working with VMware for some reason, then that might be why my failover times are so long.

 

On the mac address front, I think it should be relatively easy to change the MAC address of the vip as it comes up. In the  zenlatancy-start script you could do something like the following to change the mac address of the VIP:

 

# You already do this bit to ‘up’ the interface

ip addr add 10.200.28.174\/255.255.255.0 dev eth0\:test label eth0\:test

#This tells the kernel to reset the link address

ip link set eth0\:test address 00:11:22:33:44:55

 

You would need to have a place on the interface to edit the virtual mac address (and a way of setting it to default if someone changed it automatically), and you would have to change the interface definition file but otherwise I think everything else should just work.

 

Please don’t think I’m telling you how to develop or what direction to take Zen. It’s a great product and I’m just enthusiastic.

 

Cheers

 

David

 

 

From: Emilio Campos [mailto:emilio.campos.martin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 13 October 2011 14:51
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Hi David, at this moment UCARP can't share the mac address but we could study for add this new property

We have to study the time for develope this, maybe a process that generate an automatic mac could be interesting, or one process for introduce your own personalized mac.

We could add this but not on stable version, only release candidate, if you are interested on this, you could help us with the test

At the moment we can send you a work around for test this on your environment.

And you feel free for do donations :P

Regards

2011/10/13 David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org>

Laura,

 

This has not made any difference, sorry. I have done a bit more digging and given the issue a lot of thought and I think the following (very long, sorry) describes what is going on, at least in my environment.

 

When testing this using a local zen cluster (i.e. on the same subnet) the failover happens fairly quickly, within about 30 seconds.

 

When the cluster is on a remote subnet, the failover takes anything up to an hour.

 

The reason behind this, as far as I can see, it that Windows 7 has a very short ARP timeout (randomly selected between 15-45 seconds). The ARP entry that was mapping say:

MAC Address 00:0c:29:06:d0:a5 to    IP address   159.180.232.243

In my previous example will quickly time out and be replaced by

MAC Address 00:0c:29:8e:91:fa to    IP address   159.180.232.243

as the second node takes over.

 

When the cluster is remote, you are relying on the ARP table in the last router in the chain. By default, Cisco use and recommend an ARP timeout of four hours. This can be changed, but at the expense of increased ARP traffic, CPU load and in some cases latency. To better suit our VMWare environment, we have reduced this timeout to just one hour which we found to be a good compromise.

 

To get around this very long timeout, protocols like HSRP, GLBP, VRRP and CARP create a virtual mac address that both nodes share. When a node dies the network interface goes down and the switch immediately flushes its CAM table, meaning that the mac address almost instantly is available on the second node.

 

I suspect that by introducing the concept of a virtual mac address to Zen, this fast switchover can be achieved.

 

On the other hand, I could be doing something very wrong and, if so, please point it out! I’d be especially grateful if any other users could share their experience of Zen on a non-local subnet and what ARP timeouts are in use on the Zen VLAN.

 

Thanks for your patience once again, I definitely feel a donation will be in order soon!

 

David

 

 

 

From: laura Garcia [mailto:nevola-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 13 October 2011 13:37


To: zenloadbalancer-support-5NWGOfrQmnfLDRD5uJR0wg@public.gmane.orgeforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

David, could you try to execute the following commands under the 2 ZLB nodes?

echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 0 > /proc/sys/net/ipv4/conf/all/arp_announce

Then, try failback again.

Thanks.

On Thu, Oct 13, 2011 at 1:44 PM, David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org> wrote:

Thanks, I realise I’m being a pain but I’m really keen to get this into production!

 

From: laura Garcia [mailto:nevola <at> gmail.com]
Sent: 13 October 2011 12:38


To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Actually, you can't modify a MAC address through the zen GUI.
Let me see what can I do to support it.

About how Zen integrates CARP, maybe Emilio could give us more details.

Regards,
Laura.

On Thu, Oct 13, 2011 at 1:06 PM, David Martin (IT) <dmartin <at> jpress.co.uk> wrote:

Is there anywhere in the Zen interface definition file I can specify a mac address for the :cl interface? I can’t see a way forward without it without building a new VLAN just for Zen.

 

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 13 October 2011 11:04


To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Sorry for replying to myself again. This page suggests that CARP should be using a virtual MAC address:

 

http://www.countersiege.com/doc/pfsync-carp/

 

David

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 13 October 2011 10:48
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

So by design Zen/CARP won’t failover until the ARP timeout has expired? That might be a bit of a showstopper for us, the default value for that is 4 hours on Cisco devices. We run at one hour but can’t really go lower on our production networks.

 

David

 

From: laura Garcia [mailto:nevola <at> gmail.com]
Sent: 13 October 2011 10:41
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

It's correct. For linux, every virtual or vlan interface uses the MAC of its physical network interface.
There is several ways to force to change a MAC, but the network driver has to support it.

Cheers,
Laura.

On Thu, Oct 13, 2011 at 10:32 AM, David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org> wrote:

I may have spoken too soon. Can you confirm something about the architecture please?

 

When both nodes are up eth0:cl only exists on node1, and ifconfig on node1 looks something like this:

 

eth0      Link encap:Ethernet  HWaddr 00:0c:29:06:d0:a5

          inet addr:159.180.232.241  Bcast:159.180.232.255  Mask:255.255.255.0

          inet6 addr: fe80::20c:29ff:fe06:d0a5/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:4653 errors:0 dropped:0 overruns:0 frame:0

          TX packets:82 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:359096 (350.6 KiB)  TX bytes:16870 (16.4 KiB)

          Interrupt:19 Base address:0x2000

 

eth0:cl   Link encap:Ethernet  HWaddr 00:0c:29:06:d0:a5

          inet addr:159.180.232.243  Bcast:0.0.0.0  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          Interrupt:19 Base address:0x2000

 

But when node 1 goes down, eth0:cl appears on node 2 and ifconfig on that node looks like this:

 

eth0      Link encap:Ethernet  HWaddr 00:0c:29:8e:91:fa

          inet addr:159.180.232.242  Bcast:159.180.232.255  Mask:255.255.255.0

          inet6 addr: fe80::20c:29ff:fe8e:91fa/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:17913 errors:0 dropped:0 overruns:0 frame:0

          TX packets:610 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:1585419 (1.5 MiB)  TX bytes:56683 (55.3 KiB)

          Interrupt:19 Base address:0x2000

 

eth0:cl   Link encap:Ethernet  HWaddr 00:0c:29:8e:91:fa

          inet addr:159.180.232.243  Bcast:0.0.0.0  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          Interrupt:19 Base address:0x2000

 

The MAC address of eth1:cl is a clone of the base eth0 address on whatever node is active. On our network, which has long ARP timeouts, this means that clients will not respond to the secondary host until the timeout period has expired (which can be over an hour). I would have thought that the virtual IP should have a virtual MAC address which floats between the two hosts (like VRRP and HSRP), but I don’t know enough about CARP to know if it works in this way too.

 

Can you tell me if ZEN is behaving correctly in this case or do I have another VMWare issue to solve?

 

Thanks again.

 

David

 

 

 

 

 

From: Emilio Campos [mailto:emilio.campos.martin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 12 October 2011 23:02


To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Thanks to you David, your problems has been used for detected some bug with the cluster configuration and RSA communications. ;)

Welcomed!

2011/10/12 David Martin (IT) <dmartin-ANfHjr1BzNdHPrDE71CqTQ@public.gmane.orguk>

Success!

 

It is a VMWare issue. By default, our vSwitch security policy disables Promiscuous Mode, Mac Address Changes and Forged Transmits. Since CARP uses these features to establish the virtual mac and virtual IP addresses, it didn’t work. VMWare player does not have these security features and works fine.

 

By enabling these settings on the VMware port group for the VLAN that is in use, the virtual NIC can access the required functionality to support CARP (and VRRP, HSRP and similar).

 

I also found this document which describes another potential issue with CARP. It might be useful for others:

http://roggyblog.blogspot.com/2010/05/using-hsrpcarp-and-vrrp-within-vmware.html

 

Sorry to be such a pain over the last few days, I’ll keep the volume of email down now, honest!

 

On the plus side, I’m putting together some documentation on how to build for VMware and, if you want, I’d be happy to share it. I know Nick Furnell is working on an appliance that will take some of the nasty bits away (VMXnet drivers and the like) but I think there will still be some little tweaks that need to be made on the vCenter/ESX side.

 

Anyway, thanks again for the welcome and the support.

 

Regards

 

David

 

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 11 October 2011 23:06


To: zenloadbalancer-support-5NWGOfrQmnfLDRD5uJR0wg@public.gmane.orgeforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

I should be able to do those tests in the morning.

 

I used ssh-copy-id to push the public keys onto opposite nodes, ssh login without password was working fine when I checked last.

 

Regards

 

David

Sent from my iPhone


On 11 Oct 2011, at 22:59, "Emilio Campos" <emilio.campos.martin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

Hi David, I just configured my environment similar to your and I can't reproduce the error, for me all is working fine, I need more information:

please eject this commands on both nodes and send me the output:

on node1:

ps -ef| grep ucarp
ifconfig -a
ps -ef | grep inotify
ip addr list

on node2:

ps -ef | grep ucarp
ifconfig -a
ps -ef| grep inotify
ip addr list


from node1 try to connect to node2 via ssh
node1# ssh root <at> ip_node2
and from node try to connect to node1 via ssh
node2# ssh root <at> ip_node1
try before the configuration cluster, this should work writing the root password, confirm this please
try ffter the configuration cluster, this should work without write the root password, confirm this please


Access to web gui,and after RSA configuration try to test the connection clicking "Test RSA connections" buttom on both nodes please.


Also I checked the logs that you send me ,and all is fine, only errors about RSA connection, that on the end of file don't appear

Please run the test and attach to this lines the output.

The name hope it's not the cause, but if it should be the cause we could modify the sourcecode to accept these naming, no problem.

Thanks!

We are waiting your feedback

2011/10/11 David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org>

I will try in the morning. I think in my VMWare player environment I just used node1 and node2 as names. I have to be a bit more careful to use our naming conventions in the vSphere system so I used the full names.

 

If this is the cause, then is it something that can be accommodated or do I need to 'bend' my naming rules?

 

David

Sent from my iPhone


On 11 Oct 2011, at 20:50, "Emilio Campos" <emilio.campos.martin <at> gmail.com> wrote:

Hi David, I think I detected the problem, at the moment try to configure the other cluster type "node1 or node2 can be masters" and tell us!

I tell you the possible error:
On the cluster type, with failback on the file that configure the cluster /usr/local/zenloadbalancer/config/cluster.conf there is a line with this:


I am working on development environment and I suspect where is the bug!

TYPECLUSTER:GRP-ZEN-01s-GRP-ZEN-02s:UP

I defined the separator "-" to know the hostname for node master and the hostname for node backup, on this case with the hostname that you configured with "-" character the process can't  identify the two nodes.


Can you try the other cluster type and tell us if the configuration process work like a charm? :P


we hope your feedback!

2011/10/11 David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org>

Interesting, the same build in the vSphere 5 environment is not working.

 

I will do some more digging.

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 11 October 2011 17:04


To: zenloadbalancer-support-5NWGOfrQmnfLDRD5uJR0wg@public.gmane.orgeforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Active on bothnodesatthesametime

 

I have just built a completely new pair of servers on VMWare Player, using a single NIC and the patch that you supplied. They seem to be working fine.

 

Next I will repeat the procedure on the vSphere 5 production environment, completely building each node from scratch and applying the RC5 update and the patch you gave me. I might take a snapshot inbetween RC5 and the patch and see if there is any difference.

 

Thanks for your continued patience.

 

David

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 11 October 2011 16:37
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodesatthesametime

 

Here are the config and logs.

 

Note that on zen-02, it was complaining about rsync ssh failures. I swapped public keys on the two nodes and that seems to have gone away (see further down zeninotify.log).

 

Nick, thanks for that. I didn’t really suspect VMWare as there is no multicast or other unusual ‘traffic’ going on. In the latest attempt I ditched the extra NIC (which was provisioned though VMWare) and am just using eth0 with the same result.

 

I’m convincing myself I’ve made a daft error or am labouring under a false assumption. If someone could confirm that my clustering method is correct, that would be useful.

 

Regards


David

 

From: Emilio Campos [mailto:emilio.campos.martin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 11 October 2011 15:26
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodesatthesame time

 

David please, can you send us a tar.gz file from both nodes, with content of /usr/local/zenloadbalancer/config and /usr/local/zenloadbalancer/logs

I would like study why not on your environtment it's not working fine!

by other hand, can you try to configure all only with one eth? disable eth1 on both nodes and try again!

Tanks!

2011/10/11 David Martin (IT) <dmartin <at> jpress.co.uk>

Still not working (assuming the procedure I gave was correct):

 

Zen latency is UP on GRP-ZEN-01s 10.200.28.173 | Zen latency is UP on GRP-ZEN-02s 10.200.28.174 <image001.png>
Cluster IP 10.200.28.175 is active on GRP-ZEN-01s Cluster is active on GRP-ZEN-02s 
<image002.png>
Zen Inotify is running on GRP-ZEN-01s GRP-ZEN-02s 
<image002.png>


Global status: <image002.png>

 

<image003.jpg>

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 11 October 2011 14:51


To: zenloadbalancer-support-5NWGOfrQmnfLDRD5uJR0wg@public.gmane.orgeforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodes atthesame time

 

Hmm, not so fast. I think I deleted a vmware snapshot that contained the patched version by accident. Give me five minutes.

 

Sorry.

 

David

 

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 11 October 2011 14:46
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodes at thesame time

 

Emilio,

 

I have applied on both nodes.

 

Because I have done quite a bit of messing about, I’m tempted to start again. It should only take half an hour or so.

 

Before I do, can you confirm that the following procedure is ok please?

 

On Node1

1. Configure real IP address of eth1 = 10.200.28.173

 

On Node2

2. Configure real IP address of eth1 = 10.200.28.174

 

On Node1

3. Create virtual interface called eth1:cl = 10.200.28.175

4. Select eth1:cl as the virtual IP for a new Cluster and press "Save VIP"

5. Enter Node2's name and eth1 IP address in the "Remote" section and press "Save"

6. Type password in box and press "Configure RSA connection"

7. Select the first option from the cluster type menu "Node1 master and Node2 backup automatic failback"

8. Select "Configure Cluster Type"

 

The only other thing I can think of is that eth0 and eth1 are on the same subnet. Could this be causing confusion?

 

Regards

 

David

 

From: Emilio Campos [mailto:emilio.campos.martin <at> gmail.com]
Sent: 11 October 2011 13:43
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodes at the same time

 

David, please confirm me.

 applied the patch on both zen servers ?

Did you deleted the cluster interface on both nodes? and repeated the process from begining?

 Remember:  You don't need connect to both node members for configure the cluster, the secondary node will be configured automaticaly.

I'm waiting your feedback

Regards!

Hmm, looks a bit different but still not right:

 

Node 1:

 

Zen latency is UP on GRP-ZEN-01s 10.200.28.173 | Zen latency is DOWN on GRP-ZEN-02s 10.200.28.174 <image002.png>
Cluster IP 10.200.28.175 is active on GRP-ZEN-01s Host key verification failed. 
<image001.png>
Zen Inotify is running on GRP-ZEN-01s Host key verification failed. 
<image001.png>
Global status: <image002.png>

 

Node 2:

 

Zen latency is UP on GRP-ZEN-02s 10.200.28.174 | Zen latency is DOWN on GRP-ZEN-01s 10.200.28.173 <image002.png>
Cluster IP 10.200.28.175 is active on GRP-ZEN-02s Host key verification failed. 
<image001.png>
Zen Inotify is running on GRP-ZEN-02s Host key verification failed
<image001.png>.
Global status: <image002.png>

 

David

 

From: Emilio Campos [mailto:emilio.campos.martin <at> gmail.com]
Sent: 10 October 2011 22:28
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodes at the same time

 

David, I just developed the patch that fix the problem reported by you, could you help us with your test and send us your feedback?

Please write my file attached on /usr/local/zenloadbalancer/www/, rewriting the actual file
Disable the cluster configuration, delete the eth0:cl interface on both nodes and repeat the proccess from the begining.


We would like to know if with this change all is working fine

We are waiting your feedback!

Thanks and regards

2011/10/10 Emilio Campos <emilio.campos.martin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

HI David, I just detected a problem on cluster configuration, from node backup to node master


We going to solve for v1 stable


Thanks about your reports!

Hi,

 

I’m new to Zen and was hoping to get some advice. I have configured two boxes, grp-zen-01s and grp-zen-02s, and am struggling to get clustering to work.

 

I get no errors when configuring the cluster, but when I am finished I get the following status:

 

 

 

Zen latency is UP on GRP-ZEN-02s 10.200.28.174 | Zen latency is UP on GRP-ZEN-01s 10.200.28.173 <image001.png>
Cluster IP 10.200.28.175 is active on GRP-ZEN-02s Cluster is active on GRP-ZEN-01s 
<image002.png>
Zen Inotify is running on GRP-ZEN-02s GRP-ZEN-01s 
<image002.png>
Global status: <image002.png>

 

 

 

From what I can see, the VIP and Inotify should only be active on one node. I’m guessing the Passive node is having difficulty seeing the active node so it is ‘going active’ too.

 

The only ‘unusual’ bit of my setup is that both nodes are running on VMWare vSphere 5 hosts (the same host for testing, actually). I’m wondering if that could be part of the issue but I can’t see how.

 

I built one node (but no cluster or farm config) and then cloned it to get the second. I think I have caught all the IDs that I need to change (IP address, hostname, mac address, etc) but, in case I have missed something, I am going to build another node from scratch tomorrow and see if that makes a difference. Is there anything else that uniquely identifies a Zen node?

 

Thanks in advance.

 

Regards

 

David

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS  Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed. This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error.Please delete it or return it to the sender or notify us by email at postmaster <at> jpress.co.uk 

 

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmncRDUWM+popnw@public.gmane.orgforge.net

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org  Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org 
Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS  Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s). If you are not the intended recipient, you have received this e-mail in error.Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org  


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org  Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org 
Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS  Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s). If you are not the intended recipient, you have received this e-mail in error.Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org  


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmncRDUWM+popnw@public.gmane.orgforge.net

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct

Johnston Press plc  Registered in Scotland no. SC015382 Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed. This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error.Please delete it or return it to the sender or notify us by email at postmaster <at> jpress.co.uk 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct

Johnston Press plc  Registered in Scotland no. SC015382 Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed. This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error.Please delete it or return it to the sender or notify us by email at postmaster <at> jpress.co.uk 
Johnston Press plc  Registered in Scotland no. SC015382 Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed. This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error.Please delete it or return it to the sender or notify us by email at postmaster <at> jpress.co.uk 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org  Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org 
Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org 
Johnston Press plc Registered in Scotland no. SC015382 Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed. This e-mail and any files with it are solely for the use of the addressee(s). If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email at postmaster <at> jpress.co.uk

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
David Martin (IT | 17 Oct 09:39 2011
Picon

Re: Cluster Activeonbothnodesatthesametime

Will give it a go. Is this any use:

 

http://www.cyberciti.biz/faq/linux-networking-sending-gratuitous-arps/

 

 

 

From: laura Garcia [mailto:nevola-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 14 October 2011 16:58
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Ok, it's the behaviour I though.

Meanwhile we find a way to force the ARP replication, you could use the cluster interface (eth0:cl) to start the farm service as workaround.

Regards,
Laura.

On Fri, Oct 14, 2011 at 3:26 PM, David Martin (IT) <dmartin <at> jpress.co.uk> wrote:

Interesting.

 

First with 10.200.28.175, which is the eth0:cl interface:

 

root <at> zen2:~# tcpdump -i eth0 arp src host 10.200.28.175

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

14:19:33.345966 ARP, Request who-has 10.200.28.175 (00:50:56:02:81:72 (oui Unknown)) tell 10.200.28.175, length 28

14:19:34.346096 ARP, Request who-has 10.200.28.175 (00:50:56:02:81:72 (oui Unknown)) tell 10.200.28.175, length 28

 

And now with 10.200.28.173, which is the eth0:vip0 interface:

 

root <at> zen2:~# tcpdump -i eth0 arp src host 10.200.28.173

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

^C

0 packets captured

1 packets received by filter

0 packets dropped by kernel

 

No ARP packets for the vip01 interface. I’m going to move the 10.200.28.173 VIP onto eth1 and see if that produces a different result. I can’t see why it would though.

 

Regards

 

David

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 14 October 2011 13:34
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5ug@public.gmane.orge.net
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

I will try it now.

 

Thanks

 

David

 

From: laura Garcia [mailto:nevola-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 14 October 2011 11:56
To: zenloadbalancer-support-5NWGOfrQmnd4wTydcyPnfg@public.gmane.orgceforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

In my testing, when a new ip address has been added to a network interface, the system sends ARP packets with the new state.
Could you run this command on the node 2 and try the failover again?

> tcpdump -i eth0 arp src host 10.200.28.173

The output should show the change of the MAC address when the failover is in process.

Regards,
Laura.

On Fri, Oct 14, 2011 at 11:18 AM, David Martin (IT) <dmartin <at> jpress.co.uk> wrote:

In my tests you can do it without downing the interface but I think it will still confuse UCARP.

 

On the ARP front, I’ve just done a preliminary test on the switches by debugging ARP traffic. I’ve cut the logs down quite a bit (each of these switches has at least 8 10Gig ports and they are pretty busy).

 

Oct 14 09:53:28.205 UTC: IP ARP: rcvd req src 10.200.28.172 0050.5602.8172, dst 10.200.28.254 Vlan28

Oct 14 09:53:28.205 UTC: IP ARP: sent rep src 10.200.28.254 0000.0c07.ac01, dst 10.200.28.172 0050.5602.8172 Vlan28

Oct 14 09:53:39.797 UTC: IP ARP: rcvd req src 10.200.28.171 0050.5602.8171, dst 10.200.28.254 Vlan28

Oct 14 09:53:39.797 UTC: IP ARP: sent rep src 10.200.28.254 0000.0c07.ac01, dst 10.200.28.171 0050.5602.8171 Vlan28

Oct 14 09:53:50.145 UTC: IP ARP: rcvd req src 10.200.28.175 0050.5602.8172, dst 10.200.28.175 Vlan28

Oct 14 09:53:50.145 UTC: IP ARP: rcvd req src 10.200.28.175 0050.5602.8172, dst 10.200.28.175 Vlan28

Oct 14 09:53:51.145 UTC: IP ARP: rcvd req src 10.200.28.175 0050.5602.8172, dst 10.200.28.175 Vlan28

Oct 14 09:53:51.145 UTC: IP ARP: rcvd req src 10.200.28.175 0050.5602.8172, dst 10.200.28.175 Vlan28

Oct 14 09:54:14.953 UTC: IP ARP: rcvd req src 10.200.28.172 0050.5602.8172, dst 10.200.28.171 Vlan28

Oct 14 09:54:14.953 UTC: IP ARP: rcvd req src 10.200.28.172 0050.5602.8172, dst 10.200.28.171 Vlan28

Oct 14 09:54:15.953 UTC: IP ARP: rcvd req src 10.200.28.172 0050.5602.8172, dst 10.200.28.171 Vlan28

Oct 14 09:54:15.953 UTC: IP ARP: rcvd req src 10.200.28.172 0050.5602.8172, dst 10.200.28.171 Vlan28

 

This is taken just as I pull the network card on node 1 (10.200.28.171). the eth0:cl address is 10.200.28.175 and the eth0:vip01 address (my test farm) is 10.200.28.173.  Interestingly, the :cl interface ARP gets updated but the 10.200.28.173 does not.

 

I have tried ping tests on the :cl interface and that does failover correctly….. it’s just the farms that don’t work

 

David

 

From: laura Garcia [mailto:nevola-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 14 October 2011 08:24
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Definitely, it's not possible to change the MAC address. To change the MAC address we've to do a down of the physical interface, change the MAC, and then, up the interface again. Meanwhile this process is done, the CARP diagnoses a problem with the network interface (that it has been down) and then, try to failover again.

CARP doesn't wait for the timeout of ARP tables, like you said, it sends gratuitous ARP packets that would be enough to update the ARP tables on the switches. Did you have analyzed the traffic between vmware servers?

Regards,
Laura.

On Thu, Oct 13, 2011 at 5:26 PM, David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org> wrote:

You are right, sorry. It looks like it is quite involved to get more than one mac on a card. There are some linux TAP/TUN drivers that can do it but it looks pretty complex.

 

From: laura Garcia [mailto:nevola <at> gmail.com]
Sent: 13 October 2011 16:07
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

You're right, but I've been doing some testing and the system doesn't allow to change a MAC address of a virtual interface. You've to change the physical parent MAC to get it works.

On Thu, Oct 13, 2011 at 4:59 PM, David Martin (IT) <dmartin <at> jpress.co.uk> wrote:

Emilio,

 

I’d love to help with any testing you want.

 

In the meantime, I’ve been looking through the ucarp documentation and the zen source so I can get a better idea of how failover is working.

 

It looks from the documentation like ucarp should be sending a Gratuitous ARP when the failover occurs so that the router can update the arp table. I’m going to have a play with wireshark later today to see if I can capture and examine this packet. If that is not working with VMware for some reason, then that might be why my failover times are so long.

 

On the mac address front, I think it should be relatively easy to change the MAC address of the vip as it comes up. In the  zenlatancy-start script you could do something like the following to change the mac address of the VIP:

 

# You already do this bit to ‘up’ the interface

ip addr add 10.200.28.174\/255.255.255.0 dev eth0\:test label eth0\:test

#This tells the kernel to reset the link address

ip link set eth0\:test address 00:11:22:33:44:55

 

You would need to have a place on the interface to edit the virtual mac address (and a way of setting it to default if someone changed it automatically), and you would have to change the interface definition file but otherwise I think everything else should just work.

 

Please don’t think I’m telling you how to develop or what direction to take Zen. It’s a great product and I’m just enthusiastic.

 

Cheers

 

David

 

 

From: Emilio Campos [mailto:emilio.campos.martin <at> gmail.com]
Sent: 13 October 2011 14:51
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Hi David, at this moment UCARP can't share the mac address but we could study for add this new property

We have to study the time for develope this, maybe a process that generate an automatic mac could be interesting, or one process for introduce your own personalized mac.

We could add this but not on stable version, only release candidate, if you are interested on this, you could help us with the test

At the moment we can send you a work around for test this on your environment.

And you feel free for do donations :P

Regards

2011/10/13 David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org>

Laura,

 

This has not made any difference, sorry. I have done a bit more digging and given the issue a lot of thought and I think the following (very long, sorry) describes what is going on, at least in my environment.

 

When testing this using a local zen cluster (i.e. on the same subnet) the failover happens fairly quickly, within about 30 seconds.

 

When the cluster is on a remote subnet, the failover takes anything up to an hour.

 

The reason behind this, as far as I can see, it that Windows 7 has a very short ARP timeout (randomly selected between 15-45 seconds). The ARP entry that was mapping say:

MAC Address 00:0c:29:06:d0:a5 to    IP address   159.180.232.243

In my previous example will quickly time out and be replaced by

MAC Address 00:0c:29:8e:91:fa to    IP address   159.180.232.243

as the second node takes over.

 

When the cluster is remote, you are relying on the ARP table in the last router in the chain. By default, Cisco use and recommend an ARP timeout of four hours. This can be changed, but at the expense of increased ARP traffic, CPU load and in some cases latency. To better suit our VMWare environment, we have reduced this timeout to just one hour which we found to be a good compromise.

 

To get around this very long timeout, protocols like HSRP, GLBP, VRRP and CARP create a virtual mac address that both nodes share. When a node dies the network interface goes down and the switch immediately flushes its CAM table, meaning that the mac address almost instantly is available on the second node.

 

I suspect that by introducing the concept of a virtual mac address to Zen, this fast switchover can be achieved.

 

On the other hand, I could be doing something very wrong and, if so, please point it out! I’d be especially grateful if any other users could share their experience of Zen on a non-local subnet and what ARP timeouts are in use on the Zen VLAN.

 

Thanks for your patience once again, I definitely feel a donation will be in order soon!

 

David

 

 

 

From: laura Garcia [mailto:nevola-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 13 October 2011 13:37


To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

David, could you try to execute the following commands under the 2 ZLB nodes?

echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 0 > /proc/sys/net/ipv4/conf/all/arp_announce

Then, try failback again.

Thanks.

On Thu, Oct 13, 2011 at 1:44 PM, David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org> wrote:

Thanks, I realise I’m being a pain but I’m really keen to get this into production!

 

From: laura Garcia [mailto:nevola <at> gmail.com]
Sent: 13 October 2011 12:38


To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Actually, you can't modify a MAC address through the zen GUI.
Let me see what can I do to support it.

About how Zen integrates CARP, maybe Emilio could give us more details.

Regards,
Laura.

On Thu, Oct 13, 2011 at 1:06 PM, David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org> wrote:

Is there anywhere in the Zen interface definition file I can specify a mac address for the :cl interface? I can’t see a way forward without it without building a new VLAN just for Zen.

 

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 13 October 2011 11:04


To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Sorry for replying to myself again. This page suggests that CARP should be using a virtual MAC address:

 

http://www.countersiege.com/doc/pfsync-carp/

 

David

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 13 October 2011 10:48
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

So by design Zen/CARP won’t failover until the ARP timeout has expired? That might be a bit of a showstopper for us, the default value for that is 4 hours on Cisco devices. We run at one hour but can’t really go lower on our production networks.

 

David

 

From: laura Garcia [mailto:nevola-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 13 October 2011 10:41
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

It's correct. For linux, every virtual or vlan interface uses the MAC of its physical network interface.
There is several ways to force to change a MAC, but the network driver has to support it.

Cheers,
Laura.

On Thu, Oct 13, 2011 at 10:32 AM, David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org> wrote:

I may have spoken too soon. Can you confirm something about the architecture please?

 

When both nodes are up eth0:cl only exists on node1, and ifconfig on node1 looks something like this:

 

eth0      Link encap:Ethernet  HWaddr 00:0c:29:06:d0:a5

          inet addr:159.180.232.241  Bcast:159.180.232.255  Mask:255.255.255.0

          inet6 addr: fe80::20c:29ff:fe06:d0a5/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:4653 errors:0 dropped:0 overruns:0 frame:0

          TX packets:82 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:359096 (350.6 KiB)  TX bytes:16870 (16.4 KiB)

          Interrupt:19 Base address:0x2000

 

eth0:cl   Link encap:Ethernet  HWaddr 00:0c:29:06:d0:a5

          inet addr:159.180.232.243  Bcast:0.0.0.0  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          Interrupt:19 Base address:0x2000

 

But when node 1 goes down, eth0:cl appears on node 2 and ifconfig on that node looks like this:

 

eth0      Link encap:Ethernet  HWaddr 00:0c:29:8e:91:fa

          inet addr:159.180.232.242  Bcast:159.180.232.255  Mask:255.255.255.0

          inet6 addr: fe80::20c:29ff:fe8e:91fa/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:17913 errors:0 dropped:0 overruns:0 frame:0

          TX packets:610 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:1585419 (1.5 MiB)  TX bytes:56683 (55.3 KiB)

          Interrupt:19 Base address:0x2000

 

eth0:cl   Link encap:Ethernet  HWaddr 00:0c:29:8e:91:fa

          inet addr:159.180.232.243  Bcast:0.0.0.0  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          Interrupt:19 Base address:0x2000

 

The MAC address of eth1:cl is a clone of the base eth0 address on whatever node is active. On our network, which has long ARP timeouts, this means that clients will not respond to the secondary host until the timeout period has expired (which can be over an hour). I would have thought that the virtual IP should have a virtual MAC address which floats between the two hosts (like VRRP and HSRP), but I don’t know enough about CARP to know if it works in this way too.

 

Can you tell me if ZEN is behaving correctly in this case or do I have another VMWare issue to solve?

 

Thanks again.

 

David

 

 

 

 

 

From: Emilio Campos [mailto:emilio.campos.martin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 12 October 2011 23:02


To: zenloadbalancer-support-5NWGOfrQmncRDUWM+popnw@public.gmane.orgforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Thanks to you David, your problems has been used for detected some bug with the cluster configuration and RSA communications. ;)

Welcomed!

2011/10/12 David Martin (IT) <dmartin <at> jpress.co.uk>

Success!

 

It is a VMWare issue. By default, our vSwitch security policy disables Promiscuous Mode, Mac Address Changes and Forged Transmits. Since CARP uses these features to establish the virtual mac and virtual IP addresses, it didn’t work. VMWare player does not have these security features and works fine.

 

By enabling these settings on the VMware port group for the VLAN that is in use, the virtual NIC can access the required functionality to support CARP (and VRRP, HSRP and similar).

 

I also found this document which describes another potential issue with CARP. It might be useful for others:

http://roggyblog.blogspot.com/2010/05/using-hsrpcarp-and-vrrp-within-vmware.html

 

Sorry to be such a pain over the last few days, I’ll keep the volume of email down now, honest!

 

On the plus side, I’m putting together some documentation on how to build for VMware and, if you want, I’d be happy to share it. I know Nick Furnell is working on an appliance that will take some of the nasty bits away (VMXnet drivers and the like) but I think there will still be some little tweaks that need to be made on the vCenter/ESX side.

 

Anyway, thanks again for the welcome and the support.

 

Regards

 

David

 

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 11 October 2011 23:06


To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

I should be able to do those tests in the morning.

 

I used ssh-copy-id to push the public keys onto opposite nodes, ssh login without password was working fine when I checked last.

 

Regards

 

David

Sent from my iPhone


On 11 Oct 2011, at 22:59, "Emilio Campos" <emilio.campos.martin <at> gmail.com> wrote:

Hi David, I just configured my environment similar to your and I can't reproduce the error, for me all is working fine, I need more information:

please eject this commands on both nodes and send me the output:

on node1:

ps -ef| grep ucarp
ifconfig -a
ps -ef | grep inotify
ip addr list

on node2:

ps -ef | grep ucarp
ifconfig -a
ps -ef| grep inotify
ip addr list


from node1 try to connect to node2 via ssh
node1# ssh root <at> ip_node2
and from node try to connect to node1 via ssh
node2# ssh root <at> ip_node1
try before the configuration cluster, this should work writing the root password, confirm this please
try ffter the configuration cluster, this should work without write the root password, confirm this please


Access to web gui,and after RSA configuration try to test the connection clicking "Test RSA connections" buttom on both nodes please.


Also I checked the logs that you send me ,and all is fine, only errors about RSA connection, that on the end of file don't appear

Please run the test and attach to this lines the output.

The name hope it's not the cause, but if it should be the cause we could modify the sourcecode to accept these naming, no problem.

Thanks!

We are waiting your feedback

2011/10/11 David Martin (IT) <dmartin <at> jpress.co.uk>

I will try in the morning. I think in my VMWare player environment I just used node1 and node2 as names. I have to be a bit more careful to use our naming conventions in the vSphere system so I used the full names.

 

If this is the cause, then is it something that can be accommodated or do I need to 'bend' my naming rules?

 

David

Sent from my iPhone


On 11 Oct 2011, at 20:50, "Emilio Campos" <emilio.campos.martin <at> gmail.com> wrote:

Hi David, I think I detected the problem, at the moment try to configure the other cluster type "node1 or node2 can be masters" and tell us!

I tell you the possible error:
On the cluster type, with failback on the file that configure the cluster /usr/local/zenloadbalancer/config/cluster.conf there is a line with this:


I am working on development environment and I suspect where is the bug!

TYPECLUSTER:GRP-ZEN-01s-GRP-ZEN-02s:UP

I defined the separator "-" to know the hostname for node master and the hostname for node backup, on this case with the hostname that you configured with "-" character the process can't  identify the two nodes.


Can you try the other cluster type and tell us if the configuration process work like a charm? :P


we hope your feedback!

Interesting, the same build in the vSphere 5 environment is not working.

 

I will do some more digging.

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 11 October 2011 17:04


To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Active on bothnodesatthesametime

 

I have just built a completely new pair of servers on VMWare Player, using a single NIC and the patch that you supplied. They seem to be working fine.

 

Next I will repeat the procedure on the vSphere 5 production environment, completely building each node from scratch and applying the RC5 update and the patch you gave me. I might take a snapshot inbetween RC5 and the patch and see if there is any difference.

 

Thanks for your continued patience.

 

David

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 11 October 2011 16:37
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodesatthesametime

 

Here are the config and logs.

 

Note that on zen-02, it was complaining about rsync ssh failures. I swapped public keys on the two nodes and that seems to have gone away (see further down zeninotify.log).

 

Nick, thanks for that. I didn’t really suspect VMWare as there is no multicast or other unusual ‘traffic’ going on. In the latest attempt I ditched the extra NIC (which was provisioned though VMWare) and am just using eth0 with the same result.

 

I’m convincing myself I’ve made a daft error or am labouring under a false assumption. If someone could confirm that my clustering method is correct, that would be useful.

 

Regards


David

 

From: Emilio Campos [mailto:emilio.campos.martin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 11 October 2011 15:26
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodesatthesame time

 

David please, can you send us a tar.gz file from both nodes, with content of /usr/local/zenloadbalancer/config and /usr/local/zenloadbalancer/logs

I would like study why not on your environtment it's not working fine!

by other hand, can you try to configure all only with one eth? disable eth1 on both nodes and try again!

Tanks!

Still not working (assuming the procedure I gave was correct):

 

Zen latency is UP on GRP-ZEN-01s 10.200.28.173 | Zen latency is UP on GRP-ZEN-02s 10.200.28.174 <image001.png>
Cluster IP 10.200.28.175 is active on GRP-ZEN-01s Cluster is active on GRP-ZEN-02s 
<image002.png>
Zen Inotify is running on GRP-ZEN-01s GRP-ZEN-02s 
<image002.png>


Global status: <image002.png>

 

<image003.jpg>

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 11 October 2011 14:51


To: zenloadbalancer-support <at> lists.sourceforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodes atthesame time

 

Hmm, not so fast. I think I deleted a vmware snapshot that contained the patched version by accident. Give me five minutes.

 

Sorry.

 

David

 

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 11 October 2011 14:46
To: zenloadbalancer-support <at> lists.sourceforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodes at thesame time

 

Emilio,

 

I have applied on both nodes.

 

Because I have done quite a bit of messing about, I’m tempted to start again. It should only take half an hour or so.

 

Before I do, can you confirm that the following procedure is ok please?

 

On Node1

1. Configure real IP address of eth1 = 10.200.28.173

 

On Node2

2. Configure real IP address of eth1 = 10.200.28.174

 

On Node1

3. Create virtual interface called eth1:cl = 10.200.28.175

4. Select eth1:cl as the virtual IP for a new Cluster and press "Save VIP"

5. Enter Node2's name and eth1 IP address in the "Remote" section and press "Save"

6. Type password in box and press "Configure RSA connection"

7. Select the first option from the cluster type menu "Node1 master and Node2 backup automatic failback"

8. Select "Configure Cluster Type"

 

The only other thing I can think of is that eth0 and eth1 are on the same subnet. Could this be causing confusion?

 

Regards

 

David

 

From: Emilio Campos [mailto:emilio.campos.martin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 11 October 2011 13:43
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodes at the same time

 

David, please confirm me.

 applied the patch on both zen servers ?

Did you deleted the cluster interface on both nodes? and repeated the process from begining?

 Remember:  You don't need connect to both node members for configure the cluster, the secondary node will be configured automaticaly.

I'm waiting your feedback

Regards!

Hmm, looks a bit different but still not right:

 

Node 1:

 

Zen latency is UP on GRP-ZEN-01s 10.200.28.173 | Zen latency is DOWN on GRP-ZEN-02s 10.200.28.174 <image002.png>
Cluster IP 10.200.28.175 is active on GRP-ZEN-01s Host key verification failed. 
<image001.png>
Zen Inotify is running on GRP-ZEN-01s Host key verification failed. 
<image001.png>
Global status: <image002.png>

 

Node 2:

 

Zen latency is UP on GRP-ZEN-02s 10.200.28.174 | Zen latency is DOWN on GRP-ZEN-01s 10.200.28.173 <image002.png>
Cluster IP 10.200.28.175 is active on GRP-ZEN-02s Host key verification failed. 
<image001.png>
Zen Inotify is running on GRP-ZEN-02s Host key verification failed
<image001.png>.
Global status: <image002.png>

 

David

 

From: Emilio Campos [mailto:emilio.campos.martin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 10 October 2011 22:28
To: zenloadbalancer-support <at> lists.sourceforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodes at the same time

 

David, I just developed the patch that fix the problem reported by you, could you help us with your test and send us your feedback?

Please write my file attached on /usr/local/zenloadbalancer/www/, rewriting the actual file
Disable the cluster configuration, delete the eth0:cl interface on both nodes and repeat the proccess from the begining.


We would like to know if with this change all is working fine

We are waiting your feedback!

Thanks and regards

2011/10/10 Emilio Campos <emilio.campos.martin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

HI David, I just detected a problem on cluster configuration, from node backup to node master


We going to solve for v1 stable


Thanks about your reports!

Hi,

 

I’m new to Zen and was hoping to get some advice. I have configured two boxes, grp-zen-01s and grp-zen-02s, and am struggling to get clustering to work.

 

I get no errors when configuring the cluster, but when I am finished I get the following status:

 

 

 

Zen latency is UP on GRP-ZEN-02s 10.200.28.174 | Zen latency is UP on GRP-ZEN-01s 10.200.28.173 <image001.png>
Cluster IP 10.200.28.175 is active on GRP-ZEN-02s Cluster is active on GRP-ZEN-01s 
<image002.png>
Zen Inotify is running on GRP-ZEN-02s GRP-ZEN-01s 
<image002.png>
Global status: <image002.png>

 

 

 

From what I can see, the VIP and Inotify should only be active on one node. I’m guessing the Passive node is having difficulty seeing the active node so it is ‘going active’ too.

 

The only ‘unusual’ bit of my setup is that both nodes are running on VMWare vSphere 5 hosts (the same host for testing, actually). I’m wondering if that could be part of the issue but I can’t see how.

 

I built one node (but no cluster or farm config) and then cloned it to get the second. I think I have caught all the IDs that I need to change (IP address, hostname, mac address, etc) but, in case I have missed something, I am going to build another node from scratch tomorrow and see if that makes a difference. Is there anything else that uniquely identifies a Zen node?

 

Thanks in advance.

 

Regards

 

David

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 

 

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneHXe+LvDLADg@public.gmane.orgrceforge.net
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster <at> jpress.co.uk

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster <at> jpress.co.uk

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support <at> lists.sourceforge.net

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmndRYHbF4JBHZw@public.gmane.orgge.net
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support <at> lists.sourceforge.net

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster <at> jpress.co.uk

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support <at> lists.sourceforge.net

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster <at> jpress.co.uk

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmnegEbju0hdhLg@public.gmane.orgorge.net
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc Registered in Scotland no. SC015382 Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed. This e-mail and any files with it are solely for the use of the addressee(s). If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email at postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
laura Garcia | 17 Oct 17:23 2011
Picon

Re: Cluster Activeonbothnodesatthesametime

Well David, here you are the patch. Please, follow these steps on both nodes:

# > apt-get install iputils-arping
# > tar zxvf zen-GARP.tgz -C /

The global.cfg file will be overwritten so you should reconfigure the global default gw through the Zen GUI before the failover.

Try & feedback, please.

Regards,
Laura.

On Mon, Oct 17, 2011 at 9:39 AM, David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org> wrote:

Will give it a go. Is this any use:

 

http://www.cyberciti.biz/faq/linux-networking-sending-gratuitous-arps/

 

 

 

From: laura Garcia [mailto:nevola <at> gmail.com]
Sent: 14 October 2011 16:58
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Ok, it's the behaviour I though.

Meanwhile we find a way to force the ARP replication, you could use the cluster interface (eth0:cl) to start the farm service as workaround.

Regards,
Laura.

On Fri, Oct 14, 2011 at 3:26 PM, David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org> wrote:

Interesting.

 

First with 10.200.28.175, which is the eth0:cl interface:

 

root <at> zen2:~# tcpdump -i eth0 arp src host 10.200.28.175

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

14:19:33.345966 ARP, Request who-has 10.200.28.175 (00:50:56:02:81:72 (oui Unknown)) tell 10.200.28.175, length 28

14:19:34.346096 ARP, Request who-has 10.200.28.175 (00:50:56:02:81:72 (oui Unknown)) tell 10.200.28.175, length 28

 

And now with 10.200.28.173, which is the eth0:vip0 interface:

 

root <at> zen2:~# tcpdump -i eth0 arp src host 10.200.28.173

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

^C

0 packets captured

1 packets received by filter

0 packets dropped by kernel

 

No ARP packets for the vip01 interface. I’m going to move the 10.200.28.173 VIP onto eth1 and see if that produces a different result. I can’t see why it would though.

 

Regards

 

David

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 14 October 2011 13:34
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

I will try it now.

 

Thanks

 

David

 

From: laura Garcia [mailto:nevola-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 14 October 2011 11:56
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

In my testing, when a new ip address has been added to a network interface, the system sends ARP packets with the new state.
Could you run this command on the node 2 and try the failover again?

> tcpdump -i eth0 arp src host 10.200.28.173

The output should show the change of the MAC address when the failover is in process.

Regards,
Laura.

On Fri, Oct 14, 2011 at 11:18 AM, David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org> wrote:

In my tests you can do it without downing the interface but I think it will still confuse UCARP.

 

On the ARP front, I’ve just done a preliminary test on the switches by debugging ARP traffic. I’ve cut the logs down quite a bit (each of these switches has at least 8 10Gig ports and they are pretty busy).

 

Oct 14 09:53:28.205 UTC: IP ARP: rcvd req src 10.200.28.172 0050.5602.8172, dst 10.200.28.254 Vlan28

Oct 14 09:53:28.205 UTC: IP ARP: sent rep src 10.200.28.254 0000.0c07.ac01, dst 10.200.28.172 0050.5602.8172 Vlan28

Oct 14 09:53:39.797 UTC: IP ARP: rcvd req src 10.200.28.171 0050.5602.8171, dst 10.200.28.254 Vlan28

Oct 14 09:53:39.797 UTC: IP ARP: sent rep src 10.200.28.254 0000.0c07.ac01, dst 10.200.28.171 0050.5602.8171 Vlan28

Oct 14 09:53:50.145 UTC: IP ARP: rcvd req src 10.200.28.175 0050.5602.8172, dst 10.200.28.175 Vlan28

Oct 14 09:53:50.145 UTC: IP ARP: rcvd req src 10.200.28.175 0050.5602.8172, dst 10.200.28.175 Vlan28

Oct 14 09:53:51.145 UTC: IP ARP: rcvd req src 10.200.28.175 0050.5602.8172, dst 10.200.28.175 Vlan28

Oct 14 09:53:51.145 UTC: IP ARP: rcvd req src 10.200.28.175 0050.5602.8172, dst 10.200.28.175 Vlan28

Oct 14 09:54:14.953 UTC: IP ARP: rcvd req src 10.200.28.172 0050.5602.8172, dst 10.200.28.171 Vlan28

Oct 14 09:54:14.953 UTC: IP ARP: rcvd req src 10.200.28.172 0050.5602.8172, dst 10.200.28.171 Vlan28

Oct 14 09:54:15.953 UTC: IP ARP: rcvd req src 10.200.28.172 0050.5602.8172, dst 10.200.28.171 Vlan28

Oct 14 09:54:15.953 UTC: IP ARP: rcvd req src 10.200.28.172 0050.5602.8172, dst 10.200.28.171 Vlan28

 

This is taken just as I pull the network card on node 1 (10.200.28.171). the eth0:cl address is 10.200.28.175 and the eth0:vip01 address (my test farm) is 10.200.28.173.  Interestingly, the :cl interface ARP gets updated but the 10.200.28.173 does not.

 

I have tried ping tests on the :cl interface and that does failover correctly….. it’s just the farms that don’t work

 

David

 

From: laura Garcia [mailto:nevola-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 14 October 2011 08:24
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Definitely, it's not possible to change the MAC address. To change the MAC address we've to do a down of the physical interface, change the MAC, and then, up the interface again. Meanwhile this process is done, the CARP diagnoses a problem with the network interface (that it has been down) and then, try to failover again.

CARP doesn't wait for the timeout of ARP tables, like you said, it sends gratuitous ARP packets that would be enough to update the ARP tables on the switches. Did you have analyzed the traffic between vmware servers?

Regards,
Laura.

On Thu, Oct 13, 2011 at 5:26 PM, David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org> wrote:

You are right, sorry. It looks like it is quite involved to get more than one mac on a card. There are some linux TAP/TUN drivers that can do it but it looks pretty complex.

 

From: laura Garcia [mailto:nevola-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 13 October 2011 16:07
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

You're right, but I've been doing some testing and the system doesn't allow to change a MAC address of a virtual interface. You've to change the physical parent MAC to get it works.

On Thu, Oct 13, 2011 at 4:59 PM, David Martin (IT) <dmartin <at> jpress.co.uk> wrote:

Emilio,

 

I’d love to help with any testing you want.

 

In the meantime, I’ve been looking through the ucarp documentation and the zen source so I can get a better idea of how failover is working.

 

It looks from the documentation like ucarp should be sending a Gratuitous ARP when the failover occurs so that the router can update the arp table. I’m going to have a play with wireshark later today to see if I can capture and examine this packet. If that is not working with VMware for some reason, then that might be why my failover times are so long.

 

On the mac address front, I think it should be relatively easy to change the MAC address of the vip as it comes up. In the  zenlatancy-start script you could do something like the following to change the mac address of the VIP:

 

# You already do this bit to ‘up’ the interface

ip addr add 10.200.28.174\/255.255.255.0 dev eth0\:test label eth0\:test

#This tells the kernel to reset the link address

ip link set eth0\:test address 00:11:22:33:44:55

 

You would need to have a place on the interface to edit the virtual mac address (and a way of setting it to default if someone changed it automatically), and you would have to change the interface definition file but otherwise I think everything else should just work.

 

Please don’t think I’m telling you how to develop or what direction to take Zen. It’s a great product and I’m just enthusiastic.

 

Cheers

 

David

 

 

From: Emilio Campos [mailto:emilio.campos.martin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 13 October 2011 14:51
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Hi David, at this moment UCARP can't share the mac address but we could study for add this new property

We have to study the time for develope this, maybe a process that generate an automatic mac could be interesting, or one process for introduce your own personalized mac.

We could add this but not on stable version, only release candidate, if you are interested on this, you could help us with the test

At the moment we can send you a work around for test this on your environment.

And you feel free for do donations :P

Regards

2011/10/13 David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org>

Laura,

 

This has not made any difference, sorry. I have done a bit more digging and given the issue a lot of thought and I think the following (very long, sorry) describes what is going on, at least in my environment.

 

When testing this using a local zen cluster (i.e. on the same subnet) the failover happens fairly quickly, within about 30 seconds.

 

When the cluster is on a remote subnet, the failover takes anything up to an hour.

 

The reason behind this, as far as I can see, it that Windows 7 has a very short ARP timeout (randomly selected between 15-45 seconds). The ARP entry that was mapping say:

MAC Address 00:0c:29:06:d0:a5 to    IP address   159.180.232.243

In my previous example will quickly time out and be replaced by

MAC Address 00:0c:29:8e:91:fa to    IP address   159.180.232.243

as the second node takes over.

 

When the cluster is remote, you are relying on the ARP table in the last router in the chain. By default, Cisco use and recommend an ARP timeout of four hours. This can be changed, but at the expense of increased ARP traffic, CPU load and in some cases latency. To better suit our VMWare environment, we have reduced this timeout to just one hour which we found to be a good compromise.

 

To get around this very long timeout, protocols like HSRP, GLBP, VRRP and CARP create a virtual mac address that both nodes share. When a node dies the network interface goes down and the switch immediately flushes its CAM table, meaning that the mac address almost instantly is available on the second node.

 

I suspect that by introducing the concept of a virtual mac address to Zen, this fast switchover can be achieved.

 

On the other hand, I could be doing something very wrong and, if so, please point it out! I’d be especially grateful if any other users could share their experience of Zen on a non-local subnet and what ARP timeouts are in use on the Zen VLAN.

 

Thanks for your patience once again, I definitely feel a donation will be in order soon!

 

David

 

 

 

From: laura Garcia [mailto:nevola <at> gmail.com]
Sent: 13 October 2011 13:37


To: zenloadbalancer-support-5NWGOfrQmnfLDRD5uJR0wg@public.gmane.orgeforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

David, could you try to execute the following commands under the 2 ZLB nodes?

echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 0 > /proc/sys/net/ipv4/conf/all/arp_announce

Then, try failback again.

Thanks.

On Thu, Oct 13, 2011 at 1:44 PM, David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org> wrote:

Thanks, I realise I’m being a pain but I’m really keen to get this into production!

 

From: laura Garcia [mailto:nevola <at> gmail.com]
Sent: 13 October 2011 12:38


To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Actually, you can't modify a MAC address through the zen GUI.
Let me see what can I do to support it.

About how Zen integrates CARP, maybe Emilio could give us more details.

Regards,
Laura.

On Thu, Oct 13, 2011 at 1:06 PM, David Martin (IT) <dmartin <at> jpress.co.uk> wrote:

Is there anywhere in the Zen interface definition file I can specify a mac address for the :cl interface? I can’t see a way forward without it without building a new VLAN just for Zen.

 

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 13 October 2011 11:04


To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Sorry for replying to myself again. This page suggests that CARP should be using a virtual MAC address:

 

http://www.countersiege.com/doc/pfsync-carp/

 

David

 

From: David Martin (IT) [mailto:dmartin <at> jpress.co.uk]
Sent: 13 October 2011 10:48
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

So by design Zen/CARP won’t failover until the ARP timeout has expired? That might be a bit of a showstopper for us, the default value for that is 4 hours on Cisco devices. We run at one hour but can’t really go lower on our production networks.

 

David

 

From: laura Garcia [mailto:nevola-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 13 October 2011 10:41
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

It's correct. For linux, every virtual or vlan interface uses the MAC of its physical network interface.
There is several ways to force to change a MAC, but the network driver has to support it.

Cheers,
Laura.

On Thu, Oct 13, 2011 at 10:32 AM, David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org> wrote:

I may have spoken too soon. Can you confirm something about the architecture please?

 

When both nodes are up eth0:cl only exists on node1, and ifconfig on node1 looks something like this:

 

eth0      Link encap:Ethernet  HWaddr 00:0c:29:06:d0:a5

          inet addr:159.180.232.241  Bcast:159.180.232.255  Mask:255.255.255.0

          inet6 addr: fe80::20c:29ff:fe06:d0a5/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:4653 errors:0 dropped:0 overruns:0 frame:0

          TX packets:82 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:359096 (350.6 KiB)  TX bytes:16870 (16.4 KiB)

          Interrupt:19 Base address:0x2000

 

eth0:cl   Link encap:Ethernet  HWaddr 00:0c:29:06:d0:a5

          inet addr:159.180.232.243  Bcast:0.0.0.0  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          Interrupt:19 Base address:0x2000

 

But when node 1 goes down, eth0:cl appears on node 2 and ifconfig on that node looks like this:

 

eth0      Link encap:Ethernet  HWaddr 00:0c:29:8e:91:fa

          inet addr:159.180.232.242  Bcast:159.180.232.255  Mask:255.255.255.0

          inet6 addr: fe80::20c:29ff:fe8e:91fa/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:17913 errors:0 dropped:0 overruns:0 frame:0

          TX packets:610 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:1585419 (1.5 MiB)  TX bytes:56683 (55.3 KiB)

          Interrupt:19 Base address:0x2000

 

eth0:cl   Link encap:Ethernet  HWaddr 00:0c:29:8e:91:fa

          inet addr:159.180.232.243  Bcast:0.0.0.0  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          Interrupt:19 Base address:0x2000

 

The MAC address of eth1:cl is a clone of the base eth0 address on whatever node is active. On our network, which has long ARP timeouts, this means that clients will not respond to the secondary host until the timeout period has expired (which can be over an hour). I would have thought that the virtual IP should have a virtual MAC address which floats between the two hosts (like VRRP and HSRP), but I don’t know enough about CARP to know if it works in this way too.

 

Can you tell me if ZEN is behaving correctly in this case or do I have another VMWare issue to solve?

 

Thanks again.

 

David

 

 

 

 

 

From: Emilio Campos [mailto:emilio.campos.martin <at> gmail.com]
Sent: 12 October 2011 23:02


To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Thanks to you David, your problems has been used for detected some bug with the cluster configuration and RSA communications. ;)

Welcomed!

2011/10/12 David Martin (IT) <dmartin-ANfHjr1BzNdHPrDE71CqTQ@public.gmane.orguk>

Success!

 

It is a VMWare issue. By default, our vSwitch security policy disables Promiscuous Mode, Mac Address Changes and Forged Transmits. Since CARP uses these features to establish the virtual mac and virtual IP addresses, it didn’t work. VMWare player does not have these security features and works fine.

 

By enabling these settings on the VMware port group for the VLAN that is in use, the virtual NIC can access the required functionality to support CARP (and VRRP, HSRP and similar).

 

I also found this document which describes another potential issue with CARP. It might be useful for others:

http://roggyblog.blogspot.com/2010/05/using-hsrpcarp-and-vrrp-within-vmware.html

 

Sorry to be such a pain over the last few days, I’ll keep the volume of email down now, honest!

 

On the plus side, I’m putting together some documentation on how to build for VMware and, if you want, I’d be happy to share it. I know Nick Furnell is working on an appliance that will take some of the nasty bits away (VMXnet drivers and the like) but I think there will still be some little tweaks that need to be made on the vCenter/ESX side.

 

Anyway, thanks again for the welcome and the support.

 

Regards

 

David

 

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 11 October 2011 23:06


To: zenloadbalancer-support-5NWGOfrQmnfLDRD5uJR0wg@public.gmane.orgeforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

I should be able to do those tests in the morning.

 

I used ssh-copy-id to push the public keys onto opposite nodes, ssh login without password was working fine when I checked last.

 

Regards

 

David

Sent from my iPhone


On 11 Oct 2011, at 22:59, "Emilio Campos" <emilio.campos.martin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

Hi David, I just configured my environment similar to your and I can't reproduce the error, for me all is working fine, I need more information:

please eject this commands on both nodes and send me the output:

on node1:

ps -ef| grep ucarp
ifconfig -a
ps -ef | grep inotify
ip addr list

on node2:

ps -ef | grep ucarp
ifconfig -a
ps -ef| grep inotify
ip addr list


from node1 try to connect to node2 via ssh
node1# ssh root <at> ip_node2
and from node try to connect to node1 via ssh
node2# ssh root <at> ip_node1
try before the configuration cluster, this should work writing the root password, confirm this please
try ffter the configuration cluster, this should work without write the root password, confirm this please


Access to web gui,and after RSA configuration try to test the connection clicking "Test RSA connections" buttom on both nodes please.


Also I checked the logs that you send me ,and all is fine, only errors about RSA connection, that on the end of file don't appear

Please run the test and attach to this lines the output.

The name hope it's not the cause, but if it should be the cause we could modify the sourcecode to accept these naming, no problem.

Thanks!

We are waiting your feedback

2011/10/11 David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org>

I will try in the morning. I think in my VMWare player environment I just used node1 and node2 as names. I have to be a bit more careful to use our naming conventions in the vSphere system so I used the full names.

 

If this is the cause, then is it something that can be accommodated or do I need to 'bend' my naming rules?

 

David

Sent from my iPhone


On 11 Oct 2011, at 20:50, "Emilio Campos" <emilio.campos.martin <at> gmail.com> wrote:

Hi David, I think I detected the problem, at the moment try to configure the other cluster type "node1 or node2 can be masters" and tell us!

I tell you the possible error:
On the cluster type, with failback on the file that configure the cluster /usr/local/zenloadbalancer/config/cluster.conf there is a line with this:


I am working on development environment and I suspect where is the bug!

TYPECLUSTER:GRP-ZEN-01s-GRP-ZEN-02s:UP

I defined the separator "-" to know the hostname for node master and the hostname for node backup, on this case with the hostname that you configured with "-" character the process can't  identify the two nodes.


Can you try the other cluster type and tell us if the configuration process work like a charm? :P


we hope your feedback!

2011/10/11 David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org>

Interesting, the same build in the vSphere 5 environment is not working.

 

I will do some more digging.

 

From: David Martin (IT) [mailto:dmartin <at> jpress.co.uk]
Sent: 11 October 2011 17:04


To: zenloadbalancer-support-5NWGOfrQmnfLDRD5uJR0wg@public.gmane.orgeforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Active on bothnodesatthesametime

 

I have just built a completely new pair of servers on VMWare Player, using a single NIC and the patch that you supplied. They seem to be working fine.

 

Next I will repeat the procedure on the vSphere 5 production environment, completely building each node from scratch and applying the RC5 update and the patch you gave me. I might take a snapshot inbetween RC5 and the patch and see if there is any difference.

 

Thanks for your continued patience.

 

David

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 11 October 2011 16:37
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodesatthesametime

 

Here are the config and logs.

 

Note that on zen-02, it was complaining about rsync ssh failures. I swapped public keys on the two nodes and that seems to have gone away (see further down zeninotify.log).

 

Nick, thanks for that. I didn’t really suspect VMWare as there is no multicast or other unusual ‘traffic’ going on. In the latest attempt I ditched the extra NIC (which was provisioned though VMWare) and am just using eth0 with the same result.

 

I’m convincing myself I’ve made a daft error or am labouring under a false assumption. If someone could confirm that my clustering method is correct, that would be useful.

 

Regards


David

 

From: Emilio Campos [mailto:emilio.campos.martin <at> gmail.com]
Sent: 11 October 2011 15:26
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodesatthesame time

 

David please, can you send us a tar.gz file from both nodes, with content of /usr/local/zenloadbalancer/config and /usr/local/zenloadbalancer/logs

I would like study why not on your environtment it's not working fine!

by other hand, can you try to configure all only with one eth? disable eth1 on both nodes and try again!

Tanks!

2011/10/11 David Martin (IT) <dmartin <at> jpress.co.uk>

Still not working (assuming the procedure I gave was correct):

 

Zen latency is UP on GRP-ZEN-01s 10.200.28.173 | Zen latency is UP on GRP-ZEN-02s 10.200.28.174 <image001.png>
Cluster IP 10.200.28.175 is active on GRP-ZEN-01s Cluster is active on GRP-ZEN-02s 
<image002.png>
Zen Inotify is running on GRP-ZEN-01s GRP-ZEN-02s 
<image002.png>


Global status: <image002.png>

 

<image003.jpg>

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 11 October 2011 14:51


To: zenloadbalancer-support-5NWGOfrQmnfLDRD5uJR0wg@public.gmane.orgeforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodes atthesame time

 

Hmm, not so fast. I think I deleted a vmware snapshot that contained the patched version by accident. Give me five minutes.

 

Sorry.

 

David

 

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 11 October 2011 14:46
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodes at thesame time

 

Emilio,

 

I have applied on both nodes.

 

Because I have done quite a bit of messing about, I’m tempted to start again. It should only take half an hour or so.

 

Before I do, can you confirm that the following procedure is ok please?

 

On Node1

1. Configure real IP address of eth1 = 10.200.28.173

 

On Node2

2. Configure real IP address of eth1 = 10.200.28.174

 

On Node1

3. Create virtual interface called eth1:cl = 10.200.28.175

4. Select eth1:cl as the virtual IP for a new Cluster and press "Save VIP"

5. Enter Node2's name and eth1 IP address in the "Remote" section and press "Save"

6. Type password in box and press "Configure RSA connection"

7. Select the first option from the cluster type menu "Node1 master and Node2 backup automatic failback"

8. Select "Configure Cluster Type"

 

The only other thing I can think of is that eth0 and eth1 are on the same subnet. Could this be causing confusion?

 

Regards

 

David

 

From: Emilio Campos [mailto:emilio.campos.martin <at> gmail.com]
Sent: 11 October 2011 13:43
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodes at the same time

 

David, please confirm me.

 applied the patch on both zen servers ?

Did you deleted the cluster interface on both nodes? and repeated the process from begining?

 Remember:  You don't need connect to both node members for configure the cluster, the secondary node will be configured automaticaly.

I'm waiting your feedback

Regards!

Hmm, looks a bit different but still not right:

 

Node 1:

 

Zen latency is UP on GRP-ZEN-01s 10.200.28.173 | Zen latency is DOWN on GRP-ZEN-02s 10.200.28.174 <image002.png>
Cluster IP 10.200.28.175 is active on GRP-ZEN-01s Host key verification failed. 
<image001.png>
Zen Inotify is running on GRP-ZEN-01s Host key verification failed. 
<image001.png>
Global status: <image002.png>

 

Node 2:

 

Zen latency is UP on GRP-ZEN-02s 10.200.28.174 | Zen latency is DOWN on GRP-ZEN-01s 10.200.28.173 <image002.png>
Cluster IP 10.200.28.175 is active on GRP-ZEN-02s Host key verification failed. 
<image001.png>
Zen Inotify is running on GRP-ZEN-02s Host key verification failed
<image001.png>.
Global status: <image002.png>

 

David

 

From: Emilio Campos [mailto:emilio.campos.martin <at> gmail.com]
Sent: 10 October 2011 22:28
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodes at the same time

 

David, I just developed the patch that fix the problem reported by you, could you help us with your test and send us your feedback?

Please write my file attached on /usr/local/zenloadbalancer/www/, rewriting the actual file
Disable the cluster configuration, delete the eth0:cl interface on both nodes and repeat the proccess from the begining.


We would like to know if with this change all is working fine

We are waiting your feedback!

Thanks and regards

2011/10/10 Emilio Campos <emilio.campos.martin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

HI David, I just detected a problem on cluster configuration, from node backup to node master


We going to solve for v1 stable


Thanks about your reports!

Hi,

 

I’m new to Zen and was hoping to get some advice. I have configured two boxes, grp-zen-01s and grp-zen-02s, and am struggling to get clustering to work.

 

I get no errors when configuring the cluster, but when I am finished I get the following status:

 

 

 

Zen latency is UP on GRP-ZEN-02s 10.200.28.174 | Zen latency is UP on GRP-ZEN-01s 10.200.28.173 <image001.png>
Cluster IP 10.200.28.175 is active on GRP-ZEN-02s Cluster is active on GRP-ZEN-01s 
<image002.png>
Zen Inotify is running on GRP-ZEN-02s GRP-ZEN-01s 
<image002.png>
Global status: <image002.png>

 

 

 

From what I can see, the VIP and Inotify should only be active on one node. I’m guessing the Passive node is having difficulty seeing the active node so it is ‘going active’ too.

 

The only ‘unusual’ bit of my setup is that both nodes are running on VMWare vSphere 5 hosts (the same host for testing, actually). I’m wondering if that could be part of the issue but I can’t see how.

 

I built one node (but no cluster or farm config) and then cloned it to get the second. I think I have caught all the IDs that I need to change (IP address, hostname, mac address, etc) but, in case I have missed something, I am going to build another node from scratch tomorrow and see if that makes a difference. Is there anything else that uniquely identifies a Zen node?

 

Thanks in advance.

 

Regards

 

David

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS  Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed. This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error.Please delete it or return it to the sender or notify us by email at postmaster <at> jpress.co.uk 

 

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmnd4wTydcyPnfg@public.gmane.orgceforge.net




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmncRDUWM+popnw@public.gmane.orgforge.net

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org  Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org 
Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS  Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s). If you are not the intended recipient, you have received this e-mail in error.Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org  


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org  Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org 
Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS  Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s). If you are not the intended recipient, you have received this e-mail in error.Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org  


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmncRDUWM+popnw@public.gmane.orgforge.net

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct

Johnston Press plc  Registered in Scotland no. SC015382 Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed. This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error.Please delete it or return it to the sender or notify us by email at postmaster <at> jpress.co.uk 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct

Johnston Press plc  Registered in Scotland no. SC015382 Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed. This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error.Please delete it or return it to the sender or notify us by email at postmaster <at> jpress.co.uk 
Johnston Press plc  Registered in Scotland no. SC015382 Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed. This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error.Please delete it or return it to the sender or notify us by email at postmaster <at> jpress.co.uk 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org  Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org 
Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org 
Johnston Press plc  Registered in Scotland no. SC015382Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed.This e-mail and any files with it are solely for the use of the addressee(s).If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email atpostmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc Registered in Scotland no. SC015382 Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed. This e-mail and any files with it are solely for the use of the addressee(s). If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email at postmaster <at> jpress.co.uk

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support


Attachment (zen-GARP.tgz): application/x-gzip, 18 KiB
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
David Martin (IT | 18 Oct 11:05 2011
Picon

Re: Cluster Activeonbothnodesatthesametime

Great, I will try and test today.

 

Thanks Laura

 

David

 

From: laura Garcia [mailto:nevola-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 17 October 2011 16:23
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Well David, here you are the patch. Please, follow these steps on both nodes:

# > apt-get install iputils-arping
# > tar zxvf zen-GARP.tgz -C /

The global.cfg file will be overwritten so you should reconfigure the global default gw through the Zen GUI before the failover.

Try & feedback, please.

Regards,
Laura.

On Mon, Oct 17, 2011 at 9:39 AM, David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org> wrote:

Will give it a go. Is this any use:

 

http://www.cyberciti.biz/faq/linux-networking-sending-gratuitous-arps/

 

 

 

From: laura Garcia [mailto:nevola-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 14 October 2011 16:58
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5urNAH6kLmebB@public.gmane.org.net
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Ok, it's the behaviour I though.

Meanwhile we find a way to force the ARP replication, you could use the cluster interface (eth0:cl) to start the farm service as workaround.

Regards,
Laura.

On Fri, Oct 14, 2011 at 3:26 PM, David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org> wrote:

Interesting.

 

First with 10.200.28.175, which is the eth0:cl interface:

 

root <at> zen2:~# tcpdump -i eth0 arp src host 10.200.28.175

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

14:19:33.345966 ARP, Request who-has 10.200.28.175 (00:50:56:02:81:72 (oui Unknown)) tell 10.200.28.175, length 28

14:19:34.346096 ARP, Request who-has 10.200.28.175 (00:50:56:02:81:72 (oui Unknown)) tell 10.200.28.175, length 28

 

And now with 10.200.28.173, which is the eth0:vip0 interface:

 

root <at> zen2:~# tcpdump -i eth0 arp src host 10.200.28.173

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

^C

0 packets captured

1 packets received by filter

0 packets dropped by kernel

 

No ARP packets for the vip01 interface. I’m going to move the 10.200.28.173 VIP onto eth1 and see if that produces a different result. I can’t see why it would though.

 

Regards

 

David

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 14 October 2011 13:34
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

I will try it now.

 

Thanks

 

David

 

From: laura Garcia [mailto:nevola <at> gmail.com]
Sent: 14 October 2011 11:56
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

In my testing, when a new ip address has been added to a network interface, the system sends ARP packets with the new state.
Could you run this command on the node 2 and try the failover again?

> tcpdump -i eth0 arp src host 10.200.28.173

The output should show the change of the MAC address when the failover is in process.

Regards,
Laura.

On Fri, Oct 14, 2011 at 11:18 AM, David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org> wrote:

In my tests you can do it without downing the interface but I think it will still confuse UCARP.

 

On the ARP front, I’ve just done a preliminary test on the switches by debugging ARP traffic. I’ve cut the logs down quite a bit (each of these switches has at least 8 10Gig ports and they are pretty busy).

 

Oct 14 09:53:28.205 UTC: IP ARP: rcvd req src 10.200.28.172 0050.5602.8172, dst 10.200.28.254 Vlan28

Oct 14 09:53:28.205 UTC: IP ARP: sent rep src 10.200.28.254 0000.0c07.ac01, dst 10.200.28.172 0050.5602.8172 Vlan28

Oct 14 09:53:39.797 UTC: IP ARP: rcvd req src 10.200.28.171 0050.5602.8171, dst 10.200.28.254 Vlan28

Oct 14 09:53:39.797 UTC: IP ARP: sent rep src 10.200.28.254 0000.0c07.ac01, dst 10.200.28.171 0050.5602.8171 Vlan28

Oct 14 09:53:50.145 UTC: IP ARP: rcvd req src 10.200.28.175 0050.5602.8172, dst 10.200.28.175 Vlan28

Oct 14 09:53:50.145 UTC: IP ARP: rcvd req src 10.200.28.175 0050.5602.8172, dst 10.200.28.175 Vlan28

Oct 14 09:53:51.145 UTC: IP ARP: rcvd req src 10.200.28.175 0050.5602.8172, dst 10.200.28.175 Vlan28

Oct 14 09:53:51.145 UTC: IP ARP: rcvd req src 10.200.28.175 0050.5602.8172, dst 10.200.28.175 Vlan28

Oct 14 09:54:14.953 UTC: IP ARP: rcvd req src 10.200.28.172 0050.5602.8172, dst 10.200.28.171 Vlan28

Oct 14 09:54:14.953 UTC: IP ARP: rcvd req src 10.200.28.172 0050.5602.8172, dst 10.200.28.171 Vlan28

Oct 14 09:54:15.953 UTC: IP ARP: rcvd req src 10.200.28.172 0050.5602.8172, dst 10.200.28.171 Vlan28

Oct 14 09:54:15.953 UTC: IP ARP: rcvd req src 10.200.28.172 0050.5602.8172, dst 10.200.28.171 Vlan28

 

This is taken just as I pull the network card on node 1 (10.200.28.171). the eth0:cl address is 10.200.28.175 and the eth0:vip01 address (my test farm) is 10.200.28.173.  Interestingly, the :cl interface ARP gets updated but the 10.200.28.173 does not.

 

I have tried ping tests on the :cl interface and that does failover correctly….. it’s just the farms that don’t work

 

David

 

From: laura Garcia [mailto:nevola-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 14 October 2011 08:24
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uuRhgaa4a2kL@public.gmane.orgnet
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Definitely, it's not possible to change the MAC address. To change the MAC address we've to do a down of the physical interface, change the MAC, and then, up the interface again. Meanwhile this process is done, the CARP diagnoses a problem with the network interface (that it has been down) and then, try to failover again.

CARP doesn't wait for the timeout of ARP tables, like you said, it sends gratuitous ARP packets that would be enough to update the ARP tables on the switches. Did you have analyzed the traffic between vmware servers?

Regards,
Laura.

On Thu, Oct 13, 2011 at 5:26 PM, David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org> wrote:

You are right, sorry. It looks like it is quite involved to get more than one mac on a card. There are some linux TAP/TUN drivers that can do it but it looks pretty complex.

 

From: laura Garcia [mailto:nevola-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 13 October 2011 16:07
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

You're right, but I've been doing some testing and the system doesn't allow to change a MAC address of a virtual interface. You've to change the physical parent MAC to get it works.

On Thu, Oct 13, 2011 at 4:59 PM, David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org> wrote:

Emilio,

 

I’d love to help with any testing you want.

 

In the meantime, I’ve been looking through the ucarp documentation and the zen source so I can get a better idea of how failover is working.

 

It looks from the documentation like ucarp should be sending a Gratuitous ARP when the failover occurs so that the router can update the arp table. I’m going to have a play with wireshark later today to see if I can capture and examine this packet. If that is not working with VMware for some reason, then that might be why my failover times are so long.

 

On the mac address front, I think it should be relatively easy to change the MAC address of the vip as it comes up. In the  zenlatancy-start script you could do something like the following to change the mac address of the VIP:

 

# You already do this bit to ‘up’ the interface

ip addr add 10.200.28.174\/255.255.255.0 dev eth0\:test label eth0\:test

#This tells the kernel to reset the link address

ip link set eth0\:test address 00:11:22:33:44:55

 

You would need to have a place on the interface to edit the virtual mac address (and a way of setting it to default if someone changed it automatically), and you would have to change the interface definition file but otherwise I think everything else should just work.

 

Please don’t think I’m telling you how to develop or what direction to take Zen. It’s a great product and I’m just enthusiastic.

 

Cheers

 

David

 

 

From: Emilio Campos [mailto:emilio.campos.martin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 13 October 2011 14:51
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Hi David, at this moment UCARP can't share the mac address but we could study for add this new property

We have to study the time for develope this, maybe a process that generate an automatic mac could be interesting, or one process for introduce your own personalized mac.

We could add this but not on stable version, only release candidate, if you are interested on this, you could help us with the test

At the moment we can send you a work around for test this on your environment.

And you feel free for do donations :P

Regards

2011/10/13 David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org>

Laura,

 

This has not made any difference, sorry. I have done a bit more digging and given the issue a lot of thought and I think the following (very long, sorry) describes what is going on, at least in my environment.

 

When testing this using a local zen cluster (i.e. on the same subnet) the failover happens fairly quickly, within about 30 seconds.

 

When the cluster is on a remote subnet, the failover takes anything up to an hour.

 

The reason behind this, as far as I can see, it that Windows 7 has a very short ARP timeout (randomly selected between 15-45 seconds). The ARP entry that was mapping say:

MAC Address 00:0c:29:06:d0:a5 to    IP address   159.180.232.243

In my previous example will quickly time out and be replaced by

MAC Address 00:0c:29:8e:91:fa to    IP address   159.180.232.243

as the second node takes over.

 

When the cluster is remote, you are relying on the ARP table in the last router in the chain. By default, Cisco use and recommend an ARP timeout of four hours. This can be changed, but at the expense of increased ARP traffic, CPU load and in some cases latency. To better suit our VMWare environment, we have reduced this timeout to just one hour which we found to be a good compromise.

 

To get around this very long timeout, protocols like HSRP, GLBP, VRRP and CARP create a virtual mac address that both nodes share. When a node dies the network interface goes down and the switch immediately flushes its CAM table, meaning that the mac address almost instantly is available on the second node.

 

I suspect that by introducing the concept of a virtual mac address to Zen, this fast switchover can be achieved.

 

On the other hand, I could be doing something very wrong and, if so, please point it out! I’d be especially grateful if any other users could share their experience of Zen on a non-local subnet and what ARP timeouts are in use on the Zen VLAN.

 

Thanks for your patience once again, I definitely feel a donation will be in order soon!

 

David

 

 

 

From: laura Garcia [mailto:nevola-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 13 October 2011 13:37


To: zenloadbalancer-support <at> lists.sourceforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

David, could you try to execute the following commands under the 2 ZLB nodes?

echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 0 > /proc/sys/net/ipv4/conf/all/arp_announce

Then, try failback again.

Thanks.

On Thu, Oct 13, 2011 at 1:44 PM, David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org> wrote:

Thanks, I realise I’m being a pain but I’m really keen to get this into production!

 

From: laura Garcia [mailto:nevola-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 13 October 2011 12:38


To: zenloadbalancer-support-5NWGOfrQmnetEtDZOKyKiw@public.gmane.orgrge.net
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Actually, you can't modify a MAC address through the zen GUI.
Let me see what can I do to support it.

About how Zen integrates CARP, maybe Emilio could give us more details.

Regards,
Laura.

On Thu, Oct 13, 2011 at 1:06 PM, David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org> wrote:

Is there anywhere in the Zen interface definition file I can specify a mac address for the :cl interface? I can’t see a way forward without it without building a new VLAN just for Zen.

 

 

From: David Martin (IT) [mailto:dmartin <at> jpress.co.uk]
Sent: 13 October 2011 11:04


To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Sorry for replying to myself again. This page suggests that CARP should be using a virtual MAC address:

 

http://www.countersiege.com/doc/pfsync-carp/

 

David

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 13 October 2011 10:48
To: zenloadbalancer-support <at> lists.sourceforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

So by design Zen/CARP won’t failover until the ARP timeout has expired? That might be a bit of a showstopper for us, the default value for that is 4 hours on Cisco devices. We run at one hour but can’t really go lower on our production networks.

 

David

 

From: laura Garcia [mailto:nevola-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 13 October 2011 10:41
To: zenloadbalancer-support <at> lists.sourceforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

It's correct. For linux, every virtual or vlan interface uses the MAC of its physical network interface.
There is several ways to force to change a MAC, but the network driver has to support it.

Cheers,
Laura.

On Thu, Oct 13, 2011 at 10:32 AM, David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org> wrote:

I may have spoken too soon. Can you confirm something about the architecture please?

 

When both nodes are up eth0:cl only exists on node1, and ifconfig on node1 looks something like this:

 

eth0      Link encap:Ethernet  HWaddr 00:0c:29:06:d0:a5

          inet addr:159.180.232.241  Bcast:159.180.232.255  Mask:255.255.255.0

          inet6 addr: fe80::20c:29ff:fe06:d0a5/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:4653 errors:0 dropped:0 overruns:0 frame:0

          TX packets:82 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:359096 (350.6 KiB)  TX bytes:16870 (16.4 KiB)

          Interrupt:19 Base address:0x2000

 

eth0:cl   Link encap:Ethernet  HWaddr 00:0c:29:06:d0:a5

          inet addr:159.180.232.243  Bcast:0.0.0.0  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          Interrupt:19 Base address:0x2000

 

But when node 1 goes down, eth0:cl appears on node 2 and ifconfig on that node looks like this:

 

eth0      Link encap:Ethernet  HWaddr 00:0c:29:8e:91:fa

          inet addr:159.180.232.242  Bcast:159.180.232.255  Mask:255.255.255.0

          inet6 addr: fe80::20c:29ff:fe8e:91fa/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:17913 errors:0 dropped:0 overruns:0 frame:0

          TX packets:610 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:1585419 (1.5 MiB)  TX bytes:56683 (55.3 KiB)

          Interrupt:19 Base address:0x2000

 

eth0:cl   Link encap:Ethernet  HWaddr 00:0c:29:8e:91:fa

          inet addr:159.180.232.243  Bcast:0.0.0.0  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          Interrupt:19 Base address:0x2000

 

The MAC address of eth1:cl is a clone of the base eth0 address on whatever node is active. On our network, which has long ARP timeouts, this means that clients will not respond to the secondary host until the timeout period has expired (which can be over an hour). I would have thought that the virtual IP should have a virtual MAC address which floats between the two hosts (like VRRP and HSRP), but I don’t know enough about CARP to know if it works in this way too.

 

Can you tell me if ZEN is behaving correctly in this case or do I have another VMWare issue to solve?

 

Thanks again.

 

David

 

 

 

 

 

From: Emilio Campos [mailto:emilio.campos.martin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 12 October 2011 23:02


To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

Thanks to you David, your problems has been used for detected some bug with the cluster configuration and RSA communications. ;)

Welcomed!

2011/10/12 David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org>

Success!

 

It is a VMWare issue. By default, our vSwitch security policy disables Promiscuous Mode, Mac Address Changes and Forged Transmits. Since CARP uses these features to establish the virtual mac and virtual IP addresses, it didn’t work. VMWare player does not have these security features and works fine.

 

By enabling these settings on the VMware port group for the VLAN that is in use, the virtual NIC can access the required functionality to support CARP (and VRRP, HSRP and similar).

 

I also found this document which describes another potential issue with CARP. It might be useful for others:

http://roggyblog.blogspot.com/2010/05/using-hsrpcarp-and-vrrp-within-vmware.html

 

Sorry to be such a pain over the last few days, I’ll keep the volume of email down now, honest!

 

On the plus side, I’m putting together some documentation on how to build for VMware and, if you want, I’d be happy to share it. I know Nick Furnell is working on an appliance that will take some of the nasty bits away (VMXnet drivers and the like) but I think there will still be some little tweaks that need to be made on the vCenter/ESX side.

 

Anyway, thanks again for the welcome and the support.

 

Regards

 

David

 

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 11 October 2011 23:06


To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Activeonbothnodesatthesametime

 

I should be able to do those tests in the morning.

 

I used ssh-copy-id to push the public keys onto opposite nodes, ssh login without password was working fine when I checked last.

 

Regards

 

David

Sent from my iPhone


On 11 Oct 2011, at 22:59, "Emilio Campos" <emilio.campos.martin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

Hi David, I just configured my environment similar to your and I can't reproduce the error, for me all is working fine, I need more information:

please eject this commands on both nodes and send me the output:

on node1:

ps -ef| grep ucarp
ifconfig -a
ps -ef | grep inotify
ip addr list

on node2:

ps -ef | grep ucarp
ifconfig -a
ps -ef| grep inotify
ip addr list


from node1 try to connect to node2 via ssh
node1# ssh root <at> ip_node2
and from node try to connect to node1 via ssh
node2# ssh root <at> ip_node1
try before the configuration cluster, this should work writing the root password, confirm this please
try ffter the configuration cluster, this should work without write the root password, confirm this please


Access to web gui,and after RSA configuration try to test the connection clicking "Test RSA connections" buttom on both nodes please.


Also I checked the logs that you send me ,and all is fine, only errors about RSA connection, that on the end of file don't appear

Please run the test and attach to this lines the output.

The name hope it's not the cause, but if it should be the cause we could modify the sourcecode to accept these naming, no problem.

Thanks!

We are waiting your feedback

2011/10/11 David Martin (IT) <dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org>

I will try in the morning. I think in my VMWare player environment I just used node1 and node2 as names. I have to be a bit more careful to use our naming conventions in the vSphere system so I used the full names.

 

If this is the cause, then is it something that can be accommodated or do I need to 'bend' my naming rules?

 

David

Sent from my iPhone


On 11 Oct 2011, at 20:50, "Emilio Campos" <emilio.campos.martin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

Hi David, I think I detected the problem, at the moment try to configure the other cluster type "node1 or node2 can be masters" and tell us!

I tell you the possible error:
On the cluster type, with failback on the file that configure the cluster /usr/local/zenloadbalancer/config/cluster.conf there is a line with this:


I am working on development environment and I suspect where is the bug!

TYPECLUSTER:GRP-ZEN-01s-GRP-ZEN-02s:UP

I defined the separator "-" to know the hostname for node master and the hostname for node backup, on this case with the hostname that you configured with "-" character the process can't  identify the two nodes.


Can you try the other cluster type and tell us if the configuration process work like a charm? :P


we hope your feedback!

Interesting, the same build in the vSphere 5 environment is not working.

 

I will do some more digging.

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 11 October 2011 17:04


To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Active on bothnodesatthesametime

 

I have just built a completely new pair of servers on VMWare Player, using a single NIC and the patch that you supplied. They seem to be working fine.

 

Next I will repeat the procedure on the vSphere 5 production environment, completely building each node from scratch and applying the RC5 update and the patch you gave me. I might take a snapshot inbetween RC5 and the patch and see if there is any difference.

 

Thanks for your continued patience.

 

David

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 11 October 2011 16:37
To: zenloadbalancer-support-5NWGOfrQmncRDUWM+popnw@public.gmane.orgforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodesatthesametime

 

Here are the config and logs.

 

Note that on zen-02, it was complaining about rsync ssh failures. I swapped public keys on the two nodes and that seems to have gone away (see further down zeninotify.log).

 

Nick, thanks for that. I didn’t really suspect VMWare as there is no multicast or other unusual ‘traffic’ going on. In the latest attempt I ditched the extra NIC (which was provisioned though VMWare) and am just using eth0 with the same result.

 

I’m convincing myself I’ve made a daft error or am labouring under a false assumption. If someone could confirm that my clustering method is correct, that would be useful.

 

Regards


David

 

From: Emilio Campos [mailto:emilio.campos.martin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 11 October 2011 15:26
To: zenloadbalancer-support <at> lists.sourceforge.net
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodesatthesame time

 

David please, can you send us a tar.gz file from both nodes, with content of /usr/local/zenloadbalancer/config and /usr/local/zenloadbalancer/logs

I would like study why not on your environtment it's not working fine!

by other hand, can you try to configure all only with one eth? disable eth1 on both nodes and try again!

Tanks!

Still not working (assuming the procedure I gave was correct):

 

Zen latency is UP on GRP-ZEN-01s 10.200.28.173 | Zen latency is UP on GRP-ZEN-02s 10.200.28.174 <image001.png>
Cluster IP 10.200.28.175 is active on GRP-ZEN-01s Cluster is active on GRP-ZEN-02s 
<image002.png>
Zen Inotify is running on GRP-ZEN-01s GRP-ZEN-02s 
<image002.png>


Global status: <image002.png>

 

<image003.jpg>

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org]
Sent: 11 October 2011 14:51


To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodes atthesame time

 

Hmm, not so fast. I think I deleted a vmware snapshot that contained the patched version by accident. Give me five minutes.

 

Sorry.

 

David

 

 

From: David Martin (IT) [mailto:dmartin-ANfHjr1BzNdJMcDr3E8U/A@public.gmane.orgk]
Sent: 11 October 2011 14:46
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodes at thesame time

 

Emilio,

 

I have applied on both nodes.

 

Because I have done quite a bit of messing about, I’m tempted to start again. It should only take half an hour or so.

 

Before I do, can you confirm that the following procedure is ok please?

 

On Node1

1. Configure real IP address of eth1 = 10.200.28.173

 

On Node2

2. Configure real IP address of eth1 = 10.200.28.174

 

On Node1

3. Create virtual interface called eth1:cl = 10.200.28.175

4. Select eth1:cl as the virtual IP for a new Cluster and press "Save VIP"

5. Enter Node2's name and eth1 IP address in the "Remote" section and press "Save"

6. Type password in box and press "Configure RSA connection"

7. Select the first option from the cluster type menu "Node1 master and Node2 backup automatic failback"

8. Select "Configure Cluster Type"

 

The only other thing I can think of is that eth0 and eth1 are on the same subnet. Could this be causing confusion?

 

Regards

 

David

 

From: Emilio Campos [mailto:emilio.campos.martin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 11 October 2011 13:43
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodes at the same time

 

David, please confirm me.

 applied the patch on both zen servers ?

Did you deleted the cluster interface on both nodes? and repeated the process from begining?

 Remember:  You don't need connect to both node members for configure the cluster, the secondary node will be configured automaticaly.

I'm waiting your feedback

Regards!

Hmm, looks a bit different but still not right:

 

Node 1:

 

Zen latency is UP on GRP-ZEN-01s 10.200.28.173 | Zen latency is DOWN on GRP-ZEN-02s 10.200.28.174 <image002.png>
Cluster IP 10.200.28.175 is active on GRP-ZEN-01s Host key verification failed. 
<image001.png>
Zen Inotify is running on GRP-ZEN-01s Host key verification failed. 
<image001.png>
Global status: <image002.png>

 

Node 2:

 

Zen latency is UP on GRP-ZEN-02s 10.200.28.174 | Zen latency is DOWN on GRP-ZEN-01s 10.200.28.173 <image002.png>
Cluster IP 10.200.28.175 is active on GRP-ZEN-02s Host key verification failed. 
<image001.png>
Zen Inotify is running on GRP-ZEN-02s Host key verification failed
<image001.png>.
Global status: <image002.png>

 

David

 

From: Emilio Campos [mailto:emilio.campos.martin <at> gmail.com]
Sent: 10 October 2011 22:28
To: zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Zenloadbalancer-support] Cluster Active on both nodes at the same time

 

David, I just developed the patch that fix the problem reported by you, could you help us with your test and send us your feedback?

Please write my file attached on /usr/local/zenloadbalancer/www/, rewriting the actual file
Disable the cluster configuration, delete the eth0:cl interface on both nodes and repeat the proccess from the begining.


We would like to know if with this change all is working fine

We are waiting your feedback!

Thanks and regards

2011/10/10 Emilio Campos <emilio.campos.martin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

HI David, I just detected a problem on cluster configuration, from node backup to node master


We going to solve for v1 stable


Thanks about your reports!

Hi,

 

I’m new to Zen and was hoping to get some advice. I have configured two boxes, grp-zen-01s and grp-zen-02s, and am struggling to get clustering to work.

 

I get no errors when configuring the cluster, but when I am finished I get the following status:

 

 

 

Zen latency is UP on GRP-ZEN-02s 10.200.28.174 | Zen latency is UP on GRP-ZEN-01s 10.200.28.173 <image001.png>
Cluster IP 10.200.28.175 is active on GRP-ZEN-02s Cluster is active on GRP-ZEN-01s 
<image002.png>
Zen Inotify is running on GRP-ZEN-02s GRP-ZEN-01s 
<image002.png>
Global status: <image002.png>

 

 

 

From what I can see, the VIP and Inotify should only be active on one node. I’m guessing the Passive node is having difficulty seeing the active node so it is ‘going active’ too.

 

The only ‘unusual’ bit of my setup is that both nodes are running on VMWare vSphere 5 hosts (the same host for testing, actually). I’m wondering if that could be part of the issue but I can’t see how.

 

I built one node (but no cluster or farm config) and then cloned it to get the second. I think I have caught all the IDs that I need to change (IP address, hostname, mac address, etc) but, in case I have missed something, I am going to build another node from scratch tomorrow and see if that makes a difference. Is there anything else that uniquely identifies a Zen node?

 

Thanks in advance.

 

Regards

 

David

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster <at> jpress.co.uk

 

 

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uuRhgaa4a2kL@public.gmane.orgnet

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster <at> jpress.co.uk

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uuRhgaa4a2kL@public.gmane.orgnet

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster <at> jpress.co.uk

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNdHPrDE71CqTQ@public.gmane.orguk

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneHXe+LvDLADg@public.gmane.orgrceforge.net

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster <at> jpress.co.uk

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support




--
Load balancer distribution - Open Source Project
http://www.zenloadbalancer.com
Distribution list (subscribe): zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNdhl2p70BpVqQ@public.gmane.org.uk

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc  Registered in Scotland no. SC015382

Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS

 

Opinions expressed in this email are those of the writer and not the company.

E-mail traffic is monitored within Johnston Press and messages may be viewed.

This e-mail and any files with it are solely for the use of the addressee(s).

If you are not the intended recipient, you have received this e-mail in error.

Please delete it or return it to the sender or notify us by email at

postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org

 


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Zenloadbalancer-support mailing list
Zenloadbalancer-support <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support

 

Johnston Press plc Registered in Scotland no. SC015382 Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS Opinions expressed in this email are those of the writer and not the company. E-mail traffic is monitored within Johnston Press and messages may be viewed. This e-mail and any files with it are solely for the use of the addressee(s). If you are not the intended recipient, you have received this e-mail in error. Please delete it or return it to the sender or notify us by email at postmaster-ANfHjr1BzNfQXOPxS62xeg@public.gmane.org
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct

Gmane