Vi siete mai chiesti come si sentisse Cassandra a prevedere il futuro?

Beh, io settimana scorsa un pochino sì, e vorrei raccontarvelo in questo post. Troverete sicuramente in queste ore e nei prossimi giorni numerosi articoli relativi alle nuove funzioni di Veeam Backup & Replication 7, tenute segrete a tutti fino ad oggi. Quello che vorrei offrirvi è la mia particolare visione del tutto…

Innanzitutto, di cosa stiamo parlando? Veeam aveva conservato due funzioni da annunciare per ultime, oltre alle 7 precedentemente presentate.

Una di esse era abbastanza prevedibile. Dopo aver introdotto con la versione 6.5 il Veeam Explorer for San Snapshots (VESS), che permetteva di effettuare i restore dalle SAN Snapshots di storage LeftHand, in questa nuova versione VESS aggiunge il supporto per 3Par, già annunciato, ma soprattutto la possibilità di effettuare i backup delle VM già salvate nelle snapshots. Limitato impatto sulle VM, snapshots VMware mantenute aperte per poco tempo, e quindi un migliore RPO.

Vi suona interessante? Ne avevo parlato lo scorso 29 Gennaio, nel post E’ ora di avere degli “Storage Aware” backups?. Ecco come funziona in Veeam:

Leggetevi il mio post, leggetevi le note rilasciate da Veeam, e vedrete quanto ci sono andato vicino!!

Se questa poteva essere una facile previsione, la seconda è ancora più incredibile.

L’altra funzione segreta e resa nota solo oggi, è il WAN Accelerator, ma per chi legge i miei articoli, potrebbe tranquillamente chiamarlo VeeaMover, di cui avevo parlato il 22 Gennaio scorso. Qui la precisione della previsione è stata quasi imbarazzante: introdotto come quarto ruolo dell’architettura Veeam Backup, il WAN Accelerator permetterà di copiare i backup di VM a piacimento (quindi non necessariamente quelle contenute in un set di backup) in altri storage, con frequenze e policy dedicate e separate da quelle dei backup sul sito primario, in formato forever incremental.

E’ stato chiamato WAN accelerator perchè Veeam ha deciso disviluppare internamente il sistema di caching e replica, invece di adottare qualche tecnologia esistente. Ecco lo schema logico del suo funzionamento:

Per gestire queste nuove funzioni, sarà necessario come detto (e da me previsto!) attivare un quarto ruolo nella Backup Infrastructure:

Un’altra cosa interessante infine, è la possibilità di utilizzare schemi di retention di tipo GFS sul WAN Accelerator, in modo che il repository remoto possegga differenti copie delle VM, sempre meno frequenti man mano che il tempo passa:

Sicuramente, il VeeaMover… ops scusate WAN Accelerator è un elemento di cui si sentiva pesantemente la mancanza. Veeam ha rimediato a questo con uno strumento che pare molto ben congegnato: dal momento che Veeam possiede a priori una mappa dei blocchi di ogni VM in ogni backup, realizzare una copia incrementale perpetua di questi blocchi stessi era per loro sicuramente possibile.

Rispetto alle mie considerazioni di inizio anno, parrebbe che anche la funzione hub-and-spoke sia possibile, dato che distribuendo diversi WAN Accelerator in sedi differenti e attivando differenti job di copia immagino si possano creare diverse copie contemporanee dei dati. Inoltre, uno schema GFS permette sicuramente di ottimizzare lo spazio disco di uno storage remoto, dove a differenza del backup primario non abbiamo necessità di mantenere tutti i backup più recenti, ma anzi è necessario mantenere versioni più vecchie dei nostri backup per soddisfare retention policies differenti.

Tweet

Per un responsabile della data protection, VSS è probabilmente una delle migliori funzioni che Microsoft ha introdotto negli ultimi 10 anni. A partire dalla sua introduzione questa funzione del sistema operativo ha consentito negli anni di realizzare backup consistenti degli applicativi, ma soprattutto di non dover più ricorrere a numerosi agenti specializzati per i singoli applicativi: è sufficiente che un programma sia compatibile con VSS, e un programma di backup può genericamente invocare le librerie VSS del sistema operativo, le quali dialogheranno con i vari applicativi registrati in VSS appunto.

Esistono oggigiorno numerosi applicativi compatibili con VSS, ovviamente tutti quelli Microsoft (Exchange, SQL, e anche Active Directory ad esempio), ma anche programmi di terze parti con ad esempio Oracle DB (a partire dalla versione 11g).

Purtroppo, esistono anche numerosi applicativi che dopo 10 anni appunto, ancora non supportano le librerie VSS. Nel mio caso specifico, ho dovuto realizzare un backup applicativo di Lotus Dominio, che non supporta VSS. Questo articolo quindi ha un doppio scopo: mostrarvi come si realizza il backup “application-aware” di Lotus Domino, e più in generale come si possono utilizzare i VMware Tools per aggirare in parte la mancanza del supporto VSS.

Innanzitutto, come indicato implicitamente nel titolo e nella precedente frase, la virtual machine di cui dobbiamo realizzare il backup deve avere i VMware tools installati e in esecuzione. I tools permettono al programma di backup di invocare due script, detti genericamente pre-freeze e post-thaw, tramite i quali è possibile compiere alcune operazioni rispettivamente prima e dopo l’esecuzione della snapshot da parte di vSphere. In questo modo, si può fare in modo che l’applicativo non compatibile con VSS venga messo in uno stato “quieto” senza dati pendenti, e in questo modo garantirne la consistenza.

Verificato il prerequisito dei tools, dovremo creare la nuova directory C:\Program Files\VMware\VMware Tools\backupscripts.d\. Se è già presente, è possibile che sia stata creata precedentemente da qualche agent di backup installato.

In questa directory, è possibile tecnicamente creare un unico script contenente tutti i comandi necessari. Io per comodità ho sempre lavorato in modo diverso: creo uno script generico, che chiamo master.bat, che contiene i puntatori per eseguire i due script finali di pre-freeze e post-thaw. Ecco il suo codice:

@echo off
if "%1" == "freeze" goto dofreeze
goto dothaw
:dofreeze
call c:\scripts\pre-freeze.bat
goto EOF
:dothaw
call c:\scripts\post-thaw.bat
:EOF

In questo modo, la parte di invocazione degli script è ultimata, ed è possibile testare i vari comandi pre e post job editando i due script specifici, migliorandoli e correggendoli dopo ogni prova. Mi è sempre sembrato un modo più pulito di gestire la quiescenza realizzata con i VMware Tools, ma ovviamente non è una regola assoluta.

