= 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.

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 20 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 20 can be found here, http://docs.fedoraproject.org/en-US/Fedora/20/html/Installation_Guide/.

Fedora 20 (or similar distro) host preparation steps.

== 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 ==

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 pacemaker-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 ==

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 ==

On the two cluster-nodes install the following packages.

[source,C]
----
# yum install -y pacemaker corosync pcs resource-agents
----

== Setup Corosync on cluster-nodes ==

Corosync handles pacemaker's cluster membership and messaging. The corosync config file is located in /etc/corosync/corosync.conf. That config file must be initialized with information about the two cluster-nodes before pacemaker can start.

To initialize the corosync config file, execute the following pcs command on both nodes filling in the information in <> with your nodes' information.
[source,C]
----
# pcs cluster setup --local mycluster <node1 ip or hostname> <node2 ip or hostname>
----

A recent syntax change in pcs may cause the above command to fail. If so try this alternative.
[source,C]
----
# pcs cluster setup --force --local --name mycluster <node1 ip or hostname> <node2 ip or hostname>
----

== 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 ==

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 ==

+"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 ==

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 ==

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.

