Devo ammettere che è stata un’esperienza interessante, sia dal punto di vista del dimensionamento dell’infrastruttura che dal punto di vista della migrazione.

Se è vero che, quando lo avremo portato completamente a regime, il portale potrà servire qualche centinaio di migliaia di pagine al giorno, è anche vero che la situazione iniziale che ho trovato era tutt’altro che rosea.

Provate ad immaginare un portale che viene aggiornato qualche decina di volte al giorno e che, quando giocano i Lupi, viene aggiornato ancor di più.

Immaginate inoltre un server fisico assolutamente “al tappo” alla vigilia di un week-end lungo, con due partite in programma e con una migrazione da fare in tempi che farebbero invidia a Bolt.

Queste le premesse della sfida.

Partiamo dal dimensionamento dell’infrastruttura: mi ritrovo per le mani un framework Joomla, che di sua natura è piuttosto pesante ma che per fortuna è stato dotato di una buona cache dai precedenti sviluppatori.

Purtroppo il server fisico su cui ForzaRoma è ospitato è così carico che non è facile stimare il numero di visitatori potenziali a regime. Ci incontriamo con lo staff del portale, facciamo due conteggi veloci su peso della pagina e del codice, stimiamo che ad ogni istante sul portale ci siano sempre alcune decine di lettori e buttiamo giù un’idea d’infrastruttura.

Per poter reggere a questo tipo di traffico, un cloud dedicato deve essere basato su server con un comparto I/O dalle performance generose: dischi veloci, controller con molta cache, doppio processore. Poi si passa alla RAM: ce ne deve essere abbastanza da poter effettuare caching pesante delle pagine da servire, altrimenti processori e dischi non possono reggere.

Dopo aver scelto la macchina giusta, ho preparato il cloud dedicato con un paio di livelli di cache a livello di sistema operativo.

Hai mai sentito parlare di cache lato sistema operativo? In pratica si tratta di utilizzare configurare il sistema in modo da effettuare il reverse proxy e mantenere i dati temporanei in RAM.. In questo modo, gli accessi al database, e quindi al disco, smettono di essere (entro un certo limite) un collo di bottiglia.

Una volta che l’infrastruttura è stata migrata, sono bastati un paio di giorni per fare il fine-tuning della cache e adesso ForzaRoma.info viaggia a dovere.

Se hai bisogno di un partner competente che sappia ospitare la tua infrastruttura web ed accompagnarti nella sua crescita, non esitare a contattarmi attraverso questo form.

Apparentemente, in alcune condizioni ben specifiche, sarebbe possibile leggere i dati lasciati sul disco da altri utenti del cloud pubblico dopo che questi hanno dato disdetta.

Cosa ancora più sconcertante, accedere a questi dati sarebbe tanto semplice quanto lanciare un comando come “dd if=/dev/sda1 bs=1M skip=5000 | strings”: se chiedi al tuo sistemista ti confermerà che questi comandi sono alla portata tecnica di chiunque.

Paura eh?

Ad onor del vero, per generare questo tipo di problema sono necessarie una serie di condizioni specifiche che non si verificano sempre:

1. Il problema è legato a piattaforme tecnologiche già un po datate e – sembrerebbe – non alla nuova tecnologia openstack che Rackspace ha contribuito a fondare e che sarebbe molto più sicuro.

2. Il problema è dovuto ad una mancata pulizia dei dischi che vengono allocati alle nuove istanze virtuali, o meglio, quando viene creato un nuovo volume virtuale solo la parte relativa al sistema operativo viene sovrascritta dai nuovi dati, i bit che rappresentano altre porzioni del nuovo disco *non* vengono resettati.

3. Il problema si presenta solo quando le VM vengono create usando una interfaccia web, apparentemente se creassi una VM utilizzando le API la pulizia verrebbe fatta senza problemi.

Tuttavia una volta che la VM viene creata senza l’opportuna pulizia disco, tutti i vecchi dati non criptati potrebbero risultare leggibili, questo include password, dati degli utenti, numeri di carte di credito….

Apparentemente, il problema è stato identificato da una società che si occupa di security assessment e risolto prima di essere annunciato al pubblico. Molto bene! Mi sento in dovere, tuttavia, di fare alcune considerazioni.

I cloud condivisi sono *solo relativamente* affidabili.
Infatti la sicurezza di queste strutture dipende da come l’hosting provider opera, da quanto questi riutilizzi le porzioni più vecchie dell’infrastruttura per fare margine, da quanto gli utenti sono consapevoli dei problemi di sicurezza di un’infrastruttura in cloud shared, problemi sicurezza che come visto vanno ben oltre la disdetta del servizio

I cloud condivisi non offrono controllo sul layer fisico e sul layer di virtualizzazione.
Ovvero, ti consentono a volte di risparmiare al prezzo della perdita del controllo di ciò che veramente fa l’infrastruttura hardware e software al di sotto del tuo layer di virtualizzazione.

