หยุดยาวเมื่อเข้าถึง DFS namespace

เราเพิ่งย้ายเครือข่าย Windows ของเราเพื่อใช้ DFS สำหรับไฟล์ที่ใช้ร่วมกัน DFS ทำงานได้ดียกเว้นปัญหาที่น่ารำคาญอย่างหนึ่ง: ผู้ใช้พบความล่าช้าอย่างมีนัยสำคัญเมื่อพวกเขาพยายามเข้าถึงเนมสเปซ DFS ที่พวกเขาไม่ได้เข้าถึงมาระยะหนึ่ง ฉันพยายามแก้ไขปัญหา แต่ยังไม่เคยประสบความสำเร็จมาก่อนและฉันหวังว่าจะมีบางคนที่นี่อาจมีตัวชี้บางอย่างเพื่อช่วยแก้ไขปัญหา

ประการแรกพื้นหลังบางส่วนในเครือข่ายของเรา:

เครือข่ายใช้โดเมน Active Directory ระดับการทำงานของ Windows 2008 พร้อม DCS Windows 2008 สองตัวและเซิร์ฟเวอร์ DNS สองตัว (หนึ่งตัวต่อ DCS แต่ละตัว) เครือข่ายเป็น DNS เท่านั้น - ไม่มี WINS คอมพิวเตอร์ทุกเครื่องตั้งอยู่ที่ไซต์เดียวกันและเชื่อมต่อโดย Gigabit Ethernet เรามีเนมสเปซ DFS บนโดเมนประมาณ 20 รายการในโหมด Windows 2008 และเนมสเปซ DFS แต่ละรายการมีเนมสเปซเซิร์ฟเวอร์ Windows 2008 DFS สองเซิร์ฟเวอร์ (เซิร์ฟเวอร์สองรายการเดียวกันสำหรับเนมสเปซทั้งหมด) เซิร์ฟเวอร์เนมสเปซทั้งหมดอยู่ในโหมด FQDN และระบุเป้าหมายโฟลเดอร์ทั้งหมดโดยใช้ FQDN คอมพิวเตอร์ทุกเครื่องเป็นรุ่นล่าสุดพร้อม Service Packs และแพตช์

เป้าหมายโฟลเดอร์ที่แท้จริง (เช่น SMB ที่แชร์โฟลเดอร์ DFS ของเราชี้ไปที่) กระจัดกระจายอยู่ในไฟล์เซิร์ฟเวอร์และแอปพลิเคชั่นหลายตัวที่รัน Windows 2008 บาร์สองแอปพลิเคชันเซิร์ฟเวอร์ที่รัน Windows 2003 R2 โดยไม่มีการตั้งค่าการจำลองแบบเลย มีเป้าหมายโฟลเดอร์เดียวเท่านั้น)

รายละเอียดเพิ่มเติมเกี่ยวกับปัญหา:

ความล่าช้าในการเข้าถึงเนมสเปซโดยทั่วไปจะมีความยาว 1 - 10 วินาทีและดูเหมือนว่าจะเกิดขึ้นเมื่อคอมพิวเตอร์เครื่องใดเครื่องหนึ่งไม่ได้เข้าถึงเนมสเปซที่ร้องขอเป็นเวลาประมาณห้านาทีหรือนานกว่านั้น

ตัวอย่างเช่นหากผู้ใช้ไม่ได้เข้าถึง \\ domain.name \ namespace1 \ นานกว่าห้านาทีและพยายามเข้าถึง \\ domain.name \ namespace1 \ ผ่าน Windows Explorer หน้าต่าง Explorer จะหยุดทำงานเป็นเวลา 1 - 10 วินาทีก่อนที่ในที่สุด ดำเนินการต่อและแสดงโฟลเดอร์ที่มีอยู่ใน \\ domain.name \ namespace1 หากพวกเขาปิดหน้าต่าง Explorer และพยายามเข้าถึง \\ domain.name \ namespace1 \ อีกครั้งภายในห้านาทีเนื้อหาจะปรากฏขึ้นเกือบจะทันที - ถ้ารอนานกว่าห้านาทีมันจะผ่านการหยุด 1 - 10 วินาทีอีกครั้ง

