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


8

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?


3
Comment avez-vous déterminé exactement qu'il s'agissait en fait d'un retour en arrière de l'USN?
Mathias R. Jessen

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

Très bonne question. J'y pense depuis quelques heures maintenant. Je ne sais toujours pas. Mais accessoirement, puisque vous prévoyez que le serveur connaîtra fréquemment des pannes de courant, avez-vous confirmé que la mise en cache d'écriture est toujours désactivée sur tous les volumes? Je sais que c'est la valeur par défaut une fois que vous avez décompressé, mais elle peut être remplacée. Je veux juste m'assurer que vous n'avez pas réactivé la mise en cache d'écriture.
Ryan Ries

Bonne estimation de la mise en cache de l'écriture. Outre le cache système, le serveur dispose d'un contrôleur RAID matériel, qui doit donc être vérifié également. J'irai voir demain.
Massimo

Réponses:


6

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.


2
Exactement mes pensées. Écriture du cache sur l'adaptateur de baie, mais non sauvegardé par batterie. Parierait 0,05 GBP dessus :-)
Simon Catlin

1
Le cache d'écriture était en fait activé sur le contrôleur RAID et le système d'exploitation n'était pas en mesure de le désactiver automatiquement; Je l'ai désactivé manuellement et j'espère que cela a résolu le problème une fois pour toutes. Cette configuration était très probablement sa cause première.
Massimo

Agréable! Cela devrait vous retenir jusqu'à ce que vous puissiez améliorer UPS! ;)
Ryan Ries

Confirmé: le problème ne s'est plus jamais produit après que le cache d'écriture (non sauvegardé par batterie) ait été désactivé sur le contrôleur de disque physique.
Massimo

@Massimo J'adore que vous soyez revenu le confirmer après 4 ans. :)
Ryan Ries
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.