07/05/2014

Cache write-through vs write-back

Una delle cose che spesso vengono sottovalutate nella configurazione dello storage in RAID con parità (tipicamente RAID5) è l’importanza della batteria tampone e conseguentemente la configurazione della cache write-back anzichè write-through.

Molti pensano che la batteria tampone sia una sorta di gadget, bello e soprattutto costoso, perchè diciamocela tutta, queste miserabili e banalissime batterie al litio sono care come il fuoco, e se esistesse una divinità della giustizia vedremmo fulmini cadere h24 sulle sedi di Adaptec, LSI, IBM, Dell, HP e tutte le altre società coinvolte in questo sanguionosissimo mercato…
Purtroppo l’utente medio (almeno questa è la mia esperienza frequentando varie realtà aziendali) è portato a pensare “Massì, è già tanto se abbiamo un controller raid hardware, noi non siamo così enterprise da aver persino bisogno della batteria…”. oppure “Ok, cosa cambiera mai con la batteria o senza… i dati sono comunque al sicuro”.

Tralasciamo i commenti su questa sensazione di finta sicurezza (“shit happens”, e non è questione di se, ma di quando…), il fatto è che le batterie tampone servono, e non solo per permettere la corretta esecuzioni delle transazioni di I/O, ma anche per una pura e semplice questione legata alle performance degli array con parità, più nello specifico le politiche di utilizzo della cache nell’esecuzioni delle attività di scrittura.
Non smetterò mai di lottare contro gli array RAID5 e RAID6, uno dei motivi per i quali osteggio questo genere di configurazione è la cosidetta write penalty, ovvero il sovraccarico di IOPS dovuto calcolo e salvataggio della parità durante ciascuna attività di scrittura; per tamponare questo handicap i controller dotati di batteria tampone utilizzano la cache del controller in modalità write-back (ovvero asincrona), in caso contrario utilizzano la più sicura modalità write-through (sincrona), per una spiegazione più esaustiva rimando a questa pagina di Wikipedia.

Se pensate che questa differenza possa essere marginale date un’occhiata al grafico che segue, queste sono le prestazioni di una lun su san IBM DS4300 con array raid5 composto da tre dischi SCSI Ultra320 da 10.000 rpm durante una banale import di uno schema Oracle 9 su GNU/Linux iniziata alle ore 01:00AM (non le 13:00).
San preistorica, server ancora più antiquato, storage malridotto, sistema operativo antidiluviano (RedHat Enterprise 3), tutte ottime ragioni per giustificare delle performance così basse, guardate però la differenza tra le prestazioni antecedenti alle ore 13:00 (batteria nuova in carica e cache write-through attiva) e dopo le ore 13:00 (batteria online e cache write-back)… non ho altro da aggiungere.

io-cache

02/03/2014

Server assemblato

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.

11/02/2014

CM Storm Quickfire XT

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.

quickfireXT00

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.

quickfireXT02

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

quickfireXT03
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.

quickfireXT05

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.

quickfireXT01

28/11/2013

Seagate ST2000DM001

In quest’epoca di continue evoluzioni sul fronte solid state fa un po’ specie parlare di un buon vecchio disco meccanico, sta di fatto che mi sono acchiappato un esemplare di suddetto disco Seagate.

Confesso di essere sempre stato più propenso ad acquistare unità di questo produttore rispetto all’agguerrito concorrente Western Digital, non ho pregiudizi ne verso quest’ultimo produttore, semplicemente le unità Seagate su cui ho lavorato mi hanno più favorevolmente impressionato per performance e affidabilità.

Pare che queste mie impressioni abbiano trovato un’ulteriore conferma con questa unità, senza pormi alcun problema su settaggi da bios o altro l’ho connessa, partizionata, formattata e ho lanciato due benchmark veloci veloci giusto per non saper ne leggere ne scrivere…

HDTune_Benchmark_ST2000DMST2000DM001-1CH1

crystal_disk_seagate2GB

Ma guarda un po’… e chi se le sarebbe aspettate queste performance da un disco meccanico, per giunta economico!
Stiamo a vedere come si comporterà in futuro, per il momento lasciatemi levare tanto di cappello di fronte a questo ennesimo gioiellino Seagate.

22/08/2013

