it-swarm.asia

DFS ad alanına erişirken uzun duraklama

Kısa bir süre önce Windows ağımızı paylaşılan dosyalar için DFS kullanmak üzere taşıdık. DFS, can sıkıcı bir sorun dışında iyi çalışıyor: kullanıcılar, bir süredir erişmedikleri bir DFS ad alanına erişmeye çalıştıklarında önemli bir gecikme yaşıyorlar. Sorunu gidermeye çalıştım, ancak şu ana kadar herhangi bir başarı elde etmedim ve burada birinin sorunu çözmeye yardımcı olacak bazı işaretçiler olabileceğini umuyordum.

İlk olarak, ağımızla ilgili bazı bilgiler:

Ağ, iki Windows 2008 DC'si ve iki DNS sunucusu (DC'lerin her birinde bir tane) bulunan Windows 2008 işlev düzeyinde bir Active Directory etki alanı kullanır. Ağ yalnızca DNS - WINS yok. Tüm bilgisayarlar aynı sitede bulunur ve Gigabit Ethernet ile bağlanır. Windows 2008 modunda yaklaşık 20 Etki Alanı tabanlı DFS ad alanımız vardır ve her DFS ad alanında iki Windows 2008 DFS ad alanı sunucusu vardır (tüm ad alanları için aynı iki sunucu). Tüm ad alanı sunucuları FQDN modundadır ve tüm klasör hedefleri FQDN'leri kullanılarak belirtilir. Tüm bilgisayarlar Servis Paketleri ve yamalar ile günceldir.

Gerçek klasör hedefleri (yani SMB DFS klasörlerimizi paylaşır) birkaç dosya ve uygulama sunucusuna dağılmıştır; bunların tümü Windows 2008 çalıştıran ve çoğaltma olmadan Windows 2008 R2 çalışan iki uygulama sunucusunu engeller (örneğin tüm DFS klasörlerinin şu anda yalnızca bir klasör hedefi vardır).

Sorun hakkında biraz daha detay:

Ad alanı erişim gecikmesi genellikle 1 - 10 saniye uzunluğundadır ve belirli bir bilgisayar istenen ad alanına yaklaşık beş dakika veya daha uzun bir süre erişmediğinde ortaya çıkar.

Örneğin, kullanıcı beş dakikadan fazla bir süre \\ domain.name\namespace1\'e erişmediyse ve Windows Gezgini aracılığıyla \\ domain.name\namespace1 \' e erişmeye çalışırsa, Gezgin penceresi en az 1 - 10 saniye donacaktır \\ domain.name\namespace1 içinde bulunan klasörleri sürdürme ve görüntüleme. Daha sonra Gezgin penceresini kapatır ve beş dakika içinde \\ domain.name\namespace1\'e tekrar erişmeye çalışırlarsa, içerik neredeyse anında görüntülenir - beş dakikadan fazla beklerse tekrar 1 - 10 saniye duraklamaya geçer.

Bir kez ad alanının içinde "her şey güzel ve çabuk, sadece yavaş ad alanına ilk bağlantı.

Göz atma gecikmeleri, kullandığımız tüm Windows çeşitlerini etkiliyor gibi görünüyor (Windows 2008 x64 SP2, Windows 2003 R2 x86 SP2, Windows XP Pro x86 SP3) - muhtemelen Windows'da biraz daha kötü = XP/2003, Windows 2008'den daha fazla, ancak farkın sadece psikolojik olmadığından emin değilim.

