Newsgroup: it.comp.retrocomputing
Titolo: [LUNGO] VMS Cluster help

Dopo aver salvato la configurazione attuale ed aver trasferito il VAX-
simh sul fisso, mi sto cimentando nel cluster, partendo dal server.
Parametri inseriti:
1) cluster's group number: 1
2) password
========================================================================
$ @cluster_config_lan
                   Cluster Configuration Procedure
                      Executing on a VAX System
    DECnet Phase IV is installed on this node.
    The LAN, not DECnet, will be used for MOP downline loading.
        To ensure that this procedure is executing with the required
        privileges, invoke it from the system manager's account.
        Enter a "?" for help at any prompt.  If you are familiar with
        the execution of this procedure, you may want to mute extra notes
        and explanations by invoking it with "@CLUSTER_CONFIG_LAN BRIEF".
    This VAX node is not currently a cluster member.
MAIN MENU
   1. ADD SVXVAX to existing cluster, or form a new cluster.
   2. MAKE a directory structure for a new root on a system disk.
   3. DELETE a root from a system disk.
   4. EXIT from this procedure.
Enter choice [1]: 1
Will the LAN be used for cluster communications (Y/N)? y
Enter this cluster's group number: 1
Enter this cluster's password:
Re-enter this cluster's password for verification:
Will SVXVAX be a boot server [Y]? y
    Verifying LAN adapters in LANACP database...
    Updating LANACP LAN server process volatile and permanent databases...
%%%%%%%%%%%  OPCOM   9-OCT-2010 15:10:30.93  %%%%%%%%%%%
Message from user SYSTEM on SVXVAX
LANACP MOP Downline Load Service
Enabled LAN device XQA0 for MOP downline load service in non-exclusive 
mode
  ERROR: Permanent LANCP database did not update for any adapters
%LANCP-E-DEVNFND, Device not found in LAN device database, E
%LANCP-E-CMDERROR, Error executing command
%LANCP-E-DEVNFND, Device not found in LAN device database, F
%LANCP-E-CMDERROR, Error executing command
%LANCP-I-FNFDEV, File not found, LAN$DEVICE_DATABASE
-LANCP-I-CREATDEV, Created LAN$DEVICE_DATABASE file
%LANCP-E-NOSUCHDEV, No such device available, E
-LANCP-E-FERRDEV, Error accessing LAN$DEVICE_DATABASE file
%LANCP-E-CMDERROR, Error executing command
%LANCP-E-DEVNFND, Device not found in LAN device database, F
%LANCP-E-CMDERROR, Error executing command
%LANCP-E-DEVNFND, Device not found in LAN device database, X
%LANCP-E-CMDERROR, Error executing command
    Searched the LAN database for device names beginning with E 
(Ethernet),
    F (FDDI) or X (Ethernet). Updates to LANCP MOP downline load 
information
    failed in the permanent database for all such devices.
    Note: The LANACP LAN server process will be used by SVXVAX for boot
          serving satellites. The following LAN devices have been found:
    Verifying LAN adapters in LANACP database...
    LAN TYPE    ADAPTER NAME    SERVICE STATUS
    ========    ============    ==============
    new adapter         service
CTRL-Z a questo punto :P
==========================================================================
Domanda: ignoro i messaggi d'errore e continuo ?
Eppure LANACP qualcosina la riconosce...
LANCP> sh config
LAN Configuration:
   Device   Medium      Default LAN Address   Version
   ------   ------      -------------------   -------
    XQA0    CSMA/CD      08-00-2B-AA-BB-CC    Not available
LANCP> sh device
Device Listing, volatile database:
   Device
   ------
   XQA0
Ovviamente, aggiungendo altri satelliti (altri simh su altre macchine), 
devo inserire in ogni VAX.INI un diverso mac address (diverso da quello 
delle schede di rete fisicamenti presenti nella LAN casalinga, ma forse 
non necessario)

Ripensandoci ...
Non è per caso necessario che io esegua @CLUSTER_CONFIG_LAN dopo aver 
effettuato un set def SYS$SYSTEM ?
La mia directory "home" si trova su DUA1:, mentre SYS$SYSTEM è su DUA0:
Ovviamente, ho eseguito il tutto come SYSTEM ... (anche se dispongo di un 
utente con /priv=all :D, che mi è servito oggi per ripristinare la 
password di SYSTEM :P )



