Vi segnaliamo la ricerca sul mercato embedded e sul mondo RTOS:

• Microcontroller firmware development and embedded RTOS

L'iniziativa è curata dal team di BeRTOS, sistema operativo real time open source, e censisce e fa analisi sul mondo embedded, identificando gli RTOS più usati, gli strumenti di lavoro più diffusi e le tendenze nel mercato di settore. All'interno del questionario i temi trattati sono 4: Open Source, hardware preferito nei progetti, strumenti software di sviluppo preferito, inchiesta sui Real-Time OS.

La survey contiene 25 domande (si termina in circa 5 minuti), è gratuita e non è obbligatorio lasciare contatti, anche se consigliamo di lasciare la mail visto che permetterà di ricevere il PDF completo dell'analisi finale.

I risultati saranno comunque resi pubblici sul blog di BeRTOS al termine della survey, con diversi post mirati ad analizzare alcune delle risposte più significative che sono state date.

Nei giorni 27/28 Gennaio, Firenze ospiterà QtDay Italia, la prima conferenza italiana su Qt, che farà il punto sulle ultime novità del framework di sviluppo Nokia. L’evento è organizzato da Develer in collaborazione con Nokia e Digia.

QtDay è rivolto a professionisti ed aziende che vogliono migliorare i propri servizi e prodotti integrando tecnologie innovative e multipiattaforma, diminuendo il proprio Time-To-Market e valorizzando le competenze del proprio staff, entrando in contatto con i più importanti esperti di sviluppo del proprio mercato di riferimento.

Develer e QtDay

Oltre ad essere parte dell'organizzazione dell'evento, lo staff Develer sarà in conferenza come speaker nelle giornate Business e Community, sia come staff tecnico disponibile nel Qt Real Time Help Desk.

Durante tutta la conferenza, infatti, saranno a disposizione dei partecipanti alcuni sviluppatori certificati Qt che potranno risolvere problemi legati di sviluppo Qt, dando risposte a problematiche tecniche o anche metodologiche sul codice della vostra applicazione.

La Conferenza

La conferenza porta sul palco programmatori Nokia che realizzano ed evolvono Qt, oltre a staff esperto dei partner certificati italiani, come Develer, che contribuiranno parlando di come si costruiscono e quali sono i vantaggi di business realizzando prodotti software con Qt.

La location scelta, il centro congressi del AC Hotel Firenze, permette un comodo accesso alla conferenza con qualsiasi mezzo di trasporto, ampio parcheggio, vicinanza con la stazione centrale e navetta per l'aeroporto di Firenze e Pisa.

QtDay è diviso in 2 giornate:

• Business Day, dedicato a manager e responsabili commerciali e di progetto, che vogliono scoprire l’impatto di Qt sul business delle proprie aziende, conoscere casi reali di successo e confrontarsi direttamente con le aziende che possono fornire consulenza in materia sui propri progetti;
• Community Day, che ha il suo focus su Qt come strumento open source, è dedicato agli sviluppatori della community italiana che vuole aggiornarsi sulle nuove tendenze ed il futuro di Qt.

Sarà possibile iscriversi ad entrambe le giornate di conferenza direttamente dal sito web. Il programma ancora non è stato ancora definito nel dettaglio, è online tuttavia una pagina di Agenda dove verrete informati delle novità in merito.

Iscrizioni

Le iscrizioni inizieranno mercoledi 16 Novembre (domani), la partecipazione è gratuita, ma riusciremo ad ospitare circa 120 partecipanti per giornata; consigliamo quindi di registrarsi all'evento appena possibile: qtday.eventbrite.com.

Per maggiori informazioni: www.qtday.it

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 :)

Dal 6 al 10 Giugno Develer organizza un corso sul framework Qt per programmatori C++, che si terrà nella sede di Campi Bisenzio.

Il corso ha come obiettivo l'introduzione alle librerie Qt di Nokia, per velocizzare l'apprendimento di chi sia avvicina la prima volta a questa libreria.

Al termine del corso, i partecipanti avranno gli strumenti necessari per:

• Leggere e capire codice Qt già esistente
• Scrivere semplice programmi Qt in autonomia
• Partecipare allo sviluppo di programmi Qt più complessi, in affiancamento a programmatori più esperti.

Il corso Qt Basic Plus ha una durata di una intera settimana, viene svolto in sede Develer ed ha un numero limitato di partecipanti (solitamente 5).

Prerequisiti

Per poter partecipare al corso e trarne il massimo beneficio, è necessario che i partecipanti soddisfino i seguenti requisiti:

• Almeno 1 anno di esperienza concreta con il linguaggio di programmazione C++
• Conoscenza universitaria dell'inglese tecnico

Struttura del corso

Il corso ha la durata di 5 giorni ed è diviso in due diverse tipologie di sessione:

• Sessioni teoriche: si svolgono la mattina e hanno la durata di 4 ore al giorno (totale 20 ore).
• Sessioni pratiche: si svolgono nel pomeriggio e hanno la durata di 4 ore al giorno (totale 20 ore).

Dove possibile, durante il corso si alterneranno diversi istruttori, in modo da fornire una formazione ancora più completa e accurata ai partecipanti, poiché ogni istruttore sarà particolarmente competente nella materia trattata.

Download