Spesso i termini Grid Computer e Cloud Computer sono utilizzati per identificare la stessa cosa: in realtà stiamo parlando di cose simili ma tecnicamente diverse.
Come spiegato da Rich Wolski del progetto Eucalyptus, differenziamo innanzi tutto lo scopo delle due modalità di cluster: dato un numero X di server fisici, un Grid Computer contiene al suo interno un numero di istanze minore o uguale ad X (ad esempio se ho 100 server fisici, il numero di istanze sarà 10, 50, 100… ma non di più); al contrario, in un Cloud Computer, il numero di istanze sarà sempre maggiore rispetto ad X (tornando all’esempio di prima, se faccio girare sui miei 100 server 200, 500, 1000 istanze).
Facendo questa premessa risulta evidente anche la differenza in termini di ingegnerizzazione del sistema che sta alla base del cluster.
In un Grid Computer il controller si occuperà prevalentemente di gestire la schedulazione delle operazioni, parallelizzandole ove possibile: difatti, nel caso del Grid Computing avremo poche istanze che girano contemporaneamente, però queste normalmente saranno estremamente esose di risorse e, pertanto, potrebbero richedere l’utilizzo esclusivo dell’hardware del sistema costringendo le nuove istanze a rimanere in attesa.
In un Cloud Computer, al contrario, abbiamo un gran numero di piccole istanze che girano contemporaneamente all’interno del cloud in real time e quindi non è possibile concepire un meccanismo di schedulazione delle stesse. Facendo un esempio con il servizio Cloud più conosciuto (Amazon EC2), un utente ha di base la possibilità di istanziare 20 VM contemporanee all’interno del cloud che condividono le medesime risorse Hardware. Quindi un simile sistema necessita di meccanismi di sincronizzazione e condivisione delle risorse diversi (e ovviamente più sofisticati) rispetto a quelli necessari per realizzare un Grid Computer.
Portando questa differenza astratta nella pratica, ci si accorge subito di quali rischi si possono incontrare quando si offre il servizio di cloud computing: gli strumenti attualmente disponibili che ci permettono di creare facilmente ed in maniera economica un sistema di cloud computing partendo da una manciata di server, rendono le cose talmente semplici che spesso si perde il controllo di ciò che è il reale utilizzo della propria infrastruttura. E’ facile, purtroppo, lasciarsi “prendere la mano” e istanziare un elevato numero di VM che, in caso di intenso utilizzo, arrivano a saturare l’infrastruttura Cloud; è necessario quindi mantenere un controllo sistemistico dello stato dell’infrastruttura, coadiuvandosi magari con l’utilizzo di sistemi appositamente concepiti quali Nagios e Ganglia, in modo da essere proattivi e agire con l’aggiunta di nuove risorse hardware prima che il sistema arrivi a saturazione.
[...] già detto in questo articolo, se il numero di processi istanziabili è minore del numero di nodi di calcolo si parla si grid [...]