1. ABSTRACT 2. INTRODUZIONE PROGETTO DI UN INFRASTRUTTURA GERARCHICA PER SERVIZI DI FILE HOSTING

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "1. ABSTRACT 2. INTRODUZIONE PROGETTO DI UN INFRASTRUTTURA GERARCHICA PER SERVIZI DI FILE HOSTING"

Transcript

1 PROGETTO DI UN INFRASTRUTTURA GERARCHICA PER SERVIZI DI FILE HOSTING 1. ABSTRACT Al giorno d oggi, l enorme diffusione di contenuti multimediali quali, ad esempio, video ad alta definizione piuttosto che musica o foto digitali, ha causato un notevole aumento della capacità di memorizzazione richiesta da ogni utente. Disporre di dispositivi di archiviazione sempre più grandi non è più la scelta ottimale sia dal punto di vista economico che, soprattutto, considerando come i nuovi scenari dell IT moderno spingono verso una sempre maggior mobilità di dati e utenti che hanno una variegata quantità di dispositivi diversi: da classici PC fino a computer palmari, passando per telefoni cellulari e computer portatili. Emerge quindi un problema cruciale presente in tali scenari: la portabilità dei dati. Ogni utente, infatti, desidera poter avere i propri file indipendentemente dalla sua locazione fisica o dal dispositivo che utilizza in ogni istante. Per risolvere questo problema è necessario avere un deposito remoto dove immagazzinare i propri dati e un sistema che consenta di renderli fruibili ovunque nell intero globo. In questo scenario nascono i servizi di file hosting, che consentono agli utenti di memorizzare dati personali su server remoti, non occupando le proprie risorse locali e potendo disporre dei file da qualsiasi postazione connessa alla rete Internet, che allo stato attuale consente una copertura pressoché capillare del globo, grazie anche alle recenti introduzioni di tecnologie radio wireless come il Wi-Fi o, migliore, il Wi-Max. È evidente che con questa soluzione siamo in grado di risolvere i problemi citati in precedenza, ma non solo. Ci si rende subito conto della possibilità di instaurare una forma di condivisione dei dati. Infatti, in base alla politica adottata dal servizio, potranno esserci file pubblici, accessibili a tutti gli utenti, piuttosto che file privati. Esiste però anche un rovescio della medaglia. Pensare di realizzare un tale servizio di file hosting a larga scala, pone seri problemi riguardo alla capacità di memoria richiesta, la congestione indotta nella rete di supporto ed anche riguardo alla sicurezza dei dati nelle loro varie fasi di vita: dal trasporto via rete al server di file hosting fino alla memorizzazione nel file system di quest ultimo. E necessario anche predisporre un opportuno meccanismo di autenticazione e autorizzazione dei diversi utenti per garantire un adeguata privacy. Gli aspetti fondamentali che determinano la QoS percepita dagli utenti in questi servizi, sono senza dubbio la disponibilità e la correttezza dei dati, nonché la velocità di risposta da parte del server. Il presente lavoro s inquadra proprio in questo scenario e mira a realizzare un infrastruttura client/server che consenta di fruire di un servizio di file hosting affidabile, disponibile e scalabile, garantendo agli utenti la maggior QoS percepita possibile in base alle risorse disponibili nell architettura server. 2. INTRODUZIONE Questo lavoro presenta un infrastruttura client/server che implementa un servizio di file hosting. Nella realizzazione sono stati particolarmente curati gli aspetti di disponibilità, affidabilità e scalabilità del servizio, presentando una soluzione server basata su un cluster in grado di garantire sia le proprietà sopra enunciate, che di bilanciare il carico di lavoro tra i diversi nodi del cluster stesso. È stato inoltre realizzato un middleware di supporto in grado di integrare, in maniera 1

2 trasparente, qualsiasi client con l architettura server progettata, fornendo una interfaccia che espone tutti le api base per accedere a tutti i servizi offerti. 3. ARCHITETTURA L infrastruttura progettata è basata su un paradigma client/server, in cui il server è gestito mediante una struttura a livelli, modellando l intera architettura server come un highavailability cluster. La figura seguente rappresenta la struttura proposta: M I D D L E W A R E Manager Server Data Server Si vengono così a individuare tre tipologie diversi di attori (manager server, data server, client) organizzati in una struttura gerarchica. Il cliente vede in modo trasparente solo un manager, ed esegue su di esso tutte le operazioni che desidera, senza accorgersi della presenza dei data server e/o degli altri manager server: questo grazie all uso di un middleware, che nasconde tutti i dettagli della struttura e della comunicazione. Fondamentalmente la struttura del sistema presenta due layer: Manager server: uno o più server di gestione dove i clienti si collegano e richiedono le operazioni sul file system (aggiunta file, rimozione file, lista file, ecc ). Data server: uno o più server dove risiedono i veri e propri file depositati dai clienti. Il cliente, per accedere al file di hosting, richiede i servizi utilizzando il middleware di supporto, che invierà la richiesta ad un manager (locazione presente nel file di configurazione del middleware e scelto in base a politiche implementate all interno del middleware stesso) che a sua volta la ridirigerà sull opportuno data server, applicando le politiche di bilanciamento di risorse e di carico, implementate all interno del manager. Nella memoria del manager deve quindi essere presente una struttura dati che definisca logicamente l intero file system, mentre i file sono fisicamente memorizzati nei diversi data server partecipanti. Ciò permette al manager da un lato di servire velocemente richieste da parte dei client delegandole ai data server che presentano una situazione di carico migliore e dall altro lato di mantenere un controllo centralizzato sui diversi data server per gestire al meglio le capacità di replicazione e faulttolerance, nonché di garantire un elevata scalabilità del servizio. Da notare che l overhead di comunicazione dovuto alla gestione e coordinamento tra data server e manager server è limitato alla sola isola di gestione di ciascun manager (ricordiamo che ciascun data server, in ogni istante, è registrato presso un solo manager server) e sarà quest ultimo che, con un servizio di background, aggiornerà gli altri manager sullo stato di operatività e carico dei data server registrati presso di lui, minimizzando così il numero di pacchetti scambiati (vedi capitolo 10) e quindi l overhead di comunicazione dovuto alla gestione dell infrastruttura. In linea teorica il sistema può operare correttamente se sono presenti un client, un manager e un data server. Questa è una configurazione minima che ovviamente non consente alcun tipo di ottimizzazione e che in 2

3 sostanza non garantisce nessuna delle proprietà che sono obiettivo di progetto. E quindi con l aggiunta di più data server e manager server che si ottengono i benefici desiderati da un sistema di tale genere: infatti, grazie agli algoritmi di ottimizzazione implementati dai manager, si possono ottenere affidabilità, disponibilità e scalabilità del servizio. Il prossimo capitolo è dedicato alla presentazione di tali algoritmi e delle annesse scelte di progetto. Passiamo ora a una rapida descrizione delle scelte tecnologiche effettuate. L intero progetto è stato scritto sfruttando il linguaggio Java, con l obiettivo di beneficiare dell ormai nota portabilità inter-piattaforma propria di questo linguaggio. Per quanto riguarda le comunicazioni attraverso la rete si è preferito utilizzare delle socket TCP che, a fronte di un maggiore overhead di trasmissione, garantiscono l affidabilità necessaria al servizio (garanzia di consegna dei messaggi e conservazione dell ordine d invio): questo non è un vincolo stretto di progetto, poiché, grazie all utilizzo del provider model, è possibile in modo molto semplice integrare diversi tipi di connettività semplicemente cambiando il file di configurazione. E stato implementato, per ora, un servizio di file hosting mono-utente, dove i file depositati sono pubblici e chiunque può vederli o aggiungerne degli altri, senza nessun meccanismo di autenticazione o autorizzazione. Le operazioni possibili per i client sono quelle di upload e di download di file e listare i file contenuti correntemente nel sistema, mentre l amministratore, tramite l interfaccia grafica, può decidere a run-time di registrare il manager server (o il data server) sul sistema per iniziare a servire le richieste dei clienti, o deregistrarsi dal sistema per eseguire ad esempio delle operazioni di manutenzione offline sul server. Interessante è notare che alla chiusura del manager non è terminato solo lui, ma a cascata, sono chiusi anche tutti i data server che erano registrati presso lui. Illustriamo ora le principali caratteristiche del manager e del data server, rimandando al capitolo 9 quelle riguardanti il client e il rispettivo middleware. 3.1 MANAGER SERVER Il manager rappresenta il fulcro dell architettura, poiché ha il duplice ruolo di coordinare i vari data server e di servire o ridirigere le richieste provenienti dai client, nonché di sincronizzarsi con gli altri manager per mantenere una copia del File System logico globale, e riconfigurare l anello logico presente fra i vari manager server nel caso avvengano delle variazioni (aggiunta/rimozione di nuovi manager). Per questo motivo, esso è realizzato come un applicazione multi-threaded: una server socket TCP riceve, infatti, le richieste dai client attivando un thread specifico per ogni operazione; una server socket TCP per accettare i nuovi data server che vogliono registrarsi al sistema; e una server socket TCP per registrare i nuovi manager server (da notare che i manager che vogliono registrarsi al cluster devono farne richiesta presso un qualsiasi dei manager già attivo nel sistema). Per mantenere un alta disponibilità del servizio, all interno del sistema sono presenti più manager server organizzati in una struttura ad anello logico, il cui numero può essere variato in modo dinamico senza interruzioni di servizio. Ogni manager ha una connessione permanente verso un manager successivo, e queste connessioni sono utilizzate dai manager per: controllare l operatività dei server: in particolare ogni manager controlla l operatività del proprio manager successivo attraverso l invio di messaggi di heartbeat mediante questo canale; per propagare eventuali modifiche del file system; 3

