CNIPA - Gruppo di lavoro sui benchmark per i server

Transcript

1 CNIPA - Gruppo di lavoro sui benchmark per i server Premessa Validità temporale delle indicazioni fornite. Il settore dei sistemi Server è, come è noto, in rapida e costante evoluzione tecnologica. Pertanto le indicazioni fornite dal presente documento, che, naturalmente, si riferiscono all attuale contesto tecnologico-applicativo, si devono considerare soggette ad una attività di periodico aggiornamento. 1 - Obiettivi del sottogruppo Nel discutere i benchmark da adottare nel caso di sistemi server, accogliendo alcune osservazioni contenute nel documento elaborato da AITech-Assinform, il gruppo di lavoro ha senz altro riconosciuto la maggiore articolazione e complessità di questo scenario rispetto a quello dei sistemi PC desktop e mobili. In particolare ci si è trovati d accordo sull opportunità, nel caso dei server, di affiancare a specifiche di gara relative ad aspetti prestazionali, e quindi riconducibili ai benchmark, anche specifiche riguardanti aspetti qualitativi, non prestazionali, ma almeno altrettanto importanti, quali: disponibilità, affidabilità, scalabilità, configurabilità, ridondanza, aspetti ergonomici e di risparmio energetico Il presente documento raccoglie le conclusioni del gruppo di lavoro e formula una proposta sulle linee d azione da adottare nella specifica dei requisiti per l acquisizione di sistemi server. 2 - Classificazione dei server Data l ampiezza e la varietà dei contesti applicativi, è comunque utile, se non necessario, procedere ad una classificazione delle tipologie di server. Ciò consentirà di specializzare e precisare per ciascuna tipologia le specifiche di qualità che si intende definire. Vengono a tale scopo individuati tre diversi criteri (o dimensioni) di classificazione: Costo/valore del sistema Piattaforma software Criterio di utilizzo 1/8

2 Per quanto riguarda la prima dimensione, si decide di assumere come riferimento operativo la classificazione adottata da Gartner Group, la quale considera il costo complessivo hw/sw del sistema ed individua tre classi: A. Costo/valore del sistema Volume/entry: costo fino a 10 K$ Midrange: costo da 10 K$ a 50 K$ Enterprise: costo oltre 50 K$ Per quanto riguarda la seconda dimensione, cioè la piattaforma software, l attuale situazione di mercato permette di individuare quattro classi: B. Piattaforma software Windows Unix proprietario Open source (Unix e Linux) Altre piattaforme proprietarie Per quanto infine riguarda la terza dimensione, cioè il criterio d uso, non appare percorribile la strada di una classificazione basata sul contesto applicativo, che porterebbe ad una eccessiva parcellizzazione. Appare invece ragionevole una schematizzazione che distingua le seguenti classi: C. Criterio di utilizzo Front-end: server inseriti in una architettura a più livelli in cui svolgono la funzione specializzata di gestione dell interazione con gli utenti Back-end: server inseriti in una architettura a più livelli in cui svolgono la funzione specializzata di application server o di database server General purpose/remote-end: server inseriti in architetture ad un solo livello e che non svolgono pertanto funzioni specializzate Considerando le tre dimensioni ortogonali sulle quali si articola la classificazione complessiva, occorre dire che non tutte le possibili combinazioni corrispondono a situazioni reali di effettivo interesse. Ci si propone pertanto di considerare la precisazione e la specializzazione delle specifiche che si verranno ricavando per le sole combinazioni di effettivo interesse. 3 - Specifiche riguardanti gli aspetti qualitativi La natura di questi aspetti fa sì che essi non possano essere facilmente ricondotti a metriche oggettive e di effettiva e generale applicabilità, come è invece possibile fare per l aspetto meramente prestazionale tramite l uso dei benchmark, seppure con le note difficoltà. Ad esempio, per quanto riguarda l affidabilità di un sistema, non appare sensato adottare metriche complessive come lo MTBF riferendole all intero sistema, per le ovvie ed insormontabili difficoltà 2/8

