RAID1 con Chiron FS

Chiron FS è un filesystem basato su FUSE che implementa repliche RAID1 a livello di filesystem.
Il filesystem replicato può essere di qualsiasi tipo che si desidera, l'unico requisito è che sia montato. Non sono necessari files di configurazione speciali, perchè l'installazione è semplice come un comando mount (o una riga in fstab).
Ecco una parziale e libera traduzione del manuale d'installazione.
Ricordo che sul sito ufficiale è pubblicata tutta la documentazione completa ( http://www.furquim.org/chironfs/howto.html )
IMPORTANTE: Ricordo a tutti che non rispondo di eventuali danni ai vostri apparati quindi chi segue ciò che scrivo lo fa a suo rischio e pericolo!!!!


Capitolo 1. Come installare e testare Chiron FS

a) Ottenere e installare Chiron FS

ChironFS si può scaricare da Google Code. Ci sono alcune scelte:

* Il codice sorgente, sia come archivio compresso che in formato RPM;
* Binario:
a)i386, sia in formato RPM e DEB;
b)64 bit, sia in formato amd64/DEB che x86_64/RPM

Per il tarball, chironfs-current_version.tar.gz, occorre che sul sistema sia installato FUSE sia in versione binaria che di sviluppo.
Se hai una distribuzione recente probabilmente lo hai già installato o è possibile farlo con pochi comandi come apt-get, yum, yast, ecc
Se non è installato puoi scaricarlo dal suo sito.
Scompatta il binario nel path che preferisci ed avrai una directory di nome chironfs-current_version.
Basta entrare nella directory appena creata e compilare con i seguenti comandicomandi:

# cd / path/to/source/chironfs-current_version
# ./configure [usare le opzioni desiderate]
# make
# make install


Per installare il pacchetto sorgente in formato RPM basta eseguire:

rpmbuild -ba chironfs-current_version. src.rpm

e questo compilerà ChironFS generando un chironfs-current_version.rpm
Fatto ciò si può installare chiron con questo comando:

rpm -i chironfs-current_version-your_architecture.rpm

Per i binari in formato RPM, basta lanciare il seguente comando:

rpm -i chironfs-current_version-architecture.rpm

Per i binari in formato DEB basta eseguire:

dpkg -i chironfs_current_version_architecture.deb


b)Testare Chiron FS

Crea 3 directory, una per il filesystem virtuale e due per le repliche e montale tutte con i comandi:

mkdir /virtual /real1 /real2
chironfs /real1=/real2 /virtual

Verifica che siano montate correttamente con il comando:

df

Si dovrebbe vedere una riga come questa:

/real1=/real2 138456396 130613500 809640 100% /virtual

Tenta di creare/modificare/eliminare alcuni file in /virtual e controlla il risultato in /real1 e /real2.
A questo punto abbiamo tutto il necessario per iniziare la replica dei file.
Possiamo smontare il tutto con il comando:

fusermount -u /virtual

Capitolo 2. Utilizzare Chiron FS

Nel test di cui sopra abbiamo appena fatto l'uso più semplice di ChironFS ma non abbiamo usato due opzioni che, pur essendo OPTIONAL, in un ambiente di produzione sono effettivamente essenziali.
In primo luogo, in un ambiente corporate, vogliamo condividere l'accesso a molti utenti.
Ma se FUSE è stato installato con impostazioni predefinite di utente individuale in questo modo solo l'utente che ha montato il sistema virtuale ha la visibilità necessaria mentre gli altri vedono solo il vuoto mount point.
Così per consentire la visibilità anche agli altri utenti dobbiamo utilizzare l'opzione FUSE allow_other.
In secondo luogo vogliamo che ci venga segnalato se qualche replica non riesce.
Il sistema continuerà a funzionare ma non vogliamo scoprire gli errori quando l'ultima replica ha esito negativo ed il sistema si blocca!
Vogliamo venire a conoscenza della replica non funzionante prima!
Abbiamo pertanto bisogno di attivare i log!
Così l'esempio di cui sopra migliora se si cambia il comando mount con questo:

chironfs --fuseoptions allow_other --log /var/log/chironfs.log /real1=/real2 /virtual

Se si desiderano più repliche, 3 per esempio, digitare:

chironfs --fuseoptions allow_other --log /var/log/chironfs.log /real1=/real2=/real3 /virtual

Ora supponiamo in questo esempio che il /real2 sia un filesystem molto più lento di /real1 e /real3.
ChironFS quando deve scrivere i dati deve scriverli in tutte e tre le directory mentre quando si deve leggere sceglierà solo una di esse.
Decidiamo che non vogliamo che ChironFS dia le stesse possibilità di lettura a /real2 rispetto a /real1 e a /real3.
Dato che ChironFS utilizza un algoritmo di round robin se noi non gli specifichiamo che /real2 è lento leggerà da /real2 ad ogni tre letture.
Così, per evitare questo inconveniente, possiamo dare una bassa priorità a /real2 in modo che ChironFS leggerà da quest'ultima solo se /real1 e /real3 saranno in failure. Per fare questo digitiamo i due punti appena prima del path /real2 :

chironfs --fuseoptions allow_other --log /var/log/chironfs.log /real1=:/real2=/real3 /virtual


Capitolo 3. Modificare fstab

Per montare automaticamente al momento del boot la dir virtuale basta aggiungere una riga al file /etc/fstab così come mostrato nell'esempio qui sotto.
La prima colonna deve iniziare con "chironfs #" seguito, senza spazi, con l'elenco delle repliche separate dal simbolo uguale.
La seconda colonna è il punto di mount.
La terza colonna deve essere "fuse".
La quarta colonna indica le opzioni di fuse e chironfs che devono essere separate da due punti.
Le ultime due colonne sono le opzioni di fstab e funziona proprio come si può vedere nella documentazione fstab.

chironfs#/real1=/real2 /virtual fuse allow_other,log=/var/log/chironfs.log 0 0


Capitolo 4. Alcuni esempi

Analizziamo alcuni esempi reali:

a) File e web servers

In questo esempio vedremo 3 diverse soluzioni per la replica dei dati su una rete LAN con 2 server, tipicamente un file server e un server web.

i) Network storage
In questa soluzione avremo bisogno di 2 server in più che ricopriranno il ruolo di 'server dei server', condividendo il loro filesystem utilizzando qualsiasi protocollo come NFS, SSHFS, ecc.
Ai fini del nostro esempio useremo NFS. I 'server dei server'avranno i nomi degli host impostati come nfs1 e nfs2 ed esporteranno la directory /dati.
Il file e web server, avranno i loro nomi di host impostato su fileserver e server web, e saranno, rispettivamente, i 'server degli utenti '.
Creiamo localmente in ciascuno dei server degli utenti le seguenti dir:

mkdir /real1 /real2 /virtuale

Aggiorna i loro /etc/fstabs con l'aggiunta di queste 3 linee:

nfs1: /data /real1 nfs auto 0 0
nfs2: /data /real2 nfs auto 0 0
chironfs#/real1=/real2 /virtual fuse allow_other,log=/var/log/chironfs.log 0 0

Ora è possibile fare il setup del 'server degli utenti'.
Segui le istruzioni specifiche dei servizi che desideri configurare cercando di far sì che il fileserver esporti la directory /virtual agli utenti e mettendo la document root del webserver sotto la directory /virtual.
Per non avere alcun single point of failure è necessario fornire i backup hardware di rete, per esempio 2 schede di rete per ogni server, collegati a switche ridondati.
Infine installa e configura heartbeat nei 'server utenti' per far si che se uno di essi vada in failure sia automaticamente sostituito da uno degli altri.

ii) Local storage
Creiamo il punto di mount locale per tutti i filesystem reale e virtuale in ciascuno dei 'server degli utenti':

mkdir /real1 /real2 /virtuale

Aggiornare il file /etc/fstab sul fileserver con l'aggiunta di queste 2 linee:

webserver:/real1 /real1 nfs auto 0 0
chironfs #/real2 =:/real1 /virtual fuse allow_other,log = /var/log/chironfs.log 0 0

Aggiornare il file /etc/fstab sul webserver con l'aggiunta di queste 2 linee:

fileserver:/real2 /real2 nfs auto 0 0
chironfs #/real1 =:/real2 /virtual fuse allow_other,log=/var/log/chironfs.log 0 0

Ora è possibile l'installazione di 'server degli utenti'.
Seguire le istruzioni specifiche dei servizi che si desidera configurare, cercando di far sì che il fileserver esporti la directory /virtual
agli utenti e mettere la document root del webserver sotto la directory /virtual.
Per evitare single point of failure è necessario fornire i backup hardware di rete, come 2 schede di rete per ogni server, collegati a switches ridondati.
Infine installa heartbeat nei server degli utenti in modo che ' qualsiasi failure di uno di essi sia fronteggiato da uno dei server utenti'.


