Il miracoloso NodeJS

piattaforma Open Source event-driven

NodeJS – una piattaforma Open Source event-driven

Ok, ammetto che fino a non molto tempo fa mi ero quasi scordato di Javascript, nonostante fosse stato uno dei primi linguaggi da me studiati, nel lontano 1997, quando mi approcciai al mondo del web; negli anni successivi pero’, non essendo io uno sviluppatore, le tecnologie di gestione e deploy dei server web che dovevo gestire si erano spostate verso un grande quantitativo di linguaggi, in particolare per la parte back-end , passando cosi dal php, perl, python, java, ruby, lua etc……

Come stavo dicendo, per me javascript era rimasto in sordina come un linguaggio di scripting che intercorreva tra l’hmtl ed il css, nella composizione piu’ o meno dinamica di una pagina web ,prima che i pesi massimi sopra citati entrassero in campo per svolgere il duro lavoro.

Poi, un giorno, a ciel sereno……BOOOOOOOMMMM ! scopro l’esistenza di NodeJS, ed iniziai a chiedermi a cosa si dovesse tutto l’interesse di cui stavo leggendo; scopro quindi che NodeJS e’ una piattaforma Open Source event-driven per l’esecuzione di codice JavaScript Server-side, costruita sul motore V8 di Google Chrome. Mmmmhhhh, ok bene, ma quindi? cosa fa?

Ebbene questa piccola rivoluzione creata da Google consente agli sviluppatori di realizzare web application con JavaScript non più solo lato client, ma anche sfruttandolo come linguaggio di programmazione lato server.

E gli sviluppi sono davvero moltissimi, cosi tanti che mettere un’elenco sarebbe noioso e stancante ma, tanto per farne uno molto odierno, con NodeJS possiamo, ad esempio, realizzare dei ChatBot.

Ma qual’e’ dunque il funzionamento che lo rende cosi appetitoso? Innanzitutto partiamo dal dire che Node funziona con una logica a eventi: quando un evento viene generato, allora viene eseguita un’azione. Grazie a questa tecnica non bisogna attendere che le istruzioni precedenti siano terminate, rendendo cosi il tutto molto veloce.

Nella pratica, non c’e’ bisogno di sapere come funziona il V8 per poter utilizzare NodeJS, basti sapere che e’ l’interprete javascript piu’ veloce al mondo, poiche’ e’ stato altamente ottimizzato utilizzando un tipo di programmazione JIT (Just In Time), che trasforma rapidamente il codice javascript in linguaggio macchina.

Ma la cosa che, almeno a parere personale, mi ha maggiormente colpito, e’ stato quello che possiamo chiamare come “Modello non bloccante” , questo si basa sul concetto degli eventi, ma per meglio chiarire dovremmo spiegare un minimo la differenza tra modello bloccante e NON bloccante.

Immaginiamo di dover creare un programma che ci permetta di scaricare un file da internet e che alla fine dell’esecuzione del download ci mostri un messaggio.

Bene, con il modello classico (bloccante) basato sulla programmazione sincrona potremmo schematizzare il processo nel seguente modo:

  • Scarica il file
  • Mostra il messaggio
  • Fai qualcos’altro

Ci aspetteremmo quindi che le azione vengano eseguite in ordine, leggendo le operazioni da eseguire dall’alto verso il basso.

Nel sistema asincrono di NodeJS invece le operazioni verranno svolte nel seguente modo:

  • Scarica file
  • Fai qualcos’altro
  • Mostra il messaggio

Perche’ questa diversita’ nell’esecuzione rende il tutto piu’ veloce e performante? Beh perche’ mentre il sistema effettua il download del file, il programma non rimane in attesa che il processo venga portato a termine ma anzi nell’attesa il programma esegue altre operazioni.

Il codice in oggetto avra’un aspetto tipo questo:

request(‘http://www.site.com/file.zip’, function (error, response, body) {
console.log(“Download completato!”);
});

console.log(“Mentre aspetto eseguo il resto del codice…”);

Quello appena descritto qui sopra e’ un’esempio di procedura di callback 