Se ospiti dati preziosi e/o sensibili i cloud pubblici potrebbero non essere così economici quanto appaiono, perchè l’eventuale perdita dei tuoi dati sensibili (anche diverso tempo dopo la disdetta del servizio) potrebbe avere danni economici e di immagine incalcolabili.

Certo, se devi limitarti all’hosting di un blog (benchè non ad alta volumetria) per ricavarne pubblicità ad-sense allora il cloud shared è ancora una soluzione viabile.

E la posizione di Level iP?
Beh, per me il problema non si pone. Io faccio cloud dedicato e a ciascun cliente corrisponde una o più macchine fisiche, sue e di nessun’altro… forse sarò un pelino meno economico, ma almeno la notte non ho gli incubi!

Ho scritto abbastanza, è ora di tornare al lavoro! Se tuttavia ti piace quello che scrivo e vuoi entrare in contatto con me, oppure se hai bisogno di un partner competente per le tue esigenze di cloud dedicato, non esitare a contattarmi attraverso questo form.

—–
Credits: Dirty Disks Raise New Questions About Cloud Security

Evidentemente, ad un certo punto, si sono accorti che l’overbooking di risorse fa parte della lista di ciò che il cliente non vuole e hanno pensato bene di specificarlo eppure, mio caro lettore, l’overbooking fa parte della natura dei sistemi condivisi ed è qualcosa che qualsiasi provider farà sempre.

In pratica, finchè il ricavo marginale della vendita di una unità cloud in overbooking sarà superiore al costo marginale necessario a produrla, ovvero finchè non si perdono più clienti di quanti se ne guadagnano. Brillante!

Al di là dell’umana avarizia, ti starai chiedendo perchè all’interno di un cloud si faccia overbooking. Dopotutto, l’idea che ti sarai fatto del “cloud” è che questo contenga una quantità di risorse molto elevate, sempre in aumento… elastiche!

L’idea che ti sei fatto è – probabilmente – vera solo nel caso di cloud estremamente grandi: Amazon, Google, Heroku ne sono alcuni esempi.

A livello italiano, tuttavia, la situazione è ben diversa, le risorse esistono in una quantità finita e non elevatissima. Inoltre è la struttura stessa dei cloud più piccoli ad essere soggetta a limiti che fanno dell’overbooking una normalità.

Per capire perchè l’overbooking sia inevitabile, bisogna capire come funzionano i mini-cloud nazionali.

Un ambiente cloud altro non è che una collezione di server fisici collegati a una oppure a più di una SAN. I server fisici sono quelli che ti aspetteresti comprando un qualunque server dedicato, magari hanno più RAM e un processore multi-thread un po più spinto ma le differenze finiscono qui.

La SAN è un normale array di dischi. A seconda di quanto il provider vuole (e può) spendere la SAN sarà più o meno piena e conterrà dischi più capienti oppure più veloci. Per farti un’idea di come un cloud è organizzato dai uno sguardo alla rappresentazione – molto semplificata – che ho allegato sopra.

Se il mini-cloud è fatto per bene, avrà magari un paio di switch ben carrozzati, magari un paio di SAN e poi delle API per automatizzare la gestione delle virtual machines. Questo è tutto quello che serve per partire… e poi?

E poi il provider si mette a vendere e, man mano che riempie il cloud, aggiunge nodi di calcolo, oppure banda, oppure ulteriori SAN..

E qui nascono i problemi, perchè la decisione del provider di espandere il cloud è basata su di un capacity planning iniziale. Quando il limite progettuale dell’infrastruttura viene raggiunto allora la si espande, e qui casca l’asino.

Un’infrastruttura è satura quando il costo di produrre una ulteriore unità di potenza “cloud” è superiore al ricavo che se ne ottiene.

A meno che il provider non sia particolarmente ben messo sia dal punto di vista progettuale che dal punto di vista del cash flow è presumibile che il cloud verrà espanso solo quando ce ne sia l’effettiva necessità (leggi: problemi) e non prima.

Questa considerazione è tanto più vera quanto sono valide queste affermazioni:

1) Il costo dell’hardware decresce nel tempo (quindi comprare dopo offre un rapporto potenza/euro più favorevole).

2) Il costo della banda internet italiana è elevato (quindi meglio comprare il più tardi possibile e solo quello che serve per davvero).

3) Il costo dell’elettricità è in aumento (perchè anticipare spese elettriche mangiando via il margine?)

4) L’assorbimento elettrico dei server diminuisce man mano che la tecnologia avanza (quindi meglio comprarli dopo).

5) Lo spazio occupato dai server (a parità di potenza) diminuisce man mano che la tecnologia avanza (quindi aspettando puoi ottenere densità di sala maggiori).

Se unisci queste considerazioni al fatto che i servizi cloud vengono percepiti dai clienti come dei servizi più economici dei normali server dedicati e che i servizi cloud vengono inoltre percepiti come privi di barriere in ingresso ed in uscita allora capirai come i cloud provider italiani siano tra l’incudine ed un martello bello grosso!

