Posts Tagged ‘data center’

Nelle reti neurali il futuro dei data center (e degli archivi digitali)?

neural network

neural network di onkel_wart (thomas lieser), su Flickr

L’idea di fondo che permea buona parte dei post pubblicati in questo blog è che in tempi di cloud computing imperante, gli archivi digitali stiano tendenzialmente finendo per coincidere con i data center; questi ultimi, nella teoricamente impalpabile nuvola, rappresenterebbero la parte “materiale” (la ferraglia, per intenderci) del sistema, nella quale i nostri dati e documenti digitali trovano riparo.
Quest’approccio archivistico ai data center, inevitabile alla luce di quelli che sono i miei interessi, mi ha dunque inesorabilmente portato a prendere in considerazione queste infrastrutture strategiche essenzialmente nella loro “staticità” (intendendo con tale termine la capacità di offrire, materialmente, ricovero ai dati e documenti caricati nella nuvola), sottacendo nella maggior parte dei casi l’insieme di compiti computazionali che in misura crescente deleghiamo “al lato server“.
L’annuncio dato da Google con un post nel suo blog circa l’applicazione di tecnologie machine learning in uno dei suoi data center (DC), oltre ad aprire scenari che fino a pochi anni fa avrebbero trovato posto al più nei libri di fantascienza, spariglia le carte e mi impone a riflettere se l’impostazione sin qui adottata rimanga corretta o sia al contrario da rivedere.
Ma, prima di abbandonarci a voli pindarici, partiamo dalla notizia che, va detto, in sé non rappresenta nulla di trascendentale: in sostanza i tecnici dell’azienda di Mountain View, sempre alla ricerca di nuovi metodi per tagliare i consumi energetici dei propri DC, invece di seguire le teorie “classiche” che puntano su aspetti quali la dislocazione geografica (con tentativi talvolta stravaganti, come il fantomatico data center galleggiante approntato nella baia di San Francisco proprio da Big G e che così tanto ha fatto discutere lo scorso autunno), hanno ottenuto importanti risparmi implementando un “neural network” capace di apprendere dal comportamento di quei macchinari presenti nel DC e deputati al raffreddamento dei server (aspetto, come noto, costosissimo ma fondamentale per garantirne la massima operatività ed efficienza), prevedendo l’andamento dei consumi e, passaggio successivo, ottimizzandoli.
Ma cosa intende Google per rete neurale (artificiale)? Come specificato in un white paper diffuso per l’occasione, l’idea di fondo è realizzare “[a] class of machine learning algorithms that mimic cognitive behaviour via interactions between artifical neurons”; tali algoritmi permettono di avviare nelle macchine un processo di “apprendimento” (training) progressivo e cumulativo (nonché potenzialmente infinito) che ha come obiettivo l’accrescimento complessivo della “conoscenza” e l’accuratezza / qualità dei dati raccolti, con il fine dichiarato di individuare “patterns and interactions between features to automatically generate best-fit model”.
Nel concreto che hanno fatto i ricercatori di Google? Hanno applicato una serie di sensori in punti chiave del data center (quali refrigeratori, torri di raffreddamento, scambiatori di calore, pompe, etc.) ed hanno iniziato a cambiare, uno alla volta, i vari parametri tenendo nel frattempo costanti gli altri. Sono in tal modo riusciti a vedere non solo gli effetti, sull’intero sistema, dei cambiamenti apportati ma, grazie agli algoritmi di apprendimento utilizzati, sono stati in grado di far “imparare” il sistema dalle performance passate sviluppando progressivamente capacità predittive tali da migliorare quelle future.
Si capirà dunque come i titoloni circolati nei giorni scorsi (vedi le “superintelligent server farms” di cui ha parlato Techcrunch) siano eccessivi: Google, in definitiva, ha “semplicemente” reso operativo, peraltro in via sperimentale, un primo fascio di reti neurali artificiali applicato a quella che è la parte “meccanica” dei DC.
Il data center supercervellone capace di agire (ed interagire) sulla falsariga del celeberrimo HAL 9000 del film “2001 – Odissea nello spazio” (ovvero un supercomputer dotato di intelligenza artificiale ed in grado, se interrogato, di fornirci risposte), è dunque lungi dal divenire realtà.
Una volta depurata la notizia dai risvolti “fantascientifici” con i quali è stata subito ricoperta, bisogna però pure ammettere come essa, al di là del suo significato “basico” (ovvero la possibilità, anche per quei DC che svolgono funzioni di “archivio”, di adottare algoritmi di machine learning grazie ai quali ottenere considerevoli risparmi), riveste effettivamente una notevole importanza archivistica.
E’ stato infatti compiuto, con il progetto pilota di Google, un importante salto qualitativo: è infatti solo questione di tempo prima che i sensori vengano applicati, oltre che alla parte meccanica, ai server medesimi. Quando ciò avverrà il neural network instaurerà nessi e collegamenti (assimilabili in qualche modo al vincolo archivistico impuro?) tra i vari dati e documenti conservati sprigionandone l’intero potenziale informativo (tema connesso a quello dei big data ed al warehouse computing del quale ho parlato giusto nel mio ultimo post) e decretando così l’importanza strategica degli archivi.
Inoltre, aspetto non secondario, d’ora in poi l’idea statica di “data center come archivio”, ovvero come luogo fisico nel quale risiedono concretamente i dati ed i documenti digitali, è destinata a lasciar posto a quella, dinamica, di data center come luogo nel quale si instaurano collegamenti e percorsi nuovi e non prevedibili da parte… di un’intelligenza artificiale; l’attenzione si sposterà, in altri termini, dal contenitore (il DC) al suo contenuto.
Con tutto ciò che ne consegue.

