Dal cloud all’edge: come cambia l’architettura dei data center per supportare il business moderno

In un precedente articolo avevamo suggerito come impostare un data center assessment in relazione alla sostenibilità ambientale. Ma come conciliare gli aspetti legati alla resilienza dei data center?

La continua crescita dell‘IoT (Internet of Things), l’aumento del volume di traffico digitale e l’adozione sempre più diffusa di applicazioni basate sul cloud sono tendenze tecnologiche che stanno rimodellando il panorama dei data center.

Migliaia di applicazioni aziendali critiche che prima risiedevano nei data center interni ora sono ospitate in data center su cloud di vaste o vastissime proporzioni. Tuttavia, non tutte le applicazioni sono passate sul cloud per vari motivi, ad esempio per vincoli normativi, per BIAS legati alla cultura aziendale o a causa di applicazioni proprietarie o di problemi con la latenza.

Attualmente, le aziende di medio-grandi dimensioni, come gli istituti finanziari, convivono con diverse tipologie di data center, in una situazione “ibrida”.

Esistono normalmente tre modelli di data center che vengono utilizzati dalle aziende:

1. Data center su cloud centralizzati;

2. Data center regionali di medie-grosse dimensioni

3. Data center interni, localizzati, di dimensioni inferiori;

Data center centralizzato

I grandi data center centralizzati (dal consumo di parecchi megawatt), sia nel cloud sia di proprietà delle aziende, generalmente sono ritenuti fondamentali, per cui sono progettati ottimizzandone la disponibilità. Per garantire la continuità di questi data center, sono stati implementati standard specifici che nel corso degli anni si sono ampiamente consolidati.

Le strutture e il personale informatico gestiscono queste sedi perseguendo un unico obiettivo primario: la continuità 24/7 di tutti i sistemi.

Generalmente, queste sedi sono progettate e talvolta certificate in base agli standard Tier III o Tier IV dell’Uptime Institute (vedi figura 1 sotto). I fornitori di cloud e colocation spesso pubblicizzano queste caratteristiche progettuali di alta disponibilità per incentivare le vendite dei servizi presso i loro data center.

Standard ottimali comuni

• Ridondanza dei sistemi critici: gli impianti di alimentazione e raffreddamento critici spesso sono progettati con ridondanza 2N per evitare interruzioni causate da guasti o interventi di manutenzione.

• Sicurezza fisica di alto livello: soluzioni con sensori biometrici alle entrate, varchi di ingresso a bussola o con tornelli, videosorveglianza e guardie giurate presenti 24/7 sono ampiamente diffuse per garantire la sicurezza dei sistemi e limitare l’accesso solo al personale autorizzato.

• File e rack organizzati: oltre al blocco dei rack, i cavi di alimentazione e di rete sono organizzati per ridurre il rischio di errori umani (ad es. il rischio che vengano tirati i cavi sbagliati o che vengano collegati due alimentatori allo stesso circuito elettrico); viene pianificata, inoltre, la distribuzione dell’aria e vengono utilizzati vari dispositivi (ad es. strisce a spazzola e pannelli ciechi) per ridurre le aree più calde.

• Monitoraggio: per la gestione, il controllo e l’ottimizzazione di tutti i sistemi del data center vengono implementati sensori e misuratori per la gestione tramite sistemi BMS (Building Management Systems) e DCIM (Data Center Infrastructure Management).

Data center regionali

I data center regionali sono più vicini ai punti di fruizione (ossia dove i dati vengono creati e utilizzati) e sono di dimensioni inferiori rispetto a quelli centralizzati. Questi data center hanno la funzione di avvicinare ai punti di fruizione le applicazioni sensibili alla latenza e alla larghezza di banda e generalmente occupano una posizione strategica per la gestione di elevati volumi di dati.

Questi data center possono essere ritenuti una sorta di “ponte” tra i data center centrali e quelli ubicati all’interno delle aziende.

Analogamente ai grossi data center centralizzati, i data center regionali generalmente sono progettati per ottimizzare la sicurezza e la disponibilità, per cui i progetti Tier III non sono rari in questo tipo di strutture. A volte per questi usi vengono scelti e implementati approcci progettuali prefabbricati, sfruttando anche i progetti di riferimento come punto di partenza.

Anche i data center regionali sono presidiati fisicamente 24/7, e adottano la segmentazione dell’area fisica con diverse regole di accesso, denominata profondità di sicurezza, che rafforza l’applicazione del criterio need to know. Con la profondità di sicurezza, un’area interna è protetta sia dai propri metodi di accesso che da quelli delle aree che la racchiudono. Inoltre, qualsiasi violazione di un’area esterna può essere contenuta da un’altra protezione di accesso di un perimetro più interno, fino ad arrivare al bloccaggio del rack che, se utilizzato, serve come ultima difesa contro l’accesso non autorizzato alle attrezzature critiche.

