Consulta con el equipo de Windows : Cluster

Cmdlets útiles para Failover Cluster 2008 R2

esplat — Tue, 27 Oct 2009 20:59:00 GMT

Hace ya algún tiempo que Power Shell nos abrió paso a un modo más sencillo y potente de hacer las cosas. En esta ocasión me acerco a vosotros para mostraros otro modo de administrar clúster fuera de la consola y los comandos propios proporcionados por clúster.

La lista completa podéis encontrarla en la siguiente URL:

Failover Cluster Cmdlets in Windows PowerShell

A continuación os muestro algunos ejemplos:

Listado de la propiedades del Clúster

C:\> Get-Cluster | FL *

Donde FL es el alias de Format-List

Crear un servidor de ficheros

C:\> Add-ClusterFileServerRole –Storage “Cluster Disk 3” –Name Win2008R2FS1 – StaticAddress 192.168.1.100

Exportar a texto el log de Clúster

C:\> Get-ClusterLog –Cluster Win2008R2Cluster –Node nodo1 –Destination C:\Logs

Paloma García Martín

Actualización de los videos paso a paso de Hyper-V Live Migration Tool para la versión RC

esplat — Wed, 27 May 2009 11:23:00 GMT

Hola a tod@s,

A nivel mundial se esta levantando una gran expectación alrededor de esta herramienta que permite, el paso de maquinas virtuales entre nodos de un clúster, de forma transparente para el usuario final, y sin afectar al servicio.

Se publico una serie de de videos con los paso a paso para la versión Beta del producto por parte de mi compañero Giovanni Marchetti, la cual podeis revisar desde:

Con la llegada de la RC de la herramienta Hyper-V Live Migration ha actualizado el primer video publicada en Technet en la cual explica paso a paso el manejo de la herramienta. Teniendo previsto ir actualizando el resto de los videos en breve.

Podéis acceder a la actualización del primer video desde update , en el se explican las mejoras incluidas en este versión RC para R2.

Lo podéis revisar junto con al documentación sobre el producto publicada en Technet aqui.

Saludos.

Raúl del Moral

Técnico de Soporte Premier

Replicación de drivers de impresora en un clúster Windows 2003

esplat — Wed, 04 Feb 2009 18:42:06 GMT

Replicación de drivers de impresora en un clúster Windows 2003

En Windows Server 2003, los drivers de impresora en un servidor de impresión en clúster son almacenados en un disco compartido y replicados a todos los nodos del clúster. Los drivers son guardados en un directorio bajo el raíz del disco compartido del cual el servicio spooler o cola de impresión depende, llamado PrinterDrivers

Nota Este nombre de carpeta no podrá ser cambiado aunque haya una propiedad privada de recurso que de pie a ello.

Cuando un driver de impresora es actualizado, es establecido el valor TimeStamp en el registro al sello de fecha y hora incluidas en el driver. Cuando el recurso spooler o cola de impresión su estado pasa a Online, él comprueba este valor bajo la siguiente rama del registro:

HKLM\Cluster\Resources\%GUID%\Parameters\Environments\Windows NT x86\Drivers\Version-3\%DriverName%\TimeStamp

Y lo compara con el valor:

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Print\Cluster\%GUID%\Windows NT x86\Version-3\%DriverName%\TimeStamp

Nota %GUID% corresponde al identificador en el registro del recurso spooler o cola de impresión

Si él encuentra que la versión bajo la primera rama es mas nuevo que el de la segunda, el driver actualizado es descargado desde el disco compartido al disco del sistema operativo del nodo.

Se comprueba driver por driver, y si hay alguna diferencia de versión, son descargados desde la carpeta o directorio \PrinterDrivers del disco compartido a la siguiente ruta local del nodo %SystemRoot%\System32\Spool\ResourceGUID\Drivers, donde ResourceGUID es el identificador único global (GUID) que representa al recurso spooler o cola de impresión. Estos drivers son mantenidos aparte de cualquier driver instalado en el nodo o de otro recurso spooler en configuraciones activo/activo.

Imagen 1: Directorio con el GUID del recurso spooler

En un servidor de impresión no en clúster, los drivers para cada sistema operativo son almacenados en directorios diferentes. Una simple impresora puede tener diferentes drivers cargados y cada uno de estos está almacenado en una carpeta diferente bajo Drivers. El Cluster mantiene las mismas convenciones en la separación de drivers bajo cada carpeta GUID de cada recurso de spooler o cola de impresión.

