I come Informatica - I como Informática - I for Information Technology
PORTALE PORTAL PORTAL	FORUM FORO FORUM	Informatica Informática Information Technology	Stefano Pederzani Consulente informatico	ARTE	Homepages	Curricula Curricula Resumes	Pubblicità Publicidad Advertisement

Niente cluster, siamo inglesi

Tanti buoni motivi per NON fare un cluster. Di Stefano Pederzani

Spesso il tema del cluster salta fuori quando meno ve lo aspettate. In genere si sta progettando un nuovo server, magari una migrazione, una separazione in due di una macchina che fa troppe cose, per qualche motivo qualcuno non ha escluso la cosa a priori. Ci si trova in una stanza, tante persone a parlare del futuro... ed eccolo lì, un'altra volta.
"Beh, questo poi sarà un CLUSTER, VERO????"
Silenzio di tomba.
Le facce si fanno serie, e i musi si allungano verso il basso. L'entusiasmo scende sotto il pavimento.
Se siamo fortunati c'è qualche sistemista più pronto degli altri che si affretta a negare con una scusa qualsiasi:
"NO, perché {nome_del_dirigente} ha detto che {non ci sono i soldi|non possiamo perché non funziona con la versione nuova|il gatto è nervoso e potrebbe graffiarti}, quindi sarà un server normale."
Eppoi, all'aumentare della perplessità del proponente, sempre il sistemista pronto sarà svelto ad aggiungere, con un sorriso compiaciuto da enorme soddisfazione:
"Ma avrà il nuovo processore {nome_del_nuovo_processore}, {numero_GB_RAM} di RAM ed un sacco di dischi velocissimi."
OK, due colpi assestati, ma non basta ancora. A questo punto non manca che il terzo: quello decisivo. Spostare l'attenzione sul problema pi� grosso del progetto, quello che riempie la mente e non lascia spazio all'argomento precedente perché richiede la massima concentrazione. "Dobbiamo ancora trovare un sito per il disaster recovery del DB server.", ad esempio.
BEM!
È fatta. Equivale ad averlo preso a bastonate, quello che ha proposto il cluster.
Ma la realtà spesso non è così rosea, e il tarlo del dubbio buttato lì come fosse a caso, in realtà ha un fondamento progettuale, non scritto, ma ce l'ha. E qualcuno, parlando in privato in una stanza chiusa, magari mentre prendevate il caffé, ha trovato i soldi e lo vuole fare. Lo vuole tanto.

Il punto di vista del sistemista

Cominciai a lavorare sui server in una grigia e polverosa sala macchine al piano interrato nel lontano 1995... No, non vi farò qui la storia della mia vita, ma mi limiterò ad esporre il mio punto di vista: quello del sistemista.
Quando iniziai, i cluster non esistevano, bei tempi! Ogni tanto si inchiodava un server e tutti pendevano dalle nostre labbra, perché noi sistemisti dovevamo farli ripartire. In quel periodo ero molto amato. Vorrei insinuare che per chi non fa il sistemista, il cluster è una buona ragione per non pendere da queste labbra... E invece dovete! Anche se i server non si fermano più così spesso come una volta.
Si è cominciato con il mirroring dei dischi, prima sui server più importanti, poi, piano piano, anche su tutti gli altri. Poi hanno cominciato a chiamarlo RAID, e a quel punto era oramai diventato un must. Sono d'accordo.
Le macchine sono diventate tutte multiprocessore, anche quelle medio-piccole alle quali ho dedicato gran parte della mia carriera. I singoli processori sono oggi tutti multicore, e non credo che qualcuno abbia il timore di rimanere senza processori per un guasto.
Nel frattempo la RAM ha cominciato a rompersi. Negli anni '90 non si guastava mai. Dopo, invece, ha cominciato a causare dei bei problemi, che non stiamo qui a trattare; ma anche quella è composta di tanti banchi, ed il sistema sa come isolare quello guasto, accendere una bella lucina rossa, ed aspettare che il sistemista indovini di cosa si tratta.
Insomma, quello che sto dicendo è che la ridondanza abbonda da ogni punto di vista. Io ci metterei dentro anche quei bellissimi servizi formati da più application server in load balancing, sempre che il load balancer non risieda proprio sull'unico application server che si inchioda per qualche motivo.
Parlare di cluster per chi non ci deve lavorare è molto semplice. Ma chi lo deve mettere in opera deve fare il triplo del lavoro! E questo soltanto perché ogni tanto, forse ogni mai, il server con la tanto preziosa applicazione... potrebbe... Oddio! Fermarsi? Ma io mi sparo! E chi lo dice all'utente! Aiuto!!!
Insomma per le paranoie di chi sistemista non è, e nemmeno si rende conto di cosa sta parlando.
Ebbene nella mia lunga e onorata carriera, posso assicurarvi che il numero di fermi imprevisti su di un server che NON sia un cluster è bassissimo, tendente allo zero. Mentre quello dovuto a riconfigurazioni del cluster è in media di 2-3 volte l'anno, e vi assicuro che non sono programmate più della metà.
Esatto, avete capito bene: un servizio in cluster ha in media blocchi imprevisti maggiori di server singoli.

Il punto di vista del dirigente

