Skip to content

Latest commit

 

History

History
1850 lines (1170 loc) · 57.6 KB

REFERENCE.md

File metadata and controls

1850 lines (1170 loc) · 57.6 KB
Raw

Reference

Table of Contents

Classes

  • corosync: Configures the Pacemaker+Corosync stack to provide high-availability.
  • corosync::params: Configures sane defaults based on the operating system.
  • corosync::qdevice: Performs basic initial configuration of the qdevice daemon on a node.
  • corosync::reprobe: Triggers re-probe for changes any of the native cs_* types.

Defined types

Resource types

  • cs_clone: Type for manipulating corosync/pacemaker resource clone. More information on Corosync/Pacemaker colocation can be found here: * http://www.c
  • cs_colocation: Type for manipulating corosync/pacemaker colocation. Colocation is the grouping together of a set of primitives so that they travel together
  • cs_commit: Final commit statement which triggers the synchronous application of all primitive changes which reference this CIB. Do not generate more tha
  • cs_group: Type for manipulating Corosync/Pacemaker group entries. Groups are a set or resources (primitives) that need to be grouped together. More in
  • cs_location: Type for manipulating corosync/pacemaker resource location. More information on Corosync/Pacemaker colocation can be found here: * http://ww
  • cs_order: Type for manipulating Corosync/Pacemaker ordering entries. Order entries are another type of constraint that can be put on sets of primitive
  • cs_primitive: Type for manipulating Corosync/Pacemaker primitives. Primitives are probably the most important building block when creating highly availabl
  • cs_property: Type for manipulating corosync/pacemaker configuration properties. Besides the configuration file that is managed by the module the contains
  • cs_rsc_defaults: Type for manipulating corosync/pacemaker global defaults for resource options. The type is pretty simple interface for setting key/value pair
  • cs_shadow: cs_shadow resources represent a Corosync shadow CIB. Any corosync resources defined with 'cib' set to the title of a cs_shadow resource will

Data types

Classes

corosync

This class will set up corosync for use by the Puppet Enterprise console to facilitate an active/standby configuration for high availability. It is assumed that this module has been initially ran on a Puppet master with the capabilities of signing certificates to do the initial key generation.

=== Authors

Cody Herriges cody@puppetlabs.com

=== Copyright

Copyright 2012, Puppet Labs, LLC.

Examples

Simple configuration without secauth
class { 'corosync':
  enable_secauth    => false,
  bind_address      => '192.168.2.10',
  multicast_address => '239.1.1.2',
}

Parameters

The following parameters are available in the corosync class:

enable_secauth

Data type: Boolean

Controls corosync's ability to authenticate and encrypt multicast messages.

Default value: $corosync::params::enable_secauth

authkey_source

Data type: Enum['file', 'string']

Allows to use either a file or a string as a authkey.

Default value: $corosync::params::authkey_source

authkey

Data type: Variant[Stdlib::Filesource,Stdlib::Base64]

Specifies the path to the CA which is used to sign Corosync's certificate if authkey_source is 'file' or a base64 encoded version of the actual authkey if 'string' is used instead.

Default value: $corosync::params::authkey

crypto_hash

Data type: Corosync::CryptoHash

Hashing algorithm used by corosync for intra-cluster communication. Valid values are none, md5, sha1, sha256, sha384, and sha512

Default value: 'sha1'

crypto_cipher

Data type: Corosync::CryptoCipher

Encryption cipher used by corosync for intra-cluster communication. Valid values are none, aes256, aes192, aes128, and 3des

Default value: 'aes256'

threads

Data type: Optional[Integer]

How many threads you are going to let corosync use to encode and decode multicast messages. If you turn off secauth then corosync will ignore threads.

Default value: undef

bind_address

Data type: Corosync::IpStringIp

The ip address we are going to bind the corosync daemon too. Can be specified as an array to have multiple rings.

Default value: $corosync::params::bind_address

port

Data type: Optional[Variant[Stdlib::Port, Array[Stdlib::Port]]]

The UDP port that corosync will use to do its multicast communication. Be aware that corosync used this defined port plus minus one. Can be specified as an array to have multiple rings.

Default value: $corosync::params::port

multicast_address

Data type: Optional[Corosync::IpStringIp]

An IP address that has been reserved for multicast traffic. This is the default way that Corosync accomplishes communication across the cluster. Use 'broadcast' to have broadcast instead Can be specified as an array to have multiple rings (multicast only).

Default value: undef

unicast_addresses

Data type: Optional[Array]

