Università degli Studi di Padova

Università degli Studi di Padova Dipartimento di Matematica Corso di Laurea in Informatica

SNMP per il recupero di metriche applicative Tesi di laurea triennale Relatore Prof. Massimo Marchiori

Anno Accademico 2015-2016

Laureando Matteo Zilio

iii

Legge di Hofstadter "Per fare una cosa ci vuole sempre più tempo di quanto si pensi, anche tenendo conto della legge di Hofstadter."

All’altra parte di me, alla mia Famiglia, a tutti coloro che mi vogliono bene.

v

Sommario Il presente documento descrive il lavoro svolto durante il periodo di stage in InfoCert S.p.A. presso la sede di Padova. Lo stage è durato 8 settimane, dal 5 ottobre al 27 novembre 2015, per un totale di 320 ore lavorative e ha avuto come obiettivo la realizzazione di un sistema di raccolta di metriche generate dalle applicazioni in un ottica di data warehouse. Il documento inizia dunque con la presentazione dell’azienda e la descrizione del prodotto da realizzare, successivamente vengono illustrate le principali tecnologie che sono state utilizzate per la realizzazione del sistema. Verrà introdotta l’analisi del progetto con la presentazione delle scelte che sono state effettuate, a seguire la spiegazione di come è stata implementata la soluzione per poi concludere con la parte di verifica e le considerazioni finali.

Indice 1 Introduzione 1.1 L’azienda . . . . . . . . . . . . . . . . . . . . . 1.2 Prodotti dell’azienda . . . . . . . . . . . . . . . 1.2.1 Legalmail - Posta Elettronica Certificata 1.2.2 LegalCert - Firma digitale . . . . . . . . 1.2.3 LegalDoc - Conservazione sostitutiva . . 1.2.4 Legalinvoice - Fatturazione elettronica . 1.3 L’area sistemi . . . . . . . . . . . . . . . . . . .

. . . . . . .

1 1 2 2 3 3 4 5

2 Descrizione del progetto 2.1 Requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7 8

3 Tecnologie usate 3.1 Protocollo UDP . . . . . . . . . . . . . 3.2 Protocollo SNMP . . . . . . . . . . . . 3.2.1 Management Information Base 3.2.2 Struttura delle comunicazioni . 3.2.3 Sicurezza del protocollo . . . . 3.3 Net-SNMP . . . . . . . . . . . . . . . 3.4 SNMP4J . . . . . . . . . . . . . . . . . 3.5 Virtualizzazione . . . . . . . . . . . . . 3.5.1 Data Center . . . . . . . . . . . 3.5.2 Cluster . . . . . . . . . . . . . 3.5.3 Host . . . . . . . . . . . . . . . 3.5.4 Virtual Machine . . . . . . . . 3.6 NetEye . . . . . . . . . . . . . . . . . . 3.6.1 Nagios . . . . . . . . . . . . . . 3.6.2 Cacti . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . . . . . . . . . .

11 11 12 12 13 15 16 16 16 18 18 18 18 18 18 19

4 Analisi del progetto 4.1 Estensione del MIB . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Architettura delle comunicazioni . . . . . . . . . . . . . . . . 4.2.1 Sistema gestito . . . . . . . . . . . . . . . . . . . . . .

21 22 22 24

vii

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

viii

INDICE 4.2.2 4.2.3

Agente di gestione . . . . . . . . . . . . . . . . . . . . Sistema di gestione . . . . . . . . . . . . . . . . . . . .

24 26

5 Implementazione della soluzione 27 5.1 Creazione del MIB . . . . . . . . . . . . . . . . . . . . . . . . 27 5.2 Estensione dell’agente . . . . . . . . . . . . . . . . . . . . . . 29 5.3 Impostazione del manager . . . . . . . . . . . . . . . . . . . . 32 6 Verifica e test

35

7 Conclusioni

37

Bibliografia

39

Glossario

41

Elenco delle figure 1.1 1.2 1.3 1.4 1.5

Logo Logo Logo Logo Logo

InfoCert S.p.A. Legalmail . . . LegalCert . . . LegalDoc . . . Legalinvoice . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

2 3 3 4 4

3.1 3.2 3.3 3.4

Struttura ad albero del MIB . . . . . . . . . . . . Diagramma di sequenza di una richiesta SNMP . Diagramma di sequenza di una trap SNMP . . . Architettura dell’infrastruttura di virtualizzazione

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

13 14 14 17

4.1

Protocollo AgentX: comunicazioni fra i diversi attori . . . . .

25

5.1

Diagramma di attività di una richiesta SET . . . . . . . . . .

31

ix

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

Elenco delle tabelle 2.1

Requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

4.1 4.2 4.3

KPI Legalmail . . . . . . . . . . . . . . . . . . . . . . . . . . KPI LegalCert . . . . . . . . . . . . . . . . . . . . . . . . . . KPI LegalDoc . . . . . . . . . . . . . . . . . . . . . . . . . . .

23 23 23

5.1 5.2

Tipi di dato utilizzabili in un MIB . . . . . . . . . . . . . . . Valori possibili per la clausula MAX-ACCESS . . . . . . . . .

28 29

xi

Capitolo 1

Introduzione In questo capitolo verrà introdotta la realtà aziendale nella quale si è svolto il progetto di stage.

1.1

L’azienda

InfoCert si pone sul mercato come un partner altamente specializzato nei servizi di Certificazione Digitale e Gestione dei documenti in modalità elettronica, capace di garantire ai propri clienti la piena innovazione nei processi di gestione del patrimonio documentale e informativo. Con un fatturato, nel 2014, di 41 milioni di euro, InfoCert è leader a livello europeo per i processi di conservazione digitale dei documenti a norma di legge e per i servizi di Posta Elettronica Certificata, ed è una delle maggiori Certification Authority (CA) in Italia per la firma digitale. InfoCert progetta e sviluppa soluzioni informatiche ad alto valore tecnologico di dematerializzazione dei processi documentali, attraverso componenti di gestione documentale, conservazione digitale, firma digitale e posta elettronica certificata. I clienti vengono accompagnati nella scelta di servizi e soluzioni pienamente rispondenti alle esigenze organizzative, così come ai vincoli normativi generali e specifici di settore. InfoCert propone al mercato tre componenti di offerta: Consulenza Esperienza, dinamismo e flessibilità caratterizzano la progettazione e la realizzazione della soluzione più adatta per una gestione completamente digitale della documentazione. InfoCert guida il Cliente nel passaggio dalla gestione cartacea a quella digitale, ottimizzando i flussi documentali e favorendo l’adozione degli strumenti a supporto della dematerializzazione, anche in modalità SaaS; Tecnologia Soluzioni modulari, affidabili e sicure, ad alta qualità tecnologica e applicativa, con piena soddisfazione del Cliente. Continui aggiorna1

2

CAPITOLO 1. INTRODUZIONE menti e importanti partnership tecnologiche garantiscono a InfoCert esclusive competenze in ambito di progettazione e sviluppo;

Servizi Application Service Provider (ASP) L’offerta InfoCert si declina in famiglie di servizi, basate su tecnologia di ultima generazione. Le suite InfoCert comprendono servizi e soluzioni per la gestione di Posta Elettronica Certificata (Legalmail), la certificazione e la sicurezza digitale (LegalCert), la conservazione digitale a norma dei documenti (LegalDoc), il servizio di fatturazione elettronica (Legalinvoice).

Figura 1.1: Logo InfoCert S.p.A.

1.2 1.2.1

Prodotti dell’azienda Legalmail - Posta Elettronica Certificata

La posta elettronica certificata (PEC) è un tipo particolare di posta elettronica, disciplinata dalla legge italiana, che permette di dare a un messaggio di posta elettronica lo stesso valore legale di una raccomandata con avviso di ricevimento tradizionale garantendo così il non ripudio. Anche il contenuto può essere certificato e firmato elettronicamente oppure criptato garantendo quindi anche autenticazione, integrità dei dati e confidenzialità. L’utilizzo della PEC si sta rapidamente diffondendo grazie alle caratteristiche precedentemente descritte, oltre che nei rapporti con la Pubblica Amministrazione, anche in molti altri settori privati. Una trasmissione può essere considerata posta certificata solo se le caselle del mittente e del destinatario sono entrambe caselle di posta elettronica certificata, altrimenti il sistema potrà fornire solo una parte delle funzionalità di certificazione previste (per esempio, non viene fornita la ricevuta di avvenuta consegna). I gestori di posta certificata sono obbligati a registrare tutti i principali eventi che riguardano la trasmissione per 30 mesi da fornire come prova da parte degli interessati. I gestori sono anche tenuti ad utilizzare sempre un riferimento orario allineato con gli istituti ufficiali che garantiscono l’ora esatta. Quindi tutti gli elementi che compongono il servizio conterranno sempre l’ora esatta.

1.2. PRODOTTI DELL’AZIENDA

3

Figura 1.2: Logo Legalmail

1.2.2

LegalCert - Firma digitale

La firma digitale è il risultato di una procedura informatica che consente a chi firma un documento digitale di rendere manifesta e garantire: • L’autenticità, cioè che il documento è originale; • La paternità, ossia chi ha firmato il documento; • L’integrità, ovvero che il documento non sia stato modificato dopo essere stato firmato digitalmente. Il soggetto che voglia firmare digitalmente i propri documenti deve essere titolare di un certificato digitale di sottoscrizione, contenuto in un dispositivo di firma (smart card o chiave USB). In particolare, questo dispositivo permette di utilizzare una chiave crittografica "privata" univoca e segreta, che consente l’apposizione della firma digitale; la chiave "pubblica" correlata, resa disponibile in rete dall’Ente Certificatore emittente, consentirà invece ogni successiva verifica. La firma digitale presenta vantaggi in termini di semplificazione dei rapporti tra aziende e tra queste e gli enti pubblici. Si pensi all’invio di un qualsiasi documento cartaceo: va scritto, stampato, firmato e poi spedito tramite posta tradizionale. Con la firma digitale si firma il documento attraverso dispositivi elettronici e lo si invia elettronicamente, senza stamparlo. Si risparmia, quindi, in costi di stampa del cartaceo e tempi di trasmissione, con la sicurezza dell’inalterabilità dei contenuti.

Figura 1.3: Logo LegalCert

1.2.3

LegalDoc - Conservazione sostitutiva

La conservazione sostitutiva è una procedura legale/informatica regolamentata dalla legge italiana, in grado di garantire nel tempo la validità legale di un documento informatico, inteso come una rappresentazione di atti o fatti e dati su un supporto sia esso cartaceo o informatico (delibera CNIPA 11/2004).

4

CAPITOLO 1. INTRODUZIONE

La conservazione sostitutiva equipara, sotto certe condizioni, i documenti cartacei con quelli elettronici e dovrebbe permettere alle aziende e all’amministrazione pubblica di risparmiare sui costi di stampa, di stoccaggio e di archiviazione. Il risparmio è particolarmente alto per la documentazione che deve essere, a norma di legge, conservata per più anni. Conservare digitalmente significa sostituire i documenti cartacei, che per legge alcuni soggetti giuridici sono tenuti a conservare, con l’equivalente documento in formato digitale che viene “bloccato” nella forma, contenuto e tempo attraverso la firma digitale e la marca temporale. È infatti la tecnologia della firma digitale che permette di dare la paternità e rendere immodificabile un documento informatico, affiancata poi dalla marcatura temporale permette di datare in modo certo il documento digitale prodotto.

Figura 1.4: Logo LegalDoc

1.2.4

Legalinvoice - Fatturazione elettronica

Nella prospettiva della fatturazione elettronica "in senso stretto" la fattura è il documento amministrativo per eccellenza, il più importante documento aziendale in grado di rappresentare nel tempo un’operazione commerciale, e da cui scaturiscono risvolti fiscali (detrazione dell’IVA e deducibilità del costo), civili (ingiunzioni di pagamento ed efficacia probatoria tra imprenditori), penali (reati tributari e reati commessi dal fallito) e finanziari (la gestione del credito e la riconciliazione della fatture ai pagamenti ed agli incassi). La fatturazione è dunque intesa come quel processo che parte dalla composizione della fattura – in generale da parte del fornitore di beni/servizi – e si conclude generalmente con l’archiviazione della fattura sia da parte del fornitore che da parte del cliente secondo quanto prescritto per legge e che può prevedere, se richiesto dall’Agenzia delle Entrate, la messa a disposizione delle fatture conservate per accertamenti fiscali. Con fatturazione elettronica ci si riferisce alla possibilità di emettere e conservare le fatture in solo formato digitale.

Figura 1.5: Logo Legalinvoice

1.3. L’AREA SISTEMI

1.3

5

L’area sistemi

L’area sistemi all’interno dell’azienda ha il ruolo di far funzionare correttamente tutta l’infrastruttura necessaria alla corretta erogazione dei servizi offerti. Le persone all’interno dell’area sistemi sono ulteriormente suddivise in sotto-aree per competenze: Operation gestisce il datacenter dell’azienda, si occupa quindi del monitoraggio e del ruolo di help desk di primo livello; Middleware si occupa di gestire il livello software che sta fra le applicazioni e i sistemi operativi come Web server, Application server, sistemi di gestione dei contenuti ed altri strumenti basati sul concetto di sviluppo e pubblicazione di applicazioni e contenuti; Network si occupa della progettazione, sviluppo, realizzazione, verifica e controllo dei sistemi di connessione LAN e WAN. Stabilisce, realizza e verifica le politiche e i protocolli per l’accesso alle strutture di rete. Si occupa della configurazione e gestione dei router, degli switch, dei proxy, dei firewall e di tutti i dispositivi comunque connessi alla rete; Storage gestisce i sistemi a disco e a nastro all’interno dell’azienda. Le responsabilità includono lo sviluppo di un programma di gestione dello storage e modalità di backup di routine; Database cura, in collaborazione con il team di sviluppo, la progettazione fisica dei database e delle funzioni dirette di gestione. Segue, in monitoraggio costante, l’evoluzione dei database, in termini di volumi, accessi, tempi di risposta e malfunzionamenti. Organizza ed esegue le operazioni di manutenzione ordinaria, straordinaria e le procedure di sicurezza, come i backup ordinari, straordinari e gli eventuali ripristini a seguito di malfunzionamenti; Informatica individuale si occupa della sicurezza e del buon funzionamento di tutti gli strumenti (sia hardware che software) che l’azienda mette a disposizione dei dipendenti per svolgere il proprio lavoro.

Capitolo 2

Descrizione del progetto Ad oggi l’area sistemi ha un completo monitoraggio in tempo reale di tutta la parte hardware che compone il data center. Purtroppo non si può dire la stessa cosa per quanto riguarda la parte software. Le metriche che vengono attualmente raccolte, lato software, riguardano principalmente informazioni per l’accounting ovvero registrano, misurano e documentano le risorse utilizzate da un utente durante la fruizione di un particolare servizio, questo al fine di poter applicare la corretta tariffazione al cliente. Attualmente queste metriche vengono scritte dalle applicazioni su dei file di log che periodicamente vengono analizzati per estrarne le informazioni utili. L’intenzione dell’azienda è quella di ampliare dunque il pacchetto di metriche applicative raccolte andando a definire nuovi Key Performance Indicator (KPI) al fine di capire: • Come impatta, sui sistemi, il carico delle diverse applicazioni; • I trend di crescita/decrescita delle singole applicazioni, in un ottica di data warehouse. L’obiettivo di questo progetto è quindi quello di andare a popolare un cruscotto, con dati forniti dalle applicazioni, dal quale poter capire quanto stanno erogando i singoli servizi. A tal fine, utilizzare la tecnica dei file di log per recuperare anche le nuove metriche che si intende implementare presenta subito alcune lacune: • L’analisi dei dati a posteriori non permette un controllo real time della situazione; • La scrittura, frequente, di un numero maggiore di metriche su disco può degradare pesantemente le prestazioni delle applicazioni. La principale richiesta da parte dell’azienda è che la soluzione proposta non vada ad appesantire l’applicazione monitorata; bisognerà porre attenzione 7

8

CAPITOLO 2. DESCRIZIONE DEL PROGETTO

affinché la raccolta delle nuove metriche sia meno invasiva possibile infatti più la misurazione è invasiva più l’applicazione degrada le proprie performance. Un’altra richiesta è che, per il recupero delle nuove metriche, si utilizzi il protocollo di comunicazione SNMP, questo fondamentalmente per due motivi: • È uno standard per collezionare e organizzare informazioni riguardanti l’infrastruttura; • L’attuale infrastruttura di rete, essendo InfoCert anche una CA, ha dei requisiti di sicurezza che impongono firewall e chiusure al fine di rispettare le normative. Le porte utilizzate dal protocollo SNMP sono già aperte sulla rete e qualunque altro protocollo o soluzione richiederebbe di impostare regole e aperture specifiche su tutti gli apparati di rete.

2.1

Requisiti

In questa sezione vengono riportati in forma tabulare i requisiti che il progetto dovrebbe soddisfare. Ogni requisito è descritto da un codice che lo identifica univocamente e da una descrizione. I requisiti possono essere di vari tipi: funzionali, di qualità, prestazionali o di vincolo e avere gradi di importanza diversi; per questo, ognuno di essi è identificato da un codice con il seguente formalismo: R[importanza][tipo][codice] dove, importanza assume uno tra i seguenti valori: • 0: requisito obbligatorio; • 1: requisito desiderabile; • 2: requisito opzionale. tipo assume uno tra i seguenti valori: • F: requisito funzionale; • Q: requisito di qualità; • P: requisito prestazionale; • V: requisito di vincolo. e codice rappresenta il codice univoco di ogni requisito.

2.1. REQUISITI

9

Tabella 2.1: Requisiti Requisito

Descrizione

R0F1

Individuare i KPI per l’applicazione Legalmail

R0F2

Individuare i KPI per l’applicazione LegalCert

R0F3

Individuare i KPI per l’applicazione LegalDoc

R0F4

Estendere il MIB con i nuovi KPI individuati

R0F5

Creare un estensione per l’agente SNMP in modo che possa gestire i nuovi KPI

R0F6

Definire l’interfaccia di collegamento fra gli applicativi esistenti e l’agente SNMP

R0F7

Aggiungere al manager SNMP i nuovi KPI

R1F8

Creare grafici dei nuovi KPI sul manager SNMP

R2F9

Implementare sul manager SNMP una gestione dei dati in ottica di data warehouse

R0V10

Il sistema dovrà utilizzare SNMP come protocollo di comunicazione

R0V11

Il manager utilizzato sarà la piattaforma NetEye

R0V12

Consegnare i manuali operativi stesi seguendo le norme aziendali

Capitolo 3

Tecnologie usate In questo capitolo verranno presentate le principali tecnologie utilizzate nel progetto con lo scopo di fornire un background al lettore per affrontare i capitoli successivi.

3.1

Protocollo UDP

User Datagram Protocol (UDP) è uno dei principali protocolli di rete della suite di protocolli Internet [7]. È un protocollo di livello di trasporto a pacchetto, usato di solito in combinazione con il protocollo di livello di rete IP. A differenza del Transmission Control Protocol (TCP), l’UDP è un protocollo di tipo connectionless, inoltre non gestisce il riordinamento dei pacchetti né la ritrasmissione di quelli persi, ed è perciò generalmente considerato di minore affidabilità. In compenso è molto rapido (non c’è latenza per riordino e ritrasmissione) ed efficiente per le applicazioni "leggere" o time-sensitive. Ad esempio, è usato spesso per la trasmissione di informazioni audio-video real-time come nel caso delle trasmissioni Voip. L’UDP fornisce soltanto i servizi basilari del livello di trasporto, ovvero: • Multiplexing delle connessioni, ottenuta attraverso il meccanismo di assegnazione delle porte; • Verifica degli errori (integrità dei dati) mediante una checksum, inserita in un campo dell’intestazione (header) del pacchetto, mentre TCP garantisce anche il trasferimento affidabile dei dati, il controllo di flusso e il controllo della congestione. L’UDP è un protocollo stateless, ovvero non tiene nota dello stato della connessione dunque ha, rispetto al TCP, meno informazioni da memorizzare: un server dedicato ad una particolare applicazione che scelga UDP come protocollo di trasporto può supportare quindi molti più client attivi. 11

12

CAPITOLO 3. TECNOLOGIE USATE

3.2

Protocollo SNMP

Simple Network Management Protocol (SNMP) è un protocollo a livello di applicazione, definito in [2], per introdurre una semplice architettura per la gestione di reti basate sulla suite di protocolli UDP/IP. Tale protocollo definisce le modalità di scambio di informazioni tra apparecchiature di rete, consentendo agli amministratori di tenere sotto controllo le performances e di accorgersi in tempo reale del manifestarsi di malfunzionamenti. Attualmente il protocollo presenta tre definizioni successive: SNMPv1, SNMPv2c, SNMPv3. La versione più recente introduce nel protocollo alcune nuove funzionalità e correzioni, soprattutto nel campo della sicurezza. I tre componenti logici del protocollo SNMP, fondamentali per il suo funzionamento sono: • Sistema gestito (managed object); • Agente di gestione (master agent) e vari subagent (su sistema gestito); • Sistema di gestione (manager) da remoto. Il protocollo SNMP è attualmente quello più diffuso per la gestione delle reti di calcolatori, con una curva di apprendimento abbastanza ripida (ho ritenuto utile la consultazione di [4]), è supportato praticamente da tutti i produttori di hardware ed apparecchiature di rete. Ogni sistema gestito (per esempio un semplice nodo, un router, una stampante o qualsiasi altro dispositivo che fornisca un’interfaccia di gestione SNMP) ospita un agente di gestione (master agent) e solitamente un certo numero di subagent. Il master agent ha almeno il ruolo di intermediario fra il manager (che è l’applicazione remota che prende le decisioni di gestione, per esempio sotto il controllo diretto dell’operatore umano) e i subagent (che sono gli esecutori di tali decisioni).

3.2.1

Management Information Base

Le informazioni o caratteristiche che è possibile gestire per una particolare apparecchiatura, mediante il protocollo SNMP, verranno indicati come oggetti gestiti. L’insieme di questi oggetti costituisce un’astrazione di database detto Management Information Base (MIB). Ogni agente possiede una lista contenente tutti gli oggetti che dovrà gestire e che potranno via via essere chiesti dal sistema di gestione. Ad esempio un oggetto può rappresentare lo stato di funzionamento di una interfaccia (up, down. . . ). Il MIB può essere pensato come un database di oggetti gestiti. Ogni tipo di informazione alla quale può accedere un sistema di gestione è definito in un MIB. In pratica come un dizionario raccoglie in sè tutte le

3.2. PROTOCOLLO SNMP

13

Figura 3.1: Struttura ad albero del MIB parole con i relativi significati, così un MIB definisce un nome per un oggetto e ne spiega il significato. Gli oggetti gestiti sono organizzati secondo una gerarchia ad albero e ad ogni nodo è associato un intero e un riferimento testuale; il percorso che va dalla radice dell’albero all’oggetto gestito è definito come OID (Object IDentifier). Un OID è dunque costituito dalla concatenazione delle chiavi dei nodi attraversati per raggiungere l’oggetto gestito, separate da punti; si possono usare indifferentemente le sequenze di numeri o di parole. Come si vede in figura 3.1 ogni nodo ha un riferimento sia numerico che letterale, per cui, volendo riferirsi al nodo denominato "enterprise" dovremmo concatenare l’ID di ogni nodo attraversato dal cammino, l’OID risultante sarà dunque iso.org.dod.internet.private.enterprise che è equivalente a 1.3.6.1.4.1. Esiste un’organizzazione, Internet Assigned Numbers Authority (IANA), che gestisce e regolamenta le concessioni di spazi all’interno dell’albero, sotto il nodo private, per privati, istituzioni, organizzazioni e compagnie.

3.2.2

Struttura delle comunicazioni

Il protocollo mette a disposizione due distinte tipologie di comunicazione fra manager e agenti: • Richieste; • Trap.

14

CAPITOLO 3. TECNOLOGIE USATE

Figura 3.2: Diagramma di sequenza di una richiesta SNMP

Figura 3.3: Diagramma di sequenza di una trap SNMP La richiesta è un’azione di interrogazione sincrona, come mostrato in figura 3.2, tramite la quale il manager richiede determinate informazioni, le quali saranno utilizzate per determinare lo stato dei dispositivi di rete e della rete stessa. La trap è un messaggio spedito dall’agente al manager, come mostrato in figura 3.3, non sollecitato da quest’ultimo, quindi non in risposta ad una interrogazione, per comunicare l’avvenimento di un particolare evento; in questo caso il manager dovrà gestire, in maniera "straordinaria", le informazioni ricevute. Le operazioni di cui SNMP dispone sono: • GET Utilizzato per richiedere valori specifici all’agente; • GETNEXT Viene utilizzato per percorrere un sotto albero del MIB in

3.2. PROTOCOLLO SNMP

15

