diff --git a/doc/Pacemaker_Explained/en-US/Ap-Install.xml b/doc/Pacemaker_Explained/en-US/Ap-Install.xml index f6fe4578f0..72341ba849 100644 --- a/doc/Pacemaker_Explained/en-US/Ap-Install.xml +++ b/doc/Pacemaker_Explained/en-US/Ap-Install.xml @@ -1,108 +1,108 @@ Installation
Choosing a Cluster Stack Ultimately the choice of cluster stack is a personal decision that must be made in the context of you or your company's needs and strategic direction. Pacemaker currently functions equally well with both stacks. Here are some factors that may influence the decision SUSE/Novell, Red Hat and Oracle are all putting their collective weight behind the Corosync cluster stack. Corosync is an OSI Certified implementation of an industry standard (the Service Availability Forum Application Interface Specification). Using Corosync gives your applications access to the following additional cluster services checkpoint service distributed locking service extended virtual synchrony service cluster closed process group service It is likely that Pacemaker, at some point in the future, will make use of some of these additional services not provided by Heartbeat To date, Pacemaker has received less real-world testing on Corosync than it has on Heartbeat.
Enabling Pacemaker
For Corosync The Corosync configuration is normally located in /etc/corosync/corosync.conf and an example for a machine with an address of 1.2.3.4 in a cluster communicating on port 1234 (without peer authentication and message encryption) is shown below. An example Corosync configuration file totem { version: 2 secauth: off threads: 0 interface { ringnumber: 0 bindnetaddr: 1.2.3.4 mcastaddr: 226.94.1.1 mcastport: 1234 } } logging { fileline: off to_syslog: yes syslog_facility: daemon } amf { mode: disabled } The logging should be mostly obvious and the amf section refers to the Availability Management Framework and is not covered in this document. - The interesting part of the configuration is the totem section. This is where we define the how the node can communicate with the rest of the cluster and what protocol version and options (including encryption + The interesting part of the configuration is the totem section. This is where we define how the node can communicate with the rest of the cluster and what protocol version and options (including encryption Please consult the Corosync website and documentation for details on enabling encryption and peer authentication for the cluster. ) it should use. Beginners are encouraged to use the values shown and modify the interface section based on their network. It is also possible to configure Corosync for an IPv6 based environment. Simply configure bindnetaddr and mcastaddr with their IPv6 equivalents. Eg Example options for an IPv6 environment bindnetaddr: fec0::1:a800:4ff:fe00:20 mcastaddr: ff05::1 To tell Corosync to use the Pacemaker cluster manager, add the following fragment to a functional Corosync configuration and restart the cluster. Configuration fragment for enabling Pacemaker under Corosync aisexec { user: root group: root } service { name: pacemaker ver: 0 } The cluster needs to be run as root so that its child processes (the lrmd in particular) have sufficient privileges to perform the actions requested of it. After-all, a cluster manager that can't add an IP address or start apache is of little use. The second directive is the one that actually instructs the cluster to run Pacemaker.
For Heartbeat Add the following to a functional ha.cf configuration file and restart Heartbeat Configuration fragment for enabling Pacemaker under Heartbeat crm respawn