Ok ma se non fosse ancora del tutto chiaro, proviamo ancora a spiegare perche’ le callback sono cosi importanti, procediamo con l’esempio di prima ed aggiungiamo una difficolta’; adesso i file da scaricare sono diventati due, dunque nel sistema sincrono il programma procederebbe nel seguente modo:

  • Scarico primo file
  • Attendo che finisca
  • Scarico secondo file
  • Attendo che finisca
  • Mando messaggio

La grande differenza in questo esempio sarebbe che con NodeJS verrebbero lanciati entrambi i download, nello stesso momento, permettendo gia cosi un piu’ veloce download e, nel frattempo il programma e’ in grado di svolgere eventuali altri compiti. Ma questo come dicevo e’ soltanto un esempio, invece di un download multiplo, potrebbero essere delle query ad un DB, o la richiesta di dati a servizi esterni tramite API (Facebook, Twitter).

Pensiamo quindi ad un sistema come Facebook, che riceve X richieste di Like ogni tot secondi e vengono cosi aperti N operatori che devono attendere il loro turno per fare la modifica (del like) consumando comunque energie anche mentre sono fermi in attesa; invece NodeJS nella stessa situazione di richiesta di “reaction” sul sisto di FB (like o altro) si comporterebbe nel seguente modo:

metterebbe tutte le richieste in ordine di arrivo, prenderebbe la prima e, vedendo che si tratta di una sfilza di input le inserirebbe all’interno del sistema e, una volta capito che si tratta di stesse azioni (ad esempio che aggiungono un Like) che devono contattare un DB, NodeJS contatta il DB e invece di attendere per effettuare ogni singola modifica, aggancia alla richiesta una callback, per ogni richiesta di modifica, tutti uno dietro l’altro. Quando il DB finisce la prima modifica scatta la callback e NodeJS restituisce all’utente l’avvenuta modifica della pagina e cosi via, gestendo quindi con un solo operatore le N richieste di modifica del Like invece di crearne uno per ogni richiesta e parcheggiandoli tutti in attesa della loro singola modifica. Quindi con un server (magari anche un container con Docker) e con poche risorse possiamo gestire un’enorme quantita’ di richieste al secondo.

Inoltre NodeJS usa come sistema di pacchetti e librerie l’NPM, ma di questo fantastico sistema di librerie parleremo in un’altro articolo.

Nel prossimo articolo su NodeJS parleremo anche di 5 nuovi framework ottimi per chi si occupa di sviluppare.

#NodeJS

 

in-memory computing grandi moli di dati direttamente nella memoria

In-Memory Computing Database

In-Memory Computing Database

La quantità di dati prodotti e gestiti giornalmente in ogni parte del mondo ha raggiunto dimensioni inimmaginabili rispetto anche solo a cinque anni fa. Internet of Things, Digital Technology, Mobility sono solo alcune delle ultime evoluzioni tecnologiche che hanno impresso a questo fenomeno un’accelerazione esponenziale. Un trend, visibile in tutti i settori dell’economia e in ogni parte del mondo.
La complessità degli attuali scenari competitivi obbliga le aziende al continuo riallineamento dell’offerta sulla base dei cambiamenti repentini della domanda. Big Data e Internet of Things restituiscono un ricco bacino informativo da cui sviluppare nuove opportunità di business, ma generano al contempo nuove sfide di governance.

L’in-memory computing è la chiave di volta per rispondere proattivamente all’effervescenza del mercato, perché permette di elaborare grandi moli di dati direttamente nella memoria centrale del sistema, restituendo le informazioni pertinenti con maggiore rapidità.
Il ricorso a piattaforme di “in-memory” via cloud permette di dotarsi di un’infrastruttura prestazionale e scalabile per il data management, con vantaggi di affidabilità, agilità e performance, a supporto di applicazioni analitiche e mission-critical.

In altre parole, l’in-memory computing elimina la necessità di eseguire operazioni di ricerca e recupero delle informazioni su disco ogni volta che viene eseguita un’elaborazione, rendendo trascurabile la latenza di accesso ai dati. Questo nuovo modello tecnologico porta ad un forte miglioramento delle performance di sistema e contiene in sé il potenziale per un’innovazione epocale delle attività di elaborazione elettronica, insomma una nuova era, caratterizzata da un più rapido ed efficiente accesso ai dati.
Due fattori principali stanno contribuendo alla forte espansione dell’ in-memory computing:

Processori a 64 bit
Con il rilascio del processore a 64 bit, avviene una vera e propria rivoluzione nelle capacità di
memoria potenzialmente utilizzabili.

Continua diminuzione del prezzo della RAM
Negli ultimi 30 anni i prezzi della RAM sono diminuiti di oltre 500.000 volte:

Nel frattempo i retailers, alla costante ricerca di strumenti di analisi dei dati per assumere decisioni tempestive in maniera rapida e confidente, hanno un potenziale enorme, a oggi ancora inespresso, nei dati immagazzinati nei propri sistemi, siano essi transazionali o memorizzati in data-warehouse, siano essi prodotti e gestiti dall’azienda o provenienti dalle interconnessioni con il proprio eco-sistema composto da clienti, fornitori, partner commerciali etc… Questa impressionante mole d’informazioni è un patrimonio fondamentale che può essere reso disponibile per prendere decisioni immediate, in modalità real-time ad ogni livello della propria catena decisionale.

Al pari di un comune database, il motore di In-Memory Computing supporta gli standard di settore, come SQL e MDX, ma include anche un motore per il calcolo ad alte prestazioni che integra il supporto del linguaggio procedurale direttamente nel kernel del database. Tale approccio elimina l’esigenza di leggere i dati dal database, elaborarli e quindi riscriverli nuovamente nel database.

Il motore di In-Memory Computing propone quindi significative innovazioni tecniche come l’utilizzo del nucleo della CPU e la massiccia elaborazione parallela. In particolare la velocità, la scalabilità e la capacità di compressione dei dati sono i suoi veri punti di forza tecnici.

Tra le prime aziende a credere ed investire in questa tecnologia e’ stata SAP che ha creato una propria soluzione HANA, una nuova tecnologia destinata a cambiare il mercato, in particolare della Business Intelligence.

Hana e’ una nuova soluzione ibrida basata sulla tecnologia di in-memory computing, che sarà installata su diversi server e apparati di Dell, Hp, Ibm e Fujitsu. Coinvolte nel progetto anche Cisco e Intel. Si chiama Hana (acronimo di High Performance Analytic Appliance) ed è una soluzione che comprende la prima appliance analitica basata sulla tecnologia ‘in-memory computing’.

HANA è una combinazione di software e hardware sulla quale possono girare applicazioni sviluppate appositamente ma che può anche essere accostata a tradizionali sistemi ERP e di business intelligence.

Le regole del gioco cambiano quindi con il software in-memory di SAP HANA:

Perché attendere analisi effettuate su dati già obsoleti? Perché accettare elaborazioni di transazioni, esecuzione dei processi e ricerca di informazioni troppo lenti?
Affidati alla piattaforma SAP HANA per attingere a volumi elevati di informazioni dettagliate e aggiornate al verificarsi degli eventi.

Perché scegliere SAP HANA?

  • Velocità: gestire volumi di dati massivi in secondi, non in ore
  • Agilità: decisioni real-time supportate da informazioni real-time
  • Ordine: ottenere informazioni da ogni dato, strutturato o non strutturato
  • Penetrazione dei dati: indagare, e ottenere risposte, immediatamente
  • Potenza: eseguire nuove applicazioni che sfruttano le potenzialità delle informazioni
  • Cloud: un modello cloud-based sicuro, scalabile e robusto
  • Innovazione: utilizzare la conoscenza per guidare il cambiamento, velocemente come mai prima
  • Semplicità: ridurre costi e complessità per ogni volume o tipo di dato
  • Valore: ottimizzare il business per creare nuove offerte e aumentare i margini di profitto
  • Scelta: utilizzare l’hardware e il software che si preferiscono

Tutto ciò significa che attraverso HANA, le applicazioni possono delegare le operazioni direttamente alla memoria invece che ai dischi. L’informazione viene così conservata e analizzata in HANA, invece che immagazzinata in tabelle statiche all’interno di database tradizionali.

IN-MEMORY COMPUTING, la tecnologia c’e’ e vale la pena provarla.

OSSEC host-based intrusion detection system

host-based intrusion detection system

OSSEC host-based intrusion detection system

