[ Fin de página | Página anterior | Página siguiente | Contenido | Índice ]

Funcionamiento de los nodos en un clúster

Los nodos tienen las siguientes características:
Todo nodo tiene acceso a todos los datos de la configuración de clúster.
Todo nodo se comunica con los demás nodos del clúster a través de una o más redes físicamente independientes (a veces denominadas interconexiones). Los
adaptadores de red, conocidos como interfaces de red en los clústeres de servidor, conectan los nodos a las redes.
Todos los nodos del clúster saben cuándo otro sistema se une o abandona el clúster.
Todos los nodos del clúster tienen conocimiento de los recursos que se ejecutan localmente y de los recursos que se ejecutan en los demás nodos del
clúster.
Todos los nodos del clúster están agrupados bajo un nombre común, el nombre de clúster, que se utiliza para acceder al clúster y para gestionarlo.
Cuando se inicia un nodo, éste busca nodos activos en las redes designadas para la comunicación interna. Si encuentra un nodo activo, intenta unirse al clúster del
nodo. Si no encuentra ningún clúster, intenta formar un clúster tomando control del recurso de quórum. El recurso de quórum almacena la versión más reciente de la
base de datos del clúster, que contiene la configuración del clúster y los datos de estado. Un clúster de servidor mantiene una copia coherente y actualizada de la
base de datos del clúster en todos los nodos activos.
Un nodo puede albergar unidades físicas o lógicas, denominadas recursos. Los administradores organizan estos recursos de clúster en unidades funcionales
conocidas como grupos y asignan estos grupos a nodos individuales. Si un nodo falla, el clúster de servidor transfiere los grupos alojados en el nodo a otros nodos
del clúster. Este proceso de transferencia se llama sustitución por anomalía. El proceso inverso, recuperación tras error, tiene lugar cuando el nodo con errores se
vuelve a activar y los grupos que habían sido sustituidos por anomalía se transfieren de nuevo al nodo original.

Objetos de clúster
Los nodos, los recursos y los grupos son tres tipos de objetos de clúster. Los demás son las redes, las interfaces de red y los tipos de recurso. Todos los objetos de
clúster de servidor están asociados a un conjunto de propiedades, con valores de datos que describen la identidad de un objeto y su comportamiento en el clúster.
Los administradores gestionan los objetos de clúster manipulando sus propiedades, normalmente mediante una aplicación de gestión de clústeres como el
administrador de clústeres (parte de la aplicación MSCS).

Servidores virtuales MSCS

