mag 162011
 

In questo articolo descriverò la procedura necessaria per creare un nodo di calcolo Xen con CentOS 5.5 compatibile con OpenNebula e MooseFS.

In fase di installazione di CentOS 5.5, scegliamo di installare i tools per la virtualizzazione: così facendo verrà automaticamente installato XEN 3.1.2 e il kernel 2.6.18 con le estensioni per Xen.

A questo punto installiamo il pacchetto necessario per montare il filesystem MooseFS. In CentOS è piuttosto semplice in quanto è già presente nel repository RPMforge:

wget http://packages.sw.be/rpmforge-release/rpmforge-release-0.5.2-2.el5.rf.x86_64.rpm
rpm -ivh rpmforge-release-0.5.2-2.el5.rf.x86_64.rpm
yum install mfs-client ruby
mkdir -p /srv/vms

Per montare il filesystem ho scelto di creare il mountpoint in /etc/fstab con l’opzione noauto e di montarlo all’avvio tramite rc.local in modo di essere certo che il montaggio avvenga al termine del caricamento degli altri servizi.
Modificiamo il file /etc/fstab aggiungerndo:

mfsmount                /srv/vms                fuse    mfsmaster=172.16.0.200,mfsport=9421,noauto	0 0

Quindi modifichiamo il file /etc/rc.local aggiungendo:

mount /srv/vms

Ora creiamo l’utente per OpenNebula:

groupadd --gid 1002 cloud
useradd --uid 1002 -g cloud -d /srv/vms/one -s /bin/bash oneadmin

Ora bisogna editare il file /etc/sudoers aggiungendo:

%cloud    ALL=(ALL) NOPASSWD: /usr/sbin/xm *
%cloud    ALL=(ALL) NOPASSWD: /usr/sbin/xentop *

inoltre, sempre in questo file, bisogna commentare la riga:

#Defaults    requiretty

La configurazione di XEN deve essere modificata aggiornando il file /etc/xen/xend-config.sxp:

(xend-relocation-server yes)
(xend-relocation-port 8002)
(xend-relocation-address '')
(xend-relocation-hosts-allow '')

Infine, sul cloud controller, aggingiamo il nuovo server al pool:

onehost create compute-01 im_xen vmm_xen tm_moosefs
apr 272011
 

MooseFS è un filesystem  di rete che può essere montato attraverso il protocollo FUSE, con il quale è possibile creare uno storage ridondato e scalabile utilizzando una batteria di “commodity server” (cioè PC senza particolari caratteristiche di potenza).

Il sistema si compone di 3 elementi: il master server che fungerà da proxy e che ha la “mappa” delle posizione di tutti i dati all’interno del cluster, il metalogger server con una copia della “mappa” del server principale che può essere promosso a master in caso di necessità e una serie di “chunk server” che formetanno il vero e proprio storage.

Riguardo all’hardware, è consigliato avere due server robusti sia in termini di tolleranza ai guasti sia in termini di quantità di RAM per il master e il metalogger, mentre i chunk hanno bisogno, ovviamente, solo di parecchio spazio su disco.

In questo howto, installeremo un sistema semplificato formato solamente da un master e un chunk.

Partiamo da una installazione pulita della vostra distribuzione Linux preferita e installate i tools per la compilazione.

Quindi scarichiamo i sorgenti e scompattiamoli:

wget http://pro.hit.gemius.pl/hitredir/id=0sWa0S8ft4sTAHF1bGAAEZPcP3ziyq7f9SdhoQf7oeT.c7/url=moosefs.org/tl_files/mfscode/mfs-1.6.20-2.tar.gz
tar zxvf mfs-1.6.20-2.tar.gz
cd mfs-1.6.20-2

E creiamo un utente per eseguire il demone:

useradd moose

Installazione del master server
Sul master server, per comodità, installeremo anche l’opzione di mount del filesystem, per cui è necessario avere installato FUSE.
Su Gentoo è possibile installare il pacchetto con:

emerge sys-fs/fuse

Ora passiamo alla compilazione dei sorgenti. Innanzi tutto lanciamo il comando configure con le dovute opzioni:

./configure --disable-mfschunkserver --enable-mfsmount --with-default-user=moose --with-default-group=moose

Quindi passiamo alla compilazione vera e propria con:

make && make install

A questo punto il pacchetto è installato in /usr/local in modo da essere isolato dal resto del setup.

E’ necessario creare il file di configurazione /usr/local/etc/mfsmaster.cfg; io sono partito da quello di default.

