Con la testa tra le nuvole

Il cloud computing sta diventando un termine sempre più usato (ed abusato) del panorama IT degli ultimi tre anni.

Come tutte le buzzword che si rispettino, lo abbiamo maltrattato un pochino negli anni passati, ma è  venuto il momento di affrontarlo in modo analitico, per una serie di ragioni.

Prima di tutto da uno studio risulta che quasi l’1% del traffico internet arrivi ad un nodo del cloud di Amazon. In secondo luogo, le tecnologie di virtualizzazione sono molto progredite, e anche se al momento hanno un fattore di efficacia basso (circa il 50% della velocità di un sistema nativo) l’hosting dedicato ha ancora costi proibitivi per business ristretti.

La “nuvola” promette la capacità di riconfigurazione dinamica delle risorse, e un controllo dei costi con una notevole granularità, con un loro abbattimento.

Iniziamo quindi facendo un’analisi di massima degli hosting provder virtualizzati, normalizzando i loro costi.Ecco  una modesta tabella comparativa:

[table id=4 /]

 

Note:

  • I provider comparati hanno generalmente uno SLA del 99.99%, che in un mese equivale a meno di  4 minuti e mezzo di downtime. In un anno però implica un downtime di oltre 50 minuti.
  • Nei limiti del possibile, si è cercato di comparare servizi equivalenti
  • Supponendo un mese di 30 giorni, in un mese vi sono 720 ore.

Metriche di confronto

Dalla tabella precedente si evince che il parametro più critico è la RAM fisica, seguito dallo spazio disco e dalla banda. Le ragioni sono le seguenti.

Tipicamente la banda è venduta in lotti molto alti oppure è illimitata. Lo spazio su disco ha oramai un costo risibile, poiché si trovano hard disk interni con un costo al Gb di circa 0,10€. I software di virtualizzazione inoltre possono funzionare anche con meno spazio disco di quello necessario, e quindi migliorare i consumi ed il provisioning. Ma la RAM fisica non è facile da virtualizzare: anche se alcuni sistemi riescono a farlo, per es dichiarando X Gb e allocando solo quelli realmente necessari, si tratta di una risorsa di per sé:

  • veloce da consumare
  • molto costosa
  • non genera contention
  • non scala linearmente come la memoria di massa
    Questo vuol dire che mentre è possibile, pagando molto, ottenere dischi o spazi di indirizzamento di milioni di petabyte, modellandoli come un gigantesco hard disk, questo al momento non è possibile per la RAM a costi ragionevoli, poiché è molto più limitata dall’architettura fisica.
L’I/O su disco genera contention. Cioé se si mettono troppe macchine virtuali sullo stesso dispositivo fisico, esse competeranno per l’utilizzo del disco, che essendo soggeto ad una inerzia fisica molto maggiore della RAM, potrebbe ridurre le prestazioni dei sistemi in modo significaivo.
La memoria RAM può generare contention, ma essendo molto più veloce questo aspetto è molto più tollerabile/ignorabile.
Una vecchia legge dell’informatica sostiene che per raddopiare le performance di un sistema è necessario spendere il quadruplo. Da questo se ne desume che un sistema virtualizzato (che mediamente è il 50% più lento di uno fisico) dovrebbe costare un quarto di un server dedicato, per essere economicamente accettabile.
 Detto questo, il primo servizio che analizziamo in dettaglio è l’Amazon Web Services, per una panoramica sugli altri cloud provider vi rimandiamo a questa discussione su quora.

Amazon Web Services

Uno dei plus di Amazon Web Services (AWS) è che offre una serie di servizi ridotti a titolo gratuito per un anno. Al momento è l’unico cloud provider con questa aggressiva strategia di vendita. Nella nostra comparazione però guarderemo ai costi puri, ipotizzeremo cioé di trovarci a pagare il prezzo pieno.

