Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
L'archiviazione BLOB supporta ora il protocollo NFS (Network File System) 3.0. Questo articolo contiene raccomandazioni che consentono di ottimizzare le prestazioni delle richieste di archiviazione. Per altre informazioni sul supporto di NFS 3.0 per Archiviazione BLOB di Azure, vedere Supporto del protocollo NFS (NFS) 3.0 per Archiviazione BLOB di Azure.
Aggiungere client per aumentare la velocità effettiva
Archiviazione BLOB di Azure ridimensiona in modo lineare fino a raggiungere il limite massimo di uscita e ingresso dell'account di archiviazione. Di conseguenza, le applicazioni possono ottenere una velocità effettiva maggiore usando più client. Per visualizzare i limiti di uscita e ingresso degli account di archiviazione, vedere Obiettivi di scalabilità e prestazioni per gli account di archiviazione standard.
Il grafico seguente mostra come aumenta la larghezza di banda man mano che si aggiungono altri client. In questo grafico un client è una macchina virtuale e con un account di archiviazione per utilizzo generico v2 standard.
Il grafico seguente mostra lo stesso effetto quando applicato a un account di archiviazione BLOB in blocchi Premium.
Usare account di archiviazione BLOB in blocchi Premium per applicazioni su scala ridotta
Non tutte le applicazioni possono aumentare le prestazioni aggiungendo altri client. Per queste applicazioni, l'account di archiviazione BLOB in blocchi Premium di Azure offre una bassa latenza coerente e tariffe elevate per le transazioni. L'account di archiviazione BLOB in blocchi Premium può raggiungere la larghezza di banda massima con meno thread e client. Ad esempio, con un singolo client, un account di archiviazione BLOB in blocchi Premium può raggiungere una larghezza di banda di 2,3 volte rispetto alla stessa configurazione usata con un account di archiviazione per utilizzo generico con prestazioni standard v2.
Ogni barra del grafico seguente mostra la differenza nella larghezza di banda ottenuta tra gli account di archiviazione delle prestazioni Premium e Standard. Con l'aumentare del numero di client, tale differenza diminuisce.
Migliorare le dimensioni di lettura in avanti per aumentare la velocità effettiva di lettura dei file di grandi dimensioni
Il parametro kernel read_ahead_kb rappresenta la quantità di dati aggiuntivi che devono essere letti dopo aver soddisfatto una determinata richiesta di lettura. È possibile aumentare questo parametro a 16 MiB per migliorare la velocità effettiva di lettura di file di grandi dimensioni.
export AZMNT=/your/container/mountpoint
echo 16384 > /sys/class/bdi/0:$(stat -c "%d" $AZMNT)/read_ahead_kb
Evitare frequenti sovrascrizioni sui dati
Il completamento di un'operazione di sovrascrittura richiede più tempo rispetto a una nuova operazione di scrittura. Ciò è dovuto al fatto che un'operazione di sovrascrittura NFS, in particolare una modifica parziale sul posto, è una combinazione di diverse operazioni BLOB sottostanti: una lettura, una modifica e un'operazione di scrittura. Pertanto, un'applicazione che richiede modifiche frequenti sul posto non è adatta per gli account di archiviazione BLOB abilitati per NFS.
Distribuire Cache HPC di Azure per applicazioni sensibili alla latenza
Alcune applicazioni possono richiedere bassa latenza oltre alla velocità effettiva elevata. È possibile distribuire Cache HPC di Azure per migliorare significativamente la latenza. Altre informazioni sulla latenza nell'archiviazione BLOB.
Aumentare il numero di connessioni TCP
È possibile usare l'opzione nconnect
di montaggio per ottenere prestazioni di lettura e scrittura di aggregazioni più elevate da una singola macchina virtuale, ma solo se il kernel Linux dispone del supporto di Azure nconnect.
nconnect
è un'opzione di montaggio Linux sul lato client che consente di usare più connessioni TCP tra il client e l'endpoint del servizio BLOB. È possibile usare l'opzione nconnect
nel comando di montaggio per specificare il numero di connessioni TCP da creare, ad esempio . mount -t aznfs -o nconnect=16,sec=sys,vers=3,nolock,proto=tcp <storage-account-name>.blob.core.windows.net:/<storage-account-name>/<container-name> /nfsdatain
Importante
Anche se le distribuzioni Linux più recenti supportano completamente nconnect, è consigliabile usare questa opzione solo se il kernel dispone del supporto nconnect di Azure. L'uso dell'opzione di montaggio senza il supporto di Azure nconnect ridurrà la nconnect
velocità effettiva, causerà più timeout e causerà un funzionamento non corretto dei comandi, ad esempio READDIR
e READIRPLUS
.
Il supporto di Azure nconnect è disponibile con la maggior parte dei kernel Ubuntu più recenti che possono essere usati con le macchine virtuali di Azure. Per scoprire se il supporto di Azure nconnect è disponibile per il kernel, eseguire il comando seguente.
[ -e /sys/module/sunrpc/parameters/enable_azure_nconnect ] && echo "Yes" || echo "No"
Se il supporto di Azure nconnect è disponibile per il kernel, Yes
viene stampato nella console. In caso contrario, 'No
viene stampato nella console.
Se il supporto di Azure nconnect è disponibile, abilitarlo eseguendo il comando seguente.
echo Y > /sys/module/sunrpc/parameters/enable_azure_nconnect
Altri consigli sulle procedure consigliate
Usare macchine virtuali con larghezza di banda di rete sufficiente.
Usare più punti di montaggio quando i carichi di lavoro lo consentono.
Usare il maggior numero possibile di thread.
Usare dimensioni di blocchi di grandi dimensioni.
Effettuare richieste di archiviazione da un client che si trova nella stessa area dell'account di archiviazione. Ciò può migliorare la latenza di rete.
Passaggi successivi
Per altre informazioni sul supporto di NFS 3.0 per Archiviazione BLOB di Azure, vedere Supporto del protocollo NFS (NFS) 3.0 per Archiviazione BLOB di Azure.
Per iniziare, vedere Montare l'archiviazione BLOB usando il protocollo NFS (Network File System) 3.0.