Massimizzazione del throughput di S3 File Gateway

Le sezioni seguenti descrivono le best practice per massimizzare il throughput tra i client NFS e SMB, S3 File Gateway e Amazon S3. Le indicazioni fornite in ogni sezione contribuiscono in modo incrementale a migliorare il throughput complessivo. Sebbene nessuna di queste raccomandazioni sia obbligatoria e non siano interdipendenti, sono state selezionate e ordinate in modo logico che consente di testare e ottimizzare le implementazioni Supporto di S3 File Gateway. Nell'implementare e testare questi suggerimenti, tieni presente che ogni implementazione di S3 File Gateway è unica, quindi i risultati possono variare.

S3 File Gateway fornisce un'interfaccia di file per archiviare e recuperare oggetti Amazon S3 utilizzando i protocolli di file NFS o SMB standard del settore, con una mappatura 1:1 nativa tra file e oggetto. Implementa S3 File Gateway come macchina virtuale in locale nel tuo ambiente KVM VMware Microsoft Hyper-V o Linux o nel cloud come istanza Amazon. AWS EC2 S3 File Gateway non è progettato per fungere da sostituto completo del NAS aziendale. S3 File Gateway emula un file system, ma non è un file system. L'utilizzo di Amazon S3 come storage backend durevole crea un sovraccarico aggiuntivo per ogni I/O operazione, quindi la valutazione delle prestazioni di S3 File Gateway rispetto a un NAS o un file server esistente non è un confronto equivalente.

Implementa il gateway nella stessa posizione dei tuoi client

Ti consigliamo di implementare l'appliance virtuale S3 File Gateway in una posizione fisica con la minore latenza di rete possibile tra l'appliance e i client NFS o SMB. Quando scegli una posizione per il gateway, considera quanto segue:

• Una latenza di rete inferiore rispetto al gateway può contribuire a migliorare le prestazioni dei client NFS o SMB.

• S3 File Gateway è progettato per tollerare una latenza di rete più elevata tra il gateway e Amazon S3 rispetto a quella tra il gateway e i client.

• Per le istanze S3 File Gateway distribuite in Amazon EC2, consigliamo di mantenere il gateway e i client NFS o SMB nello stesso gruppo di collocamento. Per ulteriori informazioni, consulta i gruppi di posizionamento per le tue EC2 istanze Amazon nella Amazon Elastic Compute Cloud User Guide.

Riduci i colli di bottiglia causati dai dischi lenti

Ti consigliamo di monitorare la IoWaitPercent CloudWatch metrica per identificare i rallentamenti nelle prestazioni che possono derivare dalla lentezza dei dischi di archiviazione sul tuo S3 File Gateway. Quando tenti di ottimizzare i problemi di prestazioni relativi al disco, considera quanto segue:

• IoWaitPercentriporta la percentuale di tempo in cui la CPU è in attesa di una risposta dai dischi root o cache.

• Quando IoWaitPercent è superiore al 5-10%, in genere indica un rallentamento delle prestazioni del gateway causato da dischi con prestazioni insufficienti. Questa metrica dovrebbe avvicinarsi il più possibile allo 0%, il che significa che il gateway non è mai in attesa sul disco, il che aiuta a ottimizzare le risorse della CPU.

• Puoi controllare IoWaitPercent nella scheda Monitoraggio della console Storage Gateway o configurare gli CloudWatch allarmi consigliati per avvisarti automaticamente se la metrica supera una soglia specifica. Per ulteriori informazioni, consulta Creazione di CloudWatch allarmi consigliati per il gateway.

• Per ridurre al minimo i dischi root e cache del gateway, consigliamo di utilizzare uno NVMe o l'SSD. IoWaitPercent

Modifica l'allocazione delle risorse delle macchine virtuali per CPU, RAM e dischi cache

Quando si tenta di ottimizzare il throughput per S3 File Gateway, è importante allocare risorse sufficienti alla macchina virtuale del gateway, tra cui CPU, RAM e dischi di cache. I requisiti minimi di risorse virtuali di CPUs 4,16 GB di RAM e 150 GB di storage nella cache sono in genere adatti solo per carichi di lavoro più piccoli. Quando si allocano risorse virtuali per carichi di lavoro più grandi, si consiglia quanto segue:

• Aumenta il numero allocato tra 16 e 48, CPUs a seconda dell'utilizzo tipico della CPU generato da S3 File Gateway. Puoi monitorare l'utilizzo della CPU utilizzando la UserCpuPercent metrica. Per ulteriori informazioni, consulta Comprendere le metriche del gateway.