Inoltre utilizzano, in genere, uno schema di protezione tipico che utilizza metodi in progressione e in combinazione (autenticazione a multifattore) per aumentare l’affidabilità, dalle aree più esterne (meno sensibili) alle aree più interne (più sensibili) e specifiche misure di prevenzione e monitoraggio per evitare il piggybacking (quando una persona si intrufola dietro un’altra autorizzata), il tailgating, o i tentativi di accesso tramite coercizione.

Data center interni o localizzati

Un data center localizzato è normalmente quello gestito internamente o in colocation dalle aziende. Per descrivere questi data center si utilizzano vari termini, ad esempio “interni”, “on premise” o “micro”. La potenza dei data center localizzati può variare da 1-2 MW fino ad appena 10-20 kW.

Dal momento che sono sempre di più le imprese che scelgono l’esternalizzazione delle applicazioni aziendali affidandosi a fornitori di cloud e colocation, le dimensioni di questi data center tendono a restringersi fino a un paio di rack sistemati in armadi o piccoli ambienti.

Per molti di questi moderni data center “sottodimensionati” i progetti sono Tier 1, senza particolare attenzione alla ridondanza o alla disponibilità. Non è infrequente constatare vari problemi di questi tipi di data center, come ad esempio:

• Assenza di sicurezza: spesso manca il presidio fisico 24/7 e, data la piccola dimensione, diverse misure organizzative e tecnologiche per la prevenzione degli accessi non autorizzati, e i rack spesso vengono lasciati aperti (a volte sono sprovvisti di sportelli).

• Assenza di organizzazione dei rack: la gestione dei cavi non è curata, per cui i cavi si aggrovigliano, ostacolano il flusso d’aria nei rack e aumentano gli errori umani in occasione di aggiunte, spostamenti e cambiamenti.

• Assenza di ridondanza: i sistemi di alimentazione (UPS, distribuzione) spesso sono 1N, riducendo la disponibilità e la continuità dei sistemi durante la manutenzione.

• Assenza di raffreddamento dedicato: il raffreddamento di questi piccoli ambienti e armadi spesso è affidato unicamente ai condizionatori presenti nell’edificio, per cui le apparecchiature sono soggette a surriscaldamenti.

• Assenza di monitoraggio DCIM: questi ambienti spesso non vengono affatto gestiti, per cui non esiste una gestione delle risorse e della continuità tramite strumenti software o personale dedicato.

Se si considerano le risorse che generalmente rimangono interne in un data center localizzato, come le applicazioni critiche e proprietarie e i collegamenti di rete verso il cloud (che sono fondamentali per la connettività alle applicazioni aziendali quotidiane), ci si rende conto della particolare importanza che questi data center assumono per l’organizzazione.

Un nuovo approccio per l’infrastruttura IT

Tuttavia, poiché le funzioni globali dei data center non risiedono più esclusivamente all’interno delle tradizionali quattro mura fisiche di un singolo edificio, l’intera infrastruttura deve essere vista come un unico modello operativo IT cloud ibrido all’interno di confini virtuali per scopi di pianificazione e amministrazione, che possiamo definire un “continuum” cloud-edge (figura 2).  

L’infrastruttura, quindi, non può più essere vista come un singolo componente a livello di dominio del prodotto (ad esempio, storage, elaborazione), ma deve essere visualizzata strategicamente a livello di “servizio”.

Considerando questi ambienti ibridi interconnessi, è necessario riconsiderare i problemi di criticità e ridondanza. Infatti, gli strumenti e le metriche non contemplano la dipendenza da più data center, dall’elevato numero di utenti interessati dal guasto, dalla criticità delle funzioni aziendali interessate o dal failover di un’applicazione software.

È necessario utilizzare un nuovo approccio che consideri aspetti diversi:

Si consideri come esempio un’azienda elettrica e la relativa disponibilità: non basta considerare solo gli impianti che producono l’energia e le linee in alta tensione (i “data center centralizzati”), ma occorre valutare anche le diramazioni, i trasformatori su palo e così via, per cui l’efficienza in definitiva viene misurata in base all’energia fornita ai clienti (i “data center periferici”). Il responsabile IT dei data center deve considerare questo modello di servizio pubblico in cui le strutture periferiche hanno un’importanza pari o anche maggiore rispetto ai data center centralizzati.

Ma come si può valutare (e quindi migliorare) la disponibilità di un insieme di data center in una configurazione ibrida?