An array of IP addresses that make up the cluster's members. These are used if you are not able to use multicast on your network and instead opt for the udpu transport. You need a relatively recent version of Corosync to make this possible. You can also have an array of arrays to have multiple rings. In that case, each subarray matches a host IP addresses. As of Corosync 3 knet is the new default which also does not use multicast.

Default value: undef

force_online

Data type: Boolean

Boolean parameter specifying whether to force nodes that have been put in standby back online.

Default value: $corosync::params::force_online

check_standby

Data type: Boolean

Boolean parameter specifying whether puppet should return an error log message if a node is in standby. Useful for monitoring node state.

Default value: $corosync::params::check_standby

log_timestamp

Data type: Boolean

Boolean parameter specifying whether a timestamp should be placed on all log messages.

Default value: $corosync::params::log_timestamp

log_file

Data type: Boolean

Boolean parameter specifying whether Corosync should produce debug output in a logfile.

Default value: $corosync::params::log_file

log_file_name

Data type: Optional[Stdlib::Absolutepath]

Absolute path to the logfile Corosync should use when $log_file (see above) is true.

Default value: undef

debug

Data type: Boolean

Boolean parameter specifying whether Corosync should produce debug output in its logs.

Default value: $corosync::params::debug

log_stderr

Data type: Boolean

Boolean parameter specifying whether Corosync should log errors to stderr.

Default value: $corosync::params::log_stderr

syslog_priority

Data type: Corosync::SyslogPriority

String parameter specifying the minimal log level for Corosync syslog messages. Allowed values: debug|info|notice|warning|err|emerg.

Default value: $corosync::params::syslog_priority

log_function_name

Data type: Boolean

Boolean parameter specifying whether Corosync should log called function names to.

Default value: $corosync::params::log_function_name

rrp_mode

Data type: Optional[Enum['none', 'active', 'passive']]

Mode of redundant ring. May be none, active, or passive.

Default value: undef

netmtu

Data type: Optional[Integer]

This specifies the network maximum transmit unit.

Default value: undef

ttl

Data type: Optional[Integer[0,255]]

Time To Live.

Default value: undef

vsftype

Data type: Optional[Enum['ykd', 'none']]

Virtual synchrony filter type.

Default value: undef

package_corosync

Data type: Boolean

Define if package corosync should be managed.

Default value: $corosync::params::package_corosync

package_pacemaker

Data type: Boolean

Define if package pacemaker should be managed.

Default value: $corosync::params::package_pacemaker

package_fence_agents

Data type: Boolean

Define if package fence-agents should be managed. Default (Red Hat based): true Default (otherwise): false

Default value: false

packageopts_corosync

Data type: Optional[Array[String[1]]]

Additional install-options for the corosync package resource. Default: undef

Default value: $corosync::params::package_install_options

packageopts_crmsh

Data type: Optional[Array[String[1]]]

Additional install-options for the crmsh package resource. Default: undef

Default value: $corosync::params::package_install_options

packageopts_pacemaker

Data type: Optional[Array[String[1]]]

Additional install-options for the pacemaker package resource. Default: undef

Default value: $corosync::params::package_install_options

packageopts_pcs

Data type: Optional[Array[String[1]]]

Additional install-options for the pcs package resource. Default: undef

Default value: $corosync::params::package_install_options

packageopts_fence_agents

Data type: Optional[Array[String[1]]]

Additional install-options for the pcs package resource. Default: undef

Default value: $corosync::params::package_install_options

ensure_corosync

Data type: String[1]

Define what version of the corosync package should be installed. Default: 'present'

Default value: $corosync::params::ensure_corosync

ensure_crmsh

Data type: String[1]

Define what version of the crmsh package should be installed. Default: 'present'

Default value: $corosync::params::ensure_crmsh

ensure_pacemaker

Data type: String[1]

Define what version of the pacemaker package should be installed. Default: 'present'

Default value: $corosync::params::ensure_pacemaker

ensure_pcs

Data type: String[1]

Define what version of the pcs package should be installed. Default: 'present'

Default value: $corosync::params::ensure_pcs

ensure_fence_agents

Data type: String[1]

Define what version of the fence-agents-all package should be installed. Default: 'present'

Default value: $corosync::params::ensure_fence_agents

set_votequorum

Data type: Boolean

Set to true if corosync_votequorum should be used as quorum provider. Default (Red Hat based): true Default (Ubuntu >= 14.04): true Default (otherwise): false

Default value: $corosync::params::set_votequorum

votequorum_expected_votes

Data type: Optional[Integer]

Overrides the automatic calculation of expected votes which is normally derived from the number of nodes.

Default value: undef

quorum_members

Data type: Array

Array of quorum member hostname. This is required if set_votequorum is set to true. You can also have an array of arrays to have multiple rings. In that case, each subarray matches a member IP addresses.

