Jump to content
  • entries
    16
  • comments
    22
  • views
    6450

Windows 2008 R2 Schema update, lingering objects


SOF

590 views

 Share

Πλησιάζοντας τον μήνα από το Release Date των Windows 2008 R2, ήδη πολλές επιχειρήσεις έχουν στο καλεντάρι τους την εγκατάσταση του πρώτου τους Windows 2008 R2 Domain Controller. Με την ευκαιρία αυτή θα δούμε σε συντομία τι πρέπει να προσέξουμε πριν την αναβάθμιση του Schema του AD σε R2 σχετικά με τα lingering objects. Προφανώς επειδή πρόκειται για σχετικά κανούργια διαδικασία, ενδέχεται να υπάρχουν σημεία τα οποία δεν τα έχω λάβει υπόψη. Σχόλια και παρατηρήσεις είναι ευπρόσδεκτα.

Ας αρχίσουμε λοιπόν.

Κατά την αναβάθμιση του Schema σε R2 είναι γνωστό ότι εισάγoνται και τα extensions για το Recycle Bin. Ακόμα και πριν ενεργοποιηθεί ο Recycle Bin, τα objects του AD προετοιμάζονται για να τον υποστηρίξουν με την εισαγωγή του isRecycled attribute. Αυτό φυσικά ισχύει και για τα deleted objects. Ύστερα από την αναβάθμιση μπορεί να προκύψουν μηνύματα λάθουs που να ισχυρίζονται ότι υπάρχουν lingering objects στο AD. Συνήθως το πρόβλημα αυτό προκύπτει σε περιβάλλοντα με πολλές καθημερινές εγγραφές/διαγραφές χρηστών, DNS records κ.α. Το αποτέλεσμα είναι να σταματά το replication μέχρι να τρέξει ο Garbage Collector στον source DC. Το "πρόβλημα" αυτό λύνεται από μόνο του, αφού δεν πρόκειται για πραγματικά lingering objects.

Μια ματιά στο υπόβαρθρο.

Το μοντέλο που ακολουθεί το Active Directory για τον συγχρονισμό των δεδομένων είναι το loose consistency with convergence

Σύμφωνα με αυτό το μοντέλο, κανείς δεν μπορεί να εγγυηθεί ότι σε ένα συγκεκριμένο χρονικό σημείο κάθε replication partner θα έχει ακριβώς τα ίδια objects, αφού επιτρέπεται να γίνονται αλλαγές σε κάθε έναν από αυτούς. Εαν όμως το σύστημα αφεθεί να φθάσει σε μια ισορροπία, μην επιτρέποντας οποιεσδήποτε αλλαγές για το χρονικό διάστημα που απαιτείται για να συγχρονιστούν οι πληροφορίες μεταξύ τους, τότε η τελική κατάσταση είναι εγγυημένα η ίδια παντού.

Στην περίπτωση μας συγκεκριμένα αυτό που συμβαίνει είναι το εξής:

α.) Γίνεται το schema update.

β.) Επηρρεάζεται ένα deleted object του οποίου το Tombstone Lifetime λήγει σήμερα, και θα το διαγράψει ο garbage collector στην επόμενη προγραμματισμένη εκτέλεσή του.

γ.) Ο garbage collector του DC προορισμού έχει τρέξει ήδη, διαγράφοντας μόνιμα το αντικείμενο αυτό.

δ.) O DC της πηγής προσπαθεί να συγχρονίσει με τον DC προορισμού.

ε.) Ο DC προορισμού δηλώνει άγνοια για το αντικείμενο αυτό, και καταχωρεί το μήνυμα NTDS Event ID: 1988

ζ.) Ο DC προορισμού μπλοκάρει το εισερχόμενο replication, λόγω του strict replication consistency.

στ.) O source DC εκτελεί τον garbage collector και το πρόβλημα λύνεται, εφόσον δεν προσπαθεί να συγχρονίσει πλέον το συγκεκριμένο object.

Τα άρθρα σχετικά με το Tombstone Lifetime και τον Garbage Collector:

The Active Directory database garbage collection process

The default tombstone lifetime (TSL) value remains at 60 days instead of increasing to 180 days in Windows Server 2003 R2

Εάν για κάποια επιχείρηση η καθυστέρηση του replication μέχρι 12 ώρες από site σε site μπορεί να σημαίνει σημαντική απώλεια κερδών, σκαρφιστίκαμε έναν τρόπο να ελλατώσουμε τις απώλειες αν όχι να τις αποφύγουμε εντελώς.

α.) Προαιρετικά: αυξάνουμε παντού την συχνότητα εκτέλεσης του garbage collector. Στο παραπάνω άρθρο περιγράφεται πώς.

β.) Συγχρονίζουμε παντού την εκτέλεση του garbage collector. Η εκτέλεση μπορεί να επιβληθεί τοπικά με την εντολή: repadmin /setattr "" "" doGarbageCollection add "1", ή ακολουθώντας τις οδηγίες εδώ. Το καλύτερο θα ήταν να προγραμματίσουμε την εκτέλεση σε κάποιο χρονικό σημείο όπου πραγματοποιούνται οι λιγότερες αλλαγές στην βάση δεδομένων του AD.

γ.) Ακριβώς μετά από την εκτέλεση του garbage collector, (τουλάχιστον μία μέρα μετά τις παραπάνω αλλαγές), αυξάνουμε την τιμή του Tombstone Lifetime στο Hub site. Αυτή η αλλαγή θα μεταφερθεί στους υπολοιπους με το replication. Το σημαντικότερο πριν την εκτέλεση αυτού του βήματος είναι να έχουμε όσο το δυνατότερο την ίδια κατάσταση σχετικά με τα διαγραφέντα αντικείμενα από την προηγούμενη εκτέλεση του garbage collector.

δ.) Εκτέλεση του Schema upgrade,

ε.) Προαιρετικά: μείωση του TBL στην αρχική τιμή. Επιβάλουμε την εκτέλεση του garbage collector ξανά. Μειώνουμε την συχνότητα εκτέλεσης στην προηγούμενη τιμή.

Προς το παρόν δεν υπάρχει κάποιο δημοσιευμένο KB επί του θέματος, αλλά απ' ότι ξέρω βρίσκεται ένα στα σκαριά.

Ελπίζω να βρήκατε τα παραπάνω χρήσιμα! Έστω και αν δεν σκοπεύετε να αναβαθμίσετε το schema σύντομα, τα περισσότερα αφορούν γενικά την λειτουργία του AD replication, οπότε αξίζει να τους ρίξετε μια ματιά!

 

Φιλικά

SOF

 Share

0 Comments


Recommended Comments

There are no comments to display.

Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...