UNIVERSITÀ DEGLI STUDI DI SIENA. Autodiscovery e gestione delle configurazioni di una rete di sistemi distribuiti FACOLTÀ DI INGEGNERIA

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "UNIVERSITÀ DEGLI STUDI DI SIENA. Autodiscovery e gestione delle configurazioni di una rete di sistemi distribuiti FACOLTÀ DI INGEGNERIA"

Transcript

1 UNIVERSITÀ DEGLI STUDI DI SIENA FACOLTÀ DI INGEGNERIA Corso di Laurea in Ingegneria Informatica Autodiscovery e gestione delle configurazioni di una rete di sistemi distribuiti Relatore Prof. Alfio Andronico Correlatori Prof. Sandro Bartolini Dott. Stefano Martinelli Ing. Andrea Righi Tesi di laurea di Matteo Chesi A. A. 2006/2007

2

3 I think I ll just take another walk, he said. Don t blame you, said Marvin and counted five hundred and ninety-seven thousand million sheep before falling asleep again a second later. Douglas Adams, The Hitchhiker s Guide to the Galaxy

4

5 Indice 1 Introduzione Introduzione al problema Organizzazione della Tesi Definizioni e Concetti base Descrizione formale del problema Notazioni Definizioni Analisi formale del problema Agent-based vs Agentless Requisiti Requisiti funzionali Requisti di qualità Stato dell arte e tecnologie Tecnologie Cluster Computing Perl SNMP i

6 ii INDICE 4.2 Software esaminati Software Commerciali Software Opensource OCS Inventory NG Motivazioni della scelta Analisi di OCS Inventory NG Progettazione e Sviluppo Requisiti non soddisfatti discovery dei dispositivi discovery dei servizi discovery dei dispotivi di rete Struttura dei Plugin di OCS Inventory NG Ipdiscover Progettazione Implementazione Services discovery Progettazione Implementazione SNMP discovery Progettazione Implementazione Risultati Sperimentali Ambiente di Test Installazione Installazione del Communication Server Installazione degli agent

7 INDICE iii 6.3 Descrizione dei Test Risultati Attesi Risultati Conclusioni Sviluppi futuri 111 A Administration Console - Screenshots 113 Bibliografia 131

8 iv INDICE

9 Elenco delle figure 4.1 Albero degli oggetti della MIB L architettura di OCS Inventory NG Schema del Database di OCS Inventory NG Il flusso di esecuzione dei moduli di OCS Inventory NG Struttura del cluster BCX A.1 Pagina Principale dell Administration Console A.2 Inventario: Dettaglio di un nodo A.3 Inventario: BIOS A.4 Inventario: Configurazioni A.5 Inventario: Configurazione di Ipdiscover A.6 Inventario: Controllers A.7 Inventario: Filesystem A.8 Inventario: Storage A.9 Inventario: Memoria A.10 Inventario: Interfacce di Rete A.11 Inventario: Pacchetti Software A.12 Inventario: Porte A.13 Inventario: Processori v

10 vi ELENCO DELLE FIGURE A.14 Inventario: Servizi A.15 Inventario: SNMP - Dispositivi di rete A.16 Inventario: Schede Video

11 Capitolo 1 Introduzione 1.1 Introduzione al problema I Computer sono entrati a far parte della vita della nostra società, ormai la presenza di computer o dispositivi informatici in generale risulta praticamente indispensabile in qualsiasi ambito, che si parli di lavoro, intrattenimento o quant altro un computer può fornire sempre il suo valido aiuto. L evoluzione dell informatica ha fatto sì che negli anni il numero di questi dispositivi sia cresciuto costantemente a ritmi sempre più vertiginosi. Questo numero crescente di computer oltre a creare nuove opportunità ha dato vita a nuove esigenze. In primo luogo ogni computer necessita di amministrazione ed assistenza. Ogni realtà che sfrutta il supporto dell informatica deve fare i conti con queste attività e maggiore è l apporto dell informatica nel suo business più queste attività divengono cruciali. Poiché la gestione di un sistema non può prescindere dalla conoscenza dello stesso, così anche quando si parla di computer e della gestione di sistemi informatici la conoscenza dettagliata delle caratteristiche di questi sistemi risulta 1

12 2 CAPITOLO 1. INTRODUZIONE di fondamentale importanza. In pratica è richiesto che chi si occupa di gestire un computer, l amministratore, conosca il computer che deve amministrare. Quella che di primo acchito potrebbe sembrare una richiesta banale da soddisfare risulta invece una questione complessa quando si prende in considerazione la realtà pratica. Nella realtà odierna di molte organizzazioni, con l incremento del numero di computer, l amministratore si trova a dover gestire centinaia, in alcuni casi migliaia, di sistemi, spesso, anche eterogenei. Quando si parla di numeri così elevati è facile comprendere come la conoscenza dettagliata di un singolo dispositivo all interno di un cosí vasto parco macchine possa essere una questione tutt altro che banale, quindi risulta necessario costruire e mantenere aggiornato un inventario completo dell intero parco macchine sia dal punto di vista hardware, di configurazione e di dotazione software. La gestione dell inventario è una pratica fondamentale dell amministrazione di impresa moderna e come tale ha subito anche essa una forte evoluzione. Dal punto di vista informatico, la gestione dell inventario è un problema che riguarda l acquisizione, conservazione e fruizione di un informazione, l inventario appunto. In un primo momento la gestione dell inventario si è evoluta grazie all informatica nella fase di conservazione dell informazione, sostituendo il supporto dell archivio cartaceo con i file digitali e l organizzazione dei database. In un secondo momento si è provveduto ad alleggerire la fase di acquisizione dell informazione cercando di supportare con l informatica quello che un tempo era gestito con la burocrazia dei moduli stampati. In molti casi questo è il massimo che si può fare come supporto informatico alla gestione dell inventario, perché alle estremità della catena dell informazione ci sarà sempre un operatore umano che deve inserire l informazione ed un altro che deve richiederla.

13 1.1. INTRODUZIONE AL PROBLEMA 3 Nel caso dell inventario dei dispositivi informatici si può fare molto di più. Infatti si potrebbe dire che i computer hanno coscienza di sé, o meglio conoscenza di sé, in pratica sono in grado di fornire un gran numero di informazioni riguardo alla loro stessa natura. Grazie a questa caratteristica dei computer è possibile gestire l inventario come un sistema perfettamente automatizzato dove sarà lo stesso componente inventariato ad inserire i suoi dati nell inventario senza alcun intervento dell operatore umano. Quest attività di estrazione automatizzata delle informazioni è detta AutoDiscovery. L AutoDiscovery è di notevole aiuto in questo caso poiché i sistemi informatici non sono risorse statiche da inventariare come ad esempio potrebbero essere i componenti di arredo di un ufficio o i prodotti conservati in un magazzino, le cui uniche attivitá di scrittura nell inventario riguardano la loro entrata e la loro uscita dall inventario stesso; un sistema informatico è una realtà dinamica che nel corso del tempo può modificare la sua configurazione hardware e software, la sua posizione nella rete, le sue funzioni. Risulta quindi considerevole il flusso di informazioni che l inventario deve gestire per tenersi aggiornato ed è impensabile gestire tale mole di informazioni manualmente. L AutoDiscovery diviene quindi una soluzione indispensabile per l inventario laddove il gran numero di dispositivi e l importanza della qualità del servizio informatico rendono fondamentale il ruolo della amministrazione di sistema. L avanguardia per le problematiche di amministrazione di sistemi è sicuramente l HPC (High Performance Computing). Per soddisfare le crescenti esigenze di calcolo, in ambito HPC, si fa da tempo affidamento a tecnologie quali il Grid Computing o il Clustering Computing che per mezzo di una forte distribuzione e parallelizzazione del calcolo computazionale riescono a garantire prestazioni sempre maggiori a costi sostenibili. Il calcolo distribuito riesce ad offrire un incremento di prestazioni a fronte di una maggiore

14 4 CAPITOLO 1. INTRODUZIONE complessità dei sistemi. Ad oggi parlare complessità dei sistemi in HPC significa fare riferimento a centri di calcolo che possono disporre di cluster da decine di migliaia di nodi. Risulta quindi evidente come in HPC dove la qualita del servizio informatico è centrale, dove l amministrazione dei sistemi è portata agli estremi, dove i numeri sono così elevati, sia impossibile rinunciare a sistemi di AutoDiscovery per mantenere efficacemente l inventario delle apparecchiature informatiche e riuscire così ad offrire un servizio sempre più efficiente. 1.2 Organizzazione della Tesi Di seguito vengono descritti i contenuti degli otto capitoli di cui è composto questo lavoro di tesi. 1. Nel primo capitolo si è fornita una descrizione del contesto e delle motivazioni per cui si sono sviluppate le applicazioni di autodiscovery. 2. Nel secondo capitolo introdurremo i concetti base che verranno usati nello svolgimento di tutto il lavoro di tesi e verrà descritto il problema dell autodiscovery delle configurazioni mediante un modello logico formale. Quindi analizzeremo gli aspetti peculiari delle due architetture maggiormente diffuse per le soluzioni di autodiscovery, l architettura Agent-based e quella Agentless. 3. Nel terzo capitolo verranno specificati i requisiti che hanno vincolato le scelte effettuate nel corso del lavoro di tesi. 4. Il quarto capitolo illustra lo stato dell arte per le teconologie di auto-discovery. Dopo aver introdotto alcune delle tecnologie che operano in questo contesto, vengono vagliati i principali software disponibili sul mercato alla ricerca della soluzione ottimale.

15 1.2. ORGANIZZAZIONE DELLA TESI 5 5. La soluzione scelta non aderisce completamente ai requisiti in esame e quindi occorre progettare e implementare alcune modifiche. Nel quinto capitolo viene così descritta questa fase di progettazione e sviluppo del lavoro di tesi. 6. Nel sesto capitolo vengono descritti i test effettuati e i risultati ottenuti dalla sperimentazione. 7. Nel settimo capitolo vengono tracciate le conclusioni del lavoro di tesi. 8. Infine nell ottavo capitolo vengono analizzati gli eventuali scenari futuri e i possibili sviluppi che potrebbero seguire questo lavoro di tesi. 9. Nell Appendice A vengono riportati alcuni screenshot dell applicazione sviluppata.

16 6 CAPITOLO 1. INTRODUZIONE

17 Capitolo 2 Definizioni e Concetti base 2.1 Descrizione formale del problema La soluzione del problema dell autodiscovery delle configurazioni di sistemi distribuiti consiste nel riuscire a fornire agli amministratori di sistema una visione dettagliata della rete che devono amministrare. L amministratore di sistema deve avere accesso diretto all elenco delle configurazioni dei dispositivi presenti nella rete, in modo tale da poter eseguire piú efficacemente i suoi compiti di gestione e risoluzione dei problemi. Inoltre l amministratore di sistema deve avere a disposizione le informazioni sulla struttura della rete in cui opera in modo tale da avere accesso alle informazioni che desidera basandosi sulle relazioni di connessione che intercorrono tra i dispostivi e sulla posizione dei dispositivi all interno della rete. In questo capitolo verrà analizzato il problema mediante un modello logico così da fornire una descrizione formale dei suoi vari aspetti e degli strumenti necessari alla sua risoluzione. Allo scopo saranno esplicitate, qui di seguito, le notazioni e i concetti fondamentali su cui baseremo questa descrizione. 7

18 8 CAPITOLO 2. DEFINIZIONI E CONCETTI BASE Notazioni Il concetto di insieme sta alla base della descrizione logica e delle definizioni che saranno utilizzate. Si utilizza il parametro n ad indicare la cardinalità di un insieme quando il suo valore non sia rilevante; chiaramente lo stesso n in riferimento a due insiemi diversi, non sta ad indicare che questi due insiemi abbiano la medesima cardinalità. Si utilizza la notazione ˆx per indicare un identificativo, un riferimento univoco all elemento x. Inoltre con la notazione ˆX si indica l insieme degli identificativi degli elementi appartenenti all insieme X Definizioni Definiamo rete r, un insieme di calcolatori autonomi interconnessi tra loro. Con R = {r 1,..., r n } indichiamo l insieme di tutte le reti esistenti. Definiamo dispositivo δ, un generico elemento di una rete. Con D = {δ 1,..., δ n } indichiamo l insieme di tutti i dispositivi esistenti. Una rete r può essere considerata un insieme di identificativi di dispostivi, e l appartenenza di un dispositivo δ x ad una rete r si indica con ˆδ x r. Definiamo connessione k una coppia di identificativi di dispostivi. Con k a,b = ( ˆδ a, ˆδ b ) indichiamo la connessione tra il dispositivo δ a e il dispositivo δ b Con K indichiamo l insieme delle connessioni che coinvolgono due a due i dispositivi appartenenti alla rete r Invece indichiamo con I x l insieme dei dispositivi connessi al dispositivo δ x.

19 2.1. DESCRIZIONE FORMALE DEL PROBLEMA 9 Sia un grafo una coppia G = (N, A) in cui N è un insieme finito ed A è una famiglia di coppie di elementi di N. Gli elementi di N sono chiamati nodi, mentre gli elementi di A sono chiamati archi di G. Definiamo topologia t di rete, la rappresentazione della rete mediante un grafo. Indichiamo con t la topologia della rete r, allora t = (r, K ) dove ogni nodo è un dispositivo appartenente alla rete r ed ogni arco è una connessione appartenente a K. Definiamo computer un qualsiasi dispositivo su cui sia possibile installare ed eseguire software arbitrario. Definiamo dispositivo di rete un qualsiasi dispositivo facente parte dell infrastruttura di rete che non permette l installazione e l esecuzione di software arbitrario. Definiamo componente c, un elemento costitutivo di un dispositivo sia esso di natura hardware o software. Con C = {c 1,..., c n } indichiamo l insieme di tutti i componenti esistenti. Un dispositivo δ può essere considerato un insieme di identificativi di componenti, e l appartenenza di un componente c x ad un dispositivo δ si indica con ĉ x δ. Definiamo caratteristica p, una proprietà di un componente. Con P = {p 1,..., p n } indichiamo l insieme di tutte le caratteristiche esistenti. Per le caratteristiche non si applica la distinzione tra identificativo di caratteristica e caratteristica vera e propria, poichè in questa astrazione la caratteristica

20 10 CAPITOLO 2. DEFINIZIONI E CONCETTI BASE è considerata il dato finale oltre il quale non è più richiesta alcuna azione di discovery. Si può quindi affermare che nella caratteristica identificativo ed elemento coincidono. Un componente c può essere considerato un insieme di caratteristiche, e l appartenenza di una caratterisitca p x ad un componente c si indica con ˆp x c (o identicamente con p x c ). Al fine di ottenere la risoluzione del problema rimangono da definire in modo formale i risultati che vogliamo ottenere. Anche questi saranno definiti facendo uso del concetto di insieme. Gli obiettivi sono sostanzialmente due e corrispondono a due tipologie diverse di viste sui dati che sono oggetto dell azione di discovery. Queste viste devono essere messe a disposizione degli amministratori di sistema affinche il problema della gestione delle configurazioni di sistemi distribuiti possa dirsi risolto. Dicesi configurazione f di un dispositivo l insieme delle caratteristiche dei componenti di un determinato dispositivo. Si indica con f la configurazione del dispositivo δ che risulta essere definita nel seguente modo: Se il componente ĉ i appartiene al dispositivo δ e p ij è una caratteristica del componente c i allora la caratteristica p ij fa parte della configurazione f del dispositivo δ. ĉ i δ p ij c i p ij f Definiamo Vista Logica V di una rete l insieme delle configurazioni dei dispositivi di una determinata rete.

21 2.1. DESCRIZIONE FORMALE DEL PROBLEMA 11 Si indica con V la Vista Logica della rete r e può essere definita in questo modo: Se il dispositivo ˆδ i appartiene alla rete r e f i è la configurazione del dispositivo δ i allora la configurazione f i fa parte della Vista Logica V della rete r. ˆδ i r f i è configurazione di δ i f i V Definiamo Vista Fisica W di una rete, la topologia della rete ove i nodi non siano rappresentati dai dispositivi, bensì dalle loro configurazioni. Ovvero indichiamo con W la Vista Fisica della rete r per cui W è il grafo i cui nodi appartengono a V, Vista Logica della rete r, e i cui archi appartengono a A insieme delle coppie a ij = (f i, f j ) tali che: Esiste a ij arco che congiunge le configurazioni f i e f j appartenenti alla Vista Logica V se e solo se esiste i ij connessione tra i dispositivi ˆδ i e ˆδ j nel grafo della topologia t della rete r W = (V, A ) Quindi d ora in avanti gli obiettivi di tutto il processo di discovery saranno indicati come : O 1 : fornire la Vista Logica della rete in esame r agli amministratori di sistema. O 2 : fornire la Vista fisica della rete in esame r agli amministratori di sistema.

22 12 CAPITOLO 2. DEFINIZIONI E CONCETTI BASE Analisi formale del problema Allo scopo di raggiungere i due obiettivi servono degli strumenti in grado di raccogliere informazioni dettagliate su ogni singolo elemento a partire dal suo identificativo. Chiameremo questi strumenti funzioni di discovery. Utilizzando queste funzioni è possibile risalire dall identificativo di un elemento alle parti che lo compongono e/o caratterizzano. Le condizioni iniziali del problema dell autodiscovery delle configurazioni sono la conoscenza della rete di cui vogliamo ottenere le varie viste. Questa conoscenza si limita però alla sola esistenza. Inizialmente non è conosciuta né la topologia né i dispositivi che ne fanno parte. Quindi l unico dato di partenza è: ˆr ˆR dove r è appunto la rete di cui vogliamo effettuare il discovery. Discovery dei dispositivi Per procedere alla soluzione del problema, il primo passo è riuscire ad ottenere i dispositivi facenti parte della rete in esame. Ciò che serve è una funzione di discovery ϕ : ˆR R Quindi applicando ϕ( ˆr ) si ottiene r = { ˆδ 1,..., ˆδ n } con r ˆD. Discovery dei componenti Il passo successivo è quello di ricavare per ogni dispositivo i componenti di cui è composto. La funzione di discovery che occorre è : χ : ˆD D

23 2.1. DESCRIZIONE FORMALE DEL PROBLEMA 13 Quindi per ottenere gli identificativi dei componenti di un determinato dispositivo δ si può applicare χ( ˆδ ) e si ottiene δ = {ĉ 1,..., ĉ n } con δ Ĉ. Discovery delle caratteristiche Da ogni componente si vuole ricavare le sue caratteristiche e per fare ciò si deve far uso di una funzione di discovery: ψ : Ĉ C Per cui tramite ψ(ĉ ) = c = {p 1,..., p n } è possibile ottenere le caratteristiche associate a qualsiasi componente. Inoltre applicando la funzione ψ ad ogni componente di un dispositivo sarà possibile ricavarne la configurazione. Difatti la configurazione f del dispositivo δ corrisponde all unione degli insiemi c i se e solo se per ogni i l insieme c i è il risultato del discovery delle caratteristiche sul componente ĉ i e tale componente fa parte del dispositivo δ : f = c i i : c i = ψ(ĉ i ) ĉ i χ(δ ) Infine per raggiungere l obbiettivo O 1 occorre presentare la vista logica per la rete r. La vista logica V della rete r corrisponde all unione delle configurazioni f i se e solo se per ogni i, f i è la configurazione di un dispositivo δ i che appartiene alla rete r : V = f i i : f i è configurazione di δ i ˆδ i r Discovery delle connessioni Per il secondo obbiettivo (O 2 ) si deve far uso di un ulteriore funzione di discovery

24 14 CAPITOLO 2. DEFINIZIONI E CONCETTI BASE che riesca ad individuare le connessioni tra i dispositivi, ovvero l insieme I i r dei dispositivi connessi a ˆδ i r Per trovare I i si utilizza una funzione di discovery ω : ˆD R In questo caso si considera il codominio R poiché vogliamo ottenere un insieme di identificativi di dispositivi; tale insieme è formalmente equivalente al concetto di rete che abbiamo definito. ˆδ x I i = ω(ˆδ i ) δ x è connesso direttamente a δ i A questo punto è possibile estrarre le informazioni necessarie alla costruzione della topologia di rete, selezionando come nodi a i gli identificativi dei dispositivi appartenenti a r, e unendoli tramite gli archi k ij esistenti. Il generico arco/connessione k ij esiste nella topologia t della rete r se e solo se i dispositivi ˆδ i e ˆδ j appartengono alla rete r e il dispositivo ˆδ j appartiene all insieme I i dei dispositivi connessi a ˆδ i : k ij ˆδ i, ˆδ j r ˆδ j I i Per ottenere la vista fisica della rete, basta sostituire nel grafo della topologia i nodi ˆδ i con le rispettive configurazioni f i. In definitiva, dal punto di vista formale, il problema così impostato evidenzia la necessità di individuare le seguenti funzioni: ϕ : per il discovery dei dispositivi in rete. χ : per il discovery dei componenenti dei dispositivi.

25 2.1. DESCRIZIONE FORMALE DEL PROBLEMA 15 ψ : per il discovery delle caratteristiche dei componenti. ω : per il discovery delle connessioni tra dispositivi. Nella pratica queste funzioni sono in realtà classi di funzioni in quanto non è quasi mai possibile trovare un unica procedura che permetta di effettuare il discovery a partire dai macro-domini che abbiamo selezionato. Nella pratica ogni dominio sarà a sua volta diviso in sottodomini separati per caratteristiche e peculiarità. Così ad esempio la funzione χ non sarà unica per tutti i dispositivi appartenenti a r, ma sarà comunque possibile individuare delle tipologie di dispositivo, come ad esempio quelle già definite come i computer e i dispositivi di rete che sfrutteranno diverse funzioni della classe χ. Questi sotto-domini e classi di funzioni aprono due possibili scenari. Nel primo in cui i dati ottenuti sono sufficienti ad includere un determinato elemento in un sottodominio specifico, è possibile scegliere la funzione più adeguata tra quelle presenti nella classe di funzioni per effettuare il discovery. Nel secondo scenario invece i dati ottenuti non sono sufficienti a classificare l elemento ed allora è necessario provare esaustivamente tutte le funzioni della classe alla ricerca dell unica funzione di discovery che sia in grado di restituire il risultato corretto. Questa divisione dei domini in sottodomini avviene in genere su molteplici livelli e con un buon grado di profondità, generando un esplosione di procedure appartenenti ad ogni singola classe in funzione dei livelli. Il rapporto con questo insieme non definito di tipologie, classi e procedure risulta essere la parte aperta del problema dell autodiscovery delle configurazioni, che impedisce di fatto la determinazione di un unica procedura dalla validità assoluta ed obbliga a definire procedure sempre dipendenti dal contesto.

26 16 CAPITOLO 2. DEFINIZIONI E CONCETTI BASE 2.2 Agent-based vs Agentless I sistemi software che si occupano di autodiscovery si basano principlamente sue due diversi modelli. Questi modelli differiscono sull utilizzo o meno di agenti software. Un agente è un componente software che ha il compito di agire per conto di un utente o di un programma. La capacita di agire per conto di qualcuno o qualcosa implica che l agente non solo deve essere in grado di portare a termine un task, ma deve anche avere l autorita per decidere quando (e se) le sue azioni siano appropriate. La definizione di agente è un idea, un astrazione come lo è la definizione di oggetto nella programmazione ad oggetti, ma mentre un oggetto risulta definito in termini di attributi e metodi, un agente lo si puo definire in base al suo comportamento. Esistono varie definzione di agente proposte da diversi autori che nell affrontare l argomento hanno adottato una loro interpretazione. Nell eterogenietà delle definizioni si possono tuttavia individuare alcuni concetti comuni e portanti: La persistenza : il codice non viene eseguito su richiesta, ma è in esecuzione continua e decide da solo quando è il caso di compiere determinate attività L autonomia : gli agenti possono avere capacità di selezione dei task, gestione delle priorità controllo delle decisioni senza avvalersi dell intervento umano. L abilità sociale : gli agenti hanno la capacità di comunicare con altri componenti, e inoltre possono coordinarsi in modo tale da compiere in collaborazione determinati task. La reattività : gli agenti hanno la percezione del contesto in cui operano e possono reagire al contesto in modo appropriato.

27 2.2. AGENT-BASED VS AGENTLESS 17 Gli agenti vengono solitamente utilizzati per portare a termine task complessi, come puo essere l analisi dei sistemi. L architettura software denominata Agent-based prevede appunto la distribuzione di agenti nel sistema che deve analizzare o monitorare. Oltre agli agenti distribuiti, l architettura prevede un management server che si occupi di gestire le informazioni che riceve dagli agenti ed interfacciarsi con gli utenti. Al contrario l architettura Agentless rifiuta l utilizzo di agenti e consiste solo di un management server esterno al sistema che deve analizzare. Il funzionamento di quest architettura si basa su interrogazioni remote che a partire dal server esterno cercano di carprire quante più informazioni possibile del sistema da analizzare senza dover installare software su di esso. L architettura Agentless non prevede di introdurre nessuna nuova funzionalita al sistema che analizza, ma solamente di sfruttare quelle che il sistema rende già disponibili. Le architetture Agent-based e Agentless sono per natura contrapposte così i pregi dell una sono i difetti dell altra e nella scelta di una di queste architetture vanno presi in considerazione questi aspetti che le rendono così diverse. Utilizzo delle risorse Un agente locale richiede all host che lo ospita risorse come tempo di CPU, memoria, spazio su disco. Sebbene queste risorse siano generalmente esigue, la costante presenza di un agente locale ha comunque un certo impatto sulle operazioni dell host. Nell architettura Agentless le risorse che vengono sfruttate risiedono tutte all esterno del sistema e quindi non c è nessun impatto sulle prestazioni interne al sistema.

28 18 CAPITOLO 2. DEFINIZIONI E CONCETTI BASE Utilizzo della rete Il tipo di discovery eseguito dall agente locale sull host, non richiede l utilizzo della rete se non per la comunicazione dei risultati al management server. Quindi generalmente una soluzione Agent-baed ha pochissimo impatto sulle prestazioni della rete. L architettura Agentless, al contrario, fa un uso intenso di questa risorsa poiché tutte le operazioni di discovery si svolgono da remoto. L impatto sulla rete di una soluzione Agentless non è affatto trascurabile e cresce considervolmente all aumentare della complessità del sistema e della frequenza con cui si richiedono informazioni aggiornate. Inoltre la soluzione Agentless non è adatta a compiere l attività di discovery su reti WAN (Wide Area Network) dove solitamente varie parti della rete sono isolate le une dalle altre non permettendo le interrogazioni dirette di cui il sistema Agentless necessita. Mantenimento del software Una soluzione basata sugli agenti è molto dispendiosa dal punto di vista del mantinemento del software. Gli agenti vanno distribuiti su ogni host e ne va controllata la corretta installazione e funzionamento. Non sono rare le occasioni in cui il software degli agenti necessiti di essere aggiornato, patchato o riconfigurato. Al crescere del numero degli agenti queste operazioni possono risultare pesanti. Inoltre possono coesistere nello stesso sistema versioni diverse degli agenti, ognuna con le sue peculiarità e l amministrazione di versioni eterogenee non risulta certo semplice. In una soluzione Agentless questo problema semplicemente non si pone. L unico software da mantenere è quello sul management server. L assenza delle problematiche di mantenimento degli agenti è sicuramente il maggior pregio delle soluzioni Agentless.

29 2.2. AGENT-BASED VS AGENTLESS 19 Profondità dei dati Una soluzione Agent-based permette di fare un discovery molto in profondità nel sistema. Il software girando direttamente sull host permette di ricavare qualsiasi tipo di informazione sulla sua configurazione ed il suo funzionamento. Una soluzione agentless, per quanto buona, avrà comunque una vista esterna sugli host e non potrà mai raggiungere la profondità e il dettaglio delle informazioni fruibili ad un software interno al sistema. High Availability La soluzione Agent-based può lavorare anche in situazioni di malfunzionamento quando non siano disponibili le risorse di rete oppure il management server sia inattivo. In questi casi gli Agenti possono compiere il loro discovery in locale aspettando che quelle risorse tornino disponibili per inviare i risultati ottenuti. La soluzione Agentless è invece completamente inattiva quando non sono disponibili le risorse di rete. Reattività Gli agenti locali sono in continua esecuzione e possono essere sensibili al contesto in cui vengono eseguiti. Possono rispondere con effetto immediato alle situazioni che vengono a verificarsi di fatto permettendo un discovery real-time sulle funzionalità dell host. Una soluzione Agentless non permette un discovery di tipo real-time, anzi più si cerca la reattività in un sistema Agentless, più si consumano risorse di rete per l azione di polling ad alte frequenze. Sicurezza Gli agenti richiedono spesso privilegi di root in esecuzione e quindi se non per-

30 20 CAPITOLO 2. DEFINIZIONI E CONCETTI BASE fettamente sicuri possono essere sfruttate come falle nella sicurezza dell intero sistema. Al contrario una soluzione Agentless lavorando completamente dall esterno non può in nessun caso creare problemi di sicurezza. Reliability Gli agenti richiedono molto spesso un azione di controllo sul loro effettivo funzionamento, altrimenti risulterebbe difficile stabile se il mancato invio dei dati sia causato da un malfunzionamento o dalla mancanza di dati da inviare. La soluzione Agentless non è affetta da queste problematiche. Maturità Le soluzioni Agent-based sono state le prime ad essere implementate e sono quindi da considerarsi più mature, al contrario le soluzioni Agentless sono comparse sul mercato del software solo recentemente ed è quindi più probabile che siano affette da problemi di gioventù. Costi Il costo delle soluzioni Agent-based è di solito maggiore della controparte Agentless in virtù della struttura più complessa e della natura degli agenti che sono comunque componenti software che vanno acquistati, installati, mantenuti e gestiti. Tutte queste operazioni incidono sui costi effettivi di implementazione di un software Agent-based. Negli ultimi tempi, sempre più prodotti offrono funzionalità di discovery di tipo ibrido. Questi prodotti cercano di sfruttare la tecnologia Agentless laddove questa sia in grado di soddisfare le richieste dell utente e propongono l installazione di

31 2.2. AGENT-BASED VS AGENTLESS 21 Tabella 2.1: I punti di forza delle architetture Agent-based e Agentless Utilizzo della risorse Utilizzo della rete Mantenimento del software Profondità dei dati High Availability Reattività Sicurezza Reliability Maturità Costi Agentbased X X X X X Agentless X X X X X agenti solo per gli utenti più esigenti o per soddisfare requisiti di funzionalità o qualità specifiche. Un altro tipo di approccio ibrido è quello che prevede di utilizzare funzionalità di controllo remoto già presenti sugli host per monitorarli senza dover ricorrere all installazione di alcun nuovo software. Questa soluzione spesso associata al protocollo SSH può considerarsi a tutti gli effetti una soluzione Agentless, ma possiede anche molte delle prerogative dell architettura Agent-based. Difatti la profondità dei dati acquisibili è la stessa del discovery tramite agenti in quanto la visione tramite interfaccia di controllo remoto è la stessa di un software interno al sistema. D altra parte la sicurezza è un difetto di questa soluzione poiché un discovery che richieda l accesso remoto necessita di avere credenziali di accesso per tutti gli host e questa concentrazione di dati sensibili potrebbe facilmente compromettere la sicurezza dell intero sistema. Infine il più grande problema di questa soluzione altrimenti ottima è lo sfruttamente delle risorse di rete che diviene incredibilmente pesante. Un sistema di criptaggio della comunicazione è essenziale per qualsiasi

32 22 CAPITOLO 2. DEFINIZIONI E CONCETTI BASE soluzione di controllo remoto, tuttavia il criptaggio introduce un notevole overhead che si sovrappone alla necessità di scambiare una gran quantità di dati per ogni sessione di discovery per ogni singolo host. Difatti il non voler installare software sull host per garantire i pregi della soluzione agentless obbliga a trasferire tutto il software necessario all esecuzione del discovery per ogni singola sessione. Il risultato dell overhead del criptaggio associato alla gran quantità di dati scambiati non può essere altro che una mole non indifferente di traffico generato che aumenta con l aumentare dei dispositivi coinvolti.

33 Capitolo 3 Requisiti Nell analisi di soluzioni software per la gestione dell autodiscovery finalizzata all inventario un ruolo di rilevanza fondamentale lo ricoprono i requisiti. I requisiti sono stati indivudati e scelti in collaborazione con il consorzio CINECA sulla base di reali esigenze nell ambito dell amministrazione di sistemi per l HPC Requisiti funzionali Discovery dei Computer È necessario che siano supportate azioni di discovery sia Hardware che Software almeno per i computer dotati di sistema operativo Gnu/Linux versioni Redhat e Suse che sono maggiormente usate nella sezione HPC del consorzio CINECA. Hardware Discovery Una soluzione software per la gestione dell inventario deve essere capace di scoprire e catalogare l hardware di cui sono composti i diversi computer. I dati relativi all hardware ritenuti essenziali sono i seguenti: 23

34 24 CAPITOLO 3. REQUISITI CPU : di cui è necessario conoscere produttore, modello, frequenza di clock, numero di core fisici. Memoria : di cui è necessario conoscere il quantitativo totale, ma anche la composizione delle singole schede installate, la loro architettura (SDRAM, DDR, DDR2,...), capacità e frequenza di clock operativa. Memoria di massa : è necessario conoscere quanti più dettagli possibili dei dispositivi di storage: produttore, modello capacità, tipologia di BUS utilizzata (IDE, SATA, SCSI,...). Dispositivi per la connessione : è necessario conoscere i dispositivi per la comunicazione di ogni genere, che siano questi Ethernet, fibra, seriale o quant altro. È necessario inoltre conoscere le caratteristiche del canale di comunicazione quali ad esempio la capacità di canale. Sono necessari inoltre tutti quei parametri come l IP e l indirizzo MAC che rendono possibile l individuazione del dispositivo nella rete. Software Discovery Molto importante è anche il contenuto software di ogni dispositivo. conoscere il software installato permette di rendere più semplice l opera di mantenimento, individuando con facilità quali dispositivi necessitano di aggiornamenti, quali siano in grado di erogare un determinato servizio o quali nod di un cluster abbiano subito un disallineamento durante un precedente aggiornamento. Le caratteristiche software ritenute importanti sono: BIOS : si debbono conoscere il nome del produttore e la versione. Sistema Operativo : si debbono conoscere quanti piu dettagli disponibili a riguardo come nome, versione, kernel.

35 25 Filesystem : si deve conoscere la composizione dei filesystem a disposizione del sistema operativo locale, il numero di partizioni, la capacità di ognuna, il nome e il tipo di filesystem utilizzato (FAT, Ext2, Ext3, ReiserFS,...) Pacchetti Software : se il sistema in esame sfrutta un sistema di pacchettizzazione come l RPM o il Debian Package System deve essere possibile catalogare quali pacchetti siano installati e la loro versione in uso. Servizi : ogni computer è in grado di erogare determinati servizi, che possono essere i più vari come Web Server, Mail Server, Database, ecc. È richiesto che il software di discovery cataloghi quali servizi è in grado di erogare ciascun computer. Discovery dei dispositivi di rete Un ulteriore requisito richiesto è quello di gestire anche i dispositivi di rete quali possono essere router o switch. Questi dispositivi non permettono l installazione di software al loro interno ma sono spesso dotati di interfacce di controllo raggiungibili tramite alcuni protocolli di comunicazione come HTTP. telnet, SNMP. È richiesto che il software di discovery sia in grado di inventariare anche questidispositivi con il maggior dettaglio possibile. Discovery della topologia di rete Un requisito importante è quello che richiede di non limitare l azione di discovery ai singoli dispositivi e ai loro componenti interni, ma di estenderlo in modo tale da inquadrare i singoli dispositivi nel più ampio scenario della struttura di rete. È infatti richiesto che l azione di discovery permetta di individuare e riconoscere la

36 26 CAPITOLO 3. REQUISITI topologia della rete che collega i vari dispositivi l un l altro in modo automatico senza richiedere l intervento umano per svolgere tale compito. Autoaggiornamento È richiesto che il sistema sia in grado di mantenere aggiornati i dati di inventario in automatico. Interfaccia I dati devono essere presentati all utente mediante un unica interfaccia di controllo. Dall interfaccia deve essere possibile visualizzare i dati di inventario per singolo dispositivo, ma anche selezionare i dispositivi mediante query basate sui dati di inventario. Ad esempio, deve essere possibile selezionare tutti quei dispositivi che hanno un determinato componente o software. Inoltre dall interfaccia deve essere possibile gestire i parametri di configurazione del sistema di discovery Requisti di qualità Utilizzo della rete La soluzione da adottare dovrà utilizzare la risorsa di rete il minimo necessario. In ambito HPC, nel grid-computing, il bus di rete è una risorsa fondamentale che non può essere sacrificata per questioni di amministrazione.è quindi auspicabile che le comunicazioni del software di discovery utilizzi un formato di compressione e non siano troppo frequenti. È inoltre sconsigliabile qualsiasi attività di polling che sfrutti il bus di rete ad alte frequenze.

37 27 Utilizzo delle risorse interne Anche le risorse interne di ogni dispositivo non possono essere eccessivamente sacrificate per le attività di discovery e di inventario. Quindi è necessario che il software di discovery non abusi di risorse quali CPU e memoria mantenendo le eventuali esecuzioni locali molto brevi e poco frequenti in modo da influire il meno posssibile sull attività principale dei dispositivi. Per mantenere i tempi di esecuzione più bassi possibile è sconsigliabile che il software utilizzi in modo intenso le risorse di storage a causa degli elevati tempi di latenza. Scalabilità È inoltre necessatrio che la soluzione da adottare sia capace di scalare in maniera efficace all aumentare delle dimensioni della rete su cui lavora e quindi del numero di dispositivi coinvolti. Validità dei dati aggiornati È necessario che i dati presentati dal sistema siano aggiornati. È ammissibile che l attività di discovery interroghi ciascun dispositivo con frequenza quotidiana e riesca quindi a presentare dati al massimo vecchi di un giorno. Interfaccia di Amministrazione È gradito che l interfaccia di ammministrazione sia facilemnte accessibile, così è consigliato che il sistema di discovery utilizzi un interfaccia web accessibile da qualsiasi terminale della rete interna mediante un qualsiasi web browser. È inoltre gradito che l interfaccia sia sviluppata con un occchio di riguardo alla sua usabilità.

38 28 CAPITOLO 3. REQUISITI Sicurezza Tutto il sistema di discovery in ogni sua parte deve essere sviluppato tenendo ben presente il concetto di sicurezza informatica. Le comunicazioni e i dati conservati devono essere protetti da minacce esterne, mentre è ammissibile considerare sicuro l ambiente della rete interna. Qualità del modello di sviluppo Altri aspetti significativi nella valutazione del software da adottare sono le possibilità che questo offre in fase di sviluppo. Per quanto un software sia buono e soddisfi i requisiti odierni non è detto che gli stessi requisiti siano validi in futuro. Nel futuro possono nascere nuove esigenze ed è praticamente ovvio che ci sia la necessità di correggere e modificare il software. È quindi importante che il software sia facilemnte aggiornabile e comprenda tutta una serie di strumenti (API, tool,...) per gestire le sue eventuali espansioni. Compare quindi tra i requisiti preferenziali la modularità, in modo tale da permettere le modifiche tramite l aggiunta o rimozione di moduli software piuttosto che la modifica dell intera applicazione. Compare inoltre l utilizzo di protocolli e standard aperti in modo che sia sempre possibile e semplice gestire la sua interoperatività con altro software. Infine è requisito preferenziale il fatto che il software venga rilasciato sotto licenza GPL. Questa licenza garantisce la natura opensource del software e con essa la piena libertà di azione ed intervento per quanto riguarda l adattamento del software alle proprie esigenze. Inoltre garantisce la possibilità di ottenere supporto per il software dalla vasta comunità di sviluppatori opensource piuttosto che essere obbligati ad affidarsi soltanto all assistenza del produttore.

39 Capitolo 4 Stato dell arte e tecnologie 4.1 Tecnologie In questa sezione verranno introdotte alcune delle tecnologie con cui si è dovuto lavorare durante la tesi. L amministrazione dei cluster era il principale target del sistema che è stato sviluppato pertanto sarà data una breve panoramica su cosa sono i cluster, come sono nati e a quali scopi vengono utilizzati. Il linguaggio Perl è stato il principale linguaggio di programmazione utilizzato nella fase di sviluppo e il protocollo SNMP è servito per interfacciarsi con gli apparati di rete quali switch e router. Di seguito saranno quindi illustrati gli aspetti peculiari di queste tecnologie Cluster Computing Comunemente si intende per cluster un insieme di calcolatori, detti nodi, che vengono visti dall utilizzatore come un unico grande server virtuale. Le motivazioni che spingono a realizzare soluzioni basate su cluster sono le seguenti [24]: 29

40 30 CAPITOLO 4. STATO DELL ARTE E TECNOLOGIE aggregare potenza - quando servono maggiori risorse si aggiungono nodi al cluster e le prestazioni in termini di capacità computazionale aumentano; accrescere l affidabilità - se uno o più nodi smettono di funzionare, i servizi forniti possono migrare su altri nodi del cluster, o essere ridistribuiti su altri server, in modo del tutto trasparente agli utilizzatori. Di conseguenza è possibile anche fare manutenzione sui nodi senza dover fermare i servizi attivi ospitati; ridurre i costi - utilizzare calcolatori comuni per realizzare complesse soluzioni che richiederebbero l acquisto di costosi supercomputer commerciali. I cluster e Beowulf, una breve storia Nell estate del 1994 Thomas Sterling e Don Becker, due ricercatori che lavoravano al CESDIS (Center of Excellence in Space Data and Information Sciences) nel progetto ESS (Earth and Space Science Project), costruirono quello che poteva essere definito il primo cluster [8]. Il CESDIS è una divisione della USRA (University Space Research Association), presso il NASA Goddard Space Flight Center in Greenbelt, Maryland e il progetto ESS era un progetto di ricerca del programma HPCC (High Performance Computing and Communication), che studiava l applicazione dei computer e del parallelismo massivo ai problemi di scienza della Terra e dello spazio. La macchina creata venne battezzata col nome di Beowulf, prendendo spunto dal più antico poema epico scritto in lingua inglese giunto fino a noi. Questo poema narra la storia di un eroe forte e coraggioso che sconfigge un mostro di nome Grendel. Dal nome di questo eroe e dalle sue epiche gesta deriva il nome di un progetto che, in ambito Linux, è stato per molto tempo sinonimo di cluster. L apparecchiatura iniziale consisteva di 16 processori 486 DX4 collegati via

41 4.1. TECNOLOGIE 31 Ethernet 10 Mbit/s channelbonded, cioè suddividendo il traffico di rete tra le varie interfacce disponibili (in genere due o tre), in modo da aumentare la banda di trasmissione e ridurre le latenze di comunicazione tra i nodi. La molla che spinse Sterling e Becker nel loro lavoro fu, banalmente, la mancanza di fondi. A fronte di una sempre crescente necessità di potenza computazionale per portare avanti le loro ricerche, emerse l idea di riutilizzare sistemi accantonati per il loro scarso interesse come singole workstation e di assemblarli in una sorta di operazione di riciclaggio, condita con qualche tocco di originalità. La loro macchina ebbe un successo immediato e l idea di usare i cosiddetti COTS (Commodity Off The Shelf ), cioè calcolatori comuni per calcoli specialistici, si diffuse molto velocemente dalla NASA all interno della comunità accademica e di ricerca 1. Lo sviluppo dei cluster si è poi evoluto nel Beowulf Project e ha portato alla creazione di una nuovissima classe di supercomputer denominati Beowulf Class Cluster Computer che offrono un sistema distribuito costruito con componenti a basso costo, prestazioni e scalabilità tipiche di un supercomputer. Beowulf diviene così popolare fra i ricercatori e gli scenziati di tutto il mondo, tanto che, per parecchio tempo, cluster è stato sinonimo di Beowulf e viceversa. L idea di Sterling e Becker, essendo trasportabile, riproducibile e soprattutto free, finisce con lo sconvolgere decisamente il mercato dell HPC (High Performance Computing), tanto che, per la prima volta, nel 1998, nella classifica dei TOP500 Supercomputer 2 mantenuta dall Università di Mannheim, figurano due Beowulf 1 La prima installazione di un cluster totalmente italiano è avvenuta a Pisa nell estate del 1996, a cura di Maurizio Davini e Alberto Ciampa nell ambito del cosiddetto Hawaii Project. Tale cluster era formato da sei nodi P6 (PentiumPro) a 200 Mhz dotati di 512KB di cache secondaria, con una rete Fast Ethernet switched. 2 Partito nel 1993, il TOP500 project fornisce una lista, aggiornata ogni 6 mesi, dei 500 computer più potenti al mondo. La misurazione viene effettuata sul miglior valore ottenuto dai benchmark Linpack e costituisce una misurazione efficace ed attendibile dei trend nel calcolo delle prestazioni.

42 32 CAPITOLO 4. STATO DELL ARTE E TECNOLOGIE cluster realizzati con semplici PC e sistema operativo Linux: Cplant del Sandia National Labs e Avalon dei Los Alamos National Labs; gli altri 498 sistemi erano tutti supercomputer commerciali, del costo di svariati milioni di dollari ciascuno. La nascita dei cluster non fu un caso, ma il risultato di una catena di eventi che si era evoluta in una decina di anni. Il periodo era quello in cui il software libero prendeva sempre più campo, sia nell ambito della ricerca, ma anche nell industria. Era il periodo in cui Linux e i compilatori della GNU stavano diventando una valida alternativa alle soluzioni commerciali, in più erano gratis. Inoltre proprio per tali sistemi veniva standardizzato il paradigma del message passing 3 e nascevano le librerie PVM (Parallel Virtual Machine) e MPI (Message Passing Interface), che consentivano lo sviluppo di applicazioni a livello utente basate su architetture cluster. Tutta questa libera diffusione di idee e di prodotti ebbe prima di tutto un forte impatto positivo nella ricerca e come conseguenza diretta, ben presto, non mancò di portare i dovuti benefici anche in ambito industriale. Il sempre maggiore affermarsi dell uso dei computer nelle normali attività aveva spinto infatti l industria allo sviluppo di nuove soluzioni sempre più a buon mercato, investendo così in queste nuove soluzioni alternative. Ma inizialmente l anello debole dei cluster era dato più che altro dalle latenze degli adattatori di rete, che non consentivano il passaggio di messaggi tra i vari nodi in modo efficiente e efficace come si sarebbe voluto. Lo studio di soluzioni alternative come il channel bonding non era sufficiente a garantire il livello di prestazioni desiderato. La parte più importante fu quindi giocata dal miglioramento del rap- Per entrare nei primi 10 posti della lista l attuale soglia è di 43.5 Teraflops, mentre l attuale primo posto è detenuto dal BlueGene/L presso il Lawrence Livermore National Laboratory in California con Teraflops [41]. 3 Un paradigma nel quale la comunicazione fra processi avviene attraverso uno scambio di messaggi sui canali di comunicazione.

43 4.1. TECNOLOGIE 33 porto prezzo / prestazioni proprio della nuova generazione di adattatori di rete. Era questo il problema storico delle architetture parallele: reti di comnicazione dedicate, sofisticate e molto costose. Quando sia le Ethernet a 100 Mbit/s che gli switch furono disponibili ad un prezzo ragionevole, la necessità di soluzioni tipo il channel bonding diminuì. Il superamento di questo ostacolo permise quindi di realizzare sistemi HPC interamente costruiti da tecnologie COTS, facilitando lo sviluppo del software di utilizzo. A Supercomputing 96 la NASA e il DOE (Department Of Energy) mostrarono dei cluster da $ che ottenevano prestazioni sostenute superiori ad 1 Gigaflop/s 4. Un anno dopo i ricercatori del Goddard Space Flight Center della NASA combinarono due cluster per un totale di 199 processori P6 e girarono una versione PVM del codice PPM (Piecewise Parabolic Method) ad un rate sostenuto di 10.1 Gigaflop/s. Questo non voleva dire che i cluster fossero supercomputer, ma dimostrava il fatto che tale architettura poteva crescere di dimensioni tali da interessare gli utenti di supercomputer. Al di là del programmatore di professione i cluster sono stati implementati e usati anche da persone con pochissima o nessuna esperienza di programmazione. Questo perché il basso costo ne ha permesso l introduzione in ambienti accademici fornendo una piattaforma ideale per la didattica ed una interessante alternativa per il calcolo scientifico. 4 Ossia 1 miliardo di operazioni in virgola mobile al secondo. I flops sono un comune metodo di misurazione della velocità di esecuzione dei computer. Una floatingpoint operation è un operazione su numeri considerando la presenza dei decimali, più complessa e computazionalmente più pesante di un operazione su interi. Le unità di misura più comunemente usate oggi sono il Megaflop ( flops), il Gigaflop (1.000 Megaflops) e il Teraflop (1.000 Gigaflops) [19].

44 34 CAPITOLO 4. STATO DELL ARTE E TECNOLOGIE Tipologie di cluster Molti sostengono che esista una definizione e una tipologia di cluster per ogni cluster realizzato. Una prima distizione tra i vari tipi di cluster si basa sulla natura dei nodi che compongono il cluster, un cluster formato da nodi con caratteristiche identiche 5 è detto omogeneo, mentre se i nodi presentano caratteristiche diverse tra loro il cluster è detto eterogeneo. Oltre a questa distinzione di base è possibile classificare i vari tipi di cluster sulla base della loro struttura e dei servizi che sono in grado di erogare.[20]. Cluster ad alta affidabilità I cluster ad alta affidabilità hanno lo scopo di rendere disponibile un servizio in maniera soddisfacente indipendentemente dal numero di richieste per quel servizio da parte degli utenti. Devono inoltre garantire un livello di scalabilità e di replicabilità molto alto con costi e tempi contenuti. Cluster ad alta disponibilità I cluster ad alta disponibilità sono costituiti prevalentemente da macchine replicate che erogano lo stesso servizio con le stesse caratteristiche e si pongono come obiettivo quello di distribuire il servizio senza soluzione di continuità anche nel caso di indisponibilità di uno degli elementi che costituiscono il cluster. Cluster load balancing Un cluster load balancing si deve occupare principalmente di sfruttare al meglio tutte le risorse all interno della struttura che compone il cluster reindirizzando le richieste degli utenti e della rete sulle macchine che meglio possono assolvere quel compito. Il carico di lavoro viene bilanciato e ridistribuito secondo criteri che permettono l ottimizazione delle risorse e quindi delle prestazioni. 5 Per caratteristiche identiche si intende, ad esempio, stessa architettura, stessa tipolgia di hardware, stesso sistema operativo, ecc.

45 4.1. TECNOLOGIE 35 Cluster per il calcolo parallelo I cluster per il calcolo parallelo sono utilizzati in tutti quegli ambiti in cui è necessaria una grande potenza di calcolo. Non si tratta quindi di condividere risorse o archivi, bensì di condividere hardware di elaborazione. In questo caso un elaborazione viene inviata al cluster che, lavorando come un unica entità, ridistribuisce e suddivide il lavoro tra le macchine presenti nel cluster ottenendo una velocità nel calcolo superiore a quella che si otterrebbe su una singola macchina. Problematiche di Amministrazione nel Cluster Computing Passiamo adesso ad analizzare le problematiche e le difficoltà che coinvolgono la messa a punto e la gestione dei cluster. Il primo aspetto critico di questi sistemi è quello dovuto all omogeneità o meno delle macchine che compongono il cluster, sia per quanto riguarda le architetture, sia per l hardware installato. L intervento dell amministratore può risultare un lavoro veramente difficoltoso, se non impossibile, in presenza di un vasto numero di unità (cluster con centinaia di nodi). Inoltre i problemi si complicano se i nodi non sono omogenei tra loro. In questo caso è necessaria prima di tutto un esatta competenza sulla tipologia di architettura e sull hardware installato su ogni singola macchina; inoltre è inevitabile la necessità di un intervento diretto su ogni singola macchina che differisce dalle altre. I cluster omogenei hanno sicuramente il vantaggio di essere più facilmente installabili, configurabili e gestibili; d altra parte i cluster omogenei presentano un grado di scalabilità notevolmente ridotto, che ha come conseguenza diretta un notevole impedimento per quanto riguarda la possibilità di aggiornare e ampliare l intero sistema. Nei cluster omogenei, infatti, l installazione di nuove tecnologie può avvenire solo se viene rispettata l omogeneità, cioè se il nuovo dispositivo o la nuova tecnologia viene rimpiazzata su ogni unità del cluster. Visto il rapido evolversi delle

46 36 CAPITOLO 4. STATO DELL ARTE E TECNOLOGIE prestazioni, in presenza di piccoli cluster, si può correre il rischio di trovare sul mercato, dopo poco tempo, singole workstation dalle prestazioni addirittura superiori all intero cluster. Nei cluster eterogenei, invece, basta semplicemente collegare alla rete la nuova macchina o installare su singole macchine i nuovi dispositivi per preservare la funzionalità del cluster e sfruttare al tempo stesso le funzionalità e le prestazioni offerte dalle nuove tecnologie, nel pieno rispetto della filosofia COTS. Ovviamente, però, un ampia eterogeneità ha come conseguenza diretta la difficoltà di essere facilmente amministrata dall utente umano, che non può ricordarsi ed essere a conoscenza dell hardware presente su ogni unità. Per questo motivo nasce l esigenza di sviluppare degli strumenti che sostituiscono l intervento umano in questo tipo di attività, con particolare rilievo per quanto riguarda i cluster eterogenei Perl Perl, detto anche Pratical Extraction and Report Language (un acronimo assegnato dopo la creazione del nome) è un Linguaggio di programmazione di alto livello, dinamico, procedurale interpretato creato nel 1987 da Larry Wall. Perl ha un singolare insieme di funzionalità mediate dal C, scripting shell Unix (sh), awk, sed e in diversa misura da molti altri linguaggi di programmazione.[2] Benché sia noto come linguaggio per lo sviluppo di CGI, Perl è stato creato inizialmente come ausilio ai sistemisti, come linguaggio di manipolazione del testo e dei file. Si è evoluto tramite il sistema dei moduli in un linguaggio a carattere più generale, comprendente l elaborazione di immagini, l interrogazione di banche dati e i processi di comunicazione via rete. Il linguaggio è stato pensato per essere pratico (facile da usare, efficiente, completo) oltre che bello (compatto, elegante, minimale). Il suo maggior pregio è la

47 4.1. TECNOLOGIE 37 semplicità ma supporta sia il paradigma procedurale che quello object oriented, ha potenti funzioni per l elaborazione dei testi ed è dotato di una della maggiori collezioni di moduli prodotte dalla sua vasta comunità di utenti. Se a prima vista il Perl appare largamente derivato dal C, in verità ha ricevuto questa somiglianza mediata dai linguaggi di scripting delle shell. Perl è un linguaggio procedurale non tipato con variabili, espressioni, assegnamenti, blocchi delimitati da graffe, strutture di controllo e subroutine. Queste ultime possono essere intese come funzioni e il Perl ha numerose doti mediate dai linguaggi funzionali. Le variabili hanno un prefisso ($ per variabili per array, % per hash) e se questo in parte ha determinato la ricchezza sintattica del Perl, permette l interpolazione delle variabili nelle stringhe. Come le shell Unix, Perl è dotato di molte funzioni di serie per i compiti più comuni come l ordinamento, accesso al sistema operativo. Perl ha preso i vettori associativi (conosciuti come hash ) da awk e le espressioni regolari da sed. Queste semplificano e facilitano molto la parsificazione ed i compiti di trattamento del testo e dei dati. Inoltre c è la possibilità di integrare codice scritto in C in un programma Perl così come viceversa (aggiungere o riscrivere parti in C/C++ in applicazioni o package Perl, o inserire un embedded Perl in programmi C). In verità grazie all uso di moduli Inline:: sono diversi i linguaggi tramite i quali possono essere definite le funzioni di un sorgente Perl. Perl è comunemente ritenuto un linguaggio interpretato, ossia che per essere eseguito viene interpretato al momento dell esecuzione. In realtà, la prima cosa che fa l interprete è di trasformare il codice sorgente in bytecode, un po come Java; sul bytecode crea un grafo intermedio sul quale applica ottimizzazioni, ed è questo grafo ad essere interpretato. Questo approccio permette di limitare la lentezza tipica dei linguaggi interpretati. La versione del Perl6, in via di sviluppo da alcuni anni,

48 38 CAPITOLO 4. STATO DELL ARTE E TECNOLOGIE divide l esecutore del bytecode (o virtual machine) dal linguaggio in modo tale da permetterne l utilizzo anche da compilatori di altri linguaggi, tra cui Tcl, Python, Java, etc. Ancora una volta è stato messo in evidenza come il Perl sia un linguaggio socievole, che tende quindi a interagire con gli altri linguaggi e ambienti di sviluppo, siano essi: dialetti shell, altri linguaggi interpretati, linguaggi specializzati (come l SQL), o i più comuni linguaggi compilati. Questa è la ragione che determina il successo di Perl nell integrazione di sistemi diversi. Perl è nato in ambiente Unix e distribuito contemporaneamente con due licenze liberali, la GPL e la Licenza Artistica, è disponibile anche per i sistemi operativi Microsoft Windows e MacOS precedente alla versione MacOS X (che appartiene alla famiglia Unix).[12] Benché il Perl sia stato una delle grandi novità nel campo della programmazione, il giudizio su di esso da parte della comunità di programmatori è vario. Da un lato viene giudicato negativamente per il fatto che facilita la scrittura di programmi difficili da leggere e quindi rendendo complicata la loro manutenzione. Dall altro viene apprezzato per la facilità di scrivere programmi potenti ma semplici, per la libertà semantica che lascia al programmatore al punto che There s more than one way to do it 6 è uno dei modi di dire legati a Perl. Wall, che per formazione è un linguista, ritiene questa libertà semantica un pregio, in quanto più simile al linguaggio umano. Un ulteriore aspetto positivo che attrae i programmatori è l ampia disponibilità di moduli rilasciati con licenze open source, quasi sempre le stesse di Perl. Moduli solitamente ben documentati, in quanto il linguaggio stesso offre il Pod, un modo di includere la documentazione all interno del codice, garantendo cosí che assieme al modulo ci sia pure la documenta- 6 TIMTOWTDI, spesso pronunciato come TIMTODAY, tradotto: C è più di un modo per fare le cose

49 4.1. TECNOLOGIE 39 zione. La comunità ha creato un sito particolare, chiamato CPAN, il quale organizza per argomenti i moduli ritenuti particolarmente validi. I moduli stessi non sono archiviati in quel sito, ma rimangono sui siti scelti dai loro autori. Infine, in quanto linguaggio interpretato e dunque sempre distribuito con il codice sorgente visibile, favorisce la pratica liberale. Altre caratteristiche importanti di Perl sono: le variabili di default che sono definite per molte funzioni e operatori builtin del perl la sensibilità del contesto negli assegnamenti, dove Perl sa riconoscere cosa restituire in base al left value le espressioni regolari, che permettono la ricerca e la sostituzione di stringhe di testo descritte con caratteri speciali le Closure la possibilità di applicare paradigmi di programmazione diversi, come quello funzionale o quello ad oggetti, impossibile con altri linguaggi. Alcune caratteristiche del Perl, tra cui la sintassi, permettono una sintesi raramente possibile con altri linguaggi ed impossibile con linguaggi tipo Java e i sorgenti possono dunque essere molto densi di significato, tanto da risultare criptici a chi non ne conosca i rudimenti. In compenso su Internet c è così tanta documentazione sul Perl che è possibile avvicinarsi rapidamente al linguaggio e con opportuni testi di riferimento iniziarne la strada dell apprendimento. Il linguaggio e l interprete vengono sviluppati da un gruppo di circa cento sviluppatori, guidati da Wall, il quale prende le decisioni finali su cosa includere nel codice. Gli sviluppatori hanno creato il Perl Institute per facilitare lo sviluppo di Perl e migliorarne la visibilità e organizzano conferenze.

50 40 CAPITOLO 4. STATO DELL ARTE E TECNOLOGIE Perl fa parte degli strumenti standard dei sistemi operativi Unix. La comunità Perl è sovente attaccata per l assenza di un IDE come quelli presenti per Java che rendano semplice l avvicinamento al linguaggio da parte dei neofiti. In realtà la ricchezza espressiva del Perl rendono complicata la realizzazione di un IDE che evidenzi errori di costruzione degli statement, e dati i numerosi valori di default delle funzioni base risulterebbe oltremodo difficile comprendere in automatico cosa vuole ottenere il programmatore, dove c e un errore o forse no. Tuttavia recentemente un IDE come Eclipse contiene una estensione per il Perl, anche se ad oggi lo strumento migliore per programmare in Perl risulta essere il semplice editor di testo SNMP Introduzione SNMP (Simple Network Management Protocol) è uno standard che definisce un protocollo di rete per la gestione di dispositivi sulle reti IP. SNMP nasce nel 1988 dall esigenza di costruire uno strumento standard per tenere sotto controllo le reti IP in costante crescita per numeri e complessitá. A differenza del suo predecessore SGMP (Simple Gateway Management Protocol) che permetteva di gestire esclusivamente i router, SNMP é in grado di gestire una gran quantitá di dispositivi oltre ai router, tra questi vi sono switch, server, workstation, stampanti, modem e gruppi di continuitá. In pratica ogni dispositivo che in grado di eseguire software per la comunicazione tramite SNMP puo essere gestito da remoto, e non vanno intesi solo dispositivi fisici e funzioni hardware, ma anche le soluzioni software quali possono essere web server o database. SNMP viene usato per monitorare costantemente questi apparati di rete per assicurarsi che non solo questi siano regolarmente in funzione ma anche che le loro

51 4.1. TECNOLOGIE 41 prestazioni siano ottimali. Il compito di SNMP non si ferma soltanto al monitorare, ma è ben piú ampio e comprende la possibilita di gestire da remoto questi apparati e di rispondere tramite azioni automatiche (trigger) a situazioni previste. SNMP definisce un semplice set di operazioni che possono essere compiute sui dispositivi remoti supportati; queste operazioni sono la base per programmare applicazioni di genere amministrativo per sfruttare nel miglior modo possibile questi dispositivi. Il protocollo SNMP è uno standard definito dalla IETF (Internet Engineering Task Force) attraverso i suoi documenti RFC (Request for Comment) e negli anni ha subito alcune revisioni, attualmente si distinguono tre versioni di SNMP: SNMPv1: descritto nelle RFC rappresenta la prima versione, utilizza l invio dei nomi di community (una specie di password per SNMP) in chiaro. SNMPv2: descritto nelle RFC in cui sono state aggiunte alcune funzionalitá tra cui la crittografia tramite algoritmi MD5. SNMPv3: descritto nelle RFC , sebbene sia lo standard attuale è ancora troppo giovane per essere supportato dalla maggioranza dei dispositivi e risulta quindi raramente utilizzato. SNMP opera al livello 7 (livello applicazioni) del modello OSI, sebbene teoricamente possa funzionare su reti di ogni tipo, in pratica risulta sfruttato sopratutto su reti IP appoggiandosi sopra il protocollo di trasporto UDP (User Datagram Protocol). UDP è un protocollo non rivolto alla connessione, in pratica non viene creata nessun tipo di connessione punto-punto durante la trasmissione dei pacchetti. Questo aspetto di UDP lo rende un protocollo non affidabile poiché non c è alcuna

52 42 CAPITOLO 4. STATO DELL ARTE E TECNOLOGIE possibilitá di riconoscere che un pacchetto è andato perduto durante la trasmissione. É quindi compito dell applicazione SNMP comprendere se si sono persi alcuni messaggi e nel caso ritramsetterli. Questo viene di solito realizzato tramite dei tempi di timeout oltre i quali se l applicazione non riceve alcuna risposta considera il messaggio precedente perduto e ripete la richiesta. Sia il tempo di timeout che il numero massimo di ritrasmissioni sono impostazioni configurabili dall applicazione. A lato di questa inaffidabilitá, tra il vantaggio di UDP è il basso overhead rispetto alla controparte TCP (Trasmission Control Protocol). Un basso overhead significa un minor impatto sulle prestazioni della rete, e siccome SNMP si occupa di monitorare la rete, è importante che la influenzi il meno possibile. Inoltre SNMP viene utilizzato maggiormente nelle condizioni di malfunzionamento della rete e in quelle condizioni risulta migliore un protocollo che tenta di inviare dati attraverso la rete ma desiste se non vi riesce rispetto ad un altro protocollo che rischia di congestionare la rete con le continue ritrasmissioni nel tentativo di conservare la sua affidabilitá. I tre componenti fondamentali del framework SNMP sono: sistema gestito (managed object) agente di gestione (management agent) sistema di gestione (manager) Il sistema gestito puó essere un semplice nodo di rete, un router, una stampante o qualsiasi altro dispositivo che fornisca una interfaccia di gestione SNMP. Ogni sistema gestito ospita un agente di gestione (agent). Il manager è il sistema che si occupa di eseguire il software per i compiti di amministrazione di rete, ci si puó riferire a lui anche con l acronimo NMS (Network Management System). Il manager per conoscere lo status dei dispositivi di

53 4.1. TECNOLOGIE 43 rete sfrutta due metodi di comunicazione, le poll, ovvero le query dirette all agente, oppure le trap. La trap è la modalitá che ha l agente per informare l NMS che è successo qualcosa. Le trap sono comunicazioni asincrone, non in risposta a query dell NMS. In seguito alla ricezione di trap, l NMS diviene responsabile della situazione e deve decidere quale sia l azione da compiere in base alle informazioni ricevute dall agente. Per esempio se cade la connessione con Internet, il router interessato puo avvertire l NMS responsabile con una trap. In seguito l NMS dovrebbe essere in grado di riconfigurare i dispositivi di rete per sfruttare una connessione di backup, cosí da risolvere la situazione nel modo piu trasparente possibile per l intera struttura di rete. SNMP usa la porta UDP 161 per inviare e ricevere le nomarli richieste mentre utilizza la porta 162 per ricevere le trap dagli agenti. Ogni dispositivo SNMP utilizza queste porte come default, ma è comunque possibile cambiarle a patto che gli NMS della rete vengano anch essi riconfigurati in base a alle modifiche effettuate. L agente è il software che gira sul sistema gestito, è l interfaccia tra il manager e il sistema gestito. La natura dell agente puó essere di vario genere. L agente puó essere un programma a sé stante (un demone, in linguaggio Unix) oppure essere incorporato nel sistema operativo (come ad esempio nell IOS di un router Cisco, o nel sistema che controlla un UPS). Oggigiorno la maggior parte dei dispositivi IP viene equipaggiata con un agente SNMP preinstallato rendendo cosí piu semplice il compito degli amministratori di rete. In alcuni casi l agente puó essere implementato in maniera modulare con una netta distinzione tra i suoi compiti. In questi casi è lecito parlare di master agent che si occupa di dialogare con il manager fornirgli le informazioni e ricevere le decisioni e di subagent che possono essere piú di uno, ognuno dei quali si occupa di attuare le decisioni del manager o rispondere alle sue richieste sulla parte del sistema gestito che gli compete, dividendo cosí il sistema gestito in sottosistemi indipendenti l uno dall altro. L agente ha il compito

54 44 CAPITOLO 4. STATO DELL ARTE E TECNOLOGIE di rispondere alle poll dell NMS e di generare trap quando la situazione lo richiede. Considerando la natura sincrona delle poll e quella asincrona delle trap, questi due eventi possono coincidere ed è importante per ogni implementazione di SNMP riuscire a gestire anche queste situazioni. SNMP Communities Le versioni SNMPv1 e SNMPv2 utilizzano il concetto di comunitá (community) per garantire la sicurezza delle comunicazioni tra manager e agente. Un agente comunica solamanete con manager che appartengano ad una delle sue tre comunitá: solo-lettura, lettura-scrittura e trap. L appartenenza ad una comunitá è sancita dalla comunicazione del nome della comunitá stessa fornito insieme alle eventuali richieste. Il nome della comunitá deve essere una stringa di massimo 32 caratteri di tipo case sensitive ed in pratica la sua funzione è quello di vera e propria password di accesso. L agente permetterá attivitá diverse a seconda del nome di comunitá che il manager gli fornisce. In caso di comunitá sola-lettura il manager potrá ricevere i dati dall agente ma non potrá né alterarli né richiedere nessuna azione all agente. Ad esempio si potrebbe leggere il numero dei pacchetti trasferiti da un router ma non si potrebbe resettare tale contatore. Invece con la comunitá lettura-scrittura si potrebbe sia leggere il numero di pacchetti che resettare il contatore che cambiare la configurazione del router. Infine la comunitá trap permette al manager di ricevere le trap dall agente. Molti produttori equipaggiano i loro dispositivi con dei nomi di comunitá predefiniti, tipicamente public per la comunitá sola-lettura e private per la letturascrittura. Ovviamente è bene modificare tali impostazioni di default per motivi di sicurezza. Purtroppo la sicurezza è uno degli aspetti negativi di SNMP, i nomi di comunitá vengono inviati in chiaro durante le comunicazioni e quindi facilmente intercettabili; solamente con l ultima versione, la SNMPv3, si è fornito questo pro-

55 4.1. TECNOLOGIE 45 tocollo con un vero e proprio sistema di autentificazione e comunicazione sicura. Fino a quando SNMPv3 non verrá adottato da tutti i dispositivi SNMP, chi amministra questi apparati deve avere un occhio di riguardo verso la sicurezza della propria rete considerando SNMP facilmente vulnerabile. MIB SNMP utilizza una chiara separazione fra il protocollo di gestione e la struttura dell oggetto gestito. Nell architettura SNMP, per ogni sistema gestito è definita una base di dati detta MIB (Management Information Base) gestita dall agente, nel caso modulare vi sará una MIB per ogni sottosistema, ognuna delle quali gestita da un subagent. Ad ogni sottosistema gestito corrisponde una MIB, ed ogni agente puo implementarne quante ne vuole, l unico vincolo che pone SNMP in questo senso è che ogni agente debba implemntare una MIB in particolare chiamata MIB-II (RFC 1213). Questo standard definisce variabili per alcune caratteristiche fondamentali di SNMP, come le statistiche per le interfacce di rete (velocitá di trasmissione, MTU, ottetti trasmessi 7, ottetti ricevuti, ecc.) ed altre informazioni pertinenti il sistema (locazione del sistema, contatti di riferimento). Oltre al MIB-II esistono MIB per i piu svariati scopi, per gestire oggetti e caratteristiche di sistemi di diversa natura (router, DNS server, Mail server,...). La MIB rappresenta lo stato del sistema gestito, o meglio, una proiezione di tale stato limitata agli aspetti di cui si vuole consentire la gestione. Si tratta di una base dati che si potrebbe definire, mutuando un termine dalla riflessione, causalmente connessa: in altre parole, ogni modifica alla MIB causa un corrispondente mutamento nello stato del sottosistema rappresentato, e viceversa. Garantire questa proprietà della MIB è la funzione principale dell agente che la gestisce. 7 SNMP chiama ottetti i gruppi di 8 bit meglio conosciuti come byte

56 46 CAPITOLO 4. STATO DELL ARTE E TECNOLOGIE L accesso alla MIB (in lettura e scrittura) rappresenta l interfaccia fornita al manager per gestire il sistema. Ogni MIB, pur variando nei contenuti specifici, ha la medesima struttura generale e i medesimi meccanismi generali di accesso da parte del manager (lettura e scrittura dei dati). Grazie alla connessione causale della MIB, è quindi possibile al manager agire sullo stato del sottosistema in un modo che è largamente indipendente dalle procedure concrete che devono essere messe in atto (dal subagent) per estrarre le informazioni di stato rappresentate nella MIB, o attuare le modifiche di stato a seguito di cambiamenti dei contenuti della MIB. Così, per esempio, si potrebbe avere un dato di MIB che rappresenta l indirizzo IP del sistema gestito; per modificare tale indirizzo, al manager è sufficiente accedere alla MIB sovrascrivendo il dato corrispondente, prescindendo dei dettagli di come una tale modifica venga poi concretamente attuata sul sistema gestito. SMI La definizione di una MIB si basa sulla SMI (Structure of Management Information). SMI fornisce un modo di rappresentare gli oggetti gestiti mentre il MIB contiene la definizione degli oggetti stessi espressa tramite la sintassi di SMI. Nella sintassi di SMI ogni oggetto gestito viene definito tramite tre attribuiti: Nome, Tipo e Codifica. Nome Il nome, anche detto OID (Object Identifier) definisce univocamente l oggetto gestito. I nomi possono apparire in due forme equivalenti: numerica o letterale. In entrambi i casi risultano essere nomi molti lunghi e complicati, difatti molto del lavoro delle applicazioni SNMP consiste nel fornire un interfaccia più intuitiva agli oggetti gestiti. Lo schema dei nomi alla base di SNMP è infatti basato su una struttura gerarchica ad albero. Ogni OID riproduce la posizione dell oggetto gestito nell albero.

57 4.1. TECNOLOGIE 47 Nell albero degli oggetti, il nodo in alto é la root (radice) dell albero. Per definire l OID di un ramo o di una foglia dell albero gerarchico vengono presi in considerazione i nodi che lo legano alla root in una sequenza separata da punti. Per la notazione numerica, tutti i figli di uno stesso nodo vengono indicati con un numero intero crescente da sinistra a destra. Per la notazione letterale ogni nodo viene indicato con un etichetta. Considerando l albero degli oggetti in figura 4.1, l OID del nodo internet viene rappresentato come in notazione numerica per uso interno dell agente SNMP e come iso.org.dod.internet in notazione letterale. Tipo Il tipo di dato di un oggetto gestito viene definito utilizzando un sottoinseme dell ASN.1 (Abstract Syntax Notation One). ASN.1 è una notazione standard e flessibile per rappresentare e trasmettere strutture dati. Il punto di forza di ASN.1 é che la sua notazione è indipendente dalla codifica della macchina, questo significa che con ASN.1 un PC che utilizza Windows puó dialogare con un Sun SPARCstation senza preoccuparsi della codifica dei dati scambiati, come ad esempio l ordine dei byte. Net-SNMP Per l utilizzo e lo sviluppo di applicazioni che si basano su SNMP sono disponibili diverse strumenti, tra questi la soluzione piú completa e maggiormente utilizzata è sicuramente Net-SNMP. Net-SNMP è un suite di applicazioni opensource volte all implementazione dei protocolli SNMPv1, SNMPv2 e SNMPv3 utilizzabili sia con IPv4 che con IPv6.

58 48 CAPITOLO 4. STATO DELL ARTE E TECNOLOGIE Figura 4.1: Albero degli oggetti della MIB

59 4.1. TECNOLOGIE 49 Net-SNMP è disponibile per molti sistemi operativi Unix e Unix-Like ed anche per Microsoft Windows. La suite Net-SNMP comprende: Applicazioni da riga di comando in grado di: ricevere informazioni da un dispositivo SNMP, sia utilizzando richieste singole (snmpget, snmpgetnext) sia richieste multiple (snmpwalk, snmptable, snmpdelta) modificare le informazioni di configurazione di un dispositivo SNMP (snmpset) recuperare un insieme prefissato di informazioni da un dispositivo SNMP (snmpdf, snmpnetstat, snmpstatus) convertire gli OID dei MIB tra il formato numerico e quello testuale, e visualizzare il contenuto e la struttura di una MIB (snmptranslate) un browser grafico per le MIB basato su Tk/perl. un demone per ricevere le notifiche SNMP (snmptrapd). Le notifiche selezionate possono essere loggate (nel syslog, nel NT Event Log, oppure in testo semplice), inoltrate ad un altro NMS oppure passate ad un applicazione esterna. Un agente estensibile per rispondere alle query SNMP (snmpd). Include supporto build-in per un vasto numero di MIB e puó essere esteso utilizzando moduli caricati dinamicamente, script e comandi esterni, e i protocolli SNMP Multiplexing (SMUX) e Agent Extensibility (AgentX). Una libreria per lo sviluppo di nuove applicazioni SNMP comprendente API sia per il C che per il perl

60 50 CAPITOLO 4. STATO DELL ARTE E TECNOLOGIE Modulo Perl SNMP::Info SNMP::Info è un modulo Perl5 che fornisce un interfaccia orientata agli oggetti per i dispositivi di rete SNMP e le informazioni contenute nelle MIB. Questo modulo nasce dallo sviluppo del Network Manager opensource NetDisco e si basa sul modulo perl Net::SNMP della suite Net-SNMP. Grazie all utilizzo di SNMP::Info il recupero delle informazioni da un dispositivo SNMP puó essere svincolato dai comandi specifici di questo protocollo come Get o GetNext; ogni dispositivo SNMP viene visto come un oggetto con campi e metodi specifici delle MIB che implementa. Ogni MIB implementata da un dispostivo viene considerato alla stregua di una classe a cui l oggetto appartiene. Aggiungendo questo livello di astrazione SNMP::Info semplifica notevolmente il compito del programmatore alle prese con il protocollo SNMP. 4.2 Software esaminati Nella ricerca di una soluzione al problema dell autodiscovery delle configurazioni in una rete si è partiti con l esaminare i software disponibili sul mercato. Nell esaminare i prodotti si è tenuto conto dei requisiti richiesti, delle funzionalità offerte, della qualità generale del prodotto e d anche del contesto in cui avrebbe dovuto operare ovvero la rete di amministrazione di cluster destinati all HPC. Sebbene al momento attuale il mercato delle soluzioni software di questo tipo abbia un target ristretto a pochi operatori professionali alle prese con vasti parchi di sistemi informatici,i produttori di software commerciale non sono rimasti indifferenti di fronte alle esigenze di questi pochi, ma generalmente facoltosi, operatori. Come spesso accade nell ambito del software i prodotti commerciali sono quelli che per primi si sono affacciati sul mercato cercando di coprire la domanda con

61 4.2. SOFTWARE ESAMINATI 51 le le loro offerte. Al contrario i prodotti opensource sono arrivati sul mercato relativamente da poco e quindi sono generalmente meno maturi, ma grazie alle qualità del modello di sviluppo stanno recuperando molto velocemente l osvantaggio temporale. Quest analisi preliminare sui prodotti software non si è basata su test pratici o dimostrazioni, ma solamente sullo studio della documentazione rilasciata pubblicamente dai produttori. Mediante quest approccio di analisi si è potuto notare come anche la presentazione dei prodotti tramite la documentazione sia sostanzialmente diversa nell ambito commerciale rispetto a quello opensource. In ambito opensource la documentazione oltre a fornire le caratteristiche del software e le sue funzionalità è in grado di approfondire dettagliatamente gli aspetti tecnici e di implementazione. Per ovvi motivi la documentazione di un prodotto commerciale a sorgenti chiusi non pu o scendere altrettanto dettagliatamente negli aspetti tecnici, ma in realtà quello che si nota è un approccio totalmente diverso alla presentazione del prodotto. In genere il prodotto commerciale viene presentato utilizzando un linguaggio ed un enfasi propria del marketing senza mai scendere nel dettaglio tecnico, senza mai specificare neppure i requisiti che debbono verificarsi affinchè le funzionalità dichiarate possano realmente operare. È facile intuire che il target della presentazione dei software comemrciali non è l utilizzatore del software, in questo caso l amministratore di sistema, bensì un generico acquirente per lo più ignaro delle problematiche che riguardano l adozione di un nuovo software. Sebbene fosse esplicita una preferenza per il modello di sviluppo opensource tra i requisiti di qualità, l analisi dei software ha inizio con i software commerciali di tre tra i più attivi produttori di software in ambito professionale: BMC, Ibm e Hp.

62 52 CAPITOLO 4. STATO DELL ARTE E TECNOLOGIE Software Commerciali BMC (http://www.bmc.com) La proposta di BMC si basa sul loro CMDB (Configuration Management DataBase) di nome Atrium. Nell offerta di BMC, attorno al database orbitano tutta una serie di applicazioni volte alla gestione delle risorse a disposizione di una generica azienda. Per questo BMC offre i suite completa, o in componenti separati, applicativi per la gestione del personale, del magazzino, di un generico processo di produzione e tra le tante anche la gestione dell infrastruttura informatica. La parte quindi che ci interessa di questa suite di applicazioni è il prodotto denominato BMC Configuration Discovery. Questo prodotto è realizzato tramite un architettura ibrida in parte agentless, in parte agent-based, basata sul protocollo HTTP e dotata di un database centrale in grado di raccogliere i dati in un unica vista globale dell intera infrastruttura informatica. Questo genere di architettura è piuttosto comune, la BMC sembra non aver optato per nessuna scelta particolarmente radicale e innovativa cercando un buon compromesso tra i pregi e i difetti delle tecnologie esistenti. IBM (http://www.ibm.com) Ibm all interno della suite di applicazioni Tivoli offre la sua soluzione software denominata Tivoli Configuration Manager. Questo software è basato su un architettura agent-based di tipo tradizionale e permette il discovery e la gestione dell inventario dei sistemi informatici nell ambiente di rete. anche in questo caso le caratteristiche sono standard e comprendono

63 4.2. SOFTWARE ESAMINATI 53 la possibilità di effettuare il deployment di pacchetti o patch software per i sistemi gestiti. Tra i prodotti Tivoli, Ibm offre anche un altro interessante componente denominato Tivoli Application Dependency Discovery che fornisce funzionalità di discovery sui sistemi informatici distribuiti basandosi su un architettura completamente agentless che sfrutta il protocollo SNMP, ma anche SSH, in modo da garantirsi una buona profondità dell azione di discovery. Purtroppo quest applicazione è mirata per lo più alla gestione e al monitoring di applicazioni distribuite piuttosto che all infrastruttura informatica in se e quindi non riesce a fornire i dettagli specifici per questo problema. HP (http://www.hp.com) Anche HP offre un prodotto per effettuare il disocvery dei sistemi informatci in rete, il suo nome è Hp Enterprise Discovery. Anche questo software utilizza un approccio ibrido agent-based/agentless, ma a differenza degli basa la sua struttura su un server centrale che obbligatoriamente deve girare su piattaforma Microsoft Windows. Questo requisito risulta abbastanza stringente per l ambiente in cui il software dovrebbe essere testato ed operare. Infatti attualemnte non ci sono piattaforme Microsoft Windows nella rete di amministrazione dei cluster del CINECA ed introdurne una al solo scopo di gestire le altre non sarebbe una buona scelta. Tutti questi software commerciali hanno la capacità di effettuare il discovery mediante l utlizzo di agenti software da installare sui dispositivi presenti in rete. Questi agenti sono sviluppati dai rispettivi produttori per essere installati su ungran

64 54 CAPITOLO 4. STATO DELL ARTE E TECNOLOGIE numero di piattaforme diverse: Microsoft windows, Mac OsX, AIX, HP-UX, Unix, Solaris, Gnu/Linux. Purtroppo come spesso accade per i software commericali che operano in ambiente Gnu/Linux, il funzionamento di tali agenti è garantito solo per alcune distribuzionie solamente per alcune versioni. Per i software opnsource che analizzeremo in seguto questo problema non si verifica, infatti qualora utilizzassero agenti software questi possono essere facilmente ricompilati ed adattati ad ogni distribuzione Software Opensource A differenza dei software commerciali, nel panorama dei software opensource c è molta eterogeneità e una grande quantità di offerte. Come spesso accade in ambito opensource i progetti nascono e muoiono continuamente e anche per quelli che superano la fase embrionale non è facile avere garanzie sull effettivo sviluppo. Così nel vasto parco di offerte opensource rivolte all autodiscovery delle configurazioni di sistemi in rete si trovano alcuni prodotti con architettura agent-based come H-Inventory che mirano al target della gestione dell inventario dei sistemi informatici e supportano sia la piattaforma Linux che Microsoft Windows, ma che risultano ancora troppo giovani per essere valutati come un opzione implementabile. Anche zci si basa sugli agenti, ma non risulta applicabile al contesto di utilizzo richiesto in quanto sebbene la sua roadmap di sviluppo preveda l adozione di agenti Linux, al momento risulta in grado di monitorare solo host Microsoft Windows. Esistono inoltre anche altri prodotti come NetDirector, eslusivamente agentbased, o Pandora, dalla struttura ibrida, che sono davvero dei buoni prodotti per il discovery dei sistemi in rete, ma che purtroppo hanno un target diverso da quello della gestione dell inventario dei sistemi. Questi due software, infatti, sono svilup-

65 4.2. SOFTWARE ESAMINATI 55 pati per monitorare le attività dei servizi offerti da sistemi distribuiti e andrebbero pesantemente riadattati per poterli utilizzare per raggiungere gli obiettivi richiesti. Un altro software interessante è Zenoss. A differenza degli altri Zenoss ha una struttura completamante agentless basata per lo più sul protocollo SNMP. In questo caso il server è composto da diversi demoni separati, ognuno atto a svolgere un determinato compito di discovery. Il server gira su piattaforma Linux, ma è in grado di dialogare con qualsiasi dispositivo che implementi un agente SNMP. Putroppo questo tipo di discovery agentless non è sufficiente per l elevato livello di dettaglio dei dati che sono richiesti. Hyperic è invece un prodotto che cerca di mediare tra i pregi di uno sviluppo opensource e i benefici che offre un prodotto esclusivamente commericale. È un prodotto che offre un discovery di tipo ibrido basato sia su agenti software che sul protocollo SNMP. La parte server di Hyperic viene rilasciata con licenza opensource in modo da permettere teoricamente un facile sciluppo, ma le funzionalità della sola parte opensource sono decisamente limitate e la software house ha previsto di integrarla tramite un corredo di plugin a sorgenti chiusi e a pagamento in modo da estenderle le funzionalità. Sebbene il prodotto appaia di buon livello, questa strategia di commercializzazion non convince ed inoltre nessuno dei plugin esistenti riesce a soddisfare alcuni dei requisiti base, come ad esempio il discovery del sfotware Tra i software opensource compare anche OCS Inventory NG, software che per le sue caratteristiche è parso essere il più adatto a soddisfare i requisiti di funzionalità e qualità precedentemente individuati. Anche se questa soluzione non aderisce totalmente alle richieste, è sembrata da subito una buona base di partenza per poter sviluppare anche le funzionalità di cui era sprovvista.

66 56 CAPITOLO 4. STATO DELL ARTE E TECNOLOGIE 4.3 OCS Inventory NG Motivazioni della scelta OCS Inventory NG è un software opensource dall architettura esclusivamente agent-based. Tra tutti i software opensource è apparso come quello più affidabile poiché il suo sviluppo iniziato ufficialmente nel luglio 2002 è sempre progredito con costanza fino a raggiungere la prima versione stabile ed ufficiale nel corso del gennaio Già dalle prime versioni ha subito suscitato interesse dentro e fuori la comunità opensource ed è stato adottato anche da software di terze parti 8 che sviluppano prevalentemente CMDB (Configuration Management DataBase) come struemnto per l autodiscovery impiegato per popolare automaticamente i database da loro prodotti. La comunità degli sviluppatori e degli utenti risulta essere molto attiva e il software è già impiegato in diverse realtà professionali. Inoltre OCS Inventory NG è stato anche premiato durante l edizione 2006 del concorso Trophées du Libre come miglior progetto nell ambito della sicurezza informatica. Dal punto di vista del rispetto dei requisiti preposti (cfr. Capitolo 2), OCS Inventory NG soddisfa compeltamente i requisiti di qualità e in larga parte anche quelli funzionali. L utilizzo delle risorse è molto ridotto in quanto l agente software viene eseguito una sola volta al giorno con tempi e requisiti di esecuzione per lo più trascurabili. La rete viene utilizzata solamente per le comunicazioni tra le varie parti del software, ma lo scambio di messaggi è limitato dalal bassa frequenza si esecuzione degli agenti, inoltre i messaggi scambiati vengono sempre compressi in modo da ridurne le dimensioni. 8 CMDBuild GLPI

67 4.3. OCS INVENTORY NG 57 I dati vengono aggiornati quotidianamente per ogni computer presente in rete e così anche il requisiti di validità dei dati è soddisfatto. L interfaccia di amministrazione è realizzata tramite un server web e non evidenziato particolari difetti di usabilità durante i test effettuati. OCS non utilizza nessun tipo di criptaggio dei messaggi, durante le sue comunicazioni, allo scopo di mantenere più basso possibile l utilizzo delle risorse di rete. Non dovrebbero sussitere problemi di sicurezza finchè i componenti del software restano tutti confinati all interno di una rete sicura e l accesso ai dati raccolti è comunque protetto da un semplice sistema di password. Il modello di sviluppo è uno dei veri e propri punti di forza di questo software. Oltre alal già citaa licenza opensource il software di OCS è stato scritto per sfruttare un semplice ed efficace sistema di plugin. Inoltre il linguaggio principale utilizzato per lo sviluppo di OCS è il Perl che per sua natura di linguaggio interpretato evita un gran numero di problematiche riguardo la compilazione del software per le varie piattaforme. Per quanto riguarda i requisiti funzionali, il discovery delle caratteristiche dei componenti hardware è già completamente implementato con un dettaglio addirittura più accurato rispetto a quello richiesto. Sebbene OCS abbia le fnzionalità per effettuare il discovery delle caratteristiche software, attualmente non effettua nessuna investigazione sui servizi disponibili. Inoltre OCS non dispone di alcuno strumento che gli permetta di effettuare il discovery dei dispositivi di rete ed è anche limitato nel discovery della topologia di rete. Infatti OCs possiede funzionalità in grado di discoverare i dispositivi che compongono la rete (i nodi della topologia), ma non riesce in alcun modo a stabilire le connessioni tra di essi (gli archi della topologia).

68 58 CAPITOLO 4. STATO DELL ARTE E TECNOLOGIE Data la bontà del progetto e delle funzionalità già disponibili è stato deciso di utilizzare proprio questo software come struemnto di partenza. Nel corso del lavoro di tesi si è quindi sviluppato le funzionalità mancanti e si è testato l applicazione nel contesto in cui dovrebbe operare nella pratica Analisi di OCS Inventory NG OCS Inventory NG (Open Computer and Software Inventory Next Generation) è un applicazione disegnata per aiutare l amministratore di sistema e di rete a monitorare le configurazioni dei computer e dei software installati nella rete. Informazioni inventariate OCS Inventory NG permette di invetariare automaticamente le seguenti informazioni: BIOS: numero seriale di sistema, produttore del sistema, modello, produttore del BIOS, versione del BIOS, data del BIOS. Processori: tipo, clock, numero di processori. Memoria: descrizione, capacità, tipo (system memory, flash memory,...), architettura (SDRAM, DDR,...), clock, numero degli slot, memoria fisica totale, memoria di swap. Input device: tipo (tastiera, dispositivo di puntamento), produttore, descrizione, interfaccia usata (PS/2, USB,...). System ports: tipo (seriale o parallela), nome, descrizione. System slots: nome, descrizione, tipo (AGP1, PCI1, PCI2, ISA1,...).

69 4.3. OCS INVENTORY NG 59 System controllers: produttore, nome, descrizione, tipo (floppy, ide, scsi, usb,...) Periferiche per lo storage: produttore, modello, descrizione, tipo (floppy, hard disk, cdrom,...) capacità. Dischi logici: tipo, filesystem, capacità, spazio libero. Schede audio: produttore, nome, descrizione. Schede video: nome, chipset, quantità di memoria, risoluzione dello schermo. Monitor: produttore, descrizione, tipo, numero di serie. Modem: nome, modello, descrizione, tipo (esterno, interno,...). Schede di rete: descrizione, tipo (dialpu, ethernet, token ring, atm,...) indirizzo MAC, indirizzo IP, Subnet Mask, IP gatweay, DHCP server. Stampanti: nome, driver, porta di connessione. Sistema operativo: nome, versione, commenti (realese, service pack,...). Software: nome, versione. L architettura OCS Inventory NG utilizza un agente che esegue l inventario sui computer client e un Management Server che riceve e mantiene i risultati degli inventari di ogni client. Inoltre il Management Server permette la visione dei risultati e la creazione di pacchetti per il deployment 9. 9 deployment: in linguaggio militare significa dispiegamento inteso come porre le truppe militari in posizione per il combattimento. In Ingegneria va inteso come la messa in produzione di un

70 60 CAPITOLO 4. STATO DELL ARTE E TECNOLOGIE Le comunicazioni tra gli agente e il Management server sono basate sui protocolli HTTP/HTTPS. Tutti i dati scambiati sono formattati in XML compresso tramite Zlib per ridurre il traffico di rete. Gli agenti devono essere installati sui computer client. OCS possiede uno strumento basato su script di login o sull Active Directory GPO 10 per fare il deploy dell agente su client windows. Al contrario su sistemi Linux l agente deve essere installato manualmente. OCS Inventory NG può utilizzare lo strumento di deployment anche per permettere l eventuale aggiornamento dell agente ad una nuova versione. Il Management server contiene 4 componenti principali: Database server, per conservare le informazioni di inventario. Communication server, che gestisce le comunicazioni HTTP tra il Database Server e gli agenti. Deployment server, che mantiene le configurazioni per il deployment dei pacchetti (richiede HTPPS) Administration console, che permette agli amministratori di eseguire sul Database Server tramite il browser. Questi quattro componenti possono essere ospitati su un singolo computer oppure su computer diversi per permettere un mioglior bilanciamneto del carico. Per inventariare più di computer, è meglio usare almeno due server diversi, uno sistema. Nel caso specifico si intende la distribuzione del software verso un sistema remoto e la sua esecuzione. 10 Active Directory Group Policy Objects sono parte della tecnologia IntelliMirror di Microsft che ha lo scopo di ridurre i costi del supporto agli utenti di Windows, La Group Policy fornisce uno strumento di gestione centralizzato di computer ed utenti nell ambiente Active Directory. Active Directory è l implementazione dei LDAP directory services sviluppata da Microsoft per ambienti Windows.

71 4.3. OCS INVENTORY NG 61 Figura 4.2: L architettura di OCS Inventory NG come Database server e Comminication server e l altro come replica del Database, Administration server e Deployment server. Database server: al momento è supportato solamente MySql 4.1 o superiore. Communication server: è possibile utilizzare sia la versione 1.3 di Apache che la 2.0. Il Communication Server è scritto in Perl e viene eseguito come modulo per Apache. In questo modo lo script Perl viene compilato una sola volta all avvio del server Apache invece che per ogni singola richiesta. Questo permette di incrementarne le prestazioni. Il Communication Server può richiedere moduli Perl aggiuntivi a seconda della distribuzione utilizzata. Deployment Server: richiede un qualsiasi Web Server abilitato allo SSL. Administration console: è scritto in PHP 4.1 (o superiore) e viene eseguito da Apache 1.3 o 2.0 (potrebbe essere adattato anche ad altri web Server che

72 62 CAPITOLO 4. STATO DELL ARTE E TECNOLOGIE supportano PHP). La feature di Package Deployment richiede le funzionalità Zip e GD abilitate nell interprete PHP Windows agent: è scritto in C++. Per essere compilato richiede MS Visual C++ 6 Service Pack 5 (o superiore) e MS Platform SDK February 2003 (o superiore). Inoltre richiede gli script NSIS 11 oppure il GPO Automatic Deployment Tool per gli script di logon. Linux agent: è scritto in linguaggio Perl e C. A seconda della distribuzione Linux di partenza potrebbe richiedere alcuni moduli Perl addizionali per gestire XML e la compressione Zlib. Fa anche uso di dmidecode 12 L installazione OCS Inventory NG viene distribuito tramite il sito ufficiale sull hosting di Sourceforge: La distribuzione ufficale è disponibile sia per la piattaforma Linux che per quella Windows. Inoltre sono disponibili anche i software agent non ufficiali per le altre piattaforme. Per quanto concerne Linux, i pacchetti software della release 1.00 Final (rilasciata il 28 Gennaio 2007) sono distribuiti tramite due archivi TAR.GZ di cui uno contiene tutto il software per la parte server di OCS mentre l altro contiene il software per l agent. Infine nella repository Fedora Extras è presente un pacchetto rpm denominato ocsinventory-client che contiene l agente già compilato per le distribuzioni Linux RedHat e Fedora. L installazione del software sulle piattaforme Microsoft Windows non è di particolare interesse per questa tesi e quindi non viene trattato. 11 NSIS (NullSoft Scriptable Install System) è un sistema opensource che permette di creare degli installer per la piattaforma Windows. 12 dmidecode: è uno strumento opensource che prmette di estrarre dal BIOS informazioni sull hardware del sistema

73 4.3. OCS INVENTORY NG 63 Server Dopo aver scompattato l archivio TAR.GZ, l installazione del lato server di OCS procede con l esecuzione dello script setup.sh che provvede ad accertarsi che tutti i componenti software necessari siano presenti nelle versioni corrette. Requisiti Software: Apache o superiore oppure Apache 2.0.X o superiore Apache mod perl 1.29 o superiore MySql 4.1 o superiore con INNODB engine attivo PHP o superiore con con il supporto a ZIP, GD e MySql Apache mod php o superiore Perl 5.6 o superiore con i moduli: XML::Simple 2.12 o superiore Compress::Zlib 1.33 o superiore DBI 1.40 o superiore DBD::Mysql o superiore Apache::DBI 0.93 o superiore Net::IP 1.21 o superiore Soap::Lite 0.66 o superiore Make Utility (ad esempio GNU Make)

74 64 CAPITOLO 4. STATO DELL ARTE E TECNOLOGIE Lo script setup.sh provvede inoltre a scrivere i file di configurazione ricavando le informazioni dal sistema o richiedendone all utente. Informazioni necessarie alla Configurazione: Nome dell host su cui gira il database Mysql (generalmente localhost) Porta del server Mysql (generalmente 3306) Path dell eseguibile binario dell web server Apache (generalmente e un eseguibile di nome httpd o apache o apache2) Path della directory di configurazione di Apache (generalmente chiamata conf.d) Nome dell utente che esegue Apache (generalmente apache o www-data) Nome del gruppo utenti che esegue Apache (generalmente uguale al nome dell utente) Versione dell Apache mod perl Path della Document Root direcotry di Apache (generalmente /var/www/html o /var/www-data) Path sotto cui inserire il log dell OCS Communication Server (generalmente /var/log/ocs-inventory) L ultimo compito di cui si occupa lo script di installazione e quello di copiare tutti i file necessari al corretto utilizzo del sistema nelle apposite directory del filesystem. L utente-amminsitratore dovra quindi accedere all Administration Console appena installata sul Server Web all indirizzo e completare l installazione configurando correttamente l Administration console.

75 4.3. OCS INVENTORY NG 65 Descrizione dei file del Server di OCS: ocsinventory.conf: Questo file si trova nella directory di configurazione di Apache e serve per definire i moduli e le opzioni che il mod perl che verra caricato insieme al Web Server dovra includere per far funzionare correttamente OCS. Ocsinventory local.pl: Questo è uno script perl utilizzato per importare manualmente il file XML prodotto da un agente per il quale non è possibile procedere con l aggiornamento automatico. Questo file viene installato di default nella directory /usr/sbin. Apache/Ocsinventory.pm: È un modulo perl per Apache e si trova nella directory predefinita per i moduli perl. Il file contiene uno script per la gestione della routine principale del Communication Server. Questo modulo viene caricato dal web server all avvio insieme a tutti gli altri moduli del Communication Server che sono citati nelle direttive di inclusione di questo modulo. Gli altri moduli svolgono ognuno una funzione specifica: Apache/Ocsinventory/Interface.pm: fornisce delle funzioni di interfaccia per permettere agli sviluppatori di servizi esterni ad OCS di utilizzare i dati di inventario. Apache/Ocsinventory/Interface/Internals.pm: contiene subroutine interne utilizzate dal modulo Interface.pm Apache/Ocsinventory/Map.pm: fornisce la struttura dati per la gestione degli elementi di inventario Apache/Ocsinventory/SOAP.pm: abilita la comunicazione tramite protocollo SOAP (usata per i servizi esterni).

76 66 CAPITOLO 4. STATO DELL ARTE E TECNOLOGIE Apache/Ocsinventory/Server/Communication.pm: contiene le subroutine utilizzate per la comunicazione tra Agent e Communication Server. Apache/Ocsinventory/Server/Constants.pm: contiene la definizione di alcune costanti. Apache/Ocsinventory/Server/Duplicate.pm: contiene le subroutine per la gestione dei duplicati di inventario. Apache/Ocsinventory/Server/Inventory.pm: gestisce l inserimento dei dati di inventario nel DB. Apache/Ocsinventory/Server/Modperl1.pm: è il modulo che permette il caricamento del Communication Server sui server Apache versione 1.3 Apache/Ocsinventory/Server/Modperl2.pm: è il modulo che permette il caricamento del Communication Server sui server Apache versione 2 o superiore. Apache/Ocsinventory/Server/System.pm: contiene alcune subroutine di utilità per gli altri moduli. Apache/Ocsinventory/Server/Option/Download.pm: Plugin per la gestione della funzione Download del Package Deployment, implementazione lato server. Apache/Ocsinventory/Server/Option/Example.pm: Plugin di esempio per gli sviluppatori, lato server. Apache/Ocsinventory/Server/Option/Filter.pm: Plugin che implementa un semplice filtraggio delle richieste degli Agent

77 4.3. OCS INVENTORY NG 67 Apache/Ocsinventory/Server/Option/Ipdiscover.pm: Plugin per la gestione dell Ipdiscover, implementazione lato server. Apache/Ocsinventory/Server/Option/Registry.pm: Plugin per inventariare alcune informazioni provenienti dai registri di Windows, lato server. Apache/Ocsinventory/Server/Option/Update.pm: Plugin per la gestione dell Update degli Agent, implementazione lato server. ocsreports: Questa è una directory creata all interno della Document Root di Apache. Contiene tutti i file necessari all Administration Console sviluppata completamente in PHP. ocsinventory-ng.log: Questo è il file di log del Server di OCS e si trova nella direcotry di log specificata durante l installazione. Linux Agent L installazione dell Agent può avvenire con due metodi diversi. Tramite l archivio TAR.GZ e l esecuzione dello script setup.sh come per l installazione della parte Server oppure tramite pacchetto binario rpm per le distribuzioni che supportano questo genere di pacchetti software. Durante l installazione tramite setup.sh vengono verificate i requisiti software e vengono richiesti i riferimenti per il Communication Server. Con l installazione tramite rpm i requisiti vengono soddistatti in maniera automatica e installando tutte le dipendenze software che non siano già soddisfatte. L installazione tramite rpm però non configura alcun Communication Server e sarà compito dell utente-amministratore settare tale configurazione una volta terminata l installazione. Ove disponibile è consigliabile l installazione dell rpm poi-

78 68 CAPITOLO 4. STATO DELL ARTE E TECNOLOGIE chè permette di avere maggior controllo sul software installato durante la fase di manutenzione del software stesso. Requisiti Software: dmidecode 2.2 o superiore Perl 5.6 o superiore con i moduli: XML::Simple 2.12 o superiore Compress::Zlib 1.33 o superiore Net::IP 1.21 o superiore LWP::UserAgent version o superiore Digest::MD5 version 2.33 o superiore Net::SSLeay version 1.25 o superiore Make Utility (ad esempio GNU Make) C/C++ compiler (ad esempio GCC) Informazioni necessarie alla Configurazione: Nome dell host su cui gira il Communication Server Descrizione dei file dell Agent Linux: /etc/ocsinventory-client/ocsinv.conf: è il file di configurazione dell Agent /etc/ocsinventory-client/ocsinv.adm: è un file che contiene alcune informazioni per l amministrazione dell Agent

79 4.3. OCS INVENTORY NG 69 /usr/sbin/ocsinventory-client.pl: è lo script perl principale dell Agent. Eseguendo questo script viene generato l inventario aggiornato della macchina e inviato al Communication Server specificato nel file di configurazione. /usr/sbin/ipdiscover: è un eseguibile binario che si occupa di eseguire il discovery degli ip nella rete dell Agent. Viene richiamato dal Plugin di Ipdiscover. Ocsinventory/Agent.pm: è il modulo perl principale dell Agent. Viene installato nella directory di sistema per i moduli perl. Contiene i riferimenti ai Plugin Installati e il numero di versione. Ocsinventory/Agent/Common.pm: contiene alcune subroutine di utilità per gli altri moduli perl. Ocsinventory/Agent/Option/Download.pm: Plugin per la gestione della funzione Download del Package Deployment, implementazione lato client. Ocsinventory/Agent/Option/Ipdiscover.pm: Plugin per la gestione dell Ipdiscover, implementazione lato client. Ocsinventory/Agent/Option/Update.pm: Plugin per la gestione dell Update dell Agent, implementazione lato client. /var/log/ocsinventory-client/ocsinv.log: contiene il log generato dall Agent /etc/cron.daily/ocsinventory-client: contiene la chiamata allo script ocsinventory-client.pl che viene eseguita dal demone cron quotidianamente per tenere l inventario aggiornato.

80 70 CAPITOLO 4. STATO DELL ARTE E TECNOLOGIE Comunicazione Agent-Server È interessante vedere come si svolge la comunicazione tra Agent e Communication Server durante l aggiornamento dell inventario di una singola macchina. Al momento non è possibile impartire una richiesta di aggiornamento dal Communication Server all Agent e quindi l iniziativa per la comunicazione è tutta a carico dell Agent. Questo è in parte voluto per ridurre il traffico di rete e il carico di lavoro del Communication Server. L aggiornamento dell inventario può quindi iniziare in due soli modi: quello automatico, tramite cronjob quotidiano, o quello manuale, tramite esecuzione diretta avviata dall utente sulla macchina client. Comunque avvenga l inizializzazione, sia il cronjob che l utente eseguono lo script ocsinventory-client.pl. Questo script provvede alla comunicazione con il Communication Server e alla raccolta dell inventario aggiornato. La comunicazione inizia con una fase di PRO- LOG. In questa fase l Agent contatta il Communication Server per ottenere alcuni parametri utili per le funzioni che dovra svolgere. Infatti l Agent non conserva nessun informazione nè può contattare direttamente il database quindi deve necessariamente interrogare il Communication Server, unico suo riferimento esterno, per ottenere informazioni. In seguito alla fase di PROLOG l Agent ha tutto il necessario per cominciare a raccogliere i dati dell inventario. Esegue tutte le funzioni di inventario e scrive i risultati in formato XML quindi contatta nuovamente il Communication Server e gli invia l inventario. Una volta ricevuto l inventario, il Communication Server ne verifica la consistenza ed esegue un controllo per gestire i dati duplicati, quindi provvede ad inserire i dati nel database. L Agent può funzionare anche senza interfacciarsi direttamente con il Communication Server. Impostando la modalità local l Agent si occupa solo di generare l inventario e salvare i risultati in un file xml nella directory di log. Sarà quindi com-

81 4.3. OCS INVENTORY NG 71 pito dell utente importare tali risultati nel sistema tramite un apposita interfaccia dell Administration Console.

82 72 CAPITOLO 4. STATO DELL ARTE E TECNOLOGIE Figura 4.3: Schema del Database di OCS Inventory NG

Novell ZENworks Configuration Management in ambiente Microsoft * Windows *

Novell ZENworks Configuration Management in ambiente Microsoft * Windows * Guida GESTIONE SISTEMI www.novell.com Novell ZENworks Configuration Management in ambiente Microsoft * Windows * Novell ZENworks Configuration Management in ambiente Microsoft Windows Indice: 2..... Benvenuti

Dettagli

Il clustering. Sistemi Distribuiti 2002/2003

Il clustering. Sistemi Distribuiti 2002/2003 Il clustering Sistemi Distribuiti 2002/2003 Introduzione In termini generali, un cluster è un gruppo di sistemi indipendenti che funzionano come un sistema unico Un client interagisce con un cluster come

Dettagli

Reti di calcolatori. Condivisione di risorse e comunicazione con gli altri utenti

Reti di calcolatori. Condivisione di risorse e comunicazione con gli altri utenti Reti di calcolatori Condivisione di risorse e comunicazione con gli altri utenti Reti di calcolatori Anni 70: calcolatori di grandi dimensioni, modello time-sharing, centri di calcolo Anni 80: reti di

Dettagli

La classificazione delle reti

La classificazione delle reti La classificazione delle reti Introduzione Con il termine rete si intende un sistema che permette la condivisione di informazioni e risorse (sia hardware che software) tra diversi calcolatori. Il sistema

Dettagli

BEOWULF Cluester Linux/BSD

BEOWULF Cluester Linux/BSD BEOWULF Cluester Linux/BSD Nardo Guido 784169 Introduzione Negli anni passati, il mondo del Supercomputer inteso come clusters, è sempre stato dominato da architetture e software proprietario delle maggiori

Dettagli

A cura di: Dott. Ing. Elisabetta Visciotti. e.visciotti@gmail.com

A cura di: Dott. Ing. Elisabetta Visciotti. e.visciotti@gmail.com A cura di: Dott. Ing. Elisabetta Visciotti e.visciotti@gmail.com Il termine generico rete (network) definisce un insieme di entità (oggetti, persone, ecc.) interconnesse le une alle altre. Una rete permette

Dettagli

VIRTUALIZE IT. www.digibyte.it - digibyte@digibyte.it

VIRTUALIZE IT. www.digibyte.it - digibyte@digibyte.it il server? virtualizzalo!! Se ti stai domandando: ma cosa stanno dicendo? ancora non sai che la virtualizzazione è una tecnologia software, oggi ormai consolidata, che sta progressivamente modificando

Dettagli

Reti di computer- Internet- Web. Concetti principali sulle Reti Internet Il Web

Reti di computer- Internet- Web. Concetti principali sulle Reti Internet Il Web Reti di computer- Internet- Web Concetti principali sulle Reti Internet Il Web Condivisione di risorse e comunicazione con gli altri utenti n n n Anni 70: calcolatori di grandi dimensioni, modello timesharing,

Dettagli

Introduzione. File System Distribuiti. Nominazione e Trasparenza. Struttura dei DFS. Strutture di Nominazione

Introduzione. File System Distribuiti. Nominazione e Trasparenza. Struttura dei DFS. Strutture di Nominazione File System Distribuiti Introduzione Nominazione e Trasparenza Accesso ai File Remoti Servizio Con/Senza Informazione di Stato Replica dei File Un esempio di sistema Introduzione File System Distribuito

Dettagli

File System Distribuiti

File System Distribuiti File System Distribuiti Introduzione Nominazione e Trasparenza Accesso ai File Remoti Servizio Con/Senza Informazione di Stato Replica dei File Un esempio di sistema 20.1 Introduzione File System Distribuito

Dettagli

Il clustering HA con Linux: Kimberlite

Il clustering HA con Linux: Kimberlite Il clustering HA con Linux: Kimberlite Simone Piccardi: piccardi@firenze.linux.it February 4, 2002 Perché un cluster Un cluster è un insieme di computer in grado di eseguire insieme una certa serie di

Dettagli

Informatica Generale Andrea Corradini. 10 - Le reti di calcolatori e Internet

Informatica Generale Andrea Corradini. 10 - Le reti di calcolatori e Internet Informatica Generale Andrea Corradini 10 - Le reti di calcolatori e Internet Cos è una rete di calcolatori? Rete : È un insieme di calcolatori e dispositivi collegati fra loro in modo tale da permettere

Dettagli

D3.1 Documento di analisi della visualizzazione 3D in ambiente Cloud e relative problematiche

D3.1 Documento di analisi della visualizzazione 3D in ambiente Cloud e relative problematiche D3.1 Documento di analisi della visualizzazione 3D in ambiente Cloud e relative problematiche Il Cloud Computing La visualizzazione nella Cloud Problematiche Virtualizzazione della GPU Front end Virtualization

Dettagli

Linux nel calcolo distribuito

Linux nel calcolo distribuito openmosix Linux nel calcolo distribuito Dino Del Favero, Micky Del Favero dino@delfavero.it, micky@delfavero.it BLUG - Belluno Linux User Group Linux Day 2004 - Belluno 27 novembre openmosix p. 1 Cos è

Dettagli

Architetture dei WIS. Definizione di WIS. Benefici dei WIS. Prof.ssa E. Gentile a.a. 2011-2012

Architetture dei WIS. Definizione di WIS. Benefici dei WIS. Prof.ssa E. Gentile a.a. 2011-2012 Architetture dei WIS Prof.ssa E. Gentile a.a. 2011-2012 Definizione di WIS Un WIS può essere definito come un insieme di applicazioni in grado di reperire, cooperare e fornire informazioni utilizzando

Dettagli

Finalità delle Reti di calcolatori. Le Reti Informatiche. Una definizione di Rete di calcolatori. Schema di una Rete

Finalità delle Reti di calcolatori. Le Reti Informatiche. Una definizione di Rete di calcolatori. Schema di una Rete Finalità delle Reti di calcolatori Le Reti Informatiche Un calcolatore isolato, anche se multiutente ha a disposizione solo le risorse locali potrà elaborare unicamente i dati dei propri utenti 2 / 44

Dettagli

Calcolo numerico e programmazione. Sistemi operativi

Calcolo numerico e programmazione. Sistemi operativi Calcolo numerico e programmazione Sistemi operativi Tullio Facchinetti 25 maggio 2012 13:47 http://robot.unipv.it/toolleeo Sistemi operativi insieme di programmi che rendono

Dettagli

MCloud.Gov l infrastruttura SaaS per la Pubblica Amministrazione locale

MCloud.Gov l infrastruttura SaaS per la Pubblica Amministrazione locale MCloud.Gov l infrastruttura SaaS per la Pubblica Amministrazione locale 1. Livello infrastrutturale Il Cloud, inteso come un ampio insieme di risorse e servizi fruibili da Internet che possono essere dinamicamente

Dettagli

UBIQUITY 6 e Server. Il documento descrive le novità introdotte con la versione 6 della piattaforma software ASEM Ubiquity.

UBIQUITY 6 e Server. Il documento descrive le novità introdotte con la versione 6 della piattaforma software ASEM Ubiquity. UBIQUITY 6 e Server Privato Introduzione Il documento descrive le novità introdotte con la versione 6 della piattaforma software ASEM Ubiquity. Versione Descrizione Data 1 Prima emissione 21/06/2015 Disclaimer

Dettagli

Introduzione. è uguale a 0, spostamento di dati da una parte della memoria del calcolatore ad un altra.

Introduzione. è uguale a 0, spostamento di dati da una parte della memoria del calcolatore ad un altra. Appunti di Calcolatori Elettronici Modello di macchina multilivello Introduzione... 1 Linguaggi, livelli e macchine virtuali... 3 La struttura a livelli delle macchine odierne... 4 Evoluzione delle macchine

Dettagli

Progetto M.A.Y.H.E.M.

Progetto M.A.Y.H.E.M. Progetto M.A.Y.H.E.M. In informatica un computer cluster, o più semplicemente un cluster (dall'inglese 'grappolo'), è un insieme di computer connessi tra loro tramite una rete telematica. Lo scopo di un

Dettagli

TECNICO SUPERIORE PER LE APPLICAZIONI INFORMATICHE

TECNICO SUPERIORE PER LE APPLICAZIONI INFORMATICHE ISTRUZIONE E FORMAZIONE TECNICA SUPERIORE SETTORE I.C.T. Information and Communication Technology TECNICO SUPERIORE PER LE APPLICAZIONI INFORMATICHE STANDARD MINIMI DELLE COMPETENZE TECNICO PROFESSIONALI

Dettagli

ICT (Information and Communication Technology): ELEMENTI DI TECNOLOGIA

ICT (Information and Communication Technology): ELEMENTI DI TECNOLOGIA ICT (Information and Communication Technology): ELEMENTI DI TECNOLOGIA Obiettivo Richiamare quello che non si può non sapere Fare alcune precisazioni terminologiche IL COMPUTER La struttura, i componenti

Dettagli

SISTEMA DI PREFETCHING CLIENT-SIDE PER TRAFFICO WEB

SISTEMA DI PREFETCHING CLIENT-SIDE PER TRAFFICO WEB UNIVERSITÀ DEGLI STUDI DI ROMA TOR VERGATA Facoltà di Ingegneria Corso di Laurea Specialistica in Ingegneria Informatica Progetto per il corso di Ingegneria del Web SISTEMA DI PREFETCHING CLIENT-SIDE PER

Dettagli

Sistema Operativo Compilatore

Sistema Operativo Compilatore MASTER Information Technology Excellence Road (I.T.E.R.) Sistema Operativo Compilatore Maurizio Palesi Salvatore Serrano Master ITER Informatica di Base Maurizio Palesi, Salvatore Serrano 1 Il Sistema

Dettagli

Corso Configurazione e gestione dell Aula di Informatica (18 lezioni 54 ore)

Corso Configurazione e gestione dell Aula di Informatica (18 lezioni 54 ore) Corso Configurazione e gestione dell Aula di Informatica (18 lezioni 54 ore) 1. L hardware del PC (3 Lezioni - 9 ore) 2. Troubleshooting (1 Lezione - 3 ore) 3. Ambiente Operativo (5 Lezioni - 15 ore) 4.

Dettagli

Appunti di Sistemi Distribuiti

Appunti di Sistemi Distribuiti Appunti di Sistemi Distribuiti Matteo Gianello 27 settembre 2013 1 Indice 1 Introduzione 3 1.1 Definizione di sistema distribuito........................... 3 1.2 Obiettivi.........................................

Dettagli

Estratto dell'agenda dell'innovazione e del Trade Padova 2011. Speciale: I casi. Introduzione dell'area tematica IL CASO ARREDO3

Estratto dell'agenda dell'innovazione e del Trade Padova 2011. Speciale: I casi. Introduzione dell'area tematica IL CASO ARREDO3 Estratto dell'agenda dell'innovazione e del Trade Padova 2011 Speciale: I casi Introduzione dell'area tematica IL CASO ARREDO3 Innovare e competere con le ICT: casi di successo - PARTE II Cap.9 Far evolvere

Dettagli

IBM iseries Soluzioni integrate per xseries

IBM iseries Soluzioni integrate per xseries Soluzioni innovative per l integrazione dei server Intel IBM iseries Soluzioni integrate per xseries La famiglia iseries, il cui modello più recente è l _` i5, offre due soluzioni che forniscono alternative

Dettagli

D3.2 Documento illustrante l architettura 3D Cloud per la realizzazione di servizi in modalità SaaS

D3.2 Documento illustrante l architettura 3D Cloud per la realizzazione di servizi in modalità SaaS D3.2 Documento illustrante l architettura 3D Cloud per la realizzazione di servizi in modalità SaaS Il modello SaaS Architettura 3D Cloud Il protocollo DCV Benefici Il portale Web EnginFrame EnginFrame

Dettagli

UNIVERSITÀ DEGLI STUDI DI FIRENZE FACOLTÀ DI INGEGNERIA

UNIVERSITÀ DEGLI STUDI DI FIRENZE FACOLTÀ DI INGEGNERIA UNIVERSITÀ DEGLI STUDI DI FIRENZE FACOLTÀ DI INGEGNERIA Corso di Sistemi Operativi Prof. Stefano Berretti SEMINARIO: VIRTUALIZZAZIONE DI INFRASTRUTTURE INFORMATICHE a cura di: Nicola Fusari A.A. 2012/2013

Dettagli

L ottimizzazione dei processi con Microsoft Office System: come generare e misurare il valore per le aziende

L ottimizzazione dei processi con Microsoft Office System: come generare e misurare il valore per le aziende MICROSOFT BUSINESS DESKTOP MICROSOFT ENTERPRISE CLUB Disponibile anche sul sito: www.microsoft.com/italy/eclub/ L ottimizzazione dei processi con Microsoft Office System: come generare e misurare il valore

Dettagli

C) supponendo che la scuola voglia collegarsi in modo sicuro con una sede remota, valutare le possibili soluzioni (non risolto)

C) supponendo che la scuola voglia collegarsi in modo sicuro con una sede remota, valutare le possibili soluzioni (non risolto) PROGETTO DI UNA SEMPLICE RETE Testo In una scuola media si vuole realizzare un laboratorio informatico con 12 stazioni di lavoro. Per tale scopo si decide di creare un unica rete locale che colleghi fra

Dettagli

Corso Configurazione e gestione dell Aula di Informatica (18 lezioni 54 ore)

Corso Configurazione e gestione dell Aula di Informatica (18 lezioni 54 ore) Corso Configurazione e gestione dell Aula di Informatica (18 lezioni 54 ore) 1. L hardware del PC (3 Lezioni - 9 ore) 2. Troubleshooting (1 Lezione - 3 ore) 3. Ambiente Operativo (5 Lezioni - 15 ore) 4.

Dettagli

Estratto dell'agenda dell'innovazione e del Trade Bologna 2011. Speciale: I casi. Introduzione dell'area tematica IL CASO PRIMA INDUSTRIES

Estratto dell'agenda dell'innovazione e del Trade Bologna 2011. Speciale: I casi. Introduzione dell'area tematica IL CASO PRIMA INDUSTRIES Estratto dell'agenda dell'innovazione e del Trade Bologna 2011 Speciale: I casi Introduzione dell'area tematica IL CASO PRIMA INDUSTRIES Innovare e competere con le ICT: casi di successo - PARTE I Cap.8

Dettagli

Descrizione della piattaforma software MPS Monitor

Descrizione della piattaforma software MPS Monitor Descrizione della piattaforma software MPS Monitor MPS Monitor è il più completo sistema di monitoraggio remoto e di gestione integrata ed automatizzata dei dati e degli allarmi relativi ai dispositivi

Dettagli

Processi di Business e Sistemi di Gestione di Workflow: concetti di base. Prof. Giancarlo Fortino g.fortino@unical.it

Processi di Business e Sistemi di Gestione di Workflow: concetti di base. Prof. Giancarlo Fortino g.fortino@unical.it Processi di Business e Sistemi di Gestione di Workflow: concetti di base Prof. Giancarlo Fortino g.fortino@unical.it Introduzione Le aziende devono modificare la loro organizzazione per cogliere le nuove

Dettagli

CLOUD COMPUTING. Che cos è il Cloud

CLOUD COMPUTING. Che cos è il Cloud CLOUD COMPUTING Che cos è il Cloud Durante la rivoluzione industriale, le imprese che si affacciavano per la prima volta alla produzione dovevano costruirsi in casa l energia che, generata da grandi macchine

Dettagli

Il sistema operativo TinyOS

Il sistema operativo TinyOS tesi di laurea Anno Accademico 2005/2006 relatore Ch.mo prof. Domenico Cotroneo candidato Giovanni Chierchia Matr. 534 / 804 ::. Obiettivi del lavoro di tesi Studio del sistema operativo TinyOS Studio

Dettagli

LE 10 TECNOLOGIE STRATEGICHE PER IL 2008

LE 10 TECNOLOGIE STRATEGICHE PER IL 2008 http://www.sinedi.com ARTICOLO 18 DICEMBRE 2007 LE 10 TECNOLOGIE STRATEGICHE PER IL 2008 Come ogni anno, Gartner, la società americana di ricerche e d informazione sulle tecnologie, ha identificato dieci

Dettagli

KeyPA Print Agent. Informazioni di Funzionamento. Versione Manuale 1.0. Viale S. Franscini, 17. 6900 Lugano (CH) Tel. +41 (0)91 911 85 05

KeyPA Print Agent. Informazioni di Funzionamento. Versione Manuale 1.0. Viale S. Franscini, 17. 6900 Lugano (CH) Tel. +41 (0)91 911 85 05 KeyPA Print Agent Informazioni di Funzionamento Versione Manuale 1.0 Versione PrintAgent 2.4.2 e successive Viale S. Franscini, 17 6900 Lugano (CH) Tel. +41 (0)91 911 85 05 Fax. +41 (0)91 921 05 39 Indice

Dettagli

Sistemi informatici in ambito radiologico

Sistemi informatici in ambito radiologico Sistemi informatici in ambito radiologico Dott. Ing. Andrea Badaloni A.A. 2015 2016 Reti di elaboratori, il modello a strati e i protocolli di comunicazione e di servizio Reti di elaboratori Definizioni

Dettagli

Famed was this Beowulf: far flew the

Famed was this Beowulf: far flew the Beowulf: ll principe dei cluster LINUX Con questo articolo introduciamo beowulf, un progetto che, in ambito Linux, per molto tempo è stato sinonimo di cluster. Famed was this Beowulf: far flew the boast

Dettagli

L Informatica al Vostro Servizio

L Informatica al Vostro Servizio L Informatica al Vostro Servizio Faticoni S.p.A. è Certificata UNI ENI ISO 9001:2008 N. CERT-02228-97-AQ-MILSINCERT per Progettazione, Realizzazione, Manutenzione di soluzioni Hardware e Software Soluzioni

Dettagli

Alessandro Bottaioli Responsabile Tecnico Progetti InFarma. Pieralberto Nati Responsabile progetto FrontEnd Studiofarma

Alessandro Bottaioli Responsabile Tecnico Progetti InFarma. Pieralberto Nati Responsabile progetto FrontEnd Studiofarma Alessandro Bottaioli Responsabile Tecnico Progetti InFarma Pieralberto Nati Responsabile progetto FrontEnd Studiofarma COME SIAMO ARRIVATI QUI C era una volta la signorina che rispondeva al telefono finalmente

Dettagli

Realizzazione di un cluster Condor su macchine virtuali

Realizzazione di un cluster Condor su macchine virtuali Realizzazione di un cluster Condor su macchine virtuali Davide Petturiti Sistemi Operativi Avanzati Prof. Osvaldo Gervasi A.A. 2007/2008 Corso di Laurea Specialistica in Informatica Facoltà di Scienze

Dettagli

Reti di calcolatori. Permettono la condivisione di risorse (hardware e software) e la comunicazione con gli altri utenti. Reti di calcolatori

Reti di calcolatori. Permettono la condivisione di risorse (hardware e software) e la comunicazione con gli altri utenti. Reti di calcolatori Reti di calcolatori Permettono la condivisione di risorse (hardware e software) e la comunicazione con gli altri utenti Reti di calcolatori Anni 70: calcolatori di grandi dimensioni, modello time-sharing,

Dettagli

Capitolo 3: Strutture dei sistemi operativi

Capitolo 3: Strutture dei sistemi operativi Capitolo 3: Strutture dei sistemi operativi Componenti del sistema Servizi di un sistema operativo Chiamate del sistema Programmi di sistema Struttura del sistema Macchine virtuali Progettazione e realizzazione

Dettagli

Progetto Vserver- HighAvailability

Progetto Vserver- HighAvailability Progetto Vserver- HighAvailability 16.12.2003 Alberto Cammozzo - Dipartimento di Scienze Statistiche - Università di Padova mmzz@stat.unipd.it Nell'ambito dell'aggiornamento dei servizi in corso si propone

Dettagli

Come Funziona. Virtualizzare con VMware

Come Funziona. Virtualizzare con VMware Virtualize IT Il Server? Virtualizzalo!! Se ti stai domandando: ma cosa stanno dicendo? ancora non sai che la virtualizzazione è una tecnologia software, oggi ormai consolidata, che sta progressivamente

Dettagli

Sistemi Informativi Distribuiti

Sistemi Informativi Distribuiti Corso di Laurea Magistrale in Ingegneria Gestionale Corso di Sistemi Informativi Modulo II A. A. 2013-2014 SISTEMI INFORMATIVI MODULO II Sistemi Informativi Distribuiti 1 Sistemi informativi distribuiti

Dettagli

Valutazione del sistema di storage EMC CLARiiON AX4

Valutazione del sistema di storage EMC CLARiiON AX4 Valutazione del sistema di storage EMC CLARiiON AX4 Relazione preparata sotto contratto con EMC Introduzione EMC Corporation ha incaricato Demartek di eseguire una valutazione pratica del nuovo sistema

Dettagli

Considera tutti i requisiti funzionali (use cases) NON deve necessariamente modellare i requisiti non funzionali

Considera tutti i requisiti funzionali (use cases) NON deve necessariamente modellare i requisiti non funzionali Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Progettazione OO E. TINELLI Punto di Partenza Il modello di analisi E una rappresentazione minima del

Dettagli

Sistemi avanzati di gestione dei Sistemi Informativi

Sistemi avanzati di gestione dei Sistemi Informativi Esperti nella gestione dei sistemi informativi e tecnologie informatiche Sistemi avanzati di gestione dei Sistemi Informativi Docente: Email: Sito: eduard@roccatello.it http://www.roccatello.it/teaching/gsi/

Dettagli

1.3 Concetti base dell Informatica: Elaboratore

1.3 Concetti base dell Informatica: Elaboratore 1.3 Concetti base dell Informatica: Elaboratore Insegnamento di Informatica Elisabetta Ronchieri Corso di Laurea di Economia, Universitá di Ferrara I semestre, anno 2014-2015 Elisabetta Ronchieri (Universitá)

Dettagli

CAPITOLO 5 - Sistemi Operativi Moderni

CAPITOLO 5 - Sistemi Operativi Moderni CAPITOLO 5 - Sistemi Operativi Moderni PRESENTAZIONE DI INSIEME Vedremo ora come si è evoluta nel tempo la struttura di un sistema operativo, per passare dalle vecchie strutture di tipo normalmente modulari,

Dettagli

NetCrunch 6. Server per il controllo della rete aziendale. Controlla

NetCrunch 6. Server per il controllo della rete aziendale. Controlla AdRem NetCrunch 6 Server per il controllo della rete aziendale Con NetCrunch puoi tenere sotto controllo ogni applicazione, servizio, server e apparato critico della tua azienda. Documenta Esplora la topologia

Dettagli

Davide Cesari Massimo Bider Paolo Patruno. Emilia Romagna

Davide Cesari Massimo Bider Paolo Patruno. Emilia Romagna 1 IMPLEMENTAZIONE OPERATIVA DI UN MODELLO DI PREVISIONI METEOROLOGICHE SU UN SISTEMA DI CALCOLO PARALLELO LINUX/GNU Davide Cesari Massimo Bider Paolo Patruno Emilia Romagna LM-COSMO-LAMI 2 Il modello LM

Dettagli

Approfondimenti tecnici su framework v6.3

Approfondimenti tecnici su framework v6.3 Sito http://www.icu.fitb.eu/ pagina 1 I.C.U. "I See You" Sito...1 Cosa è...3 Cosa fa...3 Alcune funzionalità Base:...3 Alcune funzionalità Avanzate:...3 Personalizzazioni...3 Elenco Moduli base...4 Elenco

Dettagli

Zoo di sistemi operativi: studio e realizzazione del supporto di macchine virtuali con accesso via Web

Zoo di sistemi operativi: studio e realizzazione del supporto di macchine virtuali con accesso via Web Zoo di sistemi operativi: studio e realizzazione del supporto di macchine virtuali con accesso via Web Mattia Gentilini Relatore: Renzo Davoli Laurea Specialistica in Informatica I Sessione A.A. 2005/2006

Dettagli

Estratto dell'agenda dell'innovazione e del Trade Bari 2011. Speciale: I casi. Introduzione dell'area tematica IL CASO BOOKINGSHOW

Estratto dell'agenda dell'innovazione e del Trade Bari 2011. Speciale: I casi. Introduzione dell'area tematica IL CASO BOOKINGSHOW Estratto dell'agenda dell'innovazione e del Trade Bari 2011 Speciale: I casi Introduzione dell'area tematica IL CASO BOOKINGSHOW Innovare e competere con le ICT: casi di successo - PARTE II Cap.9 Far evolvere

Dettagli

Approccio stratificato

Approccio stratificato Approccio stratificato Il sistema operativo è suddiviso in strati (livelli), ciascuno costruito sopra quelli inferiori. Il livello più basso (strato 0) è l hardware, il più alto (strato N) è l interfaccia

Dettagli

Il DNS e la gestione degli indirizzi IP. Appunti a cura del prof. ing. Mario Catalano

Il DNS e la gestione degli indirizzi IP. Appunti a cura del prof. ing. Mario Catalano Il DNS e la gestione degli indirizzi IP Appunti a cura del prof. ing. Mario Catalano Indirizzi fisici e indirizzi astratti Ogni macchina all interno di una rete è identificata da un indirizzo hardware

Dettagli

10 argomenti a favore dell over IP

10 argomenti a favore dell over IP Quello che i fornitori di telecamere analogiche non dicono 10 argomenti a favore dell over IP Le telecamere di rete non sono certo una novità, infatti il primo modello è stato lanciato nel 1996. Nei primi

Dettagli

Il File System. È la componente del S.O. che si occupa della gestione della memoria di massa e dell organizzazione logica dei dati

Il File System. È la componente del S.O. che si occupa della gestione della memoria di massa e dell organizzazione logica dei dati Il File System È la componente del S.O. che si occupa della gestione della memoria di massa e dell organizzazione logica dei dati Le operazioni supportate da un file system sono: eliminazione di dati modifica

Dettagli

Manuale Servizi di Virtualizzazione e Porta di Accesso Virtualizzata

Manuale Servizi di Virtualizzazione e Porta di Accesso Virtualizzata Manuale Servizi di Virtualizzazione e Porta di Accesso Virtualizzata COD. PROD. D.6.3 1 Indice Considerazioni sulla virtualizzazione... 3 Vantaggi della virtualizzazione:... 3 Piattaforma di virtualizzazione...

Dettagli

Il software: natura e qualità

Il software: natura e qualità Sommario Il software: natura e qualità Leggere Cap. 2 Ghezzi et al. Natura e peculiarità del software Classificazione delle qualità del software Qualità del prodotto e del processo Qualità interne ed esterne

Dettagli

PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO 147 6/001.0

PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO 147 6/001.0 PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO 147 6/001.0 PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO ELEMENTI FONDAMENTALI PER LO SVILUPPO DI SISTEMI INFORMATIVI ELABORAZIONE DI

Dettagli

VDI IN A BOX. www.lansolution.it - info@lansolution.it - 051 5947388

VDI IN A BOX. www.lansolution.it - info@lansolution.it - 051 5947388 VDI IN A BOX Con le soluzioni Citrix e la professionalità di Lansolution, ora puoi: -Ridurre i costi -Garantire la sicurezza -Incrementare la produttività -Lavorare ovunque* La flessibilità del luogo di

Dettagli

LABORATORIO DI TELEMATICA

LABORATORIO DI TELEMATICA LABORATORIO DI TELEMATICA COGNOME: Ronchi NOME: Valerio NUMERO MATRICOLA: 41210 CORSO DI LAUREA: Ingegneria Informatica TEMA: Analisi del protocollo FTP File Transfer Protocol File Transfer Protocol (FTP)

Dettagli

Introduzione alle tecnologie informatiche. Strumenti mentali per il futuro

Introduzione alle tecnologie informatiche. Strumenti mentali per il futuro Introduzione alle tecnologie informatiche Strumenti mentali per il futuro Panoramica Affronteremo i seguenti argomenti. I vari tipi di computer e il loro uso Il funzionamento dei computer Il futuro delle

Dettagli

Virtualizzazione. Orazio Battaglia

Virtualizzazione. Orazio Battaglia Virtualizzazione Orazio Battaglia Definizione di virtualizzazione In informatica il termine virtualizzazione si riferisce alla possibilità di astrarre le componenti hardware, cioè fisiche, degli elaboratori

Dettagli

Le reti di calcolatori

Le reti di calcolatori Le reti di calcolatori 1 La storia Computer grandi e costosi Gli utenti potevano accerdervi tramite telescriventi per i telex o i telegrammi usando le normali linee telefoniche Successivamente le macchine

Dettagli

IBM i5/os: un sistema progettato per essere sicuro e flessibile

IBM i5/os: un sistema progettato per essere sicuro e flessibile IBM i5/os garantisce la continua operatività della vostra azienda IBM i5/os: un sistema progettato per essere sicuro e flessibile Caratteristiche principali Introduzione del software HASM (High Availability

Dettagli

INTRODUZIONE A RETI E PROTOCOLLI

INTRODUZIONE A RETI E PROTOCOLLI PARTE 1 INTRODUZIONE A RETI E PROTOCOLLI Parte 1 Modulo 1: Introduzione alle reti Perché le reti tra computer? Collegamenti remoti a mainframe (< anni 70) Informatica distribuita vs informatica monolitica

Dettagli

SISTEMI OPERATIVI DISTRIBUITI

SISTEMI OPERATIVI DISTRIBUITI SISTEMI OPERATIVI DISTRIBUITI E FILE SYSTEM DISTRIBUITI 12.1 Sistemi Distribuiti Sistemi operativi di rete Sistemi operativi distribuiti Robustezza File system distribuiti Naming e Trasparenza Caching

Dettagli

INTERNET INTRANET EXTRANET

INTERNET INTRANET EXTRANET LEZIONE DEL 17/10/08 Prof.ssa Antonella LONGO In un sistema WEB possono esserci tre configurazioni possibili: internet, intranet ed extranet. La differenza viene fatta dalla presenza o meno di firewall

Dettagli

Openmosix e Beowulf: introduzione e confronto

Openmosix e Beowulf: introduzione e confronto Openmosix e Beowulf: introduzione e confronto Giovanni Perbellini Cluster Introduzione Cluster ESD Openmosix Comandi principali Beowulf (PVM) Comandi principali Libreria PVM API Agenda 1 Introduzione -

Dettagli

I benefici di una infrastruttura IT sicura e ben gestita: come fare di più con meno

I benefici di una infrastruttura IT sicura e ben gestita: come fare di più con meno I benefici di una infrastruttura IT sicura e ben gestita: come fare di più con meno I benefici di una infrastruttura IT sicura e ben gestita: come fare di più con meno In questi ultimi anni gli investimenti

Dettagli

Kaseya. Perché ogni azienda dovrebbe automatizzare la gestione dei sistemi IT

Kaseya. Perché ogni azienda dovrebbe automatizzare la gestione dei sistemi IT Kaseya è il software per la gestione integrata delle reti informatiche Kaseya controlla pochi o migliaia di computer con un comune browser web! Kaseya Perché ogni azienda dovrebbe automatizzare la gestione

Dettagli

Descrizione generale del sistema SGRI

Descrizione generale del sistema SGRI NEATEC S.P.A. Il sistema è un sito WEB intranet realizzato per rappresentare logicamente e fisicamente, in forma grafica e testuale, le informazioni e le infrastrutture attive e passive che compongono

Dettagli

La Videosorveglianza e la Salvaguardia degli ambienti

La Videosorveglianza e la Salvaguardia degli ambienti La Videosorveglianza e la Salvaguardia degli ambienti 2015 Un sistema di sicurezza evoluto 01 LA VIDEOSORVEGLIANZA 02 A COSA SERVE? 03 PERCHE GLOBAL SISTEMI La videosorveglianza è un evoluto sistema di

Dettagli

IBM Tivoli Endpoint Manager for Lifecycle Management

IBM Tivoli Endpoint Manager for Lifecycle Management IBM Endpoint Manager for Lifecycle Management Un approccio basato sull utilizzo di un singolo agente software e un unica console per la gestione degli endpoint all interno dell intera organizzazione aziendale

Dettagli

Corso Creare una rete locale Lezione n. 1

Corso Creare una rete locale Lezione n. 1 Introduzione al Networking Introduzione Al giorno d oggi il Networking non è più un sistema riservato solo alle aziende di enormi dimensioni, ma interessa anche i piccoli uffici, le scuole e le case. Infatti

Dettagli

USO OTTIMALE DI ACTIVE DIRECTORY DI WINDOWS 2000

USO OTTIMALE DI ACTIVE DIRECTORY DI WINDOWS 2000 VERITAS StorageCentral 1 USO OTTIMALE DI ACTIVE DIRECTORY DI WINDOWS 2000 1. Panoramica di StorageCentral...3 2. StorageCentral riduce il costo totale di proprietà per lo storage di Windows...3 3. Panoramica

Dettagli

Corso di Informatica

Corso di Informatica Corso di Informatica Modulo T2 A2 Introduzione ai database 1 Prerequisiti Concetto di sistema File system Archivi File e record 2 1 Introduzione Nella gestione di una attività, ad esempio un azienda, la

Dettagli

Sicurezza dei sistemi SIP: analisi sperimentale di possibili attacchi e contromisure

Sicurezza dei sistemi SIP: analisi sperimentale di possibili attacchi e contromisure UNIVERSITÀ DEGLI STUDI DI PISA FACOLTÀ DI INGEGNERIA Corso di Laurea in INGEGNERIA DELLE TELECOMUNICAZIONI Tesi di Laurea Sicurezza dei sistemi SIP: analisi sperimentale di possibili attacchi e contromisure

Dettagli

Informatica per la comunicazione" - lezione 8 -

Informatica per la comunicazione - lezione 8 - Informatica per la comunicazione - lezione 8 - Esercizio Convertire i seguenti numeri da base 10 a base 2: 8, 23, 144, 201. Come procedere per risolvere il problema? Bisogna ricordarsi che ogni sistema,

Dettagli

TECNICO SUPERIORE PER I SISTEMI E LE TECNOLOGIE INFORMATICHE

TECNICO SUPERIORE PER I SISTEMI E LE TECNOLOGIE INFORMATICHE ISTRUZIONE E FORMAZIONE TECNICA SUPERIORE SETTORE I.C.T. Information and Communication Technology TECNICO SUPERIORE PER I SISTEMI E LE TECNOLOGIE INFORMATICHE STANDARD MINIMI DELLE COMPETENZE TECNICO PROFESSIONALI

Dettagli

Descrizione della piattaforma software MPS Monitor

Descrizione della piattaforma software MPS Monitor Descrizione della piattaforma software MPS Monitor MPS Monitor è il più completo sistema di monitoraggio remoto e di gestione integrata ed automatizzata dei dati e degli allarmi relativi ai dispositivi

Dettagli

MAGO CRESCO - SPI.2. Relazione finale sul Progetto MAGO. Consorzio Campano di Ricerca per l Informatica e l Automazione Industriale S.c.a.r.l.

MAGO CRESCO - SPI.2. Relazione finale sul Progetto MAGO. Consorzio Campano di Ricerca per l Informatica e l Automazione Industriale S.c.a.r.l. CRESCO - SPI.2 MAGO Relazione finale sul Progetto MAGO Relativo al contratto tra ENEA e CRIAI avente per oggetto: Analisi e Realizzazione di tool innovativi a supporto delle funzionalità GRID stipulato

Dettagli

LE POSSIBILITA' DI ACCESSO DA REMOTO ALLE RETI DI CALCOLATORI

LE POSSIBILITA' DI ACCESSO DA REMOTO ALLE RETI DI CALCOLATORI VPN: VNC Virtual Network Computing VPN: RETI PRIVATE VIRTUALI LE POSSIBILITA' DI ACCESSO DA REMOTO ALLE RETI DI CALCOLATORI 14 marzo 2006 Fondazione Ordine degli Ingegneri di Milano Corso Venezia Relatore

Dettagli

Backup e ripristino per ambienti VMware con Avamar 6.0

Backup e ripristino per ambienti VMware con Avamar 6.0 White paper Backup e ripristino per ambienti VMware con Avamar 6.0 Analisi dettagliata Abstract Con l aumento incalzante degli ambienti virtuali implementati nel cloud delle aziende, è facile notare come

Dettagli

Progetto di Applicazioni Software

Progetto di Applicazioni Software Progetto di Applicazioni Software Antonella Poggi Dipartimento di Informatica e Sistemistica Antonio Ruberti SAPIENZA Università di Roma Anno Accademico 2008/2009 Questi lucidi sono stati prodotti sulla

Dettagli

Sistemi Informativi e WWW

Sistemi Informativi e WWW Premesse Sistemi Informativi e WWW WWW: introduce un nuovo paradigma di diffusione (per i fornitori) e acquisizione (per gli utilizzatori) delle informazioni, con facilità d uso, flessibilità ed economicità

Dettagli

Laboratorio di Informatica. Le reti telematiche e Internet

Laboratorio di Informatica. Le reti telematiche e Internet Le reti telematiche e Internet Lezione 6 1 Insieme di cavi, protocolli, apparati di rete che collegano tra loro computer distinti i cavi trasportano fisicamente le informazioni opportunamente codificate

Dettagli

Corso di Alfabetizzazione Informatica

Corso di Alfabetizzazione Informatica Corso di Alfabetizzazione Informatica Lezione 6 a.a. 2010/2011 Francesco Fontanella La Complessità del Hardware Il modello di Von Neumann è uno schema di principio. Attualmente in commercio esistono: diversi

Dettagli

ARCHITETTURE DEI SISTEMI DI ELABORAZIONE

ARCHITETTURE DEI SISTEMI DI ELABORAZIONE ARCHITETTURE DEI SISTEMI DI ELABORAZIONE 1 SISTEMI ACCENTRATI CARATTERISTICHE Sistemi proprietari Monocultura Scarsa diffusione informatica Backlog 2 Soluzione centralizzata TERMINALE TERMINALE ELABORATORE

Dettagli