diff --git a/doc/Pacemaker_Remote/en-US/Ch-Baremetal-Tutorial.txt b/doc/Pacemaker_Remote/en-US/Ch-Baremetal-Tutorial.txt index e33f5cb6a0..0e3584412c 100644 --- a/doc/Pacemaker_Remote/en-US/Ch-Baremetal-Tutorial.txt +++ b/doc/Pacemaker_Remote/en-US/Ch-Baremetal-Tutorial.txt @@ -1,251 +1,251 @@ = Baremetal Walk-through = +What this tutorial is:+ This tutorial is an in-depth walk-through of how to get pacemaker to integrate a baremetal remote-node into the cluster as a node capable of running cluster resources. +What this tutorial is not:+ This tutorial is not a realistic deployment scenario. The steps shown here are meant to get users familiar with the concept of remote-nodes as quickly as possible. -== Step 1: Setup == +== Overview == This tutorial requires three machines. Two machines to act as cluster-nodes and a third to act as the baremetal remote-node. This tutorial was tested using Fedora 18 on both the cluster-nodes and baremetal remote-node. Anything that is capable of running pacemaker v1.1.11 or greater will do though. An installation guide for installing Fedora 18 can be found here, http://docs.fedoraproject.org/en-US/Fedora/18/html/Installation_Guide/. Fedora 18 (or similar distro) host preparation steps. -=== SElinux and Firewall Considerations === +== SElinux and Firewall Considerations == In order to simply this tutorial we will disable selinux and the firewall on all the nodes. +WARNING:+ These actions will open a significant security threat to machines exposed to the outside world. [source,C] ---- # setenforce 0 # sed -i.bak "s/SELINUX=enforcing/SELINUX=permissive/g" /etc/selinux/config # firewall-cmd --add-port 3121/tcp --permanent # systemctl disable iptables.service # systemctl disable ip6tables.service # rm '/etc/systemd/system/basic.target.wants/iptables.service' # rm '/etc/systemd/system/basic.target.wants/ip6tables.service' # systemctl stop iptables.service # systemctl stop ip6tables.service ---- -=== Setup Pacemaker Remote on Baremetal remote-node === +== Setup Pacemaker Remote on Baremetal remote-node == On the baremetal remote-node machine run these commands to generate an authkey and copy it to the /etc/pacemaker folder. [source,C] ---- # mkdir /etc/pacemaker # dd if=/dev/urandom of=/etc/pacemaker/authkey bs=4096 count=1 ---- Make sure to distribute this key to both of the cluster-nodes as well. All the nodes must have the same /etc/pacemaker/authkey installed for the communication to work correctly. Now install and start the pacemaker_remote daemon on the baremetal remote-node. [source,C] ---- # yum install -y paceamaker-remote resource-agents pcs # systemctl enable pacemaker_remote.service # systemctl start pacemaker_remote.service ---- Verify the start is successful. [source,C] ---- # systemctl status pacemaker_remote pacemaker_remote.service - Pacemaker Remote Service Loaded: loaded (/usr/lib/systemd/system/pacemaker_remote.service; enabled) Active: active (running) since Thu 2013-03-14 18:24:04 EDT; 2min 8s ago Main PID: 1233 (pacemaker_remot) CGroup: name=systemd:/system/pacemaker_remote.service └─1233 /usr/sbin/pacemaker_remoted Mar 14 18:24:04 remote1 systemd[1]: Starting Pacemaker Remote Service... Mar 14 18:24:04 remote1 systemd[1]: Started Pacemaker Remote Service. Mar 14 18:24:04 remote1 pacemaker_remoted[1233]: notice: lrmd_init_remote_tls_server: Starting a tls listener on port 3121. ---- -=== Verify cluster-node Connection to baremetal-node === +== Verify cluster-node Connection to baremetal-node == Before moving forward it's worth going ahead and verifying the cluster-nodes can contact the baremetal node on port 3121. Here's a trick you can use. Connect using telnet from each of the cluster-nodes. The connection will get destroyed, but how it is destroyed tells you whether it worked or not. First add the baremetal remote-node's hostname (we're using remote1 in this tutorial) to the cluster-nodes' /etc/hosts files if you haven't already. This is required unless you have dns setup in a way where remote1's address can be discovered. Execute the following on each cluster-node, replacing the ip address with the actual ip address of the baremetal remote-node. [source,C] ---- # cat << END >> /etc/hosts 192.168.122.10 remote1 END ---- If running the telnet command on one of the cluster-nodes results in this output before disconnecting, the connection works. [source,C] ---- # telnet remote1 3121 Trying 192.168.122.10... Connected to remote1. Escape character is '^]'. Connection closed by foreign host. ---- If you see this, the connection is not working. [source,C] ---- # telnet remote1 3121 Trying 192.168.122.10... telnet: connect to address 192.168.122.10: No route to host ---- Once you can successfully connect to the baremetal remote-node from the both cluster-nodes, move on to setting up pacemaker on the cluster-nodes. -=== Install cluster-node Software === +== Install cluster-node Software == On the two cluster-nodes install the following packages. [source,C] ---- # yum install -y pacemaker corosync pcs resource-agents ---- -=== Setup Corosync on cluster-nodes === +== Setup Corosync on cluster-nodes == On one of the cluster nodes, execute the following. [source,C] ---- # export corosync_addr=`ip addr | grep "inet " | tail -n 1 | awk '{print $4}' | sed s/255/0/g` ---- Display and verify that address is correct [source,C] ---- # echo $corosync_addr ---- In many cases the address will be 192.168.1.0 if you are behind a standard home router. Now copy over the example corosync.conf. This code will inject your bindaddress and enable the vote quorum api which is required by pacemaker. [source,C] ---- # cp /etc/corosync/corosync.conf.example /etc/corosync/corosync.conf # sed -i.bak "s/.*\tbindnetaddr:.*/bindnetaddr:\ $corosync_addr/g" /etc/corosync/corosync.conf # cat << END >> /etc/corosync/corosync.conf quorum { provider: corosync_votequorum expected_votes: 2 two_node: 1 } END ---- Make sure to copy the newly created /etc/corosync/corosync.conf file to the second cluster-node before continuing. -=== Start Pacemaker on cluster-nodes === +== Start Pacemaker on cluster-nodes == Start the cluster stack on both cluster nodes using the following command. [source,C] ---- # pcs cluster start ---- Verify corosync membership [source,C] ---- # pcs status corosync Membership information Nodeid Votes Name 1795270848 1 node1 (local) ---- Verify pacemaker status. At first the 'pcs cluster status' output will look like this. [source,C] ---- # pcs status Last updated: Thu Mar 14 12:26:00 2013 Last change: Thu Mar 14 12:25:55 2013 via crmd on example-host Stack: corosync Current DC: Version: 1.1.11 1 Nodes configured, unknown expected votes 0 Resources configured. ---- After about a minute you should see your two cluster-nodes come online. [source,C] ---- # pcs status Last updated: Thu Mar 14 12:28:23 2013 Last change: Thu Mar 14 12:25:55 2013 via crmd on node1 Stack: corosync Current DC: node1 (1795270848) - partition with quorum Version: 1.1.11 2 Nodes configured, unknown expected votes 0 Resources configured. Online: [ node1 node2 ] ---- For the sake of this tutorial, we are going to disable stonith to avoid having to cover fencing device configuration. [source,C] ---- # pcs property set stonith-enabled=false ---- -=== Integrate Baremetal remote-node into Cluster === +== Integrate Baremetal remote-node into Cluster == Integrating a baremetal remote-node into the cluster is achieved through the creation of a remote-node connection resource. The remote-node connection resource both establishes the connection to the remote-node and defines that the remote-node exists. Note that this resource is actually internal to Pacemaker's crmd component. A metadata file for this resource can be found in the /usr/lib/ocf/resource.d/pacemaker/remote file that describes what options are available, but there is no actual ocf:pacemaker:remote resource agent script that performs any work. Define the remote-node connection resource to our baremetal remote-node, remote1, using the following command. [source,C] ---- # pcs resource create remote1 ocf:pacemaker:remote ---- That's it. After a moment you should see the remote-node come online. [source,C] ---- Last updated: Fri Oct 18 18:47:21 2013 Last change: Fri Oct 18 18:46:14 2013 via cibadmin on node1 Stack: corosync Current DC: node1 (1) - partition with quorum Version: 1.1.11 3 Nodes configured 1 Resources configured Online: [ node1 node2 ] RemoteOnline: [ remote1 ] remote1 (ocf::pacemaker:remote): Started node1 ---- -=== Starting Resources on baremetal remote-node === +== Starting Resources on baremetal remote-node == +"Warning: Never involve a remote-node connection resource in a resource group, colocation, or order constraint"+ Once the baremetal remote-node is integrated into the cluster, starting resources on a baremetal remote-node is the exact same as the cluster nodes. Refer to the Clusters from Scratch document for examples on resource creation. http://clusterlabs.org/doc/ -=== Fencing baremetal remote-nodes === +== Fencing baremetal remote-nodes == The cluster understands how to fence baremetal remote-nodes and can use standard fencing devices to do so. No special considerations are required. Note however that remote-nodes can never initiate a fencing action. Only cluster-nodes are capable of actually executing the fencing operation on another node. -=== Accessing Cluster Tools from a Baremetal remote-node === +== Accessing Cluster Tools from a Baremetal remote-node == Besides allowing the cluster to manage resources on a remote-node, pacemaker_remote has one other trick. +The pacemaker_remote daemon allows nearly all the pacemaker tools (crm_resource, crm_mon, crm_attribute, crm_master) to work on remote nodes natively.+ Try it, run +crm_mon+ or +pcs status+ on the baremetal node after pacemaker has integrated the remote-node into the cluster. These tools just work. These means resource agents such as master/slave resources which need access to tools like crm_master work seamlessly on the remote-nodes.