/usr/local/etc/mfsmaster.cfg
WORKING_USER = moose
WORKING_GROUP = moose
SYSLOG_IDENT = mfsmaster
LOCK_MEMORY = 0
NICE_LEVEL = -19

EXPORTS_FILENAME = /usr/local/etc/mfsexports.cfg

DATA_PATH = /usr/local/var/mfs

BACK_LOGS = 50

REPLICATIONS_DELAY_INIT = 300
REPLICATIONS_DELAY_DISCONNECT = 3600

MATOML_LISTEN_HOST = *
MATOML_LISTEN_PORT = 9419

MATOCS_LISTEN_HOST = *
MATOCS_LISTEN_PORT = 9420

MATOCU_LISTEN_HOST = *
MATOCU_LISTEN_PORT = 9421

CHUNKS_LOOP_TIME = 300
CHUNKS_DEL_LIMIT = 100
CHUNKS_WRITE_REP_LIMIT = 1
CHUNKS_READ_REP_LIMIT = 5

REJECT_OLD_CLIENTS = 0

Inoltre bisogna creare il file con gli export /usr/local/etc/mfsexports.cfg. Io ho semplicemente tutto a tutti in lettura e scrittura:

/usr/local/etc/mfsexports.cfg
*			/	rw,alldirs,maproot=0
*			.	rw

Infine, trattandosi di una nuova installazione, bisogna creare il metadata:

mv /usr/local/var/mfs/metadata.mfs.empty /usr/local/var/mfs/metadata.mfs

A questo punto avviamo il servizio master e la console di stato con:

/usr/local/sbin/mfsmaster
/usr/local/sbin/mfscgiserv

Ricordiamoci di aggiungerlo all’avvio automatico, ad esempo modificando il file rc.local o /etc/conf.d/local.start a seconda della distrinuzione in uso.

Attraverso il servizio mfscgiserv si ha a disposizione una interfaccia web per controllare lo stato del proprio cluster storage. Ecco qui di seguito alcuni screenshot per stuzzicavi l’appetito.

Installazione del Chunk Server
Innanzi tutto formattiamo una partizione del nostro disco e montiamola in una directory dedicata

mke2fs -j /dev/sda4
mount /dev/sda4 /public

Ora passiamo alla compilazione di moose:

./configure --disable-mfsmaster --disable-mfsmount --with-default-user=moose --with-default-group=moose
make
make install

Assegnamo all’utente moose i privilegi di scrittura:

chown -R moose:moose /public

Creiamo il file di configurazione del demone:

/usr/local/etc/mfschunkserver.cfg
WORKING_USER = moose
WORKING_GROUP = moose
SYSLOG_IDENT = mfschunkserver
LOCK_MEMORY = 0
NICE_LEVEL = -19

DATA_PATH = /usr/local/var/mfs

MASTER_RECONNECTION_DELAY = 5

BIND_HOST = *
MASTER_HOST = master
MASTER_PORT = 9420

MASTER_TIMEOUT = 60

CSSERV_LISTEN_HOST = *
CSSERV_LISTEN_PORT = 9422

HDD_CONF_FILENAME = /usr/local/etc/mfshdd.cfg
HDD_TEST_FREQ = 10

e il file mfshdd.cfg con l’elenco dei dischi condivisi:

/usr/local/etc/mfshdd.cfg
/public

e avviamo il demone con:

/usr/local/sbin/mfschunkserver

Dato che sul master abbiamo installato anche il mfsmount, possiamo collaudare il funzionamento montando il disco con:

mfsmount /mnt/moose/ -H 192.168.0.100 -P 9421

Nel prossimo Howto aggiungeremo a questo setup un metalogger server attraverso il quale garantiremo alta affidabilità al master.

apr 222011
 

Quando si ha a che fare con più server, sicuramente prima o poi nascerà l’esigenza di avere un unico posto dove salvare i propri dati, in modo da poterci accedere contemporaneamente da più server. Questo è uno dei problemi più difficili da affrontare quando si progetta un sistema di server, in quanto esistono moltissimi metodi per arrivare allo scopo ma ciascuno ha le sue peculiarità che lo rendono più o meno adatto ad essere sfruttato in determinate applicazioni.
Diciamo che fare un confronto non è cosa semplice, anche perchè in alcuni casi è possibile avere situazioni ibride di due sistemi concatenati (ad es. NFS su GlusterFS)

