Descripción del bloqueo (o la falta de bloqueo) de archivos distribuidos en DFSR

En este artículo se analiza la ausencia de un mecanismo de bloqueo de archivos distribuido multi-host dentro de Windows, y específicamente dentro de las carpetas replicadas por DFSR.

Algunos antecedentes

• Bloqueo de archivos distribuido: se refiere al concepto de tener varias copias de un archivo en varios equipos y, cuando se abre un archivo para escribir, se bloquean todas las demás copias. Esto impide que varios usuarios modifiquen un archivo en varios servidores al mismo tiempo.
• Replicación del Sistema de archivos distribuido: DFSR funciona en un diseño basado en estado con arquitectura multimaestro. En la replicación basada en estado, cada servidor del sistema con arquitectura multimaestro aplica actualizaciones a su réplica a medida que llegan, sin intercambiar archivos de registro (en su lugar usa vectores de versión para mantener la información "actualizada"). Ningún servidor es arbitrariamente autoritativo después de la sincronización inicial, por lo que es altamente disponible y muy flexible en varias topologías de red.
• Bloque de mensajes del servidor: SMB es el protocolo común que se usa en Windows para acceder a los archivos a través de la red. En términos simplificados, es un protocolo cliente-servidor que hace uso de un redirector para que los sistemas de archivos remotos parezcan ser sistemas de archivos locales. No es específico de Windows y es bastante común: un ejemplo conocido que no es de Microsoft es Samba, que permite a Linux, Mac y otros sistemas operativos actuar como clientes o servidores SMB y participar en redes de Windows.

Es importante definir claramente dónde residen DFSR y SMB en el entorno de datos replicado. SMB permite a los usuarios acceder a sus archivos y no tiene reconocimiento de DFSR. Del mismo modo, DFSR (mediante el protocolo RPC) mantiene los archivos sincronizados entre servidores y no tiene reconocimiento de SMB. No confunda el bloqueo distribuido tal y como se define en este post y el Bloqueo oportunista.

Aquí es donde las cosas pueden torcerse.

Puesto que los usuarios pueden modificar datos en varios servidores, y puesto que cada servidor Windows solo conoce un bloqueo de archivo en sí mismo, y puesto que DFSR no sabe nada de esos bloqueos en otros servidores, se hace posible que los usuarios sobrescriban los cambios de los demás. DFSR usa un algoritmo de conflicto de "el último que escribe gana", por lo que alguien tiene que perder y la persona que guarde en último lugar se queda con sus cambios. La copia del archivo que pierde se muestra en la carpeta ConflictAndDeleted.

Ahora bien, esto es mucho menos común de lo que a la gente le gusta creer. Normalmente, los verdaderos archivos compartidos se modifican en un entorno local; en la sucursal o en la misma fila de cubículos. Suelen trabajar en ellos personas del mismo equipo, por lo que la gente suele ser consciente de que sus colegas modifican los datos. Y como suelen estar en el mismo sitio, las probabilidades de que todos los usuarios que trabajen en un documento compartido usen el mismo servidor son mucho mayores. Windows SMB controla la situación aquí. Cuando un usuario tiene un archivo bloqueado para su modificación y su compañero de trabajo intenta editarlo, el otro usuario obtendrá un error como:

Y si la aplicación que abre el archivo es realmente inteligente, como Word 2007, puede darle:

DFSR tiene un mecanismo para los archivos bloqueados, pero solo está dentro del propio contexto del servidor. DFSR no replicará un archivo dentro o fuera si su copia local tiene un bloqueo exclusivo. Pero esto no impide que nadie de otro servidor modifique el archivo.

Volviendo al tema, la cuestión de los datos compartidos que se modifican geográficamente existe, y para algunas personas es bastante espinoso. A veces nos preguntan por qué DFSR no controla este bloqueo y se encarga de todo con un movimiento de la varita mágica. Resulta que este es un escenario interesante y difícil de resolver para un sistema de replicación con arquitectura multimaestro. Comencemos a explorar.

Soluciones de terceros

Existen algunas soluciones de proveedores que se hacen cargo de este problema, que suelen abordar mediante uno o varios de los siguientes métodos*:

• Uso de un mecanismo de agente

Tener una "policía de tráfico" central permite que un servidor tenga en cuenta todos los demás servidores y qué archivos han bloqueado los usuarios. Desafortunadamente, esto también significa que a menudo hay un único punto de error en el sistema de bloqueo distribuido.

• Requisito para una red enrutada completamente

Dado que un agente central debe poder comunicarse con todos los servidores que participan en la replicación de archivos, esto elimina la capacidad de controlar topologías de red complejas. Las topologías en anillo y las topologías múltiples de concentrador y radios no suelen ser posibles. En una red no enrutada completamente, es posible que algunos servidores no puedan ponerse en contacto directamente entre sí o con un agente, y solo puedan comunicarse con un asociado que pueda comunicarse con otro servidor, etc. Esto está bien en un entorno de arquitectura multimaestro, pero no con un mecanismo de agente.

