Tengo que dejar de hacer estos juegos de palabras tan ridículos…

Aprovecharemos las tribulaciones de parte del equipo de Sybase para comentar un par de trucos sobre puertos y procesos, que es algo que viste mucho y resulta muy útil y facil.

Supongamos una situación más que típica. Una instancia de base de datos ha dado un error y se está intentando parar. Como el error ha dejado un montón de procesos colgando de un puerto, no se puede parar hasta que se eliminen uno a uno. Pero ¿cuales son esos procesos?.

Partamos de la base de que conocemos cual es el puerto de la aplicación. No me digan que o lo saben, porque cualquier administrador de bases de datos digno de su nombre deberia conocer ese dato. Hombre ya.

Emplearemos lsof para ver qué está escuchando por ahí

root@madhatter # lsof |grep -i esta|grep 2640
dataserve 15366   sybase   51u  IPv4 0x513f9aec060  0t0  TCP madhatter-ce0:45880->madhatter-ce0:2640 (ESTABLISHED)

Bueno, pues podemos ver que se trata de una instancia Sybase lanzada con un par de dataservers por debajo.

En fin, vamos al meollo de la cuestión, averiguar cuales son todos los procesos que están escuchando. Filtremos un poco las opciones de lsof, buscando un puerto concreto y un estado concreto: LISTEN. En caso necesario, también se podría buscar procesos vinculados a un puerto buscando por BOUND.

root@madhatter # lsof -i | egrep LISTEN|grep 2640
aocarga_S  5770   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)
aocarga_S  6742   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)
aocarga_S  7303   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)
aocarga_S  7982   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)
aocarga_S  9387   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)
aocarga_S  9574   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)
aocarga_S 10571   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)
sleep     12052   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)
sleep     12063   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)
sleep     12066   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)
sleep     12070   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)
sleep     12071   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)
sleep     12074   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)
sleep     12075   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)
sleep     12078   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)
sleep     12080   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)
sleep     12084   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)
sleep     12085   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)
aocarga_S 16192   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)
aocarga_S 20088   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)
fcunw     22710   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)
aocarga_S 22714   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)
aocarga_S 22715   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)
fcunw     22768   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)
fcunw     27050   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)
fcunw     27372   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)

Quizás deberíamos hablar un día del fascinante mundo de los puertos…

Y como gran final, lo unimos todo en una línea gracias a la magia de UNIX

root@madhatter # lsof -i | egrep LISTEN|grep 2640 |nawk ' {print $2}'

Caballeros, ya pueden empezar a mandar kills a estos procesos para que mueran ordenadamente. Ar!.

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.

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.

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.

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

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

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.

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

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

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