cluster: the tag gfs-kernel_0_1_33 has been created

Chris Feist cfeist@fedoraproject.org
Fri Jun 12 14:41:00 GMT 2009


Gitweb:        http://git.fedorahosted.org/git/cluster.git?p=cluster.git;a=commitdiff;h=7955e22fd2d8b5f99fa033ff12c182a03c9a1b25
Commit:        7955e22fd2d8b5f99fa033ff12c182a03c9a1b25
Parent:        5c9407043283db699d68643c456ed3014857da15
Author:        Christine Caulfield <ccaulfie@redhat.com>
AuthorDate:    Mon Jun 8 09:37:49 2009 +0100
Committer:     Christine Caulfield <ccaulfie@redhat.com>
CommitterDate: Mon Jun 8 09:37:49 2009 +0100

cman: Replace openais with corosync in several places

Signed-off-by: Christine Caulfield <ccaulfie@redhat.com>
---
 cman/man/cman.5      |   38 +++++++++++-----------
 cman/man/cman_tool.8 |   88 ++++++-------------------------------------------
 2 files changed, 30 insertions(+), 96 deletions(-)

diff --git a/cman/man/cman.5 b/cman/man/cman.5
index d36f484..8e52226 100644
--- a/cman/man/cman.5
+++ b/cman/man/cman.5
@@ -93,14 +93,14 @@ the nodeid to one that is already used.
 .in +7
 It is quite common to use multiple ethernet adapters for cluster nodes, so
 they will tolerate the failure of one link. A common way to do this is to use
-ethernet bonding. Alternatively you can get openais to run in redundant ring
+ethernet bonding. Alternatively you can get corosync to run in redundant ring
 mode by specifying an 'altname' for the node. This is an alternative name by
 which the node is known, that resolves to another IP address used on the 
 other ethernet adapter(s). You can optionally specify a different port and/or 
 multicast address for each altname in use. Up to 9 altnames (10 interfaces 
 in total) can be used.
 
-Note that if you are using the DLM with cman/openais then you MUST tell it 
+Note that if you are using the DLM with Corosync then you MUST tell it 
 to use SCTP as it's communications protocol as TCP does not support multihoming.
 
   <clusternode name="nd1" nodeid="1"> 
@@ -141,15 +141,15 @@ you feel the need. Sometimes cluster names can hash to the same ID.
 
 .in -7
 
-\fIopenais security key\fR
+\fICorosync security key\fR
 .in +7
-All traffic sent out by cman/openais is encrypted. By default the security key 
+All traffic sent out by Corosync is encrypted. By default the security key 
 used is simply the cluster name. If you need more security you can specify a
 key file that contains the key used to encrypt cluster communications.
 Of course, the contents of the key file must be the same on all nodes in the
 cluster. It is up to you to securely copy the file to the nodes.
 
-  <cman keyfile="/etc/openais.key">
+  <cman keyfile="/etc/corosync.key">
   </cman>
 
 Note that this only applies to cluster communication. The DLM does not encrypt 
@@ -157,13 +157,13 @@ traffic.
 .in -7
 
 
-\fIOther openais parameters\fR
+\fIOther Corosync parameters\fR
 .in +7
-When openais is started by cman (cman_tool runs aisexec), the openais.conf
+When Corosync is started by cman (cman_tool runs corosync), the corosync.conf
 file is not used.  Many of the configuration parameters listed in
-openais.conf can be set in cluster.conf (CCS) instead.  Cman will read
-openais parameters from the following sections in cluster.conf and load
-them into openais:
+corosync.conf can be set in cluster.conf instead.  Cman will read
+corosync parameters from the following sections in cluster.conf and load
+them into corosync:
 
   <cluster>
     <totem />
@@ -174,15 +174,15 @@ them into openais:
   </cluster>
 
 See the 
-.B openais.conf(5)
+.B corosync.conf(5)
 man page for more information on keys that are valid for these sections.
 Note that settings in the <clusternodes> section will override settings in
 the sections above, and options on the cman_tool command line will
 override both.  In particular, settings like bindnetaddr, mcastaddr,
 mcastport and nodeid will always be replaced by values in <clusternodes>.
 
-Cman uses different defaults for some of the openais parameters listed in
-openais.conf(5).  If you wish to use a non-default setting, they can be
+Cman uses different defaults for some of the corosync parameters listed in
+corosync.conf(5).  If you wish to use a non-default setting, they can be
 configured in cluster.conf as shown above.  Cman uses the following
 default values:
 
@@ -202,13 +202,13 @@ Here's how to set the token timeout to five seconds:
 
   <totem token="5000"/>
 
-And this is how to add extra openais logging options to CMAN and CPG:
+And this is how to add extra corosync logging options to CMAN and CPG:
 
   <logging to_stderr="yes">