4 per propagare informazioni sullo stato di carico dei vari server (sia data server che manager server). In questo modo ogni manager server è incaricato di servire i clienti, e nel caso vada offline, questi ultimi possono rivolgersi a un manager alternativo per richiederne i servizi. Per questo motivo occorre che tutti i manager server siano perfettamente sincronizzati tra di loro in modo che ciascuno di questi abbia una copia del file system logico globale. A tal scopo ogni manager server mantiene al suo interno due oggetti di tipo InformationControl e FileSystem contenenti tutte le info riguardanti il sistema globale: rispettivamente, informazioni sul carico dei vari server sino a quel momento registrati al sistema, e struttura logica dei file presenti nei diversi data server. Tramite l ispezione di questi oggetti sono scelte le locazioni di download e upload per i client e si definiscono le operazioni di ottimizzazione possibili. Nascono così problematiche di propagazione dello stato e sincronizzazione a run-time dei manager che affronteremo nel capitolo DATA SERVER I data server rappresentano gli effettivi esecutori del servizio e il loro numero può essere dinamicamente variato, con la prerogativa che maggiore è il loro numero e maggiori saranno le prestazioni dell infrastruttura. Ogni data server è registrato presso un manager che lo gestisce, ed è compito dell amministratore del sistema stabilire in modo statico quest associazione, inserendo nella configurazione del data server la locazione del manager server al quale rivolgersi, cercando di strutturare il sistema in modo intelligente, associando i vari data server in base alle esigenze di risorse richieste (manager ad alto traffico dovrebbero avere più data server a disposizione rispetto a manager più scarichi) e permettere quindi politiche di bilanciamento sensate sfruttando al massimo le potenzialità dell hardware a disposizione. I data server sono costantemente monitorati dal manager, che gestisce la replicazione dei file e bilancia il carico di lavoro su ognuno di essi. La comunicazione con i client durante le operazioni di trasferimento file sono ovviamente gestite secondo il protocollo TCP, così come le operazioni di replica fra data server diversi. Anche i data server sono realizzati come applicazioni multi-threaded e presentano una GUI tramite la quale un amministratore di sistema può avviare il server e visualizzare le operazioni che avvengono grazie ad un log grafico, o deregistrarlo rendendo i file in esso contenuti non più disponibili (ad esempio per far migrare il data server presso altri manager che presentano una situazione di carico maggiore, o per eseguire qualsiasi tipo di manutenzione offline del server). Per essere integrato nel sistema, un data server quindi ha bisogno di registrarsi presso un manager già attivo nel sistema: durante questa procedura esso invia i propri dati identificativi (IP, porta di ascolto, file condivisi, spazio disponibile ) e attende una risposta per mettersi in ascolto sulla porta convenuta in attesa di richieste da parte dei client. Inoltre viene connessa con il manager anche una socket TCP permanente che funge da canale di controllo per monitorare l operatività del data server mediante invio di messaggi heartbeat, e propagare lo stato di carico del data server verso il manager (spazio disponibile, quantità di carico, ecc). 3.3 PRINCIPALI OPERAZIONI Vediamo ora quali sono i protocolli previsti per le principali operazioni messe a disposizione dall architettura. Banalmente la richiesta della lista dei file remoti prevede un messaggio di richiesta da parte del middleware verso il manager server a lui assegnato e un 4

5 messaggio di risposta contenente la lista dei file. Più d interesse possono essere invece gli altri due protocolli. Per quanto riguarda l upload/download di file il protocollo è il seguente: il middleware invia un messaggio di richiesta al manager contenente il path remoto e la dimensione del file da caricare/scaricare; il manager, dopo aver effettuato alcuni controlli, risponde alla richiesta con la locazione (indirizzo ip + porta) del data server dove depositare/prelevare il file (scelta secondo le politiche di bilanciamento che affronteremo nel capitolo 5); il middleware quindi instaura una connessione con esso e inizia il trasferimento del file; in caso di upload, al termine del trasferimento, il data server invia una notifica al manager server a conferma del completamento del trasferimento del file, e quest ultimo provvede ad aggiungerlo all interno del file system; inserire la corrispondente informazione nel vettore delle modifiche per essere propagata all interno dell anello, e risponde al data server con un messaggio di successo; in caso di errori durante queste operazioni risponde con un messaggio di fallimento (una eccezione) contenente una descrizione dell errore; il data server ricevuta la risposta invia un messaggio al middleware (cliente), che può essere di successo nel caso non ci siano stati malfunzionamenti durante il protocollo; altrimenti cancella il file appena caricato e inoltra la descrizione dell errore al cliente. In questo ultimo caso è il cliente che dovrà ripetere al richiesta riprendendo il protocollo dal principio. Questo stesso protocollo è eseguito anche dal data server nel caso di replica di un file: in particolare quando un manager trova un file da replicare invia un comando al data server interessato, indicando la locazione del data server scelto per il deposito del file ed instaura una connessione con questo per il trasferimento del file. Per quanto riguarda la rimozione di file il protocollo seguito è il seguente: il middleware invia un messaggio al manager contenente il path remoto del file da rimuovere; il manager provvede a rimuovere il file dal file system logico e inserisce la rispettiva informazione di modifica nel vettore delle modifiche da propagare nell anello; lancia un thread responsabile di rimuovere il file dai rispettivi data server da lui gestiti dove risiede realmente il file, in modo da liberarne le risorse (il cliente non dovrà attendere che il file sia fisicamente rimosso dal data server); invia un messaggio al middleware contenente l esito dell operazione; anche gli altri manager server alla ricezione del messaggio di modifica rimuoveranno eventuali repliche del file sui data server gestiti. Da notare che il middleware (e quindi il cliente) ottiene una risposta sull esito dell operazione richiesta nonostante la modifica non sia stata ancora propagata all interno del sistema (approccio time-based di propagazione delle modifiche del file system). Questo tipo di approccio può portare a delle inconsistenze nel file system nel caso ad esempio il manager cada prima che l informazioni siano propagate, o anche nel caso ci siano interferenze nelle modifica dei file (due clienti eseguano delle modifiche sui medesimi file), dovuto ai tempi di propagazione. Tutti questi aspetti sono stati presi in considerazione e si è deciso di accettare eventuali inconsistenze per mantenere il più possibile un ottimo livello di prestazione e 5

6 banda occupata. Per risolvere questi problemi, si potrebbe pensare di complicare la progettazione dell infrastruttura, anche in relazione agli scopi d impiego, prevedendo ad esempio degli spazi di hosting separati, e impedire quindi che due utenti diversi non possano accedere in contemporanea allo stesso spazio, in modo da evitare a monte queste situazioni. 4. SINCRONIZZAZIONE L infrastruttura, come visto nel capitolo precedente, presenta più manager server organizzati in una struttura ad anello che collaborano per la fornitura del servizio. Ciascuno di essi mantiene una copia dell intero file system: occorre quindi che informazioni riguardanti la modifica del file system (aggiunta o rimozione file da parte dei clienti o anche replicazione automatica dei file) siano propagate nell interno anello in modo che ogni manager continui a mantenere una copia esatta del file system logico. Per far ciò si è pensato di usare ancora una volta un sistema time-based (per mantenere un livello di efficienza, visti dal cliente, elevato) in cui ogni manager server mantiene nella sua memoria una lista ordinata di modifiche da propagare all interno dell anello. In questo modo quando un cliente aggiunge o rimuove un file, il manager aggiunge questa informazione all interno della lista, e quindi un servizio in background provvederà a propagarle in ordine FIFO all interno dell anello: l informazione attraverserà così tutto l anello, raggiungendo tutti i manager partecipanti al sistema, sino a ritornare al manager di partenza che provvederà a distruggerla. Si accetta quindi di avere delle copie tiepide del file system a vantaggio di prestazioni viste dal cliente decisamente migliori (non occorre che il cliente aspetti che l informazione sia propagata nell anello per avere una risposta sull esito della richiesta, ma in un certo senso, il cliente si fida del manager che quindi sarà responsabile di tale compito). Si potrebbe pensare a dei vincoli e/o politiche che evitano a priori questo tipo di inconsistenze, introducendo ad esempio della ridondanza nelle informazioni di modifica del file system. Ad esempio si potrebbe decidere, in modo statico, un numero di manager server verso i quali propagare queste informazioni, prima di dare una risposta al cliente sull esito dell operazione (con ipotesi di guasto singolo, in linea teorica, basterebbe anche propagare l informazione verso il solo manager successivo). In questo modo, se il cliente ha avuto una risposta positiva, allora si avranno almeno due manager che sono a conoscenza della modifica e nel caso uno dei due cada sarà l altro a propagare l informazione nell anello. Questo tipo di approccio non è stato previsto per mantenere un livello di prestazioni il più alto possibile, ma potrebbe essere una eventuale estensione da implementare. Per rendere possibili questi protocolli, occorre che tutti i messaggi scambiati tra i manager siano identificati in modo univoco, e occorre poter stabilire un ordine temporale tra questi: in particolare occorre che i messaggi creati da ciascun manager siano mantenuti in ordine FIFO (aggiunta e rimozione di file dal sistema non devono invertirsi). Per far ciò le informazioni sono marcate in modo univoco con un identificativo composto dalla combinazione di ID del manager che l ha generata e numero di sequenza (un numero progressivo locale a ciascun server e indipendente dagli altri server). Vediamo ora quali protocolli i manager seguono per configurare l anello mantenendo il file system globale consistente. Innanzitutto il numero di manager all interno del sistema può variare in modo dinamico, e quindi occorre prevedere dei protocolli di join e unjoin del manager all interno del sistema: 6

