Lo storage è una componente molto importante per qualsiasi installazione di SQL Server. Nelle sezioni successive discuteremo le varie tipologie di storage: collegato localmente o tramite SAN, con alcune considerazioni per il posizionamento dei file.
Storage locale
Se il server utilizza uno storage locale, allora si dovrebbe considerare attentamente il posizionamento dei file. Per sua stessa natura, SQL Server è spesso vincolato a operazioni di input/output (I/O) e, pertanto, la configurazione del sottosistema I/O è uno degli aspetti critici per le prestazioni. Si deve prevedere la separazione dei file di dati e dei file di transaction log dei database utente su dischi o array separati e anche separare il TempDB, che è il database di sistema più utilizzato. Se tutti questi file risiedono su un singolo volume, allora è probabile che si verifichi una contesa del disco mentre SQL Server tenta di scrivere su tutti contemporaneamente.
In genere, lo storage locale verrà presentato al server come array RAID (redundant array of inexpensive disks) e sono disponibili vari livelli RAID. Sono disponibili molti livelli RAID, ma i più comuni sono descritti di seguito.
Tipologia | Descrizione | Ridondanza | Note |
RAID 0 | E’ composto da almeno due fino a n dischi. I dati sono distribuiti su tutti i dischi all'interno dell'array. Fornisce prestazioni eccellenti; tuttavia, non fornisce alcuna tolleranza agli errori. La perdita di un disco all'interno dell'array significa che l'intero array fallirà. | No | Poiché RAID 0 non fornisce ridondanza, non dovrebbe essere utilizzato per i sistemi di produzione. |
RAID 1 | E’ composto da almeno due dischi, che lavorano insieme come una coppia speculare. Ciò fornisce ridondanza in caso di guasto di uno dei dischi, ma a scapito delle prestazioni di scrittura, perché ogni scrittura sul volume deve essere eseguita due volte. | RAID 1 fornisce ridondanza tramite il mirroring del disco. | La formula per calcolare gli IOPS totali (input/output al secondo) rispetto a un array RAID 1 è la seguente: IOPS = Letture + (Scritture * 2). |
RAID 5 | E’ composto da tre a n dischi e fornisce ridondanza di esattamente un disco all'interno dell'array. Poiché i blocchi di dati sono distribuiti su più dischi, le prestazioni di lettura del volume saranno molto buone, ma ancora una volta, ciò avviene a scapito delle prestazioni di scrittura. Le prestazioni di scrittura sono compromesse perché la ridondanza è ottenuta distribuendo bit di parità su tutti i dischi nell'array. Ciò significa che c'è una penalità di prestazioni di quattro scritture per ogni scrittura sul volume. Questo indipendentemente dal numero di dischi nell'array. Il motivo di questa penalità arbitraria è che i bit di parità sono suddivisi nello stesso modo in cui lo sono i dati. Il controller leggerà i dati originali e la parità originale e poi scriverà i nuovi dati e la nuova parità, senza dover leggere tutti gli altri dischi nell'array. | RAID 5 fornisce ridondanza tramite bit di parità | La formula per calcolare gli IOPS totali rispetto a un array RAiD 5 è la seguente: IOioPS = Lettura + (Scritture * 4). |
RAID 10 | E’ composto da quattro a n dischi, ma è sempre un numero pari. Fornisce la migliore combinazione di ridondanza e prestazioni. Funziona creando una sezione di mirror. I bit sono suddivisi, senza parità, su metà dei dischi all'interno dell'array, come per RAID 0, ma vengono poi replicati sull'altra metà dei dischi nell'array. È una combinazione di RAID 1 e RAID 0. | RAID 10 fornisce ridondanza eseguendo il mirroring di ogni disco all'interno della sezione | La formula per calcolare gli ioPS totali su un array RAiD 10 è la seguente: IOioPS = Letture + (Scritture * 2). |
Posizionamento File
In genere, si ritiene che RAID 0 non debba essere utilizzato per i file di SQL Server.
Tuttavia alcune correnti di pensiero suggeriscono che il RAID 0 potrebbe essere utilizzato per i file del Tempdb.
La logica è che un TempDB molto utilizzato spesso richiede prestazioni importanti e, poiché viene ricreato ogni volta che l'istanza si riavvia, non richiede ridondanza. Sembra perfettamente ragionevole, ma a pensare in termini di uptime, si capisce perché non si può essere d'accordo con questa opinione.
L’ istanza di SQL Server richiede il TempDB per funzionare. Se si perde il TempDB, l’istanza andrà in down e se il TempDB non può essere ricreato, non si sarà in grado di ripristinare l’istanza. Pertanto, se si ospita il TempDB su un array RAID 0 e uno dei dischi all'interno di quell'array si guasta, non si sarà in grado di ripristinare l'istanza finché non sarà eseguita una delle seguenti azioni:
- Attesa del team storage per ripristinare l’array RAID 0.
- Avviare l’istanza in “minimal configuration mode” ed utilizzare SQLCMD per cambiare il path del TempDB.
Per questo motivo, TempDB è generalmente meglio posizionato su un array RAID 10, quando possibile. Ciò fornirà il miglior livello di prestazioni per il database e, poiché le sue dimensioni sono significativamente inferiori ai file del database utente, non si avrà lo stesso livello di implicazione sui costi.
Idealmente i file di dati dei database utente saranno archiviati su array RAID 10, poiché RAID 10 fornisce la migliore combinazione di ridondanza e prestazioni.
Nel mondo reale, tuttavia, se le applicazioni presenti non sono mission critical, il costo potrebbe non essere giustificabile.
Se questa è la situazione, allora RAID 5 può essere una buona scelta, a patto che le applicazioni abbiano un rapporto abbastanza alto tra letture e scritture. Normalmente si potrebbe utilizzare un rapporto di tre a uno a favore delle letture come buona base di partenza, ma ovviamente questo può variare in ogni scenario.
Se i database utilizzano solo le funzionalità di base di SQL Server, probabilmente si scoprirà che RAID 1 è una buona scelta per i tuoi file di log. RAID 5 non è generalmente adatto, a causa della natura di scrittura intensiva del log delle transazioni.
Tuttavia, alcune funzionalità di SQL Server possono generare un'attività di lettura massiva dal transaction log. Se questo è il caso, si potrebbe scoprire che RAID 10 è un requisito per il tuo transaction log e per i tuoi file di dati. Le funzionalità che causano letture del registro delle transazioni includono quanto segue:
- AlwaysOn availability groups
- Database mirroring
- Snapshot creation
- Backups
- DBCC CHECKDB
- Change data capture
- Log shipping (sia backups, che in caso di restoring dei log con opzione WITH STANDBY)
Solid-State Drives (SSDs)
Un motivo comune per utilizzare uno storage locale, al contrario di una storage area network (SAN), è ottimizzare le prestazioni dei componenti di SQL Server, che richiedono I/O estremamente rapidi. Questi componenti includono TempDB e estensioni della buffer cache. Non è raro scoprire che i dati e i file di transaction log di un database sono archiviati su una SAN, ma TempDB ed estensioni buffer cache sono posizionati su uno storage locale.
In questo scenario, avrebbe senso utilizzare SSD nello storage locale.
Le unità disco a stato solido (SSD) possono offrire velocità di I/O molto elevate, ma a un costo più elevato rispetto ai dischi tradizionali. Le SSD non sono neanche una "soluzione magica". Sebbene offrano un numero molto elevato di IOPS per l'accesso random al disco, possono essere meno efficienti per le attività di scansione sequenziale, che sono comuni in determinati profili di carico di lavoro del database, come i datawarehouse.
Gli SSD sono anche soggetti a guasti improvvisi, al contrario del declino graduale di un disco tradizionale. Pertanto, avere un livello RAID fault-tolerant e hot spare nell'array è un'ottima idea.
Lavorare con una SAN
Storage area network è un concetto che può incutere timore ad un amministratore di database (DBA). Il DBA moderno deve abbracciare concetti come SAN e virtualizzazione; tuttavia, sebbene pongano un cambiamento fondamentale, facilitano anche la gestibilità complessiva dell’infrastruttura e riducono il costo totale di proprietà.
La cosa più importante che un DBA deve ricordare di una SAN è che cambia i principi fondamentali del sottosistema I/O e i DBA devono cambiare il loro modo di pensare di conseguenza.
Ad esempio, nel mondo dello storage locale, il principio fondamentale è separare i file di dati, i file di log e TempDB e assicurarsi che siano tutti ospitati sul livello RAID più appropriato.
Nel mondo delle SAN, tuttavia, ci si potrebbe inizialmente allarmare nello scoprire che gli amministratori della SAN non offrono una scelta del livello RAID e, se lo fanno, potrebbero non offrire RAID 10. Se si scopre che è questo il caso, è probabile che la SAN stia, dietro le quinte, effettivamente estraendo i dati da ogni disco nell'array. Ciò significa che, sebbene il livello RAID possa ancora avere un certo impatto sul throughput, la considerazione più importante è quale livello di storage scegliere.
Molte organizzazioni scelgono di suddividere lo storage sulla loro SAN, offrendo tre o più livelli. Il livello 1 sarà il livello più alto e potrebbe essere costituito da una combinazione di SSD e piccole unità Fiber Channel ad alte prestazioni. Il livello 2 sarà normalmente costituito da unità più grandi, potenzialmente SATA (Serial Advanced Technology Attachment), e il livello 3 utilizzerà spesso lo storage near-line. Lo storage near-line è costituito da un gran numero di dischi economici, come i dischi SATA, che di solito vengono fermati. I dischi si avviano solo quando è necessario accedere ai dati in essi contenuti. Come probabilmente avrai intuito, vorrai assicurarti che tutte le applicazioni che richiedono buone prestazioni debbano essere posizionate sul livello 1 del tuo SAN. Il livello 2 potrebbe essere un'opzione per database piccoli e raramente utilizzati con poca o nessuna concorrenza, e il livello 3 dovrebbe essere raramente, se non mai, utilizzato per archiviare database o log di SQL Server.
Il throughput effettivo sarà determinata da questi fattori, ma anche da molti altri, come il numero di percorsi di rete tra il server e la SAN, il numero di server che accedono contemporaneamente alla SAN e così via.
Successivamente, considera che poiché tutti i tuoi dati potrebbero essere distribuiti su tutti i dischi nell'array, non dovresti aspettarti un miglioramento immediato delle prestazioni separando i tuoi file di dati, log e TempDB.
Molti DBA, tuttavia, scelgono ancora di posizionare i propri dati, log e file TempDB su dischi separati per separazione logica e coerenza con altri server che utilizzano storage collegato localmente. In alcuni casi, tuttavia, se si utilizzano snapshot della SAN o repliche della SAN per ridondanza, potrebbe essere necessario disporre di file di dati e log di un database sullo stesso volume. Questo dovrebbe essere verificato con il team sistemistico.
Disk Block Size
Un'altra cosa da considerare per la configurazione del disco, sia che sia collegato localmente o su una SAN, è la block size del disco.
A seconda dello storage, è probabile che la dimensione predefinita dell'unità di allocazione NTFS (New Technology File System) sia impostata su 4 KB.
Il problema è che SQL Server organizza i dati in otto pagine continue da 8 KB, note come extent.
Per ottenere prestazioni ottimali per SQL Server, le block size dei volumi che ospitano dati, log e TempDB devono essere allineate e impostate su 64 KB.
di Alice Sella, pubblicato il 6 febbraio 2026