En3pY :: Sebastian Zdrojewski

“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:

1. Incrementare lo spazio della LUN sullo storage
2. Rescan delle LUN sul server *nix
3. Ridimensionamento del disco fisico con pvextend
4. Aumento della dimensione del disco logico con lvextend
5. 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 Aste abbiamo fatto una serie di test sullo storage di E4 Engineering, il E6550.

La macchina che abbiamo in casa da vita alla seconda infrastruttura Fibre Channel del datacenter, dedicata ai servizi in outsourcing che verranno ora consolidati su questo dispositivo di memorizzazione. La macchina e’ configurata con doppio controller, quattro dischi da 750Gb SATA-2 (3Gbps di accesso) e 4 dischi da 146Gb SAS a 15Krpm (4Gbps). La rete F.C. e’ centralizzata su due switch Qlogic a 16 porte.

La prima cosa che decisamente risulta essere interessante e’ la coesistenza - sempre piu’ frequente sul mercato - di entrambe le tipologie di disco, SATA e SAS che coesistono promiscuamente nello stesso chasis. Questo consente agli amministratori di rete di dislocare sui dischi SATA dati che non richiedano una particolare velocita’ di accesso e caratterizzati - ovviamente - da un costo al Gb inferiore, ed avere la possibilita’ di ospitare anche dati che richiedono performance su dischi piu’ idonei (per esempio Mail Server o Database Server) sui dischi SAS.

Il cabling della macchina e del network F.C. e’ relativamente semplice. L’alimentazione e’ naturalmente ridondata, con alimentatori hot-swap, attestati su due linee elettriche indipendenti (DX ed SX). I controller, ridondati anch’essi, con due porte per controller sono attestati sui due switch che creano il backbone F.C., anch’essi nominati DX ed SX per distinguere i percorsi di ridondanza. Come si puo’ notare dalla foto, i controller devono essere cablati in un modo particolare. Seguendo la direzione delle fibre noterete che la porta A del controller 1 (superiore) va attestata sullo switch su cui e’ attestata la porta B del controller 2 (inferiore) nel nostro caso switch DX. Stessa cosa, ma inversa, per la porta B1 e A2, che devono essere cablate sul secondo switch F.C. (SX). Ogni controller, una porta di management seriale (quella col cavo grigio) e una ethernet (verde). Il connettore che si vede (poco) a destra delle interfacce di rete, e’ il connettore di espansione per i chasis di espansione (Jbod) ed e’ lo stesso connettore che si usa per le connessioni Infiniband. Anche nel caso delle interfacce di management via Ethernet, rete DX e rete SX.

La configurazione dello storage e’ piuttosto elementare. L’interfaccia di gestione e’ accessibile via HTTP o HTTPS, Telnet, SSH e naturalmente via seriale. La nostra scelta e’ stata fatta per il HTTPS ed SSH, disabilitando tutto il resto. La mancanza di applet java all’interno del pannello di configurazione rende il pannello di configurazione molto piu’ snello da gestire, poiche’ la JVM non deve essere invocata (a differenza dello Switch Manager o altre SAN).

I test condotti, una volta terminata la configurazione dei Virtual Disk (RAID) e dei Volumi sono stati quelli di stabilita in caso di fault. Il host collegato e’ un server E4 con un HBA Qlogic a due porte e VMware ESX 3.5. I test condotti sono stati relativamente semplici:

• Disconnessione di una delle due connessioni tra host e switch F.C.
• Disconnessione dei canali dei controller
• Disconnessione dalla rete elettrica di uno degli switch F.C.
• Distacco totale di un controller
• Distacco totale di un alimentatore

L’unico problema in cui siamo incappati e’ stato nella disconnessione dello switch F.C. per un’errata configurazione del MPIO. Al distacco dello switch VMware (che stava facendo una copia di macchine virtuali) e’ andato in errore. L’errore - che si pensava fosse dovuto alla mancanza della configurazione MPIO nel Kernel di VMWare - in realta’ e’ stato risolto con l’attivazione del supporto alla Virtualizzazione nel BIOS della motherboard (Intel) del server. Attivato il supporto, la stessa prova e’ stata rieseguita con successo.

Con questo devo dire che la configurazione hardware della SAN e’ stata un successo e relativamente semplice (in un’oretta abbiamo installato e cablato tutto), la parte di configurazione software la rimando ad un altro post.

Da sempre sono stato un maniaco dell’immagine: un datacenter deve essere non solo efficiente e ordinato: deve avere carattere, deve essere bello. Finalmente abbiamo deciso di dargliene un po’ 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!

Vai alla gallery

Maestose, argentee e soprattutto: SPARC!! Il nostro nuovo gestionale gira su questo gioiello