Google ed il data center galleggiante

Il data  center galleggiante di Google

Il data center galleggiante di Google

Di data center (DC), in questi anni, mi sono occupato per i più svariati motivi e sotto molteplici prospettive: vuoi perché essi sono infrastruttura necessaria (ma purtroppo non sufficiente!) per mantenere in vita le speranze di archivi e biblioteche di giocare un ruolo nella società digitale, vuoi perché la loro corretta gestione (leggasi: dei dati in essi custoditi) impatta direttamente sulla privacy di tutti noi, vuoi ancora per i risvolti più strettamente tecnologici inerenti alle modalità con i quali li si costruisce (e a dove li si colloca) e, a cascata, alle possibilità di assicurare la loro continuità operativa nonché, nella peggiore delle ipotesi, la sopravvivenza dei contenuti digitali in essi custoditi.
La notizia che vado qui a commentare riassume in sé un po’ tutti questi aspetti: Google starebbe costruendo (il condizionale è d’obbligo non essendoci infatti conferme ufficiali da parte di Mountain View ma tutti gli indizi lasciano presupporre che sia effettivamente così), su un molo affacciantesi sulla baia di San Francisco, un avveniristico data center galleggiante.
Naturalmente la maggior parte dei commentatori ha spiegato la costruzione come esito della naturale ricerca, da parte dei colossi dell’high tech, di data center meno energivori: in tal senso la scelta dell’ambiente acquatico sarebbe l’ideale (a parte la presenza di sale), in quanto l’acqua potrebbe venir impiegata, oltre che per il raffreddamento delle macchine, anche per generare l’energia elettrica (in tutto od in parte non è dato sapere) necessaria al suo funzionamento. Inoltre questo data center galleggiante, potendo muoversi (nell’articolo sopra linkato si assicura che quella sorta di chiatta destinata ad ospitare i container modulari – che a loro volta andrebbero a comporre il DC in una sorta di Lego – ha capacità nautiche tali da poter andare praticamente ovunque), assicurerebbe l’ulteriore vantaggio di spostarsi in base alle esigenze, mettendolo al riparo da tutte quelle minacce atmosferico-ambientali che, per quanto ci si sforzi di realizzarli in luoghi sicuri, tipicamente affliggono i data center fissi.
Un ulteriore “vantaggio competitivo” potrebbe essere rappresentato dalla possibilità di servire aree geograficamente prive di tali infrastrutture vitali (si pensi al continente africano ed a molte regioni asiatiche): in questo senso il data center galleggiante ben si inserirebbe all’interno di altri progetti (non disinteressati, si badi) portati avanti da Google e tesi a ridurre il digital divide, come quello che prevede la realizzazione di dirigibili i quali, sorvolando le aree più remote di Africa ed Asia, letteralmente le irradierebbero dall’alto con il “vitale” segnale Wi-Fi, donando loro la connessione. Brin e Page, in altri termini, si presenterebbero come moderni “liberatori” e civilizzatori di queste nazioni arretrate…
Non meno importanti le considerazioni relative alla privacy: in tempi di datagate la presenza di un data center mobile, sottraibile dunque dalle grinfie dell’NSA, è politicamente decisamente vantaggioso ed al contrario un’ottimo modo per rifarsi un’immagine davanti ai propri utenti, ai quali si dimostrerebbe che l’azienda californiana resta fedele, nonostante tutto, al suo vecchio motto “Don’t be evil”. In verità anche sotto questo aspetto non c’è da stare molto sereni, essendo Google una maestra in fatto di data mining, tanto più che tra le due sponde dell’Atlantico la concezione della privacy si va divaricando in misura crescente ed i colossi d’oltre oceano sembrano sempre più in grado di imporre la loro legge.
In altri termini la presenza di data center che sfuggono a qualsiasi forma di controllo rappresentano un motivo di preoccupazione tanto quanto quelli, posti sul suolo degli States, che stando alle ultime indiscrezioni di giornale paiono sempre più essere stati dei veri e propri “libri aperti” per le varie agenzie federali. Forse sarebbe il caso di cercare soluzioni alternative all’apparentemente inarrestabile processo di concentrazione in pochi ed enormi DC e, parallelamente, di realizzare dorsali Internet meno americanocentriche.
Ma mi fermo qui, che sono già andato sin troppo off-topic

