Tạm dừng lâu khi truy cập không gian tên DFS

Gần đây chúng tôi đã di chuyển mạng Windows của chúng tôi để sử dụng DFS cho các tệp được chia sẻ. DFS đang hoạt động tốt, ngoại trừ một vấn đề gây phiền nhiễu: người dùng gặp phải sự chậm trễ đáng kể khi họ cố gắng truy cập vào một không gian tên DFS mà họ đã không truy cập trong một thời gian. Tôi đã cố gắng khắc phục sự cố nhưng cho đến nay vẫn chưa có thành công nào và tôi hy vọng ai đó ở đây có thể có một số gợi ý để giúp giải quyết vấn đề.

Đầu tiên, một số nền tảng trên mạng của chúng tôi:

Mạng sử dụng miền Active Directory cấp độ chức năng của Windows 2008 với hai DC Windows 2008 và hai máy chủ DNS (một trên mỗi DC). Mạng chỉ là DNS - không có CHIẾN THẮNG. Tất cả các máy tính được đặt tại cùng một trang và được kết nối bằng Gigabit Ethernet. Chúng tôi có khoảng 20 không gian tên DFS dựa trên tên miền trong chế độ Windows 2008 và mỗi không gian tên DFS có hai máy chủ không gian tên DFS Windows 2008 (cùng hai máy chủ cho tất cả các không gian tên). Tất cả các máy chủ không gian tên đều ở chế độ FQDN và tất cả các mục tiêu thư mục được chỉ định bằng FQDN của chúng. Tất cả các máy tính đều được cập nhật với Gói dịch vụ và bản vá.

Các mục tiêu thư mục thực tế (ví dụ SMB chia sẻ các thư mục DFS của chúng tôi) nằm rải rác trên một số máy chủ ứng dụng và tệp, tất cả đều chạy Windows 2008 hai máy chủ ứng dụng chạy Windows 2003 R2, không có thiết lập sao chép nào (ví dụ: tất cả các thư mục DFS hiện tại chỉ có một mục tiêu thư mục).

Một số chi tiết về vấn đề:

Độ trễ truy cập không gian tên thường dài 1 - 10 giây và dường như xảy ra khi một máy tính cụ thể không truy cập vào không gian tên được yêu cầu trong khoảng năm phút trở lên.

Ví dụ: nếu người dùng chưa truy cập \ domain.name \ namepace1 \ trong hơn năm phút và cố gắng truy cập \ domain.name \ namepace1 \ qua Windows Explorer, cửa sổ Explorer sẽ đóng băng trong 1 - 10 giây trước khi cuối cùng nối lại và hiển thị các thư mục tồn tại trong \ domain.name \ namepace1. Sau đó, nếu họ đóng cửa sổ Explorer và cố gắng truy cập \ domain.name \ namepace1 \ trong vòng năm phút, nội dung sẽ được hiển thị gần như ngay lập tức - nếu họ chờ lâu hơn năm phút, nó sẽ lại tiếp tục tạm dừng 1 - 10 giây.

Khi "bên trong" không gian tên, mọi thứ đều tốt và linh hoạt, đó chỉ là kết nối ban đầu với không gian tên chậm.

Sự chậm trễ duyệt web dường như ảnh hưởng đến tất cả các biến thể của Windows mà chúng tôi sử dụng (Windows 2008 x64 SP2, Windows 2003 R2 x86 SP2, Windows XP Pro x86 SP3) - có thể tệ hơn một chút trong Windows XP / 2003 so với Windows 2008, nhưng tôi Tôi không chắc sự khác biệt không chỉ là tâm lý.

Truy cập các mục tiêu thư mục cơ bản trực tiếp thể hiện không có độ trễ nào - tức là nếu các cổ phiếu SMB được chỉ ra bởi DFS được truy cập trực tiếp (bỏ qua DFS) thì không có tạm dừng.

Trong quá trình xử lý sự cố, tôi nhận thấy rằng "Thời lượng bộ nhớ cache" cho tất cả các gốc DFS của chúng tôi được đặt thành 300 giây - 5 phút. Cho rằng đây là cùng một khoảng thời gian cần thiết để kích hoạt tạm dừng, tôi cho rằng bộ đệm này có liên quan nào đó, mặc dù tôi không chắc chính xác những gì được lưu trong bộ nhớ cache trên máy khách và do đó những gì cần phải tra cứu lại sau 5 phút đã trôi qua.

Khi cố gắng giải quyết vấn đề tôi đã thử / kiểm tra như sau (không thành công):

