Multi-tenant multi-datacenters network virtualization platform

Hasta el momento se ha visto como realizar una configuración básica de Heartbeat-2, de modo que mientras el número de recursos a configurar y el comportamiento que se le exija, tanto a estos como al cluster, no sea muy especifico, es más que suficiente. Sin embargo si necesitamos dotar de alta disponibilidad a muchos servicios se hacen necesarios mecanismos adicionales de configuración que faciliten la tarea.

Supongamos que vamos a dotar de alta disponibilidad a tres recursos: un servicio Web, un servicio de base de datos y una IP Virtual mediante la cuál accederán los clientes externos al portal que hemos creado para nuestra empresa. Si analizamos la situación en la que estos recursos han de funcionar podemos observar el siguiente comportamiento:

Tanto el servicio Web, el servicio de base de datos como la IP Virtual deben

ejecutarse siempre juntos en el mismo nodo, ya que el servicio Web sin base de datos no puede funcionar, y del mismo modo, si la dirección IP Virtual no se encuentra levantada en el nodo donde se encuentran los servicios ejecutándose, los clientes no pueden acceder al servicio.

Entre los tres servicios existe un cierto orden lógico para comenzar a

ejecutarse. No tiene sentido tener la dirección IP Virtual levantada y aún no tener ejecutándose ninguno de los dos servicios. El resultado sería que los clientes podrían alcanzar la dirección IP pero no se ofrecería ningún servicio en ella. Además el servicio Web requiere que previamente haya sido ejecutado el servicio de base de datos ya que si los clientes acceden al servicio Web, la página Web no va a mostrar contenido ya que las consultas no pueden llevarse a cabo.

Estas restricciones se pueden establecer con lo que se ha visto hasta el momento, sin embargo, es cierto que el número de restricciones resultantes va a ser elevado, y no pensemos en la posibilidad de además de tener estos tres servicios se tengan otros tres servicios más que cumplan estas mismas restricciones de comportamiento y además ambos conjuntos no puedan ejecutarse en el mismo nodo.

Heartbeat-2 solventa estos inconvenientes de configuración permitiendo agrupar los

recursos para formar un grupo entre sí, a lo que denomina “grupo de recursos”. Principalmente la finalidad de hacer un grupo de recursos es:

Los recursos del grupo siempre se ejecutan en el mismo nodo. Cada recurso del

grupo tendrá implícita una restricción de colocación con el resto de recursos.

Los recursos del grupo siempre arrancan y paran en un determinado orden.

Cada recurso tendrá implícita una restricción de orden.

Esto facilita enormemente la configuración y posterior mantenimiento del cluster aunque se crea una desventaja, y es que perdemos el gran potencial que se tiene cuando se definen de manera individual cada una de las restricciones para cada uno de los recursos, sin embargo, personalmente opino que para la mayoría de las situaciones las ventajas son mucho más interesantes.

Hay que recordar que si en el archivo haresources se escriben los recursos en una misma línea se está definiendo automáticamente un grupo de recursos, es decir, por cada

línea a modo de listado de recursos en haresources se crea un grupo de recursos, donde los recursos además se ejecutarán en el orden en el que se listen, de izquierda a derecha y pararan secuencialmente en orden inverso, de derecha a izquierda.

Continuando con el ejemplo anterior, se muestra a continuación cómo definir los recursos para formar con ellos un grupo. Por lo tanto, estos recursos comenzarán y siempre se ejecutarán en el mismo nodo además de comenzar y parar en el orden en que se declaren dentro del grupo.

<group id="MiEmpresaWWW">

<primitive id="IPServidorWeb" class="ocf" type="IPaddr" provider="Heartbeat">

<instance_attributes> <attributes>

<nvpair name="ip" value="127.0.0.26"/> </attributes>

</instance_attributes> </primitive>

<primitive id="ServidorBaseDatosWeb" class="lsb" type="oracle" provider="Heartbeat">

<instance_attributes> <attributes>

<nvpair name="SID" value="servidorweb_db"/> </attributes>

</instance_attributes> </primitive>

<primitive id="ServidorWebApache" class="ocf" type="Apache" provider="Heartbeat"> <instance_attributes> <attributes> <nvpair name="apache_config" value="/home/www.miempresa.com/conf/apache.conf"/> </attributes> </instance_attributes> </primitive> </group>