NFS
NFS è il sistema di condivisione file classico del modo Unix: è senza ombra di dubbio il più usato, il più conosciuto ed il più semplice da implementare. Per quanto riguarda il funzionamento, il server NFS ha accesso ad uno spazio fisico a blocchi che può essere formattato utilizzando un qualsiasi FileSystem con funzionalità POSIX. Il server NFS ha il compito di gestire l’accesso contemporaneo ai dati contenuti all’interno del dispositivo a blocchi, oltre ovviamente a gestire i permessi utente. I client NFS (gli altri server della rete) potranno montare la directory condivisa (in gergo esportata) come se fosse un disco locale, un po’ come avviene con la condivisione di windows CIFS/SAMBA.
I punti a favore di questo sistema sono senza dubbio la facilità di implementazione, la stabilità del protocollo e, tutto sommato, discrete velocità di rete.
I punti debili di questo sistema sono la totale impossibilità di scalare “on line” aggiungendo nuovo storage nel momento in cui se ne ha la necessità, il fatto di avere un SPoF (Single Point of Failure) costituito dal server NFS che è suscettibile a guasti e che rischia di sovraccaricarsi in maniera considerevole all’aumentare di richieste di rete.

OCFS2 e GFS
OCFS2 e GFS sono due FileSystem concettualemente simili in quanto prevedono nativamente l’accesso contemporaneo ai file: OCFS2 è sviluppato da Oracle mentre GFS2 è sviluppato da RedHat. La teoria di funzionamento è identica: ogni server che ha accesso allo storage deve avere attivo un demone che dialoga continuamente con gli altri server in modo da conoscere esattamente lo stato dello storage. Il disco condiviso viene montato in locale deve essere formattato con il suo filesystem, non è possibile utilizzare un filesystem tradizionale (ext3, xfs, ecc); la cosa interessante è che, trattandosi della formattazione di un disco, questo può essere di qualsiasi tipo, basta che sia accessibile da tutti i server: quindi può essere un disco di rete iSCSI o AoE, ma anche una partizione locale replicata su un secondo server attraverso DRBD8 configurato in modalità Attivo/Attivo o un disco FireWire collegato a più server.
Da un confronto tra i due filesystem, GFS è il più semplice da configurare dato che utilizza i tools di alta affidabilità di RedHat, mentre OCFS2 è più macchinoso. OCFS2 è però nettamente più veloce anche se non supporta le quote in nessun modo (è una delle cose in implementazione).
I maggiori pregi di questo sistema è che non serve un server che faccia da tramite e quindi non si ha un SPoF e le prestazioni sono le migliori in assoluto (specie con OCFS2).
Il difetto principale, deriva direttamente dal pregio: non avendo un server che gestisce la condivisione dei file, ogni nuovo nodo che entra a far parte del cluster comporta un riconfigurazione di tutto il cluster. Anche la scalabilità del sistema è relativa: anche ammettendo di avere un dispositivo di storage che consente di “aggiungere dischi”, è necessario eseguire un resize della partizione con rischi, annessi e connessi.

I figli di FUSE
FUSE è l’acronimo di File System in Userspace ed è un nuovo metodo di utilizzo di dispositivi di rete. Molti filesystem di nuova generazione utilizzano questo sistema per gestire i dischi di rete. L’utilizzo di un ulteriore layer per la comunicazione tra disco e client va nella direzione opposta rispetto all’utilizzo di un filesystem cluster come OCFS2 o GFS, cosa che porta una maggiore flessibilità e stabilità a discapito di una leggera perdita in termini di prestazioni.
Analizziamo due filesystem che fanno affidamento a FUSE: GlusterFS e MooseFS.

GlusterFS
GlusterFS è un filesystem che in questo momento va molto “di moda”. Consente di unire più “commodity computer” per realizzare un cluster di storage server: è possibile realizzare uno stripe (unire lo storage di più server, simile concettualmente al raid 0) o un mirror (avere lo stesso dato copiato su più server, simile concettualmente al RAID 1). Lo storage ove viene creato il filesystem Gluster è, come per NFS, un filesystem comune (EXT3, XFS, ecc,)
Una volta creato lo storage, è possibile accedevi sia utilizzando il protocollo NFS, sia il protocollo CIFS (Samba), sia, come dicevo pocanzi, usando il protocollo nativo attraverso FUSE: questo sistema è quello che garantisce le migliori performance.
Il pregio maggiore di questo protocollo è a mio avviso che non esiste alcun SPoF: tutti i server sono autoritativi allo stesso modo, quando un client monta la partizione attraverso FUSE seve specificare un server, ma poi la comunicazione avviene direttamente con tutto il cluster. Altro pregio è la diffusione: essendo molto diffuso e mantenuto, è anche molto stabile.
Il difetto maggiore a mio avviso è la complessità concettuale: Gluster è formato da tanti layer ciascuno dei quali assove una sua funzione: comprenderli e tarali non è semplicissimo e l’ordinaria manutenzione (aggiungere un nodo ecc.) è spesso fonte di problemi. Le prestazioni del sistema sono buone in lettura se configurato in modalità mirror (le letture possono avvenire contemporaneamente da più nodi), però in scrittura non sono esaltanti.

