VIRTUALIZZAZIONE IN UN CLUSTER AD

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "VIRTUALIZZAZIONE IN UN CLUSTER AD"

Transcript

1 UNIVERSITÀ DEGLI STUDI DI CAMERINO FACOLTÀ DI SCIENZE E TECNOLOGIE Corso di Laurea Specialistica in Informatica Dipartimento di Matematica e Informatica VIRTUALIZZAZIONE IN UN CLUSTER AD ALTA DISPONIBILITÀ IN AMBIENTE LINUX Tesi di Laurea Sperimentale In Reti di Elaboratori Laureando Mirco Perini Relatore Prof. F. Marcantoni Anno Accademico

2 ho risalito il crepaccio della Sibilla ho lottato per onorare la mia Muta ho vigilato sulla gente delle Arance ho combattuto la guerra sotto la Lanterna ho trascinato amici fuori dal Niveo ho puntato i piedi guardando le Scintille ma il vero coraggio lo vedo in te.. in voi nella difficoltà d ella vita tutti i giorni se mai dovrò bere anch io da questo amaro calice spemo d aver il vostro stesso ardire. forza papà forza mamma

3 Ringraziamenti Vorrei ringraziare il Prof. Fausto Marcantoni per avermi seguito e consigliato nella realizzazione del progetto e nella stesura della tesi. Un ulteriore grazie va agli operatori e ai ragazzi della Ripartizione Servizi Informatici e Statistici dell Università degli Studi di Perugia, ed in particolare a Tiziano Micheli per aver ascoltato le mie noiose spiegazioni, a Giovanni Sabatini e Federico Giorgetti per la disponibilità e soprattutto a Marco Pallotta colui che mi ha permesso di diventare l amministratore di sistema che sono oggi. Un meritato ringraziamento va al compagno di questa fantastica avventura Dott. Carlo Manuali, alla Dott.sa Chiara Del Buono e alla sua crew per aver sopportato il mio nervosismo, a tutti i malati di nolannoparty, agli amici del fù GHS, a Maurino e a tutti i ragazzi della sua band per essere stati la colonna sonora di questa tesi ed infine a tutti coloro che con il loro affetto e la loro pazienza mi hanno sopportato ed hanno permesso per la terza volta che tutto questo si realizzasse. Grazie.

4 INDICE Indice INTRODUZIONE... VI CAPITOLO 1 SISTEMI DISTRIBUITI: GENERALITÀ ARCHITE TTUR A SIS TEM I OPER AT IV I TIP IC I DE I C LU S TER T IP O LO G IE D I C LU S TER... 8 CAPITOLO 2 L'ALTA DISPONIBILITÀ L IVE LLI D I D IS P ON IB IL ITÀ I L REQU IS ITO DE I C IN Q UE LE PRESTAZ IO N I NE LL'ALTA D ISP ON IB ILITÀ T IP O LO G IE D I C LU S TER IN ALT A D IS PO N IB ILIT À CAPITOLO 3 LA VIRTUALIZZAZIONE CONCETT I GE NER ALI I

5 INDICE 3.2 AS PE TTI FO ND AMENTALI RE QU IS IT I D I UN A M ACC H IN A V IR TUALE VIR TUAL MACH INE MON ITOR (VMM) FULL V IR TUALIZ AT IO N E PAR AV IR TU A LIZ AT ION B IN ARY TR ANS LAT ION E DYN AM IC RECOMP ILAT ION STRUTTUR A IN TER N A DELL'HYPER V IS OR V IR TUALIZZ AZ IO NE DE LL A CPU V IR TUALIZZ AZ IO NE DE LL A MEMOR IA V IR TUALIZZ AZ IO NE DE LLE PER IFER ICHE BENE F IC I DELLA V IR TUALIZZAZ IO N E PRINC IP A LI SO FTWAR E D I V IR TU A LIZZAZ IO N E CAPITOLO 4 REALIZZAZIONE DEL PROGETTO AN A LIS I DE L PR OB LE MA INS TALLAZ IO N E E CONFI GUR AZ IO NE DE I DUE NO DI CHANNE L B ON D IN G CON F IGU R AZIO NE DE LLO STOR AGE C ON D IV IS O T IPO LO G IE D I STORAGE CAR ATTER IS T IC HE D I DRBD I PROTOCOLLI D I S INCR O N IZZAZ IO N E INS TALLA Z IO NE E CON F IGUR AZ IO N E D I DRBD I L F ILE D I CONFIGUR AZ IO NE "DRBD.CONF" CON F IGU R AZ IO NE D I HE AR TBEAT LA STR U TTUR A D I HE AR TBEAT I PLU G IN D I HEARTBEAT I RE SO URCE GROUP INS TALLA Z IO NE E CON F IGUR AZ IO N E D I HE A RTBEAT CON F IGU R AZ IO NE DELLE V IR TUAL M ACH IN E INS TALLA Z IO NE E CON F IGU R AZ IO NE DI VMWARE SERVER INS TALLA Z IO NE DE LLE V IR TUAL MACH INE S INTE GR AZ IO NE D I TUTTO IL S IS TEM A T ESTIN G DE L PR O GE TTO II

6 INDICE CONCLUSIONI APPENDICE A - I FILE DEL S.O APPENDICE B - I FILE DI DRBD APPENDICE C - I FILE DI HEARTBEAT APPENDICE D - I FILE DI PROGETTO BIBLIOGRAFIA III

7 ELENCO DELLE FIGURE Elenco delle figure 2.1 P ROBAB ILI C AUSE D I DO WN TIME I COS TI DE LL' A LTA AF F ID AB ILIT À C LU S TER IN CONFIGUR AZ IO N E AC TIV E-STANDB Y C LU S TER IN CONFIGUR AZ IO N E AC TIV E-AC T IV E C LU S TER IN CONFIGUR AZ IO N E LO AD B A LANC IN G E SEMPIO D I V IR TU A LIZZ AZ IO NE M U LT IP LAZ IO NE TEMPORA LE NE GLI AMB IE N TI V IR TU A LI DE GLI AN N I SESSAN TA SCHEM A A LIV E LLI DE LL A S TRUTTUR A D I UN C A LC O LATORE SENZA V IR TUAL M AC H IN E SCHEM A D I UN C ALC O LAT ORE DO TATO D I MACCH INE V IR TU A LI S TRU TTUR A DE L V IR TUAL MACH INE MONITOR INTERCETTAZ IO N E DE LLE ECCEZIO N I DE L D IS P AT C HER S IS TEM A D I IN D IR IZZ AM E N TO DE LLA MEMOR IA N E L VMM M ASC HER AMENTO DE L LIVELLO H ARDWARE NEL VMM T ABELLA C OMPAR AT IV A D E I PR IN C IP A LI S O FTWA RE D I V IR TU A L IZZAZ IO N E FOTO DE L NO DO ALP H A FOTO DE L NO DO BRAVO SCHEM A DE L PROGE TTO D OP O L'IN S TALLA Z IO NE DE L CHANE LL B ON D IN G IMPOS TAZ IO NE D I DRBD PER L'AV V IO A L BOO T SCHEM A DE L PROGE TTO D OP O L' IN S TALLAZ IO NE D I DRBD SCHEM A DE I M O DU LI D I HE AR TBEAT M OD U LI ESTERN I D I HE A RTBEAT IMPOS TAZ IO NE D I HE AR TBEAT PER L' AV V IO AL BOOT IV

8 ELENCO DELLE FIGURE 4.9 SCHEM A DE L PROGE TTO D OPO L'IN S TALLAZ IO NE D I HEAR TBEAT LA F INE S TR A D I LO G IN D I VMWARE M AN AGEMENT INTER FACE LA SCHERM ATA IN IZ IA LE DI VMWARE SER VER CONSO LE FAS I IN IZ IA LI DE LLA C ON F IGUR AZ IO N E D I U N A VM CON VMWARE SER VER CON S O LE CONFIGU R AZ IO NE H AR D WA RE D I UN A VM CON VMWARE SERVER CO NS O LE INS TALLAZ IO N E DE L S IS TEM A O PER AT IV O IN U N A M ACCH IN A V IR TU A LE LE FAS I D I IN S TALLAZ I ONE DE I VMWARE T OO LS IN U N A MACCH IN A V IR TU A LE AVV IO D I HE AR TBEAT E TEST D I F U N ZIO N A LITÀ DE LLO SCR IP T REALIZZ ATO SCHEM A F IN A LE DE L PRO GE TTO FOTO DE L C LU S TER NELL A C ON F IGUR AZ IO NE DE F IN IT IV A LA MUI MOS TR A LO STATO DE LLE Q U ATTR O MACCH INE V IR TU A LI SU L NO DO A L P H A I L C LIE N T KM A IL MOSTR A LA SEQUE N ZA D I MESS AGG I D I U P E DO WN DE LLE M ACC H IN E V IR TU A LI SCHE D A DEL PROGE TTO A SE GU ITO DEL CR AS H S I MULATO V

9 INTRODUZIONE Introduzione Il presente lavoro di tesi è stato svolto presso l Area Servizi Tecnico- Sistemistici della Ripartizione Servizi Informatici e Statistici dell Università degli studi di Perugia. Il progetto ha avuto come scopo la ricerca, lo studio e l implementazione di una soluzione completamente open-source finalizzata alla virtualizzazione di alcune macchine, utilizzando come sistema ospite un Cluster composto da due nodi configurato per l erogazione di servizi in alta affidabilità (High Avaiability o HA). Nella sala macchine dell Ateneo, come in molte altre aziende, si è notato che diverse macchine server vengono utilizzate ampliamente al disotto delle loro potenzialità. Questo significa nella pratica che, per la maggior parte del tempo, il processore di tali macchine resta inutilizzato, in attesa che gli venga dato qualcosa da fare. Di fatto questa situazione rappresenta per l amministrazione un inutile spreco di risorse: gli investimenti finanziari effettuati per l acquisto di tali macchine e il tempo richiesto ai sistemisti per la loro gestione, potrebbero essere facilmente recuperati mediante un attento VI

10 INTRODUZIONE consolidamento, avente come fine ultimo l accorpamento in un unico server delle attività svolte da un insieme di macchine. Proprio sulla base dei principi appena illustrati, la Ripartizione Servizi Informatici e Statistici ha deciso attraverso questo lavoro di tesi di sperimentare la virtualizzazione di alcune delle sue macchine, ponendosi fondamentalmente due obiettivi: da un lato la minimizzazione delle spese necessarie alla realizzazione del progetto stesso e dall altro il miglioramento della qualità dei servizi offerti con particolare riferimento alla loro affidabilità. Nei capitoli iniziali verranno illustrate le caratteristiche fondamentali delle teorie alla base di questo lavoro. Nel primo capitolo si affronterà un analisi dei fondamenti e delle tipologie di sistemi distribuiti, soffermandosi in particolare sui sistemi operativi maggiormente utilizzati e sulle differenze tra cluster per il calcolo scientifico e cluster per l alta affidabilità. Nel secondo capitolo si proseguirà con una attenta descrizione dei diversi livelli di disponibilità, dei requisiti fondamentali, delle vari livelli prestazionali dell affidabilità e delle varie tipologie che caratterizzano un cluster in high avaiability. Nel terzo capitolo verranno affrontati i concetti basilari su cui si fondano le teorie della virtualizzazione: dagli aspetti fondamentali ai requisiti indispensabili per la sua attuazione. Nella parte conclusiva del capitolo verrà infine descritta, in modo dettagliato, l architettura alla base VII

11 INTRODUZIONE della virtualizzazione con particolare riferimento ai benefici introdotti da questa tecnica ed ai principali software utilizzati. Nel quarto e ultimo capitolo verrà affrontata la fase di analisi di questo lavoro di tesi, si cercherà di far capire il percorso logico e le motivazioni che hanno condotto alle scelte adottate all interno del progetto. Si partirà in principio con una panoramica delle potenziali soluzioni a disposizione, sia dal punto di vista software che da quello hardware, e si proseguirà poi con un dettagliato studio delle informazioni raccolte che porterà alla definizione delle scelte progettuali effettivamente adottate nella fase realizzativa. La seconda parte del capitolo è invece incentrato sull implentazione pratica del lavoro ed in particolare sull installazione e la configurazione degli strumenti scelti per la messa in opera del progetto. Il primo di questi strumenti è il modulo DRDB che, in combinazione con il meccanismo del channel bonding, fornisce ai sistemi operativi appartenenti al cluster, un dispositivo di memorizzazione di massa condiviso realizzato attraverso le partizioni dei dischi reali. Nei paragrafi seguenti verrà prima configurata la suite Heartbeat, indispensabile per garantire l alta disponibilità del sistema, e successivamente VMWare Server per la virtualizzazione. Nella parte conclusiva del capitolo verranno infine illustrate le modifiche necessarie per integrare gli strumenti mostrati e rendere operativo l intero progetto. Chiudono il lavoro di tesi una serie di appendici contenenti i file testuali relativi alla configurazione dei software utilizzati. VIII

12 SISTEMI DISTRIBUITI: GENERALITÀ Capitolo 1 1 Sistemi distribuiti: generalità Nonostante l informatica sia una scienza relativamente moderna è riuscita nel corso del tempo ad invadere ogni strato della società civile. Il suo sviluppo, avvenuto contestualmente all invenzione delle macchine in grado di eseguire calcoli in modo automatico ed in brevi lassi di tempo, ha consentito agli studiosi di addentrarsi in realtà prima di allora inesplorate. I primi computer erano in grado di risolvere solo problemi elementari, ma grazie alla ricerca e agli investimenti negli ambienti accademici e in quelli aziendali, la scienza informatica è stata progressivamente in grado di progettare elaboratori sempre più potenti, denominati supercomputer, capaci di risolvere problematiche sempre più evolute. La crescente richiesta di ingenti capacità elaborative in molti settori legati alla ricerca e all analisi di realtà complesse (scientifica, finanziaria, ecc ) condussero molte aziende a realizzare prodotti 1

13 SISTEMI DISTRIBUITI: GENERALITÀ informatici specializzati e progettati appositamente allo scopo ma a prezzi decisamente elevati. Il successivo avvento dell informatica personale e la creazione di ciò che può esserne ritenuto il suo simbolo, il personal computer (PC), portarono realtà consolidate come i supercomputer a diminuire la loro incidenza sul mercato. La diffusione dei PC a prezzi modesti indusse la richiesta di capacità di calcolo ad orientarsi verso soluzioni a basso costo; nacquero così software in grado di virtualizzare un gruppo di macchine, creando un unico sistema in grado di redistribuire il carico operativo su ogni singolo componente. Un gruppo di computer, uniti allo scopo di risolvere insieme un problema comune e visibili all utente come un unica macchina virtuale, viene definito sistema distribuito o cluster 1 Il paradigma alla base del sistema distribuito è assimilabile alla teoria del divide et impera, tipica degli studi sugli algoritmi, secondo la quale ogni problema può essere risolto con una scomposizione in sottoproblemi più piccoli, la cui risoluzione genera una parte della soluzione complessiva del problema primario. L applicazione di questo schema di ragionamento incorpora il concetto di modularità che 1 Un cluster (dall inglese grappolo) è un insieme di computer connessi tramite una rete telematica. Lo scopo di un cluster è quello di distribuire una computazione molto complessa tra i vari computer componenti il cluster. In sostanza un problema che richiede molte elaborazioni per essere risolto viene scomposto in sottoproblemi separati i quali vengono risolti in parallelo. Questo aumenta, ovviamente, la potenza di calcolo del sistema 2

14 SISTEMI DISTRIBUITI: GENERALITÀ caratterizza tutti i moderni sistemi di calcolo, in modo particolare i sistemi distribuiti. Un sistema distribuito, infatti, non è altro che un insieme di calcolatori identici che vengono comunemente definiti nodi. In un sistema di questo tipo si ha la possibilità di aggiungere o eliminare nodi generando rispettivamente un aumento oppure una diminuzione di potenza di calcolo complessiva dell intero sistema. Questa particolare caratteristica prende il nome di scalabilità. In generale un sistema si definisce scalabile quanto l aumento delle prestazioni di calcolo aumenta in modo proporzionale al numero di nodi del sistema. Secondo la definizione principale, un cluster è un sistema distribuito composto da un numero non specificato di singoli computer definiti processori o più semplicemente nodi, interconnessi tra loro da una rete di comunicazione privata utilizzata esclusivamente per la sincronizzazione dei dati e l interscambio di messaggi fra i processi in esecuzione e che condividono delle risorse locali o remote[1]. 1.1 Architettura In funzione della modalità con cui le risorse utilizzate dai nodi sono disposte e gestite, un sistema distribuito può essere principalmente distinto in due categorie[2]: 3

15 SISTEMI DISTRIBUITI: GENERALITÀ Sistemi Tightly Coupled o anche definiti Shared Memory, la cui caratteristica distintiva sta nel fatto che ogni singolo nodo del cluster condivide la medesima porzione di memoria, utilizzata anche per scopi di comunicazione e sincronizzazione; Sistemi Loosely Coupled, si differenziano dai precedenti per il fatto che ognuno dei nodi utilizza e gestisce autonomamente la propria memoria principale e lo scambio di informazioni tra i processi avviene mediante una tecnica denominata di Message Passing. La specializzazione che rivestono i diversi nodi all interno del cluster, classifica ulteriormente un sistema distribuito, consentendo di individuare dei modelli che meglio definiscono la tipologia di soluzione adottata. Fanno parte della categoria Tightly Coupled i sistemi definibili come minicomputer che in realtà non sono altro che sistemi dotati di un certo numero di processori che condividono le stesse risorse centralizzate mantenendo al contempo caratteristiche di scalabilità e modularità. La sincronizzazione delle operazioni e lo scambio di messaggi tra di essi avviene utilizzando aree della memoria principale ed ogni operazione d inserimento dati e consultazione viene realizzata utilizzando appositi terminali oppure workstation. Nella categoria Loosely Coupled possiamo individuare i seguenti modelli [3]: 4

16 SISTEMI DISTRIBUITI: GENERALITÀ workstation model: comprendono quei sistemi caratterizzati dalla presenza di un insieme di workstation che gestiscono autonomamente le proprie risorse e che sono dotate sia di un sistema di gestione dei processi locali, sia di un sistema per la gestione dei processi remoti in grado di spostare i processi sui nodi meno carichi; workstation-server model: è un modello caratterizzato dalla flessibilità del modello workstation model, dato che anch esso è costituito da un gruppo di workstation interconnesse, ma eredita anche i vantaggi del modello a minicomputer. Tale soluzione permette l esecuzione di operazioni generiche sulle workstation e di operazioni particolarmente specializzate sui minicomputer dedicati. I vantaggi forniti da questo modello possono essere di importanza rilevante, quando sono richiesti livelli di performance molto elevati, spesso infatti la scelta risulta obbligata. Grazie a questo modello, per esempio, è possibile centralizzare le risorse di memorizzazione di massa predisponendo un minicomputer come file server, al fine di fornire prestazioni eccellenti nell input/output dei dati, semplificare la manutenzione, evitare un traffico eccessivo nella migrazione dei processi dati ed eseguire elaborazioni remote attraverso protocolli di tipo client-server; 5

17 SISTEMI DISTRIBUITI: GENERALITÀ processor pool model: è caratterizzato dalla presenza di nodi generici non specializzati che vengono dinamicamente allocati dal sistema di gestione delle risorse e che vengono rappresentati esternamente con l immagine di un sistema singolo. L utente che deve utilizzare le risorse di calcolo del cluster, non si collega in modo diretto ai nodi, ma a terminali specializzati che non fanno parte del cluster. Pertanto la percezione che ne risulta è quella di collegarsi direttamente all interno del sistema. Per le sue caratteristiche di praticità ed efficacia, questo modello, risulta essere quello più diffuso tra gli attuali cluster adibiti al calcolo scientifico. 1.2 Sistemi Operativi tipici dei cluster Una parte cruciale nel corretto funzionamento dei sistemi distribuiti è svolta dal sistema operativo che deve essere in grado di consentire e favorire le operazioni tipiche eseguite da un cluster. Si possono in tal senso distinguere due classi di sistemi operativi per cluster denominati Network Operating System e Distributed Operating System. Le differenze fra i due possono essere individuate, in particolare, nell immagine che l utente percepisce dell intero sistema [4]. 6

18 SISTEMI DISTRIBUITI: GENERALITÀ Un Network Operating System coordina i diversi sistemi operativi presenti su ogni nodo, demandati alla gestione delle risorse locali, dando all utente la possibilità di conoscere quali sono i nodi che costituiscono il cluster, il loro stato e il nodo sul quale eseguire la computazione. Un Distributed Operating System invece si prende in carico la gestione dell onere di assegnamento del lavoro ai diversi nodi del cluster, fornendo all utente l immagine di un sistema unico. È evidente, in questo caso, che i malfunzionamenti di ciascun nodo vengono nascosti all utente, dato che egli stesso non conosce come il sistema è costruito. Un sistema operativo distribuito è estremamente complesso, sia perché deve consentire performance, scalabilità e affidabilità nella gestione dei suoi componenti, ma anche e soprattutto per la sicurezza che deve garantire sicurezza visto l utilizzo contemporaneo di diversi utenti. La necessità di utilizzare un sistema operativo con le caratteristiche appena esposte e nel contempo di abbattere i costi del software, ha fatto si che il sistema operativo GNU/Linux 2 giocasse un 2 Si noti la differenza tra le diciture Linux e GNU/Linux. La prima sta ad indicare il solo kernel del sistema operativo sviluppato originariamente da Linus Torvalds, la seconda indica invece l'insieme del kernel Linux e di svariati programmi open-source facenti capo al progetto GNU il cui padre è Richard Stallman. Spesso questo insieme più o meno esteso può costituire una distribuzione Linux creata da chiunque ed eventualmente messa in vendita. A volte si dice Linux per riferirsi erroneamente ad una intera distribuzione quando invece il termine Linux sta ad indicare il solo kernel. 7

19 SISTEMI DISTRIBUITI: GENERALITÀ ruolo chiave per la definizione e l implementazione di modelli di clustering. GNU/Linux è un sistema UNIX-Like notoriamente orientato alle reti e che ha come vantaggio non trascurabile, oltre alla stabilità e l efficienza tipica di tutti i sistemi *NIX, il fatto di essere completamente open-source e quindi generalmente gratuito. È evidente come la caratteristica open-source di tali prodotti sia garanzia di trasparenza e stabilità, per il fatto che chiunque può analizzare, modificare e correggere il codice sorgente. 1.3 Tipologie di cluster Un cluster può, in generale, essere visto come un insieme di nodi ognuno dei quali è un fornitore di servizi per tutto l insieme. All interno del cluster si avranno quindi diverse tipologie di nodi con specifici compiti per la collettività come File Server, Batch Server, Tape Server o nodi che offrono servizi specializzati come NIS, DNS, Web, Mail, FTP e così via. Per passare da un insieme di sistemi interconnessi ad un cluster sono necessari almeno tre elementi: un meccanismo di condivisione delle informazioni amministrative; 8

20 SISTEMI DISTRIBUITI: GENERALITÀ un architettura con forte centralizzazione delle immagini di sistema (auspicabile ma non essenziale); un meccanismo di gestione della schedulazione di richieste delle risorse. Quest ultimo punto (insieme alla distribuzione sui vari nodi di tali richieste) è il primo valore aggiunto che deve essere previsto dopo lo startup iniziale. Ovviamente la topologia del cluster e soprattutto la sua architettura vanno selezionate in base alle diverse esigenze degli utilizzatori ed al particolare contesto in cui si viene ad operare. Mentre un responsabile IT (Information Technology) potrebbe essere interessato al mantenimento della massima affidabilità dei propri server o alla diminuzione del tempo generale di esecuzione delle applicazioni e dei servizi di punta della sua organizzazione, un fisico delle alte energie potrebbe essere interessato alla simulazione su larga scala o alla disponibilità di enormi quantità di dati sperimentali fisicamente distribuiti suwan. In definitiva la distinzione fondamentale sulle tipologie di cluster è legata essenzialmente alle finalità cui il cluster è destinato, si possono quindi individuare almeno quattro categorie distinte [5]: cluster per l affidabilità dei servizi; cluster per l alta disponibilità dei servizi (High Avaiability oppure HA) 9

21 SISTEMI DISTRIBUITI: GENERALITÀ cluster per il bilanciamento del carico (Load Balancing oppure LB); cluster per il calcolo parallelo. Cluster per l affidabilità dei servizi Tale soluzione prevede la predisposizione di un insieme di sistemi che devono mantenere copie separate dei servizi e che rispondono comunque ad un unico nome host virtuale con il quale i client interrogano il singolo servizio. Essenzialmente, avendo a disposizione un cluster con forte centralizzazione delle immagini di sistema e di quelle applicative, diverse tipologie di servizi di rete si prestano per far sì che ogni singolo nodo del cluster possa, nel caso si renda necessario, diventare un nodoservizio. Questo permette di avere una scalabilità dei servizi a costi irrisori rispetto ad un eventuale cambio architetturale (ad esempio da low ad high level server). Il punto cruciale di questo modello è il servizio di virtualizzazione dei nomi macchina a livello DNS (fino ad arrivare a criteri avanzati di load balancing) e la gestione del carico della rete (attuabile con l introduzione di router in grado di effettuarne il bilanciamento del carico). 10

22 SISTEMI DISTRIBUITI: GENERALITÀ Cluster per l alta disponibilità dei servizi Se il modello di affidabilità risponde alla domanda di scalabilità, quello di alta disponibilità risponde alla domanda di continuità di servizio, puntando sull eliminazione dei punti deboli del sistema comunemente definiti single point of failure. Un cluster per l alta disponibilità (HA cluster) è costituito essenzialmente da due (o più) server gemelli, nei quali meccanismi hardware e software permettono di far sì che se il nodo principale del cluster HA si blocca, il nodo secondario, fino a quel momento in attesa, si riconfiguri per apparire come il nodo principale del cluster, con un immagine congrua al nodo originale immediatamente prima della sua indisponibilità (ovvero senza perdite di dati sensibili). All utente finale, attraverso complessi algoritmi per la determinazione delle variazioni di stato dei sistemi, l intero processo di riconfigurazione apparirà come una breve indisponibilità temporanea del servizio. Tale modello è particolarmente indicato per tipologie di servizi come File Server, Web Server o Database Server. Cluster per il bilanciamento del carico Un load balancing cluster può essere un incomparabile strumento di produttività. L idea (che estende il modello di affidabilità) è quella di introdurre un sotto-sistema di schedulazione delle richieste applicative, 11