• Aumenta la RAM allocata tra 32 e 64 GB.

  Nota

  S3 File Gateway non può utilizzare più di 64 GB di RAM.

• NVMe Utilizzate il nostro SSD per i dischi root e il disco di cache e dimensionate i dischi di cache in modo da allinearli al set di dati di picco che intendete scrivere sul gateway. Per ulteriori informazioni, consulta le best practice di dimensionamento della cache di S3 File Gateway sul canale ufficiale Amazon Web Services YouTube .

• Aggiungi almeno 4 dischi di cache virtuale al gateway, anziché utilizzare un unico disco di grandi dimensioni. Più dischi virtuali possono migliorare le prestazioni anche se condividono lo stesso disco fisico sottostante, ma i miglioramenti sono in genere maggiori quando i dischi virtuali si trovano su dischi fisici sottostanti diversi.

  Ad esempio, se desideri distribuire 12 TB di cache, puoi utilizzare una delle seguenti configurazioni:

  • 4 dischi cache da 3 TB

  • 8 dischi cache da 1,5 TB

  • 12 dischi cache da 1 TB

  Oltre alle prestazioni, ciò consente una gestione più efficiente della macchina virtuale nel tempo. Man mano che il carico di lavoro cambia, è possibile aumentare in modo incrementale il numero di dischi di cache e la capacità complessiva della cache, mantenendo al contempo le dimensioni originali di ogni singolo disco virtuale per preservare l'integrità del gateway.

  Per ulteriori informazioni, vedere Decidere la quantità di storage su disco locale.

Quando distribuisci S3 File Gateway come EC2 istanza Amazon, considera quanto segue:

• Il tipo di istanza scelto può influire in modo significativo sulle prestazioni del gateway. Amazon EC2 offre un'ampia flessibilità per regolare l'allocazione delle risorse per l'istanza S3 File Gateway.

• Per i tipi di EC2 istanze Amazon consigliati per S3 File Gateway, consulta Requisiti per i tipi di EC2 istanze Amazon.

• Puoi modificare il tipo di EC2 istanza Amazon che ospita un S3 File Gateway attivo. Ciò consente di regolare facilmente la generazione di EC2 hardware Amazon e l'allocazione delle risorse per trovare un price-to-performance rapporto ideale. Per modificare il tipo di istanza, utilizza la seguente procedura nella EC2 console Amazon:

  1. Arresta l' EC2 istanza Amazon.

  2. Cambia il tipo di EC2 istanza Amazon.

  3. Accendi l' EC2 istanza Amazon.

  Nota

  L'arresto di un'istanza che ospita un S3 File Gateway interromperà temporaneamente l'accesso alla condivisione dei file. Assicurati di pianificare una finestra di manutenzione, se necessario.

• Il price-to-performance rapporto di un' EC2 istanza Amazon si riferisce alla potenza di calcolo ottenuta al prezzo pagato. In genere, EC2 le istanze Amazon di nuova generazione offrono il price-to-performance rapporto migliore, con hardware più recente e prestazioni migliorate a un costo relativamente inferiore rispetto alle generazioni precedenti. Fattori come il tipo di istanza, la regione e i modelli di utilizzo influiscono su questo rapporto, quindi è importante selezionare l'istanza giusta per il carico di lavoro specifico per ottimizzare il rapporto costo/efficacia.

Regola il livello di sicurezza delle PMI

Il SMBv3 protocollo consente sia la firma SMB che la crittografia SMB, con alcuni compromessi in termini di prestazioni e sicurezza. Per ottimizzare il throughput, è possibile regolare il livello di sicurezza SMB del gateway per specificare quali di queste funzionalità di sicurezza vengono applicate alle connessioni client. Per ulteriori informazioni, consulta Impostare un livello di sicurezza per il gateway.

Quando regolate il livello di sicurezza SMB, tenete presente quanto segue:

• Il livello di sicurezza predefinito per S3 File Gateway è Enforce encryption. Questa impostazione applica sia la crittografia che la firma per le connessioni client SMB alle condivisioni di file del gateway, il che significa che tutto il traffico dal client al gateway è crittografato. Questa impostazione non influisce sul traffico dal gateway a AWS, che è sempre crittografato.

  Il gateway limita ogni connessione client crittografata a una singola vCPU. Ad esempio, se si dispone di un solo client crittografato, tale client sarà limitato a una sola vCPU, anche se 4 o più v CPUs sono allocate al gateway. Per questo motivo, la velocità effettiva per le connessioni crittografate da un singolo client a S3 File Gateway è in genere limitata tra 40-60 MB/s.

