[Pacemaker] RHEL/CentOS 6.4: corosync -> CMAN migration
Hello world, according to [1] using the pacemaker plugin with corosync is deprecated and will cease to be supported at some point in the future (on RHEL!). Instead, the use of CMAN and running pacemaker as a standalone service is recommended. Now, unfortunately, the former (corosync with pcmk plugin) is exactly what we are using on two fileservice clusters, so we need a migration path with no downtime. I'm going to do some extensive testing later this week, but I'd be grateful for a bit of advance help. I think what I will try is: 1. Put pacemaker into maintenance mode. 2. Stop corosync, remove corosync.conf and the config snippet loading pacemaker from within corosync. 3. Install cman and ccs. 4. Generate new cluster.conf, using appropriate tools. 5. Start cman, start pacemaker. The two crucial questions are: 1. In step (2), will pacemaker stop resources when it's brought down, despite being in maintenance mode? 2. In step (5), will the pacemaker resource configuration be preserved throughout this migration? Any insights would be greatly appreciated. Cheers Stefan [1] https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/6.4_Technical_Notes/pacemaker.html ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [Pacemaker] RHEL/CentOS 6.4: corosync -> CMAN migration
Am Sonntag, 10. März 2013, 10:35:33 schrieb Stefan Förster: > Hello world, > > according to [1] using the pacemaker plugin with corosync is > deprecated and will cease to be supported at some point in the future > (on RHEL!). Instead, the use of CMAN and running pacemaker as a > standalone service is recommended. > > Now, unfortunately, the former (corosync with pcmk plugin) is exactly > what we are using on two fileservice clusters, so we need a migration > path with no downtime. I'm going to do some extensive testing later > this week, but I'd be grateful for a bit of advance help. I think what > I will try is: > > 1. Put pacemaker into maintenance mode. > 2. Stop corosync, remove corosync.conf and the config snippet loading >pacemaker from within corosync. > 3. Install cman and ccs. > 4. Generate new cluster.conf, using appropriate tools. > 5. Start cman, start pacemaker. > > The two crucial questions are: > > 1. In step (2), will pacemaker stop resources when it's brought down, >despite being in maintenance mode? > 2. In step (5), will the pacemaker resource configuration be >preserved throughout this migration? > > Any insights would be greatly appreciated. > > > Cheers > Stefan Yes. pacemaker should honor the maintanance mode when being stopped or started. It also should read the existing configuration from the files. But if your service is really that crucial be sure to make extended testing for the migration on a test system. Greetings, Michael Schwartzkopff -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [Pacemaker] [Problem][crmsh]The designation of the 'ordered' attribute becomes the error.
Hi Dejan, Thank you for comment. > sequential=true is the default. In that case it's not possible to > have an unequivocal representation for the same construct and, in > this particular case, the conversion XML->CLI->XML yields a > different XML. There's a later commit which helps here, I think > that it should be possible to backport it to 1.0: > > changeset: 789:916d1b15edc3 > user:Dejan Muhamedagic > date:Thu Aug 16 17:01:24 2012 +0200 > summary: Medium: cibconfig: drop attributes set to default on cib import I apply the backporting that you taught and confirm movement. I talk with you again if I have a problem. > > Is there a right method to appoint an attribute of "resource_set" with crm > > shell? > > Possibly is not "resource_set" usable with crm shell of Pacemaker1.0.13? > > Should work. It's just that using it with two resources, well, > it's sort of unusual use case. All right! Many Thanks! Hideo Yamauchi. --- On Fri, 2013/3/8, Dejan Muhamedagic wrote: > Hi Hideo-san, > > On Thu, Mar 07, 2013 at 10:18:09AM +0900, renayama19661...@ybb.ne.jp wrote: > > Hi Dejan, > > > > The problem was settled with your patch. > > > > However, I have a question. > > I want to use "resource_set" which Mr. Andrew proposed, but do not > > understand a method to use with crm shell. > > > > I read two next cib.xml and confirmed it with crm shell. > > > > Case 1) sequential="false". > > (snip) > > > > > > >id="test-order-resource_set"> > > > > > > > > > > > > (snip) > > * When I confirm it with crm shell ... > > (snip) > > group master-group vip-master vip-rep > > order test-order : _rsc_set_ ( vip-master vip-rep ) > > (snip) > > Yes. All size two resource sets get the _rsc_set_ keyword, > otherwise it's not possible to distinguish them from "normal" > constraints. Resource sets are supposed to help cases when it is > necessary to express relation between three or more resources. > Perhaps this case should be an exception. > > > Case 2) sequential="true" > > (snip) > > > > > > > > > > > > > > > > > > (snip) > > * When I confirm it with crm shell ... > > (snip) > > group master-group vip-master vip-rep > > xml \ > > \ > > \ > > \ > > \ > > > > (snip) > > > > Does the designation of "sequential=true" have to describe it in xml? > > sequential=true is the default. In that case it's not possible to > have an unequivocal representation for the same construct and, in > this particular case, the conversion XML->CLI->XML yields a > different XML. There's a later commit which helps here, I think > that it should be possible to backport it to 1.0: > > changeset: 789:916d1b15edc3 > user: Dejan Muhamedagic > date: Thu Aug 16 17:01:24 2012 +0200 > summary: Medium: cibconfig: drop attributes set to default on cib import > > > Is there a right method to appoint an attribute of "resource_set" with crm > > shell? > > Possibly is not "resource_set" usable with crm shell of Pacemaker1.0.13? > > Should work. It's just that using it with two resources, well, > it's sort of unusual use case. > > Cheers, > > Dejan > > > Best Regards, > > Hideo Yamauchi. > > > > --- On Thu, 2013/3/7, renayama19661...@ybb.ne.jp > > wrote: > > > > > Hi Dejan, > > > Hi Andrew, > > > > > > Thank you for comment. > > > I confirm the movement of the patch and report it. > > > > > > Best Regards, > > > Hideo Yamauchi. > > > > > > --- On Wed, 2013/3/6, Dejan Muhamedagic wrote: > > > > > > > Hi Hideo-san, > > > > > > > > On Wed, Mar 06, 2013 at 10:37:44AM +0900, renayama19661...@ybb.ne.jp > > > > wrote: > > > > > Hi Dejan, > > > > > Hi Andrew, > > > > > > > > > > As for the crm shell, the check of the meta attribute was revised > > > > > with the next patch. > > > > > > > > > > * http://hg.savannah.gnu.org/hgweb/crmsh/rev/d1174f42f4b3 > > > > > > > > > > This patch was backported in Pacemaker1.0.13. > > > > > > > > > > * > > > > >https://github.com/ClusterLabs/pacemaker-1.0/commit/fa1a99ab36e0ed015f1bcbbb28f7db962a9d1abc#shell/modules/cibconfig.py > > > > > > > > > > However, the ordered,colocated attribute of the group resource is > > > > > treated as an error when I use crm Shell which adopted this patch. > > > > > > > > > > -- > > > > > (snip) > > > > > ### Group Configuration ### > > > > > group master-group \ > > > > > vip-master \ > > > > > vip-rep \ > > > > > meta \ > > > > > ordered="false" > > > > > (snip) > > > > > > > > > > [root@rh63-heartbeat1 ~]# crm configure load update test2339.crm > > > > > INFO: building help index > > > > > crm_verify[20028]: 2013/03/06_17:57:18 WARN: unpack_nodes: Blind > > > > > faith: not fencing unseen nodes > > > >
[Pacemaker] Help on defining resource-stickness
Hi I am currently learning how to use pacemaker. I have created a three nodes configuration, and two IP resources. My target to setup the IP to follow only two nodes, and this is able to achieve by using the score in location command. My next target is to disable the failover back when node is resumed. But I am confused how I can define the resource-stickness accordingly to different resources. Below is my configuration. crm(live)configure# show node HA_NODE1 node HA_NODE2 node HA_NODE3 primitive ClusterIP ocf:heartbeat:IPaddr2 \ params ip="192.168.206.161" cidr_netmask="32" \ op monitor interval="30s" primitive PDNS_IP ocf:heartbeat:IPaddr2 \ params ip="192.168.206.160" cidr_netmask="32" nic="eth2" location ClusterIP-prefer1 ClusterIP 500: HA_NODE1 location ClusterIP-prefer2 ClusterIP 300: HA_NODE2 location ClusterIP-prefer3 ClusterIP -inf: HA_NODE3 location PDNS_IP-prefer1 PDNS_IP -inf: HA_NODE1 location PDNS_IP-prefer2 PDNS_IP 500: HA_NODE2 location PDNS_IP-prefer3 PDNS_IP 300: HA_NODE3 property $id="cib-bootstrap-options" \ dc-version="1.1.7-6.el6-148fccfd5985c5590cc601123c6c16e966b85d14" \ cluster-infrastructure="openais" \ expected-quorum-votes="3" \ stonith-enabled="false" \ no-quorum-policy="ignore" \ last-lrm-refresh="1362737116" rsc_defaults $id="rsc-options" \ resource-stickiness="150" Target is to 1. ClusterIP will flow between HA_NODE1 and HA_NODE2 only. 2. PDNS_IP will flow between HA_NODE2 and HA_NODE3 only. Question: How I can setup the resources "CLUSTERIP" not failover back to HA_NODE1 when it is resumed, and resources "PDNS_IP" failover back to HA_NODE2 when it is resumed? RBK ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