เมื่อ "ข้างใน" ทุกอย่างเนมสเปซนั้นดีและเร็วมันเป็นเพียงการเชื่อมต่อเริ่มต้นกับเนมสเปซที่ช้า

ความล่าช้าในการเปิดดูดูเหมือนจะส่งผลกระทบต่อทุกรูปแบบของ Windows ที่เราใช้ (Windows 2008 x64 SP2, Windows 2003 R2 x86 SP2, Windows XP Pro x86 SP3) - อาจเป็นเรื่องที่แย่กว่าใน Windows XP / 2003 มากกว่าใน Windows 2008 แต่ฉัน ไม่แน่ใจว่าความแตกต่างไม่ใช่แค่ทางด้านจิตใจ

การเข้าถึงเป้าหมายโฟลเดอร์พื้นฐานจะไม่แสดงความล่าช้าเลยโดยตรง - เช่นหากการเข้าถึง SMB ที่แชร์โดย DFS นั้นถูกเข้าถึงโดยตรง (ข้าม DFS) ดังนั้นจึงไม่มีการหยุดชั่วคราว

ในระหว่างการแก้ไขปัญหาฉันสังเกตเห็นว่า "ระยะเวลาแคช" สำหรับราก DFS ทั้งหมดของเราตั้งไว้ที่ 300 วินาที - 5 นาที ระบุว่านี่เป็นระยะเวลาเท่ากันในการกระตุ้นการหยุดชั่วคราวฉันคิดว่าการแคชนี้มีความสัมพันธ์กันแม้ว่าฉันจะไม่แน่ใจว่าสิ่งใดที่แคชบนไคลเอนต์และดังนั้นสิ่งที่ต้องค้นหาอีกครั้งหลังจากผ่านไป 5 นาที

ในการพยายามแก้ไขปัญหาฉันได้ลอง / ตรวจสอบสิ่งต่อไปนี้ (ไม่สำเร็จ):

• เรียกใช้ dcdiag บนทั้ง Domain Controllers - ไม่พบปัญหา
• เสร็จสิ้นการตรวจสอบเซิร์ฟเวอร์ DNS พื้นฐานโดยไม่พบปัญหาใด ๆ - ฉันไม่รู้วิธีตรวจสอบเซิร์ฟเวอร์ DNS โดยละเอียด แต่ฉันจะเพิ่มว่าเครือข่ายไม่แสดงพฤติกรรมแปลก ๆ ที่อาจชี้ไปที่ปัญหา DNS
• ปิดใช้งานโปรแกรมป้องกันไวรัสบนไคลเอนต์และเซิร์ฟเวอร์
• ลบหนึ่งในเซิร์ฟเวอร์ namespace จากสอง namespaces - ไม่แตกต่างกัน

นั่นคือสิ่งที่ฉันทำ - และฉันไม่มีความคิด ใครช่วยแนะนำสิ่งที่อาจทำให้เกิดความล่าช้าและ / หรือสิ่งที่ฉันควรจะลองต่อไป?

ในที่สุดเราก็ดูเหมือนจะแก้ไขปัญหานี้ในสภาพแวดล้อมของเรา เพื่อประโยชน์ของผู้อื่นนี่คือสิ่งที่เราค้นพบและวิธีที่เราแก้ไขปัญหา:

ในการลองและรับข้อมูลเชิงลึกเพิ่มเติมเกี่ยวกับสิ่งที่เกิดขึ้นก่อน / ระหว่าง / หลังความล่าช้าเราใช้ Wireshark บนเครื่องไคลเอ็นต์เพื่อจับ / วิเคราะห์ปริมาณการใช้เครือข่ายในขณะที่ลูกค้ารายนั้นพยายามเข้าถึงการแบ่งปัน DFS

การจับภาพเหล่านี้แสดงให้เห็นถึงสิ่งที่แปลก: เมื่อใดก็ตามที่ความล่าช้าเกิดขึ้นในระหว่างคำขอ DFS ที่ถูกส่งจากลูกค้าไปยัง DC และการอ้างอิงไปยังเซิร์ฟเวอร์ราก DFS กลับมาจาก DC ไปยังไคลเอนต์ DC กำลังส่งชื่อออกอากาศหลายชื่อ การค้นหาเครือข่าย