23 SISTEMI DISTRIBUITI: GENERALITÀ ad esempio un sistema di code che sia in grado di reindirizzare la richiesta sul nodo più scarico, in grado di far fronte alla richiesta utente. I sotto-sistemi di questo tipo solitamente sono dotati di vari strumenti amministrativi che permettono un controllo molto fine sull utilizzo delle risorse e che consentono un monitoraggio avanzato dello stato del cluster. L asintoto attuale di questo modello è rappresentato dalla possibilità di includere a livello kernel i meccanismi di schedulazione, la gestione dello spazio globale delle risorse (file system e processi) e la gestione delle politiche di bilanciamento del carico e della migrazione dei processi. Cluster per il calcolo parallelo La ragione principale per cui molti sforzi si sono concentrati verso lo sviluppo di architetture cluster per il calcolo parallelo basate su PC sono i costi. In questo modo, invece di rincorrere a colpi di milioni di dollari l ultimo supercomputer in grado di far fronte alle sempre maggiori richieste di TeraFlops (trilioni di operazioni in virgola mobile per secondo), si è sempre più affermata l idea di assemblare grandi quantità di processori classe PC con una struttura di comunicazione a banda larga e bassa latenza, appositamente progettata. 12

24 SISTEMI DISTRIBUITI: GENERALITÀ Per mantenere tali caratteristiche a volte viene utilizzato un protocollo di rete diverso dal TCP/IP (come ad esempio Myrinet), che contiene troppo overhead rispetto alle limitate esigenze di indirizzamento, routing, e controllo nell ambito di una rete di cui i nodi siano ben noti a priori. In alcuni casi viene utilizzato un meccanismo di Direct Memory Access (DMA) fra i nodi, fornendo una sorta di distribuited shared memory che può essere acceduta direttamente da ogni processore su ogni nodo. È previsto, inoltre, un livello di comunicazione a scambio di messaggi (message passing) per la sincronizzazione dei nodi, le cui implementazioni più diffuse sono rappresentate da MPI (Message Passing Interface), OpenMP (Open Message Passing) e PVM (Parallel Virtual Machine). MPI è una API (Application Program Interface) per gli sviluppatori di programmi paralleli che garantisce una piena astrazione dell hardware correntemente utilizzato senza alcuna necessità di inserire nel codice del programma alcuna direttiva di effettiva distribuzione dei segmenti di codice fra i nodi del cluster garantendo, fra l altro, una buona portabilità del codice prodotto. PVM permette ad un insieme di computer di essere visto come una singola macchina parallela; la Parallel Virtual Machine è composta da 13

25 SISTEMI DISTRIBUITI: GENERALITÀ due entità principali: il processo PVM daemon su ogni processore e l insieme delle routine che ne forniscono il controllo [6]. 14

26 L ALTA DISPONIBILITÀ Capitolo 2 2 L alta disponibilità Nel corso del capitolo si cercherà di chiarire in profondità il concetto di alta disponibilità. Si tenga presente che lo scopo di un sistema in High Avaiability, o in sintesi HA, è nella pratica quello di fornire la capacità di fault tolerance 3 all erogazione di un servizio. Tale funzionalità può ritenersi cruciale ed indispensabile per servizi di particolare importanza ma, grazie ad un progressivo abbattimento dei costi di realizzazione derivati dall utilizzo di hardware ad ampia diffusione in congiunzione con la nascita di software open-source e gratuito, si può scegliere di dotare di tale funzionalità anche servizi che non sono particolarmente critici. 3 Con il termine fault tolerance (letteralmente tolleranza ai guasti ) si intende la capacità di un sistema di non subire fallimenti ovvero interruzioni di servizio, anche in presenza di guasti. È importante notare che la tolleranza ai guasti non garantisce l immunità da tutti i guasti, ma solo che i guasti per cui è stata progettata una determinata protezione non causino fallimenti. 15

27 L ALTA DISPONIBILITÀ 2.1 Livelli di disponibilità La disponibilità di un servizio può essere definita come una serie stratificata di livelli concentrici, ed ognuno dei quali include il precedente e lo estende con nuove funzionalità, essi possono essere schematizzati nel seguente modo [7]: Livello 1: Disponibilità normale. Rappresenta il livello minimo di disponibilità. L unica protezione contro eventuali interruzioni nell erogazione del servizio è il backup dei dati, eseguito secondo una politica decisa e posta in essere dall amministratore di sistema. Risulta evidente che in caso di guasto con il successivo ripristino del sistema e delle informazioni gestite, potrebbe essere possibile ottenere solo parte dei dati, che risulterebbero così aggiornati in modo incompleto (in funzione della frequenza con cui vengono eseguiti e conservati i backup). È altresì ovvio che l erogazione del servizio potrà essere ripresa solamente quando l amministratore avrà completato il restore dell intero sistema e riterrà sicuro e opportuno riprendere l erogazione del servizio agli utenti. Il tempo di ripresa dell attività è pertanto inevitabilmente legato ad un fattore umano. Attente analisi, svolte nell ambito di questa problematica, hanno dimostrato che in situazioni critiche, quali il ripristino di un sistema 16

28 L ALTA DISPONIBILITÀ informativo, l incidenza dell errore umano aumenta in modo esponenziale, dilatando ulteriormente i tempi potenziali per la ripresa del servizio. Livello 2: Media disponibilità con protezione dei dati. Lo scopo di un sistema, in grado di garantire questo livello di disponibilità, è quello di garantire un miglior livello di aggiornamento dei dati anche in caso di guasto di uno o più dischi (in funzione del tipo di tecnologia utilizzata). Tale obiettivo è raggiunto attraverso la replicazione fisica dei dati memorizzati sui dischi attraverso una tecnologia definita RAID 4. Anche in questa situazione, come in quella presentata precedentemente, è possibile mantenere i dati aggiornati anche nell eventualità di danni lievi ai dispositivi di memorizzazione di massa in uso. Tuttavia la ripresa dell erogazione piena del servizio dipenderà comunque, seppure in modo minore, dalla disponibilità dell amministratore di sistema che dovrà intervenire manualmente per riportare la funzionalità allo stato normale. Livello 3: Alta disponibilità con protezione del sistema. Questo livello garantisce la protezione del sistema e l erogazione dei servizi ad esso collegati, anche in caso di guasto di una porzione particolarmente significativa del 17

29 L ALTA DISPONIBILITÀ sistema. Risulta evidente come questo livello rappresenti un notevole salto di qualità rispetto ai quelli appena presentati. In soluzioni di questo tipo non si è più dipendenti dal livello di disponibilità dell amministratore di sistema e soprattutto la ripresa dell erogazione del servizio non è più vincolata ad eventuali errori umani. Un sistema implementato secondo queste specifiche è costituito da un cluster di almeno due nodi, configurati in modo che il secondo intervenga automaticamente prendendo il posto del primo, nel caso in cui quest ultimo non fosse più in grado di erogare il servizio per un evento casuale (rottura di un componente hardware) oppure previsto (manutenzione programmata del sistema). Livello 4: Disaster Recovery con protezione del sito. Questo livello, che rappresenta l evoluzione dell alta disponibilità, permette di mettere al riparo i dati anche da eventi che comportino la distruzione dell intero sito nel quale sono fisicamente collocate le macchine. Essenzialmente, si procede con una replicazione dell intera infrastruttura di sistema e dei dati in essa contenuti, in un area dislocata geograficamente lontano, più o meno distante in funzione del livello di fault tolerance che si vuole ottenere. 4 RAID: Acronimo di Redundat Array of Inexpensive Disk. Sistema di sicurezza che consente la registrazione simultanea su più memorie degli stessi dati. 18

30 L ALTA DISPONIBILITÀ Al fine di comprendere a fondo i motivi che impongono il ricorso all alta disponibilità nell erogazione di un servizio, si riporta una statistica redatta dall IEEE 5, che mostra le classiche cause di downtime di un sistema di elaborazione [36][4]. 15,00% 10,00% 30,00% 5,00% Malfunzionamenti Software Downtime Pianificati Persone Hardware Ambiente 40,00% Figura 2-1 Probabili cause di downtime. Come si evince dal grafico, la causa principale di inattività dei sistemi informatici è un malfunzionamento software che per sua natura è praticamente impossibile da prevedere in quanto concerne errori di 5 IEEE: acronimo di Institute of Electrical and Electronic Engineers. Organismo Americano che nasce nel 1963 dalla fusione di due istituzioni precedenti: l IRE (Institute of Radio Engineers) e l AIEE (American Institute of Electic Engineers). Scopo fondamentale è la promozione, lo sviluppo e l applicazione di tecnologie e 19

31 L ALTA DISPONIBILITÀ programmazione che si verificano unicamente in presenza di certe condizioni ignote a priori. Sulla base di questa analisi risulta evidente quindi che fornire un servizio con la probabilità che quattro volte su dieci si interrompa, non è di certo incoraggiante. Proprio per questo motivo l adozione di un cluster in alta disponibilità ben configurato, può ridurre drasticamente le percentuali indicate nel grafico, eliminando i punti deboli del sistema definiti SPF (Single Point of Failure). 2.2 Il requisito dei cinque 9 Un sistema in alta disponibilità viene tipicamente classificato sulla base di tre fattori: il tempo di disponibilità del servizio; le prestazioni complessive del sistema; l economicità totale del sistema implementato. È evidente come il tempo di disponibilità del servizio sia quello che maggiormente caratterizza un sistema ad alta disponibilità. Proprio per questo motivo uno dei parametri presi generalmente in considerazione è il tempo di disponibilità garantita [4] definito come il rapporto scienze per il beneficio dell umanità attraverso la definizione di standard internazionali. 20

32 L ALTA DISPONIBILITÀ percentuale fra il tempo di erogazione effettiva del servizio ed il tempo di osservazione. L obiettivo ideale di ogni sistema ad alta disponibilità è quello di raggiungere la fatidica soglia dei cinque 9, ovvero un tempo di erogazione effettiva del servizio pari al 99,999% del tempo totale di osservazione. Se prendiamo in considerazione un tempo di osservazione pari ad un anno solare, si ricava facilmente che il tempo massimo consentito per la sospensione del servizio è di soli 5 minuti e 15 secondi, che equivalgono ad una media settimanale di 6 secondi. Tale valore è un traguardo estremamente arduo da raggiungere, e sino a pochi anni fa era raggiungibile solamente con implementazioni ad appannaggio di grandi aziende specializzate nella creazione di sistemi ad alta disponibilità e con grande impiego di risorse finanziarie. Con l affermarsi negli ultimi anni, in modo sempre più marcato, della filosofia open-source, ed in particolare con la diffusione dei sistemi operativi GNU/Linux, sono stati creati diversi strumenti gratuiti per la realizzazione dell alta disponibilità in grado di avvicinarsi alla fatidica soglia del 99,999% di uptime del servizio. I tempi di sospensione di un servizio, ammissibili secondo la percentuale di erogazione del servizio stesso, sono riassunti nella tabella seguente: 21

33 L ALTA DISPONIBILITÀ Percentuale Uptime Downtime per anno Downtime per settimana 98,00% 7,3 giorni 3 ore, 22 minuti 99,00% 3,65 giorni 1 ora, 41 minuti 99,80% 17 ore e 30 minuti 20 minuti, 10 secondi 99,90% 8 ore e 45 minuti 10 minuti, 5 secondi 99,99% 52 minuti, 30 secondi 1 minuto 99,999% 5 minuti, 15 secondi 6 secondi 99,9999% 30,5 secondi 0,6 secondi Tabella 2-1 Tempi di sospensione in base alla percentuale di erogazione. Figura 2-2 I costi dell alta affidabilità [43]. Per ottenere percentuali di uptime sempre più elevate, è indispensabile analizzare nel dettaglio l infrastruttura che si desidera realizzare mirando all eliminazione progressiva di ogni single point of failure, ovvero tutti gli elementi la cui compromissione porterebbe ad un inevitabile collasso dell intera struttura, interrompendo pertanto l erogazione del servizio stesso. 22

34 L ALTA DISPONIBILITÀ Le possibili soluzioni a questo problema sono essenzialmente di due tipi: si può procedere con l introduzione della ridondanza dell hardware chiave del sistema, oppure si possono adottare soluzioni clusterizzate. L introduzione di componenti ridondati nel sistema, sebbene migliori il livello di disponibilità medio del servizio, non pone al riparo da diverse tipologie di guasto ed implica, se estremizzata, un incremento smisurato dei costi di realizzazione. A dimostrazione di quanto esposto si prenda in considerazione la ridondanza di componenti relativamente economici quali le schede di rete, gli hard disk o gli alimentatori, questo può portare ad avere considerevoli vantaggi in termini di disponibilità con un leggero aggravio in termini finanziari pari solo al 1-2% del costo totale del sistema. Se si cerca però di ridondare componenti chiave quali CPU, moduli di memoria RAM o controller RAID del sistema i costi possono lievitare fino al % del costo del sistema base. Come si può facilmente comprendere, un sistema così configurato diviene poco conveniente in termini economici ed induce alla ricerca di implementazioni alternative in grado di offrire gli stessi livelli di disponibilità a costi decisamente più ridotti. Con il passare degli anni e con l evoluzione delle tecniche di programmazione sia nei software che nei sistemi operativi, si sono creati programmi in grado di trasformare una collezione di due o più 23

35 L ALTA DISPONIBILITÀ personal computer in un sistema server virtuale in grado di erogare i suoi servizi con livelli di continuità conformi alla fatidica soglia dei cinque 9. Tale tecnica prende il nome di clustering HA (High Avaiability) ed attualmente è talmente diffusa da essere presente in ogni reparto dell Information Tecnology (IT). Aziende del calibro di Google, Porsche, Sony, Motorola e FedEX stanno utilizzando da anni sistemi basati sulla tecnologia Linux Virutal Server (ed in particolare Linux- HA) all interno di diverse sezioni critiche della loro infrastruttura informatica. Il segreto di tale diffusione è da ricercarsi, probabilmente, nella semplicità dell idea che sta alla base di tale soluzione ad alta disponibilità. Nell implementazione più semplice si hanno due macchine gemelle che sono in grado di erogare in modo intercambiabile un determinato insieme di servizi e che, attraverso un software di analisi dello stato dei servizi, sono in grado di commutare l erogazione del servizio stesso da un server ad un altro. In questo modo se una delle macchine viene danneggiata mentre sta fornendo un servizio, ad esempio a causa della rottura di un componente hardware, il sistema automaticamente provvede a spostare l erogazione del servizio sul server superstite, escludendo dall intera infrastruttura la macchina danneggiata. 24

36 L ALTA DISPONIBILITÀ L affinamento di questi passaggi ed alcune accortezze in termini di implementazione del servizio permettono di non far percepire il guasto all utente che non noterà discontinuità nell erogazione del servizio. 2.3 Le prestazioni nell alta disponibilità Altra caratteristica non trascurabile di un sistema in alta disponibilità sono le prestazione complessive nell erogazione del servizio. In base ad alcuni studi condotti sull argomento da diverse aziende, ed in particolare dal Gartner Group e dalla Forresters 6, si evidenzia che il tempo di attesa tollerabile dagli utenti dopo aver effettuato la richiesta di un servizio va dai 4 ai 20 secondo in funzione del tipo di applicazione. Considerando questi dati, per rendere l erogazione di un servizio sufficientemente continua è necessario che in caso di malfunzionamenti legati al server, il tempo di recovery non superi di molto la soglia prefissata. Si consideri inoltre che il tempo di risposta di una singola transazione comprende, non solo il tempo di elaborazione effettiva, che è l unico sul quale si possono fare interventi 6 Gartner Group (www3.gartner.com), Forrester (www.forrester.com), sono enti di ricerca e analisi che svolgono indagini sui più disparati argomenti: analisi di mercato, analisi delle tendenze comuni e di comportamento. 25

37 L ALTA DISPONIBILITÀ diretti, ma anche i tempi legati all ampiezza di banda del sistema di comunicazione fra il client e il server, e la latenza dei dispositivi. Inoltre deve essere garantita una qualità nell erogazione del servizio indipendente dal numero degli utenti che contemporaneamente lo richiedono: in altri termini il sistema deve essere dimensionato in modo tale da supportare il numero massimo di utenti che probabilmente possono richiedere il servizio in contemporane. Questo fattore impone dunque la disponibilità di potenza elaborativa che sia adeguata e facilmente e velocemente scalabile per far fronte ad esigenze crescenti nel futuro. Adottando una soluzione di ridondanza dei componenti, il problema viene risolto potenziando l hardware a disposizione, sostituendo e aggiornando le periferiche che costituiscono il collo di bottiglia 7 del sistema. Questo induce però un aumento dei costi di installazione oltre che una scarsa adattabilità dell intera infrastruttura all aumento del carico computazionale. La soluzione cluster, ancora una volta, mostra di poter risolvere il problema in modo più efficiente ed economico; infatti la scalabilità delle prestazioni del sistema viene ottenuta aumentando il numero dei server sui quali è distribuito il carico di lavoro oppure aggiornando i server utilizzati [4]. 7 In ambito informatico con l espressione collo di bottiglia si indica un componente hardware o software di un sistema di elaborazione che condiziona il resto del sistema a prestazioni non efficienti. 26

38 L ALTA DISPONIBILITÀ 2.4 Tipologie di cluster in alta disponibilità Scendendo maggiormente in dettaglio, a seguito di tutte le considerazioni fatte fin qui, si distinguono due tipologie di cluster ad alta disponibilità utilizzabili per l erogazione di servizi: Cluster Active-Standby (A-S) o Active-Active (A-A); Cluster a bilanciamento di carico (Load Balancing cluster). Nella tipologia di cluster Active-Standby i servizi offerti sono tutti residenti su un solo nodo, vengono poi presi totalmente in carico dall altro nodo, precedentemente in standby, nel momento in cui il nodo principale dovesse cadere. ACTIVE STANDBY Web Server Database Server ACTIVE ACTIVE Web Server Database Server Web Server Database Server Figura 2-3 Cluster in configurazione Active-Standby. 27

39 L ALTA DISPONIBILITÀ Nel modello Active-Active i servizi sono invece distribuiti su entrambi i nodi, i quali si compensano a vicenda nel caso uno dei due dovesse bloccarsi, prendendo in carico il lavoro di quel nodo in difficoltà. ACTIVE ACTIVE Web Server Database Server ACTIVE ACTIVE Web Server Database Server Web Server Figura 2-4 Cluster in configurazione Active-Active. Il software che realizza queste configurazioni fra i nodi è in grado di riconoscere lo stato dell erogazione dei servizi e del funzionamento dei nodi e quindi agire di conseguenza per far passare i servizi da un nodo all altro attraverso la migrazione dello storage, degli eventuali indirizzi IP e la riattivazione degli stessi sull altro nodo. Il tutto avviene in maniera del tutto trasparente per l amministratore che interviene solamente per riportare il cluster nello stato di funzionamento standard, 28

40 L ALTA DISPONIBILITÀ ma senza che il servizio erogato abbia subito interruzioni di qualsiasi tipo. Un cluster per il bilanciamento del carico è costituito, a differenza dei precedenti, da un pool di nodi opportunamente configurati per consentire la suddivisione dinamica e bilanciata del carico di lavoro computazionale. Load Balancing LAN / WAN Web Server 1 Web Server 3 Web Server 2 Figura 2-5 Cluster in configurazione Load Balancing. In tale configurazione uno dei nodi assume un ruolo specializzato, in quanto assolve alla funzione di dispatcher e ha quindi la facoltà di ripartire tra i nodi generici il lavoro. Esso infatti è costantemente consapevole del carico presente su ogni nodo e, in base alla politica 29

41 L ALTA DISPONIBILITÀ scelta per la ripartizione, distribuisce i processi da elaborare in modo opportuno. Il trasferimento dei pacchetti dalla macchina che funge da load balancer agli altri nodi incaricati di una certa elaborazione può avviene con tecniche diverse che comprendono il Direct-Redirect, il NAT (Network Address Translation) o l IP-Tunneling. E evidente che un cluster di questo tipo offre oltre che il bilanciamento del carico e la scalabilità, per via della possibilità di aggiungere nodi generici in ogni momento, la caratteristica di faulttolerance in quanto se uno dei nodi generici dovesse per qualunque problema rendersi non disponibile verrebbe automaticamente trascurato e indirettamente verrebbe messo fuori dal cluster. L alta disponibilità viene realizzata completamente utilizzando per il nodo dispatcher un cluster del tipo Active-Standby, eliminando così il single point of failure. Naturalmente un servizio di questo tipo si rende necessario solo nel caso in cui il carico al quale viene sottoposto il server è decisamente elevato, come può accadere per un web server aziendale. In definitiva dunque l architettura cluster è molto vantaggiosa per realizzare l alta disponibilità dei servizi erogati, è in grado di fornire scalabilità nelle prestazioni se si utilizza la tipologia di cluster che consente il load balancing e non ultimo risulta essere molto più economica rispetto a soluzioni diverse che offrono le stesse 30

42 L ALTA DISPONIBILITÀ caratteristiche, soprattutto in considerazione del fatto che il software che ne permette l implementazione può essere reperito in modo gratuito oltre che open-source. 31

43 LA VIRTUALIZZAZIONE Capitolo 3 3 La virtualizzazione Il concetto di virtualizzazione è uno dei più pervasivi e utilizzati in informatica. In [8] la virtualizzazione viene definita come: [ ] a framework or methodology of dividing the resources of a computer into multiple execution environments, by applying one or more concepts or technologies such as hardware and software partitioning, time-sharing, partial or complete machine simulation, emulation, quality of service, and many others. In particolare, la virtualizzazione definisce e implementa un livello di astrazione rispetto alle risorse del computer: questo livello di astrazione media tra le risorse fisiche del computer e il software che le utilizza. Questa strategia permette di creare, all interno della stessa macchina fisica, più ambienti di esecuzione virtuali (le macchine virtuali) che emulano il comportamento della macchina reale sottostante, mettendo a 32

44 LA VIRTUALIZZAZIONE disposizione dei livelli superiori l interfaccia esportata dall hardware della macchina. Negli ultimi anni questa tecnologia è stata rivalutata, soprattutto perché dà la possibilità di eseguire simultaneamente sulla stessa macchina fisica diverse istanze di sistemi operativi. Ad esempio, è possibile eseguire Linux, Windows e Solaris in concorrenza sulla stessa macchina, sfruttando l esistenza di diverse macchine virtuali all interno delle quali è possibile eseguire sistemi operativi (vedi fig. 3-1). LINUX WINDOWS CPU MEM DISCO CPU MEM DISCO MACCHINA VIRTUALE MACCHINA VIRTUALE SOFTWARE DI VIRTUALIZZAZIONE CPU MEMORIA DISCO MACCHINA REALE Figura 3-1 Esempio di virtualizzazione. Il software di virtualizzazione è in grado di tenere traccia dello stato di ogni sistema operativo in esecuzione nelle macchine virtuali, in maniera simile a quella con cui un sistema operativo tradizionale tiene traccia dello stato dei processi e, inoltre, fornisce protezione e isolamento tra le macchine virtuali [9]. 33

45 LA VIRTUALIZZAZIONE Non solo si hanno benefici in termini economici, per cui, ad esempio, è possibile consolidare su una macchina fisica diversi server, ma altresì si hanno benefici in termini di controllo centralizzato degli ambienti virtuali. È possibile salvare lo stato delle macchine virtuali o sospendere l esecuzione per poi ripristinarla successivamente, oppure si può migrare una macchina virtuale tra diverse macchine fisiche. 3.1 Concetti generali Le prime macchine virtuali furono implementate negli anni sessanta dalla IBM con lo scopo di creare più ambienti di lavoro su un unico calcolatore. Ogni macchina virtuale era una copia del sistema ospitante. Istanziando più macchine virtuali si avevano a disposizione diversi calcolatori (virtuali) pronti all uso. L obiettivo di questo meccanismo era ottimizzare l utilizzo del calcolatore reale (all epoca molto oneroso) permettendo allo stesso tempo il suo utilizzo da parte di più utenti in contemporanea. Le risorse del calcolatore venivano condivise fra gli ambienti virtuali creati attraverso una forma di multiplazione temporale simile a quella che avviene nei moderni sistemi operativi tra i processi (vedi fig. 3.2). Esistono anche altri tipi di macchine virtuali che non sono incentrate sull utilizzo condiviso di un calcolatore. Esse hanno lo scopo di 34

46 LA VIRTUALIZZAZIONE effettuare il porting, cioè l adattamento, di applicazioni e sistemi operativi tra calcolatori con architetture diverse. Sistema Operativo 1 Sistema Operativo 2 Sistema Operativo 3 Sistema Operativo 1 Sistema Operativo 2 t Figura 3-2 Multiplazione temporale negli ambienti virtuali degli anni sessanta. Ogni architettura hardware risponde a determinate specifiche descritte dalle ISA (Instruction Set Architecture) che possiamo descrivere come l interfaccia di presentazione dell architettura verso i propri utilizzatori. I sistemi operativi e le applicazioni che devono lavorare con una determinata architettura conoscono e rispettano solo quella determinata ISA. Questo rende praticamente impossibile la portabilità dei sistemi operativi fra le diverse architetture [10]. Per ovviare a questo problema esistono quindi particolari macchine virtuali in grado di imitare architetture diverse da quella del sistema operativo. Interponendo queste macchine virtuali fra il calcolatore ospitante ed il sistema operativo impossibilitato a girare su tale architettura si crea una nuova interfaccia in grado di tradurre le istruzioni tra le due ISA. Riepilogando, esistono due grandi famiglie di macchine virtuali con obiettivi ben diversi: 35

47 LA VIRTUALIZZAZIONE Condivisione delle risorse hardware di un calcolatore; Emulazione di architetture hardware diverse da quelle in possesso. In generale un obiettivo esclude l altro poiché, come sarà possibile vedere, emulare totalmente una architettura diversa è molto dispendioso eliminando di fatto la possibilità di prevedere altre macchine virtuali istanziate contemporaneamente. Allo stesso modo, la ricerca di prestazioni elevate in modo da poter avviare simultaneamente più macchine virtuali implica l introduzione di macchine virtuali che emulano solo in parte un calcolatore fisico, che di conseguenza devono essere simili. 3.2 Aspetti fondamentali La progettazione di un sistema complesso è facilitata da un approccio a livelli di astrazione. In questo modo è possibile progettare una parte del sistema senza considerare i dettagli delle altre parti. Ogni livello di astrazione è rappresentato ai livelli superiori attraverso una interfaccia che ne rappresenta il funzionamento senza scendere nei dettagli implementativi e costrutti del livello, si può pertanto dividere la struttura di un calcolatore in tre livelli di astrazione (vedi fig. 3.3). 36

