Not found :(
-Sorry, but the page you were trying to view does not exist.
-It looks like this was the result of either:
--
-
- a mistyped address -
- an out-of-date link -
t |
- This document has been retired. See the "Access Control Lists" chapter of - "Pacemaker Explained" in the Pacemaker - documentation set instead. -
-- Most of the documentation listed here was generated from the Pacemaker - sources. -
- -- If you're new to Pacemaker or clustering in general, the best place to - start is Clusters from Scratch, which walks you step-by-step through - the installation and configuration of a high-availability cluster with - Pacemaker. It even makes common configuration mistakes so that it can - demonstrate how to fix them. -
- -- On the other hand, if you're looking for an exhaustive reference of all - of Pacemaker's options and features, try Pacemaker Explained. It's - dry, but should have the answers you're looking for. -
- -- There is also a project wiki - with examples, how-to guides, and other information that doesn't make it - into the manuals. -
- -man(1) pages | -[html] | -
Configuring Fencing with crmsh | -[html] | -
$desc
\n"; - } - $build = file_get_contents("$base/build-$version.txt"); - if (!empty($build)) { - echo "$build
\n"; - } - } - - function sphinx_docs_for_version($base, $version) { - echo "" . str_replace("_", " ", $book) . " | \n"; - echo ""; - - foreach ($formats as $format) { - $format_name = basename($format); - if (strncmp($format_name, "build-", 6) !== 0) { - if ($format_name == "pdf") { - $link = "$format/$book.pdf"; - } else { - $link = "$format/"; - } - echo " [" . $format_name . "]"; - } - } - echo " | \n"; - echo "
'.str_replace("_", " ", $b)." ($lang) | "; - - echo ''; - foreach (glob("$base/$lang/Pacemaker/$version/epub/$b/*.epub") as $filename) { - echo " [epub]"; - } - foreach (glob("$base/$lang/Pacemaker/$version/pdf/$b/*.pdf") as $filename) { - echo " [pdf]"; - } - foreach (glob("$base/$lang/Pacemaker/$version/html/$b/index.html") as $filename) { - echo " [html]"; - } - foreach (glob("$base/$lang/Pacemaker/$version/html-single/$b/index.html") as $filename) { - echo " [html-single]"; - } - foreach (glob("$base/$lang/Pacemaker/$version/txt/$b/*.txt") as $filename) { - echo " [txt]"; - } - echo " |
- "The definitive open-source high-availability stack for the Linux - platform builds upon the Pacemaker cluster resource manager." - -- LINUX Journal, - "Ahead - of the Pack: the Pacemaker High-Availability Stack" -- - -
- Pacemaker has been around since - 2004 - and is a collaborative effort by the ClusterLabs community, including - full-time developers with - Red Hat - and SuSE. -
-- Pacemaker ships with most modern Linux distributions and has been - deployed in many critical environments including Deutsche - Flugsicherung GmbH - (DFS) - which uses Pacemaker to ensure - its air traffic - control systems are always available. -
-- Andrew Beekhof was - Pacemaker's original author and long-time project lead. The current - project lead is Ken Gaillot. -
-- Pacemaker ships with a set of command-line tools to assist you - in managing your cluster. Their manual pages are all linked - above. Here are more details about the most important tools: -
-The crm_mon command - allows you to monitor your cluster's status and - configuration. Its output includes the number of nodes, - uname, uuid, status, the resources configured in your - cluster, and the current status of each. The output of - crm_mon - can be displayed at the console or printed into an XML or HTML - file. When provided with a cluster configuration file - without the status section, - crm_mon - creates an overview of nodes and resources as specified - in the file. See crm_mon(8) - for a detailed introduction to this tool's usage and - command syntax. -
-The cibadmin command is - the low-level administrative command for manipulating - the Pacemaker CIB. It can be used to dump all or part of - the CIB, update all or part of it, modify all or part of - it, delete the entire CIB, or perform miscellaneous CIB - administrative operations. See - cibadmin(8) for a - detailed introduction - to this tool's usage and command syntax. -
-The crm_diff command - assists you in creating and applying XML patches. This - can be useful for visualizing the changes between two - versions of the cluster configuration or saving changes - so they can be applied at a later time - using - cibadmin(8). - See - crm_diff(8) for a - detailed introduction to this tool's usage and command - syntax. -
-The crm_verify command - checks the configuration database (CIB) for consistency - and other problems. It can check a file containing the - configuration or connect to a running cluster. It - reports two classes of problems. Errors must be fixed - before Pacemaker can work properly while warning - resolution is up to the administrator. - crm_verify assists in - creating new or modified configurations. You can take a - local copy of a CIB in the running cluster, edit it, - validate it - using crm_verify , then - put the new configuration into effect using - cibadmin - . See - crm_verify(8) - for a detailed introduction to this tool's usage and - command syntax. -
-The crm_attribute - command lets you query and manipulate node attributes - and cluster configuration options that are used in the - CIB. See crm_attribute(8) - for a detailed introduction to this tool's usage and - command syntax.
-The crm_resource - command performs various resource-related actions on the - cluster. It lets you modify the definition of configured - resources, start and stop resources, or delete and - migrate resources between - nodes. See - crm_resource(8) - for a detailed introduction to this tool's usage and - command syntax.
-The crm_failcount - command queries the number of failures per resource on a - given node. This tool can also be used to reset the - failcount, allowing the resource to again run on nodes - where it had failed too often. - See - crm_failcount(8) - for a detailed introduction to this tool's usage and - command syntax.
-The crm_standby command - can manipulate a node's standby attribute. Any node in - standby mode is no longer eligible to host resources and - any resources that are there must be moved. Standby mode - can be useful for performing maintenance tasks, such as - kernel updates. Remove the standby attribute from the - node as it should become a fully active member of the - cluster again. See - crm_standby(8) - for a detailed introduction to this tool's usage and - command syntax. -
-- -
- - - | -- - - | -- - - | -
- - - -
- -- Pacemaker ships as part of the Red Hat - High Availability Add-on. - The easiest way to try it out on RHEL is to install it from the - Scientific Linux - or CentOS repositories. -
-- If you are already running CentOS or Scientific Linux, you can skip this step. Otherwise, to teach the machine where to find the CentOS packages, run: -
-
-[ALL] # cat <
- Next we use yum to install pacemaker and some other - necessary packages we will need: -
--[ALL] # yum install pacemaker cman pcs ccs resource-agents -
- -- The supported stack on RHEL6 is based on CMAN, so thats - what Pacemaker uses too. -
- -- We now create a CMAN cluster and populate it with some - nodes. Note that the name cannot exceed 15 characters - (we'll use 'pacemaker1'). -
--[ONE] # ccs -f /etc/cluster/cluster.conf --createcluster pacemaker1 - -[ONE] # ccs -f /etc/cluster/cluster.conf --addnode node1 -[ONE] # ccs -f /etc/cluster/cluster.conf --addnode node2 -
- -- Next we need to teach CMAN how to send it's fencing - requests to Pacemaker. We do this regardless of whether - or not fencing is enabled within Pacemaker. -
--[ONE] # ccs -f /etc/cluster/cluster.conf --addfencedev pcmk agent=fence_pcmk - -[ONE] # ccs -f /etc/cluster/cluster.conf --addmethod pcmk-redirect node1 -[ONE] # ccs -f /etc/cluster/cluster.conf --addmethod pcmk-redirect node2 - -[ONE] # ccs -f /etc/cluster/cluster.conf --addfenceinst pcmk node1 pcmk-redirect port=node1 -[ONE] # ccs -f /etc/cluster/cluster.conf --addfenceinst pcmk node2 pcmk-redirect port=node2 -
-- Now copy /etc/cluster/cluster.conf to all - the other nodes that will be part of the cluster. -
- -- CMAN was originally written for rgmanager and assumes the - cluster should not start until the node has - quorum, - so before we try to start the cluster, we need to disable - this behavior: -
--[ALL] # echo "CMAN_QUORUM_TIMEOUT=0" >> /etc/sysconfig/cman -
-- Now, on each machine, run: -
--[ALL] # service cman start -[ALL] # service pacemaker start -
- -- The original cluster shell (crmsh) is no - longer available on RHEL. To help people make the - transition there is - a - quick reference guide for those wanting to know what - the pcs equivalent is for various crmsh commands. -
- -- With so many devices and possible topologies, it is nearly - impossible to include Fencing in a document like this. - For now we will disable it. -
--[ONE] # pcs property set stonith-enabled=false -
-- One of the most common ways to deploy Pacemaker is in a - 2-node configuration. However quorum as a concept makes - no sense in this scenario (because you only have it when - more than half the nodes are available), so we'll disable - it too. -
--[ONE] # pcs property set no-quorum-policy=ignore -
-- For demonstration purposes, we will force the cluster to - move services after a single failure: -
--[ONE] # pcs resource defaults migration-threshold=1 -
- -- Lets add a cluster service, we'll choose one doesn't - require any configuration and works everywhere to make - things easy. Here's the command: -
--[ONE] # pcs resource create my_first_svc Dummy op monitor interval=120s -
-- "my_first_svc" is the name the service - will be known as. -
-- "ocf:pacemaker:Dummy" tells Pacemaker - which script to use - (Dummy - - an agent that's useful as a template and for guides like - this one), which namespace it is in (pacemaker) and what - standard it conforms to (OCF). -
-- "op monitor interval=120s" tells Pacemaker to - check the health of this service every 2 minutes by - calling the agent's monitor action. -
-- You should now be able to see the service running using: -
--[ONE] # pcs status -
-- or -
--[ONE] # crm_mon -1 -
- -- We can simulate an error by telling the service to stop - directly (without telling the cluster): -
--[ONE] # crm_resource --resource my_first_svc --force-stop -
-- If you now run crm_mon in interactive - mode (the default), you should see (within the monitor - interval - 2 minutes) the cluster notice - that my_first_svc failed and move it to - another node. -
--
- Pacemaker ships as part of the Red Hat - High Availability Add-on. - The easiest way to try it out on RHEL is to install it from the - Scientific Linux - or CentOS repositories. -
-- If you are already running CentOS or Scientific Linux, you can skip this step. Otherwise, to teach the machine where to find the CentOS packages, run: -
-
-[ALL] # cat <
- Next we use yum to install pacemaker and some other - necessary packages we will need: -
--[ALL] # yum install pacemaker pcs resource-agents -
- -- The supported stack on RHEL7 is based on Corosync 2, so thats - what Pacemaker uses too. -
- -- First make sure that pcs daemon is running on every node: -
-- [ALL] # systemctl start pcsd.service - [ALL] # systemctl enable pcsd.service -
- -- Then we set up the authentication needed for pcs. -
--[ALL] # echo CHANGEME | passwd --stdin hacluster -[ONE] # pcs cluster auth node1 node2 -u hacluster -p CHANGEME --force -
- -- We now create a cluster and populate it with some nodes. - Note that the name cannot exceed 15 characters (we'll use - 'pacemaker1'). -
--[ONE] # pcs cluster setup --force --name pacemaker1 node1 node2 -
- --[ONE] # pcs cluster start --all -
- -- With so many devices and possible topologies, it is nearly - impossible to include Fencing in a document like this. - For now we will disable it. -
--[ONE] # pcs property set stonith-enabled=false -
-- One of the most common ways to deploy Pacemaker is in a - 2-node configuration. However quorum as a concept makes - no sense in this scenario (because you only have it when - more than half the nodes are available), so we'll disable - it too. -
--[ONE] # pcs property set no-quorum-policy=ignore -
-- For demonstration purposes, we will force the cluster to - move services after a single failure: -
--[ONE] # pcs resource defaults migration-threshold=1 -
- -- Lets add a cluster service, we'll choose one doesn't - require any configuration and works everywhere to make - things easy. Here's the command: -
--[ONE] # pcs resource create my_first_svc Dummy op monitor interval=120s -
-- "my_first_svc" is the name the service - will be known as. -
-- "ocf:pacemaker:Dummy" tells Pacemaker - which script to use - (Dummy - - an agent that's useful as a template and for guides like - this one), which namespace it is in (pacemaker) and what - standard it conforms to (OCF). -
-- "op monitor interval=120s" tells Pacemaker to - check the health of this service every 2 minutes by - calling the agent's monitor action. -
-- You should now be able to see the service running using: -
--[ONE] # pcs status -
-- or -
--[ONE] # crm_mon -1 -
- -- We can simulate an error by telling the service to stop - directly (without telling the cluster): -
--[ONE] # crm_resource --resource my_first_svc --force-stop -
-- If you now run crm_mon in interactive - mode (the default), you should see (within the monitor - interval of 2 minutes) the cluster notice - that my_first_svc failed and move it to - another node. -
--
- Pacemaker ships as part of the - SUSE High - Availability Extension. To install, follow the provided - documentation. It is also available in openSUSE Leap and openSUSE - Tumbleweed (for openSUSE, see the SLES 12 Quickstart guide. -
- -- The supported stack on SLES11 is based on Corosync/OpenAIS. -
- -- To get started, install the cluster stack on all nodes. -
--[ALL] # zypper install ha-cluster-bootstrap -
- -- First we initialize the cluster on the first machine (node1): -
--[ONE] # ha-cluster-init -
- -- Now we can join the cluster from the second machine (node2): -
--[ONE] # ha-cluster-join -c node1 -
- -- These two steps create and start a basic cluster together with the - HAWK web interface. If given - additional arguments, ha-cluster-init can also configure - STONITH and OCFS2 as part of initial configuration. -
-- For more details on ha-cluster-init, see the output of - ha-cluster-init --help. -
- -- For demonstration purposes, we will force the cluster to - move services after a single failure: -
--[ONE] # crm configure property migration-threshold=1 -
- -- Lets add a cluster service, we'll choose one doesn't - require any configuration and works everywhere to make - things easy. Here's the command: -
--[ONE] # crm configure primitive my_first_svc ocf:pacemaker:Dummy op monitor interval=120s -
-- "my_first_svc" is the name the service - will be known as. -
-- "ocf:pacemaker:Dummy" tells Pacemaker - which script to use - (Dummy - - an agent that's useful as a template and for guides like - this one), which namespace it is in (pacemaker) and what - standard it conforms to - (OCF). -
-- "op monitor interval=120s" tells Pacemaker to - check the health of this service every 2 minutes by - calling the agent's monitor action. -
-- You should now be able to see the service running using: -
--[ONE] # crm status -
- -- We can simulate an error by telling the service stop - directly (without telling the cluster): -
--[ONE] # crm_resource --resource my_first_svc --force-stop -
-- If you now run crm_mon in interactive - mode (the default), you should see (within the monitor - interval - 2 minutes) the cluster notice - that my_first_svc failed and move it to - another node. -
-- You can also watch the transition from the HAWK dashboard, by going - to https://node1:7630. -
--
- Pacemaker ships as part of the - SUSE High - Availability Extension. To install, follow the provided - documentation. It is also available in openSUSE Leap and openSUSE - Tumbleweed. -
- -- The supported stack on SLES12 is based on Corosync 2.x. -
- -- To get started, install the cluster stack on all nodes. -
--[ALL] # zypper install ha-cluster-bootstrap -
- -- First we initialize the cluster on the first machine (node1): -
--[ONE] # ha-cluster-init -
- -- Now we can join the cluster from the second machine (node2): -
--[TWO] # ha-cluster-join -c node1 -
- -- These two steps create and start a basic cluster together with the - HAWK web interface. If given - additional arguments, ha-cluster-init can also configure - STONITH, OCFS2 and an administration IP address as part of initial - configuration. It is also possible to choose whether to use multicast - or unicast for corosync communication. -
-- For more details on ha-cluster-init, see the output of - ha-cluster-init --help. -
- -- For demonstration purposes, we will force the cluster to - move services after a single failure: -
--[ONE] # crm configure property migration-threshold=1 -
- -- Lets add a cluster service, we'll choose one doesn't - require any configuration and works everywhere to make - things easy. Here's the command: -
--[ONE] # crm configure primitive my_first_svc Dummy op monitor interval=120s -
-- "my_first_svc" is the name the service - will be known as. -
-- "Dummy" tells Pacemaker - which script to use - (Dummy - - an agent that's useful as a template and for guides like - this one), which namespace it is in (pacemaker) and what - standard it conforms to (OCF). -
-- "op monitor interval=120s" tells Pacemaker to - check the health of this service every 2 minutes by - calling the agent's monitor action. -
-- You should now be able to see the service running using: -
--[ONE] # crm status -
- -- We can simulate an error by telling the service stop - directly (without telling the cluster): -
--[ONE] # crm_resource --resource my_first_svc --force-stop -
-- If you now run crm_mon in interactive - mode (the default), you should see (within the monitor - interval - 2 minutes) the cluster notice - that my_first_svc failed and move it to - another node. -
-- You can also watch the transition from the HAWK dashboard, by going - to https://node1:7630. -
--
- Ubuntu appears to have switched to Corosync 2 for it's LTS releases. -
-- We use aptitude to install pacemaker and some other - necessary packages we will need: -
--[ALL] # aptitude install pacemaker corosync fence-agents -
- -- Since the pcs tool from RHEL does not exist on Ubuntu, we - well create the corosync configuration file on both machines - manually: -
-
-[ALL] # cat <
- On each machine, run: -
--[ALL] # service pacemaker start -
- -- With so many devices and possible topologies, it is nearly - impossible to include Fencing in a document like this. - For now we will disable it. -
--[ONE] # crm configure property stonith-enabled=false -
-- One of the most common ways to deploy Pacemaker is in a - 2-node configuration. However quorum as a concept makes - no sense in this scenario (because you only have it when - more than half the nodes are available), so we'll disable - it too. -
--[ONE] # crm configure property no-quorum-policy=ignore -
-- For demonstration purposes, we will force the cluster to - move services after a single failure: -
--[ONE] # crm configure property migration-threshold=1 -
- -- Lets add a cluster service, we'll choose one doesn't - require any configuration and works everywhere to make - things easy. Here's the command: -
--[ONE] # crm configure primitive my_first_svc ocf:pacemaker:Dummy op monitor interval=120s -
-- "my_first_svc" is the name the service - will be known as. -
-- "ocf:pacemaker:Dummy" tells Pacemaker - which script to use - (Dummy - - an agent that's useful as a template and for guides like - this one), which namespace it is in (pacemaker) and what - standard it conforms to - (OCF). -
-- "op monitor interval=120s" tells Pacemaker to - check the health of this service every 2 minutes by - calling the agent's monitor action. -
-- You should now be able to see the service running using: -
--[ONE] # crm_mon -1 -
- -- We can simulate an error by telling the service stop - directly (without telling the cluster): -
--[ONE] # crm_resource --resource my_first_svc --force-stop -
-- If you now run crm_mon in interactive - mode (the default), you should see (within the monitor - interval - 2 minutes) the cluster notice - that my_first_svc failed and move it to - another node. -
--
- We have a quickstart edition for each major distro. To - continue, select the distribution you'll be using: -
- Now that all distributions have standardized on Corosync 2 or - greater as the underlying cluster layer, the differences are - minimal. -
-- However, in the past, Pacemaker also supported Corosync 1 (with or - without CMAN) as well as Heartbeat. Different distributions - supported different cluster layers, requiring different set-up. - We call each combination of Pacemaker and cluster layer a "stack". -
-- For example, on RHEL6 the supported stack is based on CMAN - which has APIs Pacemaker can use to obtain the membership - and quroum information it needs. Although CMAN uses - Corosync underneath, it is configured via cluster.conf and - Pacemaker is started as a separate init script. -
-- However SLES11 doesn't ship CMAN, so its users configure - corosync.conf directly and enable a custom plugin that - gets loaded into Corosync (because Corosync 1.4 doesn't - have the quorum and membership APIs needed by Pacemaker). - This plugin also starts Pacemaker automatically when - Corosync is started. -
-- To confuse things further, SLES users start Corosync with - the openAIS init script because it used to be part of that - project. -
-- See this - post for a longer discussion on the different stack - options and how they relate to cluster filesystems in particular. -
-