Il cloud è nato come alternativa economica all'hosting, ma poi si è scoperto che era una fregatura sotto questo punto di vista.

L'altra idea era quella di avere un uptime del 100%, migrando le macchine virtuali all'occorrenza.

C'era poi l'idea di dispiegare i contenuti su più macchine fisiche in differenti continenti, per diminuire le latenze.

Nessuno implementa tutto questo in realtà e alla fine della fiera si arriva ad avere un hosting su un vps che, ogni tanto, migra su qualche altro server fisico.

Imho, se vuoi usare il cloud, prendi un vps ( li chiamano cloud server ) e non un cloud hosting.

Rimane però un grandissimo problema ed è quello della gestione dei database, i quali sono difficilissimi da implementare con il cloud e, in molti casi, sono implementati su server diversi da quelli usati per il cloud ( perdendo quindi tutte le proprietà del cloud ).

Ciao paolini,

in che senso erano delle fregature? Potresti spiegarti meglio? Io sto seguendo la cosa del cloud per meglio dire del private cloud. La mia intenzione è quella di avere il mio cloud dove ci faccio quello che voglio. Tipo crearmi il mio sito internet e altre cosette. Ma in che senso dici che è una fregatura il fatto dell hosting? In che senso? Non capisco.

@filosofomatto said:

in che senso erano delle fregature? Potresti spiegarti meglio? Io sto seguendo la cosa del cloud per meglio dire del private cloud.

Originariamente il cloud fu pubblicizzato come un qualcosa che faceva risparmiare un mucchio di soldi rispetto al classico hosting/vps/dedicati.

Mostrano in effetti prezzi stracciati, ma sono ad ore e pay as you go. Cioè vuoi più cicli cpu? Paghi un tot in più. Vuoi quel giga in più di banda? Paghi un altro tot.

Facendo un confronto tra il costo delle risorse che servono per far girare un sito e il corrispettivo costo di un hosting tradizionale, si scopre che il cloud costa di più.

Ovviamente non tutti i casi sono simili e i prezzi del cloud dipendono moltissimo dalle economie di scala e da quanto efficiente è l'infrastruttura messa in opera dai vari provider. Rivolgendosi ad Amazon, probabilmente, si risparmia pure qualcosa e si hanno vantaggi tecnici anche importanti.

L'altro dilemma riguarda i database sql, che hanno difficoltà ad essere implementati in un'infrastruttura cloud. Molti provider hanno deciso semplicemente di mettere i dbms su altri server, ma ovviamente si perdono tutti i vantaggi del cloud ( tipo la replicabilità, la migrabilità delle vm, la possibilità di posizionare le vm geograficamente vicino agli utenti, ecc... ).

Imho il cloud va valutato per quelle situazioni in cui è fondamentale gestire un'elevatissimo numeri di operazioni cpu intensive e laddove è necessario distribuire contenuti statici con latenze minime ( ma in quest'ultimo caso si tratta di una cdn, che alcuni provider offrono in accoppiata al cloud ).

Se un sito fa uso pesante di database ( come molti siti ), diventa problematico valutare il vantaggio del cloud, a meno di optare per un database nosql ( modificando ovviamente tutta la parte che gestisce i dati ).

scusa Paolino ma per i database secondo me valgono le stesse regole dell'hosting. Si possono mettere sul cloud anche quelli. Ormai da tempo l'hosting e il db non stanno sulla stessa macchina e se ben implementati non ci sono problemi di latenza .

Probabilmente in Italia i cloud hanno più senso di esistere come cloud privati , all'interno della propria azienda considerate le problematiche delle linee adsl in questo paese ma nel resto del mondo ormai la connettività non è più un problema

@ManInJeans said:

scusa Paolino ma per i database secondo me valgono le stesse regole dell'hosting. Si possono mettere sul cloud anche quelli. Ormai da tempo l'hosting e il db non stanno sulla stessa macchina e se ben implementati non ci sono problemi di latenza .

Ovviamente li puoi vendere inclusi nel pacchetto cloud, ma non integrati nell'infrastruttura cloud.

