Aruba Cloud. Vantaggi e svantaggi del cloud a confronto di server dedicati. Benchmark e non solo.

Scrivo questo post, in quanto in questi giorni sto seguendo un’importante azienda che sviluppa soluzioni ecommerce su Magento, nell’ottimizzare l’hosting per velocizzare sensibilmente la navigazione e l’user experience nei loro siti web.

La ricetta per far ciò è stata quella ben più volte menzionata e documentata in questo blog :

  • PHP 5.5
  • Zend OpCache (dato che abbiamo montato PHP 5.5) al posto del “solito” APC
  • Redis, che abbraccia la filosofia NOSQL come gestore cache e sessioni di Magento
  • Memcache
  • Percona Server – un fork molto stabile e performante di MySQL
  • Nginx, un webserver con gli steroidi che rimpiazzi egregiamente il lento (seppur ottimo) Apache.

La “ricetta” è quella ormai evangelizzata da tutti gli esperti sistemisti che sappiano il fatto loro e che abbiano la necessità di gestire picchi di utenze importanti e carichi elevati.

Ricetta che mi ha dato grossissime soddisfazioni anche su portali famosi come “Il fatto Quotidiano” e “tuttoandroid.net”

La scelta dell’hosting è stata invece “obbligata” su un player importantissimo a livello italiano, che si può definire tranquillamente scelta del mercato : Aruba.

Più precisamente data la necessità di avere una High Availability senza single point of failure, è stato scelto il Cloud di Aruba.

Se è vero che dal punto di vista sistemistico, feature come l’allocazione dinamica delle risorse e la scalabilità sono il forte di ogni Cloud che si rispetti, è anche vero che approfondendo meglio la soluzione proposta da Aruba ci si accorge che non sono tutte rose e fiori.

Ecco un elenco di gravi difetti che ho riscontrato a livello prestazionale sottoponendo la nostra istanza allocata a dei benchmark e comparati ad altre realtà che conosco bene, come un server dedicato con doppio disco RAID su Hetzner (noto hosting provider tedesco).

CPU

E’ evidente come già descritto nelle loro linee guida che “Ogni CPU Virtuale acquistata prevede una potenza minima riservata e garantita di almeno 0,5 core fisici di una CPU Intel Xeon serie 5600.
Dunque acquistare 4 CPU equivale nella peggiore delle ipotesi avere a disposizione una potenza di calcolo pari a 2 core di un Intel Xeon 5600, senza nemmeno il supporto del multithreading.
Caratteristiche senz’altro discutibili considerando anche il posizionamento di questa CPU nella classifica di CPU Benchmark.

Dal punto di vista di un sistemista bisogna per ovvi motivi ragionare nell’ottica della situazione peggiore, sopratutto quando si intende progettare un servizio di hosting dimensionato alle reali esigenze dell’utente finale.

Per avere insomma 8 core reali  su Aruba Cloud dovrei comprare ben 16 vCore. Su un server dedicato invece avrei potuto beneficiare di 4 core reali visti come 8 thread.

Scegliendo l’hypervisor VMWare (il più costoso ma anche il migliore) il costo per 1 singola CPU virtuale è di € 0,025/Ora che significa esattamente 18 euro / mese.
Avendo la necessità di garantirci almeno 4 core reali (ricordando che la potenza minima riservata e garantita è della metà) dovremmo moltiplicare per 8 questo valore : 144 € / mese !

RAM

La RAM è del tutto fisica e dedicata. Nulla da criticare se non fosse il costo sicuramente non trascurabile.
Per ogni GB infatti il costo è di € 0,005 / ora, che significano ben 3,60 euro / mese.
Considerato che un server in produzione ai giorni d’oggi non ha meno di 8 GB di RAM, parliamo di ben 28,8 € / Mese.

DISCO

Questa è la nota più dolente di tutti. Il motivo per cui non consiglierei mai a nessuno di utilizzare questa piattaforma Cloud per progetti commerciali di qualsiasi tipo.
In primis perchè il costo è proibitivo. Secondariamente perchè le prestazioni sono davvero troppo basse per il prezzo pagato.

Ipotizziamo un taglio disco di 100 GB (valore reale del sistema per cui sto prestando consulenza), costando € 0,003 / Ora ogni 10 GB, significa ben 21,6 € / Mese

