Veritas Cluster

ARQUITECTURA:

Básicamente Veritas se caracteriza por ser un gestor de recursos software y hardware, con el objetivo de dar alta disponibilidad.

1.      INTRODUCCION:

VCS PAQUETES

Los paquetes instalados de VCS son los siguientes:

VRTSllt

VRTSgab

VRTSperl

VRTSvcs

VRTSweb

VRTSvcsw

VRTSvcsdc:

VERIFICANDO LA INSTALACION DE VxFS

# pkginfo Comando para la visualización de todos los paquetes

# pkginfo | grep VRTS Comando para la visualización de los paquetes de Veritas

# pkginfo –l VRTSvcs : Comando para visualizar un paquete concreto.

LICENCIAS DE USO

Veritas Cluster Server es un paquete bajo licencia.

-         Comando para visualizar el estado de las licencias:

# vxlicrep

-         Comando para instalar nuevas licencias

# vxlicinst

COMANDOS DE VCS

Localización de los Comandos VCS

 /opt/VRTSvcs/sbin

 /opt/VRTSllt

 /sbin

Se deben de especificar los tres directorios en la variable PATH.

2.     CONCEPTOS

Los nodos del cluster se comunican a través de una red privada mediante latidos

(heartbeats). Esto permite reconocer que sistemas están disponibles dentro del cluster, cuales están abandonando o ingresando en el cluster o cuales han fallado. Por lo tanto, aporta una comunicación entre el cluster, y la distribución de la configuración.

El motor de VCS es conocido como “had”, el cual, se ejecuta en cada sistema del cluster. VCS monitoriza el sistema y sus servicios sobre la red privada.

Cada nodo del cluster tiene su propia copia del software del cluster, su propia licencia de uso de VCS, librerías, programas, scripts, ejecutables, etc.

Todos los nodos del cluster comparten una vista común de la configuración del cluster, la cual es dinámicamente comunicada.

Tipos de elementos:

SERVICE GROUPS

Un service group es una colección de recursos (hardware y software) que trabajan conjuntamente para proporcionar un servicio de aplicación a los clientes.

Los service groups pueden ser de uno de los siguientes tipos:

 Failover:

El service group corre solamente en un sistema en el cluster al mismo tiempo. Se rearranca en otro sistema cuando falla el servicio.

 Parallel:

El service group corre en distintos sistemas del cluster al mismo tiempo.

RECURSOS

Los recursos son entidades hardware y software como por ejemplo: discos, tarjetas de red, la dirección IP, una aplicación..., que son monitorizados y controlados por VCS. Se clasifican por tipo y conjuntamente forman bloques que conforman Service groups.

Es posible establecer depencias entre recursos. Por ejemplo, el recurso IP 10.0.0.1 depende de la tarjeta de red hme0 (el NIC físico).

Son las descripciones genéricas de los atributos necesarios para definir un recurso.

Existen 3 clases de tipos de recursos:

 Bundled (por ejemplo , recurso de tipo IP)

 Enterprise (recurso bajo licencia Oracle)

 Custom (Desarrollo propio)

AGENTES

Los agentes son procesos VCS que monitorizan recursos e informan de cualquier cambio de estado, al motor de VCS (had).

Cada tipo de recurso tiene su correspondiente agente que maneja todos los recursos de ese tipo. En cada sistema corre solo un proceso agente por cada tipo de recurso.

VCS controla los recursos, y su motor had, que a través de sus agentes correspondientes, básicamente actúa sobre ellos de la siguiente forma:

 Pone un recurso online (starting)

 Pone un recurso offline (stopping)

 Monitoriza su status (probing)

El estado de los mismos dependerá de las dependencias indicadas en la configuración.

CONFIGURACIÓN DEL CLUSTER

El motor de VCS (had) mantiene la configuración de todos los recursos del cluster en memoria, de cada nodo del cluster. Asimismo, en determinadas ocasiones, la configuración se guarda en el fichero main.cf. y reside en el disco de cada sistema.

La información de la configuración y el estado del cluster, es comunicado hacia todos los nodos por la red privada del cluster para asegurar que cada nodo tiene la misma vista del cluster. El fichero main.cf reside en directorio /etc/VRTSvcs/conf/config, y sirve como salvaguarda de la configuración, de forma que pueda recrearse cuando los sistemas reinician y en determinadas condiciones forzadas por el Administrador.

MODIFICAR LA CONFIGURACIÓN DEL CLUSTER

VCS guarda la configuración en memoria y la escribe a disco cuando el administrador usa el comando ‘haconf ’.

