Nel 2010, con il passaggio alla fibra ottica per la connettività, in Develer è iniziato un processo di rinnovamento della struttura tecnologica interna.

Questo processo si è concretizzato, pochi mesi fa, anche sui server interni, rinnovati sia nell’hardware che nel software, portandoci a passare da una struttura basata su server fisici verso una struttura che opera sulla base di server virtualizzati.

Il passaggio, dibattuto e valutato, è stato dettato dal raggiungimento del limite fisico della vecchia struttura hardware; in Develer avevamo infatti 2 server in house (Trinity, Atlantis) con cui venivano svolte la maggioranza delle funzioni necessarie.

Essenzialmente Trinity fungeva da:

• Intranet
• Mail server
• NFS e gestione Home
• shell server

Atlantis invece era il nostro server web dove erano hostati diversi servizi, dai nostri siti web (better software ad esempio) alle applicazioni dei clienti.

Come detto, il passaggio è stato pensato per risolvere la maggior parte delle problematiche che avevamo col tempo riscontrato nella vecchia struttura. Ecco alcuni dei principali motivi che hanno reso necessaria la migrazione:

Lock Hardware per le prestazioni

Il sistema così come era fino a qualche mese fa era nato con Develer, quando in azienda orbitavano solo 5 dipendenti, va da se che con gli attuali “quasi 30” il vecchio server fosse un pò in difficoltà!

Le Home con NFS, infatti, non riuscivano più a scalare prestazionalmente, creando un vero e proprio collo di bottiglia per tutti i client e le applicazioni interne.

Hardware non Enterprise

Alla fine l’hardware che faceva girare tutto il sistema era ottimo hardware di tipo consumer, che ha svolto un lavoro egregio, ma con il difetto di essere soggetto a molta più manutenzione del necessario, rispetto ad hardware di classe Enterprise.

Proliferazione dell’hardware

Questo aspetto, logisticamente fastidioso, potrebbe essere inteso come semplice scelta “estetica”, ma non lo è; la proliferazione di cavi patch, cavi corrente, spazio occupato dai server non portano a nessun beneficio comune e quindi non sono una strada percorribile se vuoi ottimizzare risorse e spazi.

Single Point of Failure

Questa è veramete facile da spiegare. Se fa tutto Trinity, quando Trinity va giù non si lavora :)

La scelta della virtualizzazione

Questa scelta è stata basata, oltre che sull’annullamento dei vecchi problemi, su 4 diversi risultati che volevamo ottenere per la nuova configurazione:

Concentrazione dei servizi in HW Enterprise

Questo perchè la proliferazione dell’hardware non ci piaceva, ma anche perchè i tempi di intervento per manutenzione su hardware di classe Enterprise è estremamente più veloce!

Attualmente utilizziamo:

• SAN: HP P2000 G3 MSA Fibre Channel
• 2 server: HP DL380G7 (2 CPU Xeon E5630 quad-core, 24 GB di RAM, scheda fibre channel)

Niente più spreco di risorse!

Con la virtualizzazione, il bilanciamento e la condivisione delle risorse è un obiettivo molto facile da raggiungere, al contrario della vecchia impostazione.

Adesso possiamo ottimizzare in tempo reale i carichi server su ogni CPU in base alla richiesta di potenza in ogni momento di ogni servizio virtualizzato.

Semplicità di gestione

Tutti i server virtuali sono gestibili da console remota con il vantaggio che non serve essere fisicamente presenti per spegnere/riaccendere, utilizzare CD o DVD, posso aggiungere o togliere dischi virtuali a piacimento, collegare la macchina virtuale a una sottorete piuttosto che un’altra senza toccare cavi.

Tutte le problematiche di gestione “fisica” dell’hardware sono concentrate su due soli server.

Migliorare la scalabilità ed i tempi di messa online

Questo quarto obiettivo è la conseguenza di aver centrato i tre precedenti! Un HW più potente che possiamo gestire in maniera semplice, controllando in tempo reale bilanciamenti e carichi di lavoro porta ad un miglioramento dei tempi di messa online di qualsiasi nuovo servizio sia necessario.

La scalabilità viene garantita da un adeguato dimensionamento dei server:

• 24 GB di RAM per server sono sufficienti a ospitare tutte le nostre macchine virtuali su un singolo server; se qualche VM ha bisogno di maggiori risorse può girare sulla macchina hardware più scarica.
• I doppi processori quad-core su ogni server garantiscono potenza CPU più che adeguata. Le VM girano sullo stesso hardware quindi quando una VM ha bisogno di più memoria o potenza di calcolo ne può usufruire in quanto capita molto raramente che tutte le VM abbiano bisogno contemporaneamente di maggiori risorse. Al contrario in caso di tanti server fisici separati ognuno è limitato alla sua CPU e memoria e non può sfruttare quella degli altri.
• Tutti gli aggiornamenti hardware e la manutenzione (memoria, CPU, dischi sulla SAN) possono essere effettuati senza spegnere o mettere off-line le macchine virtuali.

