Problemi noti e best practice per le apparecchiature di memorizzazione nella cache dei file: Nasuni, Synology, Morro Data, ecc

Disponiamo di numerosi client che eseguono MyWorkDrive come client Web di accesso remoto e mappano l'unità per i file archiviati con dispositivi/strumenti di memorizzazione nella cache remota di aziende come Nasuni, Synology e Morro Data.

Con questi, i file vengono archiviati nel cloud e trasferiti localmente sul dispositivo locale quando l'utente vi accede. Il server MyWorkDrive è collegato a uno di questi dispositivi di memorizzazione nella cache locale tramite una condivisione CIFS tramite SMB utilizzando le autorizzazioni NTFS.

 

Ci sono quattro considerazioni da fare quando si distribuisce MyWorkDrive con un dispositivo di memorizzazione nella cache dei file di archiviazione remota.

1) In genere consigliamo di tenere il server MyWorkDrive accanto a una “cache pronta” di tutti i file e documenti disponibili, in questo modo il server MyWorkDrive non deve attendere che il documento venga scaricato dal cloud prima di passarlo al utente finale o fino a Office Online per la modifica.
​
I clienti che sono in grado di eseguire l'implementazione in questo modo, dove tutti i documenti disponibili sono archiviati sull'appliance a cui il server MyWorkDrive si connette localmente, segnalano molti pochi problemi con le prestazioni dei file (timeout, lentezza) rispetto a chiunque altro utilizzi un'appliance di tipo caching come parte di la loro soluzione.

2) Per mantenere le prestazioni e la stabilità, MyWorkDrive dispone di una funzione di timeout integrata quando si accede alle condivisioni di rete. Se la condivisione non risponde entro un certo tempo (l'impostazione predefinita è 2 secondi), MyWorkDrive procede al montaggio delle condivisioni senza i volumi che non rispondono. Ciò impedisce al client di bloccarsi e al server di rallentare in attesa o nel tentativo di servire condivisioni di file che potrebbero essere offline.

Abbiamo osservato uno schema in cui i dispositivi di memorizzazione nella cache hanno la tendenza ad "andare a dormire" e hanno bisogno di "riscaldarsi" prima di rispondere alle richieste di condivisione in modo tempestivo.

Abbiamo apportato alcuni miglioramenti specifici al nostro software per risolvere questo caso, poiché si presentava come uno schema chiaro, ma in alcuni casi potresti comunque ritenere necessario regolare la nostra impostazione di timeout per evitare che le condivisioni non vengano mappate al primo accesso dopo un periodo di non utilizzo. Contattaci per dettagli specifici sulla regolazione dell'impostazione DirectoryExistsMillisecondsTimeout se noti la necessità di accedere due volte per far sì che le condivisioni sui dispositivi di memorizzazione nella cache vengano visualizzate nei client MyWorkDrive.

3) Nasuni, in particolare, ha riscontrato un problema con gli accessi SSO di AzureAD non riusciti perché Nasuni non riconosceva un UPN (utente@dominio.ext) e accettava solo un nome utente puro. Per risolvere questo problema, abbiamo aggiunto un parametro alle impostazioni di MyWorkDrive per consentire la rimozione del dominio denominato dopo l'autenticazione e prima del montaggio delle condivisioni per l'utente.

I nuovi client non hanno segnalato questo problema, quindi è probabile che Nasuni abbia aggiornato i propri dispositivi per accettare gli UPN per i nomi utente, ma se ti imbatti in una situazione con un Nasuni in cui le condivisioni non vengono montate dopo l'accesso SSO (e la delega è impostata correttamente!), contattaci per dettagli specifici sulla regolazione dell'impostazione SsoRemoveDomainBeforeImpersonation.

Questo caso è applicabile solo quando si utilizza Nasuni insieme a MyWorkDrive che esegue Active Directory con un provider SSO SAML. Se si utilizza MyWorkDrive con Active Directory e gli accessi utente tramite User Pass, la regolazione delle impostazioni non dovrebbe essere necessaria.

Utilizzo dell'archiviazione SMB su Nasuni con MyWorkDrive in modalità database utente Entra ID con una connessione all'account di servizio SMB non dovrebbe richiedere alcuna modifica poiché l'account del servizio si presenta come utente/pass.

4) Infine, abbiamo riscontrato che i dispositivi di cache/sincronizzazione spesso non gestiscono bene la sincronizzazione dei blocchi di file. Supponiamo che un utente collegato all'appliance presso la sede centrale apra un documento da modificare. Viene inserito un blocco su quel file tramite SMB per indicare agli altri utenti che il file è di sola lettura e non può essere modificato.

Se il blocco non è sincronizzato con altre posizioni, come un tecnico di supporto in viaggio o un ufficio sul campo in un altro paese, un utente esterno alla sede centrale potrebbe aprire e modificare lo stesso documento e provocare un conflitto da risolvere, con la perdita delle modifiche apportate. o sovrascrivere la persona in HQ.

Ti consigliamo di assicurarti che il fornitore dell'appliance di cache/sincronizzazione supporti la replica dei blocchi di file.

Per Nasuni, abbiamo notato che il blocco predefinito dei file di "lettura" applicato da MyWorkDrive potrebbe non essere replicato correttamente e potrebbe essere necessario modificare l'impostazione LockFileAccessMode in ReadWrite. Se utilizzi un Nasuni, prova il blocco dei file sui tuoi dispositivi Nasuni. Se non funziona, contattaci per i dettagli sulla modifica di LockFileAccessMode.

Il blocco dei file è applicabile solo quando si utilizza MyWorkDrive in modalità Active Directory. I blocchi del file system esterno non vengono applicati quando si utilizza MyWorkDrive con una connessione all'account di servizio SMB.