3 che le relative misure e collaudi comporterebbero. Si può invece pensare di associare nella valutazione del sistema valore, ed eventualmente punteggio, a precisi aspetti elementari ai quali l affidabilità del sistema sia effettivamente riconducibile. Tali potrebbero essere nel caso dell affidabilità la ridondanza di alcune componenti o la capacità di resistere a determinate tipologie di guasto. In generale sembra che la strada da percorrere sia quella di ricondurre la valutazione di ciascun aspetto qualitativo ad una serie di caratteristiche o criteri elementari. Verificando se e in che misura determinate caratteristiche siano presenti si può infatti procedere a confrontare sistemi diversi sotto il profilo di un dato aspetto qualitativo. Sulla base di questi principi la discussione nel gruppo di interesse ha portato a definire per i diversi aspetti qualitativi i seguenti criteri elementari Affidabilità e disponibilità L affidabilità è definita come la capacità di un sistema di operare in modo continuativo ed ininterrotto per lunghi periodi di tempo. Complessivamente può essere misurata tramite lo MTBF (Mean Time Between Failures) cioè tramite il valore atteso del tempo intercorrente tra due guasti che interrompono la continuità di funzionamento del sistema. Si tratta di una misura comunemente adottata per le singole componenti (e.g. i dischi), ma che non è pensabile di utilizzare per un sistema complesso e composito qual è un server, almeno nella grande generalità dei casi. La disponibilità di un sistema si misura come la probabilità che un utente ha, durante i periodi di tempo nei quali è previsto che il sistema sia operativo, di trovare il sistema funzionante ed in grado di offrire il suo servizio ai livelli stabiliti. Questa misura è strettamente legata all affidabilità, anche se a questa non è direttamente riconducibile, in quanto a determinarla concorrono anche altri elementi, quali le scelte relative all organizzazione della manutenzione del sistema, nonché scelte architetturali riguardanti l intero sistema informatico, e quindi non il server in quanto tale. In entrambi i casi si tratta quindi di una misura che non può essere utilizzata direttamente come specifica espressa a livello del sistema server, almeno nella grande generalità dei casi. Sulla base del principio sopra esposto, la specifica va invece riportata ad un insieme di caratteristiche strutturali che incidono sull affidabilità e la disponibilità dei sistemi server. In particolare il gruppo di lavoro ha individuato le seguenti caratteristiche: caratteristiche di affidabilità (MTBF) di alcuni componenti critici; presenza di meccanismi di rilevamento e di intervento hw/sw per monitorare situazioni anomale e garantire il funzionamento in sicurezza; capacità di funzionamento in presenza di guasti di singoli componenti con soluzioni quali: ridondanza del sistema di alimentazione; ridondanza del sistema di raffreddamento; ridondanza della memoria di massa; presenza di meccanismi di protezione della memoria RAM; Manutenibilità Si tratta di caratteristiche di progettazione e realizzazione che rendono agevole l individuazione dei guasti e l effettuazione degli interventi di manutenzione. È un aspetto di grande interesse perché incide significativamente sia sui costi di gestione del sistema, sia, indirettamente, sulla stessa disponibilità del sistema. Più in particolare caratteristiche elementari alle quali manutenibilità può essere ricondotta sono le seguenti: 3/8