E’ chiaro che, in una situazione di questo tipo si deve sfruttare l’hardware fino all’ultima goccia: quindi i cloud shared italiani (che gli piaccia ammetterlo oppure no) fanno overbooking, ma si vergognano ad ammetterlo.

Ora, se ti viene la tentazione di considerarmi nel mucchio degli altri provider, trattieniti: io non faccio cloud shared, io faccio cloud dedicato.

Questo significa che l’infrastruttura che vedi ad inizio articolo, nei limiti del possibile, cerco di farla per ciascun singolo cliente che ho: questo significa che, se lavori con me, sei tu a decidere se fare overbooking dei **tuoi** sistemi (te li alloco, ma sono tuoi).

Dal canto mio, io cerco di guidare i clienti attraverso un percorso di capacity planning fatto a misura di quello che i clienti producono, forse non sarò il più economico ma almeno i miei clienti sanno quello che hanno, sanno dove vanno e sanno che la loro infrastruttura non è soggetta a problemi di concorrenza di accesso alle risorse da parte di altri clienti.

Non fraintendermi, non sto dicendo che se vai da altri provider ti troverai necessariamente male. Dico solo che non devi aspettarti che i problemi di performance dei tuoi sistemi non siano dovuti (anche) al grado di saturazione del cloud che li ospita.

Per oggi è tutto. Se ti piace quello che scrivo e vuoi entrare in contatto con me, oppure se hai bisogno di un partner competente per le tue esigenze di cloud dedicato, non esitare a contattarmi attraverso questo form.

Scommetto che non c’è uno di voi lettori che non abbia mai avuto problemi con le email, eppure si tratta di un sistema molto affidabile in rapporto alla quantità di dati che muove.

In questo post descriverò un po di metodi di troubleshooting lato client e, dal momento che non posso sapere se utilizzate Windows, Linux oppure OSX, farò degli esempi validi su tutte e tre i sistemi operativi.

Immaginate di avere un server dedicato in hosting da qualche provider, il server è fully managed e gestisce sia il servizio web che il servizio posta. Una bella mattina arrivate in ufficio, provate a scaricare la mail, e ricevete un messaggio di errore… cosa fate?

Innanzitutto restate calmi, ciò che vale per l’amministrazione di un server vale anche per il troubleshooting di qualsiasi problema!

Adesso analizziamo la situazione in modo analitico:

1. La connessione ad internet è funzionante?
In una buona percentuale di casi il problema è di linea e non di server, limitarsi ad aprire il browser non basta ad identificare un problema di linea, quello di cui avete bisogno è di una shell e del comando ‘ping’: aprite la shell e digitate:

ping www.google.it (vale su Linux, su Windows e su OSX), aspettate qualche secondo, se Google risponde al ping la connessione ad internet funziona, altrimenti fareste bene a chiamare il vostro provider di fonia e non il vostro provider di hosting.

2. Il server viene risolto attraverso il servizio DNS?
Premesso che la linea funzioni, bisogna verificare che i server DNS siano a posto, nella shell di Linux/OSX: dig mx ilvostronomedidominio, se invece usate Windows potete seguire questo how-to pubblicato su technet.

Questo è uno stralcio della risposta che ottengo se effettuo una query MX per il server mail registrato sul dominio levelip.com (ho usato il comando “dig mx levelip.com”):

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61450
levelip.com. 86400 IN MX 10 mail2.levelip.com.

In questo caso tutto bene, il server DNS risponde che non ci sono errori (NOERROR) e che il nome di domino relativo al mio sistema di posta è mail2.levelip.com.

Se invece avessi ottenuto come risposta: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 38964 allora potrei avere problemi con i DNS, oppure potrei aver digitato male il nome di dominio, oppure il nome di dominio è scaduto o magari è stato modificato un file di zona del DNS ed è stato configurato male…

Se ti trovi in questo, devi contattare con urgenza il provider del servizio DNS, e ricorda che potrebbe essere diverso dal provider dal quale hai in hosting il server dedicato.

Infatti, nulla ti impedisce di mantenere i tuoi domini da GoDaddy e poi comprare un server dedicato da Level iP

3. Il tuo server mail risponde al ping?
Se i tuoi server DNS sono a posto e hai connettività internet, allora il problema potrebbe essere davvero sul server mail. Prova a fare un ping direttamente all’URL del tuo server mail (nel mio caso, ad esempio, farei ‘ping mail2.levelip.com’) se il ping risponde allora il server è raggiungibile, se non risponde devi chiamare il provider che ti mantiene in hosting il server.

4. La porta del server di posta è aperta e risponde?
Se il server risponde al ping ma hai ancora problemi ad inviare e ricevere posta è il momento di sfoderare il vetusto – ma ancora utile – telnet: Apri una console e digita “telnet (nomedeltuoserverdiposta) 25″, ad esempio nel mio caso scriverei “telnet mail2.levelip.com 25″ ottenendo:

Trying 80.247.64.82…
Connected to mail2.levelip.com.
Escape character is ‘^]’.

Se riesci a collegarti con il telnet allora il server di posta risponde, potrebbe essere un problema di autenticazione, altrimenti potresti avere il servizio mail stoppato oppure molto lento.

L’analisi non finisce qui, bisognerebbe poi verificare se hai o meno problemi di autenticazione e di che tipo, l’importante è che hai capito il meccanismo di analisi.

La prossima volta che hai un server di posta con dei problemi, non limitarti ad arrabbiarti con il tuo provider, effettua un po di test e condividi queste informazioni con il tuo provider, se non altro renderà più facile ad entrambi risolvere il problema velocemente.

Ti è capitato mai di avere inviato una mail che non è mai arrivata, oppure che è arrivata in ritardo? Ti è mai capitato di vedere i tuoi messaggi di posta elettronica ritornare nella tua casella di origine ‘marchiati’ (in gergo si dice ‘flaggati’) come spam? Hai mai attribuito la responsabilità di questi problemi a questo oppure a quell’internet provider?

Beh, sappi che sei in ottima compagnia! Non conosco nessuno che non abbia mai affrontato queste difficoltà, per di più la colpa non è di nessuno (e in un certo senso è un po di tutti), continua a leggere e ti spiegherò il perchè.

La posta elettronica è un framework distribuito

In soldoni, questo significa che quando invii una mail non esiste un unico server che s’incarica della consegna: ne esistono almeno due, a volte di più, e poi ci sono i client di posta (il tuo e quello del destinatario).

La posta elettronica viene considerata (a torto) un sistema poco affidabile, in realtà è molto affidabile proprio perchè è un sistema distribuito dove la morte di un server non comporta lo stop completo dell’intero servizio a livello globale: in pratica, il framework mail (l’insieme di tutti i mail-server esistenti in internet) è quasi inaffondabile, mentre i server di un singolo ISP possono avere problemi senza che questo non pregiudichi il funzionamento dei server di altri provider.

Per esempio, se il server di posta di google mail si dovesse spegnere per qualche ragione, tu potresti ancora inviare la posta elettronica dal tuo server aruba ad un server di register, ma non a un server di google mail..

Per chiarire meglio il concetto, vediamo in un mondo ideale, cosa succede quando invii un messaggio di posta. Le cose si svolgono più o meno in questo modo:

> Il tuo client di posta invia il messaggio al server mittente, questo può essere anche un server diverso da quello che ospita il client di posta.

> Il server mittente invia il messaggio al server ricevente che lo accetta oppure lo rifiuta.

> Se il messaggio viene rifiutato potrebbe venir cancellato oppure rimandato al mittente assieme ad un messaggio di errore.

> Se il messaggio viene accettato verrà recapitato alla casella di posta destinataria (eventualmente marchiato come spam)

> Il client mail del destinatario scarica il messaggio di posta e lo presenta a video.

Sembra semplice, cosa potrà mai andare storto? … Praticamente, tutto!

Errori sul client di posta
Ci sono molte cose che possono andare storte sul client di posta: potrebbe non raggiungere internet (magari non ti funziona la DSL), potrebbe non avere le username/password settate correttamente, potrebbe esserci un firewall che ne blocca la connessione, potrebbe dover passare da un server di mail-proxy prima di raggiungere il server mittente, etc etc.

Errori sul server mail mittente
In questo caso è responsabilità del tuo ISP risolvere il problema, non sto ad elencarti la quantità di possibili problemi e le relative soluzioni perchè si tratta di un elenco quasi infinito.

Errori sul server mail destinazione
In questo caso è responsabilità dell’ISP del destinatario risolvere il problema. Anche qui la quantità possibili problemi e soluzioni sfida ogni capacità di sintesi.

Errori sul client del destinatario
Come per il client mittente, i problemi potrebbero essere di connettività, di credenziali, di firewall, etc etc.

Scommetto che, con tutti questi potenziali punti di errore, la tua impressione che i servizi mail siano inaffidabili si è rafforzata… non commettere questo errore.

In realtà il framework di comunicazione mail è molto resistente proprio perchè, in caso di guasto di una delle componenti, è in grado di mantenere una qualità di servizio comunque accettabile: se perdi la connessione DSL le tue mail arriveranno dopo, ma arriveranno, se il tuo server mail primario va in crash, le tue mail verranno ricevute e gestite da un server mail secondario, se un server mail non riesce a connettersi con un altro, continuerà a riprovare per un paio di giorni, etc etc.

Nel prossimo post approfondirò invece gli errori che vengono visualizzati quando ci sono problemi di invio/ricezione mail ed elencherò una serie di possibili soluzioni e metodi per fare un troubleshooting efficace. Stay tuned.

Dovete sapere che scalare un’infrastruttura web ad alta volumetria è come cambiare tutti i componenti della tua macchina mentre guidi allegramente a 150Km/h, tipicamente è un evento critico, traumatizzante per alcuni, e come tale va gestito con attenzione.