-    <logger ident="CPG" debug="on" to_stderr="yes">
-    </logger>
-    <logger ident="CMAN" debug="on" to_stderr="yes">
-    </logger>
+    <logger_subsys subsys="CPG" debug="on" to_stderr="yes">
+    </logger_subsys>
+    <logger_subsys subsys="CMAN" debug="on" to_stderr="yes">
+    </logger_subsys>
   </logging>
 
 .in -7
@@ -218,5 +218,5 @@ And this is how to add extra openais logging options to CMAN and CPG:
 
 .SH "SEE ALSO"
 
-cluster.conf(5), openais.conf(5), ccs(7), cman_tool(8)
+cluster.conf(5), corosync.conf(5), ccs(7), cman_tool(8)
 
diff --git a/cman/man/cman_tool.8 b/cman/man/cman_tool.8
index 8160a9b..d9bc224 100644
--- a/cman/man/cman_tool.8
+++ b/cman/man/cman_tool.8
@@ -228,7 +228,7 @@ command without -w followed by
 .B cman_tool wait.
 .TP
 .I -k <keyfile>
-All traffic sent out by cman/openais is encrypted. By default the security key 
+All traffic sent out by Corosync is encrypted. By default the security key 
 used is simply the cluster name. If you need more security you can specify a
 key file that contains the key used to encrypt cluster communications.
 Of course, the contents of the key file must be the same on all nodes in the
@@ -255,9 +255,7 @@ failover cluster this might save you some effort.
 On each node using this configuration you will need to have the same authorization key
 installed. To create this key run
 .br
-mkdir /etc/ais
-.br
-ais-keygen
+corosync-keygen
 .br
 mv /etc/ais/authkey /etc/cluster/cman_authkey
 .br
@@ -265,7 +263,7 @@ then copy that file to all nodes you want to join the cluster.
 .br
 .TP
 .I -C