Gli archivi sulla nuvola alla prova dell’uragano Sandy

A quanto pare è destino che gli uragani fungano da banco di prova per gli archivi digitali: nel 1995 l’uragano Marilyn colpì violentemente le Isole Vergini provocando vittime e danni ad edifici tanto pubblici quanto privati: sulla scorta di quell’evento il National Media Lab redasse delle linee guida (una sintesi in italiano la trovate all’interno del volume “Memorie digitali: rischi ed emergenze”, pubblicato dall’ICCU nel 2005) su come minimizzare i danni in simili casi.
Alcuni dei consigli forniti allora mantengono appieno la loro validità (in particolare quelli su dove collocare fisicamente i sistemi di archiviazione ed i sistemi ed i supporti informatici contenenti dati, ovvero in piani che non siano il primo e l’ultimo ed in locali non affacciantesi sull’esterno) ma molti altri appaiono anacronistici ed evidenziano quanta strada abbia fatto la tecnologia in questi tre lustri e, di riflesso, quanto la nostra vita dipenda in modo sempre più stringente da quest’ultima.
Un esempio su tutti: 15 anni fa il NML suggeriva di scollegare dalla rete elettrica tutte le apparecchiature elettroniche e di impacchettarle in apposite buste di plastica mentre oggi la lotta con l’uragano Sandy si è giocata tutta, al contrario, proprio sul riuscire ad evitare di finire offline! Del resto all’epoca l’ipotesi di “vivere senza Internet” ed i vari dispositivi tecnologici ad essa collegati per alcuni giorni non sollevava particolari problemi, a differenza di oggi dove la cosa sarebbe vissuta come una tragedia!
Non è dunque un caso se siti e blog nordamericani hanno fatto a gara a raccontare, praticamente minuto per minuto, quali e quanti data center (con relativi servizi) “andavano giù”; molti commentatori infatti hanno sottolineato come fosse, quella presente, una prova del nove della sostenibilità del modello del cloud computing (con annesso servizio di archiviazione) il quale ha come imprescindibile corollario l’essere always on.
Come spesso accade non c’è unanimità sul fatto che la prova sia stata superata o meno: come mostra l’analisi di Renesys (sintetizzata nel video qui sopra) in termini percentuali appena il 10% dei network dell’area di New York sono rimasti colpiti anche se, aggiunge poco sotto la stessa società, considerando la densità di reti è come se l’intera Austria si fosse bloccata, il che non è esattamente una cosa da niente!
Vittime di Sandy, del resto, sono stati anche servizi di primo piano come Gawker (che annovera tra i suoi siti pure il tecnologicissimo Gizmodo!) ed il celeberrimo Huffington Post, tutti “ospitati” nei server della newyorkese Datagram Inc. che, nel momento in cui scrivo, ha da poco terminato di svuotare i propri locali dall’acqua ed opera dunque ancora in regime di piena emergenza.
L’acqua infatti, oggi come per gli archivi cartacei dei secoli passati, si è rivelata ancora una volta essere la minaccia principale: evidentemente molti data center erano fisicamente collocati in locali non idonei (vuoi vedere che macchinari dal valore complessivo di centinaia di migliaia di dollari sono finiti negli scantinati?!) o comunque senza tener conto di possibili criticità idrauliche (l’agglomerato urbano di New York in definitiva sorge su più isole ed è attraversato da grossi fiumi come l’Hudson e l’East River).
Sono stati proprio gli allagamenti diffusi, una volta che la Conedison (la società energetica che serve New York; n.d.r.) ha interrotto l’erogazione di corrente, ad impedire ad un gran numero di generatori ausiliari di entrare in azione! Ma va tenuto presente che anche nei casi in cui i generatori sono correttamente entrati in funzione si è palesata la limitatezza dell’autonomia vuoi perché le scorte non erano sufficienti (le 48 – 72 ore di norma previste sono risultate troppo poche per un’emergenza di questa portata) vuoi perché gli stessi serbatoi erano finiti in ammollo. Questo ha costretto molti tecnici ad un’affannosa ricerca per la città di pompe di benzina per sopperire alla carenza del prezioso carburante! Su “The Verge” Adrianne Jeffries ha spiegato con dovizia di particolari un’emergenza tipo, con i tecnici sistemisti che, una volta riempite le taniche, hanno dovuto travasare a mano il loro contenuto nei serbatoi dei generatori operando in ambienti invasi da un misto di acqua, carburante e rifiuti.
Un’altra criticità chiaramente emersa, e che deve far profondamente riflettere, riguarda poi la collocazione geografica dei centri secondari di back-up e ripristino: è evidente che se i succitati servizi sono andati giù ciò è dipeso dal fatto che non solo i siti primari ma anche quelli secondari hanno fatto cilecca. Difatti è emerso che molti di questi siti secondari si trovano nel vicino New Jersey (vicino in senso relativo; è più o meno come se un’azienda di Milano avesse il suo sito secondario nei pressi di Bologna…), investito anch’esso dalla furia di Sandy.
Ovviamente non tutto è filato storto, anzi, prendendo per buona e rigirando la statistica citata all’inizio si può a buon diritto affermare che nel 90% dei casi le procedure ed i sistemi d’emergenza hanno funzionato a dovere (qui alcuni esempi). Pertanto mi sembra si possa tranquillamente affermare che complessivamente il “modello cloud computing” abbia retto all’urto e che anzi esso, se sarà capace di metabolizzare le lessons learned ovvero:
1) porre serbatoi, generatori e sale macchine in zone al riparo dagli allagamenti,
2) costruire i centri secondari di ripristino a debita distanza dal primario, sacrificando magari qualche frazione di secondo in fatto di tempi di latenza,
potrà, almeno dal punto di vista tecnologico, divenire davvero un modello altamente affidabile tale da assicurare un elevato grado di sopravvivenza ai nostri archivi digitali sulla nuvola.
Certo, resta il problema di fondo della dipendenza assoluta dall’energia elettrica, ma questo è un limite generale della nostra società e personalmente non vedo soluzioni soddisfacenti all’orizzonte (la diversificazione, magari puntando sulle rinnovabili, al momento non è che un palliativo) e pertanto lo lascerei fuori dal dibattito fin qui fatto.
Va infine sottolineata l’eccezionalità, relativamente alle aree geografiche interessate, del fenomeno meteorologico in oggetto ed anzi c’è da domandarsi (ma qui mi rendo perfettamente conto che entriamo nel campo della pura speculazione): quanti archivi, digitali ed analogici, sarebbero sopravvissuti se un’emergenza simile si fosse verificata in Italia?

