Pourquoi un contrôleur de domaine encouterait-il un rollback USN après un arrêt impur?

J'ai ce contrôleur de domaine Windows Server 2008 R2 exécuté sur un serveur Dell physique, modèle PowerEdge R510.

Il y a quelques problèmes électriques ici, donc une panne d'électricité est malheureusement assez courante; il existe des onduleurs, mais ils ne sont pas aussi fiables qu'ils le devraient, et parfois les serveurs subiront des arrêts impurs.

Pour une raison que je ne peux vraiment pas comprendre, parfois ce contrôleur de domaine spécifique apparaîtra après un arrêt impur et rencontrera un retour en arrière de l'USN , nous obligeant à rétrograder et à le promouvoir à nouveau.

Cela n'a aucun sens, car le serveur est un serveur physique et aucun instantané, clonage et / ou restauration n'a jamais été effectué sur celui-ci; en outre, aucun logiciel supplémentaire n'est installé dessus, il n'effectue que des tâches DC; en particulier, aucun logiciel de clonage / récupération / quel qu'il soit n'est présent.

Une corruption du système de fichiers aurait au moins un certain sens, mais pas vraiment une restauration USN, car il n'y a aucun moyen de ramener le serveur à un état précédent. Cependant, cela s'est produit au moins trois fois au cours des deux derniers mois, donc ce n'était certainement pas un événement fou unique; mais je suis complètement incapable de trouver une explication.

Quelle pourrait être la raison de ce problème?

J'ai réfléchi à cela pendant quelques heures aujourd'hui. C'est un peu perplexe, mais comme je l'ai indiqué dans mon commentaire, ma meilleure supposition est que vous avez une sorte de mise en cache du disque en cours qui n'est pas validée sur le disque avant que la panne de courant / l'arrêt sale n'efface le contenu du cache ... Ou, étant donné que vous utilisez un volume RAID hébergeant ntds.dit, la panne de courant peut provoquer une interruption ou une incohérence temporaire de votre volume RAID, ne serait-ce qu'un instant.

Nous savons que la ligne de parti sur les restaurations USN se produit lorsqu'un contrôleur de domaine est restauré dans un état tel qu'il était auparavant, l'exemple classique étant la restauration d'un contrôleur de domaine virtualisé à partir d'un instantané. Je sais que cela ne s'applique pas exactement à vous ... mais même dans le cas d'un disque avec un cache d'écriture, vous pouvez penser que les données qui se trouvent physiquement sur le disque contiennent un "état précédent", tandis que le cache d'écriture est ce qui contient en fait l'état le plus à jour du DC ... même si les deux états ne sont séparés que par une demi-seconde.

Ruminate sur ces commentaires de Microsoft:

Instructions pour les contrôleurs de domaine virtualisés

Les disques SCSI virtuels offrent des performances accrues par rapport à l'IDE virtuel et prennent en charge l'accès forcé aux unités (FUA). FUA garantit que le système d'exploitation écrit et lit les données directement à partir du support en contournant tous les mécanismes de mise en cache.

Je sais que votre DC n'est pas une VM, mais le concept s'applique toujours. La mise en cache du disque et les contrôleurs de domaine ne se mélangent pas. C'est pourquoi l'installation d'Active Directory désactive la mise en cache d'écriture en tant que stratégie Windows, mais vous pouvez toujours avoir des mécanismes de mise en cache dans votre contrôleur RAID matériel, etc.

Scénario B: démarrage d'Active Directory à partir d'autres lecteurs dans un miroir cassé

1. Promouvoir un contrôleur de domaine. Recherchez le fichier Ntds.dit sur un lecteur en miroir.

2. Brisez le miroir.

3. Continuez la réplication entrante et la réplication sortante à l'aide du fichier Ntds.dit sur le premier lecteur du miroir.

4. Démarrez le contrôleur de domaine en utilisant le fichier Ntds.dit sur le deuxième lecteur dans le miroir.

C'est un tueur de réplication qui m'a beaucoup mordu sur les contrôleurs de domaine physiques avec des volumes RAID 1. Personnellement, je n'ai jamais eu de retour en arrière de l'USN, mais cela tuera la réplication sur ce contrôleur de domaine. Je veux dire, imaginez un volume RAID 1 de 2 disques. 1 lecteur meurt. Vous le supprimez, insérez un nouveau lecteur ... aaaaaaand DSA Not Writable.

Depuis le blog AskDS :

Si vous ne disposez pas d'alimentations sans coupure (UPS) pour vos hôtes VM ou le disque de stockage où réside la base de données Active Directory, assurez-vous que la mise en cache en écriture est désactivée sur l'ordinateur hôte de la machine virtuelle. Veuillez consulter ce lien pour obtenir des conseils supplémentaires. Inversement, si la mise en cache d'écriture doit rester activée pour l'hôte VM qui héberge le contrôleur de domaine, installez un onduleur pour éviter d'endommager le ou les contrôleurs de domaine.

Encore une fois, il s'agit de contrôleurs de domaine virtualisés, mais le concept de mise en cache de disque s'applique également aux contrôleurs de domaine physiques.

Voilà donc mon idée. Je pense que cela a quelque chose à voir avec votre système de stockage. Vous voulez certainement désactiver tous les mécanismes de mise en cache au moins sur le volume ntds.dit, surtout si vous êtes sujet à des pannes de courant.