• Se i requisiti di sicurezza consentono un approccio più rilassato, è possibile modificare il livello di sicurezza impostandolo su Client negotiated, che disabiliterà la crittografia SMB e applicherà solo la firma SMB. Con questa impostazione, le connessioni client al gateway possono utilizzare più v, il che in genere si traduce in un aumento delle CPUs prestazioni di throughput.

  Nota

  Dopo aver modificato il livello di sicurezza SMB per S3 File Gateway, è necessario attendere che lo stato della condivisione dei file passi da Aggiornamento a Disponibile nella console Storage Gateway, quindi disconnettere e ricollegare i client SMB affinché la nuova impostazione abbia effetto.

Utilizza più thread e client per parallelizzare le operazioni di scrittura

È difficile ottenere le massime prestazioni di throughput con un S3 File Gateway che utilizza un solo client NFS o SMB per scrivere un file alla volta, perché la scrittura sequenziale da un singolo client è un'operazione a thread singolo. Consigliamo invece di utilizzare più thread di ogni client NFS o SMB per scrivere più file in parallelo e di utilizzare più client NFS o SMB contemporaneamente sul tuo S3 File Gateway per massimizzare il throughput del gateway.

L'utilizzo di più thread può migliorare significativamente le prestazioni. Tuttavia, l'utilizzo di più thread richiede più risorse di sistema, il che può influire negativamente sulle prestazioni se il gateway non è dimensionato per soddisfare l'aumento del carico. In un'implementazione tipica, ci si può aspettare di ottenere migliori prestazioni di throughput aggiungendo più thread e client, fino a raggiungere i limiti massimi di hardware e larghezza di banda per il gateway. Ti consigliamo di sperimentare diversi numeri di thread per trovare l'equilibrio ottimale tra velocità e utilizzo delle risorse di sistema per la tua specifica configurazione hardware e di rete.

Considerate le seguenti informazioni sugli strumenti più comuni che possono aiutarvi a testare la configurazione del thread e del client:

• Puoi testare le prestazioni di scrittura multithread utilizzando strumenti come robocopy per copiare un set di file in una condivisione di file sul tuo gateway. Per impostazione predefinita, robocopy utilizza 8 thread per copiare i file, ma è possibile specificare fino a 128 thread.

  Per usare più thread con robocopy, aggiungi lo /MT:n switch al tuo comando, n dov'è il numero di thread che vuoi usare. Per esempio:

  robocopy C:\source D:\destination /MT:64

  Questo comando utilizzerà 64 thread per l'operazione di copia.

  Nota

  Si sconsiglia di utilizzare Windows Explorer per trascinare e rilasciare i file durante il test della velocità effettiva massima, poiché questo metodo è limitato a un singolo thread e copia i file in sequenza.

  Per ulteriori informazioni, consulta robocopy sul sito Web Microsoft Learn.

• Puoi anche eseguire test utilizzando strumenti comuni di benchmarking dello storage come DISKSPD o FIO. Questi strumenti offrono opzioni per regolare il numero di thread, la profondità di I/O e altri parametri in base ai requisiti specifici del carico di lavoro.

  DiskSpd consente di controllare il numero di thread utilizzando il parametro. -t Per esempio:

  diskspd -c10G -d300 -r -w50 -t64 -o32 -b1M -h -L C:\testfile.dat

  Questo comando di esempio esegue le seguenti operazioni:

  • Crea un file di test da 10 GB () -c1G

  • Funziona per 300 secondi () -d300

  • Esegue un I/O test casuale con il 50% di letture e 50% di scrittura () -r -w50

  • Utilizza 64 thread () -t64

  • Imposta la profondità della coda a 32 per thread () -o32

  • Utilizza una dimensione del blocco di 1 MB () -b1M

  • Disattiva la memorizzazione nella cache hardware e software () -h -L

  Per ulteriori informazioni, consulta Utilizzare DISKSPD per testare le prestazioni di archiviazione del carico di lavoro sul sito Web Microsoft Learn.