อันดับแรก DC จะออกอากาศการค้นหา NetBIOS สำหรับ DOMAIN (โดยที่ DOMAIN เป็นชื่อโดเมน pre-Windows 2000 Active Directory ของเรา) ไม่กี่วินาทีต่อมามันจะออกอากาศการค้นหาLLMNRสำหรับ DOMAIN สิ่งนี้จะตามมาด้วยการค้นหาการออกอากาศของ NetBios อีกครั้งสำหรับ DOMAIN หลังจากการค้นหาทั้งสามนี้ได้รับการเผยแพร่ (และฉันถือว่าหมดเวลา) DC จะตอบกลับไปยังไคลเอนต์ด้วยการอ้างอิง (ถูกต้อง) ไปยังเซิร์ฟเวอร์รากของ DFS

การค้นหาชื่อบรอดคาสต์เหล่านี้สำหรับ DOMAIN จะถูกส่งเมื่อเกิดความล่าช้าอย่างยาวนานในการเปิดการแชร์ DFS และเราสามารถเห็นได้อย่างชัดเจนจากการจับ Wireshark ว่า DC ไม่ส่งคืนการอ้างอิงไปยังเซิร์ฟเวอร์รูท DFS จนกว่าการค้นหาทั้งสามจะถูกส่ง และ ~ 7 วินาทีผ่านไป) การค้นหาชื่อออกอากาศเหล่านี้ค่อนข้างชัดเจนว่าเป็นสาเหตุของความล่าช้าของเรา

ตอนนี้เรารู้ว่าปัญหาคืออะไรเราเริ่มพยายามหาสาเหตุที่การค้นหาชื่อออกอากาศเหล่านี้เกิดขึ้น หลังจาก Googling และการทดลองและข้อผิดพลาดอีกเล็กน้อยเราพบคำตอบของเรา: เราไม่ได้ตั้งค่า DfsDnsConfig รีจิสตรีคีย์ในตัวควบคุมโดเมนของเราเป็น 1 ตามที่จำเป็นเมื่อใช้ DFS ในสภาพแวดล้อม DNS เท่านั้น

เมื่อแรกเริ่มเราตั้งค่า DFS ในสภาพแวดล้อมของเราเราได้อ่านบทความต่าง ๆ เกี่ยวกับวิธีการกำหนดค่า DFS สำหรับสภาพแวดล้อม DNS เท่านั้น (เช่นMicrosoft KB244380และอื่น ๆ ) และทราบถึงคีย์รีจิสทรีนี้ ใช้มัน.

KB244380 พูดว่า:

ต้องเพิ่มรีจิสตรีคีย์ DFSDnsConfig ในแต่ละเซิร์ฟเวอร์ที่จะเข้าร่วมใน DFS namespace เพื่อให้คอมพิวเตอร์ทุกเครื่องเข้าใจชื่อที่ผ่านการรับรองโดยสมบูรณ์

เราคิดว่านี่หมายความว่าต้องมีการตั้งค่าคีย์รีจิสทรีบนเซิร์ฟเวอร์ namespace DFS เท่านั้นโดยไม่ทราบว่าจำเป็นต้องมีตัวควบคุมโดเมนด้วย หลังจากที่เราตั้งค่า DfsDnsConfig เป็น 1 บนตัวควบคุมโดเมนของเรา (และเริ่มบริการ "DFS Namespace" ใหม่) ปัญหาจะหายไป

เห็นได้ชัดว่าเรามีความสุขกับผลลัพธ์นี้ แต่ฉันจะเพิ่มว่าฉันยังไม่มั่นใจ 100% ว่านี่เป็นปัญหาเดียวของเรา - ฉันสงสัยว่าการเพิ่ม DfsDnsConfig = 1 ไปยัง DCs ของเราทำงานได้เฉพาะปัญหาแทนที่จะแก้ไขมัน . ฉันไม่สามารถเข้าใจได้ว่าเหตุใด DCs จึงพยายามค้นหา DOMAIN (ชื่อโดเมนเองแทนที่จะเป็นเซิร์ฟเวอร์ในโดเมน) ในระหว่างกระบวนการอ้างอิง DFS แม้ในสภาพแวดล้อมที่ไม่ใช่ DNS เท่านั้นและฉันก็รู้ว่า ยังไม่ได้ตั้งค่า DfsDnsConfig = 1 บนตัวควบคุมโดเมนในสภาพแวดล้อม DNS อย่างเดียว (เล็กกว่า / ง่ายกว่า) อื่น ๆ (ยอมรับน้อยกว่ามาก) และไม่ได้มีปัญหาเดียวกัน ถึงกระนั้นเราได้แก้ปัญหาของเราแล้วเราจึงมีความสุข