Default value: ['localhost']

quorum_members_ids

Data type: Optional[Array]

Array of quorum member IDs. Persistent IDs are required for the dynamic config of a corosync cluster and when_set_votequorum is set to true. Should be used only with the quorum_members parameter.

Default value: undef

quorum_members_names

Data type: Optional[Array]

Array of quorum member names. Persistent names are required when you define IP addresses in quorum_members.

Default value: undef

token

Data type: Optional[Integer]

Time (in ms) to wait for a token

Default value: undef

token_retransmits_before_loss_const

Data type: Optional[Integer]

How many token retransmits before forming a new configuration.

Default value: undef

compatibility

Data type: Optional[String]

Older versions of corosync allowed a config-file directive to indicate backward compatibility. This sets that.

Default value: undef

enable_corosync_service

Data type: Boolean

Whether the module should enable the corosync service.

Default value: $corosync::params::enable_corosync_service

manage_corosync_service

Data type: Boolean

Whether the module should try to manage the corosync service. If set to false, the service will need to be specified in the catalog elsewhere.

Default value: $corosync::params::manage_corosync_service

enable_pacemaker_service

Data type: Boolean

Whether the module should enable the pacemaker service.

Default value: $corosync::params::enable_pacemaker_service

manage_pacemaker_service

Data type: Boolean

Whether the module should try to manage the pacemaker service. Default (Red Hat based >= 7): true Default (Ubuntu >= 14.04): true Default (otherwise): false

Default value: $corosync::params::manage_pacemaker_service

enable_pcsd_service

Data type: Boolean

Whether the module should enable the pcsd service.

Default value: $corosync::params::enable_pcsd_service

manage_pcsd_service

Data type: Boolean

Whether the module should try to manage the pcsd service in addition to the corosync service. pcsd service is the GUI and the remote configuration interface.

Default value: false

manage_pcsd_auth

Data type: Boolean

This only has an effect when $manage_pcsd_service is enabled. If set, an attempt will be made to authorize pcs on the cluster node determined by manage_pcsd_auth_node. Note that this determination can only be made when the entries in quorum_members match the trusted certnames of the nodes in the environment or the IP addresses of the primary adapters. $sensitive_hacluster_password is mandatory if this parameter is set.

Default value: false

manage_pcsd_auth_node

Data type: Enum['first','last']

When managing authorization for PCS this determines which node does the work. Note that only one node 'should' do the work and nodes are chosen by matching local facts to the contents of quorum_members. When manage_pcsd_auth is disabled this parameter has no effect.

Default value: 'first'

sensitive_hacluster_password

Data type: Optional[Sensitive[String]]

When PCS is configured on a RHEL system this directive is used to set the password for the hacluster user. If both $manage_pcsd_service and $manage_pcsd_auth are both set to true the cluster will use this credential to authorize all nodes.

Default value: undef

sensitive_hacluster_hash

Data type: Optional[Sensitive[String]]

This parameter expects a valid password hash of sensitive_hacluster_password. If provided, the hash provided the hash will be used to set the password for the hacluster user on each node.

Default value: undef

manage_quorum_device

Data type: Boolean

Enable or disable the addition of a quorum device external to the cluster. This device is used avoid cluster splits typically in conjunction with fencing by providing an external network vote. Additionally, this allows symmentric clusters to continue operation in the event that 50% of their nodes have failed.

Default value: false

quorum_device_host

Data type: Optional[Stdlib::Fqdn]

The fully qualified hostname of the quorum device. This parameter is mandatory when manage_quorum_device is true.

Default value: undef

quorum_device_algorithm

Data type: Corosync::QuorumAlgorithm

There are currently two algorithms the quorum device can utilize to determine how its vote should be allocated; Fifty-fifty split and last-man-standing. See the corosync-qdevice man page for details.

Default value: 'ffsplit'

package_quorum_device

Data type: Optional[String]

The name of the package providing the quorum device functionality. This parameter is mandatory if manage_quorum_device is true.

Default value: $corosync::params::package_quorum_device

sensitive_quorum_device_password

Data type: Optional[Sensitive[String]]

The plain text password for the hacluster user on the quorum_device_host. This parameter is mandatory if manage_quorum_device is true.

Default value: undef

cluster_name

Data type: Optional[String[1]]

This specifies the name of cluster and it's used for automatic generating of multicast address.

Default value: undef

join

Data type: Optional[Integer]

This timeout specifies in milliseconds how long to wait for join messages in the membership protocol.

Default value: undef

consensus

Data type: Optional[Integer]

