High Performance Computing (HPC)- tornare ad investire sull’Edge Computing

OK, con questa dichiarazione si capirà che sono un sistemista di vecchia scuola, per l’appunto ho iniziato ad occuparmi di sistemi HPC/Cluster nei primi anni 2000 ed ho realizzato il mio primo importante sistema Cluste HPC nel lontano 2004, da quel momento ho lavorato nello stesso ambito per grosse aziende in ambiti bancario, assicurativo, editoria, pubblica amministrazione etc…… ; ho potuto dunque analizzare per esperienza diretta che quello che legava tutti questi ambienti, che si stavano aprendo al mondo dell’offerta di servizi web online per i loro clienti (outsourcing), era la “ovvia” gestione in loco (on premise) dei dati aziendali, nonostante questo comportasse un forte investimento in hardware/network e sviluppo del software. Tutto ciò permetteva di tenere sotto controllo l’andamento dei progetti perchè per far funzionare tutti quegli avanzamenti tecnologici serviva far crescere anche il livello di preparazione tecnologica del proprio personale IT, seppur con le dovute integrazioni esterne di consulenti ad hoc, atti a portare uno slancio alla realizzazione finale del prodotto.

Dunque in un’azienda servivano un tot persone skillate in vari ambiti che procedessero di pari passo nel far avanzare il progetto fungendo anche da beta tester per i colleghi degli altri team, team solitamente suddivisi in:

  • Sistemisti
  • Database Administrator
  • Networking
  • Sviluppo (developer)
  • Cyber Security

Ogni gruppo testava se stesso e faceva da tester per gli altri così da arrivare , step by step, ai vari rilasci di pre-produzione e produzione, diminuendo, a mio avviso, di gran lunga il Bug da errore umano.

Credo che tutto ciò abbia funzionato piuttosto bene, in una specie di “status quo” fino all’arrivo della crisi del 2008 ed in particolare degli strascichi sui budget i cui effetti si sono visti negli anni subito successivi, nel frattempo il maggior sviluppo di piattaforme Cloud proposte dai Big come Gloogle Cloud ed Amazon AWS (in particolare) hanno portato alla decisione sempre più massiccia dei Manager di esternalizzare tutti i processi verso queste piattaforme per massimizzare gli sforzi nello sviluppo (programmazione) dei servizi eliminando dai budget le spese hardware, quelle per le location da dedicare alla ridondanza dei dati ed ai sistemi di backup integrati. Tutto questo ora era possibile pagarlo in un forfait di servizi on chain offerti dalle piattaforme Web-Cloud che hanno invaso il campo di gioco con acronimi di ogni genere, tra cui i primi furono le PaaS, SaaS, IaaS, CaaS, DaaS etc…. (solo la fantasia li può fermare) tagliando così anche le competenze dirette dei team poichè adesso le piattaforme web, la loro gestione, il mantenimento software, gli aggiornamenti, i backup, le problematiche di rete, i DNS, le connessioni VPN, la sicurezza e quant’altro potevano essere preoccupazione ed appannaggio di altri.

Tutto ciò per me ha solo impoverito il nucleo di esperti IT, smembrando i suddetti team e generando nuovi mostri poichè le aziende diventarono prede di “metodologie” di lavoro in stile Silicon Valley (ma ehi la verità è che funzionano solo in Silicon Valley) come la Agile, è da li sono partiti inglesismi lavorativi come lo “stand up meeting”, il “parking lot”, arrivando oggi all’uso di Framework per supportare l’Agile come lo “Scrum” che ha introdotto la figura dello “scrum master” e via di questo passo.
Ma quello che si è potuto vedere è che mentre prima i Team IT aziendali necessitavano di specifiche competenze , adesso posson bastare come capo progetto uno sviluppatore Senior con conoscenze da sistemista o un sistemista con conoscenze di programmazione per mandare avantiil 70% dei progetti perchè il resto lo prepara la piattaforma Cloud che ti aiuta a gestirlo con comodi tool grafici Plug ‘n Play e se qualcosa non funziona c’è il blog/tutorial o il call center…….. semplice giusto?