7 Join: quando un manager si vuole registrare al sistema per iniziare a fornire il servizio, deve effettuare la richiesta presso un manager già attivo e operante (locazione presente all interno del file di configurazione del manager). Quest operazione segue il protocollo qui descritto, indicando con server A il manager servitore della richiesta, server B il suo successivo e server C il richiedente: a) il manager C richiede il join al manager A passandogli il proprio identificativo e un vettore contenente per ciascun manager l ID dell ultimo messaggio ricevuto da una eventuale precedente esecuzione (nel caso un manager registrato al sistema, non sia presente in questo vettore, vengono considerati per la ritrasmissione, tutte le modifiche da esso generate); b) il manager A ricevuta la richiesta, attraverso questo vettore, individua e invia le modifiche da trasmettere al manager C in modo che questo abbia il file system consistente con lo stato corrente, e appende all interno del vettore delle modifiche una particolare informazione (InfoJoin) utile avere conoscenza di quali messaggi sono stati inviati al nuovo manager e quali ancora devono essere inviati, e quindi utilizzato per sincronizzare il thread incaricato di eseguire il join con il thread di background di propagazione delle modifiche; tutto in simultanea al normale funzionamento del manager (thread parallelo e indipendente dal normale funzionamento del manager); c) una volta che il manager C si è sincronizzato con il manager A il processo incaricato di servire la richiesta termina depositando all interno dell oggetto InfoJoin la locazione del nuovo manager; d) il servizio di background una volta raggiunto il messaggio InfoJoin (o nel caso lo raggiungesse prima che il thread depositi il nuovo valore, attende questo valore) invia al manager B l ID del manager C che dovrà essere accettato da B come suo precedente, e chiude la connessione con esso. Questa connessione è rimpiazzata con la connessione al manager C che ha richiesto l operazione di join, e invia a quest ultimo la locazione del manager al quale collegarsi per richiudere l anello (locazione del manager B). e) Il manager C si collega così all indirizzo ricevuto che diventa il proprio manager successivo (richiudendo l anello): a questo punto il join può considerarsi concluso. Per ovvi motivi di semplicità d implementazione un manager può eseguire solo un join alla volta (metodi implementati come syncronized): eventuali altre richieste contemporanee sullo stesso manager saranno messe in coda e servite con i dovuti tempi di attesa. Per capire meglio i vari passaggi illustriamo la seguente figura riassuntiva: A a,b d Unjoin: questo protocollo invece è eseguito nel caso un manager intenda deregistrarsi dal sistema: a) Il manager che intende eseguire l operazione invia innanzitutto una richiesta di unjoin ai data server a lui e C B 7

8 registrati e attende che questi si siano deregistrati (chiusura soft delle comunicazioni attendendo la conclusione delle operazioni correntemente in esecuzione senza accettarne delle nuove); b) una volta che tutti i data server hanno terminato di servire i propri clienti pendenti e si sono deregistrati dal sistema, e tutte le modifiche effettuate sul file system sono state propagate, il manager invia una richiesta di unjoin al manager precedente e chiude la connessione con esso e con il manager successivo; c) il manager precedente ricevuta la richiesta di unjoin (o comunque alla chiusura della connessione) si collega al manager successivo del successivo (locazione sempre presente all interno di ciascun manager e aggiornata automaticamente in caso di riconfigurazione dell anello) ripetendo il protocollo di richiesta del vettore identificativo delle ultime modifiche ricevute e ritrasmette eventuali modifiche perse durante la chiusura delle connessioni. Da notare che questo stesso protocollo è eseguito anche nel caso di crash di un manager: in tal caso è il manager precedente a quello caduto che si accorge della non operatività (grazie ai messaggi di heartbeat) e quindi chiude la connessione con il manager successivo e ne apre una nuova con il manager successivo del successivo in modo da escludere, di fatto, il manager caduto (vedi capitolo 7). Per capire meglio i vari passaggi illustriamo la seguente figura riassuntiva: Manager Precedente b c Nuovo manager Manager successivo Da notare che quando l anello viene riconfigurato il manager che ha cambiato il proprio manager successivo deve aggiornare, sul manager precedente, la locazione del proprio manager successivo (che sarà quindi il successivo del successivo per manager precedente), in modo che ciascun manager conosca la locazione sempre aggiornata del manager successivo al successivo, in accordo alla configurazione attuale dell anello. Ovviamente l unjoin di un manager porta alla chiusura di tutti i data server a lui registrati che quindi non potranno svolgere il proprio servizio: tutti i file depositati su di essi, se non replicati presso altre isole di data server gestiti da altri manager, non saranno disponibili sino a quando quel manager e i suoi rispettivi data server a lui registrati non torneranno online. Per ovviare a questo problema si potrebbe prevedere nella configurazione dei data server un manager alternativo che prende in carico la gestione di questi, sin tanto il manager principale non torna online. Anche questo punto di vista non è stato implementato nella realizzazione dell architettura trattata in quest articolo, ma potrebbero essere una estensione che potrebbe essere integrata nel sistema. a b 8

9 5. LOAD-BALANCING L infrastruttura progettata è in grado di ripartire in maniera uniforme il carico di lavoro fra i diversi data server. Tutto ciò in primo luogo favorisce la velocità di risposta percepita dai client, ma consente anche di non sovraccaricare eccessivamente i vari data server, sfruttando al meglio l hardware a disposizione. Il criterio usato per la scelta è diverso secondo l operazione richiesta, infatti, a fronte di una richiesta da parte di un cliente, il manager, nel restituire una locazione, valuta diversi fattori: In caso di download, il manager sceglie, fra i data server sui quali risiede il file richiesto, quello che è meno congestionato. Il livello di congestione, in questo caso, è misurato come il numero di connessioni simultanee già attive in ogni server. Si sceglierà il server per cui questo valore è minimo, controllando anche il vincolo sul valore massimo di connessioni simultanee ammesse, parametro questo scelto dall amministratore del data server. In caso di una richiesta di upload, invece, oltre a controllare il livello di congestione come nel caso di download, sarà necessario individuare quei data server che hanno sufficiente spazio a disposizione per memorizzare il file. Per effettuare la scelta, infatti, si calcola una media pesata fra questi due fattori, considerando come predominante lo spazio a disposizione del data server. Questa scelta di progetto è stata dettata dalla considerazione che, viste le capacità di replicazione del sistema, caricare file su data server con poco spazio disponibile limita fortemente le possibilità di ottimizzazione, descritte nel prossimo paragrafo. Per quanto riguarda invece il bilanciamento di carico tra i vari manager server questo è demandato al middleware di supporto lato cliente che tratteremo nel capitolo REPLICAZIONE Un altra caratteristica fondamentale per assicurare la disponibilità dei dati è la replicazione degli stessi. Il punto cruciale è quello di trovare un compromesso fra una replicazione totale (situazione idealmente perfetta, ma penalizzante dal punto di vista delle performance) e una replicazione parziale e time-based. Nel progetto è stato usato un sistema di replicazione time-based creando un thread di background che analizza la situazione dell intero cluster logico e, dinamicamente, sceglie quali file, presenti nella propria isola di data server, devono essere replicati e in quali data server (privilegiando data server registrati presso altri manager per garantire che in caso il manager vada offline, altri manager server possono rispondere alla richiesta del file) lasciando poi l effettivo onere della replica ai singoli data server coinvolti. Ciò consente di ottenere un buon grado di affidabilità, introducendo un limitato overhead. Il principio è elementare: a ogni intervallo, che è un parametro di progetto, il manager esamina la lista dei file dei data server gestiti, individuando tutte le possibili repliche da eseguire. Nel determinare le operazioni di replica si è seguito un modello gerarchico, ordinando i file in base al numero di proprietari (numero di data server dove effettivamente risiede una copia del file). Sono così processati prima i file con singolo proprietario, e poi man mano quelli con più proprietari. A parità di numero di proprietari si esegue un secondo ordinamento per dimensione decrescente e quindi (seguendo gli algoritmi di load-balancing) si seleziona, per ognuno, il data server dove compiere l upload. 9

