• Tweet
• Email

• Tweet
• Email

Hace aproximadamente 1 año, realice un post donde explicaba como hacer la instalación de dos servidores de alta disponibilidad usando Heartbeat, en ese caso era simplemente para un Proxy. Luego 6 meses atrás explique como instalar un cluster de alta disponibilidad con Heartbeat, Mysql y Centos, bueno hasta ahora puedo decir que el que instale hace 1 año con los proxys no ha fallado, y el que monte con mysql no solo que no ha fallado sino que he realizado instalaciones similares ya que me ha ido bastante bien, a parte de aplicarlo a otros servicios como el Ftp.

En este caso les traigo como realizar la instalación de un Cluster con Heartbeat y Cualquier servicio con CRM, la diferencia es que en esta ocasión me interesa usar el modo CRM de Heartbeat. Para quienes no sepan lo que es el modo CRM, consiste en un XML que generamos en el nodo 1 y que Heartbeat se encargara de propagar a los demás nodos. Este XML conocido con el nombre de cib.XML, es un fichero que tendremos ubicado en /var/lib/heartbeat/crm/cib.xml, y es quien contiene toda la informacion del equipo entre ellas, Id’s  de cada nodo, datos de cada interfaz, servicio a monitorizar entre otras.

Para configurar el Heartbeat en este caso usaremos el siguiente manual, para este caso usaremos como ejemplo la instalacion de un Cluster Heartbeat, Mysql, con CRM.

Una vez hayamos configurado el Heartbeat como en el manual anterior, debemos realizar una modificación en nuestro fichero /etc/ha.d/ha.cf el cambio sera agregar :

crm yes

Esta linea sera la encargada de informarle a heartbeat que el modo de crm esta activo y que por ende no debe consultar el fichero haresources sino que por el contrario deberá consultar el cib.XML.

En este punto es necesario generar el cib.XML, este fichero lo creamos con una utilidad de Heartbeat, conocida como  haresources2cib.py esta utiildad se encuentra en /usr/lib/heartbeat/, es un python que se encarga de transformar nuestro haresource a formato xml de cib, el genera los id de los nodos y toda la información necesaria.

Para generar el script es suficiente con ejecutar la utilidad siempre y cuando tengamos nuestro haresource en la ruta /etc/ha.d/haresources, y nos generara un archivo con el siguiente contenido, en la ruta /var/lib/heartbeat/crm/