La natura infrastrutturale degli archivi contemporanei

IMG_20110415_151845 di GrigorPDX, su Flickr

Left: air filters - they look like plain old disposable filters you'd have in your furnace. Right top: louvers leading to outside air Right bottom: louvers leading to the "hot" side of the data center racks.
(Foto di GrigorPDX, su Flickr)


INTRODUZIONE.

In un celebre quanto datato articolo Robert-Henry Bautier, insigne archivista e medievista francese, proponeva una interessante periodizzazione circa la storia degli archivi; in particolare egli individuava quattro fasi, la terza delle quali veniva definita come “celle des archives arsenal de l’authorithé” e che sarebbe stata caratterizzata dalla concentrazione dei fondi all’interno di edifici realizzati ad hoc che erano in tutto e per tutto castelli, vale a dire muniti di fossati, mura e torrioni difensivi in pietra (da manuale i casi del castello di Simancas in Spagna oppure quello di Castel Sant’Angelo nello Stato Pontificio). Dietro a simili realizzazioni stava una concezione che attribuiva ai documenti un’importanza decisiva per il regolare andamento della macchina amministrativa, l’attestazione dei diritti e delle prerogative regie così come per l’attuazione della politica estera (per riprendere Bautier gli archivisti, e gli archivi, “se font auxiliaires de la politique e de la diplomatie“) motivo per cui la dimensione del corretto ordinamento delle carte procedeva di pari passo con quella della loro “sicura custodia”. Insomma, il ricorso a questa terminologia “militaresca” da parte di Bautier non era dettato da semplici motivazioni retoriche ma dalla constatazione di una realtà oggettiva: così come l’arsenale è una struttura deputata alla costruzione, alla riparazione, all’immagazzinamento ed alla fornitura di armi e munizioni, similmente l’archivio era il luogo in cui trovavano riparo quei documenti che sarebbero stati usati alla stregua di armi nel corso delle bella diplomatica del XVII secolo.

I DATA CENTER, ARSENALI DEL XXI SECOLO.

Con le debite differenze, sulle quali torno poco sotto, mi sembra che gli odierni “arsenali archivistici” siano rappresentati dagli enormi data center che si vanno costruendo in giro per il mondo; il paragone appare calzante in quanto 1) in essi si vanno concentrando le “memorie digitali” relative a milioni e milioni di persone, enti ed aziende 2) nella loro realizzazione vengono adottate precauzioni ed accorgimenti del tutto affini a quelle delle basi militari. Basta dare una scorsa alle misure di sicurezza messe in campo da Amazon per capire come l’accostamento con la realtà militare sia tutt’altro che campato per aria:

Amazon has many years of experience in designing, constructing, and operating large-scale data centers. This experience has been applied to the AWS platform and infrastructure. AWS data centers are housed in nondescript facilities, and critical facilities have extensive setback and military grade perimeter control berms as well as other natural boundary protection. Physical access is strictly controlled both at the perimeter and at building ingress points by professional security staff utilizing video surveillance, state of the art intrusion detection systems, and other electronic means. Authorized staff must pass two-factor authentication no fewer than three times to access data center floors. All visitors and contractors are required to present identification and are signed in and continually escorted by authorized staff.

Amazon only provides data center access and information to employees who have a legitimate business need for such privileges. When an employee no longer has a business need for these privileges, his or her access is immediately revoked, even if they continue to be an employee of Amazon or Amazon Web Services. All physical and electronic access to data centers by Amazon employees is logged and audited routinely.

Fin qui le affinità; venendo alle differenze, ve ne sono due di macroscopiche: 1) gli archivi residenti nei data center, per quanto militarizzati, almeno in linea di principio non sono concepiti per essere al servizio di un qualche potere vessatorio ma bensì sono la base per offrire “servizi” e/o custodire dati, documenti, etc. di cittadini liberi, di aziende operanti nel libero mercato e di istituzioni democratiche 2) diversamente dai secoli passati, lo Stato sembra latitare ed i principali data center sono di proprietà di colossi ben noti al grande pubblico come Amazon, Apple, Google, Facebook ma anche di provider / fornitori come Carpathia, Cogent, OVH, Rackspace, Digital Realty; operatori che ovviamente poi sono ben lieti di offrire i propri “servizi” ai vari enti pubblici! Ad esempio sia Amazon che Carpathia hanno sviluppato apposite soluzioni per il Governo Federale degli Stati Uniti, il quale attinge largamente in modalità cloud computing a questo tipo di servizi (cliccate qui per una lista parziale); in Europa invece, essendo la legislazione comunitaria relativa al trasferimento transfrontaliero dei dati decisamente più restrittiva, si è molto più cauti nell’affidarsi a privati.
Ciò nonostante, ragionando in prospettiva, è verosimile ipotizzare che nell’Unione Europea o si allenteranno le citate restrizioni al trasferimento dei dati (a riguardo si sta delineando una spaccatura tra stati nordici, non disponibili ad un simile passo, e stati mediterranei, più possibilisti), dando dunque la possibilità di avvalersi dei servizi offerti da privati, oppure si procederà alla realizzazione di data center europei in territorio europeo. Personalmente ritengo la seconda opzione come la più lungimirante per i seguenti motivi: 1) il possedere dei data center è, dal punto di vista archivistico, premessa necessaria (ma non sufficiente) per attuare le indispensabili procedure tese a garantire la continuità operativa ed il disaster recovery (il che consente in primis di salvaguardare la parte “corrente”, vale a dire quei dati e documenti contenuti nei server ed indispensabili per il proseguimento dell’attività “istituzionale” del produttore, ed in ultima analisi di garantire la conservazione nel lungo periodo; ovviamente anche un privato può attuare questi piani ma quando si tratta della cosa pubblica e, soprattutto, sono in ballo aspetti così delicati, sono dell’avviso che la P.A. debba occuparsene direttamente) 2) assicura indipendenza ed in un ultima analisi “libertà”. Il rovescio della medaglia, evidente, è che ci si deve fare carico di tutti i costi: realizzativi, di gestione e di manutenzione.

DATA CENTER: MODELLI REALIZZATIVI, ASPETTI TECNICI…

La maggior parte dei moderni data center non è costituita da pochi supercomputer o pochissimi mainframe, bensì dall’unione all’interno di un medesimo spazio fisico di migliaia di elaboratori di fascia medio – bassa. E’ questo, tra i tanti, l’approccio di Google che significativamente lo definisce wharehouse computing e così lo descrive:

The hardware for such a platform consists of thousands of individual computing nodes with their corresponding networking and storage subsystems, power distribution and conditioning equipment and extensive cooling systems. The enclosure for these systems is in fact a building structure and often indistinguishable from a large warehouse

Tale definizione individua quelli che sono gli elementi principali di un data center ovvero “n” elaboratori, custoditi in una sorta di armadietto definito in gergo rack, a loro volta siti all’interno di un edificio e collegati tra di loro. Da ciò deriva che in un DC ricoprono un ruolo cruciale i seguenti sistemi:
1) UPS (Uninterruptible Power Supply; Gruppo di Continuità), il quale assolve a tre compiti fondamentali, ovvero a) garantire l’erogazione continua di energia elettrica alla struttura e, qualora dovesse verificarsi un’interruzione nella fornitura da parte della public utility, b) far intervenire la batteria fintantoché non interviene il generatore di emergenza, il tutto c) senza che si verifichino dannosi sbalzi di tensione
2) PDU (Power Distribution Units), ovvero il sistema di distribuzione dell’energia elettrica, distribuzione che avviene attraverso quadri e/o interruttori elettrici in genere “annegati” nel pavimento del data center
3) sistema di condizionamento; il metodo più diffuso vede la presenza di CRAC (Computer Room Air Conditioning), vale a dire di “stanze” dalle quali spira aria fredda che, scorrendo sotto il pavimento (tra il pavimento vero e proprio e quello che effettivamente si calpesta e sul quale sono collocati rack, CRAC, etc. può esserci sino ad un metro e mezzo di spazio vuoto; n.d.r.), esce attraverso delle specie di grate giusto in corrispondenza dei rack da raffreddare; l’aria calda uscita dai rack fluisce verso l’alto all’interno di un ulteriore spazio vuoto posto nel soffitto e di qui indirizzata verso il CRAC per riprendere il circolo. Nei DC più evoluti la gestione dei flussi d’aria è così raffinata che ad ogni singolo server perviene la necessaria aria di raffreddamento alla temperatura ottimale (una via alternativa è il cosiddetto in-rack cooling nel quale ogni “armadietto” è praticamente “cablato” da serpentine che fungono da scambiatori di calore; questa soluzione ovviamente ottimizza il raffreddamento ma è assai costosa dal momento che l’impianto di raffreddamento viene ad estendersi su tutta la superficie del centro dati oltre che relativamente più pericolosa giacché, in caso di rottura delle serpentine, il liquido di raffreddamento potrebbe finire sulla parte elettrica… evenienza assolutamente da scongiurare!).

Cabinet Airflow

Cabinet Airflow di talk2stu, su Flickr

Va ricordato, per finire, che per aumentare il livello di sicurezza spesso e volentieri i citati elementi sono ridondanti; così se in un data center Tier I vi è un’unico canale di raffreddamento e di distribuzione dell’energia in un Tier IV (il più elevato della scala) ve ne sono due di attivi oltre che ulteriori percorsi di emergenza. Non va ovviamente neppure dimenticato che fondamentale risulta essere la localizzazione geografica del data center: non dovrebbe trovarsi, ad esempio, in zone sismiche, in prossimità di corsi d’acqua ed in generale in aree soggette ad allagamenti o frane (“a rischio idro-geologico”) così come andrebbero evitate zone troppo fredde od al contrario troppo calde! Inoltre, sarebbe auspicabile che nella realizzazione dei DC europei si metabolizzasse l’approccio “green” di Gartner e, pertanto, si facesse ricorso a fonti di energia rinnovabile.

… E L’OBIETTIVO INDEROGABILE DELLA CONTINUITA’ OPERATIVA.

Castelli e fortezze, spesso progettati dai migliori architetti militari, erano in grado di resistere a lunghissimi attacchi ed assedi senza che si verificasse un sensibile degradamento della loro capacità bellica; similmente tutte le soluzioni tecnologiche descritte nella precedente sezione sono finalizzate a garantire la continuità operativa (business continuity), ossia il normale funzionamento dei servizi ICT utilizzati per lo svolgimento delle attività istituzionali, anche in presenza di disguidi tecnici, di “attacchi” o di altri eventi imprevisti. A fronte di avvenimenti che provocano l’indisponibilità prolungata del data center in cui normalmente si opera / al quale ci si appoggia (sito primario), viene attivato il piano di disaster recovery, il quale prevede l’attuazione di un mix di soluzioni tecnologiche ed organizzative tese a garantire la pronta ripresa dell’attività istituzionale in siti alternativi (detti secondari) rispetto a quelli primari/di produzione per il tempo necessario a rendere nuovamente operativo il sito primario.
Si tratta, manco a dirlo, di argomenti da tempo dibattuti in ambito internazionale ma che in Italia, dal punto di vista legislativo, solo di recente hanno finalmente trovato piena recezione; ad esempio le “Linee guida per il Disaster Recovery delle Pubbliche Amministrazioni”, redatte ai sensi dell’art. 50-bis, co. 3 del CAD (D. Lgs. 82/2005), hanno visto la luce solo nell’autunno 2011 ed imponevano che ogni ente presentasse entro il 25 aprile 2012 un Piano di Continuità Operativa (PCO) ed uno di Disaster recovery (PDR), individuando contestualmente una figura responsabile (RCO). Al di là del fatto che le varie amministrazioni abbiano ottemperato o meno nei tempi prescritti ai suddetti obblighi di legge, mi preme qui rilevare come l’input sia stato essenzialmente “archivistico”: nelle citate Linee Guida si trova infatti testualmente scritto che “il processo di dematerializzazione promosso dal CAD […] ha trasformato da ordinatoria a perentoria l’azione di eliminazione della carta, comporta[ndo] un incremento della criticità dei sistemi informatici che non possono più contare su un backup basato sulla documentazione cartacea”.
Da quanto innanzi detto derivano a cascata alcuni cambiamenti di una certa portata:
1) la continuità operativa ed in subordine il disaster recovery sono possibili a patto di individuare preliminarmente, accanto al sito primario, un sito secondario al quale trasferire come operazione di routine i dati / documenti prodotti dal primario; in caso di “problemi” il sito secondario diviene temporaneamente operativo fintantoché il primario non ritorna disponibile e pertanto deve disporre delle necessarie risorse hardware e software =>
2) nelle procedure di BC / DR diventa un fattore cruciale il trasferimento tra i due siti; le Linee Guida prevedono sei livelli (Tier 1 – 6) nei primi due dei quali il trasferimento consiste nel trasporto fisico (ad esempio a mezzo di apposito furgone) dal sito primario a quello secondario dei dischi ottici contenenti la copia di backup. E’ inutile sottolineare, però, come nell’epoca di Internet, grazie anche all’innalzamento delle velocità di upload / download ed ai migliori tempi di latenza, la Rete sia la soluzione più in voga e come il paradigma del cloud computing sia la soluzione sulla quale oggi si punta di più
3) dando per assodato che il trasferimento dei dati avvenga attraverso la Rete, va osservato che le operazioni di copia (Data Mirroring) finiscono per riguardare anche gli applicativi; le Linee Guida infatti lo definiscono “un processo con cui dati ritenuti critici vengono copiati secondo precise regole e politiche di backup al fine di garantire l’integrità, la custodia e la fruibilità degli archivi, dei dati e delle applicazioni e la possibilità di renderli utilizzabili, ove fosse necessario, procedendo al ripristino degli archivi, dei dati e delle applicazioni presso un sito alternativo a quello primario”. In particolare uno degli obiettivi principali è ottenere l’allineamento dei dati (ovvero il “coordinamento dei dati presenti in più archivi finalizzato alla verifica della corrispondenza delle informazioni in essi contenute”; per inciso l’allineamento, a seconda del Tier prescelto, può essere asincrono o sincrono) ed eventualmente il retroallineamento (ovvero “caricare” i dati prodotti nel sito secondario durante una fase di emergenza in quello primario in vista della ripresa dell’operatività di quest’ultimo) =>
4) dal punto di vista archivistico l’attuazione del Piano di Continuità Operativa significa il trasferimento costante di dati / documenti dal sito primario a quello secondario con questi ultimi che, nel caso di Tier 6, sono de facto speculari, motivo per cui (fatto salvo il caso di mancato allineamento), mi sembra si possa parlare della presenza di originali in duplice copia (per quanto poco senso possa avere la distinzione originale – copia in ambiente digitale). Inoltre è interessante osservare come, proprio perché parte integrante delle policy messe in atto, l’instabilità e l’ubiquità di dati e documenti sia, soprattutto nella fase corrente, più la regola che l’eccezione.
5) il legislatore ha chiaro come le operazioni di backup da un sito all’altro non equivalgono alla conservazione di lungo periodo per finalità storico – documentali; a proposito nelle Linee Guida ci si limita a ricordare come occorra raccordarsi al Manuale di conservazione e come il “salvataggio” debba avvenire su supporti adeguati. Sulla scorta di tali suggerimenti mi vien da ipotizzare due possibili soluzioni: a) all’interno della medesima coppia di data center vanno predisposti dei rack attrezzati con storage server di elevata qualità (diversamente dai rimanenti che, abbiamo visto, possono essere di livello medio – basso) nei quali destinare quei dati e documenti per i quali è prevista la conservazione permanente (la cosa è fattibile in quanto la “destinazione finale” è nota sin dal momento della creazione) b) che accanto alla coppia di data center deputati alla fase operativa / corrente ne venga costruita una ad hoc per quella di conservazione.
A prescindere da quale delle due opzioni prediligere (motivazioni di contenimento dei costi / ottenimento di economie di scala mi fanno propendere per la prima soluzione), va rimarcato come venga confermato che la migliore strategia conservativa sia quella di assicurare (potendolo provare attraverso audit, file di log, etc.), che la vita dei dati / documenti è sempre avvenuta all’interno di un sistema sicuro ed inviolato (e qui ritorniamo alle specifiche costruttive che devono possedere i data center) e che le procedure di copia sono avvenute senza errori.
6) Superfluo, da ultimo, sottolineare come gli aspetti tecnici non debbano mettere in secondo piano quelli organizzativi (come sempre deve venir coinvolta l’intera organizzazione!); mi preme solamente evidenziare come vada assolutamente individuata una catena di comando strutturata gerarchicamente secondo un modello che guarda caso rimanda nuovamente all’ambiente militare.