10 Seguendo questo principio si tende a replicare prima i file più grandi per cercare di utilizzare al meglio lo spazio disponibile: infatti, se si replicassero prima i file più piccoli, si correrebbe il rischio di non avere più spazio disponibile per replicare quelli grandi, poiché trovare ampi spazi liberi è sen altro meno probabile rispetto a trovarne di piccoli. 7. FAULT-TOLERANCE In un servizio come il file hosting riveste particolare importanza la gestione delle possibili cadute dei diversi server. È quindi necessario predisporre dei meccanismi, il più possibile automatici, in grado di porre rimedio, in un tempo il più breve possibile, a tali eventi negativi. Per quanto riguarda il controllo dei diversi data server, è lo stesso manager che se ne occupa, mediante un thread che invia pacchetti heartbeat a intervalli regolari, consentendo così di verificarne lo stato di esecuzione: in tali thread, è presente un valore di timeout, trascorso il quale il server è ipotizzato caduto. Per minimizzare l eventualità in cui un singolo pacchetto heartbeat sia perso, per motivi non dipendenti dal data server, è prevista una ritrasmissione immediata del pacchetto alla scadenza del timeout, e una successiva violazione dello stesso porta in questo caso alla dichiarazione di caduta del server, con la conseguenza che vengono rimossi dal manager tutti i riferimenti allo stesso. Un altro aspetto riguardante la faulttolerance è gestito durante le operazioni di download/upload dei file. Infatti, il client, in caso di malfunzionamenti nella rete, prevede meccanismi di ritrasmissione. Nel caso, ad esempio, in cui il data server non rispondesse più, il client chiede al manager un altro indirizzo e ricomincia la transazione con quest ultimo. E stato adottato quest approccio perché, la connessione con il manager è mantenuta durante tutta la durata della sessione di operatività, è statisticamente più rapido richiedere un nuovo indirizzo piuttosto che tentare ritrasmissioni con un server probabilmente caduto. Inoltre anche in caso di caduta di un manager il sistema cerca di reagire minimizzando i tempi di recupero. In sostanza quando un manager cade, il suo manager precedente si accorge di tale situazione, mediante l invio di messaggi di heartbeat, e provvede a riconfigurare l anello connettendosi al manager successivo a quello caduto (ogni manager conosce il manager successivo al successivo che viene continuamente aggiornato nel caso l anello venga riconfigurato per l aggiunta o rimozione di eventuali altri manager). Richiede a quest'ultimo il vettore degli ID delle modifiche ritrasmettendo eventuali modifiche perse, escludendo così, di fatto, il manager caduto (da notare che questo protocollo è simile al protocollo di unjoin, con al differenza che non vi è il messaggio iniziale di richiesta, ma è il manager precedente che accortosi della non operatività del manager fa partire il protocollo). Ovviamente tutte le operazioni in corso al manager caduto dovranno riprendere su un altro manager: è il middleware lato cliente che persa la connessione con il manager cercherà un manager alternativo (locazione anch essa contenuta nel file di configurazione e aggiornata a run-time da parte del manager mediante meccanismi di piggybacking). Questo meccanismo garantisce la massima operatività grazie all assunzione esemplificativa di guasto singolo dei server. Un ultima riflessione merita l argomento della concorrenza: l intera architettura server è stata concepita cercando di assicurare un livello ottimo di concorrenza gestendo ogni operazione in maniera transazionale e garantendo quindi le proprietà A.C.I.D. mediante l uso di metodi synchronized e di opportuni meccanismi di rollback, ad esempio nel caso di trasferimenti falliti. 10

11 8. SCALABILITÀ Un alto grado di scalabilità in un servizio come il file hosting è decisivo. Infatti, sia la capacità di memorizzazione, che il numero di richieste simultanee aumentano in maniera quasi esponenziale al crescere del numero di utenti che utilizzano il servizio. Questo problema è stato preso in considerazione fin dall inizio nel progetto, codificando tutta l architettura server in un livello di controllo (manager) e uno di storage (data server). Infatti, variando il numero di macchine che eseguono i data server e i manager server è possibile ottenere ogni livello di potenza (in termini di capacità di memorizzazione e di gestione di richieste simultanee) desiderato. È compito dei manager gestire l ingresso e l uscita di data server in maniera che siano tutti utilizzati al loro massimo potenziale, mostrando invece all utente una visione trasparente dell architettura server, mentre il compito di distribuire il carico sui manager server è rimandato al middleware (ispirato al modello degli smart proxy) in modo che questi scelgano il manager al quale richiedere il servizio seguendo delle politiche più o meno dinamiche: ad esempio attraverso politiche basate sulla località (dividere i clienti in zone geografiche e quindi il manager è responsabile di servire quella determinata zona) o delle politiche statiche in cui in fase di distribuzione del middleware a ciascuno di essi è assegnato in maniera statica un manager, attraverso una politica round robin, ad esempio, o qualsiasi altra politica che ci può venire in mente. I client operano in maniera trasparente rispetto all architettura server, questo perché il middleware esporta loro una semplice interfaccia con le tre primitive delle operazioni fondamentali, oscurando i meri dettagli delle comunicazioni. Nel progetto è stato implementato un middleware per applicazioni grafiche e threadsafe; è tuttavia possibile, implementando l interfaccia base, realizzare versioni alternative sia a livello locale sia nella comunicazione con l architettura server, anche grazie all approccio al provider model adottato nella realizzazione del componente. Inoltre all interno di questo middleware è stato implementato la logica per la gestione del load-balancing dei manager: è compito del middleware decidere a quale manager connettersi, avendo a disposizione una lista di manager, che potrebbe essere aggiornata a runtime attraverso pacchetti di piggybacking inviati dai manager durante l ultima sessione (meccanismi ispirati agli smart proxy utilizzati in j-boss), meccanismo non implementato nella infrastruttura sviluppata in quest articolo. 10. COMPLESSITÀ Ora facciamo delle considerazioni riguardanti l overhead di comunicazione durante le varie operazioni, dovute alla gestione della struttura. Indicando con N il numero di manager server partecipanti al sistema e M il numero di data server registrati verso un generico manager, abbiamo: 9. CLIENT Il client distribuito nel progetto è realizzato come un applicazione grafica che consente di eseguire le operazioni di download, upload e lista file remoti. E possibile però costruire diversi client, magari all interno di applicazioni più complesse, inglobando queste funzionalità grazie al middleware di supporto progettato. 11

12 per ogni operazione di aggiunta file occorrono nel complesso sette messaggi scambiati tra client, manager e data server: Cliente Manager Data Richiesta Loc. DS Ack UP compl. Trasf. file in più sono inviati sulla rete 2*(N 1) messaggi contenente l informazione dell aggiunta nel file system e rispettivi ack scambiati fra gli N manager. per ogni operazione di rimozione file sono inviati sempre 2*(N-1) messaggi tra imanager; 2*R messaggi (dove R è il numero di repliche dove il file risiede) tra manager e data server dove risiede realmente il file; un messaggi di richiesta e risposta tra client e manager, per un totale di 2*(N-1+R) + 2: informazioni di carico di tutti i data server partecipanti; messaggi di controllo dell operatività di ciascun server, sia esso manager che data: come per gli aggiornamenti di stato abbiamo M+N messaggi di heartbeat; per quanto riguarda invece il protocollo di join abbiamo un messaggio di richiesta, 2*Q messaggi di modifica del file system, in relazione alla quantità di modifiche che il nuovo manager deve ricevere per sincronizzarsi con gli altri manager e rispettivi ack. In più abbiamo due messaggi contenente la locazione del manager da inviare sia al manager che vuole registrarsi, sia al manager successivo, ed inoltre un messaggio di richiesta del nuovo manager verso il manager successivo e rispettivo messaggio di ack per il nuovo collegamento: in totale 2*Q+7 Precedente Nuovo Cliente Successivo Ric. join Richiesta Sinc. FS Manager InfoJoin Ack Data Richiesta Rimozione file Ack Ovviamente tutti i protocolli possono subire dei malfunzionamenti, per cui si possono avere delle ritrasmissioni o, nei casi peggiori, dei fallimenti con i dovuti rollback per mantenere il sistema consistente. per gli aggiornamenti sul carico dei vari server sono inviati nel complesso M+N messaggi: M messaggi inviati tra data server e i rispettivi manager server di gestione, e N messaggi per attraversare tutto l anello dei manager partecipanti; in questo modo tutti i manager server hanno 11. CONCLUSIONI E SVILUPPI FUTURI E stata progettata un architettura client/server in grado di gestire un servizio di file hosting affidabile, disponibile e scalabile, garantendo agli utenti la maggior QoS percepita 12

