1 / 23

Profilazione utente in ambienti virtualizzati

UNIVERSITA’ DEGLI STUDI DI TRIESTEDIPARTIMENTO DI INGEGNERIA E ARCHITETTURA

Laureando: Pietro CORONA

Relatore:Massimiliano NOLICH

2 / 23

Introduzione

• Profilazione utente

o identificare alcuni comportamenti tipici degli utenti che utilizzano il

sistema

o creare i modelli di questi comportamenti misurando grandezze

proprie del sistema

o classificare il comportamento degli utenti in base ai modelli creati

o tema molto ampio, non limitato all’ambito informatico

o profilazione dell’utente che utilizza una macchina virtuale

3 / 23

Scenario applicativo

• Server farm

• gli utenti acquistano una macchina virtuale in base alle loro

esigenze

• sistema host su cui è eseguito un layer di virtualizzazione

• sul layer di virtualizzazione sono eseguite le macchine virtuali

• user profiling mediante tool pensato per sistemisti

4 / 23

Motivazioni

• la virtualizzazione è largamente impiegata dalle aziende per

abbattere i costi di gestione dell’infrastruttura informatica

• profilazione utente in ambienti virtualizzati è un problema ancora

in fase di studio

• la profilazione utente:

• consente di migliorare la qualità del servizio offerto

• consente di effettuare campagne di marketing mirate

• consente di rilevare i comportamenti anomali

5 / 23

Problema

• classificazione user behavior ≈ classificazione programmi in

esecuzione

Classificare il programma in esecuzione su una

macchina virtuale, attraverso l’analisi delle tracce di

esecuzione ricavabili dal virtual machine monitor.

6 / 23

Stato dell’arte

• In letteratura vengono proposti dei framework per l’analisi del workload su macchine virtuali in cui però non vengono presentati risultati sperimentali dettagliati ([MAER09] e [FA11])

• esistono dei lavori sulla classificazione dei programmi utilizzando i memory reference ([Mascots09],[Cec10])

• esistono dei tools commerciali (VmWare) per analisi del workloade supporto nell’allocazione delle risorse

7 / 23

Studio di fattibilità

• Analisi dei virtual machine monitor sul mercato:o è possibile ricavare tracce di esecuzioneo considerati solo quelli più diffusi (VmWare Player, Oracle Virtual

Box, VmWare vSphere Hypervisor)o dati ricavabili da ciascuno (quali, con che frequenza)o interfacciamento con programmi ad hoc

• Virtual Box risponde meglio alle esigenze:o informazioni stato interno macchina virtuale (0,5ms)o informazioni su utilizzo risorse (1s)o dati ricavabili da APIo SDK con client API per vari linguaggi

8 / 23

Scelte preliminari

• Tracce di esecuzione da utilizzareo memory reference: già utilizzati con successo per la

classificazione dei programmi ([Mascots09] e [Cec10])o indicatori sull’utilizzo delle risorse: utilizzati in letteratura per

effettuare la profilazione utente ([MAER09] e [FA11])

• Programmi per creare i modelli delle classi

• benchmark della suite Spec CPU2006:o già utilizzati per la classificazione dei programmio prove ripetibili in condizioni similio comportamento corrispondente a programmi di uso effettivo

9 / 23

Fasi di sviluppo

1. implementazione software acquisizione dati

2. analisi dei dati

3. progettazione e implementazione del sistema di classificazione

4. raccolta tracce per creazione modelli e test

5. test del sistema con tracce di programmi Spec e di programmi generici

10 / 23

1 – acquisizione dati(software sviluppato)

• Modalità di funzionamentoo online: acquisizione pilotata da host

o batch: acquisizione pilotata da programma client su VM

11 / 23

1 – acquisizione dati(impatto sulle performace)

• Non ha impatto significativo sulle performance della VM (1%)• con instrumentazione del codice tempo di esecuzione aumentava dai 3

ai 4 ordini di grandezza

12 / 23

2 – analisi dei dati(memory reference)

• segnale discreto tempo-variante• anche dopo il campionamento resta valido il principio di località• programmi diversi presentano andamenti temporali diversi

13 / 23

• ram libera, disco occupato, % cpu utente, % cpu kernel• dipendono dalla fase di elaborazione del programma• esecuzioni diverse dello stesso programma hanno andamenti simili• programmi diversi presentano andamenti temporali diversi

2 – analisi dei dati(indicatori utilizzo risorse)

14 / 23

3 – sistema classificazione(premessa)

• Due tipi di tracce di esecuzione diverse:o memory reference (0,5ms)

o indicatori utilizzo risorse (1s)