Costi a parte, considerando che chi fa serio business difficilmente si fa problemi sui costi se il servizio ha un alto valore aggiunto, in questo caso va evidenziato un dettaglio fondamentale : le prestazioni di I/O talmente scarse da poter diventare il collo di bottiglia per l’intera architettura.

Pur notando empiricamente dei transfer rate non ottimali in routine di copia file, abbiamo voluto testare scientificamente le prestazioni con un benchmark dei dischi e comparandolo coi risultati di un server dedicato con dischi da 6 Gb/s 7200 rpm in RAID1 – Software.

Aruba Cloud :

  • Timing cached reads: 8834 MB in 2.00 seconds = 4419.74 MB/sec
  • Timing buffered disk reads: 28 MB in 3.80 seconds = 7.37 MB/sec

Hetzner – Server Dedicato con dischi RAID

  • Timing cached reads: 24252 MB in 2.00 seconds = 12145.40 MB/sec
  • Timing buffered disk reads: 344 MB in 3.00 seconds = 114.65 MB/sec

Emerge eloquentemente e senza ombra di dubbio che le performance disco della Cloud di Aruba sono dalle 3 alle 20 volte inferiori a quelle del server dedicato preso come riferimento per il confronto.

Valori indubbiamente bassi per servire grosse quantità di file, ma sopratutto per essere alla base dello storage di grosse basi di dati su MySQL o PostgreSQL, laddove la tendenza del mercato oggi è quella di usare dispositivi di archiviazione a stato solido come drive SSD o periferiche dedicate come Fusion IO.

Sento il dovere di dover chiarire un concetto, nel caso venisse fraintesa l’analisi dei valori : questi dati riguardano esclusivamente il Cloud Aruba e non l’architettura Cloud in generale.
Va detto infatti che altri competitor come Amazon AWS, Azure, o Linode danno valori decisamente ottimi.

Ad esempio un hdparm -tT su una Linode 2048 (virtualizzata XEN): Timing buffered disk reads: 254 MB in 3.01 seconds = 84.48 MB/sec

Cosa vogliamo dimostrare con questa analisi ? Tutto e niente.

Dipende da quello che si deve fare e sopratutto chiedersi (e rispondersi) se veramente il Cloud Aruba è la soluzione adatta al nostro progetto e alle nostre esigenze.

Valutare i “vecchi” sistemi dedicati e compararli sopratutto nel caso di prestazioni spinte.

A livello di costi non ci sono ovviamente paragoni, pur essendo per loro natura prodotti simili, ma non equivalenti e quindi difficilmente comparabili.

Per puro sfizio ecco il preventivo di una configurazione Aruba Cloud per garantire prestazioni equivalenti ad un server di fascia medio alta Hetzner

hetzner-server-dedicato

aruba-cloud-preventivo

Emergono due ulteriori conclusioni importanti :

Le risorse allocabili sono limitate, e 8 CPU e 32 GB di RAM sono valori BASSI in un contesto reale, tanto che non riesce ad eguagliare minimamente la comparazione con il server dedicato preso come esempio.
I costi sono decisamente alti : al lordo dell’iva sono 448 € contro i 99 € (iva compresa) dell’offerta tedesca.

Insomma, ne avremmo abbastanza per mettere online almeno 4 server dislocati geograficamente e garantirci un H/A tramite ridondanza geografica.

Qualora abbiate esigenza di progettare o ottimizzare i vostri servizi online contattateci pure, sapremmo sicuramente consigliarvi la soluzione da adottare e il partner più indicato per il vostro business.

Come implementare e configurare correttamente le DNSBL (o RBL) sul nostro server di posta onde evitare falsi positivi.

spam_dnsbl_rmiozioneUno dei problemi maggiori da sempre riguardo il servizio email è lo SPAM.

Negli svariati anni sono state ideate diverse soluzioni (più o meno efficaci) per arginare il problema, tutte con i relativi pro e i relativi contro.
Ciò che si cerca di raggiungere è l’identificazione ed eliminazione dello SPAM totale, avendo cura di non eliminare nemmeno una mail legittima (o considerata tale).

Ovviamente bilanciare l’obiettivo risulta estremamente complesso, nell’ottica che cestinare una mail legittima, sia ben più grave che lasciar passare 2 email di SPAM.

Per questo, è bene tenere sempre a mente che non si possono scegliere soluzioni drastiche, ma sopratutto che la sicurezza è un processo e non un prodotto.