Cuando esto ocurre, VCS considera que la configuración se encuentra en un estado denominado ‘stale’ (rancio).

Un fichero “.stale” es creado cuando el administrador abre la configuración para cualquier modificación. Cuando el administrador cierra la configuración el fichero .stale se borra.

Veamos los comandos de VCS para la apertura, salvado y cierre de la configuración.

El comando ‘haconf ’ es usado para abrir y cerrar la configuración de cluster:

Abrir:

#haconf -makerw

Salvar

#haconf -dump

Salvar y Cerrar:

#haconf –dump –makero

Cuando no se realiza el guardado de la configuración  y se reinicia el servidor puede ocurrir que:

1.- hastart

2.- Se verifica la conf y se detecta el .stale

3.- Se chequea si existe algún sistema con la conf. Válida en la red privada.

4.- Se recibe la configuración válida.

CONGELACIÓN: PREVENCIÓN DE FAILOVER

Es posible la congelación de un Service Group para evitar su “failover”, bajo algunas circunstancias, por ejemplo, cuando se realizar labores de test o mantenimiento, de forma que ante el fallo de un recurso crítico, el SG es prevenido de cambiar de nodo del cluster.

El congelado puede ser permanente, de forma que aunque VCS se reinicie, se mantiene su estado; o temporal.

#hagrp –freeze SG –persistent

# hagrp –unfreeze SG –persistent

LIMPIEZA DE FALTAS

Cuando un recurso no persistente ha fallado, se debe de limpiar la falta. Después de esta operación el Recurso pasará de estado FAULTED a OFFLINE, y después será posible su puesta ONLINE por el operador.

#hares –clear resource_name

#hares –clear SG

Los recursos persistentes son “limpiados” probándolos:

# hares –probe resource_name

3.     COMANDOS BASICOS

1. ARRANQUE DE VCS

Veamos inicialmente, el proceso de arranque de VCS, desde una situación de parada de todos los nodos del cluster.

Premisa: Inicialmente no existen más nodos activos.

Comando para arranque de VCS en un nodo:

#hastart

2. PARADA DEL CLUSTER

A continuación, se muestran todos los tipos de paradas y su correspondiente comando:

1.-Parar VCS (had) y situar los SG offline (parar las aplicaciones) en un nodo:

#hastop –local

#hastop –sys sysname

2.- Parar VCS y evacuar los SG a otro nodo donde corre VCS.

#hastop –local – evacuate

#hastop –sys sysname –evacuate

3.- Parar VCS y dejar las aplicaciones corriendo. Pero, en este caso, las aplicaciones dejan de estar bajo el control del cluster.

#hastop –local –force

#hastop -sys sysname –force

Comandos de STOP GENERALISTA:

Parar VCS en todos los nodos del cluster

# hastop –all

Parar VCS y dejar las aplicaciones corriendo

# hastop –all –force

3. VISUALIZANDO EL ESTADO DEL CLUSTER

Información general del cluster:

#hastatus –summary (interrumpir con ctrl.+C)

Para el estado de un SG concreto hay que usar la opcion –group

#hastatus –group <SG> […]

4. FORZAR EL ARRANQUE DEL CLUSTER

Si no hay sistemas corriendo VCS, y si la configuración esta en stale, se puede forzar el arranque de VCS usando el comando:

#hastart –force

5. FORZAR A UN SISTEMA A ARRANCAR EL CLUSTER

Si todos los sistemas están en situación .stale, (estado STALE_ADMIN._WAIT) ejecutar el siguiente comando desde cualquier nodo del cluster y forzar a recoger la configuración local:

# hasys –force system

6. VALIDANDO LA CONFIGURACIÓN DEL CLUSTER

El comando hacf verifica la sintaxis del fichero main.cf, actuando como un intérprete entre el fichero basado en texto y el motor de VCS.

De esta forma, es posible verificar la sintaxis del fichero main.cf antes de aplicarlo al cluster con el comando:

hacf –verify /etc/VRTSvcs/conf/config

4. SERVICE GROUPS

-          Crear Service Group:

#hagrp –add <nameSG>

SystemList

Define que nodos pueden ejecutar un Service Group concreto. No indica donde se va a iniciar el SG sino que nos señala, en caso de failover , en cual nodo lo intenta levantar.

Se define un número que indica a VCS la prioridad del sistema, siendo el número más bajo el sistema que posee más prioridad como objetivo en el caso de failover del service group.

#hagrp –modify <nameSG> SystemList nodoX 0 nodoY 1…

