Nadie quiere al administrador de backup
Pero lo cierto es que nadie puede vivir sin él…
Esta es una máxima bastante extendida en el proceloso mundo de la administración de máquinas. Las copia de seguridad son una lata, pero en caso de desastre nos salvan la vida. Literalmente.
Existen cantidad de métodos para realizar una buena política de salvados. Hoy vamos a dedicarle un pequeño espacio de tiempo a una de las más comunes. Ufsdump y Ufsrestores en combinación con nuestras aliadas. Las unidades de cinta.
Es importante conocer qué es lo que queremos salvar. mi experiencia me dice que no es necesario realizar un backup completo de una máquina, sino determinadas piezas de información contenida en ella. Por ejemplo, /var /opt /export/home /oracle, etc…
Conviene determinar claramente cuales son los ficheros y configuraciones impresccindibles y guardarlo a buen recaudo. Un apache se puede instalar desde cero en caso necesario, pero la configuración de cada servidor y el contenido de las páginas son temas más peliagudos.
Por otra parte, no tendremos que copiarlo todo todos los días. Hay archivos y directorios que no sufren variaciones en su contenido, mientras que otros van teniendo información nueva cada día, como una tabla de una base de datos.
Normalmente, hay dos tipos de backup:
- Completo: A realizar el primer día en que hacemos backup
- Incremental: A realizar en los días subsiguientes, y que incluirá únicamente los archivos que hayan sido modificados.
Por último, un pequeño procedimiento para copiado de filesystem completos a cinta. Solo para sus ojos…
Se copian los archivos a la cinta mediante ufsdump completo. En este caso, se realizaría un ufsdump por cada filesystem independiente.
# ufsdump 0uf /dev/rmt/numero_de_cinta /filesyetem
Ejemplos:
# ufsdump 0uf /dev/rmt/0 / # ufsdump 0uf /dev/rmt/0 /var # ufsdump 0uf /dev/rmt/0 /export/home
… etc
Si el salvado que deseamos hacer es incremental, hay que prestar atencion al dump level, que es un valor desde 0 a 9, y establece los ficheros que se van a a copiar que hayan sido modificados desde el último backup realizado a un nivel de dump inferior. Por ejemplo: Si el lunes hemos realizado un dump a nivel 2, y el martes hacemos un dump a nivel 4, en caso de que hagamos un dump a nivel 3 el miércoles copiaría asimismo todos los ficheros modificados o añadidos al sistema desde el backup del lunes.
Hay diferentes combinaciones, pero la que encuentro más adecuada es el llamado modelo de Torres de Hanoi y que viene a ser:
L: Nivel 3 M: Nivel 2 X: Nivel 5 J: Nivel 4 V: Nivel 7 S: Nivel 6 D: Nivel 0
En caso de que se quiera restaurar en un punto fijo, el comando sería:
Desde un directorio creado para contener los FS copiados (Ej: /var/tmp/restauracion)
# ufsrestore rvf /dev/rmt/numero_de_cinta ./filesyetem
Ejemplos:
# ufsrestore rvf /dev/rmt/0 ./ # ufsrestore rvf /dev/rmt/0 ./var # ufsrestore rvf /dev/rmt/0 ./export/home
Recuerden que estas cintas han de guardarse como oro en paño. En caso de que se destruyan o deterioren, es mucho trabajo tirado a la basura 
Si quieren mayor información, lo cual es muy inteligente ya que estas breve pinceladas apenas explican nada, les recomiendo el muy chulo (y divertido) manual Backup & Recovery de W. Preston publicado por O’Reilly.
Braiiiiiins…
Aprovechando una consulta que me han realizado, vamos a hacer un pequeño recordatorio sobre los procesos defunct, también llamados zombies. Es una buena época del año para ello, teniendo Halloween al lado. Hasta en World of Warcraft lo zombie está de moda
Hagamos un pequeño repaso para los que se perdieran las clases.
Los procesos en los sistemas Unix cuentan con una jerarquía de ejecución, de forma que, en caso de que se necesite, un proceso puede generar procesos nuevos (denominados hijos) para realizar funciones adicionales. De hecho, este punto es absolutamente normal y un proceso padre más o menos complejo puede llegar a generar buena cantidad de procesos hijos. Pensemos en una base de datos o un servidor web, por ejemplo.
Para poner un ejemplo, he aquí la jerarquía de procesos de un servidor ssh:
root@madhatter # ptree 19963
876 /usr/lib/ssh/sshd
19963 /usr/lib/ssh/sshd
19966 /usr/lib/ssh/sshd
19968 -sh
19972 bash
20025 ptree 19963
Así podemos ver que el proceso 19963 ha generado el proceso 19966, etc…
Los procesos no acabarán completamente hasta que el padre haya elegido sus estados de salida y acabado con ellos. En caso de que exista un gran número de procesos en estado defunct, sería conveniente examinar cual es el ID del proceso padre, ya que es responsabilidad de este proceso padre identificar todos los hijos que hayan acabado y obtener su estado. En caso contrario, el proceso padre de ese proceso padre heredaría los hijos, de forma que eventualmente puedan llegar al PID 1 (Init).
Si init hereda un proceso defunct (zombie), este proceso será “segado” o eliminado de la tabla de procesos, ya que esta es una de las tareas asignadas a init.
En caso de que el número de procesos defunct en la máquina no os parezca normal, convendría vigilar qué proceso está causando ese número de zombies para depurarlo.
Como detalle adicional, si el número de procesos defunct se descontrola, en Solaris 8 no queda otra opción que rebotar la máquina, mientras que en Solaris 9 y superior se puede emplear el comando preap para eliminar estos procesos defunct.
Por cierto, mucho ojo al emplear preap, que debería ser empleado únicamente como último recurso, ya que si se usa para matar un proceso que luego intenta ser eliminado por su proceso padre esto puede dañar el proceso padre de forma impredecible.
Ah, y no intentéis utilizar kill -9 para eliminar procesos defunct, ya que no hay ningún proceso corriendo para recoger la señal de KILL y no responderá al comando.
Colega, ¿donde está mi last?
Uno de los misterios más habituales, que ha causado más de un quebradero de cabeza a los sysadmins del mundo mundial es la falta de informacióncuando hacemos un last.
Para los que no lo tengan muy claro, last es una herramienta de seguridad que indica los últimos accesos a la máquina en orden reverso. Cada línea nos va a indicar nombre de usuario, la consola (tty) desde donde conecta, nombre de máquina y el comienzo y el fin de la sesión. Utilísimo para los paranoicos en todos nosotros
Un ejemplo práctico:
root@madhatter # last root pts/4 10.10.1.229 Tue Oct 21 13:57 still logged in root sshd 10.10.1.229 Tue Oct 21 13:57 still logged in root sshd 10.10.1.229 Wed Oct 8 12:30 - 12:36 (00:05) root sshd 10.0.231.64 Wed Oct 8 11:55 - 12:25 (00:29) root pts/4 10.10.1.229 Wed Oct 8 11:30 - 12:41 (01:11) root sshd 10.10.1.229 Wed Oct 8 11:30 - 11:55 (00:25) root console :0 Tue Sep 30 12:27 still logged in root pts/2 10.10.3.43 Mon Sep 29 11:30 - 11:30 (00:00) root sshd 10.10.3.43 Mon Sep 29 11:30 - 11:30 (00:00) root pts/2 10.10.1.229 Wed Sep 24 07:25 - 07:51 (00:26) root sshd 10.10.1.229 Wed Sep 24 07:25 - 07:51 (00:26) root sshd 10.10.1.229 Thu Sep 18 14:17 - 14:32 (00:15) root pts/2 10.10.1.229 Thu Sep 18 14:15 - 14:47 (00:31) root sshd 10.10.1.229 Thu Sep 18 14:15 - 14:17 (00:01) root pts/2 10.10.1.229 Thu Sep 18 08:44 - 08:44 (00:00) [...]
Imaginemos ahora una situación como esta
root@madhatter # last wtmp begins Wed Feb 25 04:30
La cara de tonto que se te queda cuando compruebas que el fichero está actualizado
root@madhatter # ls -l /var/adm/wtmpx -rw-r--r-- 1 adm adm 43599145 Oct 21 13:28 /var/adm/wtmpx
Que forzando te manda a peinarte
root@madhatter # last -f /var/adm/wtmpx wtmp begins Wed Feb 25 04:30
Que el filesystem no está lleno
root@madhatter # df -k /var Filesystem kbytes used avail capacity Mounted on /dev/vx/dsk/bootdg/rootvol 15345315 8665186 6526676 58% /
La causa más normal de este comportamiento es corrupción de datos en el fichero /var/adm/wtmpx que es donde se almacenan los datos para sacar el last. Las causas son variadas, desde llenado temporal de ese filesystem, un backup mal realizado, truncados de ficheros o simple y pura mala práctica.
La cuestión es arreglarlo. La forma más sencilla es, simplemente, recrearlo con los permisos adecuados, haciendo copia de seguridad previa:
root@madhatter # mv /var/adm/wtmpx /var/adm/wtmpx.BAK root@madhatter # touch /var/adm/wtmpx root@madhatter # chown adm:adm /var/adm/wtmpx root@madhatter # chmod 644 /var/adm/wtmpx
Listo. En caso de que nos interese mucho guardar los datos contenidos en el fichero, hay una operativa mucho más complicada que podéis examinar a fondo.
Esto es grande… Esto es pequeño
La comprobación de que el tamaño de las cosas es elástico (ejem, ejem) y más todavía en Unix.
Como me imagino que todos sabréis, el archivo de /var/adm/lastlog registra y almacena el tiempo de login de cada usuario, sea este correcto o incorrecto. Es útil para saber quien se ha conectado, cuanto tiempo, y desde donde.
En ocasiones, me han dado un toque de atención por el excesivo tamaño de /var y concretamente el de lastlog. Yo siempre les digo que para qué andan mirando donde no deben 
y luego les explico lo que me contaron a mí en su momento: El tamaño del archivo de lastlog al hacer un ls no se corresponde con su tamaño real.
El tamaño indicado al hacer un ls -l del fichero lastlog está basado en el UID más alto de los usuarios que estén conectados a la máquina. La fórmula que utiliza Solaris para esto es tamaño total de lastlog=(UID más alto de los usuarios + 1) * 28
De ésta manera, el fichero de lastlog se convierte en un fichero “disperso” en el que su tamaño real es mucho más pequeño del que pueda parecer. Para comprobarlo, vamos a seguir unos ejemplos sencillos:
Tamaño de /var actual de la máquina nuestra de pruebas:
root@madhatter # df -k /var/ Filesystem kbytes used avail capacity Mounted on /dev/vx/dsk/var 2031101 1472886 497282 75% /var
Tamaño de lastlog según ls (Aparente)
root@madhatter # ls -la /var/adm/lastlog -r--r--r-- 1 root root 1820084 Dec 10 14:17 /var/adm/lastlog root@madhatter # ls -lha /var/adm/lastlog -r--r--r-- 1 root root 1.7M Dec 10 14:17 /var/adm/lastlog
Tamaño real del mismo fichero
root@madhatter # du -ks /var/adm/lastlog 24 /var/adm/lastlog
Procedemos a vaciar el fichero lastlog y comprobamos su tamaño
root@madhatter # > lastlog
root@madhatter # ls -la lastlog
-r--r--r-- 1 root root 0 Dec 10 14:30 lastlog
root@madhatter # du -ks lastlog
0 lastlog
Así como el de /var
root@madhatter # df -k /var Filesystem kbytes used avail capacity Mounted on /dev/vx/dsk/var 2031101 1472862 497306 75% /var
Vemos que sólo ha aumentado en 24 Kb.
Ahora, entramos como usuario root. Según lo especificado en la fórmula, crece de tamaño en 28 bytes aparentes (Pero solo 1 kb real)
root@madhatter # ls -la lastlog
-r--r--r-- 1 root root 28 Dec 10 14:32 lastlog
root@madhatter # du -ks lastlog
1 lastlog
Kb que se descuenta de /var
root@madhatter # df -k /var Filesystem kbytes used avail capacity Mounted on /dev/vx/dsk/var 2031101 1472863 497305 75% /var
Ahora, procedemos a entrar con el usuario que tiene el UID mas alto en la maquina
prueba:x:65002:1::/var/tmp/usuario_prueba:/usr/bin/ksh
De nuevo, el fichero crece según la fórmula (65002+1)*28=1820084
root@madhatter # ls -la lastlog
-r--r--r-- 1 root root 1820084 Dec 10 14:35 lastlog
Pero sólo ha aumentado 23 Kb
root@madhatter # du -ks lastlog 24 lastlog
Así como /var
root@madhatter # df -k /var Filesystem kbytes used avail capacity Mounted on /dev/vx/dsk/var 2031101 1472894 497274 75% /var
Así pues no hay reserva de espacio en/var por parte de last log en lo que concierne al tamaño aparente, sino únicamente al tamaño real.
Y recordad: This is not a bug, is a feature
¡Trata de arrancarlo, por Dios!
¿Qué haríamos sin Veritas Volume Manager, me pregunto?. La cantidad de frustraciones y malos ratos que nos ha ahorraro… al tiempo que nos ha producido frustraciones y malos ratos nuevo es legandaria. Se puede odiar o se puede adorar a Veritas y conozco ambos tipos de gente, e incluso gente que pasa por ambos estado según el día.
Lo que es innegable es la necesidad de usar un buen gestor de volúmenes, que sea fiable, robusto y sencillo de manejar. En mi opinión, VXVM y VXFS lo son.
Sin embargo, nada es de color de rosa, y en ocasiones, al intentar arrancar una máquina que haya caído por cualquier cuestión (Un panic causado por una CPU en mal estado, por ejemplo), puede haber problemas (vaya novedad) y provocar que los volúmenes queden en estado disabled.
root@madhatter:/root# vxprint -htr [...] v crash - DISABLED ACTIVE 2427516 ROUND - fsgen pl crash-01 crash DISABLED ACTIVE 2427516 CONCAT - RW sd rootdisk-03 crash-01 rootdisk 15254567 2427516 0 c0t0d0 ENA pl crash-02 crash DISABLED ACTIVE 2427516 CONCAT - RW sd rootmirror-03 crash-02 rootmirror 8955954 2427516 0 c0t8d0 ENA [...]
Este problema es fácilmente solucionable. Únicamente hace falta deshabilitar uno de los plexes del volumen.
root@madhatter:/root# vxmend off crash-01 [...] v crash - DISABLED ACTIVE 2427516 ROUND - fsgen pl crash-01 crash DISABLED OFFLINE 2427516 CONCAT - RW sd rootdisk-03 crash-01 rootdisk 15254567 2427516 0 c0t0d0 ENA pl crash-02 crash DISABLED ACTIVE 2427516 CONCAT - RW sd rootmirror-03 crash-02 rootmirror 8955954 2427516 0 c0t8d0 ENA [...]
Tras ello, lo habilitamos de nuevo, dejando el plex en DISABLED CLEAN, y lo limpiamos. Es necesario psaar por estos estados, ya que de otro modo VXVM se quejará y no nos dejará continuar.
root@madhatter:/root# vxmend on crash-01 root@madhatter:/root# vxmend fix clean crash-01 root@madhatter:/root# vxprint -htr
[...] v crash - DISABLED ACTIVE 2427516 ROUND - fsgen pl crash-01 crash DISABLED CLEAN 2427516 CONCAT - RW sd rootdisk-03 crash-01 rootdisk 15254567 2427516 0 c0t0d0 ENA pl crash-02 crash DISABLED ACTIVE 2427516 CONCAT - RW sd rootmirror-03 crash-02 rootmirror 8955954 2427516 0 c0t8d0 ENA [...]
El último paso es arrancar el volumen completo.
root@madhatter:/root# vxvol start crash root@madhatter:/root# vxprint -htr [...] v crash - ENABLED ACTIVE 2427516 ROUND - fsgen pl crash-01 crash ENABLED ACTIVE 2427516 CONCAT - RW sd rootdisk-03 crash-01 rootdisk 15254567 2427516 0 c0t0d0 ENA pl crash-02 crash ENABLED ACTIVE 2427516 CONCAT - RW sd rootmirror-03 crash-02 rootmirror 8955954 2427516 0 c0t8d0 ENA [...]
Repetir el proceso en todos los volúmenes afectados. Y ya tenemos la máquina limpita.
Y para acabar, les remito al excelente tutorial de Veritas FS y Veritas VM de Ben Rockwood Aunque se trata de versiones antiguas del software es un punto de partida excelente para comprender esta tecnología.
Espejito, espejito…
Odio Solaris Volume Manager. Si fuera por mí, lo quemaba con fuego mientras reía a carcajadas.
Pero claro, viene de serie con el sistema operativo Y entre tener que pagar una licencia de Veritas Volume Manager que cuesta un riñon y poder contar con un gestor de volúmenes por la patilla, adivina que es lo que se va a quedar la gente en una gran mayoría de los casos 
Efectivamente, con uno de los gestores de volúmenes mas antiintuitivos y despreciables que existen. Para matarlos, Oiga.
Menos mal que en Solaris 10 viene incluído por defecto ZFS, que además de ser un tiro y fiable, es absurdamente sencillo de administrar, aunque lo mismo de ello hablamos otro día.
En todo caso, y para todas aquellas veces que tengamos que hacer un mirror de sistema con esta herramienta, una pequeña guía.
Supongamos que nuestra máquina tiene cuatro discos internos:
AVAILABLE DISK SELECTIONS: 0. c0t0d0 <SUN36G cyl 24620 alt 2 hd 27 sec 107> /pci@1f,4000/scsi@3/sd@0,0 1. c0t1d0 <SUN36G cyl 24620 alt 2 hd 27 sec 107> /pci@1f,4000/scsi@3/sd@1,0 2. c0t2d0 <SUN18G cyl 7506 alt 2 hd 19 sec 248> /pci@1f,4000/scsi@3/sd@2,0 3. c0t3d0 <SUN18G cyl 7506 alt 2 hd 19 sec 248> /pci@1f,4000/scsi@3/sd@3,0
Un listado de la tabla de particiones del disco de arranque muestra lo siguiente:
Total disk cylinders available: 24620 + 2 (reserved cylinders) Part Tag Flag Cylinders Size Blocks 0 root wm 0 - 4355 6.00GB (4356/0/0) 12584484 1 swap wu 4356 - 10163 8.00GB (5808/0/0) 16779312 2 backup wm 0 - 24619 33.92GB (24620/0/0) 71127180 3 unassigned wm 0 0 (0/0/0) 0 4 unassigned wm 0 0 (0/0/0) 0 5 var wm 10164 - 14519 6.00GB (4356/0/0) 12584484 6 unassigned wm 14520 - 20327 8.00GB (5808/0/0) 16779312 7 unassigned wm 20328 - 20509 256.74MB (182/0/0) 525798
Lo primero es asegurarnos de que el disco que va a hacer mirror tiene la misma tabla de particiones, para lo cual:
root@madhatter # prtvtoc /dev/rdsk/c0t0d0s2 | fmthard -s - /dev/rdsk/c0t1d0s2
Continuamos inicializando la base de metadispositivos. Emplearemos el slice 7 ya que cuenta con espacio suficiente.
root@madhatter # metadb -a -f -c3 /dev/dsk/c0t0d0s7 /dev/dsk/c0t1d0s7
Tras ello, podemos comenzar a crear los mirrors, comenzando por /
root@madhatter # metainit -f d10 1 1 c0t0d0s0 d10: Concat/Stripe is setup root@madhatter # metainit d20 1 1 c0t1d0s0 d20: Concat/Stripe is setup root@madhatter # metainit d30 -m d10 d30: Mirror is setup root@madhatter # metaroot d30
Lo mismo para swap:
root@madhatter # metainit -f d11 1 1 c0t0d0s1 d11: Concat/Stripe is setup root@madhatter # metainit d21 1 1 c0t1d0s1 d21: Concat/Stripe is setup root@madhatter # metainit d31 -m d11 d31: Mirror is setup
Para /var
root@madhatter # metainit -f d15 1 1 c0t0d0s5 d15: Concat/Stripe is setup root@madhatter # metainit d25 1 1 c0t1d0s5 d25: Concat/Stripe is setup root@tesol025 # metainit d35 -m d15 d35: Mirror is setup
Y finalmente para /var/crash
root@madhatter # metainit -f d16 1 1 c0t0d0s6 d16: Concat/Stripe is setup root@madhatter # metainit d26 1 1 c0t1d0s6 d26: Concat/Stripe is setup root@madhatter # metainit d36 -m d16 d36: Mirror is setup
Ahora podemos añadir los cambios realizados a /etc/vfstab para que se cojan los cambios en arranque. Recordemos que conviene hacer siempre una copia de seguridad antes de las modificaciones, para evitar futuras lágrimas
root@madhatter #/dev/dsk/c1d0s2 /dev/rdsk/c1d0s2 /usr ufs 1 yes - fd - /dev/fd fd - no - /proc - /proc proc - no - /dev/md/dsk/d31 - - swap - no - /dev/md/dsk/d30 /dev/md/rdsk/d30 / ufs 1 no - /dev/md/dsk/d35 /dev/md/rdsk/d35 /var ufs 1 no - /dev/md/dsk/d36 /dev/md/rdsk/d36 /var/crash ufs 2 yes - swap - /tmp tmpfs - yes -
Tras ello, realizamos un reboot de la maquina. En el momento en que este de nuevo arriba, entramos como root y comprobamos si el disco esta inicializado para arrancar desde mirror:
root@madhatter # eeprom |grep boot [...] boot-file: data not available. boot-device=disk
Tenemos que añadir el otro disco. Para ello, comprobamos cual es:
root@madhatter # prtconf -vp |grep disk
[...]
disk: '/pci@1f,4000/scsi@3/disk@0,0'
disk0: '/pci@1f,4000/scsi@3/disk@0,0'
disk1: '/pci@1f,4000/scsi@3/disk@1,0'
disk2: '/pci@1f,4000/scsi@3/disk@2,0'
disk3: '/pci@1f,4000/scsi@3/disk@3,0'
[...]
Comprobamos que ambos discos sean iguales:
root@madhatter # format
AVAILABLE DISK SELECTIONS:
[...]
1. c0t1d0 <SUN36G cyl 24620 alt 2 hd 27 sec 107>
/pci@1f,4000/scsi@3/sd@1,0
[...]
Y cambiamos los valores correspondientes:
root@madhatter # eeprom boot-device="disk disk1"
Comprobamos:
root@madhatter # eeprom |grep boot [...] boot-file: data not available. boot-device=disk disk1
Y procedemos a atachar los metadevices entre si.
# metattach d30 d20 submirror d20 is attached # metattach d31 d21 d31: submirror d21 is attached # metattach d35 d25 d35: submirror d25 is attached # metattach d36 d26
Tras ello, los disco comenzaran a realizar la sincronizacion. Podemos comprobar el estado de la misma con el comando:
root@madhatter # metastat |grep % Resync in progress: 4 % done Resync in progress: 2 % done Resync in progress: 2 % done Resync in progress: 1 % done
Una vez terminada, se habra creado correctamente el mirror.
MPXIO para el nene y la nena. Segunda parte
Una vez comprendidas las generalidades, vamos a proceder a la implementación del asunto, que es lo más interesante.
MPXIO está implementado en Solaris desde la versión 8, pero su configuración ha sido cambiada en Solaris 10, de modo que un caveat antes de ponernos en harina: Imaginemos que el artículo ha sido escrito para las versiones 8 y 9 de Solaris. Haré las matizaciones necesarias para la última versión.
Retomando el ejemplo de la última entrada, vamos a examinar el total de discos que habría en la máquina:
root@madhatter $ format
Searching for disks...done
AVAILABLE DISK SELECTIONS: 0. c0t0d0 /pci@83,4000/FJSV,ulsa@2,1/sd@0,0 1. c0t1d0 /pci@83,4000/FJSV,ulsa@2,1/sd@1,0 2. c2t50060168082006E2d0 /pci@83,2000/pci@2/lpfc@4/fp@0,0/ssd@w50060168082006e2,0 3. c2t50060160082006E2d0 /pci@83,2000/pci@2/lpfc@4/fp@0,0/ssd@w50060160082006e2,0 4. c2t50060168082006E2d1 /pci@83,2000/pci@2/lpfc@4/fp@0,0/ssd@w50060168082006e2,1 5. c2t50060160082006E2d1 /pci@83,2000/pci@2/lpfc@4/fp@0,0/ssd@w50060160082006e2,1 6. c3t50060169082006E2d0 /pci@83,2000/pci@2/lpfc@5/fp@0,0/ssd@w50060169082006e2,0 7. c3t50060161082006E2d0 /pci@83,2000/pci@2/lpfc@5/fp@0,0/ssd@w50060161082006e2,0 8. c3t50060161082006E2d1 /pci@83,2000/pci@2/lpfc@5/fp@0,0/ssd@w50060161082006e2,1 9. c3t50060169082006E2d1 /pci@83,2000/pci@2/lpfc@5/fp@0,0/ssd@w50060169082006e2,1 Specify disk (enter its number): ^D
Antes de nada, será necesario instalar el software de SAN más los parches correspondientes. Diríjanse a Sunsolve a golpe de atambores para recoger el SAN Foundation Kit, así como los drivers y parches para HBA Emulex, que será las que utilicemos en este ejemplo. En caso de Solaris 10, no será necesario, ya que está incluído con el sistema operativo.
Una vez instalado todo, editaremos el fichero /kernel/drv/scsi_vhci.conf
Vamos a buscar la entrada mpxio-disable=”yes”;
Y la cambiaremos para que diga mpxio-disable=”no”;
Nota: En Solaris 10 el fichero a editar es /kernel/drv/fp.conf
Por último, y en caso de que estemos utilizando un dispositivo de almacenamiento externo, habrá que rellenar la parte correspondiente del final del fichero. El ejemplo que pongo a continuación está hecho usando una cabina IBM.
# For enabling MPxIO support for 3rd party symmetric device need an # entry similar to following in this file. Just replace the "SUN SENA" # part with the Vendor ID/Product ID for the device, exactly as reported by # Inquiry cmd. # # This functionality requires patch 113039-02 (or higher). # # device-type-scsi-options-list = # "SUN SENA", "symmetric-option"; # # symmetric-option = 0x1000000; # device-type-scsi-options-list = "IBM 2105800", "symmetric-option"; symmetric-option = 0x1000000;
Eso es todo, ahora será necesario realizar un reboot con reconfiguración. Una vez terminado, podremos ver que los discos en el sistema han cambiado:
AVAILABLE DISK SELECTIONS: 0. c0t0d0 /pci@83,4000/FJSV,ulsa@2,1/sd@0,0 1. c0t1d0 /pci@83,4000/FJSV,ulsa@2,1/sd@1,0 2. c4t6006016061B71000AD0810C9979CD911d0 /scsi_vhci/ssd@g6006016061b71000ad0810c9979cd911 3. c4t6006016061B7100055B12704989CD911d0 /scsi_vhci/ssd@g6006016061b7100055b12704989cd911 Specify disk (enter its number): ^D
De hecho, la correcta composición del dispositivo nuevo se puede ver en el arranque:
Dec 18 11:42:24 madhatter mpxio: [ID 669396 kern.info] /scsi_vhci/ssd@g600c0ff000000000086ab238b2af0600 (ssd11) multipath status: optimal, path /pci@9,600000/SUNW,qlc@1/fp@0,0 (fp1) to target address: 216000c0ff886ab2,0 is online. Load balancing: round-robin
En caso de que haya algún problema con los caminos, sería reportado en el messages:
Aug 24 07:09:01 madhatter mpxio: [ID 669396 kern.info] /scsi_vhci/ssd@g600c0ff000000000086ab238b2af0600 (ssd11) multipath status: degraded, path /pci@9,600000/SUNW,qlc@1/fp@0,0 (fp1) to target address: 216000c0ff886ab2,0 is online. Load balancing: round-robin
Y asimismo, podemos ver lo que hay por debajo, así como los caminos independientes, haciendo un luxadm de los discos. De la misma forma, podemos ver si hay problemas con los caminos de las tarjetas hacia las LUN.
root@madhatter# luxadm display /dev/rdsk/c4t6006016061B71000AD0810C9979CD911d0s2 DEVICE PROPERTIES for disk: /dev/rdsk/c4t6006016061B71000AD0810C9979CD911d0s2 Vendor: SUN Product ID: StorEdge 3510 Revision: 413C Serial Num: 086AB238B2AF Unformatted capacity: 1397535.000 MBytes Write Cache: Enabled Read Cache: Enabled Minimum prefetch: 0x0 Maximum prefetch: 0xffff Device Type: Disk device Path(s):
/dev/rdsk/c4t6006016061B71000AD0810C9979CD911d0s2 /devices/scsi_vhci/ssd@g600c0ff000000000086ab238b2af0600:c,raw Controller /pci@83,2000/pci@2/lpfc@4/fp@0,0 Device Address 216000c0ff886ab2,0 Host controller port WWN 210000e08b14cc40 Class primary State ONLINE Controller /pci@83,2000/pci@2/lpfc@4/fp@0,0 Device Address 266000c0fff86ab2,0 Host controller port WWN 210000e08b144540 Class primary State ONLINE
MPXIO para el nene y la nena. Primera parte
Voy a comenzar una serie de artículos comentando la tecnología MPXIO con un doble objetivo: Hacer algo un poco más extenso que las entradas anteriores que puedan servir a quien lo lea, si es que esto lo llega a leer alguien alguna vez 
y refrescar mis conocimientos sobre el tema, que nunca viene mal.
Así que vamos a comenzar por lo básico…
MPXIO, también llamado Solaris Multiplexed I/O o Sun StorageTek Traffic Manager (Ogh!) permite acceder a un disco a través de varias instancias I/O, pero tratándolas como si fueran una única instancia a nivel de sistema operativo.
¿Suena la pera de complicado?. Les aseguro que no es para tanto, buena señora.
Vamos a suponer que tenemos una máquina llamada Madhatter (Que original!. Gracias, gracias). Esta máquina cuenta con dos discos internos, que se encuentran en mirror para asegurar redundancia y, digamos, cuatro LUN adicionales que nos provee una cabina de discos a los que se accede por un par de HBAs Emulex. El tinglado habitual, pero dejemos una imagen para que no haya líos…
En caso de que no tuviéramos MPXIO implementado, veríamos nada menos que diez discos en el sistema operativo al hacer un format, ya que tenemos los dos discos internos más los cuatro discos externos ofrecidos por los dos caminos.
Ahora bien, al implementar MPXIO estamos “encapsulando” las LUN en un dispositivo virtual por cada una de las HBA que tengamos en la máquina. Y dejaremos de ver los discos anteriores, sustituyéndose estos por un dispositivo nuevo.
Esto tiene dos ventajas muy claras. La primera es que, en caso de que uno de los dispositivos I/O falle (Imaginemos que una de las HBA de la máquina se queda frita), tendremos redundancia ya que el propio software de MPXIO se encarga de hacer el failover hacia un dispositivo de backup.
Y, en segundo lugar, tenemos un incremento en el rendimiento de la lectura en disco externo, ya que estamos repartiendo la carga a través de varios canales. Vamos, que todo el mundo gana
La teoría es siempre un rollo. En el próximo artículo nos ponemos en harina. Ya verán que sencillo
Este disco ¿De quien es?
Los mensajes de error en almacenamiento, tanto interno como externo, en sistemas Solaris tienen la particularidad de no ser especialmente amistosos con el que los lee por primera vez. Un ejemplo:
Apr 13 06:22:06 madhatter scsi: [ID 107833 kern.warning] WARNING: /pci@7c,600000/SUNW,qlc@1/fp@0,0/ssd@w50060e8003ea6d03,49 (ssd356): Apr 13 06:22:06 madhatter SCSI transport failed: reason 'timeout': retrying command Apr 13 06:22:36 madhatter scsi: [ID 107833 kern.warning] WARNING: /pci@fc,600000/SUNW,qlc@1/fp@0,0/ssd@w50060e8003ea6d13,49 (ssd986): Apr 13 06:22:36 madhatter SCSI transport failed: reason 'timeout': retrying command Apr 13 06:23:06 madhatter scsi: [ID 107833 kern.warning] WARNING: /pci@7c,600000/SUNW,qlc@1/fp@0,0/ssd@w50060e8003ea6d03,49 (ssd356): Apr 13 06:23:06 madhatter SCSI transport failed: reason 'timeout': giving up
El problema es descodificar el chorro que sale en un disco en concreto. Afortunadamente para nosotros, Solaris pone un acceso al nombre de disco concreto dentro del directorio /dev/dsk
De este modo, se trata de una simple cuestión de filtrado.
madhatter:root:/dev/dsk# ls -l *s2 |grep w50060e8003ea6d03,49 lrwxrwxrwx 1 root root 72 Sep 5 2005 c6t50060E8003EA6D03d73s2 -> ../../devices/pci@7c,600000/SUNW,qlc@1/fp@0,0/ssd@w50060e8003ea6d03,49:c
Tachan!. Sabía que ese almacenamiento externo del todo a un euro me iba a causar problemas
¿Y si son muchos los discos que están fallando?. Ah, pues entonces viene a nosotros el poder de la shell:
madhatter:root:/dev/dsk# for i in `grep WARNING /var/adm/messages |nawk ' {print $10}'`;
do ls -arlit *s2 |nawk ' {print $10}'; done
Esto nos sacaría por pantalla únicamente el disco con problemas.
Ahora ya podemos examinar la cabecera del disco para ver si se puede leer correctamente, así como los caminos físicos, por si hubiera problemas en alguna parte de la cadena.
Otro día hablamos de las HBA, esas grandes desconocidas
Escuchando bajo el radar
Iba a escribir hoy una entrada sobre la forma de sacar los discos físicos desde los errores del /var/adm/messages, que es tema fácil y agradecido, pero ya que hemos tenido una pequeña movida con una máquina, aprovecharé para comentar cosas sobre monitorización de procesos en Solaris. Es tema conocido, pero nunca está de mas revisar temas de base.
ps: El que todo el mundo conoce, lista los procesos que se encuentran ejecutándose en ese momento en la máquina. Tiene buena cantidad de operandos, pero los más habituales son -ef (Listar todos los procesos actuales y sacar lista completa de los mismos). Es el punto de partida desde el que comenzaremos a explorar el sistema con los demás comandos.
ptree: Nos permite ver el árbol de procesos completo y qué cuelga por debajo del principal. Un ejemplo curioso en el que vemos como sshd tiene por debajo una sesión desde la que se lanza el propio comando ptree.
bash-3.00# ptree 876
876 /usr/lib/ssh/sshd
21670 /usr/lib/ssh/sshd
21673 /usr/lib/ssh/sshd
21675 -sh
21679 bash
21729 ptree 876
prstat: Vista a pantalla completa de procesos, que se puede separar por distintos operandos (-J para agrupar por proyectos, -L para lightweight process, etc… Es similar al top de Linux. Para más operandos, examinar el man.
bash-3.00# prstat -J
PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
3416 root 131M 69M sleep 59 0 23:33:21 1.7% java/20
3831 root 115M 52M sleep 59 0 12:26:17 0.8% java/23
21670 root 11M 5648K sleep 59 0 0:00:00 0.4% sshd/1
3936 root 102M 31M sleep 49 0 6:15:39 0.2% java/14
21680 root 3376K 2928K cpu1 39 0 0:00:00 0.1% prstat/1
2184 noaccess 166M 86M sleep 59 0 3:24:06 0.1% java/23
3896 root 71M 13M sleep 59 0 4:16:51 0.1% gnome-netstatus/1
21673 root 11M 2488K sleep 59 0 0:00:00 0.1% sshd/1
648 root 94M 19M sleep 59 0 3:46:56 0.1% poold/8
21679 root 3096K 2280K sleep 59 0 0:00:00 0.1% bash/1
157 daemon 4592K 2432K sleep 59 0 0:00:01 0.1% kcfd/3
21675 root 1360K 1128K sleep 59 0 0:00:00 0.0% sh/1
3915 root 70M 12M sleep 59 0 0:51:34 0.0% mixer_applet2/1
3693 root 77M 19M sleep 59 0 0:57:05 0.0% gnome-panel/1
1411 root 20M 14M sleep 59 0 1:00:41 0.0% Xsun/1
775 daemon 183M 182M sleep 59 0 0:13:21 0.0% nfsmapid/4
150 root 5112K 3840K sleep 59 0 0:07:56 0.0% nscd/31
3805 root 9808K 5216K sleep 59 0 0:07:27 0.0% gnome-vfs-daemo/2
PROJID NPROC SWAP RSS MEMORY TIME CPU PROJECT
1 37 187M 320M 31% 37:23:39 2.8% user.root
0 47 392M 480M 47% 20:27:06 1.1% system
Total: 84 processes, 313 lwps, load averages: 0.13, 0.12, 0.12
pfiles: Muestra los descriptores del proceso, asociados al mismo. Con el proceso anterior, podremos ver inodos, uis, gid y hasta el puerto en el que está escuchando.
bash-3.00# pfiles 876
876: /usr/lib/ssh/sshd
Current rlimit: 256 file descriptors
0: S_IFCHR mode:0666 dev:308,0 ino:6815752 uid:0 gid:3 rdev:13,2
O_RDWR|O_LARGEFILE
/devices/pseudo/mm@0:null
1: S_IFCHR mode:0666 dev:308,0 ino:6815752 uid:0 gid:3 rdev:13,2
O_RDWR|O_LARGEFILE
/devices/pseudo/mm@0:null
2: S_IFCHR mode:0666 dev:308,0 ino:6815752 uid:0 gid:3 rdev:13,2
O_RDWR|O_LARGEFILE
/devices/pseudo/mm@0:null
3: S_IFSOCK mode:0666 dev:314,0 ino:14371 uid:0 gid:0 size:0
O_RDWR|O_NONBLOCK
SOCK_STREAM
SO_REUSEADDR,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.0.192.0)
sockname: AF_INET6 :: port: 22
7: S_IFREG mode:0666 dev:309,1 ino:65539 uid:0 gid:0 size:0
O_RDWR|O_LARGEFILE
/system/contract/process/template
pstack: Muestra la pila de memoria del proceso. Es útil para saber qué está pasando a alto nivel, pero prefiero truss para estos casos.
bash-3.00# pstack 876
876: /usr/lib/ssh/sshd
ff0457c8 pollsys (ffbff3a8, 1, 0, 0)
fefe6d00 pselect (ffbff3a8, ff072528, ff072528, 40, 0, 0) + 1c8
fefe7078 select (6, 7f4d0, 0, 0, 0, 28) + a0
0001d084 main (8, ffffffff, a, 0, 0, a) + e58
0001acc0 _start (0, 0, 0, 0, 0, 0) + 108
pmap: Muestra el mapa de los procesos, junto con las librerías de las que está tirando en un momento concreto y la memoria que consume. Resulta sorprendente todo lo que se carga para un proceso concreto.
bash-3.00# pmap 876
876: /usr/lib/ssh/sshd
00010000 328K r-x– /usr/lib/ssh/sshd
00072000 16K rwx– /usr/lib/ssh/sshd
00076000 64K rwx– [ heap ]
FEEF0000 40K r-x– /usr/sfw/lib/libcrypto_extra.so.0.9.7
FEF0A000 8K rwx– /usr/sfw/lib/libcrypto_extra.so.0.9.7
FEF10000 24K r-x– /lib/libnvpair.so.1
FEF26000 8K rwx– /lib/libnvpair.so.1
FEF30000 16K r-x– /lib/libsecdb.so.1
FEF44000 8K rwx– /lib/libsecdb.so.1
FEF50000 80K r-x– /lib/libmd.so.1
FEF74000 8K rwx– /lib/libmd.so.1
FEF80000 888K r-x– /lib/libc.so.1
FF06E000 32K rwx– /lib/libc.so.1
FF076000 8K rwx– /lib/libc.so.1
FF080000 1088K r-x– /usr/sfw/lib/libcrypto.so.0.9.7
FF190000 112K rwx– /usr/sfw/lib/libcrypto.so.0.9.7
FF1AC000 8K rwx– /usr/sfw/lib/libcrypto.so.0.9.7
FF1B0000 16K r-x– /lib/libcontract.so.1
FF1C4000 8K rwx– /lib/libcontract.so.1
FF1D0000 16K r-x– /lib/libcmd.so.1
FF1E4000 8K rwx– /lib/libcmd.so.1
FF1F0000 48K r-x– /usr/lib/libgss.so.1
FF20C000 8K rwx– /usr/lib/libgss.so.1
FF210000 32K r-x– /usr/sfw/lib/libwrap.so.1.0
FF228000 8K rwx– /usr/sfw/lib/libwrap.so.1.0
FF230000 128K r-x– /lib/libbsm.so.1
FF250000 24K rwx– /lib/libbsm.so.1
FF260000 32K r-x– /lib/libpam.so.1
FF270000 24K rwx– [ anon ]
FF278000 8K rwx– /lib/libpam.so.1
FF280000 584K r-x– /lib/libnsl.so.1
FF31E000 8K rwxs- [ anon ]
FF322000 40K rwx– /lib/libnsl.so.1
FF32C000 24K rwx– /lib/libnsl.so.1
FF340000 8K rwx– [ anon ]
FF350000 72K r-x– /usr/lib/libz.so.1
FF370000 8K rwx– /usr/lib/libz.so.1
FF380000 48K r-x– /lib/libsocket.so.1
FF390000 8K rwx– [ anon ]
FF39C000 8K rwx– /lib/libsocket.so.1
FF3A0000 16K r-x– /platform/sun4u/lib/libc_psr.so.1
FF3B0000 208K r-x– /lib/ld.so.1
FF3F0000 8K rwx– [ anon ]
FF3F4000 8K rwx– /lib/ld.so.1
FF3F6000 8K rwx– /lib/ld.so.1
FFBFC000 16K rw— [ stack ]
total 4168K
lsof: Muestra los ficheros y procesos abiertos. Resulta muy útil cuando queremos saber quien está accediendo a un directorio concreto o a un fichero específico.
bash-3.00# lsof /usr/lib/ssh/sshd
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
sshd 876 root txt VREG 276,0 350624 256405 /usr/lib/ssh/sshd
sshd 21670 root txt VREG 276,0 350624 256405 /usr/lib/ssh/sshd
sshd 21673 root txt VREG 276,0 350624 256405 /usr/lib/ssh/sshd
Otro día seguimos.
