La mia nuova configurazione cloud

Dall’inizio della mia esperienza con OpenNebula, ho provato parecchie soluzioni di storage, ma solo ora ho trovato una combinazione che soddisfa le mie esigenze di velocità, sicurezza e contenimento dei costi.

Innanzi tutto: non esiste mai la soluzione perfetta, ma esistono soluzioni diverse ciascuna delle quali si adatta meglio a risolvere un determinato problema. Nel mio caso, trattandosi di un cloud privato, l’esigenza principale è quella di avere una soluzione sufficientemente performate ma contnedo i costi.

Nel mio cloud privato, ho 5 server KVM che ospitano un totale di 20-30 VM: alcune sono stressanti solo per la CPU (mail scanner, DNS, ecc.), altre purtroppo generano molto traffico I/O (MySQL server per LAMP, Syslog server, ecc.): le seconde sono il problema, perche le soluzioni precedentemente adottate non hanno soddisfatto adeguatamente richieste di I/O.

La mia prima soluzione è stata quella di creare uno storage server che esportasse una partizione (c)LVM via AoE (che ha un overhead inferiore rispetto ad iSCSI): il carico di lavoro sul server era davvero elevato e la velocità di I/O non troppo veloce. Ok, ho imparato la lezione: se devi avere uno storage condiviso, non usare un server economico, ma usane uno ottimizzato per lo storage con dischi ad alta velocità, controller potenti con una buona dose di cache, LAN a 10GB… or semplicemente, compra una SAN FC 😉

Il mio secondo test è stato con uno storage basato su MooseFS: qui ho ottenuto risultati contrastanti. Ho un cliente che è davvero soddisfatto delle prestaizione e ha all’attivo un cloud con 10 storage server e 10 Hypervisor XEN; nel mio private cloud, con solo 3 storage server (un master e 2 chunk) l’I/O è lento come nella prima soluzione: nessun beneficio dall’uso di due server in bilanciamentoe 2 porte LAN ad 1 Gb in bonding è un altro collo di bottiglia. La lezione che ho imparato qui: per avere uno storage cluster dalle prestazioni soddisfacenti è necessario usare parecchi server.

Il mio terzo ed ultimo setup che vi racconto ora è… non usare un solo storage condiviso, ma distribuirlo sui server HyperVisor.

Partiamo da una considerazione: i miei “vecchi” HyperVisor sono dei Dell R410 dotati di 2 CPU quad-core e 32 GB Ram; se riuscissi a far stare in un cabinet Rack da 1U, 2 Motherboard Mini-ITX con una CPU Core i7 (non esattamente come la CPU Xeon dell’R410 ma non troppo distante) e 16 GB Ram… avrei la stessa potenza di calcolo, nello stesso spazio divisa su due server. E se riuscissi a farci stare anche 2 dischi SATA ad alta velocità come i WD Velociraptor per le VM e due dischi SSD per il SO, potrei usare DRBD in modalità Attivo/Attivo con cLVM o GFS2 per avere uno storage in HA dalle prestazioni accettabili per le VMs instanziate in questo “double-server”.

Ora ho 4 mini-itx double server ciascuno con questa configurazione; in OpenNebula, ogni double-server viene visto come un “cluster” separato e il disco DRBD è il datastore associato al cluster.

Ovviamente non posso migrare una VM tra due cluster diversi, ma al momento questa soluzione risponde bene alle mie esigenze di velocità, il costo di ogni “double-server” è inferiore rispetto ad un vero server ad 1U e il consumo di energia elettrica nel datacenter è diminuito.

Sostituzione storage server

Come accenntato in questo articolo, stiamo per iniziare la progressiva sostituzione dei server più obsoleti (e quindi più esosi in termini di consumo elettrico) con apparecchi di nuova concezione basati su architettura Mini-ITX/Sandy Bridge più performanti e a basso consumo.

Lo scopo di questa iniziativa è di rendere il datacenter più ecosostenibile diminuendo drasticamente il consumo di elettricità sia per i server, sia per gli impianti di smaltimento del calore prodotto.

Nella settimana dal 4 al 10 marzo, saranno sostituiti i primi due apparecchi per cui potrebbero verificarsi brevi interruzioni di servizio durante lo spostamento delle VM interessate sui nuovi server.

Ci scusiamo anticipatamente per gli eventuali piccoli disservizi.