<?xml version=”1.0″ ?>
<cib admin_epoch=”0″ epoch=”0″ num_updates=”0″>
<configuration>
<crm_config>
<cluster_property_set id=”cib-bootstrap-options”>
<attributes>
<nvpair id=”cib-bootstrap-options-symmetric-cluster” name=”symmetric-cluster” value=”true”/>
<nvpair id=”cib-bootstrap-options-no-quorum-policy” name=”no-quorum-policy” value=”stop”/>
<nvpair id=”cib-bootstrap-options-default-resource-stickiness” name=”default-resource-stickiness” value=”0″/>
<nvpair id=”cib-bootstrap-options-default-resource-failure-stickiness” name=”default-resource-failure-stickiness” value=”0″/>
<nvpair id=”cib-bootstrap-options-stonith-enabled” name=”stonith-enabled” value=”false”/>
<nvpair id=”cib-bootstrap-options-stonith-action” name=”stonith-action” value=”reboot”/>
<nvpair id=”cib-bootstrap-options-startup-fencing” name=”startup-fencing” value=”true”/>
<nvpair id=”cib-bootstrap-options-stop-orphan-resources” name=”stop-orphan-resources” value=”true”/>
<nvpair id=”cib-bootstrap-options-stop-orphan-actions” name=”stop-orphan-actions” value=”true”/>
<nvpair id=”cib-bootstrap-options-remove-after-stop” name=”remove-after-stop” value=”false”/>
<nvpair id=”cib-bootstrap-options-short-resource-names” name=”short-resource-names” value=”true”/>
<nvpair id=”cib-bootstrap-options-transition-idle-timeout” name=”transition-idle-timeout” value=”5min”/>
<nvpair id=”cib-bootstrap-options-default-action-timeout” name=”default-action-timeout” value=”20s”/>
<nvpair id=”cib-bootstrap-options-is-managed-default” name=”is-managed-default” value=”true”/>
<nvpair id=”cib-bootstrap-options-cluster-delay” name=”cluster-delay” value=”60s”/>
<nvpair id=”cib-bootstrap-options-pe-error-series-max” name=”pe-error-series-max” value=”-1″/>
<nvpair id=”cib-bootstrap-options-pe-warn-series-max” name=”pe-warn-series-max” value=”-1″/>
<nvpair id=”cib-bootstrap-options-pe-input-series-max” name=”pe-input-series-max” value=”-1″/>
</attributes>
</cluster_property_set>
</crm_config>
<nodes/>
<resources>
<group id=”group_1″>
<primitive id=”LVSSyncDaemonSwap_1″ provider=”heartbeat” type=”LVSSyncDaemonSwap”>
<operations>
<op id=”LVSSyncDaemonSwap_1_mon” interval=”120s” name=”monitor” timeout=”60s”/>
</operations>
<instance_attributes id=”LVSSyncDaemonSwap_1_inst_attr”>
<attributes>
<nvpair id=”LVSSyncDaemonSwap_1_attr_1″ name=”1″ value=”master”/>
</attributes>
</instance_attributes>
</primitive>
<primitive id=”IPaddr2_2″ provider=”heartbeat” type=”IPaddr2″>
<operations>
<op id=”IPaddr2_2_mon” interval=”5s” name=”monitor” timeout=”5s”/>
</operations>
<instance_attributes id=”IPaddr2_2_inst_attr”>
<attributes>
<nvpair id=”IPaddr2_2_attr_0″ name=”ip” value=”192.168.2.2″/>
<nvpair id=”IPaddr2_2_attr_1″ name=”nic” value=”eth0″/>
<nvpair id=”IPaddr2_2_attr_2″ name=”cidr_netmask” value=”24″/>
<nvpair id=”IPaddr2_2_attr_3″ name=”iflabel” value=”1″/>

</attributes>
</instance_attributes>
</primitive>
<primitive id=”mysql_3″ provider=”heartbeat” type=”mysql”>
<operations>
<op id=”mysql_3_mon” interval=”30s” name=”monitor” timeout=”5s”/>
</operations>
</primitive>
</group>
</resources>
<constraints>
<rsc_location id=”rsc_location_group_1″ rsc=”group_1″>
<rule id=”prefered_location_group_1″ score=”100″>
<expression attribute=”#uname” id=”prefered_location_group_1_expr” operation=”eq” value=”mysql01″/>
</rule>
</rsc_location>
</constraints>
</configuration>
<status/>
</cib>

Hay unos parametros que tenemos que tener en cuenta, en el apartado de la interfaz de red este debe estar de la siguiente forma.

<nvpair id=”IPaddr2_2_attr_0″ name=”ip” value=”192.168.2.2″/>
<nvpair id=”IPaddr2_2_attr_1″ name=”nic” value=”eth0″/>
<nvpair id=”IPaddr2_2_attr_2″ name=”cidr_netmask” value=”24″/>
<nvpair id=”IPaddr2_2_attr_3″ name=”iflabel” value=”1″/>

Esto permite que nuestro heartbeat sepa que la ip “192.168.2.2” estará como el interfaz virtual “1” de la interfaz física “eth0“.

Cada vez que hagamos un cambio en el cib.xml debemos hacerlo en el nodo01, y borrar todo el contenido del directorio /var/lib/heartbeat/crm/ en el nodo02. esto permitirá asegurarnos de estar usando el fichero cib.xml actualizado.

El modo CRM tiene una ventaja sustancial sobre el heartbeat, y es que este le agrega una funcionalidad conocida como MONITOR, esta funcionalidad radica en que heartbeat verifica que los servicios especifiquemos estén levantados con scripts OCF mediante la función monitor. En el cib.xml podemos programar los tiempos de caída, y el numero de re intentos antes de que tome el control el nodo 2, esto se hace para verificar que hay fallos de servicios que son muy comunes si no puede iniciarlo pues lo que haría es detener los servicios con el Stonich y asegurarse que estos están detenidos para luego enviar el ip virtual al nodo 2.