iii) Local and network storage
Si possono combinare le due soluzioni sopra esposte per una terza soluzione, combinando local e storage network.
Creare il mount point locale per tutti i filesystem reali e virtuali in ciascuno dei 'server degli utenti':

mkdir /real1 /real2 /real3 /virtual

Aggiornare i files /etc/fstabs con l'aggiunta di queste tre linee:

nfs1:/data /real1 nfs auto 0 0
nfs2:/data /real2 nfs auto 0 0
chironfs #/real3 =:/real2 =:/real1 /virtual fuse allow_other,log=/var/log/chironfs.log 0 0


Ora è possibile configurare i 'server degli utenti'.
Seguire le istruzioni specifiche dei servizi che si desidera configurare cercando di far sì che il fileserver esporti la directory /virtual agli utenti e la document root del webserver sotto la directory /virtual.
Per non avere alcun single point of failure è necessario fornire i backup hardware di rete, come 2 schede di rete per ogni server, collegati a switch ridondati.
Infine installare heartbeat nei 'server degli utenti 'in modo tale da far sì che se uno di essi andrà in failure sarà automaticamente sostituito da uno degli altri 'server degli altri utenti'.

b) Desktop con il backup di rete
Se si dispone di un desktop Linux si consiglia di avere un backup dei file locali su alcuni server di rete.
Questa soluzione si applica a fare il backup istantaneo dei tuoi files sulla rete.
ATTENZIONE!!!!!
QUESTO NON SOSTITUISCE UNA QUALSIASI SOLUZIONE DI REALE BACKUP PERCHE' QUALSIASI CAMBIAMENTO O MODIFICA AI FILES (aggiornamento o cancellazione) SARA' REPLICATA VIA RETE, QUINDI CONTINUA A CREARE IL TUO BACKUP REGOLARMENTE!
QUESTA SOLUZIONE SERVE SOLO A NON PERDERE IL TUO RECENTE LAVORO CHE NON PUO' TROVARSI NEL BACKUP PERCHE' LA PROCEDURA NON È ANCORA GIRATA!
Creare i punti di mount locali per tutti i filesystem reali e virtuali in ciascuno dei 'server degli utenti':

mkdir /real1 /real2 /virtual

Aggiorna il tuo fstab con l'aggiunta di queste 2 linee:

nfs1:/data /real1 nfs auto 0 0
chironfs#:/real1=/real2 /virtual fuse allow_other,log=/var/log/chironfs.log 0 0


Capitolo 5. Replica Failures
Ogni volta che qualcuna delle tue repliche non va a buon fine chironfs tenta di tenere i tuoi sistemi in esecuzione.
Se il failure si verifica nel corso di una operazione di lettura chironfs cerca di leggere da qualche altra replica ed in caso di successo ritorna al chiamante senza alcun errore. In questo caso, chironfs registra l'evento se hai operato il mount con la raccomandata opzione di log.
Se il failure si verifica durante un'operazione di scrittura chironfs continua a lavorare cercando di scrivere nelle altre repliche.
Se almeno una delle repliche in scrittura riesce chironfs ritorna al chiamante senza alcun errore.
Ma questa volta chironfs registra l'evento e disattiva le repliche verso il nodo che ha fallito. Ciò significa che nessuna ulteriore lettura
o scrittura sarà effettuata da o verso esso.
A questo punto dovete far sì che il vostro sistema di monitoraggio segnali l'evento.
È possibile utilizzare qualsiasi software, come logwatch, per questo scopo. A partire dalla versione 1.1, ChironFS offre un altro modo per controllare la salute del tuo filesystem. Ora hai la possibilità di montare un proc-like control filesystem utilizzando da riga di comando l'opzione --ctl (or -c ).
Il filesystem di controllo è composto da una directory per ogni replica.
I loro nomi sono il path completo delle repliche con il carattere _ al posto di ogni /.
Ognuno di essi contiene due file: il primo è denominato "status" e contiene un numero "0" per le repliche in buono stato o un numero "2" se la replica è disattivata ed i dati sono incoerenti. Scrivendo "0" o "2" in questo file puoi attivare o disattivare la replica.
Il secondo file, chiamato "check_chironfs.sh" è uno script destinato a funzionare come un plugin nagios.
Se si vuole utilizzare non va copiato in un altro percorso perché i suoi contenuti cambiano in modo dinamico e non funzionerà in un altro percorso.
Quindi ammettiamo che il vostro fstab è qualcosa di simile:

nfs1:/data /real1 nfs auto 0 0
chironfs #:/real1=/real2 /virtual fuse allow_other,log=/var/log/chironfs.log,ctl=/var/run/chironctl 0 0

Se si desidera controllare le repliche con Nagios, basta solo indicare a Nagios di eseguire i seguenti scripts: "/var/run/chironctl/_real1/check_chironfs.sh" e "/ var/run/chironctl/_real2/check_chironfs.sh".
Non è possibile modificare la proprietà o il permesso di bit su uno qualsiasi dei files/directories in questo filesystem.
Configurare chi può accedere e modificare la proprietà di un mount point PRIMA di montarlo.
ChironFS applicherà questa proprietà a tutti i file e le directory sotto di esso.
Dopo aver rilevato il failure devi correggere la causa del fallimento nella replica non server.
DEVI PROVVEDERE TE A RISTABILIRE LA COERENZA DEI DATI SUL SERVER IN FAILURE.
E' consigliabile l'uso di rsync per aggiornare i dati.
QUESTO PASSO DEVE ESSERE FATTO PRIMA DELLA RIATTIVAZIONE DELLA REPLICA ALTRIMENTI SI DANNEGGEREBBERO I DATI IN TUTTIE LE ALTRE REPLICHE.
Per ripristinare l'uso della replica dopo la procedura di recupero di coerenza, supponendo che il tuo fstab sia lo stesso di cui sopra e la replica in failure (e disabilitata) è /real2 utilizzare il file system di controllo per consentirla di nuovo, come di seguito:

echo 0> / var/run/chironctl/_real2/status

Acer Aspire One A150 - Lo schermo non si accende

Ieri l'Aspire One A150 di una mia cara amica ha fatto i capricci.

Al momento dell'accensione infatti lo schermo non si accendeva restando impietosamente nero.

Incaricato di risolvere la questione (ho fatto i salti dalla gioia) all'inizio ho pensato "Ecco ci risiamo con questi netbook da strapazzo..." (confesso che sono stato un pò più pesante nel mio giudizio).

Prima di portarlo in assistenza ho provato a verificare il problema sul sito della Acer scoprendo che quanto occorso non solo è conosciuto ma anche molto ricorrente!

La soluzione comunque è a portata di tutti perchè occorre semplicemente ripristinare il BIOS del nostro Aspire! La procedura di ripristino del bios dell'Acer Aspire One A150 richiede quanto segue:

1) Formattare una chiavetta USB con filesystem FAT

2) Andare sul sito della Acer ( http://support.acer-euro.com/drivers/downloads.html ) e da lì scaricare l’ultima release del bios

3) Scompattare il file zip del bios, spostare il file FLASHIT.EXE ed il file del BIOS 3309.FD nella chiavetta USB. Rinominare il file 3309.FD in ZG5IA32.FD

4) Collegare la chiavetta USB nella porta USB (quella accanto alla ethernet!) dell’Acer Aspire spento, con batteria e alimentatore collegati

5) Tenere premuti i tasti Fn+Esc ed accendere il pc senza lasciare i tasti

6) Rilasciare Fn+Esc dopo pochi secondi dall'accensione: il LED del pulsante d’accensione lampeggerà

7) Premere il pulsante d’accensione UNA SOLA VOLTA: inizierà il processo di aggiornamento del Bios che a me è durato una ventina di secondi circa!

8)Quando il LED del pulsante di accensione smetterà di lampeggiare, l’Acer Aspire One si riavvierà da solo.

Se tutto filerà liscio il nostro Acer Aspire sarà completamente ripristinato e funzionerà perfettamente!

Sia ben chiaro che l'esecuzione di questo how-to è a vostro rischio e pericolo: ciò che ha funzionato con me per altri e svariati motivi potrebbe non funzionare con Voi...Insomma se fate l'aggiornamento del BIOS seguendo in toto quanto ho scritto sopra Vi assumete la piena responsabilità di eventuali ed ulteriori malfunzionamenti.

Bye bye...

Bilanciare il traffico http con Keepalived e Debian Lenny