MooseFS
Operativamente è simile a GlusterFS in quanto condivide FUSE per il montaggio dei dischi in rete, MooseFS è però diverso in quanto a sistema di gestione che lo rende simile a Openstack Swift. In Moose, a differenza di Gluster, i nodi non sono paritetici, ma si compone di un Master Server, un Metalogger server (che può essere promosso a Master in caso di guasto) e di X nodi dati.
Il Master fa da Proxy e conosce esattamente dove sono salvati i dati all’interno dei nodi dati; i dati possono essere replicati su un numero arbitrario di zone in modo da avere sia un sistema tollerante ai guasti sia un sistema di lettura parallelo. Purtroppo, al contrario di OpenStack Swift, anche le scritture avvengono in parallelo, cosa che di fatto lo rende un po’ lento in questo frangente.
Due cose interessanti di questo FileSystem sono l’interfaccia web per il controllo dello stato del cluster e il plugin appena rilasciato per l’integrazione diretta con OpenNebula.
Il principale pregio di questo sistema è la facilità di implementazione e di scalabilità, unita a una velocità generale di tutto rispetto.
Il principale difetto è la quantità di server necessari ad implementare un sistema funzionante: almeno 3 per ambienti di test, almeno 5 per ambienti in produzione.

Ceph
Ceph è l’ultimo Filesystem che prendiamo in considerazione. Diciamo che promette bene e, non a caso, è stato già introdotto nella mainline del kernel linux. Ultima cosa che mi sarei aspettato, quindi, è di avere problemi di sorta, cosa che puntualmente è avvenuta cercando di creare un ambiente misto di nodi a 32 e a 64 bit.
Concettualmente è simile a MooseFS, però introduce due feature interessanti: il driver nel kernel è in grado di lavorare a diretto contatto con lo storage del cluster, senza quindi necessitare di FUSE, pertanto dovrebbe garantire prestazioni superiori; inoltre introduce un proxy in grado di esporre una interfaccia REST API compatibile con Amazon S3.
Diciamo che è ancora un prodotto giovane e, a causa delle limitazioni di gioventù, non ho potuto sperimentarlo in maniera approfondita, peranto ritornerò a provarlo sicuramente in futuro.

apr 042011
 

Quando abbiamo la necessità di collegare uno storage a blocchi ad una batteria di server, ci viene spontaneo soffermarci sul protocollo iSCSI.
Questo protocollo permette di incapsulare le istruzioni SCSI su una connessione IP e promette di raggiungere prestazioni simili a SAN in Fibre Channel ad un costo nettamente inferiore. Il protocollo è largamente diffuso sia sul mondo Linux, sia sul mondo proprietario (VMWare, Windows, ecc).
iSCSI, però, manifesta i sui limiti in caso di intenso traffico in quanto carica la CPU del server durante le operazioni di incapsulamento e decapsulamento dei pacchett SCSI nel/dal pacchetto IP. Quando il traffico aumenta, quindi, per mantenere prestazioni adeguate si rende necessario acquistare costose schede ethernet dedicate in grado di compiere direttamente questa operazione, senza caricare la CPU dello storage.

Se la nostra SAN dovrà servire esclusivamente sistemi Linux, però, c’è una valida alternativa ad iSCSI: AoE.
AoE è l’acronimo di ATA over Ethernet ed è un protocollo concettualmente simile all’iSCSI, però molto più “light”: basti solo pensare che l’intera specifica del protocollo risiede in sole 9 pagine!
AoE è in grado di inviare direttamente i comadi ATA su Ethernet, senza però incapsularli all’interno di un pacchetto IP, pertanto l’overhead del protocollo iSCSI con l’annesso maggior carico della CPU viene scongiurato: le comunicazioni avvengono sfruttando direttamente il MAC Address, pertanto hanno il limite (che non ha iSCSI) di non essere routabili.
In caso di più device all’interno della stessa rete, il protocollo AoE permette di identificarli assegnando due valori: shelf e slot che sono assegnabili liberamente alla creazione del device, ma che concettualmente sono simili all’idea dell’identificativo del disco (shelf) e della partizione (slot).

