Usare l'archiviazione BLOB montata su NFS con Cache HPC di Azure

È possibile usare contenitori BLOB montati su NFS con Azure Cache HPC. Altre informazioni sul supporto del protocollo NFS 3.0 nell'archiviazione BLOB di Azure sono disponibili nel sito della documentazione sull'archiviazione BLOB.

Azure Cache HPC usa l'archiviazione BLOB abilitata per NFS nel tipo di destinazione di archiviazione ADLS-NFS. Queste destinazioni di archiviazione sono simili alle normali destinazioni di archiviazione NFS, ma hanno anche alcune sovrapposizioni con le normali destinazioni BLOB di Azure.

Questo articolo illustra strategie e limitazioni da comprendere quando si usano destinazioni di archiviazione ADLS-NFS.

È anche necessario leggere la documentazione del BLOB NFS, in particolare queste sezioni che descrivono scenari compatibili e incompatibili e forniscono suggerimenti per la risoluzione dei problemi:

• Panoramica delle funzionalità
• Considerazioni sulle prestazioni
• Problemi noti e limitazioni
• Procedura e guida alla risoluzione dei problemi

Comprendere i requisiti di coerenza

Cache HPC richiede una coerenza assoluta per le destinazioni di archiviazione ADLS-NFS. Per impostazione predefinita, l'archiviazione BLOB abilitata per NFS non aggiorna rigorosamente i metadati dei file, che impedisce Cache HPC di confrontare accuratamente le versioni dei file.

Per ovviare a questa differenza, Azure Cache HPC disabilita automaticamente la memorizzazione nella cache degli attributi NFS in qualsiasi contenitore BLOB abilitato per NFS usato come destinazione di archiviazione.

Questa impostazione viene mantenuta per la durata del contenitore, anche se la si rimuove dalla cache.

Pre-caricare i dati con il protocollo NFS

In un contenitore BLOB abilitato per NFS, un file può essere modificato solo dallo stesso protocollo usato al momento della creazione. Ovvero, se si usa l'API REST di Azure per popolare un contenitore, non è possibile usare NFS per aggiornare tali file. Poiché Azure Cache HPC usa solo NFS, non può modificare i file creati con l'API REST di Azure. Altre informazioni sui problemi noti relativi alle API di archiviazione BLOB

Non è un problema per la cache se il contenitore è vuoto o se i file sono stati creati usando NFS.

Se i file nel contenitore sono stati creati con l'API REST BLOB di Azure anziché NFS, Azure Cache HPC è limitato a queste azioni nei file originali:

• Elencare il file in una directory.
• Leggere il file e tenerlo nella cache per le letture successive.
• Eliminare il file .
• Svuotare il file (troncarlo a 0).
• Salvare una copia del file. La copia è contrassegnata come file creato da NFS e può essere modificata tramite NFS.

Azure Cache HPC non può modificare il contenuto di un file creato tramite REST. Ciò significa che la cache non può salvare un file modificato da un client alla destinazione di archiviazione.

È importante comprendere questa limitazione, perché può causare problemi di integrità dei dati se si usano modelli di utilizzo di memorizzazione nella cache di lettura/scrittura nei file non creati con NFS.

Suggerimento

Altre informazioni sulla memorizzazione nella cache di lettura e scrittura sono disponibili in Informazioni sui modelli di utilizzo della cache.

Scenari di memorizzazione nella cache di scrittura

Questi modelli di utilizzo della cache includono la memorizzazione nella cache di scrittura:

• Scritture superiori al 15%
• Scritture superiori al 15%, verificando la presenza di modifiche al server di backup ogni 30 secondi
• Scritture superiori al 15%, verificando la presenza di modifiche nel server di backup ogni 60 secondi
• Scritture superiori al 15%, writeback nel server ogni 30 secondi

I modelli di utilizzo della memorizzazione nella cache di scrittura devono essere usati solo nei file creati con NFS.

