Manejo del Service Guard

El Service Guard es un software de HP para configurar un cluster de servidores para asegurar la "alta disponibilidad".

En el trabajo se han comprado dos servidores HP integrity 6600 y se ha configurado el producto (Service Guard) en los dos. Esta historia requiere licencia.

En /etc/cmcluster está la configuración del ServiceGuard.
/etc/cmcluster/cluster.ascii es el fichero de configuración.

Hay tres conceptos importantes en todo este tema:

Concepto de cluster:
Podemos definir varios cluster. Por defecto el nombre del primero será cluster1. El "status" del cluster es lo que siempre debería estar en UP. Mientras un nodo esté UP no debería haber problemas para que el cluster esté UP.

Concepto de nodo (NODE):
Los nodos son las máquinas que componen el cluster. En mi caso sólo hay dos pero puedes poner todos los que quieras. Es conveniente que los nodos estén en "status" UP aunque con uno es suficiente para que el cluster esté UP. También conviene que el "state" de los nodos sea "running".

Concepto de paquete (PACKAGE):
El paquete es lo que se va a mover de nodo en nodo. Se define un nodo principal y cuando falla podemos levantar el paquete en otro nodo del cluster.

COMANDOS DEL SERVICE GUARD

cmviewcl
El principal para saber como está la cosa.
Nos muestra lo siguiente:

Si nos parece poco, con la opción verbose tenemos más información:
cmviescl -v

Cuando está en el nodo que tiene el package, verás que además de la IP de la máquina está definida una IP virtual para ese paquete:

Para ver la IP física del servidor (definido por medio del APA):
ifconfig lan900
lan900 es como lo hemos definido en nuestra instalación.

Para ver la IP virtual del paquete:
ifconfig lan900:1

Si hacemos netstat -rn veremos definidos el interface lan900:1 y la ip virtual.
Todo esto sólo cuando estemos en el nodo que tiene el paquete corriendo.

Además de la IP Virtual, al ser el nodo que tiene el paquete podemos hacer un bdf, o un df -k y ver los file system. Los otros nodos no tienen en estos momentos estos file system montados. Cuando movemos el paquete a otro nodo entre otras cosas se montan automáticamente los file system. Vamos, en eso consiste el cluster.

Cuando queramos parar el paquete ejecutamos:
cmhaltpkg oracle siendo oracle el nombre del paquete.


Cuidado porque AUTO_RUN se queda en disable. Esto es porque se supone que hay un problema. Paramos el paquete y lo vamos a levantar en otro nodo, pero no queremos que se vuelva a switchear el paquete para que no vuelva.

Al hacer el halt (cmhaltpkg) se desmonta los vg-s y se quita la IP virtual.

Podemos ir a otro nodo y arrancar el paquete:
cmrunpkg oracle
Arranca el paquete, pero si estaba con AUTO_RUN disable ya no switchea automáticamente.

Modificaciones del paquete:

cmmodpkg -e oracle
Pone el AUTO_RUN a enabled. Quiere decir que se activa el switching del paquete.
Si el paquete estuviera parado lo arrancaría.
Por lo tanto es la mejor forma de arrancarlo.

cmmodpkg -d oracle
Pone el autorun a disable. Deshabilita el switching del paquete.


Por supuesto, hay muchas más cosas:

Si queremos gestionar el cluster de forma gráfica:
http://direccion-ip-servidor:2301

Para que una máquina concreta se una al cluster al arrancar:
Editamos /etc/rc.config.d/cmcluster
y ponemos AUTOSTART_CMCLD=1

Hemos visto comandos que se refieren al paquete, pero tienen sus equivalencias en nodos.
cmhaltnode para sacar un nodo del cluster.
cmrunnode para que forme parte del cluster. No hace falta que lo utilicemos porque con el AUTOSTART_CMCLD=1 ya se une en el arranque.
cmruncluster y cmhaltcluster hacen lo que su propio nombre indica :-)

La configuración del paquete se almacena en /etc/cmcluster/oracle, y dentro de este directorio, los volúmenes a montar están en oracle.cntl

ORACLE TOOLKIT

Si tenemos una B.D ORACLE, lo normal es utilizar el toolkit oracle en el cluster serviceguard. Estas toolkit se componen de scripts que hacen lo siguiente:

1.-Levantar Oracle cuando arrancamos el paquete Oracle.

2.-Monitorizar Oracle de forma que si se cae el cluster intentará levantarlo en el otro nodo.

3.-Parar Oracle cuando paremos el paquete Oracle.

Documentación completa del ORACLE TOOLKIT: http://h20000.www2.hp.com/bc/docs/support/SupportManual/c02496200/c02496200.pdf

El problema suele ser que cuando paramos el paquete, además de Oracle el serviceguard quita también la IP virtual y los volúmenes asociados al paquete. A veces necesitamos parar Oracle, pero necesitamos también tener los filesystems montados para hacer algún trabajo de mantenimiento. Esto se hace así:

#cd /etc/cmcluster/oracle

Creamos un fichero vacío llamado oracle.debug. Esto hará que se pause la monitorización:

#touch oracle.debug

Deshabilitamos el failover en caso de fallo Oracle. Lo hacemos para que no levante Oracle en el nodo pasivo:

#cmmodpkg -d oracle

Lanzamos la orden de parada Oracle:

#./toolkit.sh stop

Cuando hayamos terminado NO OLVIDAR eliminar el fichero oracle.debug.

#cmmodpkg -e oracle

#./toolkit.sh start

LO QUE DICE LA LÓGICA
Tenemos dos máquinas idénticas para una sola instancia Oracle (paquete oracle). Esta instancia va a funcionar en una máquina y si hay algún fallo pasará a la otra. Si no hay ningún fallo nunca la segunda máquina no se va a utilizar nunca. Es un cluster Activo-Pasivo.

Lo lógico es aprovechar la máquina pasiva para algo secundario como una instancia de desarrollo o pruebas Oracle. Podemos definir un nuevo paquete que corra en esta segunda máquina normalmente y si hubiera algún fallo pasaríamos el paquete a la otra.

Saludos.