corosync_overview man page on RedHat

Man page or keyword search:  
man Server   29550 pages
apropos Keyword Search (all sections)
Output format
RedHat logo
[printable version]

COROSYNC_OVERVIEW(Corosync Cluster Engine Programmer's ManCOROSYNC_OVERVIEW(8)

NAME
       corosync_overview - Corosync overview

OVERVIEW
       The corosync project's purpose is to implement and support a production
       quality Revised BSD licensed implementation of a high  performance  low
       overhead high availability development toolkit.

       Faults occur for various reasons:

       * Application Faults

       * Middleware Faults

       * Operating System Faults

       * Hardware Faults

       The major focus of high availability in the past has been to mask hard‐
       ware faults. Faults  in	other  components  of  the  system  have  gone
       unsolved	 until	Corosync.   Corosync  is  designed for applications to
       replicate their state to up to 16 processors.  The processors all  con‐
       tain a replica of the application state.

       The  corosync  project  provides	 a  group message API called CPG.  The
       project developers recommend CPG be used for  most  applications.   The
       CPG  service  implements	 a  closed  group  messaging  model presenting
       extended virtual synchrony guarantees.

       To manage conditions where the process executing	 the  CPG  application
       exchange	 fails,	 we  provide  the Simple Availability Manager (sam) to
       provide simple application restart.

QUICKSTART
       The corosync executive must be configured.  In the  directory  conf  in
       the  source  distribution  are several files that must be copied to the
       /etc/corosync directory.	 If corosync is packaged by a distro, this may
       be complete.

       The  directory  contains	 the  file  corosync.conf.   Please  read  the
       corosync.conf(5) man page for details  on  the  configuration  options.
       The corosync project will work out of the box with the default configu‐
       ration  options,	 although  the	administrator  may  desire   different
       options.

       The  corosync executive uses cryptographic techniques to ensure authen‐
       ticity and privacy of the messages.  In order for corosync to be secure
       and  operate, a private key must be generated and shared to all proces‐
       sors.

       First generate the key on one of the nodes:

       unix# corosync-keygen
       Corosync Cluster Engine Authentication key generator.
       Gathering 1024 bits for key from /dev/random.
       Press keys on your keyboard to generate entropy.
       Writing corosync key to /etc/corosync/authkey.

       After  this  operation,	a  private   key   will	  be   in   the	  file
       /etc/corosync/authkey.	This  private key must be copied to every pro‐
       cessor in the cluster.  If the private key isn't	 the  same  for	 every
       node,  those  nodes  with  nonmatching private keys will not be able to
       join the same configuration.

       Copy the key to some security  transportable  storage  or  use  ssh  to
       transmit the key from node to node.  Then install the key with the com‐
       mand:

       unix#:	  install     -D     --group=0	    --owner=0	   --mode=0400
       /path_to_authkey/authkey /etc/corosync/authkey

       If  a message "Invalid digest" appears from the corosync executive, the
       keys are not consistent between processors.

       Finally run the corosync executive.  If corosync	 is  packaged  from  a
       distro,	it may be set to start on system start.	 It may also be turned
       off by default in which case the	 init  script  for  corosync  must  be
       enabled.

USING LIBRARIES
       The  corosync libraries have header files which must be included in the
       developer's application.	 Once the header file is included, the	devel‐
       oper can reference the corosync interfaces.

       The  corosync  project  recommends to distros to place include files in
       /usr/include/corosync.

IPv6
       The corosync project supports both IPv4	and  IPv6  network  addresses.
       The  entire cluster must use either IPv4 or IPv6 for the cluster commu‐
       nication mechanism.  In order to use IPv6, IPv6 addresses must be spec‐
       ified  in  the  bindnetaddr  and	 mcastaddr fields in the configuration
       file.  The nodeid field must also be set.

       An example of this is: nodeid: 2 bindnetaddr:  fec0::1:a800:4ff:fe00:20
       mcastaddr: ff05::1

       To  configure  a	 host for IPv6, use the ifconfig program to add inter‐
       faces: box20:  ifconfig	eth0  add  fec0::1:a800:4ff:fe00:20/64	box30:
       ifconfig eth0 add fec0::1:a800:4ff:fe00:30/64

       If  the	/64 is not specified, a route for the IPv6 network will not be
       configured which will cause significant problems.  Make sure a route is
       available for IPv6 traffic.

ARCHITECTURE
       The  corosync libraries are a thin IPC interface to the corosync execu‐
       tive.  The corosync  executive  implements  the	functionality  of  the
       corosync APIs for distributed coming.

       The corosync executive uses the Totem extended virtual synchrony proto‐
       col.  The advantage to the end user is excellent performance character‐
       istics and a proven protocol with excellent reliability.	 This protocol
       connects the processors in a configuration together so they may	commu‐
       nicate.

ENVIRONMENT VARIABLES
       The  corosync  executive process uses four environment variables during
       startup.	 If these environment variables are not set, defaults will  be
       used.

       COROSYNC_MAIN_CONFIG_FILE
	      This specifies the fully qualified path to the corosync configu‐
	      ration file.

	      The default is /etc/corosync/corosync.conf.

       COROSYNC_TOTEM_AUTHKEY_FILE
	      This specifies the fully qualified path to the shared  key  used
	      to authenticate and encrypt data used within the Totem protocol.

	      The default is /etc/corosync/authkey.

SECURITY
       The  corosync  executive optionally encrypts all messages sent over the
       network using the AES-128 cipher.  The corosync executive uses HMAC and
       SHA1 to authenticate all messages.  The corosync executive library uses
       NSS as a pseudo random number generator.

       If membership messages can be captured by intruders, it is possible  to
       execute	a  denial of service attack on the cluster.  In this scenario,
       the cluster is likely already compromised and a DOS attack is the least
       of the administration's worries.

       The security in corosync does not offer perfect forward secrecy because
       the keys are reused.  It may be possible for an intruder	 by  capturing
       packets	in  an automated fashion to determine the shared key.  No such
       automated attack has been published as of yet.  In this	scenario,  the
       cluster is likely already compromised to allow the long-term capture of
       transmitted data.

       For security reasons, the corosync executive  binary  should  NEVER  be
       setuid or setgid in the filesystem.

BUGS
       None that are known.

SEE ALSO
       corosync.conf(5), corosync-keygen(8), cpg_overview(8), sam_overview(8)

corosync Man Page		  2012-02-13		  COROSYNC_OVERVIEW(8)
[top]

List of man pages available for RedHat

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net