¿Por qué un controlador de dominio alentaría una reversión de USN después de un cierre impuro?


8

Tengo este controlador de dominio de Windows Server 2008 R2 ejecutándose en un servidor físico de Dell, modelo PowerEdge R510.

Hay algunos problemas eléctricos por aquí, por lo tanto, un apagón es, desafortunadamente, una ocurrencia bastante común; hay UPS, pero no son tan confiables como deberían ser, y a veces los servidores experimentarán apagados sucios.

Por alguna razón que realmente no puedo entender, a veces este DC específico surgirá después de un cierre inmundo y se encontrará con un retroceso de USN , lo que nos obligará a degradarlo y promoverlo nuevamente.

Esto no tiene ningún sentido, ya que el servidor es físico y no se ha realizado ninguna instantánea, clonación y / o restauración; Además, no se instala ningún software adicional, solo realiza tareas de CC; específicamente, no hay clonación / recuperación / cualquier software presente.

Una corrupción del sistema de archivos al menos tendría sentido, pero una reversión de USN realmente no lo hace, ya que no hay forma de que el servidor pueda volver a un estado anterior. Sin embargo, esto ha sucedido al menos tres veces en los últimos dos meses, por lo que definitivamente no fue un evento loco de una sola vez; pero soy completamente incapaz de dar una explicación.

¿Cuál podría ser la razón de este problema?


3
¿Cómo determinó exactamente que se trataba de una reversión de USN?
Mathias R. Jessen

HKLM\System\CurrentControlSet\Services\NTDS\Parameters\DSA not writable= 4
Massimo

Muy buena pregunta He estado pensando en eso por un par de horas ahora. Aún no lo se. Pero por cierto, dado que anticipa que el servidor experimentará cortes de energía con frecuencia, ¿ha confirmado que el almacenamiento en caché de escritura todavía está desactivado en todos los volúmenes? Sé que es el valor predeterminado una vez que dcpromo, pero se puede anular. Solo quiero asegurarme de que no volviste a activar el almacenamiento en caché de escritura.
Ryan Ries

Buena suposición sobre el almacenamiento en caché de escritura. Además de la memoria caché del sistema, el servidor tiene un controlador RAID de hardware, por lo que también debe verificarse. Echaré un vistazo mañana.
Massimo

Respuestas:


6

Pensé en esto por unas horas hoy. Es un poco desconcertante, pero como indiqué en mi comentario, mi mejor conjetura es que tienes algún tipo de almacenamiento en caché de disco que no se compromete en el disco antes de que el corte de energía / apagado sucio haya borrado el contenido del caché ... O, dado que está ejecutando un volumen RAID que contiene ntds.dit, el corte de energía podría estar causando que su volumen RAID se rompa temporalmente o se vuelva incoherente, aunque sea por un momento.

Sabemos que la línea de partido en las reversiones de USN es cuando un DC se restaura a un estado como era antes, el ejemplo clásico es restaurar un DC virtualizado desde una instantánea. Sé que eso no se aplica exactamente a usted ... pero incluso en el caso de un disco con un caché de escritura, puede pensar que los datos que están físicamente en el disco contienen un "estado anterior", mientras que el caché de escritura es lo que realmente contiene el estado más actualizado de DC ... incluso si los dos estados están separados por medio segundo.

Reflexione sobre estos comentarios de Microsoft:

Pautas para controladores de dominio virtualizados

Los discos SCSI virtuales proporcionan un mayor rendimiento en comparación con el IDE virtual y admiten el acceso a unidades forzadas (FUA). FUA garantiza que el sistema operativo escriba y lea datos directamente desde los medios sin pasar por ninguno de los mecanismos de almacenamiento en caché.

Sé que su DC no es una VM, pero el concepto aún se aplica. El almacenamiento en caché de disco y los DC no se mezclan. Es por eso que la instalación de Active Directory desactiva el almacenamiento en caché de escritura como una política de Windows, pero aún puede tener mecanismos de almacenamiento en caché en su controlador RAID de hardware, etc.

Escenario B: iniciar Active Directory desde otras unidades en un espejo roto

  1. Promocionar un controlador de dominio. Localice el archivo Ntds.dit en una unidad reflejada.

  2. Rompe el espejo.

  3. Continúe replicando entrante y replicando saliente utilizando el archivo Ntds.dit en la primera unidad en el espejo.

  4. Inicie el controlador de dominio utilizando el archivo Ntds.dit en la segunda unidad en el espejo.

Eso es un asesino de replicación que me ha mordido mucho en DC físicos con volúmenes RAID 1. Nunca tuve personalmente una reversión real de USN causada por él, pero matará la replicación en ese DC. Quiero decir, imagina un volumen RAID 1 de 2 discos. 1 unidad muere. Lo eliminas, introduces una nueva unidad ... aaaaaa y DSA no se puede escribir.

Del blog AskDS :

Si no tiene fuentes de alimentación ininterrumpida (UPS) para sus hosts VM o el disco de almacenamiento donde reside la base de datos del directorio activo, asegúrese de que el almacenamiento en caché de escritura esté desactivado en la computadora host de la máquina virtual. Consulte este enlace para obtener orientación adicional. Por el contrario, si el almacenamiento en caché de escritura debe permanecer habilitado para el host de VM que aloja el DC, entonces instale un UPS para evitar daños en el DC (s).

Nuevamente, se trata de DC virtualizados, pero el concepto de almacenamiento en caché de disco se aplica también a los DC físicos.

Entonces ahí está mi idea. Creo que tiene algo que ver con su sistema de almacenamiento. Definitivamente desea deshabilitar cualquiera y todos los mecanismos de almacenamiento en caché al menos en el volumen ntds.dit, especialmente si es propenso a cortes de energía.


2
Exactamente mis pensamientos. Escribir caché en el adaptador de matriz, pero no con batería Apostaría 0.05 GBP en él :-)
Simon Catlin

1
De hecho, el caché de escritura estaba habilitado en el controlador RAID y el sistema operativo no pudo deshabilitarlo automáticamente; Lo he desactivado manualmente y espero que esto haya solucionado el problema de una vez por todas. Esta configuración fue muy probablemente su causa raíz.
Massimo

¡Agradable! ¡Eso debería detenerte hasta que puedas mejorar UPS! ;)
Ryan Ries

Confirmado: el problema nunca volvió a ocurrir después de que la memoria caché de escritura (no respaldada por batería) se deshabilitó en el controlador de disco físico.
Massimo

@ Massimo Me encanta que hayas vuelto para confirmar esto después de 4 años. :)
Ryan Ries
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.