Tuttavia fino a questo punto abbiamo considerato sempre un unico server dedicato ad una piattaforma LAMP; in questo post, invece, spiegherò perchè sia vantaggioso separare Apache e MySQL su due server differenti, ciascuno dedicato ad uno dei due servizi.

Perchè dovreste voler separare Apache da MySQL?

Innanzitutto perchè i due servizi hanno un modo differente di utilizzare le risorse del vostro server, ovvero a seconda del tipo di applicazione web che state eseguendo (wordpress, magento, joomla oppure un cms autocostruito), il sistema potrebbe avere come collo di bottiglia Apache oppure MySQL o magari entrambi.

In secondo luogo perchè iniziare a separare i servizi web dai servizi database è il passo essenziale per poi riuscire a scalare la tua applicazione web. Man mano che il traffico aumenta, infatti, un singolo server potrebbe non essere più in grado di gestire tutto da solo, indipendentemente da quanto è potente e da quanti soldi hai speso per comprarlo.

Il condizionale è d’obbligo: “potrebbe non essere in grado”.

Non tutte le applicazioni web sono le stesse e quale sia il limite fisico di erogazione della tua infrastruttura dipende sopratutto dal software che la compone, dalla sua organizzazione, dal tipo e dalla distribuzione di traffico e solo infine dall’infrastruttura stessa.

Come fate a capire che è necessario separare Apache da MySQL?

Non esiste una risposta univoca, visto che molto dipende dall’applicazione. Tuttavia, se invocando un comando “top” sulla shell della vostra macchina verificate che il sistema è molto carico (load average elevato, utilizzo dello spazio di swap, molti processi apache e/o mysql elevato utilizzo del processore, etc) allora bisogna iniziare ad indagare.

La cosa richiede un po di ‘virtualizzazione’.

Cominciate con il creare su di una macchina di test due macchine virtuali. L’importante è che sulla macchina di test utilizziate xenserver oppure vmware come ambiente di virtualizzazione: questi sono ampiamente diffusi e facili da scaricare, installare, utilizzare e sono ben documentati.

Inoltre gli hosting provider si appoggiano prevalentemente a vmware e a xenserver come base dei loro servizi di hosting dedicato in cloud oppure in vps.

Dopo che avete creato le due macchine virtuali configuratele all’interno di una rete privata in modo che si possano parlare a vicenda: il ping fatto su una deve raggiungere l’altra e viceversa.

Installate Apache su una e MySQL sull’altra dopodichè assicuratevi che:

• - la macchina MySQL possa rispondere (faccia il bind) all’interfaccia di rete
• - l’utente MySQL con il quale la vostra applicazione web effettua il login abbia un GRANT con wildcard e non una @’localhost’ (ovvero: GRANT ALL PRIVILEGES ON ‘user’@'%’ IDENTIFIED BY …..”.
• - gli script php siano impostati per conoscere l’indirizzo IP sul quale gira il server MySQL (e non localhost).

Se avete fatto tutto correttamente, una versione di test del sito dovrebbe girare localmente al vostro sistema di test. Se l’applicazione funziona normalmente è ora di iniziare i test.

Metti in crisi il sistema con AB
Adesso che Apache e Mysql sono su due macchine separate, è il momento di testare come il carico viene distribuito tra webserver e database.

Lo strumento adatto ad effettuare questo test è Apache Benchmark. Utilizzando AB puoi chiamare una pagina del tuo sito un numero arbitrario di volte e aprendo un numero arbitrario di connessioni contemporanee: ad esempio la index.php, ma perchè no, anche pagine specifiche.

Questo significa che puoi testare come una data pagina web performa sotto carichi bassi, medi, alti e folli!

Poichè la pagina che vai a richiamare con AB esegue delle query MySQL e poichè adesso apache gira su di una macchina diversa dal database, monitorando l’output del comando ‘top’ su entrambe le VM riuscirai a capire quale delle due componenti è più carica.

Se è più carica la macchina apache, una veloce ricerca su google potrebbe aiutarti a risolvere il problema, un esempio delle ottimizzazioni da fare potrebbe essere:

• - modificare il file di configurazione di apache in modo da mantenere più processi attivi, ad esempio quando ha molto più traffico di quanto il server sia configurato per gestire e la macchina ha abbastanza risorse di RAM e processore
• - modificare il file di configurazione di apache in modo da ridurre il consumo di RAM degli script php
• - passare a webserver alternativi, ad esempio nginx + php-fpm
• - eventualmente potresti scoprire che i tuoi script sono il collo di bottiglia, quindi ottimizzazione del tuo codice

Se invece è il database ad essere sotto carico la cosa si fa più complessa e la scalabilità dipende da come hai scritto il tuo codice.

Nella quarta parte di questo post parlerò un po più in dettaglio di MySQL, delle problematiche di carico e di ottimizzazione, e della possibiltà di scalare su più server dedicati al database.

Se nel frattempo hai bisogno di ottimizzare un server e hai bisogno di supporto contattami attraverso questo form. Sarò a tua disposizione per creare un’infrastruttura dedicata al tuo sito web, ottimizzata e scalabile.

Ad esempio, il valore del blocco di server email per un sito di e-commerce è diverso dal valore del blocco del server mail per un sito che effettua campagne di mail marketing.

Nel primo caso, al più, non puoi inviare delle conferme (d’ordine, di registrazione) ai clienti, è un problema molto fastidioso ma gestibile. Nel secondo caso il tuo servizio è completamente fermo. E’ chiaro che i due rischi meritano un’allocazione di risorse economiche differente e proporzionale al grado di impatto sul tuo business.

Qualsiasi attività che richiede un fermo macchina ha un valore economico: una migrazione, un upgrade, una nuova implementazione, per ciascuna di queste devi conoscerne il costo, altrimenti non puoi valutare la convenienza (o meno) di ciascuna operazione

E nota bene, ho volutamente usato la parola “valore” e non la parola “costo”. Se infatti consideri la tua infrastruttura web come un semplice centro di costo, rischi di sottovalutare la situazione.

Se fai business sul web, il tuo server vale tanto quanto il fatturato che ti genera, l’assenza del server vale quanto il fatturato potenziale che perdi.

Fatturato potenziale e coefficenti di impatto
Facciamo un esempio: immagina di essere proprietario di un sito di ecommerce che fattura un milione di euro ogni anno. Il valore di un minuto di downtime potrebbe essere dato da questa formula.

1.000.000 Eur / (365 giorni) / (24 ore) / (60 minuti) = 1,9 Euro/minuto

In realtà, però, i siti di ecommerce non vendono sempre nello stesso modo durante l’arco della giornata, avranno degli orari in cui vendono di più e degli orari in cui vendono di meno. Considerata come “una unità” (1) il momento di massime vendite della giornata puoi immaginare che tutti gli altri momenti di downtime valgano meno: questo è un coefficente d’impatto.

Ad esempio, il coefficente d’impatto di un downtime alle tre di notte su di un sito che vende unicamente in Italia e durante la settimana lavorativa potrebbe essere 0.1 nella notte tra sabato e domenica.

Inoltre il tuo sito potrebbe avere delle stagionalità: ad esempio, potrebbe vendere di più durante le feste di natale e di meno d’estate, oppure potrebbe vendere durante il weekend ma non durante la settimana.

L’importante è ricordare che il coefficiente d’impatto è una stima statistica che puoi ricavare dallo storico del tuo fatturato e che non può mai essere maggiore di uno

Quindi, la formula per calcolare il valore di un downtime alle tre di notte di sabato potrebbe essere:
1.000.000 Eur / (365 giorni) / (24 ore) / (60 minuti) * (coefficente d’impatto 0,1) = 0,19 centesimi/minuto

Adesso aggiungiamo i costi
A volte, un downtime rappresenta un costo, oltre che un mancato fatturato, anche questo va computato.

Facciamo un esempio: il server che muove il sito di ecommerce descritto sopra è in housing (quindi sei responsabile della manutenzione) e va in crash alle tre di notte. Poichè sei responsabile della tua macchina devi avere un tecnico che se ne prenda cura.

Se il tecnico è assunto a tempo indeterminato, quanto paghi per il suo stipendio? Se è un consulente esterno, quanto ti costa annualmente? Quando hai la risposta dividi il costo del tecnico per i giorni dell’anno, per le ore del giorno e per i minuti in un ora, poi aggiungi il costo al mancato guadagno.

Non complicare la formula
Potresti complicarti la vita ripartendo costi fissi, costi straordinari ed inventarti chi sa cosa. Ma alla fine l’importante non è di avere il costo *al centesimo* di un minuto di downtime, bensì un valore realistico – ma indicativo – che ti serva come guida per orientarti durante le scelte tecniche che comportano un down del tuo server web.

L’importante è non complicare eccessivamente la formula. Si tratta di una stima e serve ad orientarti in una scelta. Ricorda che l’importante è gestire il downtime e non illudersi di poterlo prevenire sempre e ad ogni costo.

Poi, se hai un’infrastruttura web critica per il tuo business, e se hai bisogno di un hosting partner affidabile e preparato, contattami tramite questo form.

Ad onor del vero, penso che chi fa business online dovrebbe concentrarsi su quello che sa fare meglio – il business – e non sull’ottimizzazione dei sistemi, tuttavia anche se non siete dei tecnici e non metterete mai il naso dentro un server, è bene conoscere il campo di battaglia con il quale vi dovrete confrontare.

Perchè ottimizzare un sistema è come una piccola guerra, ci sono sempre dei compromessi da fare e come in guerra tutti i compromessi causano ‘danni collaterali’.

Immagina di avere un blog in wordpress in hosting su di un server dedicato oppure su di un server vps, ovvero puoi quantomeno accedere all’ambiente linux sottostante con una password di root.

Immagina inoltre che il tuo blog abbia davvero problemi di performance: questo è un presupposto essenziale perchè se non hai problemi non devi mai cercare di ottimizzare un sistema, rischieresti solo di destabilizzarlo.

Tornando a wordpress, questo è basato su un’architettura LAMP, quindi il tuo hosting ti avrà fornito un server linux con apache e php preinstallati. Tipicamente il tutto gira all’interno di un unico sistema operativo quindi se fai login in root e lanci un ‘pstree’, trovi in esecuzione sia apache+php che MySQL.

E’ probabile che questa sia la configurazione LAMP che hai sempre visto e alla quale sei abituato.

Se non sei un sistemista e se non hai mai avuto problemi di performance non ti sarà mai venuto in mente che potresti eseguire Apache e MySQL su due server dedicati differenti (non correre subito a comprare un nuovo server dal tuo provider, aspetta!)

Prima di tutto soffermati ad analizzare la situazione, fai login nel tuo server come root, esegui il comando ‘top’ e Prendi nota dei valori di “load average”, di CPU e di memoria (libera, usata e swap). Guarda inoltre la lista dei processi e annota quanta CPU consumano Apache e MySQL rispettivamente.

Se il load average è molto vicino a zero, la CPU idem, la memoria usata è minore di quella installata e l’utilizzo dello swap è zero stai cercando di ottimizzare un sistema che è già scarico, fai logoff e vatti a godere una birra.

Altrimenti, comincia ad analizzare i dati e fatti queste domande:

Il sistema ha usato recentemente dello swap?
Se il sistema usa lo swap vuol dire che ha usato tutta la memoria disponibile.

In genere, a questo punto, l’utente medio corre dall’hosting provider e si fa vendere più RAM e magari una macchina più potente, ma questo approccio è tanto efficiente quanto usare una bomba atomica per eliminare un termitaio, funziona ma è una misura sproporzionata al risultato.

Quello che devi fare è capire se la memoria è usata maggiormente da Apache o da MySQL e iniziare ad ottimizzare la configurazione del servizio che occupa più RAM.

Il sistema non usa swap e ha tantissima memoria libera?
Generalmente questo si verifica dopo che hai usato l’approccio “bomba atomica su termite” visto sopra.

Già che hai fatto l’investimento, entra nelle configurazioni di apache e di MySQL e assicurati che utilizzino quanta più memoria possibile per attività di caching delle pagine e delle query.

Dovresti comunque ottenere un incremento delle prestazioni del tuo server, cosa significa?

Vuole dire che quell’aumento di prestazioni non è dovuto tanto all’hardware più potente bensi alle ottimizzazioni fatte. Questo significa inoltre che avresti potuto migliorare la situazione precedente senza affrontare una spesa: risolvere i problemi con hardware più potente non è sempre la soluzione migliore.

Il sistema ha un load average alto?
Qui ci dobbiamo intendere: se hai 4 processori e un sito moderatamente trafficato, avere un load average di 1 non significa che la macchina è sovraccarica. Avere un load average di 25 nella stessa situazione, invece, è un problema

Se il tuo load average è alto devi capire se il problema sta in Apache oppure in MySQL, ovvero: sono i tuoi script php ad essere molto pesanti, stai ricevendo più richieste di quante apache è configurato per servire, oppure sono le query MySQL a richiedere molto tempo per essere eseguite?

Fai un giro sui log di Apache e di MySQL, abilita il log delle query lente e senza indici, verifica che non ci siano errori che suonano come:

> “sto ricevendo più richieste di quelle che posso servire, aumentami i thread” (sia apache che mysql danno messaggi di questo tipo)

> “la query xxx ha impiegato più di 3 secondi ad essere eseguita” (MySQL da queste informazioni nel log delle query lente, se lo hai abilitato. Se non lo hai fatto abilitalo subito da my.cnf)

> “il processo php xxxx è rimasto appeso per troppo tempo e sarà terminato” (questo vuol dire che i tuoi script usano male la RAM oppure non vengono terminati correttamente e quindi devi ottimizzarli.

Ricorda che molto spesso anche query relativamente semplici possono impiegare molto tempo, se il database ha molte righe: ad esempio, lo sapevi che le query “select count(*)” quando contengono una clausola “where” effettuano un full table scan anche su innodb?

Quindi, ricordati sempre che anche il codice potrebbe (e dovrebbe) essere ottimizzato, al pari di un server.

E adesso i danni collaterali….
Siccome le risorse del sistema sono una quantità limitata, se scegli di ottimizzare un componente rischi di penalizzare un altro.

Ad esempio: se MySQL ha molte query lente e cerchi di aumentare la cache delle query per migliorarne le performance, la macchina userà più RAM e questo potrebbe dare fastidio a degli script PHP che prima non avevano problemi.

Oppure: se Apache riceve molte più richieste di quante ne può servire, potresti ottimizzare aumentando il numero di thread che apache tiene in ascolto. Questo però potrebbe aumentare il numero di script PHP in esecuzione e mandare alle stelle il Load Average.

L’ottimizzazione di un server è sempre un processo empirico, durante ogni step potresti causare un down, ogni down potrebbe darti indicazioni importanti per capire quale è il tuo collo di bottiglia.

Nella terza parte di questo blog spiegherò nel dettaglio come separare a livello applicativo Apache da MySQL, quando conviene e come bisogna farlo, quali sono i rischi.

Se hai bisogno di ottimizzare un server e hai bisogno di consulenza, se vuoi posso darti una mano, contattami attraverso questo form. Creare infrastrutture dedicate al web ottimizzate e scalabili è esattamente il lavoro che svolgo in Level iP (oltre che scrivere questo allegro blog, s’intende).

Non è un’obiezione da poco, perchè non c’è situazione più pericolosa per un fornitore di servizi hosting che il downtime di un server, questo per due motivi: il primo è che il mercato dell’hosting italiano è dominato da strategie di massimo ribasso sul prezzo, il secondo è che si tratta di un servizio relativamente intercambiabile.

Se i server dedicati costano relativamente poco ed è facile trovare online un nuovo fornitore, quando un server si pianta il cliente potrebbe decidere di passare ad un hosting alternativo (ad esempio da aruba a register), e qui viene il bello…

Prima o poi il tuo server si pianterà.

Se sei vagamente skillato avrai impostato un servizio di monitoring per inviare degli SMS ad un cellulare di emergenza, e porterai quel cellulare con te come una seconda pelle per tutto il tempo che il tuo business sarà online – il che probabilmente equivale al resto dei tuoi giorni – e ti verrà un tuffo al cuore ogni volta che quel cellulare emetterà un suono.

Non è che ti voglio portare sfiga. E’ che ho un datacenter pieno di server e so che ogni tanto uno si guasta. Se in datacenter avessi 1000 server e la probabilità di un guasto fosse di uno ogni 1000 giorni, dovrei probabilmente affrontare un guasto al giorno.

Quindi, per approcciare correttamente il tema dell’high availability bisogna convincersi che prima o poi un down è inevitabile, e in un certo senso anche benvenuto!

Perchè l’evento di “down del server”, per quanto sia un momento critico, è la cartina al tornasole con la quale misuri l’andamento del tuo business: il down è dovuto ad un eccesso di traffico rispetto a quanto previsto? Bene! Stai vendendo di più, risolvi i tuoi problemi di hardware e goditi gli utili!

Inoltre è un buon momento per verificare che gli investimenti che hai fatto nel provider di servizi hosting stiano dando i loro frutti: sei stato seguito correttamente, il tuo provider sapeva del down prima di te, è stato risolto velocemente o almeno con perizia?

Secondo me, quello che un buon provider di servizi hosting deve offrire in termini di high availability e gestione del down macchina, potrebbe riassumersi in questi punti:

> stabilire un canale di comunicazione diretto con il cliente
> stabilire un canale di comunicazione diretto con il cliente
> stabilire un canale di comunicazione diretto con il cliente
> costruire infrastrutture su misura, con più di un server dedicato, con la ridondanza built-in nel progetto in modo che l’incidenza di eventuali problemi hardware sia minima
> utilizzare un sistema di alert proprietario, procedure di escalation chiare e tecnici con reperibilità notturna/festiva, in modo da essere avvisati per tempo e poter ristabilire il servizio velocemente
> imparare dagli errori in modo da non ripeterli

Ti invito a fare una riflessione: quante volte hai intrapreso la scelta di cambiare provider di hosting dopo un evento di down risolto in modo non adeguato?

Se hai vissuto questa esperienza più di una volta, la ragione è che normalmente il provider offre elevate garanzie di persistenza a livello di datacenter (e ci mancherebbe pure!!) e non necessariamente a livello di singolo server dedicato / shared / vps.

In effetti, le chiavi di volta nella gestione del down macchina sono solo due: comunicazione e prevenzione.

Quindi per poter gestire correttamente i down di un server hai bisogno di:

> poter parlare con il responsabile tecnico della tua macchina presso l’hosting provider, e possibilmente che questo non cambi ogni tre mesi.

> aver concordato con il tecnico di cui sopra una serie di procedure di alert, escalation e recovery, e assicurarti al primo down che queste vengano rispettate

> in caso di imprevisti – e ce ne saranno, credimi – condividere l’esperienza acquisita con il tecnico di cui sopra, aggiornare le procedure di alert, escalation e recovery, apprendere per il futuro.

Poi, l’high availability dei tuoi servizi web può essere migliorata ulteriormente progettando correttamente l’infrastruttura, magari su di un layer di virtualizzazione dedicata, ma di questo parlerò nella seconda parte di questo post, fra qualche giorno.

Nel frattempo, se hai un’infrastruttura web critica per il tuo business e desideri confrontarti con un partner di hosting affidabile e preparato, potrai contattarmi tramite questo form.

Eppure il cloud, e specialmente il cloud dedicato, è in grado di consolidare in modo notevole l’ambiente in cui vengono eseguite le applicazioni web, siano queste dei blog wordpress, uno shop magento, una applicazione joomla, un’infrastruttura microsoft .net con SQL Server.

Il vantaggio principale sta nella creazione di un layer di esecuzione astratto, facile da espandere, migrare, mantenere.

Sia che tu stia utilizzando un cloud pubblico – ad esempio amazon – che un cloud privato costruito su hardware di tua proprietà, il primo vantaggio che ottieni è la possibilità di separare le componenti della tua applicazione web ed ottimizzarle in modo specifico.

Prendiamo ad esempio un blog wordpress: costruito sullo stack LAMP è un’architettura molto diffusa e ben documentata. In particolare lo stack LAMP prevede che le singole componenti che eseguiranno wordpress (Apache, MySQL e PHP) sono in esecuzione su di una macchina Linux.

Se il blog eroga qualche decina di visitatori al giorno, nessun problema. Anche un normale Server VPS può tranquillamente erogare quel traffico. Quando i visitatori aumentano l’architettura comincia a rallentare.

Fintanto che il sito in wordpress è ospitato all’interno di un solo server (vps o dedicato che sia), i margini di ottimizzazione sono limitati dalla mancanza di separazione tra i vari livelli dell’applicazione. Eppure puoi ancora effettuare delle ottimizzazioni sostanziali, ad esempio:

> Puoi modificare i parametri di apache per ridurre il consumo di memoria
> Puoi installare un opcode cacher
> Puoi utilizzare php-fastcgi
> Puoi modificare i parametri di MySQL in modo da utilizzare meglio i meccanismi di caching e ridurre l’accesso al disco
> Puoi installare dei plugin di wordpress che effettuano il caching delle pagine servite

…e puoi fare ancora tante piccole operazioni di tuning ma, inevitabilmente, raggiungerai un collo di bottiglia.

Se il tuo blog è database intensive – se ad esempio hai tantissimi commenti divisi in thread e molti visitatori – il collo di bottiglia potrebbe essere MySQL ed in particolare le performance di scrittura su disco.

Se il tuo blog è process-intensive, se ad esempio se vengono fatti moltissimi calcoli attraverso script php oppure se vengono serviti molti utenti contemporanei senza però impegnare il database, il collo di bottiglia potrebbe invece essere rappresentato da processore e RAM.

Quando raggiungi questo limite puoi decidere di comprare un singolo server più potente e sperare che basti. Oppure puoi decidere di separare i livelli applicativi, ovvero ospitare apache/php e MySQL su due macchine differenti, in ogni caso stai comprando hardware.

Se però decidi di utilizzare un cloud dedicato le tue opzioni aumentano notevolmente.

Un cloud dedicato è composto da uno o più server fisici interamente dedicati ad un cliente. Questo ti permette immediatamente di sapere quale è la potenza di calcolo reale che i tuoi server possono erogare e ti da la certezza che questa potenza di calcolo sia allocata interamente a te.

Poichè a questo punto dovresti già sapere se la tua applicazione è database intensive oppure processor intensive puoi decidere, stabilito un budget, quale è il set di hardware che meglio soddisfa le tue richieste di elaborazione.

Se non sai fare questa valutazione oppure preferisci demandarla a terzi, sarò ben felice di costruire per te un cloud dedicato bilanciato sulle tue reali esigenze.

Una volta definito l’hardware, su questo si installa un layer di virtualizzazione e si creano tante virtual machines quante sono necessarie ad erogare l’infrastruttura in modo coerente.

Nell’esempio del blog wordpress che facevamo sopra, se hai deciso di utilizzare due server dedicati, una volta installato un hypervisor potresti creare un paio di load balancer, una coppia di front-end dedicati al web ed una coppia di macchine MySQL dedicate al back-end.

In questo modo distribuirai meglio il carico di elaborazione sui due server e – incidentalmente – oltre ad aver dato potenza di calcolo alla tua infrastruttura avrai ottenuto

> maggiore sicurezza, perchè distribuendo l’elaborazione su due macchine fisiche ti proteggi contro il guasto hardware di uno dei due nodi

> maggiore scalabilità, perchè configurando due load balancer potrai affrontare più facilmente la crescita del traffico del tuo blog, magari aumentando il numero di macchine dedicate all’elaborazione php/mysql, oppure il numero di macchine dedicate al database MySQL.

Ancora una volta, se non sai oppure se non vuoi creare da solo un’infrastruttura del genere, Level iP ha un team di sistemisti esperti che sono in grado di consigliarti una soluzione tecnica adeguata in funzione al tuo budget.

Nei prossimi blog espanderò ulteriormente il concetto di cloud dedicato, se nel frattempo vuoi saperne di più puoi contattarci attraverso il nostro form oppure scrivendo info@levelip.com

Quando si valuta l’acquisto di un servizio di hosting dedicato (server dedicato, cloud o VPS che dir si voglia), si rimane molto spesso accecati da parole come ‘tutto incluso’, ‘minimo garantito’, ‘full managed’.

La convinzione, erronea, che queste parole danno al cliente è che il servizio sia gratuito, che si stia facendo un grande affare orientandosi verso il fornitore che offre di più ad un prezzo apparentemente molto più concorrenziale.

Si tratta di un errore di valutazione piuttosto comune, sia nell’acquisto di servizi di hosting che in altri settori della vita quotidiana, ad esempio nella scelta di un posto di lavoro: provate a dare un occhio a questo post di un ex googler… che conclusione ne traete?

Prima di fare le mie considerazioni, vorrei richiamare la vostra attenzione su come i recruiter di google hanno superato l’obiezione del candidato sottolineando che il cibo ‘incluso’ nello stipendio avesse un valore economico considerevole, questo lo ha spinto ad accettare il lavoro.

Nel corso del tempo la qualità del servizio si è via via ridotta (il blogger suppone) perchè il costo del servizio ha cominciato a pesare sul bilancio e quindi il budget è stato tagliato. E buonanotte alle promesse fatte.

Penso che il blogger si sia lasciato ingannare perchè ha valutato l’offerta solo dal proprio punto di vista (mi fanno mangiare gratis, abbondante, posso scegliere, risparmio tempo). Avrebbe invece fatto meglio a ricordare che un servizio mensa viene tradizionalmente considerato dalle aziende come un costo e che, indipendentemente dalle promesse, avrebbe potuto essere tagliato in futuro.

Ora ti starai chiedendo perchè si parla di cibo in un blog dove sistematicamente si parla di hosting e cloud dedicati.

Innanzitutto perchè è ora di pranzo e pure i sistemisti hanno fame. In secondo luogo perchè ritengo ci siano dei paralleli importanti con l’offerta di servizi hosting italiani.

Se provate a fare un preventivo online vi accorgerete di quanto spesso la parola ‘incluso’ viene utilizzata con più di qualche licenza poetica. Facciamo qualche esempio:

Banda internet inclusa
Immaginate un’offerta con 10Mbit/s di banda internet inclusa e 3 Gigabyte di traffico mensile: apparentemente tutti coloro che offrono meno di 10Mbit/s sono meno concorrenziali.

Fate mente locale e vi accorgerete però che vi stanno proponendo una doppia misurazione, una di volume ed una di flusso, dove il flusso (i Mbit/s) sembra essere molto abbondante ed il volume (i Gigabyte/mese) è in realtà un valore limitante. Eh si, perchè con un rapido calcolo scoprirete che 1Mbit/s a flusso continuo corrisponde a circa 330 Gigabyte/mese di traffico.

Si tratta di una bella differenza, anche perchè molte volte questo meccanismo di limitazione viene usato per vendere molta più banda di quanta se ne acquista e apparire concorrenziali.

Assistenza sistemistica inclusa
La frase lascerebbe intendere che posso chiedere assistenza tecnica in qualsiasi momento, che parlerò con una persona e che se chiedo assistenza nella notte tra sabato e domenica questa sia gratuita.

Chiunque offra qualcosa diverso da questa dicitura sembra essere meno concorrenziale, addirittura disonesto.

In realtà, che garanzia hai di parlare con un individuo direttamente e non esclusivamente tramite un ticketing system, un account skype? Che garanzia hai che l’assistenza durante l’orario notturno e festivo rimane gratuita?

La verità è che la dicitura ‘incluso’ viene usata per nascondere il fatto che un sistemista competente e sempre disponibile è un costo sostanziale per un provider di servizi di hosting. Il sistemista è ‘incluso’ perchè deve esserci, altrimenti il provider non sta in piedi. Ma ‘incluso’ è molto differente da ‘dedicato’, non indica quante ore di servizio hai diritto, in che fasce orarie, eventualmente a che prezzo.

La cosa peggiore è che ti accorgi del problema solo quando ti è scoppiato il server, quando pagheresti qualsiasi cifra senza fare storie pur di rimettere in piedi il servizio.

Posta con servizio antivirus e antispam incluso
Se non sei un sistemista la cosa potrà sembrarti una condizione essenziale per poter firmare un contratto.

La verità è che oggi non esiste una installazione di postfix (su ambienti linux) che non abbia incluso un servizio di antispam e di antivirus: incluso per definizione e non per graziosa concessione del provider!

Configurare l’antispam è facile come fare ‘apt-get install …..’; Fare il fine tuning è una cosa differente, ma tanto avete sottoscritto un servizio di hosting con assistenza sistemistica inclusa, no?

Servizio di backup incluso
E’ raro trovare un offerta che non dichiari il servizio di backup incluso. Chi non lo include oppure formula la frase in modo differente rischia di apparire come una persona insensibile alla perdita dei vostri preziosi dati, poco meritevole di fiducia.

La bontà di ogni backup, tuttavia, si vede solo in fase di restore, quindi se non vi lasciano accedere ai dati di backup, se non vi fanno fare le prove di restore, se non avete modo di verificare che il backup sia stato fatto veramente, che garanzie avete?

Se il dato si perde davvero, sicuramente vi arrabbierete con il vostro provider, ma tanto il danno è fatto.

Beh, consolatevi, anche in questo caso avevate scelto un hosting con assistenza sistemistica inclusa….

Conclusione
Quando sentite le paroline magiche “tutto incluso” dovete stare particolarmente attenti, è li che si nascondono le gabole.

Io mi sento di parlare di questi temi liberamente perchè in Level iP ho il compito di costruire progetti di infrastruttura dedicata su misura del cliente. Questo significa che incontro il cliente, valuto assieme a lui le esigenze di erogazioni reali, lo guido nella scelta di un budget, realizzo personalmente il progetto e l’infrastruttura, poi li mantengo: non posso permettermi di raccontar sciocchezze.

Quando costruisco un progetto “includo” una serie di servizi (banda, assistenza, etc) oltre all’hardware, ma questo viene fatto con trasparenza nei confronti del cliente: egli sa esattamente cosa e quanto sta comprando, io so esattamente cosa mi sto impegnando a produrre e come.

Siccome non nascondo al cliente la natura dei servizi che includo, anzi la specifico a contratto, non c’è pericolo che domani io mi possa rimangiare la parola data: cio che è incluso è incluso per davvero, e anche fatto su misura e concordato con il cliente.

Non vendo certo prodotti al massimo ribasso con servizio “tutto incluso“!

Se sei interessato a valutare delle proposte per un’infrastruttura dedicata al web contattaci attraverso questo form. Ti ricontatteremo e costruiremo assieme a te un servizio di hosting dedicato che includa – per davvero – ciò di cui hai bisogno.

Si è trattato di un percorso interessante che ha visto la migrazione progressiva di ciascun portale dalla vecchia infrastruttura, basata su di un unico server dedicato, a quella nuova.

QNetwork è un operatore web italiano, attivo dal 2007, che pubblica una serie di portali dedicati a tematiche quali l’istruzione, i libri, la salute, le vacanze, la ristorazione.

Il network ha registrato una costante crescita nel tempo in termini di visitatori e di partecipazione degli utenti, grazie alla quale ha superato abbondantemente il traguardo del milione di visitatori unici al mese sulle proprie pagine, nonché la collaborazione con aziende leader nei settori in cui operano i vari siti.

Tra i portali editi da QNetwork, si contraddistingue QSalute, che in breve tempo si è affermato come punto di riferimento online per il mondo della sanità italiana.

L’impiego massiccio della virtualizzazione, proposto da Level iP, ha consentito la creazione di una separazione logica tra i server dedicati all’erogazione dei documenti in php e quelli dedicati all’interrogazione mysql. E’ stato inoltre necessario effettuare – assieme al cliente – il fine tuning sia del codice che dei server. Il codice di QNetwork, infatti, era pensato per essere eseguito su di un’unica macchina dedicata.

Attualmente il network viene erogato a partire da una serie di server dedicati in alta affidabilità che hanno conferito all’infrastruttura robustezza e capacità di scalare con tempi di downtime minimi.

“Abbiamo trovato in Level iP un partner tecnologico ideale per le nostre esigenze: la fornitura di un’architettura all’avanguardia
e la presenza di un supporto sempre disponibile in tempi rapidissimi ci ha consentito di dare solidità e sicurezza alla nostra attività”,
afferma lo staff di QNetwork.

Se, come QNetwork, hai bisogno di uno o più server dedicati in grado di adeguarsi correttamente alle esigenze del tuo business, contattaci con fiducia. Un nostro capo progetto sarà a tua disposizione per ascoltare le tue esigenze di erogazione, di budget e proporre un’infrastruttura coerente e scalabile.

Non prendetemi per un maniaco del minimalismo, ma nel corso degli anni ho imparato mio malgrado che se un fornitore ha un’offerta troppo ampia, nessuno dei servizi offerti sarà eccellente.

Questo è particolarmente vero nei servizi dedicati al web e non è un caso che housing, hosting, server dedicati virtuali e fisici, cloud e servizi IAAS vengano spesso confusi tra di loro al momento di effettuare un acquisto.

Negli ultimi anni i big players dei servizi di hosting hanno fatto un ottimo lavoro nel banalizzare il mercato.

La ricetta è semplice: mettono in vendita 10 prodotti differenti, a ciascuno di loro assegnano tre fasce di prezzo – chiamiamole ‘low cost’, ‘business’ e ‘premium’ – fanno un bellissimo shop online che riceve un flusso di visitatori più o meno bisognosi, li lasciano girare in un bel labirinto fatto di almeno 1000 (10 elevato 3) possibili scelte e aspettano che i potenziali clienti chiariscano da soli le idee.

Se nel processo comprano qualcosa il gioco è fatto, i soldi li hanno incassati. Il prodotto non era quello di cui avevi bisogno? “Game over, insert coin to play again!”

Lasciamo perdere il fatto che questo approccio ti posiziona come il topolino in gabbia. E lasciamo perdere il fatto che se non hai competenza tecnica specifica diventa molto difficile fare una scelta adeguata al tuo bisogno.

Sicuramente questo approccio da parte del fornitore ‘classico’ di hosting ti porterà a paragonare le ‘caratteristiche tecniche’ di tre preventivi senza sapere se questi risolvono per davvero il tuo bisogno ed è allora che ti dovresti ricordare che, se fai un confronto implicitamente significa che non ti fidi del servizio che compri.

E fai bene, perchè se un fornitore ti offre 1000 possibili opzioni, in realtà non te ne sta offrendo nessuna.

Pensi forse che le sappia produrre tutte altrettanto bene? Pensi forse che non ci sia un modello di ‘vendor lock-in’ nel lasciarti acquistare 100 domini, 3 Vps, un servizio firewall, un servizio di backup, un cloud mail con servizio antispam a parte ed un host smtp dedicato senza neanche parlare con te?

E il tuo bisogno?

Se invece un fornitore ti offre uno ed un solo servizio, semplice, misurabile, adeguato alle tue esigenze e che realmente le risolve alla radice, ti metti a fare tante comparazioni sul prezzo?

Dal momento che il tuo bisogno è chiaro e che il tuo tempo ha un valore, se lo fai c’è del masochismo in te… a quello non posso offrire una soluzione tecnica, mi dispiace!

Quando ho deciso di lavorare con Level iP (e di scrivere questo blog) ho fatto questa scelta perchè mi ha consentito di offrire un servizio ben definito, semplice ma personalizzabile, con degli standard qualitativi che siano misurabili anche quantitativamente, e perchè mi consente di costruire un rapporto diretto con il cliente che mi consente di risolvere – per davvero e alla radice – i nodi tecnici della sua infrastruttura tecnologica.

E perchè amo la semplicità, ovviamente.

Se sei curioso di sapere come possiamo semplificare la scelta della tua prossima infrastruttura web, contattaci tramite questo form. Uno dei nostri capo progetto (forse io) ti ricontatterà per costruire assieme a te un progetto di hosting dedicato che sia davvero adeguato al tuo business.

Soprattutto negli ultimi anni la piccola e media impresa italiana si è arricchita di un nugolo ben nutrito di start-up tecnologiche e questo garantisce una richiesta sostenuta di servizi di hosting, di cloud e di infrastrutture dedicate.

Noi abbiamo basato il nostro intero modello di business, ed in particolare il nostro modello di cloud dedicato, per poter supportare le PMI ad elevato contenuto tecnologico.

In particolare, i servizi di hosting, housing, cloud e server dedicato, vengono erroneamente considerati dagli acquirenti come delle utility, alla stregua di luce, gas e telefono.

Non è cosi! Non lo è in special modo per le PMI e non lo è soprattutto per le imprese ad alto contenuto tecnologico.

E’ evidente che se sei a capo di un’azienda di grandi dimensioni che non ha come core business i mestieri dell’information technology, allora un servizio vale l’altro, purchè funzioni e costi poco.

Se invece la tua azienda è di dimensioni contenute e soprattutto ha una forte componente tecnologica, magari al centro del tuo modello di business, allora hai bisogno di qualcosa in più dei classici servizi hosting.

Innanzitutto hai bisogno di perennità del servizio… e non intendo gli SLA di uptime. Il tuo interlocutore tecnologico deve essere perenne nel senso che deve poter essere in grado di sostenere la tua infrastruttura nel tempo ed essere sempre facilmente raggiungibile nei momenti di criticità. Tanto in fase di crescita dell’infrastruttura quanto in fase di supporto durante un’anomalia tecnica.

In secondo luogo hai bisogno di un interlocutore al tuo livello. Ti ricorderai sicuramente la ragazza più bella della scuola, quella troppo corteggiata e per i più irraggiungibile.

Ecco, nel mondo dell’Information Technology è lo stesso: se ti rivolgi ad un fornitore troppo più grande di te verrai preso relativamente in considerazione, dove la parola ‘relativamente’ vuol dire ‘più o meno in funzione del parco clienti e del fatturato di quel momento’.

E’ qui che sta la chiave dei servizi di cloud dedicato che offriamo.

Siamo in grado di ascoltare il tuo bisogno tecnico e di erogazione, di sederci ad una scrivania per delineare con te la tua infrastruttura cloud presente e futura, di farti da supporto sistemistico sia in fase di criticità che in ottica evolutiva.

Se pensi di aver bisogno di un partner competente per effettuare delle scelte strategiche che riguardano il tuo acquisto in server dedicati, architettura cloud e/o tecnologia delle infrastrutture web in generale, contattaci con fiducia.

Il più delle volte la loro complessità cresce in modo esponenziale tanto che server dedicati perfettamente stabili, appena superano un certo limite, diventano bizzosi in modo imprevedibile quasi fossero dotati di una volontà propria e di una certa dose di sadismo.

La prima reazione, la più istintiva, è quella di cercare di prevenire ad ogni costo il crash: si tratta di una reazione sbagliata.

In realtà è giusto e necessario che – alle volte – un sistemista lasci andare i server in crash. Infatti, posto di aver correttamente configurato i log e di monitorare i parametri vitali della macchina, è proprio in quel momento che il sistemista acquisisce le informazioni necessarie per intraprendere i futuri step di ottimizzazione.

Uno dei mantra del buon sistemista dovrebbe essere:

1. Lascia che il server vada in crash
2. Analizza i log attentamente
3. Effettua le ottimizzazioni necessarie
4. Se il server ritorna ad essere instabile, lascia che vada di nuovo in crash e ripeti.

Dal momento che uno dei miei compiti è quello di interfacciarmi con i clienti, mi è sempre stato chiaro quanto sia difficile riuscire a spiegare questo concetto. Questo è ancora più vero perchè il cliente ha paura dei crash come il fuoco ne ha dell’acqua.

Ora, ad onor del vero, non è sempre necessario fare schiantare un server per migliorarne le performance, ma a volte lo è!

Prima lo si comunica **a chiare lettere** e meglio si vive la prova del ‘crash’, che poi altro non è che un momento di crescita per il cliente e per la sua infrastruttura.

Ad esempio, immaginate di dover scegliere una configurazione di server dedicato in HA dove i front-end web sono bilanciati ed i server sql sono configurati in master-master. Immaginate di aver scelto questa configurazione per garantire che il vostro e-commerce magento giri in alta affidabilità.

Vi installano l’infrastruttura, migrate i dati, gli ordini arrivano, tutto bene.

Tuttavia, un bel giorno, uno dei due server fisici si spegne e scoprite, solo in quel momento, che il server sopravvissuto non ha la capacità di reggere da solo l’intero traffico. Cosa è successo?

E’ successo che avete superato la soglia del 50% delle risorse del singolo server e non ve ne siete accorti. Questo sarebbe stato facilmente evitabile se, ad esempio, aveste pianificato con i sistemisti del vostro hosting dedicato alcuni “crash simulati” dell’infrastruttura.

E prestate bene attenzione, superare il 50% delle risorse del singolo server, non significa necessariamente superare il 50% di utilizzo del processore, della RAM e del disco. Per esempio, a volte il collo di bottiglia è il controller disco oppure la capacità di I/O del disco stesso.

I fattori che influenzano il carico di un server dedicato, poi, sono molteplici e molte volte suscettibili di ottimizzazioni.

Ad esempio molte volte basta cambiare i settaggi di apache/mysql, altre volte alcuni parametri di IPV4, altre volte ancora bisogna sostituire apache con un webserver più efficiente oppure stabilire politiche di caching adeguate.

Ti sei mai trovato in questo tipo di difficoltà?

Se hai bisogno di un server dedicato in grado di adeguarsi correttamente alle esigenze del tuo business, contattaci con fiducia. Un nostro capo progetto sarà a tua disposizione per ascoltare le tue esigenze di erogazione, di budget e proporre un’infrastruttura coerente e scalabile.