4 accessibilità fisica delle varie componenti del sistema e semplicità degli interventi di manutenzione e sostituzione; presenza di sistemi di autodiagnostica; possibilità di effettuare interventi di manutenzione in remoto; possibilità di effettuare interventi a macchina funzionante; periodo di tempo per il quale il fornitore garantisce la disponibilità delle compenti necessarie alla manutenzione dell apparecchiatura, eventualmente tramite sostituzioni migliorative Scalabilità La scalabilità di un sistema è definita come la sua capacità di crescere rispetto alla sua configurazione iniziale in termini di risorse complessive, e quindi in termini di volume di lavoro che esso è in condizione di gestire. Nei sistemi server la scalabilità assume forme diverse in base alle tipologie di architettura, ed in una certa misura anche in dipendenza del contesto applicativo. Distinguiamo due tipi fondamentali di scalabilità. Scalabilità orizzontale. Secondo questo schema si consegue l aumento delle risorse complessive aumentando il numero di sistemi componenti in un architettura che prevede la suddivisione ed il bilanciamento del carico tra più sistemi. In questo caso la scalabilità di un sistema server è individuabile nei seguenti aspetti. Possibilità di affiancare ulteriori sistemi al sistema o ai sistemi previsti nella sua configurazione iniziale. Efficacia dei meccanismi previsti per il bilanciamento del carico e per conseguire un effettivo aumento della capacità di elaborazione. Scalabilità verticale. Secondo questo schema si consegue l aumento delle risorse complessive tramite l aumento delle risorse di base all interno di uno stesso sistema. In questo caso la scalabilità di un sistema server è rapportabile alla sua capacità di crescere per ciascuna delle risorse fondamentali che lo compongono: Processori. Memoria centrale. Connessioni (specificando banda e throughput). Ulteriore aspetto interessante, riconducibile in qualche modo alla scalabilità verticale, è costituito dalla configurabilità intesa come capacità che un sistema ha di integrare e di integrarsi con componenti eterogenee Impatto ambientale Sotto questo nome vengono riuniti una serie di aspetti relativi ai consumi energetici e all impatto che il sistema ha sull ambiente in cui esso opera. Per molti di questi aspetti è possibile fare riferimento a metriche oggettive, ed in certi casi anche a standard internazionali. Sotto questo punto si fanno anche convergere gli aspetti di ergonomia. Tolleranza alle condizioni ambientali. Intervalli di temperatura e umidità nei quali i sistemi devono poter operare in maniera regolare e senza errori. Silenziosità. Livello massimo di rumorosità (potenza sonora) con riferimento alle norme UNI EN ISO 9296 e UNI EN ISO Consumi elettrici e dissipazione termica. Valore massimo di potenza assorbita e potenza media dissipata. 4/8

5 Ergonomia. Caratteristiche di ergonomia migliorative rispetto a quanto stabilito dalle norme. Peso e ingombro. Nell ingombro sono incluse le superfici di servizio. 4 Caratteristiche prestazionali Rispetto alla misura delle prestazioni di un desktop o di un notebook nel caso dei server non si può prescindere dal tenere in considerazione le molteplici e diverse possibilità d impiego unitamente alla variabilità anche degli ambienti operativi. A causa di ciò non è affatto facile racchiudere un server all'interno di un valore di benchmark univoco slegandolo di fatto dall'applicazione e dal contesto in cui verrà utilizzato il sistema. Infatti, se nell'universo dei PC si può considerare la possibilità di definire differenti fasce applicative con unico benchmark, nel mondo dei server un'assunzione del genere correrebbe il rischio di vanificare completamente il significato del benchmark stesso. Un server è un sistema che, come dice il suo stesso nome, deve fornire un livello di servizio più elevato possibile ai client presenti all'interno della propria infrastruttura. Questa definizione diventa ancora più determinante quando si pensi alla tipologia di applicazioni che un server può eseguire, quali, ad esempio: File Server; Printer Server; Firewall; Proxy; Gateway; Mail server; Application server; Database server; Media Server ; High Performance Computing Ciascuna di queste applicazioni\ambienti applicativi richiederebbe specifici strumenti di benchmark con precisa definizione dei valori soglia e quant'altro. Quindi l'unico parametro utilizzabile per una corretta misurazione delle prestazioni di una specifica architettura, consisterebbe nell'esecuzione di un insieme di applicativi scelti in modo da rispecchiare, nel modo migliore possibile, le reali condizioni di utilizzo. In particolare gli ambienti di virtualizzazione devono essere considerati in modo specifico. Purtroppo, questo principio non è talvolta possibile quando le stesse condizioni di utilizzo non siano note a priori, o non sia facile od economico riprodurle in modo fedele. Tali considerazioni sottolineano come possa essere di fatto problematica l indicazione di un solo strumento di misura per le prestazioni dei Server. Occorre comunque distinguere fra benchmark sintetici ed applicativi. I primi esprimono un insieme di caratteristiche prestazioni tramite valori numerici non direttamente rapportabili al carico applicativo. I secondi misurano le prestazioni con diretto riferimento a particolari contesti applicativi. 5. Benchmark 5/8