ordine lessicografico crescente ed ottenere il primo valore non nullo, successivo a quello specificato nella richiesta, in esso contenuto; • GETBULK Si effettua un’unica richiesta che interessa una grande quantità di dati per prelevare più OID con il minimo numero di pacchetti; • SET Permette di impostare un valore nell’agente; • TRAP Notifica asincrona da parte di un agente al manager in seguito al verificarsi di un evento; • INFORM Eredita il funzionamento delle trap con la differenza che chi invia questo comando rimane in attesa di conferma della ricezione; • RESPONSE Utilizzato per rispondere a tutte le richieste, tranne alle trap.

3.2.3

Sicurezza del protocollo

Date le caratteristiche con le quali è stato ideato il protocollo, ovvero per la gestione remota di sistemi, ogni agente deve essere in grado di proteggere e regolare l’accesso ai propri MIB. La prime due versioni di SNMP (v1 e v2c) utilizzano una semplice protezione nella comunicazione, introducendo il concetto di community. Una SNMP community definisce sia il metodo di autenticazione sia la politica di controllo degli accessi. Ad ogni community viene assegnato un nominativo unico (community name) che sarà noto a tutte le stazioni coinvolte in quella particolare relazione (manager e agenti). Il community name svolge quindi il ruolo di parola chiave nella comunicazione tra i vari sistemi, garantendo una limitata autenticazione nella richiesta di informazioni. Il community name è presente in ogni messaggio SNMP inviato e viene considerato valido nel momento in cui siano compatibili i nominativi di comunità dei sistemi trasmittente e ricevente. Ogni agente può, inoltre, definire più comunità associate ad un particolare sottoinsieme di MIB caratterizzate da una particolare modalità di accesso: o di sola lettura, o di lettura e scrittura. La terza versione del protocollo (v3) ha introdotto tutta una serie di nuove funzionalità relative alla sicurezza che mancavano nelle versioni precedenti. Fra le principali troviamo: • Lo User-based Security Model (USM) è il modulo di sicurezza predefinito per SNMPv3 e contiene un elenco di utenti e dei relativi attributi [1]; • Il View-based Access Control Model (VACM) è il modulo per il controllo dell’accesso e determina quali utenti sono autorizzati ad accedere alle informazioni contenute nel MIB, questo consente diversi livelli di accesso per le diverse sezioni della struttura MIB [8]. Inoltre, tramite diversi livelli di sicurezza, si può stabilire se consentire un accesso:

16

CAPITOLO 3. TECNOLOGIE USATE • Senza autenticazione; • Con sola autenticazione; • Con autenticazione e codifica dei dati.

3.3

Net-SNMP

Net-SNMP è una suite di applicativi per utilizzare e sviluppare il protocollo SNMP (supporta v1, v2c, v3 e il protocollo AgentX subagent) [6]. È largamente distribuito incluso in molti sistemi operativi fra cui molte distribuzioni principali di Linux, FreeBSD, OpenBSD, Solaris, e Mac OS X. È inoltre disponibile sul sito web di Net-SNMP. La suite contiene: • Una libreria generica per i client; • Una suite di applicazioni a riga di comando; • Un agente SNMP espandibile e moduli per i linguaggi Perl e Python. Le applicazioni consentono di implementare le operazioni definite dal protocollo SNMP, mentre l’agente permette alla macchina che lo ospita di essere gestita da un manager, può quindi essere interrogata o generare trap.

3.4

SNMP4J

SNMP4J è un implementazione, open source e di livello enterprise, del protocollo SNMP per il linguaggio Java SE/EE 1.4 o successivi. SNMP4J supporta la generazione dei comandi, per l’implementazione dei manager, come anche la generazione di risposte, per l’implementazione degli agenti. Il design orientato agli oggetti è stato ispirato dalla famosa Application Programming Interface (API) SNMP++ per il linguaggio C++.

3.5

Virtualizzazione

La virtualizzazione è una tecnologia software collaudata che consente di eseguire simultaneamente più sistemi operativi e applicazioni sullo stesso server. La virtualizzazione sta trasformando il panorama IT e sta cambiando radicalmente il modo di utilizzare la tecnologia. La virtualizzazione consente di aumentare l’agilità, la flessibilità e la scalabilità dell’IT, oltre a ridurre notevolmente i costi. L’IT è più facile da gestire e richiede meno spese di capitale e operative grazie alla distribuzione più rapida dei carichi di lavoro, al miglioramento delle prestazioni e della disponibilità e all’automazione delle operations. Alcuni dei vantaggi portati dalla virtualizzazione sono:

3.5. VIRTUALIZZAZIONE

17

Figura 3.4: Architettura dell’infrastruttura di virtualizzazione • Costi di capitale e operativi ridotti; • Alta disponibilità delle applicazioni; • Downtime ridotto al minimo o eliminato; • Miglioramento di produttività, efficienza, agilità e reattività dell’IT; • Provisioning più rapido e semplice di applicazioni e risorse; • Supporto di Business Continuity e Disaster Recovery; • Gestione centralizzata. Il software in uso, all’interno dell’azienda, per realizzare la virtualizzazione è VMware vSphere. Di seguito vengono elencati e descritti i componenti che realizzano l’infrastruttura, mostrata in figura 3.4.

18

3.5.1

CAPITOLO 3. TECNOLOGIE USATE

Data Center

Un data center è il contenitore primario di oggetti, come host e virtual machine. Dal data center, è possibile aggiungere e organizzare gli oggetti. In genere, si possono aggiungere ad un data center host, cluster e cartelle per organizzare il tutto. Gli oggetti all’interno di un data center possono interagire tra loro. Ad esempio, è possibile spostare una virtual machine tra i diversi host all’interno di un data center.

3.5.2

Cluster

Un cluster è un gruppo di host. Quando si aggiunge un host a un cluster, le risorse del host diventano parte delle risorse del cluster. Il cluster gestisce le risorse di tutti gli host all’interno di esso.

3.5.3

Host

Un host è un computer che utilizza software di virtualizzazione per eseguire le virtual machine. Gli host forniscono alle virtual machine le risorse (principalmente CPU e memoria) e danno loro accesso allo storage e alla connettività di rete.

3.5.4

Virtual Machine

Una virtual machine è un computer software che, come un computer fisico, esegue un sistema operativo con delle applicazioni. Un sistema operativo installato su una virtual machine viene chiamato sistema operativo guest. Poiché ogni virtual machine è un ambiente di elaborazione isolato, è possibile utilizzare le virtual machine come ambienti desktop o workstation, come ambienti di test o di consolidare le applicazioni server. Le virtual machine possono essere eseguite su host o cluster. Lo stesso host può eseguire più virtual machine.

3.6

NetEye

NetEye é un sistema di monitoraggio open source su base Nagios e Cacti in utilizzo all’interno dell’azienda.

3.6.1

Nagios

Nagios è una nota applicazione open source per il monitoraggio di computer e risorse di rete. La sua funzione base è quella di controllare nodi, reti e servizi specificati, avvertendo quando questi non garantiscono il loro servizio o quando ritornano attivi. Alcune delle funzionalità di Nagios sono:

3.6. NETEYE

19

• Monitoraggio di servizi di rete (SMTP, POP3, HTTP, NNTP, ICMP, SNMP, FTP, SSH); • Monitoraggio delle risorse di sistema (carico del processore, uso dell’hard disk, log di sistema sulla maggior parte dei sistemi operativi, anche per Microsoft Windows); • Monitoraggio remoto supportato attraverso tunnel SSH o SSL; • Semplici plugin che permettono agli utenti di sviluppare facilmente nuovi controlli per i servizi in base alle proprie esigenze, usando bash, C++, Perl, Ruby, Python, PHP, ecc.; • Controlli paralleli sui servizi; • Capacità di definire gerarchie di nodi di rete usando nodi "parent", permettendo la distinzione tra nodi che sono down e nodi non raggiungibili; • Notifiche quando l’applicazione riscontra problemi o la loro risoluzione (via email, SMS o con altri sistemi, per mezzo di plugin aggiuntivi); • Capacità di definire "event handler", ovvero azioni automatiche che vengono attivate all’apparire o alla risoluzione di un problema; • Rotazione automatica dei file di log; • Supporto per l’implementazione di monitoring ridondante; • Interfaccia web per la visualizzazione dell’attuale stato, notifiche, storico dei problemi, file di log, ecc.

3.6.2

Cacti

Cacti è uno strumento open source per il monitoraggio il cui punto di forza è la capacità di realizzare grafici a partire dai dati acquisiti. Viene generalmente utilizzato per creare grafici temporali ad esempio per il carico della CPU o per l’utilizzo della larghezza di banda. Il front end può gestire utenti multipli, ognuno con il proprio set di grafici, il che può risultare utile nei casi sia presente un hosting di servizi per i quali il cliente richiede di poter procedere in autonomia alla gestione dei monitoraggi. Le caratteristiche principali di Cacti includono: • Aggiunta degli host da interfaccia web; • Gestione dei grafici gerarchia; • Gestione utenti multipli e relativi permessi di visualizzazione; • Template per host simili.

Capitolo 4

Analisi del progetto In questo capitolo verranno presentate, discusse e scelte le diverse soluzioni possibili per la realizzazione del progetto descritto nel capitolo 2. Si è reso necessario da subito un confronto con gli sviluppatori delle applicazioni interessate dalla nuova raccolta delle metriche al fine di capire le caratteristiche delle applicazioni e cosa possono o non possono fare. Le applicazioni sono sviluppate in linguaggio Java e distribuite con tecnologia ASP, vengono quindi eseguite su degli application server; in particolare, all’interno dell’azienda è in uso JBoss. Tutte le applicazioni che offrono servizi all’esterno dell’azienda (quindi rivolte ai clienti) vengono implementate in alta affidabilità, ciò significa che vengono avviate più istanze della stessa applicazione e ogni istanza viene fatta girare su una propria virtual machine; questo consente innanzitutto di suddividere il carico di lavoro generato dagli utenti dell’applicazione su diverse virtual machine ma sopratutto permette di erogare il servizio anche nel caso una parte delle virtual machine risulti temporaneamente indisponibile (a causa di guasti, per attività di manutenzione programmata, . . . ). Vista l’architettura delle applicazioni si ritiene utile procedere alla raccolta delle metriche per ogni singola istanza in modo da poter ad esempio valutare se il carico totale generato dalle applicazioni viene ben suddiviso sulle diverse istanze. Un’altra considerazione da fare in questa fase riguarda il livello di sicurezza da utilizzare con il protocollo SNMP. Come già descritto nella sezione 3.2.3, il protocollo presenta tre versioni che si differenziano principalmente per il livello di sicurezza offerto nelle comunicazioni. Visto che le metriche da raccogliere sono ad esclusivo uso interno e che la rete aziendale, nella quale il progetto deve essere implementato, è di per sé già molto protetta, si ritiene che l’utilizzo del protocollo in una delle sue due prime versioni (v1 o v2c) possa essere più che sufficiente. Comunque una scelta di cambio versione risulta di semplice implementazione. 21

22

CAPITOLO 4. ANALISI DEL PROGETTO

4.1

Estensione del MIB

Per poter gestire, tramite il protocollo SNMP, le nuove metriche si rende necessario innanzitutto estendere un ramo del MIB. La sezione del MIB che sarebbe più appropriato estendere con il nuovo sotto-albero aziendale sarebbe quello "enterprise" che ad oggi conta più di 47000 numerazioni già assegnate. L’azienda però non è in possesso di un proprio numero identificativo rilasciato da IANA che permette di essere proprietari di un ramo del MIB. Dato che questo MIB non dovrà essere rilasciato pubblicamente, in quanto le metriche raccolte sono solo per uso interno all’azienda, si è scelto di estendere il ramo "experimental" scegliendo un numero abbastanza elevato in modo che non ci possano essere interferenze in seguito a future assegnazioni, infatti anche il ramo "experimental" prevede l’assegnazione di un numero da parte di IANA ma attualmente sono occupate solo le prime 126 numerazioni. iso.org.dod.internet.experimental.InfoCert sarà dunque la radice del nuovo MIB e a partire da questo nodo si andranno ad aggiungere tutti i nodi con le informazioni che dovremo gestire. Nel primo livello definito al di sotto della radice precedentemente descritta saranno definiti i nodi che rappresentano le applicazioni da monitorare ovvero: • Legalmail (descritta in 1.2.1); • LegalCert (descritta in 1.2.2); • LegalDoc (descritta in 1.2.3). Al secondo livello, internamente ad ogni nodo che definisce un’applicazione, saranno contenute le metriche specifiche che corrisponderanno ai KPI dell’applicazione stessa. Nelle tabelle 4.1, 4.2 e 4.3 vengono presentati i KPI che sono stati individuati per le applicazioni precedentemente descritte. Anche se potranno essere presenti più istanze della stessa applicazione da monitorare, le metriche da inserire nel MIB saranno comunque uniche. Sarà poi compito del manager distinguere il valore della metrica per le diverse istanze, infatti quando il manager richiede ad una determinata virtual machine il valore di una certa metrica, l’agente risponderà con il valore che l’istanza dell’applicazione ospitata avrà potuto calcolare.

4.2

Architettura delle comunicazioni

Lo scopo del progetto è far pervenire le informazioni, generate dalle applicazioni, al manager. Al fine di realizzare al meglio l’infrastruttura richiesta, utilizzando il protocollo SNMP, risulta conveniente analizzare singolarmente i diversi attori coinvolti.

4.2. ARCHITETTURA DELLE COMUNICAZIONI

23

Tabella 4.1: KPI Legalmail Macro funzione

KPI

Ricevuta di accetta- Tempo medio, calcolato in un arco di 5 minuti, che zione del messaggio intercorre dal momento in cui il server di front-end originale riceve l’ok all’invio del messaggio al momento in cui viene generata la ricevuta di accettazione Tempo di uscita del messaggio

Tempo medio, calcolato in un arco di 5 minuti, che intercorre dalla generazione della ricevuta di accettazione all’uscita reale del messaggio sul punto di uscita

Generazione ricevuta di consegna

Tempo medio, calcolato in un arco di 5 minuti, che intercorre dall’arrivo di un messaggio PEC al momento della generazione della ricevuta di consegna

Invio ricevuta di conse- Tempo medio, calcolato in un arco di 5 minuti, che gna intercorre dal momento della generazione della ricevuta di consegna al punto di uscita verso il mittente

Tabella 4.2: KPI LegalCert Macro funzione

KPI

Richiesta di marcatura

Tempo medio, calcolato in un arco di 5 minuti, che intercorre dal momento in cui il server riceve la richiesta di marcatura al momento in cui restituisce il documento al gestore

Servizio di firma del Numero di hash firmati al minuto hash Emissione del certifica- Tempo medio, calcolato in un arco di 5 minuti, di to rilascio del certificato lato CA Tempi di registrazione

Tempo medio, calcolato in un arco di 5 minuti, di registrazione dei dati dell’utente nell’archivio

Tabella 4.3: KPI LegalDoc Macro funzione

KPI

Calcolo dell’impronta

Tempo medio, calcolato in un arco di 5 minuti, di calcolo dell’impronta dei documenti

Esibizione

Tempo medio, calcolato in un arco di 5 minuti, di esibizione a norma del documento conservato

24

CAPITOLO 4. ANALISI DEL PROGETTO

4.2.1

Sistema gestito

L’applicazione da monitorare deve rendere disponibili le informazioni che intende far avere al manager, per fare questo è possibile implementare due diverse soluzioni: 1. Pubblicare le informazioni tramite API e lasciare che sia l’agente a preoccuparsi di recuperarle; 2. Mettere a disposizione dell’applicazione una libreria per il protocollo SNMP in modo che sia l’applicazione stessa ad inviare le informazioni all’agente. Dal confronto con gli sviluppatori è emerso che una soluzione del primo tipo non è desiderabile. Se venissero implementate delle API infatti l’agente dovrebbe preoccuparsi di andare ad interrogare l’applicazione per recuperare le informazioni; questa soluzione, nei momenti di maggior carico, non farebbe altro che peggiorare la situazione. Fra applicazione ed agente dovrebbe infatti instaurarsi l’ennesima connessione, inoltre nei casi più critici, l’agente potrebbe vedersi rifiutare la connessione direttamente dall’application server. Si è quindi scelto di implementare la seconda soluzione creando un framework per Java che possa essere utilizzato da tutte le applicazioni. Il framework deve permettere l’invio all’agente, tramite operazioni SET del protocollo SNMP, delle metriche da raccogliere; le metriche devono poter essere inviate a scansioni temporali precise o ad evento. Vista inoltre l’architettura distribuita che caratterizza le applicazioni, si ritiene che l’agente vada installato su ogni macchina nella quale giri un’istanza dell’applicazione, questo consente infatti di avere un controllo puntuale sulle singole istanze di ogni applicazione. Le metriche dovranno quindi essere inviate, tramite il framework, all’agente installato in locale sulla stessa macchina.

4.2.2

Agente di gestione

Era stato consigliato l’utilizzo della libreria openSNMP per sviluppare l’agente, dopo essermi informato ho invece proposto l’utilizzo della libreria Net-SNMP in quanto, a differenza della prima, presenta una più ricca documentazione e molti tutorial [6]. L’agente che viene installato col pacchetto Net-SNMP viene definito master agent e porta con sé le funzionalità necessarie a pubblicare via SNMP tutte le informazioni di base del sistema. Per poter gestire nuove variabili definite in MIB auto-prodotti è necessario indicare all’agente come e dove reperire le informazioni associate. Ci sono diverse soluzioni per estendere l’agente: 1. Classe compilata direttamente nel codice dell’agente;

4.2. ARCHITETTURA DELLE COMUNICAZIONI

25

Figura 4.1: Protocollo AgentX: comunicazioni fra i diversi attori 2. Modulo caricato dinamicamente (dlmod); 3. Comunicazione con un altro agente (subagent). Le prime due soluzioni prevedono che le estensioni siano strettamente legate al master agent, tanto che un eventuale caduta delle estensioni provocherebbe anche la caduta del master agent al quale sono collegate. L’unica differenza fra le prime due soluzioni è che con la prima, per ogni modifica da effettuare sull’estensione, si deve obbligatoriamente ricompilare tutto il pacchetto Net-SNMP, mentre con la seconda no. La terza soluzione invece prevede che l’estensione (o subagent) sia implementata come un’entità separata dal master agent e che i due agenti parlino fra loro utilizzando il protocollo AgentX [3]. Quest’ultima soluzione permette di implementare il subagent con il linguaggio preferito (grazie alla grande varietà di librerie disponibili per i diversi linguaggi) senza rinunciare alle API fornite per le prime due soluzioni. Per l’estensione di questo progetto si è quindi optato per la terza soluzione e la figura 4.1 mostra come avvengono le comunicazioni fra manager, master agent e subagent. Vista la scelta della seconda soluzione al punto precedente l’agente dovrà rimanere in ascolto sulla porta UDP 161 (definita dallo standard) in attesa di eventuali SET effettuate dall’applicazione. Una volta ricevuta l’informazione, l’agente dovrà essere in grado di:

26

CAPITOLO 4. ANALISI DEL PROGETTO • Registrare il valore inviatogli, sovrascrivendo il valore precedente (se presente); • Analizzare il dato ricevuto e, se esce da un range precedentemente definito, inviare una trap.

4.2.3

Sistema di gestione

Il compito del manager è quello di interrogare gli agenti, in base a dei tempi prestabiliti, tramite il protocollo SNMP, per recuperare le metriche e salvarle, deve inoltre rimanere in ascolto sulla porta UDP 162 (definita dallo standard) in attesa di eventuali trap inviate dagli agenti. Il manager dovrebbe avere anche le seguenti caratteristiche: • Presenta una dashboard che possa evidenziare eventuali situazioni critiche; • È in grado di gestire una grande mole di dati in un ottica di data warehouse; • È in grado di aggregare, per esempio, i dati delle diverse istanze della stessa applicazione per fornire visioni di insieme; • È in grado di fornire dei grafici interattivi sull’andamento di una specifica metrica.

Capitolo 5

Implementazione della soluzione In questo capitolo verrà presentato il lavoro effettivamente svolto per il progetto descritto nel capitolo 2.

5.1

Creazione del MIB

Un MIB, fisicamente, è rappresentato da un file con estensione txt il cui nome sarà quello che andrà poi definito anche internamente. A seconda di quante informazioni vanno inserite nel MIB si può inserire tutto nello stesso file o si può suddividere in file separati che rappresentano parti diverse dell’albero. La definizione di un MIB inizia con la dichiarazione del nome (uguale al nome del file) e con le dichiarazioni di importazione dei tipi che verranno usati, definiti in altri MIB. I tipi di dato che possono essere gestiti in un MIB vengono presentati in tabella 5.1 e sono tutti contenuti nel MIB denominato SNMPv2-SMI. Una volta importato tutto il necessario si procede con la definizione vera e propria del nodo radice del MIB che si sta estendendo. Si dichiara tramite la direttiva MODULE-IDENTITY che si sta definendo un nuovo nodo, si inserisce data e ora dell’ultimo aggiornamento, l’entità alla quale appartiene, dei recapiti per poter contattare il proprietario, il nome del nodo padre che il nuovo ramo andrà ad estendere e l’ID univoco per il nuovo nodo. Terminata la definizione del nodo radice che estende l’albero MIB si può procedere con la definizione dei nodi sottostanti. Si è deciso di raggruppare le metriche per applicazione, quindi sotto il nodo radice vanno inseriti i nodi che, non rappresentando nessuna metrica, funzionano solo da contenitori logici, questo si può fare grazie al tipo OBJECT IDENTIFIER. Rimangono ora da definire le variabili, definite nella sezione 4.1, che conterranno le metriche applicative tramite la direttiva OBJECT-TYPE. Per ogni variabile se ne definisce il tipo (descritti in tabella 5.1), il livello 27

28

CAPITOLO 5. IMPLEMENTAZIONE DELLA SOLUZIONE

Tabella 5.1: Tipi di dato utilizzabili in un MIB Tipo di dato

Definizione

INTEGER

Sono interi con segno nell’intervallo da −231 a 231 − 1 (estremi inclusi)

OCTET STRING

Rappresentano dati binari o testuali arbitrari

OBJECT IDENTIFIER

Provengono dal set di tutti gli OID assegnati secondo le norme specificate in ASN.1

IpAddress

Rappresentano gli indirizzi di una particolare famiglia di protocolli (SMIv1 solo indirizzi IPv4, SMIv2 indirizzi generici)

Counter32/Counter64

Sono numeri interi non negativi che aumentano fino a raggiungere un valore massimo e poi ricominciano da zero (il valore massimo per SMIv1 è 232 − 1, mentre per SMIv2 è 264 − 1)

Gauge32

Sono interi non negativi che possono aumentare o diminuire entro un range specifico. Ogni volta che la metrica rappresentata dall’indicatore è al di fuori di tale intervallo, il valore indicato rimane comunque dentro al range

TimeTicks

Rappresentano il tempo a partire da un determinato evento, misurato in centesimi di secondo

Opaque

È fornito esclusivamente per fornire compatibilità retroattiva, e non deve essere utilizzato per i tipi di oggetti di nuova definizione. Permette di passare sintassi ASN.1 arbitraria

Unsigned32

Rappresentano le informazioni come interi senza segno, risulta utile quando i valori sono sempre positivi

5.2. ESTENSIONE DELL’AGENTE

29

Tabella 5.2: Valori possibili per la clausula MAX-ACCESS Valore

Significato

read-create

Indica che è accessibile in lettura, scrittura e creazione

read-write

Indica che è accessibile in lettura e scrittura ma non in creazione

read-only

Indica che è accessibile in sola lettura

accessible-for-notify

Indica un oggetto che è accessibile solo tramite una notifica

not-accessible

Indica un oggetto ausiliario

massimo di accesso (MAX-ACCESS) che può assumere i valori presentati in tabella 5.2, lo stato della variabile che indica se può essere utilizzata (current, deprecated o obsolete), una descrizione testuale che spieghi cosa rappresenta la variabile, il nome del nodo padre che la contiene e l’ID univoco per il nuovo nodo. La variabile così creata rappresenta una foglia per l’albero MIB. Allo stesso modo delle variabili per le metriche applicative, vanno definite anche le possibili trap che possono venire generate dagli agenti. Per approfondimenti riguardo questa sezione si faccia riferimento a [5].

5.2

Estensione dell’agente

Per estendere l’agente tramite il protocollo AgentX [3] mi sono avvalso di librerie pre-esistenti. Il subagent è stato inizialmente scritto in Python con l’ausilio della libreria pyagentx; dopo alcuni test però, ho potuto constatare che la libreria utilizzata aveva dei problemi nella gestione dei lock sulle variabili interne, questo si traduceva in un funzionamento a rilento e con molti timeout lato applicazione. Ho tentato quindi di appoggiarmi ad una libreria più autorevole (NetSNMP::agent) per il linguaggio Perl e ho osservato subito un netto miglioramento delle performance generali. Ricapitolando il funzionamento del protocollo AgentX, presentato in sezione 4.2.2, le richieste di informazioni che non possono essere soddisfatte direttamente dal master agent vengono girate al subagent che estende il MIB contenente le informazioni richieste. Per poter estendere il MIB su un dato sistema tramite il protocollo AgentX e la libreria NetSNMP::agent i seguenti componenti devono essere correttamente installati e funzionanti:

30

CAPITOLO 5. IMPLEMENTAZIONE DELLA SOLUZIONE • Interprete Perl; • Pacchetto Net-SNMP (versione minima 5.0.0, consigliata 5.7.1).

La libreria NetSNMP::agent mette a disposizione tutti i metodi necessari per gestire le richieste. Di seguito vengono presentati i metodi che sono stati utilizzati per la realizzazione del progetto: • getMode() Ritorna il tipo della richiesta; • next() Ritorna la richiesta successiva nella lista delle richieste o NULL se non ci sono altre richieste; • getOID() Ritorna l’OID contenuto nella richiesta; • getValue() Ritorna il valore contenuto nella richiesta. Viene solitamente richiamato per gestire una richiesta SET e recuperare il valore, contenuto nella richiesta, da assegnare alla variabile. Non è possibile recuperare il tipo del valore; • setValue(type, data) Assegna alla richiesta il valore contenuto nel subagent. Viene solitamente utilizzato per gestire una richiesta GET e assegnare alla richiesta il valore cercato; • setError(request, error) Imposta, per la richiesta, un codice d’errore al fine di segnalare un’anomalia nella richiesta. Ulteriori informazioni in merito possono essere recuperate consultando [9]. Mentre le richieste di tipo GET sono semplici da gestire perché, dato un certo OID, basta assegnare alla richiesta il valore cercato, le richieste di tipo SET affrontano un percorso più interessante, degno di essere analizzato approfonditamente. Il processo che porta a salvare il valore ricevuto non è banale e affronta una serie di passaggi mostrati in figura 5.1. I diversi stati che può attraversare una richiesta SET sono: 1. SET_RESERVE1 Lo scopo è rilevare richieste non valide il prima possibile. Se la richiesta porta con se un valore illegale (tipo errato, fuori range, . . . ) allora la richiesta fallisce; 2. SET_RESERVE2 Lo scopo è allocare la struttura dati per la variabile o eseguire qualsiasi allocazione delle risorse necessarie per ulteriori elaborazioni (ad esempio prendere il lock su qualche variabile di servizio); 3. SET_FREE Lo scopo è annullare qualsiasi cosa fatta nei due stati precedenti, nel caso qualche aspetto della richiesta si dimostri inaccettabile. Questo può ad esempio significare il rilascio di un lock o la deallocazione di una struttura dati inutilizzata. Nel caso non sia stata eseguita alcuna azione non è necessario nessun annullamento;

5.2. ESTENSIONE DELL’AGENTE

Figura 5.1: Diagramma di attività di una richiesta SET

31

32

CAPITOLO 5. IMPLEMENTAZIONE DELLA SOLUZIONE 4. SET_ACTION assegna i valori alle strutture dati corrette (la nuova struttura creata nel secondo stato ad esempio, o una struttura già esistente); 5. SET_UNDO pulisce qualsiasi modifica effettuata negli stati 1, 2 o 4. Viene chiamato se l’esecuzione del quarto stato da esito negativo. È simile al terzo stato, ma ha anche bisogno di ripristinare i valori che possono essere stati modificati; 6. SET_COMMIT Lo scopo è confermare che l’elaborazione della richiesta SET è stata completata con successo, ed eseguire tutte le azioni "irreversibili". Ad esempio, confermare le modifiche al database.

Una volta completata la stesura dell’estensione si deve aggiungere il MIB precedentemente creato nella directory del master agent che contiene tutti gli altri MIB e impostare i permessi di lettura/scrittura per i diversi rami del MIB che si intende interrogare. Queste operazioni vanno fatte con entrambi gli agenti (master agent e subagent) fermi.

5.3

Impostazione del manager

I requisiti chiedono di utilizzare come manager la piattaforma di monitoraggio NetEye già in uso all’interno dell’azienda. NetEye nasce come piattaforma per il monitoraggio dell’infrastruttura hardware e lo scopo di questa sezione è descrivere come adattarlo affinché possa recuperare anche le nuove metriche definite. Naturalmente il fatto che le nuove metriche utilizzino il protocollo SNMP è di aiuto per il raggiungimento dell’obiettivo. Essendo NetEye un implementazione open source di Nagios è possibile utilizzarne la funzionalità dei plugin per consentire a NetEye di recuperare le nuove metriche. I plugin sono degli script scritti in un linguaggio a piacere (Perl, bash, . . . ) che definiscono i template per dei nuovi comandi. In questi template poi, tramite l’interfaccia di NetEye, si andranno a specificare di volta in volta i parametri del caso. Nel caso in esame il template conterrà il comando snmpget per recuperare le metriche. Questo comando richiede che vengano forniti dei parametri affinché la richiesta sia valida: i parametri per l’autenticazione, dove recuperare le informazioni e l’OID delle informazioni effettivamente da recuperare. Una richiesta GET effettuata con il comando snmpget avrà dunque la seguente forma: snmpget -v 2c -c public host OID Analizzando le parti che compongono la richiesta si ha che:

5.3. IMPOSTAZIONE DEL MANAGER

33

-v 2c Il flag -v serve a specificare la versione del protocollo da usare (in questo caso 2c); -c public Il flag -c serve a specificare la chiave di autenticazione (in questo caso public); host Serve a specificare l’indirizzo della virtual machine sulla quale risiede l’agente da interrogare. Può essere fornito come indirizzo IP o come Fully Qualified Domain Name (FQDN); OID Serve a specificare quale sia l’informazione effettivamente da recuperare. Può essere fornito nella versione numerica o testuale indifferentemente. Dopo aver creato i plugin necessari vanno aggiunti nella directory dedicata di NetEye e tramite interfaccia grafica vanno resi disponibili. In seguito è necessario, sempre tramite interfaccia grafica, programmare le richieste in base ad ogni quanto vengono aggiornate le metriche (tempi definiti nei KPI) e definire il tipo di grafico che si vuole ottenere. Una volta definito tutto ciò il manager comincerà a raccogliere le metriche in modo autonomo e potrà fornire grafici e valori delle metriche recuperate.

Capitolo 6

Verifica e test In questo capitolo verranno presentate le modalità e gli strumenti che ho utilizzato per verificare l’infrastruttura realizzata. Mi sono avvalso, per la stesura del MIB, di un validatore on line al fine di controllarne la sintassi. http://www.simpleweb.org/ietf/mibs/validate/ Questo strumento è stato molto importante in quanto mi ha permesso di cogliere alcune mie incomprensioni riguardo lo standard e correggere velocemente gli errori che introducevo, prima che potessi accorgermene a causa di malfunzionamenti. Per quanto riguarda invece l’attività di verifica sull’estensione dell’agente ho scritto un semplice programma in Java, utilizzando il framework SNMP4J, per emulare il comportamento dell’applicazione. In pratica il programma per effettuare il test invia una serie di richieste SET all’agente installato in locale al fine di testare: • La ricezione delle richieste • La corretta gestione delle richieste SET • L’invio di trap nei casi definiti • Il recupero delle informazioni da parte del manager • La presentazione delle informazioni tramite grafici nel manager Questa modalità di test ha evidenziato come la prima estensione dell’agente tramite la libreria pyagentx (descritta nella sezione 5.2) fosse completamente inefficiente faticando a gestire un pool di cento richieste. Con la seconda estensione dell’agente tramite la libreria NetSNMP::agent invece ho potuto effettuare uno stress test con un pool di quattromila richieste senza che l’agente presentasse il minimo problema. 35

36

CAPITOLO 6. VERIFICA E TEST

Sempre con lo stesso programma Java ho potuto testare la corretta impostazione del manager in quanto le richieste SET andavano a riflettersi sul valore richiesto dal manager all’agente e di conseguenza sul grafico prodotto. Rispetto ai requisiti presentati in tabella 2.1 tutti i requisiti obbligatori e desiderabili sono stati soddisfatti. Non è stato possibile invece soddisfare il requisito opzionale R2F9 che chiedeva di implementare sul manager SNMP una gestione dei dati in ottica di data warehouse in quanto la stessa piattaforma, che l’azienda ha richiesto venisse utilizzata per il progetto, impone dei limiti in quest’ottica. Si è infatti osservato che NetEye, per quanto riguarda la storicizzazione dei dati, a causa di limiti interni alla piattaforma, mantiene in memoria solamente le registrazioni degli ultimi sette giorni, questo ovviamente non è un comportamento accettabile in quanto la registrazione dei dati, in ottica di data warehouse, esige un orizzonte temporale molto più esteso. Inoltre non permette un’agevole aggregazione dei dati e quindi non risulta possibile ottenere una visione d’insieme delle diverse virtual machine che eseguono la stessa applicazione. Durante la fase di analisi, visto che l’azienda stessa aveva richiesto che il manager SNMP fosse rappresentato da NetEye, si è investito poco tempo per valutare se la piattaforma in questione potesse soddisfare il requisito opzionale. Quando poi mi sono accorto che NetEye, già in uso all’interno dell’azienda, non poteva soddisfare il requisito in oggetto, era divenuto troppo tardi per rivedere la pianificazione ed includere lo studio di altre piattaforme.

Capitolo 7

Conclusioni Il progetto che ho seguito è sicuramente un tassello utile per l’azienda, sia per il gruppo operation che per l’amministrazione. Per il gruppo operation, che quotidianamente deve gestire guasti e malfunzionamenti, poter contare su un tale sistema gli consente di porre in atto misure preventive per contrastare sul nascere eventuali malfunzionamenti. Per l’amministrazione uno strumento di data warehouse è in grado di fornire supporto ai processi decisionali. Attualmente il sistema non è in funzione in quanto manca il framework che dovrebbe venire utilizzato dalle applicazioni per interfacciarsi col sistema stesso, inoltre le applicazioni (attualmente in uso) vanno modificate per far si che possano comunicare le nuove metriche tramite il suddetto framework. Sia il framework che l’adattamento delle applicazioni esistenti è in carico all’area sviluppo dell’azienda stessa. Un possibile sviluppo futuro dal quale questo progetto potrebbe trarre grossi benefici è sicuramente l’individuazione di un manager diverso da NetEye in quanto, come già discusso nel capitolo 6, risulta essere prettamente studiato per il monitoraggio e difficilmente utilizzabile come data warehouse. Un’altra possibile espansione del progetto sta nell’individuazione di nuovi KPI che possano rilevare lo stato delle applicazioni durante altre operazioni. L’esperienza di stage è stata molto importante perché mi ha permesso di affacciarmi sul mondo del lavoro. La stessa transizione tra università e lavoro è stata inizialmente mediata dall’attività didattica prevista dall’insegnamento di Ingegneria del Software e in seguito dall’incontro offerto tra aziende e studenti durante l’evento STAGE-IT. Una volta in azienda, nonostante il Corso di Laurea Triennale non faccia formazione in ambito sistemi, sono comunque riuscito a mettermi in gioco. L’università mi ha dato, oltre che un background di conoscenze necessario, anche una metodologia analitica per affrontare e risolvere i problemi, infatti durante il Corso di Laurea non mi è mai stato presentato il protocollo SNMP come anche tante altre tecnologie, ma sono conscio del fatto che ciò sia impossibile in un ambito, in continua evoluzione, come quello informatico. 37

38

CAPITOLO 7. CONCLUSIONI

Nonostante ciò il background e la metodologia per affrontare i problemi che ho appreso durante il percorso universitario sono risultati sufficienti per permettermi di affrontare in autonomia il progetto. Come bagaglio personale da questa esperienza porto con me un idea molto più chiara sull’infrastruttura (sia umana che hardware) e sulle tecnologie che stanno alla base di servizi informatici erogati in modalità ASP. Oltre a questo sicuramente oggi posso dire di conoscere e padroneggiare, anche con una certa sicurezza, il protocollo SNMP, nonostante abbia presentato da subito una curva di apprendimento molto ripida.

Bibliografia [1] Blumenthal U., WijnenB. (2002), RFC 3414 - User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3), http://www.rfc-editor.org/info/rfc3414. [2] Case J., Fedor M., Schoffstall M., Davin J. (1990), RFC 1157 - Simple Network Management Protocol (SNMP), http://www.rfc-editor.org/ info/rfc1157. [3] Daniele M., Wijnen B., Ellison M., Francisco D. (2000), RFC 2741 - Agent Extensibility (AgentX) Protocol Version 1, http://www.rfc-editor.org/ info/rfc2741. [4] Mauro D., Schmidt K. (2005), Essential SNMP, 2nd Edition, O’Reilly Media, ISBN: 978-0-596-00840-6. [5] McCloghrie K., Perkins D., Schoenwaelder J. (1999), RFC 2578 Structure of Management Information Version 2 (SMIv2), http://www. rfc-editor.org/info/rfc2578. [6] Net-SNMP.org, The Net-SNMP Wiki, http://www.net-snmp.org/ wiki/. [7] Postel J. (1980), RFC 768 - User Datagram Protocol, http://www. rfc-editor.org/info/rfc768. [8] Wijnen B., Presuhn R., McCloghrie K. (2002), RFC 3415 - View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP), http://www.rfc-editor.org/info/rfc3415. [9] Willberg T., Hardaker W. (2013), NetSNMP::agent, http://search. cpan.org/~hardaker/NetSNMP-agent-5.0404/agent.pm.

39

Glossario Application Programming Interface (API) Indica ogni insieme di procedure disponibili al programmatore, di solito raggruppate a formare un set di strumenti specifici per l’espletamento di un determinato compito all’interno di un certo programma. Spesso con tale termine si intendono le librerie software disponibili in un certo linguaggio di programmazione. 16, 24, 25 Application Service Provider (ASP) È un modello architetturale per l’erogazione di servizi informatici che prevede una spinta remotizzazione elaborativa ed applicativa. Spesso il termine è usato indicando l’erogazione di servizi informatici in modalità ASP. 2, 21, 38 Certification Authority (CA) È un ente di terza parte (trusted third party), pubblico o privato, abilitato a rilasciare un certificato digitale tramite procedura di certificazione che segue standard internazionali e conforme alla normativa europea e nazionale in materia. Il sistema in oggetto utilizza la crittografia a doppia chiave, o asimmetrica, in cui una delle due chiavi viene resa pubblica all’interno del certificato (chiave pubblica), mentre la seconda, univocamente correlata con la prima, rimane segreta e associata al titolare (chiave privata). Una coppia di chiavi può essere attribuita ad un solo titolare. L’autorità dispone di un certificato con il quale sono firmati tutti i certificati emessi agli utenti, e ovviamente deve essere installata su di una macchina sicura. 1, 8, 22 Data warehouse È un archivio informatico contenente i dati di un’organizzazione, progettati per consentire di produrre facilmente analisi e relazioni utili a fini decisionali-aziendali. v, 7, 8, 26, 36, 37 Framework È un’architettura logica di supporto (spesso un’implementazione logica di un particolare design pattern) su cui un software può essere progettato 41

42

Glossario e realizzato, spesso facilitandone lo sviluppo da parte del programmatore. 24, 35, 37

Fully Qualified Domain Name (FQDN) È un nome di dominio non ambiguo che specifica la posizione assoluta di un nodo all’interno della gerarchia dell’albero DNS. Per distinguere un FQDN da un nome di dominio standard si aggiunge il nome dell’host alla stringa del dominio, in modo da renderla assoluta. 33 Internet Assigned Numbers Authority (IANA) È un dipartimento di ICANN il cui compito è quello di coordinare alcuni degli elementi chiave che mantengono il funzionamento di Internet senza problemi. In particolare, IANA assegna e gestisce i codici unici e i sistemi di numerazione che vengono utilizzati nelle norme tecniche ("protocolli") che guidano Internet. 13, 21 Key Performance Indicator (KPI) È un indice che monitora l’andamento di un processo aziendale. I principali indicatori sono di quattro tipi: generali (misurano il volume del lavoro del processo), di qualità (valutano la qualità dell’output di processo), di costo e di servizio (o di tempo, misurano il tempo di risposta, a partire dall’avvio del processo fino alla sua conclusione). 7, 22, 33, 37 Management Information Base (MIB) È un tipo di database per la gestione di dispositivi nelle reti di comunicazione, comprende una collezione di oggetti in un database (virtuale) usato per gestire le entità (ad esempio router e switch) facenti parte di una rete. Il database è di tipo gerarchico (ovvero strutturato ad albero). 12, 14, 15, 21, 22, 24, 27, 29, 32, 35 Transmission Control Protocol (TCP) È un protocollo di rete a pacchetto di livello di trasporto, appartenente alla suite di protocolli Internet, che si occupa di controllo di trasmissione ovvero rendere affidabile la comunicazione dati in rete tra mittente e destinatario. 11