SEMINARIO DI SISTEMI DISTRIBUITI 2002/2003 IL CLUSTERING

Transcript

1 SEMINARIO DI SISTEMI DISTRIBUITI 2002/2003 IL CLUSTERING

2 INDICE INDICE...2 Introduzione...3 Un esempio...3 Architetture tradizionali...4 Architettura cluster...4 Caratteristiche generali del Cluster Service e del Network Load Balancing...5 Cluster Service...5 Network Load Balancing (NLB)...5 Organizzazione di un Cluster...6 FARM...7 PACK...7 SHARED DISK MODEL...7 SHARED NOTHING MODEL...8 Componenti dell architettura del cluster server...9 NODI...9 NETWORK...11 RESOURCES...11 UNA PARTICOLARE RISORSA: LA QUORUM RESOURCE...13 RESOURCE TYPES...14 RESOURCE GROUP...15 CLUSTER ADMINISTRATOR...18

3 Introduzione In termini generali, un cluster è un gruppo di sistemi indipendenti che funzionano come un sistema unico. Un client interagisce con un cluster come se questo fosse un unico server. Le configurazioni cluster sono utilizzate per ragioni di disponibilità (availability), gestibilità (manageability) e scalabilità (scalability). Disponibilità: Si riferisce alla capacità di gestire le richieste degli utenti nel modo più continuativo possibile cercando di ridurre al minimo i casi di failure del sistema. Generalmente un cluster provvede alla necessità di availability duplicando e rendendo disponibili le risorse su tutte le macchine che lo compongono. Quando un sistema o un applicazione del cluster sono interrotti, il software del cluster reagirà (tramite un processo chiamato failover) riavviando l applicazione o suddividendo le operazioni del sistema interrotto ai restanti sistemi del cluster (load balancing), dividendo perciò il carico di lavoro, garantendo così un servizio continuativo all utente finale. Gestibilità: Gli amministratori utilizzano una console grafica per spostare le applicazioni e i dati all interno del cluster su server diversi utilizzando un punto di controllo centralizzato che può essere anche remoto grazie ad un potente tool: il Cluster Administrator. Queste operazioni sono eseguite per bilanciare manualmente i carichi di lavoro e per liberare i server per operazioni di manutenzione senza che sia necessario interrompere il sistema. Scalabilità: Si riferisce alla possibilità di aggiungere risorse intese come CPU, memorie o dischi (operazione di scale up) o computer (operazione di scale out) al sistema per potenziare le performance quando il carico totale va oltre le capacità del sistema cluster stesso. Questo permette di aumentare le prestazioni con costi contenuti. Un esempio I punti di vendita sono il punto focale del settore commerciale. Per mantenere aggiornate le registrazioni delle vendite è necessario che ogni cassa abbia accesso continuo al database dei prodotti del negozio, ai codici, ai nomi e ai prezzi. In caso di errore del sistema del punto di vendita, le vendite non potranno essere registrate con conseguente perdita di denaro, clienti e della qualità del servizio. In questo caso, la tecnologia di clustering può essere utilizzata per garantire la disponibilità del sistema. La soluzione clustering potrebbe essere costituita da due server con accesso a dispositivi di memorizzazione multi-port (Disk Array) sui quali si trova il database. Nel caso dell arresto del Server uno, il sistema di backup (Server due) è automaticamente messo in funzione e gli utenti finali sono commutati sul secondo server, senza alcun intervento tecnico. Il downtime è in questo modo ridotto al minimo. La tecnologia dei dischi con tolleranza agli errori incorporata nei NOS protegge il disk array, ma l utilizzo congiunto della tecnologia di clustering consente al sistema di restare in funzione.

