[ClusterLabs] Cluster resources migration from CMAN to Pacemaker
jpokorny at redhat.com
Mon Jan 25 15:30:33 EST 2016
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
> Thanks a lot John for explaining each and everything in detailed manner. I
> 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 had
> difficulties in migration of their legacy programs from CMAN to Pacemaker.
Glad to hear this, indeed :)
> As suggested I tried to migrate my existing cluster.conf file from CMAN to
> 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:
>> 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
>> 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 configuration
>>> from CMAN (RHEL-6.5) to PACEMAKER (RHEL-7.1).
>>> I have tried to explore a lot but couldn't find similarities configuring
>>> 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" post_join_delay="3"/>
>>> <clusternode name="ha1-105.test.com" nodeid="1" votes="1">
>> (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 the
> 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.
>>> <rm log_facility="local4" log_level="7">
>>> <failoverdomain name="Ha1-105_Domain" nofailback="0" ordered="0" restricted="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:
>>> <script file="/data/Product/HA/bin/ODG_IFAgent.py" name="REPL_IF"/>
>> 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
>> 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" name="ORACLE_REPLICATOR"/>
>>> <script file="/data/Product/HA/bin/OracleAgent.py" name="CTM_SID"/>
>>> <script file="/data/Product/HA/bin/NtwIFAgent.py" name="NTW_IF"/>
>>> <script file="/data/Product/HA/bin/FsCheckAgent.py" name="FSCheck"/>
>>> <script file="/data/Product/HA/bin/ApacheAgent.py" name="CTM_APACHE"/>
>>> <script file="/data/Product/HA/bin/CtmAgent.py" name="CTM_SRV"/>
>>> <script file="/data/Product/HA/bin/RsyncAgent.py" name="CTM_RSYNC"/>
>>> <script file="/data/Product/HA/bin/HeartBeat.py" name="CTM_HEARTBEAT"/>
>>> <script file="/data/Product/HA/bin/FlashBackMonitor.py" name="FLASHBACK"/>
>>> <service autostart="0" domain="Ha1-105_Domain" exclusive="0" name="ctm_service" recovery="disable">
>> autostart="0" discovered a bug in processing towards "pcs commands"
> 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
pcs resource meta SERVICE-ctm_service-GROUP is-managed=true
Will get back to you with answer for __independent_subtree later.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: not available
More information about the Users