Corosync supports redundant networking via its integrated Kronosnet layer by
default (it is not supported on the legacy udp/udpu transports). It can be
enabled by specifying more than one link address, either via the –linkX
parameters of pvecm, in the GUI as Link 1 (while creating a cluster or
adding a new node) or by specifying more than one ringX_addr in
corosync.conf.
|
To provide useful failover, every link should be on its own
physical network connection. |
Links are used according to a priority setting. You can configure this priority
by setting knet_link_priority in the corresponding interface section in
corosync.conf, or, preferably, using the priority parameter when creating
your cluster with pvecm:
# pvecm create CLUSTERNAME --link0 10.10.10.1,priority=15 --link1 10.20.20.1,priority=20
This would cause link1 to be used first, since it has the higher priority.
If no priorities are configured manually (or two links have the same priority),
links will be used in order of their number, with the lower number having higher
priority.
Even if all links are working, only the one with the highest priority will see
corosync traffic. Link priorities cannot be mixed, meaning that links with
different priorities will not be able to communicate with each other.
Since lower priority links will not see traffic unless all higher priorities
have failed, it becomes a useful strategy to specify networks used for
other tasks (VMs, storage, etc.) as low-priority links. If worst comes to
worst, a higher latency or more congested connection might be better than no
connection at all.
Adding Redundant Links To An Existing Cluster
Then, add a new ringX_addr to every node in the nodelist section. Make
sure that your X is the same for every node you add it to, and that it is
unique for each node.
Lastly, add a new interface, as shown below, to your totem
section, replacing X with the link number chosen above.
Assuming you added a link with number 1, the new configuration file could look
like this:
logging {
debug: off
to_syslog: yes
}
nodelist {
node {
name: due
nodeid: 2
quorum_votes: 1
ring0_addr: 10.10.10.2
ring1_addr: 10.20.20.2
}
node {
name: tre
nodeid: 3
quorum_votes: 1
ring0_addr: 10.10.10.3
ring1_addr: 10.20.20.3
}
node {
name: uno
nodeid: 1
quorum_votes: 1
ring0_addr: 10.10.10.1
ring1_addr: 10.20.20.1
}
}
quorum {
provider: corosync_votequorum
}
totem {
cluster_name: testcluster
config_version: 4
ip_version: ipv4-6
secauth: on
version: 2
interface {
linknumber: 0
}
interface {
linknumber: 1
}
}
The new link will be enabled as soon as you follow the last steps to
edit the corosync.conf file. A restart should not
be necessary. You can check that corosync loaded the new link using:
journalctl -b -u corosync
It might be a good idea to test the new link by temporarily disconnecting the
old link on one node and making sure that its status remains online while
disconnected:
If you see a healthy cluster state, it means that your new link is being used.
Summarize this content to 100 words
Corosync supports redundant networking via its integrated Kronosnet layer by
default (it is not supported on the legacy udp/udpu transports). It can be
enabled by specifying more than one link address, either via the –linkX
parameters of pvecm, in the GUI as Link 1 (while creating a cluster or
adding a new node) or by specifying more than one ringX_addr in
corosync.conf.
To provide useful failover, every link should be on its own
physical network connection.
Links are used according to a priority setting. You can configure this priority
by setting knet_link_priority in the corresponding interface section in
corosync.conf, or, preferably, using the priority parameter when creating
your cluster with pvecm:
# pvecm create CLUSTERNAME –link0 10.10.10.1,priority=15 –link1 10.20.20.1,priority=20
This would cause link1 to be used first, since it has the higher priority.
If no priorities are configured manually (or two links have the same priority),
links will be used in order of their number, with the lower number having higher
priority.
Even if all links are working, only the one with the highest priority will see
corosync traffic. Link priorities cannot be mixed, meaning that links with
different priorities will not be able to communicate with each other.
Since lower priority links will not see traffic unless all higher priorities
have failed, it becomes a useful strategy to specify networks used for
other tasks (VMs, storage, etc.) as low-priority links. If worst comes to
worst, a higher latency or more congested connection might be better than no
connection at all.
Adding Redundant Links To An Existing Cluster
Then, add a new ringX_addr to every node in the nodelist section. Make
sure that your X is the same for every node you add it to, and that it is
unique for each node.
Lastly, add a new interface, as shown below, to your totem
section, replacing X with the link number chosen above.
Assuming you added a link with number 1, the new configuration file could look
like this:
logging {
debug: off
to_syslog: yes
}
nodelist {
node {
name: due
nodeid: 2
quorum_votes: 1
ring0_addr: 10.10.10.2
ring1_addr: 10.20.20.2
}
node {
name: tre
nodeid: 3
quorum_votes: 1
ring0_addr: 10.10.10.3
ring1_addr: 10.20.20.3
}
node {
name: uno
nodeid: 1
quorum_votes: 1
ring0_addr: 10.10.10.1
ring1_addr: 10.20.20.1
}
}
quorum {
provider: corosync_votequorum
}
totem {
cluster_name: testcluster
config_version: 4
ip_version: ipv4-6
secauth: on
version: 2
interface {
linknumber: 0
}
interface {
linknumber: 1
}
}
The new link will be enabled as soon as you follow the last steps to
edit the corosync.conf file. A restart should not
be necessary. You can check that corosync loaded the new link using:
journalctl -b -u corosync
It might be a good idea to test the new link by temporarily disconnecting the
old link on one node and making sure that its status remains online while
disconnected:
If you see a healthy cluster state, it means that your new link is being used.
