[ClusterLabs] Users Digest, Vol 23, Issue 1

Ronny Machado C. ronny.machado.c at gmail.com
Thu Dec 1 12:51:35 CET 2016


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-request at clusterlabs.org> wrote:

> Send Users mailing list submissions to
>         users at 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-request at clusterlabs.org
>
> You can reach the person managing the list at
>         users-owner at 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 <dmaziuk at bmrb.wisc.edu>
> To: users at clusterlabs.org
> Subject: Re: [ClusterLabs] ocf:heartbeat:IPaddr2 - Different network
>         segment
> Message-ID: <057788d3-be24-05c9-c8bd-190237057b6b at 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 <dmaziuk at bmrb.wisc.edu>
> To: users at clusterlabs.org
> Subject: Re: [ClusterLabs] ocf:heartbeat:IPaddr2 - Different network
>         segment
> Message-ID: <d000f619-a395-1379-0259-5e0f05dfd337 at 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 <kgaillot at redhat.com>
> To: Cluster Labs - All topics related to open-source clustering
>         welcomed        <users at clusterlabs.org>
> Subject: [ClusterLabs] Pacemaker 1.1.16 released
> Message-ID: <b2510d57-79f4-927f-8315-67d81f03995e at 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 <kgaillot at redhat.com>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 30 Nov 2016 14:39:27 -0600
> From: Ken Gaillot <kgaillot at redhat.com>
> To: Kostiantyn Ponomarenko <konstantin.ponomarenko at gmail.com>
> Cc: Cluster Labs - All topics related to open-source clustering
>         welcomed        <users at clusterlabs.org>
> Subject: Re: [ClusterLabs] Antw: Re: Set a node attribute for multiple
>         nodes with one command
> Message-ID: <62cb811f-4396-ff36-ec03-67000b4ed07b at 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 <kgaillot at redhat.com
> > <mailto:kgaillot at 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.ponomarenko at gmail.com
> >     <mailto:konstantin.ponomarenko at gmail.com>
> >     > <mailto:konstantin.ponomarenko at gmail.com
> >     <mailto:konstantin.ponomarenko at 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.ponomarenko at gmail.com
> >     <mailto:konstantin.ponomarenko at gmail.com>
> >     >     <mailto:konstantin.ponomarenko at gmail.com
> >     <mailto:konstantin.ponomarenko at 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
> >     >         <kgaillot at redhat.com <mailto:kgaillot at redhat.com>
> >     <mailto:kgaillot at redhat.com <mailto:kgaillot at 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.Windl at rz.uni-regensburg.de
> >     <mailto:Ulrich.Windl at rz.uni-regensburg.de>
> >     >             <mailto:Ulrich.Windl at rz.uni-regensburg.de
> >     <mailto:Ulrich.Windl at rz.uni-regensburg.de>>
> >     >             > <mailto:Ulrich.Windl at rz.uni-regensburg.de
> >     <mailto:Ulrich.Windl at rz.uni-regensburg.de>
> >     >             <mailto:Ulrich.Windl at rz.uni-regensburg.de
> >     <mailto:Ulrich.Windl at rz.uni-regensburg.de>>>> wrote:
> >     >             >
> >     >             >     >>> Ken Gaillot <kgaillot at redhat.com <mailto:
> kgaillot at redhat.com>
> >     >             <mailto:kgaillot at redhat.com
> >     <mailto:kgaillot at redhat.com>> <mailto:kgaillot at redhat.com
> >     <mailto:kgaillot at redhat.com>
> >     >             <mailto:kgaillot at redhat.com <mailto:
> kgaillot at redhat.com>>>>
> >     >             >     schrieb am 18.11.2016 um 16:17 in Nachricht
> >     >             >     <d6f449da-64f8-12ad-00be-e772d8e382ca at redhat.com
> >     <mailto:d6f449da-64f8-12ad-00be-e772d8e382ca at redhat.com>
> >     >             <mailto:d6f449da-64f8-12ad-
> 00be-e772d8e382ca at redhat.com
> >     <mailto:d6f449da-64f8-12ad-00be-e772d8e382ca at redhat.com>>
> >     >             >
> >     >
> >     <mailto:d6f449da-64f8-12ad-00be-e772d8e382ca at redhat.com
> >     <mailto:d6f449da-64f8-12ad-00be-e772d8e382ca at redhat.com>
> >     >
> >      <mailto:d6f449da-64f8-12ad-00be-e772d8e382ca at redhat.com
> >     <mailto:d6f449da-64f8-12ad-00be-e772d8e382ca at 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.Windl at rz.uni-regensburg.de>
> To: <kgaillot at redhat.com>
> Cc: users at clusterlabs.org
> Subject: [ClusterLabs] Deleting a variable
> Message-ID: <583FDC38020000A10002375E at gwsmtp1.uni-regensburg.de>
> Content-Type: text/plain; charset=US-ASCII
>
> >>> Ken Gaillot <kgaillot at redhat.com> schrieb am 30.11.2016 um 21:39 in
> Nachricht
> <62cb811f-4396-ff36-ec03-67000b4ed07b at 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 at clusterlabs.org
> http://clusterlabs.org/mailman/listinfo/users
>
>
> End of Users Digest, Vol 23, Issue 1
> ************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://clusterlabs.org/pipermail/users/attachments/20161201/a92bda84/attachment-0001.html>


More information about the Users mailing list