Thanks a bunch for the advice, but finally is easier than I thought, I will simply use a different configuration for each apache server, but still maintaning replication via DRBD (DB/FS).
Again, thanks for the reply @Dimitri. Hugs from Chile!! *---* *Ronny Machado C.* * IT Consultant* * +569 75199262* ** <http://www.aaconsultoria.cl/> On 1 December 2016 at 08:00, <users-requ...@clusterlabs.org> wrote: > Send Users mailing list submissions to > users@clusterlabs.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://clusterlabs.org/mailman/listinfo/users > or, via email, send a message with subject or body 'help' to > users-requ...@clusterlabs.org > > You can reach the person managing the list at > users-ow...@clusterlabs.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Users digest..." > > > Today's Topics: > > 1. Re: ocf:heartbeat:IPaddr2 - Different network segment > (Dimitri Maziuk) > 2. Re: ocf:heartbeat:IPaddr2 - Different network segment > (Dimitri Maziuk) > 3. Pacemaker 1.1.16 released (Ken Gaillot) > 4. Re: Antw: Re: Set a node attribute for multiple nodes with > one command (Ken Gaillot) > 5. Deleting a variable (Ulrich Windl) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 30 Nov 2016 12:19:03 -0600 > From: Dimitri Maziuk <dmaz...@bmrb.wisc.edu> > To: users@clusterlabs.org > Subject: Re: [ClusterLabs] ocf:heartbeat:IPaddr2 - Different network > segment > Message-ID: <057788d3-be24-05c9-c8bd-190237057...@bmrb.wisc.edu> > Content-Type: text/plain; charset="utf-8" > > On 11/30/2016 09:10 AM, Ronny Machado C. wrote: > ...any advice on how to > > use ocf:heartbeat:IPaddr2 ip=x.x.x.x but in different segments, maybe is > > super easy, but right now I can't find out how. > > ICBW but if you bring up an ip in the wrong segment, it'll just be > unroutable/unreachable. As long as outgoing packets don't have it as > their from address, you should be fine. > > I.e. just have both ips up on either node and see what happens. > > -- > Dimitri Maziuk > Programmer/sysadmin > BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 190 bytes > Desc: OpenPGP digital signature > URL: <http://clusterlabs.org/pipermail/users/attachments/ > 20161130/2ad706d5/attachment-0001.sig> > > ------------------------------ > > Message: 2 > Date: Wed, 30 Nov 2016 12:24:05 -0600 > From: Dimitri Maziuk <dmaz...@bmrb.wisc.edu> > To: users@clusterlabs.org > Subject: Re: [ClusterLabs] ocf:heartbeat:IPaddr2 - Different network > segment > Message-ID: <d000f619-a395-1379-0259-5e0f05dfd...@bmrb.wisc.edu> > Content-Type: text/plain; charset="utf-8" > > PS you could probably use iptables to block/log outgoing traffic from > the wrong ip (different on each node) to be really really sure. > > -- > Dimitri Maziuk > Programmer/sysadmin > BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 190 bytes > Desc: OpenPGP digital signature > URL: <http://clusterlabs.org/pipermail/users/attachments/ > 20161130/2a0fc3be/attachment-0001.sig> > > ------------------------------ > > Message: 3 > Date: Wed, 30 Nov 2016 14:05:19 -0600 > From: Ken Gaillot <kgail...@redhat.com> > To: Cluster Labs - All topics related to open-source clustering > welcomed <users@clusterlabs.org> > Subject: [ClusterLabs] Pacemaker 1.1.16 released > Message-ID: <b2510d57-79f4-927f-8315-67d81f039...@redhat.com> > Content-Type: text/plain; charset=utf-8 > > ClusterLabs is proud to announce the latest release of the Pacemaker > cluster resource manager, version 1.1.15. The source code is available at: > > https://github.com/ClusterLabs/pacemaker/releases/tag/Pacemaker-1.1.16 > The most significant enhancements in this release are: > > * rsc-pattern may now be used instead of rsc in location constraints, to > allow a single location constraint to apply to all resources whose names > match a regular expression. Sed-like %0 - %9 backreferences let > submatches be used in node attribute names in rules. > > * The new ocf:pacemaker:attribute resource agent sets a node attribute > according to whether the resource is running or stopped. This may be > useful in combination with attribute-based rules to model dependencies > that simple constraints can't handle. > > * Pacemaker's existing "node health" feature allows resources to move > off nodes that become unhealthy. Now, when using > node-health-strategy=progressive, a new cluster property > node-health-base will be used as the initial health score of newly > joined nodes (defaulting to 0, which is the previous behavior). This > allows a node to be treated as "healthy" even if it has some "yellow" > health attributes, which can be useful to allow clones to run on such > nodes. > > * Previously, the OCF_RESKEY_CRM_meta_notify_active_* variables were not > properly passed to multistate resources with notification enabled. This > has been fixed. To help resource agents detect when the fix is > available, the CRM feature set has been incremented. (Whenever the > feature set changes, mixed-version clusters are supported only during > rolling upgrades -- nodes with an older version will not be allowed to > rejoin once they shut down.) > > * Watchdog-based fencing using sbd now works better on remote nodes. > This capability still likely has some limitations, however. > > * The build process now takes advantage of various compiler features > (RELRO, PIE, as-needed linking, etc.) that enhance security and start-up > performance. See the "Hardening flags" comments in the configure.ac file > for more details. > > * Python 3 compatibility: The Pacemaker project now targets > compatibility with both python 2 (versions 2.6 and later) and python 3 > (versions 3.2 and later). All of the project's python code now meets > this target, with the exception of CTS, which is still python 2 only. > > * The Pacemaker coding guidelines have been replaced by a more > comprehensive addition to the documentation set, "Pacemaker > Development". It is intended for developers working on the Pacemaker > code base itself, rather than external code such as resource agents. A > copy is viewable at > http://clusterlabs.org/doc/en-US/Pacemaker/1.1-pcs/html- > single/Pacemaker_Development/ > > As usual, the release includes many bugfixes, including a fix for a > serious security vulnerability (CVE-2016-7035). For a more detailed list > of changes, see the change log: > > https://github.com/ClusterLabs/pacemaker/blob/1.1/ChangeLog > > Many thanks to all contributors of source code to this release, > including Andrew Beekhof, Bin Liu, Christian Schneider, Christoph Berg, > David Shane Holden, Ferenc W?gner, Yan Gao, Hideo Yamauchi, Jan Pokorn?, > Ken Gaillot, Klaus Wenninger, Kostiantyn Ponomarenko, Kristoffer > Gr?nlund, Lars Ellenberg, Masatake Yamato, Michal Koutn?, Nakahira > Kazutomo, Nate Clark, Nishanth Aravamudan, Oyvind Albrigtsen, Ruben > Kerkhof, Tim Bishop, Vladislav Bogdanov and Yusuke Iida. Apologies if I > have overlooked anyone. > -- > Ken Gaillot <kgail...@redhat.com> > > > > ------------------------------ > > Message: 4 > Date: Wed, 30 Nov 2016 14:39:27 -0600 > From: Ken Gaillot <kgail...@redhat.com> > To: Kostiantyn Ponomarenko <konstantin.ponomare...@gmail.com> > Cc: Cluster Labs - All topics related to open-source clustering > welcomed <users@clusterlabs.org> > Subject: Re: [ClusterLabs] Antw: Re: Set a node attribute for multiple > nodes with one command > Message-ID: <62cb811f-4396-ff36-ec03-67000b4ed...@redhat.com> > Content-Type: text/plain; charset=utf-8 > > On 11/30/2016 11:31 AM, Kostiantyn Ponomarenko wrote: > > Hi Ken, > > > > I didn't look into the logs, but I experimented with it for a while. > > Here is what I found. > > > > It worked for you because this attribute - "my-attr" - has not ever been > > set before in that cluster. > > > > So if you set an attribute, then remove it, and then set it with > > "--delay", like: > > > > # attrd_updater -N node-0 -n my-attr --update false --delay 20 > > > > , this delay (dampening) won't work. > > Once set, attributes are not truly deleted -- only their values are > cleared. And --delay has no effect with --update if the attribute > already exists, which is what you see above. > > To set a delay on an already existing attribute, you have to use > attrd_updater --update-delay or --update-both. > > > Moreover, when you delete this attribute the actual remove will be > > delayed by that "--delay" which was used when the attribute was set. > > > > > > Thank you, > > Kostia > > > > On Tue, Nov 29, 2016 at 1:08 AM, Ken Gaillot <kgail...@redhat.com > > <mailto:kgail...@redhat.com>> wrote: > > > > On 11/24/2016 05:24 AM, Kostiantyn Ponomarenko wrote: > > > Attribute dampening doesn't work for me also. > > > To test that I have a script: > > > > > > attrd_updater -N node-0 -n my-attr --update false --delay 20 > > > sleep 3 > > > attrd_updater -N node-0 -n my-attr --update true > > > sleep 7 > > > attrd_updater -N node-1 -n my-attr --update true > > > > This sequence works for me -- the attributes are not written to the > live > > CIB until the end of the delay, when both are written at the same > time. > > > > The remaining issue must be with the policy engine. You could look at > > the detail log on the DC when these changes were made; you should see > > info-level messages with the CIB change with both values together > (lines > > with "cib_perform_op: ++" and the attribute values), then > "Transition > > aborted" with "Transient attribute change", then a bunch of > "pengine:" > > lines saying what the cluster wants to do with each resource. > > > > There should be some information about the scores used to place the > > resources. > > > > > > > > All my resources have this rule in Pacemaker config: > > > > > > crm configure location res1-location-rule res1 \ > > > rule 0: my-attr eq true \ > > > rule -inf: my-attr ne true > > > > > > On a working two-node cluster I remove "my-attr" from both nodes. > > > Then run my script. And all resources start on node-0. > > > Am I doing something wrong? > > > Or maybe my understanding of an attribute dampening is not correct? > > > > > > My Pacemaker version is 1.1.13. (heh, not the last one, but it is > what > > > it is ...) > > > > > > Thank you, > > > Kostia > > > > > > On Wed, Nov 23, 2016 at 7:27 PM, Kostiantyn Ponomarenko > > > <konstantin.ponomare...@gmail.com > > <mailto:konstantin.ponomare...@gmail.com> > > > <mailto:konstantin.ponomare...@gmail.com > > <mailto:konstantin.ponomare...@gmail.com>>> wrote: > > > > > > Maybe I am doing something wrong, but I cannot set "status" > section > > > node attributes to a shadow cib, cluster applies them > immediately. > > > To try it out I do in a console: > > > > > > crm_shadow --create test > > > crm_attribute --type nodes --node node-0 --name > my-attribute > > > --update 1 --lifetime=reboot > > > > > > And this attribute is set to the live cluster configuration > immediately. > > > What am I doing wrong? > > > > > > Thank you, > > > Kostia > > > > > > On Tue, Nov 22, 2016 at 11:33 PM, Kostiantyn Ponomarenko > > > <konstantin.ponomare...@gmail.com > > <mailto:konstantin.ponomare...@gmail.com> > > > <mailto:konstantin.ponomare...@gmail.com > > <mailto:konstantin.ponomare...@gmail.com>>> wrote: > > > > > > Ken, > > > Thank you for the explanation. > > > I will try this low-level way of shadow cib creation > tomorrow. > > > PS: I will sleep much better with this excellent > news/idea. =) > > > > > > Thank you, > > > Kostia > > > > > > On Tue, Nov 22, 2016 at 10:53 PM, Ken Gaillot > > > <kgail...@redhat.com <mailto:kgail...@redhat.com> > > <mailto:kgail...@redhat.com <mailto:kgail...@redhat.com>>> wrote: > > > > > > On 11/22/2016 04:39 AM, Kostiantyn Ponomarenko wrote: > > > > Using "shadow cib" in crmsh looks like a good idea, > but it doesn't work > > > > with node attributes set into "status" section of > Pacemaker config. > > > > I wonder it it is possible to make it work that way. > > > > > > Forgot to mention -- the shadow CIB is probably the > best way > > > to do this. > > > I don't know if there's a way to do it in crmsh, but > you can > > > use it with > > > the low-level commands crm_shadow and crm_attribute > > > --lifetime=reboot. > > > > > > > Ken, > > > >>> start dampening timer > > > > Could you please elaborate more on this. I don't get > how I can set this > > > > timer. > > > > Do I need to set this timer for each node? > > > > > > > > > > > > Thank you, > > > > Kostia > > > > > > > > On Mon, Nov 21, 2016 at 9:30 AM, Ulrich Windl > > > > <ulrich.wi...@rz.uni-regensburg.de > > <mailto:ulrich.wi...@rz.uni-regensburg.de> > > > <mailto:ulrich.wi...@rz.uni-regensburg.de > > <mailto:ulrich.wi...@rz.uni-regensburg.de>> > > > > <mailto:ulrich.wi...@rz.uni-regensburg.de > > <mailto:ulrich.wi...@rz.uni-regensburg.de> > > > <mailto:ulrich.wi...@rz.uni-regensburg.de > > <mailto:ulrich.wi...@rz.uni-regensburg.de>>>> wrote: > > > > > > > > >>> Ken Gaillot <kgail...@redhat.com <mailto: > kgail...@redhat.com> > > > <mailto:kgail...@redhat.com > > <mailto:kgail...@redhat.com>> <mailto:kgail...@redhat.com > > <mailto:kgail...@redhat.com> > > > <mailto:kgail...@redhat.com <mailto: > kgail...@redhat.com>>>> > > > > schrieb am 18.11.2016 um 16:17 in Nachricht > > > > <d6f449da-64f8-12ad-00be-e772d8e38...@redhat.com > > <mailto:d6f449da-64f8-12ad-00be-e772d8e38...@redhat.com> > > > <mailto:d6f449da-64f8-12ad- > 00be-e772d8e38...@redhat.com > > <mailto:d6f449da-64f8-12ad-00be-e772d8e38...@redhat.com>> > > > > > > > > > <mailto:d6f449da-64f8-12ad-00be-e772d8e38...@redhat.com > > <mailto:d6f449da-64f8-12ad-00be-e772d8e38...@redhat.com> > > > > > <mailto:d6f449da-64f8-12ad-00be-e772d8e38...@redhat.com > > <mailto:d6f449da-64f8-12ad-00be-e772d8e38...@redhat.com>>>>: > > > > > On 11/18/2016 08:55 AM, Kostiantyn Ponomarenko > > wrote: > > > > >> Hi folks, > > > > >> > > > > >> Is there a way to set a node attribute to the > > > "status" section for few > > > > >> nodes at the same time? > > > > >> > > > > >> In my case there is a node attribute which > allows > > > some resources to > > > > >> start in the cluster if it is set. > > > > >> If I set this node attribute for say two > > nodes in a > > > way - one and then > > > > >> another, than these resources are not > distributed > > > equally between these > > > > >> two nodes. That because Pacemaker picks the > first > > > node to with this > > > > >> attribute is set and immediately starts all > > allowed > > > resources on it. And > > > > >> this is not the behavior i would like to get. > > > > >> > > > > >> Thank you, > > > > >> Kostia > > > > > > > > > > Not that I know of, but it would be a good > feature > > > to add to > > > > > attrd_updater and/or crm_attribute. > > > > > > > > With crm (shell) you don't have transactions for > > node > > > attributes, > > > > but for the configuration. So if you add a > location > > > restriction > > > > preventing any resources on your nodes, then > enable > > > the nodes, and > > > > then delete the location restrictions in one > > > transaction, you might > > > > get what you want. It's not elegant, but itt ill > do. > > > > > > > > To the crm shell maintainer: Is is difficult to > > build > > > transactions > > > > to node status changes? The problem I see is > > this: For > > > configuration > > > > you always have transactions (requiring > > "commit), but > > > for nodes you > > > > traditionally have non (effects are immediate). > So > > > you'd need a > > > > thing like "start transaction" which requires a > > > "commit" or some > > > > kind of abort later. > > > > > > > > I also don't know whether a "shadow CIB" would > help > > > for the original > > > > problem. > > > > > > > > Ulrich > > > > > > > > > > > > > > You can probably hack it with a dampening > > value of a > > > few seconds. If > > > > > your rule checks for a particular value of the > > > attribute, set all the > > > > > nodes to a different value first, which will > write > > > that value and > > > > start > > > > > the dampening timer. Then set all the > > attributes to > > > the desired value, > > > > > and they will get written out together when the > > > timer expires. > > > > ------------------------------ > > Message: 5 > Date: Thu, 01 Dec 2016 08:15:52 +0100 > From: "Ulrich Windl" <ulrich.wi...@rz.uni-regensburg.de> > To: <kgail...@redhat.com> > Cc: users@clusterlabs.org > Subject: [ClusterLabs] Deleting a variable > Message-ID: <583fdc38020000a100023...@gwsmtp1.uni-regensburg.de> > Content-Type: text/plain; charset=US-ASCII > > >>> Ken Gaillot <kgail...@redhat.com> schrieb am 30.11.2016 um 21:39 in > Nachricht > <62cb811f-4396-ff36-ec03-67000b4ed...@redhat.com>: > > [...] > > Once set, attributes are not truly deleted -- only their values are > > cleared. And --delay has no effect with --update if the attribute > > already exists, which is what you see above. > > Is there a difference between a "deleted" variable and a defined variable > that has an empty string as value? I feel there should be! > > [...] > > Ulrich > > > > > > ------------------------------ > > _______________________________________________ > Users mailing list > Users@clusterlabs.org > http://clusterlabs.org/mailman/listinfo/users > > > End of Users Digest, Vol 23, Issue 1 > ************************************ >
_______________________________________________ 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