Il sistema operativo Unix Tru64 (alias Digital Unix, alias OSF1) nella versione 4.X supporta una serie di configurazioni ad alta affidabilita'. In tali configurazioni la caduta di un qualsiasi componente Hardware o Software viene gestita dal sistema facendo ripartire i servizi e le applicazioni su un'altra componente o mantenendoli contemporaneamente attivi su piu' sistemi. Sono disponibili due livelli di disponibilita' di servizio. Nella configurazione in ASE (Available Server Environment) i servizi possono migrare tra i diversi membri. Con la configurazione in TruCluster i membri possono condividere (in contemporanea) storage su raw devices. Con la configurazione in TruCluster e' possibile l'installazione di Database o TP monitor distribuiti sui diversi membri del cluster (eg. Oracle Parallel DB).
In questo documento viene brevemente descritta l'architettura
e le caratteristiche relative alla configurazione di un ambiente ASE
disponibile con la versione 4.X di Compaq Tru64.
Dopo una breve introduzione sulle funzionalita' e l'architettura
ASE sono presentati i servizi presenti. Quindi vengono trattati
i passi necessari per una corretta configurazione. Infine
sono riportate le principali opzioni del comando di gestione di ASE asemgr.
Il contenuto di questo documento non e' di semplice lettura per non conosce gli aspetti sistemistici sui sistemi Compaq. Il documento infatti fa riferimento a concetti, ambienti ed acronimi non descritti in modo dettagliato per ragioni di spazio. Per maggiori dettagli e' sicuramente opportuno fare riferimento a documenti maggiormente indroduttivi quali: Compaq Tru64 - Digital Unix, Utilizzo di volume manager su Unix: note pratiche.
Un Available Server Environment (ASE) e' una configurazione multinodo in cui sistemi e storage ad alta disponibilità sono connessi a busses SCSI condivisi.
I nodi della configurazione ASE sono detti "membri o sistemi membro" dell'ASE.
Componenti di sistema, come file systems o volumi, e applicazioni vengono organizzate in entità dette ASE services (servizi ASE) con lo scopo di renderle altamente disponibili, attraverso l'implementazione di meccanismi di rilocazione dei servizi tra i diversi nodi dell'ASE.
AS è un'abbreviazione per il TruCluster Available Server Software, che è il software ASE della Compaq. AS impiega tecnologia ASE.
Il software ASE è installato su ogni membro della collezione e monitorizza la salute dei singoli membri e dello storage condiviso.
In caso di indisponibilità, per una qualsiasi ragione, del sistema su cui stava girando un servizio, il software ASE gestisce la ripartenza del servizio stesso rilocandolo su un qualsiasi altro sistema dell'ASE (chiaramente tra quelli disponibili).
Il fail over è implementato e controllato da particolari scripts, detti action scripts, associati ai singoli servizi.
E' così possibile configurare un'organizzazione altamente integrata di sistemi, servizi e storage devices.
I principali vantaggi della configurazione ASE si possono brevemente enunciare come segue:
L'available server software mette a disposizione l'utility asemgr per configurare membri e servizi ASE.
ASE utilizza suoi demoni e drivers per monitorare le interconnessioni di rete e lo stato dei sistemi, dei dischi e dei busses SCSI condivisi nell'ASE.
Ecco quali sono tali demoni/drivers e quali i loro compiti.
E' il "direttore" (il boss, il capo, ... e' lui che comanda!).
Gira su un solo membro dell'ASE e controlla l'intero ASE,
coordinandone la maggior parte delle attività.
In questo suo compito si avvale della collaborazione di altri ASE daemons locali
ai singoli membri, come l'agent daemon o il Host status monitor daemon.
Gira in locale su ogni membro dell'ASE. Gestisce e controlla le operazioni ASE locali al membro, notificandone l'esito al director daemon. Si occupa eventualmente anche di avviare il director daemon in locale qualora esso termini per esempio per una failure sul sistema su cui stava girando.
Gira in locale su ogni membro dell'ASE, individuando le eventuali failures di sistema o di rete e riportandole ai director e agent daemons.
Si tratta di un device driver, mappato al livello del Kernel del sistema operativo, locale ad ogni membro dell'ASE.
Le interfacce del driver permettono di gestire e verificare lo stato di tutte le componenti dell'ASE che insistono sul bus SCSI come la disponibiltà dei dischi piuttosto che quella dei sistemi stessi.
Eventuali failures identificate dall'AM driver vengono riportate ai daemons agent o HSM.
Traccia tutti i messaggi ASE che sono generati dai membri dell'ASE.
La seguente figura illustra l'architettura di una configurazione ASE costruita su due nodi.
In ASE sono definiti cinque tipi di servizi
Un disk service include (uno o più) file systems, AdvFS filesets o volumi LSM su cui si vuole garantire una alta disponibilità. Disks services possono anche includere un'applicazione disk-based. Un esempio di applicazione che si può usare in un disk service è una applicazione che lavora su database.
Un modo di referenziare il servizio è mappare il nome del disk service con un suo proprio indirizzo Internet, indirizzo a cui il membro che fa girare il servizio deve poter rispondere. Questo rende il servizo indipendente dal membro su cui sta girando. I clients accedono al servizio includendo il nome del servizio e il directory path esportato nel loro file /etc/fstab. Se il servizio si interrompe su un membro, esso viene rilanciato su un altro sistema tra quelli disponibili, e i clients avvertono solo un breve timeout.
Un distributed raw disk (DRD) è un sottosistema del TruCluster Production Server cluster, il cluster della Compaq. Anche se questo documento non tratta di cluster, questo breve accenno ai DRD è opportuno.
Un DRD service permette di avere applicazioni che accedono in parallelo da più membri di un cluster a storage condiviso.
L'utility asemgr permette di creare DRD services in una configurazione ASE all'interno di un cluster.
Un tape service è un servizio che può essere costruito su (uno o più) tape devices, media changer devices o file systems.
Utilizzando un servizio di questo tipo si può per esempio configurare in fail over il server POLICENTER NetWorker, sistema di gestione dei backup, o i servers di altre applicazioni client/server.
Un Network File System (NFS) service include (uno o più) file systems, AdvFS filesets o volumi LSM, da esportare verso dei sistemi client. NFS services possono anche includere applicazioni.
Un modo di referenziare il servizio è mappare il nome del NFS service con un suo proprio indirizzo Internet, indirizzo a cui il membro che fa girare il servizio deve poter rispondere. Questo rende il servizo indipendente dal membro su cui sta girando. I clients accedono al servizio includendo il nome del servizio e il directory path esportato nel loro file /etc/fstab. Se il servizio si interrompe su un membro, esso viene rilanciato su un altro sistema tra quelli disponibili, e i clients avvertono solo un breve timeout.
E' inoltre possibile, referenziando il servizio tramite il nome, effettuare il backup dello storage ad esso associato, utilizzando POLYCENTER NetWorker che tratta il NFS service come un client indipendente e memorizza gli storage indexes sotto il nome del servizio stesso. In questo modo backup e recover dello storage del servizio sono indipendenti dal sistema membro che sta facendo girare il servizio.
I files di configurazione di un NFS service sono il file /etc/exports e il file /etc/fstab.
Gli User-defined service consentono di creare servizi gestiti dal software ASE completamente controllati dall'utente mediante la creazione degli action script. Tali servizi sono tipicamente servizi applicativi che non hanno una relazione diretta con risorse di sistema.
E' opportuno ricordare alcune regole importanti nella preparazione di un servizio che dovrà girare in ambiente ASE.
La rilocazione di un servizio in ASE è gestita attraverso delle regole dette politiche ASP (Automatic Service Placement), che servono a determinare su quale altro membro dell'ASE far girare il servizio che si è reso indisponibile per un fault del sistema su cui era attivo.
Il tipo di politica che verrà implementata è scritta a livello di definizione dei singoli servizi (l'utility asemgr ti chiede di specificare una politica ASP quando la stai utilizzando per aggiungere un servizio).
Poiché la scelta del membro su cui rilocare un servizio non può essere fatta solo in base a regole scritte a priori per un dato servizio, essa dipende infatti fortemente dalla disponibilità reale dei membri dell'ASE in un dato istante, il fattore disponibilità di un membro è l'elemento principale intorno a cui sono stati costruiti i diversi tipi di politiche ASP.
Si può comunque rilocare un servizio anche manualmente utilizzando l'utility asemgr, aggirando in questo caso le regole definite su quel servizio.
Utilizzando sui servizi alcune politiche piuttosto che altre si possono disegnare configurazioni ASE le più diverse che meglio soddisfano le diverse esigenze. Alcuni esempi. Si può disegnare una configurazione ASE di tipo master/standby, dove i servizi girano tutti su un solo membro (master) e l'altro (standby) è usato solo in caso di fail sul primo. All'opposto si può disegnare una configurazione ASE in cui i servizi sono equamente distribuiti tra i membri.
I tipi di politiche ASP implementate in ASE sono tre:
Balanced service distribution
Il membro prescelto dal sw ASE per rilocare un servizio è quello su cui sta girando il minor numero di servizi all'interno di quell'ASE. Questa politica permette di gestire una distribuzione equa dei servizi tra i membri.
Favour members
Al singolo servizio è associata una lista di membri dell'ASE da definire al momento della configurazione del servizio stesso. La scelta del sw ASE del membro su cui rilocare il servizio è fatta in base alla disponibilità del primo membro della lista che trova, percorrendo la lista in modo ordinato a partire dal primo elemento della stessa. Se nessun membro della lista è diponibile, in automatico, il sw passa ad implementare la politica del "Balanced service distribution".
Restrict to favoured members
E' in tutto simile alla politica del "Favour members" tranne nel caso in cui non venga trovato alcun membro disponibile nella lista. In questo caso, infatti, non procede all'implemetazione di altre politiche e così se si vuole effettuare comunque la rilocazione del servizio bisogna procedere manualmente.
Il software TruCluster usa gli action scripts per gestire il fail over dei servizi nell'ASE. Gli action scripts permettono di spezzare una procedura in una serie di passi che verranno eseguiti in ordine sotto il controllo del software TruCluster.
Ci sono cinque tipi di action scripts:
Add action scripts
Contiene tutti i comandi necessari affinchè il sistema sia in grado di far girare il servizio. Per esempio un add action script potrebbe editare un file di sistema.
Utilizzando l'utility asemgr per fare il set up (add) di un servizio, il software TruCluster si occupa di eseguire l'add action script in locale su tutti i membri dell'ASE; il servizio viene in questo modo configurato sull'intero ASE.
Delete action scripts
Contiene tutti i comandi necessari ad annullare le azioni effettuate sul sistema dal set up del servizio stesso. Per esempio nel caso di un add action script che abbia editato un file di sistema per apportarne alcune modifiche, il corrispondente delete action script editerà lo stesso file rimuovendone le modifiche.
Utilizzando l'utility asemgr per cancellare un servizio dall'ASE, il software TruCluster si occupa di eseguire il delete action script in locale su tutti i membri dell'ASE; il servizio viene in questo modo rimosso dall'intero ASE.
Start action scripts
Contiene tutti i comandi necessari ad avviare un servizio su un membro. Per esempio in uno start action script potrebbe esserci il richiamo di unpplicazione. Poichè nell'ASE solo un membro alla volta può far girare un servizio, quando il software TruCluster avvia un servizio su un membro, viene eseguito solo lo start action script locale al membro prescelto.
Stop action scripts
Contiene i comandi necessari ad invertire le azioni effettuate nel corrispondente start action script. Per esempio, se lo start action script richiama un'applicazione lo stop action script includerà un comando per interromperla e così via.
Quando il software TruCluster effettua lo stop di un servizio su un membro, viene eseguito lo stop action script locale a quel membro.
Check action scripts
Controllano lo stato dei servizi, determinando se un dato servizio è running.
Vengono richiamati dagli agent daemons per determinare se i servizi sono running, risultato calcolato in base agli exit status ritornati dai check action scripts stessi.
Il comando asemgr lancia un'utility che permette di amministrare l'ambiente ASE e di configurarne e gestirne i servizi.
Si può utilizzare sia in modalità interattiva che con interfaccia a linea di comando.
Nel primo caso occorre digitare il comando asemgr con nessuna opzione, viene avviata un'utility che mostra menus e punti di attività e ti sollecita per informazioni circa l'attività che vuoi eseguire. Se si vuole invece, per esempio, includere il comando in shell scripts si può utilizzare l'interfaccia a linea di comando. La sintassi è come segue:
/usr/sbin/asemgr [options]
Passiamo ora ad una breve descrizione di cosa si può fare utilizzando alcune delle opzioni del comando:
-d [-h member] | [-v service] | [-l]
Mostra lo stato di tutti o di specifici sistemi membro (-h) e servizi (-v). Inoltre mostra i sistemi membro su cui sta girando il logger daemon (-l).
-d [-C [database]] | [-c service]
Mostra i contenuti del database ASE corrente o specificato (-C [database]) o i contenuti del servizio specificato (-c service).
-m service member
Riloca il servizio specificato sul sistema membro specificato. Quando si riloca un servizio, si ferma il servizio sul sistema su cui sta correntemente girando e si avvia su un altro sistema.
-r service
Riavvia un servizio.
-s service [member]
Avvia il servizio specificato e lo mette on line, rendendolo disponibile ai clients. Quando è specificato il parametro member, il servizio è avviato su quello specifico membro, senza tener conto della corrente politica ASP associata al servizio.
-x service
Ferma il servizio specificato e lo mette off line, rendendolo indisponibile ai clients.
Alcune attività di amministrazione su ASE possono lockare ASE. Se si prova ad eseguire l'utility asemgr e ASE è bloccato, viene visualizzato il messaggio ASE is locked by 'hostname'.
Questo messaggio indica che l'attività non può essere eseguita poiché al momento già il sistema hostname sta utilizzando l'utility asemgr.
Testo: Available Server Environment
Data: 12 Settembre 2000
Versione: 1.1.3
Autore: Cristina Vescovo
Correttore di bozze: Meo Bogliolo