Un software open source che utilizzo parecchio sui miei sistemi e su quelli dei miei clienti è Collectd, che ormai è diventato il mio standard in fatto di storicizzazione dei valori di carico e dell’andamento delle risorse sui miei server linux.

Si tratta di un ottimo software che non ha dipendenze clamorose (giusto rrdtool per conservare i dati in formato rrd), che rileva i dati direttamente dal sistema (/proc) e che soprattutto non si appoggia ad altro, in particolare al protocollo SNMP (come ad esempio il celebre Cacti); insieme all’ottimo Collectd Graph Panel permette di tenere tutto sott’occhio tramite una comoda (e bella) interfaccia web based in php.

L’unico difetto di Collectd è che se utilizzato male tende a piegare lo storage più performante a causa dell’elevato numero di IOPS generati, il fenomeno è direttamente proporzionale al numero di database rrd utilizzati quindi si manifesta soprattutto se si utilizza il plugin network per centralizzare la raccolta dati su una singola macchina; il risultato è un server ridotto ad un 486 a causa dell’eccessiva sollecitazione del sottosistema di storage in termini di scritture.
Qui potete vederne un esempio, si tratta di poche decine di server per un totale di circa 3800 file rrd collezionati mediante plugin network con le impostazioni di default, in pratica un chiaro caso di “I/O Hell”

Per risolvere il problema occorre da una parte un po’ di buon senso e dall’altra un paio di semplici accorgimenti nel file di configurazione (/etc/collectd.conf).

1) Raccogliete i dati che servono, evitate il resto.
Sembrerà una banalità ma spesso di default sono attivi un sacco di plugin che in realtà su molte macchine non servono, se ad esempio state monitorando un server su cui vengono fatti accessi locali solo a scopo amministrativo, e questi vengono loggati altrove, che senso ha attivare il plugin users e generare degli rrd inutili?

2) Fate attenzione ai device del plugin disk.
I server connessi ad una san spesso si ritrovano con un gran numero di lun e di conseguenza di device di storage, se per giunta utilizzano LVM si generano una serie di altri device rilevati dal plugin “disk” (/dev/dm-*) che rappresentano i device map dei logical volumes, valutate se vi serve davvero monitorarli, ed eventualmente escludeteli limitandovi ai device fisici (es /dev/sd*)

3) Utilizzate il plugin rrdtool solo dove serve.
Se raccogliete i dati su un server centralizzato tramite plugin network è inutile (e ridondante) conservare gli stessi dati anche in locale, genererete il doppio degli IOPS (sulle interfacce di rete e sui device di storage locali) senza alcun reale beneficio (se volete un backup fatelo sul server che raccoglie tutti gli rrd…).

4) Utilizzate le opzioni CacheTimeout e CacheFlush del plugin rrdtool.
Queste sono la vera manna nel caso di I/O Hell, abilitando questi due parametri Collectd non scriverà ogni modifica ai file rrd istantaneamente ma la terrà in RAM per un certo numero di secondi (definito dal parametro CacheTimeout), al termine dei quali effettuerà un’unica scrittura. Il parametro CacheFlush forza la pulizia della cache dopo un certo numero di secondi, giusto per fare “pulizia” nel caso qualche server abbia smesso di rispondere oppure qualche rilevazione sia rimasta in sospeso per qualsiasi motivo.

Potete osservare l’impatto di queste modifiche nel grafico che segue

• I/O Hell (1)
• Rimozione dei plugin inutili e dei device poco significativi (2)
• Attivazione CacheTimeout con frequenza pari a 120″ (3)
• Attivazione CacheTimeout con frequenza pari a 300″ (4)

Come potete osservare il numero di IOPS si è DRASTICAMENTE ridotto, e soprattutto non si verifica più l’affollamento di scritture presente prima della modifica.
Come risultato il server finalmente è tornato ad avere tempi di risposta fulminei (in precedenza aprire la homepage di Collectd Graph Panel richiedeva una trentina di secondi buoni, generare una decina di grafici poteva richiedere anche un minuto o più) e il carico di sistema ne ha beneficiato.