Spesso i dirigenti hanno attriti politici con altri dirigenti, i quali fanno di tutto per trovare difetti nei progetti proposti dal CTO. Magari si tratta di attriti tra capufficio tutti all'interno del settore informatico. Non cambia molto.
Per un dirigente, mettere in clustering un servizio fa fico, ed è un fiore all'occhiello.

Il punto di vista del commerciale

A lui che gliene frega? Il commerciale vende servizi ed è abituato a fare sconti. Magari il clustering sul servizio, al cliente glielo regala! No, adesso sto esagerando, ma è vero che non ci si rende conto del costo in termini di servizi e di risorse umane.

Il costo ed il prezzo del clustering

Ne vogliamo parlare?
Allora facciamo un rapido conto. Diciamo che 100 è il costo di un server singolo in termini di progettazione, installazione, configurazione, installazione del software, deployment, test, collaudo e produzione.
Tralasciamo migrazione, dismissione e riciclo, per il momento.
Diciamo che il cluster che andremo a costruire semplicemente è composto da due macchine uguali che erogano lo stesso servizio insieme, quindi un cluster "a due nodi attivi".
Aggiungiamo 100 per il secondo nodo. Somma: 200. Aggiungiamo il software di clustering ed i consulenti o il lavoro in più per i sistemisti per configurarlo e mantenerlo in piedi. Ancora 150, ad essere magnanimi. Somma: 350.
Fin qui abbiamo speso il 350% per clusterizzare un servizio che avrebbe funzionato benissimo anche senza.
Ora cominciamo a parlare della sua manutenzione. Quando si parla della "manutenzione" si tende a pensare che un cluster ci venga incontro. "ecco che mi ripago un po' di soldi spesi", si pensa. Mentre spengo un nodo, il servizio continua ad essere erogato, ed evito un fermo. E però salta fuori che per fare l'upgrade del software bisogna farlo su tutti e due i nodi, perché non posso far funzionare il clustering su due nodi con versioni diverse di software. E così per il firmware di questo o di quel componente. Ed il software del cluster?
Ma sto spendendo il 350% in più anche per la manutenzione???

tanti buoni motivi per NON fare un cluster. di Stefano Pederzani A quanto viene venduto un servizio in clustering rispetto ad un server singolo? Al doppio? Cominciamo a venderlo al quadruplo, e vediamo se il cliente comincia a rendersi conto di quanto si spende a farlo.

Obiezioni frequenti

Avrete notato che i miei discorsi hanno un sapore un po' antico. Oggi esiste la virtualizzazione, la paravirualizzazione, ed il cloud.
Ma è difficile affrontare tematiche così complesse se prima non si espongono, come ho fatto io, i concetti basilari.

• La virtualizzazione.
  In ambiente di macchine virtualizzate si hanno vantaggi dovuti alla clonazione dei nodi, molto utile in questo caso. Il clustering può essere una feature del software di virtualizzazione e semplificarci ulteriormente il lavoro. Tenete conto però del costo di licenza di tale feature quando andate a fare il conto. Su VmWare© il costo di un clustering può scendere al 300%.
  Nessuno regala niente.
• La paravirtualizzazione.
  In ambienti paravirtualizzati, ossia dove l'hardware è costruito per condividere risorse (ad esempio: System P© di IBM, (Oracle©) Sun Microsystems o macchine con Xen) si tende più che altro ad avere best practice per la clusterizzazione, più che avere un vero e proprio aiuto. Su System P© di IBM si usa infatti HACMP come se si trattasse di macchine fisiche totalmente separate. Nessun calo dei costi, a mio avviso, rispetto al 350%.
• Cloud.
  Ecco, qui le cose cambiano. Il punto di vista del cloud è totalmente avulso dalla struttura che lo supporta, perché abbiamo il modello dell' *-as-a-Service.. Volete il caffè? Coffe-as-a-Service. Volete il pranzo? Lunch-as-a-Service, e via dicendo.
  Ci sono tanti server che hanno tutte le loro ridondanze ed i loro clustering in un stanza ignota di una ignota località chissà dove, che fanno tante cose, tutte insieme. Tra le altre, erogano il vostro servizio.
  Tenete presente che in genere quando si scende da un Saas (Software-as-a-Service) ad una PaaS (Platform-as-a-Service) e fino ad una IaaS (Infrastructure-as-a-Service), non cambia molto per il provider, che comunque al massimo vi fornisce macchine virtuali.
  Qui il costo non cambia molto dopo che si è deciso il servizio, ma è molto alto all'inizio e tutti i paragoni di cui sopra non si applicano. Il cloud richiede enormi investimenti, alta specializzazione dei tecnici del provider, ed in Italia stenta a prendere piede. E non parlatemi di digital divide, perché non è la velocità della rete a frenare il suo utilizzo, ma al massimo la velocità del cliente ad adattarsi, mente e macchine.

Di Stefano Pederzani. Bologna, dicembre 2013

I come Informatica - I como Informática - I for Information Technology
Vai al PORTALE - Ir a el PORTAL - Go to PORTAL	Stefano Pederzani Consulenze informatiche Bologna	Automatic barriers and access control Barriere stradali e controllo accessi	MMS IMPIANTI Cablaggio strutturato - telefonia Elettricità - climatizzazione