DB filesystem. Un sogno

Transcript

1

2 LINUX&C APRILE I FILE SYSTEM DISTRIBUITI DB filesystem DB amministrativi distribuiti La gestione di un cluster evidenzia immediatamente una serie di problematiche alle quali bisogna dare una risposta: parliamo, in questa puntata, dei file system distribuiti e dei database amministrativi. Cercare di fare una panoramica dei progetti che contengono il termine "clustering" in ambiente Linux Ž oggi come tentare di contare le stelle del cielo in una tersa giornata estiva. Le caratteristiche di apertura del software e la ormai incontestabile stabilitˆ del sistema fanno di Linux il laboratorio ideale per lo sviluppo di ogni sorta di progetto che sia teso a mettere in comune risorse su di una rete. Gli ultimi tempi hanno visto un largo fiorire di progetti, in parte scaturiti da prodotti commerciali, che propongono modelli di cluster con caratteristiche spesso poco definite, cosa che non facilita chi deve capire quale tipologia di cluster scegliere per soddisfare le proprie necessitˆ. La nostra panoramica cercherˆ di guidarvi nel labirinto delle diverse soluzioni dando risalto a quelle soluzioni ÒpilotaÓ che a nostro giudizio meglio caratterizzano certi modelli. Nostra precisa scelta stata quella di non parlare di soluzioni commerciali ma solo di quelle che rientrano nella categoria di Òsoftware di pubblico dominioó, cio rilasciate con una licenze tipo GPL (o altro). Capita sovente, tuttavia, che negli stessi siti di riferimento per queste soluzioni ÒpubblicheÓ siano citate le soluzioni commerciali da esse derivate. Per chi fosse interessato, l'unico consiglio che possiamo dare di armarsi e partire... con il web surfing. Un sogno Il sogno di ogni amministratore di cluster sarebbe quello di vedere il pi possibile il proprio insieme di sistemi come un unico sistema di calcolo. In questa ottica desidererebbe definire gli utenti una sola volta, avere un unico file system da gestire, poter monitorare in modo semplice tutto il sistema, riuscire a bilanciare il carico del sistema facilmente (senza dover impazzire nella riconfigurazione di sistemi di code complicatissimi ogni qualvolta sia necessario fare "tuning") e dormire tranquillo con la sicurezza che il proprio sistema offra servizio in modo continuativo anche quando non sorvegliato. Ogni tanto qualcuno dei nostri colleghi confessa pure di sognare di poter pianificare le proprie ferie con largo anticipo! Insomma, il sogno di ogni amministratore di sistemi quello di trovare un mezzo non chimico per curare finalmente la malattia professionale dei sistemisti... la gastrite. Altro che diete in bianco, dateci un sistema con uptime mostruosi, che sia dotato di un controllo gestionale centralizzato, che risponda alle richieste di servizio in modo egregio, con costi contenuti e noi vi promettiamo di buttar via tutta quella serie di pillole Maurizio Davini m.davini@oltrelinux.com Lavora come sistemista presso il Dipartimento di Fisica dell'universitˆ di Pisa. Le sue attivitˆ coprono tutti i sistemi Unix (proprietari e non). Usa Linux fin dalla prima versione beta ed ha installato il suo primo cluster nel I suoi interessi attuali si concentrano sul calcolo ad alte prestazioni e sullo storage di dati in ambiente Linux. Italo Lisi i.lisi@oltrelinux.com GLI AUTORI Laureato in Informatica all'universitˆ di Pisa, da circa 13 anni sistemista Unix, lavorando praticamente su tutte le piattaforme e su tutte le versioni di Unix proprietario. Si occupato di sistemi a parallelismo massivo e per il calcolo parallelo, seguendo in modo operativo le varie evoluzioni di mercato. E' sistemista presso il Centro di Calcolo della Scuola Normale Superiore di Pisa. 40 INTERMEDIO