Ti sei già risposto da solo: se hai eseguito tutto come SYSTEM, ti trovavi
probabilmente nella sua home, cioè in SYS$MANAGER, che è su DUA0: di sicuro.
Comunque il problema direi proprio che non è quello, perché la procedura di
configurazione del cluster dovrebbe essere abbastanza intelligente da non
considerare il default attuale.
Prova a entrare in LANCP e a dare i comandi CONVERT NODE e CONVERT DEVICE.
Dovrebbe crearti i file che prima non trovava. Dopodiché prova di nuovo la
configurazione del cluster e dicci se ora funziona.
Francamente questo errore mi sorprende, ma se non ricordo male tu usi la 7.3
che noi di solito non usiamo (preferiamo la 7.2 perché c'è scritto Digital
invece di Compaq), quindi può darsi che ci sia qualche differenza e che si
tratti di un problema noto che però a noi non è mai capitato di vedere. Può
anche darsi che sia il risultato di qualche patch: mi pare che tu le abbia
installate tutte, quindi non una patch mancante, ma semmai una patch che
richiedeva qualche manovra dopo l'installazione, manovra che per un motivo o
per l'altro non è stata fatta...
Con Google non ho trovato grandi cose, e dando un'occhiata ai nostri nodi
pare che quei file non ci siano, però ho trovato che con CONVERT dovrebbe
crearli, quindi in un modo o nell'altro la cosa si dovrebbe risolvere.
Facci sapere,
G.
P.S. Prova un DIR SYS$SYSTEM:LAN$* prima e dopo i CONVERT...

----- PRIMA -----
$ dir SYS$SYSTEM:LAN$*
Directory SYS$SYSROOT:[SYSEXE]
LAN$DEVICE_DATABASE.DAT;1
Total of 1 file.
$
----- DOPO -----
$ dir SYS$SYSTEM:LAN$*
Directory SYS$SYSROOT:[SYSEXE]
LAN$DEVICE_DATABASE.DAT;2               LAN$DEVICE_DATABASE.DAT;1
------------------
Ma l'errore permane.
Allora ho provato
LANACP> DEFINE DEVICE/ALL/UPDATE/VOLATILE_DATABASE
LANACP> DEFINE DEVICE XQA0 /MOPDLL
LANCP> list device/mopdll
Device Listing, permanent database:
              --- MOP Downline Load Service Characteristics ---
   Device     State   Access Mode      Clients           Data Size
   ------     -----   -----------      -------           ---------
   XQA0      Enabled  NoExclusive  NoKnownClientsOnly     246 bytes
LANCP>
Prima la lista era vuota ...
Al successivo CLUSTER_CONFIG_LAN:
....
    Verifying LAN adapters in LANACP database...
    Updating LANACP LAN server process volatile and permanent databases...
%%%%%%%%%%%  OPCOM   9-OCT-2010 18:10:19.66  %%%%%%%%%%%
Message from user SYSTEM on SVXVAX
LANACP MOP Downline Load Service
Disabled LAN device XQA0 for MOP downline load service
%%%%%%%%%%%  OPCOM   9-OCT-2010 18:10:19.67  %%%%%%%%%%%
Message from user SYSTEM on SVXVAX
LANACP MOP Downline Load Service
Enabled LAN device XQA0 for MOP downline load service in non-exclusive 
mode
    Note: The LANACP LAN server process will be used by SVXVAX for boot
          serving satellites. The following LAN devices have been found:
    Verifying LAN adapters in LANACP database...
    LAN TYPE    ADAPTER NAME    SERVICE STATUS
    ========    ============    ==============
    new adapter         service
-----
Ora, la lista qui sopra deve essere ancora vuota ?
Non mi riporta messaggi d'errore, però...
Le patches le ho installate ed ho seguito la procedura.
La rete funziona perfettamente, ed anche il nameserver.

 %LANCP-E-CMDERROR, Error executing command
Tenta la stessa cosa con X e dà errore anche se da te un device Xxxx esiste,
probabilmente perché la specifica impostazione che controlla non è impostata
neppure per quel tipo di device (visto che è la prima volta che gira):


 Non mi riporta messaggi d'errore, però...
L'hai visto il mio secondo post o Usenet se l'è mangiato?
http://groups.google.it/group/it.comp.retrocomputing/msg/3722df2bdb44871f
Ciao,
G.