ฉันหวังว่านี่จะเป็นประโยชน์กับคนอื่น ๆ ที่กำลังประสบปัญหาที่คล้ายกัน - และขอขอบคุณอีกครั้งสำหรับผู้ที่ให้คำแนะนำตลอดทาง

ซึ่งอาจเกิดจากการสั่งซื้อ netmask เซิร์ฟเวอร์ DNS เราเจอสิ่งนี้เมื่อเร็ว ๆ นี้ใน Server 2003 ขึ้นอยู่กับเครือข่ายย่อยปัจจุบันของคุณ

ตัวอย่าง.

ไซต์ 1: IP ซับเน็ต 10.0.0.0/24 ไซต์ 2: IP ซับเน็ต 10.0.1.0/24

ไคลเอนต์ในไซต์ 2 สร้างแบบสอบถาม DNS สำหรับเนมสเปซที่อิงกับโดเมนของคุณและจะได้รับเซิร์ฟเวอร์ DFS ในไซต์ 1 โดยค่าเริ่มต้นเนื่องจากเซิร์ฟเวอร์ DNS ไม่ทราบขอบเขตของไซต์ IP คุณต้องบอกเซิร์ฟเวอร์ DNS ของคุณว่า subnet mask ใช้เพื่อระบุที่อยู่ IP ที่จะตอบกลับ

ดูhttp://support.microsoft.com/kb/842197

บล็อกทีม Active Directory มีบทความสามส่วนทั้งหมดเกี่ยวกับความล่าช้าของ DFS

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

ครอบคลุมพื้นฐานในกระบวนการอ้างอิงจากนั้นแสดงวิธีการใช้เครื่องมือต่าง ๆ รวมถึง dfsUtil และ dfsDiag เพื่อค้นหาสาเหตุที่แท้จริงของความล่าช้า

มันช่วยให้ฉันพบปัญหาของฉัน ซึ่งกลายเป็นว่าไม่มีสิทธิ์อ่านในไดเรกทอรีแชร์สำหรับผู้ใช้โดเมน

HTH ดาเนียล

มีกลิ่นเหมือนปัญหา DNS แต่มีอะไรเกิดขึ้น ฉันชอบ FRS แบบเก่ามากเพราะเครื่องมือวินิจฉัยอย่าง Ultrasound มีประโยชน์มาก: 7

คุณได้รับอะไรในบันทึกเหตุการณ์การจำลองแบบ DFS บนเป้าหมายหรือไม่ (รายงานสุขภาพ DFS จะดึงคำเตือนจากบันทึกเหตุการณ์)

การทำงานโดยไม่ต้องใช้ WINS นั้นเป็นเป้าหมายที่ดีและน่าชื่นชมแม้ว่าฉันจะใช้ระบบปฏิบัติการวินโดวส์รุ่นก่อนหน้านี้ / Vista / 2008 เพราะสิ่งต่าง ๆ ไม่ได้ทำงานอย่างที่คาดไว้ ไม่ควรสำคัญ

ไคลเอนต์แคชการอ้างอิง DFS เช่นเมื่อคุณป้อน \ domain.name \ namespace มันจะแคชเซิร์ฟเวอร์ domain.name จริงที่อ้างถึง เมื่อการอ้างอิงหมดอายุจากแคชไคลเอนต์จะต้อง "ค้นพบ" โทโพโลยี DFS ของคุณอีกครั้งดังนั้นความล่าช้า

