La versione in lingua italiana fornita proviene da una traduzione automatica. Per eventuali incoerenze, fare riferimento alla versione in lingua inglese.

TR-4923: Server SQL su AWS EC2 con Amazon FSX per NetApp ONTAP

04/12/2024 Collaboratori

PDF

Autori: Pat Sinthusan e Niyaz Mohamed, NetApp

Introduzione

Molte aziende che desiderano migrare le applicazioni da on-premise a cloud scoprono che lo sforzo è ostacolato dalle differenze nelle funzionalità offerte dai sistemi di storage on-premise e dai servizi di cloud storage. Questo divario ha reso la migrazione delle applicazioni aziendali come Microsoft SQL Server molto più problematica. In particolare, le lacune nei servizi necessari per eseguire un'applicazione aziendale, come ad esempio solide snapshot, funzionalità di efficienza dello storage, alta disponibilità, affidabilità e performance costanti, hanno costretto i clienti a fare compromessi di progettazione o a rinunciare alla migrazione delle applicazioni. Con FSX per NetApp ONTAP, i clienti non devono più scendere a compromessi. FSX per NetApp ONTAP è un servizio AWS nativo (di prima parte) venduto, supportato, fatturato e completamente gestito da AWS. Utilizza la potenza di NetApp ONTAP per fornire le stesse funzionalità di storage e gestione dei dati di livello Enterprise che NetApp ha fornito on-premise per trent'anni in AWS come servizio gestito.

Con SQL Server sulle istanze EC2, gli amministratori di database possono accedere e personalizzare il proprio ambiente di database e il sistema operativo sottostante. Un SQL Server sull'istanza EC2 in combinazione con "ONTAP AWS FSX" per memorizzare i file di database, consente performance elevate, gestione dei dati e un percorso di migrazione semplice e semplice utilizzando la replica a livello di blocco. Pertanto, è possibile eseguire il database complesso su AWS VPC con un semplice approccio "lift-and-shift", meno clic e nessuna conversione dello schema.

Vantaggi dell'utilizzo di Amazon FSX per NetApp ONTAP con SQL Server

Amazon FSX per NetApp ONTAP è il file storage ideale per le implementazioni di SQL Server in AWS. I vantaggi includono:

Performance elevate e throughput costanti con bassa latenza
Caching intelligente con cache NVMe per migliorare le performance
Dimensionamento flessibile per aumentare o ridurre capacità, throughput e IOPS in tempo reale
Replica efficiente dei blocchi on-premise-to-AWS
L'utilizzo di iSCSI, un protocollo noto per l'ambiente di database
Funzionalità di efficienza dello storage come thin provisioning e cloni a impatto zero
Riduzione dei tempi di backup da ore a minuti, con conseguente riduzione dell'RTO
Backup granulare e ripristino di database SQL con l'intuitiva interfaccia utente di NetApp SnapCenter
Possibilità di eseguire più migrazioni di test prima della migrazione effettiva
Riduzione dei downtime durante la migrazione e superamento delle sfide di migrazione con copia a livello di file o i/O.
Riduzione del MTTR individuando la causa principale dopo una release importante o un aggiornamento delle patch

L'implementazione di database SQL Server su FSX ONTAP con il protocollo iSCSI, come comunemente utilizzato on-premise, offre un ambiente di storage ideale per database con performance superiori, efficienza dello storage e funzionalità di gestione dei dati. Utilizzando più sessioni iSCSI, presupponendo una dimensione del working set pari al 5%, l'adattamento di una Flash cache offre oltre 100.000 IOPS con il servizio FSX ONTAP. Questa configurazione offre un controllo completo delle performance per le applicazioni più esigenti. SQL Server in esecuzione su istanze EC2 più piccole connesse a FSX per ONTAP può eseguire le stesse prestazioni di SQL Server in esecuzione su un'istanza EC2 molto più grande, perché vengono applicati solo limiti di larghezza di banda di rete a fronte di FSX per ONTAP. La riduzione delle dimensioni delle istanze riduce anche i costi di calcolo, offrendo un'implementazione ottimizzata per il TCO. La combinazione di SQL con iSCSI, SMB3.0 e condivisioni di disponibilità continua multicanale su FSX per ONTAP offre grandi vantaggi per i carichi di lavoro SQL.

Prima di iniziare

La combinazione di Amazon FSX per NetApp ONTAP e SQL Server su istanza EC2 consente la creazione di design di storage di database di livello Enterprise in grado di soddisfare i requisiti applicativi più esigenti di oggi. Per ottimizzare entrambe le tecnologie, è fondamentale comprendere i modelli e le caratteristiche di i/o di SQL Server. Un layout di storage ben progettato per un database SQL Server supporta le performance di SQL Server e la gestione dell'infrastruttura SQL Server. Un buon layout dello storage consente inoltre di avere successo nell'implementazione iniziale e di far crescere l'ambiente nel tempo con la crescita del business.

Prerequisiti

Prima di completare la procedura descritta in questo documento, è necessario disporre dei seguenti prerequisiti:

Un account AWS
Ruoli IAM appropriati per il provisioning di EC2 e FSX per ONTAP
Un dominio Windows Active Directory su EC2
Tutti i nodi di SQL Server devono essere in grado di comunicare tra loro
Assicurarsi che la risoluzione DNS funzioni e che i nomi host possano essere risolti. In caso contrario, utilizzare la voce del file host.
Conoscenza generale dell'installazione di SQL Server

Inoltre, fare riferimento alle Best practice NetApp per gli ambienti SQL Server per garantire la migliore configurazione dello storage.

Configurazioni Best practice per ambienti SQL Server su EC2

Con FSX ONTAP, procurarsi lo storage è l'attività più semplice e può essere eseguita aggiornando il file system. Questo semplice processo consente l'ottimizzazione dinamica dei costi e delle performance in base alle esigenze, aiuta a bilanciare il carico di lavoro SQL ed è anche un ottimo elemento di supporto per il thin provisioning. Il thin provisioning di FSX ONTAP è progettato per presentare più storage logico alle istanze EC2 che eseguono SQL Server rispetto a quanto previsto nel file system. Invece di allocare lo spazio in anticipo, lo spazio di storage viene allocato dinamicamente a ciascun volume o LUN durante la scrittura dei dati. Nella maggior parte delle configurazioni, lo spazio libero viene liberato anche quando i dati nel volume o nel LUN vengono cancellati (e non vengono conservati da alcuna copia Snapshot). La tabella seguente fornisce le impostazioni di configurazione per l'allocazione dinamica dello storage.

Impostazione

Configurazione

Garanzia di volume

Nessuno (impostazione predefinita)

Prenotazione LUN

Attivato

fractional_reserve

0% (impostazione predefinita)

snap_reserve

Eliminazione automatica

volume / oldest_first

Dimensionamento automatico

Acceso

prova_prima

Crescita automatica

Policy di tiering dei volumi

Solo Snapshot

Policy di Snapshot

Nessuno

Con questa configurazione, la dimensione totale dei volumi può essere superiore allo storage effettivo disponibile nel file system. Se le LUN o le copie Snapshot richiedono più spazio di quello disponibile nel volume, i volumi aumentano automaticamente, occupando più spazio dal file system contenente. La funzione di crescita automatica consente a FSX ONTAP di aumentare automaticamente le dimensioni del volume fino alle dimensioni massime predeterminate. Per supportare la crescita automatica del volume, deve essere disponibile spazio nel file system contenente. Pertanto, con la funzione di crescita automatica attivata, è necessario monitorare lo spazio libero nel file system contenente e aggiornare il file system quando necessario.

Insieme a questo, impostare "allocazione dello spazio" Opzione on LUN (LUN) su Enabled (attivato) in modo che FSX ONTAP notifichi all'host EC2 quando il volume ha esaurito lo spazio e il LUN nel volume non può accettare scritture. Inoltre, questa opzione consente a FSX per ONTAP di recuperare automaticamente lo spazio quando il server SQL sull'host EC2 elimina i dati. Per impostazione predefinita, l'opzione di allocazione dello spazio è disattivata.

Se viene creata una LUN riservata allo spazio in un volume non garantito, la LUN si comporta come una LUN non riservata allo spazio. Questo perché un volume non garantito non dispone di spazio da allocare al LUN; il volume stesso può allocare spazio solo quando viene scritto, a causa della sua garanzia di assenza.

Con questa configurazione, gli amministratori di FSX ONTAP possono in genere dimensionare il volume in modo che debbano gestire e monitorare lo spazio utilizzato nel LUN sul lato host e nel file system.

NetApp consiglia di utilizzare un file system separato per i carichi di lavoro di SQL Server. Se il file system viene utilizzato per più applicazioni, monitorare l'utilizzo dello spazio del file system e dei volumi all'interno del file system per assicurarsi che i volumi non siano in concorrenza con lo spazio disponibile.

Le copie Snapshot utilizzate per creare volumi FlexClone non vengono eliminate dall'opzione di eliminazione automatica.

L'overcommitment dello storage deve essere attentamente considerato e gestito per un'applicazione mission-critical come SQL Server per la quale non è possibile tollerare anche un'interruzione minima. In tal caso, è meglio monitorare le tendenze di consumo dello storage per determinare quanto, se presenti, l'impegno in eccesso sia accettabile.

Best Practice

Per ottenere performance di storage ottimali, è possibile eseguire il provisioning della capacità del file system fino a 1,35 volte più grande rispetto all'utilizzo totale del database.
Quando si utilizza il thin provisioning, è necessario un monitoraggio appropriato, accompagnato da un piano d'azione efficace, per evitare il downtime delle applicazioni.
Assicurati di impostare gli avvisi di Cloudwatch e di altri strumenti di monitoraggio in modo che le persone vengano contattate con il tempo necessario per reagire quando lo storage viene riempito.

Configurare lo storage per SQL Server e implementare SnapCenter per le operazioni di backup, ripristino e clonazione

Per eseguire operazioni SQL Server con SnapCenter, è necessario innanzitutto creare volumi e LUN per SQL Server.

Creare volumi e LUN per SQL Server

Per creare volumi e LUN per SQL Server, attenersi alla seguente procedura:

Aprire la console Amazon FSX all'indirizzo https://console.aws.amazon.com/fsx/
Creare un file system Amazon FSX per NetApp ONTAP utilizzando l'opzione di creazione standard nel metodo di creazione. In questo modo è possibile definire le credenziali FSxadmin e vsadmin.
Specificare la password per fsxadmin.
Specificare la password per le SVM.
Creare i volumi seguendo la procedura indicata nella "Creazione di un volume su FSX per NetApp ONTAP".

Best practice
- Disattivare le pianificazioni delle copie Snapshot dello storage e le policy di conservazione. Utilizzare invece NetApp SnapCenter per coordinare le copie Snapshot dei dati e dei volumi di log di SQL Server.
- Configurare i database su LUN individuali su volumi separati per sfruttare la funzionalità di ripristino rapida e granulare.
- Posizionare i file di dati utente (.mdf) su volumi separati perché si tratta di carichi di lavoro di lettura/scrittura casuali. È comune creare backup del log delle transazioni con maggiore frequenza rispetto ai backup del database. Per questo motivo, posizionare i file di log delle transazioni (.ldf) su un volume separato dai file di dati, in modo che sia possibile creare pianificazioni di backup indipendenti per ciascuno di essi. Questa separazione isola inoltre l'i/o di scrittura sequenziale dei file di log dall'i/o di lettura/scrittura casuale dei file di dati e migliora significativamente le prestazioni di SQL Server.
- Tempdb è un database di sistema utilizzato da Microsoft SQL Server come area di lavoro temporanea, in particolare per le operazioni DBCC CHECKDB i/o intensive. Pertanto, posizionare questo database su un volume dedicato. In ambienti di grandi dimensioni in cui il numero di volumi rappresenta una sfida, è possibile consolidare il tempdb in un numero inferiore di volumi e memorizzarlo nello stesso volume degli altri database di sistema dopo un'attenta pianificazione. La protezione dei dati per tempdb non è una priorità elevata perché questo database viene ricreato ogni volta che Microsoft SQL Server viene riavviato.

Utilizzare il seguente comando SSH per creare volumi:

vol create -vserver svm001 -volume vol_awssqlprod01_data -aggregate aggr1 -size 800GB -state online -tiering-policy snapshot-only -percent-snapshot-space 0 -autosize-mode grow -snapshot-policy none -security-style ntfs
volume modify -vserver svm001 -volume vol_awssqlprod01_data -fractional-reserve 0
volume modify -vserver svm001 -volume vol_awssqlprod01_data -space-mgmt-try-first vol_grow
volume snapshot autodelete modify -vserver svm001 -volume vol_awssqlprod01_data -delete-order oldest_first

Avviare il servizio iSCSI con PowerShell utilizzando privilegi elevati nei server Windows.
```
Start-service -Name msiscsi
Set-Service -Name msiscsi -StartupType Automatic
```
Installare multipath-io con PowerShell utilizzando privilegi elevati nei server Windows.
```
 Install-WindowsFeature -name Multipath-IO -Restart
```
Individuare il nome di Windows Initiator con PowerShell utilizzando privilegi elevati nei server Windows.
```
Get-InitiatorPort | select NodeAddress
```

Connettersi alle macchine virtuali di storage (SVM) utilizzando PuTTY e creare un iGroup.

igroup create -igroup igrp_ws2019sql1 -protocol iscsi -ostype windows -initiator iqn.1991-05.com.microsoft:ws2019-sql1.contoso.net

Utilizzare il seguente comando SSH per creare LUN:

lun create -path /vol/vol_awssqlprod01_data/lun_awssqlprod01_data -size 700GB -ostype windows_2008 -space-allocation enabled lun create -path /vol/vol_awssqlprod01_log/lun_awssqlprod01_log -size 100GB -ostype windows_2008 -space-allocation enabled

Errore: Immagine grafica mancante

Per ottenere l'allineamento i/o con lo schema di partizione del sistema operativo, utilizzare Windows_2008 come tipo di LUN consigliato. Fare riferimento a. "qui" per ulteriori informazioni.

Utilizzare il seguente comando SSH per mappare i LUN appena creati.

lun show
lun map -path /vol/vol_awssqlprod01_data/lun_awssqlprod01_data -igroup igrp_awssqlprod01lun map -path /vol/vol_awssqlprod01_log/lun_awssqlprod01_log -igroup igrp_awssqlprod01

Errore: Immagine grafica mancante

Per un disco condiviso che utilizza il cluster di failover di Windows, eseguire un comando SSH per mappare lo stesso LUN all'igroup che appartiene a tutti i server che fanno parte del cluster di failover di Windows.
Connessione di Windows Server a una SVM con una destinazione iSCSI. Individuare l'indirizzo IP di destinazione da AWS Portal.
Da Server Manager (Gestione server) e dal menu Tools (Strumenti), selezionare iSCSI Initiator (iniziatore iSCSI). Selezionare la scheda Discovery (rilevamento), quindi Discover Portal (Scopri portale). Fornire l'indirizzo IP iSCSI indicato nella fase precedente e selezionare Advanced (Avanzate). Da Local Adapter, selezionare Microsoft iSCSI Initiator. Da Initiator IP (IP iniziatore), selezionare l'IP del server. Quindi selezionare OK per chiudere tutte le finestre.
Ripetere il punto 12 per il secondo IP iSCSI da SVM.
Selezionare la scheda targets, selezionare Connect e selezionare Enable muti-path.
Per ottenere performance ottimali, aggiungere altre sessioni; NetApp consiglia di creare cinque sessioni iSCSI. Selezionare Proprietà *> *Aggiungi sessione *> *Avanzate e ripetere il punto 12.
```
$TargetPortals = ('10.2.1.167', '10.2.2.12')
foreach ($TargetPortal in $TargetPortals) {New-IscsiTargetPortal -TargetPortalAddress $TargetPortal}
```

Best practice

Configurare cinque sessioni iSCSI per interfaccia di destinazione per ottenere performance ottimali.
Configurare una policy di round robin per ottenere le migliori performance iSCSI complessive.

Assicurarsi che la dimensione dell'unità di allocazione sia impostata su 64K per le partizioni durante la formattazione dei LUN

Eseguire il seguente comando PowerShell per assicurarsi che la sessione iSCSI sia persistente.

$targets = Get-IscsiTarget
foreach ($target in $targets)
{
Connect-IscsiTarget -IsMultipathEnabled $true -NodeAddress $target.NodeAddress -IsPersistent $true
}

Errore: Immagine grafica mancante

Inizializzare i dischi con il seguente comando PowerShell.

$disks = Get-Disk | where PartitionStyle -eq raw
foreach ($disk in $disks) {Initialize-Disk $disk.Number}

Errore: Immagine grafica mancante

Eseguire i comandi Create Partition (Crea partizione) e Format Disk (Formatta disco) con PowerShell.

New-Partition -DiskNumber 1 -DriveLetter F -UseMaximumSize
Format-Volume -DriveLetter F -FileSystem NTFS -AllocationUnitSize 65536
New-Partition -DiskNumber 2 -DriveLetter G -UseMaximumSize
Format-Volume -DriveLetter G -FileSystem NTFS -AllocationUnitSize 65536

È possibile automatizzare la creazione di volumi e LUN utilizzando lo script PowerShell dell'Appendice B. I LUN possono essere creati anche utilizzando SnapCenter.

Una volta definiti i volumi e le LUN, è necessario configurare SnapCenter per eseguire le operazioni del database.

Panoramica di SnapCenter

NetApp SnapCenter è un software per la protezione dei dati di prossima generazione per le applicazioni Enterprise Tier-1. SnapCenter, con la sua interfaccia di gestione con singolo pannello di controllo, automatizza e semplifica i processi manuali, complessi e lunghi associati al backup, al ripristino e alla clonazione di più database e altri carichi di lavoro applicativi. SnapCenter sfrutta le tecnologie NetApp, tra cui NetApp Snapshots, NetApp SnapMirror, SnapRestore e NetApp FlexClone. Questa integrazione consente alle organizzazioni IT di scalare la propria infrastruttura storage, soddisfare gli impegni SLA sempre più rigorosi e migliorare la produttività degli amministratori in tutta l'azienda.

Requisiti del server SnapCenter

La seguente tabella elenca i requisiti minimi per l'installazione del server e del plug-in SnapCenter.

Componenti	Requisito
Numero minimo di CPU	Quattro core/vCPU
Memoria	Minimo: 8 GB consigliati: 32 GB
Spazio di storage	Spazio minimo per l'installazione: 10 GB di spazio minimo per il repository: 10 GB
Sistema operativo supportato	Windows Server 2012 Windows Server 2012 R2 Windows Server 2016 Windows Server 2019
Pacchetti software	.NET 4.5.2 o versione successiva Windows Management Framework (WMF) 4.0 o versione successiva PowerShell 4.0 o versione successiva

Componenti

Requisito

Numero minimo di CPU

Quattro core/vCPU

Memoria

Minimo: 8 GB consigliati: 32 GB

Spazio di storage

Spazio minimo per l'installazione: 10 GB di spazio minimo per il repository: 10 GB

Sistema operativo supportato

Windows Server 2012
Windows Server 2012 R2
Windows Server 2016
Windows Server 2019

Pacchetti software

.NET 4.5.2 o versione successiva
Windows Management Framework (WMF) 4.0 o versione successiva
PowerShell 4.0 o versione successiva

Per informazioni dettagliate, fare riferimento a. "requisiti di spazio e dimensionamento".

Per informazioni sulla compatibilità delle versioni, consultare "Tool di matrice di interoperabilità NetApp".

Layout dello storage del database

La figura seguente illustra alcune considerazioni relative alla creazione del layout di storage del database Microsoft SQL Server durante il backup con SnapCenter.

Errore: Immagine grafica mancante

Best practice

Posizionare i database con query i/o intensive o con database di grandi dimensioni (ad esempio, 500 GB o più) su un volume separato per un ripristino più rapido. Il backup di questo volume deve essere eseguito anche da processi separati.
Consolidamento di database di piccole e medie dimensioni meno critici o con meno requisiti di i/o in un singolo volume. Il backup di un gran numero di database che risiedono nello stesso volume comporta un minor numero di copie Snapshot che devono essere mantenute. È inoltre consigliabile consolidare le istanze di Microsoft SQL Server per utilizzare gli stessi volumi per controllare il numero di copie Snapshot di backup eseguite.
Creare LUN separati per memorizzare file di testo completi e file correlati allo streaming di file.
Assegnare LUN separati per host per memorizzare i backup dei log di Microsoft SQL Server.
I database di sistema che memorizzano la configurazione dei metadati del server di database e i dettagli del lavoro non vengono aggiornati frequentemente. Posizionare i database/tempdb di sistema in dischi o LUN separati. Non collocare i database di sistema nello stesso volume dei database dell'utente. I database degli utenti hanno criteri di backup diversi e la frequenza del backup del database degli utenti non è la stessa per i database di sistema.
Per l'installazione di Microsoft SQL Server Availability Group, posizionare i file di dati e di log per le repliche in una struttura di cartelle identica su tutti i nodi.

Oltre ai vantaggi in termini di performance derivanti dalla separazione del layout del database utente in diversi volumi, il database influisce in modo significativo anche sul tempo necessario per il backup e il ripristino. La presenza di volumi separati per i file di dati e log migliora significativamente il tempo di ripristino rispetto a un volume che ospita più file di dati utente. Allo stesso modo, i database degli utenti con un'applicazione con elevato utilizzo di i/o sono soggetti a un aumento dei tempi di backup. Una spiegazione più dettagliata sulle procedure di backup e ripristino è fornita più avanti in questo documento.

A partire da SQL Server 2012 (11.x), database di sistema (Master, Model, MSDB e TempDB), I database utente di Database Engine possono essere installati con un file server SMB come opzione di storage. Questo vale per le installazioni standalone di cluster di failover di SQL Server e SQL Server. Questo consente di utilizzare FSX per ONTAP con tutte le sue funzionalità di performance e gestione dei dati, tra cui capacità dei volumi, scalabilità delle performance e funzionalità di protezione dei dati, di cui può usufruire SQL Server. Le condivisioni utilizzate dai server applicazioni devono essere configurate con il set di proprietà Continuously Available e il volume deve essere creato con lo stile di protezione NTFS. NetApp SnapCenter non può essere utilizzato con database collocati su condivisioni SMB da FSX per ONTAP.

Per i database SQL Server che non utilizzano SnapCenter per eseguire i backup, Microsoft consiglia di posizionare i file di dati e di log su dischi separati. Per le applicazioni che aggiornano e richiedono contemporaneamente i dati, il file di log è intensivo in scrittura e il file di dati (a seconda dell'applicazione) è intensivo in lettura/scrittura. Per il recupero dei dati, il file di log non è necessario. Pertanto, le richieste di dati possono essere soddisfatte dal file di dati posto sul proprio disco.

Quando si crea un nuovo database, Microsoft consiglia di specificare unità separate per i dati e i registri. Per spostare i file dopo la creazione del database, il database deve essere portato offline. Per ulteriori consigli Microsoft, consulta l'articolo posizionare i file di dati e di registro su unità separate.

Installazione e configurazione di SnapCenter

Seguire la "Installare il server SnapCenter" e. "Installazione del plug-in SnapCenter per Microsoft SQL Server" Per installare e configurare SnapCenter.

Dopo aver installato SnapCenter, completare la seguente procedura per configurarlo.

Per impostare le credenziali, selezionare Impostazioni > nuovo, quindi immettere le informazioni sulle credenziali.
Aggiungere il sistema di storage selezionando sistemi di storage > nuovo e fornire l'FSX appropriato per le informazioni di storage ONTAP.
Aggiungere gli host selezionando hosts > Add, quindi fornire le informazioni sull'host. SnapCenter installa automaticamente il plug-in di Windows e SQL Server. Questo processo potrebbe richiedere del tempo.

Una volta installati tutti i plug-in, è necessario configurare la directory di log. Questa è la posizione in cui risiede il backup del log delle transazioni. È possibile configurare la directory del registro selezionando l'host, quindi configurando la directory del registro.

SnapCenter utilizza una directory del log host per memorizzare i dati di backup del log delle transazioni. Si tratta di un'operazione a livello di host e istanza. Ogni host SQL Server utilizzato da SnapCenter deve disporre di una directory del registro host configurata per eseguire i backup del registro. SnapCenter dispone di un repository di database, pertanto i metadati relativi alle operazioni di backup, ripristino o clonazione vengono memorizzati in un repository di database centrale.

La dimensione della directory del log host viene calcolata come segue:

Dimensione della directory del log host = dimensione del database di sistema + (dimensione massima del LDF del DB × tasso di cambiamento giornaliero del log % × (conservazione delle copie Snapshot) ÷ (1 – spazio di overhead del LUN %)

La formula di dimensionamento della directory del log host presuppone quanto segue:

Backup del database di sistema che non include il database tempdb
Uno spazio di overhead del LUN del 10%: Consente di creare una directory di log host su un volume dedicato o su un LUN. La quantità di dati nella directory del registro host dipende dalle dimensioni dei backup e dal numero di giorni in cui i backup vengono conservati.

Se il provisioning dei LUN è già stato eseguito, è possibile selezionare il punto di montaggio per rappresentare la directory del registro host.

Ora è possibile eseguire operazioni di backup, ripristino e clonazione per SQL Server.

Database di backup con SnapCenter

Dopo aver inserito il database e i file di log nelle LUN ONTAP FSX, è possibile utilizzare SnapCenter per eseguire il backup dei database. I seguenti processi vengono utilizzati per creare un backup completo.

Best Practice

In termini di SnapCenter, è possibile identificare RPO come frequenza di backup, ad esempio, con quale frequenza si desidera pianificare il backup in modo da ridurre la perdita di dati fino a pochi minuti. SnapCenter consente di pianificare i backup ogni cinque minuti. Tuttavia, potrebbero verificarsi alcuni casi in cui un backup potrebbe non essere completato entro cinque minuti durante i periodi di picco delle transazioni o quando il tasso di cambiamento dei dati è maggiore nel tempo specificato. Una Best practice consiste nel pianificare backup frequenti del log delle transazioni invece di backup completi.
Esistono numerosi approcci per gestire l'RPO e l'RTO. Un'alternativa a questo approccio al backup consiste nell'avere policy di backup separate per dati e log con intervalli diversi. Ad esempio, da SnapCenter, pianifica backup dei log a intervalli di 15 minuti e backup dei dati a intervalli di 6 ore.
Utilizzare un gruppo di risorse per una configurazione di backup per l'ottimizzazione Snapshot e il numero di lavori da gestire.
1. Selezionare risorse, quindi selezionare Microsoft SQL Server *dal menu a discesa in alto a sinistra. Selezionare *Aggiorna risorse.
2. Selezionare il database da sottoporre a backup, quindi selezionare Avanti e (*) per aggiungere il criterio se non è stato creato. Seguire la *New SQL Server Backup Policy per creare un nuovo criterio.
3. Se necessario, selezionare il server di verifica. Questo server è il server che SnapCenter esegue DBCC CHECKDB dopo la creazione di un backup completo. Fare clic su Avanti per la notifica, quindi selezionare Riepilogo per la revisione. Dopo la revisione, fare clic su fine.
4. Fare clic su Backup Now per verificare il backup. Nelle finestre a comparsa, selezionare Backup.
5. Selezionare Monitor per verificare che il backup sia stato completato.

Best Practice

Eseguire il backup del log delle transazioni da SnapCenter in modo che durante il processo di ripristino, SnapCenter possa leggere tutti i file di backup e ripristinarli automaticamente in sequenza.
Se per il backup vengono utilizzati prodotti di terze parti, selezionare Copia backup in SnapCenter per evitare problemi di sequenza di log e verificare la funzionalità di ripristino prima di passare alla produzione.

Ripristinare il database con SnapCenter

Uno dei principali vantaggi dell'utilizzo di FSX ONTAP con SQL Server su EC2 è la capacità di eseguire un ripristino rapido e granulare a ogni livello di database.

Completare i seguenti passaggi per ripristinare un singolo database a un punto specifico o fino al minuto con SnapCenter.

Selezionare Resources (risorse), quindi selezionare il database che si desidera ripristinare.
Selezionare il nome del backup da cui deve essere ripristinato il database, quindi selezionare Restore (Ripristina).
Seguire le finestre a comparsa Restore per ripristinare il database.
Selezionare Monitor per verificare che il processo di ripristino abbia esito positivo.

Considerazioni per un'istanza con un elevato numero di database di piccole o grandi dimensioni

SnapCenter può eseguire il backup di un gran numero di database importanti in un'istanza o in un gruppo di istanze all'interno di un gruppo di risorse. La dimensione di un database non è il fattore principale nel tempo di backup. La durata di un backup può variare a seconda del numero di LUN per volume, del carico su Microsoft SQL Server, del numero totale di database per istanza e, in particolare, della larghezza di banda e dell'utilizzo di i/O. Durante la configurazione del criterio per eseguire il backup dei database da un'istanza o da un gruppo di risorse, NetApp consiglia di limitare a 100 il numero massimo di database di cui è stato eseguito il backup per copia Snapshot per host. Assicurarsi che il numero totale di copie Snapshot non superi il limite di 1,023 copie.

NetApp consiglia inoltre di limitare i processi di backup eseguiti in parallelo raggruppando il numero di database invece di creare più processi per ogni database o istanza. Per ottenere prestazioni ottimali della durata del backup, ridurre il numero di processi di backup a un numero che può eseguire il backup di circa 100 database alla volta.

Come accennato in precedenza, l'utilizzo di i/o è un fattore importante nel processo di backup. Il processo di backup deve attendere fino al completamento di tutte le operazioni di i/o su un database. I database con operazioni di i/o altamente intensive devono essere posticipati a un altro tempo di backup o devono essere isolati da altri processi di backup per evitare di influenzare altre risorse all'interno dello stesso gruppo di risorse di cui si desidera eseguire il backup.

Per un ambiente con sei host Microsoft SQL Server che ospitano 200 database per istanza, presupponendo quattro LUN per host e un LUN per volume creato, impostare la policy di backup completa con il numero massimo di database di cui è stato eseguito il backup per copia Snapshot su 100. Duecento database su ciascuna istanza sono disposti come 200 file di dati distribuiti in parti uguali su due LUN e 200 file di log sono distribuiti in parti uguali su due LUN, ovvero 100 file per LUN per volume.

Pianificare tre processi di backup creando tre gruppi di risorse, ciascuno raggruppando due istanze che includono un totale di 400 database.

L'esecuzione di tutti e tre i processi di backup in parallelo esegue il backup di 1,200 database contemporaneamente. A seconda del carico sul server e dell'utilizzo di i/o, l'ora di inizio e di fine di ogni istanza può variare. In questo caso, viene creato un totale di 24 copie Snapshot.

Oltre al backup completo, NetApp consiglia di configurare un backup del log delle transazioni per i database critici. Assicurarsi che la proprietà del database sia impostata sul modello di ripristino completo.

Best practice

Non includere il database tempdb in un backup perché i dati in esso contenuti sono temporanei. Posizionare tempdb su una LUN o una condivisione SMB che si trova in un volume di sistema storage in cui non verranno create copie Snapshot.
Un'istanza di Microsoft SQL Server con un'applicazione che richiede elevati livelli di i/o deve essere isolata in un processo di backup diverso per ridurre i tempi di backup complessivi per altre risorse.
Limitare il set di database di cui eseguire il backup simultaneo a circa 100 e sfalsare il set rimanente di backup del database per evitare un processo simultaneo.
Utilizzare il nome dell'istanza di Microsoft SQL Server nel gruppo di risorse invece di più database, perché ogni volta che vengono creati nuovi database nell'istanza di Microsoft SQL Server, SnapCenter considera automaticamente un nuovo database per il backup.
Se si modifica la configurazione del database, ad esempio cambiando il modello di ripristino del database con il modello di ripristino completo, eseguire immediatamente un backup per consentire operazioni di ripristino aggiornate.
SnapCenter non è in grado di ripristinare i backup del log delle transazioni creati al di fuori di SnapCenter.
Quando si clonano volumi FlexVol, assicurarsi di disporre di spazio sufficiente per i metadati del clone.
Quando si ripristinano i database, assicurarsi che sul volume sia disponibile spazio sufficiente.
Creare una policy separata per gestire ed eseguire il backup dei database di sistema almeno una volta alla settimana.

Clonazione di database con SnapCenter

Per ripristinare un database in un'altra posizione in un ambiente di sviluppo o test o per creare una copia a scopo di analisi aziendale, la Best practice di NetApp consiste nel sfruttare la metodologia di cloning per creare una copia del database sulla stessa istanza o su un'istanza alternativa.

La clonazione di database da 500 GB su un disco iSCSI ospitato in un ambiente FSX per ONTAP richiede in genere meno di cinque minuti. Una volta completata la clonazione, l'utente può eseguire tutte le operazioni di lettura/scrittura necessarie sul database clonato. La maggior parte del tempo viene utilizzata per la scansione dei dischi (diskpart). La procedura di cloning di NetApp richiede in genere meno di 2 minuti, indipendentemente dalle dimensioni dei database.

La clonazione di un database può essere eseguita con il metodo dual: È possibile creare un clone dall'ultimo backup oppure utilizzare la gestione del ciclo di vita dei cloni attraverso la quale è possibile rendere disponibile l'ultima copia sull'istanza secondaria.

SnapCenter consente di montare la copia clone sul disco richiesto per mantenere il formato della struttura di cartelle sull'istanza secondaria e continuare a pianificare i processi di backup.

Clonare i database con il nuovo nome del database nella stessa istanza

Per clonare i database con il nuovo nome del database nella stessa istanza di SQL Server in esecuzione su EC2, è possibile utilizzare i seguenti passaggi:

Selezionare Resources (risorse), quindi il database da clonare.
Selezionare il nome del backup che si desidera clonare e selezionare Clone (Clona).
Seguire le istruzioni del clone dalle finestre di backup per completare il processo.
Selezionare Monitor per assicurarsi che la clonazione sia stata completata.

Clonare i database nella nuova istanza di SQL Server in esecuzione su EC2

La seguente procedura viene utilizzata per clonare i database nella nuova istanza di SQL Server in esecuzione su EC2:

Creare un nuovo SQL Server su EC2 nello stesso VPC.
Abilitare il protocollo iSCSI e MPIO, quindi configurare la connessione iSCSI a FSX per ONTAP seguendo i passaggi 3 e 4 della sezione "creazione di volumi e LUN per SQL Server".
Aggiungere un nuovo SQL Server su EC2 in SnapCenter seguendo il passaggio 3 della sezione "Installazione e configurazione di SnapCenter".
Selezionare Resource > View Instance (risorsa > Visualizza istanza), quindi Refresh Resource (Aggiorna risorsa).
Selezionare risorse, quindi il database che si desidera clonare.
Selezionare il nome del backup che si desidera clonare, quindi selezionare Clone (Clona).
Seguire le istruzioni Clone from Backup fornendo la nuova istanza di SQL Server su EC2 e il nome dell'istanza per completare il processo di clonazione.
Selezionare Monitor per assicurarsi che la clonazione sia stata completata.

Per ulteriori informazioni su questo processo, guarda il seguente video:

Clonare i database nella nuova istanza di SQL Server in esecuzione su EC2

Appendici

Appendice A: File YAML da utilizzare nel modello di formazione cloud

Il seguente file .yaml può essere utilizzato con Cloud Formation Template in AWS Console.

"https://github.com/NetApp/fsxn-iscsisetup-cft"

Per automatizzare la creazione di LUN ISCSI e l'installazione di NetApp SnapCenter con PowerShell, clonare il repo da "Questo link GitHub".

Appendice B: Script PowerShell per il provisioning di volumi e LUN

Il seguente script viene utilizzato per eseguire il provisioning di volumi e LUN e per impostare iSCSI in base alle istruzioni fornite in precedenza. Esistono due script PowerShell:

_EnableMPIO.ps1

Function Install_MPIO_ssh {
    $hostname = $env:COMPUTERNAME
    $hostname = $hostname.Replace('-','_')

    #Add schedule action for the next step
    $path = Get-Location
    $path = $path.Path + '\2_CreateDisks.ps1'
    $arg = '-NoProfile -WindowStyle Hidden -File ' +$path
    $schAction = New-ScheduledTaskAction -Execute "Powershell.exe" -Argument $arg
    $schTrigger = New-ScheduledTaskTrigger -AtStartup
    $schPrincipal = New-ScheduledTaskPrincipal -UserId "NT AUTHORITY\SYSTEM" -LogonType ServiceAccount -RunLevel Highest
    $return = Register-ScheduledTask -Action $schAction -Trigger $schTrigger -TaskName "Create Vols and LUNs" -Description "Scheduled Task to run configuration Script At Startup" -Principal $schPrincipal
    #Install -Module Posh-SSH
    Write-host 'Enable MPIO and SSH for PowerShell' -ForegroundColor Yellow
    $return = Find-PackageProvider -Name 'Nuget' -ForceBootstrap -IncludeDependencies
    $return = Find-Module PoSH-SSH | Install-Module -Force
    #Install Multipath-IO with PowerShell using elevated privileges in Windows Servers
    Write-host 'Enable MPIO' -ForegroundColor Yellow
    $return = Install-WindowsFeature -name Multipath-IO -Restart
}
Install_MPIO_ssh
Remove-Item -Path $MyInvocation.MyCommand.Source

_CreateDisks.ps1

....
#Enable MPIO and Start iSCSI Service
Function PrepISCSI {
    $return = Enable-MSDSMAutomaticClaim -BusType iSCSI
    #Start iSCSI service with PowerShell using elevated privileges in Windows Servers
    $return = Start-service -Name msiscsi
    $return = Set-Service -Name msiscsi -StartupType Automatic
}
Function Create_igroup_vols_luns ($fsxN){
    $hostname = $env:COMPUTERNAME
    $hostname = $hostname.Replace('-','_')
    $volsluns = @()
    for ($i = 1;$i -lt 10;$i++){
        if ($i -eq 9){
            $volsluns +=(@{volname=('v_'+$hostname+'_log');volsize=$fsxN.logvolsize;lunname=('l_'+$hostname+'_log');lunsize=$fsxN.loglunsize})
        } else {
            $volsluns +=(@{volname=('v_'+$hostname+'_data'+[string]$i);volsize=$fsxN.datavolsize;lunname=('l_'+$hostname+'_data'+[string]$i);lunsize=$fsxN.datalunsize})
        }
    }
    $secStringPassword = ConvertTo-SecureString $fsxN.password -AsPlainText -Force
    $credObject = New-Object System.Management.Automation.PSCredential ($fsxN.login, $secStringPassword)
    $igroup = 'igrp_'+$hostname
    #Connect to FSx N filesystem
    $session = New-SSHSession -ComputerName $fsxN.svmip -Credential $credObject -AcceptKey:$true
    #Create igroup
    Write-host 'Creating igroup' -ForegroundColor Yellow
    #Find Windows initiator Name with PowerShell using elevated privileges in Windows Servers
    $initport = Get-InitiatorPort | select -ExpandProperty NodeAddress
    $sshcmd = 'igroup create -igroup ' + $igroup + ' -protocol iscsi -ostype windows -initiator ' + $initport
    $ret = Invoke-SSHCommand -Command $sshcmd -SSHSession $session
    #Create vols
    Write-host 'Creating Volumes' -ForegroundColor Yellow
    foreach ($vollun in $volsluns){
        $sshcmd = 'vol create ' + $vollun.volname + ' -aggregate aggr1 -size ' + $vollun.volsize #+ ' -vserver ' + $vserver
        $return = Invoke-SSHCommand -Command $sshcmd -SSHSession $session
    }
    #Create LUNs and mapped LUN to igroup
    Write-host 'Creating LUNs and map to igroup' -ForegroundColor Yellow
    foreach ($vollun in $volsluns){
        $sshcmd = "lun create -path /vol/" + $vollun.volname + "/" + $vollun.lunname + " -size " + $vollun.lunsize + " -ostype Windows_2008 " #-vserver " +$vserver
        $return = Invoke-SSHCommand -Command $sshcmd -SSHSession $session
        #map all luns to igroup
        $sshcmd = "lun map -path /vol/" + $vollun.volname + "/" + $vollun.lunname + " -igroup " + $igroup
        $return = Invoke-SSHCommand -Command $sshcmd -SSHSession $session
    }
}
Function Connect_iSCSI_to_SVM ($TargetPortals){
    Write-host 'Online, Initialize and format disks' -ForegroundColor Yellow
    #Connect Windows Server to svm with iSCSI target.
    foreach ($TargetPortal in $TargetPortals) {
        New-IscsiTargetPortal -TargetPortalAddress $TargetPortal
        for ($i = 1; $i -lt 5; $i++){
            $return = Connect-IscsiTarget -IsMultipathEnabled $true -IsPersistent $true -NodeAddress (Get-iscsiTarget | select -ExpandProperty NodeAddress)
        }
    }
}
Function Create_Partition_Format_Disks{

    #Create Partion and format disk
    $disks = Get-Disk | where PartitionStyle -eq raw
    foreach ($disk in $disks) {
        $return = Initialize-Disk $disk.Number
        $partition = New-Partition -DiskNumber $disk.Number -AssignDriveLetter -UseMaximumSize | Format-Volume -FileSystem NTFS -AllocationUnitSize 65536 -Confirm:$false -Force
        #$return = Format-Volume -DriveLetter $partition.DriveLetter -FileSystem NTFS -AllocationUnitSize 65536
    }
}
Function UnregisterTask {
    Unregister-ScheduledTask -TaskName "Create Vols and LUNs" -Confirm:$false
}
Start-Sleep -s 30
$fsxN = @{svmip ='198.19.255.153';login = 'vsadmin';password='net@pp11';datavolsize='10GB';datalunsize='8GB';logvolsize='8GB';loglunsize='6GB'}
$TargetPortals = ('10.2.1.167', '10.2.2.12')
PrepISCSI
Create_igroup_vols_luns $fsxN
Connect_iSCSI_to_SVM $TargetPortals
Create_Partition_Format_Disks
UnregisterTask
Remove-Item -Path $MyInvocation.MyCommand.Source
....

Eseguire il file EnableMPIO.ps1 il primo e il secondo script vengono eseguite automaticamente dopo il riavvio del server. Questi script PowerShell possono essere rimossi dopo essere stati eseguiti a causa dell'accesso alle credenziali alla SVM.