Visitare i datacenter di societa’ come i.Net (ma anche qualsiasi altro) e’ sempre un evento molto costruttivo. Ti fa capire le dinamiche economiche, politiche e tecniche che si celano dietro alla realizzazione di un datacenter (o di una Business Factory come la definiscono i signori del gruppo BT). Devo dire che il datacenter di i.Net e’ un gioiello tecnologico. Il giro fatto oggi all’evento ci ha consentito di andare a vedere sia le strutture dei servizi generali (condizionamento, generazione elettrica) che i locali di outsourcing veri e propri. La spiegazione di gran parte delle problematiche e’ stata in alcuni punti illuminante, mentre altre hanno confermato che il progetto datacenter (naturalmente non lontanamente paragonabile a quello di i.Net) che stiamo sviluppando e mettendo in atto presso la nostra realta’ e’ perfettamente in linea con gli standard dei datacenter piu’ evoluti.

E’ un periodo che continuo a “giocare” con le Storage Area Network. Ad inizio anno abbiamo installato il DS4700 di IBM: 7 dischi da 500Gb SATA per il Gruppo Editoriale. A febbraio gestiva solamente l’archivio delle edizioni dei giornali (giusto quei 400Gb di dati), oggi e’ stata affiancata da due switch F.C. a 16 porte e lo storage conta 16 dischi misti SATA e SAS. Devo dire che tra tutte le soluzioni storage basate su Fibre Channel il DS4700 e’ quello che mi da le soddisfazioni piu’ grandi sia come qualita’ del hardware, sia come prestazioni (anche se oggi e’ piuttosto sottoutilizzata). Un progetto a medio/lungo termine che sto cercando di portare avanti prevede l’utilizzo di questo storage (ovviamente tutto 4Gbps con doppi percorsi) per mettere in piedi un cluster active/standby per il database di Tera (il sistema editoriale del Gruppo) che altri non e’ che un SQL Server. Ma questa e’ un’altra battaglia.

Il DS4700 secondo benchmark ufficiali e’ uno storage che offre performance di fascia alta a prezzi non eccessivi (~ 40KEUR). Supporta dischi SAS F.C. a 4Gbps e SATA (chiamati da IBM Fiber - ATA) da 3GBps con capacita’ fino a 750Gb che possono essere contenute all’interno dello stesso enclosure grazie all’opzione “Intermix”. Come da capitolato di IBM, lo storage ha delle licenze per le “partizioni” (ossia le macchine che accedono allo storage) e per le funzioni addizionali (sistemi Microsoft Windows, sistemi Linux, sistemi Solaris, ecc.). Le altre opzioni degne di massima considerazione sono FlashCopy per istantanee del filesystem nonche’ Intellimirror (se non erro) per la replica dello storage finalizzata al Disaster Recovery. Il sistema e’ equipaggiato con controller da 2Gb di cache (nel nostro caso) interamente ridondato. Degno di nota il fatto che il enclosure consente di contenere fino a 16 dischi, a differenza dei 12 normalmente contenuti in altri sistemi storage visti in giro. Anche l’architettura interna e’ degna di considerazione: ogni disco ha un percorso di accesso dedicato (ovviamente ridondante) dal controller, a differenza delle altre soluzioni storage F.C. che hanno una topologia di accesso ai dischi ad anello, che rallente le operazioni di I/O.

Il DS4700 e’ stato il progenitore delle SAN e delle infrastrutture F.C. all’interno del nostro datacenter. Settimana scorsa e’ arrivata un altro storage F.C., di Sun Microsystems, appunto per il sistema gestionale. Il bello di avere un’infrastruttura F.C. in casa e’ che si entra in una fascia di servizi di livello decisamente superiore (e una corrente filosofica di gestione dello storage totalmente diversa). Il nuovo storage di Sun e’ stato inglobato nell’infrastruttura F.C. del Gruppo Editoriale, manovra che ha consentito di risparmiare una somma non indifferente sugli switch necessari per il suo corretto funzionamento (parliamo di cifre che si aggirano sui 15KEUR per due switch in fibra nuovi), e consentendo di avere in casa un sistema active/standby di indubbia qualita’ per termini di performance ed affidabilita’. Sull’architettura e benchmark di questa macchina non ho nessun tipo di informazione (ancora) perche’ e’ una scatola chiusa installataci dagli uomini del gestionale, ma e’ solo questione di tempo.

Oggi, infine terzo Storage analizzato e testato: si tratta del E-Storage 6550 di E4, dispositivo dual controller con 1Gb di cache per controller ad un prezzo di listino maledettamente accattivante (a partire da 10.800 EUR circa) che supporta sia dischi SATA che dischi SAS, promiscui come nel caso del DS4700, all’interno di un unico enclosure o - naturalmente - nei box di espansione addizionali (chiamati JBOD). Scalabile fino a 112 dischi questa sara’ la terza soluzione storage che andremo ad implementare entro fine anno, che andra’ a costituire la seconda infrastruttura Fibre Channel del nostro Datacenter, completamente separato da quello del gruppo editoriale e finalizzato all’erogazione dei servizi in outsourcing che richiedono capacita’ scalabili (servizi E-Mail, storage condiviso per i web server, storage on demand, backup, ecc).