• FIO utilizza il numjobs parametro per controllare il numero di thread paralleli. Per esempio:

  fio --name=mixed_test --rw=randrw --rwmixread=70 --bs=1M -- iodepth=64 --size=10G --runtime=300 --numjobs=64 --ioengine=libaio --direct=1 --group_reporting

  Questo comando di esempio esegue le seguenti operazioni:

  • Esegue un I/O test casuale (--rw=randrw)

  • Esegue il 70% di letture e il 30% di scrittura () --rwmixread=70

  • Utilizza una dimensione del blocco di 1 MB () --bs=1M

  • Imposta la I/O profondità su 64 () --iodepth=64

  • Test su un file da 10 GB (--size=10G)

  • Funziona per 5 minuti (--runtime=300)

  • Crea 64 lavori paralleli (thread) (--numjobs=64)

  • Utilizza un motore asincrono I/O () --ioengine=libaio

  • Raggruppa i risultati per un'analisi più semplice () --group_reporting

  Per ulteriori informazioni, consultate la pagina man di fio Linux.

Disattiva l'aggiornamento automatico della cache

La funzionalità di aggiornamento automatico della cache consente a S3 File Gateway di aggiornare automaticamente i metadati, il che può aiutare a catturare eventuali modifiche apportate da utenti o applicazioni al set di file scrivendo direttamente nel bucket Amazon S3, anziché tramite il gateway. Per ulteriori informazioni, consulta Refreshing Amazon S3 bucket Object Cache.

Per ottimizzare il throughput del gateway, consigliamo di disattivare questa funzionalità nelle distribuzioni in cui tutte le letture e le scritture sul bucket Amazon S3 verranno eseguite tramite il tuo S3 File Gateway.

Quando configuri l'aggiornamento automatico della cache, considera quanto segue:

• Se devi utilizzare l'aggiornamento automatico della cache perché gli utenti o le applicazioni della tua distribuzione scrivono occasionalmente direttamente su Amazon S3, ti consigliamo di configurare l'intervallo di tempo più lungo possibile tra gli aggiornamenti, in modo che sia comunque pratico per le tue esigenze aziendali. Un intervallo di aggiornamento della cache più lungo aiuta a ridurre il numero di operazioni sui metadati che il gateway deve eseguire durante la navigazione nelle directory o la modifica dei file.

  Ad esempio: imposta l'aggiornamento automatico della cache su 24 ore, anziché 5 minuti, se ciò è tollerabile per il carico di lavoro.

• L'intervallo di tempo minimo è di 5 minuti. L'intervallo massimo è di 30 giorni.

• Se scegli di impostare un intervallo di aggiornamento della cache molto breve, ti consigliamo di testare l'esperienza di navigazione nelle directory per i tuoi client NFS e SMB. Il tempo necessario per aggiornare la cache del gateway può aumentare notevolmente a seconda del numero di file e sottodirectory nel bucket Amazon S3.

Aumenta il numero di thread di caricamento di Amazon S3

Per impostazione predefinita, S3 File Gateway apre 8 thread per il caricamento dei dati di Amazon S3, che fornisce una capacità di caricamento sufficiente per le distribuzioni più comuni. Tuttavia, è possibile che un gateway riceva dati dai client NFS e SMB a una velocità superiore a quella che può caricare su Amazon S3 con la capacità standard di 8 thread, il che può far sì che la cache locale raggiunga il limite di archiviazione.

In circostanze specifiche, Supporto puoi aumentare il numero di thread di caricamento di Amazon S3 per il tuo gateway da 8 a 40, il che consente di caricare più dati in parallelo. A seconda della larghezza di banda e di altri fattori specifici della distribuzione, ciò può aumentare significativamente le prestazioni di caricamento e contribuire a ridurre la quantità di storage nella cache necessaria per supportare il carico di lavoro.

Ti consigliamo di utilizzare la CachePercentDirty CloudWatch metrica per monitorare la quantità di dati archiviati sui dischi di cache del gateway locale che non sono ancora stati caricati su Amazon S3 e di Supporto contattarci per determinare se l'aumento del numero del pool di thread di caricamento possa migliorare il throughput per il tuo S3 File Gateway. Per ulteriori informazioni, consulta Understanding gateway metrics.

Nota

Questa impostazione consuma risorse aggiuntive della CPU del gateway. Si consiglia di monitorare l'utilizzo della CPU del gateway e di aumentare le risorse CPU allocate, se necessario.

Aumenta le impostazioni di timeout SMB

Quando S3 File Gateway copia file di grandi dimensioni in una condivisione di file SMB, la connessione client SMB può scadere dopo un periodo di tempo prolungato.

