Difference between revisions of "User talk:Gertp"
| Line 1: | Line 1: | ||
| − | |||
== BDII setup on active/passive failover cluster == | == BDII setup on active/passive failover cluster == | ||
| Line 8: | Line 7: | ||
This script is very much like an "init.d" script, but you can't directly use an init.d script as heartbeat scripts use tri-state logic in stead of two-state logic. I.e., heartbeat controlled services are "running", "stopped" or "failed", whereas services controlled by init that fail are stopped and must be restarted. Heartbeat uses the third state "failed" as the trigger to migrate the service to another node in your services pool. | This script is very much like an "init.d" script, but you can't directly use an init.d script as heartbeat scripts use tri-state logic in stead of two-state logic. I.e., heartbeat controlled services are "running", "stopped" or "failed", whereas services controlled by init that fail are stopped and must be restarted. Heartbeat uses the third state "failed" as the trigger to migrate the service to another node in your services pool. | ||
| − | For a simple service consisting of one process, monitoring is easy and | + | For a simple service consisting of one process, monitoring is easy and adaptation of an existing init.d script straighforward. Hint: use the sample |
| + | /usr/lib/ocf/resource.d/heartbeat/Dummy | ||
| + | as a starting-point. | ||
Revision as of 12:12, 29 March 2011
BDII setup on active/passive failover cluster
Generic active/passive clusters
Configuring a cluster using corosync and heartbeat involves you having to write a start/stop and monitoring script for the service you are building the cluster for.
This script is very much like an "init.d" script, but you can't directly use an init.d script as heartbeat scripts use tri-state logic in stead of two-state logic. I.e., heartbeat controlled services are "running", "stopped" or "failed", whereas services controlled by init that fail are stopped and must be restarted. Heartbeat uses the third state "failed" as the trigger to migrate the service to another node in your services pool.
For a simple service consisting of one process, monitoring is easy and adaptation of an existing init.d script straighforward. Hint: use the sample
/usr/lib/ocf/resource.d/heartbeat/Dummy
as a starting-point.
Install the cluster engine & resource manager
You need to perform the installation on each cluster node.
Add the EPEL repo to /etc/yum.repos.d:
# rpm -Uhv http://download.fedora.redhat.com/pub/epel/5/x86_64/epel-release-5-4.noarch.rpm
Add the Clusterlabs repo to /etc/yum.repos.d:
# wget -O /etc/yum.repos.d/pacemaker.repo http://clusterlabs.org/rpm/epel-5/clusterlabs.repo
Now have yum install the cluster engine and resource managers. This will install loads of dependencies:
# yum -y install pacemaker