48 LA VIRTUALIZZAZIONE Applicazione Utente Applicazione Utente API Sistema Operativo ISA Hardware Figura 3-3 Schema a livelli della struttura di un calcolatore senza virtual machine. Il livello hardware comprende la parte fisica del calcolatore (CPU, memoria, dispositivi di I/O, ecc ). Esso viene interfacciato ai livelli superiori attraverso le ISA (Instruction Set Architecture) cioè un insieme di istruzioni macchina proprie di una architettura con cui è possibile interagire con il livello hardware stesso. I livelli successivi sono di tipo software ovvero non hanno nessun tipo di rappresentazione tangibile. Il primo di questi è il sistema operativo che possiamo definire come l applicazione che sta a più vicino contatto con il livello hardware e che permette il funzionamento di tutte le applicazioni. Il sistema operativo interagisce con il livello hardware attraverso le istruzioni che fanno parte dell ISA relativa all hardware del calcolatore. L interfaccia superiore del sistema operativo è detta API (Application Programming Interface) che è un insieme di regole e metodologie che i livelli superiori devono utilizzare per interagire con le librerie del sistema operativo. 37

49 LA VIRTUALIZZAZIONE L ultimo livello di astrazione è quello delle applicazioni utente che rappresenta tutti i programmi (processi) che interagiscono direttamente con l utilizzatore del calcolatore attraverso l interfaccia grafica o altri metodi di input e output. La virtualizzazione di un sistema operativo comporta l introduzione di un nuovo livello posto tra l hardware e il sistema operativo. Il nuovo livello viene chiamato Virtual Machine Monitor o Hypervisor (vedi fig. 3.4). Ha il compito di fornire delle repliche del sistema hardware del calcolatore attraverso la suddivisione temporale delle risorse. Si può infatti affermare che il cuore, l elemento chiave della virtualizzazione è proprio il virtual machine monitor (VMM). La sua attività principale è il controllo, da effettuare in modo trasparente, sulle istanze virtuali di sistema da esso create. Ogni istanza virtuale prende il nome di virtual machine o domain. Dominio 1 Dominio 2 Applicazione Utente Applicazione Utente Applicazione Utente Sistema Operativo Sistema Operativo Virtual Machine Monitor Hardware Figura 3-4 Schema di un calcolatore dotato di macchine virtuali. 38

50 LA VIRTUALIZZAZIONE I livelli che si trovano al di sopra della virtualizzazione prendono il nome di sistemi ospiti (Guest Systems) mentre i livelli su cui si appoggia il virtual machine monitor sono chiamati sistemi ospitanti (Host Systems). Le CPU attualmente in commercio prevedono almeno due modalità di funzionamento: una privilegiata (identificata con diversi nomi: kernel mode, monitor mode, supervisor mode oppure system mode) in cui è possibile invocare qualsiasi istruzione macchina e una modalità utente (user mode) in cui, per questioni di sicurezza e protezione dell hardware, è possibile invocare solo alcune istruzioni macchina, generalmente quelle ritenute non pericolose. In un sistema privo di macchine virtuali le applicazioni lavorano in modalità utente e il sistema operativo (o parte di esso: il kernel) lavora in modalità privilegiata. È possibile vedere le due modalità come due livelli gerarchici, infatti, le applicazioni che lavorano in user mode non possono in alcun modo influire sul sistema operativo che lavora in modo privilegiato; viceversa, il sistema operativo riesce a controllare l attività delle applicazioni grazie alla possibilità di lavorare in modalità privilegiata. Lo scheduling dei processi, ad esempio, avviene in modalità privilegiata, in questo modo, nessuna applicazione (processo) che sta lavorando in modalità utente può impedire il cambio di contesto e di processo. In un architettura basata su macchine virtuali, il virtual machine monitor deve appartenere ad un livello gerarchico più alto di quello dei 39

51 LA VIRTUALIZZAZIONE sistemi operativi, poiché deve avere il controllo su di loro. La maggior parte delle CPU prevede due soli livelli 8 e dunque, se il VMM lavora nella modalità privilegiata, i sistemi operativi devono forzatamente utilizzare solo la modalità utente come le applicazioni che vi girano. 3.3 Requisiti di una macchina virtuale Il virtual machine monitor deve in generale rispondere ai seguenti requisiti [10]: Compatibilità: l utilizzo delle macchine virtuali non deve richiedere modifiche ai livelli superiori; sarebbe infatti improponibile al mercato una macchina virtuale che richieda modifiche agli applicativi. Per questo motivo è necessario che le macchine virtuali imitino completamente i comportamenti della macchina che vanno a virtualizzare; Performance: l introduzione di un livello tra il sistema operativo e l hardware comporta l introduzione di un certo overhead 9. Il raggiungimento di performance simili a quelle di una macchina 8 In realtà l architettura x86 a 32 bit e a 64 bit prevedono quattro modalità di funzionamento ma i sistemi operativi moderni utilizzano solo le due poste agli estremi. 9 Con il termine overhead si intende il tempo impiegato in attività accessorie all esecuzione di un compito. In questo caso al tempo strettamente necessario per eseguire una certa interazione tra sistema operativo e hardware va aggiunto il tempo speso nella gestione di questa interazione da parte del virtual machine monitor. 40

52 LA VIRTUALIZZAZIONE reale copre buona parte degli studi sull ottimizzazione dell attività di virtualizzazione; Semplicità: le macchine virtuali possono essere utilizzate per aumentare la sicurezza e l affidabilità dei server. Per garantire ciò, anche il virtual machine monitor deve essere affidabile. In generale una architettura semplice è anche caratterizzata da un certo grado di affidabilità e robustezza; Isolamento: ogni macchina virtuale deve essere isolata da ogni altra, quindi sia da attacchi accidentali che malintenzionati. Non deve essere possibile consentire che una macchina virtuale interferisca con un altra macchina e che siano violati i meccanismi di protezione implementati dal VMM. 3.4 Virtual Machine Monitor (VMM) Il Virtual Machine Monitor (VMM) anche definito Hypervisor è il software vero e proprio che permette l esecuzione multipla di sistemi operativi, sullo stesso computer e nello stesso momento. Il VMM è il componente primario della virtualizzazione che abilita la suddivisione delle risorse base di un PC, come ad esempio il partizionamento della CPU, della memoria e dell I/O. Con l evolversi delle tecnologie di virtualizzazione ed il miglioramento dell hardware, le 41

53 LA VIRTUALIZZAZIONE funzionalità base del VMM possono risiedere in uno strato software a sé stante, che può trovarsi direttamente sull hardware della macchina oppure essere implementato in una parte del sistema operativo Full virtualization e paravirtualization Esiste una distinzione tra le tipologie di virtualizzazione che vengono fornite. Si ha virtualizzazione completa (full virtualization) quando un sistema operativo può essere eseguito nella macchina virtuale creata dall hypervisor senza che sia necessario modificare il codice. Invece, nel caso della paravirtualizzazione (paravirtualization) sono necessarie alcune modifiche al codice del sistema operativo per portarlo, cioè per permettergli di essere eseguito da una macchina virtuale. In questo ultimo caso, il VMM presenta un interfaccia di astrazione, tramite la macchina virtuale, non uguale ma simile all interfaccia esportata dall hardware sottostante. Sono quindi necessarie delle modifiche al codice del sistema operativo, ma non alle applicazioni che vengono eseguite sul sistema operativo. Uno dei vantaggi della paravirtualizzazione è una performance migliore. Infatti, non è necessario effettuare la traduzione dinamica delle istruzioni. Uno svantaggio, invece, è che il numero di sistemi operativi che possono essere eseguiti con questa tecnologia è minore, in quanto 42

54 LA VIRTUALIZZAZIONE possono essere eseguiti nelle macchine virtuali, solo quei sistemi operativi dei quali è possibile modificare il codice Binary translation e dynamic recompilation Tra le varie tecniche utilizzate per implementare la virtualizzazione completa è possibile citare quella della binary translation, tra gli altri utilizzata da VMware [11] e da Virtual PC della Microsoft [12]. Questa tecnica prevede una traduzione a tempo di esecuzione del codice destinato all architettura hardware. In pratica, visto che il codice del sistema operativo non viene modificato, tutte le parti di codice che contengono operazioni privilegiate, e che quindi richiedono l intervento del VMM, devono essere interpretate a tempo di esecuzione per inserivi un trap al VM. Questa soluzione, rispetto a quella della paravirtualizzazione, ha però un overhead più elevato. Un altra tecnica per implementare la virtualizzazione completa è la dynamic recompilation. Questo termine viene usato per indicare il fatto che un sistema operativo, progettato per essere eseguito su una particolare classe di CPU e quindi con un determinato linguaggio macchina, viene eseguito da una macchina virtuale che emula un altro tipo di CPU, con un differente insieme di istruzioni. Di conseguenza, a tempo di esecuzione parti di codice vengono ricompilate per essere 43

55 LA VIRTUALIZZAZIONE eseguite sulla nuova architettura. È un esempio pratico di questa filosofia PearPC [13] che permette l esecuzione di MacOS, noto sistema per processori PowerPC su macchine con architettura x86. Nella binary translation esiste il classico ciclo di prelievo-decodificaesecuzione dell istruzione, e quindi ogni istruzione viene emulata per la nuova architettura. Nel caso della dinamyc recompilation, invece, durante l esecuzione vengono riscritte in blocco sezioni di codice, ad esempio la prima volta che si entra in una determinata sezione di codice. Successivamente, se le stesse istruzioni dovessero essere rieseguite, si utilizzerà nuovamente la sezione ricompilata. Un altra differenza è dovuta al fatto che, nel caso della binary translation le istruzioni vengono eseguite direttamente dalle macchine virtuali e non vengono tradotte, invece, nel caso della dynamic recompilation tutte le istruzioni devono essere emulate Struttura interna dell hypervisor La struttura centrale del Virtual Machine Monitor (VMM), è la parte che esegue la virtualizzazione vera e propria, può essere suddivisa in tre moduli che gestiscono la virtualizzazione (o in alcuni casi l emulazione) della CPU, della memoria e delle periferiche di input e di output. 44

56 LA VIRTUALIZZAZIONE Nei prossimi paragrafi verranno descritte nel dettaglio le implementazioni di ognuno di questi moduli [10]. Macchina Virtuale Macchina Virtuale Sistema Operativo Sistema Operativo CPU Virtuale Memoria Virtualizzata Periferiche Virtuali CPU Virtuale Memoria Virtualizzata Periferiche Virtuali Virtual Machine Monitor Macchina Reale CPU Memoria Periferiche I/O Figura 3-5 Struttura del Virtual Machine Monitor Virtualizzazione della CPU La gran parte dei microprocessori presenti nei calcolatori moderni presentano un istruction set (l insieme delle istruzioni macchina con cui vengono scritti i programmi) non adatto alla virtualizzazione. La virtualizzazione della CPU passa attraverso la risoluzione o l aggiramento di questo problema. MODALITÀ DI FUNZIONAMENTO DELLA CPU La famiglia di CPU x86 presenta due soli modi di funzionamento che in un sistema non virtualizzato sono assegnati al sistema operativo e alle applicazioni. Il virtual machine monitor deve però utilizzare un modo di funzionamento più privilegiato rispetto a quello del sistema operativo. 45

57 LA VIRTUALIZZAZIONE Per questo motivo si sceglie di assegnare al virtual machine monitor il livello privilegiato mentre sistema operativo e applicazioni girano in modalità utente. In questo modo l hypervisor riesce a mantenere il controllo della CPU. Eseguendo il sistema operativo in modalità utente, le istruzioni privilegiate che esso tenta di eseguire sono facilmente catturate dal virtual machine monitor: la CPU reale infatti, lancia delle eccezioni (traps) quando si trova in modalità utente e deve eseguire una istruzione privilegiata. È sufficiente implementare un sistema in grado di percepire quando le eccezioni vengono lanciate (dispatcher), capire quale istruzione l ha generata (allocator) ed eseguire una istruzione alternativa (interpreter). L interpreter può eseguire la stessa istruzione in modalità privilegiata, oppure scegliere di eseguire una istruzione equivalente che produce gli stessi effetti. Il VMM deve quindi implementare questi tre moduli per eseguire la virtualizzazione della CPU (vedi fig. 3.6). ISTRUZIONI SENSITIVE Un ulteriore problema è rappresentato dalle sensitive instructions cioè quelle istruzioni che interferiscono con lo stato della VMM o delle altre macchine virtuali eventualmente istanziate dal virutal machine monitor. Se queste istruzioni sono tutte privilegiate allora la complessità dell hypervisor non aumenta poiché vengono riconosciute grazie alle eccezioni della CPU ed in questo caso la CPU stessa viene definita virtualizzabile. 46

58 LA VIRTUALIZZAZIONE Sistema operativo ospitato Istruzione Privilegiata Dispatcher delle eccezioni Eccezione (trap) Istruzione Alternativa Allocator Interpreter Output dell istruzione Microprocessore reale tempo Figura 3-6 Intercettazione delle eccezioni del dispatcher. Purtroppo il progetto delle attuali CPU non ha tenuto conto delle esigenze di una possibile virtualizzazione. Nelle CPU della famiglia x86 esistono delle istruzioni sensitive non privilegiate che non possono essere catturate dall hypervisor e di conseguenza la CPU non rilascia eccezioni nel caso si verifichino. Per questo motivo deve esistere un sistema che permetta il riconoscimento delle istruzioni sensitive non privilegiate prima che vengano messe in esecuzione. Questo sistema si fonda sulla traduzione binaria dinamica che permette di tradurre al volo le istruzioni sensitive non privilegiate sostituendole con altre non pericolose. L implementazione di un traduttore binario dinamico necessità però di 47

59 LA VIRTUALIZZAZIONE molte risorse ed aumenta notevolmente la complessità del VMM. Le istruzioni tradotte vengono poi memorizzate in una memoria cache in modo da evitare inutili traduzioni successive. Per diminuire l inevitabile overhead introdotto dal traduttore binario dinamico vengono di norma implementate funzioni di ottimizzazione dinamica del codice. SCHEDULING DELLE CPU VIRTUALI Più macchine virtuali che lavorano contemporaneamente, necessitano di più CPU virtuali che lavorano a turno sul processore reale del calcolatore. Deve quindi esistere un algoritmo di scheduling delle macchine virtuali, generalmente basato sul round robin: ad ogni macchina virtuale viene concesso, a turno, l utilizzo delle risorse reali per un quanto di tempo prestabilito. Quando una macchina virtuale termina la sua porzione di tempo deve congelarsi e attendere che le venga assegnato il nuovo turno. La CPU virtuale deve quindi avvalersi di una struttura dati in memoria sui cui possa memorizzare lo stato della sua CPU reale (registri, translation look-aside buffer, ecc ) in ogni transizione tra le macchine virtuali. Questi dati verranno poi ricaricati sulla CPU reale quando la machina virtuale entrerà in un nuovo quanto di tempo ad essa dedicato. 48

60 LA VIRTUALIZZAZIONE Virtualizzazione della memoria La memoria di un calcolatore classico è formata da una sequenza di celle elementari su cui è possibile scrivere e leggere dati. Ad ogni cella è assegnato un indirizzo che viene chiamato fisico perché è effettivamente quello che indica la posizione della cella nell implementazione hardware della memoria. Per migliorare e facilitare la gestione della memoria centrale da parte della CPU ad ogni cella è assegnato almeno un indirizzo logico. Poiché la CPU e il sistema operativo utilizzano i soli indirizzi logici, deve esistere un unità che effettui la conversione e il controllo sulla validità degli indirizzi: la Memory Management Unit (MMU). La gestione di grosse quantità di memoria necessita di un sistema di indirizzamento basato su elementi di memoria di capacità maggiore rispetto alle celle. Questi elementi, che a loro volta saranno formati da un numero prestabilito di celle, sono chiamati pagine (pages). Analogamente a quello che succede per le celle, anche in questo caso si hanno pagine logiche (spesso chiamate semplicemente pagine) e pagine fisiche chiamate normalmente frames. Le corrispondenze tra pagine e frames sono mantenute dalla page table (letteralmente tabella delle pagine). In questa situazione l algoritmo di indirizzamento della memoria svolto dalla memory management unit prevede l indirizzamento della pagina (logica) e della cella (in termini di offset rispetto all inizio della pagina) e la conversione della parte di 49

61 LA VIRTUALIZZAZIONE indirizzo riferito alla pagina tramite un accesso alla page table da cui si ottiene l indirizzo del frame. Il tempo impiegato nella conversione tra gli indirizzi di pagine e frames dipende dalla dimensione della page table e dal tempo impiegato per scorrerla. Per questo motivo parte della page table viene memorizzata in una memoria ad accesso veloce chiamata generalmente cache memory e che nello specifico viene denominata Translation lookaside buffer (TLB). Esistono diversi tipi di TLB che sono più o meno adatti alla virtualizzazione, tra i più funzionali c è il TLB di tipo tagged in cui oltre agli indirizzi di pagine e frames viene memorizzato un indicatore con il processo proprietario della pagina. Questa importante caratteristica può essere sfruttata per discriminare fra le pagine appartenenti a macchine virtuali diverse. La virtualizzazione è notevolmente agevolata quando la TLB viene gestita dal sistema operativo e quindi dal virtual machine monitor nel caso di un sistema virtualizzato. Purtroppo l architettura x86 non risponde a nessuna delle due caratteristiche elencate e quindi, la virtualizzazione di questa architettura è correlata a diverse complicazioni. Virtualizzare la memoria significa condividere in modo sicuro la memoria centrale del calcolatore e creare una rappresentazione virtuale di questo complesso sistema di indirizzamento e di tutti gli altri dettagli, quali caching della page table e gestione della memoria. La memoria centrale del calcolatore viene quindi suddivisa in parti, ciascuna delle quali assegnata in esclusiva ad una macchina virtuale. 50

62 LA VIRTUALIZZAZIONE Ogni sistema operativo ospitato costruisce e gestisce una propria page table che servirà come riferimento alla memory management unit e al translation look-aside buffer per eseguire le conversioni fra gli indirizzi. L architettura x86 ha MMU e TLB di tipo hardware che quindi non possono essere gestiti dai sistemi operativi ospitati e nemmeno dal VMM. La page table di ogni sistema operativo ospitato traduce gli indirizzi delle pagine in indirizzi di frames che vengono calcolati come se la macchina virtuale avesse a disposizione l intero banco di memoria del calcolatore reale. Per ovviare a questo problema è necessario introdurre una nuova tabella che traduce gli indirizzi dei frames virtuali in indirizzi di frames reali effettivamente residenti nella memoria reale. Questa struttura dati, unica per ogni macchina virtuale, viene detta pmap ed anche in questo caso la virtualizzazione introduce un passaggio in più che genera overhead. Infatti, MMU e TLB dovrebbero effettuare il doppio degli accessi in memoria per tradurre un indirizzo. Per evitare ciò, il VMM si occupa allora del mantenimento di un altra tabella delle pagine trasparente alle macchine virtuali che per questo è definita shadow (letteralmente ombra). La shadow page table mantiene la corrispondenza tra le pagine di ogni macchina virtuale e i frames reali. È quindi necessaria l implementazione di un algoritmo che mantenga coerentemente il contenuto della shadow page table con i contenuti della coppia formata da page table e pmap. È necessario poi che il virtual 51

63 LA VIRTUALIZZAZIONE machine monitor catturi ogni istruzione di indirizzamento che utilizzi le page tables virtuali e le sostituisca con nuove istruzioni che dicano al MMU di utilizzare la shadow page table come riferimento per la conversione degli indirizzi. L utilizzo della shadow page table permette anche lo spostamento al volo delle locazioni di memoria utilizzate da una macchina virtuale senza dover modificare la page table della macchina stessa, è sufficiente modificare il pmap corrispondente e la shadow page table. Page Table1 Indirizzo del frame virtuale Pmap1 Indirizzo del frame reale Memoria centrale del calcolatore Page Table1 Pmap2 Shadow page table Figura 3-7 Sistema di indirizzamento della memoria nel VMM. 52

64 LA VIRTUALIZZAZIONE CONDIVISIONE DELLA MEMORIA Risparmiare memoria è fondamentale per un virtual machine monitor, per cui, quando è possibile si tende a condividere locazioni di memoria fra diverse macchine virtuali. Soprattutto nel caso delle sue applicazioni in ambito server, il VMM si trova ad istanziare numerose macchine virtuali su cui viene eseguito lo stesso sistema operativo. Una parte delle informazioni immagazzinate in memoria centrale dai sistemi operativi ospitati sono di sola lettura come, ad esempio, alcune parti del kernel del sistema stesso. Esistono alcuni algoritmi di riconoscimento di pagine simili basati sul controllo di una chiave (hash) assegnata ad ogni pagina che ne riassume il contenuto. Nel caso il virtual machine monitor individui due pagine simili, modifica immediatamente la shadow page table in modo che le pagine allocate dalle due macchine virtuali puntino allo stesso frame Virtualizzazione delle periferiche La virtualizzazione dei dispositivi di input e di output di un calcolatore è particolarmente complessa a causa della eterogeneità dei dispositivi stessi. È infatti impossibile definire un unico livello di astrazione per tutti i tipi dispositivi. 53

65 LA VIRTUALIZZAZIONE Nelle prime applicazioni della virtualizzazione, i sistemi IBM prevedevano dei canali asincroni di comunicazione attraverso i quali il sistema virtuale poteva interagire con la periferica senza introdurre fastidiosi overheads. Con questo sistema non era necessario nessun tipo di interazione con il virtual machine monitor durante la comunicazione con le periferiche. Questo sistema non è più applicabile a causa dell enorme eterogeneità delle periferiche che vengono utilizzate soprattutto nei sistemi desktop. I VMM utilizzati nelle varie applicazioni comunicano con le periferiche effettuando appropriate system calls sul sistema operativo ospitante. La struttura del virtual machine monitor risulta in questo modo molto semplice poiché viene progettato tenendo conto delle sole API del sistema operativo. Questa modalità purtroppo introduce delle latenze nell interazione con le periferiche poiché, in ogni caso, la comunicazione tra macchina virtuale e periferica reale deve passare attraverso il controllo effettuato dall hypervisor e dal sistema operativo host. In ambito server, dove l eterogeneità delle periferiche è trascurabile rispetto alla necessità di avere un ridottissimo overhead, le periferiche vengono virtualizzate attraverso interfacce semplificate che comportano un elevato grado di semplicità di progettazione e di portabilità delle macchine virtuali stesse. La gestione della comunicazione tra macchine virtuali e periferiche reali passa comunque attraverso il virtual machine monitor. 54

66 LA VIRTUALIZZAZIONE Alcuni hypervisor hanno inoltre la possibilità di virtualizzare una periferica non presente nel calcolatore reale. In questo caso si parla di emulazione di una periferica. Come è già stato specificato più volte, emulare qualcosa significa, imitarne il comportamento. È infatti possibile creare una emulazione di periferica SCSI quando esse non sono presenti o emulare porte seriali e parallele oppure, soprattutto nel caso di console giocattolo, tutto l hardware che sta attorno alla CPU. 3.5 Benefici della virtualizzazione Come si è detto nei paragrafi precedenti, l idea di creare una macchina virtuale nacque all incirca negli anni sessanta quando i calcolatori erano molto onerosi in termini di costo e di spazio. In quella situazione era conveniente cercare un meccanismo per riuscire ad utilizzare più sistemi operativi (quindi più applicazioni) su una sola macchina. Con il progredire delle tecnologie elettroniche ed informatiche i calcolatori sono diventati sempre meno grandi, meno costosi e più potenti. Questo tipo di progresso nell hardware nascose le potenzialità della virtualizzazione. Al giorno d oggi la ricerca sulla virtualizzazione ha ripreso vigore poiché il livello di integrazione dei moderni calcolatori è tale da mantenere sottoutilizzati i calcolatori che svolgono attività di server. Infatti, per questioni di sicurezza e affidabilità, si tende ad installare una 55

67 LA VIRTUALIZZAZIONE sola applicazione per sistema operativo e quindi una sola applicazione per calcolatore. In questo modo se una applicazione o un sistema operativo è sotto attacco gli altri servizi forniti non ne risentono perché meccanicamente indipendenti. Questa tecnica, assolutamente infallibile da un punto di vista di affidabilità mostra però problemi in termini di risorse: sono necessari svariati calcolatori che, tenuto conto delle potenzialità odierne, risultano sottoutilizzati ed i costi di gestione e di spazio necessario aumentano. Attraverso l impiego delle macchine virtuali è possibile sostituire i server sottoutilizzati con un unico calcolatore su cui girano diverse istanze di macchine virtuali. Su ognuna di queste è possibile installare il sistema operativo e l applicazione che si utilizzava precedentemente. In questo modo, il numero dei calcolatori diminuisce, i costi di gestione e di spazio diminuiscono, e il rendimento del calcolatore aumenta poiché viene sfruttato maggiormente rispetto a prima. Anche se con questo tipo di progettazione si ha un solo calcolatore, le macchine virtuali sono isolate meccanicamente tra loro e quindi le applicazioni mantengono lo stesso tipo di isolamento che avevano girando in calcolatori reali diversi. Infatti nel caso in cui una applicazione o un sistema operativo sia attaccato o comunque abbia problemi, sarà eventualmente la macchina virtuale su cui gira ad avere problemi e non il calcolatore reale. 56

68 LA VIRTUALIZZAZIONE L utilizzo delle macchine virtuali comporta una certa forma di standardizzazione che ha aspetti positivi in termini di istallazione di sistemi e di loro amministrazione. Si pensi ad esempio ad una serie di calcolatori differenti tra loro: il sistema operativo deve essere installato e configurato su ognuno di essi per adattarsi alle caratteristiche hardware del calcolatore. Questa attività richiede tempo e rappresenta un costo notevole. Per evitare ciò si può installare su ogni macchina un virtual machine monitor che generalmente è molto più leggero ed elastico di un sistema operativo. Su ogni calcolatore viene quindi generata una macchina virtuale standardizzata che li rende tutti uguali agli occhi del sistema operativo. In questo modo è possibile effettuare una sola installazione e configurazione del sistema operativo su di una macchina virtuale e poi copiare il file immagine contenente la macchina virtuale. In questo modo abbiamo configurato diversi calcolatori impiegando solo il tempo necessario alla configurazione di un solo sistema operativo e al trasferimento dell immagine relativa tra i calcolatori. La virtualizzazione permette di creare una imitazione d un componente hardware o di un intero calcolatore. Nell esempio visto in precedenza si creavano macchine virtuali identiche al calcolatore sottostante. È anche possibile generare macchine virtuali che differiscono dal calcolatore su cui si appoggiano. Questo permette di utilizzare sistemi 57