Qualsiasi distribuzione linux è adatta ad utilizzare questo protocollo: l’introduzione a livello kernel è arrivata già con la release 2.6.11 e due pacchetti (vblade e aoetools) permettono di gestire il protocollo.

Configurazione di uno storage AoE
Sul server che fungerà da storage (in gergo chiamato “target”) è necessario installare il pacchetto vblade che permette di trattare i device AoE analogamente al Coraid Etherdrive. Una volta installato il pacchetto, è necessario esportare il drive; ad esempio:

./vbladed 0 0 eth0 /dev/sda4

Così facendo, esporteremo il disco /dev/sda4 attraverso l’interfaccia di rete eth0 assegnando lo shelf 0 e lo slot 0. Il comando restituirà in output una striga simile alla seguente:

pid 12905: e0.0, 436614507 sectors

Questa indica il PID del processo (12905), il valore di shelf e slot (e0.0) e il numero di settori del disco esportato.

 

Configurazione di un client AoE
Per collegarsi ad un disco esportato attraverso un client linux, innanzi tutto è necessario caricare il modulo del kernel con:

modprobe aoe

Quindi, per montare il disco nello userspace, bisogna installare il paccheto aoetools. Con il seguente comando è possibile eseguire una scansione della rete per identificare i drive AoE e creare automaticamente il device:

aoe-discover;aoe-stat

Seguendo il nostro esempio, troverete un nuovo device in /dev/etherd/e0.0

A questo punto potete formattare il disco e montarlo proprio come se si trattasse di un disco locale:

mkfs.ext3 /dev/etherd/e0.0;mount /dev/etherd/e0.0 /mnt

Per semplicità ho usato ext3, nulla vieta ovviamente di utilizzare un filesystem cluster come ocfs2 o gfs e montare il disco su più client.

apr 012011
 

Dopo l’articolo dedicato ad Openstack Swift, sistema per creare storage ridondati e distribuiti geograficamente, analizzamo un nascente protocollo concettualemte simile ma molto più innovativo, il SoS.

SoS è l’acronimo di Storage over Smartphone e si tratta di un protocollo nato dalla collaborazione dell’americana AT&T e la svedese Nokia con Microsoft, in grado di realizzare uno storage ridondato distribuito sugli smartphone.

L’idea è quella di utilizzare lo spazio per lo più inutilizzato delle schede SD degli smartphone di ultima generazione collegati in maniera ormai costante alla rete internet per realizzare uno storage distribuito. Per spiegarlo in maniera semplice, ogni smartphone “cede” una partizione di 1 GB sulla propria SD card alle funzionalità SoS; ogni dato memorizzato all’interno del servizio SoS viene replicato almeno su tre partizioni (e quindi su almeno tre apparecchi smartphone) per garantirne l’alta affidabilità anche in caso di spegnimento o mancata raggiungibilità del telefono.

Un server centrale si occupa di gestire lo storage e quindi di distribuire automaticamente il dato in scrittura all’interno del maggior numero di smartphone possibile e di “proxare” le richieste in lettura in modo da rendere il sistema più veloce: difatti questo server viene aggiornato costantemente anche sulla posizione geografica dei vari nodi, ed è quindi in grado di capire se l’apparecchio che richiede il dato può comunicare direttamente con un apparecchio in cui il dato è presente, anche con connessioni bluetooth o wifi locale e senza passare quindi attraverso la rete telefonica dell’operatire: lo scopo è quello di rendere lo stesso dato disponibile sul maggior numero di apparecchi possibile (tendenza all’infinito) in modo da sfruttare la parallelizzazione dei download per quando il dato deve essere letto.

Sicuramente l’idea che sta alla base è geniale, in quanto si tratta di un sistema di storage distribuito simile concettualmente ai vecchi sistemi di peer-to-peer e quindi virtualmente infinito e ridondato. I dubbi riguardano essenzialmente la capacità di banda consumata dal protocollo in relazione a quella a disposizione degli SmartPhone che potrebbe far “sedere” le reti degli operatori mobili, facendo apparire sul display degli smartphone un messaggio simile a questo: