Skip to main content
NetApp database solutions
La versione in lingua italiana fornita proviene da una traduzione automatica. Per eventuali incoerenze, fare riferimento alla versione in lingua inglese.

Progettazione di riferimento di alto livello in tempo reale

Collaboratori kevin-hoke
PDF

Questa sezione illustra la distribuzione in tempo reale di un database SQL in una configurazione AOAG utilizzando un volume SMB Azure NetApp Files .

  • Numero di nodi: 4

  • Numero di database: 21

  • Numero di gruppi di disponibilità: 4

  • Conservazione del backup: 7 giorni

  • Archivio di backup: 365 giorni

Nota L'implementazione di FCI con SQL Server su macchine virtuali di Azure con una condivisione di Azure NetApp Files fornisce un modello conveniente con una singola copia dei dati. Questa soluzione può prevenire problemi durante l'operazione di aggiunta file se il percorso del file è diverso dalla replica secondaria.

Figura che mostra il dialogo di input/output o che rappresenta il contenuto scritto

L'immagine seguente mostra i database all'interno di AOAG distribuiti tra i nodi.

Figura che mostra il dialogo di input/output o che rappresenta il contenuto scritto

Layout dei dati

I file del database utente (.mdf) e i file di registro delle transazioni del database utente (.ldf), insieme a tempDB, sono archiviati sullo stesso volume. Il livello di servizio è Ultra.

La configurazione è composta da quattro nodi e quattro AG. Tutti i 21 database (parte di Dynamic AX, SharePoint, broker di connessione RDS e servizi di indicizzazione) sono archiviati nei volumi Azure NetApp Files . I database sono bilanciati tra i nodi AOAG per utilizzare in modo efficace le risorse sui nodi. Vengono aggiunte quattro istanze D32 v3 nel WSFC, che partecipa alla configurazione AOAG. Questi quattro nodi vengono forniti nella rete virtuale di Azure e non vengono migrati da locale.

Note:

  • Se i log richiedono maggiori prestazioni e throughput a seconda della natura dell'applicazione e delle query eseguite, i file del database possono essere posizionati sul livello di servizio Premium e i log possono essere archiviati sul livello di servizio Ultra.

  • Se i file tempdb sono stati posizionati su Azure NetApp Files, il volume Azure NetApp Files deve essere separato dai file del database utente. Ecco un esempio di distribuzione dei file del database in AOAG.

Note:

  • Per mantenere i vantaggi della protezione dei dati basata sulla copia Snapshot, NetApp consiglia di non combinare dati e dati di registro nello stesso volume.

  • Un'operazione di aggiunta file eseguita sulla replica primaria potrebbe non riuscire sui database secondari se il percorso del file di un database secondario è diverso dal percorso del database primario corrispondente. Ciò può accadere se il percorso di condivisione è diverso sui nodi primario e secondario (a causa di account computer diversi). Questo errore potrebbe causare la sospensione dei database secondari. Se non è possibile prevedere il modello di crescita o di prestazioni e si prevede di aggiungere file in un secondo momento, un cluster di failover di SQL Server con Azure NetApp Files è una soluzione accettabile. Per la maggior parte delle distribuzioni, Azure NetApp Files soddisfa i requisiti di prestazioni.

Migrazione

Esistono diversi modi per migrare un database utente SQL Server locale a SQL Server in una macchina virtuale di Azure. La migrazione può avvenire sia online che offline. Le opzioni scelte dipendono dalla versione di SQL Server, dai requisiti aziendali e dagli SLA definiti all'interno dell'organizzazione. Per ridurre al minimo i tempi di inattività durante il processo di migrazione del database, NetApp consiglia di utilizzare l'opzione AlwaysOn o l'opzione di replica transazionale. Se non è possibile utilizzare questi metodi, è possibile migrare il database manualmente.

L'approccio più semplice e ampiamente testato per spostare i database tra macchine è il backup e il ripristino. In genere, è possibile iniziare con un backup del database seguito da una copia del backup del database in Azure. È quindi possibile ripristinare il database. Per ottenere le migliori prestazioni di trasferimento dati, migrare i file del database nella macchina virtuale di Azure utilizzando un file di backup compresso. La progettazione di alto livello a cui si fa riferimento in questo documento utilizza l'approccio di backup per l'archiviazione dei file di Azure con sincronizzazione dei file di Azure e quindi ripristina i file di Azure NetApp .

