On 03/22/2017 11:23 AM, Nikhil Utane wrote: > Hi Ulrich, > > It's not an option unfortunately. > Our product runs on a specialized hardware and provides both the > services (A & B) that I am referring to. Hence I cannot have service A > running on some nodes as cluster A and service B running on other > nodes as cluster B. > The two services HAVE to run on same node. The catch being service A > and service B have to be independent of each other. > > Hence looking at Container option since we are using that for some > other product (but not for Pacemaker/Corosync).
I don't know what the official statements are but I have been running up to 15 Pacemaker (1.1.10)/Corosync-Instances(1.4.7) with a product years ago using lxc (basically as docker using the namespaces the linux-kernel provides) and that worked fairly well. I just had to allow a certain CPU-percentage within a container to be RT-scheduled for corosync to start properly. Maybe you could tackle the fencing issue Ulrich has addressed by introduction of 2 fencing-levels. The 1st one going for docker-instances and the 2nd (lower prio) going for the nodes. So as long as fencing the container does the trick the 2nd cluster won't be involved and once this doesn't work it will go for the node itself and you will suffer from the probably anyway inevitable consequences. Regards, Klaus > > -Regards > Nikhil > > > On Wed, Mar 22, 2017 at 12:41 PM, Ulrich Windl > <ulrich.wi...@rz.uni-regensburg.de > <mailto:ulrich.wi...@rz.uni-regensburg.de>> wrote: > > >>> Nikhil Utane <nikhil.subscri...@gmail.com > <mailto:nikhil.subscri...@gmail.com>> schrieb am 22.03.2017 um > 07:48 in > Nachricht > <CAGNWmJV05-YG+f9VNG0Deu-2xo7Lp+kRQPOn9sWYy7Jz=0g...@mail.gmail.com > <mailto:0g...@mail.gmail.com>>: > > Hi All, > > > > First of all, let me thank everyone here for providing excellent > support > > from the time I started evaluating this tool about a year ago. > It has > > helped me to make a timely and good quality release of our > Redundancy > > solution using Pacemaker & Corosync. (Three cheers :)) > > > > Now for our next release we have a slightly different ask. > > We want to provide Redundancy to two different types of services > (we can > > call them Service A and Service B) such that all cluster > communication for > > Service A happens on one network/interface (say VLAN A) and for > service B > > happens on a different network/interface (say VLAN B). Moreover > we do not > > want the details of Service A (resource attributes etc) to be > seen by > > Service B and vice-versa. > > > > So essentially we want to be able to run two independent > clusters. From > > what I gathered, we cannot run multiple instances of Pacemaker > and Corosync > > on same node. I was thinking if we can use Containers and run > two isolated > > You conclude from two services that should not see each other that > you need to instances of pacemaker on one node. Why? > If you want true separation, drop the VLANs, make real networks > and two independent clusters. > Even if two pacemeaker on one node would work, you habe the > problem of fencing, where at least one pacemaker instance will > always be surprised badly if fencing takes place. I cannot imaging > you want that! > > > instances of Pacemaker + Corosync on same node. > > As per https://github.com/davidvossel/pacemaker_docker > <https://github.com/davidvossel/pacemaker_docker> it looks do-able. > > I wanted to get an opinion on this forum before I can commit > that it can be > > done. > > Why are you designing it more complicated as necessary? > > > > > Please share your views if you have already done this and if > there are any > > known challenges that I should be familiar with. > > > > -Thanks > > Nikhil > > > > > > _______________________________________________ > Users mailing list: Users@clusterlabs.org > <mailto:Users@clusterlabs.org> > http://lists.clusterlabs.org/mailman/listinfo/users > <http://lists.clusterlabs.org/mailman/listinfo/users> > > Project Home: http://www.clusterlabs.org > Getting started: > http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf > <http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf> > Bugs: http://bugs.clusterlabs.org > > > > > _______________________________________________ > Users mailing list: Users@clusterlabs.org > http://lists.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://lists.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