Molte volte ci si ritrova a dover dare supporto morale sia al proprio cliente che ai propri sistemisti, perchè durante una migrazione non sempre va tutto a posto al primo colpo e alcune volte devi fare dei compromessi radicali.

Voglio raccontarti un aneddoto…

Qualche tempo addietro mi è capitato di sviluppare un’infrastruttura dedicata ad un sistema di advertising. Il software era basato su un normale stack LAMP, girava su di un paio di server dedicati e oltre un certo limite di traffico cominciava ad avere problemi.

Che tipo di problemi aveva il cliente quando ancora si trovava dal vecchio fornitore?

Beh, diciamo che quando si raggiungeva qualche milione di page view al giorno, il numero delle richieste in ingresso era così tanto superiore alla capacità di erogazione del sistema che l’infrastruttura smetteva di erogare: errore 503 e tanti saluti.

La cosa peggiore è che la migrazione andava fatta in corsa, da un sistema che erogava male ad un sistema che sapevo avrebbe erogato meglio. Quello che non potevo prevedere, tuttavia, era la difficoltà di migrazione ed ottimizzazione dell’infrastruttura.

Firmo il contratto, ordino due macchine quattro volte più potenti di quelle attuali, preparo l’infrastruttura, effettuo il test di carico di un ora simulando un traffico quattro volte superiore a quello previsto contrattualmente, tutto sembra funzionare a puntino.

Decido allora di spostare i dati e girare i DNS: nel giro di tre ore mi va tutto in bomba! Ma come? Con un hardware molto più potente, a parità di traffico e dopo un test di carico fatto per bene?

Voi che cosa avreste fatto al posto mio?

Se la risposta è “panico”, allora dovreste cambiare mestiere. Se la risposta è invece “avrei aperto i log”, complimenti, avete intrapreso il giusto cammino verso l’illuminazione.

Per conto mio, sono fortificato da una quindicina d’anni di sviluppo e attività sistemistica, quindi mi sono dato una scrollata ed ho eseguito il mantra del buon sistemista, che più o meno recita così:

1. Resta calmo
2. Non spegnere o riavviare il servizio morente a meno che non sia necessario
3. Non interrompere l’attività che mantiene il servizio in uno stato critico (se interrompi il problema, non troverai la soluzione)
3. Analizza i log
4. Individua il problema principale
5. Correggi un problema per volta
6. Analizza il risultato basandoti su metriche e logfile
7. Torna al punto uno e ripeti

E’ chiaro che, per poter risolvere una situazione così critica, ho dovuto mantenere il servizio del mio cliente in uno stato di instabilità almeno per il tempo necessario a capire quale il problema fosse, correggerlo, verificare che il problema fosse davvero risolto.

Siccome produco infrastrutture sulle quali i miei clienti fatturano, sono consapevole che ogni minuto di fermo servizio è un costo! Tuttavia rivendico fortemente il dovere di mantenere l’infrastruttura in stato di ‘down controllato’ almeno per il tempo necessario a capire il percorso di azione più adeguato.

Durante questa fase, devo sempre essere trasparente con il cliente, spiegare quale problema sto affrontando, dare delle tempistiche affidabili, spiegare quanto sia normale che durante una migrazione si attraversi un momento di crisi.

Ogni volta che si effettua una migrazione si prova un mix di sensazioni strane.

Se sei un sistemista dovresti provare un senso di profonda consapevolezza della situazione. Qualunque sensazione diversa (e soprattutto legata alla paura) ti dovrebbe indicare che stai correndo un rischio che non sei pronto ad affrontare. E sappi che se vai in panico non ne esci più da solo!

Se invece sei un cliente proverai forse timore misto a speranza: timore che ti si schianti tutto, speranza che a migrazione ultimata il tuo sistema sarà stabile per molto tempo e ne guadagnerai bei soldini!

In entrambi i casi senti lo stress e, ammettiamolo, fare infrastrutture dedicate al web non è un mestiere facile, specialmente se ci metti la faccia.

E come è finita con l’infrastruttura che mi si era schiantata in tre ore dal deploy?

Ho guardato i log e ho scoperto che i processi di php lasciavano i socket aperti su mysql fino ad esaurirne le connessioni. Durante il test di carico il problema non era emerso perchè il test era durato meno del tempo necessario per esaurire i socket! Un breve tweak alla configurazione MySQL, una tirata di orecchi al programmatore php del cliente e da allora tutto tranquillo.

Per oggi la smetto di scribacchiare, se tuttavia doveste aver bisogno di un hosting provider affidabile (e vi riconoscete in quello che scrivo), potete raggiungermi attraverso questo form.

Alla prossima.

In particolare, si tratta di un engine NoSQL che pur trovando nella quantità di RAM richiesta uno dei propri limiti, è estremamente performante durante le operazioni di scrittura, quindi adatto ad applicazioni ad alto volume di write dove la persistenza del dato non è un elemento essenziale.

