Mar 1
Ridimensionamento a caldo di partizioni XFS
“Per quanto sia grosso il nostro storage, e’ inevitabilmente destinato ad esaurirsi” Questa forse e’ la prima regola dello storage management. La conseguenza diretta di un IT Manager o chi per esso, e’ di avere un sistema di storage non solo scalabile, ma anche in grado di estendere la propria capacita’ in modo piu’ o meno lineare in modo semplice e spesso, a “caldo”.
L’obiettivo del nostro lavoro, stavolta, era quello di riuscire a raggiungere i seguenti obiettivi:
- poter creare una LUN sulla SAN e ridimensionarla dinamicamente
- montare la LUN su un server Linux
- aumentare le dimensioni del mount point senza fermare le applicazioni che vi girano sopra
Il terzo punto e’ una caratteristica abbastanza ovvia e soprattutto fondamentale in alcuni ambiti. Prendiamo per esempio un servizio di posta elettronica che opera 24/7/365. Fermare il sottosistema di storage potrebbe rappresentare un problema talvolta. Allora si preferisce fare le operazioni “online” o “a caldo”. In ambiente Microsoft Windows, il ridimensionamento delle partizioni puo’ essere effettuato a caldo utilizzando il comando diskpart, con la funzione extend. Questa volta, pero’, abbiamo dovuto replicare la situazione anche in ambiente *nix.
Lo storage utilizzato in questo contesto e’ stato il E6550 di E4 Engineering, che in realta’ maschera un ferro DotHill. Abbiamo operato su un sottosistema di dischi basato su un RAID-5 realizzato su 4 dischi SATA-II da 750Gb. Il VirtualDisk iniziale era di 100Gb per il laboratorio. Lo storage supporta nativamente il ridimensionamento a caldo delle LUN, il che risponde al primo punto dei nostri obiettivi.
Per il sistema operativo la scelta e’ caduta su un fork di Fedora per questioni di compatibilita’ del hardware (il HBA di qLogic) e tempi stretti di implementazione. E con questa abbiamo raggiunto il scondo obiettivo. Il filesystem scelto e’ stato XFS poiche’ e’ l’unico - dichiarato - che supporta il ridimensionamento delle partizioni a caldo, senza l’impiego di strumenti di terze parti. Quest’ultima scelta ci consentiva di realizzare il terzo punto.
Il laboratorio realizzato consisteva nel montare volume da 100Gb sul server Linux (fisico), crearvi sopra il filesystem XFS, scriverci sopra dei dati. Successivamente il volume sarebbe stato incrementato di un certo valore (abbiamo aggiunto blocchi da 10Gb ogni volta).
Dopo una serie (lunga) di tentativi abbiamo realizzato (nostro malgrado) che xfs_growfs non supporta il ridimensionamento delle partizioni se non con l’ausilio di LVM, divenuto pertanto una scelta obbligata. La configurazione con LVM e’ stata molto piu’ semplice del previsto. Un unico disco fisico definito nel contesto di LVM (/dev/sdc), creato un virtualgroup con quel disco, e quindi un volume logico con lvcreate. Lo storage di 100Gb e’ stato formattato con filesystem XFS, e quindi montato. Ridimensionare la partizione pertanto e’ divenuta una procedura consolidata:
- Incrementare lo spazio della LUN sullo storage
- Rescan delle LUN sul server *nix
- Ridimensionamento del disco fisico con pvextend
- Aumento della dimensione del disco logico con lvextend
- Incremento della dimensione del mountpoint con xfs_growfs -d
Considerazioni
In effetti esistono soluzioni che consentono di estendere il filesystem in modi alternativi, aggiungendo volumi o dischi fisici al volume LVM stesso, oppure utilizzando software di terze parti (ne esistono diversi che avrebbero consentito anche l’utilizzo di ext3 o ReiserFS), tuttavia avendo a disposizione una SAN questo tipo di gestione dello storage non mi piace. Preferisco avere per le mani un volume unico, sebbene di dimensioni considerevoli. Avendo un sottosistema di I/O che gestisce le operazioni di scrittura su disco gli aspetti hardware sono un problema relativo, mentre la gestione dello spazio assume un ruolo cardine nell’attivita’ di gestione quotidiana dei sistemi.
Estendere un disco o un mount point e’ secondo me una delle funzioni piu’ importanti quando si inizia a parlare di volumi di dati consistenti. Su piattaforme Windows Server (e anche XP), questo tipo di operazione puo’ essere effettuata grazie al supporto nativo che NTFS offre all’amministratore di sistema: estendendo la capacita’ di una LUN su una SAN, al rescan dei dischi e’ possibile procedere all’estensione del volume senza fermare i sistemi in produzione. 
Quando si hanno dei dati con una certa fluttuazione e soprattutto continua, queste operazioni diventano una necessita’. Il nostro sistema editoriale, infatti, dispone di un DS4700. Su di esso manteniamo, oltre ai dati comuni, anche lo storico delle edizioni. Essendo uno storico, la capacita’ di questo storage e’ destinata a crescere con l’aumentare delle informazioni. Ieri il sistema era basato su dischi in un sottosistema tradizionale (DAS), quindi limitato dal hardware (controller) e dai fattori di forma (baie disco, midplane). Oggi su un’infrastruttura SAN, possiamo aggiungere spazio in base alle necessita’. La medesima funzionalita’ la offre anche il E6550, tuttavia il host e’ una macchina Linux la quale gestira’ sia un database che uno storage in linea con dati che possono crescere in tempi e proporzioni diverse. Di conseguenza un meccanismo di estensione del filesystem efficace e soprattutto sicuro era piu’ che necessario, e l’impiego di soluzioni di terze parti o - in questo caso molto peggio - Open Source introduceva delle variabili e dei rischi che su questa particolare infrastruttura non potevamo permetterci (decisamente un ambiente Mission Critical).
Un’ultima considerazione sull’amministrazione di una singola LUN di grosse dimensioni e piu’ LUN raggruppate in un volume logico. Intanto la semplicita’ di gestione, come detto prima. La seconda ragione e’ la gestione del backup: una singola LUN e’ piu’ mantenibile anche sotto questo aspetto: possono essere fatte delle snapshot del sistema utilizzando le funzionalita’ della SAN (flash copy, ecc.) il che semplifica notevolmente i processi di gestione dei backup dei dati, altro fattore assolutamente non indifferente.
Lo storage non e’ mai sufficiente per le nostre esigenze e, a seconda del business in cui operiamo, abbiamo esigenze drammaticamente diverse tra di loro. Le previsioni di crescita dello spazio su disco sono un’attivita’ importante, e anche le logiche di gestione dello spazio stesso. Una SAN sicuramente richiede investimenti maggiori rispetto a dischi interni alle macchine, tuttavia consente una gestione migliore degli spazi e una diversificazione della loro allocazione (magari oggetto di un altro testo).
Qualche tempo fa descrivevo in un post (Having fun with SANs) le varie opzioni SAN che sto vedendo in questo periodo. Nelle ultime due settimane, con 
Idea congiunta mia e di Aste83, ecco il risultato: 2 ore di lavoro, costo tecnicamente zero, un sacco di divertimento e soprattutto una soddisfazione per gli occhi e lo spirito!