CONCLUSIONI.

Considerando la formazione prettamente umanistica della maggior parte degli archivisti (sottoscritto naturalmente incluso), comprendo come gli argomenti trattati in questo post appaiano oggettivamente ostici; eppure con tali tematiche occorre confrontarsi in quanto, è la mia convinzione, l’archivio del prossimo futuro coinciderà de facto con i moderni data center. Si tratta di un cambiamento di prospettiva di notevole portata per almeno i seguenti motivi: a) in primo luogo perché si torna a parlare di archivio nel suo complesso e non per questa o quella delle ripartizioni logiche – corrente, deposito, storico – nelle quali la teoria e la legislazione tradizionalmente l’hanno suddiviso b) in secondo luogo perché l’archivio diviene infrastruttura strategica e centrale per il “regolare svolgimento” della vita (digitale) di cittadini, aziende ed enti pubblici c) ultimo perché, della costruzione di tali data center / archivi “arsenali”, devono tornare a farsene carico gli Stati, meglio ancora se in chiave europea, l’unica che può garantire il necessario apporto finanziario nonché quell’ampiezza di spazi geografici tali da rendere la localizzazione dei DC veramente adeguata al raggiungimento dei dichiarati obiettivi di business continuity e di disaster recovery.

A chi volesse approfondire questo importante argomento consiglio di leggere la versione su Storify di questo post, ricca di documenti utili.

Nuovo CAD e massimi sistemi

Seminario sul nuovo CAD

Seminario sul nuovo CAD

Tornato da un convegno / seminario sul nuovo CAD, nel corso del quale Gianni Penzo Doria ha come sempre saputo tenere attento e partecipe il numeroso pubblico, mi sono messo come spesso mi capita a fare considerazione sui massimi sistemi.

Infatti sarà stata la semplicemente fantastica “equazione del disordine”:

D*I = C2 (ovvero: Disorganizzazione * Informatica = Casino al quadrato)

la quale può a buon diritto essere riportata nei libri di fisica a fianco della legge dell’entropia oppure sarà stato il senso di smarrimento mistico in cui getta l’operato di un legislatore tanto iperattivo quanto confuso e pasticcione o ancora sarà stata la mia naturale repulsione per tutto ciò che sa anche solo lontanamente di legislativo… insomma sarà stato per tutto un insieme di fattori ma ho ritenuto che non ci fosse nulla di più tranquillizzante che rifugiarsi nei lenti (ma non per questo meno dirompenti) cambiamenti che agendo sottotraccia modificano la vita di tutti noi in modo impercettibile.
In particolare sono partito per la tangente con le mie speculazioni altamente filosofiche nel momento in cui si è parlato di firma elettronica / digitale; difatti, al di là del proliferare di specie e sottospecie, mi ha fatto riflettere il fatto che mentre il documento è attualmente conservabile per un discreto numero di anni, ciò non vale per l’eventuale firma ad esso apposta, essendo quest’ultima, per semplificare, “a scadenza”. Questo problema non da poco è aggirabile se l’utente si accredita ed interagisce (si vedano gli artt. 65 e 47 rispettivamente dei decreti legislativi 82/2005 e 235/2010) all’interno di un sito di una Pubblica Amministrazione: in tal caso infatti tutte le istanze e dichiarazioni vanno considerate per l’appunto come validamente sottoscritte.
In sostanza anche in questo caso, così come in quello parimenti complesso della conservazione digitale, una soluzione efficace pare essere il ricorso ad un “sistema”, visto alla stregua di luogo sicuro nel quale i documenti e gli atti si formano in base alle volontà degli attori chiamati in causa, vengono da essi “usati” ed infine conservati.
Rapito da questo turbinio di pensieri ho ampliato ancor più i miei orizzonti e mi sono soffermato sul fatto che la residenza di questi “sistemi” sarà in un tempo molto prossimo l’eterea “nuvola”, con tutto ciò che ne consegue. Infatti dopo tre decenni di atomizzazione della potenza di calcolo, degli applicativi e delle unità di memoria presso ciascun singolo individuo, il futuro del computing sembra andare inesorabilmente nella direzione dei grossi data center di proprietà anche degli Stati nazionali ma soprattutto dei colossi dell’informatica; data center cui delegheremo parte della capacità di calcolo e sui quali faremo girare i nostri programmi e “archivieremo” i nostri dati e documenti.
Una spinta centripeta che cozza con quella centrifuga alla quale ci eravamo oramai abituati; sarà la rivincita degli eredi dei grandi computer mainstream ed il tramonto dell’era del personal computer e con esso di tutte le promesse di liberazione dell’individuo.