Amazon FSx File Gateway non è più disponibile per i nuovi clienti. I clienti esistenti di FSx File Gateway possono continuare a utilizzare il servizio normalmente. Per funzionalità simili a FSx File Gateway, consulta [questo post del blog](https://aws.amazon.com/blogs/storage/switch-your-file-share-access-from-amazon-fsx-file-gateway-to-amazon-fsx-for-windows-file-server/).
Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Prestazioni e ottimizzazione
Questa sezione descrive linee guida e best practice per ottimizzare le prestazioni di File Gateway.
**Topics**
+ [
## Linee guida di base sulle prestazioni per FSx
](#performance-fgw)
+ [
## Ottimizzazione delle prestazioni del gateway
](#Optimizing-common)
+ [
# Massimizzazione del throughput di S3 File Gateway
](Performance-Throughput.md)
+ [
# Ottimizzazione di S3 File Gateway per i backup dei database SQL Server
](SQL-Backup-Best-Practices.md)
## Linee guida di base sulle prestazioni per FSx
In questa sezione, puoi trovare indicazioni per il provisioning dell'hardware per la tua macchina virtuale FSx File Gateway. Le configurazioni di istanza elencate nella tabella sono esempi e vengono fornite come riferimento.
Per prestazioni ottimali, la dimensione del disco della cache deve essere ottimizzata in base alle dimensioni del set di lavoro attivo. L'utilizzo di più dischi locali per la cache aumenta le prestazioni in scrittura parallelizzando l'accesso ai dati e comportando maggiori IOPS.
**Nota**
Non è consigliabile utilizzare lo storage temporaneo. Per informazioni sull'utilizzo dello storage temporaneo, consulta [Utilizzo dello storage temporaneo con i gateway EC2](ephemeral-disk-cache.md).
Il limite di dimensione suggerito per le singole directory nei file system di Gateway è di 10.000 file per directory. È possibile utilizzare File Gateway con directory che contengono più di 10.000 file, ma le prestazioni potrebbero risentirne.
Nelle tabelle seguenti, le operazioni di lettura di *accesso alla cache* vengono lette dai dati dei file che vengono serviti dalla cache. Le operazioni di *mancata lettura della cache* vengono lette dai dati dei file forniti da Amazon FSx for Windows File Server.
La tabella seguente mostra un esempio di configurazione di FSx File Gateway.
### FSx Prestazioni di File Gateway sui client Windows
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/filegateway/latest/filefsxw/Performance.html)
**Nota**
Le prestazioni potrebbero variare in base alla configurazione della piattaforma host e alla larghezza di banda della rete. Le prestazioni di velocità effettiva di scrittura diminuiscono con la dimensione del file, con la velocità massima raggiungibile per file di piccole dimensioni (meno di 32 MiB) pari a 16 file al secondo.
## Ottimizzazione delle prestazioni del gateway
Puoi trovare le informazioni su come ottimizzare le prestazioni del gateway. Le linee guida sono basate sull'aggiunta di risorse al gateway e sull'aggiunta di risorse al server dell'applicazione.
### Aggiungere risorse al gateway
È possibile ottimizzare le prestazioni del gateway aggiungendo risorse al gateway in uno o più dei seguenti modi.
**Utilizzare dischi a elevate prestazioni**
Per ottimizzare le prestazioni del gateway, è possibile aggiungere dischi ad alte prestazioni come unità a stato solido (SSDs) e un controller. NVMe È anche possibile collegare dischi virtuali alla macchina virtuale direttamente da una SAN (Storage Area Network) piuttosto che da Microsoft Hyper-V NTFS. Il miglioramento delle prestazioni del disco si traduce in genere in una migliore velocità di trasmissione e in un maggior numero di input/output operazioni al secondo (IOPS). Per informazioni sull'aggiunta di dischi, vedere. [Configurazione di una memoria cache aggiuntiva](ConfiguringLocalDiskStorage.md)
Per misurare il throughput, utilizzare i parametri `ReadBytes` e `WriteBytes` con la statistica di `Samples` Amazon CloudWatch . Ad esempio, le statistiche `Samples` del parametro `ReadBytes` in un periodo di 5 minuti divisi 300 secondi forniscono gli IOPS. In generale, quando si prendono in esame questi parametri per un gateway, cercare un throughput basso e andamenti IOPS bassi per indicare colli di bottiglia correlati al disco.
CloudWatch le metriche non sono disponibili per tutti i gateway. Per informazioni sui parametri del gateway, consulta [Monitoraggio di FSx](monitoring-file-gateway.md).
**Aggiungere risorse CPU all'host del gateway**
Il requisito minimo per un host server gateway è rappresentato da quattro processori virtuali. Per ottimizzare le prestazioni del gateway, confermare che i quattro processori virtuali assegnati alla macchina virtuale del gateway sono supportati da quattro core. Inoltre, conferma di non aver sottoscritto un numero di sottoscrizioni superiore a quello CPUs del server host.
Quando ne aggiungete altri CPUs al server host del gateway, aumentate la capacità di elaborazione del gateway. In questo modo il gateway può gestire, in parallelo, sia l'archiviazione dei dati dall'applicazione allo storage locale sia il caricamento di questi dati S3 per Windows File Server. CPUs Inoltre, aiuta a garantire che il gateway riceva risorse CPU sufficienti quando l'host è condiviso con altri. VMs Fornire un numero sufficiente di risorse CPU ha l'effetto di migliorare il throughput generale.
Storage Gateway supporta l'utilizzo di 24 CPUs nel server host gateway. È possibile utilizzare 24 CPUs per migliorare in modo significativo le prestazioni del gateway. Ti consigliamo la seguente configurazione gateway per il tuo server host gateway:
+ 24 CPUs.
+ 16 GiB di RAM riservata per i gateway di file
+ 16 GiB di RAM riservata per gateway con dimensioni della cache fino a 16 TiB
+ 32 GiB di RAM riservata per gateway con dimensioni della cache da 16 TiB a 32 TiB
+ 48 GiB di RAM riservata per gateway con dimensioni della cache da 32 TiB a 64 TiB
+ Disco 1 collegato a un controller 1 paravirtuale per essere usato come cache gateway come segue:
+ SSD che utilizza un NVMe controller.
+ Adattatore di rete 1 configurato sulla rete macchina virtuale 1:
+ Usa la rete VM 1 e aggiungi VMXnet3 (10 Gbps) da utilizzare per l'ingestione.
+ Adattatore di rete 2 configurato sulla rete macchina virtuale 2:
+ Usa la rete VM 2 e aggiungi un VMXnet3 (10 Gbps) da utilizzare per la connessione. AWS
**Supportare dischi virtuali gateway con dischi fisici separati**
Quando si esegue il provisioning dei dischi gateway, si consiglia vivamente di non effettuare il provisioning di dischi locali per lo storage locale che utilizzano lo stesso disco di archiviazione fisico sottostante. Ad esempio, per VMware ESXi, le risorse di archiviazione fisica sottostanti sono rappresentate come un archivio dati. Quando si distribuisce la macchina virtuale del gateway, si sceglie un datastore in cui archiviare i file VM. Quando viene effettuato il provisioning di un disco virtuale (ad esempio, come buffer di caricamento), è possibile archiviare il disco virtuale nello stesso datastore della macchina virtuale o in un datastore differente.
Se si dispone di più di un datastore, è consigliabile scegliere un datastore per ogni tipo di storage locale che si sta creando. Un datastore che è supportato da un solo disco fisico sottostante può offrire prestazioni non soddisfacenti. Un esempio è quando questo disco viene usato per supportare sia lo storage della cache che il buffer di caricamento in una configurazione del gateway. Analogamente, un datastore supportato da una configurazione RAID con prestazioni minori, ad esempio RAID 1, può portare a prestazioni mediocri.
### Aggiungere risorse per l'ambiente applicativo
**Aumentare la larghezza di banda tra l'applicazione server e il gateway**
Per ottimizzare le prestazioni del gateway, garantire che la larghezza di banda di rete tra l'applicazione e il gateway sia in grado di far fronte alle esigenze dell'applicazione. È possibile utilizzare le `WriteBytes` metriche `ReadBytes` e del gateway per misurare la velocità totale dei dati.
Per l'applicazione, confrontare il throughput misurato con il throughput desiderato. Se il throughput misurato è inferiore al throughput desiderato, aumentando la larghezza di banda tra l'applicazione e il gateway è possibile migliorare le prestazioni se la rete è il collo di bottiglia. Analogamente, è possibile aumentare la larghezza di banda tra la macchina virtuale e i tuoi dischi locali, se non sono collegati direttamente.
**Aggiungere risorse CPU per l'ambiente applicativo**
Se l'applicazione può utilizzare risorse CPU aggiuntive, aggiungerne altre CPUs può aiutare l'applicazione a scalare il carico. I/O
Alcune operazioni sui file su FSx File Gateway, come la ridenominazione delle cartelle di primo livello o la modifica delle autorizzazioni, possono comportare più operazioni sui file che comportano un I/O carico elevato sul file system FSx per Windows File Server. Se il file system non dispone di risorse prestazionali sufficienti per il carico di lavoro, il file system potrebbe eliminare le [copie shadow](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/shadow-copies-fsxW.html) perché dà priorità alla disponibilità per la conservazione continua I/O rispetto alla conservazione delle copie shadow storiche.
Nella FSx console Amazon, consulta la pagina **Monitoraggio e prestazioni** per verificare se il provisioning del file system è insufficiente. In tal caso, puoi passare allo storage SSD, aumentare la capacità di throughput o aumentare gli IOPS SSD per gestire il tuo carico di lavoro.
# 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. Durante l'implementazione e il test di 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 AWS istanza Amazon 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 istanze Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html) 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:
+ `IoWaitPercent`riporta 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](https://docs.aws.amazon.com/filegateway/latest/files3/cloudwatch-alarms-create-recommended.html) 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, inclusi 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](https://docs.aws.amazon.com/filegateway/latest/files3/monitoring-file-gateway.html#understanding-file-gateway-metrics).
+ 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](https://youtu.be/-ibL1eEcROI?si=dMAakj_dulZiG4Ln) 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](https://docs.aws.amazon.com/filegateway/latest/files3/decide-local-disks-and-sizes.html) storage su disco locale.
Quando distribuisci S3 File Gateway come istanza Amazon EC2, 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 istanze Amazon EC2 consigliati per S3 File Gateway, consulta [Requisiti per i tipi di istanze Amazon EC2](https://docs.aws.amazon.com/filegateway/latest/files3/Requirements.html#requirements-hardware-ec2).
+ Puoi modificare il tipo di istanza Amazon EC2 che ospita un S3 File Gateway attivo. Ciò consente di regolare facilmente la generazione di hardware Amazon EC2 e l'allocazione delle risorse per trovare un rapporto ideale. price-to-performance Per modificare il tipo di istanza, utilizza la seguente procedura nella console Amazon EC2:
1. Arresta l'istanza Amazon EC2.
1. Cambia il tipo di istanza Amazon EC2.
1. Accendi l'istanza Amazon EC2.
**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'istanza Amazon EC2 si riferisce alla potenza di calcolo ottenuta al prezzo pagato. In genere, le istanze Amazon EC2 di nuova generazione offrono il rapporto price-to-performance 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](https://docs.aws.amazon.com/filegateway/latest/files3/security-strategy.html).
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. 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](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/robocopy) 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` 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](https://learn.microsoft.com/en-us/azure/azure-local/manage/diskspd-overview?view=azloc-24113) Microsoft Learn.
+ FIO utilizza il `numjobs` parametro per controllare il numero di thread paralleli. 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](https://linux.die.net/man/1/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](https://docs.aws.amazon.com/filegateway/latest/files3/refresh-cache.html) 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 in modo significativo 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.](https://docs.aws.amazon.com/filegateway/latest/files3/monitoring-file-gateway.html#understanding-file-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 delle dimensioni 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](https://docs.aws.amazon.com/filegateway/latest/files3/troubleshooting-file-gateway-issues.html#backup-job-fails).
## 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.](https://docs.aws.amazon.com/filegateway/latest/files3/monitoring-file-gateway.html#understanding-file-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](https://docs.aws.amazon.com/storagegateway/latest/APIReference/API_UpdateGatewayInformation.html).
**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, vedere [Guida alle prestazioni per gateway con più condivisioni di file](https://docs.aws.amazon.com/filegateway/latest/files3/Performance.html#performance-multiple-file-shares).
+ 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.
# Ottimizzazione di S3 File Gateway per i backup dei database SQL Server
I backup dei database sono un caso d'uso comune e consigliato per S3 File Gateway, che offre una conservazione conveniente a breve e lungo termine archiviando i backup del database in Amazon S3, con la possibilità di eseguire il ciclo di vita su livelli di storage più bassi, se necessario. Con questa soluzione, puoi ridurre la necessità di applicazioni di backup aziendali utilizzando strumenti integrati come SQL Server Management Studio e Oracle RMAN.
Le sezioni seguenti descrivono le migliori pratiche per ottimizzare l'implementazione di S3 File Gateway per prestazioni ottimizzate e un supporto conveniente per centinaia di terabyte di backup di database SQL. Le linee guida 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. Durante l'implementazione e il test di 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 AWS istanza Amazon 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 server SQL
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 server SQL. 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 SMB, come i server SQL.
+ 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 server SQL nello stesso gruppo di collocamento. Per ulteriori informazioni, consulta [i gruppi di posizionamento per le tue istanze Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html) 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:
+ `IoWaitPercent`riporta 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](https://docs.aws.amazon.com/filegateway/latest/files3/cloudwatch-alarms-create-recommended.html) per il gateway.
+ Per ridurre al minimo i dischi root e cache del gateway, consigliamo di utilizzare uno NVMe o l'SSD. `IoWaitPercent`
## Regola l'allocazione delle risorse della macchina virtuale S3 File Gateway 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, inclusi 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](https://docs.aws.amazon.com/filegateway/latest/files3/monitoring-file-gateway.html#understanding-file-gateway-metrics).
+ 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](https://youtu.be/-ibL1eEcROI?si=dMAakj_dulZiG4Ln) 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](https://docs.aws.amazon.com/filegateway/latest/files3/decide-local-disks-and-sizes.html) storage su disco locale.
Quando distribuisci S3 File Gateway come istanza Amazon EC2, 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 istanze Amazon EC2 consigliati per S3 File Gateway, consulta [Requisiti per i tipi di istanze Amazon EC2](https://docs.aws.amazon.com/filegateway/latest/files3/Requirements.html#requirements-hardware-ec2).
+ Puoi modificare il tipo di istanza Amazon EC2 che ospita un S3 File Gateway attivo. Ciò consente di regolare facilmente la generazione di hardware Amazon EC2 e l'allocazione delle risorse per trovare un rapporto ideale. price-to-performance Per modificare il tipo di istanza, utilizza la seguente procedura nella console Amazon EC2:
1. Arresta l'istanza Amazon EC2.
1. Cambia il tipo di istanza Amazon EC2.
1. Accendi l'istanza Amazon EC2.
**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'istanza Amazon EC2 si riferisce alla potenza di calcolo ottenuta al prezzo pagato. In genere, le istanze Amazon EC2 di nuova generazione offrono il rapporto price-to-performance 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.
## Migliora la produttività dei client SMB regolando il livello di sicurezza del tuo S3 File Gateway
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](https://docs.aws.amazon.com/filegateway/latest/files3/security-strategy.html).
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.
## Migliora la produttività dei client SMB suddividendo i backup SQL in più file
+ È difficile ottenere le massime prestazioni di throughput con un S3 File Gateway: solo un server SQL scrive un file alla volta, perché la scrittura sequenziale da un singolo server SQL è un'operazione a thread singolo. Si consiglia invece di utilizzare più thread da ciascun server SQL per scrivere più file in parallelo e di utilizzare più server SQL contemporaneamente su S3 File Gateway per massimizzare il throughput del gateway. Con i backup SQL, la suddivisione dei backup in più file consente a ciascun file di utilizzare un thread separato, che scriverà più file contemporaneamente nella condivisione di file S3 File Gateway. Maggiore è il numero di thread, maggiore è la velocità effettiva che è possibile ottenere, fino ai limiti del gateway.
+ SQL Server supporta la scrittura su più file contemporaneamente durante una singola operazione di backup. Ad esempio, è possibile specificare più destinazioni di file utilizzando i comandi T-SQL o SQL Server Management Studio (SSMS). Ogni file utilizza un thread separato per inviare dati dal server SQL alla condivisione di file del gateway. Questo approccio consente una migliore I/O velocità di trasmissione, che può migliorare in modo significativo la velocità e l'efficienza del backup.
Quando configuri i backup del server SQL, considera quanto segue:
+ Suddividendo i backup in più file, gli amministratori di SQL Server possono ottimizzare i tempi di backup e gestire i backup di database di grandi dimensioni in modo più efficace.
+ Il numero di file utilizzati dipende dalla configurazione dello storage e dai requisiti prestazionali del server. Per i database di grandi dimensioni, si consiglia di suddividere i backup in diversi file più piccoli tra 10 GB e 20 GB ciascuno.
+ Non esiste un limite rigoroso al numero di file su cui SQL Server può scrivere durante un backup, ma considerazioni pratiche come l'architettura di archiviazione e la larghezza di banda della rete dovrebbero guidare questa scelta.
Per ulteriori informazioni, consulta:
+ [Esegui il backup di SQL Server il 43-67% più velocemente scrivendo su più file](https://www.brentozar.com/archive/2020/08/back-up-sql-server-43-67-faster-by-writing-to-multiple-files/)
+ [Archivia facilmente i tuoi backup di SQL Server in Amazon S3 utilizzando File Gateway](https://aws.amazon.com/blogs/storage/easily-store-your-sql-server-backups-in-amazon-s3-using-file-gateway/)
## Previeni errori di copia di file di grandi dimensioni aumentando le impostazioni di timeout SMB
Quando S3 File Gateway copia file di backup SQL 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 di SQL Server a 20 minuti o più, a seconda delle dimensioni 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](https://docs.aws.amazon.com/filegateway/latest/files3/troubleshooting-file-gateway-issues.html#backup-job-fails).
## 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 server SQL 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 in modo significativo 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.](https://docs.aws.amazon.com/filegateway/latest/files3/monitoring-file-gateway.html#understanding-file-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.
## 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](https://docs.aws.amazon.com/filegateway/latest/files3/refresh-cache.html) 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 server SQL. Il tempo necessario per aggiornare la cache del gateway può aumentare notevolmente a seconda del numero di file e sottodirectory nel bucket Amazon S3.
## Implementa più gateway per supportare il carico di lavoro
Storage Gateway può supportare backup SQL per ambienti di grandi dimensioni con centinaia di database SQL, più SQL Server e centinaia di terabyte di dati di backup suddividendo il carico di lavoro su più gateway.
Quando pianifichi una distribuzione con più gateway e server SQL, considera quanto segue:
+ Un singolo gateway può in genere caricare fino a 20 TB al giorno, con risorse hardware e larghezza di banda sufficienti. Puoi aumentare questo limite fino a 40 TB al giorno [aumentando il numero di thread di caricamento di Amazon S3](https://docs.aws.amazon.com/filegateway/latest/files3/SQL-Backup-Best-Practices.html#SQL-Backup-Uploader-Threads).
+ Ti consigliamo di eseguire un proof-of-concept test per misurare le prestazioni e tenere conto di tutte le variabili della distribuzione. Dopo aver determinato il throughput di picco del carico di lavoro di backup SQL, puoi scalare il numero di gateway per soddisfare i tuoi requisiti.
+ Consigliamo di progettare la soluzione pensando alla crescita, poiché il numero di database e le dimensioni dei database possono aumentare nel tempo. Per continuare a scalare e supportare un carico di lavoro crescente, puoi implementare gateway aggiuntivi in base alle esigenze.
## Risorse aggiuntive per i carichi di lavoro di backup del database
+ [Archivia i backup di SQL Server in Amazon S3 utilizzando Gateway di archiviazione AWS](https://aws.amazon.com/blogs/database/storing-sql-server-backups-in-amazon-s3-using-aws-storage-gateway/)
+ [Archivia facilmente i tuoi backup di SQL Server in Amazon S3 utilizzando File Gateway](https://aws.amazon.com/blogs/storage/easily-store-your-sql-server-backups-in-amazon-s3-using-file-gateway/)
+ [Utilizzo Gateway di archiviazione AWS per archiviare i backup dei database Oracle in Amazon S3](https://aws.amazon.com/blogs/storage/using-aws-storage-gateway-to-store-oracle-database-backups-in-amazon-s3/)
+ [Backup dei database Oracle su Amazon S3 su larga scala](https://aws.amazon.com/blogs/storage/backing-up-oracle-databases-to-amazon-s3-at-scale/)
+ [Integra un database SAP ASE in Amazon S3 utilizzando Gateway di archiviazione AWS](https://aws.amazon.com/blogs/storage/integrate-an-sap-ase-database-to-amazon-s3-using-aws-storage-gateway/)
+ [Come viene utilizzato One AWS Hero Gateway di archiviazione AWS per il backup nel cloud](https://aws.amazon.com/blogs/storage/how-one-aws-hero-uses-aws-storage-gateway-for-in-cloud-backup/)
+ [Migliori pratiche per il dimensionamento della cache di S3 File Gateway](https://www.youtube.com/watch?v=-ibL1eEcROI)