Keepalived è un framework che serve ad implementare cluster ad alta affidabilità con Linux sfruttando il protocollo VRRP (Virtual Router Redundancy Protocol) che permette a più macchine di condividere un VIP (Virtual IP) per garantire l'altà affidabilità dei servizi.
In questo caso vogliamo usare un bilanciatore keepalived, protetto a monte da un firewall, per bilanciare tra due nostri web server il traffico http proveniente dalla rete pubblica in modo del tutto trasparente per i visitatori.
Installiamo sulla nostra Debian Lenny il software incaricato del bilanciamento, Keepalived, con il seguente comando:

#apt-get install keepalived

Stabilito che il nostro bilanciatore avrà l'IP pubblico 73.XX.XX.XX configurato sull'interfaccia eth0 e l'ip privato 192.168.10.33 sull'interfaccia eth1.
e che i due webserver che formeranno il pool hanno gli ip privati 192.168.10.38 e 192.168.10.39 il nostro file di configurazione /etc/keepalived/keepalived.conf sarà questo (i punti esclamativi introducono una riga di commento):


! da verificare il funzionamento definendo come segue i virtual ip address
!
! le interfacce di rete che uso devo averle già configurate prima:
! su eth1 il gateway per le macchine da bilanciare
! su eth0:x gli ip virtuali per il virtual server
!
! il fowarding deve essere abilitato
!
! echo 1 > /proc/sys/net/ipv4/ip_forward
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
global_defs {

# Invia una mail a ciascuno dei seguenti indirizzi quando una destinazione va in stato down
notification_email {
miouser@miodominio.com
secondomiouser@miodominio.it
}
# L'indirizzo da usare nel campo From: header
notification_email_from usermiobilanciatore@miodominio.com

# Il server SMTP con cui inviare le mail
smtp_server mail.miodominio.com

# Quanto tempo attendere per la risposta del mail server
smtp_connect_timeout 30

# Un nome descrittivo del server keepalived
router_id Bilanciatore1
}

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
vrrp_sync_group VG1 {
group {
VI_1
VI_GATEWAY
}# addresses when a failure occurs
}
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
vrrp_instance VI_1 {
state MASTER
interface eth0

lvs_sync_daemon_inteface eth0

virtual_router_id 51

priority 150

advert_int 1

virtual_ipaddress {
73.XX.XX.XX/27 brd 73.XX.XX.127
}
}
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!# addresses when a failure occurs
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
vrrp_instance VI_GATEWAY {
state MASTER
interface eth1
lvs_sync_daemon_inteface eth1
virtual_router_id 52
priority 150
advert_int 1
virtual_ipaddress {
192.168.10.33/24 brd 192.168.10.255
}
}
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
virtual_server 73.XX.XX.XX 80 {
delay_loop 6
lb_algo rr
lb_kind NAT
nat_mask 255.255.255.0
protocol TCP

real_server 192.168.10.38 80 {
weight 1
TCP_CHECK {
connect_timeout 3
connect_port 80
}
}

real_server 192.168.10.39 80 {
weight 1
TCP_CHECK {
connect_timeout 3
connect_port 80
}
}
}
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Startiamo keepalived:

#/etc/init.d/keepalived start

Se il firewall a monte del bilanciatore è configurato correttamente da questo momento tutto il traffico web diretto alla destinazione 73.XX.XX.XX sarà bilanciato in round robin tra i nostri due server privati.
Se uno dei due server privati non dovesse più rispondere alle chiamate sulla porta 80 keepalived girerà tutto il traffico http verso l'altro nodo privato.
Per eventuali approfondimenti consiglio di fare riferimento al sito ufficiale di keepalived e a questa documentazione:

http://prefetch.net/articles/linuxkeepalivedvrrp.html

http://bollettino.cilea.it/include/getdoc.php?id=259

http://bollettino.cilea.it/include/getdoc.php?id=340

Nic Bonding su Debian Lenny

Come spiega wikipedia il bonding è "...un modulo kernel per linux che permette l'aggregazione di più schede di rete al fine crearne N virtuali (tipicamente chiamate Bond dove N è un numero). Questa nuova interfaccia chiamata channel bonding permette diverse configurazioni tra cui l'aggregazione active-active per aumentare l'ampiezza di banda garantendo la ridondanza oppure l'aggregazione active-standby per la sola ridondanza del servizio.L'utilizzo di questo tipo di architettura permette il collegamento a due tratte diverse di switch distinti per aumentare l'affidabilità del collegamento."
Il modulo kernel di Linux supporta un buon numero di tipi di bonding.
mode= indica la modalità di funzionamento dell'interfaccia virtuale che può essere:

a) 0 = round-robin per il bilanciamento del carico e per il fault tolerance. I pacchetti sono trasmessi alternativamente ed in maniera sequenziale su tutte le interfacce di tipo slave.In altre parole supponendo di avere 3 Slave: eth0, eth1, eth2 che appartengono al Master bond0, il pacchetto numero 1 passa dalla eth0, il 2 dalla eth1, il 3 dalla eth2, il 4 di nuovo dalla eth0 e cosi' via.

b) 1 = active-backup per il fault tolerance. E' attiva solo una slave per volta. La successiva scheda appartenente alla bond0 diventa attiva solo nel caso in cui la slave primaria, attualmenta attiva, perdesse il collegamento. Il MAC address visibile all'esterno e' solo il MAC assegnato alla bond0 (che corrisponde al MAC di una scheda fisica)

c) 2 = active-active XOR (source MAC address XOR'd with destination MAC address) Usando questo metodo l'interfaccia associa l'indirizzo MAC della richiesta in entrata con l'indirizzo MAC per uno dei NIC slave. Una volta fatto ciò tutto il dialogo avviene sullo stesso NIC slave

d) 3 = active-active (Broadcast policy) I pacchetti sono trasmessi su tutte le interfacce di tipo slave aggregate.

e) 4 = IIEEE 802.3ad dynamic link aggregation. Crea gruppi d'aggregazione che condividono la stessa velocità e impostazioni duplex. Trasmette e riceve su tutte le interfacce slave nell'aggregator attivo. Necessita uno switch compatibile con 802.3ad e di un ethtool in grado di stabilire la velocità e le impostazioni per ogni singola scheda salve.

f) 5 = Transmit Load Balancing (TLB). Il traffico in uscita viene distribuito a seconda del carico su ogni interfaccia slave. Il traffico in ingresso viene ricevuto dall'interfaccia slave corrente. Se lo slave ricevente fallisce, un altro al suo posto assume il controllo dell'indirizzo MAC.In questa modalità si ha quindi il load-balancing adattativo (in funzione del traffico) solo in trasmissione.

g) 6 = Adaptive Load Balancing. Bilanciamento del traffico sia in ingresso che in uscita. In ricezione il bilanciamento del carico è garantito da una ARP negotiation. In trasmissione il driver bonding intercetta le risposte ARP inviate dal sistema locale in uscita e sovrascrive l'indirizzo hardware sorgente con l'indirizzo univoco hardware di uno dei membri del bonding in modo tale che diversi peers utilizzino gli indirizzi hardware differenti per il server.In questa modalità si ha quindi il load-balancing adattativo (in funzione del traffico) in entrambe le direzioni.


Configurare l'ethernet bonding su Debian Lenny

In questo esempio creeremo il bonding di due interfacce di rete, eth0 ed eth1.
Installiamo il package ifenslave-2.6 con il seguente comando:

#apt-get install ifenslave-2.6

Assicurariamoci che il modulo kernel sia caricato automaticamente e, quindi, editiamo il file /etc/network/interfaces rendendolo simile a questo:

iface bond0 inet static
address TUOIP
netmask NETMASKTUARETE
network IPRETE
gateway IPGATEWAY
up /sbin/ifenslave bond0 eth0 eth1
down /sbin/ifenslave -d bond0 eth0 eth1

Nello stesso file commenta o elimina le linee che fanno riferimento alle tue reali NICs.

Aggiungi le seguenti linee al tuo /etc/modprobe.d/arch/i386 (ovviamente ricordati di configurare la modalità del bonding di cui necessiti):

alias bond0 bonding
options bonding mode=0 miimon=100 downdelay=200 updelay=200

Riavvia il tuo networking:

#/etc/init.d/networking restart

Installare Oracle Rac 11g su Centos 5.2

SCENARIO:
2 server che montano antrambi 4 interfacce di rete configurate in bonding
1 storage scsi
1 switch Gigabit Atlantis Land

ORACLE SARA' INSTALLATO IN QUESTA MODALITA':
OCR e VOTING DISK su dischi raw devices esterni (su storage scsi, quindi ridondanza esterna)
DATI su disco esterno non formattato gestito da Oracle ASM (su storage scsi, quindi ridondanza esterna)

Software:
Oracle 11g (11.1.0.6) Database & Clusterware Software
OS: Centos 5.2
Ciascuno dei due server monta 2 dischi da 70 Gb in RAID1 hardware così partizionati:
/dev/sda1 19Gb /
/dev/sda2 32Gb /data
/dev/sda3 10Gb swap