-Overrides the default configuration module. Usually cman uses ccsd to load its
+Overrides the default configuration module. Usually cman uses cluster.conf to load its
 configuration. If you have your configuration database held elsewhere (eg LDAP) and 
 have a configuration plugin for it, then you should specify the name of the module
 (see the documentation for the module for the name of it - it's not necessarily the 
@@ -275,7 +273,7 @@ It is possible to chain configuration modules by separating them with colons. So
 add two modules (eg) 'ldapconfig' and 'ldappreproc' to the chain start cman with
 -C ldapconfig:ldappreproc
 .br
-The default value for this is 'ccsconfig'. Note that if the -X is on the command-line
+The default value for this is 'xmlconfig'. Note that if the -X is on the command-line
 then -C will be ignored.
 .TP
 .I -A
@@ -307,17 +305,7 @@ include: id, name, type, and addr.
 .SH "DEBUG" OPTIONS
 .TP
 .I -d <value>
-The value is a bitmask of
-.br 
-2 Barriers
-.br
-4 Membership messages
-.br
-8 Daemon operation, including command-line interaction
-.br
-16 Interaction with OpenAIS
-.br
-32 Startup debugging (cman_tool join operations only)
+Currently only a value of 1 is supported.
 .br
 .SH NOTES
 .br
@@ -332,80 +320,26 @@ X	The node is not a member of the cluster
 d	The node is known to the cluster but disallowed access to it.
 .br
 .SH ENVIRONMENT VARIABLES
-cman_tool removes most environment variables before forking and running OpenAIS, as well as adding some of its own for setting up
+cman_tool removes most environment variables before forking and running Corosync, as well as adding some of its own for setting up
 configuration parameters that were overridden on the command-line, the exception to this is that variable with names starting
 COROSYNC_ will be passed down intact as they are assumed to be used for configuring the daemon. 
 
-.SH DISALLOWED NODES
-Occasionally (but very infrequently I hope) you may see nodes marked as "Disallowed" in cman_tool status or "d" in cman_tool nodes.  This is a bit of a nasty hack to get around mismatch between what the upper layers expect of the cluster manager and OpenAIS.
-.TP
-If a node experiences a momentary lack of connectivity, but one that is long enough to trigger the token timeouts, then it will be removed from the cluster. When connectivity is restored OpenAIS will happily let it rejoin the cluster with no fuss. Sadly the upper layers don't like this very much. They may (indeed probably will have) have changed their internal state while the other node was away and there is no straightforward way to bring the rejoined node up-to-date with that state. When this happens the node is marked "Disallowed" and is not permitted to take part in cman operations.  
-.P
-If the remainder of the cluster is quorate the the node will be sent a kill message and it will be forced to leave the cluster that way. Note that fencing should kick in to remove the node permanently anyway, but it may take longer than the network outage for this to complete.
-
-If the remainder of the cluster is inquorate then we have a problem. The likelihood is that we will have two (or more) partitioned clusters and we cannot decide which is the "right" one. In this case we need to defer to the system administrator to kill an appropriate selection of nodes to restore the cluster to sensible operation.
-
-The latter scenario should be very rare and may indicate a bug somewhere in the code. If the local network is very flaky or busy it may be necessary to increase some of the protocol timeouts for OpenAIS. We are trying to think of better solutions to this problem.
-
-Recovering from this state can, unfortunately, be complicated. Fortunately, in the majority of cases, fencing will do the job for you, and the disallowed state will only be temporary. If it persists, the recommended approach it is to do a cman tool nodes on all systems in the cluster and determine the largest common subset of nodes that are valid members to each other. Then reboot the others and let them rejoin correctly. In the case of a single-node disconnection this should be straightforward, with a large cluster that has experienced a network partition it could get very complicated!
-
-Example:
-
-In this example we have a five node cluster that has experienced a network partition. Here is the output of cman_tool nodes from all systems:
-.nf
-Node  Sts   Inc   Joined               Name
-   1   M   2372   2007-11-05 02:58:55  node-01.example.com
-   2   d   2376   2007-11-05 02:58:56  node-02.example.com
-   3   d   2376   2007-11-05 02:58:56  node-03.example.com
-   4   M   2376   2007-11-05 02:58:56  node-04.example.com
-   5   M   2376   2007-11-05 02:58:56  node-05.example.com
-
-Node  Sts   Inc   Joined               Name
-   1   d   2372   2007-11-05 02:58:55  node-01.example.com
-   2   M   2376   2007-11-05 02:58:56  node-02.example.com
-   3   M   2376   2007-11-05 02:58:56  node-03.example.com
-   4   d   2376   2007-11-05 02:58:56  node-04.example.com
-   5   d   2376   2007-11-05 02:58:56  node-05.example.com
-
-Node  Sts   Inc   Joined               Name
-   1   d   2372   2007-11-05 02:58:55  node-01.example.com
-   2   M   2376   2007-11-05 02:58:56  node-02.example.com
-   3   M   2376   2007-11-05 02:58:56  node-03.example.com
-   4   d   2376   2007-11-05 02:58:56  node-04.example.com
-   5   d   2376   2007-11-05 02:58:56  node-05.example.com
-
-Node  Sts   Inc   Joined               Name
-   1   M   2372   2007-11-05 02:58:55  node-01.example.com
-   2   d   2376   2007-11-05 02:58:56  node-02.example.com
-   3   d   2376   2007-11-05 02:58:56  node-03.example.com
-   4   M   2376   2007-11-05 02:58:56  node-04.example.com
-   5   M   2376   2007-11-05 02:58:56  node-05.example.com
-
-Node  Sts   Inc   Joined               Name
-   1   M   2372   2007-11-05 02:58:55  node-01.example.com
-   2   d   2376   2007-11-05 02:58:56  node-02.example.com
-   3   d   2376   2007-11-05 02:58:56  node-03.example.com
-   4   M   2376   2007-11-05 02:58:56  node-04.example.com
-   5   M   2376   2007-11-05 02:58:56  node-05.example.com
-.fi
-In this scenario we should kill the node node-02 and node-03. Of course, the 3 node cluster of node-01, node-04 & node-05 should remain quorate and be able to fenced the two rejoined nodes anyway, but it is possible that the cluster has a qdisk setup that precludes this.
-
 .SH CONFIGURATION SYSTEMS
 This section details how the configuration systems work in cman. You might need to know this if you are using the -C option
 to cman_tool, or writing your own configuration subsystem.
 .br
-By default cman uses two configuration plugins to OpenAIS. The first, 'ccsconfig', reads the configuration information
+By default cman uses two configuration plugins to Corosync. The first, 'xmlconfig', reads the configuration information
 stored in cluster.conf and stores it in an internal database, in the same schema as it finds in cluster.conf. 
 The second plugin, 'cmanpreconfig', takes the information in that the database, adds several cman defaults, determines 
-the OpenAIS node name and nodeID
-and formats the information in a similar manner to openais.conf(5). OpenAIS then reads those keys to start the cluster protocol.
+the Corosync node name and nodeID
+and formats the information in a similar manner to corosync.conf(5). Corosync then reads those keys to start the cluster protocol.
 cmanpreconfig also reads several environment variables that might be set by cman_tool which can override information in the 
 configuration.
 .br
-In the absence of ccsconfig, ie when 'cman_tool join' is run with -X switch (this removes ccsconfig from the module list), 
+In the absence of xmlconfig, ie when 'cman_tool join' is run with -X switch (this removes xmlconfig from the module list), 
 cmanpreconfig also generates several defaults so that the cluster can be got running without any configuration information - see above
 for the details.
 .br
-Note that cmanpreconfig will not overwrite OpenAIS keys that are explicitly set in the configuration file, allowing you to provide
+Note that cmanpreconfig will not overwrite Corosync keys that are explicitly set in the configuration file, allowing you to provide
 custom values for token timeouts etc, even though cman has its own defaults for some of those values. The exception to this is the node
 name/address and multicast values, which are always taken from the cman configuration keys.



More information about the Cluster-cvs mailing list