AIX

Topasrec, topasout y nmon_analyzer

2012-01-10T09:28:00.000-05:00

En AIX 6.1 el proceso topasrec se ejecuta en modo background por omisión, recopilando data de rendimiento en el directorio /etc/perf/daily. Estos archivos pueden ser convertidos a .csv pero más importante -desde el punto de vista de la facilidad de análisis- a .nmon.

Para ello solo hay que convertir el archivo deseado utilizando topasout con la opcion -a:

#cd /etc/perf/daily

#topasout -a archivo.topas

luego el archivo generado se le cambia la extensión a .nmon y puede ser alimentado al nmon_analyzer.

Notas:

Esta opcion es útil cuando no se consta con una recopilación previa para el análisis rapido del rendimiento, además de que el proceso guarda varios días anteriores al presente.
El archivo de opciones /usr/lpp/perfagent/daily.cf debe ser modificado para proveer más o menos detalles. La forma normal de recopilación de nmon ofrece más datos.

Clonear discos de AIX con dd

2011-08-26T07:40:00.000-05:00

# cd /var/adm/ras
# >nim.script
# >suma.log
# >bootlog
# >nimlog
# >conslog
# >nimsh.log
# >bosinstlog
# >devinst.log
# >nim.installp
# cd /
# >smit.log
# >smit.script
# errclear 0
# skulker
# rmtcpip
# chdev –l sys0 \
–a autorestart=true \
–a cpuguard=enable

y clonear los discos -usando raw devices- con el comando dd en bloques de 8MB

# dd if=/dev/rclientlv3 of=/dev/rclientlv4 bs=8M

Más detalles en: el blog de Doug Ranz

Cantidad de memoria a reservar para el Hypervisor

2011-08-26T07:28:00.002-05:00

Al menos 8%

Tunings comunes para Sybase y Oracle en AIX 5.3

2009-11-02T18:26:00.000-05:00

lru_file_repage=0
%max_client=90=%max_perm
%min_perm=5

Avarana

2009-07-20T00:58:00.000-05:00

Un blog sobre cultura, ciencia, Panamá, arte

Dump device perdido

2009-07-20T00:46:00.000-05:00

El volumen lógico lg_dumplv no se espejea durante un mirrorvg de rootvg, y puede ocurrir que en caso la pérdida del disco hdisk0, el primary dump quede sin referencia, tomandose como secundario la paginación primaria.
Esta situación también se da si estamos utilizando una instalación base como fuente para crear multiples instalaciones de AIX.
De cualquier manera, el lg_dumplv no es más que un logical volume de tipo sysdump con unos 128MB o más (depende su instalación) que puede ser asignado por medio de smit dump.

Formas variables y colas de impresion

2009-07-19T23:24:00.000-05:00

En muchos casos, la configuración de colas de impresión en AIX se complica por los diferentes formatos requeridos por el cliente: cheques, informes, reportes utilizan diferentes largos de página lo que puede sugerir que se creen tantas colas como existan requerimientos. Sin embargo esto solo complica la administración ya que tanto el aplicativo/base de datos como el sistema operativo requeriría cambios en caso de que dichas formas cambien.

Es así como es más factible crear colas con anchos de página máximos (usualmente 136 columnas) y largo de 0 (cero) lineas de tal forma que sea el programador de la aplicación quien maneje los formatos y no el administrador de AIX. Esto además evita la duplicidad de saltos de página.

Drivers para adaptadores no reconocidos por el Virtual IO server

2009-07-19T22:51:00.000-05:00

Luego de instalar el Virtual I/O server (V2.1.0.10) sobre un Blade JS23, se observó que este no reconocía las nuevas tarjetas de fibra, al ejecutar el cfgmgr sobre el oem_setup_env se obtenian errores de falta de drivers (no se encontraban paquetes devices.pciex.*); luego el VIO se actualizó al último fixpack disponible (V2.1.0.10 FP-20.1) en aras de que este trajera los ultimos drivers pero no fue así.

Ya que los drivers de dispositivo son parte del sistema operativo AIX "debajo" del VIO (AIX 6.1.2), se obtuvo un nivel de AIX que poseyera dichos devices.* y solo se instalaron aquellos que no forzacen un visible update del nivel, lo suficiente para poder reconocer los adaptadores y asignarlos (AIX 6.1.4):

fcs0 Available 03-00 PCI Express 4Gb FC Adapter (77103224)
fcs1 Available 03-01 PCI Express 4Gb FC Adapter (77103224)
fcs2 Available 05-00 4Gb PCIe FC Blade Expansion Card (7710322577106501)
fcs3 Available 05-01 4Gb PCIe FC Blade Expansion Card (7710322577106501)

Copia de un volumen logico entre diferentes volumenes de grupo

2008-05-05T09:18:00.001-05:00

El comando cplv ofrece una manera directa de copiar un volumen lógico a otro volumen de grupo. Esta funcionalidad es útil para realizar respaldos de dispositivos crudos o, por motivos de rendimiento, descargar E/S de discos sobreutilizados. El formato es el siguiente:

cplv -v volumen-de-grupo-destino -y volumen-logico-destino volumen-logico-original
Ejemplo:
cplv -v memevg -y copialv lv56

Otras parámetros permiten la copia hacia un volumen lógico ya creado, pero considero que el formato antes expuesto es mejor ya que inclusive copia el tipo de volumen lógico, el cual bien podria ser "raw" o cualquier cosa con la que hubiesemos creado el lv original. Digo esto porque muchos lv's se utilizan como dispositivos crudos (raw devices) y el "lv type" -de existir- es inconsecuente, mientras que las otras formas del cplv necesitan una especificación conocida: jfs, jfs2, sysdump, paging, jfslog, jfs2log o boot.

Ejecucion remota de comandos por conexion segura

2008-04-18T15:22:00.000-05:00

Para ejecutar comandos dentro de una conexión segura entre servidores, se necesita instalar el SSL y secure shell (ssh) primero, configurarlo y probarlo. Para los efectos de este ejemplo, el usuario ysanson del servidor alpha ejecutará comandos y copiará archivos en el servidor epsilon con el permiso del usuario apptest.

1. Generar las llaves de identificación. En este caso utilizaremos la encriptación rsa:

ysanson@alpha:/home/ysanson $ssh-keygen -t rsa

Generating public/private rsa key pair.

Enter file in which to save the key (/home/ysanson/.ssh/id_rsa):

Created directory '/home/ysanson/.ssh'.

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /home/ysanson/.ssh/id_rsa.

Your public key has been saved in /home/ysanson/.ssh/id_rsa.pub.

The key fingerprint is:pp:41:yy:84:4c:ta:c8:b4:90:e4:82:j9:5b:pp:fe:a9 ysanson@alpha

Solo necesitamos la llave pública (id_rsa.pub), no introducimos clave (porque añadiría un paso interactivo) y esta queda guardada en el directorio .ssh bajo el HOME del usuario.

2. Copiar el archivo público al servidor destino por de forma segura (scp), utilizando el usuario que nos permitirá la ejecución y copia remota, en este caso apptest.

ysanson@alpha:/home/ysanson/.ssh $scp id_rsa.pub apptest@epsilon:

The authenticity of host 'epsilon (1.70.1.210)' can't be established.

RSA key fingerprint is uu:ce:0a:xx:2b:83:a4:ii:a7:66:86:ed:ee:46:01:80.

Are you sure you want to continue connecting (yes/no)? yes

Warning: Permanently added 'epsilon,1.70.1.210' (RSA) to the list of known hosts.

mailto:apptest@epsilon password:id_rsa.pub 100% 224 0.2KB/s 00:00

El archivo es copiado al HOME del usuario apptest en epsilon porque al final del hostname destino hay dos puntos.

3. Crear el directorio .ssh en el servidor epsilon bajo el HOME de apptest y anexamos el contenido que archivo id_rsa.pub dentro del otro denominado authorized_keys.

$ mkdir .ssh

$ chmod 755 .ssh

$ cd .ssh$ cat ../id_rsa.pub >> authorized_keys

Los permisos son necesarios para garantizar que la llave pueda ser leída. La anexión (>>) se debe a que el mismo archivo puede contener las llaves públicas de otros usuario y servidores.

4. Ejecutamos un comando remotamente utilizando el comando ssh:

ysanson@alpha:/home/ysanson/.ssh $ssh apptest@epsilon cal

April 2008

Sun Mon Tue Wed Thu Fri Sat

1 2 3 4 5

6 7 8 9 10 11 12

13 14 15 16 17 18 19

20 21 22 23 24 25 26

27 28 29 30
o copiamos un archivo:

ysanson@alpha:/home/ysanson/.ssh $scp prueba apptest@epsilon:

Nuevamente es importante los dos puntos al final sino el archivo prueba es copiado al mismo servidor bajo el nombre apptest@epsilon .

Este aparentemente sencillo proceso requiere de mucho cuidado ya que la colocación de los archivos y sus permisos es crítico para su funcionamiento. Un problema que he observado es que durante el proceso de generación de la llave, el ssh-keygen pregunta dónde queremos almacenar los id_rsa*, sin embargo cuando hacemos la copia remota (scp), el archivo known_hosts generado se crea bajo el $HOME del usuario. Esto no tiene mayor consecuencia si el usuario que ejecuta el proceso es único, pero cuando se realiza por medio de un usuario que tiene el mismo UID que otro -como ocurre con aquellos que reemplazan a root-, entonces los id_rsa* deben copiarse al directorio .ssh donde exista el archivo known_hosts.

Corrupcion de los espejos de un volumen logico

2008-04-17T16:38:00.000-05:00

La corrupción de los espejos de un volumen lógico se refleja en errores como:

0516-1509 : VGDA corruption: physical partition info for this LV is invalid.

En estos casos, lo primero es tratar de eliminar el espejo y recrearlo, sea por medio de comandos o el smit. Sin embargo, no siempre es posible realizar la operación ya que la corrupción inhabilita al comando para ejecutar la operación de forma directa. En Internet encontré una forma de corregir el problema y aunque la solución funciona, las instrucciones no son claras. Al final lo que se desea es alimentar el comando lreducelv con el mapa de las particiones físicas mal espejadas. En el siguiente ejemplo obtenemos el mapa físico del volumen lógico:

root@server:/home/root #lslv -m fslv02

fslv02:/finanzas

LP PP1 PV1 PP2 PV2 PP3 PV3

0001 0204 hdisk1 0214 hdisk0

0002 0205 hdisk1 0215 hdisk0

0003 0206 hdisk1 0216 hdisk0

0004 0207 hdisk1 0217 hdisk0

El volumen lógico fslv02 tiene un espejo en el disco cero (hdisk0), el cual no permite ser eliminado. El comando lreducelv tiene el siguiente formato:

lreducelv -l identificador-del-volumen-logico -s numero-de-particiones-parcialmente-espejadas nombre-de-archivo

El identificador del volumen lógico lo obtenemos por medio de: lslv fslv02

root@server:/home/root #lslv fslv02

LOGICAL VOLUME: fslv02 VOLUME GROUP: rootvg

LV IDENTIFIER: 00cfd90f00004c0000000108493c5c5b.18

Para construir el archivo necesitamos el identificador de disco físico que contiene el espejo, por medio del comando lspv:

root@server:/home/root #lspv hdisk0

PHYSICAL VOLUME: hdisk0 VOLUME GROUP: rootvg

PV IDENTIFIER: 00cfd90f493c4574

luego, extraemos la información necesaria del lslv -m volumen-logico y creamos el archivo asi:

lslv -m fslv02 awk {'print "00cfd90f493c4574 "$4" "$1'} > archivo

Observese que luego del identificador del volumen físico hay un espacio y que el awk transpone las columnas 4 y 1 para obtener el siguiente formato:

00cfd90f493c4574 0214 0001

00cfd90f493c4574 0215 0002

00cfd90f493c4574 0216 0003

00cfd90f493c4574 0217 0004

Nota: el archivo debe ser editado a mano para eliminar los headers.

Finalmente el comando se corre así:

lreducelv -l 00cfd90f00004c0000000108493c5c5b.18 -s 4 archivo

donde el "4" es el número de líneas del archivo, obtenible por medio de vi o wc -l archivo.

Luego de corregido el problema, el volumen lógico puede volver a ser espejado de forma regular.

Replicacion diferencial de directorios y archivos

2008-03-13T12:29:00.000-05:00

Bajo ciertas circunstancias, aparte de las medidas de respaldo hacia dispositivos externos (cintas) o las estrategias de espejo o arreglo en disco, es necesario constar con un sistema actualizado y funcional, que -en caso de desastre- permita continuar la operación o al menos reducir al mínimo el downtime. Por supuesto, podríamos restaurar desde cinta, ¿pero qué tal si esto no es posible?Al existir un equipo de contingencia, usualmente las bases de datos pueden replicarse en línea, sin embargo, que hay sobre los programas y archivos de configuración?

El siguiente shell script copia los archivos del directorio /home/user en el serverA hacia su homologo en el serverB, denominado /home/replic, excluyendo un par de archivos que no nos interesan o bien, contienen información que "dañaría" el destino.

#!/usr/bin/ksh
x=`date`
echo "Directory replication /nProcess begun at: $x"
HOMEDIR=/home/user

cd $HOMEDIR
find . -newer tstamp > list
cat list grep -v "/conf/config.xml" > list1
cat list1 grep -v "/conf/web.xml" > list2
sed "s/user/replic/g" list2 > list3
x=`wc -l list3 awk {'print $1'}`
y=0
y=$(($x - 1))
tail -$y list3 > lista
cat lista
for file in `cat lista`
do
tar -cvf - $file ssh root@serverb "cd /home; tar -xpvf -"
echo $file
done
touch tstamp
x=`date`
echo "Process finished at: $x"

exit 0

Aunque el script podría ser más reducido y elegante, se buscó ser lo más claro posible, mostrando los diferentes filtros aplicables; El find crea la primera lista con los archivos modificados posteriores a la fecha del último respaldo (tstamp), luego deseamos que los archivos config.xml y web.xml sean excluídos (si se necesitan más, un archivo aparte podría contenerlos), esto se logra por medio de un grep exclusivo.

El tail elimina la primera línea de la última lista filtrada, removiendo la referencia al directorio raíz original (/home/user), de no existir este paso la copia se realizaría íntegra, completa, inutilizando la diferencialidad requerida, ya que el comando tar copia subdirectorios por omisión.

El otro punto importante lo constituye el reemplazo de la ruta original /home/user por la del destino /home/replic, utilizando el comando sed. Es decir que el destino raíz no tiene que ser igual que el origen, pero sí lo que hay debajo de él.

Luego de la copia, el archivo tstamp es actualizado por el comando touch, de tal manera que la proxima iteración solo contemple archivos nuevos y aquellos que han sido modificados.

Finalmente, el script depende de que la ejecución de comandos remotos a través de ssh se haya configurado previamente, procedimiento que veremos en otra entrada del blog.