pengembangan-web-mp-pd.com

Jeda lama saat mengakses namespace DFS

Kami baru saja memigrasikan jaringan Windows kami untuk menggunakan DFS untuk file yang dibagikan. DFS bekerja dengan baik, kecuali untuk satu masalah yang menjengkelkan: pengguna mengalami penundaan yang signifikan ketika mereka mencoba mengakses ruang nama DFS yang belum mereka akses selama beberapa waktu. Saya telah mencoba untuk memecahkan masalah tetapi belum berhasil sejauh ini, dan saya berharap seseorang di sini mungkin memiliki beberapa petunjuk untuk membantu menyelesaikan masalah.

Pertama, beberapa latar belakang di jaringan kami:

Jaringan menggunakan domain Active Directory tingkat fungsional Windows 2008 dengan dua DC 2008 dan dua server DNS (satu di masing-masing DC). Jaringan hanya DNS - tidak ada WINS. Semua komputer berada di situs yang sama dan terhubung oleh Gigabit Ethernet. Kami memiliki sekitar 20 ruang nama DFS berbasis Domain dalam mode Windows 2008, dan setiap ruang nama DFS memiliki dua server ruang nama DFS Windows 2008 (dua server yang sama untuk semua ruang nama). Semua server namespace berada dalam mode FQDN dan semua target folder ditentukan menggunakan FQDN mereka. Semua komputer mutakhir dengan Paket Layanan dan tambalan.

Target folder aktual (yaitu SMB yang dibagikan folder DFS kami) tersebar di beberapa server file dan aplikasi, semuanya menjalankan Windows 2008, dua server aplikasi yang menjalankan Windows 2003 R2, tanpa replikasi setup sama sekali (misalnya semua folder DFS saat ini hanya memiliki satu target folder).

Beberapa detail tentang masalah ini:

Penundaan akses namespace umumnya 1 - 10 detik panjang dan tampaknya terjadi ketika komputer tertentu belum mengakses namespace yang diminta sekitar lima menit atau lebih.

Misalnya, jika pengguna belum mengakses \\ domain.name\namespace1\selama lebih dari lima menit dan berupaya mengakses \\ domain.name\namespace1\melalui Windows Explorer, jendela Explorer akan membeku selama 1 - 10 detik sebelum akhirnya melanjutkan dan menampilkan folder yang ada di \\ domain.name\namespace1. Jika mereka kemudian menutup jendela Explorer dan mencoba mengakses \\ domain.name\namespace1\lagi dalam waktu lima menit, konten akan ditampilkan hampir secara instan - jika mereka menunggu lebih dari lima menit maka akan melalui jeda 1 - 10 detik lagi.

Setelah "di dalam" namespace semuanya Nice dan cepat, itu hanya koneksi awal ke namespace yang lambat.

Penundaan penjelajahan tampaknya memengaruhi semua varian Windows yang kami gunakan (Windows 2008 x64 SP2, Windows 2003 R2 x86 SP2, Windows XP Pro x86 SP3) - mungkin sedikit lebih buruk di Windows = XP/2003 dari pada Windows 2008, tapi saya tidak yakin apakah perbedaannya bukan hanya psikologis.

Mengakses target folder yang mendasarinya secara langsung menunjukkan tidak ada penundaan sama sekali - yaitu jika saham SMB yang ditunjukkan oleh DFS diakses secara langsung (melewati DFS) maka tidak ada jeda.

Selama pemecahan masalah, saya perhatikan bahwa "Durasi cache" untuk semua root DFS kami diatur ke 300 detik - 5 menit. Mengingat bahwa ini adalah jumlah waktu yang sama yang diperlukan untuk memicu jeda, saya berasumsi bahwa caching ini entah bagaimana terkait, meskipun saya tidak yakin persis apa yang di-cache pada klien dan karenanya apa yang perlu dilihat lagi setelah 5 menit berlalu.