Terminata la parte generale, veniamo ai due script. In molti casi, la quiescenza di un applicativo purtroppo deve essere realizzata arrestandolo completamente e riavviandolo dopo la snapshot, e Lotus Domino non fa differenza. Troverete pertanto in rete molti esempi in cui i due script non contengono altro che “net stop servizio” e “net start servizio”. Nel caso di Lotus Dominio, lo script di pre-freeze è più complesso dato che dopo aver arrestato il servizio verifica che non vi siano più processi attivi, e nel caso procede al loro arresto forzato. Ecco il codice:

pre-freeze.bat

Net Time \\%computername% >> C:\scripts\logs\freeze.log
rem ***************************************
rem creates and inventory of all running Domino processes
rem ***************************************
pslist | findstr /I /C:"nadminp" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"naldaemn" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"namgr" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"ncalconn" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"ncatalog" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"nchronos" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"ncollect" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"ncompact" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"nconvert" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"ndesign" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"ndircat" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"ndrt" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"ndsmgr" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"nevent" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"nfixup" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"nhttp" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"nhttpcgi" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"nimap" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"nimsgcnv" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"nisesctl" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"niseshlr" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"nldap" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"nlivecs" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"nlnotes" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"nlogin" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"nmtc" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"nnntp" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"nnsadmin" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"nnotesmm" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"nobject" >>C:\scripts\logs\pid.lst 
pslist | findstr /I /C:"nomsgcnv" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"nosesctl" >>C:\scripts\logs\pid.lst 
pslist | findstr /I /C:"noseshlr" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"notes" >>C:\scripts\logs\pid.lst 
pslist | findstr /I /C:"npop3c" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"npop3" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"nreport" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"nrouter" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"nreplica" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"nsapdmn" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"nsmtpmta" >>C:\scripts\logs\pid.lst 
pslist | findstr /I /C:"nsmtp" >>C:\scripts\logs\pid.lst 
pslist | findstr /I /C:"nstatlog" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"nstaddin" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"nstats" >>C:\scripts\logs\pid.lst 
pslist | findstr /I /C:"nsched" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"nservice" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"nserver" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"ntaskldr" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"ntsvinst" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"nupdate" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"nupdall" >>C:\scripts\logs\pid.lst 
pslist | findstr /I /C:"nwrdaemn" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"nweb" >>C:\scripts\logs\pid.lst 
pslist | findstr /I /C:"nxpcdmn" >>C:\scripts\logs\pid.lst 
pslist | findstr /I /C:"nccmta" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"ncctctl" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"nccmctl" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"nccttcp" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"nccbctl" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"nccmin" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"nccmout" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"nccdctl" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"nccdin" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"nccdout" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"ngdsscan" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"ngsscan" >>C:\scripts\logs\pid.lst
pslist | findstr /I /C:"ngstmgr" >>C:\scripts\logs\pid.lst
rem ***************************************
rem Stops Dominio daemon in a controller fashion
rem ***************************************
net stop "Lotus Domino Server (LotusDominoData)"
rem ***************************************
rem Wait a fair amount of time for processes to stop
rem ***************************************
Sleep 300
rem ***************************************
rem If some Domino processes are hanged, it kills all of them
rem ***************************************
for /f "tokens=2" %%I in (C:\scripts\logs\pid.lst ) do pskill %%I
Net Time \\%computername% >> C:\scripts\logs\freeze.log

Per verificare che lo script abbia fatto il suo dovere, scriviamo nel file freeze.log la data di esecuzione. L’unico parametro da variare è il tempo di Sleep: nell’esempio è impostato a 5 minuti, e potrebbe essere necessario aumentarlo in presenza di server di grandi dimensioni o particolarmente lenti.

Lo script di riavvio è ovviamente molto più semplice:

post-thaw.bat

net start "Lotus Domino Server (LotusDominodata)"

I due comandi vengono automaticamente invocati dai VMware tools in fase di creazione della snapshot della virtual machine, specificatamente prima e dopo la realizzazione della stessa. In questo modo, l’applicativo è fermo mentre la virtual machine viene congelata, e i suoi dati sono quindi consistenti. Il fermo può durare alcuni secondi o diversi minuti, in dipendenza di quali attività prevede lo script e dalla velocità dell’infrastruttura vSphere che ospita la virtual machine stessa. Bisogna quindi pianificare bene “quando” realizzare questo tipo di backup, perchè arrestando i servizi si crea un disservizio agli utenti.

Per testare lo script, è sufficiente realizzare una snapshot da vCenter scegliendo di utilizzare appunto la quiescence tramite VMware Tools. Noterete che l’esecuzione della snapshot, che solitamente impiegherebbe pochi secondi, in questo caso impiega molto più tempo, appunto per il tempo necessario ad eseguire lo script. Questo invece è lo stesso fenomeno visto dall’interno di un software di backup come Veeam.

Tweet

Nel precedente articolo, ho raccontato dell’acquisizione di NexGen da parte di Fusion-IO, quali sono stati gli elementi tecnologici e di business che hanno portato a questa acquisizione, e di come Fusion-IO intende modificare e potenziare l’approccio sul mercato di NexGen stessa. In questo articolo invece andremo a vedere come è fatta l’architettura NexGen, quali scelte progettuali sono state compiute, e quali vantaggi possiede.

Un rapido sguardo all’hardware

Innanzitutto, lo storage NexGen è un sistema midrange studiato per la gestione di applicativi principalmente virtualizzati. Il team che l’ha sviluppato (John Spiers come CEO e Kelly Long come CTO) è lo stesso che molti anni fa ha lanciato LeftHand, e questa eredità è lampante ad esempio nella scelta di iSCSI come protocollo di comunicazione.

Lo chassis occupa 3U, e presenta al suo interno 2 controller active-active. I controller montano al loro interno ognuno delle schede Fusion-IO non condivise, il cui contenuto viene quindi sincronizzato in tempo reale dal software di gestione ioControl sviluppato da NexGen stessa.

Una delle caratteristiche distintive rispetto ad altri storage è sicuramente la presenza di schede Fusion-IO. Secondo NexGen, l’uso delle flash cards davanti ai dischi permette di poter impiegare poi dischi ancora più larghi e “lenti” senza impattare le prestazioni complessive, poichè le flash memory sono molto più veloci dei dischi ssd. I dischi ssd infatti sono tutti connessi allo stesso controller, e quindi il collo di bottiglia spesso è il bus pci stesso, attraverso il quale passano TUTTI i dati che arrivano dai dischi, siano essi SSD o meccanici. Le schede Fusion-IO invece sono connesse direttamente al controller PCI-Express, e presentano quindi vincoli inferiori.

