Problemas conocidos y mejores prácticas para dispositivos de almacenamiento en caché de archivos: Nasuni, Synology, Morro Data, etc.

Tenemos una serie de clientes que ejecutan MyWorkDrive como cliente web de acceso remoto y unidad de mapa para archivos almacenados con dispositivos/herramientas de almacenamiento en caché remotas de empresas como Nasuni, Synology y Morro Data.

Con estos, los archivos se almacenan en la nube y se descargan localmente en el dispositivo local cuando el usuario accede a ellos. El servidor MyWorkDrive está conectado a uno de estos dispositivos de almacenamiento en caché locales a través de un recurso compartido CIFS a través de SMB utilizando permisos NTFS.

 

Hay cuatro consideraciones a tener en cuenta al implementar MyWorkDrive con un dispositivo de almacenamiento en caché de archivos de almacenamiento remoto.

1) En general, recomendamos que mantenga el servidor MyWorkDrive junto a un "caché listo" de todos los archivos y documentos disponibles, de esa manera el servidor MyWorkDrive no tiene que esperar a que el documento se descargue de la nube antes de pasarlo al usuario final o hasta Office Online para editar.
​
Los clientes que pueden implementar de esta manera, donde todos los documentos disponibles se almacenan en el dispositivo al que el servidor MyWorkDrive se conecta localmente, informan muchos menos problemas con el rendimiento de los archivos (tiempos de espera, lentitud) que cualquier otra persona que use un dispositivo de tipo de almacenamiento en caché como parte de su solucion

2) Para mantener el rendimiento y la estabilidad, MyWorkDrive tiene una función de tiempo de espera integrada al acceder a recursos compartidos de red. Si el recurso compartido no responde dentro de un tiempo determinado (el valor predeterminado es 2 segundos), MyWorkDrive procede a montar recursos compartidos sin los volúmenes que no responden. Esto evita que el cliente se cuelgue y que el servidor se ralentice mientras espera o intenta servir recursos compartidos de archivos que pueden estar fuera de línea.

Hemos visto un patrón en el que los dispositivos de almacenamiento en caché tienden a "ir a dormir" y necesitan "calentarse" antes de que respondan a las solicitudes de uso compartido de manera oportuna.

Hicimos algunas mejoras específicas en nuestro software para abordar este caso, ya que se presentó como un patrón claro, pero en algunos casos aún puede ser necesario ajustar nuestra configuración de tiempo de espera para evitar que los recursos compartidos no se asignen en el primer acceso después de un período de no uso Comuníquese con nosotros para obtener detalles específicos sobre cómo ajustar la configuración DirectoryExistsMillisecondsTimeout si nota un patrón de necesidad de iniciar sesión dos veces para que los recursos compartidos en los dispositivos de almacenamiento en caché aparezcan en los clientes de MyWorkDrive.

3) Nasuni, en particular, ha mostrado un problema con los inicios de sesión de SSO de AzureAD porque Nasuni no reconocía un UPN (usuario@dominio.ext) y solo aceptaba un nombre de usuario puro. Para solucionar esto, agregamos un parámetro a la configuración de MyWorkDrive para permitir que el dominio nombrado se elimine después de la autenticación y antes de montar recursos compartidos para el usuario.

Los nuevos clientes no han informado de este problema, por lo que es probable que Nasuni actualice sus dispositivos para aceptar UPN para nombres de usuario, pero si se encuentra con una situación con un Nasuni donde los recursos compartidos no se montan después del inicio de sesión de SSO (y la delegación está configurada correctamente!), comuníquese con nosotros para obtener detalles específicos sobre cómo ajustar la configuración de SsoRemoveDomainBeforeImpersonation.

Este caso solo se aplica cuando se usa Nasuni junto con MyWorkDrive que ejecuta Active Directory con un proveedor SAML SSO. Si utiliza MyWorkDrive con Active Directory y los inicios de sesión de usuario a través de User Pass, el ajuste de configuración no debería ser necesario.

Uso del almacenamiento SMB en Nasuni con MyWorkDrive en modo de base de datos de usuario de Entra ID con una conexión de cuenta de servicio SMB no debería requerir ningún ajuste ya que la cuenta de servicio se presenta como usuario/contraseña.

4) Finalmente, hemos experimentado que los dispositivos de caché/sincronización a menudo no manejan bien la sincronización de bloqueos de archivos. Supongamos que un usuario conectado al dispositivo en la sede central abre un documento para editarlo. Se coloca un bloqueo en ese archivo a través de SMB para indicar a otros usuarios que el archivo es de solo lectura y no se puede editar.

Si ese bloqueo no está sincronizado con otras ubicaciones, como un técnico de soporte que viaja o una oficina de campo en otro país, un usuario fuera de la sede podría abrir y editar ese mismo documento y dar como resultado un conflicto que resolver, con la pérdida de sus cambios. o sobrescribir la persona en HQ.

Querrá asegurarse de que su proveedor de dispositivo de caché/sincronización admita la replicación de bloqueos de archivos.

Para Nasuni, hemos notado que el bloqueo de archivo de "lectura" predeterminado aplicado por MyWorkDrive puede no replicarse correctamente, y es posible que la configuración LockFileAccessMode deba cambiarse a ReadWrite. Si está utilizando un Nasuni, pruebe el bloqueo de archivos en sus dispositivos Nasuni. Si no funciona, comuníquese con nosotros para obtener detalles sobre cómo cambiar LockFileAccessMode.

El bloqueo de archivos solo se aplica cuando se utiliza MyWorkDrive en modo Active Directory. Los bloqueos del sistema de archivos externo no se colocan cuando se utiliza MyWorkDrive con una conexión de cuenta de servicio SMB.