AutoStart

Indica si el SG autoarranca automáticamente cuando VCS se inicia en algún nodo.

#hagrp –modify <nameSG> AutoStart 0 | 1

AutoStartList

Lista de los sistemas en los cuales el SG puede ser iniciado cuando VCS se arranca.

Todos los sistemas de la lista AutStartList deberán de estar incluidos en la System List.

#hagrp –modify <nameSG> AutoStartList nodoX nodoY …

AutoStartIfPartial

Este atributo de Service Group permite situar a un SG en estado “online”, a pesar de tener algún recurso “disable” deshabilitado. Por defecto, el valor es 1, osea “enabled”.

#hagrp –modify <nameSG> AutoStartIfPartial value

Parallel

Este atributo indica si el SG el paralelo o failover. Por defecto es 0, es decir, failover.

#hagrp –modify <nameSG> Parallel 1

-          OPERACIONES DE SERVICE GROUPS

Online:

Un SG se considera ONLINE cuando todos sus recursos críticos están ONLINE, y los recursos autostart son “online”.

#hagrp –online <nameSG>

Partially Online:

Un Service Group se considera “Partially Online” si alguno de los recursos no persistentes está en estado “online”, pero no todos sus recursos autostart ó críticos están online. Si un Service Group está en este estado, no se puede poner online en ningún sistema dentro del cluster.

Offline:

Cuando un SG es puesto offline todos los recursos que contiene son puestos offline empezando de arriba a abajo.

#hagrp –offline <nameSG>

Un recurso persistente no pueden ponerse offline, pero el SG se considera

OFFLINE cuando todos los recursos NO persistentes estén offline.

Switch:

Una vez comprobado que un SG funciona correctamente, hay que realizar un test de que el failover funciona.

#hagrp –switch <nameSG> -to <nododestino>

Flush:

En ocasiones los agentes de los recursos de un SG pueden llegar a colgarse, para ello es necesario reiniciar.

#hagrp –flush <nameSG> -sys <nodo>

Borrar SG:

Procedimiento para borrar un SG:

1.- Poner recursos no persistentes en offline

2.- Deshabilitar los recursos

3.- Borrar el SG

#hagrp –delete <nameSG>

Visualizar el SG:

Para visualizar los atributos de un service group.

#hagrp –display <nameSG>

5. RECURSOS:

Clasificación de recursos según OPERATIVA DEL AGENTE:

 RECURSOS No persistentes

Cuando el agente los puede poner online y offline, y por tanto pueden ser parados o arrancados por el usuarios.

En el fichero types.cf se encontrará el atributo Operations=OnOff

 RECURSOS Persistentes

VCS y el agente no son capaces de controlarlos. None: ni offline ni online (recursos hardware).

En el types.cf : Operations=None

 RECURSOS Ononly

OnOnly: el agente los levanta pero no los para.

En el types.cf : Operations=OnOnly

-          OPERACIONES CON RECURSOS:

Creación de un nuevo recurso:

#hares –add <nameRES> <nameSG>

Borrar un recurso:

#hares –delete <nameRES>

Habilitando un recurso (cambiar a ‘enable’). Un recurso debe estar habilitado (enable) para que pueda ser gestionado por el agente correspondiente. El agente, a su vez, pasará la información de la monitorización al demonio de VCS “had”. Todos los atributos necesarios deben ser definidos inicialmente antes de ponerlo “enable”.

Por defecto los recursos están deshabilitados.

#hares –modify <nameRES> enable 1

Para deshabilitar un recurso:

# hares –modify <nameRES> enable 0

Poner un recurso ‘online’

Es el estado en que un recurso puede estar en una configuración de “fail over”.

No se puede poner online el mismo recurso en nodos distintos.

#hares –online <nameRES> -sys nodoX

Poner un recurso Offline:

# hares –offline <nameRES> -sys nodoX

Crear o poner un recurso crítico

Un recurso en estado crítico, en el caso de fallar, sitúa todo el Service Group que lo contiene “offline” y provoca un fail-over del Service Group a otro sistema disponible.

#hares –modify <nameRES> Critical 0 | 1

Establecer dependencias:

Para establecer dependencias Padre-Hijo de recursos:

#hares –link <RESpadre> <REShijo>

Borrar un fallo: Limpieza de falta

Los recursos deben de limpiarse después de un fallo, antes de que puedan ponerse de nuevo “online”

#hares –clear <nameRES>

Si el recurso es persistente, se autolimpia cuando el problema que provocó el fallo se soluciona.