Lascia che il tuo server vada in crash, poi ottimizzalo.

Sono sempre stato affascinato dalla complessità delle infrastrutture server dedicate al web.

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.