4 Il clustering può agevolare i professionisti informatici nella progettazione di sistemi che sono in grado di crescere parallelamente alle esigenze di un organizzazione, consente inoltre una maggiore flessibilità. Architetture tradizionali Una struttura hardware tradizionale per ottenere un alta disponibilità è quella di duplicare i sistemi con componenti completamente replicati. Il modello software tradizionale per l utilizzo di questo hardware prevede che uno dei sistemi esegua l applicazione mentre l altro resti inattivo, pronto a sostituire il sistema primario in caso di arresto. I difetti di questo approccio comprendono l aumento dei costi dell hardware, che non corrispondono a un miglioramento della capacità di elaborazione del sistema, e la mancanza di protezione nel caso di errori intermittenti delle applicazioni. Per aumentare la scalabilità sono state utilizzate numerose architetture diverse. Una struttura hardware per ottenere la scalabilità andando oltre un solo processore è il sistema di symmetric multiprocessing (SMP). Un sistema SMP è composto da più processori che condividono una memoria e un sottosistema I/O globali. Il modello software SMP tradizionale, denominato "modello a memoria condivisa", esegue una sola copia del sistema operativo con i processi delle applicazioni eseguiti come se si trovassero su un sistema con un solo processore. Se su un sistema SMP vengono eseguite delle applicazioni che non condividono dati, il sistema consente un elevato grado di scalabilità. A livello dell hardware, il principale problema dei sistemi SMP sono le limitazioni fisiche della velocità di memoria e di bus. Superare queste limitazioni implica investimenti costosi, infatti con l aumento della velocità dei microprocessori, i multiprocessori con memoria condivisa hanno costi sempre più elevati. Al momento passare da un solo processore a 2-4 processori è un operazione costosa, e ancora più costosi sono i sistemi che vanno oltre gli 8 processori. Infine occorre sottolineare che né la struttura hardware dei sistemi SMP né il corrispondente modello software tradizionale fornisce vantaggi intrinseci di disponibilità rispetto ai sistemi a processore unico. Esiste però un architettura che si è dimostrata ottimale per ottenere disponibilità e scalabilità nelle applicazioni per l elaborazione business critical: il cluster. Architettura cluster Un cluster è un insieme di sistemi di computer accoppiati liberamente e indipendenti che agiscono come un sistema unico. I client vedono un cluster come se fosse un unico server ad elevate prestazioni e altamente affidabile. Anche i gestori dei sistemi vedono un cluster praticamente allo stesso modo in cui vedono un server unico. La tecnologia di clustering è facilmente adattabile alla tecnologia standard dei computer, a basso costo e con possibilità di interconnessione. Il clustering può essere implementato in molti modi diversi. Un cluster può essere semplicemente

5 struttura hardware potrebbe essere composta da sistemi SMP ad elevate prestazioni interconnessi da bus I/O per le comunicazioni ad elevate prestazioni. In entrambi i casi, l aggiunta di capacità elaborative viene effettuata in piccole fasi successive, aggiungendo altri sistemi. È possibile aggiungere al cluster ulteriori sistemi per elaborare richieste più complesse o più frequenti da parte dei client. Se uno dei sistemi di un cluster si arresta, il carico di lavoro di quel sistema può essere automaticamente suddiviso tra i restanti sistemi. Quest operazione in genere non è rilevata dal client. Facendo riferimento alle Clustering Technologies fornite da Windows 2000 Advance Server possiamo identificare due tecnologie di base differenti: il Cluster Service e il Network Load Balancing. Queste due tecnologie hanno caratteristiche differenti tra loro e possono essere usate in maniera indipendente oppure in combinazione tra loro, indifferentemente. Caratteristiche generali del Cluster Service e del Network Load Balancing Cluster Service: è praticamente il cervello del sistema e su ogni nodo del Cluster vi è una istanza del Cluster Service. Tutte quelle applicazioni denominate Line-of-Business applications (che includono database, messaggi di sistema e altro) sono operazioni fondamentali per una qualsiasi compagnia che deve fornire diversi servizi. Cluster Service è proprio il componente che assicura che queste applicazioni siano sempre attive e disponibili, eliminando ogni volta i punti di failure del sistema tramite la politica del Failover. Oltre a gestire il failover, il Cluster Service si occupa anche dei Cluster Objects, dei dischi, della configurazione del Cluster e di tutte le comunicazioni che ci sono tra i server del sistema e tutte le applicazioni che vi appartengono. Fondamentalmente questo servizio viene utilizzato in tutti quei sistemi come i Back-End system (questi ultimi sono proprio quelli che generalmente vengono intesi come i server di sito web) che hanno costantemente bisogno che le loro applicazioni siano sempre attive ventiquattr ore su ventiquattro e per 365 giorni l anno. Il Cluster Service offre i seguenti vantaggi: Riduzione drastica del periodo di tempo in cui un server di un Cluster viene considerato down grazie alla politica del Failover e conseguente applicazione delle varie politiche di Failback (processo inverso al Failover che consiste nel trasferire nuovamente le risorse nel loro server di origine dal quale erano state spostate, una volta che questo ritorna disponibile). Grande possibilità di operare gli upgrade del sistema senza perdere in prestazioni proprio perché il Cluster Service è stato progettato per garantire un aggiornamento del sistema in modo completamente trasparente all utente. Questo avviene facendo migrare da un nodo all altro le varie applicazioni, operando l upgrade sul primo nodo e quindi riportando le applicazioni sul nodo di partenza. Usando il cluster service infatti riusciamo a completare ogni tipo di upgrade (sia esso hardware, software o addirittura di un intero sistema operativo) senza dover portare offline l applicazione in questione e quindi senza interruzioni nel lavoro del cliente. Grande gestibilità di tutto il sistema grazie alla presenza del Cluster Administrator che permette all amministratore, tramite l uso di un solo semplice tool, di definire tutte le varie politiche di controllo e di gestione. Questo tool inoltre permette di visualizzare, monitorare e modificare tutte le risorse del Cluster da una unica locazione, che può essere anche remota, senza nuovamente dover portare offline le varie applicazioni su cui si deve andare ad operare. Network Load Balancing (NLB): questo tipo di servizio viene generalmente utilizzato per