3 I FILE SYSTEM DISTRIBUITI LINUX&C APRILE che solitamente ci portiamo dietro! E' solo un sogno? O forse la realtˆ comincia ad avvicinarsi al sogno, senza necessariamente richiedere centinaia di milioni di lire da pagare a questa o quella multinazionale dell'it? Se dovessimo individuare i componenti principali che caratterizzano il nostro ÒsognoÓ li sintetizzeremmo cos : 1) File systems Distribuiti; 2) Database Amministrativi; 3) Componenti per il bilanciamento del carico; 4) Componenti per l'affidabilitˆ di servizi; 5) Componenti per l'alta disponibilitˆ di servizi; 6) Componenti per il Calcolo ad Alte Prestazioni; 7) Componenti per il monitoring e l'amministrazione centralizzata. Proviamo a fare una rapida carrellata nell'universo Linux per vedere quanti dei suddetti componenti possono essere reperiti, e quali sono le loro caratteristiche pricipali. Giocoforza queste tematiche avrebbero bisogno di approfondimenti che non possibile trattare all'interno di questo contenitore. Ce ne scusiamo con i lettori, ma gli argomenti saranno trattati solo Òa volo di uccelloó. File system distribuiti I file systems distribuiti sono argomento di intensa ricerca e sperimentazione da almeno vent'anni. Ultimamente si sono consolidati due grandi filoni entro i quali vengono convogliati gli sforzi implementativi e di ricerca. Il primo rappresentato dai filesystem distribuiti ÒclassiciÓ (come ad esempio NFS e AFS) che mettono a disposizione files e directories su tutti i sistemi collegati su di una rete con protocollo TCP/ IP. L'altro rientra invece nella categoria dei cosiddetti file system di tipo SAN (Storage Area Network) come GFS che permettono invece ai sistemi di condividere i dispositivi di storage attravero una rete dedicata (tipicamente Fiber Channel, che supporta nativamente il protocollo SC) e mostrare i dischi come fossero locali. Ma qual il ÒgiustoÓ file system distribuito per le nostre necessitˆ? La risposta a questa domanda pu dipendere da diversi fattori, quali, ad esempio, la distribuzione topologica dei nodi, il grado di sicurezza richiesto, le prestazioni desiderate, l'espandibilitˆ e la tolleranza ai guasti, il numero e la qualitˆ dei sistemisti che abbiamo a disposizione... In figura 1 presentiamo una tabella comparativa dei file system distribuiti, comparsa in un articolo di Bill Von Hagen comparso su Linux Magazine del Novembre 2000, che forse potrˆ essere d'aiuto per Òfare la scelta giustaó. Soffermiamoci per ora su i Òfilesystems distribuiti classició che forniscono in effetti indubbi vantaggi a chi usa e gestisce un sistema di calcolo distribuito perch permettono un accesso trasparente ai files sulla rete indipendentemente dal tipo di sistema con cui si compie tale accesso (Unix, Windows, Mac...). Da un punto di vista storico tutto cominci con il sistema Domain Network Filesystem di Apollo nei primi anni '80. Si basano su un funzionamento di tipo client/server in cui i file servers contengono fisicamente i files e le directories e i clients accedono e modificano i files stessi. Tutti hanno 3 caratteristiche di base: l'accesso trasparente ai files utente da tipi di sistemi diversi; un sistema di autenticazione Filesystem Piattaforme Supportate Sistema di sicurezza Scalabilitˆ Posizione della Cache del Client Cache Permanente Disponibile? Licenza AFS Unix (tutte), Linux RedHat, Windows 95, 98, NT e 2000 Kerberos Eccellente directory del disco locale IBM Public License CODA Linux, NetBSD, FreeBSD, Windows 95, NT Kerberos directory o partizioni del disco locale GPL Lesser GPL GFS Linux Qualsiasi NO N.D. GPL InterMezzo Linux, kernel 2.2 o superiori NESSUNO directory o partizioni del disco locale GPL NFS Unix (tutte), Linux (tutte), Windows 95, 98, NT, 2000 yp, NIS, NIS+ Accettabile directory del disco locale NO La versione per Linux GPL: altre licenze proprietarie ma comunque aperte. Figura 1: un confronto tra i vari file systems distribuiti. INTERMEDIO 41