• Chạy dcdiag trên cả hai Bộ điều khiển miền - không tìm thấy sự cố nào
• Thực hiện một số kiểm tra máy chủ DNS cơ bản mà không tìm thấy bất kỳ sự cố nào - Tôi không biết cách kiểm tra chi tiết các máy chủ DNS, nhưng tôi sẽ thêm rằng mạng không thể hiện bất kỳ hành vi lạ nào khác có thể chỉ ra sự cố DNS
• Vô hiệu hóa chống vi-rút trên máy khách và máy chủ
• Xóa một trong các máy chủ không gian tên khỏi một vài không gian tên - không có sự khác biệt

Vì vậy, đó là nơi tôi đang đến - và tôi hết ý tưởng. Bất cứ ai cũng có thể đề xuất những gì có thể gây ra sự chậm trễ và / hoặc những gì tôi nên thử tiếp theo?

Vâng, cuối cùng chúng tôi dường như đã giải quyết vấn đề này trong môi trường của chúng tôi. Vì lợi ích của người khác, đây là những gì chúng tôi đã khám phá và cách chúng tôi khắc phục vấn đề:

Để thử và hiểu rõ hơn về những gì đã xảy ra trước / trong / sau khi trì hoãn, chúng tôi đã sử dụng Wireshark trên máy khách để nắm bắt / phân tích lưu lượng mạng trong khi máy khách đó cố truy cập vào chia sẻ DFS.

Các ảnh chụp này cho thấy một điều kỳ lạ: bất cứ khi nào sự chậm trễ xảy ra, ở giữa yêu cầu DFS được gửi từ máy khách đến DC và giới thiệu đến máy chủ gốc DFS quay lại từ DC đến máy khách, DC đã gửi một số tên quảng bá tra cứu mạng.

Đầu tiên, DC sẽ phát một tra cứu NetBIOS cho DOMAIN (trong đó DOMAIN là tên miền Active Directory trước Windows 2000 của chúng tôi). Vài giây sau, nó sẽ phát một tra cứu LLMNR cho DOMAIN. Điều này sẽ được theo sau bởi một tra cứu NetBios phát sóng khác cho DOMAIN. Sau khi ba lần tra cứu này được phát sóng (và tôi giả sử đã hết thời gian), DC cuối cùng sẽ trả lời khách hàng bằng một giới thiệu (chính xác) đến máy chủ gốc DFS.

Các tra cứu tên quảng bá cho DOMAIN chỉ được gửi khi xảy ra sự chậm trễ kéo dài chia sẻ DFS và chúng ta có thể thấy rõ từ bản chụp Wireshark rằng DC không trả lại giới thiệu cho máy chủ gốc DFS cho đến khi cả ba lần tra cứu được gửi ( và ~ 7 giây trôi qua). Vì vậy, các tra cứu tên phát sóng này rõ ràng là nguyên nhân của sự chậm trễ của chúng tôi.

Bây giờ chúng tôi đã biết vấn đề là gì, chúng tôi bắt đầu cố gắng tìm hiểu tại sao các tra cứu tên phát sóng này lại xảy ra. Sau khi thêm một chút về Google và một số lỗi và thử, chúng tôi đã tìm thấy câu trả lời của mình: chúng tôi đã không đặt khóa đăng ký DfsDnsConfig trên các bộ điều khiển miền của mình thành 1, như yêu cầu khi sử dụng DFS trong môi trường chỉ có DNS.

Khi chúng tôi thiết lập DFS ban đầu trong môi trường của mình, chúng tôi đã đọc các bài viết khác nhau về cách định cấu hình DFS cho môi trường chỉ có DNS (ví dụ: Microsoft KB244380 và các dịch vụ khác) và đã biết về khóa đăng ký này, nhưng đã hiểu sai hướng dẫn về cách / sử dụng nó.

KB244380 nói:

Khóa đăng ký DFSDnsConfig phải được thêm vào mỗi máy chủ sẽ tham gia vào không gian tên DFS cho tất cả các máy tính để hiểu tên đủ điều kiện.

Chúng tôi nghĩ rằng điều này có nghĩa là khóa đăng ký phải được đặt trên các máy chủ không gian tên DFS , không nhận ra rằng nó cũng được yêu cầu trên các bộ điều khiển miền. Sau khi chúng tôi đặt DfsDnsConfig thành 1 trên bộ điều khiển miền của chúng tôi (và khởi động lại dịch vụ "Không gian tên DFS"), vấn đề đã biến mất.

Rõ ràng là chúng tôi hài lòng với kết quả này, nhưng tôi sẽ nói thêm rằng tôi vẫn không tin chắc 100% rằng đây là vấn đề duy nhất của chúng tôi - tôi tự hỏi liệu việc thêm DfsDnsConfig = 1 vào DC của chúng tôi chỉ giải quyết vấn đề chứ không phải giải quyết nó . Tôi không thể hiểu tại sao các DC sẽ cố gắng tra cứu DOMAIN (chính tên miền chứ không phải máy chủ trong miền) trong quá trình giới thiệu DFS, ngay cả trong môi trường không có DNS và tôi cũng biết tôi chưa đặt DfsDnsConfig = 1 trên các bộ điều khiển miền trong các môi trường khác (chỉ đơn giản là nhỏ hơn / đơn giản hơn) và không có vấn đề tương tự. Tuy nhiên, chúng tôi đã giải quyết vấn đề của mình vì vậy chúng tôi rất vui.