• prove con vari sistemi di classificazione:1. HMM

2. rete neurale

3. K-means

4. K-means + rete neurale

• il classificatore con le prestazioni migliori è risultato K-means + rete

neurale con entrambi i tipi di tracce di esecuzione

• due classificatori funzionanti

15 / 23

3 – sistema classificazione(training)

• divisione in frame:

o aumentare il numero di esempi

o svincolarsi da istante iniziale acquisizione

• divisione frame in blocchi e clusterizzazione per:o comprimere informazioni estraendo le features

o mantenere corrispondenza con sequenza temporale

• frame clusterizzate come input addestramento reti neurali

• output:o centroidi

o modelli (rete neurale addestrata)

16 / 23

3 – sistema classificazione(execution)

• traccia programma da classificare divisa in frame

• frame divisa in blocchi e clusterizzata con i centroidi

• frame clusterizzata in input a tutte le reti neurali addestrate

• output:o ∀ m in Modelli P(f ϵ m), massimo in modello classe programma

• processo usato per validation, test ed execution

17 / 23

3 – sistema classificazione(fusione dati)

• Abbiamo due classificatori => utilizzarli entrambi

• in ingresso:o P(f ϵ m) ∀ m in Modelli, per memory reference e indicatori

utilizzo risorse

• output:

o classe più probabile

18 / 23

4 – raccolta tracce

• Dataset finale composto da:

o 720 tracce di programmi Spec CPU2006 (bzip2, gcc, sjeng,

libquantum, omnetpp, perlbench, gobmk, astar, hmmer, h264ref,

o 40 tracce di programmi generici (compressore dati, compilatore)

o ogni traccia 10 minuti

o 14 GB

o 6 giorni di acquisizione

19 / 23

5 – test del sistema (I)

• Test del sistema con frame di 6 programmi Spec con 3 input:

• stima parametri

• 6 classi (bzip2, gcc, sjeng, libquantum, omnetpp, perlbench)

Classificatore % corretta classificazione

Memory reference 66%

Indicatori utilizzo risorse 56%

Fusione dati Dempster-Shafer 75%

• Questo non è sufficiente a dimostrare la validità del sistema:• sistema pensato per utilizzo con programmi qualsiasi

• pochi input disponibili per i programmi Spec

• utile per la creazione dei modelli

20 / 23

5 – test del sistema (II)

• Test del sistema con frame di programmi (generici compressore

dati e compilatore):• 6 classi (bzip2, gcc, sjeng, libquantum, omnetpp, perlbench)

• modelli creati come per il test precedente

• fusione classi che vengono confuse maggiormente

Classificatore 6 classi 5 classi

bzip2 + sjeng

5 classi

bzip2+libquantum

Memory reference 26% 30% 57%

Indicatori utilizzo risorse 40% 62% 31%

Fusione dati Dempster-Shafer 20%* 66% 63%

*spiegabile con il fatto che le % di corretta classificazione sono troppo basse

21 / 23

Riepilogo lavoro svolto

• Ricerca di materiale (articoli, libri, tesi, software) sull’argomento e

analisi di alcuni esempi

• studio tecniche di machine learning: reti neurali, HMM, K-means

• sviluppo software:

• raccolta tracce

• test del sistema

Programma L. P. Classi Righe di codice

Acquisizone dati Java 7 700

Framing C++ 1 320

Divisione blocchi e clustering C++ 6 1400

Train, execution rete neurale C++ 7 1300

Fusione dati DS C++ 2 300

Script automazione Bash - 200

22 / 23

Conclusioni

• Gli obiettivi inizialmente proposti sono stati raggiunti

• sia con memory reference sia con indicatori sull’utilizzo delle

risorse è possibile classificare i programmi in esecuzione

• l’utilizzo della fusione dati permette di migliorare il tasso di

corretta classificazione

• il tasso di corretta classificazione con 5 classi (66%) è

soddisfacente se confrontato con la probabilità a priori (20%)

• la scelta di 5 classi permette una buona differenziazione dello

user behavior

23 / 23

Sviluppi futuri

• Il lavoro svolto è da ritenersi un utile punto di partenza per

ulteriori approfondimenti sul tema

• selezione più accurata delle classi

• miglioramento usabilità tramite sviluppo add-on di Virtual Box

• ulteriori test ampliando l’insieme delle tracce di programmi non

Spec

• impiego di altri dati ricavabili dai virtual machine monitor

• impiego del sistema per workload characterization in ambienti di

produzione virtualizzati (es. Web server, dbms server, mail

server)

24 / 23

Fine

Grazie per l’attenzione!