La migrazione verso le VM

La migrazione ci ha portato ad una struttura del CED con 2 server fisici ridondati, collegati in fiber channel con una SAN, che gestiscono tutto il carico di lavoro, con NFS e home gestite a livello fisico, mentre tutti gli altri servizi sono stati virtualizzati in 8 diverse VM.

Struttura del CED:

L’unico servizio che non è stato virtualizzato è stata l’accoppiata tra Home+NFS. Questa scelta è stata fatta perchè NFS servito dalla VM non era in grado di sfruttare pienamente la velocità di accesso ai dischi fornita dalla SAN, rendendo il servizio di poco migliore rispetto al vecchio server. NFS e le home sono state quindi montate fisicamente sui server, abbattendo definitivamente ogni problema di performance.

Vantaggi delle VM:

La nuova struttura permette implicitamente una serie di vantaggi non trascurabili, sia a livello di prestazioni sia a livello di gestione servizi e sicurezza.

Server ridondati e migrazioni Live grazie allo storage condiviso

I servizi, le Virtual Machine, vengono tenuti sul server (esempio) A. Essendo una struttura in cluster (cluster di 2 nodi) nel caso in cui il server A dovesse avere qualche problema di hardware i siti e le VM vengono migrati sul server B, la migrazione avviene a caldo, praticamente senza nessun down sui servizi.

Anche la SAN è ridondata, sia nell’alimentazione che nel RAID e addirittura nel controller, il che rende teoricamente impossibile un guasto da “immobilità totale”.

Per gestire la sincronia dei dati in real time dello storage abbiamo in un primo momento valutato l’utilizzo di DRBD (http://en.wikipedia.org/wiki/DRBD). Dalle prove fatte abbiamo ritenuto insufficienti le prestazioni ottenute quindi abbiamo deciso di utilizzare la SAN.

Ottimizzazione delle prestazioni delle Home

Come detto la gestione delle home degli utenti era un tassello importante nella scelta della nuova soluzione. La scelta della SAN condivisa è motivata proprio dalla possibilità di scalare ed ottimizzare le prestazioni in questo senso rispetto ad usare DRBD.

Le prestazioni sono garantite da dischi SAS (serial attached SCSI) dual port a 15000 RPM. Il throughput elevato invece è mantenuto grazie alla connessione Fiber Channel SAN <-> Server a 4Gbit.

Affidabilità superiore

Dischi server-grade con un MTBF superiore ai dischi consumer. Ridondanza di tutti i componenti (dischi in RAID, 2 controllers, 2 alimentatori, 2 cache, 2 connessioni in fibra). Un livello di affidabilità impossibile da raggiungere con componentistica consumer.

Versatilità e efficienza nella gestione dello storage

Tutti i dischi virtuali sono sulla SAN e sono configurati tramite l’interfaccia di gestione web molto flessibile (possibilità di fare snapshot dei dati, copie, ridimensionare i dischi virtuali, ripartizione del carico di I/O su gruppi di dischi diversi in base alle esigenze delle varie macchine virtuali).

Software utilizzato

Quale soluzione software abbiamo scelto:

• Ubuntu server 11.04 (Natty Narwhal)
• Qemu + KVM + libvirt per la virtualizzazione
• Pacemaker e Corosync per l'high-availability

Perchè KVM

KVM ha dato prova di prestazioni migliori (circa il 20%) sul nuovo hardware installato rispetto ad una soluzione come XEN, nonostante questo rimanga una soluzione più matura ed abbia maggiori funzioni rispetto a KVM

Inoltre XEN Hypervisor è realmente molto leggero, ma il sistema principale è una VM e, tra i nostri requisiti c’era quello di far girare NFS su hardware vero e non su VM.

Conclusioni ...

Parlando di ottimizzazioni, il nodo da sciogliere rimane a questo punto la rete cablata, l’ufficio cablato Gigabit comincia a essere al limite confrontato con le prestazioni del collegamento fiber channel 4Gb tra i server e la SAN :)

Appena possibile metteremo online alcuni test prestazionali che ci hanno aiutato a scegliere tra le varie soluzioni (DRDB vs SAN ed anche KVM vs XEN) oltre ad un pò di benchmark prima e dopo la cura :)