Spesso, da sisteimsti, capita di dover tenere sotto controllo un grande numero di sistemi e di dover analizzare i log con una certa costanza per problemi di sicurezza. Ma amministrare molti sistemi e collegarcisi quotidianamente è un’operazione dispendiosa e anche noiosa.

Il problema può essere affrontato con l’aiuto di analizzatori di log, come ad esempio il noto Logwatch oppure con software di integrity checker come AIDE, oppure con rootkit control come Rkhunter. Ci sono molti di questi strumenti, ma la loro funzione è molto specifica, ed alla fine ci occorre installare diversi software per poter ottenere un controllo completo.

OSSEC è un “host-based intrusion detection system” (HIDS) opensource, ed e’ in grado di monitorare il funzionamento di un sistema “dal suo interno” anziché ricorrere all’uso delle interfacce di rete, come fanno invece i network-based intrusion detection system. Ossec e’ un sistema scalabile che possiede un potente motore di analisi e correlazione che può effettuare analisi dei log, file integrity checking, Windows registry monitoring (per scovare intrusioni non autorizzate), rootkit detection, real-time alerting e active response; inoltre Ossec è multipiattaforma e supporta la maggior parte dei sistemi operativi, come Linux, OpenBSD, MacOS, Solaris e Windows.

I software HIDS , si occupano di sorvegliare costantemente il comportamento del sistema oggetto d’esame e lo stato in cui sta operando. Mentre i NIDS ispezionano il contentuto di ogni singolo pacchetto dati in transito, un HIDS, qual è OSSEC, può stabilire a quali risorse tentano di accedere i programmi installati bloccando tempestivamente operazioni sospette. Per esempio, un word-processor non deve poter modificare le password di sistema o la configurazione di aree vitali, se lo fa significa che, con buona probabilità, sta eseguendo del codice maligno, collegato all’azione di un malware.
Un HIDS quindi controlla lo stato del sistema verificando le informazioni memorizzate, sia in RAM che sul file system, i file di log e così via, poiche’ l’obiettivo è quello di rilevare tempestivamente le anomalie.

In particolare, OSSEC si incarica di analizzare i log di sistema, verificare l’integrita dei file memorizzati su disco, controllare la presenza di rootkit e tenere traccia delle performance di ogni macchina collegata alla rete locale nella quale e installato.