6 5.1 - Benchmark Sintetici I macrocomponenti di un sistema di calcolo sono: Processore Memoria Cache I/O Per valutare l impatto di tali elementi sulle prestazioni del server sono stati sviluppati, da organizzazioni indipendenti benchmark specifici, cui corrisponde una documentazione dettagliata ed esauriente, ed una procedura consolidata di pubblicazione dei risultati. Il più comunemente usato è SPECCPU, il quale prevede due componenti Cint e CFP, rispettivamente rappresentanti di un carico con computazioni intere e in virgola mobile. Di norma, per i server di uso comune (non dedicati cioè ad applicazioni di calcolo numerico intensivo), il riferimento è costituito da Cint2006. Nell ambito di Cint, occorre segnalare la presenza di diversi indicatori tra i quali si suggerisce di adottare come riferimento SPECint per i sistemi monoprocessore e SPECint_rate per quelli multiprocessore, dato che quest ultimo indicatore tiene conto throughput complessivo. I suddetti benchmark, vista la loro natura e specificità tecnologica si riferiscono a misure prestazionali del processore e, quindi, non sempre molto applicabili ad ambienti server complessi ovvero con un numero di processori molto elevato. Si ribadisce comunque che tali benchmark, utilizzati in modo esclusivo, non sono esaustivi della classificazione prestazionale del server stesso, perché non tengono conto dell effetto sulle prestazioni di risorse significative, ed in primo luogo dell I/O. Un vantaggio del benchmark SPECCPU è costituito dal gran numero di risultati certificati e pubblicati, e dalla procedura ben definita e relativamente semplice con cui nuovi esperimenti possono essere condotti. Con riferimento alla classificazione di cui al paragrafo 2, per quanto detto, tale benchmark si rivela principalmente idoneo per i server di tipo general purpose Benchmark Applicativi In genere i benchmark applicativi non sono prodotti da organismi indipendenti (con l eccezioni di SPEC e TPC) e richiedono per la loro esecuzione un setup che, spesso, può risultare complesso e costoso. Per la suite SPEC si potrebbero considerare: SPECWeb2005 per i sistemi il cui uso finale è quello di un webserver; SPECJBB quando si tratterà di eseguire applicazioni Java; SPECSFS per file servers; Anche per questi benchmark esistono e sono facilmente reperibili un buon numero di risultati, per sistemi di differenti fornitori. La loro applicabilità risulta tuttavia condizionata da elementi legati alla specificità del contesto di utilizzo. Considerando la tipologia delle applicazioni nel settore pubblico, sembra comunque interessante l utilizzo del benchmark SPECWeb2005, per i sistemi che nella classificazione di cui al paragrafo 2 sono definiti come front-end. 6/8