Nota Azure Migrate può essere utilizzato per individuare, valutare ed eseguire la migrazione dei carichi di lavoro di SQL Server.

Per eseguire una migrazione, completare i seguenti passaggi generali:

  1. In base alle tue esigenze, configura la connettività.

  2. Eseguire un backup completo del database in una posizione di condivisione file locale.

  3. Copiare i file di backup in una condivisione file di Azure con la sincronizzazione file di Azure.

  4. Fornire alla VM la versione desiderata di SQL Server.

  5. Copiare i file di backup nella VM utilizzando copy comando da un prompt dei comandi.

  6. Ripristinare i database completi su SQL Server su macchine virtuali di Azure.

Nota Per ripristinare 21 database ci sono volute circa nove ore. Questo approccio è specifico per questo scenario. Tuttavia, è possibile utilizzare altre tecniche di migrazione elencate di seguito, in base alla situazione e alle esigenze specifiche.

Altre opzioni di migrazione per spostare i dati da un SQL Server locale ad Azure NetApp Files includono quanto segue:

  • Scollegare i file di dati e di registro, copiarli nell'archivio BLOB di Azure e quindi collegarli a SQL Server nella macchina virtuale di Azure con una condivisione file ANF montata dall'URL.

  • Se si utilizza la distribuzione del gruppo di disponibilità Always On in locale, utilizzare "Aggiungi procedura guidata replica di Azure" per creare una replica in Azure e quindi eseguire il failover.

  • Utilizzare SQL Server "replica transazionale" per configurare l'istanza di Azure SQL Server come sottoscrittore, disabilitare la replica e indirizzare gli utenti all'istanza del database di Azure.

  • Spedire il disco rigido utilizzando il servizio Importa/Esportazione di Windows.

Backup e ripristino

Il backup e il ripristino sono aspetti importanti di qualsiasi distribuzione di SQL Server. È fondamentale disporre di una rete di sicurezza adeguata per ripristinare rapidamente i dati in caso di vari scenari di guasto e perdita, in combinazione con soluzioni ad alta disponibilità come AOAG. È possibile utilizzare lo strumento di quiesce del database di SQL Server, Azure Backup (streaming) o qualsiasi strumento di backup di terze parti come Commvault per eseguire un backup coerente con l'applicazione dei database,