Mi sono letto il manuale del 7.3 per la configurazione del cluster, e mi 
sono rimasti dei dubbi circa il voting cluster.
Ho risposto no al quorum disk, e mi ha consigliato di assegnare un valore 
ad EXPECTED_VOTES. Sì, ma dove e come ? Che valore è appropriato, per far 
avviare il cluster anche in presenza del solo server ?
------------------
Does this cluster contain a quorum disk [N]?
  WARNING: SVXVAX will be a voting cluster member. EXPECTED_VOTES for
           this and every other cluster member should be adjusted at
           a convenient time before a reboot. For complete instructions,
           check the section on configuring a cluster in the "OpenVMS
           Cluster Systems" manual.
    Execute AUTOGEN to compute the SYSGEN parameters for your 
configuration
    and reboot SVXVAX with the new parameters. This is necessary before
    SVXVAX can become a cluster member.
-------------------
Ad ogni modo, eseuguito AUTOGEN si è riavviato ed, analizzando 
attentamente i messaggi di startup
%%%%%%%%%%%  OPCOM   9-OCT-2010 23:30:22.89  %%%%%%%%%%%
Message from user SYSTEM on SVXVAX
%LICENSE-E-NOAUTH, DEC VAX-VMS use is not authorized on this node
-LICENSE-F-NOLICENSE, no license is active for this software product
-LICENSE-I-SYSMGR, please see your system manager
%LICENSE-E-NOAUTH, DEC VAX-VMS use is not authorized on this node
-LICENSE-F-NOLICENSE, no license is active for this software product
-LICENSE-I-SYSMGR, please see your system manager
Startup processing continuing...
Devo rimettere la licenza base ?

 Devo rimettere la licenza base ?
Il database delle licenze e' condiviso con gli eventuali satelliti
del cluster ed essendo la licenza legata al singolo nodo lui si
aspetta di sapere di quale nodo e' quella licenza
lic mod/inc=nomedelnodo vax-vms
(modify/include)
E' l'unica licenza (di quelle hobbystiche almeno) che vuole il
nodo specificato, le altre van bene come sono, ovviamente quando
configurerai un satellite dovrai aggiungere una licenza vax-vms
col relativo nome del nodo, una per satellite.
-- 
member of the italian hobbyist DECnet network - 
decnet.ipv7.net
www.unsupported.info
 - 
img.unixantichrist.net



Volevo una conferma d'aver capito bene, cioé che la segnalazione new 
adapter significasse quello che avevo inteso (complicato, eh ?)
Adesso, ora che il cluster è avviato, come ho scritto nell'altro post, 
c'è un segnalazione d'errore sulla licenza vax-vms ...

Al riavvio, ho scoperto che i servizi TCP/IP erano disattivati :(
%TCPIP-E-STARTFAIL, failed to start TCP/IP Services
-TCPIP-E-UNSUPPORTED, SYSGEN parameter INTSTKPAGES is 6; must be at least 
12
e così ...
$ run sys$system:sysgen
SYSGEN> SET INTSTKPAGES 20
SYSGEN> WRITE CURRENT
SYSGEN> EXIT
riavvio, incrociando le dita ...
I servizi sono ora attivi ... in questo momento sono connesso ad athena, 
dal virtual vax :)

E per questa sera, pausa :)
Domani ci preoccupiamo di predisporre un paio di satelliti...
Nel frattempo, non poteva mancare un po' di ascii_art :)
 
http://www.supervinx.com/temp/AsciiArt.png

 avviare il cluster anche in presenza del solo server ?
