Windows Server 2008 R2: Escenarios de solución de problemas en los clústeres de conmutación por error

  • Artículo

La configuración de clústeres de conmutación por error en Windows Server puede garantizar una disponibilidad prácticamente continua. Estos son algunos de los posibles escenarios de solución de problemas.

John Marlin

El mes pasado, miré algunos de los problemas más comunes con Windows Server 2008 R2 Failover Clustering y examina cómo solucionar con precisión esos problemas.

Recuerde que la política actual de asistencia es que, para que una solución Windows Server 2008 o Windows Server 2008 R2 Failover Clustering a considerar una solución oficialmente admitida por Microsoft al cliente soporte Services (CSS), debe cumplir la siguientes criterios:

  • Todos los componentes de hardware y software deben cumplir con los requisitos para recibir un logotipo "Certificado para Windows Server 2008 R2".
  • La solución totalmente configurada debe pasar la prueba de validación en la administración de clúster de conmutación por error.

Aquí hay varios escenarios que pueden ayudar a acelerar o informar a sus próximos esfuerzos para solucionar problemas. Representan algunos de los problemas más comunes en clústeres de conmutación por error compatibles Windows 2008 R2, así como los pasos que debe tomar para resolverlos.

Escenario 1: Nos estaban haciendo nuestro mensual limpieza de objetos de Active Directory y sin querer eliminar el objeto de nombre de clúster. Hemos intentado crear una nueva, pero no en línea.

El objeto de nombre de clúster (CNO) es muy importante, porque es la identidad común del clúster.

Crea automáticamente el Asistente para crear el clúster y tiene el mismo nombre que el clúster. A través de esta cuenta, crea otros objetos de equipo Virtual de Cluster (VCOs) al configurar nuevos servicios y aplicaciones en el clúster. Si elimina la CNO o permisos de lejos, no se puede crear otros objetos como lo exige el clúster hasta que se restaure o sean reintegrados los permisos correctos.

Como en todos los demás objetos en Active Directory, hay un objectGUID asociado. Se trata de cómo el clúster de conmutación por error sabe que usted está tratando con el objeto correcto. Si simplemente crea un nuevo objeto, se crea también una nueva objectGUID. Lo que tenemos que hacer es restaurar el objeto correcto para que ese clúster de conmutación por error puede continuar con sus operaciones normales.

Para solucionar esto, tenemos que saber dos cosas del recurso de clúster. Desde Windows PowerShell, ejecute el comando:

"Nombre del clúster" Get-ClusterResource | Get-ClusterParameterCreatingDC, objectGUID

Esto será recuperar los valores necesarios. El primer parámetro que queremos es la CreatingDC. Cuando el clúster de conmutación por error crea la CNO, observamos el controlador de dominio (DC) a la que fue creado. Para cualquier actividad que debemos hacer con el Cluster (crear VCOs, poner nombres en línea, etc.), sabemos que para ir a este controlador de dominio para obtener el objeto y la seguridad. Si no se encuentra en que DC o que DC no está disponible, buscamos a otros que responder, pero sabemos ir aquí primero.

El segundo parámetro es el objectGUID para asegurarse de que estamos hablando el objeto correcto. Para nuestro ejemplo, el nombre del clúster es CLUSTER1, la creación de DC es DC1 y el objectGUID es 1a3cf049cf79614ebd94670560da6f04, así:

Objeto nombre de valor
------     ----      -----
Cluster de nombre CreatingDC \\DC1.domain.com
ObjectGUID1a3cf049cf79614ebd94670560da6f04 de nombre de clúster

Tendríamos que iniciar una sesión en la máquina DC1 y ejecutar usuarios y equipos. Si hay un objeto actual de CLUSTER1, nos podemos comprobar para ver si tiene los atributos adecuados. Una nota acerca de esto es la pantalla que verá. Editor de atributo de directorio activo inicialmente no se va a mostrar el GUID que se muestran aquí, como no está mostrando en formato hexadecimal.

Lo que inicialmente te vas a ver es 49f03c1a-79cf-4e61-bd94-670560da6f04. El formato hexadecimal no un conmutador y funciona en pares, que es un poco confuso. Si tomar los primeros ocho pares de números y hacer el conmutador, 49f03c1a se convierte en 1a3cf049. Por los siguientes dos pares de conmutación, 79cf se convierte en cf79 y, a continuación, 4e61 se convierte en 614e. Los pares restantes permanecen igual.

Debe traer las propiedades de la objectGUID en el editor de atributo para ver en el formato hexadecimal que ve Failover Clustering. Porque no es el objeto correcto, debemos eliminar primero el objeto de tomar de la imagen para restaurar una adecuada.