I dbms sql soffrono di problematiche relative alla replicazione dei dati e alla loro sincronizzazione in tempo reale ( cosa necessaria per il cloud ).

Qualche anno fa c'è stato un accesso dibattito a riguardo, tra chi bollava il cloud come utile proprio per questo motivo e chi chiedevo la sostituzione dei dbms sql con dbms nosql ( che invece sono integrabili nelle infrastrutture cloud ).

Ad oggi, chi prende un host cloud, compra anche l'accesso ad un dbms. Solo che il dbms gira su server separati rispetto a quelli dedicati al cloud e non gode di tutte le proprietà del cloud.

ok . Il discorso mi torna ma mi chiedo se questo valga solo per i cloud pubblici o anche per i cloud privati.
Io ho un'infrastruttura cloud privata realizzata con vari nodi hyper-v tutti all'interno della stessa sede . Secondo te soffrirei del problema della replicazione dei dati nei vari dbms sql anche in una lan interna ? Anche se gli host sono collegati in fibra ?

@ManInJeans said:

ok . Il discorso mi torna ma mi chiedo se questo valga solo per i cloud pubblici o anche per i cloud privati.
Io ho un'infrastruttura cloud privata realizzata con vari nodi hyper-v tutti all'interno della stessa sede . Secondo te soffrirei del problema della replicazione dei dati nei vari dbms sql anche in una lan interna ? Anche se gli host sono collegati in fibra ?

Si, il problema è tecnico non politico o commerciale. I dbms sql semplicemente non possono sincronizzare in tempo reale varie istanze, per cui bisogna metterli fuori dal cloud ( per così dire ).

Proprio a causa di questo problema, i dbms nosql ( snobbati per decenni ) stanno godendo di un boom nell'interesse da parte degli utenti.

Ciao Paolino,

interessante e giusto quello che dici. Penso però che Microsoft ad esempio stia compiendo dei grandi passi in avanti in questo senso. Guarda la nuova technologia private cloud con il System Center 2012.

Con il system center 2012 hai tutto in uno anche il db SQL Server.
Fammi sapere se hai avuto esperienze in merito.

Ciao e grazie

In quel caso si tratta semplicemente di un'interfaccia per centralizzare l'amministrazione di tutte le infrastrutture del cloud.

Però rimane sempre il problema di come riuscire, ad esempio, a creare alla bisogna una nuova istanza del dbms e fare in modo che i dati che legge/scrive siano sincronizzati.

Fino ad ora solo mysql e postgresql hanno affrontato il problema, trovando soluzioni quasi accettabili. Ma la formula magica, in quest'ambito, non esiste. A meno di usare database nosql ovviamente.

Tecnicamente il problema è direttamente legato alla non parallelizzabilità dei workload. Cioè, inserisco un nuovo record nel db e voglio ( ovviamente ) che siano rispettate le proprietà acid e quel nuovo record sia presente in tutte le repliche/istanze del db.

Ma come faccio a verificare questa condizione se ho 4 istanze dello stesso db che girano su 4 macchine, magari piazzate in 4 diverse parti del mondo? Dovrei farle comunicare tutte? E allora sto riserializzando il tutto, quindi ho eliminato uno dei vantaggi del cloud. E se l'istanza master va in crash? Va in crash tutto il db e quindi addio fault tolerance del cloud.

Motivo per cui i db nosql ( che se ne fregano delle proprietà acid ) sono l'unica soluzione in ambito cloud. Ovviamente perdere tali proprietà non è sempre accettabile e quindi va valutato il contesto prima di decidere.

I grandi provider cloud stanno semplicemente fornendo il cloud, accoppiato ad una classica infrastruttura cluster per i dbms transazionali.

In soldoni il problema principale è la scalabilità, ovvero aggiungo più istanze del mio cloud host/server ma il dbms non cresce in termini di performance. Come ho detto, ci stanno provando mysql e postgresql, ma la soluzione proposta è di avere una gestione centralizzata delle scritture e tante repliche in sola lettura. In questo modo si scala in lettura, ma chi diavolo usa un dbms per leggere solamente? L'esperienza c'insegna che si fanno tot letture e, almeno, altrettante scritture.