4 LINUX&C APRILE I FILE SYSTEM DISTRIBUITI distribuita in rete (network-oriented); la gestione di accessi concorrenti ai files e la sincronizzazione delle modifiche. NFS Nato da un progetto di Sun Microsystems degli anni 80, il Network File System ad oggi il filesytem distribuito pi diffuso. Praticamente tutte le piattaforme lo supportano, rendendolo pertanto il supporto ideale per implementare dispositivi di storage tipo Network Attached Storage (NAS). Nonostante il suo protocollo abbia subito varie revisioni negli anni il sistema ha comunque alcuni problemi. Il primo problema che i client non mantengono una cache locale, quindi il server un single point-of-failure cruciale per il funzionamento dell'intero sistema. Il secondo sono le prestazioni (anche se le pi recenti versioni di Linux hanno un NFS daemon integrato dentro il kernel, con eccellenti prestazioni, anche se con alcune limitazioni). Il terzo la scalabilitˆ, consentita fino a cluster di piccole/medie dimensioni e comunque sia all'interno di LAN. Altra carenza derivante dalla strutturazione stessa di NFS il meccanismo di autenticazione debole, ovvero quel meccanismo che riconosce se il client che compie una richiesta di servizio o meno autorizzato a farla. E infine il meccanismo di locking: fino alla versione 2 tale meccanismo era senz'altro il punto debole del sistema, creando seri problemi in presenza di accessi concorrenti in scrittura sullo stesso file da parte di diverse macchine. Il meccanismo di locking stato migliorato con la versione 3, permettendo fra l'altro una migliore scalabilitˆ dell'intero sistema (teoricamente fino a comprendere un insieme di nodi apparteneneti a due intere sottoreti di classe C, ossia circa 500 macchine). Sull'altro versante, l'ampia diffusione e la sua facilitˆ di configurazione e gestione sono alla base del suo successo. AFS AFS (Andrew File System) fu un progetto finanziato nel 1983 dall'ibm alla Carnegie-Mellon University (CMU). Nel 1989 divenne un prodotto commerciale della Transarc (poi acquisita da IBM). Nelle intenzioni degli sviluppatori AFS avrebbe dovuto soppiantare NFS (se non ci credete, guardate la figura 2, realizzata dai bad-guys della Transarc); in parte questo si verificato laddove i limiti di NFS ne rendevano praticamente impossibile l'utilizzo. Tuttavia, gli alti costi del prodotto e la difficoltˆ nella gestione, soprattutto legata alla necessitˆ di adottare la kerberos authentication, non hanno di fatto portato AFS Figura 2: le intenzioni di AFS sono piuttosto chiare :) all'obbiettivo previsto. La struttura di base la cella AFS: la cella dal punto di vista di accesso ai files vista come un sottoalbero dello spazio globale dei nomi messo a disposizione da AFS (che appare come directory "/afs"); dal punto di vista hardware la cella un insieme di servers e clients amministrativamente collegato, quindi ogni ente/industria/istituzione avrˆ definita una cella separata (ad es., l'istituto di Fisica Nucleare nazionale ha una cella propria indirizzata /afs/infn.it). Le varie celle situate in varie parti della rete condividono i dati su Internet. Il modello di AFS client-server, con distribuzione su WAN dei nodi e scalabilitˆ elevatissima. I veri punti di forza di questo sistema sono tre: caching, fault tolerance e strong-authentication. Per contro, c' una maggior difficoltˆ amministrativa/gestionale, la necessitˆ di server dedicati con compiti diversi (file server, authentication server etc.) e la necessitˆ di modificare il meccanismo di autenticazione standard di sistema, che si ripercuote sull'utilizzo delle applicazioni. Il meccanismo di autenticazione dei client infatti basato su Kerberos, per assicurare un alto grado di sicurezza. Ogni richiesta di servizio AFS viene autenticato tramite "ticket" (AFS "token") che hanno una durata temporale limitata. Nel settembre 2000 IBM ha reso il codice sorgente di AFS di pubblico dominio. CODA e INTERMEZZO Coda e Intermezzo hanno in comune il creatore Peter.J.Braam. Coda nasce alla Carnegie Mellon University come erede di AFS versione 2 ed aggiunge alcune caratteristiche interessanti a quelle di AFS, quale ad esempio la possibilitˆ di eseguire operazioni in modalitˆ disconnessa con successiva reintegrazione. In pratica una volta che viene a mancare la connessione (indisponibilitˆ del Server o mancanza di con- 42 INTERMEDIO

5 I FILE SYSTEM DISTRIBUITI LINUX&C APRILE Figura 3: CODA permette di operare in modalitˆ disconnessa con successiva reintegrazione. nessione di rete) Coda crea un log delle operazioni sul disco locale della macchina client. Una tipica situazione schematizzata in figura 3. Con i servers nuovamente disponibili avviene una sincronizzazione delle operazioni registrate dal client con i files sul server. L'affidabilitˆ dimostrata dal sistema ha fatto s che il Coda Filesystem sia stato, a partire dalla versione 2.2, integrato direttamente nel kernel di Linux. Intermezzo, che nasce alla Stelias Computing e alla Mountain View Data (dove ora lavora Braam), viene pensato come una evoluzione di Coda. E' un filesystem ancora in fase di test e conserva gran parte delle caratteristiche di Coda cercando di migliorarne le prestazioni in fase di sincronizzazione dopo operazioni disconnesse. E' implementato in C e Perl (il cache-manager e il file server sono scritti in Perl) e sembra molto promettente La tecnologia SAN offre delle possibilitˆ finora impensate sul fronte della distribuzione dei file systems, le cui implicazioni potranno stravolgere il concetto di clustering. La pi famosa implementazione di file system su architettura SAN senza dubbio GFS (Global File System), ma vorremo solo citare il progetto LUSTRE (il cui nome deriva dall'associazione di Linux e Cluster) che porta ad un livello di astrazione molto elevato l'idea di un'implementazione di file system non pi basato sul paradigma di accesso a block devices. Per chi volesse approfondire consigliamo il sito e quello della Carnegie Mellon University Va forse sottolineato che comunque la tecnologia SAN richiede un livello di sofisticazione elevato, nel senso che necessario installare adattatori speciali nei sistemi e realizzare una rete (tipicamente in fibra ottica) dedicata alla condivisione dei dispositivi. GFS Il GFS (Global File System) un file system a dischi condivisi implementato per clusters di sistemi Linux dalla Sistina Software. I nodi di un cluster GFS condividono gli stessi dispositivi di storage, accedendo questi devices a livello block anzich a livello files o directories. Questa condivisione dei dispositivi di storage pu avvenire con l'uso di collegamenti Fiber Channel, dispositivi SC condivisi e network block devices (NBD). Per questo motivo GFS richiede l'uso di drivers per i dischi a basso livello invece che daemons tradizionali client-server che lavorino a livello files e directories. Un file system GFS appare come locale su ogni nodo e GFS si occupa della sincronizzazione dell'accesso ai files attraverso il cluster. Un file system implementato su devices condivise offre diversi vantaggi rispetto alla tradizionale architettura client-server: Disponibilitˆ del file system: aumentata grazie al fatto che non esiste pi un unico point-offailure dalla parte host. Se uno o pi host diventano indisponibili, il file system e i suoi dati sono ancora accedibili agli hosts rima- Figura 4: I nodi di un cluster GFS condividono gli stessi dispositivi di storage. INTERMEDIO 43

