Mengapa kontroler domain encouter rollback USN setelah shutdown yang tidak bersih?


8

Saya memiliki pengontrol domain Windows Server 2008 R2 ini berjalan pada server Dell fisik, model PowerEdge R510.

Ada beberapa masalah listrik di sekitar sini, sehingga pemadaman listrik, sayangnya, cukup umum terjadi; ada UPS, tetapi mereka tidak dapat diandalkan seperti seharusnya, dan kadang-kadang server akan mengalami shutdown yang tidak bersih.

Untuk beberapa alasan saya benar-benar tidak dapat mengerti, kadang-kadang DC khusus ini akan muncul setelah shutdown yang tidak bersih dan menghadapi rollback USN , memaksa kami untuk menurunkan dan mempromosikannya kembali.

Ini tidak masuk akal sama sekali, karena server adalah fisik dan tidak ada snapshot, kloning dan / atau pemulihan pernah dilakukan di dalamnya; juga, tidak ada perangkat lunak tambahan yang diinstal di sana, hanya menjalankan tugas DC; khususnya, tidak ada kloning / pemulihan / perangkat lunak apa pun yang ada.

Sebuah korupsi filesystem setidaknya masuk akal, tetapi kembalikan USN benar-benar tidak, karena tidak ada cara server dapat dibawa kembali ke keadaan sebelumnya. Namun, ini telah terjadi setidaknya tiga kali dalam dua bulan terakhir, jadi itu pasti bukan peristiwa gila satu kali; tapi saya benar-benar tidak dapat memberikan penjelasan.

Apa yang bisa menjadi alasan untuk masalah ini?


3
Bagaimana tepatnya Anda menentukan bahwa itu sebenarnya adalah kembalikan USN?
Mathias R. Jessen

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

Pertanyaan yang sangat bagus Saya sudah memikirkannya selama beberapa jam sekarang. Saya masih belum tahu. Tetapi secara kebetulan, karena Anda mengantisipasi server akan sering mengalami pemadaman listrik, sudahkah Anda mengonfirmasi bahwa cache tulis masih dimatikan pada semua volume? Saya tahu itu adalah default begitu Anda dcpromo, tetapi dapat diganti. Hanya ingin memastikan bahwa Anda tidak mengaktifkan cache tulis kembali.
Ryan Ries

Tebakan bagus tentang menulis caching. Terlepas dari cache sistem, server memiliki pengontrol RAID perangkat keras, sehingga harus diperiksa juga. Saya akan melihat besok.
Massimo

Jawaban:


6

Saya memikirkan hal ini selama beberapa jam hari ini. Agak membingungkan, tetapi seperti yang saya tunjukkan dalam komentar saya, tebakan terbaik saya adalah Anda juga memiliki semacam caching disk yang tidak dilakukan ke disk sebelum pemadaman listrik / shutdown kotor telah menghapus isi cache. ... Atau, karena Anda menjalankan volume RAID yang menampung ntds.dit, pemadaman listrik mungkin menyebabkan volume RAID Anda untuk sementara waktu rusak atau menjadi tidak koheren, jika hanya untuk sesaat.

Kita tahu bahwa garis partai pada rollback USN adalah ketika DC dikembalikan ke keadaan seperti sebelumnya, contoh klasik yang memulihkan DC tervirtualisasi dari snapshot. Saya tahu itu tidak berlaku untuk Anda persis ... tetapi bahkan dalam kasus disk dengan cache tulis, Anda dapat menganggap data yang secara fisik pada disk tersebut berisi "keadaan sebelumnya," sementara cache tulis adalah apa yang sebenarnya mengandung status terbaru DC ... bahkan jika kedua negara bagian hanya berjarak setengah detik.

Merenungkan komentar-komentar ini dari Microsoft:

Pedoman untuk pengontrol domain tervirtualisasi

Disk SCSI virtual memberikan peningkatan kinerja dibandingkan dengan IDE virtual dan mereka mendukung Akses Unit Paksa (FUA). FUA memastikan bahwa sistem operasi menulis dan membaca data secara langsung dari media dengan memintas setiap dan semua mekanisme caching.

Saya tahu bahwa DC Anda bukan VM, tetapi konsepnya masih berlaku. Disk caching dan DC tidak bisa bercampur. Itulah sebabnya menginstal Active Directory ternyata menulis caching off sebagai kebijakan Windows, tetapi Anda masih dapat memiliki mekanisme caching di pengontrol RAID perangkat keras Anda, dll.

Skenario B: Memulai Direktori Aktif dari drive lain di cermin yang rusak

  1. Promosikan pengontrol domain. Temukan file Ntds.dit pada drive yang dicerminkan.

  2. Hancurkan cermin.

  3. Lanjutkan ke replikasi masuk dan keluar replikasi dengan menggunakan file Ntds.dit pada drive pertama di mirror.

  4. Mulai pengendali domain dengan menggunakan file Ntds.dit pada drive kedua di mirror.

Itu pembunuh replikasi yang telah banyak menggigit saya di DC fisik dengan volume RAID 1. Saya tidak pernah secara pribadi memiliki kembalikan USN yang sebenarnya disebabkan oleh itu, tetapi itu akan membunuh replikasi pada DC itu. Maksud saya, bayangkan volume 1 disk RAID 2. 1 drive mati. Anda menghapusnya, pop dalam drive baru ... aaaaaa dan DSA Not Writable.

Dari blog AskDS :

Jika Anda tidak memiliki catu daya tak terputus (UPS) untuk host VM Anda atau disk penyimpanan di mana basis data direktori aktif berada, maka pastikan cache tulis dinonaktifkan pada komputer host mesin virtual itu. Silakan merujuk tautan ini untuk panduan tambahan. Sebaliknya, jika cache tulis perlu tetap diaktifkan untuk host VM yang menampung DC, kemudian instal UPS untuk menghindari kerusakan DC.

Sekali lagi, ini berbicara tentang DC tervirtualisasi, tetapi konsep cache disk berlaku untuk DC fisik juga.

Jadi, itulah ideku. Saya pikir itu ada hubungannya dengan sistem penyimpanan Anda. Pasti ingin menonaktifkan setiap dan semua mekanisme caching setidaknya pada volume ntds.dit, terutama jika Anda rentan terhadap pemadaman listrik.


2
Pikiranku persis. Tulis cache pada adaptor array, tetapi tidak didukung baterai. Taruhan 0,05 GBP untuk itu :-)
Simon Catlin

1
Cache tulis sebenarnya diaktifkan pada pengontrol RAID, dan OS tidak dapat menonaktifkannya secara otomatis; Saya telah menonaktifkannya secara manual dan saya harap ini memperbaiki masalah ini sekali dan untuk semua. Konfigurasi ini sangat mungkin menjadi penyebab utamanya.
Massimo

Bagus! Itu harus menahan Anda sampai Anda dapat UPS lebih baik! ;)
Ryan Ries

Dikonfirmasi: masalah tidak pernah terjadi lagi setelah cache tulis (bukan didukung baterai) dinonaktifkan pada pengontrol disk fisik.
Massimo

@ Massimo Saya suka Anda kembali untuk mengkonfirmasi ini setelah 4 tahun. :)
Ryan Ries
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.