This timeout specifies in milliseconds how long to wait for consensus to be achieved before starting a new round of membership configuration. The minimum value for consensus must be 1.2 * token. This value will be automatically calculated at 1.2 * token if the user doesn't specify a consensus value.

Default value: undef

ip_version

Data type: Optional[String[1]]

This specifies version of IP to ask DNS resolver for. The value can be one of ipv4 (look only for an IPv4 address) , ipv6 (check only IPv6 address), ipv4-6 (look for all address families and use first IPv4 address found in the list if there is such address, otherwise use first IPv6 address) and ipv6-4 (look for all address families and use first IPv6 address found in the list if there is such address, otherwise use first IPv4 address).

Default (if unspecified) is ipv6-4 for knet and udpu transports and ipv4 for udp.

Default value: undef

clear_node_high_bit

Data type: Optional[Enum['yes', 'no']]

This configuration option is optional and is only relevant when no nodeid is specified. Some openais clients require a signed 32 bit nodeid that is greater than zero however by default openais uses all 32 bits of the IPv4 address space when generating a nodeid. Set this option to yes to force the high bit to be zero and therefor ensure the nodeid is a positive signed 32 bit integer. WARNING: The clusters behavior is undefined if this option is enabled on only a subset of the cluster (for example during a rolling upgrade).

Default value: undef

max_messages

Data type: Optional[Integer]

This constant specifies the maximum number of messages that may be sent by one processor on receipt of the token. The max_messages parameter is limited to 256000 / netmtu to prevent overflow of the kernel transmit buffers.

Default value: undef

test_corosync_config

Data type: Boolean

Whether we should test new configuration files with corosync -t. (requires corosync 2.3.4)

Default value: $corosync::params::test_corosync_config

test_corosync_config_cmd

Override the standard config_validate_cmd which only works for corosync 2.x.

watchdog_device

Data type: Optional[Variant[Stdlib::Absolutepath, Enum['off']]]

Watchdog device to use, for example '/dev/watchdog' or 'off'. Its presence (or lack thereof) shifted with corosync versions.

Default value: undef

provider

Data type: Enum['pcs', 'crm']

What command line utility provides corosync configuration capabilities.

Default value: 'pcs'

config_validate_cmd

Data type: String[1]

Default value: '/usr/bin/env COROSYNC_MAIN_CONFIG_FILE=% /usr/sbin/corosync -t'

pcs_version

Data type: String

Default value: ''

corosync::params

Configures sane defaults based on the operating system.

corosync::qdevice

This class performs the configuration of the qdevice daemon on a target node. Note that this requires corosync 2.x and must never be deployed on a node which is actually part of a cluster. Additionally, you will need to open the correct firewall ports for both pcs, and the actual quorum device as shown in the included example.

Examples

Quorum node with default password & configuring the firewall
include firewalld

class { 'corosync::qdevice':
  sensitive_hacluster_hash => $sensitive_hacluster_hash,
}
contain 'corosync::qdevice'

# Open the corosync-qnetd port
firewalld::custom_service { 'corosync-qdevice-net':
  description => 'Corosync Quorum Net Device Port',
  port        => [
    {
      port     => '5403',
      protocol => 'tcp',
    },
  ],
}
firewalld_service { 'corosync-qdevice-net':
  ensure  => 'present',
  service => 'corosync-qdevice-net',
  zone    => 'public',
}

# Configure general PCS firewall rules
firewalld_service { 'high-availability':
  ensure  => 'present',
  service => 'high-availability',
  zone    => 'public',
}

Parameters

The following parameters are available in the corosync::qdevice class:

sensitive_hacluster_hash

Data type: Optional[Sensitive[String]]

The password hash for the hacluster user on this quorum device node. If omitted, you must create the hacluster user and haclient group yourself. This user is required because pcsd must be used to perform the quorum node configuration.

Default value: undef

package_pcs

Data type: String[1]

Name of the PCS package on this system.

Default value: 'pcs'

package_corosync_qnetd

Data type: String[1]

Name of the corosync qnetd package for this system.

Default value: 'corosync-qnetd'

provider

Data type: String

What command line utility provides corosync configuration capabilities.

corosync::reprobe

Include this class to reprobe the corosync cluster when there are changes in any of the native cs_* types. Useful for multi-node provisioning when the nodes are not always in a stable state after provisioning.

Copyright 2012 Puppet Labs, LLC.

Examples

Reprobe corosync after making cluster configuration changes
include corosync::reprobe

Defined types

corosync::service

Models a Corosync service. Corosync services are plugins that provide functionality for monitoring cluster resources. One of the most common of these plugins being Pacemaker. This is for corosync 1.x!

