Yes you can, delete the file /usr/local/zenloadbalancer/config/cluster.conf on two nodes and restart zenloadablancer
/etc/init.d/zenloadbalancer stop /etc/init.d/zenloadbalancer start maybe would be neccesary reenter the route command that laura sended you on the last messages we going to study the problem and tell you! Please write me if your problem persist! 2011/7/5 Chiesa Stefano <[email protected]>: > Hi Emilio. > > I changed the script and the cluster could be up. I said "could" because as > cluster started I lost the two server. > In the cluster configuration I chose to use one if for web gui (eth1) e one > for the cluster (eth5). > > Now from HQ (10.39.160.x) I can't reach any of the two servers > (10.39.18.x-dmz nor 172.16.40.x-web gui) > > Even zen1 can't ping zen2 (in the same network): > > root@s-dr-zen:~# ping -I eth0 10.39.18.190 > PING 10.39.18.190 (10.39.18.190) from 10.39.18.110 eth0: 56(84) bytes of data. > >From 10.39.18.110 icmp_seq=1 Destination Host Unreachable > >From 10.39.18.110 icmp_seq=2 Destination Host Unreachable > >From 10.39.18.110 icmp_seq=3 Destination Host Unreachable > > root@s-dr-zen:~# ping -I eth1 172.16.40.111 > PING 172.16.40.111 (172.16.40.111) from 172.16.40.110 eth1: 56(84) bytes of > data. > >From 172.16.40.110 icmp_seq=2 Destination Host Unreachable > >From 172.16.40.110 icmp_seq=3 Destination Host Unreachable > >From 172.16.40.110 icmp_seq=4 Destination Host Unreachable > > As I can reach zen2 via ssh on the cluster if, what ca I do to "reset" the > situation at the previous step? > Can I delete the "/usr/local/zenloadbalancer/config/cluster.conf" on two > nodes? Try a reboot? > > It's quite importat for me to be able to return in a manageable situation (my > collegues are keep trying their services and in that moment are not reachable > form outside the DMZ) > > > > p.s. in the following (and attached) log files errors are reported. Maybe you > can find more info there. > > Sorry the long long email. > > Ciao. > Stefano. > > > ######### ZEN 1 ########## > > /usr/local/zenloadbalancer/logs/zenloadbalancer.log (today logs) > > Tue Jul 5 09:07:58 2011 - 172.16.40.110 - 10.39.160.41 - admin - Running > process for configure RSA comunication > Tue Jul 5 09:07:58 2011 - 172.16.40.110 - 10.39.160.41 - admin - Deleting > old RSA key on s-dr-zen (172.16.18.1) > Tue Jul 5 09:07:58 2011 - 172.16.40.110 - 10.39.160.41 - admin - Creating > new RSA keys on s-dr-zen (172.16.18.1) > Tue Jul 5 09:07:59 2011 - 172.16.40.110 - 10.39.160.41 - admin - Copying new > RSA key from s-dr-zen (172.16.18.1) to s-dr-zen2 (172.16.18.2) > Tue Jul 5 09:08:03 2011 - 172.16.40.110 - 10.39.160.41 - admin - Deleting > old RSA key on s-dr-zen2 > Tue Jul 5 09:08:03 2011 - 172.16.40.110 - 10.39.160.41 - admin - Creating > new remote RSA key on s-dr-zen2 > Tue Jul 5 09:08:04 2011 - 172.16.40.110 - 10.39.160.41 - admin - Copying new > RSA key from s-dr-zen2 to s-dr-zen > Tue Jul 5 09:08:04 2011 - 172.16.40.110 - 10.39.160.41 - admin - Enabled RSA > communication between cluster hosts > Tue Jul 5 09:08:04 2011 - 172.16.40.110 - 10.39.160.41 - admin - Enabled RSA > communication between cluster hosts > Tue Jul 5 09:08:17 2011 - 172.16.40.110 - 10.39.160.41 - admin - RSA > connection from s-dr-zen (172.16.18.1) to s-dr-zen2 (172.16.18.2) is OK > Tue Jul 5 09:08:33 2011 - 172.16.40.110 - 10.39.160.41 - admin - Sending > /usr/local/zenloadbalancer/config/cluster.conf to 172.16.18.2 > Tue Jul 5 09:08:34 2011 - 172.16.40.110 - 10.39.160.41 - admin - Running Zen > latency Service and Zen inotify Service, please wait > Tue Jul 5 09:08:40 2011 - 172.16.40.110 - 10.39.160.41 - admin - Cluster > configured on mode s-dr-zen or s-dr-zen2 can be masters > Tue Jul 5 09:08:40 2011 - 172.16.40.110 - 10.39.160.41 - admin - Reload here > <a href="index.cgi?id=3-3"><img src="img/icons/small/arrow_refresh.png"></a> > for see changes > Tue Jul 5 09:08:48 2011 - 172.16.40.110 - 10.39.160.41 - admin - running > '/sbin/ip link set up' > Tue Jul 5 09:08:48 2011 - 172.16.40.110 - 10.39.160.41 - admin - running > '/sbin/ip link set up' > Tue Jul 5 09:08:48 2011 - 172.16.40.110 - 10.39.160.41 - admin - running > '/sbin/ip link set up' > root@s-dr-zen:/usr/local/zenloadbalancer# > > --- > root@s-dr-zen:/usr/local/zenloadbalancer/logs# cat ucarp.log > Jul 5 09:08:34 s-dr-zen ucarp[6517]: [INFO] Local advertised ethernet > address is [00:26:55:db:68:3e] > Jul 5 09:08:34 s-dr-zen ucarp[6517]: [WARNING] Switching to state: BACKUP > Jul 5 09:08:34 s-dr-zen ucarp[6517]: [WARNING] Spawning > [/usr/local/zenloadbalancer/app/zenlatency/zenlatency-stop.pl eth5 > 172.16.18.3] > Jul 5 09:08:42 s-dr-zen ucarp[6517]: [WARNING] Switching to state: MASTER > Jul 5 09:08:42 s-dr-zen ucarp[6517]: [WARNING] Spawning > [/usr/local/zenloadbalancer/app/zenlatency/zenlatency-start.pl eth5 > 172.16.18.3] > Jul 5 09:08:53 s-dr-zen ucarp[6517]: [WARNING] Non-preferred master > advertising: reasserting control of VIP with another gratuitous arp > Jul 5 09:08:53 s-dr-zen ucarp[6517]: [WARNING] Non-preferred master > advertising: reasserting control of VIP with another gratuitous arp > Jul 5 09:08:53 s-dr-zen ucarp[6517]: [WARNING] Non-preferred master > advertising: reasserting control of VIP with another gratuitous arp > root@s-dr-zen:/usr/local/zenloadbalancer/logs# > > --- > root@s-dr-zen:/usr/local/zenloadbalancer/logs# cat zenlatency.log > > 11/07/05 09-08-34 Running start commands: > Running: /sbin/ip addr del 172.16.18.3/29 dev eth5 label eth5:cl > > 11/07/05 09-08-42 Running start commands: > Running: /sbin/ip addr add 172.16.18.3/29 dev eth5 label eth5:cl > > Running Zen inotify syncronization service > /usr/local/zenloadbalancer/app/zeninotify/zeninotify.pl &cp: missing > destination file operand after `/etc/iproute2/rt_tables' > Try `cp --help' for more information. > mv: cannot stat `/etc/iproute2/rt_tables_sync': No such file or directory > root@s-dr-zen:/usr/local/zenloadbalancer/logs# > > --- > root@s-dr-zen:/usr/local/zenloadbalancer/logs# cat zeninotify.log ATTACHED > > ---- > root@s-dr-zen:~# ip route > 172.16.18.0/29 dev eth5 proto kernel scope link src 172.16.18.1 > 172.16.40.0/24 dev eth1 proto kernel scope link src 172.16.40.110 > 10.39.18.0/23 dev eth0 proto kernel scope link src 10.39.18.110 > default via 10.39.18.240 dev eth0 > > *** The config seems ok, bu I can't ping any server if from HQ > > root@s-dr-zen:~# ifconfig -a > eth0 Link encap:Ethernet HWaddr 00:1b:78:92:96:c2 > inet addr:10.39.18.110 Bcast:10.39.19.255 Mask:255.255.254.0 > inet6 addr: fe80::21b:78ff:fe92:96c2/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:30254 errors:0 dropped:0 overruns:0 frame:0 > TX packets:1145 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:15798235 (15.0 MiB) TX bytes:371268 (362.5 KiB) > Interrupt:16 Memory:f8000000-f8012800 > > eth0:1 Link encap:Ethernet HWaddr 00:1b:78:92:96:c2 > inet addr:10.39.18.100 Bcast:10.39.19.255 Mask:255.255.254.0 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > Interrupt:16 Memory:f8000000-f8012800 > > eth0:2 Link encap:Ethernet HWaddr 00:1b:78:92:96:c2 > inet addr:10.39.18.103 Bcast:10.39.19.255 Mask:255.255.254.0 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > Interrupt:16 Memory:f8000000-f8012800 > > eth0:3 Link encap:Ethernet HWaddr 00:1b:78:92:96:c2 > inet addr:10.39.18.106 Bcast:10.39.19.255 Mask:255.255.254.0 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > Interrupt:16 Memory:f8000000-f8012800 > > eth1 Link encap:Ethernet HWaddr 00:1b:78:92:96:c0 > inet addr:172.16.40.110 Bcast:172.16.40.255 Mask:255.255.255.0 > inet6 addr: fe80::21b:78ff:fe92:96c0/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:2209 errors:0 dropped:0 overruns:0 frame:0 > TX packets:19 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:148319 (144.8 KiB) TX bytes:1552 (1.5 KiB) > Interrupt:17 Memory:fa000000-fa012800 > > eth2 Link encap:Ethernet HWaddr 00:26:55:db:68:3c > BROADCAST MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) > Memory:fdbe0000-fdc00000 > > eth3 Link encap:Ethernet HWaddr 00:26:55:db:68:3d > BROADCAST MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) > Memory:fdce0000-fdd00000 > > eth4 Link encap:Ethernet HWaddr 00:26:55:db:68:3f > BROADCAST MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) > Memory:fdee0000-fdf00000 > > eth5 Link encap:Ethernet HWaddr 00:26:55:db:68:3e > inet addr:172.16.18.1 Bcast:172.16.18.7 Mask:255.255.255.248 > inet6 addr: fe80::226:55ff:fedb:683e/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:1429 errors:0 dropped:0 overruns:0 frame:0 > TX packets:6123 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:295556 (288.6 KiB) TX bytes:578122 (564.5 KiB) > Memory:fdde0000-fde00000 > > eth5:cl Link encap:Ethernet HWaddr 00:26:55:db:68:3e > inet addr:172.16.18.3 Bcast:0.0.0.0 Mask:255.255.255.248 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > Memory:fdde0000-fde00000 > > ######### ZEN 2 ########## > > /usr/local/zenloadbalancer/logs/zenloadbalancer.log (yesterday and today > logs) > > Mon Jul 4 12:28:05 2011 - 172.16.40.111 - 10.39.160.41 - admin - running > '/sbin/ifconfig eth5 172.16.18.2 netmask 255.255.255.248' > Mon Jul 4 12:28:05 2011 - 172.16.40.111 - 10.39.160.41 - admin - running > '/sbin/ip link set eth5 up' > Mon Jul 4 12:28:05 2011 - 172.16.40.111 - 10.39.160.41 - admin - Network > interface eth5 is now UP > Mon Jul 4 12:28:05 2011 - 172.16.40.111 - 10.39.160.41 - admin - running > '/sbin/ip route flush table table_eth5' > Mon Jul 4 12:28:05 2011 - 172.16.40.111 - 10.39.160.41 - admin - running > '/sbin/ip route add default via dev eth5 table table_eth5' > Mon Jul 4 12:28:05 2011 - 172.16.40.111 - 10.39.160.41 - admin - All is ok, > saved eth5 interface config file > Mon Jul 4 13:33:22 2011 - 172.16.40.111 - 10.39.160.41 - admin - Local > system backup created <b>backup-s-dr-zen2-OK.tar.gz</b> > Tue Jul 5 09:08:54 2011 - - - - running '/sbin/ip link set up' > Tue Jul 5 09:08:54 2011 - - - - running '/sbin/ip link set up' > Tue Jul 5 09:08:54 2011 - - - - running '/sbin/ip link set up' > > ---- > root@s-dr-zen2:/usr/local/zenloadbalancer/logs# cat ucarp.log > Jul 5 09:08:40 s-dr-zen2 ucarp[26579]: [INFO] Local advertised ethernet > address is [00:1f:29:e8:1e:7c] > Jul 5 09:08:40 s-dr-zen2 ucarp[26579]: [WARNING] Switching to state: BACKUP > Jul 5 09:08:40 s-dr-zen2 ucarp[26579]: [WARNING] Spawning > [/usr/local/zenloadbalancer/app/zenlatency/zenlatency-stop.pl eth5 > 172.16.18.3] > Jul 5 09:08:49 s-dr-zen2 ucarp[26579]: [WARNING] Switching to state: MASTER > Jul 5 09:08:49 s-dr-zen2 ucarp[26579]: [WARNING] Spawning > [/usr/local/zenloadbalancer/app/zenlatency/zenlatency-start.pl eth5 > 172.16.18.3] > Jul 5 09:08:54 s-dr-zen2 ucarp[26579]: [WARNING] Switching to state: BACKUP > Jul 5 09:08:54 s-dr-zen2 ucarp[26579]: [WARNING] Spawning > [/usr/local/zenloadbalancer/app/zenlatency/zenlatency-stop.pl eth5 > 172.16.18.3] > Jul 5 09:09:00 s-dr-zen2 ucarp[26579]: [WARNING] Preferred master > advertised: going back to BACKUP state > > --- > root@s-dr-zen2:/usr/local/zenloadbalancer/logs# cat zeninotify.log > Running the firs replication... > /usr/bin/rsync -auzv --delete --exclude=if_eth5_conf > /usr/local/zenloadbalancer/config/ > [email protected]:/usr/local/zenloadbalancer/config/ > Host key verification failed. > rsync: connection unexpectedly closed (0 bytes received so far) [sender] > rsync error: unexplained error (code 255) at io.c(601) [sender=3.0.7] > /usr/bin/rsync -auzv --delete /etc/iproute2/rt_tables > [email protected]:/etc/iproute2/rt_tables > Host key verification failed. > rsync: connection unexpectedly closed (0 bytes received so far) [sender] > rsync error: unexplained error (code 255) at io.c(601) [sender=3.0.7] > > --- > root@s-dr-zen2:/usr/local/zenloadbalancer/logs# cat zenlatency.log > 11/07/05 09-08-40 Running start commands: > RTNETLINK answers: Cannot assign requested address > Running: /sbin/ip addr del 172.16.18.3/29 dev eth5 label eth5:cl > > 11/07/05 09-08-49 Running start commands: > Running: /sbin/ip addr add 172.16.18.3/29 dev eth5 label eth5:cl > > Running Zen inotify syncronization service > /usr/local/zenloadbalancer/app/zeninotify/zeninotify.pl &cp: missing > destination file operand after `/etc/iproute2/rt_tables' > Try `cp --help' for more information. > mv: cannot stat `/etc/iproute2/rt_tables_sync': No such file or directory > 11/07/05 09-08-54 Running start commands: > Running: /sbin/ip addr del 172.16.18.3/29 dev eth5 label eth5:cl > > Stopping zeninotify with pid 26623 > > --- > root@s-dr-zen2:~# ip route > 172.16.18.0/29 dev eth5 proto kernel scope link src 172.16.18.2 > root@s-dr-zen2:~# > > *** if I try to add the lines suggested by Laura: > > root@s-dr-zen2:~# ip rule add from 10.39.18.190 table table_eth0 > Error: argument "table_eth0" is wrong: invalid table ID > > root@s-dr-zen2:~# ip rule add from 172.16.40.111 table table_eth1 > Error: argument "table_eth1" is wrong: invalid table ID > > root@s-dr-zen2:~# ip rule add from 172.16.18.2 table table_eth5 > Error: argument "table_eth5" is wrong: invalid table ID > > *** ifconfig: is it correct? It's the original one, shouldn't be changed? > > root@s-dr-zen2:~# ifconfig -a > eth0 Link encap:Ethernet HWaddr 00:26:55:db:71:fd > inet addr:10.39.18.190 Bcast:10.39.19.255 Mask:255.255.254.0 > BROADCAST MULTICAST MTU:1500 Metric:1 > RX packets:2366292 errors:0 dropped:0 overruns:0 frame:0 > TX packets:822 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:1126136841 (1.0 GiB) TX bytes:89230 (87.1 KiB) > Memory:fdce0000-fdd00000 > > eth1 Link encap:Ethernet HWaddr 00:26:55:db:71:fc > inet addr:172.16.40.110 Bcast:172.16.40.255 Mask:255.255.255.0 > BROADCAST MULTICAST MTU:1500 Metric:1 > RX packets:164511 errors:0 dropped:0 overruns:0 frame:0 > TX packets:6199 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:10690964 (10.1 MiB) TX bytes:3135673 (2.9 MiB) > Memory:fdbe0000-fdc00000 > > eth2 Link encap:Ethernet HWaddr 00:26:55:db:71:ff > BROADCAST MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) > Memory:fdee0000-fdf00000 > > eth3 Link encap:Ethernet HWaddr 00:26:55:db:71:fe > BROADCAST MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) > Memory:fdde0000-fde00000 > > eth4 Link encap:Ethernet HWaddr 00:1f:29:e8:1e:7e > BROADCAST MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) > Interrupt:16 Memory:f8000000-f8012800 > > eth5 Link encap:Ethernet HWaddr 00:1f:29:e8:1e:7c > inet addr:172.16.18.2 Bcast:172.16.18.7 Mask:255.255.255.248 > inet6 addr: fe80::21f:29ff:fee8:1e7c/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:4324 errors:0 dropped:0 overruns:0 frame:0 > TX packets:1409 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:468666 (457.6 KiB) TX bytes:295052 (288.1 KiB) > Interrupt:17 Memory:fa000000-fa012800 > > > -----Messaggio originale----- > Da: Emilio Campos [mailto:[email protected]] > Inviato: lunedì 4 luglio 2011 22.09 > A: [email protected] > Oggetto: Re: [Zenloadbalancer-support] R: R: Zen Cluster, try #2 > > Hi Stefano, I've just detected a bug on cluster configuration scripts. > > Sometimes if not exist /root/.ssh/ directory, zen gui writes the > messages that you attached on last images. > > Please modify the next script: > > open /usr/local/zenloadbalancer/www/content3-3.cgi, on line 223 would > be something similar to this > > my $eject = $ssh->exec("rm /root/.ssh/authorized_keys; echo $rsa_pass > \>\> /root/.ssh/authorized_keys "); > > modify by > > my $eject = $ssh->exec("rm /root/.ssh/authorized_keys; mkdir > /root/.ssh/; echo $rsa_pass \>\> /root/.ssh/authorized_keys "); > > > the problem should be solved! > > > Your second bug detected, thanks! > > > > 2011/7/4 Emilio Campos <[email protected]>: >> 2011/7/4 Chiesa Stefano <[email protected]>: >>> Hi Emilio. >>> >>> Sorry but I'd not do this test... The zen2 server has not the same config >>> as zen1 (it doesn't have farms configured) ad if the cluster will start it >>> will destroy the configuration on zen1. >> >> and not needed >> >>> >>> Maybe I need more info about zen cluster. >>> For example: >>> * Do I have configure the same farms of zen1 on zen2 server? >> >> Not needed, this configuration will be copied to zen2 server on the >> moment of the cluster configuration, your configuration on node1 >> (where you are configuring the cluster) will be replicated to node2 >> >>> * Based on what rules zen cluster decide to do a failover? when an if is >>> disconnected? when the two server can't see each other on the cluster if? >>> Other? >> >> When you configured your cluster you selected one interface , on your >> case eth5, the cluster will be switched when the ucarp service >> (similar to heartbeat) don't detect connection between processes, over >> eth5 on two nodes, for example: cable disconnected, kernel panic on >> active node, reboot on active node, etc.. >> >>> * What happened to interfaces ip addresses when the cluster is up? Will I >>> still be able to connect to each server? On the management if? >> >> Oh yes, it is the best of the cluster service;), Im going to try >> explain more about this service: >> >> When you configure your cluster service you have to select one >> interface (eth5 on your case) this interface will be locked by the >> cluster, and this configuration will not be replicated. On this >> moment, we recommend access to zen over this interfaces, also, would >> be recommended configure the https gui service over this same >> interface. >> >> I just readed better your mails and I detected you used a cross over >> cable for cluster node, also this is other type or configuration, but >> with this, is neccesary that you selected one diferent interface for >> https gui service, (the https gui interface and the cluster interface >> will not be replicated to other node, and zen load balancer service >> don't stops this nics) >> >> >> You can select: >> >> case1: one interface for https gui and one diferent interface for >> cluster service >> case2: the same interface for cluster service and https gui service >> (this is recommended by us, because with this you need less NICs), but >> this is not your problem, feel free for use the case1. >> >> >> if you decide configure your cluster, you need: >> >> On node1: configure your farms, your interfaces, after select the gui >> nic and cluster nic, with the cluster active, you can configure and >> modify farms and nics without problem. >> On node2, select the gui nic and cluster nic. NOTHING ELSE. >> >> At the moment of cluster runs, tje cluster service going to replicate >> the configuration from node1 to node2, less, cluster nic and gui nic, >> farms and other nics (NO nic for https gui and nic for cluster) will >> be configured on node2 but down, waiting a fail on node1 for be >> started. >> >> With your cluster running, you only have to configure farms and >> interfaces on active node, on real time the configuration will be >> replicated to pasive node. >> >> I recommend you read more about cluster on "documentation section" on >> official website, you can see a logical schema for undertand the >> philosofy, and you can read steps by steps the cluster configuration. >> >> >> You have to understand: >> -Not needed configure farms and all interfaces on node2 >> -after cluster configuration you can follow configuring farms and >> nics, but on active node >> >> Once you configure the cluster, Zen decides the active node, depending >> the configuration type you selected, on https gui, you can see on the >> upper right zone the active and the pasive node. >> >> For more doubt, ask us ;) >> >> >> We are waiting your feedback >> >>> >>> Anyway attached the two zenloadbalancer.log files. >>> >>> Ciao. >>> Stefano. >>> >>> -----Messaggio originale----- >>> Da: Emilio Campos [mailto:[email protected]] >>> Inviato: lunedì 4 luglio 2011 16.09 >>> A: [email protected] >>> Oggetto: Re: [Zenloadbalancer-support] R: Zen Cluster, try #2 >>> >>> 1º Connect to the node2 >>> 2º Configure the eth5:cl virtual interface (not delete this >>> configuration on node1) >>> 3º From node2 follow the steps for configure the cluster on webgui >>> 4º and please, send me the file >>> /usr/local/zenloadbalancer/logs/zenloadbalancer.log of node1 and node2 >>> for study the problem >>> >>> I am waiting your test >>> >>> >>> Regards! >>> >>> 2011/7/4 Chiesa Stefano <[email protected]>: >>>> Hi Emilio. >>>> OK, we did a step forward, but: >>>> >>>> Cluster IP 172.16.18.3 is active on s-dr-zen Permission denied, please try >>>> again. Permission denied, please try again. Permission denied >>>> (publickey,password). >>>> Zen Inotify is running on Permission denied, please try again. Permission >>>> denied, please try again. Permission denied (publickey,password). >>>> >>>> I don't know if it's a root password issue, but I'm quite confident that >>>> is right because it's the same on the two zen server... >>>> >>>> Ciao. >>>> Stefano. >>>> >>>> >>>> -----Messaggio originale----- >>>> Da: Emilio Campos [mailto:[email protected]] >>>> Inviato: lunedì 4 luglio 2011 14.22 >>>> A: [email protected] >>>> Oggetto: Re: [Zenloadbalancer-support] Zen Cluster, try #2 >>>> >>>> Hi Stefano, on two nodes, delete all content of >>>> >>>> /root/.ssh/* >>>> >>>> Delete if exist: >>>> >>>> /usr/local/zenloadbalancer/config/cluster.conf >>>> >>>> on two nodes >>>> >>>> And try! >>>> >>>> >>>> We are waiting your feedback! >>>> Regard! >>>> >>>> 2011/7/4 Chiesa Stefano <[email protected]>: >>>>> Hello Laura, Emilio. >>>>> >>>>> After checks on if and routing, I'm trying to set up the cluster again. >>>>> When I try this are the messages: >>>>> >>>>> >>>>> "Zen latency is DOWN on s-dr-zen 172.16.18.1 | Zen latency is DOWN on >>>>> s-dr-zen2 172.16.18.2 >>>>> >>>>> Cluster IP 172.16.18.3 is active on s-dr-zen >>>>> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: >>>>> REMOTE HOST IDENTIFICATION HAS CHANGED! @ >>>>> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS >>>>> POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be >>>>> eavesdropping on you right now (man-in-the-middle attack)! It is also >>>>> possible that the RSA host key has just been changed. The fingerprint for >>>>> the RSA key sent by the remote host is >>>>> 04:0f:e7:24:98:4c:3a:19:80:38:c3:46:7b:d0:c5:14. Please contact your >>>>> system administrator. Add correct host key in /root/.ssh/known_hosts to >>>>> get rid of this message. Offending key in /root/.ssh/known_hosts:1 RSA >>>>> host key for 172.16.18.2 has changed and you have requested strict >>>>> checking. Host key verification failed. >>>>> >>>>> Zen Inotify is running on >>>>> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: >>>>> REMOTE HOST IDENTIFICATION HAS CHANGED! @ >>>>> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS >>>>> POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be >>>>> eavesdropping on you right now (man-in-the-middle attack)! It is also >>>>> possible that the RSA host key has just been changed. The fingerprint for >>>>> the RSA key sent by the remote host is >>>>> 04:0f:e7:24:98:4c:3a:19:80:38:c3:46:7b:d0:c5:14. Please contact your >>>>> system administrator. Add correct host key in /root/.ssh/known_hosts to >>>>> get rid of this message. Offending key in /root/.ssh/known_hosts:1 RSA >>>>> host key for 172.16.18.2 has changed and you have requested strict >>>>> checking. Host key verification failed. >>>>> " >>>>> >>>>> Virtual IP for Cluster: eth5:cl 172.16.18.3 >>>>> >>>>> s-dr-zen 172.16.18.1 >>>>> s-dr-zen2 172.16.18.2 >>>>> >>>>> I think It's only "garbage" coming from old test anche changes. >>>>> How can I CLEANUP the RSA configuration to avoid this message? >>>>> >>>>> Thanks. >>>>> >>>>> Stefano. >>>>> >>>>> >>>>> -----Messaggio originale----- >>>>> Da: Emilio Campos [mailto:[email protected]] >>>>> Inviato: lunedì 27 giugno 2011 0.38 >>>>> A: [email protected] >>>>> Oggetto: Re: [Zenloadbalancer-support] Zen Cluster >>>>> >>>>> on the other node, can you try the same configuration steps and >>>>> attach screenshots with the output? >>>>> >>>>> after, can you attach the >>>>> /usr/local/zenloadbalancer/logs/zenloadbalancer.log file (2 nodes) >>>>> >>>>> 2011/6/24 Chiesa Stefano <[email protected]>: >>>>>> Hello Emilio. >>>>>> >>>>>> After some good tests with a single server, I'm trying to set up the >>>>>> cluster. >>>>>> I follewed the instructions but I have some problems (attached print >>>>>> screens and errors). >>>>>> >>>>>> I set up an IF with a private address (172.16.18.x - s-dr-zen master >>>>>> 172.16.18.1 - s-dr-zen2 - slave 172.16.18.2) on eth5. >>>>>> I connected the two servers on eth5 with a cross cable. The two server >>>>>> can ping each other. >>>>>> >>>>>> If you need other info don't hesitate to ask. >>>>>> >>>>>> Thanks in advance. >>>>>> >>>>>> Ciao. >>>>>> Stefano. >>>>>> >>>>>> ---------------------------------------- >>>>>> Stefano Chiesa >>>>>> Wolters Kluwer Italia >>>>>> Strada 1, Palazzo F6 >>>>>> 20090 Milanofiori Assago (Mi) - Italia >>>>>> Phone +39 0282476279 (20279 Voip) >>>>>> Fax +39 0282476633 >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> 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-c1 >>>>>> _______________________________________________ >>>>>> Zenloadbalancer-support mailing list >>>>>> [email protected] >>>>>> https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Load balancer distribution - Open Source Project >>>>> http://zenloadbalancer.sourceforge.net >>>>> Distribution list (subscribe): >>>>> [email protected] >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> All of the data generated in your IT infrastructure is seriously valuable. >>>>> Why? It contains a definitive record of application performance, security >>>>> threats, fraudulent activity, and more. Splunk takes this data and makes >>>>> sense of it. IT sense. And common sense. >>>>> http://p.sf.net/sfu/splunk-d2d-c2 >>>>> _______________________________________________ >>>>> Zenloadbalancer-support mailing list >>>>> [email protected] >>>>> https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> All of the data generated in your IT infrastructure is seriously valuable. >>>>> Why? It contains a definitive record of application performance, security >>>>> threats, fraudulent activity, and more. Splunk takes this data and makes >>>>> sense of it. IT sense. And common sense. >>>>> http://p.sf.net/sfu/splunk-d2d-c2 >>>>> _______________________________________________ >>>>> Zenloadbalancer-support mailing list >>>>> [email protected] >>>>> https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support >>>>> >>>> >>>> >>>> >>>> -- >>>> Load balancer distribution - Open Source Project >>>> http://zenloadbalancer.sourceforge.net >>>> Distribution list (subscribe): >>>> [email protected] >>>> >>>> ------------------------------------------------------------------------------ >>>> All of the data generated in your IT infrastructure is seriously valuable. >>>> Why? It contains a definitive record of application performance, security >>>> threats, fraudulent activity, and more. Splunk takes this data and makes >>>> sense of it. IT sense. And common sense. >>>> http://p.sf.net/sfu/splunk-d2d-c2 >>>> _______________________________________________ >>>> Zenloadbalancer-support mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support >>>> >>>> ------------------------------------------------------------------------------ >>>> All of the data generated in your IT infrastructure is seriously valuable. >>>> Why? It contains a definitive record of application performance, security >>>> threats, fraudulent activity, and more. Splunk takes this data and makes >>>> sense of it. IT sense. And common sense. >>>> http://p.sf.net/sfu/splunk-d2d-c2 >>>> _______________________________________________ >>>> Zenloadbalancer-support mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support >>>> >>>> >>> >>> >>> >>> -- >>> Load balancer distribution - Open Source Project >>> http://zenloadbalancer.sourceforge.net >>> Distribution list (subscribe): [email protected] >>> >>> ------------------------------------------------------------------------------ >>> All of the data generated in your IT infrastructure is seriously valuable. >>> Why? It contains a definitive record of application performance, security >>> threats, fraudulent activity, and more. Splunk takes this data and makes >>> sense of it. IT sense. And common sense. >>> http://p.sf.net/sfu/splunk-d2d-c2 >>> _______________________________________________ >>> Zenloadbalancer-support mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support >>> >>> ------------------------------------------------------------------------------ >>> All of the data generated in your IT infrastructure is seriously valuable. >>> Why? It contains a definitive record of application performance, security >>> threats, fraudulent activity, and more. Splunk takes this data and makes >>> sense of it. IT sense. And common sense. >>> http://p.sf.net/sfu/splunk-d2d-c2 >>> _______________________________________________ >>> Zenloadbalancer-support mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support >>> >>> >> >> >> >> -- >> Load balancer distribution - Open Source Project >> http://zenloadbalancer.sourceforge.net >> Distribution list (subscribe): [email protected] >> > > > > -- > Load balancer distribution - Open Source Project > http://zenloadbalancer.sourceforge.net > Distribution list (subscribe): [email protected] > > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > _______________________________________________ > Zenloadbalancer-support mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support > > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > _______________________________________________ > Zenloadbalancer-support mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support > > -- Load balancer distribution - Open Source Project http://zenloadbalancer.sourceforge.net Distribution list (subscribe): [email protected] ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ Zenloadbalancer-support mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support
