Seeweb Cloud Hosting: ecco i dettagli del servizio e della piattaforma di cloud hosti

[Redazione Hosting Talk 10]

Abbiamo parlato a lungo della soluzione di Seeweb, la prima compagnia italiana che si è "immersa" nel cloud computing, con due prodotti differenti e uno in lancio nei prossimi mesi, come ci ha detto qualche settimana fa il CEO Antonio Baldassarra.

 

 

 

Leggi il resto dell'intervista: Seeweb Cloud Hosting: ecco i dettagli del servizio e della piattaforma di cloud hosting

[guest 16]

Io sinceramente non ho capito.

Perchè creano un container VZ dentro una domU Xen?

A che serve in container, in questo caso, oppure, che vantaggi ha metterci

sopra un layer aggiuntivo come Xen.

 

Non capisco in che modo abbiano legato le due cose e sopratutto perchè.

 

Ci sono dettagli in merito?

[Antonio 18]

Io sinceramente non ho capito.

Perchè creano un container VZ dentro una domU Xen?

A che serve in container, in questo caso, oppure, che vantaggi ha metterci

sopra un layer aggiuntivo come Xen.

 

Non capisco in che modo abbiano legato le due cose e sopratutto perchè.

 

Ci sono dettagli in merito?

 

Lo fanno solo con il nodo web per far condividere CPU/RAM a più utenti, in maniera tale da assorbire picchi improvvisi e fare un uso migliore delle risorse a disposizione.

 

La VM in cui è presente VZ ha 4vCPU e 4GB di ram se ricordo bene.

Edited May 7, 2010 by Antonio

[guest 16]

Si ma continuo a non capire.

Non si poteva mettere VZ su un nodo fisico piuttosto che fare la doppia virtualizzazione?

 

A che serve Xen allora?

[Antonio 18]

Si ma continuo a non capire.

Non si poteva mettere VZ su un nodo fisico piuttosto che fare la doppia virtualizzazione?

 

A che serve Xen allora?

 

Probabile che la gestione dell'HA (ed del futuro disaster recovery) la facciano a livello di XEN e non volevano ambienti eterogenei.

Edited May 8, 2010 by Antonio

[DonChisciotte 59]

forse faccio una domanda stupida, ma cosi' facendo (VZ su Xen) non si hanno perdite prestazionali?

 

ciao

[Antonio 18]

forse faccio una domanda stupida, ma cosi' facendo (VZ su Xen) non si hanno perdite prestazionali?

 

ciao

 

Claro che sì, ma quel 3% di performance che perdi saranno bilanciate sicuramente da benefici di gestione dell'infrastruttura :)

 

Sto testando il servizio di cloud server (per metà maggio penso vedrete la rece) ed il fatto che il nodo web non sia una istanza xen dedicata ad un solo cliente ti permette di assorbire picchi anche importanti.

 

Saggia decisione quella di aver usato VZ per i nodi web, l'unico dubbio è quello sollevato da Alessandro nel post precedente (perché VZ in XEN).

[guest 16]

Umh, è probabile che allora abbiano una infrastruttura sottostante pensata su Xen, quindi dialogano in maniera omogenea con tutti i nodi, poi, per gestire i picchi al meglio, sui domU Xen dedicati al web gli piazzano sopra VZ, in modo da poter far sforare la gente in caso di picchi.

 

Ad esempio un domU da 16GB con dentro alcuni container con 1GB di ram ma con ben 2GB di burst. Io garantisco il giga, però nel caso il tuo container avesse un picco potresti essere in grado di arrivare fino a 2GB (sempre che non ci siano altri container sotto forte carico)

 

Però siamo in overselling qui...

[Antonio 18]

Umh, è probabile che allora abbiano una infrastruttura sottostante pensata su Xen, quindi dialogano in maniera omogenea con tutti i nodi, poi, per gestire i picchi al meglio, sui domU Xen dedicati al web gli piazzano sopra VZ, in modo da poter far sforare la gente in caso di picchi.

 

Ad esempio un domU da 16GB con dentro alcuni container con 1GB di ram ma con ben 2GB di burst. Io garantisco il giga, però nel caso il tuo container avesse un picco potresti essere in grado di arrivare fino a 2GB (sempre che non ci siano altri container sotto forte carico)

 

E' quel che ho spiegato io in precedenza :emoticons_dent2020: (anche se esiste il balooning anche su xen, quindi non credo sia stato usato VZ solo per quel motivo).

 

Però siamo in overselling qui...

 

Non è overselling, perché loro non ti garantiscono nulla a livello di ram/cpu (ricordiamoci che è cloud hosting, non cloud server); la cosa è fatta per permetterti di attutire eventuali picchi.

 

Semplicemente per ogni XXX SPU hanno dei profili di ram/cpu minimi dedicati all'istanza, ma, non essendoci hard limit, se in un determinato istante hai un picco di visitatori, puoi usufruire di un quantitativo di ram/CPU superiore a quello "standard".

 

Ovvio che se inizi a dedicare XXXX SPU solo al nodo web bilanciano il carico e non ti permettono di soffocare gli altri clienti.

 

Ho provato anche a chiedere l'algoritmo col quale calcolano l'uso delle SPU, ma (ovviamente) la risposta non è stata esauriente :stordita:

Edited May 8, 2010 by Antonio

[guest 16]

Il balooning non sono troppo sicuro che sia presente su XenServer.

Vediamo un po:

 

# xe vm-param-list uuid=81c99a5d-abd0-1ad3-f0bb-ec7e1097e4e2 | grep memory | egrep -v 'boot|reco'
                memory-actual ( RO): 8589934592
                memory-target ( RO): 8589934592
            memory-static-max ( RW): 8589934592
           memory-dynamic-max ( RW): 8589934592
           memory-dynamic-min ( RW): 8589934592
            memory-static-min ( RW): 16777216
                       memory (MRO): 

 

Umh, forse si, ma non l'ho mai usato.

 

EDIT: ovviamente per XenServer intendo Xen di Citrix no XenSource.

 

EDIT2: ma in pratica cosa hanno fatto, han preso un server fisico, gli han creato una singola istanza Xen e dentro tale istanza ci creano un container per ciascun cliente?

Edited May 8, 2010 by guest