Назад | Перейти на главную страницу

«Неправильно» ли мы используем DFS?

Мы компания, имеющая филиалы по всей стране. У нас есть минимум 1 T1 для каждой ветви и максимум 2 T1. У нас есть сервер DFS в каждом филиале и в нашем главном офисе. На прошлой неделе одна особенно проблемная папка с некоторыми из наших пользовательских файлов никогда не имела отставания в 0 файлов. Я скорректировал расписание репликации, чтобы попытаться очистить его, и самое низкое, что мне удалось, - это 1500 файлов для этого конкретного общего ресурса.

Итак, мои вопросы:

Вы, кажется, ответили на свой вопрос здесь. Учитывая большое количество модификаций, которые ваши пользователи вносят в этот общий ресурс, никакие настройки конфигурации DFS не помогут решить эту проблему. Ваш невыполненный журнал зависит от пропускной способности и никогда не будет сброшен до 0, если ваши пользователи вносят изменения быстрее, чем процедура синхронизации может их синхронизировать. Вы можете пересмотреть архитектуру использования DFS в этой настройке. Похоже, что система управления документами / коллективного программного обеспечения для совместной работы может быть лучше здесь, чем попытки запускать все на уровне файловой системы.

Я поддержал вашу точную настройку с 70 сайтами WAN на Windows Server 2003 R2, в основном с T-1. Это сработало отлично. DFSR был нашим методом резервного копирования файлового сервера WAN. Можете ли вы использовать MRTG для мониторинга пропускной способности вашего маршрутизатора T-1, чтобы проверить любые проблемы с пропускной способностью?

Мы использовали MRTG для просмотра графиков использования полосы пропускания и GPO на основе сайта для управления полосой пропускания, используемой для BITS в DFSR. Мы настроили GPO на использование ~ 700 КБ в течение дня и максимальное использование T-1 ночью. Иногда у нас были случаи, когда объем невыполненных журналов увеличивался, и если они никогда не опорожнялись, мы знали, что через мониторинг серверов и MRTG единственный вариант - увеличить пропускную способность. DFSR уже сжат и является блочным, поэтому я не знаю, улучшат ли его другие сторонние решения для репликации данных за пределы площадки (если вы действительно можете показать, что его пропускная способность ограничена).

DFSR в 2008 или 2008 R2 может иметь дальнейшую оптимизацию, поэтому изучите и этот вариант обновления.

В 2008 году вы можете переключиться на использование Branchcache - он не просто слепо копирует все, что изменилось, но поддерживает файлы, которые были открыты в кеше, который обновляется при обновлении центральной копии. Насколько я помню, под 2003 DFS работает как репликатор измененных файлов. Вы меняете 1 байт в файле размером 100 МБ, и он копирует 100 МБ. В 2008 году копируется только 1 байт.

Я удивлен, что вы не видите больше проблем. Несколько лет назад я использовал DFS, но у меня начались проблемы с репликацией около 70 ГБ файлов. После расследования я нашел документ MS, в котором указывалось, что он не поддерживался сверх магической отметки в 50 ГБ. Проблемы включали удаление нереплицированных файлов ... и это в локальной сети, а не в локальной сети.

В Linux есть некоторые распределенные файловые системы и инструменты репликации файлов, но все они будут иметь одни и те же проблемы, если у вас нехватка полосы пропускания.

Другой альтернативой было бы использование ускорителей cifs. Мы используем packeteer (теперь часть bluecoat), и люди могут открывать и редактировать 20-мегабайтные схемы САПР через простой DSL. Время открытия и сохранения разумное.