Real Application Cluster. Real fun.

Oracle 10gR2 - SuSE SLES10 - VMware server 1.0.0

di Rodolfo Baselli
luglio 2006

Attenzione: questo articolo è stato scritto cercando di riproporre fedelmente le procedure di installazione ed è il frutto di molte ore di lavoro fatte esclusivamente per passione personale. È possibile che siano presenti errori od omissioni, che vi invito a segnalare all'indirizzo di posta che potete trovare sulla mia homepage.

Ultima modifica: 31-7-2006


Questo articolo illustra l'installazione di Oracle 10gR2 RAC su SuSE Linux Enterprise Server 10 (SLES10), utilizzando il software di virtualizzazione VMware.
RAC è l'acronimo di Real Application Clusters; si tratta in sostanza di una serie di istanze che lavorano su un database comune, che consentono il bilanciamento del carico di lavoro su n server, garantendo anche una maggiore disponibilità del servizio.
Il database viene condiviso idealmente attraverso dischi comuni; la configurazione più semplice che mi viene in mente è quella di due server con il canale SCSI collegato a una enclosure di dischi avente due canali che espongono le stesse unità fisiche o logiche, gestite attraverso il firmware del controller interno.
Nel caso di Oracle 10gR2, è possibile utilizzare anche soluzioni come ASM, OCFS2 e NFS. ASM (Automatic Storage Management) è praticamente un'istanza Oracle priva di datafile propri completamente dedicata all'immagazzinamento di dati e alla gestione dei dischi fisici; permette infatti striping e mirroring a livello anche di datafile, e viene vista dall'istanza di database come un filesystem. OFCS2 (Oracle Cluster FileSystem versione 2) è un filesystem distribuito, derivato principalmente da ext3, rilasciato da Oracle alla comunità open-source, ora ufficialmente incluso nel kernel Linux da una una delle ultime versioni 2.6; permette sostanzialmente di montare un volume all'interno di tutte le proprie istanze coinvolte nel cluster in modo che le modifiche al filesystem siano sincrone rispetto a ciò che vedono i kernel delle varie macchine coinvolte; in più c'è una sovrastruttura che permette alle istanze di dialogare tra loro e sincronizzarsi attraverso collegamenti di rete veloci e dedicati.
NFS è il classico filesystem di rete Unix, di cui alcune versioni vengono dichiarate compatibili con RAC; permette la semplice condivisione dei volumi attraverso storage NAS; penso che ovviamente sia la soluzione più lenta di tutte.

Inizialmente avevo intenzione di provare l'installazione su Ubuntu Linux "Dapper Drake" 6.06 LTS, ma i moduli del suo kernel, benché molto aggiornati, si riferivano ancora alla vecchia versione di OCFS2, che non permetteva la condivisione dei datafile.
In questi giorni (luglio 2006) è uscita la nuova SLES10, uno dei migliori sistemi operativi di classe enterprise di sempre, come può confermare chiunque abbia provato la magnifica versione 9, già molto avanzata anche ai tempi della sua pubblicazione.

Prima di procedere all'installazione vediamo l'occorrente:

Il software Oracle si scarica da http://www.oracle.com/technology/software/products/database/oracle10g/index.html fornendo la propria login gratuita di OTN.

Configurazione di VMWare

Scaricate VMware Server free edition per il vostro sistema operativo. Io come sistema di base ho usato (abbastanza a caso) SLES9, ma per chi ha un PC o un server con Windows le cose dovrebbero essere praticamente uguali.
Dopo l'installazione di VMware, bisogna creare due server virtuali (nelle figure si possono vedere le varie fasi).
Scegliete Linux/SLES come sistema operativo ospite:


Scegliete la collocazione sul filesystem dei file del server virtuale:


Nota: volendo la procedura di creazione dei server virtuali si può eseguire su un solo server, per poi clonarlo alla fine grazie alla omonima opzione di VMware. Io preferisco invece fare tutto a mano, sia per esercizio che per simulare la situazione reale.