Esistono differenti modelli, che si differenziano per lo spazio disponibile a bordo, sia per quanto riguarda le Fusion-IO montate a bordo (da 730 Gb fino a 4.8 Tb) sia per i dischi SATA condivisi tra i due controller (da un minimo di 16 TB fino a 192 TB aggiungendo shelves). I vari modelli garantiscono prestazioni tra 50k e 150k IOPS  (4k, 50/50 read-write). Un elemento affascinante di questo design è la scalabilità nei due sensi: è possibile indistintamente aggiungere schede Fusion-IO o dischi SATA, a seconda che si necessiti di ulteriore storage performante o economico.

Come detto, la connettività esterna è unicamente iSCSI, erogata tramite 4 schede 10G o 4 schede 1G complessive sui due controller.

Garantire le prestazioni

Come detto, NexGen ha come mercato di riferimento i clienti midrange. Secondo l’analisi di NexGen stessa, e condivisa da Fusion-IO, questi clienti necessitano di uno storage univoco sul quale poter salvare ed eseguire differenti workload, siano essi esigenti in termini di prestazioni, o di spazio disco. Questo elemento è alla base della decisione di sviluppare uno storage ibrido, abbinando quindi un primo tier fatto con schede Fusion-IO (per le prestazioni) e un secondo tier con dischi meccanici (per lo spazio disco economico).

Uno dei problemi tipici degli storage ibridi, che NexGen ha cercato di risolvere, risiede nell’impredicibilità delle prestazioni. Spesso i blocchi di una VM non si trovano nel posto giusto al momento giusto (tipicamente nei dischi meccanici quando l’I/O iniizia a crescere), e l’autotiering fatica a soddisfare le richieste delle applicazioni. Il rischio, per molti clienti, è di dover dedicare un determinato storage a un particolare workload per isolarlo e garantirne le prestazioni. Esempio tipico in questo senso è VDI, per la sua natura di workload “invasivo” rispetto ad altri workload con cui convive.

I silos però sono un problema aggiuntivo, in quanto portano i clienti a dover gestire differenti storage, aumentando di conseguenza la complessità dell’infrastruttura e i problemi di gestione correlati. NexGen offre a questi clienti uno storage che consente di caricare su di esso tutti i tipi di workload, garantendo loro le prestazioni richieste. Vediamo come.

Secondo NexGen, il problema risiede nel fatto che le prestazioni sono regolate solitamente dagli algoritmi di caching e tiering, e non dai requisiti di business e dalle policy di utilizzo dei vari workload.

Attualmente, sebbene il sistema operativo ioControl di NexGen permetta controlli molto fini e granulari, all’utente finale sono stati risparmiati eccessivi parametri, e il tutto è consolidato in sole 5 policy che è possibile applicare. Queste vengono attivate in modo istantaneo e dinamico.

Un altro elemento di aumento delle prestazioni è la deduplica. Per ora implementata ad uno stadio iniziale, permette di risparmiare scritture e quindi accelerare l’uso dei dischi, e risparmiare il consumo delle celle delle Fusion-IO.

Infine, è molto interessante l’aver realizzato un sistema operativo molto customizzato, partendo non da una classica distribuzione Linux (parlavamo prima delle origini LeftHand, beh li si usava una CentOS…) ma direttamente dai sorgenti. Sempre nell’ottica di garantire prestazioni costanti e prevedibili, i ragazzi di NexGen hanno creato un OS che parte e viene eseguito totalmente in RAM; questo permette di non usare le Fusion-IO per le attività del sistema operativo stesso, e quindi ancora una volta preservarne la durata.

L’interfaccia

Anche l’iterfaccia è stata disegnata mantenendo come obiettivo principale le prestazioni. Questo ha significato due cose: l’interfaccia stessa è quando più leggera e compatibile con i vari browser, evitando elementi problematici come javascript e similii; e uno degli elementi fondamentali dell’interfaccia è la sua funzione di gateway verso l’analisi dei dati.

Puntando infatti molto sulle prestazioni e sul QoS, il sistema deve essere in grado di mostrare tutti i dati di performance disponibili, poterne personalizzare la visualizzazione. Per fare ciò, si è scelto un approccio molto radicale ma perfettamente coerente con gli obiettivi: tutta l’interfaccia è basata su JSON e REST APIs, che coprono il 100% dei comandi disponibili sia in GUI che in CLI. Questo vuol dire che sia la riga di comando che l’interfaccia grafica, in realtà sono soltanto dei framework per accedere alla vera interfaccia, che è appunto basata su API.

La cosa che più mi ha affiscinato dell’interfaccia è la sua estrema semplicità: pochi pulsanti, subito disponibili le funzioni necessarie e l’accesso alle metriche, e un senso generale di estrema pulizia e velocità.

Integrazione con VMware

Per quanto riguarda l’integrazione con VMware, innanzitutto è bene ricordare che questo storage è di tipo active-active, o per dirla ancora meglio ALUA. Non esiste un controller che diventa l’unico proprietario delle LUN, ma piuttosto un path preferito rispetto ad un altro. L’I/O può invece sopraggiungere da qualsiasi path.

Detto ciò, ad oggi l’integrazione è principalmente affidata al plugin per vCenter. E’ interessante l’astrazione che è stata portata in questo elemento, cercando di nascondere il più possibile lo storage e permettere a un amministratore vSphere di usare termini cui è abituato. Per esempio, è possibile dal plugin creare e mappare un nuovo datastore (e assegnargli una della policy definite), mentre il termine Volume è lasciato solo all’interfaccia nativa.

Oltre questo, ad oggi non è disponibile altro. Lo storage non supporta le librerie VAAI ad esempio, e sebbene le attività intensive siano in parte gestite comunque in modo efficiente dall’uso di tecnologie di replica dei dati di tipo redirect-on-write, il supporto a queste librerie sarebbe auspicabile. Vedremo nelle prossime versioni del loro software. Stesso discorso per il supporto a SRM: quando lo storage possiederà funzionalità di replica, sicuramente il plugin per SRM diventerà a questo punto praticamente obbligatorio.

Conclusioni

Lo sviluppo iniziale dello storage NexGen si è concentrato sulla realizzazione di un sistema molto prestazionale, ma che garantisse allo stesso tempo un costo per IO vantaggioso per i propri clienti. A vedere le cifre indicate da NexGen questo risultato sembrerebbe essere stato decisamente raggiunto. Nel futuro, dovremo attenderci ulteriori migliorie alle funzioni oggi disponibili, ma soprattutto una maggiore integrazione con altri sistemi, VMware prima di tutti, ma magari anche Hyper-V o altro. In quanto tempo queste integrazioni saranno disponibili non mi è dato saperlo, ma ritengo che l’acquisizione da parte di Fusion-IO porterà tra le altre cose un aumento del budget disponibile per accelerare questi sviluppi. Vedremo nei prossimi rilasci di software le novità che verranno introdotte.