E poi… è stato scritto da un italiano!

In particolare Redis è uno store key-value che utilizza la memoria RAM come repository principale: proprio per questo motivo Redis è molto performante durante le operazioni di scrittura e tuttavia un meccanismo di snapshot su disco rigido consente di mantenere una sorta di persistenza del dato.

Tuttavia, in caso di crash o down della macchina, i dati presenti in RAM e non saranno scritti su disco… ooops!

Quando si decide di utilizzare Redis, quindi, bisogna essere consapevoli che in caso di problemi si perderanno alcuni dati ed è necessario che questo non rappresenti un problema.

Inoltre, bisogna tenere conto che Redis mantiene il proprio dataset nella memoria RAM. Questo significa che è necessario stimare correttamente la dimensione del dataset ed il suo tasso di crescita a medio-lungo termine, altrimenti si pobrebbe rimanere senza RAM.

Intendiamoci, se stai utilizzando un servizio cloud allora potresti essere in grado di espandere la RAM in tempi ragionevolmente brevi, ma ci sono due considerazioni di cui tenere conto: innanzitutto potrebbe non essere un’operazione esattamente economica, in secondo luogo se hai un dataset molto grande ed in veloce espansione allora redis potrebbe non essere ciò di cui hai bisogno.

Detto questo, Redis rimane un engine NoSQL molto utilizzato, vuoi sapere da chi? In Italia, per esempio, viene utilizzato dal portale OKNotizie, che proprio piccolino non è. A livello internazionale, viene utilizzato (tra gli altri) da Disqus, una piattaforma per la gestione dei commenti SAAS. Disqus non è conosciutissimo nel nostro paese, ma è molto utilizzato all’estero e fa dei volumi di traffico notevoli.

In particolare Redis risulta essere ottimo in alcuni contesti write-intensive dove i normali RDBMS segnano il passo.

Quando si devono memorizzare dei dati statistici in realtime: ad esempio per memorizzare dati relativi alla navigazione di siti web oppure relativi all’accesso a banner pubblicitari.

Quando si deve trovare un’alternativa a MemCached: in questo senso redis offre inoltre il vantaggio di garantire una sorta di persistenza del dato pur rimanendo veloce quanto una cache.

Per alcuni tipi di portali web: quando la velocità di lettura/scrittura è fondamentale (ad esempio per un blog estremamente trafficato) allora Redis è un ottimo compromesso.

Se sei abituato ad utilizzare MySQL, utilizzare Redis può sembrare qualcosa di molto nuovo e concettualmente ostico. Tuttavia, se hai il controllo del tuo codice, Redis potrebbe offrirti benefici notevoli.

Specialmente quando puoi sacrificare un po di persistenza del dato nel nome di maggiori performance.

Questo significa che qualsiasi scelta di hosting tu faccia, se la tua applicazione web utilizza una base dati, sarai sempre costretto a scegliere tra consistenza e disponibilità, oppure tra disponibilità e partition tolerancy oppure tra consistenza e partition tolerancy.

In pratica, dovrai fare dei compromessi su come la tua applicazione utilizza i database e su come questa risponde ad eventuali problematiche lato infrastruttura di erogazione.

Hai capito bene… il livello di resilienza applicativa non lo sceglie il provider, ma lo scegli tu (anche) nel momento in cui decidi come interfacciare la tua applicazione ad un database.

Quindi, che alternative hai?

Se decidi di puntare su Availability e Consistenza del dato, cadrai su di un RDBMS tradizionale, che poi potrebbe non essere MySQL. Ad esempio potresti scegliere SQL Server di Microsoft, oppure PostgreSql oppure Oracle.

Ciascuno di questi prodotti ha i suoi pro ed i suoi contro, ma di buono hanno tutti di essere basati sul linguaggio SQL, percui è relativamente facile trovare qualcuno che li sappia sfruttare al meglio sia al livello di sviluppo che lato sistemistico.

Se invece decidi di sacrificare la consistenza in nome della partition tolerancy potrai scegliere dei sistemi come Riak, SimbleDB oppure Cassandra.

Cassandra, in modo particolare, è mantenuto dall’apache foundation, ha la capacità di scalare molto bene e ti permette di gestire dataset molto grandi. Personalmente ho visto un paio di installazioni cassandra sui cloud che ho dedicato ad alcuni clienti, mi sembra un prodotto molto interessante.

Non che gli altri prodotti siano necessariamente meno buoni, ma non ho ancora avuto modo di testare ne Riak ne SimpleDB su basi dati molto larghe, quindi ne parlerò quando avrò qualche dato in mano.

Infine, se decidi di puntare su consistenza e partition tolerancy sacrificando l’availability, allora userai probabilmente MongoDB oppure Redis.

Redis è un prodotto maturo, molto noto e soprattutto lanciato dall’italianissimo Antirez, che è anche colui che va ringraziato se in italia esiste OkNotizie, l’aggregatore che probabilmente avete usato per raggiungere questo blog.