Certo qualcuno potrà giustamente dire che così è tutto più mirato, perchè no più comodo, e le aziende possono essere più verticali sullo sviluppo e sul risultato finale, FORSE, ma se devo cedere capacità cognitive, conoscenza dei sistemi e competenze di problem solving solo perchè è più pratico allora forse sto sbagliando mestiere. Non parliamo poi del nuovo arrivato, la A.I. , con ChatGPT e compagnia bella… quella unita ai movimenti No-Code, non fanno ben sperare per una futura esistenza delle ultime figure rimaste (gli sviluppatori) che credo si dovranno preparare a periodi di transizione poco rosei.

Il futuro non lo si può arrestare, arriva comunque dunque è giusto imparare a conoscerlo per capire come e quali cose sono vantaggiose da utilizzare, e che cosa invece determinerà la perdita di competenze apprese con fatica, studio ed esperienza lavorativa. Si potrebbe fare qualcosa per riprendere un minimo il controllo? Credo di SI, innanzitutto diminuendo la dipendenza dai sistemi Cloud esterni e tornando a volersi sporcare le mani in casa, quindi spazio alla rinascita dei data center aziendali costruiti su misura dei progetti reali ed implementati dalle persone che li gestiranno e li faranno crescere e scalare nel tempo, quindi riprendiamoci il controllo dei dati, in primis, e dei sistemi con loro, più sistemi on premise e Edge Computing e meno esternalizzazione con il Cloud Computing.

Vantaggi dell’ Edge Computing

L’edge computing è preferibile al cloud computing in molte situazioni e per diversi motivi chiave, tra cui sicurezza, controllo dei dati e velocità di elaborazione dei dati.

  1. Sicurezza: Nell’edge computing, i dati sono elaborati più vicino alla loro origine, riducendo il rischio di esposizione a minacce esterne. Questo approccio migliora la sicurezza dei dati sensibili.
  2. Controllo dei Dati: Con l’edge computing, le organizzazioni mantengono un maggiore controllo sui propri dati. I dati rimangono locali o in prossimità dei dispositivi, consentendo un controllo diretto sull’accesso e sulla gestione.
  3. Velocità nell’Elaborazione dei Dati: Poiché i dati vengono elaborati localmente nell’edge computing, la latenza è ridotta al minimo. Questo è fondamentale per applicazioni in tempo reale, come il monitoraggio industriale o i molti sistemi di monitoraggio delle città moderne (IoT), dove ogni millisecondo conta.
  4. Risparmio di Banda: Elaborare i dati in loco riduce la necessità di trasferire grandi quantità di dati in cloud, risparmiando banda e costi associati.
  5. Affidabilità: L’edge computing migliora l’affidabilità delle applicazioni. In caso di interruzione della connettività cloud, i dispositivi edge possono continuare a funzionare autonomamente.
  6. Scalabilità: L’edge computing è altamente scalabile. È possibile aggiungere dispositivi edge in modo modulare per gestire carichi di lavoro crescenti.
  7. Privacy: Per alcune applicazioni, come il monitoraggio della salute in tempo reale, la privacy dei dati è essenziale. L’edge computing mantiene i dati locali, riducendo le preoccupazioni sulla privacy.

In sintesi, l’edge computing è una soluzione vantaggiosa per applicazioni che richiedono velocità, sicurezza e controllo dei dati. Tuttavia, è importante notare che non esclude completamente il cloud computing, ma piuttosto lo integra in un modello ibrido per massimizzare i benefici.

