Jump to content
Sign in to follow this  
Redazione Hosting Talk

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

Recommended Posts

Schermata 2010-02-14 a 16.56.59.thumbnail.png

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

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites
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 by Antonio

Share this post


Link to post
Share on other sites
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 by Antonio

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites

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...

Share this post


Link to post
Share on other sites
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 by Antonio

Share this post


Link to post
Share on other sites

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 by guest

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×