Tweet

Quello che segue è il racconto di una disavventura che mi ha fatto sudare freddo per diversi giorni ma che fortunatamente si è conclusa per il meglio, e che mi ha fatto riflettere…

Solitamente, spengo il mio MacBook unicamente quando c’è qualche programma o aggiornamento da installare che richiede espressamente il riavvio. La modalità standby non mi ha mai dato problemi, mi permette di usare il computer dopo due secondi dalla sua estrazione dalla borsa, e capita quindi sovente che l’uptime del mio Mac superi abbonantemente il mese. Settimana scorsa, il solito aggiornamento di flash player richiedeva il riavvio, e così a malincuore ho riavviato il mio MacBook, dopo aver controllato come spesso faccio che l’uptime era di 28 giorni e alcune ore.

Dopo pochi minuti dal riavvio, ho chiuso il computer per mandarlo in standby e sono tornato a casa. Rincasato, ho aperto il notebook e con mia sopresa, il sistema era completamente bloccato. Schermo nero, mouse visibile e muovibile, ma nessuna possibilità di accedere al sistema. Nessun sistema è perfetto mi son detto, men che meno Mac OS X, ho provveduto quindi a resettare il computer, e dopo il riavvio ho riaperto i miei soliti programmi e ricominciato ad usarlo.

Improvvisamente, dopo un pò di tempo, è comparsa lei, la diabolica “spinning beachball of death“!!

Per chi non usa sistemi Mac, quando compare lei, solitamente sono dolori. Applicazioni che non rispondono, code disco che non si svuotano, l’equivalente Mac della clessidra di Windows insomma. Dato che spesso il problema è un’applicazione in crash, ho provato ad aprire l’apposito menu per arrestare, ma con mia sopresa, non riuscivo più a lanciare nessuna applicazione e nemmeno a spostarmi tra quelle già aperte, finder e dock compresi.

Altro hard reset, e da qui è iniziato un vero e proprio calvario, durato tre giorni abbondanti. Non sto a raccontarvi tutte le prove che ho fatto, un mix di controlli hardware a ventole e cpu, verifica dei task alla ricerca di applicazioni o daemon fuori controllo, rimozione di vecchie app non più usate da tempo, e via dicendo. Avevo anche temuto una imminente dipartita del mio disco SSD che tante gioie mi aveva dato, ma un controllo con DriveDX mi dava uno stato generale ottimo.

Mentre effettuavo tutti questi test intanto, i blocchi erano sempre più frequenti, costringendomi ogni volta a un riavvio forzato di tutto il sistema. Una voce di questo report mi ha fatto suonare un campanello d’allarme in testa: “buggy/unknown firmware config”. Vuoi vedere che il problema risiedeva nel disco SSD? La cosa mi pareva strana, dato che stavo usando il disco oramai da 19 mesi, ma una rapida ricerca su google per “Crucial M4 firmware bug” mi ha fatto trovare questo articolo, che recitava testuale:

This bug would cause systems that reached a total of 5184 hours on their m4 SSD to become unstable. Once restarted systems would be stable until another hour had passed. The 0309 firmware update released today fixes this problem and allows users to update directly to the latest version regardless if the current firmware revision is 0001, 0002, or 0009.

Il mio firmware era effettivamente lo 009, quindi tra quelli col bug, anche se non mi tornava il conteggio delle ore. Il mio disco aveva un uptime di 5788 ore, di molto superiore alle 5184 indicate dal bug report. Ragionandoci però, poteva effettivamente essere il mio problema: se il valore di uptime veniva aggiornato unicamente al boot, il mio precedente valore di uptime doveva essere ridotto di almeno 28 giorni, tanti quanti il MacBook era rimasto acceso. Il valore da sottrarre era di circa 672 ore, il che portava il precedente valore a 5116…

Scoperto l’arcano: al riavvio il contatore aveva aggiunto in un colpo solo 672 ore, portando il valore al di sopra di 5184. Un paio di test col terminale e il comando “watch uptime” mi hanno poi dato conferma che il sistema si bloccava esattamente dopo 1 ora, come indicato dal bug. Aggiornato il firmware dell’SSD (dopo un doveroso backup!), sono ruscito a passare la soglia dell’ora:

In questi giorni vissuti a periodi di un’ora, mi sono fatto una discreta cultura sui dischi SSD, e di come siano tutto tranne semplici dischi, ma assomiglino molto più a veri e propri computer in miniatura. Il firmware che possiedono è aggiornabile, presenta bug, e al loro interno eseguono attività schedulate come veri e propri daemon, come Wear Leveling, Garbage Collection e altre ancora. Leggendo le note di rilascio dei vari firmware si vede chiaramente come da una versione all’altra migliorino i servizi, le prestazioni, esattamente come in un sistema operativo. Niente a che vedere con i vecchi dischi meccanici, i cui firmware erano poco più che delle interfacce per permettere ai controller di dialogarci.

Tweet

Esattamente il giorno prima di incontrare NexGen Storage, è giunta la notizia della sua acquisizone da parte di Fusion-io. E’ pertanto diventanto impossibile parlare di NexGen senza collegare la loro tecnologia alla visione più generale da parte di Fusion-io; ho deciso pertanto di sviluppare due articoli separati, questo che state leggendo relativo alle strategie di Fusion-IO per il futuro di NexGen, e il secondo che analizzerà in dettaglio lo storage NexGen.

L’acquisizione appena avvenuta ha portato la presenza di ben due CEO all’incontro che io e gli altri delegati del Tech Field Day abbiamo avuto. Non capita tutti i giorni di poter ascoltare direttamente dalla voce delle due figure principali delle due società, le idee e i motivi che hanno portato all’acquisizione stessa. Ho apprezzato molto l’intervento di David Flynn, CEO di Fusion-io, che ha spiegato perchè la società che lui dirige ha deciso di acquistare NexGen (potete vedere il video integrale alla fine di questo articolo).

Perchè un produttore di schede flash PCI, che ha sempre combattuto “contro” gli storage tradizionali, dichiarando la superiorità dei modelli computazionali “share-nothing” e “scale-out” (ogni server possiede storage locale basato su flash, e la replica tra i server è gestita unicamente dal software), adesso si butta in quello stesso mercato?

David Flynn ha dato una spiegazione convincente.

Il primo motivo, ovviamente nemmeno esplicitato tanto era ovvio, è che NexGen già utilizza schede Fusion-IO all’interno dei propri sistemi storage, quindi era sicuramente tra le società papabili ad essere acquisite.

