Il comportamento dei sistemi informatici: behaviour analysis, machine learning e caffè.

Piccolo focus sul tema dell’analisi del comportamento dei sistemi.

A cosa ci serve l’ho accennato nel precedente post, in questa occasione scendiamo un po’ nel tecnico per capire come si analizza un comportamento e quali paradigmi/algoritmi possiamo utilizzare.

Ovviamente tutto parte dai dati che possiamo collezionare da un sistema informatico: spesso ho parlato di logs, ovvero i registri degli eventi che le applicazioni compilano durante la loro operatività, ma si tratta di una delle molte fonti di dati. Possiamo infatti prendere in considerazione le metriche prestazionali (carico CPU, utilizzo RAM, impegno di banda, ecc) o il traffico di rete che il sistema genera/riceve.

cpu_usage_esxiTutti i dati citati solo utili a definire un comportamento del sistema: se mettiamo in forma grafica il carico delle CPU di un server o di uno switch vedremo un certo andamento che si ripete nel tempo. Il traffico TCP a cui un sistema è sottoposto è strettamente legato al tipo si servizio che il server eroga, analizzando quindi il traffico di un File Server vedremo per lo più sessioni CIFS o NFS con i vari client della rete e l’intensità del traffico è legata alla presenza di utenza in rete. Anche in questo caso le “conversazioni” tra client e server possono essere quantificate nel tempo a produrre un grafico dove vedremo, ancora una volta, l’andamento delle sessione CIFS del nostro File Server MS.

L’analisi dei comportamenti dei sistemi informatici (behaviour analysis) ci aiuta ad imparare quale sia il comportamento tipico di un sistema complesso (applicazioni, server, reti, persone) e di individuare variazioni sensibili nei trend registrati. Questo consente di poter individuare rapidamente comportamento diversi dall’ordinario senza impostare delle soglie di allarme come si farebbe in un sistema di monitoraggio.

L’analisi comportamente non prevede statiche impostazioni di policy o soglie di funzionamento, in primo luogo perché non necessariamente i dati raccolti possono essere trattati in questo modo ma soprattuto perché il focus non è il raggiungimento di una soglia critica ma la presenza di comportamenti non consueti e quindi degni di interesse.

low-cpu-loadEsempio: osservando l’immagine allegata si vede una CPU che tendenzialmente lavora tra il 20% e il 60% di carico e ad una precisa ora il carico varia assestandosi poco sotto il 20%. Un sistema di monitoraggio ci avviserebbe probabilmente solo se la CPU raggiunge il 90-100% del carico (a seconda delle impostazioni scelte) per un certo periodo di tempo, in questo caso quindi nulla sarebbe accaduto. L’analisi comportamentale ci dice che la CPU sta lavorando in un modo in cui di solito non lavora. Questo diverso approccio porta ad individuare situazione dove le soglie non agirebbero ma dove evidentemente è successo qualcosa che ha avuto un impatto sul carico della CPU.

Il modello di machine learning che personalmente trovo più interessante per individuare un comportamento o pettern è quello dell’apprendimento non supervisionato: il programma, dato un input, cerca di trovare uno schema nei dati collezionati senza che questi vengano etichettati a priori. In questo modo è possibile scrivere algoritmi generici in grado di cercare schemi strutturati in eterogenee fonti di informazioni come possono essere i sistemi informatici di cui si vuole eseguire l’analisi.

La particolarità di questo modello sta nella capacità della macchina di migliorarsi nell’attività di riconoscimento dei pattern e delle relative anomalie. Questo è possibile in quanto con l’aumentare dei campioni di input è possibile istruire l’algoritmo affinché vengano considerati i dati nel loro insieme e non solo in intervalli di tempo definiti aprioristicamente. (maggiori informazioni qui: https://it.wikipedia.org/wiki/Apprendimento_automatico)

In ICT esistono due principali campi di applicazione di questo modello.

Indubbiamente l’analisi di questi dati è utile per comprendere se un sistema complesso, composto da diversi software che collaborano, sta performando correttamente e, in caso contrario, è estramemente utile all’individuazione delle anomalie che impattano sulle prestazioni del sistema.

Sul fronte della sicurezza informatica l’utilità è forse più lampante: malware e attacker generano tipicamente comportamenti inattesi all’interno dei sistemi informatici e tali comportamenti spesso passona inosservati ai classici sistemi di sicurezza che basano il loro funzionamento su specifiche firme o soglie.

In generale è più utile sapere se un utente sta eseguendo attività che di solito non esegue (es: copia massiva dei dati dal File Server) più che bloccare aprioristicamente tutti i canali di cominicazione verso l’esterno, tali azioni possono invece essere eseguite dal sistema che individua l’anomalia (remediation). In questo modo se il sistema ha imparato che l’utente Mario Rossi tipicamente lavora su 50 file al giorno e scambia 2 GB di dati con il File Server, potremmo istruirlo nel limitare il suo accesso ai servizi nel caso in cui il suo comportamento evidenzi una sensibile variazione… e in caso sarà possibile allertare il team competente.

In questo caso potremmo scoprire che la workstation di Mario Rossi è stata compromessa ed è in corso un tentativo di furto di informazioni, o che Mario Rossi stesso sta prelevando massivamente informazioni dal File Server senza apparante ragione che verrà puntualmente indagata.

Concludo con una nota di non tecnica: esistono diverse soluzione che mettono a disposizione queste potenzialità, alcume molto verticali dove sono già pronte alcune specifiche funzionalità, altre molto generaliste che richiedono molte configurazioni per lavorare correttamente. Ho avuto modo di notare che spesso ci si sofferma sulla rete con il paradigma Network-as-a-Sensor, sistema che trovo valido ma che reputo un po’ limitato rispetto alla visione più ampia in cui posso mettere a confronto il traffico di rete con i logs delle applicazioni e le metriche di funzionamento dei sistemi.

Diciamo che, come spesso capita, non c’è una soluzione che spicca particolarmente e il focus deve essere la specifica esigenza.

Cyber Attack Analy(si|tic)s

cyberattack-mapRiprendo qui un tema che diventerà, a mio avviso, un tormentone per gli addetti ai lavori. Nel corso dell’anno appena passato ho spesso parlato di analisi dei dati che, in ambito ICT, spesso significa controllo delle metriche di funzionamento al fine di verificare prestazioni, efficienza, funzionalità e mille altre cose.

In questo momento quando penso ad un sistema complesso, di qualsiasi tipo (server farm, catene di produzione, social network, sistemi domotici, ecc), non posso non riflettere sulla quantità di dati – gigantesca – che potrei analizzare per controllare principalmente due cose, banalizzando al massimo:

  • se sta funzionando bene
  • se è al sicuro

In questa occasione mi soffermo sul fattore sicurezza (e ho in previsione degli speech in merito) in quanto credo sia un po’ più urgente degli altri temi visti gli attuali trends… l’ambito prestazionale/funzionale lo riprendo prossimamente; il tema è quello dell’utilizzo dei dati, informatici e non, derivanti dai comportamenti dei sistemi complessi per dedurre se il nostro ambiente (azienda, casa, identità digitale, ecc.) è sottoposto ad una minaccia informatica o meno. Se questa frase non vi ha fatto svenire o addormentare potete proseguire nella lettura.

Partiamo dall’inizio: la quantità di dispositivi smart che entrano nel nostro uso quotidiano sta notevolmente aumentando, l’automazione industriale si affida (necessariamente) a sistemi informatici complessi, molti di noi vivono costantemente connessi alla rete grazie ai propri smart phone.

Forse neanche ci rendiamo conto di quanto siamo immersi nella tecnologia, in contesti lavorativi come tra le mura domestiche, e quanto questa tecnologia sia in qualche misura “accessibile” dall’esterno al mero scopo di sottrarci informazioni che possono mettere a repentaglio la nostra privacy o il nostro business (o quello dei nostri clienti).

A questo proliferare di “porte di accesso” connesse alla rete si sommano le nuove tecniche di attacco informatico, molto più sofisticate di un tempo. In particolare sono stati sviluppati malware le cui caratteristiche a livello di codice consentono una quasi totale invisibilità tale da vanificare, in molti casi, la protezione dei software antivirus.

Anche le tecniche di intrusione informatica si sono affinate: gli attacker si preoccupano di camuffare molto bene le proprie attività mescolando azioni di attacco reali ad azioni pseudo-reali con lo scopo di confondere le proprie tracce nel tentativo di accedere ai sistemi. Un esempio è facilmente osservabile analizzando i logs di un qualsiasi web server: all’interno del progetto #init1 abbiamo analizzato i logs di specifici honey pot sui quali erano stati implementati piccoli ambienti LAMP con un sito WordPress. Questo tipo di piattaforma, molto diffusa, è tipicamente soggetta ad attacchi che hanno lo scopo di carpire informazioni dal sito web o iniettare nelle pagine del sito del codice malevolo per tentare degli attacchi XSS.

I tentativi di attacco al server vengono ovviamente “registrati” dai log dell’ambiente LAMP assieme a tutti i comportamenti leciti di consultazione del sito web “civetta”. La difficoltà è riuscire a comprendere, rapidamente, quali logs siano generati da richieste lecite a quali siano generati da un potenziale attacker che sta agendo richieste solo apparentemente lecite.

Esempi simili ve ne sono un’infinità, ma abbiamo a disposizione montagne di dati per individuare e discriminare comportamenti sospetti. La buzzword coniata da tempo è behaviour analysis: analizziamo il comportamento dei sistemi per individuare eventi insoliti, fuori dagli schemi classici di funzionamento di un sistema che, lavorando secondo uno specifico programma, dovrebbe presentare comportamenti predicibili o per lo meno corrispondenti a specifiche metriche.

Quando questo non avviene è lecito insospettirsi, è lecito definire l’anomalia comportamentale una “potenziale minaccia” di cui probabilmente non mi sarei mai accorto se non avessi correlato tutti gli eventi analizzati. Non ci resta che verificare se l’anomalia è stata generata da attività lecite o da attività sospette per le quali sarà il caso di adottare delle contromisure.

In parole povere possiamo dotarci di strumenti che ci permettano di essere molto efficienti dell’individuazione di attività sospette ben prima di subire un’intrusione, salvo situazioni tragiche delle nostre infrastrutture.

E quali tecniche dobbiamo imparare a padroneggiare noi analisti? Chiudo con un po’ di parolacce a caso: log analysis, data visualization, analytics, event correlation. Sparare termini in inglese fa sempre figo, tanto vale metterli tutti assieme e un po’ alla volta discuterli.

Insecurity of Things

iotOltre a sovrappopolare il pianeta stiamo sovrappopolando internet. Mentre scrivo questo poche righe mi guardo attorno, nel mio studio, e vedo un solo laptop e altri NOVE devices connessi alla rete… NAS, SmartTV, IP-cam, tablet, stampanti (come rinunciare al piacere di stampare a casa dalla Cappadocia), ecc.

Tutti questi oggetti hanno un sistema operativo e un indirizzo IP, ovvero quel numeraccio (es: 192.168.1.xyz) che gli permette di essere raggiunti via rete dagli altri utenti e/o dispositivi, e ci mettono a disposizione dei servizi usabili in LAN ma anche dall’esterno tramite VPN o specifici servizi spesso comodamente in cloud.

Abbiamo chiamato questa pletora di funzionalità Internet of Things (IoT): l’internet delle cose, oggetti che oggi hanno una connessione ad internet e la sfruttano per fare il loro lavoro.

Ovviamente, come avviene per i sistemi operativi dei Personal Computer e dei Server, capita che vi siano dei bug o delle vulnerabilità che espongono a diversi rischi di sicurezza anche tutti questi oggetti che, in soldoni, non sono altre che mini-computer istruiti ad eseguire poche e limitate funzioni.

Su questo fronte abbiamo un duplice problema in ambito sicurezza.

Il primo si riferisce alla privacy degli utilizzatori in quanto questi sistemi spesso contengono dati privati (la NAS di casa con le foto delle vacanze) o dati sensibili (informazioni risevate, account). In alcuni casi possono fornire informazioni realtime sull’utente: accedendo, ad esempio, ad una IP-cam è possibile verificare la presenza fisica in determinati ambienti. Un rischio non da poco.

Il secondo fronte, che analizziamo qui, è un po’ più complesso ed ha scopi un po’ più “globali”. Il tema è quello delle Botnet applicato all’IoT. In seno al progetto #init1 si sta conducendo uno dei tanti studi di ricerca che analizzano alcune tipologie di attacco informatico (per i dettagli vi invito a contattare il team di #init1). Nel corso dello studio si è avuto modo di osservare il comportamento di alcune Botnet “a caccia” di dispositivi come quelli citati ed in particolare NAS, IP-cam, sistemi domotici, sistemi Raspberry-Pi in generale.

I log analizzati mostrano come un considerevole numero di sistemi sta conducendo attacchi di tipo SSH Brute Force (quindi attacchi molto banali) utilizzando le tipiche credenziali di default di alcuni prodotti del mondo IoT, con lo scopo di compromettere il sistema, guadagnare un accesso non autorizzato ed installare una piccola back-door. (comportamento osservato su un honeypot)

honeypot ssh log
honeypot ssh log (json): l’attacker cerca dispositivi Raspberry

Alcuni di questi sistemi vengono poi utilizzati per eseguire delle ulteriori scansioni all’interno della rete LAN in cui si trovano a caccia di altri device, un po’ come se qualcuno riuscisse ad accedere alla mia NAS malamente pubblicata in internet e da li cercasse di attaccare anche la mia IP-cam, ip mio PC, ecc.

Una volta compromesso il device entra a far parte di una gigantesca Botnet fatta di frigoriferi, termostati, telecamere, citofoni e frullatori ai quali abbiamo dato un accesso ad internet e che per qualche ragione non abbiamo adeguatamente protetto come si fa abitualmente per un PC o per un Server.

Queste Botnet sono enormi – ma veramente enormi – e possono essere utilizzate per lanciare mastodontici attacchi DDoS verso obiettivi che si pensava essere troppo grandi da “DoSsare“… eppure è successo.

L’evidenza dei fatti ci porta ad affermare che il tema IoT non è stato affrontato dai Big del settore con la dovuta cautela in ambito sicurezza. Già il fatto che molti sistemi escano dalla fabbrica con una utenza di default uguale per tutti i device di quel modello dovrebbe farci riflettere sul livello di “leggerezza” con il quale si sta operando.

La situazione attuale delle Botnet è, inoltre, già andata ben oltre in quanto i log mostrano che in molti casi i sistemi che stanno esegunto gli scan a caccia di device sono spesso loro stessi dei dispositivi “IoT”. Ovvero si stanno costituiendo delle IoT Botnet in grado di espandersi molto rapidamente con migliaia di sistemi. La potenza di fuoco è ovviamente notevole, molto più grande di quella a cui siamo “abituati”, se non altro per numero di device coinvolti.

E quindi?

Prima cosa da fare è valutare immediatamente delle serie strategie per proteggere i device. Su questo fronte devono metterci le mani prima di tutto i produttori blindando opportunamenti i sistemi o dando istruzioni precise e vincolanti ai consumatori su come installate i propri device.

Chi ha competenza in materia e gestisce reti (aziendali ovviamente) deve essere consapevole di cosa ha in LAN. In questo momento anche la Smart-TV che abbiamo nella sala riunioni potrebbe essere terreno fertile per un attacker… le stiamo controllando? Per non parlare degli SmartPhone (problema vecchio) che portano in rete le peggio cose. Stiamo adottando soluzioni di controllo per questi End Point?

Salendo di livello c’è il tema dei DDoS: la quantità di connessioni simultanee che queste Botnet possono generare è devastante. L’arma non è tanto la banda che vanno a “consumare” sui sistemi vittima ma il numero di richieste che in poco tempo rendono il servizio attaccato indisponibile per saturazione delle risorse. Mitigare questo genere di attacchi comincia ad essere complesso.

In campana

Come #init1 anche altri progetti e specialist del mondo della Cyber Security (alcuni anche illustri italiani) stanno discutendo il tema di quella che in alcuni casi è una vera e propria arma.

Non nascondiamo la testa sotto la sabbia. Seguiamo news e rumors sul mondo della Cyber Security e cominciamo a guardare che tipo di strategie e soluzioni possiamo adottare.

IoT: a cosa mi serve?

Periodicamente il mondo dell’Information Technology ci regala degli acronimi che molti abusano senza avere la minima idea del loro significato. Il web 2.0, il cloud, i big data… e oggi, non lontano da quest’ultimo, abbiamo l’IoT… l’Internet delle cose.

Ad onor del vero alcune tematiche le abbiamo quasi chiare.
Tutti hanno capito che si sta parlando di qualche miliardo di devices (c’è chi dice 5, chi dice 10…) connessi ad internet. Tutti abbiamo capito che in qualche modo questo oceano di sistemi genererà della complessità tecnica a cui far fronte e richiederanno un maggior numero di risorse per la gestione (infrastrutture, sistemi, applicazioni)… questo è forse il cavallo di battaglia più utilizzato da chi vende ferro. Tutti abbiamo capito che questi devices potranno mettere a disposizione molte informazioni.

Sento, purtroppo, parlare poco della principale opportunità – e relativa problematica – che l’IoT offre: come rendere utili queste informazioni. Cosa ci facciamo con tutti questi dati? Ora che ne abbiamo veramente tanti, ora che sono veramente Big, a cosa mi possono servire?

Su questo fronte leggo esempi un po’ limitati come “il frigorifero che mi dice che sono finite le uova”. Si, è utile che il device frigorifero mi fornisca questa informazione e provveda ad aggiornare la mia App con la lista della spesa. Stiamo però pensando troppo in piccolo, il livello di efficienza è ancora basso. Molto più utile è sapere che è la quarta volta che faccio scadere il formaggio e devo quindi rivedere la mia spesa riducendone l’approvvigionamento, o meglio ancora ci pensa il frigorifero ad aggiornare online la mia lista della spesa. Estremamente più utile è interpolare i dati degli alimenti che acquisto (calorie, vitamine, proteine, ecc) con le mia oscillazione di peso e scoprire che da quando compro quella scatola di cannoli da 600 gr. tutti i sabati la mia massa grassa è aumentata e la mia Fiit app mi proporrà di correre qualche km in più questa domenica. (si, ci potevo arrivare anche senza l’interpolazione dei dati, ma così è più fico)

Tutto ciò, rapportato al singolo individuo, ha già un sapore innovativo: potrebbe aiutarci a percepire meglio l’impatto delle proprie scelte, potrebbe aiutarci a correggere dei comportamenti poco utili, poco efficienti… ma se lo portiamo in azienda scopriamo fattori moltiplicativi decisamente più interessanti.

Un esempio abbastanza lampante è il settore della ristorazione. Il gestore di un locale ha tutto l’interesse economico (e si spera anche etico) nel non sprecare la merce e servire cibi con valori nutrizionali equilibrati. Scoprire che la propria merce viene gettata perché resta inutilizzata dovrebbe farlo saltare sulla sedia al pensiero dei soldi che ha buttato.
Tipicamente sappiamo quanto approvvigioniamo, più difficile è sapere quanto sprechiamo, dove spreco == inefficienza. Nell’esempio della ristorazione essere consapevoli degli sprechi ed averne contezza avvia un processo per rendere più efficiente l’approvvigionamento della materia prima con relativo risparmio di denaro in acquisto, spazio in magazzino e costi di gestione e smaltimento.
E il business del “cibo sano”? Anche questo è un trend che possiamo leggere dai dati che ci forniscono, ad esempio, i social network… e se i clienti preferiscono il cibi, ad esempio, bio il ristoratore ha tutto l’interesse economico a fornirli.

Per avviare questo processo dobbiamo attraversare tre fasi, un percorso che le aziende (o le persone) devono necessariamente fare per beneficiare dell’era dell’IoT e dare un sonoro scossone al proprio business, qualsiasi esso sia.

Data Collecting
Per prima cosa dobbiamo registrare, organizzare e modellare i dati. Che si tratti di materie prime o dei log di un firewall, i dati vanno collezionati ed organizzati secondo specifici criteri che ne consentano una rapida consultazione in un formato comodo. Il dato istantaneo ha poco valore, è il trend che ci interessa, quindi ciò che collezioniamo va mantenuto nel tempo.

Sul piano tecnologico non possiamo pensare di gestire questa enorme quantità di dati “alla vecchia maniera”. Il paradigma dell’applicazione che macina dati su un database SQL che crescerà all’infinito qua non funziona più (imho) come non funzionano più le architetture rigide: X server di front-end, Y di back-end, ecc… X e Y diventano variabili mutevoli in virtù di Z fattori, nulla è certo e tutto deve essere dinamico. (altrimenti cosa ce lo siamo inventati a fare il cloud?)

Non è un caso che i produttori di software che di mestiere macinano dati stanno utilizzando database NoSQL, ci si spinge pesantemente verso le cloud ad elevata automazione e si investe in infrastrutture ibride, elastiche (mai sentito il termine Elastic Cloud?), scalabili.

Che dati raccogliere? Tutti. Logs, eventi, traffico di rete, accessi, trend, posizioni geografiche, telemetrie, status, ecc, hashtag, rumors… tutti i dispositivi ed i canali sono una fonte di dati  e tutti i dati possono essere presi in considerazione.

Se raccogliere i dati è relativamente semplice, organizzarli lo è un po’ meno. Esistono diversi standard e formati anche solo nell’esportazione dei logs. Dobbiamo quindi scegliere strumenti che ci consentano di gestire in modo comodo dati generati anche in formati differenti e, se possibile, convergere verso un modello rappresentativo unico (personalmente trovo molto comodo JSON e l’intramontabile XML, ad esempio).

Ovviamente per fare tutto ciò avete a disposizione diverse strade, ci sono ottimi prodotti software che vi possono aiutare (a me piacciono molto Splunk e Kibana) e fior di aziende che possono fornire consulenza specifica sulla gestione dei dati ed in particolare dei Big Data o che possono fornire architetture a tal fine. Nulla vieta, avendone la possibilità, di utilizzare le tecnologie disponibili per crearsi qualcosa di custom. Nessun limite alla fantasia.

Data Anyalsis
Ho i dati, cosa ci faccio? Forse questa è una delle sfide tecnologiche più avvincenti. L’immensa quantità di dati di cui si dispone spesso non è consultabile in modo intellegibile. Milioni, se non miliardi, di informazioni senza un modello rappresentativo sono semplicemente inutili. E’ necessario analizzare i dati raccolti al fine di rappresentarli in forma grafica ed individuare dei pattern e/o delle correlazioni funzionali.

Sull’individuazione dei pattern la strada esiste già, di base si tratta di individuare la funzione che descrive il tracciato, mentre sul tema delle correlazioni la questione si complica un po’. Correlare, in questo caso, significa individuare una variazione in un trend causata da eventi terzi e non necessariamente contenuti nella base dati di cui si dispone.

Tornando all’esempio della ristorazione, la materia prima (il formaggio ad esempio) raggiunge la data di scadenza evidentemente perché non è stato consumato per tempo. I motivi posso dipendere da fattori controllabili ed evidenziabili nella propria base dati (ordinato eccessivo, prezzo elevato del prodotto, ecc) o del tutto fuori controllo come, ad esempio, un’improvvisa e generalizzata diminuzione di gradimento del prodotto da parte dei consumatori.
Uno di questi fattori “fuori controllo” che mi piace citare (in onore di alcune persone che stimo) è la reputazione di cui farò cenno nel prossimo punto. Vi ricordare il caso Moncler-Report? Quanto ha giocato un ruolo determinante la Brand Reputation?

Il processo di analisi dei dati deve essere real-time, ovvero nel momento in cui i  dati sono disponibili questi devono essere immediatamente elaborati ed analizzati per produrre un output intellegibile (un grafico, un report, un poesia o una ballata). L’individuazione dei trend e le correlazioni dei dati ci permettono di fare previsioni sull’oggetto dell’analisi e, se necessario, di intraprendere azioni correttive in tempo reale. In questo modo il nostro ristoratore disporrebbe di un grafico che, in tempo reale, riporterebbe un’abbassamento di gradimento verso il prodotto “formaggio” e sarebbe così possibile variare il menù del giorno secondo il nuovo gradimento registrato dall’analisi, se necessario.

In informatica la predictive analytics è ampiamente utilizzati per valutare correttivi infrastrutturali nella gestione dei workloads o delle security policy. Come nell’esempio del “consumo di formaggio” vengono presi in considerazione i consumi di risorse nel tempo per individuare dei pattern di efficienza operativa in modo da agire sui sistemi per tempo qualora si presenti una variazione significativa dei carichi. Talvolta questi processi possono essere automatizzati per rendere ancor più efficiente il sistema fino ad ottenere una infrastruttura che tende ad autoregolarsi secondo policy e parametri prestabiliti. Non parliamo di IA ma di semplice analisi degli eventi ed applicazione di “contromisure”.

Questo paradigma è in realtà replicabile in qualsiasi campo… laddove posso tracciare un trend posso anche andare a caccia di un pattern, studiarlo, interpretarlo, giungere a delle conclusioni e scatenare delle reazioni.

Data-to-Business
Ho i dati, li ho analizzati e ho capito cosa sta succedendo… ora? Ora miglioriamo il nostro business! Prendiamo decisioni che ci permettano di essere più efficienti, più agili, più reattivi, più disponibili. Già nei piccoli esempi precedentemente riportati i correttivi erano atti a migliorare l’efficienza del nostro sistema: il ristoratore avrebbe speso meglio i propri soldi ed il SysAdmin avrebbe migliorato la distribuzione dei workloads della propria infrastruttura/applicazione.

Prendiamo in considerazione anche i dati che possiamo reperire all’esterno della nostra struttura – come la citata reputazione – e mettiamoli in relazione con i dati di cui già disponiamo. Se in un certo momento storico la reputazione del prodotto “formaggio” scende drasticamente è del tutto probabile che vi saranno meno persone disposte a consumarlo. In tal caso, anche se a livello di approvvigionamento ho agito correttamente, un fattore esterno può comunque influenzare le scelte dei consumatori che non acquisteranno il prodotto, il quale resterà inutilizzato fino alla data di scadenza.

Questo principio si applica a moltissimi prodotti: la reputazione di un Brand o di uno specifico bene ne influenza drasticamente il consumo ed è un esempio di dato “esterno” di cui tener conto per prendere decisioni efficaci. Non è un caso che siano prese in grande considerazione le famigerate analisi sintetizzate nei Gartner Magic Quadrant tanto da motivare rinnovi tecnologici perché un prodotto non è più Leader.

Interpoliamo le nostre fonti con fonti esterne, con i trend dei social network, con le stime di mercato… e condividiamo – perché no – le nostre analisi con il nostro network e con i nostri partner affinché si possa fare una strategia comune. Un esempio di cooperazione molto banale è quello che vi può essere tra il Brand che produce uno specifico prodotto ed il System Integrator che lo porta sul mercato e e installa/gestisce il prodotto in tutto il mondo. I dati analitici del System Integrator sono preziosi come l’oro per il produttore che li può utilizzare per migliorare la propria soluzione.

Combinando i dati messi a disposizione dalle nostre fonti con quelli provenienti da fonti esterne potremmo individuare nuovi trend in crescita, valutare nuove partnership, nuove tecnologie, nuove idee… valutare oggi le esigenze di domani, nostre e del mercato.

Concludo…
…questo sproloquio ribadendo che la quantità di dati di cui già disponiamo è immensa, la quantità di dati di cui potremmo disporre sfruttando l’IoT è difficile persino da immaginare. Personalmente ritengo molto utile (e strategicamente vantaggioso) per tutte le aziende e per i professionisti lavorare in direzione della data analysis e della data visualization, individuare prodotti validi in tal senso ed integrarli con gli strumenti oggi disponibili.

Disporre di molte informazioni genera l’esigenza di volerle leggere ed interpretare al meglio ed il più rapidamente possibile. Anche nel “mio piccolo” sapere, ad esempio, quale tecnologia cresce più rapidamente di altre ha la sua utilità, molti di noi operano le proprie scelte tecnologiche dopo aver consultato recensioni, articoli, studi, analisi… un lavoro doveroso e spesso oneroso. Poi arriva il citato Gartner Magic Quadrant con 4 quadrati e 7 pallini colorati ed è fatta… decisione presa. Questo è il potenziale di una efficiente data analysis/visualization.

Chi accede ai dati aziendali?

In una rete aziendale, se le cose sono state progettate ed implementate con criterio, l’acceso alle risorse è regolamentato da specifiche policy: l’IT Manager avrà definito chi può accedere a determinati servizi e dati profilando gli utenti della rete e definendo dei gruppi. Si evita così di dare accesso indiscriminato ai file dell’ufficio HR per ovvie ragioni legate alla privacy, per fare un esempio molto pratico.

L’esigenza non è però sempre così banale. Potrebbe essere necessario, per l’IT Manager e per l’azienda, sapere quali sono i dati a cui l’utenza accede pur avendone pieno diritto concesso dalle policy. Sapere chi accede ai dati, come vi accede e come li utilizza può essere di immenso aiuto per rilevare possibili comportamenti anomali da parte degli utenti della rete o di presunti tali.

Audit
Il requisito per qual si voglia analisi è disporre di un set di dati di riferimento. In questo caso il dato è rappresentato dai log di accesso ai file dei sistemi aziendali; i sistemi operativi più diffusi hanno infatti la possibilità di tracciare l’accesso (o il tentativo di accesso) ad una specifica risorsa come un file o una share.

Sempre ipotizzando di aver fatto le cose per bene l’azienda disporrà di un sistema di autenticazione per consentire ai diversi device (Laptop, Workstation, Tablet, Smartphone) di accedere alla rete aziendale e poi ai dati in essa contenuti: sia che il sistema acceda alla rete cablata o tramite sistemi wireless l’utente dovrà inserire delle valide credenziali che il Directory Server dovrà verificare. Anche questo evento può essere facilmente tracciato grazie ai log dei sistemi coinvolti.

Con queste poche essenziali informazioni possiamo già farci un’idea di chi si è connesso alla rete in un determinato momento, che sistema ha utilizzato, che IP gli è stato assegnato, a che risorse ha acceduto e molto altro.

Consultazione, interpolazione e deduzione
Abbiamo un sacco di dati, cosa ce ne facciamo? Quanto meno abbiamo modo di consultare queste informazioni semplicemente anche solo per sapere chi mette le mani su determinati file o chi era connesso alla rete in un certo momento, con che IP (posizione logica), su che apparato (posizione fisica). Potremmo ad esempio generare un report per l’ufficio HR ove viene specificato chi ha acceduto a dati sensibili così da valutare, se necessario, attività correttive. Se accendiamo qualche neurone possiamo utilizzare questi dati per analizzare il comportamento degli utenti interpolando diverse informazioni fino a dedurre il comportamento dell’utente.

Banalmente se un utente ha timbrato il cartellino nella sede di Roma e 10 minuti dopo il suo Laptop risulta connesso alla sede di Milano, forse qualcosa non torna.
Altro esempio un po’ più complesso: prendendo in esame i dati di accesso ad un file molto spesso si riesce ad individuare un pattern di utilizzo della risorsa. Una volta individuato il pattern di utilizzo, qualsiasi esso sia, sarà sufficiente tracciare i cambiamenti per far emergere un potenziale rischio. Esempio: se il file TopSecret.txt è acceduto solo dall’ufficio Marketing tipicamente verso la fine del quadrimestre, un’eventuale accesso alla risorsa in quantità considerevole fuori dal periodo indicato dal pattern potrebbe essere considerato un comportamento anomalo.

splunk_file_access

Esempi di comportamenti chiaramente anomali possiamo farne davvero un’infinità:

  • accesso massivo ai dati durante l’orario di chiusura degli uffici
  • anomalie di associazione device/utente
  • accesso a dati sensibili (anagrafiche, cedolini, contratti, …)
  • condivisione di dati sensibili
  • cancellazione o manipolazione massiva di dati sensibili

Tutti questi eventi possono essere tracciati ed individuati con molta semplicità… dopo che sono avvenuti. Il tracciamento dell’accesso ai dati non è ovviamente sostitutivo alle policy di gestione del dato che deve essere adeguatamente protetto anche da chi è titolato ad accedervi in quanto anche l’utente più attento non è esente dal rischio di commettere errori.

Data Loss Prevention
Oltre ad osservare quello che accade possiamo fare qualcosa per intervenire sugli eventi in corso. Diamo ovviamente per scontato che l’infrastruttura sia adeguatamente protetta da un solido sistema di backup configurato in modo corretto… non mi riferisco alle arcaiche policy del “faccio il backup tutte le notti”, i tempi sono un po’ cambiati e abbiamo a disposizione strumenti molto più evoluti che ci aiutano ad avere una protezione continua del dato.

In questo continuum i dati si spostano in molti modi, dalla banale email alle condivisioni via cloud storage, social media, collaboration services, ecc. Per essere consci di chi sta accedendo ai nostri dati dovremmo controllare tutti i canali con i quali i dati possono uscire dell’azienda, compresi gli USB drive che tutti abbiamo nelle nostre borse.

Se questo era complesso quando la dotazione informatica aziendale era il PC, l’attuale trend che vede pesantemente impiegati Tablet e Smartphone complicata notevolmente le cose. Per definizione questi oggetti sono “mobili” e accedono in vario modo alla rete aziendale. Pensare di gestire centinaia di utenti e migliaia di device che girano per il territorio con delle policy di Active Directory e con delle ACL sui Firewall è semplicemente follia. E’ necessario sapere come gli utenti utilizzano i dati, quindi il miglior punto di controllo è il device. Esistono moltissime suite che consentono il controllo dei device aziendali così da intercettare e talvolta prevenire la perdita dei dati, sia essa volontaria (dolosa) o accidentale.

Quindi?
La quantità di dati aumenta, l’accessibilità ai dati aumenta, le modalità di accesso aumentano, i sistemi di collaborazione e condivisione aumentano… spesso, soprattutto in Italia, non vedo aumentare la consapevolezza che questi trend esistono e, oltre ai benefici, portano anche dei rischi.

Ovviamente il rischio è relativo al tipo di dato. Se un mio utente si porta a casa l’elenco degli interni telefonici aziendali forse non interessa a nessuno, ma se si porta a casa i file di un progetto in corso che vale qualche milione di euro o i dati di un brevetto … … a qualcuno dovrebbe interessare, quanto meno per verificare le intenzioni.

I prodotti esistono… “We have the technology”, dobbiamo solo imparare ad usarla e/o chiedere aiuto a chi ne sa più di noi.

Io (come tanti altri) son qua.

Cisco HyperFlex

In queste ore sul blog di Cisco appare un annuncio decisamente interessante per chi si aggira nel mondo della server consolidation.

Fino a ieri la massima integrazione tra server Cisco ed il mondo storage era rappresentata dal mondo del *POD*: FlexPod (Cisco UCS+NetApp), vBlock (Cisco UCS+EMC), VersaStack (Cisco UCS+IBM). Il tema è molto maturo e spesso ci si riferisce a questi sistemi come soluzioni hyper-converged su cui persone come il sottoscritto lavorano molto volentieri (personalmente vedo che i progetti in questa direzione piacciono molto).

Ora Cisco fa un altro passo in avanti, non è la prima a fare questo passo ma stiamo comunque parlando di Cisco. Il passo in avanti si chiama HyperFlex e si tratta di una soluzione completamente hyperconverged al momento disponibile in tre versioni.

hyperflex.PNG

HX220c rappresenta la soluzione hyperconverged più piccola dove ogni host è equipaggiato con processori Intel E5 2600 v3, da 256 GB a 512 GB di RAM e 6 dischi SAS da 1,2 TB. La cache è affidata ad un Intel S3610 da 480 GB che da solo presenta un “Random 4k write” di 28mila iops.

HX240c è il fratellone che arriva a montare 784 GB di RAM, presenta lo stello taglio di dischi SAS ma arrida a montarne 15 e la cache è affidata ad un Intel S3610 da 1,6 TB, un po’ più “lento” con i suoi 27mila iops, ma tre volte più grande della cache disponibile sul HX220c.

La terza versione è per chi divora CPU e RAM: è una configurazione ibrida tra gli HX240c e la piattaforma UCS che consente di sfruttare lo scaling di potenza dato dalle lame B200.

Prima impressione
Ovviamente non ho ancora messo le mani su queste macchine quindi ho poche considerazioni da fare e non voglio, in questo post, spiegare i vantaggi del concetto di hyper-convergence (scriverò due righe più avanti).

Sicuramente poter contare su UCS Manager per la configurazione del tutto è un punto a favore notevole.

E’ molto probabile che gli interlocutori interessati alle soluzioni Cisco in ambito IT abbiano Cisco anche a livello di rete e mi aspetto di vedere in futuro scenari di integrazione con la tecnologia NX-OS così come da subito viene proposta l’integrazione con il mondo UCS.

La competition?
intgegrated_systems_magic_quadrant_august_2015

Nel Gartner Converged Infrastructure Magic Quadrant la situazione aggiornata all’estate 2015 era abbastanza chiara. Cisco compariva tra i Leaders sia singolarmente che sotto il cappello VCE (VMware-Cisco-EMC) assieme al nome che in questo campo sta segnando, a parer mio, il passo: Nutanix.

Proprio Nutanix è, sempre secondo il mio modestissimo parere, il nome con coi competere. Quindi stiamo a vedere cosa succede nel prossimo futuro quanto il tema avrà raggiunto la stessa maturità della virtualizzazione.

Backup, una buona strategia

La prima domanda che mi viene posta ad un tavolo di confronto tecnico spesso è “quale sia il miglior prodotto per il backup dei dati aziendali”.

Di prodotti ne esistono un oceano e alcuni sono sicuramente di spicco, ma una risposta definitiva a questa domanda non esiste. La domanda corretta dovrebbe essere relativa alla strategia di backup.

Le aziende hanno esigenze e dimensioni diverse la classica soluzione – ottima, intendiamoci – Veeam + NAS non sempre risponde all’esigenza di protezione del dato, tanto meno nell’era “criptolocker” dove le NAS sono spesso vittime. E’ indispensabile affiancare un buon prodotto ad una buona strategia.

Arrivo a scrivere questo post al temine di uno studio che è culminato con l’ingegnerizzazione di un servizio di Data Protection rilasciato dal System Integrator per cui lavoro e con l’occasione condivido l’idea che ho maturato per una buona strategia di backup.

Esistono dei fattori trainanti e peculiarità da non trascurare:

  • Semplicità d’uso: un prodotto che considero meraviglioso come Tivoli Storage Manager di IBM spesso non è la scelta giusta in quanto molto complesso.
  • Non solo Virtual Machine: le Server Farm si sono, fortunatamente, pesantemente consolidate il Virtual Server Farm, ma esistono situazioni rimaste “fisiche” e la soluzione di Backup deve prevederlo.
  • Data Deduplication: a tutti i livelli il dato deve essere sottoposto a deduplica.
  • End Point Data Protection: soprattutto per gli utenti mobili avere a disposizione un metodo di backup del dato locale, se non dell’intero sistema, potrebbe essere estremamente utile.
  • Off-Site copy: avere il sistema di backup nella stessa sala ove sono ospitati i sistemi di produzione potrebbe comportare un rischio, è necessario avere una policy di “esportazione” delle copie dei dati all’esterno della sede operativa.

A quanto elencato ci aggiungo il paradigma di backup definito “incremental forever”, non sempre presente nelle suite di backup ma decisamente utile nella gestione del dato.

L’architettura di riferimento prevede il posizionamento di un’appliance di backup presso la sede ove solo presenti i sistemi da proteggere. Questa componente avrà l’onere di eseguire i job di backup utilizzando il paradigma “incremental forever” e gestirà la retention del dato per un periodo medio corto, tipicamente 1 o 2 mesi. Potendo contare sulle prestazioni di una LAN tipicamente Gigabit Ethernet e su un fattore di deduplica elevato si presume che le attività di copia dei dati, o meglio dei blocchi, saranno decisamente rapide.

Presso un sito remoto, o presso il Datacenter del partner di riferimento, si prevede l’utilizzo di un’ulteriore appliance ove archiviare una copia dei dati. In questo caso è possibile valutare se archiviare solo i dati per i quali è necessario mantenere una retention elevata o se mantenere una copia speculare del dato rispetto a quanto contenuto dell’appliance locale.

Questa architettura consente di avere il dato locale pronto all’uso in caso di restore, laddove tipicamente si richiede di accedere ai dati recentemente salvati. Il dato è inoltre protetto presso un sito remoto così da non compromettere il Backup Set in caso di gravi problemi all’infrastruttura di esercizio (alluvioni, incendi, atti vandalici, ecc.).

Il dato all’interno delle appliance è cifrato e non disponibile ai sistemi esterni tramite share o mappature di rete, questo consente di proteggere i dati di backup da eventuali infezioni o manomissioni in quanto solo chi ha i privilegi di accesso alla console di amministrazione del sistema può accedervi.

Non possiamo ancora parlare di Disaster Recovery (almeno per ora) in questo disegno, ma stiamo sicuramente tutelando molto bene i dati aziendali senza aver rinunciato alla semplicità d’uso del sistema laddove si è andato a selezionare un software o un partner adeguato.

A mio personalissimo parere le architettura che consentono di lavorarecomodamente in questo modo sono:

  1. Avamar + Datadomain – leader di settore ma non sempre abbordabile a livello economico
  2. Barracuda Backup – player di rilievo che da ottime soddisfazioni a livello di deduplica e semplicità d’uso

La soluzione Barracuda è risultata così semplice da consentire la creazione di un listino di servizi di Data Protection.

Per chiudere ci tengo a non discriminare gli altri pur ottimi prodotti che il mercato offre, da Veeam a Commvault, ma il messaggio che sottolineo resta lo stesso: prestate attenzione alla strategia e al disegno della soluzione più che al prodotto.

Stretched Clustering (speech al Festival ICT 2015)

Anche quest’anno sarò a questo eccezionale evento, per la seconda volta in veste di relatore (onorato) e per la prima volta con alla spalle l’azienda per cui lavoro in veste di sponsor (fiero).

Un po’ restando sul filone delle infrastrutture di virtualizzazione e della service continuity ho deciso di basare il mio intervento sugli scenari di stretched clustering, ancora una volta chiamando in causa VMware vSphere. Il concetto di “software defined” si è intrufolato in molte parti delle nostre infrastrutture di rete e sistemi, tanto che ragionare con infrastrutture di clustering in campus oggi è meno complesso di qualche tempo fa e, in molti casi, anche meno costoso.

L’intervento è diviso in quattro parti che potrei suddividere così:

  1. Scenario – Requitement – Constriction: un cappello introduttivo al tema partendo dal concetto di cluster
  2. Stretched Cluster Example (mirror): forse il più “immediato” scenario di Stretched Cluster
  3. Stretched Cluster Example (preferred site): il disegno che personalmente preferisco
  4. Hyper-converged Stretched Cluster Example: un passetto avanti

Scenario – Requitement – Constriction
Prima di approcciare il tema bisogna fare i conti con un po’ di variabili. E’ indispensabile comprendere gli obbiettivi del progetto per individuare le tecnologie utili e dimensionare correttamente l’infrastruttura. Tale fase dell’analisi è anche utile per comprende se l’esigenza del nostro interlocutore è effettivamente corrisposta da un progetto di Stretched Clustering o se il “tiro” va corretto verso altre soluzioni parimenti resilienti ma che prevedono comportamenti differenti e, di conseguente, possono essere implementate con altre tecnologie.

L’obbiettivo di un progetto di Stretched Clustering non può che essere quello di disporre di un ambiente ridondato e geograficamente distribuito in grado di garantire l’erogazione di uno o più servizi anche in caso di un evento di fault presso una delle strutture che ospitano una parte degli ambienti server/storage. Devono inoltre essere richiesti tempi di ripristino molto rapiti e perdita di dati prossima allo zero.

Nel mondo della virtualizzazione il concetto di cluster accetta, in caso di fault di un host, che vi sia una perdita temporanea del servizio. Prodotti come VMware vSphere (che prenderemo ad esempio in questo post) prevedono che in caso di fault di un host le VMs impattate vengano riaccese sugli altri host del cluster. Sommando i tempi di rilevamenti del fault, i tempi di riaccensione delle VMs ed i tempi di startup dei relativi servizi (ammesso che tutto sia automatizzato anche a livello guest) tale situazione comporta un disservizio di alcuni minuti percepito dagli utilizzatori dei servizi. Per ovviare a questo esistono funzionalità specifiche come la Fault Tollerance che ci consente di non avere disservizio anche a livello guest.

I limiti del concetto di clustering sono da tenere in considerazione anche in un progetto di Stretched Cluster dove spesso l’obbiettivo finale richiesto è quello di ottenere uno scenario di Business Continuity dove R.T.O. ed R.P.O. attesi sono di fatto uguali a zero.

Esistono dei requisiti tecnici da soddisfare per ottenere un cluster. Per comodità continuo a prendere in esame la tipica infrastruttura di clustering di VMware vSphere dove i requisiti tecnici minimi sono il Networking e lo Storage condiviso tra gli host. Nel classico scenario vSphere Cluster il networking tende a collassare sugli apparati di rete del Datacenter mentre la Storage Area Network garantisce la comunicazione tra gli host e lo storage array.

Uno Stretched Cluster vSphere presenta le stesse esigenze minime ma con qualche accorgimento in più. Il disegno prevede almeno una coppia di Datacenter tra loro interconnessi dove le reti devono essere estese tra i due siti. E’ ovviamente estremamente comodo estendere le reti a “livello 2” ottenendo così una Stretched Network tra i Datacenter.

I Datastore – e relativi dati – devono essere messi in disponibilità ad entrambi i Datacenter, è quindi necessario mettere a disposizione di ogni singolo sito uno storage in configurazione di “replica” con il compagno. I dati messi a disposizione dei due storage devono essere gli stessi in ogni momento, di fatto la replica deve essere “sincrona”, ovvero al variare di un dato sullo storage del “Datacenter A” deve corrispondere la stessa variazione istantanea sullo storage del “Datacenter B”.

image-scluster

La replica sincrona del dato porta con se nuovi requisiti architetturali, in particolare deve essere garantita sufficiente banda tra i due siti per consentire il trasferimento dati (quantificabile ipotizzando il data-change) ed il collegamento deve presentare latenze molto basse, nell’ordine dei millisecondi (il valore esatto può variare a seconda dalla tecnologia storage in uso). Il tema della latenza è forse quello più delicato: per ottenere basse latenze a distanze elevate – fino a 100 km – è indispensabile disporre di un collegamento in fibra ottica dedicati. Il mancato rispetto della bassa latenza invaliderebbe di fatto la possibilità di disporre di uno Stretched Cluster.

Chiarito l’obbiettivo esistono diverse strade per raggiungerlo e di seguito esploriamo i tre principali scenari di Stretched Clustering.

Stretched Cluster Example: mirror
Forse lo scenario più intuitivo, si basa sulla disponibilità di un Datastore accessibile in lettura-scrittura presso il Datacenter-A ed una “copia sincrona” dello stesso Datastore presso il Datacenter-B disponibile in sola lettura. Le VMs possono utilizzare, indistintamente, i Datastore dei due storage: nel diagramma riportato vengono ad esempio raffigurate delle VMs attive sui nodi del Datacenter-A che utilizzano il Datastore VMFS-B dello Storage-B. In questo caso l’I/O della VM attraverserà il LINK tra i due Datacenter.

image-scluster-mirror

Cosa potrebbe accadere?

In caso di fault di uno dei datacenter, ad esempio il Datacenter-B, ad intervenire è vSphere HA. Una volta che la procedura di HA ha stabilito che gli host sono effettivamente in fault le VMs verranno riaccese sugli host rimasti attivi, quelli del Datacenter-A. A livello storage l’evento non ha impatti in quanto i Datastore sono disponibile ad entrambi i siti, le VMs riaccese nel Datacenter-A continueranno quindi ad utilizzare i virtual disk posizionati nello Storage-B grazie alla comunicazione garantita a livello di Storage Area Network.

In caso di fault di uno dei due storage, ad esempio lo Storage-B, ad intervenire è il “meccanismo di clustering” degli storage. Il Datastore VMFS-B, sino ad ora attivo in sola lettura sullo Storage-A, verrebbe immediatamente messo in disponibilità in lettura-scrittura all’intero cluster. A livello di HA il cluster vSphere non si accorgerebbe di nulla, i virtual disk verrebbero immediatamente rimessi in disponibilità delle VMs che continuerebbero a lavorare.

In caso i due Datacenter dovessero isolarsi la situazione si complica un poco. Questo scenario di fatto porta con se una debolezza in quanto l’evento in questione potrebbe comportare che in entrambe i Datacenter HA tenti di accendere le VMs che fino a prima del fault erano attive nel Datacenter compagno e che di fatto sono rimaste accese. Tale comportamento potrebbe dare origine ad una problematica nota come split-brain.

Stretched Cluster Example: preferred site
In questo scenario vengono definite delle regole di affinity per gruppi di VMs i cui virtual disk risiedono sui Datastore in lettura-scrittura del sito di appartenenza. Tale scelta consente di mantenere l’I/O delle VMs all’interno del sito a cui appartengono. Inoltre questo disegno consente di gestire meglio un’ipotetico evento di “isolamento” tra i due siti.

image-scluster-preferredsite

Come per lo scenario precedentemente descritto anche in questo caso possono verificarsi eventi di fault in vari punti della struttura ed il comportamento è molto simile: che il problema si verifichi a livello host o a livello storage i meccanismi di HA interverrebbero in modo del tutto simile al precedente scenario.

E’ invece particolarmente interessante il comportamento in caso di isolamento tra i due siti. Dal punto di vista delle VMs non vi è alcun impatto in quanto le VMs del Datacenter-A continuano a lavorare generando I/O sullo Storage-A. Stessa sorte hanno le VMs del Datacenter-B.

Dal punto di vista del cluster l’isolamento comporta una rielezione del HA master: se l’host master era locato nel Datacenter-A gli host del Datacenter-B eleggeranno un nuovo HA master per il sito. Anche in questo caso le possibilità che si verifichi uno split-brain sono reali in quanto l’innesco dei meccanismi di HA di vSphere potrebbe  avviare il processo di riaccensione delle VMs.

Per far fronte a tale problema è possibile, grazie a tecnologie storage come VPLEX, definire delle regole che impediscano, in caso di isolamento totale dei siti, la messa in disponibilità sul sito “B” dei volumi dichiarati come “prefferred” su sito “A”. Ovvero, non dovendo gestire lo spostamento di VMs tra siti, il sistema mantiene accessibili i VMFS-A* al Datacenter-A ed i VMFS-B* al Datacenter-B. Una volta ripristinato il collegamento tra i siti il sistema farà semplicemente ripartire la sincronizzazione delle LUN sotto protezione.

Hyper-Converged Stretched Cluster Example
Ultimo interessante scenario da considerare è sicuramente quello relativo alla convergenza di sistemi, storage e network. Questo tema, da solo, meriterebbe un post ed uno speech dedicato, ma per oggi ci accontentiamo di una piccola presentazione. E’ relativamente recente l’introduzione di alcune nuove funzionalità in VMware VSAN che consentono di sfruttare questa tecnologia per creare uno Stretched Cluster. Non avendo ancora avuto modo di realizzare soluzioni su questo fronte “rubo” l’immagine descrittiva direttamente dal blog di VMware:

image-scluster-vsan

In questo scenario il paradigma è completamente diverso: sono richiesti tre siti tra loro interconnessi per garantire il corretto funzionamento dello Stretched Cluster, due attivi ed uno di “quorum”. I due siti attivi sono costituiti da gruppi di ESXi server che mettono a disposizione delle VMs tutto il virtual hardware necessario, il sito di quorum contiene solo informazioni e dati specifici per il corretto funzionamento della ridondanza a livello cluster, il server in oggetto non partecipa attivamente al cluster di servizi VMware vSphere.

In questo scenario Datacenter e Storage sono identificati dagli stessi oggetti fisici: i server. In modo molto simile a quanto già illustrato nei precedenti scenari tale architettura si occupa di garantire la ridondanza del servizio di virtualizzazione eseguendo una riaccensione delle VMs impattare in caso di fault di uno specifico sito.

Anche in questo scenario è interessante il comportamento in caso si verifichi un isolamento tra i siti “attivi” (identificati nella figura dal Fault Domain A e dal Fault Domain C). In fase di implementazione di questo scenario viene decretato uno dei due sito come “preferred site”. Per evitare le problematiche che posso insorgere in caso di split-brain il sistema di HA fa si che tutte le VMs attive sul “non-preferred site” vengano riaccese sul “preferred site” lasciando il secondo Datacenter praticamente vuoto. Tale comportamento mette al riparo il cluster da comportamenti inattesi generati da uno split-brain.

Il comportamento è semplice quanto efficacie, a giocare un ruolo chiave è proprio il sito di quorum che consente al sistema di identificare correttamente una mancanza di LINK tra i due siti come in problema di isolamento e non come un fault reale del sito.

In definitiva…
Nel progettare e realizzare soluzioni di questo tipo è estremamente importante tenere in considerazione la resilienza dell’infrastruttura che interconnette i due siti al fine di minimizzare il rischio di split brain.

Teniamo in oltre a mente che un sistemi di Business Continuity NON è un sistema di Disaster Recovery: si tratta di scenari differenti realizzabili con tecnologie anche molto diverse tra loro.

In un panorama ICT che tende rapidamente al “software defined” mi aspetto una certa accelerazione verso le soluzioni iper convergenti dove la tecnologia permette in qualche misura di semplificare il disegno della soluzione.

Per chi ci sarà vi aspetto al festival ICT (l’11 novembre) per discutere assieme questi temi.