69 LA VIRTUALIZZAZIONE operativi su architetture diverse da quelle per cui erano stati progettati 10. Attraverso una stretta emulazione delle caratteristiche prestazionali di un calcolatore si riesce anche ad imitare le prestazioni di calcolatori obsoleti e piattaforme di gioco in cui la temporizzazione delle attività è fondamentale. App App App App SO SO SO SO V M M HW HW HW a b Figura 3-8 Mascheramento del livello hardware nel VMM. I domini creati dal VMM, oltre che essere isolati tra di loro, sono isolati anche dal calcolatore reale poiché le interazioni con esso avvengono sotto il controllo dell hypervisor che interrompe eventuali attività pericolose. Questa caratteristica dà la possibilità di utilizzare le macchine virtuali anche in ambito di ricerca e di testing di software. È possibile infatti testare il comportamento di applicazioni costruendo, attraverso il virtual machine monitor, situazioni critiche (introduzione di nuovi dispositivi, malfunzionamenti, ecc ) ed analizzare l andamento della situazione senza danneggiare il calcolatore reale. 10 Tra gli esempi più famosi Microsoft VirtualPC che permette agli utenti di architetture PowerPC di utilizzare sistemi operativi Microsoft Windows progettati per architetture x86 e dall altro lato PearPC che consente di utilizzare MacOS nato per processori PowerPC su architetture x86. 58

70 LA VIRTUALIZZAZIONE 3.6 Principali software di virtualizzazione L architettura utilizzata in molti PC è particolarmente difficile da virtualizzare, in quanto tutto ciò che non è supportato direttamente dall hardware come ad esempio l accesso che normalmente avviene in modo esclusivo a varie risorse del sistema, deve essere modificato e reso compatibile, in modo da far convivere più sistemi operativi contemporaneamente, attraverso il software. La piena virtualizzazione, ossia la simulazione di un insieme completo di hardware di tipo standard, nella architettura x86 ha quindi costi significativi nella complessità e nelle performance per l hypervisor (o VMM). Un approccio alternativo richiede che il sistema operativo ospite sia modificato. Questo sistema è utilizzato dal recente progetto open-source Xen [14], è chiamato paravirtualizzazione e permette alte performance ed una semplicità maggiore dell hypervisor. Xen, è un implementazione software di macchina virtuale che gira quasi esclusivamente in sistemi operativi di tipo linux, ma con kernel modificati. Molti produttori di CPU hanno iniziato recentemente ad aggiungere il supporto hardware per la virtualizzazione nei loro prodotti. I rispettivi nomi per i progetti che realizzano questo obiettivo sono Vanderpool ovt (Virtualization Technology) per Intel e Pacifica o SVM per AMD. In 59

71 LA VIRTUALIZZAZIONE particolare viene aggiunto il supporto alle parti difficilmente virtualizzabili o inefficienti da virtualizzare, nell architettura x86, garantendo un supporto ulteriore agli hypervisors. Questo nuovo passo, porta e porterà ad un aumento notevole di performance, migliorerà la semplicità del codice da scrivere per virtualizzare un sistema, e permetterà infine piena e completa virtualizzazione [15][16]. Tra i sistemi simile a Xen, che usa anch esso la paravirtualizzazione è Denali, che garantisce macchine virtuali ad alte performance, sempre nelle architetture x86. Denali supporta macchine virtuali specializzate e minimali per fornire servizi Internet. Il sistema può scalare migliaia di macchine virtuali. A differenza di Xen, Denali non preserva l interfaccia dell applicazione binaria, per questo motivo le applicazioni devono essere ricompilate per girare nel sistema operativo. La differenza tra Xen e Denali è proprio di carattere, di utilizzo e di scelte progettuali differenti. Xen preferisce far girare un numero moderato di sistemi operativi pienamente funzionanti, mentre Denali preferisce quelli specializzati e leggeri [17]. VMware permette la virtualizzazione di sistemi operativi non modificati, sempre nell architettura x86. La tecnologia utilizzata è estremamente complessa ma è anche altrettanto performante. Recentemente, VMware per contrastare la concorrenza ha rilasciato gratuitamente VMware Server. Questo è un prodotto freeware che permette di partizionare server x86 (anche a 64 bit) in più macchine 60

72 LA VIRTUALIZZAZIONE virtuali. Supporta inoltre la tecnologia di virtualizzazione Intel Virtualization Technology e utilizza una specifica e potente interfaccia per il monitoraggio delle macchine virtuali. Virtuozzo, un altro sistema proprietario, sostituisce lo strato di astrazione dell hardware con una versione modificata, migliorando le performance del sistema operativo. Questo è ottenuto forzando però l utilizzo dello stesso sistema operativo da parte di tutte le macchine virtuali [18]. Un altra implementazione dell hypervisor è chiamata lightweight hypervisor introdotta in Parallels Workstation, anch esso un sistema proprietario. Questo tipo di hypervisor è uno strato software snello tra il sistema operativo ospitato, che non necessita modifiche, ed il computer ospite. Il lightweight hypervisor controlla direttamente una parte dell hardware della macchina e fornisce una interfaccia di supporto per le chiamate di sistema virtualizzate, sia per i VMM che per il sistema operativo ospitato, eliminato l overhead e migliorando la velocità, le performance e l isolamento della macchina virtuale [19]. La tabella riassuntiva 3.1 presenta le caratteristiche base dei principali Virtual Machine Manager. 61

73 LA VIRTUALIZZAZIONE Figura 3-9 Tabella comparativa dei principali software di virtualizzazione. 62

74 REALIZZAZIONE DEL PROGETTO Capitolo 4 4 Realizzazione del progetto L Università degli Studi di Perugia è continuamente impegnata nel tentativo di ridurre i costi di gestione e nell ottimizzare le risorse a sua disposizione. A questo scopo la Ripartizione Servizi Informatici e Statistici, che è la struttura demandata all amministrazione sia dei server e che più in generale alla struttura informatica dell Ateneo, ha deciso nell ultimo periodo di rivedere il parco macchine a sua disposizione. Una dettagliata analisi della sala server ha messo in evidenza che molte delle macchine utilizzate risultano sovradimensionate rispetto alla capacità di calcolo richiesta dai servizi che offrono. Proprio sulla base di questa motivazione e sulla crescente spinta del mondo IT verso i software di virtualizzazione, è nata l idea di un progetto finalizzato alla realizzazione di una struttura che permettesse di 63

75 REALIZZAZIONE DEL PROGETTO virtualizzare tutte quelle macchine con modeste richieste di calcolo cercando nel contempo di migliorane l affidabilità complessiva. 4.1 Analisi del problema Quando si inizia la realizzazione di un progetto è importante capirne bene le finalità e soprattutto le necessità che deve soddisfare, proprio per questi motivi occorre analizzare il problema a fondo e in modo dettagliato. Essendo il progetto di natura sperimentale, inteso a verificare la fattibilità dell utilizzo della virtualizzazione su un ampio numero di server, si è cercato di ridurre al minimo le spese necessarie: puntando su macchine riciclate, per quanto riguarda l hardware, e su prodotti opensource o freeware per la parte relativa al software. La necessità di realizzare un sistema in grado di garantire la disponibilità dei servizi offerti, ha indirizzato verso l utilizzo di due macchine da configurare in alta affidabilità. Il software scelto per la realizzazione del sistema è hearbeat del progetto Linux-HA, un prodotto open-source in grado di rispecchiare pienamente i requisiti di minimizzazione dei costi imposti dal progetto. L utilizzo di un sistema in alta disponibilità richiede obbligatoriamente la presenza di uno storage condiviso tra le macchine 64

76 REALIZZAZIONE DEL PROGETTO che ne fanno parte. Poiché nelle disponibilità della Ripartizione Servizi Informatici e Statistici non vi è un dispositivo adeguato da poter recuperare e destinare a questo progetto, si è pensato di sopperire a questa mancanza mediante il software drbd, che consente la realizzazione di uno storage condiviso attraverso i dischi fissi dei nodi. Il recente annuncio della società VMware, in merito al rilascio gratuito della versione server del suo famoso e rinomato software per la virtualizzazione, ha inciso notevolmente, insieme alle doti di stabilità e performance, sulla scelta di adottare per questo progetto VMware Server come layer di virtualizzazione. Sulla base dei software scelti e di tutte le considerazioni sin qui fatte, le due macchine recuperate sono state configurate con determinate caratteristiche fisiche. La necessità di conferire al sistema capacità prestazionali accettabili e throughtput adeguato nelle connessioni di rete, ha reso necessaria l installazione di almeno 4 interfacce di rete per ogni nodo. Per migliorare l affidabilità delle macchine, aderendo inoltre al livello 2 di disponibilità esposto nel paragrafo 2.1, i computer sono stati dotati di un hard disk supplementare in modo da poter effettuare il mirroring (RAID 1) dei dischi di sistema. La necessità infine di mandare in esecuzione diverse macchine virtuali, obbliga i nodi ad essere dotati di molta RAM. Nel caso specifico si è riusciti a recuperare un GigaByte per ogni macchina che, in aggiunta 65

77 REALIZZAZIONE DEL PROGETTO ai processori rispettivamente di classe Pentium IV e Xeon, sono in grado di garantire una capacità di calcolo sufficiente agli scopi che ci si è prefissati. Nome Nodo Alpha Bravo Marca/Modello IBM xseries 336 Assemblato Processore Intel Xeon 3.20 Ghz Intel Pentium Ghz Memoria RAM 1 GB 1 GB Dischi Maxtor 6Y080M0 80 GB HDS728080PLA GB Maxtor 6Y080L0 80 GB Maxtor 6Y080L0 80 GB Dischi BCM5704 Gigabit Ethernet BCM5704 Gigabit Ethernet BCM5721 Gigabit Ethernet BCM5721 Gigabit Ethernet Tabella 4-1 Caratteristiche hardware dei nodi. RTL-8169 Gigabit Ethernet RTL-8169 Gigabit Ethernet VT6105 [Rhine-III] VT6105 [Rhine-III] Figura 4-1 Foto del nodo Alpha. Figura 4-2 Foto del nodo Bravo. 66

78 REALIZZAZIONE DEL PROGETTO 4.2 Installazione e configurazione dei nodi Una volta recuperate le macchine e terminata la configurazione della loro parte hardware si è proceduto all installazione del sistema operativo. Per questo progetto si è scelta la distribuzione Kubuntu nella versione LTS Alternate per via delle sue spiccate caratteristiche open-source e per il forte orientamento verso gli ambienti server. Kubuntu è un sistema operativo GNU/Linux di facile utilizzo che si fonda sul progetto Ubuntu (distribuzione di derivazione Debian) al quale viene sostituito l ambiente grafico GNOME con quello KDE (K Desktop Environment) decisamente più intuitivo. È stata scelta la versione definita LTS (Long Team Support) poiché vanta un ragguardevole supporto di 5 anni, molto utile negli ambienti server in cui la completa reinstallazione del sistema non è sempre facilmente attuabile. La dicitura Alternate indica infine che il CD consente di eseguire installazioni personalizzate in modalità esperta, necessario per la configurazione del RAID software. Una volta giunta a termine l installazione del sistema operativo in entrambe le macchine, è bene controllare che i software installati siano speculari. A questo proposito si può utilizzare il comando dpkg che, lanciato con le giuste opzioni, restituisce l elenco completo dei pacchetti installati. Utilizzando lo stesso comando, insieme all elenco dei package 67

79 REALIZZAZIONE DEL PROGETTO appena creato, si possono ottenere due macchine perfettamente speculari dal punto di vista del software installato. alpha:~ dpkg --get-selections > pacchetti_alpha.txt bravo:~ dpkg --set-selections < pacchetti_alpha.txt bravo:~ dselect Ottenuta la specularità del sistema operativo tra le macchine, si può procedere alla configurazione dei componenti necessari al funzionamento del progetto ed in particolare alle schede di rete [20][21][22] Channel Bonding Il channel bonding è una tecnica utilizzata per configurare due o più interfacce di rete, in modo da agire come so fossero una sola. Viene utilizzata al fine di aumentare le performance del canale trasmissivo oppure per evitare un possibile point of failure, dovuto a guasto delle schede, del cavo o delle porte a cui esse sono collegate. Sfruttando questo particolare metodo, basato su una proprietà del kernel di Linux, si ottiene che i pacchetti di una trasmissione dati vengano inviati attraverso tutte le interacce del pool di bonding configurato (definite sullo stesso indirizzo IP). Il kernel del sistema infatti mette a disposizione un device virtuale (tipicamente /dev/bond0) che viene utilizzato normalmente dalle applicazioni di più alto livello come un device di comunicazione. 68

80 REALIZZAZIONE DEL PROGETTO Per il funzionamento del bonding sono necessari due pacchetti particolari iproute e ifenslave che vanno ovviamente installati su entrambi i nodi attraverso i seguenti comandi: alpha:~ apt-get install ifenslave alpha:~ apt-get install iproute bravo:~ apt-get install ifenslave bravo:~ apt-get install iproute Aggiunti i pacchetti necessari al sistema si può procedere con la configurazione del modulo kernel, necessario per la creazione del bonding, per farlo si deve modificare /etc/modprobe.d/arch/i386 aggiungendovi le seguenti righe: alias bond0 bonding options bonding mode=3 max_bonds=2 miimon=100 downdelay=200 updelay=200 Questo permette al kernel di caricare e configurare il modulo secondo i parametri che gli vengono passati attraverso la sezione options. Di seguito verranno illustrate le varie opzioni utilizzate a cominciare da quella mode che identifica la policy utilizzata dal modulo bonding secondo la seguente dicitura [25]: 0 Imposta una policy di tipo round-robin per il bilanciamento del carico e per il fault tolerance. Le trasmissioni vengono ricevute e inviate in modo sequenziale, su ogni interfaccia slave di tipo bonded, iniziando dalla prima disponibile. 1 Imposta una policy di tipo active-backup per il fault tolerance. Le trasmissioni vengono ricevute e inviate tramite la prima 69

81 REALIZZAZIONE DEL PROGETTO interfaccia slave di tipo bonded. Un altra interfaccia slave viene usata solo se la prima interfaccia non ha un esito sperato. 2 Imposta una policy di tipo XOR (exclusive-or) per il bilanciamento del carico e di fault tolerance. Usando questo metodo l interfaccia eguaglia l indirizzo MAC della richiesta in entrata, con l indirizzo MAC per uno dei NIC slave. Una volta stabilito questo collegamento, le trasmissioni vengono inviate in modo sequenziale iniziando con la prima interfaccia disponibile. 3 Imposta una policy di trasmissione per il fault tolerance. Tutte le trasmissioni vengono inviate su tutte le interfacce di tipo slave. 4 Imposta una policy del tipo IEEE 802.3ad dynamic link aggregation. Crea gruppi d aggregazione che condividono la stessa velocità e impostazioni duplex. Trasmette e riceve su tutte le interfacce slave nell aggregator attivo. Questa funzione necessità di un interruttore compatibile con il protocollo 802.3ad. 5 Imposta una policy Transmit Load Balancing (TLB) per il fault tolerance e per il bilanciamento del carico. Il traffico in uscita viene distribuito a seconda del carico su ogni interfaccia slave. Il traffico in ingresso viene ricevuto dall interfaccia slave corrente. Se la slave ricevente fallisce, un altra al suo posto assume il controllo dell indirizzo MAC. 6 Imposta una policy Active Load Balancing (ALB) per il fault tolerance ed il bilanciamento del carico. La ricezione del 70

82 REALIZZAZIONE DEL PROGETTO bilanciamento del carico viene raggiunta grazie ad un ARP negotiation. Il parametro miimon invece specifica (in millisecondi) la frequenza con cui il modulo controlla lo stato del link, quello downdelay definisce quanto tempo si deve attendere dopo il fallimento del link prima di disabilitarlo ed infine updalay specifica quanto bisogna attendere prima di abilitare un link. Dopo queste modifiche si può procedere con la configurazione del nuovo device (che verrà generato dal caricamento del modulo) mediante alcuni cambiamenti nel file /etc/network/interfaces. Nel caso specifico vanno sostituiti tutti i riferimenti alle interfacce eth2 ed eth3 con le righe seguenti: Per il nodo Alpha auto bond0 iface bond0 inet static address netmask post-up ifenslave bond0 eth2 eth3 pre-down ifenslave -d bond0 eth2 eth3 Per il nodo Bravo auto bond0 iface bond0 inet static address netmask post-up ifenslave bond0 eth2 eth3 pre-down ifenslave -d bond0 eth2 eth3 A questo punto un riavvio di entrambi i nodi metterà in funzione le modifiche apportate e sarà sufficiente lanciare il comando ifconfig seguito da alcuni ping di prova, per verificare il corretto funzionamento di quanto configurato: 71

83 REALIZZAZIONE DEL PROGETTO alpha:~ ifconfig bond0 bond0 Link encap:ethernet HWaddr 00:11:25:41:5D:7C inet addr: Bcast: Mask: inet6 addr: fe80::211:25ff:fe41:5d7c/64 Scope:Link UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1 RX packets:264 errors:0 dropped:0 overruns:0 frame:0 TX packets:158 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:24350 (23.7 KiB) TX bytes:19998 (19.5 KiB) ping -I bond0 -c PING ( ) from bond0: 56(84) bytes of data. 64 bytes from : icmp_seq=1 ttl=64 time=0.165 ms 64 bytes from : icmp_seq=2 ttl=64 time=0.194 ms 64 bytes from : icmp_seq=3 ttl=64 time=0.245 ms 64 bytes from : icmp_seq=4 ttl=64 time=0.166 ms 64 bytes from : icmp_seq=5 ttl=64 time=0.205 ms 64 bytes from : icmp_seq=6 ttl=64 time=0.249 ms ping statistics packets transmitted, 6 receivedc, 0% packet loss, time 4999ms rtt min/avg/max/mdev = 0.165/0.205/0.257/0.033 ms bravo:~ ifconfig bond0 bond0 Link encap:ethernet HWaddr 00:50:70:13:11:AA inet addr: Bcast: Mask: inet6 addr: fe80::250:70ff:fe13:11aa/64 Scope:Link UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1 RX packets:185 errors:0 dropped:0 overruns:0 frame:0 TX packets:90 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:18136 (17.7 KiB) TX bytes:10502 (10.2 KiB) ping -I bond0 -c PING ( ) from bond0: 56(84) bytes of data. 64 bytes from : icmp_seq=1 ttl=64 time=0.218 ms 64 bytes from : icmp_seq=2 ttl=64 time=0.129 ms 64 bytes from : icmp_seq=3 ttl=64 time=0.227 ms 64 bytes from : icmp_seq=4 ttl=64 time=0.219 ms 64 bytes from : icmp_seq=5 ttl=64 time=0.186 ms 64 bytes from : icmp_seq=6 ttl=64 time=0.166 ms ping statistics packets transmitted, 6 received, 0% packet loss, time 5000ms rtt min/avg/max/mdev = 0.129/0.190/0.227/0.039 ms Allo stato attuale di evoluzione, il progetto può essere sintetizzato nello schema riportato in figura 4-3 che illustra le configurazioni sin qui effettuate [23][24][26][27]. 72

84 Power Port Status Green = 100M, Yellow = 10M, Flash = Activity 3C16794 ä Power Port Status Green = 100M, Yellow = 10M, Flash = Activity 3C16794 ä REALIZZAZIONE DEL PROGETTO INTERNET / INTRANET Office Connect Switch 8 Office Connect Switch 8 CHANNEL BONDING bond bond eth2 eth3 eth3 eth2 CHANNEL BONDING RAID 1 Software ALPHA (KUBUNTU ) RAID 1 Software BRAVO (KUBUNTU ) Figura 4-3 Schema del progetto dopo l installazione del channel bonding. 4.3 Configurazione dello storage condiviso Il sistema di memorizzazione dei dati in un elaboratore elettronico costituisce un punto nevralgico dell intero sistema. È fondamentale notare che le esigenze di un PC dal punto di vista della memorizzazione dei dati sono notevolmente diverse dalle esigenze di un cluster ad alta disponibilità, così come diversi sono anche i 73

85 REALIZZAZIONE DEL PROGETTO problemi legati alla sua gestione. Si pensi ad esempio al fatto che in un cluster ogni nodo deve avere accesso agli stessi dati, e gli stessi dati devono essere anche protetti da accessi contemporanei da parte di più nodi. Un file system progettato per sistemi cluster deve inoltre fornire la possibilità della gestione dello storage da un singolo punto oltre che un certo livello di consolidamento dei dati. Potrebbero inoltre esserci esigenze ulteriori relative ad esempio al throughtput 11 dei dati, che potrebbero richiedere specifiche particolari, volte ad evitare che il filesystem rappresenti il collo di bottiglia di un sistema cluster Tipologie di storage Si possono individuare due grandi famiglie o filosofie costruttive per i supporti di memorizzazione dei sistemi cluster, che si differenziano sostanzialmente per la dislocazione fisica delle memorie di massa: esterne oppure interne. STORAGE ESTERNO Questo tipo di storage permette di risolvere immediatamente il problema dell accesso condiviso ai dati da parte di tutti i nodi. Questa tipologia di device infatti, sono dispositivi esterni ai quali tutti i nodi del cluster 74

86 REALIZZAZIONE DEL PROGETTO possono accedere. Con questa soluzione viene centralizzato il sistema di memorizzazione dei dati, favorendo la gestione del file system da un solo punto e allo stesso tempo eliminando l onere della replica dei dati da parte del gestore del cluster. Le eventuali funzioni di protezione dei dati, mediante tecniche di ridondanza e replicazione, sono gestite internamente dal dispositivo di storage, riducendo in tal modo sia il traffico di rete generato dai meccanismi di ridondanza che eventuali carichi elaborativi a scapito dei nodi. Questi vantaggi sono apprezzati soprattutto nella realizzazione di cluster di calcolo per i quali spesso si ha la necessità di dover memorizzare enormi quantità di dati a velocità elevata: lo storage esterno è infatti spesso realizzato con tecnologie tali da massimizzare questa capacità. Non è pertanto difficile trovare storage esterni, connessi al cluster attraverso connessioni dedicate ad alta velocità basati su fibra ottica, firewire 12 o SCSI. Spesso si parla di SAN (Storage Area Network) per far riferimento a un insieme di dispositivi di storage di questo tipo, che si avvalgono di una rete dedicata esclusivamente al traffico di dati e quindi spesso utilizzando connessioni ad alta velocità per consentire alte prestazioni. 11 Throughput: con questo termine si definisce l entità di un flusso per unità di tempo. In questo contesto si riferisce al flusso di dati che viene calcolato in MB/sec. 12 Firewire: è il nome dato allo standard di collegamento ad alta velocità IEEE1394 il quale ha come limite teorico di banda passante 480 Mb/sec. Molto usato in ambito desktop anche come interfaccia di collegamento per dispositivi video e di editing digitale. 75

87 REALIZZAZIONE DEL PROGETTO Un altra tecnologia in forte crescita negli storage esterni è iscsi (SCSI over IP) in cui il dispositivo è costruito con tecnologia SCSI ma si basa, per le trasmissioni dati con i nodi, sul protocollo di comunicazione IP. Il lato negativo maggiormente evidente in questo tipo di soluzioni di storage, risiede negli ingenti costi da sopportare. Tali dispositivi sono infatti molto onerosi poiché devono sfruttare tecnologie spesso dedicate e molte volte proprietarie, per fornire le prestazioni per cui sono stati costruiti. È da valutare quindi con molta attenzione se l esigenza di disporre di dispositivi di questo genere giustifichi l investimento necessario. STORAGE INTERNO E DISTRIBUITO Questa seconda categoria di storage è invece orientata principalmente ai cluster di tipo HA, visto che la caratteristica di essere distribuito consente il recupero dei dati su tutti i nodi del cluster, nel caso in cui uno dei nodi dovesse momentaneamente rendersi indisponibile. In questi sistemi la caratteristica di alta velocità è spesso trascurabile perché un cluster progettato per l High Avaiability è spesso adibito all erogazione di servizi e non al calcolo intensivo, per cui la mole di dati da dover gestire e memorizzare può essere relativamente ridotta. Le soluzioni che consentono l implementazione di uno storage distribuito e affidabile si basano essenzialmente sul modello definito un server-un disco il quale stabilisce che ogni nodo del cluster esporta un proprio quantitativo di spazio disco, facendo in modo che ogni altro nodo 76

88 REALIZZAZIONE DEL PROGETTO del cluster vi possa accedere. Viene in questo modo costruito un device astratto che comprende i diversi dischi esportati dai vari nodi e che viene considerato a tutti gli effetti uno storage condiviso. Un file system così costruito si definisce file system parallelo e presenta il suo vantaggio più evidente nella suddivisione dei compiti di lettura/scrittura dei dati ai diversi dispositivi presenti. Un altro evidente vantaggio, decisamente non trascurabile, risiede nell alta affidabilità, fornita grazie al fatto che questa tecnica può incorporare strategie di ridondanza sui vari dischi basate su RAID, eliminando un ulteriore single point of failure rappresentato dal file system di ogni specifico nodo. Le alternative possibili e maggiormente diffuse per la realizzazione di un file system basato su dischi interni sono: Network Block Device (NBD) e RAID software. La combinazione di queste due tecnologie infatti consente di soddisfare le esigenze tipiche di un file system per cluster. Il network block device infatti è un dispositivo che viene aggiunto agli altri già gestiti dal kernel. Consente di montare un device remoto attraverso la rete per fare in modo che venga trattato come un dispositivo locale. Tutto il traffico dati relativo al dispositivo viene pertanto passato attraverso la connessione di rete. Per consentire la replica dei dati necessaria per assolvere alle caratteristiche di disponibilità viene installato un RAID software fra il dispositivo remoto (NBD) e quello logico gestendo poi 77