INSTALLAZIONE SERVER CENTOS:

Configurazione:

Server 1:
hostname: db1
IP (Public): 192.168.111.21 in channel bonding
IP (Private): 192.168.112.21 in channel bonding

Server 2:
hostname: db2
IP (Public):192.168.111.22 in channel bonding
IP (Private):192.168.112.22 in channel bonding


Pacchetti selezionati in fase di installazione OS:

Desktop Environments
KDE Desktop Environment
Applications
Editors
Graphical Internet
Text-based Internet
Development
Development Libraries
Development Tools
Legacy Software Development
Servers
Server Configuration Tools
Base System
Administration Tools
Base
Java
Legacy Software Support
System Tools
X Window System

I packages sotto riportati ( o le loro successive versioni) sono necessari per l'installazione del cluster Oracle (da installare attraverso il comando yum install NOMEPACKAGE ). Nel nostro caso si installeranno le seguenti versioni packages x86_64:
binutils-2.17.50.0.6-2.el5
compat-libstdc++-33-3.2.3-61
elfutils-libelf-0.97-5
elfutils-libelf-devel-0.125
glibc-2.5-12
glibc-common-2.5-12
glibc-devel-2.5-12
gcc-4.1.1-52
gcc-c++-4.1.1-52
libaio-0.3.106
libaio-devel-0.3.106
libgcc-4.1.1-52
libstdc++-4.1.1
libstdc++-devel-4.1.1-52
make-3.81-1.1
sysstat-7.0.0
unixODBC-2.2.11
unixODBC-devel-2.2.11
sg3_utils

Scaricare inoltre da internet ed installare anche i seguenti pacchetti rpm:

rpmforge-release-0.3.6-1.el5.rf
redhat-release-5Server-5.1.0.2.src.rpm

Interfacce Channel Bonding
Centos permette agli amministratori di unire le interfacce di rete multiple insieme in un singolo canale usando il modulo del kernel bonding e una interfaccia di rete speciale chiamata interfaccia channel bonding. Il channel bonding permette a due o più interfacce di agire come se fossero una unica interfaccia aumentando simultaneamente la larghezza della banda fornendo così ridondanza.
Per creare una interfaccia channel bonding, creare un file nella directory /etc/sysconfig/network-scripts/ chiamato ifcfg-bond, sostituendo con il numero per l'interfaccia, come ad esempio 0.
Il contenuto del file può essere identico a qualsiasi tipo di interfaccia alla quale ci si sta legando come ad esempio una interfaccia Ethernet.
La sola differenza è che la direttiva DEVICE= deve essere bond sostituendo con il numero per l'interfaccia.
Il seguente è un esempio del file di configurazione channel bonding:

DEVICE=bond0
BOOTPROTO=none
ONBOOT=yes
NETWORK=192.168.111.0
NETMASK=255.255.255.0
IPADDR=192.168.111.21
USERCTL=no

Dopo aver creato l'interfaccia channel bonding, le interfacce di rete da unire devono essere configurate aggiungendo le direttive MASTER= e SLAVE= ai loro file di configurazione. I file di configurazione per ogni interfaccia channel bonded, possono essere quasi identici.
Per esempio, se il channel bonding unisce due interfacce Ethernet, eth0 e eth1, i due file delle interfacce potrebbero somigliare al seguente esempio:

DEVICE=eth
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no

In questo esempio, sostituire con il valore numerico per l'interfaccia.
Il modulo del Kernel deve essere caricato per far si che l'interfaccia channel bonding possa essere valida. Per assicurarsi che il modulo sia stato caricato quando si usa l'interfaccia channel bonding aggiungere la seguente riga a /etc/modprobe.conf:

alias bond0 bonding
options bond0 miimon=80 mode=3

L'opzione mode determina la modalità di bonding (in questo caso trasmette in broadcast con tutte le interfacce garantendo la massima fault tolerance).
Per ogni interfaccia channel bonding configurata ci dovrebbe essere una entry di questo genere corrispondente in /etc/modprobe.conf


PREPARAZIONE DEI DISCHI DELLO STORAGE /dev/sdd /dev/sde
/dev/sdd ---------> un'unica partizione /dev/sdd1 da 500 Gb destinata ad accogliere i data files
/dev/sde ---------> due partizioni: a) /dev/sde1 da 500 Mb RAW device per files Oracle Registry
b) /dev/sde2 da 500 Mb RAW device per files Voting Disk
Importante: non formattare nessuna delle tre partizioni create!!!!

Per vedere i dischi /dev/sde1 e /dev/sde2 come raw devices su entrambi i server occorre fare due operazioni:

1)creare il file /etc/sysconfig/rawdevices in cui scrivere quanto segue:

/dev/raw/raw1 /dev/sde1
/dev/raw/raw2 /dev/sde2

2)creare il file /etc/udev/rules.d/60-raw.rules in cui scrivere quanto segue:

ACTION=="add", KERNEL=="sde1", RUN+="/bin/raw /dev/raw/raw1 %N"
ACTION=="add", KERNEL=="sde2", RUN+="/bin/raw /dev/raw/raw2 %N"
ACTION=="add", KERNEL=="raw*", OWNER=="oracle", GROUP=="dba", MODE=="0660"

L'ultima riga è importante perchè i raw devices devono appartenere all'utente oracle.
Una volta fatto tutto ciò fare un riavvio della macchina e verificare che i sistemi vedano i raw devices appartenenti ad oracle.
Il comando per listare i raw devices è: raw -aq
Il comando per verificare i permessi dei raw devices: ls -lash /dev/raw/raw*

Creiamo l'ambiente per Oracle.

1)Creazione di utenti e gruppi
Come utente root eseguire sequenzialmente:

groupadd -g 501 oinstall
groupadd -g 502 dba
useradd -g oinstall -G dba -s /bin/ksh oracle
passwd oracle

2)Configurare kernel parameters e shell limits
Editare il file /etc/sysctl.conf come utente root e verificare l'esistenza ed i valori assegnati ai seguenti parametri(quelli presenti non devono essere inferiori a quelli sotto riportati):

kernel.sem = 250 32000 100 128
kernel.shmmax = 536870912
net.ipv4.ip_local_port_range = 1024 65000
net.core.rmem_default = 4194304
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 262144

Per far avere effetto immediato ai cambiamenti tira il seguente comando: /sbin/sysctl –p

3) File /etc/hosts

a)server db1:
127.0.0.1 localhost.localdomain localhost
::1 localhost6.localdomain6 localhost6

192.168.112.21 db1priv1
192.168.111.31 db1vip
192.168.112.22 db2priv1
192.168.111.32 db2vip
192.168.111.222 db2
192.168.111.221 db1

b)server db2:
127.0.0.1 localhost.localdomain localhost
::1 localhost6.localdomain6 localhost6

192.168.112.21 db1priv1
192.168.111.31 db1vip
192.168.112.22 db2priv1
192.168.111.32 db2vip
192.168.111.222 db2
192.168.111.221 db1

4) Come utente root creare le seguenti dir e darne la ownership all'utente oracle:

mkdir -p /u01/app/crs
mkdir /u01/app/oracle/product/11.1.0/db_1
chown -R oracle:oinstall /u01/app
mkdir /u02/oradata/orcl/arch
chown -R oracle:oinstall /u02

Settare le variabili di ambiente dell'utente oracle:
Editare il file .bash_profile dell'utente oracle aggiungendo quanrto sotto riportato:
(Nota: quando setti le variabili di ambiente Oracle per ogni nodo del cluster assicurati
che ogni nodo abbia un unico Oracle SID!
Nel nostro caso abbiamo usato questi:

db1 : ORACLE_SID=db1
db2 : ORACLE_SID=db2

Loggati con l'utente oracle su ogni nodo ed aggiungi le seguenti variabili al .bash_profile (attenzione che l'ORACLE_SID varia a seconda del nodo db su cui ci troviamo!):

# User specific environment and startup programs
export ORACLE_BASE=/u01/app/oracle
export ORACLE_HOME=$ORACLE_BASE/product/11.1.0/db_1
export ORA_CRS_HOME=/u01/app/crs
export ORACLE_PATH=$ORACLE_BASE/common/oracle/sql:.:$ORACLE_HOME/rdbms/admin
# Each RAC node must have a unique ORACLE_SID. (i.e. db1, db2,...)
export ORACLE_SID=db1
export PATH=.:${JAVA_HOME}/bin:${PATH}:$HOME/bin:$ORACLE_HOME/bin
export PATH=${PATH}:/usr/bin:/bin:/usr/bin/X11:/usr/local/bin
export PATH=${PATH}:$ORACLE_BASE/common/oracle/bin
export ORACLE_TERM=xterm
export TNS_ADMIN=$ORACLE_HOME/network/admin
export ORA_NLS10=$ORACLE_HOME/nls/data
export LD_LIBRARY_PATH=$ORACLE_HOME/lib
export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:$ORACLE_HOME/oracm/lib
export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/lib:/usr/lib:/usr/local/lib
export CLASSPATH=$ORACLE_HOME/JRE
export CLASSPATH=${CLASSPATH}:$ORACLE_HOME/jlib
export CLASSPATH=${CLASSPATH}:$ORACLE_HOME/rdbms/jlib
export CLASSPATH=${CLASSPATH}:$ORACLE_HOME/network/jlib
export THREADS_FLAG=native
export TEMP=/tmp
export TMPDIR=/tmp

