1COROSYNC_OVERVIEW(7C)orosync Cluster Engine Programmer's ManuCaOlROSYNC_OVERVIEW(7)
2
3
4

NAME

6       corosync_overview - Corosync overview
7

OVERVIEW

9       The corosync project's purpose is to implement and support a production
10       quality Revised BSD licensed implementation of a high  performance  low
11       overhead high availability development toolkit.
12
13       Faults occur for various reasons:
14
15       * Application Faults
16
17       * Middleware Faults
18
19       * Operating System Faults
20
21       * Hardware Faults
22
23       The major focus of high availability in the past has been to mask hard‐
24       ware faults. Faults  in  other  components  of  the  system  have  gone
25       unsolved  until  Corosync.   Corosync  is  designed for applications to
26       replicate their state to up to 16 processors.  The processors all  con‐
27       tain a replica of the application state.
28
29       The  corosync  project  provides  a  group message API called CPG.  The
30       project developers recommend CPG be used for  most  applications.   The
31       CPG  service  implements  a  closed  group  messaging  model presenting
32       extended virtual synchrony guarantees.
33
34       To manage conditions where the process executing  the  CPG  application
35       exchange  fails,  we  provide  the Simple Availability Manager (sam) to
36       provide simple application restart.
37
38

QUICKSTART

40       The corosync executive must be configured.  In the  directory  conf  in
41       the  source  distribution  are several files that must be copied to the
42       /etc/corosync directory.  If corosync is packaged by a distro, this may
43       be complete.
44
45       The  directory  contains  the  file  corosync.conf.   Please  read  the
46       corosync.conf(5) man page for details  on  the  configuration  options.
47       The corosync project will work out of the box with the default configu‐
48       ration  options,  although  the  administrator  may  desire   different
49       options.
50
51       The  corosync executive uses cryptographic techniques to ensure authen‐
52       ticity and privacy of the messages.  In order for corosync to be secure
53       and  operate, a private key must be generated and shared to all proces‐
54       sors.
55
56       First generate the key on one of the nodes:
57
58       unix# corosync-keygen
59       Corosync Cluster Engine Authentication key generator.
60       Gathering 2048 bits for key from /dev/urandom.
61       Writing corosync key to /etc/corosync/authkey.
62
63       After  this  operation,  a  private   key   will   be   in   the   file
64       /etc/corosync/authkey.   This  private key must be copied to every pro‐
65       cessor in the cluster.  If the private key isn't  the  same  for  every
66       node,  those  nodes  with  nonmatching private keys will not be able to
67       join the same configuration.
68
69       Copy the key to some security  transportable  storage  or  use  ssh  to
70       transmit the key from node to node.  Then install the key with the com‐
71       mand:
72
73       unix#:     install     -D     --group=0      --owner=0      --mode=0400
74       /path_to_authkey/authkey /etc/corosync/authkey
75
76       If  a message "Invalid digest" appears from the corosync executive, the
77       keys are not consistent between processors.
78
79       Finally run the corosync executive.  If corosync  is  packaged  from  a
80       distro,  it may be set to start on system start.  It may also be turned
81       off by default in which case the  init  script  for  corosync  must  be
82       enabled.
83
84

USING LIBRARIES

86       The  corosync libraries have header files which must be included in the
87       developer's application.  Once the header file is included, the  devel‐
88       oper can reference the corosync interfaces.
89
90       The  corosync  project  recommends to distros to place include files in
91       /usr/include/corosync.
92
93

IPv6

95       The corosync project supports both IPv4  and  IPv6  network  addresses.
96       The  entire cluster must use either IPv4 or IPv6 for the cluster commu‐
97       nication mechanism.  In order to use IPv6, IPv6 addresses must be spec‐
98       ified  in  the  bindnetaddr  and  mcastaddr fields in the configuration
99       file.  The nodeid field must also be set.
100
101       An example of this is: nodeid: 2 bindnetaddr:  fec0::1:a800:4ff:fe00:20
102       mcastaddr: ff05::1
103
104       To  configure  a  host for IPv6, use the ifconfig program to add inter‐
105       faces: box20:  ifconfig  eth0  add  fec0::1:a800:4ff:fe00:20/64  box30:
106       ifconfig eth0 add fec0::1:a800:4ff:fe00:30/64
107
108       If  the  /64 is not specified, a route for the IPv6 network will not be
109       configured which will cause significant problems.  Make sure a route is
110       available for IPv6 traffic.
111
112

ARCHITECTURE

114       The  corosync libraries are a thin IPC interface to the corosync execu‐
115       tive.  The corosync  executive  implements  the  functionality  of  the
116       corosync APIs for distributed coming.
117
118       The corosync executive uses the Totem extended virtual synchrony proto‐
119       col.  The advantage to the end user is excellent performance character‐
120       istics and a proven protocol with excellent reliability.  This protocol
121       connects the processors in a configuration together so they may  commu‐
122       nicate.
123
124

SECURITY

126       The  corosync executive optionally encrypts and signs all messages sent
127       over the network. For more details see  crypto_model,  crypto_hash  and
128       crypto_cipher options in the corosync.conf(5).
129
130       If  membership messages can be captured by intruders, it is possible to
131       execute a denial of service attack on the cluster.  In  this  scenario,
132       the cluster is likely already compromised and a DOS attack is the least
133       of the administration's worries.
134
135       The security in corosync does not offer perfect forward secrecy because
136       the  keys  are reused.  It may be possible for an intruder by capturing
137       packets in an automated fashion to determine the shared key.   No  such
138       automated  attack  has been published as of yet.  In this scenario, the
139       cluster is likely already compromised to allow the long-term capture of
140       transmitted data.
141
142       For  security  reasons,  the  corosync executive binary should NEVER be
143       setuid or setgid in the filesystem.
144
145

BUGS

147       None that are known.
148
149

SEE ALSO

151       corosync.conf(5), corosync-keygen(8), cpg_overview(3), sam_overview(3)
152
153corosync Man Page                 2018-11-13              COROSYNC_OVERVIEW(7)
Impressum