Windows Server 2012 Branchcache vs.DFS-R


8

Advertencia, pregunta subjetiva por delante! Pero espero que sea una buena que no se cierre.

GUIÓN:

Tengo una sucursal que actualmente no tiene un servidor en las instalaciones. Acceden a todo, incluido un DC a través de un enlace WAN de 12Mbps (MPLS). El enlace no está saturado, con un promedio de utilización de alrededor del 20%. El circuito es muy estable y tiene un alto SLA y un excelente tiempo de actividad.

Sin embargo, las transferencias de archivos grandes (principalmente lecturas, no escrituras) desde el servidor de archivos a través de la WAN pueden ser lentas. Actualmente no utilizamos DFS.

INVESTIGACIÓN REALIZADA:

Soy consciente de la aceleración de WAN, por ejemplo, utilizando hardware dedicado (Riverbed) o una VM de software dedicada (Silver Peak). Pero el precio está fuera de nuestro presupuesto actual y la necesidad aún no está allí desde nuestra perspectiva (ya que el problema se encuentra principalmente en un escenario de "atracción", no necesariamente de inserción / extracción).

Principalmente estoy buscando implementar un servidor de Windows en esta sucursal y utilizar DFS-R o BranchCache. Mirando una comparación de tablas y asumiendo que estamos viendo un "servidor de sucursal alojado" y no simplemente distribuido:

ingrese la descripción de la imagen aquí

Parece que hay beneficios para ambos, incluso si ambos están "alojados" en un servidor.

PREGUNTAS QUE REALMENTE TENGO:

  • ¿En qué escenarios brillan cada uno de estos técnicos y dónde eliges uno sobre el otro?
  • En cuanto a un servidor Branchcache alojado, ¿puede configurar la "recuperación previa" de ciertas carpetas / archivos en el servidor de archivos central para que sean accesibles localmente de inmediato en la sucursal? ¿Tiene que hacer esto en un horario (si es posible)?
  • Al mirar DFS-R, mi preocupación (y aparentemente resuelta con aplicaciones de terceros) es el bloqueo de archivos y asegurarme de que el archivo se actualice correctamente durante una operación de escritura (es decir, asegurarme de que se acceda a ambas copias y se escriban ambas, en qué archivo toma precedencia y qué sucede con los cambios? Lo ideal parece ser bloquear cualquier réplica alternativa de los datos, pero ¿es realmente un problema tan grande?
  • ¿Branchcache bloquea el archivo central para editarlo?
  • ¿Branchcache solo transmite los deltas al archivo central de lo que ha cambiado?
  • ¿Sería desaconsejable cualquiera de las tecnologías si el servidor de la sucursal fuera a utilizarse también como controlador de dominio?

Respuestas:


4

BranchCache es de solo lectura y no guarda en caché. Se utiliza principalmente para cosas como la distribución de actualizaciones, etc., es un CACHE.

DFS no se bloquea. La tecnología NO WAN que es resistente hace el bloqueo porque el bloqueo no es posible si / cuando el enlace WAN se cae, por lo que se trata de resistencia o bloqueo.

Si necesita versionar / bloquear para que funcione correctamente, solo puede usar un servidor central. BranchCache en este momento PUEDE ayudar con la velocidad de descarga para descargas REPETIDAS. Solamente.

Si no tiene ninguno, es decir, necesita hacer muchas actualizaciones desde muchos lugares (que es un escenario bastante inusual, la mayoría de las veces los archivos no están bloqueados de esa manera en las empresas), entonces tiene que pagar por más ancho de banda cuando surge la necesidad O bien, puede usar algún elemento DFS-R de terceros, pero entonces tiene OTRO problema ... que es asegurarse de que el ancho de banda no disminuya replicando toneladas de cosas no utilizadas porque la replicación DFS es totalmente a lo largo de las líneas de intercambio de archivos, no Un elemento bajo demanda.

Esto realmente es un escenario "Maldita sea si lo haces, maldita sea si no lo haces". Especialmente con una LAN (alta latencia, cierta falta de fiabilidad) en su lugar.

BranchCache brilla, por ejemplo, como caché de actualización; no es necesario tener un servidor WSUS local en una sucursal. No hay bloqueo, ya que es un mecanismo de almacenamiento en caché puro: no puede editar un archivo BranchCache. Dicho esto, como no hay bloqueo, una escritura bloqueará el archivo CENTRAL, y la versión actualizada se propagará, por lo que en realidad puede funcionar para usted;)

DFS es ideal para cosas de solo lectura (imágenes de instalación, imágenes de software para la instalación, documentos de políticas que se editan centralmente, etc.). La mayoría de los archivos que tengo pertenecen a esta categoría: la mayoría de los archivos que editamos aquí se encuentran principalmente en almacenes centrales con otras tecnologías de sincronización (gestión de documentos sharepoint). DFS es una excelente solución técnica para las necesidades de replicación técnica.

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

Tiene una muy buena explicación en profundidad.

Es posible que BranchCache funcione ... no detendrá la latencia de descarga única, pero manejará lecturas repetidas. También permite el bloqueo.


Editar: Después de chequear, parece que la precarga ahora es posible. Por favor refiérase a

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


Gracias TomTom En el artículo dice "DFS-R tendrá una réplica completa de todos los archivos y después de la sincronización inicial cuando configure DFS-R, solo los bloques de archivos cambiados volverán a cruzar la WAN", una de mis preguntas fue cómo branchcache guarda cualquier actualización. ¿Tiene que transmitir el archivo completo al servidor central para escribir, o solo los cambios?
TheCleaner

technet.microsoft.com/en-us/library/jj127252.aspx - 2012: pequeños cambios en archivos grandes producen ahorros de ancho de banda (+ explicación).
TomTom

Gracias, no había mirado ese artículo todavía. Sin embargo, un gran problema (al menos para nosotros), había olvidado que BranchCache requiere que el cliente esté en Enterprise / Ultimate ... no se permite Pro. Eso requiere que veamos DFS-R o alguna otra opción de terceros.
TheCleaner
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.