6 LINUX&C APRILE I FILE SYSTEM DISTRIBUITI nenti. Load Balancing: il carico viene distribuito tra i vari hosts che accedono al disco. Pooling: la possibilitˆ di raggruppare logicamente in un unico volume i dispositivi di storage diminusce la complessitˆ di amministrazione. Scalabilitˆ: in capacitˆ, connettivitˆ e banda passante pu essere raggiunta senza compromessi. L'implementazione attuale del GFS supporta il journaling del file system e il recupero rapido degli errori. Uno schema architetturale di GFS riportato in figura 4. Database Amministrativi Distribuiti Un sistema propriamente configurato dipende da decine di files di configurazione, ognuna contenente la giusta porzione di informazione che permette il corretto funzionamento del sistema stesso. Se moltiplichiamo questo numero di files per i nodi di un cluster, arriviamo con facilitˆ a numeri che impediscono di fatto una gestione manuale di ogni singolo file su ogni singolo nodo. L'introduzione di un Database Amministrativo Distribuito permette di eliminare le informazioni dai files, e forzare allo stesso tempo la ricerca di quelle informazioni attraverso un accesso al database di rete. La costruzione del database avviene a partire dai ÒflatÓ files contenenti le informazioni amministrative. Vengono forniti perci alcuni strumenti che permettono di estrarne il contenuto, costruire le basi di dati, gestire la manipolazione dei dati e renderle disponibili sulla rete (via RPC, remote procedure call). Le diverse implementazioni differiscono soprattutto per il livello di sicurezza devoluto al sistema di autenticazione dei client. I files amministrativi pi comuni le cui informazioni possono essere distribuite sono /etc/passwd, /etc/shadow, /etc/group, /etc/gshadow, /etc/hosts, /etc/networks, /etc/services, /etc/protocols, /etc/mail/aliases, /etc/rpc, /etc/netgroup o loro corrispettivi. Le implementazioni di db amministrativi che consentono la distribuzione dei suddetti file di sistema sono essenzialmente due: NIS (Network Information Service) e NIS+ (detto anche NIS con steroidi), che sotto Linux al momento implementato solo per il lato client. Ad essi va aggiunto anche LDAP (Lightweight Directory Access Protocol), protocollo di directory access che nelle ultime release di alcune distribuzioni pu assurgere a metodo di autenticazione dei sistemi (con l'utilizzo delle librerie PAM, Pluggable Authentication Module). Tuttavia LDAP da noi visto pi come mezzo d'integrazione di servizi piuttosto che come database amministrativo. NIS Il NIS Ž una invenzione di Sun Microsystems Inc., risalente agli anni '80. Originariamente conosciuto come YP (Yellow Pages), sub questa ridenominazione a causa di ragioni legali legate al ÒtrademarkÓ del nome "yellow pages" da parte della British Telecomunication in UK. Dal punto di vista architetturale, le caratteristiche del NIS sono le seguenti: architettura client/server, basata su RPC e protocolli TCP e UDP; all'interno della rete locale deve essere presente almeno un sistema che agisca come NIS master server; ogni NIS server Ž associato ad un dominio NIS; Ž possibile, ed anche auspicabile, che pi sistemi nella rete siano configurati come NIS server all'interno di un dominio NIS, agenti fra loro in modo cooperativo e comunque facenti capo ad un unico NIS master server (gli altri server prendono il nome di NIS slaves); sul lato client Ž possibile eliminare del tutto le informazioni amministrative dai files di sistema, richiedendo attraverso una interrogazione ad uno dei server NIS tali informazioni quando effettivamente servono. Il NIS Master Server mantiene i files di configurazione ed i NIS databases da essi derivati (chiamati "mappe NIS"). Le mappe vengono distribuite ai vari slave servers ogni qualvolta vengono create o modificate, mantenendo quindi sincroni fra loro i vari database. Nel caso che uno slave server sia indisponibile al momento della distribuzione delle mappe, esistono giˆ predisposti dei meccanismi di ÒpollingÓ, che forzano periodicamente tale sincronizzazione. I NIS Slave Servers mantengono una propria copia delle mappe, ma non necessitano dei files originari. Possono essere quindi interrogati dai client al posto del master. Questo meccanismo di replica pu essere utile sia per garantire una certa scalabilitˆ all'intero sistema, sia come recovery in caso di non disponibilitˆ del master, o persino in caso di "disastri" comportanti un partizionamento fisico della rete. Sul lato NIS Client Ž possibile decidere se derivare le informazioni amministrative dai propri files, se importarle dalle corrispettive mappe NIS esportate dai servers, od utilizzare un mix di entrambi, attraverso l'introduzione nei files di sistema dei cosiddetti NIS Magic Cookies. 44 INTERMEDIO

7 I FILE SYSTEM DISTRIBUITI LINUX&C APRILE di definire politiche di privilegi su porzioni dei dati in esse contenute; il modello di autenticazione ed autorizzazione associato con lo spazio dei nomi ed i dati in esso contenuti. In questo modo si ha la capacitˆ di autenticare i servizi di rete, ovvero discriminare fra chi pu o non pu accedere ad un certo servizio, e autorizzare l'accesso al servizio, ossia dire cosa pu fare o a quale porzione di dati pu accedere un cliente autorizzato per un determinato servizio. Figura 5: schema di funzionamento dellõinterazione tra NIS server e client. ƒ inoltre possibile dare un ordine di prioritˆ alla ricerca fra locale e NIS in modo selettivo per ogni singolo file amministrativo. L'aspetto focale Ž comunque che su lato client per utilizzare il servizio NIS non deve essere presente alcuna porzione dei database amministrativi. Uno schema di funzionamento dell'interazione fra NIS server e client riportato in figura 5. Qualsiasi implementazione del NIS consente di sfruttare meccanismi di sicurezza abbastanza limitati per la protezione degli accessi ai servers. Questo, unitamente ad una scalabilitˆ limitata dell'intero sistema, rappresentano, se volete, i veri punto debole del NIS. NIS+ Sebbene dal punto di vista Linux abbia una importanza limitata, essendo al momento presente solo un'implementazione lato client, NISplus, creato da Sun come rimpiazzamento del suo predecessore, risponde ad alcune delle esigenze lasciate in sospeso dal NIS. NIS+ Ž un applicazione client/server costruita sopra l'interfaccia ONC Trasport-Indipendent Remote Procedure Call. Le applicazioni RPC sono quindi clients del servizio NIS+, e lo utilizzano per localizzare e collegarsi ai servers RPC distribuiti su una rete di sistemi potenzialmente etereogenei. Fra le varie caratteristiche, NIS+ consente: un controllo amministrativo decentrato; la prevenzione da accessi non autorizzati attraverso un meccanismo distribuito di sicurezza; la scalabilitˆ nell'ordine di migliaia di nodi; la garanzia di un alto livello di consistenza nelle informazioni. I miglioramenti introdotti dal NIS+ ricadono in tre categorie generali: la struttura dello Òspazio dei nomi" globale, con l'introduzione di un sistema gerarchico per l'assegnazione dei nomi di dominio, tipo quello utilizzato per il servizio di Domain Name System (DNS); la struttura dei dati all'interno delle mappe, con la possibilitˆ NIS+ pu essere configurato per mantenere compatibilitˆ col NIS, ma in questo modo vengono meno tutte le sue prerogative in termini di sicurezza. E alfin vi giunga un monito... l'installazione e la gestione di un server NIS+ uno dei compiti pi ardui che un sistemista possa accollarsi, uno di quei compiti che valgono solitamente un aumento di stipendio (sigh!). Su lato client, le cose migliorano notevolmente, anche se si rende necessaria l'installazione di Secure RPC ed un buon meccanismo di sincronizzazione temporale fra i nodi del dominio NIS+. Permetteteci quindi una considerazione lapalissiana: complicatevi la vita solo per validi motivi! E per seguire... Nella prossima parte tratteremo del software disponibile sotto Linux per l'implementazione di quei componenti rimasti al momento fuori dalla trattazione, ovvero i cluster a bilanciamento del carico, i cluster in alta disponibilitˆ, quelli ad alta affidabilitˆ, le componenti di monitoraggio e di amministrazione centralizzata e i cluster per calcoli ad alte prestazioni. INTERMEDIO 45