Стоит ли рассматривать Branch Cache как замену DFS-R?

У нас есть небольшой офис-заглушка, который в настоящее время имеет контроллер домена с одним сервером 2003, и копию хранилища файлов DFS-R, хранящуюся в нашем главном офисе. Мы, вероятно, копируем около 100 ГБ данных, я бы предположил, что максимум 20 ГБ активно используется на обоих концах. У нас есть (относительно) медленные ADSL-ссылки между сайтами.

Репликация в основном работает довольно хорошо для нас, за исключением случаев, когда мы вносим изменения в безопасность некоторых реплицируемых файлов. - это приводит к огромному отставанию от изменений, которые, по-видимому, занимают несколько дней. Я читал некоторые другие сообщения о проблемах, а также о новой функции Branch Cache, которую может предложить Windows 7 & Server 2008 R2, и, насколько я понимаю, плюсы и минусы заключаются в следующем:

Ветка кеша

Pros

• Нет конфликтов версий
• Быстрый доступ для последующего доступа

Cons

• Медленный доступ для первого доступа
• Медленный доступ к записи

DFSR

Pros

• Быстрый доступ для чтения / записи данных в любое время
• Ограниченный объем дополнительной безопасности данных

Cons

• Бэклоги могут возникнуть очень легко
• Конфликты версий могут быть проблемой с задержками
• Репликация может занять слишком много времени - не подходит для доступа к файлам между офисами в режиме реального времени.

Кто-нибудь проверял ветку кеша? Мне интересно, если вы знаете, насколько хорошо работает кеш веток в реальном мире? Будет ли это лучше, чем DFSR для нашей установки? Я полагаю, что это может быть очень полезно, если бы я мог предварительно извлекать порции данных (я думаю, я мог бы сделать это вручную с помощью robocopy и удаления!). Единственное, что меня беспокоит, это то, что запись данных будет медленной.

Я также рассматривал возможность внедрения sharepoint в нашем главном офисе. Я думаю, что это может быть просто в пользу Branch Cache.

Очевидно, что если бы я решил использовать кеш веток, он должен был бы пройти тестирование, но я просто хотел узнать, не хватает ли мне каких-либо других плюсов или минусов, которые могли бы убедить меня так или иначе?

Вероятно, я бы сохранил наше развернутое программное обеспечение AD в виде репликации DFS-R и, возможно, даже пользовательских данных (например, домашних каталогов и профилей), иначе записи наверняка вызовут задержки на клиентах?

Похоже, что BranchCache может вам подойти, хотя вы также можете извлечь выгоду из некоторых улучшений производительности в DFS-R, сделанных в Server 2008 и Server 2008 R2.

Были написаны некоторые примеры использования BranchCache, которые могут рассказать вам больше о производительности BranchCache в реальном мире. Просто выполните поиск по запросу "BranchCache".

BranchCache старается всегда соблюдать самые последние настройки контроля доступа для любой части содержимого (файла, веб-страницы ...). Прежде чем клиентский компьютер сможет загрузить данные из кэша в филиале (либо на сервере размещенного кэша, либо на одноранговом узле), он должен получить идентификаторы содержимого с сервера главного офиса. Если у клиента нет разрешения на доступ к данным, сервер главного офиса не будет отправлять идентификаторы. Существует множество документов, объясняющих, как это работает на branchcache.com.

При желании вы можете предварительно загрузить кэш BranchCache, если один из клиентов в филиале (или фактический сервер размещенного кэша) получит доступ к данным заранее. Это может быть сценарием в некоторых случаях, если вы хотите предварительно загрузить кэш, прежде чем рабочие войти.

Если вы собираетесь сохранить сервер в филиале и собираетесь выполнить обновление до R2, нет никаких причин, по которым вы не можете развернуть комбинацию BranchCache и DFS-R. Один блок может одновременно выполнять роль точки репликации DFS-R и сервера размещенного кэша. Таким способом вы можете оптимизировать sharepoint и SMB, и, распределив ваши данные по двум технологиям, вы сможете получить лучшие свойства каждого из них для ваших различных категорий данных.

Надеюсь, это поможет! Тайлер