Câu hỏi: Có cách nào để làm cho 350.000 tệp tồn đọng này hoàn thành nhanh hơn không? Đối với gần như mọi tệp, thay đổi duy nhất là thay đổi ACL cho mỗi tệp bị ảnh hưởng. Một số tệp đã thay đổi nội dung, nhưng đó không phải là trường hợp phổ biến trong tình huống này.
Điều này có thể được sửa chữa. Tôi sẽ chỉnh sửa văn bản này để xác nhận thành công / thất bại sau một khoảng thời gian và xác minh. Đến cuối văn bản câu hỏi này, tôi đã nêu chi tiết những thay đổi được thực hiện gần đây có thể đã sửa nó.
Chúng tôi có một nhóm sao chép DFSR với khoảng 450.000 tệp và chiếm 1,5TB dung lượng. Trong tình huống này, có hai máy chủ Windows Server 2008 R2 có khoảng 500 dặm. Có những máy chủ khác, nhưng họ không tham gia vào nhóm sao chép này. Máy chủ ALPHA là máy chủ chính và là máy chủ được sử dụng bởi hầu hết các nhân viên. Máy chủ BETA là máy chủ trong văn phòng từ xa và ít bận rộn hơn.
Dưới đây là biểu đồ tồn đọng cho nhóm sao chép này (PNG được lưu trữ trên Google Drive) hiển thị tiến trình đồng bộ hóa chậm.
Tôi cần phải xóa một mục cấp phép trong thư mục gốc của nhóm sao chép đó, tất nhiên được kế thừa trên hầu hết các thư mục con. Tôi đã thực hiện thay đổi này trên máy chủ ALPHA. Ngay sau đó, DFSR đã tồn đọng 350.000 tệp. Nó đã được hơn một tuần và bây giờ là ở mức 267.000. Điều duy nhất thay đổi (ban đầu) là thay đổi quyền duy nhất.
Đây là những gì đã xảy ra (đây không phải là giải pháp, chỉ là một lời giải thích khác về những gì đã xảy ra gây ra vấn đề này): http://blogs.technet.com/b/askds/archive/2012/04/14/saturday-mail-sack -bec Because-it-Turn-out-friday-night-was-alright-for-combat.aspx # dfsr
Mọi thay đổi xảy ra trên máy chủ BETA đều được sao chép vào máy chủ ALPHA rất nhanh do không có tồn đọng theo hướng đó. Bất kỳ tệp nào được thay đổi trên BETA đều biến nó thành ALPHA mà không gặp sự cố.
Nó sao chép 24/7 ở tốc độ tối đa trên một kết nối 50Mbps ở một đầu đến 100Mbps sợi ở đầu kia. Khu vực tổ chức là 100GB trên mỗi máy chủ. Không có gì thú vị trong nhật ký sự kiện cả. Có một sự kiện hình mờ cao không liên quan xuất hiện cho một nhóm sao chép không liên quan mà không phải là bản sao cụ thể này cũng không phải cho cặp máy chủ ALPHA / BETA này. Đặc biệt, không có mục nhật ký sự kiện cho hình mờ cao cũng như lỗi kết nối.
Quan điểm của ALPHA về nhóm nhân rộng:
Tiết kiệm băng thông : Giảm 99,83% (nhân rộng 30,85 MB thay vì 18,1 GB)
Tôi tin rằng 30,85 MB / 18,1GB đã xảy ra kể từ lần cuối tôi khởi động lại dịch vụ DFSR trên ALPHA và BETA. Nếu vậy, điều này cho thấy rằng mặc dù phải mất một thời gian rất dài (lâu hơn tôi nghĩ nó sẽ mất) nhưng nó không thực sự chuyển nội dung tệp qua dây.
Thư mục được sao chép : 1.46TB (kích thước thực tế), 439.387 (tệp), 52.886 (thư mục)
Thư mục xung đột và đã xóa : 100.00GB (kích thước được định cấu hình), 34,01GB (kích thước thực tế), 19.620 (tệp), 2.393 (thư mục)
Thư mục dàn : 200.00GB (kích thước được cấu hình), 92.54GB (kích thước thực tế)
Tôi đã gặp một lỗi hình mờ cao trong nhật ký (ngày 14 tháng 5, 7 giờ tối) và do đó đã tăng dung lượng dàn lên 200GB từ 100GB. Tôi biết rằng tuyến đường được Microsoft phê duyệt là tăng 20%, nhưng tôi không chơi xung quanh vấn đề này. Chúng tôi có nhiều không gian đĩa để dành cho các mảng đĩa.
Vô hiệu hóa chống vi-rút trên tất cả các máy chủ không giúp ích gì, mặc dù tôi nghĩ rằng nó sẽ giúp một chút. Hiện tại tôi đã kích hoạt lại phần mềm chống vi-rút nhưng đặt đường dẫn của nhóm sao chép được loại trừ khỏi quá trình quét để xóa biến đó khỏi phương trình.
Có cách nào để có được điều này để đi nhanh hơn? Tôi cũng sẽ thực hiện thay đổi này trên máy chủ BETA, nhưng có những tệp đã thay đổi trên ALPHA nhưng không được sao chép sang BETA và bằng cách thay đổi quyền được thừa kế trên BETA sẽ đẩy các tệp OLD từ BETA sang ALPHA (vì DFSR dường như bỏ qua dấu thời gian của tệp khi so sánh tệp nào là người chiến thắng trong một vụ va chạm). Và có điều đó xảy ra sẽ khá tệ.
Sự tồn đọng đang giảm dần. Rất, rất chậm. Nó đang đi về phía trước, mặc dù. Nhưng với tốc độ này, sẽ mất vài tuần trước khi nó kết thúc. Tôi đang dự tính chỉ cần đẩy một bản sao của dữ liệu được đặt vào ổ đĩa 3TB và chuyển nó đến văn phòng từ xa. Có cách nào tốt hơn?
Ngày 16 tháng 5, 4 giờ sáng, PT Hoa Kỳ: Điều gì có thể đã khắc phục sự cố (dù sao nó cũng đã được khắc phục một cách trung thực):
Tôi đã thực hiện nhiều thay đổi đối với các DC đáng lẽ phải được thực hiện từ lâu. Vấn đề là mạng này được kế thừa từ một người khác có lẽ đã thừa hưởng nó từ người khác, v.v. Tôi không thể hứa thay đổi nào đã khắc phục vấn đề. Ở đây họ không theo thứ tự đặc biệt:
- Tất cả các DC không nằm trong "Bộ điều khiển miền" OU. Tôi chưa bao giờ thấy một tên miền Windows có DC của họ ở nơi khác. Tôi chuyển họ trở lại nơi họ thuộc về. Họ trước đây trong OU đã được tách biệt bởi tên của thành phố mỗi văn phòng là ở. (Tôi có một cảm giác tôi đã có một số công việc hệ thống ống nước để đối phó với bây giờ mà tôi chuyển đó, nhưng tất cả dường như ổn hiện nay ...)
- AVG Anti-Virus đang chạy trên tất cả các máy chủ tham gia DC và DFSR. Tôi đã loại trừ các thư mục được sao chép và các thư mục theo giai đoạn khỏi quá trình quét đang hoạt động / truy cập. Tôi không nghĩ rằng điều này đã khắc phục vấn đề và tôi có thể sẽ kiểm tra vấn đề này sau để xem liệu việc hoàn tác thay đổi đó có ảnh hưởng đến tốc độ sao chép của DFSR hay không. Đó là một thách thức cho một ngày khác.
- dcdiag.exe phàn nàn về vấn đề DNS liên quan đến RODC. Tôi đã khắc phục vấn đề đó mặc dù chúng tôi không có RODC trên miền. Tôi nghi ngờ điều này cố định bất cứ điều gì.
- Một trong các bản ghi _ldap._tcp.domain.GUID._msdcs.DOMAIN.NET SRV bị thiếu đối với một trong các DC (không phải một trong các máy chủ DFSR) và tôi đã khắc phục điều đó. Tôi cũng không nghĩ điều này có ích.
- Một trong những lần tôi khởi động lại máy chủ BETA, nó đã phàn nàn về việc tắt cơ sở dữ liệu DFSR (sự kiện 2212) và sau đó phải tiến hành mất hàng giờ để xây dựng lại cơ sở dữ liệu. Khi hoàn thành nó báo cáo sự kiện 2214 để cho tôi biết nó đã hoàn thành. Sau đó, sao chép vẫn chạy rất chậm, nhưng nó có thể giúp gỡ bỏ mọi thứ bị kẹt.
- Một trong những DC không có 127.0.0.1 làm máy chủ DNS thứ cấp trong cấu hình giao diện của nó. Tôi đã thêm nó. Đây không phải là một trong những máy chủ DFSR, nên có lẽ không liên quan gì đến nó.
- Tôi đã theo dõi Blog TechNet: Điều chỉnh hiệu suất sao chép trong DFSR được đề xuất Cài đặt đăng ký cho máy chủ DFSR. Tôi đã sử dụng tất cả các giá trị "giá trị hiệu suất cao đã kiểm tra" ngoại trừ AsyncIoMaxBufferSizeBytes được đặt thành 4194304, thấp hơn một giá trị so với giá trị cao. Điều này có thể đã giúp với vấn đề ... hoặc có thể không. Thật khó để nói khi một thay đổi quá nhiều biến.
- dcdiag.exe đã phàn nàn về sự cố khi giao tiếp với dịch vụ RPC trên BETA, nhưng chỉ sau khi đã thực hiện các thay đổi trên. Đây dường như là vấn đề rất có thể xảy ra, nhưng tôi không làm gì để sửa nó. VPN đã chạy đúng và tường lửa không chặn nó. Có thể một trong những mục trên là nguyên nhân gây ra và sau đó khắc phục sự cố RPC hoặc đó có thể là sự trùng hợp đơn giản. Tôi hiện không nhận được lỗi đó và hiện tại nhân rộng đang hoạt động trơn tru.
Đạo đức của câu chuyện là: thay đổi từng thứ một hoặc bạn sẽ không bao giờ thực sự biết cái gì đã sửa nó. Nhưng tôi đã tuyệt vọng và sắp hết thời gian để sửa nó, vì vậy tôi chỉ bắn một loạt đạn vào vấn đề. Nếu tôi xác định chính xác bản sửa lỗi, tôi sẽ báo cáo điều đó tại đây. Đừng ngân hàng cho tôi thu hẹp nó, mặc dù.
EDIT 5/21/2012: Tôi đã giải quyết điều này bằng cách lái xe trong khoảng bảy giờ với một máy chủ dự phòng (GAMMA) đến văn phòng từ xa ngày hôm qua. GAMMA hiện đang hoạt động như máy chủ cục bộ chính của họ trong khi máy chủ thông thường (BETA) của họ bắt kịp bản sao. Kể từ khi tôi đặt nó vào vị trí, các máy chủ đã tăng gấp đôi tốc độ sao chép. Mặc dù điều này cho tôi biết đó có thể là một vấn đề liên quan đến VPN, nhưng tôi ít tin rằng đó là vì tất cả các bản cập nhật mới dường như sao chép vào GAMMA từ ALPHA đã rất nhanh chóng và diễn ra tốt đẹp.
EDIT 5/22/2012: Bây giờ là 12000 và sẽ hoàn thành sau vài giờ. Tôi sẽ đăng một biểu đồ đẹp về tiến trình từ bắt đầu chậm đến kết thúc nhanh. Vấn đề là điều duy nhất thực sự "cố định" đó là kết nối máy chủ cục bộ. Hiện tại tôi đang nghĩ rằng có lẽ VPN là một phần của vấn đề. Và nếu đó là trường hợp, tôi cảm thấy rằng câu hỏi này chưa được trả lời. Sau khi tôi có thêm thời gian để kiểm tra xem mọi thứ đang sao chép qua VPN như thế nào và thấy bất kỳ lỗi nào, tôi sẽ gỡ lỗi và báo cáo tiến trình.
Nếu có gì đó thay đổi tôi sẽ cập nhật tại đây.
dfsrdiag replicationstate /acho thấy rằng nó chỉ gửi hai tệp, nhưng cả hai đều có cùng tên tệp. Nó nói rằng dù sao nó cũng có hai kết nối ra tới BETA từ ALPHA. Tệp mà nó đang gửi là 850MB. Như đã trình bày trước đây, tôi không tin rằng nó thực sự gửi nội dung toàn bộ tập tin, mặc dù tôi không chắc chắn những gì nó sẽ làm nếu không muốn nói vì nó mất một thời gian rất dài chỉ để đối phó với một tập tin duy nhất. Tệp được cập nhật lần cuối vào năm 2008 (trên cả hai máy chủ), vì vậy không có lý do gì nó cần phải làm bất cứ điều gì ngoại trừ cập nhật thông tin ACL trên tệp trên BETA.