6 quando vorremo gestire nel migliore dei modi Web Servers oppure Front-end system che devono supportare un notevole carico di richieste da parte di più utenti e che non devono calare in prestazioni anche se un computer della rete smette di funzionare. A differenza del Cluster Service che opera su sistemi composti al più da 2/4 server, l NLB supporta reti di computer che possono comprendere fino a 32 server. L utilizzo di questo servizio ci offre i seguenti vantaggi: Scalabilità: la rapida crescita di Internet e di tutti i servizi che ad essa sono correlati, ha fatto nascere una forte necessità di avere sistemi, come i Web Server, che potessero essere dinamicamente scalabili per poter far fronte al continuo aumento di richieste da parte degli utenti. NLB distribuisce, in maniera assolutamente trasparente, le richieste dei clienti attraverso tutti i servers presenti nel cluster (detti anche hosts); nel momento in cui il traffico viene ad aumentare, per evitare cali di prestazione che possono verificarsi soprattutto a causa di colli di bottiglia, l amministratore della rete semplicemente non deve far altro che aggiungere un altro server al cluster (fino ad un massimo di 32) per poter di nuovo avere il carico di lavoro bilanciato tra tutte le macchine disponibili (operazione di scale-out). Alta disponibilità: NLB oltre che provvedere all eliminazione dei bottleneck, garantisce anche la gestione delle situazione di failover. Nel Cluster Service, ad ogni failure del sistema, le applicazioni coinvolte venivano spostate direttamente sull altro nodo del cluster e in seguito venivano riportate sul cluster di origine; in questo caso invece, quando si verifica una situazione di failover, NLB ripartisce il traffico attraverso tutti i restanti server del cluster, bilanciando tra loro il carico di lavoro del server offline. Nel momento in cui il server viene ripristinato, NLB opera nuovamente l operazione di bilanciamento del carico di lavoro tra tutti i server disponibili. Tutte queste operazioni appena descritte sono completamente automatiche e il tempo di failover è così breve (meno di 10 secondi) che l utente riesce sempre ad ottenere le massime prestazioni dal sistema senza sperimentare grossi cali di performance o addirittura interruzione della comunicazione. Limitazioni: abbiamo detto che fondamentalmente un cluster è progettato per gestire i casi di failure del sistema, delle applicazioni e anche dei siti, ma in generale il cluster non riesce anche a garantire l integrità dei dati dell utente quando i guasti sono causati da virus, decadenza del software usato oppure da errori umani. Il recupero dei dati dell utente dovrebbe essere fatto dall applicazione stessa che deve essere progettato appositamente per contemplare questa eventualità. Organizzazione di un Cluster I Clusters possono essere composti da due o più server raggruppati tra loro ma generalmente l organizzazione interna varia a seconda del modo in cui questi sistemi verranno usati e a seconda delle applicazioni che poi vi dovranno girare. Il disegno seguente illustra la tipica configurazione per un cluster composto da due soli nodi:

7 La configurazione è quella di base dove due server sono connessi fra loro tramite una rete interna; il cluster è accessibile da diversi clienti appartenenti tutti ad una rete locale (LAN) a cui il cluster appare come una singola entità. Per quanto riguarda invece cluster composti da più di due server possiamo identificare due tipi distinti di gruppi di cluster che vengono definiti farm e pack. FARM: è composta da un gruppo di server che forniscono servizi simili, ma che tipicamente non condividono dati. Front-end Web Servers che gestiscono Internet Information Services (IIS) usando NLB sono un tipico esempio di un cluster farm. In una Web farm troviamo dati identici replicati in ogni server del farm e ognuno di questi può gestire le richieste inoltrate dagli utenti usando le copie locali dei dati che ha al suo interno. Spesso si fa riferimento a questi definendoli come cloni perché ogni server, pur lavorando indipendentemente dagli altri, è praticamente identico a tutti quelli del farm e possiede copie uguali dei dati (invece di condividerli). PACK: generalmente vengono definiti packs quei gruppi di server che condividono dati partizionati e che collaborano in tutte le operazioni di gestione e mantenimento del sistema e dei servizi forniti. Tutti i membri di un pack condividono l accesso a dati partizionati, che però si trovano tutti su dischi e memorie a cui tutte le macchine sono connesse; ogni server quindi non potrà gestire qualsiasi richiesta inoltrata dall utente, ma ne potrà soddisfare solo una porzione ben definita. Il fatto di separare tra i server le modalità di risposta alle varie richieste è fondamentale per evitare che nascano problemi di inconsistenza di dati (dovuti magari ad accessi ad uno stesso dato da parte di macchine diverse). I due tipi di organizzazione del Cluster appena descritti derivano direttamente dall interpretazione di due modelli software fondamentali che vengono usati oggigiorno nell ambito del clustering e che sono lo shared disk model e lo shared nothing model. SHARED DISK MODEL: Nel modello a disco condiviso, il software in esecuzione su qualsiasi sistema del cluster può accedere a qualunque risorsa, quale ad esempio un disco, connessa a qualsiasi sistema del cluster. Se gli stessi dati devono essere a disposizione di due sistemi, i dati dovranno o essere letti due volte dal disco oppure copiati da un sistema all altro. Analogamente a quanto accade in un sistema SMP, l applicazione deve sincronizzare e serializzare l accesso ai dati condivisi. Sono condivisi dischi e