• Están limitados a un par de servidores

Algunas soluciones limitan la topología a un par de servidores para simplificar su mecanismo de bloqueo distribuido. Para entornos más grandes, es posible que esto no sea factible.

• Uso de agentes en clientes y servidores
• No usar la replicación con arquitectura multimaestro
• No hacer uso de la agrupación en clústeres de MS
• Hacer uso de dispositivos especializados

* Observe que digo ¡suelen! Rogamos que no publiquen amenazas de muerte porque tengan una solución que aplique o no uno o varios de esos métodos.

Reflexiones más profundas

Al reflexionar más sobre este tema, empiezan a surgir algunas cuestiones fundamentales. Por ejemplo, si tenemos cuatro servidores con datos que pueden modificar los usuarios de cuatro sitios y la conexión WAN a uno de ellos se queda sin conexión, ¿qué hacemos? Los usuarios pueden seguir accediendo a sus servidores individuales, pero ¿deberíamos permitírselo? No queremos que hagan cambios que entren en conflicto, pero sin duda queremos que sigan trabajando y haciendo ganar dinero a nuestra empresa. Si bloqueamos arbitrariamente los cambios en ese punto, ¡ningún usuario podrá trabajar aunque en realidad no haya ningún conflicto! No hay forma de decir a los otros servidores que el archivo está en uso y se vuelve al principio.

Después está el propio SMB y el control de errores de los bloqueos de informes. En realidad, no podemos cambiar la forma en que SMB informa de las infracciones de compartición, ya que romperíamos un montón de aplicaciones y, de todos modos, los clientes no entenderían los nuevos mensajes de error ampliados. Aplicaciones como Word 2007 realizan algunos trucos encubiertos para averiguar quién está bloqueando los archivos, pero la gran mayoría de las aplicaciones no saben quién tiene un archivo en uso (o incluso que SMB existe, en serio). Así que cuando un usuario recibe el mensaje "Este archivo está en uso" no es particularmente procesable... ¿Deberían llamar todos al departamento de soporte técnico? ¿Tiene el departamento de soporte técnico acceso a todos los servidores de archivos para consultar qué usuarios están accediendo a los archivos? Complicado.

Puesto que queremos un sistema con arquitectura multimaestro para una alta disponibilidad, un sistema de agente es menos deseable; puede que necesitemos tener algo funcionando en todos los servidores que les permita a todos comunicarse incluso a través de redes no enrutadas completamente. Esto requerirá técnicas de sincronización muy complejas. Agregará algo de sobrecarga en la red (aunque probablemente no mucha) y tendrá que ser rapidísimo para asegurarnos de que no estamos retrasando al usuario en su trabajo; tiene que superar a la propia replicación de archivos; de hecho, puede que tenga que estar vinculado a la replicación de algún modo. También tendrá que tener en cuenta las interrupciones del servidor relacionadas con la red y no los bloqueos del servidor, de alguna manera.

Y después volvemos a un software cliente especial para este escenario que entiende mejor los bloqueos y puede dar al usuario alguna información útil ("Vaya a llamar a Laura a contabilidad y dígale que libere ese documento", "Lo siento, la topología de bloqueo de archivos está rota y su administrador le impide abrir este archivo hasta que se arregle", etc). Conseguir que esto funcione bien con los millones de aplicaciones que se ejecutan en Windows será definitivamente interesante. Hay muchos sistemas operativos que no serían compatibles ni recibirían el software: Windows 2000 ya no recibe soporte general y XP pronto dejará de recibirlo. Los clientes de Linux y Mac no dispondrían de este software hasta que lo consideraran importante, por lo que el cliente tendría que esperar que sus proveedores fabricaran algo análogo.

Más información

En estos momentos, la forma más sencilla de controlar esta situación en DFSR es usar Espacios de nombres DFS para guiar a los usuarios a ubicaciones predecibles, con un espacio de nombres coherente. Al configurar correctamente la topología de sitio DFSN y los vínculos de servidor, obliga a los usuarios a compartir el mismo servidor local y solo les permite acceder a equipos remotos cuando su servidor "principal" está inactivo. Para la mayoría de los entornos, esto funciona bastante bien. Como alternativa a DFSR, SharePoint es una opción por su sistema de insertar y sacar en repositorios. BranchCache (que llega en Windows Server 2008 R2 y Windows 7) puede ser una opción para usted, ya que está diseñado para facilitar la lectura de archivos en un escenario de sucursales, pero al final los datos autoritativos seguirán viviendo en un solo servidor (más información al respecto aquí). Y de nuevo, esos proveedores tienen sus soluciones.