Windows Server 2012 Branchcache или DFS-R


8

Предупреждение, субъективный вопрос впереди! Но, надеюсь, хороший , который не будет закрыт.

СЦЕНАРИЙ:

У меня есть филиал, который в настоящее время не имеет локального сервера. Они получают доступ ко всему, включая DC через канал WAN 12 Мбит / с (MPLS). Ссылка не насыщена, в среднем около 20% использования. Схема очень стабильна и имеет высокий SLA и отличное время безотказной работы.

Однако передача больших файлов (в основном чтение, а не запись) с файлового сервера через глобальную сеть может быть медленной. В настоящее время мы не используем DFS.

ИССЛЕДОВАНИЕ СДЕЛАНО:

Мне известно об ускорении WAN, например, с использованием выделенного аппаратного обеспечения (Riverbed) или выделенной программной виртуальной машины (Silver Peak). Но ценообразование выходит за рамки нашего текущего бюджета, и с нашей точки зрения пока нет необходимости (поскольку проблема в основном в сценарии «тянуть», а вовсе не в том, что «тянуть / тянуть»).

В основном я рассматриваю развертывание сервера Windows в этом филиале и использование DFS-R или BranchCache. Глядя на сравнение таблиц и предполагая, что мы смотрим на «размещенный сервер BranchCache», а не просто распределенный:

введите описание изображения здесь

Казалось бы, есть преимущества для обоих, даже если оба «размещены» на сервере.

ВОПРОСЫ, которые у меня на самом деле есть:

  • В каких сценариях сияет каждая из этих техник и где вы выбираете одну над другой?
  • Рассматривая размещенный сервер Branchcache, можете ли вы установить «предварительную выборку» определенных папок / файлов на центральном файловом сервере, чтобы они были немедленно доступны локально в филиале? Нужно ли делать это по расписанию (если это возможно)?
  • Глядя на DFS-R, моя проблема (и, по-видимому, решаемая сторонними приложениями) заключается в блокировке файла и обеспечении правильного обновления файла во время операции записи (т. Е. Проверки того, что обе копии доступны и обе записаны, какой файл занимает приоритет и что происходит с изменениями?). В идеале может показаться, что нужно заблокировать любые альтернативные копии данных, но действительно ли это большая проблема?
  • Запирает ли Branchcache центральный файл для редактирования?
  • Branchcache только передает дельты обратно в центральный файл того, что изменилось?
  • Будет ли плохая технология, если сервер филиала будет использоваться в качестве контроллера домена?

Ответы:


4

BranchCache доступен только для чтения и не выполняет предварительную кеширование. Он в основном используется для таких вещей, как распространение обновлений и т. Д. - это CACHE.

DFS не блокирует. НЕТ гибкой технологии WAN делает блокировку, потому что блокировка невозможна, если / когда канал WAN выходит из строя - так что это либо устойчивость, либо блокировка.

Если вам нужна версионность / блокировка для правильной работы, вы можете использовать только центральный сервер. BranchCache в этот момент МОЖЕТ помочь со скоростью загрузки для ПОВТОРНЫХ загрузок. Только.

Если у вас нет ни одного - т.е. вам нужно делать много обновлений из многих мест (что является довольно необычным сценарием - в большинстве случаев файлы не блокируются, как в компаниях), тогда вам придется платить за большую пропускную способность, когда необходимость возникает. Или вы можете использовать какой-то элемент DFS-R сторонней организации, но тогда у вас есть ДРУГАЯ проблема ... которая гарантирует, что пропускная способность не уменьшится, реплицируя тонны неиспользуемого материала, потому что DFS-Replication полностью располагается вдоль линий общего доступа к файлам, а не элемент по запросу.

Это действительно сценарий «Черт побери, черт, если нет». Особенно с локальной сетью (высокая задержка, определенная ненадежность) на месте.

BranchCache работает, например, как кэш обновлений - нет необходимости иметь локальный сервер WSUS в филиале. Блокировка отсутствует, так как это чистый механизм кэширования - вы не можете редактировать файл BranchCache. Тем не менее, поскольку нет блокировки, запись блокирует файл CENTRAL - и обновленная версия затем распространяется, так что это может на самом деле работать для вас;)

DFS отлично подходит только для чтения (установочные образы, образы программного обеспечения для установки, документы политики, которые редактируются централизованно и т. Д.). Довольно забавно, что большинство файлов, которые у меня есть, попадают в эту категорию - материал, который мы здесь редактируем, в основном находится в центральном sotrages с другими технологиями синхронизации (управление документами sharepoint). DFS - отличное техническое решение для технических задач репликации.

http://pertorben.wordpress.com/2012/05/29/dfs-r-or-branchcache/

имеет очень хорошее углубленное объяснение.

BranchCache может сработать .... он не остановит задержку при загрузке, но будет обрабатывать повторные чтения. Это также позволяет блокировку.


Редактировать: После другой проверки, похоже, что предварительная загрузка теперь возможна. Пожалуйста, обратитесь к

http://technet.microsoft.com/en-us/library/jj127252.aspx


Спасибо TomTom. В статье говорится, что «DFS-R будет иметь полную копию всех файлов, и после начальной синхронизации при настройке DFS-R только измененные файловые блоки будут пересекать WAN снова» - один из моих вопросов был о том, как BranchCache сохраняет любые обновления. Должен ли он передавать полный файл обратно на центральный сервер для записи или только изменения?
TheCleaner

technet.microsoft.com/en-us/library/jj127252.aspx - 2012: небольшие изменения в больших файлах приводят к экономии полосы пропускания (+ объяснение).
TomTom

Спасибо, еще не посмотрел эту статью. Большая проблема, хотя (по крайней мере для нас), я забыл, что BranchCache требует, чтобы клиент был на Enterprise / Ultimate ... не допускается Pro. Это требует от нас взглянуть на DFS-R или какой-либо другой сторонний вариант.
TheCleaner
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.