MSCS permite colocar recursos de clúster de servidor de Tivoli Storage Manager en un servidor virtual. Un servidor virtual es un grupo de clúster MSCS parecido a un
servidor Windows. El servidor virtual tiene un nombre de red, una dirección IP, uno o más discos físicos y un servicio. Un servidor de Tivoli Storage Manager puede ser
uno de los servicios virtuales proporcionados por un servidor virtual MSCS.
El servidor virtual no depende del nombre del nodo físico en el que se ejecuta el servidor virtual. El nombre y la dirección de servidor virtual migran de un nodo a otro
con el servidor virtual. Los clientes se conectan a un servidor de Tivoli Storage Manager utilizando el nombre del servidor virtual en lugar del nombre del servidor
Windows. El nombre del servidor virtual se implementa como un recurso de nombre de red del clúster y se correlaciona con un nodo primario o de copia de seguridad.
La correlación depende de la ubicación actual del servidor virtual. Cualquier cliente que utilice WINS o servicios de directorio para localizar servidores podrá realizar
automáticamente el seguimiento del servidor virtual mientras se mueve de un nodo a otro. No es preciso modificar ni volver a configurar el cliente para realizar el
seguimiento automático del servidor virtual.
Como se ha indicado anteriormente, cada servidor virtual tiene su propio disco como parte de un grupo de recursos del clúster. Por lo tanto, no pueden compartir
datos. Cada servidor de Tivoli Storage Manager que se ha implementado como servidor virtual posee una base de datos, un registro de anotaciones de recuperación y
un conjunto de volúmenes de agrupaciones de almacenamiento en un disco separado que es propiedad de dicho servidor virtual.
Las aplicaciones del cliente detectan claramente la ubicación del servidor,lo cual facilita a Tivoli Storage Manager los procesos de sustitución por anomalía y
recuperación tras error, al tiempo que se minimiza el impacto en los clientes de Tivoli Storage Manager.
Nota:
MSCS sólo admite una dirección IP como recurso. Esto significa que cualquier servidor de Tivoli Storage Manager que se ejecute en un clúster debe limitar su
método de comunicación admitido a TCP/IP. Un cliente que no utilice TCP/IP como método de comunicación no podrá acceder al servidor virtual en caso de que
se produzca una sustitución por anomalía para el otro nodo del clúster.
En el ejemplo siguiente se muestra cómo funciona el concepto de servidor virtual.
Pongamos por caso que un servidor de Tivoli Storage Manager con clústeres denominado TSMSERVER1 se está ejecutando en el nodo A y un servidor de Tivoli
Storage Manager con clústeres denominado TSMSERVER2 se está ejecutando en el nodo B. Los clientes se conectan al servidor de Tivoli Storage Manager
TSMSERVER1 y al servidor de Tivoli Storage Manager TSMSERVER2 sin saber qué nodo alberga actualmente su servidor. El concepto de servidor virtual de MSCS
garantiza que las aplicaciones del cliente detecten claramente la ubicación de servidor. El cliente percibe que el servidor de Tivoli Storage Manager se está ejecutando
en un servidor virtual denominado TSMSERVER1.

Figura 23. Entorno de clústeres con TSMSERVER1 como nodo A y TSMSERVER2 como nodo B

converted by Web2PDFConvert.com
Cuando falla uno de los recursos de software o de hardware, se produce una sustitución por anomalía. Los recursos (por ejemplo, aplicaciones, discos o una
dirección IP) migran desde el nodo con errores al nodo restante. El nodo restante toma el control del grupo de recursos del servidor de Tivoli Storage Manager, reinicia
el servicio de Tivoli Storage Manager y proporciona acceso a los administradores y los clientes.
Si el nodo A falla, el nodo B se encarga de ejecutar TSMSERVER1. Para un cliente, es exactamente como si el nodo A se desactivara y se volviera a activar de
inmediato. Los clientes experimentan la pérdida de todas las conexiones con TSMSERVER1 y todas las transacciones activas se retrotraen al cliente. Cuando esto
ocurre, los clientes deben volver a conectarse a TSMSERVER1. El cliente detecta claramente la ubicación de TSMSERVER1.

Figura 24. Entorno de clústeres con TSMSERVER2 como nodo B y adoptando el rol de TSMSERVER1 como nodo A

Consideraciones de hardware y software

Generalmente, las siguientes consideraciones se determinan durante la fase de planificación del clúster y antes de la instalación. No obstante, dada su importancia
para el correcto funcionamiento de un clúster, conviene recordarlas aquí.
1. Decida la configuración de clústeres que necesita usar con servidores que utilicen dispositivos de disco. Cada servidor virtual necesita un conjunto separado de
recursos de disco en el subsistema de disco compartido. Por lo tanto, puede tener problemas si configura el subsistema de E/S como una gran matriz en

converted by Web2PDFConvert.com
 caso de configurar un clúster de dos servidores y después decidir ampliarlo a un clúster de cuatro servidores.
