Problemas conhecidos e práticas recomendadas para dispositivos de cache de arquivos - Nasuni, Synology, Morro Data, etc.

Temos vários clientes executando o MyWorkDrive como cliente Web de acesso remoto e unidade de mapa para arquivos armazenados com dispositivos/ferramentas de cache remoto de empresas como Nasuni, Synology e Morro Data.

Com eles, os arquivos são armazenados na nuvem e baixados localmente para o dispositivo local quando acessados pelo usuário. O servidor MyWorkDrive é conectado a um desses dispositivos de cache local por meio de um compartilhamento CIFS via SMB usando permissões NTFS.

Há quatro considerações a serem feitas ao implantar o MyWorkDrive com um dispositivo de armazenamento em cache de arquivos de armazenamento remoto.

1) Geralmente recomendamos que você mantenha o servidor MyWorkDrive próximo a um “cache pronto” de todos os arquivos e documentos disponíveis, assim o servidor MyWorkDrive não precisa esperar o download do documento da nuvem antes de passá-lo para o usuário final ou até o Office Online para edição.
Em
Os clientes que são capazes de implantar dessa maneira, onde todos os documentos disponíveis são armazenados no dispositivo ao qual o servidor MyWorkDrive está se conectando localmente, relatam muito poucos problemas com o desempenho do arquivo - tempos limite, lentidão - do que qualquer outra pessoa que usa um dispositivo do tipo cache como parte de a solução deles.

2) Para manter o desempenho e a estabilidade, o MyWorkDrive possui um recurso de tempo limite integrado ao acessar compartilhamentos de rede. Se o compartilhamento não responder dentro de um determinado tempo (o padrão é 2 segundos), o MyWorkDrive continua montando compartilhamentos sem os volumes que não respondem. Isso evita que o cliente trave e que o servidor fique lento esperando ou tentando servir compartilhamentos de arquivos que podem estar offline.

Vimos um padrão em que os dispositivos de cache têm uma tendência a “ir dormir” e precisam “aquecer” antes de responder às solicitações de compartilhamento em tempo hábil.

Fizemos algumas melhorias específicas em nosso software para resolver esse caso, conforme apresentado como um padrão claro, mas em alguns casos você ainda pode achar necessário ajustar nossa configuração de tempo limite para evitar que os compartilhamentos não sejam mapeados no primeiro acesso após um período de não uso. Entre em contato conosco para obter detalhes específicos sobre como ajustar a configuração DirectoryExistsMillisecondsTimeout se você notar um padrão de necessidade de login duas vezes para obter compartilhamentos em dispositivos de cache para aparecer em clientes MyWorkDrive.

3) Nasuni, em particular, apresentou um problema com a falha de logins SSO do AzureAD porque o Nasuni não reconhecia um UPN (user@domain.ext) e aceitava apenas um nome de usuário puro. Para resolver isso, adicionamos um parâmetro às configurações do MyWorkDrive para permitir que o domínio nomeado seja removido após a autenticação e antes da montagem dos compartilhamentos para o usuário.

Novos clientes não relataram esse problema, portanto, é provável que o Nasuni tenha atualizado seus dispositivos para aceitar UPNs para nomes de usuário, mas se você se deparar com uma situação com um Nasuni em que os compartilhamentos não são montados após o login SSO (e a delegação está definida corretamente! ), entre em contato conosco para obter detalhes específicos sobre como ajustar a configuração SsoRemoveDomainBeforeImpersonation.

Este caso só é aplicável ao usar o Nasuni em conjunto com o MyWorkDrive executando o Active Directory com um provedor SAML SSO. Se estiver usando MyWorkDrive com Active Directory e logins de usuário via User Pass, o ajuste da configuração não deverá ser necessário.

Usando armazenamento SMB no Nasuni com MyWorkDrive no modo de banco de dados de usuário Entra ID com uma conexão de conta de serviço SMB não deve exigir nenhum ajuste, pois a conta do serviço se apresenta como usuário/senha.

4) Por fim, percebemos que os dispositivos de cache/sincronização geralmente não lidam bem com a sincronização de bloqueios de arquivos. Digamos que um usuário vinculado ao appliance na sede abra um documento para editar. Um bloqueio é colocado nesse arquivo via SMB para indicar a outros usuários que o arquivo é somente leitura e não pode ser editado.

Se esse bloqueio não estiver sincronizado com outros locais, como um técnico de suporte em viagem ou um escritório de campo em outro país, um usuário fora da sede poderá abrir e editar esse mesmo documento e resultar em um conflito a ser resolvido, perdendo suas alterações, ou substituindo a pessoa no HQ.

Você deve certificar-se de que o fornecedor do dispositivo de cache/sincronização oferece suporte à replicação de bloqueios de arquivos.

Para Nasuni, observamos que o bloqueio de arquivo de “leitura” padrão aplicado pelo MyWorkDrive pode não ser replicado corretamente e a configuração LockFileAccessMode pode precisar ser alterada para ReadWrite. Se você estiver usando um Nasuni, teste o bloqueio de arquivos em seus dispositivos Nasuni. Se não estiver funcionando, entre em contato conosco para obter detalhes sobre como alterar o LockFileAccessMode.

O bloqueio de arquivos só é aplicável ao usar o MyWorkDrive no modo Active Directory. Os bloqueios do sistema de arquivos externo não são colocados ao usar o MyWorkDrive com uma conexão de conta de serviço SMB.