L’unica conseguenza negativa di questa operazione è il fatto che i grafici non vengono più aggiornati in real time ma soltanto quando il plugin rrdtool salva i dati nei file rrd, un disagio tutto sommato accettabile considerando i benefici, senza contare che il ritardo è passibile di tuning in base al livello di carico e al numero di rrd file da gestire.

Frequentando vari forum e newsgroup che trattano tematiche sistemistiche mi capita di incappare piuttosto frequentemente in richieste d’aiuto da parte di persone che lavorano per piccole aziende e che vogliono/devono sostituire un server aziendale.
Generalmente in questi casi le esigenze sono piuttosto modeste, e i servizi ricadono quasi sempre nei classici DNS, DHCP, piccolo dominio Active Directory, gestionali vari (Zucchetti&C per capirci), e spesso gli interessati si presentano chiedendo consigli sui componenti con cui assemblare la macchina in questione.

Dato che:

1. queste casistiche sono molto frequenti
2. sono sinceramente interessato all’argomento
3. non mi va di ripetermi tutte le volte

ho deciso di scrivere questo post in modo da chiarire una volta per tutte perchè secondo me la soluzione del server assemblato è una pessima idea.

COSTI
Sfatiamo subito un mito, un server “brandizzato” non costa più di un server assemblato, potrà sembrare strano ma è così.
In realtà la cosa è facilmente intuibile anche da chi non ha familiarità con il mondo IT, a parità di componentistica come può un privato (o una azienda) scucire un prezzo migliore su un singolo pezzo rispetto a un colosso come IBM, Dell o HP che effettuano ordini per migliaia o milioni di pezzi?
Qualcuno a questo punto potrà affermare che un pc basato su Intel Core i5 fa lo stesso lavoro del server IBM basato su cpu Intel Xeon, benissimo, ma allora perchè non comprare un pc Lenovo o HP o Dell anzichè un server?
Mi spiego, che senso ha paragonare i costi di un server rispetto ad un semplice PC? Questo ci porta al punto 2

COMPONENTISTICA
Inutile che ci giriamo attorno, un server NON E’ UN PC PIU’ POTENTE.
L’architettura è la stessa, la componentistica potrà sembrare simile, ma non sono la stessa cosa, un server è una macchina che ha come obbiettivo primario l’affidabilità e la stabilità, una workstation ha altri obbiettivi.
Un server è ben più di un case con dentro una mainboard con installata una CPU, un po’ di RAM, un controller per lo storage e qualche disco; un server è una macchina con componentistica custom (non per complicare la vita, ma anzi per semplificarla, sostituire una mainboard svitando una vite e tirando una leva è ben diverso dello smontare ogni componente come su un pc), con componenti di monitoraggio specifiche (BMC) che rispettano standard ufficiali (IPMI), con interfacce di controllo remoto complesse (interfacce di Lights-Out management), con componenti ridondate per garantire la continuità di servizio, e spesso con tecnologie e soluzioni proprietarie molto interessanti  (pensiamo ad esempio alla sostituzione della ram a caldo, piuttosto che a tecnologie di aggregazione delle risorse tipo IBM X6 o di virtualizzazione hw LPAR)

QUALITA’ COSTRUTTIVA
A me piace parecchio assemblare i miei pc, è un’attività che mi rilassa e mi diverte, e le poche volte in cui capita impiego tantissimo tempo per curare ogni minimo dettaglio, fascettare ogni cavo, curare anche i dettagli estetici. Ciò nonostante sfido chiunque (anche il più assatanato cultore delle fascette plastiche) a raggiungere la qualità costruittiva e l’ingegnerizzazione interna di un server “brandizzato” o anche di un semplice pc.
Chiunque abbia guardato dentro una macchina Lenovo, IBM, Dell o HP può confermarlo, la precisione nell’assemblaggio e la pulizia di una soluzione ufficiale di questi produttori batte 6:0 6:0 6:0 anche l’assemblatore più appassionato, merito anche del fatto che queste società possono permettersi di utilizzare componentistica customizzata, e non parlo solo di mainboard o dissipatori, mi riferisco anche solo alle cose più banali come un semplice connettore di alimentazione con una forma particolare che il privato (o azienda) non potrebbe mai procurarsi.