Normalmente, se si considerassero i data center come dei sistemi in serie, la disponibilità totale si potrebbe esprimere come una funzione prodotto della disponibilità dei diversi data center: Disp(totale) = Disp(data center₁) X Disp(data center₂) X… Disp(data center_n).

Tuttavia, questo metodo non considera l’effettiva dipendenza dei diversi data center tra di loro (un data center a Roma potrebbe dipendere da un data center a Milano, ma non da quello di Pavia), la relativa importanza dei data center (un data center potrebbe essere utilizzato solo per le funzioni amministrative, un altro solo per servizi di supporto), il numero degli utenti coinvolti, ecc.

È necessario quindi effettuare una Business Impact Analysis (BIA) sui data center per identificare l’impatto dei servizi erogati, la numerosità degli utenti convolti, le dipendenze interne ed esterne e, in seguito ad una analisi di sensitività, individuare ed elencare i data center in ordine di criticità per l’organizzazione.

Nuovi modelli architetturali per i data center

Da un punto di vista progettuale, nei prossimi anni assisteremo a grossi sviluppi nell’ambito dei modelli architetturali per i data center, richiesti dai requisiti sempre più stringenti della continuità operativa, dalle nuove tecnologie (IoT e AI), dalla sostenibilità ambientale, dall’efficientamento operativo ed energetico, dall’ottimizzazione dei costi e dai requisiti normativi.

Un modello che si sta diffondendo è l’edge computing che espande la trasformazione digitale dei data center alle sedi in cui operano le aziende, migliorandone la sicurezza, la resilienza e l’efficienza, in particolare legate alla latency e alla larghezza di banda.

Tuttavia, permangono degli ostacoli che ne ostacolano la diffusione, in relazione alla mancanza di standard ampiamente accettati che possono creare problemi di lock-in per le aziende, alla diversità dei requisiti del settore, dei dispositivi, dei controlli software e alla complessità per la gestione e l’orchestrazione dell’edge. Le aziende adottano spesso l’edge computing attraverso casi d’uso specifici e discreti, piuttosto che a livello di architettura, rallentandone l’implementazione e l’espansione.

Modelli emergenti, complementari e non sostitutivi dell’edge computing, sono l’infrastruttura intelligente e l’infrastruttura programmabile.

Infrastruttura intelligente

L’infrastruttura intelligente è costruita a partire da componenti di base dell’infrastruttura, semplici e ripetibili, integrata e gestita in modo standardizzato e automatizzato. L’infrastruttura intelligente incapsula l’intelligenza artificiale generativa e il machine learning (ML) per la sua configurazione, in modo da fornire una configurazione virtualizzata e ottimizzata per il carico di lavoro per un’applicazione specifica, legata alle funzioni svolte dal software (fornitori come IBM, VMWare, CU Coding stanno sviluppando prototipi di questo tipo). 

Infrastruttura programmabile

L’infrastruttura programmabile invece utilizza applicazioni di metodi e strumenti tipici dello sviluppo software per la gestione dell’infrastruttura IT, utilizzabili sia per i data center locali, per il cloud on premise, per il cloud ibrido e per il cloud pubblico, rispondendo più rapidamente alle nuove esigenze dell’azienda, migliorando la qualità del servizio e liberando il personale dalle operazioni manuali.

Il concetto di infrastruttura programmabile di per sé non è nuovo, essendo stato introdotto come Infrastructure as code (IaC) già alla fine degli anni ‘90 e più ampiamente negli anni duemila da aziende come, ad esempio, Puppet e Chef, ma oggi assume una connotazione completamente originale.

Alcuni recenti progetti della comunità europea, come il progetto “Autopoietic Cognitive Edge-cloud Services ACES” integrano questi nuovi modelli con modalità innovative per affrontare le sfide presentate dalla natura dinamica degli ambienti nel continuum edge-cloud. Questi ambienti sono caratterizzati, come abbiamo visto, da requisiti di bassa latenza, hardware eterogeneo, vincoli di risorse e volatilità della domanda e richiesta di elevata resilienza e sostenibilità.

Traendo ispirazione dal concetto di autopoiesi, il progetto ACES mira a sviluppare un’architettura autogestita con proprietà analoghe, ovvero in grado di mantenersi e rinnovarsi autonomamente. Questa architettura è progettata per rispondere in modo proattivo alle variazioni esterne e interne, nonché all’evoluzione dei requisiti di servizio.

Nei sistemi distribuiti, l’autopoiesi si manifesta come reti in cui i componenti operano in modo autonomo, ma formano un insieme coeso, mantenendo struttura e funzione attraverso processi interni. Questo concetto ha ispirato lo sviluppo di sistemi informatici adattabili e robusti in grado di autogestirsi senza interventi esterni.

