Perché un controller di dominio dovrebbe riscontrare un rollback USN dopo un arresto impuro?


8

Ho questo controller di dominio Windows Server 2008 R2 in esecuzione su un server Dell fisico, modello PowerEdge R510.

Ci sono alcuni problemi elettrici qui intorno, quindi un black-out è, purtroppo, un evento abbastanza comune; ci sono UPS, ma non sono così affidabili come dovrebbero essere e talvolta i server subiranno arresti impuri.

Per qualche ragione non riesco davvero a capire, a volte questo DC specifico si presenterà dopo uno spegnimento impuro e incontrerà un rollback USN , costringendoci a retrocedere e promuoverlo.

Ciò non ha alcun senso, poiché il server è fisico e non è mai stata eseguita alcuna istantanea, clonazione e / o ripristino; inoltre, non è installato alcun software aggiuntivo, esegue solo compiti DC; in particolare, nessuna clonazione / recupero / qualunque software sia presente.

Un danneggiamento del filesystem avrebbe almeno un senso, ma un rollback USN in realtà non lo è, poiché non è possibile riportare il server a uno stato precedente. Tuttavia, questo è successo almeno tre volte negli ultimi due mesi, quindi non è stato sicuramente un evento pazzo di una volta; ma non sono del tutto in grado di trovare una spiegazione.

Quale potrebbe essere la ragione di questo problema?


3
Come hai determinato esattamente che si trattava in realtà di un rollback USN?
Mathias R. Jessen,

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

Ottima domanda Ci sto pensando da un paio d'ore. Ancora non lo so. Ma per inciso, poiché prevedete che il server subisca frequentemente interruzioni di corrente, avete confermato che la memorizzazione nella cache di scrittura è ancora disattivata su tutti i volumi? So che è l'impostazione predefinita una volta che hai dcpromo, ma può essere ignorato. Voglio solo assicurarmi di non aver riattivato la cache di scrittura.
Ryan Ries,

Buona ipotesi sulla scrittura nella cache. Oltre alla cache di sistema, il server ha un controller RAID hardware, quindi anche questo dovrebbe essere verificato. Daro 'un'occhiata domani.
Massimo

Risposte:


6

Ci ho pensato per qualche ora oggi. È un po 'sconcertante, ma come ho indicato nel mio commento, la mia ipotesi migliore è che tu abbia una sorta di cache su disco in corso che non viene impegnata su disco prima che l'interruzione di corrente / spegnimento sporco abbia cancellato il contenuto della cache ... Oppure, poiché si sta eseguendo un volume RAID che ospita ntds.dit, l'interruzione dell'alimentazione potrebbe causare l'interruzione temporanea o l'incoerenza del volume RAID, anche se per un momento.

Sappiamo che la linea del partito sui rollback USN è quando un controller di dominio viene ripristinato a uno stato come era in precedenza, l'esempio classico è il ripristino di un controller di dominio virtualizzato da un'istantanea. So che non si applica esattamente a te ... ma anche nel caso di un disco con una cache di scrittura, puoi pensare ai dati che si trovano fisicamente sul disco come contenenti uno "stato precedente" mentre la cache di scrittura è ciò che in realtà contiene lo stato più aggiornato della DC ... anche se i due stati sono distanti solo mezzo secondo.

Ruminare su questi commenti da Microsoft:

Linee guida per controller di dominio virtualizzati

I dischi SCSI virtuali offrono prestazioni migliori rispetto all'IDE virtuale e supportano l'accesso forzato all'unità (FUA). FUA garantisce che il sistema operativo scriva e legge i dati direttamente dal supporto ignorando qualsiasi meccanismo di memorizzazione nella cache.

So che il tuo controller di dominio non è una macchina virtuale, ma il concetto è ancora valido. La memorizzazione nella cache del disco e i controller di dominio non si mescolano. Questo è il motivo per cui l'installazione di Active Directory disattiva la cache di scrittura come criterio di Windows, ma è ancora possibile avere meccanismi di cache nel controller RAID hardware, ecc.

Scenario B: avvio di Active Directory da altre unità in un mirror rotto

  1. Promuovi un controller di dominio. Individua il file Ntds.dit su un'unità con mirroring.

  2. Rompi lo specchio.

  3. Continuare a replicare in entrata e replicare in uscita utilizzando il file Ntds.dit sulla prima unità nel mirror.

  4. Avviare il controller di dominio utilizzando il file Ntds.dit sulla seconda unità nel mirror.

Questo è un killer di replica che mi ha morso molto su controller di dominio fisici con volumi RAID 1. Personalmente non ho mai avuto un vero rollback USN causato da esso, ma ucciderà la replica su quel controller di dominio. Voglio dire, immagina un volume RAID 1 di 2 dischi. 1 unità muore. Lo rimuovi, pop in una nuova unità ... aaaaaae DSA Not Writable.

Dal blog AskDS :

Se non si dispone di gruppi di continuità (UPS) per gli host di macchine virtuali o per il disco di archiviazione in cui risiede il database di Active Directory, assicurarsi che la memorizzazione nella cache di scrittura sia disabilitata sul computer host della macchina virtuale. Si prega di fare riferimento a questo link per ulteriori indicazioni. Al contrario, se la memorizzazione nella cache di scrittura deve rimanere abilitata per l'host di macchine virtuali che ospita il controller di dominio, installare un UPS per evitare danni ai controller di dominio.

Ancora una volta, si parla di controller di dominio virtualizzati, ma il concetto di memorizzazione nella cache del disco si applica anche ai controller di dominio fisici.

Quindi c'è la mia idea. Penso che abbia qualcosa a che fare con il tuo sistema di archiviazione. Sicuramente vuoi disabilitare tutti i meccanismi di memorizzazione nella cache almeno sul volume ntds.dit, specialmente se sei soggetto a interruzioni di corrente.


2
Esattamente i miei pensieri. Scrivi cache sull'adattatore di array, ma non alimentato a batteria. Ci scommetterei 0,05 GBP su questo :-)
Simon Catlin l'

1
La cache di scrittura era infatti abilitata sul controller RAID e il sistema operativo non era in grado di disabilitarla automaticamente; L'ho disabilitato manualmente e spero che questo abbia risolto il problema una volta per tutte. Questa configurazione è stata molto probabilmente la sua causa principale.
Massimo

Bello! Ciò dovrebbe trattenerti fino a quando non potrai UPS migliore! ;)
Ryan Ries,

Confermato: il problema non si è più verificato dopo che la cache di scrittura (non supportata da batteria) è stata disabilitata sul controller del disco fisico.
Massimo,

@Massimo Adoro che tu sia tornato per confermarlo dopo 4 anni. :)
Ryan Ries il
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.