=== Authors

Cody Herriges cody@puppetlabs.com

=== Copyright

Copyright 2012 Puppet Labs, LLC.

Examples

Simple configuration of a service with version '0'.
corosync::service { 'pacemaker':
  version => '0',
}

Parameters

The following parameters are available in the corosync::service defined type:

name

Data type: String

The namevar in this type is the title you give it when you define a resource instance. It is used for a handful of purposes; defining the name of the config file and the name defined inside the file itself.

version

Data type: String[1]

Version of the protocol used by this service. This is currently unused.

Resource types

cs_clone

Type for manipulating corosync/pacemaker resource clone. More information on Corosync/Pacemaker colocation can be found here:

Properties

The following properties are available in the cs_clone type.

clone_max

Valid values: %r{\d+}, absent

How many copies of the resource to start. Defaults to the number of nodes in the cluster.

Default value: absent

clone_node_max

Valid values: %r{\d+}, absent

How many copies of the resource can be started on a single node. Defaults to 1.

Default value: absent

ensure

Valid values: present, absent

The basic property that the resource should be in.

Default value: present

globally_unique

Valid values: true, false, absent

Does each copy of the clone perform a different function? Allowed values: true, false

Default value: absent

group

The corosync resource group to be cloned.

interleave

Valid values: true, false, absent

Changes the behavior of ordering constraints (between clones/masters) so that instances can start/stop as soon as their peer instance has (rather than waiting for every instance of the other clone has). Allowed values: true, false

Default value: absent

notify_clones

Valid values: true, false, absent

When stopping or starting a copy of the clone, tell all the other copies beforehand and when the action was successful. Allowed values: true, false

Default value: absent

ordered

Valid values: true, false, absent

Should the copies be started in series (instead of in parallel). Allowed values: true, false

Default value: absent

primitive

The corosync resource primitive to be cloned.

Parameters

The following parameters are available in the cs_clone type.

cib

Corosync applies its configuration immediately. Using a CIB allows you to group multiple primitives and relationships to be applied at once. This can be necessary to insert complex configurations into Corosync correctly.

This parameter sets the CIB this colocation should be created in. A cs_shadow resource with a title of the same name as this value should also be added to your manifest.

name

namevar

Identifier of the clone entry. This value needs to be unique across the entire Corosync/Pacemaker configuration since it doesn't have the concept of name spaces per type.

provider

The specific backend to use for this cs_clone resource. You will seldom need to specify this --- Puppet will usually discover the appropriate provider for your platform.

cs_colocation

Type for manipulating corosync/pacemaker colocation. Colocation is the grouping together of a set of primitives so that they travel together when one of them fails. For instance, if a web server vhost is colocated with a specific ip address and the web server software crashes, the ip address with migrate to the new host with the vhost.

More information on Corosync/Pacemaker colocation can be found here:

Properties

The following properties are available in the cs_colocation type.

ensure

Valid values: present, absent

The basic property that the resource should be in.

Default value: present

primitives

At least two Pacemaker primitives to be located together. Order of primitives in colocation groups is important. In Pacemaker, a colocation of 2 primitives behaves different than a colocation between more than 2 primitives. Here the behavior is altered to be more consistent. Examples on how to define colocations here:

  • 2 primitives: [A, B] will cause A to be located first, and B will be located with A. This is different than how crm configure colocation works, because there [A, B] would mean colocate A with B, thus B should be located first.
  • multiple primitives: [A, B, C] will cause A to be located first, B next, and finally C. This is identical to how crm configure colocation works with multiple resources, it will add a colocated set. Property will raise an error if you do not provide an array containing at least two values. Values can be either the name of the primitive, or primitive:role. Notice, we can only interpret colocations of single sets, not multiple sets combined. In Pacemaker speak, this means we can support 'A B C' but not e.g. 'A B (C D) E'. Feel free to contribute a patch for this.
score

The priority of this colocation. Primitives can be a part of multiple colocation groups and so there is a way to control which primitives get priority when forcing the move of other primitives. This value can be an integer but is often defined as the string INFINITY.

Default value: INFINITY

Parameters

The following parameters are available in the cs_colocation type.

cib

Corosync applies its configuration immediately. Using a CIB allows you to group multiple primitives and relationships to be applied at once. This can be necessary to insert complex configurations into Corosync correctly.

This paramater sets the CIB this colocation should be created in. A cs_shadow resource with a title of the same name as this value should also be added to your manifest.

name

namevar

Identifier of the colocation entry. This value needs to be unique across the entire Corosync/Pacemaker configuration since it doesn't have the concept of name spaces per type.

provider

