5.0: Heartbeat HA Configuration: Difference between revisions

From SambaWiki
No edit summary
No edit summary
Line 41: Line 41:



The heartbeat solution is not needed for domain logons; however in mission critical environments it supports failover if a node becomes unavailable. It provides a heartbeat through a serial and a crossover connection directly connected to each server. A virtual IP is shared by the cluster; we connect to this virtual IP Address when accessing a Samba share.
The heartbeat solution is not needed for domain logons; however in mission critical environments it supports failover if a node becomes unavailable. It provides a heartbeat through a serial and a crossover connection directly connected to each server. A virtual IP is shared by the cluster; we connect to this virtual IP Address when accessing a Samba share.



There are 2 main differential versions of heartbeat - version 1.2.3 is limited to a two node cluster; version 2 can span many machines and can become quite complex. Heartbeat version 2 is however backwards compatible with version 1.2.3 configuration files using the “crm no” option in the ha.cf configuration file.
There are 2 main differential versions of heartbeat - version 1.2.3 is limited to a two node cluster; version 2 can span many machines and can become quite complex. Heartbeat version 2 is however backwards compatible with version 1.2.3 configuration files using the “crm no” option in the ha.cf configuration file.



You must never mix different versions of heartbeat in a cluster; they must all run the same version. If you do it will create instability and may lead to random rebooting.
You must never mix different versions of heartbeat in a cluster; they must all run the same version. If you do it will create instability and may lead to random rebooting.



If you want to be completely safe I highly recommend using version 1.2.3, for this exercise however we will be using version heartbeat 2.
If you want to be completely safe I highly recommend using version 1.2.3, for this exercise however we will be using version heartbeat 2.



If you are looking for proven stability version 1.2.3 has been used with DRBD for a long time; it is often used in hospitals to store MRI and other data that needs to be readily accessible; currently this is limited to a 2 node cluster.
If you are looking for proven stability version 1.2.3 has been used with DRBD for a long time; it is often used in hospitals to store MRI and other data that needs to be readily accessible; currently this is limited to a 2 node cluster.

Revision as of 13:47, 25 January 2007

1.0: Configuring Samba

2.0: Configuring LDAP

3.0: Initialization LDAP Database

4.0: User Management

5.0: Heartbeat HA Configuration

6.0: DRBD

7.0: BIND DNS



Table of Contents

5.1 Requirements

5.2 Installation

5.3 Configuration

5.3.1 ha.cf

5.3.2 haresources

5.3.3 authkeys

5.4 Testing


Heartbeat Configuration

Node1

Node2


The heartbeat solution is not needed for domain logons; however in mission critical environments it supports failover if a node becomes unavailable. It provides a heartbeat through a serial and a crossover connection directly connected to each server. A virtual IP is shared by the cluster; we connect to this virtual IP Address when accessing a Samba share.


There are 2 main differential versions of heartbeat - version 1.2.3 is limited to a two node cluster; version 2 can span many machines and can become quite complex. Heartbeat version 2 is however backwards compatible with version 1.2.3 configuration files using the “crm no” option in the ha.cf configuration file.


You must never mix different versions of heartbeat in a cluster; they must all run the same version. If you do it will create instability and may lead to random rebooting.


If you want to be completely safe I highly recommend using version 1.2.3, for this exercise however we will be using version heartbeat 2.


If you are looking for proven stability version 1.2.3 has been used with DRBD for a long time; it is often used in hospitals to store MRI and other data that needs to be readily accessible; currently this is limited to a 2 node cluster.