Se si tenta di usare la memorizzazione nella cache di scrittura nei file creati da REST, le modifiche al file potrebbero andare perse. Ciò è dovuto al fatto che la cache non tenta di salvare immediatamente le modifiche dei file nel contenitore di archiviazione.

Ecco come provare a memorizzare nella cache le scritture nei file creati da REST comporta un rischio per i dati:

1. La cache accetta modifiche dai client e restituisce un messaggio di esito positivo in ogni modifica.

2. La cache mantiene il file modificato nella risorsa di archiviazione e attende ulteriori modifiche.

3. Dopo un certo periodo di tempo, la cache tenta di salvare il file modificato nel contenitore back-end. A questo punto, verrà visualizzato un messaggio di errore perché sta tentando di scrivere in un file creato da REST con NFS.

   È troppo tardi per indicare al computer client che le modifiche non sono state accettate e la cache non è in grado di aggiornare il file originale. Le modifiche apportate dai client andranno perse.

Leggere gli scenari di memorizzazione nella cache

Gli scenari di memorizzazione nella cache di lettura sono appropriati per i file creati con NFS o l'API REST BLOB di Azure.

Questi modelli di utilizzo usano solo la memorizzazione nella cache di lettura:

• Leggere scritture pesanti e poco frequenti
• I client scrivono nella destinazione NFS, ignorando la cache
• Lettura pesante, controllo del server di backup ogni 3 ore

È possibile usare questi modelli di utilizzo con i file creati dall'API REST o da NFS. Tutte le scritture NFS inviate da un client al contenitore back-end avranno comunque esito negativo, ma non riusciranno immediatamente e restituiranno un messaggio di errore al client.

Un flusso di lavoro di memorizzazione nella cache di lettura può comunque comportare modifiche ai file, purché non vengano memorizzate nella cache. Ad esempio, i client potrebbero accedere ai file dal contenitore, ma scrivere le modifiche come nuovo file oppure salvare i file modificati in un percorso diverso.

Riconoscere le limitazioni di Gestione blocchi di rete (NLM)

I contenitori BLOB abilitati per NFS non supportano Network Lock Manager (NLM), un protocollo NFS comunemente usato per proteggere i file dai conflitti.

Se il flusso di lavoro NFS è stato originariamente scritto per i sistemi di archiviazione hardware, le applicazioni client potrebbero includere richieste NLM. Per ovviare a questa limitazione quando si sposta il processo nell'archiviazione BLOB abilitata per NFS, assicurarsi che i client disabilitino NLM quando montano la cache.

Per disabilitare NLM, usare l'opzione -o nolock nel comando dei mount client. Questa opzione impedisce ai client di richiedere blocchi NLM e ricevere errori in risposta. L'opzione nolock viene implementata in modo diverso in sistemi operativi diversi. Per informazioni dettagliate, vedere la documentazione del sistema operativo client (man 5 nfs).

Semplificare le scritture in contenitori abilitati per NFS con Cache HPC

Azure Cache HPC consente di migliorare le prestazioni in un carico di lavoro che include la scrittura di modifiche in una destinazione di archiviazione ADLS-NFS.

Nota

È necessario usare NFS per popolare il contenitore di archiviazione ADLS-NFS se si desidera modificarne i file tramite Azure Cache HPC.

Una delle limitazioni descritte nell'articolo Considerazioni sulle prestazioni dei BLOB abilitate per NFS è che l'archiviazione ADLS-NFS non è molto efficiente per sovrascrivere i file esistenti. Se si usa Azure Cache HPC con l'archiviazione BLOB montata su NFS, la cache gestisce le riscritture intermittenti quando i client modificano un file attivo. La latenza di scrittura di un file nel contenitore back-end è nascosta dai client.

Tenere presenti le limitazioni descritte in precedenza in Pre-caricamento dei dati con il protocollo NFS.

Passaggi successivi

• Informazioni sui prerequisiti di destinazione dell'archiviazione ADLS-NFS
• Creare un account di archiviazione BLOB abilitato per NFS