[ClusterLabs] Cluster resources migration from CMAN to Pacemaker
jaspal.singla at gmail.com
Wed Jan 27 03:34:23 EST 2016
Thanks for your replies!!
I have couple of concerns more to answer, please help!
1) In CMAN, there was meta attribute - autostart=0 (This parameter disables
the start of all services when RGManager starts). Is there any way for such
behavior in Pacemaker?
I tried to explore is-manged=0 but when I start the cluster through pcs
cluster start OR pcs cluster start --all, my all of the resources gets
started (even the one which has meta attribute configured as
is-managed=false). Any clue to achieve such behavior?
What does is-manged=false do?
2) Please put some alternatives to exclusive=0 and __independent_subtree?
what we have in Pacemaker instead of these?
My cluster depends on these meta attributes and I am getting nothing in
pacemaker as an alternative to these one. Please see, if it is feasible to
achieve such meta attributes in Pacemaker.
> On 24/01/16 16:54 +0530, jaspal singla wrote:
> > Thanks Digimer for letting me about the tool. I was unaware of any such
> > tools!! And because of that I was able to search clufter-cli tool for the
> > migration.
> > Thanks a lot John for explaining each and everything in detailed manner.
> > am really admired the knowledge you guys have!!
> > I also noticed that clufter tool is written by you :). I am very thankful
> > to you as it would save the ass of millions people like me who may have
> > difficulties in migration of their legacy programs from CMAN to
> Glad to hear this, indeed :)
> > As suggested I tried to migrate my existing cluster.conf file from CMAN
> > Pacemaker through the use of clufter. But have couple of queries going
> > forward, would appreciate if you could answer these.
> > Please find In-line queries:
> Answers ditto...
> >> Date: Fri, 22 Jan 2016 21:52:17 +0100
> >> From: Jan Pokorn? <jpokorny at redhat.com>
> >> Subject: Re: [ClusterLabs] Cluster resources migration from CMAN to
> >> Pacemaker
> >> Message-ID: <20160122205217.GE28856 at redhat.com>
> >> yes, as Digimer mentioned, clufter is the tool you may want to look
> >> at. Do not expect fully automatic miracles from it, though.
> >> It's meant to show the conversion path, but one has to be walk it
> >> very carefully and make adjustments every here and there.
> >> In part because there is not a large overlap between resource agents
> >> of both kinds.
> >> On 22/01/16 17:32 +0530, jaspal singla wrote:
> >>> I desperately need some help in order to migrate my cluster
> >>> from CMAN (RHEL-6.5) to PACEMAKER (RHEL-7.1).
> >>> I have tried to explore a lot but couldn't find similarities
> >>> same resources (created in CMAN's cluster.conf file) to Pacemaker.
> >>> I'd like to share cluster.conf of RHEL-6.5 and want to achieve the same
> >>> thing through Pacemaker. Any help would be greatly appreciable!!
> >>> *Cluster.conf file*
> >>> ######################################################################
> >> [reformatted configuration file below for better readability and added
> >> some comment in-line]
> >>> <?xml version="1.1"?>
> >> ^^^
> >> no, this is not the way to increase config version
> >> This seems to be quite frequented mistake; looks like configuration
> >> tools should have strictly refrained from using this XML declaration
> >> in the first place.
> >>> <cluster config_version="1" name="HA1-105_CLUSTER">
> >>> <fence_daemon clean_start="0" post_fail_delay="0"
> >>> <clusternodes>
> >>> <clusternode name="ha1-105.test.com" nodeid="1" votes="1">
> >>> <fence/>
> >>> </clusternode>
> >> (I suppose that other nodes were omitted)
> > No, its Single-Node Cluster Geographical Redundancy Configuration.
> > The geographical redundancy configuration allows us to locate two Prime
> > Optical instances at geographically remote sites. One server instance is
> > active; the other server instance is standby. The HA agent switches to
> > standby Element Management System (EMS) instance if an unrecoverable
> > failure occurs on the active EMS instance. In a single-node cluster
> > geographical redundancy configuration, there are two clusters with
> > different names (one on each node), each containing a server.
> Ah, it's more me not being familiar with rather exotic uses cases and
> I definitely include degenerate single-node-on-purpose case here.
> >>> </clusternodes>
> >>> <cman/>
> >>> <fencedevices/>
> >>> <rm log_facility="local4" log_level="7">
> >>> <failoverdomains>
> >>> <failoverdomain name="Ha1-105_Domain" nofailback="0" ordered="0"
> >> TODO: have to check what does it mean when FOD is not saturated
> >> with any cluster node references
> > No worries of using FOD as I don't think, it will be in use as we have
> > groups in pacemaker.
> FYI, I checked the code and it seams utterly useless to define an
> empty failover domain and to refer to it from the resource group.
> Based on its properties, just the logged warnings may vary.
> Furthermore, enabling restricted property may prevent associated
> groups to start at all.
> Added a warning and corrected the conversion accordingly:
> >>> </failoverdomains>
> >>> <resources>
> >>> <script file="/data/Product/HA/bin/ODG_IFAgent.py"
> >> General LSB-compliance-assumed commands are currently using a path hack
> >> with lsb:XYZ resource specification. In this very case, it means
> >> the result after the conversion refers to
> >> "lsb:../../..//data/Product/HA/bin/FsCheckAgent.py".
> >> Agreed, there should be a better way to support arbitrary locations
> >> beside /etc/init.d/XYZ.
> > Configured resources as LSB as you suggested.
> >>> <script file="/data/Product/HA/bin/ODG_ReplicatorAgent.py"
> >>> <script file="/data/Product/HA/bin/OracleAgent.py"
> >>> <script file="/data/Product/HA/bin/NtwIFAgent.py" name="NTW_IF"/>
> >>> <script file="/data/Product/HA/bin/FsCheckAgent.py"
> >>> <script file="/data/Product/HA/bin/ApacheAgent.py"
> >>> <script file="/data/Product/HA/bin/CtmAgent.py" name="CTM_SRV"/>
> >>> <script file="/data/Product/HA/bin/RsyncAgent.py"
> >>> <script file="/data/Product/HA/bin/HeartBeat.py"
> >>> <script file="/data/Product/HA/bin/FlashBackMonitor.py"
> >>> </resources>
> >>> <service autostart="0" domain="Ha1-105_Domain" exclusive="0"
> name="ctm_service" recovery="disable">
> >> autostart="0" discovered a bug in processing towards "pcs commands"
> >> output:
> >> https://pagure.io/clufter/57ebc50caf2deddbc6c12042753ce0573a4a260c
> > I don't want to start my some of the configured services when Pacemaker
> > starts ( like it had happen in RGManager), I want to manually starts the
> > services. Is their any way I can do that?
> > Also, I am trying to start the cluster but "Resource Group:
> > SERVICE-ctm_service-GROUP" is going into unmanaged state and cannot be
> > started. Could you please give me some clue of it like why its going in
> > unamanged state and how it can be rectified?
> Just a quick suggestion for now if it helps:
> pcs resource manage SERVICE-ctm_service-GROUP
> or alternatively:
> pcs resource meta SERVICE-ctm_service-GROUP is-managed=true
> Will get back to you with answer for __independent_subtree later.
> Jan (Poki)
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 819 bytes
> Desc: not available
> URL: <
> Message: 3
> Date: Mon, 25 Jan 2016 16:49:11 -0500
> From: Digimer <lists at alteeve.ca>
> To: Cluster Labs - Users <users at clusterlabs.org>
> Subject: [ClusterLabs] Moving Anvil! and Striker development to this
> Message-ID: <56A69857.10308 at alteeve.ca>
> Content-Type: text/plain; charset=utf-8
> Hi all,
> The Anvil! and Striker (and now ScanCore) projects used to have their
> own low-volume mailing list. Recently it started getting some use and,
> being the one who advocated the strongest for the merger of lists, I
> decided to close it down and migrate over to here.
> To give a brief overview of what Anvil!, Striker and ScanCore is;
> The "Anvil!" is the name of our 2-node HA cluster based on this
> tutorial. It's also the term we generally use for the full HA stack
> we've built.
> Striker is a web-based front-end for Managing Anvil! clusters and
> the servers that run on them. It has been in very heavy development the
> last year and change and we're getting close to the version 2 release
> "real soon now(tm)".
> ScanCore is a new component that runs on both Anvil! nodes and
> Striker dashboards. It was initially announced at the HA Summit in Brno
> in 2015 is it's release will coincide with Striker v2's release. It is
> an alert, predictive failure and mitigation program that is technically
> stand-alone but has been built into the heart of the Anvil! platform. It
> is inherently redundant does things like watch for faults, try to
> recover from known problems autonomously and alert users to these issues.
> I've been somewhat reluctant to move our list over because Alteeve,
> our company and the company that builds and maintains the Anvil!,
> Striker and ScanCore is for-profit. However, _everything_ we do is open
> source, so I hope that won't be held against us. :)
> If anyone has any comments or concerns about us moving our project
> discussion to this list, please let me know and I'll do what I can to
> make sure we address those concerns.
> 1. https://alteeve.ca/w/AN!Cluster_Tutorial_2
> 2. https://github.com/digimer/striker
> 3. https://github.com/digimer/striker/tree/master/ScanCore
> Papers and Projects: https://alteeve.ca/w/
> What if the cure for cancer is trapped in the mind of a person without
> access to education?
> Users mailing list
> Users at clusterlabs.org
> End of Users Digest, Vol 12, Issue 42
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Users