Juju Charm - HACluster
Go to file
Corey Bryant ac5a0a5283 c-h sync - restore proxy env vars for add-apt-repository
Change-Id: I48aea64a1154e68d91e2dd5f6d05085b6ba9f38a
Co-authored-by: Aurelien Lourot <aurelien.lourot@canonical.com>
2021-08-03 14:56:39 +02:00
actions Improved action to display the cluster status 2021-03-16 14:12:48 +01:00
charmhelpers c-h sync - restore proxy env vars for add-apt-repository 2021-08-03 14:56:39 +02:00
files NRPE: Don't report paused hacluster nodes as CRITICAL error 2020-11-06 14:19:42 +01:00
hooks Fix pacemaker-remote-relation-changed hook error 2021-03-19 13:29:30 +01:00
lib Update tox.ini files from release-tools gold copy 2016-09-09 19:22:07 +00:00
templates Convert charm to Python 3 2019-03-14 12:40:07 +00:00
tests Updates for stable branch creation 2021-05-03 12:19:29 +02:00
unit_tests Fix pacemaker-remote-relation-changed hook error 2021-03-19 13:29:30 +01:00
.gitignore Support network space binding of hanode relation 2017-09-28 09:00:43 +01:00
.gitreview Updates for stable branch creation 2021-05-03 12:19:29 +02:00
.project Refactoring to use openstack charm helpers. 2013-03-24 12:01:17 +00:00
.pydevproject Refactoring to use openstack charm helpers. 2013-03-24 12:01:17 +00:00
.stestr.conf Replace ostestr with stestr in testing framework. 2019-03-07 17:11:32 -05:00
.zuul.yaml Fix installing dnspython on python 3.5 2020-07-20 16:12:38 +02:00
LICENSE Re-license charm as Apache-2.0 2016-06-28 12:12:40 +01:00
Makefile Port hacluster tests from Amulet to Zaza 2019-12-19 02:54:10 +00:00
README.md Improved action to display the cluster status 2021-03-16 14:12:48 +01:00
actions.yaml Improved action to display the cluster status 2021-03-16 14:12:48 +01:00
charm-helpers-hooks.yaml 21.04 libraries freeze for charms on master branch 2021-04-06 11:14:01 -07:00
config.yaml Adjust quorum after node removal 2021-03-11 17:24:01 +01:00
copyright Re-license charm as Apache-2.0 2016-06-28 12:12:40 +01:00
icon.svg Add icon and category 2014-04-11 12:22:46 +01:00
metadata.yaml Add hirsute and remove trusty from metadata.yaml 2021-03-02 20:56:07 +00:00
osci.yaml c-h sync - restore proxy env vars for add-apt-repository 2021-08-03 14:56:39 +02:00
requirements.txt Sync release-tools 2021-08-02 13:53:08 +02:00
setup.cfg fix coverage settings 2015-04-02 18:53:16 +01:00
test-requirements.txt Sync release-tools 2021-08-02 13:53:08 +02:00
tox.ini Sync release-tools 2021-08-02 13:53:08 +02:00

README.md

Overview

The hacluster charm provides high availability for OpenStack applications that lack native (built-in) HA functionality. The clustering solution is based on Corosync and Pacemaker.

It is a subordinate charm that works in conjunction with a principle charm that supports the 'hacluster' interface. The current list of such charms can be obtained from the Charm Store (the charms officially supported by the OpenStack Charms project are published by 'openstack-charmers').

See OpenStack high availability in the OpenStack Charms Deployment Guide for a comprehensive treatment of HA with charmed OpenStack.

Note: The hacluster charm is generally intended to be used with MAAS-based clouds.

Usage

High availability can be configured in two mutually exclusive ways:

  • virtual IP(s)
  • DNS

The virtual IP method of implementing HA requires that all units of the clustered OpenStack application are on the same subnet.

The DNS method of implementing HA requires that MAAS is used as the backing cloud. The clustered nodes must have static or "reserved" IP addresses registered in MAAS. If using a version of MAAS earlier than 2.3 the DNS hostname(s) should be pre-registered in MAAS before use with DNS HA.

Configuration

This section covers common configuration options. See file config.yaml for the full list of options, along with their descriptions and default values.

cluster_count

The cluster_count option sets the number of hacluster units required to form the principle application cluster (the default is 3). It is best practice to provide a value explicitly as doing so ensures that the hacluster charm will wait until all relations are made to the principle application before building the Corosync/Pacemaker cluster, thereby avoiding a race condition.

Deployment

At deploy time an application name should be set, and be based on the principle charm name (for organisational purposes):

juju deploy hacluster <principle-charm-name>-hacluster

A relation is then added between the hacluster application and the principle application.

In the below example the VIP approach is taken. These commands will deploy a three-node Keystone HA cluster, with a VIP of 10.246.114.11. Each will reside in a container on existing machines 0, 1, and 2:

juju deploy -n 3 --to lxd:0,lxd:1,lxd:2 --config vip=10.246.114.11 keystone
juju deploy --config cluster_count=3 hacluster keystone-hacluster
juju add-relation keystone-hacluster:ha keystone:ha

Actions

This section lists Juju actions supported by the charm. Actions allow specific operations to be performed on a per-unit basis.

  • pause
  • resume
  • status
  • cleanup
  • update-ring

To display action descriptions run juju actions hacluster. If the charm is not deployed then see file actions.yaml.

update-ring action

The update-ring action requires a parameter (i-really-mean-it=true) to make sure tidying up the list of available corosync nodes in the ring is intended.

The operation expects:

  1. juju run-action hacluster/N pause --wait. This will make sure no Pacemaker resources run on the unit.

  2. juju remove-unit principal-unit/N. Iterate through this step as many times as units want to be removed (ie. to scale back from 6 to 3 units).

  3. juju run-action hacluster/leader update-ring i-really-mean-it=true --wait. This step will remove corosync nodes from the ring and update corosync.conf to list an updated number of nodes (min_quorum is recalculated).

In case a unit goes into lost state (ie. caused by hardware failure), the initial step (pause a unit) can be skipped. Unit removal may also be replaced by juju remove-machine N --force, where N is the Juju machine ID where the unit to be removed runs.

Presenting status information

Here are a few examples of how to present useful information with the status action and the jq utility.

  • Querying for online and standby parameter values:

    juju run-action --wait hacluster/leader status \
      --format json | jq '.[] | {(.UnitId):.results.result | fromjson \
      | .nodes | .[] | {unit_name: .name, online: .online, standby: .standby}}'
    

    output example

    {
      "hacluster/0": {
        "unit_name": "juju-a37bc0-3",
        "online": "true",
        "standby": "false"
      }
    }
    {
      "hacluster/0": {
        "unit_name": "juju-a37bc0-4",
        "online": "true",
        "standby": "false"
      }
    }
    {
      "hacluster/0": {
        "unit_name": "juju-a37bc0-5",
        "online": "true",
        "standby": "false"
      }
    }
    
  • Displaying cluster resource information:

    juju run-action --wait hacluster/leader status \
      --format json | jq '.[] | {(.UnitId):.results.result | fromjson \
      | .resources.groups}'
    

Bugs

Please report bugs on Launchpad.

For general charm questions refer to the OpenStack Charm Guide.