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. 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 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 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

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, 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.

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.

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. Più thread hai, maggiore è la velocità effettiva che puoi raggiungere, 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, consultare:

• Esegui il backup di SQL Server il 43-67% più velocemente scrivendo su più file

• Archivia facilmente i tuoi backup di SQL Server in Amazon S3 utilizzando 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.

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 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.

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 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.

• 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 AWS Storage Gateway

• Archivia facilmente i tuoi backup di SQL Server in Amazon S3 utilizzando File Gateway

• Utilizzo AWS Storage Gateway per archiviare i backup dei database Oracle in Amazon S3

• Backup dei database Oracle su Amazon S3 su larga scala

• Integra un database SAP ASE in Amazon S3 utilizzando AWS Storage Gateway

• Come viene utilizzato One AWS Hero AWS Storage Gateway per il backup nel cloud

• Migliori pratiche per il dimensionamento della cache di S3 File Gateway