L’impatto con la procedura di registrazione ha dato una impressione di eccessiva “fiscalità”:viene forzatamente richiesto un numero di telefono che il sistema chiamerà per una verifica.

Giocando con il calcolatore incluso sul sito web di aws, i costi generalmente si aggirano intorno ai $20 per una istanza micro (che ha circa 600MB di RAM) supponendo un consumo di banda medio.L’istanza micro che abbiamo provato risulta essere un S.O. Linux virtualizzato con xen con modeste prestazioni.

La creazione della istanza di test è risultata però molto ben organizzata: è possibile creare una macchina virtuale linux in pochissimo tempo, configurando sia il firewall che  una chiave SSH per l’accesso. La macchina virtuale che abbiamo provato è quella standard fornita da Amazon, e siamo riusciti ad installare su di essa un server Redis in pochissimo tempo.

Purtroppo le istanze micro hanno delle “latenze forzate”, per cui il tentativo di utilizzare troppo tempo di CPU nella unità di tempo porta ad un “congelamento” della istanza micro.
E’ quindi difficile installare un server ad alto assorbimento di CPU su tali istanze, poiché se provate a connettere client molto aggressivi a un server su’istanza micro, riceverete errori di rete casuali (“socket reset to peer”, “connection timeout”, ecc) rendendolo di fatto poco affodabile.
Nessun provider di VPS citato sopra arriva a questo basso livello di affidabilità (a meno di non andare sui veri cheap hosting che però costano meno della metà di AWS).

Le istanze micro sono ideali per:

  • Modesti blog
  • Piccoli server GIT ospitati in SSH
  • Attività batch a basso carico e non critiche

 

E’ possibile creare un clone della macchina in modo molto rapido: basta effettuare una “snapshot” del disco virtuale (chiamato EBS nel gergo inziatico di Amazon) e poi creare da esso una AMI (AMazon Image file).

Punti di forza di aws sono la possibilità di installare velocemente un array di micro istanze server, e di poterle rimuovere in qualsiasi momento.

Trattandosi di un servizio a consumo, da’ i suoi risultati migliori se vi dotate di una infrastruttura che spenga dinamicamente i server che non prevedete di usare.

Se invece avete la necessità di un numero fisso di server sempre operativi, i costi di AWS iniziando ad essere comparabili a quelli di un qualsiasi provider linux.

Questo articolo del 2011 mostra come l’uso di istanze riservate porti a vantaggi solo dopo un attenta disanima, e leggiamo (italico aggiunto da noi):

As a result of all this, it is pretty undesirable to buy reserve instances unless you have a very stable environment, both technically and scale-wise. That sentence doesn’t describe the typical cloud use case in my opinion.
[…]
In the end, one of the reasons people move to the cloud in the first place is to get rid of the constraints of hardware.  When Amazon just puts those constraints back in place, it becomes undesirable. Frankly even now, I tried to just pay Amazon up front rather than actually buy reserve, but they’re not really enterprise friendly yet from a finance point of view so I couldn’t make that happen, so in the end I reluctantly bought reserve.
[…]

Inoltre qualsiasi provider di macchine virtuali vi farà uno sconto se acquistate in lotti da 3, 6 o 12 mesi, e sarà piuttosto disponibile ad aumentarvi/ridurvi un po’ la RAM se sapete impostare bene una marketing email: questo azzera i presunti vantaggi di AWS per volumi ridotti.

Prime conclusioni su AWS

Tra i plus di AWS c’è la possibilità di avere istanze di MS-Windows Server ad un prezzo accettabile, con una installazione di base di IIS e SQL Server “Express”.

Tra i contro, l’eccessiva complessità del sistema di compravendita che fa sì che sia confuso capire quanto effettivamente si spenda, e che ricorda molto da vicino le confuse tariffe degli operatori telefonici mobili Italiani (Tim, Vodafone, Tre…).

Per approfondire, guardate anche questo articolo per configurare da zero la vostra linux box.