Sei ancora indeciso tra RDBMS e NoSQL? Ti dico la mia: NoSQL is the way forward.

Innanzitutto perchè la dimensioni delle basi dati sta crescendo più velocemente della capacità delle piattaforme di accoglierli. Quindi molto spesso i sistemi database necessitano di essere distribuiti.

In secondo luogo per un problema legato alle performance. Oggi, infatti, i database sono spesso legati ad applicazioni web, questo significa che i tempi di risposta contano. A meno che non abbiate *davvero* bisogno del SQL, i sistemi NoSQL consentono ottime performance in cambio di un po di eleganza in meno.

Infine, le applicazioni moderne hanno un volume di ‘scritture a disco’ a volte molto importante. Provate ad immaginare, ad esempio, sistemi dedicati all’advertising pay-per-click, oppure dedicati al performance monitoring.

Non è strano che in questi sistemi ‘ad elevato carico di scrittura’ i dati vengano raccolti con stream di write su dei NoSQL (performanti) e poi gli stream vengano tradotti in SQL attraverso batch notturni (più lenti) per essere poi analizzati con più calma e sfruttando la potenza del SQL laddove serve per davvero.

Per oggi è tutto. Se ti piace quello che scrivo e vuoi entrare in contatto con me, oppure se hai bisogno di un partner competente per le tue esigenze di hosting dedicato, non esitare a contattarmi attraverso questo form.

Stay tuned.

I temi della scalabilità e dell’high availability erano privilegio quasi esclusivo delle infrastrutture con budget elevati che potevano acquistare molti server fisici, magari in datacenter differenti.

Il boom dei servizi online ha però mutato lo scenario in modo radicale e oggi anche aziende con budget relativamente modesti possono distribuire i server dedicati all’infrastruttura di erogazione su più macchine fisiche, magari in datacenter diversi, a volte nei cloud pubblici di Amazon.

E qui arrivano le note dolenti, perchè sebbene i contenuti statici (immagini, codice, css, html) siano facili da distribuire, ci si è accorti che database rappresentano un challenge del tutto differente: quando un sistema è distribuito, infatti, bisogna scendere a compromessi tra disponibilità del servizio, consistenza del dato e tolerance agli errori di networking.

E qui entra in gioco il teorema di CAP, che è un acronimo di Consistency, Availability e Partition tolerance. Per fare una scelta tra sistemi SQL o NoSQL bisogna prima afferrare questi tre concetti base:

1. Se un database è Consistente opera in maniera completa oppure non opera affatto.

Facciamo un esempio. State comprando un libro online e di questo ne è rimasta solo una copia. Il sistema vi permette di aggiungere il libro nel vostro carrello ma, quando arrivate al checkout, scoprite che qualcuno è stato più veloce di voi: questa è una inconsistenza.

Non è che un libro possa essere comprato a metà ed in magazzino ne è rimasto uno solo, l’inconsistenza va risolta! Questo significa che o un lettore rimarrà senza libro (e la transazione verrà annullata), o l’editore dovrà ordinare una copia ulteriore (e spedirla). Questo significa maggiori costi e/o perdite di guadagno

L’inconsistenza avrebbe potuto anche essere risolta utilizzando un database relazionale in questo modo: quando metti un libro nel carrello, la quantità a magazzino viene decrementata di uno, quindi il secondo acquirente vede il libro come “non disponibile” e non lo può comprare: Il sistema funziona in modo completo nel primo caso, e non funziona affatto nel secondo, quindi è consistente.

2. Se un database è disponibile risponde (in modo consistente) anche durante i picchi di traffico e l’intensità del picco (entro una soglia ragionevole) non rappresenta una causa di indisponibilità del servizio. Nota che se se un database non è disponibile non risponde affatto, quindi rimane comunque consistente.

3. Se un database è partition tolerant vuol dire che è distribuito su più server dedicati e che i dati sono mantenuti in sincronia automatica attraverso un pool di nodi.

Questo significa che se uno dei nodi del pool smette di rispondere (va in crash, si spezza il cavo di rete), si crea una partizione ovvero uno dei database del pool rimane con un set di dati più vecchio a causa della perdita di connessione, tuttavia lo stesso evento non altera il modo in cui gli altri nodi continuano a rispondere alle richieste, ovvero non impatta l’availability e la consistenza dei nodi rimasti in vita.

Capiti i tre punti sopra, possiamo definire il teorema di CAP.

Un sistema distribuito non può essere allo stesso tempo consistente, disponibile e partition tolerant.

E’ importante capire che finchè il tuo database si trova su di una singola macchina, purchè l’applicazione sia scritta per la consistenza del dato ed il database la supporti, questa sarà disponibile oppure no (se il server è vivo oppure in crash) e sarà sempre partition tolerant (perchè non c’è modo di avere network split su una singola macchina).

E’ anche vero che la potenza di calcolo della tua macchina singola non scalerà all’infinito e sarà tanto più inadeguata al tuo business quanto più questo (il tuo business) cresce più velocemente della capacità dell’hardware di raddoppiare la propria potenza di calcolo ogni 12-18 mesi