Svantaggi dell’uso del Cloud Computing

  1. Aumento della Latenza: Nel Cloud, i dati devono viaggiare attraverso una rete molto estesa fino ai server remoti, causando ritardi (latenza) nell’elaborazione. Nel modello di Edge Computing, la distribuzione delle risorse di elaborazione avviene all’edge della rete, vicino ai dispositivi o ai sensori. Ciò elimina la necessità di trasmettere dati su lunghe distanze ai server remoti del Cloud, riducendo significativamente la latenza. Questa bassa latenza è essenziale per applicazioni in tempo reale come il controllo industriale, la guida autonoma e la realtà virtuale, migliorando notevolmente l’efficienza e la reattività dei sistemi.
  2. Dipendenza dalla Connessione Internet: Il Cloud richiede una connessione Internet costante, mentre l’Edge Computing funziona anche offline, garantendo continuità operativa.
  3. Controllo sull’Infrastruttura: Nel Cloud, hai meno controllo sull’infrastruttura sottostante, poiché è gestita dal provider. Con l’Edge Computing, hai maggiore controllo su hardware e sul software.
  4. Sicurezza e Privacy: Il Cloud può presentare rischi di sicurezza dovuti alla memorizzazione dei dati su server remoti. L’Edge Computing può offrire un maggiore controllo sulla sicurezza, poiché i dati rimangono locali.
  5. Costi Operativi: Il mantenimento di server remoti nel Cloud può comportare costi operativi elevati, mentre l’Edge Computing può essere più economico in particolare per piccole implementazioni locali.
  6. Complessità della Gestione: La gestione di ambienti Cloud complessi può richiedere competenze specializzate, mentre l’Edge Computing può essere più semplice da gestire localmente.

Certo tutto questo può essere solo un parere soggettivo determinato dalle mie personali esperienze lavorative, per altre persone potrà essere l’esatto contrario, rimango comunque dell’avviso che ciò di cui ho parlato descrive, in un paragone calzante, le stesse problematiche che il mondo sta affrontando per l’eccessiva deindustrializzazione dell’occidente che ha deciso decenni addietro di esternalizzare i processi produttivi sull’onda del concetto di “globalizzazione”, per il quale si è arrivati oggi ad essere dipendenti dei nostri fornitori (vedi la Cina solo per fare l’esempio più lampante) senza i quali non potremmo assemblare un PC o un telefonino, produrre abbastanza energia elettrica etc….

Alla fine un’azienda non è così diversa da uno Stato, lo Stato per essere definibile come tale deve avere un popolo che lo contraddistingue ed un territorio su cui esercita la sua sovranità; un’azienda necessità di proprio personale che apporta lavoro ed intelletto, che crea e genera idee da cui scaturiscono know-how e magari anche brevetti e deve essere la proprietaria di tutto ciò che produce e/o trasforma, altrimenti per entrambi i casi parliamo solo di “Colonie”.

MaxScale DB Proxy scalabile

 

MaxScale DB Proxy Server

MaxScale DB Proxy Server

Il suo nome per esteso e’ “MariaDB MaxScale” ed è il nuovo database proxy server open source sviluppato da MariaDB Corporation Ab.

In pratica  MaxScale ci permetta di avere database ad alte prestazioni, in grado di consentire la costruzione di architetture flessibili. Ecco nel dettaglio le sue caratteristiche e funzionalità principali.

 

Innanzitutto ricordiamo a tutti che, un proxy è un server che fa da intermediario in una connessione: riceve le richieste da un client e le reindirizza verso altri server che sono i destinatari delle richieste. In altre parole un proxy è un mezzo per deviare una connessione tra due computer in modo da non collegarli direttamente. Un proxy funziona, nella sua pratica, come un centralinista: riceve la chiamata da chi vuole telefonare e la gira all’interno desiderato.

MaxScale si può inserire in modo trasparente tra l’applicativo e il server MySQL, esattamente come fa un proxy web tra il nostro browser (es. Chrome) e il sito che stiamo cercando di visitare.

Grazie ad un proxy è possibile avere:

  • Ridondanza: usando più di un database dietro al proxy. Un solo server non fornisce l’affidabilità e l’alta disponibilità in caso di down di una macchina.
  • Diminuizione dei costi di infrastruttura: perché generalmente due server piccoli sono meno costosi che un unico server molto performante.

Vedremo ora due tipologie di database proxy server:

I proxy di livello trasporto come HAProxy
I proxy di livello applicativo come MaxScale