Ovvero, non ci si può affidare solamente di un software specifico, ma bisogna coordinare diverse tecnologie che lavorino in sinergia tra loro.

Noi ad esempio nel nostro stack antispam utilizziamo :

  • Postgrey
  • SPF
  • Amavisd
  • Clamd
  • Spamassassin
  • RBL (configurate su Spamassassin)
  • Pyzor

e possiamo vantarci di avere un ottimo rapporto SPAM ricevuto / fasi positivi, laddove i falsi positivi sono praticamente nulli, e lo SPAM ridotto al minimo (nella caselle info@dreamsnet.it ieri ne ho ricevute 3).

Da anni che lavoro nel settore, come sistemista e amministratore di server mail, posso fermamente affermare che un mailserver che non riceve nemmeno una mail di SPAM saltuariamente è un mailserver che filtra troppo (anche quello che non dovrebbe filtrare).

Una delle configurazioni più classiche (ed errate) che ho trovato implementate in diversi server mail (anche di importanti società di hosting e internet service provider) è quella di implementare RBL a livello assoluto direttamente sul mail server.

Cos’è RBL ?

Una DNS-based Blackhole List (anche DNSBL, Real-time Blackhole List o RBL) è un mezzo attraverso il quale è possibile pubblicare una lista di indirizzi IP, in un apposito formato facilmente “interrogabile” tramite la rete Internet. Come suggerisce il nome, il meccanismo di funzionamento è basato sul DNS (Domain Name System).
Le DNSBL sono principalmente utilizzate per la pubblicazione di indirizzi IP legati in qualche modo a spammer. La maggior parte dei mail server possono essere configurati per rifiutare o contrassegnare messaggi inviati da host presenti in una o più liste.
Questi servizi offerti gratuitamente agli utenti e sistemisti di tutto il mondo, permettono realmente di decimare l’invio di SPAM, nonchè la ricezione, contribuendo a una funzione realmente utile all’utente finale.

spamhaus_dnsbl_basic

 

Brevemente funziona così :

  1. Il mail server del mittente ci invia una mail.
  2. Il mailserver del destinatario (il nostro) farà una richiesta di tipo DNS a una delle liste DNSBL che abbiamo implementato.
  3. La lista DNSBL ci risponderà che è in blacklist o che non lo è.
  4. Se lo è rifiutamo di accettare il messaggio segnalando con un errore e informando il nostro mittente che è presente in una lista antispam.
  5. Se non è in SPAM accettiamo il messaggio.

 

Fino a qui tutto bene, sembra una meraviglia. Si potrebbe tranquillamente dire che si può eliminare lo SPAM alla frontiera, senza accettare il messaggio e dunque risparmiando preziose risorse sul mailserver.

Una meraviglia in effetti se non fosse che bisogna mettere in discussione la precisione della tecnologia RBL, e del suo insindacabile giudizio.

Come avrebbe detto un famoso conduttore televisivo : “La domanda nasce spontanea !”, ovvero :

Essere segnalati in una lista RBL significa che siamo veramente degli SPAMMER ?

La risposta è NO.

Vediamo ad esempio alcuni scenari per cui noi legittimi mittenti e non spammer ci vediamo ritrovati in una blacklist, e il nostro fidato e amico destinatario vedrà rifiutarsi la consegna del messaggio a causa della configurazione errata del suo mail server.

  1. Sono col dominio dominiotizio.it e sullo stesso mailserver (con lo stesso IP) ci sono ospitati altri 500 domini per un totale di 2500 caselle email gestite.
    Una casella email viene violata, e nel giro di un ora uno spammer riesce a consegnare 10000 email a indirizzi email random sui classici yahoo.com.
    L’amministratore se ne accorge, limita il danno disabilitando l’account … ma nel frattempo viene inserito in dnsbl.sorbs.net (una nota ed usatissima RBL).
    Da li in poi per diverse ore (anche giorni), l’IP del mail server risulterà come SPAMMER.
  2. Gli stessi presupposti dello scenario 1, con la differenza che siamo finiti in altre liste (questa volta a pagamento). Come riportato qui https://www.dreamsnet.it/2013/06/mailserver-blacklist-dnsbl-e-spam-uscire-dalle-liste-e-vivere-serenamente/ a volte per rimuoversi da liste RBL in tempi accettabili (poche ore), alcune liste pretendono un pagamento variabile tra 40 e 100 dollari per effettuare la rimozione dell’indirizzo “nell’immediato”.Nessun amministratore di server mail accetterà mai di cedere a tale spesa (o meglio ricatto), per cui è possibile che invece di essere in liste DNSBL per qualche ora o giorno, possiate rimanerci per 7 giorni fino alla rimozione automatica.
  3. Siamo sempre listati nelle liste di SPAM. Basti pensare e molti provider italiani, Libero.it su tutti, ma anche i vari Telecom e Fastweb che col loro alto numero di utenti e di mail server sono spessissimo (Libero lo è quasi sempre) listato in una o pià liste RBL.

 

