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.
Muy buen articulo, me ha servido de mucho. Comentas que se puede configurar el heartbeat para que si un servicio se cae este lo trate de levantar, esto lo hace de forma automática, creo, pero como se puede configurar el número de veces que tarta de levantarlo? por defecto creo que es 999999 veces. Se puede configurar??
Muchas gracias
Hay varios parametros en el cib.xml esenciales, el stickness es uno de ellos y el otro es el timeout. El timeout es el numero de segundos para que deje de intentar levantar el servicio. el stickness es el numero de segundos que debe esperar el segundo nodo antes de devolver los servicios al primer nodo, esto se configura por seguridad para que si el primer equipo cae, y luego vuelve a aparecer por un periodo muy corto pues no estemos experimentando esa intermitencia normalmente yo le pondría unos 5 minutos de stickness.
Muchas gracias, funciona perfecto. Otra preguntilla…
Una vez que lo tengo todo funcionando lo pongo en marcha, pero me hace una cosa un poco rara, es decir, yo enciendo el nodo1 y el 2, pues la ip virtual se me queda en el nodo1, como es normal mientras que le nodo1 funcione, pero el servicio que estoy monitorizando, se me va al nodo2, si por lo que sea el nodo2 cae, el servicio vuelve al nodo1, raro no?
No debería quedarse el servicio en el nodo1 junto con la ip??
Te ha pasado algo parecido??
Muchas gracias
Eso no deberia estar ocurriendo que servicio estas monitorizando? de donde sacaste el ocf de ese servicio?
Estoy monitorizando el asterisk, el ocf le saque de un compañero de la lista que lo hizo y no ha tenido ningun problema.
Funcionar funciona, pero lo cruza.
que Extrano eso tiene que ver quizas con el cib.xml revisa bien especialmente que en el chequeo del servicio estes usando ocf y no lsb
Al final me ha funcionado, quite el cib.xml de los 2 servers, le puse otra vez el en master y funciona.
Me imagino que seria algo que meti mal o en orden incorrecto o algo asi.
Muchas gracias
@:
Una pregunta, cuando usamos crm la opcion auto_failback deja de funcionar, entonces, como podemos hacer que si el master falla vaya al esclavo, pero que si el master vuelve se quede en el esclavo??
Sabes como se podria hacer??
Muchas gracias
@: coye no lo he probado en realidad siempre me ha interesado que si vuelve el master vuelva a tomar el control en eso consiste el failover no?