The specific backend to use for this cs_colocation resource. You will seldom need to specify this --- Puppet will usually discover the appropriate provider for your platform.

cs_commit

Final commit statement which triggers the synchronous application of all primitive changes which reference this CIB. Do not generate more than one cs_commit referencing the same CIB for a given cluster!

Parameters

The following parameters are available in the cs_commit type.

cib

Name of the CIB to commit. This value defaults to the name of the cs_commit resource.

name

namevar

Name of the CIB to commit. See the cib parameter for more detail.

provider

The specific backend to use for this cs_commit resource. You will seldom need to specify this --- Puppet will usually discover the appropriate provider for your platform.

cs_group

Type for manipulating Corosync/Pacemaker group entries. Groups are a set or resources (primitives) that need to be grouped together.

More information can be found at the following link:

Properties

The following properties are available in the cs_group type.

ensure

Valid values: present, absent

The basic property that the resource should be in.

Default value: present

primitives

An array of primitives to have in this group. Must be listed in the order that you wish them to start.

Parameters

The following parameters are available in the cs_group type.

cib

Corosync applies its configuration immediately. Using a CIB allows you to group multiple primitives and relationships to be applied at once. This can be necessary to insert complex configurations into Corosync correctly.

This parameter sets the CIB this order should be created in. A cs_shadow resource with a title of the same name as this value should also be added to your manifest.

name

namevar

Name identifier of this group entry. This value needs to be unique across the entire Corosync/Pacemaker configuration since it doesn't have the concept of name spaces per type.

provider

The specific backend to use for this cs_group resource. You will seldom need to specify this --- Puppet will usually discover the appropriate provider for your platform.

cs_location

Type for manipulating corosync/pacemaker resource location. More information on Corosync/Pacemaker colocation can be found here:

Properties

The following properties are available in the cs_location type.

ensure

Valid values: present, absent

The basic property that the resource should be in.

Default value: present

node_name

The corosync node_name where the resource should be located.

primitive

The corosync resource primitive to have a location applied.

resource_discovery

Whether Pacemaker should perform resource discovery on this node for the specified resource. It matches the resource-discovery location property in pacemaker

rules

The rules of this location. This is an array of hashes where each hash contains an array of one or more expressions.

Example:

cs_location { 'vip-ping-connected': primitive => 'vip', rules => [ 'vip-ping-exclude-rule' => { 'score' => '-INFINITY', 'expression' => [ { 'attribute' => 'pingd', 'operation' => 'lt', 'value' => '100', }, ], }, 'vip-ping-prefer-rule' => { 'score-attribute' => 'pingd', 'expression' => [ { 'attribute' => 'pingd', 'operation' => 'defined', }, ], }, ], }

score

The priority of this location. Primitives can be a part of multiple location groups and so there is a way to control which primitives get priority when forcing the move of other primitives. This value can be an integer but is often defined as the string INFINITY.

Default value: INFINITY

Parameters

The following parameters are available in the cs_location type.

cib

Corosync applies its configuration immediately. Using a CIB allows you to group multiple primitives and relationships to be applied at once. This can be necessary to insert complex configurations into Corosync correctly.

This paramater sets the CIB this colocation should be created in. A cs_shadow resource with a title of the same name as this value should also be added to your manifest.

name

namevar

Identifier of the location entry. This value needs to be unique across the entire Corosync/Pacemaker configuration since it doesn't have the concept of name spaces per type.

provider

The specific backend to use for this cs_location resource. You will seldom need to specify this --- Puppet will usually discover the appropriate provider for your platform.

cs_order

Type for manipulating Corosync/Pacemaker ordering entries. Order entries are another type of constraint that can be put on sets of primitives but unlike colocation, order does matter. These designate the order at which you need specific primitives to come into a desired state before starting up a related primitive.

More information can be found at the following link:

Properties

The following properties are available in the cs_order type.

ensure

Valid values: present, absent

The basic property that the resource should be in.

Default value: present

first

First Corosync primitive. Just like colocation, our primitives for ordering come in pairs but this time order matters so we need to define which primitive starts the desired state change chain.

kind

How to enforce the constraint.

Allowed values:

  • Optional: Just a suggestion. Only applies if both resources are executing the specified actions. Any change in state by the first resource will have no effect on the then resource.
  • Mandatory: Always. If first does not perform first-action, then will not be allowed to performed then-action. If first is restarted, then (if running) will be stopped beforehand and started afterward.
  • Serialize: Ensure that no two stop/start actions occur concurrently for the resources. First and then can start in either order, but one must complete starting before the other can be started. A typical use case is when resource start-up puts a high load on the host.

Default value: Mandatory