CARATTERISTICHE:
Architettura: Ossec è costituito da più di un dispositivo, possiede un Manager centrale che monitorizza tutto e riceve informazioni da agents (sensori), syslog e databases.

  • Manager: Il manager è la parte centrale di Ossec e contiene i databases dei file integrity checking , dei logs e degli eventi. Contiene anche tutte le regole, i decoder e le configurazioni cosi da
    rendere più facile l’amministrazione di agents multipli.
  • Agent: L’agent è un piccolo programma installato nei sistemi che si desidera monitorare. Esso raccoglie informazioni e le spedisce al Manager per l’analisi. Sono progettati per utilizzare veramente poche risorse quindi non influenzano le prestazioni del sistema.
  • Agentless: Per i sistemi in cui non si possono installare agents, Ossec permette operazioni di file integrity monitoring . Alcuni esempi possono essere firewalls, routers o anche particolari sistemi Unix.
  • Sicurezza: Ossec offre svariate funzionalità nell’ambito della sicurezza:
    • Analisi dei log e correlazioni:
    • Regole flessibili basate su XML
    • Time Based Alerting
    • Libreria contenente molte regole già integrata
    • Integrity Checking
    • Root Kit detection
    • Active Response: Ossec permette di intervenire immediatamente sulla minaccia con vari metodi:
    • Disabilitare il servizio per un determinato intervallo di tempo (espresso in minuti)
    • Blacklists
    • Firewall-Drop: uno script che permette di comunicare universalmente con i firewall delle più comuni distribuzioni Unix/Linux Firewalls, Switch e Routers: Ossec può ricevere ed analizzare eventi di Syslog da una grande varietà di firewalls, switch e routers che supportano
      questa tecnologia.
  • Scansione dei processi nascosti: grazie all’utilizzo delle funzioni getsid() e kill() sicontrolla se esistono pid utilizzati. In caso positivo, se il comando permostrare i processi attivi (ps in Linux, tasklist in Windows) non `e in grado di rilevarli, significa che nel sistema `e presente un rootkit a livello kernel;
  • Scansione delle porte segrete: con la funzione bind() si controlla ogni porta TCP e UDP del sistema. Se il binding relativo a una porta fallisce (il che significa che tale porta `e attualmente utilizzata), ma netstat, il comando che permette di visualizzare le connessioni attive del computer, non `e in grado di rilevarla, `e probabile la presenza di un rootkit all’interno del sistema
  • Scansione delle interfacce di rete: se una o pi`u interfacce sono in modalit`a promiscua, e il comando ifconfig non lo evidenzia, `e probabile che un rootkit stia nascondendo la presenza di uno o pi`u dispositivi che intercettano tutti i pacchetti di rete

Un’altra interessante estensione del software permette di realizzare la disabilitazione distribuita delle memorie USB, per impedire ai dipendenti di appropriarsi in modo illecito dei contenuti del patrimonio informativo aziendale.


Funzionalita’
OSSEC ha un motore di analisi dei log in grado di correlare e analizzare i log da più dispositivi e formati. I seguenti sono quelli attualmente supportati:

  • Sistemi Unix:
    • Unix PAM
    • sshd
    • Telnetd Solaris
    • Samba
    • Su
    • Sudo
  • Server FTP:
    • ProFTPd
    • Pure FTPd
    • vsftpd
    • Microsoft FTP Server
    • Ftpd Solaris
  • I server di posta:
    • Imapd e pop3d
    • Postfix
    • Sendmail
    • Vpopmail
    • Microsoft Exchange Server
  • Basi di dati:
    • PostgreSQL
    • MySQL
  • Server Web:
    • Apache Server
    • Web server IIS
    • Log Zeus errori del server Web
  • Applicazioni Web:
    • Horde IMP
    • SquirrelMail
    • ModSecurity
  • Firewall:
    • Iptables firewall
    • Solaris IPFilter firewall
    • AIX IPsec/firewall
    • Netscreen firewall
    • Windows Firewall
    • Cisco PIX
    • Cisco FWSM
    • Cisco ASA
  • NIDS:
    • Modulo Cisco IOS IDS/IPS
    • Snort IDS
  • I tool di sicurezza:
    • Symantec AntiVirus
    • Nmap
    • Arpwatch
    • Cisco VPN Concentrator
  • Altri:
    • Detto
    • Proxy Squid
    • Zeus Traffic Manager eXtensible

 

INSTALLAZIONE
Partiamo installando i pre-requisiti di base con il seguente comando :

sudo apt-get install build-essential apache2 libapache2-mod-php5 apache2-utils

Adesso passiamo ad effettuare il download dei pacchetti che ci servono direttamente dal sito del produttore  DOWNLOAD

Server/Agent 2.8 – Linux/BSD  : ossec-hids-2.8.tar.gz
Web UI 0.8 : ossec-wui-0.8.tar.gz

tar xfz ossec-hids-2.8.tar.gz
cd ossec-hids-2.8/
sudo ./install.sh

Start OSSEC HIDS:

sudo /var/ossec/bin/ossec-control start

Installiamo OSSEC Web UI

tar xfz ossec-wui-0.8.tar.gz
sudo mv ossec-wui-0.8 /var/www/html/osssec-wui/
cd /var/www/html/osssec-wui/
sudo ./setup.sh

Restart apache:

sudo apache2ctl restart

Adesso apriamo il browser e facciamolo puntare all’url :  http://localhost/osssec-wui/

Una volta entrati con le credenziali impostate durante l’installazione non rimane che fare pratica delle configurazioni.
Nel prossimo articolo vedremo come affiancare ad Ossec un ottimo tool per la getione dei Log come l’ottimo Splunk.

Splunk è un tool che può essere integrato in OSSEC per trasformare i log in formato grafico con integrati alcuni report che permettono di controllare più facilmente i sistemi monitorati.

#OssecHIDS

Couchbase = CouchDB + Membase

Couchbase NoSQL

Couchbase NoSQL

Scopriamo perche’ grandi aziende come Ebay,PayPal, LinkedIn, Viber hanno scelto Couchbase.
Stupiscono le sue incredibili performance e di quanto sia piu’ veloce di MongoDB e Cassandra .

Innanzitutto
Il mondo informatico e’ come non mai in continuo fermento ed evoluzione, questi continui cambiamenti a volte sono difficili da seguire ma, spesso portano novita’ interessanti come Couchbase NoSQL. Ma di cosa si tratta ??
Nel variegato mondo dei database NoSQL da qualche tempo c’è una novità: CouchDB e Membase, insieme alle relative società, si sono unite, dando luogo a un unico prodotto e una sola azienda, entrambi chiamati Couchbase.

#Couchbase = CouchDB + Membase
Quest’ultimo unisce le caratteristiche salienti dei predecessori da cui trae origine, ereditando lo storage ad oggetti su disco di CouchDB e le capacità di caching in memoria di Membase.
Interessante e’ anche la possibilità di utilizzare la stessa tecnologia anche su piattaforme mobili, ottenendo con il minimo sforzo la sincronizzazione dei dati fra il dispositivo mobile e il data center grazie alla tecnologia di sincronizzazione dei dati tipica di CouchDB.

In questo primo articolo vedremo i passi necessari per l’installazione di CouchBase su piattaforma Linux-Ubuntu .

PS: l’installazione di un sistema di questo tipi non e’ per PC casalignhi infatti le richieste minime sono nell’ordine di:
Minimum number of processors required : 4 cores
Minimum RAM required  : 4 GB

Innanzitutto, occorre scaricare la versione piu’ appropriata al vostro sistema operativo, a questo link. Io ho scelto la “couchbase-server-enterprise_3.0.2-ubuntu12.04_amd64.deb”
Quindi lanciare il seguente comando :

# sudo dpkg -i couchbase-server-enterprise_3.0.2-ubuntu12.04_amd64.deb

ed al termine dell’installazione, verificare che tutto e’ andato correttamente, digitando nel browser, questo link

http://127.0.0.1:8091/

e seguite la procedura di Setup……, una volta ultimata il primo login come Amministratori sara’ automatico e vi ritroverete direttamente all’interno della console di gestione del DB. Complimenti  il primo step e’ stato ultimato con successo.

Se durante l’installazione non avete cambiato nulla avrete notato che i file di gestione/configurazione del DB sono stati salvati in /opt/couchbase/………/ – Per fare lo shutdown e lo startup, digitare questi comandi

# sudo /etc/init.d/couchbase-server start
# sudo /etc/init.d/couchbase-server stop

Per ogni ulteriore dettaglio nella configurazione per ora vi rimando alla documentazione ufficiale che potete trovare a questo LINK .

Per il momento e’ tutto, spero che queste poche righe abbiano destato l’interesse verso una soluzione DB ad alte prestazioni interessante qual’e’ CouchBase.
Bis Bald, a presto!

Ottimizzare grazie a Memcached

theflash_memcachedOttimizzazione server dedicato grazie a MemCached

Spesso si e’ portati a credere che i meccanismi di cache siano una specie di Panacea, e che dalla loro implementazione non si debba temere alcun  problema : ovviamente non è così.
Specialmente se il tuo cloud è dedicato all’erogazione di siti/portali web con volumi importanti l’utilizzo di memcached può sicuramente aumentare le performance di quest’ultimo;  ma può anche introdurre un nuovo point of failure, uno di quelli che non ti aspetti.
Facciamo un esempio, non ti aspetteresti che un’istanza memcached possa rappresentare un collo di bottiglia !, men che meno un pool di istanze bilanciate e, cosa forse ancor più singolare, che lo possano rappresentare a livello di networking. Eppure succede!

Cos’è memcached, e come funziona?
Memcached è un sistema di caching distribuito ed ha una struttura client/server che permette di servire i dati più richiesti direttamente dalla RAM, riducendo cosi al tempo stesso il carico sul database.
Questo può essere di grande aiuto se si ha la necessità di gestire una quantità di dati davvero importante.
Sfruttare elaborazioni già effettuate: questo è il punto di forza di Memcached; infatti raggruppando la cache dei nodi crea una memoria a breve termine che serve per ottimizzare le operazioni ripetute.

Memcached è semplice ma potente. Il suo design semplice promuove un’implementazione veloce, facilità di sviluppo, e risolve molti dei problemi che ci si trova ad affrontare quando si ha a che fare con grandi cache di dati.

Il server funziona ricevendo una serie di coppie chiave-valore e mantenendole in RAM.
In genere è compito della logica applicativa (quindi della programmazione degli scripts php, ruby, phyton ecc…) decidere se effettuare un’operazione di scrittura su memcached oppure di lettura, ed e’sempre compito dell’applicazione computare un hash delle key che invia a memcached e, successivamente, inviare la coppia chiave-valore al server stesso.
Nel caso di un cluster, l’applicazione deve determinare in base all’hash quale nodo memcached contiene quale valore.

Ora, può succedere che alcune coppie chiavi-valore siano molto più utilizzate di altre, queste si definiscono in gergo “hot keys”.
Può succedere inoltre, nel caso che il sito sia molto trafficato, che i front-end web interroghino con preferenza alcune coppie chiave-valore specifiche.
Facciamo un’altro esempio: immaginiamo di dover gestire la home page di un quotidiano nazionale (a me e’ capitato).
Immaginiamo che il codice che muove quel sito interroghi memcached per evitare che, ad ogni richiesta della home page, vengano fatte delle richieste al database.
Immaginiamo infine che la home page del tuo portale riceva un grosso picco di traffico completamente inatteso (per esempio un terremoto).
Man mano che il traffico aumenta, aumentano le richieste che i front-end devono effettuare al back-end memcached per evitare di interrogare continuamente i database.
Per servire un sito di questo tipo, si sono probabilmente predisposti una mezza dozzina di front-end applicativi, o forse di più, e ciascuno di questi chiama il back-end memcache.
Man mano che il traffico da servire lato pubblico scala verso le decine di Mbit/s, il traffico verso il backend memcached aumenta con un moltiplicatore pari al numero di front-end e questo comincia a saturare la scheda di rete del memcached.
Il traffico aumenta fintanto che la scheda di rete si satura, il sistema crolla, con buona pace di ottimizzazioni lato front-end, bilanciatori di carico, e ottimizzazioni lato SQL.

Se avessimo configurato un cluster memcached alle spalle dei front-end il problema potrebbe comunque presentarsi perchè alcuni nodi del cluster potrebbero avere delle “hot-keys” un po più “hot” delle chiavi degli altri nodi.

Ora, potrebbe anche essere che i memcached contengano solo piccole porzioni di dato e quindi il traffico sulla NIC sia molto contenuto, ma se non siete stati voi ad aver scritto l’applicazione, non potrete esserne certi, quindi si dovra’ quantomeno monitorare la saturazione della NIC e l’eventuale presenza di differenti hot keys sui server.

Come uscirne fuori?
Se la situazione non si è ancora deteriorata del tutto, potreste effettuare l’analisi del traffico in uscita dalla NIC con un packet sniffer e cercare di capire quale sia la chiave “incriminata” e i dati ad essa associati.
Ma c’e’ da dire che state facendo passare qualche centinaio di Mbit/s su una NIC, un’attività del genere non deve essere una passeggiata anche solo per la mole di dati che si deve processare.
In alternativa, può venirci in aiuto uno strumento come mctop, che permette di tracciare il numero di chiamate, richieste al secondo, e l’uso della banda per ogni singolo pacchetto.
In questo modo, sara’ molto più facile individuare le key che tendono a saturare la banda ed indicare dove ai programmatori o tecnici dove devono intervenire.

Non è solo un problema lato server.
Come si puo’ immaginare, questo tipo di problemi va affrontato sia lato sistemi che lato sviluppo
In una situazione di emergenza identificare una “hot key” manualmente, potra’ anche andare bene, ma il punto è che dal lato sviluppo applicativo dovranno mettere mano al codice ed essere in grado di effettuare, per quanto possibile, questo tipo di operazione in autonomia migliorando le fasi di test e di pre produzione.
Diventa cosi’ davvero opportuno avere nella propria infrastruttura, dei sistemi di monitoraggio e di alert, che possano segnalare per tempo gli status ed i possibili rischi di saturazione lato NIC.