Nel nostro esempio ORACLE_SID su db1 è db1, su db2 è db2

Scrivere i shell limits per l'utente Oracle
Come utente root aggiungi le seguenti linee al file /etc/security/limits.conf :

oracle soft nproc 2047
oracle hard nproc 16384
oracle soft nofile 1024
oracle hard nofile 65536

Se non esiste il file creare /etc/pam.d/login ed aggiungere come penultima riga:

session required pam_limits.so

Aggiungere nel file /etc/profile :

if [ $USER = “oracle” ]; then
if [ $SHELL = “/bin/ksh” ]; then
ulimit -p 16384
ulimit -n 65536
else
ulimit -u 16384 -n 65536
fi
umask 022
fi

Creare le dir di destinazione degli archive logs.
Come utente root:
mkdir /data/arch
ln -s /data/arch /u02/oradata/orcl/arch
chown -R oracle:oinstall /data/arch
chown oracle:oinstall /u02/oradata/orcl/arch

Abilitare la SSH User Equivalency
L'Oracle Universal Installer usa comandi ssh e scp durante l'installazione per eseguire comandi remoti e copiare files sugli altri nodi del cluster. Per questo bisogna settare la “user equivalency” per l'utente Oracle su tutti i nodi.
Come utente oracle (nella sua home dir) sul nodo cluster db1 eseguire:

mkdir ~/.ssh
chmod 700 ~/.ssh
/usr/bin/ssh-keygen -t rsa
Nota: Lasciare vuota la passphrase e battere invio.

Come utente oracle sul nodo cluster db2 eseguire:

mkdir ~/.ssh
chmod 700 ~/.ssh
/usr/bin/ssh-keygen -t rsa
Nota: Lasciare vuota la passphrase e battere invio.

Come utente oracle sul nodo cluster db1 eseguire:

cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
ssh db2 "cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys"

Come utente oracle copiare la chiave pubblica generata in db1 su db2 e viceversa
su db1: scp ~/.ssh/id_rsa.pub 192.168.111.22:/home/oracle/.ssh/id_rsa.pub.db1
su db2: scp ~/.ssh/id_rsa.pub 192.168.111.21:/home/oracle/.ssh/id_rsa.pub.db2

Come utente oracle copiare le chiavi pubbliche copiate dentro i file authorized_keys

su db1: cat ~/.ssh/id_rsa.pub.db2 >> ~/.ssh/authorized_keys
su db2: cat ~/.ssh/id_rsa.pub.db1 >> ~/.ssh/authorized_keys

Eseguire i seguenti comandi di verifica su entrambi i nodi come utente Oracle:

ssh db1 date
ssh db2 date
ssh db1priv1 date
ssh db2priv1 date


Installare i packages ASMLib
Scarica dal sito della Oracle il software ASM che include i seguenti packages (noi installiamo a 64 bit):
ASMLib Kernel Driver: oracleasm-2.6.18-53.el5-2.0.4-1.el5.x86_64.rpm
Userspace Library: oracleasmlib-2.0.3-1.el5.x86_64.rpm
Driver Support Files: oracleasm-support-2.0.4-1.el5.x86_64.rpm

Installiamo gli rpm scaricati come utente root con il seguente comando:

rpm -iv oracleasm-2.6.18-53.el5-2.0.4-1.el5.x86_64.rpm
rpm -iv oracleasm-support-2.0.4-1.el5.x86_64.rpm
rpm -iv oracleasmlib-2.0.3-1.el5.x86_64.rpm

Configurare e caricare i packages ASMLib 2.0
Come utente root su entrambi i nodi lancia il seguente comando:

/etc/init.d/oracleasm configure

L'output del comando appena tirato sarà questo:

Configuring the Oracle ASM library driver.
This will configure the on-boot properties of the Oracle ASM library
driver. The following questions will determine whether the driver is
loaded on boot and what permissions it will have. The current values
will be shown in brackets (’[]’). Hitting without typing an
answer will keep that current value. Ctrl-C will abort.
Default user to own the driver interface []: oracle
Default group to own the driver interface []: dba
Start Oracle ASM library driver on boot (y/n) [n]: y
Fix permissions of Oracle ASM disks on boot (y/n) [y]: y
Writing Oracle ASM library driver configuration: [ OK ]
Loading module “oracleasm”: [ OK ]
Mounting ASMlib driver filesystem: [ OK ]
Scanning system for ASM disks: [ OK ]

Creare il disco ASM destinato ad accogliere i dati
Come utente root sul nodo db1 (o su db2, ma NON su entrambi) esegui:

/etc/init.d/oracleasm createdisk DATA /dev/sdd1

L'output di questo comando sarà:

Marking disk /dev/sdd1 as an ASM disk: [ OK ]

Ora verifichiamo il nuovo disco ASM configurato
Come utente root su entrambi i nodi esegui i seguenti comandi:

# /etc/init.d/oracleasm scandisks
# /etc/init.d/oracleasm listdisks

L'output di questi comandi su entrambi i nodi del cluster dovrà essere questo:

[root@db1]# /etc/init.d/oracleasm scandisks
Scanning system for ASM disks: [ OK ]
[root@db2]# /etc/init.d/oracleasm scandisks
Scanning system for ASM disks: [ OK ]
[root@db1]#/etc/init.d/oracleasm listdisks
DATA
[root@db2 etc]#/etc/init.d/oracleasm listdisks
DATA

Fatto questo ora siamo pronti ad installare Oracle Clusterware.


Scaricare il software Oracle RAC 11g
Loggarsi sul nodo db1 sul quale saranno eseguite tutte le installazioni Oracle
attraverso l'utente oracle.
In questo esempio scaricheremo il software Oracle necessario su db1 e lo salveremo
nella dir /home/oracle/install.
Il software da scaricare(VERSIONE x86_64 in questo caso) dal sito www.oracle.com
è il seguente:

Oracle Clusterware 11g Release 1 (11.1.0.6.0)
Oracle Database 11g Release 1 (11.1.0.6.0)

Tutti i download sono disponibili dalla stessa pagina.
Come utente oracle estrai i due pacchetti scaricati nella dir temporanea
/home/oracle/install in questo modo:

cd /home/oracle/orainstall
unzip linux_11gR1_clusterware.zip
unzip linux_11gR1_database.zip


Installare Oracle Clusterware

Verificare il server e abilitare l'accesso al server X
# hostname
db1
xhost +
access control disabled, clients can connect from any host