8 sincronizzazione si utilizza in genere un Distributed Lock Manager (DLM). Un DLM è un servizio fornito alle applicazioni per mantenere traccia dei riferimenti alle risorse in tutto il cluster. Nel caso in cui più di un sistema cerchi di fare riferimento alla stessa risorsa, il DLM riconosce il potenziale conflitto e lo risolve. Le attività del DLM possono tuttavia causare un aumento del traffico dei messaggi e ridurre le prestazioni a causa dell accesso serializzato associato ai sistemi aggiuntivi. Un modo per risolvere questi problemi è il modello software senza condivisione. SHARED NOTHING MODEL: Nel modello software senza condivisione, ogni sistema del cluster possiede un sottoinsieme delle risorse del cluster. Una determinata risorsa può essere di proprietà di un solo sistema alla volta, il quale è anche l unico a disporre dell accesso a quella risorsa particolare, benché in caso di arresto di quel sistema un altro sistema determinato in modo dinamico potrà prendere possesso della risorsa. Le richieste dei client vengono indirizzate automaticamente al sistema che possiede la risorsa. Se ad esempio un client richiede l accesso a risorse di proprietà di più sistemi, per soddisfare la richiesta verrà scelto uno dei sistemi. Il sistema host analizza la richiesta del client e invia sottorichieste ai sistemi appropriati. Ciascun sistema esegue la sottorichiesta che gli compete e restituisce al sistema host solo la risposta richiesta. Il sistema host unisce quindi le varie risposte nella risposta finale completa e la invia al client. Utilizzando un applicazione distribuita su più sistemi in cluster, quale un database, le prestazioni globali del sistema non subiscono limitazioni dipendenti dalle limitazioni hardware di un solo computer. È possibile supportare i modelli a disco condiviso e senza condivisione all interno dello stesso cluster. Esistono tipi di software che riescono a sfruttare con facilità le capacità del cluster tramite il modello a disco condiviso. Questo tipo di software comprende applicazioni e servizi che richiedono un modesto accesso condiviso (a lettura intensiva) ai dati, insieme ad applicazioni o carichi di lavoro che sono molto difficili da suddividere. Le applicazioni che richiedono il massimo della scalabilità dovrebbero utilizzare il supporto senza condivisione del cluster.

9 Sia il modello shared-disk sia quello shared-nothing possono essere implementati nello stesso cluster, ma il secondo viene soprattutto usato quando si devono sviluppare applicazioni che hanno bisogno di alta scalabilità del sistema (vedi il caso del NLB). Componenti dell architettura del cluster server Tipicamente in una architettura cluster server possiamo identificare i seguenti componenti software: Cluster Service; Uno o più Resource Monitor; Uno o più Resource DLLs; Cluster Network Driver; Cluster Administrator; Vengono invece identificati come componenti hardware i Cluster Server Objects che generalmente comprendono i nodi del sistema, le networks, le risorse, i resource type e i gruppi di risorse. NODI: è un computer system membro del cluster; ogni macchina che fa parte del cluster viene definita nodo del sistema il quale può essere sia attivo che passivo: ATTIVO: un nodo viene definito attivo quando sta effettivamente gestendo tutte le richieste che gli vengono inoltrate dai clienti. PASSIVO: un nodo viene definito passivo quando si viene a trovare in situazione di standby, ovvero è in attesa che un altro nodo del sistema cada, per sostituirsi ad esso; in questo caso si dice anche che si trova nello stato idle.