ดูที่นี่: http://technet.microsoft.com/en-us/library/cc758234(WS.10).aspxและที่นี่http://blogs.technet.com/filecab/archive/2006/01/20 /417832.aspxสำหรับข้อมูลเพิ่มเติมเกี่ยวกับวิธีการทำงาน

การแก้ปัญหาที่เป็นไปได้? วิธีแฮ็กไปเกี่ยวกับมันอาจจะเขียนโปรแกรมขนาดเล็กที่ "รักษา" ทุก ๆ สองสามนาที; เช่นโปรแกรม C ที่ fopen เป็นไฟล์แรกที่ค้นพบและ fclose ทันที ฉันไม่ได้ลองหรือทดสอบสิ่งนี้และคุณจะต้องพิจารณาอย่างรอบคอบหากคุณกำลังจะทำ

เรามีปัญหาการทำให้เกิดเสียงคล้ายกันซึ่งผู้ใช้จะได้สัมผัสกับความล่าช้า (ไม่เกินหนึ่งนาที) ระหว่างการคลิกที่ไดรฟ์ที่แมปกับการแชร์ DFS และสามารถดูและเรียกดูโฟลเดอร์ภายในการแบ่งปัน

ผู้ใช้ยังมีไดรฟ์ภายในบ้านที่แมปกับการแบ่งปัน DFS ที่แตกต่างกันบนไดรฟ์ข้อมูลเดียวกันและไม่มีความล่าช้าเมื่อเข้าถึงโฟลเดอร์ที่นั่น

ความแตกต่างระหว่างทั้งสองคือการเข้าถึงการแจงนับ (ABE) - ส่วนแบ่งปัญหามีการเปิดใช้งานนี้ (เป็นไดรฟ์ทั่วไปสำหรับผู้ใช้ที่มีหลายพันโฟลเดอร์ - ABE หมายถึงผู้ใช้เห็นเฉพาะโฟลเดอร์ที่พวกเขามีสิทธิ์)

การปิดใช้งาน ABE จะลบปัญหาโดยสิ้นเชิง เห็นได้ชัดว่านี่ไม่ใช่วิธีแก้ปัญหาในขณะที่ผู้ใช้เห็นโฟลเดอร์ทั้งหมดทำให้พวกเขาสับสน ฉันจำลอง DFS ที่ใช้ร่วมกันไปยังเซิร์ฟเวอร์ที่มีดิสก์สำรองบางส่วนเป็นมาตรการชั่วคราวและแม้ว่าจะเปิดใช้งาน ABE สำหรับเป้าหมายใหม่นี้ความล่าช้าก็หายไป

เซิร์ฟเวอร์ที่มีปัญหาคือ 2k3R2 และมีเวลาใช้งานมากกว่า 150 วัน (!) ดังนั้นจึงจะเริ่มต้นระบบใหม่และให้ CHKDSK ทำงานในปริมาณที่ละเมิด ฉันจะโพสต์กลับที่นี่ถ้าสิ่งนี้สร้างความแตกต่างให้กับปัญหา เป้าหมายใหม่อยู่บนเซิร์ฟเวอร์ 2k8

dfsutil / spcflush และ dfsutil / pktflush สามารถเป็นโซลูชันได้เช่นกันในเครือข่ายหลายไซต์ตรวจสอบให้แน่ใจว่าลิงก์ DFS ของเว็บไซต์บ้านกำลังมาในรูปแบบโลคัลเซิร์ฟเวอร์ไม่ใช่จากแคช

ฉันรู้ว่าโปสเตอร์ดั้งเดิมไม่ได้ใช้ WINS แต่ฉันกำลังโพสต์เพื่อผลประโยชน์ของผู้อื่นเนื่องจากเราใช้โพสต์นี้มากที่สุดเพื่อช่วยแก้ปัญหาที่คล้ายกันมาก สำหรับเราแล้วการเป็นคนตัดสินใจที่จะตั้งชื่อเวิร์กสเตชันด้วยชื่อเดียวกันกับโดเมน ดังนั้นทุกครั้งที่ DC ทำการค้นหาชื่อโดเมนสำหรับการอ้างอิง DFS มันต้องการที่จะแก้ไขไปยังเวิร์กสเตชันนั้นและจะทำให้เกิดการหน่วงเวลาหลายวินาทีจำนวนมาก 20 รายการแบบคงที่ถูกวางไว้ใน WINS ที่ชี้ไปที่ DC และสิ่งนี้ได้แก้ไขปัญหาแล้ว หากคุณไม่มี WINS คุณสามารถทดลองวางชื่อโดเมนเป็นชื่อเครื่องในไฟล์ LMHOSTS ที่ชี้ไปที่ DC เพื่อรับการค้นหา 20 และกำหนดลำดับความสำคัญเพื่อให้ LMHOSTS เป็นที่แรกที่มองหาการแก้ไขชื่อ netbios

