1COROSYNC_CONF(5) Corosync Cluster Engine Programmer's Manual COROSYNC_CONF(5)
2
6 corosync.conf - corosync executive configuration file
7
10 /etc/corosync/corosync.conf
11
14 The corosync.conf instructs the corosync executive about various param‐
15 eters needed to control the corosync executive. Empty lines and lines
16 starting with # character are ignored. The configuration file consists
17 of bracketed top level directives. The possible directive choices are:
18 totem { }
21 This top level directive contains configuration options for the
22 totem protocol.
23 logging { }
25 This top level directive contains configuration options for log‐
26 ging.
27 quorum { }
29 This top level directive contains configuration options for quo‐
30 rum.
31 nodelist { }
33 This top level directive contains configuration options for
34 nodes in cluster.
35 system { }
37 This top level directive contains configuration options related
38 to system.
39 resources { }
41 This top level directive contains configuration options for
42 resources.
43 nozzle { }
45 This top level directive contains configuration options for a
46 libnozzle device.
47 The interface sub-directive of totem is optional for UDP and knet
50 transports.
51 For knet, multiple interface subsections define parameters for each
53 knet link on the system.
54 For UDPU an interface section is not needed and it is recommended that
56 the nodelist is used to define cluster nodes.
57 linknumber
60 This specifies the link number for the interface. When using
61 the knet protocol, each interface should specify separate link
62 numbers to uniquely identify to the membership protocol which
63 interface to use for which link. The linknumber must start at
64 0. For UDP the only supported linknumber is 0.
65 knet_link_priority
68 This specifies the priority for the link when knet is used in
69 'passive' mode. (see link_mode below)
70 knet_ping_interval
73 This specifies the interval between knet link pings.
74 knet_ping_interval and knet_ping_timeout are a pair, if one is
75 specified the other should be too, otherwise one will be calcu‐
76 lated from the token timeout and one will be taken from the con‐
77 fig file. (default is token timeout / (knet_pong_count*2))
78 knet_ping_timeout
81 If no ping is received within this time, the knet link is
82 declared dead. knet_ping_interval and knet_ping_timeout are a
83 pair, if one is specified the other should be too, otherwise one
84 will be calculated from the token timeout and one will be taken
85 from the config file. (default is token timeout /
86 knet_pong_count)
87 knet_ping_precision
90 How many values of latency are used to calculate the average
91 link latency. (default 2048 samples)
92 knet_pong_count
95 How many valid ping/pongs before a link is marked UP. (default
96 2)
97 knet_transport
100 Which IP transport knet should use. valid values are "sctp" or
101 "udp". (default: udp)
102 bindnetaddr (udp only)
105 This specifies the network address the corosync executive should
106 bind to when using udp.
107 bindnetaddr (udp only) should be an IP address configured on the
109 system, or a network address.
110 For example, if the local interface is 192.168.5.92 with netmask
112 255.255.255.0, you should set bindnetaddr to 192.168.5.92 or
113 192.168.5.0. If the local interface is 192.168.5.92 with net‐
114 mask 255.255.255.192, set bindnetaddr to 192.168.5.92 or
115 192.168.5.64, and so forth.
116 This may also be an IPV6 address, in which case IPV6 networking
118 will be used. In this case, the exact address must be specified
119 and there is no automatic selection of the network interface
120 within a specific subnet as with IPv4.
121 If IPv6 networking is used, the nodeid field in nodelist must be
123 specified.
124 broadcast (udp only)
127 This is optional and can be set to yes. If it is set to yes,
128 the broadcast address will be used for communication. If this
129 option is set, mcastaddr should not be set.
130 mcastaddr (udp only)
133 This is the multicast address used by corosync executive. The
134 default should work for most networks, but the network adminis‐
135 trator should be queried about a multicast address to use.
136 Avoid 224.x.x.x because this is a "config" multicast address.
137 This may also be an IPV6 multicast address, in which case IPV6
139 networking will be used. If IPv6 networking is used, the nodeid
140 field in nodelist must be specified.
141 It's not necessary to use this option if cluster_name option is
143 used. If both options are used, mcastaddr has higher priority.
144 mcastport (udp only)
147 This specifies the UDP port number. It is possible to use the
148 same multicast address on a network with the corosync services
149 configured for different UDP ports. Please note corosync uses
150 two UDP ports mcastport (for mcast receives) and mcastport - 1
151 (for mcast sends). If you have multiple clusters on the same
152 network using the same mcastaddr please configure the mcastports
153 with a gap.
154 ttl (udp only)
157 This specifies the Time To Live (TTL). If you run your cluster
158 on a routed network then the default of "1" will be too small.
159 This option provides a way to increase this up to 255. The valid
160 range is 0..255.
161 Within the totem directive, there are seven configuration options of
164 which one is required, five are optional, and one is required when IPV6
165 is configured in the interface subdirective. The required directive
166 controls the version of the totem configuration. The optional option
167 unless using IPV6 directive controls identification of the processor.
168 The optional options control secrecy and authentication, the network
169 mode of operation and maximum network MTU field.
170 version
173 This specifies the version of the configuration file. Currently
174 the only valid version for this directive is 2.
175 clear_node_high_bit
178 This configuration option is optional and is only relevant when
179 no nodeid is specified. Some corosync clients require a signed
180 32 bit nodeid that is greater than zero however by default
181 corosync uses all 32 bits of the IPv4 address space when gener‐
182 ating a nodeid. Set this option to yes to force the high bit to
183 be zero and therefore ensure the nodeid is a positive signed 32
184 bit integer.
185 WARNING: Cluster behavior is undefined if this option is enabled
187 on only a subset of the cluster (for example during a rolling
188 upgrade).
189 crypto_model
192 This specifies which cryptographic library should be used by
193 knet. Options are nss and openssl.
194 The default is nss.
196 crypto_hash
199 This specifies which HMAC authentication should be used to
200 authenticate all messages. Valid values are none (no authentica‐
201 tion), md5, sha1, sha256, sha384 and sha512. Encrypted transmis‐
202 sion is only supported for the knet transport.
203 The default is none.
205 crypto_cipher
208 This specifies which cipher should be used to encrypt all mes‐
209 sages. Valid values are none (no encryption), aes256, aes192
210 and aes128. Enabling crypto_cipher, requires also enabling of
211 crypto_hash. Encrypted transmission is only supported for the
212 knet transport.
213 The default is none.
215 secauth
218 This implies crypto_cipher=aes256 and crypto_hash=sha256, unless
219 those options are explicitly set. Encrypted transmission is only
220 supported for the knet transport.
221 The default is off.
223 keyfile
226 This specifies the fully qualified path to the shared key used
227 to authenticate and encrypt data used within the Totem protocol.
228 The default is /etc/corosync/authkey.
230 key Shared key stored in configuration instead of authkey file. This
233 option has lower precedence than keyfile option so it's used
234 only when keyfile is not specified. Using this option is not
235 recommended for security reasons.
236 link_mode
239 This specifies the Kronosnet mode, which may be passive, active,
240 or rr (round-robin). passive: the active link with the highest
241 priority (highest number) will be used. If one or more links
242 share the same priority the one with the lowest link ID will be
243 used. active: All active links will be used simultaneously to
244 send traffic. link priority is ignored. rr: Round-Robin pol‐
245 icy. Each packet will be sent to the next active link in order.
246 If only one interface directive is specified, passive is auto‐
248 matically chosen.
249 The maximum number of interface directives that is allowed with
251 Kronosnet is 8. For other transports it is 1.
252 netmtu This specifies the network maximum transmit unit. To set this
255 value beyond 1500, the regular frame MTU, requires ethernet
256 devices that support large, or also called jumbo, frames. If
257 any device in the network doesn't support large frames, the pro‐
258 tocol will not operate properly. The hosts must also have their
259 mtu size set from 1500 to whatever frame size is specified here.
260 Please note while some NICs or switches claim large frame sup‐
262 port, they support 9000 MTU as the maximum frame size including
263 the IP header. Setting the netmtu and host MTUs to 9000 will
264 cause totem to use the full 9000 bytes of the frame. Then Linux
265 will add a 18 byte header moving the full frame size to 9018.
266 As a result some hardware will not operate properly with this
267 size of data. A netmtu of 8982 seems to work for the few large
268 frame devices that have been tested. Some manufacturers claim
269 large frame support when in fact they support frame sizes of
270 4500 bytes.
271 When sending multicast traffic, if the network frequently recon‐
273 figures, chances are that some device in the network doesn't
274 support large frames.
275 Choose hardware carefully if intending to use large frame sup‐
277 port.
278 The default is 1500.
280 transport
283 This directive controls the transport mechanism used. The
284 default is knet. The transport type can also be set to udpu or
285 udp. Only knet allows crypto or multiple interfaces per node.
286 cluster_name
289 This specifies the name of cluster and it's used for automatic
290 generating of multicast address.
291 config_version
294 This specifies version of config file. This is converted to
295 unsigned 64-bit int. By default it's 0. Option is used to pre‐
296 vent joining old nodes with not up-to-date configuration. If
297 value is not 0, and node is going for first time (only for first
298 time, join after split doesn't follow this rules) from single-
299 node membership to multiple nodes membership, other nodes con‐
300 fig_versions are collected. If current node config_version is
301 not equal to highest of collected versions, corosync is termi‐
302 nated.
303 ip_version
306 This specifies version of IP to ask DNS resolver for. The value
307 can be one of ipv4 (look only for an IPv4 address) , ipv6 (check
308 only IPv6 address) , ipv4-6 (look for all address families and
309 use first IPv4 address found in the list if there is such
310 address, otherwise use first IPv6 address) and ipv6-4 (look for
311 all address families and use first IPv6 address found in the
312 list if there is such address, otherwise use first IPv4
313 address).
314 Default (if unspecified) is ipv6-4 for knet and udpu transports
316 and ipv4 for udp.
317 The knet transport supports IPv4 and IPv6 addresses concur‐
319 rently, provided they are consistent on each link.
320 Within the totem directive, there are several configuration
322 options which are used to control the operation of the protocol.
323 It is generally not recommended to change any of these values
324 without proper guidance and sufficient testing. Some networks
325 may require larger values if suffering from frequent reconfigu‐
326 rations. Some applications may require faster failure detection
327 times which can be achieved by reducing the token timeout.
328 token This timeout is used directly or as a base for real token time‐
331 out calculation (explained in token_coefficient section). Token
332 timeout specifies in milliseconds until a token loss is declared
333 after not receiving a token. This is the time spent detecting a
334 failure of a processor in the current configuration. Reforming
335 a new configuration takes about 50 milliseconds in addition to
336 this timeout.
337 For real token timeout used by totem it's possible to read cmap
339 value of runtime.config.totem.token key.
340 Be careful to use the same timeout values on each of the nodes
342 in the cluster or unpredictable results may occur.
343 The default is 1000 milliseconds.
345 token_warning
348 Specifies the interval between warnings that the token has not
349 been received. The value is a percentage of the token timeout
350 and can be set to 0 to disable warnings.
351 The default is 75%.
353 token_coefficient
356 This value is used only when nodelist section is specified and
357 contains at least 3 nodes. If so, real token timeout is then
358 computed as token + (number_of_nodes - 2) * token_coefficient.
359 This allows cluster to scale without manually changing token
360 timeout every time new node is added. This value can be set to 0
361 resulting in effective removal of this feature.
362 The default is 650 milliseconds.
364 token_retransmit
367 This timeout specifies in milliseconds after how long before
368 receiving a token the token is retransmitted. This will be
369 automatically calculated if token is modified. It is not recom‐
370 mended to alter this value without guidance from the corosync
371 community.
372 The minimum is 30 milliseconds. If not set and error occur, make
374 sure token / (token_retransmits_before_loss_const + 0.2) is more
375 than 30.
376 The default is 238 milliseconds for two nodes cluster. Three or
378 more nodes reference token_coefficient.
379 knet_compression_model
382 The (optional) type of compression used by Kronosnet. The values
383 available depend on the build and also avaialable libraries.
384 Typically zlib and lz4 will be available but bzip2 and others
385 could also be allowed. The default is 'none'
386 knet_compression_threshold
389 Tells knet to NOT compress any packets that are smaller than the
390 value indicated. Default 100 bytes.
391 Set to 0 to reset to the default. Set to 1 to compress every‐
393 thing.
394 knet_compression_level
397 Many compression libraries allow tuning of compression parame‐
398 ters. For example 0 or 1 ... 9 are commonly used to determine
399 the level of compression. This value is passed unmodified to the
400 compression library so it is recommended to consult the
401 library's documentation for more detailed information.
402 hold This timeout specifies in milliseconds how long the token should
405 be held by the representative when the protocol is under low
406 utilization. It is not recommended to alter this value without
407 guidance from the corosync community.
408 The default is 180 milliseconds.
410 token_retransmits_before_loss_const
413 This value identifies how many token retransmits should be
414 attempted before forming a new configuration. It is also used
415 for token_retransmit and hold calculations.
416 The default is 4 retransmissions.
418 join This timeout specifies in milliseconds how long to wait for join
421 messages in the membership protocol.
422 The default is 50 milliseconds.
424 send_join
427 This timeout specifies in milliseconds an upper range between 0
428 and send_join to wait before sending a join message. For con‐
429 figurations with less than 32 nodes, this parameter is not nec‐
430 essary. For larger rings, this parameter is necessary to ensure
431 the NIC is not overflowed with join messages on formation of a
432 new ring. A reasonable value for large rings (128 nodes) would
433 be 80msec. Other timer values must also change if this value is
434 changed. Seek advice from the corosync mailing list if trying
435 to run larger configurations.
436 The default is 0 milliseconds.
438 consensus
441 This timeout specifies in milliseconds how long to wait for con‐
442 sensus to be achieved before starting a new round of membership
443 configuration. The minimum value for consensus must be 1.2 *
444 token. This value will be automatically calculated at 1.2 *
445 token if the user doesn't specify a consensus value.
446 For two node clusters, a consensus larger than the join timeout
448 but less than token is safe. For three node or larger clusters,
449 consensus should be larger than token. There is an increasing
450 risk of odd membership changes, which still guarantee virtual
451 synchrony, as node count grows if consensus is less than token.
452 The default is 1200 milliseconds.
454 merge This timeout specifies in milliseconds how long to wait before
457 checking for a partition when no multicast traffic is being
458 sent. If multicast traffic is being sent, the merge detection
459 happens automatically as a function of the protocol.
460 The default is 200 milliseconds.
462 downcheck
465 This timeout specifies in milliseconds how long to wait before
466 checking that a network interface is back up after it has been
467 downed.
468 The default is 1000 milliseconds.
470 fail_recv_const
473 This constant specifies how many rotations of the token without
474 receiving any of the messages when messages should be received
475 may occur before a new configuration is formed.
476 The default is 2500 failures to receive a message.
478 seqno_unchanged_const
481 This constant specifies how many rotations of the token without
482 any multicast traffic should occur before the hold timer is
483 started.
484 The default is 30 rotations.
486 heartbeat_failures_allowed
489 [HeartBeating mechanism] Configures the optional HeartBeating
490 mechanism for faster failure detection. Keep in mind that engag‐
491 ing this mechanism in lossy networks could cause faulty loss
492 declaration as the mechanism relies on the network for heart‐
493 beating.
494 So as a rule of thumb use this mechanism if you require improved
496 failure in low to medium utilized networks.
497 This constant specifies the number of heartbeat failures the
499 system should tolerate before declaring heartbeat failure e.g 3.
500 Also if this value is not set or is 0 then the heartbeat mecha‐
501 nism is not engaged in the system and token rotation is the
502 method of failure detection
503 The default is 0 (disabled).
505 max_network_delay
508 [HeartBeating mechanism] This constant specifies in milliseconds
509 the approximate delay that your network takes to transport one
510 packet from one machine to another. This value is to be set by
511 system engineers and please don't change if not sure as this
512 effects the failure detection mechanism using heartbeat.
513 The default is 50 milliseconds.
515 window_size
518 This constant specifies the maximum number of messages that may
519 be sent on one token rotation. If all processors perform
520 equally well, this value could be large (300), which would
521 introduce higher latency from origination to delivery for very
522 large rings. To reduce latency in large rings(16+), the
523 defaults are a safe compromise. If 1 or more slow processor(s)
524 are present among fast processors, window_size should be no
525 larger than 256000 / netmtu to avoid overflow of the kernel
526 receive buffers. The user is notified of this by the display of
527 a retransmit list in the notification logs. There is no loss of
528 data, but performance is reduced when these errors occur.
529 The default is 50 messages.
531 max_messages
534 This constant specifies the maximum number of messages that may
535 be sent by one processor on receipt of the token. The max_mes‐
536 sages parameter is limited to 256000 / netmtu to prevent over‐
537 flow of the kernel transmit buffers.
538 The default is 17 messages.
540 miss_count_const
543 This constant defines the maximum number of times on receipt of
544 a token a message is checked for retransmission before a
545 retransmission occurs. This parameter is useful to modify for
546 switches that delay multicast packets compared to unicast pack‐
547 ets. The default setting works well for nearly all modern
548 switches.
549 The default is 5 messages.
551 knet_pmtud_interval
554 How often the knet PMTUd runs to look for network MTU changes.
555 Value in seconds, default: 30
556 block_unlisted_ips
559 Allow UDPU and KNET to drop packets from IP addresses that are
560 not known (nodes which don't exist in the nodelist) to corosync.
561 Value is yes or no.
562 This feature is mainly to protect against the joining of nodes
564 with outdated configurations after a cluster split. Another use
565 case is to allow the atomic merge of two independent clusters.
566 Changing the default value is not recommended, the overhead is
568 tiny and an existing cluster may fail if corosync is started on
569 an unlisted node with an old configuration.
570 The default value is yes.
572 Within the logging directive, there are several configuration options
575 which are all optional.
576 The following 3 options are valid only for the top level logging direc‐
579 tive:
580 timestamp
583 This specifies that a timestamp is placed on all log messages.
584 It can be one of off (no timestamp), on (second precision time‐
585 stamp) or hires (millisecond precision timestamp - only when
586 supported by LibQB).
587 The default is hires (or on if hires is not supported).
589 fileline
592 This specifies that file and line should be printed.
593 The default is off.
595 function_name
598 This specifies that the code function name should be printed.
599 The default is off.
601 blackbox
604 This specifies that blackbox functionality should be enabled.
605 The default is on.
607 The following options are valid both for top level logging directive
610 and they can be overridden in logger_subsys entries.
611 to_stderr
614 to_logfile
616 to_syslog
618 These specify the destination of logging output. Any combination
619 of these options may be specified. Valid options are yes and no.
620 The default is syslog and stderr.
622 Please note, if you are using to_logfile and want to rotate the
624 file, use logrotate(8) with the option copytruncate. eg.
625 /var/log/corosync.log {
626 missingok
627 compress
628 notifempty
629 daily
630 rotate 7
631 copytruncate
632 }
633 logfile
636 If the to_logfile directive is set to yes , this option speci‐
637 fies the pathname of the log file.
638 No default.
640 logfile_priority
643 This specifies the logfile priority for this particular subsys‐
644 tem. Ignored if debug is on. Possible values are: alert, crit,
645 debug (same as debug = on), emerg, err, info, notice, warning.
646 The default is: info.
648 syslog_facility
651 This specifies the syslog facility type that will be used for
652 any messages sent to syslog. options are daemon, local0, local1,
653 local2, local3, local4, local5, local6 & local7.
654 The default is daemon.
656 syslog_priority
659 This specifies the syslog level for this particular subsystem.
660 Ignored if debug is on. Possible values are: alert, crit, debug
661 (same as debug = on), emerg, err, info, notice, warning.
662 The default is: info.
664 debug This specifies whether debug output is logged for this particu‐
667 lar logger. Also can contain value trace, what is highest level
668 of debug information.
669 The default is off.
671 Within the logging directive, logger_subsys directives are optional.
674 Within the logger_subsys sub-directive, all of the above logging con‐
677 figuration options are valid and can be used to override the default
678 settings. The subsys entry, described below, is mandatory to identify
679 the subsystem.
680 subsys This specifies the subsystem identity (name) for which logging
683 is specified. This is the name used by a service in the
684 log_init() call. E.g. 'CPG'. This directive is required.
685 Within the quorum directive it is possible to specify the quorum algo‐
688 rithm to use with the
689 provider
692 directive. At the time of writing only corosync_votequorum is
693 supported. See votequorum(5) for configuration options.
694 Within the nodelist directive it is possible to specify specific infor‐
697 mation about nodes in cluster. Directive can contain only node sub-
698 directive, which specifies every node that should be a member of the
699 membership, and where non-default options are needed. Every node must
700 have at least ring0_addr field filled.
701 Every node that should be a member of the membership must be specified.
703 Possible options are:
705 ringX_addr
707 This specifies IP or network hostname address of the particular
708 node. X is a link number.
709 nodeid This configuration option is required for each node for Kronos‐
712 net mode. It is a 32 bit value specifying the node identifier
713 delivered to the cluster membership service. The node identifier
714 value of zero is reserved and should not be used. If knet is
715 set, this field must be set.
716 name This option is used mainly with knet transport to identify local
719 node. It's also used by client software (pacemaker). Algorithm
720 for identifying local node is following:
721 1. Looks up $HOSTNAME in the nodelist
723 2. If this fails strip the domain name from $HOSTNAME and
725 looks up that in the nodelist
726 3. If this fails look in the nodelist for a fully-qualified
728 name whose short version matches the short version of
729 $HOSTNAME
730 4. If all this fails then search the interfaces list for an
732 address that matches a name in the nodelist
733 Within the system directive it is possible to specify system options.
736 Possible options are:
738 qb_ipc_type
740 This specifies type of IPC to use. Can be one of native
741 (default), shm and socket. Native means one of shm or socket,
742 depending on what is supported by OS. On systems with support
743 for both, SHM is selected. SHM is generally faster, but need to
744 allocate ring buffer file in /dev/shm.
745 sched_rr
748 Should be set to yes (default) if corosync should try to set
749 round robin realtime scheduling with maximal priority to itself.
750 When setting of scheduler fails, fallback to set maximal prior‐
751 ity.
752 priority
755 Set priority of corosync process. Valid only when sched_rr is
756 set to no. Can be ether numeric value with similar meaning as
757 nice(1) or max / min meaning maximal / minimal priority (so min‐
758 imal / maximal nice value).
759 move_to_root_cgroup
762 Should be set to yes (default) if corosync should try to move
763 itself to root cgroup. This feature is available only for sys‐
764 tems with cgroups with RT sched enabled (Linux with CON‐
765 FIG_RT_GROUP_SCHED kernel option).
766 state_dir
769 Existing directory where corosync should chdir into. Corosync
770 stores important state files and blackboxes there.
771 The default is /var/lib/corosync.
773 Within the resources directive it is possible to specify options for
776 resources.
777 Possible option is:
779 watchdog_device
781 (Valid only if Corosync was compiled with watchdog support.)
782 Watchdog device to use, for example /dev/watchdog. If unset,
783 empty or "off", no watchdog is used.
784 In a cluster with properly configured power fencing a watchdog
786 provides no additional value. On the other hand, slow watchdog
787 communication may incur multi-second delays in the Corosync main
788 loop, potentially breaking down membership. IPMI watchdogs are
789 particularly notorious in this regard: read about kip‐
790 mid_max_busy_us in IPMI.txt in the Linux kernel documentation.
791 Within the nozzle directive it is possible to specify options for a
795 libnozzle device. This is a pseudo ethernet device that routes network
796 traffic through a channel on the corosync knet network (NOT cpg or any
797 corosync internal service) to other nodes in the cluster. This allows
798 applications to take advantage of knet features such as multipathing,
799 automatic failover, link switching etc. Note that libnozzle is not a
800 reliable transport, but you can tunnel TCP through it for reliable com‐
801 munications.
802 libnozzle also supports optional interface up/down scripts that are
803 kept under a /etc/corosync/updown.d/ directory. See the knet documenta‐
804 tion for more information.
805 Only one nozzle device is allowed.
806 The nozzle stanza takes several options:
807 name The name of the network device to be created. On Linux this may
809 be any name at all, other platforms have restrictions on the
810 name.
811 ipaddr The IP address (IPv6 or IPv4) of the interface. The bottom part
813 of this address will be replaced by the local node's nodeid in
814 conjunction with ipprefix. so, eg ipaddr: 192.168.1.0 ipprefix:
815 24 will make nodeids 1,2,5 use IP addresses 192.168.1.1,
816 192.168.1.2 & 192.168.1.5. If a prefix length of 16 is used
817 then the bottom two bytes will be filled in with nodeid numbers.
818 IPv6 addresses must end in '::', the nodeid will be added after
819 the two colons to make the local IP address. Only one IP
820 address is currently supported in the corosync.conf file. Addi‐
821 tional IP addresses can be added in the ifup script if neces‐
822 sary.
823 ipprefix
825 specifies the IP address prefix for the nozzle device (see
826 above)
827 macaddr
829 Specifies the MAC address prefix for the nozzle device. As for
830 the IP address, the bottom part of the MAC address will be
831 filled in with the node id. In this case no prefix applies, the
832 bottom two bytes of the MAC address will always be overwritten
833 with the node id. So specifying macaddr: 54:54:12:24:12:12 on
834 nodeid 1 will result in it having a MAC address of
835 54:54:12:24:00:01
836
839 For example to add a node with address 10.24.38.108 with nodeid 3. The
840 node has the name NEW (in DNS or /etc/hosts) and is not currently run‐
841 ning corosync. The current corosync.conf nodelist looks like this:
842 nodelist {
844 node {
845 nodeid: 1
846 ring0_addr: 10.24.38.101
847 name: node1
848 }
849 node {
850 nodeid: 2
851 ring0_addr: 10.24.38.102
852 name: node2
853 }
855 }
856 Add a new entry for the node below the existing nodes. Node entries
858 don't have to be in nodeid order, but it will help keep you sane. So
859 the nodelist now looks like this:
860 nodelist {
862 node {
863 nodeid: 1
864 ring0_addr: 10.24.38.101
865 name: node1
866 }
867 node {
868 nodeid: 2
869 ring0_addr: 10.24.38.102
870 name: node2
871 }
873 node {
874 nodeid: 3
875 ring0_addr: 10.24.38.108
876 name: NEW
877 }
879 }
880 This file must then be copied onto all three nodes - the existing two
882 nodes, and the new one. On one of the existing corosync nodes, tell
883 corosync to re-read the updated config file into memory:
884 corosync-cfgtool -R
886 This command only needs to be run on one node in the cluster. You may
888 then start corosync on the NEW node and it should join the cluster. If
889 this doesn't work as expected then check the communications between all
890 three nodes is working, and check the syslog files on all nodes for
891 more information. It's important to note that the key bit of informa‐
892 tion about a node failing to join might be on a different node than you
893 expect.
894
897 This is the reverse procedure to 'Adding a node' above. First you need
898 to shut down the node you will be removing from the cluster.
899 corosync-cfgtool -H
901 Then delete the nodelist stanza from corosync.conf and finally update
905 corosync on the remaining nodes by running
906 corosync-cfgtool -R
908 on one of them.
910
913 corosync resolves ringX_addr names/IP addresses using the getad‐
914 drinfo(3) call with respect of totem.ip_version setting.
915 getaddrinfo() function uses a sophisticated algorithm to sort node
917 addresses into a preferred order and corosync always chooses the first
918 address in that list of the required family. As such it is essential
919 that your DNS or /etc/hosts files are correctly configured so that all
920 addresses for ringX appear on the same network (or are reachable with
921 minimal hops) and over the same IP protocol. If this is not the case
922 then some nodes might not be able to join the cluster. It is possible
923 to override the search order used by getaddrinfo() using the configura‐
924 tion file /etc/gai.conf(5) if necessary, but this is not recommended.
925 If there is any doubt about the order of addresses returned from getad‐
927 drinfo() then it might be simpler to use IP addresses (v4 or v6) in the
928 ringX_addr field.
929
932 /etc/corosync/corosync.conf
933 The corosync executive configuration file.
934
937 corosync_overview(7), votequorum(5), corosync-qdevice(8), logrotate(8)
938 getaddrinfo(3) gai.conf(5)
939corosync Man Page 2020-02-25 COROSYNC_CONF(5)