Dalam mencoba menyelesaikan masalah, saya sudah mencoba/memeriksa yang berikut (tidak berhasil):

  • Jalankan dcdiag di kedua Pengontrol Domain - tidak ada masalah ditemukan
  • Selesai memeriksa server DNS dasar tanpa menemukan masalah - Saya tidak tahu cara memeriksa server DNS secara detail, tetapi saya akan menambahkan bahwa jaringan tidak menunjukkan perilaku aneh lainnya yang mungkin mengarah ke masalah DNS
  • Anti Virus dinonaktifkan pada klien dan server
  • Menghapus salah satu server namespace dari beberapa ruang nama - tidak ada perbedaan

Jadi di situlah saya merencanakan - dan saya kehabisan ide. Adakah yang bisa menyarankan apa yang menyebabkan penundaan dan/atau apa yang harus saya coba selanjutnya?

22
Matt

Ya, kami akhirnya tampaknya telah menyelesaikan masalah ini di lingkungan kami. Untuk keuntungan orang lain, inilah yang kami temukan dan bagaimana kami memperbaiki masalahnya:

Untuk mencoba dan mendapatkan wawasan lebih lanjut tentang apa yang terjadi sebelum/selama/setelah penundaan, kami menggunakan Wireshark pada mesin klien untuk menangkap/menganalisis lalu lintas jaringan sementara klien itu berusaha mengakses bagian DFS.

Capture ini menunjukkan sesuatu yang aneh: setiap kali penundaan terjadi, di antara permintaan DFS dikirim dari klien ke DC, dan rujukan ke server root DFS kembali dari DC ke klien , DC mengirimkan beberapa pencarian nama siaran ke jaringan.

Pertama, DC akan menyiarkan pencarian NetBIOS untuk DOMAIN (di mana DOMAIN adalah nama domain Active Directory pra-Windows 2000 kami). Beberapa detik kemudian, ia akan menyiarkan LLMNR pencarian untuk DOMAIN. Ini akan diikuti oleh siaran NetBios lainnya untuk pencarian DOMAIN. Setelah ketiga pencarian ini telah disiarkan (dan saya berasumsi waktunya habis) DC akhirnya akan menanggapi klien dengan rujukan (yang benar) ke server root DFS.

Pencarian nama siaran ini untuk DOMAIN hanya dikirim ketika penundaan lama membuka bagian DFS terjadi, dan kami dapat dengan jelas melihat dari penangkapan Wireshark bahwa DC tidak mengembalikan referensi ke DFS root server sampai ketiga pencarian dikirim (dan ~ 7 detik berlalu) .Jadi, pencarian nama siaran ini jelas merupakan penyebab penundaan kami.

Sekarang kami tahu apa masalahnya, kami mulai mencari tahu mengapa pencarian nama siaran ini terjadi. Setelah sedikit lebih banyak Googling dan beberapa trial-and-error, kami menemukan jawaban kami: kami belum menetapkan kunci registri DfsDnsConfig pada pengontrol domain kami menjadi 1, seperti yang diperlukan saat menggunakan DFS di lingkungan khusus DNS.

Ketika kami awalnya menyiapkan DFS di lingkungan kami, kami melakukan membaca berbagai artikel tentang cara mengkonfigurasi DFS untuk lingkungan khusus-DNS (mis. Microsoft KB24438 dan lainnya) dan mengetahui kunci registri ini, tetapi telah salah menginterpretasikan instruksi kapan/bagaimana menggunakannya.

KB244380 mengatakan:

Kunci registri DFSDnsConfig harus ditambahkan ke setiap server yang akan berpartisipasi dalam ruang nama DFS untuk semua komputer untuk memahami nama yang sepenuhnya memenuhi syarat.

Kami pikir ini berarti bahwa kunci registri harus ditetapkan pada server namespace DFS saja, tidak menyadari bahwa itu juga diperlukan pada pengontrol domain. Setelah kami menetapkan DfsDnsConfig ke 1 pada pengontrol domain kami (dan me-restart layanan "DFS Namespace"), masalahnya hilang.