Loggarsi come utente oracle e settare la variabile DISPLAY (se necessario perchè stai usando un client
remoto per connetterti al nodo per eseguire l'installazione)

DISPLAY=:0.0
export DISPLAY

Ora possiamo lanciare l'installazione del software cluster:

cd /home/oracle/install/clusterware
/home/oracle/orainstall/clusterware/runInstaller

Si apre la GUI di installazione.
Seguire le seguenti voci passo per passo:

Welcome Screen
Cliccare Next
Specify Inventory directory and credentials
Accetta i valori di default:
Inventory directory: /u01/app/oraInventory
Operating System group name: oinstall
Clicca Next per continuare
Specify Home Details (for crs)
Setta il Name e il Path come ORACLE_HOME di crs (la $ORA_CRS_HOME che abbiamo
messo nel .bash_profile) :
Name: OraCrs11g_home
Path: /u01/app/crs
Clicca Next per continuare
Product-Specific Prerequisite Checks
L'installer lancerà una serie di checks per determinare se il nodo soddisfa i
requisiti minimi per l'installazione di Oracle Clusterware Software. Se qualcuno
di questi fallisce devi verificarli manualmente cliccando nel checkbox e ripetendo
il controllo. Nella mia installazione tutti i check sono passati senza problemi.
Clicca Next per continuare.
Specify Cluster Configuration
Cluster Name: db
Public Node - Name Private Node - Name Virtual Host Name
db1 db1priv1 db1vip
db2 db2priv1 db2vip

NB: i private nodes e i vip nodes devono essere inseriti nel file /etc/hosts di
entrambi i servers
Specify Network Interface Usage
Bond0 192.168.111.0 Public
Bond1 192.168.112.0 Private
Specify OCR Location
Scegliere External Redundancy ed indicare la OCR location come /dev/raw/raw1
Specify Voting Disk Location
Scegliere External Redundancy ed indicare la Voting Disk location
come /dev/raw/raw2
Summary
Cliccare Install per iniziare l'installazione!
Execute Configuration scripts
Una volta che l'installazione è completa comparirà una finestra in cui viene richiesta
l'esecuzione di due scripts come utente root su entrambe le macchine. Apri una finestra
terminale ed esegui questi scripts come utente root su ciascun nodo. Scegli OK per
continuare dopo che i due scripts sono stati eseguiti con successo su entrambi i nodi.NON
ESEGUIRE SIMULTANEAMENTE GLI SCRIPTS SU ENTRAMBI I NODI (fai prima un nodo e
poi l'altro!!!!)
Configuration Assistants
Esegue un controllo post installazione. Questo controllo potrebbe generare
errori. Se gli errori sono relativi al sistema operativo (per esempio oracle non riesce
a capire che versione di Red Hat sta usando) si possono tralasciare e dare la spunta di
verificato a mano. Se i problemi sono relativi a librerie mancantri allora vanno
verificati a fondo. Una volta verificato il tutto cliccare su Next.
End of Installation
Cliccare su Exit


Verificare lo stato del Clusterware
Esegui i seguenti comandi come utente root:
/bin/olsnodes -n
db1 1
db2 2

/u01/app/oracle/product/11.1.0/crs/bin/crsctl check crs
Cluster Synchronization Services appears healthy
Cluster Ready Services appears healthy
Event Manager appears healthy

Per avere altre informazioni dettagliate come utente root lanciare il seguente comando:
/u01/app/oracle/product/11.1.0/crs/bin/crs_stat -t -v
Name Type R/RA F/FT Target Status Host
ora.db1.gsd application 0/5 0/0 ONLINE ONLINE db1
ora.db1.ons application 0/3 0/0 ONLINE ONLINE db1
ora.db1.vip application 0/0 0/0 ONLINE ONLINE db1
ora.db2.gsd application 0/5 0/0 ONLINE ONLINE db2
ora.db2.ons application 0/3 0/0 ONLINE ONLINE db2
ora.db2.vip application 0/0 0/0 ONLINE ONLINE db2

Verificare Oracle Clusterware Auto-Start Scripts
$ ls -l /etc/init.d/init.*
-rwxr-xr-x 1 root root 2236 Oct 12 22:08 /etc/init.d/init.crs
-rwxr-xr-x 1 root root 5290 Oct 12 22:08 /etc/init.d/init.crsd
-rwxr-xr-x 1 root root 49416 Oct 12 22:08 /etc/init.d/init.cssd
-rwxr-xr-x 1 root root 3859 Oct 12 22:08 /etc/init.d/init.evmd


Installare il software Oracle Database 11g

Come utente oracle:
$ cd /home/oracle/install/database
$ /home/oracle/orainstall/database/runInstaller


Welcome Screen
Cliccare Next
Select Installation Type
Selezionare Standard Edition
Cliccare Next
Install Location
Lascia sia la default Oracle Base Location (/u01/app/oracle) sia la default
Oracle Home location (/u01/app/oracle/product/11.1.0/db_1).
Next per continuare
Specify Hardware Cluster Installation Mode
Lascia la default ‘Cluster Installation’ e seleziona entrambi i nodi.
Clicca Next per continuare.
Product-Specific Prerequisite Checks
La OUI ora verificherà che l'ambiente soddisfi tutti i requisiti necessari.
Tutti i passaggi pre-requisiti devono essere completati con successo.
Clicca Next per continuare.
Select Configuration Option
Scegli ‘Install Software Only’. Si userà più avanti il tool DBCA
(Database Configuration Assistant) per configurare ASM e creare il database.
Next per continuare.
Privileged Operating System Groups
Lascia le opzioni di defaults(dba, oinstall and oinstall).
Clicca Next per continuare.
Summary
Controlla il riepilogo di installazione e clicca su Install per cominciarla.
Install
Osserva il progresso dell'installazione
Configuration scripts
Una volta che l'installazione è completa comparirà una finestra che richiede
l'esecuzione come utente root di uno script. Apri una finestra di terminale ed eseguilo
su entrambi i nodi. Seleziona Ok per continuare dopo che lo script è stato eseguito
con successo su entrambi i nodi.
End of Installation
Cliccare su Exit


Creare istanze Oracle ASM
Lanciare in esecuzione DBCA (Database Configuration Assistant) per configurare ASM e creare un RAC database.
Apri una finestra terminale come utente oracle.
Dalla dir /u01/app/oracle/product/11.1.0/db_1/bin lancia dbca con il seguente comando:
$ ./dbca


Welcome Screen
Lascia la selezione di default (Oracle RAC database).
Next per continuare.
Operations
Seleziona Configure Automatic Storage Management.
Clicca Next.
Node Selection
Seleziona tutti i nodi.
Clicca Next per continuare
Create ASM Instance
Setta la “SYS password” per l'istanza ASM. Lascia il tipo di “parmeter file”
di default (IFILE) da creare.
Next per continuare.
Database configuration assistant
Scegli Ok per confermare la creazione dell'istanza ASM.
Scegli Yes per permettere a DBCA di creare i listeners di default.
ASM Disk Groups
Scegli “Create New” per creare un nuovo ASM disk groups.
Scrivi DATA come nome del disk group. Setta “Redundancy External” e
seleziona il data disk ORCL:DATA
Clicca Ok per continuare.
Il disk group DATA dovrà ora essere montato.
Seleziona il check box DATA e clicca il tasto Finish.
Database configuration assistant
Scegli Yes per eseguire la creazione del database.
Operations
Seleziona “Create a Database”.
Clicca “Next” per continuare.
Node Selection
Seleziona tutti i nodi e clicca su “Next” per continuare.
Database Templates
Lascia il default setting (General Purpose or Transaction Processing).
Clicca “Next” per continuare.
Database Identification
Inserisci “db” (senza le virgolette) come global database name.Il sid si scriverà in
automatico uguale al global database name.
“Next” per continuare.
Management Options
Lascia i defaults settings (“Configure Enterprise Manager” e “Configure
Database Control for local management” selezionati, ma “Enable Alert Notifications” e
“Enable Daily Disk Backup to Recovery Area” deselezionati).
Clicca su “Next” per continuare.
Database Credentials
Seleziona “Use the same Administrative Password for All Accounts” e
inserisci la password.
Clicca “Next” per continuare.
Storage Options
Seleziona “Automatic Storage Management”.
Clicca “Next” per continuare.
ASM Disk Groups
Seleziona il disk group DATA2 .
Clicca “Next” per continuare.
Database File Locations
Lascia la selezione di default (Use Oracle-Managed Files).
Controlla che +DATA2 compaia come Database Area.
Clicca “Next” per continuare.
Recovery Configuration
Togli la spunta a “Specify Flash Recovery Area”.
Seleziona “Enable archiving” e clicca sul bottone “Edit Archive Mode Parameters”.
Edit Archive Mode Parameters
Modifica l'Archive Log Destination in /u02/oradata/orcl/arch .
Clicca “OK” e poi “Next” per continuare.
Database Content
Non selezionare nulla.
Clicca Next per continuare.
Initialization Parameters
Riduci la ‘Memory Size’ al 25% e seleziona “Use Automatic Memory Management”.
Cliccare sul tab “Character Sets”.
Selezionare questi parametri(si selezioni il tipo di carattere necessario):
SET DEI CARATTERI DEL DB: AL32UTF8
SET DI CARATTERI NAZIONALI: AL16UTF16 - Unicode UTF-16 Universal character set
Lingua predefinita: Americano
Territorio predefinito: Stati Uniti
Lascia tutti gli altri parametri invariati.
Clicca “Next” per continuare.
Security Settings
Lascia la selezione di default.
Clicca “Next” per continuare.
Automatic Maintenance Tasks
Assicurarsi che sia selezionato “Enable automatic maintenance tasks” .
Cliccare “Next” per continuare.
Database Storage
Controlla le opzioni storage per tutti i files.
Clicca “Next” per continuare.
Creation Options
Seleziona “Generate database creation scripts”.
Clicca su ‘Finish’ per rivedere i parametri di installazione.
Summary
Seleziona “Ok” per chiudere la pagina riepilogativa.
Clicca su Finish per cominciare l'installazione.
Database Configuration Assistant
DBCA per prima cosa genererà gli scripts di creazione db che tu hai
selezionato prima. Un messaggio sarà visualizzato una volta che questa operazione
sarà terminata. Visto il messaggio starterà la creazione del db.
Database Configuration Assistant
Una volta che la creazione del db è terminata comparirà una finestra di riepilogo
con le informazioni del db.
Clicca su “Exit” per uscire dall'OUI.


Come utente oracle edita il file /etc/oratab su entrambi i nodi.
Sostituisci il nome del database con il nome dell'istanza per il database Rac
(per esempio sostituisci la parola db con db1 o db2 a seconda del nodo Rac su cui ti trovi).
Inoltre aggiungi i dettagli della tua home clusterware in questo file.
Questo ti permetterà di abilitare di settare la tua home Clusterware usando lo script oraenv.
Una volta editato il file /etc/oratab dovrà contenere quanto segue:
Sul nodo db1:
+ASM1:/u01/app/oracle/products/11.1.0/db_1:N
db1:/u01/app/oracle/products/11.1.0/db_1:N
crs:/u01/app/oracle/products/11.1.0/crs:N
Sul nodo db2:
+ASM2:/u01/app/oracle/products/11.1.0/db_1:N
db2:/u01/app/oracle/products/11.1.0/db_1:N
crs:/u01/app/oracle/products/11.1.0/crs:N


Riavviare entrambi i nodi e verificare che Oracle RAC 11g parta al boot.
La management console non starta al boot.
Per farla partire bisogna lanciare come utente oracle prima su db1 poi su db2
il seguente comando:

$ emctl start dbconsole

Con Oracle RAC11 la dbconsole va startata su tutti i nodi del cluster.
Ripetere lo stesso comando di start della console anche su db2
L'installazione del nostro Rac Oracle è terminata.


APPENDICE

DISINSTALLARE ORACLE RAC 11 g
Nel caso in cui in fase di installazione si commetta qualche errore ci possiamo trovare nelle condizioni di dover reinstallare tutto il software.
A tal fine per disinstallare Oracle Rac 11 g occorre eseguire queste operazioni:
A)come utente oracle lanciare il comando /home/oracle/install/database/runinstaller
e disinstallare il software db
B)come utente oracle lanciare il comando /home/oracle/install/clusterware/runinstaller
e disinstallare il software cluster
La disinstallazione di Oracle non termina qui perchè purtroppo la GUI non ripulisce del
tutto i server.
Bisogna quindi provvedere a mano, come utente root, a rimuovere tutto ciò che segue
su entrambi i nodi del cluster:
1)tutto il contenuto della dir /u01/app ECCETTO la dir asm
2)tutto il contenuto della dir /u02/oradata/orcl/arch
3)la directory /etc/oracle
4)i files /etc/oraInst.loc , /etc/oratab e /etc/inittab.crs
5)i files /usr/local/bin/coraenv , /usr/local/bin/dbhome , /usr/local/bin/oraenv
6)tutto il contenuto della dir /tmp
7)/etc/init.d/init.crs , /etc/init.d/init.crsd , /etc/init.d/init.cssd , /etc/init.d/init.evmd