La replicación de todos los drivers puede incrementar el tiempo que a un recurso spooler o cola de impresión pasar su estado a online, porque cuando un driver es actualizado, el spooler debe comprobar la lista de todas las impresoras pare ver cuáles son las impresoras afectadas (y ver si usa algún archivo actualizado) y si así fuera, decir a la impresora que actualice su información de driver. No se pasara el estado del recurso spooler o cola de impresión a Online hasta que esta comprobación y actualización este completa. Este retraso no afectara a otros nodos hasta que el recurso spooler se ponga online por primera vez en ellos. Cuando tu agregas un gran número de colas de impresión y drivers de una vez, es altamente recomendado que después de haberlas añadido, muevas el recurso spooler o cola de impresión a cada uno de los nodos en el clúster. Esto necesita ser hecho solo una vez, y cuando el recurso es puesto online ocurrirá la replicación de los driver. Esto asegura que todos los nodos tienen los drivers más actuales. El tiempo de failover será menor después que la que mayoría de los drivers estén replicados para las siguientes impresoras que añadas.

El spooler y otras aplicaciones no deberían copiar drivers de impresora directamente al disco compartido, porque si se produjese un failover el proceso de carga de drivers obtendría un error de E/S. Esto es el por qué los drivers son descargados y mantenidos en cada uno de los nodos localmente. Cuando se accede a un driver, se usa rutas UNC (\\%VirtualServer%\print$\%GUID%) en vez de la ruta local al driver (%SystemRoot%\System32\spool\Driver).

El sitio de Windows Update es seguro usarlo en los clúster. Si es usado el actualizara los drivers en el nodo local y también en los servidores virtuales, pero para poder hacerlo el recurso spooler debe estar online en el nodo donde se está usando Windows Update.

A la hora de borrar un recurso cuando un nodo está offline, la próxima vez que el nodo este online borrara la carpeta GUID del nodo local.

Cuando borras un recurso spooler, ocurren dos cosas:

La carpeta GUID es borrada del nodo local (o marcada para borrar en el reinicio si los archivos de un driver están en uso).
La carpeta PrinterDrivers es borrada del disco compartido.

El resto de los nodos (sin hacer caso si están online u offline) llevaran a cabo una limpieza cuando el Servicio de clúster inicie (ya que había una marca para borrado porque los archivos del driver estaban en uso). Esto es debido a cuando un recurso es borrado el servicio de clúster solo notifica a la DLL de recursos en el nodo donde el recurso está siendo borrado.

Una cosa a tener en cuenta a la par de la replicación de los drivers entre los discos compartidos y los nodos es la información que se pasan los nodos a través de la rama CLUSTER del registro. A veces debemos ser cuidadosos a la hora de agregar muchas impresoras y tenemos configurado un reseteo del log de quórum cada pocos KB. En un movimiento o failover puede perderse información relacionada con colas de impresión si es muy bajo el valor.

Para incrementarlo sigue estos pasos:

Abrir la consola de administración de clúster (CluAdmin.exe).
Clic con el botón derecho sobre el nombre de clúster en la parte superior izquierda, y luego Propiedades.
Clic en el tabulador de Quorum.
En la caja Reset quorum log at, teclear un valor mayor que el tamaño del archive CLUSDB en el carpeta \windows\cluster.

Nota Introducir un valor múltiplo de 64. Por ejemplo, 5120 o 8192.

Nota Este valor es global y solo necesita cambiarse en un nodo. El servicio de clúster llevara este cambio al resto de nodos y el cambio es dinámico no es necesario reiniciar el servicio de clúster.

Troubleshooting (solucionando problemas)

Directorio o carpeta del driver corrupta

Cuando una carpeta de un driver esta corrupta, cualquier impresora cuyo driver este corrupto no imprimirá. Puedes encontrar en alguna situación que una impresora en un nodo puede imprimir correctamente, pero desde otro nodo por la misma impresora no es posible. Esto puede ser debido a un driver corrupto o faltan archivos del driver en el nodo. Para corregir esto tú puedes manualmente forzar el borrado de todos los drivers del nodo y luego llevar a cabo una replicación completa desde el nodo que no tiene problemas.

Ya que el Servicio de clúster comprueba si las versiones coinciden en el failover, sería raro que en un failover el recurso spooler no propagara los drivers correctos al otro nodo..

Si la carpeta GUID en uno de los nodos esta corrupta puedes hacer una de estas cosas:

Restaurarla de un backup
Quitar y volver añadir el nodo problemático de la lista de la caja Possible Owners para recrear los drivers.

Con esta última opción el servicio de clúster copiara los drivers del disco compartido al disco local del nodo:

Abrir el administrador de cluster, y mover el grupo que contiene el spooler al nodo que sospechamos que no tiene los drivers corruptos.
Clic con el botón derecho en el recurso del spooler o cola de impression y luego Take Offline.
Doble clic en el recurso Spooler, y luego clic en Modify bajo Possible Owners.
Mover el nodo que sospechas que tiene el problema a la lista Available Nodes, y luego clic en OK.
Clic en Apply.
Clic en Modify bajo Possible Owners, y luego mueve de vuelta el nodo problemático a la lista Possible Owners.
Clic en OK, y luego clic en OK.
Mover el grupo que contine el recurso spooler al nodo problematico.
Clic con el derecho sobre el recurso Spooler, y luego en Bring Online.

Esto causara que el recurso Spooler recree los drivers en el nodo local. Los driver viejos pueden ser movidos dentro de una carpeta llamada old dependiendo si pueden ser borrados o no. Si los driver en el nodo problemático todavía parecen estar corruptos, reinicia el nodo después de que lo hayas quitado de Possible Owners. Cuando tú hagas esto, cualquier driver que tuvieran handles abiertos serán cerrados. Normalmente este paso no es necesario.

Nosotros recomendamos que uses drivers de nivel 3 en pro de la estabilidad del clúster. Evita los de nivel 2 o de modo núcleo. Ellos pueden causar un stop e inestabilidad en el sistema.

Carpeta PrinterDrivers esta corrupta o le faltan archivos

Si por cualquier razón, la carpeta \PrinterDrivers en el disco compartido se pierde o la información que contiene se daña o se borra, tu puedes usar uno de los siguientes métodos para recuperarla:

· Restaurar de un backup.

· Copiar desde la carpeta %SystemRoot%\System32\Spool\SpoolerResource GUID a %SharedSpoolerDisk% y renombrar SpoolerResource GUID a PrinterDrivers.

· Reinstalar las impresoras (la carpeta PrinterDrivers es recreada cuando un driver es instalado).

Failover clustering Windows 2008 – registro

esplat — Mon, 02 Feb 2009 18:32:00 GMT

Como ya hemos hablado otras veces, con 2008 se he realizado un rediseño del antiguo clúster MSCS que utilizábamos en versiones anteriores de Windows.

De entre todos los cambios introducidos hoy nos centraremos en el registro.

HKLM\Cluster

También conocida como “Cluster hive”, continua siendo la clave principal dentro del registro, almacenando información sobre la configuración del clúster. Residente en todos los nodos del clúster es también replicada al disco de witness en caso de haberse definido.

Las claves modificadas son:

HKLM\Cluster

HKLM\Cluster\Checkpoints

HKLM\Cluster\Dependencies

HKLM\Cluster\Groups

HKLM\Cluster\Networks

HKLM\Cluster\Nodes

HKLM\Cluster\Quorum

HKLM\Cluster\ResourceTypes

HKLM\System\CCS\Services\clusdisk

HKLM\System\CCS\Services\ClusSvc

HKLM\System\CCS\Services\Netft

A continuación adjunto el acceso al documento con toda la información, pantallazos y ejemplos de configuración.

Espero que os resulte de utilidad.

Un saludo, Paloma García

Técnico de Soporte Microsoft Premier

Documentación sobre Hyper-V y Servicio de Cluster para sistemas de alta disponibildad

esplat — Wed, 21 Jan 2009 15:55:39 GMT

Hola a todos,

Hace algunos días se publicaron una serie de guías sobre Hyper-V y Servicios de Cluster en Technet.

Para todos los interesados en testar e implantar esta tecnología resultaran de gran utilidad y los reunimos todos en este post para que sean mas fáciles de localizar.

· Design for a Failover Cluster in Which All Nodes Run Hyper-V http://go.microsoft.com/fwlink/?LinkId=129117

· Requirements and Recommendations for Failover Clusters in Which All Nodes Run Hyper-V

http://go.microsoft.com/fwlink/?LinkId=129110

· Checklist: Failover Cluster in Which the Servers Run Hyper-V

http://go.microsoft.com/fwlink/?LinkId=129123

Step by-Step Guide: Hyper-V and Failover Clustering

http://go.microsoft.com/fwlink/?LinkId=129063

Configure a Virtual Machine for High Availability

http://go.microsoft.com/fwlink/?LinkId=131363

Un saludo.

Raúl del Moral.

Técnico de Soporte Premier

Cómo presentar nuevos discos en un cluster

esplat — Wed, 19 Nov 2008 20:05:22 GMT

Desde el equipo de soporte nos hemos encontrado con diversos casos en los que se añaden nuevos discos a un cluster. Dichos discos se inicializan y formatean desde el Disk Manager del nodo 1 (pongamos un entorno cluster de dos nodos). Cuando se intentan ver esos discos desde el Disk Manager del nodo 2 vuelven a aparecer como no inicializados.

Esto ocurre normalmente al presentar los discos con todos los nodos del cluster levantados. Al estar levantado el servicio de cluster el driver clusdisk, que es quien se encarga de proteger los discos en un cluster, tiene el control del sistema de discos no permitiendo añadir correctamente los nuevos discos.

La forma adecuada de añadir nuevos discos en cualquiera de las versiones de Microsoft Cluster Service (MSCS) es la siguiente:

1. Hacer un failover de todos los recursos a un solo nodo

2. Apagar todos los nodos menos el que tiene los recursos

3. Deshabilitar el servicio de cluster poniendo el arranque del servicio de cluster como Manual

4. Deshabilitar el driver cluster disk:

a. Abrir Device Manager

b. En el menú Ver, seleccionar ‘mostrar dispositivos ocultos’

c. Expandir la rama Non-Plug and Play Drivers, botón derecho sobre Cluster Disk Driver, propiedades, pestaña Driver y seleccionar Deshabilitado

5. Cerramos todas las ventanas y reiniciamos el nodo

6. Añadir los nuevos discos, inicializarlos, formatearlos y seleccionar las unidades

7. Habilitar de nuevo el clusdisk

8. Poner el servicio de cluster en automático

9. Apagar el nodo

10. Para asegurarnos que los discos tienen la misma letra en todos los nodos (recomendable por temas administrativos), arrancar el otro nodo y repetir los pasos del 3 al 9 (no habrá que formatear otra vez el disco; Para agilizar, se puede deshabilitar tanto el servicio de cluster como el clusdisk antes de apagar el nodo en el paso 2).

11. Arrancar el nodo 1

12. Una vez arrancado, arrancar el nodo 2

Hay artículos interesantes de la Knowledge Base que se pueden consultar:

890549 You cannot format a shared cluster hard disk volume, and you receive "The format did not complete successfully" error message in Windows Server 2003

http://support.microsoft.com/default.aspx?scid=kb;EN-US;890549

257937 HOW TO: Format an Existing Partition on a Shared Cluster Hard Disk

http://support.microsoft.com/default.aspx?scid=kb;EN-US;257937

929275 A new disk resource from a SAN or from an iSCSI storage device does not appear in the Disk list on a Windows Server 2003-based server cluster

http://support.microsoft.com/default.aspx?scid=kb;EN-US;929275

Si tenéis cualquier problema a la hora de realizar este procedimiento, desde soporte siempre estaremos encantados de ayudaros.

Un saludo,

Rafael Basterra Careaga
Platforms Support Engineer

Problemas de cluster: Cambio de firmas de disco

esplat — Wed, 03 Sep 2008 13:45:02 GMT

Este post pretende ser el primero de una serie de post sobre los problemas más habituales que observamos día a día los ingenieros de soporte de cluster, el primero de ellos estará centrado en el cambio de firmas de los discos de cluster.

El servicio de cluster reconoce e identifica los discos por su firma. Las firmas de los discos están almacenadas en el disco físico en el Master Boot Record (MBR). El MBR es un registro que utiliza el servicio de cluster para mantener todos los discos que administra, es decir utiliza el MBR para realizar un seguimiento de los discos.

Durante el transcurso de las operaciones del servicio de cluster (arranque, reinicio, failover…), si el servicio de cluster no puede encontrar un disco que está identificado con una firma en concreto, no podrá poner online el disco.

El componente de cluster que específicamente detecta esta condición y añade el error en el cluster.log es el cluster disk filter driver (clusdisk.sys).

En la imagen de abajo se puede ver un ejemplo de la firma de un disco en el MBR.

La firma del disco en el MBR está en formato Little endien, con lo que los bytes esta al revés con lo que la firma que aparece en la imagen en la rama de registro de cluster estará como 0XA3D9A3D9.

El primer paso para en el troubleshooting de firmas de discos en cluster es verificar si la firma del disco ha cambiado.

Como determina si la firma del disco ha cambiado

Síntomas

· El servicio de cluster no arranca en ninguno de los nodos.

· El servicio de cluster arranca pero algún disco no se pone online.

Comprobaciones rápidas

Los siguientes pasos pueden facilitar una rápida evaluación para detectar si los fallos de disco se deben a un cambio de firmas. Si las firmas cambian clusdisk.sys las ignorara permitiendo al sistema operativo montar el disco.

1. Revisa el visor de eventos en busca del siguiente evento

Identificador de sucesos: 1034
Origen: ClusDisk
Descripción: No se pudo encontrar el disco asociado a recurso de disco de clúster <DriveLetter>. La firma esperada del disco fue <DiskSignature>.

2. Si el evento anterior no está en el visor de sucesos continuar al paso 3 y si esta pasar a la sección “como arreglar firmas de discos que han cambiado”

3. Navegar por el Explorer y verificar si alguno de los discos compartidos que fallen aparecen listados.

4. En caso de que aparezcan intentar acceder a ellos.

5. Crear una carpeta en el disco compartido.

6. Cierra el explorer, reábrelo, conecta con la unidad y verifica que la carpeta sigue presente.

7. Si la carpeta aun está presente en el disco verifica el clusdisk.sys está cargado y ejecutándose

a. Botón derecho en MI PC selecciona administrar.

b. Selecciona administrador de dispositivos.

c. En el menú ver del administrador de dispositivos selecciona Mostrar dispositivos ocultos.

d. En la parte derecha del administrador de dispositivos, despliega dispositivos que no son plug and play

e. Doble clic en Cluster Disk Driver para abrir la ventana de propiedades

f. En la pestaña de general verificar que Utilizar este dispositivo está habilitado, si no habilítalo

g. En la pestaña Driver verifica que el tipo de arranque sea Sistema, si no selecciona system verifica que el estado sea Arrancado

h. Si el driver de disco de cluster ha sido deshabilitado o el tipo de arranque esta en manual y no esta ejecutándose configúralo de manera correcta y reinicia el nodo y verifica que el servicio de cluster este arrancado, si no está arrancado y aun puedes acceder a los discos a través del Explorer continua con el siguiente paso

8. SI los disco son accesible verifica que si ambos nodos del cluster están arrancados, si lo están apagad uno de ellos para reducir la posibilidad de corrupción de datos antes de reparar las firmas.

Como reparar las firmas que han cambiado

Cuando un recurso de disco físico es creado, la firma del disco es almacenada en el GUID del recurso en la subclave Parameters en el hive de cluster

Las siguientes imágenes muestran el GUID de un recurso de disco físico de un disco de Quorum y la subclave de parameters donde esta almacenada la firma,

Para reemplazar las firmas hay 2 herramientas:

Cluster recovery tool

1. Añade de nuevo el disco en el administrador de cluster

2. Utiliza la herramienta cluster recovery la cual reconstruirá las dependencias del disco y asignara a la nueva unidad la letra correspondiente.

3. Borra el recurso de disco fallido

Dumpcfg.exe

1. Utiliza dumpcfg.exe para reemplazar la firma del disco siguiendo los pasos de el siguiente articulo 280425 Recovering from an Event ID 1034 on a Server Cluster.

Juan Bautista Arlandis

Tecnico de Soporte Microsoft Premier.

W2k8 Days Novedades en la tecnología Clúster NLB

esplat — Tue, 03 Jun 2008 16:12:00 GMT

Hola a tod@s,

Hoy publicamos la presentación que realizo nuestro compañero de soporte Eduardo Díez respecto a las novedades incluidas en el servicio de Clúster NLB y sus opciones de configuración y administración.

Espero que a los administradores tanto de la parte servidora como de la red os resulte interesante y de utilidad en las tareas diarias.

Saludos.

W2k8 Days Novedades en la administración de Clúster

esplat — Fri, 30 May 2008 10:36:00 GMT

Hola de nuevo,

Hoy vamos a publicar la presentación realizada por nuestra compañera Paloma Garcia Martin sobre las novedades que presenta Windows 2008 en cuanto a la administración de Clúster.

Esperamos que esta os resulte de utilidad para poder administrar con mas facilidad estas funcionalidades añadidas o modificadas en esta nueva versión.

Un saludo a tod@s.