Jelas kami senang dengan hasil ini, tetapi saya akan menambahkan bahwa saya masih belum 100% yakin bahwa ini adalah satu-satunya masalah kami - Saya ingin tahu apakah menambahkan DfsDnsConfig = 1 ke DC kami hanya menyelesaikan masalah, daripada menyelesaikannya . Saya tidak tahu mengapa DC akan mencoba mencari DOMAIN (nama domain itu sendiri, bukan server di domain) selama proses rujukan DFS, bahkan di lingkungan non-DNS-saja, dan saya juga tahu saya belum menetapkan DfsDnsConfig = 1 pada pengontrol domain di lingkungan DNS-only (diakui jauh lebih kecil/sederhana) lainnya dan belum memiliki masalah yang sama. Namun, kami telah memecahkan masalah kami sehingga kami senang.

Saya harap ini bermanfaat bagi orang lain yang mengalami masalah serupa - dan terima kasih sekali lagi kepada mereka yang menawarkan saran.

28
Matt

Ini bisa disebabkan oleh pemesanan netmask server DNS. Kami menemukan ini baru-baru ini di Server 2003. Ini tergantung pada subnetting Anda saat ini.

Contoh.

Situs 1: IP subnet 10.0.0.0/24 Situs 2: IP subnet 10.0.1.0/24

Klien di situs 2 membuat kueri DNS untuk namespace berbasis domain Anda dan akan diberikan server DFS di situs 1 secara default karena server DNS tidak mengetahui batas-batas IP situs. Anda perlu memberi tahu server DNS Anda apa subnet mask yang digunakan untuk mengidentifikasi alamat IP mana yang harus ditanggapi.

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

3
Chris

Blog Tim Direktori Aktif memiliki artikel Tiga bagian SEMUA tentang Penundaan DFS.

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

Ini mencakup dasar-dasar pada Proses Referensi, dan kemudian menunjukkan bagaimana menggunakan berbagai alat termasuk dfsUtil dan dfsDiag untuk menemukan penyebab sebenarnya dari keterlambatan.

Itu membantu saya menemukan masalah saya. Yang ternyata bukan izin Baca di direktori berbagi untuk Pengguna Domain.

HTH, Daniel

3
Daniel B

Berbau seperti masalah DNS tetapi semuanya berjalan. Saya lebih suka FRS lama karena alat diagnostik seperti Ultrasound sangat berguna: 7

Apakah Anda mendapatkan sesuatu di Log Acara Replikasi DFS pada target? (laporan DFS Health akan menarik peringatannya dari log peristiwa)

Berjalan tanpa WINS adalah tujuan yang bagus dan mengagumkan, meskipun saya cukup menentang ini jika ada sistem Windows pra-Vista/2008 sekitar karena semuanya tidak selalu berfungsi seperti yang diharapkan atau secepat tanpa WINS dalam pengalaman saya - meskipun itu sebenarnya tidak masalah.

2
Oskar Duveborn

Jadi saya menggunakan artikel ini dalam pencarian saya. Saya mengatur semuanya dan masih memiliki masalah. Setelah menghabiskan beberapa hari mencari masalah dan mengecualikan semuanya 'Microsoft' saya kira itu terkait Jaringan. Ternyata WAN Accelerator kami masalahnya. Saya meminta orang Networking kami mematikan akselerasi untuk Pengontrol Domain kami dan semuanya menjadi lebih baik.

1
David Jenkins

dfsutil/spcflush dan dfsutil/pktflush dapat menjadi solusi juga di jaringan multi-situs, pastikan bahwa tautan DFS dari situs rumah datang dari server lokal dan bukan dari cache.

1
Parag DJ

Kami memiliki masalah yang terdengar serupa, di mana pengguna akan mengalami keterlambatan (hingga satu menit) antara mengklik drive yang dipetakan ke share DFS, dan dapat melihat dan menelusuri folder di dalam share.

Pengguna juga memiliki drive rumah yang dipetakan ke berbagi DFS yang berbeda pada volume yang sama, dan tidak memiliki penundaan saat mengakses folder di sana.

Perbedaan antara keduanya adalah Access-Based Enumeration (ABE) - pembagian masalah mengaktifkannya (ini adalah drive yang umum untuk pengguna, dengan ribuan folder - ABE berarti pengguna hanya melihat folder yang memiliki izin).