Con NexGen, Fusion-IO può accedere al mercato MidRange, che secondo diverse stime vale circa 16 miliardi di dollari all’anno, ovvero il doppio di quello enterprise. Una cifra che sicuramente ingolosisce e che quindi ha spinto FIO a dotarsi di uno storage con cui entrare in questo segmento. FIO infatti sa pefettamente che la loro soluzione basata su schede PCI integrate direttamente nei server, benchè sia la più efficace per prestazioni ed economie di scala, richiede l’uso di applicazioni specificatamente scritte in modalità “scale-out”. Operazione sicuramente fattibile e percorribile da società di livello enterprise come Facebook o Apple (i loro due maggiori clienti), ma poco praticabile per clienti che basano le loro attività su software scritto da altri e che non presenta caratteristiche di “scale-out” appunto. Anche con soluzioni “ibride” come ioTurbine e Ion, Fusion-io riteneva di dover possedere qualcosa di più vicino al mercato midrange che a quello enterprise.

Le aziende midrange usano lo stesso storage per eseguire workload misti, quindi ha più senso (sempre secondo Fusion-io) possedere uno storage “multi-funzione” se così vogliamo chiamarlo, che sfrutti la potenza delle schede flash conbinata con la grande capienza dei dischi SATA per creare uno storage performante e al tempo stesso economico.

NexGen, a differenza di alcuni affermati produttori di storage ibrido, usa la componente flash per accelerare non solo le letture, ma anche le scritture. In questo modo lo storage può utilizzare la parte flash come un vero tier, e non come semplice cache. Questa potenza elevata diventa un elemento fondante della migrazione su questi storage di varie applicazioni, poprio perchè è possibile consolidare i workload in un unico storage (risparmiando quindi) senza scendere a compromessi in quanto a prestazioni.

Proprio perchè lo storage midrange non è dedicato ad una singola applicazione, ma gestisce contemporaneamente più workload, è necessario poter garantire livelli prestazionali ai singoli workload stessi, in modo che ognuno abbia gli I/O necessari, e senza penalizzare allo stesso tempo gli altri workload ospitati.

NexGen possiede queste funzioni appena descritte, e pertanto sono questi i motivi che hanno spinto Fusion-IO alla sua acquisizione.

Molto interessante infine è stata la descrizione di come Fusion-IO vuole trasformare le piattaforme flash (e anche la soluzione NexGen) da semplici componenti in una piattaforma su cui i vari rifenditori possano costruire le loro soluzioni finali verso i clienti. Secondo Fusion-IO lo stack software creato da NexGen per i propri storage è molto sofisticata, e permette di creare sistemi storage OEM potendo garantire anche a questi sistemi prestazioni ed efficienza come i modelli disegnati direttamente da NexGen.

Questo potrebbe portare nel breve periodo credo (non è una cosa immediata) a nuove versioni di NexGen puramente software, che i vari system integrator potrebbero usare unitamente alle schede Fusion-IO per realizzare e rivendere le loro soluzioni storage. Un’idea sicuramente affascinante e che è già stata percorsa da alcuni vendor come ad esempio Nexenta. Aspettatevi quindi nel prossimo futuro nuovi sistemi storage col logo “Fusion Powered IO”, un pò come “Intel Inside” che conosciamo da anni.

Infine, Fusion-IO punta a trasmettere questo messaggio soprattutto al cliente finale, perchè secondo David Flynn “Fusion-IO non ha molti amici tra gli altri vendor IT, dato che la nostra tecnologia aiuta i clienti a ridurre l’hardware necessario, e quindi riduce i guadagni di questi vendor”.

Una sfida sicuramente interessante, che potrebbe già iniziare a rivelarsi nei prossimi mesi. Fusion-IO si è attrezzata per la sfida sia acquisendo NexGen, sia assumendo alcune persone chiave nelle vendite provenienti da 3Par, LeftHand e EqualLogic.

Vedremo nei mesi a venire se la strategia di Fusion-IO avrà successo.

Tweet

Ho ricentemente incontrato Hitachi Data Systems (HDS) per una breve introduzione della loro soluzione object storage. Storicamente nota per le sue soluzioni storage di fascia media e alta (ad esempio le soluzioni VSP), Hitachi in realtà ha un catalogo di prodotti e applicazioni che spaziano in differenti ambiti.

Argomento dell’incontro infatti è stata una veloce panoramica sulla loro soluzione object storage. L’object storage è sicuramente uno degli argomenti “caldi” del momento, e tutti i grandi vendor come Hitachi e altri si sono attrezzati per poter offrire queste soluzioni, spesso integrate con le loro classiche soluzioni block e file storage.

La soluzione Hitachi Content Platform (HCP, Hitachi adora usare sigle triletterali…) presenta tutte le caratteristiche classiche che ci si aspetterebbe da un object storage, come filespace univoco (il limite attuale è 40 PB per singolo namespace), supporto per vari filesystems esterni che possono essere interrogati e indicizzati (NFS, SMB, HTTP/REST, WebDAV…), policy based access, life-cycle management degli oggetti, e altre funzioni.

Non mi dilungherò in particolari tecnici, se foste interessati il link indicato ad inizio articolo contiene molte informazioni. Piuttosto, ero interessato a capire quali punti di forza ha questa soluzione object storage rispetto ai milioni di concorrenti ad oggi presenti sul mercato. Le funzioni indicate precedentemente infatti sono oramai diventate la “base line” di un sistema object, e più che funzioni di cui vantarsi sarebbe una grave carenza non possederle.

Quali sono quindi gli elementi differenzianti di HCP rispetto ad altri concorrenti?

Innanzitutto, è Hitachi. So che sembra una sparata commerciale, ma esattamente come le soluzioni concorrenti dei principali vendor (EMC, IBM, HP per nominarne alcuni), questo prodotto avrà come target iniziale sicuramente chi è già cliente Hitachi, e può quindi usufruire di una integrazione spinta tra questa soluzione e altri prodotti già posseduti.

Ci sono però altri elementi interessanti.

Nonostante il sito web di Hitachi promuova i vari modelli hardware di questa soluzione, esiste anche una soluzione unicamente software di HCP. In un mondo IT che si sta sempre più spostando sul “Software Defined” qualcosa, potersi svincolare dall’hardware imposto dal vendor e adottare una soluzione software che possa essere messa in esercizio sul proprio hardware già posseduto, è una richiesta comune che arriva dai clienti, specie in forma di virtual machine sui propri hypervisor; esattamente il formato che offre Hitachi.

Inoltre, il licensing della soluzione HCP virtuale è sicuramente intelligente: un semplice licensing per TB gestito, con un minimo di 4 TB indipendentemente dal numero di “nodi” in esecuzione. Scelta molto semplice per poter fare i propri calcoli e, nel caso di Service Provider, un rapido modo per calcolare il prezzo verso il cliente finale. Il licensing invece dei modelli hardware prevede anche un costo per il singolo nodo, e questo invece non mi piace molto, ma si ritrova spesso nelle soluzioni anche hardware…