Alla fine si tratta di palliativi e poco più.

Però capiamoci bene!!! Non sto dicendo che il cloud fa pena. Il cloud mantiene intatti tutti i suoi vantaggi nel trattamento dei contenuti statici e nell'esecuzione di script ( quindi processi cpu-bound e network-bound ). Solamente non bisogna sperare che automagicamente questi vantaggi vengano trasmessi pure ai dbms.

Pensate a megavideo ( il fu megavideo ). Loro offrivano al 90% contenuti statici e avevano spike di traffico a seconda delle ore della giornata. Il tipico caso in cui il cloud è la scelta più azzeccata. Loro inserivano un video e questo veniva visto migliaia di volte. Chiaramente il servizio era tutto spostato verso le letture piuttosto che verso le scritture.

@paolino said:

In quel caso si tratta semplicemente di un'interfaccia per centralizzare l'amministrazione di tutte le infrastrutture del cloud.

Però rimane sempre il problema di come riuscire, ad esempio, a creare alla bisogna una nuova istanza del dbms e fare in modo che i dati che legge/scrive siano sincronizzati.

Fino ad ora solo mysql e postgresql hanno affrontato il problema, trovando soluzioni quasi accettabili. Ma la formula magica, in quest'ambito, non esiste. A meno di usare database nosql ovviamente.

Tecnicamente il problema è direttamente legato alla non parallelizzabilità dei workload. Cioè, inserisco un nuovo record nel db e voglio ( ovviamente ) che siano rispettate le proprietà acid e quel nuovo record sia presente in tutte le repliche/istanze del db.

Ma come faccio a verificare questa condizione se ho 4 istanze dello stesso db che girano su 4 macchine, magari piazzate in 4 diverse parti del mondo? Dovrei farle comunicare tutte? E allora sto riserializzando il tutto, quindi ho eliminato uno dei vantaggi del cloud. E se l'istanza master va in crash? Va in crash tutto il db e quindi addio fault tolerance del cloud.

Motivo per cui i db nosql ( che se ne fregano delle proprietà acid ) sono l'unica soluzione in ambito cloud. Ovviamente perdere tali proprietà non è sempre accettabile e quindi va valutato il contesto prima di decidere.

I grandi provider cloud stanno semplicemente fornendo il cloud, accoppiato ad una classica infrastruttura cluster per i dbms transazionali.

In soldoni il problema principale è la scalabilità, ovvero aggiungo più istanze del mio cloud host/server ma il dbms non cresce in termini di performance. Come ho detto, ci stanno provando mysql e postgresql, ma la soluzione proposta è di avere una gestione centralizzata delle scritture e tante repliche in sola lettura. In questo modo si scala in lettura, ma chi diavolo usa un dbms per leggere solamente? L'esperienza c'insegna che si fanno tot letture e, almeno, altrettante scritture.

Alla fine si tratta di palliativi e poco più.

Però capiamoci bene!!! Non sto dicendo che il cloud fa pena. Il cloud mantiene intatti tutti i suoi vantaggi nel trattamento dei contenuti statici e nell'esecuzione di script ( quindi processi cpu-bound e network-bound ). Solamente non bisogna sperare che automagicamente questi vantaggi vengano trasmessi pure ai dbms.

Pensate a megavideo ( il fu megavideo ). Loro offrivano al 90% contenuti statici e avevano spike di traffico a seconda delle ore della giornata. Il tipico caso in cui il cloud è la scelta più azzeccata. Loro inserivano un video e questo veniva visto migliaia di volte. Chiaramente il servizio era tutto spostato verso le letture piuttosto che verso le scritture.

Ciao paolino,

pensi quindi che il problema del database potrebbe essere un deterrente per le aziende a migrare sul cloud?

