Newsgroup: it.comp.os.linux.sys
Titolo: OpenStack Swift

Possibile che qui dentro nessuno abbia usato Swift come storage?
Mi piacerebbe capire una cosa: si può usare Swift (e quindi un object storage) come storage per delle VM? Sembrerebbe che swift non sia pensato per questo scopo, tant'è che nemmeno OpenStack Compute lo supporta direttamente come datastore ma necessita di passare tramite Glance.
 
Ci son delle motivazioni valide oppure la documentazione non è precisa?
Perchè sotto molti aspetti Swift è migliore di Gluster (anche se ad un costo superiore)

 Glance.
 
Non c'entra direttamente con la domanda ma hai visto che:
 
 
http://www.gluster.org/community/documentation/index.php/About33
 
 
In particolare cito:
 
"Granular locking – Allows large files to be accessed even during 
self-healing, a feature that is particularly important for VM images."
 

 self-healing, a feature that is particularly important for VM images."
 
Si, conosco gluster.
Ma è la sua architettura che non mi soddisfa appieno.
E' un prodotto *fenomenale* ma ho paura che su grosse installazioni salti per aria. Se hai 100 server che devono leggere, avrai 100 server che si devono interfacciare direttamente con gli storage e conseguentemente gestiscono i bilanciamenti da soli.
 
Mi vien quasi l'idea di fare dei gateway che esportano in AoE o altro.
Il fatto di avere la gestione eseguita tutta dai client non mi convince più di tanto, i problemi diventano esponenziali in base al numero di server che accedono allo storage.

 server che accedono allo storage.
 
Concordo. Spero che con l'acquiszione da parte di RedHat diventi un 
prodotto sempre piů solido.
 
 

 prodotto sempre più solido.
 
Dubito ne cambino il funzionamento base. 
Significherebbe creare un altro prodotto.

 Mi piacerebbe capire una cosa: si può usare Swift (e quindi un object storage) come storage per delle VM? Sembrerebbe che swift non sia pensato per questo scopo, tant'è che nemmeno OpenStack Compute lo supporta direttamente come datastore ma necessita di passare tramite Glance.
 
Mi pare di capire che il concetto di "cloud" fornito da un server OpenStack sia differente da una normale VPS.
I dati, salvo configurazioni extra, non sono persistenti e si perdono quando il server viene spento.
 
Esempio:
http://docs.openstack.org/essex/openstack-compute/admin/content/images-and-instances.html
 
 
- un utente attiva un nuovo server basato su una determinata immagine/template
- Nova va a leggere tale immagine, la copia sui propri dischi in locale e la esegue a partire da li.
- Quando l'istanza viene terminata, i dati vengono persi
 
Nel caso si volesse avere uno storage persistente, l'applicazione che fa uso di tale server deve essere cloud-aware (e quindi sapere di dover salvare dati in un filesystem dedicato e non in giro per il sistema come si farebbe normalmente in un sistema non cloud), e dire a Nova di connettere un device a blocchi in aggiunta al filesystem di root (magari tramite GlusterFS, in modo da avere condivisione di dati tra più istanze)

 prodotto.
 
Spero vivamente che rimanga cos�. Intendevo che l'apporto di RedHat 
possa renderlo impiegabile in ambienti enterprise. La mia esperienza da 
sistemista si concentra soprattuo su RHEL, e quando occasionalmente ho 
dovuto usare ad esempio Centos e Debian-Derivate, non ho riscontrato lo 
stesso grado di solidit�.
 
 

 ma immagino che complicherebbe un po' il lavoro agli sviluppatori. 
 
...modo in cui viene gestita la ridondanza.
Attualmente è il client che vede una discrepanza tra server per il file al 
quale cerca di accedere e legge da un server e sincronizza sull'altro facendo
quindi transitare la replica tramite se stesso.
 
In ambienti complessi è molto probabile avere un backbone 10gbe/infiniband tra gli storage e magari solo gigabit tra i client. Questo perchè potresti avere 10 client che per sfiga devono leggere dallo stesso storage, quindi lato client 1gbit basta ed avanza, lato storage ti servono 10gbit
 
Se la replica è fatta dal client, nello stesso giga deve transitare sia la lettura del file, sia la sua scrittura. Credo sia meglio far fare tutto al server. Il client, tramite una sorta di trigger o altro, informa il server di
un file mancante, ed il server si adopera per sincronizzarlo. (o qualcosa di simile)
 
Altro problema: se hai numerosi client, magari non stabili, rischi di ritrovarti con il client che viene riavviato durante l'healing, l'healing non si conclude ed al successivo accesso deve ripartire. Non termina mai.
Un server, solitamente, è più stabile ed affidabile.
 
Immagina questa situazione:
ufficio di grafici dove su alcune workstation è installato il client Gluster che accede al cluster locale con immagini pesanti da svariati giga.
 
Manca un file, il client inizia la sincronizzazione.
L'operatore deve riavviare a causa di un update. Riavvia, la sincronizzazione si blocca. Il server invece è ancora li, e potrebbe benissimo proseguire con il sync.

Si hai ragione su tutta la linea, il mio scenario �/era un po' diverso, 
perch� i miei client erano a loro volta dei server veri e propri.
 
Non mi sognerei mai di far accedere glusterfs al client finale, inteso 
quest'utlimo come pc desktop operatore. Nel caso delle workstation dei 
grafici avrei usato magari nfs. Glusterfs va visto solo come backend a 
mio avviso.
 

 mio avviso.
 
Quindi aggiungeresti un ulteriore livello?
Esporteresti gluster in NFS? Non cambia niente, nei client devi comunque installare le librerie di nfs e montare il volume.
 
