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

Panoramica

Collaboratori
PDF

La combinazione delle soluzioni storage ONTAP e Microsoft SQL Server genera design di storage per database di livello Enterprise in grado di soddisfare le più esigenti esigenze applicative odierne.

L'ottimizzazione di una soluzione SQL Server su ONTAP richiede la comprensione del modello e delle caratteristiche di i/o di SQL Server. Un layout di storage ben progettato per un database SQL Server deve supportare i requisiti relativi alle performance di SQL Server, offrendo al contempo la massima capacità di gestione dell'infrastruttura nel suo complesso. Un buon layout dello storage permette inoltre di avere successo nell'implementazione iniziale e di far crescere l'ambiente senza problemi nel tempo, con il crescere dell'azienda.

Progettazione dello storage dei dati

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, vedere "Posizionare i file di dati e di registro su unità separate".

Aggregati

Gli aggregati sono i container di storage di livello più basso per le configurazioni di storage NetApp. Su Internet esiste una documentazione legacy che consiglia di separare i/o su diversi set di unità sottostanti. Questa operazione non è consigliata con ONTAP. NetApp ha eseguito diverse prove di caratterizzazione dei carichi di lavoro i/o utilizzando aggregati condivisi e dedicati con file di dati e file di log delle transazioni separati. I test dimostrano che un aggregato di grandi dimensioni con più gruppi RAID e dischi ottimizza e migliora le performance dello storage ed è più semplice da gestire per due motivi:

  • Un aggregato di grandi dimensioni rende disponibili per tutti i file le funzionalità i/o di tutte le unità.

  • Un grande aggregato consente l'utilizzo più efficiente dello spazio su disco.

Per l'high Availability (ha), posiziona la replica sincrona secondaria di SQL Server Always on Availability Group su una Storage Virtual Machine (SVM) separata nell'aggregato. Per scopi di disaster recovery, posizionare la replica asincrona in un aggregato che fa parte di un cluster di storage separato nel sito di disaster recovery, con contenuto replicato utilizzando la tecnologia NetApp SnapMirror. NetApp consiglia di disporre di almeno il 10% di spazio libero in un aggregato per ottenere performance dello storage ottimali.

Volumi

i volumi vengono creati e risiedono all'interno degli aggregati. Questo termine talvolta causa confusione perché un volume ONTAP non è un LUN. Un volume ONTAP è un container di gestione per i dati. Un volume può contenere file, LUN o persino oggetti S3. Un volume non occupa spazio, ma viene utilizzato solo per la gestione dei dati contenuti.

Considerazioni sulla progettazione dei volumi

Prima di creare una progettazione di volumi di database, è importante comprendere in che modo il modello i/o di SQL Server e le relative caratteristiche variano in base al carico di lavoro e ai requisiti di backup e ripristino. Consulta i seguenti consigli NetApp per i volumi flessibili:

  • Evitare di condividere i volumi tra gli host. Ad esempio, anche se sarebbe possibile creare 2 LUN in un singolo volume e condividere ogni LUN con un host diverso, questo aspetto dovrebbe essere evitato perché complica la gestione.

  • Utilizzare i punti di montaggio NTFS invece delle lettere dell'unità per superare il limite di 26 lettere di unità in Windows. Quando si utilizzano punti di montaggio del volume, si consiglia di assegnare all'etichetta del volume lo stesso nome del punto di montaggio.

  • Se necessario, configurare un criterio di dimensionamento automatico dei volumi per evitare condizioni di spazio insufficiente. 17 Guida alle Best practice per Microsoft SQL Server con ONTAP © 2022 NetApp, Inc Tutti i diritti riservati.

  • Se si installa SQL Server su una condivisione SMB, assicurarsi che Unicode sia attivato sui volumi SMB per la creazione delle cartelle.

  • Impostare il valore di riserva snapshot nel volume su zero per semplificare il monitoraggio dal punto di vista operativo.

  • Disattivare le pianificazioni delle snapshot e i criteri di conservazione. Utilizzare invece SnapCenter per coordinare le copie Snapshot dei volumi di dati di SQL Server.

  • Posizionare i database di sistema di SQL Server su un volume dedicato.

  • Tempdb è un database di sistema utilizzato da SQL Server come area di lavoro temporanea, in particolare per operazioni DBCC CHECKDB i/o intensive. Pertanto, collocare questo database su un volume dedicato con un set separato di spindle. 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 SQL Server viene riavviato.

  • Collocare 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, inserire i file di log delle transazioni (.ldf) in un volume separato o VMDK 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.

LUN

  • Assicurarsi che i file del database utente e la directory di registro per l'archiviazione del backup del registro si trovino su volumi separati per evitare che il criterio di conservazione sovrascriva gli snapshot quando vengono utilizzati con la tecnologia SnapVault.

  • Non combinare file di database e non di database, come file di ricerca full-text, sullo stesso LUN.

  • L'inserimento di file secondari del database (come parte di un filegroup) in volumi separati migliora le prestazioni del database di SQL Server. Questa separazione è valida solo se il file del database .mdf` non condivide il LUN con altri .mdf file.

  • Se si creano LUN con DiskManager o altri strumenti, assicurarsi che la dimensione dell'unità di allocazione sia impostata su 64K per le partizioni durante la formattazione dei LUN.

  • Vedere "Microsoft Windows e MPIO nativo nelle Best practice ONTAP per le SAN moderne" Per applicare il supporto multipathing in Windows ai dispositivi iSCSI nelle proprietà MPIO.