Temel klasör hedeflerine erişmek doğrudan bir gecikme göstermez - yani DFS tarafından gösterilen SMB paylaşımlara doğrudan erişilirse (DFS'yi atlayarak), duraklama olmaz.

Sorun giderme sırasında, tüm DFS köklerimiz için "Önbellek süresinin" 300 saniye - 5 dakika olarak ayarlandığını fark ettim. Bu, duraklamayı tetiklemek için gereken aynı süre göz önüne alındığında, bu önbelleğe almanın bir şekilde ilişkili olduğunu varsayıyorum, ancak tam olarak istemci üzerinde önbelleğe alınan şeyin ne olduğundan emin değilim ve bu nedenle 5 dakika geçtikten sonra nelere tekrar bakılması gerekiyor.

Sorunu çözmeye çalışırken zaten denedim/kontrol ettim (başarılı olmadan):

  • Her iki Etki Alanı Denetleyicisinde dcdiag çalıştır - sorun bulunamadı
  • Herhangi bir sorun bulmadan bazı temel DNS sunucusu kontrolleri yapıldı - DNS sunucularını ayrıntılı olarak nasıl kontrol edeceğimi bilmiyorum, ancak ağın bir DNS sorununa işaret edebilecek başka garip davranışlar sergilemediğini ekleyeceğim
  • İstemcilerde ve sunucularda devre dışı bırakılmış virüsten koruma
  • Ad alanı sunucularından birini birkaç ad alanından kaldırma - fark yok

İşte bu noktada kaldım - ve fikirlerim bitti. Gecikmelere neyin sebep olabileceğini ve/veya bundan sonra ne denemem gerektiğini bilen var mı?

22
Matt

Sonunda sonunda bu sorunu ortamımızda çözdüğümüz görülüyor. Başkalarının yararları için, keşfettiklerimiz ve sorunu nasıl çözdüğümüz:

Gecikmelerden önce/sırasında/sonrasında neler olduğuna dair daha fazla bilgi edinmek için, istemci bir DFS paylaşımına erişmeye çalışırken ağ trafiğini yakalamak/analiz etmek için Wireshark'ı bir istemci makinesinde kullandık.

Bu yakalamalar garip bir şey gösterdi: gecikme gerçekleştiğinde, istemciden DC'ye gönderilen DFS isteği ile DC istemciye geri dönen bir DFS kök sunucusuna yönlendirme arasında) , DC ağa birkaç yayın adı araması gönderiyordu.

İlk olarak, DC DOMAIN için bir NetBIOS araması yayınlardı (DOMAIN, Windows 2000 öncesi Active Directory alan adımızdır). Birkaç saniye sonra bir [~ # ~] llmnr [~ # ~] DOMAIN için arama. Bunu DOMAIN için başka bir yayın NetBios araması izleyecek. Bu üç arama yayınlandıktan sonra (ve zaman aşımına uğradığını varsayalım) sonra DC nihayet bir DFS kök sunucusuna (doğru) yönlendirmeyle istemciye yanıt verecektir.

DOMAIN için bu yayın adı aramaları yalnızca bir DFS paylaşımını açmanın uzun gecikmesi meydana geldiğinde gönderiliyordu ve Wireshark yakalamasından DC bir DFS'ye yönlendirme döndürmediğini açıkça görebiliyorduk) her üç arama gönderilinceye kadar (ve ~ 7 saniye geçtikten sonra) bu yayın adı aramaları gecikmelerimizin sebebiydi.

Artık sorunun ne olduğunu bildiğimize göre, bu yayın adı aramalarının neden meydana geldiğini anlamaya çalıştık. Biraz daha Googling ve bazı deneme yanılma işlemlerinden sonra cevabımızı bulduk: yalnızca DNS ortamında DFS kullanılırken gerektiği gibi alan denetleyicilerinizdeki DfsDnsConfig kayıt defteri anahtarını 1 olarak ayarlamamıştık.

Başlangıçta DFS'yi çevremizde kurduğumuzda , yalnızca DNS ortamı için DFS'nin nasıl yapılandırılacağıyla ilgili çeşitli makaleleri okuduk (örn. Microsoft KB244380 ve diğerleri) ve bu kayıt defteri anahtarının farkındaydı, ancak ne zaman/nasıl kullanılacağına ilişkin talimatları yanlış yorumlamışlardı.

KB244380 diyor:

DFSDnsConfig kayıt defteri anahtarının, tam bilgisayar adlarını anlaması için tüm bilgisayarların DFS ad alanına katılacak her sunucuya eklenmesi gerekir.

Bunun, kayıt defteri anahtarının yalnızca DFS ad alanı sunucularında ayarlanması gerektiğini, etki alanı denetleyicilerinde de gerekli olduğunu fark etmediğini düşündük. Etki alanı denetleyicilerinizde DfsDnsConfig öğesini 1 olarak ayarladıktan (ve "DFS Ad Alanı" hizmetini yeniden başlattıktan) sonra sorun ortadan kalktı.

Açıkçası bu sonuçtan memnunuz, ama yine de% 100'ün bu bizim tek sorunumuz olduğuna ikna olmadığımı da ekleyeceğim - DC'lerimize DfsDnsConfig = 1 eklemenin sorunu çözmek yerine sadece sorun çözdüğünü merak ediyorum . DC'lerin neden DNS olmayan bir ortamda bile DFS yönlendirme işlemi sırasında DOMAIN (etki alanı adının kendisi, etki alanındaki bir sunucu yerine) aramaya çalıştığını anlayamıyorum ve ben de biliyorum yalnızca DNS kullanan diğer ortamlarda (kuşkusuz çok daha küçük/basit) etki alanı denetleyicilerinde DfsDnsConfig = 1'i ayarlamadı ve aynı sorunu yaşamadı. Yine de sorunumuzu çözdük, bu yüzden mutluyuz.

Umarım bu benzer bir sorun yaşayan diğerlerine yardımcı olur - ve yol boyunca öneriler sunanlara tekrar teşekkürler.

28
Matt

Bu, DNS sunucusu ağ maskesi siparişinden kaynaklanıyor olabilir. Son zamanlarda Server 2003'te karşılaştık. Bu, mevcut alt ağınıza bağlıdır.

Misal.

Site 1: IP alt ağı 10.0.0.0/24 Site 2: IP alt ağı 10.0.1.0/24

Site 2'deki istemci, etki alanı tabanlı ad alanınız için bir DNS sorgusu yapar ve DNS sunucusu site IP sınırlarının farkında olmadığından, varsayılan olarak site 1'deki DFS sunucusuna verilir. Hangi IP adreslerine yanıt verileceğini belirlemek için DNS sunucularınıza hangi alt ağ maskesini kullanacağınızı söylemeniz gerekir.

Bkz. http://support.Microsoft.com/kb/842197

3
Chris

Active Directory Ekip Blogunda DFS Gecikmeleri hakkında TÜM üç bölümlü bir makale bulunmaktadır.

http://blogs.technet.com/b/askds/archive/2009/09/29/o-dfs-shares-where-art-thou-part-1-3.aspx

Tavsiye Sürecinin temellerini kapsar ve sonra gecikmelerin gerçek nedenini bulmak için dfsUtil ve dfsDiag gibi çeşitli araçların nasıl kullanılacağını gösterir.

Sorunumu bulmama yardımcı oldu. Etki Alanı Kullanıcıları için paylaşım dizininde Okuma izni olmadığı ortaya çıktı.

HTH, Daniel

3
Daniel B

DNS sorunu gibi kokuyor ama her şey yolunda gidiyor. Eski FRS'yi çok tercih ettim çünkü Ultrason gibi teşhis araçları çok faydalıydı: 7

Hedeflerdeki DFS Çoğaltma Olay Günlüğünde bir şey alıyor musunuz? (DFS Sağlık raporu uyarılarını olay günlüğünden alır)

WINS olmadan koşmak güzel bir hedeftir ve takdire değerdir, ancak her zaman beklendiği gibi veya hızlı çalışmadığı için Vista/2008 öncesi Windows sistemleri varsa buna karşıyım. WINS deneyimlerime göre - gerçekten önemli olmamasına rağmen.

2
Oskar Duveborn

Bu makaleyi araştırmamda kullandım. Her şeyi ayarladım ve hala sorunlarım vardı. Soruna bakarak ve 'Microsoft' her şeyi hariç tutarak birkaç gün geçirdikten sonra bunun Ağ ile ilgili olduğunu tahmin ettim. Sorun çıkıyor WAN Hızlandırıcı oldu. Ağ iletişimi çalışanlarımız Etki Alanı Denetleyicileri için ivmeyi kapattı ve her şey daha iyi oldu.

1
David Jenkins

dfsutil/spcflush ve dfsutil/pktflush, çoklu site ağında da bir çözüm olabilir, ana sitenin DFS bağlantısının önbellekten değil yerel sunucudan geldiğinden emin olun.

1
Parag DJ

Kullanıcıların DFS paylaşımıyla eşlenen bir sürücüyü tıklatma ile paylaşım içindeki klasörleri görebilme ve bu dosyalara göz atabilme arasında gecikmeler (bir dakikaya kadar) yaşayabilecekleri benzer bir sorun yaşadık.

Kullanıcıların aynı birimde farklı bir DFS paylaşımına eşlenen ev sürücüleri de vardı ve buradaki klasörlere erişirken gecikme olmadı.

İkisi arasındaki fark Erişim Tabanlı Numaralandırma'dır (ABE) - sorun paylaşımında bu özellik etkinleştirilmiştir (binlerce klasör içeren kullanıcılar için ortak bir sürücüdür - ABE, kullanıcıların yalnızca izinleri olan klasörleri görmesi anlamına gelir).

ABE'nin devre dışı bırakılması sorunu tamamen ortadan kaldırdı. Açıkçası bu, kullanıcıların tüm klasörleri görüp kafalarını karıştırdığı için bir çözüm değildir. DFS paylaşımını geçici bir önlem olarak bazı yedek diskleri olan bir sunucuya çoğalttım ve hatta bu yeni hedefte ABE etkinleştirildiğinde, gecikme gitti.

Sorun sunucusu 2k3R2 ve 150 günden fazla bir çalışma süresine sahip (!), Bu yüzden yeniden başlatılacak ve rahatsız edici birimin üzerinde CHKDSK çalıştırılacak. Sorunda herhangi bir fark yaratırsa buraya geri göndereceğim. Yeni hedef 2k8 sunucusunda.

1
slag

Çok fazla denetleyicim vardı, bir komut dosyası da vardı (dnsdfs.cmd servername):

dfsutil server registry dfsdnsconfig set %1
sc \\%1 stop dfs
sc \\%1 start dfs
1
i3laze

İstemci bir DFS başvurusunu önbelleğe alır, yani\domain.name\ad alanına girdiğinizde, gerçek sunucu domain.name'nin başvurduğu önbelleğe alınır. Yönlendirme önbellekten sona erdiğinde, istemcinin temel olarak DFS topolojinizi yeniden keşfetmesi gerekir, bu nedenle gecikme.

Buraya bir göz atın: http://technet.Microsoft.com/en-us/library/cc758234 (WS.10) .aspx ve burada http: //blogs.technet. com/filecab/archive/2006/01/20/417832.aspx bunun nasıl çalıştığı hakkında daha fazla bilgi için.

Olası çözümler? Bu konuda çirkin bir yol, birkaç dakikada bir “hayatta kal” yapan küçük bir program yazmak olabilir; Örneğin. bulduğu ilk dosyayı fopen ve hemen fclose bir C programı. Bunu denemedim veya test etmedim ve eğer yapacak olsaydınız kesinlikle dikkatli bir şekilde düşünmelisiniz.

1
Maximus Minimus

Orijinal posterin WINS kullanmadığını biliyorum, ancak çok benzer bir sorunu çözmeye yardımcı olmak için bu yazıyı en çok kullandığımız için başkalarının yararına gönderiyorum. Bizim için bu, iş istasyonunu etki alanı ile aynı adla adlandırmaya karar veren biri oldu. Bu nedenle, DC DFS yönlendirme için etki alanı adını her aradığında, bu iş istasyonuna çözüm bulmak istiyordu ve çok sayıda 10 saniyelik gecikmeye neden oluyordu. giriş WINS DC 'a işaret etti ve bu sorunu çözdü. WINS'niz yoksa, alan adını şu şekilde yerleştirmeyi deneyebilirsiniz) LMHOSTS dosyasındaki bir makine adı, 20 aramayı almak için bir DC) işaret ediyor ve netbios adlarını çözümlemek için ilk yer LMHOSTS olmasını sağlamak için önceliği ayarlıyor.