In tutti e 3 i casi ci troviamo di fronte a situazioni in cui sebbene la mail venga inviata da un mailserver possa essere in liste antispam perchè precedentemente (o anche attualmente) usato da spammer, il contenuto della mail e la mail stessa risulta legittima e gradita, dunque non SPAM.

Arrivare a conclusioni del tipo “sei in una lista antispam per cui sei uno spammer, allora non accetto la mail” non ha senso in un contesto reale dove la mail diventa uno strumento di lavoro e la non ricezione può comportare gravissimi problemi.

Tornando all’introduzione precedente, oggi molti amministratori di sistema implementano i filtri direttamente sul mailserver in questo modo (esempio su mailserver postfix) :

reject_rbl_client zen.spamhaus.org,
reject_rbl_client list.dsbl.org,
reject_rbl_client sbl.spamhaus.org,
reject_rbl_client bl.spamcop.net,
permit

 

Ciò significa che il nostro mailserver rifiuterà di accettare il messaggio se l’IP del mailserver del mittente è listato in una delle 4 liste elencate. E sia ben chiaro, che per essere rifiutato basterà che sia presente in ALMENO UNA DELLE 4.

Approccio completamente assurdo e sbagliato. Nel caso in cui le liste fossero ipoteticamente 20 (teoricamente possibile, in pratica ne vengono configurate 3 o 4 normalmente), essere presente in 1 sola su 20 dovrebbe essere sinonimo di “essere in regola”, in questo caso invece 1 su 20, o su 100 significa essere SPAMMER.

Ciò è errato. Profondamente errato.

Il sistema RBL deve essere uno strumento in più, non l’unico atto a discriminare la bontà o meno di una mail. Deve indicare, ma non provare. Deve essere testimone e non giudice. Deve fornire prove, ma non emettere sentenze.

Ecco perchè un uso sensato delle RBL è quello di toglierlo immediatamente dai file di configurazione di postfix (o del vostro mailserver) e di utilizzarlo insieme ad un filtro bayesano come Spamassassin e poi eventualmente eliminato da Amavis.

Un filtro bayesiano (dal nome del noto matematico Bayes vissuto nel XVIII secolo) è una forma di filtraggio dello spam che si basa sull’analisi del contenuto delle email. Questa tecnica è complementare (e di grande efficacia) ai sistemi di blocco basati su indirizzo IP, le cosiddette blacklist.
Il filtro bayesiano applica all’analisi delle email un teorema, espresso per l’appunto da Bayes, secondo il quale ogni evento cui è attribuita una probabilità è valutabile in base all’analisi degli eventi già verificatisi. Nel caso dell’analisi antispam, se in un numero n delle mail analizzate in precedenza l’utente ha marcato come spam quelle che contenevano la parola “sesso”, il filtro ne dedurrà che la presenza di quella parola innalza la probabilità che le mail seguenti contenenti quella parola siano a loro volta spam.
In questo modo, il sistema è in grado di adattarsi in maniera dinamica e veloce alle nuove tipologie di spam.

Brevemente ora funzionerebbe così :

  1. Mi mandano una mail
  2. La accetto
  3. Faccio il controllo sull’IP del mittente. Se presente nella prima lista aggiungo 1 al punteggio
  4. Faccio il controllo sull’IP del mittente. Se presente nella seconda lista aggiungo 1 al punteggio
  5. Faccio il controllo sull’IP del mittente. Se presente nella terza lista aggiungo 1 al punteggio
  6. Faccio il controllo sull’IP del mittente. Se presente nella quarta lista aggiungo 1 al punteggio
  7. Faccio gli altri controlli Bayesani sull’oggetto, sul contenuto … e per ogni violazione aggiungo un punteggio specifico.Se alla fine di tutti i controlli di SPAMASSASSIN il punteggio finale della Email è 5, significa che questa mail è SPAM, altrimenti è legittima e la consegno.

 