10 Quando si va a progettare una architettura multi-node di un cluster bisogna fare attenzione a come configurare i nodi del sistema, ovvero quali mettere attivi e quali passivi, soprattutto perché da questo dipenderà la configurazione hardware del sistema. Per capire meglio questo problema si riportano due esempi di configurazione di un cluster multinode. 1) Architettura multi-node in cui vi è un nodo passivo per ogni nodo attivo: se ci troviamo in questo caso sappiamo che, nel momento in cui un nodo attivo viene a cadere, tutte le applicazioni e i servizi che giravano sulla macchina in questione vengono trasferite sul nodo passivo. Siccome il nodo passivo non ha un carico di lavoro corrente, il server riesce ad assumersi tutto il lavoro senza risentirne in alcun modo. Questo fattore è molto importante perché ci permette di progettare tutti i server del cluster con la stessa configurazione hardware. NODO A1 NODO P1 NODO A2 NODO P2 4-Node Clustering: 2 nodi attivi/2 nodi passivi Ogni nodo ha 4 CPU e 4GB di RAM Failover: da A1 a P1, da A2 a P2 2) Architettura multi-node in cui vi sono tutti nodi attivi e nessuno passivo: in questo caso, quando si verifica una situazione di failure in un nodo, tutto il carico di lavoro viene spostato su di un altro server anch esso attivo. Siccome un nodo attivo ha già il suo carico di lavoro da gestire, quando questo deve ricevere anche il workload della macchina caduta deve avere la capacità di sopportare entrambi i carichi, altrimenti rischia di andare in failure anch esso. Questa situazione ci dice quindi che, se nell altro caso i server potevano avere tutti la stessa configurazione hardware, qui dobbiamo progettare le macchine di modo che tutte abbiano una capacità doppia rispetto a quella che richiederebbe il loro singolo carico di lavoro per evitare che, una volta ricevuto il carico di lavoro del server in failure anche esso non lo segua. NODO A NODO B NODO C NODO D 4-Node Clustering: All nodes active Ogni nodo ha 8 CPU e 8 GB di RAM Failover: da A a B e viceversa, da C a D e viceversa

11 Le comunicazioni tra i vari nodi di un cluster sono monitorate e gestite dal Cluster Network Driver un particolare componente software avente due funzioni fondamentali. La prima è quella di garantire una comunicazione tra server sempre disponibile e attiva tramite il monitoraggio continuo dello stato di tutti le network del sistema e la spedizione dei messaggi lungo il percorso che viene scelto come il migliore e il più stabile La seconda è quella di rilevare le possibili failure di un nodo, mantenendo però attive le comunicazioni tra gli altri server, tramite l uso di messaggi periodici chiamati heartbeats. Questi messaggi sono inviati a tutti i nodi del sistema e vengono scambiati tramite tutte le network che vi sono tra i vari server e la loro funzione è quella di monitorare lo stato di salute dei vari link tra le reti e di notificare una situazione di failure di un nodo. Quando un server non risponde al messaggio di heartbeat, il cluster network driver notifica subito il fatto al cluster service che, tramite i suoi componenti, va a gestire il problema nel modo più appropriato. NETWORK: rete attraverso cui i nodi del cluster possono comunicare. In generale nel cluster server vengono individuati quattro ruoli principali affidati alle networks, in particolare abbiamo: 1) Private network o Interconnect: rete usata esclusivamente per le comunicazioni interne tra i vari nodi del cluster. 2) Internet: rete altamente usata, viene impiegata esclusivamente per le comunicazioni tra i clienti del sistema e i nodi del cluster. 3) Corporate network: rete impiegata sia per le comunicazioni interne al sistema, sia per le connessioni con i clienti. 4) Network senza ruolo o Network X: rete che, per qualche motivo particolare non può essere utilizzata dal cluster. RESOURCES: le risorse di un cluster sono entità fisiche o logiche che hanno le seguenti

12 Possono essere portate online oppure offline dal clustering software; Possono essere amministrate da un sistema di server cluster; Possono essere possedute da un solo nodo alla volta; Forniscono servizi ai clienti del cluster; Una risorsa può assumere i seguenti stati: Offline: è lo stato in cui una risorsa risulta non disponibile sia ai clienti sia a qualsiasi altra risorsa; Online: è lo stato in cui una risorsa è attiva e disponibile; Failed: si ha quando una risorsa non riesce né ad essere riportata online, né offline dopo un determinato intervallo di tempo. Pending states: la risorsa si trova negli stati online pending oppure offline pending quando è in corso il processo o di attivazione o di disattivazione della stessa. Se dopo un determinato intervallo di tempo la risorsa si trova ancora nello stato pendente, allora il suo stato verrà settato su failed. Generalmente le risorse sono implementate come Dynamically Linked Library(DLL) e vengono memorizzate nello spazio di indirizzamento dei vari Resource Monitors. Il Cluster Service usa le DLL per portare online le risorse, gestire le loro interazioni con le altre risorse del cluster e, più importante di tutto, per monitorare il loro stato di salute, evitando così situazioni di failure. Il resource monitor si trova in un processo separato dal Cluster service sostanzialmente per due motivi: principalmente per proteggere il Cluster Service dalle failure delle risorse, in secondo luogo per permettere al Resource Monitor di agire ugualmente se per caso si ha una failure del Cluster Service portando nello stato di offline tutte le risorse e i gruppi che si trovavano sul nodo caduto. Generalmente il resource monitor viene creato dal cluster service solo quando necessario (ovvero quando una nuova risorsa viene installata oppure semplicemente fatta partire su un nodo del sistema) ed opera praticamente come interfaccia di comunicazione tra le Resource DLL e il Cluster Service. Quando quest ultimo ha bisogno di ottenere dati da una risorsa, comunica questa necessità tramite una RPC al Resource Monitor relativo e questo invierà la richiesta alla DLL interessata. Viceversa, quando una risorsa deve riportare il proprio stato oppure la notifica di un evento al Cluster Service, sarà il Resource Monitor ad inviare le informazioni dalla risorsa al Cluster Service, sempre via RPC. Il grafico qui di seguito schematizza come il passaggio delle chiamate scorra dal Cluster Service attraverso il resource Monitor e le resource DLL, fino ad arrivare alla risorsa vera e propria.