Inoltre bisogna ripulire i dischi dello storage che sono stati marcati da ASM ed i raw devices.
Nel nostro caso li ripuliamo così:
A)dd if=/dev/zero of=/dev/raw/raw1 bs=1M count=10
B)dd if=/dev/zero of=/dev/raw/raw2 bs=1M count=10
C)dd if=/dev/zero of=/dev/sdd1 bs=1M count=10

Le macchine ora sono ripulite completamente e si può provvedere a reinstallare Oracle in tutta tranquillità.

Usare Openswan per una vpn IPSEC

Openswan è una completa implementazione di IPSEC per i kernel Linux 2.0, 2.2, 2.4 e 2.6.

Su debian openswan è facilmente installabile usando apt.

La vpn che andremo a creare è attestata lato nostro su un firewall linux Debian (hostname: firewall) ed è configurata attraverso un software chiamato openswan. Dall'altra parte del tunnel l'altro peer è un router Cisco 3845.

Il nostro firewall ha due schede di rete: etho (pubblica) ed eth1 (privata)

Prima di iniziare la configurazione dobbiamo sempre stabilire con chi gestisce l'altro peer (sempre che non siamo noi a gestire entrambi!) le caratteristiche del tunnel IPSEC che andremo ad instaurare. Per questo motivo mando sempre una mail al mio dirimpettaio in cui scrivo:

" ...per permettere che la VPN funzioni correttamente sarà necessario che sia basata su un IPSEC vendor free senza features aggiuntive.
Altre caratteristiche:

Autenticazione: preshared key
Cifratura: 3DES
Hash: MD5
Diffie Helmann: Gruppo 2
Perfect Forward Secrecy: Disabilitata
Modalità VPN: tunnel
IKE: Main Mode
NAT-T: No "

I file di configurazione della vpn su cui andremo a lavorare lato nostro sono i seguenti:
/etc/ipsec.conf dove indicheremo l'include del file di configurazione
/etc/ipsec.secrets dove indicheremo la pre shared key per agganciarci al peer remoto
/etc/ipsec.d/CONNESSIONI-ATTIVE/con-nuovotunnel dove scriveremo tutti i parametri della connessione

Per non incorrere in problemi di natting e di criptazione dei dati sul firewall è stata aggiunta appositamente un'ulteriore interfaccia interna, eth1:1, che nel nostro esempio risponderà all'IP 192.168.72.2

Creiamo la directory /etc/ipsec.d/CONNESSIONI-ATTIVE in cui andremo ad inserire i file di configurazione delle vpn che andremo man mano a creare:

firewall#mkdir /etc/ipsec.d/CONNESSIONI-ATTIVE

Dentro la dir appena creata scriveremo il nostro file di configurazione che chiameremo con-nuovaconnessione. Il contenuto del file sarà il seguente:

conn con-nuovaconnessione
type=tunnel #tunnel mode ipsec
left=IPPUBBLICODELNOSTROFIREWALL #the IP address of your OpenSWAN endpoint
leftnexthop=%defaultroute #default gateway
leftsubnet=192.168.72.2/32 # network behind your endpoint
right=IPPUBBLICODELLALTROPEER # Your IP, or %any for a road-warrior setup
rightnexthop=%defaultroute #defaultroute for road warrior unknown
rightsubnet=RETEPRIVATADELLALTROPEER/SUBNETMASK #network behind the PIX
esp=3des-md5 #esp: 3des, hmac: sha1
keyexchange=ike #use regular ike
compress=no #inserita per test
authby=secret #pre-shared secret, you can also use rsa nounces
auto=add #don't initiate tunnel, but allow incoming
pfs=no
spi=0x0 #use base spi of 0x0 for PIX
dpddelay=10
dpdtimeout=120
dpdaction=clear
rekey=yes

Per le singole voci del file di configurazione vi rimando alla vasta documentazione che si trova sul sito di openswan.
Ora andiamo a scrivere la pre shared key concordata dentro il file /etc/ipsec.secrets con questa modalità:

IPPUBBLICOMIOFIREWALL IPPUBBLICOALTROPEER : PSK "presharedconcordata"

Attenzione: la pre shared key deve essere scritta dentro i doppi apici!
Fatto questo ci resta solo da inserire l'include del file di configurazione nel nostro file /etc/ipsec.conf:

include /etc/ipsec.d/CONNESSIONI-ATTIVE/con-nuovaconnessione

In questo momento abbiamo terminato la configurazione di ipsec.
Prima di provare a tirare su la vpn non dobbiamo dimenticarci però due cose:
1)aver creato l'interfaccia interna 192.168.2.72 sul nostro firewall
2)aver inserito le regole iptables per pemettere al nostro firewall di girare correttamente il traffico. Un esempio:
iptables -t nat -A POSTROUTING -s 192.168.72.0/24 --dst RETEPRIVATAALTROPEER/SUBNETMASK -j SNAT --to-source 192.168.72.2

Ora possiamo tirare su la nostra vpn con i seguenti comandi:

/etc/init.d/ipsec start (solo se ipsec non era ancora stato avviato)
ipsec auto --verbose --up con-nuovaconnessione

Per verificare lo stato della vpn si può usare il seguente comando

ipsec auto --verbose --status

e verificare se sono in stato SA established sia ISAKMP che IPsec.
Esempio:

000 #153: "con-nuovaconnessione":500 STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 871s; newest ISAKMP; lastdpd=-1s(seq in:0 out:0)
000 #152: "con-nuovaconnessione":500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 25764s; newest IPSEC; eroute owner
000 #152: "con-nuovaconnessione" esp.2f26e857@IPPUBBLICOALTROPEER esp.2a9932cc@NOSTROIPPUBBLICO tun.0@IPPUBBLICOALTROPEER tun.0@NOSTROIPPUBBLICO


