Marcin Wilk
5dff73cb3a
Previously, the charm configured masakari-monitors with the following
defaults for host monitoring:
- monitoring_interval: 60 seconds
- monitoring_samples: 1
The values were hardcoded in the configuration file template.
With only a single sample, any transient OFFLINE state captured
during a masakari control plane shutdown or restart could trigger
a notification — potentially placing healthy compute nodes into
maintenance. This can occur during ownership transitions between
control nodes, when pacemaker-remote nodes may briefly appear offline.
This commit mitigates the issue by exposing the aforementioned
configurations knobs as Juju config options. Now, a user has
possibility to adjust the interval and samples on a running cloud,
within the predefined boundaries:
- monitoring-interval option: between 10 and 300 seconds
- monitoring-samples option: between 1 and 5
On the pacemaker-remote nodes, ('restrict_to_remotes==True'),
masakari-monitors use 'crm_mon -X' command to check the cluster status.
The pacemaker-remote node queries a cluster node running the Pacemaker,
which continuously maintains the state (via subscribtion to the Corosync
events) in the Cluster Information Base (CIB). When responding to the
crm_mon request, Pacemaker doesn't query Corosync or collect that
information on demand. Instead, it returns the data it already has in the CIB.
Therefore the performance impact on the cluster, of increasing the
frequency of the crm_mon one-shot calls, is negligible, even if the
change affects all the pacemaker-remote nodes running masakari-monitors.
Change-Id: I138b8a932aebaed172c9ed0f369009ace491aea8
Signed-off-by: Marcin Wilk <marcin.wilk@canonical.com>
Overview
Masakari is used to provide automated recovery of KVM-based OpenStack machine instances for deployments that use shared storage (volumes).
The masakari-monitors charm deploys Monitors for Masakari whose purpose is to detect hypervisor and instances failures and to inform Masakari about them.
The charm is a subordinate charm (to the nova-compute charm) and is used in conjunction with the masakari and pacemaker-remote charms. Together, these charms provide the following functionality:
-
Evacuation of instances (supported since OpenStack Stein)
In the event of hypervisor failure, instances can be migrated to another hypervisor. -
Restarting of instances (supported since OpenStack Ussuri)
A failed instance can be restarted.
For details see the Automated Instance Recovery appendix in the OpenStack Charms Deployment Guide.
Note
: The restarting of services (e.g. nova-compute) is not supported by the charm as it is considered a
systemdtask.
Usage
Configuration
See file config.yaml for the full list of configuration options, along with
their descriptions and default values.
Deployment
To deploy masakari-monitors:
juju deploy masakari-monitors
Because this is a subordinate charm a relation will need to be added to another application to have the charm deployed on a machine.
Actions
This section lists Juju actions supported by the charm.
Actions allow specific operations to be performed on a per-unit basis. To
display action descriptions run juju actions masakari. If the charm is
not deployed then see file actions.yaml.
pauserestart-servicesresume
Bugs
Please report bugs on Launchpad.
For general charm questions refer to the OpenStack Charm Guide.