7 Altri benchmark significativi, soprattutto per i sistemi database server, sono quelli del Transaction Performance Council (TPC). Fra questi, i più utilizzati sono quelli che individuano le caratteristiche di un server in ambiente transazionale (TPC-C), oppure per ambiente DataWarehouse (TPC-H). Per i benchmark applicativi in genere, e per i TPC in particolare, esiste un problema di replicabilità e di invecchiamento del benchmark stesso (non vicine alle tecnologie informatiche di oggi), nel senso che i risultati pubblicati sono in genere relativi a configurazioni piuttosto grandi e complesse, in cui intervengono uno o più server connessi a client e (spesso) sistemi storage. La loro riproduzione, di conseguenza, richiederebbe un investimento, in termini di tempo e risorse, molto rilevante. Pertanto per un utilizzo verso configurazioni diverse da quelle per cui esistono risultati ufficiali, i valori potrebbero essere eventualmente determinati attraverso complesse operazioni di estrapolazione, partendo da valori noti e certificati (da Organismi indipendenti ufficialmente riconosciuti). Tale possibilità si può applicare per le situazioni in cui non sia possibile far riferimento a valori puntuali di questo benchmark, Tali benchmark possono, comunque, essere utilizzati per la determinazione dell ordine di grandezza delle massime prestazioni raggiungibili.. Nel caso, infine, in cui l ambiente di produzione sia a priori definibile ed individuabile, sarebbe possibile fare riferimento a test specifici. In questo caso, però, dovrebbero essere usati solo nel caso in cui il benchmark sia effettivamente indicativo della destinazione finale d uso. Un esempio in tal senso potrebbe essere quello di sistemi server destinati ad ambienti ERP con applicazioni SAP. Va comunque considerato che si tratta di un benchmark proprietario, e che la realizzazione degli esperimenti può richiedere tempi non compatibili con quelli di procedure di gara. In relazione all utilizzo dei benchmark i fornitori possono dichiarare valori non pubblicati evidenziando la modalità in cui è stata determinata l equivalenza del valore proposto rispetto a quello richiesto. 6 - Uso delle specifiche nelle procedure di gara I criteri sopra definiti per gli aspetti qualitativi possono essere alla base di raccomandazioni riguardanti l inclusione di tali specifiche nei capitolati tecnici, e le relative assegnazioni di punteggio nei bandi di gara. Di fatto, data la grande varietà dei contesti, è possibile dare solo raccomandazioni di tipo generale, e occorrerà decidere di volta in volta quale peso dare a ciascuno dei criteri sopra enumerati. In particolare occorrerà stabilire nelle singole fattispecie cosa imporre come requisito minimo, e cosa invece considerare come un aspetto di qualità al quale riservare parte del punteggio tecnico. In ogni caso si ritiene che il fatto stesso che questi aspetti siamo esplicitamente indicati nella griglia di punteggio possa costituire una significativa spinta al miglioramento della qualità delle forniture, rispetto alla situazione corrente che troppo spesso si concentra esclusivamente sugli aspetti del prezzo e delle prestazioni. Inoltre si richiama l attenzione sul fatto, come previsto dalle attuali normative nazionali e comunitarie, di non utilizzare, nei documenti di gara (lettere invito, bandi, capitolati, ecc) specifiche tecniche che fanno riferimento a marchi o prodotti, determinando una restrizione della concorrenza. Né deve spaventare il fatto che ai criteri in questione non siano associate metriche oggettive, come nel caso dei benchmark. Ciò lascia evidentemente margini di discrezionalità in sede di valutazione, ma questo è nell ordine delle cose e non costituisce un problema se i valutatori, come si deve sempre supporre, operano in maniera coscienziosa. Occorre infatti ricordare che 7/8

8 discrezione non significa arbitrio, e che anche ciò che non è misurabile può essere valutato e quantificato in termini di elementi oggettivi. Del resto la pretesa di restringere la valutazione ai soli aspetti cui siano associabili metriche precise avrebbe come diretta ed indesiderabile conseguenza l esclusione dal processo di valutazione di tutti gli aspetti qualitativi per cui, come si è visto, ciò non è possibile. Questo comporterebbe, in ultima analisi, l impoverimento del processo di valutazione e l abbassamento dei livelli di qualità delle forniture, cioè il contrario di quello che si desidera. Sta poi agli stessi fornitori di ridurre tali margini di discrezionalità evidenziando tutto ciò che sia riconducibile ai criteri di qualità nelle loro relazioni tecniche, che sono (o dovrebbero essere) preparate con un occhio alla griglia di punteggio. Questo significa sottoporre all attenzione del valutatore una serie di elementi oggettivi che non potranno essere ignorati nell assegnazione del punteggio. Va infine osservato che, relativamente alla possibilità di utilizzo dei benchmark per i server, occorre attentamente considerare gli aspetti legati all onerosità dei test che possono comportare grossi problemi sia per fornitore che per il committente. 8/8