HAProxy: un proxy efficiente, rapido e funzionale

Fino ad oggi il proxy più usato in ambito MySQL è l’HAProxy che lavora ad un livello più basso (livello 4: trasporto). HAproxy non conosce nulla di MySQL e si occupa solo di bilanciare le connessioni tra più server. E’ molto veloce, leggero ed efficente, tuttavia questo bilanciamento è fatto senza conoscere cosa sta smistando. Questo rende il sistema meno efficente poiché un server può ricevere molte richieste pesanti, mentre altri server possono essere scarichi. Quindi l’HAProxy non è la scelta vincente in tutti i casi.

MaxScale: un proxy che può fare cose incredibili

MaxScale lavora a livello più alto (livello 7: applicativo), monitorando i server riesce a capire cosa sta succedendo all’interno dell’infrastruttura. Conoscendo il protocollo MySQL può intervenire manipolando il traffico tra client e server. Ecco alcune delle sue principali funzionalità:

  • Filtro delle query al database
  • Gestione del routing: instradamento delle richieste a uno o più database server
  • Modifica delle query al volo prima che raggiungano il database
  • Possibilità di nascondere la struttura interna dell’infrastruttura lasciando un singolo punto d’accesso.
  • Alta affidabilità e scalabilità del sistema
  • Possibilità di spostare un database dal server locale ad un server esterno senza modificare la configurazione delle applicazioni
  • Divide automaticamente le scritture sul server MasterR e le letture su uno o più database Slave.

MaxScale può fornire un Load Balacing delle connessioni senza bisogno di utilizzare applicazioni o CMS che prevedano questa funzionalità. Questo significa che CMS come WordPress o Joomla possono trarne dei benefici, usando una replicazione Master/Slave per rendere scalabile il proprio sito.

Caratteristiche di MaxScale

Il punto di forza di MaxScale è sicuramente la sua modularità che permette una notevole libertà adattandosi a molti casi d’uso, infatti MaxScale è:

  • Modulare: un sistema di moduli ne definisce le funzionalità
  • Estendibile: è possibile applicare più filtri anche in cascata
  • Flessibile: i moduli e i filtri possono essere aggiunti dinamicamente

I moduli base di MaxScale

Quelli elencati qui sotto sono i 5 moduli che costituiscono il cuore di MaxScale:

  • Protocol: da la possibilità di utilizzare più protocolli es. MySQL client, http, telnet
  • Authentication: il sistema di autenticazione permette ai client di accedere a MaxScale usando le credenziali presenti sui server di Backend
  • Monitor: legge la configurazione dello stato del sistema direttamente dai server di backend
  • Router: smista le connessioni a uno o più database di backend
  • Filter e logging: i filtri permettono di modificare le query oppure di scrivere un file di log con tutte le richieste e le risposte ricevute.

1. Protocollo di connessione
I client si connettono a MaxScale anziché al database MySQL senza accorgersi della differenza. Possono usare le stesse librerie di connessione utilizzate fino ad ora: es. MySQL client o MariaDB client.

2. Autenticazione
MaxScale non ha un sistema di autenticazione o un database di utenti. Vengono utilizzati gli stessi utenti presenti sui database di backend, caricati all’avvio dell’applicazione.

3. Monitor
Viene utilizzato per capire in ogni momento lo stato di tutti i database di backend collegati a MaxScale. In questo modo è possibile sapere qual’è il server Master e quanti Slave stanno replicando correttamentei dati.

4. Router
Dirige il traffico dal client ai server utilizzando una regola specifica:

  • Connection routing: normale router di connessione ad un database
  • Read/Write Split router: smista le richieste di scrittura sul Master e le richieste di lettura su uno degli Slave collegati

5. Filtri e log delle query
Tra i più potenti strumenti messi a disposizione di MaxScale ci sono sicuramente i filtri che permettono di effettuare operazioni avanzate sulle query senza modificare il comportamento dell’applicazione:

  • Processando query SQL e risultati
  • Utilizzando una semplice regex
  • Analizzando, modificando o rifiutando le query
  • Mettendo più filtri in cascata