Muletto ARM

Dalle analisi degli accessi noto con grande piacere che c’è sempre grande interesse riguardo ai server domestici, se preferite “muletti”.

Di recente il mio storico Epia 5000A ha subito un brutto colpo, una serie di guasti allo storage l’hanno costretto ad un down forzato, vista poi la difficoltà a reperire hard disk PATA sono stato costretto ad acquistare un adattatore IDE-SATA il quale a sua volta mi ha costretto a ritrasferire l’Epia nel primo storico case a causa di problemi di spazio (fisico stavolta).

Naturalmente nessun dato è stato perso grazie ai rigorosi piani di backup che ho implementato nel tempo, questa pausa però mi ha spinto a riflettere un po’ sul futuro del mio server domestico.
In tal senso l’esperienza con Raspberry PI è stata illuminante, le possibilità software sono pressochè le stesse del mio Epia x86, l’assorbimento è di gran lunga inferiore (meno di 1/5 in idle, addirittura circa 1/9 a pieno carico), la temperatura da dissipare pressochè trascurabile, gli ingombri ridottissimi, le performance simili.
L’unico aspetto limitante di Raspberry PI è lo storage, dover ricorrere ad un disco usb alimentato mediante un hub usb rappresenta un vero scoglio, o per lo meno trasformerebbe quello che oggi è un bel case ordinato e compatto in una foresta di mangrovie di cavi.

Una soluzione ci sarebbe, si tratta del progetto Fairywren, una mainboard mini-itx a cui connettere Raspberry PI con tutto l’occorrente per storage, rete, alimentazione, hub usb interno, un piccolo gioiellino che sta nascendo su Kickstarter e che rappresenterebbe una vera manna per chi come me vorrebbe usare Raspberry come server domestico.

7c2e31c35874e3490fd698071c48ca52_large

 

Frequentando vari forum però mi è stato giustamente fatto notare che al di la dell’hype generato dal progetto Raspberry PI è basato su un SoC relativamente antiquato e piuttosto limitato in termini di risorse, idem per quanto riguarda progetti simili tipo BeagleBone.
Così sono venuto a conoscenza di altri progetti molto più interessante, magari meno rivolti alla ricerca o alla sperimentazione ma dotati di più risorse, insomma il perfetto punto di contatto tra le esigenze server e i vantaggi delle architetture ARM.

Due hanno attirato la mia attenzione, entrambi dotato di SoC Cortex A20 dual core, entrambi dotati di 1GB di ram DDR3 e un canale SATA, si tratta di:

Cubieboard 2

Cubieboarda2

Olimex A20-OLinuXino-MICRO

A20-OLinuXino-MICRO-0

Entrambi ottimi progetti, simili dal punto di vista hardware ma differenti come approccio e filosofia di base.
Cubieboard 2 ha al suo attivo una comunità abbastanza diffusa, un forum piuttosto popolato e un layout piuttosto compatto, OLinuXino A20 è meno diffuso, un layout più “affollato”, una comunità meno popolosa ma è dotato di un gran numero di interfacce GPIO (quindi molto più indicato per la ricerca e applicazioni pratiche, un approccio simile a Raspberry PI per intenderci), entrambi sono progetti open hardware.

Di per se sarei fortemente attratto da entrambi questi progetti, l’unico aspetto che mi lascia dubbioso è il layout di questi sistemi, bellissimo e compatto ma difficilmente integrabile con un case ordinato e altrettanto compatto, insomma se dovessi utilizzarli mi ritroverei con una foresta di mangrovie di cavi come con Raspberry PI

Quasi in risposta alle mia suppliche il team di Cubieboard ha annunciato un nuovo progetto open hardware chiamato Cubietruck che prevede:

  • SoC A20 Cortex-A7 Dual Core
  • 1 o 2 GB di ram
  • canale SATA
  • interfaccia di rete Gbps

ma soprattutto grande attenzione al layout, tanto da essere sovrapposto a quello di un hard disk da 2.5″, e addirittura pubblicando un prototipo di case veramente fantastico.

CT_YKL-3

 

Mio al DAY1!!!

[EDIT]

Good news! Sembra che la produzione di Cubietruck stia per iniziare! Yuppi!!!! :)

« Post precedenti | Post successivi »