Molto interessante infine è la soluzione per i branch office (HDI, altro triletterale…): si può disegnare una soluzione distribuita, dove un sistema centrale agisce da deposito per tutti i dati posseduti dalle filiali. Uno storage piccolo viene posizionato in periferia (anche in questo caso può essere fisico o una virtual appliance) e viene replicato verso la sede centrale secondo le politiche che vengono impostate. Questa soluzione permette quindi di mantenere i dati presso la periferia (la promessa della centralizzazione dei dati spesso è appunto una promessa, a causa della connettività non sempre sufficiente in molte aree) ma garantirne al tempo stesso la sicurezza,sia a livello di confidenzialità (è possibile cifrare i dati) sia di protezione (la replica dei dati verso la sede centrale permette di non doversi preoccupare dei backup in periferia).

Infine, il sistema non prevede un vero e proprio sistema di backup, ma piuttosto un versioning interno potenzialmente illimitato, e la possibilità di effettuare repliche esterne, sia verso un altro sistema HCP, sia verso Amazon S3.

In conclusione, Hitachi propone per il mondo object storage una soluzione sicuramente interessante, forse non rivoluzionaria come altre disponibili sul mercato (ma questo solitamente si vede più in una startup che in un grande vendor) ma solida e ben architettata, nonchè dotata di numerose funzioni che permettono di realizzare una soluzione completa, come ad esempio l’accordo con CTera per fornire sistemi NAS in periferia.

Hitachi ha alle spalle una storia e una nomea fatta di soluzioni solide e affidabili per il mondo enteprise, e sicuramente questo prodotto è stato ben congegnato. Se non si hanno richieste “esoteriche” e molto particolari, HCP è una soluzione da tenere in considerazione.

Tweet

Come ogni anno, è tempo di votazioni per le sessioni del prossimo VMWorld 2013. VMware ha pubblicato infatti la lista di tutte le sessioni proposte, cui ognuno di voi può esprimere un gudizio e aiutare a far sì che venga accettata. Le votazioni rimarranno aperte fino al 6 Maggio, e sebbene i voti pubblici presi non saranno l’unico criterio di scelta finale, sicuramente ricevere molti voti potrà aiutare.

Anche se quest’anno ci sono state meno proposte dell’anno scorso, siamo sempre nell’ordine del migliaio, è pertanto difficile scegliere quali sessioni votare, scorrere la lista leggendosi tutte le presentazioni è un’attività onerosa e stancante, e si rischia di premiare chi ha sottomesso per primo la sessione, e che quindi compare in cima alla lista stessa.

Quest’anno ho deciso di proporre anch’io una sessione, e visto che non è tra le primissime, voglio darvi una mano a trovarla:

Ed ecco l’abstract completo della sessione. Se vi interessa, votatela; non dovesse venire approvata, troverò una qualche alternativa come i vBrownbag per pubblicarla.

Tweet

La serie di incontri a cui sto partecipando allo Storage Field Day in Denver è partita col botto, abbiamo avuto la fortuna di avere come primo intervento Exablox, che annunciava proprio in occasione dell’incontro la sua uscita dallo stealth mode e si presentava al mondo.

Exablox

Dovessimo usare una sola frase per descriverli: “Object storage for the masses”.

Dopo due anni di sviluppo prima del lancio, i ragazzi di Exablox hanno lanciato la loro offerta di object storage, disegnata con l’obiettivo dichiarato di offrire una soluzione scalabile, molto resistente, dotata di funzioni di livello enterprise, ma allo stesso tempo facile da gestire. Il sistema si fonda su due elementi principali, la Storage Appliance (OneBlox) e il sistema di management (OneSystem).

I principi ispiratori nella progettazione della soluzione sono stati diversi, ma riassumibili in questi quattro punti principali: – Easy to Manage – Easy to Grow – Enterprise Features – Low Cost

Il disegno della soluzione è completamente di tipo scale-out, e si basa su concetti di share-nothing stile BitTorrent per la distribuzione dei dati tra le varie appliance che formano il cluster.

La prima cosa che mi ha colpito è lo chassis. Mentre la maggiorparte delle nuove società utilizzano server Dell o SuperMicro semplicemente ribrandizzati, ExaBlox ha disegnato il proprio chassis per meglio ottimizzare lo spazio a disposizione e l’uso dei vari componenti. Tra questi, spiccano i processori e un sistema molto comodo per la gestione dei dischi: per abbattere i costi, Exablox utilizza normali dischi da negozio, che per essere installati però non richiedono attività con il caccaivite per usare le slitte a disposizione, ma invece utilizza un sistema a scatto estremamente comodo e veloce. Anche questi piccoli particolari fanno la differenza!

All’interno dello chassis, ha trovato posto un processore particolare: non il solito processore X86, ma un Cavium Octeon II. Si tratta di un processore MIPS 64 bit, che permette di ottenere ottime prestazioni per la gestione della cifratura e della creazione degli hash SHA-1 di tutti i blocchi salvati nel sistema. Ogni dato infatti è salvato in formato cifrato; questo permette di non doversi preoccupare della sicurezza dei dati, e tra le altre cose permette di poter dismettere i dischi senza doversi preoccupare della loro formattazione.

A livello di gestione dello spazio disco, non sono previsti sistemi raid. La configurazione minima di un sistema Exablox è una singola unità con 3 dischi. Questo perchè la ridondanza dei dati avviene replicandoli in almeno tre posizioni differenti. Se sono disponibili almeno 3 unità, la replica viene distribuita su ogni unità; se le posizioni disponibili sono inferiori,si usano i dischi interni di una stessa unità. Una replica di questo tipo ha una penalità elevata sullo spazio disco disponibile: per questo viene utilizzata una deduplica sui dati, di tipo inline e realtime, che permette quindi di recuperare spazio disco, in dipendenza ovviamente del tipo di dato salvato nel sistema.

I vari nodi (fino a un massimo di 6 attualmente) vengono interconnessi tra loro e alla rete tramite 4 connessioni ethernet 1G, sulle quali avvengono sia le repliche tra i nodi sia la loro gestione. Il sistema può essere espanso e ridotto semplicemente aggiungendo o sistituendo dischi e nodi al cluster, per una crescita lineate fino a 192 TB di spazio raw, che diventano 64 TB effettivi, sui quali però va calcolato il beneficio della deduplica.

