Чи варто розглянути кеш філії як заміну DFS-R

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

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

Кеш відділення

Плюси

• Немає конфліктів версій
• Швидкий доступ для подальшого доступу

Мінуси

• Повільний доступ для першого доступу
• Повільний доступ до запису

ДФСР

Плюси

• Швидкий доступ для читання / запису даних до будь-якого часу
• Обмежений обсяг додаткової безпеки даних

Мінуси

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

Хтось перевіряв кеш філії? Мені цікаво, чи знаєте, як добре працює кеш філії в реальному світі? Чи було б краще, ніж DFSR для нашого налаштування? Я думаю, що це може бути дуже корисним, якби мені вдалося заздалегідь отримати шматки даних (я думаю, я міг би це зробити вручну за допомогою роботокопіювання та видалення!). Єдине занепокоєння, яке я маю, - це те, що записування даних буде повільним.

Я також розглядав можливість впровадження sharepoint у нашому головному офісі. Я думаю, що це може просто змінюватися на користь кеша філії.

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

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

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

Про BranchCache написано кілька тематичних досліджень, які можуть розповісти вам більше про ефективність BranchCache в реальному світі. Просто шукайте "Тематичне дослідження BranchCache".

BranchCache обережно завжди вшановує найактуальніші параметри контролю доступу на будь-якому вмісті (файлі, веб-сторінці ...). Перш ніж клієнтський ПК зможе завантажити дані з кешу у відділенні (або на розміщеному кеш-сервері, або на одноранговому), він повинен отримати ідентифікатори вмісту з сервера основного офісу. Якщо клієнт не має дозволу на доступ до даних, сервер основного офісу не надсилатиме ідентифікатори. Існує купа документів, що пояснюють, як це працює на сайті branchcache.com.

Якщо ви хочете, ви можете попередньо завантажити кеш BranchCache, маючи достроково один із клієнтів у відділенні (або фактично розміщеному кеш-сервері) доступ до даних. У деяких випадках це може бути написано сценарієм, якщо ви хочете попередньо завантажити кеш-пам'ять, перш ніж працівники потраплять.

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

Я сподіваюся, що це допомагає! -Тілер