89 REALIZZAZIONE DEL PROGETTO opportunamente le diverse situazioni che richiedono l accesso ai dati sull uno o sull altro dispositivo. A prima vista potrebbe sembrare che la tecnologia basata su NBD sia molto simile ad NFS 13 ma la differenza è radicale e determinante ai fini della disponibilità e della capacità di recupero dei dati. Rispetto ad NFS, la tecnologia NBD sposta la centralizzazione del sistema distribuendola ai vari nodi della rete. Praticamente NFS è basato su un server che esporta una certa quantità di spazio disco e ogni client che ne fa uso comunica direttamente al server le modifiche che vuole fare sui dati esportati. Ciò significa che se il server si blocca nessuno dei client è in grado di usare lo spazio esportato e quindi bisogna provvedere anche alla ridondanza del server. Con NBD invece ogni macchina esporta una certa quantità di spazio disco che risulta disponibile ad ogni client, il quale attraverso la propria copia del software NBD monta il dispositivo di rete e lo gestisce. Non vi sono quindi richiesta da dover essere processate a carico di un server come in NFS, richieste che potrebbero essere innumerevoli e mettere in crisi il server stesso. Generalmente grazie a questa capacità le prestazioni di NBD sono sensibilmente migliori rispetto ad NFS. 13 NFS: Network File System. Un server NFS esporta una certa quantità di spazio disco locale renderlo accessibile a tutti gli host presenti sulla rete i quali possono montarlo come un file system locale. 78

90 REALIZZAZIONE DEL PROGETTO GPFS (General Parallel File System). Questo file system è stato sviluppato da IBM e reso disponibile gratuitamente agli ambienti accademici, viene invece fornito unicamente dietro licenza proprietaria per le realtà commerciali. Le caratteristiche che rendono appetibile un file system come GPFS riguardano le performance, la possibilità di eseguire operazioni di amministrazione da ogni nodo del cluster e la possibilità di recuperare i dati in caso di errori. GPFS utilizza infatti una tecnica detta di striping per consentire l incremento delle performance e si basa sul fatto che un operazione di scrittura/lettura viene svolta parallelamente da tutte le unità disco presenti nel file system, in quanto ognuna tratta un frammento differente dei dati; la capacità di recovery è invece garantita dal fatto che ogni frammento di dato viene scritto su più dispositivi diversi a seconda della capacità di recupero che si vuole garantire. Maggiore ridondanza genera chiaramente maggiore traffico di rete, ed è proprio per questo motivo che GPFS è ottimizzato per soluzioni di rete ad alta velocità. DRBD (Distributed Replicated Block Device). Sviluppato da Philipp Resiner è attualmente disponibile sotto licenza GPL e quindi liberamente distribuibile e modificabile. DRBD è un dispositivo a blocchi creato esclusivamente per risolvere problemi tipici inerenti cluster in alta disponibilità. Si basa sul meccanismo 79

91 REALIZZAZIONE DEL PROGETTO della replicazione dei dati fra due dispositivi a blocchi residenti su due nodi differenti, attraverso una connessione di rete privata. Semanticamente il suo funzionamento è simile al RAID-1 attuato però fra dispositivi remoti [28]. Dopo aver analizzato e preso in considerazione le alternative offerte dal mercato e sin qui menzionate, per il setup del cluster costruito in questo progetto di tesi la scelta finale è ricaduta sulla tecnologia denominata DRBD. Si è ritenuto che DRBD, poiché ideato esclusivamente per risolvere i problemi di cluster in alta disponibilità, rappresenti il miglior compromesso fra semplicità di utilizzo e potenza delle funzioni implementate. Nonostante le qualità di GPFS queste introducono una complessità decisamente non giustificata in cluster con solo due nodi. Altre caratteristiche favorevoli all uso di DRBD sono il ridotto calo di performance che il suo utilizzo introduce e la sua completa integrabilità con la suite Heartbeat, fondamentale per far sì che la gestione di eventuali failure del file system sia completamente automatizzata. Infine si deve sottolineare il fatto che DRBD è open source e gratuito, caratteristica cruciale per lo sviluppo e la messa in opera di questo progetto. 80

92 REALIZZAZIONE DEL PROGETTO Caratteristiche di DRBD DRBD si basa su di un modulo del kernel presente in entrambi i nodi. I due lavorano in stretta sincronia tra loro ed a dimostrazione di ciò il file di configurazione, che verrà illustrato più avanti, risulta identico in tutte le macchine. Nel momento in cui si decide di costruire un block device basato su DRBD, ognuno dei due nodi mette a disposizione una partizione del proprio disco locale che ovviamente non va configurata per un mounting automatico attraverso il file /etc/fstab. Leggendo il proprio file di configurazione (/etc/drbd.conf) ogni copia di DRBD imposta la partizione fisica ivi specificata e la fa entrare a far parte del block device specificato (/dev/drbd0). Successivamente, attraverso il canale di comunicazione privato bond1 (che nel setup corrente è il channel bonding tra eth0 e eth1), si sincronizza con il modulo DRBD presente nell altro nodo ed esegue le medesime operazioni A questo punto è disponibile il block device /dev/drbd0 sull intero sistema. formato dai due nodi del cluster. Tale block device, gestito da DRBD in sincronia sui due nodi, è composto dalle due partizioni messe a disposizione da ciascun nodo. Il block device, pur presente e sincronizzato, non è ancora disponibile per le normali operazioni di input/output eseguite dal kernel 81

93 REALIZZAZIONE DEL PROGETTO in quanto va inizializzato e poi montato dopo aver creato su di esso il file-system desiderato. L inizializzazione del block device /dev/drbd0 prevede l assegnazione ad uno dei due nodi della capacità di scrittura. Con DRBD infatti solo un nodo alla volta è in grado di operare attivamente sul block device onde evitare inconsistenze negli accessi agli stessi dati da parte dei due nodi. Per questo motivo rispetto a un dato block device, ogni nodo può assumere il ruolo di primary se possiede la capacità di scrivervi e secondary nel caso non gli venga accordata. Se un nodo assume il ruolo di primary, avrà la possibilità di modificare il contenuto del block device ed il modulo DRBD si occuperò di trasferire e replicare le modifiche sull altro nodo. Il trasferimento avviene attraverso la rete privata e sarò il nodo secondary il responsabile di effettuare le modifiche sulla partizione destinata a far parte del block device DRBD. Tutto questo avviene in modo del tutto trasparente per l utente che non è in grado di entrare nel merito della gestione delle partizione destinate al block device, questo perché l eventuale tentativo di montare tali partizioni in modo manuale potrebbe produrre errori di grave entità che potrebbero indurre la perdita della sincronizzazione fra i nodi e quindi ad inconsistenze nei dati. 82

94 REALIZZAZIONE DEL PROGETTO I protocolli di sincronizzazione DRBD è basato su di un collegamento attraverso il protocollo TCP fra i due nodi del cluster, tale scelta è stata dettata da questioni di praticità e per l affidabilità del protocollo stesso. TCP è infatti incluso nel kernel Linux, quindi pienamente supportato, ed integra inoltre tra le sue specifiche funzionalità di riordinamento dei pacchetti e di controllo di flusso. Queste caratteristiche rendono possibile la dislocazione remota dei due nodi per consentire capacità di recupero dei dati estreme, che possono coprire fino all ultimo livello di disponibilità, ovvero il disaster recovery, attraverso la dislocazione geografica della ridondanza. Il collegamento fra i due nodi può essere reso più o meno interdipendente in base alla relazione tra la stabilità dell hardware e l affidabilità che si vuole raggiungere. A tale scopo vengono utilizzati tre differenti protocolli che definiscono al loro interno le caratteristiche che regolano il funzionamento di DRBD: Protocollo A. Questo metodo di connessione tra i due nodi consente il massimo grado di indipendenza. Se il nodo primario esegue un operazione di I/O 14, invia al secondario il comando di eseguire la stessa operazione. Non appena termina la scrittura sul dispositivo locale, il nodo primario invia al suo sistema operativo il segnale di aver terminato l operazione senza considerare cosa è avvenuto sul nodo secondario. 83

95 REALIZZAZIONE DEL PROGETTO Risulta evidente che se il primario va in crash dopo aver segnalato la fine di una scrittura, ma prima che il secondo abbia effettivamente ricevuto tutti i dati relativi all operazione di scrittura, allora la replica dei dati non può essere considerata speculare e si potrebbero verificare perdite di dati. A volte tuttavia questo protocollo può rendersi estremamente necessario nei casi in cui il collegamento alla rete interna presenti un elevata latenza. Se non vi fosse questo protocollo, il nodo primario sarebbe costretto ad attendere il segnale di termine delle operazioni di sincronizzazione attraverso la rete e ciò pregiudicherebbe l efficienza computazionale dell intero sistema. Protocollo B. Questo protocollo favorisce una maggiore sicurezza nella replica dei dati. Il funzionamento del DRBD è simile a quanto specificato per il protocollo A con l unica, ma cruciale, differenza che il nodo primario segnala al proprio sistema operativo (attraverso il quale un applicazione sta richiedendo operazioni di I/O) il termine dell operazione stessa, solo quando ha ricevuto dal secondario il pacchetto di risposta al comando di scrittura. Questo pacchetto viene inviato dal secondario al primario non appena egli riceve il comando di scrittura, comando che provvederà successivamente ad eseguire. 14 I/O: forma abbreviata per indicare Input/Output. Generalmente si riferisce ad operazioni eseguite su memorie coinvolgenti un flusso di dati. 84

