Topasrec, topasout y nmon_analyzer

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

# 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

Al menos 8%

Tunings comunes para Sybase y Oracle en AIX 5.3


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

Avarana

Un blog sobre cultura, ciencia, Panamá, arte

Dump device perdido

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

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

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

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

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.

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:
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:
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.