hacluster set blocked status when corosync_key is missing, but secauth is always off
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack HA Cluster Charm |
Triaged
|
Medium
|
Unassigned | ||
hacluster (Juju Charms Collection) |
Invalid
|
Undecided
|
Unassigned |
Bug Description
hacluster charms considers as mandatory set corosync_key, when it's not set the charm set the service in blocked state[0], but the corosync.conf template set secauth to off[1], so the key is never used[2]
The secauth config key should be set to 'on' when the corosync_key is set (!='' or !=null)
[Regression Potential]
As corosync_key has been mandatory, but secauth off, we may find environments where the cluster breaks or performance is degraded due to the overhead added by the encryption[3].
[0] https:/
[1] https:/
[2] https:/
[3] from corosync.conf(5): "Enabling this option adds a encryption header to every message sent by totem which reduces total throughput. Also encryption and authentication consume extra CPU cycles in corosync."
Changed in hacluster (Juju Charms Collection): | |
status: | New → Invalid |
Changed in charm-hacluster: | |
milestone: | 17.05 → 17.08 |
Changed in charm-hacluster: | |
milestone: | 17.08 → 17.11 |
Changed in charm-hacluster: | |
milestone: | 17.11 → 18.02 |
Changed in charm-hacluster: | |
milestone: | 18.02 → 18.05 |
Changed in charm-hacluster: | |
milestone: | 18.05 → 18.08 |
Changed in charm-hacluster: | |
milestone: | 18.08 → 18.11 |
Changed in charm-hacluster: | |
milestone: | 18.11 → 19.04 |
Changed in charm-hacluster: | |
milestone: | 19.04 → 19.07 |
Changed in charm-hacluster: | |
milestone: | 19.07 → 19.10 |
Changed in charm-hacluster: | |
milestone: | 19.10 → 20.01 |
Changed in charm-hacluster: | |
milestone: | 20.01 → 20.05 |
Changed in charm-hacluster: | |
milestone: | 20.05 → 20.08 |
Changed in charm-hacluster: | |
milestone: | 20.08 → none |
I agree on the risk of a performance regression by fixing this problem.
secauth
This specifies that HMAC/SHA1 authentication should be used to authenticate all messages. It further specifies that all data should be encrypted with the sober128 encryption algorithm to protect data from eavesdropping.
Enabling this option adds a 36 byte header to every message sent by totem which reduces total throughput. Encryption and authentication consume 75% of CPU cycles in aisexec as measured with gprof when enabled.
For 100mbit networks with 1500 MTU frame transmissions: A throughput of 9mb/sec is possible with 100% cpu utilization when this option is enabled on 3ghz cpus. A throughput of 10mb/sec is possible wth 20% cpu utilization when this optin is disabled on 3ghz cpus.
For gig-e networks with large frame transmissions: A throughput of 20mb/sec is possible when this option is enabled on 3ghz cpus. A throughput of 60mb/sec is possible when this option is disabled on 3ghz cpus.
The default is on.