Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Robustness Testing di middleware DDS-compliant tesi di laurea Robustness Testing di middleware DDS-compliant Anno Accademico 2010/2011 relatore Prof. Domenico Cotroneo correlatore Ing. Gabriella Carrozza candidato Sergio Celentano Matr. 885/211 Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Robustness Testing di middleware DDS-compliant Contesto e motivazioni Sistemi critici Basati su COTS (Commercial Off-The-Shelf) Complessi Large scale Integrazione di componenti eterogenei Scenari ATC Sistemi navali Sistemi ferroviari LCCIs Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Robustness Testing di middleware DDS-compliant Contesto e motivazioni “The Right Data in the Right Place at the Right Time” Affidabilità Scalabilità Robustezza Realtimeliness Integrazione e complessità minano l’affidabilità complessiva del sistema Necessità di metodologie e tecniche di dependability assessment Focus sulla robustezza Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Robustness Testing di middleware DDS-compliant Obiettivi e contributo COSA Definizione di una metodologia per la valutazione della robustezza in sistemi middleware COTS based COME Realizzazione di uno strumento automatico Generalizzabile User friendly Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Robustness Testing di middleware DDS-compliant Robustezza Un software si dice robusto se opera correttamente anche in presenza di condizioni anomale [IEEE Std 610.12.1990]. Middleware Robustness threats configurazione errata uso improprio di API a livello applicativo parametri di ritorno restituiti dal S.O. Hardware induced failures Middleware Robustness testing le API del middleware sono “bombardate” con una combinazione di valori validi e non Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Robustness Testing di middleware DDS-compliant L’ approccio proposto 1. Analisi delle API del middleware. 2. Definizione del Fault Model e Failure Model. 3. Scelta del workload e dello scenario d’uso più opportuno per la campagna di test. 4. Design e implementazione di un tool per l’iniezione automatizzata dei guasti. 5. Esecuzione delle campagne di test. 6. Analisi dei risultati. Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Robustness Testing di middleware DDS-compliant Il caso di studio: SWIM BOX & OpenSplice DDS PrismTech OpenSplice SWIM-BOX Sviluppata per consentire la condivisione dei dati in scenari ATC Interazione tra sistemi “legacy” Basata su diverse tecnologie per la data distribution JMS DDS Modello Publisher/Subscriber Fully DDS-compliant Tecnologia Data-centric e Real-Time Discovery automatico dei partecipanti Qualità del servizio customizzabile Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Robustness Testing di middleware DDS-compliant Il tool di FINJ: Java Fault Injection Tool Agisce da wrapper delle API del middleware Intercetta le chiamate effettuate dall’applicazione workload ai metodi pubblici del middleware. Behavioral reflection tramite libreria Javassist. Architettura basata su pattern per la FINJ Sottomissione dei guasti completamente automatizzata Workload rappresentativo Workload Benchmark Touchstone by PrismTech. 2 differenti scenari: OLAP DB locale distribuito Injection library OLAP DB per l’analisi • dei risultati OpenSplice Java API Fault library Log file FINJ Tool Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Robustness Testing di middleware DDS-compliant Analisi dinamica Ogni run si compone dei seguenti passi: 1. 2. 3. Selezione del metodo target dalla “method list” Per ogni parametro in ingresso viene individuato un set di faults, dato il tipo del parametro Per ogni fault è previsto un esperimento diverso Dopo ogni esperimento di FINJ è eseguita una golden run per sollevare eventuali hidden failures. Alla fine dell’esperimento il sistema viene ripristinato. Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Robustness Testing di middleware DDS-compliant Scenario Workload: Benchmark Touchstone by PrismTech per sollecitare le API del middleware. Scenario: un processo Transmitter che invia 10 messaggi ad un processo Receiver. Testbed locale Transmitter e Receiver sono modellati come thread in esecuzione sulla stessa macchina. Testbed distribuito Transmitter e Receiver sono collocati su due nodi differenti. Transmitter application_id = 1 write ThroughputTopic x 10 read Receiver application_id = 2 partition_id = 50 Transmitter application_id = 1 write ThroughputTopic x 10 read Receiver application_id = 2 Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Robustness Testing di middleware DDS-compliant Campagna dei test, risultati PrismTech OpenSplice Community Edition 4.3 14 metodi analizzati 400 esperimenti effettuati 2 scenari considerati Default Qos: consegna messaggi “Best Effort” Aspetti di rilievo: Fallimenti modellati con scala CRASH Comportamento mediamente robusto (eccezione sollevata conforme alle specifiche) Due fallimenti di tipo “Silent” osservati, uno più grave (messaggi non trasmessi) Fallimenti “hang” non replicabili Nessun evento di tipo catastrophic/abort/hindering osservato. Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Robustness Testing di middleware DDS-compliant PROS & CONS PROS Automatizzazione una volta configurato, il tool opera in totale autonomia. Generalizzabilità Minimo effort richiesto per il testing su differenti implementazioni dello standard DDS CONS Metodi statici Al momento il tool di fault injection intercetta i soli metodi pubblici e nonstatic. Parametri di tipo primitivo L’iniezione del guasto avviene sui soli parametri di tipo primitivo presenti nella firma del metodo. Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Robustness Testing di middleware DDS-compliant Conclusioni e sviluppi futuri Conclusioni La metodologia individuata è efficace anche in un contesto complesso come quello dei COTS I risultati sono valorizzati dalla rappresentatività degli elementi che compongono il caso di studio Sviluppi futuri Quality of Service Ampliamento set di parametri in ingresso Ampliamento set di metodi Confronto con altri middleware DDS