score

The priority of the this ordered grouping. Primitives can be a part of multiple order groups and so there is a way to control which primitives get priority when forcing the order of state changes on other primitives. This value can be an integer but is often defined as the string INFINITY. When using pcs as provider this value is not used. It is generally preferred to use the kind parameter.

second

Second Corosync primitive. Our second primitive will move to the desired state after the first primitive.

symmetrical

Boolean specifying if the resources should stop in reverse order. Default value: true.

Default value: true

Parameters

The following parameters are available in the cs_order type.

cib

Corosync applies its configuration immediately. Using a CIB allows you to group multiple primitives and relationships to be applied at once. This can be necessary to insert complex configurations into Corosync correctly.

This parameter sets the CIB this order should be created in. A cs_shadow resource with a title of the same name as this value should also be added to your manifest.

name

namevar

Name identifier of this ordering entry. This value needs to be unique across the entire Corosync/Pacemaker configuration since it doesn't have the concept of name spaces per type.

provider

The specific backend to use for this cs_order resource. You will seldom need to specify this --- Puppet will usually discover the appropriate provider for your platform.

cs_primitive

Type for manipulating Corosync/Pacemaker primitives. Primitives are probably the most important building block when creating highly available clusters using Corosync and Pacemaker. Each primitive defines an application, ip address, or similar to monitor and maintain. These managed primitives are maintained using what is called a resource agent. These resource agents have a concept of class, type, and subsystem that provides the functionality. Regrettably these pieces of vocabulary clash with those used in Puppet so to overcome the name clashing the property and parameter names have been qualified a bit for clarity.

More information on primitive definitions can be found at the following link:

Properties

The following properties are available in the cs_primitive type.

ensure

Valid values: present, absent

The basic property that the resource should be in.

Default value: present

metadata

A hash of metadata for the primitive. A primitive can have a set of metadata that doesn't affect the underlying Corosync type/provider but affect that concept of a resource. This metadata is similar to Puppet's resources resource and some meta-parameters, they change resource behavior but have no affect of the data that is synced or manipulated.

Default value: Hash.new

operations

A hash of operations for the primitive. Operations defined in a primitive are little more predictable as they are commonly things like monitor or start and their values are in seconds. Since each resource agent can define its own set of operations we are going to defer again and just accept a hash. There maybe room to model this one but it would require a review of all resource agents to see if each operation is valid.

Default value: Hash.new

parameters

A hash of params for the primitive. Parameters in a primitive are used by the underlying resource agent, each class using them slightly differently. In ocf scripts they are exported and pulled into the script as variables to be used. Since the list of these parameters are completely arbitrary and validity not enforced we simply defer defining a model and just accept a hash.

Default value: Hash.new

utilization

A hash of utilization attributes for the primitive. If nodes are also configured with available resources, and Pacemaker's placement strategy is set appropriately, then Pacemaker can place primitives on nodes only where resources are available.

See the Pacemaker documentation:

http://clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Pacemaker_Explained/ch11.html

Default value: Hash.new

Parameters

The following parameters are available in the cs_primitive type.

cib

Corosync applies its configuration immediately. Using a CIB allows you to group multiple primitives and relationships to be applied at once. This can be necessary to insert complex configurations into Corosync correctly.

This parameter sets the CIB this primitive should be created in. A cs_shadow resource with a title of the same name as this value should also be added to your manifest.

name

namevar

Name identifier of primitive. This value needs to be unique across the entire Corosync/Pacemaker configuration since it doesn't have the concept of name spaces per type.

primitive_class

Corosync class of the primitive. Examples of classes are lsb or ocf. Lsb functions a lot like the init provider in Puppet for services, an init script is ran periodically on each host to identify status, or to start and stop a particular application. Ocf of the other hand is a script with meta-data and structure that is specific to Corosync and Pacemaker.

primitive_type

Corosync primitive type. Type generally matches to the specific 'thing' your managing, i.e. ip address or vhost. Though, they can be completely arbitrarily named and manage any number of underlying applications or resources.

provided_by

Corosync primitive provider. All resource agents used in a primitive have something that provides them to the system, be it the Pacemaker or redhat plugins...they're not always obvious though so currently you're left to understand Corosync enough to figure it out. Usually, if it isn't obvious it is because there is only one provider for the resource agent.

To find the list of providers for a resource agent run the following from the command line has Corosync installed:

  • crm configure ra providers <ra> <class>
provider

The specific backend to use for this cs_primitive resource. You will seldom need to specify this --- Puppet will usually discover the appropriate provider for your platform.

unmanaged_metadata

Metadata options that should not be managed by Puppet. Examples: ['target-role', 'is-managed']