La tecnologia Azure NetApp Files Snapshot consente di creare facilmente una copia point-in-time (PiT) dei database utente senza influire sulle prestazioni o sull'utilizzo della rete. Questa tecnologia consente inoltre di ripristinare una copia Snapshot su un nuovo volume o di riportare rapidamente il volume interessato allo stato in cui si trovava al momento della creazione della copia Snapshot utilizzando la funzione di ripristino del volume. Il processo di snapshot Azure NetApp Files è molto rapido ed efficiente e consente di effettuare più backup giornalieri, a differenza del backup in streaming offerto da Azure Backup. Grazie alla possibilità di eseguire più copie Snapshot in un dato giorno, i tempi RPO e RTO possono essere notevolmente ridotti. Per aggiungere coerenza all'applicazione in modo che i dati siano intatti e correttamente scaricati sul disco prima che venga eseguita la copia Snapshot, utilizzare lo strumento di quiesce del database SQL Server("Strumento SCSQLAPI" ; l'accesso a questo collegamento richiede le credenziali di accesso NetApp SSO). Questo strumento può essere eseguito da PowerShell, che mette in stato di quiescenza il database di SQL Server e a sua volta può acquisire una copia snapshot di archiviazione coerente con l'applicazione per i backup.

*Note: *

  • Lo strumento SCSQLAPI supporta solo le versioni 2016 e 2017 di SQL Server.

  • Lo strumento SCSQLAPI funziona solo con un database alla volta.

  • Isolare i file da ciascun database posizionandoli su un volume Azure NetApp Files separato.

A causa delle enormi limitazioni dell'API SCSQL, "Backup di Azure" è stato utilizzato per la protezione dei dati al fine di soddisfare i requisiti SLA. Offre un backup basato su flusso di SQL Server in esecuzione in Azure Virtual Machines e Azure NetApp Files. Azure Backup consente un RPO di 15 minuti con backup frequenti del log e ripristino PiT fino a un secondo.

Monitoraggio

Azure NetApp Files è integrato con Azure Monitor per i dati delle serie temporali e fornisce metriche sullo spazio di archiviazione allocato, sull'utilizzo effettivo dello spazio di archiviazione, sugli IOPS del volume, sulla velocità effettiva, sui byte di lettura/sec del disco, sui byte di scrittura/sec del disco, sulle letture/sec del disco e sulle scritture/sec del disco e sulla latenza associata. Questi dati possono essere utilizzati per identificare i colli di bottiglia negli avvisi e per eseguire controlli di integrità per verificare che la distribuzione di SQL Server sia in esecuzione in una configurazione ottimale.

In questo HLD, ScienceLogic viene utilizzato per monitorare Azure NetApp Files esponendo le metriche tramite l'entità servizio appropriata. L'immagine seguente è un esempio dell'opzione metrica Azure NetApp Files .

Figura che mostra il dialogo di input/output o che rappresenta il contenuto scritto

DevTest utilizzando cloni spessi

Con Azure NetApp Files è possibile creare copie istantanee dei database per testare le funzionalità che devono essere implementate utilizzando la struttura e il contenuto del database corrente durante i cicli di sviluppo dell'applicazione, per utilizzare gli strumenti di estrazione e manipolazione dei dati durante il popolamento dei data warehouse o persino per recuperare dati eliminati o modificati per errore. Questo processo non prevede la copia dei dati dai contenitori BLOB di Azure, il che lo rende molto efficiente. Una volta ripristinato, il volume può essere utilizzato per operazioni di lettura/scrittura, riducendo significativamente la convalida e il time-to-market. Deve essere utilizzato insieme a SCSQLAPI per garantire la coerenza dell'applicazione. Questo approccio fornisce un'ulteriore tecnica di ottimizzazione continua dei costi insieme ad Azure NetApp Files sfruttando l'opzione Ripristina in nuovo volume.

Note:

  • Il volume creato dalla copia Snapshot utilizzando l'opzione Ripristina nuovo volume consuma capacità dal pool di capacità.

  • È possibile eliminare i volumi clonati utilizzando REST o Azure CLI per evitare costi aggiuntivi (nel caso in cui sia necessario aumentare il pool di capacità).

Opzioni di archiviazione ibride

Sebbene NetApp consigli di utilizzare lo stesso storage per tutti i nodi nei gruppi di disponibilità di SQL Server, esistono scenari in cui è possibile utilizzare più opzioni di storage. Questo scenario è possibile per Azure NetApp Files in cui un nodo in AOAG è connesso a una condivisione file SMB Azure NetApp Files e il secondo nodo è connesso a un disco Azure Premium. In questi casi, assicurarsi che la condivisione SMB Azure NetApp Files contenga la copia primaria dei database utente e che il disco Premium venga utilizzato come copia secondaria.

Note:

  • In tali distribuzioni, per evitare problemi di failover, assicurarsi che la disponibilità continua sia abilitata sul volume SMB. In assenza di attributi costantemente disponibili, il database può non funzionare se è presente una manutenzione in background a livello di archiviazione.

  • Conservare la copia primaria del database nella condivisione file SMB Azure NetApp Files .

Continuità aziendale

In genere, il ripristino in caso di disastro è un aspetto da considerare in un secondo momento in qualsiasi implementazione. Tuttavia, il disaster recovery deve essere affrontato durante la fase iniziale di progettazione e implementazione per evitare qualsiasi impatto sulla tua attività. Con Azure NetApp Files, la funzionalità di replica tra regioni (CRR) può essere utilizzata per replicare i dati del volume a livello di blocco nella regione abbinata per gestire eventuali interruzioni regionali impreviste. Il volume di destinazione abilitato per CRR può essere utilizzato per operazioni di lettura, il che lo rende un candidato ideale per le simulazioni di disaster recovery. Inoltre, alla destinazione CRR può essere assegnato il livello di servizio più basso (ad esempio, Standard) per ridurre il TCO complessivo. In caso di failover, la replicazione può essere interrotta, rendendo il rispettivo volume idoneo alla lettura/scrittura. Inoltre, il livello di servizio del volume può essere modificato utilizzando la funzionalità di livello di servizio dinamico per ridurre significativamente i costi di ripristino di emergenza. Questa è un'altra caratteristica esclusiva di Azure NetApp Files con replica a blocchi all'interno di Azure.

Archivio di copie Snapshot a lungo termine

Molte organizzazioni devono conservare a lungo termine i dati snapshot dei file di database come requisito di conformità obbligatorio. Sebbene questo processo non sia utilizzato in questo HLD, può essere facilmente realizzato utilizzando un semplice script batch utilizzando "AzCopy" per copiare la directory degli snapshot nel contenitore BLOB di Azure. Lo script batch può essere attivato in base a una pianificazione specifica utilizzando attività pianificate. Il processo è semplice e comprende i seguenti passaggi:

  1. Scarica il file eseguibile AzCopy V10. Non c'è niente da installare perché è un exe file.

  2. Autorizzare AzCopy utilizzando un token SAS a livello di contenitore con le autorizzazioni appropriate.

  3. Dopo l'autorizzazione di AzCopy, inizia il trasferimento dei dati.

Note:

  • Nei file batch, assicurarsi di eseguire l'escape dei caratteri % che compaiono nei token SAS. Ciò può essere fatto aggiungendo un ulteriore carattere % accanto ai caratteri % esistenti nella stringa del token SAS.

  • IL "Trasferimento sicuro richiesto" l'impostazione di un account di archiviazione determina se la connessione a un account di archiviazione è protetta con Transport Layer Security (TLS). Questa impostazione è abilitata per impostazione predefinita. Il seguente esempio di script batch copia ricorsivamente i dati dalla directory di copia Snapshot a un contenitore Blob designato:

SET source="Z:\~snapshot"
echo %source%
SET dest="https://testanfacct.blob.core.windows.net/azcoptst?sp=racwdl&st=2020-10-21T18:41:35Z&se=2021-10-22T18:41:00Z&sv=2019-12-12&sr=c&sig=ZxRUJwFlLXgHS8As7HzXJOaDXXVJ7PxxIX3ACpx56XY%%3D"
echo %dest%

Il seguente cmd di esempio viene eseguito in PowerShell:

 –recursive
INFO: Scanning...
INFO: Any empty folders will not be processed, because source and/or destination doesn't have full folder support
Job b3731dd8-da61-9441-7281-17a4db09ce30 has started
Log file is located at: C:\Users\niyaz\.azcopy\b3731dd8-da61-9441-7281-17a4db09ce30.log
0.0 %, 0 Done, 0 Failed, 2 Pending, 0 Skipped, 2 Total,
INFO: azcopy.exe: A newer version 10.10.0 is available to download
0.0 %, 0 Done, 0 Failed, 2 Pending, 0 Skipped, 2 Total,
Job b3731dd8-da61-9441-7281-17a4db09ce30 summary
Elapsed Time (Minutes): 0.0333
Number of File Transfers: 2
Number of Folder Property Transfers: 0
Total Number of Transfers: 2
Number of Transfers Completed: 2
Number of Transfers Failed: 0
Number of Transfers Skipped: 0
TotalBytesTransferred: 5
Final Job Status: Completed

Note:

  • Una funzionalità di backup simile per la conservazione a lungo termine sarà presto disponibile in Azure NetApp Files.

  • Lo script batch può essere utilizzato in qualsiasi scenario che richieda la copia di dati nel contenitore BLOB di qualsiasi regione.

Ottimizzazione dei costi

Grazie alla riorganizzazione del volume e alla modifica dinamica del livello di servizio, completamente trasparente per il database, Azure NetApp Files consente continue ottimizzazioni dei costi in Azure. Questa funzionalità viene ampiamente utilizzata in questo HLD per evitare un eccesso di storage aggiuntivo per gestire i picchi di carico di lavoro.

Il ridimensionamento del volume può essere eseguito facilmente creando una funzione di Azure insieme ai log degli avvisi di Azure.