Menonaktifkan ABE sepenuhnya menghilangkan masalah. Jelas ini bukan solusi karena pengguna kemudian melihat semua folder, membingungkan mereka. Saya telah mereplikasi share DFS ke server dengan beberapa disk cadangan sebagai tindakan sementara, dan bahkan dengan ABE diaktifkan pada target baru ini, penundaan telah hilang.

Server masalah adalah 2k3R2, dan memiliki waktu aktif lebih dari 150 hari (!), Jadi itu akan di-boot ulang dan CHKDSK dijalankan melebihi volume yang menyinggung. Saya akan mengirim kembali ke sini jika ini ada bedanya dengan masalah. Target baru ada di server 2k8.

1
slag

Punya banyak pengontrol, begitu pula skrip (dnsdfs.cmd servername):

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

Klien cache referensi DFS, yaitu ketika Anda memasukkan\domain.name\namespace itu akan cache yang merujuk ke server.name server yang sebenarnya. Setelah rujukan kedaluwarsa dari cache, klien pada dasarnya harus "menemukan" topologi DFS Anda lagi, karena itu penundaan.

Lihat di sini: http://technet.Microsoft.com/en-us/library/cc758234 (WS.10) .aspx dan di sini http: //blogs.technet. com/filecab/arsip/2006/01/20/417832.aspx untuk info lebih lanjut tentang cara kerjanya.

Solusi yang memungkinkan? Cara yang sulit untuk menyelesaikannya mungkin dengan menulis sebuah program kecil yang "tetap hidup" setiap beberapa menit; misalnya program C yang membuka file pertama yang ditemukan dan segera menutupnya. Saya belum mencoba atau menguji ini, dan Anda pasti perlu memberikan pertimbangan hati-hati jika Anda akan melakukannya.

1
Maximus Minimus

Saya tahu poster asli tidak menggunakan WINS, tetapi saya memposting untuk kepentingan orang lain karena kami menggunakan posting ini paling banyak untuk membantu memecahkan masalah yang sangat mirip. Bagi kami, akhirnya seseorang memutuskan untuk memberi nama workstation mereka dengan nama yang sama dengan domain. Jadi, setiap kali DC melakukan pencarian pada nama domain untuk rujukan DFS, ia ingin menyelesaikan ke workstation itu dan akan menyebabkan penundaan beberapa detik yang sangat banyak. A static 20 entri ditempatkan ke WINS menunjuk pada DC dan ini telah memecahkan masalah. Jika Anda tidak punya MENANG, Anda dapat bereksperimen dengan menempatkan nama domain sebagai nama mesin dalam file LMHOSTS menunjuk ke DC untuk mendapatkan pencarian 20, dan menetapkan prioritas untuk memiliki LMHOSTS menjadi tempat pertama yang harus dicari untuk menyelesaikan nama netbios.

1
newguy

http://technet.Microsoft.com/en-us/library/cc780950 (v = ws.10) .aspx Halaman ini sebenarnya menyebutkan Pengontrol Domain dan DFSN, jika itu membantu.

DFS Domain Controller dan Entri Registry Server Root

Entri registri berikut ini berada di bawah

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs 

pada server root dan pengontrol domain. Semua entri adalah REG_DWORD.

1
Amy

Anda menyebutkan bahwa Anda memiliki 20 server DFS namun gagal menyebutkan jika semua server berada di fasilitas yang sama.

Jika server ini tidak dalam fasilitas yang sama dan setiap situs lain memiliki domainnya sendiri, Anda mungkin ingin memastikan kegagalan klien diaktifkan.

0
Ishmael

Bagi mereka yang berakhir di sini melalui pencarian google dan yang memiliki masalah yang sama ...

Pertama periksa apakah semua tautan di Namespace Anda tersedia dan bagus. Itulah yang terjadi dalam kasus saya, masih ada tautan di namespace ke server yang sedang down, jadi jeda yang lama ketika membuka DNS adalah karena sedang mencari server itu dan gagal. Setelah saya menonaktifkan tautan itu di DFS, jeda panjang itu hilang.

0
Bryan