cman(5) 					      cluster.conf cman configuration section						   cman(5)

NAME

       cman - cluster.conf cman configuration section

DESCRIPTION

	      Cman  configuration  values  are	placed	in  the <cman> </cman> section of cluster.conf.  Per-node configuration related to cman is
	      placed in the standard <clusternode> </clusternode> sections.  All cman configuration settings are optional; usually none are  used.
	      The <cman> section is placed under the <cluster> section in cluster.conf.

		<cluster>
		  <cman>
		  </cman>
		  ...
		</cluster>

       UDP port
	      By default, cman will use UDP port 5405/5404 for internode communication.  This can be changed by setting a port number as follows:

		<cman port="6809">
		</cman>

	      This will cause cman to use ports 6809 and 6808 for cluster communications.

       Expected votes
	      The  expected  votes  value  is used by cman to determine quorum.  The cluster is quorate if the sum of votes of existing members is
	      over half of the expected votes value.  By default, cman sets the expected votes value to be the sum of votes of all nodes listed in
	      cluster.conf.  This can be overridden by setting an explicit expected_votes value as follows:

		<cman expected_votes="3">
		</cman>

	      If  the  cluster	becomes  partitioned,  improper  use of this option can result in more than one partition gaining quorum.  In that
	      event, nodes in each partition will enable cluster services.

       Two node clusters
	      Ordinarily, the loss of quorum after one out of two nodes fails will prevent the remaining node from continuing (if both nodes  have
	      one  vote.)   Special configuration options can be set to allow the one remaining node to continue operating if the other fails.	To
	      do this only two nodes, each with one vote, can be defined in cluster.conf.  The two_node and expected_votes values must then be set
	      to 1 in the cman section as follows.

		<cman two_node="1" expected_votes="1">
		</cman>

       Node votes
	      By  default,  a  node is given one vote toward the calculation of quorum.  This can be changed by giving a node a specific number of
	      votes as follows:

		<clusternode name="nd1" votes="2">
		</clusternode>

       Node ID

	      All nodes must have a unique node ID. This is a single integer that identifies it to the cluster.  A node's application to join  the
	      cluster may be rejected if you try to set the nodeid to one that is already used.

		<clusternode name="nd1" nodeid="1">
		</clusternode>

       Multi-home configuration
	      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 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/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">
		   <altname name="nd1a" port="6809" mcast="229.192.0.2"/>
		</clusternode>

		<dlm protocol="sctp"/>

       Multicast network configuration
	      cman uses multicast UDP packets to communicate with other nodes in the cluster.  By default it will  generate  a	multicast  address
	      using  239.192.x.x  where x.x is the 16bit cluster ID number split into bytes. This, in turn is generated from a hash of the cluster
	      name though it can be specified explicitly. The purpose of this is to allow multiple clusters to share the same subnet -	they  will
	      each use a different multicast address. You might also/instead want to isolate clusters using the port number as shown above.

	      It is possible to override the multicast address by specifying it in cluster.conf as shown:

		<cman>
		    <multicast addr="229.192.0.1"/>
		</cman>

       Cluster ID
	      The  cluster  ID number is used to isolate clusters in the same subnet. Usually it is generated from a hash of the cluster name, but
	      it can be overridden here if you feel the need. Sometimes cluster names can hash to the same ID.

		<cman cluster_id="669">
		</cman>

       corosync security key
	      All traffic sent out by cman/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/cluster/corosync.key">
		</cman>

	      Note that this only applies to cluster communication. The DLM does not encrypt traffic.

       Other corosync parameters
	      When corosync is started by cman (cman_tool runs corosync), the corosync.conf file is not used.  Many of the  configuration  parame-
	      ters  listed in 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 />
		  <event />
		  <aisexec />
		  <group />
		</cluster>

	      See the corosync.conf(5) man page for more information on keys that are valid for these sections.  Note that settings in the  <clus-
	      ternodes>  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 corosync parameters listed in corosync.conf(5).  If you wish to use a non-default  set-
	      ting, they can be configured in cluster.conf as shown above.  Cman uses the following default values:

		<totem
		  vsftype="none"
		  token="10000"
		  token_retransmits_before_loss_const="20"
		  join="60"
		  consensus="4800"
		  rrp_mode="none"
		  <!-- or rrp_mode="active" if altnames are present >
		/>
		<aisexec user="root" group="root" />

	      Here's how to set the token timeout to five seconds:

		<totem token="5000"/>

SEE ALSO

       cluster.conf(5), corosync.conf(5), cman_tool(8)

																	   cman(5)