1
newguy

http://technet.Microsoft.com/en-us/library/cc780950 (v = ws.10) .aspx Bu sayfada, yardımcı olması durumunda aslında hem Alan Adı Denetleyicilerinden hem de DFSN'den bahsedilir.

DFS Etki Alanı Denetleyicisi ve Kök Sunucu Kayıt Defteri Girdileri

Aşağıdaki kayıt defteri girdileri altında

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs 

kök sunucularda ve etki alanı denetleyicilerinde. Tüm girişler REG_DWORD şeklindedir.

1
Amy

20 DFS sunucunuz olduğunu, ancak tüm sunucuların aynı tesiste olup olmadığını söyleyemediğinizi belirtiyorsunuz.

Bu sunucular aynı tesiste değilse ve her bir sitenin kendi etki alanı varsa, istemci geri dönmesinin etkinleştirildiğinden emin olmak isteyebilirsiniz.

0
Ishmael

Burada bir Google aramasıyla sonuçlanan ve aynı sorunu yaşayanlar için ...

Öncelikle Ad Alanınızdaki tüm bağlantıların kullanılabilir ve iyi olduğunu kontrol edin. Benim durumumda olan budur, hala isim alanında bir sunucuya bir bağlantı vardı, bu yüzden DNS'yi açarken uzun duraklama, o sunucuyu aramak ve başarısız olmasıydı. DFS'de bu bağlantıyı devre dışı bıraktıktan sonra uzun duraklama gitti.

0
Bryan