In pratica, se fai business online e hai successo, dovrai prima o poi distribuire i database su più nodi e ti esporrai al teorema di CAP.

E questa è una conclusione importante, perchè ti da bene l’idea di come la scalabilità della tua applicazione non dipenda solo dai server che acquisti ma anche dall’applicazione stessa, da come questa è pensata per essere consistente, dalla capacità dell’applicazione di replicarsi su più nodi e resistere ad eventi di network split.

E non si tratta solo di lavoro sistemistico! Il tuo provider di hosting sicuramente deve conoscere le tue esigenze di scalabilità e le peculiarità della tua applicazione prima di proporti un’infrastruttura dedicata e prima ancora di effettuare per te il capacity planning.

Altrimenti, l’infrastruttura non starà su, oppure non crescerà organicamente.

Nel prossimo post scenderò ancora più in dettaglio sulle differenze tra i sistemi RDBMS tradizionali e i sistemi NoSQL. Stay Tuned.

Quando un’applicazione web comincia a servire centinaia di migliaia di page views al giorno, uno dei colli di bottiglia è il database.

I normali RDBMS scalano in modo relativamente agevole quando si tratta di effettuare delle select, ad esempio utilizzando più MySQL slave e bilanciando le letture (si, lo so, c’è il replication lag)…

E tuttavia i veri problemi emergono quando si tratta di effettuare quantità notevoli di operazioni di scrittura su di un database: a questo punto entrano in gioco molti fattori differenti, alcuni legati all’hardware, altri legati all’ottimizzazione del database, altri ancora legati a come l’applicazione è scritta.

Ad esempio:

La velocità dei dischi: avere dischi da 15K RPM è fondamentale se l’applicazione web è database intensive (ad esempio uno shop magento oppure un blog wordpress con molto traffico).

Il tipo di controller RAID: avere dischi veloci non basta se questi non sono disposti in RAID hardware e se il controller non è performante e dotato della giusta quantità di cache.

La tipologia di supporto di memoria: i dischi SCSI sono in genere molto più lenti delle schede SSD e queste sono più lente della RAM. Ciascun supporto di memoria, però, ha le sue controindicazioni: i dischi SCSI non performano male per le scritture seriali ma hanno problemi sulle scritture randomiche, le schede SSD hanno buone performance in lettura/scrittura ma hanno problemi nella cancellazione/update di un dato, la RAM è velocissima ma è volatile.

La tipologia di operazioni di scrittura da effettuare: scritture randomiche viaggeranno bene su SSD, scritture seriali viaggeranno comunque discretamente su SCSI e giustificheranno meno il costo della SSD, ma se usate le SSD dovrete prestare occhio alle operazioni di update/delete.

Il motore di archiviazione del database: in MySQL (ad esempio) le tabelle MyISAM hanno performance che degradano al crescere della concurrency (per via dei table lock), al contrario le tabelle InnoDB hanno meno problemi di lock ma potrebbero essere meno performanti delle tabelle MyISAM in determinate condizioni. Altri database (SQL Server, Oracle) avranno le loro peculiarità al pari di MySQL.

La quantità di RAM: in genere i database necessitano di dotazioni RAM generose, questo per poter mantenere in memoria le porzioni di tabelle più utilizzate, gli indici, i buffer relativi alle operazioni di ordinamento o di raggruppamento. Sebbene ogni database avrà le sue peculiarità, le performance aumentano quasi linearmente con l’aumento di RAM e questo è particolarmente vero per database molto grandi.

Il modo in cui la tua applicazione si interfaccia al database: un conto è avere un’applicazione che effettua delle query direttamente con il connector tra il linguaggio di programmazione ed il SQL, cosa completamente differente è avere un ORM davanti (specie in applicazioni ad elevata volumetria), cosa ancora differente è doversi interfacciare al database tramite un’API rest oppure tramite un framework MVC dove il Model non è stato creato in modo attento.

Il controllo che hai sull’applicazione: ad esempio, a volte le tabelle MyISAM possono essere partizionate e, ad ogni partizione, si può associare una query cache adeguata. Questo però richiede di avere il controllo su come il proprio codice effettua le query all’interno del database. Se hai un’applicazione pre-cucinata e non sai metterci mano, avrai più difficoltà a scalare in performance.

Insomma, è il classico problema della coperta troppo corta, ottimizzare i database di un’applicazione dedicata al web richiede sempre dei compromessi e questi dipendono da fattori che non sono facilmente preventivabili nel momento in cui vengono acquistati i server dedicati all’infrastruttura.

Questo, ovviamente, a meno che non si faccia un’apposito studio di capacity planning, cosa di cui ho vi ho già parlato qualche post fa.

Nel prossimo post, scenderò un po più nel dettaglio e comparerò i tradizionali RDBMS ai NoSQL che oggi vanno tanto di moda (e non a torto).

Alla prossima.