Un ulteriore prova è quella di mettersi su una macchina dietro al nostro firewall e provare con hping3 a raggiungere una destinazione sulla rete privata dell'altro peer.
Mettendoci in ascolto con tcpdump sia sull'interfaccia privata del nostro firewall (192.168.2.72) sia su quella pubblica dovremmo vedere i pacchetti ragiiungere il firewall e venire incapsulati attraverso il tunnel verso la destinazione.
Un esempio di comando hping3 (supponiamo che la porta 80 della destinazione sia aperta) :
hping3 -S IPPRIVATORETEALTROPEER -p 80
Un esempio dei comandi tcpdump da tirare sul firewall:
1)tcpdump -i eth1:1 host IPPRIVATOALTROPEER verifica che i pacchetti giungano sull'interfaccia interna del firewall
2)tcpdump -i eth0 host IPPUBBLICOALTROPEER verifico che i pacchetti stiano venendo incapsulati e girati nel tunnel verso la destinazione.
Se i pacchetti vengono incapsulati e girati nel tunnela ma non tornano indietro è molto probabile che ci sia qualche problema di routing dall'altra parte del tunnel.
Nel caso in cui volessimo tirare giù la vpn:
ipsec auto --verbose --down con-nuovaconnessione

MONITORARE LA RETE CON XYMON, L'EREDE DI BIG BROTHER

Xymon è la versione di System Monitoring derivata da Big Brother. Installeremo la versione server su una macchina Linux mentre il client è installabile sia in ambiente linux che microsoft windows.
In questo documento avremo a che fare sia con il Xymon-Server che con il Xymon-Client.
Stabiliamo che:
1)Xymon-Server(hostname: SRV-Monitor) 192.168.0.77
2)Xymon-Client 192.168.0.10

Creiamo sia sul server che sul client l'utenza Xymon dandogli come home /home/xymon
Per cominciare installeremo Xymon partendo con il suo download dal sito ufficiale (http://www.xymon.com/).

Xymon-Server: /home/xymon# wget http://freefr.dl.sourceforge.net/sourceforge/hobbitmon/xymon-4.2.3.tar.gz


Unzippiamo e estraiamo i pacchetti :

Xymon-Server:/home/xymon#tar zxvf xymon-4.2.3.tar.gz

Entriamo nella directory estratta:

Xymon-Server:/home/xymon#cd xymon-4.2.3

CONFIGURAZIONE

Xymon ha bisogno delle librerie RRD e PCRE, installiamole:

Xymon-Server:/home/xymon/xymon-4.2.3# apt-get install librrd2-dev librrd2
Xymon-Server:/home/xymon/xymon-4.2.3# apt-get install libpcre3 libpcre3-dev

Se non lo si è ancora fatto occorre anche il necessario per compilare:
Xymon-Server:/home/xymon/xymon-4.2.3# apt-get install make gcc g++

Xymon-Server:/usr/src/xymon-4.2.3# apt-get install make gcc g++

Poi si lancia la configurazione:

Xymon-Server:/home/xymon/xymon-4.2.3# ./configure

Lasciate tutte le indicazioni di default salvo le seguenti configurazioni:

Il gruppo utilizzato da Apache:

What group-ID does your webserver use nobody ?
www-data

L'hostname che sarà utilizzato da Xymon per il monitoraggio del server (potete lasciare l'indicazione di default):
What is the name of this host SRV-Monitor ?

L'IP che sarà utilizzato da Xymon per il monitoraggio del server locale:
What is the IP-address of this host 127.0.0.1 ?
192.168.0.77

INSTALLAZIONE

Ora possiamo compilare:
Xymon-Server:/home/xymon/xymon-4.2.3# make

Poi installare:
Xymon-Server:/home/xymon/xymon-4.2.3# make install


Occorre modificare la configurazione di Apache.
La configurazione Apache per Xymon si trova in /home/xymon/xymon-4.2.3/server/etc/hobbit-apache.conf. Per metterla in atto potete creare un nuovo VirtualHost nel quale mettere il contenuto del file o sostituire il contenuto del default (000-defaut).

Xymon-Server:/home/xymon/xymon-4.2.3# cp /home/xymon/xymon-4.2.3/server/etc/hobbit-apache.conf /etc/apache2/sites-enabled/000-default

Riavviate Apache

Xymon-Server:/home/xymon/xymon-4.2.3# /etc/init.d/apache2 restart

Avviate Xymon come segue:
Xymon-Server:/home/xymon/xymon-4.2.3# su - xymon -c "/home/xymon/xymon-4.2.3/server/bin/hobbit.sh start"

Xymon è ora visibile attraverso l'URL: http://192.168.0.77/xymon/

Per lanciare il client locale:
Xymon-Server:/home/xymon/xymon-4.2.3# /home/xymon/xymon-4.2.3/client/runclient.sh start


Se volete che la home page sia protetta da password:
Xymon-Server:/home/xymon/xymon-4.2.3# htpasswd -bc /home/xymon/xymon-4.2.3/server/etc/hobbitpasswd username password

- INSTALLAZIONE DEL CLIENT Xymon

Il server Xymon utilizza la porta 1984 per ricevere i dati dei clients, occorrerà quindi assicurarsi che la porta non sia impegnata da altri servizi. Sul nostro nuovo Xymon-Client, si scaricherà lo stesso pacchetto usato precedentemente:

Xymon-Client:/home/xymon# wget http://freefr.dl.sourceforge.net/sourceforge/hobbitmon/xymon-4.2.3.tar.gz

Estraiamo i pacchetti :
Xymon-Client:/home/xymon# tar zxvf xymon-4.2.3.tar.gz

Entriamo nella dir di xymon:
Xymon-Client:/home/xymon# cd xymon-4.2.3

Installiamo ciò che serve per compilare:
Xymon-Client:/home/xymon# apt-get install make gcc g++

Lanciamo la configurazione del client:
Xymon-Client:/home/xymon# ./configure.client

Una prima questione è posta, potete scegliere "server", per centralizzare sul server certe configurazioni o "client" per porli sul client locale:
Server side client configuration, or client side server ?
server

Poi rispondiamo alle altre domande:
Configuriamo l'installazione:
Accettiamo le risposte di default tranne alcune particolari.

Configuriamo l'IP del Xymon-Server:

What is the IP-address of your Xymon server 127.0.0.1 ?
192.168.0.77

La configurazione è terminata. Però la compilazione potrebbe impiantarsi con il seguente messaggio:
"/home/xymon/xymon-4.2.3/lib/timefunc.c:55: undefined reference to `clock_gettime'"

Per regolare il problema editate il MakeFile e aggiungete queste linee prima di "include build/Makefile.Linux" :

# clock_gettime() settings 
LIBRTDEF = -lrt 

Ora si può compilare tutto:
Xymon-Client:/home/xymon/xymon-4.2.3# make

Poi installare:
Xymon-Client:/home/xymon/xymon-4.2.3# make install

Avviamo il nostro client Xymon :
Xymon-Client:/home/xymon/xymon-4.2.3# /home/xymon/xymon-4.2.3/client/runclient.sh start

Perchè le informazioni provenienti dal client siano utilizzate e pubblicate dal server editate su Xymon-server il file /home/xymon/xymon-4.2.3/server/etc/bb-hosts e aggiungete una nuova linea contenente l'IP del client seguito dal suo hostname
192.168.0.10 Xymon-Client


- INSTALLARE IL CLIENT BBWIN
Cos'è BBWin ?

BBWin è un client open source per pemettere le comunicazioni tra Windows e Xymon
Usare BBWin con Xymon in modalità centralizzata

Per usare la modalità centralizzata di BBWin per Xymon devi avere la versione BBWin 0.12 o successiva
Per abilitare la modalità centralizzata in BBWin 0.12 scrivi queste linee nel tuo file bbwin.cfg:

Esempio di hobbit-clients.cfg per l'uso di Windows

HOST=%win.* #Your windows hosts 
        LOAD 80 90 # Load threholds are in % 
        DISK D 50 55 # Can be harddrive or mount points 
        DISK InetPub 30 35 
        MEMPHYS 90 101 
        MEMSWAP 90 95 
        MEMACT  90 97 
        PORT "LOCAL=%([.:]80)$" state=LISTENING TEXT=http 
        PROC BBWin.exe 1 1 
        PROC svchost.exe 3 4 
        LOG %.*  %.*error.* COLOR=yellow 
        SVC MSSQLSERVER startup=automatic status=started 
    

Per altri esempi guarda la pagina man hobbit-clients.cfg
FAQ
Con alcuni servers, alcuni test come svcs, ports, uptime e who appaiono in purple mentre altri sono verdi?
La modalità centralizzata invia un file (Client data) con tutte le informazioni dentro.
Cambia il file hobbitserver.cfg in questo modo:
MAXMSG_DATA="5242880"
MAXMSG_CLIENT="5242880"
MAXMSG_STATUS="5242880"