Qualcuno a questo punto ribatterà sul fatto che un appassionato mediamente va a scegliere componenti più blasonate, mentre un server “brandizzato” è una sorta di black box dove non è dato da sapere quali componenti specifiche vengono usate (ad esempio che latenza ha la ram, chi è il produttore degli hard disk, che tipo di condensatori sono stati utilizzati sulla mainboard etc etc etc…), questo ci porta al punto successivo.

PEZZI DI RICAMBIO
E’ vero, su un server “brandizzato” l’utente non ha il pieno controllo di ogni dettaglio, si può scegliere il modello di CPU, la quantità di RAM e in certi casi la sua frequenza, si può scegliere il tipo di storage, il numero e il taglio dei dischi, il tipo di controller, il numero degli alimentatori, ma molti dettagli non sono selezionabili, il perchè è talmente evidente che non sto nemmeno a spiegarlo.
Il punto fondamentale però è un altro, qual’è l’obbiettivo della selezione qualitativa delle componenti? Offrire una maggiore affidabilità per  ridurre i down (ricordate l’obbiettivo primario di un server?) e garantire la continuità dei servizi.
Proviamo per un attimo ad ignorare le misure di ridondanza spesso presenti sui server (schede di rete, alimentatori, array raid, ram etc etc) e pensiamo ad un guasto, il tempo per riprendere ad erogare il servizio è dato dal tempo necessario a procurarsi il componente da sostituire + il tempo necessario a sostituirlo + il tempo per riavviare il servizio stesso (presupponendo che non si siano verificate perdite di dati o corruzioni degli stessi).
Il punto che mi interessa ora è il primo (il secondo lo tratteremo più avanti), chi può garantire che un certo componente del vostro server assemblato sia disponibile a tempo indeterminato? Molto semplice, nessuno.
Chi può garantirvi degli SLA sui tempi di consegna dei pezzi di ricambio? Nessuno.
Quindi quali garanzie avete che a fronte di un guasto riusciate a procurarvi un pezzo di ricambio? Nessuna.
Una soluzione potrebbe essere quella di procurarsi in anticipo una scorta di pezzi di ricambio, ma questo farebbe lievitare i costi (abbiamo già detto che a parità di componenti i costi di una soluzione “brandizzata” sono già più vantaggiosi), richiederebbe un magazzino, e poi quanti pezzi di ricambio? Chi può prevedere in anticipo quali e quanti guasti si verificheranno nel ciclo di vita di un server?
Ebbene, con una soluzione “brandizzata” e un contratto di supporto semplicemente non vi ponete il problema, i pezzi di ricambio ci sono e ci saranno per un arco di tempo molto più lungo del ciclo di vita massimo ipotizzabile per qualsiasi server.

SUPPORTO TECNICO
Supponiamo che sul vostro server si verifichi un guasto e voi abbiate già in casa tutti i componenti per una sostituzione.
Anzitutto non è banale ne scontato riuscire a trovare velocemente la causa di un problema (da appassionato di hardware vi posso assicurare che certi problemi sulla ram o di alimentazione o sulla mainboard sono tutt’altro che semplici da diagnosticare), in secondo luogo dovete fermare qualsiasi cosa stiate facendo, smontare la macchina, sostituire il pezzo, rimontare tutto e far ripartire il server.
Potrò anche sbagliarmi, ma dubito fortemente che una azienda possa permettersi di pagare una persona per stare perennemente in attesa che si verifichi un guasto e possa intervenire senza interrompere altre attività, persino le aziende che hanno nel loro organico dei sistemisti non si possono permettere questo lusso, pertanto è ovvio che questa attività abbia un costo composto dal tempo impiegato per la riparazione + il tempo perso sulle altre attività su cui era impegnato il tecnico che è intervenuto (e che presumibilmente saranno più redditizie della riparazione del server).
E’ fin troppo ovvio il motivo per cui il supporto tecnico è il vero vantaggio di una soluzione server “bradizzata” e dev’essere sempre tra i primi fattori da considerare quando si prende in esame l’acquisto di una nuova macchina, e non solo per una pura questione di competenze (un tecnico che fa riparazioni per 8 ore al giorno sarà sicuramente più capace e veloce di un assemblatore “della domenica”) ma e soprattutto per una pura questione di costi.
Il costo di un contratto di supporto vi sembra elevato? Provate a stimare quanto tempo vi richiederà la riparazione (anche mezza giornata per certi tipi di guasto), sommate il tempo necessario per farvi recapitare il pezzo di ricambio (min 2/3 gg, ammesso e non concesso che sia ancora sul mercato), ora prendete questo valore e moltiplicatelo per il numero di persone coinvolte (chi effettua la riparazione e chi utilizza il servizio down) e per il costo medio di questo personale, al tutto sommate la mancata produttività di tutti questi durante il down. Vi sembra ancora così caro il contratto di supporto?

