Provided by: cman_3.1.7-0ubuntu2_amd64 bug

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="239.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="239.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 parameters 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 <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  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:

                <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)