Se hai letto il manuale avrai capito che il cluster funziona con un sistema
a voti. Tralasciando configurazioni speciali ideate ad hoc, ogni nodo
autonomo ha un voto, ogni nodo non autonomo (un satellite per esempio) zero.
Il sistema a voti serve per coordinare l'accesso alle risorse condivise,
tipicamente ai dischi, e quindi per impedire che un nodo uscito per qualche
problema dal cluster possa avere accesso ai file system e fare disastri.
Caso tipico, vari nodi che condividono i dischi su un bus SCSI: un nodo
perde la comunicazione via rete con gli altri, magari perché s'è guastato
uno switch, ma non quella sul bus dei dischi, se non si fermasse subito, ma
continuasse a scrivere sui dischi condivisi, quasi certamente distruggerebbe
il file system perché non avrebbe coordinamento con gli altri nodi: se un
nodo scrive su un file, mentre un altro nodo quel file lo sposta, chissà
dove vanno a finire i dati e soprattutto i metadati.
Dunque i voti. dato un certo numero di membri votanti nel cluster, finché è
presente la metà più uno dei voti il cluster funziona, appena il numero di
voti scende sotto la soglia (mancanza di quorum) l'accesso alle risorse
condvise viene immediatamente bloccato, c.d. quorum hang. Qualora il quorum
dovesse essere ripristinato, ogni attività riprende dove era stata fermata.
Se il cluster per qualche motivo si dovesse rompere in più parti, la parte
eventualmente maggioritaria continuerebbe a funzionare, le altre parti no.
In caso contrario si avrebbe il famigerato cluster partizionato, che non è
nulla di buono, anzi è da evitare come la peste.
Il quorum viene mantenuto e aggiornato dal cluster in modo dinamico: se
compare un nuovo nodo votante mai visto prima e viene accolto nel cluster,
il quorum viene riveduto al rialzo; se un nodo votante esce dal cluster
avvertendo gli altri della sua uscita, il quorum viene riveduto al ribasso;
se un nodo votante esce senza preavviso, viene attivato un timer (default 20
secondi) allo scadere del quale il nodo uscito viene formalmente espulso dal
cluster, ma il quorum non viene abbassato. Infatti, se molti nodi escono dal
cluster, prima o poi si avrà la mancanza di quorum e quindi quel che rimane
del cluster deve assolutamente fermarsi, anche perché c'è la concreta
possibilità che i nodi usciti dal cluster stiano tentando di formare altrove
un altro cluster e nel momento in cui il quorum viene a mancare nel cluster
originario, potrebbe essere diventato sufficiente altrove.
Se poi il nodo espulso tenta di rientrare nel cluster, riceve un rifiuto al
quale risponde con un fatal bugcheck di tipo CLUEXIT (in pratica un crash
controllato). A causa del bugcheck deve per forza rifare il boot e dopo può
rientrare nel cluster. Tutto questo è necessario perché le strutture logiche
condivise (una su tutte il lock database) vengono ricalcolate e rigenerate
in seguito all'espulsione e quindi quelle del nodo espulso sono ormai
invalide. Il reboot garantisce la ripartenza da una condizione "pulita".
In tutto questo cosa c'entra EXPECTED_VOTES? Si tratta semplicemente di un
meccanismo di sicurezza, in pratica è un quorum stimato che serve per
evitare la formazione di più cluster al posto di uno se contemporaneamente
vengono (ri)attivati o aggiunti molti nodi votanti. È il valore in base al
quale ogni nodo inizializza il proprio quorum prima dell'effettiva completa
attivazione del cluster, quando il quorum diventa condiviso e dinamico. Lo
dice la parola: è il numero di voti attesi in condizioni normali prima di
dichiarare attivo un cluster. Si imposta da SYSGEN come tutti gli altri.
Il quorum disk è semplicemente un disco con un voto tutto suo e serve di
fatto solo nei cluster formati da due nodi votanti. Se il quorum è dato
dalla metà più uno dei voti, in un cluster di due nodi basta che uno dei due
esca in qualche modo dal cluster e si ferma tutto per mancanza di quorum.
Allora interviene il quorum disk che con il suo voto alza di uno il quorum
ed evita il blocco. Solitamente il quorum disk è su un bus condiviso dai due
nodi e si distingue (fra l'altro) per la presenza di uno specifico file
[000000]QUORUM.DAT tramite il quale i due nodi si controllano a vicenda: in
caso di problemi, il nodo che riesce a mantenere il "contatto" con il file
QUORUM.DAT conteggia un voto in più e ottiene il quorum per mantenere in
funzione il cluster. Nei cluster via Ethernet, in cui per forza di cose non
c'è storage fisicamente condiviso, si può anche evitare il quorum disk (che
tanto sarebbe all'interno di uno dei due nodi e non veramente autonomo) e
assegnare a uno dei due nodi due voti invece che uno. In ogni caso si
avrebbe un cluster formato da un nodo master che può proseguire da solo e da
un nodo slave che ha bisogno dell'altro per raggiungere il quorum.
Comunque, cercando quorum o expected votes in comp.os.vms si trova di tutto,
anche disquisizioni molto raffinate su disaster recovery e cluster sparsi.
Ciao,
G.
P.S. Spero di aver scritto tutto giusto... :P

 avviare il cluster anche in presenza del solo server ?
A integrazione dell'altro mio post con varie chiacchiere sul quorum, alla
fine non ho poi risposto esattamente alla tua domanda: il default è 1 e per
te ora va bene. Volendolo modificare si imposta da SYSGEN come il resto.
Il tuo nodo avrà un voto (parametro VOTES) e EXPECTED_VOTES sarà 1, quindi
il cluster si formerà tranquillamente con un solo nodo (dopo aver provato
per alcuni secondi a cercare in rete eventuali altri membri già in cluster
tra loro o con cui formarne uno: "waiting to form or join a VMScluster").
Ciao,
G.

È domenica mattina :)
Lo so che eravate in ansia ;)
--==oOo==--
Compilato e configurato l'ennesimo simh.
Aggiunto un nodo.
Avviato il nodo ed atteso pazientemente che si configurasse per il primo 
avvio ...zzzzzzzzzzzzzzzzzzzzzzz...
Autoreboot...
...zzzzzzzzzzzzzzzz...
Il nodo è attivo, il cluster anche :)
Unico neo: ogni tanto si lamenta per un'eccessiva perdita di pacchetti 
nella rete.
Eppure sono collegate allo stesso switch, fianco a fianco.
Ovviamente, nel mio caso B ESA0 non era adatto, ma *B XQ* :P
eseguito anche li mod/inc=nomenodo vax-vms
Certo, non riscontro i tempi indicati da gerry77 come esempio ... è più 
lento lo startup.
La configurazione è la seguente:
1) Cluster server: PIV HT 3.00GHZ, 2GB RAM, Ubuntu 8.04
2) Nodo satellite: IBM 300GL PII 450MHz, 384KB RAM, Ubuntu 8.10
A parte l'avvio, il resto è veloce.
Nel pomeriggio (o domani), aggiungo un altro paio di nodi ed un paio di 
vax/simh "normali" per provare rete e DECNet.
Ultima domanda: il satellite attualmente è senza dischi. Ne posso 
aggiungere uno, ovviamente, e configurarlo ?

 aggiungere uno, ovviamente, e configurarlo ?