Alla fine gluster si può considerare un sostituto clusterizzato e ridondato di NFS

 ridondato di NFS
 
Nel mio caso specifico faceva qualcosa di pi�, mi permetteva di 
estendere lo spazio in modo trasparente all'applicazione. Cosa non da 
poco.
 
 

 poco.
 
Credo nel caso di tutti. 
Se fosse solo una questione di ridondanza, DRBD dovrebbe essere superiore.

 dovrebbe essere superiore.
 
Forse si, ma glusterfs ha secondo me un punto di forza: usa ext3/ext4 
come backend, mentre DRBD usa un block device (invero mi pare si 
potesse ottenere qualcosa di simile anche con DRBD, dedicando una 
partizione/block device come supporto per i log, separata dai dati veri 
e propri).
 
In caso di situazioni catastrofiche sapere che alla fine devi gestire i 
problemi di ext? � per me confortante.
 
P.S Scusa se continuo il discorso ma glusterfs � un progettto che mi 
affascina e se ne parla abbastanza poco da queste parti, quindi ne 
approffitto per condividere le idee.
 
 

 approffitto per condividere le idee.
 
Nessun problema, sto cercando di capire anche io quale sia la soluzione migliore per un FS distribuito, scalabile, ridondato ma che possa andare bene con molti file piccoli.
 
Ci sarebbe anche ceph da provare, che fa parte del kernel, ma la configurazione è un pugno nel naso. Gluster si attiva con una riga e zero file di configurazione, ceph fa bestemmiare.
 

 zero file di configurazione, ceph fa bestemmiare.
 
Ecco vedi � proprio questo a cui mi riferivo nel mio P.S. Mi hai fatto 
scoprire un nuovo framework!
 
 

 recenti di gluster questo problema è stato risolto con l'ausilio di dbd.
 
Hai mica qualche link? Seguo la mailinglist ma di 'sta cosa non ne so nulla.

 Ci sarebbe anche AFS ma ne so poco.
 
Troppo poco conosciuto.
 
Ma possibile che nessuno stia usando OpenStack in produzione ?

 piu ne metta...
 
Fermo.
A me interessa lo storage non il sistema di gestione di un hypervisor piuttosto che un altro.
 
Io non so come fare uno storage. Con GlusterFS e 4 nodi (distributed-replicated), è meglio fare 12 dischi SATA l'uno in RAID10 o meglio SAS in raid5?
 
Parlo di performance. In teoria, lo scopo di questi progetti è usare commodity hardware , pertanto scomodare i SAS da 15K RPM potrebbe essere insensato.

 l'apparato di gestione dello storage.
 
si, sostanzialmente si.
Ma non ho molto chiari i concetti di "cloud" quindi faccio fatica a focalizzare.
 
Vedo che in america i cloud nascono tutti senza storage persistente.
Per averlo persistente devi attaccare un volume extra e salvare i
dati li dentro. Mi può star bene, ma se devo prendere un server cloud
e modificare una qualche configurazione non posso di certo spostare tutta
la configurazione sullo storage montato in /mnt/storage

 Ci sarebbe anche AFS ma ne so poco.
 
C'è anche MooseFS. Più complesso di Gluster (bisogna ammettere che qualunque cosa è più complessa di GlusterFS) ma a pelle mi ispira fiducia.

 C'è anche MooseFS. Più complesso di Gluster (bisogna ammettere che qualunque cosa è più complessa di GlusterFS) ma a pelle mi ispira fiducia.
 
Ridondare il master server di MooseFS è un po troppo brigoso per i miei gusti.
Bisogna usare CARP o equivalente, far puntare tutti i client al VIP di carp e nel caso di una transizione slave->master di un nodo secondario, eseguire alcuni comandi di sincronizzazione.
 
Nulla di impossibile, ma troppo brigoso. Gluster fa tutto ciò in automatico.
sembrerebbe, però, che MooseFS abbia buone performance su file piccoli, loro nelle FAQ dicono che mailserver e repositori SVN sono perfetti.

 sembrerebbe, però, che MooseFS abbia buone performance su file piccoli, loro nelle FAQ dicono che mailserver e repositori SVN sono perfetti.
 
questo, se ho ben capito, perchè moosefs usa un server per metadati quindi sa sempre dove si trova il file ed in che status è, gluster invece lo verifica ad ogni accesso, portando via preziose risorse su file piccolissimi (gluster perde più tempo a fare le sue cose e verificare la sincronia piuttosto che a servire il file stesso)

 quantitativi di spazio senza far lievitare comunque troppo i costi?
 
Se girano file grossi, anche gluster va bene. Il problema lo si ha con file piccoli.
Gluster ad ogni "stat" su file ne verifica la consistenza su tutto il cluster, interrogando quindi tutti i server. nel caso un server fosse fuori sincrono, replica il file. quando tutto è ok, e solo allora, gluster serve il file.
Questo, nel caso di PHP, è una martellata nelle palle perchè i programmatori PHP sono soliti a mettere include ovunque anche per file inesistenti o a controllare file ed ogni volta gluster deve fare il check di tutto il cluster.
 
MooseFS, probabilmente (ho scritto *PROBABILMENTE*) non fa tutto ciò, perchè avendo un server di metadati sincronizzato direttamente dal client e dai singoli chunk, sa già quale file è salvato dove e quale file è fuori sincrono (ci pensano i chunkserver a dirglielo) quindi, *FORSE* non fa milioni di verifiche ad ogni stat.
 
Lo devo provare, ma non saprei come. Come posso debuggare cosa fa MooseFS in caso di stat?