Consigliamo di estendere l'impostazione del timeout della sessione SMB per i client SMB a 20 minuti o più, a seconda della dimensione dei file e della velocità di scrittura del gateway. L'impostazione predefinita è 300 secondi o 5 minuti. Per ulteriori informazioni, vedi Il processo di backup del gateway non riesce o si verificano errori durante la scrittura sul gateway.

Attiva il blocco opportunistico per le applicazioni compatibili

Il blocco opportunistico, o «oplocks», è abilitato di default per ogni nuovo S3 File Gateway. Quando si utilizzano oplock con applicazioni compatibili, il client raggruppa più operazioni più piccole in operazioni più grandi, il che è più efficiente per il client, il gateway e la rete. Ti consigliamo di mantenere attivo il blocco opportunistico se utilizzi applicazioni che sfruttano la memorizzazione nella cache locale lato client, come Microsoft Office, Adobe Suite e molte altre, perché può migliorare significativamente le prestazioni.

Se disattivi il blocco opportunistico, le applicazioni che supportano gli oplock in genere aprono file di grandi dimensioni (50 MB o più) molto più lentamente. Questo ritardo si verifica perché il gateway invia i dati in parti da 4 KB, il che si traduce in una velocità effettiva elevata I/O e bassa.

Regola la capacità del gateway in base alla dimensione del set di file di lavoro

Il parametro di capacità del gateway specifica il numero massimo di file per i quali il gateway memorizzerà i metadati nella cache locale. Per impostazione predefinita, la capacità del gateway è impostata su Small, il che significa che il gateway archivia i metadati per un massimo di 5 milioni di file. L'impostazione predefinita funziona bene per la maggior parte dei carichi di lavoro, anche se ci sono centinaia di milioni o addirittura miliardi di oggetti in Amazon S3, perché in una distribuzione tipica si accede attivamente solo a un piccolo sottoinsieme di file alla volta. Questo gruppo di file viene definito «set di lavoro».

Se il carico di lavoro accede regolarmente a un set di lavoro superiore a 5 milioni di file, il gateway dovrà eliminare frequentemente la cache, ossia piccole operazioni di I/O archiviate nella RAM e mantenute sul disco principale. Ciò può influire negativamente sulle prestazioni del gateway poiché il gateway recupera nuovi dati da Amazon S3.

Puoi monitorare la IndexEvictions metrica per determinare il numero di file i cui metadati sono stati rimossi dalla cache per fare spazio a nuove voci. Per ulteriori informazioni, consulta Understanding gateway metrics.

Si consiglia di utilizzare l'azione UpdateGatewayInformation API per aumentare la capacità del gateway in modo che corrisponda al numero di file del set di lavoro tipico. Per ulteriori informazioni, consulta UpdateGatewayInformation.

Nota

L'aumento della capacità del gateway richiede RAM e capacità del disco root aggiuntive.

• Le dimensioni ridotte (5 milioni di file) richiedono almeno 16 GB di RAM e 80 GB di disco root.

• Medium (10 milioni di file) richiede almeno 32 GB di RAM e 160 GB di disco root.

• Le dimensioni grandi (20 milioni di file) richiedono 64 GB di RAM e 240 GB di disco root.

Importante

La capacità del gateway non può essere ridotta.

Implementa più gateway per carichi di lavoro più grandi

Quando possibile, consigliamo di suddividere il carico di lavoro su più gateway, anziché consolidare molte condivisioni di file su un unico gateway di grandi dimensioni. Ad esempio, è possibile isolare una condivisione di file molto utilizzata su un gateway, raggruppando le condivisioni di file utilizzate meno frequentemente su un altro gateway.

Quando pianifichi una distribuzione con più gateway e condivisioni di file, considera quanto segue:

• Il numero massimo di condivisioni di file su un singolo gateway è 50, ma il numero di condivisioni di file gestite da un gateway può influire sulle prestazioni del gateway. Per ulteriori informazioni, consulta Guida alle prestazioni per gateway con più condivisioni di file.

• Le risorse su ogni S3 File Gateway sono condivise tra tutte le condivisioni di file, senza partizionamento.

• Una singola condivisione di file con un utilizzo intenso può influire sulle prestazioni di altre condivisioni di file sul gateway.

Nota

Non è consigliabile creare più condivisioni di file mappate sulla stessa posizione Amazon S3 da più gateway, a meno che almeno una di esse non sia di sola lettura.

Le scritture simultanee sullo stesso file da più gateway sono considerate uno scenario di scrittura multipla, che può causare problemi di integrità dei dati.