PAGAMENTI
Siamo sinceri, tutto quanto ho descritto fin’ora interessa noi tecnici, l’esperienza insegna che se proverete a spiegare tutto questo al vostro capo/manager/direttore gran parte di queste informazioni entreranno da un’orecchio ed usciranno dall’altro… forse solo la parte sui costi relativi al personale fermo per un guasto sortirà qualche effetto.
Tutti sappiamo che per chi si trova a guardare alla “big picture” (insomma i capi…) conta solo l’aspetto economico immediato, mai in prospettiva (ma allora che “big picture” stanno guardando? Mah…).
Proprio su questo aspetto i server “brandizzati” offrono soluzioni di acquisto infinitamente più vantaggiose e che ho notato quasi nessuno degli aspiranti sistemisti conosce; a meno che la vostra attività sia assemblare e rivendere pc, qualsiasi fornitore di hw non potrà darvi altra soluzione di pagamento del bonifico anticipato o carta di credito (scordatevi pertanto le riba), una brutta notizia per il capo…
Nel caso di un server “brandizzato” avrete invece come interlocutore una grande azienda o un grande distributore che offre servizi finanziari spesso molto vantaggiosi, ad esempio noleggio oppure leasing (giusto per citare le due formule più celebri), alla fine vi ritroverete a pagare qualcosa di più (a causa degli interessi) ma potrete spalmare la spesa in molto più tempo, non dovrete più smaltire il bene al termine del suo ciclo di vita (nel caso del noleggio) e sicuramente il vostro capo sarà più propenso ad approvare l’investimento.

Dopo questa lunga pappardella mi sembra ovvio che la soluzione “brandizzata” sia la più vantaggiosa sotto tutti i punti di vista, ho tralasciato alcuni aspetti più tecnici (es monitoraggio) il succo del discorso però è che il server è semplicemente uno strumento di lavoro, lo strumento deve lavorare per l’azienda, non viceversa.

Poco fa ho terminato Matro Last Light, sto cercando di fare mente locale e tirare le somme su questo gioco, ma confesso che sto facendo moltissima fatica…
Anche con il predecessore Metro 2033 avevo sperimentato le stesse identiche difficoltà, sto cercando di capire come mai, e più ci penso più finisco con l’associare questa serie al celebre Stalker Shadow of Chernobyl (e successivi titoli).

Metro Last Light è sicuramente un gioco molto curato, non tutto mi è piaciuto però è evidente che ogni aspetto del gioco è stato il risultato di un lavoro molto attento.
Per essere un fps la trama non solo esiste ma (incredibile dictu…) è persino piacevole, tecnicamente il gioco è davvero molto molto bello, le armi sono carine e abbastanza personalizzabili (avrei preferito ce ne fossero di più, e più diversificate), l’atmosfera poi non manca di certo.
La varietà di gioco è forse l’aspetto meno curato, in genere lo schema che caratterizza il gameplay è abbastanza ripetitivo, avanzamenti solitari (da affrontare preferibilmente in stealth) spezzati da qualche scena più concitata e le solite scene su mezzi motorizzati.

Quello che però mi ha più indispettito è l’eccessiva linearità, forse è proprio per questo che mentre penso alla serie Metro mi viene spontaneo ricordare la serie Stalker; atmosfere simili, ambientazioni altrettanto catastrofiche con qualche aspetto fantastico, ottima immedesimazione nel protagonista, da una parte (Metro) però c’è una linearità esagerata, dall’altra (Stalker) un modello caratterizzato da una libertà d’azione pressochè totale (oltre a uno schema ibrido tra fps e crpg).
Potendo scegliere ho sempre preferito quest’ultimo, e forse è proprio per questo che fin’ora nessuno dei due titoli della serie Metro mi ha soddisfatto quanto anche solo il peggiore della serie Stalker (Clear Sky).