Nella figura 3 possiamo vedere un’illustrazione dell’accoppiamento strutturale, un aspetto dell’autopoiesi attraverso il quale il sistema vivente e il suo mezzo determinano, in modo reciproco e come risultato di un processo temporale, alcune delle loro proprietà.

Il sistema autopoietico è simboleggiato da un cerchio, che inizialmente incontra un ambiente privo di un oggetto strutturato. Attraverso interazioni continue e ricorrenti, il sistema inizia a prendere forma. Al punto t1, emerge un’entità costituita da due aspetti interdipendenti: uno risiede all’interno dell’ambiente e l’altro introduce una modifica nella configurazione strutturale del sistema autopoietico.  

Quando sono applicati all’informatica, i sistemi autopoietici si concentrano sulle dinamiche interne e sull’autoguida, in cui l’ambiente si limita a provocare il sistema, spingendo modifiche interne che si conformano alla sua struttura, come visibile nella figura 3. Questo approccio è fondamentale per la creazione di sistemi che prevengono i cambiamenti, portando potenzialmente a modelli computazionali più resilienti e intelligenti.

I sistemi autopoietici dimostrano la capacità di gestire le complessità esterne e interne, bilanciando molteplici obiettivi attraverso le capacità di auto-organizzazione come l’auto-creazione, l’auto-replicazione, l’auto-rinnovamento, l’auto-gestione e l’auto-configurazione. 

All’interno del progetto ACES sono stati inoltre adottati gli approcci di Machine Learning per realizzare le caratteristiche auto-adattative inerenti ai paradigmi di calcolo autopoietico e autonomo all’interno del continuum cloud-edge.  

Le tecniche di ML si distinguono per la loro capacità di consentire un processo decisionale intelligente, adattarsi dinamicamente ad ambienti mutevoli e ottimizzare l’utilizzo delle risorse. La capacità degli algoritmi di ML di apprendere dai dati, identificare modelli e fare previsioni è particolarmente preziosa in scenari in cui l’elaborazione e il processo decisionale rapidi e in tempo reale sono fondamentali, come nelle applicazioni IoT e nell’analisi in tempo reale.

Sfruttando il ML, i sistemi di elaborazione autonomi all’interno del continuum cloud-edge possono ottenere una maggiore efficienza, scalabilità e reattività, soddisfacendo così le esigenze critiche dei moderni ambienti di elaborazione distribuita. 

Questi algoritmi presentano tuttavia sfide per la loro applicazione alle funzioni di comportamento autopoietico. Una delle principali sfide è la scalabilità degli approcci, considerando la complessità, l’eterogeneità e il volume potenzialmente vasto di dati che devono essere gestiti per raggiungere una decisione di azione in questo ambiente.

Un potenziale approccio per superare le sfide di scalabilità di queste tecniche di gestione per ACES è quello di esplorare approcci bottom-up. In questo progetto, l’autopoiesi viene perseguita utilizzando l’intelligenza dello sciame, ovvero impiegando agenti interagenti che prendono decisioni basate su informazioni locali.  

Il progetto ACES è una delle prime applicazioni di un approccio basato su agenti nel continuum edge-cloud in cui le risorse e le richieste sono considerate agenti e la pianificazione, insieme agli obiettivi rilevanti (utilizzo, bassa latenza, efficienza energetica, ecc.), sono considerati proprietà emergenti del processo decisionale e dell’interazione locale dell’agente (autopoiesi).

Il carico di lavoro ACES viene acquisito come distribuzioni, pod e servizi Kubernetes. Il modo per interagire con questi elementi è attraverso i meccanismi principali di Kubernetes che fornirà un approccio efficiente alla gestione di queste risorse tramite azioni di posizionamento del carico di lavoro.

Gli algoritmi di ML utilizzati dal progetto, come l’algoritmo ormonale e quelli delle formiche, sono suggeriti dal mondo degli esseri viventi, in perfetta logica autopoietica.

I sistemi ormonali digitali traggono ispirazione dal sistema endocrino biologico, che regola vari processi metabolici all’interno del nostro corpo. Questo crea un sistema auto-organizzante caratterizzato da scalabilità, adattabilità e robustezza. Nel progetto, gli agenti dello sciame di offerta corrispondono ai nodi all’interno del continuum e gli agenti dello sciame di domanda rappresentano i pod che cercano un posizionamento ottimale dei nodi.  