Sì certo, anzi sarebbe preferibile, così puoi fargli fare paging e swapping
localmente invece che via rete. Ufficialmente non c'è modo per spostare i
file di paging e swapping senza rimuovere il satellite (con l'apposita
opzione di CLUSTER_CONFIG) per poi aggiungerlo di nuovo specificando che si
vuole utilizzare il disco locale per quei file, ma ci sono varie discussioni
circa i file 
SATELLITE_PAGE.COM
 e 
SYPAGSWPFILES.COM
, su come modificarli per
fare lo spostamento senza toccare la configurazione del cluster...
Si tratta di una lettura molto interessante, ma forse un po' complicata.
Visto che hai in progetto di aggiungere altri satelliti, il prossimo
potresti farlo con paging e swapping locali, poi potresti confrontare le due
configurazioni e studiare un po' le differenze. :-)
Ciao,
G.

 :P
Non esplicitamente ... hai riportato un esempio di startup con i messaggi 
di VMS, e lì c'è l'ora. È facile risalire all'intervallo fra un messaggio 
e l'altro, e mi sono regolato su quanto attendere. Per esempio, dove 
c'era circa un minuto, la mia configurazione ne impiega più di due... 
poco male :)

 poco male :)
Eh ma quelle tanto per cominciare erano due macchine vere, un MicroVAX
3100/40 (FENNEL) e una VAXstation 3100/10 (GARLIC), ma soprattutto non erano
una satellite dell'altra e il boot dal disco SCSI locale riduce di molto i
tempi rispetto al trasferimento via LAN di tutto il necessario. :)
Per quanto riguarda il discorso del disco locale, qua mi sembra tutto
riassunto in maniera semplice e chiara (vedi il primo post):
http://groups.google.it/group/comp.os.vms/browse_thread/thread/2cae6d450e14cb79/
Ciao,
G.