VMware deve rendere disponibili due reti virtuali (da me vmnet1 e vmnet8), una a ponte (bridged) con l'interfaccia di rete del server ospitante, l'altra host-only; in pratica immaginatevi che la prima sia un hub di rete collegato direttamente all'interfaccia di rete reale del vostro server ospitante e quindi anche alla rete locale, l'altra un altro hub di rete isolato. Collegando un'interfaccia di rete virtuale al ponte vi troverete direttamente sulla vostra rete locale, con la possibilità quindi di usufruire di servizi locali come DHCP; collegandovi alla rete host-only vi troverete su un hub isolato sul quale dovrete configurare una rete privata, quella che servirà per la comunicazione veloce tra i membri del cluster:



La seconda particolarità dell'installazione RAC è la presenza di un disco condiviso; per questo articolo utilizzeremo OCFS2, che è un filesystem, quindi in ultima analisi avremo datafile su filesystem, come da tradizione.
In totale ogni server virtuale deve avere due hard-disk, due interfacce di rete, un lettore CD; si può rimuovere tranquillamente il floppy.
Procediamo quindi a creare un disco condiviso.


Clicchiamo su "Add" nella finestra delle impostazioni della prima macchina virtuale (slesrac1), selezioniamo "Hard Disk", scegliendo "Create a new virtual disk", SCSI, di 8 GB; si può tranquillamente evitare di allocare subito lo spazio su disco, a meno che non ne abbiate in abbondanza; allocandolo subito eviterete di avere un disco virtuale frammentato, ammesso che i file creati su filesystem reale non lo siano già per conto loro. Consiglio di creare il disco in una directory separata dalle directory delle macchine virtuali.
Ora, il nuovo disco creato è di un tipo particolare: per prima cosa deve essere condiviso tra più server, e poi non deve essere bloccato dalla prima macchina virtuale che facciamo partire: VMware infatti usa la tecnica del file di lock per determinare se un disco è già stato usato da una macchina virtuale per impedirne l'accesso ad altre VM sullo stesso server.
VMware consiglia di mettere i dischi condivisi su un bus SCSI virtuale separato, come se fosse un controller SCSI a sé stante. Torniamo quindi alla finestra delle proprietà del primo server. Selezioniamo il disco appena aggiunto e clicchiamo su "Advanced". In questa schermata possiamo selezionare il "Virtual Device Node" appropriato, per noi SCSI 1:0 (il primo device SCSI del secondo BUS). Facciamo la stessa procedura per il secondo server virtuale, senza ovviamente ricreare il disco, ma selezionandolo come esistente:




Per dire a VMware che il disco è condiviso abbiamo due possibilità: o dichiarare qual è il disco condiviso con
scsi1:0.shared = "true"
oppure che l'intero bus SCSI 1 è composto da dischi condivisi con
scsi1.sharedBus = "virtual"
In più dobbiamo fare in modo che i dischi non vengano bloccati:
disk.locking = "FALSE"
Queste direttive devono essere immesse nei file di configurazione di tutte le macchine virtuali (file .vmx) a server virtuale spento, una volta finita la configurazione via interfaccia grafica.

Installazione di SLES10

Scaricate SLES10 dal sito della Novell, preferibilmente in DVD. Se avete abbastanza spazio sul vostro server VMware, copiate l'immagine ISO da qualche parte. Per fare partire le macchine virtuali facendo il boot del DVD non è necessario produrre un DVD reale, basta cliccare sulle proprietà delle unità CDROM dei server e inserire il full-path della vostra immagine ISO in "Use ISO image:":


A questo punto basta avviare i server con "Power on" e l'installazione parte.

Nota: se non avete abbastanza spazio per il DVD SLES10, oppure se il vostro filesystem non supporta file più grandi di 2 GB, dovete produrre un DVD, oppure copiare il DVD su una macchina (Linux) con filesystem idoneo (tipo ext3), montare l'immagine iso con
mount -o ro,loop -t iso9660 <immagine iso> <mount-point>
e fare in modo che il mount-point sia accessibile via FTP, HTTP o NFS ecc. (vedi menù di avvio della SuSE e le prime impostazioni del programma di setup). L'ultima opzione è crearsi tutti i CD per inserirli, come il DVD, nel drive reale.
Nota: di default WMware fa partire il primo hard-disk disponibile; nel caso di macchine nuove, il disco è vuoto, quindi le macchine partono dall'unità CD. Nel caso aveste necessità di cambiare queste opzioni, basta premere F2 durante la schermata di avvio del server col logo VMware: vi si presenterà un BIOS identico a quello di una macchina reale!