13 possibile in base alle risorse disponibili nell architettura server. Nei test eseguiti su rete locale, si è notato un buon grado di loadbalancing e di affidabilità; è stata osservata anche una risposta sufficientemente rapida a eventi negativi come la caduta di un nodo. E possibile tuttavia tarare questi parametri prestazionali modificando il file di configurazione Config.XML che consente di bilanciare il rapporto costo-prestazioni del sistema in proporzione alle necessità dell amministratore e delle risorse disponibili. Sono molte le estensioni possibili all infrastruttura presentata, ma le principali riguardano la sicurezza. Infatti, non è stato previsto alcun meccanismo di autenticazione e autorizzazione. Potrebbe invece essere utile inserire tali meccanismi sia a livello della comunicazione client server che in quella interna all applicazione server. Per quanto riguarda il primo caso, sarebbe così possibile risalire al proprietario di un file, poterne avere di privati, modificarli o cancellarli e consentire solo agli utenti autorizzati l uso del servizio. Nel secondo caso invece il problema è più subdolo: infatti, non essendoci meccanismi di autenticazione e autorizzazione, chiunque in possesso del codice eseguibile può spacciarsi per manager o data server, ponendosi così nella posizione di portare attacchi di pericolosità crescente alle diverse macchine server legali nonché ai client che possono essere indotti a scaricare file pericolosi invece di ciò che realmente volevano ottenere. Sarebbe utile anche poter disporre di un servizio di nomi che consenta ai client di localizzare in maniera trasparente il proprio manager all interno dell infrastruttura. In alternativa, come visto nel capitolo precedente, si potrebbe aggiornare la lista dei manager nel middleware di supporto mediante piggybacking e quindi implementare politiche dinamiche per fare load-balancing dei manager. 13

Un infrastruttura di supporto per servizi di file hosting

Un infrastruttura di supporto per servizi di file hosting Un infrastruttura di supporto per servizi di file hosting Università degli Studi di Bologna Laurea Specialistica in Ingegneria Informatica Reti di Calcolatori LS Prof. A. Corradi A.A. 2006/2007 Matteo

Dettagli

PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY

PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY Giampiero Allamprese 0000260193 PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY Reti di Calcolatori LS prof. Antonio Corradi A.A. 2007/2008 ABSTRACT L obiettivo di questo progetto è la realizzazione

Dettagli

BrightSync: progetto di un middleware di sincronizzazione per ambienti eterogenei

BrightSync: progetto di un middleware di sincronizzazione per ambienti eterogenei Corso di Laurea Specialistica in Ingegneria Informatica Reti di Calcolatori LS prof. Antonio Corradi BrightSync: progetto di un middleware di sincronizzazione per ambienti eterogenei di Emanuele Crescentini

Dettagli

Parte II: Reti di calcolatori Lezione 9

Parte II: Reti di calcolatori Lezione 9 Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14 Pietro Frasca Parte II: Reti di calcolatori Lezione 9 Martedì 1-04-2014 1 Applicazioni P2P

Dettagli

PROGETTI DISPONIBILI IL CORSO DI PROGETTO DI RETI E SISTEMI INFORMATICI

PROGETTI DISPONIBILI IL CORSO DI PROGETTO DI RETI E SISTEMI INFORMATICI PROGETTI DISPONIBILI IL CORSO DI PROGETTO DI RETI E SISTEMI INFORMATICI 1 Web Link Monitor... 2 2 Database Browser... 4 3 Network Monitor... 5 4 Ghost Site... 7 5 Copy Search... 9 6 Remote Audio Video

Dettagli

Di seguito ci accingiamo ad analizzare le possibili configurazioni di architettura: Server singolo

Di seguito ci accingiamo ad analizzare le possibili configurazioni di architettura: Server singolo La progettazione dell architettura si concentra sulla scelta dell hardware, dell infrastruttura di rete, e dei componenti software che andranno a costituire il sistema. Gli obbiettivi tecnologici che il

Dettagli

Music Everywhere with BT

Music Everywhere with BT Music Everywhere with BT Acquaviva Luca 231767 luca.acquaviva@studio.unibo.it Colombini Gabriele 231491 gabriele.colombini@studio.unibo.it Manservisi Alberto 258370 alberto.manservisi@studio.unibo.it Abstract

Dettagli

Sistemi Operativi (modulo di Informatica II)

Sistemi Operativi (modulo di Informatica II) Sistemi Operativi (modulo di Informatica II) La comunicazione tra processi Patrizia Scandurra Università degli Studi di Bergamo a.a. 2008-09 Sommario Processi cooperanti La comunicazione tra processi Necessità

Dettagli

Supporto per servizi di File Hosting

Supporto per servizi di File Hosting Supporto per servizi di File Hosting Progetto per il corso di Reti di Calcolatori LS a.a 2005-2006 Valerio Guagliumi 0000236769 Abstract Questa relazione descrive il progetto realizzato di un sistema di

Dettagli

Sistemi Distribuiti. Informatica B. Informatica B

Sistemi Distribuiti. Informatica B. Informatica B Sistemi Distribuiti Introduzione Che cos è un sistema distribuito? Un sistema distribuito è una collezione di computer indipendenti che appare all utente come un solo sistema coerente Da notare: le macchine

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

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

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

27/03/2013. Contenuti

27/03/2013. Contenuti Corso Sistemi Distribuiti 6 cfu Docente: Prof. Marcello Castellano Contenuti Virtualizzazione - 3 Macchina virtuale - 4 Architetture delle macchine virtuali - 6 Tipi di virtualizzazione - 7 Monitor della

Dettagli

31/05/2013. Sistemi Web Distribuiti (parte 2) - Indice dei Contenuti - Naming. Corso Sistemi Distribuiti 6 cfu Docente: Prof. Marcello Castellano

31/05/2013. Sistemi Web Distribuiti (parte 2) - Indice dei Contenuti - Naming. Corso Sistemi Distribuiti 6 cfu Docente: Prof. Marcello Castellano Corso Sistemi Distribuiti 6 cfu Docente: Prof. Marcello Castellano /28 Sistemi Web Distribuiti (parte 2) - Indice dei Contenuti - Naming 3 Sincronizzazione 4 Consistenza e Replica 5 Replica di sistemi

Dettagli

Introduzione. Livello applicativo Principi delle applicazioni di rete. Stack protocollare Gerarchia di protocolli Servizi e primitive di servizio 2-1

Introduzione. Livello applicativo Principi delle applicazioni di rete. Stack protocollare Gerarchia di protocolli Servizi e primitive di servizio 2-1 Introduzione Stack protocollare Gerarchia di protocolli Servizi e primitive di servizio Livello applicativo Principi delle applicazioni di rete 2-1 Pila di protocolli Internet Software applicazione: di

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

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

Testo Esame di Stato 2011-2012 YABC ESAME DI STATO DI ISTITUTO TECNICO INDUSTRIALE. CORSO SPERIMENTALE PROGETTO «ABACUS» Indirizzo: INFORMATICA

Testo Esame di Stato 2011-2012 YABC ESAME DI STATO DI ISTITUTO TECNICO INDUSTRIALE. CORSO SPERIMENTALE PROGETTO «ABACUS» Indirizzo: INFORMATICA A.S. 2011-2012 Testo Esame di Stato 2011-2012 YABC ESAME DI STATO DI ISTITUTO TECICO USTRIALE CORSO SPERIMETALE PROGETTO «ABACUS» Indirizzo: IFORMATICA Tema di: SISTEMI DI ELABORAZIOE E TRASMISSIOE DELLE

Dettagli

1.1 - Crittografia sulla infrastruttura trasmissiva tra le stazioni remote Rilheva il centro di telecontrollo

1.1 - Crittografia sulla infrastruttura trasmissiva tra le stazioni remote Rilheva il centro di telecontrollo SISTEMA DI TELECONTROLLO RILHEVA GPRS (CARATTERISTICHE DEL VETTORE GPRS E SICUREZZE ADOTTATE) Abstract: Sicurezza del Sistema di Telecontrollo Rilheva Xeo4 ha progettato e sviluppato il sistema di telecontrollo

Dettagli

Cluster per architetture a componenti

Cluster per architetture a componenti Luca Cabibbo Architetture Software Cluster per architetture a componenti Dispensa ASW 442 ottobre 2014 Un buon progetto produce benefici in più aree. Trudy Benjamin 1 -Fonti [IBM] Clustering Solutions

Dettagli

Table of Contents. Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano

Table of Contents. Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano Table of Contents Definizione di Sistema Distribuito - 4 Obiettivi Principali di un S.D. - 7 Tipi di Sistemi

Dettagli

RAMS: la gestione completa delle attività degli Istituti di Vigilanza e Sorveglianza

RAMS: la gestione completa delle attività degli Istituti di Vigilanza e Sorveglianza RAMS: la gestione completa delle attività degli Istituti di Vigilanza e Sorveglianza White Paper 1 Gennaio 2005 White Paper Pag. 1 1/1/2005 La gestione degli Istituti di Vigilanza e Sorveglianza L efficienza

Dettagli

Parte II: Reti di calcolatori Lezione 11

Parte II: Reti di calcolatori Lezione 11 Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2014-15 Parte II: Reti di calcolatori Lezione 11 Martedì 14-04-2015 1 Esempio di uso di proxy Consideriamo

Dettagli

Table of Contents. Definizione di Sistema Distribuito 15/03/2013

Table of Contents. Definizione di Sistema Distribuito 15/03/2013 Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano Table of Contents Definizione di Sistema Distribuito - 4-7 - 13 Definizioni e Principali Caratteristiche

Dettagli

Architettura SW Definizione e Notazioni

Architettura SW Definizione e Notazioni Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Stili Architetturali E. TINELLI Architettura SW Definizione e Notazioni Definizione ANSI/IEEE Std Std1471-2000

Dettagli