Quindi per la sola lettura va benissmo mentre per la scrittura e lettura contemporanea no? Devo informarmi su questa cosa. Certo che questo è un aspetto che non avevo preso in considerazione.

E come ovviare quindi a questa cosa? Aspettare ancora o cercare di implementare qualcosa che possa ovviare a questo problema?

@filosofomatto said:

pensi quindi che il problema del database potrebbe essere un deterrente per le aziende a migrare sul cloud?

se ottengono altri vantaggi non vedo perchè

un'azienda non si fa problemi ad avere un dbms separato dall'infrastruttura cloud

@filosofomatto said:

Quindi per la sola lettura va benissmo mentre per la scrittura e lettura contemporanea no?

per il semplice motivo che, date N repliche del db sincronizzate tra loro, puoi ovviamente leggere da ognuna di esse in parallelo

@filosofomatto said:

E come ovviare quindi a questa cosa? Aspettare ancora o cercare di implementare qualcosa che possa ovviare a questo problema?

non ci sono modi a prova di bomba per ovviare a questo problema

il problema rimane e ci si convive, come avviene con tanti altri limiti imposti dalla tecnologia corrente

cercando di documentarmi sul'argomento ho trovato questo link ( community.ugiss.org/blogs/dmauri/archive/2009/03/19/ssds-sql-server-on-the-cloud.aspx ) in cui viene proposta questa soluzione della Microsoft che , utilizzando questo SSDS , sembra superare le problematiche dei classici RDBMS SQL .

Che ne pensi ?

Molto hype e pochi fatti intorno a questa fantomatica soluzione miracolosa. Comunque si tratta di un dbms nosql http://news.dzone.com/news/microsoft-ssds-dumb-name-brill&default=false&zid=159&browser=17&mid=0&refresh=0

Ce ne sono a vagonate di dbms del genere http://en.wikipedia.org/wiki/NoSQL

Ciao,

ma con la nuova technologia del System Center 2012 che sto installando sul mio pc, mi sembra che il problema comunque sia stato risolto! Al momento dell'installazione hai bisogno di un server sql server per il database per poi far funzionare il vmm (virtual machine manager).

Scusa ma non si poggia quindi il sistema sul suo sql server?
In che senso quindi dovrebbe utilizzare un dbms nosql?

Non capisco scusami se ribatto.

@filosofomatto said:

Ciao,

ma con la nuova technologia del System Center 2012 che sto installando sul mio pc, mi sembra che il problema comunque sia stato risolto! Al momento dell'installazione hai bisogno di un server sql server per il database per poi far funzionare il vmm (virtual machine manager).

Scusa ma non si poggia quindi il sistema sul suo sql server?
In che senso quindi dovrebbe utilizzare un dbms nosql?

Non capisco scusami se ribatto.

