Questo articolo è stato scritto per dare una mano a chi come me commette un piccolo ma grande errore di distrazione sulla verifica dei requisiti prima dell’installazione di un istanza SQL Server .
Questa mattina ho installato un nuovo cluster per SQL Server 2016 , ma purtroppo non ho controllato bene quando mi è stato consegnato , quindi ho eseguito tranqullamente il setup dei nodi salvo poi accorgermi durante la parametrizzazione e i controlli di rito che i dischi non erano formattati 64k.
Errore da pivello , che ad ogni modo va assolutamente corretto rapidamente , quindi , che si fa ?
Ho il nuovo server pronto, configurato con basi dati , utenti , procedure , linked , tutto migrato , ma con questo neo da sistemare, fortunatamente la macchina non è andata ancora in produzione .
Il lato positivo di tutta questa vicenda è proprio questo , non dovrò informare nessuna divisione di un eventuale fermo dei servizi , non ci lavora ancora nessuno , almeno questo mi consente di lavorare con un buon grado di serenità , che non guasta mai.
Come procedere ora ?
Fortunatamente ho ancora molto spazio sui dischi , quindi si può procedere spostando i dati da un unità all’altra , lavorando su un disco per volta.
La domanda potrebbe essere ma perché non lasciare tutto così visto che tutto funziona e non ci sono segnalazioni di errore ?
perchè prendersi la bega di riformattare ?
Perché il sosttosistema disco per SQL server è uno dei fattori prestazionali più sensibili e che in molti scenari può rappresentare il collo di bottiglia principale o comunque concorrere alla creazione di altri problemi di performance sulle transazioni.
In origine la partizione che ho trovato era una partizione ReFS , le best practices di sql server prescrivono una formattazione NTFS a 64k . La modalita ReFS ( Resilient File System ) è un file system creato da Microsoft , è stata pensata per aumentare l’affidabilità e la disponibilità dei dati su data set di grandi dimensioni . E’ stato introdotto ufficialmente con windows server 2012. Rapindamente le caratteristiche principali di questa tipologia di partizioni risiedono nel fatto che garantisce una resilienza maggiore in virtù del fatto che tiene traccia del checksum di tutti i files , inoltre è in grado di effettuare eventuali riparazioni senza alcun riavvio.
Questa parte è molto interessante vengono creati degli indici B-tree stile database per memorizzare i metadati.
Altra caratteristica importante è relativa alla capacità per l’indirizzo delle cartelle che passa dai 255 caratteri dell ‘ NTFS ai 32768 dell’ReFS ha una serie di altri pregi e di difetti ma non abbiamo tempo e modo di analizzarli in questo articolo.
https://it.wikipedia.org/wiki/ReFS
Tuttavia non è universalmente considerata più vantaggiosa durante l’uso di SQL Server ,attualmente come anticipato quella consigliata da Microsoft per SQL Server rimane NTFS.
Una cosa molto importante prima di procedere è quella di verificare è l’allineamento dell’offset delle partizioni .
Questa è un controllo che a volte viene trascurato ma è molto importante per l’impatto che ha sulle prestazioni.
Nel nostro caso avendo windows server 2012 , e LUN formattate nuove non abbiamo questa incombenza ma se dovessimo lavorare su un computer installato prima di windows 2008 per bonificarlo dal problema abbiamo bisogno di prendere in considerazione questa nota.
Prima di windows server 2008 il primo blocco allocato era di 63k , questo creava un problema perchè il sistema operativo scrive blocchi a 64k , per questo un mancato allineamento delle partizioni crea un notevole degrado di prestazioni poiché una scrittura da 64 k verrà allocata in due settori .
Nel nostro caso come anticipato adottando windows server 2012 il problema è risolto direttamente da microsoft , ma possiamo verificarlo in questo modo :
da prompt wmic partition get Index, Name, StartingOffset
Il numero che torna dovrà essere divisibile 4096 , se il risultato sarà decimale avremo la necessità di intervenire per correggere la situazione.
Facciamo un esempio :
Offset 1048576 : 4096 = 255
Altra verifica è nella chiave di registro :
HKLM \SYSTEM\CurrentControlSet\services\vds\Alignment
Similmente al discorso dell’offset l’unità di allocazione è ugualmente importante e fondamentale per le prestazioni del disco . SQL Server scrive pagine da 8k ed extend da 64k , come dicevamo da windows server 2003 e precedenti l’offset di start era di 31,5k , questo ovviamente crea dei problemi a SQL Server, anche se per alcuni tipi particolari di workloads nell’ambito dei quali potrebbe essere messo in discussione questo assunto dei 64k.
Quindi se troviamo una formattazione diversa da NTFS 64k è necessario eseguire la bonifica.
Allora la prima nostra preoccupazione sarà il backup , quindi a seconda della metodologia utilizzata e dei tools a nostra disposizione provvederemo al backup dei files sui quali lavoreremo.
Una volta eseguito il backup e messi al sicuro i nostri dati , dobbiamo spostare le nostre directory per liberare i dischi per la formattazione .
Per fare questa operazione abbiamo scelto robocopy che con i switch opportuni è in grado di copiare anche le ACL in modo da non creare problemi di permission successivi.
Procediamo , sulla prima istanza abbiamo 2 shared disk esposti dalla SAN nello specifico un Emc VPLEX con dischi extreme I\O ,
I dischi su cui dovremo lavorare sono D: e F: , dove il primo ospita i nostri dati ed il secondo i nostri log.
Prima di iniziare dobbiamo fermare i servizi di SQL per rilasciare i files di database e di log e poter operare tranquillamente.
Cominciamo con il disco dei log , creiamo una cartella di appoggio sul disco dei dati , sulla quale copiare i dati provenienti dal disco dei log. Importantissimo copiare i dati insieme alle ACL altrimenti successivamente si potrebbero innescare una serie di problemi di funzionamento. In nostro aiuto per questa attività viene il programma robocopy.exe , la sintassi che abbiamo utilizzato è questa :
robocopy.exe “f:\nomeistanza” “d:\appoggio\nomeistanza” /E /SECFIX /COPY:DATSOU /IS /IT /log:\log.txt /TEE
a questo punto apriamo la nostra consolle di gestione del cluster nella sezuone storage e mettiamo il nostro disco in maintenance mode
Ora siamo pronti per la formattazione apriamo la consolle di managment del server alla sezione storage e procediamo con una formattazione NTFS 64k.
ora possiamo rimettere al loro posto i nostri files di log usando lo script di prima con i percorsi invertiti
robocopy.exe “d:\appoggio\nomeistanza” “f:\nomeistanza” /E /SECFIX /COPY:DATSOU /IS /IT /log:\log.txt /TEE
ora possiamo cancellare la directory di appoggio.
Questa operazione deve essere ripetuta su entrambi i dischi , ci dobbiamo inoltre ricordare di togliere i dischi dalla condizione di manintenance mode
Ora abbiamo risolto il nostro problema con le unità di allocazione e possiamo finalmente portare in produzione il nostro nuovo server.
Quirino Scaramastra
Rispondi