http://technet.microsoft.com/en-us/library/cc780950(v=ws.10).aspx หน้านี้กล่าวถึงทั้ง Domain Controllers และ DFSN หากเป็นเช่นนั้น

ตัวควบคุมโดเมน DFS และรายการรีจิสทรีของเซิร์ฟเวอร์ราก

รายการรีจิสทรีต่อไปนี้อยู่ภายใต้

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs 

บนเซิร์ฟเวอร์รากและตัวควบคุมโดเมน รายการทั้งหมดคือ REG_DWORD

ดังนั้นฉันจึงใช้บทความนี้ในการค้นหาของฉัน ฉันตั้งค่าทุกอย่างและยังคงมีปัญหา หลังจากใช้เวลาหลายวันในการตรวจสอบปัญหาและไม่รวมทุกอย่าง 'Microsoft' ฉันเดาว่ามันเกี่ยวข้องกับเครือข่าย ปรากฎว่าตัวเร่งความเร็ว WANของเราเป็นปัญหา ฉันให้คนในเครือข่ายของเราปิดการเร่งความเร็วสำหรับ Domain Controllers ของเราและทุกอย่างก็ดีขึ้น

มีผู้ควบคุมจำนวนมากดังนั้นสคริปต์ ( dnsdfs.cmd servername):

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

คุณพูดถึงว่าคุณมีเซิร์ฟเวอร์ 20 DFS ที่ยังไม่ได้กล่าวถึงหากเซิร์ฟเวอร์ทั้งหมดอยู่ในสถานที่เดียวกัน

หากเซิร์ฟเวอร์เหล่านี้ไม่ได้อยู่ในสถานที่เดียวกันและแต่ละเว็บไซต์อื่นมีโดเมนเป็นของตัวเองคุณอาจต้องตรวจสอบให้แน่ใจว่าได้เปิดใช้งานความล้มเหลวของไคลเอ็นต์

สำหรับผู้ที่จบลงที่นี่ผ่านการค้นหาของ Google และผู้ที่มีปัญหาเดียวกัน ...

ก่อนอื่นให้ตรวจสอบว่าลิงก์ทั้งหมดใน Namespace ของคุณนั้นพร้อมใช้งานและดีหรือไม่ นั่นคือสิ่งที่เกิดขึ้นในกรณีของฉันยังคงมีลิงก์ในเนมสเปซไปยังเซิร์ฟเวอร์ที่หยุดทำงานดังนั้นการหยุด DNS ที่เปิดชั่วคราวเนื่องจากการค้นหาเซิร์ฟเวอร์นั้นและล้มเหลว เมื่อฉันปิดการใช้งานลิงค์นั้นใน DFS การหยุดไปนานก็หายไป

ตรวจสอบว่ากลุ่มผู้ใช้ที่มีการรับรองความถูกต้องมีสิทธิ์เข้าถึงรายการเนื้อหาของไดเรกทอรีรากที่คุณถูกแมป ตัวอย่างเช่นถ้าไดรฟ์ x: ถูกแมปกับ \ domain.local \ Departents \ Marketing ผู้ใช้จะต้องได้รับอนุญาตรายการสำหรับ \ domain.local \ แผนก ใน 2008/2012 คุณสามารถระบุภายใต้การอนุญาตขั้นสูงที่ใช้กับ "โฟลเดอร์นี้เท่านั้น" เพื่อให้พวกเขาไม่ได้รับอนุญาตให้แสดงรายการเนื้อหาของโฟลเดอร์ย่อยใด ๆ ที่อาจมีการสืบทอดสิทธิ์