Facile capire che una mail legittima, pur essendo in ben 4 liste antispam (a livello di IP) verrà comunque consegnata, come è altrettanto facile capire che una mail che non è presente in nessuna blacklist ma viola innumerevoli regole a livello di contenuto, viene comunque non marcata come SPAM e dunque consegnata.

Abilitare RBL su SpamAssassin è questione di 1 minuto, basta infatti editare il file /etc/mail/spamassassin/local.cf e aggiungere :

skip_rbl_checks 1
rbl_timeout 3
score RCVD_IN_SORBS_DUL 1
score RCVD_IN_SORBS_WEB 1
score RCVD_IN_SORBS_SMTP 1
score RCVD_IN_SORBS_HTTP 1
score RCVD_IN_XBL 1

ed avere cura poi di settare il punteggio di “taglio” di amavisd a 5 … o 6 (per essere meno ferrei e un po’ più elastici).

5 buoni motivi per non far scadere un dominio internet, ma anzi registrarne uno.

killer-domain-nameUna delle cose più stupide a cui si assiste quotidianamente in rete è quello di lasciar scadere nomi a dominio che utilizziamo quotidianamente e sono una ricca risorsa per la nostra attività, o semplicemente sono importanti per il nome che hanno : pensate sex.com venduto a 13 milioni di dollari, o anche semplicemente il vostro nomecognome.it o .com

Vediamo alcuni dei validi motivi per non lasciare scadere il vostro dominio internet e rinnovarlo in tempo entro la data di scadenza.

  • Continuità dei servizi : quando un dominio scade, normalmente i servizi vengono sospesi. Ciò significa che il sito web, mail, e tutti gli altri servizi legati al dominio non saranno usabili. Inoltre al rinnovo del dominio potrebbe essere necessario la riconfigurazione di tutte le impostazioni con conseguente spreco di tempo e denaro.
  • Nessun costo aggiuntivo verso l’hosting provider : Rinnovare il dominio dopo la data di scadenza significa a volte dover contribuire ad un contributo di riattivazione che oscilla tra i 5 e i 25 euro. Ciò giustifica l’intervento umano dell’operatore che dovrà in questo caso provvedere manualmente alla riattivazione del dominio. Questa prassi non è in voga in tutti i fornitori hosting ma rimane comunque sufficientemente diffusa e del tutto lecita.
  • Nessun rischio di perdere il dominio : Se lasciate scadere il dominio, avrete ancora alcuni mesi per rinnovarlo dopodichè verrà reso viagra reviews disponibile sul mercato anche a nuovi acquirenti. E’ quanto successo alla nostrana Mediaset, che non rinnovando il dominio mediaset.com ha permesso ad un “pincopallino qualunque” statunitense di nome Didier Madiba di comprarlo ad una decina di dollari.  La legge è chiara : il primo che arriva è il primo ad essere servito. Non conta se sei Mediaset, Berlusconi o Dio in persona, se ti comprano il dominio, o lo ricompri alle condizioni che detta l’attuale proprietario (ammesso sempre che sia intenzionato a venderlo), o lo perdi per sempre. Per i domini .it è un po’ diverso ed è possibile comunque aprire un contenzioso e fare ricorso al NIC, ma significa sempre e comunque mobilitare legali e burocrazia, e spesso arrivare di fronte ad un giudice, con i tempi biblici e tutti gli effetti collaterali (anche pecuniari) che essi comportano.
  • Nessuna perdita di dati : Allo scadere della clausola contrattuale (normalmente 2 o 3 mesi dalla scadenza) l’hosting provider si riserva il diritto (esercitato praticamente sempre) di cancellare in modo irrecuperabile i dati dell’utente. Addio sito web, database, email e quant’altro.

Un consiglio spassionato è quello di evitare di sospendere, lasciar scadere i domini con l’intenzione di registrarlo poi di nuovo una volta scaduto.
Esistono società apposite come SEDO che non fanno altro che comprare domini scaduti per poi rivenderli all’asta. Non lasciate la possibilità di perdere tutto per una manciata di euro l’anno.

Tutelare un nome a dominio che reputate importante o che possa servirvi in un futuro (ad esempio nomecognome.it) è fondamentale nell’era digitale e il rinnovo del dominio o l’acquisto dello stesso non va mai considerata una spesa ma bensì un investimento.