Inoltre, un “ring” composto da un massimo di 6 nodi, può essere replicato verso un secondo ring remoto, acquistando le opportune licenze per la remote replica. Questo permette di ottenere in modo facile e veloce un disaster recovery dei dati contenuti in un ring Exablox. I dati vengono replicati in forma deduplicata, in modo che l’utilizzo di banda per la replica sia minimo.

A livello di front-end, attualmente Exablox espone il proprio storage ai client di rete unicamente tramite protocollo SMB. Una scelta iniziale sicuramente azzeccata anche se limitata (NFS o altri protocolli non sono contemplati), ma ricordiamoci sempre che parliamo di una versione 1.0 lanciata proprio oggi.

OneSystem

La gestione di un cluster Exablox viene realizzata tramite l’interfaccia di gestione, chiamata OneSystem.

Questa ha una particolarità: non è un software installabile presso il cliente che utilizza il cluster, ma è un sistema web-based offerto come servizio da Exablox stessa. In sè il software è ben fatto, permette di creare condivisioni, profili di autorizzazione alle varie condivisioni, connettere un sistema ad Active Directory, e altre attività.

Uno degli obiettivi di design nella realizzazione di questa piattaforma è stata da subito la multi-tenancy: ogni parte della gestione è delegabile, assegnabile a vari utenti o gruppi, anche appartenenti a differenti società. Questo elemento è perfetto per un MSP che voglia offrire questa soluzione a vari clienti, pur potendoli gestire da un’unica console.

Il dubbio che permane, è la necessità di dover connettere un sistema a internet per la sua gestione, e il fatto che alcune attività (come il provisioning di nuove condivisioni o le modifiche alle autorizzazioni) diventino indisponibili se si perde connessione. O pensate a clienti con “dark sites” dove non è autorizzata alcuna connettività verso l’esterno. Anche in questo caso, probabilmente se ci saranno in futuro sufficienti richieste, verrà prevista questa funzione.

Casi d’uso

Sicuramente, questo prodotto è molto orientato al mercato SMB. La sua facilità d’uso, l’interfaccia semplificata, le funzioni di autoconfigurazione, l’espandibilità intrinseca, così come la possibilità di ridurre i costi usando normali dischi da negozio sono orientate ovviamente a questo mercato. Permangono i dubbi relativi alla gestione unicamente possibile attraverso un servizio Cloud, ma come già dicevo bisogna ricordarsi che è una versione 1.0 lanciata proprio durante questo evento.

Vedo alcuni casi d’uso immediati come ad esempio i sistemi di backup o di archiviazione, dove abbiamo spesso bisogno di un sistema che inizialmente abbia certe dimensioni, e al crescere dei dati debba essere espanso secondo necessità, anche in piccoli incrementi. La possibilità poi di replicare due ring distanti tra di loro permette di avere una seconda replica remota dei nostri backup in modo automatico.

Vedremo nei prossimi mesi come crescerà questa soluzione, e come sarà la risposta del mercato a questa nuova proposta.

Infine, se volete saperne di più sulla tecnologia che hanno sviluppato, Tad Hunt, CTO di Exablox, ci ha offerto durante la sua presentazione un impressionante deep dive. Potete vedere il video qui:

Tweet

Utilizzo Mac da diversi anni, e sempre e solo portatili MacBook Pro. Non ho mai avuto particolari difficoltà a trovare un’alternativa a un software Windows, anche i più strani. E in casi estremi, c’è sempre stata una virtual machine Windows (prima XP, adesso 7) eseguita tramite VMware Fusion.

Per la parte hardware invece, i problemi sono sempre stati più complessi. Pur verificando attentamente prima di ogni acquisto che ho fatto la compatibilità con sistemi Apple (stampanti soprattutto) ci sono stati casi in cui non era disponibile una soluzione. I cavi console per poter accedere a sistemi di rete come switch e router sono sempre stati il mio problema maggiore.

Questi cavi console possiedono solitamente una connessione RJ45 verso l’apparato di rete, e un’uscita seriale verso il proprio computer. Ma da almeno 7 anni, tanti quanti sono utente Mac, non ho mai visto un notebook Apple dotato di porta seriale. Esistono dei convertori Serial-to-USB, ma non sono praticamente mai disponibili i  driver per Mac OS X. O almeno fino alla mia piccola scoperta degli scorsi giorni.

Un mio collega, che a differenza mia lavora prevalentemente come Network Administrator, utilizza Ubuntu Linux sul suo portatile, e possiede questo adattatore:

Come tantissimi prodotti di questo tipo, anche questo è completamente privo di marchi o indicazioni visibili. Il mio collega ricorda di averlo comprato anni fa in un negozio di forniture elettroniche, ma senza ulteriori informazioni riguardanti il prodotto stesso. Viene automaticamente riconosciuto dal kernel Linux come nuova porta seriale, e tanto gli basta. Su Mac OS X purtroppo questa periferica non viene riconosciuta, come si può vedere dall’output di questo comando:

ls -l /dev/cu.* /dev/tty.*
crw-rw-rw- 1 root wheel 33, 3 Mar 17 18:07 /dev/cu.Bluetooth-Modem
crw-rw-rw- 1 root wheel 33, 1 Mar 17 18:07 /dev/cu.Bluetooth-PDA-Sync
crw-rw-rw- 1 root wheel 33, 2 Mar 17 18:07 /dev/tty.Bluetooth-Modem
crw-rw-rw- 1 root wheel 33, 0 Mar 17 18:07 /dev/tty.Bluetooth-PDA-Sync

Le uniche porte seriali presenti sono quelle create dall’antenna Bluetooth, anche se l’adattatore viene correttamente identificato sulla porta USB quando connesso:

system_profiler SPUSBDataType

elenca infatti tutte le periferiche USB presenti, tra cui l’adattatore:

Composite Device:
Product ID: 0x2008
Vendor ID: 0x0557 (ATEN International Co. Ltd.)
Version: 0.01
Speed: Up to 12 Mb/sec
Location ID: 0x06200000 / 3
Current Available (mA): 500
Current Required (mA): 100

Ho trovato tuttavia questo ottimo post su internet, che ho seguito alla lettera. Ultimata la procedura, il risultato del comando precedente è stato questo:

ls -l /dev/cu.* /dev/tty.*
crw-rw-rw- 1 root wheel 18, 3 Apr 10 11:37 /dev/cu.Bluetooth-Modem
crw-rw-rw- 1 root wheel 18, 1 Apr 10 11:37 /dev/cu.Bluetooth-PDA-Sync
crw-rw-rw- 1 root wheel 18, 7 Apr 10 11:55 /dev/cu.PL2303-00002006
crw-rw-rw- 1 root wheel 18, 2 Apr 10 11:37 /dev/tty.Bluetooth-Modem
crw-rw-rw- 1 root wheel 18, 0 Apr 10 11:37 /dev/tty.Bluetooth-PDA-Sync
crw-rw-rw- 1 root wheel 18, 6 Apr 10 11:55 /dev/tty.PL2303-00002006