Dirò una stupidaggine :(
Non ho letto a fondo il capitolo cluster, ero troppo curioso di provare.
Mi sembra di legger fra le righe che un cluster può esser formato da 
macchine autonome, non necessariamente un server e tutti satelliti.
O sbaglio ?

 G.
Sì, sì ... semplice e chiara !
Me lo devo leggere, però attentamente ;)
Data la mia luuuuuuuuuuuuuuuuuuuuunga esperienza di VMS (un mese ?) 
faccio ancora un po' di difficoltà ad inquadrare bene la struttura e la 
posizione dei files/directories di sistema. SYS$ di qua ... SYS$ di là.
Il tempo di digerire ed assimilare il tutto :)

 macchine autonome, non necessariamente un server e tutti satelliti.
Esattamente, anzi, ti dirò di più: originariamente il VAXcluster era senza
satelliti. Quelli sono venuti dopo, con l'introduzione del LAVC (Local Area
VAX/VMS Cluster). Oltretutto, se ci pensi, un unico boot server con tanti
satelliti è tutt'altro che robusto: basta che il server abbia un qualunque
problema e tutti i satelliti gli vanno dietro.
All'inizio (1983) il VAXcluster era formato da un gruppo di VAX e HSC (vedi
dopo) collegati fra loro per mezzo di un doppio bus seriale ad alta velocità
in configurazione a stella chiamato CI (Computer Interconnect). Al centro
della stella c'era il cosiddetto Star Coupler a cui facevano capo i due bus
provenienti da ogni nodo del cluster. A prima vista un centro stella del
genere potrebbe sembrare un punto molto vulnerabile, ma in realtà si tratta
di un componente completamente passivo, senza alcun genere di alimentazione,
formato solo da gruppi di trasformatori a radiofrequenza e comunque tutto
raddoppiato, dato che i bus sono due. Nella remotissima ipotesi che fosse
potuto succedere qualcosa a una delle due metà di uno Star Coupler, ci
sarebbe comunque sempre stata l'altra, completamente separata. Di fatto si
trattava di due stelle sovrapposte e indipendenti.
Gli HSC erano gli Hierarchical Storage Controller a cui erano fisicamente
collegati i dischi, che quindi erano ugualmente raggiungibili da tutti i
nodi del cluster. Di fatto, i VAX che partecipavano in un cluster del genere
solitamente non avevano vero e proprio storage locale, ma accedevano tutti
ai dischi condivisi dagli HSC. Anche qua a prima vista sembra che ci possa
essere una grossa vulnerabilità, data dagli HSC come unico punto attraverso
cui passare per arrivare ai dischi, ma in realtà no, perché si utilizzavano
dischi e nastri con interfaccia proprietaria SDI/STI (Standard Disk/Tape
Interface) collegabili e accessibili contemporaneamente da due HSC. Quindi
anche se un HSC si fosse fermato, i dischi a lui collegati sarebbero
comunque stati raggiungibili attraverso un altro HSC (se presente, ovvio).
Da un punto di vista fisico, un HSC era un PDP-11 con uno specifico sistema
operativo real-time chiamato CRONIC (Colorado Rudimentary Operating Nucleus
(for) Intelligent Controllers) che faceva il boot da nastri TU58 o floppy
nascosti dentro il suo stesso cabinet e aveva un suo terminale console. I
cavi CI erano grossi coassiali con una velocità aggregata di ben 140 Mbit/s.
Tra VAX e HSC lo scambio di dati avveniva (e avviene ancora) per mezzo del
protocollo MSCP (Mass Storage Control Protocol) che astrae completamente la
geometria dei dischi e viene interpretato a destinazione dagli HSC. Nel caso
in cui un nodo abbia anche propri dischi locali da condividere, in VMS c'è
un apposito programma server (MSCP.EXE) che riceve pacchetti MSCP da altri
nodi e li traduce per i driver specifici dei dischi locali, senza che gli
altri nodi debbano preoccuparsi della geometria di un disco sconosciuto.
Poi è arrivato il bus DSSI (Digital Storage Systems Interconnect) che è in
pratica sempre il CI, ma in forma ridotta (e più economica), per piccoli
cluster da massimo tre (?) nodi. La topologia fisica cambia da stella a bus
vero e proprio (da vedere somiglia allo SCSI delle origini) e "spariscono"
gli HSC. In realtà non è proprio vero che spariscono: diciamo che vengono
integrati nell'elettronica di ciascun disco, che alla fine è logicamente
come un HSC con un singolo disco collegato. Una cosa simpatica di questa
soluzione è che si può fare un vero e proprio login interattivo dentro ogni
disco ed effettuare varie operazioni. Rimane comunque la possibilità di
avere storage veramente indipendente e condiviso, mettendo i dischi in una
apposita "torre" DSSI che li alloggia insieme alla relativa alimentazione,
magari anche doppia, il tutto collegato ai nodi con appositi cavi DSSI.
Altrimenti la soluzione più povera era avere i dischi DSSI dentro ai cabinet
delle varie CPU, vincolandoli però all'alimentazione della macchina nella
quale si trovavano, quindi indipendenza logica ma non più fisica.
Da ultimo (1987) è arrivato il cluster via LAN Ethernet, che non richiede
hardware speciale o proprietario di alcun tipo, ma che ha ovviamente le sue
limitazioni, una su tutte la mancanza di storage indipendente. E fu proprio
insieme al LAVC che nacque anche l'idea dei satelliti come nuovo concetto di
computing distribuito, sfruttando tecnologie già presenti e utilizzate per
altri scopi, tipo il protocollo MOP (Maintenance Operations Protocol), una
specie di BOOTP già in uso per fare il downline loading del firmware verso
terminal server, X-terminal, stampanti e tanti altri tipi di device. 
All'atto pratico, uno o più boot server all'interno del cluster attendono le
richieste di boot via MOP da parte dei satelliti, ai quali inviano un
piccolo programma di interfaccia (NISCS_LOAD.EXE) seguito da un pacchetto di
dati di configurazione, grazie ai quali il satellite in fase di avvio riesce
ad aprire un circuito MSCP verso il proprio disco di sistema, indicato nella
configurazione. Lo stesso programma, che è quindi una sorta di mini-client
MSCP, offre in locale tutte le strutture logiche standard fornite di solito
dal boot loader classico (VMB.EXE), di modo che SYSBOOT.EXE possa caricare
il resto del sistema operativo dal disco remoto senza neppure rendersi conto
della situazione particolare in cui si trova. Di fatto è come avere un bus
CI virtuale, emulato su Ethernet, che collega la macchina ai suoi dischi.
Nel frattempo si era evoluta anche la tecnologia SCSI e quindi nacque la
forma di cluster tuttora più utilizzata, cioè storage SCSI su uno o più bus
condivisi dai vari nodi ed Ethernet solo per le comunicazioni di controllo
del cluster, poiché SCSI non prevede il trasporto di quel genere di
informazione (a differenza di DSSI, per esempio). Da lì alla fibra il passo
è stato breve, dato che il funzionamento si può considerare analogo.
L'ultimissima evoluzione (novità degli ultimi sei mesi) è IPCI, ovvero il
clustering su trasporto IP. In sostanza si tratta dell'incapsulamento di
quanto passa su Ethernet dentro pacchetti UDP, in modo da poter formare
cluster coprendo anche le grandissime distanze (un cluster sperimentale HP
aveva dei nodi negli Stati Uniti e degli altri in India) e in quei casi in
cui non sia possibile avere un collegamento Ethernet, diretto o indiretto,
considerando anche il fatto che il protocollo originale non è routabile.
Ho tralasciato alcune cose particolari, tipo FDDI, Memory Channel e ATM
perché meno utilizzate, ma comunque rientrano nelle descrizioni fatte sopra.
È anche possibile avere cluster misti, cioè con più tipi di interconnect,
l'importante è che ogni nodo del cluster possa comunicare direttamente con
ogni altro nodo, senza passare per nodi intermedi. Quindi è possibile ad
esempio avere un cluster CI con dei satelliti Ethernet, basta che tutti i
nodi collegati al CI siano anche collegati al medesimo segmento LAN: i
satelliti dialogheranno fra loro e con i nodi votanti tramite Ethernet,
questi ultimi avendo a disposizione due interconnect bilanceranno il
traffico fra i due scegliendo via via quello con le prestazioni migliori.
Mi sembra di aver scritto (di) tutto, se mi viene in mente qualcos'altro,
vedrò di aggiungere. Per ora da leggere ce n'è. :P
Ciao,
G.