Thanks Emilio, I'll let you know. -----Messaggio originale----- Da: Emilio Campos [mailto:[email protected]] Inviato: martedì 5 luglio 2011 11.31 A: [email protected] Oggetto: Re: [Zenloadbalancer-support] R: R: R: Zen Cluster, try #2
For eth5 with problems or some interface with problems , on gui: stop and start the interface (this going to reconfigure the interfaces on system) on gui Server > interfaces, after write the commands that laura sended you! Try and tell us! 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 ------------------------------------------------------------------------------ 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