Oggi siamo stati in E4 per vedere questa nuova macchina che dovrebbe arrivarci a Dicembre. Devo dire che e’ un gran bel pezzo di macchina. Il software di management e’ tutto web based Java-less (con mia somma gioia), unica osservazione e’ riguardante l’utilizzo di Safari che potrebbe causare malfunzionamenti alla macchina (reboot). La gestione dei RAID e’ denominata “Virtual Disk Management”, su cui successivamente si possono creare le LUN che piu’ si desidera. La gestione dei percorsi e degli accessi e’ piuttosto semplice una volta comprese le logiche con cui lavora la macchina, le funzionalita’ ACL lo rendono un dispositivo decisamente allineato con i dispositivi di storage di classe superiore (molto meglio del MSA1000 di HP che - in alcune versioni dei controller - non supporta per niente il controllo accessi alle LUN). Le espansioni dello storage, mediante l’aggiunta di addizionali JBOD, avviene utilizzando cavi Infiniband, per cui standard di mercato di fatto.

Penso che mi dara’ enormi soddisfazioni questo storage! :)

Questa cosa non mi era ancora capitata. Lavorando ad uno script molto quick e very dirty per sistemare i problemi di profili roaming di Citrix mi sono trovato davanti ad un muro che mi ha sbarrato la strada per due giorni. In pratica uno script in VB.NET che funzionava perfettamente in locale, messo in produzione su un server 2003 continuava ad andare in Exception. E gira e rigira, riscrivi il programma in un altro modo. Ho preso e copiato del codice da un’applicazione che avevo sviluppato in passato e…. non funzionava piu’ in locale! Due giorni di debug e poi mi son detto… ma si… proviamo a fare questo.

La porzione di codice incriminata e’:

Private Sub jobTicker_Tick(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles jobTicker.Tick

If Not scriptingWork.IsBusy() AndAlso listUsr.Items.Count > 0 Then

scriptingWork.RunWorkerAsync()

End If

End Sub

Non e’ assolutamente nulla di trascendentale. Bene: su XP SP2 (up-to-date) non voleva saperne di funzionare ma copiato sul server Windows 2003 funzionava!!!

Ancora una giornata d’inferno sul sistema editoriale. Alla fine rendez-vous alle 0:00 di stanotte per sistemare in via definitiva il problema. Ormai abbiamo capito che il problema e’ nel caricamento dei profili e nella loro gestione, per cui abbiamo concentrato tutta la nostra attenzione su questo problema. Da oggi i profili (finalmente) vengono correttamente scaricati dai server e i processi di accesso al sistema ora sono piu’ snelli e rapidi. Dai 10-12 minuti di attesa per la “Applicazione dei criteri di protezione locali” siamo scesi a meno di un minuto. Oggi e’ una giornata decisiva per capire se il lavoro fatto stanotte ci ha risolto il problema in modo definitivo.

La cosa buona e’ che dalle 8 di questa mattina le uniche telefonate arrivate erano per problemi applicativi e non di accesso al sistema, il che e’ buon segno. Tutti i nodi verranno al pettine, comunque, verso le 14, orario in cui tendenzialmente iniziano i veri problemi.

Penso che con l’attivita’ di stanotte abbiamo fatto un ulteriore passo avanti per risolvere un problema che sembra affliggere tutta l’utenza di Citrix a livello mondiale.

Non e’ andata come speravo… o meglio… come doveva andare… il sistema e’ ancora bloccato… non riesco a darmi pace, continuo a riesaminare e riesaminare i dati che ho tirato fuori stamattina… debug di quelli piu’ assidui, a vedere cosa fa il sistema mentre elabora il batch… DLL, filesystem, memoria… nessuna conclusione… trovato un altro problemino sulle cache dei dischi di sistema… eppure non ho risolto. A livello di sistema quelle macchine sono perfette, anche a volerlo non hanno nessun errore di configurazione.

Dicono che il nostro sistema sia identico a quello di un’altra realta’… io ho un presentimento sulla internazionalizzazione del sistema… sapremo lunedi’. Oggi penso che andro’ avanti sull’analisi del sistema di posta elettronica…

Sistema in produzione, eppure… gli script di GN3 non ne vogliono sapere di generare gli XML e le immagini da esportare. Ieri con Ivan pazzi a testare gli script di importazione dal server di produzione all’ambiente web, tutto a posto e oggi… sorpresa delle sorprese, l’esecuzione dello script VB che genera foto e articoli ci sputa fuori un gran bel “Microsoft Visual C++ Runtime Library Runtime Error!”. A quanto pare secondo una KB di Microsoft (articolo n. 916177) e’ un problema legato alla versione 6.6.8063 della DLL mfc42u.dll. Ho ricevuto solo ora la hotfix via email, sveglia puntata alle 5.00AM e domani mattina sparati in ufficio ad installarla. Con un pizzico di fortuna riesco a mettere la hotfix sul server prima che partano i job di acquisizione web, il che risolverebbe non pochi problemi, altrimenti vedo di finire lo script PHP che va a interrogare il DB MSSQL e estrapola le immagini direttamente sul filesystem. Sperem di farcela entro la deadline delle 7:30am.