Cómo se puede emular la perdida de un disco externo en Linux

Una de las pruebas de certificación de los Clusters de Oracle es observar el comportamiento ante la pérdida de uno de los voting disk.

Estos discos normalmente se presentan a los servidores desde cabinas de almacenamiento externo y suelen tener varios caminos (dependiendo de las tarjetas HBA que dispongamos en el sistema).

Para emular la caída de un disco simplemente tenemos que enviar comandos scsi al dispositivo de bloque, indicándole que cambie su estado a offline.

Vamos a ver un ejemplo:


Primero buscamos nuestro disco objetivo. En un entorno Red Hat ejecutaríamos el comando "multipath -ll"

CRS1 (20017380050d10023) dm-2 IBM,2810XIV
size=16G features='0' hwhandler='0' wp=rw
|-+- policy='round-robin 0' prio=1 status=enabled
| `- 7:0:0:1 sdb 8:16  active ready running
|-+- policy='round-robin 0' prio=1 status=enabled
| `- 8:0:0:1 sdf 8:80  active ready running
|-+- policy='round-robin 0' prio=1 status=enabled
| `- 7:0:1:1 sdj 8:144 active ready running
`-+- policy='round-robin 0' prio=1 status=active
  `- 8:0:1:1 sdn 8:208 active ready running

Podemos ver que los distintos caminos se corresponden a los dispositivos de bloque "sdb, sdf, sdj, sdn".

Ahora tenemos que poner offline cada uno de los caminos, para ello haríamos esto con cada uno (sólo mostramos el último):

# echo offline > /sys/class/block/sdn/device/state

Si hacemos un cat al fichero "state" de cada uno de los dispositivos, podremos ver que están "offline".

En "messages" veríamos estos mensajes:

Apr 23 15:54:00 server kernel: sd 7:0:0:1: rejecting I/O to offline device
Apr 23 15:54:00 server kernel: device-mapper: multipath: Failing path 8:16.
Apr 23 15:54:00 server multipathd: 8:16: mark as failed
Apr 23 15:54:00 server multipathd: CRS1: remaining active paths: 3
Apr 23 15:54:10 server kernel: sd 8:0:0:1: rejecting I/O to offline device
Apr 23 15:54:10 server kernel: device-mapper: multipath: Failing path 8:80.
Apr 23 15:54:10 server multipathd: 8:80: mark as failed
Apr 23 15:54:10 server multipathd: CRS1: remaining active paths: 2
Apr 23 15:54:18 server kernel: sd 7:0:1:1: rejecting I/O to offline device
Apr 23 15:54:18 server kernel: device-mapper: multipath: Failing path 8:144.
Apr 23 15:54:18 server multipathd: 8:144: mark as failed
Apr 23 15:54:18 server multipathd: CRS1: remaining active paths: 1
Apr 23 15:54:32 server kernel: sd 8:0:1:1: rejecting I/O to offline device
Apr 23 15:54:32 server kernel: device-mapper: multipath: Failing path 8:208.
Apr 23 15:54:32 server kernel: end_request: I/O error, dev dm-2, sector 524368
Apr 23 15:54:32 server multipathd: 8:208: mark as failed
Apr 23 15:54:32 server multipathd: CRS1: remaining active paths: 0
Apr 23 15:54:33 server kernel: end_request: I/O error, dev dm-2, sector 0
Apr 23 15:54:33 server kernel: end_request: I/O error, dev dm-2, sector 4151

Para ponerlos en en el estado normal ejecutaríamos en cada dispositivo:

# echo running > /sys/class/block/sdn/device/state

Y veríamos en "messages" la recuperación:

Apr 23 16:05:01 server multipathd: CRS1: sdn - directio checker reports path is up
Apr 23 16:05:01 server multipathd: 8:208: reinstated
Apr 23 16:05:01 server multipathd: CRS1: remaining active paths: 1
Apr 23 16:05:14 server multipathd: CRS1: sdj - directio checker reports path is up
Apr 23 16:05:14 server multipathd: 8:144: reinstated
Apr 23 16:05:14 server multipathd: CRS1: remaining active paths: 2
Apr 23 16:05:25 server multipathd: CRS1: sdf - directio checker reports path is up
Apr 23 16:05:25 server multipathd: 8:80: reinstated
Apr 23 16:05:25 server multipathd: CRS1: remaining active paths: 3
Apr 23 16:05:40 server multipathd: CRS1: sdb - directio checker reports path is up
Apr 23 16:05:40 server multipathd: 8:16: reinstated
Apr 23 16:05:40 server multipathd: CRS1: remaining active paths: 4

¿Qué es lo invisible?

Gracias al TED encontré un vídeo muy interesante de dibujos animados explicando cómo hay muchas cosas invisibles para nosotros y tratando de hacer que las comprendamos aunque sea un poquito.

De optimizaciones de MySQL

Hace ya un tiempo que no escribo ninguna entrada en el blog debido a la cantidad de trabajo que me está viniendo encima, que viendo los tiempos que corren, quizás hay que pensar que es más una cuestión de fortuna que de desgracia.

Sigamos con lo que me interesa. El hecho es que mi grupo se va a hacer cargo de un despliegue web de un cliente. El despliegue es servicio un servidor web Apache con PHP, una base de datos MySQL. Al trabajar en el mundo de la consultoría, para bien o para mal, hay otro grupo que hace el "delivery", es decir, ellos preparan las instalaciones y me las traspasan. En este caso, el cliente estaba bastante cabreado con el delivery de bases de datos. Es común pensar que MySQL es una base de datos de juguete, y entonces lo que hacen las consultoras es coger a un administrador de base de datos de Oracle, que es una base de datos de verdad, y lo ponen a preparar la entraega. En nuestro caso ha pasado, que el cliente no sólo no es tonto, sino que encima sabe técnicamente y ha llegado un momento en el que ha visto que no se ha optimizado la base de datos sino que la base de datos era un cuello de botella.

Finalmente nos han traspasado a nosotros el Delivery de la base de datos, lo hemos hecho y el cliente está un poco más contento porque ahora la base de datos funciona bien. Ahora yo me pregunto, ¿tengo que hacer yo la documentación de algo que me tienen que traspasar?.

Respecto a las optimizaciones nos dedicamos a seguir las recomendaciones de la web de mysql, o en caso de duda, las de mysqlperformance.

Finalmente la sensación que tengo es que la mejora en la base de datos viene dada por el aumento de dos variables:

innodb_read_io_threads
innodb_write_io_threads

Con 12 cores situamos los parámetros anteriores en 24, y da la sensación de que esa ha sido la mejora sustancial.

Ahora se ha traspasado la responsabilidad a Apache, pero realmente por mucho que optimicemos, hay una seguridad del 90% de que haya que optimizar el código php, y norlmalmente esta es la parte menos flexible.

Sucesos extraños con ext4

Hace poco más de seis meses cambié de distribución en mi portátil y pasé de uno de los sabores de Debian (Mint), a uno de los sabores de RedHat (Fedora). Hasta la fecha la experiencia de usuario, mía y de mi mujer (que no es técnica) no ha podido ser más satisfactoria.

Hace un par de semanas asistí a un taller de Oracle Weblogic y allí me sucedió una cosa muy extraña. Encendí mi portátil, y se me quedó en el arranque indicándome que había un filesystem con muchos fallos y que tenía que ejecutar un fsck a ese filesystem manualmente. El filesystem en cuestión era /home, debido a lo cual me eché a temblar y casi a tener sudores fríos.

Después de unos 20 minutos de fsck, me cansé y pensé en montarlo para ver si había perdido mucha información, y para mi sorpresa estaba toda (o eso parecía).

¿Qué había hecho fuera de lo normal con ese filesystem los días previos? Pues simplemente lo había extendido en 10 GB con lvm y redimensionado con resize2fs.

Ese mismo día tuve que extender /tmp para que pudiera soportar la descompresión de weblogic. En el siguiente reinicio tenía los errores en /home y en /tmp. Está claro que hay un problema con ext4 y el redimensionamiento, quizás con las herramientas de redimensionamiento y el ext4 propiamente, quizás con lvm., realmente no lo sé, no he investigado demasiado, pero por las pocas cadenas que busqué no encontré nada. Los problemas que indicaban que había eran extraños, activado el flag del compresión en ínodos que no están comprimidos, ínodos que parecen directorios, pero que son ficheros..., etc, etc..., lo peor es que eran muchísimos. Ejecuté una noche el  fsck y estuvo toda la noche corrigiendo errores sin terminar.

Finalmente la solución fue muy sencilla. Creé un nuevo filesystem del mismo tamaño, copié toda la información ahí, cambié la entrada del fstab, y todo volvió a funcionar. Ahora tengo pendiente la parte de investigación, puesto que tiemblo pensando que me pueda volver a pasar el mismo problema.

Cómo saber que tamaño tiene una base de datos en mysql

Desde el cambio a la versión 5 de MySQL in con la introducción de las vistas del Information_schema, saber qué tamaño tiene una base de datos es relativamente fácil, tan fácil como ejecutar esta consulta:

SELECT table_schema "Data Base Name", sum( data_length + index_length ) / 1024 / 1024 "Data Base Size in MB"

FROM information_schema.TABLES GROUP BY table_schema ; 

El problema surge cuando tenemos una base de datos de la versión 4, ya que en estas versiones MySQL no disponía de Information_schema.

Yo he hecho un pequeño script que  parsea la información que proporciona el SHOW TABLE STATUS, de modo que me da un valor aproximado.

El script sería éste:
(lista_basesdatos es una lista con las bases de datos que quiero medir)

#!/bin/bash



for i in `cat lista_basesdedatos`; do



a=`mysql -u root -D ${i} -e 'show table status\G'|grep Data_l|awk '{print $2}'|(tr '\n' +; echo 0)|bc`

b=`mysql -u root -D ${i} -e 'show table status\G'|grep Index_l|awk '{print $2}'|(tr '\n' +; echo 0)|bc`



resultado=`echo $a+$b|bc`;



echo $i $resultado

done