Tôi hy vọng điều này hữu ích cho những người khác đang gặp phải vấn đề tương tự - và một lần nữa cảm ơn những người đã đưa ra đề xuất trên đường đi.

Điều này có thể được gây ra bởi thứ tự netmask máy chủ DNS. Chúng tôi đã bắt gặp điều này gần đây trong Server 2003. Điều này phụ thuộc vào mạng con hiện tại của bạn.

Thí dụ.

Trang web 1: Mạng con IP 10.0.0.0/24 Trang web 2: Mạng con IP 10.0.1.0/24

Máy khách trong trang 2 tạo một truy vấn DNS cho không gian tên dựa trên tên miền của bạn và sẽ được cung cấp máy chủ DFS trong trang 1 theo mặc định vì máy chủ DNS không biết về ranh giới IP của trang. Bạn cần nói với máy chủ DNS của mình sử dụng mặt nạ mạng con nào để xác định địa chỉ IP nào sẽ phản hồi.

Xem http://support.microsoft.com/kb/842197

Blog nhóm Active Directory có một bài viết gồm ba phần TẤT CẢ về độ trễ DFS.

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

Nó bao gồm những điều cơ bản về Quy trình giới thiệu và sau đó cho thấy cách sử dụng các công cụ khác nhau bao gồm dfsUtil và dfsDiag để khám phá nguyên nhân thực sự của sự chậm trễ.

Nó giúp tôi tìm ra vấn đề của mình. Hóa ra là không có quyền Đọc trên thư mục chia sẻ cho Người dùng Miền.

HTH, Daniel

Có mùi như một vấn đề DNS nhưng bất cứ điều gì đi. Tôi rất thích FRS cũ vì các công cụ chẩn đoán như Siêu âm rất hữu ích: 7

Bạn có nhận được gì trong Nhật ký sự kiện tái tạo DFS trên các mục tiêu không? (báo cáo DFS Health sẽ rút ra các cảnh báo từ nhật ký sự kiện)

Chạy mà không có THẮNG là một mục tiêu tốt và đáng ngưỡng mộ, mặc dù tôi khá chống lại điều này nếu có bất kỳ hệ thống Windows trước Vista / 2008 nào vì mọi thứ không luôn hoạt động như mong đợi hoặc nhanh mà không có THẮNG theo kinh nghiệm của tôi - mặc dù nó thực sự không nên quan trọng

Máy khách lưu trữ một giới thiệu DFS, tức là khi bạn nhập \ domain.name \ không gian tên, nó sẽ lưu trữ tên miền máy chủ thực tế nào. Khi giới thiệu hết hạn từ bộ đệm, khách hàng về cơ bản phải "khám phá" cấu trúc liên kết DFS của bạn một lần nữa, do đó độ trễ.

Hãy xem tại đây: http://technet.microsoft.com/en-us/l Library / cc758234 (WS.10) .aspx và tại đây http://blogs.technet.com/filecab/archive/2006/01/20 /417832.aspx để biết thêm thông tin về cách thức hoạt động của nó.

Phương pháp khả thi? Một cách khó khăn để thực hiện nó có thể là viết một chương trình nhỏ "giữ sống" cứ sau vài phút; ví dụ, một chương trình C tạo ra tệp đầu tiên mà nó tìm thấy và ngay lập tức đóng lại nó. Tôi chưa thử hoặc thử nghiệm điều này, và bạn chắc chắn sẽ cần cân nhắc cẩn thận nếu bạn định làm điều đó.

Chúng tôi đã có một vấn đề nghe có vẻ tương tự, trong đó người dùng sẽ gặp phải sự chậm trễ (tối đa một phút) giữa việc nhấp vào ổ đĩa được ánh xạ tới chia sẻ DFS, và có thể xem và duyệt đến các thư mục trong phần chia sẻ.

Người dùng cũng có các ổ đĩa gia đình được ánh xạ tới một chia sẻ DFS khác trên cùng một ổ đĩa và không có độ trễ khi truy cập các thư mục ở đó.

Sự khác biệt giữa hai loại này là Bảng liệt kê dựa trên truy cập (ABE) - tính năng chia sẻ vấn đề đã được bật (đây là ổ đĩa chung cho người dùng, với hàng ngàn thư mục - ABE có nghĩa là người dùng chỉ nhìn thấy những thư mục mà họ có quyền).

