jump to navigation

Enable/Disable Oracle Archive Logs Aprile 26, 2009

Posted by installatore in Oracle.
Tags: , , , , , , ,
add a comment

Per disabilitare la modalità archive log (per esempio per eseguire un grosso import),collegarsi all’istanza con Sql*Plus,quindi dare i seguenti comandi:

shutdown immediate;

startup mount;

alter database noarchivelog;

alter database open;

Se invece avete intenzione di abilitarli basta sostituire la riga alter database noarchivelog; con alter database archivelog;

Per controllare la modalità con cui si stà eseguendo oracle,sempre da Sql*Plus lanciare il seguente comando:

archive log list;

Nelle nuove installazioni di Oracle dove è presente la flash recovery area bisogna prestare attenzione quando si abilitano gli archive log.Di default con la flash recovery area la prima destinazione degli archive log è proprio quest’ultima,che però ha come grandezza di default (indipendentemente dallo spazio che avete libero sul file system) 2GB,nello sventurato caso in cui arrivate a tappare completamente questa grandezza,oracle non accetterà più nuove connessioni permettendo solo di connettervi localmente con Sql*Plus.L’errore è il seguente:

ORA-00257 archiver error. connect internal only, until freed

Per risolvere il problema collegarsi in locale e aumentare la grandezza della flash recovery area come segue:

sqlplus “/as sysdba”

alter system set db_recovery_file_dest = ‘/flash_recovery_area_location’; (nel caso voglia proprio spostarla per mancanza di spazio su file system,altrimenti saltare questo passaggio)

alter system set db_recovery_file_dest_size = 4g;  (raddoppio così il valore di default)

Log Rotation For Tomcat under Solaris 10 Aprile 26, 2009

Posted by installatore in Varie, script, solaris.
Tags: , , , ,
add a comment

Penso che almeno una volta tutti quelli che utilizzano Tomcat,si sono trovati davanti a file di log (catalina.out in primis) talmente grandi da non poter nemmeno essere aperti.Così mi sono creato questo breve scriptino che lanciato da crond una volta al giorno mi effettua la rotazione dei log e mi cancella quelli più vecchi di 3 giorni.

#!/bin/sh

logadm /opt/apache-tomcat-6.0.18/logs/cc.log -C 15 -c -p now -t ‘/opt/apache-tomcat-6.0.18/logs/CC_OK.%Y-%m-%d-%H-%M’

logadm /opt/apache-tomcat-6.0.18/logs/catalina.out -C 15 -c -p now -t ‘/opt/apache-tomcat-6.0.18/logs/CATALINA_OK.%Y-%m-%d-%H-%M’

find /opt/apache-tomcat-6.0.18/logs -mtime +3 -exec rm -f {} \;

Ho configurato successivamente lo scriptino nella crontab di root  e riavviato il servizio con

svcadm restart crond

 

Active/Active cluster with Heartbeat + Mon for a Server Application Aprile 26, 2009

Posted by installatore in linux, networking, script.
Tags: , , ,
add a comment

In questo articolo spiegherò brevemente come poter creare un cluster a 2 nodi Active/Active per un applicazione server attraverso anche l’uso di un record DNS Round Robyn,che andrà a smistare il traffico.

Per questa configurazione ho scelto di avere 2 indirizzi Ip virtuali (a cui punterà il round robyn) che potranno effettuare il failover su entrambi i nodi del nostro cluster.Per creare i 2 ip virtuali e lanciare mon, utilizzeremo heartbeat http://www.linux-ha.org/ .

Per gestire le risorse clusterizzate utilizzeremo mon http://mon.wiki.kernel.org/ .Mon avrà il compito di monitorare i nostri 2 nodi e tramite lo script tcp.monitor monitorare la porta che la nostra applicazione terrà aperta in ascolto.

Prima di tutto andiamo a configurare il file /etc/hosts inserendo i nomi host dei nostri server su entrambi i nodi.

10.0.0.2 nodoclu1                                                                                                                                                                                           

10.0.0.3 nodoclu2

Quindi procediamo con l’installazione di heartbeat e di mon,tramite i sorgenti o i packages scaricati dai relativi siti.Ipotizzerò che le cartelle di installazione per i 2 programmi siano /etc/ha.d (per heartbeat) e /etc/mon (per mon).

Cominciamo con il configurare su entrambi i nodi il file /etc/ha.d/ha.cf nel seguente modo:

# Logging 

debug 0

debugfile /var/log/ha-debug

use_logd  false

logfacility  daemon

logfile /var/log/ha-log

 

# Misc Options

traditional_compression off

compression bz2

coredumps true

 

# Communications (scelgo su quali interfacce e su che porta configurare le comunicazioni interne tra i due nodi)

udpport 691

bcast eth0

bcast eth1

 # Thresholds (in seconds)

keepalive 1

warntime 6

initdead 5   #(un nodo viene indicato come failed dopo 5 secondi)

 

deadtime 9 #(un nodo viene indicato come morto dopo 9 secondi)

ping 10.0.0.1      #(per verificare che la rete pubblica sia sù pingo il mio gateway)

node  nodoclu1,nodoclu2    #(i nodi che appartengono al cluster)

auto_failback off               #(gestisco il fail back delle risorse con mon,quindi questo lo lascio a off)

respawn hacluster /usr/lib64/heartbeat/ipfail     #(indica il programma che controlla le interfacce di rete)

In questo file abbiamo quindi specificato i parametri di partenza per heartbeat,non ci resta che andare ad editare anche il file /etc/ha.d/haresources per poter configurare le risorse che vogliamo clusterizzare.