96 REALIZZAZIONE DEL PROGETTO In effetti, pur fornendo una certa sicurezza in più, il protocollo B è una via di mezzo tra il già citato A ed il successivo C che garantisce il massimo livello di affidabilità. Protocollo C. Questo protocollo è il massimo dell affidabilità ottenibile da DRBD. Tale affidabilità è garantita dal fatto che il segnale di termine dell operazione di I/O, che il nodo primario invia al suo sistema operativo, è mandata solo quando si ha la garanzia che il nodo secondario abbia terminato la sua operazione di scrittura, ovvero quando i dati sono stati fisicamente replicati. E evidente che il tempo di attesa da parte del sistema operativo del nodo primario in questo caso comprende sia il tempo di scrittura sul nodo locale che sul nodo secondario oltre ovviamente al tempo di latenza del sistema di connessione di rete necessario al trasporto dei segnali di sincronizzazione relativi alle operazioni eseguite Installazione e configurazione di DRBD La procedura di installazione del software DRBD segue le classiche consuetudini sulla compilazione di un pacchetto nei i sistemi linux. Dopo aver navigato fino al sito internet del software (http://www.drbd.org), scaricare l ultima versione disponibile, nel caso 85

97 REALIZZAZIONE DEL PROGETTO specifico drbd tar.gz, copiarla nella directory scelta per la compilazione e scompattare il contenuto del pacchetto. alpha:~ cd /usr/local/src alpha:~ wget alpha:~ tar zxvf drbd tar.gz bravo:~ cd /usr/local/src bravo:~ wget bravo:~ tar zxvf drbd tar.gz Una volta decompresso il file si deve entrare nella cartella appena creata e lanciare i comandi di make per generare i moduli e gli eseguibili. Per evitare errori di compilazione è importante controllare che nel sistema siano presenti i sorgenti del kernel (tipicamente un pacchetto denominato kernel-source). alpha:~ cd drbd alpha:~ make clean all alpha:~ make tools alpha:~ make install bravo:~ cd drbd bravo:~ make clean all bravo:~ make tools bravo:~ make install Per completare l installazione DRBD va aggiunto all elenco dei programmi lanciati durante la fase di avvio della macchina. Il wrapper DRBD è stato inserito, dal processo di installazione, direttamente all interno della directory /etc/init.d, per cui è sufficiente eseguire il comando sysv-rc-conf ed impostarne l avvio nei runlevel di default per completare questa fase dell installazione. 86

98 REALIZZAZIONE DEL PROGETTO Figura 4-4 Impostazione di DRBD per l avvio al boot. Come già accennato nei paragrafi precedenti DRBD necessita di un canale di comunicazione, preferibilmente diretto, tra i due nodi per poter funzionare correttamente. A questo proposito, come già visto nel paragrafo 4.2.1, si possono migliorare le performance e il throughtput attraverso l adozione di un channel bonding. Anche in questo caso, quindi, si configurerà un interfaccia di bonding adibita unicamente alla sincronizzazione dei block device, andando nuovamente a modificare il file /etc/network/interfaces e restartando successivamente lo stack di rete per rendere effettive le modifiche. Per il nodo Alpha auto bond1 iface bond1 inet static address netmask post-up ifenslave bond1 eth0 eth1 pre-down ifenslave -d bond1 eth0 eth1 87

99 REALIZZAZIONE DEL PROGETTO Per il nodo Bravo auto bond1 iface bond1 inet static address netmask post-up ifenslave bond1 eth0 eth1 pre-down ifenslave -d bond1 eth0 eth1 alpha:~ /etc/init.d/networking restart * Reconfiguring network interfaces... [ ok ] bravo:~ /etc/init.d/networking restart * Reconfiguring network interfaces... [ ok ] La fase conclusiva per il funzionamento di DRBD riguarda la configurazione del file /dev/drbd.conf, al suo interno sono specificate le risorse che devono essere utilizzate e le modalità con cui DRBD dovrà utilizzarle Il file di configurazione drbd.conf Il file /etc/drbd.conf è formato da diverse sezioni, una per ogni risorsa configurata, o meglio, per ogni block device che si desidera aggiungere al cluster. Ogni riga che inizia con la parola chiave resource indica che si sta configurando un nuovo block device identificato dal nome che segue la parola stessa. Per ogni risorsa configurata ci sono poi diverse sottosezioni che definiscono le varie caratteristiche di ogni singolo block device. Tra le prime direttive da configurare si trova protocol che illustra il tipo di protocollo con cui DRBD deve effettuare la sincronizzazione sul device. Nel cluster che si sta costruendo, si utilizza il protocollo C per il 88

100 REALIZZAZIONE DEL PROGETTO particolare orientamento all alta affidabilità già esposto nel paragrafo Nell elenco seguente vengono illustrate le principali sezioni del file di configurazione, ognuna caratterizzata da una serie di parametri: startup: qui si definiscono le impostazioni relative all avvio del demone. Particolare attenzione meritano il parametro wfc-timeout, che specifica quanti secondi si deve attendere in fase di boot per avere un contatto dall altro nodo e degr-wfc-timeout che specifica quanti secondi si devono attendere prima di riavviare il nodo in caso di isolamento dal cluster. disk: specifica quale comportamento deve tenere DRBD in caso di errore I/O a basso livello nel device disco. net: in questa sezione vengono impostati tutti i parametri relativi alla connessione di rete, come ad esempio on-disconnect per il comportamento in caso di disconnessione della rete oppure pingint che specifica l intervallo di tempo tra i controlli di connettività. syncer: riporta i parametri inerenti la sincronizzazione con particolare riferimento a rate che imposta il limite massimo di occupazione di banda sulla connessione di rete. L ultima parte della sezione resource è quella più importante perché configura le risorse utilizzate da ogni nodo, identificando le partizioni fisiche e le interfacce di rete impiegate nel sistema. A tale proposito si 89

101 REALIZZAZIONE DEL PROGETTO noti che durante la fase di installazione del sistema operativo, si è provveduto a riservare alcune partizioni per la creazione dei block device DRBD. Tali partizioni hanno tutte la dimensione di 10 GB e sia sulla macchina denominata alpha che su quella bravo corrispondono ai device /dev/md6 e /dev/md7. Di seguito il dettaglio delle due risorse configurate per questo progetto: resource drbd0 { [...] on alpha { device /dev/drbd0; } disk /dev/md6; address :7788; meta-disk internal; } on bravo { device } /dev/drbd0; disk /dev/md6; address :7788; meta-disk internal; resource drbd1 { [...] on alpha { device /dev/drbd1; } disk /dev/md7; address :7789; meta-disk internal; } on bravo { device } /dev/drbd1; disk /dev/md7; address :7789; meta-disk internal; All interno di ogni sottosezione, che inizia con la parola on seguita dal nome del nodo che esporta le risorse, si trova innanzitutto la definizione del device che viene configurato, definito dai file /dev/drbd0 e 90

102 REALIZZAZIONE DEL PROGETTO /dev/drbd1. Con l attributo disk viene specificata quale sarà la partizione reale che deve essere esportata dallo specifico nodo per andare a far parte del block device condiviso. L attributo address si riferisce invece alla configurazione del modulo DRBD che verrà eseguito su ogni nodo e che, per la sincronizzazione fra i nodi, utilizzerà l indirizzo IP su alpha e su bravo. In entrambi i nodi sarà in ascolto sulla porta 7788 per il device drbd0 e 7789 per quello drbd1. Come si può notare per ogni risorsa aggiuntiva eventualmente configurata (relativa ad altri block-device) è necessario specificare una porta differente. Terminata la fase di configurazione del servizio, si può procedere con il suo avvio, verificando a posteriori che quanto sin qui realizzato funzioni in modo corretto e soprattutto che venga effettuata adeguatamente la sincronizzazione delle partizioni tra i nodi. Per prima cosa si procede con lo start del demone in entrambi i nodi attraverso lo script che l installazione ha posizionato in /etc/init.d e si controlli tramite lo stesso script lo stato del modulo. alpha:~/etc/init.d/drbd start Starting DRBD resources: [ d0 d1 s0 s1 n0 n1 ]. alpha:~/etc/init.d/drbd status drbd driver loaded OK; device status: version: (api:79/proto:74) SVN Revision: 2686 build by :08:27 0: cs:connected st:secondary/secondary ld:inconsistent ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 1: cs:connected st:secondary/secondary ld:inconsistent ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 bravo:~/etc/init.d/drbd start Starting DRBD resources: [ d0 d1 s0 s1 n0 n1 ]. 91

103 REALIZZAZIONE DEL PROGETTO bravo:~/etc/init.d/drbd status drbd driver loaded OK; device status: version: (api:79/proto:74) SVN Revision: 2686 build by :12:29 0: cs:connected st:secondary/secondary ld:inconsistent ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 1: cs:connected st:secondary/secondary ld:inconsistent ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 Come si può notare dall output del comando /etc/init.d/drbd status, entrambi i nodi vengono considerati in stato Secondary e la risorsa risulta Inconsistent; ciò sta ad indicare che la sincronizzazione non è ancora attiva, questo perché non è stato definito quale delle partizioni assegnate alla risorsa (e quindi quale nodo) sia da considerare come master tra le due. Lanciando il comando di seguito riportato, si imposta il nodo relativo come primario ed è possibile, controllando lo stato delle risorse, verificare che sia partita la sincronizzazione [30]. alpha:~ drbdadm -- --do-what-i-say primary drbd0 alpha:~ /etc/init.d/drbd status drbd driver loaded OK; device status: version: (api:79/proto:74) SVN Revision: 2686 build by :08:27 0: cs:syncsource st:primary/secondary ld:consistent ns:36 nr:0 dw:0 dr:38 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 [==>...] sync'ed:13.7% (8127/9402)M finish: 0:03:15 speed: 42,580 (38,416) K/sec 1: cs:connected st:secondary/secondary ld:inconsistent ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 bravo:~ /etc/init.d/drbd status drbd driver loaded OK; device status: version: (api:79/proto:74) SVN Revision: 2686 build by :12:29 0: cs:synctarget st:secondary/primary ld:consistent ns:0 nr:16 dw:16 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 [===>...] sync'ed: 16.7% (7840/9402)M finish: 0:02:46 speed: 48,044 (38,084) K/sec 1: cs:connected st:secondary/secondary ld:inconsistent ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 92

104 REALIZZAZIONE DEL PROGETTO bravo:~ drbdadm -- --do-what-i-say primary drbd1 bravo:~ /etc/init.d/drbd status drbd driver loaded OK; device status: version: (api:79/proto:74) SVN Revision: 2686 build by :12:29 0: cs:connected st:secondary/primary ld:consistent ns:0 nr:84 dw:84 dr:0 al:0 bm:76 lo:0 pe:0 ua:0 ap:0 1: cs:syncsource st:primary/secondary ld:consistent ns:0 nr:24 dw:24 dr:0 al:0 bm: 1 lo:0 pe:9 ua:0 ap:0 [>...] sync'ed: 0.7% (9347/9402)M finish: 0:02:47 speed: 56,924 (56,924) K/sec alpha:~ /etc/init.d/drbd status drbd driver loaded OK; device status: version: (api:79/proto:74) SVN Revision: 2686 build by :08:27 0: cs:connected st:primary/secondary ld:consistent ns:0 nr:84 dw:84 dr:0 al:0 bm:76 lo:0 pe:0 ua:0 ap:0 1: cs:synctarget st:secondary/primary ld:consistent ns:88 nr:0 dw:0 dr:48 al:0 bm:8 lo:1 pe:7 ua:90 ap:0 [>...] sync'ed: 3.6% (9073/9402)M finish: 0:04:07 speed: 37,500 (37,500) K/sec Terminata la sincronizzazione tra i due nodi si può controllare lo stato finale, verificando che le risorse siano connesse e consistenti. alpha:~ /etc/init.d/drbd start Starting DRBD resources: [ d0 d1 s0 s1 n0 n1 ]. alpha:~ /etc/init.d/drbd status drbd driver loaded OK; device status: version: (api:79/proto:74) SVN Revision: 2686 build by :08:27 0: cs:connected st:primary/secondary ld:consistent ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 1: cs:connected st:secondary/primary ld:consistent ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 A questo punto della configurazione si può procedere con la creazione del file system sulle risorse, si utilizza il comando mkfs.ext3 /dev/drbd0 per il nodo alpha e mkfs.ext3 /dev/drbd1 per il nodo bravo. Ultimata la scrittura del file system si può procedere con un test sul mounting per verificare che tutto funzioni correttamente, ma anche per accertarsi che se si tenta di utilizzare una risorsa da un nodo secondary questo viene correttamente impedito dal modulo DRBD. 93

105 Power Port Status Green = 100M, Yellow = 10M, Flash = Activity 3C16794 ä Power Port Status Green = 100M, Yellow = 10M, Flash = Activity 3C16794 ä REALIZZAZIONE DEL PROGETTO alpha:~ mkfs.ext3 /dev/hda9 [...] alpha:~ mount /dev/drbd1 /mnt alpha:~ df -k Filesystem 1K-blocks Used Available Use% Mounted on [...] /dev/drbd % /mnt bravo:~ mount -t ext3 /dev/drbd0 /mnt/ mount: block device /dev/drbd0 is write-protected, mounting read-only mount: /dev/drbd0 already mounted or /mnt/ busy A questo punto si è conclusa definitivamente la configurazione del sistema DRBD e si può visionare nello schema seguente lo stato di avanzamento del progetto di tesi. INTERNET / INTRANET Office Connect Switch 8 Office Connect Switch 8 CHANNEL BONDING bond bond eth2 eth3 eth3 eth2 CHANNEL BONDING /dev/drbd0 /dev/drbd1 eth0 bond1 DRBD CHANNEL BONDING eth1 eth0 bond eth1 RAID 1 Software RAID 1 Software ALPHA (KUBUNTU ) BRAVO (KUBUNTU ) Figura 4-5 Schema del progetto dopo l installazione di DRBD. 94

106 REALIZZAZIONE DEL PROGETTO 4.4 Configurazione di Heartbeat In questo paragrafo si analizza la configurazione e i meccanismi su cui si basa Heartbeat. Tale software caratterizza il funzionamento di buona parte del cluster realizzato in questo progetto, in quanto tiene traccia del funzionamento dei singoli nodi e prende le decisioni opportune laddove si verifichi un malfunzionamento. Come ogni software sviluppato per gli ambienti di tipo Unix, ed in particolare Linux, è una suite composta da un insieme di piccoli moduli altamente specializzati in una particolare funzione, che interagiscono costantemente tra loro per raggiungere un obiettivo finale. Questo stile volto alla modularizzazione consente di rendere molto snello ed efficiente lo sviluppo del software, in quanto in caso di manutenzione o aggiunta di nuove funzionalità, le modifiche coinvolgeranno solo i moduli direttamente interessati e non l intera suite La struttura di Heartbeat La figura 4.6 mostra che Heartbeat ha un architettura multiprocesso, questo è derivato non solo da ragioni storiche, ma anche da motivazioni 95

107 REALIZZAZIONE DEL PROGETTO riconducibili alla sicurezza. Il fatto che ogni processo gestisca separatamente un particolare aspetto della suite evita che il crash di una certa funzionalità coinvolga le altre. Dalla figura si evincono quattro tipologie di processi: primo e più importante è il Master Control Process (MCP), vengono poi i processi di lettura (read) e scrittura (write) e il processo di lettura FIFO (FIFO reader). Oltre a quelli già citati ci sono poi altri processi che possono essere considerati client, in quanto eseguono speciali operazioni e chiedono al Master Control Process di reagire conseguentemente. Tra questi i più importanti sono ipfail e Consensus Cluster Membership (CCM). READ ucast (eth0) WRITE ucast (eth0) READ serial (/dev/ttys0) WRITE serial (/dev/ttys0) FIFO Reader Master Control Process Client Child Process (ipfail) Client Child Process (ccm) Client Child Process (watchdog) Figura 4-6 Schema dei moduli di Heartbeat. 96

108 REALIZZAZIONE DEL PROGETTO Il Master Control Process è il cuore del sistema di monitoraggio. Ha il controllo dell intera attività della suite e si interfaccia con gli altri processi relativi ad Heartbeat, a cui invia e da cui riceve i dati necessari a prendere eventuali decisioni in caso di malfunzionamenti sui nodi. Scendendo nel dettaglio MCP provvede all invio dei segnali di heartbeat attraverso i canali configurati per il collegamento tra i nodi del cluster, gestisce i time-out sui segnali di heartbeat, attraverso i quali stabilire se un nodo è effettivamente funzionate, invia pacchetti firmati e autentica pacchetti ricevuti utilizzando gli appositi algoritmi crittografici e si occupa infine di avviare o riavviare i diversi processi della suite relativi alle diverse funzionalità implementate. Il processo FIFO reader ha l unico scopo di leggere la coda attraverso la quale comunicano i diversi processi di Heartbeat accessibili attraverso il file system al percorso /var/lib/heartbeat/fifo. La comunicazione fra i processi, attraverso la coda First-In-First-Out, è utilizzata quando i processi risiedono sulla stessa macchina ed è implementata aprendo in lettura o scrittura esclusiva la stessa coda. Il modulo FIFO reader evita che la gestione di tale comunicazione venga eseguita all interno del MCP evitandogli inutili sovraccarichi. I read processes sono processi adibiti esclusivamente alla lettura di messaggi da sottoporre al Master Control Process. Il loro funzionamento è molto simile al FIFO reader tranne per il fatto che i dati letti vengono ricevuti dall esterno attraverso i canali di comunicazione fra i nodi. 97

109 REALIZZAZIONE DEL PROGETTO Poiché i canali di comunicazione possono essere differenti per tipologia e funzione, è necessario che ci sia un processo di lettura per ogni tipo di canale da cui ricevere i dati. I write processes hanno le stesse caratteristiche dei read processes ma sono adibiti alla trasmissione di dati all esterno. Anche in questo caso si hanno processi di scrittura differenti in funzione del canale di comunicazione utilizzato. I client processes eseguono operazioni che si possono definire esterne all attività del Master Control Process: ad esempio ipfail che esegue un monitoraggio della connessione fra i nodi e stabilisce quando è necessario eseguire il failover del gruppo di servizi, richiedendo al MCP di eseguire materialmente questa operazione. CCM invece, acronimo di Consensus Cluster Membership, è un client process che svolge la funzione di monitorare lo stato del cluster per fornire in ogni momento, al Master Control Process, le informazioni relative ai nodi del cluster effettivamente connessi e pienamente funzionanti. Ogni nodo, grazie al CCM, è consapevole del fatto di essere o meno membro del cluster ed i nodi parzialmente collegati (per un interruzione dei canali ridondati) non vengono considerati membri del cluster e non possono accogliere un eventuale failover. È evidente che questo componente assume un importanza crescente all aumentare del numero dei nodi che compongono il cluster benché la sua funzione rimane indispensabile anche con cluster formati da due soli nodi[4]. 98

110 REALIZZAZIONE DEL PROGETTO I plugin di Heartbeat I moduli sin qui descritti costituiscono il nucleo della suite e assolvono le funzioni primarie necessarie al funzionamento del cluster. Questo nucleo centrale non implementa però alcune funzionalità esterne ed orientate al contesto operativo in cui verrà collocato il cluster. Al fine di interfacciarsi con il mondo esterno Heartbeat si appoggia a dei plugin che vengono utilizzati in modo opportuno in funzione del tipo di ambiente in cui opera, come illustrato nella figura 4.7 questi possono essere classificati in tre categorie: plugin di STONITH, plugin di comunicazione, plugin di autenticazione. Heartbeat Heartbeat Plugin Infrastructure Communication Plugin STONITH Plugin Authentication Plugin Heartbeat Client Process (ccm, ipfail, etc.) Resource Script Figura 4-7 Moduli esterni di Heartbeat. I plugin di STONITH implementano tutte le funzioni necessarie per far fronte al problema del brain-splitting. STONITH è l acronimo di Shoot 99

111 REALIZZAZIONE DEL PROGETTO The Other Node In The Head ed è un meccanismo che si occupa di disattivare istantaneamente un nodo del cluster quando se ne presenta la necessità, in particolare quando uno stesso gruppo di servizi è erogato da più di un nodo per via di un failover sbagliato, causato per esempio dall interruzione simultanea di tutti i canali di comunicazione interna. Questo plugin sfrutta un dispositivo hardware collegato al cluster, attraverso la rete ehternet oppure le porte seriali, che è in grado di comunicare con Heartbeat e ricevere comandi. Tale dispositivo gestisce l erogazione di energia elettrica a ciascuno dei nodi del cluster cosicché, in caso di brain-splitting è in grado di bloccare istantaneamente il funzionamento di uno dei nodi. In questo progetto essendo l erogazione dell energia elettrica della sala macchine fornita da un unico gruppo di continuità non è possibile utilizzare questa funzionalità. Tutte le comunicazioni verso l esterno, eseguite da Heartbeat sono gestite da plugin, i canali supportati per questi scambi di informazioni comprendono UDP di tipo broadcast, multicast e unicast e le comunicazioni attraverso porte seriali. Tali plugin si occupano di inviare al kernel le richieste necessarie all invio dei segnali generati dai vari moduli del nucleo della suite o alla ricezione di quelli provenienti dall esterno. I plugin di autenticazione forniscono tutte le funzionalità riguardanti la sicurezza delle comunicazioni fra i nodi del cluster. Tutti i messaggi scambiati dai nodi sono accompagnati da chiavi di autenticazione che 100

112 REALIZZAZIONE DEL PROGETTO consentono ai nodi che li ricevono di stabilire se un certo segnale ricevuto sia autentico ed effettivamente proveniente da un certo nodo. Tre sono gli algoritmi di crittografia implementi, utilizzabili a seconda del livello di sicurezza ed il consumo di CPU che si vuole ottenere: il primo è il CRC semplice ma anche meno sicuro, il secondo è l algoritmo MD5 mentre il terzo è SHA1 che offre una codifica difficilmente reversibile ma richiede un carico di lavoro decisamente supplementare e superfluo a meno di una comunicazione di sincronizzazione che passi attraverso segmenti di rete non esclusivamente ad utilizzo dei nodi del cluster. I resource script sono componenti esterni di Heartbeat e sono file eseguibili in formato testo che possono essere modificati dall amministratore di sistema per essere adattati alle specifiche esigenze e vengono invocati automaticamente da Heartbeat per svolgere funzioni particolari oppure richiamati dall amministratore per gestire alcuni aspetti della suite Il Resource Group Nella logica di Heartbeat si definisce risorsa ogni entità del sistema che Heartbeat gestisce [29]. Una risorsa può essere ad esempio un indirizzo 101

113 REALIZZAZIONE DEL PROGETTO IP, un servizio come Apache o MySQL, un componente hardware come un unità disco, una risorsa del kernel come un file system. Per ogni risorsa gestita da Heartbeat esiste uno script in grado di eseguirne lo start e lo stop analogamente a quanto succede con gli script presenti in /etc/init.d. Si parla di Resource Group per via del fatto che l operazione di takeover, da un nodo all altro, interessa tutte le risorse che un certo nodo del cluster gestisce. Per esempio il resource group di un dato nodo potrebbe essere composto da un indirizzo IP sul quale fornisce dei servizi, una certa partizione di disco affidata a DRBD sulla quale ad esempio svolge un ruolo primario ed i servizi forniti sull indirizzo specificato all inizio. Nel momento in cui il nodo dovesse cadere, il resource group viene interamente migrato sull altro nodo e le risorse trasferite vengono attivate così com erano sul nodo caduto Installazione e configurazione di Heartbeat La procedura di installazione di Heartbeat segue le classiche consuetudini sulla compilazione di un pacchetto nei i sistemi linux. Dopo aver navigato fino al sito internet del software (http://www.linux-ha.org), scaricare l ultima versione disponibile, nel 102

114 REALIZZAZIONE DEL PROGETTO caso specifico heartbeat tar.gz, copiarla nella directory scelta per la compilazione e scompattare il contenuto del pacchetto. alpha:~ cd /usr/local/src alpha:~ wget alpha:~ tar zxvf heartbeat tar.gz bravo:~ cd /usr/local/src bravo:~ wget bravo:~ tar zxvf heartbeat tar.gz Prima di effettuare la compilazione è necessario eseguire alcune operazioni a livello di sistema operativo per preparare l ambiente: Heartbeat richiede infatti che siano presenti in entrambi i nodi un utente ed un gruppo ad esso dedicati. alpha:~ groupadd hacluster alpha:~ useradd -g hacluster -d /nonexistent -m hacluster bravo:~ groupadd hacluster bravo:~ useradd -g hacluster -d /nonexistent -m hacluster Una volta creato l utente e decompresso il file si deve entrare nella cartella appena creata e lanciare gli opportuni comandi necessari alla compilazione. alpha:~ cd /usr/local/src/heartbeat alpha:~./configureme configure alpha:~ make alpha:~ make install bravo:~ cd /usr/local/src/heartbeat bravo:~./configureme configure bravo:~ make bravo:~ make install Per completare l installazione di Heartbeat il suo script di avvio va aggiunto all elenco dei programmi lanciati durante la fase di avvio della macchina. Lo script di avvio di Heartbeat è stato inserito, dal processo di installazione, direttamente all interno della directory /etc/init.d, per 103

115 REALIZZAZIONE DEL PROGETTO cui è sufficiente eseguire il comando sysv-rc-conf ed impostarne l avvio nei runlevel di default. Figura 4-8 Impostazione di Heartbeat per l avvio al boot. Anche Heartbeat, come ogni software per piattaforma *nix, si configura attraverso determinati file di configurazione. Nel caso specifico prima di poterli modificare a piacimento, i file vanno copiati dalla cartella contenente i documenti in /usr/share/doc/heartbeat-2.0.8/ alla /etc/ha.d. alpha:~ cd /usr/share/doc/heartbeat-2.0.8/ alpha:~ cp ha.cf haresources authkeys /etc/ha.d/ alpha:~ chmod 600 authkeys bravo:~ cd /usr/share/doc/heartbeat-2.0.8/ bravo:~ cp ha.cf haresources authkeys /etc/ha.d/ bravo:~ chmod 600 authkeys La configurazione di questi tre file evidenzia le politiche di gestione delle risorse decise in fase di progetto e le funzioni di recovery e 104

116 REALIZZAZIONE DEL PROGETTO monitoraggio che si è scelto di attivare. Si tenga presente che i file di configurazione debbono essere identici in entrambi i nodi. IL FILE HARESOURCES Nel file haresources vengono configurati i resource group per ciascuno dei nodi coinvolti nel cluster. Questo progetto utilizza una configurazione Active/Active ed il file conterrà quindi due righe, una per nodo, con definiti i servizi che dovranno essere erogati da ognuno. All inizio di ogni riga si trova l hostname del nodo (come specificato dall output del comando uname -n) che è destinato ad ospitare inizialmente il resource group. Per i servizi che si devono erogare, come mostrato nei paragrafi precedenti, si sono già configurati due device DRBD denominati drbd0 e drbd1. Con lo script drbddisk Heartbeat è in grado di dare al nodo il ruolo di primario per il device specificato, provvedendo inoltre a montare attraverso lo script Filesystem il device nel percorso definito. Accertata l esistenza della cartella per il mounting, ed eventualmente creandola con il comando mkdir in caso negativo, si può procedere alla stesura del file utilizzando le seguenti righe di configurazione. alpha drbddisk::drbd0 Filesystem::/dev/drbd0::/var/lib/vmware/VirtualMachinesALPHA::ext3 bravo drbddisk::drbd1 Filesystem::/dev/drbd1::/var/lib/vmware/VirtualMachinesBRAVO::ext3 In particolare lo script drbddisk esegue il comando drbdadm primary drbdx per rendere primario il nodo e montare il dispositivo, drbdadm 105

117 REALIZZAZIONE DEL PROGETTO secondary drbdx per rendere il nodo secondario dopo aver smontato il device ed eseguire eventualmente il takeover del resource group. A questo punto si possono inserire, di seguito nella riga, i wrapper dei servizi che si vogliono erogare, ma si vedrà questa fase più avanti nel capitolo nella parte relativa all installazione del software di virtualizzazione. IL FILE HA.CF Il file ha.cf viene letto da Heartbeat nel momento in cui se ne effettua l avvio attraverso il comando /etc/init.d/heartbeat start. Tale file contiene le impostazioni necessarie affinché la suite sia configurata per adattarsi alle specifiche del sistema che si vuole realizzare e per soddisfare le politiche di gestione che si sono stabilite in fase di progetto. Di seguito si analizzerà questo file, contenuto integralmente in appendice, illustrandone le principali opzioni utilizzate. keepalive 2 specifica il tempo in secondi che intercorre tra due segnali di heartbeat inviati ai nodi; deadtime 5 indica quanto tempo in secondi si deve attendere dall ultimo segnale di heartbeat ricevuto per poter dichiarare il nodo definitamene non funzionante; initdead 120 imposta un timing in secondi per il bypass del parametro di deadtime ed è valido solamente all avvio del 106

118 REALIZZAZIONE DEL PROGETTO servizio di Heatbeat. Questo è studiato dare tempo al demone di stabilire le connessioni ed inizializzare i diversi plugin, al fine di evitare un takeover delle risorse prima ancora che il sistema si sia completamente inizializzato su tutti i nodi; auto_failback on definisce un particolare comportamento del cluster in caso di failure di un nodo. Secondo la configurazione scelta se un nodo rientra nel cluster dopo esserne uscito per un malfunzionamento o per una eventuale manutenzione, il resource group configurato per default su tale nodo viene automaticamente riportato su di esso. È evidente che i servizi torneranno ad essere erogati da tale nodo solo dopo che il file system condiviso è stato risincronizzato, ma sarà compito di DRBD verificare il corretto andamento di questo processo. baud e serial /dev/ttys0 questi parametri vengono utilizzati nel caso si decida, per ulteriori motivi di sicurezza, di utilizzare anche la connessione seriale per il sottosistema di comunicazione. Questa configurazione prevede che le due macchine siano collegate tra loro, sulle rispettive porte seriali, mediante un cavo di tipo null modem. La verifica del corretto funzionamento del cavo e delle porte è possibile tramite alcuni semplici comandi riportati di seguito: bravo:~ cat </dev/ttys0 alpha:~ echo "Hello World" >/dev/ttys0 107

119 REALIZZAZIONE DEL PROGETTO nella console della macchina bravo dovrebbe apparire la scritta "Hello World", segnale che la comunicazione si è svolta correttamente. bcast bond0 e bcast bond1 specifica gli altri canali utilizzati per il segnale di sincronizzazione ridondando quello seriale ed evitando così l introduzione di single point of failure. Si noti che i due canali bond0 e bond1 sono di per sé già ridondati per i motivi spiegati nel paragrafo 4.2.1; watchdog /dev/watchdog watchdog è uno strumento atto al reboot del sistema qualora qualcosa non funzioni correttamente. Ad esempio nel caso in cui il kernel risponda in modo anomalo, oppure qualche programma occupi il 100% dei cicli di cpu. L idea è quella di avere un device /dev/watchdog in cui il sistema operativo si preoccupi di scrivere ad intervalli di tempo regolari e ben definiti. Se una delle scritture fallisce il computer viene riavviato. Per rendere operativa questa funzionalità è necessario prima apportare alcune modifiche al sistema operativo, ed in particolare aggiungere la voce softdog al file /etc/modules e successivamente inserire nel file /etc/modprobe.d/arch/i386 la seguente riga: options softdog nowayout=0 108

120 REALIZZAZIONE DEL PROGETTO L opzione nowayout=0 indica che il computer non deve essere rebottato anche nel momento in cui il device viene chiuso. Questo per evitare noiosi riavvii anche quanto, per esempio, viene fatto lo shutdown del servizio Heartbeat [31][33]; node alpha e node bravo indica i nomi dei nodi del cluster così come risulta dall output del comando uname -n; respawn hacluster /usr/lib/heartbeat/ipfail Questa riga, ed in generale quelle di questo tipo, sono di particolare importanza in quanto provvedono a far eseguire ad Heartbeat comandi corrispondenti a plugin appartenenti alla suite o comandi esterni, che vengono lanciati come processi figli dello stesso Heartbeat. Il comando respawn all inizio della riga, indica che Heartbeat si occuperà di monitorare costantemente il funzionamento del processo, preoccupandosi di rilanciarlo nel caso in cui venga interrotto. In questo caso, come utente hacluster, viene eseguito il plugin ipfail che si occupa di monitorare costantemente il collegamento del nodo con l esterno. Se il nodo dovesse risultare isolato ed evidentemente non nelle condizioni di erogare il servizio ipfail richiederà un failover del resource group; ping l ultima riga analizzata configura l indirizzo IP verso cui eseguire il comando ping utilizzato da 109

121 REALIZZAZIONE DEL PROGETTO ipfail per verificare il collegamento del nodo con l esterno. È evidente che tale IP deve corrispondere a un host sicuro e sempre funzionante ed in questo caso è stato scelto il gateway della rete esterna [32]. IL FILE AUTHKEYS Come analizzato nel paragrafo , tutte le comunicazioni che avvengono fra i nodi sono cifrate e autenticate al fine di evitare problemi di sicurezza che potrebbero falsare il corretto funzionamento di Heartbeat. Attraverso i plugin di autenticazione, Heartbeat consente l utilizzo di algoritmi crittografici più o meno sicuri affinché si renda possibile un corretto bilanciamento fra prestazioni e sicurezza in relazione all ambiente operativo del cluster[4]. Nel file authkeys si configura appunto l algoritmo crittografico per le comunicazioni fra i nodi ed in particolare attraverso le seguenti righe, si specifica al cluster di utilizzare l algoritmo SHA1. auth 2 2 sha1 pwd!hacluster Questa scelta è dovuta al fatto che le comunicazioni fra i nodi avvengono anche attraverso un canale di rete insicuro ed oltretutto l overhead computazionale introdotto dalla codifica con SHA1 rispetto al CRC o MD5 è assolutamente irrilevante per la potenza di calcolo dell hardware in uso. 110

122 Power Port Status Green = 100M, Yellow = 10M, Flash = Activity 3C16794 ä Power Port Status Green = 100M, Yellow = 10M, Flash = Activity 3C16794 ä REALIZZAZIONE DEL PROGETTO A questo punto può dirsi conclusa anche l installazione e la configurazione di Heartbeat, si può avere un quadro complessivo di quanto realizzato sin qui attraverso la figura 4.9. INTERNET / INTRANET Office Connect Switch 8 Office Connect Switch 8 CHANNEL BONDING bond bond eth2 eth3 IPFAIL eth3 eth2 CHANNEL BONDING ttys0 ttys0 HEARTBEAT /dev/drbd0 /dev/drbd1 eth0 eth0 DRBD bond1 bond CHANNEL BONDING WATCHDOG eth1 eth1 WATCHDOG RAID 1 Software ALPHA (KUBUNTU ) RAID 1 Software BRAVO (KUBUNTU ) UPS SYSTEM Figura 4-9 Schema del progetto dopo l installazione di Heartbeat. 111

123 REALIZZAZIONE DEL PROGETTO 4.5 Configurazione delle Virtual Machines Dopo aver configurato lo storage condiviso tramite DRBD ed aver messo in opera l alta affidabilità tramite la suite Heartbeat, si può procedere all installazione del software necessario per far girare le macchine virtuali. Il prodotto scelto per questa fase, come già descritto nei paragrafi precedenti, è la suite VMware Server, un prodotto gratuito che ha preso il posto della versione GSX Server. La versione rilasciata da pochi mesi ha stupito per le notevoli potenzialità: non si tratta infatti solo di un prodotto per l utilizzo di virtual machine in ambito server, ma anche una soluzione estremamente interessante per chi vuole avvicinarsi al mondo della virtualizzazione sfruttando un prodotto gratuito. Anche se non dispone di tutte le funzionalità avanzate offerte dagli altri prodotti della stessa software house, come Workstation o ESX, offre certamente grande flessibilità, in particolare per l utilizzo all interno di gruppi di lavoro, grazie soprattutto alle funzionalità di controllo remoto e di monitoring attraverso la rete. VMware Server deve essere installato come demone su una macchina che svolga funzioni di server e che sia dotata di adeguate risorse hardware. Le macchine virtuali create sfruttano le risorse del server, questo da il vantaggio di poterle controllare anche da un client con limitate capacità di calcolo. L accesso al server ed alle altre funzioni 112

124 REALIZZAZIONE DEL PROGETTO offerte dal prodotto della casa californiana, richiedono ovviamente una autenticazione che VMware Server permette di integrare con permessi e criteri di protezione per le macchine virtuali disponibili. Il client per l accesso al server è VMware Server Console, un pacchetto separato ed indipendente, disponibile anch esso gratuitamente sul sito di VMware. La console viene utilizzata per gestire le vm presenti su una qualsiasi macchina dotata di VMware Server, e si può farlo direttamente dallo stesso server oppure da una qualsiasi workstation remota. Una feature molto interessante è la possibilità, per diverse console, di connettersi contemporaneamente ad una virtual machine, permettendo a più utenti di avere un accesso concorrente. VMware Server è dotato anche di una interfaccia di gestione via web, denominata VMware Management Interface (MUI), che non è un alternativa alla server console, ma offre strumenti di controllo sull uso delle risorse da parte delle virtual machine in esecuzione [41][42] Installazione e configurazione di VMWare Come illustrato nel paragrafo precedente l installazione della suite VMware Server prevede l utilizzo di tre pacchetti. Dopo aver provveduto al download dell ultima versione per Linux dei package, dal sito della software house (http://www.vmware.com) si può procedere con la loro 113

125 REALIZZAZIONE DEL PROGETTO installazione e configurazione. Tutte le fasi si intendono, dove non esplicitamente specificato, speculari per entrambi i nodi del cluster. VMWARE SERVER Dopo aver scaricato il file VMware-server tar.gz nella directory prescelta, si è provveduto alla decompressione dello stesso ed al posizionamento nella cartella che ha creato. alpha:~ cd /usr/local/src alpha:~ tar zxvf VMware-server tar.gz alpha:~ cd vmware-server-distrib All interno della cartella vmware-server-distrib si trova lo script che è necessario eseguire per avviare l installazione, tale file è scritto in Perl ed è quindi indispensabile, per proseguire, che tutti i package relativi a questo linguaggio siano installati nel sistema operativo. alpha:~./vmware-install.pl Lo script, nel corso dell esecuzione, pone alcune domande in relazione ai path in cui posizionare i vari componenti del programma. Conclusa la fase di copia dei file viene automaticamente avviato un secondo script (/usr/bin/vmware-config.pl) per l impostazione dei parametri di avvio del programma. È importante ricordare che questo comando sarà utilizzabile anche in un secondo momento per qualsiasi eventuale modifica alle configurazioni di VMware Server. La prima cosa richiesta da vmware-config.pl è l accettazione della licenza d uso del programma mentre la seconda è l ubicazione dei sorgenti del kernel. 114

126 REALIZZAZIONE DEL PROGETTO Questo perché il Virtual Machine Monitor, già ampliamente descritto nel capitolo 3 e che VMware chiama vmmon, viene compilato appositamente per il kernel in uso in base alla macchina su cui dovrà andare in esecuzione. Proseguendo nella configurazione ci si addentra in una delle parti più cruciali per la virtualizzazione di macchine server: il networking. Dopo aver risposto in modo affermativo alla domanda sull utilizzo della rete da parte della macchine virtuali, si deve scegliere come mappare le interfacce di rete utilizzate da vmmon, a questo scopo si possono scegliere tre differenti modalità di funzionamento: bridged: è la configurazione di default, oltre che quella maggiormente utilizzata, con questo sistema la scheda di rete della macchina virtuale appare come un clone di quella reale e la vm è come se fosse direttamente connessa alla stessa sottorete della macchina che la ospita; host only: ogni macchina è dotata di una scheda di rete virtuale. Si realizza in tal modo una sottorete indipendente tra le macchine virtuali e la macchina host. Con questa modalità, nel caso si desideri far navigare le vm, è necessario configurare il sistema operativo ospite come gateway della sottorete attraverso adeguate regole di routing; NAT: questa opzioni è del tutto simile alla host only con l unica differenza che la macchina host si occupa automaticamente di 115

127 REALIZZAZIONE DEL PROGETTO effettuare il natting dei pacchetti provenienti dalla sottorete virtuale. In questo caso si è scelta l opzione bridged in modo da poter assegnare alle macchine virtuali, che fungeranno da server, un indirizzo IP pubblico attraverso il quale offrire i loro servizi. La scheda di rete reale scelta per il bridge è chiaramente l interfaccia bond0. Terminata la compilazione del modulo kernel relativo all interfaccia di rete vmnet0, corrispondente alla scheda virtuale di tipo bridged, va impostata la porta sulla quale è in ascolto VMware Server ed attraverso la quale VMware Server Console accede alle macchine virtuali. Nella parte conclusiva della configurazione viene chiesto in quale cartella si desidera memorizzare le macchine virtuali, per questa opzione le soluzioni adottate sono differenti per i due nodi. Essendo il cluster in configurazione Active/Active, in caso di crash di un nodo l altro prenderebbe in carico tutti i servizi, montando di conseguenza tutti i file system condivisi. Non potendo per ovvi motivi effettuare il mounting di due device sulla stessa cartella, si ha la necessità di definire un mount point differente per ogni nodo. Questo ha portato alla scelta della cartella /var/lib/vmware/virtualmachinesalpha per il nodo alpha e la directory /var/lib/vmware/virtualmachinesbravo per il nodo bravo. L ultima operazione necessaria per finire l installazione del prodotto è l inserimento di un numero seriale. VMware Server rimane comunque un prodotto gratuito, ma per utilizzarlo liberamente richiede un serial 116

128 REALIZZAZIONE DEL PROGETTO number che la società fornisce gratuitamente dietro la compilazione di un form informativo presente sul sito web di VMware all indirizzo Il messaggio finale di avvio dei servizi sulla macchina host, garantisce che tutta la procedura si è conclusa correttamente e si può procedere con l installazione degli altri componenti. [...] Starting VMware services: Virtual machine monitor Virtual Ethernet Bridged networking on /dev/vmnet0 done done done The configuration of VMware Server build for Linux for this running kernel completed successfully. VMWARE MANAGEMENT INTERFACE In modo analogo a quanto già fatto per la parte server, dopo aver scaricato il file VMware-mui tar.gz in /usr/local/src si procede alla decompressione e all avvio dello script di installazione. alpha:~ cd /usr/local/src alpha:~ tar -zxvf VMware-mui tar.gz alpha:~ cd vmware-mui-distrib alpha:~./vmware-install.pl Viene richiesta l accettazione della licenza d uso e quali cartelle utilizzare per i file del pacchetto dopodiché si avvia automaticamente lo script di configurazione /usr/bin/vmware-config.pl. Diversamente dal pacchetto Server, la Management Interface non ha molti parametri di configurazione, è sufficiente definire il solo timeout delle sessioni web per terminare le impostazioni. L output finale del comando ci comunica che tutto si è svolto in modo corretto. 117

129 REALIZZAZIONE DEL PROGETTO [...] Starting httpd.vmware: done The configuration of VMware Management Interface completed successfully. Anche se tutto è andato a buon fine lo script non si occupa di impostare l avvio automatico al boot del sistema del demone relativo alla Management Interface. Per questo motivo, come già accaduto per DRBD ed Heartbeat, si deve agire in modo autonomo sul demone httpd.vmware tramite il comando sysv-rc-conf. A questo punto si può aprire un browser qualunque e puntare all indirizzo di uno dei nodi, sulla porta 8222 oppure 8333, per verificarne il funzionamento. Per ovvi motivi di sicurezza il sito utilizza il protocollo HTTPS e di conseguenza al primo accesso verrà chiesto di accettare il certificato SSL, che VMware a generato autonomamente, solo dopo si potrà accedere alla maschera di login. Figura 4-10 La finestra di login di VMware Management Interface. VMWARE SERVER CONSOLE L ultimo strumento che è necessario installare per rendere completamente operativo il nostro virtual server, è anche il più facile e 118

130 REALIZZAZIONE DEL PROGETTO veloce. Per l installazione è infatti sufficiente effettuare il download del package necessario nella solita cartella /usr/local/src, decomprimere il pacchetto e lanciare lo script di installazione vmware-install.pl. Dopo aver indicato le cartelle di default per la copia dei file ed aver accettato la licenza d uso, si avvierà automaticamente lo script /usr/bin/vmware-config-server-console.pl che senza porre alcuna domanda concluderà la configurazione della console Installazione delle Virtual Machines Con l installazione delle macchine virtuali si entra nel vivo del progetto e si cominciano a rendere produttivi i software configurati fino ad ora. Nel corso del paragrafo si mostreranno i passi per la messa in opera di una macchina virtuale. Nel caso specifico si installerà una distribuzione SUSE Linux Enterprise Server 9 sul nodo alpha.centrale.unipg.it, ma è evidente che la medesima procedura può essere adottata per l installazione delle altre vm di cui si ha necessità. La prima cosa da fare è avviare la VMware Server Console la quale chiede subito se ci si vuole collegare alla macchina locale (localhost) oppure ad un server remoto tramite autenticazione, avendo effettuato il login direttamente sul server, in questa situazione, si sceglie la prima opzione. 119

131 REALIZZAZIONE DEL PROGETTO Appare cosi l interfaccia della console dalla quale si può partire per creare una nuova Virtual Machine. Il pulsante al centro Create a new virtual machine è quello da premere per iniziare l inserimento dei parametri. Figura 4-11 La schermata iniziale di VMware Server Console. Le prime informazioni richieste riguardano la tipologia di sistema operativo che dovrà essere ospitato (Red Hat, Suse, Windows XP, Windows 2000 solo per citarne alcuni) e la posizione in cui si desidera salvare i file. In questo caso la cartella scelta è ovviamente /var/lib/vmware/virtualmachinesalpha ma poiché il nome scelto per la VM è echo.centrale.unipg.it ed il sistema operativo è SUSE, la sottocartella in cui andremo a posizionare i file si chiamerà EchoSUSE. Questa sequenza di passaggi sono visibili in modo dettagliato negli snapshot riportati in figura

132 REALIZZAZIONE DEL PROGETTO Figura 4-12 Fasi iniziali della configurazione di una vm con VMware Server Console. La parte successiva della configurazione si occupa dei device che il Virtual Machine Monitor deve emulare, ed in particolare: il numero dei processori: VMWare Server supporta infatti anche un emulazione biprocessore molto utile nei casi di vm con grande carico di lavoro ed hardware reale compatibile. la RAM: cruciale per il buon funzionamento di tutte le macchine, nel caso di una vm deve essere adeguatamente calibrata per evitare di lasciare l host oppure la vm a corto di risorse. In questo caso per definire il quantitativo giusto di RAM si debbono tenere in considerazione due fattori: il primo riguarda l alta affidabilità, nel senso che in caso di crash di un nodo il rimanente dovrà prendere in carico tutte le macchine virtuali e 121

133 REALIZZAZIONE DEL PROGETTO dovrà quindi essere in grado di offrire sufficiente memoria. Il secondo riguarda il fatto che alcune delle macchine virtuali che andremo ad installare, non hanno grandi richieste e si accontentano di 64 MB di RAM. Alla luce di quanto esposto e considerando che entrambi i nodi hanno 1 GB di RAM, si è deciso di assegnare alla macchina echo un quantitativo di RAM pari 256 MB. i dischi: considerando lo spazio a disposizione sullo storage condiviso e lo scopo per cui vengono utilizzate le macchine virtuali, si è quantificato che 4 GB siano sufficienti per un corretto funzionamento. È importante notare che è stata selezionata l opzione Allocate all disk space now per ottimizzare il traffico sullo storage condiviso, evitando successivi comandi di ampliamento dei file disco della macchina virtuale. la rete: fondamentale per far comunicare le virtual machines con l esterno, va configurata in modalità bridged sull interfaccia bond0 per le motivazioni già spiegate nel paragrafo precedente. Inserite tutte le informazioni necessarie al processo di creazione, si può cliccare sul tasto Finish e VMWare Server Console provvederà alla creazione dei dischi virtuali. Conclusa l allocazione dello spazio necessario si tornerà alla schermata principale dalla quale premendo il tasto Power On si può avviare la macchina virtuale e procedere con l installazione del sistema operativo. 122

134 REALIZZAZIONE DEL PROGETTO Figura 4-13 Configurazione hardware di una vm con VMware Server Console. Figura 4-14 Installazione del sistema operativo in una macchina virtuale. Riutilizzando in modo iterativo la procedura descritta in questo paragrafo, si sono successivamente installate un totale di due macchine 123

135 REALIZZAZIONE DEL PROGETTO virtuali per ogni nodo, secondo le caratteristiche sintetizzate nella tabella seguente. Nome Virtual Machines S.O. RAM Disco Nodo charlie.centrale.unipg.it ( ) delta.centrale.unipg.it ( ) echo.centrale.unipg.it ( ) Windows XP 64 4 GB alpha Kubuntu GB bravo SUSE ES GB alpha foxtrot.centrale.unipg.it ( ) Windows 2000 AS GB bravo Tabella 4-1 Caratteristiche delle macchine virtuali installate nei nodi. VMWARE TOOLS Dopo aver installato il sistema operativo su un qualsiasi computer, la prima cosa da fare è ovviamente caricare i driver della scheda madre e delle principali periferiche utilizzate. Allo stesso modo, al termine dell installazione di un sistema operativo all interno di una macchina virtuale, è quasi sempre necessario installare i driver forniti dal produttore del software di virtualizzazione, che in questo caso si chiamano VMware Tools. Questi tools possono essere caricati sul sistema attraverso una delle voci di menu della console che simulerà l inserimento di un CD, con il software da installare, all interno della virtual machines. Sarà sufficiente seguire le semplici indicazioni riportate sul video, senza la necessità di impostare alcun parametro particolare, per portare a 124

136 REALIZZAZIONE DEL PROGETTO termine l installare dei driver ed ottenerne i relativi vantaggi nella compatibilità e nelle prestazioni. Figura 4-15 Le fasi di installazione dei VMware Tools in una macchina virtuale. 4.6 Integrazione di tutto il sistema Tutti i software necessari sono stati installati e ciò di cui si ha bisogno a questo punto del progetto, è una loro corretta integrazione finalizzata al raggiungimento degli scopi che ci si è prefissati sin dall inizio. Per integrare il sistema è necessario fare in modo che heartbeat non si preoccupi solo di gestire il mounting delle partizioni, come ha fatto 125

137 REALIZZAZIONE DEL PROGETTO fino ad ora, ma sia in grado anche di avviare ed arrestare le macchine virtuali del cluster. Come mostrato nel paragrafo relativo all installazione e configurazione di heartbeat, per ogni risorsa che deve essere gestita viene utilizzato un apposito script ubicato nella cartella /etc/ha.d/resource.d/. Nella stessa cartella, il pacchetto originale di heartbeat, fornisce alcuni script preconfigurati per lo start e lo stop dei servizi maggiormente utilizzati, tra questi si trovano quelli relativi a drbd, raid ed lvm. In questa cartella, e nella documentazione di heartbeat, non si fa però alcun riferimento all utilizzo di questo software in combinazione con macchine virtuali. Questa mancanza si verifica principalmente per due motivazioni: la prima per la recente uscita in versione gratuita di VMware Server e la seconda per l assoluta novità che il suo utilizzo con heartbeat rappresenta. Nel corso di questo paragrafo si descriverà la realizzazione di uno script apposito per il management delle risorse virtuali, da utilizzare all interno di heartbeat. Questo script rappresenta di fatto il fulcro di tutto il progetto ed il punto di congiunzione di tutti i software di cui si è parlato sin ora. Prima di iniziare con la stesura del codice è bene comprendere quali sono gli strumenti di cui si avrà bisogno. Andando ad operare con le macchine virtuali di VMware Server è indispensabile avere a disposizione un comando che consenta di agire direttamente sulle vm in 126

138 REALIZZAZIONE DEL PROGETTO esecuzione. Proprio per venire in contro a queste esigenze, la software house ha inserito nel suo pacchetto server una serie di comandi, tra i quali il più interessante è vmware-cmd. Questo eseguibile si occupa di interfacciarsi con il demone server e di svolgere determinate operazioni sulle virtual machines, si riportano qui di seguito le principali opzioni utilizzate nel corso della stesura dello script [39]: getstate: restituisce lo stato di esecuzione di una macchina virtuale, i possibili valori sono on, off, suspended, stuck che identifica uno stato in cui si richiede l intervento dell utente per l immissione di un determinato input oppure unknown; start: avvia un macchina virtuale precedentemente posta in stato power-off oppure ne ripristina una sospesa; suspend: sospende una virtual machine; answer: permette all utente di rispondere ad eventuali domande poste dal software di virtualizzazione, relativamente ad una macchina virtuale che è in attesa di avere informazioni; getconfig: restituisce il valore di un determinato parametro relativo al file di configurazione della vm specificata; getuptime: accede alla varibile di uptime del sistema operativo della macchina virtuale. Chiarite le opzioni del commando che si andrà ad utilizzare, si può iniziare la stesura dello script. Al fine di realizzare una procedura in grado di adattarsi alla maggior parte delle situazioni, si è cercato di 127

139 REALIZZAZIONE DEL PROGETTO renderla il più possibile parametrica sia riguardo alle informazioni di input che alle funzionalità supportate, in previsione dei possibili utilizzi all interno di heartbeat. Come in qualsiasi listato di un programma, nella parte iniziale si sono definite ed impostate le variabili. Avendo pensato di introdurre un certo livello di parametrizzazione si è deciso che la prima informazione fornita debba indicare il file con estensione vmx associato alla macchina virtuale sulla quale si vuole operare, mentre la seconda l obiettivo che si vuole raggiungere attraverso l esecuzione dello script. Questi due parametri sono stati rispettivamente associati alle variabili RISORSA e COMANDO. Contestualmente alle variabili associate ai parametri verranno impostate anche tre costanti VMWARECMD, VM_PATH e ADMIN_MAIL che identificano rispettivamente il path del comando vmware-cmd, il path base in cui si trovano tutte le macchine virtuali e l indirizzo degli amministratori per i messaggi di notifica che lo script invierà. VMWARECMD="/usr/bin/vmware-cmd" VM_PATH="/var/lib/vmware/VirtualMachines" RES="$1" CMD="$2" In funzione dell operazione che si vuole eseguire sulla virtual machine passata come parametro, si eseguiranno differenti procedure, è per questo che il contenuto della variabile COMANDO verrà valutato da un ciclo di tipo case in base a due possibilità start oppure stop. 128

140 REALIZZAZIONE DEL PROGETTO Nella fase di start si avvierà la macchina virtuale specificata nella variabile RISORSA attraverso il comando $VMWARECMD $RISORSA start. Questo comando non risolve però tutte le problematiche inerenti l avvio di una macchina virtuale. In alcuni test di funzionamento dello script infatti, si sono evidenziate alcune difficoltà che è stato indispensabile risolvere mediante l aggiunta di ulteriori istruzioni. Durante la fase di takeover del cluster, quando cioè le macchine virtuali passano da un nodo all altro, VMware Server segnala un errore relativo all uuid (Universally Unique Identifier). L uuid è un codice univoco che viene generato dal demone VMware ed assegnato ad una vm sulla base dell hardware utilizzato della macchina host, serve da un lato ad identificare in modo univoco la macchina guest e dall altro per la creazione di codici unovoci relativi all harware virtuale, come il MAC address della schede di rete. Con il cambio di nodo, l uuid ricalcolato per la macchina virtuale ovviamente cambia e VMware si accorge che il codice non è più corrispondente. Per questo motivo vuole sapere se deve essere mantenuto oppure si desidera generare un nuovo codice basandosi sull hardware della nuova macchina host. Poiché questo tipo di errore è bloccante, ovvero non permette alla fase di start di procedere in modo autonomo senza ottenere una risposta, si deve intervenire per risolverlo. La soluzione adottata è quella di modificare il file di configurazione di ogni 129

141 REALIZZAZIONE DEL PROGETTO virtual machines (il file con estensione vmx) aggiungendo o modificando il parametro uuid.action nel modo seguente: [...] uuid.action = "keep" L adozione di questa impostazione fa in modo che l uuid delle machine virtuali non venga mai cambiato indipendentemente dalla macchina host che si occupa della sua esecuzione, un ulteriore vantaggio derivante da questa scelta è il mantenimento dello stesso MAC address indispensabile per non pertere le connessioni attive in caso di un takeover graceful. Un ulteriore problematica riscontrata in questo progetto, ma che si verifica unicamente in presenza di nodi non perfettamente speculari dal punto di vista hardware, riguarda il resume di una macchina virtuale precedentemente sospesa su un nodo con processore differente. Al verificarsi di questa situazione VMware Server avverte della possibilità di malfunzionamenti dovuti alle differenze architetturali dei due processori. Questa difficoltà è stata superata grazie all opzione answer del comando vmware-cmd che consente, con gli opportuni accorgimenti, di rispondere alle eventuali domande poste dal demone. Poiché questa situazione si verifica solamente in presenza di uno stato stuck della macchina virtuale, la procedura di risposta è stata inserita in una struttura condizionale if-fi, in modo da eseguire i comandi solo se richiesto. if [ $($VMWARECMD $VM_PATH$RES getstate 2>&1 \ sed 's/getstate() =//g') = "stuck" ]; then echo 0 $VMWARECMD $VM_PATH$RES answer fi 130

142 REALIZZAZIONE DEL PROGETTO Le configurazioni e le scelte si qui effettuate hanno permesso di generare un ottima procedura per lo start, ma ulteriori test supplementari hanno messo in evidenza una difficoltà oggettiva imputabile alla potenza dei nodi. Quando heartbeat prende in carico le risorse ed avvia gli script associati, questi vengono lanciati in successione secondo l elenco definito nel file haresources. Una macchina virtuale impiega diverso tempo per portare a termine la fase di boot, ma poichè lo script non attende la fine di questo processo per passare il controllo allo script successivo, può accadere che alcune virtual machines vengano avviate praticamente in contemporanea. Tale situazione mette decisamente in crisi le non eccessive risorse dei nodi, aumentando in modo significativo il tempo totale di avvio delle macchine. Questo problema è stato superato grazie all idea di non terminare lo script fino a quando la vm, per la quale è stato mandato in esecuzione, non abbia completamente terminato la fase di boot. Per fare ciò si è creato un sistema di attesa attiva, controllando lo stato del parametro getuptime, che conclude lo script solamente dopo un determinato lasso di tempo calcolato sulla base dello stato precedente della macchina virtuale. È evidente infatti che una macchina in stato suspended impiegherà di certo meno tempo ad avviarsi di una macchina in stato off. 131

143 REALIZZAZIONE DEL PROGETTO if [ ${STARTUP_STATE//getstate() =/} = "off" ]; then TIMER=60 elif [ ${STARTUP_STATE//getstate() =/} = "on" ]; then TIMER=0 elif [ ${STARTUP_STATE//getstate() =/} = "suspended" ]; then TIMER=`expr $($VMWARECMD $VM_PATH$RES getuptime 2>&1 \ sed 's/getuptime() =//g') + 15` fi while [ $($VMWARECMD $VM_PATH$RES getuptime 2>&1 \ sed 's/getuptime() =//g') l t $TIMER ]; do wait done Concluso lo sviluppo dello script nella parte di start si è passati ad analizzare quella di stop, che ha come scopo primario quello di arrestare le macchine virtuali in caso di takeover graceful. Al fine di velocizzare il più possibile la transizione delle risorse da un nodo all altro e per fare in modo che il takeover non provochi la perdita delle sessioni stabilite dagli utenti con la macchina virtuale, si è deciso di adottare la sospensione della virtual machines e non il loro arresto. Prima di procedere all esecuzione del comando per l ibernazione della vm è indispensabile, onde evitare errori nell esecuzione, controllare che la macchina virtuale sia effettivamente in eseuzione. Questo è attuabile attraverso un semplice controllo all interno della cartella /var/run utilizzata dal sistema operativo per memorizzare i processi in esecuzione. if [ -d /var/run/vmware/`echo $VM_PATH$RES \ sed 's/\//%2f/g' sed 's/\./%2e/g'` ]; then $VMWARECMD $VM_PATH$RES suspend fi 132

144 REALIZZAZIONE DEL PROGETTO Al termine del ciclo case si è pensato di inviare un messaggio di posta elettronica agli indirizzi specificati nella variabile ADMIN_MAIL per inviare alcune informazioni e notificare l avvenuto avvio o sospensione delle macchine virtuali sul nodo. mailx -s "Virtual machine `$VMWARECMD $VM_PATH$RES \ getconfig displayname sed 's/getconfig(displayname) \ =//g'` $CMD on `hostname`" $ADMIN_MAIL << EOF Virtual Machine: `$VMWARECMD $VM_PATH$RES getconfig \ displayname sed 's/getconfig(displayname) =//g'` Status: `$VMWARECMD $VM_PATH$RES getstate \ sed 's/getstate() =//g'` Uptime: `$VMWARECMD $VM_PATH$RES getuptime \ sed 's/getuptime() =//g'` Config $VM_PATH$RES EOF Terminato lo script necessario all integrazione tra heartbeat e VMware Server, è indispensabile apportare alcune modifiche ai file di configurazione di heartbeat stesso, questo per fare in modo che il codice realizzato venga utilizzato e che le macchine virtuali possano entrare a far parte, come risorse attive, del cluster in alta affidabilità scopo di questo progetto. Come prima cosa è necessario arrestare manualmente tramite vmware-server-console le macchine virtuali eventualmente avviate e successivamente provvedere all arresto di heartbeat su entrambi i nodi del cluster. alpha:~ /etc/init.d/heartbeat stop Stopping High-Availability services: Done. bravo:~ /etc/init.d/heartbeat stop Stopping High-Availability services: Done. 133

145 REALIZZAZIONE DEL PROGETTO A questo punto si deve aprire il file /etc/ha.d/haresources in entrambi i nodi e modificare le righe relative alle risorse assegnate nel modo seguente: alpha drbddisk::drbd0 \ Filesystem::/dev/drbd0::/var/lib/vmware/VirtualMachinesALPHA::ext3 \ vmmanager::alpha/charliexp/charliexp.vmx \ vmmanager::alpha/echosuse/echosuse.vmx bravo drbddisk::drbd1 \ Filesystem::/dev/drbd1::/var/lib/vmware/VirtualMachinesBRAVO::ext3 \ vmmanager::bravo/deltakubuntu/deltakubuntu.vmx \ vmmanager::bravo/foxtrot2000as/foxtrot2000as.vmx Concluse le modifiche al file, si può riavviare heartbeat e verificare, come mostrato nella figura 4.16, che tutte le macchine virtuali configurate si siano avviate in modo corretto e che i relativi messaggi di posta elettronica siano stati spediti ai destinatari. Figura 4-16 Avvio di heartbeat e test di funzionalità dello script realizzato. 134

146 Power Port Status Green = 100M, Yellow = 10M, Flash = Activity 3C16794 ä Power Port Status Green = 100M, Yellow = 10M, Flash = Activity 3C16794 ä REALIZZAZIONE DEL PROGETTO Con queste ultime operazioni si può dire terminata la realizzazione dello script per la gestione delle macchine virtuali e contestualmente si può ritenere concluso anche il progetto sperimentale di integrare l alta affidabilità di heartbeat con il sistema di virtualizzazione di VMware Server. Nelle due figure seguenti si può osservare lo schema completo del progetto e la foto delle macchine nella loro configurazione definitiva. INTERNET / INTRANET Office Connect Switch 8 Office Connect Switch 8 CHANNEL BONDING bond bond eth2 eth3 IPFAIL eth3 eth2 CHANNEL BONDING VM VM Windows XP (CHARLIE) ttys0 ttys0 Kubuntu 6.10 (DELTA) VM HEARTBEAT VM Suse 10.2 (ECHO) /dev/drbd0 eth0 DRBD bond1 bond CHANNEL BONDING WATCHDOG eth1 eth1 WATCHDOG eth0 Windows 2000 (FOXTROT) /dev/drbd1 RAID 1 Software ALPHA (KUBUNTU ) RAID 1 Software BRAVO (KUBUNTU ) UPS SYSTEM Figura 4-17 Schema finale del progetto. 135

147 REALIZZAZIONE DEL PROGETTO Figura 4-18 Foto del cluster nella configurazione definitiva. 4.7 Testing del progetto La fase di testing del progetto consiste nel simulare due potenziali situazioni critiche e verificare a posteriori che il comportamento del cluster configurato sia adeguato alle aspettative. Nel primo esperimento si effettuerà un takeover graceful, ovvero si sposteranno tutte le risorse su un unico nodo, imitanto un caso tipico di intervento programmato da parte dell amministratore. Nel secondo test verrà invece simulato un crash completo del sistema, attraverso un intervento diretto sul cavo di alimentazione di uno dei nodi. 136

148 REALIZZAZIONE DEL PROGETTO TAKEOVER GRACEFUL Uno spostamento dei resource group effettuato in modo controllato, prevede l arresto su uno dei nodi del demone heartbeat, il quale chiudendosi richiama lo script vmmanager per la sospensione delle macchine virtuali. Per controllare in modo attento l evolversi della situazione e verificarne il corretto andamento, è necessario monitorare in entrambe le macchine i log generati da heartbeat all interno del file /var/log/ha-log. I comandi ping e ssh possono essere invece utilizzati per definire l ammontare del downtime subito dagli utenti nel corso dell intervento e per verificare che le sessioni aperte con le macchine virtuali prima della migrazione non siano andate perdute ma siano ancora attive e funzionanti. Come prima cosa si apra una shell sul nodo bravo e si esegua lo shutdown di heartbeat: bravo:~ /etc/init.d/heartbeat stop Stopping High-Availability services: Done. Analizzando dettagliatamente i log del nodo bravo riportati nella pagina seguente, si può notare come le operazioni di rilascio delle risorse avvengano in sequenza: prima la sospensione delle virtual machines a carico del nodo tramite vmmanager, successivamente l unmounting del file system utilizzato per la memorizzazione delle macchine virtuali, poi l arrestato del demone di DRBD ed infine il killing di tutti i processi heartbeat ancora rimasti. 137

149 REALIZZAZIONE DEL PROGETTO info: Heartbeat shutdown in progress. (6134) info: Giving up all HA resources. [...] info: Releasing resource group: bravo drbddisk::drbd1 Filesystem::/dev/drbd1::/var/lib/vmware/VirtualMachinesBRAVO: :ext3 vmmanager::bravo/deltakubuntu/deltakubuntu.vmx vmmanager::bravo/foxtrot2000as/foxtrot2000as.vmx info: Running /etc/ha.d/resource.d/vmmanager BRAVO/Foxtrot2000AS/Foxtrot2000AS.vmx stop info: Running /etc/ha.d/resource.d/vmmanager BRAVO/DeltaKUBUNTU/DeltaKUBUNTU.vmx stop info: Running /etc/ha.d/resource.d/filesystem /dev/drbd1 /var/lib/vmware/virtualmachinesbravo ext3 stop INFO: Running stop for /dev/drbd1 on /var/lib/vmware/virtualmachinesbravo INFO: Trying to unmount /var/lib/vmware/virtualmachinesbravo INFO: unmounted /var/lib/vmware/virtualmachinesbravo successfully INFO: Success info: Running /etc/ha.d/resource.d/drbddisk drbd1 stop info: All HA resources relinquished. info: killing /usr/lib/heartbeat/ipfail process group 6158 with signal 15 info: killing HBWRITE process 6138 with signal 15 [...] info: bravo Heartbeat shutdown complete. Una successiva analisi dei log di alpha, mostra invece la segnalazione dello shutdown di heartbeat dall altro nodo e il conseguente inizio delle operazioni per la presa in carico delle risorse. Nelle ultime righe si può notare come la macchina bravo non risponda più ad alcun segnale e venga pertanto dichiarata dead. info: Received shutdown notice from 'bravo'. info: Resources being acquired from bravo. [...] info: Taking over resource group drbddisk::drbd1 info: Acquiring resource group: bravo drbddisk::drbd1 Filesystem::/dev/drbd1::/var/lib/vmware/VirtualMachinesBRAVO: :ext3 vmmanager::bravo/deltakubuntu/deltakubuntu.vmx vmmanager::bravo/foxtrot2000as/foxtrot2000as.vmx info: Running /etc/ha.d/resource.d/drbddisk drbd1 start info: Running /etc/ha.d/resource.d/filesystem /dev/drbd1 /var/lib/vmware/virtualmachinesbravo ext3 start INFO: Running start for /dev/drbd1 on /var/lib/vmware/virtualmachinesbravo INFO: Success info: Running /etc/ha.d/resource.d/vmmanager BRAVO/DeltaKUBUNTU/DeltaKUBUNTU.vmx start 138

150 REALIZZAZIONE DEL PROGETTO info: Running /etc/ha.d/resource.d/vmmanager BRAVO/Foxtrot2000AS/Foxtrot2000AS.vmx start info: /usr/lib/heartbeat/mach_down: nice_failback: foreign resources acquired info: mach_down takeover complete for node bravo. info: mach_down takeover complete. WARN: node bravo: is dead info: Dead node bravo gave up resources. info: Link bravo:bond0 dead. info: Link bravo:bond1 dead. info: Link bravo:/dev/ttys0 dead. Come già accennato ad inizio paragrafo, nel corso del takeover si sono tenute sotto controllo le macchine virtuali del nodo bravo mediante il comando ping. Come mostra l output qui di seguito, lo spostamento delle risorse ha impiegato solo pochi secondi per concludersi ed inoltre le sessioni aperte dagli utenti prima della sospensione, siano esse ssh, http oppure ftp, sono rimaste intatte dopo il ripristino, chiaro indice della totale trasparenza dell operazione. ~]$ ping -i 5 delta.centrale.unipg.it PING delta.centrale.unipg.it ( ) 56(84) bytes of data. 64 bytes from : icmp_seq=1 ttl=64 time=0.911 ms 64 bytes from : icmp_seq=2 ttl=64 time=0.285 ms From icmp_seq=5 Destination Host Unreachable From icmp_seq=6 Destination Host Unreachable From icmp_seq=7 Destination Host Unreachable From icmp_seq=8 Destination Host Unreachable 64 bytes from : icmp_seq=9 ttl=64 time=0.298 ms 64 bytes from : icmp_seq=10 ttl=64 time=0.381 ms ~]$ ping -i 5 foxtrot.centrale.unipg.it PING foxtrot.centrale.unipg.it ( ) 56(84) bytes of data. 64 bytes from : icmp_seq=1 ttl=128 time=1.10 ms 64 bytes from : icmp_seq=2 ttl=128 time=0.313 ms From icmp_seq=5 Destination Host Unreachable From icmp_seq=6 Destination Host Unreachable From icmp_seq=7 Destination Host Unreachable From icmp_seq=8 Destination Host Unreachable From icmp_seq=9 Destination Host Unreachable 64 bytes from : icmp_seq=10 ttl=128 time=1008 ms 64 bytes from : icmp_seq=11 ttl=128 time=0.295 ms 139

151 REALIZZAZIONE DEL PROGETTO Figura 4-19 La MUI mostra lo stato delle quattro macchine virtuali sul nodo alpha. Verificato che il takeover si è svolto correttamente e che le risorse sono migrate in maniera trasparente per l utente, si può ripristinare lo stato iniziale riavviando heartbeat sul nodo bravo. In questo caso il demone richiede immediatamente le sue risorse ad alpha, il quale, resosi conto dello stato attivo dell altro nodo, rilascia il resource group permettendo a bravo di riportare la situazione allo stato originale. I log del nodo alpha, qui sotto riportati, mostrano la sequenza degli eventi appena descritta. info: Heartbeat restart on node bravo info: Link bravo:/dev/ttys0 up. info: Status update for node bravo: status init info: Link bravo:bond0 up. info: Link bravo:bond1 up. info: Status update for node bravo: status up info: all clients are now paused info: Status update for node bravo: status active info: remote resource transition completed. info: alpha wants to go standby [foreign] info: all clients are now resumed info: standby: bravo can take our foreign resources info: give up foreign HA resources (standby). 140

152 REALIZZAZIONE DEL PROGETTO info: Releasing resource group: bravo drbddisk::drbd1 Filesystem::/dev/drbd1::/var/lib/vmware/VirtualMachinesBRAVO: :ext3 vmmanager::bravo/deltakubuntu/deltakubuntu.vmx vmmanager::bravo/foxtrot2000as/foxtrot2000as.vmx info: Running /etc/ha.d/resource.d/vmmanager BRAVO/Foxtrot2000AS/Foxtrot2000AS.vmx stop info: Running /etc/ha.d/resource.d/vmmanager BRAVO/DeltaKUBUNTU/DeltaKUBUNTU.vmx stop info: Running /etc/ha.d/resource.d/filesystem /dev/drbd1 /var/lib/vmware/virtualmachinesbravo ext3 stop INFO: Running stop for /dev/drbd1 on /var/lib/vmware/virtualmachinesbravo INFO: Trying to unmount /var/lib/vmware/virtualmachinesbravo INFO: unmounted /var/lib/vmware/virtualmachinesbravo successfully INFO: Success info: Running /etc/ha.d/resource.d/drbddisk drbd1 stop info: foreign HA resource release completed (standby). info: Local standby process completed [foreign]. WARN: 1 lost packet(s) for [bravo] [51:53] info: remote resource transition completed. info: No pkts missing from bravo! info: Other node completed standby takeover of foreign resources. Tutti i passaggi inerenti le macchine virtuali sono visualizzabili sul client di posta elettronica degli amministratori ove ogni operazione di avvio e arresto delle macchine virtuali è debitamente segnalato da un messaggio di posta elettronica inviato dallo script vmmanager. Figura 4-20 Il client Kmail mostra la sequenza di messaggi di up e down delle vm. 141

Introduzione alla Virtualizzazione

Introduzione alla Virtualizzazione Introduzione alla Virtualizzazione Dott. Luca Tasquier E-mail: luca.tasquier@unina2.it Virtualizzazione - 1 La virtualizzazione è una tecnologia software che sta cambiando il metodo d utilizzo delle risorse

Dettagli

Virtualizzazione e Privacy

Virtualizzazione e Privacy Virtualizzazione e Privacy Outline Virtualizzazione Paravirtualizzazione e Xen Virtualizzazione e anonimato (Mix Network) Virtualizzazione e privacy Isolamento servizi utente Virtual Service Domains Virtualizzazione

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

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

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

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

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

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

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

Corso di Sistemi di Elaborazione delle informazioni

Corso di Sistemi di Elaborazione delle informazioni Corso di Sistemi di Elaborazione delle informazioni Sistemi Operativi Francesco Fontanella La Complessità del Hardware Il modello di Von Neumann è uno schema di principio. Attualmente in commercio esistono:

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

Architetture software. Virtualizzazione

Architetture software. Virtualizzazione Sistemi Distribuiti Architetture software 1 Virtualizzazione 2 1 Virtualizzazione (motivazioni) Sullo stesso elaboratore possono essere eseguiti indipendentemente d t e simultaneamente t sistemi i operativi

Dettagli

Sistemi Operativi. Modulo 2. C. Marrocco. Università degli Studi di Cassino

Sistemi Operativi. Modulo 2. C. Marrocco. Università degli Studi di Cassino Sistemi Operativi Modulo 2 Schema di un Sistema di Calcolo Programmi Dati di Input Calcolatore Dati di output Modello di von Neumann Bus di sistema CPU Memoria Centrale Memoria di Massa Interfaccia Periferica

Dettagli

Introduzione al sistema operativo. Laboratorio Software 2008-2009 C. Brandolese

Introduzione al sistema operativo. Laboratorio Software 2008-2009 C. Brandolese Introduzione al sistema operativo Laboratorio Software 2008-2009 C. Brandolese Che cos è un sistema operativo Alcuni anni fa un sistema operativo era definito come: Il software necessario a controllare

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

FAMIGLIA EMC VPLEX. Continuous availability e data mobility all'interno e tra i data center

FAMIGLIA EMC VPLEX. Continuous availability e data mobility all'interno e tra i data center FAMIGLIA EMC VPLEX Continuous availability e data mobility all'interno e tra i data center CONTINUOUS AVAILABILITY E DATA MOBILITY PER APPLICAZIONI MISSION- CRITICAL L'infrastruttura di storage è in evoluzione

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

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

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

Via Emanuela Loi 1, 09010 Villaspeciosa (CA) P.IVA 03071740926 - Tel.+39 380 45 42 015 CF: CSCLSN78R17B354H *** @Mail: info@afnetsistemi.

Via Emanuela Loi 1, 09010 Villaspeciosa (CA) P.IVA 03071740926 - Tel.+39 380 45 42 015 CF: CSCLSN78R17B354H *** @Mail: info@afnetsistemi. Via Emanuela Loi 1, 09010 Villaspeciosa (CA) P.IVA 03071740926 - Tel.+39 380 45 42 015 CF: CSCLSN78R17B354H *** @Mail: info@afnetsistemi.it @Pec: info.afnet@pec.it Web: http://www.afnetsistemi.it E-Commerce:

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

Soluzioni innovative per la semplificazione dell infrastruttura IT. Virtualizzazione con il sistema operativo IBM i, PowerVM e Power Systems

Soluzioni innovative per la semplificazione dell infrastruttura IT. Virtualizzazione con il sistema operativo IBM i, PowerVM e Power Systems Soluzioni innovative per la semplificazione dell infrastruttura IT Virtualizzazione con il sistema operativo IBM i, PowerVM e Power Systems Caratteristiche principali La flessibilità e la scalabilità della

Dettagli

Strutture dei Sistemi Operativi

Strutture dei Sistemi Operativi Strutture dei Sistemi Operativi Componenti di sistema Servizi del sistema operativo Chiamate di sistema Programmi di sistema Struttura del sistema Macchine virtuali Progetto e implementazione di sistemi

Dettagli

Lezione 4 La Struttura dei Sistemi Operativi. Introduzione

Lezione 4 La Struttura dei Sistemi Operativi. Introduzione Lezione 4 La Struttura dei Sistemi Operativi Introduzione Funzionamento di un SO La Struttura di un SO Sistemi Operativi con Struttura Monolitica Progettazione a Livelli di un SO 4.2 1 Introduzione (cont.)

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

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

LAN MAN WAN. Una internet è l'insieme di più reti reti distinte collegate tramite gateway/router

LAN MAN WAN. Una internet è l'insieme di più reti reti distinte collegate tramite gateway/router Rete di reti (interrete, internet) 2 Prof. Roberto De Prisco TEORIA - Lezione 8 Rete di reti e Internet Università degli studi di Salerno Laurea e Diploma in Informatica Una rete di comunicazione è un

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

Lezioni frontali. Riprendere i concetti basilari del processore utilizzato e la programmazione a basso livello

Lezioni frontali. Riprendere i concetti basilari del processore utilizzato e la programmazione a basso livello Istituto Istruzione Superiore di Baronissi ind. tecnico PROGRAMMAZIONE DIDATTICA DI SISTEMI Indirizzo: Informatica Progetto Abacus Anno scolastico 2012-2013 Classe 4^ MODULI CONTENUTI OBIETTIVI METODOLOGIE

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

I nostri servizi Dynamic Data Centre Infrastructure-as-a-Service.

I nostri servizi Dynamic Data Centre Infrastructure-as-a-Service. I nostri servizi Infrastructure-as-a-Service. 02 / TelecityGroup Cos è? (DDC) è la proposta di TelecityGroup nell ambito Infrastructure-as-a-Service (IaaS), uno dei cardini del cloud computing. Attraverso

Dettagli

Sistemi Operativi II Corso di Laurea in Ingegneria Informatica

Sistemi Operativi II Corso di Laurea in Ingegneria Informatica www.dis.uniroma1.it/~midlab Sistemi Operativi II Corso di Laurea in Ingegneria Informatica Prof. Roberto Baldoni Introduzione OS=Astrazione Dare l illusione all applicazione di memoria infinita, CPU infinita,unico

Dettagli

PICCOLE E MEDIE IMPRESE, UNA SOLUZIONE AD HOC. Soluzioni per le PMI

PICCOLE E MEDIE IMPRESE, UNA SOLUZIONE AD HOC. Soluzioni per le PMI PICCOLE E MEDIE IMPRESE, UNA SOLUZIONE AD HOC Soluzioni per le PMI Windows Server 2012 e System Center 2012 Informazioni sul copyright 2012 Microsoft Corporation. Tutti i diritti sono riservati. Il presente

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

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

Lezione 5: Software. Firmware Sistema Operativo. Introduzione all'informatica - corso E

Lezione 5: Software. Firmware Sistema Operativo. Introduzione all'informatica - corso E Lezione 5: Software Firmware Sistema Operativo Architettura del Calcolatore La prima decomposizione di un calcolatore è relativa a due macrocomponenti: Hardware e Software Firmware: strato di (micro-)programmi

Dettagli

Per questa ragione il nostro sforzo si è concentrato sugli aspetti elencati qui di seguito:

Per questa ragione il nostro sforzo si è concentrato sugli aspetti elencati qui di seguito: Autore : Giulio Martino IT Security, Network and Voice Manager Technical Writer e Supporter di ISAServer.it www.isaserver.it www.ocsserver.it www.voipexperts.it - blogs.dotnethell.it/isacab giulio.martino@isaserver.it

Dettagli

IBM Tivoli Storage Manager for Virtual Environments

IBM Tivoli Storage Manager for Virtual Environments Scheda tecnica IBM Storage Manager for Virtual Environments Backup senza interruzioni e ripristino immediato: un processo più semplice e lineare Caratteristiche principali Semplificare la gestione del

Dettagli

In estrema sintesi, NEMO VirtualFarm vuol dire:

In estrema sintesi, NEMO VirtualFarm vuol dire: VIRTUAL FARM La server consolidation è un processo che rappresenta ormai il trend principale nel design e re-styling di un sistema ICT. L ottimizzazione delle risorse macchina, degli spazi, il risparmio

Dettagli

CAPITOLO 1 I SISTEMI OPERATIVI

CAPITOLO 1 I SISTEMI OPERATIVI CAPITOLO 1 I SISTEMI OPERATIVI Introduzione ai sistemi operativi pag. 3 La shell pag. 3 Tipi di sistemi operativi pag. 4 I servizi del sistema operativo pag. 4 La gestione dei file e il file system Il

Dettagli

Sistemi Operativi. Funzioni e strategie di progettazione: dai kernel monolitici alle macchine virtuali

Sistemi Operativi. Funzioni e strategie di progettazione: dai kernel monolitici alle macchine virtuali Modulo di Sistemi Operativi per il corso di Master RISS: Ricerca e Innovazione nelle Scienze della Salute Unisa, 17-26 Luglio 2012 Sistemi Operativi Funzioni e strategie di progettazione: dai kernel monolitici

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

La componente tecnologica dei. sistemi informativi. Architettura hw. Componenti di una architettura hw

La componente tecnologica dei. sistemi informativi. Architettura hw. Componenti di una architettura hw Informatica o Information Technology La componente tecnologica dei sistemi informativi m. rumor Architettura del Sistema tecnologico Sistema tecnologico: insieme di componenti connessi e coordinati che

Dettagli

ELEMENTI DI PROGETTAZIONE SOFTWARE

ELEMENTI DI PROGETTAZIONE SOFTWARE ELEMENTI DI PROGETTAZIONE SOFTWARE Massimiliano Redolfi Architetture Architetture logiche e fisiche Stand Alone tipico applicativo anni 1980 nessun problema di concorrenza spesso nessuna scomposizione

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

Il Sistema Operativo (1)

Il Sistema Operativo (1) E il software fondamentale del computer, gestisce tutto il suo funzionamento e crea un interfaccia con l utente. Le sue funzioni principali sono: Il Sistema Operativo (1) La gestione dell unità centrale

Dettagli

Sistemi RAID. Sistemi RAID. Sistemi RAID

Sistemi RAID. Sistemi RAID. Sistemi RAID Sistemi RAID 1 Sistemi RAID Dei tre elementi fondamentali di un qualsiasi sistema computerizzato: processore, memoria primaria, memoria secondaria, quest ultimo è di gran lunga il più lento. Inoltre, il

Dettagli

Sistemi RAID. Sistemi RAID

Sistemi RAID. Sistemi RAID Sistemi RAID 1 Sistemi RAID Dei tre elementi fondamentali di un qualsiasi sistema computerizzato: processore, memoria primaria, memoria secondaria, quest ultimo è di gran lunga il più lento. Inoltre, il

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

Il Gruppo Arvedi sceglie tecnologie Microsoft per la virtualizzazione dei sistemi server

Il Gruppo Arvedi sceglie tecnologie Microsoft per la virtualizzazione dei sistemi server Caso di successo Microsoft Virtualizzazione Gruppo Arvedi Il Gruppo Arvedi sceglie tecnologie Microsoft per la virtualizzazione dei sistemi server Informazioni generali Settore Education Il Cliente Le

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

Sistemi RAID tutti i dati che contiene RAID

Sistemi RAID tutti i dati che contiene RAID Sistemi RAID 1 Sistemi RAID Dei tre elementi fondamentali di un qualsiasi sistema computerizzato: processore, memoria primaria, memoria secondaria, quest ultimo è di gran lunga il più lento. Inoltre, il

Dettagli

Tecnologie di virtualizzazione per il consolidamento dei server

Tecnologie di virtualizzazione per il consolidamento dei server Tecnologie di virtualizzazione per il consolidamento dei server Simone Balboni Seminario del corso Sistemi Operativi Bologna, 2 marzo 2006 Virtualizzazione e consolidamento dei server un caso concreto:

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

Sistemi Operativi UNICAL. Facoltà di Ingegneria. Domenico Talia A.A. 2002-2003 1.1. Sistemi Operativi. D. Talia - UNICAL

Sistemi Operativi UNICAL. Facoltà di Ingegneria. Domenico Talia A.A. 2002-2003 1.1. Sistemi Operativi. D. Talia - UNICAL Domenico Talia Facoltà di Ingegneria UNICAL A.A. 2002-2003 1.1 Introduzione Presentazione del corso Cosa è un Sistema Operativo? Sistemi Mainframe Sistemi Desktop Sistemi Multiprocessori Sistemi Distribuiti

Dettagli

WYS. WATCH YOUR SYSTEMS in any condition

WYS. WATCH YOUR SYSTEMS in any condition WYS WATCH YOUR SYSTEMS in any condition WYS WATCH YOUR SYSTEMS La soluzione WYS: prodotto esclusivo e team di esperienza. V-ision, il team di Interlinea che cura la parte Information Technology, è dotato

Dettagli

Architettura di un sistema operativo

Architettura di un sistema operativo Architettura di un sistema operativo Struttura di un S.O. Sistemi monolitici Sistemi a struttura semplice Sistemi a livelli Virtual Machine Sistemi basati su kernel Sistemi con microkernel Sistemi con

Dettagli

Introduzione ai sistemi operativi

Introduzione ai sistemi operativi Introduzione ai sistemi operativi Che cos è un S.O.? Shell Utente Utente 1 2 Utente N Window Compilatori Assembler Editor.. DB SOFTWARE APPLICATIVO System calls SISTEMA OPERATIVO HARDWARE Funzioni di un

Dettagli

Sistemi Operativi STRUTTURA DEI SISTEMI OPERATIVI 3.1. Sistemi Operativi. D. Talia - UNICAL

Sistemi Operativi STRUTTURA DEI SISTEMI OPERATIVI 3.1. Sistemi Operativi. D. Talia - UNICAL STRUTTURA DEI SISTEMI OPERATIVI 3.1 Struttura dei Componenti Servizi di un sistema operativo System Call Programmi di sistema Struttura del sistema operativo Macchine virtuali Progettazione e Realizzazione

Dettagli

Sistemi Operativi I Corso di Laurea in Ingegneria Informatica Facolta di Ingegneria, Universita La Sapienza Docente: Francesco Quaglia

Sistemi Operativi I Corso di Laurea in Ingegneria Informatica Facolta di Ingegneria, Universita La Sapienza Docente: Francesco Quaglia Sistemi Operativi I Corso di Laurea in Ingegneria Informatica Facolta di Ingegneria, Universita La Sapienza Docente: Francesco Quaglia Introduzione: 1. Principi di base dei sistemi operativi 2. Sistemi

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

Virtualizzazione e Cloud Computing

Virtualizzazione e Cloud Computing Virtualizzazione e Cloud Computing 12 marzo 2015 Claudio Bizzarri claudio@bizzarri.net Ordine degli Ingegneri di Pistoia La virtualizzazione Macchine reali e macchine virtuali Vantaggi della virtualizzazione

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

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

Il Sistema Operativo. C. Marrocco. Università degli Studi di Cassino

Il Sistema Operativo. C. Marrocco. Università degli Studi di Cassino Il Sistema Operativo Il Sistema Operativo è uno strato software che: opera direttamente sull hardware; isola dai dettagli dell architettura hardware; fornisce un insieme di funzionalità di alto livello.

Dettagli

Università degli Studi di Napoli Federico II Facoltà di Ingegneria Corso di Laurea Specialistica in Ingegneria Informatica.

Università degli Studi di Napoli Federico II Facoltà di Ingegneria Corso di Laurea Specialistica in Ingegneria Informatica. Università degli Studi di Napoli Federico II Facoltà di Ingegneria Corso di Laurea Specialistica in Ingegneria Informatica Corso di Sistemi Distribuiti Prof. Stefano Russo Caratterizzazionedei SistemiDistribuiti

Dettagli

Sistemi Operativi. Introduzione UNICAL. Facoltà di Ingegneria. Domenico Talia A.A. 2002-2003

Sistemi Operativi. Introduzione UNICAL. Facoltà di Ingegneria. Domenico Talia A.A. 2002-2003 Domenico Talia Facoltà di Ingegneria UNICAL A.A. 2002-2003 1.1 Introduzione Presentazione del corso Cosa è un Sistema Operativo? Sistemi Mainframe Sistemi Desktop Sistemi Multiprocessori Sistemi Distribuiti

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

Architettura di un sistema operativo

Architettura di un sistema operativo Architettura di un sistema operativo Dipartimento di Informatica Università di Verona, Italy Struttura di un S.O. Sistemi monolitici Sistemi a struttura semplice Sistemi a livelli Virtual Machine Sistemi

Dettagli

Prefazione. Contenuti

Prefazione. Contenuti Prefazione Il sistema operativo costituisce uno dei componenti fondamentali di ogni sistema di elaborazione, in particolare è quello con cui l utente entra direttamente in contatto quando accede al sistema,

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

Mantenere i sistemi IT sempre attivi: una guida alla continuità aziendale per piccole e medie imprese

Mantenere i sistemi IT sempre attivi: una guida alla continuità aziendale per piccole e medie imprese Mantenere i sistemi IT sempre attivi: una guida alla continuità aziendale per piccole e medie imprese Mantenere le applicazioni sempre disponibili: dalla gestione quotidiana al ripristino in caso di guasto

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

Protezione del Kernel Tramite Macchine Virtuali

Protezione del Kernel Tramite Macchine Virtuali Protezione del Kernel Tramite Macchine Virtuali Fabio Campisi Daniele Sgandurra Università di Pisa 27 Novembre 2007 1/44 Protezione del Kernel Tramite Macchine Virtuali Università di Pisa Sommario della

Dettagli

Programma Operativo di Cooperazione Transfrontaliera Italia Svizzera 2007-2013 PROGETTO STRATEGIO PTA

Programma Operativo di Cooperazione Transfrontaliera Italia Svizzera 2007-2013 PROGETTO STRATEGIO PTA Programma Operativo di Cooperazione Transfrontaliera Italia Svizzera 2007-2013 PROGETTO STRATEGIO PTA PIATTAFORMA TECNOLOGICA ALPINA: UNO STRUMENTO TRANSFRONTALIERO PER LA CONDIVISIONE DI INFRASTRUTTURE

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

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

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

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

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

I/O Dispositivi di input/output

I/O Dispositivi di input/output I/O Dispositivi di input/output Corso di Calcolatori Elettronici A 2007/2008 Sito Web:http://prometeo.ing.unibs.it/quarella Prof. G. Quarella prof@quarella.net Dispositivi di I/O Processor Interrupts Cache

Dettagli

Corso di Sistemi di Elaborazione delle informazioni

Corso di Sistemi di Elaborazione delle informazioni Corso di Sistemi di Elaborazione delle informazioni Reti di Calcolatori Francesco Fontanella Il Concetto di File e la File Allocation Table La File Allocation Table (FAT) è la realizzazione fisica che

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

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

Elementi di Informatica e Programmazione

Elementi di Informatica e Programmazione Elementi di Informatica e Programmazione Il Sistema Operativo Corsi di Laurea in: Ingegneria Civile Ingegneria per l Ambiente e il Territorio Università degli Studi di Brescia Docente: Daniela Fogli Cos

Dettagli

Sistemi Operativi (modulo di Informatica II) Architettura

Sistemi Operativi (modulo di Informatica II) Architettura Sistemi Operativi (modulo di Informatica II) Architettura Patrizia Scandurra Università degli Studi di Bergamo a.a. 2008-09 Sommario Obiettivi di un sistema operativo Concetti di base sui sistemi operativi

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

STORAGE. 2015 Arka Service s.r.l.

STORAGE. 2015 Arka Service s.r.l. STORAGE STORAGE MEDIA indipendentemente dal modello di repository utilizzato i dati devono essere salvati su dei supporti (data storage media). I modelli utilizzati da Arka Service sono i comuni metodo

Dettagli

Il ROI del consolidamento dei Server

Il ROI del consolidamento dei Server Il ROI del consolidamento dei Server Sul lungo periodo, un attività di consolidamento dei server è in grado di far scendere i costi IT in modo significativo. Con meno server, le aziende saranno in grado

Dettagli

INFORMATION TECNOLOGY. a cura di Alessandro Padovani padoale@email.it

INFORMATION TECNOLOGY. a cura di Alessandro Padovani padoale@email.it INFORMATION TECNOLOGY 2 a cura di Alessandro Padovani padoale@email.it LE MEMORIE - 1 MEMORIA CENTRALE (O PRINCIPALE) Da questa memoria l unità centrale estrae i dati che servono per eseguire i programmi

Dettagli

Cosa è un Sistema Operativo (S.O.)

Cosa è un Sistema Operativo (S.O.) Cosa è un Sistema Operativo (S.O.) Modulo software costituito da un insieme di programmi per: permettere all utente l uso dell elaboratore senza la conoscenza approfondita dell hardware S.O. supporto all

Dettagli

I SISTEMI OPERATIVI CONCETTI INTRODUTTIVI

I SISTEMI OPERATIVI CONCETTI INTRODUTTIVI I SISTEMI OPERATIVI CONCETTI INTRODUTTIVI Il Software Software di Base Sistema Operativo (Software di base essenziale) Software di base non essenziale Utility Driver Software applicativi (Applicazioni)

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

Parte VI SISTEMI OPERATIVI

Parte VI SISTEMI OPERATIVI Parte VI SISTEMI OPERATIVI Sistema Operativo Ogni computer ha un sistema operativo necessario per eseguire gli altri programmi Il sistema operativo, fra l altro, è responsabile di riconoscere i comandi

Dettagli

Telecom Italia, Gruppo innovatore nell ICT, punta sulla flessibilità adottando un server ottimizzato per il cloud

Telecom Italia, Gruppo innovatore nell ICT, punta sulla flessibilità adottando un server ottimizzato per il cloud Telecom Italia, Gruppo innovatore nell ICT, punta sulla flessibilità adottando un server ottimizzato per il cloud Panoramica Paese: Italia Settore: ICT Profilo del cliente Telecom Italia è uno dei principali

Dettagli

Il sistema operativo

Il sistema operativo Il sistema operativo Percorso di Preparazione agli Studi di Ingegneria Università degli Studi di Brescia Docente: Massimiliano Giacomin Cos è un Sistema Operativo? Per capirlo, immaginiamo inizialmente

Dettagli

WHITE PAPER. I vantaggi offerti dalla deduplicazione alle aziende di ogni dimensione White paper di Acronis

WHITE PAPER. I vantaggi offerti dalla deduplicazione alle aziende di ogni dimensione White paper di Acronis I vantaggi offerti dalla deduplicazione alle aziende di ogni dimensione White paper di Acronis Copyright Acronis, Inc., 2000 2009 Sommario Riepilogo... 3 Cos è la deduplicazione?... 4 Deduplicazione a

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

L infrastruttura tecnologica del cnr irpi di perugia

L infrastruttura tecnologica del cnr irpi di perugia Sabato 8 marzo 2014 Aula Magna ITTS «A. Volta» - Perugia L infrastruttura tecnologica del cnr irpi di perugia VINICIO BALDUCCI Istituto di Ricerca per la Protezione Idrogeologica Consiglio Nazionale delle

Dettagli