Como se puede apreciar en el ejemplo, hay que definir una serie de recursos de manera individual con la diferencia de que la definición de los recursos va entre las etiquetas <group> y </group>.

Del mismo modo que para un recurso individual, a los grupos de recursos también se le pueden definir restricciones. El concepto de restricción es el mismo que para un recurso individual salvo que ahora se establece a más de un recurso simultáneamente. La mejor manera de definir correctamente las restricciones para un grupo de recursos es pensar como si se tratara de un recurso individual, aunque de mayor abstracción, pero al fin y al cabo un recurso individual.

Por ejemplo, si se quiere que el portal Web de nuestra empresa comience inicialmente a ejecutarse en el nodo luna, la restricción de localización sería como sigue:

<constraints>

<rsc_location id="run_MiEmpresaWWW" rsc="MiEmpresaWWW"> <rule id="pref_run_IPServidorWeb" score="100">

<expression attribute="#uname" operation="eq" value="luna"/>

</rule> </rsc_location> </constraints>

Ahora el valor del atributo rsc es el identificador del grupo al cuál se va a aplicar dicha restricción. En el ejemplo el identificador del grupo es “MiEmpresaWWW”.

Para el resto de restricciones la filosofía con grupos de recursos es lo mismo que para recursos individuales.

Si para los recursos se puede crear un grupo de recursos, para los nodos sucede lo mismo. Varios nodos pueden agruparse formando un conjunto de nodos entre sí lo que facilita enormemente la configuración del cluster para aquellos casos en los que se tienen un gran número de nodos en el cluster.

Por ejemplo, supongamos un cluster se compone de 27 nodos: un nodo A, B,…., Z y el recurso IPServidorWeb. Si un determinado recurso R no puede ejecutarse en los nodos que van desde el M hasta el Z no es necesario establecer una restricción de localización como la que se muestra a continuación para cada uno de los nodos:

<rsc_location id="run_IPServidorWeb" rsc="IPServidorWeb"> <rule id="pref_run_IPServidorWeb" score="-INFINITY">

<expression attribute="#uname" operation="ne" value="nodoX"/> </rule>

</rsc_location>

Simplemente se define un grupo de nodos formado por los nodos del M al Z y con una única restricción de localización indicando en el atributo value el nombre del grupo de nodos.

<nodes>

<node id="f67904e0-4dfc-4db1-83a2-e930fc1d20f4" uname="nodoA" type="member">

<instance_attributes> <attributes>

<nvpair name="cluster_group" value="grupo_nodos_1"/> </attributes>

</instance_attributes> </node>

…

<node id="c2896699-96b8-4dbc-a94e-6c3b9252b559" uname="nodoZ" type="member">

<instance_attributes> <attributes>

<nvpair name="cluster_group" value="grupo_nodos_1"/> </attributes>

</instance_attributes> </node>

</nodes> <constraints>

<rsc_location id="run_IPServidorWeb" rsc="IPServidorWeb"> <rule id="pref_run_IPServidorWeb" score="-INFINITY">

<expression attribute="#uname" operation="ne" value="grupo_nodos_1"/>

</rule> </rsc_location> </contraints>

Heartbeat-2 dispone además de muchos otros mecanismos que permiten configurar el

cluster de alta disponibilidad a nuestra medida: Stonith, Softdog, etc. Uno de los más útiles es

pingd, que sustituye a IPFail de Heartbeat-1, de tal manera que si una interfaz cae o la red a la

que estamos conectados no es alcanzable debido a un problema de algún dispositivo hardware o por la presencia de un cortafuegos, se puede establecer que los recursos del nodo que ha perdido la conectividad migren a otro nodo o migren simplemente al nodo con mayor conectividad.

Pingd realiza su función en colaboración con los PingNodes. En la figura 4-6. IPFail Heartbeat

se muestra un escenario donde se hace uso de dos interfaces, una de ellos para mantener la comunicación con el otro nodo del cluster y la otra para mantener conectividad con el PingNode además se puede ver como en caso de pérdida de conectividad con el PingNode, los recursos pasan a ser responsabilidad del otro nodo.

Figura 4-6. IPFail Heartbeat