Default value: Array.new

cs_property

Type for manipulating corosync/pacemaker configuration properties. Besides the configuration file that is managed by the module the contains all these related Corosync types and providers, there is a set of cluster properties that can be set and saved inside the CIB (A CIB being a set of configuration that is synced across the cluster, it can be exported as XML for processing and backup). The type is pretty simple interface for setting key/value pairs or removing them completely. Removing them will result in them taking on their default value.

More information on cluster properties can be found here:

P.S Looked at generating a type dynamically from the cluster's property meta-data that would result in a single type with puppet type properties of every cluster property...may still do so in a later iteration.

Properties

The following properties are available in the cs_property type.

ensure

Valid values: present, absent

The basic property that the resource should be in.

Default value: present

value

Value of the property. It is expected that this will be a single value but we aren't validating string vs. integer vs. boolean because cluster properties can range the gambit.

Parameters

The following parameters are available in the cs_property type.

cib

Corosync applies its configuration immediately. Using a CIB allows you to group multiple primitives and relationships to be applied at once. This can be necessary to insert complex configurations into Corosync correctly.

This parameter sets the CIB this parameter should be created in. A cs_shadow resource with a title of the same name as this value should also be added to your manifest.

name

namevar

Name identifier of this property. Simply the name of the cluster property. Happily most of these are unique.

provider

The specific backend to use for this cs_property resource. You will seldom need to specify this --- Puppet will usually discover the appropriate provider for your platform.

replace

Valid values: true, false, yes, no

Whether to replace a property that already exists on the cluster whose value doesn't match what the value attribute specifies. Setting this to false allows cs_property resources to initialize properties without overwriting future changes. Defaults to true.

Default value: true

cs_rsc_defaults

Type for manipulating corosync/pacemaker global defaults for resource options. The type is pretty simple interface for setting key/value pairs or removing them completely. Removing them will result in them taking on their default value.

More information on resource defaults can be found here:

Properties

The following properties are available in the cs_rsc_defaults type.

ensure

Valid values: present, absent

The basic property that the resource should be in.

Default value: present

value

Value of the property. It is expected that this will be a single value but we aren't validating string vs. integer vs. boolean because resource options can range the gambit.

Parameters

The following parameters are available in the cs_rsc_defaults type.

cib

Corosync applies its configuration immediately. Using a CIB allows you to group multiple primitives and relationships to be applied at once. This can be necessary to insert complex configurations into Corosync correctly.

This parameter sets the CIB this rsc_defaults should be created in. A cs_shadow resource with a title of the same name as this value should also be added to your manifest.

name

namevar

Name identifier of this property. Simply the name of the resource option. Happily most of these are unique.

provider

The specific backend to use for this cs_rsc_defaults resource. You will seldom need to specify this --- Puppet will usually discover the appropriate provider for your platform.

cs_shadow

cs_shadow resources represent a Corosync shadow CIB. Any corosync resources defined with 'cib' set to the title of a cs_shadow resource will not become active until all other resources with the same cib value have also been applied.

Properties

The following properties are available in the cs_shadow type.

epoch

Implementation detail. DO NOT SET DIRECTLY.

Default value: latest

Parameters

The following parameters are available in the cs_shadow type.

autocommit

Valid values: true, false, yes, no

Whether to generate a cs_commit or not. Can be used to create shadow CIB without committing them.

Default value: true

cib

namevar

Name of the CIB to begin tracking changes against.

provider

The specific backend to use for this cs_shadow resource. You will seldom need to specify this --- Puppet will usually discover the appropriate provider for your platform.

Data types

Corosync::ArrayRing

The Corosync::ArrayRing data type.

Alias of

Variant[Array[Stdlib::IP::Address], Array[
    Array[Stdlib::IP::Address]
  ]]

Corosync::CryptoCipher

Defines the allowed cipher types for secure corosync communication

Alias of Enum['aes256', 'aes192', 'aes128', '3des']

Corosync::CryptoHash

The Corosync::CryptoHash data type.

Alias of Enum['md5', 'sha1', 'sha256', 'sha384', 'sha512']

Corosync::IpStringIp

The Corosync::IpStringIp data type.

Alias of

Variant[Stdlib::IP::Address, Array[
    Stdlib::IP::Address
  ]]

Corosync::QuorumAlgorithm

The Corosync::QuorumAlgorithm data type.

Alias of Enum['ffsplit', 'lms']

Corosync::Syslogpriority

The Corosync::Syslogpriority data type.

Alias of Enum['debug', 'info', 'notice', 'warning', 'err', 'alert', 'emerg', 'crit']