Recentemente ho fatto una migrazione di server da un cloud privato a un cloud pubblico.
La migrazione è stata programmata filosoficamente con dodici mesi di anticipo e poi operativamente in tre o quattro mesi, prevedendo ogni singola operazione al fine di minimizzare il downtime dei server.
Alcuni server sono stati fisicamente spostati dal cloud privato al cloud pubblico, altri sono stati costruiti ex-novo direttamente nel cloud pubblico per velocizzare i tempi di messa in produzione. Fin qui nulla di strano, direi.

Il primo lunedì di produzione nel cloud ho assistito a un decadimento delle prestazioni quasi inspiegabile
Ho provato allora a smontare pezzo per pezzo tutti gli applicativi e tutti gli strati software per capire chi fosse il colpevole del rallentamento.
Nonostante i continui miglioramenti, ogni volta che smontavo un pezzo non c'era mai un deciso miglioramento di performance e soprattutto, pensavo, non era possibile che con il cloud privato tutto funzionasse bene e sul cloud pubblico no.
E’ iniziata allora una meticolosa azione di troubleshooting, monitoraggio, performance monitor, tuning delle prestazioni.
Ho anche chiesto al fornitore del cloud di mettere sotto controllo gli host dove girano i nostri server.
Non ne uscivo, non esisteva apparente spiegazione a questo rallentamento.
Dopo decenni passati a fare troubleshooting dei problemi informatici, mi sono trovato in un vicolo cieco: non sapevo che pesci pigliare.
Colpo di fortuna: a un tratto mi viene in mente una cosa alla quale non avevo minimamente pensato.
Nelle fasi preparatorie alla migrazione, avevo preso uno snapshot del database server, macchina centrale nelle nostre attività
Ebbene, per errore o per dimenticanza quello snapshot non era mai stato rimosso.
Ora stando a quanto dice VMware nella sua Knowledge Base, gli snapshot sono comodi ma potenzialmente dannosi.
C'è un paragrafo che recita:
"Lo snapshot impatta negativamente sulle performance di una macchina virtuale.
Quanto più è lontano nel tempo lo snapshot e quanto più cambia il disco nella realtà, tanto peggiori sono le prestazioni.
Non è consigliabile lasciare uno snapshot in maniera permanente su un server di produzione".
Non molto convinto ho rimosso quel vecchio snapshot abbandonato…
Magia! La macchina che ospita il database server ha ripreso a volare e pian piano ho rimesso a posto tutti i servizi e i layer che avevo smontato per fare troubleshooting.
A te gli snapshot (sempre siano benedetti) hanno mai creato problemi?
Purtroppo VMware ha ragione: gli snapshot sono utili, ma rappresentano un vero pericolo. Proprio ieri sono rimasto bloccato con una macchina virtuale, dal cliente, perché il disco che la ospitava si era riempito a causa dello snapshot che si era ingrandito enormemente in poco più di due mesi. Inoltre per rimuoverlo ha impiegato varie ore, con evidente e sgradito disappunto da parte del cliente, perché l’operazione richiede lo spegnimento della macchina! Gli snapshot sono un potente strumento quando fate manutenzione, ma toglieteli appena possibile, prima che si incrementino troppo. Adriano
Sì Adriano, concordo.
Usare gli snapshop richiede cautela 🙂
In effetti il delta file delle snapshot sono insidiosi e dimenticarseli può davvero diventare un problema. C’è da dire che il decadimento delle performance a livello VM spesso dipende dalla qualità e dalle funzionalità messe a disposizione dallo storage. I più recenti storage che supportano la tecnologia VAAI o, per essere proprio all’ultimo grido, gli storage che operano la snapshot a livello array, permettono di gestire le snapshot delle VM in modo da minimizzare il decadimento delle performance.
Ovviamente questo genere di storage tende a costare, non è quindi detto che i provider cloud che lavorano molto sul "prezzo" adottino simili tecnologie… è sicuramente più facile adottarle nel provate cloud o con l’ausilio di System Integrator specializzati.
Non sapevo di questi storage "ottimizzati per gli snapshot": buono a sapersi!
Grazie per l’acuta osservazione.