Capire i benefici di una rete informatica nella propria attività. I componenti di una rete. I dispositivi utilizzati.

Capire i benefici di una rete informatica nella propria attività. I componenti di una rete. I dispositivi utilizzati. LA RETE INFORMATICA NELL AZIENDA Capire i benefici di una rete informatica nella propria attività. I componenti di una rete I dispositivi utilizzati I servizi offerti LA RETE INFORMATICA NELL AZIENDA Copyright

Dettagli

La sicurezza secondo skymeeting (data pubblicazione 06/12/2011)

La sicurezza secondo skymeeting (data pubblicazione 06/12/2011) La sicurezza secondo skymeeting (data pubblicazione 06/12/2011) www.skymeeting.net La sicurezza nel sistema di videoconferenza Skymeeting skymeeting è un sistema di videoconferenza web-based che utilizza

Dettagli

Reti di computer. Agostino Lorenzi - Reti di computer - 2008

Reti di computer. Agostino Lorenzi - Reti di computer - 2008 Reti di computer Telematica : termine che evidenzia l integrazione tra tecnologie informatiche e tecnologie delle comunicazioni. Rete (network) : insieme di sistemi per l elaborazione delle informazioni

Dettagli

TECNICO SUPERIORE PER IL SISTEMA INFORMATIVO AZIENDALE

TECNICO SUPERIORE PER IL SISTEMA INFORMATIVO AZIENDALE ISTRUZIONE E FORMAZIONE TECNICA SUPERIORE SETTORE INDUSTRIA E ARTIGIANATO TECNICO SUPERIORE PER IL SISTEMA INFORMATIVO AZIENDALE STANDARD MINIMI DELLE COMPETENZE TECNICO PROFESSIONALI DESCRIZIONE DELLA

Dettagli

Progetto RE.VE.N.GE. DDS con Fault-tolerance. del Sistema di Consegna

Progetto RE.VE.N.GE. DDS con Fault-tolerance. del Sistema di Consegna Progetto RE.VE.N.GE. DDS con Fault-tolerance del Sistema di Consegna Progetto di: Marco Livini, Luca Nardelli, Christian Pinto Reti di Calcolatori LS 08-09 Prof. Antonio Corradi, Ing. Luca Foschini Relazione

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

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 2010/2011 Questi lucidi sono stati prodotti sulla

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

Software che sovrintende al funzionamento del computer eseguendo compiti diversi:

Software che sovrintende al funzionamento del computer eseguendo compiti diversi: Sistema Operativo dispensa a cura di Alessandro Bellini Software che sovrintende al funzionamento del computer eseguendo compiti diversi: 1. Gestire interazione utente macchina 2. Fornire un interfaccia

Dettagli

Progettazione: Tecnologie e ambienti di sviluppo

Progettazione: Tecnologie e ambienti di sviluppo Contratto per l acquisizione di servizi di Assistenza specialistica per la gestione e l evoluzione del patrimonio software della Regione Basilicata. Repertorio n. 11016 del 25/09/2009 Progettazione: Tecnologie

Dettagli

La Sicurezza delle Reti. La Sicurezza delle Reti. Il software delle reti. Sistemi e tecnologie per la multimedialità e telematica.

La Sicurezza delle Reti. La Sicurezza delle Reti. Il software delle reti. Sistemi e tecnologie per la multimedialità e telematica. Sistemi e tecnologie per la multimedialità e telematica Fabio Burroni Dipartimento di Ingegneria dell Informazione Università degli Studi di Siena burronif@unisi unisi.itit La Sicurezza delle Reti La presentazione

Dettagli

Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14. Pietro Frasca. Parte II Lezione 1

Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14. Pietro Frasca. Parte II Lezione 1 Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14 Pietro Frasca Parte II Lezione 1 Martedì 4-03-2014 1 TESTO DI RIFERIMENTO RETI DI CALCOLATORI

Dettagli

La piattaforma di lettura targhe intelligente ed innovativa in grado di offrire servizi completi e personalizzati

La piattaforma di lettura targhe intelligente ed innovativa in grado di offrire servizi completi e personalizzati La piattaforma di lettura targhe intelligente ed innovativa in grado di offrire servizi completi e personalizzati Affidabilità nel servizio precisione negli strumenti Chanda LPR Chanda LPR è una piattaforma

Dettagli

Controllo remoto di SPEEDY

Controllo remoto di SPEEDY UNIVERSITÀ DI BRESCIA FACOLTÀ DI INGEGNERIA Dipartimento di Elettronica per l Automazione Laboratorio di Robotica Avanzata Advanced Robotics Laboratory Corso di Robotica (Prof. Riccardo Cassinis) Controllo

Dettagli

Servizi di hosting offerti dall'area Servizi ICT Integrazione con l'anagrafica Unica di Ateneo. Area Servizi ICT

Servizi di hosting offerti dall'area Servizi ICT Integrazione con l'anagrafica Unica di Ateneo. Area Servizi ICT Area Servizi ICT Servizi hosting di Ateneo - Integrazione con l'anagrafica Unica di Ateneo Versione 1.1 http://hosting.polimi.it Servizi di hosting offerti dall'area Servizi ICT Integrazione con l'anagrafica

Dettagli

I protocolli UDP e TCP

I protocolli UDP e TCP I protocolli UDP e TCP A.A. 2005/2006 Walter Cerroni Il livello di trasporto in Internet APP. APP. TCP UDP IP collegamento logico tra diversi processi applicativi collegamento logico tra diversi host IP

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

Algoritmi per protocolli peer-to-peer

Algoritmi per protocolli peer-to-peer Algoritmi per protocolli peer-to-peer Introduzione Livio Torrero (livio.torrero@polito.it) 09/2009 Approccio client-server (1/2) Client 1 Client 3 Server Client 2 Client 4 Paradigma molto comune Un client

Dettagli

Implementare iphone e ipad Gestione dei dispositivi mobili (MDM)

Implementare iphone e ipad Gestione dei dispositivi mobili (MDM) Implementare iphone e ipad Gestione dei dispositivi mobili (MDM) ios supporta la gestione MDM (Mobile Device Management) consentendo alle aziende di gestire implementazioni su larga scala di iphone e ipad

Dettagli

Perché scegliere Vidia

Perché scegliere Vidia Perché scegliere Vidia I sistemi Vidia funzionano con qualunque connessione Internet Un sistema di videosorveglianza si definisce moderno solo ed esclusivamente se può essere controllato oltre che tramite

Dettagli

CASE STUDY N#1. Deploy e automazione di un applicazione scalabile con il supporto di SaltStack per Corley

CASE STUDY N#1. Deploy e automazione di un applicazione scalabile con il supporto di SaltStack per Corley CASE STUDY N#1 Deploy e automazione di un applicazione scalabile con il supporto di SaltStack per Corley Enter srl - ISO 9001/27001 Quality System Certification - All rights reserved - www.entercloudsuite.it

Dettagli

OPTILOG. La soluzione Siemens per la gestione del magazzino in ambito farmaceutico. Pagina 1 Siemens IS IT MES Solutions

OPTILOG. La soluzione Siemens per la gestione del magazzino in ambito farmaceutico. Pagina 1 Siemens IS IT MES Solutions La soluzione Siemens per la gestione del magazzino in ambito farmaceutico Pagina 1 I requisiti di un WMS Certezza operativa Utilizzo pieno dell impianto Conoscenza dello stato impianto Riduzione dei costi

Dettagli

Classificazione delle applicazioni multimediali su rete

Classificazione delle applicazioni multimediali su rete Universita' di Verona Dipartimento di Informatica Classificazione delle applicazioni multimediali su rete Davide Quaglia a.a. 2006/2007 1 Sommario Architettura di riferimento Classificazione per funzionalità

Dettagli

FORUM TELECONTROLLO 2013

FORUM TELECONTROLLO 2013 FORUM TELECONTROLLO 2013 Relazione Titolo: Sulla strada per la Smart City Tecnologie e soluzioni innovative per aumentare l efficienza delle Reti Idriche. Relazione: Le città si stanno trasformando in

Dettagli

CdL MAGISTRALE in INFORMATICA A.A. 2014-15 corso di Sistemi Distribuiti. 8. Le architetture (prima parte) Prof. S.Pizzutilo

CdL MAGISTRALE in INFORMATICA A.A. 2014-15 corso di Sistemi Distribuiti. 8. Le architetture (prima parte) Prof. S.Pizzutilo CdL MAGISTRALE in INFORMATICA A.A. 2014-15 corso di Sistemi Distribuiti 8. Le architetture (prima parte) Prof. S.Pizzutilo I Sistemi Distribuiti Un Sistema Distribuito è un insieme di processori indipendenti

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

ALLEGATO 1 DESCRIZIONE DEL SERVIZIO

ALLEGATO 1 DESCRIZIONE DEL SERVIZIO ALLEGATO 1 DESCRIZIONE DEL SERVIZIO . IntrodDescrizione del Servizio a) Procedura di accreditamento Il Centro Servizi (CS) che richiede l accreditamento per la fornitura dell accesso fisico al Sistema

Dettagli

Tecnologia di un Database Server (centralizzato) Gestione dell affidabilità

