|
||
| Editor Login | Register | ||
| > Bilgisayar > Networking |
|
|
| Sık Karşılaşılan Replikasyon sorunlarını çözmek |
|
SIK KARŞILAŞILAN “ACTIVE DIRECTORY REPLICATION” SORUNLARINI ÇÖZMEK ... Giriş Microsoft’un Windows 2000 ile Bilgi İşlem dünyasına en büyük armağanı, hiç kuşkusuz Active Directory"dir. Bu muhteşem network yönetim sistemiyle, en basitinden, en devasa networklere kadar her ölçekteki networkü yönetmek oldukça kolaydır. Active Directory bu olanakları bizlere kolaylıkla sağlayan güçlü bir sistemdir ama kendiside bir o kadar hassas bir mekanizmaya sahiptir. Replication Nedir?Replication yani Türkçe ifade edersek çoğaltma, “aynı yada benzer tür verilerin birden fazla server arasında transfer edilerek herzaman güncel veriyle çalışmak” anlamına gelir, diyebiliriz. Söz konusu Active Directory olduğunda 2 tür replicationdan bahsedebiliriz; 1- Intrasite replication 2- Intersite replication Intrasite replication aynı site içindeki Domain Controllerlar arasında gerçekleşir. Intrasite topology ve replicationdan NTFRS ( NT File Replication Service) adlı servislerin sorumlu olduğunu unutmayın Intersite ise farklı sitelar arasındaki belirlenen Domain Controlerlar arasında gerçekleşir. Intersite topology ve replicationdan KCC (Knowledge Consistency Checker) sorumludur. Düzgün işlemeyen veya işlemeyen replication büyük sorundur; Ana yada yardımcı sunucularda oluşturduğunuz nesneler, diğer sunuculara çoğaltılamaz, doğrulanamaz, Active Directory veritabanındaki objelerin süresinin dolup dolmadığı belirlenemez, forest ve domain prep çalışmaz, Exchange veya schemayı genişleten uygulama ve processleri çalıştıramaz, kuramazsınız, domain controller promoto/demote işlevleri çalışmaz. Yani düşünmek bile istemeyeceğiniz bir sürü problemi karşınızda bulabilirsiniz. Neden Replication sorunu olur?Replication sorunlarının başında, düzgün ayarlanmamış site linkler, site subnet objeleri, transfer metodları ( intersite replication sorunları için) , dns problemleri, ağ iletişim problemleri ve uzun süre offline olup sonradan online olan, arızalı dizin sunucuları başı çekerler. Bunun dışında birde yapılandırma sorunları vardır. Buna bir örnek verirsek, Multi Domain yapılarında, aynı DC üzerinde Infrastructure Master FSMO rolü ve Global Catalog serverın tutulması, sık görülen hatalardan birisidir... Örnek Replication Sorunları Event loglarınızı düzenli bir şekilde kontrol etmezseniz, bir süre replication sorunu olup olmadığını anlamayabilirsiniz. Yeni bir DC i ağa katmaya çalıştığınızda, Forestprep, Domainprep, Exchange server kurulumu gibi yüksek sayıda objenin ağda transfer edildiği durumlarda hatayla karşılaştığınızda sorunla yüzleşirsiniz. Event Loglara baktığınızda ise genellikle NTDS ve Netlogon hataları görürsünüz. Event 1388 – 1988 hataları:Bu hata, hedef domain controllerda “strict replication consistency” adı verilen registry değerinin var olmaması veya yanlış değere sahip olmasından kaynaklanır. Strict Replication Consistency (SRC) değeri, süresi dolmuş (outdated) objelerin çoğaltılmasını engelleyen bir registry değeridir. SRC değeri 1 olarak ayarlandığında (etkin) DCnin local Active Directory database i ile replike edilen objeleri kıyaslar. Eğer dizin sunucusu uzun süre offline olmuş veya zaman/tarih hatası var ise, SRC değeri yok veya aktif değilse outdated olarak bahsettiğimiz bu çöpe atılacak objeler, tekrar ve tekrar replicate edilir. Aşağıda örnek bir “NTDS Replication” event error kaydı görmektesiniz. Event Type:ErrorEvent Source:NTDS ReplicationEvent Category:ReplicationEvent ID:1388Date:2/21/2005Time:9:19:48 AMUser:NT AUTHORITYANONYMOUS LOGONComputer:DC3Description:Another domain controller (DC) has attempted to replicate into this DC anobject which is not present in the local Active Directory database. Theobject may have been deleted and already garbage collected (a tombstonelifetime or more has past since the object was deleted) on this DC. Theattribute set included in the update request is not sufficient to createthe object. The object will be re-requested with a full attribute setand re-created on this DC.Source DC (Transport-specific network address):4a8717eb-8e58-456c-995a-c92e4add7e8e._msdcs.sistemuzmani.localObject:CN=InternalApps,CN=Users,DC=sistemuzmani,DC=localObject GUID:a21aa6d9-7e8a-4a8f-bebf-c3e38d0b733aDirectory partition:DC=contoso,DC=localDestination highest property USN:20510User Action:Verify the continued desire for the existence of this object. Todiscontinue re-creation of future similar objects, the followingregistry key should be created.Registry Key:HKLMSystemCurrentControlSetServicesNTDSParametersStrict Replication ConsistencyEvent Type:ErrorEvent Source:NTDS ReplicationEvent Category:ReplicationEvent ID:1988Date:2/21/2005Time:9:13:44 AMUser:NT AUTHORITYANONYMOUS LOGONComputer:DC3Description:Active Directory Replication encountered the existence of objectsin the following partition that have been deleted from the localdomain controllers (DCs) Active Directory database. Not all director transitive replication partners replicated in the deletionbefore the tombstone lifetime number of days passed. Objects thathave been deleted and garbage collected from an Active Directorypartition but still exist in the writable partitions of other DCsin the same domain, or read-only partitions of global catalog serversin other domains in the forest are known as "lingering objects".This event is being logged because the source DC contains a lingeringobject which does not exist on the local DCs Active Directory database.This replication attempt has been blocked.The best solution to this problem is to identify and remove alllingering objects in the forest.Source DC (Transport-specific network address):4a8717eb-8e58-456c-995a-c92e4add7e8e._msdcs.sistemuzmani.localObject:CN=InternalApps,CN=Users,DC=sistemuzmani,DC=localObject GUID:a21aa6d9-7e8a-4a8f-bebf-c3e38d0b733a Not: Strict Replication Consistency kayıt anahtarı Windows 2003 SP1 ve sonrasında mevcut ve aktifdir. Windows 2000, SP4 ve 2003 Serverda sonradan girmeniz gerekebilir. Strict Replication Consistency’i aktifleştirin :Daha öncede bahsettiğim gibi Strict Replication Consistency (SRC), tombstoned, yani süresi dolmuş ve silinmek üzere işaretlenmiş nesnelerin, replicationda tekrar tekrar çoğaltılmasını engeller. Bu değere registry’de : HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Strict Replication Consistencyyoluyla erişebilirsiniz. Eğer bu değer mevcut değilse yeni bir “Dword” değeri oluşturun, adına “Strict Replication Consistency” (tırnaklar olmadan) yazın ve 16lı hexadecimal değerine 1 yazın. Bu işlemi yaptıktan sonra bilgisayarı yeniden başlatınız. Repadmin ile Garbage collected objeleri silmek :Windows 2003 Resource kit ile beraber gelen araçlardan biriside “Repadmin” dir. Repadmin, replikasyon konusunda ihtiyaç duyacağınız hemen her türlü imkanı sağlar. Tek dezavantajı, komut satırından çalışmayı sevmeyen kişiler için ilk başta biraz karışık gelmesi sayılabilir. Repadmin’i yukarıda belirttiğimiz amaçta çalıştırmak için aşağıdaki komutu verin : repadmin /removelingeringobjects Destination_domain_controller Source_domain_controller_GUID Directory_partition /advisory_mode · advisoy_mode anahtarını, repadmin komutunu çalıştıracağınız ilk seferde mutlaka giriniz. advisory_mode, komut çalıştırmadan önce sonuçlarını simüle eder. Eğer bir sorun yoksa “succesfull” ibaresini görürsünüz. Komut advisory_mode anahtarıyla düzgün çalışmışsa, şimdi asıl komutu girebilirsiniz. Tam açılımlı bir örnek verirsek : repadmin /removelingeringobjects domain_controller sistemuzmani.local A0AE6093-15F5-4DB8-836B-4495E3A15396 DC=sistemuzmani,DC=local Not: GUID, Globally Unique IDentifier A0AE6093-15F5-4DB8-836B-4495E3A15396_msdcs.forest_root_domain_name.com benzeri bir tanımlayıcıdır. Repadmin için sadece ilk bölümünün alınması yeterlidir , yani A0AE6093-15F5-4DB8-836B-4495E3A15396 kısmından sonrasını yazmayın. GUID’inizi bilmiyorsanız : repadmin /showrepl /v dc.sistemuzmani.local komutunu verdiğinizde çıkan sonuçtan GUIDinizi görebilirsiniz. Örnek çıktı aşağıdaki gibidir : AnkaraBranchSite\DC DC Options: IS_GC Site Options: (none) DC object GUID: d0281ebb-4a3a-4851-9ddd-0006a4c1be08 DC invocationID: d0281ebb-4a3a-4851-9ddd-0006a4c1be08 ==== INBOUND NEIGHBORS ====================================== DC=sistemuzmani,DC=local AnkaraBranchSite\DC2 via RPC DC object GUID: 6dd95a70-86a4-4c9a-8ae9-1467b872d885 Address: 6dd95a70-86a4-4c9a-8ae9-1467b872d885._msdcs.sistemuzmani.local DC invocationID: c0f0e7a2-cb59-4861-b8b2-68b59da2a75a SYNC_ON_STARTUP DO_SCHEDULED_SYNCS WRITEABLE USNs: 42563/OU, 42563/PU Last attempt @ 2007-06-02 17:07:52 was successful. CN=Configuration,DC=sistemuzmani,DC=local KocaeliBranchSite\dc3 via RPC DC object GUID: 7bb27be0-fdcf-410c-9d4e-31270064f302 Address: 7bb27be0-fdcf-410c-9d4e-31270064f302._msdcs.sistemuzmani.local DC invocationID: 7ec73b22-27a9-4e89-8d80-b322a474bc7d SYNC_ON_STARTUP DO_SCHEDULED_SYNCS WRITEABLE COMPRESS_CHANGES NO_CHANGE_ NOTIFICATIONS USNs: 167362/OU, 167362/PU Last attempt @ 2007-06-02 14:59:38 was successful. AnkaraBranchSite\DC2 via RPC DC object GUID: 6dd95a70-86a4-4c9a-8ae9-1467b872d885 Address: 6dd95a70-86a4-4c9a-8ae9-1467b872d885._msdcs.sistemuzmani.local DC invocationID: c0f0e7a2-cb59-4861-b8b2-68b59da2a75a SYNC_ON_STARTUP DO_SCHEDULED_SYNCS WRITEABLE USNs: 42563/OU, 42563/PU Last attempt @ 2007-06-0217:06:54 was successful. CN=Schema,CN=Configuration,DC=sistemuzmani,DC=local KocaeliBranchSite\dc3 via RPC DC object GUID: 7bb27be0-fdcf-410c-9d4e-31270064f302 Address: 7bb27be0-fdcf-410c-9d4e-31270064f302._msdcs.sistemuzmani.local DC invocationID: 7ec73b22-27a9-4e89-8d80-b322a474bc7d SYNC_ON_STARTUP DO_SCHEDULED_SYNCS WRITEABLE COMPRESS_CHANGES NO_CHANGE_ NOTIFICATIONS USNs: 167217/OU, 167217/PU Last attempt @ 2007-06-02 14:59:39 was successful. AnkaraBranchSite\DC2 via RPC DC object GUID: 6dd95a70-86a4-4c9a-8ae9-1467b872d885 Address: 6dd95a70-86a4-4c9a-8ae9-1467b872d885._msdcs.sistemuzmani.local DC invocationID: c0f0e7a2-cb59-4861-b8b2-68b59da2a75a SYNC_ON_STARTUP DO_SCHEDULED_SYNCS WRITEABLE USNs: 42502/OU, 42502/PU Last attempt @ 2007-06-02 16:59:38 was successful. DC=ankara,DC=sistemuzmani,DC=local KocaeliBranchSite\dc3 via RPC DC object GUID: 7bb27be0-fdcf-410c-9d4e-31270064f302 Address: 7bb27be0-fdcf-410c-9d4e-31270064f302._msdcs.sistemuzmani.local DC invocationID: 7ec73b22-27a9-4e89-8d80-b322a474bc7d DO_SCHEDULED_SYNCS COMPRESS_CHANGES NO_CHANGE_NOTIFICATIONS USNs: 167327/OU, 167327/PU Last attempt @ 2007-06-0214:59:39 was successful. Bu komutla sadece GUID’inizi değil Inbound Neighbours bağlantıları , siteler hakkında bilgiler ve son replicationların düzgün olup olmadığı, varsa da hatalar listelenir. Not: Windows 2000 serverlarda repadmin i çalıştıramazsınız. Bunun yerine Strict Replication Consistency kayıt anahtarını aktifleştiriniz. Yapılandırma Hataları Active Directory yapılandırma hatalarının başında, Global Catalog server ile Infrastructure Master FSMO rolünün aynı serverda olduğu durumlarda yaşanabilir. Domain’de birden fazla DC olduğu durumlarda, asla infrastructure master ve global catalog aynı server üzerinde olmamalıdır. IM (Infrastructure Master) GC (Global Catalog) ile aynı serverda olduğunda, objelerin tarih statüsünü(time stamp) bilemez(outdated mı?, tombstoned mı? Yoksa güncelmi?). Bu yüzden IM FSMO rolü çalışmaz ve replication gerçekleşmez.. Bu yüzden her zaman bu FSMO rolünü GC olmayan bir başka DC de tutunuz.. Nasıl?Öncelikle Active Directory Users And Computers’ı açın. Sunucunuzu seçin, sağ tıklayın ve “Connect to Domain Controller” seçeneğini seçin.Burada FSMO rolünü devredeceğimiz DC’ye bağlanacağız. Connect to... seçeneğini verdikten sonra, karşımıza dizinde kayıtlı Dclerin bir listesi gelecektir (şekil 1).
Şekil1- Dizinde kayıtlı Domain Controllerların listesi. Listeden rolü devredeceğiniz DCyi seçin ve OK’i tıklayın. Bu işlemide tamamladıktan sonra karşımıza bağlandığımız DC’nin Active Directory Users And Computers snap-in i gelir. Yine buradan server a sağ tıklıyoruz, Operation Masters seçeneğini seçiyoruz.
Şekil 2- Operations Masters.. seçeneğiyle rolleri görüntüleyin
Şekil 3 - FSMO rolümüzü buradan değiştiriyoruz. Burada “Operations Masters” altında, rolün o andaki geçerli sahibi olan serverın adı görülür. Aşağıda ise FSMO rolünü transfer edebileceğimiz serverın ismi görüntülenir. Rolü devretmek için “Change” butonuna tıklarız. FSMO rolü başarıyla devredilirse :
Şekil 4- Başarıyla devredilmiş bir FSMO rolü. FSMO rolünün geçerlilik kazanması biraz zaman alabilir. Bu süreyi kısaltmak için Rolü devrettiğimiz sunucuda “File Replication Service” servisini yeniden başlatın. Daha sonra Directory Service loglarından rolün doğrulandığına dair bilgilendirme Event kayıtlarını kontrol edebilirsiniz..Bu information logu, Directory Services altında olacaktır :
Şekil 5- DC’nin infrastructure master rolünü aldığına dair information logu. Infrastructure Master’ı taşımayıp GC serverı taşımanız gerekiyorsa; 1-Active Directory Sites And Services Snapin i açın: Startà All Programsà Administrative Toolsà Active Directory Sites And Services
Şekil 6 - Active Directory Sites And Services Snap-in i Mevcut Site ınızı açın, Servers Container’ı altındaki GC serverınızı seçin. 2-Serverınızın altındaki NTDS settings’e sağ tıklayın, ve properties’e tıklayın.
Şekil 7 - NTDS Settings altında GC server seçeneğini buradan değiştiriyoruz. 3- General tabında “Global Catalog” altındaki check box ı kaldırın. 4- OK tıklayıp çıkın. Bir süre sonra Event Viewer’da Directory Services kayıtlarına aşağıdaki gibi bir event düşecektir
Şekil 8 – Artık yeni bir Global Catalogumuz var! Tabii ki, siz NTDS ayarlarında varolan varolan bir GC’yi kaldırırsanız, bunun tam tersi bir uyarı alırsınız.
Şekil 9- Global Catolagu kaldırdığınızda alacağınız event log kaydı. Not: Değişikliklerin gerçekleşmesi yarım saat kadar zaman alabileceğini unutmayınız. Bazen FSMO rolleri başarıyla taşınamaz, rol hatalıdır (ERROR state) veya her iki sunucunuzda çakışmalardan dolayı, domainde veya forestta tek bir serverda olması gereken rolü her iki server birden üstlenmeye çalışabilir. Böyle durumlarda rolü “seize” etmeniz gerekebilir. Bu konu ile ilgili bir makale, daha önce sevgili hocamız Alper Çanak tarafından, Sistem Uzmanı.Com da detaylı bir şekilde yazıldığı için yazma gereği duymadım. Böyle bir durumla karşılaşmışsanız http://www.sistemuzmani.com/Articles/Details.aspx?aId=1000000129 adresine tıklayarak bu makaleyi okuyabilirisiniz. USN JOURNAL WRAP HATALARI Bir diğer sık görülen replication sorunuda NTFS USN Journal Wrap hatalarıdır. NTFS USN Journal, NTFS 5.0 ile formatlanmış partitionlarda gerçekleşen tüm değişiklikleri tutan bir logdur. Journal loglarda iki tür kayıt tutulur: dosyanın açık olduğu durum ve kapalı olduğu durumu bilgisi.. NTFRS, replike ettiği dosyaların kapalı olduğuna emin olduktan sonra dosya ya da veriyi replike eder. USN Journalda oluşabilecek hatalardan dolayı NTFRS, Active Directory veritabanının durumun bilgisini alamayacak, dolayısıyla replikasyonuda gerçekleştiremeyecektir. Bu tür hatalara, USN Journal Wrap hataları denir. Journal Wrap hatalarının nedeni, journal log dosyasının belirlenmiş boyutundan daha büyük olması veya, elektrik kesintisi, uygunsuz shutdown vb. "nedenlerden dolayı log dosyasında hata oluşması sıralanabilir. A- Journal log boyutuyla ilgili sorunlar: Journal boyutunu hesaplamak için şöyle bir formül vardır : journal boyutu/((60 byte + (dosya adı uzunluğu)) * 2) Bir örnek verecek olursak: 8+3 dosya isim formatına sahip 200.000 dosya/dizin için journal log boyutu 32 MB ı bulur. Windows 2000 SP2 e kadar, varsayılan journal log boyutu 32MB, verilebilecek en büyük log boyutu ise 128 MB’dı. Windows 2000 SP3 ile bu değer varsayılan 512 MB, maksimum 10.000 MB’a çıkarılmıştır. Bu ayarı bir registry ayarında değişiklik yaparak konfigüre edeblirsiniz : HKLM\System\CCS\Services\NTFRS\Parameters\"Ntfs Journal size in MB" (REG_DWORD) “NTFS Journal Size in MB” değerini varolan değerden daha yüksek bir değere ayarlayınız. B- Inconsistent Journal log hataları ile ilgili sorunlar: Windows 2000 SP3 ve sonrası için, “Enable journal wrap automatic restore” adlı bir registry değeri gelmiştir. Bu değer aktif hale getirildiğinde, Ntfrs.exe log dosyası üzerinde *non-authoritative restore işlemi gerçekleştirerek log dosyasını kurtarmaya çalışır. İlgili registry anahtarına :HKLM\System\Ccs\Services\Ntfrs\Parameters altından ulaşablir ve Enable journal wrap automatic restore adlı kayıt anahtarına “1” değerini vererek aktif hale getirebilirsiniz (varsayılan olarak kapalıdır) * Ntfrs.exe’nin gerçekleştirdiği non-authoritative restore işleminin, Active directory’de gerçekleştirilen non-authoritative restore işlemi ile bir ilgisi yoktur. · İlgili registry değerlerini konfigüre ettikten sonra, bilgisayarı yeniden başlatınız. Sonuç Active Directory replication problemleri elbette sadece bunlarla sınırlı değildir. Fakat bu yazımda, Sistem Yöneticilerinin en sık karşılaştığı bazı temel replikasyon sorunların üzerinden geçmiş olduk ve bu sorunlarla nasıl başedebileceğimizi gördük. |
|
| Bağlantılar: bilgininefendisi.net |
| Open Source Document Project | AUP&TOS |