nodoclu1 10.0.0.10 mon_script

nodoclu2 10.0.0.20

Abbiamo quindi specificato che sul nodoclu1 sarà presente l’ip virtuale 10.0.0.10 e la risorsa mon_script ,che sarebbe lo script di avvio di mon,che dovrà essere inserito in /etc/ha.d/resource.d .Mentre per il nodoclu2 girerà solamente un altro ip virtuale.Ovviamente entrambi i nodi possono ospitare tutte le risorse qui descritte (2 ip virtuali + mon).Qui di seguito lo script mon_script….

 

#!/bin/sh

#

# start/stop the mon server

#

# processname: mon

# config: /etc/mon/mon.cf

# pidfile: /var/run/mon.pid

#

PATH=/bin:/usr/bin:/sbin:/usr/sbin

export PATH

# Source function library.

. /etc/rc.d/init.d/functions

# See how we were called.

case “$1″ in

start)

echo -n “Starting mon daemon: “

# daemon /etc/mon/mon -c /etc/mon/mon.cf

/etc/mon/mon -f -c /etc/mon/mon.cf

echo

touch /var/lock/subsys/mon

;;

stop)

echo -n “Stopping mon daemon: “

killproc mon

echo

rm -f /var/lock/subsys/mon

;;

status)

base=”mon”

pid=`pidof -o $$ -o $PPID -o %PPID -x ${base}`

if [ -n "$pid" ]; then

echo “running”

else

echo “stopped”

fi

;;

monitor)

base=”mon”

pid=`pidof -o $$ -o $PPID -o %PPID -x ${base}`

if [ -n "$pid" ]; then

echo “running”

else

echo “stopped”

exit 7

fi

;; restart)

killall -HUP mon

;;

*)

echo “Usage: mon {start|stop|status|restart|monitor}”

exit 1

esac

exit 0

A questo punto possiamo lanciare heartbeat su entrambi i nodi per controllare che vengano caricate tutte le nostre risorse (/etc/init.d/heartbeat start).Quindi possiamo partire configurando il file /etc/mon/mon.cf

 

alertdir = /etc/mon/alert.d

mondir = /etc/mon/mon.d

logdir = /etc/mon

maxprocs = 20

histlength = 100

randstart = 60s

 

hostgroup nodo1 10.0.0.2    

hostgroup nodo2 10.0.0.3

 

watch nodo1

service tcp

interval 5s

monitor tcp.monitor -p 3000 10.0.0.2  #-p portatcp indirizzonodo1

period wd {Mon-Sun}

alert ha_sall.alert  #appena non mi risponde per 2 volte il server lancio /usr/lib64/heartbeat/hb_standby all

upalert ha_tloc.alert #appena torna su il server lancio /usr/lib64/heartbeat/hb_takeover local

alertafter 2

no_comp_alerts

watch nodo2

service tcp

interval 5s

 

monitor tcp.monitor -p 3000 10.0.0.3 #-p portatcp indirizzonodo2

period wd {Mon-Sun}

alert ha_tall.alert # appena non mi risponde per 2 volte il server lancio /usr/lib64/heartbeat/hb_takeover all

upalert ha_sfor.alert #appena torna su lancio /usr/lib64/heartbeat/hb_standby foreign

alertafter 2

no_comp_alerts

I file come ha_sfor.alert sono contenuti sotto /etc/mon/alert.d e non sono altro che file script con il comando scritto affianco.Ovviamente questa è la configurazione del nodo 1 quindi sul nodo 2 dovrò scambiare tutto ciò che riguarda col nodo1 con il nodo2 e viceversa.In pratica monitorizza se la porta 3000 sugli indirizzi ip indicati è aperta se non lo è esegue il file di alert dopo 2 volte che non risponde (alertafter 2),se la porta torna disponibile allora scatta l’upalert.Con questa configurazione la mia applicazione aveva tra l’alert e il failover delle risorse solo 5 secondi :D direi un risultato molto soddisfacente.

Setting Up external ntp source in a Sun Cluster environment Aprile 25, 2009

Posted by installatore in solaris.
Tags: , , ,
add a comment

Ultimamente mi sono trovato davanti a una nuova esperienza quella su Solaris.Un gran bel sistema operativo,un pò ostico all’inizio ma una volta presa la mano si vola :D

In questo articolo vi descrivo come poter impostare il client Ntp di Solaris 10 in un ambiente clusterizzato con Sun Cluster.

Se la parte cluster è già stata installata,dovremmmo prima stoppare il servizio xntpd ì,modificare il file /etc/inet/ntp.cluster,quindi dare un bel ntpdate -B serverntp per sincronizzare il sistema con l’nt,quindi riabilitare il servizio xntpd.Ovviamente queste operazioni,si intendono da fare prima su un nodo e poi su tutti gli altri .

/etc/init.d/xntpd.cluster stop

vi /etc/inet/ntp.cluster

#server serverntp
#server 127.127.1.0
#peer clusternode1-priv prefer
#peer clusternode2-priv
#driftfile /var/ntp/ntp.drift
#filegen peerstats file peerstats type day enable
#filegen loopstats file loopstats type day enable
#filegen clockstats file clockstats type day enable

ntpdate -B serverntp

/etc/init.d/xntpd.cluster start

Et voilà….la sincronizzazione è servita!

All’interno del file ntp.cluster notiamo bene come se avessimo avuto all’interno della nostra lan più di un server ntp potevamo omettere la riga  #server 127.127.1.0 in quanto dice solamente che in mancanza del primo server usa se stesso come fonte attendibile per la sincronizzazione.