L’ultima riga è l’adattatore Serial-to-USB. Potete verificare che il driver funzioni semplicemente staccando e riattaccando l’usb, e ad ogni passaggio ripetere il comando ls, vedrete che la periferica scompare e riappare. Una volta identificato il connettore e caricato il suo driver, per utilizzarlo è possibile scaricare ed utilizzare ZTerm, che va configurato in questo modo per utilizzare l’adattatore:

Aprire Settings -> Modem Preferences… e selezionare l’adattatore come default modem. Quindi, andando in Settings -> Connections ci troveremo davanti questa schermata:

Dovrete ovviamente impostare i vari parametri come Data Rate, Data Bits, Parity e Stop Bits, Flow Control in base alla periferica a cui vi vorrete connettere. Premendo su OK, ci troveremo connessi in console all’apparato:

Nel mio caso, un sistema pfSense installato su una Soekris Net4511.

Quindi anche un Network Administrator può usare un moderno e stiloso Mac, invece di quei brutti e vecchi portatili dotati di porta seriale e Windows XP

Tweet

I log dei server ESXi sono una di quelle attività che spesso vengono ignorate o gestite frettolosamente da molti amministratori. Tipicamente ci si preoccupa molto di più delle virtual machine che vengono ospitate, e dato che la stabilità di un server di ultima generazione è alta, così come lo è quella di ESXi, si pensa che non si dovrà mai avere bisogno di accedere ai log.

Questo è a mio avviso un atteggiamento profondamente sbagliato, perchè ci preclude la possibilità in futuro di poter analizzare eventuali eventi o errori che dovessero comparire su un server ESXi. E sono più frequenti di quelli che si è portati a ritenere.

Negli incontri con diversi clienti, ho trovato tipicamente tre atteggiamenti, che si riflettono in tre modalità differenti di gestione dei log di ESXi. Vediamoli insieme.

Mettere la polvere sotto il tappeto

In questo scenario, i log sono solo un ulteriore fastidio da gestire, e quindi prima ci se ne libera meglio è. Su un server ESXi dotato di storage locale, il problema nemmeno si pone dato che per default, ESXi quando trova uno storage locale salva i log in /scratch/log.

Sempre più spesso tuttavia, le installazioni di ESXi vengono effettuare su memorie USB o SD, che non vengono però riconosciute come partizioni valide per il salvataggio dei log. Troviamo infatti tipicamente, appena ultimata l’installazione, un errore simile a questo:

Per risolvere l’errore, il metodo “mettere la polvere sotto il tappeto” prevede la selezione rapida di uno dei datastore condivisi a disposizione, e il suo uso come datastore anche per i log. E’ possibile infatti configurare il parametro avanzato Syslog.global.logDir e impostare il datastore prescelto.

Se si desidera usare lo stesso datastore per tutti i server ESXi, è necessario utilizzare anche il paramentro Syslog.global.logDirUnique, in modo che all’interno della cartella LogDir vengano create differenti sottocartelle per i vari server ESXi.

Questo approccio porta con se due problemi.
Il primo è la scarsa gestibilità di questi log; in caso di necessità di consultazione, è possibile utilizzare dal Web Client il Log Browser e consultare in tempo reale i log dei vari server ESXi:

ma questa attività è decisamente pesante e lenta, dato che ogni volta vCenter provvedere a recuperare tutti i log richiesti direttamente dal server ESXi.
Il secondo problema è evidente: se il server ESXi non è raggiungibile,proprio perchè ha un problema, in che modo posso leggerne i log se questi erano all’interno del server stesso? In questo caso è possibile infatti recuperare unicamente i log salvati nel datastore esterno…

Syslog remoto

Un sistema sicuramente più intelligente e proficuo di gestire i log, è inviarli ad un syslog remoto che provveda al loro salvataggio e sul quale è possibile effettuare delle ricerche. In questo modo, dovessimo avere problemi ad un server ESXi e i suoi log locali non fossero raggiungibili, sarà in ogni caso possibile consultare i log del syslog stesso. Questo è particolarmente vero per i server stateless generati con AutoDeploy.

VMware mette a disposizione un syslog server direttamente nell’installazione di vCenter. E’ sufficiente installarlo (Jason Boche ha scritto un ottimo post a riguardo che vi invito a leggere) e configurare in seguito il parametro avanzato Syslog.global.logHost e impostarci quindi il valore tcp://hostname:514 o udp://hostname:514, in dipendenza del protocollo di comunicazione scelto.

Se possedete numerosi server ESXi, è possibile configurare questo parametro direttamente negli Host Profiles, in modo che ogni nuovo server sia già opportunamente configurato.

Analisi dei dati?

Un semplice syslog server, sia esso quello di VMware o un altro sistema, è sicuramente una buona cosa da utilizzare, per tutti i motivi che ho indicato prima. Ma è sempre sufficiente? Ipotizziamo di avere un problema su un componente software di un server ESXi: forse potrebbe interessarci sapere che avviene in realtà da due mesi, sempre alla stessa ora del giorno? Oppure scoprire che lo stesso allarme è presente su tutti i server ESXi installati sull’hardware X?

Ecco che un sistema di analisi dei dati più avanzato di un syslog server potrebbe fare al caso nostro. Tra i molti software esistenti sul mercato, io uso in particolare Splunk. E’ un potentissimo strumento di raccolta log e dati in generale (diciamo che “ingoia” qualsiasi testo gli inviate, senza problemi di formato, sorgente e dimensioni) ma la sua forza sta soprattutto nel classificare e “taggare” tutti i dati raccolti da ogni log.

E’ possibile quindi effettuare a posteriori ricerche di ogni tipo sui dati raccolti, correlarli tra di loro, e ottenere risultati sia in formato testuale che grafico, con la generazione automatica di grafici.

Se siete interessati a provarlo, sappiate che ne esiste una versione completamente gratuita. Splunk viene licenziato per quantità di log che è in grado di salvare ogni giorno, e la versione gratuita consente un limite giornaliero di 500 Mb. Se vi sembrano tanti, sappiate che mediamente un singolo server ESXi può produrre anche 1 GB di dati, quindi ben oltre il limite della versione gratuita.

Quindi, piuttosto che indicarvi un tutorial per l’installazione di Splunk, che è veramente semplice, vi segnalo per concludere questo thread nei forum di Splunk, in cui un utente spiega come ridurre la quantità di log generati da un server ESXi in modo da farla rientrare nei limiti della versione gratuita.

E voi?

Quale livello di dettaglio utilizzate per i vostri log?

Tweet