Insomma, da questo primo articolo, si deduce che le potenzialita’ sono tutte a favore di MaxScale

 

#MaxscaledbproxyserverMysql

CoreOS ed uso nei Datacenter

CoreOS Docker Cluster

CoreOS Docker Cluster

Ormai l’ho capito, dai tanti esempi di storie di successo in campo informatico che, le migliori invenzioni si realizzano nei garage. Così come i due famosi Steve furono capaci di creare da zero il primo Mac, così i creatori di Google concepirono il loro motore di ricerca proprio in un garage o giu’ di li. La storia che si sente inizia sempre cosi :
“Qualche anno fa, in un garage della Silicon Valley…” etc… ; ma cosa ci sarà mai in questi garage americani ?!?


Nasce così CoreOS

CoreOS è praticamente una leggerissima distribuzione Linux solo con kernel e systemd. Questa distribuzione, che effettua il boot in un paio di secondi, è pensata per chi deve realizzare e gestire cluster di centinaia, addirittura migliaia, di nodi. Praticamente permette di realizzare, con hardware di proprietà, un’infrastruttura IT come quella di Amazon o Google. Oltre ad essere già disponibile sui sistemi cloud di Amazon, di Rackspace e di Google ultimamente anche Microsoft ne ha annunciato la disponibilità su Windows Azure.

Il prodotto è davvero interessanteinfatti, in poco tempo ha avuto migliaia di raccomandazioni su GitHub ed una cifra compresa tra uno e cinque milioni di dollari da gruppi di investimento privati.

CoreOS, il cui codice è interamente disponibile su GitHub, è fortemente basato sudocker“, etcd e systemd oltre ad avere un sistema di aggiornamento del sistema operativo sottostante molto innovativo chiamato FastPatch:

FastPatch aggiorna l’intero sistema operativo in un’unica soluzione, non i singoli pacchetti, su uno schema di partizioni attivo/passivo e siccome le applicazioni e le configurazioni risiedono in ambienti completamente separati e indipendenti, non si corre il rischio di lasciare alcuni nodi del cluster in uno stato di inconsistenza.

Quindi se la vostra esigenza è quella di creare un cluster, CoreOS rappresenta davvero un’ottima scelta.

Nel prossimo articolo vedremo come creare un cluster CoreOS con Vagrant .

 

#CoreOSsistemaclusteravanzato

Twemproxy il proxy per Memcached

twemproxy2

Twemproxy (repository GitHub) è un proxy server che consente di ridurre il numero di connessioni aperte verso un server Memcached o Redis. Per cosa può essere utile questo strumento?

 

 

Le caratteristiche principali sono :

– ridurre il numero di connessioni al cache server agendo come un proxy;

– sharding di dati automatico tra più cache server;

– supporto per l’hash con diverse strategie e funzioni di hashing;

– configurabile per disabilitare i nodi caduti;

– esecuzione di istanze multiple, consentendo al client di connettersi al primo proxy server disponibile;

– pipelining e batching di richieste con risparmio di round-trip;

– configurabile per disabilitare i nodi non più funzionanti, e richiamarli successivamente, dopo un po’ di tempo;

Twemproxy è stato reso open source da Twitter (che lo ha sviluppato per le proprie esigenze) all’inizio del 2012, con il supporto a memcached, e recentemente ha aggiunto anche il supporto a Redis. Twitter fa uso estensivo dei cache server ed il sistema sul quale gira Twemproxy, per Twitter, è di dimensioni impressionanti; immaginate che i sistemisti devono gestire centinaia di cache server, che a loro volta amministrano svariati TB di dati ciascuno per oltre trenta servizi diversi, in-memory, inclusa la memorizzazione dei tweet. Parliamo di almeno due milioni di miliardi di query al giorno, ossia più di ventitré milioni di query al secondo, per un’infrastruttura che, peraltro, continua a crescere in maniera esponenziale.

Leggi anche articolo (“Ottimizzazre grazie a Memcached“)