[ImoLUG] Progetto "segretissimo" sulle macchine virtuali

[Mario Giammarco]

Il giorno 20 novembre 2009 17.17, fRANz <andrea.francesconi@gmail.com> ha
scritto:

> 2009/11/20 Mario Giammarco <mgiammarco@gmail.com>:
>
> ho come l'impressione che questo sarà un thread interessante :-)
>

Credo anche io ;-)

>
>
>
> l'idea è quella, anche se l'interesse principale è verso la
> scalabilità dell'infrastruttura (se _domani_ devo lanciare una nuova
> campagna di marketing devo poter raddoppiare/triplicare _oggi_ le
> capacità dei miei webserver e di tutti i servizi correlati per
> ripristinarli _dopodomani_)
> in tempi rapidissimi a costi accessibili
>
>
Credo (leggendo anche dopo) che i nostri casi d'uso si diversifichino un po'
anche se gli obiettivi alla fine sono simili in quanto desideriamo
raggiungere comunque una soluzione piu' "open" possibile.

Magari e' il caso di esplicitare qualche caso d'uso:

- esempio (reale): cliente X si rende conto di avere bisogno di un
firewall/nas/cms. Cliente X taccagno (tutti a me...) vuole spendere poco e
-sopratutto- non vuole comprare nuovo hardware. Ha un server windows ultra
pompato inutile per quello che fa al momento (misero programma di gestione
contabilita' non sql).
Soluzione (sbagliata): cercare un firewall/cms installabile su windows,
studiarselo e installarglielo. Sbagliata perche': non voglio imparare ad
usare windows e molti firewall/cms/etc./ per windows sono closed e a
pagamento.
Soluzione (migliore?): installo vmware server e deployo firewall e/o cms
gia' semi-configurati. Gli faccio pagare solo il tempo di configurazione
finale.

- inserire altri casi d'uso




> [...]
>
> > Problemi irrisolti:
> > - ogni virtualizzatore ha un formato di macchina virtuale incompatibile
> con
> > gli altri
>
> difficile fare i conti con _tutti_ i brand. sposane uno e vivi felice
> (la fascia dei prodotti con supporto enterprise è piuttosto ridotta,
> sempre se vuoi affrontare i problemi insieme al vendor per dare
> qualche garanzia in più)
>
>
Mi spiego meglio: un conto e' il virtualizzatore un conto e'
l'infrastruttura di cloud che c'e' sopra. Per esempio openqrm si crea al
volo da solo le macchine virtuali unendo un suo kernel ad un filesystem a
mia scelta. Quindi in openqrm non posso usare ne' le macchine gratuite gia'
pronte di turnkey linux ne' esportarle in un altro formato se un giorno
dovessi scoprire che openqrm non va piu' bene.



> > - nel caso si voglia offrire una soluzione scalabile (anche nel senso di
> > velocita' di configurazione di un datacenter) cosa uso?
> > openqrm,opennebula,abiquo,eucalyptus o altri?
>
> dipende strettamente dalla scelta fatta sopra
>
> Si ma chi mi aiuta a fare ste scelte?? ;-) ;-) ;-) ;-)


> considerazione: siamo certi che preparare dei template di vm da dare
> ai clienti sia un obiettivo perseguibile in termini di tempo e
> risorse?


Nel mio caso d'uso di sopra sta cosa torna. Facciamo qualche caso d'uso di
infrastrutture complete automatiche poi ne riparliamo.


> se tanto mi da tanto, per quanto riguarda le distro ogni 6-8
> mesi hai fuori una nuova release, per non parlare dei CMS che hanno
> tempi ancora più brevi. e qundi altro giro altro regalo: nuovo
> template.
> non è forse più produttivo collaudare uno 'scenario***' template da
> applicare poi sulla realtà it del cliente, con ogni probabilità
> diversissima da cliente a cliente?!
>

Mi sfugge sta cosa dello scenario... alludi a qualcosa del tipo chef/puppet?
Mi ero dimenticato di specificarli assieme ai gestori cloud di cui sopra!

>
> 'scenario***' = insieme delle configurazioni dei svariati demoni, best
> practices sulla configurazione di CMS ed integrazione tra loro (magari
> in modalità SaaS?), directory services che giocano tra loro in
> armonia, bla bla bla
> quindi diventerebbe lo 'scenario***', a questo punto, _segretissimo_
> :-) (e probabilmente rivendibile, perchè no... l'immaginazione non ci
> manca!)
>

Rivendere una cosa riduce a zero i costi di sviluppo e mantiene il fatturato
-> ottima cosa!
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.linux.it/private/imolug/attachments/20091120/bc75574a/attachment.htm>