[ 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: T nodo tiene acceso a todos los datos de la configuración de clúster. odo T 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 odo adaptadores de red, conocidos como interfaces de red en los clústeres de servidor, conectan los nodos a las redes. T odos los nodos del clúster saben cuándo otro sistema se une o abandona el clúster. T odos 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. T odos 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. T odos 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

Cada servidor virtual necesita un conjunto separado de recursos de disco en el subsistema de disco compartido. los clientes deben volver a conectarse a TSMSERVER1. Decida la configuración de clústeres que necesita usar con servidores que utilicen dispositivos de disco. dada su importancia para el correcto funcionamiento de un clúster. Los recursos (por ejemplo. las siguientes consideraciones se determinan durante la fase de planificación del clúster y antes de la instalación. se produce una sustitución por anomalía. discos o una dirección IP) migran desde el nodo con errores al nodo restante.Cuando falla uno de los recursos de software o de hardware. Figura 24. Cuando esto ocurre. el nodo B se encarga de ejecutar TSMSERVER1. conviene recordarlas aquí.com . 1. El nodo restante toma el control del grupo de recursos del servidor de Tivoli Storage Manager. No obstante. Por lo tanto. Entorno de clústeres con TSMSERVER2 como nodo B y adoptando el rol de TSMSERVER1 como nodo A Consideraciones de hardware y software Generalmente. es exactamente como si el nodo A se desactivara y se volviera a activar de inmediato. reinicia el servicio de Tivoli Storage Manager y proporciona acceso a los administradores y los clientes. Para un cliente. Si el nodo A falla. El cliente detecta claramente la ubicación de TSMSERVER1. Los clientes experimentan la pérdida de todas las conexiones con TSMSERVER1 y todas las transacciones activas se retrotraen al cliente. aplicaciones. puede tener problemas si configura el subsistema de E/S como una gran matriz en converted by Web2PDFConvert.

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. Puede crear un nuevo grupo y trasladar recursos de disco al grupo. dispositivo de cinta. estas operaciones no están totalmente automatizadas. 3. Para un clúster con dos servidores virtuales de Tivoli Storage Manager. Una dirección IP para el clúster. por tanto. 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. Sin embargo. 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. 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. Cuatro direcciones IP para las tarjetas de interfaz de red (NIC). desconecte manualmente el dispositivo de Cuando se produzca una sustitución por anomalía. Un disco compartido no debe dividirse en varias particiones. 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. Microsoft recomienda tener al menos siete direcciones para configurar un clúster con dos servidores virtuales de TSM. datos de los volúmenes de disco locales al dispositivo de cinta. 2. Esto puede ocurrir si. con cada partición asignada a una aplicación diferente y. Sin embargo. el grupo debe contener solamente recursos de disco. suficiente superior al promedio de datos generado en 2 días. 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. 5. [ Principio de página | Página anterior | Página siguiente | Contenido | Índice ] converted by Web2PDFConvert. se necesitan dos nombres de red. 7. del servidor de Tivoli Storage Manager. Asegúrese de tener suficientes direcciones IP. también se forzará la sustitución por anomalía en la aplicación A. Si decide no utilizar el soporte para la sustitución por anomalía de cinta de Tivoli Storage Manager. 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. puede forzarse una sustitución por anomalía en la aplicación A. el servidor que pasa a estar activo continúa utilizando los volúmenes virtuales como antes. 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. una aplicación estable. Cada nodo del clúster utiliza dos tarjetas NIC. Puesto que las particiones existen en la misma unidad física. Se recomienda encarecidamente utilizar la misma letra de unidad en cada máquina. que deben estar asociados a las direcciones IP reservadas para cada servidor de Tivoli Storage Manager. Obtenga nombres de red para cada instancia de servidor de Tivoli Storage Manager en la configuración. se recomienda dedicar un disco compartido como un recurso único para posibles errores junto con la aplicación IBM Tivoli Storage Manager. Una dirección IP para cada servidor virtual de Tivoli Storage Manager. 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. Simplemente puede redenominar un grupo de recursos existentes que contenga solamente recursos de disco. se produce un problema de software en la aplicación B.caso de configurar un clúster de dos servidores y después decidir ampliarlo a un clúster de cuatro servidores. Inicialmente. Por lo tanto. a un grupo de clúster diferente. Cada instancia del servidor de Tivoli Storage Manager requiere un grupo de recursos del clúster. porque constituye un servidor virtual. Por ejemplo. no es cinta y vuelva a conectarlo al nodo en el que el servidor vuelve a estar activo. por ejemplo. Cuando se produzca una sustitución por anomalía. 4. Tivoli Storage Manager se instala en un disco local de cada nodo del clúster. necesaria la intervención del operador.com . Determine el disco que debe utilizarse en cada nodo. Una tarjeta NIC maneja la comunicación interna del clúster en la red privada de alta velocidad. 6. Identifique los recursos de disco que se asignarán a Tivoli Storage Manager. MSCS no proporciona la gestión de recursos de dispositivos de cinta SCSI.