2. Identifique los recursos de disco que se asignarán a Tivoli Storage Manager. Un disco compartido no debe dividirse en varias particiones, con cada partición
asignada a una aplicación diferente y, por tanto, a un grupo de clúster diferente. Por ejemplo, puede forzarse una sustitución por anomalía en la aplicación A,
una aplicación estable, debido a un problema de software en la aplicación B si las dos aplicaciones utilizan particiones que forman parte del mismo disco
físico. Esto puede ocurrir si, por ejemplo, se produce un problema de software en la aplicación B. Este problema hará que los servicios de clúster realicen una
sustitución por anomalía en la aplicación B y en su recurso de disco necesario. Puesto que las particiones existen en la misma unidad física, también se
forzará la sustitución por anomalía en la aplicación A. Por lo tanto, se recomienda dedicar un disco compartido como un recurso único para posibles errores
junto con la aplicación IBM Tivoli Storage Manager.
3. Asegúrese de tener suficientes direcciones IP. Microsoft recomienda tener al menos siete direcciones para configurar un clúster con dos servidores virtuales de
TSM.
Cuatro direcciones IP para las tarjetas de interfaz de red (NIC). Cada nodo del clúster utiliza dos tarjetas NIC. Una tarjeta NIC maneja la comunicación
interna del clúster en la red privada de alta velocidad. La otra tarjeta NIC maneja la comunicación con la red externa y sirve de tarjeta de reserva para la
comunicación interna del clúster.
Una dirección IP para el clúster, porque constituye un servidor virtual.
Una dirección IP para cada servidor virtual de Tivoli Storage Manager.
4. Obtenga nombres de red para cada instancia de servidor de Tivoli Storage Manager en la configuración. Para un clúster con dos servidores virtuales de Tivoli
Storage Manager, se necesitan dos nombres de red, que deben estar asociados a las direcciones IP reservadas para cada servidor de Tivoli Storage Manager.
5. Cada instancia del servidor de Tivoli Storage Manager requiere un grupo de recursos del clúster. Inicialmente, el grupo debe contener solamente recursos de
disco. Puede crear un nuevo grupo y trasladar recursos de disco al grupo. Simplemente puede redenominar un grupo de recursos existentes que contenga
solamente recursos de disco.
6. Tivoli Storage Manager se instala en un disco local de cada nodo del clúster. Determine el disco que debe utilizarse en cada nodo. Se recomienda
encarecidamente utilizar la misma letra de unidad en cada máquina.
7. MSCS no proporciona la gestión de recursos de dispositivos de cinta SCSI. Sin embargo, Tivoli Storage Manager proporciona soporte para la sustitución por
anomalía de cinta que requiere un bus SCSI compartido adicional entre dos nodos en el clúster. Si decide no utilizar el soporte para la sustitución por anomalía
de cinta de Tivoli Storage Manager, puede conectar dispositivos de cinta con cualquiera de las siguientes configuraciones:
Conexión con un tercer sistema no organizado en
Conexión con un nodo en el que la instancia del servidor de Tivoli Storage Manager esté clúster en el que esté activa una instancia adicional
activa actualmente. del servidor de Tivoli Storage Manager.
Esta configuración permite operaciones de copia de seguridad y de restauración de alto Es posible que esta configuración no sea aceptable en
rendimiento. Sin embargo, estas operaciones no están totalmente automatizadas. Se necesita la instalaciones con comunicaciones de ancho de banda bajo
intervención de un operador para dar servicio a una sustitución por anomalía donde la reparación entre los servidores del clúster y el servidor que controla el
pueda prolongarse durante más de 2 días. dispositivo de cinta.
Defina un espacio de volumen de datos basado en disco suficiente superior al promedio de datos Defina un espacio de volumen de datos basado en disco
generado en 2 días. suficiente superior al promedio de datos generado en 2
días.
Configure una jerarquía de agrupaciones de almacenamiento para migrar los datos eficazmente al Utilice los volúmenes virtuales para activar la migración de
dispositivo de cinta. datos de los volúmenes de disco locales al dispositivo de
cinta.
Cuando se produzca una sustitución por anomalía, desconecte manualmente el dispositivo de Cuando se produzca una sustitución por anomalía, no es
cinta y vuelva a conectarlo al nodo en el que el servidor vuelve a estar activo. necesaria la intervención del operador; el servidor que pasa
a estar activo continúa utilizando los volúmenes virtuales
como antes.

[ Principio de página | Página anterior | Página siguiente | Contenido | Índice ]

converted by Web2PDFConvert.com