13 Per default il Cluster Service crea un solo Resource Monitor per interagire con tutte le risorse presenti in un nodo, ma è anche possibile che ne esistano più di uno su di una singola macchina. E consigliabile, inoltre, che resources DLLs che potenzialmente potrebbero causare dei problemi abbiano ognuna il proprio resource monitor. UNA PARTICOLARE RISORSA: LA QUORUM RESOURCE Ogni cluster ha una particolare ed importantissima risorsa: la Quorum Resource. Può diventare quorum resource qualsiasi risorsa con le seguenti caratteristiche: deve poter offrire un mezzo di arbitraggio persistente. Questo significa che la quorum resource deve permettere solo ad un singolo nodo per volta di prendere il possesso fisico della stessa e soprattutto di mantenerne il controllo dopo averne preso possesso. deve poter offrire un supporto fisico di immagazzinamento dei dati che possa essere accessibile anche agli altri nodi del cluster. La quorum resource è fondamentale in un cluster perché viene usata per garantire che solo un set di nodi attivi e comunicanti possa operare come un cluster, nella spiacevole situazione in cui i nodi di un sistema siano attivi ma non possano comunicare tra di loro. Per assicurare la membership in un cluster, il Cluster Service si affida ad un frequente scambio di messaggi con i suoi pari presenti nel cluster. Può capitare, però, che si abbia una failure su tutte le reti che collegano i nodi del cluster. Questo evento può andare a provocare la scissione del cluster in due o più set di nodi attivi che possono comunicare tra di loro all interno del set, ma non tra set distinti. A questo punto ogni set potrebbe pensare che tutti i nodi degli altri set siano caduti e quindi tentare di prendere possesso delle loro risorse. Questa situazione di stallo viene risolta con l uso della quorum resource: grazie al fatto che questa possa essere posseduta da un solo e unico nodo, colui che riesce a prenderne possesso sarà l unico a cui sarà permesso di continuare ad operare. La quorum resource, inoltre, ha accesso alla più recente versione del cluster database e dei dati essenziali per un eventuale recovery del sistema; quando un nodo del cluster fallisce, infatti, i cambiamenti che si hanno nel database del sistema vengono scritti nella quorum resource. Tanto per sottolineare ulteriormente l importanza della quorum resource si pensi che se questa si rompe oppure va in failure non può nemmeno partire il Cluster Service! Anche se si è detto che qualsiasi risorsa(che abbia le caratteristiche sopra descritte) può diventare quorum resource, in generale il Cluster Server definisce il Physical Disk come unico tipo di risorsa