Vô hiệu hóa ABE đã loại bỏ hoàn toàn vấn đề. Rõ ràng đây không phải là một giải pháp vì người dùng sau đó nhìn thấy tất cả các thư mục, gây nhầm lẫn cho chúng. Tôi đã sao chép chia sẻ DFS sang một máy chủ với một số đĩa dự phòng như một biện pháp tạm thời và ngay cả khi ABE được kích hoạt trên mục tiêu mới này, sự chậm trễ đã biến mất.

Máy chủ có vấn đề là 2k3R2 và có thời gian hoạt động hơn 150 ngày (!), Do đó, nó sẽ được khởi động lại và chạy CHKDSK trên khối lượng vi phạm. Tôi sẽ đăng lại ở đây nếu điều này làm cho bất kỳ sự khác biệt cho vấn đề. Mục tiêu mới là trên máy chủ 2k8.

dfsutil / spcflush và dfsutil / pktflush cũng có thể là một giải pháp trong mạng đa trang, đảm bảo rằng liên kết DFS của trang chủ sẽ đến từ máy chủ cục bộ chứ không phải từ bộ đệm.

Tôi biết người đăng ban đầu không sử dụng THẮNG, nhưng tôi đang đăng vì lợi ích của người khác vì chúng tôi đã sử dụng bài đăng này nhiều nhất để giúp giải quyết vấn đề rất giống nhau. Đối với chúng tôi, cuối cùng đã có người quyết định đặt tên cho máy trạm của họ có cùng tên với tên miền. Vì vậy, mỗi khi DC thực hiện tra cứu tên miền cho giới thiệu DFS, họ muốn giải quyết với máy trạm đó và sẽ gây ra sự chậm trễ đáng kể trong 10 giây. Một mục nhập tĩnh 20 đã được đặt vào THẮNG chỉ vào một DC và điều này đã giải quyết được vấn đề. Nếu bạn không có CHIẾN THẮNG, bạn có thể thử nghiệm đặt tên miền làm tên máy trong tệp LMHOSTS được trỏ đến DC để lấy 20 tra cứu và đặt ưu tiên để LMHOSTS là nơi đầu tiên xem xét để giải quyết các tên netbios.

http://technet.microsoft.com/en-us/l Library / cc780950 (v = ws.10) .aspx Trang này thực sự đề cập đến cả Bộ kiểm soát miền và DFSN, nếu điều đó có ích.

Bộ điều khiển tên miền DFS và mục đăng ký máy chủ gốc

Các mục đăng ký sau được đặt dưới

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs 

trên các máy chủ gốc và bộ điều khiển miền. Tất cả các mục là REG_DWORD.

Vì vậy, tôi đã sử dụng bài viết này trong tìm kiếm của tôi. Tôi thiết lập mọi thứ và vẫn có vấn đề. Sau khi dành nhiều ngày để xem xét vấn đề và loại trừ mọi thứ 'Microsoft', tôi đoán nó có liên quan đến Mạng. Hóa ra Bộ gia tốc WAN của chúng tôi là vấn đề. Tôi đã cho các anh chàng Mạng của chúng tôi tắt tăng tốc cho Bộ kiểm soát miền của chúng tôi và mọi thứ trở nên tốt hơn.

Có rất nhiều bộ điều khiển, tập lệnh ( dnsdfs.cmd servername) cũng vậy:

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

Bạn đề cập rằng bạn có 20 máy chủ DFS chưa đề cập đến nếu tất cả các máy chủ nằm trong cùng một cơ sở.

Nếu các máy chủ này không ở cùng một cơ sở và mỗi trang web khác có tên miền riêng, bạn có thể muốn đảm bảo rằng máy khách dự phòng được bật.

Đối với những người kết thúc ở đây thông qua một tìm kiếm google và những người có cùng một vấn đề ...

Trước tiên hãy kiểm tra xem tất cả các liên kết trong Không gian tên của bạn có sẵn và tốt không. Đó là những gì đã xảy ra trong trường hợp của tôi, vẫn còn một liên kết trong không gian tên đến một máy chủ bị hỏng, do đó, việc tạm dừng lâu khi mở DNS là do nó đang tìm kiếm máy chủ đó và không thành công. Khi tôi vô hiệu hóa liên kết đó trong DFS, việc tạm dừng lâu đã biến mất.

Xác minh rằng nhóm Người dùng xác thực có quyền truy cập để liệt kê nội dung của thư mục gốc mà bạn được ánh xạ tới. Ví dụ: nếu ổ x: được ánh xạ tới \ domain.local \ khởi hành \ Marketing thì người dùng sẽ cần có quyền liệt kê danh sách cho \ domain.local \ khoa. Trong năm 2008/2012, bạn có thể chỉ định theo các quyền nâng cao mà nó áp dụng cho "Chỉ thư mục này" để chúng không được phép liệt kê nội dung của bất kỳ thư mục con nào có thể đang kế thừa quyền.