Fate il boot della SLES10 scegliendo "Installation". Alla fine della fase di avvio parte Yast. Da parte mia posso solo segnalare che, nel caso di questa installazione di natura didattica, ho lasciato al programma di installazione la decisione sul partizionamento dell'hard-disk, cosa che non faccio mai perché esigo il controllo completo delle partizioni; mi sono limitato a scegliere ext3 come filesystem per /, invece del default ReiserFS, che non mi sta simpatico per partizioni di sistema. Bisogna dedicare un po' più di attenzione allo swap, che deve rimanere comunque attorno al gigabyte, perché potrebbe dare problemi durante l'installazione del database.


Nella scelta dei profili di software invece ho eliminato praticamente tutto, selezionando "Oracle server base". Da anni ormai la SuSE dà la possibilità di installare un rpm proprietario (orarun.rpm) che preimposta le variabili d'ambiente come ORACLE_HOME, gli script di /etc/init.d, i parametri del kernel in /etc/sysctl.conf, gli utenti e i gruppi Oracle; l'opzione "Oracle server base" fa un ottimo lavoro.



Le uniche variazioni possono riguardare ORACLE_SID, da impostare al SID dell'instanza locale, ovvero al nome della singola istanza presente sul server, non a quello dell'istanza RAC; e ORACLE_HOME, il cui nome risulta alla fine poco importante, perché si tratta praticamente solo di una zona di filesystem. Un'altra variabile da impostare è (esempio mia variabile):
CRS_HOME=$ORACLE_BASE/product/10.2/crs
la home di Clusterware, che deve essere obbligatoriamente diversa da $ORACLE_HOME.
Le variabili d'ambiente si trovano, come da sana tradizione SuSE, nei piccoli script della directory /etc/profile.d; la sola presenza di uno script qui ne garantisce l'esecuzione dopo la fase di login interattivo. Modificate il file oracle.sh (se usate bash/ksh) per qualsiasi vostra esigenza.
Non dimenticate "C/C++ compiler and tools", visto che le installazioni Oracle spesso usano gcc e soprattutto il linker dietro le quinte per produrre gli eseguibili finali.
Alla fine otterrete un sistema minimo perfettamente funzionante, base per praticamente qualsiasi attività sistemistica.

Configurazione SLES10

Per prima cosa abilitiamo la shell per l'utente oracle, al massimo la potremo disabilitare successivamente: editiamo come root il file /etc/passwd e alla riga contenente oracle sostituiamo /bin/false con /bin/bash, come per gli altri "umani". Cambiamo poi la password dell'utente con il comando
passwd oracle
I moduli del kernel di OCFS2 sono già presenti nell'installazione di default, ma mancano i tools e la console grafica, che può piacere o meno ma aiuta un po'.
Avviate Yast e andate nella sezione di "Software Management"; cercate (ctrl-s) "ocfs2", vi si presentano ocfs2-tools e ocfs2console, installateli.
Allo stesso modo dovrete installare anche i seguenti pacchetti:

Questi pacchetti implicheranno l'installazione di una dozzina di altri pacchetti di supporto, voi confermate tranquillamente.
Configuriamo ora le schede di rete di tutti i server interessati. Per ogni nodo del cluster saranno presenti 3 interfacce di rete, di cui una virtuale e una privata. La prima interfaccia è quella "regolare" di connessione alla rete locale, quella privata è la rete vmnet8, quella virtuale viene creata successivamente da Oracle Clusterware come alias di eth0 (rete locale).
Facciamo un esempio: la vostra rete locale è 192.168.1.0/24, il vostro server VMware ha gà assegnato l'indirizzo IP 192.168.1.2 con maschera di rete 255.255.255.0; le interfacce di rete dei server VMware su vmnet1 faranno parte della stessa rete, poniamo 192.168.1.10 e 192.168.1.11. Per la rete vmnet8 utilizzeremo un altra serie di indirizzi IP, sempre privati, ad esempio della rete 192.168.10.0/24, come 192.168.10.1 e 192.168.10.2. Nel mio caso ho utilizzato la rete 10.0.0.0/24 perché sicuramente inutilizzata altrove.
Alla fine della configurazione degli indirizzi IP, popoliamo il file /etc/hosts di tutte le macchine virtuali con tutte le coppie nomi-indirizzi IP possibili, in quanto tutte le fasi d'installazione e il funzionamento finale sono basati su nomi. Nel mio caso, più o meno:

192.168.1.2	slesrac1
192.168.1.3	slesrac2
10.0.0.1	slesrac1-priv
10.0.0.2	slesrac1-priv
192.168.1.10	slesrac1-vip
192.168.1.11	slesrac2-vip

Le interfacce di rete -vip non sono ancora raggiungibili, verranno create da Oracle Clusterware come alias di quelle "reali".
Sia Oracle Clusterware che il database utilizzano ssh per propagare la configurazione dal nodo d'installazione a tutti gli altri nodi (e viceversa, presumo) con il metodo di autenticazione a chiave pubblica pre-autorizzata, che consente quindi di non digitare la password durante la connessione. Nel gergo Oracle questa configurazione è detta "user equivalence".
Per fare questo generiamo tutte le chiavi pubbliche e private per l'utente oracle su ogni macchina virtuale. Come utente oracle:
ssh-keygen -t rsa
rispondendo con un invio ad ogni richiesta. Ho scelto l'algoritmo RSA perché più veloce in tutte le occasioni, anche se meno sicuro, ma nel nostro caso le paranoie sulla sicurezza delle connessioni sono proprio fuori luogo: alla fine Oracle sfrutta la comodità di ssh di poter eseguire un comando in remoto senza dover fornire le credenziali di accesso.
Ora bisogna produrre il file ~oracle/.ssh/authorized_keys per ogni macchina, contenente tutte le chiavi pubbliche di tutti gli utenti oracle di tutte le macchine virtuali, copiandovi il contenuto di ogni file ~oracle/.ssh/id_rsa.pub. Fatto questo, basterà accedere almeno una volta da ogni macchina a tutte le altre macchine per aggiornare tutte le liste dei known_hosts:

oracle@slesrac1:~> ssh slesrac1 date
oracle@slesrac1:~> ssh slesrac2 date
oracle@slesrac1:~> ssh slesrac1-priv date
oracle@slesrac1:~> ssh slesrac1-priv date
oracle@slesrac2:~> ssh slesrac1 date
oracle@slesrac2:~> ssh slesrac2 date
oracle@slesrac2:~> ssh slesrac1-priv date
oracle@slesrac2:~> ssh slesrac1-priv date
dove date è un comando qualsiasi, usato per verificare l'output della connessione.
Nota: il file ~oracle/.ssh/authorized_keys deve essere leggibile e scrivibile solo dall'utente oracle, altrimenti ssh non lo considera affidabile:
chmod 600 ~/.ssh/authorized_keys
Sarebbe meglio mantenere sincronizzati gli orologi delle macchine del cluster. Per fare questo editare il file /etc/ntp.conf e inserire il server NTP di riferimento della vostra rete locale (ne avete uno VERO?), es:
server ntp.mycompany.it
(c'è una riga di esempio commentata) e poi basta eseguire:
/etc/init.d/ntp start
poi facciamo in modo che il demone di sincronizzazione degli orologi si avvii automaticamente ad ogni boot del sistema:
insserv /etc/init.d/ntp

Configurazione di OCFS2

Accedete alla prima macchina via ssh come root con l'opzione di X-forwarding:
ssh -X root@slesrac1
Eseguite /etc/init.d/o2cb configure verranno caricati i moduli del kernel per OCFS2:

Configuring the O2CB driver.

This will configure the on-boot properties of the O2CB driver.
The following questions will determine whether the driver is loaded on
boot.  The current values will be shown in brackets ('[]').  Hitting
 without typing an answer will keep that current value.  Ctrl-C
will abort.

Load O2CB driver on boot (y/n) [n]: y
Cluster to start on boot (Enter "none" to clear) [ocfs2]:
Use user-space driven heartbeat? (y/n) [n]:
Writing O2CB configuration: OK
Loading module "configfs": OK
Mounting configfs filesystem at /sys/kernel/config: OK
Loading module "ocfs2_nodemanager": OK
Loading module "ocfs2_dlm": OK
Loading module "ocfs2_dlmfs": OK
Creating directory '/dlm': OK
Mounting ocfs2_dlmfs filesystem at /dlm: OK
Checking cluster configuration : Failed

Il check del cluster fallisce perché la configurazione ancora non esiste.
Eseguite
ocfs2console &
dal menù "Cluster" scegliete "Configure nodes"; inserite un nome simbolico e l'indirizzo IP della rete privata per ciascuna delle due macchine; la rete privata viene dedicata completamente al traffico dati di OCFS2. Nel mondo reale viene realizzata con una connessione di rete dedicata ad alta velocità, minimo 1 Gb. Alla fine cliccate "Apply", e un piccolo ingranaggio comparirà a fianco degli host elencati.
Il file /etc/ocfs2/cluster.conf conterrà qualcosa come:
node:
        ip_port = 7777
        ip_address = 10.0.0.1
        number = 0
        name = slesrac1
        cluster = ocfs2

node:
        ip_port = 7777
        ip_address = 10.0.0.2
        number = 1
        name = slesrac2
        cluster = ocfs2

cluster:
        node_count = 2
        name = ocfs2
A questo punto basta eseguire
/etc/init.d/o2cb stop
/etc/init.d/o2cb start
per vedere se il cluster del filesystem viene portato online, almeno dal punto di vista del server su cui si sta agendo. La sincronizzazione vera e propria avviene quando i vari server montano il filesystem.
Ora bisogna partizionare il disco /dev/sdb con una singola partizione di tipo Linux native:
cfdisk /dev/sdb
Create la partizione 1 e di default funziona tutto.
Formattate il disco condiviso /dev/sdb1 da linea di comando:
mkfs.ocfs2 -b 4K -C 32K -L OCFS2 /dev/sdb1
anche se è possibile farlo da ocfs2console con la possibilità di variare i parametri a piacere:
Montiamo poi il disco sempre a linea di comando:
mount -t ocfs2 -o _netdev,datavolume,nointr /dev/sdb1 /ocfs
La relativa entry in /etc/fstab è necessaria:
/dev/sdb1 /ocfs ocfs2 _netdev,datavolume,nointr 0 0

L'opzione _netdev impone al sistema di montare il volume solo dopo che tutte le interfacce di rete sono state attivate e configurate dal boot; datavolume indica che il filesystem in questione ospiterà anche datafile. È infatti possibile condividere anche $ORACLE_HOME e $CRS_HOME via OCFS2 tra tutti i nodi del cluster, in modo da non dover replicare le installazioni; per questi volumi non è necessaria l'opzione datavolume.
L'operazione di mount attiva l'heartbeat tra i server. Il cluster OCFS2 è attivo a tutti gli effetti.

Installazione di Oracle Clusterware

Fare partire ./runInstaller -ignoreSysPrereqs & dalla directory principale del CD, seguire il wizard. Attenzione che i nomi degli host devono essere conosciuti da tutti i server virtuali interessati, come si vede in figura (relativa all'aggiunta della terza istanza - vedi sotto). Attenzione anche ai file di OCR e voting disk: devono finire sul volume condiviso che abbiamo creato, nel mio caso /ocfs; poco importa il loro nome. Una volta che avrete fornito ad Oracle il fullpath, il sistema stesso controller√† se il disco √® effettivamente condiviso, ovvero se il cluster del filesystem funziona. Se superate questa fase, siete sicuri che tutto è a posto.


Ad un certo punto dell'installazione verrà richiesto di eseguire alcuni script come utente root. Prima di eseguire $ORACLE_HOME/root.sh è necessario modificare il file $ORACLE_HOME/bin/vipca che fa partire il configuratore delle schede di rete virtuali. Purtroppo spesso negli script che avviano i vari programmi scritti in Java c'è un vecchio workaround per un problema di avvio sulle macchine Linux con kernel 2.6, per cui si doveva impostare la variabile d'ambiente
LD_ASSUME_KERNEL=2.4
in modo da far funzionare correttamente il dynamic loader delle librerie. Con la SLES10 questo problema non si verifica più, quindi basterebbe commentare la riga LD_ASSUME_KERNEL, il problema è poi nella virtual machine Java, che in questo caso non è compatibile a livello di kernel: cerca di ottenere la lista delle interfacce di rete ma fallisce. Un ulteriore esempio della portabilità di Java. La soluzione è stata di utilizzare il pacchetto Java versione Sun presente nella SLES10; basta modificare la riga che imposta la variabile base di JREDIR:
JREDIR=/usr/lib/jvm/java-1_4_2-sun-1.4.2.11/jre
e tutto funziona (già qui mi dovete una cena). Quasi tutto, perché sulla seconda macchina vipca evidenzia un piccolo baco con uno strano messaggio di errore; si risolve tutto eseguendo vipca da linea di comando e sostanzialmente confermando quello che viene proposto dall'interfaccia grafica.

Installazione del database:

Anche l'installazione del database parte con ./runInstaller -ignoreSysPrereqs & dalla directory principale del CD; anch'essa può essere fatta dal primo server e contemporaneamente replicata su tutti gli altri server grazie alla user equivalence. L'unico parametro significativamente variabile è la quantità di memoria dedicata a Oracle, impostata a circa il 44% di default. Consiglio di non superare il 50% di RAM dedicata con server a 512 MB, specie se ne si ha poca: è meglio lasciare almeno 256 MB per il sistema operativo.
Per quanto riguarda l'installazione, seguite col buonsenso ciò che viene proposto da OUI, lasciando possibilmente tutte le impostazioni al loro default, tenendo conto che la directory base per i datafile è /ocfs
Attenzione all'ultima schermata, perché dopo gli ultimi avvisi che il database è stato creato con successo, bisogna aspettare che compaia la seguente finestra:



Spegnimento database con srvctl

Per poter usare srvctl per spegnere il database, bisogna commentare la linea
LD_ASSUME_KERNEL=2.4.19
in $ORACLE_HOME/bin/srvctl

oracle@slesrac1:~> srvctl
Usage: srvctl <command> <object> [<options>]
    command: enable|disable|start|stop|relocate|status|add|remove|modify|getenv|setenv|unsetenv|config
    objects: database|instance|service|nodeapps|asm|listener
For detailed help on each command and object and its options use:
    srvctl <command> <object> -h
Con questo strumento è possibile far partire sia il database RAC che le istanze una per una:
oracle@slesrac1:~> srvctl start database -h
Usage: srvctl start database -d <name> [-o <start_options>] [-c <connect_str> | -q]
    -d <name>           Unique name for the database
    -o <start_options>  Options to startup command (e.g. open, mount, or nomount)
    -c <connstr>        Connect string (default: / as sysdba)
    -q                  Query connect string from standard input
    -h                  Print usage
dove -d si riferisce all nome dell'istanza RAC (nel mio caso: hillrac).
È comunque possibile far partire un'instanza alla volta oppure una serie di istanze a piacimento:
oracle@slesrac1:~> srvctl start instance -h
Usage: srvctl start instance -d <name> -i "<inst_name_list>" [-o <start_options>] [-c <connect_str> | -q]
    -d <name>           Unique name for the database
    -i "<inst,...>"     Comma separated instance names
    -o <start_options>  Options to startup command (e.g. open, mount, or nomount)
    -c <connstr>        Connect string (default: / as sysdba)
    -q                  Query connect string from standard input
    -h                  Print usage

dove -i "<inst_name_list>" contiene la lista delle istanze da fare partire separate da una virgola. Non sono sicuro che sia possibile inserire istanze appartenenti a macchine diverse.

Aggiunta di una nuova istanza:

Per simulare un'installazione reale procederemo con l'installazione della SLES10 daccapo, anche se si potrebbe usare l'opzione di cloning di VMware, che però non ci farebbe sperimentare la situazione reale e tutti i suoi problemi.
Alla fine dell'installazione della SuSE, identica alle precedenti, dopo avere aggiunto i nomi degli host a tutti i server, e dopo aver esteso la user equivalence anche alla terza macchina, passiamo alla configurazione di OCFS2.
Dal menù "Cluster" scegliamo "Configure nodes". Troviamo già presenti le prime due macchine del cluster, clicchiamo su "Add" e inseriamo il nome della terza istanza (simbolico) e i dati dell'interfaccia di rete privata, nel mio caso 10.0.0.3.
Scegliamo poi "Propagate configuration" che tramite ssh crea gli stessi file di configurazione /etc/ocfs2/cluster.conf.

Nota: è necessario spegnere tutto e riavviare le varie macchine virtuali, in quanto i miei tentativi di montare il disco condiviso alla fine della configurazione OCFS2 risultavano nell'errore "mount.ocfs2: Transport endpoint is not connected while mounting". Strano, perché il syslog delle due macchine diceva il contrario.
Una volta che il filesystem cluster è montato e funzionante anche sul terzo server, si può passare al cloning di Clusterware. Il manuale Oracle dice che il cloning è la modalità privilegiata di creazione di un nuovo nodo. Io consiglio di effettuare il cloning semiautomatico con OUI sia per Clusterware che per Oracle.



Per clonare un nodo RAC si può partire da un nodo qualsiasi. Io per provare sono partito dal secondo nodo. Andate nella directory $CRS_HOME/bin ed eseguite ./addNode.sh come utente oracle, che non fa altro che richiamare OUI con un menù particolare. Metà dell'installazione è dedicata alla copia via ssh/scp dei file, quindi vi dovrete assicurare che anche per il terzo nodo sia valida la user equivalence: si tratta ancora di aggiornare i file /etc/hosts su tutte le macchine, aggiornare authorized_keys per l'utente oracle su tutte le macchine con la chiave della terza macchina, e fare almeno una volta ssh da e verso la terza macchina.
Un'aspetto molto utile del cloning è che vi ritroverete $ORACLE_HOME e $CRS_HOME uguali a quelle del server da cui siete partiti, quindi già dotate delle patch che avete fatto nel frattempo.



Alla fine del cloning di Clusterware sarete costretti ancora a far partire $CRS_HOME/bin/vipca come utente root per ovviare ancora al baco della installazione originaria.

La seconda parte del cloning riguarda $ORACLE_HOME. Andate nella directory $ORACLE_HOME/oui/bin ed eseguite
./addNode.sh
Il cloning di $ORACLE_HOME ("RAC software" nel manuale) è analogo a quello di Clusterware.

Startup di CRS, Oracle e Enterprise Manager:


Prima di tutto controllate che i servizi CRS siano attivi con "pstree | grep init", che dovrebbe restituirvi qualcosa come:
init.cssd-+-init.cssd---su---sh---ocssd.bin---13*[{ocssd.bin}]
Per far partire Oracle è meglio, secondo me, usare srvctl.
Il listener viene fatto partire in automatico (almeno penso) in quanto nel parameter file è presente la linea
*.remote_listener='LISTENERS_HILLRAC'
corrispondente a un listener configurato in tnsnames.ora.
Per fare partire l'intero cluster si può usare, da qualsiasi server, come utente oracle:
srvctl start database -d <nome database>
dove <nome database> è il nome del cluster, nel mio caso hillrac; ho provato anche a fare partire le singole istanze con
srvctl start instance -d <database>-i <istanze>
dove istanze è una lista di istanze separate da virgola, e RAC funziona, anche facendo partire un'istanza alla volta.
Enterprise Manager alla fine è il programma che occupa più RAM e che secondo me meriterebbe un server tutto suo per la gestione del cluster, con almeno 512 MB di memoria. Oracle lo fa scaricare come prodotto a sé stante ma è fatto da tre CD, contro uno del database (ed EM è presente anche lì!). Quando avrò un po' di tempo cercherò di fare un server con solo EM, probabilmente su Ubuntu che fa più client :-P.
Enterprise Manager ha bisogno della variabile d'ambiente ORACLE_SID impostata al SID locale, nel mio caso hillrac1:
export ORACLE_SID=hillrac1 (se non lo si è già fatto)
Per farlo partire eseguire come utente oracle:
emctl start dbconsole
e attendere un bel po'.

Enterprise Manager su un server dedicato:

In futuro, forse.