Quello che ho letto in giro per la rete ( c'è poco in verità ) su questo sistema della microsoft, è del tutto simile all'approccio adottato da postgresql.

Giustamente hai detto che creando una vmm devi disporre di un db sql. Il problema è se crei 10 istanze della stessa vmm che succede? Puoi creare altrettante istanze del dbms che però usano il medesimo database?

Allo stato attuale delle cose è impossibile, perchè richiederebbe un accesso concorrente in scrittura, il che impedirebbe l'enforcing delle proprietà acid.

Si potrebbe avere un processo dbms che è il master e gli altri sono slave. In questo caso tutte le operazioni verrebbero in qualche modo controllate dal master. Però, così facendo, stiamo dicendo che il master dovrà occuparsi di tutte le operazioni di scrittura ( quelle di lettura si possono fare in parallelo e senza problemi ). Quindi il vantaggio di avere tanti processi dbms in esecuzione quale sarebbe?

Col cloud hai 10 vps che girano su altrettanti server fisici, ma vedi un solo cloud server logico. Cioè quando l'utente chiede una pagina web viene indirizzato verso uno dei vps. Lo stesso avviene quando si eseguono script e programmi.

Ciò però è possibile perchè non c'è nessun vincolo d'integrità sui dati. Cioè se il vps 1 apre in scrittura un file, semplicemente quel file sarà inaccessibile a tutti gli altri vps finchè non verrà chiuso. Una volta chiuso, qualunque altro vps, potrà farci quello che vuole ( aprirlo, leggerlo, cancellarlo, scriverci sopra ).

Con i db sql, una simile "superficialità" porta alla corruzione dei dati.

Proprio a proposito di microsoft: "Microsoft SQL Server supports multiple instances of the SQL Server database engine running concurrently on the same computer. Each instance of the SQL Server database engine has its own set of system and user databases that are not shared between instances."

Ovvero, puoi benissimo far girare 10 istanze di sql server, ma non puoi fare in modo che tutte lavorino sullo stesso database. Invece il cloud è proprio questo genere di cose che fa.

Ciao Paolino,

penso che tu ti riferisca alla tradizionale applicazione single tier. Questo è proprio il punto. Con il nuovo System Center 2012 puoi creare applicazioni multi-tier e quindi condividere app, databases e risorse a tant'altro.

Credimi la cosa è molto più estesa di quanto pensi.

"VMM mette a disposizione per questo uno strumento di modellazione visuale per definire le specifiche hardware della virtual machine, le funzionalità del server, i ruoli da avviare, il codice prodotto etc."

In VMM sono state implementate inoltre altre due funzioni che sono le seguenti:

"Per garantire la continuità dei servizi VMM ha creato anche la Dynamic Optimization: capacità di collocare e spostare virtual machine su server diversi in base a carichi di lavoro e opzioni stabilite dal gestore del datacenter e anche la Power Optimization: capacità di spegnere server fisici liberi da compiti, risparmiando energia e inquinando di meno.
Per garantire l'alta affidabilità può creare e gestire cluster hyper-v".

"Un'applicazione infine, può essere distribuita sotto forma di servizio multi-tier. In questo caso vengono utilizzate più virtual machines, ognuna destinata ad un compito specifico. Una virtual machine per il database, una virtual machine per il web server, una per l'applicazione vera e propria, etc. Un servizio si può definire quindi come un gruppo di virtual machines, create all'interno della cloud, che lavorano insieme per garantire la distribuzione di un'applicazione secondo i principi di Cloud Computing. La creazione di un servizio si basa su dei modelli chiamati "Service Template".

"I Service Template permettono di astrarre le applicazioni e di raggrupparle in un contenitore logico composto da virtual machines, modelli di configurazione, applicazioni e tutto ciò che è necessario a creare l'infrastruttura hardware e software per un servizio e a servirlo ON-DEMAND agli utenti".

"Quando un utente ha bisogno delle funzionalità definite dal service template, viene creata un'istanza del servizio e resa disponibile nel private cloud."

"I service template si costruiscono direttamente in VMM attraverso il template designer, basato su un interfaccia Drag and Drop che permette di costruire i singoli modelli di servizio aggiungendo e configurando risorse".

"Definito il service template, l'applicazione può essere distribuita attraverso il portale self-service o su hosts specifici. Il portale che permette questa e diverse altre attività di self-service si crea con AppController".

"AppController è il completamento ideale di VMM. Sebbene non direttamente integrato nell'installazione di VMM, non è un software a parte anche dal punto di vista della licenza".

Cosa ne pensi?

@filosofomatto said:

VMM mette a disposizione per questo uno strumento di modellazione visuale per definire le specifiche hardware della virtual machine, le funzionalità del server, i ruoli da avviare, il codice prodotto etc.

ok, graficamente configuri la virtual machine

@filosofomatto said:

Per garantire la continuità dei servizi VMM ha creato anche la Dynamic Optimization: capacità di collocare e spostare virtual machine su server diversi in base a carichi di lavoro e opzioni stabilite dal gestore del datacenter

cioè quello che amazon fa da anni, ovvero load balancing e migrazione dinamica delle virtual machine

@filosofomatto said:

Power Optimization: capacità di spegnere server fisici liberi da compiti, risparmiando energia e inquinando di meno.

ok, se non mi serve la potenza di un certo server, lo spengo

@filosofomatto said:

Un'applicazione infine, può essere distribuita sotto forma di servizio multi-tier. In questo caso vengono utilizzate più virtual machines,

molto meno di quanto offerto da amazon e soci e questo perchè....

@filosofomatto said:

ognuna destinata ad un compito specifico. Una virtual machine per il database, una virtual machine per il web server, una per l'applicazione vera e propria, etc.

amazon è in grado di avere più vm su cui girano i medesimi servizi, programmi, siti web e, a seconda delle decisioni del loader balancer, le richieste vengono inoltrate ad una delle vm del pool

@filosofomatto said:

Un servizio si può definire quindi come un gruppo di virtual machines, create all'interno della cloud, che lavorano insieme per garantire la distribuzione di un'applicazione secondo i principi di Cloud Computing.

ovvero un servizio è costituito da N componenti e ognuna di queste componenti gira su una vm diversa

@filosofomatto said:

Quando un utente ha bisogno delle funzionalità definite dal service template, viene creata un'istanza del servizio e resa disponibile nel private cloud.

questo si avvicina un pò di più a quello che fa amazon, ma è ancora molto limitato

infatti, in questo caso, una vm corrisponde ad uno specifico utente, quindi è come una shell remota in cui si fa login e viene assegnato un terminale ad ogni utente

ma, dulcis in fundo, rimane il problema dei database e cioè io non voglio avere 5 vm su cui girano dbms, web server, server ftp, server mail e server dns

quello che si chiede ad un dbms scalabile è di riuscire a girare, in 10-20-1000 istanze, ma accedendo allo stesso database

questo è impossibile se si devono garantire le proprietà acid, perchè è impossibile evitare corruzione dei dati senza sincronizzare le scritture

microsoft ha realizzato una bella interfaccia centralizzata, in "stile policy group", ma non ha risolto il problema della scalabilità dei dbms relazionale

@paolino said:

ok, graficamente configuri la virtual machine

cioè quello che amazon fa da anni, ovvero load balancing e migrazione dinamica delle virtual machine

ok, se non mi serve la potenza di un certo server, lo spengo

molto meno di quanto offerto da amazon e soci e questo perchè....

amazon è in grado di avere più vm su cui girano i medesimi servizi, programmi, siti web e, a seconda delle decisioni del loader balancer, le richieste vengono inoltrate ad una delle vm del pool

ovvero un servizio è costituito da N componenti e ognuna di queste componenti gira su una vm diversa

questo si avvicina un pò di più a quello che fa amazon, ma è ancora molto limitato

infatti, in questo caso, una vm corrisponde ad uno specifico utente, quindi è come una shell remota in cui si fa login e viene assegnato un terminale ad ogni utente

ma, dulcis in fundo, rimane il problema dei database e cioè io non voglio avere 5 vm su cui girano dbms, web server, server ftp, server mail e server dns

quello che si chiede ad un dbms scalabile è di riuscire a girare, in 10-20-1000 istanze, ma accedendo allo stesso database

questo è impossibile se si devono garantire le proprietà acid, perchè è impossibile evitare corruzione dei dati senza sincronizzare le scritture

microsoft ha realizzato una bella interfaccia centralizzata, in "stile policy group", ma non ha risolto il problema della scalabilità dei dbms relazionale

Ciao Paolino,

puoi cercare questo argomento su google:

Transazioni distribuite per approfondire il tema per capire come riguardo l'aspetto ACID le transazioni vendono distribuite.

Ciao

Il risultato non cambia. Dal sito della microsoft

"Le transazioni distribuite sono estese a due o più server noti come strumenti di gestione delle risorse. La gestione della transazione deve essere coordinata tra i vari strumenti di gestione delle risorse tramite un componente server denominato gestore delle transazioni."

Ovvero, come dicevo, dev'esserci un'entità che coordina le operazioni ( almeno quelle di scritture ), altrimenti è impossibile evitare che due o più istanze del dbms collidano mentre operano sullo stesso database.