Gli agenti dello sciame di domanda rilasciano ormoni sintetici nell’ambiente in base alle loro esigenze di risorse e preferenze. Questi ormoni trasportano informazioni sulle richieste e le priorità dei baccelli. Gli agenti dello sciame di rifornimento, che rappresentano i nodi, rilevano questi ormoni e regolano il loro comportamento di conseguenza. I nodi rilasciano i propri ormoni indicando la disponibilità e la capacità delle risorse.

La concentrazione di ormoni guida la domanda di agenti sciami verso i nodi che soddisfano le loro esigenze, favorendo un processo decisionale autonomo e informato. La comunicazione degli ormoni sintetici sostituisce i tradizionali meccanismi di controllo centralizzato con un coordinamento decentralizzato, consentendo al sistema di adattarsi alle variazioni dei pod e alle fluttuazioni delle risorse.

Gli algoritmi delle formiche invece traggono ispirazione dal comportamento di foraggiamento decentralizzato delle formiche, un fenomeno naturale in cui le formiche possono trovare in modo efficiente percorsi quasi ottimali per le fonti di cibo senza fare affidamento sulla conoscenza globale. Raggiungono questo obiettivo lasciando scie di feromoni per comunicare con altre formiche. Nel progetto ACES, all’interno del continuum edge, questo concetto viene applicato per ottimizzare l’allocazione e l’elaborazione dei baccelli da parte di agenti di sciame di fornitura, analoghi alle formiche, che rappresentano nodi all’interno del continuum.   

Inoltre, si aggiungono alla componente di ML le tecniche di ragionamento bayesiano per modificare i parametri dello sciame per migliorarne ulteriormente le prestazioni in base all’effetto osservato delle sue azioni. Questa integrazione consente alla piattaforma del progetto ACES di sfruttare l’intera conoscenza raccolta, traducendola in una serie di componenti di ragionamento che affrontano le principali sfide di gestione all’interno dell’infrastruttura edge-cloud.

Le caratteristiche dell’architettura del progetto ACES

Queste sono alcune delle caratteristiche che dovrebbe possedere l’architettura al termine del progetto ACES:

• La soluzione dovrebbe fornire una disponibilità di almeno il 99,9%.   

• Non dovrebbe esserci nessun single point of failure.

• I dati utilizzati devono rimanere privati ​​e sicuri.

• La soluzione dovrebbe essere scalabile in modo che in futuro si possano aggiungere ulteriori strutture nella rete energetica e includere risorse aggiuntive nella connettività rete.

• Quando un EMDC fallisce, altri nodi devono essere utilizzati con un sistema di hot swap.

• La latenza della comunicazione dovrebbe essere vicina a pochi millisecondi per consentire risposte in tempo reale.

• I dati dovrebbero rimanere archiviati per almeno 1 anno.

• La soluzione deve essere in grado di soddisfare carichi di lavoro diversi, come intervalli di tempo periodici non predeterminati o carichi di lavoro quasi in tempo reale.

Il progetto ACES sta indirizzando diversi casi d’uso. Tra questi si segnala un caso d’uso che utilizza dati SCADA insieme a dati da sensori grid-edge per sistemi GIS, che ha consentito un rilevamento più rapido dopo le interruzioni, una previsione accurata delle interruzioni e una pianificazione degli investimenti più affidabile, insieme al differimento degli investimenti.

Tramite la gestione di diversi flussi di dati IoT e di dati operativi, l’operatore può prevedere l’eventuale perdita di funzionalità degli asset. L’analisi delle anomalie potrebbe supportare, tra le altre cose, la pianificazione della manutenzione predittiva basata sulla frequenza delle anomalie. 

Ad esempio, particolari punti di misurazione che hanno un’alta frequenza di anomalie rilevate dovrebbero essere programmati per effettuare la manutenzione più frequentemente. Inoltre, i moduli di gestione della congestione e di controllo della tensione potrebbero funzionare per regolare la rete quando vengono rilevate le anomalie di corrente o di tensione rilevanti.

Ciò consente inoltre il dimensionamento corretto delle risorse, la riduzione del costo totale di proprietà, la definizione di strategie di gestione delle risorse basate sul rischio che includono la probabilità di guasto, la valorizzazione della criticità e l’indicizzazione dello stato dei dispositivi.

Un altro caso d’uso previsto dal progetto è l’ottimizzazione della gestione dei processi della rete energetica distribuita: l’utilizzo di un edge-mesh per la rete energetica greca decentralizza la gestione, migliorando l’uso delle risorse energetiche locali e adattandosi alle esigenze di consumo, passando da un’infrastruttura centralizzata a un’infrastruttura resiliente e adattabile con un’interfaccia utente che aiuta gli operatori nel processo decisionale e nell’intervento.