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] ------------------------------------------------------------------------------ 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