14 Il Resource Monitor comunica con il Cluster Service e con le rispettive risorse tramite RPC; queste remote procedure calls inoltrate dal Resource Monitor in realtà sono delle chiamate a delle entry point function contenute all interno delle DLL responsabili per la risorsa. Tutte queste funzioni fanno parte del Resource API. Il Resource API è un contenitore di funzioni, strutture e macro che permettono al Cluster Service di comunicare con le risorse. E necessario che la maggior parte delle entry point function venga definita per ogni tipo di risorsa, ma alcune sono opzionali, a seconda delle funzionalità che deve svolgere la risorsa in questione. Ad esempio la funzione Arbitrate e la Release sono entry point function che vanno implementate solo per quelle risorse che possono essere usate come quorum resource, e non devono essere assolutamente definite per quelle che non possono comportarsi come tali. Citiamo qui di seguito alcune entry point function più importanti: o Arbitrate: permette ad un nodo di partecipare all arbitraggio per riottenere il possesso della quorum resource. o Close: chiude una risorsa. o IsAlive: decide se una risorsa è disponibile ad essere usata. o LooksAlive: decide se una risorsa sembra che sia disponibile all uso. o Offline: bolla una resource come non utilizzabile solo dopo che il processo di cleanup è stato completato. o Online: bolla una risorsa come pronta all uso. o Release: rilascia una quorum resource dalla situazione di arbitraggio. o Terminate: Bolla una risorsa come non utilizzabile senza aspettare che il processo di cleanup sia terminato. o Startup: carica una resource DLL e ritorna una struttura contenente una function table dove sono contenuti tutti i puntatori a tutte le entry point function definite per quella determinata risorsa. La function di Startup è l unica che viene esportata ; tutte le altre funzioni sono accessibili grazie ai puntatori contenuti nella tabella che questa restituisce al Resource Monitor. Oltre alle entry point function appartengono al Resource API anche le funzioni di callback. Queste funzioni sono molto meno numerose delle entry point ma sono altrettanto importanti in quanto permettono ad una DLL di notificare al Resource Monitor il loro stato e qualsiasi log event si verifichi nella risorsa. RESOURCE TYPES: le risorse di un cluster sono organizzate per tipo e sono caratterizzati da un particolare set di codici di controllo; ognuno di questi codici descrive operazioni che tutte le risorse possono svolgere. Il Cluster Server definisce diversi tipi di risorse e fornisce le appropriate resource DLL per gestire questi tipi; citiamo qui di seguito le più importanti: Generic Application: usata solitamente per la gestione delle applicazioni cluster-unaware. Generalmente se si verifica una failure in questo tipo di risorsa, non si prendono troppe precauzioni e si setta a offline lo stato della risorsa terminando il processo che ha causato la failure. Generic Service: questo tipo di risorsa va solitamente ad amministrare Microsoft Windows NT services come se fossero cluster resources. E simile al Generic Application type, ma a differenza di questo, il Generic Service type fornisce solo le funzionalità di base. Physical Disk: questo tipo identifica un disco condiviso connesso a due o più nodi all interno del cluster e sono gli unici tipi di risorse definite dal Cluster Service che possono diventare quorum resource. IP Address: viene usato esclusivamente per gestire gli Internet Protocol (IP) network

15 Network Name Resource, il gruppo a cui appartengono potrà essere visto dai clienti del network come un server virtuale. Network Name: questo tipo permette ad una entità che si trova nel network di possedere, in alternativa al nome della macchina in cui si trova, anche un altro nome. Infatti, quando la Network Name Resource si trova in un gruppo con un altra risorsa di tipo IP Address, provvede a dare una identità alternativa al gruppo, permettendo ai clienti di accedervi come se fossero un server virtuale. Time Service: è un tipo di risorsa che assicura che la temporizzazione rimanga sincronizzata attraverso tutti i nodi formanti il cluster ed è un po diversa dagli altri tipi. Generalmente solo un nodo è selezionato automaticamente per ospitare la Time Service resource e in seguito il nodo prescelto viene poi memorizzato nel database del cluster. Ai resource types sono associati anche delle particolari proprietà, definite anche attributi, che per essere facilmente accessibili vengono memorizzate nel cluster database. Esistono due tipi di proprietà: common e private. Quando una proprietà è common, significa che questa esiste per tutte le istanze di quel particolare cluster object per cui è stata definita (per cui una common resource property esiste per tutte le risorse, una common group property esiste per tutti i gruppi e una common node property esiste per tutti i nodi di un server). Per esempio la RestartAction property è una proprietà common perché deve poter essere applicata a tutte le risorse, senza dover considerare il tipo. Le private properties, invece, sono attributi con un campo d azione decisamente più ristretto rispetto a quelle common. Quando un attributo è private, vuol dire che esiste solo per particolari istanze del tipo di oggetto per cui sono state definite. Esse sono gli attributi prevalenti in una risorsa e generalmente ogni tipo diverso di risorsa ne ha il suo set specifico. Ad esempio per una Generic Application resource alcune delle private properties sono la linea di comando per far partire l applicazione e la directory di riferimento; una Physical Disk resource invece ha come private property la signature del disco. L unico tipo di risorsa che non possiede attributi private è la Time Service resource type Sebbene sia sempre possibile e sicuro utilizzare le resource DLLs fornite dal Cluster Server per gestire le varie applicazioni, è comunque consigliabile e utile crearne delle proprie. Andando a implementare delle DLL che vanno a soddisfare le nostre specifiche esigenze di gestione di una particolare applicazione riusciamo, infatti, ad avere un maggior controllo e flessibilità nel modo di operare del nostro cluster server riguardo le applicazioni che ci interessano di più. Agendo in questo modo andiamo a creare quindi quello che viene definito un Custom Resource Type. RESOURCE GROUP: sono fondamentalmente collezioni di cluster resources, tipicamente composti da risorse dipendenti o correlate logicamente fra loro Un resource group può essere posseduto da un solo nodo per volta e tutte le risorse che fanno parte di quel gruppo devono essere presenti sul nodo che attualmente lo possiede. Ad ogni richiesta, infatti, server differenti all interno del cluster non possono usare risorse differenti che appartengono allo stesso resource group.