Tecnologia di un Database Server (centralizzato) Gestione dell affidabilità Affidabilità Basi di Dati / Complementi di Basi di Dati 1 Tecnologia di un Database Server (centralizzato) Gestione dell affidabilità Angelo Montanari Dipartimento di Matematica e Informatica Università

Dettagli

Introduzione ai Sistemi Distribuiti

Introduzione ai Sistemi Distribuiti Università degli Studi di Roma Tor Vergata Facoltà di Ingegneria Introduzione ai Sistemi Distribuiti Corso di Sistemi Distribuiti Valeria Cardellini Anno accademico 2008/09 Definizioni di SD Molteplici

Dettagli

Sistemi Distribuiti. Libri di Testo

Sistemi Distribuiti. Libri di Testo Sistemi Distribuiti Rocco Aversa Tel. 0815010268 rocco.aversa@unina2.it it Ricevimento: Martedì 14:16 Giovedì 14:16 1 Libri di Testo Testo Principale A.S. Tanenbaum, M. van Steen, Distributed Systems (2

Dettagli

Content Distribution Networks Digital Rights Management

Content Distribution Networks Digital Rights Management Content Distribution Networks Digital Rights Management Angelo Duilio Tracanna LabOne Italia S.r.l. Amministratore Delegato angelo.tracanna@labone.net 23 Novembre 2005 LabOne Stati uniti Brasile Italia

Dettagli

OBELISK MANUALE OPERATIVO EUTELIAVOIP

OBELISK MANUALE OPERATIVO EUTELIAVOIP OBELISK MANUALE OPERATIVO EUTELIAVOIP OBELISK Manuale Operativo EuteliaVoip Rev2-0 pag.2 INDICE DESCRIZIONE DI OBELISK...3 Caratteristiche...3 Requisiti...3 Funzionalità...4 Vantaggi...5 Tariffe...5 Number

Dettagli

RETI DI CALCOLATORI E APPLICAZIONI TELEMATICHE

RETI DI CALCOLATORI E APPLICAZIONI TELEMATICHE RETI DI CALCOLATORI E APPLICAZIONI TELEMATICHE Prof. PIER LUCA MONTESSORO Facoltà di Ingegneria Università degli Studi di Udine 1999 Pier Luca Montessoro (si veda la nota a pagina 2) 1 Nota di Copyright

Dettagli

Guida all utilizzo: Screen Sharing (data pubblicazione 22/06/2012)

Guida all utilizzo: Screen Sharing (data pubblicazione 22/06/2012) Guida all utilizzo: Screen Sharing (data pubblicazione 22/06/2012) www.skymeeting.net Indice Indice... 2 Introduzione... 3 Requisiti minimi per una sessione di Screen Sharing... 4 Test di autodiagnosi...

Dettagli

A Palazzo Madama la sicurezza è di casa

A Palazzo Madama la sicurezza è di casa A Palazzo Madama la sicurezza è di casa di Giovanni Contardi, Responsabile Security & Safety del Senato della Repubblica e Fabio Garzia, Docente di Sistemi di Sicurezza Anticrimine nel corso di laurea

Dettagli

UNA RETE SENZA FILI. C O N L E A Z I E N D E V E R S O N U O V E I M P R E S E

UNA RETE SENZA FILI. C O N L E A Z I E N D E V E R S O N U O V E I M P R E S E UNA RETE SENZA FILI. C O N L E A Z I E N D E V E R S O N U O V E I M P R E S E LA MOBILITÀ WLAN La mobilità aziendale non è più una frontiera tecnologica, ma una concreta necessità per competere ed essere

Dettagli

Processi di business sovra-regionali relativi ai sistemi regionali di FSE. Versione 1.0 24 Giugno 2014

Processi di business sovra-regionali relativi ai sistemi regionali di FSE. Versione 1.0 24 Giugno 2014 Processi di business sovra-regionali relativi ai sistemi regionali di FSE Versione 1.0 24 Giugno 2014 1 Indice Indice... 2 Indice delle figure... 3 Indice delle tabelle... 4 Obiettivi del documento...

Dettagli

CORSO EDA Informatica di base. Sicurezza, protezione, aspetti legali

CORSO EDA Informatica di base. Sicurezza, protezione, aspetti legali CORSO EDA Informatica di base Sicurezza, protezione, aspetti legali Rischi informatici Le principali fonti di rischio di perdita/danneggiamento dati informatici sono: - rischi legati all ambiente: rappresentano

Dettagli

1. Caratteristiche generali

1. Caratteristiche generali Allegato 1 (articolo 1, comma 1) ISTRUZIONI TECNICHE DI CUI AL DECRETO N. 108 DEL 11 MAGGIO 2015 1. Caratteristiche generali Premessa Il nucleo informativo dell AIA è costituito dalla Banca Dati Sinistri

Dettagli

INTEGRAZIONE ED ESPANSIONE DEL SISTEMA DI VIDEOSORVEGLIANZA DEL COMUNE DI CASTELLAMMARE DI STABIA TITOLO ELABORATO: MODULO ISOLE WI-FI HOT SPOT

INTEGRAZIONE ED ESPANSIONE DEL SISTEMA DI VIDEOSORVEGLIANZA DEL COMUNE DI CASTELLAMMARE DI STABIA TITOLO ELABORATO: MODULO ISOLE WI-FI HOT SPOT INTEGRAZIONE ED ESPANSIONE DEL SISTEMA DI VIDEOSORVEGLIANZA DEL COMUNE DI CASTELLAMMARE DI STABIA TITOLO ELABORATO: MODULO ISOLE WI-FI HOT SPOT INDICE 1. PREMESSA 4 2. ARCHITETTURA RETI MESH 5 3. DISPOSITIVI

Dettagli

CORSO I.F.T.S TECNICHE PER LA PROGETTAZIONE E LA GESTIONE DI DATABASE

CORSO I.F.T.S TECNICHE PER LA PROGETTAZIONE E LA GESTIONE DI DATABASE CORSO I.F.T.S TECNICHE PER LA PROGETTAZIONE E LA GESTIONE DI DATABASE Ing. Mariano Di Claudio Lezione del 24/09/2014 Indice 1. Aspetti di Data Management CouchBase 2. Aspetti Architetturali Infrastruttura

Dettagli

Un architettura per lo streaming multimediale in ambiente distribuito

Un architettura per lo streaming multimediale in ambiente distribuito tesi di laurea Anno Accademico 2012/2013 relatore Ch.mo prof. Simon Pietro Romano correlatori Ing. Tobia Castaldi candidato Alessandro Arrichiello Matr. M63/43 Contesto: o Content Distribution Networks

Dettagli

Data Base Management System. Strumenti: Formato: Pro: Contro: Software specifico. Proprietario

Data Base Management System. Strumenti: Formato: Pro: Contro: Software specifico. Proprietario Data Base Management System Strumenti: Software specifico Formato: Pro: Proprietario Massima semplicità di inserimento e gestione Tipizzazione Validazione dei dati Contro: Creazione del database Programmazione

Dettagli

Indirizzi Internet e. I livelli di trasporto delle informazioni. Comunicazione e naming in Internet

Indirizzi Internet e. I livelli di trasporto delle informazioni. Comunicazione e naming in Internet Indirizzi Internet e Protocolli I livelli di trasporto delle informazioni Comunicazione e naming in Internet Tre nuovi standard Sistema di indirizzamento delle risorse (URL) Linguaggio HTML Protocollo

Dettagli

Firewall Intrusion Detection System

Firewall Intrusion Detection System Firewall Intrusion Detection System Damiano Carra Università degli Studi di Verona Dipartimento di Informatica Parte I: Firewall 2 Firewall! I Firewall di rete sono apparecchiature o sistemi che controllano

Dettagli

InfoCertLog. Allegato Tecnico

InfoCertLog. Allegato Tecnico InfoCertLog Allegato Tecnico Data Maggio 2012 Pagina 2 di 13 Data: Maggio 2012 Sommario 1. Introduzione... 3 2. Le componenti del servizio InfoCertLog... 4 2.1. Componente Client... 4 2.2. Componente Server...

Dettagli

Descrizione del servizio Servizio di monitoraggio e recupero notebook e servizio di eliminazione dei dati in remoto:

Descrizione del servizio Servizio di monitoraggio e recupero notebook e servizio di eliminazione dei dati in remoto: Descrizione del servizio Servizio di monitoraggio e recupero notebook e servizio di eliminazione dei dati in remoto: Panoramica sul servizio Dell è lieta di fornire il servizio di monitoraggio e recupero

Dettagli

Sommario. G. Piscitelli

Sommario. G. Piscitelli Sommario Interprocess Communication Processi (e thread) cooperanti Il paradigma produttore-consumatore Shared Memory e Inter Process Communication (IPC) facility Proprietà caratteristiche della comunicazione

Dettagli

Progetto Virtualizzazione

Progetto Virtualizzazione Progetto Virtualizzazione Dipartimento e Facoltà di Scienze Statistiche Orazio Battaglia 25/11/2011 Dipartimento di Scienze Statiche «Paolo Fortunati», Università di Bologna, via Belle Arti 41 1 La nascita

Dettagli

Reti di Calcolatori IL LIVELLO RETE

Reti di Calcolatori IL LIVELLO RETE Reti di Calcolatori IL LIVELLO RETE D. Talia RETI DI CALCOLATORI - UNICAL 3-1 Il Livello RETE Servizi del livello Rete Organizzazione interna Livello Rete basato su Circuito Virtuale Livello Rete basato

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

Evoluzione dei sistemi operativi (5) Evoluzione dei sistemi operativi (4) Classificazione dei sistemi operativi

Evoluzione dei sistemi operativi (5) Evoluzione dei sistemi operativi (4) Classificazione dei sistemi operativi Evoluzione dei sistemi operativi (4) Sistemi multiprogrammati! più programmi sono caricati in contemporaneamente, e l elaborazione passa periodicamente dall uno all altro Evoluzione dei sistemi operativi

Dettagli

Reti basate sulla stack di protocolli TCP/IP

Reti basate sulla stack di protocolli TCP/IP Reti basate sulla stack di protocolli TCP/IP Classe V sez. E ITC Pacioli Catanzaro lido 1 Stack TCP/IP Modello TCP/IP e modello OSI Il livello internet corrisponde al livello rete del modello OSI, il suo

Dettagli

Indice REGIONE BASILICATA

Indice REGIONE BASILICATA DIPARTIMENTO PROGRAMMAZIONE UFFICIO SISTEMA INFORMATIVO REGIONALE E Via Vincenzo Verrastro n 4 fax 0971/668954 REGI ONE BASI UFFICIO S. I. LICA R. S. TA Piano dei Test Id Sistema APPROVAZIONI Redatto da:

Dettagli

Fornitura e gestione di un sistema Wireless cittadino in standard WI-FI Capitolato Tecnico

Fornitura e gestione di un sistema Wireless cittadino in standard WI-FI Capitolato Tecnico Fornitura e gestione di un sistema Wireless cittadino in standard WI-FI Capitolato Tecnico Comune di Prato Sistema Informativo e Statistica Versione 1.4 Obiettivo del progetto Il progetto ha come obiettivo

Dettagli

Programmazione modulare 2014-2015

Programmazione modulare 2014-2015 Programmazione modulare 2014-2015 Indirizzo: Informatica Disciplina: SISTEMI E RETI Classe: 5 A e 5 B Docente: Buscemi Letizia Ore settimanali previste: 4 ore (2 teoria + 2 laboratorio) Totale ore previste:

Dettagli

Auditing di Eventi. Daniele Di Lucente

Auditing di Eventi. Daniele Di Lucente Auditing di Eventi Daniele Di Lucente Un caso che potrebbe essere reale Un intruso è riuscito a penetrare nella rete informatica della società XYZ. Chi è l intruso? Come ha fatto ad entrare? Quali informazioni

Dettagli

Content Distribution Networks Digital Rights Management

Content Distribution Networks Digital Rights Management Content Distribution Networks Digital Rights Management Content Distribution Networks Digital Rights Management Angelo Duilio Tracanna LabOne Italia S.r.l. Amministratore Delegato angelo.tracanna@labone.net

Dettagli

Le reti e Internet. Corso di Archivistica e gestione documentale. Perché Internet? Non è tutto oro quello che luccica. Definizione di rete

Le reti e Internet. Corso di Archivistica e gestione documentale. Perché Internet? Non è tutto oro quello che luccica. Definizione di rete Corso di Archivistica e gestione documentale Prima Parte - Area Informatica Le reti e Internet Lezione 2 Internet Abbatte le barriere geografiche È veloce Ha costi contenuti È libero È semplice da usare

Dettagli

La Gestione Integrata dei Documenti

La Gestione Integrata dei Documenti Risparmiare tempo e risorse aumentando la sicurezza Gestione dei documenti riservati. Protezione dati sensibili. Collaborazione e condivisione file in sicurezza. LA SOLUZIONE PERCHE EAGLESAFE? Risparmia

Dettagli

Architetture di Cloud Computing

Architetture di Cloud Computing Corso di Laurea Magistrale in Ingegneria Informatica Corso di Ingegneria del A. A. 2013-2014 Architetture di Cloud Computing 1 Cloud computing Sommario Principali requisiti richiesti dal cloud clomputing

Dettagli

Laboratorio del corso Progettazione di Servizi Web e Reti di Calcolatori Politecnico di Torino AA 2014-15 Prof. Antonio Lioy

Laboratorio del corso Progettazione di Servizi Web e Reti di Calcolatori Politecnico di Torino AA 2014-15 Prof. Antonio Lioy Laboratorio del corso Progettazione di Servizi Web e Reti di Calcolatori Politecnico di Torino AA 2014-15 Prof. Antonio Lioy Soluzioni dell esercitazione n. 2 a cura di Giacomo Costantini 19 marzo 2014

Dettagli

IL PRIVATE CLOUD DELLA FRIENDS' POWER

IL PRIVATE CLOUD DELLA FRIENDS' POWER IL PRIVATE CLOUD DELLA FRIENDS' POWER Evoluzione al Cloud Computing Condivisione dei lavori Integrazione con Android & iphone Cos è il Cloud: le forme e i vantaggi Durante la rivoluzione industriale, le

Dettagli

Architettura dei sistemi di database

Architettura dei sistemi di database 2 Architettura dei sistemi di database 1 Introduzione Come si potrà ben capire, l architettura perfetta non esiste, così come non è sensato credere che esista una sola architettura in grado di risolvere

Dettagli

Nel presente documento viene descritto il processo di installazione e configurazione del client 4Copy su una generica piattaforma Windows XP.

Nel presente documento viene descritto il processo di installazione e configurazione del client 4Copy su una generica piattaforma Windows XP. Nota: Nel presente documento viene descritto il processo di installazione e configurazione del client 4Copy su una generica piattaforma Windows XP. Capitolo 1 Installazione del Client... 2 Download del

Dettagli

Evoluzione dei sistemi informatici

Evoluzione dei sistemi informatici Evoluzione dei sistemi informatici Cos è una rete? Insieme di calcolatori autonomi tra loro collegati mediante una rete di comunicazione Gli utenti sono in grado di interagire in modo esplicito con la

Dettagli

Controllo I/O Costituito dai driver dei dispositivi e dai gestori dei segnali d interruzione.

Controllo I/O Costituito dai driver dei dispositivi e dai gestori dei segnali d interruzione. C6. REALIZZAZIONE DEL FILE SYSTEM Struttura del file system Un file è analizzabile da diversi punti di vista. Dal punto di vista del sistema è un contenitore di dati collegati tra di loro, mentre dal punto

Dettagli

Realizzazione del file system

Realizzazione del file system Realizzazione del file system Struttura del file system Metodi di allocazione: Contigua Concatenata Indicizzata Gestione dello spazio libero Realizzazione delle directory Efficienza e prestazioni Ripristino

Dettagli

ACCESSNET -T IP NMS. Network Management System. www.hytera.de

ACCESSNET -T IP NMS. Network Management System. www.hytera.de ACCESSNET -T IP NMS Network System Con il sistema di gestione della rete (NMS) è possibile controllare e gestire l infrastruttura e diversi servizi di una rete ACCESSNET -T IP. NMS è un sistema distribuito

Dettagli

Systems Manager Gestione dei dispositivi mobili via cloud

Systems Manager Gestione dei dispositivi mobili via cloud Systems Manager Gestione dei dispositivi mobili via cloud Panoramica Systems Manager di Meraki offre funzioni via etere basate su cloud per la gestione, la diagnostica e il monitoraggio dei dispositivi

Dettagli

Multi-layer switch commutazione hardware a vari livelli. Mario Baldi. Politecnico di Torino. http://staff.polito.it/mario.baldi

Multi-layer switch commutazione hardware a vari livelli. Mario Baldi. Politecnico di Torino. http://staff.polito.it/mario.baldi Multi-layer switch commutazione hardware a vari livelli Mario Baldi Politecnico di Torino http://staff.polito.it/mario.baldi Basato sul capitolo 10 di: M. Baldi, P. Nicoletti, Switched LAN, McGraw-Hill,

Dettagli

Descrizione generale. Architettura del sistema

Descrizione generale. Architettura del sistema Descrizione generale Sister.Net nasce dall esigenza di avere un sistema generale di Cooperazione Applicativa tra Enti nel settore dell Informazione Geografica che consenta la realizzazione progressiva

Dettagli

Guida rapida per l utilizzo del servizio OwnCloud-MIUR (versione 1.6)

Guida rapida per l utilizzo del servizio OwnCloud-MIUR (versione 1.6) Sommario Introduzione... 2 L utilizzo dell OwnCloud con il browser.... 3 Istruzioni per l installazione del client OwnCloud... 4 Utilizzo del client OwnCloud per il caricamento dei giustificativi contabili....

Dettagli

e-connect Sistema di gestione, centralizzazione e supervisione degli impianti elmospa.com Global security solutions

e-connect Sistema di gestione, centralizzazione e supervisione degli impianti elmospa.com Global security solutions e-connect Sistema di gestione, centralizzazione e supervisione degli impianti elmospa.com Global security solutions e-connect A vanguardia tecnologica al servizio della sicurezza. Avvalendoci dell ormai

Dettagli