Re: [ClusterLabs] Moving Related Servers
On 04/18/2016 02:34 AM, H Yavari wrote: > Hi, > > I have 4 CentOS servers (App1,App2.App3 and App4). I created a cluster > for App1 and App2 with a IP float and it works well. > In our infrastructure App1 works only with App3 and App2 only works with > App4. I mean we have 2 server sets (App1 and App3) , (App2 and App4). > So I want when server app1 is down and app2 will Online node, App3 will > offline too and App4 will Online and vice versa, I mean when App3 is > down and App4 will Online, App1 will offline too. > > > How can I do with pacemaker ? we have our self service on servers so how > can I user Pacemaker for monitoring these services? > > Thanks for reply. > > Regards. > H.Yavari I'm not sure I understand your requirements. There's no way to tell one node to leave the cluster when another node is down, and it would be a bad idea if you could: the nodes could never start up, because each would wait to see the other before starting; and in your cluster, two nodes shutting down would make the cluster lose quorum, so the other nodes would refuse to run any resources. However, it is usually possible to use constraints to enforce any desired behavior. So even those the node might not leave the cluster, you could make the cluster not place any resources on that node. Can you give more information about your resources and what nodes they are allowed to run on? What makes App1 and App3 dependent on each other? ___ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] Moving Related Servers
Hi, This is servers maps: App 3-> App 1 (Active) App 4 -> App 2 (Standby) Now App1 and App2 are in a cluster with IP failover. I need when IP failover will run and App2 will be Active node, service "X" on server App3 will be stop and App 4 will be Active node.In the other words, App1 works only with App3 and App 2 works with App 4. I have a web application on App1 and some services on App 3 (this is same for App2 and App 4) Sorry for heavy description. From: Ken Gaillot To: users@clusterlabs.org On 04/18/2016 02:34 AM, H Yavari wrote: > Hi, > > I have 4 CentOS servers (App1,App2.App3 and App4). I created a cluster > for App1 and App2 with a IP float and it works well. > In our infrastructure App1 works only with App3 and App2 only works with > App4. I mean we have 2 server sets (App1 and App3) , (App2 and App4). > So I want when server app1 is down and app2 will Online node, App3 will > offline too and App4 will Online and vice versa, I mean when App3 is > down and App4 will Online, App1 will offline too. > > > How can I do with pacemaker ? we have our self service on servers so how > can I user Pacemaker for monitoring these services? > > Thanks for reply. > > Regards. > H.Yavari I'm not sure I understand your requirements. There's no way to tell one node to leave the cluster when another node is down, and it would be a bad idea if you could: the nodes could never start up, because each would wait to see the other before starting; and in your cluster, two nodes shutting down would make the cluster lose quorum, so the other nodes would refuse to run any resources. However, it is usually possible to use constraints to enforce any desired behavior. So even those the node might not leave the cluster, you could make the cluster not place any resources on that node. Can you give more information about your resources and what nodes they are allowed to run on? What makes App1 and App3 dependent on each other? ___ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org ___ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] Moving Related Servers
On 04/18/2016 10:05 PM, H Yavari wrote: > Hi, > > This is servers maps: > > App 3-> App 1(Active) > > App 4 -> App 2 (Standby) > > > Now App1 and App2 are in a cluster with IP failover. > > I need when IP failover will run and App2 will be Active node, service > "X" on server App3 will be stop and App 4 will be Active node. > In the other words, App1 works only with App3 and App 2 works with App 4. > > I have a web application on App1 and some services on App 3 (this is > same for App2 and App 4) This is a difficult situation to model. In particular, you could only have a dependency one way -- so if we could get App 3 to fail over if App 1 fails, we couldn't model the other direction (App 1 failing over if App 3 fails). If each is dependent on the other, there's no way to start one first. Is there a technical reason App 3 can work only with App 1? Is it possible for service "X" to stay running on both App 3 and App 4 all the time? If so, this becomes easier. > > Sorry for heavy description. > > > > *From:* Ken Gaillot > *To:* users@clusterlabs.org > ** > On 04/18/2016 02:34 AM, H Yavari wrote: > >> Hi, >> >> I have 4 CentOS servers (App1,App2.App3 and App4). I created a cluster >> for App1 and App2 with a IP float and it works well. >> In our infrastructure App1 works only with App3 and App2 only works with >> App4. I mean we have 2 server sets (App1 and App3) , (App2 and App4). >> So I want when server app1 is down and app2 will Online node, App3 will >> offline too and App4 will Online and vice versa, I mean when App3 is >> down and App4 will Online, App1 will offline too. >> >> >> How can I do with pacemaker ? we have our self service on servers so how >> can I user Pacemaker for monitoring these services? >> >> Thanks for reply. >> >> Regards. >> H.Yavari > > > I'm not sure I understand your requirements. > > There's no way to tell one node to leave the cluster when another node > is down, and it would be a bad idea if you could: the nodes could never > start up, because each would wait to see the other before starting; and > in your cluster, two nodes shutting down would make the cluster lose > quorum, so the other nodes would refuse to run any resources. > > However, it is usually possible to use constraints to enforce any > desired behavior. So even those the node might not leave the cluster, > you could make the cluster not place any resources on that node. > > Can you give more information about your resources and what nodes they > are allowed to run on? What makes App1 and App3 dependent on each other? ___ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] Moving Related Servers
Hi, thanks for reply. Yes this is technical limitation because this makes many side effects. So do you think we can run a script on cluster (App1 and App2) then every time when the moving is happening, script run and stop service X on App 3 or App 4? From: Ken Gaillot To: H Yavari ; Cluster Labs - All topics related to open-source clustering welcomed On 04/18/2016 10:05 PM, H Yavari wrote: > Hi, > > This is servers maps: > > App 3-> App 1 (Active) > > App 4 -> App 2 (Standby) > > > Now App1 and App2 are in a cluster with IP failover. > > I need when IP failover will run and App2 will be Active node, service > "X" on server App3 will be stop and App 4 will be Active node. > In the other words, App1 works only with App3 and App 2 works with App 4. > > I have a web application on App1 and some services on App 3 (this is > same for App2 and App 4) This is a difficult situation to model. In particular, you could only have a dependency one way -- so if we could get App 3 to fail over if App 1 fails, we couldn't model the other direction (App 1 failing over if App 3 fails). If each is dependent on the other, there's no way to start one first. Is there a technical reason App 3 can work only with App 1? Is it possible for service "X" to stay running on both App 3 and App 4 all the time? If so, this becomes easier. > > Sorry for heavy description. > > > > *From:* Ken Gaillot > *To:* users@clusterlabs.org > ** > On 04/18/2016 02:34 AM, H Yavari wrote: > >> Hi, >> >> I have 4 CentOS servers (App1,App2.App3 and App4). I created a cluster >> for App1 and App2 with a IP float and it works well. >> In our infrastructure App1 works only with App3 and App2 only works with >> App4. I mean we have 2 server sets (App1 and App3) , (App2 and App4). >> So I want when server app1 is down and app2 will Online node, App3 will >> offline too and App4 will Online and vice versa, I mean when App3 is >> down and App4 will Online, App1 will offline too. >> >> >> How can I do with pacemaker ? we have our self service on servers so how >> can I user Pacemaker for monitoring these services? >> >> Thanks for reply. >> >> Regards. >> H.Yavari > > > I'm not sure I understand your requirements. > > There's no way to tell one node to leave the cluster when another node > is down, and it would be a bad idea if you could: the nodes could never > start up, because each would wait to see the other before starting; and > in your cluster, two nodes shutting down would make the cluster lose > quorum, so the other nodes would refuse to run any resources. > > However, it is usually possible to use constraints to enforce any > desired behavior. So even those the node might not leave the cluster, > you could make the cluster not place any resources on that node. > > Can you give more information about your resources and what nodes they > are allowed to run on? What makes App1 and App3 dependent on each other? ___ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] Moving Related Servers
On 04/19/2016 04:32 PM, Ken Gaillot wrote: > On 04/18/2016 10:05 PM, H Yavari wrote: >> Hi, >> >> This is servers maps: >> >> App 3-> App 1(Active) >> >> App 4 -> App 2 (Standby) >> >> >> Now App1 and App2 are in a cluster with IP failover. >> >> I need when IP failover will run and App2 will be Active node, service >> "X" on server App3 will be stop and App 4 will be Active node. >> In the other words, App1 works only with App3 and App 2 works with App 4. >> >> I have a web application on App1 and some services on App 3 (this is >> same for App2 and App 4) > This is a difficult situation to model. In particular, you could only > have a dependency one way -- so if we could get App 3 to fail over if > App 1 fails, we couldn't model the other direction (App 1 failing over > if App 3 fails). If each is dependent on the other, there's no way to > start one first. > > Is there a technical reason App 3 can work only with App 1? > > Is it possible for service "X" to stay running on both App 3 and App 4 > all the time? If so, this becomes easier. Just another try to understand what you are aiming for: You have a 2-node-cluster at the moment consisting of the nodes App1 & App2. You configured something like a master/slave-group to realize an active/standby scenario. To get the servers App3 & App4 into the game we would make them additional pacemaker-nodes (App3 & App4). You now have a service X that could be running either on App3 or App4 (which is easy by e.g. making it dependent on a node attribute) and it should be running on App3 when the service-group is active (master in pacemaker terms) on App1 and on App4 when the service-group is active on App2. The standard thing would be to collocate a service with the master-role (see all the DRBD examples for instance). We would now need a locate-x when master is located-y rule instead of collocation. I don't know any way to directly specify this. One - ugly though - way around I could imagine would be: - locate service X1 on App3 - locate service X2 on App4 - dummy service Y1 is located App1 and collocated with master-role - dummy service Y2 is located App2 and collocated with master-role - service X1 depends on Y1 - service X2 depends on Y2 If that somehow reflects your situation the key question now would probably be if pengine would make the group on App2 master if service X1 fails on App3. I would guess yes but I'm not sure. Regards, Klaus >> Sorry for heavy description. >> >> >> >> *From:* Ken Gaillot >> *To:* users@clusterlabs.org >> ** >> On 04/18/2016 02:34 AM, H Yavari wrote: >> >>> Hi, >>> >>> I have 4 CentOS servers (App1,App2.App3 and App4). I created a cluster >>> for App1 and App2 with a IP float and it works well. >>> In our infrastructure App1 works only with App3 and App2 only works with >>> App4. I mean we have 2 server sets (App1 and App3) , (App2 and App4). >>> So I want when server app1 is down and app2 will Online node, App3 will >>> offline too and App4 will Online and vice versa, I mean when App3 is >>> down and App4 will Online, App1 will offline too. >>> >>> >>> How can I do with pacemaker ? we have our self service on servers so how >>> can I user Pacemaker for monitoring these services? >>> >>> Thanks for reply. >>> >>> Regards. >>> H.Yavari >> >> I'm not sure I understand your requirements. >> >> There's no way to tell one node to leave the cluster when another node >> is down, and it would be a bad idea if you could: the nodes could never >> start up, because each would wait to see the other before starting; and >> in your cluster, two nodes shutting down would make the cluster lose >> quorum, so the other nodes would refuse to run any resources. >> >> However, it is usually possible to use constraints to enforce any >> desired behavior. So even those the node might not leave the cluster, >> you could make the cluster not place any resources on that node. >> >> Can you give more information about your resources and what nodes they >> are allowed to run on? What makes App1 and App3 dependent on each other? > > ___ > Users mailing list: Users@clusterlabs.org > http://clusterlabs.org/mailman/listinfo/users > > Project Home: http://www.clusterlabs.org > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf > Bugs: http://bugs.clusterlabs.org ___ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] Moving Related Servers
You got my situation right. But I couldn't find any method to do this? I should create one cluster with 4 node or 2 cluster with 2 node ? How I restrict the cluster nodes to each other!!? From: Klaus Wenninger To: users@clusterlabs.org Sent: Wednesday, 20 April 2016, 9:56:05 Subject: Re: [ClusterLabs] Moving Related Servers On 04/19/2016 04:32 PM, Ken Gaillot wrote: > On 04/18/2016 10:05 PM, H Yavari wrote: >> Hi, >> >> This is servers maps: >> >> App 3-> App 1 (Active) >> >> App 4 -> App 2 (Standby) >> >> >> Now App1 and App2 are in a cluster with IP failover. >> >> I need when IP failover will run and App2 will be Active node, service >> "X" on server App3 will be stop and App 4 will be Active node. >> In the other words, App1 works only with App3 and App 2 works with App 4. >> >> I have a web application on App1 and some services on App 3 (this is >> same for App2 and App 4) > This is a difficult situation to model. In particular, you could only > have a dependency one way -- so if we could get App 3 to fail over if > App 1 fails, we couldn't model the other direction (App 1 failing over > if App 3 fails). If each is dependent on the other, there's no way to > start one first. > > Is there a technical reason App 3 can work only with App 1? > > Is it possible for service "X" to stay running on both App 3 and App 4 > all the time? If so, this becomes easier. Just another try to understand what you are aiming for: You have a 2-node-cluster at the moment consisting of the nodes App1 & App2. You configured something like a master/slave-group to realize an active/standby scenario. To get the servers App3 & App4 into the game we would make them additional pacemaker-nodes (App3 & App4). You now have a service X that could be running either on App3 or App4 (which is easy by e.g. making it dependent on a node attribute) and it should be running on App3 when the service-group is active (master in pacemaker terms) on App1 and on App4 when the service-group is active on App2. The standard thing would be to collocate a service with the master-role (see all the DRBD examples for instance). We would now need a locate-x when master is located-y rule instead of collocation. I don't know any way to directly specify this. One - ugly though - way around I could imagine would be: - locate service X1 on App3 - locate service X2 on App4 - dummy service Y1 is located App1 and collocated with master-role - dummy service Y2 is located App2 and collocated with master-role - service X1 depends on Y1 - service X2 depends on Y2 If that somehow reflects your situation the key question now would probably be if pengine would make the group on App2 master if service X1 fails on App3. I would guess yes but I'm not sure. Regards, Klaus >> Sorry for heavy description. >> >> >> >> *From:* Ken Gaillot >> *To:* users@clusterlabs.org >> ** >> On 04/18/2016 02:34 AM, H Yavari wrote: >> >>> Hi, >>> >>> I have 4 CentOS servers (App1,App2.App3 and App4). I created a cluster >>> for App1 and App2 with a IP float and it works well. >>> In our infrastructure App1 works only with App3 and App2 only works with >>> App4. I mean we have 2 server sets (App1 and App3) , (App2 and App4). >>> So I want when server app1 is down and app2 will Online node, App3 will >>> offline too and App4 will Online and vice versa, I mean when App3 is >>> down and App4 will Online, App1 will offline too. >>> >>> >>> How can I do with pacemaker ? we have our self service on servers so how >>> can I user Pacemaker for monitoring these services? >>> >>> Thanks for reply. >>> >>> Regards. >>> H.Yavari >> >> I'm not sure I understand your requirements. >> >> There's no way to tell one node to leave the cluster when another node >> is down, and it would be a bad idea if you could: the nodes could never >> start up, because each would wait to see the other before starting; and >> in your cluster, two nodes shutting down would make the cluster lose >> quorum, so the other nodes would refuse to run any resources. >> >> However, it is usually possible to use constraints to enforce any >> desired behavior. So even those the node might not leave the cluster, >> you could make the cluster not place any resources on that node. >> >> Can you give more information about your resources and what nodes they >> are allowed to run on? What makes App1 and App3 depend
Re: [ClusterLabs] Moving Related Servers
On 04/20/2016 12:44 AM, H Yavari wrote: > You got my situation right. But I couldn't find any method to do this? > > I should create one cluster with 4 node or 2 cluster with 2 node ? How I > restrict the cluster nodes to each other!!? Your last questions made me think of multi-site clustering using booth. I think this might be the best solution for you. You can configure two independent pacemaker clusters of 2 nodes each, then use booth to ensure that one cluster has the resources at any time. See: http://clusterlabs.org/doc/en-US/Pacemaker/1.1-pcs/html-single/Pacemaker_Explained/index.html#idm140617279413776 This is usually done with clusters at physically separate locations, but there's no problem with using it with two clusters in one location. Alternatively, going along more traditional lines such as what Klaus and I have mentioned, you could use rules and node attributes to keep the resources where desired. You could write a custom resource agent that would set a custom node attribute for the matching node (the start action should set the attribute to 1, and the stop action should set the attribute to 0; if the resource was on App 1, you'd set the attribute for App 3, and if the resource was on App 4, you'd set the attribute for App 4). Colocate that resource with your floating IP, and use a rule to locate service X where the custom node attribute is 1. See: http://clusterlabs.org/doc/en-US/Pacemaker/1.1-pcs/html-single/Pacemaker_Explained/index.html#ap-ocf http://clusterlabs.org/doc/en-US/Pacemaker/1.1-pcs/html-single/Pacemaker_Explained/index.html#idm140617279376656 http://clusterlabs.org/doc/en-US/Pacemaker/1.1-pcs/html-single/Pacemaker_Explained/index.html#idm140617356537136 > > > *From:* Klaus Wenninger > *To:* users@clusterlabs.org > *Sent:* Wednesday, 20 April 2016, 9:56:05 > *Subject:* Re: [ClusterLabs] Moving Related Servers > > On 04/19/2016 04:32 PM, Ken Gaillot wrote: >> On 04/18/2016 10:05 PM, H Yavari wrote: >>> Hi, >>> >>> This is servers maps: >>> >>> App 3-> App 1(Active) >>> >>> App 4 -> App 2 (Standby) >>> >>> >>> Now App1 and App2 are in a cluster with IP failover. >>> >>> I need when IP failover will run and App2 will be Active node, service >>> "X" on server App3 will be stop and App 4 will be Active node. >>> In the other words, App1 works only with App3 and App 2 works with App 4. >>> >>> I have a web application on App1 and some services on App 3 (this is >>> same for App2 and App 4) >> This is a difficult situation to model. In particular, you could only >> have a dependency one way -- so if we could get App 3 to fail over if >> App 1 fails, we couldn't model the other direction (App 1 failing over >> if App 3 fails). If each is dependent on the other, there's no way to >> start one first. >> >> Is there a technical reason App 3 can work only with App 1? >> >> Is it possible for service "X" to stay running on both App 3 and App 4 >> all the time? If so, this becomes easier. > Just another try to understand what you are aiming for: > > You have a 2-node-cluster at the moment consisting of the nodes > App1 & App2. > You configured something like a master/slave-group to realize > an active/standby scenario. > > To get the servers App3 & App4 into the game we would make > them additional pacemaker-nodes (App3 & App4). > You now have a service X that could be running either on App3 or > App4 (which is easy by e.g. making it dependent on a node attribute) > and it should be running on App3 when the service-group is active > (master in pacemaker terms) on App1 and on App4 when the > service-group is active on App2. > > The standard thing would be to collocate a service with the master-role > (see all the DRBD examples for instance). > We would now need a locate-x when master is located-y rule instead > of collocation. > I don't know any way to directly specify this. > One - ugly though - way around I could imagine would be: > > - locate service X1 on App3 > - locate service X2 on App4 > - dummy service Y1 is located App1 and collocated with master-role > - dummy service Y2 is located App2 and collocated with master-role > - service X1 depends on Y1 > - service X2 depends on Y2 > > If that somehow reflects your situation the key question now would > probably be if pengine would make the group on App2 master > if service X1 fails on App3. I would guess yes but I'm not sure. > > Regards, > Klaus > >>> Sorry for heavy de
Re: [ClusterLabs] Moving Related Servers
On 04/20/2016 04:01 PM, Ken Gaillot wrote: > On 04/20/2016 12:44 AM, H Yavari wrote: >> You got my situation right. But I couldn't find any method to do this? >> >> I should create one cluster with 4 node or 2 cluster with 2 node ? How I >> restrict the cluster nodes to each other!!? > Your last questions made me think of multi-site clustering using booth. > I think this might be the best solution for you. > > You can configure two independent pacemaker clusters of 2 nodes each, > then use booth to ensure that one cluster has the resources at any time. > See: > > http://clusterlabs.org/doc/en-US/Pacemaker/1.1-pcs/html-single/Pacemaker_Explained/index.html#idm140617279413776 > > This is usually done with clusters at physically separate locations, but > there's no problem with using it with two clusters in one location. > > Alternatively, going along more traditional lines such as what Klaus and > I have mentioned, you could use rules and node attributes to keep the > resources where desired. You could write a custom resource agent that > would set a custom node attribute for the matching node (the start > action should set the attribute to 1, and the stop action should set the > attribute to 0; Thought of that as well but wasn't sure if pengine would get this kind of dependency and then switch the resources running on App2 to master if the resources on App3 would fail... With a real dependency I would rather guess that pengine would react as preferred in this case. > if the resource was on App 1, you'd set the attribute > for App 3, and if the resource was on App 4, you'd set the attribute for > App 4). Colocate that resource with your floating IP, and use a rule to > locate service X where the custom node attribute is 1. See: > > http://clusterlabs.org/doc/en-US/Pacemaker/1.1-pcs/html-single/Pacemaker_Explained/index.html#ap-ocf > > http://clusterlabs.org/doc/en-US/Pacemaker/1.1-pcs/html-single/Pacemaker_Explained/index.html#idm140617279376656 > > http://clusterlabs.org/doc/en-US/Pacemaker/1.1-pcs/html-single/Pacemaker_Explained/index.html#idm140617356537136 > >> ---------------- >> *From:* Klaus Wenninger >> *To:* users@clusterlabs.org >> *Sent:* Wednesday, 20 April 2016, 9:56:05 >> *Subject:* Re: [ClusterLabs] Moving Related Servers >> >> On 04/19/2016 04:32 PM, Ken Gaillot wrote: >>> On 04/18/2016 10:05 PM, H Yavari wrote: >>>> Hi, >>>> >>>> This is servers maps: >>>> >>>> App 3-> App 1(Active) >>>> >>>> App 4 -> App 2 (Standby) >>>> >>>> >>>> Now App1 and App2 are in a cluster with IP failover. >>>> >>>> I need when IP failover will run and App2 will be Active node, service >>>> "X" on server App3 will be stop and App 4 will be Active node. >>>> In the other words, App1 works only with App3 and App 2 works with App 4. >>>> >>>> I have a web application on App1 and some services on App 3 (this is >>>> same for App2 and App 4) >>> This is a difficult situation to model. In particular, you could only >>> have a dependency one way -- so if we could get App 3 to fail over if >>> App 1 fails, we couldn't model the other direction (App 1 failing over >>> if App 3 fails). If each is dependent on the other, there's no way to >>> start one first. >>> >>> Is there a technical reason App 3 can work only with App 1? >>> >>> Is it possible for service "X" to stay running on both App 3 and App 4 >>> all the time? If so, this becomes easier. >> Just another try to understand what you are aiming for: >> >> You have a 2-node-cluster at the moment consisting of the nodes >> App1 & App2. >> You configured something like a master/slave-group to realize >> an active/standby scenario. >> >> To get the servers App3 & App4 into the game we would make >> them additional pacemaker-nodes (App3 & App4). >> You now have a service X that could be running either on App3 or >> App4 (which is easy by e.g. making it dependent on a node attribute) >> and it should be running on App3 when the service-group is active >> (master in pacemaker terms) on App1 and on App4 when the >> service-group is active on App2. >> >> The standard thing would be to collocate a service with the master-role >> (see all the DRBD examples for instance). >> We would now need a locate-x when master is located-y rule instead >> of coll
Re: [ClusterLabs] Moving Related Servers
Hi, Thanks for your offer. I checked this and this is a amazing solution.So I defined two cluster : testcluster1:App1App2resource : IP float testcluster2:App3App4 resource : tomcat I know that we need to grant a ticket and manage that with Booth. But I couldn't understand how should I define a ticket and relation of nodes and clusters with the ticket. I read the mentioned doc, but I missed up. Can you give me one example? Thanks so. From: Ken Gaillot On 04/20/2016 12:44 AM, H Yavari wrote: > You got my situation right. But I couldn't find any method to do this? > > I should create one cluster with 4 node or 2 cluster with 2 node ? How I > restrict the cluster nodes to each other!!? Your last questions made me think of multi-site clustering using booth. I think this might be the best solution for you. You can configure two independent pacemaker clusters of 2 nodes each, then use booth to ensure that one cluster has the resources at any time. See: http://clusterlabs.org/doc/en-US/Pacemaker/1.1-pcs/html-single/Pacemaker_Explained/index.html#idm140617279413776 This is usually done with clusters at physically separate locations, but there's no problem with using it with two clusters in one location. Alternatively, going along more traditional lines such as what Klaus and I have mentioned, you could use rules and node attributes to keep the resources where desired. You could write a custom resource agent that would set a custom node attribute for the matching node (the start action should set the attribute to 1, and the stop action should set the attribute to 0; if the resource was on App 1, you'd set the attribute for App 3, and if the resource was on App 4, you'd set the attribute for App 4). Colocate that resource with your floating IP, and use a rule to locate service X where the custom node attribute is 1. See: http://clusterlabs.org/doc/en-US/Pacemaker/1.1-pcs/html-single/Pacemaker_Explained/index.html#ap-ocf http://clusterlabs.org/doc/en-US/Pacemaker/1.1-pcs/html-single/Pacemaker_Explained/index.html#idm140617279376656 http://clusterlabs.org/doc/en-US/Pacemaker/1.1-pcs/html-single/Pacemaker_Explained/index.html#idm140617356537136 > > > *From:* Klaus Wenninger > *To:* users@clusterlabs.org > *Sent:* Wednesday, 20 April 2016, 9:56:05 > *Subject:* Re: [ClusterLabs] Moving Related Servers > > On 04/19/2016 04:32 PM, Ken Gaillot wrote: >> On 04/18/2016 10:05 PM, H Yavari wrote: >>> Hi, >>> >>> This is servers maps: >>> >>> App 3-> App 1 (Active) >>> >>> App 4 -> App 2 (Standby) >>> >>> >>> Now App1 and App2 are in a cluster with IP failover. >>> >>> I need when IP failover will run and App2 will be Active node, service >>> "X" on server App3 will be stop and App 4 will be Active node. >>> In the other words, App1 works only with App3 and App 2 works with App 4. >>> >>> I have a web application on App1 and some services on App 3 (this is >>> same for App2 and App 4) >> This is a difficult situation to model. In particular, you could only >> have a dependency one way -- so if we could get App 3 to fail over if >> App 1 fails, we couldn't model the other direction (App 1 failing over >> if App 3 fails). If each is dependent on the other, there's no way to >> start one first. >> >> Is there a technical reason App 3 can work only with App 1? >> >> Is it possible for service "X" to stay running on both App 3 and App 4 >> all the time? If so, this becomes easier. > Just another try to understand what you are aiming for: > > You have a 2-node-cluster at the moment consisting of the nodes > App1 & App2. > You configured something like a master/slave-group to realize > an active/standby scenario. > > To get the servers App3 & App4 into the game we would make > them additional pacemaker-nodes (App3 & App4). > You now have a service X that could be running either on App3 or > App4 (which is easy by e.g. making it dependent on a node attribute) > and it should be running on App3 when the service-group is active > (master in pacemaker terms) on App1 and on App4 when the > service-group is active on App2. > > The standard thing would be to collocate a service with the master-role > (see all the DRBD examples for instance). > We would now need a locate-x when master is located-y rule instead > of collocation. > I don't know any way to directly specify this. > One - ugly though - way around I could imagine would be: > > - locate service X1 on App3 > - locate service X2 on App4 > - dummy
Re: [ClusterLabs] Moving Related Servers
Hi, Thanks for your offer. I checked this and this is a amazing solution.So I defined two cluster : testcluster1:App1App2resource : IP float testcluster2:App3App4 resource : tomcat I know that we need to grant a ticket and manage that with Booth. But I couldn't understand how should I define a ticket and relation of nodes and clusters with the ticket. I read the mentioned doc, but I missed up. Can you give me one example? Thanks so. From: Ken Gaillot On 04/20/2016 12:44 AM, H Yavari wrote: > You got my situation right. But I couldn't find any method to do this? > > I should create one cluster with 4 node or 2 cluster with 2 node ? How I > restrict the cluster nodes to each other!!? Your last questions made me think of multi-site clustering using booth. I think this might be the best solution for you. You can configure two independent pacemaker clusters of 2 nodes each, then use booth to ensure that one cluster has the resources at any time. See: http://clusterlabs.org/doc/en-US/Pacemaker/1.1-pcs/html-single/Pacemaker_Explained/index.html#idm140617279413776 This is usually done with clusters at physically separate locations, but there's no problem with using it with two clusters in one location. Alternatively, going along more traditional lines such as what Klaus and I have mentioned, you could use rules and node attributes to keep the resources where desired. You could write a custom resource agent that would set a custom node attribute for the matching node (the start action should set the attribute to 1, and the stop action should set the attribute to 0; if the resource was on App 1, you'd set the attribute for App 3, and if the resource was on App 4, you'd set the attribute for App 4). Colocate that resource with your floating IP, and use a rule to locate service X where the custom node attribute is 1. See: http://clusterlabs.org/doc/en-US/Pacemaker/1.1-pcs/html-single/Pacemaker_Explained/index.html#ap-ocf http://clusterlabs.org/doc/en-US/Pacemaker/1.1-pcs/html-single/Pacemaker_Explained/index.html#idm140617279376656 http://clusterlabs.org/doc/en-US/Pacemaker/1.1-pcs/html-single/Pacemaker_Explained/index.html#idm140617356537136 > > > *From:* Klaus Wenninger > *To:* users@clusterlabs.org > *Sent:* Wednesday, 20 April 2016, 9:56:05 > *Subject:* Re: [ClusterLabs] Moving Related Servers > > On 04/19/2016 04:32 PM, Ken Gaillot wrote: >> On 04/18/2016 10:05 PM, H Yavari wrote: >>> Hi, >>> >>> This is servers maps: >>> >>> App 3-> App 1 (Active) >>> >>> App 4 -> App 2 (Standby) >>> >>> >>> Now App1 and App2 are in a cluster with IP failover. >>> >>> I need when IP failover will run and App2 will be Active node, service >>> "X" on server App3 will be stop and App 4 will be Active node. >>> In the other words, App1 works only with App3 and App 2 works with App 4. >>> >>> I have a web application on App1 and some services on App 3 (this is >>> same for App2 and App 4) >> This is a difficult situation to model. In particular, you could only >> have a dependency one way -- so if we could get App 3 to fail over if >> App 1 fails, we couldn't model the other direction (App 1 failing over >> if App 3 fails). If each is dependent on the other, there's no way to >> start one first. >> >> Is there a technical reason App 3 can work only with App 1? >> >> Is it possible for service "X" to stay running on both App 3 and App 4 >> all the time? If so, this becomes easier. > Just another try to understand what you are aiming for: > > You have a 2-node-cluster at the moment consisting of the nodes > App1 & App2. > You configured something like a master/slave-group to realize > an active/standby scenario. > > To get the servers App3 & App4 into the game we would make > them additional pacemaker-nodes (App3 & App4). > You now have a service X that could be running either on App3 or > App4 (which is easy by e.g. making it dependent on a node attribute) > and it should be running on App3 when the service-group is active > (master in pacemaker terms) on App1 and on App4 when the > service-group is active on App2. > > The standard thing would be to collocate a service with the master-role > (see all the DRBD examples for instance). > We would now need a locate-x when master is located-y rule instead > of collocation. > I don't know any way to directly specify this. > One - ugly though - way around I could imagine would be: > > - locate service X1 on App3 > - locate service X2 on App4 >