16 Ad ogni gruppo è associata una politica di controllo dello stesso, valida per tutti i server del sistema, dove viene specificato, ad esempio, su quale server un gruppo preferisce essere, oppure su quale macchina il gruppo deve essere spostato in caso di failure. In caso di failure i gruppi di risorse vengono spostati come se fossero una cosa unica. Ogni risorsa di un gruppo può dipendere da altre risorse all interno del cluster e queste dipendenze indicano quale tra le risorse deve essere attiva e disponibile prima di farne partire un altra. Ad esempio l attivazione dei servizi di una database application può dipendere dalla disponibilità del disco fisico, dall IP address e dal network name; se prima queste risorse non vengono attivate e rese disponibili la database application non potrà partire. Le dipendenze tra risorse diventano di estrema importanza quando ci troviamo in una situazione di failure di un server e le risorse devono essere trasferite: l ordine di trasferimento, infatti, è proprio dettato da queste relazioni di interdipendenza tra le risorse. Come esempio tipico di come risorse dipendenti fra loro vengano unite per formare un gruppo, riportiamo la figura seguente:

17 Nel nodo sulla destra viene evidenziata, infatti, la presenza del Web Server Group che è composto da tre tipi di risorse strettamente legate fra loro quali il Network Name, l IP Address e l IIS Virtual Root da cui dipende in particolare l Internet Information Server. In generale quando un gruppo contiene una IP Address resource e una Network Name resource (assieme anche ad altri tipi di risorse) viene presentato a tutti i clienti della rete sotto un unico nome, diverso da quello della macchina su cui stanno girando. Siccome questo gruppo appare ai clienti come un server individuale, ci si riferisce ad esso chiamandolo virtual server. I clienti non vedono però alcuna differenza tra l accedere a dei servizi e a delle applicazioni che girano su di un server virtuale e l accedere a servizi che invece si trovano su di un server fisico, proprio perché non vi è differenza nella modalità di accesso tra le prime e le seconde. Uno o più server virtuali possono essere contenuti in qualsiasi nodo del cluster e l utente è esentato dal sapere dove questi virtual servers siano ospitati. Le connessioni da parte delle applicazioni dei clienti ad un server virtuale si hanno attraverso l IP address che il Cluster Service rende pubblico come l indirizzo del virtual server. La visione del sistema da parte del cliente è solamente quella di una lista di singoli network name e IP address che vanno ad identificare i nodi del sistema, ma anche tutti i server virtuali, senza però doversi interessare dell effettiva posizione fisica di questi ultimi.

18 VIRTUAL SERVER CLIENT VIEW NODO 1 NODO 2 Virtual Server 1 Virtual Server 2 Virtual Server 3 Virtual Server 4 Internet Information Server MTS Microsoft Exchange SQL Server IP address: Network Name: WHECNod e1 IP address: Network Name: WHECNod e2 IP address: Network Name: WHEC- VS1 IP address: Network Name: WHEC- VS2 IP address: Network Name: WHEC- VS3 IP address: Network Name: WHEC- VS4 In caso di failure di una applicazione o di una macchina, il Cluster Service rimuove tutto il server virtuale su di un altro nodo del cluster; in questo caso il cliente tenterà nuovamente di riconnettersi al sistema, operando esattamente come aveva fatto per la prima connessione. Ciò, però, non recherà alcun problema perché il Cluster Service trasporterà sul nuovo nodo lo stesso IP address del server virtuale che aveva reso pubblico in precedenza. Il cliente quindi potrà ristabilire la connessione con il server virtuale, senza avere però la necessità di sapere che l applicazione ora sta fisicamente girando su di un altro nodo del sistema. In conclusione possiamo dire, quindi, che un cliente che si trova ad usufruire di un network (composto sia da non-clustered server, sia da clustered-nodes) andrà a sfruttare i servizi offerti dal sistema clusterizzato (e anche di quelli forniti dai singoli server), ma piuttosto che connettersi direttamente ai nodi del cluster, l utente andrà a collegarsi con i server virtuali contenuti al suo interno che forniscono i servizi necessari. CLUSTER ADMINISTRATOR: in un ordinario server environment, avremmo dovuto utilizzare vari tool di amministrazione per identificare i server della rete e per monitorare le loro attività e i loro dati; nel caso di un cluster environment, invece, l amministrazione delle applicazioni e dei servizi è centralizzata grazie all uso di un unico tool grafico che è proprio il Cluster Admninistrator. Le funzioni offerte da questo componente agli amministratori di sistema sono molteplici e spaziano dal poter configurare le caratteristiche dei vari gruppi di risorse al definire le diverse politiche di failover e failback, dal monitoraggio delle attività del cluster alla manutenzione dello stesso.