Tirando le somme imho Metro Last Light è gioco carino, tecnicamente molto bello, con una discreta atmosfera ma deludente dal punto di vista del gameplay, penso che l’acquisto sia giustificato solo se si è fan della serie, altrimenti meglio passare il proprio tempo libero con altro (Stalker?).

Anche se ormai si è concluso da pochi minuti ci tenevo ad augurare ai quattro gatti a cui capita di leggere queste pagine buon Darwin Day!

Quale miglior modo di festeggiare questa importante ricorrenza se non consigliare un bellissimo libro che tratta proprio di evoluzione, scritto da scienziati con la S maiuscola e che spiega perchè il nostro bel cervellino fa così fatica a credere alla teoria dell’evoluzione ed è invece così fortemente attratto da maghi, fattucchiere o santoni di turno che propinano disegni intelligenti a destra e a manca.

Nati per credere
autori: Giorgio Vallortigara, Telmo Pievani, Vittorio Girotto
Codice Edizioni
ISBN: 978-88-7578-110-1

Buona lettura!

Ed eccomi qua, a circa un anno dall’inizio della mia prima esperienza con una tastiera meccanica a provare un nuovo esemplare, stavolta dotato di switch Cherry MX Blue, una fiammante CM Storm Quickfire XT ritirata giusto giusto stamattina dal celebre store Drako.it.

Era da tempo che stavo meditando di acquistare una nuova tastiera, non perchè non fossi soddisfatto della Ozone Strike, ma per la pura e semplice curiosità di (letteralmente) mettere le mani su un differente tipo di switch Cherry MX e quindi un feeling totalmente diverso.
Purtroppo sui miei primi pc non ho avuto la fortuna di utilizzare una tastiera meccanica, ricordo però con grande piacere e nostalgia le poche esperienze su pc altrui dotati di IBM Model M o simili, ricordo il gradevole feeling tattile degli switch, il piacevolissimo suono prodotto dalla digitazione, ecco perchè non ho avuto dubbi e per questa mia seconda tastiera meccanica ho scelto un modello dotato di Cherry MX Blue.

Esteticamente ho scelto un modello che imho rappresenta una via di mezzo tra le tastiere dal design tradizionale (es Cherry G80 oppure le bellissime Filco Majestouch) e le tastiere dal design stravagante e imho orripilante (pensiamo ad esempio ai modelli prodotti da Razer, piuttosto che le orribili Logitech da gaming).

La Quickfire XT si presenta con un design pulito ed essenziale ma caratterizzato da dimensioni compatte e da forme arrotondate, il lato che presenta il connettore usb (quasi minimalista nella sua semplicità) mostra soltanto il logo CMStorm posizionato sul lato opposto che trovo carino e discreto, per concludere i font selezionati per i keycap sono moderni quasi stilizzati.

Riguardo agli switch devo confessare che l’impressione iniziale è stata… “amore alla prima digitazione”, ancora adesso mentre scrivo queste poche righe mi si riempie il cuore a sentire questo piacevole “clickettio”, in fondo basta poco per fare felice un kender nerd :D

Tirando le somme confesso di essere ESTREMAMENTE SODDISFATTO, quando iniziai ad usare la Ozone Strike (che reputo ancora oggi una ottima tastiera, forse una delle migliori basate su switch MX Black) provai un po’ di disorientamento (forse dovuto anche al layout un po’ più compatto rispetto alla mia precedente – e mai rimpianta – Logitech G510) e sperimentai qualche errore di battitura di troppo (poi svaniti con l’abitudine), ora con questa Quickfire invece mi trovo immediatamente a mio agio e trovo la digitazione più piacevole, leggera (merito del minor sforzo attuativo degli switch) e veloce.
Unico neo è l’inevitabile suono (chiamarlo rumore non mi è possibile) prodotto dagli switch MX Blue che può causare grande fastidio in chiunque si trovi in stanza con voi mentre usate la tastiera.