Hay varias formas de restaurar el objeto. Podríamos utilizar una restauración de directorio activo, una utilidad como ADRESTORE o el nuevo Active Directory papelera (si se ejecuta un controlador de dominio Windows 2008 R2 con un esquema actualizado). Utilizando el nuevo Active Directory Papelera facilita mucho las cosas y es el proceso más transparente para restaurar los objetos de Active Directory eliminados.

Con la Papelera de reciclaje de directorio activo, podemos buscar para encontrar el objeto de restaurar con el comando de Windows PowerShell:

Get-ADObject –filter 'isdeleted –eq $true –and samAccountName –eq "CLUSTER1$"' –includeDelectedObjects –property * | FormatListsamAccountName,objectGUID

Ese comando se va a buscar cualquier objeto eliminado con el nombre CLUSTER1 en la Papelera de reciclaje del directorio activo. Nos dará el nombre de cuenta y objectGUID. Si hay varios elementos, se mostrará a todos. Cuando vemos el uno que queremos, nos mostraría como esto:

samAccountName : CLUSTER1$
objectGUID:49f03c1a-79cf-4e61-bd94-670560da6f04

Ahora tenemos que recuperarlo. Después de que elimina la incorrecta, sería el comando de Windows PowerShell para restaurarlo:

Restore-ADObject –identity 49f03c1a-79cf-4e61-bd94-670560da6f04

Esto restaurará el objeto en la misma ubicación (unidad organizativa o unidad organizativa) y mantener los mismos permisos y la contraseña de la cuenta de equipo conocido como Active Directory.

Esta es una de las ventajas de Active Directory Papelera en comparación con algo como una utilidad como ADRESTORE. Con ADRESTORE, deberá restablecer la contraseña, mover a la unidad organizativa adecuada, reparar el objeto en clústeres de conmutación por error y así sucesivamente.

Con la Papelera de reciclaje de directorio activo, simplemente traemos el recurso nombre de clúster. También es una opción mejor que haciendo una restauración de Active Directory, especialmente si se han producido nuevos objetos de equipo y usuario creados, si existen los antiguos que ya no existen y que tendrían que eliminarse una vez más, y así sucesivamente.

Escenario 2: Mi volúmenes compartidos de clúster mostrar "Redirigido acceso" en la administración de clúster de conmutación por error. ¿Correcto?

En primer lugar, Recapitulemos rápidamente la definición de volúmenes de clúster compartido (CSVs). CSVs simplifican la configuración y administración de máquinas virtuales Hyper-V (VMs) en clústeres de conmutación por error. Con CSV en un clúster de conmutación por error que se ejecuta de Hyper-V, múltiples máquinas virtuales pueden utilizar el mismo LUN (disco), pero una conmutación por error (o mover de nodo a nodo) de forma independiente. La CSV proporciona mayor flexibilidad para los volúmenes de almacenamiento en clúster. Por ejemplo, puede mantener archivos de sistema independiente de datos para optimizar el rendimiento de disco, incluso si los archivos del sistema y los datos están contenidos en los archivos del disco duro virtual (VHD).

En las propiedades de todos los adaptadores de red que llevan la comunicación del clúster, asegúrese de "Cliente para redes Microsoft" y "Compartir impresoras y archivos para redes Microsoft" están habilitadas para admitir el bloque de mensajes de servidor (SMB). Esto es necesario para CSV. El servidor ejecuta Windows Server 2008 R2, por lo que proporciona automáticamente la versión de SMB que requiere CSV, que es SMB2. Habrá una única red preferida de comunicación CSV, pero habilitar a esta configuración en varias redes ayuda del clúster tienen resiliencia para responder a errores.

Redirigido medios de acceso que todas las operaciones de E/s se van a "redirigir" través de la red a otro nodo que tiene acceso a la unidad. Básicamente, hay tres razones por qué es un disco en modo de acceso Redirigido:

  1. Que haya colocado manualmente en modo redirigir
  2. Hay una copia de seguridad en curso
  3. Hay problemas de hardware, y el nodo no puede acceder directamente a la unidad

En nuestro caso, hemos descartado opción 1 y opción 2. Esto nos deja con la opción 3. Si nos fijamos en el registro de sucesos, vemos el evento "ID de evento: 5121" de clústeres de conmutación por error.

Aquí es la definición de esa entrada de registro: VolumeCSV de clúster compartido ' disco de clúster x' ya no es directamente accesible desde este nodo de clúster. Acceso de I/O se redirigirá al dispositivo de almacenamiento en la red mediante el nodo que posee el volumen. Esto puede resultar en rendimiento. Si acceso redirigida se activa para este volumen, por favor desactivarlo. Si se desactiva el acceso redireccionado, por favor solucionar problemas de conectividad de este nodo para el dispositivo de almacenamiento y I/O se reanudará en buen estado, una vez que se restablece la conexión al dispositivo de almacenamiento.

Adoptar esa postura, también sería justo antes de este evento para cualquier evento relacionado con el hardware. Por lo que esperamos para eventos como 9, 11 o 15 que apuntan a un problema de hardware o de comunicación. Esperamos en administración de discos para ver si podíamos ver físicamente el disco. En la mayoría de los casos, vamos a ver algunos otros errores. Una vez que corrija el problema con el back-end, podemos introducir el disco de este modo.

Tenga en cuenta que la CSV permanecerá funcionando siempre y cuando al menos un nodo puede comunicarse con la red de almacenamiento de información conectado. Por eso, sería en un modo "redireccionado". Todas las escrituras a la unidad se envían al nodo que puede comunicarse y las máquinas virtuales Hyper-V seguirá funcionando. Puede haber un rendimiento en esas máquinas virtuales, pero siguen ejecutar. Por lo que nunca estaremos fuera de producción, que es una buena cosa.

Escenario 3: sólo he creado un nuevo Windows 2008 R2 Failover Cluster para su uso con máquinas virtuales altamente disponibles. He configurado las unidades para CSV, pero al intentar acceder a ellos, colgar Explorer y administración de discos. No puedo copiar mis discos duros virtuales a la unidad para obtener este curso.

Hay sólo un "verdadero" dueño de la unidad y se llama el nodo coordinador. Este nodo sólo se haría cualquier tipo de escrituras de metadatos en la unidad.

Cuando se abre el explorador o administración de discos, va a querer abrir la unidad por lo que puede hacer las escrituras de metadatos (si esa es la intención). Debido a esto, obtener redirigirá cualquier unidad que no tiene en la red para el nodo coordinador. Esto es diferente a la unidad en "Redirigido acceso".

Para solucionar esto, administración de clúster de conmutación por error mostrará la unidad como en línea. Primero que debe buscar para ver qué eventos se registran. En el registro de sucesos de sistema, podría ver estos eventos de Failover Clustering:

ID de evento: 5120

Volumen compartido del clúster ' disco de clúster x' ya no está disponible en este nodo de 'STATUS_BAD_NETWORK_PATH(c00000be)'. Temporalmente se pondrán en cola todas las E/s hasta que se restablece una ruta para el volumen.

ID de evento: 5142

Volumen compartido del clúster ' disco de clúster x' ya no es accesible desde este nodo de clúster debido a error 'ERROR_TIMEOUT(1460)'. Por favor, solucionar problemas de conectividad de este nodo para el dispositivo de almacenamiento y conectividad de red.

Los registros de sucesos son agotar tratando de obtener a través de la red al nodo coordinador. Así sería para ver si hay otros errores en el registro de sucesos de sistema que apuntaría a la conectividad de red entre los nodos. Si existe, debe resolverlos. Cosas como una tarjeta de red no funciona o discapacitados pueden causar esto.

A continuación, desea comprobar la conectividad de red básica entre los nodos. Lo que primero debe verificar es la red que está viajando el tráfico de la CSV. La forma de Failover Clustering elige a utilizar la red para CSV es por mayor valor métrico. Esto es diferente de cómo Windows identifica la red.

El adaptador de Failover Cluster red tolerancia (NETFT) tiene su propio sistema métrico utiliza internamente. Detecta todas las redes tienen una puerta de enlace predeterminada y se dará la métrica de 10000, 10100, como se va a lo largo. Todas las redes que no tienen un inicio de puerta de enlace predeterminada en 1000, 1100 y así sucesivamente. Uso de Windows PowerShell, puede utilizar el comando Get-ClusterNetwork | Nombre de FT, métrica, papel para ver cómo el adaptador NETFT ha definido. Algo similar a lo verá:

Nombre de métrica
-------------------
Administración 10100
CSV tráfico 1000
10000 LAN-WAN
1100 Privada

Con estas cuatro redes, la red he identificado como la CSV se llama tráfico CSV. La dirección IP que estoy usando para ello 1.1.1.1 Nodo1 y 1.1.1.2 de nodo 2, por lo que se trataría de conectividad de red básicos con PING entre las direcciones IP.

El siguiente paso es intentar una conexión SMB utilizando las direcciones IP. Esto es justo lo que Failover Clustering va a hacer. Bastará con una simple \\1.1.1.1 NET VIEW para ver si hay una respuesta. Lo que usted debe volver es una lista de acciones o un mensaje: "No hay entradas en la lista."

Esto indica que podría realizar una conexión a ese recurso compartido. Sin embargo, si aparece el mensaje "sistema error del 53. La ruta de red no se encontró,"Esto indica un problema de configuración de TCP/IP con la tarjeta de red.

Tener "Cliente para redes Microsoft" y "Y impresora compartir archivos para redes Microsoft" habilitado en la tarjeta de red deben utilizar CSV. Si no lo están, obtendrá este problema del Explorer de suspensión. Seleccione estas y eres bueno para ir.

Clúster de servidores Windows 2003 y a continuación, desactivar estas opciones fue el procedimiento recomendado. Esto ya no es el caso de ahora en adelante y se puede ver cómo puede romper.

Otros factores

Hay algunos otros factores que debe considerar. Si los nodos del clúster se producen errores de subsistema recursos de Host (RHS), primero deben pensar acerca de la naturaleza de la RHS y lo que está haciendo. RHS es el componente de clúster de conmutación por error que hace mucho de estado de los recursos una comprobación para asegurarse de que todo funciona. Para una dirección IP, garantizará la es en la pila de red y que responde. Para discos, intentará conectarse a la unidad y no un comando DIR.

Si se produce un accidente RHS, verá 1230 de ID de registro de eventos de sistema y 1146. En el caso de 1230, realmente identificará los recursos y el archivo DLL que utiliza. Si se bloquea, significa que el recurso no responde como debe y puede ser bloqueada. Si este accidente sobre un recurso de disco, es conveniente buscar errores relacionados con los discos o las latencias de disco. Un Monitor de rendimiento en ejecución sería un buen lugar para comenzar. Actualización de drivers/firmware de las tarjetas o el back-end puede ser algo a tener en cuenta también.

También va a estar haciendo a algún usuario detecciones de modo. Failover Clustering realiza vigilancia de la salud de modo de núcleo a un proceso de modo de usuario para detectar cuando se convierte en modo de usuario bloqueado o no responde. Para recuperarse de esta condición, clustering se bug-comprobar el cuadro. Si es así, se podría ver una parada 0x0000009E. Solución de problemas de esto implicaría revisar el archivo de volcado crea a buscar se bloquea. Desea ejecutar el monitor de rendimiento y buscar cualquier cosa que aparecen como colgantes, pérdidas de memoria y así sucesivamente.

Failover Clustering es dependiente de Windows Management Instrumentation (WMI). Si tiene problemas con WMI, vas a tener problemas con Failover Clustering (creación y adición de nodos, migración, etc.). Ejecutar comprobaciones de los WMI, como WBEMTEST.EXE, o secuencias de comandos WMI incluso remotas.

Una secuencia de comandos que puede intentar desde Windows PowerShell es (donde NODE1 es el nombre del nodo actual):

Get-wmiobjectmscluster_resourcegroup-equipo Nodo1 - espacio de nombres "root\mscluster"

Esto hacer una conexión WMI al clúster y proporciona información acerca de los grupos.

Si esto falla, tiene algunos problemas WMI. Los servicios WMI puede ser detenidos, puede que necesite reiniciarlos. El repositorio WMI también puede ser dañado (utilice el Windows PowerShell comando winmgmt /salvagerepository para ver si es compatible), y así sucesivamente.

Aquí hay algunos puntos de resolución de problemas para recordar:

  • Validar, validar, validar. Utilizar la validación de clúster para solucionar problemas. Utilícelo para las mejores prácticas. Utilizarlo cuando se realizan cambios en el sistema.
  • Todo está dirigida hacia Windows PowerShell. Si no sabe todavía, empezar a jugar con él.
  • Porque estamos en objetos de Active Directory, protegerse. Habilitar la Papelera de reciclaje de directorio activo y proteger objetos de eliminación accidental.
  • Al solucionar problemas de CSVs, no suponga siempre es un problema de hardware.
  • Para solucionar el problema, dar un paso atrás y mirar todo lo que pueden ser afectados. Inicie su foco de restricción.

Failover Clustering está diseñado para detectar, recuperarse y reportar problemas. El hecho de que el clúster es decirle que es o fue que un problema no significa que el clúster causado. Como algunos dicen: "No disparar el mensajero".

John Marlin

**John Marlin**es un ingeniero de soporte senior de escalamiento en el grupo de apoyo técnico comercial. Ha sido con Microsoft por más de 19 años, con los últimos 14 años, centrándose en servidores en Cluster.

Contenido relacionado